user1692342
Reputation: 5237
Server sending RST Message
I am developing a server, and client messages are sent through a handset. Server and handset are connected through Wifi.
Client sends a HTTP Post message to server, and server is supposed to reply with a 200 ok. It works in most systems, but in some systems, after the server receives the POST Message, it replies with a TCP RST.
Server IP is: 192.168.1.2 and Client IP is : 192.168.1.9. This is the flow when it does not work.
|Time | 192.168.1.9 |
| | | 192.168.1.2 |
|103.313276| 49988 > 5901 [SYN] |TCP: 49988 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=306973 TSecr=0 WS=64
| |(49988) ------------------> (5901) |
|103.313469| 5901 > 49988 [SYN, |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
| |(49988) <------------------ (5901) |
|106.281619| 5901 > 49988 [SYN, |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
| |(49988) <------------------ (5901) |
|112.316765| 5901 > 49988 [SYN, |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
| |(49988) <------------------ (5901) |
|124.381196| POST 192.168.1.2:59 |HTTP: POST 192.168.1.2:5901/ftcontentserver.rcs.mnc.mcc.pub.3gppnetwork.org HTTP/1.1
| |(49988) ------------------> (5901) |
|124.381300| 5901 > 49988 [RST] |TCP: 5901 > 49988 [RST] Seq=1 Win=0 Len=0
| |(49988) <------------------ (5901) |
This is the case where it works:
|Time | 192.168.1.3 | 192.168.1.2 |
| | | 192.168.1.2 |
|117.828732| 42956 > 5901 [SYN] | |TCP: 42956 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=2994458 TSecr=0 WS=64
| |(42956) ------------------> (5901) | |
|117.828828| 5901 > 42956 [SYN, | |TCP: 5901 > 42956 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
| |(42956) <------------------ (5901) | |
|117.930471| 42956 > 5901 [ACK] | |TCP: 42956 > 5901 [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSval=2994490 TSecr=0
| |(42956) ------------------> (5901) | |
|117.930932| [TCP Window Update] | |TCP: [TCP Window Update] 5901 > 42956 [ACK] Seq=1 Ack=1 Win=262800 Len=0 TSval=75822 TSecr=2994490
| |(42956) <------------------ (5901) | |
|117.941444| POST 192.168.1.2:59 | |HTTP: POST 192.168.1.2:5901/ftcontentserver.rcs.mnc.mcc.pub.3gppnetwork.org HTTP/1.1
| |(42956) ------------------> (5901) | |
|117.964006| HTTP/1.1 204 No Con | |HTTP: HTTP/1.1 204 No Content
| |(42956) <------------------ (5901) | |
This is the error I get in the first case: Expert Info (Warn/Protocol): Acknowledgment number: Broken TCP. The acknowledge field is nonzero while the ACK flag is not set
Can someone suggest what could be possibly going wrong?
Here is the wireshark dump
No. Time Source Destination Protocol Length Info
1 0.000000 192.168.1.9 192.168.1.2 TCP 74 49988 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=306973 TSecr=0 WS=64
Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: Lge_4c:96:28 (5c:17:d3:4c:96:28), Dst: IntelCor_d4:8d:40 (00:23:14:d4:8d:40)
Internet Protocol Version 4, Src: 192.168.1.9 (192.168.1.9), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: 49988 (49988), Dst Port: 5901 (5901), Seq: 0, Len: 0
No. Time Source Destination Protocol Length Info
2 0.000193 192.168.1.2 192.168.1.9 TCP 78 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
Frame 2: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Ethernet II, Src: IntelCor_d4:8d:40 (00:23:14:d4:8d:40), Dst: Lge_4c:96:28 (5c:17:d3:4c:96:28)
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.9 (192.168.1.9)
Transmission Control Protocol, Src Port: 5901 (5901), Dst Port: 49988 (49988), Seq: 0, Ack: 1, Len: 0
No. Time Source Destination Protocol Length Info
3 2.968343 192.168.1.2 192.168.1.9 TCP 78 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
Frame 3: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Ethernet II, Src: IntelCor_d4:8d:40 (00:23:14:d4:8d:40), Dst: Lge_4c:96:28 (5c:17:d3:4c:96:28)
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.9 (192.168.1.9)
Transmission Control Protocol, Src Port: 5901 (5901), Dst Port: 49988 (49988), Seq: 0, Ack: 1, Len: 0
No. Time Source Destination Protocol Length Info
4 9.003489 192.168.1.2 192.168.1.9 TCP 78 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=8 TSval=0 TSecr=0 SACK_PERM=1
Frame 4: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Ethernet II, Src: IntelCor_d4:8d:40 (00:23:14:d4:8d:40), Dst: Lge_4c:96:28 (5c:17:d3:4c:96:28)
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.9 (192.168.1.9)
Transmission Control Protocol, Src Port: 5901 (5901), Dst Port: 49988 (49988), Seq: 0, Ack: 1, Len: 0
No. Time Source Destination Protocol Length Info
5 21.067920 192.168.1.9 192.168.1.2 HTTP 148 POST 192.168.1.2:5901/ftcontentserver.rcs.mnc.mcc.pub.3gppnetwork.org HTTP/1.1
Frame 5: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits)
Ethernet II, Src: Lge_4c:96:28 (5c:17:d3:4c:96:28), Dst: IntelCor_d4:8d:40 (00:23:14:d4:8d:40)
Internet Protocol Version 4, Src: 192.168.1.9 (192.168.1.9), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: 49988 (49988), Dst Port: 5901 (5901), Seq: 1, Ack: 1, Len: 82
Hypertext Transfer Protocol
No. Time Source Destination Protocol Length Info
6 21.068024 192.168.1.2 192.168.1.9 TCP 54 5901 > 49988 [RST] Seq=1 Win=0 Len=0
Frame 6: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: IntelCor_d4:8d:40 (00:23:14:d4:8d:40), Dst: Lge_4c:96:28 (5c:17:d3:4c:96:28)
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.9 (192.168.1.9)
Transmission Control Protocol, Src Port: 5901 (5901), Dst Port: 49988 (49988), Seq: 1, Len: 0
Upvotes: 1
Views: 4138
Answers (1)
Manoj Pandey
Reputation: 4666
For the case, where it is not working, the TCP handshake is not getting completed. The reason for this is the local side is not sending an ACK to the received SYN/ACK. For better readability, I am providing a short/edited variant of the 3-way hand shake:
49988 > 5901 [SYN] |TCP: 49988 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460
5901 > 49988 [SYN, |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
5901 > 49988 [SYN, |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
5901 > 49988 [SYN, |TCP: 5901 > 49988 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
For the case, where it fails, the 3-way handshake is complete:
42956 > 5901 [SYN] ||TCP: 42956 > 5901 [SYN] Seq=0 Win=14600 Len=0 MSS=1460
5901 > 42956 [SYN, ||TCP: 5901 > 42956 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
42956 > 5901 [ACK] ||TCP: 42956 > 5901 [ACK] Seq=1 Ack=1 Win=14656 Len=0
Now, the why part.. Once the connect() is issued, it is the underlying TCP that would send SYN and respond to the SYN-ACK, so I am seeing any bad thing here except that the local stack is taking more time to respond to the SYN-ACK. Also, is the client waiting enough for the connect() to succeed before it sends the request. If connect() does not go through or gets delayed, then it should not send any data on that connection.
Upvotes: 1
Related Questions
- TCP retransmission on RST - Different socket behaviour on Windows and Linux?
- Broadcasting message from server
- TCP RST packet details
- TCP Communication: Send Response
- Client Hello TCP Retransmission from wireshark
- C# TCP Client to Server messages
- How to prevent Windows from sending RST packet when trying to connect to somebody via Pcap.net?
- C# Receiving Packet in System.Sockets
- How to send a simple message from WinRT Client( .NET 4.5) to Desktop Server(.NET 4.0) using Sockets?
- TCP Sockets Server Windows Application