[sisyphus] ошибка pptp

[sisyphus] ошибка pptp

[Андрей Коновалов]

	Здравствуйте все. Следующий сабж прёт просто как из пулемёта:  localhost 
pptp[13257]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 38 
expecting 37, lost or reordered)

[root@localhost ~]# rpm -qa | grep ppp
ppp-2.4.4-alt10
kdenetwork-kppp-3.5.9-alt1
ppp-common-0.4.2-alt1

[root@localhost ~]# rpm -qa | grep pptp
pptp-client-1.7.0-alt1
alterator-net-pptp-0.5.5-alt3

[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.24-ice-wks-alt1 #1 SMP Mon Feb 25 08:44:22 MSK 
2008 i686 GNU/Linux

Никто не в курсе как исправить ситуацию?

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

[Denis Ovsienko]

> 	Здравствуйте все. Следующий сабж прёт просто как из
> пулемёта:  localhost pptp[13257]: anon log
> [decaps_gre:pptp_gre.c:407]: buffering packet 38 expecting 37, lost
> or reordered)

Я бы посмотрел на пакеты GRE-туннеля, вероятно, что они на самом деле
приходят не в том порядке, в котором были отправлены. В этом случае
PPtP-клиент не виноват.

-- 
    DO4-UANIC

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

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Alexey Novikov]

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

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

[Michael Shigorin]

On Thu, Mar 20, 2008 at 03:49:09PM +0300, Alexey Novikov wrote:
> Для меня подошел 1432 если мне память не изменяет.

Уфф... хорошо, поставлю 1400.  0.5.7-alt1 там же:
http://fly.osdn.org.ua/~mike/packages/alterator-net-pptp/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Michael Shigorin]

On Thu, Mar 20, 2008 at 11:55:52AM +0000, Michael Shigorin wrote:
> On Thu, Mar 20, 2008 at 03:49:09PM +0300, Alexey Novikov wrote:
> > Для меня подошел 1432 если мне память не изменяет.
> Уфф... хорошо, поставлю 1400.  0.5.7-alt1 там же:
> http://fly.osdn.org.ua/~mike/packages/alterator-net-pptp/

JFYI: туда же и в Sisyphus выложен 0.5.8-alt1:

* Tue Apr 22 2008 Michael Shigorin <mike@altlinux> 0.5.8-alt1
- "kludgy krap" release
- hacked to allow PPTP-over-PPP:
  + start PPTP interface numbering with "ppp1"
  + if ppp0 is active (via dialer, not etcnet) on module startup,
    append it to interface list
  + don't try to REQUIRE dynamic interface like that either

тж. https://bugzilla.altlinux.org/show_bug.cgi?id=15400

Просьба пользующимся PPTP поверх другого PPP уделить минутку 
внимания; отзывы лучше всего оставлять в баге.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

On Thu, Mar 20, 2008 at 02:39:21PM +0300, Sergey Vlasov wrote:
> Обычно не "приходят не в том порядке", а просто пропадают.
> Частая причина подобных проблем - неверные настройки MTU; в
> опциях pppd следует использовать, например, mtu 1460 (если в
> сети нет ничего странного типа вложеных туннелей), или mtu 1400
> (это значение по умолчанию использует Windows XP).

Хм, почему-то думал, что давно поставил mtu 1476 (#11988 c3
и #14730)...  оказалось, нет.  Ставлю 1460, пожалуй.

0.5.6-alt1, заинтересованным просьба посмотреть:
http://fly.osdn.org.ua/~mike/packages/alterator-net-pptp/

> При использовании etcnet опцию --nobuffer для pptp можно
> передавать через переменную PPTP_EXTRA_OPTIONS, дополнительные
> опции для pppd - через PPPOPTIONS.

Порекомендуешь тоже врисовать в alterator-net-pptp?
Вроде звучит разумно.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

On Thu, Mar 20, 2008 at 02:39:21PM +0300, Sergey Vlasov wrote:
> Кроме того, у /usr/sbin/pptp есть опция --nobuffer, отключающая проверки
> порядкового номера пакетов и попытки их переупорядочивания.  В этом случае
> пакеты будут просто передаваться в псевдотерминал в том порядке, в котором
> они приходят по сети, и с потерянными пакетами будет разбираться уже
> реализация PPP в ядре; если не используется сжатие или шифрование, эти
> потери будет приводить только к потерям соответствущих IP-пакетов,
> передаваемых через туннель, не оказывая влияние на прохождение других
> пакетов (а вот при использовании буферизации в pptp после потери пакета
> туннель оказывается заблокированным на некоторое время, пока pptp ждёт
> пакета с нужным номером).

$ ps afxww |grep pp
17914 ?        Ss     0:00 /usr/sbin/pppd nolog updetach unit 42 local pty /usr/sbin/pptp --nolaunchpppd 10.0.0.1 --nobuffer file /etc/net/ifaces/ppp42/pppoptions
25123 ?        S      1:25  \_ pptp: GRE-to-PPP gateway on /dev/ptmx  --nobuffer
25127 ?        S      0:00 pptp: call manager for 10.0.0.1  --nobuffer

$ sudo tail -1 /var/log/daemons/warnings
Mar 20 22:45:06 wrars-comp pptp[25123]: anon warn[decaps_gre:pptp_gre.c:419]: discarding bogus packet 1261156 (expecting 1258763)

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> Можно апачей вешать на старшие порты, а перед ними вешать одного
> апача с mod_proxy.
Эээ... а мы не получим +1, Funny?
		-- mike in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Андрей Коновалов]

В сообщении от Thursday 20 March 2008 22:46:11 Andrey Rahmatullin написал(а):
> sudo tail -1 /var/log/daemons/warnings

Всем большое спасибо. Игры с mtu помогли.

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

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

On Thu, Mar 20, 2008 at 10:46:11PM +0500, Andrey Rahmatullin wrote:
> On Thu, Mar 20, 2008 at 02:39:21PM +0300, Sergey Vlasov wrote:
> > Кроме того, у /usr/sbin/pptp есть опция --nobuffer, отключающая проверки
> > порядкового номера пакетов и попытки их переупорядочивания.  В этом случае
> > пакеты будут просто передаваться в псевдотерминал в том порядке, в котором
> > они приходят по сети, и с потерянными пакетами будет разбираться уже
> > реализация PPP в ядре; если не используется сжатие или шифрование, эти
> > потери будет приводить только к потерям соответствущих IP-пакетов,
> > передаваемых через туннель, не оказывая влияние на прохождение других
> > пакетов (а вот при использовании буферизации в pptp после потери пакета
> > туннель оказывается заблокированным на некоторое время, пока pptp ждёт
> > пакета с нужным номером).
> 
> $ ps afxww |grep pp
> 17914 ?        Ss     0:00 /usr/sbin/pppd nolog updetach unit 42 local pty /usr/sbin/pptp --nolaunchpppd 10.0.0.1 --nobuffer file /etc/net/ifaces/ppp42/pppoptions
> 25123 ?        S      1:25  \_ pptp: GRE-to-PPP gateway on /dev/ptmx  --nobuffer
> 25127 ?        S      0:00 pptp: call manager for 10.0.0.1  --nobuffer
> 
> $ sudo tail -1 /var/log/daemons/warnings
> Mar 20 22:45:06 wrars-comp pptp[25123]: anon warn[decaps_gre:pptp_gre.c:419]: discarding bogus packet 1261156 (expecting 1258763)

Действительно, часть проверок остаётся и в режиме --no-buffer -
принимаются пакеты, номер которых отличается от ожидаемого не более
чем на 300 (т.е., если будет потеряно более 300 пакетов подряд, после
восстановления связи соединение уже не восстановится).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Maks Re]

ваши рекомендации помогают пользователям корбины?

2008/3/21 Sergey Vlasov <vsu@altlinux.ru>:
> On Thu, Mar 20, 2008 at 10:46:11PM +0500, Andrey Rahmatullin wrote:
>  > On Thu, Mar 20, 2008 at 02:39:21PM +0300, Sergey Vlasov wrote:
>  > > Кроме того, у /usr/sbin/pptp есть опция --nobuffer, отключающая проверки
>  > > порядкового номера пакетов и попытки их переупорядочивания.  В этом случае
>  > > пакеты будут просто передаваться в псевдотерминал в том порядке, в котором
>  > > они приходят по сети, и с потерянными пакетами будет разбираться уже
>  > > реализация PPP в ядре; если не используется сжатие или шифрование, эти
>  > > потери будет приводить только к потерям соответствущих IP-пакетов,
>  > > передаваемых через туннель, не оказывая влияние на прохождение других
>  > > пакетов (а вот при использовании буферизации в pptp после потери пакета
>  > > туннель оказывается заблокированным на некоторое время, пока pptp ждёт
>  > > пакета с нужным номером).
>  >
>  > $ ps afxww |grep pp
>  > 17914 ?        Ss     0:00 /usr/sbin/pppd nolog updetach unit 42 local pty /usr/sbin/pptp --nolaunchpppd 10.0.0.1 --nobuffer file /etc/net/ifaces/ppp42/pppoptions
>  > 25123 ?        S      1:25  \_ pptp: GRE-to-PPP gateway on /dev/ptmx  --nobuffer
>  > 25127 ?        S      0:00 pptp: call manager for 10.0.0.1  --nobuffer
>  >
>  > $ sudo tail -1 /var/log/daemons/warnings
>  > Mar 20 22:45:06 wrars-comp pptp[25123]: anon warn[decaps_gre:pptp_gre.c:419]: discarding bogus packet 1261156 (expecting 1258763)
>
>  Действительно, часть проверок остаётся и в режиме --no-buffer -
>  принимаются пакеты, номер которых отличается от ожидаемого не более
>  чем на 300 (т.е., если будет потеряно более 300 пакетов подряд, после
>  восстановления связи соединение уже не восстановится).
>
> -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.7 (GNU/Linux)
>
>  iD8DBQFH45QqW82GfkQfsqIRAvipAJ4sscjkmkvK75hL5o1Hq0xC1dmLagCfZzBV
>  Bf3GMqzIt/gJU1qo/jmJGaY=
>  =zLjS
>  -----END PGP SIGNATURE-----
>
> _______________________________________________
>  Sisyphus mailing list
>  Sisyphus@lists.altlinux.org
>  https://lists.altlinux.org/mailman/listinfo/sisyphus
>



-- 
С уважением,
 Макс.