| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
'BTManager::readDefaultSysParam(const uint16_t dev_id)'
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
PAUSE_CONNECTED_UNTIL_PAIRED, which is without GATT service discovery ..
GATT service discovery is not included anymore, since user is required to call BTDevice::getGattServices()
to initiate MTU exchange and the GATT service discovery.
See new to old:
- commit 1443d3a084342fffacd405fae3c44ef290bd438e
- commit ab9f3dec2d06b9e39241c497e8aa00aaa23966c3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allowing server to countdown servingConnectionsLeft to determine to stop or continue advertising
The TestDBTClientServer10 starts client and server instances then waits for a successful completion or a timeout will abort the test.
A successful completion requires both, client and server, to have determined this state
and stop discover and advertising respectively.
The server's processDisconnectedDevice() shall re-enable advertising in case
more connections are to be served.
For example a SMP failure would disconnect the client from the server
without a successful test completion.
Hence the server needs to determine a successful test,
which is now being signaled via a GATT command by the client.
Here the client writes a specific value to a GATT characteristic,
which is recognized by the server and returned to the client.
If done, client and server countdown their counter of tests left.
This renders the client server test more robust
as required for certain BT adapter setups w/ failing connections.
Here the test will continue until success or timeout.
|
|
|
|
| |
(unchecked) before power-off to ensure proper state if tests fail.
|
|
|
|
|
|
| |
TestDBTClientServer00: Move DBTUtils.printVersionInfo() to test01
DEBUG props must be set before loading the native lib, otherwise they are ignored.
|
|
|
|
|
|
|
|
|
| |
key negotiations, mostly test01_FullCycle_EncOnlyNo1
Usually the test runs within 5s - 10s and connection w/ SMP key negotiation below 5s.
However, on none reset adapter with potential wrong key seeding
an initial negotiation test may take a bit over 20s (yeah .. to be further analyzed).
|
|
|
|
|
|
| |
processDisconnectedDevice(..)
device.remove() shall ensure to clear all device references from its BTAdapter to avoid leaks.
|
| |
|
| |
|
|
|
|
| |
client-mode discovery test post client connection
|
| |
|
| |
|
|
|
|
| |
VERSION_SHA1_SHORT. VERSION_LONG reflects post-tag and dirty.
|
|
|
|
| |
junit packages to import
|
| |
|
|
|
|
| |
enough), add \example TestDBTClientServer*.java
|
| |
|
|
|
|
| |
accumulation across connects w/o removeDevice), incl in unit test
|
|
|
|
| |
capsh command
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
server functionality
Building with enabled *trial* and *testing* , i.e. live testing with 2 Bluetooth adapter
is provided via the *cmake* build argument `-DBUILD_TRIAL=ON`, see above.
The *trial* tests utilize one or more actual Bluetooth adapter,
hence using the *capsh* launch for the required permissions as described above.
Therefor, *sudo* will be called and a user interaction to enter the *sudo* password may occur.
The *trial* tests cover *Direct-BT*'s Bluetooth functionality,
having its *master/client* and *slave/server peripheral* facilities communicating via actual adapter,
supporting regression testing of the API, its implementation and adapter.
|
|
|
|
| |
not necessarily an error (disconnect, etc)
|
|
|
|
|
|
| |
given
Otherwise a non removed device instance (after disconnect) would not take the (newly) discovered name.
|
|
|
|
|
|
|
|
|
| |
(re-added) DBTAdapter update DBTDevice.isConnected
Completes commit bac686561fdaf10813738d489f01b557a3812259.
This change set allows using BTAdapter.removeAllStatusListener()
while having the internal functionality preserved.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
via stopAdvertising() or _a_connection_ has been made.
This fix set's HCIHandler's 'advertisingEnabled' flags to 'false' after a 'connection complete' event had occured.
Further, HCIHandler::le_enable_adv(..) overrides a potential erroneous HCI failure when:
- disabling advertising when already disabled, or
- enabling advertising when already enabled
as stated in spec 'BT Core Spec v5.2: Vol 4 HCI, Part E HCI Functional: 7.8.9 LE Set Advertising Enable command'
|
|
|
|
| |
instance
|
|
|
|
| |
maintain functionality.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
thread), let client app (dbt_repeater00) manage forwarding disconnect client -> server
dbt_repeater00: On client disconnect reset the server connection:
- disconnect connection to server
- power-cycle the adapter to server
- start-discovery
|
| |
|
| |
|
|
|
|
| |
info; Fix FwdGattServerHandler::replyExchangeMTUReq(..) mtu minimum
|
|
|
|
| |
Note: The asterix '*' is added to mark the server EUI48
|
|
|
|
| |
notification callbacks, allowing better protocol tracking for DBGattServer::Mode:FWD (repeater)
|
|
|
|
| |
remark on their Java counterpart, if existing)
|
|
|
|
| |
versions (install and capsh issue)
|
| |
|
|
|
|
|
|
| |
, i.e. forwarding client requests to a GATT server and passing the results back.
Code uses DBGattServer::Mode::FWD
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
alternate GATT Server operational mode
New DBGattServer::Mode are
- NOP - no-op,
- DB - user database GATT server as before using a list of DBGattService,
- FWD - proxy: forwarding all GATT requests to another remote GATT server and returning the results
Each DBGattServer::Mode has a corresponding BTGattHandler::GattServerHandler implementation
to act upon the different GATT requests from a connected client.
All three modes are fully implemented.
|
| |
|
|
|
|
| |
mgmtEvDeviceFoundHCI: Update last_discovery on re-discovered device
|
|
|
|
| |
run-native-example.sh
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
request only via BTDevice::getGattServices()
This reverts MTU/GATT-Services 'push up' from getGattServices() -> connectGATT()
of commit ab9f3dec2d06b9e39241c497e8aa00aaa23966c3.
Objective of this revert and hence removal of the unconditional
MTU/GATT-Services query is to allow user to use custom operations.
Hence only getGattServices() will trigger the 'auto config'
mechanism on the user's request.
|
|
|
|
| |
avoiding long delays (detection + connect), use in peripheral00 example;
|