Bluetooth, der ewige Mist

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Bluetooth, der ewige Mist

Beitrag von scientific » 15.09.2017 13:58:35

Hi Leute!

Mein Bluetooth am Laptop funktioniert jetzt dank zweiter Antenne für die Audio-Wiedergabe sehr gut. ABER...

Ein paar Probleme bestehen weiterhin. Wähle ich für mein neues BT-Headset nicht A2DP als Audio-Profil sondern HSP/HFP, dann gibts das große Krachen.
Das Journal füllt sich währenddessen mit folgenden Meldungen:
Dann verabschiedet sich das BT-Device und wird nach einer gewissen Zeit wieder neu connected.

Wenn ich nach

Code: Alles auswählen

SCO packet for unknown connection handle
suche, gibt es unzählige Fehlermeldungen, aber nirgends eine Lösung, oder den Hinweis, dass das Problem mit einem Update gelöst wurde.

Das mit dem Update kann ich hier nicht bestätigen. Denn diese Meldungen finden sich in Forenbeiträgen aus den Jahren 2012 - 2015...

Ich habe jetzt einmal folgendes gefunden:

https://lists.ofono.org/pipermail/ofono ... 15891.html
Der erste Link nach ewigem Suchen, der zumindest einmal erklärt, worum es hier geht.
Aber Lösung ist es noch keine.

Hat irgendjemand Ideen dazu?

Beim Start des bluetoothd gibts noch:

Code: Alles auswählen

Failed to obtain handles for "Service Changed" characteristic
Wenn in der /etc/bluetooth/main.cfg eingetragen ist

Code: Alles auswählen

ControllerMode = dual
Ändere ich dual auf bredr, fehlt diese Fehlermeldung beim restart von bluetoothd. Ändere ich es auf le, wird das Headset nicht erkannt...

Soweit einmal ein Bericht. Ich muss jetzt leider weg und ergänze das noch am Abend.

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 16.09.2017 09:12:43

Im verlinkten Beitrag steht:
I've made a patch for this issue. It's already in Bluetooth-next tree and was merged to linux-next. It is not yet in any official kernel. It removes any leftover fragments that are there between SCO connections. If you are able to compile you own kernel then add this commit: http://git.kernel.org/cgit/linux/kernel ... d0f743f1a7 Also note that SCO handling is a bit buggy in the kernel. I'm now pursuing few crashes at SCO creation and disconnection.
Das war 2015. Ob ich diesen Patch in einen 4.13 einbauen kann? Oder ist der mglw. eh schon drin?

Jedenfalls scheints, als sei das wirklich buggy. Immer noch.

Spannend ist ja, wenn ich mit den Optionen von bluetoothd (auf der cmdl und in den configs) und mit den Moduloptionen von btusb herumspiele, dass manchmal auf einmal diese Fehlermeldungen verschwinden. Dann kann ich aber auch das Profil von hfp/hsp nicht mehr zu a2dp wechseln, und sound kommt auch keiner mehr aus dem headset...

disable_scofix und force_scofix in den Moduloptionen verändern definitiv etwas am Verhalten...

Die oft genannte (auch für bluez5) audio.conf in /etc/bluetooth/ veränderd aber nix im Verhalten.

Ich krieg beim Starten immer den Fehler, dass der sdp-server fehlgeschlagen ist "permission denied". Das würde eine WAN-Modul bzw. eine SIM-Karte im Laptop dem Handy servieren... Brauch ich nich, daher hab ich mit "--diable_plugins=sap" im bluetootd-Aufruf dieses deaktiviert. Fehlermeldung ist weg.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 16.09.2017 11:55:12

Hab mit mal die Sourcen von linux 4.9.30 runtergeladen und die genannte Datei (drivers/bluetooth/btusb.c) angesehen. Es schein, als ob der Patch da schon drinnen ist.

Nutzt in dem Falle bei mir nix. Der Fehler ist trotz Patch da.

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
KBDCALLS
Moderator
Beiträge: 22355
Registriert: 24.12.2003 21:26:55
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dortmund
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von KBDCALLS » 16.09.2017 13:12:28

In den proposed-updates für Stretch gibts schon einen 4.9.47. Ob der weiterhilft, bei deinem Problem ? Bluetooth scheint aber eh vollkommen kaputt zu sein.
Wobei wohl eher Mobilgeräte betroffen sind.
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.

EDV ist die Abkürzung für: Ende der Vernunft

Bevor du einen Beitrag postest:
  • Kennst du unsere Verhaltensregeln
  • Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 16.09.2017 15:28:34

Ich hatte schon 4.13 am Laufen, bin dann auf 4.12 zurück, da ich mit 4.13 immer wieder Totalabstürze hatte.
Der Patch ist schon in 4.9.30 und auch in den Sourcen von 4.13 enthalten. Hab auch hier grad nachgesehen.

Den Link von Heise hab ich heut auch schon gelesen. Aber wie ich sah, werden bei Ubuntu und anderen Distris schon die Patches verteilt. Debian hinkt hier offenbar etwas nach:

https://security-tracker.debian.org/tra ... 17-1000251

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
KBDCALLS
Moderator
Beiträge: 22355
Registriert: 24.12.2003 21:26:55
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dortmund
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von KBDCALLS » 16.09.2017 17:28:34

Mit welcher Kernelversion die verteilt werden, das haben sie nicht dabeigerschrieben. :facepalm:
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.

EDV ist die Abkürzung für: Ende der Vernunft

Bevor du einen Beitrag postest:
  • Kennst du unsere Verhaltensregeln
  • Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 17.09.2017 12:32:17

Ich hab bei Debian ein wenig nachgelesen... Debian hat eine "Stackschutzoption" im Kernel aktiviert.

Das bedeutet, dass ein Angriffsversuch maximal einen Absturz des Systems verusachen kann, aber nie eine Fremdübernahme.

Ein Totalabsturz ist zwar lästig (am Desktop), aber nicht bedenklich bzgl Sicherheit. Am Server kommt Bluetooth selten zum Einsatz.
Daher stimmt die Heise-Meldung so nicht...
Wie das am Androiden ausschaut, weiß ich leider nicht. Macht mich aber ein wenig unentspannt...

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 26.09.2017 10:08:48

Ich hab mir ein BT-Headset zugelegt... Grundsätzlich bin ich damit auch zufrieden.

Was mir aber auffällt... und das liegt wohl nicht an Linux, sondern an der Technik selbst...
Hab ich das Smartphone in der linken Hosentasche eingesteckt und stehe aufrecht, oder schaue ein wenig nach rechts, bricht die Verbindung ab bzw. stottert extrem. Der Empfänger ist auf der rechten Seite des Headsets. Es ist also mein Bauch dazwischen... Und der ist gar nicht mal so rund...

Hab ichs in der rechten Hosentasche, also direkte Sichtverbindung von Handy zu Empfänger am Headset (Nur der Stoff der Hose ist dazwischen), gehts etwas besser. Es reicht aber meine Hand am Smartphone (auch außen an der Hose), und die Verbindung stottert.

Ein Multimedia-Laptop steht unter meinem Schreibtisch. Entfernung zum Headset ca 75cm. Dazwischen ist nur eine ca 2,5cm dicke Schreibtischplatte (und ein wenig meine Hände...). Die Verbindung ist besser, als wenn mein Bauch dazwischen ist... aber in bestimmten Positionen stottert BT auch hier...

Ich weiß, dass feuchtes Holz, Körpermasse, feuchte Ziegeln, also alles Wasser sich auf die Verbindungsqualität massiv negativ auswirkt, so es in der direkten Sichtlinie ist.
Aber dass ein wenig Bauch dazwischen schon ausreicht (ca 80cm Entfernung von Hosentasche zu Headset) um die Verbindung unbrauchbar zu machen... find ich schon heftig.
Muss ich direkt mal an meiner Freundin probieren... die hat nur die Hälfte meiner Körpermasse... :)

Liegt das eurer Erfahrung nach an einem zu schwachen Sender im Laptop/Smartphone oder am Empfänger im Headset? Oder ist die BT-LowEnergy-Geschichte "schuld" an so wackeligen Verbindungen?

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Bluetooth, der ewige Mist

Beitrag von smutbert » 26.09.2017 10:27:17

ich kann hauptsächlich die Erfahrung von einer Bluetooth-Maus und einem spielzeugartigem Headset anbieten:

Die Verbindung zur Maus kam durch eine 25mm dicke Tischplatte schon so gut wie überhaupt nicht mehr zustande - dieselbe Erfahrung habe ich übrigens früher schon einmal mit Tastatur und Maus mit proprietärer Funktechnik gemacht. Dabei wäre die Entfernung an sich geradezu lächerlich (< 30cm). Seitdem mag ich nur mehr Eingabegeräte mit Kabel....

Bei dem spielzeugartigen Headset (hatte etwas mit Star Trek zu tun :mrgreen:) war die Verbindung bei einem Exemplar in Ordnung, auch durch die Tischplatte - leider war das Ding schon im Auslieferungszustand in anderer Hinsicht defekt und das Ersatzexemplar hat so gut wie überhaupt keine stabile Verbindung zustande gebracht, auch nicht komplett ohne Bauch, Tischplatte,...

Ansonsten hab ich Bluetooth früher gelegentlich zum Übertragen von Dateien auf das Handy genutzt und das hat immer absolut problemlos und über überraschend große Distanzen funktioniert.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 27.09.2017 09:30:35

Ok. Scheint also wirklich an der Technik zu liegen...

Vielen Dank für die Auskunft!

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 27.09.2017 09:42:46

Andere Frage...

Wieder einmal das übliche Problem, dass sich alle Anleitungen die man im Netz so findet auf bluez-Versionen VOR 5 beziehen und mit bluez5 total outdated sind...

Ich hab ein Bluetooth-Headset, einen Headless-Media-Rechner (Desktop krieg ich nur, wenn ich mich per x2go verbinde, dann ist es eine minimalistische openbox, ansonsten nur Login per ssh, kein Displaymanager, kein Gnome installiert) und ich würd gern haben, dass sich das Headset automatisch mit dem Rechner verbindet, wenn ich per ssh eingeloggt bin und das Headset einschalte. Pulseaudio wird mit einem ssh-login gestartet!

Das Modul module-bluetooth-discover ist in der PA-Config aktiviert.
Den Workaround mit dem Auskommentieren der beiden Bluetooth-Module und manuellem Nachladen später lässt keine automatische Verbindung zu...


Ich kriegs einfach nicht hin.

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Bluetooth, der ewige Mist

Beitrag von smutbert » 27.09.2017 10:33:38

Das mit dem Pairen und automatischen Verbinden funktioniert bereits nehme ich an?

Ich hab kein Headset oder ähnliches mehr, aber an zwei Kleinigkeiten kann ich mich von Threads im raspberry-Pi-Forum erinnern - zumindest mit einem systemweiten Pulseaudio-Daemon hat es dort funktioniert.
  • ist der Benutzer, der PA ausführt in der Gruppe bluetooth (oder hast du auf anderem Wege dafür gesorgt, dass der per ssh angemeldete Nutzer dieselben Rechte erhält, die ein lokal angemeldeter erhalten würde)?
  • module-bluez5-device darf afaik nicht explizit in der Pulseaudiokonfiguration geladen werden, aber module-bluetooth-discover, module-bluetooth-policy und module-bluez5-discover darf man sehr wohl laden - eventuell überprüfst du auch einfach nur ob diese Pulseaudiomodule alle bereits geladen sind bei dir?

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 27.09.2017 19:55:39

Ich hab mal in der Konfig von Pulse alle bluetoothmodule auskommentiert.

Nach einem Neustart (leider gibts regelmäßig Kernel-Crashes... K. A. warum) hab ich dann die auskommentierten load-module für bluetooth-discover und policy wieder einkommentiert, pulse neu gestartet... Und schon hat sich Headset und Comp automatisch verbunden...

Morgen kann ich testen, ob wieder klappt.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 29.09.2017 08:54:06

Klappt nicht wieder... *hmpf*
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 29.09.2017 10:07:55

smutbert hat geschrieben: ↑ zum Beitrag ↑
27.09.2017 10:33:38
Das mit dem Pairen und automatischen Verbinden funktioniert bereits nehme ich an?

Ich hab kein Headset oder ähnliches mehr, aber an zwei Kleinigkeiten kann ich mich von Threads im raspberry-Pi-Forum erinnern - zumindest mit einem systemweiten Pulseaudio-Daemon hat es dort funktioniert.
  • ist der Benutzer, der PA ausführt in der Gruppe bluetooth (oder hast du auf anderem Wege dafür gesorgt, dass der per ssh angemeldete Nutzer dieselben Rechte erhält, die ein lokal angemeldeter erhalten würde)?
  • module-bluez5-device darf afaik nicht explizit in der Pulseaudiokonfiguration geladen werden, aber module-bluetooth-discover, module-bluetooth-policy und module-bluez5-discover darf man sehr wohl laden - eventuell überprüfst du auch einfach nur ob diese Pulseaudiomodule alle bereits geladen sind bei dir?
Der User ist in der Gruppe bluetooth. Welche anderen Rechte könnten da noch ausschlaggebend sein?

Wenn ich module-bluez5-discover in der default.pa explizit angebe, dann meckert pulseaudio beim restart, dass es nur einmal explizit geladen werden darf...

In der Configuration, in der nicht automatisch connected wird, ist folgender dump:

Code: Alles auswählen

 $ pacmd dump
### Configuration dump generated at Fri Sep 29 09:31:29 2017

load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-augment-properties
load-module module-switch-on-port-available
load-module module-udev-detect
load-module module-bluetooth-policy
load-module module-bluetooth-discover
load-module module-bluez5-discover
load-module module-native-protocol-unix
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-always-sink
load-module module-intended-roles
load-module module-suspend-on-idle
load-module module-console-kit
load-module module-systemd-login
load-module module-position-event-sounds
load-module module-role-cork
load-module module-filter-heuristics
load-module module-filter-apply
load-module module-combine-sink sink_name=combined_sys rate=44100 sink_properties="device.description='System-combined-sink'"
load-module module-bluez5-device path=/org/bluez/hci0/dev_E8_07_BF_01_97_1B
load-module module-cli-protocol-unix

set-sink-volume combined_sys 0x12ab5
set-sink-mute combined_sys no
suspend-sink combined_sys no
set-sink-volume bluez_sink.E8_07_BF_01_97_1B.a2dp_sink 0x10000
set-sink-mute bluez_sink.E8_07_BF_01_97_1B.a2dp_sink no
suspend-sink bluez_sink.E8_07_BF_01_97_1B.a2dp_sink no

set-source-volume combined_sys.monitor 0x10000
set-source-mute combined_sys.monitor no
suspend-source combined_sys.monitor no
set-source-volume bluez_sink.E8_07_BF_01_97_1B.a2dp_sink.monitor 0x10000
set-source-mute bluez_sink.E8_07_BF_01_97_1B.a2dp_sink.monitor no
suspend-source bluez_sink.E8_07_BF_01_97_1B.a2dp_sink.monitor no

set-card-profile bluez_card.E8_07_BF_01_97_1B a2dp_sink

set-default-sink combined_sys
set-default-source bluez_sink.E8_07_BF_01_97_1B.a2dp_sink.monitor

### EOF
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Bluetooth, der ewige Mist

Beitrag von smutbert » 29.09.2017 10:43:11

scientific hat geschrieben: ↑ zum Beitrag ↑
29.09.2017 10:07:55
[…]
Der User ist in der Gruppe bluetooth. Welche anderen Rechte könnten da noch ausschlaggebend sein?

Wenn ich module-bluez5-discover in der default.pa explizit angebe, dann meckert pulseaudio beim […][/code]
Am Raspberry Pi hat die Gruppe bluetooth afair genügt, aber im arch-Wiki ist zusätzlich von der Gruppe lp die Rede.

Entschuldigung, was module-bluez5-discover angeht hatte ich das wohl falsch in Erinnerung - das (einzige) Modul das man unter manchen Umständen manuell/explizit laden muss ist module-bluetooth-discover.
Etwas anderes ist mir auch noch eingefallen...
scientific hat geschrieben: ↑ zum Beitrag ↑
27.09.2017 19:55:39
[…] pulse neu gestartet... Und schon hat sich Headset und Comp automatisch verbunden...
[…]
genau das (ein Neustart von Pulseaudio) ist (ebenfalls im arch-Wiki) als Workaround beschrieben, wenn das mit dem Verbinden nicht funktioniert.

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

Re: Bluetooth, der ewige Mist

Beitrag von debianoli » 29.09.2017 10:49:33

Zwischenfrage: Gibt es einen Bluetooth-Chip (Stick) der immer problemlos funktioniert?

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 29.09.2017 12:02:57

Ich hab mir ein kleines Skript geschrieben, welches mir das Headset mit dem Computer connected:

Code: Alles auswählen

#!/bin/bash

echo -e "connect E8:07:BF:01:97:1B\nquit" | bluetoothctl
Jetzt hab ich probiert und nachdem die beiden Geräte erfolgreich verbunden waren, das Headset einmal ab-, und wieder aufzudrehen. Da hat das automatische Verbinden geklappt.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Bluetooth, der ewige Mist

Beitrag von smutbert » 30.09.2017 23:23:14

debianoli hat geschrieben: ↑ zum Beitrag ↑
29.09.2017 10:49:33
Zwischenfrage: Gibt es einen Bluetooth-Chip (Stick) der immer problemlos funktioniert?
Naja die Bluetooth-Controller sind imho nicht das Problem - da gibt es viele, die funktionieren. Ich habe zB unter anderem einen Stick von Asus, für den ich zwar zuerst eine Zeit lang die passende Firmware suchen müssen habe, der aber ansonsten recht problemlos funktioniert.
Eine konkrete Liste, die auf den Raspberry Pi abzielt, aber das sollte ja egal sein, gibt es zB hier:
https://elinux.org/RPi_USB_Bluetooth_adapters
http://www.wirelesshack.org/top-raspber ... ngles.html

Ein Krampf sind vor allem die GUI-Tools zum Pairing und Verbinden mit Geräten (die in Gnome eingebaute hat in wheezy und jessie meiner Erfahrung nach überhaupt nur sporadisch ein bisschen funktioniert und die Alternative blueman zu dem Zeitpunkt, zu dem ich sie verwenden wollte, überhaupt nicht - bei KDE hat es glaube ich auch nicht viel besser ausgesehen und sonst kenne ich eh nix)
Außerdem ist die Unterstützung von manchen Geräten ziemlich problematisch: Mäuse, Tastaturen und der Dateiaustausch mit Handys klappen meist noch, aber mit Headsets, Bluetooth-Lautsprechern und ich glaube grundsätzlich Bluetooth 4.0/LE (BLE)-Geräten braucht man schon etwas Glück, dass es auf Anhieb (oder überhaupt) funktioniert.


Dazu kommen dann noch viele veraltete Tutorials für alte bluez-Versionen oder aus der Zeit, in der Alsa noch einen Bluetooth-Audiotreiber mitgebracht hat und die nun nicht mehr funktionieren und zu allem Überfluss und um die Verwirrung bei Lautsprechern und Headsets perfekt zu machen, wird wohl in raspbian der alte Alsa-Bluetooth-Audiotreiber wieder reanimiert, keine Ahnung ob dort nun der Pulseaudio-Bluetoothtreiber gestrichen wird oder ob man nun die Wahl und unter Umständen auch Konflikte zwischen den beiden Treibern hat...
Zuletzt geändert von smutbert am 02.10.2017 10:03:26, insgesamt 1-mal geändert.

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

Re: Bluetooth, der ewige Mist

Beitrag von debianoli » 02.10.2017 09:22:23

@smubert

Danke für die Infos!

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Bluetooth, der ewige Mist

Beitrag von scientific » 02.10.2017 09:56:46

Ja diese Massen an veralteten Tutorials machen mich auch ganz wookie...
Bluez glänzt auch herrlich nach unzureichender Doku... die kochen irgendwie ihr Süppchen und lassen einen dumm daneben sterben :-(

Ich persönlich würd mir ja wünschen, den BT-Stack von Android auf Linux portiert zu bekommen... dort funktioniert das alles tadellos...

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

DeletedUserReAsG

Re: Bluetooth, der ewige Mist

Beitrag von DeletedUserReAsG » 02.10.2017 10:48:44

Jacob su hat geschrieben: 3. Porting guide of Bluedroid stack
So how to use Bluedroid in your system? Yeah, I have known Bluedroid is Broadcom’s Bluetooth host stack for android and a much stable one, so what if I wanna porting Bluedroid stack into another system.
There are two parts of this question, or I separated this question into two phases.

1. How to porting the Bluedroid stack into another operating system except android?
2. How to driver another Bluetooth hardware instead of Broadcom’s in Bluedroid?

Question one: The critical part is the btif directory in Bluedroid sources, I have to reimplement the btif part of Bluedroid stack, fortunately, there is already an android implementation in btif, that’s a good reference.
Question two: There is a module named bt_vendor whose responsibility include resetting the communication bus, power management, and configuring firmware. So I need to adjust the bt_vendor module to drive the new hardware.
Das Problem mag sein, dass Android-Apps die BT-Schnittstelle von Android nutzen, während Desktopprogramme das so nicht vorgesehen haben, und möglicherweise angepasst werden müssten

Antworten