eval_<type>_req and MacOS behaviour (and other OS), improvement and bugfixes

[imwhocodes]

Hi

I'm managing a small business network, the setup is 3 AP with around 20/30 STA connected, STAs is a mix of Windows and MacOS computers and IPhone and Androids phone
Each AP has its own channels that are not overlapping with each other

I started using DAWN mostly to address the fact that MacOS are very sticky to the AP they are connected with and don't even try to roam until the connection is literally unusable

My plan was to use the eval_probe_req, eval_auth_req, eval_assoc_req to steer them during the connection phase but with no success

I start digging by reading logs and source code and experimenting so I come up with some insight and proposal to increase DAWN performance/behaviour

I noticed that on modern system steering by eval_probe_req is impossible because they do the PROBE REQUEST with a random MAC Address for privacy implications and then only during the AUTH and ASSOC phases they use their real MAC

Interesting fact is that theoretically all this ASSOC request should be refused (given the fact that the probe counter is empty/null) but thanks to this bug they passed right through

What I'm proposing is to store locally and share via network with the other DAWN AP the AUTH and ASSOC request as is done for the PROBE request (all together treated equally)

The basic idea is given this conf:

eval_probe_req = 0
eval_auth_req = 0
eval_assoc_req = 1
min_probe_count = 3 //keeping name but now this count all 3 type of request frames

To have a flow like this:
(where probe_counter is referring to frame with the real MAC address usable for actual device tracking )

1. WI-FI on STA is turned ON
2. STA do PROBE request with random MAC to AP-1
3. PROBE is accepted by AP-1 (probe_counter = 0 because random mac was used)
4. STA do AUTH with real MAC to AP-1
5. AUTH is accepted by AP-1 (probe_counter = 1)
6. STA do ASSOC with real MAC to AP-1
7. ASSOC is refused by AP-1 with AP_UNABLE_TO_HANDLE_NEW_STA because low probe count (probe_counter = 2)
8. STA do PROBE request with random MAC to AP-2 (hopefully STA is searching on a different WIFI channel)
9. PROBE is accepted by AP-2 (probe_counter = 2 because random mac was used)
10. STA do AUTH with real MAC to AP-2
11. AUTH is accepted by AP-2 (probe_counter = 3)
12. STA do ASSOC with real MAC to AP-2
13. based on score ASSOC is either accepted or refused by AP-2, on the refused case we go back to point 8 hopefully with STA finding a new AP-3 (on a different WIFI channel) during the probe phase (probe_counter = 4), if STA go back to trying AP-1 it will be accepted from that AP

What do you think about it?
From the source code it seem to me it should be implementable using all existing pieces

Hoping this project keep improving and go forward,
Thanks for your time,
Luca

[PolynomialDivision]

Thanks for reporting and your suggestions. This is on to-do list.