Contents |
Bluez is the current official Bluetooth protocol stack on Linux. It consists of kernel modules and a userspace library, with a set of tools for low-level configuration. It is used (roughly) analogously to the network subsystem, using sockets for communication.
The blts-bluetooth test driver includes functional tests for the Bluez stack, currently consisting of device scan and simple L2CAP and RFCOMM connectivity tests, a test for link-level (only) connection using HCI and simple HCI transfer/receive ACL test data package test. The Performance tests are available in the peripheral performance test set. A test case for probing the system for installed Bluetooth drivers and Bluez userspace components is included. Pairing (without services from system Bluetooth daemon) is also tested.
The test driver uses Bluez sockets with the libbluetooth functions hci_get_route(), hci_open_dev(), hci_inquiry() and hci_read_remote_name(). The L2CAP tests also check some connection parameters with direct hci_send_req() calls. HCI link-level connection is tested with hci_create_connection() and hci_disconnect(). HCI transfer/receive ACL data tests utilize hci_filter structs and socket() function with parameters AF_BLUETOOTH, SOCK_RAW and BTPROTO_HCI while receiving ACL test data. Incoming connections are audited by tracing the sequence with hcidump and analysing the trace.
The HCI name change test cases utilize hci library functions hci_read_local_name(), hci_write_local_name() to change and reset name of the device and hci_read_remote_name() function to verify changed name. The class change test cases utilize hci library functions hci_read_class_of_dev() and hci_write_class_of_dev() to change and reset the class of the device and hci_inquiry() function to verify changed device class.
The HCI controller information test cases utilize hci library functions hci_read_{local/remote}_version(), hci_read_{local/remote}_features(), hci_read_{local/remote}_ext_features() to collect data and the connected link information test cases utilize hci library functions hci_read_rssi(), hci_read_link_quality(), hci_read_transmit_power_level(), hci_read_afh_map(), hci_read_clock(), hci_read_clock_offset() to collect data.
The pairing test performs authenthication and pairing for a connected link, according to the Bluetooth specification. Due to possible interference from the Bluetooth daemon in the system, it is shut down for the duration of the test, and the test needs to perform simplified device initialisation.
Current coverage of the Bluetooth HCI API:
Hardware coverage includes the data path through the default Bluetooth adapter to the antenna.
While the device scan does list all found devices, the actual validation of the result is left to the tester.
Future test cases may include further tests for HCI link control, and exploring different connection parameter combinations in existing tests. Testing protocols and profiles further up in the Bluetooth stack is currently beyond scope for the test suite.
The tests require two test devices with Bluetooth adapters, both running the test program. Several test cases are meant to run in pairs; see below.
Hciconfig can be used to find out the required mac addresses:
$ hciconfig
This will print out all active bluetooth devices and their addresses. The output is similar to following:
hci0: Type: USB
BD Address: 00:15:83:18:C0:30 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:1007 acl:0 sco:0 events:30 errors:0
TX bytes:367 acl:0 sco:0 commands:28 errors:0
General test case execution is done with the command line program, run (as root) with "blts_bluetooth_test <logfile> <test> <test parameters>". Refer to the README file for test-specific parameters.
Test case execution instructions for high-level cases:
The Scan and Software check tests run on a single device, and don't require extra hardware. Having visible Bluetooth devices present during the Scan test may help evaluating the test results.
The L2CAP and RFCOMM test cases are executed with one device running the test "Core-Bluetooth receive L2CAP connection" or "Core-Bluetooth receive RFCOMM connection", and the other the corresponding client test cases.
Test case execution instructions for HCI test cases:
When executing HCI tests, the first step is to verify that hci device is available by typing hciconfig and then try to open and initialize it with command hciconfig hciX up.
Some of the HCI test cases are counter parts to other HCI test cases and these must be executed at the same time with two devices so that the changing/receiving side must be executed first.
Change name with HCI <-> Verify name with remote HCI
The verify test case connects to the other bluetooth device and verifies that the device name is expected one while the changing side is waiting until other bluetooth device is verified name change.
Change class with HCI <-> Verify class with remote HCI
The verify test case connects to the other bluetooth device and verifies that the class of the device is expected one while the changing side is waiting until other bluetooth device is verified class change.
HCI transfer ACL data package <-> HCI receive ACL data package
The transfer test case sends ACL test data packet containing predefined test data while the receive test case waits and receives the ACL test data packet and verifies the content.
Read HCI controller information local <-> Read HCI controller information remote
The remote test case collects information about other bluetooth device, connect to that device and sends collected information package while the local test case waits and receives the information package and verifies that locally collected information matches with received data.
Read connected link information local <-> Read connected link information remote
The remote test case connects to other bluetooth device using multiple L2CAP channels, collects information about connected link and sends collected information package while the local test case waits and receives the information package and verifies that locally collected information matches with received data.
Authentication with pairing as master / slave
As initiating device (master), the test case connects to another Bluetooth device and requests authentication, triggering pairing. The pairing sequence is completed with a predetermined PIN. The slave device waits for the connection and attempts pairing as the request arrives. Either end of the test can be substituted with any Bluetooth device supporting the functionality. The device(s) running this test case must not have the Bluetooth daemon (bluetoothd) running.
$ blts_bluetooth_test test.log "Core-Bluetooth scan"
$ blts_bluetooth_test test.log "Core-Bluetooth drivers and userspace check"
$ blts_bluetooth_test test.log "Core-Bluetooth receive L2CAP connection"
$ blts_bluetooth_test test.log "Core-Bluetooth connect with L2CAP" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth ping-pong transfer with L2CAP" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth receive RFCOMM connection"
$ blts_bluetooth_test test.log "Core-Bluetooth connect with RFCOMM" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth ping-pong transfer with RFCOMM" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth connect with HCI" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth receive ACL data with HCI"
$ blts_bluetooth_test test.log "Core-Bluetooth transfer ACL data with HCI" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth change name with HCI"
$ blts_bluetooth_test test.log "Core-Bluetooth verify name with remote HCI" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth change class with HCI"
$ blts_bluetooth_test test.log "Core-Bluetooth verify class with remote HCI" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth reset connection with HCI" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth audit incoming HCI connection"
$ blts_bluetooth_test test.log "Core-Bluetooth Read HCI controller information local"
$ blts_bluetooth_test test.log "Core-Bluetooth Read HCI controller information remote" 00:00:00:00:00:00
$ blts_bluetooth_test test.log "Core-Bluetooth Read connected link information local"
$ blts_bluetooth_test test.log "Core-Bluetooth Read connected link information remote" 00:00:00:00:00:00
$ invoke-rc.d bluetooth stop or $ initctl stop bluetoothd depending on distribution).
$ blts_bluetooth_test test.log "Core-Bluetooth authentication with pairing as master" 00:00:00:00:00:00
$ invoke-rc.d bluetooth stop or $ initctl stop bluetoothd depending on distribution).
$ blts_bluetooth_test test.log "Core-Bluetooth authentication with pairing as slave"
The test module can be compiled to both a self-sufficient command line program and a Min test framework module. Debian packaging is provided.
| Bluez | Bluez stack home page |
| Bluetooth | Bluetooth |
| Version | Date | Handled By | Status | Comments |
|---|---|---|---|---|
| 0.1 | 22-sep-2010 | Iekku Huttunen | Draft | Page created |