Linux-IrDA quick tutorial


IrNET e-Squirt Java-IrDA Linux & Wireless LANs Papers Main page
Status & Patches Links Configuration Checking Applications Debugging Pitfalls

Linux-IrDA

 The Linux IrDA project is an Open Source projects to develop an generic IrDA stack for Linux that has many contributors all over the world. I did contribute many bug fixes and enhancement to it since 1999 thanks to Hewlett Packard sponsoring my work. The list of patches is too long to put here ;-)

Let's face it, one of the main roadblock to the use of e-Squirt is getting the IrDA stack up and running, whatever the platform is. We had our share of horror stories on all the OSes involved.

When it come to Linux, I've been hacking the stack often enough to have a few words of advices. Here are a few instructions on how to get it working enough to be able to use e-Squirt or IrNET...

The instructions presented here should work for Linux Kernel 2.4.X and Kernel 2.6.X. And they may work equally well for later kernels and kernel 2.2.15, and maybe others. Some other documentations on the web, like the Linux-IrDA Howto are more generic and complete but not totally up to date, so beware...

Linux-IrDA current status

Willing or not, it seem that I'm the one responsible of making sure the Linux-IrDA stack work properly. Here is a quick status report...

New version of irda-utils :

Linux-IrDA patches included in 2.4.20-pre2 :

Linux-IrDA patches included in 2.4.21-pre3 :

Linux-IrDA patches included in 2.4.22-pre2 :

Linux-IrDA patches included in 2.4.25-pre6 :

Experimental Linux-IrDA patches for 2.4.22 and later :

Other Linux-IrDA patches included in 2.5.13 :

Other Linux-IrDA patches included in 2.5.16 :

Other Linux-IrDA patches included in 2.5.24 :

Other Linux-IrDA patches included in 2.5.39 :

Other Linux-IrDA patches included in 2.5.42 :

Other Linux-IrDA patches included in 2.5.47 :

Linux-IrDA patches included in 2.5.61 :

Linux-IrDA patches included in 2.5.67 :

Linux-IrDA patches included in 2.5.70 :

Linux-IrDA patches included in 2.6.0-test1 :

Linux-IrDA patches included in 2.6.0-test3 :

Linux-IrDA patches included in 2.6.0-test5 :

Linux-IrDA patches included in 2.6.0-test10 :

Linux-IrDA patches included in 2.6.2-rc1 :

Linux-IrDA patches included in 2.6.2-rc2 :

Linux-IrDA patches included in 2.6.3 :

Linux-IrDA patches included in 2.6.4 :

Linux-IrDA patches included in 2.6.6 :

Linux-IrDA patches included in 2.6.10-rc1 :

Linux-IrDA patches included in 2.6.10 :

Linux-IrDA patches included in 2.6.12-rc1 :

Linux-IrDA patches pending for 2.6.12 :

Experimental Linux-IrDA patches for 2.6.X :

More information and links

 Our work on IrDA :

More IrDA links :

Random Linux-IrDA links that should be on the Linux-IrDA web page : More stuff on my web site :

Tutorial : How to use Linux-IrDA

 The remaining of this document will give you some tips on how to configure Linux-IrDA.

A lot of IrDA novices mix up the low level and high level of the IrDA stack. A few words...

The low level and high level are totally independant of each other, however each need to be configured properly for what you want to do.

The procedure to get IrDA working looks usually like this :

I also offer various debugging tips at the end of this document.

Common configuration

 Most Linux kernels don't come with IrDA enabled, and most distributions come with very approximate config scripts. I don't trust those and I always do things by myself. Now, it's time to check which hardware you want to make run...

Kernel 2.6.X differences

 Kernel 2.6.X drivers are slightly different from kernel 2.4.X described above. The main driver differences are listed below. This list is known to not be final.

Module configuration is also different, you need to add the following in /etc/modules.conf : 

alias tty-ldisc-11 irtty-sir
alias char-major-161 ircomm-tty
alias irda-dongle-0 tekram-sir
alias irda-dongle-1 esi-sir
alias irda-dongle-2 actisys-sir
alias irda-dongle-3 actisys-sir
alias char-major-10-187 irnet

Low level drivers

 This really depend on the IrDA hardware that you have. I describe a few of the options below. The two safest options are Laptop in SIR mode and Serial dongle.

Serial dongle (using irtty driver)

 For all serial dongles, you need an IrDA driver, which is irtty, and a dongle driver. The dongle I use if the Actisys 220L+, and the dongle driver is called actisys (see list above). The setup for other dongles should be very similar. I'm also using the first serial port in this example (ttyS0), you may need to adapt to your case.

Note : all the modern ESI dongles work better with the litelink driver.

Laptop port in SIR mode (using irtty driver)

 SIR (Serial Infrared) is not fast but almost always work and is easy to set-up, so it's a safe bet. It will work only if the BIOS is set to SIR mode, so don't bother otherwise. Some BIOS don't offer the setting and try to be clever and autodetect the proper setting, but it doesn't always works.

Note that some laptops (Toshiba) need special magic for their IrDA port to be enabled, see link section above.

The irtty driver will use the standard Linux serial driver.

Now, you just need to figure out on which side of the laptop if the IrDA port...

HP Omnibook 6000 in FIR mode

It seems that each laptop has its quirk when it come to FIR mode. I've managed to get my OB6000 to work (great laptop BTW). Other laptops will be different (different driver, different settings). The NSC driver gives me some pretty good performance.

Other laptops in FIR mode

There is different FIR hardwares included in the various laptops. Linux-IrDA support some of them (not all) in various degrees (from good to bad). Moreover, it seems that each laptop has its quirk, so it's difficult to list everything here.

For this reason, I recommend to make it work first in SIR mode. After that, you can experiment, check the Howto and query the mailing list...

THe setup for most FIR drivers will follow the same pattern as the Omnibook 6000 example above. You will need to find the proper value of the modules parameters, set the BIOS properly, take care of conflicting hardware (serial, Pcmcia cards and other interrupt conflicts) and start the stack with irattach.

As a rule of thumb, the NSC driver seems to be the most functional (if you set the proper dongle_id, which most likely 0x9, but sometimes 0x8), and the old SMC driver the most problematic.

USB FIR dongles

 This driver is included in recent kernel. It's not as efficient as other FIR hardware, but at least is supported and is relatively easy to get working. Also, all the current products are based on the same hardware, and we know most of its bugs.

The latest version of the driver has been tested with usb-uhci and usb-ohci.

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

Recently a new type of USB dongle from SigmaTel has appeared on the market which is not compliant with the IrDA-USB specification, and therefore doesn't work with this driver. On the other hand, SigmaTel has made available the full technical specification, so writing a driver for it is possible. There is a alpha driver for 2.6.X in my patch list.

The MA 620 USB dongle is a SIR USB dongle, there is some howto for it written by Martin Diehl.

Important note : in recent kernels, the USB team has added a driver called ir-usb. Not only this driver is not compatible with the IrDA stack (the IrDA driver is called irda-usb), but this driver will load automatically before irda-usb, therefore preventing you to use it. Solution : get rid of ir-usb. It may also be possible to blacklist ir-usb in /etc/hotplug/blacklist. I would like to thank warmly the USB team for the confusion they created. For complains, please direct it to them.

SIR with irport

The standard SIR driver is irtty, which uses the standard serial driver and tty layer. This is the easiest and safest way to get IrDA working.

However, the tty layer adds some overhead and doesn't understand the IrDA protocol, which make it unsuitable in some case (dongle without echo cancelation) and less performant in others (small packets). That is why there is a second driver, irport, which allow the IrDA stack direct access to the serial port.

Unfortunately, the procedure to use irport is more complicated and less well tested. Actually, I personally never managed to make irport work reliably on any of my systems.

Checking that it work

 The first test is to check if the discovery is happening properly. If the IrDA driver is properly configured, the Linux-IrDA will discover other IrDA devices in range. If the discover doesn't work, this indicate that the low level is not configured properly (and you don't need to go any further).

You can check if there is any device listed in the discovery log with : 

> cat /proc/net/irda/discovery 
IrLMP: Discovery log:

nickname: Jean Tourrilhes, hint: 0x8220, saddr: 0x913b1bbc, daddr: 0x5619b45e
You can also check various other files in /proc, or use irdadump, check the debugging section.


Then, you might want to use a simple aplication, such as e-Squirt to verify that everything works fine. Or you can skip directly to the next section.

The big advantage of e-Squirt is that it is a really simple protocol, doesn't stress the IrDA stack too much and we have implementation for various platforms, so that you can test your setup with almost anything on the other side (Linux, Win32, WinCE or Palm).

Compile the Linux e-Squirt library and the test programs on all Linux computers, and go in the tests directory. On other platforms, load and start the relevant the e-Squirt application.

If you want to use Linux as a receiver, just do : 

./squirt
To use Linux as a sender, you can do : 
./ultra_beacon http://cooltown.hp.com/
./socket_squirt http://cooltown.hp.com/
With that, you should be able to exchange back and forth URLs and check that your IrDA stack works. If not, continue to read below.

On caveat : Most implementations have two exclusive receiving modes, IrDA and Ultra, and they switch between these (either as a preference setting, or automatically triggerd by discovery packets). Linux is an exception and can listen to both at the same time. This means that unless you do a Linux-Linux test, only one of the two sender tests listed above will work properly.

Apps and protocols on top of the IrDA stack

 If you want to run e-Squirt applications, you are done, and you just need to run the application themselves, they should work.

Other applications and protocols you may want to run :

Note that I don't use IrCOMM and IrLAN, so I can't help much with that...

Terminal over IrComm

 This is a simple test to check that IrComm is working between two PCs. After that, you can try more complex applications such as PPP. The original instructions were sent on the mailing list.

Server side :
Start the terminal server 

> getty ircomm0 DT19200 vt100		# Red-Hat syntax
or 
> getty -L ircomm0 19200 vt100		# Debian syntax
At this point, your text terminal should get reset and you come back to a login prompt. That's normal. I don't know what happen in X.

Client side with kermit :
Start the terminal emulator 

> kermit
> > set line /dev/ircomm0
> > set speed 19200
> > connect
> > > stty sane				# Get backspace to work ok
The prompt shouls appear after connect. Also, you need to ignore the following message : "Warning: no access to tty (Inappropriate ioctl for device). Thus, no job control enabled", and "Can't open terminal /dev/tty"

Client side with minicom :
Minicom is a bit more problematic, and I'm still fighting with it. I still don't understand how to connect. I managed to make it work like this :

TCP/IP over IrCOMM between two PCs

 This simple example of PPP over IrCOMM is somewhat similar to TCP/IP over IrNET, and is not much use, except to verify the IrCOMM works properly. Real life PPP over IrCOMM to a mobile phone will involve a much more complex configuration (to configure the modem and dial).

Server side :
Start the ppp deamon 

> pppd /dev/ircomm0 9600 local noauth passive
As you can see, the visible difference with IrNET is that we use /dev/ircomm0 instead of /dev/irnet. Also, IrCOMM doesn't have the advanced features of IrNET to specify IrDA peer.

Client side :
Start the ppp deamon Start the terminal emulator 

> pppd /dev/ircomm0 9600 local noauth
At this point, the IrDA stack should connect (check with irdadump) and PPP should create a new network device (usually ppp0) and configure IP and route. You should be able to ping and connect to the other side using its IP address.

TCP/IP over IrLAN

 I don't use IrLAN any longer, because I'm only using IrNET. I just did a refresh on the original instructions that I sent on the mailing list (removing mentions of irmanager which no longer exist).

IrLAN as an access option, which can be 1 (direct mode), 2 (peer to peer) and 3 (hosted). Basically, you would use 2 if you connect to another PC, 1 if you connect to a transparent access point, and 3 if you are the access point (Dag, correct me if I'm wrong). The HP Netbeamer is an access point, but it accept connections only if the PC is in peer mode. Go figure...

PC -> HP NetBeamer :
Here is how to hook to the NetBeamer... After aligning the IrDA port or after starting irattach, the light of the NetBeamer should flash. If it doesn't, you may want to play with the slot_timeout value. 

> insmod irlan access=2
> ifconfig irlan0 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255
At this point, the light goes solid green. Link is on, you can ping and everybody is happy. You may want to add a gateway with "route add default gw ...".

PC -> PC :
Not everybody has a NetBeamer, so here is a step by step on how to create a link between two PCs.

On the first PC : 

> insmod irlan access=2
> ifconfig irlan0 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255
On the second PC : 
> insmod irlan access=2
> ifconfig irlan0 10.0.0.2 netmask 255.255.255.0 broadcast 10.0.0.255
After that, you should be able to ping and telnet...

Automated ifconfig :
By default, /etc/irda/network.opts is not used. In the previous example, we ifconfig-ure irlan by hand. If you have a Red-Hat/Mandrake distribution, irmanager can do the job automatically at the condition that you create a file /etc/sysconfig/network-scripts/ifcfg-irlan0 and set the right values in there... There might be more needed, but I'm not totally expert on this...

For other distribution (like Debian), you need to replace the file /etc/irda/network with possibly something from a Pcmcia package, and with some editing you might get it to load network.opts...

You might also want to add in your /etc/conf.modules a "option irlan access=2". So, if you use modprobe instead of insmod, you won't have to specify access=2 on the command line.

IrDA and mobile phones or PDAs

 I don't have any mobile phone, and I don't use IrCOMM, so I can't help...

There is many people using IrDA to connect either to their mobile phone or PDA, and lot's of them have put instructions in their web pages. You may use OBEX to transfer simple objects, or PPP over IrCOMM to establish connections, depending on the application and the device. The people doing Gnokii are also quite knowledgeable in this area, so you may ask advice on their mailing list, but please report IrDA bugs in the IrDA mailing lists.

One of the most common gotcha is that applications need to be configured to use the proper IrCOMM virtual port (which most often is /dev/ircomm0).

If I can't reproduce your problem, I can't debug it, so I can't fix it. If I can't see anything obvious in the irdadump log, I won't bother. You may also want to try to reproduce the problem between two Linux boxes (because I may be able to reproduce that).

Checking Linux-IrDA state and debugging

 Of course, I'm sure that you won't get things smooth the first time. Actually, I'm pretty sure you will struggle a little bit.

If you get the Obex stuff out of the loop (so, using Ultra or Socket, as described above), the e-Squirt stuff is so simple that if anything doesn't work you can bet that it's the IrDA stack.

The first trick is to check is the modules are loaded : 

> cat /proc/modules 
actisys                 1652   1 (autoclean)
irtty                   7524   2 (autoclean)
irda                  151905  11 (autoclean) [actisys irtty]
This is what a serial dongle setup would look like. If the modules don't show up, check you modules configuration and check the error messages in the log (with dmesg).

Then, check the bunch of files in /proc/net/irda : 

> cat /proc/net/irda/discovery 
IrLMP: Discovery log:

nickname: Jean Tourrilhes, hint: 0x8220, saddr: 0x913b1bbc, daddr: 0x5619b45e

> cat /proc/net/irda/irlap
irlap0 state: LAP_NDM
  device name: irda0, hardware name: ttyS0
  caddr: 0x52, saddr: 0x913b1bbc, daddr: 0x5619b45e
  win size: 1, win: 1, line capacity: 4800, bytes left: 4800
  tx queue len: 0 win queue len: 0 rbusy: FALSE mbusy: FALSE
  retrans: 0 vs: 2 vr: 2 va: 0
  qos   bps     maxtt   dsize   winsize addbofs mintt   ldisc   comp
  tx    9600    0       64      1       12      0       0
  rx    9600    0       64      1       12      0       0
> cat /proc/net/irda/irias 
LM-IAS Objects:
name: hp:esquirt, id=76371435
 - Attribute name: "IrDA:TinyTP:LsapSel", value[IAS_INTEGER]: 96

name: OBEX:ESquirt, id=76371435
 - Attribute name: "IrDA:TinyTP:LsapSel", value[IAS_INTEGER]: 95

name: Device, id=0
 - Attribute name: "IrLMPSupport", value[IAS_OCT_SEQ]: octet sequence

 - Attribute name: "DeviceName", value[IAS_STRING]: "lagaffe"

name: hp:beacon, id=76371435
 - Attribute name: "IrDA:TinyTP:LsapSel", value[IAS_INTEGER]: 97
There, you can see that the IrDA stack has discovered my Palm V, that my IrDA port is ttyS0, that I'm not connected, and you can also see that I have an e-Squirt application running that has opened a bunch of server sockets (of course, if you haven't started e-Squirt, the IAS won't contains all those sockets).


The ultimate debugging tool is irdadump (and remember that I require you to use version 0.9.15 or later). You should run irdadump while attempting to connect and check what's happening. A normal irdadump log with a IrDA device in front of the port (not connected) should show something like this : 

> irdadump
22:04:48.000713 xid:cmd 6f1e8511 > ffffffff S=6 s=0 (14)
22:04:48.090705 xid:cmd 6f1e8511 > ffffffff S=6 s=1 (14)
22:04:48.180714 xid:cmd 6f1e8511 > ffffffff S=6 s=2 (14)
22:04:48.270734 xid:cmd 6f1e8511 > ffffffff S=6 s=3 (14)
22:04:48.270698 xid:rsp 6f1e8511 < fb48d412 S=6 s=2 Jean Tourrilhes hint=8220 [ PDA/Palmtop IrOBEX ] (32)
22:04:48.360742 xid:cmd 6f1e8511 > ffffffff S=6 s=4 (14)
22:04:48.450733 xid:cmd 6f1e8511 > ffffffff S=6 s=5 (14)
22:04:48.540762 xid:cmd 6f1e8511 > ffffffff S=6 s=* weblab10 hint=0400 [ Computer ] (24)
You see my Palm V answering the discoveries of Linux. The Palm shows the infamous "Waiting for sender" pop-up.

On the other hand, if the stack is not properly configured (wrong port, wrong driver), or if the device in front is not active, you will get something like this : 

22:02:47.988983 xid:cmd 6f1e8511 > ffffffff S=6 s=0 (14)
22:02:48.078981 xid:cmd 6f1e8511 > ffffffff S=6 s=1 (14)
22:02:48.168992 xid:cmd 6f1e8511 > ffffffff S=6 s=2 (14)
22:02:48.258995 xid:cmd 6f1e8511 > ffffffff S=6 s=3 (14)
22:02:48.349018 xid:cmd 6f1e8511 > ffffffff S=6 s=4 (14)
22:02:48.439035 xid:cmd 6f1e8511 > ffffffff S=6 s=5 (14)
22:02:48.529063 xid:cmd 6f1e8511 > ffffffff S=6 s=* weblab10 hint=0400 [ Computer ] (24)
As you can see, nobody answer us...

After that, send a good bug report to the Linux-IrDA mailing list.

The connection just "hang"

 The first type of hang is a very classical problem, where the connection hanging just after beeing negociated (after the packets called SNRM and UA). The irdadump looks like the following : 

18:03:28.766071 xid:cmd ffffffff < af28ca67 S=6 s=0 (14) 
18:03:28.856067 xid:cmd ffffffff < af28ca67 S=6 s=1 (14) 
18:03:28.947685 xid:cmd ffffffff < af28ca67 S=6 s=2 (14) 
18:03:29.037383 xid:cmd ffffffff < af28ca67 S=6 s=3 (14) 
18:03:29.037549 xid:rsp 977f612c > af28ca67 S=6 s=3 lagaffe hint=4400 [ Computer LAN Access ] (23) 
18:03:29.126099 xid:cmd ffffffff < af28ca67 S=6 s=4 (14) 
18:03:29.216071 xid:cmd ffffffff < af28ca67 S=6 s=5 (14) 
18:03:29.316257 xid:cmd ffffffff < af28ca67 S=6 s=* tanguy hint=4400 [ Computer LAN Access ] (22) 
18:03:29.316433 snrm:cmd ca=fe pf=1 977f612c > af28ca67 new-ca=ba (32) 
18:03:29.417508 ua:rsp ca=ba pf=1 977f612c < af28ca67 (31) 
18:03:29.417646 rr:cmd > ca=ba pf=1 nr=0 (2) 
18:03:29.666173 rr:cmd > ca=ba pf=1 nr=0 (2)
If you are on the primary, you will see a series of rr:cmd until it times-out. On the secondary, you won't see anything after the ua:rsp and it will eventually timeout.

What most likely happening is that the negociated connection parameters don't match. Usually, one end doesn't implement properly the speed that is beeing negociated, so the two nodes can't hear each other after changing speed. And most likely it happens at FIR speeds.

Of course, it would be nice to fix the driver, but in the short term the solution is to force the IrDA stack to negociate a lower speed : 

> echo 115200 > /proc/sys/net/irda/max_baud_rate
You can of course try lower values, and there is also other parameters you can tweak in this directory.


There is second type of hang, that may look similar but is not. You may see the IrDA stack "hanging" on transmitting a large packet (the last number between parenthesis). This seems due to a bug in the some FIR hardware. 


18:03:30.458569 i:rsp  < ca=ba pf=1 nr=6 ns=5 LM slsap=12 dlsap=10 CONN_CMD TTP credits=0(12) 
18:03:30.458740 i:cmd  > ca=ba pf=1 nr=6 ns=6 LM slsap=10 dlsap=12 CONN_RSP TTP credits=0(12) 
18:03:30.466399 rr:rsp < ca=ba pf=1 nr=7 (2) 
18:03:30.516548 rr:cmd > ca=ba pf=1 nr=6 (2) 
18:03:30.537423 i:rsp  < ca=ba pf=1 nr=7 ns=6 LM slsap=12 dlsap=10 TTP credits=0 (29) 
18:03:30.537663 rr:cmd > ca=ba pf=1 nr=7 (2) 
18:03:30.547328 rr:rsp < ca=ba pf=1 nr=7 (2) 
18:03:30.555025 i:cmd  > ca=ba pf=1 nr=7 ns=7 LM slsap=10 dlsap=12 TTP credits=1 (2050) 
18:03:30.566804 i:cmd  > ca=ba pf=1 nr=7 ns=7 LM slsap=10 dlsap=12 TTP credits=1 (2050) 
18:03:30.596405 i:cmd  > ca=ba pf=1 nr=7 ns=7 LM slsap=10 dlsap=12 TTP credits=1 (2050)
It may look a bit different for you, but you get the idea, the packet doesn't goes through and is retried, and the communication just dies there.

As we can't fix the hardware, the solution is to force the IrDA stack to transmit smaller packets : 

> echo 2000 > /proc/sys/net/irda/max_tx_data_size


Now, I've seen is a third type of hang which happen during the connection, and not related to a large packet. This happens with buggy phones, such as Ericsson phones (T39/T68/...). 


14:53:57.741656 snrm:cmd ca=fe pf=1 2cc4b1b4 > 29c42130 new-ca=ae
        LAP QoS: Baud Rate=4000000bps Max Turn Time=500ms Data Size=2048B
Window Size=7 Add BOFS=0 Min Turn Time=1000us Link Disc=12s (33)
14:53:57.877021 ua:rsp ca=ae pf=1 2cc4b1b4 < 29c42130   
        LAP QoS: Baud Rate=1152000bps Max Turn Time=500ms Data Size=256B Window
Size=3 Add BOFS=0 Min Turn Time=0us Link Disc=12s (31)
14:53:57.877622 rr:cmd > ca=ae pf=1 nr=0 (2)
14:53:57.889399 rr:rsp < ca=ae pf=1 nr=0 (2)
14:53:57.889468 i:cmd  > ca=ae pf=1 nr=0 ns=0 LM slsap=11 dlsap=00 CONN_CMD (6)
14:53:57.895119 i:rsp  < ca=ae pf=1 nr=1 ns=0 LM slsap=00 dlsap=11 CONN_RSP (6)
14:53:57.895264 i:cmd  > ca=ae pf=1 nr=1 ns=1 LM slsap=11 dlsap=00
GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "Parameters" (28)
14:53:57.899848 i:rsp  < ca=ae pf=1 nr=2 ns=1 LM slsap=00 dlsap=11
GET_VALUE_BY_CLASS: Success
        IrCOMM Parameters Service Type=NINE_WIRE THREE_WIRE Port Type=PARALLEL (19)
14:53:57.900690 i:cmd  > ca=ae pf=0 nr=2 ns=2 LM slsap=11 dlsap=00 DISC (6)
14:53:57.900803 i:cmd  > ca=ae pf=1 nr=2 ns=3 LM slsap=12 dlsap=00 CONN_CMD (6)
14:53:57.914408 rr:rsp < ca=ae pf=1 nr=4 (2)
14:53:57.914453 rr:cmd > ca=ae pf=1 nr=2 (2)
14:53:57.924388 rr:rsp < ca=ae pf=1 nr=4 (2)
14:53:57.965741 rr:cmd > ca=ae pf=1 nr=2 (2)
The first interesting part of the log above is the Min Turn Time=0us. The peer says that it can turn the link around in 0us, but I've never seen any device that fast.

The problem here is that the Linux-IrDA stack gives the peer exactly what he ask for, and the Linux-IrDA stack can be very fast in turning around. And of course the peer can't keep up and doesn't receive properly the frames, and after that it usually goes downhill.

In those cases, you may want mandate that Linux uses a large turnaround time : 

> echo 1000 > /proc/sys/net/irda/min_tx_turn_time

The second interesting part of the log above is that it fails just after the Linux-IrDA sends two consecutive packets. IrLAP is a windowed protocol (up to 7 consecutive frames), but some devices have trouble managing that (such as the Ericsson phones and USB dongles).

In those cases, you may want limit Linux to send one frame per IrLAP window : 

> echo 1 > /proc/sys/net/irda/max_tx_window

Note that the patch adding max_tx_window to the IrDA stack is included only in kernel 2.4.22, for earlier kernel to fetch a patch up here.

irattach print "tcsetattr" in the log

 People using FIR drivers (nsc-ircc, smc-ircc...) are often confronted to this simple problem. When they start irattach, it doesn't work and the following message (or similar) is printed in the log : 
irattach: tcsetattr: Invalid argument

This is due to a conflict between the Linux-IrDA FIR driver and the regular Linux serial driver. Both want to manage the same hardware, the serial driver has registered the FIR port as a pseudo serial port and is owning it, and the kernel rightly prevent the FIR driver to get ownership of it (it's first come first serve).

The solution is simple. You need to tell the serial driver that it should not manage this port.

The safest way is to remove the serial driver : 

> rmmod serial

Unfortunately, the trick above doesn't always work (non-modular driver, another serial port in use). Another way is to declare the port invalid : 

> setserial /dev/ttyS1 uart none

On the other hand, if you do that, you won't be able to use irtty (SIR mode driver), because irtty uses the regular Linux serial driver. If you change your mind and want to use the irtty driver, you can reenable the serial port with : 

> insmod serial
> setserial /dev/ttyS1 uart 16550A

Common pitfalls

 There is many way to get the IrDA stack to not run properly. Not following instructions seems to be one of the most guaranteed way to reach that goal.

Here are mistakes I've seen user make :

Compilation problems

Sometimes, when you compile the IrDA stack or some various IrDA package, you may have the compiler complaining the things such as IRLMP_HINT_MASK_SET or IRDAPROTO_ULTRA are not defined.

This is because of a mess related to kernel headers and the way most distributions deal with it. If you have the 2.4.X kernel source lying around, the fix is simple. Just copy the header irda.h from the kernel to your include directory : 

cp /usr/src/linux/include/linux/irda.h /usr/include/linux

That should fix it ;-)

e-Squirt, IrNET and Wireless LANs - jt@hpl.hp.com
Created 1 august 00
Updated 1 February 02
    Project hosted and sponsored by :