Using IrDA to connect your Sharp Zaurus to 

your Linux Notebook

Martin L. Purschke
Brookhaven National Laboratory


I'll describe a setup between the Zaurus and a Notebook running Linux. Read the explanations what is happening and why I chose to do it this way. You can find all scripts for both the Notebook and the Zaurus in a downloadable archive at the end of this document, so don't start typing yet as your read this.

You should still read through this document in order to understand the fine points.

Going Infrared

I got the the Zaurus SL5500 (called "the Z" by most proud owners) a few months ago, right after the full version SL5500 became available. While the Z itself is a wonderful gadget, its USB cradle is, well, another story. It's a sharp-edged, ugly-shaped, bulky contraption, and while it's borderline ok to have it sit on your desk at home, it's not something you want to carry around in your briefcase when you are on the road. I have been asking the Sharp folks if they don't want to consider making a "standalone" USB cable without the cradle (I have a Canon Powershot camera which has just such a thing to download pictures, light, easy to carry and easy to use), but I guess their answer was "no" (at least they didn't say or reply anything, nada).

So if you take your Z on the road a lot, and you need to sync your calenders and transfer files, the easiest way is to use the built-in infrared transmitter (IrDA) to get the job done. And usually your notebook is equipped with an IrDA transmitter/receiver, so all the hardware is in place.

That's why I put the "notebook" in the title - for me this feature is most useful when I'm at work or moving around. As a matter of fact, I haven't used  the USB connection much lately  and use the cradle just to charge the Z's battery.

In this document I'll describe what it takes to set it all up, make it really simple and elegant.

Here's what my Zaurus screen looks like:




Notice the "IrDA Starter" icon on the left side of the Zaurus' screen. It's supposed to show a little LED on the left, where the Z's transmitter is sitting. All I need to do is to tap on that icon, put the Z behind my notebook where the receiver is, and they start talking. Read on how it's done.




The Notebook side of the game

First Things First

We are talking notebooks running Linux here -- if you are running Windows, I don't know how to help you in this regard. You need kernel support for ppp and IrDA. Here's the relevant portion of the .config for my kernel (2.4.19):

# IrDA (infrared) support
#
CONFIG_IRDA=m
#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
# CONFIG_IRDA_ULTRA is not set
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
CONFIG_IRDA_DEBUG=y
#
# Infrared-port device drivers
#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m
# CONFIG_IRPORT_SIR is not set


 I run Redhat Linux on my Fujitsu S4542 notebook. It has its infrared port on the back, and the port shows up as /dev/ttyS3 on that machine. On yours, it may be another number. If you examine the output of the dmesg command (grep for "ttyS"), you will get some clues.

The Z and most Linux distributions have all the tools needed either built in or readily available. For RH it's an RPM called "irda-utils". If you don't have it installed, get it from your installation CD or from rpmfind.net.

You need to edit the file "/etc/sysconfig/irda" to reflect your hardware. The only thing you have to set is the ttyS number your machine uses for the IR port. Here's mine:
 
IRDA=yes
DEVICE=/dev/ttyS3
#DONGLE=actisys+
DISCOVERY=yes

Similar to a machine at an ISP, where you dial up and get a ppp connection to the internet, your notebook will run the ppp service (act as the "ISP"), and your Z will "dial up" to get  a connection. The basics of that is completely and utterly simple --

On the notebook:
  1. Start the IrDA:    /etc/rc.d/init.d/irda start
  2. start the ppp service:   /usr/sbin/pppd  /dev/ircomm0 noauth 192.168.129.200:192.168.129.201

On the Zaurus, get into the shell and type
  1. /etc/rc.d/init.d/irda start
  2. pppd /dev/ircomm

And you should be able to ping each machine from the respective other. Watch  the /var/log/messages file for some chatter such as

Oct  7 00:03:34 localhost pppd[6576]: Using interface ppp0
Oct  7 00:03:34 localhost pppd[6576]: Connect: ppp0 <--> /dev/ircomm0
Oct  7 00:03:37 localhost pppd[6576]: local  IP address 192.168.129.200
Oct  7 00:03:37 localhost pppd[6576]: remote IP address 192.168.129.201
Oct  7 00:03:37 localhost pppd[6576]: BSD-Compress (15) compression enabled

That was easy. The rest will be a bit more complicated, but in the end it's all just wrapping what we have just seen into a user-friendlier package, on both the Linux host and the Z. In addition, we want to make it so that the Zaurus can access the network through your notebook. I don't want to give all those commands to just make the notebook and the Z talk to each other. I just want to put the Zaurus behind the notebook, klick on the icon, and they connect. That's what we will accomplish next.

Warning. We will set up the connection in a way that the Zaurus doesn't need to authenticate itself. That is most likely ok, but in a high-risk/high-security environment, you may want to reconsider. Anyone with a ppp-capable infrared-equipped device (PDA, notebook) and enough knowledge can use your notebook to hop onto the network.

Special considerations for a notebook

The abov e commands can be put into a simple script or started at boot time for a desktop machine rather easily. Such a machine doesn't move around, has a fixed connection to the Internet, and so on. Your home machine that dials up a PPP connection at your ISP with potentially changing network setups may be somewhere in between such a desktop and a notebook which I will describe next.

For our notebook (at least that's true for mine), we assume that it moves around (say, between home and work) and that its network settings (especially the DNS servers) change. We also assume that the notebook doesn't get rebooted very often but only suspends and wakes up (mine goes on 41 days of uptime as I write this).

That means that the local pppd service where the Z connects must adapt to the notebook's changing network settings. We cannot fire up a static pppd server (perhaps with the "persist" keyword, or from a file that has the entries hard-coded) because of this. Also, I notice that on my notebook. the IrDA interface is dead after a wakeup, I have to (automatically) restart the IrDA service then to get it going again.

Before we go on, let's make our life easier and add a line to the /etc/hosts file reading

192.168.129.201         zaurus

I'm sure you have noticed that this IP we specified on the pppd command line is the same IP that the Z uses by default when it connects through the USB connection. So in both cases you can now refer to the Z's address as "zaurus". For example, you can now say

$ ftp zaurus 4242
Connected to zaurus (192.168.129.201).
220 Qtopia transfer service ready!
Name (zaurus:purschke): root
331 User name ok, need password
Password:
230 User logged in, proceed
Remote system type is UNIX.
Using binary mode to transfer files.

Just for our convenience.

How to start (and stop) pppd

If you don't do anything special, the pppd command acts as a daemon, that is, it forks and puts itself into the background, and you get the prompt back right away. The pppd process waits for a connect, serves the connection as long as it lasts, and exits. The full command line that we might use that also grants the Z access to the Internet is

/usr/sbin/pppd /dev/ircomm0 noauth 192.168.129.200:192.168.129.201 ktune ms-dns 192.168.1.12 passive

"ktune" means "kernel tune", it allows the pppd process to change some kernel parameters to get its settings right. The "ms-dns 192.168.1.12" tells pppd what to tell the later client where the DNS (name server) is (at 192.168.1.12 in this fictitious case). This is what we have to adapt to when the network environment changes. "passive" makes pppd wait patiently for a connection to be opened.

Ok, we said that the DNS which our notebook sees is changing all the time, and we need to communicate the current one to the pppd process. I do that with a little script called "saydns.sh" which I put in /usr/sbin:

$ cat /usr/sbin/saydns.sh
#! /bin/sh
#
/bin/grep nameserver  /etc/resolv.conf  | head -1 | awk '{print $2}'
$

It will fish out the first nameserver entry from the current resolv.conf file, and just print the IP to standard out. We can put that on the pppd line by

/usr/sbin/pppd  /dev/ircomm0 noauth 192.168.129.200:192.168.129.201  ktune ms-dns `/usr/sbin/saydns.sh` passive

(note the backquotes around the saydns.sh).

That doesn't help us yet with the adapting part, though. In order to solve that, I start the pppd through /etc/inittab. Just like the X server, or some terminal login program, the pppd server gets restarted by init each time it terminates at the end of a connection, or each time it gets killed. That's the key. If the network connection changes, I kill pppd, and the saydns.sh script will tell the new pppd process the new DNS IP.

In order to make pppd work with inittab (which expects a command to run until it terminates), we have to add the "nodetach" keyword to the command line, which prevents pppd from putting itself in the background. Otherwise it would return right away, and init would start yet another pppd process, and yet another, and so on. The command line now reads

/usr/sbin/pppd  /dev/ircomm0 noauth 192.168.129.200:192.168.129.201 ktune ms-dns `/usr/sbin/saydns.sh` passive nodetach

Not quite done yet. We will need to kill that server once in a while as we'll see later, and one way of doing that would be the command "killall pppd". Bad idea. If our machine itself connects to the Internet through PPP, we would kill that connection as well. Especially since we kill the Z's pppd as a result of the network going active (thereby adapting to the new settings), we would break the connection again right away.

The proper way is to use the "linkname <name>" keyword of pppd, which will create a file "/var/run/pppd-name.pid" (we use "zaurus" as name) which contains the Zaurus-pppd's pid, and we can kill it selectively. Here's how:

$ cat /usr/sbin/zaurus_ppp_stop.sh
#! /bin/sh
#
[ -f /var/run/ppp-zaurus.pid ] && kill `cat /var/run/ppp-zaurus.pid`
$ 

One final quirk. If we put that now really long command line in the inittab file, we get a complaint that that line is too long. So I put it into /usr/sbin/zaurus_ppp.sh (which must be executable):

$ cat /usr/sbin/zaurus_ppp.sh
#! /bin/sh
#
/usr/sbin/pppd /dev/ircomm0 noauth 192.168.129.200:192.168.129.201 proxyarp ktune ms-dns `/usr/sbin/saydns.sh` passive nodetach linkname zaurus

$

The inittab file entry  then reads:

# respawn pppd for zaurus in rl 3,4,5
S2:345:respawn:/usr/sbin/zaurus_ppp.sh

So it is started in run levels 3, 4 and 5, and gets restarted each time it terminates.

Talking to the APMD

I said before that the IrDA interface freezes up after the machine wakes up. At least that's the case on my machine. If yours doesn't, you don't need to perform the following step. When the machine wakes up, the APMD (the Power Monitor) checks for the existence of a file "/etc/sysconfig/apm-scripts/apmcontinue" and sources it (it doesn't have to be executable). That's where we restart everything we need. The script gets called with a parameter that is either "suspend", or "standby",  or "resume". We need to react only if the action is "resume":

$ cat /etc/sysconfig/apm-scripts/apmcontinue
# this script is called to wake up the ppp server for the zaurus
if [ "$1" = "resume" ] ; then
  /etc/rc.d/init.d/irda restart
  /usr/sbin/zaurus_ppp_stop.sh
fi
$

Restarting at a network change

The normal network scripts located in /etc/sysconfig/network-scripts check, when everything else is done, for the existence of an executable called "/sbin/ifup-local", and execute it. Usually there is no such file, and we can make one:

$ cat /sbin/ifup-local
#! /bin/sh
# this script is called to restart pppd when the network comes up
/usr/sbin/zaurus_ppp_stop.sh
$

This file must be executable.

This rounds up the things we need to do on the Notebook side. To recap,
  1. get the kernel configured right;
  2. edit the /etc/sysconfig/irda file to reflect your hardware;
  3. put the 4 scripts in their proper locations;
  4. add the line to start pppd to /etc/inittab;
  5. add the "zaurus" IP definition to /etc/hosts.
You can download the scripts and a README further down. Stay with me.

Now the Zaurus side

You have seen at the top of this page that I made an icon that will appear on the desktop. It will wait 8 seconds, giving you time to put the Z close to the IR receiver of your notebook, and then start the connection.

Before you try doing all the steps I'm about to describe, wait -- at the end of this document you can download a tar file which will have all the right files for the right location, so read on.

The way the icon is put there is a file  "irda.desktop" in /home/QtPalmtop/apps/Applications/, which reads (remember this is on the Zaurus)

$ cat  /home/QtPalmtop/apps/Applications/irda.desktop
[Desktop Entry]
Comment=IrDA starter
Exec=irstart
Icon=irda.png
Type=Application
Name=IrDA starter
CanFastload=0
$

Alright, so we have a desktop entry here. The icon is irda.png, the command to be run is "irstart", comment and name is "IrDA Starter", and it's an application. The place for the icons is /home/QtPalmtop/pics/, that's where we put the PNG file.

The irstart is a shell script in /usr/bin which uses yet another one (called "ir") to start the pppd:

$ cat  usr/bin/irstart    
#! /bin/sh

if  [ -n "`ifconfig | grep irda1`" ] ; then
   /usr/bin/ir stop
fi

sleep 8

/usr/bin/ir start
$

As you may have guessed, the "ir start" and "ir stop" commands start and stop the connection. Why do we want to stop the connection first? After a while of inactivity (which you can adjust in the control panel), the Z goes to sleep. When it wakes up, the "irda1" device is still there but the connection with the notebook is gone -- its PPP server has terminated (and a new one has been started) in the meantime. So if we find the existing "irda1" interface, it's highly likely that we had a connection active before the Z went to sleep, and we stop and later restart the interface in order to clear out all  stale settings that may have survived. Remember, this tapping the icon is supposed to trigger the action we most likely want - if you want something else once in a while, you can still use the ir command (or even lower-level commands) from the shell.

We then sleep 8 seconds. This is meant to allow us to use the stylus to tap on the icon while the Z is in our hand, and give us enough time to place it close to the receiver before the connection starts.

For completeness, here's the "ir" script:

$ cat  usr/bin/ir     
#/! /bin/sh
#
case "$1" in
    start)
    /etc/rc.d/init.d/irda start
    echo "Wait for IR discovery"
    sleep 2
    pppd /dev/ircomm  defaultroute usepeerdns
    echo "IRda started"
    ;;
    stop)
    killall pppd
    /etc/rc.d/init.d/irda stop
    echo "IrDA stopped"
    ;;
    *)
    echo "Usage: $0 start  stop"
    ;;
esac
$

Downloads


If you download the package and untar it in an empty directory. You'll find two directories, "notebook-side/" and "zaurus-side/". The former contains a README with instructions what to do with the files on your notebook.

The zaurus-side/ directory contains a README again with instructions what to do, and yet another tar file which contains all the zaurus files you need. Those are relative to the / directory,

$ tar tf zaurus-files.tar
tar: Record size = 11 blocks
home/QtPalmtop/apps/Applications/irda.desktop
home/QtPalmtop/pics/irda.png
usr/bin/ir
usr/bin/irstart
$

Cd to /,  then unpack. Restart Qtopia to get the icon on the desktop.

Credits...

There's a lot of information out there that helped me putting this together.

In particular the

"PPP over IrDA on Sharp Zaurus HOWTO" by Carlos Vidal (the "ir" script is taken from his document), and the

"Linux PPP HOWTO" by Corwin Light-Williams and Joshua Drake.

Contact me

I'm Martin Purschke. Find my home page here. And you can send me mail at  purschke@bnl.gov.
 

October 02, 2002