On Wed, Feb 20, 2019 at 7:00 PM Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > > > > On 02/19/2019 11:55 PM, Johannes Berg wrote: > > On Tue, 2019-02-19 at 14:41 -0800, Ben Greear wrote: > > > >> If I then quickly restart the AP configured for /n mode, I would expect that the STA would > >> then connect with HT enabled. However, what I notice is that it stays at /a rates. Probably > >> this is because it did not rescan. Here is an iw event log of this: > > > > [snip] > > > >> So, is it OK that the station did not re-scan the AP and/or automatically refresh its beacon > >> info with the new capabilities? > > > > I'd argue that's a case of "don't do that, then" :-) > > > > How often would we expect that to happen in the real world? The spec > > sort of assumes that capabilities etc. are static, so changing them > > within a few hundred milliseconds or so is not something that would be > > expected. > > > > Just give it a new BSSID when you do this? > > Hmm, new BSSID is interesting, and might work for me. I also found that keeping > the AP down for 10 seconds appears to cause the station enough trouble that it will > do a full rescan to reconnect. > > Another issue I found is that a quick bounce of the AP is often not noticed at all > by the station for a long time. Probably because it is not sending (directed?) packets > and I guess the AP would still return ACKs for null-data probes even if STA is not > associated from AP's perspective. Even if it sends ACK, it should still send deauth with reason code 7 (class3 received in not connected state), no? _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
