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 показывает заданные показатели загрузки ко мне от меня?

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

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