Layer 8Ehrlicher Tech-Support

App findet den Thread Border Router nicht: Agent schweigt

Der Border Router läuft, aber keine App findet ihn. Er kündigt sich per Multicast an, und der endet an jeder Netzgrenze.

Aufwand:
ca. 30 Min.

Das Symptom

Der Thread Border Router steht am Netz, die Kontroll-LED ist grün, im Router taucht er mit einer IP-Adresse auf, und anpingen lässt er sich auch. Die Kopplungs-App auf dem Smartphone behauptet trotzdem hartnäckig, es sei kein Thread-Netzwerk vorhanden.

Manchmal geht es am Vortag noch, nach einem Wechsel des WLANs oder dem Einrichten eines IoT-Netzes nicht mehr. Am Border Router selbst wurde dabei nichts angefasst.

Die „Layer 8“-Wahrheit

Ein Border Router wird nicht gefunden, weil jemand seine Adresse kennt, sondern weil er sich meldet. Die Thread-Spezifikation verlangt dafür einen ganz bestimmten Dienst: Border Router veröffentlichen unter dem Namen _meshcop._udp den Thread Border Agent. Das ist die Anlaufstelle, die eine Kopplungs-App sucht. Ohne diese Ankündigung ist der Border Router für die App schlicht nicht existent, ganz gleich wie tadellos er arbeitet.

Diese Ankündigung läuft über Multicast im lokalen Netzsegment. Und Multicast ist genau das, was in modernen Heimnetzen zuerst geopfert wird: Client-Isolation im Gäste-WLAN, ein getrenntes IoT-VLAN, eine Multicast-Filterung im Access Point, ein VPN auf dem Handy. Jede dieser Maßnahmen ist für sich vernünftig, und jede schneidet den Border Agent von seinem Publikum ab.

Der Ping führt dabei zuverlässig in die Irre. Er beweist, dass ein Weg zur Adresse existiert, und sagt nichts darüber aus, ob die Vorstellung des Geräts jemals irgendwo ankommt. Wer an dieser Stelle den Border Router zurücksetzt, setzt das einzige Teil zurück, das funktioniert hat.

Die echte, verifizierte Lösung

1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:

  1. 1.

    Nachsehen, ob der Dienst im eigenen Segment überhaupt auftaucht

    Vom Rechner aus lässt sich direkt danach suchen. Erscheint hier nichts, ist das Problem klar auf der Ankündigungsseite und nicht in der App zu suchen.

    dns-sd -B _meshcop._udp local
    
  2. 2.

    Unter Linux mit den Avahi-Werkzeugen gegenprüfen

    Ein zweites Werkzeug schließt aus, dass nur der eine Client hakt. Die Werkzeuge müssen dafür installiert und der Dienst gestartet sein.

    sudo apt-get install -y avahi-daemon avahi-utils
    sudo service avahi-daemon start
    avahi-browse -r -t _meshcop._udp
    
  3. 3.

    Das Smartphone in dasselbe Netzsegment holen

    Hängt das Handy im Gäste-WLAN, in einem IoT-VLAN oder in einem 5-GHz-Netz mit anderer Segmentierung, sieht es die Ankündigung nicht. Zum Test einmal ins Hauptnetz wechseln und erneut suchen.

  4. 4.

    Client-Isolation und Multicast-Einstellungen prüfen

    Viele Access Points schalten Client-Isolation oder eine Multicast-Filterung ein, um das Funknetz zu entlasten. Beides unterbindet genau die Ankündigung, um die es hier geht, ohne irgendwo eine Fehlermeldung zu erzeugen.

  5. 5.

    VPN auf dem Smartphone abschalten

    Ein aktives VPN leitet den Verkehr des Handys am lokalen Netz vorbei. Die lokale Suche läuft dann ins Leere, obwohl im Heimnetz alles korrekt ist. Für die Dauer der Kopplung abschalten genügt.

Häufige Fragen (FAQ)

?Wie kündigt sich ein Border Router im Heimnetz überhaupt an?

Über einen Dienst mit dem Namen _meshcop._udp. Die Thread-Spezifikation verlangt laut OpenThread-Dokumentation, dass Thread Border Router diesen Dienst für den Thread Border Agent veröffentlichen. Genau danach sucht eine Kopplungs-App. Findet sie ihn nicht, existiert der Border Router aus ihrer Sicht nicht, auch wenn er einwandfrei läuft.

?Ich kann den Border Router anpingen, warum reicht das nicht?

Weil Erreichbarkeit und Auffindbarkeit zwei verschiedene Dinge sind. Der Ping geht an eine bekannte Adresse und wird geroutet. Die Ankündigung des Border Agent läuft dagegen über Multicast im lokalen Segment. Sie überquert keine Netzgrenze, solange niemand sie ausdrücklich weiterleitet.

Belege

Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.

  1. [1]
    OpenThread – mDNS Discovery

    openthread.io · abgerufen am

Zuletzt geprüft am . Dokumentation altert – ein Datum daneben ist der einzige ehrliche Umgang damit.

Verwandte Fehler