Sometimes there are errors and problems on a network that need in depth analysis. Troubleshooting some issues can be almost impossible without using a tool to investigate deeper such as a packet sniffer. Often you won’t be able to find that issue with a non-responsive share or the reason that your RAS server is so slow is because all your travelling sales people are using it to watch BBC TV abroad when they’re travelling!
If a certain error condition occurs only when the request is coming from an actual client, but not when using telnet, packet snifﬁng is in order.
Sometimes, using telnet may be complex, because the proxy and origin servers may require authentication credentials to be sent. In those
cases, it is more convenient to use a real Web client that can easily construct those headers. Also, if a problem exhibits itself with a certain client,
but not with others, it is worthwhile to ﬁnd out exactly what is being sent by the client.
There are a number of packet sniffers. Depending on the operating
system, you may ﬁnd some of these useful.
Many books and instructions will pick a specific packet sniffer to use so if you’re following a guide use this. One of the most popular is Wireshark which is a fully functional and free packet sniffer often used by professionals instead of more costly commercial options.
Many of the most comprehensive are actually distributed as part of Unix and Linux distributions and you’ll have to refer to the UNIX man pages for instructions for the others.
Example. Let’s say you want to snoop the trafﬁc between the hosts fred’s PC (client) and socrates (server). You can use something like Wireshark to track the traffic between the two endpoints and analyse what’s happening between them.
Of course, this only is useful if you can initially identify which sources to monitor. If you suspect that Fred is using the company proxy for Netflix then you can prove the point easily using a packet sniffer. If you’re not sure then you may have to look first to the network hardware for clues, checking switches and hubs for span ports and plugging into them is a useful tactic. These ports typically mirror all the traffic being carried over the active ports meaning you can use the span port to track all the data on that device.
The ability to specify a port is essential and all decent packet sniffers will allow this. Also you should be able to use switch options to control how the traffic should be dumped. That is to specify exactly what format the traffic should be returned in, this is useful as it helps in the analysis stage. Any packet sniffer which doesn’t do this will make the next stages much harder as the amount of data produced will often be very large.