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?
Previous Topic
Index
