This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF Sniffer v1.0.1_1111 only shows advertisements

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

Parents
  • 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.

Reply
  • 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.

Children
Related