Sniffer on OSX - revisited

[David Elvig]

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?

thanks!

[David Elvig]

Still looking for a solution here.  I think a few others are having the same trouble.

Martin Lesund, what is the next steps?

[David Edwin]

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:

Use: 

import ctypes
ctypes.sizeof(ctypes.c_void_p)

8 -> 64 bit
4 -> 32 bit

[David Elvig]

I've done the following:
- Identified the serial port with this partial ls from \dev: 

cu.Bluetooth-Incoming-Port	ttyv0
cu.LGHBS760-CSRGAIA		ttyv1
cu.MALS				ttyv2
cu.SOC				ttyv3
cu.usbmodem1451061		ttyv4
cu.usbmodem1461			ttyv5
disk0				ttyv6
disk0s1				ttyv7

    It is the "cu.usbmodem1461" entry that appear/disappears with plugging/unplugging the dongle

I typed the following into Terminal:      
        screen cu.usbmodem1461 46800

...resulting in:

No typed keystrokes show, and it responds only to the Ctrl-a-Ctrl-k command to quit.

[David Edwin]

The baud rate I suggested was 460800 (not 46800 as I see in your screen shot). 
Please connect to the port at 460800 and see if you are getting characters on the "screen".

Thanks

[David Elvig]

Thanks for your patience.

I get the same result as above with

"screen cu.usbmodem1461 460800"

Dave

[David Edwin]

That is a problem, can you try with other terminal programs like minicom and open the port at 460800. You need to see something on the UART. Turn on the hardware flow control if possible.

Actions:

1. Can you verify that the board is indeed working by flashing some example program like ble_app_uart and running those examples.

2, Can you also try with a different board 

3. Specify the board PCA10040 and the PCA10031 version numbers ?

4. Please stay on jlink 6.16c on the jlink emulator for all the experiments and actions.

Edit: Additional Action:

I checked if the jlink 6.16c for OS X and Windows are bundling the identical version of the jlink emulator firmware they are NOT. If you have a windows PC can you install jlink 6.16c and use the exec invalidatefw to set the jlink emulator firmware to what was bundled with jlink 6.16c for windows. Then use the board with OS X. Let me know if this is possible for you.

Edit : ping

[David Elvig]

I've done all but the minicom step.  I ran the Windows j-Link Configurator and it shows this screen

as in the sniffer 2.0 documentation

I ran j-Link Commander and with exec invalidatefw I get this

I said "no" since I think we're trying to stay on older builds... That said, I'm typing commands that I don't fully understand (I don't understand all of the layers involved)

I expect my hardware is working (both the dongle (PCA10031) and the Dev Kit (PCA10040)).  I can use the dongle without trouble using nRFConnect on the Mac, and the DK works well with example SDK apps, and my own MIDI BLE app.

I've stayed on the 6.16c version throughout (on Mac and Win)

I did not easily find how to install minicom on the Mac.

I did flash the Dev Kit board using the nRF52832_XXAA parameter to "erase"

No difference in Wireshark visibility.

Is there a chance of a screen-share where you could look over my shoulder, @David Edwin?

I expect it's a missed step on my part... I have two hardware options to try, and access to all of the various permutations of j-link, segger and Wireshark.

I'm available any time around the clock to make that happen (and have WebEx available for screen-sharing)

[David Edwin]

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. 

Action 2:

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.

[David Elvig]

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)

[David Edwin]

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.

[David Edwin]

David Elvig

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.

[David Elvig]

Thanks for working on this, David Edwin!

I've copied the contents of your new code into the ...\extcap folder
no 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.

Thanks again!

Dave