Есть очень большая и давняя проблема с cbcp в ppp. В ppp, которое Альт использует сейчас, (2.4.2-alt6.1.1) cbcp не работает в принципе. Feb 16 14:14:31 piton pppd[6718]: pppd 2.4.2 started by a_ppp, uid 0 Feb 16 14:14:31 piton pppd[6718]: speed 10 not supported Feb 16 14:14:31 piton pppd[6718]: Using interface ppp0 Feb 16 14:14:31 piton pppd[6718]: Connect: ppp0 <--> /dev/ttyS0 Feb 16 14:14:34 piton pppd[6718]: LCP terminated by peer ( M-t*M-B^@<M-Mt^@^@^@^@) Feb 16 14:14:35 piton pppd[6718]: Hangup (SIGHUP) Feb 16 14:14:35 piton pppd[6718]: Modem hangup Feb 16 14:14:35 piton pppd[6718]: Connection terminated. Feb 16 14:14:35 piton pppd[6718]: Connect time 0.1 minutes. Feb 16 14:14:35 piton pppd[6718]: Sent 0 bytes, received 0 bytes. Feb 16 14:14:35 piton pppd[6718]: tcgetattr: No such device or address (line 906) Feb 16 14:14:35 piton pppd[6718]: Connect time 0.1 minutes. Feb 16 14:14:35 piton pppd[6718]: Sent 0 bytes, received 0 bytes. Feb 16 14:14:35 piton pppd[6718]: tcsetattr: No such device or address (line 1000) Feb 16 14:14:35 piton pppd[6718]: Exit. Баг известный (http://lists.altlinux.org/pipermail/community/2005-July/163144.html), решение есть (http://www.opennet.ru/openforum/vsluhforumID1/62902.html) но поправить его никто не спешит. При исправлении этого бага руками (пересбока ppp с исправлением ошибки) вылазит еще более давняя проблема ppp и cbcp. Это работа либо только с cbcp либо только с dial-in юзерами. При попытке подключиться без cbcp валятся следующие ошибки: Feb 16 14:02:59 piton pppd[5685]: sent [CBCP Ack id=0x1 < NoCallback delay = 0>] Feb 16 14:02:59 piton pppd[5685]: cbcp_sendack cb_type=2 Feb 16 14:02:59 piton pppd[5685]: cbcp_sendack CONF_NO Feb 16 14:02:59 piton pppd[5685]: sent [CBCP Ack id=0x1 < NoCallback delay = 0>] Feb 16 14:02:59 piton pppd[5685]: rcvd [CBCP Ack id=0x1 < NoCallback delay = 0>] Feb 16 14:02:59 piton last message repeated 4 times Feb 16 14:02:59 piton pppd[5685]: cbcp_sendack cb_type=2 Feb 16 14:02:59 piton pppd[5685]: cbcp_sendack CONF_NO Feb 16 14:02:59 piton pppd[5685]: sent [CBCP Ack id=0x1 < NoCallback delay = 0>] Feb 16 14:02:59 piton pppd[5685]: cbcp_sendack cb_type=2 Feb 16 14:02:59 piton pppd[5685]: sent [LCP TermReq id=0x4 "Sorry, CBCP not responding."] Feb 16 14:02:59 piton pppd[5685]: rcvd [CBCP Ack id=0x1 < NoCallback delay = 0>] Feb 16 14:02:59 piton pppd[5685]: Discarded non-LCP packet when LCP not open Feb 16 14:02:59 piton pppd[5685]: rcvd [CBCP Ack id=0x1 < NoCallback delay = 0>] Feb 16 14:02:59 piton pppd[5685]: Discarded non-LCP packet when LCP not open Feb 16 14:02:59 piton pppd[5685]: rcvd [CBCP Ack id=0x1 < NoCallback delay = 0>] Feb 16 14:02:59 piton pppd[5685]: Discarded non-LCP packet when LCP not open Feb 16 14:02:59 piton pppd[5685]: cbcp_sendack cb_type=2 Feb 16 14:02:59 piton last message repeated 4 times Feb 16 14:02:59 piton pppd[5685]: rcvd [CBCP Ack id=0x1 < NoCallback delay = 0>] Feb 16 14:02:59 piton pppd[5685]: Discarded non-LCP packet when LCP not open Feb 16 14:02:59 piton pppd[5685]: cbcp_sendack cb_type=2 Feb 16 14:02:59 piton pppd[5685]: rcvd [LCP TermReq id=0x4 "Sorry, CBCP not responding."] Feb 16 14:02:59 piton pppd[5685]: sent [LCP TermAck id=0x4] Feb 16 14:02:59 piton pppd[5685]: cbcp_sendack cb_type=2 Feb 16 14:02:59 piton last message repeated 4 times Feb 16 14:02:59 piton pppd[5685]: rcvd [LCP TermAck id=0x4] Feb 16 14:02:59 piton pppd[5685]: Connection terminated. Feb 16 14:02:59 piton pppd[5685]: Connect time 0.2 minutes. Feb 16 14:02:59 piton pppd[5685]: Sent 62 bytes, received 0 bytes. Feb 16 14:02:59 piton pppd[5685]: Connect time 0.2 minutes. Feb 16 14:02:59 piton pppd[5685]: Sent 62 bytes, received 0 bytes. Feb 16 14:02:59 piton pppd[5685]: Exit. /etc/ppp/callback-users: piton * test - * - Expected Results: рабочий cbcp :)
Я правильно понимаю, что речь идет о том что однострочник по ссылке нас спасет? И достаточно добавить | 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?)
