Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface

On 23 Sep 2023, at 14:50, Mike Karels wrote:

> On 23 Sep 2023, at 14:28, Ronald Klop wrote:
>
>> On 9/20/23 22:02, Mike Karels wrote:
>>> On 20 Sep 2023, at 14:49, Patrick M. Hausen wrote:
>>>
>>>> Hi all,
>>>>
>>>> some more research ...
>>>>
>>>>> Am 20.09.2023 um 21:05 schrieb Patrick M. Hausen <[email protected]>:
>>>>> No worky.
>>>>> [...]
>>>>
>>>>
>>>> I could not find any code in the network startup routines in userland that
>>>> would generate and configure a random MAC address. So I looked for
>>>> the driver.
>>>>
>>>> Apparently the TuringPi uses smsc(4), and there we have it straight from
>>>> the driver source:
>>>>
>>>> -------------------
>>>> static void
>>>> smsc_attach_post(struct usb_ether *ue)
>>>> {
>>>> [...]
>>>>   /* Attempt to get the mac address, if an EEPROM is not attached this
>>>> * will just return FF:FF:FF:FF:FF:FF, so in such cases we invent a MAC
>>>> * address based on urandom.
>>>> */
>>>> [...]
>>>>   /* Initialise the chip for the first time */
>>>> smsc_chip_init(sc);
>>>> }
>>>> -------------------
>>>>
>>>> So what we would really need is a tunable - one per driver or possibly a
>>>> common one read and acted upon by all of the USB ethernet drivers ...
>>>
>>> There is a routine called ether_gen_addr(), which will generate an
>>> Ethernet MAC based on the hostid and the interface name, both of which
>>> are reasonably stable.  Not very many drivers use it though.  It
>>> would probably be an improvement.
>>>
>>>> With no code on our side to perform anything, no wonder the RPI
>>>> config files have no effect.
>>>
>>> It would seem wrong to me to have USB Ethernet drivers using an RPI-specific
>>> mechanism.
>>>
>>>> Dang. That's frustrating. With aarch64 having been promoted to "tier 1"
>>>> I really expected full support for all RPI platforms and related features
>>>> and hardware.
>>>>
>>>> Or am I misreading that? I though that the Pi was *the* aarch64 platform,
>>>> at least in numbers ...
>>>
>>> In numbers, probably.  In support, no.
>>>
>>> 		Mike
>>>
>>>> Kind regards,
>>>> Patrick
>>>
>>
>>
>> Would this work?
>>
>> diff --git a/sys/dev/usb/net/if_smsc.c b/sys/dev/usb/net/if_smsc.c
>> index 0a0268bfa1a2..4a7983a20717 100644
>> --- a/sys/dev/usb/net/if_smsc.c
>> +++ b/sys/dev/usb/net/if_smsc.c
>> @@ -1554,6 +1554,7 @@ static void
>>  smsc_attach_post(struct usb_ether *ue)
>>  {
>>         struct smsc_softc *sc = uether_getsc(ue);
>> +       struct ether_addr eaddr;
>>         uint32_t mac_h, mac_l;
>>         int err;
>>  @@ -1589,9 +1590,10 @@ smsc_attach_post(struct usb_ether *ue)
>>                         err = usb_fdt_get_mac_addr(sc->sc_ue.ue_dev, &sc->sc_ue);
>>  #endif
>>                 if ((err != 0) || (!ETHER_IS_VALID(sc->sc_ue.ue_eaddr))) {
>> -                       read_random(sc->sc_ue.ue_eaddr, ETHER_ADDR_LEN);
>> -                       sc->sc_ue.ue_eaddr[0] &= ~0x01;     /* unicast */
>> -                       sc->sc_ue.ue_eaddr[0] |=  0x02;     /* locally administered */
>> +                       device_printf(ue->ue_dev, "No MAC address found. Using ether_gen_addr().\n");
>> +                       ether_gen_addr(ue->ue_ifp, &eaddr);
>> +                       for (int i = 0; i < ETHER_ADDR_LEN; i++)
>> +                               sc->sc_ue.ue_eaddr[i] = eaddr.octet[i];
>>                 }
>>         }
>>
>>
>> I don't have the hardware so I can't test it.
>
> It looks right to me, and seems like a big improvement.  I don't have the
> hardware either.

Actually, you could pass sc->sc_ue.ue_eaddr as the second parameter to
ether_gen_addr, and eliminate eaddr.

		Mike
>
>> Regards,
>> Ronald.