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.