Wireshark with nRF BLE Sniffer often does not display the data packets when establishing a BLE connection

[Tim83]

I am using Wireshark 4.4.0 and Nordic nRF Sniffer for Bluetooth LE 4.1.1 (nRF52840-Dongle PCA10059). In Wireshark I see a device, a peripheral, sending advertising packets, and when I connect to the peripheral with my phone using the nRF app, the packets related to the connection often do not appear in Wireshark. Sometimes they do, sometimes they don’t. see the attached Image as an Example where everything works fine.

It seems as if Wireshark sometimes fails to switch from the advertising channels 37, 38, 39 to the connection channels.

Does anyone know how to make Wireshark more reliable?

I have already reinstalled Wireshark. I have also tried removing all filters, which results in a lot of traffic, but you should still be able to see the connection packets if they were there. So that didn’t help either.
And i also tried to reinstall nrfutils and reflash the Dongle with hardware flowcontrol.

[Menon]

Hello,

Have you followed all the steps mentioned in setting up the nRF BLE sniffer? As a reference, you can go through this chapter to ensure everything is set up correctly. Regarding the image you shared, it’s too small, and when I tried to zoom in, the image became blurry as it is not of high quality. Could you please try sharing a clearer image that shows the issue properly?

Kind regards,
Abhijith

[Tim83]

Yes, I followed these instructions:

• Segger is installed
• The hex file was flashed onto the dongle
• The Extcap folder for Wireshark was created and the corresponding files were copied into it
• requirements.txt was installed with Python 3

Additionally, I have also tried the older or alternative method using nfrutils, but it has the same problem.
The original image is large enough: 1538x664, but whenever I copy it here via drag and drop, it seems to get smaller.
Another Try:

[Menon]

Hello,

Apologies for the delayed response. I was unwell over the weekend and just resumed work today, which caused the delay. I’m sorry if this caused any inconvenience.

Is this happening with all BLE devices? I’m not sure, but there is a chance that the issue could be due to inconsistencies in the connection procedure between your phone and the peripheral device. Could you please check with a different phone or BLE peripheral to see if the issue persists?

In the image, I see a CONNECT_IND packet at timestamp 10.259491, which signals the beginning of a connection. Ideally, the sniffer should switch from advertising channels to data channels at this point. However, the following packets show "Empty PDU," indicating that the sniffer didn't successfully follow the connection.

Kind regards,
Abhijith

[Tim83]

I have tested various other devices, see the table below.
There are 2 different Samsung mobile phones and an Apple phone, sometimes used as Central and sometimes as Peripheral. Atmosic is a Bluetooth chip, it can only be used as Peripheral.
I have two of them, hence Atmosic1 and Atmosic2.
I worked with the Nrf-Connect app.
In the app, you can click on Connect, then the connection is established, and at the same time, I used Wireshark to capture the data.
To connect the two mobiles, I set the one used as Peripheral in Nrf-Connect as an Advertiser.

I don’t know if it’s important, but on the Apple device, you could only set the advertising interval to 30ms.
On Samsung, the minimum was 100ms or more.
The Atmosics have an advertising interval of 1280ms.

You can see in the table that only the connection with Samsung as Central and Apple as Peripheral worked reliably. Strange.

You can see the ‘Empty PDU’ packets repeatedly, see the attached Picture, I always explained this to myself as the keep-alive signals, similar to a heartbeat function.

Central	Peripheral	Result
Samsung mobile1	Atmosic1	same problem as described above
Samsung mobile2	Atmosic2	same problem as described above
Apple mobile	Atmosic1	same problem as described above
Apple mobile	Samsung mobile1	same problem as described above
Samsung mobile1	Apple mobile	Works fine

Here is also the excerpt for Samsung mobile1 as Central and Apple mobile as Peripheral:

Best regards
Tim

[Tim83]

Hello,
I think I have figured out how to improve it.
I instructed the Atmosic chip to use only Channel 37 and also set Wireshark to scan only Channel 37.
(You just need to make sure to set Channel 37 in Wireshark first and then the device address, otherwise it always crashes for me.)
It seems that by separately scanning Channels 37, 38, and 39, the important packet is occasionally missed, so the nrf-Dongle does not see the connection.

However, it is strange how it works with other devices. I am fortunate to be able to instruct the Atmosic chip to advertise only on Channel 37.
How do you handle Peripherals that do not allow this?
Why does no one else encounter this problem?

Best regards
Tim