Re: pppd иногда сдаётся
В Пнд, 04/09/2006 в 20:10 +0400, Max Dmitrichenko пишет: В сообщении от 4 Сентябрь 2006 19:05 Покотиленко Костик написал(a): Во вложении более подробный кусок лога касательно того процесса pppd который сказал exit. Почему-то лог какой-то обрезанный. Там нету сообщений о bad file descriptor. Попроси ещё rp-pppoe делать подробный вывод - у него был такой параметр где-то. Извините, не заметил. Он те записи в syslog писал, а я из messages выдерал. Во вложении тот же фрагмент, только из syslog (более полный). Интересненько. Видно, что PPPoE Discovery отрабатывает, а потом кто-то закрывает соединение. Причину не пишет. Но потом, видимо, pppd продолжает пытаться писать в это соединение - это похоже какой-то непредусмотренный случай. Эх... глянуть бы в корку процесса, тогда бы я сказал, кто эта сволочь. Если хочешь, то могу сказать, как подпачить pppd, чтобы он на этом месте он валился в корку, а потом ты мне её пошлёшь, а я попытаюсь разобраться, что не так. Только сразу предупреждаю, тебе придется пересобрать deb-пакет и, возможно, запустить pppd ручками, сказав все эти опции в командной строке. ЗЫ: Попробовать pppd с backports.org - тоже хорошая идея. Единственное, что ужасно, так это поведение новой версии plugin'а rp-pppoe. А именно то, что если ему что-то не нравится, то он вызывает exit(1), и pppd завершает свою работу без какой-либо диагностики. Хотя, возможно, мейнтейнеры подпачили этот финт ушами. Большое пасибо за предложение, но давай я пока попробую новую версию, чтобы не делать дурную работу. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В Пнд, 04/09/2006 в 20:10 +0400, Max Dmitrichenko пишет: В сообщении от 4 Сентябрь 2006 19:05 Покотиленко Костик написал(a): Во вложении более подробный кусок лога касательно того процесса pppd который сказал exit. Почему-то лог какой-то обрезанный. Там нету сообщений о bad file descriptor. Попроси ещё rp-pppoe делать подробный вывод - у него был такой параметр где-то. Извините, не заметил. Он те записи в syslog писал, а я из messages выдерал. Во вложении тот же фрагмент, только из syslog (более полный). Интересненько. Видно, что PPPoE Discovery отрабатывает, а потом кто-то закрывает соединение. Причину не пишет. Но потом, видимо, pppd продолжает пытаться писать в это соединение - это похоже какой-то непредусмотренный случай. Эх... глянуть бы в корку процесса, тогда бы я сказал, кто эта сволочь. Если хочешь, то могу сказать, как подпачить pppd, чтобы он на этом месте он валился в корку, а потом ты мне её пошлёшь, а я попытаюсь разобраться, что не так. Только сразу предупреждаю, тебе придется пересобрать deb-пакет и, возможно, запустить pppd ручками, сказав все эти опции в командной строке. ЗЫ: Попробовать pppd с backports.org - тоже хорошая идея. Единственное, что ужасно, так это поведение новой версии plugin'а rp-pppoe. А именно то, что если ему что-то не нравится, то он вызывает exit(1), и pppd завершает свою работу без какой-либо диагностики. Хотя, возможно, мейнтейнеры подпачили этот финт ушами. Кстати, ещё есть вопрос. У меня интерфейсы подымаются как обычно в Debian через if[up|down]. Если pppd выходит интерфейс продолжает быть configured, т.е. второй раз его не подымешь, надо ложить сначала. А не должен ли if[up|down] как-то это отрабатывать? Перезапустить ppp например? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В Пнд, 04/09/2006 в 20:10 +0400, Max Dmitrichenko пишет: В сообщении от 4 Сентябрь 2006 19:05 Покотиленко Костик написал(a): Во вложении более подробный кусок лога касательно того процесса pppd который сказал exit. Почему-то лог какой-то обрезанный. Там нету сообщений о bad file descriptor. Попроси ещё rp-pppoe делать подробный вывод - у него был такой параметр где-то. Извините, не заметил. Он те записи в syslog писал, а я из messages выдерал. Во вложении тот же фрагмент, только из syslog (более полный). Интересненько. Видно, что PPPoE Discovery отрабатывает, а потом кто-то закрывает соединение. Причину не пишет. Но потом, видимо, pppd продолжает пытаться писать в это соединение - это похоже какой-то непредусмотренный случай. Эх... глянуть бы в корку процесса, тогда бы я сказал, кто эта сволочь. Если хочешь, то могу сказать, как подпачить pppd, чтобы он на этом месте он валился в корку, а потом ты мне её пошлёшь, а я попытаюсь разобраться, что не так. Только сразу предупреждаю, тебе придется пересобрать deb-пакет и, возможно, запустить pppd ручками, сказав все эти опции в командной строке. ЗЫ: Попробовать pppd с backports.org - тоже хорошая идея. Единственное, что ужасно, так это поведение новой версии plugin'а rp-pppoe. А именно то, что если ему что-то не нравится, то он вызывает exit(1), и pppd завершает свою работу без какой-либо диагностики. Хотя, возможно, мейнтейнеры подпачили этот финт ушами. Вот ещё нарыл похожий баг, воде решили: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313205 -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В сообщении от 5 Сентябрь 2006 11:14 Покотиленко Костик написал(a): Кстати, ещё есть вопрос. У меня интерфейсы подымаются как обычно в Debian через if[up|down]. Если pppd выходит интерфейс продолжает быть configured, т.е. второй раз его не подымешь, надо ложить сначала. А не должен ли if[up|down] как-то это отрабатывать? Перезапустить ppp например? С какого перепугу? if[up|down] - это всего лишь приблуды, которые запускают и кладут интерфейсы, имея их конфиги. Это полностью пассивные сущности, т.е. они должны кем-то запускаться. Чтобы отследить кто там упал, а кто нет, нужно что-то, что будет следить, например, какой-нибудь демон. Если тебя бесит, что интерфейс остаётся configured, то добавь вызов ifdown в /etc/ppp/ip-down.d/. Но это будет работать, только если pppd вышел корректно. В противном случае, нужно писать демонёнка, который будет отслеживать исчезновения интерфейсов в системе. Когда-то такого даже написал, но он слишком специфичный для того места, где он использовался. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В противном случае, нужно писать демонёнка, который будет отслеживать исчезновения интерфейсов в системе. Когда-то такого даже написал, но он слишком специфичный для того места, где он использовался. а не проще ли написать в /etc/inittab T0:2345:respawn:/usr/sbin/pppd file /etc/ppp/options.vpn и все будет само подниматься -- Konstantin Kubatkin [KUB-RIPE] [KUB-UANIC] Kherson, TriLogiC Group Fido: 2:468/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В сообщении от 5 Сентябрь 2006 11:35 Konstantin Kubatkin написал(a): В противном случае, нужно писать демонёнка, который будет отслеживать исчезновения интерфейсов в системе. Когда-то такого даже написал, но он слишком специфичный для того места, где он использовался. а не проще ли написать в /etc/inittab T0:2345:respawn:/usr/sbin/pppd file /etc/ppp/options.vpn и все будет само подниматься Иногда нужно наоборот положить. Как тогда делать будешь? И вообще этот путь негибок, использует не инструменты и отдает overkill'ом. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В Вто, 05/09/2006 в 11:45 +0400, Max Dmitrichenko пишет: В сообщении от 5 Сентябрь 2006 11:35 Konstantin Kubatkin написал(a): В противном случае, нужно писать демонёнка, который будет отслеживать исчезновения интерфейсов в системе. Когда-то такого даже написал, но он слишком специфичный для того места, где он использовался. а не проще ли написать в /etc/inittab T0:2345:respawn:/usr/sbin/pppd file /etc/ppp/options.vpn и все будет само подниматься Иногда нужно наоборот положить. Как тогда делать будешь? И вообще этот путь негибок, использует не инструменты и отдает overkill'ом. Согласен, хоть это и вариант. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В противном случае, нужно писать демонёнка, который будет отслеживать исчезновения интерфейсов в системе. Когда-то такого даже написал, но он слишком специфичный для того места, где он использовался. а не проще ли написать в /etc/inittab T0:2345:respawn:/usr/sbin/pppd file /etc/ppp/options.vpn и все будет само подниматься Иногда нужно наоборот положить. Как тогда делать будешь? если грубо - то поставлю коментарий и выполню 'init q' хотя вариантов много есть И вообще этот путь негибок, использует не инструменты и отдает overkill'ом. а мне и не нужна гибкость, мне надо чтоб работало зато я не думаю о том, поднимется ppp сам или придется его поднимать руками -- Konstantin Kubatkin [KUB-RIPE] [KUB-UANIC] Kherson, TriLogiC Group Fido: 2:468/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pppd иногда сдаётся
Привет всем, Есть роутер с 3-мя ADSL PPPoE соединениями. Иногда проскакивает такая ситуация, что соединение падает и автоматом не пересоединяется в течении нескольких часов (точнее сказать вообще). Вручную: ifdown dsl-providerN ifup dsl-providerN всё поднимается сразу же. Сначала времени не было разбираться. Потом вот что нарыл в логах по поводу последней такой ситуации: Sep 1 12:23:05 192.168.1.4 pppd[2972]: LCP: timeout sending Config-Requests Sep 1 12:23:05 192.168.1.4 pppd[2972]: Connection terminated. Sep 1 12:23:05 192.168.1.4 pppd[2972]: Modem hangup Sep 1 12:23:09 192.168.1.4 pppd[2972]: PPP session is 17601 Sep 1 12:23:09 192.168.1.4 pppd[2972]: Using interface ppp0 Sep 1 12:23:09 192.168.1.4 pppd[2972]: Connect: ppp0 -- eth1 Sep 1 12:23:09 192.168.1.4 pppd[2972]: Couldn't increase MTU to 1500 Sep 1 12:23:09 192.168.1.4 pppd[2972]: Couldn't increase MRU to 1500 Sep 1 12:23:09 192.168.1.4 pppd[2972]: Connection terminated. Sep 1 12:23:09 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:12 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: Connection terminated. Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: Exit. Настораживает последняя строчка: pppd[2972]: Exit. Что-то мне подсказывает, что pppd решил плюнуть на всё и помереть. Это ведь не правильное поведение, как это вылечить? Система: Debian Sarge (Stable) 2.6.8, + что-то с backports.org -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
On 2006/09/04 Mon 13:21:31 , Покотиленко Костик wrote: Привет всем, Есть роутер с 3-мя ADSL PPPoE соединениями. Иногда проскакивает такая ситуация, что соединение падает и автоматом не пересоединяется в течении нескольких часов (точнее сказать вообще). Вручную: ifdown dsl-providerN ifup dsl-providerN всё поднимается сразу же. А опция persist у pppd включена ? -- With Best Regards, Eugene Krivdyuk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В Пнд, 04/09/2006 в 13:36 +0300, Eugene Krivdyuk пишет: On 2006/09/04 Mon 13:21:31 , Покотиленко Костик wrote: Привет всем, Есть роутер с 3-мя ADSL PPPoE соединениями. Иногда проскакивает такая ситуация, что соединение падает и автоматом не пересоединяется в течении нескольких часов (точнее сказать вообще). Вручную: ifdown dsl-providerN ifup dsl-providerN всё поднимается сразу же. А опция persist у pppd включена ? Не было включено. Это наверное оно, спасибо! -- With Best Regards, Eugene Krivdyuk -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В сообщении от 4 Сентябрь 2006 14:21 Покотиленко Костик написал(a): Sep 1 12:23:15 192.168.1.4 pppd[2972]: Connection terminated. Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: Exit. ... Настораживает последняя строчка: pppd[2972]: Exit. Что-то мне подсказывает, что pppd решил плюнуть на всё и помереть. Настораживать должна строчка: pppd[2972]: write: Bad file descriptor (9) Неплохобы выяснить, что за дескриптор, а то и persist может не помочь. Это ведь не правильное поведение, как это вылечить? А более полные логи + конфиги нельзя сказать? -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В Пнд, 04/09/2006 в 15:28 +0400, Max Dmitrichenko пишет: В сообщении от 4 Сентябрь 2006 14:21 Покотиленко Костик написал(a): Sep 1 12:23:15 192.168.1.4 pppd[2972]: Connection terminated. Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: Exit. ... Настораживает последняя строчка: pppd[2972]: Exit. Что-то мне подсказывает, что pppd решил плюнуть на всё и помереть. Настораживать должна строчка: pppd[2972]: write: Bad file descriptor (9) Неплохобы выяснить, что за дескриптор, а то и persist может не помочь. Это ведь не правильное поведение, как это вылечить? А более полные логи + конфиги нельзя сказать? /etc/ppp/options: -- asyncmap 0 auth crtscts lock hide-password modem proxyarp lcp-echo-interval 30 lcp-echo-failure 4 noipx persist maxfail 0 -- последние две поставил сегодня. /etc/ppp/peers/dsl-providerN (их три, отличаются только именем пользователя, и интерфейсом eth1|eth2): -- noipdefault usepeerdns hide-password lcp-echo-interval 20 lcp-echo-failure 3 connect /bin/true noauth persist mtu 1492 noaccomp default-asyncmap plugin rp-pppoe.so eth1 user userN -- Кстати, оказывается, что persist в /etc/ppp/peers/dsl-providerN БЫЛ. Значит проблема не пропадёт?! Во вложении более подробный кусок лога касательно того процесса pppd который сказал exit. -- Покотиленко Костик [EMAIL PROTECTED] Aug 29 06:07:31 wan-r pppd[2972]: IPCP terminated by peer Aug 29 06:07:31 wan-r pppd[2972]: Connect time 16461.0 minutes. Aug 29 06:07:31 wan-r pppd[2972]: Sent 2875369757 bytes, received 511325142 bytes. Aug 29 06:07:31 wan-r pppd[2972]: LCP terminated by peer Aug 29 06:07:31 wan-r pppd[2972]: Couldn't increase MTU to 1500 Aug 29 06:07:31 wan-r pppd[2972]: Couldn't increase MRU to 1500 Aug 29 06:07:34 wan-r pppd[2972]: Connection terminated. Aug 29 06:07:34 wan-r pppd[2972]: PPP session is 57377 Aug 29 06:07:34 wan-r pppd[2972]: Using interface ppp2 Aug 29 06:07:34 wan-r pppd[2972]: Connect: ppp2 -- eth1 Aug 29 06:07:34 wan-r pppd[2972]: Couldn't increase MTU to 1500 Aug 29 06:07:34 wan-r pppd[2972]: Couldn't increase MRU to 1500 Aug 29 06:07:40 wan-r pppd[2972]: Connection terminated. Aug 29 06:07:40 wan-r pppd[2972]: PPP session is 57379 Aug 29 06:07:40 wan-r pppd[2972]: Using interface ppp2 Aug 29 06:07:40 wan-r pppd[2972]: Connect: ppp2 -- eth1 Aug 29 06:07:40 wan-r pppd[2972]: Couldn't increase MTU to 1500 Aug 29 06:07:40 wan-r pppd[2972]: Couldn't increase MRU to 1500 Aug 29 06:07:40 wan-r pppd[2972]: Couldn't increase MRU to 1500 Aug 29 06:07:41 wan-r pppd[2972]: Remote message: Welcome^M^J Aug 29 06:07:41 wan-r pppd[2972]: PAP authentication succeeded Aug 29 06:07:41 wan-r pppd[2972]: peer from calling number 00:30:48:80:37:97 authorized Aug 29 06:07:41 wan-r pppd[2972]: local IP address local_ip Aug 29 06:07:41 wan-r pppd[2972]: remote IP address remote_ip Aug 29 06:07:41 wan-r pppd[2972]: primary DNS address isp_dns1 Aug 29 06:07:41 wan-r pppd[2972]: secondary DNS address isp_dns2 Sep 1 00:36:15 wan-r pppd[2972]: LCP terminated by peer Sep 1 00:36:15 wan-r pppd[2972]: Connect time 3988.6 minutes. Sep 1 00:36:15 wan-r pppd[2972]: Sent 654417428 bytes, received 2355894726 bytes. Sep 1 00:36:15 wan-r pppd[2972]: Couldn't increase MTU to 1500 Sep 1 00:36:15 wan-r pppd[2972]: Couldn't increase MRU to 1500 Sep 1 00:36:18 wan-r pppd[2972]: Connection terminated. Sep 1 00:36:18 wan-r pppd[2972]: PPP session is 15237 Sep 1 00:36:18 wan-r pppd[2972]: Using interface ppp2 Sep 1 00:36:18 wan-r pppd[2972]: Connect: ppp2 -- eth1 Sep 1 00:36:18 wan-r pppd[2972]: Couldn't increase MTU to 1500 Sep 1 00:36:18 wan-r pppd[2972]: Couldn't increase MRU to 1500 Sep 1 00:36:24 wan-r pppd[2972]: Connection terminated. Sep 1 00:36:24 wan-r pppd[2972]: PPP session is 15238 Sep 1 00:36:24 wan-r pppd[2972]: Using interface ppp2 Sep 1 00:36:24 wan-r pppd[2972]: Connect: ppp2 -- eth1 Sep 1 00:36:24 wan-r pppd[2972]: Couldn't increase MTU to 1500 Sep 1 00:36:24 wan-r pppd[2972]: Couldn't increase MRU to 1500 Sep 1 00:36:24 wan-r pppd[2972]: Couldn't increase MRU to 1500 Sep 1 00:36:24 wan-r pppd[2972]: Remote message: Welcome^M^J Sep 1 00:36:24 wan-r pppd[2972]: PAP authentication succeeded Sep 1 00:36:24 wan-r pppd[2972]: peer from calling number 00:30:48:80:37:97 authorized Sep 1 00:36:24 wan-r pppd[2972]: local IP address local_ip Sep 1 00:36:24 wan-r pppd[2972]: remote IP address remote_ip Sep 1 00:36:24 wan-r pppd[2972]: primary DNS address isp_dns1 Sep 1 00:36:24 wan-r pppd[2972]: secondary DNS address isp_dns2 Sep 1 12:12:46 wan-r pppd[2972]: No response to 3 echo-requests Sep 1 12:12:46 wan-r pppd[2972]: Serial link appears to be disconnected. Sep 1 12:12:46 wan-r pppd[2972]: Connect time 696.4 minutes. Sep 1 12:12:46 wan-r pppd[2972]: Sent 53651585 bytes,
Re: pppd иногда сдаётся
В Пнд, 04/09/2006 в 16:06 +0300, Покотиленко Костик пишет: /etc/ppp/options: -- asyncmap 0 auth crtscts lock hide-password modem proxyarp lcp-echo-interval 30 lcp-echo-failure 4 noipx persist maxfail 0 -- последние две поставил сегодня. Кстати, оказывается, что persist в /etc/ppp/peers/dsl-providerN БЫЛ. Значит проблема не пропадёт?! Ещё заметки. Получается, что в /etc/ppp/options не было persist и не было maxfail 0, что означает использовать по умолчанию maxfail 10. Также в /etc/ppp/peers/dsl-providerN опция persist была. Значит persist был включен, а maxfail был по умолчанию равен 10. То есть, поправьте меня если я не прав, после 10-ти ре-коннектов pppd просто выходил?? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В сообщении от 4 Сентябрь 2006 17:06 Покотиленко Костик написал(a): В Пнд, 04/09/2006 в 15:28 +0400, Max Dmitrichenko пишет: В сообщении от 4 Сентябрь 2006 14:21 Покотиленко Костик написал(a): Sep 1 12:23:15 192.168.1.4 pppd[2972]: Connection terminated. Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: Exit. ... Настораживает последняя строчка: pppd[2972]: Exit. Что-то мне подсказывает, что pppd решил плюнуть на всё и помереть. Настораживать должна строчка: pppd[2972]: write: Bad file descriptor (9) Неплохобы выяснить, что за дескриптор, а то и persist может не помочь. Во вложении более подробный кусок лога касательно того процесса pppd который сказал exit. Почему-то лог какой-то обрезанный. Там нету сообщений о bad file descriptor. Попроси ещё rp-pppoe делать подробный вывод - у него был такой параметр где-то. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
Покотиленко Костик wrote: Ещё заметки. Получается, что в /etc/ppp/options не было persist и не было maxfail 0, что означает использовать по умолчанию maxfail 10. Также в /etc/ppp/peers/dsl-providerN опция persist была. Значит persist был включен, а maxfail был по умолчанию равен 10. То есть, поправьте меня если я не прав, после 10-ти ре-коннектов pppd просто выходил?? Так. Только я, вот, заметил, что всё равно persist maxfail 0 не спасает. В sarge, во всяком случае, pptp и pppoe у меня отваливаются если удалённая сторона недоступна достаточно долго (несколько часов). Разобраться с проблемой было пока недосуг. Вот мне интересно: ещё кто-нибудь подобную гадость наблюдает? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В Пнд, 04/09/2006 в 17:46 +0400, Slava Astashonok пишет: Покотиленко Костик wrote: Ещё заметки. Получается, что в /etc/ppp/options не было persist и не было maxfail 0, что означает использовать по умолчанию maxfail 10. Также в /etc/ppp/peers/dsl-providerN опция persist была. Значит persist был включен, а maxfail был по умолчанию равен 10. То есть, поправьте меня если я не прав, после 10-ти ре-коннектов pppd просто выходил?? Так. Только я, вот, заметил, что всё равно persist maxfail 0 не спасает. В sarge, во всяком случае, pptp и pppoe у меня отваливаются если удалённая сторона недоступна достаточно долго (несколько часов). Разобраться с проблемой было пока недосуг. Вот мне интересно: ещё кто-нибудь подобную гадость наблюдает? Может ppp обновить? Стоит: 2.4.3-20050321+2 Доступно: 2.4.3-20050321+2sarge1, 2.4.4rel-1bpo1 (с backports.org) -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В Пнд, 04/09/2006 в 18:02 +0400, Max Dmitrichenko пишет: В сообщении от 4 Сентябрь 2006 17:06 Покотиленко Костик написал(a): В Пнд, 04/09/2006 в 15:28 +0400, Max Dmitrichenko пишет: В сообщении от 4 Сентябрь 2006 14:21 Покотиленко Костик написал(a): Sep 1 12:23:15 192.168.1.4 pppd[2972]: Connection terminated. Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: write: Bad file descriptor (9) Sep 1 12:23:15 192.168.1.4 pppd[2972]: Exit. ... Настораживает последняя строчка: pppd[2972]: Exit. Что-то мне подсказывает, что pppd решил плюнуть на всё и помереть. Настораживать должна строчка: pppd[2972]: write: Bad file descriptor (9) Неплохобы выяснить, что за дескриптор, а то и persist может не помочь. Во вложении более подробный кусок лога касательно того процесса pppd который сказал exit. Почему-то лог какой-то обрезанный. Там нету сообщений о bad file descriptor. Попроси ещё rp-pppoe делать подробный вывод - у него был такой параметр где-то. Извините, не заметил. Он те записи в syslog писал, а я из messages выдерал. Во вложении тот же фрагмент, только из syslog (более полный). -- Покотиленко Костик [EMAIL PROTECTED] Aug 29 06:07:31 wan-r pppd[2972]: IPCP terminated by peer Aug 29 06:07:31 wan-r pppd[2972]: Connect time 16461.0 minutes. Aug 29 06:07:31 wan-r pppd[2972]: Sent 2875369757 bytes, received 511325142 bytes. Aug 29 06:07:31 wan-r pppd[2972]: LCP terminated by peer Aug 29 06:07:31 wan-r pppd[2972]: Couldn't increase MTU to 1500 Aug 29 06:07:31 wan-r pppd[2972]: Couldn't increase MRU to 1500 Aug 29 06:07:34 wan-r pppd[2972]: Connection terminated. Aug 29 06:07:34 wan-r pppd[2972]: PPP session is 57377 Aug 29 06:07:34 wan-r pppd[2972]: Using interface ppp2 Aug 29 06:07:34 wan-r pppd[2972]: Connect: ppp2 -- eth1 Aug 29 06:07:34 wan-r pppd[2972]: Couldn't increase MTU to 1500 Aug 29 06:07:34 wan-r pppd[2972]: Couldn't increase MRU to 1500 Aug 29 06:07:40 wan-r pppd[2972]: Connection terminated. Aug 29 06:07:40 wan-r pppd[2972]: PPP session is 57379 Aug 29 06:07:40 wan-r pppd[2972]: Using interface ppp2 Aug 29 06:07:40 wan-r pppd[2972]: Connect: ppp2 -- eth1 Aug 29 06:07:40 wan-r pppd[2972]: Couldn't increase MTU to 1500 Aug 29 06:07:40 wan-r pppd[2972]: Couldn't increase MRU to 1500 Aug 29 06:07:40 wan-r pppd[2972]: Couldn't increase MRU to 1500 Aug 29 06:07:41 wan-r pppd[2972]: Remote message: Welcome^M^J Aug 29 06:07:41 wan-r pppd[2972]: PAP authentication succeeded Aug 29 06:07:41 wan-r pppd[2972]: peer from calling number 00:30:48:80:37:97 authorized Aug 29 06:07:41 wan-r pppd[2972]: Cannot determine ethernet address for proxy ARP Aug 29 06:07:41 wan-r pppd[2972]: local IP address local_ip Aug 29 06:07:41 wan-r pppd[2972]: remote IP address remote_ip Aug 29 06:07:41 wan-r pppd[2972]: primary DNS address isp_dns1 Aug 29 06:07:41 wan-r pppd[2972]: secondary DNS address isp_dns2 Sep 1 00:36:15 wan-r pppd[2972]: LCP terminated by peer Sep 1 00:36:15 wan-r pppd[2972]: Connect time 3988.6 minutes. Sep 1 00:36:15 wan-r pppd[2972]: Sent 654417428 bytes, received 2355894726 bytes. Sep 1 00:36:15 wan-r pppd[2972]: Couldn't increase MTU to 1500 Sep 1 00:36:15 wan-r pppd[2972]: Couldn't increase MRU to 1500 Sep 1 00:36:18 wan-r pppd[2972]: Connection terminated. Sep 1 00:36:18 wan-r pppd[2972]: PPP session is 15237 Sep 1 00:36:18 wan-r pppd[2972]: Using interface ppp2 Sep 1 00:36:18 wan-r pppd[2972]: Connect: ppp2 -- eth1 Sep 1 00:36:18 wan-r pppd[2972]: Couldn't increase MTU to 1500 Sep 1 00:36:18 wan-r pppd[2972]: Couldn't increase MRU to 1500 Sep 1 00:36:24 wan-r pppd[2972]: Connection terminated. Sep 1 00:36:24 wan-r pppd[2972]: PPP session is 15238 Sep 1 00:36:24 wan-r pppd[2972]: Using interface ppp2 Sep 1 00:36:24 wan-r pppd[2972]: Connect: ppp2 -- eth1 Sep 1 00:36:24 wan-r pppd[2972]: Couldn't increase MTU to 1500 Sep 1 00:36:24 wan-r pppd[2972]: Couldn't increase MRU to 1500 Sep 1 00:36:24 wan-r pppd[2972]: Couldn't increase MRU to 1500 Sep 1 00:36:24 wan-r pppd[2972]: Remote message: Welcome^M^J Sep 1 00:36:24 wan-r pppd[2972]: PAP authentication succeeded Sep 1 00:36:24 wan-r pppd[2972]: peer from calling number 00:30:48:80:37:97 authorized Sep 1 00:36:24 wan-r pppd[2972]: Cannot determine ethernet address for proxy ARP Sep 1 00:36:24 wan-r pppd[2972]: local IP address local_ip Sep 1 00:36:24 wan-r pppd[2972]: remote IP address remote_ip Sep 1 00:36:24 wan-r pppd[2972]: primary DNS address isp_dns1 Sep 1 00:36:24 wan-r pppd[2972]: secondary DNS address isp_dns2 Sep 1 12:12:46 wan-r pppd[2972]: No response to 3 echo-requests Sep 1 12:12:46 wan-r pppd[2972]: Serial link appears to be disconnected. Sep 1 12:12:46 wan-r pppd[2972]: Connect time 696.4 minutes. Sep 1 12:12:46 wan-r pppd[2972]: Sent 53651585 bytes, received 157907356 bytes. Sep 1 12:12:46 wan-r pppd[2972]: Couldn't increase MTU to 1500 Sep 1 12:12:46 wan-r pppd[2972]:
Re: pppd иногда сдаётся
Так. Только я, вот, заметил, что всё равно persist maxfail 0 не спасает. В sarge, во всяком случае, pptp и pppoe у меня отваливаются если удалённая сторона недоступна достаточно долго (несколько часов). Разобраться с проблемой было пока недосуг. Вот мне интересно: ещё кто-нибудь подобную гадость наблюдает? что-то подобное было написал holdoff 60 и с тех несколько часов без связи pppd переживал -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pppd иногда сдаётся
В сообщении от 4 Сентябрь 2006 19:05 Покотиленко Костик написал(a): Во вложении более подробный кусок лога касательно того процесса pppd который сказал exit. Почему-то лог какой-то обрезанный. Там нету сообщений о bad file descriptor. Попроси ещё rp-pppoe делать подробный вывод - у него был такой параметр где-то. Извините, не заметил. Он те записи в syslog писал, а я из messages выдерал. Во вложении тот же фрагмент, только из syslog (более полный). Интересненько. Видно, что PPPoE Discovery отрабатывает, а потом кто-то закрывает соединение. Причину не пишет. Но потом, видимо, pppd продолжает пытаться писать в это соединение - это похоже какой-то непредусмотренный случай. Эх... глянуть бы в корку процесса, тогда бы я сказал, кто эта сволочь. Если хочешь, то могу сказать, как подпачить pppd, чтобы он на этом месте он валился в корку, а потом ты мне её пошлёшь, а я попытаюсь разобраться, что не так. Только сразу предупреждаю, тебе придется пересобрать deb-пакет и, возможно, запустить pppd ручками, сказав все эти опции в командной строке. ЗЫ: Попробовать pppd с backports.org - тоже хорошая идея. Единственное, что ужасно, так это поведение новой версии plugin'а rp-pppoe. А именно то, что если ему что-то не нравится, то он вызывает exit(1), и pppd завершает свою работу без какой-либо диагностики. Хотя, возможно, мейнтейнеры подпачили этот финт ушами. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
