Re: iwx VHT unknown rate (type 3)

On Wed, 8 Apr 2026, J.R. Oldroyd wrote:

> On Wed, 8 Apr 2026 14:02:59 -0700 Adrian Chadd <adrian@freebsd.org> wrote:
>>
>> Yup, it's a known issue, it should only happen during initial
>> negotiation when it's sending the early dhcp exchange and those frames
>> are marked as "please tell me what happened with them."
>> Later frames are handled completely in firmware and we don't get or
>> need per-frame completion information.
>>
>> I'll go sit down and finish cleaning that up shortly. It's harmless,
>> just a reminder that the code path needs converting to the newer world
>> order.
>>
>>
>>
>> -a
>>
>
> Thanks Adrian.
>
> Actually it's happening regularly during the day.  Laptop is about
> 2m from the A/P with a clear line of sight so there shouldn't be any
> disconnects/reconnects.
>
> That said, the i/f is under a lagg with an Ethernet which is master at
> the moment so the wlan disconnects may be related to that.

This has nothing to do with how close you are to the AP or if you are using
lagg.  This is a legacy rate code path which doesn't work with VHT, taken
unconditionally ending in a place which is a dead end logging it so that
someone can go and have a look.

net80211 has this still in the code path for ageing scan results
though I never saw that and am not sure we can hit it easily.

iwx has it in the TX path (possibly double in the same function,
depending on whether tx debugging is on or not;  there is another
call in that function too but that should be fine as it would deal
with a basic rate to my understanding).


iwlwifi (and other LinuxKPI based wireless drivers) should not hit this
at all as they don't rely on net80211 internal rate information anymore
(iwlwifi mvm 3xxx/7xxx would if we were to add VHT support for them).

HTH,
/bz

-- 
Bjoern A. Zeeb                                                     r15:7