Re: kern/60592: random Mac address generation in genet Ethernet driver causes problems

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/60592: random Mac address generation in genet Ethernet driver causes problems
Date: Sat, 15 Aug 2026 05:57:54 +0700

     Date:        Fri, 14 Aug 2026 21:50:04 +0000 (UTC)
     From:        "joe%ns1.eloisystems.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20260814215004.EF6ED1A923F%mollari.NetBSD.org@localhost>
 
 
   |         if (maclo == 0 && machi == 0) {
   |                 /* Create one */
   | -               maclo = 0x00f2 | (cprng_strong32() & 0xffff0000);
   | +               maclo = cprng_strong32() & 0x0000ffff;
   |                 machi = cprng_strong32() & 0xffff;
   |         }
   |  
   | -       eaddr[0] = (maclo >> 24) & 0xff;
   | +       eaddr[0] = (maclo >> 24) | 0xf2;
   |         eaddr[1] = (maclo >> 16) & 0xff;
   |         eaddr[2] = (maclo >>  8) & 0xff;
   |         eaddr[3] = (maclo >>  0) & 0xff;
   |
   |
   | This preserves the intent to zero out second byte and have a 0xf2
   | in first byte and randomize third and fourth byte in the Mac address
   | generated.
 
 I suspect that the correct fix (which is not that) would be to change the
 ">>" values to be (in order) 0 8 16 24 for the 4 addr bytes, so "maclo" is
 treated as a little endian value, which it was clearly intended to be.
 
 Just that (not altering the init of maclo if it wasn't set) should be all
 that is required.   If it is desired to allow maclo to be a big endian
 value when passed in rather than generated, an
 		else
 			maclo = htonl(maclo);
 
 can be added to the "if" there.    The code should respect what is given
 to it, when it isn't all 0, however, not force "f2" anywhere, or 0 anywhere,
 that would be up to wherever the passed in maclo/machi values come from
 to assign as desired.
 
 The code as proposed also doesn't clear the multicast bit, which it
 claims it should (but only when it is passed in set, in which case
 it shouldn't - though that would be strange indeed).
 
 kre