Scott Dattalo <[EMAIL PROTECTED]> writes:
> Let me ask the question and then describe the situation. What kind of
> response is "connect()" expecting from the peer? (I know the answer is: it
> depends... but) I'm getting an ENETUNREACH error when I call connect()
> after I've called
>
> fd = socket(AF_IRDA, SOCK_STREAM, 0);
>
> getsockopt(fd, SOL_IRLMP, IRLMP_ENUMDEVICES, buf, &len);
>
> setsockopt(fd, SOL_IRLMP, IRTTP_MAX_SDU_SIZE, &mtu, sizeof(mtu))
You should not use this setsockopt() since it's not required in the kernel
you are using, and not even allowed in the latest kernels.
Previously this was use to select a sequenced packet service instead of a
streaming protocol. But in the latest patches, you select this using
SOCK_STREAM or SOCK_SEQPACKET.
> connect(fd, (struct sockaddr*) &peer, sizeof(struct sockaddr_irda))
>
>
> These are the sequence of calls from (a slightly modified) irdaspray.c in
> the irda-utils-0.9.4 distribution. The peer is a Palm Pilot.
BTW: You should upgrade your irda-utils!
> I've traced back through the irda source in the kernel and the only thing
> I could see that could produce the ENETUNREACH error is the
> irda_find_lsap_sel() function. Which I take to mean that the Linux box is
> trying to find an LSAP selector for a service that's not present in the
> pilot? If so, then who's in the bad; the Linux app for not requesting the
> proper LSAP-SEL or the pilot app for not initializing the IAS properly?
>
> The key section from irdadump that shows the failure is here:
>
> 00:11:55.518569 xid:cmd b788a9ef > ffffffff S=6 s=4 (14)
> 00:11:55.598525 xid:rsp b788a9ef < d914b15c S=6 s=4 PALMDEMO hint=0200 [
> PDA/Palmtop ] (24)
> 00:11:55.668592 xid:cmd b788a9ef > ffffffff S=6 s=5 (14)
> 00:11:55.819873 xid:cmd b788a9ef > ffffffff S=6 s=* localhost hint=0500 [
> PnP Computer ] (25)
> 00:11:55.820079 snrm:cmd ca=fe pf=1 b788a9ef > d914b15c new-ca=62 (32)
> 00:11:55.968614 ua:rsp ca=62 pf=1 b788a9ef < d914b15c (31)
> 00:11:56.218572 rr:cmd > ca=62 pf=1 nr=0 (2)
> 00:11:56.248629 rr:rsp < ca=62 pf=1 nr=0 (2)
> 00:11:56.248813 i:cmd > ca=62 pf=1 nr=0 ns=0 LM slsap=5a dlsap=00
> CONN_CMD (6)
> 00:11:56.278598 i:rsp < ca=62 pf=1 nr=1 ns=0 LM slsap=00 dlsap=5a
> CONN_RSP (6)
> 00:11:56.278801 i:cmd > ca=62 pf=1 nr=1 ns=1 LM slsap=5a dlsap=00
> GET_VALUE_BY_CLASS: "PALMDEMO" "IrDA:TinyTP:LsapSel" (34)
> 00:11:56.330085 i:rsp < ca=62 pf=1 nr=2 ns=1 LM slsap=00 dlsap=5a
> GET_VALUE_BY_CLASS: No such class (6)
> 00:11:56.330334 i:cmd > ca=62 pf=1 nr=2 ns=2 LM slsap=5a dlsap=00 DISC
> (6)
> 00:11:56.358551 rr:rsp < ca=62 pf=1 nr=3 (2)
There is _no_ registered service with the name of "PALMDEMO" on the Pilot,
so this is not a Linux problem.
> Which shows that the 'GET_VALUE_BY_CLASS' is failing.
>
>
> I've got the 2.2.12 kernel (as built by the rh6.1 distribution) and
> irda-utils-0.9.4 . The Pilots are IIIx and a III.
Many of the problems you have described would be solved if you upgraded to
the latest IrDA patches (not the GVBC failure!). So please upgrade, if you
want me to help you further. You can find the latest code in
Linux-2.2.15-pre3 (Linux-2.2.14 + pre-patch-2.2.15-3). You'll find it at:
ftp://ftp.<country code>.kernel.org/pub/linux/kernel/v2.2/
and
ftp://ftp.<country code>.kernel.org/pub/linux/kernel/alan/2.2.15pre/
-- 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 - [EMAIL PROTECTED]
http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
