Sniff usb-serial communication method on osx

Question

There are several worthy alternatives in the windows (mostly paid) that allow you to monitor communication over the serial port. OSX has many terminal applications that allow you to talk to serial devices, but I have not found a mechanism to monitor communications through the serial port.

Specific use case: I have a USB serial device that lives on /dev/tty.usbmodem99999

I wrote an integration test that runs several commands (successfully).

However, when you run the command again, the device does not respond. I have confirmed (and also can) that the device is in order. It works on other platforms, as expected. However, in OSX, I can restart the tests after rebooting the device (power cycle).

My theory is that my code does not release the device properly, but it is difficult to confirm when I cannot see the connection between my device and my application.

This application: " http://www.aggsoft.com/serial-port-monitor.htm " has a "spy" function that I could not find on OSX. I experimented with "serial tools" in osx, but it doesn’t look like it performs spy operations on one port, in which case it looks like a transition between two devices, not monitoring on a port.

Any thoughts were greatly appreciated.

Serial Library Used

: https://github.com/jacobsa/go-serial

Answer 1

Have you used DTrace?

I used it to monitor USB communications between the FTDI USB / serial converter and a third-party Black Box application. So I could get everything that the application sent to the USB serial port.

It was pretty simple because I knew the name of the application, so DTrace could notice it. I wrote a DTrace script to monitor file descriptors opened by the application (looking for "/dev/tty.usbmodem ..."), and then watched interactions with this file descriptor.

I have not seen the device driver. In principle, DTrace can do this if the kernel or device driver is compiled to work with DTrace, although there is no certainty that it is. Apple can also create code that is "invisible" to DTrace (for example, I believe iTunes was opaque to DTrace to protect its DRM mechanisms.)

Thus, one of the possible starting points is to observe all open / creat OS calls, search for /dev/tty.usbmodemXXX, and attempt to identify the subsystem and observe this. You may find that a subtype can be observed, and this should help to see what the OS + device driver does.

This is not trivial. If your time matters, it may be cheaper and more reliable to get a hardware USB sniffer and put it in a cable, especially if it is only 1.2 Mbps or 12 Mbps USB (sniffers are much more expensive for higher data transfer speeds).

These links may help:
About DTrace
DTrace Guide
Dtrace book
Brendan Gregg Top 10 DTrace Scripts for Mac OS X
Apple DTrace Guide
Connected to DTrace