All Activity

Vorrei suggerire l'implementazione di una funzionalità software per migliorare la stabilità e la gestione del Wi-Fi a 5GHz, simile a quanto già presente in apparati professionali (come Ubiquiti per esempio). Attualmente, quando la selezione del canale 5GHz è impostata su "Auto", i router Keenetic scansionano l'intero spettro, includendo e preferendo da come vedo i canali DFS (52-144), soprattutto quelli superiori al 100. Sebbene questi canali offrano più larghezza di banda, a volte la frequenza viene disattivata troppe volte. Il router è costretto a interrompere le trasmissioni per 10 o 1 minuto (come da manuale) a seconda se è canale 100 e superiore o 52 e superiore, causando instabilità. Al momento, l'unica soluzione per l'utente è bloccare manualmente un canale specifico (36, 40, 44 o 48), perdendo però i vantaggi della selezione automatica in caso di interferenze. Soluzione proposta: Aggiungere un semplice interruttore (Toggle) nelle impostazioni Wi-Fi 5GHz: "Consenti l'uso dei canali DFS" (Sì/No). Se impostato su SÌ (default): Il router continua a funzionare come ora, scegliendo tra tutti i canali disponibili. Se impostato su NO: L'algoritmo di selezione automatica viene limitato esclusivamente ai canali non-DFS (dal 36 al 48).

The problem occurs when upgrading the device in the mesh system. The main device receives the update, but update checks cannot be performed for the devices in the mesh. Additionally, the devices in the mesh cannot be reached Keendns.

-Google Translate: Hello, I recently received help from AI while troubleshooting some issues with my router, and it was very helpful. I had an idea about how to integrate this into the system, and I'd like to share this model with you. Adding such a feature would be beneficial. The visual is roughly prepared to help understand the logic. It could be a similar model.

funny. nobody answers here

Release 5.1 Alpha 3 DynDNS: fixed the 'URL must be filled for custom type' error preventing operation with custom servers (reported by @snark) [NDM-4292] Web: implemented turning off the modem power cycle for custom Internet availability checker modes [NWI-4629] Web: improved the port forwarding rule management buttons for the mobile view of the registered client settings (reported by @dimon27254) [NWI-4672] Web: corrected the sorting of clients by IP address in the client lists (reported by @dimon27254) [NWI-4677] Wireguard: added support for advanced ASC parameters via configuration file import or by using CLI (requested by @FLK) [NDM-4298] interface {name} wireguard asc {jc} {jmin} {jmax} {s1} {s2} {h1} {h2} {h3} {h4} [{s3} {s4} {i1} {i2} {i3} {i4} {i5}]

It's incredibly inconvenient that you have to log in again about 10 minutes after logging in. After a short period of working with the router, the browser requires you to re-enter your login password.

Release 5.0.7 (preview): DynDNS: added the DuckDNS preset [NDM-4273] Hotspot: implemented commands to turn off the SSDP and WS-Discovery network host discovery methods [NDM-4283] interface {name} ssdp disable interface {name} wsd disable HTTP: enhanced the process for renewing the SSL certificate for the system domain name [NDM-4284] LTE: implemented a timeout mechanism to switch back to the primary SIM on the dual-SIM modem [NDM-4129] interface {name} suspend timeout {seconds} interface {name} suspend schedule {schedule} MWS: fixed the issue with the connection display for wired client devices [NDM-4282] Web: implemented turning off the modem power cycle for custom Internet availability checker modes [NWI-4629] Web: added support for IPv6 URIs when configuring DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) secure DNS servers [NWI-4610] Web: improved toggle state indication [NWI-4661] Web: fixed the shortening of client names (reported by @dimon27254) [NWI-4668] Web: fixed the sorting mode icon display in content filter settings (reported by @dimon27254) [NWI-4671] Web: fixed the actuation of toggles for the mobile view (reported by @spatiumstas) [NWI-4632] Web: fixed the tooltip display in proxy connections list (reported by @spatiumstas) [NWI-4670] Web: improved the line wrapping for the mobile view of the system log (reported by @spatiumstas) [NWI-4680] Wi-Fi: resolved the issue of the channel width decreasing below 80 MHz when the Adjustment ZeroWait DFS is active [SYS-1544] Wi-Fi: eliminated security vulnerabilities [SYS-1542] CVE-2014-3570 CVE-2022-4304

I added "ip nat Chilli0" to my config on Keenetic router. Then the issue is resolved. I don't understand. Why is this needed ? Shouldn't it be enabled by default ? Also , if I don't add Firewall rule "tcp allow any" to the Guest interface, the user can not get to the UAM server login page. Why ?

Hello, I'm trying to implement a captive portal on a Keenetic router in the guest network. My UAM and RADIUS servers are ready. I've entered the necessary parameters into the captive portal's "my profile" section as follows: UAM_Server: http://192.168.1.40:3990/login UAM_Secret: secret_2024 Radius Server: 192.168.1.40 Radius Secret: radius_secret RADIUS NAS ID: keenetic I'm trying to access it from an Android phone. When I connect to the Guest page, I'm redirected to the login page. There, I only authenticate by clicking the "accept" button. And I see "success" in the logs. 10.1.30.6 - - [21/Feb/2026 23:59:47] "GET /login?res=notyet&uamip=10.1.30.1&uamport=3990&challenge=e2fa752793a8de730eb4daebd27f5992&called=52-FF-20-F8-5D-78&mac=B2-D0-DC-7D-9C-B4&ip=10.1.30.6&nasid=keenetic&sessionid=177171836000000005&userurl=http://play.googleapis.com/generate_204&md=23DA19D9D824E0D449FBFA23DD88F63F HTTP/1.1" 200 - 10.1.30.6 - - [21/Feb/2026 23:59:47] "GET /favicon.ico HTTP/1.1" 404 - 10.1.30.6 - - [21/Feb/2026 23:59:48] "POST /accept HTTP/1.1" 302 - 10.1.30.6 - - [21/Feb/2026 23:59:48] "GET /login?res=success&uamip=10.1.30.1&uamport=3990&called=52-FF-20-F8-5D-78&uid=B2-D0-DC-7D-9C-B4&timeleft=300&mac=B2-D0-DC-7D-9C-B4&ip=10.1.30.6&reply=Welcome&nasid=keenetic&sessionid=177171836000000005&userurl=http://play.googleapis.com/generate_204&md=E50C1463B84B2838B5FF3801A094F6C3 HTTP/1.1" 200 - Then, when I check the router's CLI, I see that the client is connected and packets are being passed through: (config)> show interface Chilli0 chilli host: session-id: 177174301100000003 user: CC-F8-26-D5-00-96 ip: 10.1.30.20 mac: cc:f8:26:d5:00:96 start-time: 178 end-time: 300 idle-time: 0 idle-time-limit: 0 tx-bytes: 37575 tx-bytes-limit: 0 rx-bytes: 19874 rx-bytes-limit: 0 tx-speed: 0 tx-speed-limit: 0 rx-speed: 0 rx-speed-limit: 0 It's receiving the IP address 10.1.30.20. However, the Android client still doesn't see itself as connected and can't access web pages. The "Sign in to the network" warning persists. When I ping 10.1.30.20 from the router: PING 10.1.30.20 (10.1.30.20): 56 data bytes 64 bytes from 10.1.30.20: seq=0 ttl=64 time=79.626 ms 64 bytes from 10.1.30.20: seq=0 ttl=64 time=79.683 ms (DUP!) 64 bytes from 10.1.30.20: seq=1 ttl=64 time=29.208 ms 64 bytes from 10.1.30.20: seq=1 ttl=64 time=29.251 ms (DUP!) 64 bytes from 10.1.30.20: seq=2 ttl=64 time=51.577 ms 64 bytes from 10.1.30.20: seq=2 ttl=64 time=51.641 ms (DUP!) If I close the captive portal and access the site normally as a guest, I get the same IP address (10.1.30.20) and the ping result is correct: PING 10.1.30.20 (10.1.30.20): 56 data bytes 64 bytes from 10.1.30.20: seq=6 ttl=64 time=1135.330 ms 64 bytes from 10.1.30.20: seq=7 ttl=64 time=135.173 ms 64 bytes from 10.1.30.20: seq=8 ttl=64 time=10.261 ms 64 bytes from 10.1.30.20: seq=9 ttl=64 time=5.695 ms 64 bytes from 10.1.30.20: seq=10 ttl=64 time=3.116 ms When I look at the interfaces for the captive portal and the normal guest via the router, I see a difference: When there is no captive portal, the interface name appears as Guest and "link: up". When there is a captive portal, the interface name appears as Chilli0 and "link: down". (config)> show interface Chilli0 id: Chilli0 index: 0 interface-name: Chilli0 type: Chilli description: Guest network traits: Ip traits: Chilli link: down connected: yes state: up mtu: 1500 tx-queue-length: 1000 admin-only: no address: 10.1.30.1 mask: 255.255.255.0 uptime: 35 global: no security-level: protected bridge: interface, link = yes: GigabitEthernet0/Vlan3 interface, link = yes: WifiMaster0/AccessPoint1 interface, link = yes: WifiMaster1/AccessPoint1 uam-auth: 192.168.1.40:3990 max-auth: 1 summary: layer: conf: running ipv4: running ctrl: running (config)> show interface Guest id: Bridge1 index: 1 interface-name: Guest type: Bridge description: Guest network traits: Mac traits: Ethernet traits: Ip traits: Ip6 traits: Supplicant traits: EthernetIp traits: Bridge link: up connected: yes state: up mtu: 1500 tx-queue-length: 0 admin-only: no address: 10.1.30.1 mask: 255.255.255.0 uptime: 421 global: no security-level: protected ipv6: addresses: address: fe80::50ff:20ff:fef8:5d78 prefix-length: 64 proto: KERNEL valid-lifetime: infinite mac: 52:ff:20:f8:5d:78 auth-type: none bridge: interface, link = yes: GigabitEthernet0/Vlan3 interface, link = yes: WifiMaster0/AccessPoint1 interface, link = yes: WifiMaster1/AccessPoint1 summary: layer: conf: running link: running ipv4: disabled ipv6: disabled ctrl: running (config)> Because of this difference, the client connecting through the captive portal cannot access the site. Where is the problem? How can I fix it?

I am experiencing a persistent issue with PlayStation 5 connecting to my Keenetic Titan. While the console passes the built-in "Internet Connection Test", it consistently fails to connect to online services in games (Gran Turismo 7 and F1 25). Wi-Fi Handshake Mismatch: In the Keenetic Device List, the PS5 consistently connects at 11ac 2x2 40MHz or 11ax 2x2 40MHz, even when forced to 5GHz-only and with the router set to manual channels (36, 44, 149) and 80MHz width. The "Extender" Proof: When I connect the PS5 to a TP-Link Wi-Fi extender located in the same spot, the connection immediately stabilizes at 11ac 80MHz, and all games connect to online services perfectly. This suggests the Titan's environmental or "smart" logic is forcing a 40MHz downshift that breaks the game handshakes. Configuration Tested: I have already tried disabling IPv6, setting Static IPs, disabling "Internet Safety" (DNS filters), and manually setting MTU to 1450/1473.

Release 5.1 Alpha 2 Hotspot: implemented commands to turn off the SSDP and WS-Discovery network host discovery methods [NDM-4283] interface {name} ssdp disable interface {name} wsd disable HTTP: enhanced the process for renewing the SSL certificate for the system domain name [NDM-4284] LTE: implemented a timeout mechanism to switch back to the primary SIM on the dual-SIM modem [NDM-4129] interface {name} suspend timeout {seconds} interface {name} suspend schedule {schedule} MWS: fixed the issue with the connection display for wired client devices [NDM-4282] Storage: improved operation with USB drives that report abnormal 'discard' capabilities [NDM-4291] Web: implemented turning off the modem power cycle for custom Internet availability checker modes [NWI-4629] Web: fixed the sorting mode icon display in content filter settings (reported by @dimon27254) [NWI-4671] Web: fixed the tooltip display in proxy connections list (reported by @spatiumstas) [NWI-4670] Web: improved the line wrapping for the mobile view of the system log (reported by @spatiumstas) [NWI-4680] Wi-Fi: resolved an issue where the ZeroWait DFS adjustment prevents the use of selected Wi-Fi channel width [SYS-1544] Wi-Fi: eliminated security vulnerabilities [SYS-1542] CVE-2014-3570 CVE-2022-4304

after updating 5.0.6 to 5.1 alpha 1 media server doesn't work - it shown in interface as ON, and configured - doesn't show up on network player - doesn't show up in logs (there's no `Dlna::Server: service started.` message) - reinstalling component doesn't help - downgrading to 5.0.6 helps context: router has "recommended" components installed + dlna, transmission, ftp, smb, DoH, DoT, ext4 (no opkg)

The main thing is that everyone is silent, no one who is knowledgeable will write an explanation. It seems that the developers only read the Russian forum.

there is ssl issues, it seems.

+1

Release 5.1 Alpha 1 Dns: implemented basic access authentication (RFC 7617) for DNS-over-HTTPS (DoH) server URIs [NDM-4168] DynDNS: added the DuckDNS preset [NDM-4273] IPv6: implemented IPv6 access lists [NDM-4130] ipv6 access-list {acl} ipv6 access-list {acl} (permit | deny) ((tcp | udp) ({source} | (host {source}) | any) [port (((lt | gt | eq) {source-port}) | (range {source-port} {source-end-port}))] ({destination} | (host {destination}) | any) [port (((lt | gt | eq) {destination-port}) | (range {destination-port} {destination-end-port}))]) | ((((ipv6 | esp | ahp | pcp | sctp)) | {protocol}) ({source} | (host {source}) | any) ({destination} | (host {destination}) | any)) | (icmp ({source} | (host {source}) | any) ({destination} | (host {destination}) | any) [(icmp-message | ({icmp-type} [{icmp-code}]))]) ipv6 access-list {acl} rule {index} (disable | (schedule {schedule}) | (order {new-index}) | (description {description})) ipv6 access-list {acl} auto-delete KeenDNS: fixed updating static DNS records after switching the service from cloud to direct mode [NDM-4255] Storage: implemented tools to check and format the file system [NDM-4239] media {name} partition {partition} check media {name} partition {partition} format {type} Web: added IPv6 rule configuration to firewall [NWI-4614] Web: dedicated a page for configuring storage devices and USB devices [NWI-4583] Web: added support for IPv6 URIs when configuring DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) secure DNS servers [NWI-4610] Web: fixed editing of DNS-based routing rules (reported by @dchusovitin) [NWI-4622] Web: fixed the actuation of toggles for the mobile view (reported by @spatiumstas) [NWI-4632] Web: fixed the shortening of client names (reported by @dimon27254) [NWI-4668] Web: improved toggle state indication [NWI-4661] Web: implemented reordering of DNS-based routing rules [NWI-4659] Wi-Fi: fixed the cause of Wi-Fi clients dropping from 80 MHz channel width when the Adjustment ZeroWait DFS was triggered [SYS-1544] ZeroTier: implemented an option to connect to custom networks that use private root servers (moons) [NDM-4236] interface {name} zerotier orbit {world-id} {moon-id}

it seems issue has been resolved. i can now access my keendns addresses.

I checked and as of now, Keendns is working again. Hopefully it won't stop working again.

Hello everyone. A few days ago, when switching to the router's web interface, errors started appearing. Sometimes there is an error "no connection", sometimes there is a "DNS_PROBE_FINISHED_NXDOMAIN" error. I tried from different locations from different PCs.

The same problem today

The KeenDNS connection problem started after updating the modem to version 5.0.4. There were intermittent disconnections and drops, and finally, the problem of not being able to access KeenDNS at all. Is this a new update or a different issue? When I click on KeenDNS via the mobile application, I get the same error: "This site cannot be reached. Please check if there are any errors in my writing."

problem still persist

I have the same problem and it still persists. What is the problem?

5.1 is an experimental branch, see also changelog 5.0. Supported models: Giga (KN-1010) Hero (KN-1011, KN-1012) Start/Starter (KN-1111, KN-1112, KN-1121) Air/Explorer (KN-1613, KN-1621) Extra/Carrier (KN-1711, KN-1713, KN-1714, KN-1721) Ultra/Titan (KN-1810, KN-1811, KN-1812) Viva/Skipper (KN-1910, KN-1912, KN-1913) Omni DSL (KN-2011, KN-2012) Extra DSL/Carrier DSL/Skipper/Speedster DSL (KN-2111, KN-2112, KN-2113) Runner 4G (KN-2210, KN-2211, KN-2212, KN-2213) Hero 4G (KN-2310, KN-2311) Hopper 4G+ (KN-2312) Hero DSL (KN-2410) Peak DSL (KN-2510) Giant (KN-2610) Peak (KN-2710) Orbiter Pro (KN-2810) Skipper 4G (KN-2910) Speedster 4G (KN-2911) Speedster (KN-3010, KN-3012, KN-3013) Buddy 4 (KN-3210, KN-3211) Buddy 5 (KN-3310, KN-3311) Buddy 5S (KN-3410) Buddy 6 (KN-3411) Voyager Pro (KN-3510) Hopper DSL (KN-3610, KN-3611) Sprinter (KN-3710, KN-3711) Sprinter SE (KN-3712) Hopper (KN-3810, KN-3811) Hopper SE (KN-3812) Challenger (KN-3910) Challenger SE (KN-3911) Racer (KN-4010) Buddy 6 SE (KN-4410) Explorer 4G (KN-4910) Orbiter 6 (KAP-630)

Ok Thanks