mirror of
https://git.kernel.org/pub/scm/bluetooth/bluez.git
synced 2024-11-14 07:44:36 +08:00
7104f37735
Defining an override via a missing.h can prove difficult when a file needs to use basename and dirname both the APIs and needs to include libgen.h for them, in such situations there will be signature clash for basename function. |
||
---|---|---|
.. | ||
agent.c | ||
agent.h | ||
appkey.c | ||
appkey.h | ||
bluetooth-mesh.conf | ||
bluetooth-mesh.service.in | ||
bluetooth-meshd.rst.in | ||
cfgmod-server.c | ||
cfgmod.h | ||
crypto.c | ||
crypto.h | ||
dbus.c | ||
dbus.h | ||
error.h | ||
friend.c | ||
friend.h | ||
keyring.c | ||
keyring.h | ||
main.c | ||
manager.c | ||
manager.h | ||
mesh-config-json.c | ||
mesh-config.h | ||
mesh-defs.h | ||
mesh-io-api.h | ||
mesh-io-generic.c | ||
mesh-io-generic.h | ||
mesh-io-mgmt.c | ||
mesh-io-mgmt.h | ||
mesh-io-unit.c | ||
mesh-io-unit.h | ||
mesh-io.c | ||
mesh-io.h | ||
mesh-main.conf | ||
mesh-mgmt.c | ||
mesh-mgmt.h | ||
mesh.c | ||
mesh.h | ||
model.c | ||
model.h | ||
net-keys.c | ||
net-keys.h | ||
net.c | ||
net.h | ||
node.c | ||
node.h | ||
org.bluez.mesh.service | ||
pb-adv.c | ||
pb-adv.h | ||
prov-acceptor.c | ||
prov-initiator.c | ||
prov.h | ||
provision.h | ||
prv-beacon.h | ||
prvbeac-server.c | ||
README | ||
remprv-server.c | ||
remprv.h | ||
rpl.c | ||
rpl.h | ||
util.c | ||
util.h |
Bluetooth Mesh Daemon ********************* Copyright (C) 2019 Intel Corporation. All rights reserved. Compilation and installation ============================ In addition to main BlueZ requirements, MeshCtl needs the following: - json-c library Configuration and options ========================= --enable-mesh Build mesh daemon and other Bluetooth Mesh based tools Current implementation of the mesh daemon requires exclusive access to a Bluetooth controller. The AutoEnable option in the installed main.conf should be set to "false". Storage ======= Default storage directory is /var/lib/bluetooth/mesh. The directory contains the provisioned nodes configurations. Each node has its own subdirectory, named after node's Device UUID (32-digit hexadecimal string) that is generated by the application that created a node. Each subdirectory contains the following files: - node.json: node configuration and is populated by the daemon based on the configuration commands from a provisioner/configuration client - node.json.bak: a backup that the last known good node configuration. - seq_num: File containing next sequence number to use - seq_num.bak: Backup of the sequence number. This may be larger than the actual sequence number being used at runtime, to prevent re-use of sequence numbers in the event of an unexpected restart. - ./rpl/: Directory to store the sequence numbers of remote nodes, as required by Replay Protection List (RPL) parameters. - xxxx: Files named for remote Unicast addresses, and contain last received iv_index + seq_num from each SRC address. - ./dev_keys/: Directory to store remote Device keys. This is only created/used by Configuration Client (Network administration) nodes. - xxxx: Files named for remote Unicast addresses, and contains 16 octet key. - ./net_keys/: Directory to store network subnet keys. This is only created/used by Configuration Client (Network administration) nodes. - xxx: Files named for subnet index, and contains key refresh phase, and old/new versions of the key. - ./app_keys/: Directory to store application keys. This is only created/used by Configuration Client (Network administration) nodes. - xxx: Files named for application index, and contains bound subnet index, and old/new versions of the key. The node.json and node.json.bak are in JSON format. All other files are stored in little endian binary format. Known Issues ============ Bluetooth Mesh makes heavy usage of AEAD-AES_CCM encryption, which is implemented in the Linux kernel on most platforms. Some platforms, including those with kernel versions including and prior to v4.8, did *not* correctly implement the AEAD encryption routines. If Mesh is to be ported to such a system, it will be the responsibility of the vendor to provide support for AEAD-AES_CCM encryption by some other method. Support for the required AEAD routines can be determined by running the unit tests provided with the ELL libraries used by Mesh. Specifically, the tests found in .../ell/unit/test-cipher.c Information =========== Mailing lists: linux-bluetooth@vger.kernel.org For additional information about the project visit BlueZ web site: http://www.bluez.org