On Tue, 8 Jul 2008, Robert L Mathews wrote: > Jozsef Kadlecsik wrote: > > > If the data packet sent by the server is valid, the client should send an > > ACK and not a RST packet. If the data packet is invalid, the client should > > send an ACK again and not a RST. > > Actually, unless I'm misunderstanding, RFC1122 section 4.2.2.13 seems to allow > what the client is doing: > > A host MAY implement a "half-duplex" TCP close sequence, so > that an application that has called CLOSE cannot continue to > read data from the connection. If such a host issues a > CLOSE call while received data is still pending in TCP, or > if new data is received after CLOSE is called, its TCP > SHOULD send a RST to show that data was lost. > > So in this case, the client app closed the connection even though there was > data from the server that hadn't been delivered, and the client's TCP stack > replied with a RST as described above. Yes, that's correct and I was wrong above. > > If the server receives the RST packet (and it's valid) it should never ever > > send unsent data but destroy the connection. > > That's what I would have thought, but packet dumps are showing otherwise. On a > standard Debian 2.6.24 kernel it keeps retrying the un-acked packet for more > than a minute despite the RST, as shown at the end of: > > http://tigertech.net/20080703.tcpdump.server.txt Is the RST segment valid? Could you create a dump file using the '-S' flag of tcpdump so that not relative but absolute sequence numbers are printed? Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
