MavEtJu's Distorted View of the World - 3G
FreeBSD laptop as a Wireless Access Point for an iPhone3, iPhone and international roaming
STS-127 and 3G
Huawei E169 statistics
FreeBSD and the Huawei E169 USB 3G Modem - Step two
FreeBSD and the Huawei E169 USB 3G Modem - Step one
Three Mobile roaming 3G network
FreeBSD and the Huawei E220 USB 3G Modem
Back to index
FreeBSD laptop as a Wireless Access Point for an iPhone
Posted on 2011-01-12 18:00:00
Tags: FreeBSD, 3G, Networking, Free Internet, iPhone
Recently I was on a holiday where the provider of my iPhone had no signal, but where the provider of my 3G modem for the laptop did have a signal. At least my glass was half-full!
In the past I have tried to setup Bluetooth between my laptop and my iPhone, and that resulted in a night of hard work and no effort. This time I tried a different approach: Instead of using Bluetooth for communication, I transformed the FreeBSD laptop into a wireless access point.
The command to change the wireless card from a normal client to a wireless access point are:
[~] edwin@lappie>cat wlan-iphone #!/bin/sh ifconfig wlan0 destroy ifconfig wlan0 create \ wlandev ath0 \ wlanmode hostap \ bssid \ authmode open \ ssid "My iPhone WiFi" ifconfig wlan0 up ifconfig wlan0 inet 10.0.0.1 netmask 255.255.255.0 sleep 1 sysctl -a net.inet.ip.forwarding=1 service isc-dhcpd restart
Notes:
- Experiment with the "open" authmode before you set it to a more secure alternative. Get things working first, then secure then properly.
- The interface "ath0" is the Atheros wireless interface of this laptop.
The 3G connection is setup via ppp(8) and to enable NAT on the outgoing packets, you need to enter the following command or add it to the right label in your ppp.conf:
ppp ON lappie> dial Ppp ON lappie> PPp ON lappie> PPp ON lappie> Warning: 0.0.0.0/0: Change route failed: errno: No such process PPP ON lappie> nat enable yes PPP ON lappie>
And to make sure that the connected clients get their IP address, you should run the ISC DHCP server with for example the following configuration:
option domain-name "";
option domain-name-servers 8.8.8.8;
default-lease-time 150;
max-lease-time 300;
ddns-update-style none;
authoritative;
log-facility local7;
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.10 10.0.0.99;
option routers 10.0.0.1;
}
Notes:
- 8.8.8.8 is the Google DNS server.
Everything is working now, your glass is full again! :-)
Show comment | Share on Facebook | Share on Twitter
3, iPhone and international roaming
Posted on 2010-07-18 23:00:00, modified on 2010-07-18 18:00:00
Tags: iPhone, 3G, Travelling
While being in San Francisco this week and in Sunnyvale next week, I informed with my provider, 3 in this case, about the charges for access to the 3G network internationally. That was kind of a shock, they wanted to have AU$ 20 per megabyte. I quickly rejected that option :-)
But I did enable roaming for my voice calls, so imagine my annoyance when I came here and the telephone said "No Carrier" (which brought a lot of memories back about the time I played with modems :-). So I called the 3 helpdesk (via Skype, charging me 10 cents per minute (still cheaper than the GSM call :-) and they said I had to change from "Automatic selection" to a manual select of "AT&T" and it all worked.
still some wires which need to be crossed manually for this, but at least I am reachable again!
Next trick is to find out why I'm awake in the middle of the night. Oh yeah, jetlag :-(
Show 4 comments | Share on Facebook | Share on Twitter
STS-127 and 3G
Posted on 2009-07-11 11:00:00
Tags: Space, 3G
I'm in a inside childrens playground in Nowra (2 hours south of where we live) and while Dirkie is experimenting with slides and friction and Hanorah is trying to put matching blocks together, thanks to the powers of 3G and a laptop I can still can do some of the things I want to do (Which isn't writing weblog entries :-)
Right now I'm streaming the pre-launch video of the launch of the STS-127 Space Shuttle mission. According to the e169-stats program, it downloads about 600 kilobytes per minute. Per hour that is 36 megabytes. Per day that is 864 megabytes. With less than 24 hours to go for the scheduled launch tomorrow at 09:36 AM Sydney time (we're playing the waiting game now), this will cost me less than 1/5th of my monthly total. If I would leave it on for the next 24 hours that is.
Right now the video is the Space Shuttle on the launchpad with not much happening - Now and then a bird flies by, somebody walks in front of a light etc. It must be very cheap MPEG encoding: Just send one full frame and nearly zero-length update frames.
Yay go STS-127!
No comments | Share on Facebook | Share on Twitter
Huawei E169 statistics
Posted on 2009-06-04 08:00:00
Tags: FreeBSD, Huawei E169, 3G
As written earlier about, the Huawei E169 3G USB modem works like a charm on FreeBSD 7.2. On my trips with the train in the morning to work and in the afternoon from work I am able to do some work on catching up on email and keeping up with the news websites. Yay for a good technology.
The only thing I hadn't managed so far was to getting information from the device to about the amount of traffic uploaded and downloaded, the signal strength and the connection-type used (3G, 2G etc). I knew that the device had three modem ports, one used for the PPP connection but the other two were a mystery so far, until I heard one day that I should use cat(1) instead of tail(1) on them. And yes, that one gave me data!
There are five interesting pieces of text reported:
^BOOT - of which I have no idea what it is for. The values always seem the same, very boring. It is the only field which comes without a change of the data, the others only come when a piece of the data is changed.
^DSFLOWRPT - the most interesting part: It contains the uptime of the PPP connection (always a 2 second interval if there is a modem connection), the number of bytes received and sent out in the last interval, the number of bytes received and sent since the PPP connection got started and two numbers which I don't know what they are for.
^MODE - which tells me if the modem light is cyan, darblue, green or off.
^RSSI - Receiving signal strength, an indication if you are in a tunnel, in a hilly area or close by a basestation.
^SRVST - Not sure yet... It seems to have to be done with which provider you are linked up with and it seems to be toggling between 0 and 4.
So three days later on the train-trip I had mastered ncurses(3x) and created a nice overview of what the 3G modem thinks about my connection:
This screenshot was taken between Kirrawee station and Sutherland station, while checking the contents of the items in the ABC and BBC RSS feeds.
The stats at the top left are just the data as known at this moment. The -1 of the SRVST means we hadn't received that data yet. The table at the top right is the amount of downloaded data during those minute. And the graph at the bottom indicates the signal strength in the last N * 2 seconds.
If you have a Huawei E169 and interested in knowing what is happening, the FreeBSD port is available as net/e169-stats.
Show 6 comments | Share on Facebook | Share on Twitter
FreeBSD and the Huawei E169 USB 3G Modem - Step two
Posted on 2009-04-27 21:00:00
Tags: Huawei E169, FreeBSD, Networking, 3G
The story so far... An upgrade to FreeBSD 7.2, X not working, something goes wrong in the IPCP layer, a non-working MacOS/X upgrade and in need of a firmware upgrade.
When I put the E169 in the first Windows machine I found, it kind of died a horrible way: it kept telling me that it had found new hardware and when I was lucky enough, I managed to run it before it decided that it had found new hardware again. Flashing it to a new firmware version was a little bit optimistic for that machine!
Today I took it the E169 modem with me to work and during lunch I put it in a Windows machine there. It installed without an itch, it connected to the Virgin network and it downloaded at a wopping speed of 150 kbps. Now why did it work there and how did it achieve it?
I found a program called Advanced Serial Port Monitor which kind of puts itself between the Windows COM port drive and the Windows kernel and displays what is being said between the client and the hardware.
The client program said "AT+CGMM?" and the modem said "E169". The client program said "AT^CARDLOCK?" and the modem said "^CARDLOCK: 2,10,0" (any idea?). The client program said "AT+CIMI" and the modem said "5050299062636465". And the client program said "AT+COPS?" and the modem said "+COPS: 1,0,"YES OPTUS",2". And a lot of other AT commands were issued, but unfortunately the client program didn't want to dial out while the monitor was running...
Unfortunately, none of the AT commands helped me from getting a proper CONNECT string (CONNECT 7200000 was the one I was looking for) and getting the IPCP part of the PPP initialisation working.
None of this helped. I kept looking and looking and suddenly I saw this one being executed instead of the "YES OPTUS" one: "AT+COPS=1,2,"50502",2". It didn't make much sense, but never tried is always miss. And I ended up with a CONNECT 7200000 and a full PPP handshake session. Bingo!
So, at the end, we ended up with the following configuration on the modem (just in case it differs from yours and it doesn't work):
and the following ppp.conf:ati Manufacturer: huawei Model: E169 Revision: 11.314.17.00.261 IMEI: 351029385479124 +GCAP: +CGSM,+DS,+ES at&v &C: 2; &D: 2; &E: 0; &F: 0; &S: 0; &W: 0; E: 1; L: 0; M: 0; Q: 0; V: 1; X: 0; Z: 0; \Q: 3; \S: 0; \V: 0; S0: 0; S2: 43; S3: 13; S4: 10; S5: 8; S6: 2; S7: 50; S8: 2; S9: 6; S10: 14; S11: 95; S30: 0; S103: 1; S104: 1; +FCLASS: 0; +ICF: 3,3; +IFC: 2,2; +IPR: 115200; +DR: 0; +DS: 0,0,2048,6; +WS46: 12; +CBST: 0,0,1; +CRLP: (61,61,48,6,0),(61,61,48,6,1),(240,240,52,6,2); +CV120: 1,1,1,0,0,0; +CHSN: 0,0,0,0; +CSSN: 0,0; +CREG: 0; +CGREG: 0; +CFUN:; +CSCS: "IRA"; +CSTA: 129; +CR: 0; +CRC: 0; +CMEE: 2; +CGDCONT: (1,"IP","VirginBroadband","0.0.0.0",0,0) ; +CGDSCONT: ; +CGTFT: ; +CGEQREQ: (1,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(2,2,0,0, 0,0,2,0,"0E0","0E0",3,0,0),(3,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(4,2,0,0,0,0,2,0, "0E0","0E0",3,0,0),(5,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(6,2,0,0,0,0,2,0,"0E0","0 E0",3,0,0),(7,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(8,2,0,0,0,0,2,0,"0E0","0E0",3,0, 0),(9,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(10,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(11, 2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(12,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(13,2,0,0, 0,0,2,0,"0E0","0E0",3,0,0),(14,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(15,2,0,0,0,0,2, 0,"0E0","0E0",3,0,0),(16,2,0,0,0,0,2,0,"0E0","0E0",3,0,0) ; +CGEQMIN: ; +CGQREQ: ; +CGQMIN: ; ; +CGEREP: 0,0; +CGCLASS: "B"; +CGSMS: 1; +CSMS: 0; +CMGF: 0; +CSAS: 0; +CRES: 0; +CSCA: "+61411990010",145; +CSMP: ,,0,0; +CSDH: 0; +CSCB: 0,"",""; +FDD: 0; +FAR: 0; +FCL: 0; +FIT: 0,0; +ES: ,,; +ESA: 0,,,,0,0,255,; +CMOD: 0; +CVHU: 1; ; +CPIN: , ; +CMEC: 0,0,0; +CKPD: 1,1; +CGATT: 1; +CGACT: 0; +CPBS: "SM"; +CPMS: "SM","SM","SM"; +CNMI: 0,0,0,0,0; +CMMS: 2; +FTS: 0; +FRS: 0; +FTH: 3; +FRH: 3; +FTM: 96; +FRM: 96; +CCUG: 0,0,0; +COPS: 1,0,""; +CUSD: 0; +CAOC: 1; +CCWA: 0; +CCLK: ""; +CLVL: 4; +CMUT: 0; +CPOL: 0,2,"",0,0,0; +CPLS: 0; +CTZR: 0; +CTZU: 0; +CLIP: 0; +COLP: 0; +CDIP: 0; +CLIR: 0; ^PORTSEL: 0; ^CPIN: , ; ^ATRECORD: 0; ^FREQLOCK: 12805096,13050984; ^CVOICE: 0; ^DDSETEX: 0
virgin:
set mru 1440
set device /dev/cuaU0.0
set speed 115200
set phone *99\#
set authname VirginBroadband
set authkey VirginBroadband
deny chap
disable deflate
disable pred1
disable vjcomp
disable mppe
enable dns
accept dns
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
\"\" AT OK-AT-OK ATE1Q0 OK \
AT+COPS=1,2,"50502",2 OK \
AT+CGDCONT=1,\\\"IP\\\",\\\"VirginBroadband\\\" OK \
\\dATDT\\T TIMEOUT 40 CONNECT"
set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
add default HISADDR
This only brings up the issue with X: Starting X with the E169 modem
plugged in did make it start the X graphical screen but it failed
to start the window manager and the mouse was unresponsive. Taking
out the modem resulted in going back to the console.
Starting X without the E169 modem plugged in started everything up
but after plugging in the modem the whole system became unresponsive.
Taking out the modem and everything worked again.
I got a hint from Callum on #bugs that I should try x11-servers/xorg-server without hald support. A recompile later and X and the mouse works with the modem plugged in, but the keyboard didn't work yet. Adding these four lines to my xorg.conf overcame the problem:
Section "ServerFlags"
Option "AllowEmptyInput" "False"
Option "AutoAddDevices" "False"
EndSectionShort version: The E169 modem works with FreeBSD 7.2 out of the box, Xorg 7.4 works with four extra lines in the config, the XFCE window manager works, everybody is happy!
Show 4 comments | Share on Facebook | Share on Twitter
FreeBSD and the Huawei E169 USB 3G Modem - Step one
Posted on 2009-04-25 19:00:00
Tags: Huawei E169, FreeBSD, Networking, 3G
Earlier this century I had a Huawei E220 USB 3G modem in my possession and believe it or not, after some fiddling and hacking I got it working under FreeBSD 6.x. (Un)fortunately I quit my job and had to give it back.
Overtime it got more and more difficult to find 3G provide who offered a E220 and I had given up on ever running 3G on my FreeBSD laptop again until I saw a commit of Poul-Henning Kamp which said "Make the ubsa(4) work with Huawei Exxx (tested with E169) 3G radio devices".
It took me still quiet a couple of months before I dared to go looking for a replacement and last week I found out that Virgin shop was the only 3G provider who could tell me from their head which brand and model USB modem they provided. And it was a Huawei E169! Life would be sweet again!
Luckily the commit by Poul wasn't too big and I was able to backport it to the 7.1 release running on my laptop and oh boy... It didn't really work yet. For some reason it did the same as my previous modem did before:
It still didn't finish the IPCP layer! I checked the APN, which is VirginBroadband. And I remembered what I did last time: I had to put it in a Windows machien before it worked. I still don't understand this, but okay.$ ppp virgin ppp> dial Ppp> PPp>
Stopping the PPP program caused a kernel panic. Rebooting the machine without stopping the PPP program caused a kernel panic. Starting X while the USB modem was in caused in a hanging X. Putting the USB modem in while X was running caused a hanging keyboard. Fsck was very upset with me, every time.
So, later I found a commit of Nick Hibma which said "Say hello to the u3g driver, implementing support for 3G modems." plus a bunch of follow-up commits with fixes. And, it was backported into RELENG_7! So I upgraded my laptop to 7.2 (RC1 or something) and rebooted.... It didn't recognize the USB modem at the first attempt, but when I loaded the u3g.ko kernel module it recognized both the modem and the disk part of it! No more patches, it is all vanilla 7.2.
But for some reason it did the same as my previous attempt did before:
That kind of euhm... sucks bigtime.$ ppp virgin ppp> dial Ppp> PPp>
I don't have a Windows machine, but I do have access a MacOSX machine which should be supported out of the box! The USB modem goes into the MacOSX machine, the software gets installed and I click on the "Connect" button. It says "Connecting" and it comes back with "Connection failed". Euhm...
Looking further, it seems that the program SetNetworkConfig gets called when you press the Connect button and it crashes. At least it gives me some kind of hint where to go next: I need to get newer software, either from Huawei E169 download page or from Virgin Broadband website. The installer of this puts the new software runs on the USB modem and for some reason it only works on a Windows machines.
So tomorrow I'm going to find me a Windows machine, put the USB modem in it, see if it works with Virgin 3G, then see if it then works on my FreeBSD machine, if not then upgrade the software first, see if it still works on the Windows machine and then see if it gets to work on the FreeBSD machine.
Lots of adventures are pending!
Show comment | Share on Facebook | Share on Twitter
Three Mobile roaming 3G network
Posted on 2008-05-01 08:00:00, modified on 2008-07-14 16:00:00
Tags: Networking, FreeBSD, 3G
Thanks to my job, or cursed by my job sometimes, I have access to a 3G modem of Three Mobile. It works fine in areas where there is Three Mobile coverage, outside these areas were we are roaming (and probably on the Telstra 3G network) there are interesting issues with the IPCP phase (IP Confirguration Protocol) of PPP which make the PPP setup fail.
So what works and what doesn't? According to the PPP manual, this is what we should see:
The first two Ps become capitals, but the third one doesn't when we are roaming.ppp ON awfulhak> # No link has been established Ppp ON awfulhak> # We've connected & finished LCP PPp ON awfulhak> # We've authenticated PPP ON awfulhak> # We've agreed IP numbers
What do the logs say? The short version of a successful handshake is:
The full log is at the end of this writeup.IPCP: FSM: Using "deflink" as a transport IPCP: deflink: State change Initial --> Closed IPCP: deflink: LayerStart. IPCP: deflink: SendConfigReq(1) state = Closed IPCP: deflink: State change Closed --> Req-Sent IPCP: deflink: RecvConfigNak(1) state = Req-Sent IPCP: deflink: SendConfigReq(2) state = Req-Sent IPCP: deflink: RecvConfigNak(2) state = Req-Sent IPCP: deflink: SendConfigReq(3) state = Req-Sent IPCP: deflink: RecvConfigReq(0) state = Req-Sent IPCP: deflink: SendConfigNak(0) state = Req-Sent IPCP: deflink: RecvConfigRej(3) state = Req-Sent IPCP: deflink: SendConfigReq(4) state = Req-Sent IPCP: deflink: RecvConfigReq(1) state = Req-Sent IPCP: deflink: SendConfigAck(1) state = Req-Sent IPCP: deflink: State change Req-Sent --> Ack-Sent IPCP: deflink: RecvConfigNak(4) state = Ack-Sent IPCP: deflink: SendConfigReq(5) state = Ack-Sent IPCP: deflink: RecvConfigAck(5) state = Ack-Sent IPCP: deflink: State change Ack-Sent --> Opened
The discussion goes like this: I propose something three times (SendConfigReq) and they reject it (RecvConfigNak), but at the third time they say "Let's try it with this" (RecvConfigReq) and we come up with a common ground. And everybody is happy!
The short version of an unsuccessful handshake is:
The full log is at the end of this writeup.IPCP: FSM: Using "deflink" as a transport IPCP: deflink: State change Initial --> Closed IPCP: deflink: LayerStart. IPCP: deflink: SendConfigReq(1) state = Closed IPCP: deflink: State change Closed --> Req-Sent IPCP: deflink: RecvConfigNak(1) state = Req-Sent IPCP: deflink: SendConfigReq(2) state = Req-Sent IPCP: deflink: RecvConfigNak(2) state = Req-Sent IPCP: deflink: SendConfigReq(3) state = Req-Sent IPCP: deflink: RecvConfigNak(3) state = Req-Sent IPCP: deflink: SendConfigReq(4) state = Req-Sent IPCP: deflink: RecvConfigNak(4) state = Req-Sent IPCP: deflink: SendConfigReq(5) state = Req-Sent IPCP: deflink: RecvConfigNak(5) state = Req-Sent IPCP: deflink: SendConfigReq(6) state = Req-Sent IPCP: deflink: RecvConfigNak(6) state = Req-Sent IPCP: deflink: SendConfigReq(7) state = Req-Sent IPCP: deflink: RecvConfigNak(7) state = Req-Sent IPCP: deflink: SendConfigReq(8) state = Req-Sent IPCP: deflink: RecvConfigNak(8) state = Req-Sent IPCP: deflink: SendConfigReq(9) state = Req-Sent IPCP: deflink: RecvConfigNak(9) state = Req-Sent IPCP: deflink: SendConfigReq(10) state = Req-Sent IPCP: deflink: RecvConfigNak(10) state = Req-Sent IPCP: deflink: SendConfigReq(11) state = Req-Sent IPCP: deflink: SendTerminateReq(11) state = Req-Sent IPCP: deflink: State change Req-Sent --> Closing IPCP: deflink: RecvTerminateAck(11) state = Closing IPCP: deflink: LayerFinish. IPCP: deflink: State change Closing --> Closed IPCP: deflink: RecvConfigNak(11), dropped (expected 12)
Here there are only SendConfigReq and RecvConfigNak, there is no RecvConfigReq coming from them!
If anybody has managed to setup a successful PPP connection on the 3G network of anybody but Three Mobile can send me some logs, I would be very happy to see if I can fix things.
Update According to John Marshall, sending a string similar to this:
could resolve the issue. Next time when I'm in the roaming-zone I'll try it!AT+CGDCONT=1,"IP","telstra.internet"
It worked, when I used "3netaccess" as the indentifier.
Here are the full logs:
This is the IPCP part of a successful handshake
ppp[1098]: tun0: Phase: bundle: Network ppp[1098]: tun0: IPCP: FSM: Using "deflink" as a transport ppp[1098]: tun0: IPCP: deflink: State change Initial --> Closed ppp[1098]: tun0: IPCP: deflink: LayerStart. ppp[1098]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.76.66 ppp[1098]: tun0: IPCP: SECDNS[6] 255.255.255.255 ppp[1098]: tun0: IPCP: deflink: State change Closed --> Req-Sent ppp[1098]: tun0: LCP: deflink: RecvProtocolRej(2) state = Opened ppp[1098]: tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected! ppp[1098]: tun0: CCP: deflink: State change Req-Sent --> Stopped ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(1) state = Req-Sent ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1098]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1098]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1098]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: SendConfigReq(2) state = Req-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(2) state = Req-Sent ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1098]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1098]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1098]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: SendConfigReq(3) state = Req-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: RecvConfigReq(0) state = Req-Sent ppp[1098]: tun0: IPCP: [EMPTY] ppp[1098]: tun0: IPCP: deflink: SendConfigNak(0) state = Req-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 10.0.0.2 ppp[1098]: tun0: IPCP: deflink: RecvConfigRej(3) state = Req-Sent ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression ppp[1098]: tun0: IPCP: deflink: SendConfigReq(4) state = Req-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: RecvConfigReq(1) state = Req-Sent ppp[1098]: tun0: IPCP: [EMPTY] ppp[1098]: tun0: IPCP: deflink: SendConfigAck(1) state = Req-Sent ppp[1098]: tun0: IPCP: [EMPTY] ppp[1098]: tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(4) state = Ack-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 119.11.8.120 ppp[1098]: tun0: IPCP: IPADDR[6] changing address: 0.0.0.0 --> 119.11.8.120 ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.68.130 ppp[1098]: tun0: IPCP: SECDNS[6] 202.124.76.66 ppp[1098]: tun0: IPCP: Primary nameserver set to 202.124.68.130 ppp[1098]: tun0: IPCP: Secondary nameserver set to 202.124.76.66 ppp[1098]: tun0: IPCP: deflink: SendConfigReq(5) state = Ack-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 119.11.8.120 ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.68.130 ppp[1098]: tun0: IPCP: SECDNS[6] 202.124.76.66 ppp[1098]: tun0: IPCP: deflink: RecvConfigAck(5) state = Ack-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 119.11.8.120 ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.68.130 ppp[1098]: tun0: IPCP: SECDNS[6] 202.124.76.66 ppp[1098]: tun0: IPCP: deflink: State change Ack-Sent --> Opened ppp[1098]: tun0: IPCP: deflink: LayerUp.
This is the IPCP part of a unsuccessful handshake
ppp[1661]: tun0: Phase: bundle: Network ppp[1661]: tun0: IPCP: FSM: Using "deflink" as a transport ppp[1661]: tun0: IPCP: deflink: State change Initial --> Closed ppp[1661]: tun0: IPCP: deflink: LayerStart. ppp[1661]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: State change Closed --> Req-Sent ppp[1661]: tun0: LCP: deflink: RecvProtocolRej(2) state = Opened ppp[1661]: tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected! ppp[1661]: tun0: CCP: deflink: State change Req-Sent --> Stopped ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(1) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(2) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(2) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(3) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(3) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(4) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(4) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(5) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(5) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(6) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(6) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(7) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(7) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(8) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(8) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(9) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(9) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(10) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(10) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(11) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: Command: /dev/ttyp1: quit ppp[1661]: tun0: IPCP: deflink: SendTerminateReq(11) state = Req-Sent ppp[1661]: tun0: IPCP: deflink: State change Req-Sent --> Closing ppp[1661]: tun0: IPCP: deflink: RecvTerminateAck(11) state = Closing ppp[1661]: tun0: IPCP: deflink: LayerFinish. ppp[1661]: tun0: IPCP: Connect time: 11 secs: 0 octets in, 0 octets out ppp[1661]: tun0: IPCP: 0 packets in, 0 packets out ppp[1661]: tun0: IPCP: total 0 bytes/sec, peak 0 bytes/sec on Thu Apr 24 13:39:49 2008 ppp[1661]: tun0: IPCP: deflink: State change Closing --> Closed ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(11), dropped (expected 12) ppp[1661]: tun0: Phase: bundle: Terminate
No comments | Share on Facebook | Share on Twitter
FreeBSD and the Huawei E220 USB 3G Modem
Posted on 2007-12-14 21:00:00, modified on 2007-12-17 07:30:00
Tags: Huawei E220, FreeBSD, Networking, 3G
I'm the lucky owner of a Huawei E220 3G USB modem. For certain degrees of lucky that is: Getting it to work has been an interesting challenge.
The E220 is by default (FreeBSD 6.3-BETA) recognized as an umass(4) (USB Mass Storage Device) device. That's true, there is a memory disk in it. It is recognized as /dev/cd0 and you can mount it with mount_cd9660 /dev/cd0 /mnt, giving you 10 megabytes of space.
But that is not what you bought the E220 for. You want to use it
as a modem. You need to change a couple things in your kernel to
get it all working.
First, add a line to /sys/dev/usb/usbdevs:
See the
FreeBSD PR usb/118686 for a full patch.
And to /sys/dev/usb/usba.c:
/* HP products */
product HP2 C500 0x6002 PhotoSmart C500
/* HUAWEI products */
product HUAWEI MOBILE 0x1001 Huawei Mobile
+product HUAWEI E220 0x1003 Huawei E220 HSDPA USB Modem
/* IBM Corporation */
product IBM USBCDROMDRIVE 0x4427 USB CD-ROM Drive
{ USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3G },
/* Option GlobeTrotter 3G QUAD */
{ USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GQUAD },
/* Huawei Mobile */
{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_MOBILE },
+{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E220 },
{ 0, 0 }
};
Second, you have to disable the umass(4) device from your kernel configuration and rebuild a new kernel. Will this break things? Most likely, specially when you have USB disks and sticks. But you will load it as a module, which will undo the damage you just did to it. In your /boot/loader.conf, add the following lines:
ubsa_load="YES"
umass_load="YES"
ubsa(4) is the USB support for Belkin serial adapter. That sounds more like a modem. Next, reboot the machine and see if all modules are loaded correctly:
# kldstat
Id Refs Address Size Name
1 20 0xc0400000 72e17c kernel
2 1 0xc0b2f000 e6a4 if_iwi.ko
3 3 0xc0b3e000 2f9c firmware.ko
4 1 0xc0b41000 6cdc ugen.ko
5 1 0xc0b48000 75b4 umass.ko
6 1 0xc0b50000 7958 ng_ubt.ko
7 2 0xc0b58000 cb78 netgraph.ko
8 1 0xc0b65000 2ef0 ubsa.ko
9 2 0xc0b68000 4374 ucom.ko
10 1 0xc0b6d000 5c304 acpi.ko
11 1 0xc4868000 30000 iwi_bss.ko
Next, plugin your E220 and see what happens:
ucom0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
ucom0: Could not find interrupt in
device_attach: ucom0 attach returned 6
Yes! No! Something is wrong. But a little bit of finger skill will
resolve it:
At the USB modem side of the USB cable (not the computer side!),
carefully pull the cable from the modem and when you see this on
your screen, plug it back in:
ucom0: at uhub1 port 1 (addr 2) disconnected
ucom0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
It's loaded! If it doesn't work at the first go, try it a couple
of times more. Once you are without the dreaded "Couldn't find
interrupt in" message you are a happy person.
Check /dev/cuaaU0, it exists! If you have comms/minicom installed, you can do this:
OK
ATI
Manufacturer: huawei
Model: E220
Revision: 11.117.06.00.100
IMEI: 358191018517800
+GCAP: +CGSM,+DS,+ES
OK
And if you dial out, you will end up with a whooping 7.2Mbps connection;
OK
ATDT *90#
CONNECT 7200000
Now it is time to train ppp(1). Add this to your /etc/ppp/ppp.conf:
three:
set device /dev/cuaU0
set speed 57600
set phone *99\#
set authname
set authkey
set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
set vj slotcomp off
add default HISADDR
And dial:
$ ppp three
ppp> dial
Ppp>
PPp>
That's not good, there should be three capital P's... Going through the PPP log, you will see that the IPCP layer doesn't get initialized properly. Why? No idea. How to resolve it? Put your USB modem in a windows machine, run it once there and put it back into your FreeBSD machine. Why? No idea. It works. The USB modem didn't work with under MacOS/X neither until I did this trick. Why? No idea. It works.
Dial again:
$ ppp three
ppp> dial
Ppp>
PPp>
PPP>
$ ifconfig tun0
tun0: flags=8051 mtu 1500
inet 119.11.32.164 --> 10.0.0.2 netmask 0xffffffff
Opened by PID 22997
$ ping www.freebsd.org
PING www.freebsd.org (69.147.83.33): 56 data bytes
64 bytes from 69.147.83.33: icmp_seq=0 ttl=48 time=477.662 ms
64 bytes from 69.147.83.33: icmp_seq=1 ttl=51 time=416.606 ms
^C
--- www.freebsd.org ping statistics ---
3 packets transmitted, 2 packets received, 33% packet loss
round-trip min/avg/max/stddev = 416.606/447.134/477.662/30.528 ms
Your console and /var/log/messages will be spammed with "kernel: ucom0: usba_request: STALLED" messages for some reason, but it works.
Show 2 comments | Share on Facebook | Share on Twitter