failed building

[mfiumara]

Hi Andrew,

Great work on this bluetooth mesh stack it looks very promising. I was trying to cargo build it but it doesn't seem to work for me out of the box.

The first issue I encounter is that it looks like the submodule is pointing to a non-existant commit

mattia@mattia-pc:github/BluetoothMeshRust ‹master*›$ git submodule update
fatal: remote error: upload-pack: not our ref 246f4410e7e89e7dc08387342941cfdcff157b3c
Fetched in submodule path 'btle', but it did not contain 246f4410e7e89e7dc08387342941cfdcff157b3c. Direct fetching of that commit failed.

I tried to resolve this by pointing to the latest tip, but then I get different errors:

mattia@mattia-pc:github/BluetoothMeshRust ‹master*›$ cargo build 
error: failed to select a version for `btle`.
 ... required by package `bluetooth_mesh v0.1.4 (/home/mattia/github/BluetoothMeshRust)`
versions that meet the requirements `= 0.1.3` are: 0.1.3

the package `bluetooth_mesh` depends on `btle`, with features: `serde-1, tokio_asyncs` but `btle` does not have these features.


failed to select a version for `btle` which could resolve this conflict

I'm running 64bit arch linux with the following toolchain:

mattia@mattia-pc:github/BluetoothMeshRust ‹master*›$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home: /home/mattia/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
beta-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.42.0 (b8cedc004 2020-03-09)

mattia@mattia-pc:github/BluetoothMeshRust ‹master*›$ 

Any help in resolving these issues? I'd be happy to contribute with CI / CD builds to keep things building. Thanks for the help.

[AndrewGi]

Sorry about the delay in response! I didn't notice the github issue!

I've been doing most the development on my single computer between both the bluetooth_mesh and btle libraries. The code has been very volatile/changing as I get a good API/Interface going so I'm sorry for the build breaks. I'm finally at a point btle is working good enough to get bluetooth_mesh into a working state (this took a couple months of work).

That being said, I am planning on getting my current code I'm working on compiling with btle and then I'm going to get CI builds working currently by adding a development branch and make master always build-passing.

If I have trouble with CI/CD, I might ask for assistance. Thank you for your help and interest in this project! I'm excited to get a stable API done!

[AndrewGi]

The repo is now passing CI/CD but there still a lot of code that still needs to be done/rework (The BlueZ code, etc). Ill work on keep master always passing CI for now and adding more tests.

[mfiumara]

Thanks for the response, just tried and it seems to be running. If you need any help on the bluez code I'd be happy to contribute, just not sure where to start, I guess that lives in the other repo?

[mfiumara]

Don't want to create another issue for this, but the cli/example does not build yet:

mattia@mattia-pc:BluetoothMeshRust/cli ‹master*›$ cargo run
 Compiling btle v0.1.4 (/home/mattia/github/BluetoothMeshRust/btle)
error[E0432]: unresolved import `crate::hci::stream::Error`
 --> /home/mattia/github/BluetoothMeshRust/btle/src/hci/socket.rs:371:26
 |
371 | use crate::hci::stream::{Error, Filter, HCIFilterable, FILTER_LEN};
 | ^^^^^
 | |
 | no `Error` in `hci::stream`
 | help: a similar name exists in the module: `error`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `btle`.

To learn more, run the command again with --verbose.

Something to do with the btle library perhaps?

[AndrewGi]

My mistake! On Unix platforms, It'll try to compile the BlueZ code (which is in the btle crate). However, I just redid a bunch of the HCI code to be less dependence on BlueZ and more agnostic. Raw USB adapters work (using libusb/rusb) but I haven't updated the BlueZ code yet.

I will try to fix that today! The API may change again in the future as I add more platforms and I realize what functionality I can expose.

I really appreciate all the issues/bug reports!

[AndrewGi]

I really need to clean up/write more docs for all of the code but if you're ever wanting to make changes/contributions, be my guest! From now on, I'm going to work on making the code easier to contribute to and read 😅

The btle crate/repo is where all the BLE code is (Bluetooth Drivers, BlueZ, HCI, etc). Originally btle was just a module in bluetooth_mesh but it got way to big so I put it in its own crate/repo. Any platforms drivers/support gets added to btle.

bluetooth_mesh is where all the Bluetooth Mesh code goes (who would guess). All the layer PDUs and primitives are defined in their respected files (net.rs for network layer, upper.rs for upper transport layer, etc). The logic for 'gluing' together the layers into the Bluetooth Mesh stack is in the stack module and takes care of all the passing between layers, reassembling, segmenting, etc. The two biggest things that needs work are the provisioning and stack modules.

I'm making the cli example into a kinda Bluetooth Mesh CLI tool (like BlueZ's mesh_cli tool) but also just as a way to test code and to show an example of how too use bluetooth_mesh.

Ideally I'm designing this (and btle) with no_std in mind but some code (like the stack module) and device specific drivers use std (for async runtime, mpsc, Mutex). Once the library is somewhat working, I would like to port/add support for embedded devices (NRF52, etc).

A lot of the logic is there just work needs to gluing together the layers and better bearer support. None of the code is done and could improvements/cleaning/fixing but I'm hoping to fix/notice most the problems while gluing them together.

Also it would be nice to have more test written to test against the sample data to the Mesh Core Spec. One more thing on my todo list!

[mfiumara]

Sounds interesting getting it to work on the nrf52, have you thought about integrating it into https://github.com/tock/tock?

In any case I'll keep on trying to get your stack to build as I'd be really interested to get it to work on a linux environment without having to use the bluez mesh dbus API. I'll open issues as I find them for now, but am not yet proficient enough in rust to actually contribute :)

[AndrewGi]

I've seen a little of rtfm but I've never heard of tock before! It looks extremely interesting and exactly what I was looking for in an Embedded OS! bluetooth_mesh doesn't have any harsh real-time requirements excepts for just making sure just one advertisement gets sent out at a time. Once I get the stack running on tokio, I'll try getting it running on tock! Thank you for showing me this!

In the future, I'd like to support Bluez DBus but right now it's using HCI raw sockets to take exclusive of the Bluetooth adapter.

I believe I fixed the BlueZ problems with AndrewGi/btle@12f6030 in the dev branch so mesh_cli ble hci dump -s bluez should print BLE advertisements to the console (you might need to run as sudo for NET_RAW privileges)

I'm not very proficient either haha. I've been working on this project and I keep rewriting and rewriting parts as I learn more and more rust. Modeling the Bluetooth Mesh stack in Rust correctly/idiomatically is a difficult problem I still struggle with which I could use all the help I could get it! The only thing I got to go off of is the Mesh Profile pdf which has error/missing information sometimes.

[mfiumara]

Getting one step further. I can actually run the cli now but even with correct capabilities the program doesn't run:

mattia@mattia-pc:BluetoothMeshRust/cli ‹dev*›$ sudo setcap 'cap_net_raw,cap_net_admin+eip' target/debug/mesh_cli
[sudo] password for mattia: 
mattia@mattia-pc:BluetoothMeshRust/cli ‹dev*›$ getcap target/debug/mesh_cli
target/debug/mesh_cli = cap_net_admin,cap_net_raw+eip
mattia@mattia-pc:BluetoothMeshRust/cli ‹dev*›$ ./target/debug/mesh_cli ble hci dump
May 01 18:22:43.555 DEBG arg_match, sub_command: ble 
May 01 18:22:43.555 DEBG hci_matches, sub_command: dump
May 01 18:22:43.556 INFO dump, sub_command: dump
hci adapter error: hci adapter error IOError(AccessDenied)

If I run as sudo I get the following:

mattia@mattia-pc:BluetoothMeshRust/cli ‹dev*›$ sudo ./target/debug/mesh_cli ble hci dump -s bluez
May 01 18:23:40.401 DEBG arg_match, sub_command: ble
May 01 18:23:40.401 DEBG hci_matches, sub_command: dump
May 01 18:23:40.401 INFO dump, sub_command: dump
error: bluez either isn't enable or supported on this platform