Upgrade Buster - Bullseye => 2 Geräte mit gleicher MAC im LAN

[ingo2]

Das darf doch nicht wahr sein!

Ich habe hier in meinem LAN 2 Serverlein mit ähnlicher Hardware (PC-Engines APU.2C4 und APU.2D4). Jedes hat 3 Ethernet-Ports (Intel), die ich zu einer Bridge zusammengeschaltet habe. Die Bridge ist in /etc/network/interfaces konfiguriert:

Code: Alles auswählen

auto br0
iface br0 inet static
    address 192.168.33.91
    netmask 255.255.255.0
    gateway 192.168.33.1
    bridge_ports enp1s0 enp2s0 enp3s0
    bridge_fd 0
    bridge_stp no

Nach dem Upgrade des ersten Serverleins habe ich dann vom Router die Meldung über ein "neues Gerät" erhalten. Ursache: die MAC der Bridge hat sich geändert. Soweit ok, steht ja auch in den "listchanges" zu bridge-utils:

Code: Alles auswählen

Linux kernel has changed bridge MAC address selection.

  In older Linux kernels the MAC of the bridge was the lower mac of the
  devices attached to it, this is no longer the case now at Bullseye. The
  kernel now makes up a completely new MAC address.

Also im Router angepasst - fertig, geht.

Dann (da das Upgrade ansonsten völlig glatt und ohne Probleme durchgelaufen ist) auch das 2. Serverlein auf Bullseye upgegradet:

Nach dem zum Schluss fälligen Reboot steht das Netzwerk und mein Server ist nicht mehr erreichbar!
Glücklicherweise konnte ich noch über eine serielle Konsole zugreifen und habe mir die Netzwerkkonfiguration anzeigen lassen (ifconfig) und mußte feststellen, der hat exakt die gleiche MAC-Adresse auf der Bridge bekommen wie der 1. Server.

Also dem Rat in den "listchanges" gefolgt und in der Bridge-Konfiguration wieder die alte Methode eingestellt mit der Zeile

Code: Alles auswählen

    bridge_hw enp1s0

Reboot - und alles läuft wieder (hab jetzt auch den anderen Server wieder auf alte Methode konfiguriert).

Hier noch der Vollständigkeit halber die MAC-Adressen:

Code: Alles auswählen

apu	enp1s0		00:0d:b9:47:83:e8		-	(Eth1)
	enp2s0		00:0d:b9:47:83:e9		-	(Eth2)
	enp3s0		00:0d:b9:47:83:ea		-	(Eth3)
	br0		00:0d:b9:47:83:e8 => 4a:0f:ba:96:49:a5

apu2	enp1s0		00:0d:b9:4e:76:a0		-	(Eth1)
	enp2s0		00:0d:b9:4e:76:a1		-	(Eth2)
	enp3s0		00:0d:b9:4e:76:a2		-	(Eth3)
	br0		00:0d:b9:4e:76:a0 => 4a:0f:ba:96:49:a5

4a:0f:ba:96:49:a5 ist die besagte doppelt vergebene MAC in Bullseye.

So etwas darf doch nicht sein - und schon garnicht ohne Vorwarnung. Man stelle sich nur eine "Serverfarm" mit mehreren gleichartigen Servern vor - soll man dann bei allen persönlich über eine serielle Konsole das umkonfigurieren? Deshalb einen Bug eröffnet 998516.

Wie um Himmels Willen ermittelt denn der Kernel die neue MAC-Adresse, die sollte doch "global unique" oder zumindest lokal einzig sein?
Kann man das irgendwo an der Wurzel des Übels ab- bzw. ein-stellen und wie?

Ich habe dazu lange gesucht, aber nichts Brauchbares gefunden.
Ich kann mir nicht vorstellen, dass der Kernel solche Fehler macht, schätze eher das "Orakel von Delphi" - auch als Systemd/udev bekannt.

Gruß, Ingo

[hozo66]

Danke für den Hinweis. Ich kann Dir nur in deinen Beobachtungen beipflichten.

Bestätigt mich darin, auf Devuan umzusteigen bis die Debian Community diese schlechte Idee (*), die sich systemd nennt, wieder aufgibt.

(*) schlechte Idee weil: monolithisch, intransparent, gegen einige Community-Prinzipien verstoßend

[MSfree]

Bestätigt mich darin, auf Devuan umzusteigen bis die Debian Community diese schlechte Idee (*), die sich systemd nennt, wieder aufgibt.

Ja, systemd ist Mist, das wissen wir alle.

Das Problem, das Ingo2 hier beschreibt, hat jedoch mit systemd nichts zu tun. Welche MAC für eine Bridge benutzt wird, wird entweder vom Kernel oder von den bridge-utils bestimmt.

[reox]

Durchaus interessanter Bug! Ich hab auch vor kurzem einen APU1 auf bullseye gezogen und präventiv sofort die alte MAC reingeschrieben - zumal ich für v6 auch die linklocal des routers verwende...
Ich hab versucht herauszufinden wie das kommt. Die MAC wird offenbar mit dieser Funktion hier generiert: https://github.com/torvalds/linux/blob/ ... ice.h#L230
Die Funktion verwendet get_random_bytes. Ich kann mir nur vorstellen, dass du tatsächlich aufgrund der ähnlichkeit der boards keinen ganz zufälligen zufall mehr erwischt hast - weil ja die bridge vermutlich sehr früh initialisiert wird. Trotzdem sollte da doch ein bissi mehr entropie vorhanden sein? Spannend wäre jetzt zu wissen was passiert wenn du die Bridge neu anlegst und eine neue MAC generieren lässt (und noch interessanter: gibt es einen Unterschied zwischen Systemstart und laufendem system)

[MSfree]

Durchaus interessanter Bug!

Ich glaube nicht, daß man das neue Verhalten der Bridges als Bug bezeichnen sollte. Vormals wurde der Bridge die MAC der ersten Netzwerkschnittstelle zugeordnet, die zur Bridge hinzugefügt wurde. Jetzt wird eine zufällige MAC verwendet, solange man nicht mit

Code: Alles auswählen

    bridge_hw enp1s0

erzwingt, die MAC der angegebenen Netzwerkschnittstelle zu verwenden.

Daß da eventuell ein Bug in get_random_bytes steckt, der die "Zufallszahlen" dann eben nicht zufällig generiert sondern systematisch, ist natürlich nicht ausgeschlossen. Wenn es richtig programmiert wurde, sollte get_random_bytes einfach auf /dev/random zugreifen.

Ich bin von der Nutzung einer zufälligen MAC auch nicht besonders begeistert. Viele DHCP-Server ordnen den Clients pseudostatische IP-Adressen zu, abhängig von der MAC. Durch zufällige MACs kann man solche DHCP-Server unter Umständen zu einem Denial-of-Service zwingen, in dem man in kurzer Zeit den DHCP-Server mit MACs flutet und der so seinen Adresspool, der oft nur 250 Adressen groß ist, aufbraucht.

[reox]

Durchaus interessanter Bug!

Ich glaube nicht, daß man das neue Verhalten der Bridges als Bug bezeichnen sollte

Ich meinte ja eh genau das:

Daß da eventuell ein Bug in get_random_bytes steckt, der die "Zufallszahlen" dann eben nicht zufällig generiert sondern systematisch, ist natürlich nicht ausgeschlossen

Obs tatsächlich ein bug ist ist halt fraglich, vor allem liegts an falscher verwendung in bridge oder an "falschem" zufall in random? allerdings schreibt die Doku zu get_random_bytes, dass es wie zufall aus /dev/urandom ist - also sollte da schon mehr zufall drin sein.

Ich bin von der Nutzung einer zufälligen MAC auch nicht besonders begeistert

Ja, und mit IPv6 hat man das Problem, dass die Lokalen IPs anhand der MAC vergeben werden und ich hab viel damit konfiguriert, zB den lokalen DNS Server.

[hikaru]

(PC-Engines APU.2C4 und APU.2D4)

Die MAC wird offenbar mit dieser Funktion hier generiert: https://github.com/torvalds/linux/blob/ ... ice.h#L230

AMD hat(te?) doch immer mal wieder Probleme mit der RDRAND-Performance, was zu zu wenig Entropie in /dev/random und/oder(?) /dev/urandom führte.
Spielt das hier eine Rolle?

[reox]

Hab mal auf meinem APU geschaut:

Code: Alles auswählen

# lscpu
[...]
CPU family:                      20
Model:                           2
Model name:                      AMD G-T40E Processor
[...]
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lah
                                 f_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt hw_pstate vmmcall arat npt lbrv svm_lock nrip_save pausefilter

Die CPU ist AMD Family 20 - und offenbar (?) tritt dieser RDRAND Fehler nur (?) bei Familiy 22 auf: https://bugzilla.kernel.org/show_bug.cgi?id=85911
Aber schon möglich, dass zur Bootzeit bei den boards einfach zuwenig Zufall gesammelt wurde und dann die selbe MAC rauskommt. Im Kernel steht eh auch drin, dass embedded Hardware davon betroffen sein kann, aber offenbar sollen gewisse andere seeds das verhindern.