Re: Request for architectural review: experimental net80211/LinuxKPI HE station support

On Thu, 5 Nov 2026, Denis Lemire wrote:

Hi,

this is my personal take on this.

> I've been developing and testing experimental 802.11ax (HE) station support
> for FreeBSD, using an HP laptop with a Realtek RTL8852BT and a UniFi U6
> Mesh. I'd appreciate architectural review and guidance on the appropriate
> integration route.
>
> The series connects native HE parsing, encoding and owned association state
> to LinuxKPI peer/BSS capability handoffs, rate calculation and receive
> metadata. HE defaults off. Testing also exposed separate key/queue ordering
> and aggregation-stop lock issues, addressed in distinct commits.
>
> Source, comprising 21 signed commits based on CURRENT main 12f90bbd3029:
> https://github.com/denislemire/freebsd-src/tree/codex/80211ax-sta-review
>
> Reviewer guide, standalone helper tests and sanitized evidence:
> https://denis.lemire.name/download/enabling-he-wifi-in-freebsd.pdf

If I were to ask you a technical question about something in there, could you answer (without LLM)?


> Fresh CURRENT GENERIC builds with WITNESS and INVARIANTS pass bounded
> controls with HE disabled and with HE using software or hardware
> encryption. A separately identified STABLE port also passes IPv4/IPv6
> traffic, integrity checks, observed pairwise key renewals and automatic HE
> startup across a normal reboot.
>
> Hardware validation is limited to this adapter/AP combination at 40 MHz.
> Software encryption remains slower; suspend/resume, broader
> interoperability and several lifecycle cases need further work. The guide
> distinguishes hardware observations from modeled helper coverage.
>
> Code, tests and prose were developed with AI assistance; I remain
> responsible for their provenance and claims.
>
> I'd appreciate your assessment of whether this is a useful starting point
> for FreeBSD, what needs to change, and how best to get it reviewed. I'm
> learning kernel development through this work and would welcome guidance on
> bringing it up to the project's standards.

I would assume that at this point no (wireless) committer is going to spend any serious time on looking at this to get it integrated.
Whether this may change in the future will probably depend on other policies of the project.

I personally am bound to a at best "read-only LLM" policy so I couldn't currently even if I wanted to.

If users want to integrate the work into local trees, they are free to, but they will likely also not see (much/any) support?
Or would you be able to help them debug problems and will you maintain this code?

/bz

-- 
For there shall arise false Christs, and false prophets, and shall shew
great signs and wonders; insomuch that, if it were possible, they shall
deceive the very elect. Behold, I have told you before. [Mat. 24:24-25]