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

[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

[mrGhotius]

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

 

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

[Drakonru]

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

[mrGhotius]

Попробуйте эту программу. Может подскажет куда копать.

[Drakonru]

Спасибо, проверю эфир. Судя по описанию, полезный инструмент.

[Drakonru]

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

 

[KeyYerS]

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

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

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

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

[Drakonru]

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

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

И вот почему (ниже выдержка из лога). Сначала идет отбой регистрации по неизвестной причине для 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

[mrGhotius]

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 July 9 by mrGhotius

[Drakonru]

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

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

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

Telnet_Logs_100724.pdf

[mrGhotius]

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

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

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

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

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

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

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

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

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

Edited July 10 by mrGhotius

[mrGhotius]

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

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

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

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

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

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

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

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

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

Edited July 10 by mrGhotius

[Drakonru]

Спасибо.

Да, это я погорячился, действительно, в логах работы роутера фигурирует МАС 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.

 

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

 

 

[Drakonru]

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

Июл 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.

[mrGhotius]

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

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

 

Июл 9 10:44:38 ndm

 

Network::InternetChecker: Internet access detected.

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

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

[Drakonru]

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

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

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

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

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

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

[mrGhotius]

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

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

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

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

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

Edited July 10 by mrGhotius

[Drakonru]

Да, конечно, JPG почему-то не грузит форма сообщения, поэтому опять PDF и то со второго захода, что необычно.

WiFi_Settings_100724.pdf

[mrGhotius]

Отлично.

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 July 10 by mrGhotius

[Drakonru]

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

[mrGhotius]

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

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

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

[Drakonru]

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

 

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

 
mtkiappd
L2 broadcast failed: network is down.

[mrGhotius]

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

mtkiappd
L2 broadcast failed: network is down.

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

[bigpu]

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

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

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

[Drakonru]

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

[bigpu]

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

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

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

[Drakonru]

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

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

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

[Drakonru]

Хочу поблагодарить за советы и рекомендации.

Их было гораздо больше, чем одна рекомендация от поддержки Keenetic прописать несколько дополнительных DNS.

В результате многофакторного эксперимента вот что помогло исправить ситуацию:

По радиочасти - добыл 4.1.6, поставил, проблемы ушли.

По вопросу потери и нахождения интернета для соединения с Провайдером:

ndm
Network::InternetChecker: Internet access lost (status: 0x0003).
Июл 10 19:51:02
 
ndm
Network::InternetChecker: Internet access detected.
Июл 10 19:53:55

Приезжал спец от Провайдера, сделал несколько базовых тестов на подключенном к GPON модему "напрямую" ПК, в том числе просмотр видео 4К, ping, tracert и так далее, все работало штатно.

В итоге через Telnet отключил проверку гейтвея, так как в ряде зарубежных форумов нашел ссылки на подобные проблемы, которые могут возникнуть при недекларируемых изменениях на стороне провайдера именно в 2024 году, которые приводят к тому, что такая проверка с чем-то конфликтует и соединение в итоге забивается служебными пакетами и интернет еле-еле работает. Больше деталей не сообщу, за что купил, за то продаю, мне помогло.

easyconfig check exclude-gateway

system configaration save

 

Еще на форуме Keenetic и на тех же форумах, кроме отключения проверки гейтвея, советуют включить вот такую фичу для WAN порта, типа новомодную и зеленую, правда, редко встречающуюся:

interface GigabitEthernet1/0
green-ethernet
exit
system configuration save

Это я про запас оставил, мало ли что.

Как в анекдоте про обучение Василия Ивановича в военной академии математике "нутром чую, что поллитра, доказать не могу", могу только предполагать, что получил 4.1.7, потом Провайдер что-то поменял и в итоге одно на другое наложилось и одни косяки встретились с другими косяками на Проде