From A.M.Vollebregt@research.kpn.com Wed, 01 Dec 1999 10:11:44 +0100
Date: Wed, 01 Dec 1999 10:11:44 +0100
From: Vollebregt, A.M. A.M.Vollebregt@research.kpn.com
Subject: [Linux-IrDA]Q: Connecting a Palm to Linux - IP and PPP

Hi,

I wanted the same thing and have mostly the same configuration (same kernel,
patches and util). It works for me. I use a Girbil as dongle. The only big
difference is that I use dongle_attach to attach my dongle. Perhaps you have
forgotten that?
dongle_attach <device> -d <dongle>

Arjen Vollebregt
Systems Integration and Application for Multimedia
KPN Research




> -----Original Message-----
> From: Per Wallner (QRA) [mailto:Per.Wallner@era.ericsson.se]
> Sent: dinsdag 30 november 1999 13:14
> To: 'linux-irda@pasta.cs.uit.no'
> Subject: [Linux-IrDA]Q: Connecting a Palm to Linux - IP and PPP
> 
> 
> Hi,
> I already did this way back, but now it all seems new and 
> mysterious again... ;)
> 
> Here's the scope:
> I want to connect a Palm III/V (or Ericsson MC218) IP-wise to 
> a linux box. The 
> Palm uses ppp, and I've got a JetEye PC 9680 dongle. I simply 
> want the Palm
> (or whatever) to be an IP device, using the Linux box as a 
> network connection point.
> 
> Setup:
> RedHat 6.1, 2.2.13 kernel, patch-2.2.13-irda7 and irda-utils-0.9.5
> 
> I've created device files as:
> crw-r--r--   1 root     root     161,   0 Nov 29 15:27 /dev/ircomm0
> crw-r--r--   1 root     root     161,   1 Nov 29 15:27 /dev/ircomm1
> crw-r--r--   1 root     root     161,  16 Nov 29 15:28 /dev/irlpt0
> crw-r--r--   1 root     root     161,  17 Nov 29 15:28 /dev/irlpt1
> crw-r--r--   1 root     root      60,  64 Nov 30 09:06 /dev/irnine
> 
> My conf.modules contains:
> alias tty-ldisc-11   irtty
> alias char-major-161 ircomm-tty
> 
> 
> I load various modules, and start irmanager:
> /sbin/modprobe ircomm-tty
> /sbin/modprobe irtty
> /sbin/modprobe esi
> /sbin/modprobe ppp
> /usr/sbin/irmanager -d 1
> 
> This gives the following messages, which looks pretty much OK:
> 
> Nov 30 12:23:47 gal kernel: IrDA (tm) Protocols for Linux-2.2 
> (Dag Brattli) 
> Nov 30 12:23:47 gal kernel: IrCOMM protocol (Dag Brattli) 
> Nov 30 12:23:47 gal irmanager: executing: 'echo 1 > 
> /proc/sys/net/irda/discovery'
> Nov 30 12:23:47 gal irmanager: executing: 'echo gal > 
> /proc/sys/net/irda/devname'
> Nov 30 12:23:47 gal irmanager: + 1.1 Tue Nov  9 15:30:55 1999 
> Dag Brattli
> Nov 30 12:23:47 gal irattach: Serial connection established.
> Nov 30 12:23:47 gal kernel: IrDA: Registered device irda0 
> Nov 30 12:23:47 gal irmanager: + 1.1 Tue Nov  9 15:30:55 1999 
> Dag Brattli
> Nov 30 12:23:48 gal irattach: executing: 'echo gal > 
> /proc/sys/net/irda/devname'
> Nov 30 12:23:48 gal irattach: Using device: irda0 
> 
> I start pppd with:
> pppd /dev/ircomm1 <speed> 192.168.0.1:192.168.0.100 passive 
> silent persist noauth local nodetach
> where I've tried speeds btwn 9600 and 115200.
> 
> This gives me:
> Nov 30 12:27:18 gal pppd[912]: pppd 2.3.10 started by root, uid 0
> Nov 30 12:27:18 gal pppd[912]: Using interface ppp0
> Nov 30 12:27:18 gal pppd[912]: Connect: ppp0 <--> /dev/ircomm1
> 
> An lsmod gives me this:
> 
> Module                  Size  Used by
> esi                      760   1 
> irtty                   7164   2 
> ircomm-tty             29080   1 
> ircomm                 13116   0  [ircomm-tty]
> irda                  134465   2  [esi irtty ircomm-tty ircomm]
> ppp                    20684   1 
> slhc                    4300   0  [ppp]
> 
> At this stage, the LED on the dongle is happily blinking. 
> However, there's no way
> I can get the Palm (or MC) to connect.
> 
> I'm sure I've omitted some detail (or several...), and I'm stuck.
> What have I missed?
> Do I have to set serial speed some place? How does the ppp 
> interface connect to
> the serial port?
> 
> I really would appreciate if someone could shed some light on 
> this - I'm
> lost in darkness ;(
> 
> TIA, Best regards
> Per Wallner
> 
> 
> 
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
> 




From jeant@rockfort.hpl.hp.com Wed, 1 Dec 1999 17:57:51 -0800
Date: Wed, 1 Dec 1999 17:57:51 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]New Actisys 220L/220L+ Linux driver

	Hi everybody...

	A few weeks ago, I was complaining that the timming in the
Actisys dongle driver in Linux IrDA were absurd. Today I received my
batch of Actisys dongle, and guess what, I could not make it work with
Linux IrDA.
	So, I wiped out the initialisation code and the code to change
speed in the old driver and replaced it with something simpler, faster
and more robust. I have to thanks Lichen Wang from Actisys who sent me
a nice e-mail detailing the secret of their dongle.
	Anyway, the result is a new dongle driver that work for me.
	Enjoy...

	Jean

--------------------------------------------------
/*********************************************************************
 *                
 * Filename:      actisys.c
 * Version:       0.9999
 * Description:   Implementation for the ACTiSYS IR-220L and IR-220L+ 
 *                dongles
 * Status:        Beta.
 * Authors:       Dag Brattli <dagb@cs.uit.no> (initially)
 *		  Jean Tourrilhes <jt@hpl.hp.com> (new version)
 * Created at:    Wed Oct 21 20:02:35 1998
 * Modified at:   1/12/99
 * Modified by:   Jean
 * 
 *     Copyright (c) 1998-1999 Dag Brattli, All Rights Reserved.
 *     Copyright (c) 1999 Jean Tourrilhes
 *      
 *     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 Dag Brattli nor University of Tromsø admit liability nor
 *     provide warranty for any of this software. This material is 
 *     provided "AS-IS" and at no charge.
 *     
 ********************************************************************/

/*
 * Changelog
 *
 * 0.8 -> 0.9999 - Jean
 *	o New initialisation procedure : much safer and correct
 *	o New procedure the change speed : much faster and simpler
 *	o Other cleanups & comments
 *	Thanks to Lichen Wang @ Actisys for his excellent help...
 */

#include <linux/module.h>
#include <linux/delay.h>
#include <linux/tty.h>
#include <linux/sched.h>
#include <linux/init.h>

#include <net/irda/irda.h>
#include <net/irda/irmod.h>
#include <net/irda/irda_device.h>

/*
 *	Define the timing of the pulses we send to the dongle (to reset
 * it, and to toggle speeds).
 *	Basically, the limit here is the propagation speed of the
 * signals through the serial port, the dongle being much faster.
 *	Any serial port support 115 kb/s, so we are sure that pulses
 * 8.5 us wide can go through cleanly .
 *	If you are on the wild side, you can try to lower this value
 * (Actisys recommended me 2 us, and 0 us work for me on a P233 !!!)
 */
#define MIN_DELAY 10	/* 10 us to be on the conservative side */

static int  actisys_change_speed(struct irda_task *task);
static int  actisys_reset(struct irda_task *task);
static void actisys_open(dongle_t *self, struct qos_info *qos);
static void actisys_close(dongle_t *self);

/* These are the baudrates supported, in the order available */
/* Note : the 220L doesn't support 38400, but we will fix that below */
static __u32 baud_rates[] = { 9600, 19200, 57600, 115200, 38400 };

static struct dongle_reg dongle = {
	Q_NULL,
	IRDA_ACTISYS_DONGLE,
	actisys_open,
	actisys_close,
	actisys_reset,
	actisys_change_speed,
};

static struct dongle_reg dongle_plus = {
	Q_NULL,
	IRDA_ACTISYS_PLUS_DONGLE,
	actisys_open,
	actisys_close,
	actisys_reset,
	actisys_change_speed,
};

/*
 * Function actisys_change_speed (task)
 *
 *	There is two model of Actisys dongle we are dealing with,
 * the 220L and 220L+. At this point, only irattach knows with
 * kind the user has requested (it was an argument on irattach
 * command line).
 *	So, we register a dongle of each sort and let irattach
 * pick the right one...
 */
int __init actisys_init(void)
{
	int ret;

	/* First, register an Actisys 220L dongle */
	ret = irda_device_register_dongle(&dongle);
	if (ret < 0)
		return ret;
	/* Now, register an Actisys 220L+ dongle */
	ret = irda_device_register_dongle(&dongle_plus);
	if (ret < 0) {
		irda_device_unregister_dongle(&dongle);
		return ret;
	}	
	return 0;
}

void actisys_cleanup(void)
{
	/* We have to remove both dongles */
	irda_device_unregister_dongle(&dongle);
	irda_device_unregister_dongle(&dongle_plus);
}

static void actisys_open(dongle_t *self, struct qos_info *qos)
{
	/* Power on the dongle */
	self->set_dtr_rts(self->dev, TRUE, TRUE);

	/* Set the speeds we can accept */
	qos->baud_rate.bits &= IR_9600|IR_19200|IR_38400|IR_57600|IR_115200;

	/* Remove support for 38400 if this is not a 220L+ dongle */
	if (self->issue->type == IRDA_ACTISYS_DONGLE)
		qos->baud_rate.bits &= ~IR_38400;
	
	qos->min_turn_time.bits &= 0x40; /* Needs 0.01 ms */

	MOD_INC_USE_COUNT;
}

static void actisys_close(dongle_t *self)
{
	/* Power off the dongle */
	self->set_dtr_rts(self->dev, FALSE, FALSE);

	MOD_DEC_USE_COUNT;
}

/*
 * Function actisys_change_speed (task)
 *
 *    Change speed of the ACTiSYS IR-220L and IR-220L+ type IrDA dongles.
 *    To cycle through the available baud rates, pulse RTS low for a few us.
 *
 *	First, we reset the dongle to always start from a known state.
 *	Then, we cycle through the speeds by pulsing RTS low and then up.
 *	The dongle allow us to pulse quite fast, se we can set speed in one go,
 * which is must faster ( < 100 us) and less complex than what is found
 * in some other dongle drivers...
 *	Note that even if the new speed is the same as the current speed,
 * we reassert the speed. This make sure that things are all right,
 * and it's fast anyway...
 *	By the way, this function will work for both type of dongles,
 * because the additional speed is at the end of the sequence...
 */
static int actisys_change_speed(struct irda_task *task)
{
	dongle_t *self = (dongle_t *) task->instance;
	__u32 speed = (__u32) task->param;	/* Target speed */
        int index = 0;
	int ret = 0;
	
        IRDA_DEBUG(4, __FUNCTION__ "(), speed=%d (was %d)\n",
		   speed, self->speed);

	/* Go to a known state by reseting the dongle */

	/* Reset the dongle : set DTR low for 10 us */
	self->set_dtr_rts(self->dev, FALSE, TRUE);
	udelay(MIN_DELAY);

	/* Go back to normal mode (we are now at 9600 b/s) */
	self->set_dtr_rts(self->dev, TRUE, TRUE);
 
	/* Now, we can set the speed requested */

	/* Send RTS pulses until we reach the target speed */
	while((index < 5) && (speed != baud_rates[index++]))
	{
		/* Make sure previous pulse is finished */
		udelay(MIN_DELAY);

		/* Set RTS low for 10 us */
		self->set_dtr_rts(self->dev, TRUE, FALSE);
		udelay(MIN_DELAY);

		/* Set RTS high for 10 us */
		self->set_dtr_rts(self->dev, TRUE, TRUE);
	}

	/* Check if life is sweet... */
	if(speed != baud_rates[index])
		ret = -1;	/* This should not happen */
	self->speed = baud_rates[index];	/* Do we care ? */

	/* Basta lavoro, on se casse d'ici... */
	irda_task_next_state(task, IRDA_TASK_DONE);

	return ret;
}

/*
 * Function actisys_reset (task)
 *
 *      Reset the Actisys type dongle. Warning, this function must only be
 *      called with a process context!
 *
 * We need to do two things in this function :
 *	o first make sure that the dongle is in a state where it can operate
 *	o second put the dongle in a know state
 *
 *	The dongle is powered of the RTS and DTR lines. In the dongle, there
 * is a big capacitor to accomodate the current spikes. This capacitor
 * takes a least 50 ms to be charged. In theory, the Bios set those lines
 * up, so by the time we arrive here we should be set. It doesn't hurt
 * to be on the conservative side, so we will wait...
 *	Then, we set the speed to 9600 b/s to get in a known state (see in
 * change_speed for details). It is needed because the IrDA stack
 * has tried to set the speed immediately after our first return,
 * so before we can be sure the dongle is up and running.
 */
static int actisys_reset(struct irda_task *task)
{
	dongle_t *self = (dongle_t *) task->instance;
	int ret = 0;

	ASSERT(task != NULL, return -1;);

	self->reset_task = task;

	switch (task->state) {
	case IRDA_TASK_INIT:
		/* Set both DTR & RTS to power up the dongle */
		/* In theory redundant with power up in actisys_open() */
		self->set_dtr_rts(self->dev, TRUE, TRUE);
		
		/* Sleep 50 ms to make sure capacitor is charged */
		ret = MSECS_TO_JIFFIES(50);
		irda_task_next_state(task, IRDA_TASK_WAIT);
		break;
	case IRDA_TASK_WAIT:			
		/* Reset the dongle : set DTR low for 10 us */
		self->set_dtr_rts(self->dev, FALSE, TRUE);
		udelay(MIN_DELAY);

		/* Go back to normal mode */
		self->set_dtr_rts(self->dev, TRUE, TRUE);
	
		irda_task_next_state(task, IRDA_TASK_DONE);
		self->reset_task = NULL;
		self->speed = 9600;	/* That's the default */
		break;
	default:
		ERROR(__FUNCTION__ "(), unknown state %d\n", task->state);
		irda_task_next_state(task, IRDA_TASK_DONE);
		self->reset_task = NULL;
		ret = -1;
		break;
	}
	return ret;
}

#ifdef MODULE
MODULE_AUTHOR("Dag Brattli <dagb@cs.uit.no> - Jean Tourrilhes <jt@hpl.hp.com>");
MODULE_DESCRIPTION("ACTiSYS IR-220L and IR-220L+ dongle driver");	
		
/*
 * Function init_module (void)
 *
 *    Initialize Actisys module
 *
 */
int init_module(void)
{
	return actisys_init();
}

/*
 * Function cleanup_module (void)
 *
 *    Cleanup Actisys module
 *
 */
void cleanup_module(void)
{
	actisys_cleanup();
}
#endif /* MODULE */




From bl@physics.dcu.ie Thu, 2 Dec 1999 09:49:15 +0000 (GMT)
Date: Thu, 2 Dec 1999 09:49:15 +0000 (GMT)
From: Brian Lawless bl@physics.dcu.ie
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

> 
> Hi,
> 
> I've found a very nice PDF file on http://mobileinternet.ericsson.se 
> describing the AT commands of the SH888, 

Yes this is a nice file but it is incorrect.
Page 152 gives a dial example with the SH888
ATD0705865975
This does not work. A  ; (semicolon) is required after the
number to cause  a dialling action but the software built
into the Ericsson SH888 then dials and switches the phone
back to voice mode. It is therefore impossible to 
use the SH888 as a straightforward modem. I fail to see the
necessity for this software block.   
As a result, the rest of the information in page 152 of the 
888 AT Online Reference Manual   is incorrect. See also page
89 of the manual.
On the other hand the older GS18 from Ericsson does work as a
straightforward Hayes Type modem. I cannot understand why
Ericsson did not retain the older functionality in the 888.
Regards,
Brian Lawless.
but the Motorola L7089 seems like
> a _very_ nice phone. Unfortunately Motorola tech-support says even they
> don't know of any documentation of the L7089 AT commands. Maybe this list
> knows more about Motorola phones than Motorola? :)
> 
> Anybody knows wher the L7089 AT commands can be found?
> 
> Thanx,
> Peter
> 
> 
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
> 


-- 

==============================================================
Brian Lawless                        tel :- +353-1-7045300
School of Physical Sciences          fax :- +353-1-7045384
Dublin City University                  
Dublin 9                          email :- bl@physics.dcu.ie
Ireland
==============================================================




From soruk@eridani.demon.co.uk Thu, 2 Dec 1999 11:22:57 +0000 (GMT)
Date: Thu, 2 Dec 1999 11:22:57 +0000 (GMT)
From: Michael McConnell soruk@eridani.demon.co.uk
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

> but the Motorola L7089 seems like
> > a _very_ nice phone. Unfortunately Motorola tech-support says even they
> > don't know of any documentation of the L7089 AT commands. Maybe this list
> > knows more about Motorola phones than Motorola? :)
> > 
> > Anybody knows wher the L7089 AT commands can be found?

I've got one of these things... and know a few of the commands. What
AT-command functions are you looking for?

-- Michael "Soruk" McConnell                      [Eridani Linux 6.1A Now!]
Eridani Linux  --  The Most Up-to-Date Red Hat-based Linux CDROMs Available
Email: linux@eridani.co.uk  http://www.eridani.co.uk   Fax: +44-8701-600807





From mtepperis@pdv-online.de Thu, 2 Dec 1999 13:37:39 +0100
Date: Thu, 2 Dec 1999 13:37:39 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

hi Michael,



>> > Anybody knows wher the L7089 AT commands can be found?
>
>I've got one of these things... and know a few of the commands. What
>AT-command functions are you looking for?


that is very interesting for me too.

I own a motorola L6089. may be the commands are the same.
Do you have infos about the communication protocol for configuration
etc. too?

greetings
  michael





From soruk@eridani.demon.co.uk Thu, 2 Dec 1999 12:54:45 +0000 (GMT)
Date: Thu, 2 Dec 1999 12:54:45 +0000 (GMT)
From: Michael McConnell soruk@eridani.demon.co.uk
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

On Thu, 2 Dec 1999, Michael Tepperis wrote:

> hi Michael,
> 
> >>> Anybody knows wher the L7089 AT commands can be found?
> >
> >I've got one of these things... and know a few of the commands. What
> >AT-command functions are you looking for?
> 
> that is very interesting for me too.
> 
> I own a motorola L6089. may be the commands are the same.
> Do you have infos about the communication protocol for configuration
> etc. too?

I've not heard of the L6089. I just use IRCOMM with irtty to talk to it.

The AT commands I use (since Orange now allow 14k4 connections):
AT+CBST=14,0,1 (for an analogue modem line)
AT+CBST=75,0,1 (for a digital line - Demon's 3COM ISDN line supports this,
                and Orange tell me the 0973100666 number soon will.)

Than I just do an ordinary ATDT<number> command.

-- Michael "Soruk" McConnell                      [Eridani Linux 6.1A Now!]
Eridani Linux  --  The Most Up-to-Date Red Hat-based Linux CDROMs Available
Email: linux@eridani.co.uk  http://www.eridani.co.uk   Fax: +44-8701-600807





From stuge@cdy.org Thu, 2 Dec 1999 16:20:30 +0100 (CET)
Date: Thu, 2 Dec 1999 16:20:30 +0100 (CET)
From: Peter Stuge stuge@cdy.org
Subject: [Linux-IrDA]Re: VLSI-VL82C147

On 23 Nov 1999, Dag Brattli wrote:

>VLSI chipset when there are so few people using it. It would really be much 
>more important if I got the SMC or NCS '338 chips working. That would cover 
>almost 95% of all laptops out there.
..what's the status on that SMC btw?  I'm back from Germany and a bit more
available for coding and testing again.

Btw: I got my 8810 back, now with a new software revision.  (Dunno how to
check which, though.  Anyone?)

I'm running 2.2.13irda4.

I get mixed results when I try to IrCOMM against the newer rev. software in my
phone; at first I had some problems, but now when I wanted to reproduce to get
exact debug messages and the oops(es) all of it (of course) works like a
charm.

What I did to get errors and malfunction was:
I set up everything like before, load modules, start irmanager and so on.
Then I start minicom, wait a sec. or three and THEN type AT and get OK.
I exit minicom and start pppd within one (1) second or maybe less, then chat
works as well, along with surfing over the PPP link.

If I start pppd without first having ran minicom, I get the error message
ir<dunremember-and-can't-reproduce>(), busy with a previous query
repeatedly, and no go IrCOMM.
Also, if I kill off pppd or kill/suspend minicom while it is trying to close
the port after I've exited the program when having typed a couple of chars
quickly before the port was completely opened, I got an oops.  I've gotten
oops 0 and 2 afairemember.

Of course, <dunremember-and-can't-reproduce> is what's interesting, all I can
remember is that it contained 'state'..  Sorry.

//Peter

--
irc: CareBear\    tel: +46-40-914420
irl: Peter Stuge  gsm: +46-705-783805





From stuge@cdy.org Thu, 2 Dec 1999 16:32:17 +0100 (CET)
Date: Thu, 2 Dec 1999 16:32:17 +0100 (CET)
From: Peter Stuge stuge@cdy.org
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

On Thu, 2 Dec 1999, Brian Lawless wrote:

>> I've found a very nice PDF file on http://mobileinternet.ericsson.se 
>> describing the AT commands of the SH888, 
>Yes this is a nice file but it is incorrect.
>Page 152 gives a dial example with the SH888
>ATD0705865975
>This does not work. A  ; (semicolon) is required after the
>number to cause  a dialling action but the software built
>into the Ericsson SH888 then dials and switches the phone
>back to voice mode. It is therefore impossible to 
>use the SH888 as a straightforward modem. I fail to see the
>necessity for this software block.   
I had an idea here.
What number are you calling when using the ; ?
Is it a real data number, ie. does a modem pick up the line?
And, what does the SH888 reply to your ATD command (without ';') ?

//Peter

--
irc: CareBear\    tel: +46-40-914420
irl: Peter Stuge  gsm: +46-705-783805





From james@esc.cam.ac.uk Thu, 2 Dec 1999 16:01:00 GMT
Date: Thu, 2 Dec 1999 16:01:00 GMT
From: James james@esc.cam.ac.uk
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

I have sucessfully used an SH888 to dial a modem in england using vodaphone
merely by typing.

ATDT01223360314

with no semicolon,

James.






From dagb@cs.uit.no 02 Dec 1999 12:01:25 +0100
Date: 02 Dec 1999 12:01:25 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]New Actisys 220L/220L+ Linux driver

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Hi everybody...
> 
> 	A few weeks ago, I was complaining that the timming in the
> Actisys dongle driver in Linux IrDA were absurd. Today I received my
> batch of Actisys dongle, and guess what, I could not make it work with
> Linux IrDA.
> 	So, I wiped out the initialisation code and the code to change
> speed in the old driver and replaced it with something simpler, faster
> and more robust. I have to thanks Lichen Wang from Actisys who sent me
> a nice e-mail detailing the secret of their dongle.
> 	Anyway, the result is a new dongle driver that work for me.
> 	Enjoy...
> 
> 	Jean

Very nice!! Since I don't have this dongle yet, I trust your new code and
have applied your changes. 

BTW: Right now I'm fixing the stack for the QoS settings at lower speeds,
so I hope you haven't thrown away your old dongle yet ;-)

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 02 Dec 1999 12:01:25 +0100
Date: 02 Dec 1999 12:01:25 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]New Actisys 220L/220L+ Linux driver

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Hi everybody...
> 
> 	A few weeks ago, I was complaining that the timming in the
> Actisys dongle driver in Linux IrDA were absurd. Today I received my
> batch of Actisys dongle, and guess what, I could not make it work with
> Linux IrDA.
> 	So, I wiped out the initialisation code and the code to change
> speed in the old driver and replaced it with something simpler, faster
> and more robust. I have to thanks Lichen Wang from Actisys who sent me
> a nice e-mail detailing the secret of their dongle.
> 	Anyway, the result is a new dongle driver that work for me.
> 	Enjoy...
> 
> 	Jean

Very nice!! Since I don't have this dongle yet, I trust your new code and
have applied your changes. 

BTW: Right now I'm fixing the stack for the QoS settings at lower speeds,
so I hope you haven't thrown away your old dongle yet ;-)

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From flo@rfc822.org Thu, 2 Dec 1999 19:35:24 +0100
Date: Thu, 2 Dec 1999 19:35:24 +0100
From: Florian Lohoff flo@rfc822.org
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

On Thu, Dec 02, 1999 at 12:54:45PM +0000, Michael McConnell wrote:
> I've not heard of the L6089. I just use IRCOMM with irtty to talk to it.
> 
> The AT commands I use (since Orange now allow 14k4 connections):
> AT+CBST=14,0,1 (for an analogue modem line)
> AT+CBST=75,0,1 (for a digital line - Demon's 3COM ISDN line supports this,
>                 and Orange tell me the 0973100666 number soon will.)

Its the same as the ATBnn on the S25 - It selects the type of call

V.32 9600 Analog or
V.110 Bitrate Adaption ISDN

3Com does support V.110 same as Linux. Ascend doesnt support V.110 
per default, you need special Cards in the MAXes which nearly nobody
has.

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5241-470566
  ...  The failure can be random; however, when it does occur, it is
  catastrophic and is repeatable  ...             Cisco Field Notice





From soruk@eridani.demon.co.uk Thu, 2 Dec 1999 18:53:50 +0000 (GMT)
Date: Thu, 2 Dec 1999 18:53:50 +0000 (GMT)
From: Michael McConnell soruk@eridani.demon.co.uk
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

On Thu, 2 Dec 1999, Florian Lohoff wrote:

> On Thu, Dec 02, 1999 at 12:54:45PM +0000, Michael McConnell wrote:
> > I've not heard of the L6089. I just use IRCOMM with irtty to talk to it.
> > 
> > The AT commands I use (since Orange now allow 14k4 connections):
> > AT+CBST=14,0,1 (for an analogue modem line)
> > AT+CBST=75,0,1 (for a digital line - Demon's 3COM ISDN line supports this,
> >                 and Orange tell me the 0973100666 number soon will.)
> 
> Its the same as the ATBnn on the S25 - It selects the type of call
> 
> V.32 9600 Analog or
> V.110 Bitrate Adaption ISDN
> 
> 3Com does support V.110 same as Linux. Ascend doesnt support V.110 
> per default, you need special Cards in the MAXes which nearly nobody
> has.

...which is why I can't use Demon's 01xxx ISDN lines.. (they're served by
Ascend hardware).

What I'd like to know is, does the L7089 support compression a la V42bis?
If so, how? :)

-- Michael "Soruk" McConnell                      [Eridani Linux 6.1A Now!]
Eridani Linux  --  The Most Up-to-Date Red Hat-based Linux CDROMs Available
Email: linux@eridani.co.uk  http://www.eridani.co.uk   Fax: +44-8701-600807





From peterm@shinesoft.com Thu, 02 Dec 1999 12:49:32 -0800
Date: Thu, 02 Dec 1999 12:49:32 -0800
From: Peter Michalek peterm@shinesoft.com
Subject: [Linux-IrDA]Belkin OLD SmartBeam driver


Jean Tourrilhes wrote:
> 
>         Hi,
> 
>         While I was looking at dongle drivers, I created a driver for
> the OLD Belkin SmartBeam dongle. I can claim that this is the simplest
> and dumbest dongle driver ever written ;-)
>         Read source comments for details...
> 
>         Dag, would you be kind enough to stuff that in your next IrDA
> release ?
>         Thanks...
> 
>         Jean
> 
Jean,

Would this compile and work with 

kernel 2.2.10 + irda3?

Peter




From jeant@rockfort.hpl.hp.com Thu, 2 Dec 1999 14:14:16 -0800
Date: Thu, 2 Dec 1999 14:14:16 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Re: Belkin OLD SmartBeam driver (and dongle comments)

Peter wrote :
> Jean Tourrilhes wrote:
> > 
> >         While I was looking at dongle drivers, I created a driver for
> > the OLD Belkin SmartBeam dongle. I can claim that this is the simplest
> > and dumbest dongle driver ever written ;-)
>
> Jean,
> 
> Would this compile and work with 
> kernel 2.2.10 + irda3?
> 
> Peter

	I just did this driver for getting accustomed with dongle
driver. I would not recommend anybody to use this dongle (old
SmartBeam), because it is limited to 9.6 kb/s. The new SmartBeam does
115 kb/s, but is not supported by this driver.
	Moreover, it seems that Belkin has an upgrade program allowing
you to change you old SmartBeam to a new SmartBeam, see the FAQ on
their web site for details. It is true that the new dongle is not
supported under Linux-IrDA and seem to be still limited (SmartBeam to
SmartBeam is only 57 kb/s - no comment).

	Personally, I bought some Actisys 220L+, because they are some
very nice dongle (technically) and they are making a promotion for
Linux users (see previous e-mails on the list), and I'm very happy
with those.
	I tested as well a JetEye dongle (but now it's gone), and it
is very nice as well, but doesn't offer as many speeds, unless you
have the latest model (9680C) and use the litelink dongle driver. You
can find some cheap ones at EggHead or other places...
	The little light on top of the JetEye could have been a killer
feature, but as currently implemented it's almost useless. This light
should be off when nobody is in sight, blinking when a node has been
discovered and solid when a connection is established (like on the
NetBeamer), instead it just blinks stupidly all the time without
giving you any feedback and you don't know what's happening. Too
bad... This is this kind of user feedback oversight that give IrDA a
bad name.

	In sumary, this driver is only if you are desperate and stuck
with this hardware (old SmartBeam). At this point, I would not
recommend anyone to buy such a dongle, and if you have one use the
above exchange program and use it on you Win95 box.

	Comming back to your question : I believe that the dongle
interface did change significantly between 2.2.13 and
2.2.13-irda3. The kernel you are using (2.2.20-irda3) use the old
interface, and my driver use the new one, so it won't work.
	So, either you wait for 2.2.13-irda8 (which would integrate
this driver), or you can use 2.2.13-irda{3-7} and replace one dongle
driver with the code in my e-mail.

	Does it answer all your questions ?

	Jean




From jeant@rockfort.hpl.hp.com Thu, 2 Dec 1999 14:25:31 -0800
Date: Thu, 2 Dec 1999 14:25:31 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Re: New Actisys 220L/220L+ Linux driver

Dag wrote :
>
> Very nice!! Since I don't have this dongle yet, I trust your new code and
> have applied your changes. 

	The way it is now written, there is very little chances that
you can break it by changing the higher layers. So, I'm confident that
it will be ok.

> BTW: Right now I'm fixing the stack for the QoS settings at lower speeds,
> so I hope you haven't thrown away your old dongle yet ;-)

	Nope. In fact, I need to get this dongle to work as well, so I
will welcome your fix and I will test them.

> -- Dag

	Thanks for the good work !

	Jean




From peterm@shinesoft.com Thu, 02 Dec 1999 15:22:33 -0800
Date: Thu, 02 Dec 1999 15:22:33 -0800
From: Peter Michalek peterm@shinesoft.com
Subject: [Linux-IrDA]Re: Belkin OLD SmartBeam driver (and dongle comments)


Jean Tourrilhes wrote:
> 
> Peter wrote :
> > Jean Tourrilhes wrote:
> > >
> > >         While I was looking at dongle drivers, I created a driver for
> > > the OLD Belkin SmartBeam dongle. I can claim that this is the simplest
> > > and dumbest dongle driver ever written ;-)
> >
> > Jean,
> >
> > Would this compile and work with
> > kernel 2.2.10 + irda3?
> >
> > Peter
> 
>         I just did this driver for getting accustomed with dongle
> driver. I would not recommend anybody to use this dongle (old
> SmartBeam), because it is limited to 9.6 kb/s. The new SmartBeam does
> 115 kb/s, but is not supported by this driver.
>         Moreover, it seems that Belkin has an upgrade program allowing
> you to change you old SmartBeam to a new SmartBeam, see the FAQ on
> their web site for details. It is true that the new dongle is not
> supported under Linux-IrDA and seem to be still limited (SmartBeam to
> SmartBeam is only 57 kb/s - no comment).
> 
>         Personally, I bought some Actisys 220L+, because they are some
> very nice dongle (technically) and they are making a promotion for
> Linux users (see previous e-mails on the list), and I'm very happy
> with those.
>         I tested as well a JetEye dongle (but now it's gone), and it
> is very nice as well, but doesn't offer as many speeds, unless you
> have the latest model (9680C) and use the litelink dongle driver. You
> can find some cheap ones at EggHead or other places...
>         The little light on top of the JetEye could have been a killer
> feature, but as currently implemented it's almost useless. This light
> should be off when nobody is in sight, blinking when a node has been
> discovered and solid when a connection is established (like on the
> NetBeamer), instead it just blinks stupidly all the time without
> giving you any feedback and you don't know what's happening. Too
> bad... This is this kind of user feedback oversight that give IrDA a
> bad name.
> 
>         In sumary, this driver is only if you are desperate and stuck
> with this hardware (old SmartBeam). At this point, I would not
> recommend anyone to buy such a dongle, and if you have one use the
> above exchange program and use it on you Win95 box.
> 
>         Comming back to your question : I believe that the dongle
> interface did change significantly between 2.2.13 and
> 2.2.13-irda3. The kernel you are using (2.2.20-irda3) use the old
> interface, and my driver use the new one, so it won't work.
>         So, either you wait for 2.2.13-irda8 (which would integrate
> this driver), or you can use 2.2.13-irda{3-7} and replace one dongle
> driver with the code in my e-mail.
> 
>         Does it answer all your questions ?
> 
> > kernel 2.2.10 + irda3?
correction: I an using 2.2.12 + irda3

>         Does it answer all your questions ?
Yes, I think I'll use 2.2.13 pretty soon.

Peter




From jeant@rockfort.hpl.hp.com Fri, 3 Dec 1999 23:39:56 -0800
Date: Fri, 3 Dec 1999 23:39:56 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Unreliable service on TTP

	Hi everybody...

	I was wondering what was the status of unreliable connections
on top of TinyTP (chapt 2.2.4 of the spec). Boy, you should never ask
those kind of questions when you have nothing to do in the evening...
	With the following patch, I'm able to send and receive data
unreliably over the Ir link. In fact, it's so unreliable that if you
don't pace your message the IrDA stack goes kaputt.

	To use this service, just replace SOCK_STREAM by
SOCK_SEQPACKET in your application. As opposed to UDP, this is a
connected service, so you are supposed to use connect/listen-accept
before sending data. And also, as mentionned above, now flow control.
	IAS doesn't allow to distinguish the two type of services, so
you don't know what the application on the other end will
support. I've added the feature that a SOCK_STREAM app can exchange
data with a SOCK_SEQPACKET application.
	I did my best to read the spec and try to be logical, but I
didn't have the chance to see what other implementations are doing on
the subject...

	Dag : could you please have a look at this patch ? Also, you
could add a feature to the example in irda-utils/irsockets to select
the type of service you want...

	Have fun...

	Jean

----------------------------------------
--- af_irda.old.c	Fri Dec  3 14:19:01 1999
+++ af_irda.c	Fri Dec  3 16:08:57 1999
@@ -1,7 +1,7 @@
 /*********************************************************************
  *                
  * Filename:      af_irda.c
- * Version:       0.7
+ * Version:       0.7.1
  * Description:   IrDA sockets implementation
  * Status:        Experimental.
  * Author:        Dag Brattli <dagb@cs.uit.no>
@@ -23,6 +23,13 @@
  *     
  ********************************************************************/
 
+/*
+ * 0.7 -> 0.7.1 - Jean Tourrilhes
+ *	o Make SOCK_SEQPACKET sockets send unreliable frames
+ *	o Allow to listen and accept in SOCK_SEQPACKET sockets
+ *	o Allow to receive unreliable frames
+ */
+
 #include <linux/types.h>
 #include <linux/socket.h>
 #include <linux/sockios.h>
@@ -353,6 +360,7 @@ static int irda_open_tsap(struct irda_so
 	notify.connect_indication    = irda_connect_indication;
 	notify.disconnect_indication = irda_disconnect_indication;
 	notify.data_indication       = irda_data_indication;
+	notify.udata_indication	     = irda_data_indication;
 	notify.flow_indication       = irda_flow_indication;
 	notify.instance = self;
 	strncpy(notify.name, name, NOTIFY_MAX_NAME);
@@ -448,7 +456,8 @@ static int irda_listen(struct socket *so
 
 	IRDA_DEBUG(0, __FUNCTION__ "()\n");
 
-	if (sk->type == SOCK_STREAM && sk->state != TCP_LISTEN) {
+	if (((sk->type == SOCK_STREAM) || (sk->type == SOCK_SEQPACKET))
+	    && (sk->state != TCP_LISTEN)) {
 		sk->max_ack_backlog = backlog;
 		sk->state           = TCP_LISTEN;
 
@@ -530,7 +539,7 @@ static int irda_accept(struct socket *so
 	if ((sk = sock->sk) == NULL)
 		return -EINVAL;
 
-	if (sk->type != SOCK_STREAM)
+	if ((sk->type != SOCK_STREAM) && (sk->type != SOCK_SEQPACKET))
 		return -EOPNOTSUPP;
 
 	if (sk->state != TCP_LISTEN)
@@ -852,6 +861,12 @@ static int irda_sendmsg(struct socket *s
 	}
 
 	/* Check that we don't send out to big frames */
+	/* I'm not sure, but I believe that around here we should split
+	 * big frames into smaller chunk and perform coalesce on smaller
+	 * chunks to group them in bigger packets, as it is done
+	 * in 'tcp_do_sendmsg'...
+	 * As the service is reliable AND sequenced, the higher layer won't
+	 * see the difference and the performance will be better... */
 	if (len > self->max_data_size) {
 		IRDA_DEBUG(0, __FUNCTION__ "(), Warning to much data! "
 		      "Chopping frame from %d to %d bytes!\n", len, 
@@ -883,6 +898,71 @@ static int irda_sendmsg(struct socket *s
 }
 
 /*
+ * Function irda_sendmsg_dgram (sock, msg, len, scm)
+ *
+ *    Send message down to TinyTP for the unreliable sequenced
+ *    packet service...
+ *
+ */
+static int irda_sendmsg_dgram(struct socket *sock, struct msghdr *msg,
+			      int len, struct scm_cookie *scm)
+{
+	struct sock *sk = sock->sk;
+/* 	struct sockaddr_irda *addr = (struct sockaddr_irda *) msg->msg_name; */
+	struct irda_sock *self;
+	struct sk_buff *skb;
+	unsigned char *asmptr;
+	int err;
+
+	IRDA_DEBUG(4, __FUNCTION__ "(), len=%d\n", len);
+
+	if (msg->msg_flags & ~MSG_DONTWAIT)
+		return -EINVAL;
+
+	if (sk->shutdown & SEND_SHUTDOWN) {
+		send_sig(SIGPIPE, current, 0);
+		return -EPIPE;
+	}
+
+	if (sk->state != TCP_ESTABLISHED)
+		return -ENOTCONN;
+
+	self = sk->protinfo.irda;
+	ASSERT(self != NULL, return -1;);
+
+	/* Check that we don't send out to big frames */
+	/* Unreliable service : no fragmentation, no coalescence */
+	if (len > self->max_data_size) {
+		IRDA_DEBUG(0, __FUNCTION__ "(), Warning to much data! "
+		      "Chopping frame from %d to %d bytes!\n", len, 
+		      self->max_data_size);
+		len = self->max_data_size;
+	}
+
+	skb = sock_alloc_send_skb(sk, len + self->max_header_size, 0, 
+				  msg->msg_flags & MSG_DONTWAIT, &err);
+	if (!skb)
+		return -ENOBUFS;
+
+	skb_reserve(skb, self->max_header_size);
+	
+	IRDA_DEBUG(4, __FUNCTION__ "(), appending user data\n");
+	asmptr = skb->h.raw = skb_put(skb, len);
+	memcpy_fromiovec(asmptr, msg->msg_iov, len);
+
+	/* 
+	 * Just send the message to TinyTP, and let it deal with possible 
+	 * errors. No need to duplicate all that here
+	 */
+	err = irttp_udata_request(self->tsap, skb);
+	if (err) {
+		IRDA_DEBUG(0, __FUNCTION__ "(), err=%d\n", err);
+		return err;
+	}
+	return len;
+}
+
+/*
  * Function irda_recvmsg (sock, msg, size, flags, scm)
  *
  *    Try to receive message and copy it to user
@@ -1386,7 +1466,7 @@ static struct proto_ops irda_dgram_ops =
 	irda_setsockopt,
 	irda_getsockopt,
 	sock_no_fcntl,
-	irda_sendmsg,
+	irda_sendmsg_dgram,
 	irda_recvmsg_dgram,
 };
 




From jeant@rockfort.hpl.hp.com Tue, 30 Nov 1999 20:27:15 -0800
Date: Tue, 30 Nov 1999 20:27:15 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Re: Troubles at 9600

On Tue, Nov 30, 1999 at 11:05:03AM +0100, Dag Brattli wrote:
> Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:
> 
> Yes, I've applied it and fixed the Config.in and Makefile as well. But
> could you write something for Documentation/Configure.help?

Say Y here if you want to build support for the old Belkin SmartBeam
dongle. If you want to compile it as a module, say M here and read
Documentation/modules.txt.
The Belkin SmartBeam dongle (F5F500) come in two variants. The only
way to distinguish those is to open the dongle and check the presence
of a jumper (the jumper, on the new dongle, toggle between IrDA and 
ASK modes). This driver only support the old dongle. The old dongle
is also limited to 9600 b/s (which is not very fun).
To activate support for old Belkin dongles you will have to insert
"irattach -d old_dongle" in the /etc/irda/drivers script.

> Don't think I have to test it to figure out what's wrong. How much time
> does the machine use to transmit a 2K frame (actually 2050 bytes + framing
> and stuffing) over a 9600bps link? Remember that the max turn time is 500
> ms. Yes, we need to make sure we don't allow such large frames at such a
> low speed. I hasn't been fixed yet, since I don't think anybody has tried
> this before ;-)
> 
> >From the IrLAP spec 6.6.5 (page 40):
> 
> ... "The actual maximum frame size for the connection must be adjusted to
> accommodate the baud rate and maximum turn around time." ...

	Ok, that's only that, so it's as good as solved ;-) Yes, it's
seem that I've got a way to torture your code in unexpected ways...
	Note that it may explain some of the problem that people are
seeing :
http://www4.pasta.cs.uit.no/pipermail/linux-irda/1999-November/000604.html

> -- Dag

	Jean





From dagb@cs.uit.no 04 Dec 1999 12:44:15 +0100
Date: 04 Dec 1999 12:44:15 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Re: Unreliable service on TTP

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	To use this service, just replace SOCK_STREAM by
> SOCK_SEQPACKET in your application. As opposed to UDP, this is a

Very nice Jean, but I think we should do things a bit different:

       SOCK_STREAM
              Provides  sequenced,  reliable, two-way connection-
              based byte streams.  An out-of-band data  transmis-
              sion mechanism may be supported.

       SOCK_DGRAM
              Supports datagrams (connectionless, unreliable mes-
              sages of a fixed maximum length).

       SOCK_SEQPACKET
              Provides a sequenced, reliable, two-way connection-
              based data transmission path for datagrams of fixed
              maximum length; a consumer is required to  read  an
              entire packet with each read system call.

So SOCK_SEQPACKET should be used for reliable TTP connections with SAR
(segmentation and reassembly) enabled (where message boundaries are
preserved), while SOCK_STREAM is for TTP connections with SAR disabled (and
where message boundaries _may_ not be preserved.

I think you should probably use SOCK_DGRAM for unitdata (udata)
transfer. The unitdata service you are using is however an unreliable
service _within_ a connection, so it may conflict with ultra which is
unreliable tranfer _outside_ a connection (9600 bps only)

Anyway, TTP with SAR enabled _is_ a sequenced packet service, so we must
use SOCK_SEQPACKET for this service. I feel that we should probably use an
ioctl to differ between a unitdata or ultra for a SOCK_DGRAM socket.

PS. And yes, I was a bit confused myself when I used SOCK_STREAM for both
SAR enabled, and SAR disabled TTP connections. I discovered this some time
ago, and have plans to remove this "feature", so SOCK_STREAM sockets will
only have a max SDU size of 0. Then we should only allow the MAX_SDU_SIZE
ioctl for SOCK_SEQPACKET sockets to limit the SDU size for incomming TTP
segments.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///





From dagb@cs.uit.no 05 Dec 1999 11:20:57 +0100
Date: 05 Dec 1999 11:20:57 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Unreliable service on TTP

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> @@ -852,6 +861,12 @@ static int irda_sendmsg(struct socket *s
>  	}
>  
>  	/* Check that we don't send out to big frames */
> +	/* I'm not sure, but I believe that around here we should split
> +	 * big frames into smaller chunk 

Yes, this is exactly what this function does (but in collaboration with the
client) In a STREAM based protocol, you should just chop the data into
smaller chunks. But this function does however not fragment a big frame
into many smaller frames. It will only take one bite of it and tell the
client how big bite it took. The client must then repeat this process until
all data is sent. It must do this anyway, since it cannot depend upon the
kernel sending all the data (this is the same for TCP). So this moves the
fragmentation from the kernel to the client. Why? Well, now this function
can be used for both STREAM and SEQPACK services. You could reduce the
number of syscalls by doing frag' in the kernel, but ...

> and perform coalesce on smaller
> +	 * chunks to group them in bigger packets, as it is done
> +	 * in 'tcp_do_sendmsg'...

The Linux-IrDA socket interface does not buffer frames, since this must be
done by TTP anyway, so such a feature should probably be impl. by TTP
instead. 

> +	 * As the service is reliable AND sequenced, the higher layer won't
> +	 * see the difference and the performance will be better... */

Yes, it might perform a little better. But the issue here is not SEQUENCED
but STREAMING. You _cannot_ do this thing in a sequenced packet service!!!
This is only for a streaming service where message boundaries are not
preserved. Think of IrLAN. IrLAN needs a sequenced packet service (TTP with 
SAR), and you cannot start fragmenting IrLAN frames at random places or
join IrLAN frames in order to transport the data faster. TTP SAR may
fragment, but similar to UDP, it will make sure that they are defragmented
into the _original_ frames again.

>  	if (len > self->max_data_size) {
>  		IRDA_DEBUG(0, __FUNCTION__ "(), Warning to much data! "
>  		      "Chopping frame from %d to %d bytes!\n", len, 
> @@ -883,6 +898,71 @@ static int irda_sendmsg(struct socket *s
>  }

PS. I'm applying your changes (UNITDATA), but as a datagram service. If
somebody needs ULTRA, they will deal with the name conflicts later.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 05 Dec 1999 18:25:47 +0100
Date: 05 Dec 1999 18:25:47 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]patch-2.2.13-irda8 is out!

Hi,

Have just released patch-2.2.13-irda8 which should hopefully fix a lot of
problems. Thanks to all the contributors!!

You can find it at:
	
	http://www.cs.uit.no/linux-irda/snapshots/v2.2/patch-2.2.13-irda8.gz


Changes:

o Plenty of memleaks found and fixed (Chris Richards)

o New dongle driver old_belkin, and a fixed actisys dongle driver 
 (Jean Tourrilhes)

o Unitdata (SOCK_DGRAM) support to IrDA sockets (Jean Tourrilhes)

o TTP with SAR (SOCK_SEQPACKET) support to IrDA sockets (me)

o F-timer fix in IrLAP (me)

o Max segment size fix for incomming connections (me)

o IrLAN QoS fixes for low speed connections. We now limit both window size
  and data size based on the line capacity of the link. Previously we only
  limited the window size (me)

Have fun!

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 05 Dec 1999 17:25:32 +0100
Date: 05 Dec 1999 17:25:32 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]The IrCOMM bug hunt

Hi,

I have used a couple of days trying to hunt for IrCOMM bugs, and things are
looking pretty good so far. Well, I haven't found any bugs in IrCOMM, but I
have found several bugs in the rest of the stack. The most important ones:

1) The IrLAP final timer was calculated based on the max_turn_time in the
wrong direction (rx instead of tx). This made Linux send out RR frames to
early when not hearing from a secondary station if the max turn time was
different for both directions. This could cause IrLAP frames to sometimes
collide in rare situations.

2) IrTTP annonced wrong maximum data size (one byte to much) to IrCOMM for
incomming connections which made IrCOMM sometimes use 1 byte to much when
sending out data (the link would definitively go down if there was much
IrCOMM traffic). This would make other devices drop the frame, and
retransmission would not help, and the link would break!

Bug nr. 2 was very hard to find since it only appeared sometimes for
incomming connections. But I think this might be _the_ bug which have
caused most headache for you.

I'm seing another bug as well where the Palm stops responding to RR
frames. This bug may happen if I run "cd /;ll -R" from the Palm, and run
"ping -f <palm>" from Linux. This generates a _lot_ of traffic ;-) and the
link may break after about 10 minutes. The Palm seems to function, but it's
IR subsystem is broken. Only way to make it work again is to reset the
Palm. So I suspect this has nothing to do with Linux.

I'm going to make a new patch as soon as possible so you can try out these
latest changes.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From nicb@axnet.it Sun, 5 Dec 1999 19:11:19 +0100 (CET)
Date: Sun, 5 Dec 1999 19:11:19 +0100 (CET)
From: Nicola Bernardini nicb@axnet.it
Subject: [Linux-IrDA]patch-2.2.13-irda8 is out!

Today, Dag Brattli mi scrisse cio` che segue:

> Have just released patch-2.2.13-irda8 which should hopefully fix a lot of
> problems. Thanks to all the contributors!!
[snip]

sorry if this has been answered before. Do we need to apply all
patches up to irda8 to 2.2.13 in order to get the right patching
sequence, or can we just apply irda8?

Thanks

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.





From dagb@cs.uit.no 05 Dec 1999 21:52:44 +0100
Date: 05 Dec 1999 21:52:44 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]patch-2.2.13-irda8 is out!

Nicola Bernardini <nicb@axnet.it> writes:

> Today, Dag Brattli mi scrisse cio` che segue:
> 
> > Have just released patch-2.2.13-irda8 which should hopefully fix a lot of
> > problems. Thanks to all the contributors!!
> [snip]
> 
> sorry if this has been answered before. Do we need to apply all
> patches up to irda8 to 2.2.13 in order to get the right patching
> sequence, or can we just apply irda8?

You only need -irda8. If you are unsure try patching with --dry-run. If
that gives you errors then you probably need to apply some more patches. If
not, it's a good indication that this patch is enough. Another thing you
can look at is the file size. If the file size is larger than any of the
other patches with a lower number, then you should suspect it to contain
the other patches as well. And if it's larger than all the others and
doesn't give any errors when using --dry-run then .... ;-)

Cheers

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From Per.Wallner@era.ericsson.se Mon, 6 Dec 1999 09:36:50 +0100
Date: Mon, 6 Dec 1999 09:36:50 +0100
From: Per Wallner (QRA) Per.Wallner@era.ericsson.se
Subject: [Linux-IrDA]Q: Connecting a Palm to Linux - IP and PPP

Hi Arjen,
I tried dongle_attach, but it didn't do much good. Could you tell
me the sequence of things you do, so I can give your working scheme
a shot. It would be greatly appreciated!

BTW, I tried to apply the irda8 patch to my already irda7-patched stuff.
No major success, I must admit... Is there some magic switch you have to
give to patch to make it work?

Best regards,
Per Wallner

-----Original Message-----
From: Vollebregt, A.M. [mailto:A.M.Vollebregt@research.kpn.com]
Sent: den 1 december 1999 10:12
To: 'linux-irda@PASTA.cs.uit.no'
Subject: RE: [Linux-IrDA]Q: Connecting a Palm to Linux - IP and PPP


Hi,

I wanted the same thing and have mostly the same configuration (same kernel,
patches and util). It works for me. I use a Girbil as dongle. The only big
difference is that I use dongle_attach to attach my dongle. Perhaps you have
forgotten that?
dongle_attach <device> -d <dongle>

Arjen Vollebregt
Systems Integration and Application for Multimedia
KPN Research




> -----Original Message-----
> From: Per Wallner (QRA) [mailto:Per.Wallner@era.ericsson.se]
> Sent: dinsdag 30 november 1999 13:14
> To: 'linux-irda@pasta.cs.uit.no'
> Subject: [Linux-IrDA]Q: Connecting a Palm to Linux - IP and PPP
> 
> 
> Hi,
> I already did this way back, but now it all seems new and 
> mysterious again... ;)
> 
> Here's the scope:
> I want to connect a Palm III/V (or Ericsson MC218) IP-wise to 
> a linux box. The 
> Palm uses ppp, and I've got a JetEye PC 9680 dongle. I simply 
> want the Palm
> (or whatever) to be an IP device, using the Linux box as a 
> network connection point.
> 
> Setup:
> RedHat 6.1, 2.2.13 kernel, patch-2.2.13-irda7 and irda-utils-0.9.5
> 
> I've created device files as:
> crw-r--r--   1 root     root     161,   0 Nov 29 15:27 /dev/ircomm0
> crw-r--r--   1 root     root     161,   1 Nov 29 15:27 /dev/ircomm1
> crw-r--r--   1 root     root     161,  16 Nov 29 15:28 /dev/irlpt0
> crw-r--r--   1 root     root     161,  17 Nov 29 15:28 /dev/irlpt1
> crw-r--r--   1 root     root      60,  64 Nov 30 09:06 /dev/irnine
> 
> My conf.modules contains:
> alias tty-ldisc-11   irtty
> alias char-major-161 ircomm-tty
> 
> 
> I load various modules, and start irmanager:
> /sbin/modprobe ircomm-tty
> /sbin/modprobe irtty
> /sbin/modprobe esi
> /sbin/modprobe ppp
> /usr/sbin/irmanager -d 1
> 
> This gives the following messages, which looks pretty much OK:
> 
> Nov 30 12:23:47 gal kernel: IrDA (tm) Protocols for Linux-2.2 
> (Dag Brattli) 
> Nov 30 12:23:47 gal kernel: IrCOMM protocol (Dag Brattli) 
> Nov 30 12:23:47 gal irmanager: executing: 'echo 1 > 
> /proc/sys/net/irda/discovery'
> Nov 30 12:23:47 gal irmanager: executing: 'echo gal > 
> /proc/sys/net/irda/devname'
> Nov 30 12:23:47 gal irmanager: + 1.1 Tue Nov  9 15:30:55 1999 
> Dag Brattli
> Nov 30 12:23:47 gal irattach: Serial connection established.
> Nov 30 12:23:47 gal kernel: IrDA: Registered device irda0 
> Nov 30 12:23:47 gal irmanager: + 1.1 Tue Nov  9 15:30:55 1999 
> Dag Brattli
> Nov 30 12:23:48 gal irattach: executing: 'echo gal > 
> /proc/sys/net/irda/devname'
> Nov 30 12:23:48 gal irattach: Using device: irda0 
> 
> I start pppd with:
> pppd /dev/ircomm1 <speed> 192.168.0.1:192.168.0.100 passive 
> silent persist noauth local nodetach
> where I've tried speeds btwn 9600 and 115200.
> 
> This gives me:
> Nov 30 12:27:18 gal pppd[912]: pppd 2.3.10 started by root, uid 0
> Nov 30 12:27:18 gal pppd[912]: Using interface ppp0
> Nov 30 12:27:18 gal pppd[912]: Connect: ppp0 <--> /dev/ircomm1
> 
> An lsmod gives me this:
> 
> Module                  Size  Used by
> esi                      760   1 
> irtty                   7164   2 
> ircomm-tty             29080   1 
> ircomm                 13116   0  [ircomm-tty]
> irda                  134465   2  [esi irtty ircomm-tty ircomm]
> ppp                    20684   1 
> slhc                    4300   0  [ppp]
> 
> At this stage, the LED on the dongle is happily blinking. 
> However, there's no way
> I can get the Palm (or MC) to connect.
> 
> I'm sure I've omitted some detail (or several...), and I'm stuck.
> What have I missed?
> Do I have to set serial speed some place? How does the ppp 
> interface connect to
> the serial port?
> 
> I really would appreciate if someone could shed some light on 
> this - I'm
> lost in darkness ;(
> 
> TIA, Best regards
> Per Wallner
> 
> 
> 
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
> 

_______________________________________________
Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda





From A.M.Vollebregt@research.kpn.com Mon, 06 Dec 1999 09:49:51 +0100
Date: Mon, 06 Dec 1999 09:49:51 +0100
From: Vollebregt, A.M. A.M.Vollebregt@research.kpn.com
Subject: [Linux-IrDA]Q: Connecting a Palm to Linux - IP and PPP

Hi Per,

I made a device irdevice with major/minor 161, 0.
aliases in /etc/conf.modules:
alias tty-ldisc-11 irtty
alias char-major-60 ircomm-tty
alias irda-dongle-4 girbil

modprobe ircomm-tty
modprobe irtty
modprobe girbil
modprobe ppp
dongle_attach irda0 -d girbil
irmanager -d 1
pppd /dev/irdevice 115200 10.0.0.1:10.0.0.2 passive silent persist noauth
local nodetach

Arjen Vollebregt
Systems Integration and Application for Multimedia
KPN Research

> -----Original Message-----
> From: Per Wallner (QRA) [mailto:Per.Wallner@era.ericsson.se]
> Sent: maandag 6 december 1999 9:37
> To: 'linux-irda@pasta.cs.UiT.No'
> Subject: RE: [Linux-IrDA]Q: Connecting a Palm to Linux - IP and PPP
> 
> 
> Hi Arjen,
> I tried dongle_attach, but it didn't do much good. Could you tell
> me the sequence of things you do, so I can give your working scheme
> a shot. It would be greatly appreciated!
> 
> BTW, I tried to apply the irda8 patch to my already 
> irda7-patched stuff.
> No major success, I must admit... Is there some magic switch 
> you have to
> give to patch to make it work?
> 
> Best regards,
> Per Wallner
> 
> -----Original Message-----
> From: Vollebregt, A.M. [mailto:A.M.Vollebregt@research.kpn.com]
> Sent: den 1 december 1999 10:12
> To: 'linux-irda@PASTA.cs.uit.no'
> Subject: RE: [Linux-IrDA]Q: Connecting a Palm to Linux - IP and PPP
> 
> 
> Hi,
> 
> I wanted the same thing and have mostly the same 
> configuration (same kernel,
> patches and util). It works for me. I use a Girbil as dongle. 
> The only big
> difference is that I use dongle_attach to attach my dongle. 
> Perhaps you have
> forgotten that?
> dongle_attach <device> -d <dongle>
> 
> Arjen Vollebregt
> Systems Integration and Application for Multimedia
> KPN Research
> 
> 
> 
> 
> > -----Original Message-----
> > From: Per Wallner (QRA) [mailto:Per.Wallner@era.ericsson.se]
> > Sent: dinsdag 30 november 1999 13:14
> > To: 'linux-irda@pasta.cs.uit.no'
> > Subject: [Linux-IrDA]Q: Connecting a Palm to Linux - IP and PPP
> > 
> > 
> > Hi,
> > I already did this way back, but now it all seems new and 
> > mysterious again... ;)
> > 
> > Here's the scope:
> > I want to connect a Palm III/V (or Ericsson MC218) IP-wise to 
> > a linux box. The 
> > Palm uses ppp, and I've got a JetEye PC 9680 dongle. I simply 
> > want the Palm
> > (or whatever) to be an IP device, using the Linux box as a 
> > network connection point.
> > 
> > Setup:
> > RedHat 6.1, 2.2.13 kernel, patch-2.2.13-irda7 and irda-utils-0.9.5
> > 
> > I've created device files as:
> > crw-r--r--   1 root     root     161,   0 Nov 29 15:27 /dev/ircomm0
> > crw-r--r--   1 root     root     161,   1 Nov 29 15:27 /dev/ircomm1
> > crw-r--r--   1 root     root     161,  16 Nov 29 15:28 /dev/irlpt0
> > crw-r--r--   1 root     root     161,  17 Nov 29 15:28 /dev/irlpt1
> > crw-r--r--   1 root     root      60,  64 Nov 30 09:06 /dev/irnine
> > 
> > My conf.modules contains:
> > alias tty-ldisc-11   irtty
> > alias char-major-161 ircomm-tty
> > 
> > 
> > I load various modules, and start irmanager:
> > /sbin/modprobe ircomm-tty
> > /sbin/modprobe irtty
> > /sbin/modprobe esi
> > /sbin/modprobe ppp
> > /usr/sbin/irmanager -d 1
> > 
> > This gives the following messages, which looks pretty much OK:
> > 
> > Nov 30 12:23:47 gal kernel: IrDA (tm) Protocols for Linux-2.2 
> > (Dag Brattli) 
> > Nov 30 12:23:47 gal kernel: IrCOMM protocol (Dag Brattli) 
> > Nov 30 12:23:47 gal irmanager: executing: 'echo 1 > 
> > /proc/sys/net/irda/discovery'
> > Nov 30 12:23:47 gal irmanager: executing: 'echo gal > 
> > /proc/sys/net/irda/devname'
> > Nov 30 12:23:47 gal irmanager: + 1.1 Tue Nov  9 15:30:55 1999 
> > Dag Brattli
> > Nov 30 12:23:47 gal irattach: Serial connection established.
> > Nov 30 12:23:47 gal kernel: IrDA: Registered device irda0 
> > Nov 30 12:23:47 gal irmanager: + 1.1 Tue Nov  9 15:30:55 1999 
> > Dag Brattli
> > Nov 30 12:23:48 gal irattach: executing: 'echo gal > 
> > /proc/sys/net/irda/devname'
> > Nov 30 12:23:48 gal irattach: Using device: irda0 
> > 
> > I start pppd with:
> > pppd /dev/ircomm1 <speed> 192.168.0.1:192.168.0.100 passive 
> > silent persist noauth local nodetach
> > where I've tried speeds btwn 9600 and 115200.
> > 
> > This gives me:
> > Nov 30 12:27:18 gal pppd[912]: pppd 2.3.10 started by root, uid 0
> > Nov 30 12:27:18 gal pppd[912]: Using interface ppp0
> > Nov 30 12:27:18 gal pppd[912]: Connect: ppp0 <--> /dev/ircomm1
> > 
> > An lsmod gives me this:
> > 
> > Module                  Size  Used by
> > esi                      760   1 
> > irtty                   7164   2 
> > ircomm-tty             29080   1 
> > ircomm                 13116   0  [ircomm-tty]
> > irda                  134465   2  [esi irtty ircomm-tty ircomm]
> > ppp                    20684   1 
> > slhc                    4300   0  [ppp]
> > 
> > At this stage, the LED on the dongle is happily blinking. 
> > However, there's no way
> > I can get the Palm (or MC) to connect.
> > 
> > I'm sure I've omitted some detail (or several...), and I'm stuck.
> > What have I missed?
> > Do I have to set serial speed some place? How does the ppp 
> > interface connect to
> > the serial port?
> > 
> > I really would appreciate if someone could shed some light on 
> > this - I'm
> > lost in darkness ;(
> > 
> > TIA, Best regards
> > Per Wallner
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> > http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
> > 
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
> 
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
> 




From hugues@cyberdeck.net Mon, 06 Dec 1999 10:15:10 +0100
Date: Mon, 06 Dec 1999 10:15:10 +0100
From: Yougz hugues@cyberdeck.net
Subject: [Linux-IrDA]A very basic question about the device

hello,

I would like to install a jeteye PC on e RedHat 6.1, and i just want to
know how can I build the devices /dev/ir* ?

Yougz.





From budely@tref.nl Mon, 6 Dec 1999 13:03:41 +0100
Date: Mon, 6 Dec 1999 13:03:41 +0100
From: Fons Botman budely@tref.nl
Subject: [Linux-IrDA]patch-2.2.13-irda8 is out!

Hello,

This question keeps popping up, is it possible to use a naming scheme for
this?
something like

xxx-irda<number> for a full patch
xxx-irda-<number><letter> for a patch patching another patch

Fons

-----Oorspronkelijk bericht-----
Van: Dag Brattli <dagb@cs.uit.no>
Aan: linux-irda@pasta.cs.UiT.No <linux-irda@pasta.cs.UiT.No>
Datum: zondag 5 december 1999 21:55
Onderwerp: Re: [Linux-IrDA]patch-2.2.13-irda8 is out!


>Nicola Bernardini <nicb@axnet.it> writes:
>
>> Today, Dag Brattli mi scrisse cio` che segue:
>>
>> > Have just released patch-2.2.13-irda8 which should hopefully fix a lot
of
>> > problems. Thanks to all the contributors!!
>> [snip]
>>
>> sorry if this has been answered before. Do we need to apply all
>> patches up to irda8 to 2.2.13 in order to get the right patching
>> sequence, or can we just apply irda8?
>
>You only need -irda8. If you are unsure try patching with --dry-run. If
>that gives you errors then you probably need to apply some more patches. If
>not, it's a good indication that this patch is enough. Another thing you
>can look at is the file size. If the file size is larger than any of the
>other patches with a lower number, then you should suspect it to contain
>the other patches as well. And if it's larger than all the others and
>doesn't give any errors when using --dry-run then .... ;-)
>
>Cheers
>
>-- Dag
>
>--
>   / Dag Brattli                   | The Linux-IrDA Project               /
>  // University of Tromsoe, Norway | Infrared communication for Linux    //
> /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///
>
>_______________________________________________
>Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
>http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
>





From bl@physics.dcu.ie Mon, 6 Dec 1999 12:35:32 +0000 (GMT)
Date: Mon, 6 Dec 1999 12:35:32 +0000 (GMT)
From: Brian Lawless bl@physics.dcu.ie
Subject: [Linux-IrDA]Brief question: AT commands

> 
> I have sucessfully used an SH888 to dial a modem in england using vodaphone
> merely by typing.
> 
> ATDT01223360314
> 
> with no semicolon,
> 
> James.

This does not work for me. What version phone and modem were
you using?
Request Infrared Modem model identification
AT+GMM
gives me
1100801
and Request mobile Phone revision identification 
AT+GMR
gives me
981125 1213 CXC125131

It ould be interesting to see what you get and possibly get
an interpretation of the version numbers.
Regards,
Brian.

==============================================================
Brian Lawless                        tel :- +353-1-7045300
School of Physical Sciences          fax :- +353-1-7045384
Dublin City University                  
Dublin 9                          email :- bl@physics.dcu.ie
Ireland
==============================================================




From bl@physics.dcu.ie Mon, 6 Dec 1999 12:41:15 +0000 (GMT)
Date: Mon, 6 Dec 1999 12:41:15 +0000 (GMT)
From: Brian Lawless bl@physics.dcu.ie
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

> 
> On Thu, 2 Dec 1999, Brian Lawless wrote:
> 
> >> I've found a very nice PDF file on http://mobileinternet.ericsson.se 
> >> describing the AT commands of the SH888, 
> >Yes this is a nice file but it is incorrect.
> >Page 152 gives a dial example with the SH888
> >ATD0705865975
> >This does not work. A  ; (semicolon) is required after the
> >number to cause  a dialling action but the software built
> >into the Ericsson SH888 then dials and switches the phone
> >back to voice mode. It is therefore impossible to 
> >use the SH888 as a straightforward modem. I fail to see the
> >necessity for this software block.   
> I had an idea here.
> What number are you calling when using the ; ?
> Is it a real data number, ie. does a modem pick up the line?

I have access to a landline modem and a dial in system. The
only change is that a SH888 replaced the Hayes
modem+landline.

> And, what does the SH888 reply to your ATD command (without ';') ?
> 
ATD017099988
ERROR

So I do not think that it is a problem with the answering
modem and answering computer.

Regards 
Brian

==============================================================
Brian Lawless                        tel :- +353-1-7045300
School of Physical Sciences          fax :- +353-1-7045384
Dublin City University                  
Dublin 9                          email :- bl@physics.dcu.ie
Ireland
==============================================================




From joth@bigfoot.com Mon, 6 Dec 1999 13:33:44 -0000
Date: Mon, 6 Dec 1999 13:33:44 -0000
From: Jonathan Dixon joth@bigfoot.com
Subject: [Linux-IrDA]Adaptec AIRport 2000 dongle

Hi

A few problems using this dongle...

1) Using kernel 2.3.39 and irda-utils-0.9.5, airport appears to be broken:-


> irattach /dev/ttyS0 -d airport

Dec  6 11:28:44 shrtlinx kernel: IrDA: Registered device irda0
Dec  6 11:28:45 shrtlinx insmod: /lib/modules/2.3.29/misc/airport.o:
unresolved symbol irda_execute_as_process
Dec  6 11:28:45 shrtlinx kernel: IrDA: Unable to find requested dongle



2) I have the following in /etc/conf.modules:

alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty
alias irda-dongle-0 tekram         # Are these needed?
alias irda-dongle-1 esi
alias irda-dongle-2 actisys
alias irda-dongle-3 actisys+
alias irda-dongle-4 girbil
alias irda-dongle-5 litelink
alias irda-dongle-6 airport

3) If I only select a subset of dongles to include (as modules) at kernel
configure time, it doesn't seem to find the airport dongle at all.


The esi dongle is working fine, however!
Any clues on how to set about fixing it, and I'm more than happy to have a
go at fixing/testing it (e.g. what should we replace calls to
irda_execute_as_process with?)

Cheers,
Jonathan






From hakan42@gmx.de Mon, 6 Dec 1999 14:31:26 +0100
Date: Mon, 6 Dec 1999 14:31:26 +0100
From: Hakan Tandogan hakan42@gmx.de
Subject: [Linux-IrDA]patch-2.2.13-irda8 is out!

On Sun, 05 Dec 1999, you wrote:
> Hi,
> 
> Have just released patch-2.2.13-irda8 which should hopefully fix a lot of
> problems. Thanks to all the contributors!!

	Just out of curiosity: What patchlevel of linux-irda is in the "stable"
2.2 series? I'm trying to build a irda-patch-2.2.13-irda7 together with
2.2.13-ac9, and get conflicts in net/irda/irmod.c (AC added the #ifdef's around
EXPORT_SYMBOL(proc_irda) and in net/irda/Config.in (the whole patch block
fails).

	Regards,
		Hakan

--
Hakan Tandogan                                       hakan@iconsult.com

ICONSULT Tandogan - Egerer GbR                   Tel.: +49-9131-9047-0
Memelstrasse 38 - D-91052 Erlangen               Fax.: +49-9131-9047-77




From jeant@rockfort.hpl.hp.com Mon, 6 Dec 1999 22:15:21 -0800
Date: Mon, 6 Dec 1999 22:15:21 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Auto-connect...

	Hi everybody...

	I added a new feature to connect : if you don't specify a
device address, the IrDA stack will try to find one for you (doing
discovery and all that jazz). Of course, if you specify an address,
the old behaviour is used...
	Patch below...

	Jean

-------------------------------------
--- af_irda.dag2.c	Mon Dec  6 13:32:26 1999
+++ af_irda.c	Mon Dec  6 13:48:08 1999
@@ -451,6 +451,71 @@ static int irda_find_lsap_sel(struct ird
 }
 
 /*
+ * Function irda_discover_lsap_sel (self, name)
+ *
+ *    Try to lookup LSAP selector in all remote LM-IAS that we can connect to
+ *
+ */
+static int irda_discover_lsap_sel(struct irda_sock *self, char *name)
+{
+	discovery_t *discovery;
+	int err = -ENETUNREACH;
+
+	IRDA_DEBUG(2, __FUNCTION__ "(), name=%s\n", name);
+
+	ASSERT(self != NULL, return -1;);
+
+	/* Tell IrLMP we want to be notified */
+	irlmp_update_client(self->ckey, self->mask, NULL, 
+			    irda_discovery_indication);
+	
+	/* Do some discovery */
+	irlmp_discovery_request(self->nslots);
+		
+	/* Check if the we got some results */
+	if (!cachelog)
+		/* Wait for answer */
+		/*interruptible_sleep_on(&self->discovery_wait);*/
+		return -EAGAIN;
+
+	/* 
+	 * Now, check all discovered devices (if any), and connect
+	 * client only about the services that the client is
+	 * interested in 
+	 */
+	discovery = (discovery_t *) hashbin_get_first(cachelog);
+	while (discovery != NULL) {
+		/* Mask out the ones we don't want */
+		if (discovery->hints.word & self->mask) {
+			/* Try this address */
+			self->daddr = discovery->daddr;
+			IRDA_DEBUG(1, __FUNCTION__ "(), trying daddr = %08x\n", self->daddr);
+
+			/* Query remote LM-IAS */
+			err = irda_find_lsap_sel(self, name);
+			if (err == 0)
+				break;
+		}
+
+		/* Next node */
+		discovery = (discovery_t *) hashbin_get_next(cachelog);
+	}
+	cachelog = NULL;
+
+	/* Check out what we found */
+	if(err) {
+		IRDA_DEBUG(0, __FUNCTION__ "(), cannot discover requested service ''%s'' !!!\n", name);
+		self->daddr = 0;	/* Guessing */
+		return(err);
+	}
+
+	IRDA_DEBUG(0, __FUNCTION__ "(), discovered requested service ''%s'' at address %08x\n", name, self->daddr);
+
+	return 0;
+}
+
+
+/*
  * Function irda_getname (sock, uaddr, uaddr_len, peer)
  *
  *    Return the our own, or peers socket address (sockaddr_irda)
@@ -682,19 +747,30 @@ static int irda_connect(struct socket *s
 
 	if (addr_len != sizeof(struct sockaddr_irda))
 		return -EINVAL;
-
-	/* Check if user supplied the required destination device address */
-	if (!addr->sir_addr)
+	/* Should do more check, and should do : addr->sir_name[24] = '\0' */
+	if (addr->sir_name[0] == '\0')
 		return -EINVAL;
 
-	self->daddr = addr->sir_addr;
-	IRDA_DEBUG(1, __FUNCTION__ "(), daddr = %08x\n", self->daddr);
-
-	/* Query remote LM-IAS */
-	err = irda_find_lsap_sel(self, addr->sir_name);
-	if (err) {
-		IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
-		return err;
+	/* Check if user supplied the required destination device address */
+	if (!addr->sir_addr) {
+		/* Try to find one suitable */
+		err = irda_discover_lsap_sel(self, addr->sir_name);
+		if (err) {
+			IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
+			return -EINVAL;
+		}
+	}
+	else {
+		/* Use the one provided by the user */
+		self->daddr = addr->sir_addr;
+		IRDA_DEBUG(1, __FUNCTION__ "(), daddr = %08x\n", self->daddr);
+
+		/* Query remote LM-IAS */
+		err = irda_find_lsap_sel(self, addr->sir_name);
+		if (err) {
+			IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
+			return err;
+		}
 	}
 
 	/* Check if we have opened a local TSAP */




From dagb@cs.uit.no 07 Dec 1999 10:25:23 +0100
Date: 07 Dec 1999 10:25:23 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Auto-connect...

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Hi everybody...
> 
> 	I added a new feature to connect : if you don't specify a
> device address, the IrDA stack will try to find one for you (doing
> discovery and all that jazz). Of course, if you specify an address,
> the old behaviour is used...
> 	Patch below...
> 
> 	Jean
> 
> -------------------------------------
> --- af_irda.dag2.c	Mon Dec  6 13:32:26 1999
> +++ af_irda.c	Mon Dec  6 13:48:08 1999
> @@ -451,6 +451,71 @@ static int irda_find_lsap_sel(struct ird
>  }
>  
>  /*
> + * Function irda_discover_lsap_sel (self, name)
> + *
> + *    Try to lookup LSAP selector in all remote LM-IAS that we can connect to
> + *
> + */
> +static int irda_discover_lsap_sel(struct irda_sock *self, char *name)
> +{
> +	discovery_t *discovery;

Looks OK, but I don't like the name. This function discovers device
addresses, not lsap selectors. You'll have to query the remote IAS (as the
comment says) to look up the lsap sel, but this is not what this function
is doing. It is just checking the discovery log for the device addresses
stored after receiving XID (eXchange station ID) frames. Should probably be 
called irda_discover_devices, or irda_do_discovery instead.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 07 Dec 1999 10:14:30 +0100
Date: 07 Dec 1999 10:14:30 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Re: QoS negociation broken...

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Hi,
> 
> 	At 115200 kb/s or lower, connect to another Linux box and then
> do a 'cat /proc/net/irda/irlap'. Anything wrong there ?
> 	I've tried to see where the bug is, but I can't find it !

The bug was in irlap_adjust_qos_settings() in qos.c ;-) I've fixed it and
will make a new patch.

One thing I should mention is that the -irda8 patch is a test where I for
the first time follow the IrDA spec for limiting the sending window. That
is the reason why the Tx window is only 2 (you cannot send more than 2 full
2K frames at 115200 bps with 500 ms turn time).

Previously I kept the window full sized, and calculated how many bytes I
could send in the window. So for Linux it was possible to send 2 full sized
frames, or 7 small frames (or something in between). I still think the
Linux way is better, so I'll probably go back to this way of doing it in
the next patch. Then we only need to check for a data size larger than the
maximum line capacity since the window is changed dynamically based on how
many and large frames that have already been send in the current
window. For more info check out section 6.6.11 (page 44) in
IrLAP. Comments?

> 	Of course, the performance is abysmal, IrLAN doesn't work at
> 9600 and STREAM_SEQPACKET crash the machine at every try...

Hmm, I'm still not sure if everything is OK now, so I'll try out some low
speed connections later with SAR later.

-- Dag 

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 07 Dec 1999 16:10:45 +0100
Date: 07 Dec 1999 16:10:45 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]patch-2.2.13-irda9 is out!

Hi, 

Have just released patch-2.2.13-irda9 which should be applied to vanilla
2.2.13. You can find it at:

	http://www.cs.uit.no/linux-irda/snapshots/v2.2/patch-2.2.13-irda9.gz

Changes since (-irda8):

o Fixed bug in IrLAP QoS negotiation (so serious, that I just had to make 
  a new patch)

o Fixed bug in IrTTP SAR code (serious for Jean ;-)

o Fixed some dangerous code in irlmp_event.c (maybe I got rid of some
  memleaks, but I really don't know ;-)

Have fun!

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From mtepperis@pdv-online.de Tue, 7 Dec 1999 17:54:59 +0100
Date: Tue, 7 Dec 1999 17:54:59 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: [Linux-IrDA]Linux-IRDA on PPC

hi,

a couple of days ago you gave us a status report.

Did you some more tests?

MfG
 Michael Tepperis







From mtepperis@pdv-online.de Tue, 7 Dec 1999 18:32:44 +0100
Date: Tue, 7 Dec 1999 18:32:44 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

hi,

>I've found a very nice PDF file on http://mobileinternet.ericsson.se 
>describing the AT commands of the SH888, but the Motorola L7089 seems like


where do you exactly found that pdf file?

I' ve found something like that for siemens s25 and others.

greetings
 michael





From jeant@rockfort.hpl.hp.com Tue, 7 Dec 1999 11:09:25 -0800
Date: Tue, 7 Dec 1999 11:09:25 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Re: patch-2.2.13-irda9 is out!

Dag wrote :
> Hi, 
> 
> Have just released patch-2.2.13-irda9 which should be applied to vanilla
> 2.2.13. You can find it at:
> 
>         http://www.cs.uit.no/linux-irda/snapshots/v2.2/patch-2.2.13-irda9.gz
> 
> Changes since (-irda8):
> 
> o Fixed bug in IrLAP QoS negotiation (so serious, that I just had to make 
>   a new patch)

	Yes !

> o Fixed bug in IrTTP SAR code (serious for Jean ;-)

	If you want IrLAN working at speed below 115 kb/s, you need SAR.

> o Fixed some dangerous code in irlmp_event.c (maybe I got rid of some
>   memleaks, but I really don't know ;-)
> 
> Have fun!
> 
> -- Dag

	I've got IrLan, IrComm & IrTTP working on the old_belkin
dongle at 9600 and on the actisys+ dongle at 115200. This release
seems pretty functional to me.

	Jean




From jeant@rockfort.hpl.hp.com Tue, 7 Dec 1999 14:14:34 -0800
Date: Tue, 7 Dec 1999 14:14:34 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]old_belkin dongle driver howto

	Hi again...

	For those interested in the old_belkin dongle, you need to use
Linux-IrDA 2.2.13-irda9 (kernel 2.2.13, not -acX, and
patch-2.2.13-irda9), anything earlier than that will give you grief
and pain.

	Then, you need to patch irattach.c along those lines :
----------------------------------
--- irattach.dag.c	Mon Dec  6 04:53:30 1999
+++ irattach.c	Mon Dec  6 05:00:13 1999
@@ -65,6 +65,9 @@
 #ifndef IRDA_AIRPORT_DONGLE
 #define IRDA_AIRPORT_DONGLE      6
 #endif
+#ifndef IRDA_OLD_BELKIN_DONGLE
+#define IRDA_OLD_BELKIN_DONGLE   7
+#endif
 
 extern void fork_now(void);
 extern int set_sysctl_param(char *name, char *value);
@@ -319,6 +322,8 @@ int main(int argc, char *argv[]) 
 				dongle = IRDA_LITELINK_DONGLE;
 			else if (strcmp(optarg, "airport") == 0)
 				dongle = IRDA_AIRPORT_DONGLE;
+			else if (strcmp(optarg, "old_belkin") == 0)
+				dongle = IRDA_OLD_BELKIN_DONGLE;
 			if (dongle == -1) {
 				syslog(LOG_ERR, "Sorry, dongle not supported yet!\n");
 				exit(-1);
----------------------------------

	Then, add the /etc/conf.modules the following :
----------------------------------
alias irda-dongle-7 old_belkin		# Belkin (old) SmartBeam
----------------------------------

	Then, you should be set...

	Jean




From jeant@rockfort.hpl.hp.com Tue, 7 Dec 1999 14:59:51 -0800
Date: Tue, 7 Dec 1999 14:59:51 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Sample socket programs...

--nVMJ2NtxeReIH9PS
Content-Type: text/plain; charset=us-ascii

	Hi everybody...

	Here are a few more sample programs to play with. Ultimately,
Dag could ship them as part of the IrDa utils packages like the other
samples (hint, Dag...).

	Jean

--nVMJ2NtxeReIH9PS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irprintf.c"

/*********************************************************************
 *                
 * Filename:      irprintf.c
 * Version:       
 * Description:   
 * Status:        Experimental.
 * Authors:       Dag Brattli <dagb@cs.uit.no>
 *		  Jean Tourrilhes <jt@hpl.hp.com>
 * Created at:    7/12/99
 * Modified at:   
 * Modified by:   
 * 
 *     Copyright (c) 1999 Dag Brattli, 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.
 * 
 *     This program is distributed in the hope that it will be useful,
 *     but WITHOUT ANY WARRANTY; without even the implied warranty of
 *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 *     GNU General Public License for more details.
 * 
 *     You should have received a copy of the GNU General Public License 
 *     along with this program; if not, write to the Free Software 
 *     Foundation, Inc., 59 Temple Place, Suite 330, Boston, 
 *     MA 02111-1307 USA
 *     
 ********************************************************************/

/*
 * Read an Ir socket and display it on stdout
 * Use stream
 */

#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/ioctl.h>
#include <sys/stat.h>

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>

#include <linux/irda.h>

#ifndef AF_IRDA
#define AF_IRDA 23
#endif /* AF_IRDA */

unsigned char buf[4098];

/*
 * Function main (argc, )
 *
 *    Implements IrDA Echo or Discard server
 *
 */
int main(int argc, char *argv[])
{
	struct sockaddr_irda peer, self;
	int addrlen;
	int fd, conn_fd;
	FILE *stream;

	printf("IrDA printf server starting ...\n");

	/* Create socket */
	fd = socket(AF_IRDA, SOCK_STREAM, 0);
	if (fd < 0) {
		perror("socket");
		exit(-1);
        }

	/* Init self */
	self.sir_family = AF_IRDA;
	strncpy(self.sir_name, "IrPrintf", 25);

	self.sir_lsap_sel = LSAP_ANY;
	
	if (bind(fd, (struct sockaddr*) &self, sizeof(struct sockaddr_irda))) {
		perror("bind");
		return -1;
	}

	if (listen(fd, 8)) {
		perror("listen");
		return -1;
	}

	for (;;) {
		addrlen = sizeof(struct sockaddr_irda);

		printf("Waiting for connection!\n");
		conn_fd = accept(fd, (struct sockaddr *) &peer, &addrlen);
		if (conn_fd < 0) {
			perror("accept");
			return -1;
		}
		stream = fdopen(conn_fd, "r");
		if(stream == NULL) {
			perror("fdopen");
			return -1;
		}
		printf("Connected!\n");
		
		do {
			if((fgets(buf, sizeof(buf), stream) == NULL) ||
			   (buf[0] == 0x3))
				buf[0] = '\0';

			fwrite(buf, 1, strlen(buf), stdout);

		} while (buf[0] != '\0');
		fflush(stdout);
		fclose(stream);
		close(conn_fd);
		printf("Disconnected!\n");
	}
	return 0;
}

--nVMJ2NtxeReIH9PS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irscanf.c"

/*********************************************************************
 *                
 * Filename:      irscanf.c
 * Version:       
 * Description:   
 * Status:        Experimental.
 * Authors:       Dag Brattli <dagb@cs.uit.no>
 *		  Jean Tourrilhes <jt@hpl.hp.com>
 * Created at:    7/12/99
 * Modified at:   
 * Modified by:   
 * 
 *     Copyright (c) 1999 Dag Brattli, 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.
 * 
 *     This program is distributed in the hope that it will be useful,
 *     but WITHOUT ANY WARRANTY; without even the implied warranty of
 *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 *     GNU General Public License for more details.
 * 
 *     You should have received a copy of the GNU General Public License 
 *     along with this program; if not, write to the Free Software 
 *     Foundation, Inc., 59 Temple Place, Suite 330, Boston, 
 *     MA 02111-1307 USA
 *     
 ********************************************************************/

/*
 * Read stdin and push it on an Ir socket
 * Use stream
 */

#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/wait.h>

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>

#include <linux/irda.h>

#ifndef AF_IRDA
#define AF_IRDA 23
#endif /* AF_IRDA */

#define MAX_DEVICES 10

unsigned char buf[4096];

/*
 * Function echo_discover_devices (fd)
 *
 *    Try to discover some remote device(s) that we can connect to
 *
 */
int irscanf_discover_devices(int fd)
{
	struct irda_device_list *list;
	unsigned char *buf;
	int len;
	int i;

	len = sizeof(struct irda_device_list) +
		sizeof(struct irda_device_info) * MAX_DEVICES;

	buf = malloc(len);
	list = (struct irda_device_list *) buf;
	
	if (getsockopt(fd, SOL_IRLMP, IRLMP_ENUMDEVICES, buf, &len)) {
		perror("getsockopt");
		exit(-1);
	}

	if (len > 0) {
		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");
			
			if (list->dev[i].hints[0] & HINT_COMPUTER) {
				printf("Lets try this one\n");
				return list->dev[i].daddr;
			}
		}
	}
	printf("Didn't find any devices!\n");

	return -1;
}

/*
 * Function main (argc, )
 *
 *    
 *
 */
int main(int argc, char *argv[])
{
	struct sockaddr_irda peer;
	int daddr = 0;
	int fd;
	FILE *stream;

	/* Create socket */
	fd = socket(AF_IRDA, SOCK_STREAM, 0);
	if (fd < 0) {
		perror("socket");
		exit(-1);
        }

#if 1
	/* Find a peer */
	daddr = irscanf_discover_devices(fd);
	if (daddr == -1)
		return -1;
#endif

	peer.sir_family = AF_IRDA;
	strncpy(peer.sir_name, "IrPrintf", 25);
	peer.sir_addr = daddr;
	
	if (connect(fd, (struct sockaddr*) &peer, 
		    sizeof(struct sockaddr_irda))) {
		perror("connect");
		return -1;
	}

	stream = fdopen(fd, "w");
	if(stream == NULL) {
		perror("fdopen");
		return -1;
	}

	printf("Connected!\n");
	printf("Type your text with '.' on the last line...\n");

	do {
		if((fgets(buf, sizeof(buf), stdin) == NULL) ||
		   (buf[0] == '.')) {
			buf[0] = 0x3;
			buf[1] = '\0';
		}

		fwrite(buf, 1, strlen(buf), stream);
		fflush(stream);
	} while(buf[0] != 0x3);

	printf("Closing connection...\n");
	fclose(stream);
	close (fd);

	return 0;
}

--nVMJ2NtxeReIH9PS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irprintfx.c"

/*********************************************************************
 *                
 * Filename:      irprintf.c
 * Version:       
 * Description:   
 * Status:        Experimental.
 * Authors:       Dag Brattli <dagb@cs.uit.no>
 *		  Jean Tourrilhes <jt@hpl.hp.com>
 * Created at:    7/12/99
 * Modified at:   
 * Modified by:   
 * 
 *     Copyright (c) 1999 Dag Brattli, 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.
 * 
 *     This program is distributed in the hope that it will be useful,
 *     but WITHOUT ANY WARRANTY; without even the implied warranty of
 *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 *     GNU General Public License for more details.
 * 
 *     You should have received a copy of the GNU General Public License 
 *     along with this program; if not, write to the Free Software 
 *     Foundation, Inc., 59 Temple Place, Suite 330, Boston, 
 *     MA 02111-1307 USA
 *     
 ********************************************************************/

/*
 * Read an Ir socket and display it on stdout
 * Use file descriptor
 */

#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/ioctl.h>
#include <sys/stat.h>

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>

#include <linux/irda.h>

#ifndef AF_IRDA
#define AF_IRDA 23
#endif /* AF_IRDA */

unsigned char buf[4098];

/*
 * Function main (argc, )
 *
 *    Implements IrDA Echo or Discard server
 *
 */
int main(int argc, char *argv[])
{
	struct sockaddr_irda peer, self;
	int addrlen;
	int fd, conn_fd;
	int actual;

	printf("IrDA printf server starting ...\n");

	/* Create socket */
	fd = socket(AF_IRDA, SOCK_STREAM, 0);
	if (fd < 0) {
		perror("socket");
		exit(-1);
        }

	/* Init self */
	self.sir_family = AF_IRDA;
	strncpy(self.sir_name, "IrPrintf", 25);

	self.sir_lsap_sel = LSAP_ANY;
	
	if (bind(fd, (struct sockaddr*) &self, sizeof(struct sockaddr_irda))) {
		perror("bind");
		return -1;
	}

	if (listen(fd, 8)) {
		perror("listen");
		return -1;
	}

	for (;;) {
		addrlen = sizeof(struct sockaddr_irda);

		printf("Waiting for connection!\n");
		conn_fd = accept(fd, (struct sockaddr *) &peer, &addrlen);
		if (conn_fd < 0) {
			perror("accept");
			return -1;
		}
		printf("Connected!\n");
		
		do {
			actual = read(conn_fd, buf, sizeof(buf));
			if((actual <= 0) || (buf[0] == 0x3))
				break;

			fwrite(buf, 1, actual, stdout);

		} while (buf[0] != '\0');
		fflush(stdout);
		close(conn_fd);
		printf("Disconnected!\n");
	}
	return 0;
}

--nVMJ2NtxeReIH9PS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irscanfx.c"

/*********************************************************************
 *                
 * Filename:      irscanfx.c
 * Version:       
 * Description:   
 * Status:        Experimental.
 * Authors:       Dag Brattli <dagb@cs.uit.no>
 *		  Jean Tourrilhes <jt@hpl.hp.com>
 * Created at:    7/12/99
 * Modified at:   
 * Modified by:   
 * 
 *     Copyright (c) 1999 Dag Brattli, 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.
 * 
 *     This program is distributed in the hope that it will be useful,
 *     but WITHOUT ANY WARRANTY; without even the implied warranty of
 *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 *     GNU General Public License for more details.
 * 
 *     You should have received a copy of the GNU General Public License 
 *     along with this program; if not, write to the Free Software 
 *     Foundation, Inc., 59 Temple Place, Suite 330, Boston, 
 *     MA 02111-1307 USA
 *     
 ********************************************************************/

/*
 * Read stdin and push it on an Ir socket
 * Use file descriptor
 */

#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/wait.h>

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>

#include <linux/irda.h>

#ifndef AF_IRDA
#define AF_IRDA 23
#endif /* AF_IRDA */

#define MAX_DEVICES 10

unsigned char buf[4096];

/*
 * Function echo_discover_devices (fd)
 *
 *    Try to discover some remote device(s) that we can connect to
 *
 */
int irscanf_discover_devices(int fd)
{
	struct irda_device_list *list;
	unsigned char *buf;
	int len;
	int i;

	len = sizeof(struct irda_device_list) +
		sizeof(struct irda_device_info) * MAX_DEVICES;

	buf = malloc(len);
	list = (struct irda_device_list *) buf;
	
	if (getsockopt(fd, SOL_IRLMP, IRLMP_ENUMDEVICES, buf, &len)) {
		perror("getsockopt");
		exit(-1);
	}

	if (len > 0) {
		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");
			
			if (list->dev[i].hints[0] & HINT_COMPUTER) {
				printf("Lets try this one\n");
				return list->dev[i].daddr;
			}
		}
	}
	printf("Didn't find any devices!\n");

	return -1;
}

/*
 * Function main (argc, )
 *
 *    
 *
 */
int main(int argc, char *argv[])
{
	struct sockaddr_irda peer;
	int daddr = 0;
	int fd;

	/* Create socket */
	fd = socket(AF_IRDA, SOCK_STREAM, 0);
	if (fd < 0) {
		perror("socket");
		exit(-1);
        }

#if 1
	/* Find a peer */
	daddr = irscanf_discover_devices(fd);
	if (daddr == -1)
		return -1;
#endif

	peer.sir_family = AF_IRDA;
	strncpy(peer.sir_name, "IrPrintf", 25);
	peer.sir_addr = daddr;
	
	if (connect(fd, (struct sockaddr*) &peer, 
		    sizeof(struct sockaddr_irda))) {
		perror("connect");
		return -1;
	}

	printf("Connected!\n");
	printf("Type your text with '.' on the last line...\n");

	do {
		if((fgets(buf, sizeof(buf), stdin) == NULL) ||
		   (buf[0] == '.')) {
			buf[0] = 0x3;
			buf[1] = '\0';
		}

		write(fd, buf, strlen(buf));
	} while(buf[0] != 0x3);

	printf("Closing connection...\n");
	close (fd);

	return 0;
}

--nVMJ2NtxeReIH9PS--




From jeant@rockfort.hpl.hp.com Tue, 7 Dec 1999 15:24:33 -0800
Date: Tue, 7 Dec 1999 15:24:33 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Re: Auto-connect...

Dag wrote :
>
> > +static int irda_discover_lsap_sel(struct irda_sock *self, char *name)
> 
> Looks OK, but I don't like the name. This function discovers device
> addresses, not lsap selectors. You'll have to query the remote IAS (as the
> comment says) to look up the lsap sel, but this is not what this function
> is doing. It is just checking the discovery log for the device addresses
> stored after receiving XID (eXchange station ID) frames. Should probably be 
> called irda_discover_devices, or irda_do_discovery instead.

	Yes, as you like. I thought it was stupid for each app to
duplicate exactly the same piece of code, but I was not sure if you
would like it (actually, if you just complain about the function name,
I've got a hit !!!).

> -- Dag

	Jean




From martin@stronafian.freeserve.co.uk Tue, 7 Dec 1999 23:56:08 -0500
Date: Tue, 7 Dec 1999 23:56:08 -0500
From: Martin Ritchie martin@stronafian.freeserve.co.uk
Subject: [Linux-IrDA]IrDA on LinuxPPC

I'm new to the linux world so please bare with my poor knowledge.

What rpm/bits do I need to install the IrDA stuff on my mac.
I have an iMac and would be eager to get the ir port working.

I'm running LinuxPPC 1999 Q3 as it comes off the CDs.
No upgrades have been applied other than JDK 121(122 needs dl)
Everything was not installed as I have only a 1G partition.
I still need some mac filespace! (its only a 2G drive!!!)

--
m.ritchie@iname.com




From jeant@rockfort.hpl.hp.com Tue, 7 Dec 1999 18:33:22 -0800
Date: Tue, 7 Dec 1999 18:33:22 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]UI frames in irdadump...

	Hi everybody...

	If you want to see UI frames in irdadump, you'd better apply
the following patch :

-------------------------------------
diff -u -p irdadump.dag.h irdadump.h
--- irdadump.dag.h	Tue Dec  7 10:54:41 1999
+++ irdadump.h	Tue Dec  7 10:49:23 1999
@@ -194,6 +194,7 @@ struct lsap_state {
 
 inline void parse_obex(struct lsap_state *conn, GNetBuf *buf, GString *str);
 inline void parse_irlmp(GNetBuf *buf, GString *str, int type);
+inline void parse_ui_irlmp(GNetBuf *buf, GString *str, int type);
 
 #endif /* IRDADUMP_H */
 
diff -u -p irdadump.dag.c irdadump.c
--- irdadump.dag.c	Tue Dec  7 10:54:41 1999
+++ irdadump.c	Tue Dec  7 10:49:56 1999
@@ -318,6 +318,27 @@ inline void parse_i_frame(guint8 caddr, 
 }
 
 /*
+ * Function parse_ui_frame (buf, len, u_char)
+ *
+ *    Information frames
+ *
+ */
+inline void parse_ui_frame(guint8 caddr, guint8 cmd, guint8 pf, int type, 
+			   GNetBuf *buf, GString *str)
+{
+	/* Remove IrLAP header */
+	g_netbuf_pull(buf, 2);
+
+	g_string_sprintfa(str, "ui:%s %s ca=%02x pf=%d  ", 
+			  cmd ? "cmd" : "rsp", 
+			  type ? ">" : "<", caddr, pf);
+	
+	/* Check if we should print IrLMP information */
+	if (config_print_irlmp)
+		parse_ui_irlmp(buf, str, type);
+}
+
+/*
  * Function parse_frmr_frame (caddr, cmd, pf, type, frame, len)
  *
  *    Frame reject frame
@@ -636,7 +657,7 @@ inline void parse_irda_frame(int type, G
 		parse_frmr_frame(caddr, cmd, pf, type, buf, str);
 		break;
 	case UI_FRAME:
-		/* parse_ui_frame( self, skb, &info); */
+		parse_ui_frame(caddr, cmd, pf, type, buf, str);
 		break;
 	default:
 	        g_string_sprintfa(str, "Unknown frame %02x received!\n", 
diff -u -p irlmp.dag.c irlmp.c
--- irlmp.dag.c	Tue Dec  7 10:54:41 1999
+++ irlmp.c	Tue Dec  7 10:48:38 1999
@@ -333,3 +333,26 @@ inline void parse_irlmp(GNetBuf *buf, GS
 		}
 	}
 }
+
+/*
+ * Function parse_ui_irlmp (buf)
+ *
+ *    Parse IrLMP frame in UI frame
+ *
+ */
+inline void parse_ui_irlmp(GNetBuf *buf, GString *str, int type)
+{
+	guint8 slsap_sel, dlsap_sel;
+	int ctrl;
+	int i;
+	
+	ctrl = buf->data[0] & CONTROL_BIT;
+	dlsap_sel = buf->data[0] & LSAP_MASK;
+	slsap_sel = buf->data[1];
+	
+	/* Remove IrLMP header */
+	g_netbuf_pull(buf, 2);
+
+	g_string_sprintfa(str, "LM slsap=%02x dlsap=%02x ", slsap_sel, 
+			  dlsap_sel);
+}

-------------------------------------

	Have fun...

	Jean




From dagb@cs.uit.no 08 Dec 1999 09:42:12 +0100
Date: 08 Dec 1999 09:42:12 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]IrSock programming

Adrian Pfisterer <apfister@boi.hp.com> writes:

> you should have a file named af_irda.h somewhere. 
[...]
> 
> Adrian Pfisterer.

[Cc: to Linux-IrDA maling list since others are probably also interested in
this]

Thanks! I eventually found the stuff in the Win2000 DDK (net part). But how
do you control the hint bits for the XID frames? How do you turn on the
OBEX hint bit when you want to put up an OBEX server, or any other server?

I told you this stuff was not so good in Linux, and I was hoping that the
IrSock API should tell me a nice way to do this, but I'm really clueless
after reading af_irda.h and the rest of the IrSock API docs.

Is this the reason why Quickbeam does not set the OBEX hint bit when using
the native Win98 stack. Quickbeam wants me to replace the IrDA stack for
Win98 when I'm installing it, and for Win95 this is OK, but for Win98 I'm
not so sure. But then I found out that Quickbeam cannot set the OBEX hint
bit using the native Win98 stack.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 08 Dec 1999 12:32:56 +0100
Date: 08 Dec 1999 12:32:56 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]UI frames in irdadump...

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Hi everybody...
> 
> 	If you want to see UI frames in irdadump, you'd better apply
> the following patch :

Thanks, I have btw. added Ultra support to Linux-IrDA (and sockets), so
please wait for the next patch. Just so that you don't redo this work when
it's done already ;-)

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From apm@netropolis.dk Wed, 8 Dec 1999 13:42:11 +0100 (CET)
Date: Wed, 8 Dec 1999 13:42:11 +0100 (CET)
From: Peter Mogensen apm@netropolis.dk
Subject: [Linux-IrDA]Brief question: AT commands for Motorola L7089

On Tue, 7 Dec 1999, Michael Tepperis wrote:
> where do you exactly found that pdf file?

http://mobileinternet.ericsson.se/emi_download/sh888/888_R1D.pdf

But I think I've dropepd the Motorola L7089. Ericsson is releasing a
_very_ nice alternative (R380) in a few months and I hope they document it
as good as SH888.

Peter






From dagb@cs.uit.no 08 Dec 1999 16:53:33 +0100
Date: 08 Dec 1999 16:53:33 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Re: New Actisys 220L/220L+ Linux driver

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Hi everybody...
> 
> 	A few weeks ago, I was complaining that the timming in the
> Actisys dongle driver in Linux IrDA were absurd. Today I received my
> batch of Actisys dongle, and guess what, I could not make it work with
> Linux IrDA.
> 	So, I wiped out the initialisation code and the code to change
> speed in the old driver and replaced it with something simpler, faster
> and more robust. I have to thanks Lichen Wang from Actisys who sent me

Well, I'm not so sure it's more robust ;-)

> a nice e-mail detailing the secret of their dongle.
> 	Anyway, the result is a new dongle driver that work for me.
> 	Enjoy...
> 

> static int actisys_change_speed(struct irda_task *task)
> {
> 	dongle_t *self = (dongle_t *) task->instance;
> 	__u32 speed = (__u32) task->param;	/* Target speed */
>         int index = 0;
> 	int ret = 0;
> 	
>         IRDA_DEBUG(4, __FUNCTION__ "(), speed=%d (was %d)\n",
> 		   speed, self->speed);
> 
> 	/* Go to a known state by reseting the dongle */
> 
> 	/* Reset the dongle : set DTR low for 10 us */
> 	self->set_dtr_rts(self->dev, FALSE, TRUE);
> 	udelay(MIN_DELAY);
> 
> 	/* Go back to normal mode (we are now at 9600 b/s) */
> 	self->set_dtr_rts(self->dev, TRUE, TRUE);
>  
> 	/* Now, we can set the speed requested */
> 
> 	/* Send RTS pulses until we reach the target speed */
> 	while((index < 5) && (speed != baud_rates[index++]))

I think it's very dangerous to increase the index here! Anyway, the index
will be one higher than the current baudrate when this loop is finished. 

> 	{
> 		/* Make sure previous pulse is finished */
> 		udelay(MIN_DELAY);
> 
> 		/* Set RTS low for 10 us */
> 		self->set_dtr_rts(self->dev, TRUE, FALSE);
> 		udelay(MIN_DELAY);
> 
> 		/* Set RTS high for 10 us */
> 		self->set_dtr_rts(self->dev, TRUE, TRUE);
> 	}
> 
> 	/* Check if life is sweet... */
> 	if(speed != baud_rates[index])

... and that is very dangerous here, if index becomes 5 (which it can be if
something goes wrong), you will index outside the array. Well, I cannot
find any reason why this should match at all, so I'm confused that you
actually got this code to work!? You find a match, but increase the index
at the same time, which means that the index is pointing to the next
entry (which should not match).

> 		ret = -1;	/* This should not happen */
> 	self->speed = baud_rates[index];	/* Do we care ? */
> 
> 	/* Basta lavoro, on se casse d'ici... */
> 	irda_task_next_state(task, IRDA_TASK_DONE);
> 
> 	return ret;
> }

I think it would be better (and safer) to do it like this:

	/* Send RTS pulses until we reach the target speed */
	for (i=0; i<5; i++) {
		if (speed == baud_rates[i]) {
			self->speed = baud_rates[i];
			break;
		}
		/* Make sure previous pulse is finished */
		udelay(MIN_DELAY);

		/* Set RTS low for 10 us */
		self->set_dtr_rts(self->dev, TRUE, FALSE);
		udelay(MIN_DELAY);

		/* Set RTS high for 10 us */
		self->set_dtr_rts(self->dev, TRUE, TRUE);
	}

	/* Check if life is sweet... */
	if (i == 5)
		ret = -1;  /* This should not happen */

I have fixed this in my code, and I'll be releasing a new patch later ...

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From jeant@rockfort.hpl.hp.com Wed, 8 Dec 1999 10:12:55 -0800
Date: Wed, 8 Dec 1999 10:12:55 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Ultra ?

Dag wrote :
> 
> Thanks, I have btw. added Ultra support to Linux-IrDA (and sockets), so
> please wait for the next patch. Just so that you don't redo this work when
> it's done already ;-)
> 
> -- Dag

	Boy ! What am I supposed to do now ? That was exactly my
target, and I had started working on it...
	By the way, I'm very curious on how you handle a few details,
so I will have a look at your patch with interest and make my comments ;-)

	Jean

P.S. : Forget my bug report of yesterday evening, I was tired and
mixed up LAP and LDSAP...




From cbueche@worldcom.ch Wed, 08 Dec 1999 19:22:49 +0100
Date: Wed, 08 Dec 1999 19:22:49 +0100
From: Charles Bueche cbueche@worldcom.ch
Subject: [Linux-IrDA]Linux - Palm V : serial always busy

Hi all,

my setup :

1. Dell CPtC400, RedHat 6.0, 2.2.13, patch-2.2.13-irda9,
irda-utils-0.9.5
2. Palm V with OS 3.3

goal : sync over IR, either with pilot-xfer or jpilot (preferred).
       the same sync over a normal serial port works fine.

Problem : everything I try get blocked by "port busy" kind of errors
when I start the sync tools.

Details :

- in the PC BIOS : IR enabled / slow mode / port com2 / irq3.
- Windows 98 find it and can communicate with the Palm.
- Beam receive disabled on the Palm preferences.
- same results when my PCMCIA card is out of the slot

# irattach /dev/ttyS1

  Dec  8 19:11:40 boy irattach: Serial connection established.
  Dec  8 19:11:40 boy kernel: IrDA (tm) Protocols for Linux-2.2 (Dag
Brattli) 
  Dec  8 19:11:40 boy kernel: IrDA: Registered device irda0 
  Dec  8 19:11:41 boy irattach: executing: 'echo boy >
/proc/sys/net/irda/devname'
  Dec  8 19:11:41 boy irattach: Using device: irda0 

# irmanager -d 1

  Dec  8 19:12:14 boy irmanager: executing: 'echo 1 >
/proc/sys/net/irda/discovery'
  Dec  8 19:12:14 boy irmanager: executing: 'echo boy >
/proc/sys/net/irda/devname'

# lsmod

  Module                  Size  Used by
  irtty                   4540   2  (autoclean)
  irda                   66593   2  (autoclean) [irtty]
  3c589_cs                8328   1 
  nm256                  69504   1 
  sound                  57228   0  [nm256]
  soundcore               2372   6  [sound]
  ds                      6504   2  [3c589_cs]
  i82365                 29908   2 
  pcmcia_core            43904   0  [3c589_cs ds i82365]

user% jpilot --> sync

  ****************************************
  Syncing on device /dev/ttyS1
  Press the HotSync button now
  ****************************************
  pi_bind Device or resource busy                <====== that's not
OK...
  Check your serial port and settings

user% export PILOTPORT=/dev/ttyS1
user% export PILOTRATE=9600                      <====== Pilot has same
speed setup in pref
user% pilot-xfer -b /tmp

  Unable to bind to port '/dev/ttyS1'            <====== same problem as
with jpilot

# irdadump   (extract)

  18:19:47.957418 xid:cmd ffffffff < 4125892d S=6 s=1 (14) 
  18:19:47.957552 xid:rsp 00f3169e > 4125892d S=6 s=1 boy hint=0400 [
Computer ] (19) 
  18:19:48.037485 xid:cmd ffffffff < 4125892d S=6 s=2 (14) 
  18:19:48.177360 xid:cmd ffffffff < 4125892d S=6 s=3 (14) 
  18:19:48.267744 xid:cmd ffffffff < 4125892d S=6 s=4 (14) 
  18:19:48.357357 xid:cmd ffffffff < 4125892d S=6 s=5 (14) 
  18:19:48.457515 xid:cmd ffffffff < 4125892d S=6 s=* IrCOMM hint=8204 [
PDA/Palmtop IrCOMM ] (23) 
  18:19:48.507557 snrm:cmd ca=fe pf=1 00f3169e < 4125892d new-ca=fa (32) 
  18:19:48.507694 ua:rsp ca=fa pf=1 00f3169e > 4125892d (31) 
  18:19:49.077432 rr:cmd < ca=fa pf=1 nr=0 (2) 
  18:19:49.077561 rr:rsp > ca=fa pf=1 nr=0 (2) 
  18:19:49.097447 i:cmd  < ca=fa pf=1 nr=0 ns=0 LM slsap=01 dlsap=00
CONN_CMD (6) 
  18:19:49.097591 i:rsp  > ca=fa pf=1 nr=1 ns=0 LM slsap=00 dlsap=01
CONN_RSP (6) 
  18:19:49.117621 i:cmd  < ca=fa pf=1 nr=1 ns=1 LM slsap=01 dlsap=00
GET_VALUE_BY_CLASS: 
     "IrDA:IrCOMM" "IrDA:TinyTP:LsapSel" (37) 
  18:19:49.117809 i:rsp  > ca=fa pf=1 nr=2 ns=1 LM slsap=00 dlsap=01
GET_VALUE_BY_CLASS: No such class (11) 

My conclusion : something must be wrong somewhere, and I would
appreciate your help.

Charles

-- 
---
Charles Bueche <cbueche@worldcom.ch>




From fluch@rock.helsinki.fi Wed, 8 Dec 1999 20:49:57 +0200 (EET)
Date: Wed, 8 Dec 1999 20:49:57 +0200 (EET)
From: Martin Fluch fluch@rock.helsinki.fi
Subject: [Linux-IrDA]linux-2.2.13-irda9 and IrLAN

-----BEGIN PGP SIGNED MESSAGE-----

Hi, 

I've recently started to play around with my IrDA port of my ThinkPad. I'm
in particular interestet in conecting two linux boxes (in this case two
identical TP's) via IrLAN. This basicaly works fine, but the two ThinkPads
don't reconnect probable after the conncetion got lost. Is this a known
problem? (I start irmanager with the -d1 option on both TP's, which then
executes the /etc/irda/driver scripts. These on both machines identical
and do an irattach /dev/ttyS0 ; modprobe irlan) BTW: I use irda-utils
0.9.5.

2nd: I've modified the irmanager code sligthly, so that now, when the
irmanager gets a SIGTERM, SIGINT or SIGHUP it first closes the irda
device, and then, before it exists finaly, it executes '/etc/irda/drivers
stop'. Due to these small changes it is now possible to let the 'drivers'
script free and unload all irda resources cleanly when the irmanager
exits (BTW: these changes only change the behavior of the irmanager, when
it exits, so it is not responsible for the reconnect problem)

Dag: are you interested in these changes?

Martin

- -- 
Where do you want to go today? - As far from Redmond as possible!

For public PGP-key: finger mfluch@mathphys.fsk.uni-heidelberg.de


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBOE6oWrCGSMW7I2etAQHmmwP/YIEh5hMHWNieeEaSsc9rJFpqV6Uk/Eaa
McDAHQooXBehIBvjyfLDRjFwcDfq1vACp9mZCzUQGaBzW9769M2fKrZxPhHZtGd8
C8S1WDACajSDaCObKLaerltnf6XqTsTf+Z/E8kCVaX7X4IYASfdNAHoNvV76hzhR
gwBkcsJRYQk=
=3I92
-----END PGP SIGNATURE-----





From haldevore@earthling.net Wed, 08 Dec 1999 12:58:24 -0600
Date: Wed, 08 Dec 1999 12:58:24 -0600
From: Hal DeVore haldevore@earthling.net
Subject: [Linux-IrDA]Linux - Palm V : serial always busy

>>>>> On Wed, 8 Dec 1999, "Charles" == Charles Bueche wrote:

  Charles> user% export PILOTPORT=/dev/ttyS1

This is incorrect.  The serial port is in use by the IR code, 
you want to point PILOTPORT at the IR device.  That would be 
/dev/ircomm0 probably.


--Hal






From dagb@cs.uit.no 08 Dec 1999 20:03:43 +0100
Date: 08 Dec 1999 20:03:43 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Ultra ?

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> Dag wrote :
> > 
> > Thanks, I have btw. added Ultra support to Linux-IrDA (and sockets), so
> > please wait for the next patch. Just so that you don't redo this work when
> > it's done already ;-)
> > 
> > -- Dag
> 
> 	Boy ! What am I supposed to do now ? That was exactly my

I can send you the source code for the VLSI driver ;-)

> target, and I had started working on it...
> 	By the way, I'm very curious on how you handle a few details,
> so I will have a look at your patch with interest and make my comments ;-)
> 

Don't worry. There is still a _lot_ of work to do with Ultra. I have
written the code, but I haven't tested it yet ;-) I had to make some
shortcuts when dealing with the media rules of IrLAP. The spec is a mess,
and it's really hard to know what these (simple) rules really are.

There is currently also only possible to open one Ultra socket. This is
done by the first client which does it, and others will get DoS. Instead,
the sockets layer should open one Ultra LSAP and refcount it for all
sockets using it. You can multiplex on the PID field so this should not be
to difficult.

I'll try to bring out a new patch soon, so you can start to help me with
this work.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From cbueche@worldcom.ch Wed, 08 Dec 1999 20:23:08 +0100
Date: Wed, 08 Dec 1999 20:23:08 +0100
From: Charles Bueche cbueche@worldcom.ch
Subject: [Linux-IrDA]Linux - Palm V : serial always busy

Hi again,

>Hal DeVore <haldevore@earthling.net> wrote :
>
>  Charles> user% export PILOTPORT=/dev/ttyS1
>
>This is incorrect.  The serial port is in use by the IR code, 
>you want to point PILOTPORT at the IR device.  That would be 
>/dev/ircomm0 probably.

Thanks Hal, your assuption is correct. pilot-xfer can go across the
link using /dev/ircomm0. Have yet to test jpilot, but I assume it
will just work the same way.

I want to congratulate all the IRDA/Linux developpers for their amazing
work. I have had a terrible time with IRDA/Windows at my workplace, this
is
why I can really appreciate your achievements with Linux. 
Go ahead and a big THANK !

Charles

Charles Bueche wrote:
> 1. Dell CPtC400, RedHat 6.0, 2.2.13, patch-2.2.13-irda9,
> irda-utils-0.9.5
> 2. Palm V with OS 3.3
> 
> goal : sync over IR, either with pilot-xfer or jpilot (preferred).
>        the same sync over a normal serial port works fine.
> 
> Problem : everything I try get blocked by "port busy" kind of errors
> when I start the sync tools.
>
>............. snipp..........< 
> 
> user% export PILOTPORT=/dev/ttyS1
> user% export PILOTRATE=9600                      <====== Pilot has same
> speed setup in pref
> user% pilot-xfer -b /tmp
> 
>   Unable to bind to port '/dev/ttyS1'            <====== same problem as
> with jpilot
> 
>............. snipp..........< 

-- 
---
Charles Bueche <cbueche@worldcom.ch>




From cbueche@worldcom.ch Wed, 08 Dec 1999 20:23:54 +0100
Date: Wed, 08 Dec 1999 20:23:54 +0100
From: Charles Bueche cbueche@worldcom.ch
Subject: [Linux-IrDA]Linux - Palm V : serial always busy

Hi again,

>Hal DeVore <haldevore@earthling.net> wrote :
>
>  Charles> user% export PILOTPORT=/dev/ttyS1
>
>This is incorrect.  The serial port is in use by the IR code, 
>you want to point PILOTPORT at the IR device.  That would be 
>/dev/ircomm0 probably.

Thanks Hal, your assuption is correct. pilot-xfer can go across the
link using /dev/ircomm0. Have yet to test jpilot, but I assume it
will just work the same way.

I want to congratulate all the IRDA/Linux developpers for their amazing
work. I have had a terrible time with IRDA/Windows at my workplace, this
is
why I can really appreciate your achievements with Linux. 
Go ahead and a big THANK !

Charles

Charles Bueche wrote:
> 1. Dell CPtC400, RedHat 6.0, 2.2.13, patch-2.2.13-irda9,
> irda-utils-0.9.5
> 2. Palm V with OS 3.3
> 
> goal : sync over IR, either with pilot-xfer or jpilot (preferred).
>        the same sync over a normal serial port works fine.
> 
> Problem : everything I try get blocked by "port busy" kind of errors
> when I start the sync tools.
>
>............. snipp..........< 
> 
> user% export PILOTPORT=/dev/ttyS1
> user% export PILOTRATE=9600                      <====== Pilot has same
> speed setup in pref
> user% pilot-xfer -b /tmp
> 
>   Unable to bind to port '/dev/ttyS1'            <====== same problem as
> with jpilot
> 
>............. snipp..........< 

-- 
---
Charles Bueche <cbueche@worldcom.ch>




From dagb@cs.uit.no 08 Dec 1999 20:26:24 +0100
Date: 08 Dec 1999 20:26:24 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]patch-2.2.13-irda10 is out!

Hi,

Have just put out patch-2.2.13-irda10. This is just a work in progress
patch and includes some untested Ultra code. You don't need to upgrade if
you're already running -irda9 (if your not specially interested in looking
at this code)

Changes since -irda9:

o Added Ultra (me)

o Fixed bug in actisys.c dongle driver (me)

o Fixes to the Winbond driver (Toshihiko Mineshima)


PS. Will put out a new irda-utils with the latest changes from Jean later ..

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From jeant@rockfort.hpl.hp.com Wed, 8 Dec 1999 16:49:59 -0800
Date: Wed, 8 Dec 1999 16:49:59 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]patch-2.2.13-irda10 assorted fixes...

--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=us-ascii

	Hi...

	Boy, it took me a bit of time, but now I've got
patch-2.2.13-irda10 working for me. Dag was right when he mentionned a
work in progress. See patch attached...
	Fixed :
	o wrong types in irda.h prevent compilation
	o typo in wrapper.c & actisys.c
	o create SEQPACKET with correct operations
	o auto-connect

	All is not perfect, though. Using SOCK_DGRAM (unitdata), the
first byte of every received packet is scrapped (missing - I suspect
the receiver path).
	And also, connect seems a bit flaky :
-----------------------------
irlap_state_ndm(), media busy!
irlap_state_ndm(), media busy!
irlmp_state_setup_pend() WATCHDOG_TIMEOUT!
irda_get_value_confirm(), IAS query failed!
irda_connect(), connect failed!
irlap_state_ndm(), media busy!
-----------------------------

	Have fun...

	Jean

--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irda10.diff"

diff -u -p linux/include/linux/irda.dag.h linux/include/linux/irda.h
--- linux/include/linux/irda.dag.h	Wed Dec  8 07:53:59 1999
+++ linux/include/linux/irda.h	Wed Dec  8 08:30:47 1999
@@ -22,6 +22,8 @@
  *
  ********************************************************************/
 
+#include <linux/types.h>		/* for __u8, __u32 & ... */
+
 #ifndef KERNEL_IRDA_H
 #define KERNEL_IRDA_H
 
@@ -69,11 +71,11 @@ typedef enum {
 } IRDA_DONGLE;
 
 /* Protocol types to be used for SOCK_DGRAM */
-enum {
+typedef enum {
 	IRDAPROTO_UNITDATA = 0,
 	IRDAPROTO_ULTRA    = 1,
 	IRDAPROTO_MAX
-};
+} IRDA_DGRAM_PROTOCOLS;
 
 #define SOL_IRLMP      266 /* Same as SOL_IRDA for now */
 #define SOL_IRTTP      266 /* Same as SOL_IRDA for now */
@@ -96,21 +98,21 @@ enum {
 
 struct sockaddr_irda {
 	sa_family_t   sir_family;   /* AF_IRDA */
-	uint8_t       sir_lsap_sel; /* LSAP selector */
-	uint32_t      sir_addr;     /* Device address */
+	__u8          sir_lsap_sel; /* LSAP selector */
+	__u32         sir_addr;     /* Device address */
 	char          sir_name[25]; /* Usually <service>:IrDA:TinyTP */
 };
 
 struct irda_device_info {
-	uint32_t      saddr;    /* Address of local interface */
-	uint32_t      daddr;    /* Address of remote device */
+	__u32         saddr;    /* Address of local interface */
+	__u32         daddr;    /* Address of remote device */
 	char          info[22]; /* Description */
-	uint8_t       charset;  /* Charset used for description */
-	uint8_t       hints[2]; /* Hint bits */
+	__u8	      charset;  /* Charset used for description */
+	__u8          hints[2]; /* Hint bits */
 };
 
 struct irda_device_list {
-       uint32_t len;
+       __u32  len;
        struct irda_device_info dev[1];
 };
 
diff -u -p linux/drivers/net/irda/actisys.dag2.c linux/drivers/net/irda/actisys.c
--- linux/drivers/net/irda/actisys.dag2.c	Wed Dec  8 07:15:34 1999
+++ linux/drivers/net/irda/actisys.c	Wed Dec  8 07:16:28 1999
@@ -163,7 +163,7 @@ static int actisys_change_speed(struct i
 {
 	dongle_t *self = (dongle_t *) task->instance;
 	__u32 speed = (__u32) task->param;	/* Target speed */
-        int index = 0;
+        int i = 0;
 	int ret = 0;
 	
         IRDA_DEBUG(4, __FUNCTION__ "(), speed=%d (was %d)\n", speed, 
diff -u -p linux/net/irda/wrapper.dag2.c linux/net/irda/wrapper.c
--- linux/net/irda/wrapper.dag2.c	Wed Dec  8 07:22:03 1999
+++ linux/net/irda/wrapper.c	Wed Dec  8 07:24:52 1999
@@ -220,7 +220,7 @@ static void state_outside_frame(struct d
 		rx_buff->state = BEGIN_FRAME;
 		rx_buff->in_frame = TRUE;
 		
-		/* Set mbusy when SOP and prev char not SOP (IrLAP 6.13.3)
+		/* Set mbusy when SOP and prev char not SOP (IrLAP 6.13.3) */
 		irda_device_set_media_busy(dev, TRUE);
 		break;
 	case XBOF:
@@ -285,6 +285,8 @@ static void state_link_escape(struct dev
 {
 	switch (byte) {
 	case BOF: /* New frame? */
+		IRDA_DEBUG(1, __FUNCTION__ 
+			   "(), Discarding incomplete frame\n");
 		rx_buff->state = BEGIN_FRAME;
 		irda_device_set_media_busy(dev, TRUE);
 		break;
@@ -326,6 +328,8 @@ static void state_inside_frame(struct de
 
 	switch (byte) {
 	case BOF: /* New frame? */
+		IRDA_DEBUG(1, __FUNCTION__ 
+			   "(), Discarding incomplete frame\n");
 		rx_buff->state = BEGIN_FRAME;
 		irda_device_set_media_busy(dev, TRUE);
 		break;
diff -u -p linux/net/irda/af_irda.dag4.c linux/net/irda/af_irda.c
--- linux/net/irda/af_irda.dag4.c	Wed Dec  8 07:33:10 1999
+++ linux/net/irda/af_irda.c	Wed Dec  8 08:50:42 1999
@@ -484,6 +484,77 @@ static int irda_find_lsap_sel(struct ird
 }
 
 /*
+ * Function irda_discover_daddr_and_lsap_sel (self, name)
+ *
+ *    This try to find a device with the requested service.
+ *
+ * It basically look into the discovery log. For each address in the list,
+ * it queries the LM-IAS of the device to find if this device offer
+ * the requested service.
+ * At the first node that support the service requested, the function
+ * set both the destination address and the lsap selector to point
+ * on the service on that device.
+ */
+static int irda_discover_daddr_and_lsap_sel(struct irda_sock *self, char *name)
+{
+	discovery_t *discovery;
+	int err = -ENETUNREACH;
+
+	IRDA_DEBUG(2, __FUNCTION__ "(), name=%s\n", name);
+
+	ASSERT(self != NULL, return -1;);
+
+	/* Tell IrLMP we want to be notified */
+	irlmp_update_client(self->ckey, self->mask, NULL, 
+			    irda_discovery_indication);
+	
+	/* Do some discovery */
+	irlmp_discovery_request(self->nslots);
+		
+	/* Check if the we got some results */
+	if (!cachelog)
+		/* Wait for answer */
+		/*interruptible_sleep_on(&self->discovery_wait);*/
+		return -EAGAIN;
+
+	/* 
+	 * Now, check all discovered devices (if any), and connect
+	 * client only about the services that the client is
+	 * interested in 
+	 */
+	discovery = (discovery_t *) hashbin_get_first(cachelog);
+	while (discovery != NULL) {
+		/* Mask out the ones we don't want */
+		if (discovery->hints.word & self->mask) {
+			/* Try this address */
+			self->daddr = discovery->daddr;
+			IRDA_DEBUG(1, __FUNCTION__ "(), trying daddr = %08x\n", self->daddr);
+
+			/* Query remote LM-IAS for this service */
+			err = irda_find_lsap_sel(self, name);
+			if (err == 0)
+				/* We found the requested service */
+				break;
+		}
+
+		/* Next node, maybe we will be more lucky...  */
+		discovery = (discovery_t *) hashbin_get_next(cachelog);
+	}
+	cachelog = NULL;
+
+	/* Check out what we found */
+	if(err) {
+		IRDA_DEBUG(0, __FUNCTION__ "(), cannot discover requested service ''%s'' in any discovered device !!!\n", name);
+		self->daddr = 0;	/* Guessing */
+		return(err);
+	}
+
+	IRDA_DEBUG(0, __FUNCTION__ "(), discovered requested service ''%s'' at address %08x\n", name, self->daddr);
+
+	return 0;
+}
+
+/*
  * Function irda_getname (sock, uaddr, uaddr_len, peer)
  *
  *    Return the our own, or peers socket address (sockaddr_irda)
@@ -735,17 +806,25 @@ static int irda_connect(struct socket *s
 		return -EINVAL;
 
 	/* Check if user supplied the required destination device address */
-	if (!addr->sir_addr)
-		return -EINVAL;
-
-	self->daddr = addr->sir_addr;
-	IRDA_DEBUG(1, __FUNCTION__ "(), daddr = %08x\n", self->daddr);
-
-	/* Query remote LM-IAS */
-	err = irda_find_lsap_sel(self, addr->sir_name);
-	if (err) {
-		IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
-		return err;
+	if (!addr->sir_addr) {
+		/* Try to find one suitable */
+		err = irda_discover_daddr_and_lsap_sel(self, addr->sir_name);
+		if (err) {
+			IRDA_DEBUG(0, __FUNCTION__ "(), auto-connect failed!\n");
+			return -EINVAL;
+		}
+	}
+	else {
+		/* Use the one provided by the user */
+		self->daddr = addr->sir_addr;
+		IRDA_DEBUG(1, __FUNCTION__ "(), daddr = %08x\n", self->daddr);
+
+		/* Query remote LM-IAS */
+		err = irda_find_lsap_sel(self, addr->sir_name);
+		if (err) {
+			IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
+			return err;
+		}
 	}
 
 	/* Check if we have opened a local TSAP */
@@ -838,6 +917,7 @@ static int irda_create(struct socket *so
 	case SOCK_SEQPACKET:
 		sock->ops = &irda_seqpacket_ops;
 		self->max_sdu_size_rx = TTP_SAR_UNBOUND;
+		break;
 	case SOCK_DGRAM:
 		switch (protocol) {
 		case IRDAPROTO_ULTRA:
@@ -1043,6 +1123,9 @@ static int irda_recvmsg_dgram(struct soc
 	copied     = skb->len;
 	
 	if (copied > size) {
+		IRDA_DEBUG(2, __FUNCTION__ 
+			   "(), Received truncated frame (%d < %d)!\n",
+			   copied, size);
 		copied = size;
 		msg->msg_flags |= MSG_TRUNC;
 	}

--SLDf9lqlvOQaIe6s--




From afolz@logikos.com Wed, 08 Dec 1999 22:27:28 -0500
Date: Wed, 08 Dec 1999 22:27:28 -0500
From: Allan Folz afolz@logikos.com
Subject: [Linux-IrDA]Address Beaming with Palm's

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_vlRVAA/i+oB62AX8BeghUA)
Content-type: text/plain
Content-transfer-encoding: 7BIT

I have sent the following question to Palm Technical Support, but it
might 
be a while before I get an answer from them. Would anyone on this list
be 
able to help me out?

Thanks much,
-Allan


Sent to Tech Support:
I am writing an app that sends and receives vCARDs to a Palm PDA
via IrOBEX.

I have been able to connect my device as an IrDA client to a Palm
V and send a vCARD without any problems. When I do an IAS query of
"IrDA:TinyTP:LsapSel" and provide "OBEX" as the service name, the
Palm returns an LSAP which my client connects to.

The problem is when I try to beam a vCARD from the Palm to my
device. Does the Palm do an IAS query with the same attribute,
"IrDA:TinpTP:LsapSEL"? Also, what service name is the Palm quering
my device for?

--Boundary_(ID_vlRVAA/i+oB62AX8BeghUA)
Content-type: text/html
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.0.1457.3">

</HEAD>
<BODY>
<P><FONT SIZE=2>I have sent the following question to Palm Technical Support, but it might </FONT>
<BR><FONT SIZE=2>be a while before I get an answer from them. Would anyone on this list be </FONT>
<BR><FONT SIZE=2>able to help me out?</FONT>
<BR>
<BR><FONT SIZE=2>Thanks much,</FONT>
<BR><FONT SIZE=2>-Allan</FONT>
<BR>
<BR>
<BR><FONT SIZE=2>Sent to Tech Support:</FONT>
<BR><FONT SIZE=2>I am writing an app that sends and receives vCARDs to a Palm PDA</FONT>
<BR><FONT SIZE=2>via IrOBEX.</FONT>
<BR>
<BR><FONT SIZE=2>I have been able to connect my device as an IrDA client to a Palm</FONT>
<BR><FONT SIZE=2>V and send a vCARD without any problems. When I do an IAS query of</FONT>
<BR><FONT SIZE=2>&quot;IrDA:TinyTP:LsapSel&quot; and provide &quot;OBEX&quot; as the service name, the</FONT>
<BR><FONT SIZE=2>Palm returns an LSAP which my client connects to.</FONT>
<BR>
<BR><FONT SIZE=2>The problem is when I try to beam a vCARD from the Palm to my</FONT>
<BR><FONT SIZE=2>device. Does the Palm do an IAS query with the same attribute,</FONT>
<BR><FONT SIZE=2>&quot;IrDA:TinpTP:LsapSEL&quot;? Also, what service name is the Palm quering</FONT>
<BR><FONT SIZE=2>my device for?</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_vlRVAA/i+oB62AX8BeghUA)--




From jeant@rockfort.hpl.hp.com Wed, 8 Dec 1999 22:01:37 -0800
Date: Wed, 8 Dec 1999 22:01:37 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Ultra support for irda10

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii

	Hi dag,

	This is the result of my hacking on Ultra. I can have a ultra
message going from application to application (Yes, yes, yes !!!!), so
most of the plumbing is done (it's no longer a proof of concept)...
	However, it's not finished yet. The receive path in af_irda
doesn't remove the header, and irlmp doesn't verify the upid. And also
it doesn't work when LAP is connected. And then there is the cleanups
and all the comments I left in the code...
	Have fun...

	Jean

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ultra10.diff"

diff -u -p linux/include/net/irda/irda.d1.h linux/include/net/irda/irda.h
--- linux/include/net/irda/irda.d1.h	Wed Dec  8 10:59:10 1999
+++ linux/include/net/irda/irda.h	Wed Dec  8 12:07:33 1999
@@ -116,8 +116,9 @@ struct irda_sock {
 	__u32 saddr;          /* my local address */
 	__u32 daddr;          /* peer address */
 
-	struct lsap_cb *lsap; /* LSAP used by Ultra */
-	__u8  pid;            /* Protocol IP (PID) used by Ultra */
+	struct lsap_cb *lsap; /* LSAP (used by Ultra only) */
+	__u8  upid[4];	      /* Ultra Protocol IP (UPID - used by Ultra) */
+	__u8  upid_l;	      /* Length of the UPID */
 
 	struct tsap_cb *tsap; /* TSAP used by this connection */
 	__u8 dtsap_sel;       /* remote TSAP address */
diff -u -p linux/net/irda/af_irda.d1.c linux/net/irda/af_irda.c
--- linux/net/irda/af_irda.d1.c	Wed Dec  8 11:01:08 1999
+++ linux/net/irda/af_irda.c	Wed Dec  8 14:07:49 1999
@@ -75,7 +75,7 @@ static struct wait_queue *discovery_wait
 
 #define IRDA_MAX_HEADER (TTP_MAX_HEADER)
 #define ULTRA_MAX_DATA 382
-#define ULTRA_HEADER 1
+#define ULTRA_HEADER 4
 
 /*
  * Function irda_data_indication (instance, sap, skb)
@@ -426,7 +426,7 @@ static int irda_open_tsap(struct irda_so
  *    Open local Link Service Access Point (LSAP). Used for opening Ultra
  *    sockets
  */
-static int irda_open_lsap(struct irda_sock *self)
+static int irda_open_lsap(struct irda_sock *self, __u8 slsap_sel)
 {
 	notify_t notify;
 
@@ -441,7 +441,7 @@ static int irda_open_lsap(struct irda_so
 	notify.instance = self;
 	strncpy(notify.name, "Ultra", NOTIFY_MAX_NAME);
 
-	self->lsap = irlmp_open_lsap(0x70, &notify);	
+	self->lsap = irlmp_open_lsap(slsap_sel, &notify);	
 	if (self->lsap == NULL) {
 		IRDA_DEBUG( 0, __FUNCTION__ "(), Unable to allocate LSAP!\n");
 		return -ENOMEM;
@@ -634,23 +634,12 @@ static int irda_bind(struct socket *sock
 	self = sk->protinfo.irda;
 	ASSERT(self != NULL, return -1;);
 
-	if ((addr_len < sizeof(struct sockaddr_irda)) || 
-	    (addr_len > sizeof(struct sockaddr_irda)))
+	if (addr_len != sizeof(struct sockaddr_irda))
 		return -EINVAL;
 
 	/* Special care for Ultra sockets */
-	if ((sk->type == SOCK_DGRAM) && (sk->protocol == IRDAPROTO_ULTRA)) {
-		err = irda_open_lsap(self);
-		if (err < 0)
-			return err;
-		
-		self->pid = addr->sir_lsap_sel;
-		
-		self->max_data_size = ULTRA_MAX_DATA - ULTRA_HEADER;
-		self->max_header_size = IRDA_MAX_HEADER + ULTRA_HEADER;
-
-		return 0;
-	}
+	if ((sk->type == SOCK_DGRAM) && (sk->protocol == IRDAPROTO_ULTRA))
+		return -ESOCKTNOSUPPORT;
 
 	err = irda_open_tsap(self, addr->sir_lsap_sel, addr->sir_name);
 	if (err < 0)
@@ -673,6 +662,90 @@ static int irda_bind(struct socket *sock
 }
 
 /*
+ * Function irda_bind_ultra (sock, uaddr, addr_len)
+ *
+ *    Used by ultra application to specify their UPID (Ultra Protocol ID).
+ *
+ * Note : currently, we can bind only to LSAP 0x70, which is the spec.
+ * As SAPs 0x71-0x7F are undefined, we could imagine using them as well...
+ *
+ * Note bis : if we were *very* nice, we could provide two ULTRA services,
+ * with SAR and without SAR (by having different protocol number).
+ * I feel that having SAR with Ultra is asking for troubles, so for now
+ * we will leave the responsability of doing SAR in the application.
+ */
+static int irda_bind_ultra(struct socket *sock, struct sockaddr *uaddr,
+			   int addr_len)
+{
+	struct sock *sk = sock->sk;
+	struct sockaddr_irda *addr = (struct sockaddr_irda *) uaddr;
+	struct irda_sock *self;
+	/*__u16 hints = 0; - Is there a hint for ultra ? */
+	int lsap;
+	int upid_b;		/* UPID byte */
+	int i;
+	int err;
+
+	IRDA_DEBUG(2, __FUNCTION__ "()\n");
+
+	self = sk->protinfo.irda;
+	ASSERT(self != NULL, return -1;);
+
+	if (addr_len != sizeof(struct sockaddr_irda))
+		return -EINVAL;
+
+	/* Special care for non Ultra sockets */
+	if ((sk->type != SOCK_DGRAM) && (sk->protocol != IRDAPROTO_ULTRA))
+		return -ESOCKTNOSUPPORT;
+
+	/* Parse the daddr field to get the bytes and the size */
+	/* Note : should create out own sockaddr_irda structure
+	 * replacing daddr (that we don't use) by upid[4].
+	 * It would just fit in the same space, which is cool ! */
+	for(i = 0; i < 4; i++) {
+		/* Get one byte */
+		upid_b = (addr->sir_addr >> (8*i)) & 0xFF;
+		self->upid[i] = upid_b;
+
+		/* Check the extended flag */
+		if ((upid_b & 0x80) == 0)
+			break;
+	}
+	self->upid_l = i + 1;
+	/* Check if the fourth byte has the extended flag */
+	if((i == 4) || (i >= ULTRA_HEADER)) {
+		IRDA_DEBUG(0, __FUNCTION__ "(), UPID too long!\n");
+		return -EINVAL;
+	}
+
+	/* Create a LDSAP for us in LMP */
+	lsap = 0x70;	/* Fixme */
+	err = irda_open_lsap(self, lsap);
+	if (err < 0)
+		return err;
+	/* Set the destination LSAP we target */
+	self->lsap->dlsap_sel = lsap;
+	/* Note : we should set somehow the upid in the lsap so that
+	 * IrLMP is able to multiplex for us... */
+
+	/* Set max sizes of the different bits */
+	self->max_data_size = ULTRA_MAX_DATA - self->upid_l;
+	self->max_header_size = IRDA_MAX_HEADER + self->upid_l;
+
+	/* Move to connected state ??? */
+	sock->state = SS_CONNECTED;
+	sk->state   = TCP_ESTABLISHED;
+
+	/*  Register with LM-IAS - just for fun */
+	self->ias_obj = irias_new_object(addr->sir_name, jiffies);
+	irias_add_integer_attrib(self->ias_obj, "IrDA:Ultra:LsapSel", 
+				 self->stsap_sel);
+	irias_insert_object(self->ias_obj);
+
+	return 0;
+}
+
+/*
  * Function irda_accept (sock, newsock, flags)
  *
  *    Wait for incomming connection
@@ -1351,6 +1424,7 @@ static int irda_sendmsg_ultra(struct soc
 	struct irda_sock *self;
 	struct sk_buff *skb;
 	unsigned char *asmptr;
+	int i;
 	int err;
 	
 	IRDA_DEBUG(4, __FUNCTION__ "(), len=%d\n", len);
@@ -1366,6 +1440,12 @@ static int irda_sendmsg_ultra(struct soc
 	self = sk->protinfo.irda;
 	ASSERT(self != NULL, return -1;);
 
+	/* Check that we have something to send (LMP doesn't) */
+	if (len == 0) {
+		IRDA_DEBUG(1, __FUNCTION__ "(), No data\n");
+		return -1;
+	}
+
 	/*  
 	 * Check that we don't send out to big frames. This is an unreliable 
 	 * service, so we have no fragmentation and no coalescence 
@@ -1389,8 +1469,9 @@ static int irda_sendmsg_ultra(struct soc
 	memcpy_fromiovec(asmptr, msg->msg_iov, len);
 
 	/* Insert Ultra header */
-	skb_push(skb, ULTRA_HEADER);
-	skb->data[0] = self->pid;
+	skb_push(skb, self->upid_l);
+	for (i = 0; i < self->upid_l; i++)
+		skb->data[i] = self->upid[i];
 
 	err = irlmp_ultra_request(self->lsap, skb);
 	if (err) {
@@ -1768,7 +1849,7 @@ static struct proto_ops irda_ultra_ops =
        
 	sock_no_dup,
 	irda_release,
-	irda_bind,
+	irda_bind_ultra,
 	sock_no_connect,
 	sock_no_socketpair,
 	sock_no_accept,
diff -u -p linux/net/irda/irlap.d1.c linux/net/irda/irlap.c
--- linux/net/irda/irlap.d1.c	Wed Dec  8 10:51:37 1999
+++ linux/net/irda/irlap.c	Wed Dec  8 14:08:52 1999
@@ -336,6 +336,8 @@ inline void irlap_data_indication(struct
  */
 void irlap_unitdata_indication(struct irlap_cb *self, struct sk_buff *skb)
 {
+	__u8 *frame = skb->data;
+
 	IRDA_DEBUG(1, __FUNCTION__ "()\n"); 
 
 	ASSERT(self != NULL, return;);
@@ -346,7 +348,7 @@ void irlap_unitdata_indication(struct ir
 	skb_pull(skb, LAP_ADDR_HEADER+LAP_CTRL_HEADER);
 
 #ifdef CONFIG_IRDA_COMPRESSION
-	if (self->qos_tx.compression.value) {
+	if (self->qos_tx.compression.value && (frame[0] != 0xFF)) {
 		
 		skb = irlap_decompress_frame(self, skb);
 		if (!skb) {
@@ -395,6 +397,8 @@ void irlap_data_request(struct irlap_cb 
 		IRDA_DEBUG(4, __FUNCTION__ "(), queueing unreliable frame\n");
 		skb->data[1] = UI_FRAME;
 	}
+	/* Specify that it is not a broadcast frame, will be set later */
+	skb->data[0] = 0x0;
 
 	/* 
 	 *  Send event if this frame only if we are in the right state 
@@ -419,11 +423,27 @@ void irlap_data_request(struct irlap_cb 
 /*
  * Function irlap_udata_request (self, skb)
  *
- *    Send Ultra data. This is data that must be sent outside any connection
+ *    Send Broadcast Frame (for the connectionless SAP).
+ *	This is data that must be sent outside any connection
  *
+ * Note : rename to irlap_bdata_request or irlap_budata_request
+ * Note : rename SEND_UI_FRAME to SEND_BROADCAST_FRAME
+ * Explanation : UI frame within a connection don't go through here...
  */
 void irlap_udata_request(struct irlap_cb *self, struct sk_buff *skb)
 {
+	ASSERT(self != NULL, return;);
+	ASSERT(self->magic == LAP_MAGIC, return;);
+
+	IRDA_DEBUG(3, __FUNCTION__ "()\n");
+
+	ASSERT(skb_headroom(skb) >= (LAP_ADDR_HEADER+LAP_CTRL_HEADER), 
+	       return;);
+	skb_push(skb, LAP_ADDR_HEADER+LAP_CTRL_HEADER);
+
+	skb->data[0] = 0xFF;	/* Fixme to UIBROADCAST */
+	skb->data[1] = UI_FRAME;
+
 	skb_queue_tail(&self->txq_ultra, skb);
 
 	irlap_do_event(self, SEND_UI_FRAME, NULL, NULL);
@@ -434,6 +454,10 @@ void irlap_udata_request(struct irlap_cb
  *
  *    Receive Ultra data. This is data that is received outside any connection
  *
+ * Note : rename to irlap_bdata_indication or irlap_budata_indication
+ * Explanation : UI frame within a connection don't go through here...
+ *
+ * Function no longer used...
  */
 void irlap_udata_indication(struct irlap_cb *self, struct sk_buff *skb)
 {
@@ -442,6 +466,10 @@ void irlap_udata_indication(struct irlap
 	ASSERT(self != NULL, return;);
 	ASSERT(self->magic == LAP_MAGIC, return;);
 	ASSERT(skb != NULL, return;);
+
+	/* Note : in theory, we have already checked in irlap_recv_ui_frame
+	 * if it's a braodcast frame, so we don't need to filter out
+	 * unicast frames here... */
 
 	/* Hide LAP header from IrLMP layer */
 	skb_pull(skb, LAP_ADDR_HEADER+LAP_CTRL_HEADER);
diff -u -p linux/net/irda/irlap_event.d1.c linux/net/irda/irlap_event.c
--- linux/net/irda/irlap_event.d1.c	Wed Dec  8 12:28:42 1999
+++ linux/net/irda/irlap_event.c	Wed Dec  8 14:09:17 1999
@@ -421,7 +421,10 @@ static int irlap_state_ndm(struct irlap_
 		}
 		break;
 	case RECV_UI_FRAME:
-		irlap_udata_indication(self, skb);
+		/* We can only receive broadcast frames in disconnected mode */
+		if(skb->data[0] == 0xFF /* Fixme */)
+			irlap_unitdata_indication(self, skb);
+		/*was irlap_udata_indication(self, skb);*/
 		break;
 	case RECV_TEST_CMD:
 		/* Remove test frame header */
diff -u -p linux/net/irda/irlap_frame.d1.c linux/net/irda/irlap_frame.c
--- linux/net/irda/irlap_frame.d1.c	Wed Dec  8 12:31:13 1999
+++ linux/net/irda/irlap_frame.c	Wed Dec  8 13:15:27 1999
@@ -1000,9 +1000,12 @@ void irlap_send_ui_frame(struct irlap_cb
 	
 	frame = skb->data;
 	
-	/* Insert connection address */
-	frame[0] = self->caddr;
-	frame[0] |= (command) ? CMD_FRAME : 0;
+	/* Detect broadcast frames - a bit hackish, so what ? */
+	if(frame[0] != 0xFF) {
+		/* Insert connection address */
+		frame[0] = self->caddr;
+		frame[0] |= (command) ? CMD_FRAME : 0;
+	}
 
 	irlap_queue_xmit(self, skb);
 }
diff -u -p linux/net/irda/irlmp.d1.c linux/net/irda/irlmp.c
--- linux/net/irda/irlmp.d1.c	Wed Dec  8 10:43:30 1999
+++ linux/net/irda/irlmp.c	Wed Dec  8 12:24:09 1999
@@ -971,8 +971,9 @@ void irlmp_udata_indication(struct lsap_
 /*
  * Function irlmp_ultra_request (self, skb)
  *
- *    
+ *    Send a frame on the Connectionless SAP (unreliable & broadcast)
  *
+ * Note : rename to irlmp_conless_request
  */
 int irlmp_ultra_request(struct lsap_cb *self, struct sk_buff *skb) 
 {
@@ -987,8 +988,9 @@ int irlmp_ultra_request(struct lsap_cb *
 	ASSERT(skb_headroom(skb) >= LMP_HEADER, return -1;);
 	skb_push(skb, LMP_HEADER);
 
-	/* Ultra sockets must use 0x70 */
-	skb->data[0] = skb->data[1] = 0x70;
+	/* Ultra sockets must use 0x70, but it's all set up */
+	skb->data[0] = self->dlsap_sel;
+	skb->data[1] = self->slsap_sel;
 
 	/* Try to send Ultra packets out on all links */
 	lap = (struct lap_cb *) hashbin_get_first(irlmp->links);
@@ -999,6 +1001,7 @@ int irlmp_ultra_request(struct lsap_cb *
 		if (!clone_skb)
 			return -ENOMEM;
 
+		//irlap_data_request(self->irlap, skb, FALSE);
 		irlap_udata_request(lap->irlap, clone_skb);
 		
 		lap = (struct lap_cb *) hashbin_get_next(irlmp->links);
diff -u -p linux/net/irda/irlmp_event.d1.c linux/net/irda/irlmp_event.c
--- linux/net/irda/irlmp_event.d1.c	Wed Dec  8 14:14:08 1999
+++ linux/net/irda/irlmp_event.c	Wed Dec  8 13:59:27 1999
@@ -444,6 +444,11 @@ static int irlmp_state_disconnected(stru
 
 		irlmp_do_lap_event(self->lap, LM_LAP_CONNECT_REQUEST, NULL);
 		break;
+	case LM_UDATA_INDICATION:
+		/* In theory, we can arrive here only if this is a 
+		 * connectionless lsap (used by Ultra) */
+		irlmp_udata_indication(self, skb); 
+		break;
 	default:
 		IRDA_DEBUG(2, __FUNCTION__ "(), Unknown event %s\n", 
 			   irlmp_event[event]);
diff -u -p linux/net/irda/irlmp_frame.d1.c linux/net/irda/irlmp_frame.c
--- linux/net/irda/irlmp_frame.d1.c	Wed Dec  8 14:14:08 1999
+++ linux/net/irda/irlmp_frame.c	Wed Dec  8 14:10:14 1999
@@ -37,6 +37,12 @@
 static struct lsap_cb *irlmp_find_lsap(struct lap_cb *self, __u8 dlsap, 
 				       __u8 slsap, int status, hashbin_t *);
 
+static struct lsap_cb *irlmp_find_ultra_lsap(struct lap_cb *self,
+					     __u8 dlsap_sel,
+					     __u8 slsap_sel,
+					     hashbin_t *queue,
+					     __u8 *upid);
+
 inline void irlmp_send_data_pdu(struct lap_cb *self, __u8 dlsap, __u8 slsap,
 				int expedited, struct sk_buff *skb)
 {
@@ -126,10 +132,20 @@ void irlmp_link_data_indication(struct l
 		if (!lsap)
 			lsap = irlmp_find_lsap(self, dlsap_sel, slsap_sel, 0,
 					       self->lsaps);
-	} else
-		lsap = irlmp_find_lsap(self, dlsap_sel, slsap_sel, 0, 
-				       self->lsaps);
-	
+	} else {
+		/* Check if we deal with the connectionless SAPs */
+		if(((dlsap_sel & 0x70) == 0x70) &&
+		   ((slsap_sel & 0x70) == 0x70))
+			lsap = irlmp_find_ultra_lsap(self,
+						     dlsap_sel, slsap_sel, 
+						     irlmp->unconnected_lsaps,
+						     &fp[2]);
+		else
+			lsap = irlmp_find_lsap(self, dlsap_sel, slsap_sel, 0, 
+					       self->lsaps);
+	}
+
+printk("lsap = %p, 0x%X, 0x%X\n", lsap, slsap_sel, dlsap_sel);
 	if (lsap == NULL) {
 		IRDA_DEBUG(2, "IrLMP, Sorry, no LSAP for received frame!\n");
 		IRDA_DEBUG(2, __FUNCTION__ 
@@ -182,7 +198,7 @@ void irlmp_link_data_indication(struct l
 	} else if (reliable == LAP_UNRELIABLE) {
 		/* Optimize and bypass the state machine if possible */
 		if (lsap->lsap_state == LSAP_DATA_TRANSFER_READY)
-			irlmp_data_indication(lsap, skb);
+			irlmp_udata_indication(lsap, skb);
 		else
 			irlmp_do_lsap_event(lsap, LM_UDATA_INDICATION, skb);
 	}
@@ -370,6 +386,60 @@ static struct lsap_cb *irlmp_find_lsap(s
 			irlmp_update_cache(lsap);
 #endif
 			return lsap;
+		}
+		lsap = (struct lsap_cb *) hashbin_get_next(queue);
+	}
+
+	/* Sorry not found! */
+	return NULL;
+}
+
+
+/*
+ * Function irlmp_find_ultra_lsap (self, dlsap_sel, slsap_sel, status, queue)
+ *
+ *    Look for the Connectionless SAP that match the UPID desired
+ *
+ */
+static struct lsap_cb *irlmp_find_ultra_lsap(struct lap_cb *self,
+					     __u8 dlsap_sel,
+					     __u8 slsap_sel,
+					     hashbin_t *queue,
+					     __u8 *upid)
+{
+	struct lsap_cb *lsap;
+	
+	/* Note : should we trash the lsap cache ?
+	 * should we have our own lsap cache ? */
+
+	/* 
+	 *  Optimize for the common case. We assume that the last frame
+	 *  received is in the same connection as the last one, so check in
+	 *  cache first to avoid the linear search
+	 */
+#ifdef CONFIG_IRDA_CACHE_LAST_LSAP
+	if ((irlmp->cache.valid) && 
+	    (irlmp->cache.slsap_sel == slsap_sel) && 
+	    (irlmp->cache.dlsap_sel == dlsap_sel)) 
+	{
+		return (irlmp->cache.lsap);
+	}
+#endif
+	lsap = (struct lsap_cb *) hashbin_get_first(queue);
+	while (lsap != NULL) {
+		/*
+		 *  Check if source LSAP and dest LSAP selectors match.
+		 */
+		if ((lsap->slsap_sel == slsap_sel) && 
+		    (lsap->dlsap_sel == dlsap_sel)) 
+		{
+			/* At this point, we should check the upid */
+			if(upid != NULL /* place-holder */) {
+#ifdef CONFIG_IRDA_CACHE_LAST_LSAP
+				irlmp_update_cache(lsap);
+#endif
+				return lsap;
+			}
 		}
 		lsap = (struct lsap_cb *) hashbin_get_next(queue);
 	}

--MGYHOYXEY6WxJCY8--




From daver@idiom.com Wed, 8 Dec 1999 23:12:39 -0800
Date: Wed, 8 Dec 1999 23:12:39 -0800
From: David Ray daver@idiom.com
Subject: [Linux-IrDA]Re: IrDA on LinuxPPC

At 1:39 AM +0100 12/9/99, Martin Ritchie <martin@stronafian.freeserve.co.uk wrote:
> I'm new to the linux world so please bare with my poor knowledge.
> 
> What rpm/bits do I need to install the IrDA stuff on my mac.
> I have an iMac and would be eager to get the ir port working.

Someone else asked yesterday too about the status of IRDA on PPC. I seem to be the only one in this IRDA group doing this on a PPC system. I have an Apple Macintosh Powerbook G3 (running LinuxPPC 1999 Q3 also, and kernel 2.2.13 from kernel.org) and a few weeks ago was finally successful to get IRDA to work on the Powerbook. However it's not fully tested as I don't own much IRDA equipment.  You can search the archives of this list from a couple weeks ago to see my detailed post. Basically I can run the latest IRDA irdadump and see packets on /dev/ttyS1 which the kernel sees as an IR port.

There are no RPM's at this point. In order to use IRDA you need to recompile the kernel yourself with IRDA support or get a special kernel from someone who has done this. You also need to compile the set if irda-utils. I'm not aware of anybody who has made the PPC binaries available precompiled (perhaps I should do that?). Everything compiles pretty well out of the box (Thanks Dag!). My biggest challenge is finding the equipment and the time to test all the protocols. My personal interest is mainly for syncing data with the Palm Pilot or the Newton, but I don't own the equipment yet (I haven't decided which to get yet, not real impressed with the Pilot and the Newton is discontinued.) I hope to have more time for testing my IRDA in the next few weeks.

-Dave







From mtepperis@pdv-online.de Thu, 9 Dec 1999 10:12:04 +0100
Date: Thu, 9 Dec 1999 10:12:04 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: article about Linux-IrDA - was: [Linux-IrDA]linux-2.2.13-irda9 and IrLAN

hi,

sorry I can`t help.

I just want to mention that there is a good article about Linux-IrDA in the
german magazine 'iX', current issue.

they had good experience especially with IrLAN. They used a Siemens and a
Dell laptop.


>I've recently started to play around with my IrDA port of my ThinkPad. I'm
>in particular interestet in conecting two linux boxes (in this case two
>identical TP's) via IrLAN. This basicaly works fine, but the two ThinkPads
>don't reconnect probable after the conncetion got lost. Is this a known


have fun
 michael






From mtepperis@pdv-online.de Thu, 9 Dec 1999 11:50:52 +0100
Date: Thu, 9 Dec 1999 11:50:52 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: [Linux-IrDA]Re: IrDA on LinuxPPC

hi,


> I have an Apple Macintosh Powerbook G3 (running LinuxPPC 1999

same for me

> Q3 also, and kernel 2.2.13 from kernel.org) and a few weeks 
> fully tested as I don't own much IRDA equipment.  You can 

currently I have a Motorola L ?069 phone, which is discovered as
'L series' with a JetEYE dongle ('esi' driver) attached to a x86
desktop. secondly I own a digital camera with ir support, kodak 210+.

next I want to run the following tests between:
  dongle     &  digital camera
  dongle     &  powerbook 
  powerbook  &  phone
  powerbook  &  digital camera

if I have success with the powerbook I 'll run a test via
IrLPT to a HP 2100TN on work.
 
>to have more time for testing my IRDA in the next few weeks.


I'll do that on the next weekend.

have fun 
 michael






From Tom.Grydeland@phys.uit.no Thu, 9 Dec 1999 11:48:33 +0100 (MET)
Date: Thu, 9 Dec 1999 11:48:33 +0100 (MET)
From: Tom Grydeland Tom.Grydeland@phys.uit.no
Subject: article about Linux-IrDA - was: [Linux-IrDA]linux-2.2.13-irda9
 and IrLAN

On Thu, 9 Dec 1999, Michael Tepperis wrote:

> I just want to mention that there is a good article about Linux-IrDA in the
> german magazine 'iX', current issue.

Is the article available online?

Perhaps you should bring this to the attention of Linux Weekly News
<URL:http://lwn.net/>

>  michael

-- 
//Tom Grydeland <Tom.Grydeland@phys.uit.no>





From stefan.roellin@switzerland.org Thu, 09 Dec 1999 12:16:11 +0100 (MET)
Date: Thu, 09 Dec 1999 12:16:11 +0100 (MET)
From: stefan.roellin@switzerland.org stefan.roellin@switzerland.org
Subject: article about Linux-IrDA - was: [Linux-IrDA]linux-2.2.13-irda9 and
 IrLAN

On Thu, 9 Dec 1999, Tom Grydeland wrote:

> On Thu, 9 Dec 1999, Michael Tepperis wrote:
> 
> > I just want to mention that there is a good article about Linux-IrDA in the
> > german magazine 'iX', current issue.
> 
> Is the article available online?
> 

Yes. See http://www.heise.de/ix/artikel/1999/12/156/ (german). An english
version seems not to be available.

Stefan





From mtepperis@pdv-online.de Thu, 9 Dec 1999 13:14:45 +0100
Date: Thu, 9 Dec 1999 13:14:45 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: article about Linux-IrDA - was: [Linux-IrDA]linux-2.2.13-irda9and IrLAN

hi,

>> I just want to mention that there is a good article about Linux-IrDA in
the
>> german magazine 'iX', current issue.
>
>Is the article available online?


yes

http://www.heise.de/ix/artikel/1999/12/156/


>Perhaps you should bring this to the attention of Linux Weekly News
><URL:http://lwn.net/>


okay, I'll give it to lwn and a german site named www.pro-linux.de

have fun
 michael






From dagb@cs.uit.no 09 Dec 1999 13:12:46 +0100
Date: 09 Dec 1999 13:12:46 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]patch-2.2.13-irda11 is out!

Hi,

The development is going very fast these days (lucky for us!), so here is a 
new patch (this patch includes all other patches).


Changes since -irda10:

o Fixed a lot of Ultra stuff (Jean and me).

o Fixed bug in IrCOMM which resulted in very strange behavior. The IrCOMM
  link could suddenly break etc. (me)

o Added IRLMP_HINTS_SET setsockopt to af_irda.c. Now you can register hints 
  that you want to be added to the discovery frames from the sockets
  interface (me)

o Fixed data type problems in irda.h (again). Now you must include
  <sys/types.h> before <linux/irda.h> if you intend to use it from
  user-space. (me)

o Made sure LSAP selectors above 0x6f are never used for normal
  connections. (me)

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 09 Dec 1999 12:45:44 +0100
Date: 09 Dec 1999 12:45:44 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Auto-connect...

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Hi everybody...
> 
> 	I added a new feature to connect : if you don't specify a
> device address, the IrDA stack will try to find one for you (doing
> discovery and all that jazz). Of course, if you specify an address,
> the old behaviour is used...
> 	Patch below...
> 
> 	Jean

> +	/* Check if user supplied the required destination device address */
> +	if (!addr->sir_addr) {
> +		/* Try to find one suitable */
> +		err = irda_discover_lsap_sel(self, addr->sir_name);
> +		if (err) {
> +			IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
> +			return -EINVAL;
> +		}
> +	}
> +	else {
> +		/* Use the one provided by the user */
> +		self->daddr = addr->sir_addr;
> +		IRDA_DEBUG(1, __FUNCTION__ "(), daddr = %08x\n", self->daddr);
> +
> +		/* Query remote LM-IAS */
> +	<-	err = irda_find_lsap_sel(self, addr->sir_name);
> +	<-	if (err) {
> +	<-		IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
> +	<-		return err;
> +	<-	}

Shouldn't the Query of the remote LM-IAS be done in any case? Since your
discover_lsap_sel() only discovers addresses (and should be renamed) and
does not query the LM-IAS, then the query will not be done when you don't
specify the device address!? Have marked my suggestions with <-.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 09 Dec 1999 12:54:15 +0100
Date: 09 Dec 1999 12:54:15 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Ultra support for irda10

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Hi dag,
> 
> 	This is the result of my hacking on Ultra. I can have a ultra
> message going from application to application (Yes, yes, yes !!!!), so
> most of the plumbing is done (it's no longer a proof of concept)...
> 	However, it's not finished yet. The receive path in af_irda
> doesn't remove the header, and irlmp doesn't verify the upid. And also
> it doesn't work when LAP is connected. And then there is the cleanups
> and all the comments I left in the code...
> 	Have fun...
> 
> 	Jean

Hi Jean!
 
OK, I've looked through your patch, and I have applied some of it. But I
decided to do things a bit different:

o I see no reason to support Ultra PID's with extension bytes. There will
  _never_ be any use for it! IrDA have reserved all pid's and they have only
  specified one (0x01 for Ultra). This mechanism is the same as for hint
  bytes, and nobody supports more than 2 hint bytes!!! Therefore I have
  choosen not to use your irda_ultra_bind() function.
 
o I have also moved the PID byte from af_irda.c down to irlmp.c. So now you
  can open as many connless LSAP's as you want, and IrLMP will demultiplex
  based on the pid! The only reason to not have only one connless LSAP and do
  refcounting, is that we need to have different callbacks to the different
  sockets opening the connless LSAP. I know this is incorrect (in theory), 
  but again. The connectionless LSAP will only be used by Ultra!! No need
  to support anything else, at least not in the main distribution! Making a 
  separate Ultra layer is out of the question ;-)

o No support for connectionless LSAPs with selectors other than 0x70. The
  spec says this is the _only_ connless LSAP, and that we should drop all
  frames containing higher selectors. If we have support for this, the we
  might fail a compliance test, so again this will not go into the main
  distribution.

o IrLAP now sets the conn addr to broadcast whenever it goes into NDM,
  which makes it simpler to send out correct UI frames. Remember that you
  cannot send out UI frames using the broadcast address while a connection is
  running, so the use of SEND_I_FRAME and SEND_UI_FRAME is good enough as is.

Hope you don't get really mad at me, but I think this is the best to
do. This will give us a good Ultra functionality and an impl. which is easy
to debug (and that is usually my job ;-) If you feel I'm destroying
everything, then please tell me since I really want you to continue
torturing and extending the Linux-IrDA stack. You're doing a really great
job!!

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 09 Dec 1999 15:35:39 +0100
Date: 09 Dec 1999 15:35:39 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: article about Linux-IrDA - was: [Linux-IrDA]linux-2.2.13-irda9 and  IrLAN

stefan.roellin@switzerland.org writes:

> On Thu, 9 Dec 1999, Tom Grydeland wrote:
> 
> > On Thu, 9 Dec 1999, Michael Tepperis wrote:
> > 
> > > I just want to mention that there is a good article about Linux-IrDA in the
> > > german magazine 'iX', current issue.
> > 
> > Is the article available online?
> > 
> 
> Yes. See http://www.heise.de/ix/artikel/1999/12/156/ (german). An english
> version seems not to be available.

Just use http://babelfish.altavista.com, to read an English version. Does
not translate the whole document tho'

-- Dag
 
-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 09 Dec 1999 16:12:51 +0100
Date: 09 Dec 1999 16:12:51 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]patch-2.2.13-irda11 is out!

Dag Brattli <dagb@cs.uit.no> writes:

> The development is going very fast these days (lucky for us!), so here is a 
> new patch (this patch includes all other patches).

Made a silly bug in 2.2.13-irda11, so go for -irda12 instead. It should fix 
a lot of memory leaks as well ;-)

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From fluch@rock.helsinki.fi Thu, 9 Dec 1999 19:41:10 +0200 (EET)
Date: Thu, 9 Dec 1999 19:41:10 +0200 (EET)
From: Martin Fluch fluch@rock.helsinki.fi
Subject: [Linux-IrDA]linux-2.2.13-irda12 fails to compile...

-----BEGIN PGP SIGNED MESSAGE-----

Hello,

if just tried to compile the 2.2.13 kernel with the irda12 patch applied,
and it fails to compile:

irlap_event.c: In function `irlap_state_ndm':
irlap_event.c:416: too many arguments to function `irlap_send_ui_frame'
make[3]: *** [irlap_event.o] Error 1

Martin

- -- 
Where do you want to go today? - As far from Redmond as possible!

For public PGP-key: finger mfluch@mathphys.fsk.uni-heidelberg.de


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBOE/pu7CGSMW7I2etAQGNGgQAiPWSAOgq/g2B8qlSEwnqujyTA5Ca7ePk
2O9jX8X3JpIDRDwPBmtmkPjj4QH14Q/kyZPDxI77Obk7TjveeQYILdTFRYBymiW4
pmLnGJt/UsIlVn5cOJMl0G8aXrnKG0EMIpCYPfThaaYiMpNjphBrweIyKYFxfHx2
sb1poea9YQo=
=ygvk
-----END PGP SIGNATURE-----





From jeant@rockfort.hpl.hp.com Thu, 9 Dec 1999 09:52:47 -0800
Date: Thu, 9 Dec 1999 09:52:47 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Auto-connect

Dag wrote : 
> 
> > +     <-      err = irda_find_lsap_sel(self, addr->sir_name);
> > +     <-      if (err) {
> > +     <-              IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
> > +     <-              return err;
> > +     <-      }
> 
> Shouldn't the Query of the remote LM-IAS be done in any case? Since your
> discover_lsap_sel() only discovers addresses (and should be renamed) and
> does not query the LM-IAS, then the query will not be done when you don't
> specify the device address!? Have marked my suggestions with <-.

	You are completely wrong. Go to re-read the patch carefully.

	By the way, I reimplemented it a bit cleaner in the assorted
patches for irda10. Have you seen this patch ? It fixes many important
bug. As you seem to read patches in diagonal, I will have to make sure
that you haven't forgotten any of the correct fixes.

> -- Dag

	Jean




From Stephane.FILLOD@st.com Thu, 9 Dec 1999 11:37:53 -0700
Date: Thu, 9 Dec 1999 11:37:53 -0700
From: Stephane.FILLOD@st.com Stephane.FILLOD@st.com
Subject: [Linux-IrDA]2.2.13-irda9+smc-ircc module does not load


vanialla 2.2.13 patched with 2.2.13-irda9 compiles fine, but the smc-ircc module
does not load, because of the lack of some symbols.

The symbols are from irport module (irport_stop, __irport_change_speed, etc.), 
which IS loaded, but it looks like they are not exported.
Dag, can you have a look ?

REM: you don't need to have SMC hardware to test that.


As soon as it is fixed, I'll be able to investigate why the smc-ircc is 
unable to send frames longer than 1500 bytes with DMA at 4Mbps, resulting 
most of the time in crashes..


Stephane





From jeant@rockfort.hpl.hp.com Thu, 9 Dec 1999 11:02:41 -0800
Date: Thu, 9 Dec 1999 11:02:41 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Re: Ultra support for irda10

Dag wrote :
> Hi Jean!
>  
> OK, I've looked through your patch, and I have applied some of it. But I
> decided to do things a bit different:
> 
> o I see no reason to support Ultra PID's with extension bytes. There will
>   _never_ be any use for it! IrDA have reserved all pid's and they have only
>   specified one (0x01 for Ultra). This mechanism is the same as for hint
>   bytes, and nobody supports more than 2 hint bytes!!! Therefore I have
>   choosen not to use your irda_ultra_bind() function.

	With all due respect, this is really a stupid decision. This
functionality was working (as opposed to your patches) and was
conformant to the spec, and there is absolutely no reason to remove
it. You limit the number of protocols on top of Ultra to 127, which is
not much (we don't have dynamic allocation here). If I follow your
reasoning, let's remove Ultra because nobody will _never_ use it.

> o I have also moved the PID byte from af_irda.c down to irlmp.c. So now you
>   can open as many connless LSAP's as you want, and IrLMP will demultiplex
>   based on the pid! The only reason to not have only one connless LSAP and do
>   refcounting, is that we need to have different callbacks to the different
>   sockets opening the connless LSAP. I know this is incorrect (in theory), 
>   but again. The connectionless LSAP will only be used by Ultra!! No need
>   to support anything else, at least not in the main distribution! Making a 
>   separate Ultra layer is out of the question ;-)

	This was exactly what I was proposing (see my comments in the
code) and I had started to do.

> o No support for connectionless LSAPs with selectors other than 0x70. The
>   spec says this is the _only_ connless LSAP, and that we should drop all
>   frames containing higher selectors. If we have support for this, the we
>   might fail a compliance test, so again this will not go into the main
>   distribution.

	I just hope you didn't hardcoded 0x70 all over the place. My
code was careful to strike a balance between compliance to the spec
and future extensibility.

> o IrLAP now sets the conn addr to broadcast whenever it goes into NDM,
>   which makes it simpler to send out correct UI frames. Remember that you
>   cannot send out UI frames using the broadcast address while a connection is
>   running, so the use of SEND_I_FRAME and SEND_UI_FRAME is good enough as is.

	Whatever.

> Hope you don't get really mad at me, but I think this is the best to
> do. This will give us a good Ultra functionality and an impl. which is easy
> to debug (and that is usually my job ;-)

	Currently, I feel that's it's me doing most of the debugging
and correcting your mistakes in the code.

> If you feel I'm destroying
> everything, then please tell me since I really want you to continue
> torturing and extending the Linux-IrDA stack. You're doing a really great
> job!!

	Try to read a bit more carefully patches, comments and so on,
and try to understand what the patch is doing instead of seeing it
only the way you feel.

> -- Dag

	Jean




From tadavis@veriomail.com Thu, 9 Dec 1999 12:03:57 -0800
Date: Thu, 9 Dec 1999 12:03:57 -0800
From: Thomas Davis tadavis@veriomail.com
Subject: [Linux-IrDA]Re: Ultra support for irda10

[ not posted to the list ]

On Thu, 09 Dec 1999, Jean Tourrilhes wrote:
>	Currently, I feel that's it's me doing most of the debugging
>and correcting your mistakes in the code.
>

welcome to dag's world..  :-)




From fluch@rock.helsinki.fi Thu, 9 Dec 1999 22:21:02 +0200 (EET)
Date: Thu, 9 Dec 1999 22:21:02 +0200 (EET)
From: Martin Fluch fluch@rock.helsinki.fi
Subject: [Linux-IrDA]patch for irda-utils 0.9.5

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1480499767-593744558-944770862=:364
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I've allread posted something about this, but let's say it a bit
different: It would be nice, if the attached patch would be applied to the
irmanager.c code. It changes the behavior of the irmanager on exiting
after receiving a SIGTERM, SIGINT or SIGHUP.

I find it inconsistent, if the irmanager fires up the whole irda stuff (by
calling /etc/irda/drivers start) but on exit there is no way to automate
the removal of those irda drivers (which should be done, IMO, by executing
/etc/irda/drivers stop). The patch romoves this inconsistent behavior.

The following lines are from my /etc/irda/drivers script, which works fine
for me:

#! /bin/sh

action=$1
device=$2

case "${action:?}" in
'start')
	irattach /dev/ttyS0	     # The first serial port is an IrDA port
	modprobe irlan 		     # activate irlan support
    ;;
'stop')
	ifconfig | grep irlan0 >/dev/null && \
		ifconfig irlan0 down # shutdown the network
	killall irattach             # detache all IrDA ports 
	modprobe -r irlan irtty irda # remove modules
    ;;
esac

Any comments?

Martin

---1480499767-593744558-944770862=:364
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="irmanager.c.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9912092221020.364@fun93.kivikko.hoas.fi>
Content-Description: 
Content-Disposition: attachment; filename="irmanager.c.diff"

LS0tIGlybWFuYWdlci5jLm9yaWcJVHVlIE5vdiAgOSAxNjoyNjo1MCAxOTk5
DQorKysgaXJtYW5hZ2VyLmMJV2VkIERlYyAgOCAyMDoxODo0MiAxOTk5DQpA
QCAtNjMsNiArNjMsOCBAQCBjaGFyICpwaWRmaWxlID0gIi92YXIvcnVuL2ly
bWFuYWdlci5waWQiDQogI2RlZmluZSBCRUVQX1dBUk4gMjAwMA0KICNkZWZp
bmUgQkVFUF9FUlIgIDQwMDANCiANCitpbnQgZGV2X2ZkPS0xOw0KKw0KIC8q
DQogICogRnVuY3Rpb24gc3RhcnRfc2VydmljZSAoc2VydmljZSwgZGV2X25h
bWUpDQogICoNCkBAIC0xMjIsMTkgKzEyNCwzMiBAQCBpbnQgbG9hZF9tb2R1
bGUoY2hhciAqbmFtZSkNCiANCiBzdGF0aWMgdm9pZCBjbGVhbnVwKGludCBz
aWdubykNCiB7DQorCWludCBleGl0aW5nPUZBTFNFOw0KKwkNCiAJc3dpdGNo
IChzaWdubykgew0KIAljYXNlIFNJR1RFUk06DQogCWNhc2UgU0lHSU5UOg0K
IAkgICAgICAgIHN5c2xvZyhMT0dfSU5GTywgImdvdCBTSUdURVJNIG9yIFNJ
R0lOVFxuIik7DQotCQlleGl0KDApOw0KKwkJZXhpdGluZz1UUlVFOw0KIAkJ
YnJlYWs7DQogCWNhc2UgU0lHSFVQOg0KIAkgICAgICAgIHN5c2xvZyhMT0df
SU5GTywgImdvdCBTSUdIVVBcbiIpOw0KLQkJZXhpdCgwKTsNCisJCWV4aXRp
bmc9VFJVRTsNCiAJCWJyZWFrOw0KIAlkZWZhdWx0Og0KIAkJYnJlYWs7DQog
CX0NCisNCisJaWYoZXhpdGluZykNCisJew0KKwkJaWYoZGV2X2ZkPi0xKQ0K
KwkJew0KKwkJCWNsb3NlKGRldl9mZCk7DQorCQkJZGV2X2ZkPS0xOw0KKwkJ
fQ0KKwkJc3RvcF9zZXJ2aWNlKCJkcml2ZXJzIiwgIiIpOw0KKwkJZXhpdCgw
KTsNCisJfQ0KIAl1bmxpbmsocGlkZmlsZSk7DQogfQ0KIA0KQEAgLTE1MCw3
ICsxNjUsNiBAQCBpbnQgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQ0K
IAlzdHJ1Y3QgaXJtYW5hZ2VyX2V2ZW50IGV2ZW50Ow0KIAlzdHJ1Y3QgdXRz
bmFtZSBidWY7DQogCWludCBub3RfdXNlZDsgLyogRm9yIG5vdyEgKi8NCi0J
aW50IGZkOwkNCiAJaW50IG1pbm9yOw0KIAlpbnQgcmV0Ow0KIAlpbnQgYzsN
CkBAIC0yMDMsOCArMjE3LDggQEAgaW50IG1haW4oaW50IGFyZ2MsIGNoYXIg
KmFyZ3ZbXSkNCiAJaWYgKGNoZGlyKGNvbmZpZ3BhdGgpICE9IDApDQogCQlz
eXNsb2coTE9HX0lORk8sICJjaGRpciB0byAlcyBmYWlsZWQ6ICVtIiwgY29u
ZmlncGF0aCk7DQogDQotCWZkID0gb3Blbl9kZXYoKDEwIDw8IDgpK21pbm9y
LFNfSVJFQUR8U19JRkNIUik7DQotCWlmIChmZCA9PSAtMSkgew0KKwlkZXZf
ZmQgPSBvcGVuX2RldigoMTAgPDwgOCkrbWlub3IsU19JUkVBRHxTX0lGQ0hS
KTsNCisJaWYgKGRldl9mZCA9PSAtMSkgew0KIAkgICAgICAgIHN5c2xvZyhM
T0dfSU5GTywgIlVuYWJsZSB0byBvcGVuIElyREEgZGV2aWNlIVxuIik7DQog
IAkJZXhpdCgtMSk7IA0KICAJfSANCkBAIC0yMTMsNyArMjI3LDcgQEAgaW50
IG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkNCiAJc3RhcnRfc2Vydmlj
ZSgiZHJpdmVycyIsICIiLCAwKTsNCiANCiAJd2hpbGUgKFRSVUUpIHsNCi0J
CXJldCA9IHJlYWQoZmQsICZldmVudCwgc2l6ZW9mKGV2ZW50KSk7DQorCQly
ZXQgPSByZWFkKGRldl9mZCwgJmV2ZW50LCBzaXplb2YoZXZlbnQpKTsNCiAJ
CWlmIChyZXQgPD0gMCkgew0KIAkJICAgICAvKiBEZXZpY2UgY2xvc2VkLCBz
byBwcm9iYWJseSBhIHNodXRkb3duICovDQogCQkgICAgIGV4aXQocmV0KTsN
CkBAIC0yMjEsNyArMjM1LDcgQEAgaW50IG1haW4oaW50IGFyZ2MsIGNoYXIg
KmFyZ3ZbXSkNCiAJCSAgICAgDQogCQlzd2l0Y2ggKGV2ZW50LmV2ZW50KSB7
DQogCQljYXNlIEVWRU5UX05FRURfUFJPQ0VTU19DT05URVhUOg0KLQkJICAg
ICBpb2N0bChmZCwgSVJNR1JfSU9DVE5QQywgbm90X3VzZWQpOw0KKwkJICAg
ICBpb2N0bChkZXZfZmQsIElSTUdSX0lPQ1ROUEMsIG5vdF91c2VkKTsNCiAJ
CSAgICAgYnJlYWs7DQogCQljYXNlIEVWRU5UX0RFVklDRV9ESVNDT1ZFUkVE
Og0KIAkJCXN3aXRjaCAoZXZlbnQuc2VydmljZSkgew0KQEAgLTI2Myw5ICsy
NzcsNiBAQCBpbnQgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQ0KIAkJ
CWJyZWFrOw0KIAkJfQ0KIAl9DQotCWNsb3NlKGZkKTsNCi0NCi0JcmV0dXJu
IDA7DQogfQ0KIA0KIA0K
---1480499767-593744558-944770862=:364--




From dagb@cs.uit.no 09 Dec 1999 21:56:48 +0100
Date: 09 Dec 1999 21:56:48 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Re: Ultra support for irda10

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> > OK, I've looked through your patch, and I have applied some of it. But I
> > decided to do things a bit different:
> > 
> > o I see no reason to support Ultra PID's with extension bytes. There will
> >   _never_ be any use for it! IrDA have reserved all pid's and they have only
> >   specified one (0x01 for Ultra). This mechanism is the same as for hint
> >   bytes, and nobody supports more than 2 hint bytes!!! Therefore I have
> >   choosen not to use your irda_ultra_bind() function.
> 
> 	With all due respect, this is really a stupid decision. This
> functionality was working (as opposed to your patches) and was
> conformant to the spec, and there is absolutely no reason to remove
> it. You limit the number of protocols on top of Ultra to 127, which is
> not much (we don't have dynamic allocation here). If I follow your
> reasoning, let's remove Ultra because nobody will _never_ use it.

Have you actually read your own answer? You are telling me that 127
simultanous connections on top of Ultra is not enough! I remember once
I had 7 "normal" connections at the same time ;-)

Ultra _will_ be used since you can already find it in a couple of mobile
phones which supports OBEX over Ultra. OBEX over Ultra uses PID 0x01, so
that give you 126 other PID's to play with. Nobody else are using them ;-)
If you need more for some special experiment, then why don't you multiplex
on top of one Ultra connection (or use your own patch)?

BTW. I really cannot see that limiting the number of PID bytes to 4 is more
conformant to the spec than limiting it to 1 byte.

> > o No support for connectionless LSAPs with selectors other than 0x70. The
> >   spec says this is the _only_ connless LSAP, and that we should drop all
> >   frames containing higher selectors. If we have support for this, the we
> >   might fail a compliance test, so again this will not go into the main
> >   distribution.
> 
> 	I just hope you didn't hardcoded 0x70 all over the place. My
> code was careful to strike a balance between compliance to the spec
> and future extensibility.

Yes I did ;-) In section 3.2.2 (page 21) in IrLMP they say: 

"All Data LM-PDUs delivered via IrLAP_Unitdata.indication primitived (UI
frames sent outside an IrLAP connection) except for those addressed between
Connectionless LSAPs (DLSAP-SEL=SLAP-SEL=0x70) are discarded."

Now why did they use the PID header if they planned to allow
for more connectionless LSAP's? You wanted almost 4M "connections" over one
SAP yourself!!! So now you want even more "connections"?

> > Hope you don't get really mad at me, but I think this is the best to
> > do. This will give us a good Ultra functionality and an impl. which is easy
> > to debug (and that is usually my job ;-)
> 
> 	Currently, I feel that's it's me doing most of the debugging
> and correcting your mistakes in the code.

Sorry for giving you the Ultra patch in the first place! I told you this
was work in progress! You said your were interested in Ultra, so I made a
patch out of my code. Silly me! Why don't you make your own patches it you
don't like mine. When you make patches for my patches, then you should
accept it if I choose to do things differently.

> > If you feel I'm destroying
> > everything, then please tell me since I really want you to continue
> > torturing and extending the Linux-IrDA stack. You're doing a really great
> > job!!
> 
> 	Try to read a bit more carefully patches, comments and so on,

Did that with the actisys dongle patch didn't I?

BTW: I'm having problems with the auto-connect patch because it has
problems when you put 2 or more IrDA devices in front of your machine
(suddenly you don't care about making things so general after all). This is
a policy decision which should be made in user-space and the user must
probably be involved as well (as Win98 deals with it). That this hasn't
been properly impl. in user-space yet in Linux, is not an argument for
moving it into the kernel.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 09 Dec 1999 22:22:17 +0100
Date: 09 Dec 1999 22:22:17 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]linux-2.2.13-irda12 fails to compile...

Martin Fluch <fluch@rock.helsinki.fi> writes:

> Hello,
> 
> if just tried to compile the 2.2.13 kernel with the irda12 patch applied,
> and it fails to compile:
> 
> irlap_event.c: In function `irlap_state_ndm':
> irlap_event.c:416: too many arguments to function `irlap_send_ui_frame'
> make[3]: *** [irlap_event.o] Error 1

Sorry, don't know why this happened. I'm downloading a new patch with the
same name right now.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 09 Dec 1999 23:20:38 +0100
Date: 09 Dec 1999 23:20:38 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]patch for irda-utils 0.9.5

Martin Fluch <fluch@rock.helsinki.fi> writes:

> Any comments?

Irmanager is not used for the 2.3.x code! There is also a high probability
that the latest (2.3.x) IrDA code will make it into 2.2.15, and then it
will not use irmanager either (only irattach).

If you could find a way that irattach could be used for controlling FIR
drivers as well as irtty.c, then that would be great. We need a tool that
could configure, load and unload _any_ IrDA driver. It would be great if
you could look at this issue.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 09 Dec 1999 23:14:28 +0100
Date: 09 Dec 1999 23:14:28 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]2.2.13-irda9+smc-ircc module does not load

Stephane.FILLOD@st.com writes:

> vanialla 2.2.13 patched with 2.2.13-irda9 compiles fine, but the smc-ircc module
> does not load, because of the lack of some symbols.
> 
> The symbols are from irport module (irport_stop, __irport_change_speed, etc.), 
> which IS loaded, but it looks like they are not exported.
> Dag, can you have a look ?
> 
> REM: you don't need to have SMC hardware to test that.

> 
> As soon as it is fixed, I'll be able to investigate why the smc-ircc is 
> unable to send frames longer than 1500 bytes with DMA at 4Mbps, resulting 
> most of the time in crashes..

The smc-ircc driver is broken! It uses irport, but all this stuff must be
rewritten because struct irda_device is now gone. It looks like a simple
thing to fix, but it's not! I'm hoping to look at this issue ASAP, since I
have some plans on how to resolve it. I'm going to do this for the IBM
driver first (since it's a working driver), and then look at the smc
driver. 

If you don't want to wait, then I suggest you fix the vanilla 2.2.13 code!
It will be very easy to move your fixes to the latest code later.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From jeant@rockfort.hpl.hp.com Thu, 9 Dec 1999 17:31:49 -0800
Date: Thu, 9 Dec 1999 17:31:49 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]irda12 braindamages...

--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii

	Hi,

	I spent 3 hours to get irda12 in the same state as I was
having irda10. For a starter, irda12 didn't even compile, so I won't
be talking of regression testing and all this useless QA
stuff. Basically, everything was broken...
	What really bug me is that half the fixes is things that I
already sent to Dag, and for a few of them it's only the third time
that I'm sending them. So, I wonder why I'm fixing Dag's bugs...

	So now, with this patch which apply to 2.2.13-irda12 (as I
downloaded this morning - 254373 bytes), all kind of sockets are
working (STREAM, SEQPACKET, DGRAM, ULTRA). It's tested. IrLAN and
IrComm do work as well. It's tested.

	Ok, listen Dag : if the next release of irda doesn't compile
out of the box and if not all the patch included here are in the next
version, I keep my own and forget about yours. I don't need your bugs,
my stuff is working better than yours...

	Jean

--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irda12.diff"

diff -u -p linux/include/linux/irda.d2.h linux/include/linux/irda.h
--- linux/include/linux/irda.d2.h	Thu Dec  9 05:45:46 1999
+++ linux/include/linux/irda.h	Thu Dec  9 05:45:26 1999
@@ -25,6 +25,8 @@
  *
  ********************************************************************/
 
+#include <linux/types.h>		/* for __u8, __u32 & ... */
+
 #ifndef KERNEL_IRDA_H
 #define KERNEL_IRDA_H
 
@@ -72,11 +74,11 @@ typedef enum {
 } IRDA_DONGLE;
 
 /* Protocol types to be used for SOCK_DGRAM */
-enum {
+typedef enum {
 	IRDAPROTO_UNITDATA = 0,
 	IRDAPROTO_ULTRA    = 1,
 	IRDAPROTO_MAX
-};
+} IRDA_DGRAM_PROTOCOLS;
 
 #define SOL_IRLMP      266 /* Same as SOL_IRDA for now */
 #define SOL_IRTTP      266 /* Same as SOL_IRDA for now */
@@ -84,7 +86,7 @@ enum {
 #define IRLMP_ENUMDEVICES        1
 #define IRLMP_IAS_SET            2
 #define IRLMP_IAS_QUERY          3
-#define IRLMP_HINTS_SET          4
+#define IRLMP_HINTS_SET		 4
 
 #define IRTTP_QOS_SET            5
 #define IRTTP_QOS_GET            6
@@ -99,21 +101,21 @@ enum {
 
 struct sockaddr_irda {
 	sa_family_t   sir_family;   /* AF_IRDA */
-	u_int8_t      sir_lsap_sel; /* LSAP selector */
-	u_int32_t     sir_addr;     /* Device address */
+	__u8          sir_lsap_sel; /* LSAP selector */
+	__u32         sir_addr;     /* Device address */
 	char          sir_name[25]; /* Usually <service>:IrDA:TinyTP */
 };
 
 struct irda_device_info {
-	u_int32_t     saddr;    /* Address of local interface */
-	u_int32_t     daddr;    /* Address of remote device */
+	__u32         saddr;    /* Address of local interface */
+	__u32         daddr;    /* Address of remote device */
 	char          info[22]; /* Description */
-	u_int8_t      charset;  /* Charset used for description */
-	u_int8_t      hints[2]; /* Hint bits */
+	__u8	      charset;  /* Charset used for description */
+	__u8          hints[2]; /* Hint bits */
 };
 
 struct irda_device_list {
-       u_int32_t len;
+       __u32  len;
        struct irda_device_info dev[1];
 };
 
diff -u -p linux/include/net/irda/irlap_frame.d2.h linux/include/net/irda/irlap_frame.h
--- linux/include/net/irda/irlap_frame.d2.h	Thu Dec  9 04:32:51 1999
+++ linux/include/net/irda/irlap_frame.h	Thu Dec  9 05:46:05 1999
@@ -116,8 +116,6 @@ void irlap_send_snrm_frame(struct irlap_
 void irlap_send_test_frame(struct irlap_cb *self, __u32 daddr, 
 			   struct sk_buff *cmd);
 void irlap_send_ua_response_frame(struct irlap_cb *, struct qos_info *);
-void irlap_send_ui_frame(struct irlap_cb *self, struct sk_buff *skb,
-			 int command);
 void irlap_send_dm_frame(struct irlap_cb *);
 void irlap_send_disc_frame(struct irlap_cb *);
 void irlap_send_rr_frame(struct irlap_cb *, int command);
@@ -129,7 +127,8 @@ void irlap_send_data_secondary_final(str
 void irlap_resend_rejected_frames(struct irlap_cb *, int command);
 
 void irlap_send_i_frame(struct irlap_cb *, struct sk_buff *, int command);
-void irlap_send_ui_frame(struct irlap_cb *, struct sk_buff *, int command);
+void irlap_send_ui_frame(struct irlap_cb *self, struct sk_buff *skb, 
+			 __u8 caddr, int command);
 
 extern int irlap_insert_qos_negotiation_params(struct irlap_cb *self, 
 					       struct sk_buff *skb);
diff -u -p linux/net/irda/af_irda.d2.c linux/net/irda/af_irda.c
--- linux/net/irda/af_irda.d2.c	Thu Dec  9 04:25:53 1999
+++ linux/net/irda/af_irda.c	Thu Dec  9 09:26:47 1999
@@ -570,6 +570,10 @@ static int irda_bind(struct socket *sock
 	/* Special care for Ultra sockets */
 	if ((sk->type == SOCK_DGRAM) && (sk->protocol == IRDAPROTO_ULTRA)) {
 		self->pid = addr->sir_lsap_sel;
+		if (self->pid & 0x80) {
+			IRDA_DEBUG(0, __FUNCTION__ "(), extension in PID not supp!\n");
+			return - 1;
+		}
 		
 		err = irda_open_lsap(self, self->pid);
 		if (err < 0)
@@ -1047,6 +1051,9 @@ static int irda_recvmsg_dgram(struct soc
 	copied     = skb->len;
 	
 	if (copied > size) {
+		IRDA_DEBUG(2, __FUNCTION__ 
+			   "(), Received truncated frame (%d < %d)!\n",
+			   copied, size);
 		copied = size;
 		msg->msg_flags |= MSG_TRUNC;
 	}
diff -u -p linux/net/irda/irlap_frame.d2.c linux/net/irda/irlap_frame.c
--- linux/net/irda/irlap_frame.d2.c	Thu Dec  9 08:23:01 1999
+++ linux/net/irda/irlap_frame.c	Thu Dec  9 08:28:48 1999
@@ -1001,7 +1001,7 @@ void irlap_send_ui_frame(struct irlap_cb
 	frame = skb->data;
 	
 	/* Insert connection address */
-	frame[0] = caddr | (command) ? CMD_FRAME : 0;
+	frame[0] = caddr | ((command) ? CMD_FRAME : 0);
 
 	irlap_queue_xmit(self, skb);
 }
diff -u -p linux/net/irda/irlmp.d2.c linux/net/irda/irlmp.c
--- linux/net/irda/irlmp.d2.c	Thu Dec  9 09:02:41 1999
+++ linux/net/irda/irlmp.c	Thu Dec  9 09:27:41 1999
@@ -147,8 +147,11 @@ struct lsap_cb *irlmp_open_lsap(__u8 sls
 		slsap_sel = irlmp_find_free_slsap();
 		if (!slsap_sel)
 			return NULL;
-	} else if (irlmp_slsap_inuse(slsap_sel))
+	} else if (irlmp_slsap_inuse(slsap_sel)) {
+		IRDA_DEBUG(1, __FUNCTION__ 
+		       "(), lsap already in use!\n");
 		return NULL;
+	}
 
 	/* Allocate new instance of a LSAP connection */
 	self = kmalloc(sizeof(struct lsap_cb), GFP_ATOMIC);
@@ -976,11 +979,12 @@ int irlmp_connless_data_request(struct l
 	ASSERT(skb_headroom(skb) >= LMP_HEADER+LMP_PID_HEADER, return -1;);
 	skb_push(skb, LMP_HEADER+LMP_PID_HEADER);
 	
-	/* Insert protocol identifier */
-	skb->data[0] = self->pid;
-
 	/* Connectionless sockets must use 0x70 */
-	skb->data[1] = skb->data[2] = LSAP_CONNLESS;
+	skb->data[0] = skb->data[1] = LSAP_CONNLESS;
+
+	/* Insert protocol identifier */
+printk("pid = 0x%X\n", self->pid);
+	skb->data[2] = self->pid;
 
 	/* Try to send Connectionless  packets out on all links */
 	lap = (struct lap_cb *) hashbin_get_first(irlmp->links);
diff -u -p linux/net/irda/irlmp_frame.d2.c linux/net/irda/irlmp_frame.c
--- linux/net/irda/irlmp_frame.d2.c	Thu Dec  9 04:28:03 1999
+++ linux/net/irda/irlmp_frame.c	Thu Dec  9 09:09:42 1999
@@ -176,7 +176,7 @@ void irlmp_link_data_indication(struct l
 	} else if (unreliable) {
 		/* Optimize and bypass the state machine if possible */
 		if (lsap->lsap_state == LSAP_DATA_TRANSFER_READY)
-			irlmp_data_indication(lsap, skb);
+			irlmp_udata_indication(lsap, skb);
 		else
 			irlmp_do_lsap_event(lsap, LM_UDATA_INDICATION, skb);
 	} else {	
@@ -221,12 +221,14 @@ void irlmp_link_unitdata_indication(stru
 	if (pid & 0x80) {
 		IRDA_DEBUG(0, __FUNCTION__ "(), extension in PID not supp!\n");
 		dev_kfree_skb(skb);
+		return;
 	}
 
 	/* Check if frame is addressed to the connectionless LSAP */
 	if ((slsap_sel != LSAP_CONNLESS) || (dlsap_sel != LSAP_CONNLESS)) {
 		IRDA_DEBUG(0, __FUNCTION__ "(), dropping frame!\n");
 		dev_kfree_skb(skb);
+		return;
 	}
 	
 	/* 
diff -u -p linux/net/irda/wrapper.d2.c linux/net/irda/wrapper.c
--- linux/net/irda/wrapper.d2.c	Thu Dec  9 04:22:21 1999
+++ linux/net/irda/wrapper.c	Thu Dec  9 08:49:48 1999
@@ -282,6 +282,8 @@ static void state_link_escape(struct dev
 {
 	switch (byte) {
 	case BOF: /* New frame? */
+		IRDA_DEBUG(1, __FUNCTION__ 
+			   "(), Discarding incomplete frame\n");
 		rx_buff->state = BEGIN_FRAME;
 		irda_device_set_media_busy(dev, TRUE);
 		break;
@@ -323,6 +325,8 @@ static void state_inside_frame(struct de
 
 	switch (byte) {
 	case BOF: /* New frame? */
+		IRDA_DEBUG(1, __FUNCTION__ 
+			   "(), Discarding incomplete frame\n");
 		rx_buff->state = BEGIN_FRAME;
 		irda_device_set_media_busy(dev, TRUE);
 		break;
diff -u -p linux/net/irda/irlap_event.d2.c linux/net/irda/irlap_event.c
--- linux/net/irda/irlap_event.d2.c	Thu Dec  9 04:29:46 1999
+++ linux/net/irda/irlap_event.c	Thu Dec  9 06:25:09 1999
@@ -413,7 +413,7 @@ static int irlap_state_ndm(struct irlap_
 			skb = skb_dequeue(&self->txq_ultra);
 			if (skb)			
 				irlap_send_ui_frame(self, skb, CBROADCAST, 
-						    TRUE);
+						    CMD_FRAME);
 			else
 				break;
 		}

--PEIAKu/WMn1b1Hv9--




From jeant@rockfort.hpl.hp.com Thu, 9 Dec 1999 17:47:09 -0800
Date: Thu, 9 Dec 1999 17:47:09 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Re: Ultra support for irda10

Dag wrote :
> 
> Have you actually read your own answer? You are telling me that 127
> simultanous connections on top of Ultra is not enough! I remember once
> I had 7 "normal" connections at the same time ;-)

	Wrong analogy, the PID are not dynamic. Once one is allocated
for an application, it's for life.

> Ultra _will_ be used since you can already find it in a couple of mobile
> phones which supports OBEX over Ultra. OBEX over Ultra uses PID 0x01, so
> that give you 126 other PID's to play with. Nobody else are using them ;-)
> If you need more for some special experiment, then why don't you multiplex
> on top of one Ultra connection (or use your own patch)?

	Because ultra is suppose to do that for me, and I don't want
to add another layer of protocol when I don't need one.

> BTW. I really cannot see that limiting the number of PID bytes to 4 is more
> conformant to the spec than limiting it to 1 byte.

	It's not. But what I meant is that this feature was 100%
compliant, or a least not less compliant than yours, so removing it
was stupid.

> >       I just hope you didn't hardcoded 0x70 all over the place. My
> > code was careful to strike a balance between compliance to the spec
> > and future extensibility.
> 
> Yes I did ;-) In section 3.2.2 (page 21) in IrLMP they say: 
> 
> "All Data LM-PDUs delivered via IrLAP_Unitdata.indication primitived (UI
> frames sent outside an IrLAP connection) except for those addressed between
> Connectionless LSAPs (DLSAP-SEL=SLAP-SEL=0x70) are discarded."
> 
> Now why did they use the PID header if they planned to allow
> for more connectionless LSAP's? You wanted almost 4M "connections" over one
> SAP yourself!!! So now you want even more "connections"?

	Because when I can code clean and leave flexibility, I do
it. I don't introduce stupid limitiations in my code just for
pleasure, especially when those limitations have no drawback.

	Now, I will explain you why : all the PID above 0x70 are
reserved by IrDA. So, in theory is I've got an app sitting above 0x70,
I must ask IrDA to give me a PID. IrDA will say "show me the money"
and make me wait a few years to give me a number.
	Above any other LSAP (for ex 0x71), IrDA has not defined
anything yet, so I'me free to do whatever I want. Basically, I can
developp my application, ship it in products, tell other people about
it, and IrDA can't complain about it and doesn't come in my way.

> >       Currently, I feel that's it's me doing most of the debugging
> > and correcting your mistakes in the code.
> 
> Sorry for giving you the Ultra patch in the first place! I told you this
> was work in progress! You said your were interested in Ultra, so I made a
> patch out of my code. Silly me! Why don't you make your own patches it you
> don't like mine. When you make patches for my patches, then you should
> accept it if I choose to do things differently.

	I'm not talking about the Ultra code. Ultra is the least of my
troubles. With each new patch, some of the basic functionality is
broken. Look at my last patch and tell me how much is related to
Ultra.

> 
> >       Try to read a bit more carefully patches, comments and so on,
> 
> Did that with the actisys dongle patch didn't I?

	Ha, ha, ha ! And you introduced this stupid typo preventing
the module to compile ! I would not be so smuck. At least, my version
was working.

> BTW: I'm having problems with the auto-connect patch because it has
> problems when you put 2 or more IrDA devices in front of your machine
> (suddenly you don't care about making things so general after all). This is
> a policy decision which should be made in user-space and the user must
> probably be involved as well (as Win98 deals with it). That this hasn't
> been properly impl. in user-space yet in Linux, is not an argument for
> moving it into the kernel.

	You didn't read into the detail of the patch, and it was much
more clever than that. Anyway, this is not a policy decision, because
the old way of doing things is working, you can still perform
discovery and set the desired daddr. It's just an optional feature.
	If you think about it, most of the time only one device has a
specific service activated, so it connect to the right device
automagically. But I will probably do better...

	Jean




From jeant@rockfort.hpl.hp.com Thu, 9 Dec 1999 17:51:52 -0800
Date: Thu, 9 Dec 1999 17:51:52 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Re: Ultra support for irda10

On Thu, Dec 09, 1999 at 12:03:57PM -0800, Thomas Davis wrote:
> [ not posted to the list ]

	It was...

> welcome to dag's world..  :-)

	Show me the code, Thomas... What about the SMC driver ?

	Jean




From tadavis@veriomail.com Thu, 09 Dec 1999 19:31:23 -0800
Date: Thu, 09 Dec 1999 19:31:23 -0800
From: Thomas Davis tadavis@veriomail.com
Subject: [Linux-IrDA]Re: Ultra support for irda10

Jean Tourrilhes wrote:
> 
> On Thu, Dec 09, 1999 at 12:03:57PM -0800, Thomas Davis wrote:
> > [ not posted to the list ]
> 
>         It was...
> 
> > welcome to dag's world..  :-)
> 
>         Show me the code, Thomas... What about the SMC driver ?
> 

What about it? It worked at one time.. (almost)  Besides, alot of the
code you've been looking at.  Who do you think convinced Dag that
dongles exist? That not all FIR hardware is the same?  Helped debug the
stack?  Created most of the /proc interface?

But, I've actually got some free time coming up (the lab shuts down for
two weeks over xmas/new years), so I'm going to try and bring it upto
date.

Now, if you know of a job in Linux, that would allow me to put more time
into the IrDA/Bluetooth, I'd jump.  But, where I am at, I get to do
Linux all day long (Clustering)..  To bad it's government job.  Might be
time to jump to google, or linuxcare, or one of the many pre-ipo linux
companies around here.

Oh, and yes, I've mentioned several times Linux/IrDA to people around
here, and there isn't much interest in it.  (it's one of those 'does it
work? no? come back when it does' things..)

Which is why in v2.4 Linux/IrDA should be ultra stable, and not changing
the programming interface any.  Right now, it's a novelty.

Dag, how about a ToDo list?  That may help some - right now, it seems
it's a 'oh, wow, look at this neat feature!'

-- 
-------------------------+--------------------------------------------
Thomas Davis             | Supernova's are industrial accidents.
tadavis@veriomail.com    | One of the Linux/IrDA guys.




From jeant@rockfort.hpl.hp.com Thu, 9 Dec 1999 20:10:03 -0800
Date: Thu, 9 Dec 1999 20:10:03 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]auto-connect, Dag compliant...

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii

	Dag,

	For your pleasure, I modified the auto-connect to be according
to your rules. This time, no policy in the kernel, and we do things
proper. I hope it will make you happy...

	Jean

P.S. : Of course, I've uncovered a few other details, but please put
them on your todo list with a very low priority, even lower than Ultra
support, far behind PyObex and what real people really need.

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irconnect12.diff"

diff -u -p linux/include/net/irda/irlap.f1.h linux/include/net/irda/irlap.h
--- linux/include/net/irda/irlap.f1.h	Thu Dec  9 11:48:25 1999
+++ linux/include/net/irda/irlap.h	Thu Dec  9 11:50:05 1999
@@ -92,6 +92,7 @@ struct irda_compressor {
 struct irlap_cb {
 	queue_t q;     /* Must be first */
 	magic_t magic;
+	int	n_lsaps;	/* Ref-count : number of SAP open above us */
 
 	struct device  *netdev;
 
diff -u -p linux/net/irda/irlap.f1.c linux/net/irda/irlap.c
--- linux/net/irda/irlap.f1.c	Thu Dec  9 11:52:09 1999
+++ linux/net/irda/irlap.c	Thu Dec  9 12:23:43 1999
@@ -120,6 +120,7 @@ struct irlap_cb *irlap_open(struct devic
 	
 	memset(self, 0, sizeof(struct irlap_cb));
 	self->magic = LAP_MAGIC;
+	self->n_lsaps = 0;	/* No LSAP open for now */
 
 	/* Make a binding between the layers */
 	self->netdev = dev;
@@ -265,6 +266,10 @@ void irlap_connect_request(struct irlap_
 	ASSERT(self != NULL, return;);
 	ASSERT(self->magic == LAP_MAGIC, return;);
 
+	self->n_lsaps++;	/* One more LSAP connected */
+	/* Note : verify that we refcount LSAP open on incomming connections */
+
+	/* May want to check if the same in case n_lsaps > 1 */
  	self->daddr = daddr;
 	
 	/*
@@ -434,12 +439,23 @@ void irlap_disconnect_request(struct irl
 	ASSERT(self != NULL, return;);
 	ASSERT(self->magic == LAP_MAGIC, return;);
 	
+	self->n_lsaps--;	/* Remove one LSAP from our list */
+
+	/* Check if it was the last LSAP */
+	if(self->n_lsaps)
+		return;
+
+	IRDA_DEBUG(1, __FUNCTION__ "(), going to disconnect the LAP\n"); 
+
 	/* Don't disconnect until all data frames are successfully sent */
 	if (skb_queue_len(&self->txq) > 0) {
 		self->disconnect_pending = TRUE;
 		
 		return;
 	}
+
+	/* Not connected means no address - makes IrLMP happy */
+	self->daddr = DEV_ADDR_ANY;
 
 	/* Check if we are in the right state for disconnecting */
 	switch (self->state) {
diff -u -p linux/net/irda/irlmp_event.f1.c linux/net/irda/irlmp_event.c
--- linux/net/irda/irlmp_event.f1.c	Thu Dec  9 12:02:49 1999
+++ linux/net/irda/irlmp_event.c	Thu Dec  9 12:19:13 1999
@@ -306,8 +306,8 @@ static void irlmp_state_u_connect(struct
 
 		irlmp_next_lap_state(self, LAP_STANDBY);
 
-		/* FIXME */
-/* 		irlap_disconnect_request( self->irlap); */
+		/* FIXME -> With refcount, should be better */
+/* 		irlap_disconnect_request( self->irlap);*/
 		break;
 	default:
 		IRDA_DEBUG(0, __FUNCTION__ "(), Unknown event %s\n",
diff -u -p linux/net/irda/af_irda.f1.c linux/net/irda/af_irda.c
--- linux/net/irda/af_irda.f1.c	Thu Dec  9 10:20:38 1999
+++ linux/net/irda/af_irda.c	Thu Dec  9 12:25:57 1999
@@ -485,6 +485,101 @@ static int irda_find_lsap_sel(struct ird
 }
 
 /*
+ * Function irda_discover_daddr_and_lsap_sel (self, name)
+ *
+ *    This try to find a device with the requested service.
+ *
+ * It basically look into the discovery log. For each address in the list,
+ * it queries the LM-IAS of the device to find if this device offer
+ * the requested service.
+ * If there is more than one node supporting the service, we complain
+ * to the user (it should move devices around).
+ * The, we set both the destination address and the lsap selector to point
+ * on the service on the unique device we have found.
+ *
+ * Note : this function fails if there is more than one device in range,
+ * because IrLMP doesn't disconnect the LAP when the last LSAP is closed.
+ * Moreover, we would need to wait the LAP disconnection...
+ */
+static int irda_discover_daddr_and_lsap_sel(struct irda_sock *self, char *name)
+{
+	discovery_t *discovery;
+	int err = -ENETUNREACH;
+	__u32	daddr = 0x0;		/* Address we found the service on */
+	__u8	dtsap_sel = 0x0;	/* TSAP associated with it */
+
+	IRDA_DEBUG(2, __FUNCTION__ "(), name=%s\n", name);
+
+	ASSERT(self != NULL, return -1;);
+
+	/* Tell IrLMP we want to be notified */
+	irlmp_update_client(self->ckey, self->mask, NULL, 
+			    irda_discovery_indication);
+	
+	/* Do some discovery */
+	irlmp_discovery_request(self->nslots);
+		
+	/* Check if the we got some results */
+	if (!cachelog)
+		/* Wait for answer */
+		/*interruptible_sleep_on(&self->discovery_wait);*/
+		return -EAGAIN;
+
+	/* 
+	 * Now, check all discovered devices (if any), and connect
+	 * client only about the services that the client is
+	 * interested in...
+	 */
+	discovery = (discovery_t *) hashbin_get_first(cachelog);
+	while (discovery != NULL) {
+		/* Mask out the ones we don't want */
+		if (discovery->hints.word & self->mask) {
+			/* Try this address */
+			self->daddr = discovery->daddr;
+			self->saddr = 0x0;
+			IRDA_DEBUG(1, __FUNCTION__ "(), trying daddr = %08x\n", self->daddr);
+
+			/* Query remote LM-IAS for this service */
+			err = irda_find_lsap_sel(self, name);
+			if (err == 0) {
+				/* We found the requested service */
+				if(daddr != 0x0) {
+					IRDA_DEBUG(0, __FUNCTION__
+						   "(), discovered service ''%s'' in two different devices !!!\n",
+						   name);
+					return(-ENOTUNIQ);
+				}
+				/* First time we foun that one, save it ! */
+				daddr = self->daddr;
+				dtsap_sel = self->dtsap_sel;
+			}
+		}
+
+		/* Next node, maybe we will be more lucky...  */
+		discovery = (discovery_t *) hashbin_get_next(cachelog);
+	}
+	cachelog = NULL;
+
+	/* Check out what we found */
+	if(daddr == 0x0) {
+		IRDA_DEBUG(0, __FUNCTION__
+			   "(), cannot discover service ''%s'' in any device !!!\n",
+			   name);
+		self->daddr = 0;	/* Guessing */
+		return(-ENETUNREACH);
+	}
+
+	/* Revert back to discovered device & service */
+	self->daddr = daddr;
+	self->saddr = 0x0;
+	self->dtsap_sel = dtsap_sel;
+
+	IRDA_DEBUG(0, __FUNCTION__ "(), discovered requested service ''%s'' at address %08x\n", name, self->daddr);
+
+	return 0;
+}
+
+/*
  * Function irda_getname (sock, uaddr, uaddr_len, peer)
  *
  *    Return the our own, or peers socket address (sockaddr_irda)
@@ -742,18 +837,26 @@ static int irda_connect(struct socket *s
 	if (addr_len != sizeof(struct sockaddr_irda))
 		return -EINVAL;
 
-	/* Check if user supplied the required destination device address */
-	if (!addr->sir_addr)
-		return -EINVAL;
-
-	self->daddr = addr->sir_addr;
-	IRDA_DEBUG(1, __FUNCTION__ "(), daddr = %08x\n", self->daddr);
-
-	/* Query remote LM-IAS */
-	err = irda_find_lsap_sel(self, addr->sir_name);
-	if (err) {
-		IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
-		return err;
+	/* Check if user supplied any destination device address */
+	if (!addr->sir_addr) {
+		/* Try to find one suitable */
+		err = irda_discover_daddr_and_lsap_sel(self, addr->sir_name);
+		if (err) {
+			IRDA_DEBUG(0, __FUNCTION__ "(), auto-connect failed!\n");
+			return -EINVAL;
+		}
+	}
+	else {
+		/* Use the one provided by the user */
+		self->daddr = addr->sir_addr;
+		IRDA_DEBUG(1, __FUNCTION__ "(), daddr = %08x\n", self->daddr);
+
+		/* Query remote LM-IAS */
+		err = irda_find_lsap_sel(self, addr->sir_name);
+		if (err) {
+			IRDA_DEBUG(0, __FUNCTION__ "(), connect failed!\n");
+			return err;
+		}
 	}
 
 	/* Check if we have opened a local TSAP */

--jRHKVT23PllUwdXP--




From jeant@rockfort.hpl.hp.com Thu, 9 Dec 1999 20:21:47 -0800
Date: Thu, 9 Dec 1999 20:21:47 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Re: Ultra support for irda10

Thomas wrote :
> 
> What about it? It worked at one time.. (almost) Besides, alot of the
> code you've been looking at.  Who do you think convinced Dag that
> dongles exist? That not all FIR hardware is the same?  Helped debug the
> stack?  Created most of the /proc interface?

	I'm sorry Thomas, but today I was really upset. I was having
everything working with irda10 yesterday night, and I had to spend 3
hours today to get back in the same state with irda12, and this ordeal
didn't put me in good mood.
	Actually, you may have seen that I've been quite hard with the
poor Dag.

> But, I've actually got some free time coming up (the lab shuts down for
> two weeks over xmas/new years), so I'm going to try and bring it upto
> date.

	Don't get me wrong : on the good days, there is a lot of the
stack working. If Dag was not trying to do everything is parallel,
things could be good.

> Now, if you know of a job in Linux, that would allow me to put more time
> into the IrDA/Bluetooth, I'd jump.

	You really believe that ? In any Linux company you would be so
overworked that you would not get a chance.

>  But, where I am at, I get to do
> Linux all day long (Clustering)..  To bad it's government job.  Might be
> time to jump to google, or linuxcare, or one of the many pre-ipo linux
> companies around here.
> 
> Oh, and yes, I've mentioned several times Linux/IrDA to people around
> here, and there isn't much interest in it.  (it's one of those 'does it
> work? no? come back when it does' things..)

	It does, and I plan to use it seriously. 2.2.13-irda9 was
quite good for example.
	What I will do is to get one release working and stay with
that one without trying to sync with Dag.

> Which is why in v2.4 Linux/IrDA should be ultra stable, and not changing
> the programming interface any.  Right now, it's a novelty.

	2.4 is not far away, and there is lot's of testing to do on
the stack, some parts are virtually untested (and some even
uncompiled...).

> Dag, how about a ToDo list?  That may help some - right now, it seems
> it's a 'oh, wow, look at this neat feature!'

	Yes, but a todo list with priority, and allowing people to
vote on the most requested feature. Implementing Ultra was nice for
me, but I could have done it alone, and I think most people were
waiting for PyObex.
	So : put priorities.

> Thomas Davis

	Jean




From tadavis@veriomail.com Thu, 09 Dec 1999 20:45:40 -0800
Date: Thu, 09 Dec 1999 20:45:40 -0800
From: Thomas Davis tadavis@veriomail.com
Subject: [Linux-IrDA]Re: Ultra support for irda10

Jean Tourrilhes wrote:
> 
>         You really believe that ? In any Linux company you would be so
> overworked that you would not get a chance.
> 

Yea, but have you seen the way the last two Linux companie's stock has
popped? WOW.  :-)

> 
>         2.4 is not far away, and there is lot's of testing to do on
> the stack, some parts are virtually untested (and some even
> uncompiled...).
> 

Well, I've got access to a ton of IrDA devices down in San Jose..  If
someone can tell me what to test, I can drive/ride down there, and do
some testing.

I'm sure they would love to see Linux/IrDA vs. MS/IrDA!

-- 
-------------------------+--------------------------------------------
Thomas Davis             | Supernova's are industrial accidents.
tadavis@veriomail.com    | One of the Linux/IrDA guys.




From jeant@rockfort.hpl.hp.com Thu, 9 Dec 1999 21:55:47 -0800
Date: Thu, 9 Dec 1999 21:55:47 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Set IAS object from user space for irda12...

--4SFOXa2GPu3tIq4H
Content-Type: text/plain; charset=us-ascii

	Hi again,

	This patch add the possibility to set a new IAS
object/attribute from a program in user space. This patch has been
tested and all the standard caveats of this type of procedure (moving
data user->kernel) have been taken care of.

	Jean

--4SFOXa2GPu3tIq4H
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irsetias12.diff"

linux/include/linux/irda.f2.h linux/include/linux/irda.h
--- linux/include/linux/irda.f2.h	Thu Dec  9 13:09:00 1999
+++ linux/include/linux/irda.h	Thu Dec  9 13:35:09 1999
@@ -97,6 +97,11 @@ typedef enum {
 #define IAS_MAX_CLASSNAME       64
 #define IAS_MAX_ATTRIBNAME     256
 
+#define IAS_MISSING 0
+#define IAS_INTEGER 1
+#define IAS_OCT_SEQ 2
+#define IAS_STRING  3
+
 #define LSAP_ANY               0xff
 
 struct sockaddr_irda {
@@ -132,7 +137,7 @@ struct irda_ias_set {
 		struct {
 			unsigned char len;
 			unsigned char charset;
-			unsigned char string[IAS_MAX_STRING];
+			unsigned char string[IAS_MAX_STRING + 1];
 		} irda_attrib_string;
 	} attribute;
 };
diff -u -p linux/net/irda/af_irda.f2.c linux/net/irda/af_irda.c
--- linux/net/irda/af_irda.f2.c	Thu Dec  9 13:00:32 1999
+++ linux/net/irda/af_irda.c	Thu Dec  9 14:09:04 1999
@@ -1578,6 +1578,8 @@ static int irda_setsockopt(struct socket
  	struct sock *sk = sock->sk;
 	struct irda_sock *self;
 	int opt;
+	struct irda_ias_set	ias_opt;
+	struct ias_object *	ias_obj;
 	
 	self = sk->protinfo.irda;
 	ASSERT(self != NULL, return -1;);
@@ -1585,17 +1587,74 @@ static int irda_setsockopt(struct socket
 	if (level != SOL_IRLMP)
 		return -ENOPROTOOPT;
 	
-	if (optlen < sizeof(int))
-		return -EINVAL;
-	
-	if (get_user(opt, (int *)optval))
-		return -EFAULT;
-	
 	switch (optname) {
 	case IRLMP_IAS_SET:
+		if (optlen != sizeof(struct irda_ias_set))
+			return -EINVAL;
+	
+		/* Copy query to the driver. */
+		if (copy_from_user(&ias_opt, (char *)optval, optlen))
+		  	return -EFAULT;
+
+		/* Find the object we target */
+		ias_obj = irias_find_object(ias_opt.irda_class_name);
+		if(ias_obj == (struct ias_object *) NULL) {
+			/* Create a new object */
+			ias_obj = irias_new_object(ias_opt.irda_class_name,
+						   jiffies);
+		}
+
+		/* Do we have it already ? */
+		if(irias_find_attrib(ias_obj, ias_opt.irda_attrib_name))
+			return -EINVAL;
+
+		/* Look at the type */
+		switch(ias_opt.irda_attrib_type) {
+		case IAS_INTEGER:
+			/* Add an integer attribute */
+			irias_add_integer_attrib(ias_obj,
+						 ias_opt.irda_attrib_name, 
+					 ias_opt.attribute.irda_attrib_int);
+			break;
+		case IAS_OCT_SEQ:
+			/* Check length */
+			if(ias_opt.attribute.irda_attrib_octet_seq.len >
+			   IAS_MAX_OCTET_STRING)
+				return -EINVAL;
+			/* Add an octet sequence attribute */
+			irias_add_octseq_attrib(ias_obj,
+						ias_opt.irda_attrib_name, 
+			      ias_opt.attribute.irda_attrib_octet_seq.OctetSeq,
+			      ias_opt.attribute.irda_attrib_octet_seq.len);
+			break;
+		case IAS_STRING:
+			/* Should check charset & co */
+			/* Check length */
+			if(ias_opt.attribute.irda_attrib_string.len >
+			   IAS_MAX_STRING)
+				return -EINVAL;
+			/* NULL terminate the string (avoid troubles) */
+			ias_opt.attribute.irda_attrib_string.string[ias_opt.attribute.irda_attrib_string.len] = '\0';
+			/* Add a string attribute */
+			irias_add_string_attrib(ias_obj,
+						ias_opt.irda_attrib_name, 
+				ias_opt.attribute.irda_attrib_string.string);
+			break;
+		default :
+			return -EINVAL;
+		}
+		irias_insert_object(ias_obj);
+		break;
+
 		IRDA_DEBUG(0, __FUNCTION__ "(), sorry not impl. yet!\n");
 		return -ENOPROTOOPT;
 	case IRTTP_MAX_SDU_SIZE:
+		if (optlen < sizeof(int))
+			return -EINVAL;
+	
+		if (get_user(opt, (int *)optval))
+			return -EFAULT;
+	
 		/* Only possible for a seqpacket service (TTP with SAR) */
 		if (sk->type != SOCK_SEQPACKET) {
 			IRDA_DEBUG(2, __FUNCTION__ 
@@ -1609,6 +1668,12 @@ static int irda_setsockopt(struct socket
 		}
 		break;
 	case IRLMP_HINTS_SET:
+		if (optlen < sizeof(int))
+			return -EINVAL;
+	
+		if (get_user(opt, (int *)optval))
+			return -EFAULT;
+
 		/* Unregister any old registration */
 		if (self->skey)
 			irlmp_unregister_service(self->skey);
@@ -1721,6 +1786,10 @@ static int irda_getsockopt(struct socket
 		if (copy_to_user(optval, &val, len))
 			return -EFAULT;
 		break;
+		/*
+	  if (copy_to_user(wrq->u.data.pointer, (u_char *) priv, sizeof(priv)))
+	  	ret = -EFAULT;
+		*/
 	default:
 		return -ENOPROTOOPT;
 	}

--4SFOXa2GPu3tIq4H--




From wehe@snafu.de Thu, 09 Dec 1999 19:52:07 +0100
Date: Thu, 09 Dec 1999 19:52:07 +0100
From: Werner Heuser wehe@snafu.de
Subject: [Linux-IrDA]self made IR motherboard adapter

Hi,

the German computer magazin offers an article about "PC and Infared
Support" (mostly about MS-Windows9x/NT) in it's current 
issue CT 20/1999 110ff. , same URL as mentioned in a thread 
before about the German magazine iX http://www.heise.de

This article points to a link about the description of a self made
infrared motherboard adapter http://home.t-online.de/home/Rainer.Brang 
as far as I can see, this intended for use with remote controls
but IrDA is mentioned, too.

Since this adapters are often difficult to buy and expensive I suppose
this is of some interest to you.

BTW: There is mentioned a cheap trick to check wether a IR LED is 
emitting light or not by using a CCD camera
(Videokamera / PC Kamera / Chip-Kamera)

Quoting Dag: 
"Just use http://babelfish.altavista.com, to read an English version.
Does not translate the whole document tho'"

Cheers
-werner-
-- 
Werner Heuser                       | Stop nuclear power now!       /~~
LiLAC - Linux with Laptop Computers |                              /~~~
Berlin, Germany                     |                             /~~~~
http://www.snafu.de/~wehe/index_li.html             T. +49 30 349 53 86





From dagb@cs.uit.no 10 Dec 1999 08:54:16 +0100
Date: 10 Dec 1999 08:54:16 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]irda12 braindamages...

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Ok, listen Dag : if the next release of irda doesn't compile
> out of the box and if not all the patch included here are in the next
> version, I keep my own and forget about yours. I don't need your bugs,
> my stuff is working better than yours...

Great! I suggest you fork() and go somewhere else ;-) EOF!

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From wehe@snafu.de Fri, 10 Dec 1999 11:08:13 +0100
Date: Fri, 10 Dec 1999 11:08:13 +0100
From: wehe@snafu.de wehe@snafu.de
Subject: [Linux-IrDA]irda12 braindamages...

> Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:
> 
> > 	Ok, listen Dag : if the next release of irda doesn't compile
> > out of the box and if not all the patch included here are in the 
next
> > version, I keep my own and forget about yours. I don't need your 
bugs,
> > my stuff is working better than yours...
> 
> Great! I suggest you fork() and go somewhere else ;-) EOF!

Hi Dag, hi Jean, hi All,

sorry for interfering into your trouble, but from my point of
view I'm quite interested in having both of you continuing 
your work with the Linux/IrDA Project.

>From my point of view I can understand both opinions:

- Jean was embarrassed about the compile errors of Dags last
patch, and the missing patches of him

- Dag has much work and trouble to get all the loose ends (patches, ..)
together in time, was probably embarrassed about the harsh 
tone of Jeans mail

My suggestion is: Please let us look together (I mean all members
of this list!) how we can get the release process more efficient. I 
guess this is not only a technical questions (like using CVS). I guess 
also, that the project needs more help with this work, for instance
a separate patch or CVS maintainer.

with hopefull regards

-werner- 




From dagb@cs.uit.no 10 Dec 1999 11:08:38 +0100
Date: 10 Dec 1999 11:08:38 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]auto-connect, Dag compliant...

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Dag,
> 
> 	For your pleasure, I modified the auto-connect to be according
> to your rules. This time, no policy in the kernel, and we do things
> proper. I hope it will make you happy...

No, this patch is wrong (or braindamaged since you like to use such
terminology;-) You are assuming that every LSAP connect request, results in
an IrLAP connect request. This is _not_ the case!!

I have moved the refcount to the lap_cb struct of irlmp, and I'm doing the
refcounting there instead. Then it's possible to impl what the spec sais on
page 51 in irlmp. And it dosn't say anything about doing an IrLAP
disconnect request in state u-connect.

> @@ -265,6 +266,10 @@ void irlap_connect_request(struct irlap_
>  	ASSERT(self != NULL, return;);
>  	ASSERT(self->magic == LAP_MAGIC, return;);
>  
> +	self->n_lsaps++;	/* One more LSAP connected */
> +	/* Note : verify that we refcount LSAP open on incomming connections */
> +
> +	/* May want to check if the same in case n_lsaps > 1 */
>   	self->daddr = daddr;

So, my problem is that you are sending in a lot of patches that changes
functionality in the stack, and doesn't comply with the spec. You think
that everything is OK, just because it's working for you in your setup. But
this patch would definitively have resulted in headache for somebody in the
future!

The patch you included clearly shows that you don't know how IrLMP actually 
works. Now why do I hesitate when applying your patches?

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 10 Dec 1999 11:25:44 +0100
Date: 10 Dec 1999 11:25:44 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Re: irda12 braindamages...

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:


> +#include <linux/types.h>		/* for __u8, __u32 & ... */
> +
>  #ifndef KERNEL_IRDA_H
>  #define KERNEL_IRDA_H
>  
>  struct sockaddr_irda {
>  	sa_family_t   sir_family;   /* AF_IRDA */
> -	u_int8_t      sir_lsap_sel; /* LSAP selector */
> -	u_int32_t     sir_addr;     /* Device address */
> +	__u8          sir_lsap_sel; /* LSAP selector */
> +	__u32         sir_addr;     /* Device address */
>  	char          sir_name[25]; /* Usually <service>:IrDA:TinyTP */
>  };

Currently, user-space programs needs to use <linux/irda.h>. But I see no
reason why you should force them to use <linux/types.h> as well. This may
result in a mess for application programmers. My plan was that applications
could do:

#include <sys/types.h>
#include <linux/irda.h>

and the kernel could do:

#include <linux/types.h>
#include <linux/irda.h>

Why do you want to change this? I cannot apply this patch just because you
had to make these changes in order to make your applications compile. You
must tell me what you are thinking!!! Do we need two files, one irda.h for
glibc and one for the kernel? I was just trying to delay that decision for
a while!

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 10 Dec 1999 11:31:58 +0100
Date: 10 Dec 1999 11:31:58 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Re: Set IAS object from user space for irda12...

Jean Tourrilhes <jeant@rockfort.hpl.hp.com> writes:

> 	Hi again,
> 
> 	This patch add the possibility to set a new IAS
> object/attribute from a program in user space. This patch has been
> tested and all the standard caveats of this type of procedure (moving
> data user->kernel) have been taken care of.

Yes, but what happens to the added objects when the application closes the
socket?

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From Per.Wallner@era.ericsson.se Fri, 10 Dec 1999 11:52:04 +0100
Date: Fri, 10 Dec 1999 11:52:04 +0100
From: Per Wallner (QRA) Per.Wallner@era.ericsson.se
Subject: [Linux-IrDA]Q: char-major-108

Hi there,
back to the smaller of problems for a while...

I'm still trying to connect a Palm to my linuxbox as below, frantically patching back and forth...
At least I get new things happening. Such as, when I do  'pppd ircomm0 115200 silent noauth local nodetach ip1:ip2'
syslog tells me:

Dec 10 11:20:41 gal kernel: IrDA (tm) Protocols for Linux-2.2 (Dag Brattli) 
Dec 10 11:20:41 gal kernel: IrCOMM protocol (Dag Brattli) 
Dec 10 11:20:57 gal kernel: CSLIP: code copyright 1989 Regents of the University of California 
Dec 10 11:20:57 gal kernel: PPP: version 2.3.7 (demand dialling) 
Dec 10 11:20:57 gal kernel: PPP line discipline registered. 
Dec 10 11:21:52 gal irmanager: executing: 'echo 1 > /proc/sys/net/irda/discovery'
Dec 10 11:21:52 gal irmanager: executing: 'echo gal > /proc/sys/net/irda/devname'
Dec 10 11:22:46 gal irattach: Serial connection established.
Dec 10 11:22:46 gal kernel: IrDA: Registered device irda0 
Dec 10 11:22:47 gal irattach: executing: 'echo gal > /proc/sys/net/irda/devname'Dec 10 11:22:47 gal irattach: Using device: irda0 

Dec 10 11:24:04 gal modprobe: can't locate module char-major-108
Dec 10 11:24:04 gal kernel: registered device ppp0 
Dec 10 11:24:04 gal pppd[755]: pppd 2.3.10 started by root, uid 0
Dec 10 11:24:04 gal pppd[755]: Using interface ppp0
Dec 10 11:24:04 gal pppd[755]: Connect: ppp0 <--> /dev/ircomm0

What on earth is char-major-108????

> Best regards,
> Per Wallner
> --------------------------------------------------------------------------------------------------------
> ericssonz
> Per Wallner
> Ericsson Radio Systems AB		Phone:+46 8 585 32060 
> GPRS Total Solution				Fax: +46 8 585 32100
> Kistagången 26
> SE-164 80 Stockholm
> 
> 
> -----Original Message-----
> From:	Per Wallner (QRA) 
> Sent:	den 30 november 1999 13:14
> To:	'linux-irda@pasta.cs.uit.no'
> Subject:	Q: Connecting a Palm to Linux - IP and PPP
> 
> Hi,
> I already did this way back, but now it all seems new and mysterious again... ;)
> 
> Here's the scope:
> I want to connect a Palm III/V (or Ericsson MC218) IP-wise to a linux box. The 
> Palm uses ppp, and I've got a JetEye PC 9680 dongle. I simply want the Palm
> (or whatever) to be an IP device, using the Linux box as a network connection point.
> 
> Setup:
> RedHat 6.1, 2.2.13 kernel, patch-2.2.13-irda12+++ and irda-utils-0.9.5
> 
> I've created device files as:
> crw-r--r--   1 root     root     161,   0 Nov 29 15:27 /dev/ircomm0
> crw-r--r--   1 root     root     161,   1 Nov 29 15:27 /dev/ircomm1
> crw-r--r--   1 root     root     161,  16 Nov 29 15:28 /dev/irlpt0
> crw-r--r--   1 root     root     161,  17 Nov 29 15:28 /dev/irlpt1
> crw-r--r--   1 root     root      60,  64 Nov 30 09:06 /dev/irnine
> 
> My conf.modules contains:
> alias tty-ldisc-11   irtty
> alias char-major-161 ircomm-tty
> 
> 
> I load various modules, and start irmanager:
> /sbin/modprobe ircomm-tty
> /sbin/modprobe irtty
> /sbin/modprobe esi
> /sbin/modprobe ppp
> /usr/sbin/irmanager -d 1
> 
> This gives the following messages, which looks pretty much OK:
> 
> Nov 30 12:23:47 gal kernel: IrDA (tm) Protocols for Linux-2.2 (Dag Brattli) 
> Nov 30 12:23:47 gal kernel: IrCOMM protocol (Dag Brattli) 
> Nov 30 12:23:47 gal irmanager: executing: 'echo 1 > /proc/sys/net/irda/discovery'
> Nov 30 12:23:47 gal irmanager: executing: 'echo gal > /proc/sys/net/irda/devname'
> Nov 30 12:23:47 gal irmanager: + 1.1 Tue Nov  9 15:30:55 1999 Dag Brattli
> Nov 30 12:23:47 gal irattach: Serial connection established.
> Nov 30 12:23:47 gal kernel: IrDA: Registered device irda0 
> Nov 30 12:23:47 gal irmanager: + 1.1 Tue Nov  9 15:30:55 1999 Dag Brattli
> Nov 30 12:23:48 gal irattach: executing: 'echo gal > /proc/sys/net/irda/devname'
> Nov 30 12:23:48 gal irattach: Using device: irda0 
> 
> I start pppd with:
> pppd /dev/ircomm1 <speed> 192.168.0.1:192.168.0.100 passive silent persist noauth local nodetach> 
> where I've tried speeds btwn 9600 and 115200.
> 
> This gives me:
> Nov 30 12:27:18 gal pppd[912]: pppd 2.3.10 started by root, uid 0
> Nov 30 12:27:18 gal pppd[912]: Using interface ppp0
> Nov 30 12:27:18 gal pppd[912]: Connect: ppp0 <--> /dev/ircomm1
> 
> An lsmod gives me this:
> 
> Module                  Size  Used by
> esi                      760   1 
> irtty                   7164   2 
> ircomm-tty             29080   1 
> ircomm                 13116   0  [ircomm-tty]
> irda                  134465   2  [esi irtty ircomm-tty ircomm]
> ppp                    20684   1 
> slhc                    4300   0  [ppp]
> 
> At this stage, the LED on the dongle is happily blinking. However, there's no way
> I can get the Palm (or MC) to connect.
> 
> I'm sure I've omitted some detail (or several...), and I'm stuck.
> What have I missed?
> Do I have to set serial speed some place? How does the ppp interface connect to
> the serial port?
> 
> I really would appreciate if someone could shed some light on this - I'm
> lost in darkness ;(
> 
> TIA, Best regards
> Per Wallner
> 
> 





From fluch@rock.helsinki.fi Fri, 10 Dec 1999 13:23:19 +0200 (EET)
Date: Fri, 10 Dec 1999 13:23:19 +0200 (EET)
From: Martin Fluch fluch@rock.helsinki.fi
Subject: [Linux-IrDA]patch for irda-utils 0.9.5

-----BEGIN PGP SIGNED MESSAGE-----

On 9 Dec 1999, Dag Brattli wrote:

> Martin Fluch <fluch@rock.helsinki.fi> writes:
> 
> > Any comments?
> 
> Irmanager is not used for the 2.3.x code! There is also a high probability
> that the latest (2.3.x) IrDA code will make it into 2.2.15, and then it
> will not use irmanager either (only irattach).

Ok, I see... (but it worked fine for me ;-)

> If you could find a way that irattach could be used for controlling FIR
> drivers as well as irtty.c, then that would be great. We need a tool that
> could configure, load and unload _any_ IrDA driver. It would be great if
> you could look at this issue.

I doubt I will have enought time and knowledge for that, also I would be
interesting to do that. Never the less I've downloaded yesterday the
2.3.31 kernel sources and got it running, and I had also a short closer
look at the irattach code. 

Is there any information around about the practical changes, when
irmanager is gone (how are the things irmanager did devided up between
kernel and irattach, what is still missing, who is executing the
/etc/irda/* scripts, if at all?). I expect, this has somehow been
discussed on the linux-irda mailinglist, but I haven't followed the
discussion on the list for a very long time, so it's a bit clumsy for me
to search the whole archive, can anybody give me a hint to a starting
thread on that. Any other link to some information would be appreciated,
too.

Thanx,
Martin

- -- 
Where do you want to go today? - As far from Redmond as possible!

For public PGP-key: finger mfluch@mathphys.fsk.uni-heidelberg.de




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBOFDirbCGSMW7I2etAQFqgwP/aYTm3oP1HqTxzZm5UWHIrqtodgUuH7+G
gw49un7nlSBjZbqjgEqkTk9DIXT7yk57K6Zg6cZTnvNnY5u0VXOR3MVfP57PxqSe
JATj4oPlZoRjskfATaE5BZRMch8Rv+cK8fGxv3GR7lamez83beH2M/j/eWKNW9sb
egpl6z221+s=
=lnXN
-----END PGP SIGNATURE-----





From fluch@rock.helsinki.fi Fri, 10 Dec 1999 13:28:20 +0200 (EET)
Date: Fri, 10 Dec 1999 13:28:20 +0200 (EET)
From: Martin Fluch fluch@rock.helsinki.fi
Subject: [Linux-IrDA]Q: char-major-108

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 10 Dec 1999, Per Wallner (QRA) wrote:

> What on earth is char-major-108????

mfluch@seneca:~> grep -A 2 ^108
/usr/src/linux/Documentation/devices.txt
108 char        Device independent PPP interface
                  0 = /dev/ppp          Device independent PPP interface

Martin

- -- 
Where do you want to go today? - As far from Redmond as possible!

For public PGP-key: finger mfluch@mathphys.fsk.uni-heidelberg.de

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBOFDj3bCGSMW7I2etAQFXWwQAjuUR7lQXN0GCqmRnR1r7/9+AFv2yfNiq
2g/Ngn1esOsheEMeDXYH8Mn3EDLSvKdRRJo7In50qq7kQ44IgcInhZiwezlbatlj
NehPoUBTQO6M3YrjVQ7RSdG9ffXAj+IpJioVCT3Wej1jDP1mJRqHho8rhb7/IQ50
eQFSmjRg92o=
=CV2q
-----END PGP SIGNATURE-----





From dagb@cs.uit.no 10 Dec 1999 12:44:34 +0100
Date: 10 Dec 1999 12:44:34 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Some words about the Linux-IrDA development

Hi,

I hope that people understand that we must be _very_ careful with what goes
into Linux-IrDA at this moment. A CVS style development _will_ definitively
screw things up! If people suddenly joins and wants to contribute, then
they must accept that I need to be suspisious about that they want to
do. Especially if they show lack of knowledge about how IrDA actually
works. When somebody sends in a patch, I look at it, and thinks this is
really great. He/she has found yet another bug in the stack. But I
sometimes cannot apply the patch fully because it will either breaks other
things, or doesn't follow the spec in an acceptable way. That person might
think it's correct (the reason he/she gets so angry), but he doesn't know
either the Linux-IrDA arch or the specs properly. I usually end up applying
the stuff I feel is safe, and merges it with the code I have written
myself. The result is something that I think is the best way ahead, even if
it's buggy or has a few errors. Those things will eventually be fixed.

My patches only shows where my current development is going. I started the
Ultra work, and I'm going to do it my way. If somebody disagree they should
maintain their own Ultra patches. It's really that simple! My only mistake
as I see it, is that I made some patches to early. This speeds the
development process, but makes people angry because some features doesn't
work or compile properly. It will probably not happen again, which is sad,
since waiting for a new patch will be like waiting for PyOBEX. I'm not so
sure I want to release PyOBEX if this is going to be the result!

I must admit that the current focus the last week has been IrCOMM and
memory leaks hunting (not Ultra as many people think). Both Chris Richards
and Pontus Fuchs are making more contribution to Linux-IrDA than most
others (that claims so). But in contrast to some people, they do not teach
me new English words in every mail.

The best contributer of the week is definitively Chris Richards. I just
mention this so that people on the list don't get the wrong impression
about the Linux-IrDA development. Many companies are interested in
Linux-IrDA, and I hope they don't get scared by the latest mails. That Jean
Tourrilhes of HEWLETT-PACKARD makes this list an uncomfortable place to be,
is just something I just have to apologize for.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From pb@labs.futuretv.com Fri, 10 Dec 1999 12:00:29 +0000
Date: Fri, 10 Dec 1999 12:00:29 +0000
From: Philip Blundell pb@labs.futuretv.com
Subject: [Linux-IrDA]Re: irda12 braindamages...

Dag Brattli wrote:

>Do we need two files, one irda.h for glibc and one for the kernel?

That is probably how things will turn out, I suspect.

p.






From jules@limitless.co.uk Fri, 10 Dec 1999 14:10:51 +0000
Date: Fri, 10 Dec 1999 14:10:51 +0000
From: Julian Perry jules@limitless.co.uk
Subject: [Linux-IrDA]Some words about the Linux-IrDA development

Dag and all,

> I hope that people understand that we must be _very_ careful with what goes
> into Linux-IrDA at this moment. A CVS style development _will_ definitively
> screw things up! If people suddenly joins and wants to contribute, then
> ...

As a non-contributing lurker, I must say that from what I've seen
a slightly different policy may be needed for releasing patches
as I get the feeling that the frequency and stability of patches
is a concern and that some people on the list are getting
confused and frustrated.

Don't get me wrong, rapid development and release of patches is
great - often projects get too bogged down and you have to wait 
months for fixes.

How about two levels of patch:

Stable - released every month or so, including all recent
  development, clean to install/compile.
  Always released as a complete cummulative patch on top
  of a well defined based (i.e. 2.2.13).

Dynamic - released as often as Dag is prepared too, not
  neccesarily clean to install/compile, and only based on
  last stable release.  These patches could each address
  individual issues and therefore be applicatble with or
  without eachother.

Make sense?  Crap idea?
-- 
Cheers
Jules.




From juergen@lufthansa.com Fri, 10 Dec 1999 16:32:27 +0100
Date: Fri, 10 Dec 1999 16:32:27 +0100
From: Juergen Mueller juergen@lufthansa.com
Subject: [Linux-IrDA]Some words about the Linux-IrDA development

Hi!

> > I hope that people understand that we must be _very_ careful with what goes
> > into Linux-IrDA at this moment. A CVS style development _will_ definitively
> > screw things up! If people suddenly joins and wants to contribute, then
> > ...
> 
> As a non-contributing lurker, I must say that from what I've seen
> a slightly different policy may be needed for releasing patches
> as I get the feeling that the frequency and stability of patches
> is a concern and that some people on the list are getting
> confused and frustrated.

I'm also a non-source-contributing reader of this list and actually can't
understand the worries going on here. Dag is writing this faboulus stuff in his
spare time, for free. As with everything: You get what you pay for!!

My approach for not being disappointed by breaking patches or similar things:
Wait for a patch to ripe two, three days. If there isn't a patch-patch out by
that time, it's considered stable from my side. 

This also covers the fact that I don't have the time to apply EVERY patch Dag
releases.

Just my EUR 0.02

Juergen





From dagb@cs.uit.no 10 Dec 1999 21:37:47 +0100
Date: 10 Dec 1999 21:37:47 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]WinCE and IrCOMM problems

Hi,

IrCOMM for Linux now works with most devices except WinCE. When WinCE
connects to Linux, it doesn't ask for IrDA:IrCOMM:Parameters or send any
initial parameters (as IrCOMM sais you should do). All it says is "CLIENT"
a couple of times before it disconnects. This smells like proprietary
stuff, so I'm a bit clueless! Anybody that can give me some hints.

PS. We really need to make irdadump follow speed changes!

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///

20:28:13.355562 snrm:cmd ca=fe pf=1 c677866c < 00001401 new-ca=24 (32) 
	ff93011400006c8677c62401012682010183013f84010f850180860102080107
	 . . . . . . l . w . $ . . & . . . . . ? . . . . . . . . . . . .
20:28:13.356383 ua:rsp ca=24 pf=1 c677866c > 00001401 (31) 
	24736c8677c60114000001012682010183013f84017f8501ff860101080107
	 $ s l . w . . . . . . . & . . . . . ? . . . . . . . . . . . .
20:28:13.533295 rr:cmd < ca=24 pf=1 nr=0 (2) 
	2511
	 % .
20:28:13.533556 rr:rsp > ca=24 pf=1 nr=0 (2) 
	2411
	 $ .
20:28:13.575205 i:cmd  < ca=24 pf=1 nr=0 ns=0 LM slsap=03 dlsap=00 CONN_CMD (6) 	251080030100
	 % . . . . .
20:28:13.575565 i:rsp  > ca=24 pf=1 nr=1 ns=0 LM slsap=00 dlsap=03 CONN_RSP (6) 	243083008100
	 $ 0 . . . .
20:28:13.613355 i:cmd  < ca=24 pf=1 nr=1 ns=1 LM slsap=03 dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "IrDA:TinyTP:LsapSel" (37) 
	25320003840b497244413a4972434f4d4d13497244413a54696e7954503a4c73
	 % 2 . . . . I r D A : I r C O M M . I r D A : T i n y T P : L s
20:28:13.614225 i:rsp  > ca=24 pf=1 nr=2 ns=1 LM slsap=00 dlsap=03 GET_VALUE_BY_CLASS: Success Integer: 1f (15) 
	24520300840000012343010000001f
	 $ R . . . . . . # C . . . . .
20:28:13.653318 i:cmd  < ca=24 pf=1 nr=2 ns=2 LM slsap=03 dlsap=00 DISC (6) 
	255480030201
	 % T . . . .
20:28:13.653649 rr:rsp > ca=24 pf=1 nr=3 (2) 
	2471
	 $ q
20:28:13.693358 i:cmd  < ca=24 pf=1 nr=2 ns=3 LM slsap=02 dlsap=1f CONN_CMD TTP credits=0(7) 
	25569f02010004
	 % V . . . . .
20:28:13.693726 i:rsp  > ca=24 pf=1 nr=4 ns=2 LM slsap=1f dlsap=02 CONN_RSP TTP credits=0(7) 
	2494821f81000e
	 $ . . . . . .
20:28:13.733274 rr:cmd < ca=24 pf=1 nr=3 (2) 
	2571
	 % q
20:28:13.733505 rr:rsp > ca=24 pf=1 nr=4 (2) 
	2491
	 $ .
20:28:13.773313 i:cmd  < ca=24 pf=0 nr=3 ns=4 LM slsap=02 dlsap=1f TTP credits=0 (12) 
	25681f020000434c49454e54
	 % h . . . . C L I E N T




From jburford@xsilogy.com Fri, 10 Dec 1999 13:07:33 -0800
Date: Fri, 10 Dec 1999 13:07:33 -0800
From: Jon Burford jburford@xsilogy.com
Subject: [Linux-IrDA]WinCE and IrCOMM problems

Yes, I have come accross this problem as well when trying to make an
IrCOMM/PPP connection with a WinCE device.  To get around it, you need to
manually start the connection.  Essentially you start by running a getty on
/dev/ircomm, making a serial console connection to the linux box (from CE
using "Make a connection as a Hayes Modem) and then when you get a login
prompt on the WinCE side, fire off PPP on the linux box on the IrCOMM link.
This page helped me start an IrCOMM/PPP connection between a Linux and WinCE
device:

http://www.the-gadgeteer.com/linux_ce.html

Good luck and let me know if you have any questions!  I am also very
interested in making this automated but haven't had time to come back to the
problem (our customers are all Palm users so I didn't much care).  I was
thinking that you might have to write a special WinCE app to make the thing
not do the funky CLIENT crap, but I actually think this is part of MS-CHAP
which is not supported by the Linux PPP SERVER (it is supported if you use
pppd to connect TO a MS-CHAP server).  So, even if you use the WinCE PPP
API, you still probably can't disable MS-CHAP.  The obviously better
approach is to either hack or correctly add support for MS-CHAP in the Linux
pppd.  This wasn't supported as of a few weeks ago in Linux pppd, but the
pppd guys knew about it and were thinking about adding it.

Regards,
Jon

----- Original Message -----
From: Dag Brattli <dagb@cs.uit.no>
To: <linux-irda@pasta.cs.UiT.No>
Sent: Friday, December 10, 1999 12:37 PM
Subject: [Linux-IrDA]WinCE and IrCOMM problems


> Hi,
>
> IrCOMM for Linux now works with most devices except WinCE. When WinCE
> connects to Linux, it doesn't ask for IrDA:IrCOMM:Parameters or send any
> initial parameters (as IrCOMM sais you should do). All it says is "CLIENT"
> a couple of times before it disconnects. This smells like proprietary
> stuff, so I'm a bit clueless! Anybody that can give me some hints.
>
> PS. We really need to make irdadump follow speed changes!
>
> -- Dag
>
> --
>    / Dag Brattli                   | The Linux-IrDA Project
/
>   // University of Tromsoe, Norway | Infrared communication for Linux
//
>  /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/
///
>
> 20:28:13.355562 snrm:cmd ca=fe pf=1 c677866c < 00001401 new-ca=24 (32)
> ff93011400006c8677c62401012682010183013f84010f850180860102080107
> . . . . . . l . w . $ . . & . . . . . ? . . . . . . . . . . . .
> 20:28:13.356383 ua:rsp ca=24 pf=1 c677866c > 00001401 (31)
> 24736c8677c60114000001012682010183013f84017f8501ff860101080107
> $ s l . w . . . . . . . & . . . . . ? . . . . . . . . . . . .
> 20:28:13.533295 rr:cmd < ca=24 pf=1 nr=0 (2)
> 2511
> % .
> 20:28:13.533556 rr:rsp > ca=24 pf=1 nr=0 (2)
> 2411
> $ .
> 20:28:13.575205 i:cmd  < ca=24 pf=1 nr=0 ns=0 LM slsap=03 dlsap=00
CONN_CMD (6) 251080030100
> % . . . . .
> 20:28:13.575565 i:rsp  > ca=24 pf=1 nr=1 ns=0 LM slsap=00 dlsap=03
CONN_RSP (6) 243083008100
> $ 0 . . . .
> 20:28:13.613355 i:cmd  < ca=24 pf=1 nr=1 ns=1 LM slsap=03 dlsap=00
GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "IrDA:TinyTP:LsapSel" (37)
> 25320003840b497244413a4972434f4d4d13497244413a54696e7954503a4c73
> % 2 . . . . I r D A : I r C O M M . I r D A : T i n y T P : L s
> 20:28:13.614225 i:rsp  > ca=24 pf=1 nr=2 ns=1 LM slsap=00 dlsap=03
GET_VALUE_BY_CLASS: Success Integer: 1f (15)
> 24520300840000012343010000001f
> $ R . . . . . . # C . . . . .
> 20:28:13.653318 i:cmd  < ca=24 pf=1 nr=2 ns=2 LM slsap=03 dlsap=00 DISC
(6)
> 255480030201
> % T . . . .
> 20:28:13.653649 rr:rsp > ca=24 pf=1 nr=3 (2)
> 2471
> $ q
> 20:28:13.693358 i:cmd  < ca=24 pf=1 nr=2 ns=3 LM slsap=02 dlsap=1f
CONN_CMD TTP credits=0(7)
> 25569f02010004
> % V . . . . .
> 20:28:13.693726 i:rsp  > ca=24 pf=1 nr=4 ns=2 LM slsap=1f dlsap=02
CONN_RSP TTP credits=0(7)
> 2494821f81000e
> $ . . . . . .
> 20:28:13.733274 rr:cmd < ca=24 pf=1 nr=3 (2)
> 2571
> % q
> 20:28:13.733505 rr:rsp > ca=24 pf=1 nr=4 (2)
> 2491
> $ .
> 20:28:13.773313 i:cmd  < ca=24 pf=0 nr=3 ns=4 LM slsap=02 dlsap=1f TTP
credits=0 (12)
> 25681f020000434c49454e54
> % h . . . . C L I E N T
>
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda





From paul.bristow@technologist.com Fri, 10 Dec 1999 22:35:29 +0100
Date: Fri, 10 Dec 1999 22:35:29 +0100
From: Paul Bristow paul.bristow@technologist.com
Subject: [Linux-IrDA]Some words about the Linux-IrDA development

I too have been following the Linux-IrDA development for quite some
time.

My 0.02 Euro's worth would be for those who have it working for what
they want to do to NOT follow the patches slavishly.  i.e. follow the
engineering rule: If it ain't broke don't fix it.  That way your
implementation works and Dag can fix up whatever he and the rest are
working on without worrying too much about the rest.  He always gets it
together in the end, and I for one have noticed significant improvements
in the ease of compiling/installation over the past few months.

My thanks to everyone working on this...

-- 

Paul (Who uses Linux-IrDA nearly every day, all over the world)

http://www.geocities.com/~paulbristow
ICQ# 11965223
paul.bristow@technologist.com
/* With Linux, Java and my Palm, I'm ready to face the day. */




From soruk@eridani.demon.co.uk Fri, 10 Dec 1999 23:52:58 +0000 (GMT)
Date: Fri, 10 Dec 1999 23:52:58 +0000 (GMT)
From: Michael McConnell soruk@eridani.demon.co.uk
Subject: [Linux-IrDA]Some words about the Linux-IrDA development

On Fri, 10 Dec 1999, Paul Bristow wrote:

> I too have been following the Linux-IrDA development for quite some
> time.

I'm pretty new to this but have been following with interest...

> My 0.02 Euro's worth would be for those who have it working for what
> they want to do to NOT follow the patches slavishly.  i.e. follow the
> engineering rule: If it ain't broke don't fix it.  That way your
> implementation works and Dag can fix up whatever he and the rest are
> working on without worrying too much about the rest.  He always gets it
> together in the end, and I for one have noticed significant improvements
> in the ease of compiling/installation over the past few months.

I have to agree on this - since the IrDA in kernel 2.2.13 works for me
virtually unchanged (slight fix needed for GIrBIL to compile) I haven't tried
any of the patches...

> My thanks to everyone working on this...

Seconded.

My £0.02 :-)

-- Michael "Soruk" McConnell		     [Eridani Linux 6.1A available]
Eridani Linux  --  The Most Up-to-Date Red Hat-based Linux CDROMs Available
Email: linux@eridani.co.uk  http://www.eridani.co.uk   Fax: +44-8701-600807
    "No. 'Eureka' is Greek for 'This bath is too hot.'" - Dr Who.





From jeant@rockfort.hpl.hp.com Fri, 10 Dec 1999 21:11:24 -0800
Date: Fri, 10 Dec 1999 21:11:24 -0800
From: Jean Tourrilhes jeant@rockfort.hpl.hp.com
Subject: [Linux-IrDA]Get IAS object from user space for irda12...

--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=us-ascii


	This is my leaving gift. Please ignore...

	Jean

--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irgetias12.diff"

diff -u -p linux/include/linux/irda.f3.h linux/include/linux/irda.h
--- linux/include/linux/irda.f3.h	Fri Dec 10 08:14:32 1999
+++ linux/include/linux/irda.h	Fri Dec 10 08:15:29 1999
@@ -85,6 +85,7 @@ typedef enum {
 
 #define IRLMP_ENUMDEVICES        1
 #define IRLMP_IAS_SET            2
+#define IRLMP_IAS_GET            2
 #define IRLMP_IAS_QUERY          3
 #define IRLMP_HINTS_SET		 4
 
diff -u -p linux/include/net/irda/irda.f3.h linux/include/net/irda/irda.h
--- linux/include/net/irda/irda.f3.h	Fri Dec 10 09:47:51 1999
+++ linux/include/net/irda/irda.h	Fri Dec 10 10:35:00 1999
@@ -135,12 +135,13 @@ struct irda_sock {
 	__u32 ckey;           /* IrLMP client handle */
 	__u32 skey;           /* IrLMP service handle */
 
-	struct ias_object *ias_obj;
-	struct iriap_cb *iriap;
+	struct ias_object *ias_obj;	/* Our service name + lsap in IAS */
+	struct iriap_cb *iriap;		/* Used to query remote IAS */
+	struct ias_value *ias_result;	/* Used by getsockopt(IRLMP_IAS_QUERY) */
 
 	int nslots;           /* Number of slots to use for discovery */
 
-	int errno;
+	int errno;		/* status of the IAS query */
 
 	struct sock *sk;
 	struct wait_queue *ias_wait;       /* Wait for LM-IAS answer */
diff -u -p linux/net/irda/af_irda.f3.c linux/net/irda/af_irda.c
--- linux/net/irda/af_irda.f3.c	Fri Dec 10 08:10:04 1999
+++ linux/net/irda/af_irda.c	Fri Dec 10 13:27:49 1999
@@ -976,6 +976,7 @@ static int irda_create(struct socket *so
 	self->mask = 0xffff;
 	self->rx_flow = self->tx_flow = FLOW_START;
 	self->nslots = DISCOVERY_DEFAULT_SLOTS;
+	self->daddr = DEV_ADDR_ANY;
 
 	/* Notify that we are using the irda module, so nobody removes it */
 	irda_mod_inc_use_count();
@@ -1687,6 +1688,101 @@ static int irda_setsockopt(struct socket
 }
 
 /*
+ * Function irda_simple_get_value_confirm (obj_id, value, priv)
+ *
+ *    Got answer from remote LM-IAS, just copy object to requester...
+ *
+ * Note : duplicate from above, but we need our own version that
+ * doesn't touch the dtsap_sel and save the full value structure...
+ */
+static void irda_simple_get_value_confirm(int result, __u16 obj_id, 
+					  struct ias_value *value, void *priv)
+{
+	struct irda_sock *self;
+	
+	IRDA_DEBUG(2, __FUNCTION__ "()\n");
+
+	ASSERT(priv != NULL, return;);
+	self = (struct irda_sock *) priv;
+	
+	if (!self) {
+		WARNING(__FUNCTION__ "(), lost myself!\n");
+		return;
+	}
+
+	/* We probably don't need to make any more queries */
+	iriap_close(self->iriap);
+	self->iriap = NULL;
+
+	/* Check if request succeeded */
+	if (result != IAS_SUCCESS) {
+		IRDA_DEBUG(0, __FUNCTION__ "(), IAS query failed!\n");
+
+		self->errno = result;
+
+		/* Wake up any processes waiting for result */
+		wake_up_interruptible(&self->ias_wait);
+
+		return;
+	}
+
+	/* Clone the object (so the requester can free it) */
+	self->ias_result = kmalloc(sizeof(struct ias_value), GFP_ATOMIC);
+	memcpy(self->ias_result, value, sizeof(struct ias_value));
+
+	/* Wake up any processes waiting for result */
+	wake_up_interruptible(&self->ias_wait);
+}
+
+/*
+ * Function irda_extract_ias_value(ias_opt, ias_value)
+ *
+ *    Translate internal IAS value structure to the user space representation
+ *
+ * The external representation of IAS values, as we exchange them with
+ * user space program is quite different from the internal representation,
+ * as stored in the IAS database (because we need a flat structure for
+ * crossing kernel boundary).
+ * This function transform the former in the latter. We also check
+ * that the value type is valid.
+ */
+static int irda_extract_ias_value(struct irda_ias_set *ias_opt,
+				  struct ias_value *ias_value)
+{
+	/* Look at the type */
+	switch(ias_value->type) {
+	case IAS_INTEGER:
+		/* Copy the integer */
+		ias_opt->attribute.irda_attrib_int = ias_value->t.integer;
+		break;
+	case IAS_OCT_SEQ:
+		/* Set length */
+		ias_opt->attribute.irda_attrib_octet_seq.len = ias_value->len;
+		/* Copy over */
+		memcpy(ias_opt->attribute.irda_attrib_octet_seq.OctetSeq,
+		       ias_value->t.oct_seq, ias_value->len);
+		break;
+	case IAS_STRING:
+		/* Set length */
+		ias_opt->attribute.irda_attrib_string.len = ias_value->len;
+		ias_opt->attribute.irda_attrib_string.charset = ias_value->charset;
+		/* Copy over */
+		memcpy(ias_opt->attribute.irda_attrib_string.string,
+		       ias_value->t.string, ias_value->len);
+		/* NULL terminate the string (avoid troubles) */
+		ias_opt->attribute.irda_attrib_string.string[ias_value->len] = '\0';
+		break;
+	default :
+		return -EINVAL;
+	}
+
+	/* Copy type over */
+	ias_opt->irda_attrib_type = ias_value->type;
+
+	return 0;
+}
+
+/*
  * Function irda_getsockopt (sock, level, optname, optval, optlen)
  *
  *    
@@ -1700,8 +1796,13 @@ static int irda_getsockopt(struct socket
 	struct irda_device_list list;
 	struct irda_device_info *info;
 	discovery_t *discovery;
+	struct irda_ias_set	ias_opt;	/* IAS get/query params */
+	struct ias_object *	ias_obj;	/* Object in IAS */
+	struct ias_attrib *	ias_attr;	/* Attribute in IAS object */
+	int daddr = 0;		/* Destination address for IAS queries */
 	int val = 0;
 	int len = 0;
+	int err;
 	int offset, total;
 
 	self = sk->protinfo.irda;
@@ -1757,7 +1858,7 @@ static int irda_getsockopt(struct socket
 				strncpy(info->info, discovery->nickname,
 					NICKNAME_MAX_LEN);
 
-				if (copy_to_user(optval+offset, info, 
+				if (copy_to_user(optval+total, info, 
 						 sizeof(struct irda_device_info)))
 					return -EFAULT;
 				list.len++;
@@ -1786,10 +1887,103 @@ static int irda_getsockopt(struct socket
 		if (copy_to_user(optval, &val, len))
 			return -EFAULT;
 		break;
-		/*
-	  if (copy_to_user(wrq->u.data.pointer, (u_char *) priv, sizeof(priv)))
-	  	ret = -EFAULT;
-		*/
+	case IRLMP_IAS_GET:
+		/* The user want an object from our local IAS database.
+		 * We just need to query the IAS and return the value
+		 * that we found */
+
+		/* Check that the user has allocated the right space for us */
+		if (len != sizeof(ias_opt))
+			return -EINVAL;
+
+		/* Copy query to the driver. */
+		if (copy_from_user((char *) &ias_opt, (char *)optval, len))
+		  	return -EFAULT;
+
+		/* Find the object we target */
+		ias_obj = irias_find_object(ias_opt.irda_class_name);
+		if(ias_obj == (struct ias_object *) NULL)
+			return -EINVAL;
+
+		/* Find the attribute (in the object) we target */
+		ias_attr = irias_find_attrib(ias_obj,
+					     ias_opt.irda_attrib_name); 
+		if(ias_attr == (struct ias_attrib *) NULL)
+			return -EINVAL;
+
+		/* Translate from internal to user structure */
+		err = irda_extract_ias_value(&ias_opt, ias_attr->value);
+		if(err)
+			return err;
+
+		/* Copy reply to the user */
+		if (copy_to_user((char *)optval, (char *) &ias_opt,
+				 sizeof(ias_opt)))
+		  	return -EFAULT;
+		/* Note : don't need to put optlen, we checked it */
+		break;
+	case IRLMP_IAS_QUERY:
+		/* The user want an object from a remote IAS database.
+		 * We need to use IAP to query the remote database and
+		 * then wait for the answer to come back. */
+
+		/* Check that the user has allocated the right space for us */
+		if (len != sizeof(ias_opt))
+			return -EINVAL;
+
+		/* Copy query to the driver. */
+		if (copy_from_user((char *) &ias_opt, (char *)optval, len))
+		  	return -EFAULT;
+
+		/* Check the destination address requested */
+		daddr = ias_opt.attribute.irda_attrib_int;
+		if(self->daddr != DEV_ADDR_ANY) {
+			/* If we are connected, we must use the correct
+			 * destination address (or leave it unspecified) */
+			if((daddr != DEV_ADDR_ANY) || (daddr != self->daddr))
+				return -EINVAL;
+			daddr = self->daddr;
+		} else {
+			/* If we are not connected, we must specify a valid
+			 * destination address */
+			if(daddr == DEV_ADDR_ANY)
+				return -EINVAL;
+		}
+
+		/* Check that we can proceed with IAP */
+		if (self->iriap) {
+			WARNING(__FUNCTION__
+				"(), busy with a previous query\n");
+			return -EBUSY;
+		}
+
+		self->iriap = iriap_open(LSAP_ANY, IAS_CLIENT, self,
+					 irda_simple_get_value_confirm);
+
+		/* Query remote LM-IAS */
+		self->errno = 0;
+		iriap_getvaluebyclass_request(self->iriap, self->saddr,
+					      daddr,
+					      ias_opt.irda_class_name,
+					      ias_opt.irda_attrib_name);
+		/* Wait for answer */
+		interruptible_sleep_on(&self->ias_wait);
+		/* Check what happened */
+		if(self->errno)
+			return(self->errno);
+
+		/* Translate from internal to user structure */
+		err = irda_extract_ias_value(&ias_opt, self->ias_result);
+		kfree(self->ias_result); /* Cleanup (need to be *here*) */
+		if(err)
+			return err;
+
+		/* Copy reply to the user */
+		if (copy_to_user((char *)optval, (char *) &ias_opt,
+				 sizeof(ias_opt)))
+		  	return -EFAULT;
+		/* Note : don't need to put optlen, we checked it */
+		break;
 	default:
 		return -ENOPROTOOPT;
 	}

--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="irdaspray.magic.c"

/*********************************************************************
 *                
 * Filename:      irdaspray.c
 * Version:       
 * Description:   
 * Status:        Experimental.
 * Author:        Dag Brattli <dagb@cs.uit.no>
 *		  Jean Tourrilhes <jt@hpl.hp.com>
 * Created at:    10/12/99
 * Modified at:   Mon May 10 18:31:35 1999
 * Modified by:   Dag Brattli <dagb@cs.uit.no>
 * 
 *     Copyright (c) 1999 Dag Brattli, 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.
 * 
 *     This program is distributed in the hope that it will be useful,
 *     but WITHOUT ANY WARRANTY; without even the implied warranty of
 *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 *     GNU General Public License for more details.
 * 
 *     You should have received a copy of the GNU General Public License 
 *     along with this program; if not, write to the Free Software 
 *     Foundation, Inc., 59 Temple Place, Suite 330, Boston, 
 *     MA 02111-1307 USA
 *     
 ********************************************************************/

/*
 * This program demonstrate the use of auto-connect (connect to a service
 * without having to discover/specify an address) and how a program
 * can report discovery results to the user in case the service is not
 * unique on the network.
 * Of course, you need both auto-connect and query-ias in the kernel, and
 * a few bugs sorted out...
 *
 * Jean Tourrilhes
 */

#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/wait.h>

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>

#include <linux/irda.h>

#ifndef AF_IRDA
#define AF_IRDA 23
#endif /* AF_IRDA */

#define MAX_DEVICES 10

int fd;
int mtu = 0;
int frame_size = 1024;
int frame_number = 100;
unsigned char buf[4096];
int delay = 0;
int echo = 0;             /* Use discard service by default */

/*
 * Function echo_discover_devices (fd)
 *
 *    Try to discover some remote device(s) that we can connect to
 *
 */
int irdaspray_discover_devices(int fd, char *service_name)
{
	struct irda_device_list *list;
	struct irda_ias_set ias_query;
	unsigned char *buf;
	int err;
	int len;
	int i;

	/* Get the name of our own device (not essential) */
	len = sizeof(ias_query);
	strcpy(ias_query.irda_class_name, "Device");
	strcpy(ias_query.irda_attrib_name, "DeviceName");
	if (!getsockopt(fd, SOL_IRLMP, IRLMP_IAS_GET, &ias_query, &len)) {
		printf("The name of our device is = ``%s''\n",
		       ias_query.attribute.irda_attrib_string.string);
	}

	/* Init... Note : should be cleaned up... */
	len = sizeof(struct irda_device_list) +
		sizeof(struct irda_device_info) * MAX_DEVICES;

	buf = malloc(len);
	list = (struct irda_device_list *) buf;
	

	/* Perform a discovery and get device list */
	if (getsockopt(fd, SOL_IRLMP, IRLMP_ENUMDEVICES, buf, &len)) {
		perror("getsockopt-enum");
		exit(-1);
	}

	/* Did we got any ? */
	if ((len <= 0) || (list->len <= 0)) {
		printf("Didn't find any devices!\n");
		return -1;
	}

	/* List all devices */
	printf("Discovered %d devices :\n", list->len);
	for (i=0;i<list->len;i++) {
		printf("  [%d] name:  %s, daddr: 0x%08x",
		       i + 1, list->dev[i].info, list->dev[i].daddr);

		/* Ask if the requested service exist on this device */
		len = sizeof(ias_query);
		ias_query.attribute.irda_attrib_int = list->dev[i].daddr;
		strcpy(ias_query.irda_class_name, service_name);
		strcpy(ias_query.irda_attrib_name, "IrDA:TinyTP:LsapSel");
		err = getsockopt(fd, SOL_IRLMP, IRLMP_IAS_QUERY,
				 &ias_query, &len);
		if(err == 0) {
			printf(", has service %s\n", service_name);
		} else {
			if(err != 1)
				printf(" <can't query IAS>\n");
			else
				printf("\n");
		}
	}
			
	/* Ask the user */
	printf("Enter device number:");
	fflush(stdout);
	if(scanf("%X", &i) != 1)
		return -1;
	i--;
	if((i < 0) && (i > list->len))
		return -1;
	return(list->dev[i].daddr);
}

/*
 * Function irdaspray_connect_request (self)
 *
 *    Try to connect to remote device
 *
 */
static int irdaspray_connect_request(int fd)
{
	struct sockaddr_irda peer;
	char *service_name;
	int len = sizeof(int);
	int daddr;
	int err;

	/* Set the service name */
	if (echo)
		service_name = "IrECHO";
	else
		service_name = "IrDISCARD";

	/*
	 * First, we try the auto-connect, which in 99% of the case
	 * should be good enough...
	 *
	 * Auto connect lookup devices in range and query them about the
	 * service we want. If there is only one device that support
	 * this service, we are magically connected to it...
	 */
	peer.sir_family = AF_IRDA;
	strncpy(peer.sir_name, service_name, 25);
	peer.sir_addr = 0x0;	/* Maybe DEV_ADDR_ANY is better ? */
	
	err = connect(fd, (struct sockaddr*) &peer, 
		      sizeof(struct sockaddr_irda));

	/* Check what has happened */
	if(err == 0) {
		printf("Auto-connect did found exactly one device !\n");
		return 0;
	}
	if(err != -ENOTUNIQ) {
		printf("Auto-connect could not find anything...\n");
		return -1;
	}

	printf("Auto-connect has found more than one device...\n");
	/*
	 * At this point, if we don't have any user interface or if we
	 * don't want to bother with that, we could just tell the user
	 * to aim its device closer to the target and just quit...
	 * However, for the purpose of the exercise, let's pretend that
	 * the user doesn't want to move his device and has plenty of UI...
	 */

	/* Make a proper discovery and ask user to choose */
	daddr = irdaspray_discover_devices(fd, service_name);
	if (daddr == -1)
		return -1;

	/* Now we can try again to connect using the address */
	peer.sir_family = AF_IRDA;
	strncpy(peer.sir_name, service_name, 25);
	peer.sir_addr = daddr;
	
	if (connect(fd, (struct sockaddr*) &peer, 
		    sizeof(struct sockaddr_irda))) {
		perror("connect");
		return -1;
	}

	return 0;
}

int irdaspray_transmit(int fd)
{
	int total = 0;
	int actual;
	int i;

	/* Transmit frames */
	for (i=0; i<frame_number; i++) {
		actual = send(fd, buf, frame_size, 0);
		total += actual;
	}
	return total;
}

int irdaspray_receive(int fd)
{
	int total = 0;
	int actual;
	int i;

	/* Receive frames */
	for (i=0; i<frame_number; i++) {
		actual = recv(fd, buf, sizeof(buf), 0);
		total += actual;
	}
	return total;
}

static void usage(char *argv[])
{
	fprintf(stderr, "usage: %s [-v] [-e] [-h] [-b frame-size] [-n frames] [-f file] [device]\n", argv[0]);
	fprintf(stderr, "      -v verbose\n");
	fprintf(stderr, "      -e use echo service for full duplex transfer\n");
	fprintf(stderr, "      -h print this message\n");
	fprintf(stderr, "      -b frame-size in bytes (default 1024)\n");
	fprintf(stderr, "      -n number of frames (default 100)\n");
	fprintf(stderr, "      -f file to preload buffer (zero buffer by default)\n");
	fprintf(stderr, "      -d inter-buffer transmission delay in usecs (default 0)\n");
	exit(1);
}

/*
 * Function main (argc, )
 *
 *    
 *
 */
int main(int argc, char *argv[])
{
	struct timeval start, end;
	int total;
	double time;
	int status;
	int ret;
	int c;
	int pid = 0;

	while ((c = getopt(argc, argv, "vehs:m:n:f:d:")) != -1) {
		switch (c) {
 		case 'm':
 			mtu = atoi(optarg);
 			break;
			
 		case 'e':
 			echo = 1; /* Use echo service instead of discard */
 			break;
			
		case 'h':
			usage(argv);
			break;
			
		case 'n':
			frame_number = atoi(optarg);
			break;
			
		case 's':
			frame_size = atoi(optarg);
			break;
			
/* 		case 'f': */
/* 			fflag = TRUE; */
/* 			if ((infile = fopen(optarg, "r")) == NULL) { */
/* 				fprintf(stderr, "%s: Can't open file %s.\n", argv[0], optarg); */
/* 				exit(2); */
/* 			} */
/* 			break; */
			
		case 'd':
			delay = atoi(optarg);
			break;
			
		default:
			usage(argv);
			break;
		}
	}

	/* Create socket */
	fd = socket(AF_IRDA, SOCK_STREAM, 0);
	if (fd < 0) {
		perror("socket");
		exit(-1);
        }

	/* Try connect */
	ret = irdaspray_connect_request(fd);
	if (ret) {
		return -1;
	}
	
	printf("Connected!\n");

	gettimeofday(&start, (struct timezone*) 0);

	if (echo) {
		/* Fork off receiver */
		pid = fork();
		
		if (pid) {
			total = irdaspray_receive(fd);
		} else {
			total = irdaspray_transmit(fd);
		}
	} else
		total = irdaspray_transmit(fd);

	gettimeofday(&end, (struct timezone*) 0);

	time = (double) (end.tv_sec - start.tv_sec) + (double)
		((double) (end.tv_usec - start.tv_usec) / 1000000.0);

	if (pid) 
		printf("Received %d bytes in %f seconds (%0.3f kbytes/s)\n",
		       total, time, (double) (total / time) / 1024); 
	else {
		if (echo)
			wait(&status);
		
		printf("Transmitted %d bytes in %f seconds (%0.3f kbytes/s)\n",
		       total, time, (double) (total / time) / 1024);
	}

	return 0;
}

--HlL+5n6rz5pIUxbD--




From nlhommet@netcourrier.com Sun, 12 Dec 1999 00:36:13 +0100
Date: Sun, 12 Dec 1999 00:36:13 +0100
From: Nicolas Lhommet nlhommet@netcourrier.com
Subject: [Linux-IrDA]Help! IRDA with Toshiba Libretto 110CT + HP LaserJet 5P

Hello, i have a Toshiba Libretto 110 CT and a HP LaserJet 5P printer.
I'm running kernel 2.2.13 and i got a lot of difficulties to make work IRDA
with the printer (in fact it worked with W98 of M$ the first time i tried
but i'm a kind of a masochist)
It works fine through parallel port but not with infrared port.
I looked at all the documentation i could find (IR-HOWTO mostly) and now i
understand almost nothing :)
So, i have some basic questions (in fact there's only one: 'how to print on
my HP Lasejet 5P with linux on my Libretto 110CT through IRDA ?') :

1) Should I apply the latest kernel patch (patch-2.2.13-irda9) ?
Without the patch, linux crashes on boot, when irda drivers are built in the
kernel.
With the patch, IRLTP client and server have disappeared when i do 'make
menuconfig'.

2) Should I build the irda drivers compiled in the kernel or as modules ?

3) What kernel configurations options do i need ?
Do I need irtty, o ircomm ?
I always choose the toshoboe driver, is that right ?

4) for /etc/conf.modules :
Since i use 2.2.13 kernel, i think i need to add :
alias tty-ldisc-11 irtty
alias char-major-60 ircomm-tty

Is it right ? Is 60 the right major device-number ?

5) How to start Irda ?
Do i really need irmanager or irattach ?
Should i start my modules in a specific order ?
Should i start toshoboe module first ?
How should i configure /etc/irda/drivers ?
Should i configure /etc/irda/printer ?

6) One of the most written thing in this mailing list is :
'here is what you need in /dev:
dagbnb /usr/src > ll /dev/ir*
crw---------    1    dagb    161,    0    Aug    25     20:13
/dev/ircomm0 '
...

(I understood that major number 161 is for kernels 2.3.x.)
Are these device files created automatically, or when you say 'here is what
you need' does it mean that i have to type :
mknod /dev/irlpt0    c    161    16
However, i always obtain this kind of error message :"this device does not
exist" when i do 'cat textfile > /dev/irlpt0' (after i created the file
/dev/irlpt0 with mknod).

7) In the IR-HowTo, i can read :
"to print somthing, make a modprobe irtty, and a modprobe irlpt_client, then
mknod /dev/irlpt0 c 10 <minor device number>, you can find this number in
/proc/misc on the same line that irlpt0"
But i've never found any 'irlpt0' line in /proc/misc. The only irda-related
thing i find is : '63 irda'.

8) Enough for today :)

I know that you may be tired answering always the same questions, but after
two weeks i spent to make it not work, i really need your help. Thank you.

Nicolas Lhommet
nlhommet@netcourrier.com











From dagb@cs.uit.no 12 Dec 1999 11:45:06 +0100
Date: 12 Dec 1999 11:45:06 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Interested in FIR (4Mbps) support for your laptop?

Hi,

I just want to make a quick poll on the list to find out if you would be
interested in getting yourself a FIR (4Mbps) IrDA PCMCIA card. This card is
a must for all of you that wants FIR support for your Linux laptop now, and
don't want to wait for somebody to write a driver for your builtin FIR port
(or if your laptop don't support FIR). The company which produces the card
wants to know if there are any interests for it in the Linux community.

	Visit http://www.irdatacorp.com/ for more info

The card contains an IBM 31T1502 chipset which uses shared memory to
transfer data between the card and the laptop. This makes it much more
reliable than ISA DMA transfers which suffers badly when you have disk
activity at the same time (downloading large files from the web).

The Linux driver were in fact written half a year ago (by myself) and is
stable. This card is also very fast, and I have measured FTP speeds of over
340 Kbytes/s (IrLAN). So now you know where I got those high speeds from
;-) I'm pretty sure you will never get the same performance out of any ISA
based FIR solution (which most laptops today use). And getting drivers for
all laptops will take uncountable number of hours to impl, debug, test, etc
anyway.

This is a real chance of getting stable high performance FIR support for
your laptop today, so if you are interested, then please send me a mail
which tells if you would 1) definitively, 2) most probably or 3) maybe be
buying such a card. They need to know how many units they should prepare
for Linux users, so I'll make a list and ship it over to them in a week or
so. Remember that this is just a poll to check the interest. You don't
commit to anything!

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From noguchi@npost1.netspace.or.jp Sun, 12 Dec 1999 21:33:39 +0900
Date: Sun, 12 Dec 1999 21:33:39 +0900
From: NOGUCHI Hiroshi noguchi@npost1.netspace.or.jp
Subject: [Linux-IrDA]Linux-IRDA on PPC - getting better

Hello, all.

David Ray <daver@idiom.com> writes:

> I've installed the latest IRDA patch for 2.2.13 and compiled the kernel with
> mostly good success on a LinuxPPC machine (Apple Powerbook G3 'wallsreet').
> Here's a status report.

I also installed into PowerBook G3 "Wallstreet".
The kernel is 2.2.13 and I patched the latest.

For kernel, I installed all except for FIR drivers as module.
For IrDA tools, I compiled irmanager, irattach and irdadump of rev 0.95.

I did the follows as configurations:

(1) in /etc/irda/drivers, enabled "irattach /dev/ttyS1" line.
(2) in /etc/conf.modules, added the lines:
      alias tty-ldisc-11 irtty
      alias char-major-161 ircomm-tty
(3) add the IrCOMM device (executed "mknod /dev/ircomm 161 0")

Rebooting and executing "irmanager -d 1", and "irattach /dev/ttyS1"
seemded to succeed.

Next, I tried "irdadump" with an IrTran-P digital camera.
Attemped to send an image from camera, but no data was dumped.

Then I also tried IrCOMM, connecting between Windows 98 PC via terminal
emulator.
  - on Linux PPC, ran "cu -l /dev/ircomm"
    (IrCOMM was loaded and "cu" said no error.)
  - on Windows 98 laptop PC, ran terminal software "Tera Term Pro".
As result, I failed this.

I dont' know what I did something wrong.

I have IrDA ready items:
 - PowerBook G3 (Wallstreet)
 - laptop PC (has NS 87338 FIR chip, Windows 98 runs)
 - IrCOMM/IrTran-P printer, Canon BJ-M70 (max 4Mbps)
 - IrTran-P camera, Casio QV-7000SX (max 1Mbps)

I would to like to join tests...


--------------------------------
Hiroshi Noguchi
E-mail: noguchi@npost1.netspace.or.jp
http://homepage1.nifty.com/driver/




From kh@club.innet.be Sun, 12 Dec 1999 14:32:14 +0100
Date: Sun, 12 Dec 1999 14:32:14 +0100
From: Kris Heyrman kh@club.innet.be
Subject: [Linux-IrDA]SH888 on Dell Latitude CPt C333: problem

--------------90155280C43007E2EDBFDC70
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Okay, I think I need some help here, setting up a Dell Latitude CPt
C333  to use a Ericson SH888 GSM phone to communicate, using the
infrared port. I must be doing something wrong, but cannot see what it
is.

I hope that somebody on this mailinglist will be able to help me, or
suggest further ways of exploration.

If so, please accept my warm gratitude, and if not, please don't read on
because I think tales like the one below are commonplace.

*I am using Red Hat 6.0.

* I was encouraged by http://rosebud.sps.queensu.ca/~edd/lcpt33.html
which said that the IrDA port had been successfully used on this type of
laptop.

* I checked that IrDA was enabled in the BIOS.

*I obtained the sources of Linux Kernel 2.2.13, and patched it with
sony-patch.2.2.13 for sound,  and patch-2.2.13-irda3 for IrCOMM. I also
provided it with pcmcia-cs-3.0.14 sources for card services
  (with CardBus support, and using /etc/pcmcia/network from RedHat, not
from distribution of pcmcia-cs)

* I installed irda-utils 0.9.4, most of which compiled correctly -- in
fact, all of those which I think I need.

* In /etc/conf.modules I put

        alias tty-ldisc-11 irtty

        alias char-major-161 ircomm_tty

  I saw that in many items of documentation it says

        alias char-major-161 ircomm-tty

  with a dash instead of an underscore, but doing that justs results in
a module not being found. I am curious about this, though, since the
dash comes up again in some mails I found on the Linux-IrDA mailing
list.

*I made devices:

        crw-rw-rw-   1 root     root     161,   0 Dec  7 09:32 /dev/ircomm0

        crw-rw-rw-   1 root     root     161,   1 Dec  7 09:32 /dev/ircomm1


* In the menu of my SH888, I 'activate the IR port'.

*I reboot and type

        # irmanager -s1 -d1

  The system log shows

        Dec 12 14:01:58 rennell irmanager: executing: '/sbin/modprobe irda'

        Dec 12 14:01:59 rennell kernel: IrDA (tm) Protocols for Linux-2.2 (Dag B

rattli)

        Dec 12 14:01:59 rennell irmanager: executing: 'echo 1 > /proc/sys/net/ir

da/discovery'

        Dec 12 14:01:59 rennell irmanager: executing: 'echo rennell > /proc/sys/

net/irda/devname'


*Now, according to the documentation I found, I should

        # irattach /dev/ircomm0

  Doing this shows

        0.1 Fri Jul 25 11:45:26 1997 Dag Brattli

  but the system log says:

        Dec 12 14:04:58 rennell kernel: Linux-IrDA: IrCOMM protocol ( revision:T

ue May 18 03:11:39 1999 )

        Dec 12 14:04:58 rennell kernel: ircomm_tty: virtual tty driver for IrCOM

M ( revision:Wed May 26 00:49:11 1999 )

        Dec 12 14:04:58 rennell irattach: Failed to open /dev/ircomm0: No such d

evice


*Trying do exercise /dev/ircomm0 with 'kermit', 'cu -l /dev/ircomm0',
  'dip -t' and 'minicom' all fail.

*On the other hand, the URL quoted above says one should 'irattach'
with /dev/ttyS2. I do not understand the logic of this, but I'll try.

         # irattach /dev/ttyS2

  It responds

        0.1 Fri Jul 25 11:45:26 1997 Dag Brattli

  and syslog says

        Dec 12 14:13:09 rennell irattach: Serial connection established.

        Dec 12 14:13:09 rennell kernel: IrDA: Registered device irda0

  Aha!

        # more /proc/net/irda/discovery

  says

        IrLMP: Discovery log:

        name: SH 888, hint: 0x9104, saddr: 0xc6ec6dd0, daddr: 0x21192e89

  and

        # irdaping 0x21192e89

  says

        32 bytes from 0x21192e89: irda_seq=0 time=110.39 ms.

        32 bytes from 0x21192e89: irda_seq=2 time=110.43 ms.

        32 bytes from 0x21192e89: irda_seq=3 time=110.44 ms.

        32 bytes from 0x21192e89: irda_seq=5 time=108.71 ms.

        32 bytes from 0x21192e89: irda_seq=6 time=108.32 ms.

        32 bytes from 0x21192e89: irda_seq=8 time=114.54 ms.

        32 bytes from 0x21192e89: irda_seq=9 time=114.26 ms.

        32 bytes from 0x21192e89: irda_seq=11 time=110.44 ms.

        32 bytes from 0x21192e89: irda_seq=12 time=110.43 ms.

        32 bytes from 0x21192e89: irda_seq=14 time=110.44 ms.

        32 bytes from 0x21192e89: irda_seq=15 time=110.44 ms.

   A few lost packets there, but oh well.

*Let's check the other files in /proc/net/irda:

        # head *

   It says:

        ==> ircomm <==

        instance 0:

                unused

        ==> irda_device <==

        irda0,  binding: irda0 <-> ttyS2

                UP RUNNING SIR PIO

                bps     maxtt   dsize   winsize addbofs mintt   ldisc

                9600    50      2048    7       0       5000    40

        ==> irias <==

        LM-IAS Objects:

        name: Device, id=21314

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

       ==> irlap <==

        irlap0 <-> irda0 state: LAP_NDM

          caddr: 0x9c, saddr: 0xc6ec6dd0, daddr: 0x000000

          win size: 0, win: 0, win bytes: 0, bytes left: 0

          tx queue len: 0 win queue len: 0 rbusy: FALSE

          retrans: 0 vs: 0 vr: 0 va: 0

          qos   bps     maxtt   dsize   winsize addbofs mintt   ldisc   comp

          tx    9600    0       64      0       11      0       0       0

          rx    9600    0       0       0       0       0       0       0

        ==> irlmp <==

        Unconnected LSAPs:

        lsap state: LSAP_DISCONNECTED, slsap_sel: 0x0, dlsap_sel: 0xff, (IrIAS s

rv)

        Registred Link Layers:

        lap state: LAP_STANDBY, saddr: 0xc6ec6dd0, daddr: 0xffffffff,

        Connected LSAPs:

        ==> irttp <==

* Why this should be so I do not know, but it looks OK:

        # ifconfig

  has an entry:

        irda0     Link encap:UNSPEC  HWaddr D0-6D-EC-C6-00-00-00-D9-00-00-00-00-

00-00-00-00

                  UP RUNNING NOARP  MTU:2048  Metric:1

                  RX packets:167 errors:0 dropped:0 overruns:0 frame:0

                  TX packets:1109 errors:0 dropped:0 overruns:0 carrier:0

                  collisions:0 txqueuelen:8

*Now:

        # dip -t

        ># dip -t

        DIP: Dialup IP Protocol Driver version 3.3.7o-uri (8 Feb 96)

        Written by Fred N. van Kempen, MicroWalt Corporation.

        DIP> port ttyS2

        #

  It exits, and the sys log shows.

        Dec 12 14:27:46 rennell dip[831]: DIP: tty: set_state: Invalid argument

*Try:

        # cu -l /dev/ttyS2

        cu: Stale lock /var/lock/LCK..ttyS2 held by process 831 created 1999-12-

12 14:27:46

        cu: open (/dev/ttyS2): Permission denied

        cu: /dev/ttyS2: Line in use

        #

   It also exits, there is nothing in sys log.

*Try the venerable kermit:

        # kermit

        C-Kermit 5A(190), 4 Oct 94, for Linux

         Copyright (C) 1985, 1994,

          Trustees of Columbia University in the City of New York.

        Type ? or HELP for help.

        C-Kermit>set line /dev/ttyS2

        C-Kermit>connect

        Connecting to /dev/ttyS2, speed 9600.

        The escape character is Ctrl-\ (ASCII 28, FS)

        Type the escape character followed by C to get back,

        or followed by ? to see other options.

        Sorry, Can't condition communication line

        C-Kermit>quit

        #

   It also exits, there is nothing in sys log.

*Minicom also fails.

Also funny is the output from

        # lsmod

  It says:

        Module                  Size  Used by

        irtty                   4636   2  (autoclean)

        ircomm_tty             17604   0  (autoclean) (unused)

        ircomm                 18040   0  (autoclean) [ircomm_tty]

        irda                  135713   2  [irtty ircomm_tty ircomm]

        nm256                  64456   0  (unused)

        sound                  57228   0  [nm256]

        soundcore               2372   6  [sound]

        vmnet                  11200   3

        vmppuser                5216   0  (unused)

        parport_pc              5620   0  [vmppuser]

        parport                 7124   0  [vmppuser parport_pc]

        vmmon                  15072   0  (unused)

        nfsd                  150496   8  (autoclean)

        3c575_cb               18792   2

        cb_enabler              2104   2  [3c575_cb]

        ds                      5740   2  [cb_enabler]

        i82365                 22640   2

        pcmcia_core            39912   0  [cb_enabler ds i82365]

  Why is ircomm_tty unused?

If you have read up to here, maybe you can suggest what to do.

With kind regards,

--
Kris Heyrman.
Ottergemsesteenweg 337, B-9000 Gent.      Phone:  +32.9.221.79.69

"L'an 0. On arrète tout, puis on réflechit. Et c'est pas triste."



--------------90155280C43007E2EDBFDC70
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Okay, I think I need some help here, setting up a Dell Latitude CPt C333&nbsp;
to use a Ericson SH888 GSM phone to communicate, using the infrared port.
I must be doing something wrong, but cannot see what it is.
<p>I hope that somebody on this mailinglist will be able to help me, or
suggest further ways of exploration.
<p>If so, please accept my warm gratitude, and if not, please don't read
on because I think tales like the one below are commonplace.
<br>&nbsp;
<li>
I am using Red Hat 6.0.</li>

<br>&nbsp;
<li>
&nbsp;I was encouraged by <A HREF="http://rosebud.sps.queensu.ca/~edd/lcpt33.html">http://rosebud.sps.queensu.ca/~edd/lcpt33.html</A>
which said that the IrDA port had been successfully used on this type of
laptop.</li>

<br>&nbsp;
<li>
&nbsp;I checked that IrDA was enabled in the BIOS.</li>

<br>&nbsp;
<li>
I obtained the sources of Linux Kernel 2.2.13, and patched it with sony-patch.2.2.13
for sound,&nbsp; and patch-2.2.13-irda3 for IrCOMM. I also provided it
with pcmcia-cs-3.0.14 sources for card services</li>

<br>&nbsp; (with CardBus support, and using /etc/pcmcia/network from RedHat,
not from distribution of pcmcia-cs)
<br>&nbsp;
<li>
&nbsp;I installed irda-utils 0.9.4, most of which compiled correctly --
in fact, all of those which I think I need.</li>

<br>&nbsp;
<li>
&nbsp;In /etc/conf.modules I put</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; alias tty-ldisc-11 irtty</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; alias char-major-161 ircomm_tty</pre>
&nbsp; I saw that in many items of documentation it says
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; alias char-major-161 ircomm-tty</pre>
&nbsp; with a dash instead of an underscore, but doing that justs results
in a module not being found. I am curious about this, though, since the
dash comes up again in some mails I found on the Linux-IrDA mailing list.
<br>&nbsp;
<li>
I made devices:</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; crw-rw-rw-&nbsp;&nbsp; 1 root&nbsp;&nbsp;&nbsp;&nbsp; root&nbsp;&nbsp;&nbsp;&nbsp; 161,&nbsp;&nbsp; 0 Dec&nbsp; 7 09:32 /dev/ircomm0</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; crw-rw-rw-&nbsp;&nbsp; 1 root&nbsp;&nbsp;&nbsp;&nbsp; root&nbsp;&nbsp;&nbsp;&nbsp; 161,&nbsp;&nbsp; 1 Dec&nbsp; 7 09:32 /dev/ircomm1</pre>
&nbsp;
<li>
&nbsp;In the menu of my SH888, I 'activate the IR port'.</li>

<br>&nbsp;
<li>
I reboot and type</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # irmanager -s1 -d1</pre>
&nbsp; The system log shows
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:01:58 rennell irmanager: executing: '/sbin/modprobe irda'</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:01:59 rennell kernel: IrDA (tm) Protocols for Linux-2.2 (Dag B</pre>

<pre>rattli)</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:01:59 rennell irmanager: executing: 'echo 1 > /proc/sys/net/ir</pre>

<pre>da/discovery'</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:01:59 rennell irmanager: executing: 'echo rennell > /proc/sys/</pre>

<pre>net/irda/devname'</pre>
&nbsp;
<li>
Now, according to the documentation I found, I should</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # irattach /dev/ircomm0</pre>
&nbsp; Doing this shows
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.1 Fri Jul 25 11:45:26 1997 Dag Brattli</pre>
&nbsp; but the system log says:
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:04:58 rennell kernel: Linux-IrDA: IrCOMM protocol ( revision:T</pre>

<pre>ue May 18 03:11:39 1999 )</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:04:58 rennell kernel: ircomm_tty: virtual tty driver for IrCOM</pre>

<pre>M ( revision:Wed May 26 00:49:11 1999 )</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:04:58 rennell irattach: Failed to open /dev/ircomm0: No such d</pre>

<pre>evice</pre>
&nbsp;
<li>
Trying do exercise /dev/ircomm0 with 'kermit', 'cu -l /dev/ircomm0',</li>

<br>&nbsp; 'dip -t' and 'minicom' all fail.
<br>&nbsp;
<li>
On the other hand, the URL quoted above says one should 'irattach' with
/dev/ttyS2. I do not understand the logic of this, but I'll try.</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # irattach /dev/ttyS2</pre>
&nbsp; It responds
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.1 Fri Jul 25 11:45:26 1997 Dag Brattli</pre>
&nbsp; and syslog says
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:13:09 rennell irattach: Serial connection established.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:13:09 rennell kernel: IrDA: Registered device irda0</pre>
&nbsp; Aha!
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # more /proc/net/irda/discovery</pre>
&nbsp; says
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IrLMP: Discovery log:</pre>

<pre></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; name: SH 888, hint: 0x9104, saddr: 0xc6ec6dd0, daddr: 0x21192e89</pre>
&nbsp; and
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # irdaping 0x21192e89</pre>
&nbsp; says
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=0 time=110.39 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=2 time=110.43 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=3 time=110.44 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=5 time=108.71 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=6 time=108.32 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=8 time=114.54 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=9 time=114.26 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=11 time=110.44 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=12 time=110.43 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=14 time=110.44 ms.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32 bytes from 0x21192e89: irda_seq=15 time=110.44 ms.</pre>
&nbsp;&nbsp; A few lost packets there, but oh well.
<br>&nbsp;
<li>
Let's check the other files in /proc/net/irda:</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # head *</pre>
&nbsp;&nbsp; It says:
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ==> ircomm &lt;==</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; instance 0:</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unused</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ==> irda_device &lt;==</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; irda0,&nbsp; binding: irda0 &lt;-> ttyS2</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UP RUNNING SIR PIO</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bps&nbsp;&nbsp;&nbsp;&nbsp; maxtt&nbsp;&nbsp; dsize&nbsp;&nbsp; winsize addbofs mintt&nbsp;&nbsp; ldisc</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9600&nbsp;&nbsp;&nbsp; 50&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2048&nbsp;&nbsp;&nbsp; 7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5000&nbsp;&nbsp;&nbsp; 40</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ==> irias &lt;==</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LM-IAS Objects:</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; name: Device, id=21314</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Attribute name: "DeviceName", value[IAS_STRING]: "Linux"</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ==> irlap &lt;==</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; irlap0 &lt;-> irda0 state: LAP_NDM</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; caddr: 0x9c, saddr: 0xc6ec6dd0, daddr: 0x000000</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; win size: 0, win: 0, win bytes: 0, bytes left: 0</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tx queue len: 0 win queue len: 0 rbusy: FALSE</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; retrans: 0 vs: 0 vr: 0 va: 0</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; qos&nbsp;&nbsp; bps&nbsp;&nbsp;&nbsp;&nbsp; maxtt&nbsp;&nbsp; dsize&nbsp;&nbsp; winsize addbofs mintt&nbsp;&nbsp; ldisc&nbsp;&nbsp; comp</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tx&nbsp;&nbsp;&nbsp; 9600&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rx&nbsp;&nbsp;&nbsp; 9600&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ==> irlmp &lt;==</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Unconnected LSAPs:</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lsap state: LSAP_DISCONNECTED, slsap_sel: 0x0, dlsap_sel: 0xff, (IrIAS s</pre>

<pre>rv)</pre>

<pre></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Registred Link Layers:</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lap state: LAP_STANDBY, saddr: 0xc6ec6dd0, daddr: 0xffffffff,</pre>

<pre></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connected LSAPs:</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ==> irttp &lt;==</pre>

<pre></pre>

<li>
&nbsp;Why this should be so I do not know, but it looks OK:</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # ifconfig</pre>
&nbsp; has an entry:
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; irda0&nbsp;&nbsp;&nbsp;&nbsp; Link encap:UNSPEC&nbsp; HWaddr D0-6D-EC-C6-00-00-00-D9-00-00-00-00-</pre>

<pre>00-00-00-00</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UP RUNNING NOARP&nbsp; MTU:2048&nbsp; Metric:1</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RX packets:167 errors:0 dropped:0 overruns:0 frame:0</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TX packets:1109 errors:0 dropped:0 overruns:0 carrier:0</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; collisions:0 txqueuelen:8</pre>

<li>
Now:</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # dip -t</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ># dip -t</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIP: Dialup IP Protocol Driver version 3.3.7o-uri (8 Feb 96)</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Written by Fred N. van Kempen, MicroWalt Corporation.</pre>

<pre></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIP> port ttyS2</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #</pre>
&nbsp; It exits, and the sys log shows.
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dec 12 14:27:46 rennell dip[831]: DIP: tty: set_state: Invalid argument</pre>

<pre></pre>

<li>
Try:</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # cu -l /dev/ttyS2</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cu: Stale lock /var/lock/LCK..ttyS2 held by process 831 created 1999-12-</pre>

<pre>12 14:27:46</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cu: open (/dev/ttyS2): Permission denied</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cu: /dev/ttyS2: Line in use</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #</pre>
&nbsp;&nbsp; It also exits, there is nothing in sys log.
<br>&nbsp;
<li>
Try the venerable kermit:</li>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # kermit</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C-Kermit 5A(190), 4 Oct 94, for Linux</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Copyright (C) 1985, 1994,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Trustees of Columbia University in the City of New York.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type ? or HELP for help.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C-Kermit>set line /dev/ttyS2</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C-Kermit>connect</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connecting to /dev/ttyS2, speed 9600.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The escape character is Ctrl-\ (ASCII 28, FS)</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type the escape character followed by C to get back,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or followed by ? to see other options.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sorry, Can't condition communication line</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C-Kermit>quit</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #</pre>
&nbsp;&nbsp; It also exits, there is nothing in sys log.
<br>&nbsp;
<li>
Minicom also fails.</li>

<p><br>Also funny is the output from
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # lsmod</pre>
&nbsp; It says:
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Module&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Size&nbsp; Used by</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; irtty&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4636&nbsp;&nbsp; 2&nbsp; (autoclean)</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ircomm_tty&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 17604&nbsp;&nbsp; 0&nbsp; (autoclean) (unused)</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ircomm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 18040&nbsp;&nbsp; 0&nbsp; (autoclean) [ircomm_tty]</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; irda&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 135713&nbsp;&nbsp; 2&nbsp; [irtty ircomm_tty ircomm]</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nm256&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 64456&nbsp;&nbsp; 0&nbsp; (unused)</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sound&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 57228&nbsp;&nbsp; 0&nbsp; [nm256]</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; soundcore&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2372&nbsp;&nbsp; 6&nbsp; [sound]</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vmnet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11200&nbsp;&nbsp; 3</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vmppuser&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5216&nbsp;&nbsp; 0&nbsp; (unused)</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; parport_pc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5620&nbsp;&nbsp; 0&nbsp; [vmppuser]</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; parport&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 7124&nbsp;&nbsp; 0&nbsp; [vmppuser parport_pc]</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vmmon&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 15072&nbsp;&nbsp; 0&nbsp; (unused)</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nfsd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 150496&nbsp;&nbsp; 8&nbsp; (autoclean)</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3c575_cb&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 18792&nbsp;&nbsp; 2</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cb_enabler&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2104&nbsp;&nbsp; 2&nbsp; [3c575_cb]</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ds&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5740&nbsp;&nbsp; 2&nbsp; [cb_enabler]</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i82365&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 22640&nbsp;&nbsp; 2</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pcmcia_core&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 39912&nbsp;&nbsp; 0&nbsp; [cb_enabler ds i82365]</pre>
&nbsp; Why is ircomm_tty unused?
<p>If you have read up to here, maybe you can suggest what to do.
<p>With kind regards,
<pre>--&nbsp;
Kris Heyrman.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Ottergemsesteenweg 337, B-9000 Gent.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp; +32.9.221.79.69

"L'an 0. On arr&egrave;te tout, puis on r&eacute;flechit. Et c'est pas triste."</pre>
&nbsp;</html>

--------------90155280C43007E2EDBFDC70--





From wehe@snafu.de Sun, 12 Dec 1999 15:19:47 +0100
Date: Sun, 12 Dec 1999 15:19:47 +0100
From: Werner Heuser wehe@snafu.de
Subject: [Linux-IrDA]Interested in FIR (4Mbps) support for your laptop?

...
> This is a real chance of getting stable high performance FIR support for
> your laptop today, so if you are interested, then please send me a mail
> which tells if you would 1) definitively, 2) most probably or 3) maybe be
> buying such a card. They need to know how many units they should prepare
1) definitively

hopefully this solves the problem with my HP OmniBook 800
...

-werner-
-- 
Werner Heuser                       | Stop nuclear power now!       /~~
LiLAC - Linux with Laptop Computers |                              /~~~
Berlin, Germany                     |                             /~~~~
T. +49 30 349 53 86             http://www.snafu.de/~wehe/index_li.html





From voop@innocent.com Sun, 12 Dec 1999 10:46:08 -0700
Date: Sun, 12 Dec 1999 10:46:08 -0700
From: Thomas Heide Clausen voop@innocent.com
Subject: [Linux-IrDA]SH888 on Dell Latitude CPt C333: problem

<SNIP>

> * In /etc/conf.modules I put
> 
>         alias tty-ldisc-11 irtty
> 
>         alias char-major-161 ircomm_tty
> 
>   I saw that in many items of documentation it says
> 
>         alias char-major-161 ircomm-tty
> 
>   with a dash instead of an underscore, but doing that justs results in
> a module not being found. I am curious about this, though, since the
> dash comes up again in some mails I found on the Linux-IrDA mailing
> list.

Something about two versions of the IRCOMM-driver. Not sure why. I have this in
my conf.modules:
  
# IrDA
alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty

<SNIP>

<SNIP> 
>         # irattach /dev/ircomm0
> 

Drop using irmanager. Use the following:

irattach /dev/ttyS1 -s 1

That is: you need to ATTAC the IR to a TTY (namely the one, where the IR-port
presents itself. On my laptop, the IR-port is com2, hence the above works for
me. The -s 1 means "discovery on". Discovering the semantics of -s 0 are left as
an exercise to you :)

 
<SNIP> 
>         # cu -l /dev/ttyS2
> 

HERE you use /dev/ircomm0 instead. Then it will all be dandy :)

In short: Your IR-port lives as a "serial port" (sort of - has an UART and
stuff and presents itself as such). Using irattach, you tie that port to the
IrDA-code, and by accessing /dev/ircomm0, you will be able to communicate
through the IrDA-stack to the ttyS and into the "air" :)

Sent in private since 1) I am not an "official" IrDA-person and 2) the above is
slightly inaccurate however usefull for "the craftsman" who wants to get things
working.

Have fun - the SH888 works fine with my ThinkPad :)

 
-- 
Mange hilsner / Sincerely

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: T.Clausen@computer.org
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------




From dagb@cs.uit.no 12 Dec 1999 19:46:14 +0100
Date: 12 Dec 1999 19:46:14 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]SH888 on Dell Latitude CPt C333: problem

Thomas Heide Clausen <voop@innocent.com> writes:

> >   I saw that in many items of documentation it says
> > 
> >         alias char-major-161 ircomm-tty
> > 
> >   with a dash instead of an underscore, but doing that justs results in
> > a module not being found. I am curious about this, though, since the
> > dash comes up again in some mails I found on the Linux-IrDA mailing
> > list.
> 
> Something about two versions of the IRCOMM-driver. Not sure why. I have this in
> my conf.modules:

For some info, look at:

	http://www.cs.uit.no/linux-irda/hardware/phones/sh888.html

... and as the docs sais, the config might be changed again. This is
because ircomm is a "true" serial driver and may have to be changed to
/dev/ttyIR0 or something for 2.4. Not sure yet how this is going to end ;-)

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From martin@stronafian.freeserve.co.uk Sun, 12 Dec 1999 22:41:17 -0500
Date: Sun, 12 Dec 1999 22:41:17 -0500
From: Martin Ritchie martin@stronafian.freeserve.co.uk
Subject: [Linux-IrDA]Re: PPC Linux-IrDA

OK OK, I'm sorry for sounding so slow but I'm still learning all this Linux
stuff. I'm running Linux PPC Q3 on a rev A iMac. I have downloaded
irda_utils0.9.4 and tried to 'make' however my system didn't have alot of stuff
installed so after getting bin_utils2.9.5.0.14.-0a.ppc to get cpp-2.95.1-0a.ppc
and final gcc-2.95.1-0a.ppc installed  irda utils make still complains that
there is no such file or directory. Can anyone help. You also told me
previously that the bits need compiling into the Kernel. How do you do that??

Thanks
Martin




From mtepperis@pdv-online.de Mon, 13 Dec 1999 09:41:40 +0100
Date: Mon, 13 Dec 1999 09:41:40 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: [Linux-IrDA]SH888 on Dell Latitude CPt C333: problem

hi,

>Have fun - the SH888 works fine with my ThinkPad :)


what kind of thinkpad do you have?
Ì'm thinking about to buy a 240. do you know something about that?

have fun
 michael





From mtepperis@pdv-online.de Mon, 13 Dec 1999 10:06:23 +0100
Date: Mon, 13 Dec 1999 10:06:23 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: [Linux-IrDA]Linux-IRDA on PPC - getting better

hi

>> I've installed the latest IRDA patch for 2.2.13 and compiled the kernel
with
>> mostly good success on a LinuxPPC machine (Apple Powerbook G3
'wallsreet').
>I also installed into PowerBook G3 "Wallstreet".


here is also a PowerBook G3 "Wallstreet" running.

I tried to compile the kernel 2.2.13 (non-patched) with IrDa support too but
if I do
  make menuconfig
there is no IrDA option at all.

is the patch necessary or do I have to set special options?

if I do the same on a x86 desktop with the same kernel source
the IrDA option is in the main menu.

have fun
 michael






From dagb@cs.uit.no 13 Dec 1999 10:11:32 +0100
Date: 13 Dec 1999 10:11:32 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Linux-IRDA on PPC - getting better

"Michael Tepperis" <mtepperis@pdv-online.de> writes:


> here is also a PowerBook G3 "Wallstreet" running.
> 
> I tried to compile the kernel 2.2.13 (non-patched) with IrDa support too but
> if I do
>   make menuconfig
> there is no IrDA option at all.
> 
> is the patch necessary or do I have to set special options?
> 
> if I do the same on a x86 desktop with the same kernel source
> the IrDA option is in the main menu.

You need to patch your arch/ppc/config.in:

fi

source net/ax25/Config.in

+source net/irda/Config.in

mainmenu_option next_comment
comment 'ISDN subsystem'
i 

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From thomas.clausen@inria.fr Mon, 13 Dec 1999 10:17:14 -0700
Date: Mon, 13 Dec 1999 10:17:14 -0700
From: Thomas Heide Clausen thomas.clausen@inria.fr
Subject: [Linux-IrDA]SH888 on Dell Latitude CPt C333: problem

On Mon, 13 Dec 1999, Michael Tepperis wrote:
> hi,
> 
> >Have fun - the SH888 works fine with my ThinkPad :)
> 
> 
> what kind of thinkpad do you have?
> Ì'm thinking about to buy a 240. do you know something about that?

Not a thing. I've been around the ThinkPad 560 and 390 without any
problems. But not the 240, sorry.


-- 
------------------------------------------------
Thomas Heide Clausen 
Civilingenioer i Datateknik (cand.polyt),
M.Sc. in Computer Engineering
Email: T.Clausen@computer.org
WWW:   http://www.cs.auc.dk/~voop
------------------------------------------------




From mtepperis@pdv-online.de Mon, 13 Dec 1999 10:47:26 +0100
Date: Mon, 13 Dec 1999 10:47:26 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: [Linux-IrDA]irda tests

hi,

on the weekend I do some tests with the following environment:
kernel-2.2.12
kernel-2.2.13
desktop x86 with a JetEye dongle attached to /dev/ttyS1
motorola L 7089 mobile phone
kodak dc 210+ digital camera
apple powerbook g3 'wallstreet' laptop

1. kernel-2.2.12

desktop <-> phone
tested with minicom:
that is a litle bit tricky, in cause of the order to do the single steps,
but worked

desktop <-> camera
tested with gphoto:
VERY slow, but worked

desktop <-> laptop(running mac os 8.5)
the laptop is recognized by the desktop but the laptop says that there is no
recognized peer


2. kernel-2.2.13

desktop <-> phone
tested with minicom:
most tests worked well, I have to do more, currently
I only have a manual from siemens about modem commands
for gsm communication. some commands give me not the
expected results. but this will be the most interesting
parts with the IrDA stuff.

desktop <-> camera
tested with gphoto:
speed seems to be the same like working with a cable
connected serial port

desktop <-> laptop(running mac os 8.5)
same as for kernel-2.2.12
the laptop is recognized by the desktop but the laptop
says that there is no recognized peer


3. linux on the laptop

failed (see other message)
sorry, but I am new in compiling & installing kernels for ppc.

but I'll give it more tries to do the following tests

laptop <-> phone
laptop <-> camera
laptop <-> desktop


4. Printer HP 2100TN

tests will be done with the IrDA stuff running on the laptop.


have fun
  Michael






From eugenio@convex.es Mon, 13 Dec 1999 11:05:08 +0100
Date: Mon, 13 Dec 1999 11:05:08 +0100
From: Eugenio Huertas =?iso-8859-1?Q?Tal=F3n?= eugenio@convex.es
Subject: [Linux-IrDA]Interested in FIR (4Mbps) support for your laptop?

Hi Dag,

I'll be interested on such PCMCIA card. So, my answer is "2".

Thanks for your work
Eugenio

....
Dag Brattli wrote:

> Hi,
>
> I just want to make a quick poll on the list to find out if you would be
> interested in getting yourself a FIR (4Mbps) IrDA PCMCIA card. This card is
> a must for all of you that wants FIR support for your Linux laptop now, and
> don't want to wait for somebody to write a driver for your builtin FIR port
> (or if your laptop don't support FIR). The company which produces the card
> wants to know if there are any interests for it in the Linux community.
>
>         Visit http://www.irdatacorp.com/ for more info
>
> The card contains an IBM 31T1502 chipset which uses shared memory to
> transfer data between the card and the laptop. This makes it much more
> reliable than ISA DMA transfers which suffers badly when you have disk
> activity at the same time (downloading large files from the web).
>
> The Linux driver were in fact written half a year ago (by myself) and is
> stable. This card is also very fast, and I have measured FTP speeds of over
> 340 Kbytes/s (IrLAN). So now you know where I got those high speeds from
> ;-) I'm pretty sure you will never get the same performance out of any ISA
> based FIR solution (which most laptops today use). And getting drivers for
> all laptops will take uncountable number of hours to impl, debug, test, etc
> anyway.
>
> This is a real chance of getting stable high performance FIR support for
> your laptop today, so if you are interested, then please send me a mail
> which tells if you would 1) definitively, 2) most probably or 3) maybe be
> buying such a card. They need to know how many units they should prepare
> for Linux users, so I'll make a list and ship it over to them in a week or
> so. Remember that this is just a poll to check the interest. You don't
> commit to anything!
>
> -- Dag
>
> --
>    / Dag Brattli                   | The Linux-IrDA Project               /
>   // University of Tromsoe, Norway | Infrared communication for Linux    //
>  /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///
>
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda





From joth@bigfoot.com Mon, 13 Dec 1999 12:43:57 -0000
Date: Mon, 13 Dec 1999 12:43:57 -0000
From: Jonathan Dixon joth@bigfoot.com
Subject: [Linux-IrDA]WinCE and IrCOMM problems

Hi

"CLIENT" is part of the Microsoft server chat script, required to get a ppp
connection up and running to NT RAS. i.e. it's well above the IrCOMM level,
so fortunately they're not doing any proprietary extensions there ;-)

The following is the WinCE-equivalent script used in my Psion 5:

! Generic script for direct cable connections
! Suitable for NT RAS as supplied
start:
LOOP 3
	{
	SEND "CLIENT"+<0x0d>
	WAIT 10
		{
		"SERVER" success
		}
	}
	EXIT KErrTimeOut$

success:
	EXIT

So basically, rather the hack pppd, all that is necessary is to use a simple
connect script to interface to this (assuming WinCE doesn't require anything
extra). e.g. something along the lines of:
> pppd ircomm0 115200 connect '/usr/sbin/chat "CLIENT" "SERVER"' ...

should do the trick. The (questionable?) benefit of this is that is makes
the linux machine look like an NT RAS server to any device configured to use
NT RAS (psion, palm, win95...?), not just WinCE devices.


Cheers

Joth


> -----Original Message-----
> From: linux-irda-admin@PASTA.cs.uit.no
> [mailto:linux-irda-admin@PASTA.cs.uit.no]On Behalf Of Jon Burford
> Sent: 10 December 1999 21:08
> To: linux-irda@pasta.cs.UiT.No
> Subject: Re: [Linux-IrDA]WinCE and IrCOMM problems
>
>
> Yes, I have come accross this problem as well when trying to make an
> IrCOMM/PPP connection with a WinCE device.  To get around it, you need to
> manually start the connection.  Essentially you start by running
> a getty on
> /dev/ircomm, making a serial console connection to the linux box (from CE
> using "Make a connection as a Hayes Modem) and then when you get a login
> prompt on the WinCE side, fire off PPP on the linux box on the
> IrCOMM link.
> This page helped me start an IrCOMM/PPP connection between a
> Linux and WinCE
> device:
>
> http://www.the-gadgeteer.com/linux_ce.html
>
> Good luck and let me know if you have any questions!  I am also very
> interested in making this automated but haven't had time to come
> back to the
> problem (our customers are all Palm users so I didn't much care).  I was
> thinking that you might have to write a special WinCE app to make
> the thing
> not do the funky CLIENT crap, but I actually think this is part of MS-CHAP
> which is not supported by the Linux PPP SERVER (it is supported if you use
> pppd to connect TO a MS-CHAP server).  So, even if you use the WinCE PPP
> API, you still probably can't disable MS-CHAP.  The obviously better
> approach is to either hack or correctly add support for MS-CHAP
> in the Linux
> pppd.  This wasn't supported as of a few weeks ago in Linux pppd, but the
> pppd guys knew about it and were thinking about adding it.
>
> Regards,
> Jon
>
> ----- Original Message -----
> From: Dag Brattli <dagb@cs.uit.no>
> To: <linux-irda@pasta.cs.UiT.No>
> Sent: Friday, December 10, 1999 12:37 PM
> Subject: [Linux-IrDA]WinCE and IrCOMM problems
>
>
> > Hi,
> >
> > IrCOMM for Linux now works with most devices except WinCE. When WinCE
> > connects to Linux, it doesn't ask for IrDA:IrCOMM:Parameters or send any
> > initial parameters (as IrCOMM sais you should do). All it says
> is "CLIENT"
> > a couple of times before it disconnects. This smells like proprietary
> > stuff, so I'm a bit clueless! Anybody that can give me some hints.
> >
> > PS. We really need to make irdadump follow speed changes!
> >
> > -- Dag
> >
> > --
> >    / Dag Brattli                   | The Linux-IrDA Project
> /
> >   // University of Tromsoe, Norway | Infrared communication for Linux
> //
> >  /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/
> ///
> >
> > 20:28:13.355562 snrm:cmd ca=fe pf=1 c677866c < 00001401 new-ca=24 (32)
> > ff93011400006c8677c62401012682010183013f84010f850180860102080107
> > . . . . . . l . w . $ . . & . . . . . ? . . . . . . . . . . . .
> > 20:28:13.356383 ua:rsp ca=24 pf=1 c677866c > 00001401 (31)
> > 24736c8677c60114000001012682010183013f84017f8501ff860101080107
> > $ s l . w . . . . . . . & . . . . . ? . . . . . . . . . . . .
> > 20:28:13.533295 rr:cmd < ca=24 pf=1 nr=0 (2)
> > 2511
> > % .
> > 20:28:13.533556 rr:rsp > ca=24 pf=1 nr=0 (2)
> > 2411
> > $ .
> > 20:28:13.575205 i:cmd  < ca=24 pf=1 nr=0 ns=0 LM slsap=03 dlsap=00
> CONN_CMD (6) 251080030100
> > % . . . . .
> > 20:28:13.575565 i:rsp  > ca=24 pf=1 nr=1 ns=0 LM slsap=00 dlsap=03
> CONN_RSP (6) 243083008100
> > $ 0 . . . .
> > 20:28:13.613355 i:cmd  < ca=24 pf=1 nr=1 ns=1 LM slsap=03 dlsap=00
> GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "IrDA:TinyTP:LsapSel" (37)
> > 25320003840b497244413a4972434f4d4d13497244413a54696e7954503a4c73
> > % 2 . . . . I r D A : I r C O M M . I r D A : T i n y T P : L s
> > 20:28:13.614225 i:rsp  > ca=24 pf=1 nr=2 ns=1 LM slsap=00 dlsap=03
> GET_VALUE_BY_CLASS: Success Integer: 1f (15)
> > 24520300840000012343010000001f
> > $ R . . . . . . # C . . . . .
> > 20:28:13.653318 i:cmd  < ca=24 pf=1 nr=2 ns=2 LM slsap=03 dlsap=00 DISC
> (6)
> > 255480030201
> > % T . . . .
> > 20:28:13.653649 rr:rsp > ca=24 pf=1 nr=3 (2)
> > 2471
> > $ q
> > 20:28:13.693358 i:cmd  < ca=24 pf=1 nr=2 ns=3 LM slsap=02 dlsap=1f
> CONN_CMD TTP credits=0(7)
> > 25569f02010004
> > % V . . . . .
> > 20:28:13.693726 i:rsp  > ca=24 pf=1 nr=4 ns=2 LM slsap=1f dlsap=02
> CONN_RSP TTP credits=0(7)
> > 2494821f81000e
> > $ . . . . . .
> > 20:28:13.733274 rr:cmd < ca=24 pf=1 nr=3 (2)
> > 2571
> > % q
> > 20:28:13.733505 rr:rsp > ca=24 pf=1 nr=4 (2)
> > 2491
> > $ .
> > 20:28:13.773313 i:cmd  < ca=24 pf=0 nr=3 ns=4 LM slsap=02 dlsap=1f TTP
> credits=0 (12)
> > 25681f020000434c49454e54
> > % h . . . . C L I E N T
> >
> > _______________________________________________
> > Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> > http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
>
>
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
>





From jburford@xsilogy.com Mon, 13 Dec 1999 11:29:39 -0800
Date: Mon, 13 Dec 1999 11:29:39 -0800
From: Jon Burford jburford@xsilogy.com
Subject: [Linux-IrDA]Interested in FIR (4Mbps) support for your laptop?

I would be in category 1 if the price was right, 2 if it was a little steep
;-).  And thank you for that special patch, I am in the process of patching
and compiling now.

Regards,
Jon


----- Original Message -----
From: Dag Brattli <dagb@cs.uit.no>
To: <linux-irda@pasta.cs.UiT.No>
Sent: Sunday, December 12, 1999 2:45 AM
Subject: [Linux-IrDA]Interested in FIR (4Mbps) support for your laptop?


> Hi,
>
> I just want to make a quick poll on the list to find out if you would be
> interested in getting yourself a FIR (4Mbps) IrDA PCMCIA card. This card
is
> a must for all of you that wants FIR support for your Linux laptop now,
and
> don't want to wait for somebody to write a driver for your builtin FIR
port
> (or if your laptop don't support FIR). The company which produces the card
> wants to know if there are any interests for it in the Linux community.
>
> Visit http://www.irdatacorp.com/ for more info
>
> The card contains an IBM 31T1502 chipset which uses shared memory to
> transfer data between the card and the laptop. This makes it much more
> reliable than ISA DMA transfers which suffers badly when you have disk
> activity at the same time (downloading large files from the web).
>
> The Linux driver were in fact written half a year ago (by myself) and is
> stable. This card is also very fast, and I have measured FTP speeds of
over
> 340 Kbytes/s (IrLAN). So now you know where I got those high speeds from
> ;-) I'm pretty sure you will never get the same performance out of any ISA
> based FIR solution (which most laptops today use). And getting drivers for
> all laptops will take uncountable number of hours to impl, debug, test,
etc
> anyway.
>
> This is a real chance of getting stable high performance FIR support for
> your laptop today, so if you are interested, then please send me a mail
> which tells if you would 1) definitively, 2) most probably or 3) maybe be
> buying such a card. They need to know how many units they should prepare
> for Linux users, so I'll make a list and ship it over to them in a week or
> so. Remember that this is just a poll to check the interest. You don't
> commit to anything!
>
> -- Dag
>
> --
>    / Dag Brattli                   | The Linux-IrDA Project
/
>   // University of Tromsoe, Norway | Infrared communication for Linux
//
>  /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/
///
>
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda





From kh@club.innet.be Mon, 13 Dec 1999 22:41:26 +0100
Date: Mon, 13 Dec 1999 22:41:26 +0100
From: Kris Heyrman kh@club.innet.be
Subject: [Linux-IrDA]SH888 on Dell Latitude CPt C333: problem

Thomas Heide Clausen wrote:

> Drop using irmanager. Use the following:
>
> irattach /dev/ttyS1 -s 1
>
> That is: you need to attach the IR to a TTY (namely the one, where the IR-port
> presents itself. On my laptop, the IR-port is com2, hence the above works for me.
> The -s 1 means "discovery on". Discovering the semantics of -s 0 are left as an
> exercise to you :)
>
> >         # cu -l /dev/ttyS2
>
> HERE you use /dev/ircomm0 instead. Then it will all be dandy :)
>
> In short: Your IR-port lives as a "serial port" (sort of - has an UART and stuff
> and presents itself as such). Using irattach, you tie that port to the IrDA-code,
> and by accessing /dev/ircomm0, you will be able to communicate through the
> IrDA-stack to the ttyS and into the "air" :)
>
> Sent in private since 1) I am not an "official" IrDA-person and 2) the above is
> slightly inaccurate however useful for "the craftsman" who wants to get things
> working.
>
> Have fun - the SH888 works fine with my ThinkPad :)

Hi Thomas,

Thanks very much for the speedy and knowledgeable response -- now I know at least
what I am trying to do. Still, there is something else going on.

I got irda-utils 0.9.5 instead of 0.9.4 (which has not got the -s 1 option to
irattach), and typed after reboot:

# irattach /dev/ttyS2 -s 1

1.1 Tue Nov  9 15:30:55 1999 Dag Brattli

The sys log shows:

Dec 13 22:49:12 rennell irattach: Serial connection established.

Dec 13 22:49:12 rennell kernel: IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)

Dec 13 22:49:12 rennell kernel: IrDA: Registered device irda0

Dec 13 22:49:12 rennell kernel: irmanager is not running!

Dec 13 22:49:13 rennell irattach: executing: 'echo 1 > /proc/sys/net/irda/discov

ery'

Dec 13 22:49:13 rennell irattach: executing: 'echo rennell > /proc/sys/net/irda/

devname'

Dec 13 22:49:13 rennell irattach: Unable to get name of device!

Dec 13 22:49:13 rennell irattach: Using device:

Dec 13 22:49:13 rennell modprobe: can't locate module

# more /etc/conf.modules

alias parport_lowlevel parport_pc

alias tty-ldisc-11 irtty

alias char-major-161 ircomm_tty

pre-install pcmcia_core /etc/rc.d/init.d/pcmcia start

keep

path[pcmcia]=/lib/modules/default

path[pcmcia]=/lib/modules/preferred

# more /proc/net/irda/discovery

IrLMP: Discovery log:

name: SH 888, hint: 0x9104, saddr: 0xe0380cee, daddr: 0x75138e09

[root@rennell /root]# lsmod

Module                  Size  Used by

irtty                   4636   2  (autoclean)

irda                  135713   1  (autoclean) [irtty]

nm256                  64456   0  (unused)

sound                  57228   0  [nm256]

soundcore               2372   6  [sound]

vmnet                  11200   3

vmppuser                5216   0  (unused)

parport_pc              5620   0  [vmppuser]

parport                 7124   0  [vmppuser parport_pc]

vmmon                  15072   0  (unused)

nfsd                  150496   8  (autoclean)

3c575_cb               18792   2

cb_enabler              2104   2  [3c575_cb]

ds                      5740   2  [cb_enabler]

i82365                 22640   2

pcmcia_core            39912   0  [cb_enabler ds i82365]

Ifconfig has:

irda0     Link encap:UNSPEC  HWaddr EE-0C-38-E0-00-00-00-D9-00-00-00-00-00-00-00

-00

          UP RUNNING NOARP  MTU:2048  Metric:1

          RX packets:183 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1281 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:8

What screws me is apparently  this system call in irattach.c:

 /* Start the network interface */

        if (ioctl(fd, IRTTY_IOCGNAME, &info) < 0) {

                syslog(LOG_ERR, "Unable to get name of device!\n");

        }

Any more ideas are welcome to me. Would it be worth it to patch my kernel to a
higher level than patch 2.2.13-irda3?   In which way to attack kernel debugging?

Kind regards and thanks for the help.

--
Kris Heyrman.
Ottergemsesteenweg 337, B-9000 Gent.      Phone:  +32.9.221.79.69

"L'an 0. On arrète tout, puis on réflechit. Et c'est pas triste."







From rtsteinh@wpax13.physik.uni-wuerzburg.de Tue, 14 Dec 1999 00:44:09 +0100 (MET)
Date: Tue, 14 Dec 1999 00:44:09 +0100 (MET)
From: Robert Steinhaeusser rtsteinh@wpax13.physik.uni-wuerzburg.de
Subject: [Linux-IrDA]Interested in FIR (4Mbps) support for your laptop?

On 12 Dec 1999, Dag Brattli wrote:

> (...) This card is
> a must for all of you that wants FIR support for your Linux laptop now, and
> don't want to wait for somebody to write a driver for your builtin FIR port
> (or if your laptop don't support FIR).

Well, thanks to the Linux-IrDA page I found out that my Toshiba Satellite
Pro 440CDX has a Sharp UIRCC. It also says that FIR mode currently does 
not work, so I could use IrTTY instead. Perhaps this is the reason why
the UIRCC driver has been removed? Or have I missed something very
significant on the mailing list?

The Laptop-BIOS doesn't offer any setup. Booting Linux doesn't show
anything but ttyS0, which is the "real" serial port. Win98-Config gives me
some information, e.g. IRQ 10, which in Linux is used by the PCMCIA
stuff. So I haven't got _anything_ working yet. Perhaps somebody on the
list has an idea, esp. the person who submitted the information to the
homepage?

> This is a real chance of getting stable high performance FIR support for
> your laptop today, so if you are interested, then please send me a mail
> which tells if you would 1) definitively, 2) most probably or 3) maybe be
> buying such a card.

I am interested in getting something working here. So I'd say "2", if the
other stuff continues not to work and the PCMCIA-card is available here in
Germany.

Bye, Rob
-- 
Robert Steinhaeusser, DL1NC/N9KBK

Was "DL1NC" heisst? Alles ueber Amateurfunk auf
       http://www.wuerzburg.de/darc-b17/





From stuge@cdy.org Tue, 14 Dec 1999 18:05:39 +0100 (CET)
Date: Tue, 14 Dec 1999 18:05:39 +0100 (CET)
From: Peter Stuge stuge@cdy.org
Subject: [Linux-IrDA]WinCE and IrCOMM problems

On Mon, 13 Dec 1999, Jonathan Dixon wrote:

>"CLIENT" is part of the Microsoft server chat script, required to get a ppp
>connection up and running to NT RAS. i.e. it's well above the IrCOMM level,
>so fortunately they're not doing any proprietary extensions there ;-)
>
>The following is the WinCE-equivalent script used in my Psion 5:
>
>! Generic script for direct cable connections
>! Suitable for NT RAS as supplied
>start:
>LOOP 3
>	{
>	SEND "CLIENT"+<0x0d>
>	WAIT 10
>		{
>		"SERVER" success
>		}
>	}
>	EXIT KErrTimeOut$
>
>success:
>	EXIT
>
>So basically, rather the hack pppd, all that is necessary is to use a simple
>connect script to interface to this (assuming WinCE doesn't require anything
>extra). e.g. something along the lines of:
>> pppd ircomm0 115200 connect '/usr/sbin/chat "CLIENT" "SERVER"' ...

Actually,
pppd ircomm0 115200 connect "/usr/sbin/chat '' CLIENT SERVER ''"
seems more likely to work to me.  (Just sticking my nose where it doesn't
belong. :)

//Peter

--
irc: CareBear\    tel: +46-40-914420
irl: Peter Stuge  gsm: +46-705-783805





From joth@bigfoot.com Tue, 14 Dec 1999 17:28:01 -0000
Date: Tue, 14 Dec 1999 17:28:01 -0000
From: Jonathan Dixon joth@bigfoot.com
Subject: [Linux-IrDA]WinCE and IrCOMM problems

> >> pppd ircomm0 115200 connect '/usr/sbin/chat "CLIENT" "SERVER"' ...
>
> Actually,
> pppd ircomm0 115200 connect "/usr/sbin/chat '' CLIENT SERVER ''"
> seems more likely to work to me.  (Just sticking my nose where it doesn't
> belong. :)
>
> //Peter
> ...


Sorry, I wasn't very clear.

We're pretending to be the server (as opposed to my quoted Psion script,
which was playing the role of client). So the algorithm we want is...
 * Wait for "CLIENT" from the WinCE device.
 * Send "SERVER".
>> Presto! We're connected! Start doing pppd stuff! <<

Hence my guess at the script. Of course, if we were playing the role of
client (say, on a Linux notebook connecting to a NT RAS machine) we'd want
to use your script.


Cheers,
Joth





From rene.harsch@ubs.com Wed, 15 Dec 1999 11:55:07 +0100
Date: Wed, 15 Dec 1999 11:55:07 +0100
From: rene.harsch@ubs.com rene.harsch@ubs.com
Subject: [Linux-IrDA]Help with Thinkpad 600E & Siemens S25

Hi to everyone

Well, I'm new to this maillinglist. I really need some hints from the 
IRDA-Profis,
cause I didn't get my IRDA  working  resp. the wierd thing is, that 
somethimes it works fine
(specially in the train :-). Well 1 out of 40 times it works, that 
means I can see
my cellular phone (Siemens S25) in /proc/net/irda/discovery.
I re-read the mailing-list archives an the ir-howto more than 100 times (ok 30)
and really need helps. PLEEEEASE !!!

Well my hardware: IBM Thinkpad 600E
Siemens S25

System:
kernel 2.2.13 / highly patched
irda-utils 0.9.5
enlightenment (no sound in the kernel, no esd)

depmod -a ==> works fine

Devices should be correct (I guess :-)
root@Fanny:~ > ls -l /dev/ir*
crw-r--r--   1 root     root     161,   0 Dec 14 14:40 /dev/ircomm0
crw-r--r--   1 root     root     161,   1 Dec 14 14:40 /dev/ircomm1


after a irmanager -d 1 (in devices irattach /dev/ttyS1) messages in
/var/log/messages

Dec 15 11:58:21 Fanny 1.1 Tue Nov  9 15:30:55 1999 Dag Brattli
Dec 15 11:59:05 Fanny irmanager: executing: '/sbin/modprobe irda'
Dec 15 11:59:05 Fanny kernel: IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Dec 15 11:59:05 Fanny irmanager: executing: 'echo 1 > 
/proc/sys/net/irda/discovery'
Dec 15 11:59:06 Fanny irmanager: executing: 'echo Fanny > 
/proc/sys/net/irda/devname'
Dec 15 11:59:10 Fanny irmanager: + 1.1 Tue Nov  9 15:30:55 1999 Dag Brattli
Dec 15 11:59:10 Fanny kernel: IrDA: Registered device irda0
Dec 15 11:59:10 Fanny irmanager: + 1.1 Tue Nov  9 15:30:55 1999 Dag Brattli
Dec 15 11:59:10 Fanny irattach: Serial connection established.
Dec 15 11:59:11 Fanny irattach: executing: 'echo Fanny > 
/proc/sys/net/irda/devname'
Dec 15 11:59:11 Fanny irattach: Using device: irda0
Dec 15 11:59:11 Fanny kernel: irtty_net_open()
Dec 15 11:59:11 Fanny kernel: irlap_change_speed(), setting speed to 9600

(tail /etc/conf.modules)
alias tty-ldisc-11        irtty
alias char-major-161      ircomm-tty

root@Fanny:~ > cat /proc/net/irda/irlap
irlap0 state: LAP_NDM
  caddr: 0x20, saddr: 0x46a7c013, daddr: 0x000000
  win size: 0, win: 0, line capacity: 0, bytes left: 0
  tx queue len: 0 win queue len: 0 rbusy: FALSE mbusy: FALSE
  retrans: 0 vs: 0 vr: 0 va: 0
  qos   bps     maxtt   dsize   winsize addbofs mintt   ldisc   comp
  tx    9600    0       64      1       11      0       0       0
  rx    9600    0       64      1       11      0       0       0

root@Fanny:~ > cat /proc/net/irda/irlmp
Unconnected LSAPs:
lsap state: LSAP_DISCONNECTED, slsap_sel: 0x0, dlsap_sel: 0xff, (IrIAS srv)

Registred Link Layers:
lap state: LAP_STANDBY, saddr: 0x46a7c013, daddr: 0xffffffff,

Connected LSAPs:

root@Fanny:~ > cat /proc/net/irda/discovery
IrLMP: Discovery log:


root@Fanny:~ > lsmod
Module                  Size  Used by
irtty                   7132   2  (autoclean)
irda                  139873   2  [irtty]

/proc/sys/net/irda/discovery == 1

I have tried much other configs for discovery/discovery_slots/slot_timeout
Well, thats it.
Thanks to all for reading ....

Rene





From clock@atrey.karlin.mff.cuni.cz Wed, 15 Dec 1999 18:33:52 +0100
Date: Wed, 15 Dec 1999 18:33:52 +0100
From: Karel Kulhavy clock@atrey.karlin.mff.cuni.cz
Subject: [Linux-IrDA]IR wireless LAN for 300m

Hi

I'm privately (as a ham and as a fan) developping a IR communicator intended
to work for 250m and more and transfer data packets peer-to-peer at rates
at least 1Mbit and to interconnect Linux machines (primarily). It is strongly
optimized to be low-cost and to be available to every ham who has got
a soldering iron at home and few coins in the pocket.

I'm currently at a stage where at half-optics (receiver with optics, transmitter
bare diode) I got 22.5 dBSNR @2MHz carrier in band 100kHz...2MHz and
10m distance.

I have heard that IrDA is not capable of sending full-duplex. My channel is
full-duplex (four separate simple optics heads) so it would be a great
pity to lose half of the precious bandwidth.

Is there any possibility to force IrDA chips to work full-duplex?

If not, how well would Linux communicate half-duplex?

Or is there any possibility (V.35 or others?) to encode the bits at reasonably
low costs?

Best regards,

Karel Kulhavy





From erc@khijol.org Wed, 15 Dec 1999 11:45:18 -0600 (EST)
Date: Wed, 15 Dec 1999 11:45:18 -0600 (EST)
From: Ed Carp erc@khijol.org
Subject: [Linux-IrDA]IR wireless LAN for 300m

On Wed, 15 Dec 1999, Karel Kulhavy wrote:

> I'm privately (as a ham and as a fan) developping a IR communicator intended
> to work for 250m and more and transfer data packets peer-to-peer at rates
> at least 1Mbit and to interconnect Linux machines (primarily). It is strongly
> optimized to be low-cost and to be available to every ham who has got
> a soldering iron at home and few coins in the pocket.

If this is intended for hams, then why are you using IR?  There is no
license required to use IR.
-- 
Ed Carp, N7EKG  	erc@pobox.com		940/367-2744 cell phone

Visit http://www.linux-usa.net - Plug-n-Go Linux servers for small business
                                 "Plug it in - Turn it on - You're Done!"





From clock@atrey.karlin.mff.cuni.cz Wed, 15 Dec 1999 19:15:23 +0100
Date: Wed, 15 Dec 1999 19:15:23 +0100
From: Karel Kulhavy clock@atrey.karlin.mff.cuni.cz
Subject: [Linux-IrDA]IR wireless LAN for 300m

> On Wed, 15 Dec 1999, Karel Kulhavy wrote:
> 
> > I'm privately (as a ham and as a fan) developping a IR communicator intended
> > to work for 250m and more and transfer data packets peer-to-peer at rates
> > at least 1Mbit and to interconnect Linux machines (primarily). It is strongly
> > optimized to be low-cost and to be available to every ham who has got
> > a soldering iron at home and few coins in the pocket.
> 
> If this is intended for hams, then why are you using IR?  There is no
> license required to use IR.

That's the point!

Maybe I'm using a bad word -- I meant someone who wants to communicate at
low cost by the word ham.

Karel Kulhavy




From dagb@cs.uit.no 15 Dec 1999 22:44:01 +0100
Date: 15 Dec 1999 22:44:01 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]IR wireless LAN for 300m

Karel Kulhavy <clock@atrey.karlin.mff.cuni.cz> writes:

> I have heard that IrDA is not capable of sending full-duplex. My channel is
> full-duplex (four separate simple optics heads) so it would be a great
> pity to lose half of the precious bandwidth.
> 
> Is there any possibility to force IrDA chips to work full-duplex?

Yes, most of them can do that, but the problem is that the transmitter is
placed so close to the receiver, that it "blinds" it by its own
transmission. That makes the receiver less sensitive and can even make it
recieve the nodes own transmissions. So in most chips, you can set a bit
that makes it turn off the receiver while it's transmitting. IrDA devices
negotiate whats called the minimum turn around time which is the time the
receiver needs to get its sensitivity back after being blinded by the
transmitter. I don't think it would help to separate the transmitting and
receiving diode for such row range communication, since the signal will
bounce back from the peer device (or other objects) anyway.
 
> If not, how well would Linux communicate half-duplex?

All IrDA devices are half duplex, and this is controlled by the IrLAP
protocol. This is a primary/secondary protocol where a "token" called the
pf (poll/final) bit is used to give the other station permission to
"speak". The pf bit is controlled by the primary, but the secondary can
give it back, before it's time has "expired". This means that the protocol
need not to be symmtric, and you can have a situation where the primary
sends 7 frames in a row (the last frame gives away the token) and the
secondary gives the token immediately back if it hasn't anything to send
itself. In such a scenario you will feel like you get all the bandwidth out 
of the link.

So you can get very good transmission speed if you are doing asymmetric
communication (and most Internet communication is asymmetric). If you have
two FTP transfers in different directions at the same time, then you will
notice that the transfer speed is suddenly less than half of the link speed
:-(

When using a 4Mbps half duplex link, I have measured FTP transfer speeds
above 340 Kbytes/s (asymmetric of course).

So forcing IrDA chips to be full duplex will not help much if you use the
IrLAP protocol. IrDA was designed for short range ad-hoc communication.

For longer range, more permanent. and full duplex operation you will need
to use a different (and much simpler) link protocol to get the performance
you want. Running TCP/IP over PPP would probably do the job if the frame
loss rate is low (less than 10% ?). If your link is worse than this, then
you will need a link layer than can do some retransmissions for you.

Not my strongest area, but I hope it might help you.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From clock@atrey.karlin.mff.cuni.cz Thu, 16 Dec 1999 10:40:15 +0100
Date: Thu, 16 Dec 1999 10:40:15 +0100
From: Karel Kulhavy clock@atrey.karlin.mff.cuni.cz
Subject: [Linux-IrDA]Re: IR wireless LAN for 300m

> Karel Kulhavy <clock@atrey.karlin.mff.cuni.cz> writes:
> 
> > I have heard that IrDA is not capable of sending full-duplex. My channel is
> > full-duplex (four separate simple optics heads) so it would be a great
> > pity to lose half of the precious bandwidth.
> > 
> > Is there any possibility to force IrDA chips to work full-duplex?
> 
> Yes, most of them can do that, but the problem is that the transmitter is
> placed so close to the receiver, that it "blinds" it by its own
> transmission. That makes the receiver less sensitive and can even make it
> recieve the nodes own transmissions. So in most chips, you can set a bit
> that makes it turn off the receiver while it's transmitting. IrDA devices
> negotiate whats called the minimum turn around time which is the time the
> receiver needs to get its sensitivity back after being blinded by the
> transmitter. I don't think it would help to separate the transmitting and
> receiving diode for such row range communication, since the signal will
> bounce back from the peer device (or other objects) anyway.

My optics is relatively well focused -- the beam has only about 1 degree
divergence angle and there are no obstacles in the path -- it's through free
air.  I am also able to place the two tubes about one meter away fro each other
to prevent crosstalks. Do you think that in this case atmospheric dispersion
would make full duplex unavailable?

Which analog-to-digital chip (without optic diodes) and which packet chip would
you recommend as being widely available and reasonably cheap? I need of course
4Mbit-capable chip. :-)

As I understand to your explanation, did you mean that the anoalog-to-digital IrDA chips are capable of full-duplex, but the packet chips not?

I have FIC VA503+ motherboard with "IrDA connector". Is the packet chip already
on my board?

Best regards

Karel Kulhavy




From fyr@nabab.teaser.fr Thu, 16 Dec 1999 02:39:57 +0100
Date: Thu, 16 Dec 1999 02:39:57 +0100
From: Francois Ranchin fyr@nabab.teaser.fr
Subject: [Linux-IrDA][ANNOUNCE] successfull ppp connection with the tri-band GSM MOTOROLA TIMEPORT

Hi,

On on Sony PCG-748 without any more than the phone himself (no PCCell
etc.) The IR device is an SMC. "Stable" kernel 2.2.13 under debian.

Everything is in the doc except that on /etc/irda/drivers I need
charge irattach /dev/ttyS2 AND /dev/ircomm.

Kermit and ppp work both fine. Better result with the phone away the
conputer and "on charge".


ps. For the joke : the customer support told me that there is a winmodem
in the cell-phone. But I was unable to run it under windows. huhu.

Have a nice day !




From soruk@eridani.demon.co.uk Thu, 16 Dec 1999 12:59:22 +0000 (GMT)
Date: Thu, 16 Dec 1999 12:59:22 +0000 (GMT)
From: Michael McConnell soruk@eridani.demon.co.uk
Subject: [Linux-IrDA][ANNOUNCE] successfull ppp connection with the
 tri-band GSM MOTOROLA TIMEPORT

Hate to break it to you, but I've been using that same phone with PPP
under Linux for over a month now :)

Kernel 2.2.13, built-in IrDA driver

On Thu, 16 Dec 1999, Francois Ranchin wrote:

> Hi,
> 
> On on Sony PCG-748 without any more than the phone himself (no PCCell
> etc.) The IR device is an SMC. "Stable" kernel 2.2.13 under debian.
> 
> Everything is in the doc except that on /etc/irda/drivers I need
> charge irattach /dev/ttyS2 AND /dev/ircomm.
> 
> Kermit and ppp work both fine. Better result with the phone away the
> conputer and "on charge".
> 
> 
> ps. For the joke : the customer support told me that there is a winmodem
> in the cell-phone. But I was unable to run it under windows. huhu.
> 
> Have a nice day !
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
> 
> 

-- Michael "Soruk" McConnell                      [Eridani Linux 6.1A Now!]
Eridani Linux  --  The Most Up-to-Date Red Hat-based Linux CDROMs Available
Email: linux@eridani.co.uk  http://www.eridani.co.uk   Fax: +44-8701-600807





From dagb@cs.uit.no 17 Dec 1999 08:54:04 +0100
Date: 17 Dec 1999 08:54:04 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]WinCE and IrCOMM problems

"Jonathan Dixon" <joth@bigfoot.com> writes:

> > >> pppd ircomm0 115200 connect '/usr/sbin/chat "CLIENT" "SERVER"' ...
> >
> > Actually,
> > pppd ircomm0 115200 connect "/usr/sbin/chat '' CLIENT SERVER ''"
> > seems more likely to work to me.  (Just sticking my nose where it doesn't
> > belong. :)
> >
> > //Peter
> > ...
> Sorry, I wasn't very clear.
> 
> We're pretending to be the server (as opposed to my quoted Psion script,
> which was playing the role of client). So the algorithm we want is...
>  * Wait for "CLIENT" from the WinCE device.
>  * Send "SERVER".
> >> Presto! We're connected! Start doing pppd stuff! <<

I tried this for a while, but couldn't make it work. I asked the local
technician (knows everything), and he said I had to reply with
"CLIENTSERVER" to make it work. So when I tried:

pppd ircomm0 115200 connect '/usr/sbin/chat "CLIENT" "CLIENTSERVER"'

... then it connected on the first try.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From joth@bigfoot.com Fri, 17 Dec 1999 09:43:50 -0000
Date: Fri, 17 Dec 1999 09:43:50 -0000
From: Jonathan Dixon joth@bigfoot.com
Subject: [Linux-IrDA]WinCE and IrCOMM problems

>
> I tried this for a while, but couldn't make it work. I asked the local
> technician (knows everything), and he said I had to reply with
> "CLIENTSERVER" to make it work. So when I tried:
>
> pppd ircomm0 115200 connect '/usr/sbin/chat "CLIENT" "CLIENTSERVER"'
>
> ... then it connected on the first try.
>

Ahh, interesting! Well done on getting it going.

Of course, this will then still work with some other client (i.e. the one
I'm using) that sends "CLIENT" and then waits for "SERVER". So we were both
right ;-) Sorry if you wasted much time on this... if I actually had NT-RAS
installed on my current machine I might have been able to guess this a
little more accurately!

On a different note: all my attempts at running pppd over ircomm0 have
resulted in a complete machine lock-up :-( Using kernel 2.2.13-irda12,
irda-utils-0.9.5, and irattach /dev/ttyS1 -d esi. pppd sits and waits
happily, then as soon as I try to connect (I see "Connect: pppd0 <-->
/dev/ircomm0") the linux machine completely hangs. pppd works fine over
cable though, and I've can get minicom sessions working on ircomm0.
Any ideas what might be causing this?

Cheers

Joth





From dagb@cs.uit.no 17 Dec 1999 11:51:02 +0100
Date: 17 Dec 1999 11:51:02 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]WinCE and IrCOMM problems

"Jonathan Dixon" <joth@bigfoot.com> writes:

> On a different note: all my attempts at running pppd over ircomm0 have
> resulted in a complete machine lock-up :-( Using kernel 2.2.13-irda12,
> irda-utils-0.9.5, and irattach /dev/ttyS1 -d esi. pppd sits and waits
> happily, then as soon as I try to connect (I see "Connect: pppd0 <-->
> /dev/ircomm0") the linux machine completely hangs. pppd works fine over
> cable though, and I've can get minicom sessions working on ircomm0.
> Any ideas what might be causing this?

No, but I've been trying to find the bug for the last 2 days ;-) I'll
notify you as soon as I find the bug(s).

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From adomjan@horus.ch Sat, 18 Dec 1999 13:12:38 +0100
Date: Sat, 18 Dec 1999 13:12:38 +0100
From: Alexis DOMJAN adomjan@horus.ch
Subject: [Linux-IrDA]Problems with an Ericson SH888 and IrDA

Hello,

I just got an Ericsson SH888 because I knew this one was fully supported
by linux (for IR and modem). I tried to make this works but there are some
really weird problems. Here's a list of working / not working things:

* The modem works under Linux when using the RS232 cable and then attaching the
  serial device with irattach.
* The modem and IR connection works under windows without any problem
* When trying to use IR under Linux I can't see SH888 discovery messages with
  irdadump.
* When trying to ping any device with irdaping 0x0 then I get this:

  halley:~ # irdaping 0x0
  IrDA ping (0x00000000): 32 bytes
  32 bytes from 0x207a4ebd: irda_seq=1 time=119.44 ms.   

  Then I try to ping 0x207a4ebd:

  halley:~ # irdaping 0x207a4edb
  IrDA ping (0x207a4edb): 32 bytes
  32 bytes from 0x207a4ebd: irda_seq=0 time=118.78 ms.   

  When my SH888 is in the IR field of my laptop it replies to pings,
  when I remove it from the field it doesn't. 

So, it seems that everything is working excepted the fact that I can't
see the discovery messages from my SH888. When using a SH888 from a friend
I can see those discovery messages. 

Does someone know if there are several model of the SH888 ? Does someone
have an idea about this problem ? The weird thing is that I just tried
to make it work under windows (with same hardware) to see if my SH888 had
a problem, however it works perfectly with bill's "os"...

Thanks in advance for any little help with this...

See ya
-- 
Alexis Domjan <adomjan@horus.ch>




From dagb@cs.uit.no 18 Dec 1999 14:39:24 +0100
Date: 18 Dec 1999 14:39:24 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Problems with an Ericson SH888 and IrDA

Alexis DOMJAN <adomjan@horus.ch> writes:

> Hello,
> 
> I just got an Ericsson SH888 because I knew this one was fully supported
> by linux (for IR and modem). I tried to make this works but there are some
> really weird problems. Here's a list of working / not working things:

Always tell which kernel version and patch level (if any) you are
using. How do you start irattach? Do you use irmanager? What does irdadump
say? If you are using an old kernel, then you might want to increase the 
/proc/sys/net/irda/slot_timeout to 90. If so then you should probably
consider upgrading as well.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From adomjan@horus.ch Sat, 18 Dec 1999 15:23:26 +0100
Date: Sat, 18 Dec 1999 15:23:26 +0100
From: Alexis DOMJAN adomjan@horus.ch
Subject: [Linux-IrDA]Problems with an Ericson SH888 and IrDA

On Sat, Dec 18, 1999 at 02:39:24PM +0100, Dag Brattli wrote:
Hello,

> > I just got an Ericsson SH888 because I knew this one was fully supported
> > by linux (for IR and modem). I tried to make this works but there are some
> > really weird problems. Here's a list of working / not working things:
> 
> Always tell which kernel version and patch level (if any) you are
> using. How do you start irattach? Do you use irmanager? What does irdadump
> say? If you are using an old kernel, then you might want to increase the 
> /proc/sys/net/irda/slot_timeout to 90. If so then you should probably
> consider upgrading as well.

Ok, here's more details:

I first used kernel 2.2.13 but then I tried upgrading to 2.2.14-pre14, with
both I can't see my SH888 while I see some friends' SH888. I don't use any
other patches

1. Using RS232 Cable with IrDA:

   irmanager -d 1
   irattach /dev/ttyS0
   insmod ircomm
   insmod ircomm_tty

   then I can see the modem with irdadump:

   14:12:42.917941 xid:rsp 17ccc80e < 59d9f876 S=6 s=2 SH 888         hint=9104 [ PnP Modem IrCOMM ] (31)    

   I can use it without any problem using minicom on device /dev/ircomm0
   (char major 60, minor 64).

2. Using IrDA on IR port (BIOS setup using IrDA protocol)

   irmanager -d 1
   irattach /dev/ttyS1
   insmod ircomm
   insmod ircomm_tty

   Then I can see SH888 of a friend, but not mine.

   I can also ping my SH888 by first sending a "irdaping 0x0" and then I
   get a reply from my SH888.

   halley:~/bin # irdaping 0x0
   IrDA ping (0x00000000): 32 bytes
   32 bytes from 0x3d51bf55: irda_seq=0 time=117.29 ms. 

   Then:

   halley:~/bin # irdaping 0x3d51bf55
   IrDA ping (0x3d51bf55): 32 bytes
   32 bytes from 0x3d51bf55: irda_seq=0 time=114.31 ms.  

   When pinging I can see this message in the syslogs:

   Dec 18 15:19:07 halley kernel: irlap_driver_rcv(), TEST_FRAME
   Dec 18 15:19:07 halley kernel: irlap_recv_test_frame()
   Dec 18 15:19:07 halley kernel: irlap_state_ndm() not implemented!

   So IR seems to work, but I can't see IrLMP discovery message from it.
   
   If I try to use minicom, then I get no reply from the SH888, and the
   last message in the log is:

   Dec 18 15:19:58 halley kernel: ircomm_open_instance():
   Dec 18 15:19:58 halley kernel: ircomm_next_state: NEXT STATE=0(IDLE), servicetype=(4)
   Dec 18 15:19:58 halley kernel: irias_add_octseq_attrib_R6fc33859()
   Dec 18 15:19:58 halley kernel: irias_add_octseq_attrib_R6fc33859: name=Parameters
   Dec 18 15:19:58 halley kernel: irias_add_octseq_attrib_R6fc33859: len=6
   Dec 18 15:19:58 halley kernel: ircomm_next_state: NEXT STATE=1(DISCOVERY_WAIT), servicetype=(4)
   Dec 18 15:19:58 halley kernel: irvtd_set_termios:            

   But there are no communications between computer and the modem.

You know, this is really weird... Because the SH888 works under winblows. So
it should not be defect... 

I also thought there was maybe several model of this phone. But I asked a
friend who has exactly the same model number and it works for him under
linux.

I hate this kind of problem when you can't identify the source of the 
problem... :-)

Do you know a program that can just say if there is IR activity ? Kind
of "raw" measure of IR on the diode ? That could help to see if the modem
sends IrLMP packets or not.

Thanks for your help,
Regards
-- 
Alexis Domjan <adomjan@horus.ch>




From adomjan@horus.ch Sat, 18 Dec 1999 17:20:10 +0100
Date: Sat, 18 Dec 1999 17:20:10 +0100
From: Alexis DOMJAN adomjan@horus.ch
Subject: [Linux-IrDA]Problems with an Ericson SH888 and IrDA

On Sat, Dec 18, 1999 at 02:39:24PM +0100, Dag Brattli wrote:
Hello,

> Always tell which kernel version and patch level (if any) you are
> using. How do you start irattach? Do you use irmanager? What does irdadump
> say? If you are using an old kernel, then you might want to increase the 
> /proc/sys/net/irda/slot_timeout to 90. If so then you should probably
> consider upgrading as well.

Because I didn't have an old kernel I didn't tried to increase the slot timeout
immediately. But after hours of different test I tried to set up the timeout
to 90, and then it works...

Here's my configuration:

* irda-common/irda-tools : 0.9.5-1.1 (debian potato)
* kernel 2.2.14-pre14

I tried with a slot timeout of 89 and it does not work. So the smaller value
is 90.

The weird thing is that with the same phone from a friend it works with a
80 ms as timeout...

Anyway, a big thanks for your help. 
Regards
-- 
Alexis Domjan <adomjan@horus.ch>




From dagb@cs.uit.no 18 Dec 1999 20:21:15 +0100
Date: 18 Dec 1999 20:21:15 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Problems with an Ericson SH888 and IrDA

Alexis DOMJAN <adomjan@horus.ch> writes:

> Because I didn't have an old kernel I didn't tried to increase the slot timeout
> immediately. But after hours of different test I tried to set up the timeout
> to 90, and then it works...
> 
> Here's my configuration:
> 
> * irda-common/irda-tools : 0.9.5-1.1 (debian potato)
> * kernel 2.2.14-pre14
> 
> I tried with a slot timeout of 89 and it does not work. So the smaller value
> is 90.

Yes, 89 is the same as 80 when you divide it by 10 ;-) I assume your kernel
is using a HZ of 100 (default). If you _really_ want to use a timeout of
89, then you must increase the HZ to say 1000. The Linux kernel cannot
generate a timout of 89 ms in any good way when using a HZ of 100.
 
> The weird thing is that with the same phone from a friend it works with a
> 80 ms as timeout...

Not weird, since there all small margins here. My phone uses about 87 ms
(see below) from the XID is sent til the answer is received. So if I start
the transmission of a new frame earlier than 87 ms, then it will destroy
the incomming frame. Just run irdadump -d and check out how fast your and
your friends phone is reponding:

19:19:34.898291 (0090.01 ms) xid:cmd 18088056 > ffffffff S=6 s=1 (14) 
19:19:34.985651 (0087.36 ms) xid:rsp 18088056 < 24757385 S=6 s=1 I 888 WORLD    hint=9104 [ PnP Modem IrCOMM ] (31) 
19:19:34.988214 (0002.56 ms) xid:cmd 18088056 > ffffffff S=6 s=2 (14) 
19:19:35.078199 (0089.99 ms) xid:cmd 18088056 > ffffffff S=6 s=3 (14) 
19:19:35.168223 (0090.02 ms) xid:cmd 18088056 > ffffffff S=6 s=4 (14) 
19:19:35.258218 (0090.00 ms) xid:cmd 18088056 > ffffffff S=6 s=5 (14) 
19:19:35.348264 (0090.05 ms) xid:cmd 18088056 > ffffffff S=6 s=* Linux hint=0400 [ Computer ] (21) 

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 19 Dec 1999 09:29:40 +0100
Date: 19 Dec 1999 09:29:40 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]TODO list for Linux-2.4

Hi,

Somebody wanted a TODO list, so here it is in prioritized order:

1) Fix IrLAN (cannot register netdevices from interrupt context)

2) Fix SMC driver (so it actually works)

3) Fix NSC driver (so it works with the '338)

4) Toshoboe needs cleanup, and must take the minimum turn time into
   account. This driver may not work properly with slow devices at FIR
   speeds. Using usleep up to 1 ms may be acceptable, and would help a lot!

5) Fix Airport dongle driver (not ported to the new arch yet, using
   irmanager to fix this wasn't that easy after all)

Nothing else is more important than this, so just start working! Things
that are not working properly will be removed once pre-2.4 starts. There
are good chances that we might also get all the latest changes into
pre-2.2.15 as well.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From stuge@cdy.org Sun, 19 Dec 1999 18:53:45 +0100 (CET)
Date: Sun, 19 Dec 1999 18:53:45 +0100 (CET)
From: Peter Stuge stuge@cdy.org
Subject: [Linux-IrDA]TODO list for Linux-2.4

On 19 Dec 1999, Dag Brattli wrote:

>2) Fix SMC driver (so it actually works)
>Nothing else is more important than this, so just start working! Things

Well.  Where should I start?  What is the current status of the SMC-driver?
Is there any sort of reference for me to look at for the newer irport
structure?

//Peter

--
irc: CareBear\    tel: +46-40-914420
irl: Peter Stuge  gsm: +46-705-783805





From kh@club.innet.be Sun, 19 Dec 1999 21:55:38 +0100
Date: Sun, 19 Dec 1999 21:55:38 +0100
From: Kris Heyrman kh@club.innet.be
Subject: [Linux-IrDA]SH888 on Dell Latitude CPt C333: problem

Thomas Heide Clausen wrote:

> Ohh, I just saw in the end that you are using the irda3-patch. That is WAY too
> low. It is definitely worth upgrading to the latest one.......In fact it is
> almost required. Try upgrading and retry my "procedure" - I am sure that will
> work.
>

Hallo Thomas.

I'm sorry to say.. no luck yet. (although I don't want to pretend I was busy with that
all week... I just had some other things to attend to...). I used Linux Kernel 2.2.13
patched with sony-patch.2.2.13 for sound, patch-2.2.13-irda12 for IrCOMM, and provided
with pcmcia-cs-3.0.14 (with CardBus support, and using /etc/pcmcia/network from
RedHat, not the pcmcia-cs distribution).  I believe  patch-2.2.13-irda12 contains the
ircomm-tty.o driver instead of ircomm_tty in patch-2.2.13-irda3. And that must have
been wat made my machine hang while "checking modules depencies...".  I gave up for a
while, in the meantime installed RH 6.1 on it, and will try again a bit later.

> Ohh, and let me know how it goes, ok?

I will!

> > "L'an 0. On arrète tout, puis on réflechit. Et c'est pas triste."
>
> Okok, I do LIVE in France...but I really am scandinavian like Dag . [ ... ] However,
> I do not speak French -
> what does the above mean?

It's a saying I recovered from the early seventies, and it means: "The year 0. We stop
everything, and think. And that is not a sad thing." I thought it was appropriate for
the time. Maybe, since the digit 0 was not known in Europe in the year 1000, we will
discover that counting the years really works modulo 1000! It's more romantic,
I think, to start again.

--
Kris Heyrman.
Ottergemsesteenweg 337, B-9000 Gent.      Phone:  +32.9.221.79.69

"L'an 0. On arrète tout, puis on réflechit. Et c'est pas triste."







From Holger.Brueckner@lrz-muenchen.de Mon, 20 Dec 1999 16:59:43 +0100 (MET)
Date: Mon, 20 Dec 1999 16:59:43 +0100 (MET)
From: Holger Darks Brueckner Holger.Brueckner@lrz-muenchen.de
Subject: [Linux-IrDA]Vaio F-305 and discovery

Hello *,

i'm having problems setting up irda on my vaio f305.
what i want to do is to connect my siemens s25 phone to the irda port.

i'm currently expermimenting with irda-12 patch and irda-utils-0.9.4

as usual on bootup the serial port isn't recognized correctly so i set it
with setserial to uart 1655A and irq 10. then i start irmanager -d 1
(witch includes irattach /dev/ttyS2) witch seems to work ok. at least it
doesn't produce any error messages.

but nothing appears in /proc/net/irda/discovery. not the s25 with irda
turned on nor a palm iii.

thany for any help

Holger

     _/\/\/\/\/\____________________________/\/\___________________
    _/\/\____/\/\__/\/\/\______/\/\__/\/\__/\/\__/\/\____/\/\/\/\_ 
   _/\/\____/\/\______/\/\____/\/\/\/\____/\/\/\/\____/\/\/\/\___  
  _/\/\____/\/\__/\/\/\/\____/\/\________/\/\/\/\__________/\/\_   
 _/\/\/\/\/\____/\/\/\/\/\__/\/\________/\/\__/\/\__/\/\/\/\___    
______________________________________________________________ 
      http://www.fet.org                   darks@fet.org
    





From peterm@shinesoft.com Sun, 19 Dec 1999 07:44:18 -0800
Date: Sun, 19 Dec 1999 07:44:18 -0800
From: Peter Michalek peterm@shinesoft.com
Subject: [Linux-IrDA]irdautils download

Is there a mirror of irdautils-0.9.5-1.1 and related stuff, or at least
binaries for redhat?
I couldn't access http://www.cs.uit.no:80/linux-irda/irda-utils/,
www.cs.uit.no seems to 
be down for me in the last 2 days.

Peter




From dagb@cs.uit.no 20 Dec 1999 17:51:15 +0100
Date: 20 Dec 1999 17:51:15 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]Vaio F-305 and discovery

Holger Darks Brueckner <Holger.Brueckner@lrz-muenchen.de> writes:

> Hello *,
> 
> i'm having problems setting up irda on my vaio f305.
> what i want to do is to connect my siemens s25 phone to the irda port.
> 
> i'm currently expermimenting with irda-12 patch and irda-utils-0.9.4

Wit irda12 you should really use irda-utils-0.9.5 and _not_ use irmanger!
Start irattach like this: "irattach /dev/ttyS2 -s 1"

> as usual on bootup the serial port isn't recognized correctly so i set it
> with setserial to uart 1655A and irq 10. then i start irmanager -d 1
> (witch includes irattach /dev/ttyS2) witch seems to work ok. at least it
> doesn't produce any error messages.
> 
> but nothing appears in /proc/net/irda/discovery. not the s25 with irda
> turned on nor a palm iii.
> 
> thany for any help

What does ifconfig and /proc/interrupts say?

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From Stephane.FILLOD@st.com Mon, 20 Dec 1999 09:43:14 -0700
Date: Mon, 20 Dec 1999 09:43:14 -0700
From: Stephane.FILLOD@st.com Stephane.FILLOD@st.com
Subject: [Linux-IrDA]TODO list for Linux-2.4

irport-SMC is fixed in the pre-irda14. You must compile with Ultra in order 
to prevent missing symbols (Dag, missing #ifdefs ?).

At FIR, it looks like the smc-driver is unable to transmit frames bigger than 
1500 bytes using the DMA. Peter, if you want a start point, you can have a 
look at the data sheet from www.smsc.com, and play with the dma_write (expect 
some lockups..).
There are also a couple of typos in smc-ircc.c, but fixing them does not fix 
the driver at FIR speed :(

good luck and let me know what you get.

Stephane

______________________________ Reply Separator _____________________________
Subject: Re: [Linux-IrDA]TODO list for Linux-2.4
Author:  stuge (stuge@cdy.org) at internet
Date:    12/19/99 10:53 AM


On 19 Dec 1999, Dag Brattli wrote:

>2) Fix SMC driver (so it actually works)
>Nothing else is more important than this, so just start working! Things

Well.  Where should I start?  What is the current status of the SMC-driver?
Is there any sort of reference for me to look at for the newer irport
structure?

//Peter

--
irc: CareBear\    tel: +46-40-914420
irl: Peter Stuge  gsm: +46-705-783805





From gun2019@gmx.net Mon, 20 Dec 1999 19:53:21 +0100
Date: Mon, 20 Dec 1999 19:53:21 +0100
From: gun2019 gun2019@gmx.net
Subject: [Linux-IrDA]Vaio F-305 and discovery

On Mon, Dec 20, 1999 at 05:51:15PM +0100, Dag Brattli wrote:
> Holger Darks Brueckner <Holger.Brueckner@lrz-muenchen.de> writes:
> 
> > Hello *,
> > 
> > i'm having problems setting up irda on my vaio f305.
> > what i want to do is to connect my siemens s25 phone to the irda port.
> > 
> > i'm currently expermimenting with irda-12 patch and irda-utils-0.9.4
> 
> Wit irda12 you should really use irda-utils-0.9.5 and _not_ use irmanger!
> Start irattach like this: "irattach /dev/ttyS2 -s 1"
> 
is this documented somewhere ?
Saw this "-s 1" for the first time.

Heiko

-- 
for a three year old with a hammer everything looks like a nail




From Per.Wallner@era.ericsson.se Tue, 21 Dec 1999 10:30:45 +0100
Date: Tue, 21 Dec 1999 10:30:45 +0100
From: Per Wallner (QRA) Per.Wallner@era.ericsson.se
Subject: [Linux-IrDA]patch-2.2.13-irda19/20

Dag,
reading your diary I get the impression (since you don't explicitly 
say otherwise ;) that patches 2.2.13-irda19/20 might be public.
However, I don't find them around. I guess I'm just asking when
the next patch will be released?

And oh - thanks for a great job!

Regards,
Per Wallner
Ericsson Radio Systems





From joth@bigfoot.com Tue, 21 Dec 1999 11:23:29 -0000
Date: Tue, 21 Dec 1999 11:23:29 -0000
From: Jonathan Dixon joth@bigfoot.com
Subject: [Linux-IrDA]Vaio F-305 and discovery

> is this documented somewhere ?
> Saw this "-s 1" for the first time.
> 

Yes, in irattach.c ;-)
(At least, that's where I look-up command line options)

Cheers,
Joth





From cg@suse.de Tue, 21 Dec 1999 15:24:32 +0100 (MET)
Date: Tue, 21 Dec 1999 15:24:32 +0100 (MET)
From: Carsten Gross cg@suse.de
Subject: [Linux-IrDA]IrDA connection to Motorola L7089

Hi,

I am trying to connect to a Motorola L7089 mobile phone over the infrared
port, but it won't work. Or better said: I can open the device file
/dev/ircomm0 but the connection is `dead', the mobile phone won't respond
anything.

It worked exactly once with the command `cu' and I was able to send commands
like ati and atz via the infrared interface (which were replied by the phone
with OK or ERROR) but this was not repeatable.

I tested it with an unpatched Kernel 2.3.34 and with the original SuSE
Kernel from 6.3, Version 2.2.13 (In SuSE Linux 6.3 IrDA generally works when
used for example with the Siemens S25 or on the Canon BJC-80 - perhaps it is
some trouble especially with this mobile phone?)

I included the output of irdadump when trying to send something with cu
(babbage is my desktop system using a motherboard adapter and the irport
driver).

If you need more debugging output please let me know. As you can see the
mobile phone is in range (sorry for long lines):

14:06:22.006322 xid:cmd ffffffff < 97833cb5 S=6 s=4 (14) 
14:06:22.006373 xid:rsp df462422 > 97833cb5 S=6 s=4 Babbage hint=0400 [ Computer ] (23) 
14:06:22.148784 xid:cmd ffffffff < 97833cb5 S=6 s=5 (14) 
14:06:22.248357 xid:cmd ffffffff < 97833cb5 S=6 s=* L Series hint=9104 [ PnP Modem IrCOMM ] (25) 
14:06:23.435489 xid:cmd df462422 > ffffffff S=6 s=0 (14) 
14:06:23.525514 xid:cmd df462422 > ffffffff S=6 s=1 (14) 
14:06:23.615637 xid:cmd df462422 > ffffffff S=6 s=2 (14) 
14:06:23.705471 xid:cmd df462422 > ffffffff S=6 s=3 (14) 
14:06:23.784591 xid:rsp df462422 < 97833cb5 S=6 s=3 L Series hint=9104 [ PnP Modem IrCOMM ] (25) 
14:06:23.795470 xid:cmd df462422 > ffffffff S=6 s=4 (14) 
14:06:23.885476 xid:cmd df462422 > ffffffff S=6 s=5 (14) 
14:06:23.975533 xid:cmd df462422 > ffffffff S=6 s=* Babbage hint=0400 [ Computer ] (23) 

[ I am opening /dev/ircomm0 here ]

14:06:24.556843 snrm:cmd ca=fe pf=1 df462422 > 97833cb5 new-ca=20 (32) 
14:06:24.662351 ua:rsp ca=20 pf=1 df462422 < 97833cb5 (31) 
14:06:24.662415 rr:cmd > ca=20 pf=1 nr=0 (2) 
14:06:24.905494 rr:cmd > ca=20 pf=1 nr=0 (2) 
14:06:24.913883 rr:rsp < ca=20 pf=1 nr=0 (2) 
14:06:24.913922 i:cmd  > ca=20 pf=1 nr=0 ns=0 LM slsap=16 dlsap=00 CONN_CMD (6) 
14:06:24.923016 i:rsp  < ca=20 pf=1 nr=1 ns=0 LM slsap=00 dlsap=16 CONN_RSP (6) 
14:06:24.923075 i:cmd  > ca=20 pf=1 nr=1 ns=1 LM slsap=16 dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "Parameters" (28) 
14:06:24.934935 i:rsp  < ca=20 pf=1 nr=2 ns=1 LM slsap=00 dlsap=16 GET_VALUE_BY_CLASS: Success N/A (16) 
14:06:24.934994 i:cmd  > ca=20 pf=1 nr=2 ns=2 LM slsap=16 dlsap=00 DISC (6) 
14:06:24.943643 rr:rsp < ca=20 pf=1 nr=3 (2) 
14:06:24.943682 i:cmd  > ca=20 pf=1 nr=2 ns=3 LM slsap=17 dlsap=00 CONN_CMD (6) 
14:06:24.952762 i:rsp  < ca=20 pf=1 nr=4 ns=2 LM slsap=00 dlsap=17 CONN_RSP (6) 
14:06:24.952812 i:cmd  > ca=20 pf=1 nr=3 ns=4 LM slsap=17 dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "IrDA:TinyTP:LsapSel" (37) 
14:06:24.965744 i:rsp  < ca=20 pf=1 nr=5 ns=3 LM slsap=00 dlsap=17 GET_VALUE_BY_CLASS: Success Integer: 03 (15) 
14:06:24.965809 i:cmd  > ca=20 pf=1 nr=4 ns=5 LM slsap=17 dlsap=00 DISC (6) 
14:06:24.974520 rr:rsp < ca=20 pf=1 nr=6 (2) 
14:06:24.974560 i:cmd  > ca=20 pf=1 nr=4 ns=6 LM slsap=15 dlsap=03 CONN_CMD TTP credits=0(7) 
14:06:24.983309 i:rsp  < ca=20 pf=1 nr=7 ns=4 LM slsap=03 dlsap=15 CONN_RSP TTP credits=0(17) 
14:06:24.983455 i:cmd  > ca=20 pf=1 nr=5 ns=7 LM slsap=15 dlsap=03 TTP credits=0 (24) 
14:06:24.992546 i:rsp  < ca=20 pf=1 nr=0 ns=5 LM slsap=03 dlsap=15 TTP credits=1 (5) 
14:06:24.992599 rr:cmd > ca=20 pf=1 nr=6 (2) 
14:06:25.000888 rr:rsp < ca=20 pf=1 nr=0 (2) 
14:06:25.045539 rr:cmd > ca=20 pf=1 nr=6 (2) 
14:06:25.053834 rr:rsp < ca=20 pf=1 nr=0 (2) 
14:06:25.145492 rr:cmd > ca=20 pf=1 nr=6 (2) 

[ repeats around 30-40 times, trying to enter something ]

[ and killing cu ]

14:06:44.831913 i:cmd  > ca=20 pf=1 nr=6 ns=0 LM slsap=15 dlsap=03 DISC (6) 
14:06:44.840609 rr:rsp < ca=20 pf=1 nr=1 (2) 
14:06:44.840667 rr:cmd > ca=20 pf=1 nr=6 (2) 
rd:rsp < ca=0x20 pf=1 (2) 
14:06:44.849098 ua:rsp ca=20 pf=1 df462422 > 97833cb5 (10) 
14:06:47.435978 xid:cmd df462422 > ffffffff S=6 s=0 (14) 
14:06:47.525951 xid:cmd df462422 > ffffffff S=6 s=1 (14) 
14:06:47.615956 xid:cmd df462422 > ffffffff S=6 s=2 (14) 
14:06:47.705952 xid:cmd df462422 > ffffffff S=6 s=3 (14) 
14:06:47.795953 xid:cmd df462422 > ffffffff S=6 s=4 (14) 
14:06:47.885964 xid:cmd df462422 > ffffffff S=6 s=5 (14) 
14:06:47.975972 xid:cmd df462422 > ffffffff S=6 s=* Babbage hint=0400 [ Computer ] (23) 
14:06:48.655200 xid:cmd ffffffff < 97833cb5 S=6 s=0 (14) 
14:06:48.742814 xid:cmd ffffffff < 97833cb5 S=6 s=1 (14) 
14:06:48.830503 xid:cmd ffffffff < 97833cb5 S=6 s=2 (14) 
14:06:48.918194 xid:cmd ffffffff < 97833cb5 S=6 s=3 (14) 
14:06:49.005966 xid:cmd ffffffff < 97833cb5 S=6 s=4 (14) 
14:06:49.006026 xid:rsp df462422 > 97833cb5 S=6 s=4 Babbage hint=0400 [ Computer ] (23) 
14:06:49.148975 xid:cmd ffffffff < 97833cb5 S=6 s=5 (14) 
14:06:49.248539 xid:cmd ffffffff < 97833cb5 S=6 s=* L Series hint=9104 [ PnP Modem IrCOMM ] (25) 
14:06:50.436047 xid:cmd df462422 > ffffffff S=6 s=0 (14) 
[...]

Regards and thanks 

   Carsten

-- 
Opinions written above are my own.
Carsten Groß                                                   SuSE GmbH
cg@suse.de                                          Schanzäckerstraße 10
privat: Kappengasse 13, 90402 Nürnberg                    90443 Nürnberg





From T.Clausen@computer.org Tue, 21 Dec 1999 15:31:07 -0700
Date: Tue, 21 Dec 1999 15:31:07 -0700
From: Thomas Heide Clausen T.Clausen@computer.org
Subject: [Linux-IrDA]irattach: tcsetattr: Input/output error ???

Hello All,

I have suddenly started getting some wierd messages like the one included in
the subject in my syslog when starting irattach.

The setup used to work for me (after lots of help from different guys),
but.....anyways. I tried to upgrade to the latest IrDA-patches but with the
same result. 

My config is linux-2.2.13 w. patch-2.2.13-irda12 on an IBM ThinkPad 390. I use
irattach from irda-utils 0.9.5.

My IrDA-port is the first serial port and is recognized upon bootup:

	ttyS01 at 0x02f8 (irq = 3) is a 16550A
	ttyS02 at 0x03e8 (irq = 4) is a 16550A

I use:

	irattach /dev/ttyS0 -s 1

Which in /var/adm/messages yields:

Dec 21 15:30:33 laptoy irattach: Serial connection established.

and in /var/adm/syslog yields:

Dec 21 15:30:33 laptoy irattach: tcsetattr: Input/output error

I am not sure if this is of any help, but I tired (sucessfully) from home. Then
I left it be for a while (I am not aware of having done anything mysterious
since it worked) and was yesterday to go on a rather long trip by train. Hence
I tried to connect using my Ericsson SH888 - with no luck. Well arrived at an
ethernet jack, I downloaded the latest IrDA-patch, recompiled and decided to go
from there. Still no luck. I have been looking around the mailing list, and it
seems that others have experienced the same problems when using different
"dongles". However I did not find any explanation on what was the problem or
what would be the cure.

I'll be on the road quite a lot for the rest of this month and most of the next
month, so I'd prefer to have it running. Thus *any* help , hints or clues will
be most apprecuated.

Thanks in advance.

-- 
Mange hilsner / Sincerely

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: T.Clausen@computer.org
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------




From T.Clausen@computer.org Tue, 21 Dec 1999 16:12:25 -0700
Date: Tue, 21 Dec 1999 16:12:25 -0700
From: Thomas Heide Clausen T.Clausen@computer.org
Subject: [Linux-IrDA]irattach: tcsetattr: Input/output error ???

Please ignore my previous posting. I had forgotten that I'd inserted a netcard
which decided to conflict IRQ-wise with my IR-port. Reading the FAQ-part of the
otherwise outdated HOWTO yielded a clue.

I'll go think up a real nasty punishment for myself for not thinking/reading
that before asking.

Sorry I took your time and bandwidth

--thomas

On Tue, 21 Dec 1999, you wrote:
> Hello All,
> 
> I have suddenly started getting some wierd messages like the one included in
> the subject in my syslog when starting irattach.
> 
> The setup used to work for me (after lots of help from different guys),
> but.....anyways. I tried to upgrade to the latest IrDA-patches but with the
> same result. 
> 
> My config is linux-2.2.13 w. patch-2.2.13-irda12 on an IBM ThinkPad 390. I use
> irattach from irda-utils 0.9.5.
> 
> My IrDA-port is the first serial port and is recognized upon bootup:
> 
> 	ttyS01 at 0x02f8 (irq = 3) is a 16550A
> 	ttyS02 at 0x03e8 (irq = 4) is a 16550A
> 
> I use:
> 
> 	irattach /dev/ttyS0 -s 1
> 
> Which in /var/adm/messages yields:
> 
> Dec 21 15:30:33 laptoy irattach: Serial connection established.
> 
> and in /var/adm/syslog yields:
> 
> Dec 21 15:30:33 laptoy irattach: tcsetattr: Input/output error
> 
> I am not sure if this is of any help, but I tired (sucessfully) from home. Then
> I left it be for a while (I am not aware of having done anything mysterious
> since it worked) and was yesterday to go on a rather long trip by train. Hence
> I tried to connect using my Ericsson SH888 - with no luck. Well arrived at an
> ethernet jack, I downloaded the latest IrDA-patch, recompiled and decided to go
> from there. Still no luck. I have been looking around the mailing list, and it
> seems that others have experienced the same problems when using different
> "dongles". However I did not find any explanation on what was the problem or
> what would be the cure.
> 
> I'll be on the road quite a lot for the rest of this month and most of the next
> month, so I'd prefer to have it running. Thus *any* help , hints or clues will
> be most apprecuated.
> 
> Thanks in advance.
> 
> -- 
> Mange hilsner / Sincerely
> 
> -------------------------------------------
>   Thomas Heide Clausen
>   Civilingeniør i Datateknik (cand.polyt)
>   M.Sc in Computer Engineering
> 
>   E-Mail: T.Clausen@computer.org
>   WWW:    http://www.cs.auc.dk/~voop
> -------------------------------------------
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
-- 
Mange hilsner / Sincerely

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: T.Clausen@computer.org
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------




From mtepperis@pdv-online.de Tue, 21 Dec 1999 17:32:40 +0100
Date: Tue, 21 Dec 1999 17:32:40 +0100
From: Michael Tepperis mtepperis@pdv-online.de
Subject: [Linux-IrDA]IrDA connection to Motorola L7089

hi,

>I am trying to connect to a Motorola L7089 mobile phone over the infrared



>I tested it with an unpatched Kernel 2.3.34 and with the original SuSE
>Kernel from 6.3, Version 2.2.13 (In SuSE Linux 6.3 IrDA generally works
when
>used for example with the Siemens S25 or on the Canon BJC-80 - perhaps it
is
>some trouble especially with this mobile phone?)


I don't know about SuSE kernels, but the plain kernel 2.2.13 with
irda-patch-12
works for me using irda-tools-0.9.5.

connections to the L7089 and a kodak digital camera have been tested with
this configuration.

>(babbage is my desktop system using a motherboard adapter and the irport


what kind of adapter do you use? here it is a jeteye dongle connected to
a serial port. my motherboard does not have an irda port. the dongle
was hard to get and is expensive. what did you pay for the hardware?

>Carsten Groß                                                   SuSE GmbH
>cg@suse.de                                          Schanzäckerstraße 10






From dagb@cs.uit.no 21 Dec 1999 17:37:04 +0100
Date: 21 Dec 1999 17:37:04 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]IrDA connection to Motorola L7089

"Michael Tepperis" <mtepperis@pdv-online.de> writes:

> >I tested it with an unpatched Kernel 2.3.34 and with the original SuSE
> >Kernel from 6.3, Version 2.2.13 (In SuSE Linux 6.3 IrDA generally works
> when
> >used for example with the Siemens S25 or on the Canon BJC-80 - perhaps it
> is
> >some trouble especially with this mobile phone?)
>  
> I don't know about SuSE kernels, but the plain kernel 2.2.13 with
> irda-patch-12
> works for me using irda-tools-0.9.5.
> 
> connections to the L7089 and a kodak digital camera have been tested with
> this configuration.
> 
> >(babbage is my desktop system using a motherboard adapter and the irport

Yes, the 2.3.34 kernel does not contain the latest code, although I sent a
large patch in for 2.3.33 :-( So you should probably try using 2.2.13-irdaX
for now.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From peterm@shinesoft.com Tue, 21 Dec 1999 09:06:26 -0800
Date: Tue, 21 Dec 1999 09:06:26 -0800
From: Peter Michalek peterm@shinesoft.com
Subject: [Linux-IrDA]IrDA connection to Motorola L7089

Michael, what kind of kodak camera did you use? Do you have more details
on speed etc?

Peter


Dag Brattli wrote:
> 
> "Michael Tepperis" <mtepperis@pdv-online.de> writes:
> 
> > >I tested it with an unpatched Kernel 2.3.34 and with the original SuSE
> > >Kernel from 6.3, Version 2.2.13 (In SuSE Linux 6.3 IrDA generally works
> > when
> > >used for example with the Siemens S25 or on the Canon BJC-80 - perhaps it
> > is
> > >some trouble especially with this mobile phone?)
> >
> > I don't know about SuSE kernels, but the plain kernel 2.2.13 with
> > irda-patch-12
> > works for me using irda-tools-0.9.5.
> >
> > connections to the L7089 and a kodak digital camera have been tested with
> > this configuration.
> >
> > >(babbage is my desktop system using a motherboard adapter and the irport
> 
> Yes, the 2.3.34 kernel does not contain the latest code, although I sent a
> large patch in for 2.3.33 :-( So you should probably try using 2.2.13-irdaX
> for now.
> 
> -- Dag
> 
> --
>    / Dag Brattli                   | The Linux-IrDA Project               /
>   // University of Tromsoe, Norway | Infrared communication for Linux    //
>  /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda

-- 
Peter Michalek
ShineSoft Systems
peterm@shinesoft.com
http://www.shinesoft.com
Tel: (408) 446-5040
Fax: (408) 446-2573

-----------------------------------------------------------
http://www.shinesoft.com/shineprint/
The Home of ShinePrint - the Internet Printing Solution




From cg@suse.de Wed, 22 Dec 1999 13:38:04 +0100 (MET)
Date: Wed, 22 Dec 1999 13:38:04 +0100 (MET)
From: Carsten Gross cg@suse.de
Subject: [Linux-IrDA]IrDA connection to Motorola L7089

Hi,

Am 21.12.99 um 17:32 schrieb Michael Tepperis:
> I don't know about SuSE kernels, but the plain kernel 2.2.13 with
> irda-patch-12 works for me using irda-tools-0.9.5.

Okay, after patching a plain 2.2.13 to irda-patch23 I can talk to the phone
now using cu or minicom. But for some reason wvdial doesn't work, I'll get
the echoed ATZ back from the mobile phone but not the "OK".

> what kind of adapter do you use? here it is a jeteye dongle connected to
> a serial port. my motherboard does not have an irda port. the dongle
> was hard to get and is expensive. what did you pay for the hardware?

A german company (Reichelt) sells the Actisys IR motherboard adapter for
around 60.- DM (thats around 30 Euro). It includes the dongle and the 5 pin
motherboard connector.

Regards,

   Carsten

-- 
Carsten Groß                                                   SuSE GmbH
cg@suse.de                                          Schanzäckerstraße 10
privat: Kappengasse 13, 90402 Nürnberg                    90443 Nürnberg





From dagb@cs.uit.no 22 Dec 1999 14:18:49 +0100
Date: 22 Dec 1999 14:18:49 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]IrDA connection to Motorola L7089

Carsten Gross <cg@suse.de> writes:

> Okay, after patching a plain 2.2.13 to irda-patch23 I can talk to the phone
> now using cu or minicom. But for some reason wvdial doesn't work, I'll get
> the echoed ATZ back from the mobile phone but not the "OK".

Works fine for me after some fighting with wvdial to make it use ircomm0
instead of ttyS<x>. Not so intelligent dialer after all ;-) Anyway this
config worked fine for me:

[Dialer Defaults]
Modem = /dev/ircomm0
Baud = 57600
Init = ATZ
Phone = <phone>
Username = <name>
Password = <passwd>

Maybe your Init2 string makes the phone confused?

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From peterm@shinesoft.com Wed, 22 Dec 1999 10:43:06 -0800
Date: Wed, 22 Dec 1999 10:43:06 -0800
From: Peter Michalek peterm@shinesoft.com
Subject: [Linux-IrDA]irda-utils-0.9.5 and irobex

irda-utils-0.9.4 used to contain irobex tools, such as irobex_palm3, I
don't see those in 0.9.5.
Have they been removed? Where can I find an equivalent, or can I used
0.9.4 with 2.2.13-irda23?

Another question:
when trying to make 2.2.13-irda23 work, I am getting the following
error. I tried both irmanager
and irattach. Is there a up-to-date howto that describes the exact
procedure? ir-howto that comes
with redhat 6.1 seems to be obsolete (uses irmanager which seems not to
be needed according to some
messages on this list).

What needs to be updated in
http://www.redhat.com/mirrors/LDP/HOWTO/IR-HOWTO-5.html ?

---------
tail messages
Dec 22 09:55:26 irproxy irmanager: executing: 'echo 1 >
/proc/sys/net/irda/disco
very'
Dec 22 09:55:26 irproxy irmanager: executing: 'echo irproxy >
/proc/sys/net/irda
/devname'
Dec 22 09:55:26 irproxy irmanager: + 1.1 Tue Nov  9 15:30:55 1999 Dag
Brattli
Dec 22 09:55:26 irproxy irmanager: + 1.1 Tue Nov  9 15:30:55 1999 Dag
Brattli
Dec 22 09:55:26 irproxy irattach: Serial connection established.
Dec 22 09:55:26 irproxy irattach: irattach: tty: set_disc(11): Bad file
descript
or
Dec 22 09:55:26 irproxy 1.1 Tue Nov  9 15:30:55 1999 Dag Brattli

-peter




From dagb@cs.uit.no 22 Dec 1999 20:05:35 +0100
Date: 22 Dec 1999 20:05:35 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]irda-utils-0.9.5 and irobex

Peter Michalek <peterm@shinesoft.com> writes:

> irda-utils-0.9.4 used to contain irobex tools, such as irobex_palm3, I
> don't see those in 0.9.5.
> Have they been removed? Where can I find an equivalent, or can I used
> 0.9.4 with 2.2.13-irda23?

Pontus has taken over the OBEX development but he needs some help making
RPM's. PyOBEX will soon be released, and I have in fact started updating
the new Open-OBEX web-pages today.
 
> Another question:
> when trying to make 2.2.13-irda23 work, I am getting the following
> error. I tried both irmanager
> and irattach. Is there a up-to-date howto that describes the exact
> procedure? ir-howto that comes
> with redhat 6.1 seems to be obsolete (uses irmanager which seems not to
> be needed according to some
> messages on this list).
> 
> What needs to be updated in
> http://www.redhat.com/mirrors/LDP/HOWTO/IR-HOWTO-5.html ?

It's a bit dangerous to update the HOWTO for a development version of
Linux-IrDA if you ask me. Patch-2.2.13-irda23 reflects the IrDA code for
the Linux-2.3 development. Yes, things have changed a lot, and they might
be changed again!!! Lets make the modifications needed when Linux-2.4 is
out, or if we get things as is into 2.2.15.

People who have followed this mailing list knows what to do: "irattach
/dev/ttyS<x> -s 1" and using a dongle such as esi: "irattach /dev/ttyS<x>
-d esi -s 1". Irmanager is obsolete for the latest patches.

.. and in /etc/conf.modules

# IrDA
alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty
alias irda-dongle-0 tekram
alias irda-dongle-1 esi
...

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From peterm@shinesoft.com Wed, 22 Dec 1999 12:40:51 -0800
Date: Wed, 22 Dec 1999 12:40:51 -0800
From: Peter Michalek peterm@shinesoft.com
Subject: [Linux-IrDA]OBEX

Hi Pontus,

there is readme with size 0 in the obex .gz file.
When building, I get this error:
cd apps
make 
[root@irproxy apps]# make
gcc -g  -Wall -I/usr/include -I/usr/lib/glib/include  -c irobex_palm3.c
In file included from /usr/include/obex/obex_main.h:39,
                 from /usr/include/obex/obex.h:34,
                 from irobex_palm3.c:40:
/usr/include/obex/obex_object.h:34: gnetbuf.h: No such file or directory
In file included from /usr/include/obex/obex.h:34,
                 from irobex_palm3.c:40:
/usr/include/obex/obex_main.h:42: gnetbuf.h: No such file or directory
make: *** [irobex_palm3.o] Error 1

Is there a fix for this?

Peter

Pontus Fuchs wrote:
> 
> Hi!
> 
> The C-OBEX code has now reached a state when it works better than the
> version in 0.9.4. I need your feedback so try it out if you can/want. It can
> be downloaded from http://www.tactel.se/~pf/obex/ .
> 
> Please report success/failiure back to me!
> 
> (this has nothing to do with Dag's PyOBEX)
> 
> /Pontus Fuchs
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda




From peterm@shinesoft.com Wed, 22 Dec 1999 15:35:50 -0800
Date: Wed, 22 Dec 1999 15:35:50 -0800
From: Peter Michalek peterm@shinesoft.com
Subject: [Linux-IrDA]OBEX


Peter Michalek wrote:
> 
> Hi Pontus,
> 
> there is readme with size 0 in the obex .gz file.
> When building, I get this error:
> cd apps
> make
> [root@irproxy apps]# make
> gcc -g  -Wall -I/usr/include -I/usr/lib/glib/include  -c irobex_palm3.c
> In file included from /usr/include/obex/obex_main.h:39,
>                  from /usr/include/obex/obex.h:34,
>                  from irobex_palm3.c:40:
> /usr/include/obex/obex_object.h:34: gnetbuf.h: No such file or directory
> In file included from /usr/include/obex/obex.h:34,
>                  from irobex_palm3.c:40:
> /usr/include/obex/obex_main.h:42: gnetbuf.h: No such file or directory
> make: *** [irobex_palm3.o] Error 1

OK, this is what I had to do to make it work, in addition to
instructions from Pontus' web page.
cd obex
mv /usr/include/obex /usr/include/obex_old
mkdir /usr/include/obex
cp lib/src/*.h /usr/include/obex
cp -d /usr/local/lib/libobex* /usr/lib
cd ../apps
make

... now irobex_palm3 works for me.


> 
> Is there a fix for this?
> 
> Peter
> 
> Pontus Fuchs wrote:
> >
> > Hi!
> >
> > The C-OBEX code has now reached a state when it works better than the
> > version in 0.9.4. I need your feedback so try it out if you can/want. It can
> > be downloaded from http://www.tactel.se/~pf/obex/ .
> >
> > Please report success/failiure back to me!
> >
> > (this has nothing to do with Dag's PyOBEX)
> >
> > /Pontus Fuchs
> >
> > _______________________________________________
> > Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> > http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
> 
> _______________________________________________
> Linux-IrDA mailing list  -  Linux-IrDA@pasta.cs.UiT.No
> http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda




From peterm@shinesoft.com Wed, 22 Dec 1999 15:48:47 -0800
Date: Wed, 22 Dec 1999 15:48:47 -0800
From: Peter Michalek peterm@shinesoft.com
Subject: [Linux-IrDA]irda-utils-0.9.5 and irobex


Dag Brattli wrote:
> 
> > Another question:
> > when trying to make 2.2.13-irda23 work, I am getting the following
> > error. I tried both irmanager
> > and irattach. Is there a up-to-date howto that describes the exact
> > procedure? ir-howto that comes
> > with redhat 6.1 seems to be obsolete (uses irmanager which seems not to
> > be needed according to some
> > messages on this list).
> >
> > What needs to be updated in
> > http://www.redhat.com/mirrors/LDP/HOWTO/IR-HOWTO-5.html ?
> 
> It's a bit dangerous to update the HOWTO for a development version of
> Linux-IrDA if you ask me. Patch-2.2.13-irda23 reflects the IrDA code for
> the Linux-2.3 development. Yes, things have changed a lot, and they might
> be changed again!!! Lets make the modifications needed when Linux-2.4 is
> out, or if we get things as is into 2.2.15.
> 
> People who have followed this mailing list knows what to do: "irattach
> /dev/ttyS<x> -s 1" and using a dongle such as esi: "irattach /dev/ttyS<x>
> -d esi -s 1". Irmanager is obsolete for the latest patches.
> 
> .. and in /etc/conf.modules
> 
> # IrDA
> alias tty-ldisc-11 irtty
> alias char-major-161 ircomm-tty
> alias irda-dongle-0 tekram
> alias irda-dongle-1 esi
> ...

After a lot of trials, I realized that I didn't load the tekram module.
Thanks for your help.
In my case (obex), I need:
insmod irda
insmod irtty
insmod tekram

Peter




From walter.haidinger@gmx.at Thu, 23 Dec 1999 18:20:04 +0100 (CET)
Date: Thu, 23 Dec 1999 18:20:04 +0100 (CET)
From: Walter Haidinger walter.haidinger@gmx.at
Subject: [Linux-IrDA]Internal Asus P5A infrared connector supported?

Hi!

After spending some time with the IrDA subsystem I wonder if the internal
infrared connector of my Asus P5A mainboard (5-pin) is supported. Simple 
question: Is it? 

I'm running a 2.2.13 kernel (irda patched) which does not support the
Ali 1541 chipset yet. Is this necessary?

My S25 mobile phone never shows up in /proc/net/irda/discovery while all
modules (irtty, ircomm) load successfully. Also, irattach of the 0.9.5
irda-utils shows no error.

I'm somewhat lost now, so any hint is appreciated.
Thanks, Walter  

-- 
Walter Haidinger <walter.haidinger@gmx.at>
For further information, such as address, phone or PGP public key,
please refer to: http://members.kstp.at/wh/index.html






From drebes@inf.ufrgs.br Thu, 23 Dec 1999 19:56:10 -0200 (EDT)
Date: Thu, 23 Dec 1999 19:56:10 -0200 (EDT)
From: Roberto Jung Drebes drebes@inf.ufrgs.br
Subject: [Linux-IrDA]FIR chip on Armada 1700 doesn seem to be SMC

Hello there,

I have bought a Armada 1700 notebook, the actual model is
6233/T/4000/D/M/1, which means it is the simpler model (a PII 233).

There are FIR windows drivers for it on Compaqs web site, so I downloaded
it to get more info on the FIR chip it uses.

Altough the page says it uses a SMC chip, and the Win drivers have a
smc_inst.inf file, which contains registry keys to set a smc chip at 

;               - Fast IR base = 0x100
;               - DMA channel = 0
;               - Serial IR base = 0x3E8 (COM3)

I had no success using the ir_utils package to find the smc chip. biosdump
tells me only about a generic ir port at com3, and even if i put FirBase =
0x100 in the ir_utils.ini file, I get no success (I've tried using these
utilities in the "safe mode command prompt only" option of windows.

By the other side, I 've successfully used the port in SIR mode, to
establish a ppp connection to a Palm III and to sync it, using pppd and
pilot-xfer.

Windows started showing ratees up to 4Mbps in the IrDA control panel, but
I have no devices to test it with, so I cannot be sure wheter it really is
supporting FIR mode in windows.


You may wonder why I wan to set the FIR support if I have no devices to
use it. First, to test it. Second, because whenever I find someone using
sa device in FIR mode, I can try to use it. :)

If you have *any* suggestion, let me know. I've checked the list archives,
but I do not get the success people get with findchip in the Armada 1700.

Perhaps the FIR chip is broken. Is it possible?

Thanks in advance, and "feliz natal" to everyone.

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/





From dagb@cs.uit.no 24 Dec 1999 00:07:29 +0100
Date: 24 Dec 1999 00:07:29 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]The Open-OBEX Project

Hi,

The Open-OBEX Project just got online!! Please have a look at:

	http://www.ravioli.pasta.cs.uit.no/open-obex/

Some software is already out, but you'll have to wait a few days for the
easy to install RPM's. Have fun!

Merry Christmas to everybody!!!

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From noguchi@npost1.netspace.or.jp Sat, 25 Dec 1999 12:48:04 +0900
Date: Sat, 25 Dec 1999 12:48:04 +0900
From: Hiroshi Noguchi noguchi@npost1.netspace.or.jp
Subject: [Linux-IrDA]Discovering maybe work on LinuxPPC ?

Hi.

I thought to examine whether protocol stacks work,
and tried connecting between Linux/i386-IrDA machine
via an actual serial port.

I connected two machines via cross-wired serial cable:

<host #1>
  machine: laptop PC
  system:  Linux/i386 - kernel 2.2.13 & irda-utils-0.9.5

  # irmanager -d 1      (but /etc/irda/* not exists)
  # irattach /dev/ttyS0 (COM1: actual serial port)

<host #2>
  machine: PowerBook G3 233/14" (Wallstreet)
  system:  Linux/ppc - kernel 2.2.14pre & irda-utils-0.9.5

  # irmanager -d 1      (/etc/irda/* not exists)
  # irattach /dev/ttyS0 (modem/serial port)

As result, irdadump seems to work.
Both hosts detected the another host.

Continuously, I tried IrLAN.
On both hosts, involked "modprobe irlan" and could see "irlan0"
with ifconfig.

But, assigning IP address to irlan0, Linux/i386 machine hanged up...
LinuxPPC machine did not hang up.


Because discovering did work with serial port and formerly failed
with PowerBook's built-in IR-port, I think that transceiver/receiver of
PowerBook's IR-port cannot be activated with simple serial port drivers
and they are activated via special output ports.


--------------------------------
Hiroshi Noguchi
E-mail: noguchi@npost1.netspace.or.jp
http://homepage1.nifty.com/driver/




From cg@suse.de Thu, 23 Dec 1999 19:13:19 +0100 (MET)
Date: Thu, 23 Dec 1999 19:13:19 +0100 (MET)
From: Carsten Gross cg@suse.de
Subject: [Linux-IrDA]Internal Asus P5A infrared connector supported?

Hi,

Am 23.12.99 um 18:20 schrieb Walter Haidinger:
> After spending some time with the IrDA subsystem I wonder if the internal
> infrared connector of my Asus P5A mainboard (5-pin) is supported. Simple 
> question: Is it? 

I am using the connector on an ASUS P2B and it works flawlessly. Perhaps the
connector is connected wrong? You should also enable "Infrared" in the BIOS
setup for the corrosponding serial interface. 

If it doesn't work then, you can also try to look on the infrared LED with a
CCD camera. The IR LDE should be seen as blinking in the camera after the
drivers are loaded (and the irmanager is started on older versions).

Regards,

   Carsten

-- 
Carsten Groß                                                   SuSE GmbH
cg@suse.de                                          Schanzäckerstraße 10
privat: Kappengasse 13, 90402 Nürnberg                    90443 Nürnberg





From portege@guldan.demon.nl Mon, 27 Dec 1999 11:34:37 +0100
Date: Mon, 27 Dec 1999 11:34:37 +0100
From: Robert Blacquiere portege@guldan.demon.nl
Subject: [Linux-IrDA]irda and ppp

Hello,

If got a siemens S25 working with irda more or less because 
ppp doesn't talk to the ircomm device? does any of you know
a cure for this? I use irda from the 2.2.13 kernel with no 
patches this because toshoboe is broken in the patched 
versions (??) irda utils are 0.9.4 and ppp is 2.3.10 running
on slackware 7. 
the logs show ppp0 <--> /dev/ircomm and then the line keeps up
but the ppp0 interface does not come up, and a strace off the 
pppd process loops with these messages:

select(8, [7], NULL, [7], {2, 10000})   = 0 (Timeout)
gettimeofday({946290801, 806556}, NULL) = 0
time([946290801])                       = 946290801
getpid()                                = 2136
rt_sigaction(0xd, 0xbffff364, 0xbffff2d8, 0x8, 0xd) = 0
send(5, "<31>Dec 27 11:33:21 pppd[2136]: "..., 120, 0) = 120
rt_sigaction(0xd, 0xbffff368, 0, 0x8, 0xd) = 0
write(7, "\377\3\300!\1\1\0\30\2\6\0\0\0\0"..., 28) = 28
gettimeofday({946290801, 825974}, NULL) = 0
gettimeofday({946290801, 828848}, NULL) = 0
read(7, 0x8071220, 1504)                = -1 EAGAIN (Resource temporarily unavailable)
rt_sigprocmask(0, 0, 0x806dc7c, 0x8, 0) = 0
rt_sigprocmask(0, 0xbffff84c, 0, 0x8, 0) = 0
rt_sigprocmask(0x1, 0xbffff84c, 0, 0x8, 0x1) = 0
gettimeofday({946290801, 843460}, NULL) = 0
select(8, [7], NULL, [7], {2, 982514})  = 0 (Timeout)
gettimeofday({946290804, 834103}, NULL) = 0
time([946290804])                       = 946290804
getpid()                                = 2136
rt_sigaction(0xd, 0xbffff364, 0xbffff2d8, 0x8, 0xd) = 0
send(5, "<31>Dec 27 11:33:24 pppd[2136]: "..., 120, 0) = 120
rt_sigaction(0xd, 0xbffff368, 0, 0x8, 0xd) = 0
write(7, "\377\3\300!\1\1\0\30\2\6\0\0\0\0"..., 28) = 28
gettimeofday({946290804, 835156}, NULL) = 0
gettimeofday({946290804, 835226}, NULL) = 0
read(7, 0x8071220, 1504)                = -1 EAGAIN (Resource temporarily unavailable)
rt_sigprocmask(0, 0, 0x806dc7c, 0x8, 0) = 0
rt_sigprocmask(0, 0xbffff84c, 0, 0x8, 0) = 0
rt_sigprocmask(0x1, 0xbffff84c, 0, 0x8, 0x1) = 0
gettimeofday({946290804, 835586}, NULL) = 0
select(8, [7], NULL, [7], {2, 999570} <unfinished ...>

does any know a cure or has any idees?

Greetings

Robert





From dagb@cs.uit.no 27 Dec 1999 11:54:17 +0100
Date: 27 Dec 1999 11:54:17 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]irda and ppp

Robert Blacquiere <portege@guldan.demon.nl> writes:

> a cure for this? I use irda from the 2.2.13 kernel with no 
> patches this because toshoboe is broken in the patched 
> versions (??)

Which patched version? Are you saying that toshoboe is broken in
patch-2.2.13-irda23? Did you start it like this:

modprobe toshoboe
ifconfig irda0 up
echo 1 > /proc/sys/net/irda/discovery

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From gun2019@gmx.net Mon, 27 Dec 1999 13:46:15 +0100 (MET)
Date: Mon, 27 Dec 1999 13:46:15 +0100 (MET)
From: gun2019@gmx.net gun2019@gmx.net
Subject: [Linux-IrDA]dongle or not?

Hi,

still confused with my Actisys 210L.
This is connected to a 5pin IrDA header on my
Asus P2BF board.
Is it a dongle or not?
In the docs and kernel help it is pointed out
that a dongle is connected to a 9pin serial
interface. This is not the case.
Is it a dongle, is 
irattach /dev/ttyS1 -d actisys -s 1 correct?
is it not a dongle, is
irattach /dev/ttyS1 -s 1 correct?

anyway, have no success with both versions.
Using 2.2.13 with irda23
made /dev/ircomm0 and /dev/ircomm1
and ldisc and ircomm-tty in conf.modules, and
the actisys module.
PC-BIOS is set to use COM2 as IR-Device.

Irdadump shows nothing.
Getting all Irda-Kernel-Messages, all modules loaded, but no
discovery-Message (or is this obsolete since the newest patches)

Then, after a while getting a kernel message
something like "assertion failure...irdadevice.c...line 178",
repeated many times. (This is new since a few days i played with that,
heck, don't know, i think since i installed newer irda-utils)
(i'm not at home at the moment so i haven't the complete message, but
i can post it this evening if this would be useful)

With an unpatched 2.2.13-13, irdadump shows me the "Siemens S25" and my
box,
and the kernel reacts on moving the s25 away from the "dongle" (???) 
but no connection possible.

Carsten (cg@suse.de), how do you use the actisys? as dongle? say, loading
the actisys a module? (Got mine from "Schiwi", do we have the same 210L ?)

I hoped to go further with a 2.3.xx kernel and the irda patch for that.
Tried to make a 2.3.34...this bitch won't compile (error in main) after
menuconfig. Other guys from irc compiled it somehow but it hangs after
boot.

I'm stuck.

Heiko





From dagb@cs.uit.no 27 Dec 1999 14:12:11 +0100
Date: 27 Dec 1999 14:12:11 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]dongle or not?

gun2019@gmx.net writes:

> still confused with my Actisys 210L.
> This is connected to a 5pin IrDA header on my
> Asus P2BF board.
> Is it a dongle or not?
> In the docs and kernel help it is pointed out
> that a dongle is connected to a 9pin serial
> interface. This is not the case.

Some dongles use a 9pin serial interface, while others use a PS/2 style
interface. 

> Is it a dongle, is 
> irattach /dev/ttyS1 -d actisys -s 1 correct?
> is it not a dongle, is

It is a dongle, but it controls the speed itself, so you don't need to
enable any kernel drivers for it.

> irattach /dev/ttyS1 -s 1 correct?

Yes this is correct, but only if you're using irda-utils-0.9.5. If you are
using 0.9.4, then you must also do "ifconfig irda0 up" and "echo 1 >
/proc/sys/net/irda/dicovery"

> anyway, have no success with both versions.
> Using 2.2.13 with irda23
> made /dev/ircomm0 and /dev/ircomm1
> and ldisc and ircomm-tty in conf.modules, and
> the actisys module.
> PC-BIOS is set to use COM2 as IR-Device.
> 
> Irdadump shows nothing.
> Getting all Irda-Kernel-Messages, all modules loaded, but no
> discovery-Message (or is this obsolete since the newest patches)
> 
> Then, after a while getting a kernel message
> something like "assertion failure...irdadevice.c...line 178",
> repeated many times. (This is new since a few days i played with that,
> heck, don't know, i think since i installed newer irda-utils)
> (i'm not at home at the moment so i haven't the complete message, but
> i can post it this evening if this would be useful)

Thought I have made a fix for this already. Maybe it was made after
-23. Sound like your using 0.9.4 and haven't done "ifconfig irda0 up". 

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From portege@guldan.demon.nl Mon, 27 Dec 1999 16:07:25 +0100
Date: Mon, 27 Dec 1999 16:07:25 +0100
From: Robert Blacquiere portege@guldan.demon.nl
Subject: [Linux-IrDA]irda and ppp

What i see is: one thing
the pppd demon starts and goes in to a endless loop trying to communicate
thru the irda/ircomm interface, but it can't speak to the irda modem.
Mayby it's the same as you but i don't know.


On Mon, Dec 27, 1999 at 12:19:01PM -0200, Roberto Jung Drebes wrote:
> 
> For me, what happened was that I could not authenticate the ppp on the
> other side, and so could not set a IP, and then the interface wouldn't
> come up. Have you checked this?
> 
> On Mon, 27 Dec 1999, Robert Blacquiere wrote:
> 
> 
> --
> Roberto Jung Drebes <drebes@inf.ufrgs.br>
> Porto Alegre, RS - Brasil
> http://www.inf.ufrgs.br/~drebes/





From s.p.helma@earthling.net Mon, 27 Dec 1999 17:07:48 +0100
Date: Mon, 27 Dec 1999 17:07:48 +0100
From: Stephan Helma s.p.helma@earthling.net
Subject: [Linux-IrDA]Help! Cannot persuade my Actisys+ dongle to work...

Hi,

I tried hard, but until now without any success.

BTW I use a Debian 2.1 (glibc6.0) system.

I compiled the 2.2.12 kernel with the patch-2.2.12-irda3 with the
following option:. (I cannot update to the 2.2.13 due to other
circumstances.)
	
	CONFIG_IRCOMM=m
	CONFIG_IRDA_OPTIONS=y

	CONFIG_IRDA_CACHE_LAST_LSAP=y

	CONFIG_IRTTY_SIR=m
	CONFIG_IRPORT_SIR=m

	CONFIG_DONGLE=y
	CONFIG_ACTISYS_DONGLE=m

	(from http://www.snafu.de/~wehe/IR-HOWTO-3.html)
	CONFIG_SYSCTL=y
	CONFIG_SERIAL=m

During the boot sequence setserial is called with "-b /dev/ttyS1 irq 3
port 0x2F8 skip_test autoconfig session_lockout".

I got and installed the irda-utils (0.9.5) package compiled for Debian
(slink) and irmanager is called during boot up. Then I found in
http://www4.pasta.cs.uit.no/pipermail/linux-irda/1999-November/000565.html 
that the new 0.9.5 doesn't work with the 2.2.12 kernel. So I fetched
the irda-utils-0.9.4 package, compiled and installed it.

The install script produces the devices as follows:
	mknod /dev/ircomm0 c 60 64
	mknod /dev/ircommnew0 c 161 0
	mknod /dev/irlpt0 c 161 10
and adds the following entries into /etc/conf.modules:
	alias tty-ldisc-11 irtty
	# The following is for new kernel.
	alias char-major-161 ircomm-tty
	# The following is for old kernel.
	alias char-major-60 ircomm_tty
(I changed the last ircomm_tty to ircomm-tty.)

Now I can load everything with irmanager and /etc/irda/driver
(containing "irattach /dev/ttyS1 -d actisys+").

At the first glance everything seems to be ok:

lsmod:
	ircomm-tty             15848   1  (autoclean)
	ircomm                  5276   0  (autoclean) [ircomm-tty]
	actisys                  772   1  (autoclean)
	irtty                   2880   2  (autoclean)
	irda                   63809   1  [ircomm-tty ircomm actisys irtty]
	serial                 20048   1  (autoclean)

cat /etc/log/syslog:
	Dec 27 16:54:39 frosch irmanager: executing: 'echo frosch > /proc/sys/net/irda/devname'
	Dec 27 16:54:39 frosch irmanager: + 0.1 Fri Jul 25 11:45:26 1997 Dag Brattli
	Dec 27 16:54:39 frosch irmanager: + 0.1 Fri Jul 25 11:45:26 1997 Dag Brattli
	Dec 27 16:54:39 frosch irattach: Serial connection established.
	Dec 27 16:54:39 frosch kernel: IrDA: Registered device irda0 
	Dec 27 16:54:40 frosch kernel: IrDA: Initializing ACTiSYS dongle! 

but nothing in "/proc/net/irda/discovery"
head /proc/net/irda/*:
	==> /proc/net/irda/discovery <==
	IrLMP: Discovery log:


	==> /proc/net/irda/ircomm <==
	Instance 0:

	==> /proc/net/irda/irda_device <==

	irda0,  binding: irda0 <-> ttyS1 <-> actisys
	        UP RUNNING SIR PIO DONGLE 
	        bps     maxtt   dsize   winsize addbofs mintt   ldisc
	        9600    50      2048    7       0       5000    40

	==> /proc/net/irda/irias <==
	LM-IAS Objects:
	name: Device, id=21314
	 - Attribute name: "DeviceName", value[IAS_STRING]: "Linux"


	==> /proc/net/irda/irlap <==
	irlap0 <-> irda0 state: LAP_NDM
	  caddr: 0x52, saddr: 0xc2ba13a2, daddr: 0x000000
	  win size: 0, win: 0, win bytes: 0, bytes left: 0
	  tx queue len: 0 win queue len: 0 rbusy: FALSE
	  retrans: 0 vs: 0 vr: 0 va: 0
	  qos   bps     maxtt   dsize   winsize addbofs mintt   ldisc   comp
	  tx    9600    0       64      0       11      0       0       
	  rx    9600    0       0       0       0       0       0       

	==> /proc/net/irda/irlmp <==
	Unconnected LSAPs:
	lsap state: LSAP_DISCONNECTED, slsap_sel: 0x0, dlsap_sel: 0xff, (IrIAS srv)

	Registred Link Layers:
	lap state: LAP_STANDBY, saddr: 0xc2ba13a2, daddr: 0xffffffff, 

	Connected LSAPs:


	==> /proc/net/irda/irttp <==

I tried to connect to my Psion5 with the psion5 program from
irda-utils but without success (only timeouts). I wanted to log into
my Psion machine with getty over the IR link - without success, too.

The following caught my attention: When I stop the irmanager I get the 
following entries in the syslog:
	Dec 27 17:01:15 frosch irmanager: got SIGTERM or SIGINT 
	Dec 27 17:01:16 frosch kernel: irtty_set_dtr_rts(), error doing ioctl! 

Does anybody know what I am doing wrong?? Can anybody help?

Stephan




From dagb@cs.uit.no 27 Dec 1999 17:56:00 +0100
Date: 27 Dec 1999 17:56:00 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]irda and ppp

Robert Blacquiere <portege@guldan.demon.nl> writes:

> What i see is: one thing
> the pppd demon starts and goes in to a endless loop trying to communicate
> thru the irda/ircomm interface, but it can't speak to the irda modem.
> Mayby it's the same as you but i don't know.

Yes, it will do this if the link is broken. pppd will give up and retry ...

What does irdadump say? ifconfig or "cat /proc/net/dev"

BTW: No need to run pppd or ircomm until you have the discovery working.

Could you please confirm if you are using irda-utils-0.9.5?

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From dagb@cs.uit.no 27 Dec 1999 18:16:52 +0100
Date: 27 Dec 1999 18:16:52 +0100
From: Dag Brattli dagb@cs.uit.no
Subject: [Linux-IrDA]FIR support for NSC chipsets

Hi,

After some Xmas hacking, I got FIR (4Mbps) support working for the NSC '338
chipset in addition to the '108. In other words this means that we now have
FIR support for (all?) IBM Thinkpads, some HP Omnibooks (OB 5700,?),
others?  Please reply if you know about machines using NSC (National) IrDA
chipsets.

Will release a new patch when I have fixed and tested the code a bit
more. Should be ready in a week or so.

-- Dag

-- 
   / Dag Brattli                   | The Linux-IrDA Project               /
  // University of Tromsoe, Norway | Infrared communication for Linux    //
 /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///




From gun2019@gmx.net Mon, 27 Dec 1999 19:35:52 +0100
Date: Mon, 27 Dec 1999 19:35:52 +0100
From: Bashar Teg gun2019@gmx.net
Subject: Success! was: [Linux-IrDA]dongle or not?

On Mon, Dec 27, 1999 at 02:12:11PM +0100, Dag Brattli wrote:
[snip]

> Thought I have made a fix for this already. Maybe it was made after
> -23. Sound like your using 0.9.4 and haven't done "ifconfig irda0 up". 
> 
> -- Dag
> 
 really thought i *have* the latest irda-utils :)
 got the 0.9.5 and thats it.
 Now this is a stable connection.
 thanks.

 Heiko




From portege@guldan.demon.nl Tue, 28 Dec 1999 09:49:24 +0100
Date: Tue, 28 Dec 1999 09:49:24 +0100
From: Robert Blacquiere portege@guldan.demon.nl
Subject: [Linux-IrDA]irda and ppp

I have a open connection to my provider using dip and switch over
to ppp connection. Because pppd/chat don't talk with my phone??
With dip i get a connection and after it finishes it starts pppd
 pppd -detach modem crtcts defaultroute etc.
but this doesnot finish. So i have a open connection to my phone
it all works but cant setup a ppp connection. :-(

Greetings

Robert

On Mon, Dec 27, 1999 at 05:56:00PM +0100, Dag Brattli wrote:
> Robert Blacquiere <portege@guldan.demon.nl> writes:
> 
> > What i see is: one thing
> > the pppd demon starts and goes in to a endless loop trying to communicate
> > thru the irda/ircomm interface, but it can't speak to the irda modem.
> > Mayby it's the same as you but i don't know.
> 
> Yes, it will do this if the link is broken. pppd will give up and retry ...
> 
> What does irdadump say? ifconfig or "cat /proc/net/dev"
> 
> BTW: No need to run pppd or ircomm until you have the discovery working.
> 
> Could you please confirm if you are using irda-utils-0.9.5?
> 
> -- Dag
> 
> -- 
>    / Dag Brattli                   | The Linux-IrDA Project               /
>   // University of Tromsoe, Norway | Infrared communication for Linux    //
>  /// http://www.cs.uit.no/~dagb    | http://www.cs.uit.no/linux-irda/   ///





From johan@Lhasa.NU Wed, 29 Dec 1999 19:43:21 +0100
Date: Wed, 29 Dec 1999 19:43:21 +0100
From: Johan Romin johan@Lhasa.NU
Subject: [Linux-IrDA]IrComm problems

hi!

I´ve been trying to get my laptop to communicate with my mobile phone.
I´m using irda-utils0.9.5 and 2.2.13 and irda 12 patch.
the errors i get when I try to insert irtty module is the following:
I realy hope someone can help me out with this..
Saidin:/home/johan# insmod irda            
Saidin:/home/johan# insmod ircomm
Saidin:/home/johan# insmod ircomm-tty
Saidin:/home/johan# insmod irtty
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol
irda_device_dongle_cleanup
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol irda_device_set_media_busy_
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol infrared_mode              
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol irlap_close
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol irda_task_next_state
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol irda_task_execute
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol irda_qos_bits_to_value_R96a
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol hashbin_remove_Ra730e7eb   
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol irda_init_max_qos_capabilie
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol hashbin_new_Rb3d26312      
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol irda_task_delete
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol irda_device_dongle_init
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol irlap_open
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol hashbin_delete_Rb7b5c901   
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol hashbin_insert_R2fcbdcca   
/lib/modules/2.2.13/misc/irtty.o: unresolved symbol async_unwrap_char_R8706d6fd

-- 
        /Johan
___________________________________________
This ought to be filled with personal stuff




From walter.haidinger@gmx.at Thu, 30 Dec 1999 01:33:41 +0100 (CET)
Date: Thu, 30 Dec 1999 01:33:41 +0100 (CET)
From: Walter Haidinger walter.haidinger@gmx.at
Subject: [Linux-IrDA]Asus IRM-100 adapter supported?

Hi!

Well, finally I know which infrared adapter I own...

It is the Asus IRM-100 infrared adapter. Connected to the on-board 5-pin
connector on my P5A mainboard. No other parts but the 5-wire cable and
the 1.25" square circuit board which hosts the IR diodes and four small
mounting holes. It's obviously an OEM product.

Works under Win98 with standard IrDA drivers but so far I had no success
under Linux. :-(
 
Regardless of what I try, nothing shows up in /proc/net/irda/discovery
but: 00:07:48.130331 xid:cmd 00b8a757 > ffffffff S=6 s=* banshee hint=0500 
[PnP Computer ] (23) 

Unfortunately, my mobile phone (Siemens S25) isn't discovered.

BIOS, IRQ, port-settings are all ok, IMHO. Also irda-utils-0.9.5 as well
as patched 2.2.13 kernel compiled and work without any error messages.

Now I wonder: Is this adapter supported at all? 

Thanks for any replies, 
Walter

-- 
Walter Haidinger <walter.haidinger@gmx.at>
For further information, such as address, phone or PGP public key,
please refer to: http://members.kstp.at/wh/index.html





From Gerald.Teschl@esi.ac.at Thu, 30 Dec 1999 12:34:01 +0100
Date: Thu, 30 Dec 1999 12:34:01 +0100
From: Gerald Teschl Gerald.Teschl@esi.ac.at
Subject: [Linux-IrDA]IRDA on an ASUS L7300

Hi out there,

I have an ASUS L7300 laptop

http://www.mat.univie.ac.at/~gerald/laptop/asus.html

and I want to get a network connection between two laptops via irda running. I use RedHat 6.1 with a
2.2.13
(no irda patches yet).

According to the Win98 driver I have a winbond controller sitting at /dev/ttyS1.

First of all the IR port is not detected correctely by the kernel. setserial /dev/ttyS1 says
"/dev/ttyS1,
UART: 8250, Port: 0x02f8, IRQ: 3" rather than "UART: 16550A" (according to a BIOS dump).
Is this something I should worry about?

Next I tried to use the W83977AF module, which did not work. I had a look at the kernel source and
noticed that
the irq/io stuff is hardcoded into the module. I rewrote the source so that they can be set via
paramters (I will
mail the patch to this list once I've installed the latest irda patch). Still it did not work. After
a little debugging I found
out that the module gives up at the "version check". I uncommented the code which checks for the
version of the
controller and now the module loads fine. In addition, I get an irda0 interface which I can
configure via ifconfig.

Any suggestions? How can I test it without a second laptop/ir printer/phone. I tried to use the
remote control
of my stereo and read some bytes from the device, but to no avail.

Any help is appreciated,
Gerald