1) насколько могу судить, модуль b44 коррекно работает с ifplugd и его можно включить в good_list 2) вообще же, корректность реализации ifplugd в драйвере полностью провертиь юзеру трудно. Хтелось бы иметь скрипт, которому даешь имя интерфейса, а он командует воткни провод, подожди 15 сек., что пишет - есть сигнал или нет? Тем более, что такой скрипт мог бы проверять не полную корректность модуля, а возможно только необходимую etcnet функциональность. Actual Results: после отработки zcip(eth1) - сеть пропадает, потому что все пакеты пытаются идти через eth1 После ifdown eth1 - появляется. Или после отключения eth1 явной настройкой etcnet Expected Results: eth0 используется для доступа к сети, поскольку (каждый критерий IMHO имеет смысл и все они однажды должны быть реализованы) 1. он раньше использовался. Негоже unknown перебивать настроенный интерфейс. 2. zcip в принципе не может шлюзовать пакеты куда-то, он насквозь локальный. 3. dhcp протокол более высокого уровня, чем ipv4ll - и должен быть предпочтительнее 4. наконец, у меня просто отключена антенна. См. вывод dmesg: (кажется для wi-fi есть аналог ifplugd? ) zsh 8 % dmesg |tail ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.0.6 ipw2200: Copyright(c) 2003-2004 Intel Corporation ACPI: PCI Interrupt 0000:02:06.0[A] -> Link [LNKG] -> GSI 10 (level, low) -> IRQ 10 ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection ipw2200: Radio Frequency Kill Switch is On: Kill switch must be turned off for wireless networking to work. zcip uses obsolete (PF_INET,SOCK_PACKET) device eth1 entered promiscuous mode device eth1 left promiscuous mode
OOps! все что ниже Actual Result: - не читать, это лишнее приклеилось.
(In reply to comment #0) > 1) насколько могу судить, модуль b44 коррекно работает с ifplugd и его можно > включить в good_list Включил. Чтобы вам не ждать, можете у себя в /etc/net/options.d/90-local переопределить GOOD_MODULE_LIST. > 2) вообще же, корректность реализации ifplugd в драйвере полностью провертиь > юзеру трудно. Хтелось бы иметь скрипт, которому даешь имя интерфейса, а он > командует воткни провод, подожди 15 сек., что пишет - есть сигнал или нет? > Тем более, что такой скрипт мог бы проверять не полную корректность модуля, а > возможно только необходимую etcnet функциональность. Мне нужен корректно работающий ifplugstatus. Если я буду просить пользователя проводить тесты в полевых условиях, ничего хорошего не выйдет, поэтому белый список и был заведён.
1) оно у меня давно гвоздями прибито (IFPLUGD=yes), еще с тех времен, когда никакого auto не предполагалось. ;) 2) не в полевых условиях, а для тех кто захочет дополнить список. ifplugstatus - это запрос, не мониторинг. Разве что есть polling ? А мониторинг - ifplugd. Из переписки с автором ifplugd я понял, что есть частично-работающие драйвера: если устройство включено, ifup, то драйвер посылает событие link beat detected/ lost монитору (демону ifplugd). Но проблема (иногда) начиналась, если сделать вытащить кабель. Казалось бы должен автоматически случиться ifdown - но при этом переставал работать мониторинг, потому ifplugd "руками" выставлял флаг UP но не конфигурировал интерфейс, что позднее сводило с ума etcnet. Я потому и не знаю, какие из подобных тонкостей критичны для etcnet, а накакие он забивает и обходит как-то.
ifplugd и ifplugstatus для нормального железа и модулей определяют состояние линка одним и тем же способом. Проверить адекватность работы ifplugstatus желающие могут самостоятельно.
