My ThinkPad T61 laptop came equipped with a 3G device (described in its literature as Cingular WWAN). A different device (for another carrier) was also offered, but I chose this one as I believed the hardware to be useful in more areas. It took some fiddling to get working, which I've recorded here as it may be useful to others.

Note that I had never used the device before, under any OS, when starting this process.



The device is a Sierra Wireless model MC8775 PCI Express mini PCI card. It accepts a SIM card via a slot beneath the battery, which is inconvenient, but at least it can be replaced without shutting down the laptop by connecting it to mains power.

It is seen by the OS not on a PCI bus but via USB:

Bus 005 Device 010: ID 1199:6813 Sierra Wireless, Inc. 

and is correctly detected by the kernel and claimed by the sierra module:

[12916.029835] usb 5-1: new full speed USB device using uhci_hcd and address 10
[12916.196714] usb 5-1: configuration #1 chosen from 1 choice
[12916.198507] sierra 5-1:1.0: Sierra USB modem converter detected
[12916.202541] usb 5-1: Sierra USB modem converter now attached to ttyUSB0
[12916.202541] usb 5-1: Sierra USB modem converter now attached to ttyUSB1
[12916.202541] usb 5-1: Sierra USB modem converter now attached to ttyUSB2

resulting in three character devices corresponding to USB serial ports:

crw-rw---- 1 root dialout 188, 0 2008-08-17 11:01 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 2008-08-17 11:01 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 2 2008-08-17 11:01 /dev/ttyUSB2

The unit responds to common AT commands on both ttyUSB0 and ttyUSB2 (for which I used the modest cu though any terminal program will do). I believe it is meant to be possible to use one for a data connection and still issue commands on the other. ttyUSB1 is for the proprietary CNS (commands and status) protocol, which I believe is specific to Sierra devices. The standard ATI command shows some useful identifying information:

Manufacturer: Sierra Wireless, Inc.
Model: MC8775
Revision: H1_1_8_3MCAP C:/WS/FW/H1_1_8_3MCAP/MSM6280/SRC 2007/03/08 18:17:59
IMEI: 011265000022596
FSN: X281877076210
3GPP Release 5


This was an adventure unto itself. I had purchased the laptop in the US, but now lived in the UK, and thus could not use it with the intended provider (Cingular).

The modem indicates a provider lock by responding thus:


and refuses to do much of anything until it's been unlocked. In pursuit of the unlocking code, I read various forum threads and wiki pages, including:

with stories of variable success in obtaining the unlocking code from the OEM (IBM) or from the provider.

I tried IBM UK, who referred me to IBM US, who told me that:

  1. They could not give me an unlock code
  2. I would need to contact Cingular (with whom I had no relationship at all)
  3. By the way, my modem would not work in Europe

Fortunately, at least the last of these turned out to be false. As Sierra's web page proudly states, the unit "offers connectivity to all three HSDPA/UMTS frequency bands (850, 1900, 2100 MHz) and all four EDGE/GPRS bands (850, 900, 1800, and 1900 MHz) used worldwide, allowing seamless global roaming on the best available network."

One of the forum threads reported success using some dodgy unlocking software, which of course runs only under Windows. The unlocking operation costs money, but the site claimed that the software would detect the modem and check whether it could be unlocked before any payment would be required, so I set about trying to get this to work.

The simple solution would probably have been to install Windows (this laptop came with a license for it, which I've never used) on a spare hard drive. However, I didn't have one, and besides which, I enjoy a good puzzle. So, I set about trying to get this to work under KVM, which includes QEMU's feature to allow pass-through access to a USB device on the host. I installed Windows, downloaded the unlocker software and installed it without much trouble.

I ran KVM:

kvm ... -usb -usbdevice host:1199:6813

which initially failed to open the device:

Warning: could not add USB device host:1199:6813

The problem turned out to be that it relies on the obsolescent usbfs which is not mounted by default in Ubuntu (see bug 156085). Mounting usbfs worked around that easily enough.

The next problem was that using the device under KVM triggered bug 258771 where the guest OS would slow down to a crawl, pausing for seconds at a time. It worked, but was so slow that it would take a long time to do what I wanted.

This briefly led me to try -usbdevice serial instead (thanks to a patch from Samuel Thibault which is included in the Ubuntu package). Rather than providing access to the USB device itself, it emulates a USB serial port using a character device (or other suitable interface) on the host. This seemed much simpler, and would presumably avoid the bug. Unfortunately, I didn't get very far with it, as I wasn't able to talk to the modem at all. On further investigation, Samuel's post indicates that it doesn't support flow control or modem status lines, which is probably what defeated me.

So, I resolved to suffer through the slowness and try the unlocking software. Since this was a fresh Windows install, it did not include any drivers for the modem. This experience reminded me of how nice it is that Linux includes such a wealth of device drivers, so that one doesn't need to go searching for them. In retrospect, the simplest solution would probably have been to download the drivers from IBM, but that isn't what I did.

Instead, digging around in the unlocker program, I saw that it shipped with some drivers of its own. Unfortunately, they didn't match the device I had, but by hand-hacking the .INF files I was able to get them to work. I pointed Windows' new hardware wizard at the directory with the drivers, and it proceeded to install about five different drivers, creating several corresponding new devices:


The unlocker program still failed to automatically detect the modem, though. After some experimentation, I found that manually specifying the unlocker's "application" port to be the "AT command port" and its "diagnostic" port to be the "DM" port, it successfully detected the modem. It was then a matter of using the software as advertised to unlock the modem, which took some 15 minutes or so and reported success.

Deactivating low-power mode

The next challenge was that the indicator light wouldn't turn on. This turned out to be because the device was in a low-power state, which looks like this:

Current Time:  4415             Temperature: 39
Bootup Time:   4337             Mode:        LOW POWER MODE 
System mode:   GSM              PS state:    Not attached 
WCDMA band:    IMT2000          GSM band:    GSM900     
WCDMA channel: 10637            GSM channel: 1
GMM (PS) state:NULL             ---            
MM (CS) state: NULL             ---            

RX level (dBm):-94 (Not updated) 


and was fixed like this:


at which point the indicator light turned on.

Registering on a Network

At this point, the modem seemed functional, but wasn't registered with any network. This looks like this:

Current Time:  4754             Temperature: 39
Bootup Time:   4442             Mode:        ONLINE         
System mode:   WCDMA            PS state:    Not attached 
WCDMA band:    IMT2000          GSM band:    Unknown    
WCDMA channel: 10637            GSM channel: 65535
GMM (PS) state:DEREGISTERED     NO IMSI        
MM (CS) state: IDLE             NO IMSI        

RX level (dBm):-93

I had the best luck with setting the network settings to automatic, using the command:


(see the AT command reference in the Resources section to understand what this means)

Check whether a PIN is required:



and enter it:


a moment later, I get a message indicating that it has a signal now: +PACSP1

and the status display confirms:

Current Time:  5186             Temperature: 40
Bootup Time:   5082             Mode:        ONLINE         
System mode:   WCDMA            PS state:    Attached     
WCDMA band:    IMT2000          GSM band:    Unknown    
WCDMA channel: 10637            GSM channel: 65535
MM (CS) state: IDLE             NORMAL SERVICE 

RX level (dBm):-93


Connecting via ifupdown/pppd

If !GSTATUS looks good, you should be able to get online now using pppd. Sierra provides example pppd configuration files linked in the Resource section below. These required the usual provider-specific hackery (I tested with O2 in the UK) before they worked (disabling certain compression settings, for example). My setup is as follows:




connect '/usr/sbin/chat -v -t6 -f /etc/ppp/peers/gsm_chat'



SAY 'Initializing modem:\n'
'' AT
OK \c
SAY 'OK\n'

SAY "Checking PIN:\n"
SAY "OK\n"

SAY     'Setting APN:\n'
# Access Point Name (APN) 
# Incorrect APN or CGDCONT can often cause errors in connection.
# Below are a bunch of different popular APNs

#''     'AT+CGDCONT=0,"IP","proxy"'
#''     'AT+CGDCONT=1,"IP","proxy"
#''     'AT+CGDCONT=2,"IP","proxy"'
''      AT+CGDCONT=1,"IP",""
OK \c
SAY "OK\n"

SAY     'Dialing...\n'
OK ATD*99#
SAY "Connected.\n"

Network Manager

At least for my provider (O2), Network Manager must be manually configured with the APN ( in order to work. This means that the Auto GSM Connection option won't work, and a connection must be created manually. That, and my SIM PIN, were the only configuration necessary.

However (again, at least with O2) DNS wasn't configured correctly. I ended up with nonsense DNS servers ( and in /etc/resolv.conf. This is curious, since using pppd manually gets the correct DNS servers. I've filed bug 258801 about this.


SierraMC8775 (last edited 2010-01-26 22:29:24 by whoopie79)