Slackware vrs NetworkManager

ttk · 02-02-2018, 05:08 PM

I've been working on my own alternative to NetworkManager for years. What I have now works "okay", most of the time, but is still unreliable and sometimes requires tweaks to work on new networks.

It has given me a tremendous appreciation for how many slightly-different implementations of WAPs are out there, and how much the behavior of a given implementation can change over time. For instance, the time it takes to get a DHCP response can depend on how long it's been since the WAP was last rebooted, or the number of IPs it currently has allocated.

This makes for a lot of "try something, wait a while, try something else, wait a while and try it again" which can be automated but makes the process very slow. Sometimes there is no good way to discern between a need to try again immediately with different parameters, trying again with the same parameters after a few seconds of delay, or trying again with a longer timeout.

My take-away is that NetworkManager sucks, but this is in part a reflection of the difficulty of the problem it seeks to solve.

I'm not giving up on developing an alternative, but I've given up on making it work as well as I think it should, until such time that the technology underlying wireless networking matures (if ever).

Richard Cranium · 02-04-2018, 02:41 AM

Quote:

Originally Posted by selfprogrammed

Question 1: nm-applet does not run on my box, complaining that libmm-glibc (from memory) is missing.
Now I installed every library off the Slackware install disc, especially any of those "mm" ones (every third tool I try is missing some "mm" library). Was this supposed to be on the Slackware install, or did you have to download it.

Code:

# ldd /usr/bin/nm-applet | grep libmm
	libmm-glib.so.0 => /usr/lib64/../lib64/libmm-glib.so.0 (0x00007fd6d9330000)
# grep libmm-glib.so /var/log/packages/*
/var/log/packages/ModemManager-1.4.14-x86_64-1:usr/lib64/libmm-glib.so.0.2.0

So, I'd install/reinstall the ModemManager package.

[/quote]

Quote:

Question 2: nmtli works, but fails to connect. The NetworkManager log file shows that it is connecting, then it "disassociates" with a reason that indicates a request from NetworkManager. The reason is a cryptic numeric code. Anywhere, I can look up these codes?

Did you mean nmtui?

Probably, but I'm not sure where to look. If you gave us the code, we might be able to figure it out.

Quote:

Question 3: If I try to edit a connection setup from a user account, I get a error message box that is twitching, moving or resizing itself at a rate of 4 times a second. This makes it unreadable, but I have made out the word "authorization". As this only happens from the user account, I assume it is telling me that I cannot change connection parameters without being root. Does anyone else see this twitching error message? I would like to know if it is the usual NetworkManager bugginess, or something unique to my installation.

How are you editing the connection setup? Is this a window under X?

Quote:

Question 4: The NetworkManager docs have a line that says "Support for dhcpcd has been discontinued" with a date of 2015. The Slackware installation says that it uses dhcpcd, and there is a line in the config "dhcp=dhcpcd". This package is a Slackware package, as far as I know. Either someone has restored the support for dhcpcd, or else Slackware should not be trying to use it. Are any of you successfully using dhcpcd with a NetworkManager after 2015, that says it is discontinued in its docs? And if so, then why is it still working?

It is working fine on my downstairs laptop. Why does it work? Why shouldn't it? Network manager is passing off the dhcp handshake handling to something else. I'd guess that the people who write NetworkManager don't use dhcpcd and aren't going to guarantee that it'll work.

For some people, it doesn't work and changing /etc/NetworkManager/conf.d/00-dhcp-client.conf to one of the other choices results in a system that can connect.

Quote:

Question 5: Giving the -ask on the command line is supposed to have it ask for missing parameters, like the PSK. This is buggy and for many things, it does not ask.
For the PSK, it does ask, but then comes back and asks again. It does not tell the user why it is asking again. I have seen another report of this, so I know it is NetworkManager bugginess (and not my installation). Is there any way to deal with this, or is the NetworkManager totally screwed up when it reaches this state ?

Sorry, never seen this.

Richard Cranium · 02-04-2018, 02:57 AM

Quote:

Originally Posted by selfprogrammed

Question 6: Would making my user account in the "wheel" group, or creating a "network" group
actually solve any problems.

Well, on the machine I have using NetworkManager, my user is in the groups

Code:

users lp wheel floppy video cdrom plugdev power netdev scanner docker burning

You won't need the 'docker' group. I don't think that 'wheel' really applies here.

Quote:

Question 7: My current assumption is that the dhcp negotiation is not working right.
When I try to run wifi-radar, I gets messages that it cannot get a network address.

I'd expect problems earlier in the connection process, myself. I've had NetworkManager unable to connect after a few hibernate/restore cycles, requiring a restart of all the system-level networkmanager stuff. From the logs, the problems occurred long before attempting to get an address.

Quote:

Question 8: There are plenty of statements that other network manager packages may conflict
with any other nework manager package. These statements are the vague kind, that usually indicate that they don't actually know how it conflicts.
As far as I know:

8a: NetworkManager starts at boot time, and it connects to udev events.
-- it will conflict with any other tools that connects to the udev events.
-- what other tool is there that connects to these udev events ??

8b: Wifi-radar seems to be a gui with some settings. If you do not invoke it, it cannot conflict with anything else.

8c: wpa_supplicant is actually used by NetworkManager, but it also has its own gui.
So what usage of that gui is a conflict with NetworkManager?
Is NetworkManager so fragile that you cannot even look at wpa_supplicant settings?

8d: I have not tried wicd, but I expect that is similar to NetworkManager is conflicts.

I think you are reading too much into that. If you try to run NetworkManager and wicd at the same time, they will stomp all over each other. If you attempt to use rc.inet1.conf to manage your wireless connections as well as NetworkManager, one of the two will win in any given situation. The winner may not be the one you'd expect.

Quote:

Question 9: When I look at ps -A, I am seeing
wpa_supplicant
NetworkManager
in that order. I notice that dhcpcd is missing, and that wpa_supplicant was started before NetworkManager (it has a lower procid). If NetworkManager was starting wpa_supplicant, would it not come after NetworkManager ??
For those who have NetworkManager working, is that the what you see?

Code:

$ pstree
init-+-ModemManager-+-{gdbus}
     |              `-{gmain}
     |-NetworkManager-+-dhcpcd
     |                |-{gdbus}
     |                |-{gmain}
     |                `-{pool}
     |-wpa_supplicant

Code:

$ ps -ef
root      1316     1  0 Feb03 ?        00:00:44 /usr/sbin/NetworkManager
root      1362     1  0 Feb03 ?        00:00:00 /usr/sbin/ModemManager
root      1369     1  0 Feb03 ?        00:00:04 /usr/sbin/wpa_supplicant -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
root      1477  1316  0 Feb03 ?        00:00:00 /sbin/dhcpcd -B -K -L -A -G -c /usr/libexec/nm-dhcp-helper -4 -h toshiba wlan0

(Well, there's a lot of other stuff that I'm running on that box that you don't need to see.)

selfprogrammed · 02-05-2018, 01:21 PM

I have changed lilo to have the "ipv6.disable=1" boot on my machine, but as it has decided that the big partition needs a fschk today, it will have to wait a while.

Thank you Richard Cranium. I had grabbed every document and download I could find and stuffed them on a memory stick while I had the machine and internet access. One that I had grabbed was ModemManager, as it was the only site that seemed to know anything about libmm-glib. That library seems to be built into ModemManager. The only usage that NetworkManager makes of it is for the nm-applet gui.
I do not have any broadband modems, but I have installed ModemManager as being the easiest way to get libmm-glib. For some reason it is being started automatically right before NetworkManager. At least the nm-applet is working now. Thanks.

The flickering error message is when a non-root user, on X-windows, is trying to edit connections using nmtui (I have the spelling memorized now). If you had every seen it you would know what I am talking about. Of course you have to have the same problem with "authorization" to even get the error.

I have the source code for NetworkManager-1.10 and will have to look in there to seem what they are doing. I have been forced to examine the source code as their documentation only makes sense after you already know what in the heck they are going on about (especially after you know what parts you can safely ignore, like all the WEP instructions).

I spend most of two days trying to verify the dhcpcd support in NetworkManager.
That is the step where it fails, and there no sign that it is starting dhcpcd (how much sign there would be I don't know).
I found the source code with the dhcpcd support code. All the dhcpcd support code is wrapped in a conditional.

To get dhcpcd support, the value WITH_DHCPCD has to be set true for the compile.
The source file with dhcpcd support has an #if around the dhcpcd code.
> ... src/dhcp/nm-dhcp-dhcpcd.c

Code:

 #if WITH_DHCPCD
   ...
     return nm_utils_find_helper( "dhcpcd", DHCPCD_PATH, NULL );
   ...
   const NMDhcpClientFactory _nm_dhcp_client_factory_dhcpcd = {
     ...
   };
 #endif

All the functions are declared static.
The const _nm_dhcp_client_factory_dhcpcd should be linkable.

There are several unique strings within the dhcpcd support code.
"dhcpcd"
"/dhcpcd"

Searches of the binaries to determine if the dhcpcd support was actually there.
> grep "dhcpcd" /usr/lib/libnm*
> grep "dhcpcd" /usr/bin/nm*
> grep "dhcpcd" /sbin/NetworkManager
- found the dhcpcd strings

> strings /sbin/NetworkManager | grep "/sbin"
...
/sbin/dhcpcd

So apparantly the slackware package has been fixed to include the dhcpcd support.
I don't know exactly how, as the only slackbuild for NetworkManager I could find was for Slackware 13.1. I got that too.

To test the dhcp, I changed config in /etc/NetworkManager/conf.d/00-dhcp-client.conf
so that the NetworkManager uses internal dhcp.

Using NetworkManager internal dhcp, it stays connected and does not "unassociate".
I am getting an IPv6 network address, but network access is buggy.
I can get to google and slackware site, but cannot get to linuxquestions nor the slackware-store. Which sites fail is consistent. I can get to Youtube, which is amusing until you realize how much time you are wasting. Most sites fail.

I found "Configuring your network in Slackware - Alien" to be useful in explaining the background actions (not visible) that Slackware is carrying out.
It is one of the few good documents on this. It explains things well. I have read it about 12 times and spent most of last night reading it again.
NetworkManager is forcing me to UNDO just about everything I did using this document.

I have yet to find out why I have routing problems getting to internet sites using wifi.

As the fsck must be done by now, I shall go off and test the IPv6.disable.
I don't expect this to go well as trying to turn off IPv6 using NetworkManager only made it refuse to connect at all. It insists on getting an IPv6 network address from the cable modem. I found out from the cable modem ISP that their backbone is IPv6. One computer using the LAN port is getting IPv4.

selfprogrammed · 02-05-2018, 01:36 PM

The test using IPv6.disable=1 ::
I must have typed it right, because I can see the effects.
Using nm-applet to try to connect, It just whirrs awhile, and then silenty goes away.
Using nntui, it tries awhile to connect, and then an error box pops where it says that it failed to connect (in red letters).
I cleared the wpa_supplicant.log just to make sure, ... wpa_supplicant is not even logging messages. At least before I got 5 lines of logging from wpa_supplicant even when it failed, and NetworkManager disassociated.
I am not sure how early this is failing.

I do use IPv4 in my lab networking on the LAN cable (which was working last time I used it).

Alien Bob · 02-05-2018, 01:39 PM

Quote:

Originally Posted by selfprogrammed

I don't know exactly how, as the only slackbuild for NetworkManager I could find was for Slackware 13.1. I got that too.

I guess that you've only looked at 3rd-party repositories then? And yet, SBo has a NetworkManager.SlackBuild for Slackware 13.37: https://slackbuilds.org/repository/1...etworkManager/

You may also not have noticed that a NetworkManager package got added to Slackware 14.0. So from then onward, the NetworkManager.SlackBuild can be found in the official Slackware source tree: http://slackware.osuosl.org/slackwar...etworkManager/ for instance.

selfprogrammed · 02-05-2018, 02:02 PM

I have discovered that you can change wpa_supplicant without NetworkManager noticing.
One thing you can do is turn-on debugging.

Find the wpa_supplicant
> ps -A

Look at its command line.
> less /proc/844/cmdline
Answer yes, it looks like a binary file because it has nulls between parameters.
If you use cat, it will leave out the nulls.
If you use more, it will only get the first item.

Kill wpa_supplicant
> kill 844

Start a new wpa_supplicant, with debugging, or any other parameters you want.
Debugging output is verbose, you can get more or less of the debugging messages as you want.
You can change the log file too.
> /sbin/wpa_supplicant -d -B -u -f /var/log/wpa_supp_debug.log -P /var/run/wpa_supplicant.pid
The -u is needed to get udev, which NetworkManager needs.
The -B starts it as background deamon.

NetworkManager will use the new wpa_supplicant (well as least in my test it worked).

selfprogrammed · 02-05-2018, 02:12 PM

Just checked with slackbuilds.org.
Used 14.2.
Searched for NetworkManager.
Found:
NetworkManager-openconnect
NetworkManager-openvpn
NetworkManager-pptp
NetworkManager-vpnc
wifi-radar

I do not see a NetworkManager.
As last week I was just grabbing all the packages I could in the internet time that I had, I don't remember exactly how I got to the slackbuilds for 13.1. It was some link from some other site.
I have been downloading slack patches from a slackware linked site. I have not been considering them to be 3rd-party. I found the NetworkManager package that I have installed in my slack-patches directory with all the other patches for 14.2 I got around Jan 14.
The package is: NetworkManager-1.8.4-i586-1_slack14.2
Files are dated: Oct 27.
It looks to be a slack patches package, at least it does not say alien or ponce.

I don't know if a slackbuilds for 13.37 is much better. That is a different Linux version, and the source is now NetworkManager-1.10.

But, more to the point, what slackbuild was used to build the package
NetworkManager-1.84-i586-1_slack14.2 ?
If I want to build NetworkManager-1.10, I would want that slackbuild, because at least it has been updated for Slackware 14.2 and Linux 4.4.88 (or so).

selfprogrammed · 02-05-2018, 02:27 PM

Thank you: You are using dhcpcd on a laptop and it works.
Some people report that it does not work for them, (reasons unknown ??).
Noted.

selfprogrammed · 02-05-2018, 02:35 PM

I grabbed everything I could from OSU.
Owner has returned, harassment, must flee.

Thank you.

Alien Bob · 02-05-2018, 02:42 PM

Quote:

Originally Posted by selfprogrammed

Just checked with slackbuilds.org.
Used 14.2.
Searched for NetworkManager.
Found:
NetworkManager-openconnect
NetworkManager-openvpn
NetworkManager-pptp
NetworkManager-vpnc
wifi-radar

I do not see a NetworkManager.
As last week I was just grabbing all the packages I could in the internet time that I had, I don't remember exactly how I got to the slackbuilds for 13.1. It was some link from some other site.
I have been downloading slack patches from a slackware linked site. I have not been considering them to be 3rd-party. I found the NetworkManager package that I have installed in my slack-patches directory with all the other patches for 14.2 I got around Jan 14.
The package is: NetworkManager-1.8.4-i586-1_slack14.2
Files are dated: Oct 27.
It looks to be a slack patches package, at least it does not say alien or ponce.

I don't know if a slackbuilds for 13.37 is much better. That is a different Linux version, and the source is now NetworkManager-1.10.

What's so difficult to understand about my comment?

Quote:

You may also not have noticed that a NetworkManager package got added to Slackware 14.0. So from then onward, the NetworkManager.SlackBuild can be found in the official Slackware source tree: http://slackware.osuosl.org/slackwar...etworkManager/ for instance.

Quote:

But, more to the point, what slackbuild was used to build the package
NetworkManager-1.84-i586-1_slack14.2 ?
If I want to build NetworkManager-1.10, I would want that slackbuild, because at least it has been updated for Slackware 14.2 and Linux 4.4.88 (or so).

The tag "1_slack14.2" is indication of a post-release security patch. So look here: http://slackware.osuosl.org/slackwar...etworkManager/

bassmadrigal · 02-05-2018, 09:45 PM

Quote:

Originally Posted by selfprogrammed

Just checked with slackbuilds.org.
Used 14.2.
Searched for NetworkManager.
Found:
NetworkManager-openconnect
NetworkManager-openvpn
NetworkManager-pptp
NetworkManager-vpnc
wifi-radar

I do not see a NetworkManager.

In addition to Alien Bob's post, SBo does not normally include packages that are included in Slackware. Since Network Manager was added back with Slackware 14.0, it will not be able to be found in SBo beyond Slackware 13.37.

It would probably be best to check your /var/log/packages/ directory or at the minimum https://packages.slackware.com to see if the package is included in the official OS. If it isn't included there, you could check SBo to see if they offer the package. Since Slackware includes Network Manager, SBo only includes various addons for Network Manager, which is what you found.

To use Network Manager, ensure /etc/rc.d/rc.networkmanager is executable (chmod +x /etc/rc.d/rc.networkmanager) and started (/etc/rc.d/rc.networkmanager start) and then run nmapplet from within a WM/DE or nmtui from within a console (not starting X) to ensure it is setup properly.

rkfb · 02-06-2018, 03:09 PM

I always use wicd, specifically wicd-curses (but the gui is good), and have never had any problems, it's always been so easy to use. As long as you set your wireless interface correctly in preferences.

I've often thought it should be the default software on Slackware.

selfprogrammed · 02-09-2018, 02:11 PM

Latest results.
I was checking all the Slackware installed packages, looking for anything that might be helpful.

I noticed iproute2 package was not installed. It has some tools so I installed it. It has not made any difference. I don't know if that is an optional add-on, or if it contains some necessary deamons.

I discovered didentd. I already have an updated package installed but could not find the tar file for it.
The Slackware description of didentd states that if you do not have an ident service running then some sites will not talk to you. That sound close enough to what I am experiencing to be worth investigating.
It appears that the ident service is not running. At least I cannot find any ident deamon.
> ps -A | grep ident
Trying some of the didentd programs, I keep getting an error that it cannot access libcrypto.so.0. I have libcrypto.so.1 and others, but not 0.
As this is nearly a pure Slackware 14.2 installation as far as crypto and network libraries,
I don't know why this library should be missing.
So, now I need to figure out if the library should be there, or if the didentd package needs recompilation to adjust to the new libcrypto.so.1.

I could ask if anyone outthere with Slack 14.2 has anything for /usr/lib/libcrypto.so.0, but Question 13 would be unlucky anyway. So I have about 2 hours to explore the internet for some sign of libcrypto.so.0. Otherwise I need to find the source for the didentd -2 package.

Also, I still do not know why I cannot get connected using only IPv4. Only IPv6 addressing works with the cable modem. The XP box is using IPv4, so this is a Linux issue.
I was able to use traceroute -6 to see the hops to google.
> traceroute -6 www.google.com
It refuses to traceroute with linuxquestions, saying that the site is unknown.
> traceroute -6 www.linuxquestions.org
( I am typing this from memory, hours after having done the tests yesterday, so please don't bug me about typos as I am discussing how it succeeds for some sites, and fails for others. )

The google speed test is one of the sites I could actually use.
The XP box on the cable modem LAN is getting 20 Mbps download speed.
Linux on the same XP box got about 6 Mbps download, but its configuation has not been fixed yet.
My Linux box on a LAN cable to the cable modem gets 6 Mbps, and that is a faster CPU. It was using a 200 ft LAN cable run up the stairs and down the hallway, but I would not expect that kind of speed even on that length of cable.
The cable box is capable of 900 Mbs, and the ISP service advertises 150 Mbsp, with testimony that it should be at least 100 Mbs.
I expect that Linux can do much better than this.
I have to figure out some speed test without Firefox, like FTP or something.
(Edit: The XP box explicitly says it is connecting 100 Mbps Ethernet. The Linux box is much newer and faster, and should have 100 Mbs Ethernet too. )

selfprogrammed · 02-09-2018, 02:44 PM

I have tried to access the XP from the Linux box through the cable modem. You think they should be able to see each other on the local network.
I have not been able to even ping the XP box from the Linux box, they cannot see each other.
This may have something to do with XP box using an IPv4 address to the cable modem, and the Linux box is getting an IPv6 address from DHCP.

I do not understand why an IPv4 ping from the Linux box should fail so badly.

I still cannot access the cable box admin from the Linux box, not even using the 200ft up-the-stairs LAN cable. I tried the IPv4 address that works on the XP, and the Linux box cannot see it. IPv4 addresses work on this same box when I access other computers on my local lab LAN (at least they did before Network-Manager was started). I suppose I will have to lookup the IPv6 address for the admin page and try that with the Linux Box.