Прошу рассмотреть возможность добавить в etcnet создание pppoe соединений с использованием ядерного модуля. В ядре модуль pppoe давно уже есть, плагин в пакете ppp тоже давно наличествует, но фактически не используется. Там нужно-то убрать вызов /usr/sbin/pppoe и добавить в опциях плагин /usr/{lib64|lib}/pppd/{ver.pppd}/rp-pppoe.so Может даже ввести некий переключатель USERSPACE/KERNELSPACE На скоростях более 40М процесс pppoe начинает сильно грузить систему, тогда как в ядерном режиме выжимается все доступные 100М без тормозов.
(В ответ на комментарий №0) > Там нужно-то убрать вызов /usr/sbin/pppoe А как именно? Просто убрать не получается, начинает в терминал плевать. Как ему сказать, куда данные пихать?
/etc/ppp/options.pppoe: noauth noktune #minimum autoincrement pppX name minunit 1 #Options for redial idle 0 maxfail 0 holdoff 5 #Disable ARP proxy and IPX protocol noproxyarp noipx # Turn off compression protocols we know won't be used novj novjccomp nopcomp noaccomp nobsdcomp nodeflate refuse-eap lock nomp lcp-echo-failure 5 lcp-echo-interval 30 ^D [root@metamorph ppp]# pppd file /etc/ppp/options.pppoe noipdefault noauth persist usepeerdns ifname ppp0 -detach plugin /usr/lib64/pppd/2.4.5/rp-pppoe.so dtest1 user _USER_ password _PASSWORD_ Plugin /usr/lib64/pppd/2.4.5/rp-pppoe.so loaded. RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5 Timeout waiting for PADO packets Unable to complete PPPoE Discovery ^C [root@metamorph dummy0]# tcpdump -ni dtest1 tcpdump: WARNING: dtest1: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on dtest1, link-type EN10MB (Ethernet), capture size 65535 bytes 21:29:53.490901 PPPoE PADI [Service-Name] [Host-Uniq 0xAE6E0000] 21:29:58.495935 PPPoE PADI [Service-Name] [Host-Uniq 0xAE6E0000] 21:30:08.504559 PPPoE PADI [Service-Name] [Host-Uniq 0xAE6E0000] 21:30:33.523000 PPPoE PADI [Service-Name] [Host-Uniq 0xAE6E0000] 21:30:38.525129 PPPoE PADI [Service-Name] [Host-Uniq 0xAE6E0000] 21:30:48.531992 PPPoE PADI [Service-Name] [Host-Uniq 0xAE6E0000] ^C То есть параметром вызова плугина rp-pppoe.so является физический интерфейс, на котором надо поднимать исходящее соединение. И что самое важное, такая конструкция работает весьма и весьма надежно. Сейчас в ALT мне приходится обвешиваться pppoe соединение всякими скриптами-ватчдогами, чтобы держать его постоянно активным. С предлагаемой схемой ничего подобного делать не приходится, проверено на почти сотне экземпляров ШПД-роутеров, на которых так сделано.
в чём состоит 'схема' ? можно ли оформить желаемое патчем к etcnet ? pppoe у меня в округе нету, так что не смогу даже проверить.
По идее получается, только create-ppp пропатчить на предмет PTYOPTION= , чтоб было в зависимости от наличия "plugin rp-pppoe.so" в pppoptions
Created attachment 5398 [details] замена pppoe-connect на rp-pppoe.so
(В ответ на комментарий №3) > в чём состоит 'схема' ? можно ли оформить желаемое патчем к etcnet ? > pppoe у меня в округе нету, так что не смогу даже проверить. вот корявый патч, правда он наглухо отрывает /usr/sbin/pppoe и перезаживает на собственный плугин от pppd
Created attachment 5399 [details] create-ppp.patch Все клево, ядреный модуль грузится. Проблема только с наличием плагина. Придется на выбор: - реализовать проверку его наличия - поставить зависимость там же, где на ppp - запаковать в пакет ppp Мне больше последний нравится.
Ну и не знаю, upppoe или pppoed обозвать старый юзерспейсный тип с демоном
А может просто в README добавить пункт, что "если хотите ядреного pppoe, то поставьте пакет ppp-pppoe"? Правда, его по зависимостям вытаскивает NM
(В ответ на комментарий №9) > А может просто в README добавить пункт, что "если хотите ядреного pppoe, то > поставьте пакет ppp-pppoe"? Не смог ответить. Можно я сделаю вид, что не видел этого? ;-) > Правда, его по зависимостям вытаскивает NM NM-то нам зачем для вытягивания плагина?
В общем смысл такой: У меня не было никогда NM и мне он нафиг не нужен. ppp-pppoe у меня не стоял, как оказалось. Я отправляю новый etcnet в p6 и у всех таких как я отваливается pppoe, поэтому решение должно быть надежным. Т.к. проблем с запаковкой в ppp нет вообще никаких и ppp у всей "группы риска" установлен, вижу наилучшее решение в этом.
(В ответ на комментарий №11) > У меня Имеется ввиду на моем реальном домашнем роутере/сервере/помойнике. На днях сгорел ADSL-роутер, поэтому временно взял дешевый для бриджа и появилась возможность проверить.
(В ответ на комментарий №11) > В общем смысл такой: > У меня не было никогда NM и мне он нафиг не нужен. ppp-pppoe у меня не стоял, > как оказалось. > Я отправляю новый etcnet в p6 и у всех таких как я отваливается pppoe, поэтому > решение должно быть надежным. > Т.к. проблем с запаковкой в ppp нет вообще никаких и ppp у всей "группы риска" > установлен, вижу наилучшее решение в этом. Лично у меня против этого решения возражений нет.
(В ответ на комментарий №7) > Все клево, ядреный модуль грузится. "Добавить возможность" и "изменить поведение по умолчанию" - это 2 большие разницы. Может не стоит так вот сразу? И это upppoe мне кажется совершенно неочевидным и излишним. Лучше добавить опцию типа PPPOE_KERNEL_MODE и проверять ее значение. Поведение по умолчанию тогда легко можно будет задавать в /etc/net/ifaces/default/options-ppp, например. И перекрывать при необходимости в конфиге конкретного интерфейса. > Проблема только с наличием плагина. Придется на выбор: > - реализовать проверку его наличия > - поставить зависимость там же, где на ppp > - запаковать в пакет ppp > Мне больше последний нравится. Не вижу особого смысла. Можно просто добавить зависимость в самом пакете etcnet, может потом придумается как сделать не слишком корявую проверку на наличие плагина. И, кстати, этот плагин может потенциально собираться из пакета rp-pppoe. Сейчас это не так (я не разбирался чем эти плагины отличаются), но это может и измениться в будущем. Тогда плагин в составе ppp будет мешать.
(В ответ на комментарий №14) > И, кстати, этот плагин может потенциально собираться из пакета rp-pppoe. Сейчас > это не так (я не разбирался чем эти плагины отличаются), но это может и > измениться в будущем. Тогда плагин в составе ppp будет мешать. Впрочем нет, в сборке обоих плагинов одновременно вряд ли есть какой-то смысл. Но я все равно думаю, что раз уж он отпилен, то не надо его обратно запихивать.
(В ответ на комментарий №14) > "Добавить возможность" и "изменить поведение по умолчанию" - это 2 большие > разницы. Что будет по умолчанию, мне в общем-то не важно. Как мантейнеры etcnet ppp и rp-pppoe решат. > Может не стоит так вот сразу? > И это upppoe мне кажется совершенно неочевидным и излишним. Это лишь костыль, который позже превратится в скрипте в pppoe|upppoe) > Лучше добавить опцию типа PPPOE_KERNEL_MODE и проверять ее значение. > Поведение по умолчанию тогда легко можно будет задавать в > /etc/net/ifaces/default/options-ppp, например. И перекрывать при необходимости > в конфиге конкретного интерфейса. Можно и так. Если возможность переключения оставить надолго. > может потом придумается как сделать не слишком корявую проверку на > наличие плагина. "может" "потом" "корявую"?! Я хочу "точно" "сейчас" "прямую" и решение знаю. > И, кстати, этот плагин может потенциально собираться из пакета rp-pppoe. > Сейчас это не так (я не разбирался чем эти плагины отличаются), но это может и > измениться в будущем. Тогда плагин в составе ppp будет мешать. Да. Тогда зависимость в etcnet.
(В ответ на комментарий №15) > раз уж он отпилен, то не надо его обратно запихивать. Зависимость в etcnet меня устроит
2 Sem: Кстати, а NM случайно не ядреный pppoe использует?
я предпочёл бы, чтобы плагин находился в пакете ppp -- когда и если там появится своё, можно будет выпилить обратно. зависимость же на ppp-pppoe в etcnet я ставить не хотел бы -- это ppp'шные дела, пусть внутри себя разбираются. Кроме того, там и без того предостаточно зависимостей, и я хотел бы этот список сократить, а не расширить. Касательно upppoe/kpppoe -- не стоит усложнять сверх меры и это место, можем/умеем через ядро -- значит через ядро, нету в ядре -- откатываемся на старый способ, не теребя при этом пользователя. Особо умные заблэклистят модуль, если им это зачем-то занадобится.
Вот не надо лишних зависимостей у etcnet. ppp (а тем более pppoe) нужен не всем и не всегда.
(В ответ на комментарий №19) > я предпочёл бы, чтобы плагин находился в пакете ppp +1 > Касательно upppoe/kpppoe -- не стоит усложнять сверх меры и это > место, можем/умеем через ядро -- значит через ядро, нету в ядре -- > откатываемся на старый способ, не теребя при этом пользователя. Тогда с тебя проверку наличия %_libdir/pppd/*/rp-pppoe.so придумать
проверку наличия /bin/ls не желаете ? rp-pppoe считается существующим, если существует -x "${PPPD:=$DEFAULT_PPPD}"
(В ответ на комментарий №22) > проверку наличия /bin/ls не желаете ? > rp-pppoe считается существующим, если существует > -x "${PPPD:=$DEFAULT_PPPD}" > если там появится своё, можно будет выпилить обратно и она перестанет работать
(В ответ на комментарий №18) > 2 Sem: > Кстати, а NM случайно не ядреный pppoe использует? Да, ядерный.
(В ответ на комментарий №24) > Да, ядерный. Дык! Протестирован, значит -- можно по умолчанию.
Created attachment 5404 [details] create-ppp.patch 1. тогда патч такой 2. в ppp добавить зависимость на ppp-pppoe 3. в ppp-pppoe убрать зависимость на ppp
(В ответ на комментарий №19) > я предпочёл бы, чтобы плагин находился в пакете ppp -- когда и если > там появится своё, можно будет выпилить обратно. Ну, вообще зависимость в etcnet почти равнозначна добавлению в ppp, в том смысле, что плагин все равно приедет ко всем. Но в случае изменения расположения плагина иметь дело с отдельным пакетом будет проще, если пакет с плагином начнет собираться из rp-pppoe, то он либо будет называться так же, либо будет иметь соответствующий provide. В случае зависимости в etcnet ничего менять уже не придется, иначе в etcnet все равно придется добавлять зависимость. > зависимость же на ppp-pppoe в etcnet я ставить не хотел бы -- > это ppp'шные дела, пусть внутри себя разбираются. Это не так. Если etcnet использует этот функционал, значит обеспечить наличие необходимых пакетов - его задача. > там и без того предостаточно зависимостей, и я хотел бы этот список > сократить, а не расширить. Не бывает "слишком много" зависимостей, бывают "излишние". И их, конечно, надо убирать. > Касательно upppoe/kpppoe -- не стоит усложнять сверх меры и это > место, можем/умеем через ядро -- значит через ядро, нету в ядре -- > откатываемся на старый способ, не теребя при этом пользователя. Т.е. всегда пытаться сначала использовать kernel, если ошибка при старте pppd - userspace? Можно и так, хотя я все равно предлагаю добавить опцию для управления этим поведением, чтобы избежать лишних телодвижений и дать возможность явно этим управлять. Лучше иметь возможность делать это в конфигах etcnet, чем блэклистить модули. Тогда что-то типа PPPOE_TYPE=kernel|userspace|auto с умолчанием в auto. Примерный патч я могу нарисовать, если кто-нибудь проверит, у меня сейчас тоже нет возможности проверять pppoe.
(В ответ на комментарий №27) > Примерный патч я могу нарисовать, если кто-нибудь проверит, у меня сейчас тоже > нет возможности проверять pppoe. Я могу проверить, как заинтересованное лицо.
Да уже все проверено давно. Выкидывайте к чертовой бабушке pppoed и поставьте зависимость в ppp на ppp-pppoe. Это все.
(В ответ на комментарий №26) > 2. в ppp добавить зависимость на ppp-pppoe > 3. в ppp-pppoe убрать зависимость на ppp Это, мягко выражаясь, нелогично. Это ppp-pppoe использует ppp, а не наоборот.
(В ответ на комментарий №30) > Это, мягко выражаясь, нелогично. Это ppp-pppoe использует ppp, а не наоборот. Использует, мягко выражаясь, наоборот, но нелогично делать в etcnet зависимость, которая там просто не нужна совсем.
зависимости на ppp в etcnet нету, и тем более там не будет зависимости на rp-pppoe. отслеживать расположение плагина pppoe -- задача ppp, а не etcnet.
(В ответ на комментарий №31) > (В ответ на комментарий №30) > > Это, мягко выражаясь, нелогично. Это ppp-pppoe использует ppp, а не наоборот. > Использует, мягко выражаясь, наоборот, Для нормально работы ppp пакет ppp-pppoe не нужен. Для того, чтобы работал функционал пакета ppp-pppoe - ppp нужен. > но нелогично делать в etcnet > зависимость, которая там просто не нужна совсем. Если etcnet использует ppp-pppoe в обязательном порядки и pppoe без этого работать не будет, то зависимость нужна. Если это опционально, и pppoe в etcnet может работать без пакета ppp-pppoe с настройками по умолчанию, то зависимость не нужна.
(In reply to comment #32) > зависимости на ppp в etcnet нету, и тем более там не будет зависимости на > rp-pppoe. отслеживать расположение плагина pppoe -- задача ppp, а не etcnet. Вроде бы очевидные вещи, но все же: 1. Местоположение плагинов для ppp и так уже давно фиксировано. 2. Пакет ppp не должен зависеть от пакетов-плагинов для ppp, поскольку он может работать и без этих плагинов. 3. Пакеты-плагины для ppp должны зависеть от пакета ppp, поскольку без ppp эти плагины не имеют смысла.
(В ответ на комментарий №34) > 2. Пакет ppp не должен зависеть от пакетов-плагинов для ppp > поскольку он может работать и без этих плагинов. Тогда нужно убрать из пакета ppp все плагины, без которых он может работатью Ок? ;-)
(В ответ на комментарий №32) > зависимости на ppp в etcnet нету, и тем более там не будет зависимости на > rp-pppoe. А, тогда да, зависимость на pppoe будет выглядеть странно. > отслеживать расположение плагина pppoe -- задача ppp, а не etcnet. Нет, это все равно не его проблемы. Для ppp как такого абсолютно не нужен pppoe, это дополнительный функционал, далеко не всем нужный. Но я думаю, что попытка запуска pppd - это вполне достаточная проверка. Если плагина нет (или модуля нет/заблэклистен), то сообщение об ошибке от pppd будет вполне достаточно. Можно дополнительно советовать пользователю поставить необходимый пакет.
(В ответ на комментарий №34) > 3. Пакеты-плагины для ppp должны зависеть от пакета ppp, поскольку без ppp эти > плагины не имеют смысла. Имеют. Их не нужно устанавливать и втыкать на каждый зависимости. Они же сами ничего не тащат.
(В ответ на комментарий №35) > > 2. Пакет ppp не должен зависеть от пакетов-плагинов для ppp > > поскольку он может работать и без этих плагинов. > Тогда нужно убрать из пакета ppp все плагины, без которых он может работатью > Ок? ;-) Это можно конечно, если в этом есть какой-то смысл. В случае плагина pppoe такой смысл есть - потенциальная возможность его сборки из другого пакета.
(В ответ на комментарий №38) > В случае плагина pppoe > такой смысл есть - потенциальная возможность его сборки из другого пакета. Молодец! Зависимость только не забудьте поставь на него в ppp.
> Но я думаю, что попытка запуска pppd - это вполне достаточная проверка. Если > плагина нет (или модуля нет/заблэклистен), то сообщение об ошибке от pppd будет > вполне достаточно. Можно дополнительно советовать пользователю поставить > необходимый пакет. Извините, так дело не пойдёт. Из-за 30-ти килобайтного бинаря с нулевыми внешними зависимостями предлагается парсить вывод pppd, с тем, чтобы дать совет пользователю доустановить эти 30 килобайт ? Да вы^W^W Неразумно.
Мои пять копеек: 1) если и менять зависимость на *pppoe*, то в etcnet-full; 2) если и добавлять зависимость на ppp-pppoe, то IMHO в какой ppp-full (детали в bug #27108); 3) pppoe.ko наблюдается во всех ядрах из sisyphus/p6, кроме ltsp-client; 4) фолбэк с ядерного на юзерспейный pppoe был бы идеален, чтоб пользователи по возможности получали шустрый вариант сразу; 5) кажется, простейший тест -- modprobe pppoe && [ -d /sys/module/pppoe ]
(В ответ на комментарий №40) > Из-за 30-ти килобайтного бинаря с нулевыми внешними зависимостями > предлагается парсить вывод pppd, с тем, чтобы дать совет пользователю > доустановить эти 30 килобайт ? Да вы^W^W Неразумно. Это не я предложил автоматически определять, что использовать, kernelspace или usrspace. Можно пытаться определить наличие плагина, что неудобно из-за версии ppp в пути. И этого может быть недостаточно, возможно нужно еще определять и наличие самого модуля для текущего ядра. Я изначально предлагал простую опцию. Предлагаю еще раз, и предлагаю считать, что проверка наличия плагина - не проблема etcnet. В случае, если в настройках будет стоять kernelspace, но запуск pppd завершится неудачно, можно предположить, что нет плагина и выдать подсказку пользователю - проверить, стоит ли соответствующий пакет. Ну а что включать по умолчанию, kernelspace или usrspace - это отдельный вопрос. Если с ядерным модулем все так хорошо, то возможно его можно включить и по умолчанию. Наличие же пакета с плагином в дистрибутивах - это уже ответственность RM.
(В ответ на комментарий №41) > Мои пять копеек: > 1) если и менять зависимость на *pppoe*, то в etcnet-full; Он нафиг не нужен. Как минимум, с p5 его все пользователи NM тестируют. > 2) если и добавлять зависимость на ppp-pppoe, то IMHO в какой ppp-full > (детали в bug #27108); См. comment #35 > 3) pppoe.ko наблюдается во всех ядрах из sisyphus/p6, кроме ltsp-client; И в p5 тоже > 4) фолбэк с ядерного на юзерспейный pppoe был бы идеален, чтоб пользователи > по возможности получали шустрый вариант сразу; Юзерспейный нафиг не нужен. Как минимум, с p5 его все пользователи NM тестируют. > 5) кажется, простейший тест -- modprobe pppoe && [ -d /sys/module/pppoe ] || apt-get install rp-pppoe для полного счастья
(В ответ на комментарий №42) > Наличие же пакета с плагином в дистрибутивах - это уже ответственность RM. Это уже перевод стрелок.
Я тут посмотрел, как идут дела у проектов ppp и rp-pppoe. У меня сложилось впечатление, что rp-pppoe с 2008-го года задвинут в пыльный угол. в ppp хоть какие-то движения наблюдаются. Это со стороны клиентской части. Серверная же часть rp-pppoe в современных реалиях ниже любой критики. Поэтому я бы не стал рассчитывать на появление pppoe плугина со стороны проекта rp-pppoe. Может все-таки собрать плугин в составе пакета ppp?
(В ответ на комментарий №45) > Может все-таки собрать плугин в составе пакета ppp? Да, но только отдельно, с зависимостью на него в ppp, чтоб можно было подменить.
Применительно к /etc/net и pppoe -- рассказали тут: <sfstudio> Ну запомнишь, просто потом забудется Позвонить без всяких pppoed и прочего чисто pppd+плагин https://gitorious.org/wive-rtnl-ralink-rt305x-routers-firmware/wive-rtnl-ralink-rt305x-routers-firmware/blobs/master/etc/scripts/config-pppoe.sh на логику работы с nvram внимания не обращаем ибо это для встройки. Но общий принцип понятен. (In reply to comment #45) > [...] на появление pppoe плугина со стороны проекта rp-pppoe. И сюда ремарка: <sfstudio> у них в составе rp-pppoe идёт плагин и он свежее того что в pppd, более того в моём гите есть ещё стопка дополнительных фиксов на тему pppoe/l2tp плагинов. И корректный pptp плагин.
Ну что ж, давайте теперь сюда всего и побольше напишем, чтоб всем остальным менее понятно было. Например, я на этих выходних купил wifi-роутер (больше не тестирую никаких наших pppoe), установив туда dd-wrt. Так вот, даже в нем ядреный pppoe используется.
Уважаемые, я три раза прочитал ветку, но так и не понял, на чем остановились-то? И как мне, пользуясь патчем перевести роутер на ядерный pppoe? Извините за глупость!
(В ответ на комментарий №49) > Уважаемые, я три раза прочитал ветку, но так и не понял, на чем > остановились-то? На старте. > И как мне, пользуясь патчем перевести роутер на ядерный pppoe? Применить патч.
etcnet > 0.9.10-alt16
Для обновляющихся: не забудьте установить пакет ppp-pppoe. P.S. баг #27108 стоит в зависимостях, если кто не заметил.
