ru.celebi

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.

Thank you for your kind reminder. In this context, I wanted to re-upload the relevant screenshots. It seems like the issue occurs on Edge, while everything looks normal on Firefox. Some of the lines are missing. The menus I could identify are 'Registered Clients,' 'IPv6 Route Table,' and 'System Files.' Additionally, with the latest version 4.3.B4, the spacing between client entries has increased. Maybe you could use this space to display clients' IPv6 addresses as well. Sounds like a great idea, doesn’t it? Firefox: Edge: Another issue was that the address field next to the KeenDNS name is not perfectly aligned. For someone like me, who has a thing for symmetry, this is quite annoying!

There is a problem with the grid layout in Edge, but everything looks normal in Firefox.

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

Does this feature really work? If it does, what format should be used for DoQ and DoH/3 specifically with NextDNS or AdGuard DNS?

Here’s the issue I’m facing: When clients on the network are not registered, their traffic is displayed collectively under a single entry as "unregistered clients." For example, if there are 20 unregistered clients, the total traffic shown might be 10GB, but it’s impossible to determine how much data each individual device has used. The feature to automatically register new clients is useful, but over time, hundreds of device records accumulate, which becomes unmanageable. A potential solution would be to enable the automatic registration of new clients while clearing the list of auto-registered clients whenever the Keenetic device restarts.

Currently, the router interface has an automatic device registration feature that solves the issue of unregistered clients. However, there are some challenges with the current implementation: Accumulation of Registered Devices: Over time, hundreds of registered devices accumulate in the list, making it difficult to manage. For instance, I recently deleted over 500 automatically registered clients from a router used in a corporate environment. While it's possible to clear these devices by modifying the startup-config file in one go, this would require restarting the router. Proposed Solution: After a router restart, the registered device list should be cleared automatically. Only devices that reconnect after the restart should be re-registered. This approach would keep the list clean and manageable while ensuring only actively connected devices remain registered. Unnecessary Details in Registered Device Names: When devices are automatically registered, their names include unnecessary details like the date and time of registration, which makes the list cluttered and difficult to read. Proposed Solution: Allow users to customize the naming format for automatically registered devices. Options could include: A user-defined prefix (e.g., "unregistered_"). The device’s name (if available). The device’s MAC address (if no name is available). This flexibility would make the list more organized and user-friendly. By implementing these improvements, the device registration process can be made significantly more efficient and easier to manage for end users.

Yes. However, this error does not occur when connecting from the local network.

Unpatched problem may persist? Because I use 4.3.A10.1.

The drive size appears normal on my home computer, exactly as it should be. However, on the work computer, it looks like it does in the picture. The file size doesn't matter; the same issue occurs with files of different sizes. I think third-party software is needed for this, as there seem to be no problems with them. However, I’m still curious about the cause of this error; ndm: Core::Scgi::Session: unsupported method "PROPFIND" for "/".

Hello all, I have added a WebDAV drive on Windows, but the drive size appears identical to my system drive, which seems incorrect. When I try to copy a file from the WebDAV drive, I get an error saying, "The file size exceeds the limit allowed." After some attempts to troubleshoot, the WebDAV folder became unresponsive, and my router ended up banning me. Could this be a bug, or am I missing something? The following log entry frequently appears. I researched this error a bit and learned that it might be related to the WebDAV server. ndm: Core::Scgi::Session: unsupported method "PROPFIND" for "/". ndm: Netfilter::Util::Conntrack: flushed 131 IPv4 connections for 212.175.X.X Netfilter::Lockout::Manager: "Http": ban remote host 212.175.X.X for 15 minutes.

If you are using PPPoE, you should disable these settings.

If no custom DNS addresses are entered for the clients, all devices will broadcast with the name set on the router. However, if a different name is desired, the custom DNS address must be set on the individual client. In this scenario, you cannot assign different profiles on a client-by-client basis using the profile set on the router; all devices will use the same profile. However, if you enter the details of a different profile on the client, it will work with that profile.

The cloud-based content filtering and ad blocking component is not installed on my device. I use it as shown in the image. I've never experienced the problem you mentioned.

In version 4.3.A9, the System Settings menu cannot be accessed. Manually navigating to /system via the URL also does not resolve the issue.