Как сбросить статус сетевого адаптера перед назначением имени в наборе правил udev?

Как сбросить статус сетевого адаптера перед назначением имени в наборе правил udev?

Часть 4 проблемы с интерфейсами USB3 NIC после обновления ядра Debian 6.1.0-20.

Другие посты смотрите здесь:

Абстрактный: Недавнее обновление Debian с ядром 6.1.0-20 сломало распознавание MAC-адреса, хранящегося в EEPROM-памяти сетевых карт USB-LAN, так что все правила Udev, записанные ранее сATTR{адрес}(изменение имени интерфейса на основе MAC-адреса) больше не работает.

Итак, почему этот пост:

  • используяATTRS{серийный}сработало, но у меня 3 адаптера из 6 имеют одинаковый атрибут «последовательный», поэтому невозможно определить, какой из них какой.
  • В этот момент я попытался использовать USB-накопитель.ATTRS{busnum}иATTRS{devnum}для точной идентификации 3 оставшихся интерфейсов, однако, похоже, что эти значения нестабильны и время от времени меняются при отключении и повторном включении переменного тока сети.

Таким образом, ни одно из вышеперечисленных решений на самом деле не решило конечную проблему.

Однако, похоже, что если вы нажмете «вниз» и «вверх» (или, может быть, только «вверх»), интерфейс eth будет работать с такими командами:

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

eth0, он же сетевой адаптер USB3, считывает правильный MAC-адрес, хранящийся в EEPROM...

На данный момент у меня есть только одна идея:

  • Могу ли я отключить/поднять все интерфейсы, чтобы они получили правильный mac-адрес и заставить udev повторно применить правила, или это происходит только один раз во время загрузки? Если возможно, можете ли вы помочь мне написать скрипт, который сможет отключить -> включить eth с 0 до 10, а затем вернуть udev, чтобы интерфейсы можно было переименовать.

или...

  • Возможность обновления ETH до того, как будет вызван udev, когда интерфейсы уже получат свой исходный MAC-адрес, и в этом случае udev должен выполнить свою работу.

Решение с RUN+=, которое вы предлагали в прошлый раз @AB, связано с этим?

решение1

Описание

Чтобы исправить текущее состояние, следуя идее ОП, я сделал одинудевправило, что:

  • только при соблюдении всех этих условий:

    • добавление
    • сетевое устройство
    • с водителем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
      

      Если интерфейс уже был переведен в режим UP (например, с помощью сетевого инструмента, такого какСетевой менеджер), возможно, потребуется не проверять тип MAC-адреса, а просто сделать следующее:

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

Дополнительные замечания

  • в конечном итоге это приведет к тому же количеству сбросов устройства, что и до патча, предотвращающего сброс устройства: два, поскольку интерфейс получает дополнительный сигнал UP (затем DOWN), который инициирует такой сброс.

    Таким образом, при компиляции ядра в любом случае откат патча все равно проще. Когда нужен SecureBoot и нет возможности подписать полученный модуль ядра, то этот обходной путь полезен.

    Актуальный патч для третьего драйвера все равно был бы кстати.

  • Команды RUN

    • ОБЯЗАТЕЛЬНО должна быть использована первая команда RUN.

    • Вторая команда RUN ДОЛЖНА использоваться для получения того же результата, что и при запуске с драйвером ядра, который правильно обрабатывает NIC: добавленный интерфейс в состоянии DOWN. Можно было бы подумать о том, чтобы не устанавливать его в состояние DOWN и оставить его в состоянии UP, сэкономив одно устройство для сброса, если более поздние сетевые инструменты смогут справиться с этим

    • Последняя команда RUN МОЖЕТ быть пропущена: она может не понадобиться, если интерфейс уже переименован более поздним сетевым инструментом, полагающимся только на MAC-адрес.

      • цикл не произойдет, потому что:

        • если интерфейс получил постоянный MAC-адрес: никаких действий
        • если интерфейс, который был включен и выключен, все еще не получил постоянный MAC-адрес (т. е. обходной путь не сработал), то действие addне будет выполнено (поскольку оно ограничено устройством с постоянным MAC-адресом), оставив устройство со случайным MAC-адресом.
  • Другие дистрибутивы, кроме Debian

    • Убедитесь, /bin/ipчто он существует, или замените его правильным путем (например: /sbin/ip)

    • eudev(Devuan, Gentoo ...): Я не знаю, еслиeudevведет себя так же, каксистемд'sудевпри запуске события изнутри. 3-й ЗАПУСК может потребовать изменений.

  • Если по какой-то причине необходимо добавить дополнительные условия, поскольку ...Sвсе варианты соответствия (для родительского свойства) должны быть частью одного и того же родителя, DRIVERS=="ax88179_178a"можно заменить на ATTRS{product}=="AX88179"для аналогичного эффекта, если это необходимо (и если конкретное USB-устройство действительно соответствует этому свойству), чтобы получить альтернативные полезные свойства от другого родителя (например, ATTRS{serial}).

  • По крайней мере, также есть addr_assign_type=3что-то, что, похоже, означает, что MAC-адрес был изменен (вручную или иным образом, например: установка интерфейса в качестве подчиненного устройства). Это правило не будет этого касаться (и не должно, и не столкнется с этим случаем)

  • использованная документация

    • udev(7)
    • udevadm(8)
    • файлы в /lib/udev/rules.d/качестве примеров

Связанный контент