[PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR

[Andre Heider]

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>
>>> wrote:
>>>> 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
>>> manufacturing.
>>>
>>> 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
>> dangerous/error-prone.
>>
>> 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)
>    saveenv
> 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.

Without CONFIG_NET_RANDOM_ETHADDR:
* u-boot refuses to do anything network related
* Linux generates a random mac, network works

With CONFIG_NET_RANDOM_ETHADDR:
* 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
1362

$ git grep CONFIG_NET_RANDOM_ETHADDR configs|wc -l
209

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 :)
> 
>> Thanks,
>> Andre
> 
> Marek
>