On 2021-11-27 12:44 +0100, Stefan Sperling wrote: > This patch reworks the steps involved in roaming to a new access > point on iwm(4) and iwx(4) interfaces. > > The current implementation suffers from race conditions which can > leave the interface in a state where it gets "stuck". I have seen > this happen on iwm(4) 9560 in particular, while testing the driver > with new firmware images recently published by Intel. This may well > be related to other hangs people have reported in multi-AP environments > on both iwm(4) and iwx(4).
During testing I didn't see the race condition without the patch, but in the past there have been occassions where I had to run `... netstart.sh iwm0`. So far, I see no regressions with it. The card is an 8265 in a Lenovo T450s. iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi The wireless access points are both TP-Link EAP 245s, one a hardware V1, and the other V3. Before Patch: iwm0: sending delba to 50:c7:bf:94:08:44 on channel 11 mode 11n iwm0: sending deauth to 50:c7:bf:94:08:44 on channel 11 mode 11n iwm0: firmware has detected regulatory domain 'US' (0x5553) iwm0: roaming from 50:c7:bf:94:08:44 chan 11 to b0:95:75:6d:f0:97 chan 44 iwm0: RUN -> AUTH iwm0: sending auth to b0:95:75:6d:f0:97 on channel 44 mode 11a iwm0: AUTH -> ASSOC iwm0: sending assoc_req to b0:95:75:6d:f0:97 on channel 44 mode 11a iwm0: ASSOC -> RUN After Patch: iwm0: sending deauth to 50:c7:bf:94:08:44 on channel 11 mode 11n iwm0: roaming from 50:c7:bf:94:08:44 chan 11 to b0:95:75:6d:f0:97 chan 44 iwm0: RUN -> AUTH iwm0: sending auth to b0:95:75:6d:f0:97 on channel 44 mode 11a iwm0: AUTH -> ASSOC iwm0: sending assoc_req to b0:95:75:6d:f0:97 on channel 44 mode 11a iwm0: ASSOC -> RUN I see two differences. Before the patch, before "deauth" I see "sending delba" but not after patching, and before "firmware has detected regulatory domain 'US'", but not after. Perhaps they're unimportant, or don't show up in all roaming conditions. Cheers, --Aaron
