• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Wechselnde MAC-Adressen (CentOS 7.4)

josef-wien

Ultimate Guru
Gräfin Klara schrieb:
Dann setze auf diesem Notebook die HWADDR
Wenn ich das eintrage, gibt es beim Start des Netzwerks die Fehlermeldung
Code:
Schnittstelle »eth0« aktivieren:  Device eth0 has different MAC address than expected, ignoring.
mit dem ganz unbedeutenden Nebeneffekt, daß dann kein Netzwerk zur Verfügung steht, aber bei Euch mag das ja anders sein.
 
gehrke schrieb:
Gräfin Klara schrieb:
Dann setze auf diesem Notebook die HWADDR
Bin unentschlossen. Sollte funktionieren, aber ich würde auch gerne wissen, woran das liegt.
TNX

Das ist schwer zu sagen, du kannst es aber eingrenzen.
Beispiel einer mac
14:D6:4D:xx:xx:xx
stammt von D-Link. Die ersten 3 bytes werden bei der Fertigung "bestückt" und können nur in seltenen Fällen nachher noch geändert werden.
Die letzten 3 bytes werden im letzten Fertigungsprozess in einen eeprom oder in den NIC (controller) geschrieben.
Ändert sich bei dir die mac nur in Form der letzten 3 Stellen, dann ist es wohl ein Problem des eeproms oder das timing der Schnittstelle (meist SPI oder I²C)
Ändern sich aber auch die ersten 3 Stellen, dann geht etwas Seltsames vor sich und mir fällt dazu nichts ein.

Gruß
Gräfin Klara
 
OP
gehrke

gehrke

Administrator
Teammitglied
OK, um die Sache abzurunden:
Code:
[root@j3 ~]# lspci
02:00.0 Ethernet controller: Qualcomm Atheros AR8132 Fast Ethernet (rev c0)
Weitere Ausgrabungen haben das hier zu Tage gefördert (nach Aufwecken aus STR):
Code:
Jan 04 12:12:10 j3 kernel: atl1c 0000:02:00.0: MAC state machine can't be idle since disabled for 10ms second
Jan 04 12:12:10 j3 kernel: atl1c 0000:02:00.0: Error get phy ID
Mögliche Ursache ist wohl auch Altersschwäche bei der Hardware (anno 2010). Falls das plausibel ist, werde ich es wohl doch mit dem Setzen von HWADDR probieren...
 

MH1962

Member
gehrke schrieb:
Mögliche Ursache ist wohl auch Altersschwäche bei der Hardware (anno 2010). Falls das plausibel ist, werde ich es wohl doch mit dem Setzen von HWADDR probieren...
Das war sowieso meine erste Idee, als ich das Eingangs-Posting (grade erst) gelesen habe. Entweder die Ethernet-Karte selbst hat einen an der Waffel oder auch das Ethernet-Kabel.
 
OP
gehrke

gehrke

Administrator
Teammitglied
MH1962 schrieb:
Entweder die Ethernet-Karte selbst hat einen an der Waffel oder auch das Ethernet-Kabel.
Am Kabel liegt es sicher nicht, denn die Bestimmung der MAC-Adresse ist unabhängig davon, ob ein Kabel eingesteckt ist oder nicht.
 
Als erstes mal die Frage: Wieso wird bei dir eth0 verwendet und nicht zB ens18 oder ähnliches?
Wenn irgendwo auf die alten Bezeichnungen geswitcht wird, muß eine Regel dafür da sein um die Bezeichnung persistent zu machen. Unter debian erfolgte/erfolgt? das per udev-rule, ebenso unter suse. Unter redhat scheint die /etc/sysconfig/network-scripts/ifcfg-eth0 (oder ensXX) dies zu machen. Ob HWADDR bei 7.4 noch gültig ist, kann ich dir nicht sagen. Die von marce verlinkte Doku gilt für redhat 6 und auf meinen redhat 7 Kisten wird statt dessen eine UUID verwendet (keine Ahnung wo die von wem erzeugt und hinterlegt wird).

Aber mal ein paar andere Fragen: Wenn die MAC geändert wurde, ist es dann immer die gleiche, falsche MAC? Könnte weitere Hardware zB per USB im Spiel sein?

Das Ganze stinkt nämlich wie der Grund warum man persistente Bezeichnungen für Devices eingeführt hat: Eine Schnittstelle fällt aus oder kommt hinzu und Bums werden allen anderen Devices falsche Bezeichnungen und damit IPs zugewiesen (wenn überhaupt).
Wenn das nächste Mal die MAC nicht hinhaut, guck mal per "ip link show" oder "ip address show" nach ob evtl. ein Device mehr oder weniger vorhanden ist.
Wenn es daran nicht liegt, wird es richtig häßlich ohne das ich dir helfen könnte, dann liegt es an der von dracut erzeugten initrd. Bei der alten Vorgehensweise per mkinitrd wüßte ich noch wie man die "auseinander" nimmt aber nicht bei dracut.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Geier0815 schrieb:
Als erstes mal die Frage: Wieso wird bei dir eth0 verwendet und nicht zB ens18 oder ähnliches?
Wie kommst Du darauf? Der Name des Interfaces lautet 'enp2s0'
Code:
[root@j3 ~]# ifconfig enp2s0
enp2s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:26:b9:XX:XX:XX  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Frisch gebootet, kein Kabel, letzten 3 Stellen manuell ge-X-t. Die ersten 3 Stellen zeigen auf den Hersteller 'Dell', was auch korrekt ist.

Auf die anderen Aspekte gehe ich später ein. Bin gerade unterwegs...
TNX
 

josef-wien

Ultimate Guru
Geier0815 schrieb:
ein Device mehr oder weniger vorhanden
Das hat mit der MAC-Adresse des jeweiligen Geräts nichts zu tun. Bei der Erkennung des Geräts speichert der Kernel dessen MAC-Adresse und stellt sie im vorliegenden Fall unter /sys/class/net/enp2s0/address zur Verfügung. Dieser Wert ist aber nicht veränderbar, man kann lediglich bei der softwaremäßigen Einrichtung des Geräts der Welt eine andere MAC-Adresse erfolgreich vorgaukeln. Da ein solches Vorgaukeln laut gehrke nicht definiert ist, ist es derzeit für mich am wahrscheinlichsten, daß die Netzwerkkarte Chamäleon spielt und manchmal einen falschen Wert liefert (daher auch meine letzte Frage vom 4. Jänner 2018, 17:03 Uhr).



Geier0815 schrieb:
Bei der alten Vorgehensweise per mkinitrd wüßte ich noch wie man die "auseinander" nimmt aber nicht bei dracut.
Das liegt wohl weniger am Programm als am Umstand, daß heute üblicherweise zwei initrd zusammengehängt werden (manche Boot-Manager haben Probleme mit zwei getrennten initrd), damit ein Microcode-Update zum frühest möglichen Zeitpunkt vorgenommen werden kann, wozu die erste initrd simpel und unkomprimiert sein muß (siehe auch https://www.kernel.org/doc/Documentation/x86/microcode.txt).
 
Ok, dann heißt bei dir auch die Datei unterhalb von /etc/sysconfig/network-scripts/ nicht ifcfg-eth0 sondern ifcfg-enp2s0?

Das bedeutet aber auch das sämtliche Spekulationen die hier in Richtung HWADDR (und damit persistent-names) gingen falsch waren. Damit bleibt dann nicht mehr viel übrig. Ein Versuch wert wäre es evtl. mal auf die falsche MAC zu greppen (so sie denn immer gleich ist). Unterhalb von /etc/sysconfig/network-scripts/ und /etc/sysconfig/networking (so vorhanden) und unterhalb von /sys/class/net/

Eine andere Festplatte hast Du nicht zufällig? Damit Du mal ein anderes System aufspielen kannst um zu gucken ob das damit dann auch passiert. Evtl. ist ja tatsächlich was an der Hardware matschig, das halte ich persönlich aber für weniger wahrscheinlich als das im redhat was schief läuft.

[Edit] Das mit "Device fällt aus" war auch auf die alten Zeiten bezogen wo es noch keine udev-rules gab. Da mußte man damals ganz schwindelig die Verbindung MAC zu Device festlegen weil einem sonst die ethX-Bezeichnungen verrutschen konnten. Schei*e bin ich alt das ich mich an so was noch aus Erfahrung erinnern kann ;-) [/Edit]
 
josef-wien schrieb:
... Fall unter /sys/class/net/enp2s0/address zur Verfügung. Dieser Wert ist aber nicht veränderbar, man kann lediglich...

Selbstverständlich ist dieser Wert veränderbar.
Wer in Zeiten wie diesen mit Autonummer (IP) und Fahrgestellnummer (MAC) durch das Netz fährt, ist fahrlässig.


Geier0815 schrieb:
Ok, dann heißt bei dir auch die Datei unterhalb von /etc/sysconfig/network-scripts/ nicht ifcfg-eth0 sondern ifcfg-enp2s0?
Das habe ich doch geschrieben:
Gräfin Klara schrieb:
Bei RedHat gibt es ein file mit dem Namen /etc/sysconfig/network-scripts/ifcfg-eth0
(eth0 ist entsprechend)

Geier0815 schrieb:
Ein Versuch wert wäre es evtl. mal auf die falsche MAC zu greppen (so sie denn immer gleich ist). Unterhalb von /etc/sysconfig/network-scripts/ und /etc/sysconfig/networking (so vorhanden) und unterhalb von /sys/class/net/
Ich glaube nicht, dass das zielführend ist. Was gehrke benötigt ist ein Programm, das die mac
direkt über den driver aus der Hardware liest, um das mit /sys/class/net/enp2s0/address vergleichen zu können.
ifconfig, ip link show, etc. lesen alle NUR aus dem kernel. Im Moment fällt mir kein Programm ein,
dass diese Aufgabe erfüllen könnte. Doch so ein Programm läßt sich ja schnell realisieren. Die 10 Min.
hätte ich schon Zeit, sofern das von Interesse ist.

Gruß
Gräfin Klara
 

warpi

Hacker
Hallo gehrke,
hat dann nur der eine Rechner ein Problem, oder der ganze DHCP läuft unrund?
So wie ich DHCP kenne, wird eine MAC nicht erkannt, gibts auch keine IP, usw.
Hast du die MAC gesehen, wenn das Problem auftaucht, bzw. wie kommst du auf diese Vermutung mit der MAC?
 
OP
gehrke

gehrke

Administrator
Teammitglied
Moin *

Das Thema hat doch mehr Interesse gefunden als ursprünglich von mir gedacht. Vielen Dank für das umfangreiche Feedback, Ihr seid großartig!

Ich versuche, den Sachverhalt noch einmal etwas detaillierter zusammen zu fassen und dabei alle inzwischen aufgekommenen Fragen zu beantworten:

Ein älteres Dell-Notebook (anno 2010) kommt seit einigen Monaten im LAN-Betrieb bei meinem DHCP-Server manchmal nicht mit der erwarteten MAC-Adresse an. Das Notebook ist generell relativ selten im Einsatz und wenn, dann meistens via WLAN, welches dieses Verhalten aber gar nicht zeigt. Ausserdem boote ich relativ selten und verwende stattdessen Suspend-To-X. Das erklärt wahrscheinlich die geringe Häufigkeit der Auftretens. Hinzu kommt, dass der Fehlerfall nur bei bestimmten internen Services auftritt und nicht pauschal die gesamte Netzwerk-Funktionalität betroffen ist.

Der betreffende LAN-Port ist am Switch UNTAGGED für ein bestimmtes VLAN konfiguriert. In beiden Fällen wird die DHCP-Anfrage korrekt mit einer IP im richtigen Sub-Netz beantwortet. Bei Verwendung der richtigen MAC funktioniert die statische Zuordnung zu einer bestimmten IP, andernfalls wird eine aus dem Pool zugewiesen. Aus Sicht des DHCP-Servers also kein Problem.

Das Problem entsteht beim Check auf die IP in der Firewall, wo Regeln hinterlegt sind für die erwartete IP-Adresse. Dort gibt es dann ein DENY für bestimmte Services, wenn nicht die statische Zuordnung zur Ausführung kam.

Da dies nur sehr selten der Fall war, habe ich mir bislang mit dem Workaround geholfen, die aktuelle MAC-Adresse im DHCP-Server zu hinterlegen.

Hier die aktuelle, noch unveränderte Konfiguration der NIC (Verwendung NetworkManger):
Code:
[root@j3 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp2s0
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
NAME="enp2s0"
UUID="<XXX>"
DEVICE="enp2s0"
ONBOOT="yes"
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
ZONE=work

Ich habe erst im Verlauf dieses Threads begonnen, die verwendeten MACs zu protokollieren:
gehrke schrieb:
Code:
[root@j3 .config]# cat /etc/cron.hourly/log-mac.sh 
#!/bin/sh
# collect mac adress
now=`date +%Y.%m.%d:%H:%M` && mac_enp2s0=`ifconfig enp2s0 | grep ether | awk '{ print $2 }'` && mac_wlan=`ifconfig wlp0s29f7u3 | grep ether | awk '{ print $2 }'` && echo "$now $mac_enp2s0 $mac_wlan" >> /var/log/mac.log
Mittlerweile sehe ich dort tatsächlich ein beispielhaftes Vorkommen, welches das Verhalten zeigt (MAC der WLAN-NIC weggelassen und letzten Stellen ge-X-t):
Code:
2018.01.04:17:44 e2:82:f8:XX:XX:XX
2018.01.04:19:01 00:26:b9:XX:XX:XX
Ich konnte nur die Hersteller-ID '00:26:B9' recherchieren und der Firma 'Dell' zuordnen, was korrekt ist. Die ID 'e2:82:f8' konnte ich nirgendwo finden.

Ich hatte einen verdächtigen Eintrag in den Logs gefunden, den ich hier noch einmal komplett recherchiert habe:
Code:
[root@j3 ~]# journalctl --no-pager | grep 'atl1c 0000:02:00.0: Error get phy ID'
Dez 20 18:36:08 j3 kernel: atl1c 0000:02:00.0: Error get phy ID
Dez 21 12:52:27 j3 kernel: atl1c 0000:02:00.0: Error get phy ID
Dez 30 18:31:20 j3 kernel: atl1c 0000:02:00.0: Error get phy ID
Jan 04 12:12:10 j3 kernel: atl1c 0000:02:00.0: Error get phy ID
Jan 05 13:21:21 j3 kernel: atl1c 0000:02:00.0: Error get phy ID

So, das ist der aktuelle Zwischenstand. Ich gehe davon aus, dass in meinem Falle die explizite Konfiguration via HWADDRESS funktionieren wird (@Gräfin Klara: TNX). Eine solche Konfiguration habe ich auf einem CentOS-System gefunden und auf einem Fedora-Notebook ebenfalls. Allerdings hatte ich noch keine Zeit, dieses zu testen. Und wenn sie funktioniert, werde ich damit der Ursache auch nicht mehr auf den Grund gehen können.

Noch einmal Dank an alle Beteilgten bis hierhin...
 

drcux

Hacker
Upps, übersehen....

Aber gehören die Dateien unter /etc/sysconfig/network-scripts/ zum NetworkManager? Dessen Konfiguration liegt doch unter /etc/NetworkManager/.
Daher war ich ein wenig verwirrt...
 
Oben