LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/linuxdoc/IR-HOWTO.sgml

3150 lines
172 KiB
Plaintext
Raw Blame History

<!doctype linuxdoc system>
<article>
<title>Linux IR HOWTO
<author>Werner Heuser,
<htmlurl url="mailto:wehe@snafu.de" name="&lt; wehe@snafu.de &gt;">
</author>
<date>v2.8, 20 September 1999
<abstract>
An introduction to Linux and infrared devices and how to use the software provided by the Linux/IrDA project. This package uses IrDA(TM) compliant standards. IrDA(TM) is an industrial standard for infrared wireless communication, and most laptops made after January 1996 are equipped with an IrDA(TM) compliant infrared transceiver. Infrared ports let you communicate with printers, modems, fax machines, LANs, and other laptops. Speed ranges from 2400bps to 4Mbps. The Linux/IrDA stack supports IrLAP, IrLMP, IrIAS, IrIAP, IrLPT, IrCOMM, IrOBEX, and IrLAN. Several of the protocols are implemented as both clients and servers. There is also support for multiple IrLAP connections, via several IrDA(TM) devices at once. The Linux/IrDA project started at the end of 1997 and its status is still experimental, so please don't expect every feature working straight. AFAIK Linux/IrDA is the _only_ open source IrDA implementation currently available. Remote Control (RC) via infrared is not the aim of the project, though partly treated in this HOWTO.
</abstract>
<toc>
<p>
<sect>Introduction
<p>
<it> Better red, than dead. - Unknown AuthorEss</it>
<p>
IrDA support for Linux started at the end of 1997. For 2.0.x kernels Linux/IrDA support worked in a totally other way and is no longer supported by the Linux/IrDA project. Since 2.1.131 and 2.2.0 <idx>Linux/IrDA</idx> is part of the kernel. Please note that the status of the project just changed from experimental to stable with 2.2.10 kernels.
<p>
Companies and developers which are interested in joining these efforts should contact the at <url url="http://www.cs.uit.no/linux-irda/" name="Linux/IrDA Project"> or me at <htmlurl url = "mailto:wehe@snafu.de" name = "&lt; wehe@snafu.de &gt;">.
<p>
Some history about Linux/IrDA. The project started at the end of 1997 with the name Linux/IrDA. Due to some troubles with the name IrDA, which is trademarked by the <url url="http://www.irda.org/" name="Infrared Data Association <idx>IrDA</idx>">, the name was changed to Linux/IR. At the end of 1998 the the relationship between both became better and the name was changed to Linux/IrDA again. Since February 1999 the project is an official member of <url url="http://www.irda.org/members/members.asp" name="IrDA"> .
<p>
This document is based on the <url url="http://www.cs.uit.no/linux-irda/howto.html" name="&dquot;How to use&dquot; part of the Linux/IrDA project homepage">. I also included material provided by the Linux/IrDA core team, the Linux/IrDA mailing list and other sources.
<p>
The document is included in the <url url="http://metalab.unc.edu/LDP" name="LINUX DOCUMENTATION PROJECT">.
<p>
The latest version of this document is available at <url url="http://www.snafu.de/&tilde;wehe/index_li.html" name="LiLAC - Linux with Laptop Computers"> .
Mathieu Arnold &lt;arn_mat@club-internet.fr&gt; provides the <url url="http://www.mat.cc/" name="IR-HOWTO in French"> .
The latest kernel I used is 2.2.3 and the latest irda-utils version is 0.8.8 .
I tried to check all information but I don't have all the necessary infrared hardware yet, so if something doesn't work for you, please don't blame me.
Please feel free to contact me for comments or questions about the HOWTO. I know this material is not finished or perfect, but I hope you find it useful anyway. For other questions and current information about Linux/IrDA please ask in the Linux/IrDA mailing list as explained below.
<htmlurl url = "mailto:wehe@snafu.de" name = "&lt;Werner Heuser&gt;">
<sect>Prerequisites
<p>
<enum>
<item>BIOS
<p>
- 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 Window$x installed to be able to set BIOS parameters.
<p>
<item>Docking Station
<p>
I have got reports, that connected to a docking station the infrared port was disabled.
<p>
<item>Infrared Controller Chip
<p>
- Make sure your infrared port is detected by the Linux kernel. For detailed information see the &dquot;Hardware Survey&dquot; section below.
<p>
<item>modutils
<p>
- Make sure you use modutils 2.1.x by <tt>insmod --version</tt>. I use version 2.1.121.
<p>
<item>Shared Library
<p>
- The shared library <tt>glibc2</tt> aka <tt>libc6</tt> is recommended. There are also efforts to use <tt>glibc2.1</tt>, you may get this at <url url="ftp://ftp.funet.fi/pub/gnu/funet/" name="ftp://ftp.funet.fi/pub/gnu/funet/"> .
<p>
- In some files you maybe have to change <tt>&num;include &lt;net/if_packet.h&gt;</tt> to <tt>&num;include &lt;linux/if_packet.h&gt;</tt> to get things to compile. This means using <it>kernel headers</it> instead of <it>glibc headers</it>. Please consult the mailing list archive, if your are interested in further information.
<p>
- But <file>libc.so.5</file> should work, too.
<p>
- I am not sure wether you need the <file>zlib</file> library if you use the data compression features.
<p>
<item>IrLAN
The latest release of <tt>net-tools</tt> (package <tt>netbase</tt> for Debian/GNU-Linux) is recommended, if you want to use an IrLAN connection. It's available from: <url url="ftp://ftp.netwinder.org/users/p/philb/net-tools/" name=" ftp://ftp.netwinder.org/users/p/philb/net-tools/">, <url url="http://www.tazenda.demon.co.uk/phil/net-tools/" name=" http://www.tazenda.demon.co.uk/phil/net-tools/"> and shortly from <url url="ftp://ftp.cs-ipv6.lancs.ac.uk/pub/Code/Linux/Net_Tools/" name="ftp://ftp.cs-ipv6.lancs.ac.uk/pub/Code/Linux/Net_Tools/"> .
<p>
<item>Graphical User Interface (GUI)
<p>
Currently there are two graphical user interfaces for Linux/IrDA under development one for KDE and one for GNOME. See GUI chapter below. For the GNOME application you will need the Perl-GTK+ module and Python. You must also install all the development packages. To run Linux/IrDA I recommend to check the command line tools first, because the GUIs don't seem to be finished yet.
<item>Security
<p>
- Most important, you must <tt>sync</tt> your disks!!! Maybe you have to reboot your machine. Have you read the disclaimer?
<p>
<item>Miscellaneous
<p>
- Other useful progs: APSFILTER, EZ-Magic, MagicFilter or something similar for the printer configuration.
</enum>
<sect>Kernel
<p>
Please read the Kernel-HOWTO to get more information about the compilation process. You'll find the Linux/IrDA code in:
<file>/usr/src/linux/net/irda</file> (protocol stuff)
<p>
<file>/usr/src/linux/drivers/net/irda</file> (device drivers)
<p>
<file>/usr/src/linux/include/net/irda</file> (header files)
<p>
<sect1>General Parameters
<p>
- Make sure you use <it>kernel 2.2.x</it> sources. If unsure about your kernel version try <tt>uname -r</tt>.
<p>
- Get the latest kernel patch from the Linux/IrDA project <url url="http://www.cs.uit.no/linux-irda/snapshots/" name="http://www.cs.uit.no/linux-irda/snapshots/">. Or from the Alan Cox kernel series at <url url="ftp.linux.org.uk/pub/linux/alan/2.2/" name="ftp.linux.org.uk/pub/linux/alan/2.2/"> . Put it into <file>/usr/src</file> or where else your kernel sources live and apply something like (replace <tt>patch-2_2.0-irdaXXX </tt> with the actual file name):
<code>
cd /usr/src
tar xvzf patch-2_2.0-irdaXXX.tar.gz
cd linux
patch -p1 -l &lt; ../patch-2_2.0-irdaXXX
</code>
<p>
- Experimental support has to be enabled <tt>CONFIG_EXPERIMENTAL</tt>.
<p>
- Enable sysctl in &dquot;General Setup&dquot; <tt>CONFIG_SYSCTL</tt>.
<p>
- You should have <it>proc file system support</it> <tt>CONFIG_PROC_FS</tt>.
<p>
- Also <it>serial support</it> for the SIR features <tt>CONFIG_SERIAL</tt>.
<p>
- I am not sure wether there has to be <it>printer support</it> for using a printer with Linux/IrDA <tt>CONFIG_PRINTER</tt>. But I assume this feature is not necessary.
<p>
- <it>Networking support</it> _must_ be enabled <tt>CONFIG_NET</tt>.
<p>
- Make sure you have <it>module support</it> <tt>CONFIG_MODULES</tt> in your kernel! Test it e.g. with <tt>lsmod</tt>.
<p>
- Also <tt>kerneld</tt> support <tt>CONFIG_KERNELD</tt>. But <tt>kmod</tt> (CONFIG_KMOD) also works. A monolithic kernel seems to work, too. But modules are highly recommended.
<p>
- To use <tt>irdadump</tt> you probably have to set <tt>CONFIG_PACKET</tt>.
<p>
If you only apply the Linux/IrDA patch, you should not have to do a <tt>make clean</tt>, so that should save you some time. I suggest you do something like this:
<code>make dep &amp;&amp; make all &amp;&amp; make modules &amp;&amp; make install &amp;&amp; make modules_install
</code>
If you get really strange errors, then try to rebuild from scratch after a <tt>make clean</tt>.
<sect1>IrDA Specific Parameters
<p>
The following is my draft for <file>../linux-2.2.3/Documentation/Configure.help</file>, parts are from Dag Brattli and Andreas Butz. Please consult the latest available kernel documentation for current information and new drivers.
<sect2>IrDA subsystem support
<p>
CONFIG_IRDA
<p>
IrDA(TM) is an industrial standard for infrared wireless
communication. Infrared ports let you communicate with printers,
modems, fax machines, LANs, and laptops. Speed ranges from 2400bps
to 4Mbps. To use this features you need the irda_utils provided by
the Linux/IrDA project http://www.cs.uit.no/linux-irda/ Further
information you may find there and in the Linux/IR-HOWTO at
http://www.snafu.de/&tilde;wehe/index_li.html
Currently it is recommended to build IrDA support as modules only.
Please see Documentation/modules.txt. Please note the status
of Linux/IrDA is still experimental.
<p>
<sect3>IrDA protocols
<p>
<itemize>
<item>IrLAN protocol
<p>
CONFIG_IRLAN
<p>
Builds the IrDA network device. Use ``ifconfig eth0 &lt;IP-NUMBER&gt;''
to configure it. - Just say Y
<item>IrLAN client support
<p>
CONFIG_IRLAN_CLIENT
<p>
If you connect to infrared devices via IrLAN one has to be the
server and the other the client. You can use both the client and
the server at the same time. The first one to connect becomes the
client. - Just say Y
Note: The latest patch includes peer-to-peer support instead.
<item>IrLAN server support
<p>
CONFIG_IRLAN_SERVER
<p>
If you connect to infrared devices via IrLAN one has to be the
server and the other the client. You can use both the client and
the server at the same time. The first one to connect becomes the
client. - Just say Y
Note: The latest patch includes peer-to-peer support instead.
<item>IrOBEX protocol
<p>
CONFIG_IROBEX
<p>
IrOBEX is a protocol for exchanging objects (files, vcards, etc.)
over an infrared connection. You can use it to exchange files
between linux and a PALM III. IrOBEX can also be used between two
Linux boxes, Linux and Windows95, etc. - Just say Y
<item>IrCOMM protocol
<p>
CONFIG_IRCOMM
<p>
Over IrCOMM you may communicate with cellular phones, etc. To use
this service you have to build a new device with
``mknod /dev/irnine c 60 64'', which works like
/dev/ttySx. - Just say Y
..Note: major and minor number are still not the official ones yet.
For latest improvements (IrSocket is on the way!), please look at
the page of Takahide Higuchi http://www.pluto.dti.ne.jp/&tilde;thiguchi/irda/
..Note: At the moment IrCOMM seems to crash your kernel easily,
you should probably wait for the next patch.
<item>IrLPT client support
<p>
CONFIG_IRLPT_CLIENT
<p>
Say Y here if you want to build support for the IrLPT client
protocol. If you want to compile it as a module, say M here and
read Documentation/modules.txt. The IrLPT client protocol can be
used to print documents to IrDA compatible printers like the
HP-5MP, or IrLPT printer adapters like
the ACTiSYS IR-100M. - Just say Y
<item>IrLPT server support
<p>
CONFIG_IRLPT_SERVER
<p>
Say Y here if you want to build support for the IrLPT server
protocol. If you want to compile it as a module, say M here
and read Documentation/modules.txt. The IrLPT server protocol
makes it possible to use a Linux machine as an infrared printer
server for other laptops. So if your Linux machine has a
cable connection to a printer, then other laptops can use
the Linux machine to print out documents using infrared
communication. - Just say Y
</itemize>
<sect3>IrDA protocol options
<p>
CONFIG_IRDA_OPTIONS
<p>
You may define some IrDA protocol options.
<itemize>
<item>Cache last
<p>
LSAP CONFIG_IRDA_CACHE_LAST_LSAP
<p>
Say Y here if you want IrLMP to cache the last LSAP used. This
makes sense since most frames will be sent/received on the same
connection. Enabling this option will save a hash-lookup per frame.
If unsure, say Y.
<item>FAST RRs
<p>
CONFIG_IRDA_FAST_RR
<p>
Use this option if you want to send faster RR (Receive Ready)
frames if the transmit queue is empty. This will give you much
better latencies but will consume more power, because of the
bouncing RR frame.
<item>Recycle RRs
<p>
CONFIG_IRDA_RECYCLE_RR
<p>
In the normal life of the IrLAP protocol, it sends a lot of
small RR (Receive Ready) frames over the link (at least when it
has nothing else to do). Saying Y to this option will make IrLAP
recycle these frames thus avoiding many alloc_skb's and
kfree_skb's. To do this it will only buffer one of these frame
which is enough for the usual case.
<item>Debug information
<p>
CONFIG_IRDA_DEBUG
<p>
Say Y here if you want the IrDA subsystem to write debug
information to your syslog. You can change the debug level in
/proc/sys/net/irda/debug.
If unsure, say Y (since it makes it easier to find the bugs).
</itemize>
<sect3>IrDA compressors
<p>
CONFIG_IRDA_COMPRESSION
<p>
You may use the compression methods BZIP2 and BSD. These are not
IrDA standard. This will allow two linux boxes to handshake
compression. It should be compatible with other IrDA devices,
although communication will not be compressed then.
<itemize>
<item>Deflate compression (experimental)
<p>
CONFIG_IRDA_DEFLATE
<p>
Say Y here if you want to build support for the Deflate compression
protocol. If you want to compile it as a module, say M here and
read Documentation/modules.txt. The deflate compression (GZIP) is
exactly the same as used by the PPP protocol. Enabling this option
will build a module called irda_deflate.o.
<item>BZIP2 compression
<p>CONFIG_IRDA_BZIP2
<p>
Help not available yet.
<item>BSD compression
<p>
CONFIG_IRDA_BSD
<p>
Help not available yet.
</itemize>
<sect2>Infrared-port device drivers
<p>
Three sorts of low level infrared drivers are available:
serial, dongle and FIR.
They will show up in /proc/net/dev (irda0)
after initialisation.
<p>
<sect3>IrTTY (uses serial driver)
<p>
Most IrDA chips support StandardInfraRed (SIR), which works up
to 115200bps and emulates a serial port (16550A UART). On many
laptops this port is detected by the serial support of the kernel,
see ``dmesg''. IrTTY connects the Linux/IrDA services
to this port. - You should say Y here.
<itemize>
<item>Serial dongle support
<p>
CONFIG_IRTTY_SIR
<p>
Say Y here if you want to build support for the IrTTY line
discipline. If you want to compile it as a module, say M here and
read Documentation/modules.txt. IrTTY makes it possible to use
Linux's own serial driver for all IrDA ports that are 16550
compatible. Most IrDA chips are 16550 compatible so you should
probably say Y to this option. Using IrTTY will however limit
the speed of the connection to 115200 bps (IrDA SIR mode).
If unsure, say Y.
</itemize>
<sect3>Dongle support
<p>
CONFIG_DONGLE
<p>
Currently four dongles (infrared adapters for the serial port)
are supported. The dongle is an infrared device which may be
connected to serial port, if you don't have built-in infrared
support for your machine. If you use a dongle together with a
laptop you maybe have to disable the IrDA support in the BIOS.
<itemize>
<item>ESI JetEye PC dongle
<p>
CONFIG_ESI_DONGLE
<p>
Say Y here if you want to build support for the Extended Systems
JetEye PC dongle. If you want to compile it as a module, say M here
and read Documentation/modules.txt. The ESI dongle attaches to the
normal 9-pin serial port connector, and can currently only be used
by IrTTY. To activate support for ESI dongles you will have to
insert ``irattach -d esi'' in the /etc/irda/drivers script.
http://www.extendsys.com/support/ftp/infrared.html
<item>ACTiSYS IR-220L and IR220L+ dongle
<p>
CONFIG_ACTISYS_DONGLE
<p>
Say Y here if you want to build support for the ACTiSYS
IR-220L and IR220L+ dongles. If you want to compile it as a module,
say M here and read Documentation/modules.txt. The ACTiSYS dongles
attaches to the normal 9-pin serial port connector, and can
currently only be used by IrTTY. To activate support for ACTiSYS
dongles you will have to insert ``irattach -d actisys'' or
``irattach -d actisys_plus'' in the/etc/irda/drivers script.
http://www.actisys.com
<item>Tekram IrMate 210B dongle
<p>
CONFIG_TEKRAM_DONGLE
<p>
Say Y here if you want to build support for the Tekram IrMate 210B
dongle. If you want to compile it as a module, say M here
and read Documentation/modules.txt. The Tekram dongle attaches to
the normal 9-pin serial port connector, and can currently only be
used by IrTTY. To activate support for Tekram dongles you will have
to insert ``irattach -d tekram'' in the /etc/irda/drivers script.
http://www.tekram.de/
<item>
<p>
CONFIG_GIRBIL_DONGLE
<p>
Say Y here if you want to build support for the Greenwich
Instruments GirBIL dongle. If you want to compile it as a module,
say M here and read Documentation/modules.txt. The Greenwich dongle
attaches to the normal 9-pin serial port connector, and can
currently only be used by IrTTY. To activate support for Greenwich
dongles you will have to insert ``irattach -d girbil'' in the
/etc/irda/drivers script.
http://www.greenwichinst.com/
</itemize>
<sect3>FIR support
<p>
FastInfraredSupport (FIR) needs a specific controller chip, which
supports up to 4Mps. - Just say Y
<itemize>
<item>NSC PC87108
<p>
CONFIG_NSC_FIR
<p>
NationalSemiConductor NSC PC87108 FIR chip e.g. used in the IBM
Thinkpad 560X and ACTiSYS IR2000 dongle. Probably the NSC PC87338
FIR chip is also supported. The driver supports SIR, MIR and FIR
(4Mbps) speeds. - Just say Y
<item>Winbond W83977AF (IR)
<p>
CONFIG_WINBOND_FIR
<p>
Winbond W83977AF (IR) FIR chip e.g. used in the Corel Netwinder
PC. The driver supports SIR, MIR and FIR (4Mbps)
speeds. - Just say Y
<item>Sharp UIRCC
<p>
CONFIG_SHARP_FIR
<p>
Say Y here if you want to build support for the Sharp UIRCC IrDA
chipset. If you want to compile it as a module, say M here and
read Documentation/modules.txt. This chipset is used by the Toshiba
Tecra laptops.
</itemize>
<p>
<sect>Linux/IrDA-Utils
<p>
<sect1>Compilation
<p>
<itemize>
<item>
Use the latest source snapshot of <tt>irda-utils</tt> available at <url url="http://www.cs.uit.no/linux-irda/irda-utils/" name="http://www.cs.uit.no/linux-irda/irda-utils/">
<item>
Untar the package with <tt>tar xvzf irda-utils&lt;VERSION&gt;</tt>. I recommend to do this in <file>/usr/src</file>.
<item>
Do a <tt>make depend</tt>.
<item>
Do a <tt>make clean</tt> (not necessary if you compile the package for
the first time).
<item>
Do a <tt>make all</tt> to build the binaries.
<item>
Do a <tt>make install</tt>, this brings <tt>irattach</tt> and <tt>irmanager</tt> into the right place and installs some config files in <file>/etc/irda</file>.
</itemize>
A recommendation from Bjoern Hansson &lt;Bjorn.Hansson@signal.uu.se&gt;: If <tt>make depend</tt> fails on <tt>stdef.h</tt> and <tt>stdarg.h</tt> just add <file>-I/usr/lib/gcc-lib/i586-linux/egcs-2.90.29/include/</file> or the according path for your system to the <tt>SYS_INCLUDES</tt> line in <file>Makefile</file>.
To compile <tt>irdadump</tt> and <tt>irdaping</tt> (which are not necessary to get Linux/IrDA to work) you probably to tweek the source a little:
Dag Brattli: &dquot; The problem is that I'm including kernel header files which conflicts with the libc header files. So why do I need to include kernel header files? Well, the libc/glibc header files does not know that much about IrDA (yet). The reason is just that IrDA is quite new. I could have just defined the stuff in the program itself, but then people would be able to compile the stuff even if the definitions had changed in the kernel. I think its better that you get a compile error than some possible strange behaviour. If you don't want to wait until I figure out how to solve this stuff, you can just remove the linux header files and define the constants in your program yourself:
<code>
&num;define PF_IRDA 23
&num;define AF_IRDA PF_IRDA
&num;define ARPHRD_IRDA 783
&num;define ETH_P_IRDA 0x0017
</code>
All the stuff above should not be changed, so it is probably safe to just hardcode them. I'll change the programs so they just includes the normal header files, and then defines these constants only if the header files didn't know about them. It should however be safe to include <tt>linux/irda.h</tt> .&dquot;
<p>
Though I never succeeded to compile all utilities without errors, I recommend to use at least the latest packages of <tt>libtool</tt>, <tt>m4</tt>, <tt>autoconf</tt>, and <tt>automake</tt> if you want to compile <tt>irdadump</tt>, <tt>irdaping</tt>, etc.
<sect1>Precompiled Packages
<p>
NOKUBI Takatsugu provides an <it>unofficial</it> <url url="http://www.daionet.gr.jp/&tilde;knok/debian" name="irda-utils Debian package"> (needs libc2.1). Efforts are on the way to include this package into the next Debian release, codename Potato.
<sect1>Contents of Linux/IrDA-Utils
<p>
<sect2>irmanager
<p>
The <tt>irmanager</tt> is user-space daemon that is inspired and quite similar to the <tt>cardmgr</tt> used in the PCMCIA distribution. For example, if IrLMP discovers a remote device with IrLAN provider capabilities and no local IrLAN client has registred, then IrLMP will send an event to the IrManager and make it <tt>modprobe</tt> the module required. When application level clients are ready for communication and user-space configuration, they can also notify IrManager about this, so that it can execute the right script. For example will IrLAN send the event <tt>EVENT_IRLAN_START</tt> when the data channel is ready for exchanging Ethernet frames. When IrManager receives this event, it will execute <tt>/etc/irda/network start &lt;devname&gt;</tt> to configure the network interface. If you use the RedHat variant of it, it will in turn execute <tt>/sbin/ifup&lt;devname&gt;</tt> .
<sect2>irattach
<p>
Usually <tt>irattach</tt> is started by <tt>irmanager</tt>. <tt>irattach</tt> attaches an IrDA capable tty to the basic services of Linux/IrDA. If <tt>kerneld</tt> or <tt>kmod</tt> are running, the modules <tt>irda</tt> and <tt>irtty</tt> are loaded automatically, if not you have to load them by hand in that order. It is recommended to start <tt>irattach</tt> in the background. To stop <tt>irattach</tt> just kill the process.
<sect2>load_misc
<p>
A Perl script which loads a Linux/IrDA module and builds the according device in <file>/dev</file> using <tt>mknod</tt>.
<sect2>/etc/irda
<p>
Configuration files, e.g. contains the serial port of the SIR driver:
<code>
drivers
network
network.opts
obex
</code>
You should at least configure the IR driver <file>drivers</file>:
<code>
&num;! /bin/sh
&num;
&num; drivers
&num;
&num; Initialize and shutdown IrDA device drivers.
&num;
&num; This script should be invoked with two arguments. The first is the
&num; action to be taken, either &dquot;start&dquot;, &dquot;stop&dquot;, or &dquot;restart&dquot;.
&num;
action=$1
device=$2
case &dquot;${action:?}&dquot; in
start)
irattach /dev/ttyS2 &num; The third serial port is an IrDA port
&num; irattach /dev/ttyS0 -d esi &num; Attach a ESI dongle to the first serial port
&num; insmod pc87108 &num; If your machine as a pc87108 FIR chipset
;;
stop)
killall irattach &num; ... or something. Currently not used
;;
restart)
/sbin/ifconfig ${device:?} down up
;;
esac
</code>
<sect2>irdaping
<p>
This is a program similar to <tt>ping(8)</tt>. It sends IrDA test frames (added some userdata which contains the frame number and the time the frame was sent). You can also change the size of the frame by using the <tt>-s</tt> option. You must supply an IrDA device address, and not an IP address. You have to be able to get that device address by some method <tt>irdadump</tt>?
Here is one output sample (pinging an ACTiSYS IR-100M):
<code>
dagbnb /home/dagb/linux/irda-utils/irdaping/ &num; ./irdaping 0xf7be8388
IrDA ping (0xf7be8388): 32 bytes
32 bytes from 0xf7be8388: irda_seq=0 time=102.466003 ms.
32 bytes from 0xf7be8388: irda_seq=1 time=102.202003 ms.
32 bytes from 0xf7be8388: irda_seq=2 time=102.170998 ms.
32 bytes from 0xf7be8388: irda_seq=3 time=101.633003 ms.
4 packets received by filter
</code>
<sect2>irdadump
<p>
One advantage of implementing IrDA device drivers as network device drivers is that you should be able to attach sniffers to the device (or actually the packet type). That way, it is possible to use a really handy utility called <tt>irdadump</tt> (instead of <tt>tcpdump</tt>). This will make debugging MUCH easier. Linux-2.2 implements the BPF (Berkeley Packet Filter), so its possible to filter out exactly the frames you want to see.
Note: You probably have to be <it>root</it> for using <tt>irdadump</tt> . <tt>CONFIG_PACKET</tt> has to be enabled in the kernel. If compiled as a module you might load the module manually. <tt>irdadump</tt> has been coverted into a library, so it can be used from GUI applications as well.
Here is a sample output of a small session between Linux and a Palm III. This log shows that the local irobex layer is not responding, so the Palm III sends a disc frame.
<code>
dagbnb /home/dagb/linux/irda-utils/irdadump/ &num; ./irdadump
20:18:15.305711 xid:cmd:saddr=0x05c589 &gt; daddr=0xffffffff,S=6,s=0
20:18:15.385597 xid:cmd:saddr=0x05c589 &gt; daddr=0xffffffff,S=6,s=1
20:18:15.465568 xid:cmd:saddr=0x05c589 &gt; daddr=0xffffffff,S=6,s=2
20:18:15.545953 xid:cmd:saddr=0x05c589 &gt; daddr=0xffffffff,S=6,s=3
20:18:15.625574 xid:cmd:saddr=0x05c589 &gt; daddr=0xffffffff,S=6,s=4
20:18:15.705575 xid:cmd:saddr=0x05c589 &gt; daddr=0xffffffff,S=6,s=5
20:18:15.785601 xid:cmd:saddr=0x05c589 &gt; daddr=0xffffffff,S=6,s=255,info=Linux
20:18:18.075526 xid:cmd:saddr=0xb50c14b &gt; daddr=0xffffffff,S=6,s=0
20:18:18.225498 xid:cmd:saddr=0xb50c14b &gt; daddr=0xffffffff,S=6,s=1
20:18:18.375495 xid:cmd:saddr=0xb50c14b &gt; daddr=0xffffffff,S=6,s=2
20:18:18.526355 xid:cmd:saddr=0xb50c14b &gt; daddr=0xffffffff,S=6,s=3
20:18:18.675614 xid:cmd:saddr=0xb50c14b &gt; daddr=0xffffffff,S=6,s=4
20:18:18.676364 xid:rsp:saddr=0x05c589 &gt; daddr=0xb50c14b,S=6,s=4
20:18:18.765506 xid:cmd:saddr=0xb50c14b &gt; daddr=0xffffffff,S=6,s=5
20:18:18.927221 xid:cmd:saddr=0xb50c14b &gt; daddr=0xffffffff,S=6,s=255,info=Palm III
20:18:18.975796 snrm:cmd,ca=0xfe,pf=1
20:18:18.976534 ua:rsp,ca=0x58,pf=1
20:18:18.977145 ua:rsp,ca=0x58,pf=1
20:18:19.585627 rr:rsp,ca=0x58,nr=0,pf=1
20:18:19.585810 rr:rsp,ca=0x58,nr=0,pf=1
20:18:19.606413 i:cmd,ca=0x58,nr=0,ns=0,pf=1
20:18:19.606582 rr:rsp,ca=0x58,nr=1,pf=1
20:18:19.627708 rr:cmd,ca=0x58,nr=0,pf=1
20:18:19.627871 i:rsp,ca=0x58,nr=1,ns=0,pf=1
20:18:19.650571 disc:cmd,ca=0x58,pf=1
20:18:19.650736 ua:rsp,ca=0x58,pf=1
20:18:21.165524 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=0
20:18:21.315608 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=1
20:18:21.315793 xid:rsp:saddr=0x05c589 > daddr=0xb50c14b,S=6,s=1
20:18:21.395499 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=2
20:18:21.545516 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=3
20:18:21.695500 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=4
20:18:21.845840 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=5
20:18:22.007222 xid:cmd:saddr=0xb50c14b > daddr=0xffffffff,S=6,s=255,info=Palm III
20:18:22.056143 snrm:cmd,ca=0xfe,pf=1
20:18:22.056310 ua:rsp,ca=0xc8,pf=1
20:18:22.056381 ua:rsp,ca=0xc8,pf=1
37 pacckets received by filter
</code>
<sect2>gnobex
<p>
GNOME GUI for using the IrOBEX protocol, to connect to Palm III.
<sect2>irkbd
<p>
Support for infrared keyboard (and mouse?) protocol IrKBD.
<sect2>irdalib
<p>
Linux/IrDA library.
<sect2>obex
<p>
Please compile <tt>irdalib</tt> before compiling <tt>obex</tt>. Contains <tt>irobex_test</tt>, <tt>irobex_receive</tt> and <tt>irobex_palm3</tt> . And <tt>obex_tcp</tt> which makes it possible to use OBEX over TCP/IP.
<sect>Configuration
<p>
<sect1>General Configuration
<p>
<itemize>
<item>
First you should put your IR 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.
<item>
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).
<item>
Add the following lines to your <file>/etc/conf.modules</file> file:
<code>
&num; IrDA
alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty
</code>
Note: The format of this entries has changed!
Then do a <tt>depmod -a</tt> to update, and then <tt>ircomm</tt> should be automagically loaded when you need it. Here is what you need in <file>/dev</file>:
<verb>
dagbnb /usr/src/ &gt; ll /dev/ir*
crw------- 1 dagb 161, 0 Aug 25 20:13 /dev/ircomm0
crw-rw-rw- 1 root 161, 1 Jun 18 13:44 /dev/ircomm1
crw-rw-rw- 1 root 161, 16 Jun 18 13:44 /dev/irlpt0
crw-rw-rw- 1 root 161, 17 Jun 18 13:44 /dev/irlpt1
</verb>
<item>
Have a look into the files in <file>/etc/irda</file>. They are similar to the files in <file>/etc/pcmcia</file>. Edit <file>/etc/irda/drivers</file> to reflect your setup. Most people will use <tt>irattach</tt> from that file. The files are:
<code>Makefile
network*
network.redhat*
serial
drivers
network.opts
obex
printer
</code>
<item>
Run <tt>depmod -a</tt>.
</itemize>
<sect1>IrManager
<p>
Dag Brattli wrote: &dquot; <it>IrManager</it> [...].is a user-space daemon that is inspired and quite similar to the <it>cardmgr</it> used in the PCMCIA distribution.
The <it>IrManager</it> will receive events from the kernel level side of the protocol stack. When the <it>IrManager</it> receives an event it can execute shell commands and scripts, so I have added the <file>/etc/irda</file> directory which will contain such scripts. [...]
For example, if IrLMP discovers a remote device with IrLAN provider capabilities and no local IrLAN client has registered, then IrLMP will send an event to the IrManager and make it &dquot;modprobe&dquot; the module required. [...]
When application level clients are ready for communication and user-space configuration, they can also notify IrManager about this, so that it can execute the right script. For example IrLAN will send the event EVENT_IRLAN_START when the data channel is ready for exchanging Ethernet frames. When IrManager receives this event, it will execute <tt>/etc/irda/network start &lt;devname&gt;</tt> to configure the network interface. This network script is actually the same as used by the PCMCIA code and since I'm using the Redhat variant of it, it will in turn execute <tt>/sbin/ifup &lt;devname&gt;</tt>.
So by using the IrManager, I &dquot;only&dquot; have to do this when I start the stack:
<code>
irattach /dev/ttyS2 &
irmanager -d 1 &num; -d 1 means: start discovery process
</code>
and then when my laptop discovers the IrLAN provider (HP Netbeamer in my case) it will ask <it>IrManager</it> to load the module <tt>irlan_client</tt>. When the connection is up and ready, it will ask it to execute <file>/etc/irda/network start eth0</file>. When the connection is broken, it will again ask it to take down the interface using <tt>/etc/irda/network stop eth0</tt>.[...]
That's all to get it working if you are using Redhat. If you are using some other distribution which doesn't have <file>/sbin/ifup</file>, then you better copy <file>/etc/pcmcia/network.opts</file> to <file>/etc/irda/network.opts</file> or configure the file yourself.
If you want to use the IrLAN server, you will still have to <tt>modprobe irlan_server</tt> before you start the <tt>irmanager</tt> _without_ <tt>-d 1</tt>.
And just like the <tt>cardmgr</tt>, you will (if you want to) get the beeps when the connection is up and running and when it is disconnected!!!
I hope that we can add such scripts for all the other clients/services that need user level configuration. It would be really cool to have a <file>/etc/irda/printer</file> script for configuring IrDA(TM) capable printers. So if you get in range of an IrDA(TM) capable printer, then IrManager should load the <tt>irlpt_client</tt> module, and also configure the other stuff that needs to be done for using this printer.
I also hope that we can use the <tt>config</tt> file for configuring IrDA(TM) ports and device drivers. Something like:
<code>
Device Drivers
module &dquot;irtty&dquot; script=&dquot;irattach /dev/ttyS2&dquot;
module &dquot;smc_ircc&dquot; irq=11 port=0x34f
</code>
So that IrManager can load and start all these when it is executed. In this way we would only have to start IrManager in <file>/etc/rc.d/init.d/irda</file> and the rest would be plug and play. There would be no need for manually starting programs and configuring devices.
When <tt>irmanager</tt> receives the following events for a device &lt;dev&gt; it will currently do:
EVENT_IRLAN_START, start and configure the device using <tt>/sbin/ifup &lt;dev&gt;</tt>
EVENT_IRLAN_STOP, close the device using <tt>/sbin/ifdown &lt;dev&gt;</tt>
This can however be easily changed by the user, if this is not what is the prefered behaviour.
<sect1>Low Level Drivers
<p>
There are three sorts of low level drivers: SIR, dongle and FIR. If the right driver is detected by the kernel you get a message like:
<code>
IrDA irda_device irda0 registered.
</code>
<p>
<sect2>SIR
<p>
<itemize>
Try to find out which serial port is used by the IR device. You may do so by watching the output of <tt>dmesg</tt>. If serial support is modularized do an <tt>insmod serial</tt> first. Look for an entry like:
<code>
Serial driver version 4.25 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A &num;first serial port /dev/ttyS0
ttyS01 at 0x3000 (irq = 10) is a 16550A &num;e.g. infrared port
ttyS02 at 0x0300 (irq = 3) is a 16550A &num;e.g. PCMCIA modem port
</code>
If this is not the case, you either don't have infrared support enabled in the BIOS or the SIR mode of your infrared device is not detected by the kernel. Currently I know only two laptop models with this effect, the HP OmniBook 800 and the Toshiba Libretto models. I am not sure whether PnP support effects the detection of the IR port. If you are unsure try it out and let me know the results. Maybe you can use FIR mode if SIR doesn't work.
<item>
In some situations you may have to use <tt>setserial /dev/ttyS&lt;0-2&gt; port 0xNNNN irq M</tt> to set the values for your infrared serial port, especially if the infrared port is a separate serial line. You usually don't need to change the values! For further information look into the FAQ section below.
<item>
If you don't use <tt>kerneld</tt> or <tt>kmod</tt> insert the irda module with <tt>modprobe irda</tt>.
<item>
Do <tt>lsmod</tt>. It should show the modules <tt>irda</tt> and <tt>irtty</tt> now.
<item>
A look into <file>/var/log/messages</file> should show the entry &dquot;<tt>Serial connection established</tt>&dquot; now.
<item>
Say <tt>irmanager -d1</tt>, which will start the necessary programs, such as <tt>irattach</tt>.
<item>
Give <tt>irattach</tt> some time, e.g. seven seconds, to detect other IR devices. Then watch the output from the kernel that you will hopefully get in <file>/var/log/messages</file>. It should look like the following (I removed some lines, which were not related to Linux/IrDA):
<verb>
Jan 2 12:57:26 japh kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
Jan 2 12:57:26 japh kernel: ttyS02 at 0x03e8 (irq = 4) is a 16550A
Jan 2 12:57:26 japh kernel: Linux Support for the IrDA (tm) protocols (Dag Brattli)
Jan 2 12:59:09 japh syslog: executing: 'echo 1 &gt; /proc/sys/net/irda/discovery'
Jan 2 12:59:09 japh syslog: Setting discovery to 1 exited with status 1
Jan 2 12:59:09 japh syslog: + 0.1 Fri Jul 25 11:45:26 1997 Dag Brattli
Jan 2 12:59:09 japh syslog: + 0.1 Fri Jul 25 11:45:26 1997 Dag Brattli
Jan 2 12:59:09 japh syslog: Serial connection established.
Jan 2 12:59:09 japh kernel: IrDA irda_device irda0 registered.
Jan 2 13:01:22 japh syslog: executing: './drivers start '
Jan 2 13:01:22 japh syslog: Serial connection established.
Jan 2 13:01:42 japh syslogd: Printing partial message
Jan 2 13:01:42 japh 0.1 Fri Jul 25 11:45:26 1997 Dag Brattli
Jan 2 13:02:49 japh kernel: IrDA Discovered: japh
Jan 2 13:02:49 japh kernel: Services: Computer
</verb>
<item>
Even more information you can get with <tt>cat /proc/net/irda/discovery</tt> .
</itemize>
<sect2>Dongle Connection - Infrared Adapters for the Serial Port
<p>
The currently supported dongles are the Extended Systems Inc. ESI-9680 JetEye, the Tekram IRmate 210B, the ACTiSYS IR220L and 220L+, the Greenwich GIrBIL.
dongle.
<p>
Dag Brattli wrote (modified by wh): &dquot;To use dongles you have to do something like this:
<code>
modprobe tekram &num; or esi or actisys
irmanager -d 1 &num;
irattach -d tekram &num; or -d esi or -d actisys
</code>
As you can see, you must still use the <tt>-d</tt> option with <tt>irattach</tt> 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:
<code>
modprobe tekram
modprobe esi
irattach /dev/ttyS0 -d esi &
irattach /dev/ttyS1 -d tekram &
</code>
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 <tt>irattach</tt> so that the kernel knows which dongle you are using (and what QoS can be used):
<code>
irattach /dev/ttyS0 -d actisys &num; for the 220L dongle
irattach /dev/ttyS0 -d actisys+ &num; for the 220L+ dongle
</code>
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!&dquot;
Note: When I tried to use an infrared modem (Swissmod 56Ki, manufactured by Telelink AG) connected to my laptop (IrDA works with Window$95 only, due to non standard hardware) I had to remove the infrared support in the BIOS to get it working!
Dag Brattli: &dquot;It is now possible to use <tt>irport</tt> instead of <tt>irtty</tt>! I have moved all the dongle stuff out of <tt>irtty</tt> and into <tt>irda_device</tt>, so it will also be possible to attach dongles to <tt>irport</tt>. Need however to make a small user-space utility <tt>dongle_attach</tt> that can be used to attach dongles to a specific driver instance. BTW. <tt>irattach</tt> is still working as before, and you will not notice the difference even when attaching dongles to <tt>irtty</tt> (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 <tt>insmod</tt> like this: <tt>insmod irport io=0x3f8 irq=4</tt>, or whichever values you use. You can also add these parameters to <file>/etc/conf.modules</file> like this: <tt>options irport io=0x3f8 irq=4</tt>, but then you must remember to do a <tt>depmod -a</tt> and use <tt>modprobe irport</tt> instead of <tt>insmod</tt>.&dquot;
<p>
<sect2>Dongle Connection - Infrared Motherboard Adapter
<p>
Support for the ACTiSYS IR2000 dongle has been implemented in a file called <file>pc87108</file> which you can either compile into the kernel or <tt>insmod/modprobe</tt> to insert the module:
<code>
irmanager -d 1
modprobe pc87108
</code>
or insert <tt>modprobe pc87108</tt> into the <file>/etc/irda/drivers</file> file (I think).
From James &lt;james@esc.cam.ac.uk&gt; 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 conpatible transceiver will work (I have a stack of old IRM3001 these are now obselete) you need to hook a capacitor (use a tantalum about &tilde;1uF) between 5V and 0V near the transceiver and then connect everthing else up (RX-&gt;RX, TX-&gt;TX, 5V-&gt;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.
<sect2>Fast InfraRed (FIR)
<p>
The IrDA(TM) standard knows <it>three</it> kinds of speeds:
<p>
<enum>
<item>
SIR = Standard IrDA, up to 115kbps IrDA,
<item>
MIR = Medium Speed IrDA,
<item>
FIR = Fast IrDA (4Mbps),<item>
VFIR = Very Fast IrDA(16Mbps), seems to become a future standard
</enum>
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. Currently there are two FIR chips supported: NationalSemiConductor NSC PC87108 e.g. used in IBM Thinkpad 560X and Winbond W83977AF (IR) FIR chip e.g. used in the Corel Netwinder PC. 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).
<p>
<sect>Specific Connections and IrDA - Protocols
<p>
<sect1>Printer Connection - IrLPT, IrTTP
<p>
IrLPT support is under heavy construction at the moment. Maybe it will be replaced by IrCOMM. Please see mailing list archive.
<itemize>
<item>
Remove any current print jobs with <tt>lprm &dquot;*&dquot</tt>.
<item>
If you don't use <tt>kerneld</tt> do a <tt>modprobe irtty</tt>.
<item>
Do a <tt>modprobe irlpt_client</tt>.
<item>
Check the modules with <tt>lsmod</tt>. This should show: <tt>irda</tt>, <tt>irtty</tt> and <tt>irlpt_client</tt>
<item>
<tt>cat /proc/misc</tt>. Gives you the <it>minor device-number</it> . It is the first number in the line with irlpt0.
<item>
<tt>su</tt> to root, and do <tt>mknod /dev/irlpt0 c 10 &lt;minor device-number&gt;</tt>. Note: Something like <tt>./MAKEDEV irlpt0</tt> is not possible yet. But maybe <tt>load_misc irlpt</tt> works, though I couldn't test this yet.
<item>
Try to write a small file to /dev/irlpt0 by <tt>cat FILE &gt;/dev/irlpt0</tt> (do not wonder about a bad format this is just a first check). For me this didn't always work, but I couldn't find out why not.
<item>
The better way is to change your <file>/etc/printcap</file> to use <file>/dev/irlpt0</file> in addition or instead of <file>/dev/lp1</file>. See <it>Printing-HOWTO</it> for detailed information.
<item>
For easy printer setup you may use a printing software like APSFILTER, MagicFilter EZ-Magic (with RedHat there should also be a GUI for this purpose). Make a copy of /etc/printcap before.
<item>
Example for APSFILTER with a HP 6P (non-postscript, HP 6MP is with postscript). The two relevant questions are:
<p>
&dquot;Do you have a (s)serial or a (p)arallel printer interface?&dquot;
Answer &dquot;p&dquot;
<p>
&dquot;What's the device name for your parallel printer interface?&dquot;
Answer &dquot;<file>/dev/irlpt0</file>&dquot;
<p>
<item>
Restart the print daemon with <tt>kill -HUP &lt;PID of lpd&gt;</tt>. If you use another print daemon choose the according command.
<item>
Watch whether the connection indicator of your printer shows activity, e.g. the green light above the IR port of a HP 6P/MP comes on (lower left hand corner, near the paper tray).
<item>
I couldn't get to manage printjobs larger than approximately 10 pages yet. But maybe this depends on the memory size of my hardware, which is 16MB. There seems to be a problem with the software too, Thomas Davis wrote: &dquot;I will ... limit the irlpt, so it won't eat memory when you send a large print file.&dquot;.
</itemize>
<p>
Takahide Higuchi reported: &dquot; I have been debugging IrCOMM with a printer ( Canon BJC-80v ) with IrDA port and IrCOMM protocol (not IrLPT). I can print a short e-mail text though, it easily causes dead lock when I try to print a postscript with gs.&dquot;
<p>From the page of Thomas Davis <url url="http://www.jps.net/tadavis/irda" name="http://www.jps.net/tadavis/irda ">: To use the IrLPT server, you need to perform the following steps:
<code>
/sbin/insmod irlpt_server
/sbin/mknod /dev/irlptd c 10 `grep irlptd /proc/misc|cut -f 1`
</code>
At this point, the IrLPT server is ready to recieve print jobs; now; all you need is this simple shell script
<code>
&num;/bin/sh
&num;
while (true)
do
cat /dev/irlptd | lpr
done
</code>
<p>
Dag Brattli: I hope that this will make it easier for all you that prefer to live in user-space, to make your own IrDA applications and try it out. Some printers actually use IrTTP (because of the limitations of IrLPT), so now you can write your own small user-space printer client so you can talk to it:
<code>
int discover_devices(int fd)
{
struct irda_device_list *list;
unsigned char buf[sizeof(struct irda_device_list) +
sizeof(struct irda_device_info) * MAX_DEVICES];
int len;
int daddr;
int i;
len = sizeof(struct irda_device_list) +
sizeof(struct irda_device_info) * MAX_DEVICES;
list = (struct irda_device_list *) buf;
if (getsockopt(sfd, SOL_IRLMP, IRLMP_ENUMDEVICES, buf, &amp;len)) {
perror(&dquot;getsockopt&dquot;);
exit(-1);
}
if (len > 0) {
/*
* Just pick the first one, but we should really ask the
* user
*/
daddr = list->dev[0].daddr;
printf(&dquot;Discovered: (list len=%d)\n&dquot;, list->len);
for (i=0;i<list->len;i++) {
printf(&dquot; name: %s\n&dquot;, list->dev[i].info);
printf(&dquot; daddr: %08x\n&dquot;, list->dev[i].daddr);
printf(&dquot; saddr: %08x\n&dquot;, list->dev[i].saddr);
printf(&dquot;\n&dquot;);
}
}
return daddr;
}
void client()
{
struct sockaddr_irda peer;
int addrlen = sizeof(struct sockaddr_irda);
int daddr, actual;
char buf[1024];
fd = socket(AF_IRDA, SOCK_STREAM, 0);
daddr = discover_devices(fd);
peer.sir_family = AF_IRDA;
strcpy(peer.sir_name, &dquot;P1284&dquot;);
peer.sir_addr = daddr;
connect(fd, (struct sockaddr *) &amp;daddr, sizeof(struct sockaddr_irda));
/* Try to send something */
actual = send(fd, &dquot;Testing&dquot;, 8, 0);
/* Try to read reply */
actual = recv(fd, buf, 1024, 0);
}
</code>
<sect1>LAN Connection - IrLAN
<p>
<itemize>
<item>
You might connect your Linux box using IrLAN to another network device such as a Linux box with IrLAn, a HP NetBeamer or a Window$95 box with Infrared Network Device support.
<p>
<item>
Dag Brattli wrote: &dquot;If you want to use IrLAN you must <tt>modprobe irlan_client</tt> before <tt>ifup eth0</tt>. I had to remove the request_module() stuff since that needed a process context which I don't have in the kernel. &dquot;
<p>
Maybe you have to choose the access mode. You can do this by using <tt>modprobe irlan access=1</tt> for direct mode. IrLAN states that a provider can either be in <it>direct</it> mode, or in <it>peer</it> mode, so you currently have to choose when you start IrLAN.
<p>
<item>
Run <tt>ifconfig eth0 up &lt;ip_address&gt; netmask &lt;ip_netmask&gt;</tt> to configure it with IP-address and other parameters. If the protocol is still running you may start communicating. It is possible to use RedHat's <file>netcfg</file> to do this, since it makes it very easy. Next time you only need to do <tt>/sbin/ifup eth0</tt>. Notice that <tt>ifconfig</tt> does not know how to deal with IrLAP addresses, so the address is really just the 4 first bytes (in little endian format).
<p>
<item>
Test the network device by pinging to it. For detailed information about further setup see the <it>NET3-HOWTO</it>.
<p>
<item>
Do not forget to add a route, e.g. <tt>route add default gw &lt;ip_gateway&gt;</tt> or <tt>route add -host &lt;target host&gt; dev eth0</tt>.
<p>
<item>
Ping to another IP now, to test the connection.
<p>
<item>
For testing reasons I recommend only to use one laptop and one IR ethernet device in the same room. If there are problems look which different modes for the IR ethernet device are possible. Try them.
</itemize>
For an ACTiSYS FIR board and dongle you may do:
<code>
irmanager -d1
/sbin/modprobe pc87108 &num; remove irattach from /etc/irda/drivers, or
&num; substitute irattach with the modprobe!
</code>
On machine 1:
<code>
modprobe irlan_client &num; not really necessary since irmanager should do this!
</code>
On machine 2 (if you don't have an access-point)
<code>
modprobe irlan_server
</code>
<p>
Do not compile <tt>irlan_server</tt> into the kernel, since it currently does not like that! You should have configured <file>/etc/sysconfig/network-scripts/ircfg-eth0</file> with a proper ad-hoc network if you are using two machines. If you have an access-point, then the normal setup should be fine.
<p>
Notice that in the latest patch (2.2.0-irda1) <tt>irlan_client</tt> will call the device <tt>irlan0</tt> by default, but you can change this by giving <tt>eth=1</tt> as an option to <tt>irlan_client</tt> (<tt>modprobe irlan_client eth=1</tt> or <tt>options irlan_client eth=1</tt> in <file>/etc/conf.modules</file>).
The next release of IrLAN will be only one module, so you don't need to think about if you need to have the client and/or the server installed.
It's possible to do <tt>ifconfig irlan0 -broadcast</tt> to stop the AP from flooding you with broadcast frames! That can be a problem if you are connected to a very large Ethernet segment. The only problem is that your machine will then have to initiate all communications and can therefore not function as a server (well, you could probably make a stationary machine somewhere answer ARP requestes on your behalf).
When using the IrLAN software from HP, you maybe have to name your computer &dquot;HP NetbeamIR&dquot; in the IAS entry to make it connect. Also I have heard rumors that a &dquot;Psion 3c&dquot; also wanted to connect only to another IR device if it had the same or a similar name.
<sect1>HP NetBeamer Connection
<p>
From Renaud Waldura: All the IrDA stuff is compiled in as modules.
<itemize>
<item>
edited <file>/etc/irda/drivers</file> to include <tt>irattach /dev/ttyS0</tt> (or whatever your &dquot;serial&dquot; IrDA port is, WH). Also <file>/etc/conf.modules</file> contains <tt>alias tty-ldisc-11 irtty</tt>.
<item>
<tt>irmanager -d 1</tt> then <tt>echo 3 &gt;&gt; /proc/sys/net/irda/debug</tt> to see what's going on.
<item>
<tt>modprobe irlan</tt>
<item>
I had to <tt>echo 9 &gt;&gt; /proc/sys/net/irda/slot_timeout</tt> (use 90 for newer kernels!) in order to have the NetbeamIR recognized. Otherwise I was only getting a bunch of &dquot;media busy&dquot; messages, and no actual discovery of the NetbeamIR. 9 is the smallest value that worked for me.
<item>
renamed <file>/etc/irda/network.orig</file> to <file>/etc/irda/network</file> and edited <file>/etc/irda/network.opts</file> for my IP config. Also copied <file>/etc/pcmcia/shared</file> to <file>/etc/irda</file> (this file is apparently missing from the distribution).
<item>
I also had to comment out <tt>grep_stab $1 &lt; /var/run/stab</tt> (line 131) in <file>/etc/irda/shared</file>. For some reason it fails, spitting a &dquot;usage&dquot; message.
<item>
moved laptop in range, the NetbeamIR is discovered, irlan0 created and config'ed.
<item>
transferred data at 7 kb/s, both ways: <tt>ping</tt>, <tt>ftp</tt>, <tt>telnet</tt>. Yaho!
</itemize>
<sect1>Palm III Connection - IrOBEX
<p>
The IrOBEX stuff seems under rapidly improving changing development. So the applications change, too. Therefore I just can't give quite exact information. Please see also the report by Dag Brattli at <url url="http://www.cdpubs.com/hhsys/archives/66/10brattl.pdf" name="http://www.cdpubs.com/hhsys/archives/66/10brattl.pdf"> .
<p>
Please note: IrOBEX now is in user-space and uses IrDA sockets. Remember that when using sockets, you don't need to have irobex enabled in the kernel, and <file>/dev/irobex</file> is not used anymore!The <file>/etc/irda</file> script is really only good for configuration of the devices, making the right <tt>mknod</tt> for <file>/dev/irobex</file> etc., not for starting applications.
<itemize>
<item>Palm III -&gt; Linux
<p>
1) Terminal 1&gt; <tt>irattach /dev/ttyS&lt;x&gt;</tt>
<p>
2) Terminal 2&gt; <tt>load_misc irobex</tt>
<p>
3) Terminal 3&gt; Start <tt>irobex_app</tt> in the irobex directory. I suppose <tt>irobex_app</tt> is not working anymore. Now you should use the <tt>gtk/irobex</tt> program instead! You need to have the gtk library installed to use this program. A command line frontend should be programmed by someone. Maybe the programm to use is <tt>irobex_receive</tt>.
<p>
4) Beam something from your Palm III.
<p>
5) If everything is successful, you can take a look at a new file that has been created in the directory in which you started irobex_app (or in /tmp for irobex_receive). This file will be named after the object you just transfered.
<p>
<item>Linux -&gt; Palm III
<p>
This should also be possible, but I don't have any further information
right now.
<item>PPP
<p>
Rui Oliveira wrote: &dquot;This is just to let you know that with the latest IrCOMM patch (050998) of Takahide Higuchi, I managed to <tt>HotSync</tt> and establish a PPP connection between my Palm III and my Linux box. I'm using IRLink (from IsComplete) to redirect the serial port to ir. Communication with pilot-xfer (probably at <url url="http://www.slac.com/pilone/kpilot_home/mainpage.html" name="http://www.slac.com/pilone/kpilot_home/mainpage.html">) works flawlessly. Although I was able to establish a PPP connection, I'm still unable to fetch mail and do Web browsing. This is probably due to connection time-outs. I am checking this out. Please see the <it>PPP-HOWTO</it> for further information about PPP.
... I managed to establish an apparently robust connection between my Linux box and a Palm III. The <tt>pppd</tt> invocation I use is as follows:
<tt>/usr/sbin/pppd /dev/irnine 57600 192.168.2.10:192.168.2.11 proxyarp passive silent persist noauth local nodetach</tt>. Over the PPP connection I used <tt>ping</tt>, <tt>ssh</tt>, and <tt>http</tt>.
Strange is however the fact that discovery must be enabled (<tt>irmanager -d 1</tt>). Otherwise, even with an active IrCOMM connection, the link goes down due to a IrLAP disconnect.
The pilot-link tools (used for Linux/Palm synchronization) also ran flawlessly over IrCOMM via <file>/dev/irnine</file> or <file>/dev/ircomm</file>.&dquot;
<item>IrCOMM
<p>
Jon Howell wrote: &dquot;I thought I'd try IrCOMM, since the Palm III can be made to reroute serial info to the IR port (using IrLink from IS/Complete, available at www.palmcentral.com), and then you can run a terminal program (like <it>PalmTelnet</it> in serial mode) over IrDA. I can only assume it's using the IrCOMM protocol. I've tested this configuration between two palm pilots, but of course I can't know what the protocol running over the IR is.&dquot;
(1) Start <tt>HotSync</tt> on your Palm. You need the IrDA upgrade for the Palm to have IrCOMM support <url url="http://www.palm.com/custsupp/downloads/irenhanc.html" name="http://www.palm.com/custsupp/downloads/irenhanc.html"> .
(2) Place the Palm in front of the dongle.
(3) Start <tt>pilot-xfer -p /dev/irnine -s &lt;sync-dir&gt;</tt> .
And if you are lucky it will start syncing. If you start <tt>pilot-xfer</tt> before you start <tt>HotSync</tt> on the pilot, you will _not_ be lucky!
Maybe a terminal program like <it>PalmTerm</it> is also useful.
</itemize>
Wessel de Roode wrote: The Palmpilot is default locked on 57k. You can however if you write your own software for the Pilot, use the 115k line settings. I quote a part from the <tt>irlib.h</tt>:
<code>
---------- irlib.h from the SDK 3.0 from palmpilot -----
// Options values for IrOpen
&num;define irOpenOptBackground 0x80000000 // Unsupported background task use
&num;define irOpenOptSpeed115200 0x0000003F // sets max negotiated baud rate
&num;define irOpenOptSpeed57600 0x0000001F // default is 57600
&num;define irOpenOptSpeed9600 0x00000003
-------------- end quote --------------------------------
</code>
Peter Pregler reported: If the Palm enters the range of the irda-device a popup appears with the text &dquot;Transmission: waiting for sender&dquot;
Ron Choy answered: There is a software called <it>ShutupIR</it> that is supposed to help with this problem of annoying popup <url url="http://hp.vector.co.jp/authors/VA005810/irda/shutup10.zip" name="http://hp.vector.co.jp/authors/VA005810/irda/shutup10.zip"> I haven't tried it but it looks like it would fix your problem.
<sect1>Palm III Connection to IBM Thinkpad 600
<p>
This chapter is a courtesy of Harald Milz - SuSE. Minor changes by Werner Heuser to fit into the HOWTO.
<p>
This document describes how to set up Linux/IrDA on an IBM Thinkpad 600. This works for my machine. Your mileage may vary with other machines.
<sect2>Prerequisites
<p>
<itemize>
<item>Reboot to the preinstalled M$ OS and activate the IR port using the Thinkpad tools. There is currently no Linux tool to achieve that. <it>This will disable your internal serial port (ttyS0)!</it>
<item>Reboot to Linux and configure a kernel with support for IrDA and IrCOMM. The Linux-IR-HOWTO talks about IrOBEX as well, but this is just for beaming objects across. This doesn't work with <tt>hotsync</tt> as far as I know (didn't try yet).
</itemize>
<sect2>Adding support for IrDA
<p>
<itemize>
<item>
Add the following lines to <tt>/etc/conf.modules</tt>:
<code>
&num; IrDA
alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty
</code>
<item>
Get the current IR Tools. I use version 0.9.2 at this time. Compile them proper. I installed <tt>irmanager</tt> and <tt>irattach</tt> in <tt>/usr/local/sbin</tt> (too lazy to make a RPM archive...).
<item>
I modified <file>/etc/irda/drivers</file> and set up this <file>/etc/rc.d/irda</file> start/stop script. Don't forget to add the line <tt>START_IRDA=yes</tt> to <tt>/etc/rc.config</tt> and to add a symlink like <tt>/etc/rc.d/rd3.d/S99irda</tt>.
<item>
Add a device file for the redirected IR device: <tt>mknod /dev/irnine c 161 0</tt> , see also <file>/proc/tty/drivers</file>.
<item>
Add a symlink <tt>/dev/pilot</tt> --&gt; <tt>/dev/irnine</tt> to make all programs happy (if you use the shell variable <tt>PILOTPORT=/dev/pilot</tt>).
</itemize>
<sect2>Starting IrDA - First Steps
<p>
Call <tt>/etc/rc.d/irda start</tt> and watch the console messages. <tt>ps</tt> should show <tt>irattach</tt> and <tt>irmanager</tt> running. Check <tt>/proc/net/irda</tt> to see what is there. <tt>ircomm</tt> will only be available and show reasonable stuff when an application accesses the irnine port (and loads <tt>ircomm_tty</tt> through <tt>kmod</tt>).
<p>
Start <tt>PilotManager</tt> or <tt>sync-plan</tt> and be happy :-) IR should run fine at 57600 bps.
See <url url="http://w3.muc.suse.de/links/palm.php3" name="SuSE Munich PalmIIIx pages">, too.
<sect2>Configuration Files
<p>
<file>/etc/irda/drivers</file>:
<code>
&num;! /bin/sh
&num;
&num; drivers
&num;
&num; Initialize and shutdown IrDA device drivers.
&num;
&num; This script should be invoked with two arguments. The first is the
&num; action to be taken, either "start", "stop", or "restart".
&num;
action=$1
device=$2
case "${action:?}" in
start)
/usr/local/sbin/irattach /dev/ttyS0 &num; The third serial port is an IrDA port
&num; irattach /dev/ttyS0 -d esi &num; Attach a ESI dongle to the first serial port
&num; irattach /dev/ttyS0 -d tekram
&num; insmod pc87108 &num; If your machine as a pc87108 FIR chipset
&num; modprobe uircc &num; Sharp UIRCC chipset
;;
stop)
killall irattach &num; ... or something. Currently not used
;;
restart)
/sbin/ifconfig ${device:?} down up
;;
esac
</code>
<file>/etc/rc.d/irda</file>
<code>
&num;! /bin/sh
&num; Copyright (c) 1995-1998 SuSE GmbH Nuernberg, Germany.
&num;
&num; Author: hm
&num;
&num; /sbin/init.d/irda
&num;
&num; and symbolic its link
&num;
&num; /sbin/rc&lt;skeleton&gt;
&num;
. /etc/rc.config
&num; Determine the base and follow a runlevel link name.
base=${0&num;&num;*/}
link=${base&num;*[SK][0-9][0-9]}
&num; Force execution if not called by a runlevel directory.
test $link = $base &amp;&amp; START_IRDA=yes
test "$START_IRDA" = yes || exit 0
&num; The echo return value for success (defined in /etc/rc.config).
return=$rc_done
case "$1" in
start)
echo -n "Starting service irda"
&num;&num; Start daemon with startproc(8). If this fails
&num;&num; the echo return value is set appropriate.
startproc /usr/local/sbin/irattach /dev/ttyS0 || return=$rc_failed
startproc /usr/local/sbin/irmanager -s1 -d0 || return=$rc_failed
echo -e "$return"
;;
stop)
echo -n "Shutting down service irda"
&num;&num; Stop daemon with killproc(8) and if this fails
&num;&num; set echo the echo return value.
killproc -TERM /usr/local/sbin/irmanager || return=$rc_failed
killproc -TERM /usr/local/sbin/irattach || return=$rc_failed
for i in ircomm_tty ircomm irtty irda ; do
rmmod $i;
done
echo -e "$return"
;;
restart)
&num;&num; If first returns OK call the second, if first or
&num;&num; second command fails, set echo return value.
$0 stop &amp;&amp; $0 start || return=$rc_failed
;;
reload)
&num;&num; Choose ONE of the following two cases:
&num;&num; First possibility: A few services accepts a signal
&num;&num; to reread the (changed) configuration.
&num;echo -n "Reload service foo"
&num;killproc -HUP /usr/sbin/foo || return=$rc_failed
&num;echo -e "$return"
&num;&num; Exclusive possibility: Some services must be stopped
&num;&num; and started to force a new load of the configuration.
&num;$0 stop &amp;&amp; $0 start || return=$rc_failed
;;
status)
echo -n "Checking for service foo: "
&num;&num; Check status with checkproc(8), if process is running
&num;&num; checkproc will return with exit status 0.
&num;checkproc /usr/sbin/foo &amp;&amp; echo OK || echo No process
;;
probe)
&num;&num; Optional: Probe for the necessity of a reload,
&num;&num; give out the argument which is required for a reload.
&num;test /etc/foo.conf -nt /var/run/foo.pid &amp;&amp; echo reload
;;
*)
echo "Usage: $0 {start|stop|status|restart|reload[|probe]}"
exit 1
;;
esac
&num; Inform the caller not only verbosely and set an exit status.
test "$return" = "$rc_done" || exit 1
exit 0
</code>
<sect1>Psion 5 Connection
<p>
Andrew Chadwick &lt;andrew.chadwick@symbian.com&gt; wrote: A nifty way to check that the baud rates for SIR are set up properly (if you have a Psion Series 5) is to point the S5 at your Linux box's IR window and try to beam a file. While the beamer dialog's on the screen, the S5 will try to make an IrDA connection (even when it claims it can't find another IR machine). You should be able to do a <tt>cat < /dev/ttyS3</tt> and if the serial parameters are right on both machines, you should see the words &dquot;Symbian EPOC&dquot; (machine ident) scroll past amidst the spew.
Fons Botman wrote: &dquot; Maybe someone with a Psion 5 would like to test this program. It emulates the protocol for the Psion 5 IR send and receive command for files on linux. You can now exchange files with simple commands. The transfer rate is 9.7 KBytes/sec on a 115KB SIR link for big files which is not bad methinks. It is beta, so be sure to backup the Psion first, I did get a soft reset once (no data loss). ;-)&dquot; I have put the source into Appendix C.
<sect1>Cellular Phone Connection
<p>
As far as I know some cellular phones use the IrCOMM standard, e.g. Ericsson SH888 and NOKIA 6110 (I'm not sure about the NOKIA 8110). Maybe other cellular phones use the IrOBEX standard (see the Palm III section for information about setting up a connection) or IrMC.
<sect2>Ericsson
<p>
To start a communication session with <file>/dev/irnine</file> (<file>/dev/ircomm</file>), for instance, say:
<code>
dip -t
&gt; port irnine
&gt; term
</code>
Probably you may use <tt>cu</tt> or <tt>xc</tt> instead of <tt>dip</tt>, too (<tt>cu -l /dev/irnine</tt> or <tt>xc -l /dev/irnine</tt>). There are also reports about some efforts with the Ericsson GF768 and IR Modem DI 27.
<p>
Benny Amorsen wrote: The SH888 emulates an IRDA-port when you connect it using the serial cable. Why someone would think up something weird like that is beyond me, but that is the way you get it to work in Windows. Not that I ever managed to make it work in Windows, though.
Ales Dryak has send this survey (looks like a Debian/GNU Linux distribution, please modify your configuration accordingly). Mobile Ericsson SH888 (<tt>ati1 = 980408 1035 PRGCXC125101</tt>):
<enum>
<item>
<tt>mknod /dev/ircomm c 60 64</tt>
<item>
<file>/etc/conf.modules</file>:
<code>
alias tty-ldisc-11 irtty
alias char-major-60 ircomm_tty
</code>
<item>
<file>/etc/irda/drivers</file>:
<tt>irattach /dev/ttyS0</tt> &num; (IrDA port in SIR mode)
<item>
running <tt>irmanager</tt>
<item>
<file>/etc/chatscripts/sh888</file>
<code>
<ABORT stuff>
&dquot;&dquot; \d\d\d\d\d\dATZE0
OK ATD<phone number to call)
CONNECT \d\c
</code>
<item>
<file>/etc/ppp/peers/sh888</file>
<code>
noauth
connect &dquot;/usr/sbin/chat -v -f /etc/chatscripts/sh888&dquot;
/dev/ircomm
115200
defaultroute
noipdefault
user &lt;your username&gt; &num; don't forget to add your password to chap secrets or chat script
</code>
</enum>
A few seconds (app. 30) after executing <tt>pppd call sh888</tt> I get connected to our Intranet/Internet having full IP connectivity (telnet, ftp, www, icmp tested). Futhermore I can connect to <file>/dev/ircomm</file> using <tt>minicom</tt> and play with AT command. Great! And looks stable!
<sect2>NOKIA
<p>
Carlos Vidal wrote: Correct me if I'm wrong, but it seems to me that Nokia telephones do not contain a genuine hardware modem, but something which is similar in principle to WinModems for PC. Whenever Nokia writes about modem communication, they use the name &dquot;Windows software modem&dquot; (or something similar). Which is actually backed up by the need to use special Nokia software for Windows (called Nokia Cellular Data Suite).
Joonas Lehtinen wrote: This is true with 61xx models. Models: 8810, 9000(i) and 9110 should work fine. (They have inbuilt modem). My Nokia 9000 reports IrCOMM with linux.
Some suggestion by Carlos Vidal carlos@tarkus.se : &dquot;I'm doing some tests trying to see how far can I get with my Nokia 6110 on Linux. I've just compiled gnokii-0.2.4 (gnokii is Nokia mobile phones connected via serial cable support for Linux and *BSD <url url="http://multivac.fatburen.org/gnokii/" name="http://multivac.fatburen.org/gnokii/"> , WH), but it doesn't work. As I have <it>Nokia Data Suite</it> I did the following connection:
Nokia 6110 &lt;-- Nokia Cable --&gt; PC/Linux &lt;-- Null-modem cable --&gt; PC/W95
In the PC/Linux I run the program <tt>snooper</tt> (by Jun-ichiro itojun Itoh &lt;itojun@mt.cs.keio.ac.jp&gt;, sorry couldn't find an URL maybe some other sniffer will do it also, e.g. <tt>sniffit</tt>, see also appendiy about serial sniffers, WH) with small modifications in order to configure the serial port correctly.
Normally, if <tt>snooper</tt> has the correct baud rate, the phone and the PC/W95 should communicate as if there was no snooper in between. This worked pretty well when I cracked the protocol of my Minolta camera. The problem here is that the phone doesn't answer or hangs after a while.
It seems that the timing is quite important during the initial phase of the communication. The log I obtain is:
<code>
0&gt;1: UUUUUUUUUUUUUUUUUUUUUUUU
line 0: LE *DTR *RTS ST SR CTS CD RI *DSR
line 1: LE *DTR *RTS ST SR CTS CD RI *DSR
0&gt;1: UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUU\x1e\x00\x0c\x02\x00\x09\x00\x01\x00\x0d\x00\x00\x02\x01@\x00P\x
06
1&gt;0: \x18\x00\x00\x00\xfc\x18\x00\x00\x00\x00\x00\x00\xc0\xf0
0&gt;1: \x1e\x00\x0c\x02\x00\x09\x00\x01\x00\x0d\x00\x00\x02\x01@\x00P\x06
1&gt;0: \x18\x00\x00\x00\x18\x00\x00\xc0\xf0\x18\x00\x00\x00\x00\x00\x00\xc0\xf0
0&gt;1: \x1e\x00\x0cd\x00\x06\x00\x01\x00\x10\x01`\x13\x13
1&gt;0: \x18\x00\x00\xf0\x00\x00\xfc
0&gt;1: \x1e\x00\x0cd\x00\x06\x00\x01\x00\x10\x01`\x13\x13
</code>
0 is the PC/95 and 1 is the phone. The communication starts with a stream of 'U' (0x55) and with DSR/DTR on. The phone answers with '0x18 0x00 ...'. This dialog continues for a while as if both were deaf and finally the phone crashes and the only way to reset it is to remove the batteries!
I guess that what happens is that the phone is trying to find the correct baud-rate and fails because of the delays introduced by <tt>snooper</tt>. This probably has to do with some IrDA protocol used with also with the infrared connection.&dquot;
Wessel de Roode &lt;J.W.deRoode@student.utwente.nl&gt; &dquot;I manged to get the Discovery IR hint bits (with my Palm Pilot):
<code>
Discover:
0:xxxxxxxx:81.01
01 IR_HINT_PNP 01 IR_HINT_TELEPHONY (IrMC ?)
80 IR_HINT_EXT
Device info query:
\006Device\012DeviceName
4e 6f 6b 69 61 20 36 31 30 30 Nokia 6100
</code>
I also managed to query the PNP device of the Nokia. It has one PNP device. It's PNPC100 which equalt a 9600 baud modem. I deleted the query, if somene can send me a hint to restore it. was somthing like <tt>IrDA:&lt;dunno&gt;:PNP:Comp&num;01</tt> The same query with <tt>IrDA:&lt;dunno&gt;:PNP:CompCnt</tt> gives the number of PNP-devices are available in the Nokia. Which is here only one.&dquot;
Maybe it is necessary to load the <tt>irlpt_server</tt> module for connections to a NOKIA.
<sect1> Digital Camera Connection
<p>
Markus Schill wrote: &dquot;Great that there are also other people who are interested in using the SONY DSC-F1 IR adapter under linux. Up to now I have only toyed around with the linux-irda software and the serial IR adapter from PuMa Technologies that came with the camera. This is the status. I am using linux 2.0.33 and the latest linux-irda... If I use:
<code>
insmod irda
insmod irtty
irattach /dev/cua0
</code>
the adapter starts talking to the camera. /var/log/messages says that SONY-DSC-F1 was found, but no service is started. (Please note, this probably doesn't apply to the 2.2.x kernel versions of Linux/IrDA, wh).
There are two programs for linux available that can be used for the communication with the camera via cable: (1) <tt>chotplay</tt> and (2) <tt>stillgrab</tt>. They both take a tty as commandline option, so I guess that they should work if the irtty layer of the protocol stack works correctly ... I have not looked at anything in the linux-irda code, yet!). I am not sure whether I understand the stack but shouldn't the irtty make the thing look like a normal tty? What service should be started. &dquot;
Dag Brattli wrote: &dquot;I'm not sure which application level protocol the camera uses, but it is possible that it implements the IrDA(TM) Infrared Transfer Picture Specification (IrTran-P). If you take a look at <url url="http://www.irda.org/standards/pubs/IrTran-P_10.pdf" name="http://www.irda.org/standards/pubs/IrTran-P_10.pdf">, you will see that it is a protocol which is implemented above IrCOMM (not IrTTY!). IrTTY is something we use just to be able to talk to the Linux serial driver. &dquot;
<sect1>Window$9x/NT and Linux/IrDA
<p>
<sect2>Introduction
<p>
Why this? Unfortunately Linux users are not always supported with the necessary hardware information. Sometimes it is possible to look at this informations in Window$95. Sometimes its even useful to connect the two. Linux could also provide occasional access point services to a Window95 laptop of a friend dropping by.
Where to get it from? At <url url="http://www.microsoft.com/windows95/info/irda.htm" name="http://www.microsoft.com/windows95/info/irda.htm"> you will find a support pack &dquot;Infrared Transfer 2.0&dquot;. It is a self-extracting archive <tt>W95IR.EXE</tt> with 331KB. Note: MicroSoft seems to change the location of this file (and others) at random.
Microsoft(tm) has <it>three</it> versions of IrDA support for Windows95. The version number can be found in the &dquot;Software&dquot; icon in the Control Panel and the file <file>infrared.inf</file>.
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 . 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 &dquot;miniport&dquot; 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.
MS website also used to contain a nice utility <tt>IrXfer</tt>, contained in the archive IRXFER.EXE, This is the <it>Infrared Transfer</it> 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 <tt>..\windows\inf\*.inf</tt> 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 on <url url="http://www.countersys.com" name="http://www.countersys.com"> claims to sell an IrDA solution for NT4.0 to support their JetBeam product, Microsoft refers to them for it.
<p>
AFAIK:
<itemize>
<item>Windows95 : use 2.0
<item>Windows98 : delivered with 3.0 and IrXfer (works with Linux/IrDA, IrOBEX?)
<item>WindowsNT4.0: no IrDA
<item>Windows2000 : 3.0(+?) http://www.microsoft.com/hwdev/infrared/
</itemize>
There are also some non M$ products available. Note: Some of them use proprietary infrared protocols:
<itemize>
<item>CounterPoint: QuickBeam 1.15 (works with Linux/IrDA, IrOBEX?)
<item>LapLink 7.5
<item>CarbonCopy 32 4.0
<item>pc ANYWHERE 7.5
<item>Puma Technology: TRANXIT pro 4.0
</itemize>
<sect2>Connection between Linux/IrDA and Window$95 IrDA(TM)
<p>
I suppose there are <it>four</it> ways to connect Linux/IrDA and Window$95:
1) A <it>network connection</it> between two PC's. If you have set up <it>Infrared Transfer 2.0</it>, you will find an IrDA(TM) network device in the &lt;<it>Network Device Section</it>&gt;. But I couldn't get a working connection yet.
Some information by Fons Botman: MS does not support PEER mode, which is strange, because it would fit their <it>workgroup</it> model. I have had success with IrLAN DIRECT mode when I removed the <tt>COMPUTER</tt> entry in the hints bits from the Linux side. Windows95 will recognise the Linux box as a lan access point and will try to install a driver for it but cannot find it. At this point I install the <it>network adapter</it> driver named <it>Microsoft IrDA Lan Driver</it> (you can also do this beforehand). You now should have a new active network driver which can be seen with <tt>WINIPCFG</tt>. To make it work with TCPIP I give the linux side an address using the redhat configuration tools and start a dhcp server on the linux box which hands out leases on the IrDA subnet. Sometimes I have to use <tt>WINIPCFG</tt> to explicitly ask for a lease. After this you can freely network between the two computers. Try to telnet or use explorer from Windows95 to linux.
Open points:
<p>
a. write a proper <file>/etc/sysconfig/network/irlan-up</file> script.
<p>
b. solve the direct/peer mode problem and the peer mode dhcp problem (zero, one, too many dhcp servers on the irda sublan), maybe borrow leases from a dhcpserver on the eth0 lan (dhcrelay).
<p>
c. Make the <it>Microsoft IrDA Lan Driver</it> install automatically, maybe this is a problem in the PnP configuration. This seemed to work better on Windows98.
<p>
d. I sometimes get a TCP configuration problem after disconnect, which can be solved by a Windows95 reboot. Maybe tune the dhcp configuration.
2) Maybe it is also possible to use the <it>IrOBEX protocol</it>. But I don't know which software to use and where to get it. I supposed the necessary software comes with a Palm III, but this seems not to be true.
3) Takahide Higuchi <htmlurl url = "mailto:thiguchi@pluto.dti.ne.jp" name = "&lt;thiguchi@pluto.dti.ne.jp&gt;"> provided <it>IrCOMM support</it>. From his page at <url url="http://www.pluto.dti.ne.jp/&tilde;thiguchi/irda/" name="http://www.pluto.dti.ne.jp/&tilde;thiguchi/irda/"> I have taken the following description (I have modified it at little): &dquot;With IrCOMM support you can send or receive short messages between a linux box and a terminal program on a win95 laptop! Please add this line to /etc/conf.modules:
<code>
alias char-major-60 ircomm_tty
</code>
Next, make a device file <tt>mknod /dev/irnine c 161 0</tt>. Now Linux/IrDA services can be started as usual with <tt>irattach /dev/ttyS? &amp;</tt>. <file>/dev/irnine</file> can be used as a serial device. <tt>ircomm</tt> and <tt>ircomm_tty</tt> modules will be loaded automatically by <tt>kerneld/kmod</tt> when a program uses <file>/dev/irnine</file>. NOTE: I think &dquot;setserial&dquot; utility will not work on <file>/dev/irnine</file>. Tips:
<itemize>
<item>To accept login via IrCOMM, use this as a root: First, please enable IrDA and IrCOMM. Then edit <file>/etc/inittab</file> and add a line like this:
<code>
T1:23:respawn:/sbin/getty -L -w irnine 38400 vt100
</code>
and do this as a root:
<tt>init q</tt>. And <tt>init</tt> will start waiting for incoming IrCOMM connection. You will see your favorite Linux's login prompt from terminal emulator on Win95!
<item>If you try <tt>pppd</tt>, please consider the -crtscts option to disable flow-control. I implemented some flow-control emulation but it is not tested.
<item>Now my patch reports what kind of features is needed by the peer infrared device. Messages like this will be written in syslog:
<verb>
Sep 4 10:01:02 monolith kernel: parse_control:instruction(0x12)
Sep 4 10:01:02 monolith kernel: data:03
</verb>
<item>
I especially want to know what message SH888 (or other infrared devices except for win95 PC) says. So please mail me your syslog generated during IrCOMM connection! If you have a copy of the IrCOMM specification written by IrDA(TM), please see page 34 or 38, and you will know what these messages mean.&dquot;
</itemize>
4) From Fons Botman: IrLPT works fine. Make Linux the IrLPT server, and in Windows95 configure a printer to use the virtual LPT port defined when you installed MS-IrDA. Windows95 periodically sends some short sequence to the printer, I still have to figure out what that is.
<sect1>Linux to Linux Connection
<p>
<sect2>Connection Methods
<p>
There should be <it>three</it> ways to get two Linux machines connected via Linux/IrDA.
<itemize>
<item>
Dag Brattli wrote about the <it>IrOBEX support</it>: &dquot;The awakened reader may wonder what prevents the beaming of files from Linux to Linux? Well, nothing!! (but I haven't tried that yet). This means that we now have a &dquot;simple&dquot; way of beaming files between Linux laptops. I think that this may be the &dquot;killer app&dquot; we all have been waiting for!&dquot; Try to &dquot;<tt>load_misc irobex</tt> at both ends, and then try <tt>iroabex_app get</tt> on one of the machines and <tt>irobex put &lt;file&gt;</tt> on the other.&dquot;.
<item>
Via <it>Linux/IrDA network</it> connection. I suppose you have to load the module <tt>irlan_client</tt> at one machine and <tt>irlan_server</tt> at the other one.
<item>
With <it>IrCOMM</it> support, in other words over a serial line, which could mean <tt>minicom</tt>, <tt>pppd</tt>, etc. If you want just now to use IrCOMM between Linux boxes, please add this line to <file>/etc/conf.modules</file> of _one_ box:
<code>
&num; set ircomm protocol engine to client-only mode
options ircomm ircomm_cs=1
</code>
Note: Don't add it to both boxes, or they cannot accept incoming connection each other! But since 2.2.7 there's no need to add <tt>options ircomm ircomm_cs=1</tt> to <file>/etc/conf.modules</file> anymore. Please remove it if you are using it.
</itemize>
<sect2>Compression
<p>
Please note this feature is still quite experimental! Dag Brattli wrote: &dquot;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 &lt;-&gt; Linux) you will have to insert the <tt>irda_deflate</tt> module some time before you actually make the connection. I do it before <tt>irattach</tt>.
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 <file>ftp://ds.internic.net/rfc/rfc1950.txt</file> (<it>zlib format</it>), <file>rfc1951.txt</file> (<it>deflate format</it>) and <file>rfc1952.txt</file> (<it>gzip format</it>).
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, ...&dquot;
<p>
<sect1>Multiple Instances
<p>
Dag Brattli wrote: &dquot;The IrLAP layer has been enhanced to allow more than one instance (so I can use IrLAN on my built-in ir-port, and communicate with the Pilot over the IrDA dongle at the same time) ... So how do you make two Linux/IrDA connections? Well, you just fire up <tt>irattach</tt> for each of the IR ports you have like this:
<code>
irattach /dev/ttyS0 & (my ESI dongle)
irattach /dev/ttyS2 & (my builtin IrDA port)
insmod irlan_client
insmod irobex
</code>
They will not see each other if you run them on the same machine, since they will initiate discovery exactly at the same time. You should however be able to use them against two other laptops. I can run a dongle, builtin IrDA port and a IrDA pcmcia card at the same time with three other IrDA devices without any problems.
<p>
You should notice that if the devices can interfere with each other then it might be difficult to obtain a connection, since a device is not allowed to transmit if the media is busy. I sometimes have to put a book between them.&dquot;
<sect1>Connection to Docking Station
<p>
Dag Brattli: &dquot;Connection to the Tekram IRDocking IR-660 <url url="http://www.tekram.com/Hot_Products.asp?Product=IR-660" name="http://www.tekram.com/Hot_Products.asp?Product=IR-660"> . This device is a docking station with LAN access, printer, mouse and keyboard. You can also use them at the same time as the internal mouse and keyboard! Just fire up <tt>gpm -t ps2 /dev/irkbd</tt> and the laptop will make a keyboard/mouse connection to the IR-660. Now I just have to make <tt>gpm</tt> read both <file>/dev/psaux</file> and <file>/dev/irkbd</file>, and then make X11 read <file>/dev/gpmdata</file>, and I should have the thing configured!
<p>
... one problem: <tt>gpm</tt> can handle <it>multiple mice</it>, but Linux cannot handle <it>multiple different keyboards</it>. So if you have one norwegian keyboard and one <it>remote</it> US keyboard like I have, then things will be a little bit confusing. I got a hint from Alan Cox about a project that is implementing <it>real</it> support for multiple keyboards, so I'll check that out.
<p>
... OK, I sort of worked it out. By using TIOCSTI on <file>/dev/console</file>, you can insert scancodes directly into the tty queue. This can be a problem for virtual consoles that expect to receive some translated and cooked keycodes, but X happens to like raw scancodes, so this will work quite nice when using X but not for other virtual consoles. Anyway this is good enough for me, so I will not use a lot of time converting the scancodes to keycodes and index them with some keymap just to make it work with text only virtual consoles. As I see it the irkbd driver has now been successfully been ported to user-space :-)
<p>
... the Tekram IR-660 device can, in addition to attach a keyboard and mouse, also print using IrTTP (it can print using IrLPT, but that is not so funny since it requires exclusive use of IrLMP, and you don't wan't to stop the network, mouse and keyboard just to print a document). I'll try and see if I can get IrTTP printing working using a fifo as well.
... Tekram has added a control channel in addition to the data channel so that you can get some status information about what is going on. The name of their own protocol is P1248. It's published through the &dquot;P1248&dquot; class and &dquot;IrDA:TinyTP:LsapSel&dquot; LM-IAS entry, so you can try to find it.
... Canon is using the P1248 protocol, and their printer monitor program BrintBuddy2 (Japanese version) is using this protocol now. I don't know what they use for the data channel. Maybe they support TinyTP directly in addition to the other methods. You can try and look up the &dquot;IrLPT&dquot; class with the &dquot;IrDA:TinyTP:LsapSel&dquot; in the LM-IAS and see if you can find it.&dquot;
<sect1>Connection to Keyboard
<p>
The Linux/IrDA keyboard driver is now in user-space. Please see chapter Connection to Docking Station above.
Lichen Wang: &dquot;The so called IrDA-D standard is designed to transfer Data. It is not suitable for IR Keyboard. IrDA-D is what Dag ported to Linux OS and what MS ported to Windows OS.
The so called IrDA-C (Control) is designed for Keyboard, Joy-stick, etc. I am not aware that there is any product in the market that is using it yet.
IrDA-D cannot talk to IrDA-C. IrDA-C cannot talk to IrDA-D either. Both the <it>physical encoding/decoding</it> and the <it>software protocol</it> are very different.
It is possible to implement both IrDA-D and IrDA-C in the same device. Sharp says that IrDA-D and IrDA-C can coexist -- as long as both of them are not used at the same time in the same IR space. This sounds rather funny to me. According to this definition, anything can co-exist with anything as long as you do not destroy the universe permanently in the process ;-)
Seriously, what SHARP says is that they can tailor the IrDA-D so that there are some unused time between the negotiated maximum turnaround time and the actual transmission. They then squeeze the IrDA-C frames in those unused time. The IrDA-D Primary and IrDA-C Master must be implemented in the same device. The keyboards will work, but mice and joysticks may be sluggish at times.&dquot;
<sect1>Connection via Serial Cable
<p>
For some reasons it may be useful to connect via serial cable instead of using a real infrared link. Bjorn Hanson wrote: &dquot;Using a cable, I managed to get a PPP connection through my Ericsson SH888. I did the following (maybe some steps are <it>wrong</it> but they worked for me :-)
<itemize>
<item>added <tt>alias tty-ldisc-11 irtty</tt> to <tt>/etc/conf.modules</tt>
<item>edited /etc/irda/drivers to irattach <tt>/dev/ttyS0</tt>
<item>manually inserted the irda and irtty modules using <tt>insmod</tt>
<item>started <tt>irmanager -d1</tt>
<item>run <tt>kppp</tt> using <tt>/dev/irnine</tt> (through symlink <tt>/dev/modem</tt>)
<item>executed <tt>stty &lt; /dev/irnine</tt>
<item><tt>ping thehost</tt>
<item><tt>ifconfig irda0 down</tt>
</itemize>
Everything worked fine for ping and ssh (doing ls -l a couple of times) but the computer hang when I tried to mail (Netscape) this through that PPP. After reboot I tried both Netscape and lynx. Both were able to establish contact but none got any data.&dquot;
<p>
Another way by Claudiu Costin &lt;claudiuc@calderon.pcnet.ro&gt;:
<itemize>
<item>
Linux 2.2.5 with IrDA compiled as modules
<item>
Because irattach don't make kernel to load automatically IrDA stack, let's type <tt>modprobe actisys</tt<
<item>
Now, <tt>irattach /dev/ttyS1 -d actisys</tt> where COM2 is used for null link
<item>
<tt>irmanager</tt>
<item>
<tt>ping &lt;address&gt;</tt> work very good!
</itemize>
This has to be done for both machines.
<p>
Please note this is not the recommended stuff to connect two machines. Use PPP instead. Though I cannot see how this approach is useful I have included it beause it was asked sometimes in the mailing list.
<sect1>Peer-to-Peer Mode / Direct Mode
<p>
IrCOMM and IrLAN work in both modes, but currently I don't have further information about the differences between these modes and how to set them up.
<p>
<sect>Hardware Supported by Linux/IrDA
<p>
<sect1>Obtaining Information about the Infrared Port in Laptops
<p>
To get the IrDA port of your laptop working with Linux/IrDA you may use StandardInfraRed (SIR) or FastInfraRed (FIR).
<sect2>SIR
<p>
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 <file>serial</file> module. If infrared support is enabled in the BIOS, for most laptops you will get a kernel message like:
<code>
Serial driver version 4.25 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A &num;first serial port /dev/ttyS0
ttyS01 at 0x3000 (irq = 10) is a 16550A &num;e.g. infrared port
ttyS02 at 0x0300 (irq = 3) is a 16550A &num;e.g. PCMCIA modem port
</code>
<sect2>FIR
<p>
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:
<enum>
<item>Read the <it>specification</it> of the machine, though it is very rare that you will find enough and reliable information there.
<item>Try to find out wether the FIR chip is a <it>PCI</it> device. Do a <tt>cat /proc/pci</tt> . The according files for 2.2.x kernels are in <file>/proc/bus/pci</file> . Though often the PCI information is incomplete. You may find the latest information about PCI devices and vendor numbers in the kernel documentation usually in <file>/usr/src/linux/Documentation</file> or at the page of Craig Hart <url url="http://members.hyperlink.net.au/&tilde;chart" name="http://members.hyperlink.net.au/&tilde;chart"> . From kernel 2.1.82 on, you may use <tt>lspci</tt> from the <tt>pci-utils</tt> package, too.
<item>Use the <it>DOS tool</it> <tt>CTPCI330.EXE</tt> provided in ZIP format by the German computer magazine CT <url url="ftp://www.heise.de/pub/ct/ctsi/ctpci330.zip" name="ftp://www.heise.de/pub/ct/ctsi/ctpci330.zip"> . The information provided by this program is sometimes better than that provided by the Linux tools.
<item>Try to get information about <it>Plug-and-Play (PnP)</it> devices. Though I didn't use them for this purpose yet, the <tt>isapnp</tt> tools, could be useful. At the page from Craig Hart I found this PNP IDs:
<code>
IBM0002 IBM Thinkpad Infrared Port
IBM0034 IBM Thinkpad Infrared Port
PNP0510 Generic IRDA-compatible device
PNP8294 IrDA Infrared NDIS driver (Microsoft-supplied)
PNP8389 Peer IrLAN infrared driver (Microsoft-supplied)
</code>
<item>If you are running Linux-2.3.x and PCMCIA-CS-3.1.x, turn on the PnP BIOS in PCMCIA-CS. Then, do a <tt>lspnp -v</tt> (from Thomas Davis).
<item>If you have installed the <it>Linux/IrDA software</it> load the FIR modules and watch the output of <tt>dmesg</tt>, whether FIR is detected or not.
<item>Another way how to figure it out explained by Thomas Davis (modified by WH): &dquot;Dig through the FTP site of the vendor, find the <it>Windows9x FIR drivers</it>, and they have (for a SMC chip):
<code>
-rw-rw-r-- 1 ratbert ratbert 743 Apr 3 1997 smcirlap.inf
-rw-rw-r-- 1 ratbert ratbert 17021 Mar 24 1997 smcirlap.vxd
-rw-rw-r-- 1 ratbert ratbert 1903 Jul 18 1997 smcser.inf
-rw-rw-r-- 1 ratbert ratbert 31350 Jun 7 1997 smcser.vxd
</code>
If in doubt, always look for the .inf/.vxd drivers for Windows95. Windows95 doesn't ship with _ANY_ FIR drivers. (they are all third party, mostly from Counterpoint, who was assimilated by ESI).&dquot
<item>Also Thomas Davis found a package of small <it>DOS utilities made by SMC</it>. Look at <url url="http://www.smsc.com/ftppub/chips/appnote/ir_utils.zip" name="http://www.smsc.com/ftppub/chips/appnote/ir_utils.zip"> . The package contains <tt>FINDCHIP.EXE</tt>. And includes a <tt>FIRSETUP.EXE</tt> utility that is supposed to be able to set all values except the chip address. Furthermore it contains <tt>BIOSDUMP.EXE</tt>, which produces this output:
<p>
Example 1 (from a COMPAQ Armada 1592DT)
<code>
In current devNode:
Size = 78
Handle = 14
ID = 0x1105D041 = 'PNP0511' -- Generic IrDA SIR
Types: Base = 0x07, Sub = 0x00, Interface = 0x02
Comm. Device, RS-232, 16550-compatible
Attribute = 0x80
CAN be disabled
CAN be configured
BOTH Static & Dynamic configuration
Allocated Resource Descriptor Block TAG's:
TAG=0x47, Length=7 I/O Tag, 16-bit Decode
Min=0x03E8, Max=0x03E8
Align=0x00, Range=0x08
TAG=0x22, Length=2 IRQ Tag, Mask=0x0010
TAG=0x79, Length=1 END Tag, Data=0x2F
</code>
Result 1:
<p>
<tt>Irq Tag, Mask (bit mapped - ) = 0x0010 = 0000 0000 0000 0001 0000</tt> so, it's IRQ 4. (start at 0, count up ..), so this is a SIR only device, at IRQ=4, IO=x03e8.
<p>
<p>
Example 2 (from an unknown machine)
<code>
In current devNode:
Size = 529
Handle = 14
ID = 0x10F0A34D = 'SMCF010' -- SMC IrCC
Types: Base = 0x07, Sub = 0x00, Interface = 0x02
Comm. Device, RS-232, 16550-compatible
Attribute = 0x80
CAN be disabled
CAN be configured
BOTH Static & Dynamic configuration
Allocated Resource Descriptor Block TAG's:
TAG=0x47, Length=7 I/O Tag, 16-bit Decode
Min=0x02F8, Max=0x02F8
Align=0x00, Range=0x08
TAG=0x22, Length=2 IRQ Tag, Mask=0x0008
TAG=0x47, Length=7 I/O Tag, 16-bit Decode
Min=0x02E8, Max=0x02E8
Align=0x00, Range=0x08
TAG=0x2A, Length=2 DMA Tag, Mask=0x02, Info=0x08
TAG=0x79, Length=1 END Tag, Data=0x00
</code>
Result 2:
<p>
a) it's a SMC IrCC chip
<p>
b) one portion is at 0x02f8, has an io-extent of 8 bytes; irq = 3
<p>
c) another portion is at 0x02e8, io-extent of 8 bytes; dma = 1 (0x02 =0000 0010)
<p>
<p>
Thomas Davis has placed some device information at <url url="http://www.jps.net/tadavis/irda/devids.txt" name="http://www.jps.net/tadavis/irda/devids.txt"> .
<p>
WARNING: The package is not intended for the end user, and some of the utilities could be harmful. The only documentation in the package is in M$ Word format. Linux users may read this with <tt>catdoc</tt>, available at <url url="http://www.fe.msk.ru/&tilde;vitus/catdoc/" name="http://www.fe.msk.ru/&tilde;vitus/catdoc/"> .
<item>Use the <it>Device Manager</it> of Windows9x/NT or <tt>WINMSD</tt> (Windows NT Diagnostics) in Windows NT 4.0, <tt>WINMSD</tt> is quite useful, and a bit more informative than Windows9x's Device Manager.
<item>You may also use the <it>hardware surveys</it> mentioned below.
<item>And as a last ressort, you may even <it>open the laptop</it> and look at the writings at the chipsets itselfs. Here is an probably incomplete list of manufacturers: Chrystal, Hewlett Packard (HP, chipsets are marked HSDL), Hitachi, IBM, National Semi Conductor (NSC), NEC, Philips, Sharp, Standard Micro Systems Corporation (SMC/SMSC), Texas Instruments (TI), VLSI, Winbond. As an example of application circuits the HSDL-7001 (from a HP brochure, modified by WH):
<code>
LEDs Encode/Decode SIR/FIR
HSDL-1001 HSDL-7001 UART 16550/
MicroController
______ ______________ ____________
| | | | | |
(|| TXD|<---|IR_TXD TXD|<---|SOUT |
| | | | | |
| | | RCV|--->|SIN |
| | | | | |
(|| RCV|--->|IR_RCV 16XCLK|<---|BAUDOUT |
| | | NRST|-+ | |
------ -------------- | ------------
V
</code>
</enum>
<sect1>Big Endian
<p>
Though the source is build to work with big endian machines, I didn't get any reports about actually using it. It would be interesting if it's actually working or not. You will probably need an IrDA dongle or something to test it.
<it>i386</it> and <it>alpha</it> are little endian, <it>arm</it> can choose (but the NetWinder has been wired as a little endian machine). <it>m68k</it>, <it>sparc</it> and <it>ppc</it> are big-endian! <it>mips</it> can choose I think. If unsure, look in <file>/usr/src/linux/asm/byteorder.h</file> and check if it includes <tt>&lt;linux/byteorder/big_endian.h&gt;</tt> or <tt>&lt;linux/byteorder/little_endian.h&gt;</tt> .
<sect1>SMP
<p>
Dag Brattli: &quot;The problem ... has not been analyzed yet. It may be unsafe, and it may work pretty well. All upstream traffic should be safe (bh's), but downstream traffic _may_ be dangerous. I really don't know. ... All list operations <file>irqueue.c</file> in Linux-IrDA is currently SMP safe!&dquot;. Please check the source code for the current status.
<sect1>Hardware Surveys
<p>
There are some surveys about Linux and infrared capable devices in the WWW:
<itemize>
<item>The Linux/IrDA Project - Hardware Survey at <url url="http://www.cs.uit.no/linux-irda/hardware.html" name="http://www.cs.uit.no/linux-irda/hardware.html">
<item>
Takahide Higuchi at <url url="http://www.pluto.dti.ne.jp/&tilde;thiguchi/ir/product.html" name="http://www.pluto.dti.ne.jp/&tilde;thiguchi/ir/product.html">.This page is in japanese.
<item>
I have also set up a hardware survey at <url url="http://www.snafu.de/&tilde;wehe/index_li.html" name="http://www.snafu.de/&tilde;wehe/index_li.html">. This list also contains information about infrared capable devices which are not mentioned here (mice, printers, remote control, transceivers, etc.).
<p>
To make this hardware survey list more valuable it is necessary to collect more information about the infrared devices in different hardware. You can help by sending me a short e-mail containing the exact name of the hardware you have and which type of infrared controller is used.
<p>
Please let me also know how well Linux/IrDA worked, at which tty, port and interrupt it works and the corresponding infrared device (e.g. printer, cellular phone) you use.
You can also help by contributing detailed technological information about some infrared devices, which is necessary to develope an according driver for Linux.
</itemize>
<sect>Graphical User Interface (GUI)
<p>
Currently there are two graphical user interfaces for Linux/IrDA under development:
<sect1>GNOBEX
<p>
A GNOME application developed by Dag Brattli <url url="http://www.cs.uit.no/linux-irda/irda.html" name="http://www.cs.uit.no/linux-irda/irda.html"> with support for drag'n drop from the GNOME file manager <tt>gmc</tt>. It will also show the progress of the file transfer and give some better error messages when something goes wrong. The GUI isn't finished yet, but if you want to try the GUI you will need the Perl-GTK+ module.
Annotations about CORBA by Dag Brattli: I have just had the first successful test running ORBit/CORBA over IrDA sockets/IrTTP! ORBit is btw. the GNU CORBA implementation used by the GNOME project. The goal is to make it possible for GNOME applications to work between your laptop and your stationary PC without having to first set up a TCP/IP link. Applications on the laptop can then make use of CORBA exported services on your stationary machine.
IrDA (as a one hop technology) fits nicely into the network hierarchy since ORBit will now choose which <it>profile</it> to use in this order:
<enum>
<item>Same process (same address space), Some short circut mechanism is used that I don't know much about. It should however be nearly as fast as a procedure call.
<item>Same machine (different address space), UNIX domain sockets are used
<item>One hop away, IrDA is used (if IrDA is available and a ORBit/CORBA capable device is discovered)
<item>Multiple hops away (if all other methods fails). IIOP, TCP/IP will be used.
</enum>
I use my laptop and a NetWinder for testing. The machines are connected by both Ethernet and IrDA. It's really nice to start a CORBA session and see that the IrDA does discovery, IAS-query, and connects if a CORBA capable device is discovered. If somethings goes wrong, IIOP (TCP/IP) will automagically be used instead. When the transaction if finished, the link goes down again.&dquot;
There is also OBEX support to the gnome-calendar application <tt>gncal</tt>. Just click on an event and beam it to your Palm Pilot! Still needs to do some cleanup, and support for beaming the other way as well.
<sect1>KDE
<p>
A KDE application developed by Thomas Davis. Look at his page <url url="http://www.jps.net/tadavis/irda" name="http://www.jps.net/tadavis/irda">.
<p>
Here's your chance to contribute! Both GUI's need some icons. Any icons need to be:
<itemize>
<item>each of them should display a printer, PC, PDA, LAN connection, etc.
<item>the format is not really important, but PNG is what will be used in the end
<item>set size (48x48 pixels seems to be a common size, I think)
<item>large and mini (ask about size for that; mini's are for docking and such)
<item>16 colors
<item>free for use
<item>please, don't blatently copy MS icons!
</itemize>
Please contact the developers.
<sect>Power Saving
<p>
In the specifications of my HP OmniBook 800 it is recommended to turn off the IR port, if it is not in use, because it may consume up to 10 percent of the battery time.
If necessary, you may also try to disable the <tt>Fast RRs</tt> feature in the IrDA section of the kernel. This option will give you much better latencies but will consume more power.
<p>
<sect>Beyond IrDA
<p>
<sect1>Extending Transmission Distance
<p>
According to the IrDA specification the range is up to 1 meter. From the &dquot;IrDA Data Link Design Guide&dquot p. 20 by Hewlett-Packard <url url="http://www.hp.com/go/ir" name="http://www.hp.com/go/ir"> : &dquot; 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.&dquot;
Andreas Butz wrote: &dquot;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.&dquot;. Please see the mailing list archive for details of the discussion.
Sent by Marc Bury &lt;Marc.Bury@NETGEM.com&gt; &dquot; .. just heard about some Philips new scheme for remote controls: they call it <it>IRDA - Control</it>. This is supposed to be bi-directional, 75 kbps data rate, multiple simultaneous devices (up to 8) and with a minimum 6 meter range!&dquot; More information at <url url="http://www.irda.org/" name=" http://www.irda.org/"> .
The german magazine ELEKTOR issued a guide to build a <it>Long Distance IrDA Dongle</it> (20m, RS232, IrDA 1.0), ELEKTOR 5/97 p. <url url="http://www.elektor.de" name="http://www.elektor.de"> .
&lt;tzeruch@ceddec.com&gt;: 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 ...
Someone tried it with a Palm III upgrade board <url url="http://home.t-online.de/home/PSPilot/ppppiii.htm" name=" http://home.t-online.de/home/PSPilot/ppppiii.htm "> .
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: &dquot; Who ever it was wanting to do long distance with IrDA, we've tried this before. The best approaches are:
<itemize>
<item>
<it>wavelan</it> - buy the cards but not the antennas you can make your own with equaly good gain as the $9000 type they sell here.
<item>
<it>microwave</it> - you can pick up X-band doppler radar modules, tune them slightly apart and use the your local TX as the LO for the incomming RX, the whole thing behaves like ethernet and you can hook it onto an AUI port, this may now be illegal.
<item>
<it>ir</it> - Many people sell kits which transmit video over Ir, they come complete with the large fresnel lense you need, they manage about 4MHz b/w over 100m.
<item>
<it>laser diodes</it> - when we looked at these they were a pain, I think elantec make decent drivers but modulating them was a big pain, Steve Carcia had a series on articles on modulating He-Ne lasers but be careful they have lots of volts in them that want to get out and kill you.
</itemize>
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.&dquot;
<sect1>Upcoming Standards (Bluetooth and IrDA)
<p>
&dquot;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.&dquot;
<sect>Troubleshooting, Mailing List
<p>
<sect1>General Information
<p>
If you encounter problems. Try the following:
<itemize>
<item>Read the FAQ section below.
<item>Look at <file>/var/log/messages</file> and/or <file>/var/log/kern</file>.
<item>Do a <tt>dmesg</tt>.
<item>Look at the different files in <file>/proc/irda</file>.
<item>Look at the <it>mailing list archivs</it>, whether your problem is already known. Since August 1999 it the archiv is located at <url url="http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda" name="Linux-IrDA mailing list archiv">. All mails before are archived at <url url="http://www.ita.chalmers.se/&tilde;svinto/hypermail/irda/" name="http://www.ita.chalmers.se/&tilde;svinto/hypermail/irda/"> .
<item>As a last ressort ask in the <it>Linux-IrDA mailing list</it>. You may subscribe at <url url="http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda" name="Linux-IrDA mailing list"> . You are welcome to use this mailing list for posting questions, answers, bug-reports, patches, suggestions and comments. It would be much easier to help you if you provide some information. Please include:
<code>
uname -a
cat /proc/net/irda/irlan
cat /proc/net/irda/irlap
irdadump
</code>
<item>
There is also a new IrDA related mailing-list. This list is driven by Dag Brattli and the Pasta project, and is intended for discussion about IrDA protcols, setups, configurations, devices, and problems that users and developers might have and want to discuss with others. So this is ment to be a much more general list than the Linux-IrDA list. You can find the list at: <url url="http://www.pasta.cs.uit.no/mailman/listinfo/irda/" name="Linux-IrDA list">. Archives can be found at: <url url="http://www.pasta.cs.uit.no/pipermail/irda" name="Linux-IrDA list archiv"> . From Dag Brattlis announcement: Though &dquot;IrDA is already running a public (but web-only) mailing-list, and I hope it's OK that we run these two lists in parallel. I'm not trying to have any competition ;-) but my intentions are purely to make it easier for users and developers to publicly discuss IrDA related (and non-Linux specific) issues with each other. I have named the list IrDA &lt;irda@pasta.cs.uit.no&gt; since it's about IrDA, so I hope this is OK for IrDA. If you visit the list, you will see that I have choosen to call it: <it>IrDA -- The Pasta Projects Unofficial IrDA Forum</it>.
</itemize>
<sect1>Troubleshooting Techniques
<p>
Although I'm not much of a hacker I collected some tricks to track errors or bugs in the Linux/IrDA software.
<itemize>
<item>You may set the debug level in <file>/proc/sys/net/irda/debug</file> to 1, 2, 3, 4.
<item>
Use the files in <file>/proc/sys/net/irda</file> to try different parameters like <tt>echo 0 &gt; /proc/sys/net/irda/discovery</tt>.
The <file>/proc/*/irda</file> files are:
<code>
root@duckman:&tilde;&num; ls /proc/sys/net/irda/* /proc/net/irda/*
/proc/net/irda/discovery /proc/net/irda/irlmp /proc/sys/net/irda/devname
/proc/net/irda/irda_device /proc/net/irda/irttp /proc/sys/net/irda/discovery
/proc/net/irda/irias /proc/sys/net/irda/compression
/proc/net/irda/irlap /proc/sys/net/irda/debug
</code>
<item>It is also possible to debug the code. But I don't know how to do this. If you want to use SKB debug code, you may edit <file>irda.h</file> and change <tt>/include/linux/skbuff.h</tt> (see revision history of snapshot 10-2-98).
<item>For problems with the <tt>irda</tt> module a utility from the <it>modules package</it> <tt>kdstat</tt> might be helpful. But I was not able to try this.
<item>
&dquot;You can now alter the number of discovery packets used (1, 6, 8 or 16) and the timeout between sending them (2-8 * 10 ms) in <file>/proc/sys/net/irda</file>. Please experiment if you have problems discovering your device. My Palm III seems to like 16 <tt>discovery_slots</tt> and 8 (*10 ms) for <tt>slot_timeout</tt>. &dquot; ... &dquot;The absolute minimum for reliable discovery of the IR-610 seems to be 9.&dquot;
<p>
Another statement: ... the Palm III does not like 8 discovery frames in a row, but 6 is OK. With 8 it will answer 1 out of 6-10 times, with 6 it answers every time. I really don't know if this is a problem with Linux-IrDA or the Palm III. One solution to this problem, is to cycle though some different discovery methods for each discovery like this:
<p>
Disocvery 1: send 8 xid frames with 80 ms separation
<p>
If answer, keep the same config, if no answer, try next config
<p>
Discovery 2: send 6 xid frames with 80 ms separation
<p>
Discovery 3: send 8 xid frames with 90 ms separation
<p>
Discovery 4: send 6 xid frames with 90 ms separation
<p>
Discovery 5. Go back to 1.
<p>
or some other pattern and maybe more combinations.
<p>
Maybe this is sometimes implemented, so it would be enabled if <tt>/proc/sys/net/irda/discovery_slots</tt> is set to <tt>0</tt> .
<item>
If anybody gets a kernel Oops, then please feed it to the <file>../linux/scripts/ksymoops/ksymoops</file> program, so that we can find out where it went wrong. Just cut out the Oops lines from the syslog, save them to a file, and then run <tt>ksymoops &lt;file&gt;</tt>
<item>
Dag Brattli wrote: I found out that the cs4232 sound card was giving me several hundred interrupts per second! I removed the sound stuff from my kernel, and the machine is now generally about 4 times faster!
Linux/IrDA may get problems if you are running the esound server (<tt>esd</tt>) on your machine. Both my machines, a 166Mhz Pentium laptop and a 200Mhz Pentium Pro cannot run Linux/IrDA when esd is running. The reason is that esd makes the soundcard give interrups over 300 times/second which makes the serial driver overrun when receiving. This is because the serial driver now uses slow interrupts in Linux-2.2 (everything is slow interrupts in 2.2), so the interrupt-handler schedules on its way out. The good thing about slow interrupts is that packets are delivered much faster, since you don't need to wait for the next timer-tick. The only exception for this is the pc87108 driver which works fine since it uses DMA and will only give a couple of interrupts per packet.
<item>
There are also some userspace tools <tt>irdaping</tt> and <tt>irdadump</tt> to check Linux/IrDA connections.
<item>
AFAIK it is possible to use IrCOMM either with an infrared device or via serial cable. Maybe this give some debugging possibilities, too.
<item>
1) You may edit <file>/etc/conf.modules</file>, adding the following lines:
<code>
option irda irda_debug=3
option irlpt_client_debug=3 irlpt_common_debug=3
</code>
<p>
2) Make sure the irda modules have been totally removed.
<p>
3) Edit <file>/etc/syslog.conf</file>, adding the following lines:
<code>
*/* -/var/log/all
</code>
<p>
4) Do <tt>killall -1 syslogd</tt> .
<p>
5) Print, or do whatever causes problems with <tt>irlpt</tt> .
<p>
6) Check all the files in <file>/var/log/</file> .
</itemize>
<p>
<sect>IrDA Network Neighborhood
<p>
<sect1>Laptop-Printer-PDA
<p>
You can take a little peek at <url url="http://www.cs.uit.no/linux-irda/snapshots/ircc.gif" name="http://www.cs.uit.no/linux-irda/snapshots/ircc.gif"> 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.
<sect1>Bridging/Routing
<p>
James wrote: &dquot; ... there is a much better way of doing the briding which is routing. This is entirely user land and requires no kernel patches.
It's in two parts (you may only need one your milage may vary...) the first called <tt>irdaipcfg</tt> does the following:
1) First part is executed as <tt>irdaipcfg ifeth ifirlan</tt> 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 <file>/var/run/host.ifirlan</file> so you can easily undo all of this from a script.
2) Second part is executed as <tt>gratarp ifirlan</tt>. Sometimes the gratuatous arp seems to get lost in the pipe work, <tt>gratarp</tt> deamonizes 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 <file>/etc/irda/network</file> by <tt>irmanager</tt>. <file>/etc/irda/network</file> then runs <tt>irdaipcfg eth0 irlanx</tt> and this does the routing.
From /etc/irda/network
<code>
&dquot;start&dquot;)
echo 1 &gt;/proc/sys/net/ipv4/conf/all/forwarding
./ifup ifcfg-${device}
/sbin/irdaipcfg ${localnet} ${device}
;;
&dquot;stop&dquot;)
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
;;
</code>
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 <tt>gratarp</tt> from the <file>/etc/irda/network</file>, and I can wander arround my house and not lose telnet and ssh sessions ... they are sitting in <url url="ftp://bullard.esc.cam.ac.uk/pub/irda" name="ftp://bullard.esc.cam.ac.uk/pub/irda"> &dquot;
<sect1>IPv6
<p>
AFAIK IPv6 has neighbor discovery mechanismem, 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 :&dquot;patch-2.2.7-ac1-irda4&dquot; .
<sect1>DHCP
<p>
I have got reports that it is possible to use <tt>dhcpcd</tt> with IrLAN. Please use latest DHCP software.
<sect>Linux/IrDA and APM
<p>
Fons Botman wrote: &dquot;When I hibernate my HP OmniBook 2000CT, (Fn-12 diskimage is written to disk, machine turns off completely) with irtty active and turn it on again, irda does not work. I can see it trying to reply to discovery frames it receives from a windows box, using irdadump on the OmniBook. but the windows PC does not see the replies. If I just kill irattach and remove irtty and serial, and start irattach again, it starts working again. Does this occur with other linux laptops also? Is it a problem in the serial device driver? &dquot; Also Pedro Figueiredo reported this problem for a Fujitsu LifeBook 735DX.
<p>
Answer by Dag Brattli: &dquot;Could you all check if the same thing is happening when your're using PPP (and not using IrDA). I guess the APM stuff shuts down the serial port, so that the driver will need to reinitialize it when waking up again. This is properly implemented by some of the PCMCIA drivers I know about, but I really don't think the serial driver gets any events from the APM system.
<p>
So here you have your own little kernel project. Start adding APM support to irport which will be the easiest thing (and also to the FIR drivers), then you can start adding a patch to the serial driver (if needed). Again I think the PCMCIA subsystem may be a good source on how to fix it properly.&dquot;
<sect>Known Bugs
<p>
If you find a bug, please send a bug report to the mailing list, including <tt>dmesg</tt> 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 <tt>echo 0 &gt;/proc/sys/net/irda/discovery</tt>)
A <tt>CR</tt> (carriage return) character cannot be transfered between two linux boxes via IrCOMM with <tt>cat file &gt;/dev/irnine</tt> and <tt>cat /dev/irnine</tt>. It causes a strange thing and freezes your Linux box.
Compiling the pc87108 device driver non modular crashes the kernel on boot. Temporary solution: compile the driver as a module
IrOBEX may eat some data on receive. The bug is most probably in the user-space side of IrOBEX.
<p>
<sect>FAQ
<p>
<itemize>
<item>Q1 - Question: I do not know anything about ports and irqs. What should I do?
<item>Answer:
<p>
PART A: Hardware settings
<p>
- 1 Have a look at your hardware specs!!! If not available look at the support page of your vendor, or contact the support hotline. You might also find the information in one of the hardware surveys mentioned above.
<p>
- 2 Use a current BIOS. Usually available at the support page of your vendor.
<p>
- 3 Try <tt>setserial /dev/ttyS? -g -a &verbar; egrep 16550A</tt>. One of the shown devices is probably the one you are looking for. Usually it is the second one, but with no guarantee.
<p>
- 4 Note: What seems like an UART is physically the IrDA controller. For my HP Omnibook 800 this is the VLSI VL82C147 PCI - IrDA controller. These controllers should behave up to 115 200 bps like UART's. But sometimes it is very difficult to get the right configuration.
<p>
PART B: How to tell the kernel about the hardware settings
<p>
-4 <tt>cat /dev/ioports</tt> to see which ports are already in use.
<p>
-5 <tt>cat /dev/interrupts</tt> to see which interrupts are already in use.
<p>
-6 Make ports and interrupts available for use with the IR device, e.g. stop the pcmcia service or include a line like this in <file>/etc/sysconfig/pcmcia</file>: <tt>PCIC_OPTS=&dquot;irq_list=3,4,5,7,9,10,12,14,15&dquot;</tt>
<p>
-7 Now try to guess what the right interrupt and port is. Use <tt>setserial /dev/ttySx irq M port 0xNNNN</tt> to tell the kernel. If there is more then one possible chance try them all (Note: As mentioned in the <it>Serial-HOWTO</it> you should not try irq 0, 1, 6, 8, 13, 14).
<p>
-8 If you were successful please send the useful parameters to the author, because I would like to include them in the hardware survey.
<p>
-9 Good luck.
<p>
It might also be necessary to fine tune the IR serial port with setserial, e.g., <tt>setserial /dev/ttyS0 spd_vhi</tt> (speed rate 115200).
<p>
<item> Q2 - Question: For me, <tt>irattach</tt> hangs, but recognizes the printer. <file>/var/log/messages</file> shows that irattach found my HP LaserJet 6P.
<item>Answer: The &dquot;hang&dquot; is normal for irattach. Everything is working right if you see the HP Laserjet show up in the log. &dquot;hang&dquot; means irattach is polling the IrDA-Devices for incoming connections. If you kill it with &lt;CTRL C&gt; the irattach program crashes and /dev/ttySx does not work anymore. The problem is within the irda module, and not with the irattach program. Rebooting is the only thing to do! Next time put irattach in the background by using <tt>irattach &amp;</tt>. Stop it if necessary with <tt>killall irattach</tt>. Recommendation by Andreas Butz: To my knowledge, &lt;CTRL Z&gt; <tt>bg</tt> should work, too, but I haven't tried it in this specific case. Normally it has the exact same effect as appending <tt>&amp;</tt> to a command.
<p>
<item> Q3 - Question: I get a message like tcsetattr read/write error in /var/log/messages.
<item>Answer: Caused probably by wrong /dev/ttyS* or wrong irq or port.
<p>
<item> Q4 - Question: Every setting seems alright, because I get the appropriate messages. But it still does not work.
<item>Answer: Move the devices to within 0.5 meter (1.5 feet). Check that only one application is using the infrared port. Check that both devices are using the same protocol, such as IrOBEX or IrCOMM.
<p>
<item>Q5 - Question: I have downloaded the latest snapshot, and compiled it successfully under Linux 2.0.33 running on an IBM Thinkpad 560E. In the absence of any other IrDA machines to test with, is it safe to assume that once the module has been inserted and the syslog reports &dquot;irattach: Serial connection established.&dquot;, is the IR really working, and will it start to respond once there is another machine with which to talk?
<item>Answer by Dag Brattli: Sorry, this only means that irattach has done its part of the job, which is just to start the irda-tty. Maybe the message should have been different, but as I said, it tells that the serial connection between the irda-chip and the irda-driver is established.
<p>
Note: Support for IrDA on 2.0.x kernels has been discontinued. You are encouraged to switch to 2.2.x kernels and use the newest IrDA patches available at <url url="http://www.cs.uit.no/linux-irda/snapshots/" name="http://www.cs.uit.no/linux-irda/snapshots/">.
<p>
<item>Q6 - Question: At startup <tt>modprobe -a</tt> checks <file>/lib/modules/&lt;KERNEL-VERSION&gt;/net/irda.o</file> and causes the messages: &dquot;IrLAP; Missing IrTTY /IrLMP Error no IrLAP connection&dquot; (in <file>/var/log/messages</file> and on the console).
<item>Answer by Werner Heuser: Workaround for SYSTEM V style systems: Put a script named for example &dquot;ir_rmmod&dquot; containing
<tscreen>
<code>
&num;!/bin/sh
echo &dquot;$0 : remove irda module&dquot;
rmmod irport.o
rmmod irtty.o
rmmod irda.o
</code>
</tscreen>
in the startup process (<file>/etc/init.d</file> and a symbolic link name for example &dquot;S100ir_rmmod&dquot; in <file>/etc/rc3.d</file> to &dquot;ir_rmmod&dquot;). (Verify the path for &dquot;sh&dquot;). For BSD style systems try the corresponding approach.
<p>
<item>Q7 - Question by Ho Chin Keong: Is there other way of setting up communication between the 2 laptops besides setting up a LAN route between the two?
<item>Answer by Dag Brattli: Yes and no! One of the IrDA standard, IrCOMM permits you to emulate a serial cable between two laptops, so you can use any application written for serial ports (terminals, PPP, slip, etc.). This is however not yet implemented in Linux/IrDA. The IrLPT (printer) support is actually a subset of IrCOMM, so some of it is working!
<p>
<item>Q8 - Question by Ho Chin Keong: If I block the infrared path deliberately for more than 10 seconds, the connection could not re-establish. I have to kill the irattach and restart the whole procedure to start the infrared route. The connection could be maintained, however, if the blocking is less than 10 seconds. Is this part of the design or a bug? Is there any way whereby we can lengthen this time limit from 10 s to longer or infinitely?
<item>Answer by Thomas Davis: This seems to be a bug in the primary side of the IrLAP/IrLMP code. It appears not to send the reset/disconnect notice all the way back up the stack. You'll notice it when IrLPT gets stuck in the query mode while you were trying to talk to a printer, and disconnected/interrupted it when it was handshaking. (and now, it shows up in the IrLAN portion)
<p>
<item>Q9 - Pierre-Guillaume Raverdy asked: Should I update to IR lib on my palm and update the system to version 3.0.2?
<item>Answer by Dag Brattli: You should not need to update your Pilot, but it should not do any harm to do so. It is however required if you want to use the IrCOMM library from IsComplete
<p>
<item>Q10 - Pierre-Guillaume Raverdy asked: Also any simple source code (especially on the palm side) would be greatly appreciated.
<item>Answer by Dag Brattli: Get the Pilot SDK from Palm. Unzip the examples.zip and take a look at the beamer application.
<p>
<item>Q11 - Is there any IrDA support for BSD?
<item>Answer: Linux/IrDA seems to be the only available GPL source yet.
<p>
<item>Q12 - By Rui Oliveira: I am having a problem connecting a PalmIII to a Linux box with an Actisys 220L adapter. With a motherboard adapter (no brand but, I think, similar to the Actisys 210L) I simply redirect a pilot syncronization tool (pilot-xfer) to <file>/dev/ttyS1</file> which has the ir adapter attached and, using IrLink in SIR mode, I can get the Linux box to talk with the PalmIII. Trying the above through a serial port with a serial-irda Actisys 220L adapter I can't get this to work. My question is :What happens if one just throws data into a serial port with a irda adapter?
<item>Answer by Lichen Wang: In terms of hardware, IrDA SIR needs a serializer- deserializer, an encoder-decoder, and a transceiver. The UART that drives the COM port of any PC is a serializer-deserializer. In some PC, there is also an encoder-decoder which can be enabled or disabled by the BIOS. When it is disabled, the COM port is usable as an old COM port. When the encoder-decoder is enabled, usually the COM port is no longer usable but an IrDA port is now usable instead.
Actisys IR-210 is a SIR transceiver and thus can be used if the PC has this kind of UART with an IrDA encoder-decoder and the BIOS has enabled it. Under this hardware configuration, you need to tell the Windows setup program that you have &dquot;standard infrared devices&dquot; and with &dquot;Built-in Infrared port on laptop or desktop&dquot;.
Actisys IR-220, on the other hand, includes both the encoder-decoder and the transceiver. It is designed to be used with a regular UART. If the UART in the PC has also the encoder-decoder built-in, you must use BIOS to disable that. Under either of this hardware configuration, you need to tell the Windows setup program that you have an &dquot;ACTiSYS&dquot; manufactured &dquot;ACT-IR220L Infrared Wireless Interface&dquot;.
To answer your question: In addition to throwing data at the serial port, you need to tell the UART and the encoder-decoder what data rate to use. In the case of a built-in encoder-decoder, when you set the data rate of the UART, the encoder-decode also get set correctly. In the case a separate encoder-decoder, you need to tell both of them the data rate separatly.
<item>Q13 - If I try to make a connection, say telnet, it takes an incredibly long time for the login prompt to appear.
<item>Answers by Renaud Baldura, Dag Brattli and Hee Thong: ... it's a DNS problem. The resolver times out trying to reverse-resolve the IP address of your incoming connection. I think just renaming <file>/etc/resolv.conf</file> to something else takes care of it. ... or add some static bindings in /etc/hosts for the machines you want to access in your ad-hoc network. That should avoid the DNS lookups. ... If both machines are in a private test environment, put the following line in the <file>/etc/host.conf</file>, <tt>order hosts, bind</tt>. This will make the machine check the <file>/etc/host</file> file before doing a DNS lookup. Remember to update the host file on both machines to reflect the IP and host names of the 2 machines.
<item>Q14 - Question by David LaPorte: I was wondering if anyone has had any success getting the irda port on the Toshiba Tecra 740cdt working. ... I've read that it should show up at IRQ 11, ttyS2. Well, I have a PCMCIA modem which steals ttyS2 and the PCMCIA controller steals IRQ 11. Does anyone have any suggestions?
<item>Answer by Dag Brattli: If you still have Win95 on your machine, you should go to the device manager and change the PnP setup for the IrDA port (something else than the stuff your're already using). You could for example move away ttyS1 (in Win95), so that it uses the values that the PCMCIA card is going to steal, and then use the settings from ttyS1 for ttyS2.
<code>
dagbnb ~/linux/test/ &gt; cat /etc/sysconfig/pcmcia
PCMCIA=yes
PCIC=i82365
PCIC_OPTS="irq_list=7,9,10"
CORE_OPTS=
</code>
... should make sure the PCMCIA controller stays away from irq 11. Also make sure that the IrDA port is enabled in Win95 since it's disabled by default.
</itemize>
<p>
<sect>Infrared Remote Control
<p>
<sect1>Resources
<p>
<idx>Remote control</idx> via infrared is not the aim of the Linux/IrDA project but is included in this HOWTO to cover &dquot;Linux and Infrared&dquot; more completely. I found <it>three projects</it> which worked on this topic. You may find some links to current information at <url url="http:// www.snafu.de/&tilde;wehe/index_li.html" name="http:// www.snafu.de/&tilde;wehe/index_li.html">.
<itemize>
<item>LInux Remote Control - LIRC
<p>
<idx>LIRC</idx> is a package that supports receiving and sending IR signals of the most common IR remote controls. It contains a device driver for hardware connected to the serial port, a daemon that decodes and sends IR signals using this device driver, a mouse daemon that translates IR signals to mouse movements and a couple of user programs that allow to control your computer with a remote control. Takahide Higuchi wrote about LIRC: &dquot;It's great, and it seems almost complete solution, but it seems there is almost nothing supporting hardware on the market (or need to solder some special circuit ... it is hard work for many people to do so). I believe that LIRC will be more popular if consumer IR support is implemented in FastIR drivers and some common API (for example, a raw IrSocket and common ioctls) is made!&dquot;. You may find LIRC at <url url="http://fsinfo.cs.uni-sb.de/&tilde;columbus/lirc/" name="http://fsinfo.cs.uni-sb.de/&tilde;columbus/lirc/">
To subscribe to the LIRC mailing list send an email to &lt;lirc-request@xmission.com&gt; with the word &dquot;subscribe&dquot; in the body of the message. There is also a mailing list archive at <url url="http://www.wh9.tu-dresden.de/&tilde;heinrich/lirc/list-archive/" name="http://www.wh9.tu-dresden.de/&tilde;heinrich/lirc/list-archive/">
<item>Serial Infrared Remote Controller
<p>
This is a simple, cheap device that can be connected to any serial port to control most components that have infrared remote controls. It was designed and built on a solderless breadboard and is finally designed as a PC board. You may find this package at <url url="http://www.armory.com/&tilde;spcecdt/remote/remote.html" name="http://www.armory.com/&tilde;spcecdt/remote/remote.html">
<item>Infrared Tools for the COREL Netwinder PC
<p>
Ryan Shillington wrote some tools to control the COREL Netwinder via infrared, for example:
<p>
Server Side for the Corel Palm Administrator (deamon). It depends on having ir-simple installed and up and running. With this you can check and change IP addresses, Gateway addresses, setup eth1, etc. You can also run simple commands AND you can check the Temperature, Memory, Load averages, etc.
<p>
Client Side for the Corel Palm Administrator. You can also run simple commands AND you can check the Temperature, Memory, Load averages, etc.
<p>
A very basic Infra Red device driver. This does not support IrDA (only unreliable transfers). It looks specifically for Remote Control signals (and Keyboard, etc.). It blocks and passes data up very differently.
<p>
You may find the tools at <url url="http://www.netwinder.org/&tilde;ryansh/" name="http://www.netwinder.org/&tilde;ryansh/">
<item>ir
<p>
<url url="http://kramer.ne.mediaone.net/ir/" name="ir"> is an interface program to Chris Dodge's RedRat 2 infrared controller to send and receive infrared signals to/from consumer devices like TV's, VCR's, cable boxes, and stereos. It is written in Perl. It uses only the basic Perl constructs and no external packages, so it should work on any platform that supports Perl and serial communications. It can be accessed via the command line or cron, as an email handler (through aliases), or as a cgi script which will automatically generate a form with all possible codes. It has macro capability so one command can send a series of IR signals. With an X-10's IR543, it can be used to control X10 devices, too.
</itemize>
<p>
<sect1>Infrared Remote Control - IrDA
<p>
Two of the above mentioned projects use some kind of selfmade dongle for infrared remote control. There is also a description to build a serial IrDA dongle by yourself in the german ELEKTOR 5/97 p. 28 magazine. Maybe someone can merge these two kind of dongles together.
For a discussion of the relation between Infrared Remote Control and IrDA I quote from the Linux/IrDA mailing list (shortend and modified by wh):
<p>
Ryan Shillington wrote: &dquot;Remote IR and ASK-IR are very different from FIR or MIR or SIR.
Remote IR and ASK-IR are very low speed and low frequency (but very long range) uses for IR. They operate around 2400 baud.
SIR operates at higher rates, and is meant for long range transmission where you need more than a few characters pass through (unlike a remote control).
MIR is a little faster (less range), but with speeds up to 1.15 Mbps, and FIR (where the devices have to be practically touching) is 4Mbps. The range is inversely proportional to the speed you can send data at.
I'm working on drivers for Remote-IR, but you should know that your IR stuff has to support it. Look for protocols like NEC, RC-5 or RC-0 (those are the most common ones).
You can use SIR to receive Remote Control signals. Set your baud rate nice and low and data will come through. BUT, from my experience, it's not the RIGHT data. It's not being analyzed in the right way, and as such, you can't compute the checksums or check it with its complement.
I have managed to get data in (using SIR) with remote controls. I have been told that SIR will read the remote control stuff differently depending on temperature (although I have never had that experience). &dquot;
Lichen Wang &lt;lwang1@ix.netcom.com&gt; wrote in response: &dquot;The so-called ASKIR in most laptops etc. is not meant for remote IR devices. ASKIR is meant for Sharp Wizard and Zauaus PDAs and some of Sharp's notebook PCs. Sharp stated this long before IrDA was established and is still supporting it to maintain backward compatibility. Apple's Newton had this capability at one time, too.
Briefly, ASKIR uses 9.6 Kbps (19.2 and 38.4 Kbps are also possible) asynchronous data format of 8 data bits, 1 stop bit, and odd parity. The <it>start</it> bit as well as all 0 bit in data/parity are transmitted as IR square wave at 500 KHz (DASK sub-carrier). The <it>stop</it> bit as well as all 1 bit in data/parity are represented by the absence of any IR transmission.
As you can see, this is totally incompatible with existing IR remote control.
[..]
True. Not only can you use SIR hardware to <it>receive</it>, you can transmit, too. Of course, there are some limitations.
Most IR remote controls use 38 KHz sub-carrier. 3 times 38 is 114, very close to 115.2. You can set the UART to operate at 115.2 Kbps, 7 data bits, no parity, and 1 stop bit - a total of 9 bits. Each 3 cycles of the 38 KHz sub-carrier can be <it>received</it> or <it>transmitted</it> as a byte of 0x5B.
There are some physical limitations in addition to the fact that the sub-carrier must be 38 KHz. The SIR <it>receiver</it> is not as sensitive to 38 KHz as the IR remote receiver designed for that. The SIR <it>transmitter</it> has a much lower duty cycle and thus can not emit a strong sub-carrier either.
IR remote encodes the control signal by turning on and off the sub-carrier at certain specific patterns. Now that you can <it>transmit</it> and <it>receive</it> the sub-carrier, what remains is all in timing.
For <it>transmit</it>, you have to know how many consecutive bytes of 0x5B to send for each burst of the sub-carrier, and how long to be quiet between the bursts.
For <it>receive</it>, you have to know how many of the 0x5Bs you received are consecutive, and how long the gaps were between these groups of consecutive bytes.
[..]
My experience with the IrDA link distance of SIR, MIR and FIR is somewhat different from what Ryan said.
[..]
SIR, MIR and FIR should all work from 0 to 100 cm but in practice:
(a) Some devices may have problems at <it>LONG</it> distances.
When possible, place the two communicating devices no more than 50 cm apart. Low power devices, such as pagers, phones, etc. may have even shorter ranges despite the fact that they use SIR instead of MIR or FIR.
(b) Some devices may have problems at <it>SHORT</it> distances.
Place the two devices at least a few cm apart. Putting the two devices too close to each other can cause troubles.
It is somewhat intuitive that when the link is not reliable we put the two devices closer together. But it is counterintuitive that too close is not good either. The reason is that the light intensity at 1 cm is 10.000 times brighter than that at 100 cm. At 0.5 cm, it is 40.000 times, etc. The IR receiver manufacturers have difficulties to cover this huge dynamic range. We all have problems reading under a 10 W light bulb, but imagine how it feels under a 100.000 W light!
[..]
The IrDA Physical Layer is totally incompatible with the DASK modulation used in IR remote controls. Thus it is not possible to use the same controller function for both FIR and remote control. However, practically all FIR controller chips do include some additional functions to support remote control. National, SMC, and Winbond (just to name a few) all have such I/O chips.
The IR transmitter for FIR and remote control are very similar. I have tried a standard FIR transmitter. It can reach 10 meters for remote control purpose. Thus it performs just as good as transmitters designed for remote control.
The IR receiver for FIR and remote control are somewhat different. A FIR receiver can receive remote control signals but can reach only 1 meter whereas receivers designed for remote control typically can reach 10 meters.
I have an ISA bus adapter with a National I/O chip that supports both FIR and remote control. I also have IR Dongles that include both FIR and remote control receivers. (Plus a transmitter for both modes.) I cannot find any software to support remote control functions. I did my own experiments in DOS (I cannot run Linux yet.) Anybody interest in this? &dquot;
Benny Amorsen wrote: &dquot;I have a laptop that is supposed to support ASKIR. The mode of the infrared port can be switched to ASKIR in the BIOS. Having to reboot to switch the mode in the BIOS makes it useless, though, so someone would have to find a way to switch on the fly. &dquot;
Dag Brattli wrote: It should be possible to use IrControl (formerly IrBus) for IrDA compliant remote controls. I currently don't know about any remote controls using IrControl standard, but there should be some out there (anyone else who knows better?). You should go to the IrDA site (http://www.irda.org) and get the physical layer standard (which includes IrControl I think).
&dquot;Normal&dquot; IrDA (using IrLAP) is _not_ well suited for remote control because of the connection oriented nature (and just supports 9600bps for connectionless use). The reason for the limited range is eye-safety they say (but I currently don't know why CIR works better using the same power). I have however seen laptops connect at 4-5 meters (but I don't think that any high speed communication would be possible).
Most IrDA chipsets are capable of CIR operation, and it is quite easy to modify the drivers so they talk CIR. Takahide Higuchi has started to look at IrSockets and it would be great if we could open a &dquot;raw&dquot; Ir(DA) socket which then could send and receive CIR packets. Then all the CIR applications could live in userspace.
I know that Corel is interested in using CIR for controlling the NetWinder (and they actually have running code). Take a look at <url url="http://www.slashdot.org/articles/98/12/05/0916216.shtml" name="http://www.slashdot.org/articles/98/12/05/0916216.shtml"> or <url url="http://www.netwinder.org/&tilde;ryansh" name="http://www.netwinder.org/&tilde;ryansh">
From the &dquot;IrDA Data Link Design Guide&dquot p. 21 by Hewlett-Packard <url url="http://www.hp.com/go/ir" name="http://www.hp.com/go/ir"> : &dquot; It is possible to transmit and receive signals other than IrDA signals with Hewlett-Packard IR transceivers. For implementation details, please refer to the Application Note, Transceiver Performance with ASK and TV Remote Signals.&dquot;
From the IR-MAN page <url url="http://www.usuarios.com/ib308564/irda.html" name="http://www.usuarios.com/ib308564/irda.html"> :
Fortunately, many IrDA devices are compatible with the 38-kbps ASK modulation used in TV remotes. This means that they can work with such kind of infrared type signals. ... However, it seems that there are still many portable computers that can't receive TV infrared stuff.
For desktop computers, there exist <it>two</it> options, depending on the motherboard you have. Usually a Pentium MoBo has an I/O chipset ready for infrared communication. There is a special connector where you can connect the transducer. The other option is buying a serial type transceiver that connects to the standard serial port (RS-232) of the computer. ... PC Remote Control has been tested with success using both type of IrDA devices:
1) IRmate IR-210 Serial Port Infrared Adapter. ... The serial port speed at wich the device sends recognizable data values is 2400 bps. I don't know if this speed will be the same for all the adapters of this type or is an unique characteristic of this model.
Look at the examples of data values received to see how similar are them. There are some infrared commands that change a lot every time, difficulting the recognition. In such cases, a great tolerance in the comparison could be used, but the risk of confusion between different commands will be increased. An apropiate tolerance value for almost all cases is 20.
2) Actisys IR2000L connected to an Asus P2B motherboard. ... There are several serial port speeds that work well, although 4800 bps seems to be the best one. Other adapters of this same type work also well using this speed. Take a look at the samples of data sequences received using this device. Some remote buttons send exactly the same sequence and it's impossible to distinguish between them at all.
3) Asus IR-eye connected to the same MoBo as above. It works as well as the Actisys device.
TV remotes send commands only one way, in a low-speed burst for distances of up to 30 feet. They use directed IR with LEDs that have a moderate cone angle to improve ease-of-use characteristics. Cordless connectivity via IrDA transfers files, point-to-point and bidirectionally, in a high-speed burst for short distances using directed IR with LEDs having a narrow cone angle. IrDA transmissions require relatively careful aiming, and they're easy to block. For this reason, don't expect a great distance while working with the remote unit.
Alessio Massaro &lt;Alessio.Massaro@cern.ch&gt: wrote: &dquot; IrDA doesn't talk to tv-remotes, but it does have the IrCOMM layer to emulate a serial i/f. My guess is that to get LIRC working with it, you should just need ... to read from the IrCOMM virtual serial device (as you would with a /dev/cua or whatever) and use a remote that can be seen by your dongle+IrDAheader pair.&dquot;
Answer by Dag Brattli: &dquot;You are talking about being <it>normal</it> serial ports, but that is something at least I have choosen IrDA not to be. I have implemented all the device drivers as network device drivers, so things are a bit different (more frame oriented). The device drivers deliver IrDA frames and currently nothing else.
But I don't think that we must have a tty interface to the IrDA device drivers in order to support more <it>RAW</it> reads and writes. And btw. forget about IrCOMM, it has nothing to do with this issue.
I have actually already implemented support for <it>raw</it> reads and writes for the device drivers, since some of the dongles require this.&dquot;
<sect>Infrared and Eye Safety
<p>
This section summarizes some ideas and thoughts that were exchanged on the Linux/IrDA mailing list. It is not medically wellfounded, and whoever has better evidence or some more wellfounded source of information is encouraged to contribute it to this HOWTO.
<p>
The IrDA spec says that the range of IrDA devices has been limited to 1m for reasons of eye safety. Another plausible assumption is that power consumption and IR pollution/crosstalk were reasons for this limitation. In principle there could be danger for the eye, because infrared light is not registered by the eye, and thus the pupil won't close in order to protect the retina from bright IR light sources. This is the same situation as with UV light, which will cause snow blindness eventually, but in contrast to UV light, IR light contains much less harmful energy due to its longer wavelength.
<p>
The only legal restrictions and medical advices we were able to find on the web were concerned with infrared emissions of heat lamps or in the welding process and IEC 825-1 (CENELEC EN60825-1). This suggests that IR light as emitted by IrDA devices will be harmless, since even the peak power emitted by strong IR LEDs (ca. 300mW) is several orders of magnitude below the power emitted by medical IR heat lamps (up to 500W). For these, however, you are supposed to wear protective goggles, so maybe if you are looking straight into 1.000 infrared LEDs flashing at once, you should do so, too. The effect of infrared light is mostly heat, though, and not an alteration or destruction of the biological cell structure, such as caused by UV light. Though in the specs for the HP OmniBook 800 Hewlett-Packard recommends not to look directly into the IR LED.
<p>
As stated above, this discussion is only based on guesswork and common sense assumptions about the data found in IR LED and heat lamp specs. If anybody with a better medical knowledge can comment on this, please do so!!!
<sect>Credits
<p>
Thanks to:
<itemize>
<item>Dag Brattli - Linux/IrDA core team
<item>Thomas Davis - Linux/IrDA core team
<item>Takahide Higuchi - Linux/IrDA core team
<item>Ralf Zabka
<item>Benny Amorsen
<item>Lichen Wang
<item>Ryan Shillington
<item>Richard Titmuss
<item>Fons Botman
<item>Rui Oliveira
<item>Jon Howell
<item>Carlos Vidal
<item>Joonas Lehtinen
<item>Markus Schill
<item>Bjoern Hansson
<item>Pawel Machek
<item>Ho Chin Keong
<item>Bjoern Mork
<item>Andreas Butz
<item>Tang Ning
<item>Philip Blundell
<item>Toni van de Wiel
<item>Stefan Dahlke
<item>Ales Dryak
<item>Richard Donkin
<item>Wessel de Roode
<item>Andrew Chadwick
<item>James McKenzie
<item>Gerd Knorr
<item>Claudiu Costin
<item>K-H. Eischer
<item>Alessio Massaro
<item>Igor Pesando
<item>Mathieu Arnold
<item>Harald Milz
<item>The members of the Linux-IrDA mailing list.
<item>The writers of the other HOWTOs which gave me many inspirations.
<item>The developers of the SGML-Tools which provided some means to write a HOWTO.
</itemize>
Sorry I didn't start to follow the credits when starting the HOWTO, so probably I forgot somebody.
<sect>Revision History
<p>
<itemize>
<item>v0.1 to v0.4a, 19 March 1998 to 4 August 1998, drafts, not included in the LDP
<item>v1.0, 14 August 1998, release to the LDP
<item>v1.1, 18 August 1998, added info about IrCOMM patch by Takahide Higuchi, minor changes
<item>v1.2, 24 August 1998, updated to <tt>linux-irda-1998-08-20</tt> snapshot, added FIR section and revision history, minor changes
<item>v1.3, 27 September 1998, added sections about multiple instances, cellular phones, digital cameras,Linux to Linux connection, the cutting edge - CVS, power saving; some changes in general configuration section, changes in hardware survey section, minor changes
<item>v1.4, 11 October 1998, better description of IrCOMM support, changes in dongle connection section, changes in Palm III section, minor changes
<item>v1.5, 12 October 1998, minor changes
<item>v1.6, 26 October 1998, section about IrManager added, updated to the <tt>linux-irda-1998-10-21</tt> snapshot, changed dongle connection section, minor changes
<item>v1.7, 1 November 1998, added remote control section, changed dongle connection section, minor changes
<item>v2.0, 9 January 1999, nearly complete rewrite and rearrangement according to the new structure of Linux/IR which is included into the kernel since 2.1.131, added info about BIOS support into dongle connection section, configuration tool section and CVS section removed
<item>v2.1, 13 January 1999, minor changes
<item>v2.2, 26 January 1999, project name changed from Linux/IR to Linux/IrDA, extended the Troubleshooting chapter, changed the order of the Known Bugs chapter after the Troubleshooting chapter, removed some lint
<item>v2.3, 4 February 1999, added chapter about Eye Safety written by Andreas Butz; spell checking, reworking of Kernel Parameters chapter and additional information by Andreas Butz; minor changes
<item>v2.4, 9 February 1999, changed information about applying a patch file
<item>v2.5, 12 March 1999; new URL for Linux/IrDA; added chapters about Big Endian support, <tt>irdaping</tt>, <tt>irdadump</tt> and Beyond IrDA - Extending Transmission Distance; chapter Obtaining Information about the Infrared Port in Laptops improved; added many information provided by Fons Botman to Windows chapter; added SMP chapter; informations about Ericsson SH888 added; removed obsolete FAQs; minor changes
<item>v2.6, 6 April 1999, added chapters Connection to Docking Station, Connection to Keyboard and Connection via Serial Cable, minor changes
<item>v2.7, 11 June 1999 started chapter Upcoming Standards (Bluetooth and IrDA), added annotations about CORBA to GUI chapter, minor information about Nokia cellular phones added, added Appendix B Serial Infrared Port Sniffer, started IrDA Network Neighborhood section, started Connection to Psion 5 chapter and Appendix C, minor additions to LiRC chapter, minor changes
<item>v2.8, 20 September 1999, added LiRC mailing list, changed &lt;htmlurl ... &gt; tag to &lt;url ...&gt;, changed format of conf.modules entries, addition to hardware detection (PCMCIA), added IrDA mailing list, changed address of Linux-IrDA mailing list, minor additions to multiple instances section, added URL of French translation, added new <tt>sersniff</tt> to Appendix B, added section about precompiled packages, added Palm III Connection to Thinkpad 600 chapter, minor changes
</itemize>
<p>
<sect>Copyright and Disclaimer
<p>
Copyright &copy; 1998, 1999 by Werner Heuser. This document may be distributed under the terms set forth in the LDP license at <url url="http://metalab.unc.edu/LDP/COPYRIGHT.html" name="LDP">.
<p>
The information in this document is correct to the best of my knowledge, but there's a always a chance I've made some mistakes, so don't follow everything too blindly, especially if it seems wrong. Nothing here should have a detrimental effect on your computer, but just in case I take no responsibility for any damages incurred from the use of the information contained herein.
<sect>Appendix A - Configuration Script
<p>
Configuration script by Ove Ewerlid (please change to new major device numbers, wh):
<code>
&num;!/bin/sh
&num; You may have problems if kerneld is running!
killall irattach
killall irmanager
sleep 1
rm -f /dev/ircomm
mknod /dev/ircomm c 60 64
rmmod ircomm_tty
rmmod ircomm
rmmod irtty
rmmod irda
insmod irda
insmod irtty
insmod ircomm
insmod ircomm_tty
irmanager &num; executes 'irattach /dev/ttyS1' based on /etc/irda/drivers
&num; Now start your favorite PPP software on /dev/ircomm
&num; The 'no activity on link' happens if you move the phone out of IR sight, this is no problem once the phone is back in sight!
&num; Mar 10 12:31:41 octagon kernel: Linux-2.2 Support for the IrDA (tm) Protocols (Dag Brattli)
&num; Mar 10 12:31:41 octagon kernel: IrCOMM_common, $Revision$ $Date$ (Takahide Higuchi)
&num; Mar 10 12:31:41 octagon kernel: IrVTD, $Revision$ $Date$ (Takahide Higuchi)
&num; Mar 10 12:31:41 octagon irmanager: executing: './drivers start 0'
&num; Mar 10 12:31:41 octagon irmanager: + 0.1 Fri Jul 25 11:45:26 1997 Dag Brattli
&num; Mar 10 12:31:41 octagon irattach: Serial connection established.
&num; Mar 10 12:31:41 octagon kernel: IrDA device irda0 registered.
&num; Mar 10 12:31:41 octagon irmanager: + 0.1 Fri Jul 25 11:45:26 1997 Dag Brattli
&num; ...
&num; Mar 11 13:13:43 octagon kernel: IrLAP, no activity on link!
</code>
<sect>Appendix B - Serial Infrared Port Sniffers
<p>
<sect1>Sniffer by Gerd Knorr
<p>
This programm is a courtesy by Gerd Knorr. You may use it to sniff the traffic which is going trough your IrDA port for details of the protocol (change the default ttyS1 in the source if necessary):
<code>
&num;include <stdio.h>
&num;include <stdlib.h>
&num;include <unistd.h>
&num;include <string.h>
&num;include <fcntl.h>
&num;include <termios.h>
&num;include <ctype.h>
&num;include <sys/types.h>
&num;include <sys/time.h>
&num;include <sys/ioctl.h>
&num;define BUFSIZE 1024
int
read_and_print(int fd, int sec, int usec)
{
int rc,l,i;
char buf[BUFSIZE+1];
fd_set set;
struct timeval tv;
if (sec || usec) {
FD_ZERO(&amp;set);
FD_SET(fd,&amp;set);
tv.tv_sec = sec;
tv.tv_usec = usec;
if (0 == select(fd+1,&amp;set,NULL,NULL,&amp;tv))
return -1;
}
switch (rc = read(fd,buf,BUFSIZE)) {
case 0:
printf("EOF");
exit(0);
break;
case -1:
perror("read");
exit(1);
default:
for (l = 0; l < rc; l+= 16) {
printf("%04x ",l);
for (i = l; i < l+16; i++) {
if (i < rc)
printf("%02x ",buf[i]);
else
printf("-- ");
if ((i%4) == 3)
printf(" ");
}
for (i = l; i < l+16; i++) {
if (i < rc)
printf("%c",isalnum(buf[i]) ? buf[i] : '.');
}
printf("\n");
}
break;
}
return rc;
}
void
setlines(int fd, int rts, int dtr)
{
int lines = 0;
if (rts) lines |= TIOCM_RTS;
if (dtr) lines |= TIOCM_DTR;
ioctl(fd,TIOCMSET,&amp;lines);
}
int main(int argc, char *argv[])
{
int ser,i;
struct termios saved_attributes,tattr;
struct winsize win;
char buf[16];
if (-1 == (ser = open("/dev/ttyS1",O_RDWR))) {
perror("open /dev/ttyS1");
exit(1);
}
/* Set the terminal mode */
tcgetattr (ser, &amp;tattr);
cfmakeraw (&amp;tattr);
cfsetospeed (&amp;tattr,B9600);
cfsetispeed (&amp;tattr,B9600);
tcsetattr (ser, 0, &amp;tattr);
setlines(ser,0,0);
&num;if 0
tcsendbreak(ser,0);
&num;endif
/* main loop */
fprintf(stderr,"setup done\n");
while (-1 != read_and_print(ser,30,0)) {
usleep(100000);
}
return 0;
}
</code>
<sect1>sersniff
<p>
Written by Jonathan McDowell <url url="http://www.earth.li/projectpurple/progs/sersniff.html" name="sersniff"> is a simple program to tunnel/sniff between 2 serial ports. The program was written to aid with the decoding of the protocol used by the Nokia 9000i Communicator to talk to the NServer software Nokia provides, which only runs under Windows.
<sect>Appendix C - User space application for Psion 5 Palmtop Computers: psion.c
<p>
<code>
/*********************************************************************
*
* Filename: psion5.c
* Version: 0.1
* Description: User space application for Psion 5 Palmtop Computers
* Status: Experimental.
* Author: Fons Botman &lt;budely@tref.nl&gt;
* Created at: Mon Apr 19 21:51:29 CEST 1999
*
* Copyright (c) 1999, Fons Botman, All Rights Reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* Neither Fons Botman nor anyone else admit liability nor
* provide warranty for any of this software. This material is
* provided "AS-IS" and at no charge.
*
********************************************************************/
&num;include &lt;unistd.h&gt;
&num;include &lt;stdlib.h&gt;
&num;include &lt;string.h&gt;
&num;include &lt;fcntl.h&gt;
&num;include &lt;stdio.h&gt;
&num;include &lt;errno.h&gt;
&num;include &lt;assert.h&gt;
&num;include &lt;signal.h&gt;
&num;include &lt;time.h&gt;
&num;include &lt;sys/types.h&gt;
&num;include &lt;utime.h&gt;
&num;include &lt;sys/stat.h&gt;
&num;include &lt;sys/ioctl.h&gt;
&num;include &lt;netinet/in.h&gt;
&num;include &lt;sys/socket.h&gt;
&num;include &lt;linux/types.h&gt;
&num;include &lt;linux/irda.h&gt;
&num;ifndef AF_IRDA
&num;define AF_IRDA 23
&num;endif /* AF_IRDA */
&num;define MAX_DEVICES 10
int discover_devices(int fd)
{
struct irda_device_list *list;
unsigned char *buf;
int len;
int i;
int daddr = 0;
len = sizeof(struct irda_device_list) +
sizeof(struct irda_device_info) * MAX_DEVICES;
/* FIXME */
system("echo 150 &gt; /proc/sys/net/irda/slot_timeout");
if (!(buf = malloc(len))) {
fprintf(stderr, "Could not allocate discovery buffer.\n");
exit(1);
}
list = (struct irda_device_list *) buf;
/* FIXME: discovery does not return when there are no devices */
if (getsockopt(fd, SOL_IRLMP, IRLMP_ENUMDEVICES, buf, &amp;len)) {
perror("getsockopt");
exit(-1);
}
if (len &gt; 0) {
printf("Discovered:\n");
for (i=0;i&lt;list-&gt;len;i++) {
printf(" daddr: %08x", list-&gt;dev[i].daddr);
printf(" saddr: %08x", list-&gt;dev[i].saddr);
printf(" name: %s\n", list-&gt;dev[i].info);
daddr = list-&gt;dev[i].daddr;
}
} else {
printf("No devices discovered.\n");
}
return daddr;
}
int irttp_get_mtu(int fd) {
int mtu;
int len = sizeof(int);
/* Check what the IrTTP data size is */
if (getsockopt(fd, SOL_IRLMP, IRTTP_MAX_SDU_SIZE,
(void *)&amp;mtu, &amp;len)) {
return -1;
}
return mtu;
}
int sendfile(char* filename) {
int fd;
struct sockaddr_irda peer;
int daddr;
FILE* f;
int buflen;
char *buf;
int rc;
struct stat s;
int cnt;
int t0, tx, t;
unsigned long long int fdatell;
fd = socket(AF_IRDA, SOCK_STREAM, 0);
if (fd &lt; 0) {
perror("socket");
if (errno == EINVAL)
fprintf(stderr, "Is IrDA active?, perhaps run irmanager\n");
exit(-1);
}
/* FIXME: We should use a better/any device selection mechanism */
daddr = discover_devices(fd);
if (!daddr) {
fprintf(stderr,"No IRDA device found\n");
exit(1);
}
peer.sir_family = AF_IRDA;
peer.sir_addr = daddr;
strcpy(peer.sir_name, "Epoc32:EikonIr:v1.0");
if (connect(fd, (struct sockaddr *) &amp;peer,
sizeof(struct sockaddr_irda))) {
perror("connect");
if (errno == ENETUNREACH)
/* P5: System ^L IrDA is active,
but IR-receive not selected */
fprintf(stderr,
"No Psion5 or IR-receive is not selected\n");
exit(-1);
}
printf("Connected to %x\n", daddr);
buflen = irttp_get_mtu(fd);
printf("mtu = %d\n", buflen);
if (buflen &lt; 2) {
perror("irttp_get_mtu");
exit(1);
}
if (!(buf = malloc(buflen))) {
perror("malloc");
exit(1);
}
/*
FIXME : I got strange results when the buffer size was less than
the mtu (e.g. 200), the psion did not seem to see the frames were
not full length, and stopped after the number of frames based on
the full mtu size.
investigate.
*/
/*
FIXME : psion connects to port 2, but does not get error back
from us. Linux bug?
*/
if (!(f = fopen(filename,"rb"))) {
perror(filename);
exit(1);
}
rc = stat(filename,&amp;s);
if (rc != 0) {
perror("stat");
exit(1);
}
/* FIXME map psion mode bits to unix filemodes */
fdatell = 62168263200000000ULL + 1000000 *
( s.st_mtime & 0x00000000FFFFFFFFULL);
printf("date: %Ld\n", (unsigned long long) s.st_mtime);
printf("date: %Ld\n", fdatell);
sprintf(buf,"FILE %d %d %lu %lu %s",
(int) s.st_size,
32 | (s.st_mode & S_IWUSR ? 0 : 1),
(unsigned long) ((unsigned long long int) fdatell &gt;&gt; 32),
(unsigned long) (fdatell & 0x00000000FFFFFFFFULL),
filename);
rc = write(fd,buf,strlen(buf));
if (rc != strlen(buf)) {
perror("write");
fprintf(stderr,"rc = %d, strlen=%d\n",
rc, strlen(buf));
exit(1);
}
printf("sent: %s\n", buf);
rc = read(fd,buf,buflen-1);
printf("Received (%d) ", rc);
if (rc &lt; 0) {
perror("reply error");
exit(1);
}
if (rc == 0) {
fprintf(stderr, "EOF on reply?\n");
exit(1);
}
if (rc &lt; buflen) {
buf[rc] = 0;
}
/* should be "ACK Y" */
if (0 != strcmp(buf,"ACK Y")) {
fprintf(stderr, "Unexpected response: %s\n", buf);
exit(1);
}
printf("%s\n", buf);
cnt = 0;
t0 = tx = t = time(NULL);
while (!ferror(f) &amp;&amp; !feof(f)) {
int wrc;
rc = fread(buf, 1, buflen, f);
if (rc == 0) continue;
wrc = write(fd,buf,rc);
if (wrc &lt; 0) {
perror("write");
exit(1);
}
if (wrc &lt; rc) {
fprintf(stderr, "Problem: only sent %d of %d\n",
wrc, rc);
exit(1);
}
/* progress indication */
t = time(NULL);
cnt += rc;
if (t - t0 == 0 || cnt == 0 || tx == t)
/* avoid division errors */
/* only once per second */
continue;
tx = t;
printf("sent %d/%lu bytes=%4g%% in %d sec,"
" %g Kbytes/s, to go %li sec \r",
cnt, s.st_size, 100.0 * cnt / s.st_size, t - t0,
cnt / 1000.0 / (t - t0),
( s.st_size - cnt ) * (t - t0) / cnt);
fflush(stdout);
}
if (ferror(f)) {
perror("ferror");
exit(1);
}
if (cnt != s.st_size) {
printf("Warning: "
"file size changed: initial: %lu, actual: %d\n",
s.st_size, cnt);
}
if (t == t0) t++; /* white lie for fast transfers */
printf("\r%79s\r",""); /* Cleanup the progress line */
printf("Sent %s, %d bytes in %d sec. %g KBytes/sec\n",
filename, cnt, t - t0, cnt / 1000.0 / (t - t0));
/* Check for close on the other side */
rc = read(fd,buf,buflen);
if (rc &gt; 0) {
fprintf(stderr, "Strange: the other side responded.\n");
fprintf(stderr, "rc=%d, data:%s\n", rc, buf);
exit(1);
}
if (rc == 0) {
fprintf(stderr, "Received end of file.\n");
}
if (rc == -1) {
if (errno == EPERM) {
/* Strange error code to get in this case */
printf("Other side closed connection, OK\n");
} else {
perror("last read");
exit(1);
}
}
close(fd);
return 0;
}
int handle_client(int cfd) {
int buflen;
char* buf;
int rc;
/* fields of file transfer header */
unsigned int fsize;
unsigned int fmode;
unsigned int fdate1;
unsigned int fdate2;
char* fname;
unsigned int fdate;
unsigned long long int fdatell;
FILE* f;
int cnt;
int t0, tx, t;
buflen = irttp_get_mtu(cfd);
printf("mtu=%d\n", buflen);
if (buflen &lt; 2) {
perror("irttp_get_mtu");
exit(1);
}
if (!(buf = malloc(buflen))) {
fprintf(stderr, "malloc buf failed\n");
exit(1);
}
/* Wait for the other side to send a header */
/*
Sample headers received:
DATA 185
FILE 55175 32 14689800 2691219200 Data
size mode datehi datelo name
*/
rc = read(cfd, buf, buflen);
if (rc &lt; 0) {
perror("1st read");
exit(1);
}
if (rc == 0) {
perror("1st read 0");
exit(1);
}
assert(rc &lt; buflen);
buf[rc] = 0;
printf("%s\n", buf);
fsize = 0;
fdate = 0;
if (0 == strncmp(buf, "FILE ", 5)) {
cnt = 0; /* to be safe */
rc = sscanf(buf, "FILE %u %u %u %u %n",
&amp;fsize, &amp;fmode, &amp;fdate1, &amp;fdate2,
&amp;cnt);
if (!(rc == 4 || rc == 5)) {
/* grumble */
fprintf(stderr, "sscanf rc=%d\n", rc);
exit(1);
}
assert(cnt &lt; buflen);
fname = strdup(buf+cnt);
fdatell = ((unsigned long long int) fdate1 &lt;&lt; 32) + fdate2;
fdate = ( fdatell - 62168263200000000ULL) / 1000000 ;
printf("filename: %s\n", fname);
printf("filesize: %d\n", fsize);
printf("Filemode: %d", fmode);
printf("%s", (fmode & 1 ? ", Readonly" : ""));
printf("%s", (fmode & 2 ? ", Hidden" : ""));
printf("%s", (fmode & 32 ? ", Modified" : ""));
printf("%s", (fmode & ~35 ? ", Unknown" : ""));
printf("\n");
printf("fdate1: %u = 0x%x\n", fdate1, fdate1);
printf("fdate2: %u = 0x%x\n", fdate2, fdate2);
printf("filedate: %Ld\n", fdatell);
printf("filedate: %d = %s", fdate,
asctime(gmtime((time_t*)&amp;fdate)));
if (!(f = fopen(fname,"wb"))) {
perror(fname);
exit(1);
}
} else if (0 == strncmp(buf, "DATA ", 5)) {
cnt = 0; /* to be safe */
rc = sscanf(buf, "DATA %d", &amp;fsize);
if (rc != 1) {
fprintf(stderr, "sscanf rc=%d\n", rc);
exit(1);
}
assert(cnt &lt; buflen);
fname = strdup("/tmp/psion5-data");
if (!(f = fopen(fname,"wb"))) {
perror(fname);
exit(1);
}
} else {
fprintf(stderr, "Unknown data type: %s\n", buf);
/* exit(1); */
}
rc = write(cfd,"ACK Y",5);
if (rc != 5) {
perror("1st write");
fprintf(stderr,"1st write rc = %d\n", rc);
exit(1);
}
cnt = 0;
t0 = tx = t = time(NULL);
while (cnt &lt; fsize) {
int wrc;
rc = read(cfd,buf,buflen);
if (rc &lt; 0) {
perror("data read");
/* EPERM on disconnect ? */
exit(1);
}
if (rc == 0) {
perror("data read 0");
exit(1);
}
wrc = fwrite(buf,rc,1,f);
if (wrc != 1) {
perror("fwrite");
exit(1);
}
cnt += rc;
/* progress indication */
t = time(NULL);
if (t - t0 == 0 || cnt == 0 || tx == t)
/* avoid division errors */
/* only once per second */
continue;
tx = t;
printf("got %d/%u bytes=%g%% in %d sec,"
" %g Kbytes/s, to go %i sec \r",
cnt, fsize, 100.0 * cnt / fsize, t - t0,
cnt / 1000.0 / (t - t0),
( fsize - cnt ) * (t - t0) / cnt);
fflush(stdout);
}
if (cnt != fsize) {
printf("Warning: "
"file size changed: initial: %u, actual: %d\n",
fsize, cnt);
}
if (t == t0) t++; /* white lie for fast transfers */
printf("\r%79s\r",""); /* Cleanup the progress line */
printf("Received %s, %d bytes in %d sec. %g KBytes/sec\n",
fname, cnt, t - t0, cnt / 1000.0 / (t - t0));
rc = fclose(f);
if (rc != 0) {
perror("fclose");
exit(1);
}
if (fdate) {
struct utimbuf utb;
utb.actime = fdate;
utb.modtime = fdate;
rc = utime(fname,&amp;utb);
if (rc != 0) {
perror(fname);
}
}
free(fname);
close(cfd);
return 0;
}
int receivefile(int mode)
{
/*
The Psion 5 tries the following connections:
Epoc32:EikonIr:v1.0 IrDA:TinyTP:LsapSel
IrDA:IrCOMM Parameters
IrLPT IrDA:IrLMP:LsapSel
connect on 2
Warning: discovery reply after 101ms
*/
int addrlen = sizeof(struct sockaddr_irda);
/* int oflags; */
/* int mtu; */
int fd;
struct sockaddr_irda peer;
int cfd;
/* Create socket */
fd = socket(AF_IRDA, SOCK_STREAM, 0);
if (fd &lt; 0) {
perror("socket");
exit(-1);
}
/* Bind local service */
peer.sir_family = AF_IRDA;
strcpy(peer.sir_name, "Epoc32:EikonIr:v1.0");
peer.sir_lsap_sel = LSAP_ANY;
if (bind(fd, (struct sockaddr*)&amp;peer, sizeof(struct sockaddr_irda))) {
perror("bind");
return -1;
}
if (listen(fd, 2)) {
perror("listen");
return -1;
}
/* FIXME: allow more simultaneous clients */
for (;;) {
cfd = accept(fd, (struct sockaddr *) &amp;peer, &amp;addrlen);
if (cfd &lt; 0) {
perror("accept");
return -1;
}
if (handle_client(cfd))
break;
if (mode == 1)
break;
}
sleep(1);
close(fd);
return 0;
}
int
main(int argc, char* argv[]) {
char* argv0 = argv[0];
if (argc &lt;= 1) {
fprintf(stderr, "Usage: %s [-s file] [-r] [-d]\n", argv0);
fprintf(stderr, "\t-s file\tSend file to the Psion\n");
fprintf(stderr, "\t-r\tReceive a file from the Psion\n");
fprintf(stderr, "\t-b\tReceive multiple files (batch mode)\n");
exit(1);
}
/* skip program name */
argv++; argc--;
for ( ; argc&gt;0 &amp;&amp; argv[0] ; argc-- , argv++) {
if (0 == strcmp(argv[0],"-s")) {
/* FIXME: sending multiple files does not
work yet. We need to wait for the user
to select receive again on the psion */
if (argv[1] &amp;&amp; 0 == strcmp(argv[1],"--")) {
/* Allow the user to send ANY filename */
argv++; argv++;
for ( ; argv[1] ; argv++ , argc--) {
sendfile(argv[1]);
}
} else {
/* Send files upto next switch */
while (argv[1] &amp;&amp; *argv[1] != '-') {
sendfile(argv[1]);
argv++; argc--;
}
}
} else if (argv[0] &amp;&amp; 0 == strcmp(argv[0],"-r")) {
receivefile(1);
} else if (argv[0] &amp;&amp; 0 == strcmp(argv[0],"-b"))
receivefile(0);
else {
fprintf(stderr,"Error: unknown switch %s\n", argv[0]);
fprintf(stderr,"Call without args for usage: %s\n",
argv0);
exit(1);
}
}
return 0;
}
</code>
</article>
View Git Blame Copy Permalink