Bug 6163

Summary: mppe - невозможность согласовать опции ppp
Product: Sisyphus Reporter: Mikhail Yakshin <greycat>
Component: pppAssignee: Dmitry V. Levin <ldv>
Status: CLOSED WORKSFORME QA Contact: qa-sisyphus
Severity: normal    
Priority: P2 CC: mike, mouse
Version: unstable   
Hardware: all   
OS: Linux   
Attachments:
Description Flags
Сбойные пакеты в формате libpcap none

Description Mikhail Yakshin 2005-02-25 13:08:42 MSK 
После какого-из из вот этих двух последних обновлений PPP:

* Вск Фев 13 2005 Kachalov Anton <mouse@altlinux.ru> 2.4.2-alt4

- added MPPE/MPPC support: by default, it's disabled

* Чтв Фев 10 2005 Kachalov Anton <mouse@altlinux.ru> 2.4.2-alt3

- x86_64 support (#6088)

стал себя очень странно вести pptp-туннель. Все в принципе работает, но по
индикаторам (и в /proc это видно, и если смотреть в ifconfig ppp0, в любых
gkrellm'ах и прочих) - постоянно, со строгим периодом где-то в секунду по
интерфейсу проскакивают 2 входящих пакета. Вот эта разница:

Последовательный вызов 1 (на интерфейс ppp0):
          RX packets:3523 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3740 errors:0 dropped:0 overruns:0 carrier:0
          RX bytes:580908 (567.2 KiB)  TX bytes:159245 (155.5 KiB)

Последовательный вызов 2:
          RX packets:3525 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3742 errors:0 dropped:0 overruns:0 carrier:0
          RX bytes:580933 (567.3 KiB)  TX bytes:159270 (155.5 KiB)

Если смотреть, скажем, ethereal'ом ppp0, то ничего почему-то не видно. Если
смотреть "any" - то видны постоянно идущие GRE-пакеты и PPP/CCP - Configuration
Request, Configuration Reject, Configuration Ack.

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

С более ранними ppp этого явления не наблюдалось. На сервере - стоит из M2.4:

ppp-2.4.2-alt2
pptpd-1.1.4-alt3.b4

На клиенте:

ppp-2.4.2-alt4
pptp-client-1.5.0-alt1

В логах примерно так:

pppd[2488]: Received bad configure-nak/rej:  12 06 00 00 00 00 1a 04 78 0018 04
78 00 15 03 2f
last message repeated 7 times
pppd[2488]: CCP: timeout sending Config-Requests

И такая штука повторяется постоянно соответственно. Дампы интересных пакетов я
приложил. На всякий случай - из под Ethereal в формате libpcap, и, если его
нечем смотреть - есть расшифровка прямо тем текстом, что говорит сам Ethereal.

Если включить и на клиенте, и на сервере принудительно опцию nomppe в ppp -
тогда все нормализуется.
Comment 1 Mikhail Yakshin 2005-02-25 13:12:26 MSK 
Created attachment 756 [details]
Сбойные пакеты в формате libpcap
Comment 2 Dmitry V. Levin 2005-03-09 14:20:14 MSK 
Mouse, что ты там напатчил?
Comment 3 Kachalov Anton 2005-03-18 18:07:30 MSK 
пробуем читать это и включить поддержку MPPC:
http://www.gfxcafe.com/VPN%20Howto.html
а также добавить "alias ppp-compress-18 ppp_mppe_mppc" в /etc/modules.conf
Comment 4 Mikhail Yakshin 2005-03-19 12:07:38 MSK 
Замечательно, мне их не включить надо, и не выключить даже, а чтобы проходило
нормальное согласовывание capabilities. Чтобы когда сервер задает некие свои
политики и клиент их не оверрайдит, нормально проходили бы все процедуры
установления взаимных договоренностей. Чтобы не нужно было форсить с обоих
сторон либо mppe/mppc, либо отстуствие оных.
Comment 5 Kachalov Anton 2005-03-19 12:18:32 MSK 
попробовать-то ты можешь?
в новой сборке alt5 я откусил патч MPPE/MPPC, но интересно же вместе с ним.
там немного поменялось поведение по умолчанию.
Comment 6 Mikhail Yakshin 2005-03-21 10:21:52 MSK 
нет, конечно, не могу попробовать. у меня сервер стоит на продакшен-системе,
через нее полсотни человек ходят. собирать тестовый стенд из 2 изолированных
машин - мне сейчас некогда, сложно, и, самое главное, я смысла не вижу - ну,
если настроить все и с той, и с другой стороны _с_ принудительным mppe/mppc -
ну, будет оно работать, допустим - и что дальше?
Comment 7 Denis Smirnov 2007-03-25 22:44:49 MSD 
Раз нет возможности тестить, увы.