On 23 February 2015 at 13:53, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen <j@xxxxx> wrote: >> >> How far is the station from the AP? Would it be possible to see whether >> the behavior changes if you were within, say, five meters or so? > > Well, it was pretty much within five meters already, but there was a > thin wall in between (and the old AP was right next to the laptop, > which might add some noise even if they are on different channels). > Going closer does seem to help, but again, it's not like this is 100% > reproducible to begin with. > > So the theory that the driver starts at too high a transmit rate, and > then does not handle failures well, might be true. Of course, "not > handle failures well" is something of an understatement. > >> It would be useful if you can capture the 802.11 frame exchange from a >> failed connection case with an external wireless sniffer. > > I will try with my (much more reliable) iwlwifi laptop. At least the > merge window is over, so I should have some time. Knock wood. Hm, can we just hack mac80211/ath9k to set /all/ EAPOL frames to the lowest negotiated basic rate and test? That way we don't have to worry about things resetting fixed rates or whatnot. I've done that with FreeBSD's atheros/intel drivers and net80211 stack to fix exactly these, although I'm thinking about adding a patch based on Jouni's note about EAPOL encrypting the final response. Does ath9k have an easy interface for dumping out the TX descriptors and response? That way we can see (a) what it's transmitting as, and (b) whether the hardware indicated it got an ACK for the particular frame. -adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
