Metoda sniff komunikacji usb-serial na osx

Question

W systemie Windows istnieje kilka przyzwoitych alternatyw (głównie płatnych), które pozwalają monitorować komunikację portu szeregowego. Na OSXie jest wiele aplikacji terminalowych, które pozwalają rozmawiać z urządzeniami szeregowymi, ale nie znalazłem mechanizmu do monitorowania komunikacji portu szeregowego.

Konkretny przypadek użycia jest: Mam urządzenie USB, szeregowy, który żyje na /dev/tty.usbmodem99999

Pisałem test integracyjny, który działa wielu poleceń (z powodzeniem).

Po ponownym uruchomieniu polecenia urządzenie nie odpowiada. Potwierdziłem (tak dobrze jak mogę), że urządzenie jest w porządku. Działa na innych platformach zgodnie z oczekiwaniami. Jednak w systemie OSX mogę ponownie uruchomić testy po zresetowaniu urządzenia (cykl zasilania).

Moja teoria mówi, że mój kod nie zwalnia urządzenia prawidłowo, ale trudno to potwierdzić, gdy nie widzę komunikacji między urządzeniem a aplikacją.

Ta aplikacja: "http://www.aggsoft.com/serial-port-monitor.htm" ma funkcję "szpiega", której nie mogłem znaleźć na OSX. Eksperymentowałem z "narzędziami szeregowymi" na osxie, ale nie wygląda na to, że wykonuje operacje szpiegowskie na jednym porcie, w takim przypadku wygląda na to, że przypadek użycia jest przekazywany między dwoma urządzeniami zamiast monitorowania w porcie .

Wszelkie przemyślenia są bardzo cenne.

biblioteka seryjny używany jest: https://github.com/jacobsa/go-serial

Answer 1

Czy korzystal DTrace?

Służyłem do monitorowania łączności USB między konwerterem USB/szeregowym FTDI a aplikacją "Czarna skrzynka" innej firmy. Tak więc mogłem uzyskać na wszystko, co, że aplikacja wysłana do portu szeregowego USB.

To było całkiem proste, ponieważ znałem nazwę aplikacji, więc DTrace mógł to zaobserwować. Napisałem skrypt DTrace, aby obserwować deskryptory plików otwartej aplikacji (szukając "/dev/tty.usbmodem ..."), a następnie obserwowałem interakcje z tym deskryptorem pliku.

Nie zaobserwowałem sterownika urządzenia. Zasadniczo DTrace może to zrobić, jeśli jądro lub sterownik urządzenia jest skompilowany do pracy z DTrace, choć nie ma pewności, że tak jest. Apple może także zbudować kod, który jest "niewidoczny" dla DTrace (na przykład wierzę, że iTunes został nieprzejrzysty dla DTrace, aby chronić jego mechanizmy DRM).

Jednym z możliwych punktów wyjścia jest obserwowanie wszystkich połączeń open/creat OS, patrząc dla /dev/tty.usbmodemXXX i spróbuj zidentyfikować podsystem i obserwuj to. Może się okazać, że subsytem można zaobserwować, a to powinno pomóc zobaczyć, co robi sterownik urządzenia OS +.

To nie jest trywialne. Jeśli twój czas ma jakąś wartość, może okazać się tańsze i bardziej niezawodne uzyskanie sprzętowego sniffera USB i umieszczenie go w kablu, zwłaszcza jeśli ma tylko 1,2 Mb/s lub 12 MB USB (sniffery są znacznie droższe dla wyższych szybkości transmisji danych).

Te linki mogą pomóc:
About DTrace
DTrace Guide
DTrace book
Brendan Gregg's Top 10 DTrace scripts for Mac OS X
Apple DTrace manual
Hooked on DTrace