The client had originally suggested using the Find feature with the String/Bytes option. After I found the packet with the error message, I leveraged a specific Display Filter to save time. I explained they need to dig deeper to find the error, and started with a protocol filter (HTTP). 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. 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. Wireshark reports errors from a HTTP protocol perspective, but unfortunately their issue was that there was an actual webpage displayed with the error message. I explained that in this case, the word 'error' needs to be properly explained. 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. To demonstrate this, I'll show you how I recently resolved a problem a client was having trying to trace a webpage error.

For example, Wireshark has a lot of information you can reference or leverage when troubleshooting or baselining.

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.

Use wireshark http