libnm/networkmanager 1.6.0?

ngoonee · 2024-02-23 08:15:42

After today's update which included 1.44.2-3 to 1.46.0-1 updates for libnm and networkmanager, my wifi (an Intel AX210 chip) has been spotty. After suspend it seems to connect but is not able to send/receive anything. A full reboot sometimes fixes. Downgrade of just libnm (not networkmanager) seems to fix this.

Haven't done any networking troubleshooting in maybe a decade (never needed to), and this chip should fall under 'just works' anyway so this may be a regression. Anyone else experiencing this?

ngoonee · 2024-02-23 08:37:59

So just looking at NetworkManager logs - it seems to stop/hang at "state changed new lease, address=192.168.25.121, acd pending". On a normal boot (successfully connected) it would then continue to

"state changed new lease, address=192.168.25.121
set 'SSIDNameHere' (wlp4s0) as default for IPv4 routing and DNS"

and so on.

seth · 2024-02-23 08:48:45

Does it help to use another https://wiki.archlinux.org/title/Networ … HCP_client ?
For wider context, https://bugzilla.redhat.com/show_bug.cgi?id=1713380
Maybe the dad-timeout default changed?

ngoonee · 2024-02-23 14:08:22

seth wrote:

Does it help to use another https://wiki.archlinux.org/title/Networ … HCP_client ?
For wider context, https://bugzilla.redhat.com/show_bug.cgi?id=1713380
Maybe the dad-timeout default changed?

Tried dhclient - same behaviour slightly different log.

Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.4089] device (p2p-dev-wlp4s0): supplicant management interface state: inactive -> scanning
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.4656] device (wlp4s0): supplicant interface state: scanning -> authenticating
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.4657] device (p2p-dev-wlp4s0): supplicant management interface state: scanning -> authenticating
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.5056] device (wlp4s0): supplicant interface state: authenticating -> associating
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.5056] device (p2p-dev-wlp4s0): supplicant management interface state: authenticating -> associating
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.5984] device (wlp4s0): supplicant interface state: associating -> 4way_handshake
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.5985] device (p2p-dev-wlp4s0): supplicant management interface state: associating -> 4way_handshake
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.7111] device (wlp4s0): supplicant interface state: 4way_handshake -> completed
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.7111] device (wlp4s0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network>
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.7112] device (p2p-dev-wlp4s0): supplicant management interface state: 4way_handshake -> completed
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.7115] device (wlp4s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.7119] dhcp4 (wlp4s0): activation: beginning transaction (timeout in 45 seconds)
Feb 23 22:04:13 nglegion NetworkManager[719]: <info>  [1708697053.7135] dhcp4 (wlp4s0): dhclient started with pid 5338
Feb 23 22:04:13 nglegion dhclient[5338]: DHCPDISCOVER on wlp4s0 to 255.255.255.255 port 67 interval 6
Feb 23 22:04:14 nglegion dhclient[5338]: DHCPOFFER of 192.168.25.121 from 192.168.25.1
Feb 23 22:04:14 nglegion dhclient[5338]: DHCPREQUEST for 192.168.25.121 on wlp4s0 to 255.255.255.255 port 67
Feb 23 22:04:14 nglegion dhclient[5338]: DHCPACK of 192.168.25.121 from 192.168.25.1
Feb 23 22:04:14 nglegion NetworkManager[719]: <info>  [1708697054.9928] dhcp4 (wlp4s0):   address 192.168.25.121
Feb 23 22:04:14 nglegion NetworkManager[719]: <info>  [1708697054.9928] dhcp4 (wlp4s0):   plen 24 (255.255.255.0)
Feb 23 22:04:14 nglegion NetworkManager[719]: <info>  [1708697054.9928] dhcp4 (wlp4s0):   gateway 192.168.25.1
Feb 23 22:04:14 nglegion NetworkManager[719]: <info>  [1708697054.9928] dhcp4 (wlp4s0):   lease time 7200
Feb 23 22:04:14 nglegion NetworkManager[719]: <info>  [1708697054.9928] dhcp4 (wlp4s0):   nameserver '202.188.18.188'
Feb 23 22:04:14 nglegion NetworkManager[719]: <info>  [1708697054.9928] dhcp4 (wlp4s0):   nameserver '1.9.1.9'
Feb 23 22:04:14 nglegion NetworkManager[719]: <info>  [1708697054.9928] dhcp4 (wlp4s0):   nameserver '192.168.25.1'
Feb 23 22:04:14 nglegion NetworkManager[719]: <info>  [1708697054.9929] dhcp4 (wlp4s0): state changed new lease, address=192.168.25.121, acd pending

seth · 2024-02-23 15:23:56

https://bugzilla.redhat.com/show_bug.cgi?id=1713380#c6
What if you explicitly set that to "ipv4.dad-timeout=-1"?

Can you test the system against a different router/LAN?

ngoonee · 2024-02-24 02:06:57

seth wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=1713380#c6
What if you explicitly set that to "ipv4.dad-timeout=-1"?

No difference in behaviour.

seth wrote:

Can you test the system against a different router/LAN?

Not currently, unfortunately. Stuck at home for a bit. Could test against my hotspot but not at the moment.

alexiarc · 2024-02-24 03:53:50

Downgrading libnm and networkmanager to v1.44.2 fixes the issue, I have the same issue with the new version (v1.46.0-1).

seth · 2024-02-24 08:51:08

https://people.freedesktop.org/~lkundra … tings.html

ipv4.dad-timeout=0
ipv6.dad-timeout=0

-1 is actually the default, 0 disables it.
https://gitlab.freedesktop.org/NetworkM … /-/issues/

https://gitlab.freedesktop.org/NetworkM … ssues/1485 - but that suggests an alternative dhcp client works around this…

wallentx · 2024-02-24 08:52:04

Just posting up here to say that this upgrade also broke my Realtek Semiconductor Co., Ltd. Killer E3000 2.5GbE Controller.
`dhcp4 (enp4s0): state changed new lease, address=192.168.1.251, acd pending`

Tonurics · 2024-02-24 09:30:18

Writing in to report today's update also causes NetworkManager on my system to hang at the same "acd pending" message:

Hardware:
Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller
Intel Corporation I211 Gigabit Network Connection
Intel Corporation Wi-Fi 6 AX200

Temporary Solution:
Change the NetworkManager's DHCP client to dhclient and manually execute dhclient after NetworkManager hangs on "acd pending"
https://wiki.archlinux.org/title/Networ … HCP_client

* This does not in itself fix the problem; dhclient needs to be manually run after each network change.

Additional Info:
This update also appears to break reserved DHCP leases by incorrectly reporting interface MAC addresses.

Downgrade Solution
If you have the previous package locally:

sudo pacman -U /var/cache/pacman/pkg/networkmanager-1.44.2-3-x86_64.pkg.tar.zst

If you don't have the previous package and restored network access:

sudo pacman -U https://archive.archlinux.org/packages/n/networkmanager/networkmanager-1.44.2-3-x86_64.pkg.tar.zst

Last edited by Tonurics (2024-02-24 09:44:11)

htdocscat · 2024-02-24 12:48:40

It seems that NM is having trouble applying configured IP addresses (IPv4 only, no hangs if I disable IPv4 DHCP) to the interface, as my wired interface with a static IP address configured in NM is also affected.

frumble · 2024-02-24 14:07:28

I’m not even on Testing and got the same problem today. Forum moderator "2ManyDogs" just closed my thread in the "System Administration" forum and moved it to dustbin ("Closing, as a duplicate, for deletion."), pretty rude and never have seen this behavior in 12 years on this forum before. O.o

seth · 2024-02-24 14:12:04

libnm is meanwhile in extra 1.46 and you've explicitly said you're gonna follow this thread.

And you can find that particular line A LOT throughout the forum history.
It's not rude, it's absolute standard.

=> https://bbs.archlinux.org/viewtopic.php … 6#p2152796
Try to disable the dad timeout and see the upstream bug.

Bobyl · 2024-02-24 15:30:08

seth wrote:

Try to disable the dad timeout and see the upstream bug.

Setting dad-timeout to 0 for both ipv4 and ipv6 solved the issue on my wired and wireless interface.

Last edited by Bobyl (2024-02-24 15:31:17)

Arch Linux

#1 2024-02-23 08:15:42

libnm/networkmanager 1.6.0?

#2 2024-02-23 08:37:59

Re: libnm/networkmanager 1.6.0?

#3 2024-02-23 08:48:45

Re: libnm/networkmanager 1.6.0?

#4 2024-02-23 14:08:22

Re: libnm/networkmanager 1.6.0?

#5 2024-02-23 15:23:56

Re: libnm/networkmanager 1.6.0?

#6 2024-02-24 02:06:57

Re: libnm/networkmanager 1.6.0?

#7 2024-02-24 03:53:50

Re: libnm/networkmanager 1.6.0?

#8 2024-02-24 08:51:08

Re: libnm/networkmanager 1.6.0?

#9 2024-02-24 08:52:04

Re: libnm/networkmanager 1.6.0?

#10 2024-02-24 09:30:18

Re: libnm/networkmanager 1.6.0?

#11 2024-02-24 12:48:40

Re: libnm/networkmanager 1.6.0?

#12 2024-02-24 14:07:28

Re: libnm/networkmanager 1.6.0?

#13 2024-02-24 14:12:04

Re: libnm/networkmanager 1.6.0?

#14 2024-02-24 15:30:08

Re: libnm/networkmanager 1.6.0?

Board footer