Thank you for the analysis. The fix (pun: fix the channel) is trivial once I know what's going on.
"A workaround is to fix the channel used by the AP, rather than letting the AP auto-select one." Indeed. On Tue 24. Mar 2026 at 12:32, Stefan Sperling <[email protected]> wrote: > On Tue, Mar 24, 2026 at 09:16:00AM +0100, mwpudrtxoe wrote: > > >Synopsis: IWX reports errors and eventually hangs with a full send > buffer > > >Category: kernel > > >Environment: > > System : OpenBSD 7.8 > > Details : OpenBSD 7.8 (GENERIC.MP) #6: Fri Mar 20 10:18:39 > MDT 2026 > > [email protected]: > /usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > > > The IWX driver sporadically reports errors like these: > > > > iwx0: unhandled firmware response 0x3ff/0x20000008 rx ring 126[1] > > iwx0: unhandled firmware response 0x3ff/0x20000008 rx ring 122[229] > > iwx0: unhandled firmware response 0x3fd/0x2000000c rx ring 81[128] > > iwx0: unhandled firmware response 0x3ff/0x20000008 rx ring 81[138] > > iwx0: unhandled firmware response 0x3ff/0x20000008 rx ring 91[4] > > iwx0: unhandled firmware response 0x3fd/0x2000000c rx ring 104[72] > > iwx0: unhandled firmware response 0x3fd/0x2000000c rx ring 123[124] > > > > ... then after a long while (about one day) runs into a full send buffer. > > > > This is related to channel switch announcements sent by the AP. > The firmware sends notification 0x3ff to the driver and will no longer > send frames out. Sending frames on the channel which the AP is switching > away from is not allowed (I assume this prevents interference with radar, > which could be the reason why the AP is moving away). > > The driver is expected to react to this situation, e.g. by resetting the > interface and scan for a new AP, or keep the interface associated but move > it to the AP's new channel. Our driver doesn't do any of that yet. > > A fix wouldn't be very hard to write. The interface needs to be put back > into SCAN state, and net80211 needs to be taught to skip access points > which > are currently announcing a channel switch. Or the driver could be taught to > send the necessary firmware commands to switch the device to the new > channel > in response to the channel switch annoucenment. > > I have too many things on my plate right now to work on this myself. > > A workaround is to fix the channel used by the AP, rather than letting > the AP auto-select one. Preferrably use a channel with does not require > DFS. >
