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.

[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

[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

[Magoo]

Dear David Edvin,

I'm wondering if you could replicate the issue that I reported in my reply of October 25 ?

In that post I reported that nrf_sniffer_2.0.0-beta-2-1_12oct2018_1c2a221 is now capable to decode packets with length greater than 27 bytes, however, some of the payload bytes appear to display a wrong value.

To my best knowledge, it must be an error with nrf_sniffer (showing wrong data) or with the SoftDevice (sending wrong data). My application sends exactly the same payload (all bytes zero) before and after switching from 27 to 71 bytes of on-air packet length. Before switching packet length, nrf_sniffer shows the data correctly (all bytes zero) as you can see in the log file attached to my previous post. The log includes some sniffed traffic before and after switching packet length from 27 to 71 bytes.

Thank you for your kind answer.

Best regards

Ricardo