У меня есть несколько небольших NUC, к каждому из которых подключено несколько адаптеров USB3 LAN (поскольку у NUC только один Ethernet, я добавил дополнительные адаптеры с USB3).
Вы можете увидеть изображение продуктаздесь.
Внезапно, вероятно, из-за неконтролируемого автоматического обновления, эти устройства начали получать случайные MAC-адреса.
До:
Каждое подключенное устройство USB3 имело адрес в форме:
00:0E:C6:XX:XX:XX
Каждый из них был уникален и всегда был одинаковым (стабильным), выдерживая перезагрузки.
Теперь у них такой адрес:
eth1 - be:7d:ee:6a:26:ab
eth2 - be:7d:ee:6a:26:ab
eth3 - be:7d:ee:6a:26:ab
eth4 - be:7d:ee:6a:26:ab
eth5 - be:7d:ee:6a:26:ab
все они имеют один и тот же случайно выбранный адрес.
Короче, неприятности:
- Каждый раз при перезагрузке компьютера этот случайный MAC-адрес меняется.
- Они все имеют один и тот же случайный MAC-адрес. Раньше у каждого был свой и четко различимый.
Устройства идентифицируются следующим lsusbобразом:
ASIX Electronics Corp. AX88179 Гигабитный Ethernet
Я понятия не имею, что произошло с момента последнего автоматического обновления, это вопрос последних 2 дней, 1 час назад все работало нормально, а потом все эти устройства начали вести себя странно.
Может ли это быть проблемное обновление? Может ли быть, что был выпущен новый драйвер, который каждый раз рандомизирует MAC-адрес? Может ли это быть особенностью ядра Linux или дистрибутива или настройки GRUB, когда USB-устройства LAN теперь каждый раз получают случайный MAC-адрес? Но в этом случае, почему все они имеют одинаковый адрес? Они должны быть полностью случайными...
Я ищу помощь и готов пройти тесты...
Относительно ОС:
Версия Debian:12.5
Linux 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux
На данный момент предложены обходные пути, включая последний, который всегда работает благодаря @AB:
- Используйте родительский атрибут «serial» в конфигурации UDEV, чтобы назначить интерфейсу локальной сети другое имя, а не полагаться на MAC-адрес.
- Используйте путь usb адреса USB-NIC в правилах udev, чтобы назначить имя интерфейса вместо MAC-адреса.
- Как сбросить статус сетевого адаптера перед назначением имени в наборе правил udev?
решение1
Этот6.8 фиксация ядра, портировано на 6.1.x:
net: usb: ax88179_178a: избегайте двух последовательных сбросов устройства
предназначенный для избежания двойного сброса на сетевой карте на базе AX88179, имел побочным эффектом получение случайного MAC-адреса для сетевой карты.
Исправление для будущего ядра 6.9 находится в разработке,уже портировано на ядро 6.1.85+который признает предыдущую проблему (и являетсяпредполагаемыйчтобы исправить это). Вот часть подтверждения:
net: usb: ax88179_178a: избегайте интерфейса, всегда настроенного как случайный адрес
После фиксации d2689b6a86b9 ("net: usb: ax88179_178a: избегайте двух последовательных сбросов устройства") сброс не выполняется из операции привязки, и mac-адрес не считывается из регистров устройства или дерева устройств в этот момент. Поскольку проверка для настройки того, является ли назначенный mac-адрес случайным или нет для интерфейса, происходит после операции привязки из usbnet_probe, интерфейс остается настроенным как случайный адрес, хотя адрес правильно считывается и устанавливается во время операции открытия (единственный сброс на данный момент).
Проблема в том, что ядро Debian 6.1.0-20-amd64 уже использует ядро upstream 6.1.85, которое включает исправление. Из комментария OP это, похоже, работает некорректно, так как OPявляетсяс использованием ядра 6.1.0-20-amd64.
Что гарантированно сработает, так это возврат к предыдущему состоянию: до патча, портированного на 6.1.x 2024-02-05. Похоже, что в настоящее время это означает возврат ДВУХ патчей:
- net: usb: ax88179_178a: избегайте интерфейса, всегда настроенного как случайный адрес
- net: usb: ax88179_178a: избегайте двух последовательных сбросов устройства
чтобы гарантировать, что он заработает как прежде (и вернется поведение двойной перезагрузки, которое тогда не казалось проблемой).
За последние недели я мог убедиться, что возвращениеnet: usb: ax88179_178a: избегайте двух последовательных сбросов устройствазаставил его работать, я не проверял, как ведет себя более новое состояние (например: ядро 6.1.85 или Debian 6.1.0-20-amd64). Вопрос/ответ OP предполагает, что, возможно, 2-го патча, предназначенного для исправления поведения, вызванного 1-м патчем, недостаточно, и, возможно, необходимо предоставить еще одно исправление.
Подводя итог, возможные варианты на сегодняшний день:
- сохранить старое ядро, например Debian 6.1.0-18-amd64, доступное по адресуhttps://snapshot.debian.org/ там:
linux-image-6.1.0-18-amd64 - пропатчить ядро между 6.1.77 и 6.1.84, вернув первый патч, упомянутый в этом ответе, и перекомпилировать (проверено, работает)
- проверьте, работает ли у вас ядро 6.1.85 или более новое в текущем состоянии.
либо это работает (больше ничего не нужно делать)
или нет (случай ОП)
Откатите хотя бы первый патч и перекомпилируйте:
net: usb: ax88179_178a: избегайте интерфейса, всегда настроенного как случайный адрес(необязательно, можно сохранить, а не отменять)
net: usb: ax88179_178a: избегайте двух последовательных сбросов устройства: (необходимо вернуть это)
или дождитесь патча, исправляющего это:
ОБНОВЛЯТЬ: этот коммит от 2024-04-18:
net: usb: ax88179_178a: избегайте записи MAC-адреса перед первым чтением
исправляет это (я тестировал это на ядре 6.8.x). Вероятно, его следует включить в следующее ядро 6.1.x upstream 6.1.88, и рано или поздно его выберет Debian. Дополнительный бонус: сброс, похоже, выполняется обратно во время зондирования, а не при интерфейсе UP. Таким образом, задержка для переходов между down и up теперь меньше.