On 11/13/18 4:13 PM, Thomas Haller wrote:
Maybe. But the moment when you issue
$ nmcli connection down "$PROFILE"
the "$PROFILE" is in the process of deactivating. It's not yet fully
deactivated. Hence, it is "the profile which is currently
deactivating".
Seems correct to me as-is, but
On Tue, 2018-11-13 at 14:03 +0100, Thomas HUMMEL wrote:
> On 11/13/18 1:56 PM, Thomas Haller wrote:
>
>
> > I think this is just a documentation bug.
> >
> > Fixed:
> > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17f9801e07df0c544e0416c65cedc28727476e55
> >
> >
On 11/13/18 1:56 PM, Thomas Haller wrote:
I think this is just a documentation bug.
Fixed:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17f9801e07df0c544e0416c65cedc28727476e55
Thanks for actually reading the documentation and pointing out confusing/wrong
parts!!
On Thu, 2018-11-08 at 16:30 +0100, Thomas HUMMEL wrote:
> Hello,
>
> nmcli(1) states about the connection down command :
>
> "Be aware that this command deactivates the specified active
> connection,
> but the device on which the connection was active, is still ready to
> connect and will
On Mon, 2018-11-05 at 20:25 +0200, Kemal Kilic via networkmanager-list
wrote:
> Hello Folks,
>
> I have 64 bit openSUSE Tumbleweed.
> Just a week ago my shared wifi and ethernet connections were working
> with NetworkManager
>
> I do not know what happened but now I got such messages and the
>
On Mon, 2018-11-12 at 11:37 +0100, Thomas HUMMEL wrote:
Hi,
>
> [I'm talking only about ipv4.method=manual wired ethernet connections
> here]
>
> As far as I experience, the 'search' line in the NetworkManager
> resolv.conf file comes from the union of all the ipv4.dns-search
> properties of
