Occasionally I get given a packet capture showing a ‘slowness problem’ and am asked to fix it. There’s several things wrong with this approach.

Firstly, it’s not uncommon for a capture taken on a busy network to easily include over 500,000 packets. Given that a typical website such as YouTube makes 99 requests to load the homepage, this in itself creates a wealth of data.

Secondly, it’s easy to forget that you need particulars to search through a capture with. Information such as Source\Destination IP addresses, URL domains\hostnames and URI paths are required to sieve through the sheer amount of background noise that gets picked up also.

Finally – did the problem even occur at the time? It may seem obvious to state that a packet capture only captures packets while running, but this simple fact escapes many it would seem. A capture taken to troubleshoot a slow network, should have been taken at the time it was seen as slow.

So if you deal with network engineers and they ask you to provide a capture, take the opportunity to impress the hell out of them by providing complimentary information (I really wish Wireshark would put an optional meta data field onto a capture file!) such as the IP addresses and any domains involved.

It’s also worth pointing out that the OSI model still applies. Investigating a presentation\application problem within HTTPS will not tell you much when all Wireshark can do is show you a bunch of encrypted packets.

	Posted June 11, 2015
	Written by John Payne