Bug 23556

Summary: PPPoE падает, и подняться не может.
Product: Sisyphus Reporter: MisHel64 <MisHel64>
Component: pppAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED WONTFIX QA Contact: qa-sisyphus
Severity: normal    
Priority: P3 CC: MisHel64, asy, cas, mike, pilot, sem
Version: unstable   
Hardware: all   
OS: Linux   
Attachments:
Description Flags
ifdown-ppp
none
ip-down none

Description MisHel64 2010-05-30 21:26:56 MSD
Здравствуйте.

Давно  было  подозрение,  что  PPPoE  при планом "разрыве" падает и не
поднимается.

Вот выдержка из логов:

May 29 14:26:18 hsrv pppoe[6143]: Session 7209 terminated -- received PADT from peer
May 29 14:26:18 hsrv pppd[6146]: LCP terminated by peer
May 29 14:26:18 hsrv pppd[6146]: Connect time 1440.0 minutes.
May 29 14:26:18 hsrv pppd[6146]: Sent 1803714512 bytes, received 1122830342 bytes.
May 29 14:26:18 hsrv pppoe[6143]: Sent PADT
May 29 14:26:18 hsrv pppd[6146]: Modem hangup
May 29 14:26:18 hsrv pppd[6146]: Connection terminated.
May 29 14:26:18 hsrv pppd[6146]: Using interface ppp10
May 29 14:26:18 hsrv pppd[6146]: Connect: ppp10 <--> /dev/pts/1
May 29 14:26:18 hsrv pppoe[5010]: PPP session is 10877 (0x2a7d)
May 29 14:26:18 hsrv pppd[6146]: Remote message: Authentication success,Welcome!
May 29 14:26:18 hsrv pppd[6146]: PAP authentication succeeded
May 29 14:26:18 hsrv pppd[6146]: local  IP address 95.68.188.233
May 29 14:26:18 hsrv pppd[6146]: remote IP address 89.239.189.2
May 29 14:26:18 hsrv pppd[6146]: primary   DNS address 89.239.139.130
May 29 14:26:18 hsrv pppd[6146]: secondary DNS address 89.239.139.131
May 29 14:26:19 hsrv pppd[6146]: Script /etc/ppp/ip-down finished (pid 5002), status = 0x1
May 29 14:26:19 hsrv pppd[6146]: Script /etc/ppp/ip-up finished (pid 5110), status = 0x0

После  разрыва  соединения,  который  виден  в  логе,  интерфейс PPP10
исчез  из  системы. Конфиги привожу ниже. Ткните носом, что я делаю не
так.

Сервер 4.0.1, бранч 5.1

options
===
TYPE=ppp
PPPTYPE=pppoe
DISABLED=no
ONBOOT=no
CONFIG_QOS=no
CONFIG_FW=no
NM_CONTROLLED=no
HOST=emod
===

pppoptions
===
persist
maxfail 3

noipdefault
default-asyncmap
defaultroute
hide-password
refuse-chap
usepeerdns

noaccomp
noccp
nobsdcomp
nodeflate
nopcomp
novj
novjccomp

name XXXXXXXXXXXXXXXX
linkname mvc
lcp-echo-failure 3
lcp-echo-interval 20
===
Comment 1 Sir Raorn 2010-05-30 21:45:53 MSD
Это нормальное поведение pppd.  Для невозбранного достижения желаемого надо использовать опции persist и maxfail 0 (а не 3), но тогда будет зависание во время загрузки, если по каким-то причинам ppp соединения не может подняться.

Единственный рабочий вариант на сегодняшний день - строчка в /etc/crontab:

* * * * * root [ -s /var/run/pppN.pid ] || ifup pppN

Но лучше всего таки пропатчить pppd, чтобы при persist и maxfail 0 он не зависал на старте.

*** This bug has been marked as a duplicate of bug 12382 ***
Comment 2 MisHel64 2010-05-30 22:53:45 MSD
Ну во первых данная ошибки ни коем образом не дублирует ошибку 12382.
Во вторых, все написанное вами не имеет отношения к проблеме.
В третьих, еще год назад все нормально работало. Что, где и когда поломали точнее затрудняюсь ответить. Долго не пользовался продукцией альтов.

Я правильно понял смысл вашего ответа, не только чинить, но иразбиратся в вопросе никто не будет, и единственное решение, это приделать костыли?
Comment 3 Michael Shigorin 2010-06-12 12:08:15 MSD
(In reply to comment #1)
> Но лучше всего таки пропатчить pppd, чтобы при persist и maxfail 0 он не
> зависал на старте.
Поискал -- наскоро (ppp persist maxfail patch) ничего не нашлось.

А что, у нас и сейчас ppp* поднимается не в фоне? (давно не сталкивался из etcnet, через трубы звоню своим скриптом)

(In reply to comment #2)
> Я правильно понял смысл вашего ответа, не только чинить, но и разбиратся в
> вопросе никто не будет
Скажем так -- из майнтейнеров действительно некому.

> и единственное решение, это приделать костыли?
Вполне энтерпрайзно... ещё один испытанный вариант -- строчка в /etc/inittab:
http://lists.altlinux.org/pipermail/community/2001-January/422459.html

На самом деле перезвон -- старое больное место.  См., например, bug #10095, bug #8312 или bug #1589.
Comment 4 Sergey Y. Afonin 2010-08-22 23:35:56 MSD
(In reply to comment #2)

> Я правильно понял смысл вашего ответа, не только чинить, но иразбиратся в
> вопросе никто не будет, и единственное решение, это приделать костыли?

В чём разбираться ? Написано же: "maxfail 3". Три раза тыкнулся, потом отпал.
Или речь уже про фоновый старт pppd ?
Comment 5 MisHel64 2010-08-23 11:00:29 MSD
Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до конца скриптом /etc/ppp/ip-down прибивается, что отчетливо видно из приведенного лога. Демон считает, что соединение установлено нормально, больше не пытается его поднять. А фактически оно прибито и отсутствует.

Значение maxfail 3 ему по барабану в этом случае.
Comment 6 Sergey Y. Afonin 2010-08-23 15:50:07 MSD
(In reply to comment #5)

> Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до
> конца скриптом /etc/ppp/ip-down прибивается,

Чем-чем прибивается ?! :-)

> что отчетливо видно из приведенного лога.

Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в ip-down пусто.

> Демон считает, что соединение установлено нормально, больше
> не пытается его поднять. А фактически оно прибито и отсутствует.

Скорее оно не поднято по какой-то причине.

> Значение maxfail 3 ему по барабану в этом случае.

"lcp-echo-failure 3" и "lcp-echo-interval 20", вообще-то, должны заставить демона поверить в смерть соединения... Что-то тут не так, но это что-то - совсем другое.
Comment 7 MisHel64 2010-08-23 16:28:15 MSD
(В ответ на комментарий №6)
> (In reply to comment #5)
> 
> > Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до
> > конца скриптом /etc/ppp/ip-down прибивается,
> 
> Чем-чем прибивается ?! :-)

Тем, чем я сказал. Логи приведенные в первом посте.

> > что отчетливо видно из приведенного лога.
> 
> Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в
> ip-down пусто.

В этом по умолчанию постом файле 60 строк. И вызовы других скриптов.

> > Демон считает, что соединение установлено нормально, больше
> > не пытается его поднять. А фактически оно прибито и отсутствует.
> 
> Скорее оно не поднято по какой-то причине.

Оно поднято, что видно из логов.

Логи приведены в первом посте. Посмотрите пожалуйста их с начало.
Comment 8 Sergey Y. Afonin 2010-08-23 16:37:41 MSD
(In reply to comment #7)

> > > конца скриптом /etc/ppp/ip-down прибивается,
> > 
> > Чем-чем прибивается ?! :-)
> 
> Тем, чем я сказал. Логи приведенные в первом посте.

Нет.

> > Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в
> > ip-down пусто.
> 
> В этом по умолчанию постом файле 60 строк. И вызовы других скриптов.

Да, правда. Подрос файлик. Тем не менее, там нет ничего, что относилось бы к прибиванию линка. Ещё раз, почитайте назначение скрипта, затем посмотрите, что именно он делает.

> > Скорее оно не поднято по какой-то причине.
> 
> Оно поднято, что видно из логов.

По логу видно, что поднятно, не спорю. Вопрос, что по факту - это раз, какой syslog - это два. А то, может, он просто не дописал ?

> Логи приведены в первом посте. Посмотрите пожалуйста их с начало.

Я видел. Вы их неправильно интерпретируете, по крайней мере, в районе понимания функций скрипта ip-down.
Comment 9 MisHel64 2010-08-23 17:03:18 MSD
(В ответ на комментарий №8)
> (In reply to comment #7)
> 
> > > > конца скриптом /etc/ppp/ip-down прибивается,
> > > 
> > > Чем-чем прибивается ?! :-)
> > 
> > Тем, чем я сказал. Логи приведенные в первом посте.
> 
> Нет.

А я проверял. Если /etc/ppp/ip-down заканчивается раньше, судя по логам, то соединение устанавливается и работает нормально.

Даже простейший пример. Делаю 
# ifdown
# ifup
И все отлично работает.

> > > Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в
> > > ip-down пусто.
> > 
> > В этом по умолчанию постом файле 60 строк. И вызовы других скриптов.
> 
> Да, правда. Подрос файлик. Тем не менее, там нет ничего, что относилось бы к
> прибиванию линка. 

Вы не правы.

> Ещё раз, почитайте назначение скрипта, затем посмотрите, что
> именно он делает.

Посмотрел.
Вызывает /etc/net/scripts/ifdown-ppp
А тот $IP link set dev $NAME down

> > > Скорее оно не поднято по какой-то причине.
> > 
> > Оно поднято, что видно из логов.
> 
> По логу видно, что поднятно, не спорю. Вопрос, что по факту - это раз, какой
> syslog - это два.

Обычный сислог "из коробки". Локальный, если вы на это намекаете.

> > Логи приведены в первом посте. Посмотрите пожалуйста их с начало.
> 
> Я видел. Вы их неправильно интерпретируете, по крайней мере, в районе понимания
> функций скрипта ip-down.

Сомневаюсь, что именно я не правильно интерпретирую.
Comment 10 MisHel64 2010-08-23 17:06:02 MSD
Created attachment 4504 [details]
ifdown-ppp
Comment 11 MisHel64 2010-08-23 17:06:53 MSD
Created attachment 4505 [details]
ip-down
Comment 12 Sergey Y. Afonin 2010-08-23 17:35:55 MSD
(In reply to comment #9)

> Вызывает /etc/net/scripts/ifdown-ppp

Блин, просмотрел. Действительно вызывает. Тогда вопрос к автору изменения, какова цель этого действия. Что-то я, пока, сообразить не могу.
Comment 13 MisHel64 2010-08-23 17:48:25 MSD
То, что вызывает, это не страшно, и IMHO нужно.
А вот то, что начинает устанавливать новое соединение, до завершения работы скрипта от старого, вот не кошерно, и порождает уже около года ошибку.

Да уж, скоро три месяца как бага висит...
Comment 14 Sergey Y. Afonin 2010-08-23 18:04:15 MSD
(In reply to comment #13)

> То, что вызывает, это не страшно, и IMHO нужно.

Зачем ?

> А вот то, что начинает устанавливать новое соединение, до завершения работы
> скрипта от старого, вот не кошерно, и порождает уже около года ошибку.

На сколько я понимаю, это просто особенность pppd. А когда-то давно не вызывался ifdown-ppp. Хотя вот сейчас смотрю, это есть ешё в ppp-common-0.4.2-alt1, который входил в 4.0.
Comment 15 Sergey Y. Afonin 2010-08-23 18:12:13 MSD
2pilot: Судя по
http://git.altlinux.org/people/ldv/packages/?p=ppp-common.git;a=commitdiff;h=bbb997a85edf3da618349b3ecb05aa6443f97993
оно там изначально. Не вспомнишь, зачем 

+case $CONFMETHOD in
+       etcnet)
+               # Just do nothing atm (no ppp support in /etc/net).
+#              exec $ETCNET_IFDOWN $REALDEVICE
+       ;;
+       *)
+               exec $NS_IFDOWN "ifcfg-$LOGDEVICE"
+       ;;
+esac

в /etc/ppp/ip-down ? Судя по логу, pppd успевает реконект до его завершения сделать, а завершения вовсе не ждёт.
Comment 16 MisHel64 2010-08-23 18:40:26 MSD
(В ответ на комментарий №14)
> (In reply to comment #13)
> 
> > То, что вызывает, это не страшно, и IMHO нужно.
> 
> Зачем ?

Не знаю. Наверное нужно, что бы убрать что нибудь.

> > А вот то, что начинает устанавливать новое соединение, до завершения работы
> > скрипта от старого, вот не кошерно, и порождает уже около года ошибку.
> 
> На сколько я понимаю, это просто особенность pppd. А когда-то давно не
> вызывался ifdown-ppp. Хотя вот сейчас смотрю, это есть ешё в
> ppp-common-0.4.2-alt1, который входил в 4.0.

В ALS401 это работало нормально, по крайней мере в мае прошлого года у меня подобной проблемы не было. Информация об этом странном поведении промелькнула прошлым летом в рассылках. Я то же наступив на эти грабли, не стал разбираться, перенес PPPd на железный роутер.
Comment 17 MisHel64 2010-08-23 18:43:54 MSD
(В ответ на комментарий №15)
> Судя по логу, pppd успевает реконект до его завершения
> сделать, а завершения вовсе не ждёт.

А я это еще в пятом комментарии писал. А вы мне не верили.
Comment 18 Sergey Y. Afonin 2010-08-23 19:17:05 MSD
(In reply to comment #17)

> > Судя по логу, pppd успевает реконект до его завершения
> > сделать, а завершения вовсе не ждёт.
> 
> А я это еще в пятом комментарии писал. А вы мне не верили.

Я не верил, что в ip-down вызывается что-то, что влияет на сам pppd.
Comment 19 Sergey Y. Afonin 2010-09-21 15:53:10 MSD
Думаю, надо закрыть этот баг в пользу двух других, так как тут смысл уже теряется за написанным.
Bug #24130
Bug #24131