* [PATCH] Bluetooth: l2cap: Process valid commands in too long frame
@ 2025-04-11 16:29 Frédéric Danis
2025-04-11 17:05 ` bluez.test.bot
2025-04-11 17:30 ` [PATCH] " Luiz Augusto von Dentz
0 siblings, 2 replies; 3+ messages in thread
From: Frédéric Danis @ 2025-04-11 16:29 UTC (permalink / raw)
To: linux-bluetooth
This is required for passing PTS test cases:
- L2CAP/COS/CED/BI-14-C
Multiple Signaling Command in one PDU, Data Truncated, BR/EDR,
Connection Request
- L2CAP/COS/CED/BI-15-C
Multiple Signaling Command in one PDU, Data Truncated, BR/EDR,
Disconnection Request
The test procedure defined in L2CAP.TS.p39 for both tests is:
1. The Lower Tester sends a C-frame to the IUT with PDU Length set
to 8 and Channel ID set to the correct signaling channel for the
logical link. The Information payload contains one L2CAP_ECHO_REQ
packet with Data Length set to 0 with 0 octets of echo data and
one command packet and Data Length set as specified in Table 4.6
and the correct command data.
2. The IUT sends an L2CAP_ECHO_RSP PDU to the Lower Tester.
3. Perform alternative 3A, 3B, 3C, or 3D depending on the IUT’s
response.
Alternative 3A (IUT terminates the link):
3A.1 The IUT terminates the link.
3A.2 The test ends with a Pass verdict.
Alternative 3B (IUT discards the frame):
3B.1 The IUT does not send a reply to the Lower Tester.
Alternative 3C (IUT rejects PDU):
3C.1 The IUT sends an L2CAP_COMMAND_REJECT_RSP PDU to the
Lower Tester.
Alternative 3D (Any other IUT response):
3D.1 The Upper Tester issues a warning and the test ends.
4. The Lower Tester sends a C-frame to the IUT with PDU Length set
to 4 and Channel ID set to the correct signaling channel for the
logical link. The Information payload contains Data Length set to
0 with an L2CAP_ECHO_REQ packet with 0 octets of echo data.
5. The IUT sends an L2CAP_ECHO_RSP PDU to the Lower Tester.
With expected outcome:
In Steps 2 and 5, the IUT responds with an L2CAP_ECHO_RSP.
In Step 3A.1, the IUT terminates the link.
In Step 3B.1, the IUT does not send a reply to the Lower Tester.
In Step 3C.1, the IUT rejects the PDU.
In Step 3D.1, the IUT sends any valid response.
Currently PTS fails with the following logs:
Failed to receive ECHO RESPONSE.
And HCI logs:
> ACL Data RX: Handle 11 flags 0x02 dlen 20
L2CAP: Information Response (0x0b) ident 2 len 12
Type: Fixed channels supported (0x0003)
Result: Success (0x0000)
Channels: 0x000000000000002e
L2CAP Signaling (BR/EDR)
Connectionless reception
AMP Manager Protocol
L2CAP Signaling (LE)
> ACL Data RX: Handle 11 flags 0x02 dlen 13
frame too long
08 01 00 00 08 02 01 00 aa .........
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
---
net/bluetooth/l2cap_core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index f1c4b8bd7a8b..46b2884170fa 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -7539,6 +7539,11 @@ void l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
if (skb->len > len) {
BT_ERR("Frame is too long (len %u, expected len %d)",
skb->len, len);
+ /* Process valid commands from the PDU before
+ * setting the socket unreliable
+ */
+ skb->len = len;
+ l2cap_recv_frame(conn, skb);
l2cap_conn_unreliable(conn, ECOMM);
goto drop;
}
--
2.43.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* RE: Bluetooth: l2cap: Process valid commands in too long frame
2025-04-11 16:29 [PATCH] Bluetooth: l2cap: Process valid commands in too long frame Frédéric Danis
@ 2025-04-11 17:05 ` bluez.test.bot
2025-04-11 17:30 ` [PATCH] " Luiz Augusto von Dentz
1 sibling, 0 replies; 3+ messages in thread
From: bluez.test.bot @ 2025-04-11 17:05 UTC (permalink / raw)
To: linux-bluetooth, frederic.danis
[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=952571
---Test result---
Test Summary:
CheckPatch PENDING 0.46 seconds
GitLint PENDING 0.28 seconds
SubjectPrefix PASS 0.09 seconds
BuildKernel PASS 24.51 seconds
CheckAllWarning PASS 27.83 seconds
CheckSparse PASS 30.60 seconds
BuildKernel32 PASS 24.21 seconds
TestRunnerSetup PASS 466.99 seconds
TestRunner_l2cap-tester PASS 24.31 seconds
TestRunner_iso-tester PASS 36.93 seconds
TestRunner_bnep-tester PASS 4.74 seconds
TestRunner_mgmt-tester FAIL 122.24 seconds
TestRunner_rfcomm-tester PASS 7.80 seconds
TestRunner_sco-tester PASS 12.56 seconds
TestRunner_ioctl-tester PASS 12.88 seconds
TestRunner_mesh-tester PASS 7.87 seconds
TestRunner_smp-tester PASS 10.04 seconds
TestRunner_userchan-tester PASS 7.21 seconds
IncrementalBuild PENDING 1.01 seconds
Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:
##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 490, Passed: 484 (98.8%), Failed: 2, Not Run: 4
Failed Test Cases
LL Privacy - Add Device 3 (AL is full) Failed 0.195 seconds
LL Privacy - Set Flags 1 (Add to RL) Failed 0.141 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:
---
Regards,
Linux Bluetooth
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Bluetooth: l2cap: Process valid commands in too long frame
2025-04-11 16:29 [PATCH] Bluetooth: l2cap: Process valid commands in too long frame Frédéric Danis
2025-04-11 17:05 ` bluez.test.bot
@ 2025-04-11 17:30 ` Luiz Augusto von Dentz
1 sibling, 0 replies; 3+ messages in thread
From: Luiz Augusto von Dentz @ 2025-04-11 17:30 UTC (permalink / raw)
To: Frédéric Danis; +Cc: linux-bluetooth
Hi Frédéric,
On Fri, Apr 11, 2025 at 12:29 PM Frédéric Danis
<frederic.danis@collabora.com> wrote:
>
> This is required for passing PTS test cases:
> - L2CAP/COS/CED/BI-14-C
> Multiple Signaling Command in one PDU, Data Truncated, BR/EDR,
> Connection Request
> - L2CAP/COS/CED/BI-15-C
> Multiple Signaling Command in one PDU, Data Truncated, BR/EDR,
> Disconnection Request
>
> The test procedure defined in L2CAP.TS.p39 for both tests is:
> 1. The Lower Tester sends a C-frame to the IUT with PDU Length set
> to 8 and Channel ID set to the correct signaling channel for the
> logical link. The Information payload contains one L2CAP_ECHO_REQ
> packet with Data Length set to 0 with 0 octets of echo data and
> one command packet and Data Length set as specified in Table 4.6
> and the correct command data.
> 2. The IUT sends an L2CAP_ECHO_RSP PDU to the Lower Tester.
> 3. Perform alternative 3A, 3B, 3C, or 3D depending on the IUT’s
> response.
> Alternative 3A (IUT terminates the link):
> 3A.1 The IUT terminates the link.
> 3A.2 The test ends with a Pass verdict.
> Alternative 3B (IUT discards the frame):
> 3B.1 The IUT does not send a reply to the Lower Tester.
> Alternative 3C (IUT rejects PDU):
> 3C.1 The IUT sends an L2CAP_COMMAND_REJECT_RSP PDU to the
> Lower Tester.
> Alternative 3D (Any other IUT response):
> 3D.1 The Upper Tester issues a warning and the test ends.
> 4. The Lower Tester sends a C-frame to the IUT with PDU Length set
> to 4 and Channel ID set to the correct signaling channel for the
> logical link. The Information payload contains Data Length set to
> 0 with an L2CAP_ECHO_REQ packet with 0 octets of echo data.
> 5. The IUT sends an L2CAP_ECHO_RSP PDU to the Lower Tester.
>
> With expected outcome:
> In Steps 2 and 5, the IUT responds with an L2CAP_ECHO_RSP.
> In Step 3A.1, the IUT terminates the link.
> In Step 3B.1, the IUT does not send a reply to the Lower Tester.
> In Step 3C.1, the IUT rejects the PDU.
> In Step 3D.1, the IUT sends any valid response.
>
> Currently PTS fails with the following logs:
> Failed to receive ECHO RESPONSE.
>
> And HCI logs:
> > ACL Data RX: Handle 11 flags 0x02 dlen 20
> L2CAP: Information Response (0x0b) ident 2 len 12
> Type: Fixed channels supported (0x0003)
> Result: Success (0x0000)
> Channels: 0x000000000000002e
> L2CAP Signaling (BR/EDR)
> Connectionless reception
> AMP Manager Protocol
> L2CAP Signaling (LE)
> > ACL Data RX: Handle 11 flags 0x02 dlen 13
> frame too long
> 08 01 00 00 08 02 01 00 aa .........
>
> Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
> ---
> net/bluetooth/l2cap_core.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index f1c4b8bd7a8b..46b2884170fa 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -7539,6 +7539,11 @@ void l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
> if (skb->len > len) {
> BT_ERR("Frame is too long (len %u, expected len %d)",
> skb->len, len);
> + /* Process valid commands from the PDU before
> + * setting the socket unreliable
> + */
You should probably quote the test cases here to explain that data
needs to be truncated, which I assume is why you are doing skb->len =
len bellow.
> + skb->len = len;
> + l2cap_recv_frame(conn, skb);
> l2cap_conn_unreliable(conn, ECOMM);
> goto drop;
> }
> --
> 2.43.0
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-04-11 17:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-11 16:29 [PATCH] Bluetooth: l2cap: Process valid commands in too long frame Frédéric Danis
2025-04-11 17:05 ` bluez.test.bot
2025-04-11 17:30 ` [PATCH] " Luiz Augusto von Dentz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox