Allow user to change network interface prioprity

[patrickelectric]

Adds a globe icon to show that internet access is available:

The same icon can be used to control network interface priority.

So.. The problem is that network priority is done by network route and not network and that makes things more confuse to show to the user.

root@blueos:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    202    0        0 eth0
0.0.0.0         192.168.86.1    0.0.0.0         UG    304    0        0 wlan0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 usb0
192.168.86.0    0.0.0.0         255.255.255.0   U     304    0        0 wlan0
192.168.196.0   0.0.0.0         255.255.255.0   U     0      0        0 ztyxasoevg

So, a single interface can have multiple destinations with different priorities.
We could do the same thing as ifmetric and change the network priority for all routes.

root@blueos:~# ifmetric eth0 303
root@blueos:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    303    0        0 eth0
0.0.0.0         192.168.86.1    0.0.0.0         UG    304    0        0 wlan0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     303    0        0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     303    0        0 eth0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 usb0
192.168.86.0    0.0.0.0         255.255.255.0   U     304    0        0 wlan0
192.168.196.0   0.0.0.0         255.255.255.0   U     0      0        0 ztyxasoevg

Is that correct ? How should we display the order based on the original version ?

In the end I'm changing the priority of the entire interface to the highest value + 1;

Fix #1539
Fix #1057

[rafaellehmkuhl]

Does the wireless interface appear on the Ethernet menu after this change?

[patrickelectric]

Does the wireless interface appear on the Ethernet menu after this change?

No, there's a new endpoint for all interfaces now.

[joaoantoniocardoso]

Some observations:

• Sometimes "Apply" does nothing to the route metrics.
• When "Apply" works, it always changes the value of the routes (maybe not all routes), even if the order is kept the same.
• Sometimes the order of the list is changed to the inverse of what is applied: I switch wlan0 to the second, then if I open the dialogue again, it's the first.
• The colors are very confusing to me, I have to think a lot to mentally keep track of what's happening when I've switched the position of two items. I recommend not using different colors, as the meaning should be the same as the written position. I think my little brain just expects the colors to mean each interface, not each position.
• Ipv6 metrics are not following Ipv4 metrics changes.

[joaoantoniocardoso]

From the previous observations, only one is still unfixed:

• Ipv6 metrics are not following Ipv4 metrics changes.

[patrickelectric]

From the previous observations, only one is still unfixed:

• Ipv6 metrics are not following Ipv4 metrics changes.

It should be working now, isn't it ?

[joaoantoniocardoso]

From the previous observations, only one is still unfixed:

• Ipv6 metrics are not following Ipv4 metrics changes.

It should be working now, isn't it ?

nope, Ipv6 metrics are kept unchanged :(

[patrickelectric]

From the previous observations, only one is still unfixed:

• Ipv6 metrics are not following Ipv4 metrics changes.

It should be working now, isn't it ?

nope, Ipv6 metrics are kept unchanged :(

I believe that is a problem with the ifmetric and not with this implementation, since we do not support IPv6 around our code base and this already fix the main issue, it should not be a holder.

[joaoantoniocardoso]

From the previous observations, only one is still unfixed:

• Ipv6 metrics are not following Ipv4 metrics changes.

It should be working now, isn't it ?

nope, Ipv6 metrics are kept unchanged :(

I believe that is a problem with the ifmetric and not with this implementation, since we do not support IPv6 around our code base and this already fix the main issue, it should not be a holder.

I see, then just so we are aware, #1539 might not be solved for all the cases.

[joaoantoniocardoso]

Just to be clear, the metrics changes can be done using ip, ifmetric is just a helper for ipv4.

[joaoantoniocardoso]

And there's this fork, apparently with ipv6 support.