error EAGAIN from read() in fido_hid_read() during “fido2-token -I «device»” #850
Replies: 1 comment 9 replies
-
|
Hi,
It's not something we'd imagine seeing under normal operation. We're using a non-blocking pipe to read the data from the report callback;
You mentioned CCID, are you sure there is no other program/daemon polling the device over that interface? Have you tried killing the PCSC daemon? Do you have multiple devices plugged in at the same time when you get this issue? Could you show us the output of a successful run of Could you show us the output of Footnotes |
Beta Was this translation helpful? Give feedback.
-
After building and installing the $ fido2-token -V && FIDO_DEBUG=1 fido2-token -L
$ FIDO_DEBUG=1 fido2-token -L
$ FIDO_DEBUG=1 fido2-token -L
So far, so good, as far as I can tell; three runs produced the same (non-debugging) output line. The next command was $ fido2-token -I ioreg://4295028539 This command produced no output for a few minutes before I’d interrupted it. After interrupting it, I’d added the $ fido2-token -d -I ioreg://4295028539 The ’539 output looks like it contains an expected result. I then tried it twice without the $ fido2-token -I ioreg://4295028539
$ fido2-token -I ioreg://4295028539
Leaving the plugged-in YubiKey in place, I then inserted the second YubiKey and reran the $ FIDO_DEBUG=1 fido2-token -L
which looks good. I then ran the $ fido2-token -I ioreg://4295028636
$ fido2-token -I ioreg://4295028636 The first run’s output looked good, but no output was produced in the first few minutes on the second run. I interrupted that run, and decided to rerun it by bracketing it with start and end times to see how long it might take for output to be emitted: $ date -u && fido2-token -I ioreg://4295028636 ; date -u
I interrupted it after twenty minutes without output. I then repeated this command line, but added a The presence of long periods of time without output from To my knowledge, no other program was trying to access the YubiKeys during this time; I didn’t run |
Beta Was this translation helpful? Give feedback.
-
|
Thanks.
The implementation in that branch polls the run loop differently, giving it more chances to fire the callback and effectively has an infinite timeout waiting for the data to be delivered. Unfortunately, it's not entirely unsurprising that you'd see no output instead of |
Beta Was this translation helpful? Give feedback.
-
What is the oldest version of OS X that you’d successfully tested? (If the source for its CCID version is publicly available, I might be able to port its version of CCID to OS X 10.9.5 to see if that would make a difference.)
It’s certainly a possibility. After a similar testing régime as before, but only using the $ date -u && fido2-token -d -I ioreg://4295033999 ; date -u
Apparently the “hanging” occurs after the first |
Beta Was this translation helpful? Give feedback.
-
To be clear, we do not use CCID to communicate with the authenticator, but USB HID. OS X 10.9.5 was EOL before the first release of libfido2 if I recall correctly. We'll keep trying to reproduce this on currently supported versions of OS X. Paging in @martelletto; have you seen anything like this in the past?
Yes, at the same place you'd previously see |
Beta Was this translation helpful? Give feedback.
-
|
Apologies for the delay on this. Yes, macOS 10.9.5 predates libfido2's first release, and I don't think libfido2 was ever tested or known to work with 10.9.5. This is the first time I hear about this issue, and the symptoms are consistent with @LDVG's analysis. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello, all,
I recently purchased two YubiKey 5 NFC devices. My old computer still runs OS X 10.9.5, so I compiled and installed a more recent version of CCID on it to allow it to recognize the YubiKeys. I’ve also compiled an OS X 10.9.5-friendly version of libfido2 1.15.0 by providing my own clock_gettime() call, since Apple didn’t provide its own clock_gettime() call until macOS 10.12.
When I run “fido2-token -I «device»” on my computer against either YubiKey, output such as this is often emitted:
$ fido2-token -V && fido2-token -L
$ fido2-token -I ioreg://4295015390
$ fido2-token -d -I ioreg://4295015390
Is
EAGAINa common error that is returned from the read() call in the fido_hid_read() function ofsrc/hid_osx.c? It seems to happen quite frequently when I run the “fido2-token -I «device»” command, and I’m not doing anything else with the YubiKeys when I run this command. [As an experiment, I increased the wait between calls to read() in the schedule_io_loop() function ofsrc/hid_osx.cfrom five seconds to ten seconds in case five seconds wasn’t enough time, but that didn’t seem to reduce the frequency of theEAGAINerror.]Beta Was this translation helpful? Give feedback.
All reactions