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

["Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/58702: eqos(4) MAC address fallback is busted
Date: Thu, 16 Jul 2026 12:02:12 -0000 (UTC)

 gnats-admin%NetBSD.org@localhost ("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" <david%gutteridge.ca@localhost>
 >To: gnats-bugs%netbsd.org@localhost
 >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.