Bug 23556 - PPPoE падает, и подняться не может.
: PPPoE падает, и подняться не может.
Status: CLOSED WONTFIX
: Sisyphus
(All bugs in Sisyphus/ppp)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2010-05-30 21:26 by
Modified: 2010-09-21 15:54 (History)


Attachments
ifdown-ppp (1.18 KB, text/plain)
2010-08-23 17:06, MisHel64
no flags Details
ip-down (1.38 KB, text/plain)
2010-08-23 17:06, MisHel64
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


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

Давно  было  подозрение,  что  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 From 2010-05-30 21:45:53 -------
Это нормальное поведение 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 From 2010-05-30 22:53:45 -------
Ну во первых данная ошибки ни коем образом не дублирует ошибку 12382.
Во вторых, все написанное вами не имеет отношения к проблеме.
В третьих, еще год назад все нормально работало. Что, где и когда поломали
точнее затрудняюсь ответить. Долго не пользовался продукцией альтов.

Я правильно понял смысл вашего ответа, не только чинить, но иразбиратся в
вопросе никто не будет, и единственное решение, это приделать костыли?
------- Comment #3 From 2010-06-12 12:08:15 -------
(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 From 2010-08-22 23:35:56 -------
(In reply to comment #2)

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

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

Значение maxfail 3 ему по барабану в этом случае.
------- Comment #6 From 2010-08-23 15:50:07 -------
(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 From 2010-08-23 16:28:15 -------
(В ответ на комментарий №6)
> (In reply to comment #5)
> 
> > Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до
> > конца скриптом /etc/ppp/ip-down прибивается,
> 
> Чем-чем прибивается ?! :-)

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

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

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

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

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

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

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

Нет.

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

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

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

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

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

Я видел. Вы их неправильно интерпретируете, по крайней мере, в районе понимания
функций скрипта ip-down.
------- Comment #9 From 2010-08-23 17:03:18 -------
(В ответ на комментарий №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 From 2010-08-23 17:06:02 -------
Created an attachment (id=4504) [details]
ifdown-ppp
------- Comment #11 From 2010-08-23 17:06:53 -------
Created an attachment (id=4505) [details]
ip-down
------- Comment #12 From 2010-08-23 17:35:55 -------
(In reply to comment #9)

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

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

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

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

Зачем ?

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

На сколько я понимаю, это просто особенность pppd. А когда-то давно не
вызывался ifdown-ppp. Хотя вот сейчас смотрю, это есть ешё в
ppp-common-0.4.2-alt1, который входил в 4.0.
------- Comment #15 From 2010-08-23 18:12:13 -------
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 From 2010-08-23 18:40:26 -------
(В ответ на комментарий №14)
> (In reply to comment #13)
> 
> > То, что вызывает, это не страшно, и IMHO нужно.
> 
> Зачем ?

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

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

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

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

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

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