It took about a decade for NetworkManager to gain CLI, all the time it tried to eat more and more control over network stack. It was also opinionated in the worst possible way, like responding to requests to support ad-hoc wifi mode (back when NM was only about WiFi) with "your request is dumb, you're dumb, and we will never do that".
It got usable within last few years as somewhat general thing (after having already wrestled control over network from you first), of course by the time it got useful work started on replacing it with new thing.
Wish that 2005-me was interested in keeping the citation, but I strongly remember it because I was dealing with first WiFi-enabled device at home at the time - and ad-hoc was the only form of network connectivity for me for a long time.
At the time, NetworkManager was gaining steam as "the" solution to wifi woes, and well, I tasted dirt ;)
NetworkManager was literally just a GUI initially, wasn't it? IIRC in 2006, connecting to wifi from the CLI on a system with NetworkManager involved running the wpa_supplicant commands that NetworkManager wrapped.
It already had beginnings of current architecture, but at the time it only wrapped iwconfig and wpa_supplicant, yes.
But the decision to leave people who asked for ad-hoc support (especially when, outside of USA and possibly few other countries, access points were still not as common equipment) was done by design, not because it would require any significant increase in code (IMO).
This isn't true. It was never as good as Intel's Connman, which was designed to be modular from the start. NetworkManager started out as a UI app and then was evolved into what it is now. It's still not as fast as connecting to WiFi as Connman.
I guess it was adopted instead of Connman because RedHat.
Maybe Intel was not cooperative about Connman. Trying to contribute a patch to Connman was the worst patch contribution experience I've ever had. On the official IRC channel, over several days and times of day, there were only people who could tell me about the developers, but the developers were not there. The bug tracker required writing an e-mail to someone at Intel to open an account. I don't remember details about the mailing list, but if I did write to it I was ignored as well. In the end the patch never went in, I had enough. And yes, the patch made sense. Years later I later saw one that seemed to fix my problem in a similar way.
Connman is better at least insofar that it is less code than NetworkManager and that it connects to a Wifi network in under a second instead of several seconds. But I believe it can also do less, for example regarding VPNs and such.
NM doesn't connect to wifi by itself, it uses wpa supplicant for that. If something is slow, it is wpa supplicant. Fortunately, nm backends are modular and you can use Intel's iwd instead.
A while ago, maybe about a year ago, after upgrading Debian I discovered that I was no longer able to connect to my 5GHz wifi network, but could connect to 2.4GHz networks. Switching from NM to wicd fixed the problem. Same kernel, same wifi card and driver, same wifi AP with the same configuration. As baffling as it seems, getting rid of NM was the only thing I had to do, or could do, to make it work again. NM is now dead to me.
Or systemd? I've read about complaints regarding it but never had any issues myself on the many dozens of servers that I've managed. On the contrary I find systemd very easy to work with.
That's a workaround, not a a fix and might break applications which legitimately need more time to stop!
A proper fix is to integrate startup and shutdown of all applications with systemd. That's something not properly supported everywhere yet. For example for KDE that's currently in the works: https://blog.davidedmundson.co.uk/blog/plasma-and-the-system...
it took me about 10-15 minutes to turn my eyes towards SELinux, after some initial debugging.
i turned off selinux temporarily and activated the connection successfully, and determined that it was indeed SELinux that was preventing NetworkManager from doing its job.
then i re-enabled SELinux went to look at /var/log/audit/audit.log to see what it had to complain about and indeed some files created by NetworkManager in /root/.cert had bad contexts.
I set the proper contexts (semanage fcontext -a -t <context> <pathregex>), applied them (restorecon -Rv /root) and all was well.
I had to study this stuff in order to get Red Hat certified (RHCSA, passed with 300/300).
Getting certified is absolutely worth it. Getting certified is the difference between "10-15 minutes to get a diagnosis" and "I gave up on SELinux about 20 years ago".
You can have SELinux in a learning mode where it gives you a notification when it blocks something, and a command you can run to make it not block that action any more.
selinux is at the heart just about labels. If something tries to do something but doesn't have the right label, selinux will block it.
I agree working with selinux is a bit of a PITA but if you learn sealert, ausearch, and/or audit2allow it can severely reduce the pain and allow you to keep selinux enabled. I really like this page personally: https://wiki.centos.org/HowTos/SELinux
So for example, I applied updates to a set of fedora systems recently.
The updates to network manager decided to change network interface names from looking like enP51p1s0f0 to enP51p1s0f0np0. The rename broke the (also networkmanager) channel bonding configuration, resulting in them being unreachable and requiring a physical visit to get them back online.
Networkmanager adds a lot of automagic, but outside of simple widely used configurations ("laptop with wifi") it causes unpredictable and unreliable behaviour.
I especially like the standard fedora server install where the nics present during the install all get DHCP enabled on them, but only those nics. So if you move a network card to another PCI slot after the install it will mysteriously not work. ... I see nothing wrong with not automatically bringing up interfaces on a server, but mysteriously bringing up some and not others makes for mystifying and difficult to diagnose issues that no one seems to know how to fix.
If you are cable-connected and on the edge of your wifi range it will periodically drop your cable connection to check if wifi is good. Not great.
Connecting to wifi takes way longer than without it.
Simple dhcpcd for ethernet + wpa_supplicant with handcoded config work way better.
> it will periodically drop your cable connection to check if wifi is good
I don't know when you encountered that behavior, but NetworkManager has for a long time handled wired and wireless as two independent connections; it just sets routing priority to prefer wired if available. I believe you that you observed that behavior, but to the best of my knowledge this does not match any current behavior of NM.
It got usable within last few years as somewhat general thing (after having already wrestled control over network from you first), of course by the time it got useful work started on replacing it with new thing.