Archive for the ‘NetworkManager’ Category

NetworkManager 0.9, Pidgin, and tinc

Tuesday, May 24th, 2011


As a reply to Andrew’s comments about NM 0.9 and Pidgin, I wrote patches a while back of which one got commited and a second is pending.

tinc and VPN plugins

Andrew also talked about tinc and how he’d love if it had NetworkManager integration.

NetworkManager expects quite a bit out of VPN services; they cannot simply be dumb services that expect everything to be statically configured for every user on the system.  Why?  Because NetworkManager allows many different configurations of VPN setttings; you might have one VPN for your cover-story workplace and one for your Secret Three Letter Agency that you only use in secure locations.  That configuration is stored in NM config files in /etc and includes not just VPN-specific configuration, but also IPv4 and IPv6 configuration, static routes, DNS and search domain information, and a human-readable name and connection UUID.  This allows the user to override configuration the VPN might automatically return.  In the future we’ll add proxy configuration and firewall rules to that list.  Because all these things are highly specific to a single network connection (be that VPN, wifi, wired, 3G, whatever), they need to be kept together, changed together, and applied together.  No existing VPN configuration file format supports all this.  But NetworkManager does.

This means that we cannot simply use /etc/openvpn.conf or /etc/tinc/tinc.conf because

  1. standard config files often contain only one network: they are essentially “public” configuration files and the concept falls apart if you have ever configured more than one VPN; while some VPN daemons do have formats that allow defining more than one network, many do not.
  2. config files cannot encode related connection information: there is often no facility for expanded network-specific configuration like proxies, firewall rules, additional IP addresses, static routes, DNS search domains, etc that should be associated with VPN connection.
  3. secrets should be stored securely: if the user wants secure password storage in the GNOME Keyring or KWallet or whatever, they should be able to do so.  The user should be able to keep the password in their session or even provide it on-demand and not require it to be stored in system configuration files.
  4. secrets can change periodically: at Red Hat we use RSA SecurID tokens that generate a new PIN code every 30 seconds which is entered every time we connect.  Many VPN daemons will ask for passwords too, but that requires a terminal.  Fail.  We want to ask for secrets in a generic manner which is appropriate to each desktop environment (or lack thereof), and existing VPN secret request mechanisms (stdin, TCP management socket, static config files, etc) simply do not allow this.

To work around these limitations of configuration files, NetworkManager dynamically generates configuration for each VPN daemon and inserts your password when required, retrieved from secure GNOME Keyring/KWallet storage or from a PIN entry dialog or other mechanism.  The VPN daemon is then executed and handed that configuration, either a path to a private, root-owned, transient configuration file or, even better cleanly written to stdin if the VPN daemon supports it.

Which leads me to tinc.  Nothing appears to preclude creation of  NetworkManager VPN plugin for tinc, but there are some complications that it would be great to get fixed upstream:

  • quite a few configuration files required for each VPN network, and a plugin would have to create all these files dynamically before executing tincd; it appears that tinc 1.0.14 allows arbitrary config options on the command-line, which helps somewhat, but even better would be accepting configuration on stdin as a single unit instead of a bunch of separate files.  This way no config files (possibly including secrets) might mistakenly get left lying around due to segfaults or programming errors.
  • configuration appears to require an explicit device name (like “tun0″) which is a huge no-no; if the program can’t dynamically determine a suitable device name and return that to the caller, it gets a F- grade from me.  If the user configures more than one VPN that they might use concurrently, they shouldn’t have to manually plan out interface names.  At least it appears that tinc sends the interface name to the “up” script in the INTERFACE environment variable.
  • like OpenVPN, it appears that many attributes of the VPN connection cannot be auto-detected, which requires the user to know a-priori what the VPN configuration will be.  Stuff like “Cipher”, “Compression”, “Digest”, etc.  This never helps users and apparently everybody writing VPN software thinks the user of their software is already a system administrator.  I hope I’m wrong about this.  If I’m not, hopefully tinc emits status information indicating that the parameters set in configuration are incompatible with the peers it’s trying to connect to such that we can notify the user about it.
  • it’s unclear to me how tinc reports status and progress in a usable manner; it appears that one can send signals to tincd, but they dump information to syslog.  Ideally tincd would include an option to dump this information to stdout as well, because screen-scraping syslog is just completely evil.

None of these issues are killers; but they simply result in a degraded experience for the user of tincd if that user is not a system administrator.  At this point vpnc is the best-behaved VPN daemon because it (a) accepts configuration on stdin, (b) can request secrets dynamically via stdin, (c) automatically negotiates most options with the peer, and (d) doesn’t have 50,000 configuration options with complex interdependencies.  I hope tinc can get there too.

If anyone wants to write a NetworkManager VPN plugin for tinc, definitely let  me know or jump onto the mailing list and we’d be glad to help out with suggestions and advice.

NetworkManager 0.8.4 Knows How To Party

Thursday, April 21st, 2011

Get on up, get on up and DANCE (CC BY 2.0 via Robert Bejil)

Next in the long line of illustrious NetworkManager releases, out comes 0.8.4.  It loves to party, and if you look close enough it’s busting a move just to the left of the dude with a star on his hat at its own release party.  Hell yeah.  It’s a great release and packs a lot of fixes and features, including but not limited to fixes for IPv6, DHCP, DNS, no  longer touching /etc/hosts, WWAN, and VPN.  Hot tarballs are here:

A huge thanks to everyone who helped out with this release: Jirí Klimeš, Michael Biebl, Mathieu Trudel-Lapierre, Ozan Ça?layan, Robby Workman, Mu Qiao, Pierre Ossman, Mikhail Efremov, Andrey Borzenkov, Karsten Hopp, Ionut Biru, Robert Piasek, Torsten Spindler, Richard Hughes, Radek Vykydal, Canek Peláez Valdés, Wulf C. Krueger, and anyone I’ve forgotten.

Now back to the 0.9 train.  Shake it hard and keep it rockin’ people.

Read This: RAE Vodafone Lecture Series

Tuesday, April 19th, 2011

If you’re at all interested in wireless technology, you should read this.  The first lecture (from 2005) starts with a very approachable history of [W]CDMA and cellular technology, including some of the process that went into the technology.  About the only way you can a record of the decisions, trade-offs, and design choices that went into technology these days is by being part of the working group or reading comments in IEEE discussions.  That’s incredibly boring.  The first lecture, on the other hand, is straight from the source.

Choice quote from Dr. Jacobs, and remember that at the time (2006) George W. Bush was president:

I was with the President of China about three years ago, we sat next to each other to do the informal chatting before the formal part started, and his first question was how many more generations did I think that Moore’s Law had to run. I don’t think the President of the US would have asked that!

– Dr. Irwin Jacobs (co-founder of Qualcomm)

(would Sarah Palin ask that if she were President?  Hell no.  She doesn’t know what actual laws are, let alone Moore’s Law…)  But forget about Palin for a moment, this quote reminds me of a Forbes article I saw a while ago:

In China, eight of the top nine political posts are held by engineers. In the U.S., almost no engineers or scientists are engaged in high-level politics, and there is a virtual absence of engineers in our public policy debates.

Yay for America.  Our politicians and our aspiring politicians suck.  But this post isn’t about China or the US, it’s about a Royal Academy of Arts lecture.  Go read that thing.

NetworkManager 0.8.4-beta1 Gets All Up In There

Thursday, February 24th, 2011

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

There’s literally a mountain of tarballs for your networking pleasure.  And there’s fresh updates for both Fedora 13 and Fedora 14 to satisfy yo mama.

And what about 0.9?  Huh?

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?

March 16.

Let’s do this.

I’ll Take All 4 Gs

Thursday, January 20th, 2011

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!

ModemManager and ZTE Icera-based devices

Saturday, January 1st, 2011

The T-Mobile WebConnect Rocket 2.0

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!

Good Touch, Bad Touch: /etc/hosts

Thursday, December 16th, 2010

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 few other things 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 not (Fedora) or (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.

Fedora 14 : F is the new Amazing

Thursday, November 4th, 2010

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 literally all over the globe.  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.

Don’t Try to Run, Honey

Thursday, September 23rd, 2010

Excuse me sir! Which way to the DNS?

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.

Determination That Is Incorruptible

Monday, August 2nd, 2010

Networking is never done... (via earthkath)

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