Hostapd Combined tcz Help

[sodface]

I'm making a single combined tcz for hostapd, dnsmasq and the deps.  I'm (seemingly) not having any issues making the tcz itself but hostapd is giving me a "not enough entropy" error when starting it.

Based on this post:
http://forum.tinycorelinux.net/index.php/topic,16181.msg96091.html#msg96091

I did this which fixed it (ignoring any discussion on which is more cryptographically secure):

Code: [Select]

mv /dev/random /dev/random_old
ln -s /dev/urandom /dev/random

So I wanted to make the changes to the device files happen as part of the tcz install.  I tried:
- making the /usr/local/tce.installed script (same name as package without extension) with the above commands but it doesn't do anything.  Doesn't throw any errors during tce-load but the device files are not changed.  I can then manually run the script after the tcz is loaded and it works just fine.  Permissions were root.staff 755 with +x on the file.  I made another combined tcz for wifi which has a script that does run correctly though it's not trying to make any changes to /dev so I think I'm building the package and setting file permissions correctly.

- next I tried just copying the device files into the tcz package itself thinking they would just replace the originals when the package was loaded.  That didn't work either.

- I also tried the -f option of tce-load for "Overwrite system files" which sounded promising but had no affect for either the script version of the package or the version with no script but device files added to the package.

I guess I can put the commands in one of the system startup scripts like bootsync.sh or bootlocal.sh but I thought it would be a little cleaner to just have it taken care of when you install the package.

What am I missing?

[sodface]

Adding the commands to bootlocal.sh works, but it's temporary as I think udevd changes them back, I ran into this before working with the camera module and I had to create a udev rule for the vchiq device.  Looks like at this point I'll need to look at udev rules or maybe starting hostapd with the -e option and an entropy file.

[Rich]

Hi sodface

... Doesn't throw any errors during tce-load but the device files are not changed. ...

Try adding the  syslog  bootcode. Then, use  tce-load  to load the extension. Look in  /var/log/messages  and see if any
errors were logged in there.

[sodface]

Thanks for the reply Rich but I think I know what's going on, the script may have actually run but I think the udev rules are clobbering the changes.  I'm going to create a udev rule:

# Remove any existing /dev/random, then create symlink /dev/random pointing to
# /dev/urandom
KERNEL=="urandom", PROGRAM+="/bin/rm -f /dev/random", SYMLINK+="random"

and a package script to trigger udevd:

# udevadm control --reload-rules && udevadm trigger

Have to leave but will post results later.

[sodface]

The udev rule along with the tce.installed script seems to have worked.

[Paul_123]

hostapd is one of my packages, I see the entropy log message,  It just takes time for the system to generate enough entropy.   Entropy is a weakness of the embedded system.   hostapd will also "create" the randomness internally.

As you said, the correct way to generate randomness in a cryptographic sense is a long discussion that will change based on who you talk to.

[sodface]

Thanks for the comment Paul_123 (and the package).  Unless you see an issue with my fix above I'll probably just press on with it.  I want the AP to become available as soon as possible after the package is loaded.  I'm just going to use it as a fall back for system administration in the event that the primary comm path fails to connect (cellular modem).   So during normal operation hostapd won't be needed and in fact won't be loaded unless it is and then it's just to allow me to connect to troubleshoot, so typically only a single user connected (me).

[Paul_123]

I did some testing,  as I was doing this manually, it was obviously slower than a start at boot.   But hostapd started just fine, but if I stop and restart it quickly, then I'll get message similar to

Code: [Select]

random: Cannot read from /dev/random: Resource temporarily unavailable
random: Only 0/20 bytes of strong random data available from /dev/random
random: Not enough entropy pool available for secure operations
WPA: Not enough entropy in random pool for secure operations - update keys later when the first station connects

On this test RPI3 system running 4.14.48 kernel, it takes 8.5 seconds during boot for the random pool to initialize.  After that the system generates bytes for /dev/random at a rate of ~20 bytes per minute.  So it's perfectly reasonable for what you are seeing.

[sodface]

During my googling, I saw some references to the rng-tools package to make use of the hardware random number generator, were you using that during your testing?

[Paul_123]

Intel processors do have hardware support, but arm processors typically do not.   AFAIK, rpi has not added anything to give us hardware random support.

[sodface]

http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/

[Paul_123]

Never knew that the rpi had that......that driver is now compiled in by default in to the kernel, so by running rngd, /dev/random stays nice and full now.

[sodface]

Paul_123 - I'm a little confused still, rngd comes with rng-tools right but I don't see it in the v6 repo?  Are you testing with piCore or something else?

[Paul_123]

I run a custom version of a piCore based system.   I compiled rng-tools myself.

[sodface]

I run a custom version of a piCore based system.   I compiled rng-tools myself.

Got it, thanks.  So this is probably a "better" fix than pointing /dev/random at /dev/urandom.