LINUX.ORG.RU
решено ФорумAdmin

Подъем интерфейса ppp0 и его переподъём

 


0

3

Всем привет!

Имею Ubuntu 22.04.1 LTS в качестве Интернет-роутера с systemd и /etc/network/intefaces в качестве настроек сети.

Имею интернет провайдер Ростелеком с его Eltex роутером в режиме моста оптики в медь. Этот зверёк подключен в eth0 нашей убунты.
Убунта после загрузки поднимает eth0, а затем поднимает ppp0 (pppoe) через который уже интернет.

Вроде бы всё ничего, но вот если выполнять «холодный» старт, когда всё было обесточено, то Eltex (врежиме моста между оптикой и медью) грузится ЗНАЧИТЕЛЬНО дольше Ubuntu и последняя не «могучи» поднять ppp0 успокаивается на этом и дальше живёт без ppp0.

Так вот. А можно как-то её заставить непрерывно пытаться поднять ppp0? До тех пор пока не получится?

Замечание: если ppp0 всё же удалось поднять (руками или чудом самостоятельно при загрузке) то далее если оно рвётся, оно переподнимается само.

Немного настроек:
/etc/network/interfaces.d/00-eth0.conf

auto eth0
iface eth0 inet static
    address 192.168.0.2
    netmask 255.255.255.0
    post-up sysctl -w net.ipv6.conf.$IFACE.disable_ipv6=1
    post-up /sbin/route add -net 224.0.0.0/4 dev $IFACE
    post-up ifup ppp0
    pre-down /sbin/route del -net 224.0.0.0/4 dev $IFACE

/etc/network/interfaces.d/20-ppp0.conf
auto ppp0
iface ppp0 inet ppp
    provider dsl-provider

/etc/ppp/peers/dsl-provider
# Minimalistic default options file for DSL/PPPoE connections

persist # При разрыве соединения - переподключаться снова.
maxfail 0 # Максимальное количество неудачных попыток подключения. 0 - бесконечно.
noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
#mtu 1492
#holdoff 20
plugin rp-pppoe.so eth0
user "gpon********@pppoe"
#usepeerdns

remotename rt
ipparam rt

+ipv6 ipv6cp-use-ipaddr

/var/log/ppp.log
Nov 21 18:55:02 spider pppd[1964]: Plugin rp-pppoe.so loaded.
Nov 21 18:55:02 spider pppd[1970]: pppd 2.4.9 started by root, uid 0
Nov 21 18:55:02 spider pppd[1970]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Nov 21 18:55:02 spider pppd[1970]:  dst ff:ff:ff:ff:ff:ff  src 00:04:23:a5:c1:b0
Nov 21 18:55:02 spider pppd[1970]:  [service-name] [host-uniq  b2 07 00 00]
Nov 21 18:55:07 spider pppd[1970]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Nov 21 18:55:07 spider pppd[1970]:  dst ff:ff:ff:ff:ff:ff  src 00:04:23:a5:c1:b0
Nov 21 18:55:07 spider pppd[1970]:  [service-name] [host-uniq  b2 07 00 00]
Nov 21 18:55:07 spider pppd[1970]: select (waitForPADO): Interrupted system call
Nov 21 18:55:07 spider pppd[1970]: Timeout waiting for PADO packets
Nov 21 18:55:07 spider pppd[1970]: Unable to complete PPPoE Discovery
Nov 21 18:55:07 spider pppd[1970]: Terminating on signal 15
Nov 21 18:55:07 spider pppd[1970]: Exit.



Последнее исправление: Spider55 (всего исправлений: 1)

Ответ на: комментарий от sat0r

Я бы заcrontabил костыль под это дело.

+1 У меня все эти туннели только на кроне и живут, причина простая, рухнуть оно может когда угодно и как угодно, раз в пять минут вызываю скрипт который усе проверяет и если мы мертвенькие то вызывает рестарт туннельного соединения.

anc ★★★★★
()
Ответ на: комментарий от Bers666

Понятие «отваливается» оно «разное», в смысле разные причины могут быть, не вижу смысла полагаться на встроенные в сами приложухи варианты обнаружения «мы отвалились», мне нужно ехать, а не шашечки в виде «оно само сделает», если у меня из точки A в точку B перестало что-то летать, значит начинаем с самих туннелей, а не ждем пока они возможно сами раздуплятся.

anc ★★★★★
()
Ответ на: комментарий от Bers666

Пока не отваливается и живёт. А может молча отвалиться и ты об этом последним узнаёшь.

Watchdog пока наше всё. Хотя душа и жаждет эстетически прекрасных решений.

sat0r
()
Ответ на: комментарий от Gennadevich

только ifupdown есть.

В итоге всё нашлось. Дело не в pppd, он то как раз всё делает правильно если стоит флаг persist, он бесконечно долго пытается поднять интерфейс.
Всю картину портит networking.service, он выжидает какое-то время timeout не подъема интерфейса и прибивает процесс пытающийся поднять сей интерфейс.

я не правильно понимал логику работы. А надо было так:
auto ppp0 надо убрать, тогда networking.service не будет пытаться самостоятельно поднять ppp0 при загрузке (по факту это делает ifup -a, которого пинает уже «сервис»), тогда сервис поднимет всё ещё auto eth0 и тот выполнит по факту своего поднятия post-up ifup ppp0, но и это не всё. ifup ppp0 заблокирует выполнение пока pppd не поднимет интерфейс, а значит post-up будет ждать окончания всего этого, а это значит что мы не ушли от timeout сервиса.
И тут я не придумал ничего лучше как сделать это через nohup ifup ppp0 || true (пишу упрощено, для понимания смысла). Тогда post-up возвращается мгновенно и eth0 считается поднятым.
ppp0 же когда нить поднимется, это проверено. Затем по факту поднятия systemd вызовет событие ifup@ppp0.service на After= которого можно повесить события что делать после подъёма ppp0, например я поднимаю всякие VPN и прочую ерунду. Ну в прочем это к делу уже не относится.

Spider55
() автор топика
Последнее исправление: Spider55 (всего исправлений: 1)
Ответ на: комментарий от Spider55

для меня ето сложно я бы сделал так :
если есть роутер то он что не может сам ввести логин/пароль когда включиться ? тогда при вкючении убунты автоматически поднимется Ethernet там в настройках NetworkManager есть такая галочка .
Если роутер не способен вводить логин пароль то в убунте NetworkManager сам будет пытаться поднять интернет там в настройках соединения можно указать автоматически подключаться .

Gennadevich
()