Re: Altering preferred connection

[Colin Helliwell <colin helliwell ln-systems com>]

> On 03 July 2017 at 15:39 Thomas Haller <thaller redhat com> wrote:
>
> On Mon, 2017-07-03 at 14:32 +0100, Colin Helliwell wrote:
>
> Hi,
>
> > > An alternative, a bit more graceful is
> > >
> > > nmcli connection modify "$CON" ipv4.route-metric 42
> > >  nmcli device reapply "$DEV"
> >
> > These two commands are accepted, but 'route -n' doesn't indicate any
> > change to the metric?
>
> Hm, works for me.
>
> > (This might be a side/different issue, but I tried a 'nmcli conn
> > "$CON" up' in case that would help, and get "Error: Connection
> > activation failed: Network registration timed out" - might be a
> > different problem)
>
> This failure seems unrelated.

Yes, I think so too [== pink halibut]

> > > this takes the changes from the profile and applies them on the
> > > device
> > > without going through a full down/up. Not all changes are re-
> > > applyable,
> > > so, if you change something that isn't, the command will just fail
> > > and
> > > do nothing. Basically, IP settings are reapplyable.
> > >
> > > There is also
> > >
> > > nmcli device set "$DEV" setting.property value [...]
> > >
> > > for example
> > >
> > > nmcli device set "$DEV" ipv4.route-metric 42
> > >
> > > the difference is, that this change is run-time only. The
> > > connection
> > > profile.is never modified.
> >
> > This one is more like what I'm aiming at - a non-volatile change to
> > the current connection, rather than modifying it permanently.
> > However setting that property on the Device is failing:
> >
> > root@wg:~# nmcli device set ttyMux1 ipv4.route-metric 100
> > Error: property 'ipv4.route-metric' is not known.
>
> ah, it's "modify", not "set".
>
> nmcli device modify enp0s25 ipv4.route-metric 42

Ok, no error to the command now, but 'route -n' indicates no change has occurred:

root@wg6s:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.254  0.0.0.0         UG    100    0        0 eth0
0.0.0.0         10.65.106.176   0.0.0.0         UG    400    0        0 ppp0
10.65.106.176   0.0.0.0         255.255.255.255 UH    400    0        0 ppp0
192.168.10.0    0.0.0.0         255.255.255.0   U     100    0        0 eth0

and the RTD of a ping also suggests the 'preference' is un-changed.