[uml-devel] Randomize on MAC address when bringing up ethernet iface

[uml-devel] Randomize on MAC address when bringing up ethernet iface

[Blaisorblade]

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).

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 possibly bit-swap is also used before going on the wire.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Randomize on MAC address when bringing up ethernet iface

[Jason Lunz]

blaisorblade@yahoo.it said:
> 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.

I agree this makes sense. Currently I'm forced to do it in a script.

It's especially silly that uml virtual ethernet devices *don't* get
random mac addresses automatically, while tuntap virtual ethernet
devices *do* (in the same kernel tree!).

> Conditions: the broadcast bit must be 0 and the "locally-assigned address 
> flag" must be 1 (as likely we already do).

random_ether_addr() in include/linux/etherdevice.h already takes care of
this.

Jason



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Randomize on MAC address when bringing up ethernet iface

[Blaisorblade]

On Wednesday 31 May 2006 19:09, Jason Lunz wrote:
> blaisorblade@yahoo.it said:
> > 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.

> I agree this makes sense. Currently I'm forced to do it in a script.
>
> It's especially silly that uml virtual ethernet devices *don't* get
> random mac addresses automatically, while tuntap virtual ethernet
> devices *do* (in the same kernel tree!).

> > Conditions: the broadcast bit must be 0 and the "locally-assigned address
> > flag" must be 1 (as likely we already do).
>
> random_ether_addr() in include/linux/etherdevice.h already takes care of
> this.

Correct, it would have been a pity if this didn't exist. Thanks a lot!

But because of the bit order problem, when I saw on some messages randomly 
assigned MACs (either for TAP or for some other interfaces) I wrongly thought 
they were global MACs (I expected to see 0x80 as highest-order bit, for 
multicast/broadcast, and 0x40 as "local" flag).
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Randomize on MAC address when bringing up ethernet iface

[Jeff Dike]

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 :-)

				Jeff


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Randomize on MAC address when bringing up ethernet iface

[Jason Lunz]

jdike@addtoit.com said:
> 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 :-)

the other one's the "locally administered" bit.  It's a lot like rfc1918
address space in ipv4, only for ethernet. wikipedia's discussion is
decent:

http://en.wikipedia.org/wiki/MAC_address
http://en.wikipedia.org/wiki/Locally_Administered_Address

those are the only two special mac address bits that i'm aware of.

The effect of setting it is that you ensure that your randomly-generated
mac address will never collide with a globally administered one. Of
course, it might collide with other locally-administered ones.

Jason



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Randomize on MAC address when bringing up ethernet iface

[Blaisorblade]

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)
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel