fprintd-enroll fails on fresh install of xubuntu 20.04 with an USB UPEK reader
- Focal (20.04)
- Bug #1881380
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libfprint |
Fix Released
|
High
|
|||
libfprint (Ubuntu) |
Fix Released
|
High
|
Marco Trevisan (Treviño) | ||
Focal |
Fix Released
|
High
|
Marco Trevisan (Treviño) |
Bug Description
[ Impact ]
The fingerprint reader is an UPEK TCRE3C usb fingerprint reader. It was working fine with ubuntu 16.04 and 18.04.
[ Test case ]
With an UPEK fingerprint reader run:
- fprintd-enroll
Enrollment should work properly
[ Regression potential ]
Fingers are not enrolled (not that now they are :))
----
lsusb shows:
0483:2016 STMicroelectronics Fingerprint Reader
user@xubuntu:~$ fprintd-enroll
Using device /net/reactivate
failed to claim device: Open failed with error: transfer timed out
user@xubuntu:~$ fprintd-list user
found 1 devices
Device at /net/reactivate
Using device /net/reactivate
User user has no fingers enrolled for UPEK TouchStrip.
This bug is probably the same as:
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #3 |
Probably a small regression in the driver port.
Please run with G_MESSAGES_
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #4 |
this happends when I do fprintd-list:
(fprintd:3926593): fprintd-DEBUG: 22:51:49.266: D-Bus service launched with name: net.reactivated
(fprintd:3926593): fprintd-DEBUG: 22:51:49.266: entering main loop
(fprintd:3926593): fprintd-DEBUG: 22:52:09.989: file_storage_
(fprintd:3926593): fprintd-DEBUG: 22:52:09.989: scan_dev_
and this is for fprintd-enroll:
(fprintd:3926593): fprintd-DEBUG: 22:52:46.922: user 'ark' claiming the device: 0
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
(fprintd:3926593): libfprint-
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #5 |
OK, with that it was obvious. A rather simple regression after major internal APIs changes :)
I have two requests for you:
1. Could you please try the scratch build: https:/
2. To prevent future problems, I would like to add upekts to the regression test suite. However, I don't have a device. Are you willing to record the USB traffic of an enroll+verify operation.
Request 2. means that the raw information from the device about the scanned print is captured and public. We don't know the format, but my suggestion is to not use your fingerprint as usual but some other skin (e.g. side of finger, palm, or even arm).
Point 2. should not be that complicated, but it would be helpful if your are more experienced overall :)
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #6 |
Created attachment 1686238
fprintd debug log
Now I get another type of error!
△ ~ fprintd-enroll
Using device /net/reactivate
Enrolling right-index-finger finger.
Enroll result: enroll-stage-passed
Enroll result: enroll-
ReleaseDevice failed: Release failed with error: transfer timed out
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #7 |
So, I did find a few more issues, but just in the error path after the enroll failure.
Just to make sure, did you try this only once or multiple times? I just want to make sure this is not an old rare failure that we might randomly hit depending on the user's interaction with the fingerprint reader.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #8 |
I tried several times and seems that it behaves even weirder than I thought! After a swipe I usually see "Enroll result: enroll-
(fprintd:1620882): libfprint-
(fprintd:1620882): libfprint-
(fprintd:1620882): libfprint-
(fprintd:1620882): libfprint-
(fprintd:1620882): libfprint-
(fprintd:1620882): libfprint-
(fprintd:1620882): libfprint-
(fprintd:1620882): libfprint-
(fprintd:1620882): libfprint-
double free or corruption (!prev)
apparently I need to swipe three times, but if a swipe cannot be read, it crashes instead of retry.
another type of error:
(fprintd:1619448): libfprint-
(fprintd:1619448): libfprint-
(fprintd:1619448): GLib-GObject-
(fprintd:1619448): libfprint-
(fprintd:1619448): libfprint-
(fprintd:1619448): libfprint-
(fprintd:1619448): libfprint-
(fprintd:1619448): libfprint-
(fprintd:1619448): libfprint-
(fprintd:1619448): libfprint-
(fprintd:1619448): libfprint-
(fprintd:1619448): fprintd-DEBUG: 21:59:54.931: enroll_cb: result enroll-
(fprintd:1619448): fprintd-WARNING **: 21:59:54.931: Device reported an error during enroll: (null)
sometimes I successfully get "swipe too short". but each time I try it behaves differently.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #9 |
And I cannot get a successful enrollment no matter how thoroughly I swipe :)
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #10 |
I am not really surprised about the different errors. There is a double free currently for the returned error (already have a patch see https:/
The funny thing is, I have compared the old/new code quite a bit, and the control flow appears identical. And it does work fine the first time it runs, which makes things even weirder.
The interesting this is that
(fprintd:1619448): libfprint-
means that the driver thought it was getting the final enrolled print (only happens at the end). But it happens too early and there is no print data attached.
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #11 |
OK, I am out of ideas.
I think we'll need a trace of a working enroll. Which hopefully does still work with the old packages from F31 or F30 (fprintd and libfprint).
Note, there are two things that you can do here:
1. Run the exact same test with debug output. Luckily the driver prints quite a lot of information, so this might be enough to learn more.
2. Run the test in umockdev-record to trace the USB transfers
For 2. you would need to install umockdev. Then wrap the fprintd binary with umockdev-record, something like:
umockdev-record -i /dev/bus/
You can also build an old version of libfprint (the V_1_0 tag) from git and run the smaller enroll test in the repository. Replace 001/005 with the actual device path (these numbers match the bus and device number listed by lsusb).
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #12 |
More strange things: fc31 version does remember my old fingerprints, but does not recognize the swipe or new enroll.
▲ ~ fprintd-enroll
Using device /net/reactivate
Enrolling right-index-finger finger.
Enroll result: enroll-disconnected
...
(fprintd:39576): libfprint-
(fprintd:39576): libfprint-
(fprintd:39576): libfprint-
(fprintd:39576): libfprint-
(fprintd:39576): libfprint-
(fprintd:39576): libfprint-
(fprintd:39576): libfprint-
(fprintd:39576): libfprint-
(fprintd:39576): fprintd-DEBUG: 21:12:10.053: enroll_stage_cb: result -71
(fprintd:39576): libfprint-
will now try fc30 version.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #13 |
Created attachment 1686850
more log from fc30 package
Even worse! Once it worked (not from the frist try), but the subsequent times it did not.
▲ ~ fprintd-enroll
Using device /net/reactivate
Enrolling right-index-finger finger.
Enroll result: enroll-stage-passed
Enroll result: enroll-
Enroll result: enroll-stage-passed
Enroll result: enroll-
Enroll result: enroll-
Enroll result: enroll-
Enroll result: enroll-completed
▲ ~ fprintd-enroll
Using device /net/reactivate
Enrolling right-index-finger finger.
Enroll result: enroll-disconnected
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #14 |
Created attachment 1686851
this one when it worked
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #15 |
Now I swiped my old fingerprint and it "just worked" as before. :-/
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #16 |
Yeah, the new libfprint is a rewrite in large parts and there are some incompatibilities (storage location and storage format). We never implemented a data migration, and usually it shouldn't be a big problem to simply enroll again …
From what you are writing, it looks like the old code already runs into the exact same problem. If that error is new, then I could image that your fingerprint reader itself is slowly dying. For example a dried up capacitor could make the power supply unstable, causing random processing errors.
I think the only thing one could try would be to simply ignore that bogus/unexpected packet and continue polling. But I am in doubt that will fix it, the "hardware slowly dying" hypothesis is too likely in my view. And even if we should be handling that data packet in some way, we don't know whether simply ignoring it is sufficient.
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #17 |
OK, building https:/
This contains all the bugfixes that happened recently. It will not fix the "fingerprint data too short" problem. However, it does fix other issues in the error and retry code paths (i.e. you can continue after a retry is "not centered" needed). So while you might need multiple attempts, I suspect you'll be able to enroll your finger then.
Could you test the build?
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #18 |
It works good and even picked up my old fingerprints! Regarding the faulty reader, it was like that for years :) I never ran it under any other OS so I do not know if it is supposed to work better.
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #19 |
Are you sure you updated correctly and restarted fprintd? The new build I did cannot open the old fingerprints. So it seems more likely that something went wrong during the upgrade and you were still using the F30 or F31 version of libfprint and fprintd.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #20 |
oops, apparently i had an old version hanging :( after the restart:
fprintd:361784): fprintd-DEBUG: 11:45:40.732: D-Bus service launched with name: net.reactivated
(fprintd:361784): fprintd-DEBUG: 11:45:40.732: entering main loop
(fprintd:361784): fprintd-DEBUG: 11:45:44.366: user 'ark' claiming the device: 0
(fprintd:361784): libfprint-
(fprintd:361784): libfprint-
**
libfprint-
Bail out! libfprint-
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #21 |
Outch. I added that assert just to make an assumption in the code explicit. Looks like that assumption was wrong indeed and there is a 9 byte buffer overflow in this driver. Ah, the code quality of these drivers …
Sorry, I fear you'll need to play guinea pig for me for a bit longer.
Please try this build:
https:/
That should fix the buffer overflow and result in the assertion to hold true.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #22 |
Nope, exactly the same error with different line number.
(fprintd:962696): fprintd-DEBUG: 19:23:51.675: D-Bus service launched with name: net.reactivated
(fprintd:962696): fprintd-DEBUG: 19:23:51.675: entering main loop
(fprintd:962696): fprintd-DEBUG: 19:23:59.700: user 'ark' claiming the device: 0
(fprintd:962696): libfprint-
(fprintd:962696): libfprint-
**
libfprint-
Bail out! libfprint-
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #23 |
Hah, nice one. Obviously the assert itself was also wrong. :)
Another build
https:/
with the assert fixed up.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #24 |
What happens now:
fprintd-enroll works, but if it is unable to obtain swipe, it gives up immediately like that:
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): fprintd-DEBUG: 08:46:55.706: enroll_cb: result enroll-disconnected
(fprintd:1961021): fprintd-WARNING **: 08:46:55.706: Device reported an error during enroll: fingerprint data too short
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): fprintd-DEBUG: 08:46:55.767: released device 0
However, if I delete fingerprints, mate-about-me is unable to enroll and crashes as before, however, I do not see anything wrong on the fprintd side, do you?
(fprintd:1961021): fprintd-DEBUG: 08:58:08.804: user 'ark' claiming the device: 0
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-
(fprintd:1961021): libfprint-SSM-DE...
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #25 |
Alright! We still get
(fprintd:1961021): libfprint-
but that was expected and is not a regression.
As for mate-about-me, not sure. All that the log says is that the device is being opened and then closed again about 4 seconds later (claim/release in fprintd terms). Nothing suspicious from the libfprint/fprintd side there.
So, I'll close this bug once I have patches pulled into the Fedora libfprint package. I'll probably do an upstream release first.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #26 |
But the previous version did not crash mate-about-me on unsuccessful swipes.. Something still appears somewhat off.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #27 |
also, shouldn't fprintd-enroll prompt me for another try when it is unable to obtain a decent swipe instead of restarting the whole process?
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #28 |
Also I see 3 distinct errors: swipe too short (handled correctly), swipe not centered (handled correctly) and "fingerprint data too short) -- not handled correctly.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #29 |
Also if I "successfully" enroll, it does not properly read it then!
(fprintd:2931208): libfprint-
(fprintd:2931208): libfprint-
(fprintd:2931208): libfprint-
(fprintd:2931208): fprintd-DEBUG: 21:45:13.392: claimed device 0
(fprintd:2931208): fprintd-DEBUG: 21:45:13.396: file_storage_
(fprintd:2931208): fprintd-DEBUG: 21:45:13.396: start verification device 0 finger 7
(fprintd:2931208): libfprint-
Error deserializing data: Data could not be parsed(
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #30 |
Ah, so one more issue …
New scratch build: https:/
You'll need to delete the enrolled print. You may need to manually delete the file, i.e. /var/lib/
Look, the "fingerprint data too short" is a *protocol* issue with the device. I agree it sucks, but I simply cannot support these drivers beyond fixing regressions and blatant issues like crashes. So what I am doing is resolving all the regressions. At this point we should be at the same level of support as F31 had (with a fixed buffer overflow!), so that is where my support stops.
For some of the newer device we have support from the manufacturer. That is obviously much better.
mate-about-me crashing is also a separate issue. I somewhat suspect (but really don't know) that this will already be fixed upstream. I doubt it is problem in fprintd (or libfprint) and will need dealing with on the mate side.
That said, I do have one more request for you. Could you do the following:
* Download https:/
* Install umockdev: sudo dnf install umockdev
* Run lsusb to identify the USB port (the bus/device numbers in the "Bus X Device Y: ID ..." message)
* Grab device information: umockdev-record /dev/bus/usb/X/Y >/tmp/device
* Grab a log of USB packets: umockdev-record -i /dev/bus/
* Then enroll and verify the same finger; you may need to stop fprintd first.
Replace X, Y and "/path/
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #31 |
Ah, note that the bus/device numbers might change if you run into that annoying "fingerprint data too short error". In that case you probably need to restart the whole process.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #32 |
fprintd:1626233): libfprint-
(fprintd:1626233): libfprint-
(fprintd:1626233): libfprint-
(fprintd:1626233): libfprint-
(fprintd:1626233): libfprint-
(fprintd:1626233): libfprint-
(fprintd:1626233): libfprint-
(fprintd:1626233): libfprint-
(fprintd:1626233): libfprint-
(fprintd:1626233): libfprint-
(fprintd:1626233): GLib-GObject-
(fprintd:1626233): GLib-CRITICAL **: 10:40:10.390: g_variant_get_type: assertion 'value != NULL' failed
(fprintd:1626233): GLib-CRITICAL **: 10:40:10.390: g_variant_
(fprintd:1626233): GLib-CRITICAL **: 10:40:10.390: g_variant_
(fprintd:1626233): GLib-ERROR **: 10:40:10.390: ../glib/gmem.c:108: failed to allocate 94863762044169 bytes
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #33 |
At least we are at the point that enroll works …
https:/
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #34 |
Yes!
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #35 |
With this build PAM module crashes immediately.
Swipe your right index finger across the fingerprint reader
An unknown error occurred
free(): double free detected in tcache 2
[1] 1131410 abort sudo id
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
(fprintd:1116834): GLib-CRITICAL **: 23:19:09.031: g_error_free: assertion 'error != NULL' failed
(fprintd:1116834): libfprint-
(fprintd:1116834): fprintd-DEBUG: 23:19:09.032: verify_cb: result verify-disconnect
(fprintd:1116834): fprintd-WARNING **: 23:19:09.032: Device reported an error during verify: Response had wrong subcommand type
(fprintd:1116834): libfprint-
(fprintd:1116834): libfprint-
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #36 |
Anything else I could do?
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #37 |
Right, another memory management issue and a flaw in the error reporting logic.
https:/
But even with that, well report a hard error and we'll give up fingprint auth in that situation.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #38 |
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
(fprintd:1046574): fprintd-DEBUG: 20:08:27.599: verify_cb: result verify-disconnect
(fprintd:1046574): fprintd-WARNING **: 20:08:27.599: Device reported an error during verify: Response had wrong subcommand type
(fprintd:1046574): libfprint-
(fprintd:1046574): libfprint-
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #39 |
Alright, looking pretty good.
I have no idea what that error itself means. The device isn't doing what the driver expects, but I really don't think it is a regression. I do hope that it works fine most of the time though. The only thing I could offer is that we try simply ignoring that message and see what happens then. But again, I don't think that this is a regression.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #40 |
It crashes on the client side of PAM as well:
▲ ~ sudo id
Swipe your right index finger across the fingerprint reader
An unknown error occurred
free(): double free detected in tcache 2
[1] 1047951 abort sudo id
I do not think it is intended behavior, also it never happened with the old version
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #41 |
Would recording debug session with the old version help?
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #42 |
Nah, pretty obvious what was going wrong:
https:/
Though the test case appears to be still failing, and I am not really sure why that is the case.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #43 |
ok waiting for the next build :)
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #44 |
https:/
You'll need the fprintd-pam package at least.
Launchpad Janitor (janitor) wrote : | #1 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in fprintd (Ubuntu): | |
status: | New → Confirmed |
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #45 |
Sorry for the delay, the log is apprarently similar.
(fprintd:35181): fprintd-DEBUG: 17:52:41.283: claimed device 0
(fprintd:35181): fprintd-DEBUG: 17:52:41.287: file_storage_
(fprintd:35181): fprintd-DEBUG: 17:52:41.287: start verification device 0 finger 7
(fprintd:35181): fprintd-DEBUG: 17:52:41.287: file_storage_
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
(fprintd:35181): libfprint-
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #46 |
On the PAM side, it is still the same "unknown error" but without double free error, so it falls back to the next method gracefully.
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #47 |
Exactly, that was the point of the fix.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #48 |
aand, any chance I will get fprintd working? ;)
In Red Hat Bugzilla #1832229, updates (updates-redhat-bugs) wrote : | #49 |
FEDORA-
Changed in fprintd: | |
importance: | Unknown → High |
status: | Unknown → Fix Committed |
Sebastien Bacher (seb128) wrote : | #50 |
Marco, sounds like Benjamin has a fix for that, probably worth including in the next upload?
Changed in fprintd (Ubuntu): | |
importance: | Undecided → High |
status: | Confirmed → In Progress |
assignee: | nobody → Marco Trevisan (Treviño) (3v1n0) |
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #58 |
There was a semi-working version of fprintd previously? This one fails instantly.
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #59 |
Well, the bugfix above is "just" the libfprint part. There was another (but entirely independent) problem in fprintd (i.e. pam_fprintd) for which I have not posted an update yet. Things *should* be OK if you use the new libfprint build together with the pam_fprintd package from https:/
tags: | added: fixed-upstream |
affects: | fprintd (Ubuntu) → libfprint (Ubuntu) |
affects: | fprintd → libfprint |
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #61 |
No, it enrolls but it cannot verify; the verification fails with similar error messages even before I swipe.
In Red Hat Bugzilla #1832229, updates (updates-redhat-bugs) wrote : | #62 |
libfprint-
See https:/
instructions on how to install test updates.
You can provide feedback for this update here: https:/
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #63 |
Yes, it does persist indeed. Can enroll, cannot verify.
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #64 |
Sorry, but just no …
AFAICT the regressions *are* fixed by the update. There seems to be some other issue, but I don't see anything that might be going wrong at this point.
Now, might there be another regression … yes, but this update *does* fix a lot of problems.
But, I am sorry, there is *nothing* I can do for you at this point. One might be able to figure this out with a lot of testing and comparing to the f30 version.
So:
* IF the f30 version behaves better, then this would be a regression and a valid bug. But fixing that issue would need extensive debugging (e.g. tracing the USB transfers, finding differences, manually converting an enrolled print from f30 to the new version and test if that works …), which I cannot do as I don't have the device.
* IF the f30 version beahves the same, then there is simply nothing I can do for you.
So yeah, I *will* close this bug as fixed … even if you are out of luck unfortunately.
description: | updated |
Changed in libfprint (Ubuntu Focal): | |
status: | New → Fix Committed |
Changed in libfprint (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in libfprint (Ubuntu Focal): | |
importance: | Undecided → High |
assignee: | nobody → Marco Trevisan (Treviño) (3v1n0) |
Launchpad Janitor (janitor) wrote : | #51 |
This bug was fixed in the package libfprint - 1:1.90.
---------------
libfprint (1:1.90.
* New upstream release
- Fixed crash in VFS0050 (LP: #1876502)
- Enrollment fails with UPEK reader (LP: #1881380)
- Lots of various drivers fixes
- As per a patch for nbis required for some sensors that was accidentally
dropped in an earlier release. Users of sensors/drivers aes1610, aes2501,
aes2550, aes1660, aes2660, elan, upektc_img) need to re-enroll
* d/p/git_
- Dopped (applied upstream)
* debian/control: Add missing libfprint-2-tod-dev dependencies (LP: #1884267)
* debian/rules: Be strictier about symbol changes
* libfprint-
-- Marco Trevisan (Treviño) <email address hidden> Fri, 19 Jun 2020 17:38:55 +0200
Changed in libfprint (Ubuntu): | |
status: | Fix Committed → Fix Released |
In Red Hat Bugzilla #1832229, updates (updates-redhat-bugs) wrote : | #65 |
FEDORA-
If problem still persists, please make note of it in this bug report.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #66 |
Hey wait!
Ineed there *IS* a regression. Two of them: one on the fprintd side (cannot verify) and one on libfprint side (crash when cannot verify), Only the later one was fixed. fc30 version worked fine. As I said, I am willing to provide traces and whatever could help to fix it properly. Please reopen the bug.
In Red Hat Bugzilla #1832229, bberg (bberg-redhat-bugs) wrote : | #67 |
Yes, there still is the fprintd regression for which I didn't bother to clone the bug (it'll be fixed with the next update, you can be certain of that).
There *is* something weird going on with that "f0" subcommand during verify, I agree. I don't know what the reason may be, it could be the way the driver works, it may be that the stored print data gets corrupted at some point. I simply don't know (and I *have* looked into it), and while I have some ideas of where I would start looking further (e.g. hacking together a stored libfprint 1.90.x print from the old version), I don't really have the time to do so.
It isn't that I don't want to help you. The problem is that it simply doesn't make sense for me to spend more time on supporting hardware that probably is not even sold anymore (I have not checked this). The cost/benefit falls flat if there is no big user base for the device.
It is an unfortunate regression … but I fear the "better" fix from my point of view would be to remove the driver upstream.
I do need to focus on other libfprint work unfortunately; support for new devices is simply more important.
In Red Hat Bugzilla #1832229, ark (ark-redhat-bugs) wrote : | #68 |
I understand. But it is the latest laptop you can get with 4x3 hires screen and decent keyboard, so some people like me are still stuck with it :)
In Red Hat Bugzilla #1832229, mrerick (mrerick-redhat-bugs) wrote : | #69 |
The problem continues, and it impacts the Lenovo KUF0452 Fingerprint external keyboard with this UPEK fingerprint reader. These are still widely used.
The fingerprint will now register with the version that was in today's Fedora update (1.90.2-1.fc32). But commands like "sudo dnf update" will fail with:
An unknown error occurred
free() double free detected in tcache 2
Aborted
This continues until you delete the stored fingerprint and fingerprint authentication is disabled.
Marc
Robie Basak (racb) wrote : Proposed package upload rejected | #52 |
An upload of libfprint to focal-proposed has been rejected from the upload queue for the following reason: "No bug references and/or SRU information for "New upstream release" and "Lots of various driver fixes"; incomplete discussion of regression potential in all bugs that are referenced. Please see https:/
Brian Murray (brian-murray) wrote : Please test proposed package | #53 |
Hello Jesús, or anyone else affected,
Accepted libfprint into focal-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
tags: | added: verification-needed verification-needed-focal |
Jesús Diéguez Fernández (jesusdf) wrote : | #54 |
Hi,
I enabled proposed updates and updated my packages to:
libfprint-2-2:amd64 (1:1.90.
libfprint-
And I can confirm that enrollment of fingerprints now succeeds:
$ fprintd-enroll
Using device /net/reactivate
Enrolling right-index-finger finger.
Enroll result: enroll-stage-passed
Enroll result: enroll-stage-passed
Enroll result: enroll-completed
However, trying to use su or sudo after this returns another error:
$ LANG=C sudo ls
Swipe your right index finger across the fingerprint reader
free(): double free detected in tcache 2
Abortado
$ LANG=C su
Swipe your right index finger across the fingerprint reader
free(): double free detected in tcache 2
Abortado
Should this be addressed in another bugtrack or can it be solved on this one?
Thank you.
Jesús Diéguez Fernández (jesusdf) wrote : | #55 |
It appears that in the RedHat bugtracker people are stuck at the same spot.
I'm changing the tag to verification-failed since registration of fingerprints works but validation fails.
tags: |
added: verification-failed-focal removed: verification-needed-focal |
Marco Trevisan (Treviño) (3v1n0) wrote : | #56 |
Please report a new bug for that, as they're effectively two different issues.
We will fix it in a next iteration while the enroll issue is effectively fixed as you said, so marking it as verified, but please open a new bug for the verification side of things.
tags: |
added: verification-done verification-done-focal removed: verification-failed-focal verification-needed |
Marco Trevisan (Treviño) (3v1n0) wrote : | #57 |
Ok, I've actually opened. So moving to bug #1888495.
In Red Hat Bugzilla #1832229, unknownbuckethead (unknownbuckethead-redhat-bugs) wrote : | #70 |
(In reply to Marc from comment #59)
> The problem continues, and it impacts the Lenovo KUF0452 Fingerprint
> external keyboard with this UPEK fingerprint reader. These are still widely
> used.
>
> The fingerprint will now register with the version that was in today's
> Fedora update (1.90.2-1.fc32). But commands like "sudo dnf update" will fail
> with:
>
> An unknown error occurred
> free() double free detected in tcache 2
> Aborted
>
> This continues until you delete the stored fingerprint and fingerprint
> authentication is disabled.
>
> Marc
I can confirm this problem. When I prompted for scrolling fingers I got this error.
Changed in libfprint: | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #71 |
This bug was fixed in the package libfprint - 1:1.90.
---------------
libfprint (1:1.90.
* New upstream release (LP: #1887822)
- Fixed crash in VFS0050 (LP: #1878285)
- Enrollment fails with UPEK reader (LP: #1881380)
- As per a patch for nbis required for some sensors that was accidentally
dropped in an earlier release. Users of sensors/drivers aes1610, aes2501,
aes2550, aes1660, aes2660, elan, upektc_img) need to re-enroll
* d/p/git_
- Dopped (applied upstream)
* debian/control: Add missing libfprint-2-tod-dev dependencies (LP: #1884267)
* debian/rules: Be strictier about symbol changes
* libfprint-
* debian/{control, gbp.conf}: prepare for focal branching
-- Marco Trevisan (Treviño) <email address hidden> Thu, 16 Jul 2020 18:06:19 +0200
Changed in libfprint (Ubuntu Focal): | |
status: | Fix Committed → Fix Released |
Łukasz Zemczak (sil2100) wrote : Update Released | #72 |
The verification of the Stable Release Update for libfprint has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
Description of problem:
After upgrade fc30 -> fc32, the fingerprint reader lost the enrolled fingerprint and is unable to enroll a new one.
Version-Release number of selected component (if applicable):
fprintd- 1.90.1- 1.fc32. x86_64
How reproducible:
Always
Steps to Reproduce:
1. fprintd-list `id -un`
2. fprintd-enroll
Actual results:
1. ▲ ~ fprintd-list `id -un` d/Fprint/ Device/ 0 d/Fprint/ Device/ 0
found 1 devices
Device at /net/reactivate
Using device /net/reactivate
User ark has no fingers enrolled for UPEK TouchStrip.
2. d/Fprint/ Device/ 0
▲ ~ fprintd-enroll
Using device /net/reactivate
failed to claim device: Open failed with error: transfer timed out
▲ ~ sudo /usr/libexec/ fprintd -t
(fprintd:343450): libfprint- upekts- CRITICAL **: 22:15:48.449: async msg read failed: transfer timed out
Expected results:
1. Pre-enrolled fingerprint should be visible in the list
2. A new fingerprint should be enrolled successfully.
Additional info:
also there is mate-about-me bug: https:/ /bugzilla. redhat. com/show_ bug.cgi? id=1831122