Re: Wifi network priority

[Dan Williams <dcbw redhat com>]

On Mon, 2014-05-05 at 12:55 +0200, Thomas Haller wrote:
> On Sun, 2014-05-04 at 15:42 +0200, John Page wrote:
> > Thanks for the quick and informative reply.
> >
> > On 3 May 2014 12:42, Thomas Haller <thaller redhat com> wrote:
> >         build_hidden_probe_list (together with get_best_connection) is
> >         called to
> >         find additional hidden APs, by looking at the SSIDs of our
> >         connections
> >         and explicitly scanning for those.
> >         
> >         It is only relevant, if you have an hidden AP, so that it
> >         shows up as an
> >         available Wifi network in the scan list.
> >
> >
> > That does make more sense, but I hadn't found the code that looks
> > through the list and decides which one to connect to.
> >
> >
> >         NM includes there all Networks it sees (including the hidden
> >         ones that
> >         it can find after scanning build_hidden_probe_list. No top-5
> >         restriction
> >         -- where did you see that?).
> >
> >
> > settings/nm-settings.c:get_best_connections line 1719 takes a
> > max_requested parameter which it uses to shorten the list, I don't
> > think I have misunderstood its purpose. build_hidden_probe_list gets
> > it from nm_supplicant_interface_get_max_scan_ssids and passes it to
> > get_best_connections. I think that means that you can only usefully
> > store 5 hidden APs, which is probably plenty for most people.
>
> Ah right. This is only relevant if you have hidden APs. Maybe this is
> not optimal, but the source comment indicate it's for performance
> reasons... Anyway, it's a different issue (if at all).
>
>
>
> >         - When it tries to autoconnect, it will search for a suitable,
> >         connection. This is not strictly the same as the "available
> >         connections"
> >         above, but similar.
> >         Currently that means: find connections that:
> >           - are autoconnect=yes
> >           - are not yet connected on an other interface
> >           - matches the device. E.g. if specified, it requires
> >         matching
> >             interface-name, BSSID, SSID, MAC address, etc.
> >           - connection is not "blocked" for the device (because of
> >         recent
> >             failures to connect or because you just got disconnected
> >         with
> >             `nmcli con down`).
> >         
> >         If more then one connection match, it will reconnect to the
> >         least-recently-connected (according to the timestamp).
> >
> >
> >         So yes, it's conceivable to have more policies when selecting
> >         the
> >         connection. The least-recently-policy sounds like a good idea
> >         in
> >         general.
> >
> >
> > Did you mean most recent? For short/random disconnections it is indeed
> > best to reconnect to the same AP (does that happen much?), but after a
> > longer period of disconnection it makes more sense to reconsider the
> > options (especially if the computer has been put into suspend mode
> > since - in which case it may well be a laptop that is being carried
> > around).
>
> Yes. I meant *most* recent :)
> > After a little more reading I think I know what needs to be done. Here
> > is a summary of the auto-activation procedure
> > in nm-policy.c:auto_activate_device:
> >
> >
> > 1. loads a sorted list of connections from settings via a call to
> > nm-manager.c:nm_manager_get_activatable_connections which filters out
> > the already active connections from the list given by
> > nm-settings.c:nm_settings_get_connections,
> >
> >
> > 2. checks for blacklisted connections via
> > settings/nm-settings-connection.c:nm_settings_connection_can_autoconnect,
> >
> >
> > 3. chooses the best connection
> > via nm-device.c:nm_device_get_best_auto_connection which just returns
> > the first viable connection on the list. Viability is checked
> > using NM_DEVICE_GET_CLASS (dev)->can_auto_connect.
> >
> >
> > I think nm-device.c:nm_device_get_best_auto_connection really ought to
> > just pass the call through to NM_DEVICE_GET_CLASS
> > (dev)->get_best_auto_connection so that device specific criteria can
> > be taken into account when choosing the connection.
> >
> >
> > Does that sound reasonable?
>
> 1. and 2. are uncontroversial. First filter for connections that are
> candidates for autoconnect and are currently not active nor blocked. Ok.
>
>
> The question is, which connection to choose if you have more then one
> left. You said:
>   - most-recent is reasonable, but only for a short period (how 
>     short?)
>   - prefer secured Wifi over non-secure
> I think, first this needs more details.
>
>
> Btw, I don't agree with these two rules. I think, that each connection
> should get a "connection.priority" attribute. Which is just a number to
> prefer the connection with the higher priority.
> If the priority of two connections is equal, choose the most recently
> used.
> This gives the user a way to configure priorities.

It's a bit more complicated than this for WiFi actually, because not
every network is found in every scan, due to the way WiFi works.  So
even if your SSID-X was higher priority than your SSID-Y, if the WiFi
card didn't find SSID-Y in the scan, NetworkManager would still only be
able to connect automatically to SSID-X because that's the only network
it would see.  And since NM doesn't disconnect for higher-priority
networks at this time, you'd have to manually choose the new network.
That is something we can change, possibly like how Windows has a
"Disconnect if a higher priority network is available" checkbox in each
wifi network config dialog.

> Anyway, I think it would be better to move the discussion to the
> bugzilla for this issue to collect the ideas there:
>   https://bugzilla.gnome.org/show_bug.cgi?id=580018 (now I found it).

Yes, that would be best.  It's clear that we need better priority
schemes.  But also keep in mind that we have identified a need for
"cross-device" priorities too, so that, for example, if you are
connected to WWAN and a known wifi network comes in range, WWAN gets
disconnected and put in low-power mode.  Or, if you plug in an ethernet
cable, the WiFi is disconnected and put into low-power mode.

So it's not just about WiFi networks, we need to think about the larger
picture and see if we can implement a single, simple solution for both
types of priority.  Maybe that's not possible, but we should try.

Dan