nRF Sniffer unable to track packet data length changes

RE: nRF Sniffer unable to track packet data length changes

David Edwin — Fri, 30 Nov 2018 14:17:35 GMT

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.

RE: nRF Sniffer unable to track packet data length changes

Magoo — Wed, 28 Nov 2018 15:00:55 GMT

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.

RE: nRF Sniffer unable to track packet data length changes

Magoo — Thu, 22 Nov 2018 19:19:05 GMT

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!

devzone.nordicsemi.com/.../Wireshark-log.pcapng

RE: nRF Sniffer unable to track packet data length changes

David Edwin — Tue, 20 Nov 2018 12:17:35 GMT

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

RE: nRF Sniffer unable to track packet data length changes

David Edwin — Tue, 20 Nov 2018 08:47:33 GMT

Replicated the issue and testing a fix for this.

RE: nRF Sniffer unable to track packet data length changes

David Edwin — Mon, 19 Nov 2018 15:07:15 GMT

Can you show the nRF Sniffer log file for this issue, whenever I see that the length is unexpectedly small, I see that there is a lot of packet losses on the UART.

To view the nRF Sniffer log : Click on the log button on the nRF Sniffer toolbar in Wireshark

RE: nRF Sniffer unable to track packet data length changes

David Edwin — Mon, 19 Nov 2018 14:27:02 GMT

Apologies. I did not get notifications on your updates to the case. The nRF Sniffer v2 beta-3 should have fixed this issue but let me attempt to replicate the issue.

RE: nRF Sniffer unable to track packet data length changes

Magoo — Tue, 13 Nov 2018 13:55:26 GMT

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

RE: nRF Sniffer unable to track packet data length changes

Magoo — Thu, 25 Oct 2018 18:21:01 GMT

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

devzone.nordicsemi.com/.../8540.6_5F00_nRF-Sniffer-log_2D00_change-of-packet-data-length-_2800_DLE_2900_-w-beta2_2D00_1.pcapng

RE: nRF Sniffer unable to track packet data length changes

Austin — Tue, 23 Oct 2018 22:42:47 GMT

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.

RE: nRF Sniffer unable to track packet data length changes

David Edwin — Tue, 23 Oct 2018 09:01:40 GMT

This is a bug in the beta 2. Please check using the attached version. You need to use a nRF52-DK or an nRF52840-DKdevzone.nordicsemi.com/.../nrf_5F00_sniffer_5F00_2.0.0_2D00_beta_2D00_2_2D00_1_5F00_12oct2018_5F00_1c2a221.zip

RE: nRF Sniffer unable to track packet data length changes

Magoo — Mon, 22 Oct 2018 17:06:44 GMT

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.

devzone.nordicsemi.com/.../4377.5_5F00_nRF-Sniffer-log_2D00_unsuccessful-change-of-packet-data-length-_2800_DLE_2900_-commented.pcapng

RE: nRF Sniffer unable to track packet data length changes

Hung Bui — Mon, 15 Oct 2018 10:30:10 GMT

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.