Thanks for the response. Screenshots or topology drawings won’t add anything meaningful here, because the issue is not configuration-specific. It is caused by a structural limitation in the firmware.
The core issue is that the firmware launches only a single dnsmasq instance bound to a single bridge interface, even though the GUI allows users to define multiple independent bridges, each with its own DHCP scope (e.g., a separate 2.4 GHz client/AP network). The generated /var/etc/dnsmasq.conf.cfg* file always contains only one interface= entry, and only one dnsmasq process is ever started. As a result, any additional bridges are never serviced by DHCP, regardless of how correctly they are configured in the UI.
This is why any second subnet - no matter how it’s arranged in the GUI - never works unless everything is collapsed back into a single central bridge (the workaround described by your team in the earlier thread), also see this one.
So the questions that really need clarification are:
-
Is multi-subnet / multi-bridge DHCP actually supported on the RUTC50 backend?
The GUI suggests that it is, but the implementation does not start dnsmasq instances correctly for more than one bridge. -
If it is unsupported, why does the GUI allow users to configure a layout that cannot function at the backend?
This is the misleading part, and the source of a lot of debugging time. -
If it is meant to be supported, when will there be a proper implementation?
In other words, will the firmware eventually start separate dnsmasq processes (or equivalent) per active bridge, as would be necessary?
Because this is a fundamental backend constraint rather than a user-specific misconfiguration, providing screenshots would not change the underlying question. What is needed is a straightforward statement from engineering on whether this functionality is intended to work and, if not, whether the UI will be corrected.