Orange Pi Zero random MAC address (split from BPi R1 ...)

[jim st]

as of some network release before the current (unsupported) 4.11.3 kernel, the networking has started having random value hw mac addresses on every boot.

 

I suspect if you can do so and look @ your DHCP server, you will possibly see the orangepi (or whatever your hostname is) lurking there.

 

Another way to do it if you have to, is to /sbin/ifconfig and get the HWaddr and look for that mac address on your dhcp server.

 

I came by your post while trying to find a workable solution to assigning the mac on the orangepi  zero 512 I am bringing up.

Jim

[Josh Conway]

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.

[zador.blood.stained]

3 minutes ago, Josh Conway said:

I need to test the OPI when I get home without a microSD card, to see what the MAC really is for that PHY.

There is no "true" MAC address on these boards since there is no storage for it. Normally MAC is generated using a hash function on a part of the SoC serial number.

 

4 minutes ago, Josh Conway said:

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/

On the mainline (unsupported) builds it's just some missing Device Tree properties, most likely missing an ethernet0 alias. And since without an alias u-boot won't set a persistent MAC, a random one will be generated by the driver.

 

8 minutes ago, Josh Conway said:

My money's on SystemD shit.

Or you could have checked the driver code before throwing shit on userspace.

[Josh Conway]

10 minutes ago, zador.blood.stained said:

There is no "true" MAC address on these boards since there is no storage for it. Normally MAC is generated using a hash function on a part of the SoC serial number.

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.

 

10 minutes ago, zador.blood.stained said:

On the mainline (unsupported) builds it's just some missing Device Tree properties, most likely missing an ethernet0 alias. And since without an alias u-boot won't set a persistent MAC, a random one will be generated by the driver.

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.

 

10 minutes ago, zador.blood.stained said:

Or you could have checked the driver code before throwing shit on userspace.

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.

Edited August 10, 2017 by Josh Conway
Added deviation from stable code section

[zador.blood.stained]

1 hour ago, Josh Conway said:

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.

Apart from some migration issues, the hash from a fixed serial will be constant (Edit: well, it's not a hash in the true sense of the word since it uses part of the SID directly and crc32 of another part of the SID). Whether MAC address will be generated using that hash or not is the question, and, as I said, if the MAC is random, then it's due to the Device Tree configuration, and it is a board specific problem since each board uses its own Device Tree.

Just for the reference: http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=800f412b383ddf9ac90972e50a684c534d40fea4;hb=HEAD#l656

 

1 hour ago, Josh Conway said:

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.

Random ones are not generated from a hash, obviously.

 

1 hour ago, Josh Conway said:

Seriously? Are you actually pulling the "code is the documentation" on me? Wow.

For some reason I've spent wasted some time and found the exact reason why the MAC is random in some cases. I guess blaming systemd and NetworkManager without trying to understand and debug the problem is easier.

 

1 hour ago, Josh Conway said:

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.

Are you talking about stability in images that are marked "development" and "provided with no support"? For testing/development purposes random MAC is not an issue, completely broken Ethernet is not an issue, even missing CPU frequency scaling and thermal protection is not an issue. As long as it builds without issues and boots to a command prompt on a serial console it's working as intended, everything else is a nice bonus.

[chwe]

On 10.8.2017 at 10:18 PM, Josh Conway said:

But yeah, I know nothing about networking :/ I'm only a systems engineer for one of the largest educational NOCs around.

So, if you're an experienced person in network and driver developer? Perfect, i'm glad to see your PR fixing this issues. My strengths are in drug development, definitely not helpful to solve such issues. But, I'm sometimes a little bit concerned about expectations from people buying the cheapest possible Orange Pi. 

It's like buying a 'Tata Nano' and expect a Mercedes S class (or maybe a VW Golf). This is a cheap device where Xunlong nor Allwinner tried to bring it to mainline. Mainline on OPi 0 is flagged with 'experimental' for a reason. Cause developers know that there's not everything perfect at the moment (and maybe never). If you can't live with it, stay away from mainline on every H2+, H3, A64, H5 device. As you can see on linux-sunxi.org, there are still parts flagged as WIP or not supported yet. 

 

On 10.8.2017 at 10:18 PM, Josh Conway said:

Seriously? Are you actually pulling the "code is the documentation" on me? Wow.

Documentation is an topic on various threads here in the forum. It's important, time consuming and probably not the most exciting stuff for developers who spend hours to bring armbian to work smoothly on all these SBCs in their free time.  Something I know, cause documentation in drug development was probably ~30% of my normal workload (if I would come home from a normal working day, I'm surely not that exited to do more documentation). 

So if you're interested in improving this, I'm sure your helping hand would be very appreciated. 

[@lex]

On 8/7/2017 at 6:52 AM, jim st said:

Another way to do it if you have to, is to /sbin/ifconfig and get the HWaddr and look for that mac address on your dhcp server.

For this reason i am trying to finish this: https://github.com/avafinger/showmyarm as time permits and will be open source hopefully.

[tkaiser]

8 hours ago, @lex said:

https://github.com/avafinger/showmyarm

 

Hmm... port 8888 conflicts with RPi-Monitor and why not simply using already established protocols for the problem? Bonjour/Avahi works flawlessly for over a decade and at least with my DHCP server here (being a popular Fritzbox and implementing some sort of DynDNS updates) if I boot an Orange Pi PC with Armbian all that's needed is a 'ssh root@orangepipc' 30 seconds later.

[@lex]

3 hours ago, tkaiser said:

port 8888 conflicts with RPi-Monitor and why not simply using already established protocols for the problem?

No problem, you can use any port you wish. Protocol used is very simple and works similar to how DHCP client gets its IP, the whole idea is to fire a windows application and with one click you find MAC and IP and fires a putty client to connect to it.

If you have a dozen Orange Pis, another ten Banana Pis plus a bunch of Nano Pis  connected to your network you just fire ssh root@orangepipc what about the others? You have to setup every board and then ssh root@roangepipc-1, ssh root@orangepipc-2 and so one. With showmyarm (TM) you need zero config, choose the one you want to connect from a list, it's a windows world,  but if you like to sweat and configure every new board... Anyway it was and still being a good learning experience 

Edited August 17, 2017 by @lex
(TM) I just had another clever idea, TM showmyarm, @tkaiser, sorry you are late..:)

[adrb]

On 8/17/2017 at 1:57 AM, @lex said:

With showmyarm (TM) you need zero config

 

Installing custom service isn't sounds like "zero config". Sorry , but in current form

it's pretty much useless.

 

That may be somehow useful if it will listen to DHCP requests

and pull new devices to list. That list also should have options to remove or hide device.

 

On 8/17/2017 at 1:57 AM, @lex said:

Anyway it was and still being a good learning experience 

 

Happy to hear that

[@lex]

8 hours ago, adrb said:

Installing custom service

Yes and No. It depends on whether you call DHCP client service a custom service. Install this service when Image is created just like you install DHCP client service, the custom service becomes part of the system. 

Please, forgive me, i did not want to hijack the thread,  just wanted to explain my point about "zero config", it won't happen again..

[Guillaume]

Hi there,

 

I've just been bitten by this bug: the MAC changes at every boot.

The release I'm using: Armbian_5.30_Orangepizero_Debian_jessie_dev_4.11.3

# uname -a
Linux orangepizero 4.11.3-sun8i #8 SMP Tue Jun 13 14:17:33 CEST 2017 armv7l GNU/Linux

 

Do you have any suggestion about what files to patch to have a fixed MAC ?

 

I've found another topic why seems related:

But the solution about the device tree modification is not very clear to me...

 

Regards,

Guillaume