[OpenWrt-Devel] [PATCH 0/2] introduce label_mac into hostname and SSID

mail at adrianschmutzler.de mail at adrianschmutzler.de
Sat Nov 16 18:23:35 EST 2019

Hi Piotr,

Thank you for providing extensive feedback on this topic.

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> On Behalf Of Piotr Dymacz
> Sent: Samstag, 16. November 2019 16:32
> To: Adrian Schmutzler <freifunk at adrianschmutzler.de>; openwrt-
> devel at lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 0/2] introduce label_mac into
> hostname and SSID
> Hi Adrian,
> On 08.11.2019 12:48, Adrian Schmutzler wrote:
> > This patchset will introduce the label MAC address into the _default_
> > hostname and SSID of OpenWrt devices. Devices installed after these
> > commits (or upgraded with sysupgrade -n) will have their hostname and
> > SSID set to OpenWrt-ddeeff where "ddeeff" is the EUI of the label MAC
> > address aa:bb:cc:dd:ee:ff.
> As this is something which touches essential system setting (identification), I
> would really like other team members to join the discussion before it sneaks
> in again. Especially because this was already merged and reverted later, after
> short discussion on IRC.
>  From my point of view, I'm only worried about all the consequences we
> don't know about, so I would prefer to have this one _optional_.

With the label MAC address being available already independent of this patch,
it's relatively easy for someone building the image to create custom hostname
and SSID in a uci-default script, achieving similar effects as in this patchset with
about 10 lines of code.
For that reason, I do not think that providing a _standardized optional_ rename
is worth the effort of maintaining it, as the user could get a much more flexible
alternative (manual uci-defaults file) with manageable amount of additional work.

In this context, let me point out that for me personally the important feature is
having the label MAC address. What I do in this patchset (which isn't even from
me originally) is a nice-to-have additional use of this feature, but I don't heavily
insist on it. So, if feedback keeps to be mainly negative, I will bury it and still be
fine (and will still be able to use the label MAC address in custom scripts).

> On the other hand, I'm fine with the SSID change but I see it's not going to be
> that straightforward to implement.
> Also, what I'm thinking about here is which one MAC should be used for the
> SSID name. The 'label' one which is not available on all devices or maybe the
> 'phy' one?

We had this discussion very early when this was still a PR in GitHub, as initially
it actually was using the phy addresses. The argument for using the label MAC
was on the one hand that the label MAC address is apparent to the user on the case, while
a +1/-1 of this number will be (a little bit) confusing. Secondly, only having
the label MAC address would assure having the same SSID for more than
one WiFi interface (as it's now the case with default 'OpenWrt'). This was
explicitly requested by ynezz (as the only committer reviewing this) back then.

> > For devices where no label MAC address has been specified, hostname
> > and SSIDs will use the former default "OpenWrt".
> And this is probably the biggest issue I have with the whole idea behind
> 'label_mac'. As I understand the motivation, I don't like the fact it's not
> specified (and probably would never be) for all devices so we will have here
> inconsistency (in essential system settings!) and might end up with
> confusion. Maybe that's something which should be handled by downstream
> users/projects (and AFAIK, it is already).

Yes, I cannot discuss away this drawback, some devices will have OpenWrt_ddeeff
and some will have just OpenWrt. I just never felt (and still feel) about that as being a practical
problem. And from my personal experience with downstream projects, the SSID
most probably gets overwritten with something completely different anyway,
only the change in hostname might matter there.

So, I have lots of time to wait for further feedback on this, and I most probably
will bury it without too bad feelings if negative feedback continues.
At the end, this is just meant as an improvement for the uneducated end user,
I will have zero benefit for my personal/downstream projects from this (unlike
the label MAC address itself, which is extremely helpful).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20191117/c1dd9e09/attachment.sig>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list