Has anyone successfully used InTheHand.B* to connect to a SPP using the Motorola/Symbol MC70.... From what I'm seeing, it correctly identifies the StoneStreetOne stack, I get it setting the API version to PreSsp... [it throws a SocketException "An operation was attemped on something this is not a socket" - in ASyncResultNoResult.EndInvoke] Mike

(When I added the support I found that there was apparently a breaking change in the Bluetopia SDK.  When they added support for Secure Simple Pairing they added new fields to some of the structs and changed the alignment of existing fields.  Yikes!  I've only tested on the new SDK.  However this *only* affects pairing, so simple connect wouldn't be affected).

NotSocket is a catch-all error code I use when a better SocketError code isn't known.  What's the Bluetopia error code reported in the exception message?

There's various ways to troubleshoot but let me know the Bluetopia error code for now.

Is the target a low resourced device?  It kinda looks like it can't cope with more than one connection (SDP and RFCOMM).  We see 1) SDP success (port=1) RFCOMM fail 2) SDP fail, 3) SDP fail, 4) as #1, 5) don't know.

So try cli.Connect(new BtEndpOint(addr, Empty, 1)) and see if that works -- i.e. without needing to do the SDP query.

It's the same mc70 I had working with the stack ages ago, so I'm going to upgrade it to wm6.1 on Monday and see if a clean stack solves the problem...

Have a go with the current system first to see if it works.  Try doing a RFCOMM connect to port and separately a SDP query devInfo.GetServiceRecord(BluetoothSerice.l2capprotocol).

You could also try connecting to PC say, for instance run fsquirt.exe (Bluetooth File Transfer) and try to connect to it (ObexObjectPush).

It won't make an RFCOMM connection to the device (or to the two PCs I tried this morning), and won't accept an OBEX push of a file from either PC I tried, so I think it is the PDA that is unhealthy....

 When Motorola issue the update I'll let you know if that resolves the issue....

 Thanks

 Mike

Having just updated the PDA, it sees the stack first time OK, can handle the discovery ok, but when it comes to connect it seems to timeout....

 BeginFillInPortState
CancelAllQueryNames: 0 devices.
HandleSDP_Response_Callback2: ServiceSearchAttributeResponse=0x5
BuildRecordList Number_Service_Records: 1
DoEndServiceDiscovery, got 1 records.
FillInPort_ServiceDiscoveryCallback, got port: 1
CancelAllQueryNames: 0 devices.
Authenticate_Callback: type: LinkKeyRequest, addr: 000666434392
  Have Pin: True, LinkKey: False
  Sending Auth Response: -ve (no linkkey)
EventConnectConf: ConnectionTimeout=0x1
CONNECT_ERR DEBUGID, m_state: New, m_arConnect (set)
HandlePortEvent: connect failed.
A first chance exception of type 'InTheHand.Net.Bluetooth.Widcomm.NoResultCodeWidcommSocketException' occurred in InTheHand.Net.Personal.dll
A first chance exception of type 'InTheHand.Net.Bluetooth.Widcomm.NoResultCodeWidcommSocketException' occurred in InTheHand.Net.Personal.dll

 Does the authenticate callback lines indicate that it failed to pair correctly?

No, it looks as if in this case it could be the pairing that's the problem.  A success is:

• LinkKeyRequest
• Sending Auth Response: -ve (no linkkey)
• PINCodeRequest
• Sending Auth Response: PinCode
• LinkKeyCreation
• see SDP response
• LinkKeyRequest
• Sending Auth Response: LinkKey
• see RFCOMM connect response

(See the full text in the second example in "BluetoothClient.SetPin" in "32feet Bluetopia Test.html" in the repository)

What version of stack is this?  PreSSP or not?  I'm a bit worried not to see the PINCodeRequest event.

You could try a prior call to BluetoothSecurity.PairRequest to see if its only failing due to it being part of the RFCOMM connect etc.

I can confirm that adding BluetoothSecurity.PairRequest seems to make it connect properly... I've yet to try this on the iPAQ and I'll do that later today and confirm whether that also solves the iPAQ problem.

[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.