… to shoot myself in the head. Some mobile broadband cards are like a nice, quiet child that does everything you tell them to do; they’d even clean out your family’s slurry tank if you asked. Unfortunately, most of the cards you just want to throw right into the slurry tank strapped to the side of a large brick. Hopefully the tank is full, and the card doesn’t have a snorkel, not that a snorkel would help it much.

Yes, there are standards. But as we all know, given 10 people and a standard, you’ll end the day with 12 or 13 differently behaving “standards-compliant” implementations. People suck. You’d think it would be easy to agree on an AT command for “prefer 3G / prefer 2G / 3G only / 2G only”. NO SIMPLE FOR YOU. But NetworkManager has to work around huge amounts of stupid. Here’s a run-down of some of the mobile broadband hardware that’s available today and what about it sucks.

HUAWEI (PHEAR THE DRAGON)

Europe apparently got carpet-bombed with these things. They provide two usable serial ports; one for data and another for stuff like signal strength, mode switches, etc. But asking it anything on the second port makes the modem cry, grab its toys, and run home to tell mommy what you’ve done. This caused problems with the new modem capability probing code in NetworkManager 0.7.1. Thanks guys (not). Dropping unhandled input on the floor would apparently have been too easy. And, of course, they use AT^SYSCFG with some magic numbers to indicate 2G/3G preference. That said, Huawei does participate upstream and proactively adds IDs and support for their hardware.

Qualcomm Gobi (NEW HOTNESS ALERT)

Apparently now all the rage State-side (though they’ve been out for a while); even in the ultra-small Atom-based Poulsbong-smoking Sony Vaio P series. These parts can do GSM/HSPA and CDMA/EVDO, depending on the firmware they load. Now that’s pretty cool. There’s even a driver for them (qcserial) queued up in gregkh’s tree. Unfortunately, because Qualcomm still can’t get their head out of their ass you won’t get signal strength, cell tower reports, or mode change signals, since the driver only exposes one serial port which is used for PPP (it might support GSM multiplexing, in which case this rant is wrong). Everything else seems to get done from userspace with libusb and a proprietary protocol. WTF is so awesome about proprietary protocols? You get to sell people an SDK for $20,000 or something? Nice try.

Modern Sierra (MAGICALLY DELICIOUS)

Driven by the ‘sierra’ driver (surprise!), these cards expose multiple serial ports; two or more of which accept AT commands. Only one of these ports has a full AT interpreter and gets used for PPP, the other ports get used for signal strength and GPS during the PPP session. I hear new Sierra gear is switching to the tty+netdevice model though, so these will be old-but-not-busted soon. But of course, somebody took a huge pull off the bong, and came up with AT!SELRAT for 2G/3G preference. Yay! Variation #2!

Old-School Sierra (OLD BUT NOT BUSTED)

Sweet bliss. Works like a champ. 16-bit PCMCIA. HSDPA even. GSM multiplexing support makes up for the fact that it only exposes one serial port to the OS (even though we don’t support userspace muxing yet). It’s been supported in NetworkManager since, like, day #1. Like the newer Sierra cards, it also uses AT!SELRAT, so at least Sierra is consistent. Which is more than I can say for some other hardware I’ve seen.

Option “HSO” (THE NEED FOR SPEED)

PPP sucks; it’s only between you and the card, not over the air. So why bother? Which is why Option killed PPP dead. These devices expose multiple AT-capable ttys, and an ethernet network interface. Do the setup on the AT ports, do the data in high speed on the network interface. This is the current trend. Sierra is going to do it soon. So is Huawei. But unfortunately, everyone does the authentication and the IP configuration differently. And Option’s 2G/3G preference command is AT_OPSYS. Variant #3! Go to hell. In any case, big thanks to Option for providing me with hardware and also working with the upstream kernel community; you guys rock.

Ericsson F3507g (SWEDISH INVASION)

Dude, you got a Dell Mini? If you’ve coughed up for the 5530 Mobile Broadband option, it’s probably got one of these inside. The Sony Ericsson MD300 is the same hardware. For once, somebody uses standard interfaces too; these parts expose multiple cdc-acm serial ports (like most mobile phones), and one cdc-ether network device used for data. The interesting thing is that to get an IP address, you use DHCP on the ethernet interface. We don’t yet know how to set 2G/3G preference, but you can get it with AT*ERINFO. All hail variant #4. This is getting rediculous. At least Ericsson pays people to make their stuff work with Linux, though the AT reference document is NDA-encumbered. Need to hit somebody with the cluebat for that.

BUSlink SCWi275u (DEAR GOD DON’T BUY THIS)

Really. If you find one, put it out of its misery by burning it alive. Yeah, it’s really old, and it’s only GPRS, and it’s from the land before time when they put WiFi into cellular modems because nobody had it onboard. And hey, its firmware is as clueless about standards as Qualcomm is about Open Source. But it works fine with NetworkManager

As you can see, nobody in this industry talks to each other, and none of the carriers care about making it easier to write software for the devices they sell. Everywhere you look there are silos, walled gardens, and revenue stream protection. But that’s where NetworkManager comes in.

The Bright, Shiny New Mobile Future

NM 0.7 delivered the promise of Mobile Broadband. We took a limited set of devices (ie, no phones) and made those work out of the box. Now it’s time to get bigger, faster, and stronger. We can’t support everything in the current architecture inside NetworkManager, so Tambet started a new project called ModemManager. All mobile broadband handling gets punted out to ModemManager (similar to how WiFi is handled with wpa_supplicant), making the NetworkManager core simpler, easier to maintain, and more robust. ModemManager provides a nice D-Bus API for everything modem-related; data connections, SMS, phonebook, signal strength, GPS, etc. It rocks. It’s more flexible. It spews out cute, cuddly kittens by the thousands. It’s definitely the right architecture and the way forward.

The Slightly Less-Bright Now

But until ModemManager drops some awesome on y’all, we need to better support modems in NetworkManager 0.7.x too. A few problems we’ve been tackling over the past few months:

multiple serial ports – most modems provide more than one port; but nothing tells you what that port gets used for. Sometimes asking the port what’s purpose in life is doesn’t work either. So we have to special-case some modems in the udev prober, and some in NetworkManager. This gets as ugly as your first girlfriend/boyfriend.

– most modems provide more than one port; but nothing tells you what that port gets used for. Sometimes asking the port what’s purpose in life is doesn’t work either. So we have to special-case some modems in the udev prober, and some in NetworkManager. This gets as ugly as your first girlfriend/boyfriend. modem capabilities – this is why your mobile phone didn’t work with NetworkManager 0.7.0. We need to know whether the modem is CDMA/EVDO or GSM/HSPA since the operation and UI needs to change based on which kind of modem it is. Previously we used hal-info’s 10-modem.fdi, which simply doesn’t scale. Asking the modem freaks some of them out (ie, Huawei) and others just lie for various reasons. So with NM 0.7.1, we probe serial ports with a udev helper and are careful not to touch things that shouldn’t be touched.

– this is why your mobile phone didn’t work with NetworkManager 0.7.0. We need to know whether the modem is CDMA/EVDO or GSM/HSPA since the operation and UI needs to change based on which kind of modem it is. Previously we used hal-info’s 10-modem.fdi, which simply doesn’t scale. Asking the modem freaks some of them out (ie, Huawei) and others just lie for various reasons. So with NM 0.7.1, we probe serial ports with a udev helper and are careful not to touch things that shouldn’t be touched. modem init strings – because, of course, consistent handling of initialization strings between devices would just be too easy. Some devices puke up half-eaten puppies when given the same init string that every other device on the planet supports. No standardization here. So NetworkManager 0.7.1 tries different init strings until one works.

– because, of course, consistent handling of initialization strings between devices would just be too easy. Some devices puke up half-eaten puppies when given the same init string that every other device on the planet supports. No standardization here. So NetworkManager 0.7.1 tries different init strings until one works. registration commands – some Huawei modems want to use AT+CGREG instead of AT+CREG. Yeah, I know why it seems to think it can be special, but it’s not. It’s just plain stupid. And this seems to change based on firmware version of all things. Dear God, why do you toy with me? So in lieu of finding a Huawei engineer and asking them what the fuck they were thinking, we hacked around it for now.

We’ve gotten most of worked out in the NetworkManager 0.7.1 release candidate series. And all this crap is exactly why NM 0.7.1 isn’t out yet. Like when NM 0.7.1-rc1 broke people’s Huawei cards due to modem probing freaking out the firmware, I spent $100 for a Huawei E160G off eBay. It took a week to get here, and two days to fix it.

But that’s why NetworkManager rocks; we pony up the cash to make sure our shit works. Users appreciate that.