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

birskih

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

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

  • Посещение

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

  1. В январе проблема вернулась. Неужели нет решения? Никакие ВПН и прочие настройки не менял. Проблема плавающая, поломалась после того как на тарифе закончился пакет траффика, пополнил не вовремя.
  2. Совершенно верно. Продолжает работать на "Провайдер 2", вне зависимости от статуса "Провайдер 1"
  3. Естественно, пингчек включен, и дополнительные подключения все созданы. Но дело не в нем, и даже не в восстановлении "KeeneticOS при помощи компьютера под управлением Ubuntu Linux" Зачем вы привели именно эту ссылку, решительно не ясно.
  4. Всем доброго времени суток. Встал вопрос о резервировании интернет соединения. В роутер (Keenetic Speedster (KN-3013) заходят три провайдера соответственно назовем их Первый, Второй и Третий. Так же настроено подключение l2tp к VPS. Все три подключения имеют разный приоритет в зависимости от их значимости. В политиках стоят друг за другом, самым первым - l2tp, за ним три подключения провайдера. Когда пропадает первое соединение, роутер корректно переключается на второе, если второе, то на третье. Но при восстановлении первого подключения, продолжает работать резервное, и переключения на основное не происходит. Подскажите, как сделать так что бы резервные подключения работали именно как резервные, и автоматически переключались на основные. Спасибо.
  5. В настройках доступа пункт "Доступ из интернета" выбран на какой-нибудь кроме "нет доступа"? Устройство на которое стучитесь имеет веб интерфейс?
  6. Жена добралась. Удаленно не получится, без первоначальной настройки просто не поднимает соединение. (Нужно руками указать что подключаться к сети требуется через мобильное соединение а не ethernet, например). Но мне кажется что потери через sttp не связаны с багом который словил я. В моей проблеме была четкая закономерность - 10 пакетов проходят, 4 нет.
  7. Сначала обновился на последнюю прошивку 4.3.6.3 не помогло. Потом сбросил роутер к дефолту (применил заводские настройки). Прошивка сохранилась та же, и все заработало без потерь.
  8. Докладываю: После сброса на прошивке 4.3.6.3 работает нормально. Всем спасибо.
  9. Все бы хорошо, но роутер в 600км от меня. KeenDNS после сброса работает, не пробовали? Маловероятно, наверное...
  10. К сожалению без изменений 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.
  11. Кто-нибудь решил проблему? KN-4910, оператор мегафон, теряет пакеты примерно каждые 10 секунд по 4 штуки. Откатиться на предыдущую прошивку можно конечно, но тогда пропадает WireGuard и нет возможности установить его заново.
×
×
  • Создать...

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

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