27797 2012-10-04 07:54:05 +0400 Не определяет wireless интерфейсы на ядре 3.6. 2012-11-17 00:11:47 +0400 1 1 4 Development Sisyphus etcnet unstable all Linux CLOSED FIXED P3 normal --- 27685 1 iv sem aen aris dd1email evg ldv mike real.altlinux.org rider sem shaba stalker qa-sisyphus oldest_to_newest 133665 0 iv 2012-10-04 07:54:05 +0400 Сейчас etcnet чтобы выяснить, является ли интерфейс беспровдным, ориентируется на наличие каталога /sys/class/net/$iface/wireless [1], которого начиная с ядра 3.6 нет и не будет [2]. В результате, беспроводные интерфейсы, настроенные через etcnet, под ядром 3.6 не работают [3] (используется ядро 3.6.0-un-def-alt1). References: [1] http://git.altlinux.org/gears/e/etcnet.git?p=etcnet.git;a=blob;f=etc/net/scripts/functions-eth;h=d4eecc8c3a9daa14ce7470ad44a4e014f334badf;hb=f5db20291fa2d49730eeccf835c86d46f38be8d4#l34 [2] http://lists.altlinux.org/pipermail/sisyphus/2012-October/358581.html [3] http://lists.altlinux.org/pipermail/sisyphus/2012-October/358580.html 133666 1 iv 2012-10-04 08:04:53 +0400 Сразу дополню, что grep по /proc/net/wireless (такой, как на строке 40) также не работает, так как пока интерфейс не поднят, его в этом файле нет. Сам пока в качестве workaround написал echo $1 | grep -q wlan но наверное можно попробовать и что-то типа iwgetid "$1" &>/dev/null (но не знаю, во всех ли версиях wireless-tools она возвращает правильный код ошибки) 133669 2 evg 2012-10-04 09:57:28 +0400 Насколько я понимаю, апстримом предлагается использовать iw вместо wireless-tools. 133693 3 sem 2012-10-04 19:47:50 +0400 Исправление тут: http://git.altlinux.org/people/sem/packages/?p=etcnet.git;a=shortlog;h=refs/heads/sem Там также фикс коммита e975267b71 и #24637. 133697 4 sbolshakov 2012-10-04 21:04:10 +0400 у меня нет уверенности, что можно всегда полагаться на существование phy80211 -- у кого-нибудь есть под рукой старая карточка вроде ipw2200 ? 133698 5 mike 2012-10-04 21:08:34 +0400 Возможно, ipw2200 найдётся у aris@; у меня в покойном T41, могу выковырять, если будет кому поставить. 133699 6 sem 2012-10-04 22:25:09 +0400 (В ответ на комментарий №4) > у меня нет уверенности, что можно всегда полагаться на существование phy80211 У меня, пожалуй, тоже нет такой уверенности. Есть альтернативная идея, которая мне все больше нравится: выкинуть is_wireless() совсем. Она используется только в 2-х случаях: 1. Определить, надо ли запускать скрипт config-wireless. Причем он запускается и при установленной опции CONFIG_DOT1X, что может быть проблемой при наличии файлов default/{iwconfig,iwpriv}. Это проверка не выглядит обязательной, можно выполнять необходимые действия просто при наличии $MYIFACEDIR/{wpa_supplicant.conf,iwconfig,iwpriv}. Это делает ненужным CONFIG_DOT1X. Также теряется и CONFIG_WIRELESS, но мне не кажется это большой потерей. Осмысленность существования default/{iwconfig,iwpriv}, во всяком случае без $MYIFACEDIR/{iwconfig,iwpriv}, тоже вызывает сомнения. 2. Проверка и ругань при USE_IFPLUGD=yes. Думаю, без этого тоже можно прожить. 133701 7 sem 2012-10-05 03:01:33 +0400 > Также теряется и CONFIG_WIRELESS Хотя нет, это убирать не надо. Опция должна, как и раньше, указывать надо ли вообще пытаться выполнять config-wireless. Может быть полезно устанавливать CONFIG_WIRELESS=no для не-wireless интерфейсов, например, чтобы лишние проверки не выполнялись. 133727 8 sem 2012-10-05 19:17:56 +0400 > Есть альтернативная идея Реализовано и перезапушено туда же. 133728 9 mike 2012-10-05 19:23:20 +0400 (In reply to comment #7) > Может быть полезно устанавливать CONFIG_WIRELESS=no для не-wireless Хм, а почему не CONFIG_WIRELESS=yes для wireless, а предполагать не-wireless? IMHO более разумное предположение, тем более с учётом того, что для wireless потребуется больше настройки. 133733 10 sem 2012-10-05 19:39:35 +0400 (В ответ на комментарий №9) > (In reply to comment #7) > > Может быть полезно устанавливать CONFIG_WIRELESS=no для не-wireless > Хм, а почему не CONFIG_WIRELESS=yes для wireless, а предполагать не-wireless? > IMHO более разумное предположение, тем более с учётом того, что для wireless > потребуется больше настройки. При CONFIG_WIRELESS=yes просто проверяется наличие файлов конфигурации $MYIFACEDIR/{wpa_supplicant.conf,iwconfig,iwpriv} и реальная работа выполняется только если что-то из этого есть. При CONFIG_WIRELESS=no таких проверок производиться не будет и config-wireles запускать не будет точно. На самом деле это не так уж важно, проверки - это быстро. Но если не-wireless интерфейсов вдруг очень много, то может появиться желание их все-таки отключить. 133736 11 real.altlinux.org 2012-10-05 19:41:52 +0400 Коллеги, убедительная просьба потом все подробности во оживлению iwlanX отразить на вики. 133737 12 sem 2012-10-05 19:43:03 +0400 > 2. Проверка и ругань при USE_IFPLUGD=yes. Думаю, без этого тоже можно прожить. Да, забыл сказать, google утверждает, что ifplugd вполне умеет работать с wireless интрфесами (хотя я и не проверял). Так что я просто выкинул проверку. 133740 13 sbolshakov 2012-10-05 21:48:44 +0400 >> 2. Проверка и ругань при USE_IFPLUGD=yes. Думаю, без этого тоже можно прожить. > Да, забыл сказать, google утверждает, что ifplugd вполне умеет работать с > wireless интрфесами (хотя я и не проверял). Так что я просто выкинул проверку. ifplugd с wireless считается неработающим -- в этой багзилле есть тому подтверждения -- поэтому для wireless используется wpa_cli. Хотелось бы также спросить автора alterator-net-eth и компании -- как там собираются выкручиваться, ведь чтобы можно было полагаться исключительно на наличие файликов специального вида, нужно, чтобы их кто-туда изначально положил, правда ? 133741 14 sbolshakov 2012-10-05 21:51:27 +0400 в конце концов, вернуть на место sys/.../wireless -- это один git revert в ядре, тем более что rationale того коммита 'нам кажется, что этим никто не пользуется, поэтому давайте сэкономим 2 килобайта' и ничего более. 133751 15 rider 2012-10-06 07:16:38 +0400 Никто не хочет написать автору коммита, убирающего нужный нам интерфейс ??? 133814 16 sem 2012-10-08 17:47:37 +0400 > ifplugd с wireless считается неработающим -- в этой багзилле есть тому > подтверждения -- поэтому для wireless используется wpa_cli. Тогда можно проверять так же, по наличию файлов конфигурации. > Хотелось бы также спросить автора alterator-net-eth и компании -- как там > собираются выкручиваться При чем тут проблемы альтератора? В альтераторе можно и iw какой-нибудь использовать, там такие зависимости не страшны. Или вообще свою утилиту написать, не суть. А вот etcnet не должен рассчитывать на наличие разных нестандартных (и не всем нужных) утилит. > в конце концов, вернуть на место sys/.../wireless -- это один git revert в > ядре, Только ради этих 2-х проверок в etcnet собирать аж прям специальное ядро? И потом этот патч поддерживать? Причем эти проверки не так уж нужны, получается. Возможно они и раньше были избыточны. Тот, кто настраивает сеть, лучше знает что это за интерфейс и как его конфигурить. К тому же это позволяет избавиться от совершенно лишней опции CONFIG_DOT1X. 134405 17 ldv 2012-11-02 20:35:40 +0400 (In reply to comment #13) > >> 2. Проверка и ругань при USE_IFPLUGD=yes. Думаю, без этого тоже можно прожить. > > > Да, забыл сказать, google утверждает, что ifplugd вполне умеет работать с > > wireless интрфесами (хотя я и не проверял). Так что я просто выкинул проверку. > > ifplugd с wireless считается неработающим -- в этой багзилле есть тому > подтверждения -- поэтому для wireless используется wpa_cli. > Хотелось бы также спросить автора alterator-net-eth и компании -- как там > собираются > выкручиваться, ведь чтобы можно было полагаться исключительно на наличие > файликов > специального вида, нужно, чтобы их кто-туда изначально положил, правда ? Это, все, конечно, интересно, но какое это имеет отношение к решению задачи? Если есть возражения по изменениям в v0.9.10-25-g8da1cc1..v0.9.10-29-gcca8091, то просьба их озвучить. Если нет возражений, то просьба смержить. :) (In reply to comment #14) > в конце концов, вернуть на место sys/.../wireless -- это один git revert в > ядре, > тем более что rationale того коммита 'нам кажется, что этим никто не > пользуется, > поэтому давайте сэкономим 2 килобайта' и ничего более. Давайте мы не будем искусственно ограничивать область применения etcnet. 134537 18 sbolshakov 2012-11-06 14:10:12 +0400 проблема состоит в том, что предлагается включить кумулятивный патч, затрагивающий более того, что необходимо для решения этой конкретной проблемы. 134548 19 sem 2012-11-06 15:20:10 +0400 > проблема состоит в том, что предлагается включить кумулятивный патч, > затрагивающий более того, что необходимо для решения этой конкретной > проблемы. Ок. http://git.altlinux.org/people/sem/packages/?p=etcnet.git;a=shortlog;h=refs/heads/bug27797 Можно еще и два коммита слить в один, если надо. 134552 20 sbolshakov 2012-11-06 15:57:30 +0400 эти два коммита я и имел ввиду, говоря о кумулятивном патче. уж как-нибудь я бы осилил взять их из середины ветки, будь у меня уверенность, что вот именно так и нужно. 134561 21 sem 2012-11-06 16:47:03 +0400 Сложно понять, что при наличии четырех коммитов, два из которых действительно не относятся к этой баге, под словами "кумулятивный патч, затрагивающий более того, что необходимо для решения этой конкретной проблемы" имеются в виду коммиты, напрямую относящиеся к ней. Слил в один и перезапушил. 134569 22 sbolshakov 2012-11-06 17:21:05 +0400 не нужно больше ничего перезапушивать, я перепишу что есть сам. 134570 23 sbolshakov 2012-11-06 17:33:03 +0400 в порядке обсуждения: мне кажется разумным выставить дефолтом CONFIG_WIRELESS=no в /etc/net/ifaces/default/options-eth и сохранить CONFIG_DOT1X там же. напомню, он помечен как config(noreplace), так что существующие настройки останутся работоспособными. Во вновь установленных системах CONFIG_WIRELESS=yes предлагается устанавливать поинтерфейсно, где нужно. 134580 24 sbolshakov 2012-11-06 18:18:37 +0400 ещё подробнее: у нас есть два варианта того, как происходит поднятие интерфейса: немедленный и отложенный, второй реализуется с использованием ifplugd или wpa_cli (но не оба одновременно!). нынешние ручки -- CONFIG_WIRELESS, CONFIG_DOT1X, USE_IFPLUGD -- плохо ложатся на эту схему, поскольку не описывают в точности, какой из вариантов будет выбран, а с исчезновением is_wireless всё стало совсем запутано. 134582 25 sbolshakov 2012-11-06 18:23:28 +0400 если пытаться привести эти ручки к соответствию их подразумеваемому значению, то: USE_IFPLUGD означает ifplugd (тут однозначно) CONFIG_DOT1X означает wpa_supplicant (неважно, wired или wireless) CONFIG_WIRELESS означает что угодно или ничего вообще. 134589 26 sem 2012-11-06 19:03:21 +0400 > CONFIG_DOT1X означает wpa_supplicant (неважно, wired или wireless) > CONFIG_WIRELESS означает что угодно или ничего вообще. Одна из этих опций явно лишняя, т.к. означать они могут только одно и то же. Я в патче решил оставить CONFIG_WIRELESS из тех соображений, что 1. CONFIG_WIRELESS существует гораздо дольше и тут можно считать "так исторически сложилось". К тому же гораздо чаще wpa_supplicant используется все-таки в случае wireless, а не wired конфигурации. 2. Если считать CONFIG_WIRELESS устаревшей, то по уму надо переименовывать и скрипт config-wireless. Но там могут использоваться iwpriv/iwconfig, действительно относящиеся только к wireless. 3. Имя опции CONFIG_DOT1X ничем не лучше CONFIG_WIRELESS. Оно тоже совершенно невразумительное и не отражает сути: во-первых, из него не понять, что речь идет о 802.1X, во-вторых совсем не обязательно, что 802.1X действительно используется, скорее чаще как раз используется wpa-psk. 134592 27 sem 2012-11-06 19:32:57 +0400 (В ответ на комментарий №23) > в порядке обсуждения: мне кажется разумным выставить дефолтом > CONFIG_WIRELESS=no Это экономия только на проверке существования файлов, это действительно так критично? Просто положить wpa_supplicant.conf, чтобы он начал использоваться, мне кажется гораздо привлекательнее варианта прописывания еще и опции в options. 134595 28 repository-robot 2012-11-06 19:43:13 +0400 etcnet-0.9.10-alt7 -> sisyphus: * Tue Nov 06 2012 Sergey Bolshakov <sbolshakov@altlinux> 0.9.10-alt7 - CONFIG_WIRELESS and USE_IFPLUGD options are mutually exclusive now - do not rely on /sys/class/net/<iface>/wireless anymore (closes: #27797) - added per-iface 'disable_ipv6' sysctl shortcut (closes: #27933) - always use 'resolvconf -d' during ifdown (closes: #24637) 134600 29 sbolshakov 2012-11-06 20:55:10 +0400 (В ответ на комментарий №27) > (В ответ на комментарий №23) > > в порядке обсуждения: мне кажется разумным выставить дефолтом > > CONFIG_WIRELESS=no > > Это экономия только на проверке существования файлов, это действительно так > критично? Просто положить wpa_supplicant.conf, чтобы он начал использоваться, > мне кажется гораздо привлекательнее варианта прописывания еще и опции в > options. В последней сборке CONFIG_WIRELESS остался без изменений. Но вообще да, это нежелание проверять существование файла там, где этой проверке не место (ifup-common). 134602 30 sem 2012-11-06 21:48:58 +0400 Я, собственно, делал проверки на существование файлов в ifup-common чтобы не дергать лишний раз скрипт config-wireless. Впрочем, возможно это действительно экономия на спичках. Кстати, без изменения в profiled_filename_is() при выполнении profiled_filename_exist "" "$IFACEDIR/default/iwconfig" может выполняться что-то типа eval =$IFACEDIR/default/iwconfig и будет ругань. 134607 31 sbolshakov 2012-11-06 23:22:49 +0400 (В ответ на комментарий №30) > Я, собственно, делал проверки на существование файлов в ifup-common чтобы не > дергать лишний раз скрипт config-wireless. Впрочем, возможно это действительно > экономия на спичках. > Кстати, без изменения в profiled_filename_is() при выполнении > profiled_filename_exist "" "$IFACEDIR/default/iwconfig" > может выполняться что-то типа eval =$IFACEDIR/default/iwconfig и будет ругань. наверное мне следует просто убрать всякую обработку default/iw* 134913 32 rider 2012-11-16 10:35:48 +0400 А нельзя ли сделать так, что бы вот такого рода конфиги не надо было править: # cat /etc/net/ifaces/eth0/options USE_IFPLUGD=yes LINKDETECT=auto BOOTPROTO=dhcp TYPE=eth DISABLED=no NM_CONTROLLED=no Странным выглядит необходимость прописывания CONFIG_WIRELESS=no если и так уже есть USE_IFPLUGD. 134938 33 sbolshakov 2012-11-16 22:30:31 +0400 отчего же нельзя, очень даже можно: http://comments.gmane.org/gmane.linux.kernel/1392395 134943 34 rider 2012-11-17 00:11:47 +0400 А каким образом wireless интерфейсы имеют отношение к проводным интерфейсам ? или IFPLUG уже научился работать на wireless ?