@blogic

@rosysong I think, that for this feature to be widely useful, it would be handy to get EUI from the primary MAC address, the MAC address which is usually printed on the sticker somewhere on the router. Otherwise the router is going to welcome me with nice OpenWrt_4a66a8 (I would prefer the OpenWrt-4a66a8 hostname), but how can I confirm, that it's actually the router I'm looking at? So I'm afraid, that at its current state, this PR doesn't provide any added value to what we've now.

For that primary MAC address we would probably need to add something to DTS?

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

and I think, that such primary-mac-address property/alias would be handy not just for this hostname use case, but for other derived projects as well, for example in Gluon.

Maybe a nitpick, but you've probably missed to add macaddr_geteui in separate commit, as I was looking at mac80211 patch first and then started looking at OpenWrt where is this function defined, but later found out it's in the other base-files patch.

This commit does need to add something in DTS file, the ssid and hostname will set as long as you has relevant mac address in /proc/sys/xxx/macaddress.

the ssid and hostname will set as long as you has relevant mac address in /proc/sys/xxx/macaddress.

SSID is probably ok, since you're taking that MAC address from the phy. But for the hostname, I would expect, that it would be set to something I can verify physically on the device, so if I connect to device with hostname OpenWrt-4a66a8, then I can take a look at some sticker on the device and can actually confirm, that there is MAC address xx:xx:xx:4a:66:a8 written on the sticker.

Some of the devices have all MAC addresses printed on the sticker, some of the devices have only WiFi MAC on the sticker, some of the devices have LAN or WAN MAC address. So you shouldn't use just eth0 MAC address for the hostname, but you should consider phy0, phy1, eth1, eth0 as well (list taken from Gluon primary_mac). And how do you know which one of them is the primary MAC address, the MAC address printed on the sticker?

I list the interfaces under /sys/class/net and get one of them as ifname, if succeed, we got the hostname. @ynezz

Well, it seems like you don't get my comments at all.

For that primary MAC address we would probably need to add something to DTS ?
...
And how do you know which one of them is the primary MAC address ?
...

Yes, I think you are right, we should do something to specify which mac is the primary mac address. I agree with your opinion, but how can I get its value after I add the alias in DTS file ??
This is very import.!

but you've probably missed to add macaddr_geteui in separate commit,
...
I would prefer the OpenWrt-4a66a8 hostname
...

OK, will update them.

@ynezz

@ynezz Here is the newer commit, it provides a new implementation for renaming hostname and eui.
The variable primarynetif indicates to the users and system that which is the primary net interface, so that we can rename the hostname and ssid with this, otherwise, nothing will change to the default.

For that primary MAC address we would probably need to add something to DTS?

aliases {
primary-mac-address = &eth0;
};
and I think, that such primary-mac-address property/alias would be handy not just for this hostname use case, but for other derived projects as well, for example in Gluon.

@ynezz I like that idea, as I need the "sticker MAC address" in a similar use-case as you referenced from Gluon.

So, if one defined an alias as suggested, I could then access it via
cat /proc/device-tree/aliases/primary-mac-address
and thus derive the "sticker MAC address"?

I will play around with this a litte bit.
If I then start an RFC PR just for adding such a setting, do you see a chance for it being merged or would it be wasted time?

Well, actually it is as easy as adding

get_mac_primary() {
	local basepath="/proc/device-tree"
	local macdevice="$(cat "$basepath/aliases/primary-mac-address" 2>/dev/null)"
	[ -n "$macdevice" ] && get_mac_binary "$basepath/$macdevice/mac-address" 0
}

to lib/functions/system.sh

I will try my luck with a PR.

For that primary MAC address we would probably need to add something to DTS?
aliases {
primary-mac-address = &eth0;
};
and I think, that such primary-mac-address property/alias would be handy not just for this hostname use case, but for other derived projects as well, for example in Gluon.

@ynezz I like that idea, as I need the "sticker MAC address" in a similar use-case as you referenced from Gluon.

So, if one defined an alias as suggested, I could then access it via
cat /proc/device-tree/aliases/primary-mac-address
and thus derive the "sticker MAC address"?

I will play around with this a litte bit.
If I then start an RFC PR just for adding such a setting, do you see a chance for it being merged or would it be wasted time?

for this PR, users do not need to update the DTS files but to set the primary mac address in the preinit scripts (e.g. target/linux/ath79/base-files/etc/board.d/02_network) with "ucidef_set_primarynetif ethxx".

for this PR, users do not need to update the DTS files but to set the primary mac address in the preinit scripts (e.g. target/linux/ath79/base-files/etc/board.d/02_network) with "ucidef_set_primarynetif ethxx".

Yes. I just picked the improvement suggestion from ynezz, as it serves well to solve another problem I have. (And I also prefer specifying the primary-mac device in DTS).

I actually like your initial idea of providing specific SSID/Hostname, so let's see how this goes on ...

I actually like your initial idea of providing specific SSID/Hostname, so let's see how this goes on ...

Once we figure out PR #2159 this PR could simply use get_mac_primary to get the right MAC address for the SSID/hostname.

Note that it looks like not every device is storing the relevant MAC addresses in device_tree. Here we will (maybe only after PR #2159 is sorted out) have to decide whether

• we bring the MAC address to device tree in those cases (maybe introducing redundancy)
• we follow the approach here and add a second option to specify primary MAC address in 02_network or similar (this will be comparable to the led or WiFi MAC fixes done in board.d already, as those are not solely DTS-based, too). get_mac_primary would then first check device_tree and after that look for other options
• we live with a (small?) fraction of devices not being covered by the DTS-based get_mac_primary (won't hurt much for Freifunk/Gluon, but will lead to no device-specific hostname/SSID for the aim of this PR)

So far, I'm personally far from having a preference.

@rosysong My PR #2159 for adding label MAC addresses has just been accepted.
So, you can exploit the MAC address set there by just calling get_mac_primary function.

Do you want to update this PR based on it or should I take over from here?

Note that only a fraction of devices are supported, so the features introduced here will be limited to a (hopefully growing) subset of devices; I would suggest to keep the rest with the default "OpenWrt".

@adrianschmutzler Thanks, will update this PR later! Glad to see this.

@adrianschmutzler @ynezz It's done, please check it again, thanks for your reivews!

For the last commit, maybe rephrase "Once the label is valid" into something like "If a label MAC address is provided for device".
For the first and second commit, you should also add a commit description about what you are doing and why.

Thanks, here is the newer commit.

It's done, thansk! ping @adrianschmutzler @ynezz

@adrianschmutzler Well, I updated it, replace "set" with "uci set".

I've merged the geteui patch and a rebased version of the hostname patch together and sent it to the mailing list:
https://patchwork.ozlabs.org/patch/1188868/

This was necessary as I plan to alter the label MAC address retrieval from get_mac_label function to uci config beforehand:
https://patchwork.ozlabs.org/patch/1188867/

Despite, I tried to test the WiFi patch, but found that this won't work for addresses being set up via /etc/board.json or /etc/config/system as mac80211.sh runs way earlier.
I do not have a solution for that at the moment, but expect this topic to be discussed deeply in #2408

Despite, I tried to test the WiFi patch, but found that this won't work for addresses being set up via /etc/board.json or /etc/config/system as mac80211.sh runs way earlier.

Could you give me more details on what you want/need, so I can make sure it will work properly :)

@mgiganto Well, essentially have a look at the second patch here. This will work if label MAC address is stored in device tree, and won't work if it's stored in board.json or uci config.
Both cases are relevant depending on which MAC address the vendor uses.

@mgiganto Well, essentially have a look at the second patch here. This will work if label MAC address is stored in device tree, and won't work if it's stored in board.json or uci config.
Both cases are relevant depending on which MAC address the vendor uses.

It looks to be related with board.json being generated just after wifi config... I'll keep you update with the fix

There has been demand for discussing this further in the mailing list. Despite, SSID name changes in mac80211.sh won't work as done here, as board.json is not available reliably. I will implement a solution with uci-defaults and submit that together with the hostname patch.
Thus, I will close this PR, as the discussion will continue elsewhere. Thank for your work.

Based on the feedback on the mailing list, this feature seems to be not desired. I've marked my/our patches as "Rejected". However, due to the introduction of the label MAC address one may easily do a similar adjustment of SSID/hostname in a short local uci-defaults script.