# How to troubleshoot extcap when no error?

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}


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 ... edit retag 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. ( 2021-03-11 23:59:03 +0000 )edit ## 1 Answer Sort by » oldest newest most voted 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. 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. ( 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. ( 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.

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