treewide: Provide label MAC address by adschm · Pull Request #2159 · openwrt/openwrt

adschm · 2019-06-23T16:19:08Z

Problem description:
Despite that most of the netifs have different MAC addresses, each device typically has one specific MAC address which is printed on a sticker somewhere.
This specific address may act as an identifier for the device which is apparent to the user, and thus is used e.g. for MAC adresses or IP addresses of routers in Freifunk firmware.
Other possible uses might be a router-specific SSID instead of "OpenWrt" as suggested in this PR: #1370

Solution concept:
One can introduce an alias to the device DTS files which references the node bearing the MAC address of interest:

aliases {
    label-mac-device = &eth0;
};

By adding a small function ~~"get_mac_primary"~~ "get_mac_label" to /lib/functions/system.sh, this can then be used to retrieve the "label" MAC address where required.
This is not limited to ethernet devices, but can also be WiFi etc.

Notes:

Each device needs the label-mac-device to be specified in its DTS. However, a missing primary-mac-address is not detrimental to a device's functionality.
Users of the get_mac_label function will have to take care for a missing label-mac-device themselves (= if it returns nothing)
In the second patch I updated the ath79 devices where I know the sticker MAC address myself. Feel free to share information about other devices.

CURRENT STATE:

Waiting for merge
Latest version run-tested on Archer C60 V2 (DTS-based variant) and on Ubiquiti Picostation M2 (bullet-m, board.d-based variant)
~~ToDo: Need help for ipq40xx (=> identification of ethernet nodes)~~
~~Question: Is there a preference ethernet over WiFi or vice-versa if ambiguous~~
Optional: Add data about additional targets/devices when provided
~~ToDo: Squash ath79 into one commit~~

Devices with open pull-request and reported address:
~~D-Link DIR-842 C1 #2276 label_mac=$lan_mac~~
~~D-Link DIR-842 C2 #2259 label_mac=$lan_mac~~
COMFAST CF-E313AC #1942 label-mac-device = &eth1;
~~CPExxx @ ar9344 #2252 label-mac-device = &wmac;~~
~~GL-AR750 https://patchwork.ozlabs.org/patch/1135461/ label-mac-device = &eth0;~~
~~ALFA Network AP121F #2199 label_mac=$(cat /sys/class/ieee80211/phy0/mac-address)~~
TP-Link Archer D7(b) v1 #2079 label-mac-device = &wmac;

Devices where label-mac-device is already set:
Archer C60 v1/v2
TP-Link TL-WR940N v3/v4
TP-Link TL-WR941N v6

adschm · 2019-06-23T16:30:22Z

@neoraider This could be interesting for Gluon, too.

ynezz · 2019-06-24T05:56:09Z

Thank you for taking care of this, LGTM.

adschm · 2019-06-24T11:08:55Z

I added commits for the few non-ath79 devices I can tell the sticker address.
Since it is only one device per target, depending on whether there is feedback on other devices for those, I would consider them lower priority.

I also have data on the FritzBox 4040 (ipq40xx):
eth0: Sticker MAC address
eth1: +1
2.4 GHz: +2
5 GHz: +3

However, unfortunately I'm not able to identify the corresponding ethernet nodes in the DTS/DTSI files for this one.

CodeFetch · 2019-06-24T14:50:31Z

Hm... As far as I understood the MAC addresses should always be equal to the stock firmware (Stock LAN MAC = OpenWrt LAN MAC etc.). For adding new devices to Gluon it was important that the primary MAC is correct. You can find the definitions here.

What is missing for these devices?

Edit:

However, unfortunately I'm not able to identify the corresponding ethernet nodes in the DTS/DTSI files for this one.

Can't you retrieve them from the switch configs?

adschm · 2019-06-24T14:56:30Z

@CodeFetch
The question is which of the stock/OpenWrt MAC addresses corresponds to the one on the sticker.
This can be eth0/eth1/phy0/phy1/...

If you say that the referenced script identifies these "primary" MAC addresses correctly based on the if-conditions, I will just translate those into DTS.

CodeFetch · 2019-06-24T15:15:34Z

They should. It's part of the checklist for adding device support in Gluon.
But you can only be sure for the devices already supported by Gluon.

On devices with multiple WLAN adapters, care must also be taken that the primary MAC address is configured correctly. /lib/gluon/core/sysconfig/primary_mac should contain the MAC address which can be found on a label on most hardware; if it does not, /lib/gluon/upgrade/010-primary-mac in gluon-core might need a fix. (There have also been cases in which the address was incorrect even on devices with only one WLAN adapter, in these cases a OpenWrt bug was the cause).

adschm · 2019-06-24T15:22:03Z

Okay, thanks.

adschm · 2019-06-24T16:29:07Z

@CodeFetch
So, am I right that everything not explicitly listed in 010-primary-mac, but found in targets/, defaults to /sys/class/ieee80211/phy0/macaddress ?

CodeFetch · 2019-06-24T16:29:54Z

@adrianschmutzler

x86, brcm2708, ar71xx-mikrotik
-> /sys/class/net/eth0/address

(ar71xx-generic) tl-wdr3600, tl-wdr4300, tl-wr902ac-v1
(ramips) dir-860l-b1
-> /sys/class/ieee80211/phy1/macaddress

(ar71xx-generic) a40, a60, archer-c7-v4, archer-c7-v5, carambola2, koala, mr600, mr600v2, mr900, mr900v2, mr1750, mr1750v2, om2p, om2pv2, om2pv4, om2p-hs, om2p-hsv2, om2p-hsv3, om2p-hsv4, om2p-lc, om5p, om5p-an, om5p-ac, om5p-acv2, unifi-outdoor-plus, unifiac-lite, unifiac-pro
(ipq40xx) avm,fritzbox-4040, openmesh,a42, openmesh,a62
(ramips) miwifi-mini
-> /sys/class/net/eth0/address

(ar71xx-generic) archer-c5, archer-c58-v1, archer-c59-v1, archer-c60-v1, archer-c7
(ipq806x) netgear,r7800
-> /sys/class/net/eth1/address

Yes, everything else /sys/class/ieee80211/phy0/macaddress except it does not have a phy0. In that case it's eth0...

adschm · 2019-06-24T18:31:42Z

Okay, I've now added everything from GLUON EXCEPT

brcm2708 and x86: Those targets cannot be dealt with by a simple DTS change
ipq40xx: On this target, I fail to identify the relevant nodes in the DTS structure
mvebu/sunxi: I do not understand the structure of the target

Note that only those devices from ar71xx could be transferred that are already included in ath79 (roughly 50 to 70 per cent).
For a very small number of devices (about 5) I failed to identify the correct nodes in DTS. Since the definitions in Gluon refer to ethX or phyX numbering after initialization, it is not always trivial to transfer this to the DTS order.

Edit: Obviously anything from GLUON, not from OpenWrt

adschm · 2019-06-24T18:33:59Z

Question:
For several devices, MAC address is ambiguous between an ethernet device and a WiFi device. For those cases, I arbitrarily chose the ethernet device.
Is there any justifiable reason to choose ethernet over WiFi or vice-versa?

neocturne · 2019-06-24T18:45:05Z

In Gluon, we default to the phy0 address for devices without an explicit setting, as this is the most common choice by hardware vendors - it is the address visible as BSSID after all (and that's the only address many users will ever see, if at all).

adschm · 2019-06-24T19:55:55Z

In Gluon, we default to the phy0 address for devices without an explicit setting, as this is the most common choice by hardware vendors - it is the address visible as BSSID after all (and that's the only address many users will ever see, if at all).

Indeed, that's true, and I've exploited that myself :-)

However, while this is helpful when sorting out a set of devices, it's irrelevant when you have a single device's DTS alias: I will have to write , e.g., either &eth0 or &wifi0 .

What I'm looking for is a technical reason, like a bigger likelihood of ethernet or wireless to be initialized correctly or a higher probability of one type to fail in general.
However, I suspect that there is no such criterion and in the end the choice is just arbitrary, so I can go on with something useful instead ...

adschm · 2019-06-24T20:04:39Z

@blogic Since you are listed as maintainer for ipq40xx, maybe you can help me on this one:
This PR is about defining an alias to an ethernet or WiFi device that bears the devices primary MAC address (i.e. the one on the sticker). On ipq40xx, I fail to identify which nodes represent those ethernet devices in DTS.
I would just need a hint for that, in best case combined with information about the order in which they are initialized (so which becomes eth0 and which eth1).

For example, for the FritzBox 4040 I know:
eth0: Sticker MAC address
eth1: +1
2.4 GHz: +2
5 GHz: +3

So which node would I refer to in the following statement instead of &eth0 (and why?):

aliases {
primary-mac-address = &eth0;
};

chunkeey · 2019-06-24T20:41:00Z

oh boy. Well, the Device-Tree is governed by a different project and different people.

https://github.com/devicetree-org/devicetree-specification

so while it's not a problem to specify something cool, it's usually a process to convince the dt folks to make it part of their standard. Do you think you can pitch your idea over at the device-tree project as well? Thanks.

adschm · 2019-06-24T21:46:01Z

Do you think you can pitch your idea over at the device-tree project as well?

Well, what I do here is just setting a single alias. This is very much comparable to the led-boot, led-failsafe, etc., only with much less additional code involved.
Do the devicetree people specify names of aliases?

Despite that, I doubt that the functionality established here is of any interest OUTSIDE of the OpenWrt environment. The idea to label a machine consisting of several netif devices with a single MAC address sounds very specific to me. It is very helpful here, but I suspect it won't matter for other projects.

neocturne · 2019-06-24T22:03:20Z

In theory, a device tree describes a piece of hardware - independently of the used operating system. I'd argue that a MAC address that is printed on a sticker is a property of the hardware and deserves to be part of the device tree, even if it is not that useful outside of OpenWrt.

chunkeey · 2019-06-24T22:35:53Z

Well, what I do here is just setting a single alias. This is very much comparable to the led-boot, led-failsafe, etc., only with much less additional code involved.
Do the devicetree people specify names of aliases?

This is what they say about "aliases" in context of a spi "port":
https://patchwork.kernel.org/patch/9133903/#19207021

"If those ports are physically organised and labelled the same, then
using aliases could make sense, to describe the well-defined physical
labels. If you've assigned the numbers artificially, or if the physical
organisation differs across boards, then aliases are not the right tool
for the job.

In the latter cases we're altering the hardware description to suit an
application, rather than providing the necessary abstraction, which is
the kind of (ab)use of aliases which we want to avoid."

If you look at your router, the LEDs all have either a label or some sort of
piktogramm or are documented in the manual. That's where the justification
for the aliases are coming from. I would love to hear from upstream about
their stance on this [EDIT: this = MAC Address sticker] and you seem to have
the necessary will and time to go after this properly.

Despite that, I doubt that the functionality established here is of any interest OUTSIDE of the OpenWrt environment. The idea to label a machine consisting of several netif devices with a single MAC address sounds very specific to me. It is very helpful here, but I suspect it won't matter for other projects.

Look: For once, just give it a honest try before making it sound like it that this is just a silly idea, It's not. You've managed to convince several other devs to respond. Hence it should be possible to get upstream to think about how these stickers should be handled. Contrary to popular opinion the devicetree folks are not monsters, they just sometimes make it difficult, but it's part of the process.

In theory, a device tree describes a piece of hardware - independently of the used operating system. I'd argue that a MAC address that is printed on a sticker is a property of the hardware and deserves to be part of the device tree, even if it is not that useful outside of OpenWrt.

There are a lot of devices-tree sources all over the arch/*/boot/dts directories, so why wouldn't it apply to upstream as well?

adschm · 2019-06-25T13:57:23Z

I've sent an e-mail to devicetree-spec, most probably it is waiting for moderation now. I will post a link when it made it to the archive.

chunkeey · 2019-06-25T18:32:01Z

@adrianschmutzler

https://www.spinics.net/lists/devicetree-spec/msg00843.html this one?

adschm · 2019-06-25T18:34:18Z

Yes.

adschm · 2019-06-26T12:39:49Z

One guy from devicetree-spec raised the (in my eyes justified) question whether primary-mac-address is a really good name.
Anyone having a better idea (which I will forward if I like it ;-) ) ...?

Edit: To clarify this: So far, primary-mac-address is the best option I could think of, and that's also in line with the initial feedback on the devicetree-spec list. However, being the best from a relative perspective, it is not precisely great.

CodeFetch · 2019-06-26T13:38:38Z

label-mac-address?

adschm · 2019-08-15T11:52:23Z

Rebase.

adschm · 2019-08-17T22:25:57Z

Rebased and added PISEN TS-D084, TL-MR3420v2.

adschm · 2019-08-31T13:41:00Z

Rebased and added GL-AR750.

adschm · 2019-09-04T11:35:02Z

Rebased due to addition of WDR3500 and also added 3500 here.

adschm · 2019-09-04T11:43:59Z

Added Archer D50 v1.

adschm · 2019-09-09T12:47:34Z

Would someone please merge this?

ynezz · 2019-09-19T09:57:18Z

Would someone please merge this?

Yes, sorry for the delay, please rebase.

ynezz · 2019-09-19T10:03:02Z

This is based on the work of Rosy Song [email protected]

Just a FYI there's a proper tag Co-developed-by: for such purposes:

Co-developed-by: states that the patch was co-created by multiple developers; it is a used to give attribution to co-authors (in addition to the author attributed by the From: tag) when several people work on a single patch. Since Co-developed-by: denotes authorship, every Co-developed-by: must be immediately followed by a Signed-off-by: of the associated co-author. Standard sign-off procedure applies, i.e. the ordering of Signed-off-by: tags should reflect the chronological history of the patch insofar as possible, regardless of whether the author is attributed via From: or Co-developed-by:. Notably, the last Signed-off-by: must always be that of the developer submitting the patch.

To refer to the MAC address on a device's label, one can specify the alias label-mac-device in the DTS which should point to the bearer of the corresponding MAC address. With the function get_mac_label, the user can retrieve then retrieve this address and use it as a value that uniquely identifies his device. This is severely helpful for several downstream functionalities, e.g. define MAC addresses of custom netifs or change the SSID to be easily recognizable. Signed-off-by: Adrian Schmutzler <[email protected]>

For many devices, MAC addresses cannot be retrieved via the device tree alias. To still provide the label MAC address for those, this implements a second mechanism that will put the address into uci config. Note that this stores the actual MAC address, whereas in DTS we reference the bearing device. This is based on the work of Rosy Song <[email protected]> Signed-off-by: Adrian Schmutzler <[email protected]>

This patch adds the label MAC address for several devices in ath79. Some devices require setting the MAC address in 02_network: For the following devices, the netif device can be linked in device tree, but the MAC address cannot be read: - alfa-network,ap121f - avm,fritz300e - ubnt-xm devices For the following devices, label MAC address is tied to lan or wan, so no node to link to exists in device tree: - adtran,bsap1800-v2 - adtran,bsap1840 - dlink,dir-842-c1/-c2/-c3 - engenius,ecb1750 - iodata,etg3-r - iodata,wn-ac1167dgr - iodata,wn-ac1600dgr - iodata,wn-ac1600dgr2 - iodata,wn-ag300dgr - nec,wg800hp - nec,wg1200cr - trendnet,tew-823dru Signed-off-by: Adrian Schmutzler <[email protected]>

This patch adds the label MAC address for some devices in mpc85xx. Signed-off-by: Adrian Schmutzler <[email protected]>

This patch adds the label MAC address for several devices in ipq806x. Signed-off-by: Adrian Schmutzler <[email protected]>

adschm · 2019-09-19T11:27:35Z

Rebased due to Archer C58/C59 DTS rearrangement.

@ynezz

If you plan to merge this, think about including #2253 for ramips.

ynezz · 2019-09-19T13:40:42Z

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

adschm · 2019-11-12T21:23:44Z

@mweinelt
I need to change the label_mac retrieval for Fritz Repeater 300e (as it's not a good idea to rely on phy0 directly here). Can provide me with a scheme of MAC addresses on that device, e.g.
lan *:0a (label)
wan *:0b (label+1)
2.4 GHz *:0a (label)
5 GHz *:09 (label-1)

I think I will to calculate based on the lan_mac in that particular case.

mweinelt · 2019-11-14T18:20:56Z

@adrianschmutzler

1 Ethernet port c0:25:06:63:36:af
1 Dualband WiFi radio c0:25:06:63:36:b1

adschm · 2019-11-14T18:32:06Z

@mweinelt Thanks, that's consistent with what's been reported based on the urlader key value store:
maca *:6B (ethernet port)
macb *:6C
macwlan *:6D (WiFi radio; maca + 2)
macdsl *:6E

adschm changed the title ~~Provide "sticker" MAC address via device-tree~~ [RFC] Provide "sticker" MAC address via device-tree Jun 23, 2019

ynezz added core packages pull request/issue for core (in-tree) packages target/ath79 pull request/issue for ath79 target RFC pull request ready for comments labels Jun 24, 2019

ynezz mentioned this pull request Jun 24, 2019

Rename hostname and ssid with EUI of mac address #1370

Closed

adschm mentioned this pull request Jun 24, 2019

[RFC] Support primary MAC address selection in OpenWrt freifunk-gluon/gluon#1767

Closed

adschm force-pushed the primarymac branch from b2ce692 to 61a4590 Compare June 24, 2019 18:19

adschm force-pushed the primarymac branch 3 times, most recently from baec1c2 to 311f9a1 Compare August 15, 2019 13:13

adschm force-pushed the primarymac branch from 311f9a1 to 953e06a Compare August 17, 2019 22:25

adschm force-pushed the primarymac branch from 953e06a to 414314f Compare August 31, 2019 13:40

adschm force-pushed the primarymac branch from 414314f to 988b1d2 Compare September 4, 2019 11:34

adschm force-pushed the primarymac branch from 988b1d2 to 256d470 Compare September 4, 2019 11:43

adschm mentioned this pull request Sep 13, 2019

Enable wifi with oem or mac password #2408

Closed

adschm added 5 commits September 19, 2019 13:20

mpc85xx: provide label MAC address

f5dac97

This patch adds the label MAC address for some devices in mpc85xx. Signed-off-by: Adrian Schmutzler <[email protected]>

ipq806x: provide label MAC address

9b9f0fe

This patch adds the label MAC address for several devices in ipq806x. Signed-off-by: Adrian Schmutzler <[email protected]>

adschm force-pushed the primarymac branch from 256d470 to 9b9f0fe Compare September 19, 2019 11:22

ynezz closed this Sep 19, 2019

adschm deleted the primarymac branch September 20, 2019 12:54

Uh oh!

Conversation

adschm commented Jun 23, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adschm commented Jun 23, 2019

Uh oh!

ynezz commented Jun 24, 2019

Uh oh!

adschm commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CodeFetch commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adschm commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CodeFetch commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adschm commented Jun 24, 2019

Uh oh!

adschm commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CodeFetch commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adschm commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adschm commented Jun 24, 2019

Uh oh!

neocturne commented Jun 24, 2019

Uh oh!

adschm commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adschm commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chunkeey commented Jun 24, 2019

Uh oh!

adschm commented Jun 24, 2019

Uh oh!

neocturne commented Jun 24, 2019

Uh oh!

chunkeey commented Jun 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adschm commented Jun 25, 2019

Uh oh!

chunkeey commented Jun 25, 2019

Uh oh!

adschm commented Jun 25, 2019

Uh oh!

adschm commented Jun 26, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CodeFetch commented Jun 26, 2019

Uh oh!

adschm commented Aug 15, 2019

Uh oh!

adschm commented Aug 17, 2019

Uh oh!

adschm commented Aug 31, 2019

Uh oh!

adschm commented Sep 4, 2019

Uh oh!

adschm commented Sep 4, 2019

Uh oh!

adschm commented Sep 9, 2019

Uh oh!

ynezz commented Sep 19, 2019

Uh oh!

ynezz commented Sep 19, 2019

Uh oh!

adschm commented Sep 19, 2019

Uh oh!

adschm commented Jun 23, 2019 •

edited

Loading

adschm commented Jun 24, 2019 •

edited

Loading

CodeFetch commented Jun 24, 2019 •

edited

Loading

adschm commented Jun 24, 2019 •

edited

Loading

CodeFetch commented Jun 24, 2019 •

edited

Loading

adschm commented Jun 24, 2019 •

edited

Loading

CodeFetch commented Jun 24, 2019 •

edited

Loading

adschm commented Jun 24, 2019 •

edited

Loading

adschm commented Jun 24, 2019 •

edited

Loading

adschm commented Jun 24, 2019 •

edited

Loading

chunkeey commented Jun 24, 2019 •

edited

Loading

adschm commented Jun 26, 2019 •

edited

Loading