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]

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.