Getting started under fedora core 13

[Rob Kendrick]

On Fri, Oct 08, 2010 at 05:13:19PM -0400, Timothe Litt wrote:

Hi,

> OS: Fedora core 13 (Kernel = 2.6.34.6)
> 
> I installed the x86_64 rpms for ekd and egd from the simtec website; 
> lua stuff from fedora packages (which are newer than those on the website).

As you discovered later, the Red Hat LuaSocket packages are missing
functionality, which is why we provide our own.  At some point, I'm sure
we filed a bug about this.

> cat from /dev/ttyACM0 gets an infinite stream of "Unknown Input Character
> 0x20" and 
> "k>Unable to send entropy.  Please re-key session.   J6cWOFgM"

This suggests that something is sending spaces (0x20) to the serial
port.  You might want to try `fuser /dev/ttyACM0` or similar to see if
another daemon has opened it.

The error about being unable to send entropy is expected; ekeyd needs to
set up a session key with the device.

> ekeydctl list yields the rather mysterious:
> 	Internal error: /usr/sbin/ekeydctl:101: attempt to call field 'unix'
> (a nil value)
> 
> Not being much of a lua person, I did find that line 101 of control.lua is:
> 	 local sock = type(sockorname) == "string" and
> controlsockets[sockorname] or sockorname
> 
> But starting the daemon elucidates with the rather clearer:
>   control.lua:755: control.lua:538: UNIX Domain sockets not supported by
> LuaSocket
> 
> *** Problem 1:
> 	Why aren't domain sockets available?  Are you patching lua/socket?
> If so,
> 	the patch needs to go upstream so fedora builds with it.  Fedora's
> version
> 	is 2.0.2-4.fc12.

We don't patch LuaSocket as such, we simply enable Unix Domain Socket
functionality in it.  LuaSocket's build system leaves something to be
desired, and it doesn't automatically enable this if they are available
at build time.  Debian's, Ubuntu's and I believe SuSE's (and the BSDs we
support)packages have this enabled; we have to provide our own Red Hat
packages with it enabled because the stock ones do not.  As I said above,
I'm sure somebody has filed a bug about this, but we should chase it up.

> --- /etc/init.d/ekeyd~  2010-09-06 09:42:58.000000000 -0400
> +++ /etc/init.d/ekeyd   2010-10-08 15:31:35.830274733 -0400
> @@ -34,12 +34,13 @@
> 
>  start() {
>      echo -n $"Starting $prog: "
>      $exec
>      retval=$?
> +    [ $retval -ne 0 ] && failure
> +    [ $retval -eq 0 ] && success && touch $lockfile
>      echo
> -    [ $retval -eq 0 ] && touch $lockfile
>      return $retval
>  }
> 
>  stop() {
>      echo -n $"Stopping $prog: "

We will incorporate this patch into our RHEL packages going forward if
the some issue occures on RHEL/CentOS.

> Well, we can create that by hand.
> 	Now, looking at the udev rules and ekeyd.conf, it looks like 
> 	we need a symlink from /dev/entropykey/<serial> to the /dev/ttyACM0
> device.

It is possible that Fedora have moved their rules.d directory delative
to previous Red Hat-based systems.  The main issue is that we don't use
any RPM-based systems here, and thus have no developers who are skilled
in packaging for it.  Our supplied udev rules should be capable of
making the right directories.  Ideally, we need somebody from the Fedora
project to package this for us!

> *** Does it matter which character replaces '/'?

Most udev-based systems replace '/' with either '_' or '.', both of
which our software can handle.  (Unfortunately, we do not control the
serial number of these devices; they are the unique IDs provided by the
CPU inside each device.)  If your system is not, then we need to look
into that.

> But:
> 
> *** Problem 7:
> 	/etc/init.d/ekeyd restart
> 	ekeydctl stats M/9mBjBLNzFFRyFD
> 	ERROR control.lua:210: attempt to index field '?' (a nil value)
> 
> 	ekeydctl list
> 	NR,OK,Status,Path,SerialNo
> 	1,YES,Running OK,/dev/entropykey/M.9mBjBLNzFFRyFD,M/9mBjBLNzFFRyFD
> 
> The error goes away if one waits a minute or so - but it still shouldn't be
> happening.

This one is confusing.  We have never experienced this before, and we
need to attempt to reproduce it before we can speculate much further.
The line in question in control.lua implies that the KeyBadness
information is not available, which is odd because it should be
avaialble very soon after the key is initialised.

However, there is clearly a race condition which we need to isolate and
correct.  We shall investigate.

> But we're not done:
> 	reboot the system
> 
> *** Problem 8:
> 	/dev/entropykey does not exist
> 
> This is problem 3 in disguise.  So we need a fixup script until
> autoconfiguration works:

<snip script and init patch>

This is not a solution to the problem you are seeing.  The real problem
is that the rules for the Entropy Key haven't been installed properly
into your udev environment.  Particularly, there are two sets of rules
which conflict if they are both present.  (One for the kernel ACM
driver, and one for the userland driver.)  Given your ttyACM0 works, we
can assume you do not need the ulusbd rule set.  To that end, can you
please confirm if you have the UDEKEY01.rules file installed somewhere
(or symlinked somewhere) appropriate, such as /lib/udev/rules.d/ or
/etc/udev/rules.d/ ?

Your experience unfortunately shows us that we desperately need someone
in the Fedora community to take over packaging for us, so that they
aren't made by somebody without real-world experience of RPM packaging.
Do you happen to know if there's somewhere where we can raise this?

Hope this helps,
-- 
Rob Kendrick, Support Team Lead                      Simtec Electronics
Telephone: +44 (0)1772 978013                  Avondale Drive, Tarleton
Fax: +44 (0)1772 816426                     Preston, Lancs, PR4 6AX, UK
http://www.simtec.co.uk/                       mailto:rjek at simtec.co.uk