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

10.8. Соединение часто рвётся в случайные промежутки времени

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

10.9. Удалённая система не отвечает

Здесь вы мало что можете сделать. Большинство провайдеров отказываются оказать
помощь, если вы используете ОС не от Microsoft. Вы можете добавить команду
enable lqr в ваш ppp.conf, что позволит ppp отследить ошибки в удалённой
системе и закрывать соединение, однако такое обнаружение достаточно медленно и
поэтому не так уж полезно. Вы можете также просто не сообщать своему пров
айдеру, что запускаете user-ppp....
Первым делом попробуйте отключить всю местную компрессию, указав в
конфигурационном файле следующее:
    disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
    deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Теперь попробуйте установить соединение ещё раз и удостовериться, что ситуация
не изменилась. Если качество соединения улучшилось или проблема оказалась
полностью решённой, выясните, настройка чего приводила к проблемам методом проб
и ошибок. Это даст вам дополнительную защиту, когда вы будете разговаривать с в
ашим провайдером (хотя при этом может обнаружиться, что вы работаете не с
продуктом Microsoft).
Перед тем, как звонить провайдеру, включите вывод отладочной информации, как вы
это делали ранее и подождите, пока соединение снова не прервётся. Правда, для
этого требуется некоторое дисковое пространство. Интерес могут представлять
последние прочитанные из порта данные. Обычно это данные в формате ascii и они
могут даже содержать описание проблемы ("Memory fault, core dumped" ?).
Если ваш провайдер согласен помочь вам, нужно будет включить режим отладки с их
стороны, а потом, когда связь прервётся в следующий раз, они могут сказать вам,
почему возникли проблемы с их стороны. Будет хорошо, если вы пришлёте детальное
описание на адрес Brian Somers < Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script >, или даже попросите пров
айдера связаться со мной напрямую.

10.10. Ppp зависает

Лучше всего в этом случае перекомпилировать ppp, добавив параметры CFLAGS+=-g и
STRIP= в конец Makefile, а затем выполнить команду make clean && make && make
install. Когда ppp зависнет, найдите идентификатор процесса ppp с помощью
команды ps ajxww | fgrep ppp и выполните команду gdb ppp PID. Затем в
приглашении gdb вы можете использовать команду bt для получения стека вызовов.
Пошлите результат на адрес < Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script >.

10.11. Ничего не происходит после сообщения Login OK!

До версии FreeBSD 2.2.5, как только связь устанавливалась, ppp ожидал начала
согласования Line Control Protocol (LCP) с противоположной стороны. Многие пров
айдеры Internet не начинают согласования и предполагают, что это сделает
клиент. Чтобы заставить ppp инициировать согласование параметров LCP,
используйте следующую строку:
    set openmode active

Замечание: Ничего страшного не произойдёт, если согласование начнут обе
стороны, поэтому режим инициирования сейчас по умолчанию активный. Однако, в
следующем разделе описывается ситуация, когда это приводит к некоторым
неприятностям.

10.12. В протоколе есть сообщения о том, что "magic being the same".

Иногда, сразу же после установления соединения, вы можете увидеть сообщения в
протоколе, говорящие что "magic is the same". Иногда эти сообщения проходят
безболезненно, а иногда одна из сторон прекращает работу. Большинство
реализаций ppp не может справиться с такой ситуацией, и, даже когда связь в
ыглядит установившейся, вы будете видеть только бесконечно повторяющиеся
конфигурационные запросы и подтверждения в файле протокола до тех пор, пока ppp
окончательно не закроет соединение.
Обычно это происходит на серверах с медленными дисками, на которых порт обслужи
вает программа getty, а ppp выполняется из сценария регистрации или другой
программы после регистрации пользователя. Были сообщения, что такое случается
постоянно при использовании slirp. Причина заключается в том, что во время,
проходящее между завершением работы getty и запуском ppp, ppp со стороны
клиента начинает посылать пакеты Line Control Protocol (LCP). Так как режим эха
остаётся всё ещё включенным, ppp клиента получает "отражения" своих запросов.
Частью процесса согласования параметров LCP является определение "магического"
числа для каждой стороны соединения для обнаружения "отражений". Согласно
спецификации, когда одна сторона пытается использовать совпадающее "магическое"
число, должен быть послан ответ NAK и должно быть выбрано новое "магическое"
число. В тот момент, когда на порту сервера включен режим эха, клиент ppp
посылает пакеты LCP, получает то же самое "магическое" число в отражённом
пакете и отвечает на него NAK. Он также видит отражённый NAK (который также
означает, что ppp должен изменить своё "магическое" число). В потенциале это
может вызвать появление огромного количества процессов смен "магических" чисел,
и все они накапливаются в буфере терминала. Как только запустится сервер ppp,
он будет перегружен запросами на смену "магических", немедленно решит, что
этого много для согласования LCP и прервёт соединение. В то же самое время,
клиент, который больше не видит отражений, останавливается для того, чтобы ув
идеть, что сервер закрыл соединеие.
Этого можно избежать, позволив начинать согласование противоположной стороне
следующей строкой в файле ppp.conf:
    set openmode passive

Это заставит ppp ожидать начала согласования LCP. Некоторые серверы, однако,
могут никогда не начать согласование. Если это тот самый случай, вы можете
сделать следующее:
    set openmode active 3

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