As some of you know the new FireBrick FB2700 has a USB port to allow a 3G dongle to be attached. Thanks to a lot of work by Cliff on the USB library we now have something working. The latest alpha should connect, but the code needs a lot of polish. No there is no status page or command yet, etc. If you want to try, just add
The fun bit is finding out how they work, and this is where, from a technical point of view, you probably need to start with a good head of hair...
We have only tried two so far (ZTE and Huawei).
The first thing that strikes you is that they need a mode switch to work. What this means is that they start life as a USB mass storage device and not as a modem or such. Why? Well, the best guess is windows. By appearing to be a mass storage device then windows will look for and offer to install any drivers for you. If they started off as a modem then windows would either ask for drivers or install its own drivers which then need un-installing. So it has to pretend not to be a modem at all. Great! But then the mode switch itself does not use the standard USB alternative configuration system at all, no. It uses a specific message - in this case one uses an Eject command as if it was a CD and another users a message allowing a Wakeup request from the dongle. Neither is intuitive. Thankfully we can just send both.
It then reconnects and appears as mass storage still, and, well, not a modem in fact. USB allows it to be a communications device but it claims to be a vendor specific device instead - hmmm. Thankfully it is pretty clear it has a serial type interface we can talk to at this stage...
So, we are talking to a device that apparently has to understand packets on the air, but we are talking to it as if it were an old fashioned serially connected modem. Yes, that means old Hayes modem style AT commands.
Once we get that sorted, we finally CONNECT, and get PPP in HDLC style async serial framing. Why??? The HDLC style framing was designed for slow serial modems that may confuse XON and XOFF with data, and so on, and needs escaping. It even has a 16 bit CRC which is generated by the dongle or host and sent to the other - it gets no further, and is being sent over a short reliable USB link and protocol. What is more of a surprise is that the dongle bothers to check the CRC even, and ignore you if not valid.
OK, but even with this tedious escaping and CRC, we can finally talk PPP. Woohoo... Except...
You are talking to the dongle, not the network, it seems. Most, if not all, of the PPP negotiation stage is local. And the dongle is actually extra special with its use of PPP...
1. It does not actually offer up any IP for the remote end. This is odd, most systems expect that. In fact it sends an IPCP conf Req that is totally empty!!!
2. It initially refuses to negotiate the local IP at all, and says DNS is 10.11.12.13 and 10.11.12.14. It also insists that WINS servers are 10.11.12.13 and 10.11.12.14 even if you did not ask for them, so you have to ask for DNS and WINS.
3. It keeps NAKing even though what it NAKs is what you asked for, and not ACKing, until (presumably) it managed to get through to the far end...
4. It eventually Rejects the WINS servers you asked for (why did it NAK them then, doh), and ACKs with proper DNS and IP details at last.
5. It ignores IPV6CP, which it should either pass on, or reject.
Thankfully, with the addition of WINS, my PPP stack copes with this fiasco and finally gets connected.
So, all good fun... Do let the normal support email or irc channel have any feedback if you try it.
Next trick is to try bonding 3G dongles. Watch this space.