KYTECHNGAMING

Update: The issue is tied to heavy I/O load during boot. I rebooted the router to install a new component, and I observed the exact same behavior: the tsmb-server went into a crash loop but eventually fixed itself after a few minutes and stayed stable. After reviewing the logs, the root cause seems to be an I/O bottleneck during startup. I have three drives connected (5TB, 1TB, and 480GB). Right after boot, MiniDLNA and Transmission start scanning and indexing these large drives simultaneously. Because the disk I/O is completely saturated, the tsmb service fails to initialize in time, hits an operation timeout (0xcffd0516), and gets killed/restarted by the system repeatedly. Once the initial DLNA/Torrent disk storm calms down, tsmb starts successfully and works perfectly. Perhaps the startup timeout threshold for tsmb could be increased in future drafts to handle scenarios with heavy background disk activity? I have attached my latest self-test taken right after the reboot for your reference.

Update: The issue resolved itself without a reboot. Hi again, I wanted to provide an update. I left the router alone since yesterday, and today my SMB access is fully working without me having to reboot the device. I checked my new self-test logs and the tsmb-server crashes have completely stopped. It looks like right after the firmware update, the router was doing some heavy background processing on the connected USB drives (possibly filesystem checks or DLNA media indexing). This heavy I/O load caused the SMB service to time out (0xcffd0516) and crash repeatedly. Once the background disk activity settled down, the SMB service started normally and has been completely stable. Perhaps the developers could look into increasing the timeout threshold for the tsmb service during heavy disk load so it doesn't enter a crash loop? I am attaching my latest self-test file for reference.

Hi everyone, I just updated my router to the latest 5.2.a.7 draft firmware, and I have completely lost access to my USB SMB shares. I checked the system log to see what was going on, and it looks like the tsmb-server is stuck in a continuous crash loop. It keeps trying to start, times out with an error (Cifs::ServerTsmb: system failed [0xcffd0516], operation timeout), and then stops unexpectedly. I am attaching my self-test file so the developers can take a look. Has anyone else lost their SMB access after this update? Thanks in advance for the help!

Quick update on what triggered the issue and the current state: Exact Trigger: I was using the Dark Hive theme in Transmission Web Control. The moment I switched the theme dropdown back to Default, the interface hung, which then locked up the main Keenetic Web UI. Self-recovery via timeout: After some time without rebooting, the hanging TCP socket/stream finally hit an OS-level timeout, releasing the CORE lock on ndm. Execution of queued commands: Once ndm unblocked, the CLI commands I ran earlier (no ip http proxy tr, no service torrent) executed in sequence. I re-enabled the torrent service (service torrent) to test it again. While the service is up, Transmission Web Control under the Default theme currently has broken UI rendering: Text labels are missing/blank across the interface and inside the Config dialog window. It gets stuck on "Connecting...", and clicking the UI reload/restore buttons does not fix the state. So while the router eventually recovers once the socket times out, a broken/hanging response from a proxied WebUI still temporarily freezes the main Keenetic management interface. Better thread isolation or stricter timeouts for ip http proxy upstreams would prevent third-party UI rendering issues from affecting the main Web UI. Attached are the screenshot of the broken Web Control interface and the latest self-test log. Hope this helps the dev team!

Hi Keenetic Team, 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.

Keenetic EU/TR and EAEU (Eurasian Economic Union) regional models differ primarily in factory-set parameters that dictate Wi-Fi compliance and operational behavior. https://support.netcraze.ru/air/nc-1613/en/51147-is-it-possible-to-use-keenetic-and-netcraze-models-together-.html

Hello, In my mesh system running on a mixed LTS 4.3.8 and 4.3.6.2 ecosystem, whenever I change the "Allowed Wi-Fi System Nodes for Connection" setting for a specific client, I receive random notifications from the RMM Telegram bot indicating that devices have rebooted. These entries also appear in the RMM event log. However, the devices are not actually rebooting. (There are also no reboot notifications triggered in the Keenetic mobile app.) For example, in the cropped screenshots attached, you can verify that the device named Backbone 10 never actually restarted. Since this is the 3rd time I’ve encountered this behavior, I decided to open a ticket. I am attaching the self-test file from the Peak DSL (main controller). The client device I modified the settings for was the Samsung Projector (B0:99:D7:E5:27:44). Prior to this, I disabled the 802.1r (Fast Transition) feature on the main controller. I believe doing so also triggered the same false node reboot alerts from RMM. I will double-check this behavior when I re-enable it. On a side note, I previously opened a thread regarding an issue where I couldn't access RMM with LTS 4.3.8 due to the error: Core::Scgi::Tools: ignored floating point value "channel". That thread seems to have disappeared, but @eralde had suggested repacking the FW, which successfully brought my 4.3.8 system back online in RMM. Should I perform this FW repack action for all nodes receiving these false reboot alerts? (Though some of these nodes are currently on 4.3.6.2—I suppose I should check their logs first). Thanks in advance for looking into this!

@Atalante

Hello, 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!

Which model/models do you use?

Hello, master, This issue has always been present with the new interface. It persists in the same way in many previous versions. If the list is very long, the button doesn't fit on any screen. You can only scroll down by pressing the Tab key.

I always click TAB button and reach the UPDATE button

Pppoe altında, dns yoksay seçili iken de düz dns'leri girili tut.

Hello, I thought of a feature for experienced users. It is a process I often use in SFP GPON modules. It can be seen in Openwrt or Linux-based operating systems. I would like to see the ability to manually change partitions in KeeneticOS as well. One partition could hold the stable version, while the other partition could hold the developer version of KeeneticOS. Similarly, when updating from the developer version to the stable version during an update, the update should be written to the other partition. Instead of writing the new version to the other partition and performing the version update procedure each time, it would be a good idea to change the partition using a command line or a button in the interface. Example application: nv getenv sw_commit If sw_commit returns 0 sw_commit=0 nv setenv sw_commit 1 nv setenv sw_active 1 reboot - nv getenv sw_commit If sw_commit returns 1 sw_commit=1 nv setenv sw_commit 0 nv setenv sw_active 0 reboot If you want to manage this, you can also set up one partition to always have the stable version and the other partition to always have the developer version. Just switch to the other partition first when you want to update a specific software.

Did you delete simple dns when DOH/DOT entries are enabled?