Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Зависший маячок, UniFi Network
 
У нас несколько кемпингов, где используется Outdoor UniFi. Все установки работают на версии 2.3.9. На каждом объекте есть контроллер, но мы не используем Guest Portal. Мы переопределяем SSID и устанавливаем WPA2 для безопасности. Иногда отдельные точки доступа перестают принимать клиентов. Они исправно передают сигнал Beacon, на них можно сделать ping или зайти через Putty, и они принимают команды на перезагрузку как при прямом входе, так и через контроллер UniFi. Похоже, сама точка доступа страдает от программного бага. Нет никакой закономерности — это происходит с разными точками доступа случайным образом, без определённой частоты, и, кажется, не связано с окружением, временем суток или температурой. Простой мягкий ребут через контроллер возвращает её в строй. Знаю, что эта тема уже обсуждалась на форуме. Просто хотел узнать, продвинулись ли в решении проблемы. Версия 3 что-то меняет в этом плане? Всем спасибо. Стивен
 
Решение scotkeen может решить проблему, заставив использовать 802.11g, но разве это не уменьшит радиус действия? Одно из преимуществ 802.11n — увеличенный радиус покрытия. Можете подтвердить, влияет ли принудительное использование 802.11g на радиус действия точки доступа?
 
В настоящий момент у нас установлена версия 2.4.3.2043. Большинство наших устройств работают нормально, но одно конкретное устройство, которое, как я знаю, находится в шумной среде, постоянно теряет подключение пользователей. Пользователи не остаются отключенными надолго, но это заметно, и они жалуются.
 
Привет, naldo, какую версию ты используешь? Привет всем, «залипание» маяка обычно происходит в шумной среде. Прекращение приёма клиентов действительно было проблемой в версии 2.3.x, мы исправили это в версии 2.4.x. Пожалуйста, обновитесь, это должно решить проблему с прекращением приёма клиентов. Спасибо, David.
 
Могу подтвердить, что WiFi (Intel WiFi 4965AGN) в моём Lenovo ThinkPad X61 способен «зависать» разные точки доступа в режиме stuck beacon. Он «заставил» мой роутер Trendnet и точку доступа UniFi оказаться в stuck beacon. Это всегда происходит при подключении по 802.11n. РЕШЕНИЕ: за годы я заметил, что если ограничить точку доступа до 802.11g, чтобы ноутбук подключался именно по 802.11g, а не по 802.11n, проблема решается на все 100%. Я сделал так с Trendnet и UniFi, и это помогло. Беспокоюсь, что в UniFi 3.x, кажется, уже нельзя ограничить точку доступа до 802.11g в настройках «Radios». Надеюсь, эту опцию вернут.
 
carlitosway: Эта проблема с чипсетами Atheros тянется уже с 2007? 2008? http://madwifi-project.org/wiki/StuckBeacon
 
Мы здесь не одни... Похоже, это постоянная проблема с Unifi Outdoor-AP. В форуме Unifi полно постов от разных людей с похожими описаниями проблемы, но пока UBNT никак не исправили ситуацию. Один из моих последних постов был в теме: UniFi AP's stop accepting clients and need reboot. На момент написания моего ответа в ней уже 331 комментарий и около 27 500 просмотров — одна из самых популярных тем на форуме. Исходный вопрос был задан ещё 29.06.2012 в 22:58. На следующей неделе будет год с момента первого поста, а решения от UBNT до сих пор нет. Ух ты! Интересно, кто-то из топ-менеджеров UBNT вообще читает эти темы? Может, тогда они бы выделили ресурсы на решение проблемы, ведь это точно скажется на будущих продажах продукта.

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

Я использовал Console 2.3.9 для настройки AP, но не оставлял компьютер на объекте и не использовал облачное решение. Думаю попробовать вариант Synergy_Wes с версией 2.2.5, но не уверен, не создаст ли это новых проблем. Кроме того, на объекте клиента Outdoor AP работает без консоли, и я не знаю, смогут ли AP сами понять, что зависли и автоматически перезагрузиться с помощью прошивки 2.2.5 или всё равно придётся держать компьютер с консолью, чтобы контролировать это.

Кто-нибудь может подтвердить, что проблема решена в версиях 3.1.2 или 3.1.3? Я даже готов съездить к клиенту и проверить эти версии, пусть они даже бета. Очень надеюсь, что UBNT скоро займётся этой проблемой. Система реально может быть отличным продуктом, и я на неё большие надежды возлагаю, но без этого исправления, как уже сказал Synergy_Wes, Unifi пока не готов к серьёзной работе.
 
Кто-нибудь может объяснить, что здесь происходит? Особенно с этим предупреждением Badness в local_bh_enable в kernel/softirq.c:140. Знаю, что устройство застряло на маячке, но впервые вижу такое сообщение.

Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] Badness в local_bh_enable в kernel/softirq.c:140
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] Call Trace:
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<8002ad2c>] local_bh_enable+0x94/0x9c
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<c020cdd0>] __ip_conntrack_helper_find_byname+0xf0/0x1ec [ip_conntrack]
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<80110ba8>] __kfree_skb+0x10c/0x16c
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<801109d0>] kfree_skbmem+0x14/0xe0
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<c0307c5c>] ieee80211_reset_bss+0x970/0xf80 [wlan]
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<c0307c5c>] ieee80211_reset_bss+0x970/0xf80 [wlan]
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<c0307a5c>] ieee80211_reset_bss+0x770/0xf80 [wlan]
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<8002f718>] run_timer_softirq+0x1ac/0x1ec
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<8002aac8>] __do_softirq+0x84/0x130
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<8002abdc>] do_softirq+0x68/0x70
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<80007104>] do_IRQ+0x24/0x34
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<80003608>] ar7240_interrupt_receive+0xe8/0x100
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<8000540c>] r4k_wait+0x0/0xc
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<80007664>] cpu_idle+0x30/0x50
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<80005410>] r4k_wait+0x4/0xc
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<800bfe30>] idr_cache_ctor+0x0/0xc
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<801ef804>] start_kernel+0x1d4/0x1ec
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000] [<801ef290>] unknown_bootoption+0x0/0x328
Jun 20 18:59:49 2ndFloor user.warn kernel: [789805.481000]

Повторяется тоже самое предупреждение Badness в local_bh_enable с похожим Call Trace.

Jun 20 19:00:07 2ndFloor user.warn kernel: [789824.058000] ath_bstuck_tasklet: застрявший маячок; сброс (bmiss count 18)
Jun 20 19:02:12 2ndFloor user.info syslog: wevent.recv_msg(): EVENT_STA_JOIN ath1: 00:c0:ca:4f:55:9b / 2  
Jun 20 19:02:19 2ndFloor user.info kernel: [789955.994000] NETDEV WATCHDOG: wifi0: передача данных прервана по таймауту
Jun 20 19:03:34 2ndFloor daemon.info hostapd: ath0: STA e8:3e:b6:6d:50:92 IEEE 802.11: отключился  
Jun 20 19:03:34 2ndFloor user.info syslog: wevent.recv_msg(): EVENT_STA_LEAVE ath0: 15  
Jun 20 19:05:10 2ndFloor user.info kernel: [790127.025000] NETDEV WATCHDOG: wifi0: передача данных прервана по таймауту
Jun 20 19:05:19 2ndFloor user.info kernel: [790136.054000] NETDEV WATCHDOG: wifi0: передача данных прервана по таймауту
Jun 20 19:05:30 2ndFloor user.info kernel: [790147.073000] NETDEV WATCHDOG: wifi0: передача данных прервана по таймауту
Jun 20 19:05:33 2ndFloor user.warn kernel: [790149.561000] ath_bstuck_tasklet: застрявший маячок; сброс (bmiss count 18)
 
Могу подтвердить, что эта проблема до сих пор существует и касается всех моделей Unifi. У нас несколько развертываний Unifi, самое большое — около 100 радиостанций в многоквартирном доме. Я тоже надеялся и поддержка UBNT после нескольких месяцев проблем уверила меня, что прошивка 2.3.9 решит этот вопрос. Единственное, что мне удалось использовать для исправления — это запуск всех точек доступа и контроллера на прошивке 2.2.5, которая перезагружает точки доступа при ошибке маяка. Не понимаю, зачем это убрали в более новых версиях прошивки, если проблема всё ещё есть. Минус в том, что модели Unifi Pro с 2.2.5 не совместимы. В целом эта система совсем не оправдывает своего корпоративного статуса.
Страницы: 1
Читают тему (гостей: 1)