• State Not Answered
  • Replies 12 replies
  • Subscribers 87 subscribers
  • Views 926 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 349994
Options

Can't capture any packets (Zigbee)

Sannie

Hello,

I have been trying to get my brand new nRF52840 Dongle working as an 802.15.4/Zigbee sniffer, but I am not able to capture any packets, even though the interface is detected and responsive. Here are the details of what I have done and tested:

Setup & Steps Taken

Interface Detection

When running from the terminal:

./nrf802154_sniffer.py --extcap-interfaces
extcap {version=0.8.0}{help=https://github.com/NordicSemiconductor/nRF-Sniffer-for-802.15.4}{display=nRF Sniffer for 802.15.4}
interface {value=/dev/cu.usbmodem11201}{display=nRF Sniffer for 802.15.4}
control {number=6}{type=button}{role=logger}{display=Log}{tooltip=Show capture log}

Wireshark behavior:

  • When running Wireshark with sudo (as mentioned in GitHub issue #68), the interface appears, and I can start a capture.

  • Without sudo, the interface does not appear in Wireshark.

pySerial detection:

/usr/bin/python3 -m serial

--- Available ports:
--- 1: /dev/cu.Bluetooth-Incoming-Port 'n/a'
--- 2: /dev/cu.debug-console 'n/a'
--- 3: /dev/cu.usbmodem11201 'nRF 802154 Sniffer'

When I send the 'channel' command to /dev/cu.usbmodem11201, it correctly returns the last configured channel (e.g., 11). When I send the 'receive' command no packets caputerd.

Networks Tested

  • Zigbee2MQTT network on channel 11

  • Philips Hue network on channel 15

  • I am certain these channel settings are correct.

  • No packets are captured on either network.

Traffic Verification

  • I have triggered heavy traffic on both networks (turning lights on/off, pressing buttons on temperature sensors, toggling power switches, etc.).

  • Zigbee2MQTT logs show that devices are reporting as expected.

Other Information

  • The sniffer is not in bootloader mode (LED blinks slowly green when idle, blinks faster when capture starts).

  • Tested on:

    • macOS 15.5 (24F74)

    • Windows 11 Pro

  • On both OSes:

    • The interface is detected

    • I can communicate with it via pySerial

    • But no packets are ever captured

  • Wireshark version: 4.4.8 (v4.4.8-0-g0d289c003bfb)

  • Tried reconnecting/replugging the dongle multiple times on both OSes.

  • Same result every time: interface visible, capture starts, but no packets arrive.

Question
Given that:

  • The firmware and extcap script match (v0.8.0)

  • The interface is detected and responds to commands

  • The dongle’s LED activity changes when capturing

  • Traffic is definitely present on the selected channel

…what could prevent the sniffer from actually receiving any 802.15.4 packets? Is there any known issue with v0.8.0 on the nRF52840 Dongle in promiscuous mode, or any additional configuration needed?

Thanks in advance for any guidance.

Parents
  • 0

    Hello again,

    As a follow-up to my previous post about not being able to capture any 802.15.4 packets with the nRF52840 Dongle, I also tried using the RSSI Viewer app from nRF Connect for Desktop.

    What I did

    • When I first started RSSI Viewer, it asked me to update the bootloader. This failed with an error.

    • After that, it continued and flashed the RSSI firmware. However, even then I saw no RSSI data at all in the app.

    Here is the log output:

    08:59:45.487 Initialising the bundled nrfutil device
08:59:46.153 Using the bundled core version for nrfutil device: 8.1.0
08:59:46.256 Using nrfutil-device version: 2.10.2
08:59:46.256 Using nrf-device-lib version: 0.17.71
08:59:46.256 Using nrf-probe version: 0.38.0
08:59:46.256 Using JLink version: JLink_V8.18
09:00:07.538 Getting serial port options from the persistent store for D41CCCDC14C2.pc-nrfconnect-rssi
09:00:07.539 Device connected with the serial number D41CCCDC14C2
09:00:07.772 Getting serial port options from the persistent store for D41CCCDC14C2.pc-nrfconnect-rssi
09:00:08.996 Selecting device with the serial number D41CCCDC14C2
09:00:09.550 Selected device with the serial number D41CCCDC14C2
09:00:12.179 Update bootloader [object Object]
09:00:12.853 Error: Failed with exit code 1. One or more program tasks failed: * D41CCCDC14C2: (SdfuInvalidObject). Message: Failed,.
09:00:12.854 Failed to write bootloader to the target device: Failed with exit code 1. One or more program tasks failed: * D41CCCDC14C2: (SdfuInvalidObject). Message: Failed,.
09:00:12.854 Error while setting up device with the serial number D41CCCDC14C2
09:00:12.854 "Failed with exit code 1.\nOne or more program tasks failed:\n * D41CCCDC14C2: (SdfuInvalidObject).\nMessage: Failed,."
09:00:12.855 Deselected device
09:00:15.316 Selecting device with the serial number D41CCCDC14C2
09:00:15.873 Selected device with the serial number D41CCCDC14C2
09:00:18.796 Continuing with old bootloader
09:00:21.223 All DFU images have been written to the target device.
09:00:31.470 Device connected with the serial number D41CCCDC14C2
09:00:31.471 Failed to detect device after reboot. Timed out after 10 seconds.
09:00:31.471 Error while setting up device with the serial number D41CCCDC14C2
09:00:31.471 "Failed to detect device after reboot. Timed out after 10 seconds."
09:00:31.471 Deselected device

    My interpretation (please correct me if I am wrong)

    From looking at the RSSI Viewer firmware source code, it seems to me that:

    • The firmware waits for specific radio events (EVENTS_READY, EVENTS_RSSIEND, etc.) without any timeout or error handling.

    • If the radio does not respond correctly, the code might just “hang” waiting forever.

    • I also noticed that the firmware does not seem to use the dongle’s LED as an indicator for scanning or radio errors – the LEDs are only toggled for USB/CDC events or if the user sends a “led” command over serial.

    So my question is: if the radio part of the dongle is not working, is it expected that the firmware still flashes successfully but produces no RSSI output at all (and no LED feedback)?

    That seems to match what I am seeing: the dongle enumerates, the firmware appears to be flashed, the LED blinks according to USB state, but the app never receives any actual RSSI values.

    Thanks again for any clarification – I’m mainly trying to understand whether my dongle might simply have a broken RF front-end, or if I am misinterpreting how the firmware should behave in such a case.

Reply
  • 0

    Hello again,

    As a follow-up to my previous post about not being able to capture any 802.15.4 packets with the nRF52840 Dongle, I also tried using the RSSI Viewer app from nRF Connect for Desktop.

    What I did

    • When I first started RSSI Viewer, it asked me to update the bootloader. This failed with an error.

    • After that, it continued and flashed the RSSI firmware. However, even then I saw no RSSI data at all in the app.

    Here is the log output:

    08:59:45.487 Initialising the bundled nrfutil device
08:59:46.153 Using the bundled core version for nrfutil device: 8.1.0
08:59:46.256 Using nrfutil-device version: 2.10.2
08:59:46.256 Using nrf-device-lib version: 0.17.71
08:59:46.256 Using nrf-probe version: 0.38.0
08:59:46.256 Using JLink version: JLink_V8.18
09:00:07.538 Getting serial port options from the persistent store for D41CCCDC14C2.pc-nrfconnect-rssi
09:00:07.539 Device connected with the serial number D41CCCDC14C2
09:00:07.772 Getting serial port options from the persistent store for D41CCCDC14C2.pc-nrfconnect-rssi
09:00:08.996 Selecting device with the serial number D41CCCDC14C2
09:00:09.550 Selected device with the serial number D41CCCDC14C2
09:00:12.179 Update bootloader [object Object]
09:00:12.853 Error: Failed with exit code 1. One or more program tasks failed: * D41CCCDC14C2: (SdfuInvalidObject). Message: Failed,.
09:00:12.854 Failed to write bootloader to the target device: Failed with exit code 1. One or more program tasks failed: * D41CCCDC14C2: (SdfuInvalidObject). Message: Failed,.
09:00:12.854 Error while setting up device with the serial number D41CCCDC14C2
09:00:12.854 "Failed with exit code 1.\nOne or more program tasks failed:\n * D41CCCDC14C2: (SdfuInvalidObject).\nMessage: Failed,."
09:00:12.855 Deselected device
09:00:15.316 Selecting device with the serial number D41CCCDC14C2
09:00:15.873 Selected device with the serial number D41CCCDC14C2
09:00:18.796 Continuing with old bootloader
09:00:21.223 All DFU images have been written to the target device.
09:00:31.470 Device connected with the serial number D41CCCDC14C2
09:00:31.471 Failed to detect device after reboot. Timed out after 10 seconds.
09:00:31.471 Error while setting up device with the serial number D41CCCDC14C2
09:00:31.471 "Failed to detect device after reboot. Timed out after 10 seconds."
09:00:31.471 Deselected device

    My interpretation (please correct me if I am wrong)

    From looking at the RSSI Viewer firmware source code, it seems to me that:

    • The firmware waits for specific radio events (EVENTS_READY, EVENTS_RSSIEND, etc.) without any timeout or error handling.

    • If the radio does not respond correctly, the code might just “hang” waiting forever.

    • I also noticed that the firmware does not seem to use the dongle’s LED as an indicator for scanning or radio errors – the LEDs are only toggled for USB/CDC events or if the user sends a “led” command over serial.

    So my question is: if the radio part of the dongle is not working, is it expected that the firmware still flashes successfully but produces no RSSI output at all (and no LED feedback)?

    That seems to match what I am seeing: the dongle enumerates, the firmware appears to be flashed, the LED blinks according to USB state, but the app never receives any actual RSSI values.

    Thanks again for any clarification – I’m mainly trying to understand whether my dongle might simply have a broken RF front-end, or if I am misinterpreting how the firmware should behave in such a case.

Children
No Data
Related
Terms of service