

On wired shared-medium networks, such as Ethernet, Token Ring, and FDDI, depending on the network structure ( hub or switch), it may be possible to capture all traffic on the network from a single machine.


However, the terms are frequently used interchangeably. Protocol analyzer can technically be a broader, more general class that includes packet analyzers/sniffers. While a packet analyzer can also be referred to as a network analyzer or protocol analyzer these terms can also have other meanings. As data streams flow across the network, the analyzer captures each packet and, if needed, decodes the packet's raw data, showing the values of various fields in the packet, and analyzes its content according to the appropriate RFC or other specifications.Ī packet analyzer used for intercepting traffic on wireless networks is known as a wireless analyzer or WiFi analyzer. Packet capture is the process of intercepting and logging traffic. You should add a column "Delta Time Displayed" to your setup (unless you already have it, of course) and track where the delays are for each TCP connection.Screenshot of Wireshark network protocol analyzerĪ packet analyzer, also known as packet sniffer, protocol analyzer, or network analyzer, is a computer program or computer hardware such as a packet capture appliance, that can intercept and log traffic that passes over a computer network or part of a network. To further investigate the non-anonymized packets I'd recommend you isolate the TCP conversations one by one (either via right click -> Conversation Filter -> TCP, or via Statistics -> Conversations -> right click). Also, seeing TCP Keep-Alive packets is an indicator one node is waiting for the other. From my gut feeling it looks more like a delay on that node than a network problem. It looks to me like the application processing time on 172.22.242.89 is really not that good (= performing well). It's a little hard to say without knowing exactly what is going, but what I find interesting is that if you look at the conversations that happen on TCP port 85 you can see that one side (172.29.77.183) is sending data that gets acknowledged (usually a 54 byte packet from 172.22.242.89), but then it takes at least 1 second to send the answer back each time (easy to find by looking for the TCP push flag, also from 172.22.242.89) - in case of the bad connection i've seen up to 19 seconds delay between the ACK and the PSH ACK.
