981c79b7ce
Bluetooth Mesh Protocol 1.1 is backward compatible with Bluetooth Mesh Profile 1.0.1, therefore the stack can still be qualified for 1.0.1 if needed. But explicit support for both versions requires additional maintenance efforts and doubles the CI time. To make the stack qualifiable for 1.0.1, the one needs to remove Private Beacons reception and compile out SHA256 algorithm support. What is changed: - Removed `CONFIG_BT_MESH_V1d1` option. - Removed `transport_legacy.c` which was using 1.0.1 implementation. The new transport layer has new SaR logic that should still be possible to qualify for 1.0.1. - Removed the legacy transport Kconfig options. They are superseded by the new transport Kconfig options. - Tester app: `overlay-mesh-v1d1.conf` is merged into `overlay-mesh.conf`. - Removed BabbleSim tests for 1.0.1. - Updated documentation. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
22 lines
853 B
Bash
Executable File
22 lines
853 B
Bash
Executable File
#!/usr/bin/env bash
|
|
# Copyright 2022 Nordic Semiconductor
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
source $(dirname "${BASH_SOURCE[0]}")/../../_mesh_test.sh
|
|
|
|
# Test that a maximum length SDU can be processed with SAR,
|
|
# even with "stressed" transmitter and receiver configurations.
|
|
# Test procedure:
|
|
# 1. Initialize Client and Server instances.
|
|
# 2. Bind "dummy" vendor model to both instances.
|
|
# 3. Configure SAR transmitter and receiver states.
|
|
# 4. The Client sends a Get-message with a maximum length SDU, targeting the server.
|
|
# 5. The Server responds with a maximum length SDU Status-message.
|
|
# 6. The test passes when the Client successfully receives the Status response.
|
|
RunTest sar_test \
|
|
sar_cli_max_len_sdu_send sar_srv_max_len_sdu_receive
|
|
|
|
overlay=overlay_psa_conf
|
|
RunTest sar_test_psa \
|
|
sar_cli_max_len_sdu_send sar_srv_max_len_sdu_receive
|