Contradiction in Omega2 Device MAC Address Allocation
-
@Lazar-Demin wrote here on 31 Jan 2019, 23:31
Each Omega2 device (includes through-hole and SMT models) is allocated 3 sequential MAC addresses.
Since June of 2018, the allocation schema has been the following:ra0
- the Omega's WiFi AP - matches the MAC address on the stickereth0
- ethernet port - is ra0 address + 1apcli0
- Omega's WiFi client - is ra0 address + 2
and in the OpenWRT 18 firmware release blog post WiFi Warp Core Driver Update on 26 Feb 2019
Every Omega2 device is allocated 3 sequential MAC addresses during production, and with this latest version of WiFi Warp Core, each interface will have MAC addresses according to this scheme:
- ra0 – the WiFi Access Point interface – this matches the MAC address on the sticker on the shielding
- eth0 – ethernet port – ra0 MAC address + 1
- apcli0 – the WiFi client interface – ra0 MAC address + 2
In reality all of my Omega2+ devices follow another schema
:- ra0 matches the MAC address on the sticker
- apcli0 is ra0 address + 1
- eth0 is ra0 address + 2
Omega2+ tested - for example - with these FWs:
v0.2.0-b187 released on 2018-06-04
v0.2.0-b188 released on 2018-06-12
v0.2.2 b202 released on 2019-02-15
v0.3.2 b217 released on 2019-02-26 ... v0.3.2 b233 released on 2019-12-06MAC address on the sticker: 40A36BC0**5BE1** ra0 Link encap:Ethernet HWaddr 40:A3:6B:C0:5B:E1 apcli0 Link encap:Ethernet HWaddr 40:A3:6B:C0:5B:E2 eth0 Link encap:Ethernet HWaddr 40:A3:6B:C0:5B:E3
Please look at also the above @Lazar-Demin's post
// after network interface is restarted, MAC addresses are adjusted: root@Omega-F195:~# ifconfig | grep HWaddr apcli0 Link encap:Ethernet HWaddr 40:A3:6B:C0:F1:96 br-wlan Link encap:Ethernet HWaddr 40:A3:6B:C0:F1:95 eth0 Link encap:Ethernet HWaddr 40:A3:6B:C0:F1:97 // fixed address ra0 Link encap:Ethernet HWaddr 40:A3:6B:C0:F1:95
According to the official Onion Omega2 Documentation
Device MAC Addresses
And this is my test on a "fake" Omega2 Pro (Omega2+, 16 GB microSD Card, Expansion Dock) with omega2pro-v0.3.1-b216.bin 2019-02-22
(because there are no publicly released FWs for Omega2(+) from b203 to b216)
and with omega2pro-v0.3.2-b233.bin 2019-12-06MAC address on the sticker: 40A36BC0**99A5** ra0 Link encap:Ethernet HWaddr 40:A3:6B:C0:99:A5 apcli0 Link encap:Ethernet HWaddr 40:A3:6B:C0:99:A6 eth0 Link encap:Ethernet HWaddr 40:A3:6B:C0:99:A7 root@Omega-99A5:/# iwpriv ra0 e2p ra0 e2p: [0x0000]:7628 [0x0002]:0200 [0x0004]:A340 [0x0006]:C06B [0x0008]:A599 [0x000A]:0000 [0x000C]:0000 [0x000E]:0000 [0x0010]:FFFF [0x0012]:FFFF [0x0014]:FFFF [0x0016]:FFFF [0x0018]:FFFF [0x001A]:FFFF [0x001C]:FFFF [0x001E]:FFFF [0x0020]:0000 [0x0022]:0000 [0x0024]:0020 [0x0026]:0000 [0x0028]:A340 [0x002A]:C06B [0x002C]:A799 [0x002E]:A340 [0x0030]:C06B [0x0032]:A699 [0x0034]:3422 [0x0036]:2000
Hmm.
-
@György-Farkas how many Omegas do you have and how old are they?
Earlier in the production lifetime of the Omega2 we used to write the MAC addresses like what you're seeing:
- ra0 matching the sticker
- apcli0 = ra0 + 1
- eth0 = ra0 + 2
But we then chose to standardize to what's listed in the Device MAC Addresses docs article:
In any case, the
factory
partition is writeable in the latest firmware, so if you see the need, you can edit it to follow the new addressing schema.
-
@Lazar-Demin Thank you for your reply.
-
I tested those FWs on two Kickstarter Omega2+ - I have 5BE1 since the end of 2016 and 99A5 since the first half of 2017 if I remember well.
-
You wrote
In any case, the
factory
partition is writeable in the latest firmware, so if you see the need, you can edit it to follow the new addressing schema.Does this mean that a FW sysupgrade is not enough?
-
Can the workaround what you suggested in this post correct only the MAC address collision but
can'tnot set the new addressing schema?
-
-
Hi all!
Please let us know a couple of things about your system.- the type of your Omega2, how old is it, its FW version (
onion os version
) - the output of this command
ifconfig | grep -i hwaddr
orifconfig | grep HWaddr
root@Omega-5BE1:~# onion os version === Version Info === Omega firmware: v0.3.2 b233 onion-os - 1.0.6-1 root@Omega-5BE1:~# ifconfig | grep -i hwaddr apcli0 Link encap:Ethernet HWaddr 40:A3:6B:C0:5B:E2 br-wlan Link encap:Ethernet HWaddr 40:A3:6B:C0:5B:E1 eth0 Link encap:Ethernet HWaddr 40:A3:6B:C0:5B:E3 ra0 Link encap:Ethernet HWaddr 40:A3:6B:C0:5B:E1
For example my answer can be this:
Omega2+, cca 3 years, v0.3.2 b233
apcli0 E2, br-wlan E1, eth0 E3, ra0 E1Thank you very much in advance!
- the type of your Omega2, how old is it, its FW version (
-
@György-Farkas said in Contradiction in Omega2 Device MAC Address Allocation:
Does this mean that a FW sysupgrade is not enough?
A firmware sysupgrade will not touch the
factory
partition! So no, it will not fix the the addressing schema
@György-Farkas said in Contradiction in Omega2 Device MAC Address Allocation:
Can the workaround what you suggested in this post correct only the MAC address collision but can't not set the new addressing schema?
Are you referring to the
uci set network.wan.macaddr= ...
workaround? And setting the eth0 mac address to ra0 + 1?
The wifi driver will still read the apcli0 mac address from the factory partition at "The 6 bytes starting at 0x002e - the apcli0 MAC address".
So you will end up with a collision.The last post in that topic mentions we put out a Warp Core wifi driver fix for address duplication.
With this fix, the apcli0 address will always be the 6 bytes starting at 0x002e from the factory partition.
And the eth0 address will always be the 6 bytes starting at 0x0028 from the factory partition. (This was true before the warp core update).
The Takeaway
No matter how the MAC addresses were allocated in the factory, your device will work 100% normally.
As long as you're on firmware 0.3.x you will not have any collision issues and all three interfaces will have unique mac addresses.
If your device was manufactured before mid 2018, then it will not follow the mac address allocation schema that's published in our docs:
Instead eth0 mac address will be ra0 + 2
and apcli0 mac address will be ra0 + 1However this will not cause any issues and your device will operate 100% normally
If your device was manufactured after mid 2018, the Mac addresses will follow the schema.
If not matching the mac address allocation on your older devices continues to bug you
Like I mentioned, the
factory
partition is writeable. So it's possible to edit the factory partition to adjust the two mac addresses.Here are the steps in broad strokes. I haven't tested these so proceed at your own risk
- install the
xxd
package - dump the factory partition to hex:
xxd /dev/mtd2 > factory.hex
- create a backup just in case
- edit the two mac addresses (can use vi)
- convert the edited hex file to binary:
xxd -r factory-new.hex > factory.bin
- write the binary file to the factory partition:
mtd -r write factory.bin factory
- install the
-
@Lazar-Demin said in Contradiction in Omega2 Device MAC Address Allocation:
@György-Farkas said in Contradiction in Omega2 Device MAC Address Allocation:
Does this mean that a FW sysupgrade is not enough?
A firmware sysupgrade will not touch the
factory
partition! So no, it will not fix the the addressing schema
@György-Farkas said in Contradiction in Omega2 Device MAC Address Allocation:
Can the workaround what you suggested in this post correct only the MAC address collision but can't not set the new addressing schema?
Are you referring to the
uci set network.wan.macaddr= ...
workaround? And setting the eth0 mac address to ra0 + 1?
The wifi driver will still read the apcli0 mac address from the factory partition at "The 6 bytes starting at 0x002e - the apcli0 MAC address".
So you will end up with a collision.The last post in that topic mentions we put out a Warp Core wifi driver fix for address duplication.
With this fix, the apcli0 address will always be the 6 bytes starting at 0x002e from the factory partition.
And the eth0 address will always be the 6 bytes starting at 0x0028 from the factory partition. (This was true before the warp core update).
The Takeaway
No matter how the MAC addresses were allocated in the factory, your device will work 100% normally.
As long as you're on firmware 0.3.x you will not have any collision issues and all three interfaces will have unique mac addresses.
If your device was manufactured before mid 2018, then it will not follow the mac address allocation schema that's published in our docs:
Instead eth0 mac address will be ra0 + 2
and apcli0 mac address will be ra0 + 1However this will not cause any issues and your device will operate 100% normally
If your device was manufactured after mid 2018, the Mac addresses will follow the schema.
If not matching the mac address allocation on your older devices continues to bug you
Like I mentioned, the
factory
partition is writeable. So it's possible to edit the factory partition to adjust the two mac addresses.Here are the steps in broad strokes. I haven't tested these so proceed at your own risk
- install the
xxd
package - dump the factory partition to hex:
xxd /dev/mtd2 > factory.hex
- create a backup just in case
- edit the two mac addresses (can use vi)
- convert the edited hex file to binary:
xxd -r factory-new.hex > factory.bin
- write the binary file to the factory partition:
mtd -r write factory.bin factory
- install the
-
@Lazar-Demin Many thanks for your detailed reply.
You wrote:If your device was manufactured before mid 2018, then it will not follow the mac address allocation schema that's published in our docs:
...
If your device was manufactured after mid 2018, the Mac addresses will follow the schema.Oops! This is what you did not tell us until now.
Are there any advantages of
this newyour "favorite" schema to any other ones?
-
@György-Farkas I did mention it previously:
@Lazar-Demin said in Contradiction in Omega2 Device MAC Address Allocation:
Earlier in the production lifetime of the Omega2 we used to write the MAC addresses like what you're seeing:
But I had to confirm the timing of the change
There's no advantages to one schema or the other. Remember that both schemas will work just fine.
We just chose to standardize to the one mentioned in the docs article.