ALT Linux Bugzilla – #11110

Я правильно понимаю, что речь идет о том что однострочник по ссылке нас спасет?
И достаточно добавить | CLOCAL в tios.c_cflag?

Прошу тестировать бранч mithraen/cbcp в моем git. Если бага пофикшена -- уйдет в
Сизиф.

Приложил в 2.4.4

Как минимум, нужно приложить вот этот патч. Спасибо ребятам из FC6, флагманам
linux-остроения, за их тяжкий и кропотливый труд :-D

Created attachment 1877 [details]
CBCP patch from FC6

После патча от FC, cbcp начинает вести себя следующим образом.
Соединение у клиента виснет на этапе проверки логина-пароля, причем виснет
наглухо. (Висело минут 5-ть не выдавая никаких ошибок, после чего было прервано
вручную). В логе следующее:
Mar 26 15:15:09 piton pppd[21014]: pppd 2.4.4 started by a_ppp, uid 0
Mar 26 15:15:09 piton pppd[21014]: using channel 6
Mar 26 15:15:09 piton pppd[21014]: Using interface ppp0
Mar 26 15:15:09 piton pppd[21014]: Connect: ppp0 <--> /dev/ttyS0
Mar 26 15:15:09 piton pppd[21014]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth
chap MD5> <callback CBCP> <magic 0x7fb0fbe1> <pcomp> <accomp>]
Mar 26 15:15:09 piton pppd[21014]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth
chap MD5> <callback CBCP> <magic 0x7fb0fbe1> <pcomp> <accomp>]
Mar 26 15:15:12 piton pppd[21014]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0>
<magic 0x74e966c1> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint
[local:5e.f7.3f.01.3e.1b.45.dd.88.a5.7c.37.2c.d8.bb.73.00.00.00.00]>]
Mar 26 15:15:12 piton pppd[21014]: sent [LCP ConfRej id=0x2 <callback CBCP>
<mrru 1614>]
Mar 26 15:15:12 piton pppd[21014]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth
chap MD5> <callback CBCP> <magic 0x7fb0fbe1> <pcomp> <accomp>]
Mar 26 15:15:12 piton pppd[21014]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0>
<magic 0x74e966c1> <pcomp> <accomp> <endpoint
[local:5e.f7.3f.01.3e.1b.45.dd.88.a5.7c.37.2c.d8.bb.73.00.00.00.00]>]
Mar 26 15:15:12 piton pppd[21014]: sent [LCP ConfAck id=0x3 <asyncmap 0x0>
<magic 0x74e966c1> <pcomp> <accomp> <endpoint
[local:5e.f7.3f.01.3e.1b.45.dd.88.a5.7c.37.2c.d8.bb.73.00.00.00.00]>]
Mar 26 15:15:12 piton pppd[21014]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth
chap MD5> <callback CBCP> <magic 0x7fb0fbe1> <pcomp> <accomp>]
Mar 26 15:15:12 piton pppd[21014]: cbcp_lowerup
Mar 26 15:15:12 piton pppd[21014]: want: 14
Mar 26 15:15:12 piton pppd[21014]: sent [CHAP Challenge id=0xfb
<8024f3e0c2156059e3ce58a7cbfbd02b84a8>, name = "piton.office.eva.dp.ua"]
Mar 26 15:15:12 piton pppd[21014]: rcvd [LCP Ident id=0x4 magic=0x74e966c1
"MSRASV5.00"]
Mar 26 15:15:12 piton pppd[21014]: rcvd [LCP Ident id=0x5 magic=0x74e966c1
"MSRAS-1-LINK"]
Mar 26 15:15:12 piton pppd[21014]: rcvd [CHAP Response id=0xfb
<1818171e189fb8b7b689dcc210c33cb2>, name = "piton"]
Mar 26 15:15:12 piton pppd[21014]: sent [CHAP Success id=0xfb "Access granted"]
Mar 26 15:15:12 piton pppd[21014]: cbcp_open
Файл options.dialin.ttyS0:
lock
debug 10
kdebug 7
proxyarp
bsdcomp 15
ms-wins 192.168.1.100
ms-dns 192.168.1.253
192.168.1.200:
ipcp-accept-local
ipcp-accept-remote
noauth
proxyarp
#noipdefault
-pap
+chap
nodefaultroute
#unit 2
modem
callback server

Во-первых, опечатка в спеке:
%def_with cpcp

%make_build %{?_with_pam:USE_PAM=y} \
            %{?_with_cbcp:CBCP=y} \

Соответственно, у нас оно вообще не включено. Смотрю ppp 2.4.4 и SuSE, PLD, FC:
у них нет никаких патчей на тему cbcp. Или оно должно работать сразу, или никто
не использует или наши патчи что-то ломают. Сообщу позже, если найду что-то еще.

И баг на nobody. Надо ж перевешивать на текущего майнтейнера :)

Мда, совсем ничего не понятно. pppd висит на select, пока не прибьёшь.
Попробовали  откатить некоторые изменения cbcp.c на версию 2.4.2 и не помогло.
Смотрю diff 2.4.2-2.4.4, пока ничего не понятно. Много изменений в районе
MSCHAP, каких-то NTPassword, mppe и т.п. Возможно, тут что-то не так. Похоже,
remote peer ждет от нас чего-то, узнать бы, чего.

Created attachment 1914 [details]
mppe+mppc corrections

Вот этот патч еще нужно приложить для более корректной работы mppe+mppc. Все
патчи mppe+mppc, адаптированные к 2.4.4 содержат эти строки. Наш вариант патча,
неизвестно где взятый, не содержит. См. еще: 
http://cvs.samba.org/cgi-bin/cvsweb/ppp/pppd/ccp.c.diff?r1=1.48&r2=1.49

Это важная проблема, imho.
Кстати, с последним патчем mppe+mppc начинает работать вроде как, но намертво
вешает ядро после коннекта клиента. Пока не отловили.

Результаты тестов ppp-2.4.4-alt7, сборки уважаемого товарища hiddenman(a).
Опция callback начала пониматься, диалин работает, но сервер не перезванивает 
клиенту. У клиента висит окошко "ожидание ответного вызова", которое со 
временем отваливается по тайм-ауту.

root@piton /etc/ppp # tail -f /var/log/daemons/info |grep pppd
Apr 24 14:57:42 piton pppd[5051]: pppd 2.4.4 started by a_ppp, uid 0
Apr 24 14:57:42 piton pppd[5051]: using channel 2
Apr 24 14:57:42 piton pppd[5051]: Using interface ppp0
Apr 24 14:57:42 piton pppd[5051]: Connect: ppp0 <--> /dev/ttyS0
Apr 24 14:57:42 piton pppd[5051]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth 
chap MD5> <magic 0xd5984c4c> <pcomp> <accomp>]
Apr 24 14:57:43 piton pppd[5051]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth 
chap MD5> <magic 0xd5984c4c> <pcomp> <accomp>]
Apr 24 14:57:45 piton pppd[5051]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> 
<magic 0x5c7018d1> <pcomp> <accomp> <callback CBCP>]
Apr 24 14:57:45 piton pppd[5051]: lcp_reqci: rcvd CALLBACK
Apr 24 14:57:45 piton pppd[5051]: sent [LCP ConfAck id=0x2 <asyncmap 0x0> 
<magic 0x5c7018d1> <pcomp> <accomp> <callback CBCP>]
Apr 24 14:57:45 piton pppd[5051]: cbcp_lowerup
Apr 24 14:57:45 piton pppd[5051]: want: 0
Apr 24 14:57:45 piton pppd[5051]: sent [CHAP Challenge id=0x4d 
<793f743f60e71aa7ab306a3a492a6b8080352b772d48d0>, name 
= "piton.office.eva.dp.ua"]
Apr 24 14:57:46 piton pppd[5051]: rcvd [LCP Ident id=0x3 
magic=0x5c7018d1 "MSRASV5.20"]
Apr 24 14:57:46 piton pppd[5051]: rcvd [LCP Ident id=0x4 
magic=0x5c7018d1 "MSRAS-0-MAXI4"]
Apr 24 14:57:46 piton pppd[5051]: rcvd [CHAP Response id=0x4d 
<f15f751d3a5c674efe1b08b4ba2e96cc>, name = "piton"]
Apr 24 14:57:46 piton pppd[5051]: sent [CHAP Success id=0x4d "Access granted"]
Apr 24 14:57:46 piton pppd[5051]: cbcp_open
Apr 24 14:57:46 piton pppd[5051]: cbcp_sendreq cb_allowed=4
Apr 24 14:57:46 piton pppd[5051]: cbcp_sendreq CONF_USER
Apr 24 14:57:46 piton pppd[5051]: sent [CBCP Request id=0x1 < UserDefined delay 
= 5>]
Apr 24 14:57:46 piton pppd[5051]: rcvd [CBCP Response id=0x1 < UserDefined 
delay = 12 number = 4075>] 34 30 37 35 00
Apr 24 14:57:46 piton pppd[5051]: peer will callback the client on: 4075
Apr 24 14:57:46 piton pppd[5051]: cbcp_sendack cb_type=4
Apr 24 14:57:46 piton pppd[5051]: cbcp_sendack CONF_USER
Apr 24 14:57:46 piton pppd[5051]: sent [CBCP Ack id=0x1 < UserDefined delay = 
12 number = 4075>] 34 30 37 35 00
Apr 24 14:57:46 piton pppd[5051]: rcvd [LCP TermReq 
id=0x5 "\\p\030\37777777721\000<\37777777715t\000\000\000\000"]
Apr 24 14:57:46 piton pppd[5051]: LCP terminated by peer 
(\p^XM-Q^@<M-Mt^@^@^@^@)
Apr 24 14:57:46 piton pppd[5051]: sent [LCP TermAck id=0x5]
Apr 24 14:57:47 piton pppd[5051]: Hangup (SIGHUP)
Apr 24 14:57:47 piton pppd[5051]: Modem hangup
Apr 24 14:57:47 piton pppd[5051]: Connection terminated.
Apr 24 14:57:47 piton pppd[5051]: Connect time 0.1 minutes.
Apr 24 14:57:47 piton pppd[5051]: Sent 0 bytes, received 0 bytes.
Apr 24 14:57:47 piton pppd[5051]: cbcp_start_callback running
Apr 24 14:57:47 piton pppd[5051]: Exit.

Собственно, тут нужно благодарить Pavel Boldin за портирование CBCP патча от
ASP, который был в ppp 2.4.2 и потом исчез из сборки. Так же в этой сборке
последние варианты патча mppe+mppc (у нас не совсем правильный вариант сейчас).
mppe, правда, все равно не работает, по крайней мере, у Piton-а. И еще что-то
исправлено в сборке. Вот здесь можно взять rpm и src.rpm:
http://hasher.devel.cz.ipxp.net/pub/ppp/  (пакеты не подписаны)
Просьба ко всем заинтересованным: проверьте у себя работоспособность всего, чего
сможете. В devel@ проскочила информация о новом баге из-за старого патча, её
тоже нужно решать. В серверном дистрибутиве не должно быть кривого ppp, imho.

Пардон, опечатался, правильная ссылка:
ftp://hasher.devel.cz.ipxp.net/pub/ppp/
Проверяем cbcp (callback) и mppe+mppc

в -alt7 не работает ppp через bluetooth (gprs-линк):

Apr 24 22:51:21 snowflake pppd[11263]: pppd 2.4.4 started by root, uid 0
Apr 24 22:51:22 snowflake hcid[11054]: link_key_request (sba=00:0A:3A:53:35:CE,
dba=00:0F:DE:C2:26:E9)
Apr 24 22:51:26 snowflake pppd[11263]: Serial connection established.
Apr 24 22:51:26 snowflake pppd[11263]: Using interface ppp1
Apr 24 22:51:26 snowflake pppd[11263]: Connect: ppp1 <--> /dev/rfcomm1
Apr 24 22:51:26 snowflake pppd[11263]: Remote message: Congratulations!
Apr 24 22:51:26 snowflake pppd[11263]: PAP authentication succeeded
Apr 24 22:51:27 snowflake pppd[11263]: Could not determine remote IP address:
defaulting to 10.64.64.65
Apr 24 22:51:27 snowflake pppd[11263]: local  IP address 10.205.32.252
Apr 24 22:51:27 snowflake pppd[11263]: remote IP address 10.64.64.65

не тот copy/paste, это пример _правильного_ от ppp-2.4.4-alt2, что в сизифе.
ниже от -alt7:
Apr 24 22:49:21 snowflake pppd[11129]: pppd 2.4.4 started by root, uid 0
Apr 24 22:49:33 snowflake pppd[11129]: Connect script failed
Apr 24 22:49:33 snowflake pppd[11129]: Modem hangup
Apr 24 22:49:33 snowflake pppd[11129]: Connection terminated.
Apr 24 22:49:33 snowflake pppd[11129]: Exit.

Проще говоря, что необходимо изменить в текущей сборке 2.4.4? Мне из обсуждения
это неочевидно.

По ссылке ftp://hasher.devel.cz.ipxp.net/pub/ppp/ я в упор не вижу src.rpm

О да, опять my bad :(
src.rpm теперь там же (и опять же неподписанный, нет там сейчас ключей).
А изменить нужно как минимум патч mppe+mppc, приложить патч CBCP от ASP, который
исчез из сборки и который переделал для 2.4.4 Pavel Boldin, ну и поправить спек
(написать cbcp вместо cpcp). Это все, что вспомнил пока. В ChangeLog описано,
что я делал с момента твоей последней сборки.

С этим ppp творится какой-то бред с выбором девайса.
Несмотря на то что в options указан девайс, вместо него используется консоль.
pppd call cdma у меня категорически отказывается работать

Мда, уже второй глюк, попробую разобраться, какой патч мог это сделать. Судя по
всему, это вернувшийся cbcp, больше нечему. А может попробовать без patch45?

Результаты тестирования ppp-2.4.4-alt3:
1)CBCP: Не работает! На клиенте висит на проверке логина/пароля (на этапе 
дозвона до сервера). На сервере следующее:
root@piton /etc/ppp # tail -f /var/log/daemons/info |grep pppd
May  3 14:14:40 piton pppd[5381]: pppd 2.4.4 started by a_ppp, uid 0
May  3 14:14:40 piton pppd[5381]: using channel 2
May  3 14:14:40 piton pppd[5381]: Using interface ppp0
May  3 14:14:40 piton pppd[5381]: Connect: ppp0 <--> /dev/ttyS0
May  3 14:14:40 piton pppd[5381]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth 
chap MD5> <callback CBCP> <magic 0xcb14f2cb> <pcomp> <accomp>]
May  3 14:14:41 piton pppd[5381]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth 
chap MD5> <callback CBCP> <magic 0xcb14f2cb> <pcomp> <accomp>]
May  3 14:14:43 piton pppd[5381]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> 
<magic 0x4d0105f6> <pcomp> <accomp> <callback CBCP>]
May  3 14:14:43 piton pppd[5381]: sent [LCP ConfRej id=0x2 <callback CBCP>]
May  3 14:14:43 piton pppd[5381]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth 
chap MD5> <callback CBCP> <magic 0xcb14f2cb> <pcomp> <accomp>]
May  3 14:14:44 piton pppd[5381]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> 
<magic 0x4d0105f6> <pcomp> <accomp>]
May  3 14:14:44 piton pppd[5381]: sent [LCP ConfAck id=0x3 <asyncmap 0x0> 
<magic 0x4d0105f6> <pcomp> <accomp>]
May  3 14:14:44 piton pppd[5381]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth 
chap MD5> <callback CBCP> <magic 0xcb14f2cb> <pcomp> <accomp>]
May  3 14:14:44 piton pppd[5381]: cbcp_lowerup
May  3 14:14:44 piton pppd[5381]: want: 14
May  3 14:14:44 piton pppd[5381]: sent [CHAP Challenge id=0x70 
<bd756519fce97b4ddaa85a82eb89f788a2cb>, name = "piton.office.eva.dp.ua"]
May  3 14:14:44 piton pppd[5381]: rcvd [LCP Ident id=0x4 
magic=0x4d0105f6 "MSRASV5.20"]
May  3 14:14:44 piton pppd[5381]: rcvd [LCP Ident id=0x5 
magic=0x4d0105f6 "MSRAS-0-MAXI4"]
May  3 14:14:44 piton pppd[5381]: rcvd [CHAP Response id=0x70 
<4002b71b0056fb7fd141eb626862333b>, name = "piton"]
May  3 14:14:44 piton pppd[5381]: sent [CHAP Success id=0x70 "Access granted"]
May  3 14:14:44 piton pppd[5381]: cbcp_open
2) MPPE по-прежнему ругается на опции, которые так и не удалось подобрать.
Пробовал:
nomppe-40
require-mppe-128
mppe-stateful
############################
require-mppe
mppe-128
mppe-40
Из тех, что помню. Ни одна не подходит.

Сейчас проводим с PITon тестирование ppp без патча mppe+mppc. Пока все
заработало, сообщим позже более точно и cbcp проверим.

В ppp-2.4.4-alt4 собраном многоуважаемым hiddenman и взятом с 
ftp://hasher.devel.cz.ipxp.net/pub/ppp/ наконец-то заработал долгожданный mppe.
Вот выдержки из лога:
root@piton /etc/ppp # tail -f /var/log/messages |grep pppd
May  7 17:52:28 piton pptpd[9356]: CTRL: Starting call (launching pppd, opening 
GRE)
May  7 17:52:28 piton pppd[9357]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so 
loaded.
May  7 17:52:28 piton pppd[9357]: pptpd-logwtmp: $Version$
May  7 17:52:28 piton pppd[9357]: pppd 2.4.4 started by root, uid 0
May  7 17:52:28 piton pppd[9357]: Using interface ppp0
May  7 17:52:28 piton pppd[9357]: Connect: ppp0 <--> /dev/pts/4
May  7 17:52:28 piton pptpd[9356]: GRE: Bad checksum from pppd.
May  7 17:52:28 piton pppd[9357]: MPPE 128-bit stateless compression enabled
May  7 17:52:30 piton pppd[9357]: Cannot determine ethernet address for proxy 
ARP
May  7 17:52:30 piton pppd[9357]: local  IP address 11.11.11.253
May  7 17:52:30 piton pppd[9357]: remote IP address 11.11.11.11
May  7 17:52:30 piton pppd[9357]: pptpd-logwtmp.so ip-up ppp0 piton 
192.168.1.29
May  7 17:52:30 piton pppd[9357]: Script /etc/ppp/ip-up finished (pid 9361), 
status = 0x0

(In reply to comment #12)
> Опция callback начала пониматься, диалин работает, но сервер не перезванивает 
> клиенту. У клиента висит окошко "ожидание ответного вызова", которое со 
> временем отваливается по тайм-ауту.

strace в студию!

Pavel тут нашел ошибку в портированном патче, завтра попробуем новую сборку.
Есть вероятность, что будет работать и mppe и cbcp :)

mppe работает точно. cbcp проверяем прямо сейчас. на
ftp://hasher.devel.cz.ipxp.net/pub/ppp/ доступна сборка alt5 со всеми
исправлениями, просьба проверить всем заинтересованным.

Так как заинтересованных кроме нас не оказалось, пришлось приложить титанические
усилия и всё починить. Большое спасибо Pavel Boldin, PITon и мне :) Теперь работает:
1. mppe+mppc (убран старый патч mppe+mppc, работает без него, с ним вешает ядро
наглухо) 
2. CBCP server:
2.1 Исправлен неработающий chat при накладывании патча
2.2 Исправлено падение pppd при начале процедуры callback
2.3 Теперь, при наличии опции callback server и звонке клиента, который не хочет
callback, соединение не завершается, а просто отрабатывает, как обычный dialin.
Это очень старый баг, который был всё время существования callback server-а.
Соответственно, теперь pppd может выступать и как обычный и как callback сервер
одновременно. Раньше можно было или то или то.
2.4. Продолжение пункта 2.3; теперь, при звонке с windows и использовании
интерактивного диалога на запрос callback, если пользователь нажимает Отмена и
хочет просто dialin, то соединение корректно продолжается как dialin, а не
завершается.
Это все протестировано.

3. Ситуация с  CBCP client пока не прояснилась. Вроде бы работает, сервер
перезванивает, но что-то с auth. Будем смотреть дальше, главное, что сервер
сейчас работает.

Просьба всем заинтересованным проверить работоспособность.

На ftp://hasher.devel.cz.ipxp.net/pub/ppp/ доступны i586 RPMS и SRPM

Кстати, похоже, что наша сборка ppp единственная из всех дистрибутивов с
поддержкой callback server.

Проверил на D-Link 500T/562T. Не работает mppe: РРТР-клиент означенных 
устройств регистрируется на РРТР-сервере, получает адрес, но данные по туннелю 
не передаются.
Находил подобный баг касательно отсутствия обмена данными по mppe-соединению  в 
других дистрибутивах с пометкой "работает на ядрах не новее 2.6.12".
У меня ALC30, ядро - 2.6.16

Гм. А на какой версии работает? Если взять предыдущие сборки с MPPE патчем.
Windows-клиенты заработали с шифрование и компрессией только без патча
mppe+mppe. С ним они вешали ядро (!) и отловить не удалось. Попробуй старую
версию ppp.

Насколько я помню, патча mppe+mppe сейчас нет в других дистрибутивах тоже.
Возможно, дело в ядре все-таки. Вадим, если есть возможность, попробуй разные
версии ppp и ядра.

я попробую переписать патч, что бы он был более приличным.
Там в начальной версии были задатки callback, которые хоть и не работали, не
делали этого по причине простого бага.

Очень нужен тестовый стенд.

Да, стенд бы не помешал.
Увы, я не могу проверить на старом ядре - оно уже фтопке...
А экспериментировать не имею возможности до выхода из отпуска (конец июня).

Имею лишь добавить, что до этой версии пытался поднять функционал mpp(e|c) на 
разных версиях ррр (сизиф/первоисточник) и ядер - всё мимо кассы.
Происходило всё это в наиразличнейших комбинациях, с приложением-откатом 
всевозможных патчей, касающихся тематики.
В итоге отчаялся, снёс ядро 2.6.12-альт-чётотам и жду у моря погоды.
Кстати, с сайта-первоисточника версия, помнится, семёрочкой (в отличие от 
сизифовой шестёрочки) заканчивается. Но и оно ничем не помогло ни на старом, ни 
на теперешнем ядре.

Вадим, так mppe раньше так же не работал или даже не соединялся?

(In reply to comment #36)
> Вадим, так mppe раньше так же не работал или даже не соединялся?

Не соединялся даже. Хотя согласования по +/- H, S, M & L достичь удавалось. А 
без толку.

Что-то я все никак понять не могу, что же сейчас работает, а что не работает?
Пока только увидел неработающий callback-клиент. 

*** Bug 4155 has been marked as a duplicate of this bug. ***

В общем, желающие приглашаются к починке и тестированию.

Так что все-таки не работает? :-)

Спроси piton@, тебе всяко ближе :)

Гм, а он причем, его проблемы мы вроде давно решили :-)

apparently wontfix (or worksforthem?)