[opensuse-factory] Heads up: bluez-package will get rid of the deprecated binaries.
Hi all, I want to announce a small change in the bluez package: some time from now, it will be built without the "--enable-deprecated" configure switch. This switch causes the old deprecated (by upstream) tools to be built. Right now, they are built and pacakged in the bluez package. The first step will be to split them off into a "bluez-deprecated" package, which contains the following binaries: /usr/bin/ciptool /usr/bin/gatttool /usr/bin/hciattach /usr/bin/hciconfig /usr/bin/hcidump /usr/bin/hcitool /usr/bin/rfcomm /usr/bin/sdptool In the not too far future, the bluez-deprecated package will be dropped and bluez will be built without "--enable-deprecated". If I had to guess now, I would say that "not too far future" means "end of 2020". Why do this? These tools are officially abandoned and deprecated by upstream, and issues, even security problems have to be fixed. Upstream does no longer maintain or fix bugs / issues in these tools. If you have a problem with these tools going away, *please raise these issues with bluez upstream*. The bluez / bluez-deprecated split will take place with the next factory submission. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 16. 12. 19, 15:39, Stefan Seyfried wrote:
Hi all,
I want to announce a small change in the bluez package: some time from now, it will be built without the "--enable-deprecated" configure switch.
This switch causes the old deprecated (by upstream) tools to be built. Right now, they are built and pacakged in the bluez package.
The first step will be to split them off into a "bluez-deprecated" package, which contains the following binaries:
/usr/bin/ciptool /usr/bin/gatttool /usr/bin/hciattach /usr/bin/hciconfig /usr/bin/hcidump /usr/bin/hcitool /usr/bin/rfcomm /usr/bin/sdptool
In the not too far future, the bluez-deprecated package will be dropped and bluez will be built without "--enable-deprecated". If I had to guess now, I would say that "not too far future" means "end of 2020".
Perhaps you can also point us to some document defining in favor of what they are deprecated. I.e. what we are supposed to use instead of the above? thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Jiri, I'm writing the below hints mostly from reading the tool's manpages, because I have not used them ever (and I have done some debugging on bluetooth issues during the last 15 years... ;-) Am 17.12.19 um 14:36 schrieb Jiri Slaby:
On 16. 12. 19, 15:39, Stefan Seyfried wrote:
The first step will be to split them off into a "bluez-deprecated" package, which contains the following binaries:
/usr/bin/ciptool
This is a tool for managing the "Bluetooth Common ISDN Access Profile (CIP)", I'd guess that boxes like the old BlueFritz! bluetooth isdn adapter probably might need this. I doubt this is still in use by anyone.
/usr/bin/gatttool
This is something about Bluetooth Low Energy (BLE) IIUC, I'd guess its functionality will be available via bluetoothctl nowadays.
/usr/bin/hciattach
A tool to connect serial UART Bluetooth devices. Newer tool is btattach.
/usr/bin/hciconfig /usr/bin/hcitool /usr/bin/sdptool
bluetoothd together with bluetoothctl
/usr/bin/hcidump
btmon (hcidump actually is the one that needs security patches that upstream no longer wants to include)
/usr/bin/rfcomm
bluetoothd together with bluetoothctl
In the not too far future, the bluez-deprecated package will be dropped and bluez will be built without "--enable-deprecated". If I had to guess now, I would say that "not too far future" means "end of 2020".
Perhaps you can also point us to some document defining in favor of what they are deprecated. I.e. what we are supposed to use instead of the above?
I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications. Basically the upstream reasoning for deprecating these tools is that bluetoothd as the central service is handling all this in a coordinated way and should be used (vie bluetoothctl or desktop applets) to perform the tasks that these tools did. As an example, a manual "hcitool scan" did interfere with things bluetoothd does and settings done with "hciconfig" were not persisted anywhere (and bluetoothd did not know about them and thus did not work correctly), so this is why these tools were deprecated. At least that's how I understood it :-) I have been using bluetoothctl for almost all my configuration and debugging tasks and could perform all tasks that I needed. It's even better than using a desktop applet, since I can copy and paste the bluetoothctl commands easily into a HOWTO or a bug report ;-) Have fun, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2019-12-17 at 15:16 +0100, Stefan Seyfried wrote: ...
I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.
On IRC someone just said "bluez-devel has been removed from the python3 build". Is this related? :-? - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXfjl5xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV7NcAoI8aQif+VNiIK5GZargk k7rqSsciAJ0Z6hSYVNE1d3L/Kv25duvUqqj6+A== =IFgX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 17.12.19 um 15:27 schrieb Carlos E. R.:
On Tuesday, 2019-12-17 at 15:16 +0100, Stefan Seyfried wrote:
...
I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.
On IRC someone just said "bluez-devel has been removed from the python3 build". Is this related? :-?
I guess you have to ask "someone". -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/12/2019 08.49, Stefan Seyfried wrote:
Am 17.12.19 um 15:27 schrieb Carlos E. R.:
On Tuesday, 2019-12-17 at 15:16 +0100, Stefan Seyfried wrote:
...
I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.
On IRC someone just said "bluez-devel has been removed from the python3 build". Is this related? :-?
I guess you have to ask "someone".
Sorry, it is that "someone" who is asking openSUSE. He found that it (b-d in python3) has been removed, and the question is if that removal is related to this removal commented in the OP, or is unrelated. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXfoJDwAKCRC1MxgcbY1H 1XPfAKCYNTFPKSSi8lUdx05WdiRzzDvjagCfcj2+SFU8tweTB6bg7jAnL1aPxMo= =da6f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.12.19 um 12:10 schrieb Carlos E. R.:
On 18/12/2019 08.49, Stefan Seyfried wrote:
Am 17.12.19 um 15:27 schrieb Carlos E. R.:
On Tuesday, 2019-12-17 at 15:16 +0100, Stefan Seyfried wrote:
...
I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.
On IRC someone just said "bluez-devel has been removed from the python3 build". Is this related? :-?
I guess you have to ask "someone".
Sorry, it is that "someone" who is asking openSUSE.
He found that it (b-d in python3) has been removed, and the question is if that removal is related to this removal commented in the OP, or is unrelated.
I have no idea why python3 would ever have depended on bluez-devel, but I don't think this is related, but just "somebody" cleaned out old cruft from python3 spec files. see the $SUBJECT: nothing about bluez-devel, just getting rid of deprecated tools. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/12/2019 13.33, Stefan Seyfried wrote:
Am 18.12.19 um 12:10 schrieb Carlos E. R.:
On 18/12/2019 08.49, Stefan Seyfried wrote:
Am 17.12.19 um 15:27 schrieb Carlos E. R.:
On Tuesday, 2019-12-17 at 15:16 +0100, Stefan Seyfried wrote:
...
I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.
On IRC someone just said "bluez-devel has been removed from the python3 build". Is this related? :-?
I guess you have to ask "someone".
Sorry, it is that "someone" who is asking openSUSE.
He found that it (b-d in python3) has been removed, and the question is if that removal is related to this removal commented in the OP, or is unrelated.
I have no idea why python3 would ever have depended on bluez-devel, but I don't think this is related, but just "somebody" cleaned out old cruft from python3 spec files.
see the $SUBJECT: nothing about bluez-devel, just getting rid of deprecated tools.
Ok, thanks! - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXfo50AAKCRC1MxgcbY1H 1Uw3AJ9F08OTG8Ku9+/jI+Ec5TddSGLtiACgmPDw2GBvWvNV/NnbKvkU5fuA6i0= =lQju -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mittwoch, 18. Dezember 2019 13:33:33 CET Stefan Seyfried wrote:
Am 18.12.19 um 12:10 schrieb Carlos E. R.:
On 18/12/2019 08.49, Stefan Seyfried wrote: He found that it (b-d in python3) has been removed, and the question is if that removal is related to this removal commented in the OP, or is unrelated.
I have no idea why python3 would ever have depended on bluez-devel, but I don't think this is related, but just "somebody" cleaned out old cruft from python3 spec files.
see the $SUBJECT: nothing about bluez-devel, just getting rid of deprecated tools.
Just to shed some light on why Python requires bluez-devel: Pythons 'socket' module has optional support for the AF_BLUETOOTH protocol family, but it is only enabled when bluez-devel is available during build. As socket is a dependency of many other modules it is built as part of python3-base. python3-base is a build dependency of many other packages, probably 2/3rd of all TW packages depend on it (directly or indirectly). Most importantly, python3-base is also a build dependency of bluez. The bluez-devel BuildRequires was moved from python3 to python3-base to make AF_BLUETOOTH available in pythons socket, but as it introduces a build loop it was removed again. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/12/2019 18.26, Stefan Brüns wrote:
On Mittwoch, 18. Dezember 2019 13:33:33 CET Stefan Seyfried wrote:
Am 18.12.19 um 12:10 schrieb Carlos E. R.:
On 18/12/2019 08.49, Stefan Seyfried wrote: He found that it (b-d in python3) has been removed, and the question is if that removal is related to this removal commented in the OP, or is unrelated.
I have no idea why python3 would ever have depended on bluez-devel, but I don't think this is related, but just "somebody" cleaned out old cruft from python3 spec files.
see the $SUBJECT: nothing about bluez-devel, just getting rid of deprecated tools.
Just to shed some light on why Python requires bluez-devel:
Pythons 'socket' module has optional support for the AF_BLUETOOTH protocol family, but it is only enabled when bluez-devel is available during build.
As socket is a dependency of many other modules it is built as part of python3-base. python3-base is a build dependency of many other packages, probably 2/3rd of all TW packages depend on it (directly or indirectly). Most importantly, python3-base is also a build dependency of bluez.
The bluez-devel BuildRequires was moved from python3 to python3-base to make AF_BLUETOOTH available in pythons socket, but as it introduces a build loop it was removed again.
Ah, thanks! I hope the IRC person that initially asked reads this. He is not online now. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXfu+hAAKCRC1MxgcbY1H 1WXVAJ9M8u1jhkUY12TqbIMeJiakbZtzTwCfXAmQJu5sW6ysq/AYW7Dc/3L4ZHI= =7CbD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 19.12.19 um 18:26 schrieb Stefan Brüns:
Just to shed some light on why Python requires bluez-devel:
Pythons 'socket' module has optional support for the AF_BLUETOOTH protocol family, but it is only enabled when bluez-devel is available during build.
OK, this explains things ;-) However, I guess using socket() with AF_BLUETOOTH is exactly the low-level access that bluez upstream frowns upon and that is basically discouraged by dropping the deprecated binaries and letting bluetoothd handle all this stuff.
As socket is a dependency of many other modules it is built as part of python3-base. python3-base is a build dependency of many other packages, probably 2/3rd of all TW packages depend on it (directly or indirectly). Most importantly, python3-base is also a build dependency of bluez.
The bluez-devel BuildRequires was moved from python3 to python3-base to make AF_BLUETOOTH available in pythons socket, but as it introduces a build loop it was removed again.
Maybe just copying /usr/include/bluetooth/bluetooth.h from bluez-devel to the python package and using it during build is probably a way to work around the build loop issue. I doubt that anyone is linking against libbluetooth nowadays, it's basically just a collection of some endianness byteswap functions. Are there actual users of AF_BLUETOOTH from python? (just being curious...) Thanks for the explanation, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 17 Dec 2019 15:16:38 +0100, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Hi Jiri,
I'm writing the below hints mostly from reading the tool's manpages, because I have not used them ever (and I have done some debugging on bluetooth issues during the last 15 years... ;-)
I was scanning a README that I once wrote for myself to get my phone connected. Taking this as a starting point ...
Am 17.12.19 um 14:36 schrieb Jiri Slaby:
On 16. 12. 19, 15:39, Stefan Seyfried wrote: : :
/usr/bin/hciattach
A tool to connect serial UART Bluetooth devices. Newer tool is btattach.
Clear and mostly obvious. $ hciattach help hciattach - HCI UART driver initialization utility Usage: hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty> <type | id> [speed] [flow|noflow] [sleep|nosleep] [bdaddr] hciattach -l $ btattach --help btattach - Bluetooth serial utility Usage: btattach [options] options: -B, --bredr <device> Attach Primary controller -A, --amp <device> Attach AMP controller -P, --protocol <proto> Specify protocol type -S, --speed <baudrate> Specify which baudrate to use -N, --noflowctl Disable flow control -h, --help Show help options
/usr/bin/hciconfig /usr/bin/hcitool /usr/bin/sdptool
bluetoothd together with bluetoothctl
Is there a manual describing how to convert scripts using the old tools to describing how that would be done in the new? # hciconfig hci0 up What would I need to do to use the new tools?
/usr/bin/hcidump
btmon (hcidump actually is the one that needs security patches that upstream no longer wants to include)
Clear
/usr/bin/rfcomm
bluetoothd together with bluetoothctl
Same as with the other tools: is there a walkthrough for conversion?
In the not too far future, the bluez-deprecated package will be dropped and bluez will be built without "--enable-deprecated". If I had to guess now, I would say that "not too far future" means "end of 2020".
Perhaps you can also point us to some document defining in favor of what they are deprecated. I.e. what we are supposed to use instead of the above?
I have listed the replacements as far as I know them above below the tools, other tools (or snippets for writing your own) are in the bluez-test package, which consists mostly of small python demo applications.
Basically the upstream reasoning for deprecating these tools is that bluetoothd as the central service is handling all this in a coordinated way and should be used (vie bluetoothctl or desktop applets) to perform the tasks that these tools did. As an example, a manual "hcitool scan" did interfere with things bluetoothd does and settings done with "hciconfig" were not persisted anywhere (and bluetoothd did not know about them and thus did not work correctly), so this is why these tools were deprecated. At least that's how I understood it :-)
I have been using bluetoothctl for almost all my configuration and debugging tasks and could perform all tasks that I needed. It's even better than using a desktop applet, since I can copy and paste the bluetoothctl commands easily into a HOWTO or a bug report ;-)
Have fun,
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Am 18.12.19 um 12:26 schrieb H.Merijn Brand:
On Tue, 17 Dec 2019 15:16:38 +0100, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Hi Jiri,
I'm writing the below hints mostly from reading the tool's manpages, because I have not used them ever (and I have done some debugging on bluetooth issues during the last 15 years... ;-)
I was scanning a README that I once wrote for myself to get my phone connected. Taking this as a starting point ...
Am 17.12.19 um 14:36 schrieb Jiri Slaby:
On 16. 12. 19, 15:39, Stefan Seyfried wrote: : :
/usr/bin/hciattach
A tool to connect serial UART Bluetooth devices. Newer tool is btattach.
Clear and mostly obvious.
Yes. Nobody on PC hardware has used this tool during the last 10 years.
/usr/bin/hciconfig /usr/bin/hcitool /usr/bin/sdptool
bluetoothd together with bluetoothctl
Is there a manual describing how to convert scripts using the old tools to describing how that would be done in the new?
no, but bluetoothctl has a "help" command in the interactive shell.
# hciconfig hci0 up
[bluetooth]# power on Changing power on succeeded Did you ever need this command the last 10 years? bluetoothd should have upped the controllers already.
What would I need to do to use the new tools?>
/usr/bin/hcidump
btmon (hcidump actually is the one that needs security patches that upstream no longer wants to include)
Clear
/usr/bin/rfcomm
bluetoothd together with bluetoothctl
Same as with the other tools: is there a walkthrough for conversion?
Not that I know of. Do you know hardware (which can still be bought) that talks raw rfcomm so I could test? All the common stuff (ppp over rfcomm to a phone or such) is handled by NetworkManager / ModemManager and similar tools. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18/12/2019 14.06, Stefan Seyfried wrote:
Not that I know of.
Do you know hardware (which can still be bought) that talks raw rfcomm so I could test?
All the common stuff (ppp over rfcomm to a phone or such) is handled by NetworkManager / ModemManager and similar tools.
~4 years ago, I used raw rfcomm to have my perl scripts communicate with the Lego Mindstorms (I think 2nd edition) - not sure what the current version uses but it probably still is bluetooth. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue 17-12-19 15:16:38, Stefan Seyfried wrote: [...]
/usr/bin/gatttool
This is something about Bluetooth Low Energy (BLE) IIUC, I'd guess its functionality will be available via bluetoothctl nowadays.
Yes. As far as I can tell, gatttool functions are also available under 'gatt' menu in bluetoothctl. Libor -- Libor Pechacek SUSE Labs Remember to have fun... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I regularly use an i-Blue 747A+ Bluetooth GPS Trip Recorder. It is a GPS data receiver that provides both bluetooth and USB connectivity. It can also store the data for later download, via USB only. I'm not sure the 747A+ is still sold but other brands based on the same MediaTek MTK chipset, and with similar functionality, are available. e.g. the Qstarz GPS Datalogger BT-Q1000XT. These device are quite common. For my use case, the 747A+ provides GPS data via bluetooth to a Netbook running a moving map program (OziExplorer running under Wine). I use a bash script, triggered by udev, to bind the 747A+ to /dev/rfcomm, which is soft linked with the COM port used by OziExplorer. The set up has worked well for many years. My udev script first runs "/usr/bin/hciconfig hci0 up" to ensure the controller is available. It appears /usr/bin/hciconfig can be replaced by echoing commands to bluetoothctl. e.g. " echo -e "trust $MAC\nconnect $MAC\nquit" | bluetoothctl". A workable kludge I guess. However, finding a replacement for the primary command, "/usr/bin/rfcomm bind /dev/rfcomm0 <GPS>", is another story. In an earlier reply Stefan indicated that /usr/bin/rfcomm can also be replaced by 'bluetoothd together with bluetoothctl'. I am not skilled with bluetooth and the bluetoothctl help is pretty sparse but I can't find anything there to set up /dev/rfcomm and bind a device to it. An example would be very helpful. Google failed me as well. The stuff I could find suggests it must now be set up via dbus. But this is not straight forward and one of the bluez devs commented that it would be better for non-experts to try the Python based Blue Dot library. I had a play with the Blue Dot library but it simply throws the exception "AttributeError: module 'socket' has no attribute 'AF_BLUETOOTH'", which is not surprising given the earlier comment that AF_BLUETOOTH was removed from Python on openSUSE. So, in summary, yes there are users of this stuff; there is a workable alternative to at least some of the hcixxx commands; but a replacement for /usr/bin/rfcomm is problematic. Graeme Blackman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 21.12.19 um 07:19 schrieb Graeme Blackman:
I had a play with the Blue Dot library but it simply throws the exception "AttributeError: module 'socket' has no attribute 'AF_BLUETOOTH'", which is not surprising given the earlier comment that AF_BLUETOOTH was removed from Python on openSUSE.
I don't think anything using socket() with AF_BLUETOOTH is advisable. bluez-test package contains /usr/lib64/bluez/test/test-sap-server that does some RFCOMM stuff, it is using python-pybluez (which apparently does not need AF_BLUETOOTH). blueman definitely does setup rfcomm from python, because it somehow does dial-up-networking via bluetooth, and grepping for RFCOMM in its code gives lots of results. If you all collect some example code for achieving differnt things that were previously done using the old binaries, I'd be happy to include that as a README in the SUSE bluez package, (and also submit it upstream). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 21.12.19 um 10:08 schrieb Stefan Seyfried:
[...]
I have now ordered a Kit containing amongst others a HC-05 serial bluetooth module for Arduino&co, so I guess I will be able to verify rfcomm soon (unfortunately, all my phones only support NAP/PANU but not DUN profile). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Samstag, 21. Dezember 2019 10:08:13 CET Stefan Seyfried wrote:
Am 21.12.19 um 07:19 schrieb Graeme Blackman:
I had a play with the Blue Dot library but it simply throws the exception "AttributeError: module 'socket' has no attribute 'AF_BLUETOOTH'", which is not surprising given the earlier comment that AF_BLUETOOTH was removed from Python on openSUSE.
I don't think anything using socket() with AF_BLUETOOTH is advisable.
bluez-test package contains /usr/lib64/bluez/test/test-sap-server that does some RFCOMM stuff, it is using python-pybluez (which apparently does not need AF_BLUETOOTH).
python-pybluez wraps the raw socket itself [1], so it does not depend on AF_BLUETOOTH support in pythons core socket module. Kind regards, Stefan [1] https://github.com/pybluez/pybluez/blob/master/bluez/btmodule.c#L255 -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Hi all, I have had a closer look at various code bases, including bluez git, pybluez, blueman. Am 21.12.19 um 14:25 schrieb Stefan Brüns:
On Samstag, 21. Dezember 2019 10:08:13 CET Stefan Seyfried wrote:
Am 21.12.19 um 07:19 schrieb Graeme Blackman:
I had a play with the Blue Dot library but it simply throws the exception "AttributeError: module 'socket' has no attribute 'AF_BLUETOOTH'", which is not surprising given the earlier comment that AF_BLUETOOTH was removed from Python on openSUSE.
I don't think anything using socket() with AF_BLUETOOTH is advisable.
bluez-test package contains /usr/lib64/bluez/test/test-sap-server that does some RFCOMM stuff, it is using python-pybluez (which apparently does not need AF_BLUETOOTH).
python-pybluez wraps the raw socket itself [1], so it does not depend on AF_BLUETOOTH support in pythons core socket module.
...and this is basically reimplementing the functionality of the rfcomm binary... ;-) Blueman is also more or less doing the same. So if the solution for "what to use instead of /usr/bin/rfcomm" is "implement the same funcitonality in $OTHER_LANGUAGE", then keeping the rfcomm binary seems to be the best choice. I have inquired upstream about this and asked to un-deprecate rfcomm. Let's see what comes out of this discussion. If there is no resolution, I can still patch bluez to "un-deprecate" rfcomm for openSUSE :-) Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/12/19 8:10 pm, Stefan Seyfried wrote:
So if the solution for "what to use instead of /usr/bin/rfcomm" is "implement the same funcitonality in $OTHER_LANGUAGE", then keeping the rfcomm binary seems to be the best choice.
I have inquired upstream about this and asked to un-deprecate rfcomm.
Let's see what comes out of this discussion. If there is no resolution, I can still patch bluez to "un-deprecate" rfcomm for openSUSE :-)
Stefan Many thanks for your efforts, they are really appreciated. Un-deprecating rfcomm upstream would be such a great result for many frustrated users. A further issue. I have UnitedRemote Server installed on my netbook to allow remote control of the moving map software from an Android phone via bluetooth. I run bluetoothd in compatibility mode (/usr/lib/bluetooth/bluetoothd --compat) to force it to create the required Service Discovery Protocol socket (/run/sdp); and all is good. But I suspect compatibility mode will cease be available after the proposed removal of /usr/bin/sdptool; could you please confirm whether this is the case. Obviously I'm concerned the creation of /run/sdp, or its successor, will become quite complex/difficult for a non-expert. I don't see that the suggested "bluetoothd together with bluetoothctl" will provide an alternative in this case so the answer may be to try and adapt one of the bluez test examples; maybe example-gatt-server or example-advertisement. But seriously. Do you think there is a case for un-deprecating sdptool as well? Graeme -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.12.19 um 05:47 schrieb Graeme Blackman:
Do you think there is a case for un-deprecating sdptool as well?
No. I think this "UnitedRemote Server" should just register itself properly to bluetoothd. cf /usr/share/doc/packages/bluez/dbus-apis/profile-api.txt BlueZ D-Bus Profile API description *********************************** Profile Manager hierarchy ========================= Service org.bluez Interface org.bluez.ProfileManager1 Object path /org/bluez void RegisterProfile(object profile, string uuid, dict options) This registers a profile implementation. This is not new high-tech stuff. I has been around and recommended since bluez-5.0, which is now 5 years old. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Graeme. Am 23.12.19 um 05:47 schrieb Graeme Blackman:
On 22/12/19 8:10 pm, Stefan Seyfried wrote:
I have inquired upstream about this and asked to un-deprecate rfcomm.
Let's see what comes out of this discussion. If there is no resolution, I can still patch bluez to "un-deprecate" rfcomm for openSUSE :-)
Many thanks for your efforts, they are really appreciated. Un-deprecating rfcomm upstream would be such a great result for many frustrated users.
I guess that this (upstream bluez un-deprecating rfcomm tool) will not happen: I have been pointed to the doc/profile-api.txt and after investigating I have been able to use it to create both a SPP server and a SPP client, using the examples from https://ukbaz.github.io/howto/AppInventor.html (for the SPP server) and https://github.com/tonyespy/bluez5-spp-example (for both SPP server and client). It does not create /dev/rfcommX devices, though. Best regards, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Stefan Thanks again for following up with the bluez devs. Given the lack of an alternative to /dev/rfcommX, is it still your intention to patch bluez to "un-deprecate" rfcomm for openSUSE? Best regards Graeme On 4/1/20 11:09 pm, Stefan Seyfried wrote:
Hi Graeme.
Am 23.12.19 um 05:47 schrieb Graeme Blackman:
On 22/12/19 8:10 pm, Stefan Seyfried wrote:
I have inquired upstream about this and asked to un-deprecate rfcomm.
Let's see what comes out of this discussion. If there is no resolution, I can still patch bluez to "un-deprecate" rfcomm for openSUSE :-) Many thanks for your efforts, they are really appreciated. Un-deprecating rfcomm upstream would be such a great result for many frustrated users. I guess that this (upstream bluez un-deprecating rfcomm tool) will not happen: I have been pointed to the doc/profile-api.txt and after investigating I have been able to use it to create both a SPP server and a SPP client, using the examples fromhttps://ukbaz.github.io/howto/AppInventor.html (for the SPP server) andhttps://github.com/tonyespy/bluez5-spp-example (for both SPP server and client). It does not create /dev/rfcommX devices, though.
Best regards,
Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 05.01.20 um 06:00 schrieb Graeme Blackman:
Hi Stefan
Thanks again for following up with the bluez devs.
Given the lack of an alternative to /dev/rfcommX, is it still your intention to patch bluez to "un-deprecate" rfcomm for openSUSE?
not really, as there are alternatives. See the links I posted. I plan to do a POC python script to show how to do this and maybe get it into upstream bluez doc, but don't know when I get to it. test-profile from the bluez-test package is a good starting point (once you know what you are looking for ;-). Best regards, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 17. 12. 19, 15:16, Stefan Seyfried wrote:
Hi Jiri,
/usr/bin/hciconfig /usr/bin/hcitool /usr/bin/sdptool
bluetoothd together with bluetoothctl
/usr/bin/hcidump
btmon (hcidump actually is the one that needs security patches that upstream no longer wants to include) Thanks!
-- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Bernhard M. Wiedemann -
Carlos E. R. -
Graeme Blackman -
H.Merijn Brand -
Jiri Slaby -
Libor Pechacek -
Stefan Brüns -
Stefan Seyfried