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: <20200519202519.219335-1-luiz.dentz@gmail.com> <20200519202519.219335-2-luiz.dentz@gmail.com>
 <C478BA49-0BBF-4323-AC3A-30442F65D346@holtmann.org>
In-Reply-To: <C478BA49-0BBF-4323-AC3A-30442F65D346@holtmann.org>
From:   Alain Michaud <alainmichaud@google.com>
Date:   Tue, 26 May 2020 09:53:21 -0400
Message-ID: <CALWDO_UEPaAGyLFG93JzT41P=yGePB-N2Pbh5hioLBOXdh2YBw@mail.gmail.com>
Subject: Re: [PATCH 2/4] Bluetooth: Fix assuming EIR flags can result in SSP authentication
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        BlueZ <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Marcel and Luiz,

Starting with the 2.1 specification, it is my interpretation that it
is not valid to support EIR but not SSP.  I understand that SSP may be
disabled from BlueZ's point of view, but this doesn't seem to be a
legitimate/qualifiable configuration.  Should we instead fail the
legacy pairing if EIR was received as an invalid condition?

Thanks,
Alain

On Wed, May 20, 2020 at 10:35 AM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Luiz,
>
> > EIR flags should just hint if SSP may be supported but we shall verify
> > this with use of the actual features as the SSP bits may be disabled in
> > the lower layers which would result in legacy authentication to be
> > used.
> >
> > Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> > ---
> > net/bluetooth/hci_conn.c | 2 --
> > 1 file changed, 2 deletions(-)
>
> patch has been applied to bluetooth-next tree.
>
> Regards
>
> Marcel
>