26890 2012-02-03 23:33:45 +0400 Добавить возможность работы pppoe через ядерный модуль 2015-02-11 11:12:10 +0300 1 1 4 Development Sisyphus etcnet unstable all Linux CLOSED FIXED P3 enhancement --- 27108 30721 1 taf sem andrey anubix boyarsh ldv mike mithraen rider sem shaba vvk zerg qa-sisyphus oldest_to_newest 128696 0 taf 2012-02-03 23:33:45 +0400 Прошу рассмотреть возможность добавить в etcnet создание pppoe соединений с использованием ядерного модуля. В ядре модуль pppoe давно уже есть, плагин в пакете ppp тоже давно наличествует, но фактически не используется. Там нужно-то убрать вызов /usr/sbin/pppoe и добавить в опциях плагин /usr/{lib64|lib}/pppd/{ver.pppd}/rp-pppoe.so Может даже ввести некий переключатель USERSPACE/KERNELSPACE На скоростях более 40М процесс pppoe начинает сильно грузить систему, тогда как в ядерном режиме выжимается все доступные 100М без тормозов. 129972 1 zerg 2012-03-22 16:16:42 +0400 (В ответ на комментарий №0) > Там нужно-то убрать вызов /usr/sbin/pppoe А как именно? Просто убрать не получается, начинает в терминал плевать. Как ему сказать, куда данные пихать? 129975 2 taf 2012-03-22 16:37:28 +0400 /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 соединение всякими скриптами-ватчдогами, чтобы держать его постоянно активным. С предлагаемой схемой ничего подобного делать не приходится, проверено на почти сотне экземпляров ШПД-роутеров, на которых так сделано. 129976 3 sbolshakov 2012-03-22 16:55:01 +0400 в чём состоит 'схема' ? можно ли оформить желаемое патчем к etcnet ? pppoe у меня в округе нету, так что не смогу даже проверить. 129977 4 zerg 2012-03-22 17:04:47 +0400 По идее получается, только create-ppp пропатчить на предмет PTYOPTION= , чтоб было в зависимости от наличия "plugin rp-pppoe.so" в pppoptions 129978 5 5398 taf 2012-03-22 17:26:12 +0400 Created attachment 5398 замена pppoe-connect на rp-pppoe.so 129979 6 taf 2012-03-22 17:27:55 +0400 (В ответ на комментарий №3) > в чём состоит 'схема' ? можно ли оформить желаемое патчем к etcnet ? > pppoe у меня в округе нету, так что не смогу даже проверить. вот корявый патч, правда он наглухо отрывает /usr/sbin/pppoe и перезаживает на собственный плугин от pppd 129983 7 5399 anubix 2012-03-22 19:19:12 +0400 Created attachment 5399 create-ppp.patch Все клево, ядреный модуль грузится. Проблема только с наличием плагина. Придется на выбор: - реализовать проверку его наличия - поставить зависимость там же, где на ppp - запаковать в пакет ppp Мне больше последний нравится. 129984 8 anubix 2012-03-22 19:20:59 +0400 Ну и не знаю, upppoe или pppoed обозвать старый юзерспейсный тип с демоном 129985 9 taf 2012-03-22 19:30:29 +0400 А может просто в README добавить пункт, что "если хотите ядреного pppoe, то поставьте пакет ppp-pppoe"? Правда, его по зависимостям вытаскивает NM 129986 10 anubix 2012-03-22 19:55:53 +0400 (В ответ на комментарий №9) > А может просто в README добавить пункт, что "если хотите ядреного pppoe, то > поставьте пакет ppp-pppoe"? Не смог ответить. Можно я сделаю вид, что не видел этого? ;-) > Правда, его по зависимостям вытаскивает NM NM-то нам зачем для вытягивания плагина? 129987 11 anubix 2012-03-22 20:07:28 +0400 В общем смысл такой: У меня не было никогда NM и мне он нафиг не нужен. ppp-pppoe у меня не стоял, как оказалось. Я отправляю новый etcnet в p6 и у всех таких как я отваливается pppoe, поэтому решение должно быть надежным. Т.к. проблем с запаковкой в ppp нет вообще никаких и ppp у всей "группы риска" установлен, вижу наилучшее решение в этом. 129988 12 anubix 2012-03-22 20:11:22 +0400 (В ответ на комментарий №11) > У меня Имеется ввиду на моем реальном домашнем роутере/сервере/помойнике. На днях сгорел ADSL-роутер, поэтому временно взял дешевый для бриджа и появилась возможность проверить. 129989 13 taf 2012-03-22 20:16:11 +0400 (В ответ на комментарий №11) > В общем смысл такой: > У меня не было никогда NM и мне он нафиг не нужен. ppp-pppoe у меня не стоял, > как оказалось. > Я отправляю новый etcnet в p6 и у всех таких как я отваливается pppoe, поэтому > решение должно быть надежным. > Т.к. проблем с запаковкой в ppp нет вообще никаких и ppp у всей "группы риска" > установлен, вижу наилучшее решение в этом. Лично у меня против этого решения возражений нет. 129991 14 sem 2012-03-22 20:40:07 +0400 (В ответ на комментарий №7) > Все клево, ядреный модуль грузится. "Добавить возможность" и "изменить поведение по умолчанию" - это 2 большие разницы. Может не стоит так вот сразу? И это upppoe мне кажется совершенно неочевидным и излишним. Лучше добавить опцию типа PPPOE_KERNEL_MODE и проверять ее значение. Поведение по умолчанию тогда легко можно будет задавать в /etc/net/ifaces/default/options-ppp, например. И перекрывать при необходимости в конфиге конкретного интерфейса. > Проблема только с наличием плагина. Придется на выбор: > - реализовать проверку его наличия > - поставить зависимость там же, где на ppp > - запаковать в пакет ppp > Мне больше последний нравится. Не вижу особого смысла. Можно просто добавить зависимость в самом пакете etcnet, может потом придумается как сделать не слишком корявую проверку на наличие плагина. И, кстати, этот плагин может потенциально собираться из пакета rp-pppoe. Сейчас это не так (я не разбирался чем эти плагины отличаются), но это может и измениться в будущем. Тогда плагин в составе ppp будет мешать. 129992 15 sem 2012-03-22 20:49:51 +0400 (В ответ на комментарий №14) > И, кстати, этот плагин может потенциально собираться из пакета rp-pppoe. Сейчас > это не так (я не разбирался чем эти плагины отличаются), но это может и > измениться в будущем. Тогда плагин в составе ppp будет мешать. Впрочем нет, в сборке обоих плагинов одновременно вряд ли есть какой-то смысл. Но я все равно думаю, что раз уж он отпилен, то не надо его обратно запихивать. 129994 16 anubix 2012-03-22 21:07:20 +0400 (В ответ на комментарий №14) > "Добавить возможность" и "изменить поведение по умолчанию" - это 2 большие > разницы. Что будет по умолчанию, мне в общем-то не важно. Как мантейнеры etcnet ppp и rp-pppoe решат. > Может не стоит так вот сразу? > И это upppoe мне кажется совершенно неочевидным и излишним. Это лишь костыль, который позже превратится в скрипте в pppoe|upppoe) > Лучше добавить опцию типа PPPOE_KERNEL_MODE и проверять ее значение. > Поведение по умолчанию тогда легко можно будет задавать в > /etc/net/ifaces/default/options-ppp, например. И перекрывать при необходимости > в конфиге конкретного интерфейса. Можно и так. Если возможность переключения оставить надолго. > может потом придумается как сделать не слишком корявую проверку на > наличие плагина. "может" "потом" "корявую"?! Я хочу "точно" "сейчас" "прямую" и решение знаю. > И, кстати, этот плагин может потенциально собираться из пакета rp-pppoe. > Сейчас это не так (я не разбирался чем эти плагины отличаются), но это может и > измениться в будущем. Тогда плагин в составе ppp будет мешать. Да. Тогда зависимость в etcnet. 129995 17 anubix 2012-03-22 21:08:07 +0400 (В ответ на комментарий №15) > раз уж он отпилен, то не надо его обратно запихивать. Зависимость в etcnet меня устроит 129999 18 anubix 2012-03-22 22:26:44 +0400 2 Sem: Кстати, а NM случайно не ядреный pppoe использует? 130002 19 sbolshakov 2012-03-23 00:25:45 +0400 я предпочёл бы, чтобы плагин находился в пакете ppp -- когда и если там появится своё, можно будет выпилить обратно. зависимость же на ppp-pppoe в etcnet я ставить не хотел бы -- это ppp'шные дела, пусть внутри себя разбираются. Кроме того, там и без того предостаточно зависимостей, и я хотел бы этот список сократить, а не расширить. Касательно upppoe/kpppoe -- не стоит усложнять сверх меры и это место, можем/умеем через ядро -- значит через ядро, нету в ядре -- откатываемся на старый способ, не теребя при этом пользователя. Особо умные заблэклистят модуль, если им это зачем-то занадобится. 130007 20 mithraen 2012-03-23 08:19:54 +0400 Вот не надо лишних зависимостей у etcnet. ppp (а тем более pppoe) нужен не всем и не всегда. 130019 21 anubix 2012-03-23 12:48:21 +0400 (В ответ на комментарий №19) > я предпочёл бы, чтобы плагин находился в пакете ppp +1 > Касательно upppoe/kpppoe -- не стоит усложнять сверх меры и это > место, можем/умеем через ядро -- значит через ядро, нету в ядре -- > откатываемся на старый способ, не теребя при этом пользователя. Тогда с тебя проверку наличия %_libdir/pppd/*/rp-pppoe.so придумать 130023 22 sbolshakov 2012-03-23 14:19:06 +0400 проверку наличия /bin/ls не желаете ? rp-pppoe считается существующим, если существует -x "${PPPD:=$DEFAULT_PPPD}" 130024 23 zerg 2012-03-23 14:28:42 +0400 (В ответ на комментарий №22) > проверку наличия /bin/ls не желаете ? > rp-pppoe считается существующим, если существует > -x "${PPPD:=$DEFAULT_PPPD}" > если там появится своё, можно будет выпилить обратно и она перестанет работать 130040 24 sem 2012-03-23 16:40:34 +0400 (В ответ на комментарий №18) > 2 Sem: > Кстати, а NM случайно не ядреный pppoe использует? Да, ядерный. 130042 25 zerg 2012-03-23 16:51:03 +0400 (В ответ на комментарий №24) > Да, ядерный. Дык! Протестирован, значит -- можно по умолчанию. 130043 26 5404 zerg 2012-03-23 17:10:52 +0400 Created attachment 5404 create-ppp.patch 1. тогда патч такой 2. в ppp добавить зависимость на ppp-pppoe 3. в ppp-pppoe убрать зависимость на ppp 130047 27 sem 2012-03-23 17:20:23 +0400 (В ответ на комментарий №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. 130048 28 taf 2012-03-23 17:24:31 +0400 (В ответ на комментарий №27) > Примерный патч я могу нарисовать, если кто-нибудь проверит, у меня сейчас тоже > нет возможности проверять pppoe. Я могу проверить, как заинтересованное лицо. 130050 29 zerg 2012-03-23 17:29:27 +0400 Да уже все проверено давно. Выкидывайте к чертовой бабушке pppoed и поставьте зависимость в ppp на ppp-pppoe. Это все. 130051 30 sem 2012-03-23 17:38:40 +0400 (В ответ на комментарий №26) > 2. в ppp добавить зависимость на ppp-pppoe > 3. в ppp-pppoe убрать зависимость на ppp Это, мягко выражаясь, нелогично. Это ppp-pppoe использует ppp, а не наоборот. 130053 31 zerg 2012-03-23 17:45:30 +0400 (В ответ на комментарий №30) > Это, мягко выражаясь, нелогично. Это ppp-pppoe использует ppp, а не наоборот. Использует, мягко выражаясь, наоборот, но нелогично делать в etcnet зависимость, которая там просто не нужна совсем. 130054 32 sbolshakov 2012-03-23 17:52:12 +0400 зависимости на ppp в etcnet нету, и тем более там не будет зависимости на rp-pppoe. отслеживать расположение плагина pppoe -- задача ppp, а не etcnet. 130055 33 sem 2012-03-23 17:56:51 +0400 (В ответ на комментарий №31) > (В ответ на комментарий №30) > > Это, мягко выражаясь, нелогично. Это ppp-pppoe использует ppp, а не наоборот. > Использует, мягко выражаясь, наоборот, Для нормально работы ppp пакет ppp-pppoe не нужен. Для того, чтобы работал функционал пакета ppp-pppoe - ppp нужен. > но нелогично делать в etcnet > зависимость, которая там просто не нужна совсем. Если etcnet использует ppp-pppoe в обязательном порядки и pppoe без этого работать не будет, то зависимость нужна. Если это опционально, и pppoe в etcnet может работать без пакета ppp-pppoe с настройками по умолчанию, то зависимость не нужна. 130056 34 ldv 2012-03-23 17:58:10 +0400 (In reply to comment #32) > зависимости на ppp в etcnet нету, и тем более там не будет зависимости на > rp-pppoe. отслеживать расположение плагина pppoe -- задача ppp, а не etcnet. Вроде бы очевидные вещи, но все же: 1. Местоположение плагинов для ppp и так уже давно фиксировано. 2. Пакет ppp не должен зависеть от пакетов-плагинов для ppp, поскольку он может работать и без этих плагинов. 3. Пакеты-плагины для ppp должны зависеть от пакета ppp, поскольку без ppp эти плагины не имеют смысла. 130057 35 zerg 2012-03-23 18:03:41 +0400 (В ответ на комментарий №34) > 2. Пакет ppp не должен зависеть от пакетов-плагинов для ppp > поскольку он может работать и без этих плагинов. Тогда нужно убрать из пакета ppp все плагины, без которых он может работатью Ок? ;-) 130058 36 sem 2012-03-23 18:05:06 +0400 (В ответ на комментарий №32) > зависимости на ppp в etcnet нету, и тем более там не будет зависимости на > rp-pppoe. А, тогда да, зависимость на pppoe будет выглядеть странно. > отслеживать расположение плагина pppoe -- задача ppp, а не etcnet. Нет, это все равно не его проблемы. Для ppp как такого абсолютно не нужен pppoe, это дополнительный функционал, далеко не всем нужный. Но я думаю, что попытка запуска pppd - это вполне достаточная проверка. Если плагина нет (или модуля нет/заблэклистен), то сообщение об ошибке от pppd будет вполне достаточно. Можно дополнительно советовать пользователю поставить необходимый пакет. 130059 37 zerg 2012-03-23 18:05:40 +0400 (В ответ на комментарий №34) > 3. Пакеты-плагины для ppp должны зависеть от пакета ppp, поскольку без ppp эти > плагины не имеют смысла. Имеют. Их не нужно устанавливать и втыкать на каждый зависимости. Они же сами ничего не тащат. 130060 38 sem 2012-03-23 18:08:48 +0400 (В ответ на комментарий №35) > > 2. Пакет ppp не должен зависеть от пакетов-плагинов для ppp > > поскольку он может работать и без этих плагинов. > Тогда нужно убрать из пакета ppp все плагины, без которых он может работатью > Ок? ;-) Это можно конечно, если в этом есть какой-то смысл. В случае плагина pppoe такой смысл есть - потенциальная возможность его сборки из другого пакета. 130061 39 zerg 2012-03-23 18:12:03 +0400 (В ответ на комментарий №38) > В случае плагина pppoe > такой смысл есть - потенциальная возможность его сборки из другого пакета. Молодец! Зависимость только не забудьте поставь на него в ppp. 130062 40 sbolshakov 2012-03-23 18:13:26 +0400 > Но я думаю, что попытка запуска pppd - это вполне достаточная проверка. Если > плагина нет (или модуля нет/заблэклистен), то сообщение об ошибке от pppd будет > вполне достаточно. Можно дополнительно советовать пользователю поставить > необходимый пакет. Извините, так дело не пойдёт. Из-за 30-ти килобайтного бинаря с нулевыми внешними зависимостями предлагается парсить вывод pppd, с тем, чтобы дать совет пользователю доустановить эти 30 килобайт ? Да вы^W^W Неразумно. 130066 41 mike 2012-03-23 18:43:36 +0400 Мои пять копеек: 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 ] 130069 42 sem 2012-03-23 18:49:25 +0400 (В ответ на комментарий №40) > Из-за 30-ти килобайтного бинаря с нулевыми внешними зависимостями > предлагается парсить вывод pppd, с тем, чтобы дать совет пользователю > доустановить эти 30 килобайт ? Да вы^W^W Неразумно. Это не я предложил автоматически определять, что использовать, kernelspace или usrspace. Можно пытаться определить наличие плагина, что неудобно из-за версии ppp в пути. И этого может быть недостаточно, возможно нужно еще определять и наличие самого модуля для текущего ядра. Я изначально предлагал простую опцию. Предлагаю еще раз, и предлагаю считать, что проверка наличия плагина - не проблема etcnet. В случае, если в настройках будет стоять kernelspace, но запуск pppd завершится неудачно, можно предположить, что нет плагина и выдать подсказку пользователю - проверить, стоит ли соответствующий пакет. Ну а что включать по умолчанию, kernelspace или usrspace - это отдельный вопрос. Если с ядерным модулем все так хорошо, то возможно его можно включить и по умолчанию. Наличие же пакета с плагином в дистрибутивах - это уже ответственность RM. 130070 43 zerg 2012-03-23 18:56:26 +0400 (В ответ на комментарий №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 для полного счастья 130071 44 zerg 2012-03-23 18:59:00 +0400 (В ответ на комментарий №42) > Наличие же пакета с плагином в дистрибутивах - это уже ответственность RM. Это уже перевод стрелок. 130075 45 taf 2012-03-23 19:43:16 +0400 Я тут посмотрел, как идут дела у проектов ppp и rp-pppoe. У меня сложилось впечатление, что rp-pppoe с 2008-го года задвинут в пыльный угол. в ppp хоть какие-то движения наблюдаются. Это со стороны клиентской части. Серверная же часть rp-pppoe в современных реалиях ниже любой критики. Поэтому я бы не стал рассчитывать на появление pppoe плугина со стороны проекта rp-pppoe. Может все-таки собрать плугин в составе пакета ppp? 130087 46 anubix 2012-03-24 15:25:29 +0400 (В ответ на комментарий №45) > Может все-таки собрать плугин в составе пакета ppp? Да, но только отдельно, с зависимостью на него в ppp, чтоб можно было подменить. 130092 47 mike 2012-03-24 17:28:17 +0400 Применительно к /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 плагин. 130142 48 zerg 2012-03-26 14:30:47 +0400 Ну что ж, давайте теперь сюда всего и побольше напишем, чтоб всем остальным менее понятно было. Например, я на этих выходних купил wifi-роутер (больше не тестирую никаких наших pppoe), установив туда dd-wrt. Так вот, даже в нем ядреный pppoe используется. 134238 49 andrey 2012-10-27 15:45:01 +0400 Уважаемые, я три раза прочитал ветку, но так и не понял, на чем остановились-то? И как мне, пользуясь патчем перевести роутер на ядерный pppoe? Извините за глупость! 134283 50 zerg 2012-10-29 16:55:05 +0400 (В ответ на комментарий №49) > Уважаемые, я три раза прочитал ветку, но так и не понял, на чем > остановились-то? На старте. > И как мне, пользуясь патчем перевести роутер на ядерный pppoe? Применить патч. 149404 51 anubix 2014-12-22 11:51:22 +0300 etcnet > 0.9.10-alt16 150096 52 zerg 2015-02-09 17:45:32 +0300 Для обновляющихся: не забудьте установить пакет ppp-pppoe. P.S. баг #27108 стоит в зависимостях, если кто не заметил. 5398 2012-03-22 17:26:12 +0400 2012-03-22 19:19:12 +0400 замена pppoe-connect на rp-pppoe.so create-ppp.diff text/plain 1435 taf LS0tIGNyZWF0ZS1wcHAub2xkCTIwMTEtMTAtMjggMDQ6MDk6MzkuMDAwMDAwMDAwICswOTAwCisr KyBjcmVhdGUtcHBwCTIwMTItMDMtMjIgMjI6MjA6NDUuMDAwMDAwMDAwICswOTAwCkBAIC02MSwx NSArNjEsMTYgQEAKIAkJUFRZT1BUSU9OPSIkUFBUUCAtLW5vbGF1bmNocHBwZCAkUFBUUF9TRVJW RVIgJFBQVFBfRVhUUkFfT1BUSU9OUyIKIAk7OwogCXBwcG9lKQotCQlbIC14ICIke1BQUE9FOj0k REVGQVVMVF9QUFBPRX0iIF0gfHwgewotCQkJcHJpbnRfZXJyb3IgIiRQUFBPRSBkb2VzIG5vdCBl eGlzdCBvciBpcyBub3QgZXhlY3V0YWJsZS4gVHJ5IGluc3RhbGxpbmcgcnAtcHBwb2UtYmFzZSBS UE0uIgotCQkJZXhpdCAxCi0JCX0KLQkJWyAtbiAiJEhPU1QiIF0gfHwgewotCQkJcHJpbnRfZXJy b3IgIldBUk5JTkc6IEhPU1QgaXMgbm90IHNldCBmb3IgaW50ZXJmYWNlICROQU1FIHdpdGggUFBQ VFlQRSAkUFBQVFlQRSIKLQkJCWV4aXQgMQotCQl9Ci0JCVBUWU9QVElPTj0iJFBQUE9FIC1JICRI T1NUIC1VICRQUFBPRV9FWFRSQV9PUFRJT05TIgorIwkJWyAteCAiJHtQUFBPRTo9JERFRkFVTFRf UFBQT0V9IiBdIHx8IHsKKyMJCQlwcmludF9lcnJvciAiJFBQUE9FIGRvZXMgbm90IGV4aXN0IG9y IGlzIG5vdCBleGVjdXRhYmxlLiBUcnkgaW5zdGFsbGluZyBycC1wcHBvZS1iYXNlIFJQTS4iCisj CQkJZXhpdCAxCisjCQl9CisjCQlbIC1uICIkSE9TVCIgXSB8fCB7CisjCQkJcHJpbnRfZXJyb3Ig IldBUk5JTkc6IEhPU1QgaXMgbm90IHNldCBmb3IgaW50ZXJmYWNlICROQU1FIHdpdGggUFBQVFlQ RSAkUFBQVFlQRSIKKyMJCQlleGl0IDEKKyMJCX0KKyMJCVBUWU9QVElPTj0iJFBQUE9FIC1JICRI T1NUIC1VICRQUFBPRV9FWFRSQV9PUFRJT05TIgorCQlQVFlPUFRJT049InBsdWdpbiBycC1wcHBv ZS5zbyAkSE9TVCIKIAk7OwogCWRpYWx1cCkKIAkJQkFTSUNfUFBQT1BUSU9OUz0iJEJBU0lDX1BQ UE9QVElPTlMgbW9kZW0iCkBAIC04Niw3ICs4Nyw4IEBACiBmaQogCiAjIExldCB0aGUgc2hvdyBz dGFydC4uLgotJFBQUEQgJEJBU0lDX1BQUE9QVElPTlMgJFBQUE9QVElPTlMgJHtQVFlPUFRJT046 K2xvY2FsIHB0eSAiJFBUWU9QVElPTiJ9IFwKKyMkUFBQRCAkQkFTSUNfUFBQT1BUSU9OUyAkUFBQ T1BUSU9OUyAke1BUWU9QVElPTjorbG9jYWwgcHR5ICIkUFRZT1BUSU9OIn0gXAorJFBQUEQgJEJB U0lDX1BQUE9QVElPTlMgJFBQUE9QVElPTlMgJHtQVFlPUFRJT046KyAkUFRZT1BUSU9OfSBcCiAk e1BST0ZfUFBQT1BUSU9OU0ZJTEU6KyBmaWxlICRQUk9GX1BQUE9QVElPTlNGSUxFfSBcCiAke1BS T0ZfUFBQSU5JVENIQVQ6KyBpbml0ICIkQ0hBVF9DTUQgJFBST0ZfUFBQSU5JVENIQVQifSBcCiAk e1BST0ZfUFBQQ09OTkVDVENIQVQ6KyBjb25uZWN0ICIkQ0hBVF9DTUQgJFBST0ZfUFBQQ09OTkVD VENIQVQifSBcCg== 5399 2012-03-22 19:19:12 +0400 2012-03-23 17:10:52 +0400 create-ppp.patch create-ppp.patch text/plain 1019 anubix LS0tIGNyZWF0ZS1wcHB+CTIwMTAtMDMtMjIgMjM6NDM6MjAuMDAwMDAwMDAwICswMzAwCisrKyBj cmVhdGUtcHBwCTIwMTItMDMtMjIgMTk6MTA6MTkuMDAwMDAwMDAwICswNDAwCkBAIC02MSw2ICs2 MSwxMyBAQCBjYXNlICIkUFBQVFlQRSIgaW4KIAkJUFRZT1BUSU9OPSIkUFBUUCAtLW5vbGF1bmNo cHBwZCAkUFBUUF9TRVJWRVIgJFBQVFBfRVhUUkFfT1BUSU9OUyIKIAk7OwogCXBwcG9lKQorCQlb IC1uICIkSE9TVCIgXSB8fCB7CisJCQlwcmludF9lcnJvciAiV0FSTklORzogSE9TVCBpcyBub3Qg c2V0IGZvciBpbnRlcmZhY2UgJE5BTUUgd2l0aCBQUFBUWVBFICRQUFBUWVBFIgorCQkJZXhpdCAx CisJCX0KKwkJUExVR0lOT1BUSU9OPSJwbHVnaW4gcnAtcHBwb2Uuc28gJEhPU1QiCisJOzsKKwl1 cHBwb2UpCiAJCVsgLXggIiR7UFBQT0U6PSRERUZBVUxUX1BQUE9FfSIgXSB8fCB7CiAJCQlwcmlu dF9lcnJvciAiJFBQUE9FIGRvZXMgbm90IGV4aXN0IG9yIGlzIG5vdCBleGVjdXRhYmxlLiBUcnkg aW5zdGFsbGluZyBycC1wcHBvZS1jbGllbnQgUlBNLiIKIAkJCWV4aXQgMQpAQCAtODYsNyArOTMs OSBAQCBpZiBpc195ZXMgIiRSRVNUT1JFX0RFRkFVTFRST1VURSI7IHRoZW4KIGZpCiAKICMgTGV0 IHRoZSBzaG93IHN0YXJ0Li4uCi0kUFBQRCAkQkFTSUNfUFBQT1BUSU9OUyAkUFBQT1BUSU9OUyAk e1BUWU9QVElPTjorbG9jYWwgcHR5ICIkUFRZT1BUSU9OIn0gXAorJFBQUEQgJEJBU0lDX1BQUE9Q VElPTlMgJFBQUE9QVElPTlMgXAorJHtQTFVHSU5PUFRJT046KyAkUExVR0lOT1BUSU9OfSBcCisk e1BUWU9QVElPTjorbG9jYWwgcHR5ICIkUFRZT1BUSU9OIn0gXAogJHtQUk9GX1BQUE9QVElPTlNG SUxFOisgZmlsZSAkUFJPRl9QUFBPUFRJT05TRklMRX0gXAogJHtQUk9GX1BQUElOSVRDSEFUOisg aW5pdCAiJENIQVRfQ01EICRQUk9GX1BQUElOSVRDSEFUIn0gXAogJHtQUk9GX1BQUENPTk5FQ1RD SEFUOisgY29ubmVjdCAiJENIQVRfQ01EICRQUk9GX1BQUENPTk5FQ1RDSEFUIn0gXAo= 5404 2012-03-23 17:10:52 +0400 2012-03-23 17:10:52 +0400 create-ppp.patch create-ppp.patch text/plain 1124 zerg LS0tIGNyZWF0ZS1wcHB+CTIwMTEtMTAtMjcgMjM6MDk6MzkuMDAwMDAwMDAwICswNDAwCisrKyBj cmVhdGUtcHBwCTIwMTItMDMtMjMgMTc6MDc6MjIuMTM3NTI5NzQ2ICswNDAwCkBAIC02MSwxNSAr NjEsMTEgQEAgY2FzZSAiJFBQUFRZUEUiIGluCiAJCVBUWU9QVElPTj0iJFBQVFAgLS1ub2xhdW5j aHBwcGQgJFBQVFBfU0VSVkVSICRQUFRQX0VYVFJBX09QVElPTlMiCiAJOzsKIAlwcHBvZSkKLQkJ WyAteCAiJHtQUFBPRTo9JERFRkFVTFRfUFBQT0V9IiBdIHx8IHsKLQkJCXByaW50X2Vycm9yICIk UFBQT0UgZG9lcyBub3QgZXhpc3Qgb3IgaXMgbm90IGV4ZWN1dGFibGUuIFRyeSBpbnN0YWxsaW5n IHJwLXBwcG9lLWJhc2UgUlBNLiIKLQkJCWV4aXQgMQotCQl9CiAJCVsgLW4gIiRIT1NUIiBdIHx8 IHsKIAkJCXByaW50X2Vycm9yICJXQVJOSU5HOiBIT1NUIGlzIG5vdCBzZXQgZm9yIGludGVyZmFj ZSAkTkFNRSB3aXRoIFBQUFRZUEUgJFBQUFRZUEUiCiAJCQlleGl0IDEKIAkJfQotCQlQVFlPUFRJ T049IiRQUFBPRSAtSSAkSE9TVCAtVSAkUFBQT0VfRVhUUkFfT1BUSU9OUyIKKwkJUExVR0lOT1BU SU9OPSJwbHVnaW4gcnAtcHBwb2Uuc28gJEhPU1QiCiAJOzsKIAlkaWFsdXApCiAJCUJBU0lDX1BQ UE9QVElPTlM9IiRCQVNJQ19QUFBPUFRJT05TIG1vZGVtIgpAQCAtODYsNyArODIsOSBAQCBpZiBp c195ZXMgIiRSRVNUT1JFX0RFRkFVTFRST1VURSI7IHRoZW4KIGZpCiAKICMgTGV0IHRoZSBzaG93 IHN0YXJ0Li4uCi0kUFBQRCAkQkFTSUNfUFBQT1BUSU9OUyAkUFBQT1BUSU9OUyAke1BUWU9QVElP TjorbG9jYWwgcHR5ICIkUFRZT1BUSU9OIn0gXAorJFBQUEQgJEJBU0lDX1BQUE9QVElPTlMgJFBQ UE9QVElPTlMgXAorJHtQTFVHSU5PUFRJT046KyAkUExVR0lOT1BUSU9OfSBcCiske1BUWU9QVElP TjorbG9jYWwgcHR5ICIkUFRZT1BUSU9OIn0gXAogJHtQUk9GX1BQUE9QVElPTlNGSUxFOisgZmls ZSAkUFJPRl9QUFBPUFRJT05TRklMRX0gXAogJHtQUk9GX1BQUElOSVRDSEFUOisgaW5pdCAiJENI QVRfQ01EICRQUk9GX1BQUElOSVRDSEFUIn0gXAogJHtQUk9GX1BQUENPTk5FQ1RDSEFUOisgY29u bmVjdCAiJENIQVRfQ01EICRQUk9GX1BQUENPTk5FQ1RDSEFUIn0gXAo=