This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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.