19870 2009-04-30 16:09:56 +0400 Не возможно настроить WiFi интерфейс 2009-08-20 16:57:05 +0400 1 1 4 Development Sisyphus alterator-net-eth unstable all Linux CLOSED FIXED P3 critical --- 19564 1 droid sem aen rider sbolshakov sem vitty zerg qa-sisyphus oldest_to_newest 90522 0 droid 2009-04-30 16:09:56 +0400 Нет возможности настроить WiFi интерфейс, поскольку он представлен в виде bridge. Под именем brwlan0 92280 1 ldv 2009-06-02 01:01:57 +0400 reassign 95688 2 aen 2009-08-05 15:23:23 +0400 Стас, это актуально? 95772 3 inger 2009-08-06 12:05:38 +0400 (В ответ на комментарий №2) > Стас, это актуально? Для десктопа нет. Для сервера видимо да, но вообще говоря модуль alterator-net-wifi надо бы полностью переписывать, а сейчас временно отключить. 96286 4 aen 2009-08-12 22:21:39 +0400 2vitty@: отключите? 96340 5 vitty 2009-08-13 14:29:06 +0400 В сервере я не вижу того, что нужно отключать. Просто у нас сервер без поддержки wifi. 96379 6 aen 2009-08-14 00:16:18 +0400 (В ответ на комментарий №5) > В сервере я не вижу того, что нужно отключать. Просто у нас сервер без > поддержки wifi. Она там нужна? 96380 7 vitty 2009-08-14 00:20:23 +0400 вообще нужна 96385 8 rider 2009-08-14 00:59:30 +0400 нужна конечно. 96386 9 aen 2009-08-14 01:02:29 +0400 (В ответ на комментарий №8) > нужна конечно. Тогда вешайте FR. 96387 10 vitty 2009-08-14 01:09:33 +0400 так эта ошибка для того и висит 96407 11 inger 2009-08-14 11:14:54 +0400 ошибка вообще говоря не на том пакете висит ;) 96410 12 inger 2009-08-14 11:35:30 +0400 Вообще с 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. 96411 13 rider 2009-08-14 11:46:21 +0400 Стас, я на всех своих машинах использую только etcnet, и не наблюдаю никаких проблем с wpa_supplicant и dhcp. Более того - эта связка позволяет делать намного больше, чем networkmanager. Например, у меня автоматически поднимаются/опускаются vpn соединения в зависимости от того, в какой сети я нахожусь. alterator-net-wifi так-же работает отлично. Запуск networkmanager на сервере невозможен. Эта система создана для работы на десктопе, где ей и место. на сервере же в большинстве случаев (если этот сервер не в транспорте) нет необходимости менять точки доступа и иже с ними... Впрочем, даже с учётом необходимости изменения точек доступа, я не вижу никаких серьёзных проблем не добавлять поддержку WiFI для установок серверов. Представьте себе ситуацию, что организация подключается по WiFI к интернету, у нас в районе это сплошь и рядом. Собственно Server 5.0 идеален как раз для таких подключений. 96413 14 inger 2009-08-14 11:55:31 +0400 (В ответ на комментарий №13) > Стас, я на всех своих машинах использую только etcnet, и не наблюдаю никаких > проблем с wpa_supplicant и dhcp. Я верю, что иногда оно работает без race'ов. У меня дома тоже через etcnet работает wireless, но описанные проблемы (два разных wpa_supplicant и пляска вокруг этого) это не отменяет. 96507 15 aen 2009-08-15 16:22:29 +0400 (В ответ на комментарий №13) > Стас, я на всех своих машинах использую только etcnet, и не наблюдаю никаких > проблем с wpa_supplicant и dhcp. Более того - эта связка позволяет делать > намного больше, чем networkmanager. Например, у меня автоматически > поднимаются/опускаются vpn соединения в зависимости от того, в какой сети я > нахожусь. > > alterator-net-wifi так-же работает отлично. То есть у тебя эта бага не воспроизводится? 96509 16 vitty 2009-08-15 16:35:40 +0400 (В ответ на комментарий №15) > То есть у тебя эта бага не воспроизводится? Обсуждаемая здесь бага не может не воспроизводиться т.к. alterator-net-wifi не умеет работать с интерфейсом, если оный заключён в бридж. 96512 17 rider 2009-08-15 16:59:03 +0400 Воспроизводится на сервере. Там странная идея - все интерфейсы пихать в бриджи. Я даже знаю, откуда она взялась, но на мой взгляд эту проблему нужно решать другим способом (а именно - строить бриджи тогда, когда в них есть реальная необходимость). 96513 18 rider 2009-08-15 17:00:25 +0400 (В ответ на комментарий №16) > (В ответ на комментарий №15) > > То есть у тебя эта бага не воспроизводится? > > Обсуждаемая здесь бага не может не воспроизводиться т.к. alterator-net-wifi не > умеет работать с интерфейсом, если оный заключён в бридж. alterator-net-wifi прав - у бриджа нет настроек для WiFI. Они есть у основного интерфейса wlan0 96514 19 aen 2009-08-15 17:10:15 +0400 Меня, собственно, сейчас интересует, что мы делаем к RC, если дата его выхода -- 30 августа. 1. Забиваем на эту багу в RC сервера, оставляя ее решение до релиза. 2. Пробуем сейчас искать приемлемые решения, учитывая сжатые сроки. 96519 20 vitty 2009-08-15 17:32:25 +0400 (В ответ на комментарий №17) > Воспроизводится на сервере. Там странная идея - все интерфейсы пихать в бриджи. > Я даже знаю, откуда она взялась, но на мой взгляд эту проблему нужно решать > другим способом (а именно - строить бриджи тогда, когда в них есть реальная > необходимость). Совершенно неважно в какой момент будет организован бридж. Но как только он будет организован wifi перестанет настраиваться. В этом и состоит данная бага. 96526 21 slazav 2009-08-15 19:24:16 +0400 Как я понял, решили чинить в alterator-net-eth (из которого alterator-net-wifi запускается). А именно, для бриджей определять и отдавать в alterator-net-wifi физический интерфейс, который в этот бридж воткнут (первый из). Ни и заодно, скрывать ссылку на alterator-net-wifi, если интерфейс управляется NM (чтоб не приходилось менять supplicant'ов). Перевешиваю на alterator-net-eth. 96841 22 repository-robot 2009-08-19 16:50:21 +0400 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