Bug 30449 - При запуске `ifup ppp' связь устанавливается и тут же обрывается
: При запуске `ifup ppp' связь устанавливается и тут же обрывается
Status: NEW
: Sisyphus
(All bugs in Sisyphus/ppp)
: unstable
: x86 Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2014-11-06 07:10 by
Modified: 2015-01-30 14:57 (History)


Attachments
Комплект настроек ppp0 для etcnet (811 bytes, application/octet-stream)
2014-11-09 19:05, Eugine V. Kosenko
no flags Details
Сценарий, при запуске которого pppd сразу закрывает соединение (226 bytes, application/x-shellscript)
2014-11-09 19:06, Eugine V. Kosenko
no flags Details
Результат autrace pppd из консоли (9.11 KB, application/gzip)
2014-11-09 19:07, Eugine V. Kosenko
no flags Details
Результат autrace pppd из сценария (9.13 KB, application/gzip)
2014-11-09 19:08, Eugine V. Kosenko
no flags Details
Промежуточное решение в etcnet (841 bytes, patch)
2014-11-10 11:20, Eugine V. Kosenko
no flags Details | Diff
Еще одно промежуточное решение (831 bytes, patch)
2014-11-11 18:29, Eugine V. Kosenko
no flags Details | Diff


Note

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


Description From 2014-11-06 07:10:45
Изначально я столкнулся с этой проблемой в P7, причем обновление до Сизифа не
помогло:

http://lists.altlinux.org/pipermail/sisyphus/2014-November/363127.html

Чуть позже нашел описание аналогичной проблемы у другого человека в P7:

http://lists.altlinux.org/pipermail/community/2014-November/682884.html

Возможно, это как-то связано с поведением NetworkManager:

https://bugzilla.altlinux.org/show_bug.cgi?id=28419

Не знаю, связано ли это с самим NM, etcnet или pppd. Я не силен в сетевой
инфраструктуре ALTLinux. Так что, вешаю проблему туда, где ее обнаружил.
------- Comment #1 From 2014-11-06 07:29:02 -------
По логу в рассылке это похоже на локальную проблему. А именно, кто-то после
поднятия туннеля шлёт SIGHUP процессу pppd. Кто это - надо искать на месте.

Поискал у себя на машинах - ничего такого не вижу, pppd работает без проблем.
x86_64/systemd и i586/sysvinit, NM нигде нету.
------- Comment #2 From 2014-11-06 08:08:27 -------
(В ответ на комментарий №1)
> Кто-то после поднятия туннеля шлёт SIGHUP процессу pppd.

А можно ли узнать, кто именно шлет этот самый SIGHUP? В рассылке я отписал, что
указание `nodetach' в опциях pppd частично решает проблему. А именно, после
этого `ifup ppp0', конечно же, не завершается, но и разъединения не происходит.
Достаточно просто запустить `ifup ppp0 &', то есть, в фоне.

> Кто это - надо искать на месте.

Какой журнал смотреть? Вот, например, фрагмент /var/log/messages при включенных
опциях pppd `dump' и `debug':

Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: pppd options in effect:
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: debug^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: updetach^I^I# (from command
line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: nolog^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: unit 0^I^I# (from command
line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: dump^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: noauth^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: user gdata^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: password ??????^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: /dev/ttyACM0^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: lock^I^I# (from
/etc/ppp/options)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: connect /usr/sbin/chat -t
120 -f /etc/net/ifaces/ppp0/pppconnect^I^I# (from command line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: disconnect /usr/sbin/chat
-t 120 -f /etc/net/ifaces/ppp0/pppdisconnect^I^I# (from command line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: modem^I^I# (from command
line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: noaccomp^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: nopcomp^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: lcp-echo-failure 0^I^I#
(from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: lcp-echo-interval 0^I^I#
(from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: receive-all^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: novj^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: novjccomp^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: noipdefault^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: defaultroute^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: replacedefaultroute^I^I#
(from /etc/ppp/options)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: usepeerdns^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: :10.6.6.6^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: nobsdcomp^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: nodeflate^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: pppd 2.4.5 started by
maverik, uid 0
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: Script /usr/sbin/chat -t
120 -f /etc/net/ifaces/ppp0/pppconnect finished (pid 3256), status = 0x0
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: Serial connection
established.
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: Using interface ppp0
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: Connect: ppp0 <-->
/dev/ttyACM0
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: replacing old default route
to eth1 [192.168.0.2]
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: local  IP address
xxx.xxx.xxx.xxx
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: remote IP address 10.6.6.6
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: primary   DNS address
xxx.xxx.xxx.xxx
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: secondary DNS address
xxx.xxx.xxx.xxx
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Hangup (SIGHUP)
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Modem hangup
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Connect time 0.0 minutes.
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Sent 0 bytes, received 0
bytes.
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: restoring old default route
to eth1 [192.168.0.2]
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Connection terminated.
Nov  6 08:55:57 comp-celeron-cpu-3a87ac pppd[3259]: Script /etc/ppp/ip-up
finished (pid 3260), status = 0x0
Nov  6 08:55:58 comp-celeron-cpu-3a87ac pppd[3259]: Script /etc/ppp/ip-down
finished (pid 3376), status = 0x1
Nov  6 08:55:58 comp-celeron-cpu-3a87ac pppd[3259]: Exit.

Как еще проверить, кто именно шлет сигнал на остановку? И опять же, включение
опции `detach' не разрывает соединения. Сравните:

Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: pppd options in effect:
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: debug^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nodetach^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nolog^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: unit 0^I^I# (from command
line)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: dump^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: noauth^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: user gdata^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: password ??????^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: /dev/ttyACM0^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: lock^I^I# (from
/etc/ppp/options)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: connect /usr/sbin/chat -t
120 -f /etc/net/ifaces/ppp0/pppconnect^I^I# (from command line)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: disconnect /usr/sbin/chat
-t 120 -f /etc/net/ifaces/ppp0/pppdisconnect^I^I# (from command line)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: modem^I^I# (from command
line)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: noaccomp^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nopcomp^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: lcp-echo-failure 0^I^I#
(from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: lcp-echo-interval 0^I^I#
(from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: receive-all^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: novj^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: novjccomp^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: noipdefault^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: defaultroute^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: replacedefaultroute^I^I#
(from /etc/ppp/options)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: usepeerdns^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: :10.6.6.6^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nobsdcomp^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nodeflate^I^I# (from
/etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: pppd 2.4.5 started by
maverik, uid 0
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: Script /usr/sbin/chat -t
120 -f /etc/net/ifaces/ppp0/pppconnect finished (pid 3608), status = 0x0
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: Serial connection
established.
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: Using interface ppp0
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: Connect: ppp0 <-->
/dev/ttyACM0
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: replacing old default route
to eth1 [192.168.0.2]
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: local  IP address
xxx.xxx.xxx.xxx
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: remote IP address 10.6.6.6
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: primary   DNS address
xxx.xxx.xxx.xxx
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: secondary DNS address
xxx.xxx.xxx.xxx
Nov  6 09:01:51 comp-celeron-cpu-3a87ac pppd[3607]: Script /etc/ppp/ip-up
finished (pid 3612), status = 0x0

> NM нигде нету.

Ну и у меня, похоже, нету. Значит, проблема все же в etcnet?
------- Comment #3 From 2014-11-06 12:45:19 -------
попробуйте поотлажитвать с помощью audit
включить полное протоколирование действий над процессом pppd и посмотреть от
кого получен сигнал.
------- Comment #4 From 2014-11-09 18:40:57 -------
Путем упрощения ситуации удалось выяснить, что etcnet тут вообще ни при чем. И
проблема именно в pppd и именно такая, как описано в рассылке

http://lists.altlinux.org/pipermail/community/2014-November/682884.html

По сути можно запустить просто из консоли

/usr/sbin/pppd file /etc/net/ifaces/ppp0/pppoptions connect '/usr/sbin/chat -t
15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f
/etc/net/ifaces/ppp0/pppdisconnect'

и все будет работать. Если в точности ту же строку поместить в скрипт,
например, ppp-test.sh и исполнить его в командной строке, то pppd будет
завершен аварийно. Файлы, относящиеся к этому примеру я выложу дополнительно.
------- Comment #5 From 2014-11-09 19:05:26 -------
Created an attachment (id=6165) [details]
Комплект настроек ppp0 для etcnet
------- Comment #6 From 2014-11-09 19:06:45 -------
Created an attachment (id=6166) [details]
Сценарий, при запуске которого pppd сразу закрывает соединение
------- Comment #7 From 2014-11-09 19:07:46 -------
Created an attachment (id=6167) [details]
Результат autrace pppd из консоли
------- Comment #8 From 2014-11-09 19:08:35 -------
Created an attachment (id=6168) [details]
Результат autrace pppd из сценария
------- Comment #9 From 2014-11-09 19:12:16 -------
Похоже, когда pppd запускается из сценария, он работает в новом окружении. При
завершении сценария bash закрывает окружение и вызванный pppd. Пока что нет
времени еще больше упростить задачу и поиграть с возможностями eval/exec в
сценарии.

Кроме того, autrace для меня --- темный лес. Приложил журналы трассировки, но в
обоих есть вызов SIGHUP. К тому же, я так и не понял, кто вызывает SIGHUP для
pppd. Пожалуйста, помогите в интерпретации журналов. Возможно, нужны более
тонкие опции autrace, подскажите, если нужно.

Продолжение следует...
------- Comment #10 From 2014-11-10 11:06:58 -------
Да, проблема именно в запуске pppd в новом окружении. То есть, для
воспроизведения проблемы достаточно запустить из командной строки следующим
образом:

# $(/usr/sbin/pppd file /etc/net/ifaces/ppp0/pppoptions connect '/usr/sbin/chat
-t 15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f
/etc/net/ifaces/ppp0/pppdisconnect')

Вначале pppd стартует, а потом сразу же останавливается.

Есть интересная особенность: игнорируется даже простая задержка сразу после
вызова. Например, при таком вызове:

# $(/usr/sbin/pppd file /etc/net/ifaces/ppp0/pppoptions connect '/usr/sbin/chat
-t 15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f
/etc/net/ifaces/ppp0/pppdisconnect'; sleep 10)

pppd будет остановлен сразу же после входа, не дожидаясь окончания задержки.

Естественно, что если в сценарии стоит вызов pppd через exec, то все работает
хорошо. Но этот путь неприемлем при настройке etcnet.

Даже не знаю, стоит ли шаманить с audit? Ведь суть проблемы и так очевидна.
------- Comment #11 From 2014-11-10 11:11:42 -------
В порядке бреда: а не связано ли это с новыми bash-ем, где исправили всякие
CVE, но, возможно, что-то привнесли с собой?
------- Comment #12 From 2014-11-10 11:20:49 -------
Created an attachment (id=6169) [details]
Промежуточное решение в etcnet

Вот небольшая правка скрипта /etc/net/scripts/create-ppp, которая позволяет
обойти эту проблему.

Решение не очень надежное, так как предполагается, что для запуска pppd
потребуется не больше 5 секунд, при этом пользователь не настраивает updetach в
pppoptions.
------- Comment #13 From 2014-11-10 11:35:53 -------
(В ответ на комментарий №11)
> В порядке бреда: а не связано ли это с новыми bash-ем, где исправили всякие
> CVE, но, возможно, что-то привнесли с собой?

Очевидно! Запуск

# ash ./test.sh

Проходит удачно!

Позже попробую подшаманить правильный вызов ifup через (d)ash, но думаю, что
решать проблему, похоже, придется таки в bash. Посему опять перевешиваю пакет.
------- Comment #14 From 2014-11-10 11:40:42 -------
# rpm -q bash
bash-3.2.54-alt1
------- Comment #15 From 2014-11-10 11:49:14 -------
(In reply to comment #13)
> Очевидно! Запуск
> # ash ./test.sh
> Проходит удачно!
> Позже попробую подшаманить правильный вызов ifup через (d)ash, но думаю, что
> решать проблему, похоже, придется таки в bash. Посему опять перевешиваю пакет.
Возможно, это все-таки и не bash виноват, просто в нем усилили контроль за
чем-то, а ppp не по стандарту делает что-то, вот его и посылает bash. 
Тут надо вызывать тяжелую артиллерию в лице ldv@ или vsu@.
------- Comment #16 From 2014-11-10 11:50:35 -------
Можно попробовать пооткатываться на более старые версии bash чтобы точнее
выяснить момент поломки.
------- Comment #17 From 2014-11-10 11:51:18 -------
Плюс, странно тогда что у меня нигде на PPPTYPE=pptp не наблюдается.
------- Comment #18 From 2014-11-10 11:58:54 -------
Странно. p7+ ядерный pppoe работает нормально из etcnet
rpm -qa | grep bash
bash-builtin-lockf-0.3.1-alt1.qa1
bash-3.2.54-alt0.M70P.1

Единственное что -у меня pppoe в ядерном пространстве
(http://lists.altlinux.org/pipermail/sysadmins/2013-June/036152.html)
------- Comment #19 From 2014-11-10 20:51:01 -------
(В ответ на комментарий №16)
> Можно попробовать пооткатываться на более старые версии bash чтобы точнее
> выяснить момент поломки.

А как это корректно сделать в рамках Сизифа?
------- Comment #20 From 2014-11-10 21:00:04 -------
Насколько я понимаю, посмотреть rpm -q --changelog bash на предмет дат
обновлений и потом подключая по очереди срезы Сизифа за определённую дату (см.
http://www.altlinux.org/Archive) пытаться откатывать пакет на более старую
версию (apt-get install bash=x.y.z-rel).
------- Comment #21 From 2014-11-10 23:34:36 -------
Обнаружил еще один странный момент. Если выбросить из
/etc/net/ifaces/ppp0/pppoptions установку updetach/nodetach, а также не указать
эту опцию в командной строке:

# $(/usr/sbin/pppd file /etc/net/ifaces/ppp0/pppoptions connect '/usr/sbin/chat
-t 15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f
/etc/net/ifaces/ppp0/pppdisconnect')

То запуск pppd проходит успешно. То же самое, если запустить pppd таким же
образом из сценария. Однако, если в /etc/net/scripts/create-ppp также убрать
опцию updetach из задания BASIC_PPPOPTIONS, то, хоть pppd и запускается
успешно, но делает он это слишком быстро, поэтому дальше возникает ошибка
`Cannot find device ppp0' при попытке настроить QoS. В результате оказывается,
что pppd запущен, но QoS не настроено. Приходится добавлять `sleep 5' при таком
запуске pppd из /etc/net/scripts/create-ppp.

Однако, если добавить опцию updetach в вызов, например, так:

# $(/usr/sbin/pppd updetach file /etc/net/ifaces/ppp0/pppoptions connect
'/usr/sbin/chat
-t 15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f
/etc/net/ifaces/ppp0/pppdisconnect')

то проблема стабильно остается. Очень похоже, что даже если пробема и не в
pppd, то где-то на стыке bash и pppd. Потому что непонятно, как может
отличаться поведение pppd в одной и той же версии bash, если использовать опцию
по умолчанию без ее явного указания и с явным указанием той же опции?

Ситуация полностью повторяется при работе в bash4.

Кстати, pptp я не использую --- у меня только простейший dialup.
------- Comment #22 From 2014-11-11 13:37:18 -------
(В ответ на комментарий №20)
> Насколько я понимаю, посмотреть rpm -q --changelog bash на предмет дат
> обновлений и потом подключая по очереди срезы Сизифа за определённую дату (см.
> http://www.altlinux.org/Archive) пытаться откатывать пакет на более старую
> версию (apt-get install bash=x.y.z-rel).

Самый ранний архив Сизифа, который я смог найти --- от 11 июля 2012 года. Там
bash и ppp почти тех же самых версий:

# rpm -q bash sh ppp
bash-3.2.51-alt1
sh-3.2.51-alt1
ppp-2.4.5-alt10

Проблема устойчиво повторяется при тех же условиях. Судя по журналу, правки в
bash, которые могли вызвать эту ситуацию датируются исключительно этим годом.
Пакеты в P7, где проблема была обнаружена в самом начале, датированы еще
ноябрем прошлого года. По журналу изменение это еще задолго до всех правок,
связанных с CVE.

В общем, похоже, глюк очень серьезный. У себя я использую обходное решение,
которое опубликую здесь чуть позже. На дальнейшее копание в проблеме уже просто
не осталось сил.
------- Comment #23 From 2014-11-11 17:52:16 -------
Не думаю, что за 2.5 года никто не пользовался ppp в ALT-е , даже у нас он
используется.
Проверяйте на чистой установке, проверяйте свой bash и систему, может вообще
вам трояна кто-то засадил.
------- Comment #24 From 2014-11-11 18:29:33 -------
Created an attachment (id=6172) [details]
Еще одно промежуточное решение

Это решение мне нравится больше, так как делает меньше изменений. По сути оно
просто убирает предустановленную опцию updetach и добавляет 5-секундную
задержку после запуска pppd. Последнее нужно только лишь потому, что pppd без
явно заданного updetach/nodetach отпускает консоль слишком быстро, и
последующие действия в сценарии не успевают найти поднятый интерфейс ppp0.
------- Comment #25 From 2014-11-11 18:43:15 -------
(In reply to comment #24)
> Created an attachment (id=6172) [details] [details]
> Еще одно промежуточное решение
> 
> Это решение мне нравится больше, так как делает меньше изменений. По сути оно
> просто убирает предустановленную опцию updetach и добавляет 5-секундную
> задержку после запуска pppd. Последнее нужно только лишь потому, что pppd без
> явно заданного updetach/nodetach отпускает консоль слишком быстро, и
> последующие действия в сценарии не успевают найти поднятый интерфейс ppp0.

Мне кажется, sleep-ы это не самое верное решение. На вашей машине sleep 5
хватает, а на какой-то и sleep 20 не хватит. Нужно искать корень проблемы и от
него избавляться/чинить.

Проверьте в виртуалке, поставьте минимальный сизиф в неё, например.
------- Comment #26 From 2014-11-11 20:01:12 -------
(В ответ на комментарий №23)
> Не думаю, что за 2.5 года никто не пользовался ppp в ALT-е
Пытался этим летом или прошлым, не помню точно.

> Проверяйте на чистой установке, проверяйте свой bash и систему,
> может вообще вам трояна кто-то засадил.
У меня-то тоже сломалось.
------- Comment #27 From 2014-11-11 20:41:33 -------
хм. а как же он оу меня на pppoe работает на p7

noipdefault
noauth
default-asyncmap
defaultroute
hide-password
mtu 1492
mru 1492
noaccomp
noccp
nobsdcomp
nodeflate
nopcomp
novj
novjccomp
user stalker
password *****
lcp-echo-interval 20
lcp-echo-failure 3
------- Comment #28 From 2014-11-12 06:58:10 -------
(В ответ на комментарий №25)

> Проверьте в виртуалке, поставьте минимальный сизиф в неё, например.

Увы, не на моей машинке с 512М оперативы, 10Гб дискового пространства и простым
целероном.
------- Comment #29 From 2014-11-12 07:03:45 -------
(В ответ на комментарий №23)
> Не думаю, что за 2.5 года никто не пользовался ppp в ALT-е , даже у нас он
> используется.
> Проверяйте на чистой установке, проверяйте свой bash и систему, может вообще
> вам трояна кто-то засадил.

Да в том-то и дело, что система чистая, как стекло. Только сегодня в результате
игры с Сизифом пришлось переустановить ее с нуля. Эффект стабильный. Пока что
пользуюсь предложенным промежуточным решением, хотя и сам знаю, что sleep ---
это очень ненадежно. Немного резюмирую результаты.

1. Похоже, проблема не зависит от свежих правок. Откат на самые старые версии
вплоть до апреля 2012 года ничего не дает --- проблема остается.

2. Может быть, что проблема проявляется только при PPPTYPE=dialup, так как ни
pptp ни pppoe я не использую.

2. Проблема как-то связана с оболочкой bash. А именно, возникает она только при
запуске pppd из сценария или из командной строки в новом окружении, например,
так:

# $(/usr/sbin/pppd ...)

При вызове той же самой команды или сценария из ash (dash) проблема не
возникает. С csh/tcsh/zsh/... из того же зоопарка я не проверял, похоже, тема
для отдельного исследования.

3. Подозреваю, что проблема все же в pppd. Об этом говорит различное выполнение
команд

# $(/usr/sbin/pppd ...)

и

# $(/usr/sbin/pppd updetach ...)

Во втором случае проблема возникает, в первом --- нет, pppd запускается и
держит связь. Однако в этом случае pppd отпускает консоль еще _до того_, как
поднят интерфейс ppp0. В командной строке это некритично, но команды в сценарии
(например, настройки сети ifup-common), следующие сразу за запуском pppd все
еще не видят интерфейс ppp0. В промежуточном решении пришлось вставить 'sleep
5', чтобы интерфейс успел подняться до выполнения следующих действий.

4. На основании п.3 возникло подозрение, что проблема как-то связана с гонками
при запуске pppd только на относительно медленных машинках типа моей:

# cat /proc/cpuinfo 
model name      : Intel(R) Celeron(R) CPU 1.70GHz
stepping        : 3
microcode       : 0x4
cpu MHz         : 1700.084
cache size      : 128 KB
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pebs bts
bogomips        : 3400.16

Думаю, именно по этой причине проблема не воспроизводится на других, более
быстрых машинах. Увы, проверить сейчас этого не могу, так как других машин под
рукой нет.
------- Comment #30 From 2014-11-12 07:23:07 -------
Только что проверил --- проблема устойчиво воспроизводится в bash, dash (ash),
zsh и tcsh. Так что, похоже, от типа оболочки ничего не зависит. Почему у меня
раньше работало в ash, уже не скажу --- с тех пор прошла переустановка системы.
------- Comment #31 From 2014-11-12 07:58:34 -------
Посмотрел сейчас еще раз внимательно запуск pppd под autrace и обнаружил одну
неприятную деталь, которую не заметил раньше. При вызове типа

# autrace /usr/sbin/pppd ...

проблема опять возникает --- pppd сразу же после запуска разрывает соединение.
Именно поэтому выложенные мной раньше журналы autrace и оказались похожими.
Пока что думаю, как еще можно обмануть pppd, чтобы он нормально отработал под
autrace.

Ключевой момент здесь:

----
type=SYSCALL msg=audit(09.11.14 19:31:22.410:4056) : arch=i386
syscall=rt_sigaction success=yes exit=0 a0=SIGHUP a1=0xbf8496e4 a2=0x0 a3=0x8
items=0 ppid=17585 pid=17587 auid=maverik uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1 comm=pppd
exe=/usr/sbin/pppd key=(null)
----

Это единственнай вызов SIGHUP во всей трассе. Но как понять, кто инициировал
этот вызов?
------- Comment #32 From 2014-11-18 00:09:40 -------
Проверено для шебанга ash, dash, tcsh, sh, bash, zsh, sash. Везде одинаковое
поведение:
-- при наличии updetach в опциях после установления соединения тут же оно
обрывается.
-- если указать вместо updetach -- nodetach, то работает, но не отсоединяется
от родительского скрипта и блокирует его выполнение, если не загонять в фон.
-- если не указывать ни ту опцию, ни другую, то: в терминале (zsh и sh) сразу
завершается с кодом 0 (но в фоне пытается соединиться, если получается,
работает на pts c PPID=1); в скрипте работает оптимально ( передает дальше
управление по завершению выполнения (а не сразу), устанавливает соединение, не
завершает его, отсоединяется от скрипта и переходит на pts c PPID=1 ).

Возможно, ноги растут от баги #29832, там pppd в момент, где здесь он ловит
SIGHUP, получал segfault ядра. Так что дело может быть даже не в шелле, а в
ядре (заголовках/модулях/etc). Но та машина, где была та бага, эту не
воспроизводит. А на этом ноутбуке не было той баги.

/proc/cpuinfo (первая половина, про 1 ядро из 2-х)
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 20
model           : 2
model name      : AMD E-450 APU with Radeon(tm) HD Graphics
stepping        : 0
microcode       : 0x5000119
cpu MHz         : 1650.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 6
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm constant_tsc nonstop_tsc extd_apicid aperfmperf pni monitor ssse3
cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch ibs skinit wdt arat hw_pstate npt lbrv svm_lock nrip_save
pausefilter
bogomips        : 3292.99
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

cpufreq стоит на "performance" для обоих ядер.
------- Comment #33 From 2014-12-20 19:26:24 -------
Обнаружилась еще одна особенность. Если добавить в pppoptions ключи persist и
'holdoff 5', то сначала pppd соединяется и тут же разъединяется, как и было
описано раньше. Однако через 5 секунд (время задано в holdoff) pppd сам
пытается соединиться повторно, и на сей раз все получается успешно.
------- Comment #34 From 2015-01-30 13:00:08 -------
Вот и мы её словили на openl2tp.
------- Comment #35 From 2015-01-30 14:57:22 -------
а pppd под strace никто не догадался запустить ?
мы свою проблему решили - это в openl2tp сокет лежал в "нестандартном" для ppp
пути в /var/run/
теперь не падает.