Секция 8 из 10 - Предыдущая - Следующая
Все секции - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10

следующие возможности:

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 <brian@FreeBSD.org>, или даже попросите пров
айдера связаться со мной напрямую.

10.10. Ppp зависает

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

Пошлите результат на адрес <brian@Awfulhak.org>.

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
немедленно ответит, не ожидая истечения трёхсекундного интервала.

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).

10.18. Что означают ошибки CCP

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

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


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

    disable pred1


10.19. Ppp блокируется во время передачи файла с ошибками ввода-вывода

В FreeBSD 2.2.2 и ранее существовала ошибка в драйвере устройства tun, которая
не позволяла проходить пакетам размером, превышающим значение MTU интерфейса.
Приём пакета, большего, чем размер MTU, приводит к ошибке ввода-вывода, который
протоколируется через syslogd.

Спецификация протокола ppp утверждает, что MRU, равное 1500, должно всегда
подходить как минимальное, несмотря на согласование LCP, таким образом, если
сделать MTU меньше 1500, ваш провайдер может начать передавать пакеты размером
1500, несмотря ни на что, и вы это почувствуете - ваше соединение
заблокируется.

Проблема может быть обойдена, если никогда не ставить MTU, меньшее, чем 1500,
для FreeBSD 2.2.2 и ранее.

10.20. Почему ppp не протоколирует скорость соединения?

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

    set log +connect


Это заставит ppp протоколировать всё, вплоть до последней прочтённой через
"expect" строки.

Если вы хотите видеть скорость соединения и используете PAP или CHAP (и поэтому
вам не нужно определять никаких сценариев входа через set login после получения
строки CONNECT сценарием дозвонки dial), вы должны указать ppp, что нужно
ожидать полную строку CONNECT, вроде следующего:

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


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

10.21. Ppp игнорирует символ \ в chat-скрипте

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


10.22. Ppp получает ошибку защиты, но я не вижу файла ppp.core

Ppp (или любая другая программа такого рода) никогда не создаёт файлов дампа
памяти. Так так ppp запускается с эффективным uid, равным 0, то операционная
система не будет записывать дамп памяти ppp на диск перед его завершением.
Если, однако ppp всё же прекратит работу из-за нарушения защиты, или по другому
сигналу, который вызывает создание дампа памяти, и вы уверены, что используете
самую последнюю версию (смотрите самое начало раздела), то вы должны сделать
следующее:

    % tar xfz ppp-*.src.tar.gz
    % cd ppp*/ppp
    % echo STRIP= >>Makefile
    % echo CFLAGS+=-g >>Makefile
    % make clean all
    % su
    # make install
    # chmod 555 /usr/sbin/ppp


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

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

    % su
    # gdb /usr/sbin/ppp ppp.core
    (gdb) bt
    .....
    (gdb) f 0
    ....
    (gdb) i args
    ....
    (gdb) l
    .....


Вся эта информация должна быть предоставлена вместе с вашим вопросом, чтобы
проблему можно было продиагностировать.

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

10.23. Процесс, вызвавший прозвонку в режиме auto, никогда не получает затребов
анного соединения

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

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

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

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

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

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

10.24. Почему большинство игр не работает с опцией -nat?

Причиной, по которой игры и подобные программы не работают с библиотекой
libalias заключается в том, что внешняя машина будет пытаться открыть
соединение или посылать (нежданные) UDP пакеты на машину внутренней сети.
Программное обеспечение, обеспечивающее опцию -nat, не знает о том, что она
должна пересылать эти пакеты машине внутренней сети.

Чтобы это всё же заработало, удостоверьтесь, что единственной запущенной
программой является программное обеспечение, с которым вы испытываете проблемы,
затем напустите tcpdump на tun-интерфейс маршрутизатора либо включите
протоколирование tcp/ip в ppp (set log +tcp/ip) на маршрутизаторе.

Когда вы запустите некорректно работающее программное обеспечение, вы должны ув
идеть пакеты, проходящие через маршрутизатор. Когда что-то начнёт приходить изв
не, оно будет отброшено (в этом-то и проблема). Заметьте номер порта получателя
этих пакетов, затем завершите работу вашего программного обеспечения. Выполните
эту процедуру несколько раз для того, чтобы убедиться, что номер порта
постоянен. Если это так, то следующая строчка в соответствующем разделе /etc/
ppp/ppp.conf заставит программное обеспечение функционировать нормально:

    nat port proto internalmachine:port port


Здесь proto - это tcp либо udp, internalmachine - это машина, которой вы хотите
перенаправлять пакеты, и port - это номер порта получателя пакетов.

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

Если номера портов непостоянны, есть ещё три варианта:

1) Настройте поддержку этого в libalias. Примеры "особых случаев" можно найти в
/usr/src/lib/libalias/alias_*.c (alias_ftp.c - хорошее начало). Это означает,
что вам нужно будет использовать чтение некоторых распознаваемых исходящих
пакетов, обнаруживать команды для установления внешней машиной обратной связи
на внутреннюю машину на конкретный (случайный) порт и настраивать "маршрут" в
таблице соответствий так, чтобы последующие пакеты проходили нормально.

Это самое трудоёмкое решение, но оно наилучшее и позволит программному
обеспечению работать на нескольких машинах.

2) Используйте прокси-сервера. Приложение может поддерживать, например, socks5
или (как в случае "cvsup") может иметь режим "passive", обходящийся без запросо
в к противоположной стороне на открытие обратного соединения.

3) Переназначьте всё на внутреннюю машину с помощью команды nat addr. Это
решение в лоб.

10.25. Кто-нибудь ведёт список полезных номеров портов?

Пока нет, но ниже находится список, могущий таковым стать (если к этому будет
проявлен какой-либо интерес). В каждом примере internal нужно заменить на
IP-адрес машины, участвующей в игре.

  * Asheron's Call

    nat port udp internal:65000 65000

    Находясь в игре, вручную смените номер порта на 65000. Если у вас есть
    несколько машин, на которых вы хотите играть, назначьте каждой машине
    уникальный номер порта (то есть 65001, 65002 и так далее), и добавьте по
    строчке nat port для каждой машины.

  * Half Life

    nat port udp internal:27005 27015

  * PCAnywhere 8.0

    nat port udp internal:5632 5632

    nat port tcp internal:5631 5631

  * Quake

    nat port udp internal:6112 6112

    Альтернативное решение, обеспечивающее поддержку прокси для Quake, можно
    найти на сервере www.battle.net.

  * Quake 2

    nat port udp internal:27901 27910

  * Red Alert

    nat port udp internal:8675 8675

    nat port udp internal:5009 5009

10.26. Что такое ошибки FCS?

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

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

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

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

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

10.27. Почему при работе в MacOS и Windows 98 соединения замирают, когда на
маршрутизаторе используется PPPoE

Мы благодарим Майкла Возняка (Michael Wozniak) <mwozniak@netcom.ca>, который
сообщил следующую информацию, и Дэна Флемминга (Dan Flemming) <
danflemming@mac.com> за решение проблемы в случае Mac:

Это происходит из-за эффекта, который можно назвать "чёрной дырой" на
маршрутизаторе. MacOS и Windows 98 (и, может быть, другие операционные системы
от Microsoft), посылают пакеты TCP с запрашиваемым размером сегмента, который
слишком велик для того, чтобы быть помещённым в кадр PPPoE (для сети ethernet
размер MTU по умолчанию равен 1500) и с установленным битом "не фрагментиров
ать" (по умолчанию для TCP), а маршрутизаторы Telco не посылает пакет ICMP
"нужно фрагментировать" обратно на сайт www, с которым вы работаете. Когда
www-сервер посылает вам кадры, которые не помещаются в поток PPPoE, то
маршрутизаторы Telco их отбрасывают и странички не загружаются (часть страниц/
графики всё же видно, потому что они меньше, чем MSS). Похоже, что такие
настройки действуют по умолчанию на большинстве конфигураций PPPoE Telco (если
они вообще знают, как программировать маршрутизатор... да уж...).

Одним из способов исправить это является использование утилиты regedit на
машинах 96/98 для того, чтобы добавить в реестр следующий параметр...

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU


Это должна быть строка со значением "1450" (точнее, "1464", чтобы размещать
пакеты TCP точно по размеру кадра PPPoE, однако "1450" даёт вам некоторый запас
в случае других протоколов IP, которые вы можете использовать).

Обратитесь к MS KB # "Q158474 - Windows TCPIP Registry Entries" и "Q120642 -
TCPIP & NBT Configuration Parameters for Windows NT" для получения подробной
информации по изменению MTU в Windoze для работы с маршрутизатором FreeBSD/NAT/
PPPoE.

К несчастью, в MacOS нет возможности изменить настройки TCP/IP. Однако имеется
коммерческое программное обеспечение, такое, как OTAdvancedTuner (OT for
OpenTransport, the MacOS TCP/IP stack) компании Sustainable Softworks, которое
позволяет пользователям настраивать параметры TCP/IP. Пользователи MacOS NAT
должны выбрать ip_interface_MTU из выпадающего меню, ввести число 1450 вместо
1500 в окне, затем щёлкнуть на кнопке, следующей за Save as Auto Configure, и щ
ёлкнуть на Make Active.

10.28. Ничего не помогает - я уже отчаялся!

Если всё уже перепробовано, и ничего не получается, пошлите нам максимальное
количество информации, ваш конфигурационный файл, способ запуска ppp, соответст
вующие части файла протокола, и вывод команды netstat -rn (до и после
соединения) в адрес списка рассылки <freebsd-questions@FreeBSD.org> или в
телеконференцию comp.unix.bsd.freebsd.misc, и может быть, кто-нибудь укажет вам
верное направление.

-------------------------------------------------------------------------------

Chapter 11. Коммуникационные адаптеры

В этом разделе освещены вопросы о работе последовательных адаптеров во FreeBSD.
Протоколы PPP и SLIP рассматриваются в разделе, посвящённом Chapter 9.

11.1. Как узнать, какие последовательные порты были обнаружены FreeBSD?
11.2. Как узнать, какие внутренние модемы были обнаружены FreeBSD?
11.3. Я только что поставил 2.0.5 и не нашёл устройств tty0X!
11.4. Как осуществляется доступ к последовательным портам во FreeBSD?
11.5. Как включить поддержку многопортовых последовательных адаптеров?
11.6. Может ли FreeBSD использовать несколько многопортовых адаптеров с одинако
    вым irq?
11.7. Можно ли установить режим работы по умолчанию для порта?
11.8. Как сделать вход через модем?
11.9. Как подключить терминал к FreeBSD?
11.10. Почему не удаётся запустить tip или cu?
11.11. Мой модем Hayes не поддерживается---что можно сделать?
11.12. Как я должен ввести эти AT-команды?
11.13. Знак <@> для описания характеристики pn не работает!
11.14. Как набрать телефонный номер из командной строки?
11.15. Нужно ли при этом каждый раз задавать скорость работы с портом?
11.16. Мне нужно иметь доступ к нескольких хостам через терминальный сервер.
11.17. Может ли tip использовать несколько телефонов для одного сайта?
11.18. Почему нужно нажимать CTRL+P дважды для посылки одного этого символа?
11.19. Неожиданно всё стало набираться ЗАГЛАВНЫМИ БУКВАМИ?
11.20. Как можно передавать файлы с помощью программы tip?
11.21. Как использовать zmodem вместе с tip?
11.22. FreeBSD не распознаёт последовательные порты на моей машине, хотя все
    настройки верны.

11.1. Как узнать, какие последовательные порты были обнаружены FreeBSD?

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

    % dmesg | grep sio


после загрузки и запуска системы.

Вот пример вывода указанной команды:

    sio0 at 0x3f8-0x3ff irq 4 on isa
    sio0: type 16550A
    sio1 at 0x2f8-0x2ff irq 3 on isa
    sio1: type 16550A


Здесь присутствуют два последовательных порта. Первый использует irq 4, порт вв
ода/вывода 0x3f8 и построен на микросхеме UART типа 16550A. Второй использует
тот же тип микросхемы, но использует irq 3 и адрес порта ввода/вывода 0x2f8. В
нутренние модемы выглядят точно также, как последовательные порты, за
исключением того, что к модем ним "подключен" всегда.

В ядро GENERIC встроена поддержка двух последовательных портов, с irq и
адресами портов ввода/вывода, как в примере выше. Если эти настройки не соотв
етствуют вашим, или если вы добавили внутренние модемы, или у вас больше
последовательных портов, чем описано в ядре, просто переконфигурируйте ядро. За
дополнительной информацией обратитесь к разделу о построении ядра.

11.2. Как узнать, какие внутренние модемы были обнаружены FreeBSD?

Посмотрите ответ на предыдущий вопрос.

11.3. Я только что поставил 2.0.5 и не нашёл устройств tty0X!

Не волнуйтесь, просто они были объединены с устройствами ttydX. Вам придётся
подправить конфигурационные файлы, которые вы раньше использовали.

11.4. Как осуществляется доступ к последовательным портам во FreeBSD?

Третий последовательный порт, sio2 (который в DOS называется COM3), называется
/dev/cuaa2 для устройств, выполняющих исходящие звонки, и /dev/ttyd2 для
устройств, принимающих входящие звонки. Какая разница между этими двумя
классами устройств?

Вы должны использовать ttydX для входящих соединений. При открытии /dev/ttydX в
блокирующем режиме, процесс будет ожидать неактивности соответствующего
устройства cuaaX, а затем появления сигнала о наличии несущей. При открытии
устройства cuaaX, он проверяет, что последовательный порт не используется уже
устройством ttydX. Если порт доступен, он "похищает" его у устройства ttydX.
Также устройство cuaXX не следит за наличием несущей. С такой схемой работы и
модемом, находящимся в режиме автоответа, вы можете позволить пользователям в
ходить в систему и в то же время можете осуществлять исходящие звонки, а
система позаботится о возможных конфликтах.

11.5. Как включить поддержку многопортовых последовательных адаптеров?

Повторим ещё раз: информация о конфигурировании ядра содержится в разделе, посв
ящённом этому вопросу. Для многопортовых последовательных адаптеров в файле
конфигурации ядра поместите ключевое слово sio для каждого порта на адаптере.
Но irq и вектор должен быть указан только у одного порта. Все порты на адаптере
должны использовать одно и то же irq. Используйте последний последовательный
порт для указания irq. Также включите опцию COM_MULTIPORT.

В следующем примере дано описание 4-портового адаптер AST на irq 7:

    options "COM_MULTIPORT"
    device sio4 at isa? port 0x2a0 tty flags 0x781
    device sio5 at isa? port 0x2a8 tty flags 0x781
    device sio6 at isa? port 0x2b0 tty flags 0x781

Секция 8 из 10 - Предыдущая - Следующая

© faqs.org.ru