Computer :(

/home/rrix:blog:tags:cgit:rss

The Battle to Get Online

Update: Two things. 1) I changed my APN to "internet.t-mobile" got me up to full 3.5G UMTS. 2) I re-read the Huawei AT command set documentation and got something similar to working reliably. The magic incantation is AT+COPS=1,2,310260,0 which translates to, roughly, "Change Operator to GSM operator 310260". The 310260 is a tuple of MCC and MNC. This helpful wikipedia article is a look in to the mad insanity of the mobile telephony industry, but also explains that the 310 MCC 260 MNC tuple is for T-Mobile US. That got me online ~5 minutes after bootup instead of the usual 30-60 minutes I was seeing. I shoved that in to my startup scripts, and I basically just let pppd fail until the COPS action doesn't return a CME error. The latest version of these scripts are in my Kickass Systems CGIT repository. I'm eliminating the non-functioning ones from this post.

I've made some steady progress on the body computing system project since my last update. There's still a lot of struggling left to do, which makes this a tough project since I want to get it done in time for the Bay Area Maker Faire, like I've been planning to do. I haven't spent very much time at all with the Sleeve interface and the Atmel parts of the system, focusing instead on the main brain interface in an effort to get that solid enough to move a portion of my mobile computing on to. The single biggest struggle that I've had is getting the fucking brain online, and getting the peripherals attached to the brain:

Getting the Peripherals Attached

We'll start here since it's a solved problem, mostly. The Brain is built around a Raspberry Pi B+1, and I'd like it to not need a screen and a keyboard attached to it to, but I'll still need to do longer-form things, hence the InterfaceKit system I want to have built. I decided to use 802.11 so that I didn't have cords running out of my pocket, and went down the rabbit hole of getting wireless working all around

MiFi-type hotspots

These things are nifty, right? You turn them on, they give you a wifi hotspot that you can connect all your devices to and get online. Unfortunately, the ones I have all perform client isolation and I could not find a way to disable that. Like, at all. I tried three of them. Terrible. So I could get the Pi online by configuring wpa_supplicant to talk to the hotspot, but I couldn't get a phone to talk to the Pi, no matter what I tried.

Now, I could use my cute little GL.iNet pocket router as a hotspot, but that would end up sending me down the route of insanity I'm about to describe, anyways, so let's use hostapd instead.

Hostapd PAN

Cool, so, this should be super easy. hostapd is an industry standard piece of kit, and supports a wide range of hardware and operating modes, even 802.11ac! But, wait, why doesn't it see my device? This is where the insanity begins. I purchased a mini 802.11b/g/n adapter from adafruit. Great piece of kit, it's fast, it's tiny, it works OOTB with the kernel shipped with Raspbian and Pidora. But, hostapd didn't see it. Why for this?

In short, hostapd upstream doesn't support the Realtek RTL8188CUS chipset at all. Realtek carries a fork of hostapd that supports this chipset, which as of 8643eccb9fd881d7c10c16244b6c9514d0ea509e I compile on the device during the make install command. I should move it to make but that comes after the MVP.

Cool, so now I can talk to the device, I just have to bundle a legally questionable tarball with the project. Fuck me.

Getting the Pi online

If I used the GL.iNet, I'd have to get ppp working with it. For the unitiated, PPP is the protocol which is used for cellular connectivity, dialup and DSL. It's pretty fucking janky, but it works decently.

I gave up on that route, because supporting two/three distinct operating systems and codebases for this project sounds like an insane proposition. So, let's get PPP working directly on the pi.

So, setting up hostapd and dhcpd allowed any device I wanted to to hop online and chat with the pi, but there is still no external connectivity. Enter our next actor, pppd. pppd, in essence, talks the ppp protocol, and coordinates things like dialup and authentication. It's all pretty straightforward2, and I began trying to figure out how to get pppd to speak to the T-Mobile SIM in my Huawei E220 modem. I don't need LTE, I don't need high speed, I would be satisfied with 3.5G or 3G connectivity for my project.

pppd Configuration

I re-read the Huawei AT command set documentation and got something similar to working reliably. The magic incantation is AT+COPS=1,2,310260,0 which translates to, roughly, "Change Operator to GSM operator 310260". The 310260 is a tuple of MCC and MNC. This helpful wikipedia article is a look in to the mad insanity of the mobile telephony industry, but also explains that the 310 MCC 260 MNC tuple is for T-Mobile US. That got me online ~5 minutes after bootup instead of the usual 30-60 minutes I was seeing. I shoved that in to my startup scripts, and I basically just let pppd fail until the COPS action doesn't return a CME error.

/etc/ppp/peers/tmobile: The file which pppd consumes

A pair of chat scripts, which handle the AT commands3 which the tmobile hotspot needs to get to a connected state:

/etc/chatscripts/tmobile and /etc/chatscripts/tmobile-disconnect

After a few minutes, the system should connect to the Operator's network and put you online.

[root@pidora ~]# /usr/sbin/pppd call tmobile debug dump nodetach
pppd options in effect:
debug debug             # (from command line)
nodetach                # (from command line)
holdoff 3               # (from /etc/ppp/peers/tmobile)
persist         # (from /etc/ppp/peers/tmobile)
dump            # (from command line)
noauth          # (from /etc/ppp/peers/tmobile)
user user               # (from /etc/ppp/peers/tmobile)
password ??????         # (from /etc/ppp/peers/tmobile)
/dev/ttyUSB0            # (from /etc/ppp/peers/tmobile)
115200          # (from /etc/ppp/peers/tmobile)
lock            # (from /etc/ppp/peers/tmobile)
connect /usr/sbin/chat -v -f /etc/chatscripts/tmobile           # (from /etc/ppp/peers/tmobile)
disconnect /usr/sbin/chat -v -f /etc/chatscripts/tmobile-disconnect             # (from /etc/ppp/peers/tmobile)
crtscts         # (from /etc/ppp/peers/tmobile)
lcp-echo-failure 12             # (from /etc/ppp/peers/tmobile)
lcp-echo-interval 3             # (from /etc/ppp/peers/tmobile)
show-password           # (from /etc/ppp/peers/tmobile)
novj            # (from /etc/ppp/peers/tmobile)
novjccomp               # (from /etc/ppp/peers/tmobile)
ipcp-accept-local               # (from /etc/ppp/peers/tmobile)
noipdefault             # (from /etc/ppp/peers/tmobile)
defaultroute            # (from /etc/ppp/peers/tmobile)
usepeerdns              # (from /etc/ppp/peers/tmobile)
Starting GPRS connect script
Setting APN
Dialing...
Script /usr/sbin/chat -v -f /etc/chatscripts/tmobile finished (pid 2269), status = 0x0
Serial connection established.
using channel 39
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x2fb5a0f2> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x58 <mru 1440> <asyncmap 0x0> <auth chap MD5> <magic 0x1476b05> <pcomp> <accomp>]
sent [LCP ConfAck id=0x58 <mru 1440> <asyncmap 0x0> <auth chap MD5> <magic 0x1476b05> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x1 <mru 1440>]
sent [LCP ConfReq id=0x2 <mru 1440> <asyncmap 0x0> <magic 0x2fb5a0f2> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <mru 1440> <asyncmap 0x0> <magic 0x2fb5a0f2> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x2fb5a0f2]
rcvd [LCP DiscReq id=0x59 magic=0x1476b05]
rcvd [CHAP Challenge id=0x1 <e62f99d61a1318e370848e41aef698f3>, name = "UMTS_CHAP_SRVR"]
sent [CHAP Response id=0x1 <5fade88bf917baab4af375f3b8347e18>, name = "user"]
rcvd [LCP EchoRep id=0x0 magic=0x1476b05 2f b5 a0 f2]
rcvd [CHAP Success id=0x1 ""]
CHAP authentication succeeded
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [LCP ProtRej id=0x5a 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfReq id=0x2]
sent [IPCP ConfNak id=0x2 <addr 0.0.0.0>]
rcvd [IPCP ConfRej id=0x2 <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14>]
rcvd [IPCP ConfReq id=0x3]
sent [IPCP ConfAck id=0x3]
rcvd [IPCP ConfNak id=0x3 <addr 21.121.57.67> <ms-dns1 10.177.0.34> <ms-dns2 10.176.83.140>]
sent [IPCP ConfReq id=0x4 <addr 21.121.57.67> <ms-dns1 10.177.0.34> <ms-dns2 10.176.83.140>]
rcvd [IPCP ConfAck id=0x4 <addr 21.121.57.67> <ms-dns1 10.177.0.34> <ms-dns2 10.176.83.140>]
Could not determine remote IP address: defaulting to 10.64.64.64
local  IP address 21.121.57.67
remote IP address 10.64.64.64
primary   DNS address 10.177.0.34
secondary DNS address 10.176.83.140
Script /etc/ppp/ip-up started (pid 2272)
Script /etc/ppp/ip-up finished (pid 2272), status = 0x0
sent [LCP EchoReq id=0x1 magic=0x2fb5a0f2]
rcvd [LCP EchoRep id=0x1 magic=0x1476b05 2f b5 a0 f2]

For a while, I was having an issue where it would spin in a "IPCP ConfReq" "IPCP ConfNak" state, where the modem tries repeatedly to get an IP from TMobile and fails. This is usually alleviated by keeping the device powered on long enough for the tower to discover it. This was alleviated by just having the script restart itself a few times with the COPS command in it.

Connect: ppp0 <--> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x59e05710> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1440> <asyncmap 0x0> <auth chap MD5> <magic 0xc9b3a4> <pcomp> <accomp>]
sent [LCP ConfAck id=0x0 <mru 1440> <asyncmap 0x0> <auth chap MD5> <magic 0xc9b3a4> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x1 <mru 1440>]
sent [LCP ConfReq id=0x2 <mru 1440> <asyncmap 0x0> <magic 0x59e05710> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <mru 1440> <asyncmap 0x0> <magic 0x59e05710> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x59e05710]
rcvd [LCP DiscReq id=0x1 magic=0xc9b3a4]
rcvd [CHAP Challenge id=0x1 <42c010c31a91be80fe83285f80c9f15c>, name = "UMTS_CHAP_SRVR"]
sent [CHAP Response id=0x1 <31d85e5335439f2f9dec9a62c460abd2>, name = "user"]
rcvd [LCP EchoRep id=0x0 magic=0xc9b3a4 59 e0 57 10]
rcvd [CHAP Success id=0x1 ""]
CHAP authentication succeeded
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [LCP EchoReq id=0x1 magic=0x59e05710]
rcvd [LCP EchoRep id=0x1 magic=0xc9b3a4 59 e0 57 10]
rcvd [IPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfNak id=0x4 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x5 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]

Other Options?

Depending on how this works out, I may end up with a new solution, something like:

Footnotes:

1

I'm unsure if I am going to switch to the Pi 2, or another ARM hardware platform, currently. The MVP is going to be built on the B+, and we'll move from there.

2

That is, if you live in the 90s.

3

I ended up reading Huawei's AT command set. It's pretty nice. hifhdhdhdhd