Association comeback delay behavior

[James Prestwood <prestwoj@gmail.com>]

Hi,

After noticing this log "rejected association temporarily; comeback 
duration 1000 TU (1024 ms)" I started looking more into how the kernel 
handles this and noticed a few things:

1. The kernel takes the delay in the association response frame and 
waits, but has no sane bounds for how long the wait is. An AP could send 
0xffffffff and the kernel will just block for that entire duration.

2. The first issue would appear to be guarded by the fact that 
run_again() only reschedules if the new timeout is less than the current 
time remaining but only if there is an existing timer set.

Looking at the code, the association timer gets set when we begin an 
association so it _should_ be set when we hit this comeback delay case. 
But through testing I found that it is not. Hacking hostapd to use 10000 
TU's as the comeback delay I see this:

[    4.338185] wlan1: associate with 02:00:00:00:00:00 (try 1/3)
[    4.340023] wlan1: RX AssocResp from 02:00:00:00:00:00 (capab=0x411 
status=30 aid=0)
[    4.340409] wlan1: 02:00:00:00:00:00 rejected association 
temporarily; comeback duration 10000 TU (10240 ms)
[   14.654103] wlan1: associate with 02:00:00:00:00:00 (try 2/3)
[   14.657405] wlan1: RX AssocResp from 02:00:00:00:00:00 (capab=0x411 
status=30 aid=0)
[   14.658430] wlan1: 02:00:00:00:00:00 rejected association 
temporarily; comeback duration 10000 TU (10240 ms)
[   14.848706] wlan1: associate with 02:00:00:00:00:00 (try 3/3)
[   14.851596] wlan1: RX AssocResp from 02:00:00:00:00:00 (capab=0x411 
status=30 aid=0)
[   14.854269] wlan1: 02:00:00:00:00:00 rejected association 
temporarily; comeback duration 10000 TU (10240 ms)

So the first association attempt waited the full 10 seconds, then after 
that the timer was presumably set, and we only waited the default 200ms 
(ASSOC_TIMEOUT). So to me, this feels like either a bug or an oversight 
on how this should be handled:

  - If the timer should already be set, this is a bug as I see the 
kernel waiting excessively.

  - If the timer being unset is expected, the kernel should be limiting 
this wait to something reasonable.

I also realize that CMD_ASSOC_COMEBACK was added and userspace gets 
notified, but this feels excessive to handle in userspace when the 
kernel could instead enforce a sane timeout all on its own without 
requiring userspace disconnect/reconnect when the AP sends an absurd 
timeout.

My main concern here is a rouge AP scenario that can then DoS all your 
clients that try and connect to it.

Thanks,

James