Re: kern/59997: if_ure.c has a check to avoid setting hardware capabilities that's impossible to satisfy

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

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

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kre%netbsd.org@localhost
Subject: Re: kern/59997: if_ure.c has a check to avoid setting hardware
 capabilities that's impossible to satisfy
Date: Tue, 24 Feb 2026 19:32:05 -0500

 On Thu, 2026-02-12 at 18:20 +0000, Robert Elz via gnats wrote:
 > The following reply was made to PR kern/59997; it has been noted by
 > GNATS.
 >=20
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:=20
 > Subject: Re: kern/59997: if_ure.c has a check to avoid setting
 > hardware capabilities that's impossible to satisfy
 > Date: Fri, 13 Feb 2026 01:18:52 +0700
 >=20
 > =C2=A0=C2=A0=C2=A0=C2=A0 Date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
 Thu, 12 Feb 2026 01:20:01 +0000 (UTC)
 > =C2=A0=C2=A0=C2=A0=C2=A0 From:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
 "david%gutteridge.ca@localhost=C2=A0via gnats"
 > <gnats-admin%NetBSD.org@localhost>
 > =C2=A0=C2=A0=C2=A0=C2=A0 Message-ID:=C2=A0 <20260212012001.340281A923D@mo=
 llari.NetBSD.org>
 > =C2=A0
 > =C2=A0
 > =C2=A0=C2=A0 | Presumably this test should really be:
 > =C2=A0=C2=A0 |
 > =C2=A0=C2=A0 | if (un->un_flags & ~(URE_FLAG_8152 | URE_FLAG_VER_4C00)) {
 > =C2=A0
 > =C2=A0I have none of those, and know nothing about them at all, but
 > =C2=A0it looks to me as if the what the test probably really intended
 > =C2=A0was
 > =C2=A0
 > =C2=A0	if (!(un->un_flags & URE_FLAG_VER_4C00)) {
 > =C2=A0
 > =C2=A0That is, if it is not a 4C00 (using the original to test for that
 > =C2=A0state is simply bizarre, but is also the kind of thing easy to do).
 
 Thanks, yes, your way of expressing that is simpler; I got lost in the
 existing style there.
 
 I also looked at the Linux driver provided by Realtek itself, and, yes
 the intent is indeed that 4C00 *only* is supposed to not advertise/
 enable those particular capabilities. (Much like with our code, there's
 no comment explaining why, and the change history is useless, as it
 simply syncs with a vendor-internal source. Evidently 4C00's buggy.
 I see similar things elsewhere, e.g., our ic/gem.c disables some
 offloading capabilities, but it has a nice comment explaining what's
 going on.) The way the Linux driver expresses that is different enough
 from our code (turns on all capabilities universally, then selectively
 disables 4C00, and the coding specifics vary considerably).
 
 (I tried to find relevant hardware, and came across a sub-$10 dongle
 that advertised as an 8152B, but unfortunately it's the 4C10 variant.
 Oh well.)
 =C2=A0
 > =C2=A0But there is more odd code around there ... the transmit offload
 > =C2=A0capabilities for v6 are only set if INET6 is defined (which is
 > =C2=A0reasonable) but the similar receive capabilities are set
 > unconditionally
 > =C2=A0(except for the above test) which makes little sense to me.=C2=A0
 
 I looked at pretty much every other driver I could find in our tree
 that offers any IPv6 checksum offloading, and none of them wrap those
 capabilities in an INET6 ifdef, so it seems simpler to follow suit
 here and avoid the potential confusion/inconsistency.
 
 Thanks,
 
 Dave