Openct needs to be restarted when inserting an eToken

Same issue here on 2 different computers (one upgraded from 8.10, the other has been installed from scratch).

can you check which configuration the ubuntu package has?
a hal file (official suggestion), an udev rule or a hotplug map file?

if so, what is the usb vendor and product id, and are those matched
in that file? what script is configured to be triggered by that file?

can you check if that script is run? (e.g. insert a line
"touch /tmp/openct-script-is-run" and see if it created
that file).

if that script is run, can you try inserting these commands:
exec 2> /tmp/openct-script.log 2>&1
set -x

re-insert the token and if that log file is created,
copy it aside and attach it later to this bug.

if that script seems to work (no errors etc.)
check if openct-control/ifdhandler is started by
the script. you can simply increase debug level
in openct.conf to 5 or 6 or so, and make sure
syslog logs them (usualy does, see /var/log/messages
or something like that), and check if openct is started
(e.g. messages from openct-control or ifdhandler).

maybe any of these actions can show us what is wrong
and how we can fix it.

and if anyone here knows what the magic key is to turn a
patch fixing a real-world problem, into an updated package
in both debian, the next ubuntu _AND_ jaunty-updates, please
let us know so we can try. I failed much too often:(

 /lib/udev/rules.d/40-openct.rules
replace
ENV{MODALIAS}=="usb:v0529p0514", RUN+="/lib/udev/openct_usb"
with
ENV{MODALIAS}=="usb:v0529p0514*", RUN+="/lib/udev/openct_usb"

and it should work.

can anyone fix the jaunty openct package with this trivial typo fix?
or will openct users need to wait 6 months for a new ubuntu release?

for reference, the upstream fix was commit 1063 in october 2008.
http://www.opensc-project.org/openct/changeset/1063/trunk/etc/openct.udev.modalias.in

the debian bug is 498920

Hi Andreas,

On 29/04/09 07:58, Andreas Jellinghaus wrote:
> /lib/udev/rules.d/40-openct.rules
> replace
> ENV{MODALIAS}=="usb:v0529p0514", RUN+="/lib/udev/openct_usb"
> with
> ENV{MODALIAS}=="usb:v0529p0514*", RUN+="/lib/udev/openct_usb"
>
> and it should work.

I made the change but it didn't work for me, possibly because I'm using
an eToken 64 (sorry for any confusion).

When I plug in my token I see the following in /var/log/daemon:

  Apr 29 09:41:03 toad ifdhandler[13251]: ifd_open: trying to open
etoken64@usb:/dev/
  Apr 29 09:41:03 toad ifdhandler[13251]: Unable to open USB device
/dev/: Is a directory
  Apr 29 09:41:03 toad ifdhandler[13251]: usb:/dev/: initialization
failed (driver etoken64)
  Apr 29 09:41:03 toad ifdhandler[13251]: unable to open reader etoken64
usb /dev/

so it's not getting "/dev/" as a device name.

Whereas, if I run /etc/init.d/openct restart I see:

  Apr 29 09:44:50 toad ifdhandler[13320]: ifd_open: trying to open
etoken64@usb:/dev/bus/usb/004/015
  Apr 29 09:44:50 toad ifdhandler[13320]: usb_set_params: called. config
xffffffff ifc x00 eps xffffffff/xffffffff
  Apr 29 09:44:50 toad ifdhandler[13320]: ifdhandler_poll_presence: card
status change: 0 -> 1

I will respond to your previous message shortly.

Thanks,

David

On 28/04/09 22:06, Andreas Jellinghaus wrote:
> can you check which configuration the ubuntu package has?
> a hal file (official suggestion), an udev rule or a hotplug map file?

It seems to use a udev rule file, /lib/udev/rules.d/40-openct.rules

> if so, what is the usb vendor and product id, and are those matched
> in that file? what script is configured to be triggered by that file?
>
> can you check if that script is run? (e.g. insert a line
> "touch /tmp/openct-script-is-run" and see if it created
> that file).

It runs /lib/udev/openct_usb and the file is touched.

> if that script is run, can you try inserting these commands:
> exec 2> /tmp/openct-script.log 2>&1
> set -x
>
> re-insert the token and if that log file is created,
> copy it aside and attach it later to this bug.

I added these lines at the top of /lib/udev/openct_usb. The log file was
created but was empty.

> if that script seems to work (no errors etc.)
> check if openct-control/ifdhandler is started by
> the script. you can simply increase debug level
> in openct.conf to 5 or 6 or so, and make sure
> syslog logs them (usualy does, see /var/log/messages
> or something like that), and check if openct is started
> (e.g. messages from openct-control or ifdhandler).

As my previous report showed, I am seeing messages from ifdhandler, but
udev doesn't seem to be giving it a valid device name.

we had problems like this before: the kernel finds out there is a new
usb device. udev gets an event. udev manages both to tell openct
about it and create a file in /dev/ somewhere. but again the communication
is flawed somehow, openct is not told what that new device file is. sad.

lets switch to hal setup, as the udev developers themself tell us to do,
and they don't want programs like openct to use udev directly it seems.
hald setup on the other side is tested and supported, so that seems to
be the better choice.

thanks to a huge amount of work by Stanislav Brabec from suse, openct
has even much better hal setup now, and I created a pre-release from svn
trunk and packaged it for ubuntu, and it works on my machine. can you
give it a try?

        http://www.opensc-project.org/debian/openct/
has the source and diff.gz and amd64 binaries.

if it works I will release openct 0.6.16 soon and hope that both debian and
ubuntu can pick it up to close bugs (or backport the fixes if they prefer that).

Hi Andreas,

On 29/04/09 11:05, Andreas Jellinghaus wrote:
> thanks to a huge amount of work by Stanislav Brabec from suse, openct
> has even much better hal setup now, and I created a pre-release from svn
> trunk and packaged it for ubuntu, and it works on my machine. can you
> give it a try?
>
> http://www.opensc-project.org/debian/openct/
> has the source and diff.gz and amd64 binaries.
>
> if it works I will release openct 0.6.16 soon and hope that both debian and
> ubuntu can pick it up to close bugs (or backport the fixes if they prefer that).

Fantastic! This works perfectly for me: the device is recognised when it
is plugged in and I can use pkcs11-tool to list the slots. And Firefox
can now recognise the device without a restart.

I hope you find that magic key you were looking for... :)

Hi Andreas,

Your openct 0.6.16-0 worked flawlessly for me on i386 platform as well. Any idea when this will go into Jaunty? Any place else we need to request that?

Am Dienstag 19 Mai 2009 06:13:13 schrieb David Medberry:
> Hi Andreas,
>
> Your openct 0.6.16-0 worked flawlessly for me on i386 platform as well.
> Any idea when this will go into Jaunty? Any place else we need to
> request that?
the important wiki pages seem to be
https://wiki.ubuntu.com/StableReleaseUpdates

and
https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff

but I'm not sure how that works out - why put my name in the debian/changelog
file when I can't upload patches/fixes/trigger compiling new packages etc.?

also we can only hope to get a fix included for -updates, if we want
to push the new package, we would need to go for -backports.

debian has a new 0.6.16-1 package, but without any of the changes and
improvements I made, so it still uses udev, maybe works maybe not, has
no documentation included, is compiled with libusb etc. I opened a bug
but got no response so far.

will try to write a debdiff patch for jaunty. but the update policy
will maybe not allow to fix a package only because it is broken and
does not work - the restrictions are quite big :(

Andreas

new debdiff file, please apply / upload fixed package to universe jaunty-updates.

Regarding "exec 2> /tmp/openct-script.log 2>&1" -- this is a mistake. It redirects stderr first to the file then redirects stderr to stdout. That's why the logfile was created but blank. You meant "exec 2> /tmp/openct-script.log 1>&2" to capture both stdout and stderr. Alternatively "exec 2> /tmp/openct-script.log" would suffice because "set -x" outputs on stderr.

The reason the hotplug is failing is that the udev script calls udevinfo which has been subsumed recently by udevadm. Additionally the script is faulty because it will fall through if udevinfo produces no output, since /dev/ satisfies the -n and -e checks.

Here is a patch to fix both problems. I've tested this on karmic (openct-0.6.14-3ubuntu2)

Regarding "exec 2> /tmp/openct-script.log 2>&1" -- this is a mistake. It redirects stderr first to the file then redirects stderr to stdout. That's why the logfile was created but blank. You meant "exec 2> /tmp/openct-script.log 1>&2" to capture both stdout and stderr. Alternatively "exec 2> /tmp/openct-script.log" would suffice because "set -x" outputs on stderr.

The reason the hotplug is failing is that the udev script calls udevinfo which has been subsumed recently by udevadm. Additionally the script is faulty because it will fall through if udevinfo produces no output, since /dev/ satisfies the -n and -e checks.

Here is a patch to fix both problems. I've tested this on karmic (openct-0.6.14-3ubuntu2)

The better fix would be to update to openct-0.6.16 which already handles the switch to udevadm

This bug was fixed in the package openct - 0.6.19-1ubuntu1

---------------
openct (0.6.19-1ubuntu1) lucid; urgency=low

  * Fake merge from debian unstable (LP: #519713)
  * Patch for merge from hal to udev: (LP: #503119) (LP: #436545)
    (Taken from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563755)
    + Changed files:
      - debian/openct.install
      - debian/rules
  * debian/patches/init-script.patch:
    - fix directory creation in init script (LP: #131075)
  * Already fixed bugs, but not closed in LP:
    + "no appropriate entry in fdi file" (LP: #435138)
    + "Openct needs to be restarted when inserting an eToken" (LP: #368683)
    + "openct doesn't recognize etoken" (LP: #246392)
 -- Stephan Hermann <email address hidden> Wed, 10 Feb 2010 10:52:34 +0000