By jmcp on Aug 11, 2009
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.
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
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.