I have run the MSDDisable command (and alternatively MSDEnable) on both OSX and Windows 7, getting "Probe Configured Successfully" in all cases.

I do see that the USB drive representing the dongle goes away after the MSDDisable and reappears with MSDEnable.

After running MSDDisable, I get the same non-response from the terminal apps:

On OSX using "screen cu.usbmodem1461 460800" I get a screen window with no characters as before

On Windows using puTTY, connecting to "COM18"- the JLink USB serial port at 460800, I get a similar result... a blank terminal window with no response to typing and no characters displayed (and no apparent way to exit the terminal session)

I've copied the contents of your new code into the ...\extcap folderno change in visibility of the interface in WireShark.

I ran through the "Troubleshooting" steps in nRF_Sniffer_User_Guide_v2.1.All steps gave appropriate success results, except "screen port 460800" (same blank, unresponsive screen) and WireShark - with no evidence of the interface.

I was having issues with Wireshark not showing the extcap interface in it's UI on Mac OS X 10.13.5, even though the files were in the correct location, inside the .app /Applications/Wireshark.app/Contents/MacOS/extcap/

While trying to debug the issue, i decided to run wireshark directly from my shell to see any possible output via /Applications/Wireshark.app/Contents/MacOS/Wireshark

Turns out, this was enough to get nrf_sniffer.py to load, so if you've been having trouble getting it to load, it might be worth running the executable directly from Terminal.app

I suspect it has something to do with environment variables that Wireshark inherits from the shell, but haven't debugged further.

EDIT: Turns out, the best way to fix this so regular app launches work was to change the shebang at the top of nrf_sniffer.py to point directly to your local python2 instance. For me, this was #!/usr/local/bin/python2