Thanks for the quick and informative reply. On 3 May 2014 12:42, Thomas Haller <[email protected]> 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?
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
