I've just tried the new Web Shell extension on my Keenetic Hero running KeeneticOS 5.2.A.1 (draft).

When I click the button in the menu, it fails to connect. I checked my logs and realized it might be related to my custom HTTP/HTTPS admin ports. I use non-standard ports for my router management:

ip http port 65080
ip http ssl port 65083
ip http ssl redirect

And these are the errors showing up in my logs:

2026/07/18 08:33:49 [error] 1710#0: *2166 upstream prematurely closed connection while reading response header from upstream, client: 10.101.0.17, server: , request: "GET /app/webshell/ws HTTP/1.1", upstream: "http://unix:/var/nginx/ttyd.socket:/ws", host: "10.101.0.1:65080"

Jul 18 08:33:51 web-shell [2026/07/18 08:33:51:1076] W: refuse to serve WS client from different origin due to the --check-origin option.
Jul 18 08:33:51 web-shell [2026/07/18 08:33:51:1078] W: User code denied connection

I think the backend tool (ttyd) blocks the connection because of the --check-origin option since the WebUI is running on a custom port (65080).

Hopefully, this can be fixed in future updates so it can automatically accept custom ports as well. I'm sharing my logs and screenshots just in case it helps the development team.

Thanks!

Wanted to report a bug I ran into on the latest draft firmware regarding the built-in reverse proxy feature (ip http proxy).

I was accessing my Transmission WebUI through Keenetic’s proxy (ip http proxy tr -> 127.0.0.1:78). The interface loaded a bit broken initially, and as soon as I tried changing the theme settings inside Transmission, the main Keenetic Web UI completely froze and became unreachable.

Here are the quick details from my setup and testing:

• Model & Firmware: Keenetic Hero (KN-1011-EU) running KeeneticOS 5.02.A.4.0-0 (Draft)

• What still worked: Internet access, Telnet/CLI, CIFS/SMB shares, and USB storage were all fine.

• What failed: The main Web UI (both HTTP and HTTPS on default and custom ports like 65083) stopped accepting browser connections.

I logged in via Telnet to recover the WebUI without rebooting. I tried disabling the proxy (no ip http proxy tr), stopping the torrent service (no service torrent), and resetting/restoring custom HTTP/SSL port configurations (no ip http ssl port, restarting service http). However, none of these CLI commands brought the web interface back. The web server remained completely unresponsive.

I ran my show threads output and logs through an AI assistant to figure out what was happening. The analysis pointed out that a hanging HTTP stream from the proxied WebUI likely triggered a deadlock (CORE lock) in ndm's HTTP worker threads, which explains why CLI commands couldn't clear the lock immediately.

I've attached the initial self-test log captured while the Web UI was locked out.

When I open Diagnostics → Active connections, the general list of devices and connections is displayed normally. However, when I try to expand a specific device to view its active connections, the web interface freezes completely and stops responding.

This worked normally before updating to 5.2.4.

Steps to reproduce:

1. Open the router web interface.
2. Go to Diagnostics → Active connections.
3. Expand/select a specific device to view its active connections.
4. The web interface freezes completely and becomes unresponsive.

Hello Keenetic Team,

I would like to report a possible EasyMesh Ethernet backhaul issue.

Environment

• Keenetic routers configured in an EasyMesh network.
• Initial Ethernet backhaul established using a Cat5 cable.
• The Cat5 cable negotiates at 100 Mbps, which is expected.
• After the mesh network is fully established, the Cat5 cable is replaced with a Cat7 cable.

Problem

Although both routers report that the Ethernet link is connected at 1 Gbps, the actual communication between the mesh nodes continues to be limited to approximately 100 Mbps.

The system appears to keep using the previous 100 Mbps link parameters even after the physical connection has successfully renegotiated to 1 Gbps.

Expected Behavior

After replacing the cable with a Cat7 cable and the Ethernet link successfully negotiating at 1 Gbps, the EasyMesh Ethernet backhaul should immediately utilize the full Gigabit bandwidth.

Temporary Workaround

The only way I have found to restore Gigabit backhaul performance is to recreate or reinitialize the mesh connection. Simply reconnecting the Ethernet cable or waiting for auto-negotiation is not sufficient.

Additional Notes

This behavior can easily mislead users because the interface correctly reports a 1 Gbps Ethernet connection, while the actual mesh backhaul throughput remains capped at around 100 Mbps.

Could you please investigate whether this is an EasyMesh backhaul caching issue or a firmware bug?

Thank you.

I am not a network engineer; I am an ordinary user with limited resources. However, the data in my possession is clear enough to require no expertise: **the router ignores a valid IP in its own ARP table and routes traffic to an expired, "ghost" IP that has never existed on my network.** This is not an interpretation; it is a fact visible in the raw CLI outputs below.

---

## Evidence: ARP Is Correct, NAT Is Wrong

After a modem soft-reload (certificate renewal, scheduled task, etc.), the port forwarding rule appears "active" in the management panel, but traffic from the outside world does not reach the local network. The WAN connection silently times out — not "connection refused", the packet falls into a black hole at the kernel level.

This is a synchronization/cache bug in KeeneticOS's netfilter/nf_conntrack subsystem (explicitly visible as `nf_conntrack version 0.5.0` in the kernel boot logs). Two different CLI outputs captured simultaneously during an outage prove this:

**`show ip neighbour`** output shows two separate entries for the same MAC address (`de:ad:be:ef:fe:01`, my ESP32-W5500 device):

```
id: 10
via: de:ad:be:ef:fe:01
mac: de:ad:be:ef:fe:01
address: 192.168.1.114   ← valid IP, my registered static DHCP reservation
last-seen: 12             (seconds ago)
expired: no                ← VALID and ACTIVE

id: 5
via: de:ad:be:ef:fe:01
mac: de:ad:be:ef:fe:01
address: 192.168.1.102   ← an address that has never existed on my network
last-seen: 191
expired: yes                ← expired
```

**`show ip nat`** output captured at the same time shows that incoming WAN TCP/80 traffic is being forwarded not to the correct IP marked `expired: no`, but to the invalid IP marked `expired: yes`:

```
TCP  172.71.102.233   12410    [WAN_IP]        80       4
         192.168.1.102    80      172.71.102.233   12410    4

TCP  172.71.144.9     10915    [WAN_IP]        80       4
         192.168.1.102    80      172.71.144.9     10915    4
```

The port forwarding rule is defined as MAC-based (`ip static tcp PPPoE0 80 de:ad:be:ef:fe:01`). While the ARP table shows the correct IP (`.114`), the NAT/connection tracking mechanism still uses the old/invalid IP (`.102`).

> **Additional fact:** A static DHCP reservation for `192.168.1.114` is defined for this device in the modem panel. Despite this, the `192.168.1.102` address appears to have been assigned/associated with this MAC at some point — which directly contradicts the reservation rule.

**Workaround/Temporary fix:** Disabling and re-enabling the rule via CLI or panel instantly resolves the issue.

---

## Root Cause: NAT/Conntrack Layer Ignoring ARP Update

The above data points to a single conclusion: when resolving the target IP for the MAC-based forwarding rule, **the NAT/connection tracking layer continues to use a stale cached mapping instead of the current, valid entry in the ARP table.** The router itself carries conflicting information in two different layers: the ARP table says `.114` is "valid", while the NAT chain still uses `.102`. This is, by definition, a synchronization error — two internal subsystems contradict each other about the same reality.

Let me be clear: a client device cannot choose its own IP. The authority for IP assignment and addressing lies 100% with the router's DHCP server. If my device was associated with `192.168.1.102`, the entity that created and maintained that association is the router itself — and this address directly contradicts my static DHCP reservation (`.114`) defined in the panel. A DHCP server violating its own reservation rule and/or carrying this violation into the NAT chain is an error that must be sought in KeeneticOS's addressing/routing layer, not on the client side.

This is the limit of what I can detect with the tools available to me — identifying which internal function misses this synchronization is, of course, the development team's job. However, I have no doubt that the problem exists, is reproducible, and is not client-originated.

---

## Workaround

I am bypassing the issue with an external Cloudflare Worker + ESP8266 watchdog combination that sends an automated disable/enable command sequence via Telnet to the router. This works functionally but is, of course, an application-level temporary fix; the actual correction should be on the modem/firmware side.

---

## Support Process

1. I presented the issue comprehensively to the Keenetic TR technical team with syslogs, NAT tables, and a live connection.

2. Despite the technical team connecting to my computer, verifying the issue live, and recording that the device was listed as static; instead of producing a solution, I observed attempts to shift the blame onto me with technically invalid justifications that contradict network engineering principles, such as *"your device is using two IPs, it is responding to an old IP."* I subsequently requested the closure of my support ticket.

   > My request to close the support ticket does not mean I accept the "client-side" explanation provided, nor does it mean I withdraw my technical objections — it is solely because of the pointlessness of continuing the process in this manner.

3. The initial corporate solution proposed (binding DHCP/ARP/port forwarding directly to a static IP) may work in practice, but it is a workaround — it leaves unanswered the question of why MAC-based dynamic forwarding behaves inconsistently in this scenario, and it proves that the MAC-based dynamic forwarding feature described in the documentation does not work under these conditions.

4. As an ordinary user, making definitive judgments with my limited data or misinterpreting the situation does not make the WAN access loss problem invisible, nor does it grant the technical support team any justification. My use of AI-assisted analysis tools to describe my problem is not "arrogance"; on the contrary, it is to describe the problem with the correct terminology, to draw attention to a chronic bug, and to find a rational solution. Distinguishing the limits of end-user analysis, correctly evaluating the data, and finding and researching the root cause is directly the responsibility of the Keenetic support team.

---

## Conclusion

The support team's approach gave me the impression that the focus was not on resolving a possible software bug, but on "rightfully closing" the support ticket at all costs, and the connection with the support team has been terminated.

As someone who previously recommended Keenetic to my circle with pride, this corporate lack of vision has deeply disappointed me.

Therefore, I have decided to move my network infrastructure entirely to another brand. This post is not a dry criticism of a company, but rather a technical reference and warning for those who are facing a similar issue and are left helpless.

---

**For Keenetic engineers who wish to examine the logs, the support ticket number is: `#656648`**

I would like to receive information whether a fix for the problem of connecting the backup Internet via WISP will be considered. I have a case of a problem with 40+ routers, if the Internet disappears and the backup access point works, then the reconnection goes normally. If the Internet disappears, and the backup access point (phone or 4G modem) is turned on later, the router does not connect (even when I set the reconnection timeout to 30-60 seconds instead of 600). Only rebooting the router helps. It seems that the router will check several times for a backup Wi-Fi network (on demand) and then stop looking for it. The problem is in firmware 4.3.7, 4.3.8 and 5.0.12 and is always reproduced in everyday work. Unfortunately, the routers are installed in different cities, I can't copy the log, as the routers reboot and the log is erased.

message": "\"Wireguard2\": invalid I1 value."

Symptom

With "ppe hardware" enabled (the default), a long-lived WebRTC UDP media session (Opus/RTP audio, ~50 pps, to a remote SFU) degrades reliably every ~13–15 minutes: the far side stops hearing us, the client reconnects, the cycle repeats. It reproduces with two independent WebRTC clients — a Chromium-based browser client and a native one — so it is not application-specific.

Localization (two-sided nf_conntrack capture, LAN + WAN, taken live through the moment of failure):

• LAN-IN: packets from the PC keep flowing at ~50 pps — the PC is sending fine;
• WAN-OUT: the outbound translation (external IP → SFU) freezes — the outbound half of the 5-tuple stops being forwarded;
• downlink (inbound from the SFU) stays alive;
• the conntrack entry is tagged [FASTNAT].

So the hardware offload stops forwarding the outbound half of an active UDP session while the inbound half is still alive. This is not congestion (RTT stays ~30 ms, jitter low) and not an idle timeout (traffic is continuous at ~50 pps).

Root-cause isolation — exactly one variable changed:

• ppe hardware ON → failure guaranteed every ~13–15 min (many cycles in a row);
• no ppe hardware (both off) → 22.5 min call, zero drops, 0.018% loss;
• ppe software only → 34 min clean, networkScore = EXCELLENT, 0.024% loss, surviving two windows where it previously always failed.

Nothing else was changed — toggling ppe hardware deterministically breaks / fixes the path.

This is a known class of bug

The same issue was reported and acknowledged by Keenetic years ago on the older MT7620 platform — topic 1171 (in Russian): https://forum.keenetic.com/topic/1171-
A Keenetic developer (ndm) acknowledged it was their oversight: the hardware path did not account for checksum changes inside the UDP stream. It was fixed in KeeneticOS 2.09.A.0.0-3 by routing UDP through ppe software while keeping TCP on ppe hardware.

On the new MT7981 platform the symptom is back — a regression, or the automatic "UDP → software PPE" routing from 2.09 is not applied on the KN-1012. The same MT7981 SoC has an analogous hardware-flow-offload defect in OpenWrt — issue #19449 "hardware flow offloading working abnormally": https://github.com/openwrt/openwrt/issues/19449
The general "HW offload breaks long-lived UDP" class is #17915: https://github.com/openwrt/openwrt/issues/17915

Request

Please either restore the automatic routing of UDP through software PPE (as done for MT7620 in 2.09), or expose a CLI/UI switch to disable UDP offload while keeping TCP hardware offload. Right now the only workaround is a full "no ppe hardware", which gives up gigabit LAN acceleration.

Notes

The single deciding variable is the state of ppe hardware — firmware, client and network are otherwise identical across the failing and working runs, and it reproduces across independent WebRTC clients (browser-based and native). Happy to provide a self-test diagnostic file or run any additional repro on request.

I have never had problems with stable versions of firmware. This is the first time. I don't have the backup of the 4.3.7.

Can someone share the 4.3.7 version of firmware for the Keenetic City KN-1511?

Quote

 

[EFAULT] Errors:                 2 (retrying may help)
Checks:                27 / 27, 100%, Listed 72
Elapsed time:        14.7s

2026/06/11 07:34:08 NOTICE: Failed to sync with 2 errors: last error was: update getinfo: object not found
rclone failed with exit code 4

 

Attempt 2 (I previously deleted all the files on the router's hard disk)

Quote

[EFAULT] Errors: 11 (retrying may help) Checks: 0 / 0, -, Listed 55 Elapsed time: 2m1.9s 2026/06/11 07:39:30 NOTICE: Failed to sync with 11 errors: last error was: update getinfo: object not found rclone failed with exit code 4

I'm connecting via FTP protocol
Copying is done from a device on the local network to Keenetic (the hard disk is connected to the router via USB)
On 5.0.12, the same task worked, after upgrading to 5.1 Beta 4, it breaks stably.
The hard disk file system is exFAT
rclone version:
 

Quote

rclone v1.70.2
- os/version: debian 12.11 (64 bit)
- os/kernel: 6.12.91-production+truenas (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.23.5
- go/linking: dynamic
- go/tags: none

mws zone [MAC] [CID] 

When the command is used, all Wi-Fi clients on the mesh network disconnect and reconnect after a few seconds. Could you design it so that this command can run live without any on/off switching?

Problem

WiFi became completely unstable — both 2.4 GHz and 5 GHz bands affected simultaneously. Wired Ethernet worked perfectly throughout. The problem persisted across router reboots and WiFi radio restarts (interface WifiMaster0/1 down/up).

Symptoms

1. Wireless clients unable to auto-connect — must toggle WiFi off/on on the client device
2. When connected, connection drops after seconds to minutes
3. Drops are distance-dependent (worse at range) but also occur within 1 meter of the router
4. After drop, clients get stuck in "zombie state" — they think they're connected but the router has already deauthenticated them
5. Affects all client types: iPhones (iOS 18), iPads, Android (Galaxy S20 FE, Redmi A7 Pro), Huawei tablet, Denon AVR, Yandex Station, IoT sensors
6. ~15 WiFi clients on the network

Log evidence (from self-test and syslog)

PTK 4-way handshake timeouts (router sends msg 1, client never responds):

MIC corruption during key exchange:

Group key handshake timeout:

RSN IE failure:

Mass simultaneous disconnection — all clients on both bands at once:

Constant "retransmits limit reached" for multiple devices across all 3 days.

What was ruled out

• RF interference: Channel scan shows <10% load on both bands, minimal neighbor networks
• Neighbor issues: Adjacent apartments report no WiFi problems
• Channel selection: Tested manual channels (ch 11 on 2.4 GHz, ch 36/80 MHz on 5 GHz) — no improvement
• Band steering: Disabled via CLI — no improvement
• WPA3/FT: Disabled both — no improvement
• Radio restart: interface WifiMaster0/1 down/up — no improvement
• Router reboot: Full power cycle — no improvement
• Hardware failure: No kernel panics, watchdog resets, thermal warnings, or PHY errors in logs

Configuration at time of issue

• SSID: same on both bands (band-steering enabled)
• Security: WPA2 + WPA3 (SAE), PMF, Fast Transition (802.11r)
• 2.4 GHz: auto channel, 20/40 MHz, BGN+AX+BE
• 5 GHz: auto channel, up to 160 MHz, AN+AC+AX+BE
• WireGuard VPN active
• USB storage (Seagate 2TB NTFS) attached

Resolution

Switching from preview channel (5.1 Beta 1) to main channel (5.0 stable) immediately resolved all WiFi issues. No configuration changes were needed — same settings work perfectly on 5.0.

Self-test diagnostic files from during the issue are available on request.

I've attached the logs. I'm using version 5.1 Beta 3, but this error also occurs with other versions.

I also have the problem that when my mesh nodes are assigned static IPs, they no longer communicate properly with each other.

log.txt

Hello,

I would like to report a limitation (or possibly request a feature) regarding firmware update channels in the Wi-Fi System (Mesh).

On the main Keenetic router, it is possible to switch between different update channels (e.g., Main, Preview, Dev), and also downgrade to an LTS version if needed.

However, for extender/mesh devices connected within the Wi-Fi System, there is no option to control or change the update channel. As far as I can see, these devices do not provide access to LTS versions or any channel selection at all.

This creates an inconsistency, especially for users who prefer running stable/LTS firmware across all devices in the mesh network.

Is there currently a way to:

• Set the update channel (especially LTS) for mesh/extender devices?
• Or make extender devices follow the main router’s selected channel?

If not, I would like to suggest adding this feature for better consistency and control in mesh environments.

For some time i'am unable to flash update, issue popped out couple of months ago. I tried different channels and workaround, no effect.

Via web i see error after 50% complete

`The server is temporarily unavailable (code 0). Please try again later.`

with replacing firmware by .bin file

Failed to switch system boot partition

via telnet following error

`Core::System::Update::Hooks error[8586241]: failed to update the firmware: unable to commit an update.`

Self test log in attachment.

What may be wrong, how to fix this?

self-test.txt

I performed all these operations on devices running the following file systems: Ext4, exFAT, and FAT32. In every case, these files and directories became hidden. The data transfer protocol did not affect this either, as I tested it using both SMB and SFTP. The result remained the same.

In Windows 11, when using the SMB protocol, I was only able to make files and directories visible after enabling the «Show hidden files, folders, and drives» option in File Explorer and disabling «Hide protected operating system files (Recommended)».

In Android 14, when using Cx File Explorer and the SFTP protocol, these files and directories are not displayed at all. If you look at the number of items in the parent directory containing such hidden elements, all files and directories are present and are copied correctly when copying the parent directory in which they are located, but there is no way to interact with them. You can find a file manager that can handle system hidden items, but the problem here is that user files and directories that shouldn’t be system files become system files.

At first, I thought that KeeneticOS simply wouldn't return them when requested and would say they were missing, but that's not the case. All the files and directories don't disappear but become system files, which makes it impossible to work with them normally.

ENVIRONMENT

Router: Keenetic Titan KN-1812, KeeneticOS 5.00.C.7.0-0
ISP: Magyar Telekom, fiber GPON, 1 Gbps symmetric
Topology: MBP (Wi-Fi 6) → Keenetic → Magenta Box (Technicolor FGA2235, DMZ mode) → ISP
Wi-Fi client: MacBook Pro M1 Max (BCM4387), 5 GHz, 2SS/80MHz, 802.11ax
MBP is the only client on 5 GHz band
IntelliQoS config when enabled: CAKE, input 890 Mbps, output 500 Mbps

PROBLEM

When IntelliQoS is disabled (no qos), Wi-Fi upload through WAN drops to 30-50 Mbps. With IntelliQoS enabled (CAKE, output 500 Mbps), upload is stable at ~480 Mbps.

I would expect that removing the 500 Mbps shaper would increase or maintain upload speed, not collapse it by 10x.

DIAGNOSTIC RESULTS

Upload throughput (same iperf3 server, same time of day):

Pi-hole, Ethernet → Keenetic → WAN, QoS OFF:       846 Mbps
MBP, Wi-Fi 5GHz → Keenetic → WAN, QoS OFF:         23-51 Mbps
MBP, Wi-Fi 5GHz → Keenetic → WAN, QoS ON (500):    480 Mbps
MBP, Wi-Fi 5GHz → Keenetic → LAN (iperf3), QoS OFF: 595 Mbps
MBP, Wi-Fi 5GHz → Magenta Box Wi-Fi → WAN, QoS OFF: 610 Mbps
Desktop, Ethernet → Keenetic → WAN, QoS OFF:        450-640 Mbps
Desktop, Ethernet → Magenta Box directly, QoS OFF:  980 Mbps

Key observations:
1. Wi-Fi LAN throughput = 595 Mbps (iperf3) — Wi-Fi radio works fine
2. Ethernet upload through same WAN path = 846 Mbps — WAN path works fine
3. MBP on Magenta Box Wi-Fi directly = 610 Mbps — MBP Wi-Fi chip works fine
4. PHY rate during test: TX 1201, RX 960-1080 Mbps, RSSI -67...-69 — stable
5. WAN interface stats: 0 txdropped, 0 txerrors
6. Problem is specific to Wi-Fi → WAN forwarding without CAKE

What I tested (none helped):
- Disabled hardware PPE (no ppe hardware) — upload still 44 Mbps
- Disabled TSO on MBP (sysctl net.inet.tcp.tso=0) — upload still 45 Mbps

QUESTION

Is this expected behavior? It appears that the default queueing on the WAN egress path cannot handle Wi-Fi-originated traffic properly. CAKE fixes it, but requires an artificial bandwidth limit (500 Mbps) which caps upload below ISP capacity (980 Mbps).

Is there a way to enable CAKE/fq_codel without bandwidth limiting? Or another setting to fix Wi-Fi → WAN forwarding without IntelliQoS?
 

{
	"prompt": "(config)",
	"status": [
		{
			"status": "message",
			"code": "8781924",
			"ident": "Core::Legal",
			"message": "\"dpn\": accepted version 20230223."
		}
	]
}

then I pressed acquire buttom the button disappeared, so I reset to factory settings the Air, wait air comes up, but no more acquire button. So I reboot the Sprinter, again no button, I want to type again the command but can't find it more, can you please write it me here? Thank you

I'm using Keenetic Viva (KN-1910) and have a configured Wireguard tunnel between two Keenetic routers (the second one is a Keenetic Ultra (KN-1810)).

After update the Keenetic Viva to 5.0.4, I can't connect to local devices on the side of Keenetic Ultra, but the Wireguar connection looks ok in the web ui (green and has a connected status on both sides).

When I downgrade firmware of Keenetic Viva to 4.3.6.3 - everything works perfect again.

There is no difference of Keenetic Ultra's firmware - tested on 4.3.6.3 and 5.0.4.

Could you check what is going wrong with 5.0.4? I'm ready to provide any logs you need.

Thanks in advance!

In the Install Updates screen, when a large number of components are added, the Confirm button is not visible as it gets pushed down, and the page cannot be scrolled.

Please check and resolve this issue.

Thanks.

Core::Configurator: not found: "show/sc/mws/wlan" [http/rci 192.168.1.29]

Core::Configurator: not found: "show/mws/wlan" [http/rci 192.168.1.29]

https://ibb.co/yngC12Ch

After installing the Alpha 3 version, I started experiencing issues with firmware updates.

On the Hopper, Sprinter, and Viva models, I am unable to install either the main (stable) or the dev versions.

The main unit updated to the preview version but it is impossible to update the member to the same version as it stays on the Main channel.