Отладка соединений РРР затруднена проблемами, возникающими на нескольких уровнях. Установка РРР требует настройки последовательного порта, модема, настройки РРР и TCP/IP. Ошибка на любом из уровней может приводить к проблемам на другом.
Любой из уровней может скрыть истинную причину проблемы. Лучший способ диагностирования проблем для последовательных линий - применять отладку на каждом из уровней по очереди. Обычно к настройке очередного уровня следует переходить после отладки предыдущего.
Физические последовательные порты должны настраиваться системой в процессе загрузки. Проверьте корректность настроек, обратившись к каталогу /dev. Для системы Linux с четырьмя последовательными портами должны существовать входящие последовательные порты с /dev/ttyS0 по /dev/ttyS3 и исходящие последовательные порты с /dev/cuaО по /dev/cua3. Имен устройств tty и сиа существует гораздо больше. Однако прочие устройства связаны с реально существующими только в случаях присутствия в системе многопортовой последовательной карты. В большинстве систем используются имена tty и сиа, даже если эти имена являются всего лишь символическими ссылками на реальные устройства. Например, в Solaris:
% ls -1 /dev/tty? lrwxrwxrwx 1 root root 6 Sep 23 2001 /dev/ttya -> term/a lrwxrwxrwx 1 root root 6 Sep 23 2001 /dev/ttyb -> term/b % ls -1 /dev/cua/* lrwxrwxrwx 1 root root 35 Sep 23 2001 /dev/cua/a -> /devices/obio/zseO,100000:a, cu lrwxrwxrwx 1 root root 35 Sep 23 2001 /dev/cua/b -> /devices/obio/zs®0,100000:b,cu
Если последовательные устройства не обнаружены в каталоге /dev, их можно добавить вручную при помощи команды mknod. Так, следующая команда создает последовательные устройства для первого последовательного порта системы Linux:
# mknod -m 666 /dev/cuaO c 5 64 # mknod -m 666 /dev/ttySO c 4 64
При добавлении последовательных устройств пользователем могут возникать проблемы с настройкой ядра. По умолчанию последовательные устройства должны устанавливаться системой при загрузке - в процессе обнаружения аппаратных устройств. Следующее загрузочное сообщение отражает обнаружение одного последовательного интерфейса в системе Linux:
$ dmesg | grep tty ttySOO at 0x03f8 (irq = 4) is a 16550
При загрузке системы должны наблюдаться аналогичные сообщения для всех обнаруженных интерфейсов. В противном случае возможно наличие аппаратных проблем, связанных с картой последовательного интерфейса.
Модем, позволяющий установить соединение, подключается к одному из последовательных портов. Прежде чем приступить к созданию сценария подключения, убедитесь, что модем работает и отзывается через последовательный порт. Воспользуйтесь простым коммуникационным пакетом, таким как minicom, kermit или seyon. Прежде всего, программу следует настроить на использование модема. Необходимо указать корректный порт, скорость, четность, число битов данных и т. д. Сверьтесь с документацией своего модема, чтобы определить эти значения.
Для создания примеров мы используем minicom и систему Linux. Чтобы настроить minicom, станьте суперпользователем при помощи команды su и выполните minicom с ключом -s, предписывающим вывод меню настройки. По необходимости измените значения параметров. Можно заметить, что значение порта в настройках - /dev/modem. Это имя устройства иногда является символической ссылкой на порт подключения модема. Если вы точно не знаете, существует ли такая ссылка в системе, введите в этом поле корректное имя устройства, например /dev/cual. Убедившись в точности настроек, покиньте меню и воспользуйтесь эмулятором терминала minicom, чтобы проверить работоспособность модема:
Welcome to minicom 1.83.1 OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n Compiled on Feb 23 2001, 07:31:40. Press CTRL-A 2 for help on special keys AT S7=45 S0=0 L1 V1 X4 &c1 E1 QO OK atz OK atdt555-1234 CONNECT 26400/LAPM-V Enter login> kristin Enter user password> Wats?Watt? Welcome to the PPP MODEM POOL P0RT-9> set port ppp enabled +++ OK ath OK atz OK ~A CTRL-A 2 for help | 57600 8N1 | NOR | Minicom 1.83.1 | VT102 | Offline X
В этом примере minicom выводит несколько строк заголовка, а затем посылает модему Науеэ-команду (AT). Мы ее не вводили, это часть стандартной настройки программы minicom. (Если выполнение команды вызывает проблемы, удалите ее при помощи вышепомянутого меню настройки.) Затем мы выполняем аппаратную инициализацию модема (atz) и набираем номер удаленного сервера (atdt). Когда модемы установили соединение, регистрируемся на сервере и настраиваем его. (Процедура регистрации своя для каждого удаленного сервера, это просто пример.) Похоже, что все замечательно работает, так что мы завершаем соединение - привлекаем внимание модема (+++) и вешаем трубку (ath), а затем заново инициализируем модем. Работа с minicom завершается нажатием <Ctrl>+<A> и затем <Х>. Порт и модем нашей системы отлично работают. Если вы не можете передать модему даже простую команду, проверьте, что:
- модем правильно подключен к порту;
- использованы нужные кабели;
- модем включен в сеть питания;
- модем корректно настроен на исходящие звонки и эхо-отображение команд.
Если модем реагирует на простые команды, наберите номер удаленного сервера, как мы сделали в приведенном выше примере. Если модем отказывается набирать номер либо отображает сообщение NO DIALTONE, убедитесь, что телефонный кабель соединяет верный порт модема и телефонную розетку. Для проверки телефонной розетки можно использовать обычный аналоговый телефон. Если его нет под рукой, попробуйте заменить соединительный кабель. Если модем набирает номер, но не соединяется с удаленным модемом, убедитесь, что настройки локального модема соответствуют требованиям удаленной системы, которые необходимо знать для успешной отладки соединения. Ниже приводится перечень советов по отладке, в котором упомянут ряд моментов, подлежащих проверке. Успешно произведя подключение к удаленной системе, зафиксируйте все свои действия, а также весь вывод своего модема и удаленного сервера. Затем переведите удаленный сервер в режим РРР или SLIP и запишите, как этого удалось добиться. Все эти шаги необходимо будет воспроизвести в сценарии dip.
Начните с примитивного сценария, похожего на start-ppp.dip, чтобы иметь возможность убедиться в работоспособности базовых настроек, прежде чем наращивать сложность сценария, добавляя обработку ошибок. Выполните сценарий посредством dip с ключом подробной диагностики (-v). Строки сценария будут отображаться по мере их выполнения. Обращайте внимание на следующие возможные проблемы:
- Модем не реагирует на команды сценария. Убедитесь, что в команде port используется корректное имя устройства. Убедитесь, что аргументы команд databits, parity, speed и stopbits, если таковые присутствуют в сценарии, являются допустимыми для установленного модема. Еще раз проверьте, что модем понимает команды системы Hayes, в особенности если настройка модема выполняется при помощи ключевых слов dip, а не команды send.
- Модем не может соединиться с удаленным узлом. Убедитесь, что настройки модема идентичны тем, что использовались при подключении вручную. Параметры модема, такие как databits и parity, должны соответствовать настройкам удаленной системы. Вполне возможно, что для регистрации в удаленной системе требуется временное переключение на сочетание 7-бит/контроль четности. После регистрации следует переключиться обратно на сочетание 8-бит/без контроля, которое требуется для работы РРР и SLIP. Не забудьте убедиться, что верен номер телефона, указанный в команде набора, особенно если модем выводит строки VOICE, RING - NO ANSWER либо BUSY вместо ожидаемого CONNECT.
- Сценарий зависает. Вероятно, он находится ожидании ответа. Убедитесь, что корректны строки команд wait. Помните, что в качестве ожидаемой строки необходимо указывать лишь часть ответа. Лучше использовать строку «>», чем «Port9>», в случае, когда вы не уверены в номере порта, отображаемого удаленной системой. Используйте подстроку, которой заканчивается предполагаемый ответ, чтобы сценарий не начинал передачу данных прежде, чем будет готов к приему сервер. Кроме того, пробуйте вставлять задержку в сценарий, непосредственно перед первой командой серверу: к примеру, sleep 2, чтобы создать двухсекундную задержку. Задержка бывает необходима, чтобы сервер успел инициализировать порт, когда установлено модемное соединение.
- Удаленный сервер отображает сообщение об ошибке. Вероятно, сценарий посылает неверное значение. Проверьте строки всех команд передачи. Убедитесь, что они завершаются именно той комбинацией символов возврата каретки и новой строки, которая ожидается сервером.
Если возникли проблемы со сценарием, попробуйте выполнить dip в режиме тестирования (ключ -t), который позволяет вводить команды вручную, одну за другой. Повторяйте процедуру до тех пор, пока не получите четкой последовательности команд, необходимых для регистрации на удаленном сервере. Затем возвращайтесь к отладке сценария. Скорее всего, свежий взгляд на процесс регистрации позволит вам быстро выявить ошибку в сценарии.
Когда сценарий запущен, а соединение успешно установлено, ничто не должно препятствовать нормальной работе. Удаленный сервер должен отвечать на команду ping. Если здесь возникают проблемы, дело, вероятно, в настройке IP-интерфейса или неверном маршруте по умолчанию. Сценарий должен создать последовательный интерфейс. Команда netstat -ni выводит статистику по уже настроенным интерфейсам:
|
Name Mtu Net/Oest Address Ipkts Ierrs Opkts Oerrs Collis Queue dnet0 1500 172.16.15.0 172.16.15.1 10 4 0 0 0 lo0 1536 127.0.0.0 127.0.0.1 1712 0 1712 0 0 0 ppp0 1006 172.16.15.26 172.16.15.3 0 0 0 0 0 0
Интерфейс, в данном случае - ррр0, установлен. Команда сценария default создает маршрут по умолчанию. Воспользуйтесь netstat для просмотра содержимого таблицы маршрутизации:
|
Routing tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 1 28 lo0 default 172.16.25.3 U 0 0 ppp0 172.16.15.0 172.16.15.1 U 21 1687 le0
О содержимом таблиц маршрутизации мы подробно поговорим в следующей главе. Пока просто обратите внимание, что маршрут по умолчанию проходит через интерфейс ррр0 и что маршрут по умолчанию является маршрутом к удаленному серверу РРР (в данном случае - 172.16.25.3).
Если сценарий создал соединение, установил интерфейс, и таблица маршрутизации содержит маршрут по умолчанию, все должно работать как часы. Если по-прежнему возникают проблемы, они могут быть связаны с другими подсистемами TCP/IP. В главе 13 подробно описан процесс диагностирования и отладки.
