Eat Burgers on the Short Bus

Every so often I get questions about D-Bus and I end up giving a mini-lesson on what D-Bus is and how it’s used.  It took me a while to wrap my head around D-Bus long ago so I don’t expect everyone to pick up D-Bus like Yo-Yo Ma sight-reading.  So this is D-Bus, simplified.

D-Bus is just an IPC mechanism, but it layers a few concepts on top of plain message-passing. It took me some time to understand how the D-Bus object model really works (long ago of course), so don’t worry about it you don’t completely understand how it all fits together yet.

  • service: a program that responds to requests from clients. Each service is identified by a “bus name” which clients use to find the service and send requests to it. The bus name usually looks like org.foobar.Baz. A program can claim more than one bus name; NM claims org.freedesktop.NetworkManager and org.freedesktop.NetworkManagerSystemSettings, each is a unique service which provides different functionality to clients.
  • object: a method of organizing distinct entities, just like programming languages have objects. Each object is uniquely identified by an “object path” (somewhat like an opaque pointer) that often looks like /org/foobar/Baz/235235. Each request sent to the service must be directed to a specific object. Many services have a base object with a well-known path that you use to bootstrap your communication with the service.
  • interface: each request belongs to an interface, which is simply a way of logically separating different functionality. The same way that object-oriented languages like Java or C++ or GLib define an “interface”; a specific API that completely different objects can implement, but the caller doesn’t need to know what type the object is, just what methods the interface defines. Interface names often look like D-Bus service names, but have no relation to them.
  • method call: a request for an operation or information that a client sends to the service; method calls are defined by an Interface and are sent to a service’s objects.
  • signal: a message broadcast from a service to any listening client.

Putting it All Together

Say you have a binary called “mcdonaldsd” that provides a D-Bus service called org.fastfood.McDonalds. Clients that want to talk to this service use the bus name org.fastfood.McDonalds to direct requests to mcdonaldsd.  mcdonaldsd provides a base object called /org/fastfood/McDonalds. This object implements the org.fastfood.McDonalds interface, which defines these method calls:

  • GetItems
  • Order

GetItems() returns an array of object paths representing all the things on the menu that you can order. So if you call it you’ll get something like this in return:

[ ‘/org/fastfood/McDonalds/Item/0’, ‘/org/fastfood/McDonalds/Item/1’ ]

Each of these returned object paths is a pointer to an object; mcdonaldsd probably even implements these as objects internally using Java or C++ or GObject or whatever. These objects are probably completely different (one may be a burger, one may be a drink, the other could be fries) but they all implement a common interface: org.fastfood.McDonalds.Item.

The org.fastfood.McDonalds.Item interface defines the following method calls:

  • GetName
  • GetType (returns either TYPE_BURGER, TYPE_DRINK, or TYPE_FRIES)
  • GetPrice
  • Consume

So even if you don’t know what exact type of object /org/fastfood/McDonalds/Item/0 is, you still can get a lot of information about it, enough to decide whether you want to order it or not.

Assume that item “0” is a “BigMac” and item “1” is “Coke”. These are clearly different objects, but each has a name, a calorie count, a price, and can be consumed.  Next, since each item is different (even though they all implement the common org.fastfood.McDonalds.Item interface) each item will implement other interfaces that define functionality specific to that type of item.

So item “0” (BigMac) implements the org.fastfood.McDonalds.Item.Burger interface which has the following methods:

  • Unwrap
  • AddMustard
  • RemovePickle (nobody likes those stupid limp pickles anyway)

And item “1” (Coke) implements the org.fastfood.McDonalds.Item.Drink interface which has the following methods:

  • PutLidOn
  • InsertStraw
  • RemoveStraw

Remember, since both objects *also* implement the base org.fastfood.McDonalds.Item interface, you can use the Consume() method to consume both items. But clearly, you don’t want to include the InsertStraw() method on the generic org.fastfood.McDonalds.Item interface, because all items implement that interface, and it would be pretty funny if you tried to call InsertStraw() on the BigMac object.  People would stare.

So interfaces are about logically separating method calls that have specific functionality, and thus any object that wants that functionality can implement that interface, instead of having every object type duplicate every call the interface defines.

So, with python-esque pseudocode:

# Get local proxy for the remove mcdonaldsd service
bus = get_service("org.fastfood.McDonalds")
mcds = bus.get_object("org.fastfood.McDonalds", "/org/fastfood/McDonalds")
burger_path = None
drink_path = None
# Lets read all the menu items
menu_items = mcds.GetItems()
for object_path in menu_items:
    item = bus.get_object("org.fastfood.McDonalds.Item", object_path)
    print "Item: %s price %s" % (item.GetName(), item.GetPrice())
    # Now let's figure out what we want to order; we'll order
    # the first burger we find and the first drink we find, but
    # only one of each.  We just had breakfast so we're not that
    # hungry.
    item_type = item.GetType()
    if item_type == TYPE_BURGER and burger is None:
        burger_path = object_path
    elif item_type == TYPE_DRINK and drink is None:
        drink_path = object_path
    # We've found a burger and drink on the menu, lets order them
    if burger_path and drink_path:

# Did this place not get their latest deliveries or something?
if not burger_path or not drink_path:
    print "This restaurant doesn't have enough food for me."
food = mcds.Order([burger_path, drink_path])
if food.len() != 2:
    print "Oops, not enough money or something. Need to get a job."
# Yay, we got our order.  Now we take off the damn pickle.
burger = bus.get_object("org.fastfood.McDonalds.Item.Burger", burger_path)
# And we're taking this to go, so we need a lid and straw for the drink
drink = bus.get_object("org.fastfood.McDonalds.Item.Drink", drink_path)
catch Exception, e:
    print "Oops, straw already inserted!"
# We were distracted by the smell of the burger and put the
# straw in before we put the lid on.  Oops.  Take the straw
# out, put the lid on, and then re-insert the straw
# All ready.  Now we can walk out, sit on the curb, and consume the
# burger and drink; note that even though burger_proxy and drink_proxy
# were created with D-Bus interfaces specific to their food type, we
# don't really need to create another interface just to call the
# generic Consume() method which both the burger and drink implement.
# Just give the method call the generic interface.

What You Don’t Know About NetworkManager Part 1: Configuration

It's a D-Bus Party!

A tale of two services…

The “settings service” is a core concept of NetworkManager.  There are two settings services: the system settings service and the user settings service.  These are just D-Bus services that provide stored network configuration to NM and apps like nm-connection-editor, nm-applet, knetworkmanager, and anything else.  The job of a settings service is to store configuration in some manner (GConf, KConfig, keyfiles, ifcfg, /etc/network/interfaces, whatever) and translate that into a format apps understand.  That’s it.

Why are there two of them?  Well, mainly because you don’t want every connection usable by everyone.  Do you want your kids starting your work VPN tunnel to your secret CIA front-company?  Or your metered 3G to watch online cartoons?  Probably not.  Those connections get stored in your user settings service where only you can use them.  But connections that anyone can use, like your home WiFi or ethernet, should be system connections and thus available to everyone.

What uses these services?

First, NetworkManager uses them to get the list of networks which you’ve connected to.  So it can reconnect you to them.  That’s pretty fundamental.  When you connect to a new network, the settings service (usually nm-applet or knetworkmanager) creates a new connection config and sends that to NM, which then connects you.

Second, any application that wants to know about network configuration can.  Note that they cannot read your passwords unless you allow them to via PolicyKit; there’s a good amount of security built into the system to make sure your passwords aren’t discovered and sold off by Nigerian hackers.  nm-connection-editor lets you edit this list through a UI.  nmcli reads this list to show you active connections and their details in the terminal.  An application like Evolution could read the list and start pulling your work email only when you’re connected to the VPN.  The possibilities are endless.

The system settings service is special

Partially because it’s built into NetworkManager, but also because it’s privileged, the system settings service can do stuff the user settings services can’t.  First, it’s trusted because the storage it uses (ifcfg files, /etc/network/interfaces, keyfiles, etc) cannot be modified by normal users.  You have to prove yourself with PolicyKit before you can modify system settings, and in this way unprivileged users can’t mess with your network configuration.

Second, the system settings service is tasked with interpreting your normal distro config files and turning the configuration format you’re familiar with into data all apps can use.  And this is where the magic lies. In a happy rainbow-filled world, NetworkManager can take your configuration stanzas in /etc/network/interfaces or /etc/sysconfig/network-scripts/ifcfg-eth0 and apply them to your network device, and everything works just like you expect it to.  You don’t even know NetworkManager is there.  This intelligence is provided by distro-specific plugins.

Each distro should have a plugin that understands the native configuration format.  We have plugins for SUSE, Debian, Ubuntu, and Red Hat.  There’s also a generic plugin called ‘keyfile’ that writes .ini-style files to /etc/NetworkManager/system-connections and can be used as a backup if any of the plugins you enable are incapable of saving configuration.  Plugins get enabled through the NetworkManager config file, one of /etc/NetworkManager/NetworkManager.conf (the new name) or /etc/NetworkManager/nm-system-settings.conf (the old name).  And you can stack plugins; since the ‘ifupdown’ (Debian/Ubuntu) plugin can’t write out any configuration yet, adding the ‘keyfile’ plugin allows changed connections to be saved as keyfiles instead.

Make the Editor Your Slave

All it really wants is to love you

You don’t have edit the config files directly unless you want to; the connection editor provides a convenient interface to all the network configuration.  But since the system settings service is privileged and writes system-wide configuration you’ll need to be authorized through PolicyKit to change it.  Look for /usr/share/polkit-1/actions/ to find out which privileges there are and what the default access level is.  Read up on PolicyKit to find out how to customize the privileges for your installation or your organization.  If you can’t change the “Available to all users” checkbox for a connection, chances are you’re not authorized or PolicyKit can’t determine who you are.  You should either fix that, or talk to your system administrator 🙂

So how do I talk to a settings service?

If you’re an app developer, there are three important resources are at your disposal:

  • the NetworkManager setting specification, which details what the connection configuration contains and what values each member has
  • the python examples, which show how to talk to a settings service and get the information you need
  • the mailing list, which provides quick, useful help when you get stuck

Suggestions for better examples and documentation focus greatly appreciated.  It’s not supposed to be hard.  It’s supposed to be fun to add network awareness to your apps.

Tell me more!

No.  Not yet.  Later.  I can only do so much in a week.

Qualified to Satisfy You

I spent a lot of March beating the shit out of ModemManager.  When the beatdown was done and the dust settled, out came a boatload of stuff people want.  It ain’t gonna win design awards, but your wildest 3G fantasies just got rocked. Hard.

Access Technology

Access wha? Wanna see how fast you be cruisin’ those intarwebs fool?  That’s why you want some “access technology” dropped on your desktop, right up on your 32px hot-pink GNOME panel.  Ask and you get it delivered.  Most modems can tell whether they’re connected to the tower using EDGE, UMTS, HSxPA, 1x, EVDO, or whatever, and now you see it too.  It’s a great way to figure out just how bad your provider’s network buildout is.  Yeah that means you, T-Mobile USA.

Now if only I had some EVDO...

AT&T for the 3G Win

Hope you like EDGE, 'cause with TMO that's about all you get

Avoiding the Roaming Shaft

You work hard for the cash money.  You don’t want some punk roaming network up and grabbing the bills straight outta your pocket.  So if you check the magic button, ModemManager won’t connect to a roaming network.  If you’re on the home network and get handed off to a roaming one, ModemManager will kill the connection.  Dead.

Just push the button

If you feel like you’re getting shafted, look for the roaming badge on the applet icon, or check the menu before you connect. Kick roaming in the ass or whatever you feel like doing.  Maybe you like roaming too much.  But at least now you have choice.

Roaming is fun for your wallet

You Got a Preference

Do you hate 3G?  Do you just loooove the 2G action?  Fine, have it your way.  Choose your mode preference.  But remember: every time you pick GPRS God kills a kitten.  Think of the kittens.

Don't. Kill. Kittens.

Slave to the Provider Info

Long ago Antti Kaijanmäki started the mobile broadband provider database to build up a free, open, easily usable list of mobile broadband provider details.  Besides being the core of the mobile broadband wizard, it’s now used for grabbing the provider name when we can’t get it elsewhere.

For example, every CDMA 1x base station broadcasts a System ID, and we look this SID up in the provider info and pull out the provider name.  And on the GSM side, if the card is stupid (or your provider didn’t set the SIM correctly) then sometimes the alpha for of the PLMN will be missing, but the MCC/MNC won’t be, and we look that up in the provider database to get a pretty network name too.

So that’s a wrap for what will be ModemManager 0.4 in a few weeks.  But if you want a preview, check out Fedora 12, 13, or rawhide.

Mobile Broadband and Qualcomm Proprietary Protocols

NO PROTOCOL FOR YOU (via bassclarinetist)

There are two major mobile broadband technology families: GSM/UMTS (which three quarters of the world uses) and CDMA/EVDO (used by the rest).  Keep in mind that UMTS uses CDMA as the radio technology, but incompatibly from CDMA/EVDO.

Back to School

GSM is a TDMA (Time Division Multiple Access) technology; communication is divided into a number of slots in which specific devices talk.  Each slot contains voice, data, or signalling information.  When it’s not your turn, you can’t talk.  Pretty simple, but given that it’s a TDMA technology, it’s prone to multipath interference and hard capacity limits.  You also have to carefully plan out your cell layout to ensure that adjacent towers don’t use the same frequency.

CDMA, on the other hand, is an ingenious spread-spectrum technology.  It’s got a great back story with movie stars and a war and stuff.  In contrast to GSM, in a CDMA system every user talks at the same time.  Each user is given a unique sequence of zeros and ones called a “spreading code” which is used to modulate the data stream over a certain frequency range (hence the spread-spectrum part).  On the receive side, when you know a user’s spreading code you apply it to the RF signal and retrieve the original data.  Each user in the cell just sees every other user’s signal as slightly increased background noise.  This is why CDMA is extremely robust against snooping and multipath interference, and why its capacity gracefully degrades as cell utilization increases.

What about Qualcomm?

Qualcomm holds many of the patents on CDMA since they spent a ton of time and money turning CDMA into a viable cellular radio technology 20 years ago.  They are also one of the largest sellers of cellular chipsets in the world.  We as open-source developers have to care, because their stuff shows up in tons of the devices we support.  Users don’t like being told “no”.

Most mobile broadband devices (Qualcomm’s included) appear as USB interfaces providing two or more serial ports.  One port is usually AT-command capable.  If you’re lucky, you get a secondary AT-capable port to use for signal quality and status while the primary port is using PPP for data transmission.  Most GSM/UMTS modems have a second AT port.  Most CDMA modems do not.

So when your device only has one AT-capable port, what language do the other ports speak?

Proprietary Protocol #1: QMI

This protocol is found on newer Qualcomm chipsets like the MSM7k series that show up in Android handsets Qualcomm Gobi data cards.  Google exposed some of the QMI protocol in the Android drivers.  Other details have recently turned up through the Gobi Linux driver sources, though Qualcomm doesn’t distribute sources for the “QCQMI DLKM” that probably contains the protocol mechanics.  It shouldn’t be too hard to reverse-engineer most of the protocol given these sources and a USB sniffer, but nobody has had the time yet.  QMI uses an HDLC-type framing which is quite common in proprietary mobile broadband protocols: a CRC-16 and 0x7E terminates a frame, and the frame is escaped such that 0x7E doesn’t show up in the data.  But since we haven’t reverse-engineered QMI yet, it isn’t the main focus of this post.

Proprietary Protocol #2: DM

Diagnostic Monitor is an older protocol found in most Qualcomm devices.  I’ve been interested in QCDM for a while, since without it, you can’t get signal strength and status from most CDMA devices while connected.  So I’ve been trawling the web for the past couple years looking for anything related to QCDM, and I finally hit the jackpot last fall:  the GPL sources for the Sprint-branded Linksys WRT54G3G-V2 router, which have since disappeared.  They include a GPL-licensed tool called ‘nvtlstatus’ which implements various pieces of the QCDM protocol.  The code is complete junk (as you’d expect from many embedded device manufacturers with schedules to hit) but it worked.

There’s also a sketchy Chinese package called “CDMA_Test.rar” that includes lists of the NVRAM items and some of the DM command numbers.  While not GPL, we can use the command numbering and structure definitions because it falls under the phonebook and interoperability copyright exceptions.  Additionally, there’s the TCL-based (ick) “RTManager” tool that implements some interesting QCDM commands, which, while we can’t use any of the code, is useful for structure field names that I hadn’t already guessed. Third, some guy did some reverse engineering of Novatel devices on Windows and built up a list of commands, subsystems, and NVRAM locations that were useful for confirming what I found in the other sources.

So through a combination of reverse engineering and these sources I wrote libqcdm, which we now use extensively in ModemManager for controlling CDMA devices.

DM Commands

Since DM is a pretty old protocol (2000 and possibly earlier), many of the commands are purely historical and currently unused.  The most interesting ones are:

  • DIAG_CMD_VERSION_INFO: grabs firmware build dates and version information
  • DIAG_CMD_ESN: grabs the CDMA device’s ESN, which is essentially the IMEI of a CDMA device
  • DIAG_CMD_NV_READ and DIAG_CMD_NV_WRITE: NVRAM read/write commands, see below
  • DIAG_CMD_SUBSYS: subsystem commands; see below
  • DIAG_CMD_STATUS_SNAPSHOT: gives information about the current state and registration of the device on the CDMA 1x network

But given that many aren’t really used anymore, Qualcomm started running out of command IDs a long time ago…


So Qualcomm used command 75 (DIAG_CMD_SUBSYS) to extended the number of available commands; this command takes a subsystem selector and a subsystem command ID, thus getting around the original 8-bit command ID limitation.

There are a number of standard subsystems (Call Manager, HDR Manager, WCDMA, GSM, GPS, etc) but each manufacturer generally implements their own subsystem too.  In this way QCDM isn’t that different from AT commands; while supposedly standardized, each manufacturer inevitably implements a bunch of proprietary commands for their own device because the specs simply don’t cover everything.  This just makes our life harder.

The currently identified subsystems are:

  • Call Manager: the most important command here reports the general state of the device, including the registered SID/NID, the terminal state (online/offline), the network mode (2G/3G), and various preferences that control which network the mobile registers with.  This is what we use to determine online/offline mode for CDMA devices since there aren’t any “standard” AT commands we can use to detect both 1x and EVDO registration.  Other commands start and end voice or data calls.
  • HDR (High Data Rate, ie EVDO): the most important command here provides EVDO state, which is mostly taken from the state machines specified in the IS-856 standard.  This lets us figure out if the modem is registered on the EVDO network or the CDMA 1x network.
  • Novatel: only implemented on Novatel Wireless devices, obviously.  But it provides access to a lot of stuff we want: the Extended Roaming Indicator (ERI) which shows detailed roaming state, the current access-technology the device is using (AMPS, digital, IS-95, CDMA 1x, EVDO r0, EVDO rA, etc), the voice mail and SMS indicators, and more.
  • ZTE: for ZTE devices, obviously. I actually did reverse engineer this one using a ZTE AC2726 kindly provided by Huzaifas S. from Red Hat India.  All we’ve got so far is the signal strength, the other fields of the command are unknown.

There are also GSM and WCDMA subsystems used with Qualcomm UMTS chipsets, but since most UMTS devices have multiple AT-capable ports we’re less interested in using QCDM there.

NVRAM Locations

Each device has a number of NVRAM locations in which it stores various parameters like mode preference, roaming, home networks, radio parameters, and a whole bunch of other stuff.  Not all devices implement every location.  I’ve only included the locations that we actually use in libqcdm, but there a couple thousand.  The ones we currently use are:

  • DIAG_NV_MODE_PREF: sets the mode preference: analog (ie AMPS), digital (TDMA), CDMA 1x, or EVDO (HDR)
  • DIAG_NV_DIR_NUMBER: retrieves your Mobile Directory Number (MDN), aka your phone #
  • DIAG_NV_ROAM_PREF: controls whether your device will roam on a partner network or not

The values each contains took a bit of time reverse-engineer using the Sprint connection manager, 3 different Sprint CDMA cards, and some USB traces, but now we’ve got the important parts.

Pulling It All Together

Earlier this year we had a number of bugs from Russian, Indian, and Czech Fedora users where ModemManager simply wouldn’t connect.  MM is pretty clever (a good thing) but the IS-707 AT commands aren’t useful enough to tell us what we need (not good).  The IS-707 standard AT+CAD? and AT+CSS commands really apply to the CDMA 1x network, not the EVDO network, and all these users had EVDO-only plans.  So when ModemManager checked AT+CSS and found that the device wasn’t registered, we sat around polling the registration state for a while.  The modem was already registered on the EVDO network, but not on a CDMA 1x network; of course AT+CSS doesn’t tell us that so MM got it wrong.

The real fix was to utilize QCDM and ask the Call Manager whether the modem was online or not, and if so, whether it had a 1x or an EVDO connection.  Sounds simple, but it took a lot of work to get there.

Next, since most CDMA devices only expose one AT-capable port, we need a way to get signal strength from the device while it’s connected and the primary port is talking PPP.  I’ll cover that in another blog post; stay tuned.  We still don’t have a good way to figure out which EVDO revision (either 0 or A) we’re using, nor can we get a reliable roaming indicator yet.

All of this is built in Fedora 12, 13, and rawhide if you’d like to take it for a spin.

The Kernel Side

Many devices provide the AT port via the standard CDC-ACM serial mechanism, which is picked up automatically by the kernel drivers.  But their QCDM-capable ports are only exposed via vendor-specific USB interfaces, so I created the qcaux driver to handle these ports; it’s in the 2.6.34 kernel.  With qcaux.ko and a recent version of ModemManager stuff will Just Work.

Why You Care

First a big shout to Qualcomm for keeping this shit secret.  NOT.  Double-plus-shout-out for keeping QMI secret; it’s a pretty simple protocol and there’s not much there worth keeping under wraps.  It might be nice to let open-source developers actually talk to your hardware.

With that out of the way, you care because we now have better support for a whole bunch of mobile broadband devices.  We even have support for CDMA signal strength while connected for the vast majority of CDMA devices that only expose one AT port.  I’ll talk about that later, since it’s quite an interesting story.

Why Sierra Wireless Rocks and Qualcomm Doesn’t

Buy Sierra stuff.  It’s top quality and they actually care about open-source, unlike Qualcomm’s mobile broadband division.  Last year I initiated a dialogue with Sierra about releasing some details of their proprietary Command and Status (CnS) protocol.  Being able to talk CnS to their modems gets us a lot that AT commands and even QCDM don’t provide, like roaming indicator, access technology, and RSSI.

And guess what?  They actually listened, did the work, and put the documentation under a Creative Commons license too.  I hear it’ll show up soon on their support site if it’s not there already (document #2131024, “CDMA 1xEV-DO CnS Reference”).

Sierra rocks.  Now if only Qualcomm would do it too…

Few Surprised at New Evidence of Staging Driver Suckage

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.

Whipping out the pipe snake

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

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.

NetworkManager and ConnMan

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.

Fedora 11 is out!!!!1111

There’s waaaay too much awesome going on in the Fedora community right now.  I mean it.  A TON.  So much it hurts.

If you don't run Fedora 11 he'll eat you...
If you don't run Fedora 11 he'll eat you...

Fedora 11 released, community rejoices

It’s out, no secret.  Install it. Packed with over 50 rocking features like faster startup, automatic font installation, DeviceKit, lickable kernel modesetting for Intel, ATI, and NVIDIA, Firefox 3.5, Gnome 2.26, ext4, KDE 4.2… THE AWESOME DOES NOT STOP.

So much hard work from the Fedora community went into Fedora 11 to make your life better.  Mad props to the Fedora Artwork team too, the graphics in F11 are stunning.  I started at Red Hat in 2003 during the Fedora Core 1 cycle, and with every Fedora release it’s been a great pleasure to watch how the community continues to grow rapidly and contributes so much more each release.  Fedora has truly been a community project for years now, and Fedora 11 shows just how great the community can be when everyone pulls together.  People are awesome.  Which brings us to the next stage…


If you have the right tools, tools that help you do what you came to do and don’t get in your way.  And that’s what Fedora Community is; it’s the next step in helping people make a better Fedora. Building better software like Fedora only gets you so far; to keep getting better you need to make the people that make the software better.  That means giving the community the tools it needs to be more efficient, turn ideas into features, and collaborate more effectively.  Fedora Community helps fill that need.  It only gets better from here.

Time for a Stalinist purge
Time for a Stalinist purge

HAL is dead; all hail udev

Over the past few days I’ve exorcised HAL from NetworkManager’s ‘master’ branch.  Instead, we go bare-metal with libgudev.  cgit’s diffstat lies, here are the real numbers:

 86 files changed, 5244 insertions(+), 6755 deletions(-)

Net loss of 1511 lines of code.  Not bad for a few days’ work.  Besides killing HAL, this patch merges nm-system-settings into NetworkManager.  Why do you care?  Here’s why: fewer running processes, less latency, and cleaner internal code.  We just keep scaling up from here.  Next up: nm-applet and ModemManager.

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?