admin

Our local MAP-T emulator in the test lab doesn't show any problem. Please, attach a self-test from 4.0 Alpha 4 as a hidden message to this topic.

This is intentional behavior https://help.keenetic.com/hc/en-us/articles/360000360760-Port-forwarding. The port forwarding rule opens firewall automatically for the specified port. If you want to disable access to the host, simply remove the port forwarding rule.

Please, address your bug reports to the official tech support. You may also check if the issue is fixed in the 3.9 version available through the Dev channel for your device.

Accepted. Your post is hidden just in case it contains sensitive information. Still visible to @Le ecureuil

There are some relevant command-line settings for you. ip dhcp pool {name} domain {domain} ip dhcp pool {name} update-dns {name} is normally _WEBADMIN. If your home devices send their hostnames by DHCP, these who options will automatically add DNS records "{hostname}.{domain}" for all such devices. You can also add static DNS records manually: ip host some.domain.name {ip-address} To check which entries are currently active, look for static_a lines in the output of: show dns-proxy

The initial error (unknown option "a") is hotfixed in 3.09 Beta 0.6. The @r13's one cannot be easily reproduced. We'll leave it until next time 💤

Please, reinstall 3.9 Alpha 7 from the server. We've recently published a hotfix with the same version title. First, you need to install some older backup firmware (hopefully, you saved it), and then update to the current draft version.

Please check out the latest 3.9 Alpha 7 (Dev) version. There's a specific fix for A52.

Yes, it will. The device will automatically reboot as soon as you upload the file. The startup-config only applies when the device starts up.

@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.

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.)

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.

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.)

@KYTECHNGAMING there's a new feature "Clubs" I just enabled for you. Can you try? (Let us know if it fails, we never tried before)

The Wi-Fi button and Wi-Fi toggles in the web interface are independent controls. The system architecture is: WifiMaster0 — 2.4 GHz radio WifiMaster0/AccessPoint0 WifiMaster0/AccessPoint1 ... WifiMaster1 — 5 GHz radio WifiMaster1/AccessPoint0 WifiMaster1/AccessPoint1 ... The button controls the WifiMaster interfaces. It turns radio on and off. The AccessPoints are logical multi-SSID interfaces on top of WifiMaster. So, they stop working when you turn the radio off using hardware button. On the other hand, access points have individual controls in the web interface. These software controls cannot enable Wi-Fi if you disabled the whole WifiMaster, because hardware switch has a higher priority. When someone at home turns the WifiMaster on using the button, the AccessPoint interfaces may be disabled using software. This logic may be not obvious from the GUI point of view, but it's not a bug, and works exactly as designed.