Ask Your Question
0

How to troubleshoot extcap when no error?

asked 2021-03-11 22:13:42 +0000

jaraco gravatar image

updated 2021-03-11 23:57:04 +0000

Attempting to enable BLE capture, I've downloaded and installed the latest nrf_sniffer (3.1.0) from Nordic Semiconductor and copied the nrf_sniffer_ble.py and SnifferAPI files to the extcap path (both system and user) and confirmed they work from the command-line, yet still the interface doesn't appear in Wireshark 3.4.4.

Here's the output from extcap:

extcap $ pwd
/Users/jaraco/.config/wireshark/extcap
extcap $ ./nrf_sniffer_ble.py --extcap-interfaces
extcap {version=3.1.0}{display=nRF Sniffer for Bluetooth LE}{help=https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE}
interface {value=/dev/cu.usbserial-0213648D}{display=nRF Sniffer for Bluetooth LE}
interface {value=/dev/cu.SLAB_USBtoUART}{display=nRF Sniffer for Bluetooth LE}
control {number=0}{type=selector}{display=Device}{tooltip=Device list}
control {number=1}{type=string}{display=Passkey / OOB key}{tooltip=6 digit temporary key or 16 byte Out-of-band (OOB) key in hexadecimal starting with '0x', big endian format. If the entered key is shorter than 16 bytes, it will be zero-padded in front'}{validation=\b^(([0-9]{6})|(0x[0-9a-fA-F]{1,32}))$\b}
control {number=2}{type=string}{display=Adv Hop}{default=37,38,39}{tooltip=Advertising channel hop sequence. Change the order in which the siffer switches advertising channels. Valid channels are 37, 38 and 39 separated by comma.}{validation=^\s*((37|38|39)\s*,\s*){0,2}(37|38|39){1}\s*$}{required=true}
control {number=3}{type=button}{role=help}{display=Help}{tooltip=Access user guide (launches browser)}
control {number=4}{type=button}{role=restore}{display=Defaults}{tooltip=Resets the user interface and clears the log file}
control {number=5}{type=button}{role=logger}{display=Log}{tooltip=Log per interface}
value {control=0}{value= }{display=All advertising devices}{default=true}

So clearly, interfaces are recognized. Yet, when I restart Wireshark or refresh the interfaces, a relevant interface does not appear in Wireshark.

If I delete one of the provided extcap plugins and refresh, it disappears from the list, and if I restore the plugin and refresh, the interface once again appears. It's only the nrf sniffer ble that fails to appear.

I've made the file executable (ugo+x). I've tried renaming the file with and without and extension. I've tried troubleshooting by replacing the script with something that emits output to the file system, but the output never appears. It's as if anything but the standard plugins are never run. I've tried enabling the "console" to "ALWAYS" open, but I don't see any console.

What other options do I have to troubleshoot an extcap that's silently failing but working in the terminal?

Edit: Folders config:

~ $ tshark -G folders
env: python3\r: No such file or directory
env: python3\r: No such file or directory
Temp:                   /var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/
Personal configuration: /Users/jaraco/.config/wireshark
Global configuration:   /Applications/Wireshark.app/Contents/Resources/share/wireshark
System:                 /etc
Program:                /Applications/Wireshark.app/Contents/MacOS
Personal Plugins:       /Users/jaraco/.local/lib/wireshark/plugins/3-4
Global Plugins:         /Applications/Wireshark.app/Contents ...
(more)
edit retag flag offensive close merge delete

Comments

Oh, that's interesting. I notice that tshark -G folders emits an error. "python3\r: No such file or directory." That seems likely implicated.

jaraco gravatar imagejaraco ( 2021-03-11 23:59:03 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-03-12 00:10:25 +0000

jaraco gravatar image

updated 2021-03-12 00:19:20 +0000

Aha! That's the issue. The suggestion (which seems to only have come through email and not through the interface here) to use tshark -G folders to examine the folders gave a clue as to why the binary seemed to be ignored. The Python file is terminated with Windows newlines (\r\n) and it seems that when that's the case, the shebang isn't parsed properly by Wireshark, even though it's parsed properly by my shell. I converted the Python file to Unix newlines and now tshark -G folders no longer shows an error (even though it _still_ doesn't show ~/.config/wireshark/extcap), and Wireshark now displays the Sniffer when present.

I think there may be some defects underlying this trouble I encountered. In particular, I'd recommend:

  • Wireshark should provide a debug mode or troubleshooting UI for processing extcap (log each one as its loaded and any errors encountered).
  • tshark -G folders should probably present the same values as what's in the UI.
  • Wireshark should honor Windows newlines when parsing a shebang even on Unix.
edit flag offensive delete link more

Comments

Wireshark should honor Windows newlines when parsing a shebang even on Unix.

Wireshark doesn't parse the shebang - the {Linux,macOS,*BSD,Solaris,AIX,HP-UX,...} kernel does.

I suppose Wireshark could, if it gets ENOEXEC back, open the file, try to read a line from it and, if it looks like a shebang terminated with CR-LF, extract the program and argument and run the program itself, but that's all it can do about the CR-LF.

And that works only if the script interpreter itself can handle CR-LF line endings when running on UN*X.

Guy Harris gravatar imageGuy Harris ( 2021-03-12 04:24:40 +0000 )edit

I tried a simple script with "#! /bin/sh<cr><>F>" as the first line and "echo This file has CR-LF line endings<cr><lf>" as the second line; it didn't run on macOS or Linux ("-bash: /tmp/scriptolio: /bin/sh^M: bad interpreter: No such file or directory"). In both cases, the shell presumably saw the ENOEXEC it got back from the exec or posix_spawn call and tried opening the file and interpreting it by itself. I guess bash also tries to handle #!, but the CR at the end of the line was treated as part of the interpreter path, and no file named "sh<cr>" existed in /bin, so it failed.

Guy Harris gravatar imageGuy Harris ( 2021-03-12 05:34:33 +0000 )edit

Indeed. Apparently my shell (xonsh) is special.

draft $ bash -c ./script.sh
bash: ./script.sh: /bin/sh^M: bad interpreter: No such file or directory
draft $ zsh -c ./script.sh
zsh:1: ./script.sh: bad interpreter: /bin/sh^M: no such file or directory
draft $ xonsh -c ./script.sh
ends in crlf

So that indicates that perhaps Wireshark is following the status quo, and the main reason the command worked for me (and thus I was unable to detect the issue) was because my shell was lenient to this non-standard form, and the reason it works for most users is because they rely on the .bat or .sh files before executing the python script, but I'd removed those for simplicity sake.

(aside: please consider upvoting my question/answer so I may have enough points to do the same for your helpful comments)

jaraco gravatar imagejaraco ( 2021-03-12 13:45:55 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-03-11 22:13:42 +0000

Seen: 128 times

Last updated: Mar 12