Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
From:   Mike <puffy.taco@gmail.com>
Date:   Fri, 13 May 2022 16:13:01 -0500
Message-ID: <CAB7rCTi-znCvwk5wPT652yyh8vgKyCORYFF8runEQ5nOM4y9rw@mail.gmail.com>
Subject: LE OOB pairing
To:     linux-bluetooth <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

I'm working on getting a prototype together that is intended to use
NFC to pair a Linux tablet with a device that contains a Nordic BLE
chip.  The tablet contains an NFC module with a non-standard host
interface, so at present I'm not able to use neard, but we have some
code running to the extent that we can read the NDEF record from the
Nordic chip.  I've run that through an NDEF parser to get at the EIR
data, which is what bluetoothd would be looking for.

I've looked through the bluez codebase and it appears everything is
set up for BR/EDR pairing for mime-type
application/vnd.bluetooth.ep.oob.  The Nordic NDEF provides the
mimetype application/vnd.bluetooth.le.oob, which is as expected for an
LE device.  Nothing too far looks terrible in terms of modifications
to BlueZ to process this information, but I do note that at present
eir.c doesn't look for LE Secure Connections Confirmation Value, LE
Secure Connections Random Value, or LE Bluetooth Device Address, all
of which are found in the EIR I parsed.

Eventually we get to the point of creating the device and a bonding,
which both are expecting type BDADDR_BREDR.  Before I go too far down
this rabbit hole, what I'm wondering is if anyone has thought through
this implementation and whether this is as simple as I hope, or if
there will be difficult issues ahead?

Thanks!