Connecting to 3G network, continued

My attempts to connect with the 3G network yesterday ended with a failed attempt to upgrade the firmware in this terminally broken ASUS RT-N13U router. Tried again today, in the process noting the messages that appeared during normal startup:

The messages in bold were logged with priority LOG_EMERG (“A panic condition. This is normally broadcast to all users.”), which vomited all over all my xterms. Why specifically these messages? And what doesn't get mentioned at all were the pppd messages, which show on the one hand that it appears to be attempting to connect, but it has some failure. Clearly not as much as serious as the discovery that a modem is connected. And the messages from named on dereel (there were many times the number shown here) shows the stupidity of limiting IP addresses to RFC 1918 ranges.

Tried the update again, and again it hung. So tried it with Microsoft “Windows XP” and “Internet Explorer”, and got further:

According to the instructions, “After receiving a correct firmware file, RT-N13U Rev.B1 will automatically start the upgrade process. The system reboots after the upgrading process is finished.” But it finished and still didn't reboot. When I rebooted manually, I still had the old firmware version.

Why am I having this trouble? I'm doing everything according to the bookslip of paper supplied with the router, using “standard” Microsoft tools, and it still doesn't work. That's a far cry from the NetComm 3G21WB router. Once I got past Telstra's broken software and installation procedure and used my own method, everything Just Worked. That was the rationale for buying this thing at all, to avoid setup problems; instead I've found a whole new range of them. Out of interest, I'll call ASUS after the Christmas break on Wednesday, but it's almost certain that it'll have to go back.

For the sake of completeness, tried to run the modem on boskoop, my old Apple machine. Again I couldn't get it to work, possibly because the machine only has USB 1.1 ports, which are conceivably not fast enough.

The real alternative, of course, is to use the modem directly on a FreeBSD box. I had avoided that because of the fear that the instructions would be even worse. I was right.

I'm not the first person to use this kind of modem on FreeBSD, but there are no canonical instructions. A number of people on my IRC channel have done so, and Edwin Groothuis has written not one, but several web pages on the subject. This one appears to be a collection of all the others, conveniently arranged in almost reverse chronological order. Other interesting pages are Simple way to use Huawei E1762 (Maxis Broadband) on FreeBSD 8, Nick Hibma's ppp.conf files (there's also a home page), and a partial list of AT commands for 3G modems. Jürgen Lock came up with a 3GPP specification detail which looks like the minutes of countless meetings, but with lots of links. If they contain what I hope, I might finally find the command set, but at the moment it looks like too much trouble. Nick Hibma also pointed at a command reference for the EWM770W, but both versions (http://www.letswireless.com.cn/en/down/download.asp?id=48&t=cn and http://www.letswireless.com.cn/en/down/download.asp?id=48&t=en were in Chinese—not the first time a knowledge of Chinese would have helped here.

It would be nice to say that all the instructions say the same thing, but they don't:

• Azril (not sure of the real name) starts by stating that you need entries for /etc/devd.conf, which in fact don't seem to be necessary. He then points to Nick Hibma's configuration files.

• Nick's files don't have very much to do with Edwin's files. Took a look at both of them and tried to work out what they mean. Nick has this chat script:

  set dial "ABORT BUSY TIMEOUT 2 \
         \"\" \
         AT OK-AT-OK \
         AT+CFUN=1 OK-AT-OK \
         AT+CMEE=2 OK-AT-OK \
         AT+CSQ OK \
         AT+CGDCONT=1,\\"IP\\",\\"internet\\" OK \
         AT+CGACT? OK-AT-OK \
         AT+CGATT? OK \
         AT+CGCLASS? OK \
         AT+COPS? OK \
         ATD*99***1# CONNECT"
  

  By contrast, Edwin has:

  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"
  

  What do those commands mean? It seems that the important ones are AT+COPS, which sets the network operator, and AT+CGDCONT, which defines the PDP (Packet Data Protocol) context. And clearly they're different for the two configurations. But what are the rest? At least we get a log of what's going on (/var/log/ppp.log), which in contrast to the toy routers is so voluminous that it's difficult to find your way through. Discovered that the ATE1Q0 in Edwin's script caused the chat script to fail, so removed that, and finally came up with something that connected, got as far as successful authentication, and then failed in the IPCP phase:

  Dec 26 15:08:56 swamp ppp[1114]: tun0: IPCP:  IPADDR[6] 192.109.197.138
  Dec 26 15:08:59 swamp ppp[1114]: tun0: IPCP: deflink: SendConfigReq(2) state = Req-Sent
  Dec 26 15:08:59 swamp ppp[1114]: tun0: IPCP:  IPADDR[6] 192.109.197.138
  Dec 26 15:09:02 swamp ppp[1114]: tun0: IPCP: deflink: LayerFinish.
  Dec 26 15:09:02 swamp ppp[1114]: tun0: IPCP: Connect time: 16 secs: 0 octets in, 0 octets out
  Dec 26 15:09:02 swamp ppp[1114]: tun0: IPCP: 0 packets in, 0 packets out
  Dec 26 15:09:02 swamp ppp[1114]: tun0: IPCP:  total 0 bytes/sec, peak 0 bytes/sec on Sun Dec 26 15:08:46 2010
  Dec 26 15:09:02 swamp ppp[1114]: tun0: IPCP: deflink: State change Req-Sent --> Stopped
  

  That's pretty much what Edwin described in one of his pages, but I had already applied his workaround. Then I looked at his log more carefully: he had offered the IP address 10.0.0.1. And that was in his ppp.conf, but in mine it was commented out. Removed the comment, and success!

The problem here, of course, is knowing what went wrong. The message from IPCP didn't exactly explain the problem. Time to update the PPP chapter of The Complete FreeBSD. In any case, here's roughly what I have in my ppp.conf. The user name and password (authname and authkey) are invalid, of course, but the dial string should work for anybody. I have disabled a lot of things because others have done so; I'll play around and see if they're necessary. I have also disabled DNS because I run my own name servers.

There's lots of other information. By default, when it is inserted, you get a lot of messages from the kernel:

I'll need to investigate these in more detail later. It also creates a whole slew of devices:

/dev/cuaU0.0 is the modem device itself. Thanks to Peter Jeremy, discovered that the modem returns continuous status information from one of its other ports. On my system, it's /dev/cuaU0.3, but it seems that there are other possibilities:

According to Peter,

• ^MODE is the link mode. 5,6 and 5,7 are HSUPA and HSPA but I'm not sure which way round - 5,5 is HSDPA.

• Not sure what ^BOOT is.

• ^RSSI is signal strength: 0..31 => n*2 - 113 dBm. 99 => unknown. Mostly in e169-stats.c

• ^DSFLOWRPT should be link uptime, tx data in last 2 secs, rx data in last 2 secs, cumulative tx data, cumulative rx data. Not sure of the last two fields.

• And apart from ^DSFLOWRPT, other fields only get reported when they change.

That'll give me something to investigate.

And the result? Not good. I had already noted extremely long ping times when running in GPRS mode, but they haven't gone away. I'm still getting things like:

All five of these ping replies arrived at the same time. What's causing that? I don't know, but it's not acceptable. One thing might be the signal strength, but that doesn't tally with my experience with GPRS, where it happened even with moderate signal strength. And monitoring RSSI show that there's no correlation between signal strength and these delays. Hopefully it's something that can be fixed. I didn't have anything like this in the Telstra network, and I'd hate to have to change back after this investment.

Did a test with speedtest.net, which didn't show any of those problems. Here's a comparison with satellite a few days ago (left) and to Internode in Adelaide today:

Clearly the speed of the satellite is better. If it weren't for the latency and the unreliability, I'd stay with satellite. But then, the signal strength I'm getting now is no better (possibly worse) than I got with the whip antenna. Maybe I'm pointing at the wrong mobile tower. I need to calculate some directions and try pointing at different towers. For reference, here's my location and the locations given from the Spench web site, the latter specified with a precision of 11 nm (0.0000011 mm):

Location		°S		°E
Dereel		-37.8185		143.739473
Willowvale		-37.8599992656466		143.480816856065
Cressy		-38.0328135174848		143.608488690057
Smythesdale		-37.6580344944195		143.684741395296