Hello everyone,
this is my first post, so I ask for (some) forgiveness.
As a laptop FreeBSD user I encountered an issue when I changed my Livebox from W5 -> W7 provided by Orange (internet provider). I was able to connect to the router, but had no internet access. It worked fine on the previous Livebox. What follows is the result of my troubleshooting with, admittedly, help from Claude.
Some basic info:
Relevant rc.conf
After running dmesg, Claude wrote this as possible culprit.
It defined the problem as "wlan0 associates and obtains a DHCP lease, but no unicast RX follows." As someone who knows nothing about drivers, this might be gibberish.
A temporary solution was to remove the aggregation
Sadly, this caps the performance of the network from the 400+Mbps to about 100Mbps.
Below is fully Claude generated trace and it's analysis of the issue. I cannot verify if it makes logical sense, as I lack the sufficient knowledge.
Based on this analysis, Claude provided a kernel patch. Below I paste the logic of the provided patch as indicated by Claude. I do not copy the code of the actual patch. For one, because of the unclear copyright of such code, but also because I do not want to encourage anyone to use AI-generated code on their systems.
I cannot be sure of any of this!
All I can really say, is
All best!
this is my first post, so I ask for (some) forgiveness.
As a laptop FreeBSD user I encountered an issue when I changed my Livebox from W5 -> W7 provided by Orange (internet provider). I was able to connect to the router, but had no internet access. It worked fine on the previous Livebox. What follows is the result of my troubleshooting with, admittedly, help from Claude.
Some basic info:
Code:
FreeBSD 15.1-RELEASE-p3, GENERIC amd64, laptop.
Intel AX210/AX1675 [Typhoon Peak], iwlwifi(4).
VHT/11ac. AP: Orange Livebox W7
Driver version: wifi-firmware-iwlwifi-kmod-ax210-20260410
Code:
wlans_iwlwifi0="wlan0"
create_args_wlan0="country FR regdomain etsi"
ifconfig_wlan0="WPA SYNCDHCP"After running dmesg, Claude wrote this as possible culprit.
Code:
iwlwifi0: 0x2010350B | ADVANCED_SYSASSERT
#5 iwl_mvm_mac_ampdu_action+0x238
#6 lkpi_ic_ampdu_rx_start+0x13a
#7 ht_recv_action_ba_addba_request+0x13d
iwlwifi0: lkpi_ic_ampdu_rx_start: mo_ampdu_action returned -5
iwlwifi0: FW error in SYNC CMD UNKNOWN
umac data1=0x7 data2=0x1 data3=0xDEADBEEF
UMAC PC 0x804a5aec, LMAC1 PC 0xd0It defined the problem as "wlan0 associates and obtains a DHCP lease, but no unicast RX follows." As someone who knows nothing about drivers, this might be gibberish.
A temporary solution was to remove the aggregation
ifconfig_wlan0=... -ampdurxSadly, this caps the performance of the network from the 400+Mbps to about 100Mbps.
Below is fully Claude generated trace and it's analysis of the issue. I cannot verify if it makes logical sense, as I lack the sufficient knowledge.
Code:
TRACE
compat.linuxkpi.80211.debug=0x100000 (D80211_TRACE_MO). Tuple is
{ sta, action, buf_size, timeout, ssn, tid, amsdu }; action 0 is
IEEE80211_AMPDU_RX_START, 1 is IEEE80211_AMPDU_RX_STOP.
lkpi_ic_recv_action <- ADDBA Request #1
mo_ampdu_action { 0xfffff8000434c1c0, 0, 64, 0, 10, 4, 0 }
WARNING (rcu_access_pointer(mvm->baid_map[baid])) failed at
contrib/dev/iwlwifi/mvm/sta.c:2985
lkpi_ic_ampdu_rx_start:6332 IMPROVE_HT net80211 is missing the error
check on return and assumes success
lkpi_ic_send_action <- ADDBA Response
lkpi_ic_recv_action <- ADDBA Request #2
mo_ampdu_action { 0xfffff8000434c1c0, 0, 64, 0, 10, 4, 0 }
iwlwifi0: Microcode SW error detected. Restarting 0x0. -> 0x2010350B
Two IEEE80211_AMPDU_RX_START downcalls for the same sta and tid, with no
RX_STOP between them; there is no action 1 anywhere in the capture. Both
carry ssn=10, so the AP re-sent the same ADDBA Request rather than opening
a new session.
ANALYSIS
net80211's ht_recv_action_ba_addba_request() (sys/net80211/ieee80211_ht.c)
calls ic->ic_ampdu_rx_start() for every ADDBA Request received, with no
check of rap->rxa_flags and with the return value discarded under an
existing "XXX TODO: handle ampdu_rx_start failure" comment.
The duplicate-session check lives inside net80211's *default*
ampdu_rx_start(), which tests IEEE80211_AGGR_RUNNING and purges the
reorder queue. LinuxKPI overrides that method, so for LinuxKPI drivers the
check is bypassed on the way down to the firmware. It is still applied on
the way back, because lkpi_ic_ampdu_rx_start() chains to
lhw->ic_ampdu_rx_start() after the downcall -- so net80211 software state
stays correct while the firmware receives a duplicate.
lkpi_ic_ampdu_rx_start() validates only lsta->added_to_drv and
lsta->state == IEEE80211_STA_AUTHORIZED before calling
lkpi_80211_mo_ampdu_action(). Its sibling lkpi_ic_ampdu_rx_stop() does
guard on IEEE80211_AGGR_RUNNING, with a comment explaining why the driver
must not be called for a session it never started; the start path appears
to have simply not received the same treatment.
Because net80211 ignores the error, it then replies ADDBA Response =
SUCCESS. The AP begins aggregating to a station whose firmware has just
reset, which produces the observed "lease but no unicast RX".Based on this analysis, Claude provided a kernel patch. Below I paste the logic of the provided patch as indicated by Claude. I do not copy the code of the actual patch. For one, because of the unclear copyright of such code, but also because I do not want to encourage anyone to use AI-generated code on their systems.
Code:
It issues IEEE80211_AMPDU_RX_STOP before IEEE80211_AMPDU_RX_START when
rap->rxa_flags has IEEE80211_AGGR_RUNNING set, both inside one
wiphy_lock() region, mirroring the guard already in
lkpi_ic_ampdu_rx_stop(). The TID is taken from params.tid, already decoded
from baparamset, so the reverse lookup that lkpi_ic_ampdu_rx_stop() has to
perform is not needed here.
A failed RX_STOP logs and continues rather than returning: that leaves the
pre-patch behaviour, and net80211 discards the return value in either case.
Confirmed. With the patch applied the duplicate is caught and no assert
occurs; aggregation throughput is restored (120 -> 480 Mbit/s). Paired
downcalls, same thread, adjacent stack slots (0x...b78 = params,
0x...b90 = stop_params, 0x18 apart):
... 5 100033 2146916272: params 0xfffffe00e88b3b78 { ..., 0, 64, 0, 1, 4, 0 }
... 5 100033 2146916272: params 0xfffffe00e88b3b90 { ..., 1, 0, 0, 0, 4, 0 }
... 5 100033 2146916273: params 0xfffffe00e88b3b78 { ..., 0, 64, 0, 1, 4, 0 }
... 5 100033 2146916273: params 0xfffffe00e88b3b90 { ..., 1, 0, 0, 0, 4, 0 }
... 3 100033 2146916273: params 0xfffffe00e88b3b78 { ..., 0, 64, 0, 1, 4, 0 }
... 3 100033 2146916274: params 0xfffffe00e88b3b90 { ..., 1, 0, 0, 0, 4, 0 }
The equivalent code in stable/15 and main is unchanged as of 2026-08-27:
lkpi_ic_ampdu_rx_start() and ht_recv_action_ba_addba_request() are
byte-identical to releng/15.1.I cannot be sure of any of this!
All I can really say, is
- Could not connect to internet.
ifconfig_wlan0=... -ampdurxallows for connection at download at slower speed. In my recollection, upload was not capped.- Whatever Claude's patch did, after recompiling the kernel, it allows for the proper ~480Mbps download.
All best!
