On Wednesday 31 May 2006 21:05, Jeff Dike wrote:
> On Tue, May 30, 2006 at 08:12:59PM +0200, Blaisorblade wrote:
> > I've being thinking to this and I'm wondering why we shouldn't do it.
> > When we have set no IP or 0.0.0.0, which is not a unique IP, and we bring
> > it up, we should choose a random MAC to use.
> > Conditions: the broadcast bit must be 0 and the "locally-assigned address
> > flag" must be 1 (as likely we already do).
> Yeah, this sounds like a good idea.
> > For which bits they are, I've a doubt.
> > On Tanenbaum's book they're marked as the two most significant (leftmost)
> > bits (broadcast being the most significant one), but since we've longly
> > known the broadcast bit is the lowest-order one of the highest bit, I
> > suspect that MACs are read in little-endian bit order (which likely
> > implies the same for the whole packets). I can't verify this, but bytes
> > in many fields are moved to be in network order i.e. big-endian order
> > (MACs are always used in the network order).
> So what is the second bit? I only know about the broadcast/multicast bit,
> and no one has bothered clueing me in on any other special bits :-)
Look at the other answer (which points to include/linux/etherdevice.h:
random_ether_addr()) for the bit position - the code pointed out shows that
indeed bit are reversed from the "text-book order".
For the "locally assigned", I guess that means we'll never conflict with a MAC
set on some NIC.
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
Chiacchiera con i tuoi amici in tempo reale!