Wireshark: probably the most useful network tool...

Whoever works with networks agrees that Wireshark is probably the most useful tool to "have a look" on what is going on the network. Basically, Wireshark allows to capture all the traffic flowing through the network adapter, so that users can check frames, packets, conversations, timings, bandwidth, etc.

The huge list of network protocols supported by the software at all network levels (L1-L7) makes Wireshark a really powerful tool, both for newbies and experts.

It is necessary anyhow to configure capture filters: packets have to be analysed after the capture, so it's better to avoid picking up unnecessary traffic; the less the captured packets are, the quicker the analysis will be.

For example, if the aim is to troubleshoot an HTTP conversation between Host A and Host B, we can try to filter out the network traffic that would be useless and confusing; so we can:

• capture just the traffic that is sourced from A and directed to B (and back);
• capture TCP packets only, and ignore UDP (being the HTTP based on TCP);
• capture TCP packets coming from the TCP port 80.

Wireshark allows the configuration of specific capture filters; a detailed description of capture filters can be found here: PCAP-FILTER
Examples of capture filters are provided here instead: Capture Filters

Wireshark is really helpful to troubleshoot the communication between an IP-based unit (e.g. Ulisse Netcam, MPX HD, UC SD ...) and a Video Management System: when the connection attempts fail, and everything seems to be Ok from the configuration point of view, a closer look to the conversation can disclose many hidden details.

Being ONVIF based, IP units rely the communication on HTTP protocol; that is the important traffic to pick up therefore.
At the same time, it's better to keep in mind that we are dealing with video devices: a video stream means a huge amount of network traffic, which it's normally useless for the sake of communication troubleshooting unless we need to troubleshoot the video stream itself. Better to cut it out therefore...

For example, if our unit is at 192.168.0.100, the capture filter to configure on Wireshark is going to be:

host 192.168.0.100 and not udp

or

host 192.168.0.100 and tcp port 80

The host 192.168.0.100 filter will capture just the traffic from and to our unit, the not udp filter will exclude the RTP stream packets; alternatively, the tcp port 80 will pick up HTTP traffic only.

The steps to perform in order to provide us with a good traffic capture to analyse are:

• Delete/Disable the unit from the VMS;
• Restart the unit, and wait the boot procedure to be completed;
• Close all the web browsers connected to the unit, to pick up just the HTTP traffic between the VMS and the unit itself;
• Run Wireshark, configuring one of the capture filters above; change the IP address accordingly (of course), and be sure to capture from the right network interface;
• Configure/Enable the unit from the VMS, and wait for a couple of minutes in order to capture enough traffic;
• Stop Wireshark capture, and save the captured trace using the .pcap/.pcapng file format;
• Send the .pcap/.pcapng file over to us.

Hopefully the trace will contain something useful!

Last but not least important:

Never forget that modern networks are built on L2 switches.
You need to run Wireshark on the VMS Server machine, otherwise the trace will contain no useful traffic (just broadcasts).
Such requirement can be a limitation if the VMS server can not be easily accessed for security restrictions, or whether the VMS is instead... a NVR (no chance to add software on those).
These situations can be overcome using a switch provided with a Monitor (or Mirror) port, where to connect the PC that runs Wireshark.
A Monitor is a port where the switch replicates all the incoming traffic to, allowing Wireshark to capture the conversation between the VMS/NVR and the unit.
Please check for such possibility with your network administrator.