Summary: | Time to enable wpa_supplicant support | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | Yurix <yurix> | ||||||||||||
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 | ||||||||||||||
Attachments: |
|
Description
Yurix
2005-04-20 12:36:24 MSD
Created attachment 832 [details]
WPA enable patch
> One thing is missing too. config-wireless called for each interface regardless
Разве?
ifup-common:92:is_yes "$CONFIG_WIRELESS" && ExecIfExecutable
$SCRIPTDIR/config-wireless $NAME && print_progress
wpa_supplicant вроде бы обновляется. Тестировать будете, если верну поддержку WPA? С радостью! (In reply to comment #2) > > One thing is missing too. config-wireless called for each interface regardless > Разве? > ifup-common:92:is_yes "$CONFIG_WIRELESS" && ExecIfExecutable > $SCRIPTDIR/config-wireless $NAME && print_progress Я перепроверил -- тут я был не прав. Правда встает другой вопрос -- wpa_supplicant может использоваться теперь и на простом ethernet интерфейсе. Также как и xsupplicant. Возможно, для этих целей завести отдельную опцию, типа USE_AUTH=(wpa|xopen|off-[default]) wpa - для wpa_supplicant xopen - для xsupplicant off - соответственно... WPA тестировать могу, xsupplicant в сизифе нет, но он у меня собран -- тестировать могу только частично. И всё это могу тестировать пока только на WiFi. /etc/net 0.7.3, начинайте тестирование :) Created attachment 840 [details]
WPA patch
1) Следующая конструкция не работает: $WPA_SUPPLICANT -i$NAME ${WPA_DRIVER:?-D$WPA_DRIVER} Тут видимо хотелось чтобы для тех случаев, когда указан WPA_DRIVER, добавить перед ним '-D' и это верно. Однако сама конструкция работает неправильно: Если WPA_DRIVER определен и не нулевой, то используем его, иначе ставим -D. 2) wpa_supplicant требует указывать конфигурационный файл '-c /path/to/cfg' Для хранения предлагается использовать переменную WPA_CONFIG, которую в глобальном файле задефолтить например на /etc/wpa_supplicant.conf 3) wpa_supplicant должен висеть в фоне, для того, чтобы обновлять ключи EAP и т.п. От сюда -- нужно добавить опцию '-B' (In reply to comment #8) > 1) Следующая конструкция не работает: Перепутано ":?" и ":+", исправлено. > 2) wpa_supplicant требует указывать конфигурационный файл '-c /path/to/cfg' > Для хранения предлагается использовать переменную WPA_CONFIG, которую в > глобальном файле задефолтить например на /etc/wpa_supplicant.conf if [ -x "${WPA_SUPPLICANT:=$DEFAULT_WPA_SUPPLICANT}" ]; then local prof_conf=`profiled_filename $MYIFACEDIR/wpa_supplicant.conf` $WPA_SUPPLICANT -B -i$NAME${WPA_DRIVER:+ -D$WPA_DRIVER}${prof_conf:+ -c $prof_conf} fi > 3) wpa_supplicant должен висеть в фоне, для того, чтобы обновлять ключи EAP и > т.п. От сюда -- нужно добавить опцию '-B' Хорошо. (In reply to comment #9) # ifup air ..../etc/net/scripts/config-wireless: line 27: local: can only be used in a function Если убрать local, то работает замечательно! Правда, в расчете на потенциальную необходимость использовать WPA сразу на нескольких интерфейсах, более правильным представляется задействование единого для всех сетей и интерфейсов конфигурационного файла, чтобы использовать алгоритм выбора сети, встроенный в wpa_supplicant. Однако, на данном этапе я не имею возможности протестировать такие конфигурации. По-этому, предлагаю зафиксировать текущее, пусть не идеальное, но вполне работоспособное решение ! И ещё один момент. Вероятно, для тех интерфейсов, которые рождаются с участием неких демонов :) типа pppd, wpa_supplicant, и т.д стоит предусмотреть смерь оных в результате ifdown интерфейса. Например, ловить PID в файл при старте, потом бить по нему при останове соответствующего интерфейса, как это сделано во многих sysv initscripts ? Фиксируем. Для ppp наоборот --- смерть демона инициирует ifdown. wpa_supplicant ближе к zcip/dhcpcd, его наличие влияет только на наличие пакетов, а интерфейс может быть UP. (In reply to comment #11) В реальности при ifdown интерфейса ppp смерти соответствующего pppd почему-то не происходит. По крайней мере у меня дома ifdown ppp0 не убивает pppd, соответственно каждый новый service network restart приводит к появлению ppp1 ppp2 и т.д (я использую pptp tunnel). > Для ppp наоборот --- смерть демона инициирует ifdown. wpa_supplicant ближе к > zcip/dhcpcd, его наличие влияет только на наличие пакетов, а интерфейс может > быть UP. Согласен, однако это также означает, что как максимум (как минимум не знаю --- у нас ведь нет промежуточного состояния между up и down, типа unconf), после свершения ifdown эти демоны должны быть сняты с выполнения. Т.е общее между pppd,wpa_supplicant здесь то, что факт продолжения действия после опускания интерфейса является ошибкой, так как при последующем вызове ifup в случае ppp рождается новый интерфейс, а для wpa_supplicant появляется лишний процесс (точно не знаю -- возможно старый процесс мешает работе вновь поднятого). Предлагаю всёже убивать wpa_supplicant (и pppd) при ifdown Или есть причины, которых я не знаю, но по которым им следует жить после ifdown, хотелось бы их услышать. > В реальности при ifdown интерфейса ppp смерти соответствующего pppd почему-то > не происходит. По крайней мере у меня дома ifdown ppp0 не убивает pppd, У меня происходит, что интересно. > Согласен, однако это также означает, что как максимум (как минимум не знаю --- > у нас ведь нет промежуточного состояния между up и down, типа unconf), после > свершения ifdown эти демоны должны быть сняты с выполнения. Кто оставляет pid-файл --- снимается. wpa_supplicant, к сожалению, не умеет. Какое у нас текущее состояние дел? Хоть что-то работает? (In reply to comment #14) > Какое у нас текущее состояние дел? Хоть что-то работает? etcnet-0.7.3-alt1 Пока нет изменений описанных в коментарии №9 (https://bugzilla.altlinux.org/show_bug.cgi?id=6582#c9) Без этого wpa_supplicant не работает. Простенький патч, с которым wpa работает на моем ноуте прикладиваю (etcnet-0.7.3-alt1-wpa_supplicant.patch) По сравнению с тем, что в коментарии №9 здесь убрано local и добавлена проверка сществования конффайла, без которого запуск также бесмысленен, как и без присутствия бинарника wpa_supplicant. Created attachment 880 [details]
etcnet-0.7.3-alt1-wpa_supplicant
Created attachment 881 [details]
Catch the PID of wpa_supplicant [applied]
Конечно, хотелось бы, чтобы во время опускания интерфейса, опускался также и
процесс wpa_supplicant. Этот патчик создает PID файл. Остается предусматреть
где-нибудь вызов kill `cat /var/run/wpa_supplicant-$NAME.pid` . Попробовал
создать destroy-wireless -- не действует...
> Пока нет изменений описанных в коментарии #8470 Да-да. Забыл. > По сравнению с тем, что в коментарии №9 здесь убрано local и добавлена проверка > сществования конффайла, без которого запуск также бесмысленен, как и без > присутствия бинарника wpa_supplicant. Файл может называться немного по-другому. destroy-wireless должен быть исполняемым. Но правильнее использовать shutdown-wireless, чтобы supplicant уничтожался до расформирования интерфейса. Сделано, смотрите. http://pilot.org.ua/etcnet/files/etcnet-0.7.4-alt0.2.src.rpm http://pilot.org.ua/etcnet/files/etcnet-0.7.4-alt0.2.noarch.rpm (In reply to comment #18) > destroy-wireless должен быть исполняемым. Но правильнее использовать > shutdown-wireless, чтобы supplicant уничтожался до расформирования интерфейса. > http://pilot.org.ua/etcnet/files/etcnet-0.7.4-alt0.2.noarch.rpm Спасибо! Проверил -- теперь интерфейс стартует, однако по какой-то причине не убивает wpa_supplicant после ifdown. Кроме этого, при старте появилась ругань, которой раньше не было (invalid LINKDETECT value). Плюс, я бы всё-же убрал бы сообщения от wpa_supplicant в /dev/null, хотя вероятно они будут видны только при ручном запуске (в смысле при загрузки системы их не будет видно?). Я проверял так: # ifup air ......ERROR: /etc/net/scripts/config-ipv4: invalid LINKDETECT value Trying to associate with 00:0f:a4:8b:ad:81 (SSID='SOME' freq=0 MHz) Associated with 00:0f:a4:8b:ad:81 # ip addr show dev air 5: air: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0e:d5:75:f2:0a brd ff:ff:ff:ff:ff:ff inet 10.2.11.64/24 brd 10.2.11.255 scope global air # pgrep wpa 11050 # ifdown air # pgrep wpa 11050 # ip addr show dev air Device "air" does not exist. # NAME=air /etc/net/scripts/shutdown-wireless # pgrep wpa Только теперь умер. > # NAME=air /etc/net/scripts/shutdown-wireless
Скрипт должен называться shutdown-eth, я правлю. Вывод wpa_supplicant тоже подавлен.
(In reply to comment #20) > > # NAME=air /etc/net/scripts/shutdown-wireless > Скрипт должен называться shutdown-eth, я правлю. Вывод wpa_supplicant тоже подавлен. OK Тоже смотрю: Просмотр ifdown показал, что должен вызываться shutdown-eth, потом destroy-eth Первый не вызывается из-за того, что чуть выше stop_dhcp_client убивает клиента dhcp, который похоже сам делает интевейсу DOWN, а далее в ifdown идет проверка if iface_is_up $NAME; then и естественно пролетает. Так что убивать либо в destroy-eth, либо что-то придумывать. Created attachment 885 [details]
Fix for shutdown scripts not called due to iface has been downed by dhcpcd [applied]
dhcpcd will bring down the interface when stopping. To keep etcnet logics
to work (running shutdown scripts for example) we should bring it up again as
it is for static IPs.
Дело в том, что dhcpcd при выходе снимает IFF_UP с интерфейса. По совести это нужно контролировать флагом командной строки. (In reply to comment #23) > Дело в том, что dhcpcd при выходе снимает IFF_UP с интерфейса. По совести это > нужно контролировать флагом командной строки. Полностью согласен. Порылся в руководстве на dhcpcd -- таких флагов на данный момент нет. Видимо, на данный момент меньшее зло делать UP самим. С wpa_supplicant разобрались? (In reply to comment #25) > С wpa_supplicant разобрались? Похоже что да. К самому функционалу wpa в etcnet вопросов теперь нет. Ну кроме того, что он не снимается из-за dhcpcd... :) Пока закроем... |