Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
Package: network-manager Version: 1.22.0-2 Severity: grave Justification: renders package unusable Dear Maintainer, I have an Internet box and connect to it through Wi-Fi. After upgrading network-manager to 1.22.2-1, my machine does not get an IPv4 address anymore. Specifically, ifconfig shows: wlp1s0: flags=4163 mtu 1300 inet6 ... prefixlen 64 scopeid 0x0 inet6 ... prefixlen 64 scopeid 0x20 ether ... txqueuelen 1000 (Ethernet) RX packets 14389956 bytes 13801531443 (12.8 GiB) RX errors 0 dropped 14956 overruns 0 frame 0 TX packets 3398391 bytes 958204966 (913.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 After downloading an older version of network-manager (from snapshot.debian.org) and downgrading everything works fine: root@snoopy:# dpkg -i *1.22.0-2* dpkg: warning: downgrading gir1.2-nm-1.0:amd64 from 1.22.2-1 to 1.22.0-2 (Reading database ... 330245 files and directories currently installed.) Preparing to unpack gir1.2-nm-1.0_1.22.0-2_amd64.deb ... Unpacking gir1.2-nm-1.0:amd64 (1.22.0-2) over (1.22.2-1) ... dpkg: warning: downgrading libnm0:amd64 from 1.22.2-1 to 1.22.0-2 Preparing to unpack libnm0_1.22.0-2_amd64.deb ... Unpacking libnm0:amd64 (1.22.0-2) over (1.22.2-1) ... dpkg: warning: downgrading network-manager from 1.22.2-1 to 1.22.0-2 Preparing to unpack network-manager_1.22.0-2_amd64.deb ... Unpacking network-manager (1.22.0-2) over (1.22.2-1) ... Setting up libnm0:amd64 (1.22.0-2) ... Setting up network-manager (1.22.0-2) ... Setting up gir1.2-nm-1.0:amd64 (1.22.0-2) ... Processing triggers for libc-bin (2.29-6) ... Processing triggers for systemd (244-3) ... Processing triggers for dbus (1.12.16-2) ... Processing triggers for man-db (2.9.0-2) ... Best regards, Eugen Dedu http://eugen.dedu.free.fr -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.16-2 ii init-system-helpers1.57 ii libaudit1 1:2.8.5-2+b1 ii libbluetooth3 5.50-1+b1 ii libc6 2.29-6 ii libcurl3-gnutls7.67.0-2 ii libglib2.0-0 2.62.3-2 ii libgnutls303.6.11.1-2 ii libjansson42.12-1 ii libmm-glib01.10.4-0.1 ii libndp01.6-1+b1 ii libnewt0.520.52.21-4 ii libnm0 1.22.0-2 ii libpam-systemd 244-3 ii libpolkit-agent-1-00.105-26 ii libpolkit-gobject-1-0 0.105-26 ii libpsl50.20.2-2 ii libreadline8 8.0-3 ii libselinux13.0-1 ii libsystemd0244-3 ii libteamdctl0 1.29-1 ii libudev1 244-3 ii libuuid1 2.34-0.1 ii policykit-10.105-26 ii udev 244-3 ii wpasupplicant 2:2.9-3+b1 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base [dnsmasq-base] 2.80-1.1 ii iptables 1.8.4-1 ii modemmanager 1.10.4-0.1 pn ppp Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2 pn libteam-utils -- no debconf information
Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
Package: network-manager Followup-For: Bug #947613 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! I've got the same problem. Comparing the output of "journalctl -u NetworkManager" on both versions, the only difference I am able to spot is that with 1.22.2-1, I have these lines: déc. 29 07:30:48 zoro NetworkManager[1333]: [1577601048.8881] dhcp4 (wlp3s0): activation: beginning transaction (timeout in 45 seconds) déc. 29 07:30:48 zoro NetworkManager[1333]: [1577601048.8938] dhcp4 (wlp3s0): state changed unknown -> fail While in 1.22.0-2, I have: déc. 29 07:44:13 zoro NetworkManager[5959]: [1577601853.3663] dhcp4 (wlp3s0): activation: beginning transaction (timeout in 45 seconds) déc. 29 07:44:13 zoro NetworkManager[5959]: [1577601853.3860] dhcp4 (wlp3s0): option dhcp_lease_time => '86400' déc. 29 07:44:13 zoro NetworkManager[5959]: [1577601853.3863] dhcp4 (wlp3s0): option domain_name => 'home' [...] - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_USER Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.16-2 ii init-system-helpers1.57 ii libaudit1 1:2.8.5-2+b1 ii libbluetooth3 5.50-1+b1 ii libc6 2.29-6 ii libcurl3-gnutls7.67.0-2 ii libglib2.0-0 2.62.3-2 ii libgnutls303.6.11.1-2 ii libjansson42.12-1 ii libmm-glib01.10.4-0.1 ii libndp01.6-1+b1 ii libnewt0.520.52.21-4 ii libnm0 1.22.0-2 ii libpam-systemd 244-3 ii libpolkit-agent-1-00.105-26 ii libpolkit-gobject-1-0 0.105-26 ii libpsl50.20.2-2 ii libreadline8 8.0-3 ii libselinux13.0-1 ii libsystemd0244-3 ii libteamdctl0 1.29-1 ii libudev1 244-3 ii libuuid1 2.34-0.1 ii policykit-10.105-26 ii udev 244-3 ii wpasupplicant 2:2.9-3+b1 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base [dnsmasq-base] 2.80-1.1 ii iptables 1.8.4-1 ii modemmanager 1.10.4-0.1 ii ppp 2.4.7-2+4.1+b1 Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2 ii libteam-utils1.29-1 - -- Configuration Files: /etc/NetworkManager/NetworkManager.conf changed: [main] plugins=ifupdown,keyfile dns=dnsmasq monitor-connection-files=true [keyfile] unmanaged-devices=interface-name:docker0 [ifupdown] managed=false - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4IUSMSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX54w0QAJCyATfvRu6DwWwZE1xvF4xnCFaPAbhl 90iLRubdSb8vBcU7Z5l1A1dtqndFdrx5mbs+iZmwROA+fM71nWfN084iAIiA/tfl CGVVY5ORlw/ZfcUwhk1MtABwIJVlxt05UoHvqHrgB3W1KTSOFw8oKISOFA3gcgUA MRpwAPbwj0mjr8XW2l+7v/E+qcxDfO4B0wFu44udv+xRKBLaDjs3bUC3jXAidDgX EoLfSjvmHwZYYy4yEMnp2jFeiu3En9eCdt6pqIiN0Qo3wcg4OJe/e3yd4RJo2Lsr Bm3Gdu3IPjxlCZuDOKBcxWkxQpgKweguxxui1sUslUNFxFmvz3C4S+KB3WH33fYR JsMzEbG/aGDUPC2V+U3qthaPLaw7nJh94JLRgVUBqhyefwIFmCr2j1Xg972QAUvY 5XT4tcRd6JBmVCdPD9gwaa6eRBHGqErQCr0sx+qKks6TGK3Y/CVMn2qqsInxo9uy iuwqBjcQq6HqWUIvNXOhnZJy1gOCvMqATKyI/yPPa6Dbp+wTyC7dGZNuja1y1qVb pf7Cl6z480qFqc5kbiN3dHh++yXFjlkLn4CR6aDqXkoDIREdb4LLP59E6+PpM6ax kACEsbdgZKtfegd5TbWRubDUNtqx+q4N+XEQiEPpuUeP8wFjCpKZ2v8y7X5lsY89 4zCuQ8SydOMK =c1Pt -END PGP SIGNATURE-
Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
I was affected by the same bug (Freebox Revolution from Free (French ISP) here). I switched to isc-dhcp-client by creating a file /etc/NetworkManager/conf.d/dhcp-client.conf containing the 2 following lines: [main] dhcp=dhclient Then I restarted NetworkManager using this command: sudo service NetworkManager restart and IPv4 is working as expected again. The bug is therefore probably related to the internal dhcp client. Regards
Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
I just ran into this issue. I took a packet capture of the DHCP conversation to debug it, and found that the DHCP server was responding with a DHCP NAK packet with "address in use" as the message. And indeed, my system is sending the DHCP REQUEST with a request for a specific address (which is already in use). Rather than trying again without requesting the previous address, the internal DHCP client seems to just give up and no IPv4 address is assigned. I do have an IPv6 address, so NetworkManager considers the connection UP, not sure what happens if no global IPv6 address can be assigned. I can force this issue to happen by locating the internal client lease file at /var/lib/NetworkManager/internal-$GUID-$IFACE.lease and setting the ADDRESS to something my DHCP server will NAK. Removing the file (or setting the address to one not already in use) fixes it. -- Will Dyson
Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
Hi, I maybe interpreting this wrong, but maybe the regression in the autopkgtest of python-dbusmock is pointing in the same direction. That would make it very reproducible. Otherwise that regression deserves its own bug report. Paul https://tracker.debian.org/pkg/network-manager https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/3859077/log.gz == FAIL: test_eth_and_wifi (__main__.TestNetworkManager) -- Traceback (most recent call last): File "test_networkmanager.py", line 138, in test_eth_and_wifi self.assertRegex(out, r'eth0.*\sdisconnected') AssertionError: Regex didn't match: 'eth0.*\\sdisconnected' not found in 'DEVICE TYPE STATECONNECTION \neth0ethernet unknown -- \nwlan0 wifi unknown -- \n' == FAIL: test_one_eth_connected (__main__.TestNetworkManager) -- Traceback (most recent call last): File "test_networkmanager.py", line 115, in test_one_eth_connected self.assertRegex(out, r'eth0.*\sconnected') AssertionError: Regex didn't match: 'eth0.*\\sconnected' not found in 'DEVICE TYPE STATECONNECTION \neth0ethernet unknown -- \n' == FAIL: test_one_eth_disconnected (__main__.TestNetworkManager) -- Traceback (most recent call last): File "test_networkmanager.py", line 109, in test_one_eth_disconnected self.assertRegex(out, r'eth0.*\sdisconnected') AssertionError: Regex didn't match: 'eth0.*\\sdisconnected' not found in 'DEVICE TYPE STATECONNECTION \neth0ethernet unknown -- \n' == FAIL: test_one_wifi_with_accesspoints (__main__.TestNetworkManager) -- Traceback (most recent call last): File "test_networkmanager.py", line 155, in test_one_wifi_with_accesspoints self.assertRegex(out, r'wlan0.*\sconnected') AssertionError: Regex didn't match: 'wlan0.*\\sconnected' not found in 'DEVICE TYPE STATECONNECTION \nwlan0 wifi unknown -- \n' == FAIL: test_remove_connection (__main__.TestNetworkManager) -- Traceback (most recent call last): File "test_networkmanager.py", line 349, in test_remove_connection self.assertRegex(self.read_device(), r'wlan0.*\sdisconnected') AssertionError: Regex didn't match: 'wlan0.*\\sdisconnected' not found in 'DEVICE TYPE STATECONNECTION \nwlan0 wifi unknown -- \n' == FAIL: test_two_eth (__main__.TestNetworkManager) -- Traceback (most recent call last): File "test_networkmanager.py", line 123, in test_two_eth self.assertRegex(out, r'eth0.*\sdisconnected') AssertionError: Regex didn't match: 'eth0.*\\sdisconnected' not found in 'DEVICE TYPE STATECONNECTION \neth0ethernet unknown -- \neth1ethernet unknown -- \n' == FAIL: test_two_wifi_with_accesspoints (__main__.TestNetworkManager) -- Traceback (most recent call last): File "test_networkmanager.py", line 179, in test_two_wifi_with_accesspoints self.assertRegex(out, r'wlan0.*\sconnected') AssertionError: Regex didn't match: 'wlan0.*\\sconnected' not found in 'DEVICE TYPE STATECONNECTION \nwlan0 wifi unknown -- \nwlan1 wifi unknown -- \n' == FAIL: test_wifi_without_access_points (__main__.TestNetworkManager) -- Traceback (most recent call last): File "test_networkmanager.py", line 130, in test_wifi_without_access_points self.assertRegex(out, r'wlan0.*\sconnected') AssertionError: Regex didn't match: 'wlan0.*\\sconnected' not found in 'DEVICE TYPE STATECONNECTION \nwlan0 wifi unknown -- \n' signature.asc Description: OpenPGP digital signature
Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
Can you provide a full, verbose debug log: https://wiki.gnome.org/Projects/NetworkManager/Debugging Which dhcp client do you use: internal, isc-dhcp-client, ...? signature.asc Description: OpenPGP digital signature
Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
On 29/12/2019 13:40, Michael Biebl wrote: Can you provide a full, verbose debug log: https://wiki.gnome.org/Projects/NetworkManager/Debugging Which dhcp client do you use: internal, isc-dhcp-client, ...? I made more tests and noticed that when I upgrade from 1.22.0-2 to 1.22.2-1, the IPv4 still works, even if I associate several times to the Internet box. The problem comes when I *restart* my Internet box. So: I have my laptop running and IPv4 ok with 1.22.2-1. I restart my Internet box. Around one minute later, I have an IPv6 address, but no IPv4 address, as shown by syslog: root@snoopy:~# grep IPv /var/log/syslog|tail Dec 30 14:06:04 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:06:04 snoopy avahi-daemon[24644]: Interface wlp1s0.IPv6 no longer relevant for mDNS. Dec 30 14:06:04 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv4 with address 192.168.0.37. Dec 30 14:06:04 snoopy avahi-daemon[24644]: Interface wlp1s0.IPv4 no longer relevant for mDNS. Dec 30 14:07:44 snoopy kernel: [1688643.441802] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready Dec 30 14:07:44 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:07:44 snoopy avahi-daemon[24644]: New relevant interface wlp1s0.IPv6 for mDNS. Dec 30 14:07:47 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:07:47 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address 2a01:e0a:290:82e0:5815:8149:bcb4:18b0. Dec 30 14:07:48 snoopy NetworkManager[2495]: [1577711268.6351] policy: set 'chenoisw' (wlp1s0) as default for IPv6 routing and DNS If I restart network-manager-gnome (the icon in the task bar, I use awesome window manager), syslog file insists on IPv6 only: root@snoopy:~# grep IPv /var/log/syslog|tail -11 Dec 30 14:07:48 snoopy NetworkManager[2495]: [1577711268.6351] policy: set 'chenoisw' (wlp1s0) as default for IPv6 routing and DNS Dec 30 14:21:33 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address 2a01:e0a:290:82e0:5815:8149:bcb4:18b0. Dec 30 14:21:33 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:21:33 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:21:33 snoopy avahi-daemon[24644]: Interface wlp1s0.IPv6 no longer relevant for mDNS. Dec 30 14:21:35 snoopy kernel: [1689473.467493] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready Dec 30 14:21:35 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:21:35 snoopy avahi-daemon[24644]: New relevant interface wlp1s0.IPv6 for mDNS. Dec 30 14:21:36 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:21:36 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address 2a01:e0a:290:82e0:5815:8149:bcb4:18b0. Dec 30 14:21:38 snoopy NetworkManager[2495]: [1577712098.1291] policy: set 'chenoisw' (wlp1s0) as default for IPv6 routing and DNS root@snoopy:~# ifconfig shows: wlp1s0: flags=4163 mtu 1300 inet6 2a01:e0a:290:82e0:5815:8149:bcb4:18b0 prefixlen 64 scopeid 0x0 inet6 fe80::bf01:6fea:9592:b415 prefixlen 64 scopeid 0x20 ether ... txqueuelen 1000 (Ethernet) RX packets 15747787 bytes 15483453634 (14.4 GiB) [...] Now, I downgrade to previous version: root@snoopy:/home/ededu# dpkg -i *22.* dpkg: warning: downgrading gir1.2-nm-1.0:amd64 from 1.22.2-1 to 1.22.0-2 (Reading database ... 330241 files and directories currently installed.) Preparing to unpack gir1.2-nm-1.0_1.22.0-2_amd64.deb ... Unpacking gir1.2-nm-1.0:amd64 (1.22.0-2) over (1.22.2-1) ... dpkg: warning: downgrading libnm0:amd64 from 1.22.2-1 to 1.22.0-2 Preparing to unpack libnm0_1.22.0-2_amd64.deb ... Unpacking libnm0:amd64 (1.22.0-2) over (1.22.2-1) ... dpkg: warning: downgrading network-manager from 1.22.2-1 to 1.22.0-2 Preparing to unpack network-manager_1.22.0-2_amd64.deb ... Unpacking network-manager (1.22.0-2) over (1.22.2-1) ... Setting up libnm0:amd64 (1.22.0-2) ... Setting up network-manager (1.22.0-2) ... Setting up gir1.2-nm-1.0:amd64 (1.22.0-2) ... Processing triggers for libc-bin (2.29-6) ... Processing triggers for systemd (244-3) ... Processing triggers for dbus (1.12.16-2) ... Processing triggers for man-db (2.9.0-2) ... syslog shows some IPv4 activity: root@snoopy:/home/ededu# grep IPv /var/log/syslog|tail -15 Dec 30 14:21:38 snoopy NetworkManager[2495]: [1577712098.1291] policy: set 'chenoisw' (wlp1s0) as default for IPv
Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
❦ 29 décembre 2019 13:40 +01, Michael Biebl : > Can you provide a full, verbose debug log: > > https://wiki.gnome.org/Projects/NetworkManager/Debugging > > Which dhcp client do you use: internal, isc-dhcp-client, ...? I am using the internal client. Unfortunately, I am not able to reproduce the problem anymore. Once I get it again, I'll send the logs. -- Test programs at their boundary values. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
Hello Michael, I was able to hit the bug again. It seems I have to go to another wifi network, then back to my home network to hit the bug. On the client-side, I get: janv. 06 18:57:13 zoro NetworkManager[75721]: [1578333433.9474] dhcp4 (wlp3s0): activation: beginning transaction (timeout in 45 seconds) janv. 06 18:57:13 zoro NetworkManager[75721]: [1578333433.9532] dhcp4 (wlp3s0): sent REQUEST to 255.255.255.255 janv. 06 18:57:13 zoro NetworkManager[75721]: [1578333433.9571] dhcp4 (wlp3s0): received NACK from 0.0.0.0 janv. 06 18:57:13 zoro NetworkManager[75721]: [1578333433.9572] dhcp4 (wlp3s0): state changed unknown -> fail On the server-side, I am using dnsmasq. Logs say: Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPREQUEST(lan-trusted) 192.168.117.40 3e:55:59:b2:a3:b9 Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPNAK(lan-trusted) 192.168.117.40 3e:55:59:b2:a3:b9 address in use I am a bit puzzled why dnsmasq says that, but it didn't happen with older versions of Network Manager. If I capture the request and response, I get: 18:57:13.952425 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 317) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 3e:55:59:b2:a3:b9, length 289, xid 0xa9a8ed40, Flags [none] (0x) Client-Ethernet-Address 3e:55:59:b2:a3:b9 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether 3e:55:59:b2:a3:b9 Parameter-Request Option 55, length 18: Subnet-Mask, Time-Zone, Domain-Name-Server, Hostname Domain-Name, MTU, BR, Classless-Static-Route Default-Gateway, Static-Route, YD, YS NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft Option 252, RP MSZ Option 57, length 2: 576 Requested-IP Option 50, length 4: 192.168.117.40 Hostname Option 12, length 4: "zoro" END Option 255, length 0 18:57:13.952596 IP (tos 0xc0, ttl 64, id 26751, offset 0, flags [none], proto UDP (17), length 328) 192.168.117.1.67 > 255.255.255.255.68: [bad udp cksum 0x36ef -> 0x0984!] BOOTP/DHCP, Reply, length 300, xid 0xa9a8ed40, Flags [Broadcast] (0x8000) Client-Ethernet-Address 3e:55:59:b2:a3:b9 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: NACK Server-ID Option 54, length 4: 192.168.117.1 MSG Option 56, length 14: "address in use" END Option 255, length 0 PAD Option 0, length 0, occurs 34 But if I look at the lease file from dnsmasq, I see: 1578382414 e8:2a:ea:05:c0:df 192.168.117.40 zoro 01:e8:2a:ea:05:c0:df So, I suppose this is a because of randomizatio of the MAC address on wifi networks. I don't see anytrhing special in the NEWS file about this. Previously, the hardware MAC address was used to do the DHCP request. When using dhcp=dhclient, I am getting the same NAK, but then the ISC DHCP client is using DISCOVER and gets a new IP address. RFC says "If the client receives a DHCPNAK message, the client restarts the configuration process." So, I think the bug is more in the fact that the DHCP client doesn't restart configuration when receiving a NAK but just gives up. -- Localise input and output in subroutines. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
Hi everyone On Mon, 06 Jan 2020 19:14:46 +0100 Vincent Bernat wrote: > So, I suppose this is a because of randomizatio of the MAC address on > wifi networks. I don't see anytrhing special in the NEWS file about > this. Previously, the hardware MAC address was used to do the DHCP > request. > > When using dhcp=dhclient, I am getting the same NAK, but then the ISC > DHCP client is using DISCOVER and gets a new IP address. Looking at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commits/nm-1-22 there aren't that many commits between 1.22.0 and 1.22.2 so it should be possible to find the offending commit pretty easily via git bisect for someone who can reproduce the issue. Checking the upstream bug tracker, https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/325 seems like the most likely candidate. There the following commit is mentioned as the culprit: > 46ad3aa4f39f3ec786a77847c422be9cbf5d61a5 is the first bad commit > commit 46ad3aa4f39f3ec786a77847c422be9cbf5d61a5 > Author: Beniamino Galvani > Date: Mon Dec 23 15:39:06 2019 +0100 > > dhcp: nettools: start from init-reboot phase when reusing address > > If we know the address used previously, also tell the client to start > from the init-reboot phase, so that it will start with a DHCP request > instead of a discover. > > (cherry picked from commit 6af6f70d812249bdbc27d63fbd9544c57c33d04d) > > src/dhcp/nm-dhcp-nettools.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Anyone willing to check the proposed fix https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/848b869c6ede3a796872a0b5cd8b2398804c3697 Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
On 08/01/2020 16:07, Michael Biebl wrote: Anyone willing to check the proposed fix https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/848b869c6ede3a796872a0b5cd8b2398804c3697 Hi, I tested the proposed patch on top of debian's 1.22.2-1 version. This patch does NOT fix the issue. I would say it is even worse. The network-manager-gnome icon in the task bar (I use awesome window manager) turns around and restarts several times, each time with a different MAC address (as shown by ifconfig) and getting and losing an inet6 address. After around 10 restarts, it finally stops and shows "NetworkManager is not running". I could provide a small video if it helps. Cheers. Eugen
