FAQ FreeBSD
Страница 52. Сеть и протоколы. Часть 3

10.13. Согласование LCP продолжается, пока не закроется соединение

В настоящий момент одной из неприятных особенностей реализации ppp является то,
что она не связывает сообщения 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

С этой командой нужно быть осторожным. Вы также должны будете использовать
команду
    set stopped N

для ограничения периода ожидания, в течении которого ppp ждёт начала согласов
ания с противоположной стороны. Как вариант, может быть использована строка
    set openmode active N

(где N - период ожидания в секундах перед тем, как начать согласование).

10.14. Вскоре после соединения ppp блокируется

В версиях FreeBSD ранее 2.2.5, была возможна ситуация, когда связь выключалась
очень скоро после соединения из-за некорректной обработки запроса на согласов
ания сжатия данных ppp. Это случалось, когда обе стороны пытались установить
разные типы CCP (Compression Control Protocol). Эта проблема сейчас решена, но
если вы всё ещё используете старую версию ppp, проблема может быть обойдена с
помощью строки
    disable pred1

10.15. Когда я выполняю команду shell для тестирования соединения, ppp блокируется

Когда вы выполняете команду shell или !, ppp запускает оболочку (если были
заданы параметры, ppp их использует). Ppp будет ждать окончания выполнения
команды, прежде чем продолжить. Если вы попытаетесь воспользоваться связью ppp
после запуска команды, связь будет выглядеть заблокированной. Это происходит
из-за того, что ppp ждёт завершения выполнения запущенной команды.
Если вам необходимо выполнять подобные команды, используйте команду !bg. В этом
случае нужная команда будет выполняться в фоновом режиме, а ppp сможет
продолжить обслуживание канала связи.

10.16. Ppp, обслуживающее нуль-модем, никогда не закрывается

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

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

10.17. В режиме -auto ppp неожиданно начинает звонить

Если ppp начинает неожиданно звонить, вы должны определить причину и задать
фильтры dfilters для предотвращения подобных звонков.
Для выяснения причины такого поведения, используйте строку:
    set log +tcp/ip

Это включит протоколирование всего трафика через соединение. В следующий раз,
когда неожиданно будет установлено соединение, вы установите причину по в
ременным отметкам в файле протокола.
После этого вы можете запретить дозвонку при выясненных условиях. Как правило,
такие проблемы возникают из-за обращений к DNS. Для предотвращения обращений к
DNS и установления соединения (что не запретит ppp пропускать пакеты через уже
установленное соединение), используйте такую комбинацию:
    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 в его
конфигурационном файле. Обратитесь к разделу о настройке почты за подробным
описанием создания конфигурационного файла и что туда нужно поместить. Вам
может понадобиться добавить в файл .mc строку:
    define(`confDELIVERY_MODE', `d')dnl

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