pppd undefined behavior :)

Короче хз как назвать тему, назвал как в голову пришло..
Для выхода в интернет использую GPRS и мобильник. Собственно, здесь пока проблемы нет никакой и всё вроде бы работает норм:

gentoo home # pppd call tele2
Serial connection established.
using channel 24
Using interface ppp0
Connect: ppp0 <--> /dev/rfcomm0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x953c0909>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x953c0909>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x19a426> <pcomp> <accomp>]
sent [LCP ConfRej id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth pap> <magic 0x19a4e3>]
sent [LCP ConfAck id=0x2 <asyncmap 0x0> <auth pap> <magic 0x19a4e3>]
sent [PAP AuthReq id=0x1 user="tele2" password=<hidden>]
rcvd [PAP AuthAck id=0x1]
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 90.138.219.36> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
sent [IPCP ConfReq id=0x2 <addr 90.138.219.36> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
rcvd [IPCP ConfAck id=0x2 <addr 90.138.219.36> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
rcvd [IPCP ConfReq id=0x3 <addr 192.168.100.101>]
sent [IPCP ConfAck id=0x3 <addr 192.168.100.101>]
local  IP address 90.138.219.36
remote IP address 192.168.100.101
primary   DNS address 130.244.127.161
secondary DNS address 130.244.127.169

Интерфейс нормально создаётся, и, в общем, как я уже говорил раньше, замечательно работает:

gentoo home # ifconfig

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:7034 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7034 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1177365 (1.1 MiB)  TX bytes:1177365 (1.1 MiB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:90.138.219.36  P-t-P:192.168.100.101  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:83 errors:0 dropped:0 overruns:0 frame:0
          TX packets:128 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:14971 (14.6 KiB)  TX bytes:10248 (10.0 KiB)

Засовываем это дело в скрипт. И тут начинается веселье:

gentoo home # cat /home/script/start-ppp 
#!/bin/sh

pppd call tele2

gentoo home #  /home/script/start-ppp
Serial connection established.
using channel 25
Using interface ppp0
Connect: ppp0 <--> /dev/rfcomm0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x953c0909>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x953c0909>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x19a426> <pcomp> <accomp>]
sent [LCP ConfRej id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth pap> <magic 0x19a4e3>]
sent [LCP ConfAck id=0x2 <asyncmap 0x0> <auth pap> <magic 0x19a4e3>]
sent [PAP AuthReq id=0x1 user="tele2" password=<hidden>]
rcvd [PAP AuthAck id=0x1]
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 90.138.219.36> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
sent [IPCP ConfReq id=0x2 <addr 90.138.219.36> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
rcvd [IPCP ConfAck id=0x2 <addr 90.138.219.36> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
rcvd [IPCP ConfReq id=0x3 <addr 192.168.100.101>]
sent [IPCP ConfAck id=0x3 <addr 192.168.100.101>]
local  IP address 90.138.219.36
remote IP address 192.168.100.101
primary   DNS address 130.244.127.161
secondary DNS address 130.244.127.169

Однако ни сетевого интерфейса, ни процесса pppd не создаётся. Точнее, складывается такое впечатление, что процесс создаётся и тут же благополучно завершается. Не веря своим глазам и не зная, с чего даже начать копать, я перепробовал всё это ещё много раз, попробовал менять shell-ы, но безрезультатно. Может быть кто-то знает, в чём причина столь любопытного поведения системы ?

P.S. Система Gentoo AMD-64. OpenRC. Baselayout 2.0

Попробуй воспользоваться

Попробуй воспользоваться стандартным инит скриптом.

Очень похожее поведение pppd

Очень похожее поведение pppd получил после очередного обновления месяца три назад. Если в конфигурации закоментарить параметр "updetach", то соединение поднимается сразу. Если раскоментарить, то соединение падает сразу после поднятия, правда процесс pppd остается и пытается поднять соединение автоматически после таймаута. По логам видно, что связь устанавливается только на 2-3 попытку.
А разница только в том, что в первом случае запускающий скрипт завершается сразу, не ожидая, пока соединение будет установлено, а во втором - ожидает установления соединения и после этого завершается с выводом полученного ip адреса.
Откат на предыдущую версию pppd решал проблему, но меня это не сильно напрягало, поэтому оставил так.
Система x86 собрана для i586, cpu Transmeta Crusoe 5600.

P.S. Пользуюсь стандартной настройкой ppp через /etc/conf.d/net

pppd

MVG написал(а):
Очень похожее поведение pppd получил после очередного обновления месяца три назад. Если в конфигурации закоментарить параметр "updetach", то соединение поднимается сразу. Если раскоментарить, то соединение падает сразу после поднятия, правда процесс pppd остается и пытается поднять соединение автоматически после таймаута. По логам видно, что связь устанавливается только на 2-3 попытку.
А разница только в том, что в первом случае запускающий скрипт завершается сразу, не ожидая, пока соединение будет установлено, а во втором - ожидает установления соединения и после этого завершается с выводом полученного ip адреса...

Мдя.. Как говорится, шаманство во всех его проявлениях...
P.S. Спасибо, дома попробую, отпишусь.

updetach

Ещё раз мдя...

Короче, действительно, если убрать updetach - это решает проблему. Баг что ли ? Хз - ставить [SOLVED] вроде как некошерно.

По-моему, это баг openrc. Он

По-моему, это баг openrc. Он сразу принудительно убирает pppd в фон, что видимо не нравится pppd... В предыдущей версии init ждал некоторое время.

Вы не правы. Использую

Вы не правы. Использую стабильную ветку.
Такое поведение зависит именно от версии pppd, читайте мой пост выше.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".