Probleme durch nicht randomisierte MAC-Adressen bei mehreren Links am selben Switch

[JensErat]

Betrachtet man bb67516, scheint es ein Problem mit manchen WLAN-Geräten zu geben, wenn die MAC-Adresse geändert wird.

Die Randomisierung ist allerdings notwendig, um die batman-Anforderungen zu erfüllen (wie im Init-Skript ja ohnehin bereits festgestellt wird).

Ich hatte in der Bodensee-Community (Bielefeld ist hier zumindest laut Github das schlussendliche Upstream-Projekt) das Problem, als ich zwei Knoten in Funkreichweite zusätzlich per Netzwerkkabel verbunden hatte (via VLAN und mehrere Switche, aber das sollte nichts an der Sache ändern). Auf einmal sind beide Links als sehr schlechte Verbindung gekennzeichnet gewesen -- einzeln lief alles wunderbar (Ethernet hat TQ 255, WLAN >200, zusammen <30 und WLAN wurde statt Ethernet genutzt).

Ich schlage vor, den Default auf Randomisieren zu setzen, und entweder eine Konfigurationsoption hinzuzufügen ("Randomisierung deaktivieren") oder problematische Geräte zu erkennen (sollte dann besser eine Warnung ausgegeben werden, oder gleich irgendwie sichergestellt werden, dass nur ein Mesh-Gerät existiert?).

Das Problem könnte auch bereits auftreten, wenn WLAN und Uplink-VPN am selben Switch angeschlossen sind und damit die selbe MAC-Adresse (des Switches) haben.

[mwarning]

hi @JensErat, ich muss mal überlegen ob das nicht irgendwie besser geht - ansonsten müssen wir für für manche Geräte umstellen, und sich das merken zu müssen ist nicht schön. :)

[JensErat]

Welche Ralink-Geräte sind denn betroffen? Wie erkennt man diese? Was passiert denn, wenn bei diesen randomisiert wird? Geht es nur um WLAN-Adapter?

Wenn die Rahmenbedingungen klar sind, helfe ich auch gerne mit einem Patch aus, aber bevor man irgend einen Workaround für die betroffenen Geräte strickt, sollte man das Problem verstanden haben... Google und OpenWRT-Bugtracker haben mir leider auch nicht geholfen, das Problem zu verstehen.

Ich denke, die einzig saubere Lösung wäre eine Blackliste von nicht zu randomisierenden Geräten in der /etc/init.d/freifunk. In der Hoffnung, dass betroffenen Routern denen die anderen Netzwerkkomponenten vernünftig unterstützt sind (wenn nur ein Interface nicht randomisiert wird, ist das ja nicht tragisch).

[mwarning]

Das Problem ist ein WLAN-Treiberproblem (welche das sind wüßte ich nicht genau). Das Problem ist das die Adapter dann nicht hochkommen wenn ich mich recht erinnere.

[JensErat]

Wenn ich wüsste was für ein Router betroffen ist, würde ich einen organisieren und einfach ausprobieren was geht und was nicht. Vielleicht gibt es passende Chips sogar als USB-Adapter, da geht das neu starten des Adapters schneller...

Wenn nur WLAN-Adapter betroffen sind, wäre eine Zwischenlösung nur WLAN-Geräte nicht zu randomisieren. Dann deckt man wenigstens VPN und Ethernet als andere Mesh-Interfaces mit ab, auch wenn mehrere WLAN-Interfaces noch problematisch sein könnten.

[mwarning]

@JensErat die MAC sollte eigentlich so bereits jednefalls pro Gerät eindeutig sein (die des WLAN Modules). Ich hatte das zwischenzeitlich gesetzt, damit jedes interface auf dem Router eine eindeutige MAC hat (ist nicht notwendig schlimm) und um nicht die MAC der Hardware zu nehmen (ein wenig verbesserte Anoynmisierung..). Konntest du das Problem überhaupt mit dem aktivieren der randomisierten MAC lösen?

[JensErat]

Batman benötigt eindeutige Interface-Adressen auf jedem Link, weil es für die Routenbestimmung zum jeweils nächsten Gerät die MAC-Adresse verwendet. Zumindest manche TP-Link-Router unter OpenWRT/Freifunk-Firmware nutzen jedoch die selbe MAC-Adresse für verschiedene Interfaces -- was an sich auch nicht sein dürfte.

DIe Konsequenz daraus ist, dass Batman mehrere Links zwischen den selben Geräten (mit eben der selben MAC-Adresse) als Äquivalent ansieht: dadurch schwankt die LInk-Qualität ständig zwischen den beiden Links. Im Falle einer stabilen Ethernet-Verbindung und einer wackeligen WLAN-Verbindung kann das extreme Schwankungen ergeben: Der Ethernet-Link hätte eigentlich einen Qualitätswert von 255, die WLAN-Verbindung kommt kaum über die 20 hinaus... Egal welcher Wert der Link jedoch hatte, wird ein nicht definierter gewählt, bei mir war es grundsätzlich der schlechte WLAN-Link.

Das setzen verschiedener Mac-Adresse (eine je Batman-interface) hat das Problem gelöst. Seitdem wird zuverlässig das Netzwerkkabel genutzt. Im Graph-Viewer wird immer noch zufällig einer der beiden LInks "oben" angezeigt, hier ist immer noch ein Problem in der Darstellung, aber der Traffic läuft stabilg, schnell und zuverlässig.

Um die Batman-API zu erfüllen, muss jedes an Batman durchgereichte Interface eine eindeutige Mac-Adresse haben. Ob man nun alle randomisiert, oder spezifisch abprüft ob Duplikate bei Batman-aktivierten Interfaces existieren, sei dahingestellt (vielleicht auch besser, wenn man die Randomisierung als "Nothammer" betrachtet, wenn der Hardware-Hersteller nicht-eindeutige MAC-Adressen verwendet). Aber für stabilen Betrieb bei größeren Anlagen mit Kabel-Mesh muss definitiv eine Lösung gefunden werden.

Wenn man sich einigt wie eine gute Lösung aussieht, nehme ich mich dem Projekt auch gerne an und steuere ich auch gerne einen Patch bei.

Ich sehe als mögliche Lösungen:

• Einfach alles randomisieren, das nicht von Ralink ist (oder sonst wie auf einer Sperrliste steht) -- einfachste Lösung
• Manuelles Mac-Adressen-setzen ermöglichen pro Interface, halte ich aber nicht für eine gute Lösung, das sollten wir irgendwie automatisch abdecken
• Alles randomisieren und statt Sperrliste manuelles deaktiveren ermöglichen -- finde ich auch nicht gut
• Nur randomisieren wenn die MAC-Adresse bereits einem anderen Batman-Interface zugewiesen ist (Implementierung vermutlich einfach, schlicht eine Liste von Interfaces vorhalten und abprüfen, ob das neu zu prüfende Interface bereits enthalten ist). Einfache und vermutlcih sauberere Lösung als den Vorschlaghammer anzuwenden. Eventuell sogar Interface-Name+Mac-Adresse als Seed verwenden, dann hat man sogar reproduzierbare und damit "statische" Adressen. Sperrliste bräuchte man trotzdem. Und was macht man im Falle einer Kollision und Sperrlisteneintrags? Der Code wird deutlich komplexer.

[mwarning]

Hi @JensErat, danke für die Geduld bei meinen Antworten, ich hatte gerade viel an der Karte und Frmware gebastelt. Eine favorisierte Lösung hätte ich persönlich z.Z. nicht. Kannst du mir vielleicht sagen wie ich das Problem reproduzieren könnte. Dann könnte ich mir das Problem näher anschauen.

[JensErat]

Ich denke, zwei Router, die jeweils die selbe MAC-Adresse für alle Interfaces konfiguriert haben sollten reichen. Router 1 (war hier ein TP-841n v10) hat Uplink, Ethernet-Mesh und WLAN-Mesh, Router 2 (bei mir ein TP-1043nd) hat nur Ethernet-Mesh und WLAN-Mesh.

In meinem Falle haben sich die Router per WLAN nur noch gerade so gesehen (recht schlechte Verbindung), per Kabel gab es eine einwandfreie Verbindung.

Effekt: Datentransfer per schlechter WLAN-Verbindung statt stabilem Ethernet (zu beobachten mit ifconfig), Link-Qualität lag andauernd bei etwa 20 für beide Interfaces (nachdem die MAC-Adressen unterschiedlich waren, ist Ethernet auf 255 gegangen, WLAN sogar auch auf um die 100).

Ob die Reihenfolge der Netzwerke in der Initialisierung eine Rolle spielt, weiß ich nicht.