Discussion:
[Thinkfinger-devel] issues on x86_64?
Michael
2006-11-28 03:44:43 UTC
Permalink
I keep getting 'communication error' everytime I try to use thinkfinger, with
the tf-tool testing utility.

I added some code from the old thinkfinger.c file at line 377 of
libthinkfinger.c:

if (!(flags & SILENT)) {
fprintf(stdout, "Write: ");
printhex(ctrldata, len);

fprintf(stdout, "Read: ");
printhex(inbuf, real_len);
}

Doing that gets me:

$ sudo tf-tool/tf-tool
tf-tool: intialization... ok
tf-tool: setting file... ok
tf-tool: setting callback... ok
tf-tool: acquire fingerprint...
Write: 43 69 61 6f 00 60 08 28 05 00 00 00 00 30 01 49 6b
Read: 43 69 61 6f 00 50 07 28 04 00 ea fb 02 12 36 9b 01 00 04 00 08 0f 86 00 00 00 00 00 00 00 0a 00 0a 00 64 00 f4 01 32 00 00 00 00 10 00 00 04 00 02 00 02 00 08 00 93 0f 00 00 64 01 00 00 00 00
tf-tool: TF_STATE_COMM_FAILED (255)
tf-tool: communication error
tf-tool: verifying fingerprint...
Write: 43 69 61 6f 00 50 1d 28 1a 00 00 00 03 02 00 00 00 00 00 00 00 00 00 00 00 00 c0 d4 01 00 20 00 00 00 03 00 4f 47
Read: 43 69 61 6f 00 60 07 28 04 00 52 f7 f0 1f 49 ca 6b 00 04 00 08 0f 86 00 00 00 00 00 00 00 0a 00 0a 00 64 00 f4 01 32 00 00 00 00 10 00 00 04 00 02 00 02 00 08 00 93 0f 00 00 64 01 00 00 00 00
Write: 43 69 61 6f 00 60 08 28 05 00 00 00 00 30 01 49 6b
Read: 43 69 61 6f 00 50 07 28 04 00 ea fb 03 12 07 a8 00 00 00 00 00 00 00 00 00 00 c0 d4 01 00 20 00 00 00 03 00 3e 08 32 00 00 00 00 10 00 00 04 00 02 00 02 00 08 00 93 0f 00 00 64 01 00 00 00 00
tf-tool: TF_STATE_COMM_FAILED (255)
tf-tool: communication error


Same issues I had when playing around with thinkfinger.c before.

This is Gentoo x86_64 2006.1:

$ uname -a
Linux sony 2.6.18 #7 SMP Tue Nov 21 18:03:26 EST 2006 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux

My first thought is that it's an issue with my machine being 64bit - I've seen
reports of this stuff working on 32bit machines. Any thoughts? I'll keep
hacking at it, though it'd help to know why in parse() the result is always
0x07 (thus throwing TF_STATE_COMM_FAILED)... I'm just not sure what to expect
yet.
--
Michael Stella | IT Systems Architect | http://www.michaelstella.com/
PGP: 1024D/BC3FF6D4 2BC2 A79B 88D1 218A B32B ED7A 2EC2 1206 BC3F F6D4
"To dwell on the destination is to waste the journey"
Michael
2006-11-30 01:53:53 UTC
Permalink
Is your laptop a Sony, as the hostname indicates? There could be a
subtle BIOS, chipset or other hardware issue relating to the fact that
you may have a USB fingerprint reader in your laptop that is not
responsive to the same commands as the one on recent Lenovo Thinkpads.
However, based on my own tests above, I am pretty certain this is not
something about non-portable code.
Yeah, that's one reason I named it such, makes it easy.. It's a Sony
VGN-SZ370P/C. Same PCI device ID and all, supposedly the same device, people
say it works with the binary-only driver. I was hoping it wasn't about
non-portable code, but that was a place to start.

Any idea what we could compare in our laptops?
I guess we can expect that, at this very early stage of development, we
are going to get what appears to be a fatal communications error in the
event that there is in fact some user error.
True, but this isn't a user error - I didn't get prompted to swipe, it just
failed out before that point. It's that 0x07 I see there, the 6th byte, same
thing every time. I'm not sure what a lot of that stuff means yet, I've got
to go through the hardware documentation still... the little bit that I have
so far didn't lead me to anything yet, there's quite a lot of docs for their
API, but the hardware stuff still looks like "random bytes" to me at this
point :)
don't match eachother satisfactorily, etc. We should implement this in
libthinkfinger userland for easy access by later GUI applications which
can relay this information to the user. I was thinking an OSD library
may be ideal to provide this feedback during PAM authentication on
xdm/gdm/kdm. Feedback?
I like that idea, I use OSD quite a bit myself.

The library should just return what the hardware tells it, the userland should
figure out what it wants to do with that, depending on the program, some
errors may not be as important as others.
--
Michael Stella | IT Systems Architect | http://www.michaelstella.com/
PGP: 1024D/BC3FF6D4 2BC2 A79B 88D1 218A B32B ED7A 2EC2 1206 BC3F F6D4
Got my sights on the stars, won't get that far but I'll try anyway.
- Rush
Loading...