Регулярные падения PPTP при нагрузке

Сколько видел таких тем - нигде никогда ничего хорошего не выходило.
А можно просто для коллекции: какой толщины канал?

Канал толстый. С серверами моей страны выходит около 80 мбит/с. С бангладешем около 15 мбит/с

А есть ли какие аналоги pptpd под arch, если исключить networkmanager ?

Проблема практически наверняка не в pptpd, а в pppd, а от него никуда не деться.
Сунь 'kdebug 1' в /etc/ppp/options, или куда там это положено совать. Может, что-нибудь скажет.

Странный этот pppd. Только включил дебаг, теперь не могу заставить его упасть =@

А теперь гляди: http://linuxgazette.net/165/misc/lg/erratically_dying_pppd.html

Curiously enough- the number of times my connection dies (or PPPD dies) has considerably decreased (or even not happening), since I have started running 'pppd' in 'kdebug' mode

Отсюда видим: баг, как и предсказано, живет в pppd, и его никто так и не починил.
Там в треде народ с lcp играется, но по мне это довольно бессмысленная пляска с бубном.

Но должно же быть решение. Уже замучался я с этим pppd.

Должно-то должно, но вот похоже, что увы.
Dimez, обрати внимание. Если помнишь еще тот тред.
Это именно оно и есть: pppd, похоже, поломан от рождения, и никто его не чинит. Каналы толстеют, жалоб все больше. Рано или поздно придет человек из Кемерово, но пока приходится терпеть и городить костыли.

Проблема если и в pppd, то только в связке с pptp.

С l2tp оно работает кошерно и не глючит никогда. Проверено с билайновским тырнетом домашним и траффиком ~100мбит постоянным. Работает и не жужжит.

Вообще пора уже от pptp отказываться, он убог от рождения. l2tp рулит.

Спасибо за наводку. Ушел курить мануалы

Опа.
А покажи, если не трудно, options.xl2tpd и скажи в каком режиме xl2tpd работает - юзерспейсном или ядерном?
Или у тебя не xl2tpd вообще?

Для справки, команду pptpsetup достаточно выполнить один раз без ключа --start и стартовать соединение командой pppd call NIKS (в вашем случае указываете имя соединения NIKS).

Следующее, проверьте качество линии до первого маршрутизатора. Если у вас IP назначен на физическом интерфейсе вручную, сделайте

sudo ping -f -c 100 -s 1600 <server>

ip route

<server> via <gateway> ...

ping -c 5 <gateway>

Да, возможен вариант, что вам выдаётся IP из одной подсети с pptp-сервером, тогда маршрута не будет в таблице и можно сразу пробовать пинговать сервер.

Ещё я бы рекомендовал посмотреть в сторону accel-pptp, не спутайте с accel-ppp. Последний - это реализация исключительно серверной части разных протоколов (L2TP/PPPoE/PPTP) с разными плюшками, а первый - непосредственно ускоритель pptp-соединений. В частности Вас должен интересовать плагин к pppd, который отвечает за связь pppd с ядерным модулем pptp, что ускорит работу самого туннеля (повысит скорость и немного понизит задержки), плюс должно решить проблему с падением pppd (у меня решало, по-крайней мере). Правда, стоит отметить, что исходники слегка протухшие и не факт, что соберутся без бубна.

Use accel-pptp, Luke!

xl2tpd, не ядерный. В ядерном у меня когда-то толи ядро падало, толи еще какие залипы были, я на него забил и с тех пор не проверял.

xl2tpd.conf

[global]

[lac beeline]
tx bps = 100000000
lns = tp.internet.beeline.ru
redial = yes
redial timeout = 60
max redials = 2147483647
require chap = yes
require authentication = no
ppp debug = no
pppoptfile = /etc/ppp/options.l2tp.client
autodial = yes

options.l2tp.client:

name xxxx
noauth
noaccomp
nopersist
maxfail 0
unit 128

# xl2tpd -v
xl2tpd version:  xl2tpd-1.3.1

# pppd --version
pppd version 2.4.5

Так работает на двух серверах (моём и у родителей) в билайне - траблов нет. Коннект держится неделями, вот это я перезагружал сам:

# zcat syslog*gz | grep pppd
Feb  7 21:41:29 nas pppd[18912]: Terminating on signal 15
Feb  7 21:41:29 nas pppd[18912]: Connect time 22021.2 minutes.
Feb  7 21:41:29 nas pppd[18912]: Sent 1972532287 bytes, received 3166808139 bytes.
Feb  7 21:41:29 nas pppd[18912]: Modem hangup
Feb  7 21:41:29 nas pppd[18912]: Connection terminated.
Feb  7 21:41:29 nas pppd[18912]: Exit.

Один раз, правда, такая херня в лог валиться начала:

Feb  3 05:59:52 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xde53
Feb  3 05:59:54 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xbd37
Feb  3 06:00:09 nas pppd[18912]: Protocol-Reject for unsupported protocol 0x9aed
Feb  3 06:05:26 nas pppd[18912]: Protocol-Reject for unsupported protocol 0x8009
Feb  3 06:08:21 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xbd92
Feb  3 06:09:04 nas pppd[18912]: Protocol-Reject for unsupported protocol 0x8c76
Feb  3 06:15:00 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xd7d8
Feb  3 06:15:29 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xcaa9
Feb  3 06:15:40 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xd432
Feb  3 06:17:22 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xf1b6
Feb  3 06:17:22 nas pppd[18912]: Protocol-Reject for unsupported protocol 0x921c

Да, плюсую accel-pptp. Это плагин к pppd, который позволяет работать без дополнительных приблуд в виде pptp-клиента, чисто силами самого pppd. Позволяет сильно снизить нагрузку на проц как минимум, на дохлых роутерах типа WRT54G мне помогало сильно в свое время.

Спасибо за конфиги. Надо будет поднять тестовый стенд и погонять все самому.
Кстати, как я понимаю, «Protocol-Reject for unsupported protocol» - тоже часто встречаемая ошибка как раз по данной теме.

Что касается accel-pptp, то его куски же давным-давно впихнули в ядро, сделав отдельное существование бесмысленным.

Огромное спасибо, ребята. Разобрался с accel-pptp - уже час без вылетов

сделав отдельное существование бесмысленным.

Плагин в пппд всё равно нужен. И к нему поддержка в ядре.

Protocol-Reject for unsupported protocol

2-3 февраля такое вылезло один раз, больше не видел.

Ух ты, оказывается, действительно accel помогает.
А я думал, оно разобрано на органы, сдохло и неактуально.
Интересно это всё.

Я, похоже, поторопился. Все давно подключение отваливается.

вот /etc/ppp/peers/NIKS

plugin pptp.so
pptp_server vpn.niks.by
#lock
noauth
nobsdcomp
nodeflate
name LOGIN
remotename NIKS
ipparam NIKS

pppd в связке с accel-pptp работает железобетонно в недороутерах.

pppd с связке с poptop падал от нагрузки, потому-что у poptop нет ядерного модуля и трафик бегает в юзерспейсе вместо кернелспейса при accel-pptp.

Я хз, как вы его настраиваете. У меня стоит несколько poptop-серверов на разных провайдерах для велосипедного аналога HA для нескольких клиентских вендов, всё пашет, каналы на серверных сторонах - гигабит, на клиентах - сотка. Ну да, когда полоса растёт, нагрузка на проц возрастает, но, с другой стороны, никто там торренты через vpn не гоняет.

Я ж тебе в прошлой теме про accel-pptp писал :)

poptop
для вендов

Вооот. Разницы вроде быть не должно, но фиг знает.

Я ж тебе в прошлой теме про accel-pptp писал :)

А ТС уже отписался, что радость была преждевременной.

Для _клиентских_ вендов. Сами сервера, разумеется, на линуксах

Такая же проблема. Ничего не нагуглилось кроме mtu.

Для _клиентских_ вендов.

Именно. На проблему жалуются обладатели _клиентских_ люниксов.
Вон чуть выше - еще один ITT.

попробуйте добавить опции

persist
maxfail 0

люниксов

Упоротый чтоле?

Ну давай без буквоедства. Лииинуксов, ладно. У Бздей, по слухам, не отваливается.

Фиг знает, я тоже соединяюсь к VPN и из дома и из офиса, без проблем.

Отключайте все остальные компрессии, типа ″novj″, ″novjccomp″. Понижайте размер пакета ″mtu 1300″, ″mru 1300″. Включите ″debug″, чтобы посмотреть, какой режим соедиения согласуется и, может, в логах будет указано, кто инициатор разрыва связи.

А каковы каналы до клиента и насколько бывают забиты лично тобой?
А то на 10мбит оно и УМВР.
Ну и кинь клиентских конфигов, будь добр. Для коллекции.

Да стандартные раскомментированные из репы http://pptpclient.sourceforge.net/yum/

Под бубунтой - NM.