Inconsistent Serial Communication with PM3 on macOS

[digitalentropy]

Okay, this is a bit of a harder issue to describe, and I've been trying to figure out a good way to document it before I opened this issue, but have been unsuccessful so far. Perhaps I can borrow a USB protocol analyzer from a colleague and see if I get any good data that way.

For quite some time now, about two years at least, whenever I've compiled the client on macOS I've been observing what seems to be an issue with the client going "out of sync". When I first open the client, the first two or three commands execute fine, but with each successive command, the responses take longer and longer and longer, until I'm waiting upwards of 10 - 15 seconds for something as simple as "lf search" or to finish. The delay appears to apply to all commands, both LF and HF. My current "workaround" is to constantly exit and restart the pm3 client every few commands, which is less than ideal.

It could be an issue with a library being used on macOS since I've never observed this when compiling on other platforms or within a VM.

With the latest code versions the problem has gotten particularly bad which is what prompted this ticket, so I will do my best to document more and isolate.

[pwpiwi]

Why does the same device take longer to respond when queried by Linux compared to Windows?

[merlokk]

Maybe proxmark respond wo time Output but timeout was added by low level Linux driver? There are 2 paths:

1. Hardware USB logic analyser (ill look if it can be done by selae8 on monday)
2. Simply you can measure time on answer from proxmark side

[iceman1001]

[14651.188644] usb 3-13.2: device descriptor read/64, error -110

The get device descriptor failed hence the OS host must retry the enumeration process. Which takes time, but 5seconds is long Question is why this call fails.

with icemanfork, has the same issue on ubuntu16.04,
the pm3 implementation also ignores "set_line_coding" (or set baud rate seen a few posts above) is this will also be issues for the different OS implementations. There is a quite few differences from proper USB cdc_acm implementations, so I tend to think like @cjbrigato the older pm3 implementation was good enough and worked.

[cjbrigato]

One more here for the older pm3 implementation from 2016. If i remember correctly, I posted http://proxmark.org/forum/viewtopic.php?id=3801 then @pwpiwi corrected it a bit and merged this in master. This was good, and even the near only implementation that used to work with embeded devices CDC_HOST implementation (such as STM32 etc)

[pwpiwi]

[14651.188644] usb 3-13.2: device descriptor read/64, error -110

https://stackoverflow.com/questions/13653692/device-descriptor-read-64-error-110 https://superuser.com/questions/719302/trying-to-restore-data-usb-drive-not-properly-detected

?

[merlokk]

Is this line [14646.116202] usb 3-13.2: new full-speed USB device number 63 using xhci_hcd from connecting proxmark? i dont see reset command after fail enumeration. Maybe its ok?

[iceman1001]

well.. its a USB3 port and maybe it doesn't have power enough? and need to reset it down to usb2.0 over a usb3.0 ?.. The issue is the time delays, I get the impression that the device works.

[digitalentropy]

Correct. The device “works” but with longer and longer communication delays, often to the point of becoming unusable.

On Oct 22, 2017, at 5:46 PM, Iceman notifications@github.com<mailto:notifications@github.com> wrote:

well.. its a USB3 port and maybe it doesn't have power enough? and need to reset it down to usb2.0 over a usb3.0 ?.. The issue is the time delays, I get the impression that the device works.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Proxmark/proxmark3/issues/283#issuecomment-338487256, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABWMvpSOlAc-r6KFpaR8uBs_6rKOmD5Eks5su2NGgaJpZM4NDc-x.

[merlokk]

Is it reproduced in windows? ever reproduced?

[digitalentropy]

I have not observed symptoms in Windows, but I don’t know that is because the issue does not manifest in Windows or if it’s because Windows doesn’t care.

On Oct 22, 2017, at 7:53 PM, Oleg Moiseenko notifications@github.com<mailto:notifications@github.com> wrote:

Is it reproduced in windows? ever reproduced?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Proxmark/proxmark3/issues/283#issuecomment-338496155, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABWMvlxRUpn0DgB9Dqge82_nKD3P8JAGks5su4EogaJpZM4NDc-x.

[iceman1001]

So, it still manifests on OSX?

[digitalentropy]

It appears to, yes. I’ve observed several new clean installs on other people’s machines that exhibit this behavior, as of a couple weeks ago.

On Oct 22, 2017, at 9:09 PM, Iceman notifications@github.com<mailto:notifications@github.com> wrote:

So, it still manifests on OSX?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Proxmark/proxmark3/issues/283#issuecomment-338501283, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABWMvrrVdxqjhqwK4fGKvCAiWl_N8s76ks5su5LNgaJpZM4NDc-x.

[Kaicastledine]

Indeed, seems I've also got the issue on OSX High Sierra as we speak.

Anything that might be good to test that I can help with ?

[Kaicastledine]

Is the performance better via a windows/linux VM ? I've seen it mentioned but not sure as it would still be essentially running via the mac itself

[iceman1001]

Does this issue still apply? or has it been fixed?

[digitalentropy]

I believe as of two weeks ago it was still a problem. Has a specific fix been submitted to test?

On Nov 30, 2017, at 5:05 AM, Iceman notifications@github.com<mailto:notifications@github.com> wrote:

Does this issue still apply? or has it been fixed?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Proxmark/proxmark3/issues/283#issuecomment-348169722, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABWMvoY253nveeyL-R6ZOOQowuCjhiqFks5s7poIgaJpZM4NDc-x.

[iceman1001]

... and what happend to the comment from arcsur..

I always wondered why OSX uses /dev/cu.usbmodemXXXX instead of tty like all the other *inx based OS.

[pwpiwi]

@arcsur wrote:

I have found that the serial character device type seems to cause this issue.

Using the /dev/cu.usbmodemXXXX device exhibits the slowdown. Using the /dev/tty.usbmodemXXX device does not exhibit the problem.

[iceman1001]

if that tip works, we should change the wiki and readme, pages... And close this one :)

[cjbrigato]

Hello. In my book things are more complex than just cu vs tty. A lot of time cu is best bet if not facing a modem Difference between cu and tty OSX BSD-derivative is a matter of modem and uucp legacy. As a rule of thumb : cu gives exclusive access to the device. Tty does not.

[cjbrigato]

http://lists.berlios.de/pipermail/gpsd-dev/2005-April/001288.html :

The idea is to supplement software in sharing a line between incoming and outgoing calls. The callin device (typically /dev/tty*) is used for incoming traffic. Any process trying to open it blocks within the open() call as long as DCD is not asserted by hardware (i.e. as long as the modem doesn't have a carrier). During this, the callout device (typically /dev/cu* -- cu stands for "calling unit") can be freely used. Opening /dev/cu* doesn't require DCD to be asserted and succeeds immediately. Once succeeded, the blocked open() on the callin device will be suspended, and cannot even complete when DCD is raised, until the cu device is closed again.

That way, you can have a getty listening on /dev/tty*, and can still use /dev/cu* without restrictions.

[iceman1001]

that was a informative answer. still, how to solve this one?

[cjbrigato]

Cant tell since I've lever been able To reproduce this issue during any stage of ils lifecycle. Last use on high Sierra never exhibited the issue. Anyway if multiple threads are to make call to the device (In term of kernel syscalls) better choose wisely how and to what device, or having a dedicated thread for this stack . Other common problem is misbehaving of the cdc-acm stack because of other kext. I'm thinking first of unofficial cp2102 and prolifics like, but more than any other I'm quite sure that any one with a Samsung device >= galaxy s3 having once installed a Samsung product,or Horndis to their mac Will definitely rum in one or alike of this issue. Solvable case specifically.

[TomHarkness]

Strange.. I just noticed after needing to compile with the gui that I now have no lag. Lets see if something messes this up over time. Maybe this is only after reboot or something.

[digitalentropy]

I can state that as recently as last month I’ve still observed other folks experiencing this perceived latency issue after compiling for OS X using instructions from the Wiki.

I currently do not have direct access to a macOS device to continue testing.

From: Tom Harkness notifications@github.com Sent: Friday, August 31, 2018 5:09 PM To: Proxmark/proxmark3 proxmark3@noreply.github.com Cc: Babak Javadi omikron@brokenpixel.net; Mention mention@noreply.github.com Subject: Re: [Proxmark/proxmark3] Inconsistent Serial Communication with PM3 on macOS (#283)

Strange.. I just noticed after needing to compile with the gui that I now have no lag. Lets see if something messes this up over time. Maybe this is only after reboot or something.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Proxmark/proxmark3/issues/283#issuecomment-417817745, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABWMvsgJ2-YEMucn9rwE1RtsZGGhvusuks5uWdAngaJpZM4NDc-x.

[TomHarkness]

Yes still seeing issues on my end too. It seems to run fine on first run after installing XQuartz but then starts lagging badly and having serious issues after sleep / log off / reboot. Unfortunately I need the graph for stuff that I am working on so have been putting up with the client bugging out every 3 mins.

[pwpiwi]

Does anybody know of another fork which works?

[TomHarkness]

All forks work fine IF you compile without the gui. Either edit the relevant section in the Makefile or remove the path links to the QT lib folder shown below.

Type "export" in your terminal.

See the following lines: (path may differ depending on version)

declare -x PKG_CONFIG_PATH="/usr/local/Cellar/qt/5.11.1/lib/pkgconfig/" declare -x QT_PKG_CONFIG_QT5CORE="/usr/local/Cellar/qt/5.11.1/lib/pkgconfig/Qt5Core.pc"

remove them with the "unset" command:

unset PKG_CONFIG_PATH unset QT_PKG_CONFIG_QT5CORE

Let us know how this goes for you.

[pwpiwi]

Does anybody know of another fork which works with OS X and the GUI?

[TomHarkness]

Nope. Not in existence right now. We need OS X users to help fix the bug. I would but I am working on other things and don't quite have time at the moment. It is usable but you've just got to get the hang of recognising when its bugging out and restart the client.