Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface
Date: Sat, 23 Sep 2023 19:50:46 UTC
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 <pmh@hausen.com>:
>>>> 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.
Mike
> Regards,
> Ronald.