It looks like the last discussion of Sniffer on Devzone was 2-3 yrs ago.
I’ve ordered the nRF Dongle and will download the Windows-based nRF Sniffer app.
i can run this with WireShark on a Windows VM on my Mac, though I would like a Mac OSX option.
- Any news on that front?
- Any way the Bluetooth hardware built into the MacBook could serve a Mac Sniffer app?
Still looking for a solution here. I think a few others are having the same trouble.
Martin Lesund, what is the next steps?
Can you summarize your versions so I can look at it.
OS Version:Wireshark version:Python version:Pyserial version:
Segger jlink version on PC:Segger jlink version or build date on the jlink emulator on nRF5x-DK:nRF Sniffer version:
PCA board number:
Python 32 bit or 64 bit:
8 -> 64 bit4 -> 32 bit
We need to see some characters on the screen when connecting to the board from OS X.
"screen <port> 460800"
If that does not happen then
Action 1:we need to do this in addition (we will attempt to disable the mass storage device to see if this improves the situation.
We attempt to see the characters when connecting to the board on windows. In addition can you connect to the board in Windows using termite or other terminal application at 460800 to verify that the port is accessible and that characters are coming out of it.
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)
Can you also ensure that you have an advertiser running in the neighbourhood ? You can get the advertiser running using nRF connect or some other BTLE application on the phone.
I have placed a patched sniffer python fileset that could fix this for you in my original answer. Can you try it and let me know if this is fixed.
Thanks for working on this, David Edwin!
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'm still open for a screen-share - 24/7.
Can you try the screen option on all the the DKs that you have, I see that a PCA10031 and a PCA10040 were mentioned.
OK. I'll try that tomorrow (Tuesday US Central time) with:- Python 2.7.14- pyserial (3.2.1)- SEGGER J-Link Commander V6.16c (Compiled Jun 16 2017 18:19:39) DLL version V6.16c, compiled Jun 16 2017 18:19:20- WireShark Mac OS Version 2.4.5
In separate sessions, I'll use each device (nRF dongle-PCA10031 and DK-PCA10040) and flash them using the appropriate parameters in JLINKEXE to "erase..." as in the Sniffer 2.1 User Guide.
Then in OSX Terminal, I'll run "screen <port> 460800" and report the results.
Have I got it?
OK, I've run the above with no luck on either board.
I'm wondering where to go next.
I've been through the steps many times.
Are others experiencing this problem?Is so, what is your environment?
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
Wow! This appears to be the magic bullet. With that one change to the nrf_sniffer.py file, I now see this when launching Wireshark.
I'll check this more thoroughly tomorrow, end-to-end, and with the otherwise-default installation options.
Thanks a million! I'll validate the answer after that checking.