Jump to content

Andrew Voronkov

Forum Members
  • Posts

    344
  • Joined

  • Last visited

Everything posted by Andrew Voronkov

  1. Добрый день. Уже несколько месяцев являюсь обладателем роутера 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 тысяч, а мне потом нужно к ней быстро ехать, диагностировать и восстанавливать. Так себе приключение. Не очень вяжется эта рекомендация с официальной позицией Кинетика, что ввести его в полное зависание невозможно... Буду рад любым рекомендациям. Почему-то саппорт Кинетика даже совершенно не жаждет мои селфтесты, сконцентрировавшись на выводе, что роутер виснет наглухо из-за моей сети.
  2. Приветствую. До последней беты устройства в Списке устройств - при сортировке по алфавиту размещались так: A-Z-А-Я. Теперь по непонятной причине сначала по такому принципу ранжируются устройства, подключенные по wifi, а потом после них заново ранжируются устройства, подключенные по проводу. То есть сначала беспроводные A-Z-А-Я, потом после них идут проводные A-Z-А-Я. Это нелогично и довольно неудобно. Прошу исправить.
  3. Проблему заметил давно, на бете она все еще существует. Пинг чек у меня пингует ya.ru и при определенном кол-ве неудач переключает канал на резерв. Так вот нередко замечаю, что если с одного из клиентов сильно забить канала - например, включить 4k видео онлайн + что-то скачивать и тд. - то пингчек начинает иногда произвольно переключать источник на резерв. То есть получается, что канал забивается настолько, что пинг-чеку не хватает ширины для проверки доступности интернета при том, что с интернетом всё прекрасно. Мне кажется, это неправильно, под пинг-чек должен всегда динамически выделяться микро-кусочек канала, чтобы такого не происходило. Не зависит и от роутера ситуация - после перехода с ультра2 на peak - ситуация сохранилась вообще без изменений. Ну и чтобы не вставать дважды - прошу подумать над введением не только кастомного кол-ва неудачных пингов для перехода на резерв, но и кол-во удачных пингов для возвращения на основной канал. Потому что при минутной проблеме на основном канале - роутре переключается на несколько секунд на резерв - и почти сразу обратно. Многие, например, iptv провайдеры - за такое блокируют. Я бы лучше посидел минут 5 на резерве, даже если основной канал ожил, чем наблюдать вот такие судорожные перепрыгивания.
  4. Я в саппорт отправил и стартап конфиг, и диагностику. Сюда тоже приложить? Запрос #553247
  5. Все остальные ресурсы - кроме iptv - работают идеально, вплоть до онлайн просмотра фильмов в 4k с битрейтом под 50. На резерв тоже не переулючается. Провайдер ошибок на портах не видит. Продолжаю подозревать кривую работу приоритетов, ибо совпало по времени. Да и это были первые изменения в настройках роутера за неделю - до этого год все работало идеально.
  6. Добрый день. Последняя бета 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). При необходимости могу прикрепить скрытыми селфтест и стартап-конфиг, если потребуется.
  7. Я правильно понял текущую ситуацию?: По команде more temp:/ndnproxymain.stat я вижу вообще все днс, используемые в роутере, отранжированные по скорости отклика. Но в рамках конкретного активного соединения используются именно те днс, которые привязаны к этому соединению (например, это видно на главной странице под конкретным соединением), но отранжированные по порядку, который видно по команде выше. То есть в соединение мтс днс от соединения мегафон попасть никак не могут, если я сам их туда не привяжу. И при этом ранжирование по отклику работает и в рамках конкретного соединения - днс'ы пингуются конкретно через это активное соединение. Я правильно понял?
  8. То есть то, что я прописываю в разделе Интернет-фильтр - серверы DNS - и там делаю привязку конкретных днс к конкретным соединениям - это не действует? Или я неправильно вас понял? По идее судя по этой настройке днс от мтс, например, никак не может использоваться для мегафона. "Любое" подключение - только для 8.8.4.4 и 77.88.8.8
  9. Нет планов отображать на главной днс всё же с учётом их реального ранжирования? А с привязкой к используемым провайдерам это нигде не посмотреть? Они тут ранжируются все в кучу, а потом используются только те, которые относятся к конкретному соединению, так? Просто я сейчас сижу на резервном 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)"
  10. Речь исключительно о визуальном отображении на главной странице, как я понимаю? Почему тогда иногда при падении провайдерских днс в этом списке на 3.6 наверх поднимались гугл и яндекс днс? И вообще порядок днс время от времени менялся - даже два провайдерских днс тасовались между собой иногда. А как же визуальный мониторинг доступности днс? Нет правильного отображения? Само ранжирование то осталось? То есть роутер время от времени всё ещё определяет, какой днс быстрее - и использует именно его, я правильно понял? А на главной днс отображаются по неведомой логике, не связанной с реальным положением дел. Так? Почему же тогда у меня теперь используются яндекс днс время от времени, хотя раньше всегда использовались провайдерские. Логика ранжирования и использования днс точно не поменялась с переходом с 3.6 на 3.7?
  11. Если я не ошибаюсь (а я почти уверен), то на предыдущих прошивках (3.6 в том числе) на главной странице (системный монитор) под каждым соединением dns'ы писались в столбик в порядке их использования. То есть роутер ранжировал dns по отклику - и в порядке скорости отклика он их и отображал под соединениями (в 99% случаев провайдерские днс были в верху списка). Раньше я по этому списку определял, когда провайдерские днс чувствовали себя плохо - наверх поднимался яндексовский или гугловский, я звонил провайдеру - и они лечили свои днс, ситуация исправлялась. Сейчас в ТГ группе кинетика меня убеждают, что такого ранжирования никогда не было. Вопросы: 1. Было ли раньше ранжирование днс с отображением на главной странице. Если да - то куда оно делось в 3.7 - сейчас днс расположены в одинаковом порядке для всех трех провайдеров - первыми идут яндекс и гугл, а родные провайдерские - в конце списка. Принцип сортировки - непонятный. 2. Сохранился ли в 3.7 вообще принцип ранжирования днс? У меня такое ощущение, что роутер стал использовать днс именно по очередности из списка (вместо выбора днс по скорости отклика) - при очевидно более быстрых провайдерских днс - кинетик теперь постоянно использует яндекс (первый сейчас в списке) или гугл (второй в списке). А провайдерские игнорирует по всем соединениям - проверял через whatsmydnsserver.com/ - поэтому наблюдаю проблемы с доступом к некоторым ресурсам, включая appstore. UPD. Зашел на соседские роутеры на 3.6 - там днс прекрасно ранжируются по отклику - и, что логично, первыми в списке идут провайдерские, а гугл и яндекс - в конце. Аналогично и используютсяя у соседей днс - в соответствии с этим списком. Первый скриншот - отображение и использование днс на 3.7 у меня, второй и третий скриншот - отображение и использование днс на 3.6 у соседей. 178.. и 213.. - это провайдерские.
  12. Просто я никогда не встречал сортировки, чувствительной к размеру первой буквы. А есть все яблочные устройства переназывать с прописных букв - получается хрень типа IPhone (потому что заглавная i один в один как строчная l). Ну это так, в формате багрепорта, жить не очень мешает.
  13. Приветствую. Уже много месяцев в бете при сортировке списка клиентов по алфавиту - вижу проблему. Связана она с тем, что система зачем-то учитывает регистр. То есть сначала идут устройства по алфавиту, записанные с большой буквы (от A до Z), потом идут устройства по алфавиту с маленькой буквы (от a до z), а потом идут имена на русском. В итоге все клиенты с названиями типа iPhone, iPad и тд - оказываются не по алфавиту, а почти в конце списка после всех устройств A-Z. Прошу исправить, если это баг, а не фича.
  14. А вы правильно поняли настройку? В ней, как я понимаю, надо убирать запрещённые, а не отмечать разрешенные узлы.
  15. Очень нужна эта фича, при большом количестве клиентов, особенно если это умный дом - попадаются такие, которые начинают постоянно прыгать между ТД. Привязка к конкретной ТД - оооооочен бы помогла. Даже странно, что в супер продуманном Кинетике этого еще нет (((
  16. Приветствую. Сейчас столкнулся с ситуацией. Роутер на основном источнике интернета, всё нормально. Зашел в веб-интерфейс, а резерв wisp светится красным, что нет интернета. Захожу на модем, дающий резерв - а он почему-то не может соединиться с мегафоном. Перезагрузил, заработало. Вотчдога у модема нет, к сожалению. Так вот я подумал, что был бы очень удобен функционал уведомлений (пуш, тг и тд) средствами прошивки - с информацией, что резерв ушел в офлайн. Поможет предотвратить многие сложности на объектах, требующих бесперебойный интернет.
  17. Оно не работает уже полгода минимум. Так что чуть-чуть можно и подождать )
  18. Подтверждаю, время от времени валятся фантомные онлайн-офлайн. А вот уведомления о переключении канала с основного на резерв и обратно - так и не работают, что оооочень неудобно.
  19. Я бы с удовольствием показал логи, но прилечу домой только через 10 дней ) А по поводу драйвера - полагаю, дело не в нем, а в вайфай системе. У меня часть устройств, лёжа на одном месте, скачут между двумя тд почти каждые пять минут. Одно устройство при проводном подключении вообще получало адрес каждые 5 секунд (!!) с момента перехода на релиз - судя по журналу - и ни перезагрузка, ни что другое - не помогло. Это был домофон dahua. В телеграме отписывал, там нашелся человек с такой же проблемой. У него проблемной была камера nobelic. А нобелик - это суб-бренд дахуа, кстати.
  20. К сожалению, соскоки в роуминге на ios почти постоянно. Первый вечер после обновления вообще каждая (!!) ссылка в сафари вызывала задумчивость секунд на 5, потом на пару секунд вместо вайфая мигал лте, потом снова вайфай - и всё открывалось. Бс выключен, все галки в роуминге стоят. Сейчас всё получше (ничего не менял), но все равно соскоки бывают. Спидтест скачет по скорости с 5 до 70. Вообще как поставил релиз - всё стало сильно хуже со стабильностью. На последнем драфте косяки были почти незаметны, сейчас сильно мешают пользоваться.
  21. На прошлой прошивке такого соскока не было точно. Поскольку часто пользуюсь вайфаем в метро и тд - лучше дождусь исправления или буду жить с выкл бс, чем менять эту настройку на айфоне... а про лут не подскажете, что за ошибка? Или лучше тему создать?
  22. Выражается в том, что на всех айфонах иконка вайфай меняется на лте примерно 2-3 раза в минуту. Соответственно, нужно в эти 20 сек успеть открыть страницу. С включенным бс при вкл роуминге. Если выключить бс, то работает нормально относительно. Но теперь на одной из тд появилась странная ошибка, повторяющаяся раз по 200 в час: Фев 3 11:05:38 ndm kernel: mt7621_eth: unable to find 00:5a:20:50:97:d1 / VLAN 1 user address in the LUT Судя по ip - это камера, подключенная в котельной напрямую проводом к роутеру. Почему ошибка валится на тд - неясно. Почему в ошибках нет других ровно таких же камер - непонятно. Почему ошибки нет на второй идентичной тд - тоже неясно. Перезагрузка и тд не помогает. Настройки двух тд идентичны абсолютно.
×
×
  • Create New...