On Thu, 11 Aug 2011, John A. Sullivan III wrote: > > That might be related to SACK option handling: some "clever" devices loves > > to mangle TCP SEQ/ACK values, but forget about the SACK options. Try to > > disable SACK support on both communicating endpoints. If the problem > > disappears, then it's a SACK issue. > > > <snip> > Alas, it is not SACK. We disabled sack and dsack on both sides of one > user and it still took all of a few seconds for him to lock up. > > Where do we look next? Thanks - John Please capture a full TCP session traffic (from the very first SYN to the very last ACK) with "tcpdump -s 0 ..." and send me the pcap file. Then I'll be able to replay it and check what's going on. 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
