|
From: | David Empson |
Subject: | Re: [lwip-users] How to build a simple TCP [...] |
Date: | Fri, 11 Jul 2008 11:39:11 +1200 |
Bob McConnell wrote:
Kieran Mansley wrote:Simon Goldschmidt wrote:Is this something to be afraid of? I didn't think the win32 port would be used in production environments where this matters... But of course we could change this to be defined somwhere instead of calculating it from the real ethernet card's MAC.I think that would be better. It would make it more obvious that the MAC address being used is just made up, and so needs to be carefully chosen.The specs also say that there are some bits in the first two bytes of the MAC that need to be set when it is a virtual NIC instead of a real card. I have implemented that at work for emulations using tap devices on FreeBSD, but don't have the reference here at home.
The second bit transmitted in the first octet of the MAC address identifies the address as "locally administered".
This corresponds to a value of 02 in the first octet when it is written in the usual MSB first order, so an example of a locally administered address would be 02-01-02-03-04-05.
The first octet can have any even value (bit 0 must not be set, because that would identify it as a group address, i.e. broadcast/multicast). The other five octets can be anything.
http://standards.ieee.org/regauth/groupmac/tutorial.html http://en.wikipedia.org/wiki/MAC_addressA locally administered address cannot be allocated by a manufacturer to any production Ethernet hardware, but can be used by network administrators to assign arbitrary MAC addresses for use within their organisation.
Since locally administered MAC addresses are potentially being reused by multiple people, if LWIP picks an arbitrary one it may have a greater chance of encountering a conflict. If LWIP "borrows" an arbitrary universally administered MAC address, there can be only one conflicting device in the whole world.
I suggest using a locally administered address anyway, but it should be well commented to explain the potential for a conflict, and summarise the rules for allocating a different MAC address, in particular not to use an odd value for the first octet (broadcast/multicast).
[Prev in Thread] | Current Thread | [Next in Thread] |