Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <20346dac6bd4c7fa6642b5516d89fdb275ed4990.camel@hadess.net>
Subject: Re: [PATCH] Bluetooth: L2CAP: Try harder to accept device not
 knowing options
From:   Bastien Nocera <hadess@hadess.net>
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        Florian Dollinger <dollinger.florian@gmx.de>
Date:   Wed, 06 Jan 2021 17:42:31 +0100
In-Reply-To: <CABBYNZJNTDek+kKS5wtrr67Xx8DmFGvcV13cLSxULgJRa5N+3g@mail.gmail.com>
References: <20201208172912.4352-1-hadess@hadess.net>
         <CABBYNZJNTDek+kKS5wtrr67Xx8DmFGvcV13cLSxULgJRa5N+3g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.2 (3.38.2-1.fc33) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Tue, 2020-12-08 at 10:09 -0800, Luiz Augusto von Dentz wrote:
> Hi Bastien,
> 
> On Tue, Dec 8, 2020 at 9:36 AM Bastien Nocera <hadess@hadess.net>
> wrote:
> > 
> > The current implementation of L2CAP options negotiation will
> > continue
> > the negotiation when a device responds with L2CAP_CONF_UNACCEPT
> > ("unaccepted
> > options"), but not when the device replies with L2CAP_CONF_UNKNOWN
> > ("unknown
> > options").
> > 
> > Trying to continue the negotiation without ERTM support will allow
> > Bluetooth-capable XBox One controllers (notably models 1708 and
> > 1797)
> > to connect.
> 
> While the bellow traces looks fine we need to confirm that it doesn't
> break the qualification tests e.g:
> 
> L2CAP/COS/CFD/BV-14-C [Unknown Mandatory Options Request]
> 
> • Test Purpose Verify that the IUT can give the appropriate error
> code
> when the Lower Tester proposes any number of unknown options where at
> least one is mandatory.
> 
> Afaik it should be fine to continue with another round of
> configuration given that it only expects the error 0x0003, but we
> better confirm PTS doesn't expect a L2CAP Disconnect after it.

I tested this today using Fedora's kernel-5.11.0-0.rc2.114.fc34:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1664670
And a local build using the same source kernel with this patch on top.

Both managed to pass the test without any problems.

I'll send the results of the test privately to you and Marcel.

Cheers