Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
UAP-AC-Pro не в сети примерно 10 минут после примерно 10 минут работы., UniFi Network
 
Привет, ребята! Как видно на изображении из Ping Plotter, наши UAP-AC-PRO не в сети примерно 10 минут, примерно через 10 минут после перезагрузки или отключения питания:

После 10 минут они снова доступны. Всё это время точка доступа отображается в mac-address-table на коммутаторе и в ARP-таблице роутера. Невозможно ни пропинговать устройства, ни подключиться к ним (ни по SSH, ни через контроллер).

Но это происходит только на прошивках:  
1-я точка доступа: hotfix-qca956x-3.4.17.32  
2-я точка доступа: 3.4.16.3435  

Такого не происходит на:  
3-я и 4-я точки доступа: 3.4.10.3347 (заводская прошивка)  

Логи syslog приложены. Кстати, у AP3 и AP4 проблем с синхронизацией времени нет. Я думаю, что это не нормальное поведение. Кто-то может объяснить, что здесь происходит или это баг? После того как 1-я и 2-я точки доступа возвращаются онлайн, они вроде работают нормально без проблем с подключением.
 
Извините, я пропустил момент с невозможностью подключения через SSH в вашем первоначальном сообщении. Для меня это точно что-то новое — возможно, @UBNT-jeff или кто-то из остальных разработчиков прошивки смогут что-то посоветовать или попросят провести дополнительные проверки.
 
Также не отвечает на SSH... Контроллер не может подключиться к AP и отправляет письма с темой «AP Disconnected»...
 
Он просто не отвечает на пинг, если только вы не проверили другими способами, что он вообще ничего не делает. Так вы тестировали что-то кроме пинга? Пинг может быть единственным, что не отвечает, а в остальном всё работает нормально.
 
выключил 5 ГГц -> перезагрузка -> 5 минут доступен, а потом больше не появляется в сети. записи arp и mac-таблицы остаются, но точка доступа просто не отвечает по TCP/IP.
 
10 минут звучит как время ожидания DFS после обнаружения RADAR.
 
Та же проблема с ctrl 5.0.2 и ap 3.7.2.4919.
 
Привет, @UBNT-MikeD, я понизил версию прошивки на точках доступа, но результат тот же.
 
Ты пробовал версию 3.4.19.5, как советовал Джефф? Если нет, пожалуйста, попробуй. Если да, не мог бы ты рассказать, как дела? Похоже, что этих данных не хватает.

Спасибо, Майк.
 
Есть какие-нибудь новые идеи, @UBNT-jeff?
 
В данный момент установлена встроенная прошивка версии 5.0.2 Beta.

@UBNT-jeff

P.S.: Точки доступа работают на версии 3.7.2.4919.
 
@fischeol

Извини, нужно было спросить это сразу. Ты пробовал версию 3.4.18 или последний ожидающий хотфикс: http://dl.ubnt-ut.com/uap-ac-pro-3.4.19.5.bin?
 
@EricE

Можешь перезагрузить устройство через выключатель, который его питает? Можешь запускать free по SSH каждую минуту, чтобы проверить, не утекает ли память?
 
@UBNT-jeff

У тебя включено расписание WLAN?  
— Нет, я отключил его для теста.

Уточняют ли точное время на точках доступа через 10 минут, когда они работают без сбоев?  
— Нет, время всё ещё стоит 1970 года.

Это всегда ровно 10 минут?  
— Не совсем, в моём тесте пару секунд назад было 6 минут работы и примерно 10 минут простоя, плюс-минус несколько секунд.
 
@fischeol

У тебя включено расписание для WLAN? Если да, и у точки доступа неправильное время, она будет блокировать трафик, пока не синхронизируется по времени. Через 10 минут, когда точки доступа работают нормально, у них правильное время? Это всегда ровно *ровно* 10 минут? Похоже, что через 10 минут происходит что-то автоматическое.
 
Это интересно

@UBNT-jeff

Когда я убиваю процесс: 3126 admin 1112 S /sbin/ntpclient -i 86400 -n -s -c 0 -l -h 0.ubnt.pool.ntp.org, ничего не происходит. Дата по-прежнему показывает 1970… Когда я запускаю команду вручную, происходит синхронизация: BZ.v3.7.2# /sbin/ntpclient -i 86400 -n -s -c 0 -l -h 0.ubnt.pool.ntp.org  
25567 07557.017 424.0 0.5 1463660137747742.8 71624.8 0

После остановки выполнения с помощью ctrl+C команда «date» выдает правильную дату и время.  

Прикреплен tcpdump, а ping показывает:  
ping 10.211.238.2 -l 1344 -n 1024  
Пакеты: отправлено = 309, получено = 309, потеряно = 0

ping 10.211.238.2 -l 16  
Пакеты: отправлено = 314, получено = 314, потеряно = 0  

По крайней мере — простой длится всего 10 минут после старта, а потом точки доступа работают без сбоев…
 
@fischeol

Это точно не утечка памяти, но интересно, что половина точек доступа не смогла синхронизироваться по NTP. Можешь запустить tcpdump на интерфейсе br0 примерно на 30 секунд, чтобы посмотреть, какой трафик приходит на UAP, и при этом попингуй UAP некоторое время (маленькими и большими пакетами)? Такое ощущение, что где-то в проводной сети что-то не так.
 
Я сделал так, как ты сказал.

@UBNT-jeff

Все 4 точки доступа перезагрузились примерно в 11:12:30, потом проработали около 10 минут, а затем снова перестали быть доступными. Интересный момент: в это время я смог подключиться к WLAN. На свитче, к которому подключены точки доступа, в разделе PoE Output показывается 3700 мВт потребляемой мощности, а в таблице MAC-адресов видны и точки доступа, и клиент WLAN.

Я приложил лог консоли Putty к посту: 10 минут "свободы" после того, как точки доступа снова стали доступны:

dmesg  
cat /var/log/messages

И, наконец, график Ping Plotter:
 
Это не моё, это AP от @fischeol. Уверен, он оценит ваше внимание и, судя по всему, более чем достаточно подкован, чтобы дать вам все детали, которые понадобятся для расследования. Моя задача была просто привлечь к нему внимание, так что спасибо, что откликнулись.

П.С. В его оригинальном сообщении был лог для этой темы.
Страницы: 1
Читают тему (гостей: 1)