nRF Sniffer Firmware > v3.0.0 doesn't work on nRF51822 based board

[Thinner]

Hi Nordic,

i'm using a nRF51822 based board (Adafruit Bluefruit LE Sniffer, PRODUCT ID: 2269, https://www.adafruit.com/product/2269) and could sucessfully update to nRF Sniffer firmware v3.0.0.

But the recorded pcap files can't be decrypted by 3rd party tools like crackle (github.com/.../crackle) or bsniffhub (https://github.com/homewsn/bsniffhub) even with known LTK (but this is another topic *1).

I was very happy to see lately released v4.0.0 supports setting LTK, so i flashed this version to the board, but there is no interface in Wireshark v3.4.7 (running with admin rights and correct extcapt) and there is no output when connecting serial port terminal. I've also tried firmware v3.1.0 with same result. I'm using Python v3.7.5.

Adafruit says "If by chance you have an nRF51822 board you want to load the firmware on, here's a hex  that does not require the 32khz crystal (but does require the 16 mhz crystal)" (https://learn.adafruit.com/introducing-the-adafruit-bluefruit-le-sniffer/using-with-sniffer-v2). This hex is v2.0.0beta1.

I've soldered a 32.768kHz crystal to the backside of the board today (without caps). Surprisingly firmware 3.1.0 is now working too.

Question: Is a 32kHz crystal really needed to run firmware > 3.0.0?

But v4.0.0 still doesn't work. There is no interface in Wireshark and there is no output when connecting serial port terminal.

Question: Any ideas how to get it working?

Additional Question:
Is there any distributor shipping nRF52840 Dongle from Europe?

wbr

Thinner

*1
It looks like that packets that can't be decrypted by nRF Sniffer firmware are getting corrupted (see https://github.com/homewsn/bsniffhub/blob/master/src/ble_decoder.c line 1227, "but, unfortunately, nRF Sniffer corrupts the original payload if it cannot decrypt, so no chance to decrypt here") . I've recorded the same session on two Adafruit devices, one running nRF Sniffer v3.0.0 and one running btlejack (github.com/.../btlejack). But only btlejack pcap-file can be decrypted by crackle with known LTK. I've added some debug output to crackle to log raw packet data. See screenshot, left one is nRF Sniffer, right one is btlejack. It can be seen bytes are completely different but number of bytes do correlate. See line 11, 7 bytes data + 4 bytes mic on the left (=11 bytes), 11 bytes data and 4 bytes mic on the right (=15 bytes). There is always a difference of 4 btyes. Maybe you want to have a look at this.

[Hung Bui]

Hi Thinner, 

I would suggest to get hold of a nRF52 DK or nRF52 Dongle to use as the sniffer backend. They cost around €10 and would save you from lots of headache and time. The new sniffer firmware is not tested against the Adafruit board so we can't really tell what could be wrong here. 

You can find the distributor list here: https://www.nordicsemi.com/About-us/FindDistributor

You can order online from stores as well, such as digikey or mouser. 

[Thinner]

Hi Kenneth,

this is an answer i can work with, many thanks.

Let me sum up to make sure i got it right:

1. you have switched from nRF5 SDK to nRF Connect SDK with v3.1.0 -> this explains grow up of code size

2. nRF Connect SDK (target nRF51DK-board) requires an external 32kHz crystal -> this explains why Adafruit board does work after soldering a crystal

3. there is an issue with v4.0.0 so it doesn't work on nRF51822 in general -> does that mean it will even not work on nRF51DK right now?

I came across this post: github.com/.../26256

and this pdf: infocenter.nordicsemi.com/.../nRF51822-pan_v2.1.pdf

"The following instructions shall be executed before any peripheral can be used.
*(uint32_t *)0x40000504 = 0xC007FFDF;
*(uint32_t *)0x40006C18 = 0x00008000;"

DWord 0xC007FFDF can be found in v3.0.0 binary at offset 0x0790, but can't be found in v3.1.0 or v4.0.0 binary.

Maybe there are other silicon errata not considered in Zephyr/nRF Connect SDK.

wbr
Thinner

[Joakim Andersson]

2. It sets the LF Clock source as default to external XTAL. Since we build for the nrf51dk as the build target. We can change the LF Clock source to an internal one in order to support the firmware being flashed to the Adafruit board.
It would however be best if there was support for the board in NCS/Zephyr build system.

3. Yes unfortunately. The issue is an unaligned memory access. So it is not the PAN notice. But you are right. The build system did not include the PAN workarounds. The issue is being addressed here: github.com/.../37925

[Thinner]

Hi,

thanks for the background informations. I've asked Adafruit to add support for the board in Zephyr. They will have a look at this topic, they said.

wbr
Thinner