On 09/08/2014 09:53 PM, Andy Green wrote:
On 9 September 2014 06:40:54 GMT+08:00, Robert Moskowitz <rgm(a)htt-consult.com>
> I do not have this behaviour on the Cubieboard2, just on my Cubietruck.
> I thought it was a problem with the F21 build, but today I am working
> with F19 remix:
> And I keep getting a different MACaddr. This makes it really hard to
> use persistant.rules to control things based on MACaddr.
> Is this just my particular Cubietruck? I remember Hans talking about
> since there is no eeprom, he has to use SID as the basis for the
> Is there anyway for me to set the MACaddr. It is eating up all my dhcp
There are rules for what constitutes a valid mac address, if yours in invalid the kernel
driver will assign you a random one, and then it looks like a new machine every time.
You can force the mac address in userland /etc/rc.d/rc.local using /sbin/nameif +
/etc/mactab, it's dirty but it will get you out of the hole if it runs before the
dhclient action poisons your dhcp server.
Read Hans de Goede's post on the F19 and the Allwinner (Cubie) back on
12/26/2013. He supposedly uses the SID for a consistant local scope
MACaddr. I Do get that on my Cubieboard2, but not on my Cubietruck.
If the network driver uses phylib, there is a generic Device Tree name you can use like
this inside the ethernet stanza to force it
local-mac-address = [ aa bb cc dd ee ff ];
if so, you can think about adding / overriding that DT node in U-Boot before passing to
I sent patches on lkml to improve this a couple of years ago (for Panda, which has no
nonvolatile config onboard) by replacing an invalid MAC with computing a consistent
per-board MAC from CPU serial ID but The Powers That Be felt it should be fixed by the
distros... which as you see...
Which Hans said he did in F19, but it is not working on my Cubietruck.