Information about MAC address available via device tree can be retrieved as follows:

Please run
find /proc/device-tree/ -name "*mac-address"
on your device (just with the current firmware, no need to update anything).

For each of the returned paths (if there are any), retrieve the mac-address, e.g.

. /lib/functions/system.sh
get_mac_binary "$yourpath" 0

Now check which of those returned MAC addresses matches the one on the label/sticker/case/box of your device and tell me the device-tree path leading to it. Note that you do not have to post your MAC addresses here, but just a statement about which match, e.g. like

/proc/device-tree/ahb/eth@1a000000/mac-address
/proc/device-tree/ahb/eth@1a000000/mtd-mac-address
/proc/device-tree/ahb/eth@19000000/mac-address <== this one
/proc/device-tree/ahb/eth@19000000/mtd-mac-address
/proc/device-tree/ahb/apb/wmac@18100000/mac-address
/proc/device-tree/ahb/apb/wmac@18100000/mtd-mac-address

There may be one, two or no paths giving the correct address. It may also happen that the find command returns nothing. Please also tell me that.
The "mtd-mac-address" values can be ignored.

If device tree does not lead to the relevant MAC address, we can still set it in 02_network. In this case, I need to set label_mac in a similar way as it is already used for lan_mac and wan_mac.

Thanks.

@angelsl @rogerpueyo @dengqf6 @musashino205 @alex-eri @nbriggs @jwischka @amdodak @wifiseguro @drvlabo @aparcar
Hi, you currently have open PRs concerning ramips device support. Please have a look at the instructions directly above this post.
I would be happy if you would help me with getting the designated information for your devices (not necessarily only the ones from the PR ;-) ).

@DinoTse @gvlaev @981213 @dengqf6 @djbonet @CHKDSK88 @DavideFioravanti @liuyuf78fk @nickberry17 @kapieyow @kristrev @iscilyas @p055877632 @musashino205 @ChalesYu @vk496 @ptpt52 @eikepedia @tvc @arapov @SNMetamorph @7tobias @crdotson @squigley @majo-icutech @hackpascal @Linaro1985 @donothingloop
Hi, you have opened device support/fix PRs for ramips devices that have been merged not too long in the past. Please have a look at the instructions two posts above.
I would be happy if you would help me with getting the designated information for your devices if you still have access to them (not necessarily only the ones from the PR ;-) ).

@adrianschmutzler

All jboot devices have MAC stored in Amit config partition. Please look this:

find /proc/device-tree/ -name "*mac-address" returns none.

In this case:
label_mac=$wan_mac

And what about devices (mostly Chinese) without stored MAC, like Unielec U7621?

@CHKDSK88

All jboot devices

That effectively narrows down to all the devices in the case-block you referenced (at least that's what some quick grepping tells me)?

And what about devices (mostly Chinese) without stored MAC, like Unielec U7621?

That's an interesting question indeed. It strongly depends on what you want to use the label MAC address for after it is accessible in OpenWrt.
From a systematic point of view, devices not having a label with an address also should not have a label-mac-address property assigned. At the moment, I'm actually in favor of not setting it for those.
I would then pass the question what happens if get_mac_label returns nothing to the user (or function using get_mac_label). So, get_mac_label will not return "fake information", and the question what's the right surrogate for a non-defined label-mac-address will be determined in the context of the use-case.

However, this is just my personal feeling about this topic, it represent no consensus or member's opinion.

As @CHKDSK88 said, find /proc/device-tree/ -name "*mac-address" on the "dlink,dwr-922-e2" (my PR) also returns nothing, and it's stored in the jboot settings, which is retrieved with jboot_config_read -m -i $(find_mtd_part "config") -o 0xE000, eg: jboot_config_read -m -i /dev/mtd5 -o 0xE000
1c:5f:2b:cb:0c:17, and this MAC address matches the one on the sticker on the bottom of the device.

@adrianschmutzler

That effectively narrows down to all the devices in the case-block you referenced (at least that's what some quick grepping tells me)?

Yes. Only this devices.

At the moment, I'm actually in favor of not setting it for those.

I agree with You.

Update: Added jboot devices.

Hello,

# find /proc/device-tree/ -name "*mac-address"
/proc/device-tree/ethernet@1e100000/mac-address
/proc/device-tree/ethernet@1e100000/mtd-mac-address

For /proc/device-tree/ethernet@1e100000/mac-address the MAC address returned is correct (the same at the label, wlan and eth).

The second one /proc/device-tree/ethernet@1e100000/mtd-mac-address returns 00:00:00:0d:00:00

Hello again,

# find /proc/device-tree/ -name "*mac-address"
/proc/device-tree/ethernet@1e100000/mac-address
/proc/device-tree/ethernet@1e100000/mtd-mac-address

For /proc/device-tree/ethernet@1e100000/mac-address the MAC address returned is correct (the same at the label, wlan0 (wlan1 differs in last byte) and eth).

The second one /proc/device-tree/ethernet@1e100000/mtd-mac-address returns 00:00:00:0a:00:00

My EnGenius ESR600 has the following files present:

/proc/device-tree/wmac@10180000/mac-address
/proc/device-tree/wmac@10180000/mtd-mac-address
/proc/device-tree/ethernet@10100000/mac-address
/proc/device-tree/ethernet@10100000/mtd-mac-address
/proc/device-tree/pcie@10140000/pcie@0,0/wifi@0,0/mac-address
/proc/device-tree/pcie@10140000/pcie@0,0/wifi@0,0/mtd-mac-address

but none of them contain the label MAC address, which is the WAN address.
The WAN address is in the u-boot-env partition (mtd1), as the wanaddr attribute.

I guess I should point out that the new ESR600 DTS file is one I have a PR in for, so if there's something that should be changed, now is a good time to talk about that.

@nbriggs Okay, you would then just add label_mac=$wan_mac in 02_network. However, this depends on a change I need to introduce with #2159, so as long as that PR is not merged, you won't have to change anything.
Despite, the MAC address assignment of that device is generally interesting, I will comment about that in the device support PR.

Thanks, I've added the data for mtc,wr1201, netgear,r6220 and TP-Link RE650 v1.

Hello. I checked my device and got some results.

/proc/device-tree/ethernet@10100000/mac-address       <= returns valid MAC address
/proc/device-tree/ethernet@10100000/mtd-mac-address   <= returns 00:00:00:0d:00:00

@SNMetamorph Thanks. Does "valid MAC address" mean it's the one on the label or only that it actually is a MAC address compared to the second one?

@adrianschmutzler Yes. It's address from device label.

Here is what I have for a Belkin F9K1109v1

find /proc/device-tree/ -name "*mac-address" doesn't return anything

This router uses u-boot and has the WAN MAC in a u-boot config partition. It does match the label on the unit.

Let me know if you need anything else from the device.

Update: Added zyxel,keenetic-start and belkin,f9k1109v1.

Extremely late response, but here goes: for the Xiaomi Mi R3P

# find /proc/device-tree/ -name \*mac\*
/proc/device-tree/ethernet@1e100000/mac-address
/proc/device-tree/ethernet@1e100000/mtd-mac-address

# . /lib/functions/system.sh
# get_mac_binary /proc/device-tree/ethernet@1e100000/mac-address 0
50:64:2b:33:06:dc

this, however is not the MAC address on the sticker, which is 50:64:2b:33:06:dd
the former is <&factory 0xe000> while the latter is <&factory 0xe006>

fwiw

@iscilyas Thanks for the response, it's not so much late - I expect this PR to be left open for quite a while still.

If you report that <&factory 0xe006> is the label address, this means that I could exploit lan_mac in 02_network?

lan_mac=$(mtd_get_mac_binary factory 0xe006)
label_mac=$lan_mac

@adrianschmutzler

If you report that <&factory 0xe006> is the label address, this means that I could exploit lan_mac in 02_network?

lan_mac=$(mtd_get_mac_binary factory 0xe006)
label_mac=$lan_mac

well, that depends on what label_mac is supposed to mean. from what i've read so far i'm under the impression that it means "WAN MAC address" (although... then there are people who talk about wifi address as being the "label address"... so i'm not sure). i'm not sure what the "sticker mac address" is supposed to mean in other words. it might be that i got it wrong in the dts and in 02_network (wouldn't be surprised) and they should have been reversed...

so, what on earth is the "sticker mac address" supposed to represent (in general)? just a "unique key" for the router?

@iscilyas

Have a look at #2159 for introduction of the feature and at #1370 for an example use case.

Briefly:
Most routers bear a label which has one of the device's MAC addresses written on it. Since this address is easily accessible by a user and is unique by default, one can exploit it as some kind of name/identifier for the device. However, vendor MAC address assignment is arbitrary, so we try to provide the label MAC address.

Concerning label_mac:
Have a look at the 2nd commit in #2159

@adrianschmutzler : thanks for the links. i think i got it: the "label" mac address is a lan-side thing for the administrator to distinguish between different openwrt devices.
in that case, in response to your original question/comment:

If you report that <&factory 0xe006> is the label address, this means that I could exploit lan_mac in 02_network?

lan_mac=$(mtd_get_mac_binary factory 0xe006)
label_mac=$lan_mac

yeah. but weren't you trying to get this into the dts? or is that the "long-term" solution while 02_network is the short-term hack?

Tidy up done.

Update: Exploited some cases where &ethernet has same address as &wmac, but only the former is available via DTS.

Update: added newifi-d1,-d2,-y1,-y1s.

Rebased and added iptime,a604m.

@wifiseguro Did you also check wan port on stock firmware?

@adrianschmutzler
Sorry for my late response,
wan port on stock firmware is 78:A3:51:5C:84:8F

Rebased and added ADSLR G7.

Added netgear_r6260_r6350_r6850.

Just to sum up MAC address findings for WE1326v5:
Stock firmware:
2.4 GHz :8c
5 GHz :8d
ethernet :8c
WAN :8f

OpenWrt:
2.4 GHz/label/phy0 :8c 0x4
5 GHz/phy1 :8d 0x8004
eth0/lan :8e 0xe000 (This does not match the findings from stock firmware, but the address is there, so use it)
eth0.2/wan :8f 0xe006 (Currently calculated by eth0 +1).

Here is the result from a ZBT WE3526 (as also posted here #2319 (comment) )

root@OpenWrt:~# find /proc/device-tree/ -name "*mac-address*"
/proc/device-tree/ethernet@1e100000/mac-address
/proc/device-tree/ethernet@1e100000/mtd-mac-address

root@OpenWrt:~# get_mac_binary "/proc/device-tree/ethernet@1e100000/mac-address" 0
78:a3:51:30:18:fa

root@OpenWrt:~# get_mac_binary "/proc/device-tree/ethernet@1e100000/mtd-mac-address" 0
00:00:00:0d:00:00

The MAC address on the label is actually 78:a3:51:30:18:f8.

@zorun

The MAC address on the label is actually 78:a3:51:30:18:f8

This will be either phy0 or phy1 on the running device. Can you check which of them?
cat /sys/class/ieee80211/phy0/macaddress
cat /sys/class/ieee80211/phy1/macaddress

Added dir-810l.

Rebased after MAC address fixup in 02_network.

Thanks! Pulled into my staging tree at https://git.openwrt.org/openwrt/staging/ynezz.git

Merged commit is:

• 7140394