OK, Here goes:

18:45:25.630000 xid:cmd ffffffff < 00001482 S=6 s=0 (14)
This is a discovery frame, the ffffffff denotes a broadcast address, the XID frame type tells you it is a discovery frame. The S tells you the total number of discovery frames that will be sent, the s tells you which one this is. The device being discovered can randomly pick which of the discovery frames it replies to, and it only has to reply to one.

18:45:25.630000 xid:rsp 2a526f6a > 00001482 S=6 s=0 Linux hint=8420 [ Computer IrOBEX ] (22)
This is the empegs response, the hint bits tell you that it MAY be a computer that supports OBEX, but it is only a hint

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.
The further 5 discovery frames are due to the fact that the PPC said it would send 6, and there may be more devices out there waiting to respond later in the discovery sequence.

Ok, here it looks like the Empeg and the PocketPC are negotiating a connection speed.
They are actually negotiating all of the connection parameters, not just speed, but as the link appears to work that should all be correct.

18:45:26.890000 rr:cmd < ca=60 pf=1 nr=0 (2)
Not sure what this is...
Every frame that says rr after the time is a keep alive packet, it doesn't matter if it is a cmd or rsp frame, their function is the same.

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

Now the PocketPC issues a CONN_CMD to lsap 12 (OBEX), and gives the Empeg 4 (byte?/packet?) credits to respond with.
Correct, and all credits are given in packets, so the Empeg can now send up to 4 TTP packets before needing more credits.

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

Now it just sends keepalives forever. Does it look like the PocketPC is not getting the fact that it has credits to send?
As this stalls at exactly the same place as before (just after the TTP connect) I am guessing that there were probably credits sent before just the old version of IrDA dump wasn't showing them. My guess is that something now needs to be triggered to start the OBEX connect, as that would be the next frame I would expect to see. So I guess the questions are how are you starting the link? calling some IrDA function or calling some OBEX function, if it is an IrDA function, is there some callback that you need to register for so you know the link is up and can send the OBEX connect? If it is an OBEX function you may be fighting broken M$ software

Also one other thing that worries me is that all responses from the Empeg are shown in the log twice:
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)
If this is just being added to the log by two differant levels of the stack then thats fine, we can just ignore one, if it is actually being echoed by the PPC then you could have a very broken implentation on your hands, to verify this can you take a log when using the Palm, just the discovery phase will be all I need to see.

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!
I am just happy to be able to give something back.