Re: [sisyphus] ошибка pptp

[Alexey Novikov <shader@yandex.ru>]

On Thu, Mar 20, 2008 at 02:39:21PM +0300, Sergey Vlasov wrote:
> On Wed, Mar 19, 2008 at 11:56:24PM +0300, Denis Ovsienko wrote:
> > > 	Здравствуйте все. Следующий сабж прёт просто как из
> > > пулемёта:  localhost pptp[13257]: anon log
> > > [decaps_gre:pptp_gre.c:407]: buffering packet 38 expecting 37, lost
> > > or reordered)
> > 
> > Я бы посмотрел на пакеты GRE-туннеля, вероятно, что они на самом деле
> > приходят не в том порядке, в котором были отправлены. В этом случае
> > PPtP-клиент не виноват.
> 
> Обычно не "приходят не в том порядке", а просто пропадают.  Частая причина
> подобных проблем - неверные настройки MTU; в опциях pppd следует
> использовать, например, mtu 1460 (если в сети нет ничего странного типа
> вложеных туннелей), или mtu 1400 (это значение по умолчанию использует
> Windows XP).  Если этих опций нет, по умолчанию может быть установлено mtu
> 1500, в результате пакеты GRE передаются с фрагментацией, что увеличивает
> вероятность их потери (в особо клинических случаях фрагменты вообще
> оказываются отфильтрованными).
> 
> Кроме того, у /usr/sbin/pptp есть опция --nobuffer, отключающая проверки
> порядкового номера пакетов и попытки их переупорядочивания.  В этом случае
> пакеты будут просто передаваться в псевдотерминал в том порядке, в котором
> они приходят по сети, и с потерянными пакетами будет разбираться уже
> реализация PPP в ядре; если не используется сжатие или шифрование, эти
> потери будет приводить только к потерям соответствущих IP-пакетов,
> передаваемых через туннель, не оказывая влияние на прохождение других
> пакетов (а вот при использовании буферизации в pptp после потери пакета
> туннель оказывается заблокированным на некоторое время, пока pptp ждёт
> пакета с нужным номером).
> 
> При использовании etcnet опцию --nobuffer для pptp можно передавать через
> переменную PPTP_EXTRA_OPTIONS, дополнительные опции для pppd - через
> PPPOPTIONS.
Попробуйте еще --loglevel 0, где-то в сети были предположения о
вносимой задержке именно при выводе отладочной информации. Ну и
про MTU, я подбирал с помощью ping -s <размер пакета>, там в первой строчке
в скобках как раз выводится размер всего IP-пакета, т.е.
<размер пакета>+<размер заголовков IP-пакета=28>, так вот
максимальный проходящий и есть MTU, ИМХО.
Для меня подошел 1432 если мне память не изменяет.

-- 
WBR, Alexey Novikov
XMPP: alex-novikov@jabber.ru, shader@ya.ru