Re: NetworkManager behavior answers not found in docs

[Thomas Haller <thaller redhat com>]

On Tue, 2018-10-23 at 15:25 +0200, Thomas HUMMEL wrote:
> On 10/18/2018 11:30 PM, Thomas Haller wrote:
> > The profile has a "connection.autoconnect" property. If it's "no",
> > the
> > profile never autoconnects. Period.
> >
> > But there also needs to be a device which is currently in a state
> > where
> > it would like to autoconnect a profile. With `nmcli device set
> > "$DEVICE" autoconnect no" you can set that.
> >
> > for example, `nmcli device disconnect "$DEVICE"` will block
> > autoconnect
> > on the device. It would be pretty annoying, if you disconnect the
> > device and immediatley some profile autoconnects again.
> >
> >
> >
> > > > "Autoconnect" prefers profiles which
> > > > were active last
> > >
> > > Same remark here
> >
> > When a device wants to autoconnect a profile, there might be
> > multiple
> > profiles which are compatible candidtes. Then, the one is chosen
> > with
> > the best "connection.autoconnect-priority" or as last, the
> > timestamp
> > when the profile was activate the last time.
>
> So, would that be correct to think about it this way :
>
> it is a device which, by defaults, "wants" to autoconnect and try to 
> find a profile with connection.autoconnect property set to yes ?
>
> and device disconnect or device set <device> autoconnect no inhibit
> this 
> behavior ?
>
> I mean as opposed to a profile which would "want" to auto "connect"
> to a 
> device ?

Yes, kind of.

Both the device and the profile must be willing to autoconnect for it
to happen. It's both ways. That's why you can suppress autoconnect on
both sides. And in various situations, autoconnect will also be
internally blocked. For example for the device (after `nmcli device
disconnect`) and or the profile (e.g. no secrets provided)).



best,
Thomas

Attachment: signature.asc
Description: This is a digitally signed message part