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]

Fix posted with nRF Sniffer v2 Beta 3-1 , I tested successfully for encrypted DLE for 71 bytes

[Magoo]

Dear David Edwin,

thank you for the new nRF Sniffer v2 Beta 3-1.

I tried it but unfortunately I was never able to arrive to the point where I change DLE to 71 bytes and try sending data. The sniffer looses track of encryption before that.

I get plenty of:

"Encrypted packet decrypted incorrectly (bad MIC)"

messages.

Very often they start arriving already during the Bluetooth pairing/connecting process.
I attach a Wireshark log.

In this sense (i.e. in decrypting the messages), the earlier nRF Sniffer Beta was more stable!

Wireshark log.pcapng

[Magoo]

Dear David Edwin,

I was finally able to run a test with nRF Sniffer up to the point where I can exchange data packets with a DLE of 71 bytes.

It turns out (at least in the few tests that I could run) that as expected, your fix with nRF Sniffer v2 Beta 3-1 solves the problem with garbage data shown in the data packet payload (see problem reported above with nrf_sniffer_2.0.0-beta-2-1_12oct2018_1c2a221 version).

Regarding the frequent issue with "Encrypted packet decrypted incorrectly (bad MIC)" messages shown by the nRF Sniffer, I am wondering if it can be somewhat related to the CPU load of the PC running the sniffer?

In fact, in my most recent tests, I have tried to keep the CPU load of the PC running nRF Sniffer very low (no software development environment, debugger, web browser, Java console and the like running) and this may have helped.

Can you confirm? Would it be worth to suggest this in the operating instructions of nRF Sniffer? Could it be improved?

Thank you, best regards.

[David Edwin]

Hmm, PC load should not be an issue as we are decrypting on the nRF IC, but the serial traffic may be helped by having the PC load reduced. However MIC failure is coming from the firmware.This will need more testing to re-produce as I am not able to re-produce this yet.