Re: Wifi network priority

[John Page <jpeg729 gmail com>]

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.

 

- 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).

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?