>let's consider the example of a large organisation deploying Linux >automatically on lots of machines...the probability of real >collisions within the organisation is no longer negligible.
Speaking of that I once experienced a similar issue, where a building-wide power outage shortly after our product system was widely-deployed internally resulted in none of the diskless workstations coming up! There was a bug in the boot logic that meant the servers filled their client tables with machines they _didn't_ serve. It took all day for the systems to come up, it wasn't obvious that the workaround was to power them mostly all off and bring them up serially. Subtle scaling problems can be great fun, since by the time they're noticed getting a proper solution could be quite painful. (For us, at least, all it took was a software upgrade. I couldn't even tell you how many months it took before _that_ was even complete.) One should always seed PRNG's with the best entropy available, and MAC addresses are already nearly guaranteed to be unique and are eminently suitable for a seed component. I can see how poorly-written emulators that always used the same number(s) would be a problem, but they needn't be quite so stupid. If they have to make up numbers they could do worse than to grab one of the real MAC's and set the locally-assigned bit on it, then start incrementing it in the OUI bits or something for successive numbers. Still not perfect, but better than nothing. It's a rare system that would connect to the Internet only via non-Ethernet, and that didn't also have a MAC address available to it to grab even if it wasn't using it as an interface. I'd argue that any scheme that relied on nobody else in the world ever coming up with the same ID number, by contemplating only its own navel(s), is inherently flawed. It's like using hashing without the full key check to back it up. -- Jim _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
