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

hellonow

Модераторы
  • Постов

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

  • Посещение

  • Победитель дней

    27

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

  1. @t800 у вас возникает перезапуск DHCP на Br0 контроллера, поэтому да, это может вызывать сообщения в Приложении. Напишите пожалуйста в поддержку, описав данную ситуацию.
  2. @keenet07 да, отдельную тему пожалуйста, чтобы все в кучу не мешать.
  3. @aug похоже на то, что провайдер начинает блокировать запросы DNS DoH. Также это может возникать после renew, но это уже поправлено. Пробуйте перейти на DNS over TLS.
  4. @andrey_sys лог пожалуйста так не выкладывайте в тему, либо сюда https://pastebin.com, а еще лучше делать так https://forum.keenetic.com/announcement/4-как-правильно-добавить-self-test-и-прочую-отладку-в-тему/
  5. @Winterborn Нужен self-test файл, когда работает туннель на версии 3.8.5.4 и когда не работает на версии 3.9.0
  6. В логе self-test файла не зафиксирована данная ошибка, только остановка, загрузка демона mtkiappd: [I] Nov 25 11:22:46 mtkiappd: stopped. [I] Nov 25 11:22:46 mtkiappd: stopped. [I] Nov 25 11:22:48 mtkiappd: MediaTek IAPP daemon v2.0.9 started on br0. [I] Nov 25 11:22:48 mtkiappd: MediaTek IAPP daemon v2.0.9 started on br1.
  7. @Winterborn корневые сертификаты IdenTrust DST Root CA X3 проверяли? https://habr.com/ru/post/580092/
  8. @elesdrago спасибо, пока не нужно. Ситуация воспроизводится на столе 👍
  9. @4c4127db756b4affbf2a2b3186 да, все верно, на данный момент настройка доступна в CLI, пример: dns-proxy tls upstream 2620:fe::9 domain dns.quad9.net system configuration save В будущих версиях ПО стоит ожидатьнастройку DoT DoH в веб.
  10. @saffe на данный момент имеются трудности в работе Time Machine (Tuxera) KeeneticOS и macOS Ventura 13.0.1 От файловой системы не зависит. Ожидается исправление в будущих версиях ПО.
  11. @t800 у вас явно линк падал и не был доступен шлюз: [I] Nov 24 10:20:47 ndm: Network::Interface::Switch: "FastEthernet0/1": switch link up at port 1 (100FD/AN). [I] Nov 24 10:20:47 kernel: br0: port 1(eth2.1) entered blocking state [I] Nov 24 10:20:47 kernel: br0: port 1(eth2.1) entered listening state [I] Nov 24 10:20:47 kernel: br1: port 1(eth2.2) entered blocking state [I] Nov 24 10:20:47 kernel: br1: port 1(eth2.2) entered listening state [W] Nov 24 10:20:50 ndm: Dhcp::Client: DHCP server is not responding. [W] Nov 24 10:20:50 ndm: Dhcp::Client: DHCP server is not responding. [I] Nov 24 10:20:50 ndm: Network::Interface::Ip: "Bridge1": IP address cleared. [I] Nov 24 10:20:50 ndm: Network::InternetChecker: Internet access lost (status: 0x0000). [I] Nov 24 10:20:50 kernel: br1: port 1(eth2.2) entered learning state [I] Nov 24 10:20:50 kernel: br0: port 1(eth2.1) entered learning state Далее аналогичное событие: [I] Nov 24 10:20:56 ndm: Network::Interface::Switch: "FastEthernet0/1": switch link down at port 1. [I] Nov 24 10:20:56 kernel: br0: port 1(eth2.1) entered blocking state [I] Nov 24 10:20:56 kernel: br0: port 1(eth2.1) entered listening state [I] Nov 24 10:20:56 ndhcpc: Bridge1: received OFFER for 172.16.1.21 from 172.16.1.1. [I] Nov 24 10:20:56 kernel: br1: port 1(eth2.2) entered blocking state [I] Nov 24 10:20:56 kernel: br1: port 1(eth2.2) entered listening state [I] Nov 24 10:20:58 ndm: Network::Interface::Switch: "FastEthernet0/1": switch link up at port 1 (100FD/AN). Поэтому срабатывает STP, так как есть MWS. При изменении топологии, дерево STP перестраивается и свитч в Keenetic проходит стадии blocking - listening - learning - forwarding, в такие моменты передача через все локальные порты блокируется на несколько секунд, поэтому приложение отрабатывает корректно, не похоже на "фейковые" пуши.
  12. @Vladimir Belov не надо дублировать сообщения. self-test файл нужно скрывать, не выкладывать в паблик.
  13. @koctik-2017 актуально в 3.9 Beta 2? Если да, то нужно подробное описание воспроизведения ситуации и self-test файл.
  14. @t800 можно не обращать внимания, это системное сообщение никак не влияет на работу системы. Это мобильное приложение запрашивает информацию по http \ rci.
  15. @bonlui возможно не хватает памяти ОЗУ, нужно больше информации по настройке системы и нужен self-test файл. В версии 3.9 Beta 2 актуально? Проверьте на данной версии.
  16. Продолжение темы: Исправление в следующей версии 3.9
  17. @il0x Нет подключения с удаленной стороной, возможно сессия зависает: [I] Sep 6 21:53:55 pppd_L2TP0: CHAP authentication failed: Too many connections [E] Sep 6 21:53:55 pppd_L2TP0: CHAP authentication failed [I] Sep 6 21:53:55 pppd_L2TP0: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"] [I] Sep 6 21:53:55 pppd_L2TP0: rcvd [LCP TermAck id=0x2] [I] Sep 6 21:53:55 pppd_L2TP0: Connection terminated. В целом лучше перейти на IPoE и причиной обрывов может быть то, о чем вы упомянули. Из-за большого количества соединений со стороны клиента-хоста, шлюз Билайна перестает отвечать, в логе вы увидите сообщения: Internet access lost (status: 0x0000) или Internet access lost (status: 0x0007) Но тут надо уже собирать дамп трафика и напрямую их отправлять в поддержку провайдера.
  18. @iggo данная опция отвечает за ip http security-level, когда делаете public или public ssl в controlPanel/diagnostics/General, то настройка будет распространенаи на controlPanel/remoteAccess/KeenDNS.
  19. Продолжение темы: Исправление в следующей версии 3.9
  20. @Dhampir113 проверьте работу на 3.9 Beta 2. Если актуально, то после зависания попробуйте зайти в CLI https://help.keenetic.com/hc/ru/articles/213965889... и сохранить вывод команды: sh ru и show self-test Данные пришлите в скрытом сообщении, либо на help@keenetic.ru
  21. @dimon27254 с ходу воспроизвести не получилось, возможно имеется зависимость от оператора связи или модема. Попробовал указать проверку 443 порта и хэндшейк проходит: I [Nov 18 20:16:09] ndm: PingCheck::Profile: "_WEBADMIN_UsbQmi0": interface "UsbQmi0" address 100.70.144.215 gw 100.70.144.216: success count 86/5. I [Nov 18 20:16:12] ndm: PingCheck::Profile: "_WEBADMIN_UsbQmi0": Check interface UsbQmi0, address 100.70.144.215, gw 100.70.144.216. I [Nov 18 20:16:12] ndm: PingCheck::Profile: "_WEBADMIN_UsbQmi0": install routes to peers to table 11. I [Nov 18 20:16:12] ndm: PingCheck::Profile: "_WEBADMIN_UsbQmi0": TLS handshake check of ya.ru. I [Nov 18 20:16:12] ndm: PingCheck::Profile: "_WEBADMIN_UsbQmi0": connecting to 87.250.250.242:443. I [Nov 18 20:16:12] ndm: Io::TcpSocket: connected to 87.250.250.242:443. Если указать выше интервал? Другой домен, например google.com? ping-check profile _WEBADMIN_UsbQmi0 host ya.ru port 443 update-interval 10 mode tls max-fails 5 Ситуация сохранится? В других self-test файлах в логе фиксируется, что домен не резолвится: [W] Nov 14 20:31:43 ndm: PingCheck::Profile: "_WEBADMIN_UsbQmi0": failed to resolve "ya.ru". Попробуйте настроить еще работу DNS по протоколу DoT DoH - https://help.keenetic.com/hc/ru/articles/360007687159, чтобы исключить проблему резолвинга.
  22. @Arturas953 если еще актуально на версии 3.9 Beta 2, то просьба написать в поддержку, прислав self-test файл, когда нет подключения интернета после захвата Ретранслятора.
×
×
  • Создать...

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

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