Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
U6-LR теряет пакеты на стороне LAN., wifiman
 
1 Введение  
Всем привет! Уже около года у меня проблемы с точкой доступа U6-LR. Я обращался в техподдержку не раз, но так как проблема проявляется очень непостоянно, её сложно расследовать.  
Суть в том, что с LAN стороны моих U6-LR временами пропадает связь.  
Я проверял это разными способами, но, например, в первом случае ниже видно, что я пингую свой UDM Pro (пакеты теряются), а другие устройства, подключённые к той же точке доступа, отвечают.  

Пример 1 (пинг к UDM Pro не проходит, пинг к телефону работает):  
 

Тоже самое происходит, если пинговать U6-LR с устройства, подключённого к LAN — в те же моменты видны пропущенные ответы. Обычно я пропускаю несколько пингов к UDM, но иногда связь пропадает на 20-30 секунд. Иногда (думаю, в основном при более долгих сбоях) замечаю, что индикатор на устройстве гаснет и включается снова.  
Для полноты картины: если я отключаю U6-LR и подключаюсь к AC-LR, проблем нет вообще. Вот почему, когда обе точки вещают одну и ту же Wi-Fi сеть, я почти не замечаю проблемы — клиенты плавно переходят на другую точку доступа.  

2 История и что я пробовал  
Я менял кабель, пробовал подключать к другому порту и так далее, но ничего не помогло решить проблему окончательно. На время помогало обновление прошивки на ту же версию. После этого какое-то время всё работало нормально, но потом проблема возвращалась.  
Я много общался с поддержкой Unifi, но это не привело к решению. Главное, что я хотел бы попробовать — заменить сам U6-LR на другой, но у меня нет запасного, так что сейчас это не самый простой вариант.  

3 Примеры инцидентов (все время — часовой пояс AMS, дата 18.12.2023)  
Инцидент 2: 11:52:30 — 2 пропущенных пинга  
Инцидент 3: 11:52:55 — 11:15:30 ~30 пропущенных пингов (связь пропала примерно на 3 минуты)  
 
Инцидент 3 длился так долго, что мой Android переключился на 5G — поэтому я не стал включать пинги к нему, они тоже не проходили, так как устройство уже не было подключено.  
Инцидент 4: 11:58:40 — 11:59:55 ~20 пропущенных пингов  
 
Во время инцидента 4 я ещё стал пинговать сам U6-LR по Wi-Fi. Сначала пинги проходили нормально, но когда индикатор на U6-LR начал мигать, ответы начали пропадать.
 
Так как я всё ещё не разобрался с проблемой, провёл небольшое дополнительное исследование и создал панель в Grafana, которая считает количество строк в логах и одновременно показывает, отвечает ли устройство на пинг:  

Я настроил это, подключив к Grafana/Loki через Vector (Network >> Settings >> System >> Syslog + Debug Logs).  

Так что теперь я просто жду, когда пинги снова упадут до нуля (как на графике выше, но там это был всего лишь тест с RF Scan, из-за которого устройства mesh-сети перестали отвечать на пинг).
 
Сегодня мой U6-LR снова упал. Чтобы разобраться в проблеме, я пытаюсь действовать постепенно. Что я изменил: вместо того чтобы подавать PoE напрямую с моего "Switch Lite 16 PoE" на U6-LR, я подключил его к одному из непоэ-портов и поставил между ними PoE-инжектор. Посмотрим, как теперь пойдут дела. P.S. @UI-Team, надеюсь, кто-то из вашей команды тоже подключится.
 
Сегодня днём снова произошёл разрыв связи. Я пытался записывать всё как можно точнее. Хронология:  
13:25 — начались отключения  
13:32 — устройство снова вышло в сеть примерно на минуту  
13:33 — устройство снова оффлайн  
13:34 — устройство подключилось окончательно  

Вот несколько скриншотов, которые я сделал:  
U6-LR подключён к порту, обведённому красным. Другое устройство, подключённое к PoE-портам — мой собственный компьютер (не PoE-устройство). Для порядка я теперь подключил его к другому порту без PoE питания.  
 

Точка доступа отображается как "Last Seen 11m 9s"  
 

Как уже упоминал в хронологии, устройства вернулись примерно на минуту:  
 

Uptime показывает, что устройство работает уже целых 2 дня с момента подключения (хотя есть сообщение о необходимости заменить кабель точки доступа)  
 
 

Я снова приложил файлы messages.log и messages.old.log к основному сообщению (не уверен, есть ли там чувствительные данные и стоит ли их свободно выкладывать на форуме).
 
Всем привет, честно говоря, я совсем исчерпал идеи. Последние минут десять или около того точка доступа снова долгое время не пингуется из сети. Точно так же, как с старой точкой доступа. Я пересадил её на другой порт того же коммутатора, поменял кабель, но мы снова в том же месте. Старые LR AP у меня на этом же коммутаторе работают прекрасно.

Для тех, кто с ubiquiti, я добавил /var/log/messages и /var/log/messages.old в первоначальный пост. Там есть информация о периоде, когда устройство начало глючить: примерно с четверга, 4 января, 00:30:00 до четверга, 4 января, 00:43:00. Также приложил экспортированный support-файл сразу после.

Для полноты картины, вот моя сеть:  
Мои Wi-Fi сети (все отмеченные красным сети вещаются U6-LR):  
Мои сети (VLANы):
 
Я установил устройство несколько дней назад, и всё вроде работало нормально до нескольких минут назад. Вся моя точка доступа снова потеряла соединение (через Ethernet-порт). Я подключился по ssh к AP и проверил /var/log/messages.old, вот что увидел — похоже, точка доступа снова потеряла эфирный порт!:

Tue Jan 2 23:29:28 2024 kern.warn kernel: [540888.686945] rai3: Отправка EAPOL-Key M1, DA=1c:53:f9:19:6b:f7, SA=62:22:32:38:d2:d3, длинна=113
Tue Jan 2 23:29:28 2024 kern.warn kernel: [540888.693120] [PMF]PMF_PerformRxFrameAction: NOT_ROBUST_UNICAST_FRAME, FC->SubType=13 (wcid=6)
Tue Jan 2 23:29:28 2024 kern.warn kernel: [540888.693467] rai3: Получен EAPOL-Key M2, DA=62:22:32:38:d2:d3, SA=1c:53:f9:19:6b:f7, длинна=135
Tue Jan 2 23:29:28 2024 kern.warn kernel: [540888.694538] rai3: Отправка EAPOL-Key M3, DA=1c:53:f9:19:6b:f7, SA=62:22:32:38:d2:d3, длинна=217
Tue Jan 2 23:29:28 2024 daemon.warn hostapd[28841]: RADIUS: wpa_driver_nl80211_hapd_send_eapol() ==> STA- 1c:53:f9:19:6b:f7
Tue Jan 2 23:29:28 2024 daemon.warn hostapd[28841]: RADIUS: wpa_driver_nl80211_hapd_send_eapol() ==> AP- 62:22:32:38:d2:d3
Tue Jan 2 23:29:28 2024 daemon.warn hostapd[28841]: RADIUS: Интерфейс rai3 в мосту br0.40
Tue Jan 2 23:29:28 2024 daemon.warn hostapd[28841]: RADIUS: Отправка EAPOL-кадра (длинна: 203)
Tue Jan 2 23:29:28 2024 daemon.info hostapd[28841]: rai3: STA 1c:53:f9:19:6b:f7 WPA: завершено схождение парных ключей (RSN)
Tue Jan 2 23:29:28 2024 kern.warn kernel: [540888.698356] rai3: Получен EAPOL-Key M4, DA=62:22:32:38:d2:d3, SA=1c:53:f9:19:6b:f7, длинна=107
Tue Jan 2 23:29:28 2024 kern.warn kernel: [540888.698930] 80211> Добавление ключа STA(1C:53:F9:19:6B:F7) ==>
Tue Jan 2 23:29:28 2024 kern.warn kernel: [540888.698938] 80211> Добавление ключа AP
Tue Jan 2 23:29:28 2024 user.info libubnt[28831]: wevent[28831]: wevent.ubnt_custom_event(): СОБЫТИЕ_STA_JOIN rai3: 1c:53:f9:19:6b:f7 / 14
Tue Jan 2 23:29:29 2024 kern.info kernel: [540889.366246] mtk_soc_eth 1b100000.ethernet: путь gmac1_sgmii в set_mux_gdm1_to_gmac1_esw обновлен = 1
Tue Jan 2 23:29:29 2024 kern.info kernel: [540889.366259] mtk_soc_eth 1b100000.ethernet: мультиплексор mux_gmac2_gmac0_to_gephy отсутствует на SoC
Tue Jan 2 23:29:29 2024 kern.info kernel: [540889.366265] mtk_soc_eth 1b100000.ethernet: мультиплексор mux_u3_gmac2_to_qphy отсутствует на SoC
Tue Jan 2 23:29:29 2024 kern.info kernel: [540889.366277] mtk_soc_eth 1b100000.ethernet: путь gmac1_sgmii в set_mux_gmac1_gmac2_to_sgmii_rgmii обновлен = 1
Tue Jan 2 23:29:29 2024 kern.info kernel: [540889.366283] mtk_soc_eth 1b100000.ethernet: мультиплексор mux_gmac12_to_gephy_sgmii отсутствует на SoC
Tue Jan 2 23:29:29 2024 kern.info kernel: [540889.366816] br0: порт 1(eth0) вошёл в состояние disabled
Tue Jan 2 23:29:29 2024 kern.info kernel: [540889.367292] br0.30: порт 3(eth0.30) вошёл в состояние disabled
Tue Jan 2 23:29:29 2024 kern.info kernel: [540889.367685] br0.40: порт 2(eth0.40) вошёл в состояние disabled
Tue Jan 2 23:29:29 2024 kern.info kernel: [540889.368195] br0.70: порт 2(eth0.70) вошёл в состояние disabled
Tue Jan 2 23:29:32 2024 daemon.info hostapd[28843]: ra3: STA c8:2b:96:53:86:e1 RADIUS: запускается сессия учета EAA896F4D96A1BBB
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.366268] mtk_soc_eth 1b100000.ethernet: путь gmac1_sgmii в set_mux_gdm1_to_gmac1_esw обновлен = 1
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.366283] mtk_soc_eth 1b100000.ethernet: мультиплексор mux_gmac2_gmac0_to_gephy отсутствует на SoC
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.366288] mtk_soc_eth 1b100000.ethernet: мультиплексор mux_u3_gmac2_to_qphy отсутствует на SoC
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.366300] mtk_soc_eth 1b100000.ethernet: путь gmac1_sgmii в set_mux_gmac1_gmac2_to_sgmii_rgmii обновлен = 1
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.366306] mtk_soc_eth 1b100000.ethernet: мультиплексор mux_gmac12_to_gephy_sgmii отсутствует на SoC
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.366685] br0: порт 1(eth0) вошёл в состояние blocking
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.366697] br0: порт 1(eth0) вошёл в состояние forwarding
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.367040] br0.30: порт 3(eth0.30) вошёл в состояние blocking
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.367049] br0.30: порт 3(eth0.30) вошёл в состояние forwarding
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.367192] br0.40: порт 2(eth0.40) вошёл в состояние blocking
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.367200] br0.40: порт 2(eth0.40) вошёл в состояние forwarding
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.367338] br0.70: порт 2(eth0.70) вошёл в состояние blocking
Tue Jan 2 23:29:32 2024 kern.info kernel: [540892.367347] br0.70: порт 2(eth0.70) вошёл в состояние forwarding
Страницы: 1
Читают тему (гостей: 1)