search

rindeal / libfprint-vfs_proprietary-driver

New libfprint driver for VFS451 (138a:0007), VFS471 (138a:003c), VFS491 (138a:003d), VFS495 (138a:003f). Warning: depends on proprietary binaries.
GNU Lesser General Public License v2.1
74 stars 13 forks source link

Error -103 #4

Open IvanVojtko opened 5 years ago

IvanVojtko commented 5 years ago

I've installed your AUR package and when I try to run fprintd-enroll, id gives me this: Using device /net/reactivated/Fprint/Device/0 Enrolling right-index-finger finger. EnrollStart failed: Enroll start failed with error -103 Can you help me with this?

inpos commented 5 years ago

Same issue on Gentoo. Additional journalctl output:

янв 18 12:12:04 inpos-hpe dbus[1448]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
янв 18 12:12:04 inpos-hpe systemd[1]: Starting Fingerprint Authentication Daemon...
янв 18 12:12:04 inpos-hpe dbus[1448]: [system] Successfully activated service 'net.reactivated.Fprint'
янв 18 12:12:04 inpos-hpe systemd[1]: Started Fingerprint Authentication Daemon.
янв 18 12:12:05 inpos-hpe fprintd[21422]: capture-helper probably died while we were waiting for img ready signal
янв 18 12:12:05 inpos-hpe fprintd[21422]: capture-helper output:
                                             SIGALRM caught: timed out waiting for VFS service
янв 18 12:12:05 inpos-hpe fprintd[21422]: TRACE vfs_proprietary.c: vfs_proprietary_dev_activate() [229]
янв 18 12:12:05 inpos-hpe fprintd[21422]: activation failed with error -103
янв 18 12:12:05 inpos-hpe fprintd[21422]: failed to start enrollment
rindeal commented 5 years ago

And can you confirm the vcsFPService daemon is running?

inpos commented 5 years ago 
~ # systemctl status vcsFPService
● vcsFPService.service - Validity Fingerprint Service
   Loaded: loaded (/lib/systemd/system/vcsFPService.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-01-21 10:55:50 MSK; 2min 47s ago
  Process: 5776 ExecStart=/usr/sbin/vcsFPService (code=exited, status=0/SUCCESS)
  Process: 5775 ExecStartPre=/usr/bin/find /tmp -maxdepth 1 -type p -name CH_* -delete (code=exited, status=0/SUCCESS)
  Process: 5774 ExecStartPre=/usr/bin/find /tmp -maxdepth 1 -type f -name vcsSemKey_* -delete (code=exited, status=0/SUCCESS)
 Main PID: 5778 (vcsFPService)
   Memory: 2.1M
   CGroup: /system.slice/vcsFPService.service
           └─5778 /opt/validity-sensor/usr/sbin/vcsFPService

янв 21 10:55:50 inpos-hpe systemd[1]: Starting Validity Fingerprint Service...
янв 21 10:55:50 inpos-hpe Validity_service_main[5776]: Validity service start up
янв 21 10:55:50 inpos-hpe systemd[1]: Started Validity Fingerprint Service.
inpos commented 5 years ago

journalctl output

янв 21 10:57:40 inpos-hpe dbus[1448]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
янв 21 10:57:40 inpos-hpe systemd[1]: Starting Fingerprint Authentication Daemon...
янв 21 10:57:40 inpos-hpe dbus[1448]: [system] Successfully activated service 'net.reactivated.Fprint'
янв 21 10:57:40 inpos-hpe systemd[1]: Started Fingerprint Authentication Daemon.
янв 21 10:57:41 inpos-hpe fprintd[6951]: capture-helper probably died while we were waiting for img ready signal
янв 21 10:57:41 inpos-hpe fprintd[6951]: capture-helper output:
                                            SIGALRM caught: timed out waiting for VFS service
янв 21 10:57:41 inpos-hpe fprintd[6951]: TRACE vfs_proprietary.c: vfs_proprietary_dev_activate() [229]
янв 21 10:57:41 inpos-hpe fprintd[6951]: activation failed with error -103
янв 21 10:57:41 inpos-hpe fprintd[6951]: failed to start enrollment
inpos commented 5 years ago 
inpos@inpos-hpe ~ $ fprintd-enroll 
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
EnrollStart failed: Enroll start failed with error -103
inpos@inpos-hpe ~ $ fprintd-list inpos
found 1 devices
Device at /net/reactivated/Fprint/Device/0
Using device /net/reactivated/Fprint/Device/0
User inpos has no fingers enrolled for Validity Sensors (proprietary driver).
lighterowl commented 5 years ago

Getting the same errors here, and the same logs. Weirdly, the img_capture application from libfprint examples works just fine : I can get an image without any problems.

[daniel@foobar examples]$ ./img_capture 
(process:675): libfprint-DEBUG: 19:56:36.206: 1639251876: ../libfprint/core.c:752
(process:675): libfprint-DEBUG: 19:56:36.215: registered driver vfs_proprietary
(process:675): libfprint-DEBUG: 19:56:36.215: driver vfs_proprietary supports USB device 138a:003f
(process:675): libfprint-DEBUG: 19:56:36.215: selected driver vfs_proprietary supports USB device 138a:003f
Found device claimed by Validity Sensors (proprietary driver) driver
(process:675): libfprint-sync-DEBUG: 19:56:36.215: 1639260356: ../libfprint/sync.c:56
(process:675): libfprint-async-DEBUG: 19:56:36.215: 1639260375: ../libfprint/async.c:59
(process:675): libfprint-async-DEBUG: 19:56:36.215: status 0
(process:675): libfprint-sync-DEBUG: 19:56:36.215: status 0
Opened device. It's now time to scan your finger.

(process:675): libfprint-sync-DEBUG: 19:56:36.215: to be handled by vfs_proprietary
(process:675): libfprint-async-DEBUG: 19:56:36.215: 1639261173: ../libfprint/async.c:526
(process:675): libfprint-DEBUG: 19:56:36.216: action 4
(process:675): libfprint-vfs_proprietary-DEBUG: 19:56:36.216: dev_activate(1)
(process:675): libfprint-capture-helper-DEBUG: 19:56:36.219: capture-helper spawned successfully, pid=677
(process:675): libfprint-DEBUG: 19:56:36.219: status 0
(process:675): libfprint-async-DEBUG: 19:56:36.219: 1639264564: ../libfprint/async.c:547
(process:675): libfprint-capture-helper-DEBUG: 19:56:36.219: entering epoll loop
TRACE vfs_proprietary.c: ch_img_ready_callback() [103]
(process:675): libfprint-DEBUG: 19:56:42.355: finger on sensor
TRACE vfs_proprietary.c: ch_img_ready_callback() [111]
TRACE vfs_proprietary.c: ch_img_meta_callback() [119]
(process:675): libfprint-DEBUG: 19:56:42.356: length=47000
(process:675): libfprint-vfs_proprietary-DEBUG: 19:56:42.357: img: dimensions=200x235, length=47000, flags=5
TRACE vfs_proprietary.c: ch_img_meta_callback() [152]
TRACE vfs_proprietary.c: ch_img_meta_callback() [159]
TRACE vfs_proprietary.c: ch_img_data_callback() [167]
(process:675): libfprint-DEBUG: 19:56:42.357: 1645402897: ../libfprint/imgdev.c:234
(process:675): libfprint-DEBUG: 19:56:42.358: finger removed
(process:675): libfprint-async-DEBUG: 19:56:42.358: result 0
TRACE vfs_proprietary.c: ch_img_data_callback() [177]
TRACE vfs_proprietary.c: vfs_proprietary_dev_activate() [229]
(process:675): libfprint-sync-DEBUG: 19:56:42.367: result: complete
(process:675): libfprint-sync-DEBUG: 19:56:42.368: ending capture
(process:675): libfprint-async-DEBUG: 19:56:42.369: 1645414935: ../libfprint/async.c:605
(process:675): libfprint-DEBUG: 19:56:42.370: 1645415532: ../libfprint/imgdev.c:363
(process:675): libfprint-async-DEBUG: 19:56:42.371: 1645416259: ../libfprint/async.c:580
(process:675): libfprint-sync-DEBUG: 19:56:42.371: 1645416971: ../libfprint/sync.c:608
(process:675): libfprint-DEBUG: 19:56:42.373: written to 'finger.pgm'
(process:675): libfprint-DEBUG: 19:56:42.375: written to 'finger_standardized.pgm'
(process:675): libfprint-sync-DEBUG: 19:56:42.376: 1645421464: ../libfprint/sync.c:96
(process:675): libfprint-async-DEBUG: 19:56:42.377: 1645423073: ../libfprint/async.c:93
(process:675): libfprint-sync-DEBUG: 19:56:42.378: 1645423675: ../libfprint/sync.c:77
(process:675): libfprint-DEBUG: 19:56:42.378: 1645423861: ../libfprint/core.c:772
lighterowl commented 5 years ago

I think I got it. The fact that the libfprint examples work fine, but accessing the device via fprintd doesn't made me think, and I went to fprintd's systemd unit file in order to add G_MESSAGES_DEBUG so it produces more output. At least on Arch - but I suppose the same applies to Gentoo as well, given the comments here - the unit file has the following directives, among other things meant to protect the system from misbehaving applications :

# Filesystem lockdown
ProtectSystem=strict
ProtectKernelTunables=true
ProtectControlGroups=true
ReadWritePaths=/var/lib/fprint
ProtectHome=true
PrivateTmp=true

After commenting everything out, fprintd-enroll started working. After re-enabling everything and retrying, the minimal set of stuff that needs commenting out seems to be ProtectSystem, ReadWritePaths (which has no effect if there's no ProtectSystem anyway, according to the documentation), and PrivateTmp. Running fprintd-enroll with only these three commented out works for me.

I guess the shared library that capture-helper links to does some weird stuff that causes vfs_wait_for_service to fail, at least everything seems to point in this direction. The exact system call that fails could probably be tracked down with strace, but I think this solution somewhat works for now.

This is going to be weird from a packaging perspective, since we now effectively have a package which needs to modify third-party package's (fprintd's) files. I'm not really sure how to solve this in the AUR package that I'm maintaining : let me know how/if you solve it in Gentoo.

Thanks!

rindeal commented 5 years ago

It's true that when developing this driver I tested it only with 'fprint_demo' and 'Fingerprint GUI', not 'fprintd' and not fprintd running under systemd's direction. The excerpt from the systemd's unit file is definetely too restrictive though. Because the proprietary library communicates with the proprietary daemon through special files inside '/tmp'. So forget about PrivateTmp= right away. As to the other two offending directives, I'm not sure, since I don't remember the library would need access to paths other than /tmp and /sys. The service file I created years ago for the deamon, however, uses only ProtectSystem=True and ReadWritePaths family of directives is explicitely commented out citing issues with symlink resolving, ie it blocked paths in whitelisted directories which resolved into blacklisted ones. So that may be the way to go with fprintd as well.

If you want to have fprintd working by default and cannot fix it upstream, you could modify the service file for the daemon to include PrivateTmp=true and JoinsNamespaceOf=fprintd.service. This would make this driver unusable for everyone else except fprintd though.

Anyway, this is an issue with the systemd service file shipped with fprintd. Thus, to my relief, my driver remains bug-free.

inpos commented 5 years ago

I've created /etc/systemd/system/vcsFPService.service.d/local.conf with following content:

[Service]
PrivateTmp=true
JoinsNamespaceOf=fprintd.service

then execute: systemctl reenable vcsFPService.service and reboot system. After that try fprintd-enroll and get:

inpos@inpos-hpe ~ $ fprintd-enroll 
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
EnrollStart failed: Enroll start failed with error -103

and output of journalctl -f :

янв 28 09:45:33 inpos-hpe dbus[1417]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
янв 28 09:45:33 inpos-hpe systemd[1]: Starting Fingerprint Authentication Daemon...
янв 28 09:45:34 inpos-hpe dbus[1417]: [system] Successfully activated service 'net.reactivated.Fprint'
янв 28 09:45:34 inpos-hpe systemd[1]: Started Fingerprint Authentication Daemon.
янв 28 09:45:35 inpos-hpe fprintd[5865]: capture-helper probably died while we were waiting for img ready signal
янв 28 09:45:35 inpos-hpe fprintd[5865]: capture-helper output:
                                            SIGALRM caught: timed out waiting for VFS service
янв 28 09:45:35 inpos-hpe fprintd[5865]: TRACE vfs_proprietary.c: vfs_proprietary_dev_activate() [229]
янв 28 09:45:35 inpos-hpe fprintd[5865]: activation failed with error -103
янв 28 09:45:35 inpos-hpe fprintd[5865]: failed to start enrollment
IvanVojtko commented 5 years ago

Try to kill process vcsFPService and run sudo vcsFPService Or try reboot, kill service and run manually. Works for me, but sometimes I still get -103 error.

inpos commented 5 years ago

@IvanVojtko I think this is not "daily use" workaround ;)

rindeal commented 5 years ago

Works for me, but sometimes I still get -103 error.

That shouldn't happen. One reason I see is that it could be at boot, because the systemd service is not properly ordered and you're trying to login before the proprietary daemon is started. Another reason could be that I set the timeout just too low (1sec currently) and it errors out pointlessly. I will increase the timeouts today, and will add code to check that the driver can see the daemon later this month, so that I can debug this common issue more properly. Although I didn't want to go this way initially since it adds dependencies and assumptions.

Prn-Ice commented 5 years ago

I get the same error 103 but when I run 

systemctl status vcsFPService

I get 

Unit vcsFPService.service could not be found.

I installed this package from the AUR on manjaro, and use it with fprintd-vfs_proprietary

DiceShard commented 4 years ago

I have the exact same issue

systemctl status vcsFPService

And i get

Unit vcsFPService.service could not be found.

lighterowl commented 4 years ago

I get the same error 103 but when I run

systemctl status vcsFPService

I get

Unit vcsFPService.service could not be found.

I installed this package from the AUR on manjaro, and use it with fprintd-vfs_proprietary

I have the exact same issue

systemctl status vcsFPService

And i get

Unit vcsFPService.service could not be found.

This is probably because the name of the unit in the AUR package is vfs495-daemon.

perceival commented 4 years ago

For people coming here with the same error: please make sure you reset fingerprint scanner from BIOS (on Elitebook 840 G1 that requires setting up BIOS password first). Please note that might affect ability to login to other OS if you are dual booting. In short there are three components required for FPS to work: vfs495-daemon libfprint-vfs_proprietary-git fprintd-vfs_proprietary

ReyMagos commented 1 year ago

I have similar issue and I don't have vcsFPService at all. Can someone post this systemd file? Or give me some instructions what I did wrong?