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.
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).
Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part