Ack/Fin packets dropped.

[Jesper Dybdal]

On Mon, 30 Jul 2001 19:31:11 -0300, Harald Welte <laforge@gnumonks.org> =
wrote:

>On Mon, Jul 30, 2001 at 07:41:06PM +0200, Alexander Demenshin wrote:
>> On Mon, Jul 30, 2001 at 07:30:10PM +0200, Patrick Schaaf wrote:
>>=20
>> > > Perhaps - but obviously not long enough.  I have dozens of those =
log entries
>> > > every day on my very low-traffic home firewall.
>> >=20
>> > Do they demonstrably break functionality, or just make you nervous?
>>=20
>>   Well, alternative to new "buttons" would be opportunity to filter =
those
>>   log entries (which, in turn, just pollute log files and it is easy =
to
>>   miss something important).
>>=20
>>   Is there any filtering opportunity? I fear - no, though... On one of=
 my
>>   systems (proxy) I see thousands of such entries every day, and this =
is
>>   not very busy proxy, BTW...
>
>so why don't you use ULOG and ulogd?=20

Because this is a conntrack problem.  Trying to circumvent it =
half-heartedly
by ULOG filtering would be a dirty hack that probably wouldn't even work =
very
well in practice - what should be the filter criteria?

The packets that I currently get logged, but do not want logged, differs =
from
other packets only by being part of a valid connection.  In order to =
determine
whether to log these packets, we need to know whether they are part of a
connection.  That requires stateful analysis, and that is precisely what =
we
have conntrack for.

The problem is that conntrack does not correctly distinguish between =
packets
belonging to a connection and packets not belonging to a connection.

That should really be solved by fixing conntrack.

As I understand it, this conntrack bug can be fixed simply by increasing =
a
timeout value.  Until now, I don't think anybody has offered a reason =
_not_ to
increase that value.  Is there a good reason?

Obviously a longer timeout value means that conntrack will sometimes use =
more
memory; but one the other hand, I suspect that the TCP protocol stack may=
 use
more memory when, because conntrack has erroneously dropped the =
connection, it
does not get the ACK/FIN-packets it should get.  And even if the short =
timeout
value does save a little memory, is it really worth the price of more or =
less
ruining the usability of all netfilter logging?
--=20
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).