On 10/25/2018 03:47 PM, Thomas Haller wrote:
For example,
nmcli connection up "$PROFILE" ifname "$DEVICE"
nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24
nmcli device reapply "$DEVICE"
is basically the same as:
nmcli connection up "$PROFILE" ifname "$DEVICE"
On 10/25/2018 03:47 PM, Thomas Haller wrote:
Remember, that a modification of the profile (`nmcli connection
modify`) does not take effect immeiately (except "connection.zone" and
"connection.metered" properties). You usually need to do a full re-
activation for the changes to take effect (`nmcli
Generally, there are the device states "unmanaged" -> "unavailable" ->
and "disconnected". For ethernet devices, a device is usually
"unavailable" because it has no carrier.
As a matter of fact, when no udev rules for NM_UNMANAGED, the device is
in the disconnected state.
As for the traces
On Fri, 2018-10-26 at 12:01 +0200, Thomas HUMMEL wrote:
> On 10/26/2018 10:05 AM, Thomas Haller wrote:
>
>
> > Ah, there is also `nmcli -f GENERAL.NM-MANAGED device show eth0 `,
> > but
> > this just returns (state != "unmanaged").
>
> Wait : what's the diffence (if any) between GENERAL.NM-MANA
On 10/26/2018 10:05 AM, Thomas Haller wrote:
The return value of the nmcli command is odd, maybe a bug.
In any event, it may be confusing for the user or a script indeed which
then could legitimely think the managed request succeeded.
It returns success, because it successfully flagged the
Hi,
On Thu, 2018-10-25 at 20:35 +0200, Thomas HUMMEL wrote:
> On 10/18/2018 11:30 PM, Thomas Haller wrote:
> > Btw, note that if you configure the device as unmanaged via
> > NM_CONTROLLED=no in ifcfg, then the device cannot be set to
> > managed.
> > This way of unmanaging a device is definite,
