Hacker News Reader

While I don't disagree that wpa_supplicant has been spawned from hell, I find it strange that the existence and popularity of NetworkManager is given as a clue for why {Net|Free|Open}BSD is better. You know, connecting to a WPA protected Wifi network is not the only problem users have. 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).

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.

> If I ever need them -- OH THE HORROR AND THE BLASPHEMY -- I have a Windows laptop, which for all intents and purposes is by now about as closed and as hard to wrestle with as Fedora

And therein lies my problem with your entire comment. It's not that I disagree with your usage patterns, but I disagree with your assertions in light of these usage patterns. 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.

> 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.

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.

dbus-monitor ( http://dbus.freedesktop.org/doc/dbus-monitor.1.html ) and a lot of patience are your friends. I know of no other method.

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.

> 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.

I hope my reply didn't come pff as a passive-aggressive "those bastards don't care" or anything like that -- I didn't remember seeing anything about this on the mailing lists, so I just figured out no one wants it. I, for one, can't say I do, for several reasons -- ranging from "I'm a control freak so nothing connects automatically to anything on any computer I own" to "I know of no clean way to implement something like this so maybe we should learn to live without it".

Since it's not something I'm interested in, I probably just forgot that I read about it :).

Thanks for your detailed response.

So what laptop do you use for OpenBSD? I'm running Ubuntu on my main laptop and I tend to search for hardware that's known to work with it.

I'm not the parent commenter, but I personally run OpenBSD on a pretty wide variety of hardware, most recently (among laptops, that is) a PowerBook G4 and a Dell Latitude D830. Most things work out-of-the-box, but there are a few exceptions:

* Power management is nonexistent on PowerPC hardware, so I currently have to shut down my PowerBook between uses, since I can't put it in standby. This is annoying, but workable.

* Hibernation is buggy on the Latitude. Suspend works fine, though.

* Both the PowerBook and the Latitude required the use of fw_update to install nonfree firmware (for the Broadcom-based Airport wireless NIC and the Intel PRO Wireless 3495abg-or-whatever wireless NIC, respectively). Also slightly inconvenient, but - again - still workable.

* Some things don't really work on PowerPC, most notably Firewire. A slight bummer, but hopefully this will be resolved someday.

From what I understand, IBM/Lenovo ThinkPads are - just like they are with GNU/Linux - among the best laptops to use with OpenBSD; IIRC, a lot of the OpenBSD devs dogfood pretty heavily on them, so they get a bit more attention. I'd avoid anything with Nvidia graphics, whereas AMD/ATI or Intel graphics should be decent.

It's an HP 4720s. I didn't buy it on purpose -- it used to be my girlfriend's. When it broke, I gave her my (much tinier) ThinkPad and after I fixed it, we never swapped them back.

I think the only thing that doesn't work out of the box is the weird WiFi adapter that has problems even on Windows. I just use a tiny USB adapter.

I also have OpenBSD installed on my even older laptop, which is an iBook G3. Power management and wifi don't work there but it is 15 year-old hardware, I don't really care.

Watching Linux distros push essential functions into the Desktop layer (power management, network management, etc) without good CLI equivalents limited my window manager choices in the past. This was mostly because the Gnome/desktop folks at RHT were willing to do the work, and there wasn't anyone else to do it, and then that's what happened.

What this did though is pretty much make it where Gnome was the only usable option, or you had to fight a good deal to make something else usable.

as Fedora's desktop choices seem particularly rough, and have pretty much left me with using Linux in VM environments from Macs.

This is very quickly becoming the default for most developers I know, with a few exceptions here and there.

I don't think systemd hurts too bad in the service statup environment once you rememer the commmands are all different, but I don't like what it's doing with creeping into other areas, like what it does with logging.

I don't know about power management, but I've used nmcli for network management without much difficult, and nm-applet works outside of Gnome as well. I've never felt constrained to use Gnome, which is just as well, since I run Awesome launched by "startx".

  $ vim /etc/network/interfaces

  auto wlan0
  iface wlan0 inet dhcp
        wpa-ssid <myssid>
        wpa-psk <passphrase hash>

You can also have multiple virtual interfaces configured in the same file as above, and then just do "ifup wlan0=virtualif" to switch.

Much ado about nothing.

Absolutely. It's also more secure this way, since you aren't putting the passphrase in a readable-by-any-user command line argument.

FYI, it's trivial to hide processes from other users on BSD with a sysctl variable.

I think that's just in FreeBSD, not in others like OpenBSD.

Linux has copied that feature a few years ago, called it "hidepid".

> The way OpenBSD handles WiFi configuration is a good example of this. Want to connect to a wifi network? ifconfig <interface> <ESSID> <passphrase>. If you need some other fancy flags for those 0.1% of hotspots in the world, you can do those, too (also through ifconfig) but it's that simple.

Hmm, I'm surprised OpenBSD supports this, since it will cause the passphrase to get stored in your shell history in plaintext.

I generally run it from a script that then prompts for the passphrase. I'm working on a little tool of my own to work as kind of a minimalist OpenBSD-specific network manager that'll store a list of encrypted passphrases and let me connect to a network without having to enter the passphrase and SSID each time.

This has long been my experience with BSD (back before jumping to OSX for some years, and now back to OpenBSD). There is a willingness to update core pieces of functionality where needed to reduce inessential redundancy.

Another example: console / keyboard config. In OpenBSD, I set this up through wscons. If set here, my keyboard settings get propagated in a robust, non duplicative way to X11. Contrast this with Linux, where you need to set up your keyboard config in at least two places to have, say, Dvorak in X11 and the console.

It's a minor thing, and one that Linux distros "solve" during installation by setting up the relevant configs. But it's more elegant in OpenBSD. Maybe that's because OpenBSD writes documentation that answers questions like, "How do a change my keyboard layout?" In OpenBSD, it's a simple answer. If the situation were the same as Linux, the answer would be longer. Maybe seeing that inessential redundancy in print is what spurs the project to action.

This is indeed annoying; fortunately David Herrmann is working on a new user-space terminal emulator for Linux called KMSCON which uses the same keyboard input code as XOrg (libxkbcommon) so there is hope for improvement.

https://dvdhrm.wordpress.com/2012/12/10/kmscon-introduction/

"is", "new", and "KMSCON" are all erroneous there. (-:

Ok, looking at the recent activity (or the lack thereof) in the github repo lets me be somewhat less enthused... but what's your objection to "KMSCON"?

And "your" and "objection" are erroneous, there. (-: Hint: ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc

:-) Thanks, I totally missed that.

Seriously, we need Prolog infused user interfaces and components. Logic assistant to compose subsystem. Most user facing things are crippled (good thing sometimes) views on it, fuzzy matching, completions etc etc

actually, wpa_supplicant isn't that hard to configure as long as you only use the GUI. just scan for APs, double-click on the network, and type in the PSK. no documentation-reading required.

But I don't want to (just) use it through a GUI, I want to be able to script it. What am I, a connection-making machine :)?

> wpa_supplicant isn't that hard to configure as long as you only use the GUI

Oh, my mistake! I thought I was using a Unix.

I use wpa_supplicant directly on my desktop (running Slackware64 14.1) and have no problem doing so via the command-line and conf file editing alone, though in my case it required adding a snippet to /etc/rc.d/rc.local to get it to connect to my wireless network on boot.

What are some things on OpenBSD that don't work for you?

What sort of hardware are you running?

What about Adobe Flash on OpenBSD?

> What are some things on OpenBSD that don't work for you?

The sort of things that you mentioned -- Skype, Dropbox. I also can't use OpenBSD for PCB layout (Eagle doesn't run on it; don't know about Kicad, but I have very little experience with it), but I don't really mind, because I have access to a licensed installation of Altium at work.

> What sort of hardware are you running?

Nothing special. It's a fairly high horsepower i7 box with 16 GB of RAM. The only component that didn't play nice with OpenBSD was the nVidia graphics card. I just bought a reasonable ATI card and it works fine.

> What about Adobe Flash on OpenBSD?

I haven't used the browser plugin ever since youtube-dl came out, not even on systems where it's well-(ish)-supported. But if you need it in the browser, I think you're pretty much out of luck.