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

BadWolf

Участники форума
 Профиль  Обзор контента

  • Постов

    37

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

  • Посещение

 Тип контента 

Сообщения, опубликованные BadWolf

    4.0 Работа службы Ping-Check и DNS DOT DOH

    в Тестирование Dev-сборок

    Опубликовано

    Проверил - если отключить пинг чек и отключить днс провайдера, то после перезагрузки все продолжает отлично работать. Хотя это странно. Пинг-чек был в автоматическом режиме. Но когда интернета не было, то его действительно не было (не только статус), даже icmp по ip не уходили за пределы роутера 

    4.0 Работа службы Ping-Check и DNS DOT DOH

    в Тестирование Dev-сборок

    Опубликовано

    Доброго времени суток.

    На Giga (KN-1011) UA, с прошивкой 4.0 Beta 3 (также Beta 1 и 2) наблюдаю такую картину.

    Если на роутере настроить DoH (у меня настроены 4: 8.8.8.8=dns.google, 8.8.4.4=dns.google, 1.1.1.1=cloudflare-dns.com, 1.0.0.1=cloudflare-dns.com) и при этом отключить использование DNS провайдера, то после перезагрузки интернет отсутствует, но не из-за проблем с DNS, а потому что в свойствах подключения отсутствует дефолтный шлюз. Тип подключения - обычный IPoE, получение адреса по DHCP. Если после это разрешить и использование dns провайдера и нажать обновить ip, то происходит назначение ip вместе с адресом шлюза и все работает. После этого можно снова отключить днс провайдера и работать до перезагрузки независимо от времени окончания периода аренды ip. Сам ip в обоих случаях получаю свой правильный. На стабильной версии с отключением dns провайдера такого не наблюдал.

    DNS(provider_disabled).png

    DNS(providerEnabled).png

    internet ok(providerDNSenabled).png

    NOInternet-providerDNSdisabled.png

    • Спасибо 1

    Прошу помощи по логам

    в Обмен опытом

    Опубликовано · Изменено пользователем BadWolf

    Возможны 3 причины:

    1. Собственно ошибка авторизации - неверный логин/пароль у клиента.

    2. неверные настройки клиента - клиент должен использовать MS-CHAP v2

    3. Кинетик использует несовместимую с клиентом длину ключа (на дефолтные настройки влияет версия прошивки и регион), по изменениям длины ключа есть в статье https://help.keenetic.com/hc/ru/articles/213967849

    и

     https://help.keenetic.com/hc/ru/articles/360000604720-VPN-сервер-PPTP

     

    После обновления до 2.11.D.2.0-3 на Zyxel Keenetic DSL перестает работать веб-интерфейс.

    в 2.11 [legacy]

    Опубликовано

    29 минут назад, Luka сказал:

    Началась загрузка компонентов и застряла где то на 15-20 %

    Не замечал такого. Ранее замечал, что если в начале обновления переключить вкладку, на некоторое время, то обновление прогресса может подвиснуть, на сам процесс это не влияет.

    31 минуту назад, Luka сказал:

    Установка застряла и дальше не шла. Подумал что уже роутер накрылся. Сделал перезагрузку кнопкой

    При обновлении прошивок, если есть подозрение, что процесс затянулся лучше подождать еще немного, чем сразу перегружать девайс - можно окирпичить. актуально для любого устройства

    После обновления до 2.11.D.2.0-3 на Zyxel Keenetic DSL перестает работать веб-интерфейс.

    в 2.11 [legacy]

    Опубликовано · Изменено пользователем BadWolf

    Доброго времени суток. Такая же проблема. Обновился до 2.11.D.2.0-3 с 2.11.D.1.0-0, в веб по ip не заходит, по my.keenetic.net - ок. Пробовал браузеры Opera 60.0.3255.170 (x86), IE11, Edge и Firefox esr 60.7.2 (64-бит) установленный начисто. OS - Win10x64 1809. Keenetic SDL (rev.A, черный). Так же не отдаются one.js и one.css, при заходе по ip. В логах явно подозрительного нет, по крайней мере нет явных ошибок.

    one.png.f64994b85243abf6cd0ea716770f8774.png

    CVE-2018-5702 в Transmission. Актуально ли?

    в 2.11

    Опубликовано · Изменено пользователем BadWolf

    5 часов назад, Mamay сказал:

    даже если ставить обновления, никто не застрахован от wannacry и иже с ним

    От wannacry и иже с ним как раз таки обновления помогают (в плане распространения по локальной сети с использованием эксплоита)

    Был бюллетень безопасности https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2017/ms17-010

    и отдельные патчи даже для мертвых систем типа XP https://www.catalog.update.microsoft.com/Search.aspx?q=KB4012598

    Да и тем, кто под линуксом самбу гоняет пришлось не сладко https://habr.com/company/cloud4y/blog/329464/

    CVE-2018-5702 в Transmission. Актуально ли?

    в 2.11

    Опубликовано

    19 минут назад, Mamay сказал:

    Были попытки пилить версию выше 2.84, местные же форумчане попросили вернуть её назад из-за комплекса проблем старших версий... 

    Я как-то пропустил этот момент...

    20 минут назад, Mamay сказал:

    P. S. Мастдай сам по себе решето, однако вы же не параноите при этом... 

    Если обновления не ставить, то да. С другой стороны если в интернете "на все кнопки жать" то и Линукс может не спасти ?

    CVE-2018-5702 в Transmission. Актуально ли?

    в 2.11

    Опубликовано

    Доброго времени суток.

    В торрент-клиенте Transmission существует уязвимость удаленного выполнения комманд CVE-2018-5702.

    https://www.securitylab.ru/vulnerability/494041.php

    Уязвимые версии: 2.92, 2.91, 2.90, 2.84, 2.83, 2.82, 2.81, 2.80, 2.77, 2.76, 2.75, 2.74, 2.73, 2.72, 2.71, 2.70, 2.61, 2.52, 2.51, 2.50

    В версии ndms 2.11 (возможно и в других) сейчас используется версия 2.84, но актуальная ли уязвимость для версий Transmission скомпилированных для Kennetic`ов? Если да, будет ли обновление?

    Определение состояния доступа в Интренет

    в 2.11

    Опубликовано

    6 минут назад, sergeyk сказал:

    ndnproxy посылает запросы последовательно на каждый из серверов (с небольшой задержкой) и принимает ответ от первого ответившего. Самыми быстрыми оказываются серверы провайдера. Надо смотреть, что они отвечают на google.com и facebook.com

    Хорошо, вот вывод виндового nslookup для этих доменов:

    google.com:

    Скрытый текст

    > google.com 195.248.191.67
    ╤хЁтхЁ:  [195.248.191.67]
    Address:  195.248.191.67

    Не заслуживающий доверия ответ:
    ╚ь :     google.com
    Addresses:  2a00:1450:401b:803::200e
              172.217.20.206

    > google.com 195.248.191.72
    ╤хЁтхЁ:  [195.248.191.72]
    Address:  195.248.191.72

    Не заслуживающий доверия ответ:
    ╚ь :     google.com
    Addresses:  2a00:1450:401b:802::200e
              172.217.20.174

    > google.com 8.8.8.8
    ╤хЁтхЁ:  [8.8.8.8]
    Address:  8.8.8.8

    Не заслуживающий доверия ответ:
    ╚ь :     google.com
    Addresses:  2a00:1450:401b:800::200e
              216.58.209.46

    facebook.com:

    Скрытый текст

    > facebook.com 195.248.191.67
    ╤хЁтхЁ:  [195.248.191.67]
    Address:  195.248.191.67

    Не заслуживающий доверия ответ:
    ╚ь :     facebook.com
    Addresses:  2a03:2880:f12d:83:face:b00c:0:25de
              185.60.216.35

    > facebook.com 195.248.191.72
    ╤хЁтхЁ:  [195.248.191.72]
    Address:  195.248.191.72

    Не заслуживающий доверия ответ:
    ╚ь :     facebook.com
    Addresses:  2a03:2880:f12d:83:face:b00c:0:25de
              185.60.216.35

    > facebook.com 8.8.8.8
    ╤хЁтхЁ:  [8.8.8.8]
    Address:  8.8.8.8

    Не заслуживающий доверия ответ:
    ╚ь :     facebook.com
    Addresses:  2a03:2880:f11c:8183:face:b00c:0:25de
              31.13.92.36

     

    Определение состояния доступа в Интренет

    в 2.11

    Опубликовано

    Кстати, насколько нормально, что у меня по команде show internet status показывает 0.0.0.0 адрес шлюза?

    или для PPPoE такой вывод допустим?

    Скрытый текст

     gateway:
                interface: PPPoE0
                  address: 0.0.0.0
                 failures: 0
               accessible: yes
                 excluded: no

     

    Определение состояния доступа в Интренет

    в 2.11

    Опубликовано · Изменено пользователем BadWolf

    31 минуту назад, sergeyk сказал:

    У вас есть возможность проверить этот же сценарий без серверов 195.248.191.67 и 195.248.191.72?

    Не уверен, что могу их полностью исключить. Это днс провайдера, которые приходят при автоматическом получении адреса. Адрес у меня динамический, хотя и белый и меняют не часто. Гугл днс использую только для отдельных доменов.

    Прописал гугл днс в список глобальных днс без указания домена. Не уверен как трактовать результат.

    Тест подключения теперь выполняется.

    Скрытый текст

    checked: Fri Sep 22 12:25:03 2017
             reliable: yes
    gateway-accessible: yes
       dns-accessible: yes
      host-accessible: yes
             internet: yes

              gateway:
                interface: PPPoE0
                  address: 0.0.0.0
                 failures: 0
               accessible: yes
                 excluded: no

                hosts:
                     host:
                         name: ya.ru
                     failures: 0
                     resolved: no
                   accessible: no

                     host:
                         name: google.com
                     failures: 0
                     resolved: yes
                   accessible: yes

                     host:
                         name: facebook.com
                     failures: 0
                     resolved: no
                   accessible: no

             

    Но по self-test'у запросы прошли через днс провайдера 

    DNS Servers

                      Ip   Ban  R.Sent  A.Rcvd  Med.Resp  Avg.Resp  
          195.248.191.67    no       0       0       0ms       0ms  
                 8.8.8.8   yes       0       0       0ms       0ms  
          195.248.191.72    no      25      26      18ms      26ms

     

     

    self-test3.txt

    Определение состояния доступа в Интренет

    в 2.11

    Опубликовано · Изменено пользователем BadWolf

    1 час назад, sergeyk сказал:

    Ну а остальные? 

    
(config)> tools ping google.com
    

 
    
(config)> tools ping facebook.com

     

    Скрытый текст

    (config)> tools ping ya.ru
    sending ICMP ECHO request to ya.ru...
    Failed to resolve "ya.ru".
    (config)> tools ping google.com
    sending ICMP ECHO request to google.com...
    PING google.com (172.217.20.174) 56 (84) bytes of data.
    84 bytes from google.com (172.217.20.174): icmp_req=1, ttl=55, time=43.00 ms.
    84 bytes from google.com (172.217.20.174): icmp_req=2, ttl=55, time=42.80 ms.
    84 bytes from google.com (172.217.20.174): icmp_req=3, ttl=55, time=43.03 ms.
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    84 bytes from google.com (172.217.20.174): icmp_req=4, ttl=55, time=42.94 ms.
    84 bytes from google.com (172.217.20.174): icmp_req=5, ttl=55, time=42.21 ms.
    84 bytes from google.com (172.217.20.174): icmp_req=6, ttl=55, time=42.76 ms.
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    84 bytes from google.com (172.217.20.174): icmp_req=7, ttl=55, time=42.64 ms.
    --- google.com ping statistics ---
    7 packets transmitted, 7 packets received, 0% packet loss,
    0 duplicate(s), time 6644.77 ms.
    Round-trip min/avg/max = 42.21/42.76/43.03 ms.
    (config)> tools ping facebook.com
    sending ICMP ECHO request to facebook.com...
    PING facebook.com (185.60.216.35) 56 (84) bytes of data.
    84 bytes from facebook.com (185.60.216.35): icmp_req=1, ttl=56, time=57.12 ms.
    84 bytes from facebook.com (185.60.216.35): icmp_req=2, ttl=56, time=56.11 ms.
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    84 bytes from facebook.com (185.60.216.35): icmp_req=3, ttl=56, time=56.04 ms.
    84 bytes from facebook.com (185.60.216.35): icmp_req=4, ttl=56, time=55.80 ms.
    84 bytes from facebook.com (185.60.216.35): icmp_req=5, ttl=56, time=56.42 ms.
    "Destination unreachable" ICMP packet received from 127.0.0.1 (type = 3, code = 3
    ).
    84 bytes from facebook.com (185.60.216.35): icmp_req=6, ttl=56, time=56.50 ms.
    84 bytes from facebook.com (185.60.216.35): icmp_req=7, ttl=56, time=56.24 ms.
    --- facebook.com ping statistics ---
    8 packets transmitted, 7 packets received, 12% packet loss,
    0 duplicate(s), time 7042.11 ms.
    Round-trip min/avg/max = 55.80/56.31/57.12 ms.

     

    Определение состояния доступа в Интренет

    в 2.11

    Опубликовано · Изменено пользователем BadWolf

    16 минут назад, sergeyk сказал:

    EasyConfig проверяет доступность сайта, подключаясь к его 80 порту по TCP.

    Ну браузером то я захожу на гугл и фейсбук без проблем.

    хорошо, делаем telnet google.com 80 и передаем команду GET /

    получаем

     

    googleget.png

    ну и для facebook.com 80 получаем

     

    facebookget.png

    Определение состояния доступа в Интренет

    в 2.11

    Опубликовано · Изменено пользователем BadWolf

    Что-то все же работает не так

    вот что выдает проверка через cli

              checked: Fri Sep 22 10:04:57 2017
             reliable: yes
    gateway-accessible: yes
       dns-accessible: no
      host-accessible: no
             internet: no

              gateway:
                interface: PPPoE0
                  address: 0.0.0.0
                 failures: 0
               accessible: yes
                 excluded: no

                hosts:
                     host:
                         name: ya.ru
                     failures: 0
                     resolved: no
                   accessible: no

                     host:
                         name: google.com
                     failures: 0
                     resolved: no
                   accessible: no

                     host:
                         name: facebook.com
                     failures: 0
                     resolved: no
                   accessible: no

    а вот проверка пингами сайтов (если что на хосте как днс используется только адрес роутера)

    pingsites.png

    Скрытый текст

    Кстати в списке подключений подключение с зеленой галкой и показывает мой ip адрес

    wanlist.png.080bd33f13b5d4a1bf7aa782000779a3.png

    22 часа назад, Mamay сказал:

    Ну ладно, фиг с ним с Яндексом, но Google и FaceBook тоже ваш президент залочил? :facepalm:

    Залочены в основном сайты Яндекса и Mail RU Group. В основном по ip+dns, некоторые провайдеры прогнулись и залочили и сайты не указанные явно в списке этих же контор, но только по днс - так у меня прописано 

    8.8.8.8    yandex.fr
    8.8.8.8    yastatic.net

    и я смотрю погоду на yandex.fr :)

     

    Определение состояния доступа в Интренет

    в 2.11

    Опубликовано

    Доброго времени суток!

    Keenetic DSL, Версия NDMS    2.11.A.2.0-0

    При входе на главную страницу состояния секунды 2-3 в состоянии подключения показывает "Доступ в Интернет", затем состояние меняется на "Нет доступа в Интернет". Так стоит пока не уйти со страницы - если перейти на любую вкладку веб-интерфейса и вернутся на главную страницу состояния, то снова несколько секунд будет показывать, что интернет есть, затем "Нет доступа в Интернет". Реально доступ в интернет при этом не пропадает, т.е. по факту всё работает, только статус доступа в Интернет определяет неправильно.

    В журнале при этом красных записей нет. И когда статус меняется на "Нет доступа в Интернет", то в веб интерфейсе перестает отображать ip адрес, назначаемый провайдером. Скрин приложил с пингами наружу, чтоб было видно, что реально Интернет есть

    internet-ok.png

    self-test.txt

    Скрытый текст

    3sec.png.541971340a8a4937f6012e85e99c69a3.png

     

     

    Keenetic DSL перестал видеть USB устройства

    в 2.10

    Опубликовано

    12 часа назад, AndreBA сказал:

    Так какие компоненты добавили? С USB storage связаны? Или все же криво прошилось в первом случае ?

    Добавлял что-то связанное с ВПНами, просто чтоб перезалилась прошивка, все связанное с usb уже стояло. Походу в первом случае криво встала

    Keenetic DSL перестал видеть USB устройства

    в 2.10

    Опубликовано · Изменено пользователем BadWolf

    Доброго времени суток.

    Kennetic DSL версия NDMS 2.10.A.7.0-5 перестал видеть usb жесткий диск (через ПК диск определяется нормально)

    В логе есть какая-то ошибка загрузки USB драйверов:

    Jan  1 00:00:04 ndm: Core::System::DriverManager: loading /lib/modules/3.4.113/usb-common.ko.
    [E] Jan  1 00:00:04 ndm: kernel: SQUASHFS error: xz_dec_run error, data probably corrupt
    [E] Jan  1 00:00:04 ndm: kernel: SQUASHFS error: squashfs_read_data failed to read block 0x5609f0
    [E] Jan  1 00:00:05 ndm: kernel: SQUASHFS error: Unable to read fragment cache entry [5609f0]
    [E] Jan  1 00:00:05 ndm: kernel: SQUASHFS error: Unable to read page, block 5609f0, size 94e8
    [E] Jan  1 00:00:05 ndm: kernel: SQUASHFS error: Unable to read fragment cache entry [5609f0]
    [E] Jan  1 00:00:05 ndm: kernel: SQUASHFS error: Unable to read page, block 5609f0, size 94e8
    [E] Jan  1 00:00:05 ndm: Io::File: unable to read data: input/output error.
    [E] Jan  1 00:00:05 ndm: Core::System::DriverManager: failed to read /lib/modules/3.4.113/usb-common.ko.
    [E] Jan  1 00:00:05 ndm: Core::System::DriverManager: failed to load /lib/modules/3.4.113/usb-common.ko.

    Что это значит - криво встала последняя версия прошивки или железо накрывается?

    self-test.txt

×
×
  • Создать...

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

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

  Я принимаю