Patch to split roaming out of wpa_supplicant

[Blaise Gassend]

Hi Holger,

Thanks for the feedback. I agree that splitting into the three patches
you describe makes sense.

The key question remains, however. Would the hooks that allow people
writing their own roaming code to be notified of events that concern
roaming be considered for inclusion, or is there no interest? If the
answer is yes then I am willing to work to get a patch that people
find acceptable. But if a priori the answer is no, then there is no
point in my wasting time getting the patch into presentable form. How
is such a decision made? I assume that Jouni Malinen has the main say.

> You could divide your patch into several patches, each doing one (and only
> one) thing. One patch for your libraryzation.

Agreed, the libraryzation does indeed stand alone.

> Probably no one else needs that.
> Then maybe several patches that single out all the roaming code, e.g. by
> centralizing it to one file.

I see moving all the roaming related code to a single file as a pretty
large endeavor that I wouldn't feel comfortable undertaking. To
disable the roaming code, I am mostly disabling all the mechanisms
that kick of a scan, as all the other actions that wpa_supplicant
takes follow from receiving the scan results. This approach is much
less intrusive.

>                           Then a patch that allows to completely disable
> roaming, either as config variable or as CONFIG define.
>
> I personally would like such an option, and use it well.

I don't see that this patch would be useful at all without the hooks,
as when I say roaming, I am talking pretty widely. When the roaming is
off, wpa_supplicant will not do anything on its own, including initial
association. Anybody who wants to get wpa_supplicant doing something
is going to need the hooks.

That being said, the two patches are easy to decouple, so I agree that
I might as well do it.

> Are this hooks just an interface from the librarified wpa_supplicant into your
> main program, which now uses wpa_supplicant? ? Or vica versa? ?Whatever it is,
> this should also be one patch, and is probably the one that has the least
> chance of getting in, because it's not entirely clear how this patch would be
> a win for wpa_supplicant as-is.

These hooks are calls from wpa_supplicant to an external roaming code.
They allow somebody who wants to write their own roaming code to be
notified of events in wpa_supplicant. They are used by wpa_supplicant
to notify the roaming code that an important event has happened.

I do not think that this code would be useful for wpa_supplicant, the
monolithic app that does both roaming and configuring of the radio.
However, this code would help anybody who wants to use wpa_supplicant
to configure the radio without being tied to wpa_supplicant's roaming
strategy.

There are already similar hooks for the dbus API, but they don't do
everything that is needed for an agressive roaming strategy. For
instance, it looks like dbus is notified when a scan succeeds, but not
when a scan fails. If you are writing an aggressive roaming strategy,
you need to be able to trigger a scan on a few frequencies and know
immediately if it fails so that you can potentially try some more
frequencies. (Trying all frequencies at once might not be a good idea
if you know that some frequencies aren't in use and don't want to wait
5 seconds.) As another example, there are currently many places where
association fails but is never reported over dbus.

Blaise