Hi Mark, I have some more information about the problem.

After upgrading to irdadump 0.9.15 (the Linux-IrDA maintainer told me to upgrade) I get different output when I am trying to beam. It seems that I am issuing credits when I connect, but I'm not sure if I'm issuing enough. Here is the output (with nested comments):

18:45:25.630000 xid:cmd ffffffff < 00001482 S=6 s=0 (14)
18:45:25.630000 xid:rsp 2a526f6a > 00001482 S=6 s=0 Linux hint=8420 [ Computer IrOBEX ] (22)
18:45:25.680000 xid:rsp 00001482 < 2a526f6a S=6 s=0 Linux hint=8420 [ Computer IrOBEX ] (22)


This is discovery, right? Does the ffffffff denote discovery? The Empeg tells me that it is a Linux Computer that supports IrOBEX, then the PocketPC confirms reception of the discovery packet...?

18:45:25.770000 xid:cmd ffffffff < 00001482 S=6 s=1 (14)
18:45:25.860000 xid:cmd ffffffff < 00001482 S=6 s=2 (14)
18:45:25.950000 xid:cmd ffffffff < 00001482 S=6 s=3 (14)
18:45:26.030000 xid:cmd ffffffff < 00001482 S=6 s=4 (14)
18:45:26.120000 xid:cmd ffffffff < 00001482 S=6 s=5 (14)
18:45:26.210000 xid:cmd ffffffff < 00001482 S=6 s=* Pocket_PC hint=8220 [ PDA/Palmtop IrOBEX ] (26)


Ok, I'm not sure why the PocketPC sends 5 more (discovery?) packets, but then it sends the information that it is a PocketPC supporting IrOBEX.

18:45:26.760000 snrm:cmd ca=fe pf=1 2a526f6a < 00001482 new-ca=60
LAP QoS: Baud Rate=115200bps Max Turn Time=500ms Data Size=2048B Window
Size=4 Add BOFS=0 Min Turn Time=5000us Link Disc=12s (32)
18:45:26.760000 ua:rsp ca=60 pf=1 2a526f6a > 00001482
LAP QoS: Baud Rate=115200bps Max Turn Time=500ms Data Size=2048B Window
Size=7 Add BOFS=0 Min Turn Time=5000us Link Disc=12s (31)
18:45:26.800000 ua:rsp ca=60 pf=1 00001482 < 2a526f6a
LAP QoS: Baud Rate=115200bps Max Turn Time=500ms Data Size=2048B Window
Size=7 Add BOFS=0 Min Turn Time=5000us Link Disc=12s (31)


Ok, here it looks like the Empeg and the PocketPC are negotiating a connection speed.

18:45:26.890000 rr:cmd < ca=60 pf=1 nr=0 (2)

Not sure what this is...

18:45:26.890000 rr:rsp > ca=60 pf=1 nr=0 (2)
18:45:26.900000 rr:rsp < ca=60 pf=1 nr=0 (2)


Keepalive packets?

18:45:26.910000 i:cmd < ca=60 pf=1 nr=0 ns=0 LM slsap=03 dlsap=00 CONN_CMD (6)
18:45:26.910000 i:rsp > ca=60 pf=1 nr=1 ns=0 LM slsap=00 dlsap=03 CONN_RSP (6)
18:45:26.920000 i:rsp < ca=60 pf=1 nr=1 ns=0 LM slsap=00 dlsap=03 CONN_RSP (6)
18:45:26.930000 i:cmd < ca=60 pf=1 nr=1 ns=1 LM slsap=03 dlsap=00 GET_VALUE_BY_CLASS: "OBEX" "IrDA:TinyTP:LsapSel" (30)
18:45:26.930000 i:rsp > ca=60 pf=1 nr=2 ns=1 LM slsap=00 dlsap=03 GET_VALUE_BY_CLASS: Success Integer: 12 (15)
18:45:26.940000 i:rsp < ca=60 pf=1 nr=2 ns=1 LM slsap=00 dlsap=03 GET_VALUE_BY_CLASS: Success Integer: 12 (15)
18:45:26.950000 i:cmd < ca=60 pf=1 nr=2 ns=2 LM slsap=03 dlsap=00 DISC (6)


Now the PocketPC is finding out the lsap address of IrOBEX, to which the Empeg replies: 12. The PocketPC confirms this.

18:45:26.950000 rr:rsp > ca=60 pf=1 nr=3 (2)
18:45:26.960000 rr:rsp < ca=60 pf=1 nr=3 (2)


Keepalive packets?

18:45:26.970000 i:cmd < ca=60 pf=1 nr=2 ns=3 LM slsap=01 dlsap=12 CONN_CMD TTP credits=4 (7)

Now the PocketPC issues a CONN_CMD to lsap 12 (OBEX), and gives the Empeg 4 (byte?/packet?) credits to respond with.

18:45:26.970000 rr:rsp > ca=60 pf=1 nr=4 (2)
18:45:26.980000 rr:rsp < ca=60 pf=1 nr=4 (2)


Keepalive packets?

18:45:27.000000 rr:cmd < ca=60 pf=1 nr=2 (2)

Not sure what this is...

18:45:27.000000 i:rsp > ca=60 pf=1 nr=4 ns=2 LM slsap=12 dlsap=01 CONN_RSP TTP credits=14 (7)
18:45:27.010000 i:rsp < ca=60 pf=1 nr=4 ns=2 LM slsap=12 dlsap=01 CONN_RSP (7)


The Empeg responds with a CONN_RSP, and gives the PocketPC 14 credits to begin. The PocketPC acks the connection.

18:45:27.020000 rr:cmd < ca=60 pf=1 nr=3 (2)

Again, not sure what this is.

18:45:27.020000 rr:rsp > ca=60 pf=1 nr=4 (2)
18:45:27.030000 rr:rsp < ca=60 pf=1 nr=4 (2)
18:45:27.050000 rr:cmd < ca=60 pf=1 nr=3 (2)
18:45:27.050000 rr:rsp > ca=60 pf=1 nr=4 (2)
18:45:27.060000 rr:rsp < ca=60 pf=1 nr=4 (2)


Now it just sends keepalives forever. Does it look like the PocketPC is not getting the fact that it has credits to send?

Aren't I lucky to have someone with detailed IrDA knowledge on the board. I really appreciate any insight you could give me on this problem!
_________________________
Mark Cushman