3 ms·

> For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e

by weland 11y ago

> For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e.g. if you think connecting to a Wifi network is problematic, try connecting to a L2TP over IPSec VPN). That's because there is equally no uniform and simple way to connect to use those, either. The problem is that the "simplification" that NetworkManager provides is illusory. Yes, it provides an interface that is easier to access, and all the complexity is moved in the back, where it's handled by NetworkManager. Unfortunately, the mechanisms through which it does that are fiercely complicated, too. I've had NetworkManager break on me countless times (I worked for a company that developed networking equipment for a while, so I've interacted with NM a lot), for a lot of silly things -- making me end up with slightly incorrect configurations or reapplying settings at weird times for no apparent reasons. The end result is anything but simplified: not only do I have to deal with the inherent complexity of a quirky VPN connection -- now I also have to understand how NetworkManager reasons about it and figure out where it's wrong. I also think it's misguided to have a single tool handle things so disparate like VPN and WiFi. It's not like you're ever going to be able to expose those through a unified interface -- NetworkManager's own D-Bus-based API being a prime example of that. > There's also the issue that the simplicity exposed in your example is a little misleading. Will the system persist that command and re-execute it on boot? Will it remember my previously used Wifi networks and connect automatically should I want that? How can I view the available Wifi networks in range? Being able to connect to a Wifi network using a simple ifconfig command is great, but the notion that your 80% of use-cases is the same as everybody else's 80% is misguided at best. You scan for networks with ifconfig <interface> scan. The system will not persist commands (arguably, a good decision) but persisting those settings is pretty easy -- you just add the same parameters you pass to ifconfig in /etc/hostname.<interface name>. (The same parameters as in argv[1:n]). The only thing it won't do out of the box is automatically connect to previously used wifi networks. I suspect none of the OpenBSD developers want that. I only needed a feature like that once, a few months ago when I moved to a new apartment and had no Internet connection of my own (cable company is shit) so I had to snoop from the free wireless of nearby cafes. The fact that the interface to ifconfig is so simple and uniform meant that the whole thing was a ten-line shell script to scan for, and connect to previously known networks, and a shell alias to save the current network to the list of known networks. There's an even easier way, using virtual networks, but I didn't know about it at the time. > So you're saying that xBSD is simpler / better, yet you can't use it on your laptop, as it lacks things you need. Well, no shit. I have a Windows laptop, which I also had when I ran Linux. My day-to-day laptop runs OpenBSD.

xorcist 11y ago
Network Manager still has problems. I've had a lucky streak for a few years where it hasn't given me problems, but the other day the GUI decided not to save my settings anymore. It looks like it does, but it doesn't. If I kill the beast and tap in the commands it just works, but if I run the daemon it keeps feeding the backends with old settings. How do I debug this? There's just sockets and layers of GTK. I'll probably end up doing whatever voodoo I need to keep it away and give it another few years.
- weland 11y ago
  dbus-monitor ( http://dbus.freedesktop.org/doc/dbus-monitor.1.html http://dbus.freedesktop.org/doc/dbus-monitor.1.html ) and a lot of patience are your friends. I know of no other method.
- fragmede 11y ago
  In case you're actually interested in fixing that particular problem, it's probably polkit that's gone bad. To examine the issue further, nm-connection-editor is a separate binary that you can run from the command line, and it'll print errors on stdout - including what it's unable to do.
stsp 11y ago
> The only thing it won't do out of the box is automatically connect to previously used wifi networks. I suspect none of the OpenBSD developers want that. That's not true. OpenBSD developers want this. There are several ideas floating around about making the kernel cache wifi passwords, scan and re-connect automatically when it lost link to the AP. This topic keeps coming up during hackathons. For various reasons it's not as easy to do as one might expect. The net80211 layer and wifi device drivers don't keep track of link state to the AP at present. This would need to be implemented first. It is essentially client-side roaming support. One way of doing this is to count missed beacons and assume the AP is out of range if no beacons have been seen for a while. Some devices provide such counters in hardware, some don't. The biggest part of the challenge is to make this work seamlessly with _every_ driver. Then there's a risk of feature bloat. Add too much automation and you end up with something opaque like network manager which just pisses many people off. Add too little automation and you don't cover many use cases. And networking is not just about wifi, it's at least about ethernet and VPN as well. Some tools already exist to handle aspects of this (e.g. ifstated(8), trunk(4), interface priorities managed with ifconfig(8), a ton of ipsec tooling), and should be properly integrated in the design. Another question is how to integrate with desktop wireless tools that come from Linux (e.g. wifi network pop-up menus for KDE4 and Gnome3) which usually require a backend using Linux-specific ioctls or dbus/NetworkManager/systemd APIs to function. But seamless integration with desktops would be outright awesome and make the system much easier to use for non-technical users. There's probably a couple of gsoc projects worth of work in this. If someone is seriously interested ("no talk without diffs attached" kind of serious) in pursuing this I might be available to act as a mentor.

by weland 11y ago

xorcist 11y ago

Network Manager still has problems. I've had a lucky streak for a few years where it hasn't given me problems, but the other day the GUI decided not to save my settings anymore. It looks like it does, but it doesn't. If I kill the beast and tap in the commands it just works, but if I run the daemon it keeps feeding the backends with old settings. How do I debug this? There's just sockets and layers of GTK. I'll probably end up doing whatever voodoo I need to keep it away and give it another few years.

weland 11y ago
dbus-monitor ( http://dbus.freedesktop.org/doc/dbus-monitor.1.html http://dbus.freedesktop.org/doc/dbus-monitor.1.html ) and a lot of patience are your friends. I know of no other method.
fragmede 11y ago
In case you're actually interested in fixing that particular problem, it's probably polkit that's gone bad. To examine the issue further, nm-connection-editor is a separate binary that you can run from the command line, and it'll print errors on stdout - including what it's unable to do.

stsp 11y ago

> The only thing it won't do out of the box is automatically connect to previously used wifi networks. I suspect none of the OpenBSD developers want that. That's not true. OpenBSD developers want this. There are several ideas floating around about making the kernel cache wifi passwords, scan and re-connect automatically when it lost link to the AP. This topic keeps coming up during hackathons. For various reasons it's not as easy to do as one might expect. The net80211 layer and wifi device drivers don't keep track of link state to the AP at present. This would need to be implemented first. It is essentially client-side roaming support. One way of doing this is to count missed beacons and assume the AP is out of range if no beacons have been seen for a while. Some devices provide such counters in hardware, some don't. The biggest part of the challenge is to make this work seamlessly with _every_ driver. Then there's a risk of feature bloat. Add too much automation and you end up with something opaque like network manager which just pisses many people off. Add too little automation and you don't cover many use cases. And networking is not just about wifi, it's at least about ethernet and VPN as well. Some tools already exist to handle aspects of this (e.g. ifstated(8), trunk(4), interface priorities managed with ifconfig(8), a ton of ipsec tooling), and should be properly integrated in the design. Another question is how to integrate with desktop wireless tools that come from Linux (e.g. wifi network pop-up menus for KDE4 and Gnome3) which usually require a backend using Linux-specific ioctls or dbus/NetworkManager/systemd APIs to function. But seamless integration with desktops would be outright awesome and make the system much easier to use for non-technical users. There's probably a couple of gsoc projects worth of work in this. If someone is seriously interested ("no talk without diffs attached" kind of serious) in pursuing this I might be available to act as a mentor.