Jump to content
  • 0

Keenetic Giga c 4.1.7, неожиданное ухудшение работы WiFi с 28.06.24


Drakonru

Question

День добрый. Создаю новую тему, так как, поискав по форуму ответ на свой вопрос, не нашел ответа или идеи или направления куда «копать».

Ранее уже открыл запрос в поддержку, предоставив все вводные, но полученные рекомендации не помогли.

Исходные данные:

Keenetic Giga, версия ПО 4.1.7, питание – от стабилизированного UPS, подключение к провайдеру через оптику, терминальное устройство провайдера – модем, подключенный к роутеру по Ethernet, авторизация доступа в интернет происходит на роутере по MAC. Роутер стоит на втором этаже дачного дома, так как оптика приходит со столба. Вокруг дома нет и не появилось точек доступа с мощным сигналом, которые бы могли влиять на эфир.

Как работало все 4 года до момента сбоя: для обоих диапазонов стоит WPA2, мощность сигнала 100%, выбор канала – авто, динамически. Для диапазона 2.4 GHz стандарт b/g/n, ширина канала 20/40 MHz. Для диапазона 5.0 GHz стандарт a/n/ac, ширина канала 20/40/80 MHz. Управление BSS-окружением 802.11k/v включено.

Все клиенты WiFi зарегистрированы и имеют фиксированные IP, размер пула DHCP достаточный.

Самый активный потребитель трафика – десктоп, стоит за деревянной стеной в 2-3 метрах от роутера, есть еще ноут, несколько смартфонов, которые, в отличии от десктопа, перемещаются по дому.

Есть два клиента, подключенных к роутеру по кабелю, они работают в прежнем режиме без проблем.

28.06.24 появилась проблема, связанная с передачей данных по WiFi, причем, на всех устройствах сразу. Открытие web страницы – не весь контент загружается сразу, либо нужно ждать, либо вручную перезагружать страницу принудительно несколько раз. Видео показывается дискретно: идет поток некоторое время, потом заметная пауза, потом снова воспроизведение, потом пауза и так далее. Голосовые звонки WhatsApp, Telegram, Discord, начинаются, но слышимость исходящая и входящая плохая, через несколько секунд после начала, например, приложение WA просит перейти в зону уверенного приема. На смартфонах только с 2.4 GHz происходило самопроизвольное отключение от сети – смартфон сеть видит, но автоматом не подключается, требуется участие пользователя.

Если запустить SpeedTest или другой сервис на устройстве, подключенном к WiFi, то скорость ко мне от меня соответствует заявленной, т.е. к провайдеру претензий нет. Единственный нюанс – на подключении провайдера по умолчанию MTU появляется 1500, но если попинговать с клиента, подключенного к WiFi, командой ping www.yandex.ru -f -l 1400, то выясняется, что оптимальный размер MTU, который «пролезает» без сообщения про DF – 1400.

 

Что было сделано:

Сначала несколько раз «открывали-закрывали капот» J Делали рестарт по питанию и для роутера и для модема провайдера.

Потом был открыт запрос в поддержку. Рекомендации: убрать «старые» стандарты «b» и «a» из списка поддерживаемых, зафиксировать канал в каждом диапазоне, задать выбор канала каждые 6 часов, потому что «новые устройства их могут терять», мда. Еще порекомендовали добавить порядка шести серверов DNS. После всего этого порекомендовали «забыть» сеть и подключиться снова на всех устройствах.

Также на смартфонах я отключил функцию использования подменного MAC адреса.

Дополнительно менял MTU на 1400.

 

Текущая ситуация:

Загрузка идет чуть лучше, звонки в мессенджерах по-прежнему с плохой слышимостью, но все же можно говорить. Смартфоны с диапазоном 2.4 GHz больше не отключаются. Но к исходному состоянию возврата не произошло.

Ниже выдержка из лога событий для ПК-десктопа, который является самым активным потребителем трафика. Для себя я сразу отметил событие, когда  MAC десктопа XX:XX:XX:XX:9b:67 переассоциируется с МАС 52:ff:20:89:96:4e, это первая строка, потом встречается еще раз, это не MAC одного из клиентов, проверено.

Подскажите, пожалуйста, куда копать и на что обратить внимание, чтобы восстановить нормальную работ WiFi.

Заранее Спасибо!

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had re-associated from 52:ff:20:89:96:4e.

Июл 9 10:43:00 ndm

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) set key done in WPA2/WPA2PSK.

Июл 9 10:43:01 ndhcps

DHCPDISCOVER received for 192.168.1.12 from XX:XX:XX:XX:9b:67.

Июл 9 10:43:01 ndhcps

making OFFER of 192.168.1.12 to XX:XX:XX:XX:9b:67.

Июл 9 10:43:01 ndhcps

DHCPREQUEST received (STATE_SELECTING) for 192.168.1.12 from XX:XX:XX:XX:9b:67.

Июл 9 10:43:02 ndhcps

sending ACK of 192.168.1.12 to XX:XX:XX:XX:9b:67.

Июл 9 10:43:12 ndm

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had deauthenticated by STA (reason: unspecified).

Июл 9 10:43:12 ndm

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had re-associated from 52:ff:20:89:96:4e.

Июл 9 10:43:13 ndm

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) set key done in WPA2/WPA2PSK.

Июл 9 10:43:13 ndhcps

DHCPREQUEST received (STATE_INIT) for 192.168.1.12 from XX:XX:XX:XX:9b:67.

Июл 9 10:43:13 ndhcps

sending ACK of 192.168.1.12 to XX:XX:XX:XX:9b:67.

Июл 9 10:43:28 ndm

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had deauthenticated by STA (reason: unspecified).

Июл 9 10:43:32 ndm

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had associated.

Июл 9 10:43:32 ndm

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) set key done in WPA2/WPA2PSK.

Июл 9 10:43:32 ndhcps

DHCPREQUEST received (STATE_INIT) for 192.168.1.12 from XX:XX:XX:XX:9b:67.

Июл 9 10:43:33 ndhcps

sending ACK of 192.168.1.12 to XX:XX:XX:XX:9b:67.

Июл 9 10:43:57 ndm

Network::InternetChecker: Internet access lost (status: 0x0003).

Июл 9 10:44:38 ndm

Network::InternetChecker: Internet access detected.

Июл 9 10:47:14 ndm

Link to comment
Share on other sites

26 answers to this question

Recommended Posts

  • 0
5 часов назад, Drakonru сказал:

День добрый. Создаю новую тему, так как, поискав по форуму ответ на свой вопрос, не нашел ответа или идеи или направления куда «копать».

 

Ранее уже открыл запрос в поддержку, предоставив все вводные, но полученные рекомендации не помогли.

 

Исходные данные:

 

Keenetic Giga, версия ПО 4.1.7, питание – от стабилизированного UPS, подключение к провайдеру через оптику, терминальное устройство провайдера – модем, подключенный к роутеру по Ethernet, авторизация доступа в интернет происходит на роутере по MAC. Роутер стоит на втором этаже дачного дома, так как оптика приходит со столба. Вокруг дома нет и не появилось точек доступа с мощным сигналом, которые бы могли влиять на эфир.

 

Как работало все 4 года до момента сбоя: для обоих диапазонов стоит WPA2, мощность сигнала 100%, выбор канала – авто, динамически. Для диапазона 2.4 GHz стандарт b/g/n, ширина канала 20/40 MHz. Для диапазона 5.0 GHz стандарт a/n/ac, ширина канала 20/40/80 MHz. Управление BSS-окружением 802.11k/v включено.

 

Все клиенты WiFi зарегистрированы и имеют фиксированные IP, размер пула DHCP достаточный.

 

Самый активный потребитель трафика – десктоп, стоит за деревянной стеной в 2-3 метрах от роутера, есть еще ноут, несколько смартфонов, которые, в отличии от десктопа, перемещаются по дому.

 

Есть два клиента, подключенных к роутеру по кабелю, они работают в прежнем режиме без проблем.

 

28.06.24 появилась проблема, связанная с передачей данных по WiFi, причем, на всех устройствах сразу. Открытие web страницы – не весь контент загружается сразу, либо нужно ждать, либо вручную перезагружать страницу принудительно несколько раз. Видео показывается дискретно: идет поток некоторое время, потом заметная пауза, потом снова воспроизведение, потом пауза и так далее. Голосовые звонки WhatsApp, Telegram, Discord, начинаются, но слышимость исходящая и входящая плохая, через несколько секунд после начала, например, приложение WA просит перейти в зону уверенного приема. На смартфонах только с 2.4 GHz происходило самопроизвольное отключение от сети – смартфон сеть видит, но автоматом не подключается, требуется участие пользователя.

 

Если запустить SpeedTest или другой сервис на устройстве, подключенном к WiFi, то скорость ко мне от меня соответствует заявленной, т.е. к провайдеру претензий нет. Единственный нюанс – на подключении провайдера по умолчанию MTU появляется 1500, но если попинговать с клиента, подключенного к WiFi, командой ping www.yandex.ru -f -l 1400, то выясняется, что оптимальный размер MTU, который «пролезает» без сообщения про DF – 1400.

 

 

 

Что было сделано:

 

Сначала несколько раз «открывали-закрывали капот» J Делали рестарт по питанию и для роутера и для модема провайдера.

 

Потом был открыт запрос в поддержку. Рекомендации: убрать «старые» стандарты «b» и «a» из списка поддерживаемых, зафиксировать канал в каждом диапазоне, задать выбор канала каждые 6 часов, потому что «новые устройства их могут терять», мда. Еще порекомендовали добавить порядка шести серверов DNS. После всего этого порекомендовали «забыть» сеть и подключиться снова на всех устройствах.

 

Также на смартфонах я отключил функцию использования подменного MAC адреса.

 

Дополнительно менял MTU на 1400.

 

 

 

Текущая ситуация:

 

Загрузка идет чуть лучше, звонки в мессенджерах по-прежнему с плохой слышимостью, но все же можно говорить. Смартфоны с диапазоном 2.4 GHz больше не отключаются. Но к исходному состоянию возврата не произошло.

 

Ниже выдержка из лога событий для ПК-десктопа, который является самым активным потребителем трафика. Для себя я сразу отметил событие, когда  MAC десктопа XX:XX:XX:XX:9b:67 переассоциируется с МАС 52:ff:20:89:96:4e, это первая строка, потом встречается еще раз, это не MAC одного из клиентов, проверено.

 

Подскажите, пожалуйста, куда копать и на что обратить внимание, чтобы восстановить нормальную работ WiFi.

 

Заранее Спасибо!

 

 

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had re-associated from 52:ff:20:89:96:4e.

 

Июл 9 10:43:00 ndm

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) set key done in WPA2/WPA2PSK.

 

Июл 9 10:43:01 ndhcps

 

DHCPDISCOVER received for 192.168.1.12 from XX:XX:XX:XX:9b:67.

 

Июл 9 10:43:01 ndhcps

 

making OFFER of 192.168.1.12 to XX:XX:XX:XX:9b:67.

 

Июл 9 10:43:01 ndhcps

 

DHCPREQUEST received (STATE_SELECTING) for 192.168.1.12 from XX:XX:XX:XX:9b:67.

 

Июл 9 10:43:02 ndhcps

 

sending ACK of 192.168.1.12 to XX:XX:XX:XX:9b:67.

 

Июл 9 10:43:12 ndm

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had deauthenticated by STA (reason: unspecified).

 

Июл 9 10:43:12 ndm

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had re-associated from 52:ff:20:89:96:4e.

 

Июл 9 10:43:13 ndm

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) set key done in WPA2/WPA2PSK.

 

Июл 9 10:43:13 ndhcps

 

DHCPREQUEST received (STATE_INIT) for 192.168.1.12 from XX:XX:XX:XX:9b:67.

 

Июл 9 10:43:13 ndhcps

 

sending ACK of 192.168.1.12 to XX:XX:XX:XX:9b:67.

 

Июл 9 10:43:28 ndm

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had deauthenticated by STA (reason: unspecified).

 

Июл 9 10:43:32 ndm

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had associated.

 

Июл 9 10:43:32 ndm

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) set key done in WPA2/WPA2PSK.

 

Июл 9 10:43:32 ndhcps

 

DHCPREQUEST received (STATE_INIT) for 192.168.1.12 from XX:XX:XX:XX:9b:67.

 

Июл 9 10:43:33 ndhcps

 

sending ACK of 192.168.1.12 to XX:XX:XX:XX:9b:67.

 

Июл 9 10:43:57 ndm

 

Network::InternetChecker: Internet access lost (status: 0x0003).

 

Июл 9 10:44:38 ndm

 

Network::InternetChecker: Internet access detected.

 

Июл 9 10:47:14 ndm

 

А попробуйте заменить блок питания у роутера.

Link to comment
Share on other sites

  • 0

Спасибо, попробовал подходящий блок от другого оборудования, по вольтам и амперам эквивалент. Не помогло.

Link to comment
Share on other sites

  • 0

Запускал StarTrinity CST на разных устройствах. Для Win грузится установщик со страницы по ссылке, APK для Androind почему-то не выложен по соответствующей ссылке, пришлось искать на сторонних источниках, нашел версию 2020.08.14.3 ее и использовал. Если следовать логике описания в разделе Instructions (приложенное изображение), то у меня на всех устройствах либо проблема с аппаратной частью, либо есть проблема с Провайдером. Вряд ли радио вышло из строя у всех клиентов сразу, тогда, получается, Провайдер? Но как же тогда внешний сервер speed test показывает заданные показатели загрузки ко мне от меня?

 

StarTrinityCST_090724.jpg

Link to comment
Share on other sites

  • 0
3 минуты назад, Drakonru сказал:

внешний сервер speed test показывает

... как правило не конкретно Вашу "последнюю милю", а скорость /с учётом нагрузки/ <от коммутатора Вашего провайдера до коммутатора сервера теста>.

Все провайдеры используют эту подмену, чтобы клиенты не возмущались.  Для чистоты эксперимента (теста скорости) пользуйте iperf с ПК/ноута.

Link to comment
Share on other sites

  • 0

Спасибо, попробую.

Но меня одолевают мысли о том, что проблема все же где-то в роутере. "Нутром чую, что поллитра, доказать не могу" (с) В.И. Чапаев из анекдота :)

И вот почему (ниже выдержка из лога). Сначала идет отбой регистрации по неизвестной причине для MAC XX:XX:XX:XX:9b:67, затем происходит переассоцииация с неизвестного мне МАС адреса 55:ff:20:89:96:4e, на МАС десктопа,XX:XX:XX:XX:9b:67.

И такие строки, с переассоциацией с одного и того же МАС 55:ff:20:89:96:4e на МАС всех существующих WiFi клиентов, встречаются в логе регулярно. Я просто взял десктоп в качестве примера, так как он чемпион по потреблению трафика.

Я посмотрел MAC WAN на стикере на роутере, он такой: ХХ:ХХ:ХХ:19:96:4f, то есть, не совпадает с этим неизвестным МАС 55:ff:20:89:96:4e, с которого происходит переассоциация.

МАС, по которому происходит авторизация у Провадера также другой: ХХ:ХХ:ХХ:ХХ:e7:a6.

Что за таинственный МАС 55:ff:20:89:96:4e, с которого происходит переассоциация для клиента сразу после того, как происходит событие had deauthenticated by STA (reason: unspecified) unspecified).

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had deauthenticated by STA (reason: unspecified).

 

Июл 9 10:43:12 ndm

 

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had re-associated from 52:ff:20:89:96:4e.

 

Июл 9 10:43:13 ndm

Link to comment
Share on other sites

  • 0
Posted (edited)
1 час назад, Drakonru сказал:

Что за таинственный МАС 55:ff:20:89:96:4e, с которого происходит переассоциация для клиента сразу после того, как происходит событие had deauthenticated by STA (reason: unspecified) unspecified).

Это MAC-адрес одного из WiFi-интерфейсов вашего роутера.

Посмотрите вывод команды:

show interface WifiMaster0/AccessPoint0

show interface WifiMaster1/AccessPoint0

Edited by mrGhotius
Link to comment
Share on other sites

  • 0

Спасибо. Проверил заодно еще пару интерфейсов WifiMaster для AccessPoint1, но увы, нигде нет МАС, который начинается с "55:", а вот окончание у всех четырех МАС одинаковое, как под копирку ":96:4e". Скриншоты прилагаю.

Еще заметил вот какой момент - получается, что все четыре МАС используют IPv6, в то время как от Провайдера я получаю IP через IPv4 DHCP. Забыл ранее сообщить о том, что я получаю услугу "Белый IP" для доступа из публичного Интернета и IP на подключении от Провайдера у меня фиксированный.

Также вижу MTU 1500 для всех четырех выводов команд. Как я писал ранее, без флага DF у меня пролезает 1400, может и здесь поменять?

Telnet_Logs_100724.pdf

Link to comment
Share on other sites

  • 0
8 часов назад, Drakonru сказал:

Спасибо. Проверил заодно еще пару интерфейсов WifiMaster для AccessPoint1, но увы, нигде нет МАС, который начинается с "55:", а вот окончание у всех четырех МАС одинаковое, как под копирку ":96:4e". Скриншоты прилагаю.

Так в логах у вас мак начинается с 52, откуда вы 55 взяли?

8 часов назад, Drakonru сказал:

Еще заметил вот какой момент - получается, что все четыре МАС используют IPv6

Судя по выводу команд, IPv6 вы не используете.

8 часов назад, Drakonru сказал:

Как я писал ранее, без флага DF у меня пролезает 1400

Странно, откуда у вас такой MSS, провайдер такой предоставляет?. MTU в вашем случае получается 1428

Edited by mrGhotius
Link to comment
Share on other sites

  • 0
8 часов назад, Drakonru сказал:

Спасибо. Проверил заодно еще пару интерфейсов WifiMaster для AccessPoint1, но увы, нигде нет МАС, который начинается с "55:", а вот окончание у всех четырех МАС одинаковое, как под копирку ":96:4e". Скриншоты прилагаю.

Так в логах у вас мак начинается с 52, откуда вы 55 взяли?

8 часов назад, Drakonru сказал:

Еще заметил вот какой момент - получается, что все четыре МАС используют IPv6

Судя по выводу команд, IPv6 вы не используете.

8 часов назад, Drakonru сказал:

Как я писал ранее, без флага DF у меня пролезает 1400

Странно, откуда у вас такой MSS, провайдер такой предоставляет?. MTU в вашем случае получается 1428

Edited by mrGhotius
Link to comment
Share on other sites

  • 0

Спасибо.

Да, это я погорячился, действительно, в логах работы роутера фигурирует МАС 52:ff:20:89:96:4e, это WifiMaster1/AccessPoint0, 5 Ghz диапазон.

Я не могу понять, по какой неуказанной причине происходит отключение по STA, а затем переассоциация, получается, с МАС самого интерфейса 5 GHz на МАС клиента в диапазоне 5 GHz.

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had deauthenticated by STA (reason: unspecified).

Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(XX:XX:XX:XX:9b:67) had re-associated from 52:ff:20:89:96:4e.

 

MTU на соединении от провайдера получаю 1500, размер совпадает с тем, что указан для всех интерфейсов в логах Telnet.

Это я разнонаправленно начал искать причину того, что данные стали хуже загружаться и одной из гипотез была та, что пакеты нормально не проходят, просто ping запускать смысла не было, там по умолчанию пакет маленького размера, поэтому использовал ping www.yandex.ru -f -l 1500, 1450, 1400, 1350, 1300.

 

Видимо, я не достаточно копенгаген и пока не понял, куда надо "копать".

 

 

Link to comment
Share on other sites

  • 0

Посмотрел логи, появились строки о пропадании доступа в Интернет, ранее их не было :(

Июл 10 19:50:21
 
ndm
Network::InternetChecker: Internet access lost (status: 0x0003).
Июл 10 19:51:02
 
ndm
Network::InternetChecker: Internet access detected.
Июл 10 19:53:55
 
kernel
AP 5GHz: run channel auto-switch
Июл 10 19:53:56
 
ndm
Network::Interface::Mtk::WifiMonitor: "WifiMaster0/AccessPoint0": STA(dc:ХХ:ХХ:ХХ:9b:67) had re-associated from 52:ff:20:89:96:4e.
Июл 10 19:53:58
 
ndm
Core::Syslog: last message repeated 2 times.
Июл 10 19:53:58
 
kernel
ACS result: Primary Channel 149, Min Channel Busy = 0, BW = 80
Июл 10 19:53:59
 
ndm
Network::Interface::Mtk::WifiMonitor: "WifiMaster0/AccessPoint0": STA(dc:ХХ:ХХ:ХХ:9b:67) had re-associated from 52:ff:20:89:96:4e.
Июл 10 19:54:00
 
ndm
Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(dc:ХХ:ХХ:ХХ:9b:67) had associated.
Июл 10 19:54:00
 
ndm
Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(dc:ХХ:ХХ:ХХ:9b:67) set key done in WPA2/WPA2PSK.
Июл 10 19:54:00
 
ndhcps
DHCPREQUEST received (STATE_INIT) for 192.168.1.12 from dc:ХХ:ХХ:ХХ:9b:67.
Июл 10 19:54:00
 
ndhcps
sending ACK of 192.168.1.12 to dc:ХХ:ХХ:ХХ:9b:67.

Link to comment
Share on other sites

  • 0
В 09.07.2024 в 13:46, Drakonru сказал:

Network::InternetChecker: Internet access lost (status: 0x0003).

 

Июл 9 10:44:38 ndm

 

Network::InternetChecker: Internet access detected.

Были, вот из первого сообщения, тоже хотел обратить ваше внимание на них, опередили :)

Есть возможность взять роутер и проверить у друзей/знакомых/родственников?

Link to comment
Share on other sites

  • 0

Верно, это я на радиоинтерфейс сфокусировался, видимо, излишне.

Есть где проверить, да, но быстро это сделать не получится. А меня уже готовы линчевать домашние.

Правильно ли я понимаю: проблемы с подключением от Провайдера могут влиять на работу радиоинтерфейса?

У меня небогатый опыт в области WiFi и до сего момента я жил с пониманием того, что если у клиентов радиоинтерфейса проблемы, зафиксированные в виде переподключений, то исследовать нужно радиоинтерфейс. Искать новые точки в двух диапазонах, анализировать занятые каналы и т.д.

То есть если у Провайдера проблемы, то в логе будут ошибки по соединению с Провайдером, да, но у радиоинтерфейса все должно быть штатно.

Был, правда, один случай, когда в сети WiFi точек роуминг между точками работал непредсказуемо по причине некорректно настроенного ААА оборудования, но тут вроде бы точка одна, хоть и с двумя диапазонами.

Link to comment
Share on other sites

  • 0
44 минуты назад, Drakonru сказал:

Правильно ли я понимаю: проблемы с подключением от Провайдера могут влиять на работу радиоинтерфейса?

Нет, проблемы у провайдера влияют на работу интернета в целом, но так как в логах есть сообщения о "дисконнектах" не лишним будет проверить, чтобы исключить провайдера.

По поводу WiFi. Тут, как вариант, установить на роутер(или на устройство подключенное кабелем) сервер iperf и с клиентов тестировать канал роутер-клиент.

И покажите все-таки настройки WiFi на роутере. :) 

Edited by mrGhotius
Link to comment
Share on other sites

  • 0

Отлично.

2,4ГГц:

Канал - 1, 6, 11 выберите один из этих

TX Burst - выключите

Airtime Fairness - включите

5ГГц:

Канал - 36, 40, 44 выберите один из этих

TX Burst - выключите

Airtime Fairness - включите

Бесшовный роуминг - Использовать для 2,4 и 5ГГц

Управление BSS - выключите

Также в настройках DHCP время аренды - 172800

И если установлен компонент Wi-Fi системы, отключите беспроводную транспортную сеть.

Edited by mrGhotius
Link to comment
Share on other sites

  • 0
7 минут назад, Drakonru сказал:

Спасибо, применил. Сколько наблюдать? Сейчас почти все клиенты WiFi активно работают.

Не знаю, наблюдайте :) Я привел вам оптимальные (на мой взгляд) настройки, вряд ли будет смысл возвращать все назад. И, кстати, при активной работе всех клиентов интернет канал в полку не упирается?

Link to comment
Share on other sites

  • 0

Пока таких не было оказий. Тем временем в логе две строки появилось, красным шрифтом:

 

ndm
Core::Scgi::Session: unsupported method "POST" for "/goform/set_LimitClient_cfg".

 
mtkiappd
L2 broadcast failed: network is down.

Link to comment
Share on other sites

  • 0
12 минуты назад, Drakonru сказал:

mtkiappd
L2 broadcast failed: network is down.

Хм, это лучше пусть представители Keenetic прокомментируют. Вот что есть на форуме по этой ошибке.

Link to comment
Share on other sites

  • 0
31 минуту назад, Drakonru сказал:

Спасибо, применил. Сколько наблюдать?

вам бы с вашим кейсом, знаниями и релизным ПО в ТП, а не тут пытаться решить проблему.

Link to comment
Share on other sites

  • 0
Только что, Drakonru сказал:

Пробовал в ТП, поэтому и пришел сюда за советами.

ТП - последняя инстанция, и там спецы посерьезнее нас, школьников, будут)

Link to comment
Share on other sites

  • 0

Увы, раньше они оправдывали ожидания, это не первый мой опыт общения с ТП, еще со времен Zyxel.

"Крайний раз", как сейчас пишут, имел место быть в 2019 и пока проблему не решили, шла переписка.

Мда, спецы в ТП трех Провайдеров, с которыми приходится общаться по вопросам предоставляемых услуг, в том же направлении квалификацию поменяли.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...