2016-12-29 23:34:57

by Gregoire Gentil

[permalink] [raw]
Subject: rfcomm without bluetoothd?

Hello,

I'm posting here because there doesn't seem to be any more the
bluez-users mailing list.

I have a very optimized and constrained embedded device and I would like
to use rfcomm WITHOUT dbus and bluetoothd daemon.

The following works:

dbus-daemon --system --fork
bluetoothd
sdptool add --channel=22 SP
rfcomm listen /dev/rfcomm0 22

but I would like to use rfcomm without dbus and bluetoothd running. How
could I do that?

For reference, hidd works without bluetoothd so it's possible to
associate and have some bluetooth communication in the kernel directly
from a user-space application without bluetoothd running.

Many thanks in advance for any idea,

Grégoire


2016-12-30 07:21:13

by Johan Hedberg

[permalink] [raw]
Subject: Re: rfcomm without bluetoothd?

Hi Gr?goire,

On Thu, Dec 29, 2016, Gr?goire Gentil wrote:
> I'm posting here because there doesn't seem to be any more the bluez-users
> mailing list.
>
> I have a very optimized and constrained embedded device and I would like to
> use rfcomm WITHOUT dbus and bluetoothd daemon.
>
> The following works:
>
> dbus-daemon --system --fork
> bluetoothd
> sdptool add --channel=22 SP
> rfcomm listen /dev/rfcomm0 22
>
> but I would like to use rfcomm without dbus and bluetoothd running. How
> could I do that?

It's certainly possible, however you'll then need to provide the few
critical features that bluetoothd provides through some other means.
E.g. the BlueZ for Android implementation (see android/ subdirectory)
uses neither D-Bus nor bluetoothd. You'd still need some daemon to
provide an SDP server ("sdptool add.." talks to bluetoothd which manages
the local service records) and to handle pairing related functionality
such as responding to PIN code/passkey requests and storing the
resulting link keys (and reloading them once your daemon restarts).

Johan

2018-05-18 17:40:01

by Gregoire Gentil

[permalink] [raw]
Subject: Where is the documentation of l2cap_options?

Hello,


I have a couple of questions regarding l2cap_options.

I have posted the main question on Stackoverflow:
https://stackoverflow.com/questions/50380020/where-is-the-documentation-of-l2cap-options


I would like to play with the options of l2cap. But there is no
documentation even in the kernel header. Where can I find a description
of the different fields?

On my system, I see:
omtu:0 imtu:672 flush_to:65535 mode:0 fcs:1 max_tx:3 txwin_size:63

I don't understand why omtu is different from imtu. What are the other
options?


Also, on this page
https://people.csail.mit.edu/albert/bluez-intro/x95.html#l2cap-and-udp,
it says that there are three policies possible: never retransmit,
default, drop and move. How do I select the policy?

I was guessing that the "default" is to have flush timeout of 0 and the
"drop and move" after x ms is just to put a specific timeout (knowing
that 1279ms = 0x7ff * 625us). Am I right? But then how do you select
"never retransmit"?


Grégoire