CODEWITHSUNDEEP
c++socketsnetwork-programming
jsilva
jsilva

Reputation: 111

networking weird behavior

I have a little app (c++), who connect (winsock connect / send) to the server and send a packet(28 bytes) to check if there is an update available.

The app works great, i try it from different countrys without a problem, but i have some problem with asian countrys.

The server is in USA, the test client is in thailand.

The problem is, the client connect ok (i can see the connection on the server), send the packet (i can see the packet delivered on client wireshark), but never arrive to the server.

this capture is from the server, and is what arrive, nothing more.

13:37:15.103682 IP asianet.co.th.52739 > transip.net.http: Flags [S], seq 3221849952, win 8190, options [mss 1460,nop,wscale 3,nop,nop,sackOK], length 0
13:37:15.103764 IP transip.net.http > asianet.co.th.52739: Flags [R.], seq 0, ack 3221849953, win 0, length 0
13:37:18.039495 IP asianet.co.th.46755 > transip.net.http: Flags [S], seq 3299550171, win 8190, options [mss 1460,nop,wscale 3,nop,nop,sackOK], length 0

and this is the capture on the client

No.     Time        Source                Destination           Protocol Length Info
      1 0.000000    asianet.co.th         transip.net         TCP      62     vtr-emulator > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1

Frame 1: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Dell_1e:1c:72 (78:2b:cb:1e:1c:72), Dst: Cisco_2c:17:c8 (00:21:1c:2c:17:c8)
Internet Protocol Version 4, Src: asianet.co.th (asianet.co.th), Dst: transip.net (transip.net)
Transmission Control Protocol, Src Port: vtr-emulator (3122), Dst Port: http (80), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Length Info
      2 0.291298    transip.net         asianet.co.th         TCP      62     http > vtr-emulator [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460 SACK_PERM=1

Frame 2: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Cisco_2c:17:c8 (00:21:1c:2c:17:c8), Dst: Dell_1e:1c:72 (78:2b:cb:1e:1c:72)
Internet Protocol Version 4, Src: transip.net (transip.net), Dst: asianet.co.th (asianet.co.th)
Transmission Control Protocol, Src Port: http (80), Dst Port: vtr-emulator (3122), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
      3 0.291316    asianet.co.th         transip.net         TCP      54     vtr-emulator > http [ACK] Seq=1 Ack=1 Win=65535 Len=0

Frame 3: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Dell_1e:1c:72 (78:2b:cb:1e:1c:72), Dst: Cisco_2c:17:c8 (00:21:1c:2c:17:c8)
Internet Protocol Version 4, Src: asianet.co.th (asianet.co.th), Dst: transip.net (transip.net)
Transmission Control Protocol, Src Port: vtr-emulator (3122), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
      4 1.276972    asianet.co.th         transip.net         HTTP     82     Continuation or non-HTTP traffic

Frame 4: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Ethernet II, Src: Dell_1e:1c:72 (78:2b:cb:1e:1c:72), Dst: Cisco_2c:17:c8 (00:21:1c:2c:17:c8)
Internet Protocol Version 4, Src: asianet.co.th (asianet.co.th), Dst: transip.net (transip.net)
Transmission Control Protocol, Src Port: vtr-emulator (3122), Dst Port: http (80), Seq: 1, Ack: 1, Len: 28
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Length Info
      5 1.278358    transip.net         asianet.co.th         TCP      60     http > vtr-emulator [ACK] Seq=1 Ack=29 Win=27712 Len=0

Frame 5: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: Cisco_2c:17:c8 (00:21:1c:2c:17:c8), Dst: Dell_1e:1c:72 (78:2b:cb:1e:1c:72)
Internet Protocol Version 4, Src: transip.net (transip.net), Dst: asianet.co.th (asianet.co.th)
Transmission Control Protocol, Src Port: http (80), Dst Port: vtr-emulator (3122), Seq: 1, Ack: 29, Len: 0

No.     Time        Source                Destination           Protocol Length Info
      6 1.289416    asianet.co.th         transip.net         TCP      54     vtr-emulator > http [RST, ACK] Seq=29 Ack=1 Win=0 Len=0

Frame 6: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Dell_1e:1c:72 (78:2b:cb:1e:1c:72), Dst: Cisco_2c:17:c8 (00:21:1c:2c:17:c8)
Internet Protocol Version 4, Src: asianet.co.th (asianet.co.th), Dst: transip.net (transip.net)
Transmission Control Protocol, Src Port: vtr-emulator (3122), Dst Port: http (80), Seq: 29, Ack: 1, Len: 0

NOTE: if you see "http" on any place, it's just because the server works on port 80.

NOTE2: Frame 4 on client capture is my packet.

I know that could be complicated find out what is the problem, but maybe someone could give me a clue.

thanks.-

Upvotes: 2

Views: 144

Answers (2)

phonetagger
phonetagger

Reputation: 7883

What sort of connection are you making between the server & client? TCP/IP? I'm not familiar with Wireshark, but it seems like frame 4 is being classified as "Hypertext Transfer Protocol". I know your post says "Note: if you see 'http' on any place, it's just because the server works on port 80.", but would Wireshark really report it as "Hypertext Transfer Protocol" merely because it's on port 80? Maybe there are other un-blocked ports you could try & see if you get the same results? (And is either end possibly behind a NAT-enabled router that's redirecting some packets to another host?)

Upvotes: 0

Nikolai Fetissov
Nikolai Fetissov

Reputation: 84239

Your server side capture shows that the server sends RESET back to the client, i.e. refusing connection.

The client-side capture, on the other hand, shows completed three-way TCP handshake. This can be explained by the firewall/router in front of your server trying to prevent SYN-flood attacks by masquerading as the target TCP destination, completing the handshake, and only then replaying it to the listening server behind it. Also TCP sequence numbers are usually re-mapped in this defensive scenario. You then see that RST later in the client capture.

The fact that source port numbers for the client don't match between two captures (assuming that's the same conversation) also point into direction of something in the middle.

Check that your DNS is correct. Check what intermediate devices (firewalls, switches, routers) are in the path and what they are doing. Make sure you server software is actually listening on that port 80.

Upvotes: 2

Related Questions