Re: kern/58702: eqos(4) MAC address fallback is busted

The following reply was made to PR kern/58702; it has been noted by GNATS.

From: [email protected] (Michael van Elst)
To: [email protected]
Cc: 
Subject: Re: kern/58702: eqos(4) MAC address fallback is busted
Date: Thu, 16 Jul 2026 12:02:12 -0000 (UTC)

 [email protected] ("David H. Gutteridge via gnats") writes:
 
 >The following reply was made to PR kern/58702; it has been noted by GNATS.
 
 >From: "David H. Gutteridge" <[email protected]>
 >To: [email protected]
 >Cc: 
 >Subject: Re: kern/58702: eqos(4) MAC address fallback is busted
 >Date: Wed, 15 Jul 2026 21:02:44 -0400
 
 > The main (functional ordering/invalid logic) issue mentioned here was
 > addressed by mlelstv@ in dwc_eqos.c, r. 1.46. (But not pulled up to any
 > branches, yet.)
 > 
 > > Even if it were taken, why do we always set the low 16 bits to be
 > > 0x00f2, instead of setting the low 2 bits to be 0x2 (local=3D1,
 > > multicast=3D0)?
 
 
 You may want to use other "locally assigned" prefixes that are not random,
 which would be impossible if you take all the bits. The random value is
 to avoid conflicts within your LAN segment and 32 random bits are good
 enough.
 
 Of course "good enough" isn't a strong argument nowadays.