All Activity
- Yesterday
-
Владислав Симаков joined the community
-
JohnnyVoke joined the community
-
Lukian7506 joined the community
- Last week
-
cp0 started following can't access entware root
-
Hello, I have installed entware to a usb disk for keenetic hero 2410. After I removed and reinserted the usb disk I completely locked out of entware ssh connection. It doesn't accept the password, returns "Bad password attempt for 'root'" in the system log. I also created another user, but it is the same there. SSH connection accepts router interface accounts, and it works the same as web cli. On the other hand, the disk is displayed correctly in the router interface and, the apps I installed on the disk are working as usual, like nut (network ups tools). I also have sftp access which also access that disk too. What should I do to regain access to entware ssh?
-
Hi Keenetic team, When setting a manual update-interval for DynDNS, the router appears to send updates even if the public IP hasn't changed. This leads to unnecessary updates and can cause problems with services like No-IP, which softly require that updates are only sent when the IP actually changes—otherwise, users may hit rate limits or be flagged for abuse. Suggested Improvements: When update-interval is set, skip updates if the IP hasn’t changed. This would align better with DDNS service expectations and reduce noise. Add a CLI option to force update even if the IP is unchanged, for manual or scripted use. This small change would make DDNS behavior more efficient and compliant with provider guidelines. Thanks for your consideration! Best regards
-
Hi, About a week ago, my internet service provider started assigning IPv6 addresses with a /56 prefix. The Keenetic router successfully receives a global IPv6 address and prefix, and I can confirm that IPv6 connectivity is working. However, the “Cloud Access” toggle under KeenDNS settings stays disabled (grayed out) and cannot be enabled. Interestingly, I have two friends using a different ISP and they both have this option enabled and working. Another friend using the same ISP as I do also has this option disabled — just like me. This makes me think the issue could be somehow related to my ISP, but I don't quite understand how that would block the Cloud Access option. I also checked the self-test file, and the KeenDNS hostname already has a global IPv6 address assigned with an AAAA record. Do you have any idea what could be causing this issue or what else I can check? Thanks in advance!
-
Access to router over IPv6 (Web, SSH)
ru.celebi replied to atam's question in Community Support & Knowledge Exchange
I’m in the same situation as you — my ISP only provides IPv4 through CGNAT, but I do receive a public /56 IPv6 prefix, which I actively use. 1. Web Interface Access over IPv6 You can access Keenetic's web interface remotely via IPv6, but only if HTTP is enabled. HTTPS does not work at all, because Keenetic does not have a valid SSL certificate installed by default. That’s why HTTPS connections are rejected by browsers. To enable HTTP access: Go to Users & Access > Management Access in the Keenetic web interface. Enable the "Remote web access" option. Make sure only HTTP is selected (HTTPS won’t work without a valid certificate). Copy the device's IPv6 address from the interface. Access it in your browser like this: http://[your_ipv6_address] 2. Telnet and SSH Access over IPv6 Telnet works over IPv6. You can connect to Keenetic using a Telnet client and the device’s global IPv6 address. SSH does not work over IPv6, even if it’s enabled in the web interface. This is likely because Keenetic does not support SSH over IPv6 at all (at least in current firmware versions). -
Site-to-site IPsec VPN and Broadcast routing
SySOPik replied to alasedo's question in Dev channel issues & test reports
EoIP - Earlier
-
Site-to-site IPsec VPN and Broadcast routing
alasedo posted a question in Dev channel issues & test reports
Hello, There are Keenetic Peak DSL (KN-2510) devices in 2 different locations. These devices are connected to each other with Site-to-site IPsec VPN. Is it possible to broadcast from point A to point B and/or point B to point A? When I enter the lobby of the Red Alert 2 Yuri game, local network players can see each other, but I cannot see the players in 2 different locations connected with Site-to-site IPsec VPN. Is there a way to solve this problem ? Kind regards. -
Now, both on the http://192.168.1.1/wifi-monitor/utilization tab and on the widget, you can alternately view the load of the selected channel, i.e. choosing either 2.4 GHz or 5 GHz. I would like to be able to view both ranges simultaneously, both on the widget and on the tab!!!
-
- 2
-
-
-
When I connect to Openconnect Vpn server than I'm able to connect to my local resources but not reach to internet on the vpn client (NAT check box already selected). Also, I check my route table in the windows (with route print command) then it didn't show second default route assigned by Opencconect. Unable to route all traffic through openconnect vpn
-
up
- 1 reply
-
- wake on lan
- task scheduler
-
(and 1 more)
Tagged with:
-
Feature Request: Add "Reboot" Button for Mesh Nodes
alasedo replied to ru.celebi's question in Feature Requests
+1 -
Hi, thanks for the suggestion—I actually need to verify a raw TCP handshake against my SOCKS5 port. However, when I list the available mode options in my Keenetic CLI, “tcp” isn’t there. I only see modes like icmp, http, and tls. Is there any way to force a pure TCP-connect check in this firmware, or has “tcp” been renamed to something else?
-
Please consider adding a "Reboot" button next to the existing Edit and Remove buttons in the mesh device management interface. Currently, restarting a mesh node requires logging into each device separately, which is inefficient and time-consuming. Suggested Placement: [Update] [Edit] [Remove] [Reboot] This addition would make it much easier to manage and restart mesh nodes directly from the controller interface.
- 1 reply
-
- 2
-
-
Release 4.3.1 (preview): DynDNS: fixed saving of 'dyndns nobind' setting [NDM-3816] HTTP: fixed redundant disclosure device information [NDM-3783]: CVE-2024-4021 CVE-2024-4022 IP: fixed applying static routes in multiple IP policies [NDM-3814] IP: fixed assignment of "conform" policy after automatic client registration [NDM-3810] IPsec: fixed wrong "crypto map" use in L2TP/IPSec server settings [NDM-3811] OpenConnect: added random padding to packets to improve connection resistance (reported by @dimon27254) [NDM-3791] OpenConnect: fixed access to the VPN server's attached network [NDM-3820] TSMB: enabled support for extended attributes (reported by @dimon27254) [NDM-3645] VPN: added 'session-logout' command to terminate VPN sessions (reported by @CBLoner) [NDM-3788]: crypto map l2tp-server session-logout {session} crypto map virtual-ip session-logout {session} sstp-server session-logout {session} vpn-server session-logout {session} oc-server session-logout {session} Web: added "https://" to OpenConnect VPN server URI when camouflage is enabled [NWI-4146] Web: added alphabetical sorting to Policy Bindings [NWI-4092] Web: fixed various bugs and layout issues on different screen sizes (reported by @dimon27254, @spatiumstas, @enterfaza, @FLK, @mrGhotius) [NWI-4191]: NWI-4168, NWI-4161, NWI-3901, NWI-4108, NWI-3922, NWI-4083, NWI-4085, NWI-4122, NWI-4125, NWI-4136, NWI-4134, NWI-4135, NWI-4139, NWI-4141, NWI-4130, NWI-4169, NWI-4080, NWI-4160, NWI-4151 Web: implemented display of users in file ACLs for which the system has no accounts configured [NWI-3951]
-
Kelchug changed their profile photo
-
WiFi legacy incompatibility
alfonder replied to alfonder's question in Community Support & Knowledge Exchange
Additionally, here is the log from ku_rd on successful connection of the scale: [I] Apr 25 00:46:52 ndm: Network::Interface::Mtk::WifiMonitor: "WifiMaster0/AccessPoint1": STA(d0:49:00:2f:c1:91) had associated. [I] Apr 25 00:46:52 ndm: Network::Interface::Mtk::WifiMonitor: "WifiMaster0/AccessPoint1": STA(d0:49:00:2f:c1:91) set key done in WPA2/WPA2PSK. -
Hello, I'm facing a strange issue with my Keenetic router and I hope someone can help or has experienced something similar. I'm trying to share my phone's VPN connection with my Keenetic router via USB tethering. Since direct VPN sharing over USB isn't possible, I'm using the Easy Proxy app on my phone to create a SOCKS5 proxy. My goal is to configure this SOCKS5 proxy on the Keenetic router so that all connected devices can use the VPN through the proxy. Here’s the problem: When I enter any proxy address (even an invalid one like 1.2.3.4:9999), Keenetic always shows "Connected (IP address 172.20.12.1)" in the proxy settings. Even though it says "Connected", I know for sure that the connection isn't actually established, especially when using invalid addresses. When I try to connect to the SOCKS5 proxy generated by Easy Proxy (while USB tethering is active), Keenetic keeps showing "Connection failed" in practice, but still displays "Connected" in the status. I suspect that 172.20.12.1 is some kind of internal routing address used by Keenetic, but I’m not sure why it always shows as connected without validating the proxy server. My setup: Phone with USB tethering enabled and VPN active, Easy Proxy app running SOCKS5 server, Keenetic router (latest firmware). I’m trying to configure Keenetic to route traffic through the SOCKS5 proxy. What I've tried: Tested with both valid and invalid proxy addresses — always shows "Connected". Checked IP on client devices — no traffic seems to go through the proxy. Updated Keenetic firmware to the latest version. Reviewed system logs but couldn't find clear error messages regarding proxy failures. Has anyone experienced this issue where Keenetic's proxy settings always display "Connected" regardless of the actual connection status? Is there a proper way to route VPN traffic from a phone to Keenetic via SOCKS5 over USB tethering? Is there any way to force Keenetic to validate the proxy connection instead of just marking it as connected? Could this be a firmware-related bug or limitation? Any advice, workaround, or insight would be greatly appreciated! Thanks in advance.
-
I would be glad, if you could add controld DNS to the Internet security section. Thanks :0)
-
Three segments in one IP zone, two have no internet.
maemelyanov replied to maemelyanov's question in Community Support & Knowledge Exchange
In this text, I meant that: Network: IP address: 192.168.1.1 Subnet mask: 255.255.255.0 (/24) I divided it into three parts according to the created segments: a) Segment "Home network" (segments/Bridge0): IP address: 192.168.1.1 Subnet mask: 255.255.255.224 (/27) b) Segment "Guest network" (segments/Bridge1): IP address: 192.168.1.32 Subnet mask: 255.255.255.224 (/27) c) Segment "WorkStation network" (segments/Bridge3): IP address: 192.168.1.96 Subnet mask: 255.255.255.224 (/27) Yes, saved successfully. Got it. I'll send it in the next post. -
Three segments in one IP zone, two have no internet.
eralde replied to maemelyanov's question in Community Support & Knowledge Exchange
Hello @maemelyanov Could you elaborate on this part: ? Was the segments configuration you described saved successfully (i.e. if you reload the web UI, do you see it configured there)? Also, it would be great if you could attach a self-test file from your device to this thread and hide the post with it (moderators will still be able to see it). -
Colleagues, hello everyone! I ask for your help, because I did not find the answer to my problem! I will be very glad if you tell me the solution to my problem! Model: Keenetic Ultra (KN-1810) System Update: OS version: 4.2.6.3 What I want to do and what I did. What I want to do: - by DHCP, for each segment, assign a pool of IP addresses, in one network. - and for the Internet to work in each segment. What I did: a) segment "Home network", (segments/Bridge0): IP Settings Specify the IP parameters for "NW Home": IP address: 192.168.1.1 Subnet mask: 255.255.255.224 (/27) - DHCP settings: Starting IP of the pool: 192.168.1.3 Address pool size: 28 - Gateway IP: did not specify - Use NAT: enable b) segment "Guest network", (segments/Bridge1): IP Settings Specify the IP parameters for "NW Guest": IP address: 192.168.1.32 Subnet mask: 255.255.255.224 (/27) - DHCP settings: Starting IP of the pool: 192.168.1.33 Address pool size: 30 - Gateway IP: did not specify - Use NAT: enable c) segment "WorkStation network", (segments/Bridge3): IP Settings Specify the IP parameters for "NW WorkStation": IP address: 192.168.1.96 Subnet mask: 255.255.255.224 (/27) - DHCP settings: Starting IP of the pool: 192.168.1.97 Address pool size: 30 - Gateway IP: did not specify - Use NAT: enable As a result, I get this: - crushed: IP address: 192.168.1.1 Subnet mask: 255.255.255.0 (/24) - into three parts, each segment with 30 IP addresses via Subnet mask BUT, at the same time: a) the "Home network" segment (segments/Bridge0): - works properly, both by wire and by Wi-Fi. And all other segments: - devices connect, but there is no access to the Internet. Please tell me what is the reason?
-
maemelyanov changed their profile photo
-
22/04/2025 Keenetic RMM New Added an event on changing the site status from “Online” to “Confirmation of rights required” [CIR-4363] Added a limit on the size of the event log export file [CIR-4357] Improved filters on Site detail page [CIR-4275] Added new design of “Reset” button [CIR-4362] Added blocking of seamless access to web interface for read-only role if OS version is less than 3.8 [CIR-4444] Fixed Fixed total items counter [CIR-4276]
-
A WiFi scale (probably ESP32 based) uses 2.4 GHz to sync. The problem is: the device connects successfully to the old Keenetic Ultra2, but can't connect to the modern Keenetic Challenger SE (KN-3911) with the same WiFi settings. ku_rd config fragment: interface WifiMaster0 country-code DE compatibility BGN rekey-interval 86400 up ! interface WifiMaster0/AccessPoint0 rename AccessPoint description "Wi-Fi access point" dyndns nobind mac access-list type none wps authentication wpa-psk ns3 xxxxx encryption enable encryption wpa2 ip dhcp client dns-routes ip name-servers ssid Deutschland25 wmm rrm up ! interface WifiMaster0/AccessPoint1 rename GuestWiFi dyndns nobind mac access-list type none authentication wpa-psk ns3 xxxxxx encryption enable encryption wpa2 ip dhcp client dns-routes ip name-servers ssid Umbreon rrm up ! KN-3911 config fragment: interface WifiMaster0 country-code DE compatibility BGN+AX channel width 40-below tx-burst rekey-interval 86400 beamforming explicit atf inbound vht downlink-mumimo uplink-mumimo spatial-reuse up ! interface WifiMaster0/AccessPoint0 rename AccessPoint description "Wi-Fi access point" mac access-list type none wps wps no auto-self-pin authentication wpa-psk ns3 xxxxx encryption enable encryption wpa2 ip dhcp client dns-routes ssid Deutschland25 wmm rrm up ! interface WifiMaster0/AccessPoint1 rename GuestWiFi mac access-list type none authentication wpa-psk ns3 xxxxxx encryption enable encryption wpa2 ip dhcp client dns-routes ssid Umbreon rrm up ! It looks like some new features are incompatible with old legacy wifi clients. During non-successful attempts there are the next entries-set in the log: [I] Apr 21 23:18:28 ndm: Network::Interface::Mtk::WifiMonitor: "WifiMaster0/AccessPoint1": STA(d0:49:00:2f:c1:91) had associated. [I] Apr 21 23:18:28 ndm: Network::Interface::Mtk::WifiMonitor: "WifiMaster0/AccessPoint1": STA(d0:49:00:2f:c1:91) MIC differs in key handshaking (msg 2 of 4-way). [I] Apr 21 23:18:32 ndm: Core::Syslog: last message repeated 4 times. [I] Apr 21 23:18:33 ndm: Network::Interface::Mtk::WifiMonitor: "WifiMaster0/AccessPoint1": STA(d0:49:00:2f:c1:91) had deauthenticated by AP (reason: previous auth no longer valid). Can anyone suggest which setting add/remove to achieve compatibility?
-
4.2.5 - client device does not fall off the network
ru.celebi replied to PriSonerS61's question in Dev channel issues & test reports
This issue also occurs on my side. If a device leaves the network but still appears in the device list, it is usually shown as connected via 802.11a or 802.11b. Based on my observations, if the device leaves the house without manually turning off Wi-Fi—just by going out of range—it may still appear in the list. Most likely, the device fails to properly notify the router that it has disconnected from the network. A possible solution might be for the router to send periodic automatic pings to connected devices, and if no response is received after a certain number of attempts, the device can be considered offline and removed from the list.