☰

在 udev 規則集中分配名稱之前如何重設網路介面卡的狀態？

tag-icon • tag-icon debian network-interface udev usb-device
在 udev 規則集中分配名稱之前如何重設網路介面卡的狀態？

debian 6.1.0-20 核心更新後 USB3 網路卡介面問題的第 4 部分。

請參閱此處的其他帖子：

抽象的： 最近使用核心 6.1.0-20 的 debian 更新打破了對儲存在 usb-lan nics EEPROM 內的 MAC 位址的識別，因此之前使用ATTR{地址}（根據 mac 位址更改介面名稱）不再起作用。

現在為什麼要寫這篇文章：

  • 使用ATTRS{系列}確實有效，但我有 6 個適配器中的 3 個共享相同的“串行”屬性，因此無法確定哪個是哪個。
  • 我此時嘗試使用USBATTRS{總線號碼}和ATTRS{devnum}具體識別剩餘的 3 個接口，但似乎該值並不穩定，並且會通過移除主交流電流並將其放回去而不時發生變化。

所以上述解決方案都沒有真正解決最後的問題。

然而，似乎如果您使用以下命令放下和打開（或可能僅打開）eth 介面：

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

eth0 又稱 USB3 LAN 適配器讀回儲存在 EEPROM 中的正確 MAC 位址...

此時我唯一的想法是：

  • 我可以放下/打開所有接口，以便它們獲得正確的 MAC 地址並使 udev 再次重新應用規則，還是只在啟動時發生一次？如果可能的話，你能幫我寫一個腳本，能夠將 eth 從 0 降到 10，然後重新呼叫 udev，以便可以重新命名介面。

或者...

  • 當介面已經取回其原始 MAC 位址時，能夠在呼叫 udev 之前向下/向上刷新 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"

然後僅第一次（從較重到最輕的效果）：

  • 重啟

  • 或重新啟動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

      如果介面已經啟動（例如：透過諸如網路管理器），它可能不需要檢查其 MAC 位址類型，而只需執行以下操作：

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

補充筆記

  • 這最終將導致與補丁之前相同數量的設備重置，從而避免發生此類設備重置：兩次，因為介面獲得了額外的 UP（然後是 DOWN），確實觸發了此類重置。

    因此，無論如何編譯核心時，恢復補丁仍然更簡單。當需要 SecureBoot 並且無法簽署產生的核心模組時，此解決方法非常有用。

    實際的第三個驅動程式補丁仍然會受到歡迎。

  • 運行命令

    • 必須使用第一個 RUN 指令。

    • 第二個 RUN 指令應該用於獲得與使用正確處理 NIC 的核心驅動程式執行階段相同的結果：新增處於狀態 DOWN 的介面。人們可能會考慮不要將其設置為“關閉”並保留其“打開”，從而避免一台設備重置（如果以後的網路工具可以解決這一問題）

    • 最後一個 RUN 命令可能會被跳過：如果介面已被僅依賴 MAC 位址的更高版本的網路工具重新命名，則可能不需要該命令。

      • 循環不會發生，因為：

        • 如果介面獲得永久 MAC 位址：無操作
        • 如果介面一旦啟動然後關閉仍然沒有獲得永久 MAC 位址（即：解決方法不起作用），則add不會執行該操作（因為它僅限於永久 MAC 位址裝置），為裝置留下隨機 MAC 位址

  • Debian 以外的其他發行版

    • 確保/bin/ip存在或將其替換為正確的路徑（例如/sbin/ip：）

    • 尤德夫（Devuan、Gentoo ...）：我不知道是否尤德夫行為相同系統的烏德夫當從內部觸發事件時。第三次運行可能需要改變。

  • 如果由於某種原因必須添加附加條件，因為...S匹配變體（對於父屬性）必須全部是同一父屬性的一部分，如果需要DRIVERS=="ax88179_178a"，可以替換ATTRS{product}=="AX88179"為類似的效果（並且如果特定 USB 設備確實匹配）此屬性）以從其他父級（例如ATTRS{serial}）取得備用有用屬性。

  • 至少addr_assign_type=3這似乎意味著 MAC 位址已被更改（手動或其他方式，例如：將介面設定為綁定從屬）。這個規則不會觸及這個（也不應該，也不會遇到這種情況）

  • 使用的文檔

相關內容