Re: [irda-users] help needed in analysing dump.

[Alan J. M. <ala...@ya...>]

In article news:200...@so..., Samuel Ortiz wrote:
> On Thu, Sep 14, 2006 at 09:14:39PM +0530, Harith George wrote:
>> Hi,
>>
>>  I am handling a new ir driver. But the driver is not yet stable
>> yet. Again as I am new to ir (and do not have access to the irDA
>> specs.) I am not able to analyse the dump properly.
>> irdadump exits when another board comes within range and it starts
>> transacting at 4 mbps. Could someone confirm that it is a problem
>> with driver itself.
> I can't tell you if your problem is driver related or not.
> From the irdadump output, connection is established correctly. Then
> you send an IAP request (asking for availability of some IrLAN
> service), get a positive answer, and right after that _your_ side
> disconnects.
>
That's not quite what I see, see below.

>> Also any pointers/ links to tutorials on analysing the irdadump
>> would be really appreciated.
> Well, I guess the IrDA specs and then watching the irdadump -b output
> would help quite a bit.
> There is also an excellent book about IrDA, "IrDA principles and
> protocols", from Charles D.Knutson:
> http://www.amazon.com/IrDA-Principles-Protocols-Library-Vol/dp/0975389203/sr=1-1/qid=1158275819/ref=pd_bbs_1/104-8590996-1490323?ie=UTF8&s=books
>
Yes, I can recommend it too.

So:
>> 00:01:41.633315 xid:cmd f9b13910 > ffffffff S=6 s=0 (14)
>>        ff 3f 01 10 39 b1 f9 ff ff ff ff 01 00 00
[...]
>> 00:01:42.211764 snrm:cmd ca=fe pf=1 f9b13910 > 7cec84a3 new-ca=44
>>        LAP QoS: Baud Rate=4000000bps Max Turn Time=500ms Data
>> Size=2048B Window Size=7 Add BOFS=0 Min Turn Time=10
>> 00us Link Disc=12s (33)
>>        ff 93 10 39 b1 f9 a3 84 ec 7c 44 01 02 3e 01 82
>>        01 01 83 01 3f 84 01 7f 85 01 ff 86 01 07 08 01
>>        07
>> 00:01:42.313226 ua:rsp ca=44 pf=1 f9b13910 < 7cec84a3
>>        LAP QoS: Baud Rate=4000000bps Max Turn Time=500ms Data
>> Size=2048B Window Size=7 Add BOFS=0 Min Turn Time=10
>> 00us Link Disc=12s (32)
>>        44 73 a3 84 ec 7c 10 39 b1 f9 01 02 3e 01 82 01
>>        01 83 01 3f 84 01 7f 85 01 ff 86 01 07 08 01 07
So a IrLAP connection is formed, both side have very similar
capabilities and the connection is at 4Mbps.

>> 00:01:42.314759 rr:cmd > ca=44 pf=1 nr=0 (2)
>>        45 11
>> 00:01:42.317847 i:rsp  < ca=28 pf=0 nr=0 ns=0 LM slsap=84 dlsap=23
>>        (2) 28 00
Eeeee!  The connection is using connection address 0x44 (per "new-ca=44"
in the SNRM frame above).  Where'd this frame come from!  Also it's not
valid; as it should be at least four bytes long.  Did it come from
another actual device -- which is also at sending at 4Mbps, or does the
hardware listen on 9.6kbps simultaneously.  Or is if a local software 
fault?

And unfortunately irdadump doesn't handle this well.  It's expecting a 
frame of length four, so it reads four bytes, even though it knows that 
it only received two!!  It can be seen in both cases that it used the 
latter two bytes come from the previous long frame.  The parse output 
"slsap=84 dlsap=23" uses the two bytes from the UA frame ("44 73 a3 84 
."), and below the "slsap=14 dlsap=00" comes from the CONN_CMD frame 
there "45 10 80 14 .".  It shouldn't really do that. :-,(  (I wonder if 
there's an easy way to set array bound on the it?)

>> 00:01:42.563006 rr:cmd > ca=44 pf=1 nr=0 (2)
>>        45 11
>> 00:01:42.566068 rr:rsp < ca=44 pf=1 nr=0 (2)
>>        44 11
>> 00:01:42.566157 i:cmd  > ca=44 pf=1 nr=0 ns=0 LM slsap=14 dlsap=00
>> CONN_CMD (6)
>>        45 10 80 14 01 00
>> 00:01:42.569033 i:rsp  < ca=28 pf=0 nr=0 ns=0 LM slsap=14 dlsap=00
>>        (2) 28 00
Eeek as above.

>> 00:01:42.570371 i:rsp  < ca=44 pf=1 nr=1 ns=0 LM slsap=00 dlsap=14
>> CONN_RSP (6)
>>        44 30 94 00 81 00
>> 00:01:42.570449 i:cmd  > ca=44 pf=1 nr=1 ns=1 LM slsap=14 dlsap=00
>> GET_VALUE_BY_CLASS: "IrLAN" "IrDA:TinyTP:LsapSel
>> " (31)
>>        45 32 00 14 84 05 49 72 4c 41 4e 13 49 72 44 41
>>        3a 54 69 6e 79 54 50 3a 4c 73 61 70 53 65 6c
>> 00:01:42.581426 i:rsp  < ca=44 pf=1 nr=2 ns=1 LM slsap=00 dlsap=14
>> GET_VALUE_BY_CLASS: Success Integer: 10 (15)
>>        44 52 14 00 84 00 00 01 42 34 01 00 00 00 10
So the local peer looks up IrLAN, and it is told that it's present on 
LSAP-SEL 0x00000010.

>> 00:01:42.581551 i:cmd  > ca=44 pf=0 nr=2 ns=2 LM slsap=14 dlsap=00
>>        DISC (6) 45 44 80 14 02 01
>> 00:01:42.584514 i:cmd  > ca=44 pf=1 nr=2 ns=3 LM slsap=11 dlsap=10
>> CONN_CMD TTP credits=16 MaxSduSize=1518 (12)
>>        45 56 90 11 01 00 90 04 01 02 05 ee
>> 00:01:42.589388 i:rsp  < ca=44 pf=0 nr=4 ns=2 LM slsap=10 dlsap=11
>> CONN_RSP TTP credits=1 MaxSduSize=1518 (12)
>>        44 84 91 10 81 00 81 04 01 02 05 ee
And a TinyTP connection is formed.

>> ** Message: recvfrom
Now is this actually irdadump quitting?  Does the communication continue 
on reagardless.

>From irdadump.c: [[
   len = recvfrom(fd, frame_buf->data, MAX_FRAME_SIZE, 0,
      (struct sockaddr *) &from, &fromlen);
   if (len < 0) {
      g_message("recvfrom");
      exit(-1);
   }
]]
Would there be a useful error code available there?  I wonder if its 
worth trying with an increased MAX_FRAME_SIZE?  (Though would the TinyTP 
MaxSduSize exchanged there mean we only ever get frames that big??)
-- 
Alan J. McFarlane
http://www.alanjmcf.me.uk/
Please follow-up in the newsgroup for the benefit of all.