nRF Sniffer v1.0.1_1111 only shows advertisements

[Lars Hamrén]

Hi,

I start the sniffer (on Windows), wait for it to find an advertising device, select that device, and then start Wireshark 1.12.8 .

In Wireshark I can only see broadcasts (ADV_IND) but no data on any channel.

I know for sure that data is being sent and received, since the application works and since I log all communication in my application.

On the "left hand side" I have tested with two different BLE dongles.

On the "right hand side" I am using a BLE development kit from Cypress. All of this is well tried and tested.

All devices are well within a metre from each other.

Using nRF 51 DK.

Have flashed the .HEX file from the Sniffer/Firmware directory.

Sniffer output:

NORDIC SEMICONDUCTOR SNIFFER SOFTWARE v.1.0.1_1111

   Sniffer ready and connected on COM13
   Software version      SVN rev. 1111
   Firmware version      SVN rev. 1111
   Nordic Plugin version version information unavailable
   BTLE Plugin version   SVN rev. 1111
...snip..
 Available devices:
        # public name            RSSI            device address
    ---------------------------------------------------------------------
 -> [X] 0 BLE Slider and L..    -53 dBm         00:a0:50:02:27:27  public
Sniffing device 0 - "BLE Slider and LED"

Note thet "Nordic Plugin version" does not have a value.

"nordic_ble.dll" is is wiresharks plugin directory. "btle.dll" is not, maybe because that functionality is now included in Wireshark.

=== update ===

I got the Linux version working, and get the same result. Added a print of every packet received in _continuouslyPipe in SnifferCollector

Got packet 06, 02, 01, FF, 07, 0E, 57, 04
Got packet 06, 02, 01, 00, 08, 0E, 57, 04
Got packet 06, 02, 01, 01, 08, 0E, 57, 04
Got packet 06, 36, 01, 02, 08, 06, 0A, 01, 25, 2D, 00, 00, 12, 03, 21, 01, D6, BE, 89, 8E, 00, 23, 27, 27, 02, 50, A0, 00, 02, 01, 06, 13, 09, 42, 4C, 45, 20, 53, 6C, 69, 64, 65, 72, 20, 61, 6E, 64, 20, 4C, 45, 44, 05, 16, B5, CA, A2, CA, 7C, 0C, C5
Got packet 06, 36, 01, 03, 08, 06, 0A, 01, 26, 2D, 00, 00, 7A, 03, 00, 00, D6, BE, 89, 8E, 00, 23, 27, 27, 02, 50, A0, 00, 02, 01, 06, 13, 09, 42, 4C, 45, 20, 53, 6C, 69, 64, 65, 72, 20, 61, 6E, 64, 20, 4C, 45, 44, 05, 16, B5, CA, A2, CA, 7C, 0C, C5
Got packet 06, 36, 01, 04, 08, 06, 0A, 01, 27, 2D, 00, 00, 7A, 03, 00, 00, D6, BE, 89, 8E, 00, 23, 27, 27, 02, 50, A0, 00, 02, 01, 06, 13, 09, 42, 4C, 45, 20, 53, 6C, 69, 64, 65, 72, 20, 61, 6E, 64, 20, 4C, 45, 44, 05, 16, B5, CA, A2, CA, 7C, 0C, C5
Got packet 06, 02, 01, 05, 08, 0E, 57, 04
Got packet 06, 02, 01, 06, 08, 0E, 57, 04
Got packet 06, 02, 01, 07, 08, 0E, 57, 04
Got packet 06, 36, 01, 08, 08, 06, 0A, 01, 25, 2D, 00, 00, A2, FF, 02, 00, D6, BE, 89, 8E, 00, 23, 27, 27, 02, 50, A0, 00, 02, 01, 06, 13, 09, 42, 4C, 45, 20, 53, 6C, 69, 64, 65, 72, 20, 61, 6E, 64, 20, 4C, 45, 44, 05, 16, B5, CA, A2, CA, 7C, 0C, C5
Got packet 06, 35, 01, 09, 08, 06, 0A, 01, 26, 2D, 00, 00, 78, 05, 00, 00, D6, BE, 89, 8E, 05, 22, 6B, 13, DA, 72, 02, 00, 27, 27, 02, 50, A0, 00, DF, 4A, 65, 50, 41, BF, 08, 03, 16, 00, 36, 00, 00, 00, 2A, 00, FF, FF, FF, FF, 1F, B0, EA, C1, 0B
Following device
###### Found dev BLE device ""BLE Slider and LED"" ([0, 160, 80, 2, 39, 39, False]). Start wireshark with -Y btle -k -i /tmp/Sniffer/SnifferAPIBuild/logs/nordic_ble.pipe
Got packet 06, 02, 01, 0A, 08, 0E, 57, 04
Got packet 06, 02, 01, 0B, 08, 0E, 57, 04
... more of these...

So the broadcast packets reach the SnifferCollector, but no other traffic.

I then added a similar print in PacketRead::getPacket, with the same result. Broadcast packets only.

It would seem that the data packets don't get sent by the firmware.

Does the firmware make any assumptions as to the "correct" sequence of packets? Maybe my application sends packets in the "wrong" way, acoording to the firmware, even though the application works.

=== update 2 ===

Still on Linux.

To avoid any problems that my "left hand side" (a Linux-based application) might cause, I tried a generic GATT client (Cypress CySmart, on Windows). Same result, broadcast packets only.

/Lars

[Petter Myhre]

I'm not sure if the sniffer have worked before or not. Anyways.

It is recommended to use Wireshark v1.10 with the nRF Sniffer. It is the latest version that have been tested.

Other than that everything seems correct.

What could happen is that the sniffer is unable to sniff the connection request, then it will not be able to follow the connection. You should have the sniffer close to both devices. I guess this is not your problem though.

Try to turn off other Bluetooth devices that you are not testing with, and disable Bluetooth on central devices that sends out scan requests(smart phones etc.)

We are aware that there are issues with the nRF Sniffer, and we are working on fixing them. I even have trouble with mine sometimes. Restarting my computer resolves it, bad solution yes, but it works for me.

[Lars Hamrén]

• I tested just very quickly a few weeks ago. Can't remember for sure if it worked then. I actually think it did. Seem to remember several different packet types.

• This problem is independent of Wireshark.

• The devices are within a few dm of each other.

• Yes, it seems that it does not pick up the connection request. But why?

• Have tried rebooting. Note that the problem occurs both on Linux and Windows.

• One of the dongles I have tried is the PTS dongle.

• I think the problem is in the firmware (HEX file). Do you have a later, possibly unreleased, firmware I could try?

[Petter Myhre]

We are not sure why. If replugging the dongle and rebooting doesn't work I don't know what to say. We don't have any newer firmware. Do you have any older kits available? Like an evaluation kit?

[Lars Hamrén]

I installed the sniffer on another machine, and got it to work. Quite erratic, though. Sometimes it works, sometimes not. Not very impressive, is it? Get your skates on and start fixing this software. The Linux example Python script is not even syntactically correct. See devzone.nordicsemi.com/.../

The only kit I have is the nRF 51 DK.

[Lars Hamrén]

Here is how I solved the problem. I realised that I could not debug the Windows application without the source code, and that debugging the Linux application was going to take more time than writing a new application, from scratch.

So that is what I did. I now have a stable and reliable sniffer application that runs on UNIX, and that is designed to be easily ported to other OS:es, like OS X and Windows.

One thing to note is that the sniffer firmware (in the nRF51) needs to see more than just a few broadcast packets before latching on to a connection. This works:

1. Start the sniffer
2. Put the slave/peripheral into advertising mode
3. Put the master/central into scanning mode (listening for broadcasts)

This may not work:

1. Start the sniffer
2. Put the master/central into scanning mode (listening for broadcasts)
3. Put the slave/peripheral into advertising mode

In this latter case, the connection is created too quickly for the sniffer firmware.