Andrew Voronkov

Подскажите, на некоторых устройствах, например, Start - через расширение не добавляется канал Delta - так и задумано или это баг? На ультра2, например, добавляется без проблем в списке и выбирается, а вот на старте - дельты нет в списке вообще.

В последней бете ничего не изменилось: Июн 21 22:27:04 ndnproxy query section count mismatch, got 0 (expect 1), ignore. Июн 21 22:43:29 ndnproxy Core::Syslog: last message repeated 1165 times.

Дело точно не в PPPoE - на другой локации на Ультра2 та же самая проблема, а там резерв usb модем..

На вчерашней бете 3.8.0-3 все равно та же самая красная ошибка. Роутер Keenetic Peak. Куда копать? Июн 11 19:08:48 ndnproxy query section count mismatch, got 0 (expect 1), ignore. Июн 11 19:17:53 ndnproxy Core::Syslog: last message repeated 562 times.

Я вот тоже не понял, к чему мне его посоветовали ))

Очень давно об этом прошу. Иногда резервный канал падает (за неоплату, например), а об этом узнаешь, только он вдруг нужен, а его нет!

Ещё очень не хватает функционала уведомлений, если устройства нет в сети ХХ минут. Сейчас получаю пуши по критически важным устройствам по их отключению-подключению. Но некоторые из них иногда отключаются и подключаются обратно за 2-3 секунды - а это два пуша подряд. Вот если бы можно было получать уведомление, если конкретного устройства нет в сети больше 30 секунд, например - было бы отлично.

Подтверждаю. Приложение больше не глючит, красные строки пропали.

Аналогично сразу после установки бета5 посыпалось каждую минуту Network::Interface::Base: unable to find (empty) as "Network::Interface::Base".

Нет, у меня основное подключение - витая пара, резерв тоже витая пара, второй резерв wisp. Sfp вообще не использую.

Мы как раз в теме форума для такого "шума", а правильно он называется багрепорт. Я не бете, которая относительно скоро пойдёт в релиз. Если проблему не локализовать в бете, она раскатается на все Пики. Чуть уточню. Они не совсем продолжают работать, они подключаются, получают ip, но без доступа к интернету и даже к локальной сети. Я полагаю, в кинетике далеко не один сторож - и вариантов их взаимодействия помимо перезагрузки роутера - великое множество, в том числе передергивать определенный интерфейс, который подвис. Но этого не происходит. А при наличии у меня двух резервных каналов (второй проводной и wisp) - при пропадании доступа в интернет кинетик в момент зависания никуда не переключается. Возможно, это тоже косвенно говорит о том, какой модуль зависает. Вот поэтому мне вдвойне странно, что саппорт не возбудился на такую проблему..

Скажите, а вы сначала отвечаете, а потом читаете? Кроме того, у меня в профиле указаны с десяток кинетиков. Опять же, в исходном посте указано: на месте пика пять лет стояла ультра2. За последний год сеть не менялась. Конфиг с ультры на пик портировали сотрудники кинетика. Н ультре не было ни разу такого за все годы. Если верить FAQ Кинетика (статья "Что такое Watchdog и как он работает в Keenetic") - в природе не существует случая, когда исправный роутер может зависнуть наглухо. И я склонен верить FAQ'у - из любой даже самой критической ситуации роутер должен вытягиваться вотчдогом. Я даже согласен на принудительный ребут как крайний случай - но не полное зависание. Что-то мне кажется мне с моими 60-80 клиентами на это придется потратить ни один месяц. Проще вернуться на ультру2. П.С. Вот выдержка из статьи: Так что с уверенностью можно сказать, что если если вам каким-то чудом удалось ввести Кинетик в такое состояние, что ядро перестало успевать сбрасывать счетчик сторожевого таймера (а это также означает, что Кинетик перестал успевать выполнять свои первоочередные задачи), то он сам выйдет из этого состояния перезагрузкой (временной интервал составляет не более 15 секунд от зависания до перезагрузки). А если вы обнаружили Кинетик полностью повисшим, и не реагирующим ни на что, кроме отключения питания, то увы, но мы скорее склонны подозревать, что он сломан аппаратно.

Подтверждаю, в бета3 исправлено.

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

Добрый день. Уже несколько месяцев являюсь обладателем роутера Keenetic Peak. За последний месяц роутер дважды завис так, что восстановить работоспособность получалось только выдергиванием блока питания из сети. До этого ждал минут 10, пытался подключиться по telnet и тд - всё безрезультатно. Тикет в поддержке #560431 - но сотрудник считает, что это нормальное поведение роутера и виновата моя сеть(!?!?). Другой сотрудник Кинетика мне сообщил, что в бета2 были допилены вотчдоги. Не очень помню хронологию, но на бета1 вроде Peak ни разу не зависал у меня, началось с бета2 и продолжается на бета3. В FAQ Кинетика по поводу вотчдогов написано, что роутер невозможно ввести в состояние полного зависания и если такое случилось, то проблема 100% с железом роутера. Почему тогда мне пытаются внушить, что проблема с моей сетью - не очень понятно. Выглядит зависание так. Неожиданно пропадает интернет. Проводные клиенты пишут "без доступа к сети интернет". При переподключении появляется Неопознанная сеть. Беспроводные тоже без интернета, но при отключении-подключении они получают ip без проблем, но доступа к сети нет. Пинг по беспроводной сети идёт, по проводной - не находит узел. Телнет доступа нет ни в одном варианте. Индикация на самом роутере - светодиод питания горит, беспроводной - мигает как обычно. Диод, отвечающий за интернет - не горит. Вебморда недоступна. После перезагрузки по питанию - всё начинает работать как обычно. ultra2 ровно на месте этого роутера и в той же сети (с той же конфигурацией (она портирована саппортом Кинетика), а сама сеть не менялась уже год) работала без проблем годами - а Peak виснет наглухо уже второй раз за месяц. Не знаю, связано ли это как-то, но в журнале время от времени стали появляться красные строчки, раньше их точно не было никогда: nf_conntrack: unable to save third interface 20, already has 24 and 8 (protonum 17) Селфтест и конфиг есть в саппорте, скрытыми выложил селфтест и лог сюда. На данный момент мне посоветовали в саппорте выполнить no interface GigabitEthernet0 flowcontrol и ждать, когда роутер зависнет в следующий раз, после чего отключать по одному проводные клиенты в надежде, что он оживёт. Если это не поможет, то роутер под замену. Вот только не факт, что я в момент следующего зависания окажусь рядом - то есть сначала сеть в загородном доме на 60-70 клиентов (камеры, охрана, умный дом, сервер и тд) полностью упадёт по вине роутера за 16 тысяч, а мне потом нужно к ней быстро ехать, диагностировать и восстанавливать. Так себе приключение. Не очень вяжется эта рекомендация с официальной позицией Кинетика, что ввести его в полное зависание невозможно... Буду рад любым рекомендациям. Почему-то саппорт Кинетика даже совершенно не жаждет мои селфтесты, сконцентрировавшись на выводе, что роутер виснет наглухо из-за моей сети.

Приветствую. До последней беты устройства в Списке устройств - при сортировке по алфавиту размещались так: A-Z-А-Я. Теперь по непонятной причине сначала по такому принципу ранжируются устройства, подключенные по wifi, а потом после них заново ранжируются устройства, подключенные по проводу. То есть сначала беспроводные A-Z-А-Я, потом после них идут проводные A-Z-А-Я. Это нелогично и довольно неудобно. Прошу исправить.

Проблему заметил давно, на бете она все еще существует. Пинг чек у меня пингует ya.ru и при определенном кол-ве неудач переключает канал на резерв. Так вот нередко замечаю, что если с одного из клиентов сильно забить канала - например, включить 4k видео онлайн + что-то скачивать и тд. - то пингчек начинает иногда произвольно переключать источник на резерв. То есть получается, что канал забивается настолько, что пинг-чеку не хватает ширины для проверки доступности интернета при том, что с интернетом всё прекрасно. Мне кажется, это неправильно, под пинг-чек должен всегда динамически выделяться микро-кусочек канала, чтобы такого не происходило. Не зависит и от роутера ситуация - после перехода с ультра2 на peak - ситуация сохранилась вообще без изменений. Ну и чтобы не вставать дважды - прошу подумать над введением не только кастомного кол-ва неудачных пингов для перехода на резерв, но и кол-во удачных пингов для возвращения на основной канал. Потому что при минутной проблеме на основном канале - роутре переключается на несколько секунд на резерв - и почти сразу обратно. Многие, например, iptv провайдеры - за такое блокируют. Я бы лучше посидел минут 5 на резерве, даже если основной канал ожил, чем наблюдать вот такие судорожные перепрыгивания.

Я в саппорт отправил и стартап конфиг, и диагностику. Сюда тоже приложить? Запрос #553247

Все остальные ресурсы - кроме iptv - работают идеально, вплоть до онлайн просмотра фильмов в 4k с битрейтом под 50. На резерв тоже не переулючается. Провайдер ошибок на портах не видит. Продолжаю подозревать кривую работу приоритетов, ибо совпало по времени. Да и это были первые изменения в настройках роутера за неделю - до этого год все работало идеально.

Добрый день. Последняя бета 3.7. Вчера решил выставить приоритеты клиентам в сети - поставил единичку паре телевизоров с iptv, серверу видеонаблюдения и тд. После этого стали дико буферить все провайдеры iptv - причем на любом подключении (отключал основной канал, переключал на резерв через wisp и тд). Пробовал разных iptv провайдеров. То есть смотреть невозможно - буферизация каждые 5-10 секунд, как будто не хватает скорости. До этого годами всё работало идеально. При этом соединение 100мбит по проводу, вариант с wisp вообще 150мбит. Спидтест работает нормально, все сайты открываются штатно, проблем со скоростью нет - только вот буферит iptv. Убрал все приоритеты - ситуация вообще не изменилась. Перезагружал все роутеры в вайфай системе, клиентов - делал все обычные для такой ситуации манипуляции. У меня создаётся впечатление, что выставление приоритетов повредило какие-то настройки, связанные с iptv - и ручное восстановление приоритетов на дефолт не подчистило все хвосты. Вчера вечером параллельно с проблемами с iptv появлялись иногда еще и такие строчки, то есть кинетик терял своё облако: Июл 28 21:53:00 ndm Cloud::Agent: can not connect to the cloud server. Июл 28 21:58:19 ndm Core::Syslog: last message repeated 4 times. Июл 28 21:58:22 ndm Core::Ndss: [4296] HTTP error: 502 (Bad Gateway). При необходимости могу прикрепить скрытыми селфтест и стартап-конфиг, если потребуется.

Я правильно понял текущую ситуацию?: По команде more temp:/ndnproxymain.stat я вижу вообще все днс, используемые в роутере, отранжированные по скорости отклика. Но в рамках конкретного активного соединения используются именно те днс, которые привязаны к этому соединению (например, это видно на главной странице под конкретным соединением), но отранжированные по порядку, который видно по команде выше. То есть в соединение мтс днс от соединения мегафон попасть никак не могут, если я сам их туда не привяжу. И при этом ранжирование по отклику работает и в рамках конкретного соединения - днс'ы пингуются конкретно через это активное соединение. Я правильно понял?

То есть то, что я прописываю в разделе Интернет-фильтр - серверы DNS - и там делаю привязку конкретных днс к конкретным соединениям - это не действует? Или я неправильно вас понял? По идее судя по этой настройке днс от мтс, например, никак не может использоваться для мегафона. "Любое" подключение - только для 8.8.4.4 и 77.88.8.8

Нет планов отображать на главной днс всё же с учётом их реального ранжирования? А с привязкой к используемым провайдерам это нигде не посмотреть? Они тут ранжируются все в кучу, а потом используются только те, которые относятся к конкретному соединению, так? Просто я сейчас сижу на резервном wisp от мегафона - но у меня картина вот такая (то есть днс от мегафона с рангом 3 и ниже, а с рангом 1 вообще днс от другого резерва - мтс): { "message": [ "# ndnproxy statistics file", "", "Total incoming requests: 32006", "Proxy requests sent: 63732", "Cache hits ratio: 0.321 (10277)", "Memory usage: 54.06K", "", "DNS Servers", "", " Ip Port R.Sent A.Rcvd NX.Rcvd Med.Resp Avg.Resp Rank ", " 192.168.3.1 53 147 58 67 50ms 100ms 5 ", " 8.8.4.4 53 87 0 47 43ms 46ms 1 ", " 8.8.8.8 53 3134 1475 68 46ms 54ms 5 ", " 10.77.48.115 53 7557 0 0 0ms 0ms 3 ", " 10.97.52.69 53 12937 12402 86 89ms 177ms 4 ", " 77.88.8.8 53 9188 7708 81 35ms 34ms 8 ", " 178.215.65.250 53 7559 0 0 0ms 0ms 4 ", " 212.188.8.10 53 8004 0 0 0ms 0ms 2 ", " 213.108.16.3 53 7557 0 0 0ms 0ms 3 ", " 213.87.142.85 53 7562 0 0 0ms 0ms 1 ", "" ], "prompt": "(config)"

Речь исключительно о визуальном отображении на главной странице, как я понимаю? Почему тогда иногда при падении провайдерских днс в этом списке на 3.6 наверх поднимались гугл и яндекс днс? И вообще порядок днс время от времени менялся - даже два провайдерских днс тасовались между собой иногда. А как же визуальный мониторинг доступности днс? Нет правильного отображения? Само ранжирование то осталось? То есть роутер время от времени всё ещё определяет, какой днс быстрее - и использует именно его, я правильно понял? А на главной днс отображаются по неведомой логике, не связанной с реальным положением дел. Так? Почему же тогда у меня теперь используются яндекс днс время от времени, хотя раньше всегда использовались провайдерские. Логика ранжирования и использования днс точно не поменялась с переходом с 3.6 на 3.7?

Если я не ошибаюсь (а я почти уверен), то на предыдущих прошивках (3.6 в том числе) на главной странице (системный монитор) под каждым соединением dns'ы писались в столбик в порядке их использования. То есть роутер ранжировал dns по отклику - и в порядке скорости отклика он их и отображал под соединениями (в 99% случаев провайдерские днс были в верху списка). Раньше я по этому списку определял, когда провайдерские днс чувствовали себя плохо - наверх поднимался яндексовский или гугловский, я звонил провайдеру - и они лечили свои днс, ситуация исправлялась. Сейчас в ТГ группе кинетика меня убеждают, что такого ранжирования никогда не было. Вопросы: 1. Было ли раньше ранжирование днс с отображением на главной странице. Если да - то куда оно делось в 3.7 - сейчас днс расположены в одинаковом порядке для всех трех провайдеров - первыми идут яндекс и гугл, а родные провайдерские - в конце списка. Принцип сортировки - непонятный. 2. Сохранился ли в 3.7 вообще принцип ранжирования днс? У меня такое ощущение, что роутер стал использовать днс именно по очередности из списка (вместо выбора днс по скорости отклика) - при очевидно более быстрых провайдерских днс - кинетик теперь постоянно использует яндекс (первый сейчас в списке) или гугл (второй в списке). А провайдерские игнорирует по всем соединениям - проверял через whatsmydnsserver.com/ - поэтому наблюдаю проблемы с доступом к некоторым ресурсам, включая appstore. UPD. Зашел на соседские роутеры на 3.6 - там днс прекрасно ранжируются по отклику - и, что логично, первыми в списке идут провайдерские, а гугл и яндекс - в конце. Аналогично и используютсяя у соседей днс - в соответствии с этим списком. Первый скриншот - отображение и использование днс на 3.7 у меня, второй и третий скриншот - отображение и использование днс на 3.6 у соседей. 178.. и 213.. - это провайдерские.