Configure NetworkManager to use dhcp for better connection

[simone]

With my laptop I'm on a wireless network of a hotel. Also I have had this problem of continuous disconnections, I confirm that you can fix or installing wicd or by editing the file with NM dhcp ...

[djemos]

I can confirm that this is the solution. I had this problem with a wireless connection in Nafpaktos where i had to use wicd.
Now networkmanager is working fine. No disconnections.

[westms]

To correct that I had to find and install the Slackware dhcp package and then change the Network Manager's DHCP settings.

So, that was it? We've had a couple of reports that NetworkManager wouldn't work (laprjns was one), but nobody else would be able to reproduce it. Obviously (now) because nobody else had OpenWRT routers, but nobody else had made the connection before. Are there any side effects of using dhcp instead of dhcpcd on non-OpenWRT users?

Good questions!

I can report the following:

I owned a Linksys Wireless-G Broadband Router, Model WRT54G v3.1 and installed OpenWRT micro on it. During the beta phase of Salix64 14.2 Xfce, this router was also used for a few days. In these tests, no difficulty with connect or stable connections has occurred. This would already reflect that OpenWRT has no negative influence. But WRT54G v3.1 is old hardware and the OpenWRT on it is old, too. It may well be, that there are still no problems with this old version. I still own a Linksys Router, Model WRT54G v5 with original firmware. With this are no problem visible. With my non-wireless TP-LINK, no malfunctions are visible.


NetworkManager starts the client independently. No intervention in /etc/rc.d is necessary to launch the client. Previously NetworkManager had client dhcpcd in the presets. In a later development stage, it was changed to dhclient.

When dhcpcd has delivered its data to the interface, this client continues to monitor the interface. Opposed to that, dhclient terminates and no longer observes the interface any more, when it has stored the data in the interface. I can imagine that the newer NetworkManager observe the interface extensively itself and thereby under certain conditions collides with the activities of the dhcpcd, which then leads to the known difficulty. This can also be caused by a triangle relationship between NetworkManager, dhcpcd and dhcp deamon in the router.


What can be done to further narrow the problem and find a solution?

NetworkManager can be configured for three different clients. The third client is a built-in and is called internal. (dhcp=dhclient | dhcpcd | internal)

All forum members who use Salix(64) 14.2 in conjunction with the NetworkManager should try setting dhcp=internal, especially those where dhcp=dhcpcd does not work. If users do not have problems then, this setting can be recommended as an emergency solution for Salix 14.2. This would allow the dhclient package to be downloaded and installed. An explicit forum article could point this out. For later Salix versions, the packages with dhclient and dhcpcd would be included in the installation image and the user can install the best fitting.

A survey in the forum could be called for cooperation and collect information.

I have no trouble with dhcpcd, which is more powerful than dhclient. Therefore can not explore the problem. According to my point of view, dhclient also comes from a strange Net-tools package. Personally, I'd avoid that package.

[laprjns]

I have given up on Networkmanger. A couple of weeks after posting what is the opening post of this thread, Networkmanager started to misbehave again, failing to sustain a connection, so i went back to wicd. This morning after seeing westms post, i decided to try Networkmanger again using the latest version update, 1.2.6. Tried using all three options for dhcp clients, dhcpcd, dhclient and local, and none of them resulted in a stable connection. Same problem, cycling between being connected and disconnected. Any way that's it for me, I'm sticking with wicd.

[Nate_KS]

Troubles abound...

I'd been keeping this laptop powered up for quite some time, only placing it in suspend between uses. Sunday night I pulled the power with the lid closed while half asleep and rather than go into suspend, as the lid was already closed, the laptop ran until the battery died. Yesterday evening I powered it back up and could not get an IPv4 address from my OpenWRT router with Network Manager no matter what. I've fiddled and fought and finally installed WiCD to get network again.

I see that in /var/log/packages that NetworkManager 1.2.6 was installed on April 27, 2017, but since I never logged out or restarted the laptop, I wasn't bit by this bug until now. I intend to downgrade NM and see if it works again.

ETA:

Success! Downgrading the NetworkManager package to 1.2.2 and having it configured to use dhclient is once again working just fine.

I've added "^NetworkManager" to the exclude list in gslapt to hopefully hold it at this working version.

[westms]

This is an interesting observation! But still insufficient to draw conclusions from it.

Please repeat the procedure described by yourself with this older version. This means that the accumulator must be emptied without the power supply until the computer is off. You do not necessarily have to be half asleep. Then, very important, restore the power supply and perform booting in the same time sequence as before. Does the NetworkManager problem occur again?

I would like to find out whether the power management is involved with faulty influence. As reason I have nothing but a presumption.

[Nate_KS]

I did as you requested with NM 1.2.2 installed and operational. I pulled the power and allowed the laptop to die from a depleted battery. I plugged it back in, powered it up, logged in, and NM established a Wifi connection with my router as normal.

Before I downgraded NM from 1.2.6, I had rebooted several times in an effort to troubleshoot the fault and it would simply never establish an IPv4 connection though it did establish an IPv6 connection and I actually did an update through gslapt before I realized there was an issue. In both cases, this is using dhclient instead of he default dhcpcd, though both packages are installed.

[westms]

I did as you requested with NM 1.2.2 installed and operational. I pulled the power and allowed the laptop to die from a depleted battery. I plugged it back in, powered it up, logged in, and NM established a Wifi connection with my router as normal.

Thank you very much for your work. I had expected a different result. But all right, even so one get a bit further.

Before I downgraded NM from 1.2.6, I had rebooted several times in an effort to troubleshoot the fault and it would simply never establish an IPv4 connection though it did establish an IPv6 connection and I actually did an update through gslapt before I realized there was an issue. In both cases, this is using dhclient instead of he default dhcpcd, though both packages are installed.

Strange the functioning IPv6 connection. In my memory, other affected users had never reported about it.

You did not save the configuration files by chance before downgrading? Probably not.

It would be nice if other affected users could also confirm that version 1.2.2 is running satisfactorily.

After two closely related versions exist, where one works, the error should be easier to find than by studying the complete source code. One could look for significant configuration differences between NetworkManager 1.2.2 and 1.2.6. Then one could look for the differences between the versions in the source codes. Perhaps a responsible difference can be found. A faulty cooperation with external components can also be considered. It is quite possible that an unintended deterioration in the program code has occurred.

[Papasot]

The only conclusion I can get from all the above is that using "NetworkManager" by default was a VERY bad decision from Slackware's developer(s). I wasn't affected because the first thing I did after installing Salix 14.2.1 (live cd's "full" installation) was to get rid of RedHat's crap called "NetworkManager" and install the tried-and-true WiCD instead. In ll my other computers I installed Salix 14.2 with "basic" installation, then installed WiCD, so I didn't even have to deal with "NetworkManager" at all.

By the way, this is not the only problem caused by using that crap. It's not even a new thing: I do remember "NetworkManager" to be problematic years ago, when I was using Debian. Even today, "NetworkManager" is far from being a trustworthy application: many modern USB wireless adapters don't work with "NetworkManager" while they work perfectly with WiCD; as far I am aware of, this affects most wireless adapters using Realtek chipsets (there are plenty of them). Of course, there are workarounds (see, for example, this thread), but I am still wondering WHY WiCD should be replaced by "NetworkManager" in the first place. What's so exciting in this piece of crap (other than the "exciting" problems it causes), and why should I look for a replacement if the real thing called WiCD does its job flawlessly?

I strongly recommend that next Salix version should use WiCD by default, no matter what Slackware does.

[DidierSpaier]

I strongly recommend that next Salix version should use WiCD by default, no matter what Slackware does.

I strongly disagree. That NetworkManager doesn't work for you (for reasons you didn't elaborate, at least in this thread) certainly doesn't make it bad for everybody. I am perfectly satisfied using NetworkManager and am certainly not alone.