Bug 30449 - При запуске `ifup ppp' связь устанавливается и тут же обрывается
Summary: При запуске `ifup ppp' связь устанавливается и тут же обрывается
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: ppp (show other bugs)
Version: unstable
Hardware: x86 Linux
: P3 normal
Assignee: Michael Shigorin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-06 07:10 MSK by Eugine V. Kosenko
Modified: 2015-01-30 14:57 MSK (History)
10 users (show)

See Also:


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

Поискал у себя на машинах - ничего такого не вижу, pppd работает без проблем. x86_64/systemd и i586/sysvinit, NM нигде нету.
Comment 2 Eugine V. Kosenko 2014-11-06 08:08:27 MSK
(В ответ на комментарий №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 Anton Farygin 2014-11-06 12:45:19 MSK
попробуйте поотлажитвать с помощью audit
включить полное протоколирование действий над процессом pppd и посмотреть от кого получен сигнал.
Comment 4 Eugine V. Kosenko 2014-11-09 18:40:57 MSK
Путем упрощения ситуации удалось выяснить, что 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 Eugine V. Kosenko 2014-11-09 19:05:26 MSK
Created attachment 6165 [details]
Комплект настроек ppp0 для etcnet
Comment 6 Eugine V. Kosenko 2014-11-09 19:06:45 MSK
Created attachment 6166 [details]
Сценарий, при запуске которого pppd сразу закрывает соединение
Comment 7 Eugine V. Kosenko 2014-11-09 19:07:46 MSK
Created attachment 6167 [details]
Результат autrace pppd из консоли
Comment 8 Eugine V. Kosenko 2014-11-09 19:08:35 MSK
Created attachment 6168 [details]
Результат autrace pppd из сценария
Comment 9 Eugine V. Kosenko 2014-11-09 19:12:16 MSK
Похоже, когда pppd запускается из сценария, он работает в новом окружении. При завершении сценария bash закрывает окружение и вызванный pppd. Пока что нет времени еще больше упростить задачу и поиграть с возможностями eval/exec в сценарии.

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

Продолжение следует...
Comment 10 Eugine V. Kosenko 2014-11-10 11:06:58 MSK
Да, проблема именно в запуске 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 Andrew Kornilov 2014-11-10 11:11:42 MSK
В порядке бреда: а не связано ли это с новыми bash-ем, где исправили всякие CVE, но, возможно, что-то привнесли с собой?
Comment 12 Eugine V. Kosenko 2014-11-10 11:20:49 MSK
Created attachment 6169 [details]
Промежуточное решение в etcnet

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

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

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

# ash ./test.sh

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

Позже попробую подшаманить правильный вызов ifup через (d)ash, но думаю, что решать проблему, похоже, придется таки в bash. Посему опять перевешиваю пакет.
Comment 14 Eugine V. Kosenko 2014-11-10 11:40:42 MSK
# rpm -q bash
bash-3.2.54-alt1
Comment 15 Andrew Kornilov 2014-11-10 11:49:14 MSK
(In reply to comment #13)
> Очевидно! Запуск
> # ash ./test.sh
> Проходит удачно!
> Позже попробую подшаманить правильный вызов ifup через (d)ash, но думаю, что
> решать проблему, похоже, придется таки в bash. Посему опять перевешиваю пакет.
Возможно, это все-таки и не bash виноват, просто в нем усилили контроль за чем-то, а ppp не по стандарту делает что-то, вот его и посылает bash. 
Тут надо вызывать тяжелую артиллерию в лице ldv@ или vsu@.
Comment 16 Evgenii Terechkov 2014-11-10 11:50:35 MSK
Можно попробовать пооткатываться на более старые версии bash чтобы точнее выяснить момент поломки.
Comment 17 Evgenii Terechkov 2014-11-10 11:51:18 MSK
Плюс, странно тогда что у меня нигде на PPPTYPE=pptp не наблюдается.
Comment 18 stalker 2014-11-10 11:58:54 MSK
Странно. 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 Eugine V. Kosenko 2014-11-10 20:51:01 MSK
(В ответ на комментарий №16)
> Можно попробовать пооткатываться на более старые версии bash чтобы точнее
> выяснить момент поломки.

А как это корректно сделать в рамках Сизифа?
Comment 20 Evgenii Terechkov 2014-11-10 21:00:04 MSK
Насколько я понимаю, посмотреть rpm -q --changelog bash на предмет дат обновлений и потом подключая по очереди срезы Сизифа за определённую дату (см. http://www.altlinux.org/Archive) пытаться откатывать пакет на более старую версию (apt-get install bash=x.y.z-rel).
Comment 21 Eugine V. Kosenko 2014-11-10 23:34:36 MSK
Обнаружил еще один странный момент. Если выбросить из /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 Eugine V. Kosenko 2014-11-11 13:37:18 MSK
(В ответ на комментарий №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 Andrew Kornilov 2014-11-11 17:52:16 MSK
Не думаю, что за 2.5 года никто не пользовался ppp в ALT-е , даже у нас он используется.
Проверяйте на чистой установке, проверяйте свой bash и систему, может вообще вам трояна кто-то засадил.
Comment 24 Eugine V. Kosenko 2014-11-11 18:29:33 MSK
Created attachment 6172 [details]
Еще одно промежуточное решение

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

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

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

> Проверяйте на чистой установке, проверяйте свой bash и систему,
> может вообще вам трояна кто-то засадил.
У меня-то тоже сломалось.
Comment 27 stalker 2014-11-11 20:41:33 MSK
хм. а как же он оу меня на 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 Eugine V. Kosenko 2014-11-12 06:58:10 MSK
(В ответ на комментарий №25)

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

Увы, не на моей машинке с 512М оперативы, 10Гб дискового пространства и простым целероном.
Comment 29 Eugine V. Kosenko 2014-11-12 07:03:45 MSK
(В ответ на комментарий №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 Eugine V. Kosenko 2014-11-12 07:23:07 MSK
Только что проверил --- проблема устойчиво воспроизводится в bash, dash (ash), zsh и tcsh. Так что, похоже, от типа оболочки ничего не зависит. Почему у меня раньше работало в ash, уже не скажу --- с тех пор прошла переустановка системы.
Comment 31 Eugine V. Kosenko 2014-11-12 07:58:34 MSK
Посмотрел сейчас еще раз внимательно запуск 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 freuser 2014-11-18 00:09:40 MSK
Проверено для шебанга 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 Eugine V. Kosenko 2014-12-20 19:26:24 MSK
Обнаружилась еще одна особенность. Если добавить в pppoptions ключи persist и 'holdoff 5', то сначала pppd соединяется и тут же разъединяется, как и было описано раньше. Однако через 5 секунд (время задано в holdoff) pppd сам пытается соединиться повторно, и на сей раз все получается успешно.
Comment 34 Anton Farygin 2015-01-30 13:00:08 MSK
Вот и мы её словили на openl2tp.
Comment 35 Anton Farygin 2015-01-30 14:57:22 MSK
а pppd под strace никто не догадался запустить ?
мы свою проблему решили - это в openl2tp сокет лежал в "нестандартном" для ppp пути в /var/run/
теперь не падает.