Face transplants are the new Botox

When we were adding multiple active device support to NetworkManager 0.7,  Bryan Clark and Mike Langlie redesigned much of the applet and kicked out some great mock-ups.  Turns out GtkMenu doesn’t work well for multiple connections or multiple active devices.  While it’s served us well, the applet’s GtkMenu-based code should be sent to the slaughterhouse and rendered down into tasty, tasty animal fat.  Even though the new design work was done in January 2008, I only blogged about the mock-ups in June last year because I suck.  I’ve had them sitting in my inbox for 18 months, because between getting NM 0.7 out, mobile broadband, and all the rest of the awesomeness that 0.7.1 brought, there hasn’t been any time to sit down and actually do the redesign.  But that shouldn’t stop discussions about how excellent nm-applet can become.

In the Operating Room

Ignore the title bar. These are old; we don’t want a title-bar any more.  Instead, just a custom widget like the Volume applet.  So here you go:


The user has an active wired connection, and an inactive wireless device.  Note that only your favorite wifi networks (ie, ones you’ve explicitly connected to before) appear in the list.  People often see 10 or 20 wifi networks, and list all those in the menu is mostly useless.  There’s a tradeoff between the easy first-time wifi network discovery, which would now take one more click (of “Show”), but only listing the networks you actually use makes the UI a lot cleaner.  And nicer for netbooks.  The new design also shows more relevant detail, like security settings, in plain language.


Here the user has connected to a favorite network, and the wired interface is now inactive.  Grouping the security information, the SSID, and the actions the user can perform gives a certain focus the old applet could not.  Irrelevant information simply doesn’t show up.


If you’ve used a VPN with this network before (or tied it to the wifi network) it should probably show up too.  This part needs more thought, because VPNs are really independent of the underlying network connection, but often should be “tied” them to a specific connection or two.  But what it gets right is to group the things you probably want to do near each other.


So what if you do want to see everything?  Well, hit the “Show” button and you get the list of course.  We can probably do better than a scrollbar here, but whatever; they’re mockups.  Maybe we can be more intelligent about scanning too.

An Updated Face for 2009

2008 is not 2009.  And that’s why Jon McCann and I sat down a few weeks ago and worked through things people care about now.  Hot off the whiteboard after a trip through the Gimp:

mccanImmediately you’ll notice the strong resemblance Bryan and Mike’s work from over a year ago.  To their credit, Jon and I think the same core concepts still hold.  We took a look at how mobile broadband would fit in.  We split out the icons to show each device type individually, though this needs more thought too, since you don’t care that much what your wifi signal strength is when you’re on 3G.  But you do care how good your 3G is when it’s not connected, since you want to know whether you can even hop onto 3G or not in the first place.  Thoughts?  Comments?  Flames?

Windows 7++?

Much to our surprise, Windows 7 looks a lot like what Bryan and Mike sketched out over 18 months ago.  Sooo ahead of their time.  Yeah, the coloring is different, and yeah it’s got a bunch of questionable Microsoft bling, but Windows 7’s network applet looks and feels a lot like the nm-applet mockups from January 2008.  But I think we can do better, by making networking clearer and more concise.  Apple’s Airport applet is probably too minimal, but Microsoft’s is probably too complex.  Somewhere in the middle is where nm-applet was planning to be and should be: get you connected with a minimum of steps, and put what you need in one convenient place.

Everyday Simplicity

Sounds like something Martha Stewart would sell at K-Mart, but it’s what software should aim for.  Let the users do what they came to do, then get the hell out of the way and let them do it.  Don’t show options that the users don’t need on a daily basis, but make them available elsewhere in a click or two.  Keep the interaction streamlined, simple, and clean.  Don’t clutter it up with unnecessary options.  If it’s not used on a daily basis, it probably shouldn’t be seen on a daily basis.  That’s what nm-applet should do.

So let’s make it do that.  Prototyping the concepts in a Python applet would be a great first step.  After being kicked around the court a few times, we implement them in nm-applet.  Debuting NetworkManager 0.8 with a sexy new interface would make your momma proud.  Any takers?

A•B•C Delicious

Hmm, some Internets would be good here...
Hmm, some Internets would be good here...

Sometimes You’re on a Train

And you need some internet.  You know, to giggle over the funny lolcats like a vapid schoolgirl or figure out just what Bobby Love is really up to these days or God forbid, get some actual hacking done.  What’s a person to do?  You could pull out your iPhone, but the guy across the table with the Sierra card says AT&T is shite on this part of the corridor.  Besides, you don’t have an iPhone, and the iPhone can’t tether anyway.  Useless.  Or, you could pull out your T-Mobile G1 Googlephone and make rlove proud.  Oh wait, it can’t tether either.  Nice try.

You could get out your cable and hook up a real phone that can tether, like most other phones on the planet besides the iPhone and the G1.  But then again…

Wires Suck

That’s where Bluetooth tethering comes in.  There’s a few reasons Bluetooth support hadn’t yet got into NetworkManager, mostly related to lack of time and good planning of the user experience.  Bastien and I talked over a lot of it last summer in Portland and came up with a strategy, which was spelled out in various places, but nobody really followed it through.  Bluetooth support can’t just be a hack; it shouldn’t be “Type your modem device name here”-style fail; it should be well-integrated into the desktop experience.  And that requires doing the right things in the right places.  The first step towards that goal was ModemManager, which pulls all the modem code out of NetworkManager into a nicely architected daemon that abstracts the hardware differences.  The next step was making NetworkManager talk to Bluez.

But Bluetooth Kicks Ass

Since Bastien apparently had nothing better to do, and since his favorite team was probably losing as hard as only they can and thus pointless to watch, he showed up with a pile of patches adding Bluetooth bits to NetworkManager.  At the end of the week, we’d got core Bluetooth PAN working pretty well on master, while DUN has to wait a bit until some ModemManager issues get sorted out.  Next up is creating the seamless Bluetooth desktop experience from pair to air by adding the necessary bits to the applet and connection editor.  But the heavy lifting on the NetworkManager side is mostly done.  Thanks to Bastien, NetworkManager 0.8 will ship with native Bluetooth support that doesn’t suck.

I was told there’d be cookies?

Oooh how cute...  Look at my laté!
Oooh how cute... Look at my laté!

Land of Confusion

Since NetworkManager 0.7 came out, there’s one issue that’s been causing confusion with lots of users: hashed network keys.  That passphrase you type into the box when you connect to a WiFi network using any OS isn’t what actually gets used; instead it’s hashed to come up with the real key.  There are a few different ways to enter an encryption key for a WiFi network, so bear with me:

  • Hex: works with both WEP and WPA, and is the most compatible since it actually is exactly what gets sent to the driver as the encryption key.  For WEP, this is either a 10 character (for 40-bit WEP) or a 26 character (for 104-bit WEP) string composed of hexadecimal characters.  For WPA it’s a 64 character hexadecimal string.  Typing in 64 hexadecimal characters gets old pretty fast, which leads us to…
  • Passphrase: a string of arbitrary characters that is hashed into the actual key to be used.  WEP passphrases have no real size restrictions, and are repeated into a 64-byte buffer before being hashed with MD5.  At least the creators of WPA learned from experience, specifying that WPA passphrases are between 8 and 63 characters inclusive, which means you can actually autodetect whether it’s a passphrase or a hex key, unlike WEP passphrases.  WPA passphrases are hashed using SHA-1 into the real encryption key.
  • ASCII key: Thanks, Lucent.  The original WaveLAN cards used passphrases of 5 or 13 ASCII characters, which some drivers and people still use for God knows what reason.  To hash it, take the two-byte ASCII value of each character and stuff them into a buffer.  Not secure at all.
  • Apple passwords: in their infinite wisdom, Apple chose a completely different hashing mechanism for WEP.  This means that to connect a non-Apple computer to an Airport WEP network, you need the “Compatible Network Password”, ie the hexadecimal WEP key.  At least they stuck with the standard for WPA.

The huge pain with WEP is that you simply cannot autodetect what type of key the user has entered.  Since WEP passphrases can also be composed of 10 or 26 hexadecimal characters, it’s impossible to differentiate between a WEP hex key, a WEP passphrase, or a WEP 104-bit ASCII key.  Which means the user has to know what WEP key type they are using.  FAIL.  They also have to know whether the network uses 40-bit or 104-bit encryption, and whether it uses Shared Key authentication or Open System authentication.  That’s 12 different possible WEP configurations.


In any case, NetworkManager 0.7 required pre-hashed keys for reasons I don’t accurately remember, possibly related to bad trips from the NM 0.6 API that I mis-designed.  So the applet hashed your passphrase right after you entered it and stored the hashed key in the keyring.  Unfortunately, when the driver failed to connect and NetworkManager asked for your secrets again, all you saw was something you certainly don’t remember typing in.  While this actually was your passphrase, and it would work when you hit OK, it certainly was confusing.

Change We Can Believe In

As of Saturday, you’ll always see what you typed in.  The real fix is to simply connect the first time and never ask for your passphrase again, but that’s almost always due to driver and supplicant bugs that can and should be fixed; I’ve spent weeks of my life doing just that.  Of course, that can only reliably happen in open-source drivers; at least when we find the bugs we can fix them.  Which is why you really don’t want any of these.