рестарт WAN PPPOE с линии ADSL требует ребут pfSense
-
На одной точке пользуюсь ростелекомовским ADSL интернетом с PPPoE. Модем настроен бриджом, он прокидывает PPPoE на pfsense (2.2.2)
Ситуация весьма интересная, и гугл говорит что я весьма-весьма не одинок.
Симптомы:
Иногда (не всегда!) маршрутизатор pfSense перестаёт нормально переподключаться при разрыве туннеля. Чтобы маршрутер нормально снова зацепился на туннель - нужно его ребутать.
Сам момент отключения в логах не получается оперативно отследить, т.к. объект далеко и на момент ручной перезагрузки уже старые логи все затёрты. В логе иногда проскакивают сообщения, что присвоен IP 0.0.0.0.0 c шлюзом 0.0.0.0Пока что делаю так http://blog.martinshouse.com/2014/06/pfsense-auto-reboot-if-internet.html
Хочу узнать, есть ли подобные проблемы на ADSL линке у кого о ещё, и как с ними бороться.PS: ростелек требует весьма своеобразные настройки по компрессиям. Но не думаю, что эти вещи связаны.
-
За ссылку - спасибо.
Попробуйте обновить прошивку модема до последней версии. Как вариант, заменить модем на другой. -
модем не при делах - при подключении PPPoE с компа всё норм. Это косяк маршрутера.
-
удалось выцепить часть General лога:
php-fpm[46072]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 90.188.16.yyy -> 90.188.16.yyy - Restarting packages.
Jun 13 18:23:56 check_reload_status: Starting packages
Jun 13 18:23:56 snmpd[69627]: disk_OS_get_disks: adding device 'ada0' to device list
Jun 13 18:23:57 php-fpm[16718]: /rc.start_packages: Restarting/Starting all packages.
Jun 13 18:36:51 check_reload_status: Rewriting resolv.conf
Jun 13 18:38:20 check_reload_status: Rewriting resolv.conf
Jun 13 18:38:22 php-fpm[16718]: /rc.newwanip: ROUTING: setting default route to 213.228.116.72т.е. он подключился в 18:23, а в 18:38 решил прописать default route через туннель. Что вообще происходит?!
Это кусок PPP-лога. Представляет интерес последняя строка
Jun 13 18:22:05 ppp: [wan_link0] LCP: no reply to 4 echo request(s)
Jun 13 18:22:15 ppp: [wan_link0] LCP: no reply to 5 echo request(s)
Jun 13 18:22:15 ppp: [wan_link0] LCP: peer not responding to echo requests
Jun 13 18:22:15 ppp: [wan_link0] LCP: state change Opened –> Stopping
Jun 13 18:22:15 ppp: [wan_link0] Link: Leave bundle "wan"
Jun 13 18:22:15 ppp: [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Jun 13 18:22:15 ppp: [wan] IPCP: Close event
Jun 13 18:22:15 ppp: [wan] IPCP: state change Opened –> Closing
Jun 13 18:22:15 ppp: [wan] IPCP: SendTerminateReq #9
Jun 13 18:22:15 ppp: [wan] IPCP: LayerDown
Jun 13 18:22:15 ppp: [wan] IFACE: Delete route 0.0.0.0/0 213.228.116.72 failed: No such process
Jun 13 18:22:15 ppp: [wan] IFACE: Down event -
кусок лога из System->Gateways
Jun 13 18:37:00 apinger: Could not bind socket on address(90.188.16.11) for monitoring address 78.109.128.2(WAN_RT_PPPOE) with error Can't assign requested address
-
Версии 1.2.2 и 1.2.3 работали на нескольких точка по городу без проблем чёрт-ти сколько лет. Модемы были разные zyxel, acorp, zte и ещё какие-то, уже не помню.
ростелек требует весьма своеобразные настройки по компрессиям.
А вот этого не понял.
-
Версии 1.2.2 и 1.2.3 работали на нескольких точка по городу без проблем чёрт-ти сколько лет. Модемы были разные zyxel, acorp, zte и ещё какие-то, уже не помню.
ростелек требует весьма своеобразные настройки по компрессиям.
А вот этого не понял.
установлены галочки, без них не заводится:
-Disable vjcomp(compression) (auto-negotiated by default). -Disable acfcomp (compression) (auto-negotiated by default). -Disable protocomp (compression) (auto-negotiated by default).
-
Версия не х64 случаем ? Если да, то смените на х32.
P.s. Как вариант - сменить и сетевую.
-
версия i386
смысла менять сетёвку тоже не вижу - всё остальное работает нормально.
Вот топик в англоветке с этой проблемой https://forum.pfsense.org/index.php?topic=93607.0 -
Это проделали ?
I have read about apinger, and disabled the monitoring in WAN interface. (also created a cron job to restart it every 3 minutes)
Also i have read about the auto-negotiation setting to default, but in only appears in "normal interfaces"(when you configure the interface to be used as pppoe, there is not negotiation setting). -
нет, не делал.
Опасаюсь, что с этой галочкой перестанет работать реконнект. Я прав или ….. ? -
новая информация по делу!
мёртвое отваливание на самом деле нечто иное!- Возникает при простом реконнекте
- коннект при этом успешный! И WAN при этом горит зелёным!
-
1. Что вызывает реконнект? Бродячие крысы,
магнитныебури…
2. Возможно, конфликт IP адресов, в результате того, что кто-то самовольно забил себе статику. -
1. Что вызывает реконнект? Бродячие крысы,
магнитныебури…
2. Возможно, конфликт IP адресов, в результате того, что кто-то самовольно забил себе статику.по делу есть что нибудь? если выставить статику - PPPoE сервер её отвергает.
-
если выставить статику - PPPoE сервер её отвергает.
те вариант конфликта отпадает. Попробуйте поставить фиксированный протокол на модеме. Если не поможет пробовать поднимать сессию на самом модеме(чтобы исключить pfsense как неисправный элемент)
по делу есть что нибудь?
Провайдера поменять, ещё не предлагали?
-
о каком протоколе речь? модем в режиме роутера работает безпроблемно. ПРоблема на pfSense.
Провайдера менять не резонно, ввиду отсутствия оных в радиусе 100км.
-
о каком протоколе речь?
Аля ITU G.992.5, ITU G.992.5 Annex M, ITU G.992.5 Annex L…
модем в режиме роутера работает безпроблемно. ПРоблема на pfSense.
Тогда решайте вопрос с тем кто посоветовал Вам перевести модем в режим моста.
Провайдера менять не резонно, ввиду отсутствия оных в радиусе 100км.
Всё понимаю, просто попытался отшутиться от Вашего гневного выпада. Ан не получилось.
-
Вы с DSLAM-оборудованием работали когда нибудь?
я что то очень сильно сомневаюсь, что на annex-M протокол можно посадить ANNEX-A линию.ПРобегитесь по приведённым мною ссылкам. Не у одного меня такие траблы с ADSL, линия тут не при чём. Тем более, что с компа всё "ОК".
Ну разве это нормально, что:- основной маршрут прописывается не сразу после поднятия туннеля, а через какое то рандомное время?
- что даже при лежачем туннеле (если маршрутизации нет), WAN горит зелёным? а LCP пакеты ходят без ошибок.
-
я что то очень сильно сомневаюсь, что на annex-M протокол можно посадить ANNEX-A линию
Что сомнительного?
От топикстартера реквестирую
1. status - system log - ppp в момент обрыва и подключения.
2. Регион ростелека
3. Логи dsl модема в данный моментВангую пропадание линка dsl -> его восстановление -> попытку реконекта -> отказ bras'a в коннекте в связи с неистекшим таймаутом предидущего соединения - > превышение числа неудачных попыток аутентификация -> блок порта/padi request на пару минут дабы охладить пыл -> как раз в этот момент происходит ребут
-
Попробуйте обновить прошивку модема до последней версии. Вам это трудно сделать ?