On Sun, 2 Oct 2005, Henrik Nordstrom wrote: > On Sun, 2 Oct 2005, Jozsef Kadlecsik wrote: > > > If a FIN receives which does not belong to any existing connection in > > the conntrack table, which state should we assign to the "new" connection > > "established" by the FIN? Was it the first FIN (half-closed session) or > > the second FIN from the other direction? > > If you assume it's the second then it's a good approximation, and > sufficient to push the TCP on the receiving host into a state from which > there is a guaranteed timeout as it's then only waiting on itself to > finish what it is doing. But that relies on the assumption that the receiver side wants to close the session as well. If it enters the CLOSE_WAIT state instead, the connection will hang anyway in spite of letting through the FIN and assuming the LAST_ACK state. However how would conntrack loose an (established) connection? Or are we speaking of loading in conntrack "on the fly" when there are already established connections flowing through the firewall? That's doable but hairy and unreliable anyway due to the lost window scaling parameters. > If the FIN is dropped then communication may stall indefinitely unless the > protocol is using an application level timeout or TCP keepalive. > > > I dunno how a lone RST could signal to pick up a connection. > > It should be the same as a RST in an existing connection, no more, not > much less. It has some value to the receiving host telling it to shut down > a matching TCP. But this is considerably less important than the FIN as > the RST is very unreliable anyway and protocols using initiated RST (not > in direct response to a received packet) ashould have appropriate > application level timeouts on their connections. Somehow I have got bad feelings on passing random RST segments. It is assumed (I think) that the hung connection is in the established state. That does not hurt the host, does not pose as a possible DoS situation or bottleneck. It also does not prevent establishing a new connection over the hung one, we make special efforts for enabling that. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
