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

Viewing connection issues with Wireshark

0

Hi all, I have tried to use WireShark to view traffic on certain connections to help identify why connections seemingly randomly reset. The issue seems to be, that if a connection becomes idle, no data is sent or received for some time (for example sitting idle on an irc server and only ping/ponging) the connection "dies" and the client will disconnect the next time it tries to write to the connection. In order to check this, I looked at traffic on http, irc and also for the online game WoW.

In the trace, WireShark frequently informs me that packets were sent out-of-order, previous tcp segments were not captured and packets marked with TCP retransmission. There is not enough traffic on the nic or lack of processing power for wireshark to warrant not capturing previous segments so often. Does this indicate a connection problem? If so, does this indicate a problem with my hardware?

Edit: IRC Bnetgame. My HTTP capture had many, many more marked packets however it likely contains personal information and is very large. The spikes in bnetgame correspond to when the client informed me I was disconnected and reconnected. The IRC capture shows me connecting, joining and then having my connection disconnected several times.

asked 30 May '13, 08:39

Joshx00's gravatar image

Joshx00
015
accept rate: 0%

edited 30 May '13, 09:59


One Answer:

1

It depends on your capture setup whether the symptoms you're describing are really part of a problem with your connection or hardware, or just a flawed way of recording packets. For example you might loose packets on a switch SPAN session, or writing to disk is too slow to write all captured packets to disk in time.

You should try to find out if you have drops (shown in the status bar right after stopping the capture). If there are none, your capturing machine was fast enough to write all captured packets to disk. Next thing is to find out if there are really retransmissions or just duplicate packets in the trace. Also, you will have to determine if the combination of "previous segment not captured, Out-of-Order, retransmission" isn't just an out-of-order cluster of packets. To do that you need to understand how retransmission works in regard to round trip time - could the sender have known that the packet is lost when it was sent or not? If the retransmissions comes in too fast it is probably just normal Out-of-Order behavior.

Maybe you can post a sample capture at http://www.cloudshark.org so we can take a look (only if it does not contain sensitive information).

answered 30 May '13, 08:52

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Since Akismet believes my comment is spam here, I have edited my question.

(30 May '13, 09:59) Joshx00
1

You've got bidirectional packet loss, so it looks like your connection to the internet is loosing packets both ways. In the IRC case it also leads to a RESET termination due to the fact that the other node doesn't reply anymore (Stream Index 0) and your local PC gives up in packet 88.

This may be caused by some other PC/node in your network performing massive downloads which clog the line.

(30 May '13, 12:17) Jasper ♦♦

Hi, no packet loss shows up in ping tests to these servers. Would there be a reason for this? Also, if I spam the connection with requests (such as ping/ponging every 3 seconds) it is stable. Is this because there are more replies to indicate the server is still alive?

(30 May '13, 14:18) Joshx00
1

Ping tests are not really accurate since the packet frequency is quite low (usually with 1 second delay) and they're pretty small (usually 64 byte), so they have a high chance of getting through. Packet loss usually happens with high packet volume (meaning: delta times between packets in the millisecond or microsecond range) and with larger payload.

(31 May '13, 02:42) Jasper ♦♦