IrLPT support is under heavy construction at the moment. Maybe it will be replaced by IrCOMM. Please see mailing list archive.
lprm "*".kerneld do a modprobe irtty.modprobe irlpt_client.lsmod. This should show: irda, irtty and irlpt_clientcat /proc/misc. Gives you the minor device-number . It is the first number in the line with irlpt0.su to root, and do mknod /dev/irlpt0 c 10 <minor device-number>. Note: Something like ./MAKEDEV irlpt0 is not possible yet. But maybe load_misc irlpt works, though I couldn't test this yet.cat FILE >/dev/irlpt0 (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."Do you have a (s)serial or a (p)arallel printer interface?" Answer "p"
"What's the device name for your parallel printer interface?" Answer "/dev/irlpt0"
kill -HUP <PID of lpd>. If you use another print daemon choose the according command.Takahide Higuchi reported: " 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."
From the page of Thomas Davis http://www.jps.net/tadavis/irda : To use the IrLPT server, you need to perform the following steps:
/sbin/insmod irlpt_server /sbin/mknod /dev/irlptd c 10 `grep irlptd /proc/misc|cut -f 1`
#/bin/sh # while (true) do cat /dev/irlptd | lpr done
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:
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, &len)) {
perror("getsockopt");
exit(-1);
}
if (len > 0) {
/*
* Just pick the first one, but we should really ask the
* user
*/
daddr = list->dev[0].daddr;
printf("Discovered: (list len=%d)\n", list->len);
for (i=0;i<list->len;i++) {
printf(" name: %s\n", list->dev[i].info);
printf(" daddr: %08x\n", list->dev[i].daddr);
printf(" saddr: %08x\n", list->dev[i].saddr);
printf("\n");
}
}
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, "P1284");
peer.sir_addr = daddr;
connect(fd, (struct sockaddr *) &daddr, sizeof(struct sockaddr_irda));
/* Try to send something */
actual = send(fd, "Testing", 8, 0);
/* Try to read reply */
actual = recv(fd, buf, 1024, 0);
}
modprobe irlan_client before ifup eth0. I had to remove the request_module() stuff since that needed a process context which I don't have in the kernel. "
Maybe you have to choose the access mode. You can do this by using modprobe irlan access=1 for direct mode. IrLAN states that a provider can either be in direct mode, or in peer mode, so you currently have to choose when you start IrLAN.
ifconfig eth0 up <ip_address> netmask <ip_netmask> 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 netcfg to do this, since it makes it very easy. Next time you only need to do /sbin/ifup eth0. Notice that ifconfig does not know how to deal with IrLAP addresses, so the address is really just the 4 first bytes (in little endian format).
route add default gw <ip_gateway> or route add -host <target host> dev eth0.
For an ACTiSYS FIR board and dongle you may do:
irmanager -d1
/sbin/modprobe pc87108 # remove irattach from /etc/irda/drivers, or
# substitute irattach with the modprobe!
On machine 1:
modprobe irlan_client # not really necessary since irmanager should do this!
modprobe irlan_server
Do not compile irlan_server into the kernel, since it currently does not like that! You should have configured /etc/sysconfig/network-scripts/ircfg-eth0 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.
Notice that in the latest patch (2.2.0-irda1) irlan_client will call the device irlan0 by default, but you can change this by giving eth=1 as an option to irlan_client (modprobe irlan_client eth=1 or options irlan_client eth=1 in /etc/conf.modules).
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 ifconfig irlan0 -broadcast 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 "HP NetbeamIR" in the IAS entry to make it connect. Also I have heard rumors that a "Psion 3c" also wanted to connect only to another IR device if it had the same or a similar name.
From Renaud Waldura: All the IrDA stuff is compiled in as modules.
irattach /dev/ttyS0 (or whatever your "serial" IrDA port is, WH). Also /etc/conf.modules contains alias tty-ldisc-11 irtty.irmanager -d 1 then echo 3 >> /proc/sys/net/irda/debug to see what's going on.modprobe irlanecho 9 >> /proc/sys/net/irda/slot_timeout (use 90 for newer kernels!) in order to have the NetbeamIR recognized. Otherwise I was only getting a bunch of "media busy" messages, and no actual discovery of the NetbeamIR. 9 is the smallest value that worked for me.grep_stab $1 < /var/run/stab (line 131) in /etc/irda/shared. For some reason it fails, spitting a "usage" message. ping, ftp, telnet. Yaho!
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 http://www.cdpubs.com/hhsys/archives/66/10brattl.pdf .
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 /dev/irobex is not used anymore!The /etc/irda script is really only good for configuration of the devices, making the right mknod for /dev/irobex etc., not for starting applications.
1) Terminal 1> irattach /dev/ttyS<x>
2) Terminal 2> load_misc irobex
3) Terminal 3> Start irobex_app in the irobex directory. I suppose irobex_app is not working anymore. Now you should use the gtk/irobex 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 irobex_receive.
4) Beam something from your Palm III.
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.
This should also be possible, but I don't have any further information right now.
Rui Oliveira wrote: "This is just to let you know that with the latest IrCOMM patch (050998) of Takahide Higuchi, I managed to HotSync 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
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 PPP-HOWTO for further information about PPP.
... I managed to establish an apparently robust connection between my Linux box and a Palm III. The pppd invocation I use is as follows:
/usr/sbin/pppd /dev/irnine 57600 192.168.2.10:192.168.2.11 proxyarp passive silent persist noauth local nodetach. Over the PPP connection I used ping, ssh, and http.
Strange is however the fact that discovery must be enabled (irmanager -d 1). 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 /dev/irnine or /dev/ircomm."
Jon Howell wrote: "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 PalmTelnet 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."
(1) Start HotSync on your Palm. You need the IrDA upgrade for the Palm to have IrCOMM support
http://www.palm.com/custsupp/downloads/irenhanc.html .
(2) Place the Palm in front of the dongle.
(3) Start pilot-xfer -p /dev/irnine -s <sync-dir> .
And if you are lucky it will start syncing. If you start pilot-xfer before you start HotSync on the pilot, you will _not_ be lucky!
Maybe a terminal program like PalmTerm is also useful.
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 irlib.h:
---------- irlib.h from the SDK 3.0 from palmpilot ----- // Options values for IrOpen #define irOpenOptBackground 0x80000000 // Unsupported background task use #define irOpenOptSpeed115200 0x0000003F // sets max negotiated baud rate #define irOpenOptSpeed57600 0x0000001F // default is 57600 #define irOpenOptSpeed9600 0x00000003 -------------- end quote --------------------------------
Peter Pregler reported: If the Palm enters the range of the irda-device a popup appears with the text "Transmission: waiting for sender"
Ron Choy answered: There is a software called ShutupIR that is supposed to help with this problem of annoying popup http://hp.vector.co.jp/authors/VA005810/irda/shutup10.zip I haven't tried it but it looks like it would fix your problem.
This chapter is a courtesy of Harald Milz - SuSE. Minor changes by Werner Heuser to fit into the HOWTO.
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.
hotsync as far as I know (didn't try yet).
/etc/conf.modules:
# IrDA alias tty-ldisc-11 irtty alias char-major-161 ircomm-tty
irmanager and irattach in /usr/local/sbin (too lazy to make a RPM archive...).
START_IRDA=yes to /etc/rc.config and to add a symlink like /etc/rc.d/rd3.d/S99irda.
mknod /dev/irnine c 161 0 , see also /proc/tty/drivers.
/dev/pilot --> /dev/irnine to make all programs happy (if you use the shell variable PILOTPORT=/dev/pilot).
Call /etc/rc.d/irda start and watch the console messages. ps should show irattach and irmanager running. Check /proc/net/irda to see what is there. ircomm will only be available and show reasonable stuff when an application accesses the irnine port (and loads ircomm_tty through kmod).
Start PilotManager or sync-plan and be happy :-) IR should run fine at 57600 bps.
See SuSE Munich PalmIIIx pages, too.
/etc/irda/drivers:
#! /bin/sh
#
# drivers
#
# Initialize and shutdown IrDA device drivers.
#
# This script should be invoked with two arguments. The first is the
# action to be taken, either "start", "stop", or "restart".
#
action=$1
device=$2
case "${action:?}" in
start)
/usr/local/sbin/irattach /dev/ttyS0 # The third serial port is an IrDA port
# irattach /dev/ttyS0 -d esi # Attach a ESI dongle to the first serial port
# irattach /dev/ttyS0 -d tekram
# insmod pc87108 # If your machine as a pc87108 FIR chipset
# modprobe uircc # Sharp UIRCC chipset
;;
stop)
killall irattach # ... or something. Currently not used
;;
restart)
/sbin/ifconfig ${device:?} down up
;;
esac
/etc/rc.d/irda
#! /bin/sh
# Copyright (c) 1995-1998 SuSE GmbH Nuernberg, Germany.
#
# Author: hm
#
# /sbin/init.d/irda
#
# and symbolic its link
#
# /sbin/rc<skeleton>
#
. /etc/rc.config
# Determine the base and follow a runlevel link name.
base=${0##*/}
link=${base#*[SK][0-9][0-9]}
# Force execution if not called by a runlevel directory.
test $link = $base && START_IRDA=yes
test "$START_IRDA" = yes || exit 0
# The echo return value for success (defined in /etc/rc.config).
return=$rc_done
case "$1" in
start)
echo -n "Starting service irda"
## Start daemon with startproc(8). If this fails
## 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"
## Stop daemon with killproc(8) and if this fails
## 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)
## If first returns OK call the second, if first or
## second command fails, set echo return value.
$0 stop && $0 start || return=$rc_failed
;;
reload)
## Choose ONE of the following two cases:
## First possibility: A few services accepts a signal
## to reread the (changed) configuration.
#echo -n "Reload service foo"
#killproc -HUP /usr/sbin/foo || return=$rc_failed
#echo -e "$return"
## Exclusive possibility: Some services must be stopped
## and started to force a new load of the configuration.
#$0 stop && $0 start || return=$rc_failed
;;
status)
echo -n "Checking for service foo: "
## Check status with checkproc(8), if process is running
## checkproc will return with exit status 0.
#checkproc /usr/sbin/foo && echo OK || echo No process
;;
probe)
## Optional: Probe for the necessity of a reload,
## give out the argument which is required for a reload.
#test /etc/foo.conf -nt /var/run/foo.pid && echo reload
;;
*)
echo "Usage: $0 {start|stop|status|restart|reload[|probe]}"
exit 1
;;
esac
# Inform the caller not only verbosely and set an exit status.
test "$return" = "$rc_done" || exit 1
exit 0
Andrew Chadwick <andrew.chadwick@symbian.com> 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 cat < /dev/ttyS3 and if the serial parameters are right on both machines, you should see the words "Symbian EPOC" (machine ident) scroll past amidst the spew.
Fons Botman wrote: " 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). ;-)" I have put the source into Appendix C.
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.
To start a communication session with /dev/irnine (/dev/ircomm), for instance, say:
dip -t > port irnine > term
cu or xc instead of dip, too (cu -l /dev/irnine or xc -l /dev/irnine). There are also reports about some efforts with the Ericsson GF768 and IR Modem DI 27.
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 (ati1 = 980408 1035 PRGCXC125101):
mknod /dev/ircomm c 60 64
alias tty-ldisc-11 irtty alias char-major-60 ircomm_tty
irattach /dev/ttyS0 # (IrDA port in SIR mode)
irmanager
<ABORT stuff> "" \d\d\d\d\d\dATZE0 OK ATD<phone number to call) CONNECT \d\c
noauth connect "/usr/sbin/chat -v -f /etc/chatscripts/sh888" /dev/ircomm 115200 defaultroute noipdefault user <your username> # don't forget to add your password to chap secrets or chat script
A few seconds (app. 30) after executing pppd call sh888 I get connected to our Intranet/Internet having full IP connectivity (telnet, ftp, www, icmp tested). Futhermore I can connect to /dev/ircomm using minicom and play with AT command. Great! And looks stable!
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 "Windows software modem" (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 : "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 http://multivac.fatburen.org/gnokii/ , WH), but it doesn't work. As I have Nokia Data Suite I did the following connection:
Nokia 6110 <-- Nokia Cable --> PC/Linux <-- Null-modem cable --> PC/W95
In the PC/Linux I run the program snooper (by Jun-ichiro itojun Itoh <itojun@mt.cs.keio.ac.jp>, sorry couldn't find an URL maybe some other sniffer will do it also, e.g. sniffit, see also appendiy about serial sniffers, WH) with small modifications in order to configure the serial port correctly.
Normally, if snooper 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:
0>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>1: UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUUUUUUUUUUUU\x1e\x00\x0c\x02\x00\x09\x00\x01\x00\x0d\x00\x00\x02\x01@\x00P\x 06 1>0: \x18\x00\x00\x00\xfc\x18\x00\x00\x00\x00\x00\x00\xc0\xf0 0>1: \x1e\x00\x0c\x02\x00\x09\x00\x01\x00\x0d\x00\x00\x02\x01@\x00P\x06 1>0: \x18\x00\x00\x00\x18\x00\x00\xc0\xf0\x18\x00\x00\x00\x00\x00\x00\xc0\xf0 0>1: \x1e\x00\x0cd\x00\x06\x00\x01\x00\x10\x01`\x13\x13 1>0: \x18\x00\x00\xf0\x00\x00\xfc 0>1: \x1e\x00\x0cd\x00\x06\x00\x01\x00\x10\x01`\x13\x13
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 snooper. This probably has to do with some IrDA protocol used with also with the infrared connection."
Wessel de Roode <J.W.deRoode@student.utwente.nl> "I manged to get the Discovery IR hint bits (with my Palm Pilot):
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
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 IrDA:<dunno>:PNP:Comp#01 The same query with IrDA:<dunno>:PNP:CompCnt gives the number of PNP-devices are available in the Nokia. Which is here only one."
Maybe it is necessary to load the irlpt_server module for connections to a NOKIA.
Markus Schill wrote: "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:
insmod irda insmod irtty irattach /dev/cua0
There are two programs for linux available that can be used for the communication with the camera via cable: (1) chotplay and (2) stillgrab. 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. "
Dag Brattli wrote: "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 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. "
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
http://www.microsoft.com/windows95/info/irda.htm you will find a support pack "Infrared Transfer 2.0". It is a self-extracting archive W95IR.EXE with 331KB. Note: MicroSoft seems to change the location of this file (and others) at random.
Microsoft(tm) has three versions of IrDA support for Windows95. The version number can be found in the "Software" icon in the Control Panel and the file infrared.inf.
Version 1.0 is still delivered with some hardware.
Version 2.0 is the version they currently offer at their web site. It is in the self-extracting file W95IR.EXE. The last time I looked (1999-02-21) it was 434KB and was found at http://support.microsoft.com/download/support/mslfiles/W95IR.EXE . Their website is frequently changing, so do not be surprised to find the file (also) in another location or not at all.
Version 3.0 can/could be found in their downloadable Infrared development kit IRDDK30, but is mostly useful for developers. It is internally different from 2.0, it is based on "miniport" network drivers, just like the Linux version. It exists for some time and has some support for NT, but it clearly did not make it into the mainstream NT4.0 distributions. For 95 you are probably better off with 2.0. The choice may depend on the documentation of the drivers you get with your specific hardware.
MS website also used to contain a nice utility IrXfer, contained in the archive IRXFER.EXE, This is the Infrared Transfer utility, which uses an IrOBEX variant I think, it is referenced in the IrOBEX protocol description. The utility was freely downloadable, but I could not find it the last time. It is a nice graphical utility which can be used to transfer files over IrDA between computers.
With some machines, e.g. a HP Omnibook 800 it is necessary to use a vendor specific version of this package (for the HP Omnibook 800 you may find it on the recovery CD).
Especially the ..\windows\inf\*.inf files and the device manager are of interest to look for configuration details.
As far as I know Window$NT doesn't support IrDA(TM). About Window$98 I have heard there is no IrDA(TM) support yet. Countersys on http://www.countersys.com claims to sell an IrDA solution for NT4.0 to support their JetBeam product, Microsoft refers to them for it.
AFAIK:
There are also some non M$ products available. Note: Some of them use proprietary infrared protocols:
I suppose there are four ways to connect Linux/IrDA and Window$95:
1) A network connection between two PC's. If you have set up Infrared Transfer 2.0, you will find an IrDA(TM) network device in the <Network Device Section>. 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 workgroup model. I have had success with IrLAN DIRECT mode when I removed the COMPUTER 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 network adapter driver named Microsoft IrDA Lan Driver (you can also do this beforehand). You now should have a new active network driver which can be seen with WINIPCFG. 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 WINIPCFG 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:
a. write a proper /etc/sysconfig/network/irlan-up script.
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).
c. Make the Microsoft IrDA Lan Driver install automatically, maybe this is a problem in the PnP configuration. This seemed to work better on Windows98.
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 IrOBEX protocol. 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 <thiguchi@pluto.dti.ne.jp> provided IrCOMM support. From his page at http://www.pluto.dti.ne.jp/~thiguchi/irda/ I have taken the following description (I have modified it at little): "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:
alias char-major-60 ircomm_tty
mknod /dev/irnine c 161 0. Now Linux/IrDA services can be started as usual with irattach /dev/ttyS? &. /dev/irnine can be used as a serial device. ircomm and ircomm_tty modules will be loaded automatically by kerneld/kmod when a program uses /dev/irnine. NOTE: I think "setserial" utility will not work on /dev/irnine. Tips:
T1:23:respawn:/sbin/getty -L -w irnine 38400 vt100
init q. And init will start waiting for incoming IrCOMM connection. You will see your favorite Linux's login prompt from terminal emulator on Win95!pppd, please consider the -crtscts option to disable flow-control. I implemented some flow-control emulation but it is not tested.Sep 4 10:01:02 monolith kernel: parse_control:instruction(0x12) Sep 4 10:01:02 monolith kernel: data:03
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.
There should be three ways to get two Linux machines connected via Linux/IrDA.
load_misc irobex at both ends, and then try iroabex_app get on one of the machines and irobex put <file> on the other.".irlan_client at one machine and irlan_server at the other one.minicom, pppd, etc. If you want just now to use IrCOMM between Linux boxes, please add this line to /etc/conf.modules of _one_ box:
# set ircomm protocol engine to client-only mode options ircomm ircomm_cs=1
options ircomm ircomm_cs=1 to /etc/conf.modules anymore. Please remove it if you are using it.
Please note this feature is still quite experimental! Dag Brattli wrote: "Just wanted you to know I have just added COMPRESSION support to IrLAP! As you may know, this is _not_ part of the IrDA(TM) standard, but Linux can now negotiate with its peer and check if it has the same compression capabilities). So obviously if you are talking to Win95, Palm III or whatever, you will _not_ get compression!!! This is something which is exclusive for Linux as far as I know! The IrDA(TM) standard says that devices should ignore unknown field in the negotiation header, so we are still "compatible" with IrDA(TM) (have just borrowed an unused header value).
If you want to try using the compression code (Linux <-> Linux) you will have to insert the irda_deflate module some time before you actually make the connection. I do it before irattach.
The compression standard I have added is the deflate format used by the zlib library which is described by RFCs (Request for Comments) 1950 to 1952 in the files ftp://ds.internic.net/rfc/rfc1950.txt (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format).
The compression interface is similar to PPP, so you can add as many different compressors as you want. Currently there is only support for GZIP, but BSD compression will be added later. ... Have just tested GZIP compression at 4Mbps. It was a really bad idea! Compressing the frames takes so much time that the performance is actually worse than when not using compression at all. The conclusion is that compression should only be used for SIR speeds, ..."
Dag Brattli wrote: "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 irattach for each of the IR ports you have like this:
irattach /dev/ttyS0 & (my ESI dongle) irattach /dev/ttyS2 & (my builtin IrDA port) insmod irlan_client insmod irobex
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.
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."
Dag Brattli: "Connection to the Tekram IRDocking IR-660
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 gpm -t ps2 /dev/irkbd and the laptop will make a keyboard/mouse connection to the IR-660. Now I just have to make gpm read both /dev/psaux and /dev/irkbd, and then make X11 read /dev/gpmdata, and I should have the thing configured!
... one problem: gpm can handle multiple mice, but Linux cannot handle multiple different keyboards. So if you have one norwegian keyboard and one remote 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 real support for multiple keyboards, so I'll check that out.
... OK, I sort of worked it out. By using TIOCSTI on /dev/console, 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 :-)
... 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 "P1248" class and "IrDA:TinyTP:LsapSel" 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 "IrLPT" class with the "IrDA:TinyTP:LsapSel" in the LM-IAS and see if you can find it."
The Linux/IrDA keyboard driver is now in user-space. Please see chapter Connection to Docking Station above.
Lichen Wang: "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 physical encoding/decoding and the software protocol 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."
For some reasons it may be useful to connect via serial cable instead of using a real infrared link. Bjorn Hanson wrote: "Using a cable, I managed to get a PPP connection through my Ericsson SH888. I did the following (maybe some steps are wrong but they worked for me :-)
alias tty-ldisc-11 irtty to /etc/conf.modules/dev/ttyS0insmodirmanager -d1kppp using /dev/irnine (through symlink /dev/modem)stty < /dev/irnineping thehostifconfig irda0 downAnother way by Claudiu Costin <claudiuc@calderon.pcnet.ro>:
modprobe actisys<irattach /dev/ttyS1 -d actisys where COM2 is used for null linkirmanagerping <address> work very good!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.
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.