I was just playing around with the OpenWRT environment, and I happened to check this:

# cat /proc/sys/kernel/random/entropy_avail 
0

There is no entropy in the pool for /dev/random.  Sure enough, cat /dev/random hangs forever.

I thought the system used interrupts for entropy, and I also thought there was a mechanism for choosing which interrupts could be used, but apparently under Linux this is done by setting some bits in the driver code.  Thus, it's not something easy to change from the command-line.

In examining /proc/interrupts, it looks like IRQ's 4 and 5 are fine sources of randomness.  One of them is the ethernet, the other the radio, I assume, but I'm not sure which is which.

Unfortunately I can't think of any other sources of randomness that could be used.  And maybe this is not something to be worried about, as perhaps there are no packages that use /dev/random.

In my reading, I found that some crypto experts consider network packet timings to be an insecure source of randomness, because an attacker can possibly control the packet timings and thus influence the random generator.

However, I would suggest that the vast majority of installed WRT's have very random traffic, both on the WAN and LAN side.  I know that my WAN light is constantly flashing due to ARP traffic, and my LAN generates all sorts of weird activity.. 

Are the interrupt handlers installed in Broadcom's closed-source code, and thus can't be influenced?  I'm curious if anyone else has looked into this.

noticed it too.

To circumvent this "problem", I used to change /dev/random to /dev/urandom in the packages I built, but this is not really a solution :?

--
Nico

The best idea I've come up with so far is to hack the "wl.o" and "et.o" binaries to make them pass the SA_RANDOM flag to request_irq().  It might even work.  But I don't yet have a mips disassembler. 

This is an old thread, but in light of the recent report that highlighted openWRT, it should be a hot topic.  I can't understand why my box has been running for weeks and has no entropy.  It is supposed to collect entropy from the network interfaces, but either this doesn't work on this platform for some reason or the code was changed in openWRT.
  I don't think collecting bits from /dev/urandom is a solution.  This one gives you bits whether there is any entropy or not.
  The guys who wrote the recent paper said openWRT would have poor entropy.  It actually has none, so the situation is much worse thany they reported.

The rc5 release switched the network driver and the new driver didn't have network entropy enabled. It's already fixed in svn so just wait for the next release.