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

[David Edwin]

This is a bug in the beta 2. Please check using the attached version. You need to use a nRF52-DK or an nRF52840-DKnrf_sniffer_2.0.0-beta-2-1_12oct2018_1c2a221.zip

[Austin]

I was also seeing this issue with nRF Sniffer 2.0.0.2.beta.  After reinstalling with the attached 2.0.0-beta-2-1 I am able to successfully sniff encrypted packets using a nRF52840-DK v0.9.2.

[Magoo]

Dear David,

thank you for letting me test the nrf_sniffer_2.0.0-beta-2-1_12oct2018_1c2a221 version.

It is an improvement over the earlier beta, but there are still problems.

• packet length is now reported correctly also after changing data packet length
• packets with a length of ≤27 bytes are now decrypted correctly (for example the battery service packets) after the change of data length
• however, packets with a length of 71 bytes (the size I use to accomodate 64 bytes of data payload + header) (and probably all packets with a length greater than 27 bytes) are still not decrypted correctly and are flagged as "Encrypted packet decrypted incorrectly (bad MIC)"

In the following, I show you two screenshots: in the first one, you see my 64 bytes of data (which I intentionally set to be all zero, except the second byte which can be either 0x04 or 0x00) received correctly using the default on-air packet length of 27 bytes. The 64 bytes are split and transmitted in 3 packets (with a length of 27, 27 and 17 bytes respectively) and reassembled correctly (at packet #5278). You can see the 64 bytes of payload - all zeros - shown correctly in the lower part of the screenshot:

Then, at packet 7064 my device requests to increase the on-air data packet length to 71 bytes and this request is acknoledged by the peer in packet 7065.

Then, at packet 8020 you can see again a data packet with 64 bytes of payload which are supposed to be all zeros.

However, nRF Sniffer shows some garbage data inside (see bottom part of the following screenshot) and flags the packet as "Encrypted packet decrypted incorrectly (bad MIC)".

I enclose you the full Wireshark log corresponding to above screenshots.

Since in my application running on the nRF52840 nothing changes in the two situations (with on-air packet data length of 27 bytes or 71 bytes), as this is handled by the SoftDevice, I assume that it must still be a bug in nRF Sniffer.  

Or it could be a bug in the SoftDevice which sends wrong data (??) - at this point of my development I am not yet able to tell if all 64 bytes of data are received correctly by the peer  - but this seems very unlikely to me. I can however confirm that at least the first 15 bytes of data are received free of error.

Best regards.

Ricardo

8540.6_nRF Sniffer log-change of packet data length (DLE) w beta2-1.pcapng