admin

Exactly. That was broken HW offloading for IPv6. Will be fixed in Alpha 11.

That would be very welcome. We have found a similar problem with DS-Lite, so both can likely be fixed in Alpha 6.

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.

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

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.

You may find the latest 3.6 version for your device here: https://drive.google.com/file/d/1-LougRiEfE56HgW4An_XEoSzOB6bKq2K/view, and even more versions here: https://drive.google.com/drive/u/1/folders/1K2mRv0AiWiXNM3vTRxKpodJrxhh2euHO However, we'd love to get any debug information from you, because it has to be fixed after all.

Hi, would you please provide more details: enable "interface CdcEthernet0 debug" wait 5 minutes and download the self-test; attach it to this topic in a hidden post disable the ping-check and see if it helps, read this for more info: https://help.keenetic.com/hc/en-us/articles/360000478579-Ping-Check-fine-tuning

For more information, read https://help.keenetic.com/hc/en-us/articles/360002426860-Internal-service-traffic