1

I am puzzled by issue which my client program can't establish TCP connection to remote web server.

[scene]

Client program based on ubuntu server 12.04 LTS.

192.168.1.118 (Client program) <-------TCP---------> sync.oncecode.com (web server)

[phenomenon]

Client sends SYN, Web Server replies with SYN/ACK and the client immediately sends RST. I can't see anything out of whack in the TCP/IP headers. Could someone give me a clue what might be happening here? I have ran out of ideas ...

[Tcpdump Log]

21:31:31.622576 IP 192.168.1.118.51441 > sync.oncecode.com.http: Flags [S], seq 3468888759, win 5360, options [mss 536,sackOK,TS val 40855676 ecr 0,nop,wscale 7], length 0

        0x0000:  4500 003c 537d 4000 4006 ee75 c0a8 0176  E..<S}@.@..u...v
        0x0010:  2a79 0c32 c8f1 0050 cec3 0ab7 0000 0000  *y.2...P........
        0x0020:  a002 14f0 f8f7 0000 0204 0218 0402 080a  ................
        0x0030:  026f 687c 0000 0000 0103 0307            .oh|........

21:31:31.690808 IP sync.oncecode.com.http > 192.168.1.118.51441: Flags [S.], seq 1535159088, ack 3468888760, win 5792, options [mss 1440,sackOK,TS val 971694021 ecr 40830368,nop,wscale 6], length 0

        0x0000:  4500 003c 0000 4000 3606 4bf3 2a79 0c32  E..<..@.6.K.*y.2
        0x0010:  c0a8 0176 0050 c8f1 5b80 ab30 cec3 0ab8  ...v.P..[..0....
        0x0020:  a012 16a0 6d6e 0000 0204 05a0 0402 080a  ....mn..........
        0x0030:  39ea dfc5 026f 05a0 0103 0306            9....o......
21:31:31.690826 IP 192.168.1.118.51441 > sync.oncecode.com.http: Flags [R], seq 3468888760, win 0, length 0

        0x0000:  4500 0028 0000 4000 4006 4207 c0a8 0176  E..(..@.@.B....v
        0x0010:  2a79 0c32 c8f1 0050 cec3 0ab8 0000 0000  *y.2...P........
        0x0020:  5004 0000 145a 0000

[append] firewall seems is shutdown, I checked it

olele@ubuntu:~$ sudo iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination


Chain FORWARD (policy ACCEPT)

target     prot opt source               destination


Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination
Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
tihuBird
  • 97
  • 1
  • 10
  • 1
    The `TSecr` in the `SYN+ACK` isn't the same as the `TSval` in the `SYN`. So at the very least it appears that the `SYN+ACK` isn't a reply to the `SYN` we're seeing in this packet capture. Were there any retransmits? Maybe the mismatch is accounted for by NAT that's going on somewhere, never had to poke around in such situations before. – MattH Nov 15 '12 at 17:06
  • MattH, You'r right ,client initiate send much retransmit sync packages because server no responds.After a while ,server respond the sync/ack ,then client send RST. I doubt the home router have some issue ,so reboot the router ,the issue still there . But it's very mysterious, TCP handshake success after reboot the ubuntu server in the client side. – tihuBird Nov 16 '12 at 00:27
  • MattH is right, The issue caused by the mismatch between TSecr:40830368(syc+ack) and TSval:40855676 (syc). Is that right TCP protocol stack will check the TSecr is valid during handshake? – tihuBird Nov 16 '12 at 00:48
  • Who can give some advice ,why issue is still there after reboot the router. But rebooted the client server, the issue is fixed. What's cause the slowly respond of Web Server. – tihuBird Nov 16 '12 at 01:00

1 Answers1

1

tihuBird, please correct me if I've misunderstood any of the following:

The packet capture show's the client's SYN with a Timestamp option value of 40855676 and the server's SYN+ACK reply contains a Timestamp Echo Reply of 40830368.

The first line of enquiry must be that the server has replied to a SYN other than the one in the packet capture.

Is that right TCP protocol stack will check the TSecr is valid during handshake?

Not entirely unreasonable: the echo reply has come back with a timestamp value in the past.

Who can give some advice ,why issue is still there after reboot the router. But rebooted the client server, the issue is fixed. What's cause the slowly respond of Web Server.

So you rebooted your router that is doing the NAT for the client(?) and the problem persisted. You rebooted the client and the problem was fixed?

I would have suggested that you run a packet capture on both the client and the internet-facing side of the router. Without this evidence, anything else is just speculation and you will have to wait until the problem recurs.

I suspect that the server may not be slow to respond and that there was a problem with the Network Interface Card / drivers on the client machine. Client + Router packet captures ought to be able to disprove this hypothesis.

Bear in mind that most modern network cards have a variety of performance-related TCP "offload" options, it could be that one of these was subtly broken and rebooting cleared this condition. Disabling off-load features (and letting the OS manage more of the TCP detail) may have also fixed the problem and would prove that the NIC was the cause.

Community
  • 1
  • 1
MattH
  • 37,273
  • 11
  • 82
  • 84
  • MattH, I cann't do tests according to your suggestions until problem recurs. If i got the result,i will continue to comment it. – tihuBird Nov 17 '12 at 00:25
  • 1
    This issue is recurred today. I have captured the TCP pacages both Client and Server Machine; – tihuBird Nov 23 '12 at 03:44