nRF Sniffer unable to track packet data length changes

[Magoo]

Hi,

I am trying to test an application running on the nRF52840 using your nRF Sniffer (actual version 2.0.0.2.beta).

My application should be able to request a change of the Bluetooth packet data length (DLE feature available since BLE 4.2) and it does so by calling the function nrf_ble_gatt_data_length_set .
It seems that this works. I use a packet data length of 71 bytes and ATT_MTU = 67 bytes and data are received correctly by the peer.

However I have a problem with the nRF Sniffer:

After changing the packet data length on an existing connection (sniffed correctly so far with the default packet data length of 27 bytes), the nRF Sniffer looses track of the encryption as soon as a packet is sent with a data length larger than the default 27 bytes. Starting from this moment, all subsequent packets are flagged with the following error message:

"Encrypted packet decrypted incorrectly (bad MIC)"

even if their packet data length is smaller than 27 bytes.

Can you confirm that this is a known bug or a missing feature of the nRF Sniffer?
In the latter case, I would urge you to document this limitation in the nRF Sniffer documentation!

Is a fix or feature implementation planned?

Thank you very much.

[Hung Bui]

Hi Ricardo, 

Could you send the sniffer trace ?
Please be aware that if there is bond between the two devices that you are sniffing, you would need to capture bonding process so that the sniffer catch the keys, and try to avoid bonding using LE Secure connection. 

[Magoo]

Hi Hung Bui,

I can assure you that nRF Sniffer has been capturing well before the device has bonded to the computer, therefore the keys have been correctly sniffed.

This can be easily verified in the following screenshot:

In my application (a Generic HID BLE device), the data payload for input reports consists of 64 bytes.

In the screenshot, you can se the correct transmission of such a payload in packets 5309+5311+5313, split in 3 segments when using the default packet data length of 27 bytes.
Data are received correctly and this occurs well after the device has bonded and exchanged the encryption keys.

Another successful data transmission occurs in packets 5345+5347+5349.
Therefore, nRF Sniffer has been able to catch the encryption keys correctly.

Then, at packet n. 6973, my device requests a packet data length increase from 27 to 71 bytes. It does so by calling the function nrf_ble_gatt_data_length_set() . This is to accomodate the 64 bytes of data payload in a single on-air data packet.

Packet data length change is confirmed by the peer at packet 6974 and also confirmed by the following messages sent to the nRF Logger console:

<info> app: USBD BLE Composite HID device started.
<info> app: USBD HID Composite device started.
<info> app: Erase bonds!
<debug> app: pm_whitelist_get returns 0 addr in whitelist and 0 irk whitelist
<info> app: Fast advertising.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 67 bytes on connection 0x0.
<info> app: Connected
<debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes.
<debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
<debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 515 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 67 bytes (desired: 67) on connection 0x0.
<debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 27
<debug> nrf_ble_gatt: max_tx_octets: 27
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120
<debug> nrf_ble_gatt: ATT MTU updated to 67 bytes on connection 0x0 (response).
<info> app: Connection secured: role: 1, conn_handle: 0x0, procedure: 1.
<info> app: New Bond, add the peer to the whitelist if possible
<info> app:     m_whitelist_peer_cnt 1, MAX_PEERS_WLIST 8
.....
.....
<info> app: we are going to request change of packet data length ...
<debug> nrf_ble_gatt: Updating data length to 71 on connection 0x0.
<debug> nrf_ble_gatt: Data length updated to 71 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 71
<debug> nrf_ble_gatt: max_tx_octets: 71
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120

The problem is that shortly after, nRF Sniffer looses track of data encryption and all data packets are flagged as:

Encrypted packet decrypted incorrectly (bad MIC)

For example, packet 8683 was a transmission of the usual 64 bytes of data (but only a length of 7 bytes is reported).

And packets 9662, 9928, 10196 are standard "Battery Service" packets (8 bytes long), but are not decrypted anymore by nRF Sniffer. The problem persists for all subsequent data packets until the device is reset and a new bonding established.

I can confirm that the data arrive correctly at the peer (a Macbook Pro) after the packet data length increase to 71 bytes, regardless of the fact that nRF Sniffer reports decryption errors. (fortunately at least this works  !)

I enclose the full Wireshark log.

In my opinion it must be a nRF Sniffer bug.

4377.5_nRF Sniffer log-unsuccessful change of packet data length (DLE) commented.pcapng