This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Server sending RST Message

1

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.9       |                   
|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.9:59           |                   |HTTP: POST 192.168.1.9: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?

UPDATE 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

asked 30 Sep ‘13, 06:46

networker's gravatar image

networker
16113
accept rate: 0%

edited 30 Sep ‘13, 20:29


2 Answers:

1

Probably the server does not like the POST request. There is a clear difference

BAD - Client: 192.168.1.9

POST 192.168.1.2:59 |HTTP: POST 192.168.1.2:5901/ftcontentserver.rcs.mnc.mcc.pub.3gppnetwork.org HTTP/1.1

GOOD: - Client: 192.168.1.3

POST 192.168.1.9:59 |HTTP: POST 192.168.1.9:5901/ftcontentserver.rcs.mnc.mcc.pub.3gppnetwork.org HTTP/1.1

How comes, the POST request in the GOOD case contains the IP address of the client in the BAD case (192.168.1.9) and not the server (192.168.1.2)?

Is this intended or part of the problem?

++ UPDATE ++

O.K. with a little reformatting of the text, one can see that there are 3 SYN,ACK from the server to the client, but no ACK from the client. And then 'all of a sudden' the client sends a POST request, although the connection is not yet established from the servers point of view. As a result, the server sends a RST.

Why the client behaves like that, or if the packet got lost on the way is hard to tell.

Can you please add some details about your environment.

  • OS involved (client)
  • software involved (Browser)
  • where did you capture and how

Regards
Kurt

answered 30 Sep '13, 07:07

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 30 Sep '13, 10:17

@Kurt Knochner That is not the problem, The server was just running on a different IP when it ran correctly. I had restarted my system, so server took new IP.

(30 Sep '13, 08:39) networker
1

well, then it is impossible to compare those two capture files, especially as you just printed the summaries.

Please repeat your test with the same server IP address and then post both capture files somewhere.

I still believe the server does not like the POST request for some reason. Without a chance to look at the data, I cannot give any meaningful advice.

(30 Sep '13, 10:09) Kurt Knochner ♦

see the UPDATE in my answer.

(30 Sep '13, 10:15) Kurt Knochner ♦

@Kurt Knochner : OS of server is windows XP (coded in C), Client is android phone. The ere is a client application, which sends HTTP message to a HTTP server. I have taken logs of the Server through wireshark

(30 Sep '13, 10:20) networker

@Kurt Knochner : Client sends ACK through the POST Message( this I noticed when I expand the message in wireshark). But in the case it works, it is a distinct ACK as it can be seen

(30 Sep '13, 10:21) networker

OS of server is windows XP (coded in C), Client is android phone.

O.K. on the android phone, I guess you are simply using the browser or your own app. In both cases it will use a system call (possibly connect()) to open the TCP connection and then the OS will handle to TCP 3-way handshake, so there should be no reason for the behavior shown above, especially if another device works just fine with the same browser or the same app.

After the SYN the client does not react for 11 seconds and I believe it does not receive the SYN-ACK.

How is the android device connected to the 'server'? I assume a wireless connection and possibly you are having a problem with packet loss there.

Why the server sends a RST after the POST of the client, depends on how your C application is structured. As @SYN-bit mentioned, the capture files might help to dig a bit deeper into this.

(30 Sep '13, 14:22) Kurt Knochner ♦

@Kurt Knochner I have updated the question. I have shown the wireshark dump

(30 Sep '13, 20:30) networker

Can you please post a full capture file somewhere (google drive/docs, dropbox, cloudshark)? It's hard to look at text formatted output, especially if that output does not contain everything.

(01 Oct '13, 01:53) Kurt Knochner ♦
showing 5 of 8 show 3 more comments

0

AFAIK it is allowed to send data straight after the SYN, SYN/ACK, however, the sequence number need to be 1 higher than the initial sequence number in the SYN. Also the ACK needs to be one higher than the sequence number in the SYN/ACK. Can you confirm these values (or netter, post the two tracefiles on www.cloudshark.org for further inspection)?

answered 30 Sep '13, 13:23

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

@SYN-bit I have updated the question. I have shown the wireshark dump

(30 Sep '13, 20:30) networker