Technical Support is available at:
8.30-12.30; 13.30-17.30 (CET), Mon-Fri
t: +39.0445.697420 (direct)
e: support[at] (ticket)

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, the capture filter to configure on Wireshark is going to be:

host and not udp


host and tcp port 80

The host 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.

Was this article helpful?
1 out of 1 found this helpful
, Daniele Bottini wrote this article.
Have more questions? Submit a request


  • Avatar
    Daniele Bottini

    Not sure if your NTP is synchronizing the Ulisses?
    Actually you can use Wireshark to check whether a NTP service is available on the network, and if the NTP server is able to provide a suitable time reference.

    If your are using a PC-based NTP service (e.g. Windows Time Service or Linux NTP Server), it's really simple: install Wireshark over that PC, and run the capture using the following filter:

    host <PC Address> and host <Ulisse Address> and upd port 123

    NTP requests should come from the Ulisse when restarted, and the NTP server should answer with a packet containing a valid time reference (check the NTP flags inside the packet).

    If you are using an NTP-capable appliance (e.g. a router), it could be trickier: either check the NTP logs on the appliance itself (if any), or again use Wireshark with the same filter, connecting the PC to a monitor port as explained above.

    Edited by Daniele Bottini
  • Avatar
    Daniele Bottini

    Another useful capture filter, to pick up just traffic FROM and TO Videotec units, filtering at Layer2 (for example, if you need to discover which IP address the unit working with):

    Ulisse Netcam, Ulisse Radical, Ulisse 2:

    (ether[0:4] & 0xFFFFFF00 = 0x0021A600) or (ether[6:4] & 0xFFFFFF00 = 0x0021A600)

    Ulisse Compact HD/SD, MPX HD/SD, NXPTZ HD/SD, MVX:

    (ether[0:4] & 0xFFFFFF00 = 0x001C6300) or (ether[6:4] & 0xFFFFFF00 = 0x001C6300)
    Edited by Daniele Bottini