[Justas]

запускаю pptpd из консоли или из rc.local как pptpd &. Пробовал на трех слаках -11-й, 12.1 и 13 - везде одно и то же - ругается в syslog, что MGR config file not found! При этом у клиентов 800-я ошибка, и выхлоп в логи - unsupported protokol (или что-то типа этого). Если же в pptpd.conf или в /etc/ppp/options.pptpd есть какая-то ошибка, то в логе указывает на неё.

pptpd -v выдаёт соответствие собранного имеющемуся в системе.

конфиги брал и из архива - из образцов, и писал свои - например так:

 

Просмотр топика наводит мысль на то, что ip_gre собран в ядре. Проверил, не собран и модули не подгружены. Даже пересобрал ядро с выключенной опцией ip_gre_broadcast, результат тот же. Ядра пробовал 2.6.23 с imq патчами и родные для этих слак(2.6.26.7 и 2.6.29.6) без каких-либо патчей.

Куда смотреть?

Это не GRE. Если компиляция проходит без ошибок, то проблема в настройках. Похоже, в конфигах допущены ошибки (не совпадают IP с назначенными на интерфейс, например). Или неверные права доступа к директориям/файлам.

 

У меня вот Fedora Core 5 даже не компилируется. Ядро SMP 2.6.20. При компиляции

 

bash-3.1# make
echo Building kernel module
Building kernel module
(cd kernel/driver; make )
make[1]: Entering directory `/root/newpptp/accel-pptp/kernel/driver'
using "/usr/src/linux" kernel headers
make -C /usr/src/linux SUBDIRS=/root/newpptp/accel-pptp/kernel/driver modules
make[2]: Entering directory `/usr/src/kernels/2.6.20-1.2320.fc5-smp-i686'
  CC [M]  /root/newpptp/accel-pptp/kernel/driver/pptp.o
/root/newpptp/accel-pptp/kernel/driver/pptp.c: In function 'pptp_rcv_core':
/root/newpptp/accel-pptp/kernel/driver/pptp.c:596: error: implicit declaration of function 'skb_set_network_header'
make[3]: *** [/root/newpptp/accel-pptp/kernel/driver/pptp.o] Error 1
make[2]: *** [_module_/root/newpptp/accel-pptp/kernel/driver] Error 2
make[2]: Leaving directory `/usr/src/kernels/2.6.20-1.2320.fc5-smp-i686'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/newpptp/accel-pptp/kernel/driver'
make: *** [module] Error 2

 

Само собой, на другом сервере с Федорой 12 и ядром 2.6.32 всё получается красиво.

 

Народ, компилил ли кто с ядром 2.6.20 ? Да, я понимаю, это странно, в pptp.c xab явно указал #if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,19) и что ему не нравится - ума не приложу.

[phaoost]

всем привет. решил попробовать 0.8.3 версию вместо поптопа. подскажите, есть ли какие-либо проблемы с ppp_generic_smp

[Умник]

подскажите, есть ли какие-либо проблемы с ppp_generic_smp

Его лучше не использовать. Это не очень удачный эксперимент. Подождите ядро 2.6.35, в котором проблема распределения прерываний по ядрам решена на уровня стека.

[lionspy]

Проблемка то просто решилась.

Надо было всего лишь загрузить модуль ядра pptp

modprobe pptp

перед стартом pptpd при старте системы.

Вылезла другая фигня - писал в сислог, что удаленная система просит аутентификацию, а он не может найти пароля для неё.

Решение - простейшее. Как уже тут неоднократно писалось, hostname и имя сервера (name pptp) и второе поле файла chap-secrets должны быть одинаковыми.

Хотя я в чап-секретс просто поставил звездочку во втором поле, потом, когда понял.

 

Но по-прежнему при старте ругается, что config file not found!

хотя нормально пускает клиентов.

Игрался с настройками - не могу найти возможность одновременной работы клиентов с mppe и без оного.

Либо чап (мс-чап) и без мппе, либо-мс-чап-2 и только мппе.

При чапе, чаже если в винде оставить шифрование и мс-чап-2 только, то несогласование протоколов ппп. Ессно, при этом require-mppe-128 закомментировано в конфиге, иначе не пускает клиентов без шифрования.

Есть ли возможность настроить так, чтобы пускало и тех, и тех - в старом ппп была замечательная опция mppe stateless, которая за это отвечала.

[phaoost]

подскажите, в чем может быть проблема. стартую pptpd -c /etc/pptpd.conf, в логах пишет:

Apr 29 00:30:49 cs4 pptpd[12076]: MGR: Config file not found!

Apr 29 00:30:49 cs4 pptpd[12076]: accel-pptpd-0.8.3 compiled for pppd-2.4.4, linux-2.6.26

Apr 29 00:30:49 cs4 pptpd[12078]: MGR: Manager process started

 

/etc/ppp/pptpd-options есть, указан в pptpd.conf

 

Игрался с настройками - не могу найти возможность одновременной работы клиентов с mppe и без оного.

Либо чап (мс-чап) и без мппе, либо-мс-чап-2 и только мппе.

При чапе, чаже если в винде оставить шифрование и мс-чап-2 только, то несогласование протоколов ппп. Ессно, при этом require-mppe-128 закомментировано в конфиге, иначе не пускает клиентов без шифрования.

Есть ли возможность настроить так, чтобы пускало и тех, и тех - в старом ппп была замечательная опция mppe stateless, которая за это отвечала.

такое было и в поптопе. я пускал два инстанса на разных ипах с разными pptpd-options.

 

про вторую часть вопроса есть ответ в мане пппд:

mppe-stateful

Allow MPPE to use stateful mode. Stateless mode is still attempted first. The default is to disallow stateful

mode.

 

[sfstudio]

В общем т.к. xeb не отвечает уже долгое время на любые внешние раздражители публикую тут ссылки на 2 полезных патчика для ядерного pptp модуля из официального гита, патчи в порядке в котором требуется их накладывать:

 

Первый: http://wive-ng.git.sourceforge.net/git/git...33995e310106a75

 

Второй: http://wive-ng.git.sourceforge.net/git/git...c3f4fc977f0892f

 

О назначении кратенько в гите описано как и о копирайтах на первый патч.

 

Пропатченная версия живёт тут http://sourceforge.net/projects/wive-ng/files/others

[hiller]

О назначении кратенько в гите описано как и о копирайтах на первый патч.

 

Пропатченная версия живёт тут http://sourceforge.net/projects/wive-ng/files/others

Хм... А можно подробнее, какие глюки эти патчи лечат?

[sfstudio]

К примеру залечен глюк когда под высокой нагрузкой или просто на хреновых каналах теряется часть LCP пакетов или они приходят не в той последовательности. + добавлена возможность при загрузке модуля задать максимальный mtu который будет использовать pptp чтобы оно даже и не пыталось выставить выше (часто нужно на встраиваемых девайсах). Плюс ещё мелочёвка.

[hiller]

К примеру залечен глюк когда под высокой нагрузкой или просто на хреновых каналах теряется часть LCP пакетов или они приходят не в той последовательности. + добавлена возможность при загрузке модуля задать максимальный mtu который будет использовать pptp чтобы оно даже и не пыталось выставить выше (часто нужно на встраиваемых девайсах). Плюс ещё мелочёвка.

Спасибо! Как раз сейчас наблюдаем отстрелы сессий по LCP, на насах, которые под нагрузкой.

[sfstudio]

Не за что, расскажите о результатах.

[hiller]

Час прошел. Пока летим нормально. Настройки MTU не трогал. Кстати, для каких случаев это требуется? Когда клиент пытается согласовать 1500 и более?

[sfstudio]

Час прошел. Пока летим нормально. Настройки MTU не трогал.

Уже хорошо.

 

Кстати, для каких случаев это требуется? Когда клиент пытается согласовать 1500 и более?

На некоторых мелких железяках значение dst_mtu(&rt->u.dst) получается >1500 по какой-то причине, вот сделал ограничение если задано mtu как опция модуля. А вообще могут быть и другие случаи когда это может понадобиться.

 

[Justas]

Я прям от версии 0.8.4 нарадоваться не могу. На ядре 2.6.32 двухпроцессорный ксеон на обычном пптпд загибался при 900 сессиях. Сейчас при такой же нагрузке загрузки процессора просто нет, по ощущениям хоть 5000 впнов терминировать можно.

[hiller]

Ну да, я тоже радовался и до сих пор радуюсь, правда уткнулись в другое, softirq ;)

[rsa]

Доброго времени суток.

Нарисовалась проблема с accel-pptp клиентом, модуль ядра загружается без ошибок, но после подъема ppp0 маршрутизатор перестает реагировать на любые внешние раздражители.

 

# uname -a
Linux gw 2.6.32-gentoo-r7-gw #3 SMP Sun May 16 07:54:28 MSD 2010 i686 Pentium III (Katmai) GenuineIntel GNU/Linux

# zcat /proc/config.gz | grep NET_IP
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m

 

Исходники пробовал брать из git://accel-pptp.git.sourceforge.net/gitroot/accel-pptp/accel-pptp

и из http://sourceforge.net/projects/wive-ng/files/others результат одинаков.

 

Проблему

/usr/src/linux/include/asm-generic/int-ll64.h:11:29: error: asm/bitsperlong.h: No such file or directory

решил через

# ln -s /usr/src/linux/include/asm-generic/bitsperlong.h /usr/src/linux/include/asm/bitsperlong.h

После этого make client && make client_install выполнилось без ошибок

 

# modinfo pptp
filename:       /lib/modules/2.6.32-gentoo-r7-gw/extra/pptp.ko
license:        GPL
author:         Kozlov D. (xeb@mail.ru)
description:    Point-to-Point Tunneling Protocol for Linux
depends:        pppox,ppp_generic
vermagic:       2.6.32-gentoo-r7-gw SMP mod_unload PENTIUMIII
parm:           mtu:int
parm:           log_level:Logging level (default=0) (int)
parm:           log_packets:Logging packets (default=0) (int)
parm:           log_mtu:Maximum channel MTU (default=auto)

# modprobe pptp
# lsmod
Module                  Size  Used by
pptp                    5238  0
pppox                   1676  1 pptp
ppp_generic            15009  2 pptp,pppox
slhc                    4045  1 ppp_generic

 

после /etc/init.d/net.ppp0 start в логах:

May 16 19:17:09 gw pppd[8479]: Plugin passwordfd.so loaded.
May 16 19:17:09 gw pptp[8479]: Plugin pptp.so loaded.
May 16 19:17:09 gw pptp[8479]: PPTP plugin version 0.8.4 compiled for pppd-2.4.4, linux-2.6.32-gentoo-r7
May 16 19:17:09 gw pptp[8479]: pppd 2.4.4 started by ******, uid 0
May 16 19:17:09 gw pptp[8479]: PPTP: failed to setsockopt PPTP_SO_TIMEOUT (Operation not supported)
May 16 19:17:09 gw pptp[8480]: anon log[callmgr_main:pptp_callmgr.c:132]: IP: 78.107.1.61
May 16 19:17:09 gw pptp[8480]: anon log[callmgr_main:pptp_callmgr.c:136]: control connection
May 16 19:17:09 gw pptp[8480]: anon log[callmgr_main:pptp_callmgr.c:140]: unix_sock
May 16 19:17:09 gw pptp[8481]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
May 16 19:17:09 gw pptp[8481]: anon log[ctrlp_disp:pptp_ctrl.c:737]: Received Start Control Connection Reply
May 16 19:17:09 gw pptp[8481]: anon log[ctrlp_disp:pptp_ctrl.c:771]: Client connection established.

После этого только ресет =\

 

Кусок /etc/conf.d/net

config_ppp0=( "ppp" )
link_ppp0="pptp_server vpn.corbina.net"
plugins_ppp0=( "pptp" )
pppd_ppp0=(
        "updetach noauth nodefaultroute usepeerdns nobsdcomp nopcomp mtu 1460 mru 1460 \
        noaccomp nodeflate lcp-echo-interval 10 lcp-echo-failure 5 password pass"
        )
username_ppp0="user"
password_ppp0="pass"
depend_ppp0() {
        need net.eth1
        }
postup() {
        if [ "${IFACE}" = "ppp0" ]; then
                route del `ip a s ppp0 | awk -F"[ ]+|[/]" '/inet / {print  $5}'` dev ppp0
                ip route add default dev ppp0
        fi
        return 0
}
postdown() {
        if [ "${IFACE}" = "ppp0" ]; then
                ip route del default dev ppp0
        fi
        return 0
}

c link_ppp0="pty 'pptp vpn.corbina.net --nolaunchpppd --nobuffer --loglevel 0'" без плагина pptp канал поднимается и работает нормально, но сильно загружается проц при потоке выше 20-25 Мб/с

 

Не знаю теперь в какую сторону копать.

Изменено 16 мая, 2010 пользователем rsa

[sfstudio]

Корбиновцам всегда везёт =) Петелька это батенька, старая добрая петля у горбины. У них на форуме есть описальник, как лечить догадаетесь сами.

[rsa]

sfstudio вы правы, спасибо за пинок в нужную сторону.

 

postup() в /etc/conf.d/net не отрабатывал до зависания системы и петля оставалась, при этом без модуля pptp маршрут удалялся нормально.

 

пока решил таким костылем:

/etc/conf.d/net

pppd_ppp0=(
        ":192.168.254.254"
        "updetach noauth defaultroute usepeerdns nobsdcomp nopcomp mtu 1460 mru 1460 \
        noaccomp nodeflate lcp-echo-interval 3 lcp-echo-failure 5 password pass"
        )

но, имхо, так не совсем правильно. Может есть более адекватные способы решения данной проблемы, кроме смены провайдера? Хотя это уже оффтоп.

Изменено 17 мая, 2010 пользователем rsa

[[anp/hsw]]

Пропатченная версия живёт тут http://sourceforge.net/projects/wive-ng/files/others

Поставил пропатченую версию вместо оригинальной (заменил модуль pptp.o)

Некоторые пользователи (примерно 2-3 на 100 человек не могу подключиться с ошибкой 619, в логе "LCP: timeout sending Config-Requests"

 

Менялось ли что-либо в бинарниках pptpd или pptpctrl оптносительно 0.8.4? (у меня они старые остались)

May 17 10:16:14 mega pptp[7748]: Connect: ppp86 <--> pptp (192.168.100.117)
May 17 10:16:14 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:16 mega pptp[7748]: rcvd [LCP ConfReq id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:16 mega pptp[7748]: sent [LCP ConfAck id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:17 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:17 mega pptp[7748]: rcvd [LCP ConfReq id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:17 mega pptp[7748]: sent [LCP ConfAck id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:19 mega pptp[7748]: rcvd [LCP ConfReq id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:19 mega pptp[7748]: sent [LCP ConfAck id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:20 mega pptp[7748]: rcvd [LCP ConfReq id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:20 mega pptp[7748]: sent [LCP ConfAck id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:20 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:21 mega pptp[7748]: rcvd [LCP ConfReq id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:21 mega pptp[7748]: sent [LCP ConfAck id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:22 mega pptp[7748]: rcvd [LCP ConfReq id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:22 mega pptp[7748]: sent [LCP ConfAck id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:23 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:24 mega pptp[7748]: rcvd [LCP ConfReq id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:24 mega pptp[7748]: sent [LCP ConfAck id=0x8 <mru 576> <magic 0x4c1c9903>]
May 17 10:16:26 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:29 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:32 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:35 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:38 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:41 mega pptp[7748]: sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <auth chap MD5> <magic 0xbe7d089b> <pcomp> <accomp>]
May 17 10:16:44 mega pptp[7748]: LCP: timeout sending Config-Requests

Изменено 17 мая, 2010 пользователем [anp/hsw]

[sfstudio]

Версию pppd обновить до версии из git`а для начала, у меня правок в pppd много ибо на встраиваемые системы расчёт, но вам они не нужны. А некотоорые это какие? Плугин у мну тоже свой, но там в основном примитивные правки не затрагивающие LCP. Тут нужно смотреть что общего у этих 2х-3х юзеров и разбираться, ИМХО врятли оно вообще связано с заменой pptp.ko. Ну и вообще я предпочитаю ручами интегрить модуль в ядро и плагин в pppd а не собирать сбоку да ещё.

[[anp/hsw]]

таких юзеров уже 30 собралось, у всех - 619 ошибка, притом если долго-долго долбиться - подключается всетаки. Раньше такого точно не наблюдалось - жалобы начались сразу после замены pptp. системы в основном XP, по остальным пока нету данных.

ppp-2.4.5-git05042010, судя по чейнджлогу в git'е - последний.

 

реже возникает 734 ошибка "протокол управления LCP-связью был прерван", но тем не менее, если пробьется, то нормально работает, пока пользователь сам не отключит.

со всякими маршрутизаторами типа DIR-100 ошибок пока не обнаружено.

 

Изменено 17 мая, 2010 пользователем [anp/hsw]

[sfstudio]

Ну тады незнаю ничего не подскажу =)

[[anp/hsw]]

Ну тады незнаю ничего не подскажу =)

ну, может потестируем? какие есть идеи? может какие логи дополнительно показать?

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

 

я, вообще говоря, нашел только одно место, где упоминается LCP

        if ( seq < opt->seq_recv + 1 || WRAPPED(opt->seq_recv, seq) ){
+               if ( (payload[0] == PPP_ALLSTATIONS) && (payload[1] == PPP_UI) &&
+                    (PPP_PROTOCOL(payload) == PPP_LCP) &&
+                    ((payload[4] == PPP_LCP_ECHOREQ) || (payload[4] == PPP_LCP_ECHOREP)) ){
+                       #ifdef DEBUG
+                       if ( log_level >= 1)
+                               printk(KERN_INFO"PPTP[%i]: allowing old LCP Echo packet %d (expecting %d)\n", opt->src_addr.call_id,
+                                                       seq, opt->seq_recv + 1);
+                       #endif
+                       goto allow_packet;
+               }
                #ifdef DEBUG
                if ( log_level >= 1)
                        printk(KERN_INFO"PPTP[%i]: discarding duplicate or old packet %d (expecting %d)\n",opt->src_addr.call_id,
                                                        seq, opt->seq_recv + 1);
                #endif
        }else{
+               opt->seq_recv = seq;
+allow_packet:

 

может просто в некоторых случаях под эти правила попадают LCP-config пакеты?

Изменено 17 мая, 2010 пользователем [anp/hsw]

[sfstudio]

У меня к сожалению совсем нет времени разбирать важу ситуацию ибо приёдтся снимать дампы а лучше эмулировать у себя. Большей частью изменения в данной версии вообще не мои, я просто аккумулировал прикрытил свой костылёк и положил в свободный доступ т.к. xeb где-то в анабиозе. Скажу лишь что у себя подобных проблем не вижу.

 

Ну и даже если попадёт под эти правила ничего не случиться, наоборот даже пакеты будут пропущены внутрь. Вы бы лучше посмотрели бы на загружку CPU на вашем железе, может упираетесь в softirq а тут уже никакие костыли не помогут и проблемы будут сходные.

[[anp/hsw]]

в том-то и проблема, что CPU превышает едвали 10% на каждом из ядер (вместе с сетевухами)

и вообще diff'нув файл со своим я вообще не увидел места, где бы это могло глючить. попробую вырезать автоопределение MTU, может поможет.

 

[sfstudio]

Не поможет не там у вас трабла и имхо вообще на в pptp модуле.