Bug 19870

reassign

Стас, это актуально?

(В ответ на комментарий №2)
> Стас, это актуально?

Для десктопа нет. Для сервера видимо да, но вообще говоря модуль alterator-net-wifi надо бы полностью переписывать, а сейчас временно отключить.

2vitty@: отключите?

В сервере я не вижу того, что нужно отключать. Просто у нас сервер без поддержки wifi.

(В ответ на комментарий №5)
> В сервере я не вижу того, что нужно отключать. Просто у нас сервер без
> поддержки wifi.

Она там нужна?

вообще нужна

нужна конечно.

(В ответ на комментарий №8)
> нужна конечно.

Тогда вешайте FR.

так эта ошибка для того и висит

ошибка вообще говоря не на том пакете висит ;)

Вообще с net-wifi сложная ситуация.
Постараюсь её тут кратко описать:
1. etcnet это слегка улучшенная древняя система статической настройки сетевых интерфейсов. Использование etcnet совместно с "динамическими" интерфейсами, например, беспроводными и dhcp сопряженно с трудностями. etcnet работает по принципу выстрелил и забыл, а тут остаются в системе висеть сервисы, которые постоянно меняют своё состояние. Классический race в etcnet это потеря этих сервисов при рестарте сети, например, когда старый dhcpcd не успевает уйти, новый а из-за этого не поднимается. Аналогичные проблемы были и с wpa_supplicant, но путём хитромудрого кода оно решено. Теперь вот dhcpcd, который год от года всё больше хочет стать вторым wpa_supplicant.
2. Будущее видимо за динамическими сервисами настройки сети типа network manager, особенно для desktop.
3. network manager работает с wpa_supplicant совершенно иным способом нежели etcnet, через интерфейс dbus. А wpa_cli не в состоянии подсоединяться к подобному демону и работать. То есть wpa_supplicant может работать или только в стиле etcnet или только в стиле networkmanager.
4. net-eth настраивает etcnet и networkmanager умеет пользоваться этими настройками, в том числе он умеет пользоваться настройками для wireless. Это очень удобно, но ...
5. настройка wireless интерфейса - процесс интерактивный, то есть в нынешней реализации требуется запущенный wpa_supplicant (отдельно запущенный от wpa_supplicant который нужен например network manager). Сетевой драйвер может уйти в шок от того когда с ним начнут одновременно работать два supplicant'a ;).
6. Есть хак, когда перед началом работы модуля net-wifi, он отбирается у networkmanager, тот как можно быстрее отслеживает этот факт и перестаёт его контролировать, но это хак, частенько приводящий к неожиданным результатам.
7. Возможным решением проблемы наверное было бы использование старого доброго iwconfig для отображения некоторой (всё равно недостаточной для полноценного интерактивного модуля) информации, но это тоже путь в никуда ибо wifi интерфейс в ядре периодически меняется, а  нормально мантейнится он только внутри wpa_supplicant. wireless-tools заброшены upstream.
8. Можно было бы пробовать общаться c wpa_supplicant от network manager через dbus, но если это делать через command line, то это совершенно укуренное API. Например для получения списка сетей надо сделать около четырёх нетривиальных запросов. Кроме того всё-равно осталась бы проблема, что нужно держать два разных кода: один для etcnet, второй для networkmanager.

Я понимаю что статическая настройка имеет свои преимущества для сервера, но если networkmanager обладает свойством не рушить статическую настройку при неожиданном падении, то я бы в будущем предпочёл иметь дело с ним и переориентировал бы net-eth и net-wifi полностью на настройку networkmanager.
А если добавить ещё такой paranoid hack, чтобы networkmanager при обнаружении полностью статической настройки просто настраивал бы сеть и завершал свою работу, то вообще было бы сказочно.

В связи со всем сказанным, я бы предпочёл сейчас не теребить net-wifi, где и так уже хак на хаке сидит и хаком погоняет, а переориентировал бы его полностью на networkmanager.

Стас, я на всех своих машинах использую только etcnet, и не наблюдаю никаких проблем с wpa_supplicant и dhcp. Более того - эта связка позволяет делать намного больше, чем networkmanager. Например, у меня автоматически поднимаются/опускаются vpn соединения в зависимости от того, в какой сети я нахожусь.

alterator-net-wifi так-же работает отлично.

Запуск networkmanager на сервере невозможен. Эта система создана для работы на десктопе, где ей и место. на сервере же в большинстве случаев (если этот сервер не в транспорте) нет необходимости менять точки доступа и иже с ними... 

Впрочем, даже с учётом необходимости изменения точек доступа, я не вижу никаких серьёзных проблем не добавлять поддержку WiFI для установок серверов.

Представьте себе ситуацию, что организация подключается по WiFI к интернету, у нас в районе это сплошь и рядом.

Собственно Server 5.0 идеален как раз для таких подключений.

(В ответ на комментарий №13)
> Стас, я на всех своих машинах использую только etcnet, и не наблюдаю никаких
> проблем с wpa_supplicant и dhcp. 
Я верю, что иногда оно работает без race'ов.
У меня дома тоже через etcnet работает wireless, но описанные проблемы (два разных wpa_supplicant и пляска вокруг этого) это не отменяет.

(В ответ на комментарий №13)
> Стас, я на всех своих машинах использую только etcnet, и не наблюдаю никаких
> проблем с wpa_supplicant и dhcp. Более того - эта связка позволяет делать
> намного больше, чем networkmanager. Например, у меня автоматически
> поднимаются/опускаются vpn соединения в зависимости от того, в какой сети я
> нахожусь.
> 
> alterator-net-wifi так-же работает отлично.

То есть у тебя эта бага не воспроизводится?

(В ответ на комментарий №15)
> То есть у тебя эта бага не воспроизводится?

Обсуждаемая здесь бага не может не воспроизводиться т.к. alterator-net-wifi не умеет работать с интерфейсом, если оный заключён в бридж.

Воспроизводится на сервере. Там странная идея - все интерфейсы пихать в бриджи. Я даже знаю, откуда она взялась, но на мой взгляд эту проблему нужно решать другим способом (а именно - строить бриджи тогда, когда в них есть реальная необходимость).

(В ответ на комментарий №16)
> (В ответ на комментарий №15)
> > То есть у тебя эта бага не воспроизводится?
> 
> Обсуждаемая здесь бага не может не воспроизводиться т.к. alterator-net-wifi не
> умеет работать с интерфейсом, если оный заключён в бридж.


alterator-net-wifi прав - у бриджа нет настроек для WiFI. Они есть у основного интерфейса wlan0

Меня, собственно, сейчас интересует, что мы делаем к RC, если дата его выхода -- 30 августа.
1. Забиваем на эту багу в RC сервера, оставляя ее решение до релиза.
2. Пробуем сейчас искать приемлемые решения, учитывая сжатые сроки.

(В ответ на комментарий №17)
> Воспроизводится на сервере. Там странная идея - все интерфейсы пихать в бриджи.
> Я даже знаю, откуда она взялась, но на мой взгляд эту проблему нужно решать
> другим способом (а именно - строить бриджи тогда, когда в них есть реальная
> необходимость).

Совершенно неважно в какой момент будет организован бридж. Но как только он будет организован wifi перестанет настраиваться. В этом и состоит данная бага.

Как я понял, решили чинить в alterator-net-eth (из которого alterator-net-wifi запускается).

А именно, для бриджей определять и отдавать в alterator-net-wifi физический интерфейс, который в этот бридж воткнут (первый из).

Ни и заодно, скрывать ссылку на alterator-net-wifi, если интерфейс управляется NM
(чтоб не приходилось менять supplicant'ов).

Перевешиваю на alterator-net-eth.

alterator-net-eth-4.6-alt1 -> sisyphus:

* Wed Aug 19 2009 Vladislav Zavjalov <slazav@altlinux> 4.6-alt1

[slazav@]
- fix net-wifi calls
[inger@]
- fix wireless property calculation, use real interface instead of bridge
  (closes: #19870)
- html ui:
  * move "wireless settings" button into main interface
  * show "wireless settings" button only for interfaces controlled by etcnet
  * redirect to wireless dialog with real interface, not bridge
- qt ui:
  * move "wireless settings" button into main interface
  * show "wireless settings" button only for interfaces controlled by etcnet
  * redirect to wireless dialog with real interface, not bridge