Bluetooth Service Discovery

I'm programming using Visual Studio 2005 (C#) on a PocketPC with
Windows Mobile 5.0. I have downloaded the Windows Mobile Shared Source
Bluetooth libraries from microsoft and noticed that their libraries
only support connecting to devices that are in the registry (already
paired devices).

In my application, I need to survey the surrounding area for bluetooth
devices and for each device that is found, see if it's running a
service with a particular GUID. I use PInvoke to call the
WSALookupServiceBegin and WSALookupServiceNext methods to achieve
this. At this point, I am finding devices correctly, but it seems that
the service discovery fails.

I set the WSAQUERYSET members lpServiceClassId equal to the Guid I'm
looking for and the lpszContext to the string version of the bluetooth
address (eg. "XX:XX:XX:XX:XX:XX").

I then call WSALookupServiceBegin with 0x0002 (LUP_CONTAINERS) and
then call WSALookupServiceNext using LUP_RETURN_NAME and
LUP_RETURN_ADDRESS (0x0010 | 0x0100). By the way, if you try to call
WsaLookupServiceXXXX with anything but these flags, the call fails
with 10014 (WSAEFAULT).

I am testing with 3 bluetooth devices.

Device A: The one running my program. This device is trying to
discover.
Device B: This one is just sitting there with bluetooth enabled. No
programs are running on here.
Device C: This one is running the service I am interested in. It is
just listening for connections.

I am noticing some strange behavior:

1) If I turn the program off on Device C, Device A will still identify
it as running the service (the call from WSALookupServiceNext)

2) Sometimes it says that Device B is running the service I'm
interested in, but Device B has no knowledge of the service I'm
interested in.

My questions are as follows:

1) Am I doing service discovery correctly? (eg looking for devices,
then looking for services on these devices)
2) Am I using the correct flags? A lot of the other ones like
LUP_FLUSHCACHE fail for some reason
3) Is there a better way to do what I'm trying to do?

Thanks in advance.

On Mar 2, 5:17 pm, jeffzz...@gmail.com wrote:
> I'm programming using Visual Studio 2005 (C#) on a PocketPC with
> Windows Mobile 5.0. I have downloaded the Windows Mobile Shared SourceBluetoothlibraries from microsoft and noticed that their libraries
> only support connecting to devices that are in the registry (already
> paired devices).
>
> In my application, I need to survey the surrounding area forbluetooth
> devices and for each device that is found, see if it's running aservicewith a particular GUID. I use PInvoke to call the
> WSALookupServiceBegin and WSALookupServiceNext methods to achieve
> this. At this point, I am finding devices correctly, but it seems that
> theservicediscoveryfails.
>
> I set the WSAQUERYSET members lpServiceClassId equal to the Guid I'm
> looking for and the lpszContext to the string version of thebluetooth
> address (eg. "XX:XX:XX:XX:XX:XX").
>
> I then call WSALookupServiceBegin with 0x0002 (LUP_CONTAINERS) and
> then call WSALookupServiceNext using LUP_RETURN_NAME and
> LUP_RETURN_ADDRESS (0x0010 | 0x0100). By the way, if you try to call
> WsaLookupServiceXXXX with anything but these flags, the call fails
> with 10014 (WSAEFAULT).
>
> I am testing with 3bluetoothdevices.
>
> Device A: The one running my program. This device is trying to
> discover.
> Device B: This one is just sitting there withbluetoothenabled. No
> programs are running on here.
> Device C: This one is running theserviceI am interested in. It is
> just listening for connections.
>
> I am noticing some strange behavior:
>
> 1) If I turn the program off on Device C, Device A will still identify
> it as running theservice(the call from WSALookupServiceNext)
>
> 2) Sometimes it says that Device B is running theserviceI'm
> interested in, but Device B has no knowledge of theserviceI'm
> interested in.
>
> My questions are as follows:
>
> 1) Am I doingservicediscoverycorrectly? (eg looking for devices,
> then looking for services on these devices)
> 2) Am I using the correct flags? A lot of the other ones like
> LUP_FLUSHCACHE fail for some reason
> 3) Is there a better way to do what I'm trying to do?
>
> Thanks in advance.

I'm going to answer my own question. After you have found the device
you want to query for services, you must call WSALookupServiceBegin
with 0 as the dwFlags argument. On subsequent calls to
WSALookupServiceNext, call it with 0x0200 (the one that returns the
blob) and if the service is found, the size of the blob will be
greater than 2.

I've run into a new problem now. The code works when the device is in
the cradle, but once I take it off, it crashes at the first
WSALookupServiceBegin. Any ideas?

In article news:1172873869.618214.300180@z35g2000cwz.googlegroups.com,
jeffzzang@gmail.com wrote:
[...]
> In my application, I need to survey the surrounding area for bluetooth
> devices and for each device that is found, see if it's running a
> service with a particular GUID. I use PInvoke to call the
> WSALookupServiceBegin and WSALookupServiceNext methods to achieve
> this. At this point, I am finding devices correctly, but it seems that
> the service discovery fails.
>

Well there's the http://32feet.net/ library which also provides
Bluetooth support for .NET. It should be able to do all of what you
want. Handling all that horrible native Winsock access behind the
scenes. :-)

Perhaps code something like the following (uncompiled...). Ask again in
the forums there if you need some help with it.

Guid searchedForUuid = ...
BluetoothClient cli = new ...;
BluetoothDeviceInfo[] devices = cli.DiscoverDevices(...);
foreach (BluetoothDeviceInfo curDevice in devices) {
// SDP lookup
ServiceRecord[] svcRecords =
curDevice.GetServiceRecords(searchedForUuid);
...check record contents?...

// Otherwise one could just try a connect to the service, e.g.
cli = new ...;
try{
cli.Connect(curDevice.DeviceAddress, searchedForUuid);
cli.Close();
} catch (SocketExcecption sex) {
switch(sex.ErrorCode) {
...
}
}
}//for
--
Alan J. McFarlane
http://www.alanjmcf.me.uk/
Please follow-up in the newsgroup for the benefit of all.