From: Jan Just Keijser <janjust@nikhef.nl>
To: linux-hotplug@vger.kernel.org
Subject: Re: Fedora Core 5, Aladdin eToken PRO32 and udev hotplug
Date: Thu, 05 Apr 2007 09:24:08 +0000 [thread overview]
Message-ID: <4614C038.70307@nikhef.nl> (raw)
In-Reply-To: <46092CC9.9000106@nikhef.nl>
hi all,
just for the record: I finally managed to figure out what goes wrong.
It's a nice catch-22 :
- etoken usb stick is inserted
- udev calls etoken.hotplug script based on rule BUS="usb",
SUBSYSTEM="usb"
- etoken.hotplug script sends a message to the etokend deamon
- the etokend daemon wants to talk to the etoken stick using the 'char'
device /dev/bus/usb/XXX:YYY to enable the device
- however, the char device is not created until after the etoken.hotplug
finishes ... catch-22!
the workaround is to change the udev 'add' rule to call the
etoken.hotplug script *after* the char device has been created by udev.
This means that instead of matching on
ACTION="add", BUS="usb", SUBSYSTEM="usb", \
I am now matching on
ACTION="add", SUBSYSTEM="usb_device", \
and I can happily insert and remove the etoken stick over and over and
over ;-)
cheers,
Jan Just Keijser
System Integrator
NIKHEF
Amsterdam
Jan Just Keijser wrote:
> hi all,
>
> I've got a weird problem with the udev-way of hotplugging things.
> here's my setup. It's a bit long, so please bear with me ;-)
> - Fedora Core 5, kernel 2.6.20, i686
> - udev-084-13.fc5.2 (FC5 default)
> - Aladdin eToken PRO32 with CardOS 4.21 (*NOT* recognized by
> OpenCT/OpenSC); this is a USB stick that acts as a smart card for
> storing certificates, private keys etc etc.
> - Aladdin RTE 3.65 eToken software (binaries only).
>
> Here's what happens:
> The RTE eToken software installs a daemon, /usr/local/sbin/etokend,
> which listens on a UNIX socket /var/tmp/.etoken
> It also installs a perl script
> /etc/hotplug.d/usb/etoken.hotplug
> which you're suppose to call when an eToken is inserted or removed;
> the Perl script talks to the etokend daemon using the /var/tmp/.etoken
> UNIX socket.
> This mechanism works fine on CentOS 4 , with the older 'hotplug'
> mechanism installed. I can plug the token in and out as many times as
> I like, and it will be recognized every time.
>
> With FC5 and udev, things get hairier: first , I added a rule in
> /etc/udev/rules.d/20-etoken.rules
> ---
> # add rule
> ACTION="add", BUS="usb", SUBSYSTEM="usb", \
> SYSFS{idVendor}="0529", SYSFS{idProduct}="0600", \
> RUN="/etc/hotplug.d/usb/etoken.hotplug"
> ---
>
> to make sure the Perl thingie is called when I plug in a token. I've
> added debug statements to the etoken.hotplug script and can see that
> it is actually being called when I plug in the token (not when I
> remove it, however).
>
> First gripe: how do I add a rule to call the same script when the
> token in unplugged? When the token is unplugged the SYSFS vars seem to
> be gone.... so how do I create a rule that matches this usb device only?
>
> The script is called, and the very first time I insert the token, it
> works. Yippee for udev!
> However... if I switch tokens, or take it out and put it back in a
> couple of times, then sooner or later it will no longer be recognized.
> I did some tracing and digging and am now stuck:
> - calling the /etc/hotplug.d/usb/etoken.hotplug by hand *ALWAYS*
> causes the thing to come up, e.g.
> # ACTIONd DEVICE=/proc/bus/usb/001/003
> /etc/hotplug.d/usb/etoken.hotplug
> works
> - calling the script from within the udev rules file causes it to
> sometimes work and sometimes not.
> - if I stick 'socat' in between the hotplug script and the etokend
> daemon I can see what data is sent to the etokend daemon. It's the
> same from the command line as it is from within the udev framework.
> Also, with 'socat' in the middle it seems to always work from the
> commandline and merely sometimes from within the udev framework
> - the same script works fine on a CentOS4 box (kernel 2.6.9,
> hotplug-2004_04_01-7.7)
>
> Of course, I'd like the eToken to be recognized by the OS without user
> intervention...
> So the big question for me is: what's so different about how scripts
> are called from within the udev manager vs calling them from the
> commandline? I've checked all environment variables and tried to
> mimick the 'udev' env var set as much as possible on the command line
> (e.g. no PATH, MANPATH, LANG, LC_ALL etc etc) but on the command-line,
> the script always works...
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
prev parent reply other threads:[~2007-04-05 9:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-27 14:40 Fedora Core 5, Aladdin eToken PRO32 and udev hotplug Jan Just Keijser
2007-03-27 18:46 ` Greg KH
2007-03-27 20:36 ` Jan Just Keijser
2007-03-27 23:33 ` Kay Sievers
2007-04-05 9:24 ` Jan Just Keijser [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4614C038.70307@nikhef.nl \
--to=janjust@nikhef.nl \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).