Minimal RFCOMM client example

[manio]

Hi,
I am currently using bluetooth-serial-port-async crate in my project. Unfortunately it is rather a small and unmaintained crate and I prefer to switch to bluer for better compatibility in the future.
I only want to connect to the remote bluetooth dongle with RFCOMM and "talk" to it as a client, and this crate is really easy (you may look at example here).
While looking at bluer::rfcomm examples available or an rfcat source I am confused.
I can see opening local BT adapter (this is at least understandable for me), binding to some local sockets, creating profiles, even creating session (which is not needed when I want to act as a client, right?). Is this all needed when I only want to connect as a client to remote serial port?

Can you show me the totally minimum code for connecting to the RFCOMM dongle? I have a remote MAC address, default port (1) and I'd like to get an RFCOMM stream, on which I will then AsyncRead and AsyncWrite. That's all.

[vricosti]

I am also interested so if you have any progress please let me know.

UPDATE: it seems RFCOMM is standard bluetooth and not ble so you can use react-native-bluetooth-classic.
And just for information it's not supported on iOS

[surban]

RFCOMM client and server examples have been added.

[manio]

Much thanks! :)

[manio]

@surban
I am referring to rfcomm_client.rs
Are those three lines really necessary? Can it be omitted?

let session = bluer::Session::new().await?;
let adapter = session.default_adapter().await?;
adapter.set_powered(true).await?;

It is compiling fine without it, but then I have:
write error: Os { code: 107, kind: NotConnected, message: "Transport endpoint is not connected" }
when I am trying to write to the Stream
Isn't it because I didn't do: stream.into_split() ?

I am asking because I have a series of problems when I need to use a bluetoothd feature. First I have to patch bluer like this:

diff --git a/bluer/Cargo.toml b/bluer/Cargo.toml
index 6943adc..644922a 100644
--- a/bluer/Cargo.toml
+++ b/bluer/Cargo.toml
@@ -47,7 +47,7 @@ mesh = ["bluetoothd"]
 serde = ["uuid/serde", "dep:serde"]
 
 [dependencies]
-dbus = { version = "0.9", features = ["futures"], optional = true }
+dbus = { version = "0.9", features = ["futures", "vendored"], optional = true }
 dbus-tokio = { version = "0.7", optional = true }
 dbus-crossroads = { version = "0.5", optional = true }
 futures = "0.3"

because I am crosscompiling. Then I had to remove those above lines because I have:
/lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found
because of:

objdump -T ./my_app | grep GLIBC_2.38
0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.38) __isoc23_strtoul
0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.38) __isoc23_strtol

Edit: I connected successfully after some attempts :)
Please only tell me if I can omit those three lines (I am assuming that the bluetooth adapter should be powered on after reboot, it's a raspberry pi, not a laptop)...

[surban]

Yes, if you don't need to change the power state of the adapter, you can remove these lines.

[surban]

Also you don't need to patch bluer to enable the vendored features on dbus. Just add a dependency on dbus in your Cargo.toml and include the vendored feature.

[manio]

@surban
Sorry for bothering, but I still have one question/issue with your sample client code.

I have problems writing to the Stream with:
Os { code: 107, kind: NotConnected, message: "Transport endpoint is not connected" }

I discovered that I have this error only when:
Local address: SocketAddr { addr: 00:00:00:00:00:00, channel: 1 }

So I've added this after connect and before printing Local address:

while stream.as_ref().local_addr()?.addr == bluer::Address::any() {
    println!("Waiting for local address...");
    tokio::time::sleep(Duration::from_secs(1)).await;
}
println!("Local address: {:?}", stream.as_ref().local_addr()?);

This workaround seems to be working. For me it is about 5 seconds, then it is communicating fine.

Is it a known "problem"?
Is there some better approach for this?

[surban]

BlueR is a thin wrapper around the Linux API, thus we do not adapt or modify its behavior.

I have sometimes seen this problem and similar workarounds. However, to find out the reason for this issue I would suggest that you ask in the official BlueZ Slack channel or on the Linux Bluetooth mailing list.