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,

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