Как увеличить время между переподключениями при обрыве подключения PPPoE0

[angel0chek]

У провайдера иногда, периодически обрывается связь, потом роутер пытается переподключиться и в логах вижу 2 варианта, когда как:
[I] Oct 2 17:48:21 pppd[4388]: Plugin rp-pppoe.so loaded.
[I] Oct 2 17:48:21 pppd[4388]: pppd 2.4.4-4 started by root, uid 0
[I] Oct 2 17:48:21 pppd[4388]: Found unterminated session: 15:00:21:59:af:44:84
[I] Oct 2 17:48:21 pppd[4388]: Sent PADT
[I] Oct 2 17:48:22 pppd[4388]: PPP session is 2
[I] Oct 2 17:48:22 pppd[4388]: Using interface ppp0
[I] Oct 2 17:48:22 pppd[4388]: Connect: ppp0 <--> eth2.2
[I] Oct 2 17:48:26 pppd[4388]: CHAP authentication failed: ^M^JYou are already logged in - access denied^M^J^J
[E] Oct 2 17:48:26 pppd[4388]: CHAP authentication failed
[I] Oct 2 17:48:26 pppd[4388]: Modem hangup
[I] Oct 2 17:48:26 pppd[4388]: Connection terminated.
[I] Oct 2 17:48:26 pppd[4388]: Sent PADT
[I] Oct 2 17:48:26 pppd[4388]: Exit.
[E] Oct 2 17:48:26 ndm: Service: "PPPoE0": unexpectedly stopped.
----------------------------------------
Но зачастую пишет:
[I] Oct 2 17:48:26 ndm: Network::Interface::Base: "PPPoE0": interface is up.
[I] Oct 2 17:48:29 pppd[4434]: Plugin rp-pppoe.so loaded.
[I] Oct 2 17:48:29 pppd[4434]: pppd 2.4.4-4 started by root, uid 0
[I] Oct 2 17:48:29 pppd[4434]: Found unterminated session: 15:00:21:59:af:44:84
[I] Oct 2 17:48:29 pppd[4434]: Sent PADT
[W] Oct 2 17:48:44 pppd[4434]: Timeout waiting for PADO packets
[E] Oct 2 17:48:44 pppd[4434]: Unable to complete PPPoE Discovery
[I] Oct 2 17:48:44 pppd[4434]: Exit.
[E] Oct 2 17:48:44 ndm: Service: "PPPoE0": unexpectedly stopped.

 

Как быть ?

Насколько я знаю, отбрывается подключение, роутер переподключается, но сервер еще видит завершенную сессию и не дает переподключиться.

Обычно провадер в таком случае предлагает отключить роутер , подожать 5-10 минут и снова подключиться.

Как сделать это автоматически через роутер, увеличить время между переподключением ?

Изменено 4 октября, 2020 пользователем angel0chek

[Space Alex]

Можно например искусственно рвать линк раз в сутки или раз в неделю на несколько минут, ночью. В моем примере раз в сутки в 4:30 утра на 1 минуту.

(config)> schedule inetrestart
(config-sched)> action start 31 4 *
(config-sched)> action stop 30 4 *
(config-sched)> exit
(config)> interface ISP schedule inetrestart
(config)> system configuration save
(config)> exit

Таким образом сессия принудительно будет обновляться раз в сутки.

Изменено 4 октября, 2020 пользователем Space Alex

[angel0chek]

Та не, это не вариант.

Потому что хотелось это делать в автоматическом режиме как раз во время такой проблемы.

Просто разрывать соединение каждый день или неделю - не понятно зачем.

 

[Le ecureuil]

Во втором случае вам не отвечает bras, и это починить невозможно пока не "рассосется" у провайдера - это его приблемы.

А в первом нужен по-хорошему сброс сессии по LCP, видимо PADT недостаточно, но для этого нужно хранить magic и lcp id, что проблематично.

[plagioklaz]

15 часов назад, Le ecureuil сказал:

Во втором случае вам не отвечает bras, и это починить невозможно пока не "рассосется" у провайдера - это его приблемы.

так почему не дать возможность клиенту "переждать" пока рассосуться проблемы? Дать настраиваемую задержку переподключения.

[Le ecureuil]

2 часа назад, plagioklaz сказал:

так почему не дать возможность клиенту "переждать" пока рассосуться проблемы? Дать настраиваемую задержку переподключения.

Так разницы нет - что ты постоянно долбишь и что ты ждешь. Или не проходят PADI, или PADO, и нужно постоянно активно проверять "не нормализовалось ли".

[Goblin]

6 часов назад, plagioklaz сказал:

клиенту "переждать" пока рассосуться проблемы?

а зачем? долбится и пусть долбится быстрее продолбится. а так дашь паузу мнут в 5 а там откроют через две. и чего три минуты просто так висеть? а если пауза с проверкой, то какая разница? имхо, пусть долбится.

[angel0chek]

7 часов назад, Le ecureuil сказал:

Так разницы нет - что ты постоянно долбишь и что ты ждешь. Или не проходят PADI, или PADO, и нужно постоянно активно проверять "не нормализовалось ли".

В моем случае, похоже, разница есть.

И если долбится постоянно, то долго подключается. Если подождать несколько минут, то почти сразу подключается. Так не всегда, но бывает очень даже помогает. Сам удивляюсь.

Не зря провайдер дает такие советы, подождать с подключением.

Сервер потом тупо банит роутер на запросы такое впечатление.

В любом случае, если бы добавили возможность в регулировке задержки между запросами, то было бы круто.

Изменено 6 октября, 2020 пользователем angel0chek

[Le ecureuil]

На каждый подобный заскок каждого говнопровайдера не напасешься крутилок, если честно. Я бы его тупо сменил "за неадекватность".

[angel0chek]

1 минуту назад, Le ecureuil сказал:

На каждый подобный заскок каждого говнопровайдера не напасешься крутилок, если честно. Я бы его тупо сменил "за неадекватность".

Я бы тоже может сменил, но монополиста не сменить.

[plagioklaz]

В 06.10.2020 в 19:19, Le ecureuil сказал:

На каждый подобный заскок каждого говнопровайдера не напасешься крутилок, если честно. Я бы его тупо сменил "за неадекватность".

Вы правы, но не все живут в городах миллионниках. В большинстве своём счастье, что есть проводной интернет. И, как правило, провод всего один, и выбирать не приходится.

[Le ecureuil]

Все понимаю, я сам жил несколько лет только на LTE, а сейчас на WiFi-мосте с LTE-fallback. Так что для меня тупой 100мбит кабель или проклятый GPON это вообще счастье.

Но есть объективное понимание, что тут с реконнектом делать еще одну команду нецелесообразно (пока по крайней мере) - потому что я ежедневно общаюсь с официальной техподдержкой и от них нет запросов для этого "с той стороны".

[Space Alex]

Я именно по этому и предложил в самом начале принудительное обновление сессии ночью раз в неделю с помощью расписания) один раз настроил и забыл и интернет стабильно есть всегда) мне это помогло когда такая же беда была с билайном и их l2tp. Слава богу теперь на Gpon ушел 😀

Изменено 9 октября, 2020 пользователем Space Alex

[Tribal_]

Столкнулся с такой же проблемой в Ростелекоме. Решение заключалось в том, что РТ никого не предупредив и, скорее всего сам того не зная, вернул ONT терминал в дефолтный режим, хотя он должен был быть в режима Bridge, о чем специально создавалась заявка...