bluetoothd (BlueZ 5) nie łączy się z żadnym urządzeniem

ROZWIĄZANY. Edytowane: patrz poniżej.

Wydaje mi się, że wystarczająco długo przeszukiwałem Internet w celu znalezienia tego problemu. Pytanie było zadawane wiele razy, ale żadne z rozwiązań nie działa dla mnie. Uaktualniłem do BlueZ 5, ponieważ chcę w końcu móc korzystać z jego możliwości oszczędzania energii. Jednak w tej chwili nie mogę nawet sparować urządzeń. Nie mogę użyć GUI, ponieważ ostatecznie będzie to dla wbudowanego systemu Linux. Dlatego myślę, że nie mogę również korzystać z bluetoothctl, ponieważ wymaga to interaktywnej sesji. (Mogę się mylić.) Chcę więc, aby wszystko odbywało się przez BASH, C lub python, w tej kolejności. Ponadto, ponieważ musi zostać zautomatyzowany, parowanie i połączenie będzie musiało zostać zainicjowane z urządzenia Bluetooth, a nie z systemu Linux. Na koniec wszystkie urządzenia muszą korzystać z profilu a2dp.

Wydaje się, że istnieje wiele podejść, ale nie jestem pewien, gdzie kończy się jedno, a drugie zaczyna:

PODEJŚCIE 1:

a) # $ sudo bluetoothd -d -n uruchamia bluetoothd w trybie pełnym

b) # $ hciconfig hci1 upwłącza urządzenie

$ hciconfig -a # zobacz właściwości urządzenia

    Type: BR/EDR  Bus: USB
    BD Address: 00:02:72:C5:D8:E0  ACL MTU: 1021:8  SCO MTU: 64:1
    UP RUNNING PSCAN ISCAN 
    RX bytes:32875 acl:761 sco:0 events:1037 errors:0
    TX bytes:20178 acl:780 sco:0 commands:329 errors:0
    Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
    Link policy: RSWITCH SNIFF 
    Link mode: SLAVE ACCEPT 
    Name: 'Adapter-1'
    Class: 0x00010c
    Service Classes: Unspecified
    Device Class: Computer, Laptop
    HCI Version: 4.0 (0x6)  Revision: 0x1000
    LMP Version: 4.0 (0x6)  Subversion: 0x220e
    Manufacturer: Broadcom Corporation (15)

c) spróbuj sparować z urządzeniem.

Wynik: z bluetoothd:

bluetoothd[5359]: src/adapter.c:connected_callback() hci1 device 70:72:3C:62:49:7F connected eir_len 15
bluetoothd[5359]: src/adapter.c:user_confirm_request_callback() hci1 70:72:3C:62:49:7F confirm_hint 1
bluetoothd[5359]: src/device.c:new_auth() Requesting agent authentication for 70:72:3C:62:49:7F
** bluetoothd[5359]: No agent available for request type 2
** bluetoothd[5359]: device_confirm_passkey: Operation not permitted 
bluetoothd[5359]: src/adapter.c:btd_adapter_confirm_reply() hci1 addr 70:72:3C:62:49:7F success 0
bluetoothd[5359]: src/adapter.c:bonding_attempt_complete() hci1 bdaddr 70:72:3C:62:49:7F type 0 status 0x5
bluetoothd[5359]: src/device.c:device_bonding_complete() bonding (nil) status 0x05
bluetoothd[5359]: src/device.c:device_bonding_failed() status 5
bluetoothd[5359]: src/adapter.c:resume_discovery() 
bluetoothd[5359]: src/adapter.c:dev_disconnected() Device 70:72:3C:62:49:7F disconnected, reason 3
bluetoothd[5359]: src/adapter.c:adapter_remove_connection() 
bluetoothd[5359]: src/adapter.c:bonding_attempt_complete() hci1 bdaddr 70:72:3C:62:49:7F type 0 status 0xe
bluetoothd[5359]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
bluetoothd[5359]: src/device.c:device_bonding_failed() status 14
bluetoothd[5359]: src/adapter.c:resume_discovery()

Urządzenie twierdzi, że nie można sparować z adapterem-1 z powodu nieprawidłowego kodu PIN lub klucza dostępu.

W oparciu o powyższe odpowiedzi oznaczone gwiazdkami sprawdziłem, dlaczego nie było agenta. Co to za agent? Kto wie, ale wywnioskowałem, że był to pośrednik między moim urządzeniem a demonem bluetooth.

d) $ ../bluey-5.15/test/simple-agent # Próbowałem także używać sudo z tymi poleceniami

lub $ ../bluey-5.15/test/simple-agent hci1

To jest skrypt Pythona, który obsługuje przychodzące żądania parowania. Jeśli się powiedzie, próbuje także „zaufać” i „połączyć”

wynik: Agent registered

e) następnie próbuję ponownie sparować z urządzeniem.

wyjście prostego agenta:

RequestConfirmation (/org/bluez/hci1/dev_70_72_3C_62_49_7F, 110643)
Confirm passkey (yes/no): yes 

Uderzyłem parę na urządzeniu BT i napisano, że jest sparowany, ale prosty agent zawiesza się. Użyłem BlueZ 4 i jestem pewien, że powinien powiedzieć coś w stylu „Nowe urządzenie XX_XX_XX_XX_XX_XX”

wyjście bluetoothd:

** bluetoothd[5359]: src/agent.c:set_default_agent() Default agent set to :1.126 /test/agent
bluetoothd[5359]: src/adapter.c:connected_callback() hci1 device 70:72:3C:62:49:7F connected eir_len 15
bluetoothd[5359]: src/adapter.c:user_confirm_request_callback() hci1 70:72:3C:62:49:7F confirm_hint 0
bluetoothd[5359]: src/device.c:new_auth() Requesting agent authentication for 70:72:3C:62:49:7F
bluetoothd[5359]: src/agent.c:agent_ref() 0xa59290: ref=2
bluetoothd[5359]: src/agent.c:agent_request_confirmation() Calling Agent.RequestConfirmation: name=:1.126, path=/test/agent, passkey=110643
bluetoothd[5359]: src/agent.c:agent_ref() 0xa59290: ref=3
bluetoothd[5359]: src/adapter.c:btd_adapter_confirm_reply() hci1 addr 70:72:3C:62:49:7F success 1
bluetoothd[5359]: src/agent.c:agent_unref() 0xa59290: ref=2
bluetoothd[5359]: src/agent.c:agent_unref() 0xa59290: ref=1
bluetoothd[5359]: src/adapter.c:new_link_key_callback() hci1 new key for 70:72:3C:62:49:7F type 5 pin_len 0
bluetoothd[5359]: src/device.c:device_set_bonded() 
bluetoothd[5359]: src/device.c:device_bonding_complete() bonding (nil) status 0x00
bluetoothd[5359]: src/adapter.c:resume_discovery() 
bluetoothd[5359]: src/adapter.c:dev_disconnected() Device 70:72:3C:62:49:7F disconnected, reason 3
bluetoothd[5359]: src/adapter.c:adapter_remove_connection() 
bluetoothd[5359]: src/adapter.c:bonding_attempt_complete() hci1 bdaddr 70:72:3C:62:49:7F type 0 status 0xe
bluetoothd[5359]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
bluetoothd[5359]: src/device.c:device_bonding_failed() status 14
bluetoothd[5359]: src/adapter.c:resume_discovery()

To coś robi.

moc wyjściowa:

$ hcidump -i hci1

HCI sniffer - Bluetooth packet analyzer ver 5.15
device: hci1 snap_len: 1500 filter: 0xffffffffffffffff
> HCI Event: Connect Request (0x04) plen 10
    bdaddr 70:72:3C:62:49:7F class 0x5a020c type ACL
> HCI Event: Command Status (0x0f) plen 4
    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 11 bdaddr 70:72:3C:62:49:7F type ACL encrypt 0x00
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 11
    Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Command Complete (0x0e) plen 10
    IO Capability Request Reply (0x01|0x002b) ncmd 1
    status 0x00 bdaddr 70:72:3C:62:49:7F
> HCI Event: Read Remote Extended Features (0x23) plen 13
    status 0x00 handle 11 page 1 max 1
    Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 70:72:3C:62:49:7F name 'Prism II'
> HCI Event: Command Complete (0x0e) plen 10
    User Confirmation Request Reply (0x01|0x002c) ncmd 1
    status 0x00 bdaddr 70:72:3C:62:49:7F
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 11 reason 0x13
    Reason: Remote User Terminated Connection

Próbowałem nawet bluetoothctl, ale ma takie same wyniki. Zabawne jest to, że niektóre skrypty z BlueZ (jak test-device) mogą widzieć urządzenie BT dla niektórych poleceń, ale nie dla innych. Na przykład urządzenie testowe „zaufa” urządzeniu, ale kiedy próbuję je „usunąć”, nie istnieje.

PODEJŚCIE 2:

DBUS bezpośrednio za pomocą komend dbus-send --system. Nie sądzę, żeby którekolwiek z tych poleceń przyniosło mi jakieś korzyści, dopóki nie będę mógł sparować i podłączyć urządzenia.

PODEJŚCIE 3:

Próbowałem wszystkich sugestii w tym poście . W BlueZ 5. nie ma pliku /etc/bluetooth/hcid.conf. Czy muszę go utworzyć? Polecenie rfcomm połączy się, ale zaraz potem rozłączy.

$ sudo rfcomm connect /dev/rfcomm0 70:72:3C:62:49:7F 1
Connected /dev/rfcomm0 to 70:72:3C:62:49:7F on channel 1
Press CTRL-C for hangup
Disconnected

wyjście bluetoothd:

bluetoothd[5359]: src/adapter.c:connected_callback() hci1 device 70:72:3C:62:49:7F connected eir_len 10
bluetoothd[5359]: src/adapter.c:dev_disconnected() Device 70:72:3C:62:49:7F disconnected, reason 3
bluetoothd[5359]: src/adapter.c:adapter_remove_connection() 
bluetoothd[5359]: src/adapter.c:bonding_attempt_complete() hci1 bdaddr 70:72:3C:62:49:7F type 0 status 0xe
bluetoothd[5359]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
bluetoothd[5359]: src/device.c:device_bonding_failed() status 14
bluetoothd[5359]: src/adapter.c:resume_discovery()

moc wyjściowa:

$ hcidump -i hci1
HCI sniffer - Bluetooth packet analyzer ver 5.15
device: hci1 snap_len: 1500 filter: 0xffffffffffffffff
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 11 bdaddr 70:72:3C:62:49:7F type ACL encrypt 0x00
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 11
    Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Read Remote Extended Features (0x23) plen 13
    status 0x00 handle 11 page 1 max 1
    Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 70:72:3C:62:49:7F name 'Prism II'
> HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Reply (0x01|0x000b) ncmd 1
    status 0x00 bdaddr 70:72:3C:62:49:7F
> HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 11
> HCI Event: Command Status (0x0f) plen 4
    Set Connection Encryption (0x01|0x0013) status 0x00 ncmd 1
> HCI Event: Encrypt Change (0x08) plen 4
    status 0x00 handle 11 encrypt 0x01
> HCI Event: Command Status (0x0f) plen 4
    Exit Sniff Mode (0x02|0x0004) status 0x0c ncmd 1
    Error: Command Disallowed
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 11 reason 0x13
    Reason: Remote User Terminated Connection

Jakieś sugestie? Jestem:

• Zapomniałeś czegoś naprawdę oczywistego?

• Używasz narzędzi nieprawidłowo?

• Zapomniałeś ustawić plik konfiguracyjny?

Edytować:

Ponieważ bluez simple-agent nie dawał mi żadnych przydatnych błędów, napisałem własnego agenta parowania. Kiedy to zrobiłem, byłem w stanie sparować, ale nie mogłem się połączyć. bluetoothd dał mi ten nowy błąd:

bluetoothd[3078]: profiles/audio/a2dp.c:a2dp_source_connect() path /org/bluez/hci0/dev_70_72_3C_62_49_7F
bluetoothd[3078]: a2dp-source profile connect failed for 70:72:3C:62:49:7F: Protocol not available

Ten post wskazał, że być może mój LOKALNY adapter bluetooth nie obsługiwał profilu a2dp mojego źródła audio. (Nie zachowując się jak zlew) Potem zobaczyłem, że wiele osób przechodziło z BlueZ4 do BlueZ5. Problem został również opublikowany na liście mailingowej BlueZ .

Jak dotąd nie znalazłem sposobu na dodanie tego protokołu do mojego adaptera.

Rozwiązanie:

Po stwierdzeniu, że profil (a2dp) nie był połączony i stwierdzeniu, że inni mają ten sam problem, sprawdziłem, czy profil ten został jeszcze zaimplementowany w BlueZ5. Chyba nie przeczytałem wystarczająco dokładnie przewodnika po portowaniu, ponieważ wyjaśnia, że a2dp został przeniesiony ze stosu BlueZ do GStreamera. Nigdy nie słyszałem o GStreamerze, ale z tego postu widziałem również, że PulseAudio i JACK również zaimplementują ten profil. Próbowałem PulseAudio, ale nie załadowałoby to odpowiednich UUID dla adaptera. W końcu znalazłem post na wiki ArchLinux. Musiałem być na tej stronie milion razy, ale prawdopodobnie wtedy jeszcze korzystałem z BlueZ4.

Najważniejsze:

-pobierz nowy kod źródłowy PulseAudio 5, który obsługuje BlueZ5, i skompiluj go. (To nie jest najnowsza wersja w apt repozytoriach.)

-kompilacja wymagała wielu zależności (JSON, libsndfile, libcap itp.)

-pamiętaj, że ścieżka do PA5 to / usr / local not / usr / (Jest to ważne, ponieważ musiałem umieścić ją w $ LD_LIBRARY_PATH, aby PA mógł znaleźć libpulsecore-5.0 przy uruchomieniu)

- jak głosi wiki ArchLinux, zabij serwer pulseaudio, który jest uruchamiany podczas uruchamiania i uruchom nowy. Nie ładuje profili podczas uruchamiania. Upewnij się także, że demon się odradza. (Ustaw w /usr/local//etc/pulse/client.conf)

Następnie działają zwykłe polecenia pactl. Udało mi się zdobyć źródło BT2dp (tj. IPod), aby przesyłać strumieniowo do PA5, a następnie, korzystając z modułu pętli zwrotnej, przesyłać strumieniowo do zlewu BT2dp!

Nie mogłem go uruchomić z ALSA, ale gdzieś przeczytałem, że BlueZ5 może już nie obsługiwać wtyczek pcm ALSA.

Kluczem do powyższego problemu jest zdanie: „Po zakończeniu wykrywania urządzenia, które nie zostaną podłączone ani sparowane, zostaną automatycznie usunięte przez bluetoothd w ciągu trzech minut”.

Przeczytaj sekcję Wykrywanie urządzeń z http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/

Miałem podobny problem, ale sparowałem go i połączyłem. Aby sparować i podłączyć urządzenie, należy je wykryć w ciągu ostatnich 3 minut. Zarówno prosty agent, jak i bluetoothctl działają dobrze.