ppp-2.4.4-alt10 mgetty-1.1.31-alt1.1 Настройки (по мотивам http://freesource.info/wiki/SergeyLebedev/EisSystem/PppdSystemEIS ): /etc/inittab: T0:23:respawn:/sbin/mgetty -x5 -s 115200 /dev/ttyS0 /etc/mgetty+sendfax/login.config: /AutoPPP/ - a_ppp /usr/sbin/pppd noauth refuse-chap require-pap /etc/mgetty+sendfax/mgetty.config: port ttyS0 debug 5 data-only y rings 1 /etc/ppp/options.ttyS0: modem noauth refuse-chap require-pap debug crtscts proxyarp 192.168.200.1:192.168.200.2 /etc/ppp/pap-secrets поправлен. При входящем звонке pppd нормально запускается (клиент получает IP... идут пинги с обеих сторон). При программном отсоединении клиента pppd нормально завершается и снова запускается mgetty. При физическом отсоединении (выдёргивание телефонного кабеля) pppd не завершается, хотя по модему видно и слышно (внешний Zyxel), что он правильно отреагировал на разрыв линии. Expected results: при разрыве линии pppd завершается, запускается mgetty. Оказывается, при работе pppd установлен флаг CLOCAL: # stty -a -F /dev/ttyS0 speed 115200 baud; rows 0; columns 0; line = 3; ... -parenb -parodd cs8 hupcl -cstopb cread clocal crtscts ... Он то и не даёт получить признак HANGUP внутри pppd. Причина неправильной установки CLOCAL -- тот самый однострочник из #11110: Patch44: ppp-2.4.2-cbcp.patch Это изменение устанавливает CLOCAL, не глядя, что с этим флагом делается несколькими строчками ниже. См: if (!restore_term) inittermios = tios; tios.c_cflag &= ~(CSIZE | CSTOPB | PARENB | CLOCAL); - tios.c_cflag |= CS8 | CREAD | HUPCL; + tios.c_cflag |= CS8 | CREAD | HUPCL | CLOCAL; tios.c_iflag = IGNBRK | IGNPAR; tios.c_oflag = 0; tios.c_lflag = 0; tios.c_cc[VMIN] = 1; tios.c_cc[VTIME] = 0; if (local || !modem) tios.c_cflag ^= (CLOCAL | HUPCL); В результате поведение функции set_up_tty из pppd/sys-linux.c в части, касающейся этого флага, меняется в точности на противоположное и, во всяком случае, неправильное для dial-in. При откате этого патча имеем (при работе pppd в моём случае): # stty -a -F /dev/ttyS0 ... ... -clocal ... ... и правильное поведение pppd как при логическом завершении соединения, так и при физическом разрыве линии -- pppd завершается. В логах при разрыве линии (удалил начало строк ... pppd[24720]:): Hangup (SIGHUP) Modem hangup Connect time 5.8 minutes. Sent 26493 bytes, received 35962 bytes. Script /etc/ppp/ip-down started (pid 24808) Connection terminated. Waiting for 1 child processes... script /etc/ppp/ip-down, pid 24808 Script /etc/ppp/ip-down finished (pid 24808), status = 0x1 Exit. (такого никогда не было до отката патча). Если вносимое этим патчем изменение CLOCAL необходимо для CBCP, то, по меньшей мере, надо проверять, что режим работы pppd именно CBCP. PS. На Сизифе не тестировал, но, судя по srpmcmp, всё сказанное должно быть применимо и к версии ppp в Sisyphus (ppp-2.4.4-alt10.2.1). PPS. В ppp.spec есть неправильные комментарии касательно патча 44. Вроде бы они должны относиться к патчу 49.
(In reply to comment #0) > PPS. В ppp.spec есть неправильные комментарии касательно патча 44. > Вроде бы они должны относиться к патчу 49. С разбегу не вспомню, но в своё время добавлял патч, который откатывал кусочек предыдущего патча (где-то на ppp должно тоже висеть подробнее). Было бы здорово всё-таки вычистить да протестировать нормально pppd, но сейчас слабо...
Эх, кто бы еще знал, зачем нужен LOCAL для CBCP. Патчи жутно потрошенные, концов не найти. Нужен кто-то, кто знает внутреннее устройство ppp.
перемещаю в сизиф
По-прежнему актуально. Для dial-in в p6 опять-таки пришлось откатить указанную выше строку. Работающие (при dial-in) пакеты версии 2.4.5-alt8 здесь: ftp://ftp.linux.kiev.ua/pub/Linux/ALT/people/_aoliakh/p6/ppp/ Есть желание разобраться с CBCP, чтобы сделать правильно. Приму помощь в виде подсказок, как должен работать callback и как его можно протестировать, а также в виде описания рабочих callback-конфигураций. Заведу для этого тред в sisyphus@.