
Часть 4 проблемы с интерфейсами USB3 NIC после обновления ядра Debian 6.1.0-20.
Другие посты смотрите здесь:
- Debian 12 - Внезапно моему USB3 Lan адаптеру назначается случайный MAC-адрес при каждой перезагрузке
- Используйте родительский атрибут «serial» в конфигурации UDEV, чтобы назначить интерфейсу локальной сети другое имя, а не полагаться на MAC-адрес.
- Используйте путь usb адреса USB-NIC в правилах udev, чтобы назначить имя интерфейса вместо MAC-адреса.
Абстрактный: Недавнее обновление 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/
качестве примеров