Issues on capturing BLE packets on Wireshark

RE: Issues on capturing BLE packets on Wireshark

Kenneth — Tue, 04 Jul 2023 14:56:02 GMT

In any case, this is slighly out of the scope or our support. But as far as I know the sniffer should display all packets it receives.

Kenneth

RE: Issues on capturing BLE packets on Wireshark

andreribeiro423 — Tue, 04 Jul 2023 14:49:34 GMT

I added the config "CONFIG_BT_GATT_CACHING=n" in nRF prj.conf but it didn't solve the Wireshark issue. The Heart Rate, Temperature and Battery Level Measurement packets still do not appear. In the Bluetooth ATT Server Attributes the following appears:

Where the UUID "0xa009" corresponds to my custom GATT server. The discover don't recognize the characteristics and descriptors of the service.

RE: Issues on capturing BLE packets on Wireshark

Kenneth — Tue, 04 Jul 2023 14:15:08 GMT

Hi, it may be that the raspberry pi is smart and use GATT caching, then it will read the hash of peer database without performing a discovery to find if it's changed or not since last connection, unfortunately the Wireshark is not smart enough to know that it should use previous nrf sniffer connections to know what the current database may be. You can disable this functionality by:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/kconfig/index.html#CONFIG_BT_GATT_CACHING

Kenneth

RE: Issues on capturing BLE packets on Wireshark

andreribeiro423 — Tue, 04 Jul 2023 13:35:19 GMT

I've done several logs and this problem occurs on almost all of them. Only two or three times this problem did not happen. In these situations I commented and uncommented the following config in nRF prj.conf: "CONFIG_BT_DIS=y". I don't need this service but I don't understand what this could be influencing, because commenting and uncommenting that line ends up working correctly in Wireshark. Maybe it's just coincidence I don't know. The issue is that it only works once. I run it again and it no longer works as intended in Wireshark.

I also noticed that in Wireshark's "Bluetooth ATT Server Attributes", when it doesn't work, only the "Database Hash" appears. When it works correctly, in these situations it already presents the entire GATT server. I leave images below that prove this evidence.

With this I'm confused if the issue is on the nRF or the Raspberry Pi side. I think that the problem will be on the side of the Raspberry Pi because this problem only occurs when communicating with the Raspberry, because with the smartphone or another nRF there is no problem. But since this variation in nRF's prj.conf is probably affecting something, I have doubts.

RE: Issues on capturing BLE packets on Wireshark

Kenneth — Tue, 04 Jul 2023 08:27:29 GMT

[quote user=""]However my issue occurs in Wireshark. Here, only notifications for 4 of the 7 GATT server characteristics are presented. Characteristics that correspond to known Bluetooth services do not appear (Heart Rate, Temperature and Battery Level Measurement).[/quote]

I have not seen this myself, but it could be some sort of issue in a recent wireshark release. So you can try to use an older release as listed in the minimum requirements for nRF sniffer for BLE to check if that helps:
https://infocenter.nordicsemi.com/topic/ug_sniffer_ble/UG/sniffer_ble/min_requirements.html

Alternatively you can try to make a few logs and check if you see the same every time, it could for instance be that you were unlucky with the sniffer and experienced some packet loss that caused the sniffer to miss some of the packets on-air during the GATT database discovery.

[quote user=""]In addition, in the notifications presented in Wireshark, the UUID's of any of the characteristics are not displayed. Below I leave an image of Wireshark.[/quote]

The UUID is not part of the packets, but wireshark does a lookup based on the handle to find what UUID it refer to and display it for convenience, so if some of the previous packets were lost this will not work.

Kenneth