On Sunday, 19 May 2019 18:48, Stefan Sperling <s...@stsp.name> wrote: > On Sun, May 19, 2019 at 02:30:25PM +0000, Lévai, Dániel wrote: > > > Hi everyone! > > I wonder if this 0 particular issue is what I'm experiencing. Judging from > > the fact that the only thing needed for this to happen is a full-bandwidth > > (~1MB/s) throughput via athn0 for about 20 seconds, I'm inclined to say yes. > > I wanted to ask if this 1 commit should've fixed these kind of issues, or > > that "recalibration" is something else. > > What is your reason for asking? > > These timeouts should be infrequent and the driver should recover > without intervention. If that matches your case, there is nothing > critical to fix, though it would of course be nice to understand > and perhaps fix the problem. > > Are these device timeouts causing you actual problems or are you > just curious why these messages are appearing?
Well, in my experience here, there are two different kinds of consequences that can happen when these timeouts occur. The first (that happens let's say 90% of the time) can be fixed with a swift: # /sbin/ifconfig athn0 down; sleep 1; /sbin/ifconfig athn0 up It needs to be done, but at least it's fixable -- otherwise no client can connect the AP. And for some reason -- and this is really strange, I know --, sometimes it gets into a state where no client can connect/auth to the AP, and nothing seems to be able to fix it other than a hard reset of the AP. On a Linux client machine with wpa_supplicant(8) these are the log messages when this latter happens: May 19 19:08:38 serenity kernel: wlan0: authenticate with <ap> May 19 19:08:38 serenity kernel: wlan0: send auth to <ap> (try 1/3) May 19 19:08:38 serenity kernel: wlan0: authenticated May 19 19:08:38 serenity kernel: wlan0: associate with <ap> (try 1/3) May 19 19:08:38 serenity kernel: wlan0: RX AssocResp from <ap> (capab=0x411 status=0 aid=2) May 19 19:08:38 serenity kernel: wlan0: associated May 19 19:08:39 serenity kernel: wlan0: deauthenticated from <ap> (Reason: 15=4WAY_HANDSHAKE_TIMEOUT) This just goes on and on and on. But e.g. Android phones cannot connect to the AP either in this case, and they say "Check password and try again" in the Wi-Fi settings menu, after trying to reconnect quickly a number of times -- these are really rapid, max 1 sec in between the retries. Bear in mind that I didn't not change the password on the AP or the phone. Now I'm gradually trying to lower the allowed bandwidth of the athn(4) devices with pf(4) to see if there's any setting where it wouldn't fail (lowered from around the default/max 1MB/s, in the 800KB/s range this still happened). > The latter is hard to say without sitting in front of your box. > Device timeouts mean the hardware failed to send one frame. > Which can happen for any number of reasons. Hm, is it worth trying to switch around e.g. antennas? Dani
