Eindeutige MAC-Adressen mit Batman

[Adrian Schmutzler]

Hallo,

zum Abschluss dieses Threads:

Ich habe bei batman-adv direkt nachgefragt, siehe hier:

https://www.open-mesh.org/issues/421

Die Antwort war im Wesentlichen, dass batman für die BLA Pakete immer die MAC-Adresse des _primary_ Mesh Interfaces nimmt; ich habe aber kaum/keinen Einfluss darauf, welches Interface das primary member interface ist.

Somit ist die Meldung in diesem Sinn ein Bug, und zeigt keine Loop an. Lösen kann ich das Problem lediglich durch Abschalten von BLA (keine Pakete mehr) oder Verändern der MAC-Adresse des primäre Interface (br-ethmesh/eth0.3). Ich habe mich für letzteres entschieden und nutzen hier nun eine random MAC-Adresse:

https://github.com/adschm/fff-firmware/commit/a9bf2d96fd60c4a3b031997eefc9f92b7e8088c3

Grüße

Adrian

> -----Original Message-----
> From: Johannes Kimmel [mailto:fff at bareminimum.eu]
> Sent: Montag, 19. Oktober 2020 17:31
> To: Adrian Schmutzler <mail at adrianschmutzler.de>; franken-
> dev at freifunk.net
> Subject: Re: Eindeutige MAC-Adressen mit Batman
> 
> Hi,
> 
> also ich habe gerade mal nachgesehen, was der Kernel macht, wenn man ein
> neues Macvlan Interface anlegt. Der erzeugt sich einfach Zufallsadressen und
> zwar so:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include
> /linux/etherdevice.h?h=v5.9.1#n223
> 
> Eventuell ist das eine Lösung für den Fall.
> 
> Grüße
> 
> On 17.10.20 00:53, Adrian Schmutzler wrote:
> > 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/20201103/4b9bdeb9/attachment.sig>