I'm having problems talking to a device based on the mcp2150 chip.
I've already fixed a few issues and I'll send patches as soon as I've
sorted them out.
One issue (the final one I hope) left though. I think it's sending the
odd corrupt frame, but with a correct checksum.
18:58:52.659969 (0043.17 ms) i:rsp < ca=18 pf=1 nr=4 ns=4 LM slsap=04
dlsap=10 TTP credits=0 IrCOMM (28)
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
18:58:52.660012 (0000.04 ms) rr:cmd > ca=18 pf=1 nr=5 (2)
18:58:53.460839 (0800.83 ms) rr:cmd > ca=18 pf=1 nr=5 (2)
18:58:53.479013 (0018.17 ms) i:rsp < ca=18 pf=1 nr=4 ns=5 LM slsap=04
dlsap=10 TTP credits=16 (2)
18:58:54.260863 (0781.85 ms) rr:cmd > ca=18 pf=1 nr=5 (2)
18:58:54.279057 (0018.19 ms) rd:rsp < ca=0x18 pf=1 (2)
18:58:54.279090 (0000.03 ms) disc:cmd > ca=0x18 pf=1 (2)
18:58:54.780881 (0501.79 ms) disc:cmd > ca=0x18 pf=1 (2)
I believe the illegal frame is 189a - it's a received i:rsp but with no
content (and is confusing irdadump - but pay attention to the size of
the frame, not what it parses it as). Note that I've already modified
the code to drop the frame rather than incrementing nr in the hope that
the device would retransmit the correct frame, except that it didn't -
the connection is supposed to continue.
Is sending an empty i:rsp legal? There is an IRDA_ASSERT in
irlmp_link_data_indication that fails when this happens (as the skb->len
passed to irlmp_data_indication is 0).
The device works in Windows with IrComm2k < 2 which uses the Windows
irlap/irlmp stack. Any idea what it might be doing to deal with this
situation? Perhaps it's sending a rej:cmd? I don't see code to generate
one of these at the moment. I've tried not incrementing nr (as above)
but this didn't work.
Get latest updates about Open Source Projects, Conferences and News.