Vincent, which specific options do you need that aren’t supported yet? If there are commonly used options that aren’t supported, then we should definitely figure out how to add them, but add them smartly. The large problem is that openvpn’s dev team is absolutely spineless and apparently adds every option anyone ever requests without thinking about how they fit into the larger picture. The larger picture is already huge:
That coupled with the fact that openvpn apparently has no capability to negotiate options with the peer means you have to specify the config exactly as the admin has set it on the server. This is a great recipe for Just Doesn’t Work. People have suggested that we add a GtkEntry or GtkTreeView that you can set to whatever you want, but given that openvpn gets run as root, we still need to validate those options. So why not figure out how to add them in a clear, consistent manner that’s marginally understandable to users?
All that said, there’s a number of options that we do need to add more support for, like HTTP proxy, DHCP over TAP interfaces, etc. Simply adding every single option is a great recipe incomprehensible interaction, so we need to get reports from users about what options are actually used in the wild. Please let us know!
The world only needs a few jackasses and I’d like to think I’m not one of them. So instead of being a jackass and making fun of people who bought the wrong hardware, tonight I’m going to throw a bone to everyone who mistakenly bought a Broadcom WiFi card thinking that Broadcom cares about open-source and that any bugs you had with their binary driver would be fixed in a timely manner.
In a great example of how WEXT is underspecified, the frequency returned from SIOCGIWFREQ has been interpreted to mean one of two things depending on the driver you have. Some drivers report the associated channel, while others report the tuned channel. Of course during a scan the card tunes to a bunch of different channels. So when you hit up SIOCGIWFREQ you have no idea what the card is going to report.
Some configurations use the same BSSID/SSID combination on different bands. Thus we need to know what the associated frequency is so we can match up the exact AP the card’s talking to with an entry in the scan list. Otherwise the scan list doesn’t represent any sort of reality, and that’s not a good thing. If the card reports the tuned frequency when it’s background scanning or finding a better roaming candidate then the match will fail.
Tossing the Bone
What’s the only thing more common than a dual-band single BSSID/SSID network configuration? If you guessed “drivers which make talking to that network hard” then you win a big wet donkey kiss from an ugly goddamn donkey. So in complete violation of my Fix the Stupid Drivers Instead of Hacking Around Them policy I’ve checked a fix into NetworkManager that handles this situation better. If you ever saw:
NetworkManager: <info> (wlan0): roamed from BSSID 11:22:33:44:66 (cakehole) to (none) ((none))
then I just fixed 15% of your problem. You’re welcome. The other 85% is your proprietary driver. The real fix for this is to use the much more capable nl80211/cfg80211 kernel interfaces instead of WEXT. That still doesn’t help all you proprietary driver users out there, because Broadcom pretty much ignores upstream kernel wireless advances. So next time spend another $5 and make your life easier by getting an Intel or Atheros card instead.