Linux on the Dell Latitude 2110 n-series
My boss recently suggested that he’d like me to be more available on the road and out of town. I frequently travel to places with no net connection, and this was proving to be a problem when we had sysadmin issues at work. To that end, he agreed to buy me a netbook with a data plan. The Dell Latitude 2110n had all of the features I wanted, namely, the new Intel Atom N470 (Pineview) processor, a solid state disk, and an embedded mobile broadband card. And it came preloaded with Ubuntu Netbook Edition, meaning that I felt confident that I wouldn’t have compatibility or driver issues running Linux on the hardware.
Well, I should not have been so confident.
The first discovery upon booting up was that there were no wireless drivers present in the preinstalled Ubuntu 9.10 image. There were a few wireless card options when I configured the order, and I happened to select the Dell Wireless 1501 card, which is, in reality, a Broadcom 4313. Interestingly, this choice is now gone and the only option available for orders today is the Wireless 1520 card. Apparently, I chose the old option. It was kind of impossible to tell which was better.
Thankfully, Linux drivers for this card exist, and they should’ve been available directly from Ubuntu via the bcmwl-kernel-source package, but for reasons I did not investigate very thoroughly, the wl kernel module would not detect the hardware (maybe an old version that doesn’t know the Dell hardware address?). Instead, I had to download the STA/wl driver directly from Broadcom and compile it by hand.
Next, I decided I wanted to try a pared down distro, rather than the flashy and featureful but potentially battery-sapping Ubuntu. So I installed the alpha version of Crunchbang Linux (now based directly on Debian (that’s good!)). Unfortunately, I discovered that the kernel version in Crunchbang was too old to support the ethernet port driver (that’s bad!). So, I quickly dumped Crunchbang and decided to install Debian Squeeze instead. After updating to the latest kernel from Sid, ethernet worked. Hooray!
With that sorted, I turned my attention to the mobile broadband card. It’s branded as a Dell Wireless 5620, but in reality it’s a Qualcomm GOBI 2000 (this much was apparent at purchase – it’s listed by the Qualcomm model rather than the Dell model in the configurator on the Dell Store).
After the wireless fiasco, I feared that there may be no drivers available for the Gobi card, and these fears were soon confirmed, as I could find none from either Dell or Qualcomm. In fact, upon entering my Dell Service Tag into support.dell.com, I discovered that my only OS choices for driver downloads were Windows 7 and Windows XP. Despite mine being the ‘n-series’ model that ships exclusively with Linux. Hmm…
The Gobi 2000 is unique among mobile broadband cards, and it’s one of the reasons I went with the Dell. It supports both GSM and CDMA, and I didn’t want to be locked to one or two providers. As I learned, it does this by loading carrier-specific firmware at boot-time. And I was encouraged to find that loading such firmware had been done under Linux before using gobi_loader. I applied the gobi_loader patches to the Sid kernel’s source and recompiled, but then thought better of running it. I had never tested the device under Ubuntu and started to wonder if it had already worked when the hardware shipped.
So at this point, I decided to reinstall Ubuntu, and found the reinstaller on Dell’s recovery partition. Unfortunately, this resulted in such a broken grub install that I couldn’t even load grub modules. After screwing with that for too long, I had had enough and installed Ubuntu Nebook Edition 10.04 (Lucid) from a USB drive.
Encouraged by findings on ThinkWiki where someone posted his experience extracting the firmware from Lenovo’s Windows driver for the Gobi, I downloaded Dell’s Windows drivers and unzipped the self-extracting .exe. Contained within were:
Utility/ Utility/Setup.exe Utility/Models.zip Drivers/ Drivers/XP/ Drivers/XP/x86/ Drivers/XP/x86/qcfilterdl2k.cat Drivers/XP/x86/qcfilterdl2k.inf Drivers/XP/x86/qcfilterdl2k.sys Drivers/XP/x86/qcmdmdl2k.inf Drivers/XP/x86/qcnetdl2k.inf Drivers/XP/x86/qcserdl2k.inf Drivers/XP/x86/qcusbnetdl2k.cat Drivers/XP/x86/qcusbnetdl2k.sys Drivers/XP/x86/qcusbserdl2k.cat Drivers/XP/x86/qcusbserdl2k.sys Drivers/XP/x64/ … (same as x86) Drivers/Win7/ … (same as XP)
None of the driver files were the firmware. As seen on ThinkWiki, the Lenovo driver exracts the firmware with the correct name right on the filesystem, but apparently Dell’s were all contained in the installer, which was not a self-extracting .exe. I considered running the Lenovo firmware, but was worried that the firmware might differ by vendor, which could damage or brick the hardware. Probably not since it’s all Qualcomm, but generic providers like LSI do release rebrand-specific firmware for stuff like array disks.
So, I headed on over to an XP VM and extracted the driver, and tried to run the installer. No dice, you immediately get punted from the app, with the helpful message “Incompatible platform.” I suspected the Models.zip in the same folder contained the criteria of what it could be installed on, but annoyingly, it was password protected. Andy suggeseted that I run the installer from the command line with the /? flag, which was a great idea since it gave me a few options, one of which was /vEXTRACTDRIVERS. Well, I got excited for nothing, because all this option did was copy the already-extracted files from the Drivers/ directory to the current directory. Useless.
But eventually, after a lot more screwing around, I thought to run cabextract on the installer, and got a whole bunch of files with annoying generated names:
_062ABFE6150045B98BFE34CE46B105A9.AA6CA6091BA24C2D8E86939D9B2B7961 _0D8AF8E08A2A41BF9DF0E6369820073B.AA6CA6091BA24C2D8E86939D9B2B7961 _1399D3D2AB15428390AB9541D41069F9 _18D8D1860AC74D6C96798DB49BCBEE1B
After comparing the file sizes on these against the Lenovo drivers, I discovered that they must be the wayward firmware files! Tracking down which was which required using the Lenovo drivers. Since I was getting service with Verizon, I checked against the files in Lenovo’s “1” directory. amss.mbn and apps.mbn were easy:
% ls -l GOBI/Images/Lenovo/1 -rw-r--r-- 1 nate nate 6582324 Jun 3 09:19 amss.mbn -rw-r--r-- 1 nate nate 3022892 Jun 3 09:19 apps.mbn -rw-r--r-- 1 nate nate 17136 Jun 3 09:19 UQCN.mbn % ls -l Utility | grep 6582324 -rw-r--r-- 1 nate nate 6582324 Apr 13 2009 _787710DE0BD94E448E3842AA0DFE048E % ls -l Utility | grep 3022892 -rw-r--r-- 1 nate nate 3022892 Apr 13 2009 _BEC5B34A5031495589E922B092DAEB4F
UQCN.mbn was a problem:
%ls -l Utility | grep 17136 -rw-r--r-- 1 nate nate 17136 Nov 6 2009 _3211A3D6ECFF46B9935C71744C6F9129 -rw-r--r-- 1 nate nate 17136 Nov 6 2009 _7682FE3BC2AC49BE84D7167C0E55F4AC -rw-r--r-- 1 nate nate 17136 Nov 6 2009 _9F7902055BCC477B942A596DB3283512
But thankfully, strings(1) provided the answer:
% strings GOBI/Images/Lenovo/1/UQCN.mbn > uqcn.strings % strings Utility/_3211A3D6ECFF46B9935C71744C6F9129 > 3211.strings % strings Utility/_7682FE3BC2AC49BE84D7167C0E55F4AC > 7682.strings % strings Utility/_9F7902055BCC477B942A596DB3283512 > 9f79.strings % diff uqcn.strings 3211.strings … junk snipped 99c97 < 02-c2k_vzw-00256-017 --- > 02-c2k_vzw_nogps-00257-017 % diff uqcn.strings 7682.strings … junk snipped %diff uqcn.strings 9f79.strings … junk snipped 99c95 < 02-c2k_vzw-00256-017 --- > 02-c2k_vzw_noxtra-00256-145
“nogps” would seem to be self-explanatory. I don’t know what “noxtra” is, but both the Lenovo UQCN.mbn and Dell _7682FE3BC2AC49BE84D7167C0E55F4AC had matching “ 02-c2k_vzw-00256-017” on that line of the `strings`, so I took that file to be UQCN.mbn. I can’t explain the other differences in strings output (the “junk”), but suppose it could be differing vendor IDs or a newer firmware version (although it’d be surprising that the file sizes matched, then).
Regardless, I put the following files in /lib/firmware/gobi:
_787710DE0BD94E448E3842AA0DFE048E → amss.mbn
_BEC5B34A5031495589E922B092DAEB4F → apps.mbn
_7682FE3BC2AC49BE84D7167C0E55F4AC → UQCN.mbn
Then, using the steps from response #33 in this bug in Launchpad, I rebuilt the qcserial and option kernel modules, and built the new usb_wwan one. Upon module installation, gobi_loader installation, and a reboot, the device finally existed, and was even recognized by NetworkManager!
Alas, my woes were far from over.
One annoying feature of CDMA networks is that since there is no SIM to register, the device itself must be registered, and this cannot be done by the provider, it must be initiated on the device itself. This is easy with a phone. You dial *228, hit option 1 and a few minutes later you’re provisioned. There’s also a quick way, by dialing *22899, and then you’ll be provisioned without prompting.
But how do I dial *228? It turns out, mobile broadband modems are just modems – initiate a serial connection and you send it AT commands just like the old 300 baud. But unfortunately, nothing I tried worked. As I eventually figured out, I think this is supposed to be the way, but my modem just returned ‘ERROR’ to the service programming command (AT+WSPC), despite getting the correct code from Verizon:
AT+WSPC=1,Your Verizon ESID (000000 if you’re lucky)
AT+WMDN=Your Verizon MDM number (usually your phone number)
AT+WIMI=31000Your Verizon MIN number (usually your phone number)
As far as I know, no one has ever activated a device on Verizon under Linux, except perhaps back when there was a Verizon Access Manager (VZAM), their official dialer, for Linux. If they have, they’ve never written how they did it. If you have done it, please comment and tell us how. Regardless, right now, my modem works. How did I do this, if I couldn’t get it to provision?
First, I tried running VZAM under a Windows VM via VirtualBox. The Dell driver would not install because “Incompatible platform.”
Next, I tried running the Dell driver installer under BartPE. “Incompatible platform.”
Finally, I just gave up and installed XP natively. Success. After doing this, I was able to reinstall Ubuntu and use the modem. Yes, I had to install Windows to run one crappy Windows app to do the activation, and then I was free to get rid of it. I’d really like to know what that Verizon app did. But whatever, it works now.
One final note: throughout all of this, I communicated with Dell and Verizon a bunch of times. My first call to Dell looking for drivers got me routed over to the (overseas…) Dell Ubuntu support group, who told me to post on ubuntuforums.org and “someone will post the drivers,” despite my insistence that such drivers did not exist freely. Qualcomm does not directly release them – all vendors selling Gobi cards release their own drivers, and the above proves that Dell has the firmware.
This was not a very acceptable answer for someone I’m paying money to for support. It’s not like I expect everything should work as easily under Linux as it does under Windows, but I want a better answer than “gee, that’s too bad.” If you’re a hardware vendor selling a Linux model of a system, it should at least work, even if I have to do some work to make it work.
Surprisingly, the people at Verizon seemed to understand my issue, but couldn’t help. They punted me back to Dell’s Ubuntu group, and I hung up before it connected.
Finally, I got my case escalated and the Dell escalation engineer knew exactly what the problem was. He was very sympathetic and told me that the Gobi card being orderable with Linux is a mistake, and should be removed from the store configurator. He couldn’t help, although by that point, I didn’t need it. He did say if I needed it, he might’ve been able to round up the firmware for me, which was encouraging to hear. It’s a shame they don’t just stick it up on the drivers site in a plain archive with a README explaining which firmware maps to which provider, but perhaps this is due to some sort of legal situation with Qualcomm. I don’t know.
Filed under: everything | 7 Comments
Tags: dell, gobi, gobi 2000, latitude 2110, linux, netbook, ubuntu, ubuntu nbr, ubuntu netbook