Use eth_hw_addr_random() instead of CPU serial# for MAC address on eth0

In the following file:

MAC address is generated using CPU serial # (if this isn’t the right place, I’m assuming it’s done in a similar fashion elsewhere) - in the case of bassackwards devices (such as mine) where a complete shutdown is required to somehow magically reset the CPU serial # can a CoreELEC option be added (in the CoreELEC config tool) that a user can choose to bypass using CPU serial # and instead generate a randomized MAC address using the call to eth_hw_addr_random() or eth_addr_random() under the Network Configuration section, ie:

Generate MAC Address (multi-choice menu I suppose…)

Not sure which is appropriate in this case or perhaps if this is even a proper solution (it’d probably be more useful to figure out why the device does this—since it’s a Chinese box, I’m assuming they mass-flashed these devices with basically the same U-Boot which is why I’m guessing this happens?)

Either way, it would be useful probably only to me I guess but figured I’d ask anyways.

As noted in my rambling thread about this matter, I do have a workaround but it’d be nice to just reboot instead of power down to get a MAC address that doesn’t conflict with other devices on my network as I can then hard-code the device IP-wise.

No the idea of that commit was to stop the issue of random mac addresses being issued on devices that had to valid mac address.

Right - what I’m asking is if it can be made into a toggle - in my case, random MAC would be OK vs the weird duplicate serial # issue my boxes have. Was just an idea.

Your workaround would be to create 99-mac-address.rules file in /storage/.config/udev.rules.d, the content of which should be;
SUBSYSTEM==“net”, KERNEL==“eth0”, RUN+="/sbin/ip link set dev %k address 00:00:00:00:00:00"
(replacing the 00:00:00:00:00:00 with your required MAC) :+1:

Doesn’t work - you and I had this same convo over at the LE forum too :slight_smile: (Not sure if I’m allowed to link to that convo but pretty easy to find) - I ended up pulling down the CoreELEC source and removing the commit and compiling for aarch64 - just waiting for build to complete.

But I appreciate the suggestion!

As an option - the random generation of the MAC address can be deselected in the bootloader configuration.


You can then assign any physical address or leave it as default.

#define CONFIG_ETHADDR         00:15:18:01:81:31
1 Like

Thanks - I’ll give that a whirl if this fails. Basically I can live with randomized MAC address as I’ll hardcode the IP address; these GooBangDoo S905 units are quite nice but this is an actual problem for me since I run three of them around my home. Had the same problem with LE too and just kept the others off but since switching to CoreELEC I figured I’d revisit this again.

LOL, what box are you using? (I just tried it with 8.90.4 and it works on S905 & S905X)

I do vaguely remember, in a previous life, someone mentioning it wouldn’t work for them (and apparently still doesn’t - whaddya know) :thinking:

@Poida the company name is GooBangDoo, model is M8S-II. S905 2GB/8GB 1GBIT Ethernet and Ampack 2.4/5GHz WiFi (b/g/n). Bought 3 off for probably way too much (even at the time) and I’d hate to try and resell them and toss them for something newer (although I have been considering it.)

My problem is that unless I completely power the units down, the CPU serial # is duplicated among all of them which means I have 3 units on my network with the same ethernet MAC address competing for the same IP address (via DHCP.) WiFi is unaffected, all three are unique regardless of boot scenario.

Up until recently, I had no idea why this was happening but I have another thread where I rambled on and on and was able to come to a determination that powering them down (via UI) and then unplugging/plugging the power, when it boots, the CPU serial # is unique. If i just reboot from the UI, they all reboot with the same CPU serial # which causes my issue.

When I was running LE I was only running one at a time as non of the workarounds for MAC address worked in my scenario (as we discussed back then) but now that I have some time to muck with it (and that I can’t come up with a good enough solution otherwise) dropping the commit seems to be my ticket for-the-now.

For my use-case, not using the CPU serial # and allowing a randomized MAC address suits my needs as I normally would hard-code the devices IP address (vs DHCP reservation) which will allow all three to co-exist and I don’t need to have that conversation with my better-half as to why I bought 3 units that I now need to replace (I already had the conversation as to why I bought 3 units I can’t run at the same time so I’ll take my wins where I can…)

If it’s the IP address that’s causing you grief, why not set a static IP in the CoreELEC settings addon?

Because all three boxes will attempt to bind to the IP with duplicate MAC address. Setting it static works gets me around the randomized MAC address but not the duplicate MAC address. It’s quite interesting when all three are on at the same time in this scenario; timeouts, errors relating to network, etc (what you’d expect.)

I’d never given it much thought, since 99-mac-address.rules has always worked for me in this situation.
I was aware that fixing the IP assigned to a device within your router required binding it to the MAC of that device, but didn’t think it mattered when assigning the fixed IP within the device itself (and then excluding that IP from those assigned by the router’s DHCP settings) :thinking:

In my case it mattered - I could have all three units with unique IP addresses statically assigned via the device (not DHCP reservation) and would have nothing but problems network-wise. I don’t have an overly complex network by any stretch of the imagination. 99% of the time I’d have issues like watching content and suddenly it stops playback or I’d get connection errors to TVHeadend on my NAS.

It’s such a trivial thing but causes me grief - I don’t mind pulling down the source and compiling it in a VM. It just means no automatic updates and a manual update - small price to pay for my sanity.

Hmm out of ideas for now (other than use one on eth, one on wifi and leave one off :smile:)
Or use external eth adapters on one or two

I had considered that (even bought extenders for that very reason and was for a time running it but it’s not suitable given my building structure) but since we’re not updating every day kinda thing, rebuilding every so often is do-able. The only other thing is getting a “more compatible” device but that leads to conversations I’d rather not get into :wink:

First … I am venturing into strange waters and am hesitant to even ask, but has the use of ifconfig been considered to be run at each boot, immediately after the ‘incorrect’ MAC has been assigned?

ifconfig eth0 down
ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx
ifconfig eth0 up

Essentially decide on each MAC address and spoof it.

Would this not work to overcome the problem?

I probably do not understand the real problem …

Yup - tried that too. I’ve tried every method I could Google:

  • ifconfig
  • udev
  • fw_setenv
  • autostart
  • systemd

The problem is not CoreELEC, it’s something with the box itself. As @anon88919003 pointed out, these boxes fall somewhere outside the norm and I personally believe it’s how the manufacturer built them. One post I came across is the Khardas KVIM (something like that) had a similar problem but fw_setenv (for them, it’s just setenv) is able to solve it but didn’t work for me.

In the end, I’m an edge-case - I simply revoke the commit in question (which is to generate MAC via CPU serial #) and compile my own copy, no biggie.

Compiling with that commit reverted won’t help as your boxes will fall back to the default mac if they don’t have one programmed.

You have identified the issue and you have 2 options, sell 2 boxes on and buy something different or stop rebooting them, your giving yourself a lot of unnecessary headache.

As I discovered so I’m playing with the randomized MAC address instead. I could sell the boxes and move on but this is really the only blocker (of sorts) for me and one I can mess around with to resolve. Compute time costs me nothing and maybe I’ll learn a thing or two along the way :slight_smile: