February 2011


I’ve just checked in support for Widcomm’s COM Port creation classes. Access WidcommSerialPort.CreateClient and store the result and once you’ve finished with the COM port Dispose it, it’ll be Finalized if not referenced.  I’ll look at integrating the functionality into the BluetoothSerialPort class sometime.

I’ve tested it on my Asus WM Classic device and it work fine there. The Widcomm documentation implies that it should work on Win32 too but it doesn’t work on my WinXP Widcomm v3 installation.

Download the library code (revision 85315 or later) from http://32feet.codeplex.com/SourceControl/list/changesets and compile the CF2 project to get the library code to use in your project. You’ll also need the new native Widcomm mapping DLL, get it from http://32feet.codeplex.com/releases/view/61443

Testing shows that if the connected devices go out of range then the connection is lost however (we see DISCONNECT event in the code, and the remote socket server sees close). Presumably we need to implement code to repeatedly retry to reconnect?

I’ve done about a day’s work on that. I’d be glad of a wee ‘reward’ for adding this new feature, particularly if it saves you time on your projects. 🙂 I’ve Amazon wishlist or paypal for instance.

 I’ve added support for Secure Simple Pairing (SSP) for Windows 7 and Vista SP2 using the Microsoft stack.  When a Windows 7/etc PC has a Bluetooth version 2.1 dongle (radio/controller) attached and a version 2.1 device is to be atempts to authenticate then one of the new SSP authentication methods will be used.  Previously we had support only for the original Bluetooth PIN authentication method and thus BluetoothWin32Authentication would ignore SSP authentication attempts.  It aims to supports all the authentication methods, although I’ve managed to test only the NumericalComparison/JustWorks methods, and not Passkey, PasskeyNotification and OutOfBand methods.

From the BluetoothWin32Authentication class documentation:

[…] the callback includes a parameter of type BluetoothWin32AuthenticationEventArgs. Various authentication methods are available in Bluetooth version 2.1 and later. Which one is being used is indicated by the AuthenticationMethod property. If it is Legacy then the callback method should set the Pin property.

For the other authentication methods e.g. NumericComparison or OutOfBand the callback method should use one or more of the other properties and methods e.g. NumberOrPasskeyAsString, NumberOrPasskey, Confirm, ResponseNumberOrPasskey, ConfirmOob etc.

For more information see the class documentation and the user guide (http://32feet.codeplex.com/wikipage?title=BluetoothWin32Authentication)

Let me have your feedback.

No changes to BluetoothSecurity.PairRequest nor BluetoothWin32Authentication.New(BluetoothAddress,String).  Those will be considered in the future based on your feedback.  This also affects BluetoothClient.SetPin etc.



UPDATED: Renamed to NumberOrPasskey from  NumberOrPasscode etc

Mostly as an aid memoire to myself, to help me remember how to find the version of radio (“controller” in official terminology IIRC) in the various Bluetooth stacks.

Microsoft on Windows XP, Windows 7 etc

Windows 7 Advanced tab of the Bluetooth Control Panel

Admin view of Windows XP Advanced tab of the Bluetooth Control Panel No version on Windows XP's non-admin view...

No version on Windows XP's non-admin view...

Widcomm/Broadcom

Widcomm (Windows XP at least) shows the version on the Hardware tab of its Control Panel.

BlueSoleil

BlueSoleil (Windows 7 at least) shows the version on the Hardware tab of its Control Panel.

BlueZ on Linux

Not from hcitool:

alan@foobar:~/> hcitool dev
Devices:
 hci0 00:15:83:B4:1B:FA
 hci1 00:80:98:24:4C:A4
alan@foobar:~/>

Yes from root hciconfig:

foobar:/home/alan # hciconfig hci0 version
hci0: Type: BR/EDR  Bus: USB
 BD Address: 00:15:83:B4:1B:FA  ACL MTU: 384:8  SCO MTU: 64:8
 HCI Version: 2.0 (0x3)  Revision: 0x7a6
 LMP Version: 2.0 (0x3)  Subversion: 0x7a6
 Manufacturer: Cambridge Silicon Radio (10)
foobar:/home/alan # hciconfig hci1 version
hci1: Type: BR/EDR  Bus: USB
 BD Address: 00:80:98:24:4C:A4  ACL MTU: 192:8  SCO MTU: 64:8
 HCI Version: 1.1 (0x1)  Revision: 0x20c
 LMP Version: 1.1 (0x1)  Subversion: 0x20c
 Manufacturer: Cambridge Silicon Radio (10)

foobar:/home/alan # hciconfig -a
hci0: Type: BR/EDR  Bus: USB
 BD Address: 00:15:83:B4:1B:FA  ACL MTU: 384:8  SCO MTU: 64:8
 UP RUNNING PSCAN
 RX bytes:1677 acl:0 sco:0 events:41 errors:0
 TX bytes:498 acl:0 sco:0 commands:41 errors:0
 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
 Link policy: RSWITCH HOLD SNIFF PARK
 Link mode: SLAVE ACCEPT
 Name: 'linux-0'
 Class: 0x4a0100
 Service Classes: Networking, Capturing, Telephony
 Device Class: Computer, Uncategorized
 HCI Version: 2.0 (0x3)  Revision: 0x7a6
 LMP Version: 2.0 (0x3)  Subversion: 0x7a6
 Manufacturer: Cambridge Silicon Radio (10)

hci1: Type: BR/EDR  Bus: USB
 BD Address: 00:80:98:24:4C:A4  ACL MTU: 192:8  SCO MTU: 64:8
 UP RUNNING PSCAN
 RX bytes:689 acl:0 sco:0 events:22 errors:0
 TX bytes:86 acl:0 sco:0 commands:22 errors:0
 Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
 Link policy:
 Link mode: SLAVE ACCEPT
 Name: 'ALANPC1a'
 Class: 0x4a0000
 Service Classes: Networking, Capturing, Telephony
 Device Class: Miscellaneous,
 HCI Version: 1.1 (0x1)  Revision: 0x20c
 LMP Version: 1.1 (0x1)  Subversion: 0x20c
 Manufacturer: Cambridge Silicon Radio (10)

foobar:/home/alan #

Version Numbers

The X.X e.g 1.1, 3.0, version numbers are actually represented by a simple integer, HCI and LMP strictly don’t use the same definitions but the two use the same numbering system currently and likely will do forever.  The current definitions are:

0 Bluetooth Core Specification 1.0b
1 Bluetooth Core Specification 1.1
2 Bluetooth Core Specification 1.2
3 Bluetooth Core Specification 2.0 + EDR
4 Bluetooth Core Specification 2.1 + EDR
5 Bluetooth Core Specification 3.0 + HS
6 Bluetooth Core Specification 4.0
7 – 255 Reserved

The definitions are available at https://www.bluetooth.org/Technical/AssignedNumbers/hci.htm and https://www.bluetooth.org/Technical/AssignedNumbers/link_manager.htm The Bluetooth specification documents have moved, unfortunately there’s a fault on the HCI document which requires Bluetooth log-in to access.  (http://bluetooth.com/Specification%20Documents/AssignedNumbersHostControllerInterface1.pdf and  http://bluetooth.com/Specification%20Documents/AssignedNumbersLinkManager1.pdf)