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.
Just wait. The Hayes command set isn't - it's 3GPP 27.007 (a standard for data terminal UE). And nothing in 27.007 requires a UE to transfer data frames over the PPP link; PPP exists as a convenient way to set up the point-to-point link.
ReplyDeleteSome dongle makers have cottoned onto this; you use the 27.007 command set to bring up PPP, then transfer data on a separate Ethernet-type interface. When you want to end your PSD session, you bring down the PPP, having transferred 0 bytes of real data on it; only the data on the NCM Ethernet emulation interface made it over the air.
I really do not understand how really quite simple things manage to get so completely screwed up. They must have read the documents pertaining to the standards and either ignored half of it, mis-understood it or deliberately screwed things up.
ReplyDeleteWHY?
Took your advice and never read this post lol x
ReplyDeleteHi,
ReplyDeleteI have the ZTE from O2 and it's possible to disable the autorun nonsense by sending it 'AT+ZCDRUN=8'.
Here's the relevant bits from my notes about doing it under Linux:
-----
Switching off autorun:
+ insert the device
+ use dmesg to find out when the "CD-ROM" device has been detected
+ Eject the "CD-ROM" device : 'eject /dev/sr0'
+ use dmesg to wait until the tty devices have been detected
+ /dev/ttyUSB{1,2} seem to work, {0,3} don't
+ Use 'minicom -s' on /dev/ttyUSB2 to disable autorun in future
+ AT+ZCDRUN=8
+ unplug the stick
+ replug the stick and use dmesg to wait until /dev/ttyUSB{0,1,2,3} have been d
etected again
-----
Thanks all for the suggestsions. Yes, not Hayes, but that is where it came from originally. And stuff we kind of need to work on the lowest common denominator so are pretty much stuck with the PPP and autorun stuff. We are allowing config of the init/dial sequence though.
ReplyDeleteI aim to finish most of the details this weekend after the 3D thing and issue new code maybe Sunday.
I am pondering if NAT should be the default for dongle as only A&A ones will do non NAT that I know. Trying to make it that default config is just plug and go.
How close did you come to flinging the thing out the window and saying "We're not supporting this piece of crap"?
ReplyDeleteI'm surprised the blog post didn't end with "...and decided it was such a steaming pile of ugly hackery we couldn't bear to use it".
I bought a Huawei E585 to free myself from the tomfoolery you describe.
ReplyDeleteThe autorun thing is a menace; the Huawei E220 used to only work on Linux if you could wvdial it in the interval between it coming up in lsusb (when the TTY interface would be shown) and it reporting itself as a mass storage device. KDE KNetworkManager has managed to deal with this since 4.3.
ReplyDelete