On Wed, 26 Mar 2008, Jozsef Kadlecsik wrote:
On Wed, 26 Mar 2008, Patrick McHardy wrote:
During a run with stalls:
nf_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT=
SRC=100.100.100.100 DST=200.200.200.200 LEN=80 TOS=0x00 PREC=0x00 TTL=56
ID=44105
DF PROTO=TCP SPT=22 DPT=35858 SEQ=4160349927 ACK=596614326 WINDOW=49248
RES=0x00 ACK URGP=0 OPT
(0101080A4558793C1B13CE350101051A491E8751491E8CA9491E7B71491E81F9491E40A9491E5B61)
Thanks, can you send a binary tcpdump (... -w file) of a connection
that triggers these messages please?
Yes, a tcpdump of a full session which is stalled could help a lot.
But it almost look like as a SACK related problem: isn't there a (new)
device between the communicating parties which performs ISN randomization
and fails to adjust SACK?
Yep.
$ ./optparse 0101080A4558793C1B13CE350101051A491E8751491E8CA9491E7B71491E81F9491E40A9491E5B61
No-Operation
No-Operation
TSOPT - Time Stamp Option(8) tv=1163426108 er=454282805
No-Operation
No-Operation
SACK(24) 1226737489:1226738857(1368) 1226734449:1226736121(1672) 1226719401:1226726241(6840)
So, SEQ=4160349927 & ACK=596614326 vs. 12267????? is obviously wrong.
Best regards,
Krzysztof Olędzki
