On 2/20/19 6:00 AM, Krishna Chaitanya wrote:
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?
I saw the STA disconnect for that reason after around 20 seconds in some cases,
but I would expect it to happen sooner. I didn't dig into the issue in detail
so not sure exactly what was happening on the air.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
