Re: Wifi network priority

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

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: (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.


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