| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
server-path.
|
|
|
|
| |
adapter::removeDiscoveredDevices() before adapter::startDiscovery(..)
|
|
|
|
| |
stopDiscovery() calls.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BTAdapter::removeDevicePausingDiscovery() and getCurrentDiscoveryPolicy()
Using a weak_ptr<BTDevice> list avoid stopping BTDevice destruction.
BTAdapter::removeDevicePausingDiscovery() allows manual DiscoveryPolicy intervention point,
allowing user to remove the ready device from the queue of pausing-discovery devices.
Manual intervention might be desired, if using DiscoveryPolicy::PAUSE_CONNECTED_UNTIL_DISCONNECTED,
but allowing discovery at an earlier processing step from AdapterStatusListener::deviceReady().
+++
Further added removeDevicePausingDiscovery() call in BTAdapter::removeDevice() as a last resort.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
discovery-off and detailed 'keep alive' options
API change (earmark version 2.5.0):
- AdapterStatusListener::discoveringChanged()
- BTAdapter::startDiscovery()
BTAdapter::startDiscovery() takes DiscoveryPolicy instead of bool keep_alive,
allowing fine tuned discovery keep-alive policy
and covering HCI host OS's implied discovery turn-off when connected (BlueZ/Linux).
dbt_scanner10.cpp and DBTScanner10.java covery the new DiscoveryPolicy
and user may pass its integer value via '-discoveryPolicy <0-4>'.
These example were further adjusted as follows:
- Removed WHITELIST variation of connection w/o discovery,
cleaning up and simplifying example code
- Remove manual start- and stopDiscovery() handling,
ending up in a single startDiscovery() call @ init (and power-on).
|
|
|
|
|
|
|
|
| |
overwrite = PairingMode::PRE_PAIRED != device.getPairingMode()
Only PRE_PAIRED keys shall not be overwrite the existing file, as they don't need to be and hence can preserve their timestamp.
However, another PairingMode indicates a new key and shall overwrite an existing file.
|
|
|
|
| |
Java: Same, but no default value possible (minor API change)
|
|
|
|
| |
finalize() and call super.close() on close()
|
|
|
|
|
|
| |
advertising (FIXME)
FIXME: Fast restart of advertising error: Analyze!
|
|
|
|
|
|
|
|
|
| |
name and SC init, LE_PHYs and SMPKeyPath
DBTPeripheral00 now also exposed
- startup and reusing stored SMPKeyBin files in SMPKeyPath
- prefer LE_PHYs::LE_2M, if available (BT5)
- set use SC (default) or legacy (not SC) - SC = LE Secure Connection
|
|
|
|
| |
BTAdapter held reference on disconnect, align ref holding in Java BTAdapter; Add explicit shutdown test
|
|
|
|
| |
Java side.
|
|
|
|
|
|
|
|
|
|
| |
JavaUplink
Use mutable and const field accessors, similar to upcoming Java 'proxy' classes.
This shall help defining mutable and const reference data access.
Revert adding JavaUplink to DBGatt[Desc|Char|Service] of commit 414c81b7214d895aba694ff444feca9cdc491bc5,
as we do not link from native instance to Java.
|
|
|
|
| |
and hence derive from JavaUplink
|
| |
|
|
|
|
| |
BTUtils.*print*()
|
|
|
|
| |
DBGattServer.Listener' from C++
|
|
|
|
|
|
|
| |
covering semantics of C++ POctets + bool variable_length
DBGattValue covers C++ POctets + bool variable_length,
where POctets contains bytes, its size and capacity.
|
|
|
|
| |
dbt_scanner10)
|
|
|
|
|
|
|
|
|
|
| |
DBGatt[Server|Service|Char|Desc] to Java ; BTAdapter.startAdvertising(..) Adds DBGattServer arg
- Implementation is not yet functional, i.e. types are not yet mapped to native instance.
- DBGattChar and DBGattDesc value currently just a 'byte[]' and lacks capacity:
- Its capacity defines the maximum writable variable length
- and its size defines the maximum writable fixed length.
|
|
|
|
| |
ctor braces
|
|
|
|
|
|
|
|
|
| |
proper MTU and connection tracking.
In case multiple connections will be supported, DBGattServer::Listener
is able to match the connected BTDevice to the callback event.
For now, dbt_peripheral00 only supports one connection while ignoring others ..
|
|
|
|
|
|
| |
its asynchronous response to a synchronous atomic operation
Examples, see dbt_scanner10 and DBTScanner10
|
|
|
|
| |
getGattServices(); connect() -> connectDefault()
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To have full SMP key persitency in peripheral slave mode,
BTAdapter requires fine grained control over
- Passing stored keys to BTDevice's PairingData (w/o uploading them)
- Uploading BTDevice's PairingData to the adapter
This required interaction in certain places,
only enabled if adapter is BTRole::Slave (peripheral):
- BTAdapter::mgmtEvDeviceConnectedHCI()
Only issue unpairDevice() if not pre-paired.
Unpairing is required for new pairing to avoid DHKey Check failures!
- BTAdapter::mgmtEvDeviceDisconnectedHCI()
- First unpairDevice() will be issued via notifyDisconnect()
- Set and upload stored keys for disconnected device (if existing),
preparing for next connect.
- BTAdapter::sendDevicePairingState()
- SMPPairingState::COMPLETED && not SMPPairingState::PRE_PAIRED: Store keys
- SMPPairingState::COMPLETED && SMPPairingState::PRE_PAIRED: Refresh keys to BTDevice (set), no upload!
- SMPPairingState::FAILED: Remove and delete keys
+++
BTAdapter::setSMPKeyPath(path) allows user to enable the persistent key storage
by setting its local filesystem path.
It will also read all key files (SMPKeyBin) and if valid and matching with the adapter,
uploads them for pre-pairing.
See dbt_peripheral00.cpp:
adapter->setSMPKeyPath(ADAPTER_KEY_PATH);
+++
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uploading keys (required for peripheral BTAdapter key management)
SMPKeyBin has the key apply action revoked.
SMPKeyBin is reduced to store keys, address and security settings,
as well adding persistence (read/write to filesystem).
BTDevice::setSMPKeyBin(SMPKeyBin&) shall be used copy the key data over
and BTDevice::uploadKeys() to upload them to the adapter for pre-pairing.
See dbt_scanner10.cpp's use of convenient API (same efficiency as before)
device->uploadKeys(KEY_PATH, req_sec_level, true /* verbose_ */);
BTDevice::setSMPKeyBin(SMPKeyBin&) fully restored BTDevice's PairingData
- keys
- key caps
- user security level and IOCaps
+++
The reduced 'set<Name>Key(..)' methods only
- copy the key to BTDevice's PairingData
- set the KeyType bit for keys_<role>_[init|resp], fully restoring key caps
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and connected as peripheral
This enforces a consistent and stable security workflow.
- when a BTRole::Slave BTDevice is discovered, see AdapterStatusListener::deviceFound().
- when a BTRole::Slave BTDevice is disconnected, see AdapterStatusListener::deviceDisconnected().
- when a BTRole::Master BTDevice gets connected, see AdapterStatusListener::deviceConnected().
+++
Especially when connected as peripheral without unpair in SC mode,
the peripheral fails the DHKey Check.
TODO: Provide a persistent pre-pairing mechanism via SMPKeyBin for peripheral mode.
+++
Note: Our existing example code to connect to a remote slave/peripheral,
already performed the unpair on deviceFound(..) and deviceDisconnected().
These calls have now being removed, as they are performed directly by Direct-BT.
The example code uploads pre-existing keys for pre-pairing when device is found,
if existing.
|
| |
|
|
|
|
| |
BTSecurityRegistry by start-of name as well
|
|
|
|
| |
ClientCharConfig
|
| |
|
|
|
|
| |
(name + SC)
|
|
|
|
| |
cleanup incl. CCCD regs
|
|
|
|
| |
for one adapter and apply them all (peripheral pre-pairing)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
site, incl. mapping to Mgmt event object
Situation: Linux Kernel 5.10.0-9-amd64, Debian 12
dbt_scanner10: Master, initiatior (DUAL)
dbt_peripheral00: Slave, peripheral (LE only)
LE Secure Connections enabled per default.
Issue: LTK via Mgmt event in ~50% of cases not send!
However, full information already passed via HCI commands/events.
Workaround: Listen to HCI commands as well and allow
related commands + events to complement SC status tracking.
+++
New HCI commands + events, incl. their Mgmt event mapping:
- HCIOpcode::LE_ENABLE_ENC -> HCILEEnableEncryptionCmd
- Mgmt HCI_LE_ENABLE_ENC -> MgmtEvtHCILEEnableEncryptionCmd
- HCIOpcode::LE_LTK_REPLY_ACK -> HCILELTKReplyAckCmd
- Mgmt HCI_LE_LTK_REPLY_ACK -> MgmtEvtHCILELTKReplyAckCmd
- HCIOpcode::LE_LTK_REPLY_REJ -> HCILELTKReplyRejCmd
- Mgmt HCI_LE_LTK_REPLY_REJ -> MgmtEvtHCILELTKReplyRejCmd
- HCIMetaEventType::LE_LTK_REQUEST -> HCILELTKReqEvent
- Mgmt: Opcode::HCI_LE_LTK_REQUEST -> MgmtEvtHCILELTKReq
- HCICommand::getSpecialized(..)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
move-semantics; 1st fully functional Gatt-Server!
Gatt-Server functionality provided by dbt_peripheral:
- Service GENERIC_ACCESS
- Service DEVICE_INFORMATION
- Service Proprietary `d0ca6bf3-3d50-4760-98e5-fc5883e93712`
- Characterictic DATA_STATIC: Read static data
- Characterictic COMMAND: Write a command
- Characterictic RESPONSE: Command response notify or indicate
- Characterictic DATA_PULSE: Periodical data sent via notify or indicate
|
|
|
|
| |
and echo command response via notify/indicate
|
|
|
|
| |
until disconnect
|
| |
|
|
|
|
| |
dbt_peripheral00: Add DBGattDesc::createClientCharConfig() to RESPONSE notify
|
| |
|
|
|
|
|
|
| |
DBGattDesc::createClientCharConfig(), ..
add Listener::write*Value(..) value_offset argument for long write requests
|
|
|
|
| |
testing)
|
|
|
|
| |
GATT action
|
|
|
|
| |
The Java example is currently not yet working ...
|
|
|
|
| |
DISCONNECT
|
|
|
|
| |
response components with user-description
|