ghostbsd / networkmgr

NetworkMgr is a Python GTK3 network manager for FreeBSD, GhostBSD, TrueOS and DragonFlyBSD
BSD 3-Clause "New" or "Revised" License
94 stars 30 forks source link

[Bug]: Default route removed when wired network comes up #107

Open rhaberkorn opened 1 month ago

rhaberkorn commented 1 month ago

Which BSD system

FreeBSD

Describe the bug

Networkmgr appears to remove the default route whenever configuring any interface, even if a gateway is not set in the IPv4 config, ie. if the "Gateway" field is left empty.

How to reproduce the bug?

14.1-RELEASE-p2, networkmgr 0.6.4.

  1. Connect to Wifi for internet access -> get a default route via DHCP.
  2. Configure em0 statically via ifconfig or simply replug the ethernet cable. A gateway is not set in the dialog of the wired connection in networkmgr, as we only want to communicate with an adhoc connected computer via a wired connection.

The default route through wifi will vanish, breaking internet connectivity.

Expected behavior

networkmgr will not touch the old default route, that we received via DHCP. I would also be happy if I could prevent networkmgr from managing certain interfaces at all, so I can manually manage em0 without it interfering.

rhaberkorn commented 1 month ago

Even if I disable a wired connection in networkmgr, once I bring it up via ifconfig it also gets managed by networkmgr again.

rhaberkorn commented 1 month ago

Okay, excuse me. This actually happens even without networkmgr, so it's some part of FreeBSD interfering in an unexpected manner.

ericbsd commented 1 month ago

@rhaberkorn, did you remove NetworkMgr, or you only closed NetworkMgr?

That behavior is familiar. Some code executes even if you close NetworkMgr.

rhaberkorn commented 1 month ago

did you remove NetworkMgr, or you only closed NetworkMgr?

I only closed networkmgr, but did not pkg remove it. Tried route -n monitor in order to confirm that the default route is indeed removed once the em0 interface gets up:

screenshot-1721316629

Tried some dtracing to find out which process in particular is to blame. I guess it's devd which ships with a dhclient.conf - this is the only thing reacting on LINK_UP.

rhaberkorn commented 1 month ago

Oh well, it turns out that networkmgr is indeed responsible. Here I used dwatch -R execve to trace the process removing the default route - PID 73155.

2024 Jul 23 01:32:55 0.0 python3.11[73122]: /bin/sh -c service routing restart ; service dhclient restart em0
 -+= 00001 0.0 /sbin/init
  \-+= 01260 0.0 /sbin/devd
    \-+= 73122 0.0 /usr/local/bin/python3.11 /usr/local/share/networkmgr/link-up.py em0
      \-+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
2024 Jul 23 01:32:55 0.0 sh[73143]: kenv -q rc.debug
 -+= 73122 0.0 /usr/local/bin/python3.11 /usr/local/share/networkmgr/link-up.py em0
  \-+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
    \-+= 73143 0.0 /bin/sh /usr/sbin/service routing restart
      \-+= 73144 0.0 kenv -q rc.debug
2024 Jul 23 01:32:55 0.0 sh[73143]: /sbin/sysctl -n -q kern.boottrace.enabled
 -+= 73122 0.0 /usr/local/bin/python3.11 /usr/local/share/networkmgr/link-up.py em0
  \-+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
    \-+= 73143 0.0 /bin/sh /usr/sbin/service routing restart
      \-+= 73145 0.0 /sbin/sysctl -n -q kern.boottrace.enabled
2024 Jul 23 01:32:55 0.0 sh[73142]: env -i -L -/daemon HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin /etc/rc.d/routing restart
 -+= 00000 0.0 kernel
  \-+= 00001 0.0 /sbin/init
    \-+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
      \-+= 73143 0.0 env -i -L -/daemon HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin /etc/rc.d/routing restart
2024 Jul 23 01:32:55 0.0 env[73142]: /bin/sh /etc/rc.d/routing restart
 -+= 00000 0.0 kernel
  \-+= 00001 0.0 /sbin/init
    \-+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
      \-+= 73143 0.0 /bin/sh /etc/rc.d/routing restart
2024 Jul 23 01:32:55 0.0 sh[73143]: kenv -q rc.debug
 -+= 00001 0.0 /sbin/init
  \-+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
    \-+= 73143 0.0 /bin/sh /etc/rc.d/routing restart
      \-+= 73146 0.0 kenv -q rc.debug
2024 Jul 23 01:32:55 0.0 sh[73143]: /sbin/sysctl -n -q kern.boottrace.enabled
 -+= 00001 0.0 /sbin/init
  \-+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
    \-+= 73143 0.0 /bin/sh /etc/rc.d/routing restart
      \-+= 73147 0.0 /sbin/sysctl -n -q kern.boottrace.enabled
2024 Jul 23 01:32:55 0.0 sh[73148]: /sbin/sysctl -n kern.features.inet
 -+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
  \-+= 73143 0.0 /bin/sh /etc/rc.d/routing restart
    \-+= 73148 0.0 /bin/sh /etc/rc.d/routing restart
      \-+= 73149 0.0 /sbin/sysctl -n kern.features.inet
2024 Jul 23 01:32:55 0.0 sh[73150]: /sbin/sysctl -n net.fibs
 -+= 73143 0.0 /bin/sh /etc/rc.d/routing restart
  \-+= 73148 0.0 /bin/sh /etc/rc.d/routing restart
    \-+= 73150 0.0 /bin/sh /etc/rc.d/routing restart
      \-+= 73151 0.0 /sbin/sysctl -n net.fibs
2024 Jul 23 01:32:55 0.0 sh[73148]: /sbin/sysctl -n net.fibs
 -+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
  \-+= 73143 0.0 /bin/sh /etc/rc.d/routing restart
    \-+= 73148 0.0 /bin/sh /etc/rc.d/routing restart
      \-+= 73152 0.0 /sbin/sysctl -n net.fibs
2024 Jul 23 01:32:55 0.0 sh[73148]: /sbin/route delete -inet 127.0.0.1 -iface lo0
 -+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
  \-+= 73143 0.0 /bin/sh /etc/rc.d/routing restart
    \-+= 73148 0.0 /bin/sh /etc/rc.d/routing restart
      \-+= 73154 0.0 /sbin/route delete -inet 127.0.0.1 -iface lo0
2024 Jul 23 01:32:55 0.0 sh[73148]: /sbin/route -n flush -inet
 -+= 73142 0.0 /bin/sh -c service routing restart ; service dhclient restart em0
  \-+= 73143 0.0 /bin/sh /etc/rc.d/routing restart
    \-+= 73148 0.0 /bin/sh /etc/rc.d/routing restart
      \-+= 73155 0.0 /sbin/route -n flush -inet

In other words, it's /usr/local/etc/devd/networkmgr.conf. It's indeed running stuff even when networkmgr itself is not running.

ericbsd commented 1 month ago

@rhaberkorn, thanks for all the information.

rhaberkorn commented 1 month ago

But why does service routing restart even remove the default route? Is this expected?

rhaberkorn commented 1 month ago

/etc/rc.d/routing does not add dynamic routes. See also: https://forums.freebsd.org/threads/service-netif-restart-service-routing-restart-removes-default-route-for-gateway-received-via-dhclient.91807/post-637570

I believe that you should add the interface to all calls as in service routing restart inet em0; service routing restart inet6 em0. Also, at the beginning of the scripts, you should always check whether networkmgr is actually running.

rhaberkorn commented 1 month ago

This fixes the most annoying problems for me. link-up.patch.gz

However I can still manage to flush the default route eg. when statically configuring em0 directly via networkmgr. There are probably other scripts, that call service restart routing indifferently.

ericbsd commented 1 month ago

I will test your path in various system I have and see if it that works with systems without inet6.

rhaberkorn commented 1 month ago

You should also fix this layout: screenshot-1721780176