MAC address changed after sysupgrade from Backfire (Nanostation M2)

I've been upgrading a fleet of devices using a very old version of OpenWRT (Backfire) and using different hardware models.

Now after upgrading a Ubiquiti Nanostation M2 with the image having suffix ath79-generic-ubnt_nanostation-m-squashfs-sysupgrade.bin, the mac address of eth0 seems to have changed.

Old MAC: DC:xx:xx:xx:xx:xx
New MAC: DE:xx:xx:xx:xx:xx

Only the first pair changed.

Did anyone else experience this issue? If yes why is it happening?

If not, it may be a one time thing with this device, but I didn't do any substantial changes, the images generated are the same for other hardware models which are not giving this issue.

It's happening because something changed (or 'went wrong', depending on how you look at it) when the device got migrated to ath79. The actual question is: did your original MAC match the vendor firmware's? Or is this the 'right' one? That's what you should find out. If you still got the box, with a bit of luck the MAC might still be on it. Often the MAC is extracted from the flash somewhere and then extrapolated (incremented, often) for the wireless interfaces.


I do not have the device with me but I asked a person who does have access to let me know and will reply here asap. Thanks @Borromini!

1 Like

The mac address on the external box corresponds to the WiFi mac address, which starts with DC.

I tried flashing the ar71xx device and the mac address of eth0 is fine.

This is a summary of the situation:

eth0: DC:**:**:**:**:*D
eth1: DC:**:**:**:**:*E

19.07 ar71xx
eth0: DC:**:**:**:**:*D (same as eth0 on backfire)
eth1: DE:**:**:**:**:*D (not the same there was on backfire, it's prefixed with DE instead of DC, it ends in D instead of E)

19.07 ath79
eth0: DE:**:**:**:**:*D (corresponds to eth1 on ar71xx of 19.07)
eth1: DC:**:**:**:**:*D (corresponds to eth0 on ar71xx of 19.07)

So in essence, it seems eth0 and eth1 are swapped on ath79.

This mac address change is a bit problematic for network management systems like OpenWISP which recognize the device based on the mac address of a specific interface, if this interface changes, the device is not recognized, which causes issues when upgrading.
The issues are easy to resolve for me, but may not be so obvious to regular OpenWISP users.

I am not sure if it can be changed again since this was released in OpenWRT 19.07. What do you think?

I am testing also other ath79 images for other hardware models and have not found the same issue so far, I will report if I find any other similar issue on other models.


The Ethernet interfaces being swapped is something that happens frequently in the transition to ath79. I suppose there's a technical explanation for that but I'm not familiar with how that works exactly. The question is not how to replicate the Backfire behaviour, but to match the addresses to the stock firmware.

The MAC addresses are extracted from locations on the flash defined in the DTS; the Nanostation's DTS points (amongst others) to the XM DTSI which defines this:

As you can see both MACs are extracted from the ART partition. It looks like that's the wrong match for the Nanostation M2 then, unless that's how the stock firmware behaves. Only someone who can run the stock firmware on the M2 can provide conclusive evidence on that. I checked the Wikidevi clones but they haven't logged the MAC addresses either...

1 Like

We reinstalled the stock firmware on this device on which we were testing the upgrade.

eth0 is DC:**:**:**:**:*D
eth1 is DE:**:**:**:**:*D

It looks to us that the mac addresses of the ath79 image of this model have been inadvertently swapped.
Should we open an issue and ask someone else to double check and confirm?

1 Like

Created bug report:

So far there were no responses to the bug report, I'd like to know if the bug is confirmed and if the OpenWRT devs are willing to accept a patch, any dev who can let me know? Thanks in advance.

Just send in a patch and see what happens I'd say. There's a bit of a queue so it might take some time, but bug reports with a solution tend to be closed quicker than ones without.

1 Like

It seems to me that in the DTS file of this model pretty much everything is being included from other files:

The eth0 and eth1 definitions are in this file:

So, if I understand this code correctly, either this issue is happening also on other Ubiquiti models, or Nanostation should have this inverted.

I am not sure how to proceed. Any suggestion?

I just wanted to send an update here: I found the same issue on the Ubiquiti AirRouter.