On Mon, 2019-06-24 at 08:52 +0200, Beniamino Galvani via
networkmanager-list wrote:
>
> Hi,
Hi Beniamino,
> I checked again the log you sent and I see the problem now. When NM
> receives a RA, it checks whether the parameters
Which parameters exactly? Because I might be able to shed some light
On Fri, 2019-06-21 at 17:58 +0200, Beniamino Galvani via
networkmanager-list wrote:
>
> Sounds ok.
Thanks.
> Which kernel version do you have on the EL 7.6 machine?
3.10.0-957.21.2.el7.x86_64
Cheers,
b.
signature.asc
Description: This is a digitally signed message part
__
On Fri, 2019-05-24 at 13:16 +0200, Till Maas via networkmanager-list
wrote:
> Hi Brian,
Hi.
> You can try if it is fixed in a never version. You can find builds
> from latest GIT branches for EL 7 here:
>
> https://copr.fedorainfracloud.org/coprs/networkmanager/
No, the NetworkManager-1.16.3-1
On Mon, 2019-06-03 at 14:17 -0400, Brian J. Murrell wrote:
>
> I think I had it set to DEBUG. Let me see if I can reproduce with it
> set to TRACE.
I have to correct myself. It was set to TRACE.
> It goes up quite a bit. More indication that it is NM.
CPU is pegged between NM,
On Sun, 2019-06-02 at 10:29 +0200, Thomas Haller via networkmanager-
list wrote:
>
> Thanks, that's of course a string indication that NetworkManager is
> the
> culprit.
Seems so to me. As well as (see answer to your other question
below)...
> Just to check, did you enable level=TRACE
I think
On Thu, 2019-05-30 at 12:23 +0200, Thomas Haller via networkmanager-
list wrote:
> On Wed, 2019-05-29 at 12:23 -0400, Brian J. Murrell wrote:
> > On Wed, 2019-05-29 at 09:28 +0200, Thomas Haller via
> > networkmanager-
> > list wrote:
> > > If this is happening, whe
On Wed, 2019-05-29 at 09:28 +0200, Thomas Haller via networkmanager-
list wrote:
>
> If this is happening, when you kill NetworkManager with SIGKILL, it
> would not give NetworkManager to cleanup...
>
> sudo killall -SIGKILL NetworkManager
>
> (and veryify that NetworkManager is indeed not run
On Mon, 2019-05-27 at 10:16 +0200, Beniamino Galvani via
networkmanager-list wrote:
>
> Are you sure you don't have other daemons like systemd-networkd
# repoquery -q systemd-networkd
systemd-networkd-0:219-62.el7_6.6.x86_64
# rpm -q systemd-networkd
package systemd-networkd is not installed
S
On Sat, 2019-05-11 at 17:46 -0500, Ian Pilcher via networkmanager-list
wrote:
>
> Presumably you've told NetworkManager to auto-configure the interface
> for IPv6. If you don't want it to do that, set it to link-local
> only.
But surely NM doesn't need to send dozens of RS's per second to do
tha
On Fri, 2019-02-15 at 09:05 +0100, Thomas Haller via networkmanager-
list wrote:
>
> Hi,
Hi Thomas,
> Best way is:
>
> - first disable ratelimiting in journald. For that, set
> RateLimitIntervalSec=0 in /etc/systemd/journald.conf and
> `systemctl restart systemd-journald.service`
>
> - en
On Thu, 2019-02-14 at 15:16 +0100, Thomas Haller via networkmanager-
list wrote:
>
> Hi,
Hi.
> From the logs it looks like to me the IPv6 address of the sender is
> indeed the instance managed by NetworkManager.
Oh yes, I am sure it's the NM machine that is sending the RSes.
> Is the issue har
On Thu, 2019-02-14 at 13:46 +0100, Thomas Haller wrote:
> Hi,
Hi,
> In 1.10.2-16.el7_5, that code looks pretty similar. NetworkManager
> should either log
>
> "router solicitation sent"
>
> or
>
> "failure sending router solicitation: ...
>
> for every RS that gets send.
>
>
> Possi
On Thu, 2019-02-14 at 07:49 +0100, Thomas Haller via networkmanager-
list wrote:
>
> Hi Brian,
Hi Thomas,
> It's not clear to me what you mean.
>
> Do you mean, that the many RA received at NetworkManager cause
> NetworkManager to send too frequent RS (in turn, repeating a vicious
> cycle)?
Th
On Tue, 2019-01-22 at 16:25 -0500, Brian J. Murrell wrote:
> On Tue, 2019-01-22 at 20:37 +0100, Thomas Haller via networkmanager-
> list wrote:
> > Hi,
>
> Hi Thomas,
>
> > that's odd, because NM should only log when the value actually
> > changes.
> &
On Thu, 2019-01-24 at 17:15 -0500, Brian J. Murrell wrote:
> On Tue, 2019-01-22 at 16:25 -0500, Brian J. Murrell wrote:
> > Seems I already had level=TRACE set.
>
> Was that debug useful?
So, it seems this behaviour is more harmful to the network than just
spamming a log on the
On Tue, 2019-01-22 at 16:25 -0500, Brian J. Murrell wrote:
>
> Seems I already had level=TRACE set.
Was that debug useful?
Cheers,
b.
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailin
My router is (now) sending multiple RAs instead of aggregating all
prefixes/routes into a single RA as such:
Soliciting ff02::2 (ff02::2) on pc_bridge...
Hop limit : 64 ( 0x40)
Stateful address conf.: No
Stateful other conf. : No
Mobile
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 a
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 d
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 \_
Hi. I have NM on 1.12.4 on Fedora 29 sitting behind my Internet
gateway router which has both IPv4 and IPv6 upstream connections.
Recently one of my IPv6 upstream connections changed and got a new
prefix. My Internet gateway handled that just fine and started
announcing the new prefix in it's RA
On Fri, 2018-06-29 at 11:25 +0200, Thomas Haller via networkmanager-
list wrote:
>
> in this log, there is a message:
>
> systemd-journald[621]: Suppressed 1100 messages from
> NetworkManager.service
Doh! I was looking at the wrong system when I looked for suppression
messages, so of course, I
On Thu, 2018-06-28 at 21:11 +0200, Thomas Haller wrote:
>
> Hi,
Hi,
Thanks again for looking at this...
> The number following "remove_pending_action" indicates how many
> remaining pending actions are still there (after removal).
I had wondered if that is what that was. Is that total pending
On Tue, 2018-06-05 at 14:25 +0200, Thomas Haller wrote:
>
> nm-online in "--wait-for-startup" mode is very different from the
> regular mode (as the manual page explains).
Which I don't seem to ever get.
> If you enable level=TRACE logging (see [1]), you will also see
> messages:
>
> manager:
Hi,
I have NetworkManager 1.10.8 on Fedora 28 here.
Networking is up and working fine but nm-online -s fails, even though
nm-online (without -s) succeeds:
$ nm-online
Connecting... 30s [online]
$ nm-online -s
Connecting... 30s
Connecting... 29s
Connectin
On Tue, 2018-05-22 at 13:42 +0200, Thomas Haller wrote:
>
> Correct, you cannot.
Pity.
> It's not clear why you say "in the same manner...", because this is
> regardless of whether your enslave a Wi-Fi profile to a bond or not.
> A
> Wi-Fi profile in NetworkManager (currently) always requires to
On Tue, 2018-05-22 at 07:58 +0200, Beniamino Galvani wrote:
>
> Hi,
Hi.
> bond-slave-wlp3s0-1 is of type 'ethernet', while it should be
> 'wifi'. You can create the wifi connection using your favorite
> graphical tool or nmcli and then change its master to the bond in
> this
> way:
>
> nmcli c
Hi
I am trying to bond an ethernet and wifi interface for seamless
wired/wifi switching where ethernet is the primary connection, but
fallback to wifi happens when the plug is pulled but with no IP
addressing changes.
I'm using NM 1.10.6.
I guess the first question is does anyone know of a howto
To close the loop here, this appears to be a bug in Quagga
(zebra/ospfd). Upgrading to 1.2.2 has resolved this issue.
Cheers,
b.
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-lis
On Mon, 2018-03-26 at 13:41 +0200, Thomas Haller wrote:
>
> ndisc[0x555d606ee200,"enp2s0"]: dhcp-level managed
>
> Your router says there is a DHCPv6 server around.
I guess there is no way to tell NM to ignore that if the router is
sending it, is there?
> Don't configure your
> network that w
On Mon, 2018-03-26 at 16:24 +0200, Thomas Haller wrote:
>
> ++ ipv6.may-fail = FALSE
>
> set ipv6.may-fail to yes, if you want that the connection stays up
> without IPv6.
I don't want the connection to be considered up until IPv6
configuration has happened. Other things start on t
On Mon, 2018-03-26 at 14:08 +0200, Thomas Haller wrote:
>
> In the log, the first activation attempt fails,
Why does it fail? It should be statically assigned IPv4.
> that cause
> NetworkManager to tear down the interface, and remove all IP
> addresses
> (and routes).
> It fails, because no IP
On Mon, 2018-03-26 at 13:41 +0200, Thomas Haller wrote:
>
> Hi,
Hi Thomas,
> it fails setting the token.
>
> platform-linux: link: change 2: token: set IPv6 address generation
> token to ::2
>
> Probably because kernel does in inet6_set_iftoken():
> »···if (!token)
> »···»···return
If I start zebra with an ospf configuration before Network-Manager and
then start Network-Manager after NM has completed the zebra installed
default route is removed.
A startup log with trace logging enabled where this happens can be
found at:
http://brian.interlinx.bc.ca/NetworkManager.debug
If
On Sun, 2018-03-25 at 14:27 +0200, Thomas Haller wrote:
>
> Hi,
Hi Thomas,
> try enable level=TRACE logging. See https://cgit.freedesktop.org/Netw
> or
> kManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf
> for
> hints how to do that. Then look at the logfile or send it.
Looked
Hi
I'm getting a bunch of errors and delayed network bring-up on my CentOS
7.4 system with NetworkManager version 1.8.0-11.el7_4. I wonder if
anyone has any insight.
Mar 23 16:03:40 server.interlinx.bc.ca systemd[1]: Starting Network Manager...
Mar 23 16:03:40 server.interlinx.bc.ca NetworkManag
On Sun, 2017-03-05 at 11:07 +0530, Atul Anand wrote:
> Hi Brian,
Hi Atul,
Much thanks for getting back to me. Hopefully this does not take much
effort to figure out.
> I guess the issue is with DBus activation of PacRunner. NM pushes
> config into PacRunner iff later one is available on Bus.
I
Hi,
I read with great interest about the autoproxy configuration that is
supposed to be available in 1.6, so I installed 1.6.1.
My DHCP server provides a WPAD option and NM is receiving it:
$ nmcli connection show 'pc_bridge' | grep wpad
DHCP4.OPTION[17]: wpad = http://server.example.com/proxy.
38 matches
Mail list logo
