(В ответ на комментарий №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 стоит в зависимостях, если кто не заметил.