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 call nm_device_recheck_available_connections() 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 afterwards. * 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
Network).
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
my-iface`.
- 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.
I seem to recall there should be more related bugs, but ATM I can only
find this one:
https://bugzilla.gnome.org/show_bug.cgi?id=706496
Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part