Перейти к содержанию

birskih

Участники форума
  • Постов

    11
  • Зарегистрирован

  • Посещение

Весь контент birskih

  1. Совершенно верно. Продолжает работать на "Провайдер 2", вне зависимости от статуса "Провайдер 1"
  2. Естественно, пингчек включен, и дополнительные подключения все созданы. Но дело не в нем, и даже не в восстановлении "KeeneticOS при помощи компьютера под управлением Ubuntu Linux" Зачем вы привели именно эту ссылку, решительно не ясно.
  3. Всем доброго времени суток. Встал вопрос о резервировании интернет соединения. В роутер (Keenetic Speedster (KN-3013) заходят три провайдера соответственно назовем их Первый, Второй и Третий. Так же настроено подключение l2tp к VPS. Все три подключения имеют разный приоритет в зависимости от их значимости. В политиках стоят друг за другом, самым первым - l2tp, за ним три подключения провайдера. Когда пропадает первое соединение, роутер корректно переключается на второе, если второе, то на третье. Но при восстановлении первого подключения, продолжает работать резервное, и переключения на основное не происходит. Подскажите, как сделать так что бы резервные подключения работали именно как резервные, и автоматически переключались на основные. Спасибо.
  4. В настройках доступа пункт "Доступ из интернета" выбран на какой-нибудь кроме "нет доступа"? Устройство на которое стучитесь имеет веб интерфейс?
  5. Жена добралась. Удаленно не получится, без первоначальной настройки просто не поднимает соединение. (Нужно руками указать что подключаться к сети требуется через мобильное соединение а не ethernet, например). Но мне кажется что потери через sttp не связаны с багом который словил я. В моей проблеме была четкая закономерность - 10 пакетов проходят, 4 нет.
  6. Сначала обновился на последнюю прошивку 4.3.6.3 не помогло. Потом сбросил роутер к дефолту (применил заводские настройки). Прошивка сохранилась та же, и все заработало без потерь.
  7. Докладываю: После сброса на прошивке 4.3.6.3 работает нормально. Всем спасибо.
  8. Все бы хорошо, но роутер в 600км от меня. KeenDNS после сброса работает, не пробовали? Маловероятно, наверное...
  9. К сожалению без изменений sending ICMP ECHO request to 8.8.8.8... PING 8.8.8.8 (8.8.8.8) 56 (84) bytes of data. 84 bytes from 8.8.8.8: icmp_req=1, ttl=103, time=88.40 ms. 84 bytes from 8.8.8.8: icmp_req=2, ttl=103, time=106.57 ms. 84 bytes from 8.8.8.8: icmp_req=3, ttl=103, time=98.55 ms. 84 bytes from 8.8.8.8: icmp_req=4, ttl=103, time=99.64 ms. 84 bytes from 8.8.8.8: icmp_req=5, ttl=103, time=93.65 ms. 84 bytes from 8.8.8.8: icmp_req=6, ttl=103, time=93.65 ms. 84 bytes from 8.8.8.8: icmp_req=7, ttl=103, time=96.74 ms. 84 bytes from 8.8.8.8: icmp_req=8, ttl=103, time=92.31 ms. 84 bytes from 8.8.8.8: icmp_req=9, ttl=103, time=73.45 ms. 84 bytes from 8.8.8.8: icmp_req=10, ttl=103, time=90.61 ms. A broken ICMP echo reply received. A broken ICMP echo reply received. A broken ICMP echo reply received. A broken ICMP echo reply received. 84 bytes from 8.8.8.8: icmp_req=15, ttl=103, time=203.85 ms. 84 bytes from 8.8.8.8: icmp_req=16, ttl=103, time=76.52 ms. 84 bytes from 8.8.8.8: icmp_req=18, ttl=103, time=91.64 ms. 84 bytes from 8.8.8.8: icmp_req=19, ttl=103, time=105.16 ms. 84 bytes from 8.8.8.8: icmp_req=20, ttl=103, time=89.63 ms. 84 bytes from 8.8.8.8: icmp_req=21, ttl=103, time=88.40 ms. 84 bytes from 8.8.8.8: icmp_req=22, ttl=103, time=91.45 ms. 84 bytes from 8.8.8.8: icmp_req=23, ttl=103, time=82.75 ms. 84 bytes from 8.8.8.8: icmp_req=24, ttl=103, time=73.19 ms. 84 bytes from 8.8.8.8: icmp_req=25, ttl=103, time=82.70 ms. A broken ICMP echo reply received. A broken ICMP echo reply received. A broken ICMP echo reply received. A broken ICMP echo reply received. 84 bytes from 8.8.8.8: icmp_req=30, ttl=103, time=111.06 ms. 84 bytes from 8.8.8.8: icmp_req=31, ttl=103, time=96.41 ms. 84 bytes from 8.8.8.8: icmp_req=32, ttl=103, time=95.66 ms. 84 bytes from 8.8.8.8: icmp_req=33, ttl=103, time=79.31 ms. 84 bytes from 8.8.8.8: icmp_req=34, ttl=103, time=96.47 ms. 84 bytes from 8.8.8.8: icmp_req=35, ttl=103, time=73.36 ms. 84 bytes from 8.8.8.8: icmp_req=36, ttl=103, time=97.49 ms. 84 bytes from 8.8.8.8: icmp_req=37, ttl=103, time=93.59 ms. 84 bytes from 8.8.8.8: icmp_req=38, ttl=103, time=92.24 ms. 84 bytes from 8.8.8.8: icmp_req=39, ttl=103, time=95.51 ms. 84 bytes from 8.8.8.8: icmp_req=40, ttl=103, time=89.60 ms. A broken ICMP echo reply received. A broken ICMP echo reply received. A broken ICMP echo reply received. 84 bytes from 8.8.8.8: icmp_req=44, ttl=103, time=834.90 ms. 84 bytes from 8.8.8.8: icmp_req=45, ttl=103, time=86.74 ms. 84 bytes from 8.8.8.8: icmp_req=46, ttl=103, time=85.61 ms. 84 bytes from 8.8.8.8: icmp_req=47, ttl=103, time=86.31 ms. 84 bytes from 8.8.8.8: icmp_req=48, ttl=103, time=71.67 ms. 84 bytes from 8.8.8.8: icmp_req=49, ttl=103, time=94.27 ms. 84 bytes from 8.8.8.8: icmp_req=50, ttl=103, time=83.52 ms. --- 8.8.8.8 ping statistics --- 50 packets transmitted, 38 packets received, 24% packet loss, 0 duplicate(s), time 49116.94 ms. Round-trip min/avg/max = 71.67/112.69/834.90 ms.
  10. Кто-нибудь решил проблему? KN-4910, оператор мегафон, теряет пакеты примерно каждые 10 секунд по 4 штуки. Откатиться на предыдущую прошивку можно конечно, но тогда пропадает WireGuard и нет возможности установить его заново.
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.