nRF52840 DK sniffer fails to display Data messages after Connect_Ind, only advertisements

//nRF52840 DK//PCA10056//central=apple-smartphone//Wireshark Version 4.0.1 (v4.0.1-0-ge9f3970b1527) sniffer.//

Wireshark is working perfectly on Advertising packets, but once a CONNECT_IND comes in

from the smartphone, no more messages from this Source are displayed

(since this source is programmed to stop Advertising on a Connect).

The smartphone does indicate that a series of messages are

being received from this source.

So the question is what in Wireshark/nRF-Sniffer installation/troubleshooting affects

ability to display Data messages in Connect mode ?

(No encryption or privacy is enabled, at this point).

In the Wireshark Device options, I see 2:

All advertising devices  and  Follow IRK., preceding a list of devices and dBm observed.

  • Hi 

    Have you selected the device in the Wireshark interface? 

    The nRF Sniffer can only sniff one connection at a time, and you need to select which device you want to track before the device connects. 

    Best regards
    Torbjørn

  • I just figured that out last night.

    So that is what the purpose of that list of various detected devices under Device.

    Is this nordic-wireshark interface  documented anywhere, or is this the chaos of active

    development by hard working engineers ?

    Normally, in developing ble firmware, after a firmware build, one runs the sniffer anew,

    sets up them sniffer's configuration,

    then presses Go  on the firmware debugger, to start executing the firmware.

    That sequence would not see the under-development device as

    an active air-detected device, yet, in that Device list.

    So it would be hard even to 'intuit' that functionality.

    Separately, is there any way to filter out the Empty PDUs from the list of packets ?

    And when will your engineers modify the Wireshark plug-in 

    to make btle.advertising_address official,

    in the  /list right-click menu/apply as filter/ option ?

    Currently eth.src is the default.

    Also useful would be a Filter All option, for already detected sources,

    just before pressing Go on a device generating random addresses for itself,

    Thanks.

  • Hi Aeneas, 
    I assume you have managed to select your device in the device list and now can follow the connection  ?
    The process of selecting the device in device list is actually in the documentation of the sniffer. You can see here and here.
    You can filter empty packet using !(btle.data_header.length == 0) . You can see some other common use filters here.

    Aeneas said:

    Normally, in developing ble firmware, after a firmware build, one runs the sniffer anew,

    sets up them sniffer's configuration,

    then presses Go  on the firmware debugger, to start executing the firmware.

    That sequence would not see the under-development device as

    an active air-detected device, yet, in that Device list.

    So it would be hard even to 'intuit' that functionality.

    I don't really get what you meant above. Could you elaborate ? 
    The sniffer can only capture active on-air device. The list may not be updated if you are only following one single device. If you want to update the list (if your device changes the address) you need to select follow all advertising devices or restart the sniffer. 
    Usually to make it easy to track a device, I would fix the address of the device as a static random address  and then I don't need to change the sniffer to follow new address. 

  • That portion of my statement  deals with the fact that the nrf Sniffer Plugin

    documentation does not state clearly that unless you select one of the

    air-detected devices

    listed with dBm under Device, you will not see any Data traffic at all --

    only Advertising traffic.

    This runs counter to the historic background of Wireshark, which relies

    on the right-click Filter menu, to select addresses to monitor/follow.

    That right-click Filter menu still works for Advertising Only traffic,

    as long as translation is made to btle.advertising_address in a tedious text replacement

    process from the eth.src default (i.e. for Ethernet).

  • Hi Aeneas, 

    Thanks for the feedback. 

    The challenge here is that there are 40 channels for BLE and the radio on the nRF52 can only listen on one channel at a time.  It's impossible for the sniffer to follow multiple connections (and advertising packet) with just one radio. 

    This is the reason why if you don't select a single device the sniffer can only scan advertising packets (which use only 3 channels in a predictable way). Only after a device is selected the sniffer can detect a connection for the specified device and can follow the connection. Only one connection at a time. 
    Some of the more expensive sniffer can sniff on all channels so you can just simply filter the device(s) you want to listen on the right-click menu but we are talking about professional sniffers at the cost of dozen of thousand USD.

Related