Okay... this is my previous CLOSING problem, but I've worked out that it's
being caused by the ACK field not being noticed. Attached is a tcpdump of a
connection which ended up hung in the CLOSING state. As you can see, the first
FIN|ACK is a good one, but then our FIN gets acked in another FIN|ACK. Normal
systems will just send a standard ACK.

Anyone can find out why this happens?

Taral
17:57:35.114069 208.247.22.222.1044 > 128.83.126.1.110: S 1949272623:1949272623(0) win 
32120 <mss 1460,sackOK,timestamp 112649[|tcp]> (DF) (ttl 64, id 2901)
17:57:35.150707 128.83.126.1.110 > 208.247.22.222.1044: S 7608503:7608503(0) ack 
1949272624 win 8760 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) (ttl 49, id 
48180)
17:57:35.150946 208.247.22.222.1044 > 128.83.126.1.110: . ack 1 win 32120 
<nop,nop,timestamp 112653 32361353> (DF) (ttl 64, id 2902)
17:57:35.179615 128.83.126.1.110 > 208.247.22.222.1044: P 1:39(38) ack 1 win 8760 
<nop,nop,timestamp 32361353 112653> (DF) (ttl 49, id 48206)
17:57:35.179830 208.247.22.222.1044 > 128.83.126.1.110: . ack 39 win 32120 
<nop,nop,timestamp 112655 32361353> (DF) (ttl 64, id 2903)
17:57:35.180286 208.247.22.222.1044 > 128.83.126.1.110: P 1:13(12) ack 39 win 32120 
<nop,nop,timestamp 112655 32361353> (DF) (ttl 64, id 2904)
17:57:35.204147 128.83.126.1.110 > 208.247.22.222.1044: P 39:45(6) ack 13 win 8760 
<nop,nop,timestamp 32361353 112655> (DF) (ttl 49, id 48214)
17:57:35.204518 208.247.22.222.1044 > 128.83.126.1.110: P 13:29(16) ack 45 win 32120 
<nop,nop,timestamp 112658 32361353> (DF) (ttl 64, id 2905)
17:57:35.340956 128.83.126.1.110 > 208.247.22.222.1044: . ack 29 win 8760 
<nop,nop,timestamp 32361353 112658> (DF) (ttl 49, id 48332)
17:57:35.533011 128.83.126.1.110 > 208.247.22.222.1044: P 45:75(30) ack 29 win 8760 
<nop,nop,timestamp 32361354 112658> (DF) (ttl 49, id 48424)
17:57:35.550386 208.247.22.222.1044 > 128.83.126.1.110: . ack 75 win 32120 
<nop,nop,timestamp 112693 32361354> (DF) (ttl 64, id 2906)
17:57:38.540077 208.247.22.222.1044 > 128.83.126.1.110: P 29:35(6) ack 75 win 32120 
<nop,nop,timestamp 112992 32361354> (DF) (ttl 64, id 2907)
17:57:38.559787 128.83.126.1.110 > 208.247.22.222.1044: P 75:84(9) ack 35 win 8760 
<nop,nop,timestamp 32361360 112992> (DF) (ttl 49, id 50503)
17:57:38.567185 208.247.22.222.1044 > 128.83.126.1.110: P 35:41(6) ack 84 win 32120 
<nop,nop,timestamp 112994 32361360> (DF) (ttl 64, id 2908)
17:57:38.601569 128.83.126.1.110 > 208.247.22.222.1044: P 84:98(14) ack 41 win 8760 
<nop,nop,timestamp 32361360 112994> (DF) (ttl 49, id 50547)
17:57:38.602030 208.247.22.222.1044 > 128.83.126.1.110: F 41:41(0) ack 98 win 32120 
<nop,nop,timestamp 112998 32361360> (DF) (ttl 64, id 2909)
17:57:38.603186 128.83.126.1.110 > 208.247.22.222.1044: F 98:98(0) ack 41 win 8760 
<nop,nop,timestamp 32361360 112994> (DF) (ttl 49, id 50549)
17:57:38.603274 208.247.22.222.1044 > 128.83.126.1.110: . ack 99 win 32120 
<nop,nop,timestamp 112998 32361360> (DF) (ttl 64, id 2910)
17:57:38.630922 128.83.126.1.110 > 208.247.22.222.1044: F 98:98(0) ack 42 win 8760 
<nop,nop,timestamp 32361360 112998> (DF) (ttl 49, id 50580)
17:57:38.631042 208.247.22.222.1044 > 128.83.126.1.110: . ack 99 win 32120 
<nop,nop,timestamp 113001 32361360> (DF) (ttl 64, id 2913)
17:57:38.819870 208.247.22.222.1044 > 128.83.126.1.110: F 41:41(0) ack 99 win 32120 
<nop,nop,timestamp 113020 32361360> (DF) (ttl 64, id 2916)
17:57:39.259780 208.247.22.222.1044 > 128.83.126.1.110: F 41:41(0) ack 99 win 32120 
<nop,nop,timestamp 113064 32361360> (DF) (ttl 64, id 2917)
17:57:40.139639 208.247.22.222.1044 > 128.83.126.1.110: F 41:41(0) ack 99 win 32120 
<nop,nop,timestamp 113152 32361360> (DF) (ttl 64, id 2918)
17:57:41.899346 208.247.22.222.1044 > 128.83.126.1.110: F 41:41(0) ack 99 win 32120 
<nop,nop,timestamp 113328 32361360> (DF) (ttl 64, id 2919)

Reply via email to