UniFi — Методы сбора полезной отладочной информации

В данной статье описано несколько методов сбора полезной отладочной информации.
Имейте в виду, что если Вы обнаружили проблемы и решили использовать вышеупомянутые методы, то мы рекомендуем Вам начать с изучения соответствующей ветки в сообществе, либо с написания комментариев в соответствующей ветке. Если Вам требуется настроить по удаленному доступу выдачу журналов, примите к сведению то, о чем сообщают UBNT-MikeD, UBNT-Cody, UBNT-BenBuckley, UBNT-jeff и UBNT-Brandon.

Настройка выдачи журналов (по удаленному доступу)
Для чего это требуется

Одной из первых вещей, которая нас интересует при отладке, является вывод ‘cat /var/log/messages` или ‘dmesg’. Однако, в некоторых случаях, не все сообщения могут быть переданы пользователю обратно в течение сессии SSH.  Другой обычный случай: Вы не были зарегистрированы, когда произошла проблема и поэтому не могли видеть выведенные сообщения; затем они были потеряны после того, как точка доступа АР перезагрузилась.  Простейшим решением в этом случае является использование удаленного сервера журналов.
В добавление к сбору информации о том, что привело к перезагрузке, удаленный сервер может упростить процесс совместного использования файлов журналов.

Инструкции по конфигурированию

Запустите netconsole (консоль сети) следующей командой:
insmod netconsole netconsole=1234@<IP-адрес точки доступа (AP)>/eth0,514@67.214.227.82/<MAC-адрес Вашего маршрутизатора>
ПРИМЕЧАНИЕ: 1234 — это фиктивный номер порта и это число может быть любым
ПРИМЕЧАНИЕ: MAC-адрес должен содержать двоеточия, например XX:XX:XX:XX:XX:XX

Если Вам требуется, чтобы netconsole выдерживала перезагрузки, введите следующие команды:
touch /etc/persistent/profile
echo » /etc/persistent/profile
syswrapper.sh save-config
Даже после ввода команд, делающих удаленный вывод журналов постоянным, Вам потребуется по SSH входить в AP, чтобы инициализировать вывод журналов. А именно, после каждой перезагрузки, Вам потребуется по SSH войти в AP, чтобы снова началось ведение журнала.
Чтобы деактивировать netconsole после ее постоянной работы:
rm /etc/persistent/profile
syswrapper.sh save-config

Свяжитесь с нами

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

Минимальные поддерживаемые версии фирменного программного обеспечения

Netconsole поддерживается только в последних версиях фирменного ПО. Информацию о минимальной поддерживаемой версии см. ниже.
Версия 3.7.9 поддерживает весь функционал netconsole, за исключением UAP-InWall.
В версию 3.7.10 добавлена поддержка UAP-InWall.

Захват сетевого трафика на AP
Для чего это требуется

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

Использование tcpdump для захвата трафика

Захват трафика на любом интерфейсе АР можно осуществить командами:

tcpdump -i -w /tmp/

Здесь athX соответствует SSID, вещающей с АР. Его можно определить, если войти по SSH на AP и выполнить команду iwconfig

Этот метод имеет существенный недостаток — файл сохранен на АР, на которой иногда исчерпывается память, если она работает очень долго. Кроме того, когда Вы завершите свои действия, Вам потребуется перехватить этот файл (и это, в лучшем случае, вызывает досаду). Вы можете модифицировать приведенную выше команду, чтобы сохранить файлы на компьютере с которого был инициирована сессия ssh:

ssh @<ip-адрес AP> ‘tcpdump -i src not <ip-адрес компьютера> and dst not <ip-адрес компьютера> -w -‘ >

Условия src not и dst not важны, так как они предохраняют Ваш файл от переполнения трафиком SSH между компьютером и AP.

Выполните эту команду столько раз, сколько у Вас имеется интерфейсов, на которых требуется захват трафика.

Другие статьи по этой теме

Все авторские права и другие права интеллектуальной собственности на данные материалы являются собственностью Компании «Рутстор» (ROOTSTORE). При использовании данного материала ссылка на сайт rootstore.ru обязательна.

Авторизация
*
*
Регистрация
*
*
*
*
Генерация пароля
Заказать звонок



Купить в 1 клик