Using an Iridium phone with GNU/Linux and PPP
http://www.phys.unsw.edu.au/~mcba/iridiumLinux.html
Please inform
the author of any mistakes.
Iridium, Windows, GNU/Linux
The Iridium satellite system
officially supports data connections only with proprietary Windows
software. This shuts out anyone who needs a reliable computer system (our application is for a remote, un-personned,
site on the Antarctic plateau, so Windows is completely unsuitable).
Fortunately, the Iridium system does work with standard PPP software,
making it accessible to GNU/Linux, although there are no guarantees
that this situation will continue.
Varieties of Iridium phone/modem
The common varieties of Iridium phone are the Motorola 9500, 9505, and
9522. The phone contains a fairly standard modem that responds to
most of the usual AT
commands and a few extra ones (see the Bibliography
below for a complete list of relevant documents on this web site), with
some caveats, and is
accessible via an RS-232 serial link at 19200 baud (note that you will
need the data connector on the base of the phone in order to
attach a 9-pin D connector). It is also possible to buy an Iridium
modem, which, I believe, is basically the internals of the 9505.
Varieties of data connection
There are three ways of making an
outgoing data connection with the Iridium system: either dial
another Iridium phone, dial a modem connected to the POTS (Plain Old
Telephone System), or use the Iridium gateway as your ISP (so-called
"direct
Internet data"). This latter mode is presumably a better way to
connect to the Internet.
The baud rate of the data connection is nominally 2400 (apparently it can vary from
2200 to 3800 baud depending on antenna
efficiency and atmospheric conditions). The
Windows software claims 10kbps using some sort of proprietary data
compression, but this obviously only applies to data that can be
compressed. Under GNU/Linux you can use, e.g., "ssh -C" to make a ssh
connection with compression.
Instructions for establishing a direct Internet connection
The following instructions apply to a Motorola 9505 and Redhat
GNU/Linux 7.3, and are for direct Internet connection via the
Iridium gateway. Note that US DoD users have a special gateway in
Hawaii, which will give somewhat different responses (however, it does
work; you need to use port 500 for a transparent TCP/IP socket
connection).
Begin by using the standard Redhat tool to add a new network connection
via PPP. The modem should be set to 19200 baud, 8 data bits, 1 stop
bit, no parity, hardware handshaking. After you have finished, edit
your /etc/wvdial.conf and make it look like this:
[Modem0]
Modem = /dev/ttyS0
Baud = 19200
SetVolume = 2
Dial Command = ATDT
Init1 = ATZ
Init2 = ATS0=1V1X4E1Q0&c1
Init3 = AT+cbst=71,0,1
Init4 = AT+cr=1
FlowControl = CRTSCTS
[Dialer Iridium gateway]
Phone = 008816000025
Password = none
Username = none
Stupid Mode = 1
Inherits = Modem0
The interesting things about this file are (1) the baud rate of 19200
is just for serial communication between the computer and the phone,
and is matched to the capabilities of the modem, the outgoing baud
rate is still 2400, (2) the "AT+cbst=71,0,1" line is crucial, (3)
the 008816000025 (changed from 008816000023 in versions of this
document prior to 26 Jan 2006) is an undocumented Iridium gateway number that
allows you to connect without having to specify a password and
username (this speeds up the connection). An alternative is to use
008816000022, in which case you have two options: Password is
"password" and Username is your Iridium telephone number, or, Password
and Username are both "directinternet".
You can now activate the Iridium connection using "ifup ppp0". You
should see the Iridium phone dialling out, and after about 28
seconds you should be connected. If you
have PPP configured with debugging (by putting the line "debug" in
/etc/ppp/options or /etc/ppp/peers/wvdial (I'm not sure which is
best)), you should see something like the following in
/var/log/ppplog:
Nov 25 10:42:06 mcba1 pppd[24727]: pppd 2.4.1 started by root, uid 0
Nov 25 10:42:06 mcba1 ifup-ppp: pppd started for ppp0 on /dev/ttyS0 at 19200
Nov 25 10:42:06 mcba1 WvDial: WvDial: Internet dialer version 1.41
Nov 25 10:42:06 mcba1 WvDial: Initializing modem.
Nov 25 10:42:06 mcba1 WvDial: Sending: ATZ
Nov 25 10:42:06 mcba1 WvDial: ATZ
Nov 25 10:42:06 mcba1 WvDial: OK
Nov 25 10:42:06 mcba1 WvDial: Sending: ATS0=1V1X4E1Q0&c1
Nov 25 10:42:06 mcba1 WvDial: ATS0=1V1X4E1Q0&c1
Nov 25 10:42:06 mcba1 WvDial: OK
Nov 25 10:42:06 mcba1 WvDial: Sending: AT+cbst=71,0,1
Nov 25 10:42:06 mcba1 WvDial: AT+cbst=71,0,1
Nov 25 10:42:06 mcba1 WvDial: OK
Nov 25 10:42:06 mcba1 WvDial: Sending: AT+cr=1
Nov 25 10:42:06 mcba1 WvDial: AT+cr=1
Nov 25 10:42:06 mcba1 WvDial: OK
Nov 25 10:42:06 mcba1 WvDial: Modem initialized.
Nov 25 10:42:06 mcba1 WvDial: Sending: ATDT 008816000023
Nov 25 10:42:06 mcba1 WvDial: Waiting for carrier.
Nov 25 10:42:06 mcba1 WvDial: ATDT 008816000023
Nov 25 10:42:22 mcba1 WvDial: +CR: REL ASYNC
Nov 25 10:42:22 mcba1 WvDial: CONNECT 19200
Nov 25 10:42:22 mcba1 WvDial: Carrier detected. Starting PPP immediately.
Nov 25 10:42:22 mcba1 pppd[24727]: Serial connection established.
Nov 25 10:42:22 mcba1 pppd[24727]: using channel 5
Nov 25 10:42:22 mcba1 pppd[24727]: Using interface ppp0
Nov 25 10:42:22 mcba1 pppd[24727]: Connect: ppp0 <--> /dev/ttyS0
Nov 25 10:42:23 mcba1 pppd[24727]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xf209433c> <pcomp> <accomp>]
Nov 25 10:42:24 mcba1 pppd[24727]: rcvd [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x3e76> <pcomp> <accomp>]
Nov 25 10:42:24 mcba1 pppd[24727]: sent [LCP ConfAck id=0x1 <asyncmap 0xa0000> <magic 0x3e76> <pcomp> <accomp>]
Nov 25 10:42:24 mcba1 pppd[24727]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xf209433c> <pcomp> <accomp>]
Nov 25 10:42:24 mcba1 pppd[24727]: sent [IPCP ConfReq id=0x1 <addr 166.84.159.111> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Nov 25 10:42:24 mcba1 modprobe: modprobe: Can't locate module ppp-compress-21
Nov 25 10:42:26 mcba1 pppd[24727]: rcvd [IPCP ConfReq id=0x1 <addr 172.16.1.1>]
Nov 25 10:42:26 mcba1 pppd[24727]: sent [IPCP ConfAck id=0x1 <addr 172.16.1.1>]
Nov 25 10:42:26 mcba1 pppd[24727]: rcvd [CCP ConfReq id=0x1 < 11 05 00 01 03> < 12 06 00 00 00 01>]
Nov 25 10:42:26 mcba1 modprobe: modprobe: Can't locate module ppp-compress-21
Nov 25 10:42:26 mcba1 pppd[24727]: sent [CCP ConfReq id=0x1]
Nov 25 10:42:26 mcba1 pppd[24727]: sent [CCP ConfRej id=0x1 < 11 05 00 01 03> < 12 06 00 00 00 01>]
Nov 25 10:42:26 mcba1 pppd[24727]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
Nov 25 10:42:26 mcba1 pppd[24727]: sent [IPCP ConfReq id=0x2 <addr 129.94.162.191> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Nov 25 10:42:29 mcba1 pppd[24727]: sent [CCP ConfReq id=0x1]
Nov 25 10:42:29 mcba1 pppd[24727]: sent [IPCP ConfReq id=0x2 <addr 129.94.162.191> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Nov 25 10:42:30 mcba1 pppd[24727]: rcvd [CCP ConfAck id=0x1]
Nov 25 10:42:30 mcba1 pppd[24727]: rcvd [CCP ConfReq id=0x2]
Nov 25 10:42:30 mcba1 pppd[24727]: sent [CCP ConfAck id=0x2]
Nov 25 10:42:30 mcba1 pppd[24727]: rcvd [IPCP ConfNak id=0x2 <addr 172.16.8.247> <ms-dns1 204.117.214.10> <ms-dns3 199.2.252.10>]
Nov 25 10:42:30 mcba1 pppd[24727]: sent [IPCP ConfReq id=0x3 <addr 172.16.8.247> <ms-dns1 204.117.214.10> <ms-dns3 199.2.252.10>]
Nov 25 10:42:32 mcba1 pppd[24727]: rcvd [CCP ConfAck id=0x1]
Nov 25 10:42:33 mcba1 pppd[24727]: rcvd [IPCP ConfNak id=0x2 <addr 172.16.8.247> <ms-dns1 204.117.214.10> <ms-dns3 199.2.252.10>]
Nov 25 10:42:33 mcba1 pppd[24727]: rcvd [IPCP ConfAck id=0x3 <addr 172.16.8.247> <ms-dns1 204.117.214.10> <ms-dns3 199.2.252.10>]
Nov 25 10:42:33 mcba1 pppd[24727]: local IP address 172.16.8.247
Nov 25 10:42:33 mcba1 pppd[24727]: remote IP address 172.16.1.1
Nov 25 10:42:33 mcba1 pppd[24727]: primary DNS address 204.117.214.10
Nov 25 10:42:33 mcba1 pppd[24727]: secondary DNS address 199.2.252.10
Nov 25 10:42:33 mcba1 pppd[24727]: Script /etc/ppp/ip-up started (pid 24767)
Nov 25 10:42:33 mcba1 pppd[24727]: Script /etc/ppp/ip-up finished (pid 24767), status = 0x0
Nov 25 10:42:33 mcba1 pppd[24727]: Script ?? finished (pid 24754), status = 0x0
This shows that the Iridium gateway is at address 172.16.1.1, and it
has assigned the PC the IP number 172.16.8.247. Both of these numbers
are so-called RFC1597 class B numbers reserved for private networks
(i.e., they are not accessible directly via the Internet). The
Iridium gateway handles the routing of packets from the private
network to the rest of the Internet. Domain Name Servers have also
been specified by Iridium as part of the PPP initialisation process,
and you should see these appearing in your /etc/resolve.conf file.
Your routing table should now look something like this:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
166.84.159.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 172.16.1.1 0.0.0.0 UG 0 0 0 ppp0
where all packets destined outside the local subnet (which is handled
by the existing network adapter, eth0) go via Iridium.
You can test the Iridium connection by pinging the gateway:
# ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1) from 172.16.8.247 : 56(84) bytes of data.
64 bytes from 172.16.1.1: icmp_seq=1 ttl=128 time=1516 ms
64 bytes from 172.16.1.1: icmp_seq=2 ttl=128 time=1489 ms
Note, that ICMP packets are blocked by the gateway, which means that
you cannot ping sites other than the gateway, although you should be
able to see DNS resolution (i.e., the ping command will translate a
domain name into an IP address), which verifies that the connection
is working. You can also verify connection to the rest of the
Internet by, e.g., attempting to make a ssh connection to a host
outside your local subnet.
To terminate the connection, use "ifdown ppp0".
Increasing the bandwidth
It is possible to increase the bandwidth by using inverse-multiplexing
(i.e., your data is split up across n
Iridium modems).
Remote power-on of Iridium phone
The Motorola 9505 phone can not be powered-up simply by turning on the
DC power. You need to press the ON button on the keyboard. For remote
instrumentation projects this presents a problem. Fortunately,
it is possible to reliably power on the phone using a pair of contacts on its base.
It is a mystery to me why manufacturers of products do not make this
sort of information freely available.
Getting access to the contacts is somewhat difficult, since the DC
power
adaptors are sealed units. We carefully used a hacksaw to separate the
two
plastic shells, and inserted a 240 ohm resistor between pin 2 and
ground
(as is just visible in the photo on the left). [Note: the documentation
states
that pin 2 should be pulsed low, and returned high; however, it appears
to
work when held low, and this is the approach we adopted, for
simplicity].
Screws were used to return the adaptor to a usable condition, as shown
in
the second photo.
Automatic dial-back
In order to connect to your remote system at any time, you either
need
to dial it and establish a PPP connection (a so-called
Mobile-terminated data connection) or simply have it recognise the
dial-in attempt, and then dial you back. We took the second approach,
and
used a small C program to listen to the serial port, waiting for the
"RING"
response that indicates that the phone is being dialed.
One trick here is that the "RING" response is only given by the phone
if
the data number is used. If you use the voice number, no response is
given. And if you are using the DoD system, you can't dial the data
number from the POTS, you have to use the super-secret military phone
system. An alternative may be to dial the data number from another DoD
Iridium phone, but I haven't tried this.
Obtaining time from an Iridium phone
Iridium phones keep track of time using an L-Band Frame count
synchronized to GMT time. The AT command to obtain the time is
"at-msstm" (this requires firmware LAC03xx on a 9505 phone, or SAC03xx
or SAC0201 on a 9522).
Here is an example of the "at" command and result:
at-msstm<return>
-MSSTM: 9592870f
OK
The time is ASCII hexadecimal in units of 90 milliseconds since the
epoch 1996 June 1, 00:00:11 UTC, which is 833587211 seconds after the
UNIX time epoch (1970 January 1 at 00:00:00). DANGER: Version 2.7 of the
AT command reference document states that the counter may "be changed to
prevent a rollover and as a result should not be used as a time source
for user applications". AAARRRGGG! What a mess...
The counter is a 32-bit
unsigned integer, and it overflows approximately every 12.25 years
(it is zero again on 2008 August 30 at 22:11:07 and 2020 November 29 at
20:22:04). The command may return "no network service" if the phone
has yet to register with the network. Based on some documentation I
have seen on the 9601 device, I suspect that the phone only re-synchs
with network time every 8 hours or if re-registering. In between these
events, the phone uses its internal clock to increment the frame
count. Therefore, it is possible that time using the "at-msstm"
command may not monotonically increase (and not just because of the
rollover).
To-do list
The following needs attention. Any advice gratefully received.
- Mobile-terminated
data connections, i.e., how to dial in to an Iridium phone.
Unfortunately, it appears you have to do this from either another
Iridium phone, or a modem. It would be nice if it could be
done automatically from the Iridium gateway (STOP PRESS: this may be
possible in the near future, through a telnet interface).
- IP spoofing, i.e., disconnecting from the Iridium gateway during
periods of no communication, and then seamlessly reconnecting at a
later time. The Windows software can do this. Maybe it is a
matter of requesting the same local IP address when connecting with
PPP.
- Compression. It would be useful if the Iridium gateway
supported one of the non-proprietary data compression techniques. I
haven't tried them all.
- On-demand connection. This is a standard PPP thing, but I haven't
tried it yet.
- On-lack-of-demand disconnection. As above.
- Can performance of the PPP link be improved by fiddling with
options such as the mru (the Maximum Receive Unit) or mtu (the Maximum
Transmit Unit)?
Bibliography
The following relevant documents are on this web site. They have
been obtained mostly through google searches, and are placed here in
case they disappear from their original sites. It is possible that
there are more up-to-date versions available.
Acknowledgements
Several technical folks within Iridium were
extremely helpful. Telstra were also very helpful.
This page doesn't require Macromedia Flash or Adobe Acrobat. It
doesn't have fancy graphics (OK, I couldn't resist the Tux...).
Hopefully it gave you the information you wanted, quickly.
Author
Michael
Ashley / m.ashley@unsw.edu.au
/ last updated 06-Nov-2007