admin

Приложение SkyDNS доступно только для устройств, продаваемых на территории России. (Там Skipper продается под другим названием — Viva.) Вы, судя по всему, приобрели Skipper в Европе, поэтому пользуйтесь сервисом SafeDNS. Это полный аналог SkyDNS.

Похоже на шторм через второй-третий. Куда они ведут? Как будто петля.

@T0ster: address your questions to the tech support. Please.

Check output of `show version`. Make sure it shows country `UA`. We uploaded official import lists to our cloud servers responsible for Authentication and Licensing (read Internal Service Traffic for more information). If your device is listed, it will receive the new country code from the server. Please contact the official tech support if it doesn't work for you.

Без комментариев, тему просто закроем и всё.

Для такого проброса белый адрес нужен. Далее укажите Режим работы (IPv4) — Прямой доступ.

This description is not at all sufficient to understand the reasons. As we are talking about the official (preview?) version, please, contact the tech support. Provide them with a self-test at the moment when the problem reproduces, and at the moment right after intelliQos is turned on/off, when it works fine.

(Reclassifying it as a feature request.) That's harder to implement than you might think, because the Wi-Fi system is by design based on the HTTP/S protocol and KeenDNS access with a fixed set of ports, and such manual configuration would violate its integrity. You may not use the Wi-Fi system at all. Having only two devices, it's easy to configure equal SSID, PSK, MDID, roaming key etc. manually, and you will get the same Wi-Fi capabilities. The HTTP port setting will be unblocked then.

Please continue with support@keenetic.de, that's the proper contact window for you. They will have to work out the procedure, even if it doesn't exist now.

Please, drop a message to support@keenetic.de. It makes no sense to open this kind of discussion here.

@rAcKShen @alxmslv thank you! It must've been "cloudcontrol" that triggered implicit installation of "ndns" on the server side. (Independent components, however!) Should be fixed now, please check.

Please, post your "show version" output. (There might be an implicit dependency on the server side. Just want to see, what other components are installed besides KeenDNS to fix the server-side rules.)

Всё верно. Предположительно, проблема связана с переходом устройства на country=UA, который влияет не только на выбор облачного сервиса и доступность некоторых пакетов и т.д., но и на работу Wi-Fi. Если в настройках Wi-Fi страна не была указана явно, она по умолчанию была RU, а стала UA. Код региона вещается в маяках и по-разному воспринимается клиентскими устройствами. Попробуйте явно задать другой регион Wi-Fi.

self-test пришлите в личку, пожалуйста

https://blog.keenetic.com/statement-on-ukraine/

These segments are divided by design from the very beginning, because the EU personal data must be processed in full compliance with the GDPR. All devices shipped to the EU are configured in such a way that all generated data remain exclusively on the EU territory. The reason for what you said has historical roots. Some of the devices produced for Russia were sold in the CIS and Ukraine due to identical radio frequency requirements. These days, all of a sudden, it caused inaccessibility of the RU cloud services in your country as a result of protective measures. It took time for us to reconfigure the build service and release updates for the devices. You may follow the discussion on this topic here, but anyway — it does not concern the EU at all. I have to add, starting from the end of 2021, the sales in Ukraine are served from the European branch office.

Hi David, That was an outdated repository. Kernel 3.4 has its roots in the old Zyxel days. Thank you for pointing out the broken link, we have enabled redirection. The old links are working now. The official Keenetic's Github with all up-to-date sources (i.e. devices shipped to EU) is located here: https://github.com/keenetic. The requested Statement is a work in progress, as an official thing we are not discussing it here.

Будет и должен. Условия: версия 3.8 Alpha 8 или выше, установлен "Агент облачной службы", установлен пароль админа. При таких условиях устройство добавляется в RMM и открывается через web link из RMM. Если у вас не так, включайте "cloud ndmp debug", делайте одну-две попытки открыть интерфейс устройства и присылайте self-test личным или скрытым сообщением.

Всё правильно, в идеале должно работать без этой галочки. Интерфейс устройства не должен светиться. Но есть много деталей, которые остались за кадром: RMM пока всё еще бета, и ближе всего к идеалу работает прошивка 3.8. Есть совместимость со стабильной версией 3.7, но в процессе развития "облачного модуля" 3.8 и обновления бэкенда RMM может возникать регресс. Его можно обойти с помощью чек-бокса 'Доступ к веб конфигуратору' Ошибки мы ищем и исправляем на 3.8, поскольку она заменит 3.7 и станет новой стабильной версией. Когда сообщаете об ошибке, присылайте self-test, иначе будут только общие рассуждения.

Ничего не ломалось. "show internet status" что кажет?

Предоставьте self-test, пожалуйста, не просите угадывать. Отключите band-steering, часто он виноват при таких симптомах.

Тысяча благодарностей. Что произошло В 3.8 Alpha 7 была внесена ошибка. После команды "system configuration save" вместо паролей в startup-config сохранялись три звездочки "***", и после перезагрузки ни один пароль не читался. Сегодня в 12:00 мы заблокировали раздачу draft-версии, содержащей ошибку. Исправление в течение часа будет доступно для установки. Что нужно делать Тем, кто успел поставить версию 3.8 Alpha 7 сегодня до 12:00 и менял настройки, не перезагружайте устройство. Вам необходимо дождаться появления исправленной версии (об этом будет написано в Журнале), зайти в интерфейс командной строки и выполнить: copy running-config startup-config components list draft components commit В результате startup-config будет восстановлен, а устройство обновлено на исправленную 3.8 Alpha 7 (3.08.A.7.0-1).

Please try 3.8 (Dev) branch, and attach self-test if still have a problem.

What was the reason for making such modifications to the protocol? Is manual configuration (no discovery) still allows to connect existing Wireguard to your provider?

Should be fixed in the current 3.8 Dev branch. (The error is not critical, you may ignore.)