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))
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.
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)
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.
------
The situation: What I'm trying to do is to write an application for the
Pilot and for Linux that will maintain an IrDA connection between the two.
I got this working using Obex and the Exchange Manager (Palm's obex
wrapper). However, I've discovered that the pilot only implements one half
of the obex protocol; it implements PUT but not GET. Consequently, the
pilot can establish a connection with my Linux box, send a packet of data,
but not receive (OBEX) packets back. So to have a bi-directional
communication link I'd have to do something like this:
>From the pilot:
connect to Linux box
send packet
disconnect
>From the Linux box
connect to pilot
send response
disconnect
etc.
If it were only esthetics, I could live with this scenario. However, the
connection process takes time that impatient pilot users would rather
advoid.
So to get around these (perhaps perceived) problems, I've decided to go
one level beneath OBEX and talk to the TinyTP. I've got an application
that runs on the pilot and will send and receive data to and from another
pilot. But I can't duplicate this while talking to the Linux box. The
Linux box can 'see' the pilot (i.e. discovery succeeds), but it can't
'connect' to the pilot.
Scott
-----
Also, irdadump crashes while sniffing obex packets. Specifically,
22:45:53.998559 xid:cmd ffffffff < 0e057e49 S=6 s=* IA RD IrDA Developm
hint=8220 [ PDA/Palmtop IrOBEX ] (36)
22:45:54.048594 snrm:cmd ca=fe pf=1 b788a9ef < 0e057e49 new-ca=62 (32)
22:45:54.048811 ua:rsp ca=62 pf=1 b788a9ef > 0e057e49 (31)
22:45:54.048950 ua:rsp ca=62 pf=1 b788a9ef > 0e057e49 (31)
22:45:54.638585 rr:cmd < ca=62 pf=1 nr=0 (2)
22:45:54.638691 rr:rsp > ca=62 pf=1 nr=0 (2)
22:45:54.658606 i:cmd < ca=62 pf=1 nr=0 ns=0 LM slsap=01 dlsap=00
CONN_CMD (6)
22:45:54.658704 i:rsp > ca=62 pf=1 nr=1 ns=0 LM slsap=00 dlsap=01
CONN_RSP (6)
22:45:54.688603 i:cmd < ca=62 pf=1 nr=1 ns=1 LM slsap=01 dlsap=00
GET_VALUE_BY_CLASS: "OBEX" "IrDA:TinyTP:LsapSel" (30)
22:45:54.688758 i:rsp > ca=62 pf=1 nr=2 ns=1 LM slsap=00 dlsap=01
GET_VALUE_BY_CLASS: Success Integer: 51 (15)
22:45:54.715195 i:cmd < ca=62 pf=1 nr=2 ns=2 LM slsap=03 dlsap=51
CONN_CMD TTP credits=0(7)
22:45:54.715293 rr:rsp > ca=62 pf=1 nr=3 (2)
22:45:54.738593 rr:cmd < ca=62 pf=1 nr=2 (2)
22:45:54.738691 i:rsp > ca=62 pf=1 nr=3 ns=2 LM slsap=51 dlsap=03
CONN_RSP TTP credits=0(7)
22:45:54.759289 i:cmd < ca=62 pf=1 nr=3 ns=3 LM slsap=03 dlsap=51 TTP
credits=0
OBEX CONNECT len=7 ver=1.0 flags=0 mtu=4072 (12)
22:45:54.759405 rr:rsp > ca=62 pf=1 nr=4 (2)
22:45:54.778794 rr:cmd < ca=62 pf=1 nr=3 (2)
22:45:54.778883 i:rsp > ca=62 pf=1 nr=4 ns=3 LM slsap=51 dlsap=03 TTP
credits=1
OBEX SUCCESS (12)
22:45:54.809195 i:cmd < ca=62 pf=1 nr=4 ns=4 LM slsap=03 dlsap=51 TTP
credits=1
OBEX PUT final=0 len=0 Name=IR Ping.prc Lenght=8254 Description=IR
Ping custom=1819173736 (64)
22:45:54.809339 rr:rsp > ca=62 pf=1 nr=5 (2)
22:45:54.858596 rr:cmd < ca=62 pf=1 nr=4 (2)
22:45:54.858694 i:rsp > ca=62 pf=1 nr=5 ns=4 LM slsap=51 dlsap=03 TTP
credits=1
OBEX CONTINUE (8)
GLib-ERROR **: could not reallocate 134217728 bytes
aborting...
Aborted
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
