lkml.org 
[lkml]   [2004]   [Apr]   [20]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
DateTue, 20 Apr 2004 11:05:02 +0200
FromDaniele Venzano <>
SubjectRe: 2.4.26 IRDA BUG - blocker
On Mon, Apr 19, 2004 at 10:57:18AM -0700, Jean Tourrilhes wrote:
> 	Same story, please read my web page on how to report bugs. And
> I bet the problem is the same.

You won the bet.
The echo 115200 > /proc/sys/net/irda/max_baud_rate made the trick.
What about putting some of that useful documentation under Documention/ ?
I took your web page, removed everything that looked unecessary or that
required frequent updates, and made the attached patch.

Before writing I made a grep -r irda linux-2.6.4/Documentation/, but
found nothing interesting. Since I was offline at the time, I could
not check google or irda.sf.net.

Perhaps this patch can reduce the amount of useless and unproper bug
reports against IrDA.

Bye.

-- 
-----------------------------
Daniele Venzano
Web: http://teg.homeunix.org
diff -Naur linux-2.6.5/Documentation/networking/irda.txt linux-irda-2.6.5/Documentation/networking/irda.txt
--- linux-2.6.5/Documentation/networking/irda.txt	2003-12-19 10:34:29.000000000 +0100
+++ linux-irda-2.6.5/Documentation/networking/irda.txt	2004-04-20 10:52:22.000000000 +0200
@@ -1,6 +1,9 @@
-To use the IrDA protocols within Linux you will need to get a suitable copy
-of the IrDA Utilities. More detailed information about these and associated
-programs can be found on http://irda.sourceforge.net/
+Linux-IrDA documentation by Jean Tourrilhes
+A page with much more informations, patches, links and current status can
+be found at: http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/IrDA.html
+
+The home page of the Linux-IrDA Project, with latest versions of user space
+utilities is here: http://irda.sourceforge.net/
 
 For more information about how to use the IrDA protocol stack, see the
 Linux Infared HOWTO (http://www.tuxmobil.org/Infrared-HOWTO/Infrared-HOWTO.html)
@@ -9,6 +12,858 @@
 There is an active mailing list for discussing Linux-IrDA matters called
     irda-users@lists.sourceforge.net
 
+                               ------------------
+
+   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...
+
+                               ------------------
+
+Tutorial : How to use Linux-IrDA
+
+   A lot of IrDA novices mix up the low level and high level of the IrDA
+   stack. A few words...
+
+     * Low level of Linux-IrDA : this is the part of the IrDA stack dealing
+       with the IrDA hardware on your computer and managing it. The key words
+       are IrDA driver, IrDA ports (either SIR or FIR), IrDA dongles and
+       TTY/serial port.
+     * High level of Linux-IrDA : this is the part of the IrDA stack dealing
+       with communicating with the other IrDA device and exchanging the data
+       (the protocol). The key words are protocol, IrCOMM, IrLPT, OBEX, IrLAN
+       and IrNET.
+
+   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 :
+
+     * Configure everything
+     * Set up the low level to recognise your IrDA hardware
+     * Verify that the low level works
+     * Set up your application on top of the proper high level protocol
+
+   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.
+
+     * Get kernel of your choice, unpack the source in /usr/src
+     * Compile yourself a fresh kernel and make it boot properly.
+     * Configure the IrDA stack as a module, enable all options (as module if
+       possible) and the driver/protocols you need (as modules).
+     * Configure serial port as a module. Static is ok as well, except for
+       the NSC or FIR setup.
+     * Recompile the modules and install them :
+
+ > make modules ; make modules_install
+
+     * Install irda-utils-0.9.15 or later
+     * Add the following stuff in /etc/modules.conf :
+
+ # IrDA stuff...
+ alias tty-ldisc-11 irtty
+ alias char-major-161 ircomm-tty         # if you want IrCOMM support
+ # 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
+ # IrNET module...
+ alias char-major-10-187 irnet           # Official allocation of IrNET
+
+     * Create the IrDA devices :
+
+ > 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*
+
+     * Reboot
+
+   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.
+
+     * Driver irtty-sir replaces irtty for SIR mode
+     * Dongles drivers for irtty-sir have the -sir prefix added to their name
+       (to distinguish them from old style dongle drivers).
+     * Driver donauboe replaces toshoboe
+     * Driver smsc-ircc2 may replace smc-ircc
+
+   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.
+
+     * Attach dongle to the serial port, and check which serial port it is.
+     * Check if the serial config is ok :
+
+ > setserial /dev/ttyS0
+ /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
+
+     * If it say UART: unknown, your serial configuration is invalid.
+     * Start the IrDA stack :
+
+ > irattach /dev/ttyS0 -d actisys -s
+
+     * If you want to unload/stop the IrDA stack just kill all the IrDA
+       applications and do :
+
+ > killall irattach
+ > rmmod irtty actisys
+ > rmmod irda
+
+   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.
+
+   The irtty driver will use the standard Linux serial driver.
+
+     * Go in the BIOS of the laptop, enable the Infrared port, and set it to
+       SIR mode.
+     * While in the BIOS, note the IO address and IRQ assigned to it.
+     * Using setserial or in the boot log messages, find the ttyS* that
+       correspond to this port. Let's assume /dev/ttyS1 (as in my laptop).
+     * Check if the serial config is ok :
+
+ > setserial /dev/ttyS1
+ /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
+
+     * If it say UART: unknown, your serial configuration is invalid. If the
+       port and IRQ are different, it's usually OK.
+     * Start the IrDA stack :
+
+ > irattach /dev/ttyS1 -s
+
+     * Refer to previous example for more
+
+   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).
+
+     * Go in the BIOS of the laptop, enable the Infrared port, and set it to
+       FIR mode.
+     * Add the following stuff in /etc/modules.conf :
+
+ # NSC FIR chipset in the OB6000
+ alias irda0 nsc-ircc
+ options nsc-ircc dongle_id=0x08
+
+     * Remove the serial driver that gets in the way :
+
+ > setserial /dev/ttyS1 uart none
+ > rmmod serial
+
+     * Start the IrDA stack :
+
+ > irattach irda0 -s
+
+   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.
+
+     * Start the USB stack. If you have an UHCI hardware, it looks like :
+
+ > modprobe usb-uhci
+
+     * Load USB driver and start the IrDA stack :
+
+ > modprobe irda-usb
+ > irattach irda0 -s
+
+   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 an 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 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.
+
+     * Remove the serial driver that gets in the way :
+
+ > setserial /dev/ttyS0 uart none
+ > rmmod serial
+
+     * Load the irport driver and attach the dongle driver.
+
+ > modprobe irport io=0x3f8 irq=4
+ > dongle_attach irda0 -d actisys+
+
+     * Start the IrDA stack :
+
+ > irattach irda0 -s
+
+                               ------------------
+
+Checking that it works
+
+   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 :
+
+     * TCP/IP over IrNET
+     * Terminal over IrCOMM
+     * TCP/IP over IrCOMM
+     * TCP/IP over IrLAN
+     * Connect to a mobile phones
+     * Obex to exchange files/objects with PDAs, Phones and other Obex devices
+
+   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 :
+
+     * start minicom
+     * Configure (^A O)
+     * sub-menu serial
+     * set to /dev/ircomm0
+     * set speed to 19200
+     * exit
+     * sub-menu "save as dft"
+     * exit
+     * Exit (^A X)
+     * restart minicom
+
+                               ------------------
+
+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.
+
+                               ------------------
+
+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 :
+
+     * IrDA ports not properly aligned
+     * irmanager running (it's obsolete, get rid of it)
+     * Let the init scripts of the distribution do the job
+     * irdaping running (prevent the LAP connection)
+     * Obsolete irda-utils
+     * using the wrong driver (FIR/irtty/irport)
+     * using the wrong port (/dev/ttyS0 vs /dev/ttyS1)
+     * Wrong permissions on the serial port (irattach must run as root)
+     * Some other application (such as pppd) grabbing the serial port
+     * Some other driver (most likely a Pcmcia card) using the IRQ that the
+       IrDA driver needs (for Pcmcia drivers, play with "exclude" directives
+       in /etc/pcmcia/config.opts)
+     * Wrong irattach command (irattach /dev/ttySX for SIR vs irattach irdaX
+       for FIR)
+     * Multiple instances of irattach for the same port (staying in
+       background)
+     * Wrong modules names (should be ircomm-tty, not ircomm_tty)
+     * IrDA modules not loaded
+     * Mixing up /dev/ttySX and /dev/ircommX. The stack runs on top of
+       /dev/ttySX and provides serial emulation through /dev/ircommX, so
+       serial apps should run on top of /dev/ircommX.
+     * Compiling the IrDA stack static (i.e. non module - it may work, but
+       this is not what the developpers work with)
+     * Compiling the IrDA stack without the IRDA_DEBUG option. This option
+       enable extra checks that prevent your kernel to crash.
+     * Mixing modules belonging to different versions of the IrDA stack
+     * Unclean IrDA source (failed patch)
+     * Mixing modules belonging to different kernel versions
+     * Trying to load an IrDA module on a stack wich has this code compiled
+       static (or loading module twice)
+     * Wrong version of modules tools (for kernel 2.4)
+     * Failed to do depmod -a (usually automatic at reboot)
+     * Using a version of the kernel which is not used and recommended by
+       developpers.
+
+                               ------------------
+
+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 ;-)
 
\
 
 \ /
  Last update: 2005-03-22 14:02    [from the cache]
©2003-2008