[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: Postfix timeouts  (dynamic IPF upgrade?)
From:       "Stuart Remphrey" <stuart.remphrey () rmit ! edu ! au>
Date:       2008-01-25 8:41:38
Message-ID: 479A3B70.2CD7.004D.1 () ems ! rmit ! edu ! au
[Download RAW message or body]

Hi Gabriele,

In theory you could unload the ipf module, although it must be
un-referenced first (you could disable IP Filter, which would
presumably release the kernel module - I've not tried).

However when the new filter loads it would create a fresh
(empty) state table, potentially blocking existing connections.


Perhaps reloading could be done in conjunction with manually
saving and restoring the state table (see ipf man page), but
what about sessions that either start or terminate in the meantime?

You could try duplicating all the "flags S/... keep state" tcp rules
with others that don't care about seeing the initial SYN, and try
to rebuild the state table on the fly, then re-restrict it some (random)
time later, but that probably would not catch all possibilities.


Hence there's a strong probability of losing some existing sessions,
without really knowing what's working and what's not...


If the system is only/mostly doing email transfer you should
be able to restart it without losing anything, after all that's
what mail queues are for.

Rgds, Stuart.


>>> On 25-Jan-08 at 6:57 pm, in message <24819021.1201247826207.JavaMail.root@www>,
Gabriele Bulfon <gbulfon@sonicle.com> wrote:
> Do you mean there is no command to dynamically unload a kernel module?
> Gabriele.
> Gabriele Bulfon - Sonicle S.r.l.
> Tel +39 028246016 Int. 30 - Fax +39 028243880
> Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
> http://www.sonicle.com 
> ----------------------------------------------------------------------------------
> Da: Ken Jones <kenj@kenandlori.com>
> A: Jefferson Ogata <Jefferson.Ogata@noaa.gov>
> Cc: Ipfilter <ipfilter@coombs.anu.edu.au>
> Data: 23 gennaio 2008 20.55.20 CET
> Oggetto: Re: Postfix timeouts
> Jeff,
> I had the issue with sendmail under solaris 10. EMail that relayed thru
> prodigy.net (MX) had the symptom of geting thru the data phase then timing
> out. By disabling ipfilter, the email delivers without issue.
> I upgraded to the latest ipfilter / pfil and the issue went away, using
> exactly the same config.
> I had googled the issue and found there are many who had experenced the 
> issue
> with prodigy.net, however I did not find any solutions.
> As for upgrading ipfilter without rebooting, I do not think you can as you
> need to reboot to unload the old driver and load the new one.
> - Ken
> On Wed, January 23, 2008 09:25, Jefferson Ogata wrote:
>> On 2008-01-23 08:20, Gabriele Bulfon wrote:
>>
>>> Blacklists are not an issue, because my connection would be refused much
>>> eralier than when it happens: it usually timeouts during the send of DATA or
>>> at the end of the DATA chunk.
>>
>> While your other diagnostic may rule out blacklists, your assumption
>> about the behavior when blacklists are involved is incorrect.
>>
>> As I mentioned, some MTAs apply a honeypot strategy to blacklisted IPs
>> in an effort to slow down the transmitter. I.e., when they will refuse based 
> on
>> a blacklist, they go as far as allowing DATA, set a very long reject delay,
>> and then respond with a 4xx or 5xx after DATA is complete. In addition, some
>> blacklist tests are held out until DATA so that content filters can be 
> applied
>> to the inbound message, and also to make it ambiguous for the sender whether 
> a
>> blacklist is involved (not that the latter is a good practice).
>>
>>> Last but not least, any of these options seem to be the case, because
>>> the queue instantly flushes correctly if I temporarily disable ipfilter and
>>> run "postqueue -f".
>>
>> When you snoop, what do you see on the outside when the hangs occur? Are
>> there retransmits going on? Was there an RST packet? Are there frags? What 
> is
>> IP filter logging? Are you using a return-rst policy for your
>> TCP block rules? What do the block rules look like? The excerpt you
>> posted is too short.
>>
>>> Infact, I noticed that the machines having those problems are the ones I
>>> recently upgraded to new hardware and consequentely coming with newer
>>> releases of Solaris 10.
>>
>> Is hardware checksumming enabled? Sometimes this causes bad behavior.
>>
>>
>>> What I'd like to know, is if there is some way to remove the original
>>> packages and replace them with compiled binaries from the distribution,
>>> without having to reboot the machines.
>>
>> I think you're better off finding the correct solution to the problem,
>> as it's unlikely that it will only exhibit itself where Postfix is involved.
>>
>> Even if you do run an alternate Postfix, there's no reason to remove the
>> native load. Just disable it.
>>
>> --
>> Jefferson Ogata <Jefferson.Ogata@noaa.gov>
>> NOAA Computer Incident Response Team (N-CIRT) <ncirt@noaa.gov>
>> "Never try to retrieve anything from a bear."--National Park Service
>>
>>
> --
> Ken Jones

[prev in list] [next in list] [prev in thread] [next in thread]