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 sticker
    • eth0 - ethernet port - is ra0 address + 1
    • apcli0 - 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-06

    MAC 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
    0_1581013098247_O2(+)_MAC_Address_allocation.png

    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-06

    MAC 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.


  • administrators

    @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't not 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 or ifconfig | 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 E1

    Thank you very much in advance! :-)


  • administrators

    @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 + 1

    However 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

    1. install the xxd package
    2. dump the factory partition to hex: xxd /dev/mtd2 > factory.hex
    3. create a backup just in case
    4. edit the two mac addresses (can use vi)
    5. convert the edited hex file to binary: xxd -r factory-new.hex > factory.bin
    6. write the binary file to the factory partition: mtd -r write factory.bin factory


  • @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 + 1

    However 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

    1. install the xxd package
    2. dump the factory partition to hex: xxd /dev/mtd2 > factory.hex
    3. create a backup just in case
    4. edit the two mac addresses (can use vi)
    5. convert the edited hex file to binary: xxd -r factory-new.hex > factory.bin
    6. write the binary file to the factory partition: mtd -r write factory.bin factory

Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.