i have a problem

[ghost]

segmentation fault on the ./cli

[ghost]

maybe this helps

(gdb) run
Starting program: /home/william/fingerprint/andree182-vfs301-baab9d9/cli/cli
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__pthread_mutex_lock (mutex=0x63430b) at pthread_mutex_lock.c:51
51 unsigned int type = PTHREAD_MUTEX_TYPE (mutex);

[andree182]

Unfortunately that doesn't help much. Can you try command "backtrace" in the gdb, if it prints some additional stuff? If nothing is printed, you can still add some debug printf's to cli.c...

[andree182]

I will assume the problem is either gone or sir wvzimmer is gone :-) If there are further problems, please reopen the issue...

[MaximeCheramy]

Same here (VFS300) :

(gdb) bt
#0 __pthread_mutex_lock (mutex=0x20) at pthread_mutex_lock.c:50
#1 0x00007ffff7bd0e6f in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2 0x00007ffff7bd7fac in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#3 0x00007ffff7bd837e in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#4 0x00007ffff7bd10db in libusb_get_device_list ()
from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#5 0x00007ffff7bd1ec5 in libusb_open_device_with_vid_pid ()
from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#6 0x00000000004026da in usb_init () at cli.c:69
#7 0x0000000000402b24 in init (dev=0x60e9c0) at cli.c:188
#8 0x0000000000402ca7 in main (argc=1, argv=0x7fffffffe348) at cli.c:229

[MaximeCheramy]

To avoid the segfault, the following patch works. However, it doesn't seem to work for me (reading fingerprint and then nothing... blocking at vfs301_proto.c:64).

diff --git a/cli/cli.c b/cli/cli.c
index 4de42b9..5d51eed 100644
--- a/cli/cli.c
+++ b/cli/cli.c
@@ -67,7 +67,7 @@ static void usb_init(void)

      for (i = 0; i < sizeof(usb_ids_supported) / sizeof(usb_ids_supported[0]); i++) {
              devh = libusb_open_device_with_vid_pid(
-                       NULL, usb_ids_supported[i][0], usb_ids_supported[i][1]
+                       ctx, usb_ids_supported[i][0], usb_ids_supported[i][1]
              );
              if (devh != NULL)
                      break;

[andree182]

Hm, for me it looks like the patch (still) works, so what about you (other) guys, does it help? From the libusb documentation it seems like it shouldn't really matter, probably.

Other thing is that the integration with libfprint should be possible - so if it works there, maybe it's useless to debug this probably-not-so-much-used-in-the-near-future utility...

[MaximeCheramy]

Well, the device is now recognized but it does not seem to work, unfortunately. (talking about fprint_demo)

[andree182]

you could maybe add #define DEBUG to cli/vfs301_proto.c, and maybe also some debug prints to libfprint/vfs301.c - and check where it stops / first fails? If the vfs301_proto_init() is reached, you could post the debug output here, maybe there'll be some hint...

Just a note - do you have the access permissions set up? cli/Makefile should set it up, so this shouldn't be the cause of the problem - but who knows...

[MaximeCheramy]

% ./cli
send, rv 0, len 1

recv, rv 0, len 38

send, rv 0, len 39

recv, rv 0, len 6

send, rv 0, len 39

recv, rv 0, len 7

send, rv 0, len 1

recv, rv 0, len 64

recv, rv 0, len 4

send, rv 0, len 2401

recv, rv 0, len 2

send, rv 0, len 1

recv, rv 0, len 38

send, rv 0, len 1

recv, rv 0, len 2

send, rv 0, len 1905

recv, rv 0, len 2

send, rv 0, len 2247

recv, rv 0, len 2

recv, rv 0, len 256

recv, rv 0, len 32

send, rv 0, len 1

recv, rv 0, len 2

send, rv 0, len 785

recv, rv 0, len 2

send, rv 0, len 1

recv, rv 0, len 38

send, rv 0, len 2737

recv, rv 0, len 2

recv, rv 0, len 11648

send, rv 0, len 2529

recv, rv 0, len 2

recv, rv 0, len 53248

send, rv 0, len 2542

recv, rv 0, len 2

recv, rv 0, len 19968

send, rv 0, len 2768

recv, rv 0, len 2

recv, rv 0, len 5824

send, rv 0, len 2638

recv, rv 0, len 2

recv, rv 0, len 6656

send, rv 0, len 2651

recv, rv 0, len 2

recv, rv 0, len 6656

send, rv 0, len 570

recv, rv 0, len 2

recv, rv 0, len 832

send, rv 0, len 57

recv, rv 0, len 2

send, rv 0, len 1

recv, rv 0, len 2

send, rv 0, len 1905

recv, rv 0, len 2

send, rv 0, len 2587

recv, rv 0, len 2

recv, rv 0, len 5760

send, rv 0, len 1

recv, rv 0, len 2

send, rv 0, len 2401

recv, rv 0, len 2

send, rv 0, len 1

recv, rv 0, len 2

send, rv 0, len 3057

recv, rv 0, len 2

send, rv 0, len 119

recv, rv 0, len 2

send, rv 0, len 1

recv, rv 0, len 38

send, rv 0, len 2591

recv, rv 0, len 2368

recv, rv 0, len 36

recv, rv 0, len 5760

waiting for next fingerprint...
send, rv 0, len 2615

recv, rv 0, len 2

send, rv 0, len 1

recv, rv 0, len 7

send, rv 0, len 1

recv, rv 0, len 7

reading fingerprint...
recv, rv 0, len 64

recv, rv 0, len 84032

recv, rv 0, len 84096

recv, rv 0, len 84096

(continue flooding the same thing...)

The permissions are fine, I just need to rerun make access after running ./cli because the owner is reinitialized to root.
vfs301_proto_init() is reached.

[andree182]

hey, that actually looks promising - the device seems to accept the the initialization (there are no errors in the log you sent), you are getting the fingerprint data, only for some reason the device doesn't stop reading the fingerprint (maybe there should be some calibration or something).

Seems you aren't a newbie, so here's the hint - try replacing the 'while (1)' loop in vfs301_proto_process_event() for something like 'for (int i = 0; i < 5; i++)'. That should at least return the first fingerprint (hopefully also some following ones).

[MaximeCheramy]

reading fingerprint...
recv, rv 0, len 64

recv, rv 0, len 84032

recv, rv 0, len 84096

recv, rv 0, len 84096

recv, rv 0, len 84096

recv, rv 0, len 84096

send, rv 0, len 1

recv, rv -7, len 0

recv, rv 0, len 864

recv, rv 0, len 2

send, rv 0, len 2587

recv, rv -7, len 0

recv, rv 0, len 2

recv, rv 0, len 5760

fingerprint too short (200x1 px), ignoring...

[MaximeCheramy]

If I put my finger on the sensor while it reads the fingerprint, I don't have this last error.

[andree182]

And before the first "reading fingerprint..." message, does it wait (i.e. repeat "send, rv 0, len 1"; "recv, rv 0, len 7") until you put the finger on the sensor?

[MaximeCheramy]

No, it does not wait (I did not put my finger on the sensor):

waiting for next fingerprint...
send, rv 0, len 2615

recv, rv 0, len 2

send, rv 0, len 1

recv, rv 0, len 7

send, rv 0, len 1

recv, rv 0, len 7

reading fingerprint...

[andree182]

Hmm, that's not good news... Do youhave windows on your machine? If so, you could do some usb-sniffing and send the log (I'd nagivate you) for some debugging...

[andree182]

s/nagivate/navigate/

[MaximeCheramy]

Yes, and the only thing installed on it is a usb-sniffer :D. Let me know what you want me to do. I'll do it later tonight.

[andree182]

same here :-)) I have to leave, so I'll get back to you tomorrow...

[andree182]

I suppose you are using 64-bit windows. So you can use e.g. http://www.usblyzer.com/ , it can produce quite nice csv logs... Just don't forget to set 64kb buffers in the settings, otherwise the logs are quite useless I think...

The logging is quite straight-forward. I suggest you disable the device in the device manager, then start logging in usblyzer, and reenable the device. If nothing is still logged, you'll probably have to restart some biometrics service(s) and/or start some program using the scanner.

You can then send me the logs (either ulz or exported to csv, gzipped please :) ) - you can find my email at andree.sk / email.html :) Or get back here if you have trouble obtaining the logs...

[MaximeCheramy]

I'm sorry, I lacked a bit of time, I'll try to do it this weekend.

[MaximeCheramy]

Logs (finally) sent.

[rodolforg]

Another way to work around this issue is do not use context at all at libusb_init() and libust_exit(), just passing NULL also on both.