Stefan Sperling <s...@stsp.name> wrote: > There is nothing actionable in your report, though it is good to know > that there seems to be an issue which the driver could handle better. > > It is unclear to me why the device would suddenly stop generating > interrupts, which is what leads to a "device timeout". Generally, this > implies a problem that triggers at firmware, hardware, or RF level.
Stefan, Thank you for your reply. > It would be good to know if your AP did anything extraordinary at the time. > Hopefully that would provide more context and lead to clues. > > Did your AP switch channels, perhaps? All of the output I had pertained to that one channel, so it's not obvious that this happened (at least as I understand it). > Or did the AP switch its channel width? > You could record beacons with tcpdump and look for differences in vhtop > information where the channel width is encoded: > tcpdump -n -i iwx0 -y IEEE802_11_RADIO -s 4096 -v -D in type mgt subtype > beacon > Channel width info should show up like this: > vhtop=<80MHz chan,center chan 122, Thanks for this suggestion; I'll run tcpdump tonight once I am back on wifi to see if I can work out any correlation with the drop-outs. > Those are just shots in the dark though, the driver is already expected > to cope when such changes occur. > > When the AP simply disappears from the air as a result of switching > channels, a small stall followed by a reconnect as you describe is > expected. We do not yet honor channel switch announcements (they are > not authenticated and therefore could be abused; something to revisit > once support for protected management frames gets implemented). The > exact error condition shown in debug output will depend on what the > driver was doing at the moment. If there are frames on Tx queues, I > believe a device timeout is possible, though not pretty. > > Maybe the reason is something else entirely and this issue will not > have anything related happening on the AP side. I'm not going to rule out my APs being at fault - I have had some issues in the past, which I believe you helped me out with >1 year ago which was remedied by turning off some of the "smart" channel selection/adaptation stuff on my APs. I'll take a look at what I did there and see if that needs to be applied for 11ac also. If my recollection is right, this particular issue manifests in a different way though. > I have been using iwx on my desktop, always on, on 11ac, without > issues, for weeks. At least for me, it has been quite > stable. Certainly no less stable than this driver ever has been. It > runs for weeks without firmware errors happening, which was not the > case a year or two ago.
