NetworkManager on Server-Type Machines (or, why our initscripts suck)

April 7th, 2010 by dcbw

Thomas: first, you can use NM on simple servers, or you can revert to the ‘network’ service.  But there shouldn’t be anything preventing you from using NM on a server.  We’ve tried hard to expand NM’s capabilities in that direction while still retaining the ease-of-use everyone is accustomed to.

But let’s examine your issue.  NM starts the network asynchronously, while ‘service network’ does not.  That obviously means that by the time the system gets to drbd’s init script, the network may or may not be up yet.  The typical solution to this on Fedora is to set NETWORKWAIT=yes in /etc/sysconfig/network, which causes NM’s initscript to block for 30 seconds or until a network connection is brought up (whichever is first).  Or better, drop a dispatcher script into /etc/NetworkManager/dispatcher.d that kicks drbd when the network goes up or down.  Quite a few Fedora services already have these, even sendmail!

‘man NetworkManager’ has more information on dispatcher scripts.  NM runs scripts in /etc/NetworkManager/dispatcher.d when various network events occur, which you can use to kick drbd to life when the network comes up or goes down.

The main problem is initscripts and daemons that simply aren’t smart enough to figure out what resources they require (like network connectivity) and wait until that requirement is available to them.  Instead, they quit.  And since we don’t have a real event system yet (though Upstart promises to be that) the services don’t get restarted when their resources become available.

In a perfect world, the initscript would parse the config file, figure out that it needs ‘eth0′ to be connected (or maybe just some interface with the IP address  Then, when NM brings up eth0 or when some interface gets, Upstart would look through that initscripts dependencies, notice that they are now fulfilled, and start the service.  When eth0 goes down, Upstart stops the service.  Kittens frolic in the sweet fields of clover.

Next, you probably want to make sure that your connections are ‘system’ connections, that is available to all users and before login.  For Fedora, this means creating a typical ifcfg file for your network configuration, which NetworkManager will then pick up and use to activate your device at boot time.  You can do this either by creating the ifcfg file yourself, or using nm-connection-editor and checking the “Available to all users” button.  See this wiki page for more information.

Wanted: Samsung SWC-E100 WiMAX ExpressCard

January 19th, 2010 by dcbw
Yota's Samsung SWC-E100: $65 (1,990 rubles)

Yota's Samsung SWC-E100: $65 (1,990 rubles)

XOHM's SWC-E100: $55 (when you could buy it)

XOHM's SWC-E100: $55 (when you could buy it)

Do you have either of these devices?  Or do you want to buy one?  And then send it to me?  I’ll even PayPal you up to $100 for it.  Let me know!  I believe the Yota device can still be purchased, but the XOHM variant stopped being sold last year after the XOHM/Clear merger.

Few Surprised at New Evidence of Staging Driver Suckage

November 19th, 2009 by dcbw

wdyt_photo3.articleThomas Johnson (High School Janitor)

Oh yeah, I’ve seen that code.  It’s worse than what I clean up in the bathrooms after Prom or Homecoming.  The kids get high and drunk and party too hard and puke all over the place.  I deal with enough vomit from 7:30 to 6; I wouldn’t touch the staging drivers with a mop twice as long as the one I have at work.

Just Say No

Thomas just found out that none of the “staging” wifi drivers will work with hidden access points because they don’t set the IW_SCAN_CAPA_ESSID capability bit.  Furthermore, the most popular “staging” drivers (for the Ralink hardware used in many netbooks) don’t even have specific SSID scanning capability at all.

Why do you care?  Hidden APs don’t broadcast their network ID, which misinformed people think is more secure (hint: it’s not).  Before a driver can associate to the network, it needs to discover available APs and capabilities, which requires a probe-request, which exposes the network ID to everyone anyway.  But that requires driver support which none of the staging drivers have.

I fixed this issue upstream two years ago by adding IW_SCAN_CAPA_ESSID to Wireless Extensions.  Of course the staging WiFi drivers that many distros enable never got fixed because the vendor it came from didn’t bother to work with the community in the first place.  And people wonder why they don’t work.

Broadly speaking, staging WiFi drivers come in two flavors: (a) old dried gum from under the cafeteria table (drivers with a future), and (b) fresh vomit from the hung-over kid in your math class (those without a future).

The drivers with a future (winbond, rtl81xx) are or will based on the kernel-standard mac80211 wireless stack, which implements the 802.11 WiFi specification in the kernel.  Since they use the standard mac80211 stack, they get all these nice features like probe-scanning and the correct capability bits for free.  All you have to do is work on supporting the hardware itself.

The drivers without a future (rt2860, rt2870, rt3070, rt3090, wlan-ng, vt665x) are based on forks of the ancient ieee80211 stack that Intel’s ipw2x00 drivers forked from the hostap driver.  Each of these drivers includes their own copy of the core ieee80211 stack forked at different times and with different hacks.  When a bug shows up, that means 4x the work, and 4x the chance for the fix to slip through the cracks.  Which is why these drivers have no future.  They are a maintenance nightmare.  Besides, they have crap like this:

pAdapter->StaCfg.bScanReqIsFromWebUI = TRUE;

It just blows my mind why people think staging wifi drivers are a great idea.  There’s a reason staging drivers set the TAINT_CRAP flag in your kernel; because that’s what they literally are.

So what’s the right thing to do?

There’s one huge reason why dead-end staging drivers are a bad idea: there aren’t enough developers.  So do you spend that effort  on maintaining unmaintainable shit code?  Or do you spend it on fixing the code that has a future?  Most of the time you can’t do both.

If you choose to maintain the staging drivers, then things become worse over time since the staging code is simply less tested and less maintainable.   So you continue to drop hacks and fixes onto an ever-growing steaming pile of manure.  Nobody cares much about the driver (because it doesn’t use the standard kernel interfaces and thus doesn’t have a future), so your staging driver never benefits from all the great feature work and bug fixing that the mac80211 and wireless developers are doing.

But if you choose to help fix the upstream drivers that do use mac80211 (like rt2x00), and thus have a future, maybe for a few months some users won’t have great wireless.  But they didn’t before either.  But then 6 months later, all the users get great wireless with features like power saving, background scanning, WiFi Direct, Bluetooth 3, access-point mode, etc.  Those things will never be done to the staging drivers, because those drivers are a dead-end maintenance nightmare, because their code is awful, and because they don’t use the standard kernel wireless stack.

I know I’d invest the effort where it helps users the most, even if it means a few more months of subpar driver support while the official upstream drivers get fixed and the staging drivers go untouched.  That’s how things actually get better when you can’t fix everything at once.

Public Service Announcement: Don’t believe the Internet

October 16th, 2009 by dcbw

My apologies to the VirtualBox team.  The problem appears to be users who are either (a) following really old VirtualBox recommendations that don’t even apply to their version, or (b) the age-old open-source problem of:

I found a HOW-TO that suggesting adding the following line to my /etc/fstab:
none /sys/bus/usb/drivers usbfs devgid=501,devmode=664 0 0

Don’t believe the Internet…  especially if it asks for sysadmin privileges.

Public Service Announcement: VirtualBox 3, HAL, and NetworkManager

October 14th, 2009 by dcbw

This is your /sys/bus/usb/drivers on VirtualBox 3
/sys/bus/usb/drivers with VirtualBox 3  (pic by

Ever since VirtualBox 3 came out, we’ve had random reports of mobile broadband cards not working with NetworkManager 0.7.x.  Here’s why:  VirtualBox 3 thinks it’s hilarious to screw around with sysfs.  You don’t even have to run it, you just have to install it.

/sys/bus/usb/drivers without VirtualBox:

[dcbw@localhost ~]$ ls -al /sys/bus/usb/drivers
total 0
drwxr-xr-x. 15 root root 0 2009-10-14 14:33 .
drwxr-xr-x.  4 root root 0 2009-10-14 14:31 ..
drwxr-xr-x.  2 root root 0 2009-10-14 15:40 btusb
drwxr-xr-x.  2 root root 0 2009-10-14 14:33 cdc_acm
drwxr-xr-x.  2 root root 0 2009-10-14 14:33 cdc_ether
drwxr-xr-x.  2 root root 0 2009-10-14 14:33 cdc_wdm
drwxr-xr-x.  2 root root 0 2009-10-14 15:40 hiddev
drwxr-xr-x.  2 root root 0 2009-10-14 15:40 hub
drwxr-xr-x.  2 root root 0 2009-10-14 15:40 qcserial
drwxr-xr-x.  2 root root 0 2009-10-14 14:33 usb
drwxr-xr-x.  2 root root 0 2009-10-14 15:40 usbfs
drwxr-xr-x.  2 root root 0 2009-10-14 15:40 usbhid
drwxr-xr-x.  2 root root 0 2009-10-14 15:40 usbserial
drwxr-xr-x.  2 root root 0 2009-10-14 15:40 usbserial_generic
drwxr-xr-x.  2 root root 0 2009-10-14 15:40 uvcvideo

/sys/bus/usb/drivers with VirtualBox 3:

[dcbw@localhost ~]$ ls -al /sys/bus/usb/drivers
total 0
drwxr-xr-x. 10 root root 0 2009-10-14 00:03 .
drwxr-xr-x.  4 root root 0 2009-10-14 00:04 ..
dr-xr-xr-x.  2 root root 0 2009-10-14 00:03 001
dr-xr-xr-x.  2 root root 0 2009-10-14 00:03 002
dr-xr-xr-x.  2 root root 0 2009-10-14 00:03 003
dr-xr-xr-x.  2 root root 0 2009-10-14 00:03 004
dr-xr-xr-x.  2 root root 0 2009-10-14 00:03 005
dr-xr-xr-x.  2 root root 0 2009-10-14 00:03 006
dr-xr-xr-x.  2 root root 0 2009-10-14 00:03 007
dr-xr-xr-x.  2 root root 0 2009-10-14 00:03 008
-r--r--r--.  1 root root 0 2009-10-14 01:44 devices

That’s obviously wrong.  And your sysfs USB device links still point to their driver in /sys/bus/usb/drivers and thus are completely broken:

[dcbw@localhost ~]$ ls -al /sys/devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/driver
lrwxrwxrwx. 1 root root 0 2009-10-14 02:20 /sys/devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/driver -> ../../../../../../bus/usb/drivers/option


Then HAL can’t determine the device’s driver because VirtualBox busted the link, and thus the modem will fail to be recognized by NetworkManager.  No 3G for you!  You can work around this with a HAL .fdi file:

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- xml -*- -->
 <deviceinfo version="0.2">
     <match key="info.subsystem" string="usb">
       <match key="usb.vendor_id" int="0x0af0">
         <match key="usb.product_id" int_outof="0x6701">
           <merge key="info.linux.driver" type="string">option</merge>

Drop that (after fixing the USB IDs and driver for your device) into /usr/share/hal/fdi/information/20thirdparty/10-vbox-usb-fixup.patch and replug your modem.  Or uninstall VirtualBox.  Or revert to VirtualBox 2.  Or update to NetworkManager 0.8.x snapshots.

You have been served.

VirtualBox devs, any chance you can stop messing with sysfs?  I can file a bug if you like…

Whipping out the pipe snake

October 6th, 2009 by dcbw
Not done yet; room for two more...
Can’t go home till the plumbing is done

… to get down and dirty with your wifi card.  Really, get your mind out of the gutter.  Lets keep this PG shall we?

The Wireless Summit, LinuxCon, and Linux Plumbers Conference were all two weeks ago, where the Wireless Cartel of Awesome met to unclog the drain of Linux wireless with the righteous hand of glory.  We solved world peace while simultaneously making the earth safe for Democracy, David Zeuthen’s favorite pink pony, and a bunch of cute fuzzy kittens.  But that’s boring.  Instead, two other things deserve your attention:

Background Scanning

As of the 2.6.32 kernel WiFi scans requested while connected to an access point are background scans.  The mac80211 stack will spread the scan out over about 30 seconds, jumping back to the associated AP’s channel every so often so it doesn’t stall your traffic.  We’ve actually done this in the OLPC Libertas for a long time, and now everyone on the block gets it.  There’s been any number of bugs open about NetworkManager’s scan behavior, including misguided requests for huge fat “Don’t scan while connected” checkboxes in the UI.  And now that’s been fixed upstream.  Oh, bought a Ralink card or a Broadcom?  Sorry, better luck next time.  This is why you buy hardware that actually works with Linux, so that the Gods of Kernel Wireless will rock your card, and you won’t be stuck with dead-end shit that never gets better.  But maybe pain floats your boat.  If you bought Intel or Atheros then you’re awesome.

Sometimes people stop me on the street and ask me why we want to scan periodically.  Here’s what I tell them.  Besides enabling location-based services (which help me find great candle-lit bistros for dates with your mom) there’s one super-important reason: roaming.  Not just between networks, but also between APs in the same network.  If the wifi card doesn’t have an up-to-date scan list, you’ll take the hit anyway at the worst possible moment: when your back is against the wall, the gun’s in your face, and you have to switch APs or lose the connection entirely.  So better do it while you can.  Only have one AP at your place and don’t need roaming?  That’s nice, but writing software is about making things work smoothly for everybody.  Which is what background scanning is all about.

wpa_supplicant D-Bus Interface 2.0

Over the summer, Witold Sowa rocked AP mode support in NetworkManager (though I still have to merge it), and as part of that hugely rewrote the D-Bus interface to wpa_supplicant that I wrote back in 2007.  In conjunction with the upstream mac80211-based kernel drivers (sorry Broadcom and ralink, no soup for you) we’ll get better failure information, finer-grained control over wifi connections, faster reconnections, better handling of link dropouts, AP mode support, great roaming behavior, better power-saving for awesome netbook performance, and a lot of other stuff.  Jouni already merged most of the supplicant patches so soon we’ll be rocking the wifi goodness bullet train.

And just one more thing…

Did somebody say Bluetooth DUN?

On different note, I did about 75% of the work to get bluetooth Dial-Up Networking support going this weekend.  It’s too late to land in a 0.8 release later this month but first on the merge list for 0.8.1.  Setup will be just as smooth as PAN setup, configuring your mobile broadband provider when you pair the phone and one-click connection after that.  DUN gets requested a lot, and now with ModemManager backing our mobile broadband support, there’s enough flexibility to handle most of the really crappy phones out there.  Honestly PAN just works better, but whatever.

More later.  Peace out kids.

Unwire with NetworkManager

July 10th, 2009 by dcbw
Dude, it's just easier with NetworkManager...

Dude, life's just easier with NetworkManager...

I cleaned up NetworkManager’s Bluetooth PAN support (originally by Bastien) to show Bluetooth devices in the nm-applet menu.  Then I put together this walk-through to show how easy life is these days.  DUN support needs a bit more work (it’s more complicated but also more capable); but tons of phones have PAN so let’s get it out there.  The plugin support that Bastien recently added to the gnome-bluetooth wizard got us the other 25% of the way towards seamless Bluetooth networking on your desktop.

Pairing Your Phone

So <i>that's</i> what that Bluetooth icon is for!  Who'd have thought...

So that's what that Bluetooth icon is for! Who'd have thought...

Obviously we start with the Bluetooth icon, since you need to find your phone and then pair with it.

Kyle was my barista this morning...  Apparently she has a MacBook.

Kyle was my barista this morning... She has a MacBook and pulls a mean espresso.

Pick your phone.  Hopefully you remembered to turn Bluetooth on and make your phone visible, otherwise do it now and hit the “Rescan” button.  As you can see, this is more a tutorial in gnome-bluetooth than NetworkManager right now.

The Money Note

Once you’ve paired and entered the passcode, we finally get into NetworkManager territory.  nm-applet installs a gnome-bluetooth plugin that does the magic of creating a Connection for your phone in GConf.  And all it takes is checking a box.



Patience!  You’re one more click away from all the Facebook and Twitter and MySpace and Flickr and blogging and Googleness you crave so much.  It’s just so hard being without this Internet thing for more than a few minutes.

The default connection name wants some fixin'.

The default connection name wants some fixin'...

How easy was that?  You’ll need gnome-bluetooth >=, bluez >= 4.42, and git master of both NetworkManager and network-manager-applet.  Packages for Rawhide soon.

Die HAL Die

July 3rd, 2009 by dcbw
Time for a Stalinist purge

The purge is complete

As of a week ago or so, HAL is no longer required by either NetworkManager or ModemManager.  This helps streamline the hardware detection process and cleans up that code a lot.  It was a fun ride and a lot of other great stuff came along with the udev port, because rewriting everything to use udev pretty much required cleaning up a bunch of other stuff.  The udev parts were a lot easier than I thought they would be; what was complex was rewriting a ton of ModemManager to be more flexible and work better with multi-port modems on the one hand, and really stupid quirky hardware on the other.

For everyone in the US, have wonderful 4th of July.  To everyone who’s not, have fun at the Desktop Summit.  Had prior plans meaning I couldn’t attend, but I’m sure the Red Hat team will honor my absence by spreading the love and drinking all the liquor.  Rock on, GNOME.

NetworkManager and ConnMan

June 25th, 2009 by dcbw

Lately ofono and ConnMan have been in the news, and that’s sparked some discussion about how these two projects relate to NetworkManager.  I’ve mostly just been ignoring that discussion and focusing on making NetworkManager better.  But at some point the discussion needs to become informed and the facts need to be straightened out.

So what makes NetworkManager great?

  • Flexibility: NM’s D-Bus interface provides a ton of control and information about the network connections of your machine.  Developers and applications simply don’t take enough advantage of this.  Imagine mail automatically pulled whenever the corporate VPN is up.  Or more restrictive firewalls when connected to public networks.  Yeah, you can do that today with NetworkManager.
  • Works everywhere: from the mainframe to the power desktop to the netbook and lower.  There’s nothing stopping you from running NetworkManager on an s390 or a Palm Pre.
  • Integration: most users like NetworkManager’s distro integration, so it’s on by default (but can be turned off for running bare-metal).  NM will read your distro’s network config files: ifcfg on Fedora, /etc/network/interfaces on Debian, etc.  It doesn’t pretend the rest of the world doesn’t exist, but it can if you tell it to.
  • Connection Sharing: you can share your 3G connection to the wired or the wifi interface, or the other way around.  How you share is completely up to you.
  • VPN: it’s got plugins for Cisco (vpnc), openvpn, openconnect, and pptp.  An ipsec/openswan plugin is being written.  It’s just easy to use the VPN of your choice.
  • Makes Linux better: by not working around stupid vendor drivers or other broken components, NetworkManager drives many improvements in drivers, kernel APIs, the supplicant, and desktop applications.    Five years ago I posted a list of wifi problems, many of which got fixed because NetworkManager users complained about them.  Stuff like WPA capability fixes, hidden SSID fixes, suspend/resume improvements, Ad-Hoc mode fixes, and lots of improvements to wpa_supplicant to name just a few.  By encouraging drivers to be open, by fixing bugs in the open drivers and the stack instead of hacking around them, and by encouraging vendors to work upstream, NetworkManager makes Linux better for you.

What great stuff is coming next?

All in all, a lot of great stuff is on the plate.  NetworkManager already works well for a ton of people, but we’d like to make it work better for a lot more people.  And it will.

So what about ConnMan?

I recently came across a slide deck about ConnMan which makes both disappointing and inaccurate claims about NetworkManager.  It’s also worth emphasizing the philosophical differences between the two projects.

First, ConnMan primarily targets embedded devices, netbooks, and MIDs (slide #1).  When ConnMan was first released in early 2008, NetworkManager 0.7 was under heavy development, and NetworkManager 0.6 clearly did not meet the requirements.  But 0.7, released in November 2008, works well for a wide range of use-cases and hardware platforms.

NetworkManager scales from netbooks, MIDs, and embedded devices with custom-written UIs to desktops to large systems like IBM’s s390.  You get the best of both worlds: from phenomenal cosmic power down to itty-bitty living space.

ConnMan explicitly doesn’t try to integrate with existing distributions (slide #5), partly due to it’s requirements to be as light-weight as possible.  But NetworkManager will use your distro’s normal network config and startup scripts if you tell it to do (but you don’t have to).  Early in NetworkManager days we tried to ignore the rest of the world too.  Turns out that doesn’t work so well; users demand integration with their distribution.  But ConnMan doesn’t pretend to be general purpose, and due to its embedded focus, it can wave this issue away.

Both ConnMan and ofono reject well-established technologies like GObject (but still uses glib) in favor of re-implementing much of GObject internally anyway. This is a curious decision as GObject is not a memory hog and not a performance drag for these cases.  The NIH syndrome continues with libgppp, libgdhcp, and libgdbus, where instead of improving existing, widely-used tools like dhclient/dhcpcd, pppd, and dbus-glib, ConnMan opts to re-implement them in the name of being more “lightweight”.  With embedded projects that ConnMan targets (like Maemo and Moblin) already using GObject and dhcpcd, I don’t understand why this tradeoff was made.  Perhaps this visceral dislike of GObject and dbus-glib was one reason the project’s creators decided to write their own connection manager instead of helping to improve existing ones.

NetworkManager in contrast re-uses and helps improve components all over the Linux stack.  Because of that, more people benefit from the fixes and improvements that NetworkManager drives in projects like avahi, wpa_supplicant, the kernel, pppd, glib, dbus-glib, ModemManager, libnl, PolicyKit, udev, etc.

Taking a look at the deck

I have things to say about most of the slides, but I’ll concentrate on the most interesting and misinformed ones instead.

Supposed Words About NetworkManager

Supposed Words About NetworkManager

  • Very Complex Design: a complete strawman, because it doesn’t say anything.  NetworkManager 0.7 is a mature project with many useful features.  NM is based around a core of objects, each one performing actions based on signals and events from other objects.  It’s modular and flexible.  It’s just not a ConnMan-style box of lego blocks with a rigid plugin API and all the problems that causes.
  • Large Dependency List: NM requires things like wpa_supplicant, udev, dbus, glib, libuuid, libnl, and a crypto library.  pppd and avahi are optional. This list is certainly not large.  When you take ConnMan and its optional dependencies (most of which are needed in a useful system) the list is just about the same.
  • Too Much Decision-making in the UI: Completely bogus and frankly incomprehensible.  The core NM daemon provides a default policy which is in no way connected to the UI, and the rest is up to the user.  nm-applet contains no policy whatsoever.  If the objection is to nm-applet’s desktop-centric interaction model, then it’s important to know there is no lack of applets for different use-cases.
  • Tries to work around distro problems: this is completely a matter of perspective.  Since Intel was creating its own Linux distribution (moblin), they didn’t have to work around any existing issues; these were simply waved away.  Unfortunately NetworkManager lives in the world of reality and not some universe full of ponies.  For users that expect it, NetworkManager integrates with your distros existing network config, init scripts, and DNS resolution.  For users that don’t care, NetworkManager can run bare-metal.
  • Too much GNOME-like source code: seriously, what the hell?  I’m not sure where to begin with this one.  The NetworkManager core does not depend on GNOME.  At all. Yeah, the source-code is in the Gnome style, but is that seriously an issue?
Uninformed diagram of NetworkManager architecture

Uninformed diagram of NetworkManager architecture

(Misinformation shaded blue for your protection)

The User Settings service is contained in the applet, and it’s completely optional.  The System Settings service has been merged back into the NetworkManager core daemon and is no longer a separate process.  That same commit ported NM from HAL to udev; thus HAL is no longer required.  NetworkManager always used HAL/udev for device detection instead of RTNL (ie, netlink).  NetworkManager also hasn’t used WEXT for a long time; wpa_supplicant handles kernel wireless configuration.  NetworkManager uses distro networking scripts only for service control, as does ConnMan.  The rest of the slide is quite petty and just splits hairs.

Where to?

It’s unlikely that either NetworkManager or ConnMan will disappear in the near future.  That means we’ll all have to live with two mutually exclusive connection managers and two completely different network configuration systems.  I think that’s pretty pointless, but I don’t get the last word anyway, since that’s not how Open Source works.  The users will decide which solution works best for them.  And that means NetworkManager will keep getting better, keep getting more useful, and will continue to be the easiest network management solution around.

Mobile Broadband Assistant makes it Easy

June 22nd, 2009 by dcbw
Yay!  Mobile broadband with NetworkManager is so simple!

Yay! Mobile broadband with NetworkManager is so simple!

(credit mandolin davis)

Easier than your… well, you probably know where I was going with that.  It’s a great leap forward for NetworkManager usability.  Other operating systems either don’t have one, or your network operator gives you the software so of course you don’t have to configure it.  On Linux, we like to work for everyone, so we get to make it easy to get connected to the operator of your choice.

Antti does the base

Antti Kaijanmäki did some work last summer (2008) to put together the mobile broadband provider database and write a library and assistant to use that data.  That was a great start, and Ubuntu started shipping it as a patch in 8.10.  Seems to have worked fairly well there, but since we were deep in the middle of getting the NM 0.7 release out at that time, it wasn’t possible to integrate then.  Antti’s patch didn’t get committed to 0.7.1 for mostly licensing and scope-related reasons, but he built the database which the assistant that just hit git uses, and he proved that it was something users wanted.

Tambet the wrote a compatibly-licensed library to parse the database for network-manager-netbook, which means I didn’t have to, which was nice.

Implemented with Máirín-induced goodness

So a few weeks ago I started rewriting the pitiful GSM/CDMA chooser dialog in network-manager-applet into a full GtkAssistant-based helper.  I’m not an interaction expert, so I tricked Máirín Duffy into helping me get the flow and design planned out.  Then we iterated over my implementation and fixed what sucked, and came out with something that works pretty well.  Starting from the user’s perspective is incredibly important, and that’s what we did with the mobile broadband assistant.

Why do you want this?  (or, WTF is an APN?)

Because you probably have no idea what a GPRS APN is, or why you need the right one to make things work.  Nor should you have to.  At least CDMA got this right by not having one, they are an interaction nightmare.  Your provider knows exactly what you’re paying for, so they know exactly what to bill you for when you use various services they offer.  But when connecting to GPRS data services, you need to tell your phone or device what APN you’d like to use when connecting which in turn tells the provider how you’d like to be billed for it.  But this sort of access control is simply at the wrong level, and having it a the GSM level instead of the application level sucks for users.

There are different APNs for everything; for example T-Mobile USA splits it up as follows:

  • – for T-Zones, the WAP-based walled-garden for dumbphones ($6/mo)
  • – Unblocked access to anything using a NAT-ed IP address ($20/mo)
  • – Unblocked access to anythign using a public, routable IP address for certain VPN clients (also $20/mo)
  • – new, nobody’s quite sure what its for

Some providers have a separate APN that downsamples JPEGs to save data costs, others have separate APNs for pay-as-you-go versus contract (they already know whether your IMSI is contract or not, so this baffles me), others have separate APNs per region they serve (BSNL India).  It’s a freaking mess.

Sanity through NetworkManager

APNs don’t really change that often, so it’s easy to build up a crowdsourced database of current providers and their APNs.  Which is what Antti did, and that worked out really well.  Máirín decided to loosely map the APN to a provider’s billing plan, which usually maps to brand name or service that users actually care about.  So I reorganized the mobile broadband provider database to allow multiple “services” (ie, APN or CDMA) for each provider.  This almost gave me carpal tunnel since its not easily scriptable.

Second, I added all the MCC/MNCs (network identification numbers) that I could find, so that in the future we can read you IMSI off your SIM card and automatically suggest your provider when you plug in your phone or data card the first time.  That’s pretty hot.

Hot Pics

When you first insert your card, it shows up in the applet menu.  Ubuntu has a patch that will nag you with a notification that you’ve just plugged in new 3G hardware; they’re welcome to port that to the new code and submit.  For now, it looks like this:


When you click that, you’ll get the Assistant’s intro page:


This page explains some of the information you’ll need.  Hopefully you know what provider you signed up for, but if you don’t, you seriously need to stop getting drunk before 3 in the afternoon.  You probably also know what country you’re in, if not,seriously, get a GPS.  I can’t help you with that.


Now it gets a little tougher, but since you’re filling a wheelbarrow with your money and dumping it on your provider’s doorstep, you’ll probably also know what provider you signed up with.  But maybe you got shanhai-ed into signing a contract, I don’t know.


But if your provider isn’t listed, we need your help. File a bug in Gnome Bugzilla, tell us your provider name, your country, the common name of your plan, and the APN you use.  We’ll update the provider database with that information, and thank you profusely for making life easier for everyone else too.  We could, in the future, allow users to automatically send their manually entered settings to a server somewhere, and make the provider database update process less manual.  Patches for that greatly appreciated.  Now you get to choose your plan:


Again, if your plan (ie, APN) isn’t listed, file a bug.  But since you signed up, and they probably have some sort of FAQ for that sort of thing, you’ll probably be OK.  Lastly, we have:


and if all looks well, you hit Apply, and NetworkManager will activate the connection you just set up.  You can also change the APN easily through the connection editor.  Much rejoicing was heard.

Future Improvements

There’s a few things we can do in the future…  If the connection fails for some reason, re-display the Assistant.  We can autodetect your provider based on the first 5 or 6 digits of your IMSI on your SIM, skip the Country page, and automatically select that provider in the Provider page, saving you a step or two.  Unfortunately, we can’t autodetect the plan/APN because that’s not stored anywhere (well it is usually preloaded into your phone, but all the APNs are, and there’s no indication of which one is the one you really want).  So there’s room to make it even more awesome.

Your help is required

Again, the mobile broadband provider database is incomplete.  Help fix it up for your country and your provider by filing a bug with your information.  Include your provider name, your country, your plan’s marketing name if you know it, and of course the APN you’re using for data.  If you have a CDMA provider, just tell us your country and provider name.  Username and password are generally ignored by the network and the device, so they aren’t useful.  It’s your help that makes this effort work better for everyone.