Hmmm, very strange.
198.70.117.9.80 > 195.240.25.5.1684: . 235553:236992(1439) ack 345 win 8416 (DF)
195.240.25.5.1684 > 198.70.117.9.80: . ack 236992 win 15360
Ok, at this point the are no out of order segments in the receivers
queue. Here is where the fun begins.
198.70.117.9.80 > 195.240.25.5.1684: . 238431:239870(1439) ack 345 win 8416 (DF)
195.240.25.5.1684 > 198.70.117.9.80: . ack 236992 win 15360
Ok, a segment didn't make it and got dropped for one reason or
another, we should have seen:
198.70.117.9.80 > 195.240.25.5.1684: . 236992:238431(1439) ack 345 win 8416 (DF)
If that packet had made it, thus as we see a duplicate ack is sent.
22:31:02.472338 195.240.25.5.1684 > 198.70.117.9.80: . ack 236992 win 15360
Another duplicate ack is sent.
22:35:58.240782 195.240.25.5.1684 > 198.70.117.9.80: F 345:345(0) ack 236992 win 15360
22:35:58.600782 198.70.117.9.80 > 195.240.25.5.1684: R 242947007:242947007(0) win 0
What baffles me is that in this five minute period the other end
appears to be making no attempt to perform any retransmits for the
segment 236992:238431(1439) (either via repacketization of flat out
the same sequence space). Although it is highly possible that the
line was bad enough to drop any retransmits made during that 5 minute
period, but I doubt this is what has happened due to how quickly our
end got reset when the bogus FIN was sent.
---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><