deprecated tools: rfcomm, can we un-deprecate it?

deprecated tools: rfcomm, can we un-deprecate it?

[Stefan Seyfried]

Hi all,

as the bluez package maintainer for openSUSE, I'm trying to transition
the package to build without "--enable-deprecated".

Now the users started asking me what to use as a replacement for the
deprecated tools.

For many of the tools, the answer is "just use bluetoothctl and let
bluetoothd handle things" (hciconfig, hcitool, sdptool)

But for rfcomm, I have not been able to find a suitable replacement.

All the other implementations of rfcomm services that I could find in a
quick search (some python modules, blueman) just basically reimplement
the functionality of rfcomm (socket(), bind(), connect(), ioctl()...),
some of them in really odd / crazy ways, which is probably not the way
to go...

So is there a way to set up a rfcomm device via bluetoothctl? I could
not find one, but maybe I did not look hard enough?

If not, could we please un-deprecate rfcomm, because having everyone out
there reinvent the functionality in crazy ways probably is not a good idea.

Or should I just continue to build the package with --enable-deprecated?
But that will ship tools with known unfixed security issues (hcidump).

Have fun,

	Stefan
-- 
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman

Re: deprecated tools: rfcomm, can we un-deprecate it?

[Marcel Holtmann]

Hi Stefan,

> as the bluez package maintainer for openSUSE, I'm trying to transition
> the package to build without "--enable-deprecated".
> 
> Now the users started asking me what to use as a replacement for the
> deprecated tools.
> 
> For many of the tools, the answer is "just use bluetoothctl and let
> bluetoothd handle things" (hciconfig, hcitool, sdptool)
> 
> But for rfcomm, I have not been able to find a suitable replacement.
> 
> All the other implementations of rfcomm services that I could find in a
> quick search (some python modules, blueman) just basically reimplement
> the functionality of rfcomm (socket(), bind(), connect(), ioctl()...),
> some of them in really odd / crazy ways, which is probably not the way
> to go...
> 
> So is there a way to set up a rfcomm device via bluetoothctl? I could
> not find one, but maybe I did not look hard enough?
> 
> If not, could we please un-deprecate rfcomm, because having everyone out
> there reinvent the functionality in crazy ways probably is not a good idea.
> 
> Or should I just continue to build the package with --enable-deprecated?
> But that will ship tools with known unfixed security issues (hcidump).

have a look at doc/profile-api.txt.

Regards

Marcel

Re: deprecated tools: rfcomm, can we un-deprecate it?

[Stefan Seyfried]

Hi Marcel,

thanks for the response.

Am 26.12.19 um 21:40 schrieb Marcel Holtmann:

>> So is there a way to set up a rfcomm device via bluetoothctl? I could
>> not find one, but maybe I did not look hard enough?
>>
>> If not, could we please un-deprecate rfcomm, because having everyone out
>> there reinvent the functionality in crazy ways probably is not a good idea.
>>
>> Or should I just continue to build the package with --enable-deprecated?
>> But that will ship tools with known unfixed security issues (hcidump).
> 
> have a look at doc/profile-api.txt.

This would be for creating a "rfcomm service" for other devices to
connect to, right? (The equivalent of "rfcomm listen...")

But how would I connect e.g. to my serial module (I got this for trying
it by myself instead of relying on bugreporters results...), so what's
the dbus equivalent of "rfcomm connect hci0 <bdaddr> <channel>"?

Some small example python script for this in test_scripts would be
really useful, as the knowledge on how to handle this seems
non-existent: all the various bluetooth codebases checked (e.g. blueman,
pybluez) just re-implement the code in tools/rfcomm.c's cmd_connect
(socket, bind, connect, ioctl RFCOMMCREATEDEV, ...).

Now from reading the kernel code, RFCOMMCREATEDEV seems to be the way to
create an rfcomm device.
The only place in bluez source code that uses RFCOMMCREATEDEV is...
tools/rfcomm.c.
So maybe the rfcomm tool is not as deprecated as we all thought? ;-)

Best regards,

	Stefan
-- 
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman

Re: deprecated tools: rfcomm, can we un-deprecate it?

[Stefan Seyfried]

Hi all,

Am 31.12.19 um 18:35 schrieb Stefan Seyfried:
> Hi Marcel,
> 
> thanks for the response.
> 
> Am 26.12.19 um 21:40 schrieb Marcel Holtmann:
> 
>>> So is there a way to set up a rfcomm device via bluetoothctl? I could
>>> not find one, but maybe I did not look hard enough?
>>>
>>> If not, could we please un-deprecate rfcomm, because having everyone out
>>> there reinvent the functionality in crazy ways probably is not a good idea.
>>>
>>> Or should I just continue to build the package with --enable-deprecated?
>>> But that will ship tools with known unfixed security issues (hcidump).
>>
>> have a look at doc/profile-api.txt.
> 
> This would be for creating a "rfcomm service" for other devices to
> connect to, right? (The equivalent of "rfcomm listen...")
> 
> But how would I connect e.g. to my serial module (I got this for trying
> it by myself instead of relying on bugreporters results...), so what's
> the dbus equivalent of "rfcomm connect hci0 <bdaddr> <channel>"?

OK, now I found https://github.com/tonyespy/bluez5-spp-example which
explains how to do this.

I'd still think an example in the bluez documentation would be useful,
because...

> the knowledge on how to handle this seems
> non-existent: all the various bluetooth codebases checked (e.g. blueman,
> pybluez) just re-implement the code in tools/rfcomm.c's cmd_connect
> (socket, bind, connect, ioctl RFCOMMCREATEDEV, ...).

Best regards,

	Stefan
-- 
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman

Re: deprecated tools: rfcomm, can we un-deprecate it?

[Johan Hedberg]

Hi Stefan,

On 4. Jan 2020, at 13.45, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
>> This would be for creating a "rfcomm service" for other devices to
>> connect to, right? (The equivalent of "rfcomm listen...")
>> 
>> But how would I connect e.g. to my serial module (I got this for trying
>> it by myself instead of relying on bugreporters results...), so what's
>> the dbus equivalent of "rfcomm connect hci0 <bdaddr> <channel>"?
> 
> OK, now I found https://github.com/tonyespy/bluez5-spp-example which
> explains how to do this.
> 
> I'd still think an example in the bluez documentation would be useful,
> because…

Doesn’t test/test-profile give a pretty good overview of both server- and client-role usage of the Profile D-Bus API? The main difference to the RFCOMM ioctls is that instead of a TTY you get a file descriptor (which I guess you could convert to a TTY using a pty). For client, another difference is that it’s a two-step process, i.e. first you register the client role profile and then you call e.g. ConnectProfile (which test-profile doesn’t cover).

Johan

Re: deprecated tools: rfcomm, can we un-deprecate it?

[Stefan Seyfried]

Hi Johan,

Am 04.01.20 um 14:18 schrieb Johan Hedberg:
> Hi Stefan,
> 
> On 4. Jan 2020, at 13.45, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
>>> This would be for creating a "rfcomm service" for other devices to
>>> connect to, right? (The equivalent of "rfcomm listen...")
>>>
>>> But how would I connect e.g. to my serial module (I got this for trying
>>> it by myself instead of relying on bugreporters results...), so what's
>>> the dbus equivalent of "rfcomm connect hci0 <bdaddr> <channel>"?
>>
>> OK, now I found https://github.com/tonyespy/bluez5-spp-example which
>> explains how to do this.
>>
>> I'd still think an example in the bluez documentation would be useful,
>> because…
> 
> Doesn’t test/test-profile give a pretty good overview of both server- and client-role usage of the Profile D-Bus API?

You are right, now that I know what I am looking for, this is exactly the example code that I need ;-)

> The main difference to the RFCOMM ioctls is that instead of a TTY you get a file descriptor (which I guess you could convert to a TTY using a pty). For client, another difference is that it’s a two-step process, i.e. first you register the client role profile and then you call e.g. ConnectProfile (which test-profile doesn’t cover).

I'll try to cook up an example application (if I get some spare time...) for the
(apparently) #1 wanted application of old rfcomm:
connecting to a "serial console" via bluetooth and then starting a terminal program on /dev/rfcomm0

This should be possible by either providing a local socket that can be connected to or a pty.

We can then decide if we include this in the bluez examples or if I provide it as a
separate project.

Best regards ans thanks for the info,

	Stefan
-- 
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman