Архивировано

Эта тема находится в архиве и закрыта для публикации сообщений.

ikm

packet lost or reordered

Рекомендованные сообщения

У кого нибудь лезет такое в логах и кто знает, как это бороть? Просеял полгугла, игрался с MTU - не помогло. :/ В саппорт и не напишешь - там же скажут, что "в венде все работает!".

 

Jun 5 03:24:40 localhost pptp[13257]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 38 (expecting 37, lost or reord

ered)

Jun 5 03:24:40 localhost pptp[13257]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 39 (expecting 37, lost or reord

ered)

Jun 5 03:24:41 localhost pptp[13257]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 57 (expecting 56, lost or reord

ered)

Jun 5 03:24:41 localhost pptp[13257]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 58 (expecting 56, lost or reord

ered)

Jun 5 03:24:41 localhost pptp[13257]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 59 (expecting 56, lost or reord

ered)

Jun 5 03:24:42 localhost pptp[13257]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 66 (expecting 65, lost or reord

ered)

Jun 5 03:24:42 localhost pptp[13257]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 67 (expecting 65, lost or reord

ered)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня такое бывает. Я так думаю, это связано с тем, что приходит на vpn больше чем (например) 512 Кбит/с и он лишние пакеты уничтожает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня примерно такое-же бывает. Правда не в Корбине а на работе. Ругается маршрутизатор. Я отправил пиьсмо производителю железки - и тишина... Никто не знает что это :rolleyes:

 

Jun 7 09:25:10 syslog: anon log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 605579 (expecting 605560)

Jun 7 09:25:10 syslog: anon log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 605580 (expecting 605560)

Jun 7 09:25:10 syslog: anon log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 605581 (expecting 605560)

Jun 7 09:25:10 syslog: anon log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 605582 (expecting 605560)

Jun 7 09:25:10 syslog: anon log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 605583 (expecting 605560)

 

Но в принципе я знаю где копать. 397 - это код ошибки. При чем этот код не привязан к операционке. Этот код генерит сам pptp. Надо читать RFC либо искать список кодов и расшифровывать что сие значит.

http://unix.org.ua/rfc/rfc2637.html

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня такое бывает. Я так думаю, это связано с тем, что приходит на vpn больше чем (например) 512 Кбит/с и он лишние пакеты уничтожает.

 

Я думал, что скорости выше 400 прожевать не может pptp-client во FreeBSD. Ну там хотя бы можно на mpd перейти, а в Linux что делать, если тоже тормозит pptp-client? :)

 

Но в принципе я знаю где копать. 397 - это код ошибки.

 

Точно? А не номер строки в pptp_gre.c? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Точно? А не номер строки в pptp_gre.c? :)

 

По моему нет.

Начитался яндекса? :lol:

 

В принципе ты можешь вызвать и другие ошибки. Ну например 800. В винде такую не встречал? :lol: Номер строки в виндовом pptp_gre.c ? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По моему нет.

Начитался яндекса? :)

 

Нет, как-то сам догадался. ;)

 

В принципе ты можешь вызвать и другие ошибки. Ну например 800. В винде такую не встречал? :( Номер строки в виндовом pptp_gre.c ? :)

 

Ошибки типа 800, 691 пишутся совершенно по другому, примерно вот в таком виде:

 

Jun 3 02:08:37 nova1 pppd[2801]: pppd 2.4.2b1 started by root, uid 0

Jun 3 02:08:37 nova1 pppd[2801]: Using interface ppp1

Jun 3 02:08:37 nova1 pppd[2801]: Connect: ppp1 <--> /dev/pts/3

Jun 3 02:08:38 nova1 pppd[2801]: Remote message: Unknown authentication

failure: E=691 R=1 C=83D3E15125A8CFA9F11F09C6A8C5E77C V=3

Jun 3 02:08:38 nova1 pppd[2801]: CHAP authentication failed

Jun 3 02:08:38 nova1 pppd[2801]: Connection terminated.

Jun 3 02:08:41 nova1 pppd[2801]: Exit.

 

И их выводит pppd, не pptp.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня 512 Кбит/с вполне vpn "жрёт". Так что дело не в этом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

[quote name='ikm' date='Jun 7 2006, 21:52' Нет, как-то сам догадался. :)

Ошибки типа 800, 691 пишутся совершенно по другому, примерно вот в таком виде:

 

Да в общем-то - не суть важно - в каком виде...

 

В принципе легко проверить. Вводишь в скрипте авторизации под линуксом неправильный пароль на инет и смотришь код ошибки который он тебе выдаст.

 

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

 

Я не проверял - но что-то мне подсказывает что они будут одинаковые :(

 

Кстати pptp - это набор протоколов. Как я понял gre входит в их число. И вполне вероятно что для всех протоколов используется сквозная таблица ошибок. Могу конечно ошибатся - но опять-же - что-то подсказывает :)

 

З.Ы.

К чему это я...

А!

Я где-то видел в инете здоровенную таблицу этих кодов ошибок с описаними.

Но вот хоть убей - не помню где...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Помогло вот что - задирание таймаутов у pptp.

--timeout <secs>

Time to wait for reordered packets (0.01 to 10 secs)

 

Я с горя залепил 10 секунд - вроде нормально сейчас работает. :huh:

 

UPD: Иногда все-таки опять проскакивает, но реже, чем раньше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

"Покой нам только снится" (с)

Нифига это не помогло, как выяснилось чуть позднее. :D Глючит по страшному. Руки чешутся винду поставить. :tease:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да есть такая проблемка, причём проблемка на самом деле как в линуксе, так и в винде. Я для улучшения ситуации использовал следующий приём

 

в options.pptp:

 

mtu 1250

mru 1250

 

ну и в качестве основной таблетки:

 

iptables -t mangle -A FORWARD -p tcp -o ppp+ --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1250

 

Правда надо признать, что окончательно это проблему не вылечило.

Так же есть мнение что надо поиграться с организацией очередей типа prio/cbq. Но я этим не занимался.

А вообще исходя из того что эта проблема присутствует у всех, надо бить по рукам тех, кто организовывал vpn.corbina.net

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Когда-то давно Малов говорил, что не исключает возможности ввода в сети PPPoE. Может хоть он бы не глючил. :corbina:

 

PS. Поставил винду - вроде нормально все работает.

 

в options.pptp:

 

mtu 1250

mru 1250

 

 

Мне игры с mtu/mru не помогли вообще. Пробовал разные значения, вплоть до 576 - как мертвому припарка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Гость blind_oracle

Это всё таки номер строки :D

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Друзья!

 

Могу сказать ерунду, но причиной данной ошибки, которая проявляется также и у меня, ИМХО является пропадание пакета по дороге до компа.

 

Давайте проанализируем:

 

Jul 19 09:51:59 darland pptp[26505]: anon log[decaps_gre:pptp_gre.c:404]: buffering packet 132135 (expecting 132134, lost or reordered)

 

Переводим: архивирую (пихаю в буфер) пакет 132135, так как я ожидал пакет 132134, который или пропал или придет в другом порядке.

 

Сдается мне, что пакет 132134 никогда не придет ;)

 

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

Если по таймауту пакет так и не приходит, демон чистит буфер и теряет все переданные данные.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а в чем проблема то? Ну reordered пакет, ну и что. Я себе просто дабавил ключ --loglevel 0 при запуске pptp

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а в чем проблема то? Ну reordered пакет, ну и что. Я себе просто дабавил ключ --loglevel 0 при запуске pptp

 

Это голову в песок что-ли?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

> Это голову в песок что-ли?

 

а что неправильного в том что пакеты пришли в неправильном порядке? По моему это нормальная ситуация

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

> Это голову в песок что-ли?

 

а что неправильного в том что пакеты пришли в неправильном порядке? По моему это нормальная ситуация

 

А если что-то еще произойдет - как ты узнаешь что именно было?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

так я же отключил логгирование только у pptp. Я не представляю о какой такой проблеме мне может поведать pptp, чтобы она представляла для меня интерес.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а в чем проблема то? Ну reordered пакет, ну и что. Я себе просто дабавил ключ --loglevel 0 при запуске pptp

 

Да вот проблема-то в том, что скорость серьезно падает, а через довольно непродолжительное время соединение разрывается при большой сетевой активности (это когда eDonkey-клиент несколько сотен коннекшенов наоткрывает, например). Если коннектов мало, то даже при большой скорости закачки глюков нет. В винде, что интересно, как часы работает все. :) Очень это печально, я с горя аж дебиан у себя снес. :rolleyes:

 

 

PS. Ребята, у кого FreeBSD стоит, скажите плз, вы что-то подобное у себя замечали?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ребята, у кого FreeBSD стоит, скажите плз, вы что-то подобное у себя замечали?

 

На pptp - та же хрень была. Лечил установкой mpd. С тех пор все шоколадно.

( FreeBSD 6.1 )

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Имею туже проблему (ошибка-warning в log+тормоза на больших файлах) на RH9. Пока полечилось MSS=1250 через iptables (спасибо f0x) и --nobuffer в свойствах pptp , ошибки в лог прут но меньше но зато вроде перестали происходить затыки.

 

кстати - MSS=1350 тоже работает неплохо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да вот проблема-то в том, что скорость серьезно падает, а через довольно непродолжительное время соединение разрывается при большой сетевой активности (это когда eDonkey-клиент несколько сотен коннекшенов наоткрывает, например). Если коннектов мало, то даже при большой скорости закачки глюков нет. В винде, что интересно, как часы работает все. ;) Очень это печально, я с горя аж дебиан у себя снес. :(

PS. Ребята, у кого FreeBSD стоит, скажите плз, вы что-то подобное у себя замечали?

А у меня в винде все работает как часы до тех пор пока не поставлю на закачку шоньть в ослика - спустя время начинает дисконнектиться! - Так что видимо то что пишется в логах линя в логах винды просто не пишется. Может винда винде рознь ? :P)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня сейчас через l2tpd работает, вроде как все нормально.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сдается мне, вы не там с MTU играетесь. Надо уменьшать на ethernet интерфейсе, так как сообщение говорит о том, что на ethernet пакеты теряются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

...

PS. Ребята, у кого FreeBSD стоит, скажите плз, вы что-то подобное у себя замечали?

На pptp - та же хрень была. Лечил установкой mpd. С тех пор все шоколадно.

( FreeBSD 6.1 )

 

Дело не в ОСи, просто сам pptpclient глюкавый - он (да, именно сама программа) теряет несущие пакеты, если они фрагментированы. При "настройках по умолчанию" - MTU несушей сети=1500 и MTU самого ppp канала=1500. При, скажем так, повышенной нагрузке размер пакетов, идущих через ppp канал, часто максимален (=MTU=1500). +ppp/pptp, итог - на выходе в несущую сеть пакет >1500 и будет фрагментирован (и, соответственно, потерян pptpclient'ом).

Установка меньшего MTU ppp канала на клиентской стороне решает проблему исходящего канала, но входящие пакеты всёравно могут быть фрагментированы.

FreeBSD 5.5, pptpclient-1.7.1

 

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

 

Выход - не использовать pptpclient, использовать, например, mpd.

 

Сдается мне, вы не там с MTU играетесь. Надо уменьшать на ethernet интерфейсе, так как сообщение говорит о том, что на ethernet пакеты теряются.

 

Нет, как раз на ethernet интерфейсе всё нормально, для решения проблемы там если только увеличивать MTU, но...

В общем - см. выше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Выход - не использовать pptpclient, использовать, например, mpd.

 

MPD - все-же юниксовый вариант pptp. Точнее - наоборот. Сначала был Юникс (МПД) а уж потом - линух с пптп.

На линухе, я думаю, MPD работать будет кривовато....

 

Хотя в принципе я согласен что mpd под BSD сделан получше чем pptplinux под линукс.

Но что-то мне говорит что траблы все-же на Корбиновских кисках-ВПНах...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

MPD - все-же юниксовый вариант pptp. Точнее - наоборот. Сначала был Юникс (МПД) а уж потом - линух с пптп.

На линухе, я думаю, MPD работать будет кривовато....

 

Хотя в принципе я согласен что mpd под BSD сделан получше чем pptplinux под линукс.

Но что-то мне говорит что траблы все-же на Корбиновских кисках-ВПНах...

 

Я так понимаю, под pptplinux имелся ввиду pptpclient?

 

Может там траблы и есть - не могу этого гарантировать, но в моём случае 99% (а может и все 100) траблов было вызвано именно потерей фрагментированных пакетов pptpclient'ом. Фрагментированные пакеты доходят до моего роутера в нормальном виде, а вот pptpclient их в упор не видит... ;)

 

Да, корбина может со своей стороны поправить ситуацию - не допускать отправки фрагментированных пакетов со своей стороны (уменьшить MTU на ppp'шном канале, аналогично уменьшению на стороне клиента - см. мой предыдущий пост). Но я, честно говоря, очень сомневаюсь, что они будут что-то менять по просьбе клиентов... ;) (хотя это снизило бы нагрузку на их же оборудование - не надо было бы по нескольку раз пересылать один и тот же пакет)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

> MPD - все-же юниксовый вариант pptp. Точнее - наоборот. Сначала был Юникс (МПД)

> а уж потом - линух с пптп. На линухе, я думаю, MPD работать будет кривовато....

 

MPD -- это исключительно фрибсдшный (не других бсд) демон. Он завязан на фришный нетграф которого нигде больше нет.

 

Единственные тулы работающие на всех юниксах: pppd + pptp

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сдается мне, вы не там с MTU играетесь. Надо уменьшать на ethernet интерфейсе, так как сообщение говорит о том, что на ethernet пакеты теряются.

 

терорист верно говорит.

сами смотрите:

 

ping -q -c 40 -s 1250 vpn.corbina.net

--- vpn.corbina.net ping statistics ---

40 packets transmitted, 40 packets received, 0% packet loss

round-trip min/avg/max = 5.7/8.0/20.4 ms

 

ping -q -c 40 -s 1450 vpn.corbina.net

--- vpn.corbina.net ping statistics ---

40 packets transmitted, 35 packets received, 12% packet loss <------- packet loss

round-trip min/avg/max = 6.9/25.0/302.7 ms

 

это трабла с ихними vpn серваками или up-линком из моего района т.к. до default gateway ничего не теряется

 

уменьшение mtu на ethernet интерфейсе уменьшает кол-во потерь но не спасает совсем

 

ЗЫ:

на выходных буду пробовать l2tp

хотя врядли поможет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах