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

["David H. Gutteridge via gnats" <gnats-admin%NetBSD.org@localhost>]

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)?
 
 I wondered this as well; what I've found so far is that this is
 consistent from when the first example entered our tree in 2014 onward.
 That would be dwc_gmac.c, r. 1.29, though I may have missed an example.
 Apparently no MAC OUI F2:00 assignment exists, so this could be a way
 of making the randomization more obviously such.
 (This is going by
 https://github.com/Ringmast4r/OUI-Master-Database/blob/master/LISTS/kismet_=
 manuf.txt
 .)
 
 Linux, on the other hand, does it as you describe.
 https://github.com/torvalds/linux/blob/71dfdfb0209b43dfd6f494f84f5548e4cfd1=
 8cb5/include/linux/etherdevice.h#L237
 
 > Maybe we should have a random_mac_address routine so these magic
 > constants don't get duplicated everywhere.
 
 I counted seven drivers with code like this, often similar or the same,
 but with some style variances. (When I added it to rtl8169.c, I didn't
 realize there was that much duplication already.)
 
 Separately, it may also make sense to add something to log that we're
 generating a random MAC, as this may cause unexpected complications for
 someone (IPv6 and SLAAC, network monitoring tools, insufficiently
 random generation if a MAC is calculated before the entropy pool is
 ready).
 
 Dave