nrf802154_sniffer.py doesn't exit on macOS when the capture is stopped

[nickrbogdanov]

I'm using the latest version of this repo with Wireshark 4.0.4 on macOS.

When I start a capture, it populates Wireshark with 802.15 packets (as expected). But when I click Stop, it waits about 30 seconds and then pops up this error:

During the 30 second lag, I'm not able to start a new capture and I can see in ps that the sniffer script hasn't been terminated.

If I add os._exit(0) at the top of the sig_stop_handler() function, it makes this error go away. I verified that sig_stop_handler() is being called from MainThread.

I don't understand the mechanism through which the control_reader loop is supposed to exit when Wireshark terminates the capture. Don't we need to signal it somehow to tell it to exit, before calling join() on that thread?

[WayneKeenan]

I just upgrade to Wireshark Version 4.2.4 (v4.2.4-0-g1fe5bce8d665) from v3.x (where it didn't occur) and this is still occurring.

[WayneKeenan]

This is the error I get:

Error from extcap pipe: 2024-05-06 14:43:59,084 [ERROR] Cannot write to Nrf802154Sniffer (/dev/cu.usbmodem1101) channel 18
2024-05-06 14:43:59,085 [ERROR] Cannot write to Nrf802154Sniffer (/dev/cu.usbmodem1101) channel 18
2024-05-06 14:43:59,645 [WARNING] Asked to stop Nrf802154Sniffer (/dev/cu.usbmodem1101) channel 18 while it was already stopped
2024-05-06 14:44:09,087 [ERROR] Failed to stop thread Thread-1 (control_reader)
Exception in thread serial_reader:
Traceback (most recent call last):
  File "/opt/homebrew/Cellar/python@3.12/3.12.3/Frameworks/Python.framework/Versions/3.12/lib/python3.12/threading.py", line 1073, in _bootstrap_inner
    self.run()
  File "/opt/homebrew/Cellar/python@3.12/3.12.3/Frameworks/Python.framework/Versions/3.12/lib/python3.12/threading.py", line 1010, in run
    self._target(*self._args, **self._kwargs)
  File "/Applications/Wireshark.app/Contents/MacOS/extcap/nrf802154_sniffer.py", line 389, in serial_reader
    raise Exception(msg)
Exception: Nrf802154Sniffer (/dev/cu.usbmodem1101) channel 18 did

[WayneKeenan]

It also occurs with the system/Apple python:

Error from extcap pipe: 2024-05-06 14:48:58,598 [ERROR] Cannot write to Nrf802154Sniffer (/dev/cu.usbmodem1101) channel 18
2024-05-06 14:48:58,599 [ERROR] Cannot write to Nrf802154Sniffer (/dev/cu.usbmodem1101) channel 18
2024-05-06 14:48:58,708 [WARNING] Asked to stop Nrf802154Sniffer (/dev/cu.usbmodem1101) channel 18 while it was already stopped
2024-05-06 14:49:08,603 [ERROR] Failed to stop thread Thread-1
Exception in thread serial_reader:
Traceback (most recent call last):
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/threading.py", line 973, in _bootstrap_inner
    self.run()
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/threading.py", line 910, in run
    self._target(*self._args, **self._kwargs)
  File "/Applications/Wireshark.app/Contents/MacOS/extcap/nrf802154_sniffer.py", line 391, in serial_reader
    raise Exception(msg)
Exception: Nrf802154Sniffer (/dev/cu.usbmodem1101) channel 18 di

[WayneKeenan]

I had a quick look and I it looks like the use of a non-blocking FIFO read in control_read and retry handling logic would help with timely thread cleanup.

[Chapoly1305]

Please give this patch a try, I think it fixed the issue. Chapoly1305/nRF-Sniffer-for-802.15.4@master...Chapoly1305-patch-1

I have tested it on my Ubuntu 22.04, it can now stop once click Stop on toolbar.

[WayneKeenan]

Thanks, but it still errors on my Mac: Error from extcap pipe: 2024-05-06 17:15:16,117 [ERROR] Failed to stop thread Thread-1 (control_reader)

[Chapoly1305]

Please ensure you have used correct branch and updated your local file (/Users/YOUR_USERNAME/.local/lib/wireshark/extcap), I just tested on my macbook, it seems working just fine.

For your convenience, you may use this py file directly.
nrf802154_sniffer.py.zip

[WayneKeenan]

my bad, somehow a symlink turned into a copy of the file. Only had to apply the fix in #60

thank you.