Eindeutige MAC-Adressen mit Batman

[Johannes Kimmel]

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