Note: This is a message I posted to the irda-users mailing list last night after working on Palantir CE for a bit. I'm re-posting it here just in case anyone with IrDA knowledge can provide some insight (Chimaera, you there?)

Greetings! First off, I would like to say thanks to Jean Tourrilhes and
Dag Brattli for Linux-IrDA and OpenOBEX. I have been using this
software for a unique application and I could not have done it without
their work.

I am running Linux-IrDA and OpenOBEX on an Empeg MP3 player (also known
as the Rio Car http://www.riocar.org/). The Empeg uses an ARM processor
and a custom kernel built from 2.2. I have written an IrOBEX listener
to recieve an OBEX object from a Palm device that contains a list of
songs to insert into the current playlist. Details and source code for
my application can be found at:

http://cushman.net/projects/palantir/

I have been using the default Palm libraries to send OBEX objects to the
Empeg, and it has been working flawlessly. My problem begins while I am
trying to rewrite my Palm application for the PocketPC platform. I have
copied source code for a simple OBEX sender from an article at Pocket PC
Developer Network:

http://www.pocketpcdn.com/articles/obex.html

The code I am using is the second example, called code2.cpp

http://www.pocketpcdn.com/articles/samples/obex/code2.cpp

When run, this code hangs at trying to initiate an OBEX session (I
believe). My kernel is a variant of 2.2 that has been custom-built for
the Empeg. I cannot upgrade to a newer version, but I do not believe
that my problem lies with Linux-IrDA. I can successfully transmit large
files in the same session and get the proper OBEX responses.

Here is an irdadump of the session with the PocketPC:

04:23:36.650314 xid:cmd ffffffff < 00001482 S=6 s=0 (14)
04:23:36.830231 xid:cmd ffffffff < 00001482 S=6 s=2 (14)
04:23:36.910240 xid:cmd ffffffff < 00001482 S=6 s=3 (14)
04:23:37.000248 xid:cmd ffffffff < 00001482 S=6 s=4 (14)
04:23:37.080392 xid:cmd ffffffff < 00001482 S=6 s=5 (14)
04:23:37.080909 xid:rsp 80389c4d > 00001482 S=6 s=5 Linux hint=8420 [
Computer I
rOBEX ] (22)
04:23:37.130235 xid:rsp 00001482 < 80389c4d S=6 s=5 Linux hint=8420 [
Computer I
rOBEX ] (22)
04:23:37.230306 xid:cmd ffffffff < 00001482 S=6 s=* Pocket_PC hint=8220
[ PDA/Pa
lmtop IrOBEX ] (26)
04:23:37.780517 snrm:cmd ca=fe pf=1 80389c4d < 00001482 new-ca=d4 (32)
04:23:37.781040 ua:rsp ca=d4 pf=1 80389c4d > 00001482 (31)
04:23:37.820254 ua:rsp ca=d4 pf=1 00001482 < 80389c4d (31)
04:23:37.910406 rr:cmd < ca=d4 pf=1 nr=0 (2)
04:23:37.910944 rr:rsp > ca=d4 pf=1 nr=0 (2)
04:23:37.920326 rr:rsp < ca=d4 pf=1 nr=0 (2)
04:23:37.930578 i:cmd < ca=d4 pf=1 nr=0 ns=0 LM slsap=03 dlsap=00
CONN_CMD (6)

04:23:37.931217 i:rsp > ca=d4 pf=1 nr=1 ns=0 LM slsap=00 dlsap=03
CONN_RSP (6)

04:23:37.940336 i:rsp < ca=d4 pf=1 nr=1 ns=0 LM slsap=00 dlsap=03
CONN_RSP (6)

04:23:37.950708 i:cmd < ca=d4 pf=1 nr=1 ns=1 LM slsap=03 dlsap=00
GET_VALUE_BY_
CLASS: "OBEX" "IrDA:TinyTP:LsapSel" (30)
04:23:37.951497 i:rsp > ca=d4 pf=1 nr=2 ns=1 LM slsap=00 dlsap=03
GET_VALUE_BY_
CLASS: Success Integer: 24 (15)
04:23:37.960365 i:rsp < ca=d4 pf=1 nr=2 ns=1 LM slsap=00 dlsap=03
GET_VALUE_BY_
CLASS: Success Integer: 24 (15)
04:23:37.970565 i:cmd < ca=d4 pf=1 nr=2 ns=2 LM slsap=03 dlsap=00 DISC (6)
04:23:37.971148 rr:rsp > ca=d4 pf=1 nr=3 (2)
04:23:37.980331 rr:rsp < ca=d4 pf=1 nr=3 (2)
04:23:37.991451 i:cmd < ca=d4 pf=1 nr=2 ns=3 LM slsap=01 dlsap=24
CONN_CMD TTP
credits=0(7)
04:23:37.992140 rr:rsp > ca=d4 pf=1 nr=4 (2)
04:23:38.000338 rr:rsp < ca=d4 pf=1 nr=4 (2)
04:23:38.020422 rr:cmd < ca=d4 pf=1 nr=2 (2)
04:23:38.020927 i:rsp > ca=d4 pf=1 nr=4 ns=2 LM slsap=24 dlsap=01
CONN_RSP TTP
credits=0(7)
04:23:38.030368 i:rsp < ca=d4 pf=1 nr=4 ns=2 LM slsap=24 dlsap=01
CONN_RSP (7)

04:23:38.040490 rr:cmd < ca=d4 pf=1 nr=3 (2)
04:23:38.041019 rr:rsp > ca=d4 pf=1 nr=4 (2)
04:23:38.050307 rr:rsp < ca=d4 pf=1 nr=4 (2)
04:23:38.070413 rr:cmd < ca=d4 pf=1 nr=3 (2)
04:23:38.070955 rr:rsp > ca=d4 pf=1 nr=4 (2)
04:23:38.080307 rr:rsp < ca=d4 pf=1 nr=4 (2)
04:23:38.100406 rr:cmd < ca=d4 pf=1 nr=3 (2)
04:23:38.100938 rr:rsp > ca=d4 pf=1 nr=4 (2)
04:23:38.110328 rr:rsp < ca=d4 pf=1 nr=4 (2)
04:23:38.130420 rr:cmd < ca=d4 pf=1 nr=3 (2)
04:23:38.130960 rr:rsp > ca=d4 pf=1 nr=4 (2)
04:23:38.140858 rr:rsp < ca=d4 pf=1 nr=4 (2)

The last three lines repeat until the connection is broken (by shutting
down the application on the PocketPC or breaking the physical connection).

It looks like the OBEX listener and the PocketPC are "arguing" with the
last three lines. I could not find any information (looked through
mailing lists, viewed header files for irdadump, googled) about the
format of irdadump. What do those last lines mean? If someone could
point me to a reference for values in the output of irdadump, I would
appreciate it. I am particularly interested in:

Definitions of xid, snrm, ua, rr, i (are these packet types?)
I am guessing cmd and rsp are command and response
Definitions of ca= pf= nr= (ca is Connection Address?)
Values of nr in rr:rsp and rr:cmd

Gees, I take a few days off to get married and I come back to this

OK, here are the some explanations for you:
xid = An IrDA discovery frame - ffffffff means it is sent to a broadcast address
snrm = Set normal response mode - this is telling the other device what connection settings it would like to use for the IrDA link.
ua = Un-numbered acknowledgement, sent to ack non-information frames (SNRMs for example)
rr = receiver ready, used to keep the IrDA link alive when not sending actual data.
i = Information frame
command and response guesses are coorect
ca = Connection address
pf = Poll Final bit, the low level IrDA stuff takes care of it and should be fine, if you need more info check out the IrLMP spec (I think)
nr = This is a sequencing number, it send back the number of the next frame it is expecting, so in this case the Pocket PC is waiting for frame 3 and the Empeg is waiting for frame 4.

So what could be the problem, it looks like when you do the TTP connect you do not give the Empeg any credits

04:23:37.991451 i:cmd < ca=d4 pf=1 nr=2 ns=3 LM slsap=01 dlsap=24
CONN_CMD TTP
credits=0(7)

so when the Empeg responds it doesn't give the PPC any credits

04:23:38.020927 i:rsp > ca=d4 pf=1 nr=4 ns=2 LM slsap=24 dlsap=01
CONN_RSP TTP
credits=0(7)

so the TTP link is up, but it cannot send the OBEX connect frame, as it has no credits to be able to send it, so the link will just sit there RRing unitl it gets disconnected, or one side decides to send credits (and then the other side will normally give some credits back). One of the things we do when we are running low on credits is to give the other device a credit in the hope it will send us some back.

Hope that helps, if you have further questions then let me know I should get round to them while I catch back up.

Congratulations on getting married! It's one of the best things that has happened to me (second to my son being born) and I hope you and your new wife a long and peaceful union.

Your one post has helped me understand the underlying details of IrDA better than researching for 2 or more days on the internet. I thank you for posting this, it's going to be a great help! Now if I could just get my Empeg back up and running.

I did get a reply from Jean on the irda mailing list, he just told me to upgrade the IrDA stack and to upgrade my version if irdadump. I can upgrade irdadump, and I will see if there is any difference in the output, but I don't think that backporting the IrDA stack for Linux from 2.4 to 2.2 will be something I will attempt. I am positive that it is something that I am doing wrong on the PocketPC side, since the Palm version of Palantir works perfectly every time, and you have given me someplace to start! Again, thank you very much!

Thanks for the congrats, It certainly feels good to be married to her, and it lets everyone else know how important she is to me.

No problem with posting the info, it is all in one of the many specs, it just takes ages to find it and work out how it all fits together. It took me about 3 months to learn the stuff, and that was doing it all day every day, but I guess that it is comming in usefull now.

I think start with the TTP credits (it may be an optional parameter when you kick off the TTP connect), if that doesn't work I have some specialised trace tools we can use to find out exactly what is going on.

Congrats Chimaera! I imagine this means that the USB project will be terminally delayed now...:)

Thanks,

And actually it may speed things up, as we dont have a wedding to plan anymore. I just hope that the pool table we got as a wedding present isn't too much of a distraction

A pool table? Nice. I hope my family and friends are as generous as yours.

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!

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.

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.

You are right, it is probably coming from two different levels of the stack - the Palm log shows the echoes twice, too. I've attached the complete log to this message, but discovery is shown below:

15:11:55.520000 xid:cmd ffffffff < 8c33f85d S=6 s=0 (14)
15:11:55.610000 xid:cmd ffffffff < 8c33f85d S=6 s=1 (14)
15:11:55.700000 xid:cmd ffffffff < 8c33f85d S=6 s=2 (14)
15:11:55.790000 xid:cmd ffffffff < 8c33f85d S=6 s=3 (14)
15:11:55.790000 xid:rsp 3427e52a > 8c33f85d S=6 s=3 Linux hint=8420 [ Computer IrOBEX ] (22)
15:11:55.840000 xid:rsp 8c33f85d < 3427e52a S=6 s=3 Linux hint=8420 [ Computer IrOBEX ] (22)
15:11:55.870000 xid:cmd ffffffff < 8c33f85d S=6 s=4 (14)
15:11:55.950000 xid:cmd ffffffff < 8c33f85d S=6 s=5 (14)
15:11:56.060000 xid:cmd ffffffff < 8c33f85d S=6 s=* Mark Cushman hint=8220 [ PDA/Palmtop IrOBEX ] (29)

15:11:56.100000 snrm:cmd ca=fe pf=1 3427e52a < 8c33f85d new-ca=64
LAP QoS: Baud Rate=115200bps Max Turn Time=500ms Data Size=512B Window Size=1 Add BOFS=5 Min T
urn Time=1000us Link Disc=40s (32)
15:11:56.100000 ua:rsp ca=64 pf=1 3427e52a > 8c33f85d
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)
15:11:56.150000 ua:rsp ca=64 pf=1 8c33f85d < 3427e52a
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)

So it's definately a problem with my code. With my new-found knowledge of irdadump, I looked through a log of a successfull beam from the Palm, and there are only a few differences from the PocketPC. One is the Palm issues only 2 credits on a CONN_CMD TTP, and the other is the lsap value of OBEX. Can it be different each time?

Anyway, this leads me to believe that it is my program that is dropping the ball. I lifted the source code almost directly from this article and here is a link to the code directly. I had to add in some variables like the OBEX_* definitions from the first code example, and I've also added some MessageBox alerts for debugging. This is my first time developing for the CE platform (or any Win32 platform for that matter) so I may be missing something here. I'm using sockets to do all the communication, and sometimes I have problems understanding which are blocking and non-blocking.

Here is the IrDA socket startup on CE:

	if ((ClientSock = socket(AF_IRDA, SOCK_STREAM, 0)) == INVALID_SOCKET) {

		FAILURE_MESG(_T("socket"));

		WSACleanup();

		return;

	}

Now I search for a device that is in range:

	memset (cDevice, 0, sizeof (cDevice));

	int nSize = sizeof (cDevice);

 

	// loop 10 times, if not found in 10 attempts then there's a problem

	for (cnt = 0 ; cnt < 10 ; cnt++) {

		if (getsockopt(ClientSock, SOL_IRLMP, IRLMP_ENUMDEVICES, cDevice, &nSize) == SOCKET_ERROR) {

			FAILURE_MESG(_T("getsockopt"));

			closesocket (ClientSock);

			WSACleanup();

			return;

		}

		else

			pDL = (PDEVICELIST)cDevice;

 

		if (pDL->numDevice != 0)	// Found at least one device

			break; 

		

		Sleep(200);

	}

Here is where I query IAS and get the lsap address for OBEX

	// Query IAS database

	// irdaClassName and irdaAttribName are case sensitive

	memcpy(&pIASQuery->irdaDeviceID, pDL->Device[0].irdaDeviceID, 4);

	memcpy(&pIASQuery->irdaClassName, CLASS_NAME, CLASS_NAME_LEN);

	memcpy(&pIASQuery->irdaAttribName, ATTRIBUTE_NAME, ATTRIBUTE_NAME_LEN);

 

	if (getsockopt(ClientSock, SOL_IRLMP, IRLMP_IAS_QUERY, (char *)pIASQuery, &IASQueryLen) == SOCKET_ERROR) {

		FAILURE_MESG(_T("getsockopt"));

		closesocket (ClientSock);

		WSACleanup();

		return;

	} 

 

	sprintf(szServiceName, "LSAP-SEL%d", pIASQuery->irdaAttribute.irdaAttribInt);

 

	memset (&iraddr, 0, sizeof(iraddr));

	iraddr.irdaAddressFamily = AF_IRDA;

	memcpy (iraddr.irdaDeviceID, pDL->Device[0].irdaDeviceID, 4);

	memcpy (iraddr.irdaServiceName, szServiceName, strlen(szServiceName) + 1);

Now we issue the TTP CONN connect:

	for ( cnt = 0; cnt < 10 ; cnt++ ) {

		if(connect(ClientSock, (struct sockaddr *)&iraddr, sizeof (iraddr)) == SOCKET_ERROR ) {

			Sleep(200);

		} else {

			break;

		}

	}

After the connect, I try to send the OBEX CONNECT:

	MessageBox(NULL, _T("Got Here (1)"), _T("Message"), MB_OK);



	dataBuff[0] = OBEX_CONNECT;

	*((unsigned short *)&dataBuff[1]) = htons((unsigned short)7);

	dataBuff[3] = OBEX_VERSION;

	dataBuff[4] = OBEX_CONNECT_FLAGS;

	*((unsigned short *)&dataBuff[5]) = htons((unsigned short)MAX_PKT_SIZE);



	MessageBox(NULL, _T("Got Here (2)"), _T("Message"), MB_OK);



	if (send(ClientSock, (const char*)dataBuff, 7, 0) == SOCKET_ERROR) {

		FAILURE_MESG(_T("send"));

		closesocket (ClientSock);

		WSACleanup();

		return;

	}

	

	if ((recv(ClientSock, (char *)recvBuff, MAX_RECV_BUFF_LEN, 0) == SOCKET_ERROR) 

		|| (recvBuff[0] != OBEX_SUCCESS)) {

		FAILURE_MESG(_T("recv"));

		closesocket (ClientSock);

		WSACleanup();

		return;

	}

 

	MessageBox(NULL, _T("Got Here (3)"), _T("Message"), MB_OK);

What is weird is that I see the first MessageBox, but I never see the second one "Got Here(2)". From what I can see, all the code is doing is assigning variables to dataBuff, which is defined as

BYTE dataBuff[MAX_SEND_BUFF_LEN];

MAX_SEND_BUFF_LEN is 1030. I'm not sure why it stalls after assigning values like that, but it always does. The RR's begin before I see the first messagebox, and they continue while the messagebox is active, also.

I would think that if the connnect() call was non-blocking, that the code would not stall until it hit the send() portion when I try to send the OBEX CONNECT dataBuff. This is the next step in the connection process, and from irdadump, the one that I am failing to send. Can you see anything I am doing wrong?

You are right, it is probably coming from two different levels of the stack
OK, that is good then.

One is the Palm issues only 2 credits on a CONN_CMD TTP, and the other is the lsap value of OBEX. Can it be different each time?
Only issuing 2 credits is fine, it just means that the device giving the credits probably has less memory, so cannot hold as much data (TTP uses the credits as a flow control system).
Also there is no problem with where the OBEX LSAP actually is, IrDA uses fixed names rather than numbers, which is why there is a method for finding the LSAP from the name, and it can move as much as it wants between connections, but needs to stay the same during the connection.

I am not that hot on Win32 debug either, so appologies to the M$ gods if I get it wrong

I think your code up until the TTP connect is fine, but with the TTP connect there are two ways out of that loop, to go around it 10 times (and wait 1 second) or to get the response, and we do not know which it is, so I would add something to your debug to display the value of cnt after that loop has finished.
The other thing is I am not sure what the htons() function does, so I would be tempted to remove it just so that we know it is not causing the problem, try something like this:

MessageBox(NULL, _T("Got Here (1)"), _T("Message"), MB_OK);
dataBuff[0] = OBEX_CONNECT;
dataBuff[1] = 0x00;
dataBuff[2] = 0x07;
dataBuff[3] = OBEX_VERSION;
dataBuff[4] = OBEX_CONNECT_FLAGS;
dataBuff[5] = 0x00;
dataBuff[6] = 0x7F;

MessageBox(NULL, _T("Got Here (2)"), _T("Message"), MB_OK);

Note that I changed your max OBEX packet length to a much smaller value too, incase this is causing problems, once we get the connect frame TXed we can worry about the correct numbers.

We can then see if that gets the second message box.

The RR's begin before I see the first messagebox, and they continue while the messagebox is active, also.
That would be what I would expect, the IrDA part of the socket keeps the link running while you are dealing with the message boxes.

Let me know the value for cnt, and if that code change affects anything.

I would add something to your debug to display the value of cnt after that loop has finished.

I actually have a test (I left out all the error checking code) to test for the value of cnt before continuing. It checks to make sure cnt < 10 or it shuts down. BUT (good news): I am getting a successfull OBEX_CONNECT when I build the dataBuff by hand (set all the bytes like you suggested). The htons() function is a winsock function that reverses the byte order from host byte order (little endian) to network byte order (big endian), but it looks like I do not need to do that. I'm doing tests now to see what the problem in my code is, but I think that I've got it nailed now. I'll post progress here after I mess with it some more. It's kind of tedious testing, since every time I want to run the program, I have to sync it with the Pocket PC, then take the Pocket PC out of the cradle and point it at the Empeg and beam.

Thank you very much for your help, though, I doubt if I would have found the flaw in my program if it wasn't for your help. What devices did you develop IrDA solutions for? Were they hardware-based solutions?

Cool, it looks like you are making some progress, I am sure now it is just a matter of time

I understand the tedious debug thing, when we are debugging we had to reflash the hardware between attempts, which takes about 10 minutes

I work on Cell phones, pretty much any phone made by a certain Finnish company that doesn't run Symbian has my code in it