Есть множество причин, по которым ваше соединение не будет работать, chat не сумел завершиться правильно, неправильная строчка и т.д. Проверьте записи в вашем syslog.
Самая общая проблема состоит в том, что люди компилируют поддержку PPP в ядро и тем не менее, когда они пытаются выполнить pppd, ядро жалуется, что оно не поддерживает ppp! Имеется ряд причин, посему это может происходить.
Хорошая проверка для ядра - команда uname -a, которая должна вывести
______________________________________________________________________ Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586 ______________________________________________________________________
Выведены версия ядра и дата, когда это ядро компилировалось - этого должно быть достаточно, чтобы разобраться с данным вопросом.
Вы можете получить такую ошибку, если вы вкомпилировали поддержку ppp в ваше ядро как модуль, но сам модуль не построили и не установили. Посмотрите Kernel-HOWTO и файл README в /usr/src/linux!
Другая версия, относящаяся к проблеме с модулем, состоит в том, что вы ожидаете, что требуемые модули будут автоматически загружены, но не запустили демон kerneld (который на лету автоматически загружает и выгружает модули).
Проверьте kerneld mini-HOWTO для информации по настройке kerneld.
Вы должны использовать ppp-2.2 с ядром версии 2.0.x. Вы можете использовать ppp-2.2 с ядром версии 1.2.x (если вы отпатчилиядро) иначе вы должны использовать ppp-2.1.2.
Если вы не запускаете pppd от пользователя root (и pppd - не suid для root), то вы может получить это сообщение.
На это может иметься бесконечное множество причин (см. comp.os.linux...).
САМАЯ основная ошибка - вы имеете опечатки в ваших скриптах. Единственое, что здесь можно сделать - это удостовериться, в правильной работе сценария chat, пролистав ваш syslog (/var/log/messages) строчка за строчкой.
Можно попробовать попытаться соединиться с PPP сервером вручную, чтобы проверить не изменились ли условия регистрации в системе.
Вы должны очень тщательно проверить лог-файл и посмотреть там реально выдаваемые подсказки и имейте в виду, что мы - люди часто заменяем в своем воображении фактически написанный текст на тот, который нам показался написаным на этом месте!
в этом случае также возможны варианты - например последовательная линия looped обратно и т.д., и происходить это может по ряду причин.
Чтобы понять, что происходит, необходимо немного углубиться в процессы, происходящие в pppd непосредственно.
Когда pppd запускается, он посылает LCP (протокол управления связи) пакеты удаленной машине. Если он получает приемлемый ответ, то переходит в следующую стадию (используя IPCP пакеты) и только когда эти переговоры завершаются - начинает действовать IP уровень так, чтобы вы могли использовать связь PPP.
Если на удаленном конце линии нет ppp сервера, то когда ваш PC посылает lcp пакеты, они возвращаются искаженными процессом login на удаленномй конце. Поскольку эти пакеты используют 8 битов, а вернувшиеся пакеты приходят с отрезанным 8-ым битом (вспомните, что ASCII - 7 разрядный код), то PPP видит это и соответственно жалуется.
Имеется несколько причин такого отражения сигналов.
Когда ваш сценарий chat завершается, на вашем PC запускается pppd. Однако, если вы не завершили процесс входа в систему на сервере (включая посылку команды, требуемой для запуска PPP на сервере), то PPP не запустится.
Так lcp пакеты отражаются, и вы получаете эту ошибку.
Вы должны тщательно проверить и исправить (в случае необходимости) ваш сценарий chat (см. выше).
Некоторые PPP серверы требуют, чтобы вы ввели команду и/или нажали return после завершения процесса регистрации, чтобы на удаленном конце стартовал ppp.
Проверьте ваш сценарий chat (см. выше).
Если вы регистрируетесь вручную и обнаруживаете, что после этого вы должны послать return, чтобы запустить PPP, то просто добавьте пустую пару "ожидаемое- посылаемое" в конец вашего сценария chat (пустая "посылаемая" строка фактически посылает return).
This one is a bit tricksy!
По умолчанию, ваш Linux pppd скомпилирован для посылки максимум 10 lcp запросов конфигурации. Если сервер медленно отвечает, то все 10 таких запросов могут передаться до того, как удаленный PPP будет готов получить их.
На вашей машине pppd видит, что все 10 запросов отражены обратно (с 8-ым отрезанным битом) и завершается.
Имеются два способа обхода:
Добавьте lcp-max-configure 30 в ваши опции ppp. Таким образом увеличивается максимальное число посылаемых lcp пакетов выбора конфигурации. Для действительно медленных серверов вам может понадобиться указать еще большее количество таких пакетов.
В качестве альтернативы вы можете get a bit tricksy in return. Вы, возможно, заметили, что, когда вы регистрировались вручную на PPP сервере, и PPP там запускался, то первый символ ppp мусора был всегда символ тильды ( ).
Это наблюдение можно использовать таким образом - мы можем добавить новую пару "ожидаемое-посылаемое" в конец вашего сценария chat, которая будет ожидать тильду и не посылать ничего. Это можно сделать, например, так:
______________________________________________________________________ \~ '' ______________________________________________________________________
Обратите внимание: поскольку символ тильды имеет специальное значение в shell, то нужно его за'escape'ить (и, следовательно, перед ним поставить наклонную черту влево).
Если pppd отказывается установить маршрут заданный по умолчанию, то, поэтому он (совершенно правильно) отказывается удалять/заменять существующий заданный по умолчанию маршрут.
Обычная причина состоит в том, что некоторые дистрибутивы заданный по умолчанию маршрут устанавливают через ethernet-адаптер, а не через сеть.
См. NAG Linux и Net2/3 HOWTOS для информации о правильной установке вашей платы ethernet и связанных c нею маршрутов.
Также возможно, что ваша LAN уже использует шлюз/маршрутизатор и в вашей таблице маршрутизации на него был установлен маршрут по умолчанию.
Исправление этой последней ситуации может требовать некоторых знаний IP сетей и лежит не охватывается этим HOWTO. Предлагаю вам обратиться к экспертам (в группы новостей).
Имеется много причин, кроме перечисленных, по которым ppp будет не в состоянии соединиться и/или функционировать правильно.
Смотрите PPP FAQ (который является набором вопросов и ответов). Это - очень всесторонний документ, и ответы там ЕСТЬ! Из моего собственного (грустного) опыта, если там нет ответа на ваши вопросы, то проблема - НЕ в ppp! В моем случае я использовал ELF ядро, которое я не нарастил до возможностей, соответствующих ядерным модулям.
Я потратил впустую около 2 дней (и часть ночи), ругая прекрасно работающий PPP сервер, пока меня не осенило!