| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
location (current dir) of core file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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);
+++
|
|
|
|
| |
quotes
|
|
|
|
| |
script commit)
|
|
|
|
| |
examples; Add jar install for example/java!
|
|
|
|
| |
images also build by our pi-gen branch)
|
|
|
|
| |
with definite name
|
|
|
|
|
|
|
|
|
| |
general use.
Notable, the java classes EUI48, EUI48Sub and BasicTypes are included in direct_bt's jar file
to avoid any inconvenience.
Hence BTUtils's byte[s]HexString(..) simply uses jaulib's BasicTypes s' implementation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reasonable default values have been chosen from the BT spec,
which can be overriden using the HCIHandler and BTAdapter operations.
The extended advertising operations are also supported (Bluetooth 5.0).
+++
Successfully tested running:
(0) Test machine with 2 adapter
- adapter-1 DC:FB:48:00:90:19 (acting as client)
- adapter-2 00:1A:7D:DA:71:08 (acting as peripheral)
(1) Running dbt_peripheral00.cpp or DBTPeripheral.java
as the advertising peripheral on the test machine.
`direct_bt/dist-amd64$ ../scripts/run-dbt_peripheral00.sh -adapter 00:1A:7D:DA:71:08`
or
`direct_bt/dist-amd64$ ../scripts/run-java-peripheral00.sh -adapter 00:1A:7D:DA:71:08`
(2) Running dbt_scanner10.cpp or DBTScanner10.java
as the listeninig and connection-initiator client
on the same test machine.
`direct_bt/dist-amd64$ sh ../scripts/run-dbt_scanner10.sh -adapter DC:FB:48:00:90:19 -dev 00:1A:7D:DA:71:08 -seclevel 00:1A:7D:DA:71:08 1`
or
`direct_bt/dist-amd64$ sh ../scripts/run-java-scanner10.sh -adapter DC:FB:48:00:90:19 -dev 00:1A:7D:DA:71:08 -seclevel 00:1A:7D:DA:71:08 1`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with version 2.3, the previously refactored *TinyB* has been removed completely.
Motivation was lack of detailed Bluetooth support, inclusive increasing diversion with *Direct-BT*.
Furthermore, work is underway for `BLE slave periphal and GATT server` support and its mapping to *BlueZ D-Bus* is questionable
and would be resource intensive.
Java API changed as follows:
- Objects no more Clonable
- Removed dead unsupported code
- Removed deprecated code
- Added 'GattCharPropertySet', representing property bit mask for BTGattChar,
replacing the string array.
|
|
|
|
|
|
|
|
|
| |
connecting if supported)
On Bluetooth 5.0 Adapter where HCI extended scanning and connecting is suppored,
the original HCI commands may fail via DISALLOWED.
Tested adapter: Intel AX200 Bluetooth 5.0 (Wi-Fi 6 802.11ax (2.4Gbps) + BT 5.0)
|
|
|
|
| |
setcap/capsh; README: Clean MD; Refine Direct-BT application launch options
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to lib, support full EUI84Sub and name-sub pattern matching
Same naming-schema and functionality C++/Java
Due to using EUI48Sub and name-sub pattern matching,
we naturally had to drop the hash-set fast-lookup approach.
However, looking up device names via pattern-matching is essential
to handle device groups, i.e.
- specific security settings (level, passkey, ..)
- actually accepting them to connect (waitForDevices)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BTAdapter; Add AD_EIR debug flag
MgmtEvtDeviceFound changes: Stringent ownership
- field eireport type `std::shared_ptr<EInfoReport>` -> `std::unique_ptr<EInfoReport>`
- getEIR() returns immutable EInfoReport pointer
BTAdapter::mgmtEvDeviceFoundHCI(): Cleanup confusion
- Expect coming from HCIHandler (we only listen to it), ABORT otherwise
- Cleanup confusion of ownership etc
Debug:
- HCIHandler env.DEBUG_SCAN_AD_EIR `direct_bt.debug.hci.scan_ad_eir`
|
| |
|
|
|
|
| |
properties.
|
| |
|
|
|
|
| |
setup)
|
| |
|
|
|
|
| |
to have a unified environment
|
|
|
|
|
|
|
|
|
| |
SMPIOCapability setting to be self-contained un reusage.
Also
- store keys in own path
- determine filename within class
- validate BTSecurityLevel as well
|
| |
|
|
|
|
| |
native lib loading. Added junit test facility (Java).
|
|
|
|
| |
Char] etc (align naming with direct_bt == java; reduce java code footprint and too long code lines)
|
| |
|
| |
|
| |
|
|
|
|
| |
GPROF and PERF_ANALYSIS 'tags' to build with gprof or just '-O3 -g -ggdb' (callgrind)
|
|
|
|
|
|
|
| |
Catch2 for own unit tests)
Also: cmake: Add "null-dereference" to NO_ERROR, as it causes trouble with jau::get_uint8(..) with "-O3"
See jaulib commit db34007f905dab9feeba16e95c16d84bfb0ff11a
|
| |
|
|
|
|
| |
'ulimit -c unlimited' in capsh'ed execution for core dumps
|
| |
|
|
|
|
| |
[DBT|Bluetooth]Manager, enabling fully event driven workflow w/ adapter add/remove
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
commented-out options
Example with callgrind enabled: "../scripts/run-dbt_scanner10.sh -log ~/dbt_scanner10-arm64-30 -dev_id 1 -disconnect -count 1 -Ndebug -dbt_debug false -quiet -mac C0:26:DA:01:DA:B1 -mac C0:26:DF:01:E5:CA -mac C0:26:DA:00:03:DC -mac C0:26:DA:05:EF:5B"
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note on completion..
Most reported issues were due to helgrind's lack of analyzing the atomic macros used in C++ atomic<T>.
Most issues related to 'direct_bt::LFRingbuffer::*',
utilizing SC-DRF atomic acquire (read) and release (write)
not detected by helgrind.
This mechanism is well tested, see unit test test_mm_sc_drf (passed).
However, we have fixed around 6 issues - mostly lock order related.
|
|
|
|
|
|
| |
suppressed - or - fixed
Also adding the suppression extraction scripts from <https://wiki.wxwidgets.org/Parse_valgrind_suppressions.sh>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
name aligned with dbt_scanner10.cpp
|