Re: Wifi network priority

On Sat, 2014-05-03 at 10:57 +0200, John Page wrote:
Where I live many internet providers run free access widely available
wifi routers for their clients. My own router has two access points -
my private one, and an insecure one that only allows internet access
after you have correctly identified yourself on a welcome page. I use
that when I am not at home but then at home I have to explicitly
select my home access point.

It is high time network-manager started doing something more
intelligent in those cases. I'd suggest simply preferring secure APs
to start with.

I've been reading the sources and here is what I have found.

src/devices/nm-device-wifi.c:build_hidden_probe_list is called in
order to list the APs that we might want to connect to.

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. 

You can see the list of wifi networks with
 `nmcli device wifi`

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

When you explicitly connect to a wifi network, this list is not
relevant. NM will anyway try to connect to the one you want to connect.

But the list becomes relevant, to show the "available connections for
the device" to the clients. Those connections can be especially
highlighted in the UI.

The above function calls src/settings/nm-settings.c: which reads
stored connections from storage, sorts them using
src/settings/nm-settings.c:nm_settings_sort_connections and returns
the top 5.

Whenever the list of APs in reach changes (be they hidden or not), we
This (re-)builds the list of connections that are currently applicable
on the device. In case of Wifi, this means among others the connections
with a matching SSID. It has not much to do with autoconnect -- again,
the "available connections" are for the UI.

Here are my conclusions: (they aren't criticisms, I just want to be
sure I have understood correctly.)

* network-manager doesn't ask for a list of available access points,
it just asks the supplicant to connect to one of its preferred
networks if they are available (presumably for performance).
* network-manager will never auto-connect to a stored network that
doesn't get into the top 5 - or does it check the whole list
* if several stored APs are found, the first one in the list is chosen
even if it has the weakest signal - or does the supplicant have some
say in the matter?
* the sorting code is in a wifi agnostic context so prioritizing
secure networks would (ideally) need some re-factoring. For example,
get_best_connections could return the whole list and let
build_hidden_probe_list do the sorting.

A few remarks:

- NM does not automatically disconnect. For example, if you are
connected to Insecure-Wifi, it will not disconnect and connect to
Secure-Wifi only because you came in reach of a higher priority
So, as long as you are connected, nothing happens automatically.
Disconnecting automatically would be pretty bad, because it probably
breaks your network-connections.

- when you disconnect a connection (or an error happens, such as moving
out of reach of the Wifi), NM will try to autoconnect the device again.
It does not try to autoconnect if you `nmcli device disconnect

- 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

I seem to recall there should be more related bugs, but ATM I can only
find this one:


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]