Eindeutige MAC-Adressen mit Batman

[Adrian Schmutzler]

Hallo zusammen,

da ich schon seit einiger Zeit von den folgenden Meldungen geplagt werde, bin ich der Sache heute mal auf den Grund gegangen:

Sat Oct 17 00:34:47 2020 kern.warn kernel: [2453354.532752] br-mesh: received packet on bat0 with own address as source address (addr:xxxxx, vlan:0)

Allgemein bekannt ist, dass die "mesh"-Interfaces, also typischerweise eth0.3, w2mesh und w5mesh unterschiedliche MAC-Adressen haben müssen.

Darüber hinaus habe ich jedoch festgestellt, dass die MAC-Adresse für "ethmesh", also z.B. eth0.3, auch von den Client-Interfaces (w2ap, w5ap) verschieden sein muss. Nur dann verschwindet die obige Meldung.

Dies stellt in der Praxis ein Problem dar. Bei den TP-Link-Geräten ist typischerweise die MAC-Adresse für das Ethernet-LAN und eines der WLAN-Interfaces gleich. Im normalen Betrieb (Standard-OpenWrt) stellt das kein Problem dar, auch wenn diese effektiv im "LAN" zusammengefasst sind (z.B. eth0.1, wlan0, wlan1).
Bei unserer FW sind pro radio (z.B. 2.4 GHz) jeweils wXmesh und wXap vorhanden, wobei jeweils wXmesh die "echte" MAC-Adresse erhält und wXap die mit Local-Bit. Wird nun für LAN dieselbe "echte" MAC-Adresse verwendet, kann man eine Kollision nicht vermeiden, da sowohl echte Adresse als auch die mit Local-Bit bereits vergeben sind (und entsprechend meiner Erkenntnis von oben reicht es nicht aus, für die ethmesh-Adresse das localbit zu setzen, sodass sie nur nicht mit wXmesh kollidiert). Die typische Lösung für diesen Fall war bisher, die häufig separate "echte" MAC-Adresse des WAN-Interfaces zu verwenden.

Dies ist jedoch nicht immer möglich: Z.B. der GL-AR150 hat nur eine "echte" MAC-Adresse, man bräuchte aber drei eindeutige Adressen für ethmesh, wXap und wXmesh.

Hier stellt sich also nun die Frage, wie man dieses Problem lösen kann. Abgesehen davon, dass der "Missbrauch" der WAN-Adresse nicht unbedingt erstrebenswert ist und nicht immer möglich ist, stellt sich mir auch die Frage, ob das beschriebene Verhalten überhaupt "korrekt" ist oder einen Bug darstellt: Ist eine Überlappung von ethmesh und wXap wirklich ein Problem? Und wieso tritt dasselbe Problem _nicht_ bei einer Adress-Überlappung von client ethernet (eth0.1) und wXmesh auf? Oder ist das Ganze evtl. nur ein Firewall-Problem?

Für Ideen, Vorschläge und/oder Diskussionsbeiträge wäre ich dankbar.

Beste Grüße

Adrian
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : openpgp-digital-signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20201017/7692cad9/attachment.sig>