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 <[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. > > 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 _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
