aboutsummaryrefslogtreecommitdiffstats
path: root/api/direct_bt/BTAddress.hpp
Commit message (Collapse)AuthorAgeFilesLines
* MgmtTypes: LTK, IRK and LK: Add ↵Sven Gothel2022-01-011-0/+14
| | | | | | | BDAddressAndType::getBLERandomAddressTypeString(..) in toString() BLERandomAddressType std::string representation shall be added in basic key management, allowing easier debugging of invalid keys.
* Moved EUI48, EUI48Sub (C++/Java) and uuid_t, *Octets (C++) to jaulib for ↵Sven Gothel2021-09-181-272/+22
| | | | | | | | | 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.
* BLERandomAddressType: API doc: Add more details.Sven Gothel2021-09-181-2/+8
|
* C++: EUI48Sub add: hash_code(), clear(), indexOf(), contains(), operator==() ↵Sven Gothel2021-07-301-6/+120
| | | | etc; EUI48[Sub]: Add static 'scanEUI48[Sub]'(string&) and static 'indexOf()'
* Passthrough all paramter BTAdapter::startDiscovery(..) -> ↵Sven Gothel2021-07-281-0/+1
| | | | | | | | | | | | | HCIHandler::le_set_scan_param(..): Add le_scan_active and filter_policy; Java: Add all. Also changing order of parameter, allowing to use default values in a most reasonable sense. Motivation: Expose `le_scan_active` to retrieve the AD EIR package with event-type SCAN_RSP, which gets queried via active scanning only and usually holds the device name if supported. TODO: Resolve propagating device found on SCAN_RSP message (name), since SCAN_IND is received before (w/o name). The 2nd SCAN_RSP is dropped, even though the BTDevice's name has changed properly.
* API String Conversion Simplification: get.*String() -> ↵Sven Gothel2021-02-101-8/+12
| | | | | | | | | | | | | | direct_bt::to_string() Patch [2/2] This goes along with jaulib's 'hex and decimal string conversion'. API schema for to string conversion: 1 - free function: to_string(type) 2 - main member function: toString() 3 - sub-type member function: getTypeString(Type) 3 avoid overload collision w/ potential virtual toString() method. Additional, 1 is provided for 3 as well
* C++: Promote L2CAP_PSM, L2CAP_CID, .. to 'enum class'; Minor constexpr ↵Sven Gothel2021-02-081-2/+3
| | | | | | | | | | | | | | | | | | | | | enhancements 'enum' -> 'enum class' w/ all bells and whistles: L2CAP_PSM, L2CAP_CID, AD_Type_Const BTAddress.hpp: Add 'constexpr uint8_t number(..)' constexpr: - equality- and bit-operations on different types: EIRDataType, ManufactureSpecificData - isEIRDataTypeSet(), setEIRDataTypeSet(), setAdapterSettingMaskBit() HCIACLData Cleanup - Use L2CAP_PSM and L2CAP_CID types - Convenient queries if SMP or GATT type - Add toString(..) w/ l2cap_data ptr L2CAPComm: Use L2CAP_PSM and L2CAP_CID types
* Fix EUI48 doc (it is within direct_bt namespace); Add EUI48Sub API docSven Gothel2021-02-051-4/+3
|
* C++: Replace {@code lala} with `lala` as it confuses Doxygen preprocessor ↵Sven Gothel2021-02-051-7/+7
| | | | | | | | | parsing __pack(...) using PREDEFINED "__pack(x)=x" This issue has been observed with Doxygen 1.9.1. Struct and classes wrapped with '__pack( ... )' were missing, if file contained a documentation using the javadoc `{@code lala}`.
* Example Scanner10 (C++/Java): Support Security setting per device ↵Sven Gothel2021-01-271-0/+6
| | | | | | BDAddressAndType; Tested reconnect reusing stored LTK Same code in C++ dbt_scanner10.cpp and DBTScanner10.java.
* Added EUI48Sub and EUI48::indexOf(const EUI48Sub& other) and contains(const ↵v2.2.0Sven Gothel2021-01-251-3/+72
| | | | EUI48Sub& other) (C++ and Java, both w/ unit tests)
* Fix operator==(const EUI48& lhs, const EUI48& rhs): Sloppy typo lhs -> rhs ↵Sven Gothel2020-12-251-4/+1
| | | | for 2nd argument; Remove operator<(..)
* Revamp native + java types: EUI48 and add BDAddressAndTypeSven Gothel2020-12-121-22/+200
| | | | | | | | | | | | | | | | EUI48: add hash-code, fast compare, include static const ANY_*DEVICE) - added Hash specialization in namespace std for hash-map (C++) BDAddressAndType: Added, to be utilizes as actual unique device address having EUI48 + BDAddressType - fully self sufficient w/ comparison, hash and matching methods - added Hash specialization in namespace std for hash-map (C++) Goal for BDAddressAndType is to replace separate EUI48 + BDAddressType, providing BluetoothDevice / DBTDevice with a unique single key entry. This will allow us to properly use a hash-map (new for our C++ code) Further we emphasize on the unique key contract, which requires the BDAddressAndType, as EUI48 is not enough.
* Use jau/packed_attribute.hpp; MgmtTypes.hpp: Encapsulate Cmd and Event data ↵Sven Gothel2020-11-101-2/+4
| | | | MgmtLinkKey, MgmtLongTermKey, MgmtIdentityResolvingKey and MgmtConnParam
* BTAddress.hpp: BDAddressType: Promote to scoped enumSven Gothel2020-11-081-3/+7
|
* EUI48: Use constexpr; *Octets: support uint64_t and jau::uint[128, 192, 256]_tSven Gothel2020-11-031-3/+3
|
* BTAddress: Add isLE* and isBREDR* constexpr queriesSven Gothel2020-10-071-0/+12
|
* C++: First round propagating noexcept: Adding nocheck '_nc' variants in ↵Sven Gothel2020-09-141-12/+12
| | | | OctetTypes and use them if allowed.
* README: More detailed Direct-BT description (event driven, build ↵Sven Gothel2020-09-031-4/+2
| | | | | | depenencies, build, ..); Add \example tag in examples. For unknown reason, examples are not visible in result.
* EUI48::getBLERandomAddressType(): Pass BDAddressType, to only return a valid ↵Sven Gothel2020-07-031-4/+2
| | | | | | | | | | BLERandomAddressType related to the BDAddressType. We validated the BLERandomAddressType in DBTDevice.java, but created an invalid value in DBTDevice.cpp regardless of BDAddressType. Resolved! We also perform the validate in DBTDevice.cpp now.
* Support BDADDR_LE_RANDOM (p1.2): Add ↵Sven Gothel2020-07-021-4/+14
| | | | HCILEPeerAddressType/HCILEOwnAddressType String representation + API doc
* Support BDADDR_LE_RANDOM (p1): Add BLERandomAddressType, distinguish ↵Sven Gothel2020-07-021-60/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | HCIAddressType..., Move EUI48 into direct_bt namespace Add BLERandomAddressType Exposed in DBTDevice and BluetoothDevice C++ and Java. See "BT Core Spec v5.2: Vol 6 LE, Part B Link Layer Specification: 1.3.2 Random device Address" +++ Distinguish HCIAddressType -> HCILEPeerAddressType + HCILEOwnAddressType As used for HCIHandler::le_create_conn(..) See "BT Core Spec v5.2: Vol 4, Part E Host Controller Interface (HCI) Functionality: 7.8.12: LE Create Connection command" DBTDevice::connectLE(..) translates its own BDAddressType -> HCILEPeerAddressType using BLERandomAddressType (BDAddressType, address). Currently only HCILEPeerAddressType::STATIC_PUBLIC is allowed and passed through. +++ Move EUI48 into direct_bt namespace
* BTAddress: Add 'BDAddressType getBDAddressType(const HCIAddressType ↵Sven Gothel2020-06-241-0/+1
| | | | hciAddrType)' translation
* Use Kernel BlueZ Manager for Discovery, Connect, etc. (Initial Commit - Java ↵Sven Gothel2020-04-251-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | part probably broken) We have experienced the following using the official HCI communication channel: - Lower connect performance with discovery enabled - Instability with enabled discovery and breaking general BT adapter state requiring a 'hciconfig hci0 reset' - Lack of notifications: start/stop discovery/connect/... - Lack of certain settings in general: pin, .. This commit implements discovery including listening to all BlueZ kernel events from the BlueZ Manager channel using DBTManager. TODO: Figure out how to enforce quick connect! - EInfoReport (EIR) added: FLAGS, DEVICE_CLASS, APPEARANCE, HASH, RANDOMIZER and DEVICE_ID - including parsing new segments in read_data(..) and dataSetToString(..) exposure - DBTManager adds: - manager-reader thread, putting all command status/completes to its ringbuffer and sending out all other events to its listener. - Respecting the chosen BTMode (side-effect to discovery etc) - add: start/stop discovery - add: connect/disconnect (incomplete) - DBTAdapter: - discoverDevices -> discoverDevicesMgmt is becoming redundant, now simply waiting for the DeviceFound event. Will be deleted - TODO! - mgmtEvDeviceFoundCB shall perform remaining EIR parsing and enqueing the devices plus issuing respective discovery callbacks! TODO. - DBTDevice adds: - BDAddressType - HCISession's HCIComm is now no more used (to be deleted!) - HCIComm adds generic read/write methods, mutex free. - Remaining HCI 'managment' methods are also subject to deletion! - GATTHandler / DBTManager: only use a mtx_write for communication, as reading is performed on their respective threads using a ringbuffer. Here only concurrent write access needs to be managed. (DBTManager uses its own HCIComm's mutex.) - MgmtTypes adds: - BTMode for dual, BREDR or LE only. - MgmtRequest -> MgmtCommand - Unifies the command opcodes to global 'MgmtOpcode', removing duplicate MgmtCommand::Opcode (which was also incomplete) - Adding MgmtDisconnectCmd, MgmtEvtDiscovering, MgmtEvtDeviceFound MgmtEvtDeviceConnected, MgmtEvtDeviceDisconnected - TOctets adding get_int8(..) and get_eui48(..) - TOctets adding put_eui48(..) ++++++++++++++ New ClassFunction: Introducing versatile C++ function-method type used for our DBTManager callbacks. In contrast to std::function and std::bind, ClassFunction allows using its specific type (return- and argument types) and offering the equality operation to test its identity. The latter is essential to remove a callback ClassFunction from a list of callbacks. +++++++++++++++++ Further code cleanup is also included - Address_T -> BDAddressType(incl string presentation) + HCIAddressType - ManufactureSpecificData using POctets - Convenient default param: uint*HexString(.., const bool leading0X=true); - MgmtTypes's get/put for events and commands use MGMT_HEADER_SIZE offset - MgmtTypes: Remove doubled 'btohs', as the pdu.get* commands already perform endian conversion. - EInfoReport::read_data(..) validate segment size before type conversion
* Implement direct_bt: Direct Bluetooth access via Linux's Kernel BlueZ ↵Sven Gothel2020-04-091-0/+109
protocol stack w/o D-Bus bluetoothd. By dropping BlueZ userspace D-Bus bluetoothd, we target high-performance reliable bluetooth support with least dependencies for embedded device configurations. See COPYING, describing which Linux Kernel BlueZ IOCTL information has been included in the source tree. We claim Linus Torvalds's Linux Kernel license exception regarding kernel syscalls (ioctl): <https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note> and hence maintain this project's license. The new direct_bt feature set is organized as follows - include/cppunit - api/direct_bt - api/ieee11073 - src/direct_bt - examples/direct_bt Note that the C++ direct_bt layer is not backward compatible to tinyb. Since the Java layer still needs to be completed, it has to be seen whether we will achieve compatibility or drop the original D-Bus tinyb module altogether in favor of a more streamlined API and implementation. Current state allows scanning for LE devices, connecting and parsing GATT plus receiving notifications and indications. See examples/direct_bt_scanner/dbt_scanner.cpp. The Linux Kernel BlueZ is configured via module MgmtComm.[hpp/cpp]
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 13:11:57 +0000