Yup; totally different from wireless NIC onboard. If you look in Dell’s BIOS setup on a supported system you’ll see both listed and if you happen to have an onboard ethernet controller, you’ll see all 3!
With the efivar approach might it be possible to do pairings?
e.g. a way of saying…
”If the user attaches a NIC (whether that’s a normal USB NIC, Framework ethernet module, or a dock) with MAC addresses … x, y or z… then swap that MAC for the ‘internal MAC’ which comes with the laptop. Also always prioritize which device gets to have that ‘internal MAC’ in the order of x, y, and z.”
Then ‘x’, and ‘y’ might be specific docks (e.g. WD19TB) and ‘z’ might be a specific Framework ethernet module… all of which you own and expect to sometimes find yourself using. But if you connect to some other unknown dock (or connect some other Framework ethernet module) then that MAC won’t be overridden.
Thus you get the best of both worlds… if there are certain USB NIC’s and Docks you know you use your laptop with… and you want a consistent MAC on that network (for whatever reason) then you can.
But if you connect to an unknown dock (e.g. a dock at a friends house or hot-desk setup at a workplace) then you’ll get the MAC of the dock instead… which might be better for working with their network anyway (as their network might be more prepared for that).
The part of the idea which mentions priorities, means that… if someone connects multiple Framework ethernet modules… or has just 1 of those installed but also connects up to a dock… then it knows which “thing” has priority to get the “internal MAC”… switching it as needed.
Oh and not to mention… I believe stuff like ‘Network Manager’ can associate whichever network config profile you want to whichever NIC has a particular MAC.
So this is a great way to save the user time swapping network connection to use… as it’d just ‘automagically’ switch over.
There is a fuse in realtek Network devices that can be blown to indicate it should use a pass through MAC if available. That’s what the driver looks at.
Think of this efivar idea as just another source of the MAC because your BIOS wouldn’t have one.
Then I’m guessing the Framework ethernet module is realtek and has that fuse. (or it’s some other chipset with a similar fuse).
But presumably it’s then entirely up to the OS to do this MAC swapping? So that idea I was describing about “MAC pairing” and “priorities”… am I basically seeking all this to be in the Linux kernel? Not a BIOS level thing? (except for storing the “internal MAC” as an efivar for the OS to read from)
Have I got that right? I was kind of hoping that this could be done at a higher/hardware level… but I’m guessing even the Dell stuff doesn’t do that?
Well on Dell it actually happens pre OS as well because the BIOS copies the MAC into the NIC for any BIOS NIC drivers.
This was a big argument about landing it in the kernel actually. If you PXE boot then you expect your NIC is consistent in the kernel.
But yes any policies for which to pick on this architecture are done in kernel.
OK so final idea…
efivar 0 - optionally stores the pass-through MAC you might want to use
efivar 1 - optionally stores the highest priority MAC that belongs to a device (USB NIC, dock, etc…) that may or may-not be connected at power on time… or connected even after that
efivar 2 - optionally stores the second highest priority…. blah blah
efivar 3 - optionally……blah…. third highest… blah
efivar 4 - optionally……blah…. fourth highest… blah
efivar 5 - optionally……blah…. fifth highest… blah
So at power on… the BIOS (that’d need to be re-issued with this feature) enumerates all the MACs of the devices it sees connected (NICs, docks, etc..) and whichever has the highest priority (checking efivars 1 to 5) gets overridden with efivar 0 which will even work for pxeboot purposes.
The Linux kernel could do the same thing when it boots up… except the only difference is it should keep watching devices (NICs, docks, etc..) when connected and disconnected and continue to swap the pass-through MAC to whichever one is the highest priority at any given moment.
Sound … err… unlikely to happen?… but yet plausibly workable ? 
I mean if there are some enterprise/corporate-like use cases for this which Dell (or similar vendors with this feature) are catering for with this feature… especially in hot-desk environments… then it could attract them to Framework more I guess.
Course the biggest hurdle is the customer figuring out (again optionally) which MAC to put in efivar 0… but I guess going forwards Framework could themselves populate that at the factory. But still leave the function there for anyone who already bought a machine and didn’t have it pre-populated.
I mean… technically this design is MORE flexible than Dell. As your pass-through MAC can then easily migrate from one to another whilst they’re both connected. This behavior shouldn’t confuse the user as… a) it’s all optional and b) they’d have had to have set it up this way anyway.
Two problems I see.
- Framework doesn’t ship with a cmos battery. These variables are lost if your laptop goes dead because they don’t go to SPI part.
- This requires some pretty in depth BIOS work
If you want to do it all yourself and ignore the pxe case I think you can modify the Linux kernel and it should work though.
True, so maybe we’re back to ACPI not efivars
But 6 macs is like… what? 30 bytes? I don’t know how much SPI space there is left to play with… but could this be addressed with a BIOS update?
I think that’s unlikely. Changing the flash storage regions is difficult in the field.
But you can certainly request it to framework.
Is there an official way to propose something like this? I assume you don’t mean just talking on this forum.
You could message support directly or raise an issue on GitHub but I wouldn’t expect much.