Setting MAC address of Host Only Ethernet Adapter

[ssh9614]

I have a legitimate reason for reason for wanting to set the MAC address of the host only Ethernet adapter on the host machine (Win7). The guests I'm running will only communicate with a static list of MAC addresses (for security reasons).
As far as I understand, the host only Ethernet adapter is hard coded. Some searches on Google suggests it could possibly be changed from the registry editor. However, I was not able to find any relevant entry in the registry.
I would like to suggest adding a feature to enable setting this MAC address from the command line or from the graphical user interface.
/Ted

[socratis]

The guests I'm running will only communicate with a static list of MAC addresses (for security reasons).

The guest or a program on the guest? And I assume that this is not changeable, right?

As far as I understand, the host only Ethernet adapter is hard coded.

That would be correct. The VendorID is statically set to "0a:00:27". The first part, the vendor part, is set in two places: VBoxNetAdp-win.cpp (Windows) and VBoxNetAdp.c (the rest), search for "OUI". What is funny is that I can't find it in any of the reverse MAC-to-vendor databases, someone should file for it...

Even if you could change the MAC, I'm not sure if they'd be flexible enough to change it to a random MAC, there may be restrictions.

---

Almost off-topic, if anyone knows, I'd appreciate it... I can't understand the part that goes:

pMac->au8[0] = 0x08 | 2;
pMac->au8[1] = 0x00;
pMac->au8[2] = 0x27;

why they didn't simply go with:

pMac->au8[0] = 0x0a;
pMac->au8[1] = 0x00;
pMac->au8[2] = 0x27;

[mpack]

Almost off-topic, if anyone knows, I'd appreciate it... I can't understand the part that goes:

Because using 0x0A would be a bad practice called "using magic numbers".

There will be docs somewhere which says what the 0x08 and 0x02 flags do, but not what 0x0A does. So you'd either have to insert a comment explaining where the 0x0A magic number came from, or forget the comment and just show where it came from, as in the code. The compiler produces the same code either way (0x08|0x02 is resolved by the compiler, no code is emitted for it), hence you should always default to a form that makes the intention as clear as possible. Think of the children! (who come along in future to maintain your code).

Even better would have been if whomever wrote this code had used defined symbols instead of 0x8 and 0x2.

[ssh9614]

The guest or a program on the guest? And I assume that this is not changeable, right?

It is limited in the operating system software. I can change them but it would not be my first choice. What I could probably do is to turn my host machine (used for development) into a guest also and thereby allowing me to set the MAC address on the network adapter. It would however be preferable if it could be done directly on the Host Only Adapter.

Even if you could change the MAC, I'm not sure if they'd be flexible enough to change it to a random MAC, there may be restrictions.

As for Vitualbox I have no idea if there would be any additional limitations. Common Intel NICs do seem quite lax about which MAC address ("Locally administered address") that can be used. The only limitations seems to be:

• Do not use a multicast address (least significant bit of the high megabyte = 1). For example, in the address 0Y123456789A, Y cannot be an odd number. Y must be 0, 2, 4, 6, 8, A, C, or E.
• Do not use all 0s or all Fs.

[socratis]

@ssh9614
I don't know enough on the subject, just enough to be ignorantly dangerous...

Because using 0x0A would be a bad practice called "using magic numbers". There will be docs somewhere which says what the 0x08 and 0x02 flags do, but not what 0x0A does.

To me they all seem like "magic numbers". If 0x0a is one, so is 0x00, so is 0x27. And so are 0x08 and 0x02...

I'll see if I can get an answer from the devs on IRC come Monday, and if I do, I'll post it here, just for completion...

[mpack]

0x08 and 2 are both single bit values, obviously flags, (the expression 0x8|2 clearly says "I'm setting two flags", which is the question you asked): in my companies coding guidelines they should have been defined symbols which make their purpose obvious, so yes they are magic numbers too.

[andyp73]

This is something very nerdy that I remember from a project (years ago) when I was creating custom MAC addresses.

pMac->au8[0] (as it is in the VirtualBox source code) is Octet 0 of the Company ID (CID) within the EUI-48 standard (Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)).

The four least significant bits of Octet 0 are designated the M bit, X bit, Y bit, and Z bit, respectively, beginning with the least significant bit. In the CID, the M, X, Y, and Z bits have the values 0, 1, 0, and 1, respectively.

In respect of the original question then I expect that the other values can be changed but pMac->au8[0] will need to be left as is.

Our static analysis process would have complained about the use of 0x08 and 2. It's "magic number" checker complains about anything other than 0 or 1 being used without using defined symbols!

-Andy.

[socratis]

From a developer on IRC:

- Why "0x08 | 0x02" and not straight "0x0a"...
- It's derived from the usual 080027 OUI, but with a twist (to avoid collisions with the MAC addresses of VMs) : 0x02 in the first byte means "locally administered".

Or as Wikipedia puts it in the MAC address: Universal vs. local article:

Addresses can either be universally administered addresses (UAA) or locally administered addresses (LAA)... A locally administered address is assigned to a device by a network administrator, overriding the burned-in address... Universally administered and locally administered addresses are distinguished by setting the second-least-significant bit of the first octet of the address.

or pretty much what "andy73" said, and "ssh9614" described in their second post about the restrictions of the "Y" in their example.

BTW, I guess that's why I couldn't find the manufacturer of "0a:00:27"; it's because it's not on the database, it's not a Universal MAC vendor. The "08:00:27" part however resolves to "PCS Systemtechnik GmbH", or "PcsCompu PCS Computer Systems GmbH".

[klaus]

08:00:27 is the OUI which is used by VirtualBox since day 1 (I personally have a plan to use an already existing but unused OUI which officially is assigned to Oracle, but that's a long term project I fear). The or-ing of the first byte with 2 (which is the "locally administered" bit) makes sure that the host side cannot possibly clash with the MAC address of any VM.