Alan McFarlane
January 2010
bug 23222. On Win32 (XP) test of Widcomm radio dongle unplugged.
The failing behaviour is for a empty radio instance to be returned, like:
option>10 BtIf_Create BtIf_GetLocalDeviceVersionInfo [Assertion Failed: GetLocalDeviceVersionInfo failed] BtIf_GetLocalDeviceName [Assertion Failed: GetLocalDeviceName failed] BtIf_GetLocalDeviceInfoBdAddr [Assertion Failed: GetLocalDeviceInfoBdAddr failed] BtIf_IsDeviceConnectableDiscoverable Radio, address: 00:00:00:00:00:00 Mode: Discoverable Name: , LmpSubversion: 0 ClassOfDevice: 0, device: Miscellaneous / service: None Software: Broadcom, Hardware: Ericsson, status: Running Remote: ''
Device-/ConsoleMenuTesting menu option “ServiceDiscovery” etc. Against any device, at least one record should be listed, the SDP server record itself. The device may have other records.
Note that we cannot dump the whole record as Widcomm does not provide access to the raw record bytes. Check the documentation for the Attributes we lookup (currently only the Service Class, and Name, and RFCOMM Channel Number).
Also need to do a specific class query to check we filter correctly. Widcomm returns *all* the records read in the current session, so we have to filter the matching ones in GetServiceRecords.
See the general BluetoothListener test also.
Connecting from a device that isn't trusted by the Widcomm-stack machine the DUT.
In each case, on the DUT, start BluetoothListener apply the respective settings and then connect from the peer machine. Check that the peer machine succeeds/fails to connect as expected.
Recommend specifying the Service Class UUID each time, and with a different value each time, e.g. 0x00010001, then 0x00010002, etc. May also be wise to manually specify the port at well, using 11, 12, etc in correspondence with the UUID.
We want to check that we see devices of the two types: {Remembered=true, Authenticated=false} and {Remembered=true, Authenticated=true}. This requires that we have at least one device in Widcomm's “Trusted Devices” set.
Run discovery with at least remembered=authentication=true, discoverableOnly must be false, unknown is better set to false also.
In Widcomm a device is ‘remembered’ whenever the stack sees it — unlike MSFT where manual request is required. One may need to force a device to be trusted — either by calling BluetoothSecurity.PairRequest, or by making a connection with it to a service requiring authentication.
A nice test to is to have a trusted device and then make it untrusted (either BluetoothSecurity.RemoveDevice, or use the Widcomm UI e.g. on WM do {Wireless XX -> Manage -> Advanced menu -> Trusted Devices -> Remove} and on two discovery process see it R+A and then R-A.
In a similar area to the above, here testing whether we can add and remove devices from the trusted list. Choose a peer device that is in range and you can bond with. Run discovery(auth+rmbd) and/or use the Widcomm UI to view trusted device and see the device removed from the trusted list with RemoveDevice and added with PairRequest.
In iPAQ:
StartMenu → iPAQWireless → Manager → Menu → PairedDevices
In BluetoothClient we have to do a manual SDP lookup (unless the port is set in the specified BluetoothEndPoint), thus there's some complexity around that. There's the test below 'BluetoothClient' which does SvcA->SvcB->SvcA. The SDP Lookup takes 12 seconds to time-out when the target device is not found.
Connect to a remote service, e.g. OBEX or SerialPort on most device types, or 1113 to another instance on ConsoleMenuTesting.
If the port (RFCOMM SCN) is specified in the endpoint then the process is less complex (no SDP lookup) though not worth testing that in most cases.
Start a Connect to a non-existent device, it will take a while (12secs) for the SDP lookup to fail. See that that delay (only) occurs.
We would like to report a useful Winsock Error code but Widcomm doesn't tell us if the failure was not-present, security, or something else. So ignore the exception error code.
Use ConsoleMenuTesting option: "ConnectMultiple".
Start a Connect to a non-existent device, it will take a while (12secs) for the SDP lookup to fail. In that time call BluetoothClient.Close and the sync/async Connect will fail with a ObjDispEx (we only test the async case from the same thread here). Later the SDP lookup will complete, and it will NOT crash!
Here we can see that we aren't able to do another connect immediately when we cancel a previous connect. We have to wait for the SDP to complete first. The current script in ConsoleMenuTesting is as following. It runs two Connect, the first as async=Y, cancel=Y; and we expect to see the second fail with "one at a time" InvOpEx.
bug 28623. [widcomm] Use OnStackStatusChange to close connections when radio turned off
On PDAs when the radio is turned off when there is an current RFCOMM connection, no connection loss event is received, so the program there thinks the connection is still open, and will hang on a Read for instance (the remote end sees the connection close due to 20s timeout). So we need to listen for the radio-off event and manually close any connections then. Note that on my iPAQ hx2710 with Widcomm 1.7.1.1424 when the radio is switched off a CONN_ERR event is recevied, this is not the case on my Asus device nor a newer iPAQ I've tested on.
This functionality is not implemented on the desktop PC platform, we saw wierd/bad things happening when implemented. The radio-off situation is less likely to happen then, e.g. less need for saving power, so its not important to implement it there, we'll look at it again based on demand. (The wierd/bad thing was that after the native code called up into the managed code to report the OnStackStatusChange event things went all wrong).
We need to test the connection(s) are closed. We should also test that the infrastructure is working correctly, that the list of open connections is maintained correctly, being added to at both client and server connect, and the connection is removed from the list when it closes.
1. Make a client connection to a remote machine and close the connection. Run a server on the PDA and connect to it from a remote machine, and close the connection.
2. Run a server on the PDA and connect to it from a remote machine, and start a Read on the connection.
3. In Wireless Manager or similar turn off the radio.
PortKill_Runner
done (1)
") — i.e. the two previous connections were correctly removed
from the list when they closed.4. Re-enable the radio, restart DeviceMenuTesting (if required – or use HackShutdown), make a client connection to a remote machine. Turn off the radio, and start a Read on the connection.
This checks a possible failure case on Widcomm pre 2.4.
Connect three times: to SvcA, SvcB, then SvcA again. For instance on another machine run two copies of ConsoleMenuTesting and use the ListenMultiple option with a different UUID in each instance.
Ensure that third connect does not connect to SvcB, but correctly to SvcA.
This checks a possible failure case on Widcomm pre 2.4.
Query for OPP, then for all, the for OPP again.
Ensure that the third query doesn't return 'all', but the same result as the first query.
BluetoothWin32Authentication
. It can be used in two forms,
firstly in an automatic mode where the caller specifies a device address
and the pin and it should use to authenticate to that address.
In the second mode the caller supplies a callback method which can
respond to the PIN requests.
Default method should be for the user to call SetPin(String pin)
before connect, which specifies that that pin is to be used this connection,
or at least that the PIN should be used for the device that this instance is
connecting to. There will also be a SetPin(BluetoothAddress device,String pin) method, but I'm not
sure of its use.
The use of these after a connection is made is not obvious to me. By then the PIN is not required since the connection has been successful without one!
SetPin(string)
without the device address, and for SetPin(BluetoothAddress,String)
with the address.
BTH_SOCKOPT_SECURITY in the Windows CE docsSetPin(BluetoothAddress,String)
should
start an ‘automatic’ BluetoothWin32Authenticator using the two parameters.
SetPin(string)
is called before the instance
is connected, it should store the pin. When the caller later initiates
a connection the device address from the connect
call along with the stored pin should be used to start an ‘automatic’
BluetoothWin32Authenticator.SetPin(string)
is called called after connection
the connected remote device address can be used.
CBtIf::Bond()
and try
the connect again.
However, at least with the Microsoft stack as the peer device, that is not useful
— the Bond operation fails.
BluetoothClient
, Connect to a service on an unbonded device,
where the service or device requires authentication.SetPin(pin)
on the BluetoothClient.SetPin(address,pin)
on the BluetoothClient.SetPin(wrongAddress,pin)
on the BluetoothClient.Can be configured whether to attempt to initialise more that one stack (i.e. MSFT and Widcomm together), also need to configure where we report errors in all case. For instance if configured to load more that one stack but the first stack fails to init, should the error be reported. Answer: probably not, one stack may be enough for the use case.
So the following configurations exist and the number of errors that should be reported are listed. The cells with underscores have been tested.
Widcomm | |||
Y | N | ||
MSFT | Y | 0 | 0_ |
N | 0_ | 2_ |
Widcomm | |||
Y | N | ||
MSFT | Y | 0 | 0 |
N | 1_ | 2_ |
Widcomm | |||
Y | N | ||
MSFT | Y | 0 | 0_ |
N | 0 | 2 |
Widcomm | |||
Y | N | ||
MSFT | Y | 0 | 1_ |
N | 1 | 2_ |
Check also when on a suitable machine that one stack is loaded when “OneStack” is true, and two are loaded when it is false.