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;
MIME-Version: 1.0
References: <20201208172912.4352-1-hadess@hadess.net> <CABBYNZJNTDek+kKS5wtrr67Xx8DmFGvcV13cLSxULgJRa5N+3g@mail.gmail.com>
 <3fcd56e8b875fb3d4ed6d58ad150e4b054d875ca.camel@hadess.net>
In-Reply-To: <3fcd56e8b875fb3d4ed6d58ad150e4b054d875ca.camel@hadess.net>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Tue, 8 Dec 2020 10:48:39 -0800
Message-ID: <CABBYNZKyndk8SG-xW=HYA7UZug==KtZfSmU=WHbgN1MC+DeM5A@mail.gmail.com>
Subject: Re: [PATCH] Bluetooth: L2CAP: Try harder to accept device not knowing options
To:     Bastien Nocera <hadess@hadess.net>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        Florian Dollinger <dollinger.florian@gmx.de>,
        "An, Tedd" <tedd.an@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Tedd,

On Tue, Dec 8, 2020 at 10:27 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> 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]
> >
> > =E2=80=A2 Test Purpose Verify that the IUT can give the appropriate err=
or
> > 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 have a Windows machine, and the PTS dongle. How do I set up the
> qualification test and run it against the Linux machine before and
> after the patch?

@Tedd: Do we happen to autopts working with BlueZ for L2CAP tests? Or
perhaps anything that Bastien can use as a reference to test his
changes.
@Batien: We would like to have autopts
(https://github.com/intel/auto-pts) to handle the qualification but
there is still some work pending in order to enable it to work with
L2CAP. Ultimately we could even attempt to integrate autopts on CI to
run it automatically, but in order to do that we need:

1. We need to emulate the PTS dongle (USB emulator?)
2. Run a Windows VM on CI, attach the emulated dongle to it and run
PTS on top (not sure if github actions do allow this)
3. Identify what tests need to run e.g. L2CAP changes should trigger
only L2CAP tests

--=20
Luiz Augusto von Dentz