This way to NetworkManager awesome... (via pursuethepassion, CC BY-NC-SA 2.0)
And doesn’t it feel good, too. Yeah! There’s a crapton of great fixes in NetworkManager 0.8.4, and just for you, beta1 is here. Changes for NM itself include:
Logging fixes to suppress unnecessary messages
Fix potential 64-bit crash updating timestamps
IPv6 setup, routing, and compliance fixes
Handle reverse DNS lookups with local caching nameserver configurations
No longer updates /etc/hosts when hostname changes
Request WPAD option from DHCP servers
Shutdown crash fixes
nmcli support for WWAN connections
Persistent hostname sent to DHCP servers by default
Allow disabing PPP support at build time
Memory leak fixes
while on the applet and editor side:
Updated translations
Conversion to GtkBuilder
Fixes for newer libnotify versions
Allow MD5 as a wired 802.1x EAP method
Show IPv6 information in Connection Information dialog
Completely fix crashes due to missing icons
Make VPN notifications respect user’s “Enable Notifications” preference
That’s the question both you and Justin Bieber want to know. We’ve had the 0.9 train kicked into high gear since long before Lady Gaga even thought about eggs, and it’s getting damn near the station. Giovanni Campagna nailed the GObject Introspection support and is making the GNOME Shell indicator his bitch, while Richard Hughes is all over the new control center applet. On the Ubuntu side, Matt Trudel posted a Unity indicator patch for the applet which will hit soon. It’s shaping up to be an epic release. When?
And where did every single one of those Gs come from? WiMAX of course. If you’re one of the 13 million WiMAX users or you pack an EVO 4G you know about WiMAX, but you might still be interested to know some how every one of those mind-blowing Gs showed up in your life. Yeah, there’s LTE too, and we’ll save that for another post as the networks and hardware are both quite new.
History to the MAX
Home, office, park, wherever... (credit: Intel)
The WiMAX committees got organized when your desktop looked like this or maybe even this. Seriously, that’s a GIF file and the dude is playing a MUSH. Yeah that’s right, around the time you were totally into Backstreet and there were only 1 or 2 Gs playing with your heart, not 4. Its rise to popularity began in 2005 with Mobile WiMAX (IEEE 802.16e-2005), a set of enhancements that allowed roaming and hand-off between base stations on the network. That’s when WiMAX became a viable cellular technology instead of one just for “Last Mile” wireless Internet access. While WiMAX is deployed by more than 200 operators, most people know it through Clear, Sprint, or Yota. Nokia even built WiMAX into the n810 two years ago (then canceled it 2 months later and pretended it didn’t exist). But in late 2008 (when your desktop may have looked like this) you could easily get Mobile WiMAX on your laptop thanks to…
Halfway to Open-Source Nirvana
The 5150 and 5350 WiFi/WiMAX combo cards (credit: Intel)
Intel! Around then Intel busted out the 5150 and 5350 WiFi/WiMAX combo cards, letting you connect to 802.11n WiFi and WiMAX networks all using the same cheap add-in module. Tons of laptops started offering WiMAX as a build-to-order option. It costs about $40 to add WiMAX, without a contract commitment; contrast that to the couple hundred dollars a good 3G dongle costs in many countries. Not a Huawei or ZTE prepaid thing from 3UK, but a solid well-built-and-engineered Sierra, Novatel, Option, or Ericsson part.
Amazingly, long before the devices actually shipped Intel’s Inaky Perez-Gonzalez pushed the WiMAX driver for these cards into the kernel. The firmware was reasonably licensed too! Rock on Intel. But… the userspace parts necessary for performing authentication with the WiMAX network were a closed, binary-only hacked up copy of wpa_supplicant. Worse, it was 32-bit only, and since it was closed you couldn’t rebuild it natively for 64-bit systems. Yet worse, the code is complete crap and includes re-implementations of lists, queues, and crypto. But at least it existed.
After almost two years of whining from me and others, Intel finally rewrote the binary pieces and in June 2010 released the public, open authentication code, giving us a completely open and re-distributable WiMAX stack for Intel devices. I did half of the 64-bit architecture port last fall, and the other half was recently completed by other rocking devs. As of 2011, the full Intel WiMAX stack works on 32 and 64-bit x86-compatible machines. Big-endian support is in-progress.
Fashionably Late to the 4G Party but still Smoking Hot
Since I’ve been paying $45 a month to Clear for over a year, and my USB dongle decided to commit suicide, I spent some of the holidays finishing up the NetworkManager WiMAX support that Tambet Ingo started. Then I merged it to master because it worked and you know, that’s what we care about. NM 0.9 will ship with full support for Intel WiMAX devices. And it looks like this:
I see 4G
Just pick a network. Or maybe you’re already connected because NetworkManager did the right thing. It’s really that simple. The applet’s Connection Information dialog shows all the details, including dynamically updating signal strength and the connected base station ID:
I love me some CINR and BSID
Since everyone loves the command line, we’ve got nmcli and nm-tool support as well. You don’t ever have to leave the terminal. You even get more information via the terminal than you do the applet, because we know that’s what you like. If you were ever interested in the center frequency your WiMAX card is using, you’ll think these pics are hot:
Don't you just love 100%?
So it’s almost all there. Yeah, there’s a bit of the connection editor to finish up, but that’s not hard and it’ll get done. But Intel devices aren’t the only ones out there, and not everyone can grab a 5350 and drop it into their machine.
Half Tragedy, Half Drama
Dongles Galore
Most external WiMAX USB devices sold in the US are based on the Beceem BCS250 chipset. For a long time the open-source community had nothing, but after almost two years of hiding in the shadows we’ve got a driver: Stephen Hemminger somehow found it and pushed it to Greg as a staging driver late last year. But it’s still ugly, needs help and cleanup, and ideally the Intel wimax network service can be modified to work with these devices so we don’t have to run different userspace daemons for different hardware. If you’re willing to help, most of these devices go for about $30 on Ebay.
Next Up
We’ll chat about LTE and the fun that is the Pantech UML290. It’s great. Really. Unless you’re a developer or a user, which is most of us. Just because it’s fast doesn’t mean it’s a pleasure to work with. Whee!
Thanks to Jason Clinton, I’ve had a T-Mobile WebConnect Rocket 2.0 stick for the past 2 months. Since he wants it back and I’ve been sitting on it for far too long, I spent some time over the past week making it work in ModemManager. It’s a ZTE made device that contains an Icera chipset, which is interesting for a number of reasons. First, it’s not a Qualcomm device; Icera is a fairly new company and that doesn’t happen often in the mobile broadband chipset industry. Option used an Icera chipset in the AT&T USBConnect Quicksilver HSUPA modem back in 2009 but with a customized AT command set. At least a few other devices are out there in the wild.
Second, the device continues the trend of pseudo-ethernet interfaces instead of PPP for data transfer. This is a good thing. And what’s even better is the device uses standard CDC-ACM and CDC-ETH interfaces, so no special drivers are required beyond initial mode-switching. I honestly don’t understand why companies create random new protocols and vendor-specific USB interfaces for their devices. It clearly takes engineering time, addition R&D money, and results in slower time-to-market. Why is that a win? Why not save time and money by using standard stuff?
In any case, the ZTE MF651 also appears to contain an Icera chipset. If anyone has this device, I’d love to see if it works with current ModemManager git master, and if it doesn’t, please send me debug logs so I can fix things up.
PS: Jason, your Rocket 2.0 should be on it’s way Monday. Thanks again!
Raise 'em up really high (stina jonsson, cc-by-nc-2.0)
So I’ll bet you thought touching a simple little file would be simple and a little code right? So very wrong. This is Linux we’re talking about, and if this stuff was simple, we’d already be enjoying our gin peartinis on the white sand beaches of St. Maarten with the latest dead tree from Johanna Lindsey.
See, your hostname needs to map to an IP address assigned to your computer, otherwise stuff gets angry. Like X11, unless you have this hack. Or quite a fewotherthings are broken enough to look up the hostname to determine the machine’s IP address. If your hostname isn’t in /etc/hosts, and it isn’t resolvable by DNS, or if DNS is down, or if your network cable got unplugged, or if it doesn’t map to an address assigned to your machine, or if /etc/resolv.conf isn’t set up right, this stuff just breaks. That’s a lot of ifs.
Bad Touch
So since mid-2008, NetworkManager has tried to keep /etc/hosts updated with your current hostname, and since earlier this year, to map the current hostname to your default interface’s IP address. Despite having 31 unit tests and fixing a bunch of bugs the code still doesn’t make everyone happy. The Debian people want the hostname mapped to 127.0.1.1 not 127.0.0.1 (Fedora) or 127.0.0.2 (old Debian). Which is fine. Other people get touchy when stuff changes even if their special changes get preserved. That’s also fine. Others want to let DNS handle the hostname resolution even though that creates 3 more ways your machine can inexplicably hang. And I’m tired of piling hacks on top of code that’s already really ugly and complicated. Thank God for unit tests.
Good Touch
So here’s what we’re going to do. After a third-quarter huddle with my linebackers, we’ll be removing all the code in NetworkManager that touches /etc/hosts. Gone are the bits that add your hostname. Gone are the bits that remove your old hostname if it changes. You now have all the rings of power. Distros should use the “recommends” functionality of their package system to install nss-myhostname, which ensures that your hostname is always resolvable to a local IP address. And if for some reason you don’t like that, you can uninstall it and keep /etc/hosts all to yourself. Everyone wins!
And the best part? I get to delete code. I just love doing that.
Huge congratulations to everyone on the release of Fedora 14. It’s amazing to be part of a community full of energetic and passionate people, who care about getting free software into the hands of millions. Hell, even pumpkins get Fedora for Halloween. That thing blows my mind. But since 11 is no longer enough, people are gonna crank the party up to 14 literallyallovertheglobe. So maybe you should too. If you can’t yet hear the party outside already, join the fun by grabbing the latest smokin’ hot images. You like KDE? This spin’s for you. You live on the lighter side? All yours.
♦ ♦ ♦
But while everyone rides the 14 high we’re sprinting the home stretch towards GNOME 3.0 and Fedora 15. It’s the most exciting change for the desktop since the GNOME design team began snorting lines of awesome off candy coated rainbows and the Spice Girls had a Top 40 record. You’ll love it. You know your mom does. She told me so.
We periodically get mails and feature requests for making NetworkManager play better with a local caching nameserver. Why would you want to run one, you ask? Simple: speed, latency, and split DNS. Of these, the first two are the most important. It turns out that DNS service on many ISPs just sucks. Besides returning utterly useless yet supposedly “helpful” web pages for non-existent domains that you simply mistyped, they are often just glacially slow. A huge shout out to Qwest in Portland making the Interwebs last year feel like getting all my fingernails gradually pulled off with a pair of red-hot pliers. I can’t update my Facebooks and browse my collegehumor with lookups that take a second or two. Especially on high latency connections like 3G or satellite running a local caching nameserver makes things considerably snappier.
dnsmasq makes it trivially easy. You can do it with BIND too, but like everything involving BIND, it’s certainly not trivially easy. We actually tried this about 3 or 4 years ago with NetworkManager 0.6 but it just wasn’t time yet and the implementation wasn’t that great. Oh yeah, there’s also DNSSEC which various people want to deploy.
Here’s How It’s Gonna Be
Cue fully-integrated, seamless local caching nameserver support for NetworkManager 0.8.2. If you have dnsmasq installed and set the “dns=dnsmasq” key in your /etc/NetworkManager/NetworkManager.conf file then you’re all set. Distros can enable this by default, which we’ll be doing in Fedora 15 and later. Now you’ll get a local caching nameserver that will also do split DNS when you’re connected to a VPN, so that queries for resources on the secure network go to the VPN nameservers, and everything else goes to your upstream ISP. And the results get cached for speed. This already works great with dnsmasq, but there are still a few issues with the BIND plugin that mean it’s not quite ready yet.
Plus, it’s a plugin-style architecture so it’s easy to create new plugins for services that might want to be aware of your network connection’s DNS servers for prefetching or whatever. Or if djbdns floats your boat, make a plugin! It’s pretty simple.
You’re a Fine Piece of Real-Estate
Which brings us to a 0.8.2 release. In keeping with the goal of speeding up minor point releases we’re going to push out a 0.8.2 really, really soon. We’ve spent a ton of time on polish and bug fixing and everyone should get a piece of the action. Then, we’ll start concentrating more heavily on NM 0.9 and pushing the architecture forward while simplifying the API dramatically, all in preparation for an awesome GNOME 3.
Whoever said networking was boring? Actually, I hope it is boring for users, so boring in fact that they can ignore it completely, get on with their life, and accomplish all sorts of magical things. But enabling that magic is never dull, and it’s never done. There’s always a new technology or device to enable, more configurations to cover, and changing usage patterns to adapt to. And another giant leap along that road is…
NetworkManager 0.8.1
… which we released a few days ago. Tarballs are in the usualplaces. Hit up the packages for Fedora, Debian, and Ubuntu. This release is the culmination of a ton more effort than just the minor version bump signifies, and a huge thanks goes out to everyone involved in the features, code, and testing. As always, this release nails the top feature request and piles in a bit of something for everyone else.
Bluetooth Dialup Networking (DUN) – the #1 user requested feature; you set it up just like Bluetooth PAN except you check a different box at the end
nmcli – a command-line interface to almost everything NM does
Mobile Broadband Status – signal strength, roaming, carrier name, and access technology shown for your convenience
Enhanced IPv6 support – with better DHCPv6 and tons of fixes to IPv6 operation
Logging and debugging – log verbosity and domains are now highly granular; make NM as quiet or verbose as you desire
Overall we’ve had 650 commits, 80 bugs fixed, and almost 20,000 lines of code changed since 0.8. That’s a ton of great stuff. And we’ll continue to land yet more great stuff in 0.8.2. Let us know what you want!
Next Stop: Simplification 0.9
We’ve decided the benefits of user settings are outweighed by the simplicity of having all your configuration stored and managed by the core daemon. So Daniel Gnoutcheff is spearheading the effort to kill user settings as a Google Summer of Code project, and he’s kicking major ass. We’re reworking NetworkManager into the one-stop-shop for all your configuration needs, making it radically simpler to create custom user interfaces for controlling and configuring your network, enabling great fast user switching and finer-grained administration. It makes NetworkManager smaller, faster, and easier to interact with. We’re going to base a great GNOME Shell network experience off this architecture and make KDE and XFCE developers’ lives easier at the same time.
This is a huge effort, and best of all should get rid of way more code than it adds. I love waking up to the smell of freshly killed code even if I wrote it. I don’t think I can understate how much easier it’ll be to talk to, work with, and understand NetworkManager when this is done. It’s gonna be great. Even magical.
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:
OpenVPN manpage from 2.1-rc15 before they switched to "openvpn ( options ... )". That's a 1000px terminal too.
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[666]: <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.
Then you’re forgiven for not knowing that Fedora 13 just busted outa tha cage and unleashed itself upon the world. Far from being the worstnumb3rev4r, for Fedora 13 is a greatfrickin’way to get your work done and build something worthwhile. We stuffed tons of awesome into this release, like better printing and webcam support, actual color management, great mobile broadbandexperience, out-of-the-box 3D graphics on all major hardware, and much more.
