Dear People;
[ no one probably cares, but the gist is that you may not want to enable
the tcp SACK option, which seems to be on by default in my 2.2.10, at least ]
In a previous posting, I had a number of questions about what was happening
to a stuck tcp connection involving the tcp SACK option.
[ RE: trouble in the SACK? ]
I apologize for some fragmentory tcpdump logs I included, and an incorrect
assertion that tcpdump had a bug with regard to its display of relative
sequences. It obviously does not; I was confused by my poor truncated log.
The unimitable Alan Cox postulated that I had a weird modem bug, but I
feel confident that because my problem downloading a file was extremely
reproduceable when the kernel had SACK enabled, and went away after it
was disabled, and never exhibits itself when connecting to machines that
do not support SACK, that it is not my modem, but SACK:)
After a lot more tests, and thinking, I have to come the conclusion that
linux is doing the right thing, and that several (at least 3) machines
out there on the net are very broken when it comes to SACK.
I would like someone who knows more about this, to perhaps verify my
conclusion. From now on, Im running with SACK disabled.
Here is a summary of what happens, and an anotated tcpdump log to back it
up:
Both machines set the sackOK option in their SYN packets.
The download begins....
A packet gets dropped at some random point.
At this point I have a hole in my tcp sequence, and all further segments
are buffered; the user stops getting data at this point.
I set my SACK option to reflect all the new segments arriving after
the lost one.
Eventually, the other side trys to fill in my missing segment. However,
it sends the wrong segment (the one that preceeded the lost one.)
I ack this, but Ive still got a hole.
At this point, the connection slows way down, and the sender insists on
sending me the wrong segment that I already have every minute or so.
This goes on forever, and the user app hangs.
Ive seen this behaviour talking to at least 3 machines:
helios.metalab.unc.edu (http://sunsite.unc.edu)
ciumix.ci.uminho.pt
gd.tuwien.ac.at
Paul
[EMAIL PROTECTED]
ps. I have more mind numbing tcpdump logs, one of which shows a slightly
different but equally broken behaviour when 2 segments were lost....
Here is the tcpdump logs:
### We agree on sack
18:46:26.530000 ME.1454 > THEM.www: S 859951913:859951913(0) win 32472 <mss
984,sackOK,timestamp 6499861 0,nop,wscale 0> (DF)
18:46:26.740000 THEM.www > ME.1454: S 2315407707:2315407707(0) ack 859951914 win 9720
<nop,nop,timestamp 63957962 6499861,nop,wscale 0,nop,nop,sackOK,mss 984> (DF)
...
### downloading a lot of contiguous segments, deleted...
...
18:49:52.370000 THEM.www > ME.1454: . 2315966047:2315967019(972) ack 859952539 win
9720 <nop,nop,timestamp 63977457 6519363> (DF)
18:49:52.720000 THEM.www > ME.1454: . 2315967019:2315967991(972) ack 859952539 win
9720 <nop,nop,timestamp 63977457 6519363> (DF)
18:49:52.720000 ME.1454 > THEM.www: . ack 2315967991 win 31104 <nop,nop,timestamp
6520480 63977457> (DF)
18:49:53.070000 THEM.www > ME.1454: . 2315967991:2315968963(972) ack 859952539 win
9720 <nop,nop,timestamp 63977528 6519434> (DF)
### missing one segment: this is where 2315968963:2315969935 is supposed to be
18:49:53.430000 THEM.www > ME.1454: . 2315969935:2315970907(972) ack 859952539 win
9720 <nop,nop,timestamp 63977598 6519504> (DF)
18:49:53.430000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6520551 63977598,nop,nop,sack 2315969935 2315970907> (DF)
### we ack our last contiguous sequence, and begin notifying the sender
### of our sack position, which will continue to expand as they send new
### data. Skip down to the next comment.
18:49:53.780000 THEM.www > ME.1454: . 2315970907:2315971879(972) ack 859952539 win
9720 <nop,nop,timestamp 63977598 6519504> (DF)
18:49:53.780000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6520586 63977598,nop,nop,sack 2315969935 2315971879> (DF)
18:49:54.140000 THEM.www > ME.1454: . 2315971879:2315972851(972) ack 859952539 win
9720 <nop,nop,timestamp 63977669 6519575> (DF)
18:49:54.140000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6520622 63977669,nop,nop,sack 2315969935 2315972851> (DF)
...
### a lot of sequential segments of size 972, deleted
...
18:50:02.610000 THEM.www > ME.1454: . 2315995207:2315996179(972) ack 859952539 win
9720 <nop,nop,timestamp 63978516 6520423> (DF)
18:50:02.610000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6521469 63978516,nop,nop,sack 2315969935 2315996179> (DF)
18:50:02.950000 THEM.www > ME.1454: . 2315996179:2315997151(972) ack 859952539 win
9720 <nop,nop,timestamp 63978516 6520423> (DF)
18:50:02.950000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6521503 63978516,nop,nop,sack 2315969935 2315997151> (DF)
18:50:03.190000 THEM.www > ME.1454: P 2315997151:2315997843(692) ack 859952539 win
9720 <nop,nop,timestamp 63978516 6520423> (DF)
### hmmmm. Why this shorter packet with PUSH set....?
18:50:03.190000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6521527 63978516,nop,nop,sack 2315969935 2315997843> (DF)
18:50:03.560000 THEM.www > ME.1454: . 2315997843:2315998815(972) ack 859952539 win
9720 <nop,nop,timestamp 63978574 6520480> (DF)
18:50:03.560000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6521564 63978574,nop,nop,sack 2315969935 2315998815> (DF)
### We ack on the last new piece of data they will be sending. Our sack
### range covers 28,880 bytes which were sent in and received correctly
### since a segment was dropped.
18:50:03.930000 THEM.www > ME.1454: . 2315967991:2315968963(972) ack 859952539 win
9720 <nop,nop,timestamp 63978962 6520480> (DF)
### ok. they sent us an 'old' segment, but its the wrong one! Weve already
### acked this segment, we want 2315968963:2315969935 !
18:50:03.930000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6521601 63978962,nop,nop,sack 2315969935 2315998815> (DF)
### we ack it, and maintain our sack position
18:50:25.830000 THEM.www > ME.1454: . 2315967991:2315968963(972) ack 859952539 win
9720 <nop,nop,timestamp 63981830 6520480> (DF)
### they keep sending us the wrong packet. This seems to repeat endlessly.
### Packets come very slowly after this, almost like they never hear our ack.
18:50:25.830000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6523791 63981830,nop,nop,sack 2315969935 2315998815> (DF)
18:51:23.210000 THEM.www > ME.1454: . 2315967991:2315968963(972) ack 859952539 win
9720 <nop,nop,timestamp 63987566 6520480> (DF)
18:51:23.210000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6529529 63987566,nop,nop,sack 2315969935 2315998815> (DF)
18:52:23.230000 THEM.www > ME.1454: . 2315967991:2315968963(972) ack 859952539 win
9720 <nop,nop,timestamp 63993566 6520480> (DF)
18:52:23.230000 ME.1454 > THEM.www: . ack 2315968963 win 31104 <nop,nop,timestamp
6535531 63993566,nop,nop,sack 2315969935 2315998815> (DF)
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
