RFCOMM TTY kann nicht erstellt werden: Adresse wird bereits verwendet

8

Ich höre auf meinem Server nach einer Bluetooth-Verbindung:

%Vor%

Dann verbinde ich mich mit meinem Bluetooth-Client und diese Nachricht erscheint:

%Vor%

Das bedeutet, dass alles in Ordnung ist ...

Dann beende ich meine Verbindung mit Strg + C auf dem Server oder im Client.

Danach mache ich nochmal:

%Vor%

Aber dieses Mal, wenn ich den Client verbinde, erhalte ich folgende Nachricht:

%Vor%

Also gehe ich und überprüfe, welche Verbindungen offen sind:

%Vor%

Und ich kann sehen, dass die Verbindung als geschlossen erscheint, aber nicht einmal getrennt angezeigt werden sollte ...

%Vor%

Das Seltsamste ist, dass manchmal die Trennung erfolgreich ist und ich mich ohne Probleme wieder verbinden kann.

  

BEARBEITEN

Ich habe festgestellt, dass die Verbindung erfolgreich ist, wenn das Gerät etwa 10 Sekunden oder länger verbunden bleibt. Aber wenn diese Zeit kürzer ist (schnelle Verbindung / Trennung), tritt das Problem auf.

Und wenn der Fehler auftritt, tue ich:

%Vor%

Dies ist gedruckt:

%Vor%

Wenn alles in Ordnung ist (10 oder mehr Sekunden), werden nur diese Nachrichten angezeigt:

%Vor%     
Sergio 13.10.2017, 18:27
quelle

3 Antworten

3
  

LÖSUNG

Das Problem war ein Paket, das in Ubuntu installiert wird und die normale Version des Geräts stört.

Tu es einfach:

%Vor%     
Sergio 24.10.2017, 16:39
quelle
4

Haben Sie versucht, Release zu verwenden?

  

sudo rfcomm release 0

Alternativ können Sie Ihr Gerät auch direkt zu /etc/bluetooth/rfcomm hinzufügen und dann stattdessen binden und dann die Veröffentlichung versuchen, nachdem Sie fertig sind.

  

sudo rfcomm bind 0

    
Adam 19.10.2017 09:54
quelle
4

Da es kein Problem gibt, wenn Sie 10 Sekunden warten, bevor Sie die Verbindung trennen, haben wir einen soliden Vorsprung: Die RFCOMM-Spezifikation ( Ссылка ) definiert 10 Sekunden als minimalen Timeout für Daten-ACKs (" Bestätigungstimer (T1) ") und Steuerkanalantworten (" Antworttimer für Multiplexer-Steuerkanal (T2) "). Höchstwahrscheinlich haben Sie von Ihrem Client aus Daten auf dem Kontrollkanal nicht bestätigt (klingt nicht so, als hätten Sie Daten gesendet). Obwohl ich nicht erwarten würde, dass dies beim Trennen zu Problemen führt, ist es wahrscheinlich, dass ein Problem innerhalb des BlueZ-Stacks Probleme verursacht, wenn Sie versuchen, das TTY freizugeben, während es auf diesen ACK wartet.

  1. Haben Sie versucht, Daten auf dem Kanal zu senden? Wenn der Kontrollkanal wirklich unakkodiert wird, wäre es überraschend, wenn Sie Daten austauschen könnten.

  2. Haben Sie versucht, ein anderes Gerät als RFCOMM-Client zu verwenden? Vielleicht ist ein Problem im Stapel auf der Client-Seite nicht ACKing Steuersignale.

Ich habe nicht viel mit dem BlueZ-Stack gearbeitet, daher kann ich keine genauen Code-Änderungen angeben, aber hoffentlich sind das genug Informationen, um einen Workaround zu formulieren (zB wenn Sie den Timer, der darauf wartet, aufspüren können) ACK, vielleicht könntest du es töten).

    
Jacob Torres 22.10.2017 12:39
quelle

Tags und Links