linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.
>  # ACTION­d 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

      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).