LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   TCP session establishment problem (https://www.linuxquestions.org/questions/linux-networking-3/tcp-session-establishment-problem-811486/)

slonko 06-01-2010 10:10 AM

TCP session establishment problem
 
Hi,

I'm having a strange problem since moving from 2.4 kernel to 2.6 kernel (the perth-osl.xxx.com side).
The other side (222.22...) is a windows XP machine.

Sometimes, especially when the network it being slow I get:

Code:

12:37:32.928519 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: S 3883977415:3883977415(0) win 65535 <mss 1360,nop,nop,sackOK>
12:37:32.928636 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: S 2090190464:2090190464(0) ack 3883977416 win 5840 <mss 1460,nop,nop,sackOK>
12:37:32.978249 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: . ack 1 win 65535
12:37:32.981169 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: P 1:21(20) ack 1 win 65535
12:37:36.097959 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: P 1:21(20) ack 1 win 65535
12:37:36.725371 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: S 2090190464:2090190464(0) ack 3883977416 win 5840 <mss 1460,nop,nop,sackOK>
12:37:36.819041 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: . ack 1 win 5840 <mss 1460,nop,nop,sackOK>
12:37:42.101672 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: P 1:21(20) ack 1 win 65535
12:37:43.127328 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: S 2090190464:2090190464(0) ack 3883977416 win 5840 <mss 1460,nop,nop,sackOK>
12:37:43.156299 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: . ack 1 win 5840 <mss 1460,nop,nop,sackOK>
12:38:01.159284 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: P 2806504154:2806504174(20) ack 393835729 win 65535
12:38:02.331817 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: S 2484026192:2484026192(0) ack 2395514273 win 5840 <mss 1460,nop,nop,sackOK>
12:38:02.455857 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: . ack 1 win 5840 <mss 1460,nop,nop,sackOK>
12:38:07.207778 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: P 1:21(20) ack 1 win 65535
12:38:08.733431 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: S 2484026192:2484026192(0) ack 2395514273 win 5840 <mss 1460,nop,nop,sackOK>
12:38:08.792863 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: . ack 1 win 5840 <mss 1460,nop,nop,sackOK>
12:38:18.192005 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: R 21:21(0) ack 1 win 0

Normally I get:

Code:

13:37:51.562808 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: S 4156813987:4156813987(0) win 65535 <mss 1360,nop,nop,sackOK>
13:37:51.562953 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: S 2988453294:2988453294(0) ack 4156813988 win 5840 <mss 1460,nop,nop,sackOK>
13:37:51.612869 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: . ack 1 win 65535
13:37:51.614285 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: P 1:21(20) ack 1 win 65535
13:37:51.614371 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: . ack 21 win 5840
13:37:53.197735 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: P 1:3(2) ack 21 win 5840
13:37:53.257837 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: P 21:39(18) ack 3 win 65533
13:37:53.257965 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: . ack 39 win 5840
13:37:54.589883 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: P 3:5(2) ack 39 win 5840
13:37:54.798966 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: . ack 5 win 65531
13:37:54.799079 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: P 5:18(13) ack 39 win 5840
13:37:54.849813 //IP 222.222.22.172.2001 > perth-osl.xxx.com.2001: P 39:41(2) ack 18 win 65518
13:37:54.849951 \\IP perth-osl.xxx.com.2001 > 222.222.22.172.2001: . ack 41 win 5840


I added the // and \\ so that when you view it as C code the RX/TX gets chroma-coded.

Also when this happens the netstat reports the socket to be in SYN_RECV state.

Rebooting the Linux end makes no difference, changing the port number that I use (2001 is a bit naughty) also makes no difference.

I would like to know why the Linux end will not stop SYN-ACKing the original SYN-REQ and get on with it (at least I think that's what is happening?).

Any help or questions would be appreciated!

Dan

slonko 06-04-2010 09:50 AM

If anyone is interested, I think this is being caused by a listen queue overflow on my socket which causes this strange behavior as detailed here:
http://www.cs.uwaterloo.ca/~brecht/t...ukla-MMath.pdf


All times are GMT -5. The time now is 04:20 AM.