[RFC PATCH] Bluetooth: l2cap: honor local LE connection interval range

[RFC PATCH] Bluetooth: l2cap: honor local LE connection interval range

[Kyle Pepper]

Intersect a valid peer request with the locally configured interval
range. Reject disjoint ranges and preserve validation of the original
request before applying local policy.

Assisted-by: OpenCode:gpt-6.1-sol
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Submission review notes (not part of the commit message):
October 12 no-intersection trial accepts [16,24] and completes 30 ms
with STATUS 03 02 18 and normal host TX; the user hears silence. Volume
and multi-day acoustic comparison controls are incomplete. The working
intersection yields 20 ms. Maximum-only rejection failed in kernel 5
and is not this proposal. Generic minimum/range policy and LL-path
consistency remain RFC questions, not established by one renderer.

 net/bluetooth/l2cap_core.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 49a998804..49e201d3e 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4968,6 +4968,13 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
 	memset(&rsp, 0, sizeof(rsp));
 
 	err = hci_check_conn_params(min, max, latency, to_multiplier);
+	if (!err) {
+		/* Apply local policy only after validating the peer's request. */
+		min = max_t(u16, min, hcon->le_conn_min_interval);
+		max = min_t(u16, max, hcon->le_conn_max_interval);
+		err = hci_check_conn_params(min, max, latency, to_multiplier);
+	}
+
 	if (err)
 		rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
 	else

base-commit: 964430c038967fd06643e866f68115664e1a1bd1

RE: [RFC] Bluetooth: l2cap: honor local LE connection interval range

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1073 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/series/1184338/

---Test result---

Test Summary:
CheckPatch                    PASS      0.60 seconds
VerifyFixes                   PASS      0.08 seconds
VerifySignedoff               PASS      0.08 seconds
GitLint                       PASS      0.24 seconds
SubjectPrefix                 PASS      0.08 seconds
BuildKernel                   PASS      29.43 seconds
CheckAllWarning               PASS      33.15 seconds
CheckSparse                   PASS      35.82 seconds
BuildKernel32                 PASS      29.12 seconds
CheckKernelLLVM               PASS      32.99 seconds
TestRunnerSetup               PASS      699.77 seconds
TestRunner_l2cap-tester       PASS      12.84 seconds
IncrementalBuild              PASS      28.11 seconds



https://github.com/bluez/bluetooth-next/pull/909

---
Regards,
Linux Bluetooth

Re: [RFC PATCH] Bluetooth: l2cap: honor local LE connection interval range

[Luiz Augusto von Dentz]

Hi Kyle,

On Mon, Oct 12, 2026 at 11:31 PM Kyle Pepper <cochcoder@proton.me> wrote:
>
> Intersect a valid peer request with the locally configured interval
> range. Reject disjoint ranges and preserve validation of the original
> request before applying local policy.
>
> Assisted-by: OpenCode:gpt-6.1-sol
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
> Submission review notes (not part of the commit message):
> October 12 no-intersection trial accepts [16,24] and completes 30 ms
> with STATUS 03 02 18 and normal host TX; the user hears silence. Volume
> and multi-day acoustic comparison controls are incomplete. The working
> intersection yields 20 ms. Maximum-only rejection failed in kernel 5
> and is not this proposal. Generic minimum/range policy and LL-path
> consistency remain RFC questions, not established by one renderer.

I need to check the git history but I believe we tried something
similar not long ago that created interoperability problems if we use
strict range matching like this.

>  net/bluetooth/l2cap_core.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 49a998804..49e201d3e 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -4968,6 +4968,13 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
>         memset(&rsp, 0, sizeof(rsp));
>
>         err = hci_check_conn_params(min, max, latency, to_multiplier);
> +       if (!err) {
> +               /* Apply local policy only after validating the peer's request. */
> +               min = max_t(u16, min, hcon->le_conn_min_interval);
> +               max = min_t(u16, max, hcon->le_conn_max_interval);
> +               err = hci_check_conn_params(min, max, latency, to_multiplier);
> +       }
> +
>         if (err)
>                 rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
>         else
>
> base-commit: 964430c038967fd06643e866f68115664e1a1bd1
>


-- 
Luiz Augusto von Dentz

Re: [RFC PATCH] Bluetooth: l2cap: honor local LE connection interval range

[cochcoder]

Thanks for pointing this out. I looked at the git history and confirmed the interoperability problem. I've sent a RFC v2 as 20261015043336.47734-1-cochcoder@proton.me. It prefers a valid overlap but preserves the original valid peer request when there is no usable overlap, rather than rejecting it. The native controls cover overlap, fast HID, slow idle and exact-match requests. The strict-bound version rejects the HID and idle cases. The revised full L2CAP suite passes 115/115.



On Tuesday, October 13th, 2026 at 10:33 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:

> Hi Kyle,
>
> On Mon, Oct 12, 2026 at 11:31 PM Kyle Pepper <cochcoder@proton.me> wrote:
> >
> > Intersect a valid peer request with the locally configured interval
> > range. Reject disjoint ranges and preserve validation of the original
> > request before applying local policy.
> >
> > Assisted-by: OpenCode:gpt-6.1-sol
> > Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> > ---
> > Submission review notes (not part of the commit message):
> > October 12 no-intersection trial accepts [16,24] and completes 30 ms
> > with STATUS 03 02 18 and normal host TX; the user hears silence. Volume
> > and multi-day acoustic comparison controls are incomplete. The working
> > intersection yields 20 ms. Maximum-only rejection failed in kernel 5
> > and is not this proposal. Generic minimum/range policy and LL-path
> > consistency remain RFC questions, not established by one renderer.
>
> I need to check the git history but I believe we tried something
> similar not long ago that created interoperability problems if we use
> strict range matching like this.
>
> >  net/bluetooth/l2cap_core.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index 49a998804..49e201d3e 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -4968,6 +4968,13 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
> >         memset(&rsp, 0, sizeof(rsp));
> >
> >         err = hci_check_conn_params(min, max, latency, to_multiplier);
> > +       if (!err) {
> > +               /* Apply local policy only after validating the peer's request. */
> > +               min = max_t(u16, min, hcon->le_conn_min_interval);
> > +               max = min_t(u16, max, hcon->le_conn_max_interval);
> > +               err = hci_check_conn_params(min, max, latency, to_multiplier);
> > +       }
> > +
> >         if (err)
> >                 rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
> >         else
> >
> > base-commit: 964430c038967fd06643e866f68115664e1a1bd1
> >
>
>
> --
> Luiz Augusto von Dentz
>

[RFC PATCH v2] Bluetooth: l2cap: prefer compatible local LE intervals

[Kyle Pepper]

Use a valid intersection of a peer interval range and local preferences
when they overlap. Otherwise retain the peer request instead of treating
an initial preference as a hard supported bound.

Validate the original wire request first. Only narrow its interval range;
leave latency, timeout and disjoint-range acceptance unchanged.

Assisted-by: OpenCode:gpt-6.1-sol
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Changes from v1:
- Treat local ranges as preferences, not supported bounds.
- Prefer a valid intersection; otherwise keep the original valid peer request.
- Never repair an invalid original request by clipping.
- Preserve latency, supervision timeout and disjoint-range acceptance.

Four native controls check both the accepted L2CAP response and resulting HCI
update range: overlap, fast HID fallback, slow idle fallback and exact match.
Baseline passes 3/4 (no narrower overlap); the strict-bound negative control
passes 2/4 (rejects HID/idle); this revision passes 4/4. Its full reference-guest
L2CAP suite passes 115/115 without skips or captured KASAN/lockdep alerts.
The source-extracted sanitizer fixture passes 397,723 parameter cases plus two
framing/role cases. These are finite tests, not proof for every controller.

The independent BlueZ interval-test companion is not yet sent. Its overlap test
intentionally fails without this Linux change. ASHA completed-interval startup
and stream gating are separate profile work, not a new kernel ABI or hard bound.

A combined Arch 7.2.9 trial with this change and revised BlueZ was built in a
clean chroot. I report that stack working on hardware; the running test kernel
and BlueZ package versions were verified. This is combined-stack evidence,
not isolated attribution or complete N7/paired-device/negative-path coverage.
It is not hardware testing of the bluetooth-next kernel itself. Remote CI for
this revision has not run. Target master still matches the tested source base.

 net/bluetooth/l2cap_core.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4dd56e007..afde04a19 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5031,6 +5031,19 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
 	memset(&rsp, 0, sizeof(rsp));
 
 	err = hci_check_conn_params(min, max, latency, to_multiplier);
+	if (!err) {
+		u16 pref_min = max_t(u16, min, hcon->le_conn_min_interval);
+		u16 pref_max = min_t(u16, max, hcon->le_conn_max_interval);
+
+		/* Local preferences must not reject a valid peer request. */
+		if (pref_min <= pref_max &&
+		    !hci_check_conn_params(pref_min, pref_max, latency,
+					  to_multiplier)) {
+			min = pref_min;
+			max = pref_max;
+		}
+	}
+
 	if (err)
 		rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
 	else

base-commit: 397464709a204da9b8dc3b01d6ea42539d951cd2

RE: [RFC,v2] Bluetooth: l2cap: prefer compatible local LE intervals

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1348 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/series/1186108/

---Test result---

Test Summary:
CheckPatch                    PASS      0.80 seconds
VerifyFixes                   PASS      0.12 seconds
VerifySignedoff               PASS      0.12 seconds
GitLint                       FAIL      0.32 seconds
SubjectPrefix                 PASS      0.11 seconds
BuildKernel                   PASS      29.45 seconds
CheckAllWarning               PASS      33.54 seconds
CheckSparse                   PASS      37.36 seconds
BuildKernel32                 PASS      29.54 seconds
CheckKernelLLVM               PASS      34.08 seconds
TestRunnerSetup               PASS      705.13 seconds
TestRunner_l2cap-tester       PASS      12.94 seconds
IncrementalBuild              PASS      27.88 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[RFC,v2] Bluetooth: l2cap: prefer compatible local LE intervals

22: B1 Line exceeds max length (81>80): "passes 2/4 (rejects HID/idle); this revision passes 4/4. Its full reference-guest"


https://github.com/bluez/bluetooth-next/pull/940

---
Regards,
Linux Bluetooth

[RFC PATCH v3] Bluetooth: l2cap: prefer compatible local LE intervals

[Kyle Pepper]

Use a valid intersection of a peer interval range and local preferences
when they overlap. Otherwise retain the peer request instead of treating
an initial preference as a hard supported bound.

Validate the original wire request first. Only narrow its interval range;
leave latency, timeout and disjoint-range acceptance unchanged.

Assisted-by: OpenCode:gpt-6.1-sol
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Changes since v2:
- Wrap test notes to avoid the GitLint B1 failure in series 1186108.
- Refresh onto bluetooth-next ff8b09806b7b; no source delta from v2.

Changes from v1 retained:
- Treat local ranges as preferences, not supported bounds.
- Prefer a valid intersection; otherwise keep the valid peer request.
- Never repair an invalid original request by clipping.
- Preserve latency, supervision timeout and disjoint-range acceptance.

Prior native controls check the accepted L2CAP response and HCI range:
overlap, fast HID fallback, slow idle fallback and exact match. Baseline
passes 3/4; strict bounds pass 2/4 (reject HID/idle); v2 passes 4/4.
The prior reference-guest full L2CAP suite passes 115/115, without skips
or captured KASAN/lockdep alerts. These are prior runs, not fresh v3 VMs.

The independent BlueZ test companion was sent as:
https://lore.kernel.org/r/20261015044221.55631-1-cochcoder@proton.me
Its overlap case intentionally fails without this kernel change.
Completed-interval startup/stream gating remains separate profile work.

The saved v2 CI report lists all jobs except GitLint passing, including
the native L2CAP tester. This is not a remote CI result for v3.
The combined Arch trial is reported working on hardware, not isolated
testing of bluetooth-next or exhaustive device/negative-path coverage.

 net/bluetooth/l2cap_core.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4dd56e007..afde04a19 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5031,6 +5031,19 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
 	memset(&rsp, 0, sizeof(rsp));
 
 	err = hci_check_conn_params(min, max, latency, to_multiplier);
+	if (!err) {
+		u16 pref_min = max_t(u16, min, hcon->le_conn_min_interval);
+		u16 pref_max = min_t(u16, max, hcon->le_conn_max_interval);
+
+		/* Local preferences must not reject a valid peer request. */
+		if (pref_min <= pref_max &&
+		    !hci_check_conn_params(pref_min, pref_max, latency,
+					  to_multiplier)) {
+			min = pref_min;
+			max = pref_max;
+		}
+	}
+
 	if (err)
 		rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
 	else

base-commit: ff8b09806b7b18884ad8d3a2b3d702da534a4e21

RE: [RFC,v3] Bluetooth: l2cap: prefer compatible local LE intervals

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1073 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/series/1186705/

---Test result---

Test Summary:
CheckPatch                    PASS      0.69 seconds
VerifyFixes                   PASS      0.15 seconds
VerifySignedoff               PASS      6.34 seconds
GitLint                       PASS      9.00 seconds
SubjectPrefix                 PASS      0.48 seconds
BuildKernel                   PASS      28.32 seconds
CheckAllWarning               PASS      33.29 seconds
CheckSparse                   PASS      35.57 seconds
BuildKernel32                 PASS      28.55 seconds
CheckKernelLLVM               PASS      32.07 seconds
TestRunnerSetup               PASS      663.93 seconds
TestRunner_l2cap-tester       PASS      12.35 seconds
IncrementalBuild              PASS      29.45 seconds



https://github.com/bluez/bluetooth-next/pull/951

---
Regards,
Linux Bluetooth