2010-02-04 14:11:52     random() function

Document created by Aaronwu Employee on Sep 26, 2013
Version 1Show Document
  • View in full screen mode

2010-02-04 14:11:52     random() function

Hans Waldmann (UNITED STATES)

Message: 85615   




I am seeing that the random() function is generating the same number each time we reboot. This is happening on 2008r1 on a BF537. I am guessing this is part of uClibc. Has this been seen before?






2010-02-04 14:22:24     Re: random() function

Mike Frysinger (UNITED STATES)

Message: 85616   


this is by "design".  the system has no entropy and has no way of generating more.  if you want different behavior, you must handle the design -- you need to either provide entropy, or save/restore the random seed.


this really has nothing to do with uClibc or anything else in the toolchain.


on boot: cat /var/some/seed > /dev/urandom

on shutdown: dd if=/dev/urandom of=/var/some/seed count=1




2010-02-04 14:34:14     Re: random() function

Hans Waldmann (UNITED STATES)

Message: 85619   


The problem we are seeing is that dhcpcd is using random() to generate its transaction id. If several boards boot at the same time and they use the same transaction id, then some of them end up having the same IP addr. Not sure if anyone else has seen this problem before, but it seems pretty fundamental.


Is random() as part of the uClibc C library? Where is the code for this function?


I am not so familiar with this function, but you seem to be showing that the random number is generated from the /dev/urandom file which in my case is the same each time I boot up?


I am thinking about using the cycles register to generate the random 32 bit number.




2010-02-04 14:41:42     Re: random() function

Mike Frysinger (UNITED STATES)

Message: 85620   


then implement support for RFC4361:



considering every board needs a unique MAC, it doesnt seem like it'd be hard.


the random() implementation is irrelevant.  uClibc gets its data from the kernel (/dev/urandom).  you need to fix the underlying problem.  so screwing with cycles instead of random() is just as wrong.


if you wanted to do something hacky like combine cycles and time(0) and the mac address and feed that into /dev/urandom on boot, it'd certainly be more correct.




2010-02-04 16:41:53     Re: random() function

Hans Waldmann (UNITED STATES)

Message: 85628   


I am not really sure what RFC 4361 has to do with it. From what I can tell, the main problem is that the random() function is not really generating a random number. At least not the way we are using it. If this was giving a true random number, not one which is the same on every board after bootup, then this problem would be solved.


I am also not really sure where urandom seed is coming from. I think it might be some default file in the kernel build? I do agree that this is the root cause of the problem and this is what needs to be more random than what it is now.


Given that so far I did not know about this problem, I am guessing that other may face the same issue. Wouldnt be in everyones best interest if we provided some sort of fix to this that all customers could benefit from?




2010-02-04 16:50:45     Re: random() function

Mike Frysinger (UNITED STATES)

Message: 85629   


if you had a proper unique id per client (perhaps based on the always-unique MAC), then the randomness of random() wouldnt matter.


ive already told you the problem: lack of entropy and you arent seeding the random generator.  there is no way to fix this without you designing something into your system.  the Blackfin processor has no source of true entropy thus it cant be solved in a common manner.  find me a common entropy source and i can fix it (we've looked a few times).


it is up to you to maintain the random seed in persistent storage and feed it back into /dev/urandom.  if the seed doesnt yet exist, use some random things i already suggested to seed it.


this is no different than your desktop running Linux.  look at the boot scripts and you'll find them doing the exact same thing -- saving the seed at shutdown and restoring it during boot.  desktops though have the luxury of noisy peripheral inputs and random generators.




2010-02-04 17:45:24     Re: random() function

Mike Frysinger (UNITED STATES)

Message: 85630   


ok, some of what i said isnt entirely true.  the C library random() function gives you a list of random numbers based on the initial srandom() seed.  the randomness of random() is only as good as the seed of srandom(), and with the same seed, you'd get the same set of values from random().


so if you took the code:






every uClibc system (by design) should give you the same exact result over and over.


the dhcpcd-new code uses time(NULL)&0xffff as the initial seed, so if you dont have a RTC on your system, the time will always start out as the same value (epoch), thus all your clients will seed things the same.  i dont know which dhcp client you're using though.




2010-02-05 11:27:21     Re: random() function

Hans Waldmann (UNITED STATES)

Message: 85707   


OK, thanks for the info.


We are using dhcpcd-new. I would guess that it is having something to do with our clock then not being initialized.


Does that mean that there is no dependency on the /dev/urandom seed since they are calling srandom() first or is srandom() somehow used in conjunction with the /dev/urandom seed?




2010-02-15 17:16:53     Re: random() function

Mike Frysinger (UNITED STATES)

Message: 86128   


from what i can see, srandom()/random() does not depend on /dev/urandom