Wenn ich das eintrage, gibt es beim Start des Netzwerks die FehlermeldungGräfin Klara schrieb:
Code:
Schnittstelle »eth0« aktivieren: Device eth0 has different MAC address than expected, ignoring.
-
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)
- Ersteller gehrke
- Erstellt am
gehrke schrieb:
Das ist schwer zu sagen, du kannst es aber eingrenzen.
Beispiel einer mac
14
6:4D:xx:xx:xxstammt 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
OK, um die Sache abzurunden:
Weitere Ausgrabungen haben das hier zu Tage gefördert (nach Aufwecken aus STR):
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...
Code:
[root@j3 ~]# lspci
02:00.0 Ethernet controller: Qualcomm Atheros AR8132 Fast Ethernet (rev c0)
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
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.
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
Wie kommst Du darauf? Der Name des Interfaces lautet 'enp2s0'Geier0815 schrieb:
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 0Auf die anderen Aspekte gehe ich später ein. Bin gerade unterwegs...
TNX
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:
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).Geier0815 schrieb:
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]
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:
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.
Das habe ich doch geschrieben:Geier0815 schrieb:
Gräfin Klara schrieb:
Ich glaube nicht, dass das zielführend ist. Was gehrke benötigt ist ein Programm, das die macGeier0815 schrieb:
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
OP
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):
Ich habe erst im Verlauf dieses Threads begonnen, die verwendeten MACs zu protokollieren:
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:
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...
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=workIch habe erst im Verlauf dieses Threads begonnen, die verwendeten MACs zu protokollieren:
Mittlerweile sehe ich dort tatsächlich ein beispielhaftes Vorkommen, welches das Verhalten zeigt (MAC der WLAN-NIC weggelassen und letzten Stellen ge-X-t):gehrke schrieb:
Code:
2018.01.04:17:44 e2:82:f8:XX:XX:XX
2018.01.04:19:01 00:26:b9:XX:XX:XXIch 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 IDSo, 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...