Need Assistance with Ethernet MAC Address Discrepancy on MT7628 Network Devices

I'm encountering an issue with the Ethernet MAC address on my OpenWRT device, and I'm seeking assistance resolving it. Here are the details:

Issue Summary:
The ifconfig output on my OpenWRT device shows that the MAC address for the eth0 interface is different from the MAC addresses of other interfaces:

br-lan    Link encap:Ethernet  HWaddr 90:91:64:78:45:04
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::9291:64ff:fe78:4504/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1216 (1.1 KiB)

eth0      Link encap:Ethernet  HWaddr DA:A4:03:9D:2A:25
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:118343 errors:0 dropped:0 overruns:0 frame:0
          TX packets:74978 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10500444 (10.0 MiB)  TX bytes:24804443 (23.6 MiB)
          Interrupt:5

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:14256689 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14256689 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:968645834 (923.7 MiB)  TX bytes:968645834 (923.7 MiB)

phy0-ap0  Link encap:Ethernet  HWaddr 90:91:64:78:45:04
          inet6 addr: fe80::9291:64ff:fe78:4504/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:2056 (2.0 KiB)

Observations:

  • The MAC address for eth0 (DA:A4:03:9D:2A:25) does not match the MAC addresses of other interfaces.
  • I've checked the device's configuration files, including U-Boot environment variables and the contents of /dev/mtd2 (Factory), but I couldn't find any reference to the MAC address DA:A4:03:9D:2A:25.
  • However, I did find a MAC address (90:91:64:78:45:04) in /dev/mtd2 (Factory), which matches the MAC addresses of other interfaces (e.g., br-lan, phy0-ap0).

Request for Assistance:

  • I'm seeking guidance on how OpenWRT determines the MAC address for the eth0 interface when it's not configured in U-Boot environment variables or stored in the Factory partition (/dev/mtd2).
  • Additionally, I would like to set the MAC address for eth0 to match the MAC addresses of other interfaces (90:91:64:78:45:04). Any advice on how to accomplish this would be greatly appreciated.

Thank you in advance for your assistance and insights into resolving this issue.

Best regards,
Steven

That's a randomized MAC address, generated on the fly, if that helps...

Thanks. I found the predefined MAC for the device in factory mtd as below:

root@MangoInit:/lib/functions# echo $(mtd_get_mac_binary factory 4)
90:91:64:78:45:04
root@MangoInit:/lib/functions# echo $(mtd_get_mac_binary factory 40)
90:91:64:78:45:06
root@MangoInit:/lib/functions# echo $(mtd_get_mac_binary factory 46)
90:91:64:78:45:07

These MAC addresses seem to be allocated for different interfaces or components of the device.

However, during system startup, I noticed that a random MAC address was generated for one of the interfaces:

 2023 kern.err kernel: [    1.496124] mtk_soc_eth 10100000.ethernet: generated random MAC address 8e:c0:e0:f3:62:46

This raised a question for me: Should I set the "generated on the fly" MAC address for eth0 to the same address as other interfaces like br-lan or phy0-ap0?

I'm curious to hear your thoughts and suggestions on this matter. What could have triggered the kernel to generate a random MAC address despite having predefined ones in the factory MTD?

Any insights or advice would be greatly appreciated.

Thank you!

Some models have a firstboot script which extracts the factory MAC addresses from the factory partition of flash and creates config device sections in /etc/config/network to apply them to the interfaces. If these get deleted during subsequent configuration changes, it will revert to random MACs. You can of course add them yourself:

config device 'eth0'
    option macaddr '90:91:64:78:45:04'
2 Likes

Digging into the first-boot scripts, I see a reference to mac addresses in one mediatek-specific file:

$ grep mac -ri target/linux/mediatek/base-files/
target/linux/mediatek/base-files/etc/uci-defaults/99_fwenv-store-ethaddr.sh:            fw_setenv eth1addr "$(macaddr_add $(cat /sys/class/net/eth0/address) 1)"

This would translate to /rom/etc/uci-defaults/99_fwenv-store-ethaddr.sh on your device, so maybe chase that down?

Thanks mk24 and efahl for your help!

I managed to locate the file - 99_fwenv-store-ethaddr.sh in my ImageBuilder:

root@e02209cd2489:/imageBuild# vi ./OpenWrt-ImageBuilder-ramips-mt76x8.Linux-x86_64/target/linux/mediatek/base-files/etc/uci-defaults/99_fwenv-store-ethaddr.sh

Now, I'm considering two approaches to address the MAC address issue:

  1. Creating a Script: I've created a script that updates the MAC address and stores the value to UCI under the files/uci_default folder in my ImageBuilder.
  2. Direct Modification: Alternatively, I can directly modify the 99_fwenv-store-ethaddr.sh script to set the MAC address for eth0 there. However, I haven't tested this method yet.

I'm uncertain which approach is the preferred one in OpenWrt. Any insights or recommendations would be greatly appreciated!

I'd use whatever seems most maintainable. For me, that means "least stuff to remember", so if I could write a script on the router, add it to /etc/sysupgrade.conf so it gets backed up properly, and then forget all about it, that would be perfect.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.