![]() ![]() 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. 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. But if it is not possible to do that in realtime, I can capture the traffic to the file and apply some filter to get the HTTP headers. ![]() I explained they need to dig deeper to find the error, and started with a protocol filter (HTTP). My first option is showing the HTTP header while the client is accessing the web server. 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. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |