VLAN 1298 gibt es nicht

Es fing an wie diese Dinge immer anfangen: mit einem „war das gerade..?".

Seit Wochen zuckte das Netzwerk gelegentlich. Nichts Dramatisches. Eine Webseite, die eine halbe Sekunde zu lange überlegt. Ein Ping, der einmal aus der Reihe tanzt. Kurz genug, um es sofort wieder zu vergessen, und selten genug, um sich einzureden, man habe es sich eingebildet. Man kennt das. Man legt es auf den mentalen Stapel „irgendwann mal gucken" und macht weiter.

Der Stapel wurde in den letzten Tagen unangenehm konkret. Denn das kurze Zucken hat ein untrügliches Talent dafür entwickelt, ausgerechnet mitten im Call aufzutreten. Genau in dem Moment, in dem man einen Satz sagt, den man nicht wiederholen möchte, wird man zum Standbild mit offenem Mund. Zweimal ist Zufall. Beim dritten Mal an einem Abend beschließt man, dass jetzt Schluss ist.

Also: keine Theorie mehr, kein Raten. Einfach mal draufhalten und hingucken.

Draufhalten

Die schönste Eigenschaft von tcpdump ist, dass es einem nichts vormacht. Es zeigt, was da ist — nicht, was da sein sollte. Der naive Einstieg, quer über alle Interfaces, meine eigene SSH-Session rausgefiltert, damit ich mir nicht selbst beim Tippen zusehe:

tcpdump -vvvv -en -i any port not 22

Und das Erste, was mir entgegenspringt, ist… Unsinn:

switch0 Out ... ethertype 802.1Q (0x8100), length 188: vlan 1298, p 2,
  ethertype Unknown, LLC, dsap Unknown (0x3e) ...

VLAN 1298. Priorität 2. Ich habe kein VLAN 1298. Niemand hat ein VLAN 1298. Das ist keine Zahl, die ein Mensch je in ein Formular tippt. Und trotzdem steht da eins, mit einem LLC-Frame, das mein Sniffer nicht sauber parsen kann („dsap Unknown"). Kurzer Adrenalinstoß: Läuft da irgendein fremdes Getagge über meine Leitung?

Nein. Läuft nicht. Und hier wird's schön nerdig.

Wenn man den Hex-Dump von Hand entblättert, findet man mittendrin einen völlig gesunden IP-Header: 10.0.2.1 → 10.0.2.76, TTL 64, TCP, Port 22. Das ist SSH. Verschlüsselte Nutzlast, deshalb sah der Rest so schön nach Kraut und Rüben aus.

Zwei Dinge waren zusammengekommen. Erstens hatte ich auf switch0 mitgeschnitten — dem internen Interface zum Switch-Chip der UDM. Frames zwischen CPU und ASIC tragen ein proprietäres Hardware-Tag (DSA/CPU-Tag), das libpcap schlicht nicht kennt. Die Tag-Bytes landen genau dort, wo tcpdump eine Ethertype erwartet, ergeben zufällig 0x8100, und schon „erfindet" der Parser ein 802.1Q-VLAN mit der Nummer 1298. Es ist keine echte VLAN-ID. Es ist ein Hardware-Tag, das als VLAN verkleidet aus der Wäsche kommt.

Zweitens — und das ist die kleine Pointe — genau deshalb ist es überhaupt durch meinen Filter gerutscht. Ich hatte port not 22 gesagt, um mein eigenes SSH auszublenden. Aber der BPF-Filter konnte das Paket nicht als TCP/22 erkennen, weil es für ihn ein kaputtes LLC-Frame war. Kein erkennbarer Port → port matcht nicht → not 22 ist wahr → willkommen im Output. Der Filter hat nicht versagt. Er hat nur brav das ausgeblendet, was er verstanden hat.

Lektion, die ich eigentlich kenne und trotzdem jedes Mal aufs Neue lerne: Schnüffel nicht auf switch0, und schon gar nicht auf -i any, wenn du echten Verkehr sehen willst.

Auf die richtige Leitung wechseln

Also runter von der internen Gespenster-Schnittstelle und dahin, wo die Frames sauber sind:

tcpdump -vvvv -en -i br0 port not 22

Sofort besser. link-type EN10MB, alles parst, der Filter greift. Und jetzt zeigt sich das eigentliche Bild — und das meiste davon ist einfach das Grundrauschen einer UniFi-Welt, die vor sich hin lebt: APs, die per /inform beim Controller Bericht erstatten, UBNT-Discovery, RSTP-BPDUs (Root stabil, kein Topology-Change — gut), ein bisschen ARP und IPv6 Neighbor Discovery. Das Übliche. Nichts, worüber man abends nachdenken möchte.

Bis auf eine Sache.

Zwischen dem ganzen Housekeeping tickerte, im Sekundentakt, ein Strom von mDNS-Paketen durch — Port 5353, brav von meinem Gateway reflektiert. HomeKit-Zeug (_hap._tcp), ein Homey-Hub, der sich charmanterweise „HomeKitty" nennt, und meine tado Internet Bridge. Und dann fiel der Groschen, als ich die Namen untereinander sah:

tadoBridgeIB1268123648-92 → -93 → -94 → -95 → -96 ...
tado Internet Bridge IB1268123648-08 → -09 → -10 → -11 → -12 ...

Die Bridge hörte nicht auf, sich umzubenennen. Immer weiter. Immer eins höher. Jede Sekunde eine neue Runde.

Das ist die klassische Signatur eines mDNS-Namenskonflikts. Ein gesunder Responder sucht sich einen Namen und behält ihn. Meiner probte einen Namen, hörte seinen eigenen — reflektierten — Announce zurück, hielt das für einen fremden Beanspruchen desselben Namens, benannte sich pflichtbewusst um, probte den neuen Namen, hörte den zurück, benannte sich wieder um… und so weiter, bis in alle Ewigkeit. Eine Katze, die sich im Spiegel sieht und beschließt, dass da eine zweite Katze ist, gegen die man dringend etwas unternehmen muss.

Schuld war mein eigener Komfort: der mDNS-Proxy im Gateway, damit HomeKit-Geräte über VLAN-Grenzen hinweg gefunden werden. Der spiegelte munter zurück in dieselbe Broadcast-Domain, aus der er kam. Und weil Multicast über WLAN mit der niedrigsten Basisrate rausgeht und von jedem Client im Segment verarbeitet werden muss, frisst so ein Dauer-Loop genau die Airtime, die einem dann im Call fehlt. Das kurze Zucken hatte einen Namen. Und der Name zählte hoch.

Der Handgriff

Kein episches Refactoring, keine Firmware-Odyssee. Ich habe schlicht das betroffene VLAN aus dem Gateway-mDNS-Proxy herausgenommen. Ein Häkchen weniger.

Dann, weil man nichts glaubt, was man nicht gesehen hat, noch ein Mitschnitt. Und der war still. Kein einziges 5353-Paket mehr. Kein Hochzählen. Kein _hap._tcp im Kreis. Nur noch das gewohnte, gesunde Rauschen — inform, Discovery, ein bisschen STUN, RSTP im Takt.

(Ein letztes Nerd-Bonbon am Rande: In dem Dump tauchten bei den ausgehenden Paketen der UDM lauter cksum incorrect-Meldungen auf. Kurzes Stirnrunzeln — bis man sich erinnert: TX Checksum Offload. Die NIC berechnet die Prüfsumme erst nach dem Sniffer. Auf der Sendeseite ist „falsch" hier völlig richtig.)

Was hängen bleibt

Das eigentlich Interessante an diesem Abend war nicht der Fix. Der war ein Häkchen. Interessant war der Weg dahin — und dass die erste, alarmierendste Spur (ein VLAN, das es nicht gibt!) eine komplette Sackgasse war, geboren aus dem falschen Interface. Man sucht einen Eindringling und findet einen Parser-Artefakt. Man sucht ein Routing-Drama und findet ein Thermostat mit Identitätskrise.

tcpdump erzählt einem keine Geschichten. Aber man muss ihm an der richtigen Stelle zuhören — sonst erzählt einem der Switch-Chip Märchen von VLAN 1298.

Ich beobachte jetzt ein paar Tage, ob die Zuckungen wirklich weg sind. Aber der nächste Call kommt bestimmt, und diesmal freue ich mich fast darauf, ganz normal Standbild-frei einen Satz zu Ende zu sagen.