On 2021-01-05, Alexander Dahl <p...@lespocky.de> wrote: > Am 15.12.20 um 18:03 schrieb Grant Edwards: >> After upgrading a small embedded system's net-snmp from 5.7.3 to 5.8, >> snmpd now takes a _long_ time to start up. Snmpd used to start >> "instantly", but now it blocks on /dev/random for as long as 3-5 >> minutes. This holds up my entire system startup unacceptably. > > Newer versions of dropbear also do this, and IIRC and as you said also > daemons depending on OpenSSL 1.1
We haven't noticed problems with dropbear 2020.81. There's an expected delay if it needs to generate host-keys, but it only does that one time after initial production or a "reset-to-factory". >> Is there any way to avoid this disruptive behavior? > > On our embedded devices we start haveged [1] [2] quite early in boot > process on systems without hwrng. On systems with very low memory we > stop haveged once everything else is started. > > This has drawbacks, some crypto experts would not recommend "creating > entropy from cpu timing jitter" (there's also jitterentropy-rngd [3] as > an alternative to haveged). Thanks for the pointers > On the other hand I think, daemons requiring good random values should > actually block until those are available. It would be OK if snmpd forked into the background and _then_ waited for entropy, but it blocks before it forks thus holding up the entire boot sequence. For now, we've disabled SSL support in snmpd, and that solved the immediate problem. > I'm not sure if net-snmp needs that kind of good random values at > startup? I consider it essential for generating keys. I assume it's generating host keys for SSL every time it starts up, but I didn't have time to track down the details and try to fix it. -- Grant _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
