Тупой баг с pptp

Render 18 апреля, 2007 - 15:39

Системное администрирование

Спутниковый инет, надо пптп туннель до провайдера.

соединение поднимаю через pptp-command скрипт:

ppp0 Link encap:Point-to-Point Protocol
inet addr:80.92.207.80 P-t-P:80.92.200.254 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:114211 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:40 (40.0 b) TX bytes:47894902 (45.6 Mb)

вот так поднимается и в TX пишет дикий трафик (50-80-100 мб), после чего тунель виснет (тупо висит ppp0 без адреса)

Параметры
/etc/ppp/options

lock
+chap
noauth
defaultroute

/etc/ppp/options.pptp

lock
noauth
nobsdcomp
nodeflate

система:
2.6.17-gentoo-r8
default-linux/x86/2006.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.17-gentoo-r8 i686

уже замаелся, в чем может быть проблема ?

Для комментирования войдите или зарегистрируйтесь

Может быть

Автор Subcreator, дата создания 18 апреля, 2007 - 17:58.

Может быть маршрут неправильный поднимается, - известный глюк pptp, покажи route -n

Для комментирования войдите или зарегистрируйтесь

...

Автор Render, дата создания 18 апреля, 2007 - 18:57.

маршруты до пптп

Цитата:

route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.100.100 0.0.0.0 255.255.255.255 UH 0 0 0 dvb0_0
192.168.245.0 0.0.0.0 255.255.255.192 U 0 0 0 eth1
172.16.100.0 0.0.0.0 255.255.255.0 U 0 0 0 dvb0_0
10.10.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2
192.168.0.0 192.168.245.1 255.255.0.0 UG 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 172.19.25.1 0.0.0.0 UG 0 0 0 eth2

172.19.25.1 - наземный шлюз

после подниятия туннеля роуты остаются прежними. Связь до ВПН шлюза есть, поэтому не должно выкидывать по таймауту. Соединение держится буквально 2-3 секунды, после чего ppp0 становится не активным:

ifconfig -a

Цитата:

ppp0 Link encap:Point-to-Point Protocol
POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:40 (40.0 b) TX bytes:46 (46.0 b)

в логах:

Цитата:

Apr 18 22:48:57 gw pptp[9333]: anon log[logecho:pptp_ctrl.c:676]: Echo Reply received.
Apr 18 22:49:57 gw pptp[9333]: anon log[logecho:pptp_ctrl.c:676]: Echo Reply received.
Apr 18 22:50:57 gw pptp[9333]: anon log[logecho:pptp_ctrl.c:676]: Echo Reply received.
Apr 18 22:51:47 gw pptp[9348]: anon warn[decaps_hdlc:pptp_gre.c:197]: short read (-1): Input/output error
Apr 18 22:51:47 gw pptp[9348]: anon warn[decaps_hdlc:pptp_gre.c:209]: pppd may have shutdown, see pppd log
Apr 18 22:51:47 gw pptp[9333]: anon log[callmgr_main:pptp_callmgr.c:231]: Closing connection (unhandled)
Apr 18 22:51:47 gw pptp[9333]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Apr 18 22:51:47 gw pptp[9333]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)
Apr 18 22:51:54 gw pptp[9757]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated
Apr 18 22:51:54 gw pptp[9760]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connectio
n-Request'
Apr 18 22:51:54 gw pptp[9760]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
Apr 18 22:51:54 gw pptp[9760]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
Apr 18 22:51:55 gw pptp[9760]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Apr 18 22:51:55 gw pptp[9760]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.
Apr 18 22:51:55 gw pptp[9760]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID
29184).
Apr 18 22:51:55 gw pppd[9762]: pppd 2.4.3 started by root, uid 0
Apr 18 22:51:55 gw pppd[9762]: Removed stale lock on pts_2 (pid 9335)
Apr 18 22:51:55 gw pppd[9762]: Using interface ppp0
Apr 18 22:51:55 gw pppd[9762]: Connect: ppp0 <--> /dev/pts/2
Apr 18 22:51:58 gw pppd[9762]: CHAP authentication succeeded: Welcome to io.ipdvb.ru.
Apr 18 22:51:58 gw pppd[9762]: CHAP authentication succeeded
Apr 18 22:51:58 gw pppd[9762]: local IP address 80.92.207.80
Apr 18 22:51:58 gw pppd[9762]: remote IP address 80.92.200.254
Apr 18 22:52:00 gw rc-scripts: No loaded modules provide "ppp" (ppp_start)
Apr 18 22:52:56 gw pptp[9760]: anon log[logecho:pptp_ctrl.c:676]: Echo Reply received.

почему-то рц ругается на модули хотя все загружено.

lsmod:

Цитата:

Module Size Used by
ppp_async 7680 1
ppp_generic 19988 5 ppp_async
slhc 5504 1 ppp_generic

Для комментирования войдите или зарегистрируйтесь

"после

Автор Subcreator, дата создания 18 апреля, 2007 - 22:25.

"после подниятия туннеля роуты остаются прежними"

я так понимаю, впн организуется поверх eth2
тогда после поднятия туннеля должен создаваться маршрут до впн-сервера, что-то вроде
80.92.200.254 172.19.25.1 255.255.255.255 UGH 0 0 0 eth2

собственно глюк про который я упоминал, это когда создается неправильный маршрут
80.92.200.254 172.19.25.1 255.255.255.255 UGH 0 0 0 ppp0
и весь трафик до впн сервера начинает идти в ppp0, - "в TX пишет дикий трафик", проверь может быть у тебя именно это, в таком случае после поднятия впн надо сразу либо 1) удалять этот ошибочный маршрут и заменять его правильным, либо 2) опять же удалять неправильный маршрут, но все маршруты до впн-серверов создавать заранее.

Для комментирования войдите или зарегистрируйтесь

Самое

Автор Render, дата создания 22 апреля, 2007 - 12:12.

Самое интересное, что туннель поднимается либо вручную (pppd call peer), либо через pptp-command.
через /etc/init.d/net.ppp0 - не работает. Пишет что нет модулей. Хотя они есть.
Еще интересней то, что после пересборки baselayout все это стало работать, однако перекосило всю rc подсистему. (shutdown.sh и прочее.. вываливает с кучей ошибок)