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. 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. Wenn Sie nur HTTP-POST- oder GET-Nachrichten filtern möchten, können Sie basierend auf Ihren Kommentaren den folgenden Filter verwenden: Sie können auf IP - Adresse und Port - Filter mit ip.addr192.168.0.201 and tcp.port8080 nur Pakete an anzuzeigen TCP - Port 8080. 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 kommentar(er)
