method to sniff usb-serial communication on osx

On windows, there are several decent alternatives (mostly paid) which allow you to monitor serial port communications. On OSX there are lots of terminal applications which let you talk to serial devices but I haven't found a mechanism to monitor serial port communication.

The specific use case is:
I have a USB-Serial device that lives on /dev/tty.usbmodem99999

I have written an integration test that runs multiple commands (successfully).

However on re-running the command the device does not respond. I've confirmed (as well as I can) that the device is fine. It works on other platforms as expected. However on OSX I can only re-run the tests after resetting the device (power cycle).

My theory is that my code is not releasing the device properly but that's hard to confirm when I can't see the communication between my device and my application.

This application: "http://www.aggsoft.com/serial-port-monitor.htm" has a 'spy' feature that I have been unable to find similiar functionality to on OSX. I've experimented with 'serial tools' on osx, but it doesn't look like it does spy operations on a single port, in that case it looks like the use case is as a passthrough between two devices rather than monitoring at the port.

Any thoughts greatly appreciated.

serial library being used is:
https://github.com/jacobsa/go-serial

Have you used DTrace?

I have used it to monitor USB comms between an FTDI USB/serial converter and a 3rd party 'Black Box' application. So I could get at everything that the application sent to the USB serial port.

That was pretty straightforward because I knew the name of the application, so DTrace could observe that. I wrote DTrace script to observe the file descriptors the application opened, (looking for the '/dev/tty.usbmodem...') then observed interactions with that file descriptor.

I have not observed a device driver. In principle DTrace can do that if the kernel or device driver is compiled to work with DTrace, though there is no certainty that it is. Apple can also build code which is 'invisible' to DTrace (for example I believe iTunes was made opaque to DTrace to protect its DRM mechanisms.)

So one possible starting point is to observe all OS open/creat calls, looking for /dev/tty.usbmodemXXX, and try to identify the subsystem and observe that. You may find that the subsytem can be observed, and that should help see what the OS+device driver is doing.

This isn't trivial. If your time has any value, it may be cheaper and more reliable to get a hardware USB sniffer and put it into the cable, especially if its only 1.2Mbits or 12MBits USB (sniffers are much more expensive for higher data rates).

These links may help:
About DTrace
DTrace Guide
DTrace book
Brendan Gregg's Top 10 DTrace scripts for Mac OS X
Apple DTrace manual
Hooked on DTrace