☰

udev ルールセットで名前を割り当てる前に、ネットワーク アダプターのステータスをリセットするにはどうすればよいですか?

tag-icon • tag-icon debian network-interface udev usb-device
udev ルールセットで名前を割り当てる前に、ネットワーク アダプターのステータスをリセットするにはどうすればよいですか?

Debian 6.1.0-20 カーネルアップデート後の USB3 NIC インターフェイスの問題のパート 4。

他の投稿はこちらをご覧ください:

抽象的な： カーネル6.1.0-20のDebianの最近のアップデートでは、USB-LAN NICのEEPROM内に保存されたMACアドレスの認識が壊れ、以前に書かれたすべてのudevルールがATTR{アドレス}(MAC アドレスに基づいてインターフェース名を変更する) は機能しなくなりました。

さて、なぜこの投稿なのか:

  • 使用してATTRS{シリアル}動作しましたが、6 つのアダプタのうち 3 つが同じ「シリアル」属性を共有しているため、どれがどれであるかを判別できません。
  • この時点でUSBを使用しようとしましたATTRS{バス番号}そしてATTRS{デバイス番号}残りの 3 つのインターフェースを具体的に識別しますが、この値は安定しておらず、主電源の AC 電流を除去して戻すことによって時々変化するようです。

したがって、上記の解決策のどれも、最終的な問題を実際に解決しませんでした。

ただし、次のようなコマンドを使用して eth インターフェイスを down および up (または up のみ) に設定すると、

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

eth0 (別名 USB3 LAN アダプタ) は、EEPROM に保存されている正しい MAC アドレスを読み取ります...

現時点での私の唯一のアイデアは次のとおりです。

  • すべてのインターフェースをダウン/アップして正しい MAC アドレスを取得し、udev にルールを再度適用させることはできますか? それとも、起動時に一度だけ発生するのでしょうか? 可能であれば、0 から 10 まで eth をダウン -> アップし、その後 udev を呼び戻してインターフェースの名前を変更できるスクリプトの作成を手伝っていただけますか。

または...

  • udev が呼び出される主なタイミングの前に、インターフェースがすでに元の MAC アドレスを戻しているときに ETH のダウン/アップを更新でき、この場合、udev がその役割を果たすはずです。

@AB さんが前回提案した RUN+= を使用したソリューションはこれに関係していますか?

答え1

説明

現在の状態を修正するために、OPのアイデアに従って、私は単一のユーデブ次のように規定する:

  • 以下の条件がすべて満たされた場合のみ:

    • 追加する
    • ネットワークデバイス
    • ドライバー付きax88179_178a
    • ランダムなMACアドレス（addr_assign_type=1）で作成

  • 意思：

    • インターフェイスをUPに設定する（これにより、ドライバーは永続的なMACアドレスプロパティを取得できるようになります）

    • DOWN に戻します (これは新しく追加されたインターフェースの予想される状態です)

    • インターフェースが永続的なMACアドレス（addr_assign_type=0）を取得したことが確認された場合、インターフェースの追加を再度トリガーします。

      ... これにより、適切なインターフェイス名の変更を伴う新しいラウンドがトリガーされます。(例: 他に何も指示がない場合、通常、USB ネットワーク インターフェイスは MAC アドレスから次のように名前が変更されますenx...)

ルールとアクティベーション

十分に低い優先度のルールを作成します（私は40を選択しました）

/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"

その後、最初の 1 回のみ、次のいずれかを実行します (影響が重いものから軽いものへ):

  • リブート

  • または再起動udev:

    systemctl restart udev

    • USBデバイスを抜き差しするか

    • またはドライバーをリロードする

      rmmod ax88179_178a
modprobe ax88179_178a

    • または修正が必要なインターフェースでのみ新しいルールを人為的にトリガーする

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

      インターフェースがすでにUP状態になっている場合（例：ネットワーク管理者) の場合は、MAC アドレスの種類を確認せずに、次の操作を実行する必要がある場合があります。

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

その他の注意事項

  • これにより、最終的には、パッチを適用する前と同じ数のデバイス リセットが発生し、このようなデバイス リセットが回避されます。つまり、インターフェイスが追加の UP (その後 DOWN) を取得し、それがこのようなリセットをトリガーするため、2 回になります。

    したがって、カーネルをコンパイルするときには、パッチを元に戻す方がまだ簡単です。SecureBoot が必要で、結果として得られるカーネル モジュールに署名できない場合は、この回避策が役立ちます。

    実際の 3 番目のドライバー パッチは依然として歓迎されます。

  • 実行コマンド

    • 最初の RUN コマンドを使用する必要があります。

    • 2 番目の RUN コマンドは、NIC を適切に処理するカーネル ドライバーで実行する場合と同じ結果を得るために使用する必要があります。つまり、ダウン状態のインターフェイスが追加されます。後続のネットワーク ツールがこれに対処できる場合は、デバイスを 1 つリセットせずに、ダウンに設定せずにアップのままにしておくことを検討できます。

    • 最後の RUN コマンドはスキップされる可能性があります。インターフェイスが MAC アドレスのみに依存する後続のネットワーク ツールによってすでに名前変更されている場合は、このコマンドは必要ない可能性があります。

      • ループは発生しません。理由は次のとおりです:

        • インターフェースが永続的なMACアドレスを取得した場合: アクションなし
        • 一度起動してから停止したインターフェースがまだ永続的な MAC アドレスを取得していない場合 (つまり、回避策が機能しなかった場合)、アクションはadd実行されず (永続的な MAC アドレスを持つデバイスに制限されているため)、デバイスにはランダムな MAC アドレスが残ります。

  • Debian以外のディストリビューション

    • が存在することを確認する/bin/ipか、正しいパスに置き換えてください (例: /sbin/ip)

    • ユーデフ（Devuan、Gentoo ...）：私は知らないユーデフ同じように動作しますシステムのユーデブ内部からイベントをトリガーする場合。3 回目の実行では変更が必要になる可能性があります。

  • 何らかの理由で追加の条件を追加する必要がある場合、...S一致バリアント (親プロパティ用) はすべて同じ親の一部である必要があるため、必要にDRIVERS=="ax88179_178a"応じてATTRS{product}=="AX88179"(特定の USB デバイスが実際にこのプロパティと一致する場合)、他の親 (など) からの代替の有用なプロパティに到達するために、同様の効果を得るために を に置き換えることができますATTRS{serial}。

  • 少なくとも、addr_assign_type=3MAC アドレスが変更された (手動またはその他の方法、例: インターフェースをボンド スレーブとして設定する) ことを意味するものもあるようです。このルールはこれに影響しません (影響するべきでもなく、このケースに遭遇することもありません)。

  • 使用されたドキュメント

関連情報