The list of error codes used by Bluetooth sockets on the Microsoft stack on desktop Windows is described at “Bluetooth and connect”
(the generic list of errors is at
), and at
for the Microsoft stack on CE/WM (generic errors).
This error code is stored in the SocketErrorCode
Property of SocketException
In summary on MSFT+Win32 the common error codes are:
||"Only one usage of each socket address (protocol/network address/port) is normally permitted"
||Already a connection to the RFCOMM port/channel
||"The requested address is not valid in its context."
||No Service with given Service Class Id is running on the remote device
||No Device with given Address is in-range/answering
||"A socket operation failed because the destination host was down."
||Service doesn't use RFCOMM. i.e. the SDP record type is for L2CAP etc.
||"An invalid argument was supplied."
||"Plug and Play, driver-stack event, or other error caused failure."
Note that the error can sometimes be different from expected, for instance on connecting with BluetoothClient to a Blackberry which requires bonding the error that occurs is 10058 WSAESHUTDOWN (“The L2CAP channel disconnected by remote peer”), rather than say
10013 WSAEACCES (“Connecting application requested authentication”). We have also seen simitar behaviour when connecting to a Parani Bluetooth module where we see error 10022, which is documented as a hardware fault, when the module should be requesting authentication/pairing.
On the other stacks (Broadcom/Widcomm, BlueSoleil and Bluetopia stacks etc) Winsock isn’t used but instead we have to talk to a custom API, and we thus create the error IOException/SocketException instances ourself. We aim to use same error codes as the Microsoft
stack on Win32 (as opposed to the WCE/WM error codes). However there isn’t always a good correspondence between the errors reported by the Microsoft stack and the other stacks, for instance the Widcomm stack reports the same error for every variety of the
RFCOMM connect operation failing and connection closing. See the particular stack documents for more information -- for example the matching is good on the Bluetopia stack and most error cases use the expected error code.
For the stacks where we manually do the SDP lookup we can identify what is wrong. For instance:
||Error code matches above
||There are no SDP records matching the specified Service Class Id.
||There was one or more SDP records, but none of them were accessible via RFCOMM (i.e. thus probably use L2CAP only).
See also Connect Errors at the bottom of
Feature Support Table