Wechselnde MAC-Adressen (CentOS 7.4)

[josef-wien]

Dann setze auf diesem Notebook die HWADDR

Wenn ich das eintrage, gibt es beim Start des Netzwerks die Fehlermeldung

Code: Alles auswählen

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.

[Gräfin Klara]

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

[gehrke]

OK, um die Sache abzurunden:

Code: Alles auswählen

[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: Alles auswählen

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]

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.

[gehrke]

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.

[Geier0815]

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.

[gehrke]

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: Alles auswählen

[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]

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).

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/Documentatio ... rocode.txt).

[Geier0815]

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]

[Gräfin Klara]

... 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.

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:

Bei RedHat gibt es ein file mit dem Namen /etc/sysconfig/network-scripts/ifcfg-eth0
(eth0 ist entsprechend)

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]

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?

[gehrke]

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: Alles auswählen

[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:

Code: Alles auswählen

[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: Alles auswählen

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: Alles auswählen

[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]

Nutzt du auf dem System den Networkmanager?

[gehrke]

Nutzt du auf dem System den Networkmanager?

Hier die aktuelle, noch unveränderte Konfiguration der NIC (Verwendung NetworkManger):

[drcux]

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...