Bug 19870 - Не возможно настроить WiFi интерфейс
Summary: Не возможно настроить WiFi интерфейс
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: alterator-net-eth (show other bugs)
Version: unstable
Hardware: all Linux
: P3 critical
Assignee: Mikhail Efremov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 19564
  Show dependency tree
 
Reported: 2009-04-30 16:09 MSD by Andrey Lykov
Modified: 2009-08-20 16:57 MSD (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Lykov 2009-04-30 16:09:56 MSD
Нет возможности настроить WiFi интерфейс, поскольку он представлен в виде bridge. Под именем brwlan0
Comment 1 Dmitry V. Levin 2009-06-02 01:01:57 MSD
reassign
Comment 2 AEN 2009-08-05 15:23:23 MSD
Стас, это актуально?
Comment 3 inger@altlinux.org 2009-08-06 12:05:38 MSD
(В ответ на комментарий №2)
> Стас, это актуально?

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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