Глава 14. PPP

Первым делом прочтите страницу Справочника ppp(8) и раздел PPP Руководства. Для помощи с устранением неполадок включите протоколирование следующей командой:

set log Phase Chat Connect Carrier lcp ipcp ccp command

Эту команду можно набрать в командной строке ppp(8) или ввести в начале раздела default в /etc/ppp/ppp.conf. Проверьте, что файл /etc/syslog.conf содержит указанные ниже строки и существует файл /var/log/ppp.log:

!ppp
*.*    /var/log/ppp.log

Полную информацию о происходящем можно найти в файле протокола. Не беспокойтесь, если не всё будет понятно, ведь это может быть понятно кому-то ещё.

Обычно это происходит, когда имя хоста не может быть преобразовано в адрес. Наилучший способ исправить это - удостовериться, что файл /etc/hosts читается первым. Для этого нужно проверить, что в файле /etc/host.conf на первом месте стоит строчка hosts. Затем добавьте в файл /etc/hosts запись о локальной машине. Если локальная сеть отсутствует, измените строку для localhost:

127.0.0.1	foo.example.com foo localhost

В противном случае добавьте для хоста ещё одну запись. Обратитесь к соответствующим страницам Справочника за подробным описанием.

В конце убедитесь, что эта команда выполняется успешно: ping -c1 `hostname`.

Сначала проверьте наличие маршрута по умолчанию. Команда netstat -rn должна показать две строки:

Destination	Gateway	    Flags    Refs     Use     Netif Expire
default 	10.0.0.2    UGSc	0	0      tun0
10.0.0.2	10.0.0.1    UH		0	0      tun0

Если нет маршрута по умолчанию, убедитесь, что строка HISADDR была добавлена в /etc/ppp/ppp.conf.

Другая причина отсутствия строки с маршрутом по умолчанию может крыться в том, что маршрут по умолчанию был добавлен в /etc/rc.conf, и эта строка отсутствует в /etc/ppp/ppp.conf:

delete ALL

В таком случае обратитесь к соответствующему разделу Руководства.

Обычно эта ошибка появляется из-за отсутствия в файле /etc/ppp/ppp.linkup следующего раздела:

MYADDR:
  delete ALL
  add 0 0 HISADDR

Он необходим только для динамического IP адреса или когда адрес маршрутизатора не известен. При использовании интерактивного режима можно набрать следующие команды после входа в пакетный режим. Пакетный режим обозначается заглавными буквами PPP в приглашении:

delete ALL
add 0 0 HISADDR

Обратитесь к разделу PPP и динамические IP адреса Руководства за подробной информацией.

Таймаут для PPP по умолчанию равен 3 минутам. Это может быть изменено такой строкой:

set timeout NNN

где NNN - время неактивности в секундах, после которого соединение закрывается. Если NNN равно нулю, соединение никогда не разрывается по таймауту. Эту команду можно поместить в файл ppp.conf или набрать ее в интерактивном режиме. Изменение этого параметра также возможно при активном соединении, если подключиться к сокету ppp сервера с помощью программ telnet(1) или pppctl(8). Обратитесь к страницам Справочника, посвящённым ppp(8).

Если включен Link Quality Reporting (LQR), то возможно слишком много пакетов LQR теряется в канале. ppp(8) делает вывод, что канал плох, и разрывает соединение. LQR по умолчанию выключен. Включить LQR можно так:

enable lqr

Иногда на шумной линии или даже на линии с включенным режимом ожидания звонка модем может вешать трубку, ошибочно полагая, что потеряна несущая.

В большинстве модемов есть параметр, определяющий чувствительность к временной потере несущей. Обратитесь к документации модема.

Многие сообщают об обрывах соединений без видимой причины. Первым делом нужно выяснить, с какой стороны рвётся соединение.

При использовании внешнего модема проверьте утилитой ping(8), мигает ли индикатор TD при передаче данных. Если он мигает, а индикатор RD нет, проблема с той стороны. Если TD не загорается, проблема является локальной. Для внутреннего модема используйте команду set server в ppp.conf. При обрыве связи подключитесь к ppp(8) с помощью pppctl(8). Если сетевое подключение неожиданно восстанавливается при проявлении активности на диагностическом сокете или нет соединения, но команда set socket в начальный момент была выполнена успешно, то проблема имеет локальный характер. Если получается подключиться, но связи всё равно нет, включите вывод локальной отладочной информации командой set log local async и используйте ping(8) в другом окне или терминале, чтобы проверить связь. В отладочном выводе будут показаны данные, передаваемые и получаемые из канала связи. Если данные посылаются, но не принимаются обратно, то проблема с той стороны.

Теперь, после выяснения местонахождения проблемы, имеется два варианта действий:

Здесь мало что можно сделать. Большинство провайдеров отказываются помогать пользователям, которые не используют ОС от Microsoft(R). Добавьте enable lqr в /etc/ppp/ppp.conf, чтобы позволить ppp(8) отследить ошибки в удалённой системе и закрыть соединение. Такое обнаружение достаточно медленно и поэтому не так уж полезно.

Первым делом попробуйте отключить любое сжатие, указав в конфигурационном файле следующее:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Теперь попробуйте установить соединение ещё раз и удостоверьтесь, что ситуация не изменилась. Если качество соединения улучшилось или проблема оказалась полностью решённой, выясните, настройка чего приводила к проблемам методом проб и ошибок. Это полезная информация для провайдера, хотя при этом может обнаружиться, что вы работаете не с продуктом Microsoft(R).

Перед тем, как звонить провайдеру, включите вывод отладочной информации и подождите, пока соединение снова не прервётся. Для этого может потребоваться некоторое дисковое пространство. Интерес могут представлять последние прочитанные из порта данные. Обычно это данные в формате ASCII и они могут даже содержать описание проблемы (Memory fault, Core dumped).

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

В этом случае перекомпилируйте ppp(8) с отладочной информацией, и затем используйте gdb(1) для получения стека вызовов для зависшего процесса ppp. Чтобы откомпилировать программу ppp с отладочной информацией, наберите такие команды:

# cd /usr/src/usr.sbin/ppp
# env DEBUG_FLAGS='-g' make clean
# env DEBUG_FLAGS='-g' make install

Затем перезапустите ppp и дождитесь следующего зависания. Когда отладочная сборка ppp(8) зависнет, запустите gdb для зависшего процесса:

# gdb ppp `pgrep ppp`

В приглашении gdb используйте команду bt или where для получения стека вызовов. Сохраните вывод сессии gdb и <<отключитесь>> от работающего процесса, выполнив команду quit в gdb.

Иногда, сразу после установления соединения, в журнале могут возникать сообщения Magic is the same. Иногда эти сообщения проходят безболезненно, а иногда одна из сторон прекращает работу. Большинство реализаций PPP не может справиться с такой ситуацией, и даже когда связь выглядит установившейся, вы будeт только бесконечно повторяющиеся конфигурационные запросы и подтверждения в файле протокола до тех пор, пока ppp(8) окончательно не закроет соединение.

Обычно это происходит на серверах с медленными дисками, на которых порт обслуживает программа getty(8), а ppp(8) выполняется из сценария регистрации или другой программы после регистрации пользователя. Были сообщения, что такое случается постоянно при использовании slirp. Причина заключается в том, что во время, проходящее между завершением работы getty(8) и запуском ppp(8), ppp(8) со стороны клиента начинает посылать пакеты Line Control Protocol (LCP). Так как режим эха остаётся всё ещё включенным, ppp(8) клиента получает <<отражения>> своих запросов.

Частью процесса согласования параметров LCP является определение <<магического>> числа для каждой стороны соединения для обнаружения <<отражений>>. Согласно спецификации, когда одна сторона пытается использовать совпадающее "магическое" число, должен быть послан ответ NAK и должно быть выбрано новое "магическое" число. В тот момент, когда на порту сервера включен режим эха, клиент ppp(8) посылает пакеты LCP, получает то же самое "магическое" число в отражённом пакете и отвечает на него NAK. Он также видит отражённый NAK (который также означает, что ppp(8) должен изменить своё "магическое" число). В потенциале это может вызвать появление огромного количества процессов смен "магических" чисел, и все они накапливаются в буфере терминала. Как только запустится сервер ppp(8), он будет перегружен запросами на смену "магических", немедленно решит, что этого много для согласования LCP и прервёт соединение. В то же самое время, клиент, который больше не видит отражений, останавливается для того, чтобы увидеть, что сервер закрыл соединение.

Этого можно избежать, позволив начинать согласование противоположной стороне следующей строкой в файле ppp.conf:

set openmode passive

Это заставит ppp(8) ожидать начала согласования LCP. Некоторые серверы, однако, могут никогда не начать согласование. В этом случае попробуйте сделать следующее:

set openmode active 3

Это заставит ppp(8) пассивно ждать 3 секунды, и только затем посылать запросы LCP. Если противоположная сторона начнёт посылать в этот момент запросы, ppp(8) немедленно ответит, не ожидая истечения трёхсекундного интервала.

В настоящий момент одной из неприятных особенностей реализации ppp(8) является то, что она не связывает сообщения LCP, CCP & IPCP с запросами. Как результат, если реализация PPP с одной стороны более чем на 6 секунд медленнее, чем с другой, противоположная сторона будет посылать два дополнительных запроса на согласование параметров LCP. Это фатально.

Предположим, что у нас работают две реализации, на машинах A и B. A начинает посылать запросы LCP сразу же после соединения, а B требуется 7 секунд для запуска. Когда B запускается, A послало 3 LCP-запроса. Полагаем, что режим эха выключен, в противном случае мы столкнулись бы с проблемами "магического" числа, описанными в предыдущем разделе. B посылает REQ, затем ACK на первый REQ от A. Это приводит к тому, что A входит в состояние OPENED и посылает (первый) ACK обратно B. В то же самое время B посылает обратно ещё два ACK в ответ на два дополнительных REQ, посланные A до старта B. B затем получает первый ACK от A и возвращается в состояние REQ-SENT, послав ещё один (четвёртый) REQ согласно RFC. Затем он получает третий ACK и входит в состояние OPENED. В это же время B принимает четвёртый REQ от A, что возвращает его в состояние ACK-SENT и посылает ещё один (второй) REQ и (четвёртый) ACK согласно RFC. A получает REQ, переходит в состояние REQ-SENT и посылает ещё один REQ. Он немедленно принимает последующий ACK и входит в состояние OPENED.

Это будет продолжаться до тех пор, пока одна из сторон не обнаружит, что это ни к чему не приводит и не закроет соединение.

Лучшим способом избежать этой ситуации является конфигурация одной из сторон как passive, чтобы она ждала другую для начала согласования. Это можно сделать следующей командой:

set openmode passive

С этой командой нужно быть осторожным. Эту команду можно также использовать для ограничения периода ожидания, в течении которого ppp(8) ждёт начала согласования с противоположной стороны:

set stopped N

Как вариант, может быть использована следующая команда (где N - период ожидания в секундах перед тем, как начать согласование):

set openmode active N

За дополнительной информацией обращайтесь к странице Справочника.

При использовании shell или ! ppp(8) запускает оболочку или переданные параметры. Программа ppp будет ждать окончания выполнения команды, прежде чем продолжить. При любой попытке воспользоваться связью PPP во время выполнения команды связь будет выглядеть заблокированной. Это происходит из-за того, что ppp(8) ждёт завершения команды.

Для выполнения подобных команд используйте вместо этого !bg. В этом случае нужная команда будет выполняться в фоновом режиме, а ppp(8) сможет продолжить обслуживание канала связи.

ppp(8) не может определить, что соединение было закрыто. Это происходит из-за метода использования сигнальных линий нуль-модемного кабеля. При использовании такого типа соединения всегда включайте LQR:

enable lqr

По умолчанию LQR включается, если это было затребовано с противоположной стороны на этапе согласования параметров соединения.

Если ppp(8) начинает неожиданно звонить, определите причину и настройте фильтры дозвона для предотвращения подобных звонков.

Для выяснения причины такого поведения, используйте строку:

set log +tcp/ip

Это включит протоколирование всего трафика через соединение. В следующий раз, когда неожиданно будет установлено соединение, в файл протокола будет следом занесена причина с отметкой времени.

Теперь отключите дозвон при данных условиях. Как правило, такие проблемы возникают из-за обращений к DNS. Для предотвращения обращений к DNS и установления соединения (что не запретит ppp(8) пропускать пакеты через уже установленное соединение), используйте такую комбинацию:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

Это не всегда удобно, так как закрывает возможность дозвона по запросу. Большинству программ нужно обратиться к DNS до того, как начать работать.

В случае DNS попытайтесь установить, что именно пытается определить имя хоста. В большинстве случаев виновным оказывается Sendmail. Проверьте, чтобы в конфигурационном файле программы Sendmail не было указано обращаться к DNS. Обратитесь к разделу об использовании электронной почты при коммутируемом соединении в Руководстве FreeBSD за подробным описанием. Вам может понадобиться добавить в файл .mc строку:

define(`confDELIVERY_MODE', `d')dnl

Это заставит Sendmail добавлять все сообщения в очередь до тех пор, пока не будет запущена её обработка, как правило, каждые 30 минут, или пока не будет выполнена команда sendmail -q, возможно, из файла /etc/ppp/ppp.linkup).

В файле протокола появляются такие сообщения об ошибках:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)

Это происходит, если ppp(8) пытается установить сжатие Predictor1, а противоположная сторона не хочет устанавливать никакого сжатия. Эти сообщения безобидны, но их можно заглушить отключением сжатия:

disable pred1

Для записи полного протокола взаимодействия с модемом включите следующее:

set log +connect

Это заставит ppp(8) протоколировать всё, вплоть до последней прочтённой через <<expect>> строки.

Чтобы увидеть скорость соединения при использовании PAP или CHAP, укажите ppp(8) ожидать полную строку CONNECT:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Здесь мы получаем строку CONNECT, ничего не посылаем, а затем ожидаем символа перевода строки, заставляя ppp(8) читать целиком содержимое ответа CONNECT.

Программа ppp разбирает каждую строку в конфигурационных файлах и поэтому может правильно интерпретировать строки вида set phone "123 456 789" и обнаруживать, что на самом деле номер является единственным аргументом. Для того, чтобы указать символ ", заэкранируйте его символом обратного слэша (\).

Когда интерпретатор chat разбирает каждый параметр, он ещё раз просматривает аргумент на предмет каких-либо специальных последовательностей типа \P или \T. Вследствие этой двойной интерпретации не забывайте об использовании нужного количества экранирующих символов.

Чтобы передать сам символ \, укажите что-то типа:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

Это приведёт к такой последовательности:

ATZ
OK
AT\X
OK

Или:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"

Это даст такую последовательность:

ATZ
OK
ATDT1234567

Эта проблема проявлялась, когда ppp(8) в режиме -auto был настроен на динамическое согласование локального IP-адреса с противоположной стороной. Это было давно исправлено - поищите на странице справочника слово iface.

Причиной было то, что когда эта программа использует системный вызов connect(2), для сокета назначается IP-адрес интерфейса tun(4). Ядро создаёт первый исходящий пакет и записывает его в устройство tun(4). Затем ppp(8) читает пакет и устанавливает соединение. Если в результате согласования ppp(8) динамического IP-адреса адрес интерфейса изменится, сокет будет работать некорректно. Любые IP-пакеты, передаваемые через сокет, будут отброшены. Если даже этого не произойдёт, ответные данные не будут достигать отправителя, так как этот адрес больше ему не принадлежит.

Теоретически есть несколько способов решить эту проблему. Лучше всего, если противоположная сторона назначит интерфейсу тот же самый IP-адрес. Текущая версия ppp(8) именно так и поступает, но большинство других реализаций этого не делают.

Самым простым решением будет просто никогда не менять IP-адрес интерфейса tun(4), а вместо этого изменять на лету все исходящие пакеты так, чтобы IP-адрес источника менялся с IP-адреса интерфейса на соответствующий с противоположной стороны. Это, в сущности, то же самое, что делает опция iface-alias в самой последней версии ppp(8) (с помощью библиотеки libalias(3) и ключа -nat для ppp(8)) - она отслеживает все назначенные ранее интерфейсу адреса и замещает их на последний из назначенных.

Другой возможный (и, наверное, самый надёжный) способ - это создать системный вызов, меняющий IP-адреса всем уже связанным сокетам. ppp(8) использовал бы этот вызов для модификации сокетов всех работающих программ после согласования нового IP-адреса. Этот же самый системный вызов могли бы использовать клиенты DHCP, когда они осуществляют повторную привязку к сокету, вызывая для этого функцию bind().

Ещё одной возможностью является разрешение интерфейсу становиться активным без IP-адреса. Исходящим пакетам будет даваться IP адрес 255.255.255.255 до первого вызова ioctl(2) SIOCAIFADDR, приводящего к полной привязке сокета. ppp(8) нужно будет изменять исходящий IP-адрес и контрольную сумму пакета, только если он установлен в 255.255.255.255. Это, однако, является некоторым хаком, так как ядро будет посылать некорректные пакеты на не полностью сконфигурированный интерфейс, в предположении, что существует механизм исправления этих пакетов.

FCS является сокращением от Frame Check Sequence (контроль последовательности кадров). Каждый кадр PPP имеет контрольную сумму для проверки того, что принятые данные совпадают с переданными. Если FCS принятого пакета некорректна, пакет отбрасывается и счётчик FCS для HDLC увеличивается. Значения ошибок уровня HDLC можно вывести командой show hdlc.

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

Если связь замирает сразу при установлении соединения и наблюдается большое количество ошибок FCS, убедитесь, чтобы модем не использовал программное управление потоком (XON/XOFF). Если же для соединения должно использоваться программное управление потоком, то воспользуйтесь командой set accmap 0x000a0000 для указания ppp(8) экранировать символы ^Q и ^S.

Другой причиной слишком большого количества ошибок FCS может быть прекращение противоположной стороной сеанса PPP. В этом случае включите протоколирование async для проверки того, не являются ли поступаемые из линии данные на самом деле приглашением login или shell. Если с противоположной стороны находится приглашение shell, завершить ppp(8) без обрыва связи можно командой close lcp и последующей командой term, чтобы переподключиться к приглашению shell на удалённой машине.

Если ничего в файле протокола не говорит о причине разрыва связи, спросите у администратора удалённой машины или вашего провайдера, почему сеанс был закрыт.

Если всё уже перепробовано, и ничего не получается, пошлите подробности об ошибке, конфигурационные файлы, способ запуска ppp(8), соответствующие части файла протокола, и вывод команды netstat -rn до и после соединения в Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD.