All Activity

it does get a ip now on the extender, but no internet connection

Is the connection via a cable? If so, make sure the Guest LAN is also shared on that port.

How did you find a solution? I can log in admin account, but root doesn't works with keenetic password. P.S. I've got it. Just change dropbear port. Sorry

hello used the aquire option in the interface of the main router, it looks like the clients dont get a ip from the ones in extender mode.

The main idea is to add the ability to reject connections based on MAC address patterns (masks) in cases where white/blacklists are not flexible enough for configuration.

Do you have your extender acquired in the MWS or did you configured it manually?

So the real feature request sounds as "don't lease the IP address to the host with the installed local-administrated bit in address". Sounds interesting, will reconsider this.

You can have multiple DHCP servers on the same network segment. Accordingly, it is possible for each vendor to receive different settings.

Release 4.3 Alpha 13: AFP: enabled Time Machine attribute for all shares by default [NDM-3510]: afp share {label} {mount} [timemachine] [{description}] IPoE: fixed "voip" role assignment (reported by @Leshiyart) [NDM-3643] IPv6: fixed 6in4 tunneling when static MTU is set [NDM-3644] Web: fixed display of connection name in the “Signal Levels” pop-up (reported by @dimon27254) [NWI-3978] Web: fixed errors in log when adding a DNS server (reported by @dimon27254) [NWI-3991] Web: fixed traffic monitor card on the dashboard (reported by @spatiumstas) [NWI-3921]

I support this. I also want to prevent devices with random mac address from connecting to my network. Maybe put a checkbox in the segment settings like "prevent devices with random mac address from connecting". It works like Wireless ACL and when enabled, devices with a random mac address cannot connect to that network/segment. I did some research on the internet and this is how you can tell if the match address is random or not. I don't know how true it is... "If the 2nd character in a mac address is 2, 6, A or E, that mac address is randomly generated."

since auto registration of devices without random mac is already implemented it would be convenient to have smth like "drop clients with random mac" black list option

Hello i'm trying to setup a guest wifi on my sprinter kn-3710 it does work on the main router but not on the second one in extender mode. any idea what i'm doing wrong did follow the online instruction kind regards

I confirm, the function of grouping and subsequent batch editing/enabling-disabling/deleting routes is very necessary

The main goal is to block connections from clients with randomized addresses and, conversely, allow only clients with randomized addresses. Ranges are more of an additional functionality, although blocking devices from a specific vendor based on their IEEE OUI database could also be useful in some cases. Implementing filtering by mask is simpler and more preferable for most cases.

I've got the point, thanks. Implementing some sort of a garbage collection would be nice.

MAC addresses ranges are allocated just per-vendor and rather randomly. To be honest, I don't understand where one can use ranges. Do you want to block all Realtek devices, but to allow all Intel ones? Sounds strange.

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.

Feature Request: Support for MAC Address Filtering by Masks and Ranges Introduction Currently, my routers allow me to control wireless network access using allowlists (“White List”) and blocklists (“Black List”) based on device MAC addresses. While this works for basic cases, it becomes inconvenient in larger networks or when frequent adjustments to access settings are required. Proposed Feature I propose adding the ability to filter MAC addresses using masks and/or ranges. This would allow managing access not on a per-device basis but for entire groups of devices with similar MAC addresses. Why This Matters Ease of Management If the network contains many devices from the same manufacturer (with identical MAC address prefixes), a single rule could replace dozens of individual entries. Scalability For large or dynamic networks, this tool would simplify the management process, as working with ranges or masks is far easier than maintaining a long list of addresses. Improved Security The ability to define precise filters for groups of devices helps ensure better control over who can connect to the network. Suitable for IoT and Office Networks Devices from the same manufacturer often have similar MAC address patterns. Filtering by masks and/or ranges would make managing such devices more efficient. Management of Randomized MAC Addresses This feature would make it possible to allow or block all devices with randomized MAC addresses, or permit connections only for devices using static ones. Currently, this is nearly impossible to achieve without relying on external services. However, implementing this directly in the routers seems feasible and would not require significant technical or human resources. How It Could Work MAC Address Masks: An entry like 00:1A:2B:XX:XX:XX would cover all devices within the specified range. MAC Address Ranges: Users could specify a start and end MAC address, such as 00:1A:2B:00:00:00 – 00:1A:2B:FF:FF:FF. Interface: Add fields in the access control settings for inputting masks and/or ranges, ensuring the feature remains intuitive. Conclusion Supporting masks and/or ranges for MAC address filtering would make network management more convenient, flexible, and secure. This is especially important for modern networks where the number of connected devices continues to grow.

1. Do you really use profits of the autoregistration in this case? Maybe it's enough just to turn it off? 2. This request can be considered in the future, thanks.

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.

Hi. I've got 2 Hero4G routers in the same mesh. One is the controller and one is an extender. Currently the connection is via SIM card on the 4G controller. Is it possible to create another connection for the Mesh on the Hero 4G that is an extender? The Hero4G extender doesn't show the mobile connection, and the Hero 4G controller doesn't show a possibility for a connection through the extender. Is this possible without adding a 4G USB Model to the 4G Hero controller? -Mark

debian still sticks with 3.0 in stable so i guess there are reasons for this

+1

Release 4.3 Alpha 12: IPoE: reworked code for configuring Wired connections concerning IPTV, VoIP and VLANs on Ethernet ports [NDM-3586] IPv6: fixed the cause of nginx error “bind() to [fd05:...] failed (Address not available)” [NDM-3525]

We are keeping track of this, and in case of obsoletion we will do something, of course. But now it's not strictly required.