Re: [PATCH] Bluetooth: L2CAP: rate-limit ECHO_RSP per signaling PDU

[Luiz Augusto von Dentz]

Hi Michael,

On Sun, May 17, 2026 at 9:03 PM Michael Bommarito
<michael.bommarito@xxxxxxxxx> wrote:
>
> On Sun, May 17, 2026 at 9:00 PM Muhammad Bilal <meatuni001@xxxxxxxxx> wrote:
> > A response counter covering all outbound responses generated per PDU
> > would close both paths. Something like:
> >
> >         int resp_count = 0;
> >
> >         /* in the error path: */
> >         if (err) {
> >                 if (++resp_count <= L2CAP_SIG_ECHO_BURST) {
> >                         BT_ERR("Wrong link type (%d)", err);
> >                         l2cap_sig_send_rej(conn, cmd->ident);
> >                 }
> >                 continue;
> >         }
> >
> >         /* existing echo path: */
> >         if (cmd->code == L2CAP_ECHO_REQ &&
> >             ++resp_count > L2CAP_SIG_ECHO_BURST) {
> >                 skb_pull(skb, len);
> >                 continue;
> >         }
> >
> > Using pr_warn_ratelimited() instead of BT_ERR() in the loop would
> > also reduce log amplification independent of the skb path.
>
> Thanks, good catch on both!  Luiz reminded me about
> pr_warn_ratelimited before and I missed that again.
>
> I'll give others an opportunity to weigh in and then send an updated v2.

Hmm, the spec does not have support limitation though, it just says:

Implementations shall be able to handle the reception of multiple
commands in an L2CAP packet sent over fixed channel CID 0x0001.
[] https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d

Perhaps we should define our Signalling MTU:

Signaling MTU (MTUsig)

The maximum size of command information that the L2CAP layer entity is
capable of accepting. The MTUsig, refers to the signaling channel only
and corresponds to the maximum size of a C-frame, omitting the size of
the Basic L2CAP header. The MTUsig value of a peer is discovered when
a C-frame that is too large is rejected by the peer.

The minimum MTU seems to be 48, so we could probably use that as a
limit for the overall packet. If the response exceeds this limit, we
should reject it as recommended by the spec, but I think we need to
reject the whole packet rather than the cmd CID.

> Thanks,
> Mike



-- 
Luiz Augusto von Dentz