Re: DHCP renewal changes routing table

On Fr, 2015-06-05 at 11:39 -0500, Dan Williams wrote:
On Thu, 2015-06-04 at 13:45 +0200, Thomas Haller wrote:
On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote:

When I run the Juniper Network Connect client (ncsvc) it 
every time the DHCP license is renewed. The log files of ncsvc 
unfortunately rather cryptic, but it appears as if the DHCP 
leads to a change in the routing table which triggers a 
in ncsvc which then tears down the VPN tunnel. Using timestamps 
following two events correlate:

20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to 
destination is missing mask with gw, metric 1, if_id 0, disconnecting (routemon.cpp:628)

which coincides with the following journal entries:

Jun 03 13:34:55.454967 host NetworkManager[1805]: address
Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24
Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 
Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway
Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver 
Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): 
state changed bound -> bound
Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via 
systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus
Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully 
activated service 'org.freedesktop.nm_dispatcher'
Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching 
'dhcp4-change' for wlp6s0
Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost 

Besides the ncsvc error listed above I sometimes also see this 

20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized 
route to has been added        (conflicts 
our route to, disconnecting (routemon.cpp:598)

Both seem to indicate that the routing table is changed on DHCP 
renewal. Is there a way to prevent networkmanager from doing 
this? Or 
is this problem caused by something else possibly?

as you suspect, this is caused by NetworkManager. At various times
(e.g. when activating a connection, or on new DHCP lease), NM will
reinstall routes.

recently there was a related email thread:

but no solution either.

We could change NM not only do any system-modification when it will
actually have any effect.
Like, re-installing a route, only if it is not yet currently there.

In NM 1.0.x we still have nm_platform_ip4_route_sync() which already
checks array_contains_ip4_route(), so shouldn't that prevent
re-installation of device-specific routes that are already there?  Or
this is only about the default route and subnet routes from the

Yes, NMRouteManager would not install routes that are already present.
But from DHCP a new address/route could be announced, or another
interface might activate/deactivate...


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]