Важный шаг в стадию конфигурации связи PPP клиентского разрешения.
Хотя это не обязательно, это действительно должно было бы быть для dial-
up линий. Обычно, вызываемый хост просит клиента зарегестрировать
себя, доказывая, что он знает некоторый секретный ключ. Если клиент
набрал неправильный ключ, то связь будет прервана. С PPP, разрешение
работает обеими способами; то есть вызывающий может также просить,
чтобы сервер опознал себя. Эти процедуры установления подлиности не
зависят друг от друга. Имеются два протокола для различных типов
разрешения, которые мы обсудим позже. Они именованы "Протоколом
Установления Подлинности Пароля", или PAP(Password Authentication
Protocol ), или CHAP(Challenge Handshake Authentication Protocol).

Каждый сетевой протокол, который разбит поперек канала связи, 
пожобно IP, AppleTalk, и т.д, сконфигурирован динамически, используя
соответствующую Network Control Protocol (NCP). Например, чтобы послать
IP датаграммы поперек

1. Релевантные RFCs перечислены в Annoted Bibiliography в конце
этой книги.
2. Фактически, HDLC- намного более общий протокол,
изобретенный Международной организацией по стандартизации



связи, оба PPPs должны сначала обсудить, который из IP адресов
каждый из них использует. Протокол управления, используемый для
этого - IPCP, the Internet Protocol Control Protocol.

Помимо посылки стандарта IP датаграммы поперек связи, PPP
также поддерживает Van Jacobson header compression IP датаграмм. Это -
метод для того, чтобы сократить заголовки TCP блоков к всего трем байтам.
Это также используется в CSLIP, и - больше относится к VJ header
compression. Использование сжатия может быть заключено в лимите времени
запуска через IPCP.

9.2 PPP на Linux

- 142 -


На Linux, PPP функциональные возможности расщеплены на две части,
low-level HDLC драйвер, который размещен в ядре, и пространство
пользователя pppd daemon, которое обрабатывает различные протоколы
управления. Текущее разъединение PPP для Linux - linux-ppp-1.0.0, которое
содержит ядро PPP модуля, pppd, и программа, именованная chat
используется для того, чтобы выполнить отдаленную связь.

PPP kernel драйвер был написан Michael Callahan. Pppd был
выведен из PPP реализации для Sun и 386BSD машин, который был написан
Drew Perkins и другими, и поддерживается Paul Mackerras. Это было
предоставлено к Linux Al Longyear. (3) chat был написан Karl Fox.(4)

Точно так же как и SLIP, PPP выполнен посредством специальной
line discipline. Для того, чтобы использовать последовательную линию как
PPP связь, Вы сначала должпы уутановить связь над вашим модемом как
обычно, и впоследствии преобразовать линию к PPP режиму. В этом методе,
все входящие данные проходят через PPP драйвер, который проверяет
входящие HDLC структуры для соответствия (каждая HDLC структура
несет 16 битов контрольной суммы). В настоящее время, он способен к
выбору, используя Van Jacobson header compression. Как только Linux
поддерживает IPX, PPP драйвер будет расширен для того, чтобы обрабатывать
IPX блоки.

Kernel драйверу помогает pppd, PPP daemon, который выполняет
целую инициализацию и опознавательный период, который является необходимым
перед тем, как фактическое сетевое движение может быть послано поперек
связи. Поведение Pppd может подстраиваться, используя ряд опций. PPP -
комплексный, невозможно описать все из них в единственной главе.

3. Оба автора сказали, что они будут очень заняты некоторое время для
того, чтобы вернуться. Если Вы имеете какие-либо вопросы относительно PPP
в общем, то Вам лучше всего спросить бы людей относительно NET
канала Linux activists mailing list..
4. Karl@morningstar.com.




- 143 -

Эта книга, однако, не может покрывать все аспекты pppd, но
даст Вам полное введение. Для более подробной информации, обратитесь к
страницам инструкции и файлам README на pppd исходном распространении,
которое должно помочь Вам отсортировать большинство вопросов, эта глава
объясняет как это сделать. Если у Вас остаются проблемы даже после
чтения всей документации, то Вы должны обратиться к newsgroup
сomp.protocols.ppp для справки, которая является местом где Вы узнаете
многое о pppd.

9.3 Запуск pppd

Когда Вы хотите соединитьcя с Internet через PPP связь, Вы
должны
установить базисные возможности работы с сетями типа возврата
цикла, и решающего устройства. Оба были описаны в предыдчщих"
главах. Имеются некоторые вещи, которые нужно упоминать относительно
использования DNS над последовательной связью; пожалуйста обратитесь к
SLIP главе для описания.

Как вводный пример того, как устанавливать PPP связь с pppd,
представте, что Вы - во vlager снова. Вы уже соеденились с сервером по
телефону, c3po, и зарегистрировались на ppp account. C3po уже
запустила свой PPP драйвер. После выхода из коммуникационных программ,
которые Вы используете для соединения по телефону, Вам необходимо выполнить
следующую команду:

# pppd /dev/cua3 38400 crtscts defaultroute

Это переместит последовательную линию cua3 к PPP режиму и
установит IP связь с c3po. Скорость передачи, используемая на
последовательном порте будет 38400bps. Опция crtscts включает аппаратное
рукопожатие на порт, который должен работать на скорости более чем 9600
бит\сек.

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

- 144 -

подробно несколько позже.

В настоящее время, мы также принимаем, что c3po не требует
какого-либо установление нашей подлинности, так что период
конфигурации завершен успешно.

Pppd будет договариваться о IP параметрах с peer используя
IPCP, IP управляет протоколом. Так как мы не точно определяли IP



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

Обычно, ничего не случается с этими значениями по умолчанию. Даже
если Ваша машина находится в Ethernet, Вы можете использовать тот же самый
IP адрес для обоих. и для Ethernet, и для PPP interface. Но тем не
менее, pppd позволяет Вам использовать различные адреса, или даже
спрашивать Вашего peer для того, чтобы использовать некоторый
специфический адрес. Эти опции обсуждены далее.

После прохождения IPCP периода установки, pppd подготовит Ваш
host's networking layer для того, чтобы использовать PPP связь. Сначала
будет сконфигурированн PPP сетевой interface как point-to-point связь,
используя ppp0 для первой PPP cвязи, которая является активной, ppp1 для
второй, и так далее. Затем, он установит маршрутную таблицу, которая
указывает на хост в другом конце связи. В примере, показанном выше,
pppd сделает заданный по умолчанию сетевой маршрут к c3 опциии
defaultroute. (5) Он азаставляет все датаграммы к хостам не на
вашей локальной сети быть посланными к C3po. Имеется ряд различных
маршрутов, которые pppd поддерживает, которые мы обсудим позже в этой
главе.

9.4 Использование файлов опций

Прежде чем pppd проанализирует аргументы командной строки, он
просмотрит несколько файлов для опций, заданных по умолчанию. Эти

- 145 -

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

Первый файл опций - /etc/ppp/options, который всегда просматривается
тогда, когда запускается pppd. При использовании этого для установки
некоторых глобальных значений по умолчанию - хорошая идея, потому что это
позволит Вам сохранить пользователей от выполнения нескольких вещей,
которые могут поставить под угрозу защиту. Например, чтобы pppd запросил
некоторый вид установления подлинности (или PAP или CHAP) от peer, Вы бы
добавили опцию auth к этому файлу. Эта опция необходима для того,
чтобы стало невозможно установить PPP связь с любой системой, которая
не в наших опозназательных базах данных.

Другой файл опций, который читается после /etc/ppp/options -
рpprc в исходном каталоге пользователя. Он позволяет каждому
пользователю точно определить ее собственное множество опций по умолчанию.

Типовой файл /etc/ppp/options мог бы выглядеть следующим образом:

5. Заданный по умолчанию сетевой маршрут может быть только
установлен, если ни один из них не установлен.



# Global options for pppd running on vlager.vbrew.com
auth # require authentication
usehostname # use local hostname for CHAP
lock # use UUCP-style device locking
domain vbrew.com # our domain name

Первыя две из этих опций обращаются к установлению подлинности и
будут объяснены ниже. Ключевое слово блокировки заставит pppd уступить
стандарту UUCP метод блокировки устройства. С этим собранием, каждый
процесс, который обращается к последовательному устройству, скажем
/dev/cua3, создает файл блокировки, названный LCK.. cua3 в UUCP катологе,
чтобы сообщить, что это устройство находится в использовании. Необходимо
предотвратить любые другие программы типа minicom или uuci локального

- 146 -

устройства в то время как используется PPP.

Причина в обеспечении этой опцией в глобальном конфигурационном
файле - то, что опции типа тех, что были показанны выше не могут быть
отменены, и они обеспечивают приемлемый уровень защиты. Заметьте
однако, что некоторые опции могут быть отменены позже; один такой пример
-соединить строку.

9.5 Набор номера с chat

Одна из вещей, которая может испугать Вас как неудобная в
вышеизложенным примере - то, что Вы должны установить связь вручную прежде,
чем Вы могли бы запустить pppd. В отличие от dip, pppd не имеет
собственный script язык для набора незначительной системы и регистрации,
но полагается на некоторую внешнюю программу или shell script для того,
чтобы сделать это. Команда, которая будет выполнена может быть дана
pppd с connect командой line option. Pppd переназначит вход и выход
к последовательной линии. Одна полезная программа для этого - expect,
написанная Don Libes. Она имеет очень мощный язык основанный на Tcl, и
была разработана точно для этого сорта приложения.

Pppd пакет идет с подобной программой называемой called chat,
которая позволяет Вам определить UUCP-style chat script. В основном, chat
script состоит из чередующихся последовательности строк, которые мы
ожидаем получить от отдаленной системы, и ответов, которые мы должны
послать. Мы будем называть expect и send строки, соответственно. Это
типичная выборка из chat script;

ogin: b1ff ssword: s3kr3t



Он сообщает chat чтобы ждать отает из отдаленной системы для того,
чтобы послать login prompt, и вернуть login имя b1ff. Мы только ждем ogin:
так чтобы было все равно стартует ли login prompt с верхнего регистра или с
нижнего регистра I, или приходит искаженным. Следующяя строка - expect
string снова, которая заставит chat ждать пароль, и посылать свой пароль в
ответ.

- 147 -


Вот это в основном и все то, для чего предназначен chat scripts.
Полный script для соединения с PPP сервером, несомненно должен
включать соотствующие команды модема. Представте, что ваш модем
понимает Hayes команды, и номер телефона сервера был 318714. Полный
вызов chat для установки связи с c3po был бы:

$ chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN

По определению, первая строка должна бы быть expect строкой, но так
как модем не будет говорить что - нибудь прежде, чем мы пнули его, мы
сделаем chat так, чтобы он сначала ожидал, опрзделкв пустую строку. Мы
продолжаем и посылаем ATZ, reset команда для Hayes-совместимых модемов, и
ждем реакцию (OK). Следующая строка посылает dial команду с номером
телефона для chat, и ожидает сообщение CONNECT в ответ. За этим следует
пустая строка снова, потому что мы не хотим посылать, но лучше подождать
для быстрого входа в систему. Остаток от chat script работает точно так,
как описано выше.

Опция -v делает caht log all activities к syslog daemon's local2
facility. (6)

Определение chat script на командной строке несет оправданный риск,
потому что пользователи могут просматривать командную строку
процессов с использованием ps команды. Вы можете избежать этого, помещая
chat script в файл, скажем dial-c3po. Вы можете заставить chat прочесть
script из файла вместо командной строки, давая ему опцию -f,
сопровождаемой именем файла. Завершением колдовства над pppd теперь
выглядело бы следующим образом:

# pppd connect "chat -f dial-c3po" /dev/cua3 38400 -detach \
crtscts modem defaultroute

6. Если Вы редактируете syslog.conf так, чтобы переназначить
эти log сообщения к файлу, удостоверитесь, что этот файл не всемирно
читаемый, так как chat также регестрирует введенный chat script по
умолчанию - включая пароли и все.


- 148 -



Помимо соединяющейся опции, которая определяет dial-up script, мы
добавили еще две опции к командной строке: - detach, которая сообщает
рppd не отделяться от консоли и стать процессом предпосылки. Ключевое
слово модема заставит его выполнить некоторые модем-определенные
действия на последовательном устройстве, подобно "повесить трубку"
прежде и после вызова. Если Вы не используете это ключевое слово, pppd не
будет определять DCD линию, и будет не обнаруженна неожиданно.

Примеры, показанные выше были довольно просты; chct позволяет
учитывать намного более комплексные chat script. Одна очень полезная
особенность - способность к точному определению строки на которой можно
прервать chat с ошибкой. Типичные аварийные строки - BUSY, или NO
CARRIER, которые ваш модем обычно генерирует, когда вызываемый номер
занят, или не поднимают трубку. Для того, чтобы сделать chat
распознающим их немедленно, скорее быстрее чем выйдет время, Вы можете
определить начало script, используя ключевое слово ABORT.

$ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ...

В подобном режиме, Вы можете изменить значение блокировки по
времени для частей chat scripts, вставляя TIME OUT опции. Для
деталей, пожалуйста обратитесь к chat(8) справочника.

Иногда, вы может быть захотели бы иметь некоторый вид условного
извлечения частей chat script. Например, когда Вы не получаете
отдаленный end'slogin prompt, возможно Вы можете захотеть послать BREAK,
или возврат каретки. Вы можете достичь этого, присоединяя sub-script к
expect строке. Она состоит из последовательности send- и expect- строк,
точно таких же как и полный script непосредственно, который отделен
дефисами. Sub-script выполняется всякий раз, когда expected строка когда
не было ничего получено. В примере изложенном выше, мы модифицировали бы
chat script следующим образом:

ogin:-BREAK-ogin: ppp ssword: GaGariN

Теперь, когда chat не видит, что отдаленная система посылает

- 149 -

быстрый вход в систему, sub-script выполняется сначала посылая BREAK, и
затем ожидает для входа в систему снова. Если prompt теперь появится,
то script будет продолжаться как обычно, иначе это прервется с ошибкой.



9.6 Отладка вашей PPP установки

По умолчанию, pppd регестрирует любые предупреждения и сообщения
об ошибках к syslog's daemon facility. Вы должны добавить записю "
в syslog.conf, которая переназначит его к файлу, или даже к консоли,
иначе syslog просто отбросит эти сообщения. Следующая запись
посылает все сообщения к /var/log/ppp-log:

daemon.* /var/log/ppp-log

Если ваша PPP установка не работает, при просмотре этого log файла,
то он должен дать Вам подсказку, что что-то идет неправильно. Если это не
помогает, то Вы можете включить особо отлаживающийся вывод, используя
опцию отладки. Это делает pppd log с содержанием из всех управляющих
блоков, посланных или полученных к syslog. Все сообщения будут идти к
daemon facility.

В заключение, наиболее решительная особенность - отключение
kernel-level отладки, вызывая pppd с опцией kdebug. Она
сопровождается числовым аргументом, который является поразрядным ИЛИ
следующих значений: 1 для общих сообщении отладки, 2 для печати
содержания всей входящей HDLC структуры, и 4 для того, чтобы сделать
драйвер принтера выходящим на HDLC структуру. Для того, чтобы захватить
kernel отлаживающее сообщения, Вы должны также запустить syslogd daemon,
кот или klogd daemon. Каждый из них направляет kernel отладку к syslog's
kernel facility.

9.7 IP опции конфигурации

IРCP используется для того, чтобы обговорить пару IP
параметров в конфигурационной связи. Обычно, каждый peer может
посылать IPCP запрос конфигурации, указывая, которая переменная хочет

- 150 -

измениться из значений заданных по умолчанию, и к какому значению.
После получения, отдаленный end осматривает каждую опцию, и подтверждает
или отклоняет ее.

Pppd дает Вам множество управления, относительно IPCP опций, которые
будут пытаться вести переговоры. Вы можете настроить ее через различные
опции командных строк, которые мы обсудим ниже.



9.7.1 Выбор IP адресов

В примере выше, у нау был pppd, связывающейся с c3po и
устанавливающий IP связь. Никакие условия не принимались для того, чтобы
выбрать частный адрес IP на любом конце связи. Взамен, мы выбрали адрес
vlager's как локальный адрес IP, и позволяем c3po обеспечить себя
собственным. Иногда это полезно иметь контроль над тем , какой адрес
используется на одном или на другом конец связи. Pppd поддерживает
отдельные разновидности этого.

Чтобы просить о частных адресах, Вы вообще обеспечиваете pppd
следующеми
опциями:

local addr:remote addr

Где local addr и remote addr могут быть определены или в dotted
quad notation, или как hostnames.(7) Это заставит pppd попытаться
использовать первый адрес как собственный адрес IP, и второй как
peer. Если peer отклоняет любой из них в течение IPCP переговоров,
никакая связь IP не будет установленна. (8)

Если Вы хотите установить локальный адрес, но принимаете любой
адрес, который использует peer, Вы просто не учитываете remote addr
part. Например, для того, чтобы vlager использовал IP адрес 130.83.4.27
вместо собственного, Вы бы дали ему 130.83.4.27: на командной строке.
Подобно установки remote адресов только, Вы покинули бы локальную
область адреса.

- 151 -

Используя значение по умолчанию, pppd затем использует адрес,
связанный с вашим hostname.

Некоторые PPP серверы, которые обрабатывают множество клиентов,
приписывают адреса динамически: адреса назначены системам только когда
существует обращение и требуются после того, как они прекратили
регистрироваться снова. Когда происходит соединение с таким
сервером, Вы должны удостовериться, что pppd не запрашивает какой-
либо IP адрес из сервера, но когда адрес будет принят сервер попросит Вас,
чтобы Вы его использовали. Это означает то, что Вы не должны определить
того, Вы должны использовать опцию noipdefault, которая заставит pppd
ждатю pegr, чтобы обеспечить адрес IP вместо использования адреса
локального хоста.

7. Использование hostnames в этой опции имеет следствия на
CHAP установления подлинности. Пожалуйста обратитесь к разделу на CHAP.
8. Вы можете позволить peer PPP отменить ваши идеи относительно IP
адресов, давая pppd ipcp-accept-local и ipcp-accept-remote опции.
Пожалуйста обратитесь к руководству для выяснения деталей.



9.7.2 Направление через связь PPP

После установки сетевого interface, pppd будет устанавливать хост
маршрут только к своему peer. Если remote хост находится на LAN, Вы
обязательно захотите быть способным соединится с хостами множествами
"позади" Вашего peer; то есть сетевой маршрут должен быть установлен.

Мы уже видели, что pppd можно попросить уствновить заданный по
умолчанию маршрут, используяю опцию defaultroute. Эта опция очень полезна
если PPP сервер, с которым Вы связались будет действовать как ваши
Internet ворота.

Обратный случай, где ваша система действует как ворота для
единственного хоста, является также относительно простым для того, чтобы
быть выполненым. Например, возьмите некоторых служащих в Virtual
Brewery, чья локальная машина называется loner. При соединении с vlager

- 152 -

через PPP, он использует адрес на подсети Brewery. В vlager, мы можем
теперь дать pppd опцию proxyarp, которая установит полномочную ARP
запись для loner. Это автоматически сделает loner доступным для всех
и в Winery.

Однако, вещи далеко не всегда просты как это иногда кажется, например
когда Вы соединяете две LAN. Это обычно требует добавления специального
сетевого маршрута, потому что эти сети могут иметь свой маршрут
заданный по умолчанию. Кроме того, имея обоих peer использование связи PPP
как маршрут заданный по умолчанию генерировало бы цикл, где блоки к
некзвеутным адресатам будут пинаться между peer пока их time-to-live
истечет.

Как пример, предположите, что Virtual Brewery открывает
ветвь в каком-нибудь другом городе. Подразделение запускает
собственную Ethernet используя IP сетевой номер 191.72.3.0, который
является подсетью 3 из Brewery класса B сети. Они хотят соединиться с
Brewery's main Ethernet via PPP для тго, чтобы модифицировать базы данных
заказчиков, и т.д. Снова, vlager действует как ворота; peer вызывается
sub-etha и имеет адрес IP 191.72.3.1..

Когда sub-etha соединится с vlager, она примет заданный по
умолчанию маршрут к vlager как обычный. На vlager, мы будем должны
установить сетевой маршрут для подсети 3, который проходит к sub-etha. Для
этого, мы используем особенность pppd, не обсужденного пока - ip-в
готовности команды. Это shell script или программа, размещенная в
/etc/ppp, которая выполнена после того, как PPP interface был
сконфигурирован. Когда он существует, это вызывается со следующими пар



ip-up iface device speed local addr remote addr

Где iface называет сетевой interface используемым, device - тропа
файла последовательного устройства используемого (/dev/tty, если
stdin/stdout используется), и speed - быстродействие устройства. Local
addr и remote addr дают IP адреса, используемые в обоих концах связи
в dotted quad notation. В нашем случае, ip-up script, может содержать

- 153 -

следующий кодовый фрагмент:

#!/bin/sh
case $5 in
191.72.3.1) # this is sub-etha
route add -net 191.72.3.0 gw 191.72.3.1;;
esac
exit 0

В подобном режиме, /etc/ppp/ip-down используется для того, чтобы
отменить все действия ip-up после того, как связь PPP была демонтирована
снова.

Однако, схемж матшрутов еще не полна. Мы установили маршрут входов
таблицы на оба PPP хоста, но пока, все другие хосты на обих сетях не знают
ничего относительно связи PPP. Это не большая проблема, если все
хосты в подразделении имеют свои, заданные по умолчанию маршруты в sub-
etha, и все хосты в Brewery направляются к vlager по умолчанию. Если это
не так, то ваша единственная опция будет использовать daemon маршрут
подобно воротам. После создания сетевого маршрута передал бы по радио
новый маршрут ко всем хостам на присоединенной подсети.

9.8 Опции управления связью

Выше, мы уже столкнулись с LCP, Протоколом Управления Связи,
который используется для того, чтобы заключить характеристики связи, и
проверить связь.

Две наиболее важных опции, которые могут быть заключены LCP -
максимум получает единицу и Асинхронное Отображение Управляющего символа.
Имеется ряд других LCP опций конфигурации, но они слишком
специализированны для обсуждения их здесь. Пожалуйста обратитесь к RFC
1548 для описания этого.



Асинхронное отображение управляющего символа, разговорно
называемого async отображение, используется на асинхронных связях типа

- 154 -

телефонных линий для опознавания управляющих символов, которых
нужно найти (заменить специфической последовательностью с двумя
характерами). Например, Вы может быть захотите избежать XON и XOFF,
используемые для рукопожатия программного обеспечения, потому что
некоторый плохо сконфигурированный модем мог бы удушить получения стоп-
сигнала. Ctrl-] (telnet символ ESC). PPP позволяет Вам выходить из любого
из знака с ASCII кодировкой от 0 до 31, точно определяя их в аsync
отображении.

Async отображение - растр шириной 32 бита, с самым младшим
битом, соответствующим ASCII NUL знаку, и старшим битом соответствующим 31
ASCII. Если бит установлен, то оп сообщает соответствующему знаку, который
должен выйти перед посылкой через связь. Первоначально, async
отображение - множество к 0xffffffff, то есть все управляющие символы
будут esaped.

Для того, чтобы сообщить вашему peer, что это он не должен
escaped все управляющие символы, а только несколько из них, Вы можете
точно определять новый asyncmap к pppd используя опцию asyncmap. Например,
если только ^S и ^Q (ASCII 17 и 19, обычно используемый для
старт-сигнала(XON) и стоп-сигнала(XOFF)) должно быть escaped, то Вам
надо использовать следующую опцию:

Asyncmap 0x000A0000

Максимум получает единицу, или MRU, сообщает peer максимальный размер
HDLC рамки, которую мы хотим получить. Хотя это может напомнить Вам
значение MTU (Максимальная Порция обмена), то эти два имеет немного
общего. MTU - параметр kernel устройства работы с сетями, и
описывает максимальную структуру inerface делая его способным к обработке.
MRU более, чем совета к remote end для того, чтобы не генерировать любой
фрейм больший чем MRU; interface должен однако быть способен 1500 байт.

Выбор MRU не такой большой вопрос того что как связь способна к
пересылке, но того, что даст Вам самый лучший throughput. Если Вы
имеете в виду интерактивные приложения над связью, то установки MRU к
значениям всего 296 - хорошая идея, так, чтобы случайный больший блок
(говорят, из FTP сеанса) не сделал бы ваш курсор "jump''. Чтобы сообщить

- 155 -

pppd чтобы он запросил MRU 296, Вы бы дали ему опцию mru 296. Малый
MRUs, однако, только имеет смысл, если Вы не имеете эту опцию (это
отключается по умолчанию).



Pppd понимает также пару LCP опций, которые конфигурируют полное
поведение процесса переговоров, типа максимального номера из запросов
конфигурации, которые могут быть обменены перед тем как связь будет
прервана.
&
" В заключение, имеются две опции, которые обращаются к LCP ECHO
сообщениям. PPP определяет эти два сообщения, запрос ECHO и ответ ECHO.
Pppd использует эту особенность, чтобы проверить, действует ли связь все
еще. Вы можете отключить это используя опцию lcp-echo-interval
вместе со временем мгновенно. Если никакие структуры не получены от
отдаленного хоста внутри этого интервала, то pppd сгенерирует запрос ECHO,