BadWolf
-
Posts
36 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by BadWolf
-
-
Доброго времени суток.
На 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 провайдера такого не наблюдал.
.png.2383e38b10bb48a11f645bdbf8ee5695.png)
.thumb.png.a84f3d761b28f1a53af9ae41b121078d.png)
.png.e203cef94966ae1506f6e7f12227ce1d.png)
-
1
-
-
Возможны 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-5 полет нормальный - по ip заходит
-
29 минут назад, Luka сказал:
Началась загрузка компонентов и застряла где то на 15-20 %
Не замечал такого. Ранее замечал, что если в начале обновления переключить вкладку, на некоторое время, то обновление прогресса может подвиснуть, на сам процесс это не влияет.
31 минуту назад, Luka сказал:Установка застряла и дальше не шла. Подумал что уже роутер накрылся. Сделал перезагрузку кнопкой
При обновлении прошивок, если есть подозрение, что процесс затянулся лучше подождать еще немного, чем сразу перегружать девайс - можно окирпичить. актуально для любого устройства
-
На 2.11.D.2.0-4 картина та же относительно 2.11.D.2.0-3
-
Доброго времени суток. Такая же проблема. Обновился до 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. В логах явно подозрительного нет, по крайней мере нет явных ошибок.
-
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/
-
19 минут назад, Mamay сказал:
Были попытки пилить версию выше 2.84, местные же форумчане попросили вернуть её назад из-за комплекса проблем старших версий...
Я как-то пропустил этот момент...
20 минут назад, Mamay сказал:P. S. Мастдай сам по себе решето, однако вы же не параноите при этом...
Если обновления не ставить, то да. С другой стороны если в интернете "на все кнопки жать" то и Линукс может не спасти ?
-
Доброго времени суток.
В торрент-клиенте 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`ов? Если да, будет ли обновление?
-
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.46facebook.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 -
Кстати, насколько нормально, что у меня по команде show internet status показывает 0.0.0.0 адрес шлюза?
или для PPPoE такой вывод допустим?
Скрытый текстgateway:
interface: PPPoE0
address: 0.0.0.0
failures: 0
accessible: yes
excluded: no -
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: yesgateway:
interface: PPPoE0
address: 0.0.0.0
failures: 0
accessible: yes
excluded: nohosts:
host:
name: ya.ru
failures: 0
resolved: no
accessible: nohost:
name: google.com
failures: 0
resolved: yes
accessible: yeshost:
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 -
8 минут назад, sergeyk сказал:
Показывайте self-test в таком случае.
Какие-то конкретные операции при включенной отладке нужно повторять?
-
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. -
12 минуты назад, sergeyk сказал:
(config)> tools ping ya.ruчто показывает?
ya.ru забанен провайдером - уже писал же
Скрытый текст
-
16 минут назад, sergeyk сказал:
EasyConfig проверяет доступность сайта, подключаясь к его 80 порту по TCP.
Ну браузером то я захожу на гугл и фейсбук без проблем.
хорошо, делаем telnet google.com 80 и передаем команду GET /
получаем
ну и для facebook.com 80 получаем
-
Что-то все же работает не так
вот что выдает проверка через cli
checked: Fri Sep 22 10:04:57 2017
reliable: yes
gateway-accessible: yes
dns-accessible: no
host-accessible: no
internet: nogateway:
interface: PPPoE0
address: 0.0.0.0
failures: 0
accessible: yes
excluded: nohosts:
host:
name: ya.ru
failures: 0
resolved: no
accessible: nohost:
name: google.com
failures: 0
resolved: no
accessible: nohost:
name: facebook.com
failures: 0
resolved: no
accessible: noа вот проверка пингами сайтов (если что на хосте как днс используется только адрес роутера)
Скрытый текстКстати в списке подключений подключение с зеленой галкой и показывает мой ip адрес
22 часа назад, Mamay сказал:Ну ладно, фиг с ним с Яндексом, но Google и FaceBook тоже ваш президент залочил?
Залочены в основном сайты Яндекса и Mail RU Group. В основном по ip+dns, некоторые провайдеры прогнулись и залочили и сайты не указанные явно в списке этих же контор, но только по днс - так у меня прописано
8.8.8.8 yandex.fr
8.8.8.8 yastatic.netи я смотрю погоду на yandex.fr
-
Есть подозрение, что там если любой из 3-х недоступен, то пишем нет интернета. Хорошо бы как то (через cli) иметь возможность видеть какие из сайтов не проходят проверку
-
ya.ru забанен провайдером по указу президента... основные сайты (из списка бана) - по ip, некоторые по dns. google и facebook нормально работают
-
Доброго времени суток!
Keenetic DSL, Версия NDMS 2.11.A.2.0-0
При входе на главную страницу состояния секунды 2-3 в состоянии подключения показывает "Доступ в Интернет", затем состояние меняется на "Нет доступа в Интернет". Так стоит пока не уйти со страницы - если перейти на любую вкладку веб-интерфейса и вернутся на главную страницу состояния, то снова несколько секунд будет показывать, что интернет есть, затем "Нет доступа в Интернет". Реально доступ в интернет при этом не пропадает, т.е. по факту всё работает, только статус доступа в Интернет определяет неправильно.
В журнале при этом красных записей нет. И когда статус меняется на "Нет доступа в Интернет", то в веб интерфейсе перестает отображать ip адрес, назначаемый провайдером. Скрин приложил с пингами наружу, чтоб было видно, что реально Интернет есть
Скрытый текст
-
12 часа назад, AndreBA сказал:
Так какие компоненты добавили? С USB storage связаны? Или все же криво прошилось в первом случае ?
Добавлял что-то связанное с ВПНами, просто чтоб перезалилась прошивка, все связанное с usb уже стояло. Походу в первом случае криво встала
-
-
Доброго времени суток.
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.Что это значит - криво встала последняя версия прошивки или железо накрывается?
-
2 часа назад, Le ecureuil сказал:
А если штук 5 туннелей поднято, то что делать? А тут у многих такие конфигурации не редкость.
Тогда для доменов (сайтов) которые нужно резолвить через конкретный днс сервер прописываем условную днс пересылку, а остальные резолвятся через дефолтные днс. Для большинства пользователей таких записей будет не больше 10-ка.
Впрочем если кому-то очень нужно резолвить почти все сайты через особый днс, то делаем наоборот - прописываем на интернет интерфейсе (или просто в списке днс) гугл днс или другой нужный, днс провайдера убираем из дефолтных днс (или убираем с интерфейса) , а для локальных доменов (в т.ч. провайдерских, если есть) прописываем условное соответствие нужному днс серверу.
Но если реально есть штук 5 туннелей, то вероятно еще и в правила маршрутизации придется что-то добавлять
.png.2383e38b10bb48a11f645bdbf8ee5695.png)
.png.0067bc56d45ac6a4fefaa3fa153b208e.png)
.png.e203cef94966ae1506f6e7f12227ce1d.png)
4.0 Работа службы Ping-Check и DNS DOT DOH
in Тестирование Dev-сборок
Posted
Проверил - если отключить пинг чек и отключить днс провайдера, то после перезагрузки все продолжает отлично работать. Хотя это странно. Пинг-чек был в автоматическом режиме. Но когда интернета не было, то его действительно не было (не только статус), даже icmp по ip не уходили за пределы роутера