Josh Conway

That's an interesting "hash", that generates new hashes from the same serial#. Sure doesn't sound like any "hash" I've ever heard of before. Ah, so it's **not** a hash. It's generated from a pRNG. I guess undocumented and undefined behavior is the ideal here? Somehow, that doesn't sound ideal. Seriously? Are you actually pulling the "code is the documentation" on me? Wow. This is frankly undocumented, undefined, random behavior by something that clearly shouldn't be. And we're not talking about some random USB hardware - We're talking about physical, soldered on, ain't gonna change hardware. Not to mention, this is also a departure, for who know's reasons, from the stable code that actually seems to do a hash(serial) and outputs a 48bit address. OPI may not have paid for a address block, but not a big deal. Stability is. Period. (Not to mention that SystemD violates one of the core tenants in Unix philosophy: do one thing and do it well. Instead, it does a whole ton of things, and badly.) But yeah, I know nothing about networking :/ I'm only a systems engineer for one of the largest educational NOCs around.

I concur. I tried using "current (unsupported) 4.11.3 kernel" with an Orange Pi Nano , and have the same issue. The MAC address keeps being randomly generated, and not even holding true for the manufacturer, which is the first 1/2 of the MAC. The whole thing's auto-genning every reboot. I need to test the OPI when I get home without a microSD card, to see what the MAC really is for that PHY. I'm guessing it's more fuckery with SystemD and NetworkManager, given this link https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ I know the older Stable release doesn't do this. My money's on SystemD shit.