Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface
- Reply: Mike Karels : "Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface"
- Reply: Patrick M. Hausen: "Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface"
- In reply to: Mike Karels : "Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 23 Sep 2023 19:28:39 UTC
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. Regards, Ronald.