Hi Joe,
Am Dienstag 29 Mai 2012, 23:08:23 schrieb Joe Hershberger:
Hi Michael,
On Tue, May 29, 2012 at 1:23 PM, Michael Walle michael@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).
yeah i'll fix that.
You also haven't addressed the issue of isolating the link-local algorithm from other non-MAC-seeded random numbers.
Ah now i get it. But which other code may run and seed the NG with the timer only, while we are in the link local netloop? Shouldn't it be safe to first call srand(mac+timer) and then rand() multiple times? No other code can be run unless NetLoop(LINKLOCAL) returns, right?
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.
i think we should focus on combining not reinventing the wheel multiple times.