[PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR
a.heider at gmail.com
Fri Sep 11 18:47:02 CEST 2020
On 11/09/2020 18:22, Marek Behún wrote:
> On Fri, 11 Sep 2020 17:52:26 +0200
> Andre Heider <a.heider at gmail.com> wrote:
>> Hi Marek,
>> On 11/09/2020 13:55, Marek Behún wrote:
>>> On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár <pali at kernel.org>
>>>> On Tuesday 08 September 2020 08:52:56 Tom Rini wrote:
>>>>> Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only use a
>>>>> random MAC address when we haven't found one either on the
>>>>> hardware or environment.
>>>> I know.
>>>>> It also prints a warning that you are using a random MAC,
>>>>> so if it's documented on how to recover the real MAC a user should
>>>>> see that warning and fix it.
>>>> In case you did backup of MAC address or you have MAC address
>>>> printed on sticker, you can restore it. If you loaded distribution
>>>> U-Boot which erase MAC address and you have not did any backup,
>>>> then your MAC address is forever lost.
>>> On Turris MOX we write the MAC address into OTP of the SOC during
>>> It is possible to write code that burns the MAC address into OTP, I
>>> consider this a better option than enabling random MAC address.
>>> Maybe we can enable random MAC address, and if MAC address is not
>>> found in environment nor OTP, issue a warning, something like
>>> "WARNING: MAC address lost, please burn the MAC address of your
>>> device to OTP with command xyz"
>>> What do you think?
>> if there's a mac stored in otp during manufacturing, that's of course
>> the best solution. There's no need for CONFIG_NET_RANDOM_ETHADDR
>> then. But globalscale does not do that.
>> Doing it afterwards, so u-boot claiming some otp space for itself,
>> and instructing the user how to write to it sounds too
>> For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be enabled if
>> there's no mac address stored in a sane way (where saving it just to
>> an u-boot env during manufacturing doesn't count as sane, especially
>> if the vendor moves the spi env offset around in a firmware update).
>> So I think CONFIG_NET_RANDOM_ETHADDR is enough.
> I understand Pali's concerns, though.
> The thing is that if we enable CONFIG_NET_RANDOM_ETHADDR by default,
> many users that have managed to wipe their env won't care about that
> they are using randomly generated MAC address and won't solve the issue,
> which is again the spirit of correctly configure networks.
> If we do not enable CONFIG_NET_RANDOM_ETHADDR, the worst that can
> happen is that the device won't boot from network. This will force the
> users to solve the issue, which is not that hard
> setenv ethaddr aa:bb:cc:dd:ee:ff (address from the sticker)
> If the users boots from SD/eMMC/SATA/USB, Linux won't have problem with
> network, since it will generate random MAC address anyway.
Good point, so let's assume the user doesn't have a mac stored.
* u-boot refuses to do anything network related
* Linux generates a random mac, network works
* u-boot generates a random mac, network works
* Linux uses the same random mac, passed on from u-boot throught the
device-tree, network works
It's still random, but at least it's consistent ;)
> The worst case scenario does not look that bad to me if we don't enable
> CONFIG_NET_RANDOM_ETHADDR by default.
> I think the option CONFIG_NET_RANDOM_ETHADDR should be used only by
> developers when they are developing on devices that have not yet burned
> the MAC addresses, or on some embedded devices that don't have space
> for saving a MAC address (no storage for env or anything else, do such
> devices exist?).
It looks like it's used for more than that though:
$ git ls-files configs|wc -l
$ git grep CONFIG_NET_RANDOM_ETHADDR configs|wc -l
Some popular sbc's are part of that list.
> But it shouldn't be used as a default setting for a device that has
> storage where it can store the address.
>> But it would be nice if e.g. a board could set specific env vars as
>> indestructible/unwipeable/precious/whatever, which instructs `env
>> default -a` to keep those (which is common after updating the
>> bootloader). Maybe that's an idea worth pursuing?
> Yes, that would be nice :)
More information about the U-Boot