| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
device if not pre-paired
Avoid losing device pairing if performed via Direct-BT in case explicit startDiscovery() purged discovered devices.
|
| |
|
|
|
|
| |
aligned for all cases (C++ and Java, via setSMPKey() or manual)
|
|
|
|
| |
RSSI, BDADDR* change (java)
|
|
|
|
| |
state
|
| |
|
|
|
|
| |
properties: Use irk_resp (copy/paste bug) and SMPIdentityResolvingKey::Property::RESPONDER
|
|
|
|
| |
have full startDiscovery variant use DBGattServerRef default nullptr arg
|
|
|
|
| |
array) with extra capacity and size
|
|
|
|
| |
array)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
add sendOnly(..) to skip waiting for response
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GATTRole::Client; BTAdapter::startDiscovery() add DBGattServerRef ref
A GattServerHandler(DBGattServer) is also possible for LL master (GATT client) connections
where the server inquires certain data points within the client's GATT.
User can pass DBGattServer to BTAdapter::startDiscovery() to enable the GattServerHandler for such cause.
Test case: Avalun's LabPad device
- DBTLabPadClient01.java
- dbt_labpadclient01.cpp
|
|
|
|
| |
Vol 3, Part G GATT: 4.8.2 Read Using Characteristic UUID
|
|
|
|
| |
for C++ for general use (commonly used to ctor a DBGattServer)
|
|
|
|
| |
matching dbt_peripheral00
|
|
|
|
| |
earlier commit
|
|
|
|
|
|
|
|
|
|
|
| |
server mode
The actual used security level shall match the required (user-set) level as follows
- Don't care if request is < ENC_ONLY
- If request == ENC_ONLY, actual must be >= ENC_ONLY
- If request >= ENC_AUTH, actual must be >= ENC_AUTH
Here we do ignore ENC_AUTH_FIPS, as not all devices/adapter support it yet.
|
|
|
|
|
|
| |
authentication in server mode; Read-out l2cap's actual sec_level when paired
This state works w/ pairing against an Android phone using Random Private Address and authentication.
|
|
|
|
| |
authentication mode
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
utilizing sec_level_server, io_cap_server in server mode
In server mode, pre-set and validated sec_level_server, io_cap_server
are handled as follows:
(1) io_cap_server gets set in the manager before start advertising
and actual when connected at mgmtEvDeviceConnectedHCI() the manager setting
is propagated to the device via notifyConnected()
(2) sec_level_server is also propagated to the device
when connected at mgmtEvDeviceConnectedHCI() via notifyConnected().
It subsequently is set on the L2CAP at BTDevice::processL2CAPSetup()
on the server l2cap connection.
+++
Renamed 'ioCap'* -> 'io_cap'* for readability
as we don't regularly use camel-case for fields here.
|
|
|
|
|
|
|
|
| |
removed even if disconnect failed (power-off case)
Notable was a failed pairing attempt causing the adapter to reset (power cycle).
The disconnect command was unable to succeed, hence survived in the connected list
and subsequent startAdvertising faild.
|
|
|
|
| |
enum conversion, fix byte values
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
'SMPIOCapability adapter_sec_io_cap' commandline param to enable IO for auth
Currently I limit my tests for ENC + AUTH to:
- BTSecurityLevel: ENC_AUTH (3) and ENC_AUTH_FIPS(4)
- SMPIOCapability.DISPLAY_ONLY (0) to have a PASSKEY being display by the user application.
Current unit tests cover the ENC_ONLY(2) with IO NONE (0xff) only
and shall be enhanced for these enc+auth cases as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
using RPA/IRK crypto matcher for HCI events (passing RPA)
HCIConnectionRef and BTDevice store both address pairs, naming the potential RPA as 'visibleAddressAndType'.
BTAdapter's findDevice*() method seeks through all device's address first
and if the potential RPA is not found queries each device whether it
matches with its IRK (if existing).
In case the latter is positive, the identity address has been found.
Naturally, to have this work, the adapter (in server mode) needs to upload all
keys to the host adapter to allow resolving as well as instantiating
all devices per key-set.
This concept has already been implemented,
hence the IRK resolution change-set is not too dramatic.
Trial unit tests passed.
|
| |
|
|
|
|
| |
supported, fix DBG_PRINT, add missing declarations
|
|
|
|
| |
id_address), SMPKeyBin storage and host upload, w/ clearing all IRKs on startup
|
|
|
|
| |
Random Address, made available in SMPIdentityResolvingKey and BTDevice
|
|
|
|
| |
Random Address
|
|
|
|
| |
BTAdapter clear resolvable list at 1st init, BTDevice del from resolvable list at disconnect
|
|
|
|
| |
using AdapterStatusListener::devicePairingState() + SMPPairingState::PASSKEY_NOTIFY to display generated PassKey
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
read.., set..
NOTE that the following seem not to be supported in Linux/BlueZ:
- LE_READ_PEER_RESOLV_ADDR
- LE_READ_LOCAL_RESOLV_ADDR
The others are coded within BlueZ,
but I received 0x01 UNKNOWN_COMMAND as a HCIStatusCode
Used kernel for analysis:
- bluetooth-next 2022-04-01
- 38a1944deda4d96ca04b9aaa51ee5ae879b61aa0
|
| |
|
|
|
|
| |
status
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
API Changes for v3.2.0:
- BTAdapter:
- setPrivacy(bool) added
- initialize() w/o args or default args removed
- initialize(final BTMode btMode, boolean powerOn) added
|
|
|
|
|
|
|
|
|
| |
new-IRK
FIXME: Passing a HCILEOwnAddressType other than PUBLIC for "LE set scan Param"
after setPrivacy(true) via BTManager results in failure.
TBD: Seems like the mngr API and HCI is not aligned or my adapter revolts.
|
|
|
|
| |
LE for clarity
|
|
|
|
| |
setDiscoverable() mode change replies
|
|
|
|
| |
subsequent power-off settings w/o toggling power again
|
|
|
|
| |
use it for BTAdapter::startDiscovery() and BTDevice::connectLE()
|
|
|
|
| |
BTSecurityRegistry.Entry lookup: Add remote device name (same as dbt_scanner10.cpp)
|
|
|
|
| |
BTDevice::updatePairingState/hciSMPMsgCallback: Clear smp_events after pairing completion
|