[OpenWrt-Devel] [PATCH 0/2] introduce label_mac into hostname and SSID
pepe2k at gmail.com
Sun Nov 17 08:18:56 EST 2019
On 17.11.2019 00:23, mail at adrianschmutzler.de wrote:
> 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).
I also think it would be good to document that new system function
'get_mac_label' somewhere in the Wiki. I know that you worked on the
topic already: .
>> 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.
I believe SSID is probably first thing users change when they setup
their device after installing OpenWrt. Given the fact we don't allow
Wi-Fi to be enabled by default, this is more a matter of taste for me.
>> > 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).
I think we look at the project from slightly different perspectives. I
have (still) a feeling that OpenWrt should be considered more as a
platform, framework or kind of a 'base' for building something bigger on
it. Just not a fully ready, polished distribution with fireworks where
everything is already defined for users, out of the box.
Of course, we have releases with GUI included but everyone can expect
that after installing OpenWrt, the box will be available under default
project-wide, static hostname and IP address (not some vendor-specific
settings), there might be a diag LED defined, there will be filesafe in
case of an emergency plus some other _default_ things... and that's all.
Everything else we leave (and I believe should be left) for users or
downstream projects for customization as there is no way to satisfy
everybody. One could prefer static hostname, someone else is asking for
a different default IP or protocol on the LAN and there is still demand
for unencrypted Wi-Fi enabled by default. We provide sane defaults
_only_ which can be maintained without lot of troubles and burden.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel