IUT works as a Bluetooth GAP Client. The peer device (tester) is
configured to respond to inquiries and process connection requests.
Add tests to verify GAP client functionality for inquiry, connection,
and disconnection scenarios.
In the test suite, there are six test cases:
Case 1: General Inquiry followed by Connection and Active Disconnection.
Verifies that DUT can perform general inquiry, establish connection, and
actively disconnect from tester.
Case 2: General Inquiry followed by Connection and Passive
Disconnection. Verifies that DUT can perform general inquiry, establish
connection, and handle disconnection initiated by tester.
Case 3: General Inquiry followed by Rejected Connection Request.
Verifies that DUT can perform general inquiry and handle connection
rejection from tester.
Case 4: Limited Inquiry followed by Connection and Active Disconnection.
Verifies that DUT can perform limited inquiry, establish connection, and
actively disconnect from tester.
Case 5: Limited Inquiry followed by Connection and Passive
Disconnection. Verifies that DUT can perform limited inquiry, establish
connection, and handle disconnection initiated by tester.
Case 6: Limited Inquiry followed by Rejected Connection Request.
Verifies that DUT can perform limited inquiry and handle connection
rejection from tester.
Signed-off-by: Jiawei Yang <jiawei.yang_1@nxp.com>
IUT works as a GAP Server (Peripheral) in the Bluetooth system. The peer
device, GAP Client,
is a PC running Bumble as a test tool.
This test suite implements the following test cases:
Case 1, Non-connectable Mode Testing. Verifies DUT can operate in
non-connectable mode without allowing connections.
Case 2, Connectable Non-discoverable Mode with Active Disconnection.
Verifies DUT can accept connections and initiate disconnection.
Case 3, Connectable Non-discoverable Mode with Passive Disconnection.
Verifies DUT can accept connections and handle passive disconnection.
Case 4, Connectable Non-discoverable Mode with Connection Rejection.
Verifies DUT can reject connection requests.
Case 5, Limited Discoverable Mode with Active Disconnection. Verifies
DUT in limited discoverable mode can be discovered, accept connections
and initiate disconnection.
Case 6, Limited Discoverable Mode with Passive Disconnection. Verifies
DUT can be discovered, accept connections and handle passive
disconnection.
Case 7, Limited Discoverable Mode with Connection Rejection. Verifies
DUT can be discovered but reject connection requests.
Case 8, General Discoverable Mode with Active Disconnection. Verifies
DUT in general discoverable mode can be discovered, accept connections
and initiate disconnection.
Case 9, General Discoverable Mode with Passive Disconnection. Verifies
DUT can be discovered, accept connections and handle passive
disconnection.
Case 10, General Discoverable Mode with Connection Rejection. Verifies
DUT can be discovered but reject connection requests.
Signed-off-by: Jiawei Yang <jiawei.yang_1@nxp.com>
Add dedicated test case `bluetooth.classic.sdp.server.no_blobs` and
`bluetooth.classic.sdp.client.no_blobs` with the extra argument
`CONFIG_BUILD_ONLY_NO_BLOBS=y` and `build_only: true` to make sure the
tests sdp_s and sdp_c can be passed by Zephyr CI.
Fixes#88060.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
On Linux, the function `power_on()` of Bumble will fail when executing
even-numbered test cases.
From the `btmon` log, the controller will not reply the `HCI Command:
Reset` when the issue occurs.
Add a try-except to catch the exception of the function `power_on()`,
and retry to call the function `power_on()` until issue no longer
occurs. Or, the test will fail due to the timeout.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
IUT works as a SDP Server. The peer device, SDP client, is a PC with
running `bumble` on it.
Define 10 SDP records. 8 normal SDP records. one SDP record with large
service name that cannot be discovered by peer since the data length
exceeds the MTU of SDP. And one SDP record with large service name
that can be discovered by peer but `continuation state` needs to be
involved.
By default, no SDP record will be registered.
Add shell command `register_sdp` to register specific SDP record.
Add shell command `register_sdp_all` to register all normal SDP
records.
Add shell command `register_sdp_large` to register SDP record with
large service name that cannot be discovered by peer.
Add shell command `register_sdp_large_valid` to register SDP record
with large service name that can be discovered by peer.
In the test suite, there two test cases,
Case 1, discover the IUT.
Case 2, connect to the IUT. And send serial SDP discovery requests.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
The Bluetooth Classic sdp_client was the last user
of the ctx_shell, which could easily be removed.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
IUT works as a SDP Client. The peer device, SDP server, is a PC with
running `bumble` on it.
Add shell command `discovery` to discover specific SDP record
according to specific UUID.
In the test suite, there are three groups test cases,
Group 1 is for Service Search Attribute transaction.
Group 2 is for Service Search transaction.
Group 3 is for Service Attribute transaction.
For each test group, there are four test cases,
Case 1, No SDP record is registered on PC. IUT should not find any SDP
record.
Case 2, A2DP source SDP record is registered on PC. IUT can find SDP
record. And the discovered PSM and version should be same with
registered.
Case 3, A2DP source and HFP HF SDP Records are registered. IUT can
find SDP record. And the discovered RFCOMM channel and HFP version
should be same with registered. This case is used to test the
"continuation state information".
Case 4, Multiple SDP Records are registered. This case is used to test
the "continuation state information". And also it used to test the
total length exceeds the ACL RX Buffer Size.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
