Ack/Fin packets dropped.
Tue, 31 Jul 2001 19:19:31 +0200
On Mon, 30 Jul 2001 19:31:11 -0300, Harald Welte <email@example.com> =
>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:
>> > > Perhaps - but obviously not long enough. I have dozens of those =
>> > > every day on my very low-traffic home firewall.
>> > Do they demonstrably break functionality, or just make you nervous?
>> Well, alternative to new "buttons" would be opportunity to filter =
>> log entries (which, in turn, just pollute log files and it is easy =
>> miss something important).
>> Is there any filtering opportunity? I fear - no, though... On one of=
>> systems (proxy) I see thousands of such entries every day, and this =
>> 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 =
by ULOG filtering would be a dirty hack that probably wouldn't even work =
well in practice - what should be the filter criteria?
The packets that I currently get logged, but do not want logged, differs =
other packets only by being part of a valid connection. In order to =
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 =
have conntrack for.
The problem is that conntrack does not correctly distinguish between =
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 =
timeout value. Until now, I don't think anybody has offered a reason =
increase that value. Is there a good reason?
Obviously a longer timeout value means that conntrack will sometimes use =
memory; but one the other hand, I suspect that the TCP protocol stack may=
more memory when, because conntrack has erroneously dropped the =
does not get the ACK/FIN-packets it should get. And even if the short =
value does save a little memory, is it really worth the price of more or =
ruining the usability of all netfilter logging?
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).