Bug 7764

Summary:	отсутствует b44
Product:	Sisyphus	Reporter:	burov dmitry <the_arioch>
Component:	etcnet	Assignee:	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
желающие могут самостоятельно.