Using Wireshark to troubleshoot Cobranet network latency
So I’m working on a project to deploy IP-Public Announcement systems. The hardware were deployed but things didn’t go as planned. They have a lot of static noise when making announcements.
The hardware company did the troubleshooting and said it’s “most likely” because of the network, specifically because their hardware didn’t receive enough “Beat packets”. Based on that finding, they concluded that until we “improve” the network , the project had to stop.
A quick search on the Internet got me a few info on Cobranet beat packets
- Beat packets are broadcast packets
- They are sent 750 times per seconds (Or 0.001333ms per packets)
- The acceptable range is from 0.000833ms to 0.001833ms
Let’s use Wireshark to see if the network is capable of delivering this?
First, I put Wireshark on a port and captured everything for 25 minutes. This would capture everything coming in and out of the port, Spanning Tree, CDP, SMB….
For many reasons, I needed a pcapng file that contains only things that I want to see, which were beat packets in this case. To do this, I used a LUA module, written by Eliot Blennerhassett, AudioScience Inc to filter out the beat packets. (More info here . Finally I saved the result to a new file.
I then re-opened the new file. This time Wireshark ran much faster.
Let’s look at the I/O Stats, to do this , go to
Statistics\ IO Graphs
As you can see from the Graphs, the network had no problem delivered 750 packets per seconds. To provide more details, we can look closely to see how many packets fall out of range (0.000833ms to 0.001833ms)
To do this, I used the following filter
(frame.time_delta >= 0.001833) or (frame.time_delta <= 0.000833)
Looks like we have 93 packets that were out of range, 0.02%. I don’t think this is an issue.
Update1: Turned out that when I captured the server, the server also had 0.02% delayed beat packets. It means the network doesn’t delay the packets, just the server doesn’t send them fast enough.
Update2: 2 weeks after I showed this result, the Vendor admitted that the issue wasn’t the network.