Лог засыпан ошибками PPTP

Выход в инет у меня через vpn провайдера. Соединение работает без проблем, вот тока в логах с интервалом в 1 - 2 секунды сыпятся такие сообщения:

Jan 17 00:25:14 serv pptp[18144]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1414698 (expecting 1414657, lost or reordered)
Jan 17 00:25:14 serv pptp[18144]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1414699 (expecting 1414657, lost or reordered)
Jan 17 00:25:14 serv pptp[18144]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1414700 (expecting 1414657, lost or reordered)
Jan 17 00:25:14 serv pptp[18144]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1414701 (expecting 1414657, lost or reordered)
Jan 17 00:25:14 serv pptp[18144]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1414702 (expecting 1414657, lost or reordered)
Jan 17 00:25:14 serv pptp[18144]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1414703 (expecting 1414657, lost or reordered)
Jan 17 00:25:14 serv pptp[18144]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1414704 (expecting 1414657, lost or reordered)
Jan 17 00:25:14 serv pptp[18144]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1414705 (expecting 1414657, lost or reordered)

Подскажите - в чём может быть проблема? Может кто сталкивался?

serv ppp # cat options
name @@@@@
remotename vpn
noauth
nobsdcomp
nodeflate
persist
lock
lcp-echo-interval 30
lcp-echo-failure 4
mtu 500
mru 500

Спасибо!

mru и mtu выше

mru и mtu выше поставь, 1400-1500 в таком диапозоне, возможно поможет.

root@Antarctic $ emerge -av penguins

ставил 1450 1500 1550,

ставил 1450 1500 1550, не помогло. Причём сообщения в логи начинают сыпаться не сразу, а спустя секунд 40 после запуска соединения.
Есть ещё идеи?

У меня уже файл messages занимает 3.5 Гига )))

Пока проблему

Пока проблему решил тупо ключем --loglevel 0.
Может есть более цивильные решения данной проблемы?

Попроюуй

Попроюуй поиграться параметрами nobsdcomp, nodeflate и проч.. В ядре включен GRE протокол ? фаер не режет 47 порт ?

Да причём здесь

Да причём здесь компрессия и gre? Это вообще pptp ругается а не pppd. 2 Jaja: Ничего ужасного в этом вроде как нет, у меня так ужо пол года работает, просто какой-то пакет потерялся или пришёл не в том порядке и остальные пакеты, до прибытия нужного, буферизуются. Если не отваливается, то можешь смело на это забить (--loglevel 0). У меня временами отваливалось, копал пол дня, причину падений так и не выяснил. Поставил mtu и mru 1250, падать перестало. Если выяснишь таки, напиши, интересно :)

проверьте

проверьте txqueuelen
по-умолчанию он на некоторых системах ставиться в 3, что мало
ppp0 Link encap:Протокол PPP (Point-to-Point Protocol)
inet addr:172.16.1.108 P-t-P:172.16.1.117 Mask:255.255.255.255
ВВЕРХ POINTOPOINT RUNNING NOARP MULTICAST MTU:1296 Metric:1
RX packets:21953 errors:0 dropped:0 overruns:0 frame:0
TX packets:27444 errors:0 dropped:0 overruns:0 carrier:0
коллизии:0 txqueuelen:1000
RX bytes:8269602 (7.8 MB) TX bytes:3008203 (2.8 MB)

.

А я выбрал спорный путь -
* распаковал исходники 1.7.1 и в pptp_gre.c закомментировал if (log_level >= ... ) ... ;
* tar --create -z --file=pptp-1.7.2.tar.gz pptp-1.7.2
* mv pptp-1.7.2.tar.gz /usr/portage/distfiles/
* sudo ebuild /usr/local/portage/net-dialup/pptpclient/pptpclient-1.7.2.ebuild digest

Вот лишь бы чего-нибудь в

Вот лишь бы чего-нибудь в исходниках наковырять... А про обновление системы вообще не думаем? Тапки настанут всем вашим ковыряниям... есди дополнительных мер не предпринимать...
Столкнулся с этой проблемой, было найдено следующее решение, тоже спорное ;) Это опция командной строки pptp:
--nobuffer Completely disables buffering and reordering of packets. Any --timeout specified will be ignored.
Не уверен, что не пойдут потери пакетов и, как следствие, потеря производительности. Завтра проверю скорость канала связи, сегодня поздно уже. Но сообщения в лог сыпаться точно перестали ;)
PS. А txqueuelen у меня и точно 3 :( Надо попробовать это увеличить, хотя не очень понятно, как очередь на передачу должна повлиять на порядок приема пакетов...

Ну так что-нибудь поменялось.

Ну так что-нибудь поменялось. Очень интересно.

Не :(

Ничего не поменялось, то же самое в логах, просто в меньшем количестве.
На корбиновском форуме накопал такое, там пишут, что --timeout 10 вроде помогает. Только что попробовал - отвратительно, просто-таки сыплет в лог, --nobuffer и то лучше. Там же прочитал про игры с MTU. У меня уже стояло теоретически правильное MTU 1476!!! C горя попробовал его в 1300 загнать. "Аналогично" (C) братья Колобки. Сдаюсь, ставлю --loglevel 0...
PS. Еще там же нашел, что в pptp косо сделана запись в syslog, и из-за того, что таких сообщений pptp пишет в лог очень много, он не успевает обрабатывать поступающие пакеты. Соответственно, потери и низкая скорость. Отключение лога потери убирает. Смешно.

cisco wntosr2 1995 year

Avari написал(а):
PS. Еще там же нашел, что в pptp косо сделана

Он сам по себе (c его убогим GRE) такой, с родовыми травмами... отходы жизнедеятельности Cisco.

PPS. У кого там чего

PPS. У кого там чего отваливается... Можно же автоматически пересоединяться... У меня вообще два подключения автоматом поднимаются-опускаются, недавно вообще полдня просидел, потом в логи глянул и обнаружил, что весь день то одно, то другое соединение падало ;) автоматика работала за админа, перекидывая весь офис на работающее соединение и восстанавливая подключения по возможности ;)
Смотрите идею для одного pptp-подключения:

config_eth1=( "xx.xx.xx.xx/24" )
routes_eth1=( "pp.tp.ser.ver/32 via ga.te.wa.y" )

RC_NEED_ppp1="net.eth1"
config_ppp1=( "ppp" )
link_ppp1="pty 'pptp pp.tp.ser.ver --nolaunchpppd --loglevel 0'"
# --loglevel 0 нужен, чтобы pptp не писал в лог уйму сообщений
# по поводу packet lost or reordered
# --nobuffer в этом случае не помогает
# есть данные, что из-за плохо сделанной записи в syslog pptpd теряет пакеты
# отключение лога улучшает связь
username_ppp1="xxxxx"
password_ppp1="xxxxx"
pppd_ppp1=(
"lock"
"noauth"
# долго объяснять, зачем, вам пока не нужно
# "updetach"
# время, через которое после разрыва соединения делается попытка установить новое
"holdoff 10"
"refuse-pap"
# C этой опцией будет само пересоединяться при обрыве
"persist"
# чтобы при инкапсуляции пакеты не фрагментировались
"mtu 1476"
"mru 1476"
# если с той стороны не придет 3 подряд ответов на LCP echo requests через каждые 10 сек - разрываем соединение.
# если стоит persist - тут же и пересоединяемся...
"lcp-echo-interval 10"
"lcp-echo-failure 3"
# долго объяснять, зачем, вам пока не нужно
# "maxfail 5"
)
Конфиг с двумя подключениями интереснее, но он в хронически недопиленном состоянии (мне хочется запихать туда больше возможностей и поправить существующие так, чтобы не надо было документировать баги как фичи =) Мб когда-нибудь потом заведу наконец здесь блог и выложу наработки.

Смысл в том, что соединение

Смысл в том, что соединение может не обрываться а тупить из-за потери пакетов - совершенно другая история, ктомуже, если посмотреть на пост топикстартера то видно — егоный конфиг от твоего отличается мягко говоря не драматически. Также, у меня при обрывах соединения меняется ip-адрес, он динамический внешний, и соответственно IM-клиенты и торрент несколько плющит от этого. Если бы это была работа - я бы придушил админа из-за того что с интернетом невозможно работать - постоянно чёто отваливается и пересоединяется.
Про твой конфиг

Avari написал(а):
# долго объяснять, зачем, вам пока не нужно
# "updetach"

и ничего не долго — всего лишь служба на старте не уйдёт в фон до того как состоится подключение.

Avari написал(а):
# долго объяснять, зачем, вам пока не нужно
# "maxfail 5"

аналогично — если по предыдущим параметрам будет сочтено что линк разорван - сколько попыток будет предпринято для его поднятия, после этого демон «упадёт». В твоей конфигурации он упадёт сразу после 3х не полученных эхопакетах, что видать сделано для 2х интернетной конфигурации. У меня он пробует 10 раз подцепится.

ясно, что опции делают, не

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

evadim написал(а): егоный

evadim написал(а):
егоный конфиг от твоего отличается мягко говоря не драматически. Также, у меня при обрывах соединения меняется ip-адрес, он динамический внешний, и соответственно IM-клиенты и торрент несколько плющит от этого. Если бы это была работа - я бы придушил админа из-за того что с интернетом невозможно работать - постоянно чёто отваливается и пересоединяется.

Мне когда-то показалось очень полезным иметь всё собранным в /etc/conf.d/net - опции, логины-пароли, всё. ip у меня при реконнектах не меняется. А хоть бы и менялся - это работа, и важней обеспечить максимально быстрое восстановление хоть какого-то канала связи, чтобы работа не останавливалась у всего офиса. С обрывами связи, потерями пакетов итп можно потом на досуге побороться. Аську у всего офиса плющило до меня, когда длинковская железка не тянула тысячи соединений торрента и обламывала NAT у чего попало. А торрентоводов я сам могу придушить - хоть так, хоть шейпером ;)
- Красная Шапочка, а Красная Шапочка, я тебя съем! >8P
- Я сама голооооодная... Ж8-E

evadim написал(а):
Про твой конфиг

Avari написал(а):
# долго объяснять, зачем, вам пока не нужно
# "updetach"

и ничего не долго — всего лишь служба на старте не уйдёт в фон до того как состоится подключение.

Из-за этих уходов в фон обламываются зависимости служб друг от друга, и, скажем, стартующий раньше создания pppX bind потом уже никак не сможет это самое pppX прибиндить. Тк рутовые привилегии дропнул уже. Какие-то еще глюки страшные лезли, ntpd, что-то еще, уже не помню. Запретил уходить в фон.

evadim написал(а):
Avari написал(а):
# долго объяснять, зачем, вам пока не нужно
# "maxfail 5"

аналогично — если по предыдущим параметрам будет сочтено что линк разорван - сколько попыток будет предпринято для его поднятия, после этого демон «упадёт». В твоей конфигурации он упадёт сразу после 3х не полученных эхопакетах, что видать сделано для 2х интернетной конфигурации. У меня он пробует 10 раз подцепится.

Изначально вообще не стояло. Т.е. коннектиться до бесконечности. Потом поставил updetach, потом глюкнул свет (злой начальник не дает UPS) и после загрузки роутера, как потом выяснилось, все зависло на этапе подъема второго канала. Т.к. у них тоже глюкнуло при выключении света. А коннектимся до бесконечности. Что обидно - первый канал нормально работал, все бы завелось... Поставил maxfail 5, написал скрипт для крона, который раз в 10 мин смотрит на состояние интерфейсов и перезапускает net.pppX при необходимости.
Пока - все. Еще хочется в /etc/conf.d/net интегрировать добавление правил шейпера (почему не htbinit? а потому же - ppp отвалилось - корневая дисциплина вместе со всем деревом сбросилась), объединение емкости каналов для тех, кому надо (все те же торренты, так оно никому не нужно) и немного изменить логику работы, которая для переконфигурирования "на лету" совсем не заточена была... Но это как-нибудь потом. Пока же роутер способен при обрыве (и последующем возможном восстановлении) любого из двух каналов связи, в том числе со временным отключением питания роутера, обойтись без вмешательства админа. Это удобно ;)

Avari написал(а): Из-за этих

Avari написал(а):
Из-за этих уходов в фон обламываются зависимости служб друг от друга, и, скажем, стартующий раньше создания pppX bind потом уже никак не сможет это самое pppX прибиндить. Тк рутовые привилегии дропнул уже. Какие-то еще глюки страшные лезли, ntpd, что-то еще, уже не помню. Запретил уходить в фон.

У меня всё подругому - бывает что пров тупит или ещё почемунить, на старте не поднимается pppoe - и мы ждём вечность пока система загрузится, да и djbdns таких траблов в отличии от бинда не имеет.

clamp-mss-to-pmtu

Если кому еще надо, проблема заключается в разнице размеров пакетов, ходящими между eth+ и ppp+ интерфейсами.
Решается добавление одного правила iptables:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 0:65535 -j TCPMSS --clamp-mss-to-pmtu -i ppp+

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

пункт 7.2

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

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