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

intermittent disconnection

0

can somebody please explain the below packet capture output.I am not good with packet captures.

Client:192.168.1.3
Server:121.11.12.241
This Packet capture has been taken from client end.

625: 16:29:35.800892 802.1Q vlan#412 P0 192.168.1.3.62597 > 121.11.12.241.443: S 3810026419:3810026419(0) win 8192 < mss 1460,nop,wscale 8,nop,nop,sackOK>  
626: 16:29:35.816730 802.1Q vlan#412 P0 121.11.12.241.443 > 192.168.1.3.62597: S 2188766603:2188766603(0) ack 3810026420 win 4140 < mss 1380,sackOK,eol> 
627: 16:29:35.817386 802.1Q vlan#412 P0 192.168.1.3.62597 > 121.11.12.241.443: . ack 2188766604 win 64860 
628: 16:29:35.819354 802.1Q vlan#412 P0 192.168.1.3.62597 > 121.11.12.241.443: R 3810026420:3810026420(0) ack 2188766604 win 0

Thanks in advance

asked 07 Nov '16, 08:50

Jith1010's gravatar image

Jith1010
6●1●1●4
accept rate: 0%

edited 07 Nov '16, 09:45

sindy's gravatar image

sindy
6.0k●4●8●51

One Answer:

1

tcpdump's way of displaying TCP is, well, compact. Wireshark is aimed to render you the same information in much more user-friendly form, so if you cannot install Wireshark on the platform where you've taken that capture, just run tcpdump the same way you did but add -s 0 -w some/file/name to its command line parameters. Then, copy some/file/name to a machine on which you can run Wireshark and open it there.

In your case:

625 - the client sends a SYN packet, indicating that it supports window scaling and sack, and the MSS value

626 - the server responds with a SYN,ACK packet, indicating that it does not support window scaling by not placing the wscale option to that packet, the MSS value, and making the option list shorter by using an EOL option.

627 - the client confirms reception of the server's SYN,ACK packet by sending its own ACK

628 - the client terminates the session in emergency mode by sending a RST packet, possibly because it didn't like that the server doesn't support window scaling, or because it didn't like something else about the server's response.

The actual reason can not be found using tcpdump or Wireshark. Network analyzers tell you what has happened, but very rarely the protocols carry detailed information about why it has happened.

answered 07 Nov '16, 13:55

sindy's gravatar image

sindy
6.0k●4●8●51
accept rate: 24%

edited 07 Nov '16, 13:56

So in your opinion which side has more chance to have the issue ,client side or server side?

(07 Nov '16, 22:40) Jith1010

The initiative to terminate connection was client's.

As the client tears down the session at such an early stage, you may try to connect to other two https servers, one which does support window size scaling and another one which doesn't. If the client doesn't reset the connection to the first one at the same stage as in this capture and does reset at the same stage the connection to the second one, it is very likely that it doesn't like this particular feature (or the absence of it).

(08 Nov '16, 00:51) sindy