Wireshark BLE Sniffer missing packet, non-sequential event counter observed

[jasperwong]

I am using Wireshark with Nordic BLE Sniffer plugin. The sniffer dongle used is nRF52840. I using it to capture a BLE connection from my laptop BLE to a peripheral BLE device. 

I observe that the event counter of my BLE communication captured on Wireshark is not incrementing sequentially. I expect that "Event counter" after CONNECT_IND should be 0->1->2->3->..., but I observe that the "Event counter" after CONNECT_IND is 0->2->4->6->8->10->...

May I know why the "Event counter" is not sequentially incrementing? 

The screenshot below starts from Packet No. 4478.

nRF app success, VDD_BLE=2.6V, 100ohm shunt, peripheral_server_sleep_UART, adv_int=500ms, 20260106.pcapng

[Hung Bui]

Hi Jasper, 
Could you try to test on another computer ? 
From what I can see it could be that it's the issue with the Event counter counting , not the issue with the packets. If you look at the NESN and SN you can see that they are fine, no packet missing. For example here is what I have in my capture: 

You can add the delta time (start to start) column to see the distance between packets to see if the packet are actually missing. 

In my case, except for connection event 3 missing, the rest looks fine. The SN of a packet should be equal to the NESN of the last packet. 

I suspect that it could be something wrong with the counting of the event count when transmitting data from the sniffer to PC (event count is not a part of a BLE packet, when SN and NESN are) 

[jasperwong]

As suggested, I used another Windows 11 laptop to plug in the nRF52840 USB Dongle and capture a BLE transaction with Wireshark.

The delta time (start to start) shows the average to be 97ms when event counter is even, but at Packet No. 50699, the gap became 146ms, which is roughly 1.5 times that of 97ms. I think this suggests that packets are indeed lost/overlooked by the nRF52840 Sniffer. 

Assuming my understanding of packet lost is correct, why would the sniffer miss out on BLE packets so consistently (every other event counter)?

nRF app success, VDD_BLE=2.6V, 100ohm shunt, peripheral_server, adv_int=3000ms, 20260107.pcapng

[Hung Bui]

Hi Jasper, 
Could you let us know if programming the .hex file worked for you ? 
You need to flash it using nRF Connect for Desktop -> Programmer. 

[jasperwong]

Hi Hung,

The behaviour is quite strange.

I programmed the dongle with the hex you provided. 

For the first capture initially, I see sequentially incrementing event counter, which is correct. But later when I did more subsequent captures after saving the first file, the packets are skipped again judging by the event counter. I have attached both the first capture file and the subsequent capture file for your reference. 

I am unsure why the new hex file behaves this way. I cannot reproduce capturing the first file which has correct sequential event counter anymore. I kept seeing skipped event counter for all captures except the first one I did after flashing the hex file. 

Hung Bui sniffer firmware Wireshark log.zip

[Hung Bui]

Hi Jasper, 

Which DUT you are sniffing  ? Could you try to test with one of our DK (to advertise and get connected) . Which central device do you use ? Could you try to test with another phone if possible ? It could be that the phone has too strict timing causing the problem. 

 I don't have the same issue, the dongle worked for me most of the time (it's the opposite of what you experience, I only got the same even counter skipping once and then it didnt happen again , with the .zip file, quite strange). 

Regarding professional sniffer, most often used AFAIK are Ellisys and Frontline (Teledynelecroy) sniffers. 

[jasperwong]

I was sniffing the traffic between my phone nRF Connect app (Central) and Onsemi RSL10 (Peripheral). I don't have other Nordic DK on hand. Perhaps I can sniff other BLE devices such as wireless mouse or earphones. 

May I know what's the difference between the hex file you sent me and the official .zip file? Is there a changelog?

Also, is the Wireshark event counter incremented by the NRF BLE Sniffer or the Wireshark software? How is it kept track?

[Hung Bui]

Hi Jasper,
I don't have the detail on how the event counter implemented, but from what I can see I think it's just a counter used in the sniffer firmware and count based on the scheduling of the connection event. 
I don't think it's very important as what we are seeing here is the actual packet missing, not just event counter is skipped. So there is no issue with the event counter, it's simply we don't know why the sniffer couldn't capture all the packet and skip on packet in between.