[Touch-packages] [Bug 1745463] Re: Disabling systemd-resolved breaks dhclient resolvconf integration
If you google a bit around then you will find many issues with systemd- resolved that could be a reason you want to be able to not use it. So I have a strong opinion that Ubuntu should keep the flexibility to be able to use alternative resolving configurations. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1745463 Title: Disabling systemd-resolved breaks dhclient resolvconf integration Status in resolvconf package in Ubuntu: Expired Status in systemd package in Ubuntu: Confirmed Bug description: To reproduce, mask resolved: sudo systemctl mask systemd-resolved.service ...then disable network-manager for ifupdown interfaces: $cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile dns=default rc-manager=resolvconf [ifupdown] managed=false [device] wifi.scan-rand-mac-address=no ...and reboot. You'll note that resolvconf integration with dhclient is now broken. Interfaces listed in /etc/network/interfaces or /etc/network/interfaces.d/* will not provide DNS configuration in /etc/resolv.conf and /run/resolvconf/interfaces/. This is because /etc/dhcp/dhclient-enter-hooks.d/resolvconf defines "make_resolv_conf()" as a valid function for the BOUND case, but /etc/dhcp/dhclient-enter-hooks.d/resolved undefines it (who's nasty now, eh?) even though resolved is masked. The file existence check in the beginning of /etc/dhcp/dhclient-enter- hooks.d/resolved should be more thorough, i.e. it should ensure that resolved is enabled, rather than simply look for the existence of /lib/systemd/systemd-resolved. This works for me: -if [ -x /lib/systemd/systemd-resolved ] ; then +if [ -x /lib/systemd/systemd-resolved ] && systemctl -q is-enabled systemd-resolved ; then Arguably, /etc/dhcp/dhclient-enter-hooks.d/resolvconf should implement a similar check, looking for /run/resolvconf/enable-updates as a condition for meddling with DNS settings. If desired, I'll file a separate bug for that package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1745463/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1745463] Re: Disabling systemd-resolved breaks dhclient resolvconf integration
I've spent a lot of time discovering this issue, and now it is bugging me every time there is an update of systemd, it wants to reinstall the file again. Actually this should be solved by making systemd-resolved a separate package so it can actually be UNINSTALLED including files that disturb other packages, instead of disabled... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1745463 Title: Disabling systemd-resolved breaks dhclient resolvconf integration Status in resolvconf package in Ubuntu: Expired Status in systemd package in Ubuntu: Confirmed Bug description: To reproduce, mask resolved: sudo systemctl mask systemd-resolved.service ...then disable network-manager for ifupdown interfaces: $cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile dns=default rc-manager=resolvconf [ifupdown] managed=false [device] wifi.scan-rand-mac-address=no ...and reboot. You'll note that resolvconf integration with dhclient is now broken. Interfaces listed in /etc/network/interfaces or /etc/network/interfaces.d/* will not provide DNS configuration in /etc/resolv.conf and /run/resolvconf/interfaces/. This is because /etc/dhcp/dhclient-enter-hooks.d/resolvconf defines "make_resolv_conf()" as a valid function for the BOUND case, but /etc/dhcp/dhclient-enter-hooks.d/resolved undefines it (who's nasty now, eh?) even though resolved is masked. The file existence check in the beginning of /etc/dhcp/dhclient-enter- hooks.d/resolved should be more thorough, i.e. it should ensure that resolved is enabled, rather than simply look for the existence of /lib/systemd/systemd-resolved. This works for me: -if [ -x /lib/systemd/systemd-resolved ] ; then +if [ -x /lib/systemd/systemd-resolved ] && systemctl -q is-enabled systemd-resolved ; then Arguably, /etc/dhcp/dhclient-enter-hooks.d/resolvconf should implement a similar check, looking for /run/resolvconf/enable-updates as a condition for meddling with DNS settings. If desired, I'll file a separate bug for that package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1745463/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1826403] Re: Ethernet won't connect when cable is plugged in at boot
This could well be related to this bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1793763 I experience the same problem, not only during boot but also when waking up from sleep. All ethernet connectivity is dead for 30 minutes because the switch in my network seems to have detected an IP conflict. This does not occur if I put the plug in after boot. Very annoying, my work arround is to use ifplugd for eth0 instead of NetworkManager -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1826403 Title: Ethernet won't connect when cable is plugged in at boot Status in network-manager package in Ubuntu: Confirmed Bug description: When booting Ubuntu 19.04 with the Ethernet cable plugged in, after boot, network manager won't connect. Unplugging and plugging back in the cable with the system running doesn't work to establish a connection. The workaround is to boot with the cable unplugged, then to plug it in after boot. This problem emerged immediately following an upgrade from 18.10 to 19.04. On the first boot networking was fine, but from the first reboot a networking connection through the Ethernet cable couldn't be established if the cable was plugged in at boot. This issue is also described here: https://askubuntu.com/questions/1135412/updated-to-19-04-and-no- ethernet-now/1135726#1135726 and here: https://ubuntu- mate.community/t/19-04-ethernet-wired-connection-refuses-to-connect- when-plugged-in-before-boot/19333/6 ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: network-manager 1.16.0-0ubuntu2 ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6 Uname: Linux 5.0.0-13-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 CurrentDesktop: GNOME Date: Thu Apr 25 21:50:27 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto enp4s0f1 auto lo iface lo inet loopback InstallationDate: Installed on 2018-11-23 (153 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) IpRoute: default via 192.168.11.1 dev enp4s0f1 proto dhcp metric 100 169.254.0.0/16 dev enp4s0f1 scope link metric 1000 192.168.11.0/24 dev enp4s0f1 proto kernel scope link src 192.168.11.13 metric 100 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=false WWANEnabled=true SourcePackage: network-manager UpgradeStatus: Upgraded to disco on 2019-04-25 (0 days ago) mtime.conffile..etc.NetworkManager.NetworkManager.conf: 2019-04-25T20:03:28.380204 nmcli-dev: DEVICETYPE STATEIP4-CONNECTIVITY IP6-CONNECTIVITY DBUS-PATH CONNECTIONCON-UUID CON-PATH enp4s0f1 ethernet connectedfull limited /org/freedesktop/NetworkManager/Devices/2 Automatic connection e906293b-df71-435b-8909-7d88ca006540 /org/freedesktop/NetworkManager/ActiveConnection/1 wlp3s0wifi unavailable limited limited /org/freedesktop/NetworkManager/Devices/3 ---- -- loloopback unmanagedunknown unknown /org/freedesktop/NetworkManager/Devices/1 ---- -- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.16.0 connected started full enabled enabled disabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1826403/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1793763] [NEW] NetworkManager interaction with dhclient triggers IP conflict detection at dhcp server, causes ip address changing every day
Public bug reported:
After installing my laptop with Ubuntu and using the wired network cable
with default NetworkManager service to handle the connection, I ran into
the issue that my local ipv4 address changes every day, while this never
happens for other devices in the network. This is undesirable to me,
because it exhausts the local networks IP address pool and the change of
IP is inconvenient when working with services like SSH, samba, etc.
Added to this, I sometimes experience random network outages especially
when waking up from suspend.
After some investigation, I found the following to happen:
- The exact time the DHCP server provides with a new IP address that different
from previous one, is when I wake up my laptop after about 12 hours of being
suspended, typicaly at the start of the new working day.
- When I lookup the logs of the DHCP server at the time of the laptop getting
its new IP address, I find the following:
Sep 21 14:36 router dhcpd: DHCPDISCOVER from 68:f7:28:3f:a0:11 via eth2
Sep 21 14:36 router dhcpd: Abandoning IP address 192.168.1.137: pinged before
offer
Sep 21 14:36 router dhcpd: DHCPDISCOVER from 68:f7:28:3f:a0:11 via eth2
Sep 21 14:36 router dhcpd: DHCPOFFER on 192.168.1.139 to 68:f7:28:3f:a0:11
(kubuntu1804) via eth2
It looks like the DHCP server is detecting a possible IP conflict
because it can ping .137 while a DHCPDISCOVER for the hardware address
matches the lease with the same IP address it is about to offer. To
prevent problems, the DHCP server finds a new free IP address .139 and
offers this one instead.
Why is this triggered by the ubuntu client? When I look at the client
logs at the same time, I see following to happen:
Sep 21 00:27 kubuntu1804 systemd-sleep[21703]: Suspending system...
Sep 21 14:36 kubuntu1804 kernel: [14934.160293] Restarting tasks ... done.
Sep 21 14:36 kubuntu1804 NetworkManager[1027]: [1537533403.1923] device
(enp0s25): carrier: link connected
Sep 21 14:36 kubuntu1804 NetworkManager[1027]: [1537533403.1925] device
(enp0s25): DHCPv4 lease renewal requested
Sep 21 14:36 kubuntu1804 NetworkManager[1027]: [1537533403.2246] dhcp4
(enp0s25): canceled DHCP transaction, DHCP client pid 18900
Sep 21 14:36 kubuntu1804 NetworkManager[1027]: [1537533403.2247] dhcp4
(enp0s25): state changed bound -> done
Sep 21 14:36 kubuntu1804 NetworkManager[1027]: [1537533403.2257] dhcp4
(enp0s25): activation: beginning transaction (timeout in 45 seconds)
Sep 21 14:36 kubuntu1804 NetworkManager[1027]: [1537533403.2292] dhcp4
(enp0s25): dhclient started with pid 21860
Sep 21 14:36 kubuntu1804 dhclient[21860]: DHCPDISCOVER on enp0s25 to
255.255.255.255 port 67 interval 3 (xid=0x71ed8c51)
Sep 21 14:36 kubuntu1804 dhclient[21860]: DHCPDISCOVER on enp0s25 to
255.255.255.255 port 67 interval 5 (xid=0x71ed8c51)
Sep 21 14:36 kubuntu1804 dhclient[21860]: DHCPREQUEST of 192.168.1.139 on
enp0s25 to 255.255.255.255 port 67 (xid=0x518ced71)
Sep 21 14:36 kubuntu1804 dhclient[21860]: DHCPOFFER of 192.168.1.139 from
192.168.1.1
Sep 21 14:36 kubuntu1804 dhclient[21860]: DHCPACK of 192.168.1.139 from
192.168.1.1
So if I understand it well, the summary of what happens here is:
1) Client wakes up after being suspended for about 14h
2) Existing running dhclient fired from NetworkManager discovers the lease has
expired and requesting a renewal
3) Shortly after that this dhclient is killed by NetworkManager, probably
because NetworkManager has detected a "link connected" event, caused by the
suspend (the cable has not been removed physicaly). The old dhclient is killed
during the lease renewal and probably long before the renewal procedure could
be proparly handled
4) A new dhclient is fired by NetworkManager, performing a whole new DHCP
request, getting a new IP address from the server
I expect the events 2 and 3 happening simultaneously are causing
trouble. Probably the old IP .137 is already set to the interface while
handling the lease renewal and then a new dhclient is started performing
again a new DHCPREQUEST, confusing the dhcp server.
When I look at the ISC dhclient, it is running the hook script "/sbin
/dhclient-script" when a lease is expired or the dhclient is terminated.
See line 347 of this file:
EXPIRE|FAIL|RELEASE|STOP)
if [ -n "$old_ip_address" ]; then
# flush leased IP
ip -4 addr flush dev ${interface} label ${interface}
fi
I see when dhclient is invoked by NetworkManager, the /sbin/dhclient-
script hook is not run at all, but replaced by /usr/lib/NetworkManager
/nm-dhcp-helper, fireing events to dbus. It is unclear for me if these
events perform the correct actions like removing the old IP from the
interface.
==
Usual extra information:
1) Ubuntu version: Ubuntu 18.04.1 LTS
2) network-manager version: 1.10.6-2ubuntu1
The DHCP server is a CentOS 7 machine running the ISC DHCP server version
