Таймаут DNS и высокая задержка TCP

Таймаут DNS и высокая задержка TCP, UniFi Network

rcichosz

Guest

17.02.2021 15:07:00

Что тут сказать.
[62720.037606] [STA_TRACKER] Тайм-аут DNS-запроса; [STA: 3a:37:c1:41:29:51][ЗАПРОС: google.com.] [DNS_SERVER: 192.168.50.1] [TXN_ID 000e] [SRCPORT 60000]
[62837.070616] ieee80211_sta_leave: 3a:37:c1:41:29:51
[64280.157601] [STA_TRACKER] Тайм-аут DNS-запроса; [STA: 3a:37:c1:41:29:51][ЗАПРОС: google.com.] [DNS_SERVER: 192.168.50.1] [TXN_ID 000e] [SRCPORT 38756]
[64753.239387] ieee80211_sta_leave: 3a:37:c1:41:29:51
[64770.637595] [STA_TRACKER] Тайм-аут DNS-запроса; [STA: 3a:37:c1:41:29:51][ЗАПРОС: google.com.] [DNS_SERVER: 192.168.50.1] [TXN_ID 000e] [SRCPORT 57863]
[65568.469474] ieee80211_sta_leave: 3a:37:c1:41:29:51
[65604.477601] [STA_TRACKER] Тайм-аут DNS-запроса; [STA: 3a:37:c1:41:29:51][ЗАПРОС: google.com.] [DNS_SERVER: 192.168.50.1] [TXN_ID 000e] [SRCPORT 34598]
[65758.015344] ieee80211_sta_leave: 3a:37:c1:41:29:51
[66108.197601] [STA_TRACKER] Тайм-аут DNS-запроса; [STA: 3a:37:c1:41:29:51][ЗАПРОС: google.com.] [DNS_SERVER: 192.168.50.1] [TXN_ID 000e] [SRCPORT 44656]

И так снова и снова на разных точках доступа. Это не роуминг. Некоторые устройства вообще не двигаются, например контроллер ST-525, телевизор Samsung.

Оборудование: RB4011 роутер, vlan на интерфейсе, а не на мосту. Свитчи Cisco 3750, DGS-1210, DGS-1100, EdgeMAX 10xp, UAPv1, UAP-AC-lite. В сети несколько постоянных vlan. Пинги к роутеру с AP всегда идут. Ошибки в разных сегментах сети. Проблема с DHCP, вероятно, решена, но если смотреть на статистику у клиента, создаётся впечатление, что трафик либо остановился, либо ограничен.

В другой сети, где тоже стоит RB4011 с vlan на мосту, свитчи T1600G, DES-3028, SLM2048, UAPv2, UAP-AC-Lite, сеть построена на freeradius. Ошибки DHCP спорадичны, скорее всего, потому что я увеличил время аренды. Но в списке клиентов появляются повторяющиеся IP-адреса, хоть адреса и выдаются роутером корректно, и передача работает. Пытался 4.3.28, но на zoom.us были тормоза, пришлось вернуться к 4.3.26 — сейчас она самая стабильная. Включение DHCP snooping на tp-link вызывает ситуацию, когда беспроводные клиенты случайным образом не получают DHCP-адреса. Настольные компьютеры по Ethernet работают отлично.

elijahg0

Guest

09.04.2021 02:05:00

Я сталкиваюсь с той же проблемой — высокая задержка TCP практически у всех клиентов, но, кажется, на частоте 5 ГГц это ещё хуже. Пинги от клиента до роутера обычно доходят до самого роутера, и ответ приходит на беспроводной интерфейс точки доступа, но потом этот ответ почему-то пропадает при передаче и так и не доходит до клиента. Скоро создам новую тему по этому вопросу.

jamessturge

Guest

28.03.2021 22:08:00

У меня такая же проблема — высокая задержка TCP для клиентов. У меня около точки доступа AC-PRO стоит много Wi-Fi устройств, таких как телефоны, iPad, MacBook и т.д., почти прямо под точками доступа, и они показывают эти аномалии.

UI-Glenn Guest	#4 09.03.2021 19:14:00 Привет, @rcichosz, нам нужны захваты пакетов, которые покажут, что 1.1.1.1 действительно отвечает, несмотря на то, что точка доступа говорит обратное.

rcichosz

Guest

09.03.2021 16:45:00

Я уже проверял с dns 1.1.1.1, и это не сработало. Я сдаюсь. Проблема есть, но как-то я справляюсь. Перезагружаю время от времени — и всё норм. Бороться с этим не хочу, это пустая трата времени. Будет повод заменить точку доступа на устройство другого производителя. Сеть простая, буду менять постепенно, и всё.

UI-Glenn Guest	#6 08.03.2021 19:42:00 Привет, @rcichosz, тебе нужно сосредоточиться на захвате пакетов с DNS-запросами, на которые нет ответов. Также настрой своих клиентов на использование 1.1.1.1 и сообщи, решит ли это твои проблемы.

rcichosz Guest	#7 08.03.2021 19:07:00 Что касается меня, на UAP наблюдается утечка пакетов — они просто теряются и не доходят до пункта назначения. Скриншоты с разных точек доступа. UAP-AC-Lite и UAP.

rcichosz

Guest

05.03.2021 14:34:00

Я не использую расписание, PMF отключён, ATF обычно тоже выключен. Я включил его для теста, но разницы никакой не заметил. После тестов ATF у меня только ощущение, что трафик лучше распределяется между 2G и 5G, и клиенты чаще подключаются к 5G. Во время теста никаких негативных симптомов не заметил. В целом, файл SUPP находится в PW, так что можно посмотреть, что именно настроено.

UI-Glenn Guest	#9 05.03.2021 13:27:00 Привет, @rcichosz, у тебя есть расписание для WLAN? Или включены ATF/PMF? (и так далее)

jchipps Guest	#10 05.03.2021 12:37:00 У многих возникли проблемы с версией 4.3.24 — можно вернуться к 4.3.20?

rcichosz

Guest

#11

05.03.2021 12:23:00

UAP-AC-Lite точно работает на 2G. Например, один клиент подключён к точке доступа, но наблюдаются повторные передачи TCP. Мне нужно посмотреть, как ведёт себя 5G. Когда передачи стали пропадать, возможно, к точке доступа были привязаны только 2 клиента, а третий не мог подключиться. Перезагрузка помогла. Начинаю подозревать, что проблема может быть в контроллере версии 6.0.45. Хотя сеть простая, и мне совсем не хочется винить контроллер, потому что явной связи не вижу. Может, дело в настройках, которые контроллер отправляет на UAP? Ещё можно поработать с сообщениями в логах событий WARN с тегом <inform_stat-1>.

UI-Glenn Guest	#12 04.03.2021 14:26:00 Привет, @rcichosz, можешь попробовать каналы без DFS? Это происходит только на 2,4 ГГц или на 5 ГГц тоже?

rcichosz

Guest

#13

04.03.2021 07:16:00

Мои основные каналы от провайдера — радио. Средний пинг 20-30 мс, максимум иногда до 50 мс. Целый день проверял. Это не задержки и точно не DNS. Что касается повторных TCP-передач, похоже, что-то не так с AP. У меня есть второе место — ссылка с большим запасом по пропускной способности, и там повторные TCP-передачи тоже случаются. Я всё ещё ломаю голову над ухудшением Wi-Fi соединения. Неясно, где именно возникает проблема с AP, но когда она появляется, у пользователей начинаются проблемы. Помогает перезагрузка AP. Что-то тут явно не так. Кабельная сеть нормально работает. По DHCP и hostapd: интересно, не используете ли вы иногда DHCP-функционал, встроенный в модуль hostapd, и не вызывает ли это проблемы.

64 bytes from 1.1.1.1: icmp_seq=23034 ttl=57 time=32.4 ms
64 bytes from 1.1.1.1: icmp_seq=23035 ttl=57 time=18.8 ms
64 bytes from 1.1.1.1: icmp_seq=23036 ttl=57 time=17.2 ms
64 bytes from 1.1.1.1: icmp_seq=23037 ttl=57 time=16.2 ms
64 bytes from 1.1.1.1: icmp_seq=23038 ttl=57 time=16.6 ms
64 bytes from 1.1.1.1: icmp_seq=23039 ttl=57 time=24.9 ms
64 bytes from 1.1.1.1: icmp_seq=23040 ttl=57 time=50.3 ms
64 bytes from 1.1.1.1: icmp_seq=23041 ttl=57 time=17.2 ms
64 bytes from 1.1.1.1: icmp_seq=23042 ttl=57 time=17.9 ms
64 bytes from 1.1.1.1: icmp_seq=23043 ttl=57 time=15.9 ms
64 bytes from 1.1.1.1: icmp_seq=23044 ttl=57 time=29.4 ms
64 bytes from 1.1.1.1: icmp_seq=23045 ttl=57 time=29.1 ms
64 bytes from 1.1.1.1: icmp_seq=23046 ttl=57 time=16.0 ms
64 bytes from 1.1.1.1: icmp_seq=23047 ttl=57 time=26.2 ms
64 bytes from 1.1.1.1: icmp_seq=23048 ttl=57 time=49.1 ms

hwinkel Guest	#14 03.03.2021 19:44:00 У нас такая же проблема с контроллером на версии 6.x. Офисный WiFi почти перестал работать. Вся надежда, что это наконец-то исправят, постепенно исчезает. Резервной копии для контроллера 5.x у нас нет, так как храним всего 10 дней. У нас есть несколько HD точек доступа с AC, в надежде, что это поможет. Но после первоначального обновления прошивки до текущей версии 4.3.24 та же проблема повторилась. Сброс TCP-соединений и тайм-ауты DNS теперь стали нормой, и вся команда уже на грани. Что можно сделать с этой проблемой?

Читают тему (гостей: 1)