[SOLVED] Networkmanager question

pchristy · 09-19-2023, 03:48 AM

System: Pi 400 running slackwareaarch64-current

This is more of a general question rather than an issue. In addition to my Pi, I also have a few x86_64 machines, and there is a distinct difference in the way networkmanager behaves between the two.

On x86_64, the network connects during boot up, before the login screen appears. On the Pi, the network doesn't connect until a user logs in.

As far as I can tell, there is no difference between the configuration of the two systems - at least at an obvious, user accessible level.

Why is this a problem? Well, the Pi doesn't have a RTC, so until a network connection is established, the system time will be wrong. I have a local NAS which I use for updates, keeping a local copy of the systems I use (Slackware64-current, Slackwareaarch64-current and slarm64-current). In order for slackpkg(+) to update, it needs the time and date to be correct. Also, it needs the network to be connected.

On x86_64, I can boot straight into a command line environment and run the usual slackpkg commands to update my system as required. On the Pi, I have to log in as a user first in order to 1) establish a network connection and 2) get the correct system time. Then I have to kill the Xserver (ctl-alt-backspace), get back to a command line (ctl-alt-F1), login as root in order to update.

As I say, not a big problem, and I accept I am nit-picking here, but why does the Pi behave differently from x86_64 with the same network manager? Have I missed something in the configuration somewhere?

I appreciate that I could probably bypass this issue by bringing up the network the old fashioned way, without networkmanager. But one of the beauties of the Pi400 is its small size and portability, which makes moving it around easy. Networkmanager is so much more convenient.

Cheers,

--
Pete

mralk3 · 09-19-2023, 01:45 PM

There are two boxes that need to be checked in the General Tab for your wifi connection in Network Manager. One is "Connect Automatically with priority" set to 0 and the other is "All users may connect to this network".

As an alternative you can use the "nmtui" command without needing to start up the X server. It has a very similar layout to the network manager applet in the X server.

I typically do not use network manager on arm. I configure the network card with /etc/rc.d/rc.inet1.conf and wpa_supplicant.

vi /etc/rc.d/rc.inet1.conf:
(go all the way down to the section about wlan0 and uncomment the following variables)

Code:

# Example config information for wlan0:
..snip..
IFNAME[4]="wlan0"
USE_DHCP[4]="yes"
WLAN_WPA[4]="wpa_supplicant"

Then you just have to run two commands as root to have rc.inet1 look for your wifi access point.

Code:

wpa_passphrase <name> <wifi password>  >> /etc/wpa_supplicant.conf
/etc/rc.d/rc.inet1 restart

Finally, this all can be done manually with these commands:

Code:

iwconfig wlan0 essid <name>
wpa_passphrase <name> <wifi password>  >> /etc/wpa_supplicant.conf
wpa_supplicant -i wlan0 -B -c /etc/wpa_supplicant.conf
dhcpcd wlan0

You can list multiple access point names and passwords in /etc/wpa_supplicant.conf and the rc.inet1 and manual method will connect based on what access point is in range with a stronger signal. This I think is a much better solution for systems that are headless or that do not use X.

pchristy · 09-19-2023, 04:38 PM

Hi, mralk3 and thanks for your comprehensive reply!

Yes, I was already aware of those two settings in networkmanager, and they are the same on both my x86_64 and arm64 systems. That's why I'm puzzled that x86_64 starts before the gui, but arm64 doesn't. I'm guessing its something to do with the way arm64 boots, but its a bit above my pay-grade!

I'm also familiar with using rc.inet1 and wpa_supplicant, as I used to use them in the days before networkmanager became reasonably stable - though that was some time ago now! I did try them on my old workshop machine recently, when I started having occasional network issues on that, but it turned out to be the "internet over power-line" adapter I was using in there!

I can live with it as it is. Its just interesting that slarm64 (and sarpi) both behave the same way, so it appears to be something specific to arm - or more likely, the way arm boots - that is the source of the problem.

--
Pete

netcrawl · 09-19-2023, 06:13 PM

Setting "All users may connect to this network" in KDE network settings and an ntpdate command to set the time in /etc/rc.d/rc.local works on my Rpi 4 with SARpi Slackware-current. I run a ycast server on it and it comes up at boot perfectly, time is set, the server functions, no login, no problems.

mralk3 · 09-19-2023, 06:50 PM

I will take a look on my pinebook and compare the behavior to my raspberry pi 3 when I get home later tonight. Unfortunately, my raspberry pi 4 is no longer with us. I had some trouble with the Pi 3 coming up on wifi and it is headless with slackware aarch64.

drmozes · 09-20-2023, 02:35 AM

Quote:

Originally Posted by pchristy

System: Pi 400 running slackwareaarch64-current

This is more of a general question rather than an issue. In addition to my Pi, I also have a few x86_64 machines, and there is a distinct difference in the way networkmanager behaves between the two.

On x86_64, the network connects during boot up, before the login screen appears. On the Pi, the network doesn't connect until a user logs in.

Possibly because the hardware has not been detected or the firmware loaded. If you look at the interface list (ifconfig -a) immediately once the system boots and you can login, the wireless interface may not be present and you need to wait for it to come online.
I've seen that behaviour with the Pinebook Pro a number of times and I just waited for it. You might be able to hurry it along but I never looked into it.

camorri · 09-20-2023, 05:49 AM

This behaviour is not limited to Slackware arm devices. I have 3 laptops, 2 of which are older, and one that is up to date. The older 2 run Slackware 15, the hew one is on current.

The older Compaq shows this behaviour. It has a light on the keyboard for wifi. If I boot it, and don't log in, the light blinks slowly, and I can not reach it on the network. For updateing, I opften will download the latest patches to my main desktop system, and scp the files to the others. The Compaq does not come online until I login. As soom as I do, the keyboard light will blink rapidly and communication is normal.

I have checked the settings mentioned on the general tab, and they are set as described above. So, not sure where that leaves us, other than to say 15.0 can display this behaviour
also.

drmozes · 09-20-2023, 06:09 AM

Quote:

Originally Posted by camorri

This behaviour is not limited to Slackware arm devices. I have 3 laptops, 2 of which are older, and one that is up to date. The older 2 run Slackware 15, the hew one is on current.

The older Compaq shows this behaviour. It has a light on the keyboard for wifi. If I boot it, and don't log in, the light blinks slowly, and I can not reach it on the network. For updateing, I opften will download the latest patches to my main desktop system, and scp the files to the others. The Compaq does not come online until I login. As soom as I do, the keyboard light will blink rapidly and communication is normal.

I have checked the settings mentioned on the general tab, and they are set as described above. So, not sure where that leaves us, other than to say 15.0 can display this behaviour
also.

Thanks for this information - my own x86_64 laptop runs -current and is wired, so I've never noticed.

Possibly the reason for the delayed Wifi could be because the secrets for the WiFi need to be unlocked by the user upon login?

pchristy · 09-20-2023, 08:01 AM

Interesting to hear that camorri has experienced this same thing on x86_64. My main desktop machine, and my older workshop machine are both hard-wired, so I would expect them to come on line pretty much as soon as booting is complete. I have two laptops - and ancient Dell that I was given for spares, but managed to get working (after a fashion!) and a modern Clevo. Both these connect wirelessly to the net, as does the Pi 400.

Both laptops are connected by the time the command prompt appears and disappears, just before the graphical login screen appears. I can immediately go back to a command prompt, login as root and run slackpkg to update the system without waiting. The Pi 400 doesn't - no matter which flavour of Slackware arm I'm running. In each of those, I have to log in as a user before the network connects, and the time is adjusted. If I go back to a command prompt (ctl-alt-F1) and log in as root, it doesn't connect either - even though "all users" is selected. It appears that a login to the graphical UI is required to trigger Networkmanager connecting. But why don't my laptops behave the same way?

I don't know!

FOUND IT!

I had set the password for the wireless network to "Store password for this user - encrypted". Changing it to "Store password for all users - unencrypted" got it to logon immediately!

It was Stuart's comment about the secrets for the wifi that rang a distant bell, and made me check!

I'm the only user for the Pi, and its behind a hardware firewall anyway, so I'm not too worried about the encryption. Phew! Another box ticked!

Thanks to all who have contributed!

--
Pete

pchristy · 09-20-2023, 08:18 AM

FOUND IT!

Stuart's comment about wifi secrets got me thinking, and when I looked at the networkmanager settings, I had set the password security to "Just this user - encrypted". Changing it to "All users - unencrypted" solved the puzzle, and it now logs into the network without having to login as a user first!

I'm behind a hardware firewall, and in a relatively rural location, so the security implications are fairly minor. Your mileage may vary!

Thanks to all who have contributed, and to Stuart for inspiring the "Eureka!" moment!

Sorry about the double post! The system did something strange whilst I was editing my post, and I thought it had been lost!

--
Pete

camorri · 09-20-2023, 01:35 PM

pchristy, Thank-you for finding the problem.

I had a look at the 15.0 system with this behavior. I run XFCE on it, and could not find ( in XFCE ) a setting for storing passwords encrypted or un-encrypted. I had to select KDE Settings, and there it was. Changed it, and verified the wifi connection comes up without logging a user in.