On Thu, 2004-06-24 at 06:44, Antony Stone wrote: > > The other thing you see logged quite often for similar reasons is FIN-ACK > packets - the reply FIN-ACK is regarded as optional by many systems, so > netfilter often ends up logging (and dropping) the second one to come along. IMHO this is completely non-RFC. It is clearly defined (RFC 793 page 22) that both sides must issue a FIN/ACK and receive an ACK before the connection is closed. What OS does not issue the reciprocating FIN/ACK? > No harm done though, because the first one has done the job. Actually not quite true as both sides will enter a fin-wait state (RFC 793 page 20) till the second FIN/ACK-ACK exchange takes place. This chews up a session on both ends till their timers expire. Add up enough of them and it can kill a busy server (seen it happen and have had to stop state tracking to fix it). The "problem" is that there is no requirement for the second FIN to be immediately issued. The remote host is free to continue to send data till it is finished. Sometimes this exceeds iptables's timer for the FIN portion of the session, thus causing the problem many of us are seeing. Also, if you check the log entry that was posted: > Jun 23 16:42:43 javagreen kernel: New not syn:IN=eth0 OUT= > MAC=00:09:6b:19:b4:24:00:0e:83:f6:19:9f:08:00 SRC=202.138.101.5 > DST=202.138.22.218 LEN=1500 TOS=0x00 PREC=0x00 TTL=122 ID=51601 DF > PROTO=TCP SPT=80 DPT=2162 WINDOW=64574 RES=0x00 ACK URGP=0 Its a 1500 byte ACK packet. So iptables is not just blocking the FIN/ACK exchange, it can sometimes end up blocking data transfer as well. :( I reported this "bug" back when iptables was still alpha code. At the time iptables would expire the session 60 seconds after the first FIN has been passed. I think Rusty bumped the timer up to 2 minutes. Perhaps its been tweaked back down again or needs to be increased to 3 minutes? HTH, Chris
