It fixed the problem, and connection is OK.
I did resolve a git revert conflict and I hope I've done it right:
```
commit 2f01dc980004db5651186efb9e8a475f98f054b2 (HEAD -> main)
Author: Nuno Teixeira <edua...@freebsd.org>
Date: Sat Sep 20 22:33:04 2025 +0100
Revert "iwx: enable seqno offload"
This reverts commit 5bf3c5586b5e8256af0c1a6916fb5fdc6c70b3c9.
diff --git a/sys/dev/iwx/if_iwx.c b/sys/dev/iwx/if_iwx.c
index 3b29c8e78b97..6921ef453406 100644
--- a/sys/dev/iwx/if_iwx.c
+++ b/sys/dev/iwx/if_iwx.c
@@ -5673,10 +5673,6 @@ iwx_tx(struct iwx_softc *sc, struct mbuf *m, struct
ieee80211_node *ni)
if (rinfo == NULL)
return EINVAL;
- /* Offloaded sequence number assignment */
- /* Note: Should be done in firmware on all supported devices */
-
- /* Radiotap */
if (ieee80211_radiotap_active_vap(vap)) {
struct iwx_tx_radiotap_header *tap = &sc->sc_txtap;
@@ -5689,7 +5685,6 @@ iwx_tx(struct iwx_softc *sc, struct mbuf *m, struct
ieee80211_node *ni)
ieee80211_radiotap_tx(vap, m);
}
- /* Encrypt - CCMP via direct HW path, TKIP/WEP indirected
openbsd-style for now */
if (wh->i_fc[1] & IEEE80211_FC1_PROTECTED) {
k = ieee80211_crypto_get_txkey(ni, m);
if (k == NULL) {
```
I will update my rpi4 box that uses a usb Archer RTL8821AU (rtwn) and see
what happens without revert.
Adrian Chadd <adr...@freebsd.org> escreveu (sábado, 20/09/2025 à(s) 22:14):
> Just cd src ; make buildkernel ; it will do an incremental build.
>
> then make reinstallkernel
>
>
>
> -adrian
>
>
> On Sat, 20 Sept 2025 at 13:42, Nuno Teixeira <edua...@freebsd.org> wrote:
>
>> Ok, after reverting 5bf3c55 how do I quick compile it to avoid compile
>> entire kernel?
>>
>> Adrian Chadd <adr...@freebsd.org> escreveu (sábado, 20/09/2025 à(s)
>> 20:13):
>>
>>>
>>>
>>> On Sat, 20 Sept 2025 at 12:04, Nuno Teixeira <edua...@freebsd.org>
>>> wrote:
>>>
>>>> Hello Adrian!
>>>>
>>>> I'm using iwx driver on my AX201 for some months and I saw it as stable
>>>> on my laptop.
>>>> (switching to iwlwifi, I saw that connection rate becomes degradated
>>>> after some hours, and some crashes too)
>>>>
>>>> I'm using main 20250920-e043af9ca596 . Today I upgraded to
>>>> 20250920-31ec8b6407fd and iperf3 tests to my router failed:
>>>>
>>>> - after failed iperf3, I need to restart servive netif to get internet
>>>> back.
>>>> - nothing in messages, dmesg, no crash
>>>>
>>>
>>> Hm. Yeah I saw some oddness like this, even before my work.
>>>
>>> Can you try reverting the iwx diffs until it works? Not the net80211
>>> ones; as they're only enabled if you enable the iwx ones.
>>>
>>> here's the list to try reverting one at a time. They're one or two line
>>> diffs, you can totally do it locally without checking out a new tree, and
>>> reload the iwx module. :-)
>>>
>>>
>>> commit 5bf3c5586b5e8256af0c1a6916fb5fdc6c70b3c9
>>> Author: Adrian Chadd <adr...@freebsd.org>
>>> Date: Wed Jun 4 20:50:33 2025 -0700
>>> iwx: enable seqno offload
>>>
>>> Author: Adrian Chadd <adr...@freebsd.org>
>>> Date: Fri Aug 29 22:10:22 2025 -0700
>>>
>>> [iwx] tell net80211 not to originate NULL data frames
>>>
>>> Lemme know what you see!
>>>
>>> Thanks!
>>>
>>>
>>>
>>> -adrian
>>>
>>>
>>>
>>>
>>>
>>>> iperf3 -c 192.168.1.1
>>>> Connecting to host 192.168.1.1, port 5201
>>>> [ 5] local 192.168.1.188 port 41996 connected to 192.168.1.1 port 5201
>>>> [ ID] Interval Transfer Bitrate Retr Cwnd
>>>> [ 5] 0.00-1.06 sec 3.75 MBytes 29.6 Mbits/sec 110 214 KBytes
>>>> [ 5] 1.06-2.06 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
>>>> [ 5] 2.06-3.06 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
>>>> [ 5] 3.06-4.03 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
>>>> [ 5] 4.03-5.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
>>>> [ 5] 5.06-6.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
>>>> [ 5] 6.06-7.02 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
>>>> [ 5] 7.02-8.06 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
>>>> [ 5] 8.06-9.02 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
>>>>
>>>> - rolled back to latest BE:
>>>>
>>>> iperf3 -c 192.168.1.1
>>>> Connecting to host 192.168.1.1, port 5201
>>>> [ 5] local 192.168.1.188 port 49619 connected to 192.168.1.1 port 5201
>>>> [ ID] Interval Transfer Bitrate Retr Cwnd
>>>> [ 5] 0.00-1.06 sec 2.88 MBytes 22.7 Mbits/sec 274 1.41 KBytes
>>>> [ 5] 1.06-2.00 sec 25.1 MBytes 224 Mbits/sec 79 280 KBytes
>>>> [ 5] 2.00-3.03 sec 31.6 MBytes 259 Mbits/sec 23 249 KBytes
>>>> [ 5] 3.03-4.06 sec 36.2 MBytes 295 Mbits/sec 2 263 KBytes
>>>> [ 5] 4.06-5.04 sec 35.2 MBytes 301 Mbits/sec 6 266 KBytes
>>>> [ 5] 5.04-6.03 sec 30.5 MBytes 259 Mbits/sec 3 236 KBytes
>>>> [ 5] 6.03-7.06 sec 31.6 MBytes 257 Mbits/sec 14 214 KBytes
>>>> [ 5] 7.06-8.06 sec 30.8 MBytes 259 Mbits/sec 0 368 KBytes
>>>> [ 5] 8.06-9.05 sec 30.6 MBytes 259 Mbits/sec 4 339 KBytes
>>>> [ 5] 9.05-10.01 sec 29.8 MBytes 260 Mbits/sec 2 330 KBytes
>>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>>> [ ID] Interval Transfer Bitrate Retr
>>>> [ 5] 0.00-10.01 sec 284 MBytes 238 Mbits/sec 407
>>>> sender
>>>> [ 5] 0.00-10.02 sec 284 MBytes 237 Mbits/sec
>>>> receiver
>>>>
>>>> Thanks,
>>>>
>>>> Adrian Chadd <adr...@freebsd.org> escreveu (sábado, 20/09/2025 à(s)
>>>> 01:55):
>>>>
>>>>> hi!
>>>>>
>>>>> I've been sitting on this for a while and noodling on the devices I
>>>>> have here.
>>>>> If you're using -HEAD, please update and let me know if wifi is OK or
>>>>> not OK after today's commits.
>>>>>
>>>>>
>>>>> First up is enabling sequence number offloading in almost everything.
>>>>> I think the only thing left to do is the linuxkpi layer and then
>>>>> thoroughly test the heck out of it. The TL;DR is that now the sequence
>>>>> number assignment is done by a call from the driver - at the same time
>>>>> it's
>>>>> doing encryption and other setup - rather than net80211. This removes the
>>>>> need for the "TX lock" in the net80211 transmit path.
>>>>>
>>>>> I added this way back in 2011/2012 timeframe because I noticed that
>>>>> after the vap work, sometimes i'd get dropped packets / hung data streams.
>>>>> What was happening was the sequence numbers were assigned by net80211, but
>>>>> the encryption - and the encryption sequence IVs - were being done in the
>>>>> driver. This can happen concurrently across multiple CPUs, or even
>>>>> preempted on a single CPU. It wasn't a problem on earlier single CPU
>>>>> setups
>>>>> because preemption wasn't as aggressive, and pre-VAP the encapsulation /
>>>>> encryption was actually done by the driver calling into net80211.
>>>>>
>>>>> I cheaped out and added that lock. It fixed it for everything, with
>>>>> the cost of concurrency performance and some LORs.
>>>>>
>>>>> So, my goal is to finally get rid of the lock entirely during -16.
>>>>>
>>>>> Secondly, the NULL data frame handling. This is something that has
>>>>> plagued things like iwn(4) forever, where the TX sequence number would get
>>>>> out of whack with the TX DMA ring (oh no I'm going into the weeds.)
>>>>> Anyway,
>>>>> it would cause the firmware to crash. A lot of NICs with firmware MACs
>>>>> actually generate their own NULL data frames so there's no need for us to
>>>>> do it. I've turned it off for a handful of NICs so we can test it out.
>>>>>
>>>>> Thanks! More to come once this settles.
>>>>>
>>>>>
>>>>>
>>>>> -adrian
>>>>>
>>>>>
>>>>
>>>> --
>>>> Nuno Teixeira
>>>> FreeBSD UNIX: <edua...@freebsd.org> Web: https://FreeBSD.org
>>>>
>>>
>>
>> --
>> Nuno Teixeira
>> FreeBSD UNIX: <edua...@freebsd.org> Web: https://FreeBSD.org
>>
>
--
Nuno Teixeira
FreeBSD UNIX: <edua...@freebsd.org> Web: https://FreeBSD.org
