admin

Release 4.3 Alpha 10.1: IPsec: fixed printing of redundant "vici client" log messages (reported by @Denis P) [NDM-3617] IP: fixed access to my.keenetic.net from the home network (reported by @Denis P) [NDM-3618] MWS: fixed password configuration on acquired Extenders [NDM-3619] NTCE: fixed "system failed [0xcffd0532], unable to write to control file" error (reported by @Denis P) [NDM-3614]

Release 4.3 Alpha 6.2: MWS: fixed Home segment configuration on Extenders (reported by @ru.celebi) [NDM-3578] SFP: added quirks for GPON modules on KN-1012 [SYS-1248]: ODI DFP-34X-2I3 ODI DFP-34X-2IY3

Release 4.3 Alpha 6.1: Core: fixed "interface mac address factory wan" setting (reported by @lighting) [NDM-3574] Wireguard: fixed connection uptime (reported by @spatiumstas) [NDM-3567]

Release 4.3 Alpha 3.1: NTC: fixed crash in the traffic shaper (reported by @dmroot) [SYS-1226]

Thanks for reporting; it's not supposed to be like this, and it can be fixed. The uptime indication is broken here so that a shorter time from the Wi-Fi association table overwrites the network-wide value. It's too late to push any changes to the upcoming release 4.2.1, but the fix itself is trivial and will be released in 4.2.2 or so.

It is an operator's equipment issue. KeeneticOS has a feature that restarts the underlying ethernet port automatically after 5 PADO timeouts in a row. This feature is enabled by default. You are welcome to share your ideas on how to improve it.

Keenetic has necessary firewall rules enabled by default so that you don't need to duplicate them manually, and therefore, it's secure by default. The provider's router does not add any extra isolation, nor does it break any existing Keenetic isolation. The provider's router is simply a part "provider" for Keenetic, which is, by default, an untrusted (public) network. Keenetic permits no incoming connections from the outside. Keenetic segmentation adds security to your network so that if your IoT device is compromised, it will not allow access to other devices on another segment as long as they are isolated. And the ISP router in no way reduces security in this scenario.

Hi, security is enabled by default. It is based on so-called security levels. There are three security levels in KeeneticOS: private (default for Home segments), public (default for WAN connections), protected (default for Guest segment). You can get more information here: https://docs.keenetic.com/eu/carrier/kn-1713/en/22346-configuring-firewall-rules-from-the-command-line-interface.html

You may connect your Keenetic to the RMM service (https://support.keenetic.ru/eaeu/ultra/kn-1811/ru/31407-keenetic-remote-monitoring-and-management.html) and then subscribe to online/offline notifications in Telegram https://support.keenetic.ru/eaeu/ultra/kn-1811/ru/31412-telegram-notifications.html. Another option would be to book a KeenDNS domain name (https://support.keenetic.ru/eaeu/ultra/kn-1811/ru/15881-domain-name.html ) and open access to your device's web interface (https://support.keenetic.ru/eaeu/ultra/kn-1811/ru/18524-changing-the-router-management-port.html). Remember to set a strong password. KeenDNS does not need a public IP address on the device, as it can tunnel your HTTPS traffic through the cloud. Then, you may configure a third-party service such as https://uptimerobot.com/ to check your device's uptime for free. There are also options through the external package system to develop whatever you need using cron and shell scripts.

I'm afraid that no one can help based on the information you gave us. The best option for you is to talk to Keenetic's official tech support, as they can professionally request all details about your error.

This is not implemented for IPv6. Can you tell what address you expect in response to AAAA? IPv4 simply uses addresses from DHCP leases. IPv6, in contrast, has both SLAAC and DHCP (not enabled by default), and the addresses themselves are generated from multiple prefixes, which may be obtained from your ISP (multiple ISPs) and ULA. (Suppose, you want to see ULA addresses since you asked about it.)

To do that, use the "ipv6 local-prefix" command. The DHCPv6 server will slice it based on the subnet number and prefix length configured for the subnet, and use it along with the ISP's prefix. ipv6 local-prefix default — enable the default ULA prefix ipv6 local-prefix fd00:caba::/48 — set a specific ULA prefix show ipv6 prefixes — view the available prefixes, for example prefix: prefix: 2a01:c23:XXXX::/48 <---- prefix from ISP interface: PPPoE0 valid-lifetime: 251717 preferred-lifetime: 165317 global: yes prefix: prefix: fdf2:cc10:506a::/48 <---- ULA interface: valid-lifetime: infinite preferred-lifetime: infinite global: yes

My reply was based on your initial descriptions of what you were trying to do to fix the problem. None of those actions is helpful, because: - reset by pressing the RESET button clears the Wi-Fi-system binding keys, so you have to acquire the extender again. To do that, however, you will have to erase it from the controller as well. - turning the switch to A makes the device a router, but not an extender - turning the switch back to B has no effect after pressing the RESET button, because (see above) the controller still remembers it under the old keys, so you have to erase it from the controller. So, the only thing you need to do after steps 2,3 and changing the IP address of the home network, is to make the extender get a new IP address from the controller. The extender's DHCP client doesn't react quickly enough, because it waits for the lease to expire. (We can try to improve it later by sending a special command to extenders when changing the controller's IP address.) Anyway, if simple restarting of the extender (power off and on) doesn't help after steps 2,3, please file a bug report to our tech support and provide all the diagnostics they will ask for. Apart from that, you can do the procedure another way: 1. Reset the controller to factory defaults. 2. Set the IP address you wanted initially. 3. Reset the extender devices to factory defaults and turn them to B mode (extender). 4. Connect them to the controller and acquire them, just like you did initially.

After doing steps 1-3 you are not supposed to hard-reset the extenders, because this way you erase the binding keys, and you have to acquire the extenders again. So, if your extenders do not appear after changing the IP address of the main router, just re-plug their ethernet cable or reboot them to let their DHCP client get an IP address from the new network.

Hi, sorry for that, we've had a deployment issue on the weekend, so it didn't go out for some devices. We are fixing it right now.

Please make sure the problem persists after upgrading to 4.0.5. Then address this issue with the official tech support. Be ready to provide the diagnostic files when they ask.

That's a mistakenly late-activated protection rule, previously intended to protect users from installation of Alpha 12. It is supposed to be active until at least tomorrow. The mechanism of these rules still clearly needs to be further developed for such cases. We apologize for the inconvenience.

Regarding the stable firmware, please send a report to support@keenetic.de. They will instruct you how to download the diagnostics file and help with further steps.

Release 4.1 Alpha 10: DNS: fixed "Could not bind on given addresses: Address in use" error when using DNS-over-TLS [SYS-1007] IP: fixed missing traffic statistics for a number of registered devices approaching 200 [SYS-1014] IPv6: fixed CLAT functioning in backup connection mode [NDM-2885] MWS: implemented synchronization of the "readonly" tag for user accounts [NDM-2985] USB: activated USB modem components in the Dev channel for KN-2210, KN-2211 [SYS-1011] Web (beta): corrected description in the VPN connection pop-up window (reported by @dimon27254) [NWI-2994] Web (beta): fixed "Traffic monitor" page issues (reported by @dimon27254) [NWI-2999] Web (beta): fixed data output on the traffic monitor for the 1-hour time period (reported by @keenet07) [NDM-2952] Web (beta): fixed data output on traffic charts on the dashboard (reported by @dimon27254) [NDM-2913] Web (beta): fixed displaying of instantaneous values near the CPU/RAM load graphs (reported by @dimon27254) [NWI-3004] Web (beta): fixed WireGuard configuration import (reported by @T@rkus) [NWI-2997] Web (beta): fixed WireGuard private key validation (reported by @dimon27254) [NWI-2998] Web (beta): implemented band steering configuration on all segments [NWI-2992] Web (beta): optimized displaying of the connection uptime on the dashboard (reported by @dimon27254) [NWI-2988] Wi-Fi: added "force" parameter to the "interface pmf" setting [NDM-2930] Wi-Fi: fixed regression of the channel width from 80 to 20 MHz for mt7615-based devices (reported by @PriSonerS61) [SYS-1005]

Release 4.1 Alpha 9: Chilli: fixed client bandwidth limitation configured via RADIUS server options [NDM-2947] DNS: fixed applying profiles to hosts with assigned routing policies (reported by @t800) [NDM-2928] MWS: implemented transfer of additional user accounts to extenders [NDM-2871] Proxy: implemented UDP support (reported by @Skrill0) [NDM-2971]: interface {name} proxy udpgw-upstream {ip} {port} — set UDPGW remote server; interface {name} proxy socks5-udp — enable UDP mode for SOCKS5 SIP: fixed the "hash-ends-dial" function to retain the disabled state after reboot [VOX-298] VPN: fixed accounting of host traffic forwarded to non-public VPN connections [SYS-1004] Web (beta): fixed the display of extender backhaul connection details (reported by @dimon27254) [NWI-2955] Web (beta): fixed the display of the customizable header (reported by @dimon27254) [NWI-2950] Wi-Fi: enabled AX mode by default for KN-3610 when used as an extender [SYS-997] Wi-Fi: fixed kernel crash in FT_KDP_EventInform [SYS-994] Wi-Fi: fixed termination of concurrent dual-band site survey [SYS-989] Wi-Fi: increased the number of SSIDs up to 7 on each band* [SYS-995] Wi-Fi: implemented sequential shutdown of bridged interfaces when a broadcast storm occurs [SYS-1003] * Note: BSSID MAC addresses on dual-band devices may have changed.

The current implementation of KeenDNS does not support direct IPv6. It resolves your KeenDNS name into the cloud IPv6 addresses only. The only option is to connect to the IPv6 address directly without HTTPS. The Web interface is accessible by IPv6 in version 4.0 only, so please upgrade your device to 4.0 (Preview).

Hi, this is not a "Dev channel issue", please continue communicating with the official tech support.

@roman_sh: thanks for reporting! The bug will be fixed in the next releases.

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.