Hi Michael, On Tue, May 29, 2012 at 1:23 PM, Michael Walle <mich...@walle.cc> wrote: > Hi Joe, > > Am Dienstag 29 Mai 2012, 20:08:26 schrieb Joe Hershberger: >> If you can verify that the functionality of the >> CONFIG_BOOTP_RANDOM_DELAY and CONFIG_CMD_LINK_LOCAL are uneffected, >> then I'm OK with it. >> >> One thing to note is that the link-local implementation needs to use a >> MAC seeded random number. That means we can't have other things >> coming in and seeding it with a time. It is nice that it is separate >> for that reason. Can you solve that and integrate it with your PRNG? > > I'm in a hurry, short answer for now: > I thought of sth like this: > > static inline void srand_mac(void) > { > unsigned char enetaddr[6]; > unsigned int seed; > > /* get our mac */ > eth_getenv_enetaddr("ethaddr", enetaddr); > > seed = enetaddr[5]; > seed |= enetaddr[4] << 8; > seed |= enetaddr[3] << 16; > seed |= enetaddr[2] << 24; > > srand(seed); > }
I'm not sure why you are only seeding with the last 4 bytes of the MAC. The original algorithm used all 6 (in its way). You also haven't addressed the issue of isolating the link-local algorithm from other non-MAC-seeded random numbers. The most naive way around it would be to rename the rand() in net to rand_mac() or something like that and not attempt to combine them. -Joe _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot