Vodafone Mobile Broadband with a Huawei K3520/E169

Since I'll be even more remote from my office for a few days, due to acceptance of my talk about gatekeeping for SAGE-AU, I thought I should acquire one of those funky mobile broadband solutions so I could keep in contact with the gate.

It's been a bit of a pain to get working, but now it is I figure I should provide some details what I've done.

Firstly, a big thankyou to my mate Arjen who brought his Huawei E220 dongle over and let me muck around with it for a few hours.

The solution I chose was Vodafone's Mobile Prepaid Broadband, which comes with a Huawei E169, aka K3520 usb dongle. This has the increasingly popular "ZeroCD(tm)" feature - when you plug it in, it defaults to showing a storage device (usb device class 8) rather than as a communications device (usb device class 2). This storage device has the windows drivers and application on it, which then kicks the device into being a communications device. All good, or something, as long as you're running XP, Vista or Mac OS X.

Not so good, clearly, for yours truly.

A bunch of google hits came up with http://darkstar-solaris.blogspot.com/2008/10/huawei-e169-usb-umts-gprs-modem.html, http://www.opensolaris.org/jive/thread.jspa?messageID=272246, http://in.opensolaris.org/jive/thread.jspa?messageID=227212 and http://my2ndhead.blogspot.com/2008/11/opensolaris-huawei-e220-swisscom-and.html, which got me started - I need to use the usbsacm(7D) driver, so it was time to update_drv. Being a bit lazy, and suspecting that there'd be a few options that needed covering, I just hand-edited /etc/driver_aliases to add in all the possible compatible entries for the device (starting with usb12d1,1001.0). Still no joy - darn thing was still showing up as a storage device even after hotplugging.

On the off-chance that the attached-at-power-on state might be different I rebooted with it attached, ... lo and behold, it was different! No usb,class8, just compatible properties which allowed me to attach it to the usbsacm driver, and get 3 /dev/term entries. After a hotplug op, however, it was back to showing up as a storage device, which was most undesirable.

So I tried looking for what solutions the linux world has come up with to the problem, came across usb_modeswitch (which gave the clue that sending a "USB_REQ_SET_FEATURE, 00000001" would kick it properly), and also some Huawei forum posts.

One thread in particular caught my eye: Thread: K3520 (E169) microSD lost which featured a comment from a Huawei employee instructing the user to utter "at\^u2diag=255" in a hyperterm session in order to get back their microSD card slot.

So being inquisitive, and making a guess, when I had the dongle connected from boot, I ran

# tip /dev/term/0
connected
ATZ
OK
at\^u2diag=0
OK
~.
and hotplugged the device. On re-insertion (after waiting 1 minute), I saw that there was no storage device found, just usbsacm instances. W0000t!

So now all I had to do was trawl my memories to recall how to do ppp (eeeek!) and would be connectable.

Therein lies a lot of pain, so I'll cut straight to the "this works for me" part:

The aliases I've got in /etc/driver_aliases are

usbsacm "usb12d1,1001.0"
usbsacm "usb12d1,1001"

The peers file that I'm using is

/dev/huawei
720000
debug
logfile /var/tmp/pppd.log
crtscts
asyncmap a0000
idle 300
passive
defaultroute
usepeerdns
:0.0.0.0
noccp
novj
lcp-echo-interval 0
lock
modem
connect '/usr/bin/chat -s -t60 -f /etc/ppp/voda-chat'
noauth
persist

Note that I symlinked /dev/term/0 to /dev/huawei - purely because I wanted to.

The chat script is

ABORT 'BUSY'
ABORT 'NO CARRIER'
"" AT&F
OK AT\\136u2diag=0
OK ATE0V1E1X1\\136SYSCFG=2,2,3FFFFFFF,1,2
OK ATS7=60
OK AT+CGDCONT=1,"IP","vfprepaymbb"
OK AT+CGQMIN=1
OK AT+CGQREQ=1
OK "ATD \\052 99\\052\\052 2 \\043"
REPORT CONNECT ''
CONNECT

Note the use of octal characters - Solaris' /usr/bin/chat doesn't like the caret (\^), asterisk (\*) or hash (#) in a chat script, so you have to work around that by using \\136 for caret, \\052 for asterisk, and \\043 for hash. Also, note that the prepaid solution uses an Access Point Name (APN) of "vfprepaymbb" rather than the contract/postpaid "vfinternet.au".

The other thing of interest is the ":0.0.0.0" in the peers file. This is what I needed to add in order to get around the problem

[ID 702911 daemon.debug] Peer refused to provide his address; assuming 192.168.1.1

Once I'd done that, things seemed to work just fine. It was rather weird to see a ping time from my non-global zone to the laptop via 3G taking about 170msec even though both machines are within my arm's reach!

I just need to get some ip-up and ip-down scripts figured out, and then I'll be all raring to go.

One final thing, there are apparently a reasonably annoying bug with usbsacm:

6840063 usbsacm stops sending data out when pushed hard (fixed in snv_120), and an RFE

6588968 Provide support for 3G USB broadband modem device from Huawei Technologies.

I don't know for sure whether this works if you're not running snv_120, but rather than disabling a core, you could try

# pbind -b 0 `pgrep pppd`

as part of your ip-up script. I'm going to try it and see.

Comments:

The below site would be helpful for the people who are trying to make Huawei Modem work with OpenSolaris.

PROJECT Kyoto
http://chototsumoushinp.dip.jp/projectkyoto/home.html

You can find “Huawei USB Modem hot plug patch” and download it from their IPS Repository. It is worth trying. :)

Posted by Robinky Taiyo_k on August 14, 2009 at 02:59 AM EST #

Post a Comment:
Comments are closed for this entry.
About

I work at Oracle in the Solaris group. The opinions expressed here are entirely my own, and neither Oracle nor any other party necessarily agrees with them.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today