Slackware vrs NetworkManager
 

Yet another posting about NetworkManager on Slackware.
I read the posting

"Can't get Wi-Fi working in Slackware 14.2 with usb adapter and networkmanager"

and most of it is identical to what I have been experiencing.

However, I still have some questions that I think someone out there could answer.

Background: Slackware 14.2 package, Running Linux 4.4.88,
updated to almost every patch package as of Jan 4, 2018.

I have two USB wifi dongles, and have experimented with them trying to connect to a router. Finally succeeded at that (it was missing route setup).
Now, our internet has been replaced with a cable router,
which is on another floor, and I will need to use a USB dongle to reach it. I managed to get connected twice, using command line invocation of wpa_supplicant, dhcpcd, iwconfig, and iw. I cannot reproduce it.

I have been trying to find a network manager that would allow me to connect to the network when needed (NOT AUTOMATICALLY all the time), that would know the keyphrases needed, and start the support tools needed to do WPA2-PSK, and DHCP, with this cable modem.

I repeat, I managed to do this by command line twice,
but it is not repeatable. So it is no use questioning the drivers and dongle.

Continue with questions in next posting....

Right now, I think that NetworkManager is buggy and should be thrown out the window as more of a problem than a solution. It seems to be manager being suggested (out of sheer desperation I think).

I discovered that it was installed, and figured how to enable it (I think). There are no useful instructions, just ones that go on and on about obscurities that have nothing to do with connecting to a simple WPA2-PSK cable modem.

I want a tool that can adapt to what demons are running and start those that are missing.
NetworkManager is NOT that tool. It appears to be a totally DUMB runner of scripts.

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.
(Fixed: Must install ModemManager to get the required library)

Question 2: nmtui 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?
(The internal dhcp seems to work, it gets an IPv6 address. Using dhcpcd does not seem to work for me, even though it is installed and is the default for slackware. )


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.


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?
(Answer: Verified that Slackware package does have dhcpcd support enabled.)


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 ?

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


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.


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.

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?

Experiences with wpa_supplicant.

Question 10: My settings in wpa_supplicant keep disappearing, so I have to set it up each time anew. Is that the usual experience ?

Question 11: If I setup wpa_supplicant (without using NetworkManager, and before NetworkManager was enabled). To even see the device I must do something like
> /etc/rc.d/rc.inet1 wlan0_start
I can then select this device and setup a connection using wpa_cli.
However, it won't actually connect.
I believe that I had to manually start dhcp with some line like:
> dhcpcd
But I still could not get a connection, but got as a last message "WPA-AP IS AVAILABLE".
SO.. I looked under WPS tab, and the only thing there that I could do was to create a key number, so I created a key number. Then I pushed the button to negotiate. I got the message "push the button on the AP", so I ran to the cable modem and pushed the button on top of it. When I get back, the message has changed to "Push the button to register this key" (something like that), but the only button I can push is the same one I pushed to start this. Tight loop.
OK seems irrelevant, but when I backed out to the other tab, I managed to connect and was able to acess the web using Firefox (used it for several hours, and there is no other net access on that computer). I have not managed to do this a second time.

Is this key necessary for WPA2-PSK? If not then what mode uses it?
Is there some other way to pass the key to the cable modem?

networkmanager works for me here.

I believe wpa_supplicant should be started by networkmanager;
Have you tried running this before trying to connect using nm-applet?
Assuming something else is starting wpa_supplicant, this should get networkmanager functioning if that's the case.

I'm not sure if it's politically correct to agree with you on the statement above, but at least I can say that I like it.
You have a lot of questions and I only can help you with a temporary manual network setup, as I don't use NetworkManager myself.
As root, without having NetworManager (make sure it's dead) running you can use as inspiration the instructions from this post:
https://www.linuxquestions.org/quest...ml#post5802633

Additionally, for the push-button on your router connection try, I'd suggest to avoid that kind of WPS connection as it's probably very insecure (older implementations were not protected against PIN brute-force).
https://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup

I was at the computer in question, and booted it for today.
I modified some config files last night, decided that NetworkManager was not going to pay any attention to them. Perhaps it would look at them after a reboot.

I changed the PSK keys on the cable modem, just to catch out any tools keeping stale keys.
Typed an extra char in the PSK in the config file, and NetworkManager did not even notice.
It still asks for the passphrase, and I keep typing it in.
I have corrected the PSK extra character.

Today (after reboot) it is as follows:

The USB network dongle was plugged in before booting today.

> ps -A
Today it looks like NetworkManager started wpa_supplicant.

Used nmtui to try to connect.
It failed again.
I had cleared the wpa_supplicant logs the night before, so this log is exactly for the one attempt using NetworkManager.
As far as I can tell, it is not negotiating the network address (dhcp) which make my
questions about the dhcp rather important.
That question is rather specific to someone who runs a recent NetworkManager on Slackware, using the slackware package.

Question 12: When the NetworkManager does connect, using nmtui, does the nmtui stay active, or does it go away ? Can I close it without disturbing the connection?
I am wondering if the message about "disassociating" in the log is due to shutting down nmtui.
(Answer: it can go away. The diassociation is done by NetworkManager due to dhcpcd not working. I had to change to the internal dhcp (and I am not absolutely sure that is working ether, but I do get an address from the modem, and it stopped "diassociating".)

Perhaps your Wi-Fi disconnect issues will go away if you disable IPv6. Helped me in the past.
If you use lilo, add the following string to the "append" statement in /etc/lilo.conf and re-run the "lilo" command:

I could configure the cable modem with a static address for my machine.
That would get around the dhcp problem.

Problem is that I also have a laptop to configure, that runs the same Slackware installation,
and that will have to connect to a cable modem that I cannot configure. It will have to
use dhcp. So I do have to solve the dhcp problem.

Could someone look in their /var/log/wpa_supplicant.log when their network is up and tell me what the last log entry is.

Does it log CTRL-EVENT-DISCONNECTED normally as part of connecting ?
Does it log CTRL-EVENT-DISCONNECTED normally as part of disconnecting ?
Does it only log CTRL-EVENT-DISCONNECTED when there is an error ?

I assume you like talking to yourself a lot.
Care to answer any of the posts not written by you?

I was off reading the suggested material someone else posted.
If there was a question in there, I have not seen it yet.

I am NOT at the computer in question, but am using someone else's computer to get to LinuxQuestions. So I won't be rebooting it right now. Your suggestion about IPV6 will have to wait until next time I can reboot.

This cable modem is still using its default address (10.0.0.1).
I intend to later change this to something in my usual network address range (192.168...).
Is this default address setting something that would be hampering dhcp?
Should I change all the cable modem dhcp addresses to this other address and range?
Is this change likely to mess-up any other devices (like Windows) that might try to connect to this cable modem?

What if I used:
192.168.4.88 for the cable modem
192.168.4.89 to 254 for the dhcp address range.

I have not done this yet because of having to track down all the places in Linux where
unusual net address have to be set.
- I cannot set any address in /etc/hosts because it is dhcp
- Setting the cable modem address in /etc/hosts would not seem to be useful, as I expect it is used for dhcp negotiation
- However, I know (because I ran in to it before) that there is some place in Linux that I have to set the dhcp address for a particular device.

Is it possible that dhcp cannot find the dhcp server in the cable modem because it has not
been told the network address to use ?

The owner of this machine has come back and I have to go.

For those who only want to snark about how many questions I asked or how much information I posted, I probably will not be able to get access to LinuxQuestions again until sometime next week, in case that is some kind of issue for you.

Alien had the correct answer but you have missed it, I had the same issues on two computers, connect then immediate disconnect.

If you are using NetworkManager then edit the connection and disable ipv6 it will connect and stay connected if not then go with what Alien said.

To stop network manager connecting when it sees the network remove the tick from that box (General Config tab).

Unfortunately to resolve the underlying issue with ipv6 involved changing dhcp settings on the router side, I cannot recall how i configured mine but that can be looked at if you need ipv6.