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

nrf52840 failure with connect desktop and wireshark

Hi all, I am trying to use the nrf52840 dongle with wireshark, I was having permission errors trying to open the device in the program section of the nrf desktop suite running on Ubuntu 20 and followed the suggestions found at https://devzone.nordicsemi.com/f/nordic-q-a/52546/nrf-connect-linux/211625#211625 , adding the user to the dialout group did not do anything, the method using https://github.com/NordicSemiconductor/nrf-udev and https://github.com/NordicSemiconductor/nrf-udev/releases made the dongle visible and readable.  In the program section of the desktop suite I selected to add the hex nrf802154_sniffer_dongle.hex and ran the 'write' option.  During or after it ran the write option i recieved the following log

2020-10-17T15:14:09.904Z INFO Parsing HEX file:  /home/david/nRF-Sniffer-for-802.15.4/nrf802154_sniffer/nrf802154_sniffer_dongle.hex
2020-10-17T15:14:10.036Z INFO File was last modified at  10/16/2020, 11:51:25 PM
2020-10-17T15:14:15.204Z INFO Using USB SDFU protocol to communicate with target
2020-10-17T15:14:15.271Z INFO Protocol Version:  1 found
2020-10-17T15:14:15.306Z INFO Hardware: 52840 found
2020-10-17T15:14:15.492Z INFO Firmware: Bootloader found
2020-10-17T15:14:15.494Z INFO Firmware: Application found
2020-10-17T15:14:51.577Z INFO Does not need to be reloaded:  /home/david/nRF-Sniffer-for-802.15.4/nrf802154_sniffer/nrf802154_sniffer_dongle.hex
2020-10-17T15:14:51.592Z INFO Hash is generated by SHA256
2020-10-17T15:14:51.605Z INFO Performing DFU. This may take a few seconds
2020-10-17T15:14:51.659Z INFO DFU procedure starts. This may take a few seconds.
2020-10-17T15:14:56.693Z INFO DFU for Application completed successfully!
2020-10-17T15:14:56.694Z INFO 0 dfu package(s) left.
2020-10-17T15:14:56.694Z INFO Waiting for device
2020-10-17T15:15:01.697Z ERROR Reopen device failed: Timeout while waiting for device  C621B478D146 to be attached and enumerated
2020-10-17T15:15:01.698Z INFO Nordic DFU Trigger Interface was not found.Please physically reset device.
2020-10-17T15:15:01.718Z ERROR Device not found due to failure during DFU
2020-10-17T15:15:25.178Z INFO Target device closed.

After this I had to press the reset button on the dongle for it to be recognized, but it did appear to show the hex in the dongles memory.  However, I cannot find any protocol in wireshark despite having added the appropriate python script to the wireshark extcap directory (I have wireshark working successfully with the nrf BLE protocol using  a dongle from Adafruit, so the pyserial and all that is in order) and wireshark does not see the dongle.

I'm very new to working with the wireless protocols and wireshark and the associated hardware so I'm not really sure where the real issue lies in this, if I've overlooked any imortant information please let me know.

Thanks,

David

Parents
  • Thanks for the response Vidar,  yes I have done both of those, changing the user permissions didn't make any difference that I could tell.  From setting up the Bluetooth LE dongle from Adafruit I did find out that running wireshark as sudo can make a difference but, it does not do anything to the protocols to choose from.

    The python file is in the excap folder, and has its permission set to allow executing as a program, I hit the 'refresh interfaces' button in the capture menu, but I'm still not getting the selection for 'nRF Sniffer for 802.15.4'.  I really don't know what I missed, I did the j-link and command line tools.  I'm just stuck right now.

    Thanks for any help,

    David

  • Hi David,

    Please try to program nrf802154_sniffer_dongle.hex from the latest release tagged with v0.7.2. It seems like there may be a problem with the one on Master. The green led should start to blink once you have programmed it. You should also see a new ttyACMx device popping up when the dongle is plugged in (ls /dev/ttyACM*)

  • Ok, new developments, I decided to try a completely fresh install of wireshark which got  a bit complicated and ended up with a completely fresh install of Ubuntu 20.  I wanted to try getting the nrf802154_sniffer protocol to work before making ANY other changes to wireshark.  I installed pyserial and transferred nrf802154_sniffer.py to the extcap folder.  When I copied nrf802154_sniffer.py over I got the following in terminal

    /Downloads/nRF-Sniffer-for-802.15.4$ sudo wireshark
    QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
    18:08:18.709 Main Warn QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
    Initializing caja-open-terminal extension
    RuntimeError: object at 0x7f1649abf500 of type RenameMenu is not initialized
    RuntimeError: object at 0x7f164b1b74c0 of type FolderColorMenu is not initialized

    ** (caja:25234): WARNING **: 18:08:57.949: Could not inhibit power management: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.gnome.SessionManager" does not exist
    Traceback (most recent call last):
    File "/usr/share/caja-python/extensions/dejadup.py", line 156, in get_file_items
    include_paths = self.dejadup.get_dejadup_paths('include-list')
    File "/usr/share/caja-python/extensions/dejadup.py", line 70, in get_dejadup_paths
    paths = ast.literal_eval([stdout][0]) # Convert shell dump to list
    File "/usr/lib/python3.8/ast.py", line 99, in literal_eval
    return _convert(node_or_string)
    File "/usr/lib/python3.8/ast.py", line 98, in _convert
    return _convert_signed_num(node)
    File "/usr/lib/python3.8/ast.py", line 75, in _convert_signed_num
    return _convert_num(node)
    File "/usr/lib/python3.8/ast.py", line 66, in _convert_num
    _raise_malformed_node(node)
    File "/usr/lib/python3.8/ast.py", line 63, in _raise_malformed_node
    raise ValueError(f'malformed node or string: {node!r}')
    ValueError: malformed node or string: b"['$HOME']\n"

    everything from Traceback (most recent call last) is when I actually pasted the file into the extcap folder.  After pasting the file there were no more warnings, I refreshed the interfaces, closed and reopened wireshark and there was still no nRF-Sniffer-for-802.15.4 protocol listed.  I'm hoping maybe this could give you some insight, I'll try looking into it but I'm not sure what it means off the top of my head.

  • Ok, from looking into it for some reason caja file manager is causing all of those, I wouldn't have thought that used python.

    I'm actually getting the nrf 802.15.4 sniffer protocol!  I cannot say what exactly made it show up, the whole list of what I did before this worked: fresh install of Ubuntu 20 and the wireshark from default repository (I did not add an additional wireshark ppa like the instructions suggested), moved the nrf802154_sniffer.py to the global extcap folder, changed the header of the file to python3, refreshed the interfaces then rebooted the computer.

    I'm not sure what the difference was, possibly the version of wireshark, possibly just a new install of wireshark.  Or someohter conflict that could have been happening with the OS.

    So, assuming I can identify the thing I'm hoping to could you suggest a small product that could handle the communication protocols that's compatiable with raspberry pi?  If not raspberry pi arduino?

    Thank you very much for all your help with this!

  • It would of course have been nice to know the root cause of why it didn't work at first, but I'm glad to hear that it's working now.

    david613 said:
    So, assuming I can identify the thing I'm hoping to could you suggest a small product that could handle the communication protocols that's compatiable with raspberry pi?  If not raspberry pi arduino?

     Sorry, but I'm not sure I understand the question here. Can you try to elaborate? Newer Pi's come with built-in BLE support, but you can also plug-in a nRF52840 Dongle to work with both Zigbee and Thread.

  • Sorry for the slow responce Vidar,

    I agree it would have been satisfying to know what was going wrong, but I suppose it could at least be a basic method to get it working if anyone else has a similar problem.  Defiantly not an ideal solution but it seems to work.

    That was a very vague question, I believe I found the communication stream I'm looking for, and it gives two separate protocols.  When it  is acting as a beacon (source address 00:23:f7:45:ee:19:6c:50 no addressed destination) it shows the protocol is IEEE 802.15.4 which is what I expected to find.  When it is performing a data transfer (source address 00:23:f7:23:a4:73:a7:f1 and destination address 00:23:f7:45:ee:19:6c:50) it says the protocol is lwmesh.  I've tried googling to find more information about what the lwmesh protocol is but either didn't find anything talking about what I was looking for or I just don't know enough of the basics to understand what it was saying, for all I know the two protocols are exactly the same and just labelled differently.

    All that being said, what I'm looking to do is create a small and easily portable contained package that can intercept and process the transmissions (it's for a blood sugar reading device, I've written some scripts in R that pretty effectively predict whether the blood sugar is going to go high or low but obviously that would be most useful if i can carry it with me on a regular basis.  I'm pretty familiar with the raspberry pi and my first choice would be to use a pi zero simply because I wouldn't have to learn to use an entirely new hardware platform.  However, if that doesn't end up being practical I could figure out how to port it to an arduino platform.  I had considered simply using the dongle but I would end up soldering it together so they could stack without the dongle sticking out.  ideally I would like to have a solution that would be somewhat smaller then the dongle and could communicate via the GPIO on the pi.

    Also as long as I've got you, I was trying to decode the transmissions using wireshark but haven't been able to get it set up and working.  I'm fairly certain that the 'key' is going to be the 10 character serial number of one of the devices.  Could you recommend any really basic guide to wireshark for that, or even better a separate package (python, shell, etc.) that could do the decoding?

    Thanks so much for all the help,

    David

  • I suppose lwmesh is referring to this proprietary protocol by Atmel: https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/Atmel%20Lightweight%20Mesh.  I'm not familiar with this protocol, but I think the first step should probably be to find out if the specification specifies how data is encrypted. Wireshark also seems to have support for this protocol - maybe it supports decryption if you provide the correct key like it does for Zigbee and Thread.

Reply Children
Related