thanks for the workaround.
similar behavior and improvement here using the setting "dhcp=internal" in /etc/NetworkManager/conf.d/00-dhcp-client.conf.
but network connection is not as stable as it used to be upon suspend (loginctl suspend) then resume.

Similarly the network manager applet, nm-applet, under fluxbox with an X11 session is not working as well as it used to be :
- mouse click on the nm-applet tray's icon or connection status are often off on my machine.

expecting updates will address it on the network manager release side ?

I've noticed the boot-time warning about there being no dhcpcd user/group and (at first) was glad to see that it was added, but now I'm not so sure. This is turning into a support problem for me as I keep having to help my dad every time he resumes his laptop. I was first going to try the internal DHCP, but someone reported in this thread that it has some stability problem, so I think I'll just remove the user/group.

I couldn't find any report or discussion of the dhcpcd user/group warning here on the forum, so perhaps the report was directly emailed to Pat.

I spent a few minutes digging through the dhcpcd and NetworkManager sources but couldn't find any references to a user or group. (Admittedly, I didn't search very hard.) This leaves me wondering what was responsible for printing that warning in the first place. Removing the user and group should help me to flush out an answer to that question.

Recent dhcpcd releases introduce the concept of privilege separation.

From https://roy.marples.name/git/dhcpcd/...4e202281cb8ef9

In Slackware that user didn't exist, so dhcpcd always ran as root and wrote on the system log that it failed to drop privileges because the user was missing.
I guess somebody reported the error message and reported it to Pat (the changelog mentions Paul Blazejowski), so the dhcpcd user got added to Slackware.
This fixed the error message and now dhcpcd is correctly using priviledge separation.
Unfortunately this is now causing this new problem.

The dhcp=internal workaround worked for me as well. Haven't experienced the instability issues mentioned by _peter (at least not yet).

This is the pull request that added support for dhcpcd-9.x to networkmanager: https://gitlab.freedesktop.org/Netwo...ests/668/diffs

Notably, it mentions this in the code:

So, the dhcpcd-9.x is broken?

I don't have a lot of insight into what's happening on suspend. But conceptually, if NM relies on dhcpcd processes to completely disappear on suspend, and they do not, I would assume the problem to be more likely be located with dhcpcd than NM, based on that comment.

just to say, is not somethiung only wifi-related, but current connected network related:

I usually connect via ethernet with my laptop. After suspending, the ethernet stops working, but if i enable the wifi, it works correctly. Just saying if it helps in any way

Yep, I confirm that the Ethernet itself goes nuts and and several USB WiFi cards may or may not work...

Man, I really hope that the Slackware team is aware of the DISASTER on networking after last updates on this stack. You put it down like a wounded horse, people!

And no, is not Firefox or Chromium. I've got "network unreachable" on ping, while being well connected to router. Theoretically.

At my limited knowledge I fail to understand for what those changes was really needed, BUT at least be gentle to put the default to "internal" on that config file of NetworkManager.

Is the single configuration which still works more or less - I have some WiFi cards unable to connect to router anymore even with this "internal" option. Isn't even needed a hibernation resume. Just straight from boot.

And a humble question: you are sure 100% that that latest DHCP, or whatever on this networking stack of today, does not suppose that it should runs from a systemd unit, just like the PipeWire daemons? Just asking...

Not really sure about that

Because dhcpcd is only a broadcast daemon that interact with NM. I think it's more a problem related to both,
and how NM handles suspend/resume with an external DHCP daemon ( which I have absolutely no idea how it behaves) - and it doesn't seem to be their problem, cf. @ppr:kut post #20
rather than a problem related only to one or the other

That's why I completely agree with LuckyCyborg, for now the best for us is to adopt dhcp=internal. Which works well in any case

I suppose the other option would be to revert the changes from the last etc upgrade, but that's probably more disruptive. dhcp=internal hasn't given me any issues.

yes, but if you want to downgrade dhcpcd, you need to revert to NM 1.28
because since NM v1.30, dhcpcd >= 9.3.3 is requiered

And, I for one, that's not what I want

Agreed. I meant keep the dhcpcd package as-is, but remove the user and group.

I run with "dhcp=internal" for about a year now without problems until some weeks (?) ago resuming from suspend started to show the symptoms this thread is about.
:D

a couple of days of good stability with "dhcp=internal" and then a sporadic re-connection upon suspend/resume with the following messages that is beyond my understanding.
will let it be for now. not worried about it as a wired connection via rc.inet1 - ie: not network-manager - is stable, as always.

Also ISP modem providing the dhcp server are notoriously poorly designed when working w/ address reservation over wifi. Mine needs a reboot every month, more or less.

the end for me.