Bug 19870 - Не возможно настроить WiFi интерфейс
: Не возможно настроить WiFi интерфейс
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/alterator-net-eth)
: unstable
: all Linux
: P3 critical
Assigned To:
:
:
:
:
: 19564
  Show dependency tree
 
Reported: 2009-04-30 16:09 by
Modified: 2009-08-20 16:57 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-04-30 16:09:56
Нет возможности настроить WiFi интерфейс, поскольку он представлен в виде
bridge. Под именем brwlan0
------- Comment #1 From 2009-06-02 01:01:57 -------
reassign
------- Comment #2 From 2009-08-05 15:23:23 -------
Стас, это актуально?
------- Comment #3 From 2009-08-06 12:05:38 -------
(В ответ на комментарий №2)
> Стас, это актуально?

Для десктопа нет. Для сервера видимо да, но вообще говоря модуль
alterator-net-wifi надо бы полностью переписывать, а сейчас временно отключить.
------- Comment #4 From 2009-08-12 22:21:39 -------
2vitty@: отключите?
------- Comment #5 From 2009-08-13 14:29:06 -------
В сервере я не вижу того, что нужно отключать. Просто у нас сервер без
поддержки wifi.
------- Comment #6 From 2009-08-14 00:16:18 -------
(В ответ на комментарий №5)
> В сервере я не вижу того, что нужно отключать. Просто у нас сервер без
> поддержки wifi.

Она там нужна?
------- Comment #7 From 2009-08-14 00:20:23 -------
вообще нужна
------- Comment #8 From 2009-08-14 00:59:30 -------
нужна конечно.
------- Comment #9 From 2009-08-14 01:02:29 -------
(В ответ на комментарий №8)
> нужна конечно.

Тогда вешайте FR.
------- Comment #10 From 2009-08-14 01:09:33 -------
так эта ошибка для того и висит
------- Comment #11 From 2009-08-14 11:14:54 -------
ошибка вообще говоря не на том пакете висит ;)
------- Comment #12 From 2009-08-14 11:35:30 -------
Вообще с 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.
------- Comment #13 From 2009-08-14 11:46:21 -------
Стас, я на всех своих машинах использую только etcnet, и не наблюдаю никаких
проблем с wpa_supplicant и dhcp. Более того - эта связка позволяет делать
намного больше, чем networkmanager. Например, у меня автоматически
поднимаются/опускаются vpn соединения в зависимости от того, в какой сети я
нахожусь.

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

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

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

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

Собственно Server 5.0 идеален как раз для таких подключений.
------- Comment #14 From 2009-08-14 11:55:31 -------
(В ответ на комментарий №13)
> Стас, я на всех своих машинах использую только etcnet, и не наблюдаю никаких
> проблем с wpa_supplicant и dhcp. 
Я верю, что иногда оно работает без race'ов.
У меня дома тоже через etcnet работает wireless, но описанные проблемы (два
разных wpa_supplicant и пляска вокруг этого) это не отменяет.
------- Comment #15 From 2009-08-15 16:22:29 -------
(В ответ на комментарий №13)
> Стас, я на всех своих машинах использую только etcnet, и не наблюдаю никаких
> проблем с wpa_supplicant и dhcp. Более того - эта связка позволяет делать
> намного больше, чем networkmanager. Например, у меня автоматически
> поднимаются/опускаются vpn соединения в зависимости от того, в какой сети я
> нахожусь.
> 
> alterator-net-wifi так-же работает отлично.

То есть у тебя эта бага не воспроизводится?
------- Comment #16 From 2009-08-15 16:35:40 -------
(В ответ на комментарий №15)
> То есть у тебя эта бага не воспроизводится?

Обсуждаемая здесь бага не может не воспроизводиться т.к. alterator-net-wifi не
умеет работать с интерфейсом, если оный заключён в бридж.
------- Comment #17 From 2009-08-15 16:59:03 -------
Воспроизводится на сервере. Там странная идея - все интерфейсы пихать в бриджи.
Я даже знаю, откуда она взялась, но на мой взгляд эту проблему нужно решать
другим способом (а именно - строить бриджи тогда, когда в них есть реальная
необходимость).
------- Comment #18 From 2009-08-15 17:00:25 -------
(В ответ на комментарий №16)
> (В ответ на комментарий №15)
> > То есть у тебя эта бага не воспроизводится?
> 
> Обсуждаемая здесь бага не может не воспроизводиться т.к. alterator-net-wifi не
> умеет работать с интерфейсом, если оный заключён в бридж.


alterator-net-wifi прав - у бриджа нет настроек для WiFI. Они есть у основного
интерфейса wlan0
------- Comment #19 From 2009-08-15 17:10:15 -------
Меня, собственно, сейчас интересует, что мы делаем к RC, если дата его выхода
-- 30 августа.
1. Забиваем на эту багу в RC сервера, оставляя ее решение до релиза.
2. Пробуем сейчас искать приемлемые решения, учитывая сжатые сроки.
------- Comment #20 From 2009-08-15 17:32:25 -------
(В ответ на комментарий №17)
> Воспроизводится на сервере. Там странная идея - все интерфейсы пихать в бриджи.
> Я даже знаю, откуда она взялась, но на мой взгляд эту проблему нужно решать
> другим способом (а именно - строить бриджи тогда, когда в них есть реальная
> необходимость).

Совершенно неважно в какой момент будет организован бридж. Но как только он
будет организован wifi перестанет настраиваться. В этом и состоит данная бага.
------- Comment #21 From 2009-08-15 19:24:16 -------
Как я понял, решили чинить в alterator-net-eth (из которого alterator-net-wifi
запускается).

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

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

Перевешиваю на alterator-net-eth.
------- Comment #22 From 2009-08-19 16:50:21 -------
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