[PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR

[Pali Rohár]

On Friday 11 September 2020 18:22:04 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.

Yes, CONFIG_NET_RANDOM_ETHADDR does not solve the issue. It is just a
workaround which hides real issue.

> 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.
> 
> The worst case scenario does not look that bad to me if we don't enable
> CONFIG_NET_RANDOM_ETHADDR by default.

I see it in the same way.

CONFIG_NET_RANDOM_ETHADDR does not affect Linux kernel as it always
generates a random mac address when it does not have correct one.

Moreover CONFIG_NET_RANDOM_ETHADDR introduce another issue. In case
there is no valid mac address, U-Boot generates one. But it does not
pass this generates mac address to kernel and therefore kernel generates
another new random mac address.

I just do not see a benefit from having CONFIG_NET_RANDOM_ETHADDR
enabled by default for Espressobin. Real issue is hidden, people would
be confused (why it still have different mac address) and distributions,
like armbian would continue "workarounding" it by hardcoding one static
mac address for all devices into boot scripts or other places.

> 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?).
> 
> 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