IUT works as an RFCOMM Client. The peer device, RFCOMM server, is a PC
running bumble.
Add following test cases:
Case 6, RFCOMM MTU Size Data Send/Receive Test. To verify that the RFCOMM
client can correctly send and receive data packets that are exactly equal
to the negotiated MTU size.
Case 7, RFCOMM Data Transfer Exceeding MTU Size Test. To verify that the
RFCOMM client can reject sending and receiving data packets that exceed
the negotiated MTU size.
Case 8, RFCOMM Disconnect and Reconnect Test. To verify that the RFCOMM
client can properly handle a normal RFCOMM disconnection and successfully
reestablish the connection.
Case 9, RFCOMM Recovery After ACL Disconnection Test. To verify that the
RFCOMM client can properly recover when the underlying ACL connection is
abruptly disconnected, by reestablishing both ACL and RFCOMM connections.
Signed-off-by: Jiawei Yang <jiawei.yang_1@nxp.com>
IUT works as an SM Initiator/Responder. The peer device,
SM Responder/Initiator, is a PC running bumble on it.
Add shell commands to create and manage L2CAP server and channel with
different security level.
In the test suite, there are 5 test cases. The test matrix combines
each bonding flag:
| Test Case ID | Initiator | Responder | Expected Result |
|--------------|-----------|-----------|-----------------|
| BR_SM_Bonding_INIT_001 | Non-bondable | Non-bondable | Pass |
| BR_SM_Bonding_INIT_005 | General Bonding | General Bonding | Pass |
| BR_SM_Bonding_RSP_010 | Non-bondable | Non-bondable | Pass |
| BR_SM_Bonding_RSP_011 | General Bonding | Non-bondable | Fail |
| BR_SM_Bonding_RSP_014 | General Bonding | General Bonding | Pass |
Signed-off-by: Can Wang <can.wang@nxp.com>
IUT works as an SM Initiator/Responder. The peer device,
SM Responder/Initiator, is a PC running bumble on it.
Add shell commands to create and manage L2CAP server and channel with
different security level, reboot the board, and transfer data on the
SDP channel.
In the test suite, there are 28 test cases to verify SMP functions.
The test case list is:
- BR_SM_INIT_001: Basic Pairing with No Input No Output Capability
- BR_SM_INIT_002: Pairing with Display Only Capability
- BR_SM_INIT_003: Pairing with Keyboard Only Capability
- BR_SM_INIT_005: L2CAP Connection Failure After Successful Pairing
- BR_SM_INIT_006: L2CAP Server with Incoming Connection
- BR_SM_INIT_008: ACL Disconnection During Pairing
- BR_SM_INIT_011: Repeated Pairing Between Same Devices
- BR_SM_INIT_012: Security Level Escalation
- BR_SM_INIT_013: Multiple Channel Establishment
- BR_SM_INIT_017: Pairing Rejection by Remote Device
- BR_SM_INIT_018: Pairing Timeout
- BR_SM_INIT_021: Authentication Failure during Pairing
- BR_SM_INIT_022: Secure Connection vs. Legacy Pairing Fallback
- BR_SM_INIT_025: Rejection of Weak Pairing Methods
- BR_SM_INIT_028: Reconnection After Key Deletion
- BR_SM_INIT_029: Pairing with Delayed Response
- BR_SM_INIT_030: Stress Testing with Multiple Connect/Disconnect Cycles
- BR_SM_INIT_032: Power Loss Recovery
- BR_SM_INIT_034: Pairing During Active Data Transfer
- BR_SM_INIT_035: Pairing with Very Long PIN/Passkey
- BR_SM_INIT_037: Pairing with Peripheral Requesting Maximum Key Size
- BR_SM_INIT_039: Security Level Downgrade Attempt
- BR_SM_RSP_001: Basic Non-bondable Pairing with No Input No Output
- BR_SM_RSP_002: Display Only with Secure Connection
- BR_SM_RSP_003: Keyboard Only with Dedicated Bonding
- BR_SM_RSP_006: Security Level Enforcement
- BR_SM_RSP_008: L2CAP Connection with Security Level 1
- BR_SM_RSP_009: L2CAP Server with Security Level 2
Signed-off-by: Can Wang <can.wang@nxp.com>
IUT works as an SM Initiator/Responder. The peer device,
SM Responder/Initiator, is a PC running bumble on it.
Add shell commands to create and manage L2CAP server and channel with
different security level.
In the test suite, there are 10 test cases. IUT is configured
with Secure Connections Only Mode. The peer device is configured with
Secure Connections Mode or Legacy Mode. The test matrix is:
| Case ID | Secure Connection Option | Security Level | Expected Result |
|---------|--------------------------|----------------|-----------------|
| BR_SM_SC_INIT_005 | SC Only with SC | Level 4 | Pass |
| BR_SM_SC_INIT_006 | SC Only with SC | Level 1 | Fail |
| BR_SM_SC_INIT_007 | SC Only with SC | Level 2 | Fail |
| BR_SM_SC_INIT_008 | SC Only with SC | Level 3 | Fail |
| BR_SM_SC_INIT_009 | SC Only with Legacy | Level 3 | Fail |
| BR_SM_SC_RSP_005 | SC Only with SC | Level 1 | Fail |
| BR_SM_SC_RSP_006 | SC Only with SC | Level 2 | Fail |
| BR_SM_SC_RSP_007 | SC Only with SC | Level 3 | Fail |
| BR_SM_SC_RSP_008 | SC Only with SC | Level 4 | Pass |
| BR_SM_SC_RSP_009 | SC Only with Legacy | Level 3 | Fail |
Signed-off-by: Can Wang <can.wang@nxp.com>
IUT works as an RFCOMM Server. The peer device, RFCOMM Client, is a PC
running bumble on it.
Add shell commands to create and manage RFCOMM server with different
flow control mechanisms.
In the test suite, there are seven test cases:
Case 1: RFCOMM Server - Reject RFCOMM Session. IUT should properly
reject incoming RFCOMM session when BR connection is disconnected.
Case 2: RFCOMM Server - Forward compatible with Bluetooth devices that
do not send PN command. IUT should properly handle this case and use
FCON/FCOFF as flow control.
RPN, Test) and send NSC responses
Case 3: RFCOMM Server - Respond to Control Commands After DLC
Establishment. IUT should properly respond to control commands (RLS,
RPN, Test) and send NSC responses.
Case 4: RFCOMM Server - Information Transfer with Aggregate Flow
Control. IUT should handle information transfer with aggregate flow
control and properly issue flow control signals.
Case 5: RFCOMM Server - Information Transfer with Credit Based Flow
Control and Active Disconnection. IUT should handle credit-based flow
control and actively disconnect DLC.
Case 6: RFCOMM Server - Information Transfer with Credit Based Flow
Control and Passive Disconnection. IUT should handle credit-based flow
control and respond to DLC disconnection.
Signed-off-by: Jiawei Yang <jiawei.yang_1@nxp.com>
Attempting this would fail (assuming the controller is implemented
correctly) because when using legacy commands it is not allowed to
change the device address while scanning.
It also did not make sense. If we have configured the scanner to use
the identity address as own_addr, because the advertiser and scanner
addresses are shared when using legacy commands, setting the adv NRPA
here would overwrite the identity address used by the scanner, which
I assume is not the intention.
Signed-off-by: Olivier Lesage <olivier.lesage@nordicsemi.no>
In 25c993e5b7 a new case was introduced
where own_addr_type is not set by bt_id_set_scan_own_addr properly.
This led to issues for users where increasing their zephyr version
led to failures to start scanning after advertising in the case where
CONFIG_BT_SCAN_WITH_IDENTITY=n and legacy advertising commands are used.
Signed-off-by: Olivier Lesage <olivier.lesage@nordicsemi.no>
IUT works as an RFCOMM Client. The peer device, RFCOMM server, is a PC
running bumble.
In the test suite, there are five test cases:
Case 1, RFCOMM Client with Command Responses. Tests that the client can
establish a DLC, respond to various commands (RLS, RPN, Test), send NSC
responses, and properly handle DLC disconnection and RFCOMM session
shutdown.
Case 2, RFCOMM Client with Credit Based Flow Control. Tests that the
client can establish a DLC, perform information transfer with credit
based flow control, initiate disconnection, and shutdown the RFCOMM
session.
Case 3, RFCOMM Client with BR Connection Disconnection. Tests that the
client correctly handles scenarios where the BR connection is
disconnected during DLC establishment.
Case 4, RFCOMM Client with Aggregate Flow Control. Tests that the client
can establish a DLC, perform information transfer with aggregate flow
control, and properly handle disconnection and session shutdown.
Case 5, RFCOMM Client with Failed PN Response. Tests that the client
correctly handles scenarios where it fails to receive a PN response when
establishing a DLC.
Signed-off-by: Jiawei Yang <jiawei.yang_1@nxp.com>
Adds a new abstract struct for unicast group that is
specific for CAP. The difference between this and the BAP
unicast group, is that the parameters are CAP streams and
thus ensuring that the streams in the group adhere to the
additional requirements that CAP has on top of BAP.
This also adds foreach functions for both CAP and BAP
to allow users to iterate on the streams in the
abstract groups.
Various samples, modules and tests have been updated
to use the CAP struct and API.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
This adds support for BTP commands and events required for running
PAST tests.
struct btp_gap_ev_periodic_transfer_received_ev is also adjusted
to match BTP specification.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Updated the tester README with configuration options required to
build with support for btsnoop and SEGGER RTT log backends. This
helps developers capture logs for debugging and analysis during
Bluetooth testing.
Signed-off-by: Szymon Czapracki <szymon.czapracki@codecoup.pl>
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>
Fix issues reported by string validation which was added to strings
used in zassert macros.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Update the includes so that only what is actually used is included,
and so that everything is used is includes (IWYU).
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Removes the dependency on the host mocks for LE Audio tests.
This is done by copying the missing mocks for assert into
the audio mocks, and then always including ztest.h.
The inclusion of ztest.h is due to the fact that
arch/cpu.h does not have an appropriate header file for
ztest, and some header files depend on ARCH_STACK_PTR_ALIGN
which is usually defined by those headers in cpu.h. However
ztest.h does define this value as well, and thus needs
to be included always.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
After https://github.com/zephyrproject-rtos/zephyr/pull/72090,
`conn_tx_alloc` no longer blocks, and each buffer always has a
corresponding `bt_conn_tx` object. This eliminates the need to configure
the number of `bt_conn_tx` objects via `CONFIG_BT_CONN_TX_MAX`, since
every buffer now carries its own context even when no callback is used.
This commit deprecates `CONFIG_BT_CONN_TX_MAX` as it is no longer
necessary. Instead, `CONFIG_BT_BUF_ACL_TX_COUNT` is used to allocate
`bt_conn_tx` objects for outgoing ACL data. ZLL already uses
`CONFIG_BT_BUF_ACL_TX_COUNT` to configure the number of outgoing ACL
packets. With this change, modifying the packet count will automatically
adjust the number of corresponding contexts, preventing both context
starvatoin and underutilization.
This approach also aligns with ISO, where the number of `bt_conn_tx`
objects for outgoing ISOdata matches `CONFIG_BT_ISO_TX_BUF_COUNT`.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Change the ACL buffer sizes to be a higher value than the
default, as that caused some issues with the CIS established
event.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Default the BT Tester to use the overlay-bt_ll_sw_split.conf for all
Zephyr based configurations.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Adds a new BT controller configuration that can be applied
to multiple boards and not specific to the nRF5340 cpunet
as the existing setup uses from hci_ipc.
The config is based on nrf5340_cpunet_iso-bt_ll_sw_split.conf
from hci_ipc sample.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The stream_started and stream_stopped callbacks are called for
both broadcast sink and source in the BT Tester, and thus
they should check if the stream can send before attempting
to register it for TX (which would otherwise fail).
This also guards the call to btp_send_bis_syced_ev so that
the event is only sent for broadcast sinks.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
This commit refactors when the BTP_ASCS_EV_OPERATION_COMPLETED
is sent to the upper tester. Previously it was send
in the stream changed callbacks, but that would send
the events to the BAP Unicast Server when it did not initiate
any changes, and would not properly match when the control
point operation was completed (which happens before the
ASE state changes).
This change makes it easier to determine when an operation was
actually completed, and easier to separate that from a
ASE state change which is another type of event.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The ase state changed event was only sent when entering the
streaming state, rather whenever there is a state change.
This commit sends the event for all ASE/stream state changes.
To make it clear that these are called in the callbacks,
the callbacks have all been suffixed with _cb.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Fixes trivial typo
Co-authored-by: Harry Martin <48959255+Harry-Martin@users.noreply.github.com>
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Update the README file to be .rst instead of (implied) .md
and update the text w.r.t. supported profiles and services,
and how to build for LE Audio.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Updates the includes in a a few files to
avoid including unused header files and include the
ones that are used.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Update the Bluetooth tests to assume the new H:4 encoding for data that's
passing between HCI drivers and their users (normally the host stack).
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
- Added new shield to add support for WIFI and BT interface.
- Added board overlay for MIMXRT1060EVKC.
- Removed mimxrt1062 overlay from shell example to avoid conflicts.
- Added seperate shield overlay for supported M.2 module to enable
BT or WIFI or Both.
- Added default kconfigs for each BT and WIFI which enables supported
modules and SoC as part of enabled shield through build param.
- Added shield document.
Signed-off-by: Nirav Agrawal <nirav.agrawal@nxp.com>
Update the includes so that only what is actually used is included,
and so that everything is used is includes (IWYU).
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Add test case bluetooth.general.tester_br_edr.
Add overlay `zephyr,sram` and `zephyr,uart-pipe` for the board.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
Set following configuration by default,
CONFIG_BT_CLASSIC=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_SMP=y
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_PAGE_TIMEOUT=0xFFFF
When building the project, the argument `--extra-conf prj_br.conf`
needs to be appended for BR.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
If the L2CAP connection response of command `listen` is
`BTP_L2CAP_CONNECTION_RESPONSE_INSUFF_SEC_AUTHEN`, set the security
level of L2CAP server to level 4.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
The error code `-EBUSY` of `bt_conn_set_security` means the
pairing/encryption procedure is ongoing. Ignore the error code.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
Compare with BTP GAP pair, the pair_v2 add more arguments, including
security mode, security level, and flags.
The argument `security mode` is used to set the security mode.
The argument `security level` is used to set the security level of the
specific security mode.
The argument `flags` is used to add additional setting, such as flag
`BTP_GAP_PAIR_V2_FLAG_FORCE_PAIR` is used to force the pairing
procedure.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
