From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-Yandex-Spam: 1 X-Yandex-Front: smtp4 X-Yandex-TimeMark: 1206017351 X-MsgDayCount: 1 X-Comment: RFC 2476 MSA function at smtp4.yandex.ru logged sender identity as: shader Date: Thu, 20 Mar 2008 15:49:09 +0300 From: Alexey Novikov To: ALT Linux Sisyphus discussions Message-ID: <20080320124909.GA23293@localhost.localdomain> References: <200803200010.42162.krapa666@gmail.com> <20080319235624.cc847a52.pilot@altlinux.ru> <20080320113921.GJ3835@newmaster.mivlgu.local> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080320113921.GJ3835@newmaster.mivlgu.local> Subject: Re: [sisyphus] =?koi8-r?b?z9vJwsvBIHBwdHA=?= X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.10b3 Precedence: list Reply-To: ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 12:49:21 -0000 Archived-At: List-Archive: List-Post: 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