All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.