I agree. I would love to see this too. I filed a bug to the KDE Network Manager and was told that this must be solved upstream  https://bugs.kde.org/show_bug.cgi?id=194101 here.
In addition to the priorities of connection, the priorities should also then power down the other network devices to save resources. 
For example:
If I am connected by wire, I want to be able to have the wireless module and the 3g modem automatically turned off. The other devices should come online again, when cable connection is lost.

It should be also important that NM be able to recognize which device is connected to the internet and which to the LAN automatically. For example, I use a broadband connection and I would like to continue to use internet even if my wired connection to my router (without internet) is activated.

Shall NM be able to try every profile by its priority? priority can be determined by whether it is authorized or something else.

*** This bug has been marked as a duplicate of bug 635294 ***

How's this a duplicate of 635294 when this one is older, and has more detail?

*** Bug 635294 has been marked as a duplicate of this bug. ***

Granted.

:-P

*** Bug 682954 has been marked as a duplicate of this bug. ***

*** Bug 687803 has been marked as a duplicate of this bug. ***

From a duplicate bug report:

Kim Nguyễn [reporter] 2012-11-06 20:35:14 UTC

NM uses a heuristic to determine which wireless network it should associate
with. IIRC, it keeps the list of SSID to which it has successfully associated,
sort from the most recently connected to, to the least recently connected to,
and chooses the first one.

The following happens to me. I believe this situation is quite common:

- Connecting from a public place, using a widely deployed wireless network in
my city (let's call the SSID "Freewifi")
- Suspend my laptop, go back home
- Open my laptop. Since Freewifi is also visible from my place, it will
associate to it instead of my home network.
- I have to manually change the network.

There could be some possible solution to that:
- give control to the user by allowing him to mark a connection as 'preferred'
- uses a more clever heuristic. I can think of the following ones
(1) prefer encrypted network over unencrypted ones (I think that would cover
most cases)
(2) do not sort by most recently used, but maybe most 'frequently used' or
'whose total connection time is the longest' (I'm less sure about that one).


This situation is very real and is bound to happen in every big city where
telco companies use people's DSL boxes to deploy their own city-wide wifi
network.

Although the comments speak about wireless connections which are mutually exclusive, the preference is also important when choosing the default routing interface. Whether those things should work with a single property remains a question.

*** Bug 675519 has been marked as a duplicate of this bug. ***

We would probably need something like:

1) A default cost/metric/order
2) Per-type cost/metric/order override
3) Per-connection cost/metric/order override

Source:

https://bugzilla.gnome.org/show_bug.cgi?id=723178#c16

Continuing comment 14....

I'd love to (also) be able to 
- deploy a plugin per interface that determines its costs
- deploy a 'global' plugin that determines the order of the interfaces, by plain sorting / accounting for user preference / whatever.

*** Bug 725882 has been marked as a duplicate of this bug. ***

Currently nm-device.c:nm_device_get_best_auto_connection (called when activating a device) just chooses the first viable connection in its list (ordered by most recently used). I propose that instead it should call through to a new function 

NM_DEVICE_GET_CLASS (dev)->get_best_auto_connection

It would be fairly simple to do, then per device prioritization could be easily added. I'll happily give it a go.

Then, of the ideas mentioned above, the following could be implemented in the device specific functions:

- numeric priorities - which begs the question, how do we assign the numbers? Connection ordering in the ui? if so, we need to deal with the different users.
- prefer better encryption, though where public hotspots are concerned simply preferring encryption would work, since most of them are unsecured.
- prefer the most  frequently used - though if you use both every day that won't really help.

To which I shall add:

- signal strength or at least eliminating anything considered too weak

Let's do something fairly simple to start with, a two step approach, for example:

1. eliminate connections considered too weak. I am not yet sure what logic to apply for that, but I am sure we can figure something out.
2. prefer encrypted connections.

That would cover most people's current needs (home, work, and insecure hotspots) while keeping in line with the project's goal that it should mostly just work. 

Later on the second step could be replaced by numeric priorities via ui ordering, though I suggest we keep preferring encrypted connections as a sensible default.

That is how I see things.

For the record:

downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=663730 talks about "priorities for which device gets the default route", while this BZ talks about "which connection should be selected as next for autoconnect".

*** Bug 734545 has been marked as a duplicate of this bug. ***

Pushed branch for review: th/bgo580018_autoconnect_priority

It adds a setting "autoconnect-priority" to NMSettingConnection and nmcli support for it.

The value defaults to 0, basically, higher priority values are preferred.

I would make the priority unsigned. I have pushed that and some other fixup commit on top of the branch.
Else the branch seems fine (though I did't test).

(In reply to comment #21)

+     * The lower number means higher priority.

I intended to have "higher number means higher priority" in _sort_auto_connect_fcn(). Did you got the impression I implemented it the other way round? 

-- clearly a documentation line is appropriate.

Why would it be better that lower number means higher priority?
That is the behavior for route metrics. But autoconnect-priority is quite unrelated to route priorities and in general I feel "higher number - more important" more intuitive.

Also, since we default to 0, that would mean, that all devices by default have the highest priority already. I think that is bad, the default should be either "least preferred" or "somewhere in the middle".



> I would make the priority unsigned.

what are the arguments for that?

At the moment, the gobject property range is limited to [0, 1000]. But making it as g_param_spec_int(), we could later extend it to a negative range and extend it to full gint32 range.
For now (due to the range limitation), it effectively does not matter.
But making it int now, might allow us to extend it later.

I feel that is useful because we have 0 being the default. So you could set the priority to -1 for a particular connection, so that the user can make one connection explicitly "less preferred".


Here there is not correct/wrong solution, there are just many possibilities. We could range priorities from [0,2000], 1000 being default...

My current preference is, making the valid range from [-999, 999] with 0 being default. I prefer "0" being a default value.


> Else the branch seems fine (though I did't test).

I also didn't test it ;-)

People adjusting the priority probably are familiar with route metrics, therefore the priority should mirror the behaviour of route metrics.
This avoids confusion as well as all kinds of conversion functions.

There are many ways in which a UI can represent high/low priority, even without showing actual numbers. Do not put extra complexity in back-end layers to appease the UI. Back-end software should be straight forward, it's already a complex enough area to get right.

I disagree with Ferry Huberts.

The proposed code by Thomas Haller is to prioritize connection configurations. As an example with this one could have a higher prioritized config that does 802.1x and a config with the default priority that just does auto configuration without 802.1x.
This setup would be useful for laptops (on/off a secured network) or NAP scenarios to ensure that 802.1x is preferred and if it fails the machine still tries to bring somehow the interface up.

IMHO this has nothing to do with routing. If someone would want to prioritize connections based on routing data then someone should implement policy routing for NM. This bug is certainly not about implementing policy routing and so a separate bug - if there isn't one already - should be opened.

With lower value = higher priority that doesn't change.
Only the (your) axis is inverted and you'd have to use a default value != 0.

Currently NM already uses route metric 1024 for the default gateway.
So just use 1024 as default for normal routes as well.

As I tried to indicate before, the whole networking stuff is already complex enough and will get even more complex once you start dealing with multi-homing, source based routing, multi-path TCP and whatelse. A (very) prudent course is to NOT change semantics of parameters. Only change semantics when you _really_ have to. This is not such a case.

(In reply to comment #25)
> With lower value = higher priority that doesn't change.
> Only the (your) axis is inverted and you'd have to use a default value != 0.
> 
> Currently NM already uses route metric 1024 for the default gateway.
> So just use 1024 as default for normal routes as well.
> 
> As I tried to indicate before, the whole networking stuff is already complex
> enough and will get even more complex once you start dealing with multi-homing,
> source based routing, multi-path TCP and whatelse. A (very) prudent course is
> to NOT change semantics of parameters. Only change semantics when you _really_
> have to. This is not such a case.

This has almost nothing to do with routing. Only: both things are in the realm of NetworkManager, and both have a concept of priority/preferred/unfavorable.

I meant, that route-metrics have the "lower==preferred" semantic. But we certainly *can* make the inversed semantic.

It is more a matter of taste, whether lower numbers are preferred or the opposite. http://lmgtfy.com/?q=priority%20lower%20higher .

Note that bug 735512 will add a property "ipv4.route-metric" with the metric semantic, but the name "route-metric" vs. "autoconnect-priority" already hints to a possible different semantics.



I prefer the non-route-metric semantics.


Even more important is, that:

- what is the default? I vote for 0.
- what does the default mean? Most preferred? Least preferred? Or Normal/middle priority? I vote for "middle priority".
- what is the range? I vote for [-999,999].



However we decide, the back-end implementation for this property *is* very straight forward.




Regarding UIs (except nmcli): likely they want to combine "autoconnect-priority" with "autoconnect", and just show:

  [ ] autoconnect disabled
  [ ] least preferred    <- -/+ 999
  [ ] less preferred
  [o] normal priority    <- the default (0)
  [ ] more preferred
  [ ] highest priority   <- +/- 999

but that is a different question.

Thomas, you could add an enum that defines for UIs some common priorities like "critical", "high", "normal", "low", "insignificant".

I am not sure priority labels like that make sense. For example, in
nm-applet we might want to determine priority based on the order that
networks are listed; in this case, it is the (positive) numerical
priority that matters, and there is little notion of "high" or "low"
priority.

[See also https://mail.gnome.org/archives/networkmanager-list/2014-August/msg00032.html]

Let's have the bug focused on connection priorities ~ what connection will be selected for auto-connecting.

Do not mix it with route metrics - that is bug 735512.
Do not discuss UI here too - a new bug can be created later (after this lands).

(In reply to comment #26)
> (In reply to comment #25)
> Even more important is, that:
> 
> - what is the default? I vote for 0.
> - what does the default mean? Most preferred? Least preferred? Or Normal/middle
> priority? I vote for "middle priority".
> - what is the range? I vote for [-999,999].
>

I agree that the default value should be in the middle. Thus, it is easy to explicitly add a new more or less preferred connection. However, I prefer having an uint range ([0 - 1000] or other maximum). It seems to me more straightforward having priorities like e.g. 500, 700, 23 than 0 200 -876. I don't have a strong preference whether low number should mean lower or higher priority, though.

It seems like most places where this is used will be either:

  - a single connection is preferred to all others
  - one or more connections are dispreferred to all others (but are
    equal to each other)

And sometimes both at once. I really think -1 to 1 would be enough range. -999 to 999 seems like way more precision than anyone is going to need.

At any rate, I like 0 as the default, and low=bad, high=good

(In reply to comment #30)
> It seems like most places where this is used will be either:
> 
>   - a single connection is preferred to all others

"Always try Red Hat first, even if there is a Starbucks downstairs and I often connect to Starbucks elsewhere", which is the canonical Red Hat Mountain View office case that kinda started all of this a couple years ago.

>   - one or more connections are dispreferred to all others (but are
>     equal to each other)

"Only try Minneapolis WiFi if nothing else is available", because here its literally everywhere (municipal WiFi) but it's often pretty crappy speed and the WiFi at coffee shop or the friend's house is guaranteed to be faster.

But you're only listing of the within-device use-cases here, and I think there's one other large use-case too: device class priority.  We currently hardcode that via nm_device_get_priority() and it's well established that this isn't great.  But numeric priority, if it's global across devices, could solve this too; more complex rules like "default to XFinity WiFi if available, but keep WWAN as an active backup".

> And sometimes both at once. I really think -1 to 1 would be enough range. -999
> to 999 seems like way more precision than anyone is going to need.

I think a range of 3 total values would limiting for the device class priority.  I think there's some neat tricks you could do with a larger range of values, especially related to fallback.  For example, say you have WWAN, WiFi, WiMAX, and ADSL.  You'd like to order them in a specific way, regardless of how we currently order them in NM.  With a larger range of values, you can order these connections for whatever fallback policy you have (based on speed, or price, or latency, or whatever).  I believe there are real-world cases for that kind of thing, but having only 3 values doesn't really cover it.

That said, I don't think micro-managing connections with 1999 possible values (-999 to 999) is really that useful either, but I think there's a good argument for at least 199 or 599 values based on the above, if you accept it.  Ideally, UIs should be hiding the implementation entirely, and leaving you with an ordered list or something, which might mean they have to dynamically adjust the values of all connections based on how you drag/reorder stuff (as a possibly implementation).

> At any rate, I like 0 as the default, and low=bad, high=good

Yeah, that's a good way to classify it.

(In reply to comment #31)
> (In reply to comment #30)
> > It seems like most places where this is used will be either:

Right. *most* cases probably amount to > 99%. But lets not artificially restrict the 0.X% cases for no strong reason.


> But you're only listing of the within-device use-cases here, and I think
> there's one other large use-case too: device class priority.  We currently
> hardcode that via nm_device_get_priority() and it's well established that this
> isn't great.  But numeric priority, if it's global across devices, could solve
> this too; more complex rules like "default to XFinity WiFi if available, but
> keep WWAN as an active backup".

I think the out-of-device use-cases are very uncommon. Auto-connect only matters when a device becomes ready. Usually, a WiFi connection does not apply on a WWAN device and vice versa.

In context of https://mail.gnome.org/archives/networkmanager-list/2014-September/msg00039.html, the issue there is more who gets the default route and about route metrics (bug 735512).

But again: from "very uncommon" it does not follow that we should limit such uses.


> > And sometimes both at once. I really think -1 to 1 would be enough range. -999
> > to 999 seems like way more precision than anyone is going to need.
> 
> I think a range of 3 total values would limiting for the device class priority.
>  I think there's some neat tricks you could do with a larger range of values,
> especially related to fallback.  For example, say you have WWAN, WiFi, WiMAX,
> and ADSL.  You'd like to order them in a specific way, regardless of how we
> currently order them in NM.  With a larger range of values, you can order these
> connections for whatever fallback policy you have (based on speed, or price, or
> latency, or whatever).  I believe there are real-world cases for that kind of
> thing, but having only 3 values doesn't really cover it.
>
> That said, I don't think micro-managing connections with 1999 possible values
> (-999 to 999) is really that useful either, but I think there's a good argument
> for at least 199 or 599 values based on the above, if you accept it.  Ideally,
> UIs should be hiding the implementation entirely, and leaving you with an
> ordered list or something, which might mean they have to dynamically adjust the
> values of all connections based on how you drag/reorder stuff (as a possibly
> implementation).

Having an (excessively!) large range helps managing the priorities.

It's just numbers. It does not mean we need an actual use case where somebody really wants to assign hundreds of different priorities. It's useful because the user can assign the priorities and there is still a large gap to the next assigned one.

IMO [-99,99] is large, but not excessive enough.
[-299,299] seems a very odd limit.

I prefer [-999,999], because ordinary people think in decimal and 1000 seems like a natural border to me. I'd also be fine with [-1000,1000].



> > At any rate, I like 0 as the default, and low=bad, high=good
> 
> Yeah, that's a good way to classify it.

Ok, so there seems to be some consensus: default==0 and negative-numbers==less-preferred.

I agree that -1 to 1 is too limited. 0 as default sounds very reasonable to me. Also negative numbers being less preferred sounds very reasonable to me.

I don't care about the actual number range. I only wonder why it needs to be arbitrarily limited instead of just selecting a type (gint8 or gint16) and using the full number range.

And I insist:

the most sensible thing would be checking for the BEST signal available (a single line of iwlist/grep/awk will do it, so networkmanager CAN do this) and connect automagically to the BEST signal. 

the actual nm behaviour about connecting is very stupid.

asbesto: that may be true in your scenarios, but it is not always true. eg, dcbw's first example in comment 31 (which is an actual real-life problem).

(In reply to comment #31)
> But you're only listing of the within-device use-cases here, and I think
> there's one other large use-case too: device class priority.

I was thinking that that was more covered by the routing priority bug...

> We currently
> hardcode that via nm_device_get_priority() and it's well established that this
> isn't great.  But numeric priority, if it's global across devices, could solve
> this too; more complex rules like "default to XFinity WiFi if available, but
> keep WWAN as an active backup".

At that point maybe we should just have /etc/NetworkManager/dispatcher.d/pre-connect.d/, which contains scripts that NM passes a list of activatable connections to, and the script decides which one to try to activate next.

> Ideally,
> UIs should be hiding the implementation entirely, and leaving you with an
> ordered list or something, which might mean they have to dynamically adjust the
> values of all connections based on how you drag/reorder stuff (as a possibly
> implementation).

Yes, if we're going to have more than just high/low/medium, this is probably how we'd have to show it. (I guess we could just change the connection list to be sorted first by priority and second by timestamp. Though that only works for the within-device-types case.)

(In reply to comment #34)
> And I insist:
> 
> the most sensible thing would be checking for the BEST signal available (a
> single line of iwlist/grep/awk will do it, so networkmanager CAN do this) and
> connect automagically to the BEST signal. 
> 
> the actual nm behaviour about connecting is very stupid.

The new autoconnect-priority gives the user a way to overwrite the automatism. So, the new property is a good idea anyway -- regardless of how NM chooses automatically.

autoconnect-priority partitions the connections into groups of same priority. Within each group, the automatism however still hits.

You request a different kind of automatism, and the autoconnect-priority will not give you that.


The current automatism is to connect to the connection that was connected last. That seems a reasonable auto-behaviour for *most* use cases. I like the simplicity and predictability of it.

Note, in *most* cases, different connections/SSIDs really are "different networks". You don't want to connect to one or the other network based on arbitrary measures. The signal strength is arbitrary, depending in which corner you are hiding. "last-connect-time" is not arbitrary. You recently showed interest in that connection, hence it is a good guess for NM to prefer it.


The only use case I see for signal strength is when you have two WiFis (different SSID), that are actually bridged to the same LAN. Actually, I have that at home because I could not convince my WRT-router to play WiFi repeater with the same SSID. But it wouldn't help that much, because I still cannot roam between my WiFis.
More importantly, I don't see how to reconcile that with the predominant case of preferring most recently used. 

What is your use case?

Repushed branch th/bgo580018_autoconnect_priority

It seem to me *natural* that, lacking any other kind of priority setting, I want to connect to the BEST signal instead of the worst one (and so I dont care about corners etc: I want the best signal, because instead, my connection simply doesnt work). 

If I set other priorities, ok, nm can follow them - but If i'm in an area with 3 known hotspot I usually use, well, I want the best one, for a stable and fast wifi connection.


Is like beer. I don't want the same brand of yesterday, I want the COOLEST beer in my fridge. What's so weird about this? :)

(PS I'm here because I requested this simple and natural feature, and I was redirected here - so here people is talking about something totally different - priorities - instead of that simple, natural choice.)

(In reply to comment #39)
> It seem to me *natural* that, lacking any other kind of priority setting, I
> want to connect to the BEST signal instead of the worst one (and so I dont care
> about corners etc: I want the best signal, because instead, my connection
> simply doesnt work). 
> 
> If I set other priorities, ok, nm can follow them - but If i'm in an area with
> 3 known hotspot I usually use, well, I want the best one, for a stable and fast
> wifi connection.
> 
> 
> Is like beer. I don't want the same brand of yesterday, I want the COOLEST beer
> in my fridge. What's so weird about this? :)

I can tell you from experience that BEST isn't always what you expect.
Try imagining multiple wlan interfaces, multiple ethernets, some 3g/4g and some vpn tunnels all being active. Now which one is the best?

Or 2 wlan ap's with the ssid that interchangidly have the best connection specs. Now which one is the best?

That is a question that is actually very hard to answer, especially in the presence of tunnels.
Mainly this is because picking a different interface just breaks existing connections... None (that includes you) will be happy that his vpn tunnel break just because you insisted that you always want the best connection.

In olsrd I've implemented the 'multi-smart-gateway' mechanism is there we try very hard not to break connections until it is actually needed.

The only real solution that allows you to pick a different best interface without breaking connections is multi-path tcp. But we're a long way removed from that to become a viable solution.

Yeah but I was talking only about WIFI, not 3g or whatever :D it's so simple! :D

Yeah but I was talking only about WIFI, not 3g or whatever :D it's so simple! :D
No multiple vlan, no ethernet - WIFI! :)

I opened bug 737356 this is more specific for selecting based on WiFi signal strength.

Lets use this bug, to implement autoconnect-priority (which is a great idea anyway) and move this discussion over there.

You need to make ifcfg-rh save and restore autoconnect-priority.


> libnm: add _nm_utils_slist_to_ptr_array()

This is very very similar to the already-existing _nm_utils_copy_slist_to_array(). Just change your code to do

    connections = _nm_utils_copy_slist_to_array (connection_list, g_object_ref, g_object_unref);

The returned objects will have been reffed, but they'll be unreffed when you free the array, so you don't need any memory-management changes.


> core: ensure properly comparing boolean values in connection_sort()

>+	can_ac = !!nm_setting_connection_get_autoconnect (con_a);
>+	if (can_ac != (!!nm_setting_connection_get_autoconnect (con_b))) {

it's weird to store one in a variable and the other not...


> core: prefer connections with higher priority for autoconnect

>+# ensure, that the sort function _sort_auto_connect_fcn we are testing is identical to the
>+# one in nm-policy.c

It seems like it would be simpler (both now and in the future) to just move the function to NetworkManagerUtils.c...

(In reply to comment #45)
> You need to make ifcfg-rh save and restore autoconnect-priority.

Added commits:
>> ifcfg-rh: add support for NM_SETTING_CONNECTION_AUTOCONNECT_PRIORITY
>> ifcfg-rh: add svGetValueInt64() utility function


> > libnm: add _nm_utils_slist_to_ptr_array()
> 
> This is very very similar to the already-existing
> _nm_utils_copy_slist_to_array(). Just change your code to do
> 
>     connections = _nm_utils_copy_slist_to_array (connection_list, g_object_ref,
> g_object_unref);
> 
> The returned objects will have been reffed, but they'll be unreffed when you
> free the array, so you don't need any memory-management changes.

Oh right. These functions weren't there when I wrote that patch.
I added patch:

>> libnm: make @copy_func argument in _nm_utils_copy_strdict() optional



> > core: ensure properly comparing boolean values in connection_sort()
> 
> >+	can_ac = !!nm_setting_connection_get_autoconnect (con_a);
> >+	if (can_ac != (!!nm_setting_connection_get_autoconnect (con_b))) {
> 
> it's weird to store one in a variable and the other not...

done.


> > core: prefer connections with higher priority for autoconnect
> 
> >+# ensure, that the sort function _sort_auto_connect_fcn we are testing is identical to the
> >+# one in nm-policy.c
> 
> It seems like it would be simpler (both now and in the future) to just move the
> function to NetworkManagerUtils.c...

done.



Rebased to master.

> core: ensure properly comparing boolean values in connection_sort()

+	if (can_ac_a != can_ac_b) {
+		if (can_ac_a)
 			return -1;
 		return 1;
 	}

I would write:

    return can_ac_a ? -1 : 1;

> core: prefer connections with higher priority for autoconnect

Same here:

+	if (a_ap != b_ap) {
+		if (a_ap > b_ap)
+			return -1;
+		return 1;
+	}

return a_ap > b_ap ? -1 : 1;

But that's it, everything else looks good to me.

Merged to master as http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a7c8e5c6e9aad100b782f0be62916e8d99399aca


User now have a way to (always) prefer a connection over another for autoconnect.



Note: this does not change the behaviour how NM chooses a connection when several candidates have the same priority. In that case, NM will still choose least-recently-connected.

For the RFE to improve on the automatism see bug 737356 (for example to choose a candidate based on the strength of the Wi-Fi signal).

Just reading the comments.  The way Microsoft does it, when you are wired, you are wired....unless you choose to use a wifi.

The gui should apply a list which you can bump up or down.  The order of the list is the order in which the NM should look for the connections, maybe after sniffing a list from the air to make things more efficient.

My situation is at least 2 available wifi connections where I am most of my time.  In some areas, I have 3 which could possibly be used.  If my first isn't in the sniffed list, I should connect to the next in line

Is this bug really fixed? I can't see how to choose autoconnect-priority from command line, gui or tui.

nmcli connection modify $NAME connection.autoconnect-priority 5

What is the range of the prio?
And I assume 1 is highest prio?

`man nm-settings` says:

  The autoconnect priority. If the
  connection is set to autoconnect,
  connections with higher priority will be
  preferred. Defaults to 0. The higher
  number means higher priority.

the range is from -999 to +999, with 0 being the default.
The higher (the more positive) the value, the more it will be preferred.


Try:

$ nmcli connection modify $NAME connection.autoconnect-priority 1000
Error: failed to modify connection.autoconnect-priority: '1000' is not valid; use <-999-999>.

thanks!

(a bit too narrow for my usecase however, and a power-of-2 range would have been much more useful as well)

Great thanks! I'll add a feature request to add autoconnect-priority to nm-connection-editor.