SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 451
Rep:
WiFi loss upon resume?
Since the latest round of upgrades (Tue Aug 31 20:58:13 UTC 2021), my laptop (Intel wireless controller AX200) has been losing connectivity after closing the lid and re-opening. It's been running -current since January, and I haven't seen this issue before.
Basically, after opening the lid, a process called "dhcpcd [Network Proxy]" didn't reappear, and all subsequent pings returned "temporary name resolution failure." This happened both under X and in tty.
I tried a number of things, including a firmware rollback, using the standard kernel and rebuilding dhcpcd, but the only working solution was to remove the dhcpcd user and group. Now the connection seems to be behaving normally. Has anyone else had this issue since the etc package upgrade?
It seems like networkmanager doesn't kill the old dhcpcd while suspending, and after resume it tried to start a new client that fails since another instance of dhcpcd is already rinning.
Changing the dhcp client used by networkmanager in /etc/NetworkManager/conf.d/00-dhcp-client.conf could workaround this, but i suppose that there's a root cause that needs proper fixing here.
It's not really solved yet.
EDIT: i can confirm that setting "dhcp=internal" in /etc/NetworkManager/conf.d/00-dhcp-client.conf is a workaround for the problem
Network manager can use different methods to get an ip address using dhcp:
1. using the external program dhcpcd
2. using the external program dhclient
3. using an internal implementation in networkmanager
The networkmanager guys recommend using option 3, but Slackware defaults to option 1 since it's the same dhcp used by rc init scripts.
Since the problem here seems to be interaction between networkmanager and dhcpcd, switching to the internal implementation avoids the problem.
If you switch to using option 3, even if the main problem gets a patch in Slackware, you won't probably notice.
Good thread! I think I have a related challenge. I have the same syslog error messages on a remote gateway running -current.
It started July 20th after a full run with slackpkg over an openvpn connection. Based on the logs it looks like I rebooted the gateway then a couple hours later NetworkManager lost connectivity with an error "wlan0: failed to renew DHCP". The interface cascades multiple errors then fails with a loss of network. I've been physically at the location a couple times & have to hard boot the gateway to regain functionality. The error process starts over again and is currently not responding remotely.
The gateway manages eth0 with an inet1.conf static IP. NM ignores eth0 using the unmanaged-devices setting in NetworkManager.conf. It also has an on demand tun0 when the openvpn connection is activated. Both of those interfaces seem to run as expected.
I'm going to try the dhcp=internal setting to see if that corrects the NM dhcp error messages and stabilizes wlan0 over the weekend.
Well glad to hear I'm not the lone stranger. Had this issue with my laptop that I hibernate. I tried the dhcp=internal setting, it does not work for me. I still have to reboot or:
Hi, got this as well the other day; seems not have changed by setting "dhcp=internal".
After recompiling the NetworkManager modules from SBo I had for various vpn methods, the wifi can connect again after resume on my box. Maybe I am not the only one forgetting to recompile such modules after an upgrade even it might be the obvious thing to do.
EDIT: red herring; sorry. Resume still cannot restore wifi irrespective of dhcp= setting.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.