Лог засыпан ошибками 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
Он сам по себе (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-клиенты и торрент несколько плющит от этого. Если бы это была работа - я бы придушил админа из-за того что с интернетом невозможно работать - постоянно чёто отваливается и пересоединяется.
Про твой конфиг
и ничего не долго — всего лишь служба на старте не уйдёт в фон до того как состоится подключение.
аналогично — если по предыдущим параметрам будет сочтено что линк разорван - сколько попыток будет предпринято для его поднятия, после этого демон «упадёт». В твоей конфигурации он упадёт сразу после 3х не полученных эхопакетах, что видать сделано для 2х интернетной конфигурации. У меня он пробует 10 раз подцепится.
ясно, что опции делают, не
ясно, что опции делают, не ясно, зачем они - тут вроде даже вредны. сейчас некогда, потом отпишусь.
evadim написал(а): егоный
Мне когда-то показалось очень полезным иметь всё собранным в /etc/conf.d/net - опции, логины-пароли, всё. ip у меня при реконнектах не меняется. А хоть бы и менялся - это работа, и важней обеспечить максимально быстрое восстановление хоть какого-то канала связи, чтобы работа не останавливалась у всего офиса. С обрывами связи, потерями пакетов итп можно потом на досуге побороться. Аську у всего офиса плющило до меня, когда длинковская железка не тянула тысячи соединений торрента и обламывала NAT у чего попало. А торрентоводов я сам могу придушить - хоть так, хоть шейпером ;)
- Красная Шапочка, а Красная Шапочка, я тебя съем! >8P
- Я сама голооооодная... Ж8-E
Из-за этих уходов в фон обламываются зависимости служб друг от друга, и, скажем, стартующий раньше создания pppX bind потом уже никак не сможет это самое pppX прибиндить. Тк рутовые привилегии дропнул уже. Какие-то еще глюки страшные лезли, ntpd, что-то еще, уже не помню. Запретил уходить в фон.
Изначально вообще не стояло. Т.е. коннектиться до бесконечности. Потом поставил updetach, потом глюкнул свет (злой начальник не дает UPS) и после загрузки роутера, как потом выяснилось, все зависло на этапе подъема второго канала. Т.к. у них тоже глюкнуло при выключении света. А коннектимся до бесконечности. Что обидно - первый канал нормально работал, все бы завелось... Поставил maxfail 5, написал скрипт для крона, который раз в 10 мин смотрит на состояние интерфейсов и перезапускает net.pppX при необходимости.
Пока - все. Еще хочется в /etc/conf.d/net интегрировать добавление правил шейпера (почему не htbinit? а потому же - ppp отвалилось - корневая дисциплина вместе со всем деревом сбросилась), объединение емкости каналов для тех, кому надо (все те же торренты, так оно никому не нужно) и немного изменить логику работы, которая для переконфигурирования "на лету" совсем не заточена была... Но это как-нибудь потом. Пока же роутер способен при обрыве (и последующем возможном восстановлении) любого из двух каналов связи, в том числе со временным отключением питания роутера, обойтись без вмешательства админа. Это удобно ;)
Avari написал(а): Из-за этих
У меня всё подругому - бывает что пров тупит или ещё почемунить, на старте не поднимается pppoe - и мы ждём вечность пока система загрузится, да и djbdns таких траблов в отличии от бинда не имеет.
clamp-mss-to-pmtu
Если кому еще надо, проблема заключается в разнице размеров пакетов, ходящими между eth+ и ppp+ интерфейсами.
Решается добавление одного правила iptables:
Если в двух словах, то теперь iptables будет подгонять размеры пакетов автоматически.
пункт 7.2
пункт 7.2 http://www.gentoo.org/doc/ru/home-router-howto.xml