Bug: "Phantom" RSSI Probe with inaccurate data

[seemebreakthis]

(The bold text below is the crux of the problem)

Problem: After a client device moves away from a BSSI, i.e. when "ubus call hostapd.<interface_name> get_clients" does not show the client anymore, DAWN still does "RSSI Probe" of the client, plus kicking evaluation, for a certain amount of time (approx 10 times the value in seconds set in "update_clients" from my testing) before stopping.

This normally wouldn't be a problem because even if these "phantom RSSI probes" result in the client getting kicked, nothing will happen in reality as the client is no longer there anyway.

But the problem manifests itself when the router on which DAWN is run has two (or more) BSSI's - for example one 2.4G radio, and one 5G radio - AND when a client device moves from the 2.4G radio to 5G radio of the same router, or vice versa.

When that happens, hostapd will immediately erase the client from the old radio (meaning "ubus call hostapd.<old_interface_name> get_clients" will instantly stop showing the client). But DAWN doesn't pick that up right away, causing the RSSI Probe to happen on both the new radio (with accurate RSSI info as the client is connected to it), and the old radio (where DAWN seems to probe the currently active connection (i.e. new radio) then assign the detected RSSI value to the old radio)

So the PROBE returns the RSSI value of the new radio to BOTH the old and new radio. Worst yet, evaluation is THEN done on both the old radio (irrelevant as the client is no longer there), and new radio (where evaluation is done with INACCURATE RSSI value for the old radio so the wrong score is calculated for the old radio during evaluation).

So the kicking evaluation outcome of the new radio will more often than not be wrong, as DAWN thinks the old radio has the SAME RSSI value as the new radio. This problem will continue until DAWN finally realizes the old radio no longer has the client, but by then it is usually much too late as kicking has already taken place (out of the incorrect evaluations).

I hope I am explaining myself right.

I believe the solution to this problem is to either:

1. Stop doing RSSI Probes (and subsequent kicking evaluations) of the old radio immediately, when "ubus call hostapd.<old_interface_name> get_clients" no longer shows the client
2. If it is a must to continue with RSSI Probes of the (now disconnected) old radio, at least detect the BSSID of the probe, then figure out the probed result actually comes from the new radio with a different BSSID, and don't assign the probed value to the old radio.