☰

Wie setzt man den Status eines Netzwerkadapters zurück, bevor man den Namen in einem Udev-Regelsatz zuweist?

tag-icon • tag-icon debian network-interface udev usb-device
Wie setzt man den Status eines Netzwerkadapters zurück, bevor man den Namen in einem Udev-Regelsatz zuweist?

Teil 4 des Problems mit den USB3-NIC-Schnittstellen nach dem Kernel-Update von Debian 6.1.0-20.

Die anderen Beiträge finden Sie hier:

Abstrakt: Ein kürzliches Update von Debian mit Kernel 6.1.0-20 unterbrach die Erkennung der in den EEPROMs der USB-LAN-Netzwerkkarten gespeicherten Mac-Adresse, so dass alle zuvor mit demATTR{Adresse}(Ändern des Schnittstellennamens basierend auf der MAC-Adresse) funktioniert nicht mehr.

Warum nun dieser Beitrag:

  • Verwendung derATTRS{serial}hat funktioniert, aber ich habe 3 von 6 Adaptern, die das gleiche „serielle“ Attribut haben, daher ist es nicht möglich festzustellen, welcher welcher ist.
  • Ich habe an dieser Stelle versucht, die USB's zu verwendenATTRS{busnum}UndATTRS{Gerätenummer}um speziell die drei verbleibenden Schnittstellen zu identifizieren, es scheint jedoch, dass diese Werte nicht stabil sind und sich von Zeit zu Zeit ändern, wenn der Netzwechselstrom entfernt und wiederhergestellt wird.

Keine der oben genannten Lösungen hat also das eigentliche Problem gelöst.

Wenn Sie jedoch „down“ und „up“ (oder vielleicht nur „up“) eingeben, scheint die ETH-Schnittstelle Befehle wie die folgenden zu enthalten:

ip link set dev eth0 down
ip link set dev eth0 up

eth0, auch bekannt als USB3-LAN-Adapter, liest die korrekte, im EEPROM gespeicherte Mac-Adresse zurück …

An diesem Punkt ist meine einzige Idee:

  • Kann ich alle Schnittstellen zurücksetzen/upgraden, damit sie die richtige Mac-Adresse erhalten und Udev die Regeln erneut anwendet, oder passiert das nur einmal beim Booten? Falls möglich, können Sie mir helfen, ein Skript zu schreiben, das eth von 0 bis 10 zurücksetzen und dann Udev wieder aufrufen kann, damit die Schnittstellen umbenannt werden können.

oder...

  • Die Möglichkeit, die ETHs herunter-/hochzuladen, bevor udev tatsächlich aufgerufen wird, wenn die Schnittstellen bereits ihre ursprüngliche Mac-Adresse zurückerhalten haben. In diesem Fall sollte udev seine Aufgabe erfüllen.

Die Lösung mit RUN+=, die Sie letztes Mal vorgeschlagen haben, @AB, hängt damit zusammen?

Antwort1

Beschreibung

Um den aktuellen Zustand zu beheben, habe ich nach der Idee des OP eine einzigeudevurteilen, dass:

  • nur wenn alle dieser Bedingungen erfüllt sind:

    • Hinzufügen
    • ein Netzwerkgerät
    • mit Fahrerax88179_178a
    • mit einer zufälligen MAC-Adresse erstellt ( addr_assign_type=1)

  • Wille:

    • Setzen Sie die Schnittstelle auf „UP“ (damit der Treiber die permanente MAC-Adresseigenschaft abruft).

    • setze es wieder auf DOWN (das ist der erwartete Status einer neu hinzugefügten Schnittstelle)

    • Wenn bestätigt wird, dass die Schnittstelle nun ihre permanente MAC-Adresse abgerufen hat ( addr_assign_type=0), lösen Sie das Hinzufügen der Schnittstelle erneut aus

      ... und löst damit eine neue Runde mit der entsprechenden Umbenennung der Schnittstelle aus. (Beispiel: Wenn nichts anderes angegeben ist, werden USB-Netzwerkschnittstellen normalerweise anhand ihrer MAC-Adresse in umbenannt. enx...)

Regel und Aktivierung

Erstellen Sie eine Regel mit einer ausreichend niedrigen Priorität (ich habe 40 gewählt)

/etc/udev/rules.d/40-local-net-ax88179_178a.rules:

ACTION=="add", SUBSYSTEM=="net", ATTR{addr_assign_type}=="1", DRIVERS=="ax88179_178a", \
  RUN="/bin/ip link set %k up", RUN+="/bin/ip link set %k down", \
  RUN+="/bin/udevadm trigger -s net -a addr_assign_type=0 -p INTERFACE=%k -c add"

Dann nur beim ersten Mal, entweder (vom stärkeren zum leichtesten Effekt):

  • Neustart

  • oder neu starten udev:

    systemctl restart udev

    • und USB-Geräte entweder ab- oder wieder anschließen

    • oder Treiber neu laden

      rmmod ax88179_178a
modprobe ax88179_178a

    • oder die neue Regel künstlich nur auf Schnittstellen auslösen, die eine Korrektur benötigen

      udevadm trigger -v -s net -p ID_NET_DRIVER=ax88179_178a -a addr_assign_type=1 -c add

      Wenn die Schnittstelle bereits aktiviert wurde (z. B. durch ein Netzwerktool wieNetzwerk Manager), muss möglicherweise nicht der MAC-Adresstyp überprüft werden, sondern es muss lediglich Folgendes ausgeführt werden:

      udevadm trigger -v -s net -p ID_NET_DRIVER=ax88179_178a -c add

Zusätzliche Bemerkungen

  • Dadurch werden am Ende die gleiche Anzahl an Geräte-Resets wie vor dem Patch durchgeführt, wodurch solche Geräte-Resets vermieden werden: zwei, weil die Schnittstelle ein zusätzliches UP (dann DOWN) erhält, das solche Resets auslöst.

    Wenn Sie also ohnehin einen Kernel kompilieren, ist es immer noch einfacher, den Patch rückgängig zu machen. Wenn Sie SecureBoot benötigen und das resultierende Kernelmodul nicht signieren können, ist dieser Workaround nützlich.

    Ein tatsächlicher Patch für den 3. Treiber wäre dennoch willkommen.

  • RUN-Befehle

    • Der erste RUN-Befehl MUSS verwendet werden.

    • Der zweite RUN-Befehl SOLLTE verwendet werden, um das gleiche Ergebnis zu erzielen wie bei der Ausführung mit einem Kerneltreiber, der die Netzwerkkarte ordnungsgemäß handhabt: eine hinzugefügte Schnittstelle im Status DOWN. Man könnte darüber nachdenken, sie nicht auf DOWN zu setzen und sie UP zu lassen, um ein Zurücksetzen eines Geräts zu vermeiden, wenn spätere Netzwerktools damit umgehen können.

    • Der letzte RUN-Befehl KANN möglicherweise übersprungen werden: Er ist möglicherweise nicht erforderlich, wenn die Schnittstelle bereits von einem späteren Netzwerktool umbenannt wurde, das nur auf der MAC-Adresse basiert.

      • Schleife wird nicht auftreten, weil:

        • wenn die Schnittstelle die permanente MAC-Adresse erhalten hat: keine Aktion
        • Wenn die Schnittstelle nach dem Hoch- und Herunterfahren immer noch keine permanente MAC-Adresse erhalten hat (d. h.: die Problemumgehung hat nicht funktioniert), addwird die Aktion nicht ausgeführt (da sie auf ein Gerät mit permanenter MAC-Adresse beschränkt ist), sodass das Gerät eine zufällige MAC-Adresse erhält

  • Andere Distributionen als Debian

    • Stellen Sie sicher, /bin/ipdass der Pfad existiert, oder ersetzen Sie ihn durch einen korrekten Pfad (z. B.: /sbin/ip).

    • eudev(Devuan, Gentoo ...): Ich weiß nicht, obeudevverhält sich genauso wiesystemd'Sudevwenn ein Ereignis von innen ausgelöst wird. Der 3. RUN muss möglicherweise geändert werden.

  • Wenn aus irgendeinem Grund zusätzliche Bedingungen hinzugefügt werden müssen, da die ...SÜbereinstimmungsvarianten (für eine übergeordnete Eigenschaft) alle Teil desselben übergeordneten Elements sein müssen, DRIVERS=="ax88179_178a"könnte bei Bedarf (und wenn das bestimmte USB-Gerät tatsächlich dieser Eigenschaft entspricht) für eine ähnliche Wirkung durch ersetzt werden, ATTRS{product}=="AX88179"um alternative nützliche Eigenschaften von einem anderen übergeordneten Element (wie z. B. ATTRS{serial}) zu erreichen.

  • Es gibt zumindest auch addr_assign_type=3das, was zu bedeuten scheint, dass die MAC-Adresse geändert wurde (manuell oder anderweitig, z. B.: Festlegen der Schnittstelle als Bond-Slave). Diese Regel berührt dies nicht (sollte sie auch nicht und würde auch nicht auf diesen Fall stoßen).

  • verwendete Dokumentation

verwandte Informationen