Re: Wifi network priority

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
        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
        -- 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
        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
            interface-name, BSSID, SSID, MAC address, etc.
          - connection is not "blocked" for the device (because of
            failures to connect or because you just got disconnected
            `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
        connection. The least-recently-policy sounds like a good idea

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

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

2. checks for blacklisted connections via

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 
  - 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
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: (now I found it).


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]