The overall goal of the OpenOBEX project is to make an open source implementation of the Object Exchange (OBEX) protocol. OBEX is a session protocol and can best be described as a binary HTTP protocol. OBEX is builtin in devices like PDA's like the Palm Pilot, and mobile phones like the Ericsson R320, Siemens S25, Siemens S45, Siemens ME45, Nokia NM207 and Nokia 9110 Communicator. OBEX is optimised for ad-hoc wireless links and can be used to exchange all kind of objects like files, pictures, calendar entries (vCal) and business cards (vCard). A typical application is the "beam" function of PalmOS.

e-Squirt is a simple protocol for sending URLs over the IrDA medium. This allows for interaction with CoolTown enabled devices.

IrNET is a protocol allowing to carry TCP/IP traffic between two IrDA peers in an efficient fashion. It is a thin layer, passing PPP packets in a IrTTP socket. It uses PPP in synchronous mode for efficiency, and offers lots of flexibility and various features. The main part of IrNET in included in kernel 2.4.x, and a user-space daemon (to automate connections) is available on the web page.

This Java Infrared Socket API provides a way of communicating through infrared medium on a linux machine using Java. Thus, Java application developers can develop applications involving infrared access much easily. The API is very similar to java.net.Socket API and has been implemented using the Linux infrared stack. Both connection oriented streams (IrSocket and IrServerSocket) and connectionless Ultra (UltraSocket, UltraPacket) interfaces are available.

Please read the Kernel-HOWTO from TLDP to get more information about the compilation process. Thomas Hertweck has written another useful Linux-Kernel-HOWTO (but it is only available in German and Italian). Check the Linux/IrDA Project or the Linux/IrDA mailing list archives for latest patches.

You'll find the Linux/IrDA Kernel code in:

/usr/src/linux/net/irda (protocol stuff)

/usr/src/linux/drivers/net/irda (device drivers)

/usr/src/linux/include/net/irda (header files)

Make sure you use kernel 2.6 sources. I recommend not to use any earlier kernel version, but this document will describe differences to the kernel 2.4 series in the appropriate places. If unsure about your kernel version try uname -r.

For current 2.6 kernels there are no patches necessary. In case there is a kernel patch from the Linux/IrDA project or other places to apply (for example for kernel 2.4), put it into the directory /usr/src or where else your kernel sources live and apply something like (replace patch-2_4.0-irdaXXX with the actual file name):

cd /usr/src
tar xvzf patch-2_4.0-irdaXXX.tar.gz
cd linux
patch -p1 -l < ../patch-2_4.0-irdaXXX

For latest drivers experimental support has to be enabled CONFIG_EXPERIMENTAL, at least in kernel 2.4.

Enable sysctl in "General Setup" CONFIG_SYSCTL.

You should have proc file system support CONFIG_PROC_FS.

Also serial support for the SIR features CONFIG_SERIAL.

I am not sure whether there has to be printer support for using a printer with Linux/IrDA CONFIG_PRINTER. But I assume this feature is not necessary.

Networking support _must_ be enabled CONFIG_NET.

Make sure you have module support CONFIG_MODULES in your kernel! Test it e.g. with lsmod.

Also kerneld support CONFIG_KERNELD. But kmod (CONFIG_KMOD) also works. A monolithic kernel seems to work, too. But modules are highly recommended!

To use irdadump you probably have to set CONFIG_PACKET.

If you only apply the Linux/IrDA patch, you should not have to do a make clean, so that should save you some time. I suggest you do something like this:

For kernel 2.4 use: make dep && make all && make modules && make install && make modules_install. For kernel 2.6 use: make all && make install && make modules_install. If you get really strange errors, then try to rebuild from scratch after a make clean.

The following is from ../linux-2.4.3/Documentation/Configure.help (kernel 2.4) or ../linux-2.6.x/net/irda/Kconfig, ../linux-2.6.x/drivers/net/irda/Kconfig (kernel 2.6) with some modifications by me. Please consult the latest available kernel documentation for current information and new drivers.

Note: donauboe is a new version of toshoboe better FIR support and compatibility with Donauoboe chip from lib-irda. Note: the toshoboe drivers has been removed from the 2.6 kernel series.

mknod /dev/ircomm0 c 161 0
mknod /dev/ircomm1 c 161 1
mknod /dev/irlpt0 c 161 16
mknod /dev/irlpt1 c 161 17
mknod /dev/irnet c 10 187
chmod 666 /dev/ir*

There might be some other device number necessary if you want to use the irkbd features. You may find the latest device numbers in ../src/linux/Documentation/devices.txt.

First you should put your IrDA devices in range. Though it might be possible that the Linux/IrDA service detects every new device automagically I only have good experience with the devices in range during the configuration process.

Keep your infrared devices together in a range below one meter and an angle of 30 degree. There has to be a direct line of sight between them. If this is not possible, you may use a mirror (an unused M$ CD should work quite good).

Add the following lines to your /etc/modprobe.conf (for kernel 2.4 /etc/modules.conf) file (attention: the actual filename may depend on your Linux distribution):

# IrDA over a normal serial port, or a serial port compatible IrDA port (SIR)
alias tty-ldisc-11 irtty

# IrCOMM (for printing, PPP, Minicom etc)
alias char-major-161 ircomm-tty     # if you want IrCOMM support

# IRLAN
# But currently the IrLAN protocol is no longer maintained
# by the Linux/IrDA core team.
alias irlan0 irlan

# To be able to attach some serial dongles
# These values are hard-coded in irattach (not instance order)
alias irda-dongle-0  tekram             # Tekram IrMate IR-210B
alias irda-dongle-1  esi                # ESI JetEye
alias irda-dongle-2  actisys            # Actisys IR-220L
alias irda-dongle-3  actisys            # Actisys IR-220L+
alias irda-dongle-4  girbil             # Greenwich GIrBIL
alias irda-dongle-5  litelink           # Parallax LiteLink/ESI JetEye
alias irda-dongle-6  airport            # Adaptec Airport 1000 and 2000
alias irda-dongle-7  old_belkin         # Belkin (old) SmartBeam dongle
alias irda-dongle-8  ep7211_ir          # Cirrus Logic EP7211 Processor (ARM)
alias irda-dongle-9  mcp2120            # MCP2120 (Microchip) based
alias irda-dongle-10 act200l            # ACTiSYS Ir-200L
alias irda-dongle-11 ma600              # Mobile Action ma600

# To use the FIR driver. This applies only to the specific device!!!

#options nsc-ircc dongle_id=0x09	# NSC driver on a IBM Thinkpad laptop
#options nsc-ircc dongle_id=0x08	# HP Omnibook 6000
#alias irda0 nsc-ircc

# options smc-ircc ircc_irq= ircc_dma=
# alias irda0 smc-ircc

# options toshoboe max_baud=
# alias irda0 toshoboe

# options w83977af_ir io= io2= irq= qos_mtt_bits=
# alias irda0 w83977af_ir

# IrNET module...
alias char-major-10-187 irnet       # Official allocation of IrNET

Then do a depmod -a to update, and then all IrDA modules should be automagically loaded when you need them. Note for testing reasons you may load them manually, but please make sure not to load them twice. There might be some other entries necessary, if you want to use the irkbd features or an USB dongle. A template file is included in the irda-utils package.

Note: With Debian GNU/Linux however you shouldn't edit /etc/modules.conf directly, instead place the lines inside /etc/modutils/irda-utils and run update-modules afterwards. Running update-modules seems obsolete for 2.6 kernels.

Have a look into the files in /etc/irda. Edit them to reflect your setup.

Make sure your infrared port is enabled in the BIOS and check what interrupt and port address it uses. With some laptops it seems necessary to have Microsoft-Windows installed to be able to set BIOS parameters.

I have got reports, that on some laptops, when connected to a docking station, the infrared port was disabled .

Please decide first whether you want to set up Irda either in SIR or in FIR mode. It is recommended to start with SIR.

Is some cases IRQ conflicts may occur, especially conflicts with sound, PCMCIA or the hotplug system have been reported. Check cat /proc/interrupts to get some information about IRQ usage on your machine.

Most important, you must sync your disks!!! Maybe you have to reboot your machine. Have you read the disclaimer?

There are three sorts of low level drivers: SIR, FIR and dongle for machines without an in-built InfraRed port. To start with Linux/IrDA I recommend to use the SIR method.

Load the modules modprobe irda irtty. irattach /dev/ttyS1 -s to attach the IrDA device to the IrDA services. Check lsmod and dmesg.

irdadump should show all available IrDA devices in range now. Hint: If you are connecting different Linux boxes, you may use hostname YOUR_HOSTNAME to set a unique hostname for each computer.

On the "server" side do pppd /dev/ircomm0 LOCAL_IP:REMOTE_IP On the "client" side do pppd /dev/ircomm0 .

You may now test the connection with ping. And use all sorts of networking connections (ssh, NFS, ...) now.

The IrDA(TM) standard knows three kinds of speeds:

Up to 115.200bps (SIR) many (probably all) infrared controllers work like a serial port and use a RZI (return to zero, inverted) modulation. Not every infrared controller supports 4Mps (FIR), up to 4Mbps they have to use 4PPM (4 pulse position) modulation technique. A list of supported FIR chips is included in /usr/src/linux/drivers/net/irda/Kconfig. You may start the FIR service by loading the according module. Linux/IrDA will probe your hardware then. More drivers are under development.

So what speeds can you expect? Using SIR, you should be able to get about 10 Kbytes/s. Using FIR (4Mbps) you can get over 300 Kbytes/s (if you are lucky).

A survey of supported dongles is included in /usr/src/linux/drivers/net/irda/Kconfig.

Dag Brattli wrote (modified by wh): "To use dongles you have to do something like this:

modprobe tekram         # or esi or actisys
irattach -d tekram      # or -d esi or -d actisys

modprobe is not necessary, if /etc/modules.conf is correct. As you can see, you must still use the -d option with irattach since it is possible to have two serial ports using different dongles at the same time (so the tty you are binding must know which dongle it is supposed to use). So if you have two dongles and two serial ports, you could do something like this:

modprobe tekram
modprobe esi
irattach /dev/ttyS0 -d esi &
irattach /dev/ttyS1 -d tekram &

PS: I would not try to turn the two dongles against each other, since I really don't know how the stack would react :-) ... Since I don't have any of these new ACTiSYS 220L+ dongles, I'm not able to test it. Since the new dongle has support for one extra speed (38400bps), you must specify the dongles differently with irattach so that the kernel knows which dongle you are using (and what QoS can be used):

irattach /dev/ttyS0 -d actisys     # for the 220L dongle
irattach /dev/ttyS0 -d actisys+    # for the 220L+ dongle

The current implementation of dongle support does not have any state associated with it, so its not possible to use both ACTiSYS dongles (220L and 220L+) at the same time (connected to two serial ports) for now. If someone needs to be able to do so, please mail me (Dag Brattli) and I will think about it!"

Note: When I tried to use an infrared modem (Swissmod 56Ki, manufactured by Telelink AG) connected to my laptop (IrDA works with Microsoft-Window$95 only, due to non-standard hardware) I had to remove the infrared support in the BIOS to get it working!

Dag Brattli: "It is now possible to use irport instead of irtty! I have moved all the dongle stuff out of irtty and into irda_device, so it will also be possible to attach dongles to irport. Need however to make a small user-space utility dongle_attach that can be used to attach dongles to a specific driver instance. BTW: irattach is still working as before, and you will not notice the difference even when attaching dongles to irtty (I've just redirected the dongle ioctl to irda_device). Irport may be interesting since you avoid one software interrupt (bh) level, and it's also forced to work in half duplex mode so you don't get any echo if the irda port itself don't have echo-cancellation (Girbil dongle and HP-4000 etc) ... To use it, you must supply the parameters to modprobe like this: modprobe irport io=0x3f8 irq=4, or whichever values you use. You can also add these parameters to /etc/modprobe.conf (kernel 2.6) or /etc/modules.conf (kernel 2.4) like this: options irport io=0x3f8 irq=4, but then you must remember to do a depmod -a and use modprobe irport instead of modprobe."

Alvin Loh: "Anyone with a ESI 9680C can use both parallax's and ESI's signalling scheme, meaning they can use Parallax's driver with ESI9680C to work. "

Not every USB dongle does work. For details see the dedicated chapter below IrDA and USB.

Support for e.g. the ACTiSYS IR2000 dongle has been implemented.

From James I have this description about setting up the hardware: There are two configurations, a five pin in line connector and a 6 pin DIL (at the end of a 18 pin DIL header). Basically any IrDA compatible transceiver will work (I have a stack of old IRM3001 these are now obselete) you need to hook a capacitor (use a tantalum about ~1uF) between 5V and 0V near the transceiver and then connect everthing else up (RX->RX, TX->TX, 5V->5V, and 0V-0V). If you don't like soldering irons, lots of companies do sell IR modules for the 5 pin connectors that fit into a hole in your case.

This chapter describes how to connect your mobile phone via IrDA with your Linux box. It is based on a report by Matthias Schmidt. It was tested with the following mobiles:

Configure the IrDA basics as described above (kernel configuration, /etc/modules.conf, irattach, PPP) (for detailed information about PPP see also the PPP-HOWTO. Now check whether your mobile phone was found:

# irdadump
xid:rsp be1eb736 > 08666644 S=6 s=4 SIEMENS S35 hint=9024 [ Modem IrCOMM IrOBEX ] (28)
# irdadump
xid:rsp be1eb736 > 35450000 S=6 s=4 Nokia 6100 hint=8101 [ PnP Telephony ] (28)
# irdadump
xid:rsp be1eb736 > 04489982 S=6 s=5 SIEMENS ME45 hint=b124 [ PnP Modem Fax IrCOMM IrOBEX ] (29)

[Dialer Defaults]
Modem = /dev/ircomm0
Baud = 9600
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Password = internet
Username = internet
Phone = 00393492002800
ISDN = 0
Modem Type = Analog Modem

[Dialer shh]
Init3 = ATM0

# username	connection-name	password
test	irda		test

hide-password
noauth
connect "/usr/sbin/chat -v -f /etc/chatscripts/irda"
debug
/dev/ircomm0
9600
defaultroute
noipdefault
user test
remotename irda
ipparam irda
usepeerdns

ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' 
ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED
'' ATZ
# dial-in number of the ISP
OK-AT-OK ATDT<YOUR_ISP_PHONE_NUMBER>
CONNECT \d\c

 
# irattach /dev/ttyS1 -s
IrDA: Registered device irda0

# irdadump
xid:cmd 9d5dcefa < ffffffff S=6 s=3 (14)
xid:cmd 9d5dcefa < ffffffff S=6 s=4 (14)
xid:rsp 9d5dcefa > 08666644 S=6 s=3 SIEMENS S35 hint=9024 [ Modem IrCOMM IrOBEX ] (28)

# scmxx -i
Accessing device /dev/ircomm0
OK, a modem device is present.
Vendor:         SIEMENS
Model:          S35i
Revision:       20
Serial (Phone): xxxxxxxxxxxxxxx
Serial (SIM):   xxxxxxxxxxxxxxx
SIM-ID:         xxxxxxxxxxxxxxxxxxxxx
Operator:       D2
SMS Server:     +491722270333
Charset:        GSM
Battery:        40%
Signal/BER:     -79 dBm/?
Time:           02/10/07,11:48:49
Readable Slots: bmp: 0-1, mid: 0, vcs: 1-30
Phonebooks:     FD, SM, ON, ME, LD, MC, RC, OW, MS, CD, BL, RD, CS
SMS storages:   SM

# scmxx -g -PSM -f phonebook
Accessing device /dev/ircomm0
OK, a modem device is present.
Detected SIEMENS S35i
phonebook created.
Receiving: 1 2 3 4 5 6 7 8 9 [...] 
Received all gettable entries

# scmxx -g -S3 -f -
Accessing device /dev/ircomm0
OK, a modem device is present.
Detected SIEMENS S35i
Looking for SMS of specified type...
Receiving incoming, read SMS from slot 3.
Slot: 3
From: xxxxxxxxxxxxxx
Date: 2002-10-03 23:11:47 (GMT+0)
SMSC number: xxxxxxxxxxxxxxxx
PDU type: SMS-DELIVER MMS
Data Coding Scheme: 7bit-GSM
Message length: 160
Message:
	xxxxxxxxxxxxxxxxxxxxxxxxxx

# scmxx -g -B0 -f logo.bmp
Accessing device /dev/ircomm0
OK, a modem device is present.
Detected SIEMENS S35i
Slot 0...
Receiving packet 1 of 5...
logo.bmp created.
Receiving packet 2 of 5...
Receiving packet 3 of 5...
Receiving packet 4 of 5...
Receiving packet 5 of 5...
File transfer complete.

# scmxx -g -M0 -f sound.mid
Accessing device /dev/ircomm0
OK, a modem device is present.
Detected SIEMENS S35i
Slot 0...
Receiving packet 1 of 1...
sound.mid created.
File transfer complete.

See the OpenOBEX chapter below. Detailed information about OBEX connections to mobile phones will follow soon hopefully. See also the Palm III section for information about setting up a connection.

A note to German e-plus users:

Every e-plus contract (except Free&Easy) contains a PPP conncetion to the WWW (no separate registration necessary). This service is available around Germany under the phone number 123100. This worked also out of the box.

pppd configuration:

/dev/ircomm0
defaultroute
netmask 255.255.255.0
debug
mtu 552
crtscts
noauth
connect '/usr/sbin/chat -v -f /etc/ppp/eplus.chat'
chat script /etc/ppp/eplus.chat:

ABORT "BUSY"
ABORT "ERROR"
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "NO ANSWER"
SAY "initializing modem..."
"" "AT"
"OK" "ATZ"
SAY "dialing..."
"OK" "ATDT123100"
SAY "waiting for CONNECT..."
"CONNECT" ""
SAY "connected!"
SAY ""

For the nameserver you may use 192.76.144.66 . Username or password are not necessary.

Why this? Unfortunately Linux users are not always supplied with the necessary hardware information. Sometimes it is possible to look at this information in Microsoft-Windows. Sometimes its even useful to connect the two. Linux could also provide occasional access point services to a Microsoft-Windows laptop of a friend dropping by.

Where to get it from? At MicroSoft in the directory /Windows95/downloads/contents/WURecommended/S_WUCommunications/W95IrDA/ you will find a support pack Infrared Transfer 2.0. It is a self-extracting archive W95IR.EXE with 331KB. Note: Microsoft seems to change the location of this file (and others) at random, the former URL is Microsoft Windows95 IrDA - Old

Microsoft(tm) has three versions of IrDA support for Windows95. The version number can be found in the "Software" icon in the Control Panel and the file infrared.inf.

Version 1.0 is still delivered with some hardware.

Version 2.0 is the version they currently offer at their web site. It is in the self-extracting file W95IR.EXE. The last time I looked (1999-02-21) it was 434KB and was found at http://support.microsoft.com/download/support/mslfiles/W95IR.EXE the link is dead now. Their website is frequently changing, so do not be surprised to find the file (also) in another location or not at all.

Version 3.0 can/could be found in their downloadable Infrared development kit IRDDK30, but is mostly useful for developers. It is internally different from 2.0, it is based on "miniport" network drivers, just like the Linux version. It exists for some time and has some support for NT, but it clearly did not make it into the mainstream NT4.0 distributions. For 95 you are probably better off with 2.0. The choice may depend on the documentation of the drivers you get with your specific hardware.

The Microsoft website also used to contain a nice utility IrXfer, contained in the archive IRXFER.EXE, This is the Infrared Transfer utility, which uses an IrOBEX variant I think, it is referenced in the IrOBEX protocol description. The utility was freely downloadable, but I could not find it the last time. It is a nice graphical utility which can be used to transfer files over IrDA between computers.

With some machines, e.g. a HP Omnibook 800 it is necessary to use a vendor specific version of this package (for the HP Omnibook 800 you may find it on the recovery CD).

Especially the ..\windows\inf\*.inf files and the device manager are of interest to look for configuration details.

As far as I know Window$NT doesn't support IrDA(TM). About Window$98 I have heard there is no IrDA(TM) support yet. Countersys claims to sell an IrDA solution for NT4.0 to support their JetBeam product, Microsoft refers to them for it.

AFAIK:

You may use IrNET .

Ha Duong Minh: Today I am delighted to report that ircp from the OpenOBEX project , works like a charm to transfer files between my Linux box and its Microsoft-Windows98 cousin. It can't be simpler: ircp file1, file2, ... to send or ircp -r [DEST] to receive files over IrDA.

IrCOMM2k is a driver by Jan Kiszka for Windows 2000 and XP. It emulates a serial port which can be used to exchange data with mobile devices. For example, some cellular phones are able to act as modems or fax devices. PDAs with infrared interface can be synchronized with the PC. IrCOMM2k is an Open Source project according to the terms of the GPL.

There should be four ways to get two Linux machines connected via Linux/IrDA.

Please note this feature is still quite experimental! Dag Brattli wrote: "Just wanted you to know I have just added COMPRESSION support to IrLAP! As you may know, this is _not_ part of the IrDA(TM) standard, but Linux can now negotiate with its peer and check if it has the same compression capabilities). So obviously if you are talking to Win95, Palm III or whatever, you will _not_ get compression!!! This is something which is exclusive for Linux as far as I know! The IrDA(TM) standard says that devices should ignore unknown field in the negotiation header, so we are still "compatible" with IrDA(TM) (have just borrowed an unused header value).

If you want to try using the compression code (Linux <-> Linux) you will have to insert the irda_deflate module some time before you actually make the connection. I do it before irattach.

The compression standard I have added is the deflate format used by the zlib library which is described by RFCs (Request for Comments) 1950 to 1952 in the files ftp://ds.internic.net/rfc/rfc1950.txt (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format).

The compression interface is similar to PPP, so you can add as many different compressors as you want. Currently there is only support for GZIP, but BSD compression will be added later. ... Have just tested GZIP compression at 4Mbps. It was a really bad idea! Compressing the frames takes so much time that the performance is actually worse than when not using compression at all. The conclusion is that compression should only be used for SIR speeds, ..."

Up to 115.200bps, the infrared port emulates a serial port like the 16550A UART. This will be detected by the kernel serial driver at boot time, or when you load the serial module. If infrared support is enabled in the BIOS, for most laptops you will get a kernel message like:

Serial driver version 4.25 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A     #first serial port /dev/ttyS0
ttyS01 at 0x3000 (irq = 10) is a 16550A    #e.g. infrared port
ttyS02 at 0x0300 (irq = 3) is a 16550A     #e.g. PCMCIA modem port

If you want to use up to 4Mbps, your machine has to be equipped with a certain FIR chip. You need a certain Linux/IrDA driver to support this chip. Therefore you need exact information about the FIR chip. You may get this information in one of the following ways:

I have checked this chapter with this environment: ACTiSYS ACT-IR2000U FIR-USB Adapter (but it should work for any other USB dongle except the one mentioned above), Kernel 2.4.19, irda-utils 0.9.14 and Debian GNU/Linux 3.0 Woody.

You need a kernel with appropriate IrDA and USB support and the standard entries in /etc/modprobe.conf (kernel 2.6) /etc/modules.conf (kernel 2.4) and devices in /dev/ir* as described in the chapters above. And a second IrDA device whether with Linux inside or not, e.g. a laptop, a printer or a cell phone with IrDA port.

You need a working USB controller. Check whether the appropriate module is already inserted with lsmod. If not you may insert it with modprobe usb-uhci (for Intel/Via USB controllers) or modprobe usb-ohci (for other USB controllers)

Note: this driver has NOT been tested with the usb-ehci driver (for USB 2.0 controllers). This driver WON'T WORK with the uhci driver (alternate/JE driver for Intel/Via USB controllers).

If you are not familiar with routing issues, I dare to recommend to shut down all external network interfaces with ifconfig during the first set up. Then check with route -n. Also netfiltering (iptables) may cause problems, so if you are not connected to a network you may disable it.

I have described the process in every detail, to make every caveat as clear as possible. The actual configuration is much shorter and easier. During configuration I will choose to open three different terminal windows to watch the log messages from different programs.

Now plug the dongle in and check the Kernel messages with dmesg:

hub.c: USB new device connect on bus1/1, assigned device number 2
usb.c: USB device 2 (vend/prod 0x50f/0x180) is not claimed by any active driver.
usb.c: registered new driver irda-usb
IRDA-USB found at address 2, Vendor: 50f, Product: 180
irda_usb_parse_endpoints(), And our endpoints are : in=02, out=01 (64), int=03
irda_usb_init_qos(), dongle says speed=0x13E, size=0x20, window=0x2, bofs=0x4, turn=0x2
IrDA: Registered device irda1
USB IrDA support registered

If you have already some other IrDA hardware configured on the PC, the driver won't load as irda0, so to check the message log as shown above is important (the driver can manage up to 4 IrDA-USB dongles per PC, that can be increased in the source).

In this example the device is irda1. You may check this with ifconfig, too:

irda1     Link encap:IrLAP  HWaddr 2c:52:61:ec
          EtherTalk Phase 2 addr:140/191
          UP RUNNING NOARP  MTU:2048  Metric:1
          RX packets:2278 errors:0 dropped:0 overruns:0 frame:0
          TX packets:844 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0
          RX bytes:33848 (33.0 KiB)  TX bytes:15116 (14.7 KiB)

Now you are ready to attach the Linux/IrDA service to the dongle With irattach irda1 -s (note the device name from the step before).

The green LED on the adapter should blink now, approximately every three seconds. And with dmesg you may see this message:

irlap_change_speed(), setting speed to 9600
irlap_recv_discovery_xid_cmd(), discovery frame to short!

Now start irdadump, you should see all IrDA devices in range. Or at least this one, here "japh" (the other IrDA device in this example is named "Olga"). For diagnostic purposes leave irdadump running in this terminal window and switch to another window for the next steps.

07:58:40.889590 xid:cmd ffffffff < 4fe026d8 S=6 s=3 (14)
07:58:40.979575 xid:cmd ffffffff < 4fe026d8 S=6 s=4 (14)
07:58:40.979679 xid:rsp 2c5261ec > 4fe026d8 S=6 s=4 japh hint=0400 [ Computer ] (20)
07:58:41.069571 xid:cmd ffffffff < 4fe026d8 S=6 s=5 (14)
07:58:41.166552 xid:cmd ffffffff < 4fe026d8 S=6 s=* Olga hint=0400 [ Computer ] (20)
07:58:43.620104 xid:cmd ffffffff < 4fe026d8 S=6 s=0 (14)
07:58:43.709078 xid:cmd ffffffff < 4fe026d8 S=6 s=1 (14)

Now load the IrCOMM modules (note this is usually done automagically by the kernel daemon kmod if you start PPP or printing via IrDA, but for the first time we do things by hand). So do modprobe ircomm and modprobe ircomm-tty .

The dmesg will show now:

IrCOMM protocol (Dag Brattli)
ircomm_open_lsap()
ircomm_tty_attach_cable()
ircomm_tty_ias_register()
ircomm_tty_close()
ircomm_tty_shutdown()
ircomm_tty_detach_cable()
ircomm_close()

And with lsmod you may see:

Module                  Size  Used by    Tainted: P  
ircomm-tty             30080   0  (autoclean)
ircomm                 13164   0  (autoclean) [ircomm-tty]
irda-usb               13776   1 
...
irtty                   7264   0  (autoclean)
irda                  141648   1  (autoclean) [ircomm-tty ircomm irda-usb irtty]

You may start pppd with commandline options, but for me it's more convenient to have a configuration file /etc/ppp/peers/irda.

connect /bin/true
noauth
persist
debug
kdebug 7
nodetach
115200
local
/dev/ircomm0
192.168.0.2:192.168.0.3

Some note about the configuration: Yes the device name is correct, don't choose an USB device here. If the other IrDA device is a Linux laptop you may use the same configuration file and the same PPP options, without the last line, which sets the LOCAL and REMOTE IP address. The following entries are for debugging purposes and can be commented out when everything works fine:

persist
debug
kdebug 7
nodetach

Now start PPP with pppd call irda. For diagnostic purposes leave the messages running in this terminal window and switch to another window for the next steps.

Serial connection established.
using channel 3
Using interface ppp0
Connect: ppp0 <--> /dev/ircomm0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x4592a46e> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x4592a46e> <pcomp> <accomp>]
...

Now start PPP on the remote IrDA device and you should see:

sent [LCP EchoReq id=0x0 magic=0x3c8803b1]
sent [IPCP ConfReq id=0x1 <addr 192.168.0.2> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x3c8803b1> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x3c8803b1> <pcomp> <accomp>]
rcvd [LCP EchoReq id=0x0 magic=0xa922f0e8]
sent [LCP EchoRep id=0x0 magic=0x3c8803b1]
rcvd [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
sent [IPCP ConfNak id=0x1 <addr 192.168.0.3>]
rcvd [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
rcvd [LCP EchoRep id=0x0 magic=0xa922f0e8]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.0.2> <compress VJ 0f 01>]
rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Deflate (15) compression enabled
rcvd [IPCP ConfReq id=0x2 <addr 192.168.0.3> <compress VJ 0f 01>]
sent [IPCP ConfAck id=0x2 <addr 192.168.0.3> <compress VJ 0f 01>]
Cannot determine ethernet address for proxy ARP
local  IP address 192.168.0.2
remote IP address 192.168.0.3
Script /etc/ppp/ip-up started (pid 3975)
Script /etc/ppp/ip-up finished (pid 3975), status = 0x1

And in the window running irdadump you see the IrDA traffic:

08:17:11.179260 i:rsp  > ca=08 pf=1 nr=1 ns=2 LM slsap=00 dlsap=19 CONN_RSP (6)
08:17:11.199127 i:cmd  < ca=08 pf=1 nr=3 ns=1 LM slsap=00 dlsap=1d CONN_RSP (6)
08:17:11.199226 i:rsp  > ca=08 pf=1 nr=2 ns=3 LM slsap=1d dlsap=00 GET_VALUE_BY_CLASS: "IrLPT" "IrDA:IrLMP:LsapSel" (30)
08:17:11.219123 i:cmd  < ca=08 pf=1 nr=4 ns=2 LM slsap=00 dlsap=1c CONN_RSP (6)
08:17:11.219207 i:rsp  > ca=08 pf=1 nr=3 ns=4 LM slsap=1c dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "Parameters" (28)
08:17:11.241117 i:cmd  < ca=08 pf=1 nr=5 ns=3 LM slsap=19 dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "Parameters" (28)
08:17:11.241213 i:rsp  > ca=08 pf=1 nr=4 ns=5 LM slsap=00 dlsap=19 GET_VALUE_BY_CLASS: Success N/A (19)
08:17:11.259114 i:cmd  < ca=08 pf=1 nr=6 ns=4 LM slsap=00 dlsap=1d GET_VALUE_BY_CLASS: No such class (11)
08:17:11.259216 i:rsp  > ca=08 pf=1 nr=5 ns=6 LM slsap=1d dlsap=00 DISC (6)
08:17:11.280107 i:cmd  < ca=08 pf=1 nr=7 ns=5 LM slsap=00 dlsap=1c GET_VALUE_BY_CLASS: Success N/A (19)
08:17:11.280281 i:rsp  > ca=08 pf=0 nr=6 ns=7 LM slsap=1c dlsap=00 DISC (6)
08:17:11.282124 i:rsp  > ca=08 pf=1 nr=6 ns=0 LM slsap=1e dlsap=00 CONN_CMD (6)
08:17:11.299104 i:cmd  < ca=08 pf=1 nr=1 ns=6 LM slsap=19 dlsap=00 DISC (6)
08:17:11.299204 rr:rsp > ca=08 pf=1 nr=7 (2)
08:17:11.319102 i:cmd  < ca=08 pf=1 nr=1 ns=7 LM slsap=1a dlsap=00 CONN_CMD (6)
08:17:11.319209 i:rsp  > ca=08 pf=1 nr=0 ns=1 LM slsap=00 dlsap=1a CONN_RSP (6)
08:17:11.339100 i:cmd  < ca=08 pf=1 nr=2 ns=0 LM slsap=00 dlsap=1e CONN_RSP (6)
08:17:11.339197 i:rsp  > ca=08 pf=1 nr=1 ns=2 LM slsap=1e dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "IrDA:TinyTP:LsapSel" (37)
08:17:11.361096 i:cmd  < ca=08 pf=1 nr=3 ns=1 LM slsap=1a dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "IrDA:TinyTP:LsapSel" (37)
08:17:11.361191 i:rsp  > ca=08 pf=1 nr=2 ns=3 LM slsap=00 dlsap=1a GET_VALUE_BY_CLASS: Success Integer: 14 (15)
08:17:11.380092 i:cmd  < ca=08 pf=1 nr=4 ns=2 LM slsap=00 dlsap=1e GET_VALUE_BY_CLASS: Success Integer: 14 (15)
08:17:11.380214 i:rsp  > ca=08 pf=0 nr=3 ns=4 LM slsap=1e dlsap=00 DISC (6)
08:17:11.382104 i:rsp  > ca=08 pf=1 nr=3 ns=5 LM slsap=14 dlsap=14 CONN_CMD TTP credits=0(7)
08:17:11.399090 i:cmd  < ca=08 pf=1 nr=6 ns=3 LM slsap=1a dlsap=00 DISC (6)
08:17:11.399190 rr:rsp > ca=08 pf=1 nr=4 (2)
08:17:11.419082 i:cmd  < ca=08 pf=1 nr=6 ns=4 LM slsap=14 dlsap=14 CONN_CMD TTP credits=0(7)
08:17:11.419159 rr:rsp > ca=08 pf=1 nr=5 (2)
08:17:11.438080 rr:cmd < ca=08 pf=1 nr=6 (2)

Switch to another terminal and check the PPP device with ifconfig :

ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.0.2  P-t-P:192.168.0.3  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0
          RX bytes:318 (318.0 b)  TX bytes:708 (708.0 b)

With ps aux | grep irda you should now see these Processes:

root      3534  0.0  0.2  1272  464 ?        S    06:51   0:00 irattach irda1 -s
root      3579  0.3  0.2  1400  476 tty1     S    06:55   0:06 irdadump
root      4312  0.1  0.4  2088  948 tty2     S    07:18   0:00 pppd call irda

With route -n you may now see this PPP devices:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.3     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
0.0.0.0         192.168.0.3     0.0.0.0         UG    0      0        0 ppp0

And it should be possible to do a ping 192.168.0.3 to the remote host:

PING 192.168.0.3 (192.168.0.3): 56 data bytes
64 bytes from 192.168.0.3: icmp_seq=0 ttl=64 time=290.7 ms
64 bytes from 192.168.0.3: icmp_seq=1 ttl=64 time=146.6 ms

Now you may use TCP/IP applications. For example ssh (note it will take some time to establish the connection be patient):

ssh -v USER@192.168.0.3

Instead of using TCP/IP connections the dongle works for printer connections, too. The device name is /dev/irlpt0. For details about IrDA printer connections see the appropriate chapter above.

You may now finetune your settings, e.g. to solve routing issues. It may also possible to set up higher speeds, but I haven't tried that yet. If everything works fine, you may now choose to make the configuration permanent. You may edit /etc/irda.conf and configure the system V init scripts (for IrDA, network, ..). But the way to do it right depends on your Linux distribution.

I encountered a strange problem. When inserting the IrDA-USB dongle, I got a slight and constant noise from the beeper.

With PPP you may get a network connection through your cell phone or with another computer. See the PPP-HOWTO for details. For fowarding packages via NAT through another Linux box see the IPTABLES-Tutorial .

You may start pppd with commandline options, but for me it's more convenient to have a configuration file /etc/ppp/peers/irda. Here is an example for a first test:

connect /bin/true
noauth
persist
debug
kdebug 7
nodetach
115200
local
/dev/ircomm
192.168.0.2:192.168.0.3

If the other IrDA device is a Linux laptop you may use the same configuration file name and the same PPP options without the last line, which sets the LOCAL and REMOTE IP address. Also take care of the correct device name, e.g. /dev/ircomm0. The following entries are for debugging purposes and can be commented out when everything works fine:

persist
debug
kdebug 7
nodetach

Now start PPP with pppd call irda on both machines. For diagnostic purposes leave the messages running in this terminal window and switch to another window for the next steps. You may now check the network connectivity with ifconfig and ping. For connections to a cell phone see the Cellular Phone Connection chapter above.

The advantage of OBEX is usually the integration. Send an appointement event over OBEX, and most likely the Zaurus will integrate that in the built-in calendar automagically, like the Palm does. Same for business cards. The IrOBEX protocol offers an easy way to beam files via infrared to another PDA, a cell phone or computer. The Linux tools are provided by OpenOBEX . Beaming via the GUI between two Zaurus PDAs or to a Palm PDA might work. But currently I couldn't send or receive files from my Linux laptop. When trying to send a file per ircp FILE, I get this irdadump message:

11:11:03.943005 i:cmd  > ca=8a pf=1 nr=0 ns=0 LM slsap=12 dlsap=00 CONN_CMD (6)
11:11:03.972964 i:rsp  < ca=8a pf=1 nr=1 ns=0 LM slsap=00 dlsap=12 CONN_RSP (6)
11:11:03.973010 i:cmd  > ca=8a pf=1 nr=1 ns=1 LM slsap=12 dlsap=00 GET_VALUE_BY_CLASS: "OBEX:IrXfer" "IrDA:TinyTP:LsapSel" (37)
11:11:04.002973 i:rsp  < ca=8a pf=1 nr=2 ns=1 LM slsap=00 dlsap=12 GET_VALUE_BY_CLASS: No such class (11)
11:11:04.003015 i:cmd  > ca=8a pf=1 nr=2 ns=2 LM slsap=12 dlsap=00 DISC (6)

When trying to receive a file per ircp -r, I get this irdadump message:

11:15:08.682979 i:cmd  < ca=8a pf=1 nr=4 ns=5 LM slsap=53 dlsap=00 CONN_CMD (6)
11:15:08.683063 i:rsp  > ca=8a pf=1 nr=6 ns=4 LM slsap=00 dlsap=53 CONN_RSP (6)
11:15:08.712970 i:cmd  < ca=8a pf=1 nr=5 ns=6 LM slsap=53 dlsap=00 GET_VALUE_BY_CLASS: "OBEX" "IrDA:TinyTP:LsapSel" (30)
11:15:08.713035 i:rsp  > ca=8a pf=1 nr=7 ns=5 LM slsap=00 dlsap=53 GET_VALUE_BY_CLASS: No such class (11)
11:15:08.732976 i:cmd  < ca=8a pf=1 nr=6 ns=7 LM slsap=53 dlsap=00 DISC (6)

Jean Tourrilhes suggests this solution: "The Zaurus doesn't support the "OBEX:IrXfer" service, it probably only supports the "OBEX" service use cat /proc/net/irda/irias to verify. So, either you start a server on "OBEX:IrXfer" on the Zaurus, (ircp_server - cross compiled for Zaurus), or you use a client using "OBEX" on the laptop (irobex_palm3)."

To print directly to an IrDA capable printer you need the device file /dev/irlpt0. If it's not available, use mknod /dev/irlpt0 c 161 16 to create it. Now you may perform a first and simple test. Try to write a small file to /dev/irlpt0 by cat FILE >/dev/irlpt0. With the stock Kernel from SHARP this didn't work, but with a custom kernel it worked fine. Do not wonder about a bad format (the lines form sort of steps) this is just a first check. To get a pretty print format you may have to write a filter as described in the Printing-HOWTO from LinuxPrinting.org . More about printing from mobile Linux devices you may find in the Linux-Mobile-Guide .

Consumer InfraRed - CIR aka remote control via infrared can be had on a Linux PDA by installing lirc-modules-KERNEL for the appropriate Kernel version, and LIRC. For more details see the HandHelds.org-WiKi and the Opie-Remote page. Opie-Remote is a remote control emulator for the Compaq iPAQ and the SHARP Zaurus.

At the SHARP Zaurus Developer Site you may find the Zaurus-IrDA-HOWTO , which explains how to utilize the IrDA port on the Zaurus. The iPAQ Help - iPAQ and Zaurus development using QPE by Werner Schulte desribes how to develope Qtopia applications in general.

For the iPAQ there is module h3600_microkbd, which supports the MicroInnovations IR keyboard. There seem to be optical barcode readers available, which use sort of a red light to read the data. But I doubt that this has anything to do with IrDA or Consumer InfraRed - CIR.

IRK allows you to use external infrared keyboards with the Zaurus. It interfaces the LIRC driver to the Qtopia environment. Currently only the Chicony KB-9820 keyboard (German version) is supported.

If you encounter problems. Try the following:

If you find a bug, please send a bug report to the mailing list, including dmesg output, and which Linux version, and hardware you are using. Thank you!

Sometimes IrCOMM fails to connect, especially when both devices discover each other. You can disable discovering with echo 0 >/proc/sys/net/irda/discovery.

A CR (carriage return) character cannot be transfered between two linux boxes via IrCOMM with cat file >/dev/ircomm0 and cat /dev/ircomm0. It causes a strange thing and freezes your Linux box.

IrOBEX may eat some data on receive. The bug is most probably in the user-space side of IrOBEX.

Although I'm not much of a hacker I collected some tricks to track errors or bugs in the Linux/IrDA software.

For some ThinkPad models you have to reboot to the preinstalled M$ OS and activate the IrDA port using the Thinkpad tools. There is currently no Linux tool to achieve that. This will disable your internal serial port (ttyS0)!. The DOS tool is PS2.EXE, as far as I know tpctl doesn't achieve this. It is really important to use this DOS program to enable IrDA. Using the Microsoft-Windows tools does not work. Without that the driver loads correctly and everythings seems OK, but the LED does not light bright enough.

Daniel R. Risacher magnus_at_alum.mit.edu wrote: To syncronize my Palm III with my Tecra 8100 running 2.2.17, I needed to edit /usr/src/linux/include/net/irda/toshoboe.h I changed "#define PCI_DEVICE_ID_FIR701 0x0701" to "#define PCI_DEVICE_ID_FIR701 0x0D01"

scanport can be used to get the correct device ID for a chip. It's part of the hwtools package (on Debian, probably same elsewhere). You just type it in and it scans the I/O ports from 0x100 to 0x400 - the usual ISA range. Above 0x400 there are shadows of below 0x400 devices, and beyond that there are PCI devices, so the default is not to scan above 0x400. "Anyway, I had to manually scan using inb to find my chip's I/O. Fortunately I didn't have to go far to find it. (Newer sound cards often sit at 0x530ish, with 0x220 reserved for legacy compatibility modes) Normally, if you know where some device is located you just point the driver at it and the driver probes to see if it's the device the driver is expecting. Not entirely safe, but much safer than every driver probing every I/O port looking for something it thinks it can understand. scanport only does reads, which are usually safe."

According to the IrDA specification the range is up to 1 meter. From the "IrDA Data Link Design Guide" p. 20 by Hewlett-Packard : " In some cases it may be desired to increase link distance beyond the 1 meter guaranteed by IrDA. The two ways to do this are to increase transmitted light intensity, or to increase receiver sensitivity. In order to extend the link distance, both sensitivity and intensity must be increased for both ends of the IR link. If it is desired to communicate with a standard IrDA device that may have minimum transmitter intensity, the receiver intensity must be increased. The standard IrDA device may also have minimum receiver sensitivity, so transmitter intensity must also be increased."

Andreas Butz wrote: "This might be a silly question, but has anyone an idea whether the whole IrDA stack really relies on a two-way connection, or whether there are some parts of it that could be abused for a one-way connection, ideally for unreliable data? We're trying to modify some IR dongles to broadcast information to palm pilots over several meters distance (cover a whole room), and since we don't want to modify the pilots themselves, and increasing the sensitivity on the receiver side seems unlikely to work, we're stuck with a one way link.". Please see the mailing list archive for details of the discussion.

Sent by Marc Bury " .. just heard about some Philips new scheme for remote controls: they call it IRDA - Control. This is supposed to be bi-directional, 75 kbps data rate, multiple simultaneous devices (up to 8) and with a minimum 6 meter range!" More information at IrDA.org .

The German magazine ELEKTOR issued a guide to build a Long Distance IrDA Dongle (20m, RS232, IrDA 1.0), ELEKTOR 5/97 p.

“The main problem is that you generally have to make the receiver more sensitive. Basic physics has the inverse square law: the intensity drops with the SQUARE of the distance, so going from 1 to 5 meters requires 25x the power (and battery drain on a portable device), or 25x the sensitivity (and dynamic range - it still has to be able to work at 3 inches). And if you want to do it on the other end, it doesn't simply have to be 25x more sensitive, it must pick up the tiny IrDA pulse needle in a haystack of florescent lights, screen savers, moving shadows ...”

Also laser diodes (pulsable) were recommended by K-H. Eischer: But they are more expensive. And the laser diodes are also dangerous if they have more than 1 mW. A better solution would be to use lenses to focus the beam. There is a minimum of absorbtion in the air (I don't know the right frequency) and you should use IR diodes with this frequency.

James wrote: " Who ever it was wanting to do long distance with IrDA, we've tried this before. The best approaches are:

Whatever you choose IrDA might very well be a good choice for a protocol, given it's one of the few that sensibly copes with simplex."

Here are some links to do-it-yourself InfraRed (IrDA) devices to use with your laptop, notebook, PDA or mobile phone.

"More and more people now think that IrDA and Bluetooth will live happily side by side, and the idea of Bluetooth as the IrDA killer just don't work anymore. IrDA is still unbeatable in price/performance and with the new additions to the standards family like AIR and VFIR, it's really good to see that IrDA is moving in the right direction."

You can take a little peek at Drag-n-drop stuff , so you will be able to drop files to your PDA (uses IrOBEX) or drop files to your printer (uses IrLPT) etc.

James wrote: " ... there is a much better way of doing the bridging which is routing. This is entirely user land and requires no kernel patches. But the IrLAN protocol is no longer maintained by the Linux/IrDA core team.

It's in two parts (you may only need one your milage may vary...) the first called irdaipcfg does the following:

1) First part is executed as irdaipcfg ifeth ifirlan daemonizes, then looks for ARP packets on ifirlan, checks that the arp was not generated by the machine on which it is running. The arp contains the ip address of the machine on the other end of the irlan (it was generated by the gratuatous arp in the irlan code). The program then sets up a host route to this ip address via ifirlan, adds a proxy arp to ifeth for it and generates a gratuatous arp on ifeth. It writes the ip address of the client in /var/run/host.ifirlan so you can easily undo all of this from a script.

2) Second part is executed as gratarp ifirlan. Sometimes the gratuatous arp seems to get lost in the pipe work, gratarp daemonizes and spits out a whole stream of the things...

I use them as follows: (you can use them to do whatever you like)

On my host (the machine bolted to my local net) irlanx is brought up as 10.192.0.1 with a netmask of 255.255.255.255 and a broadcast of 10.192.0.1 by my ifup script from /etc/irda/network by irattach. /etc/irda/network then runs irdaipcfg eth0 irlanx and this does the routing.

From /etc/irda/network

"start")
    echo 1 >/proc/sys/net/ipv4/conf/all/forwarding
    ./ifup ifcfg-${device}
    /sbin/irdaipcfg ${localnet} ${device}
    ;;
"stop")
    host=`cat /var/run/host.${device}`
    if [ .$host != . ]; then
      /sbin/arp -d ${host} dev ${localnet}
      /sbin/route delete ${host} dev ${device}
    fi
    ./ifdown ifcfg-${device}
    /sbin/ifconfig ${device} down
    ;;

on the client I set up IrLAN to use an address on my normal subnet 10.32.32.51 but with netmask 255.255.255.255 (not my usual netmask) I have some static routes which are host 10.192.0.1 dev irlan, and net default gw 10.192.0.1 dev irlan. I run gratarp from the /etc/irda/network, and I can wander arround my house and not lose telnet and ssh sessions ..."

As far as I know IPv6 has neighbor discovery mechanism, but I don't have information about Linux/IrDA used with IPv6. Please see the mailing list archive for a discussion of this topic under the subject :"patch-2.2.7-ac1-irda4".

I have got reports that it is possible to use dhcpcd with IrLAN. Please use latest DHCP software. But currently the IrLAN protocol is no longer maintained by the Linux/IrDA core team.

From Lichen Wang I have taken these remarks:

IrLAP, IrLMP, and TinyTP are pretty stable now. But various individual implementations may still have quirks.

IrCOMM is widely used, but Microsoft vowed to drop it and use IrSocket only.

IrObex, IrMC, IrTran-P, etc. are showing up in various devices. The supports on PC are segmented and sometimes very poor.

New IrDA Protocol Development AIR is pushed mainly by IBM. You get wider angle and longer distance (10M?) but may be at lower data rate. You can also time-multiplex this already slow channel. In my opinion the benefit to the user is very little. AIR hardware and software changes are costly. I think you will have to wait for a long time, if ever, to see any product using AIR.

IrBUS is pushed mainly by Sharp. It is aimed at remote control, IR keyboard, etc., not for data communication. I think if Sharp succeed, you may see IrBUS in set-top boxes, web-tv, etc. If and when these devices reaches a critical mass, some PC may incorporate IrBUS in order to control these devices.

VFIR is the latest. The benefit is higher data rate (16 Mbps). Unlike AIR and IrBUS, the software changes for VFIR are minimum. The changes are mainly in hardware.

In summary, I do not think we need to wait in anticipation of new IrDA protocols. A easy to install and solid implementation of the existing IrDA protocols is the cutting edge!.