Bug 7764

Summary: отсутствует b44
Product: Sisyphus Reporter: burov dmitry <the_arioch>
Component: etcnetAssignee: Mikhail Efremov <sem>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: enhancement    
Priority: P2 CC: ldv, rider, sem, shaba, vseleznv
Version: unstable   
Hardware: all   
OS: Linux   

Description burov dmitry 2005-08-27 07:15:44 MSD
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
Comment 1 burov dmitry 2005-08-27 07:20:19 MSD
OOps! все что ниже Actual Result: - не читать, это лишнее приклеилось.
Comment 2 Denis Ovsienko 2005-08-27 14:45:31 MSD
(In reply to comment #0)
> 1) насколько могу судить, модуль b44 коррекно работает с ifplugd и его можно 
> включить в good_list
Включил. Чтобы вам не ждать, можете у себя в /etc/net/options.d/90-local
переопределить GOOD_MODULE_LIST.

> 2) вообще же, корректность реализации ifplugd в драйвере полностью провертиь 
> юзеру трудно. Хтелось бы иметь скрипт, которому даешь имя интерфейса, а он 
> командует воткни провод, подожди 15 сек., что пишет - есть сигнал или нет?
> Тем более, что такой скрипт мог бы проверять не полную корректность модуля, а 
> возможно только необходимую etcnet функциональность.
Мне нужен корректно работающий ifplugstatus. Если я буду просить пользователя
проводить тесты в полевых условиях, ничего хорошего не выйдет, поэтому белый
список и был заведён.
Comment 3 burov dmitry 2005-08-27 18:36:32 MSD
1) оно у меня давно гвоздями прибито (IFPLUGD=yes), еще с тех времен, когда 
никакого auto не предполагалось. ;)

2) не в полевых условиях, а для тех кто захочет дополнить список.
ifplugstatus - это запрос, не мониторинг. Разве что есть polling ?
А мониторинг - ifplugd.

Из переписки с автором ifplugd я понял, что есть частично-работающие драйвера:
если устройство включено, ifup, то драйвер посылает событие link beat detected/
lost монитору (демону ifplugd). Но проблема (иногда) начиналась, если сделать 
вытащить кабель. Казалось бы должен автоматически случиться ifdown - но при этом 
переставал работать мониторинг, потому ifplugd "руками" выставлял флаг UP но не 
конфигурировал интерфейс, что позднее сводило с ума etcnet.
Я потому и не знаю, какие из подобных тонкостей критичны для etcnet, а накакие 
он забивает и обходит как-то.
Comment 4 Denis Ovsienko 2005-08-29 09:40:29 MSD
ifplugd и ifplugstatus для нормального железа и модулей определяют состояние
линка одним и тем же способом. Проверить адекватность работы ifplugstatus
желающие могут самостоятельно.