Re: [PATCH v2] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig

[Luiz Augusto von Dentz]

Hi Michael,

On Wed, May 20, 2026 at 10:13 AM Michael Bommarito
<michael.bommarito@xxxxxxxxx> wrote:
>
> On Wed, May 20, 2026 at 10:00 AM Luiz Augusto von Dentz
> <luiz.dentz@xxxxxxxxx> wrote:
> > Weird, does the AI come up with this? The id is actually _not_
> > important because the error code will essentially indicate that the
> > entire packet was rejected. Therefore, it doesn't matter if the id is
> > for a request or a response, it still needs rejection if it exceeds
> > the MTU, so this seems overengineered.
>
> Yes, and I debated this with Claude, but it convinced me that the
> lifted helpers were more idiomatic for the actual spec and bt system:
> "The identifier shall match the first request command in the L2CAP
> packet. If only responses are recognized, the packet shall be silently
> discarded."

This coming from the spec is priceless because silently discarding the
packets means the remote stack won't know the responses were
discarded, causing the stacks to go out of sync. We also shouldn't
process packets beyond the allowed MTU. Therefore, I strongly disagree
with the spec requiring an identifier on the reject, as this implies
that even if a custom MTU is set, the packet must still be processed
if it exceeds that MTU to find the first request command within it.

> So if we ever lifted or refactored the code, it would be abundantly
> clear/safe to reuse elsewhere.
>
> There is also much shorter version that just peeks skb->data[1] and
> exits early if not ident=0 if that's what you're going for.
>
> Just let me know what version you prefer.
>
> Thanks,
> Mike



-- 
Luiz Augusto von Dentz