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, потом Провайдер что-то поменял и в итоге одно на другое наложилось и одни косяки встретились с другими косяками на Проде

Здравствуйте. Тоже сейчас исследую вопрос потери и обнаружения интернета роутером KN-1010 согласно логам. Подключение к провайдеру: из порта Ethernet GPON модема в WAN порт роутера. Есть услуга по предоставлению Статического IP - 213.141.130.88. Я правильно понимаю, что в файле self-test таблица соединений содержит вот такие строки ниже и [UNREPLIED] появляется тогда, когда запрос на соединение был отправлен, но не подтвержден? Массовому появлению сообщений о потере и обнаружении вроде не предшествовали аварии у провайдера и обновления FW. И что еще меня смущает - не смотря на множество таких парных сообщений, в Системном Мониторе исправно идет отсчет времени подключения, не взирая на потери/обнаружения, между которыми проходит порой больше минуты. Заранее спасибо. TCP 6 src=192.168.1.2 dst=192.168.1.1 sport=44320 dport=1900 packets=7 bytes=426 src=192.168.1.1 dst=192.168.1.2 sport=1900 dport=44320 packets=5 bytes=3217 [ASSURED] mark=0x00000000 ndmmark=0x00 ifl=32 mac=00:62:6e:4e:21:5d swan TCP 6 src=192.168.1.3 dst=77.74.181.34 sport=64270 dport=443 packets=5 bytes=205 src=77.74.181.34 dst=213.141.130.88 sport=443 dport=64270 packets=0 bytes=0 [UNREPLIED] [FASTNAT] mark=0x00000000 ndmmark=0x00 ifl=32 ifw=10 mac=28:ee:52:43:e2:f7 swan TCP 6 src=192.168.1.37 dst=52.155.91.177 sport=51241 dport=443 packets=1 bytes=52 src=52.155.91.177 dst=213.141.130.88 sport=443 dport=51241 packets=0 bytes=0 [UNREPLIED] [FASTNAT] mark=0x00000000 ndmmark=0x00 ifl=32 ifw=10 mac=d0:c6:37:c1:d2:c5 swan

Увы, раньше они оправдывали ожидания, это не первый мой опыт общения с ТП, еще со времен Zyxel. "Крайний раз", как сейчас пишут, имел место быть в 2019 и пока проблему не решили, шла переписка. Мда, спецы в ТП трех Провайдеров, с которыми приходится общаться по вопросам предоставляемых услуг, в том же направлении квалификацию поменяли.

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

Пока таких не было оказий. Тем временем в логе две строки появилось, красным шрифтом: ndm Core::Scgi::Session: unsupported method "POST" for "/goform/set_LimitClient_cfg". mtkiappd L2 broadcast failed: network is down.

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

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

Верно, это я на радиоинтерфейс сфокусировался, видимо, излишне. Есть где проверить, да, но быстро это сделать не получится. А меня уже готовы линчевать домашние. Правильно ли я понимаю: проблемы с подключением от Провайдера могут влиять на работу радиоинтерфейса? У меня небогатый опыт в области WiFi и до сего момента я жил с пониманием того, что если у клиентов радиоинтерфейса проблемы, зафиксированные в виде переподключений, то исследовать нужно радиоинтерфейс. Искать новые точки в двух диапазонах, анализировать занятые каналы и т.д. То есть если у Провайдера проблемы, то в логе будут ошибки по соединению с Провайдером, да, но у радиоинтерфейса все должно быть штатно. Был, правда, один случай, когда в сети WiFi точек роуминг между точками работал непредсказуемо по причине некорректно настроенного ААА оборудования, но тут вроде бы точка одна, хоть и с двумя диапазонами.

Посмотрел логи, появились строки о пропадании доступа в Интернет, ранее их не было Июл 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.

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

Спасибо. Проверил заодно еще пару интерфейсов WifiMaster для AccessPoint1, но увы, нигде нет МАС, который начинается с "55:", а вот окончание у всех четырех МАС одинаковое, как под копирку ":96:4e". Скриншоты прилагаю. Еще заметил вот какой момент - получается, что все четыре МАС используют IPv6, в то время как от Провайдера я получаю IP через IPv4 DHCP. Забыл ранее сообщить о том, что я получаю услугу "Белый IP" для доступа из публичного Интернета и IP на подключении от Провайдера у меня фиксированный. Также вижу MTU 1500 для всех четырех выводов команд. Как я писал ранее, без флага DF у меня пролезает 1400, может и здесь поменять? Telnet_Logs_100724.pdf

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

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

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

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

День добрый. Создаю новую тему, так как, поискав по форуму ответ на свой вопрос, не нашел ответа или идеи или направления куда «копать». Ранее уже открыл запрос в поддержку, предоставив все вводные, но полученные рекомендации не помогли. Исходные данные: 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