This implemented in the repository code now.  Workitem 32034.  And will be in the next release.

Sorry I can't see any description of what problems you are having... Presumably you are connecting to a v2.1 device and the Bluetooth v2.1 Secure Simple Pairing (SSP) dialog is popping-up.  You should create an instance of BluetoothWin32Authentication and provide a callback function.  To just accept every pairing just do ...

I've just re-read your first post and noticed that you're using v2.3. Why??? :-,(  Back then we *only* supported the MSFT stack.  If you use a current version then you should be more successful.  For Widcomm one needs to also copy the 32feetWidcomm.dll file along the app and the 32feet.NET library assembly. (In Device ...

There are multiple suppliers of Bluetooth stack for Windows.  We support all of the main ones except for Toshiba who aren't keen to provide their SDK.  Its possible your PC has that stack installed.  Can you check.  See e.g. http://32feet.codeplex.com/wikipage?title=Supported%20Hardware%20and%20Software and thus ...

If the two devices are already paired/bonded they don't need to re-pair so there's no security callback required.  BTW I would completely remove the call to PairRequest.  Just always call connect.  Then let the callback handler handle *both* the SSP (v2.1) and 'traditional pairing' schemes -- add code to ...

Don't know, sorry.  I presume you have access to the full debugger symbols, with them hopefully it will be able to tell you the real function in platform code where the crash occurs.

[Sorry your message was stuck in moderation -- communityserver seems to do that randomly...] Hope you made progress.  We support various Bluetooth stacks: Microsoft, Broadcom/Widcomm, Bluetopia etc.  We try to load them one-by-one.  Obviously an error occur if try to load the stack and it is not present (i.e. the P/Invoke error you ...

[Your message was stuck in moderation -- communityserver seems to do that randomly...] Ohh cool.  So probably some sort of timing/one-thing-at-a-time issue.

Have a read of the thread http://inthehand.com/forums/t/5204.aspx Note also the line "If you simply want to allow the pairing to go ahead when to SSP devices are connecting then handling the callback and setting e.Confirm=True will be enough -- but that is a little insecure..." at ...

Can you copy and paste the exception here. LATER: I suspect the exception is occuring on the PUT.  ObexClientSession will send the correct Connection Id so there's no need to send it, so we'll get a duplicate there.  Also the rest of the PUT is too complex. :-)  Just do:      ... ...