Using Wireshark To Hunt for HTTP Errors

One of the biggest advantages of using a network analysis tool with a reporting facility is the ability to aggregate and summarize specific characteristics to save you time and brain cells. For example, Wireshark has a lot of information you can reference or leverage when troubleshooting or baselining.

To demonstrate this, I'll show you how I recently resolved a problem a client was having trying to trace a webpage error. Using Wireshark, engineers at the customer site went to Statistics-> HTTP-> Packet Counters and did not see any errors even though they could obviously see an error clearly referenced on their screen. I explained that in this case, the word "error" needs to be properly explained.

Wireshark reports errors from a HTTP protocol perspective, but unfortunately their issue was that there was an actual webpage displayed with the error message. This can get a bit confusing, but as far as HTTP is concerned, the error page being returned is a valid page, therefore no error is reported.

The best analogy I can provide is when the mailman delivers you an overdue bill, he doesn’t know the details or situation, all he knows is that he delivered the mail.

I explained they need to dig deeper to find the error, and started with a protocol filter (HTTP).  After I found the packet with the error message, I leveraged a specific Display Filter to save time.

The client had originally suggested using the Find feature with the String/Bytes option. I agreed that would work, but it would be much easier if they could use a Display Filter so the only packets remaining on the screen are the offending packets.