Hi Dan -
I realized I could work around the immediate problem of setting tc qdisc's with
options on a connection by adding a script to
/etc/NetworkManager/dispatcher.d/; so answering the message below is not
urgent, though I'd use it instead of the workaround.
However, on Fedora it's a
On Fri, 2019-01-04 at 12:34 -0600, Dan Williams via networkmanager-list
wrote:
>
> Yeah.
So, that does seem to have recognized the dhcp-level:
Jan 04 13:53:07 server NetworkManager[1842]: [1546627987.3736]
ndisc[0x5571081feb00,"enp2s0"]: dhcp-level none
It did leave the previous dhclient
On Fri, 2019-01-04 at 12:00 -0500, Brian J. Murrell wrote:
> On Fri, 2019-01-04 at 09:52 -0600, Dan Williams via networkmanager-
> list
> wrote:
> > While NM was running, is it possible there was a previous RA that
> > had
> > "stateful other conf" (eg the M/managed flag) set?
>
> Possibly.
>
>
On Fri, 2019-01-04 at 09:52 -0600, Dan Williams via networkmanager-list
wrote:
>
> While NM was running, is it possible there was a previous RA that had
> "stateful other conf" (eg the M/managed flag) set?
Possibly.
> To avoid ping-pong
> with RA changes or multiple router advertisements from
On Fri, 2019-01-04 at 07:19 -0500, Brian J. Murrell wrote:
> I see the following message in the debug for NM:
>
> Jan 04 07:02:19 server NetworkManager[1138]:
> [1546603339.8846] ndisc[0x5592e10188c0,"enp2s0"]: dhcp-level
> managed
You're not mistaken about the interpretation of those fields,
I see the following message in the debug for NM:
Jan 04 07:02:19 server NetworkManager[1138]: [1546603339.8846]
ndisc[0x5592e10188c0,"enp2s0"]: dhcp-level managed
Which I presume is what leads to:
1138 ?Ssl 16:39 /usr/sbin/NetworkManager --no-daemon
26196 ?S 0:00 \_
