I’m reopening this because the underlying issue remains unresolved more than 1 year.
The GUI allows you to define two separate subnets/bridges (e.g. a bridge for LAN + 5 GHz + one DHCP pool, and another bridge for 2.4 GHz + a second DHCP pool). That layout works on many other devices. On the RUTC50, though, only the first subnet gets IP assignments - the second never does.
In other words: the front-end (web UI) lets you configure independent DHCP on two segments - but the back-end never applies it reliably. That is misleading and unhelpful.
Please explain this clearly:
Is this dual-DHCP, dual-bridge configuration officially unsupported?
If so - why is the UI even letting users create it instead of blocking it?
If not - when will a properly working implementation be provided (or what is the correct way to achieve what the GUI advertises)?
As things stand, this is a significant design inconsistency in a flagship product. A straight answer would be appreciated.
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.
We tested this on 2 separate RUTC50 devices and were able to successfully achieve the desired results.
The steps were exactly the same as in this thread - connecting to one Wi-Fi leased our phones an IP under network #1, connecting to the other one, leased an IP under network #2. I presume this is the functionality you were looking for? If not, could you clarify?
Please note that the configuration below is only the simplest possible setup that reproduces the flaw. My previous technical description already characterizes the defect in sufficient detail that you should be able to identify all other affected configurations.
For the minimal reproduction scenario, please proceed as follows:
Create a bridge that includes all Ethernet interfaces together with one wireless radio (for example, the 5 GHz radio).
Enable DHCPv4 on this bridge.
Create a second, independent bridge that includes the 2.4 GHz radio.
Enable DHCPv4 on this second bridge as well.
In this arrangement, dnsmasq is launched only for the first bridge, and the second bridge fails to receive its DHCP daemon. This is the core defect already described.
If you still conclude that dnsmasq is instantiated correctly for both bridges under this configuration, please provide the following evidence from your test device:
The generated dnsmasq configuration file(s).
ip a
ps | grep dnsmasq
These outputs are required to confirm whether dnsmasq is actually being invoked for both bridges.
I would like to follow up on this issue, as there has been no response for five days, and at this point it is unclear whether the core problem is properly understood.
To restate the issue precisely:
The web UI allows configuration of two independent Linux bridges, each with its own DHCP server enabled. However, in practice, the firmware/backend does not support correct DHCP operation on two separate bridges simultaneously. The resulting behavior strongly suggests that the DHCP service is bound to only one bridge, despite the UI implying otherwise.
So far, your responses indicate that you are testing a different configuration than the one I am describing — one that may work for you, but is not relevant to this report.
To move forward constructively, I explicitly asked for:
The generated configuration files (e.g. dnsmasq and network config)
Confirmation that the DHCP process is actively serving both bridges (not just one)
This would clearly demonstrate whether:
The backend truly supports this scenario, or
The UI exposes an option that the firmware does not actually implement
At this point, I need one of the following:
Confirmation that you understand the described setup and can demonstrate it working as specified, or
A clear statement that multiple independent bridges with DHCP are not supported, despite being configurable in the UI
Silence or continued testing of unrelated “known-good” configurations does not resolve the issue and leaves users with misleading functionality.
I would appreciate a clear technical response so we can close this topic based on facts rather than assumptions.
Apologies for not providing a response. I’ve passed your previous reply back to the R&D so they could investigate this on their local setups. Your response was clear, I’ll get back to you once I have anything.
@egothor whats the purpose of your setup? why do you want to bridge?
also, your setup is not quite understandable, so do you want to have 2 access points that provide IP addresses to their clients under 2 separate subnets? If so, the examples provided earlier by Matas are exactly what they do
This is not a SoHo use case, but a security-driven design requiring strict L2 separation. The requirement is two independent bridges, each with its own DHCP service, to enforce clear trust boundaries between wireless networks and wired ports.
We are not discussing a $50 device, but hardware in the several-hundred-dollar price range, where this capability is a reasonable expectation.
The issue itself is simple: the web UI allows enabling DHCP on multiple bridges, but the firmware/backend does not actually support it.
Requesting real configuration files and running services is not academic - it will explicitly show what is supported by design and how Teltonika interprets the requirement of two independent bridges with DHCP.
At this point, the only relevant response is from Teltonika:
either confirm that this is supported and demonstrate it with real configs and running services, or
explicitly state that it is not supported, despite being configurable in the UI.
I’m sorry to say but you sound like a competitor on a random account creating an issue that doesn’t exist. You failed to answer a question as to what exact setup you’re looking for about 2 or 3 times so far. I went ahead and created 2 networks and assigned each of them separately to each of the AP’s available within my device, ended up checking the running processes, which I had 2 of (hmm.. strange, thought you said it’d only be one?) and also checked the cfg file which DIDN’T even contain a line such as interface= as you mentioned also.
What’s even more suspicious is you avoiding to share any screenshots, logs and such, what’s the problem? If I’m wrong about you being a competitor, I’m sorry, but please co-operate with the people trying to help you out here..
I connect to wi-fi AP #1 - I get an IP that I’m supposed to get
I connect to wi-fi AP #2 - I get an IP that I’m supposed to get
I seriously don’t understand the question that you’re raising when you say
The requirement is two independent bridges, each with its own DHCP service, to enforce clear trust boundaries between wireless networks and wired ports.
Okay? Clients get separate IP addresses leased out to them, since both of the APs have different LAN networks assigned to them, so 2 separate DHCP instances? Mind elaborating?
I already provided a concrete configuration file and specific directives. If you cannot locate them, that indicates you are looking in the wrong place and are not familiar with how the firmware generates and applies its runtime configuration.
Likewise, simply counting processes is not sufficient. Correct verification requires understanding PID/PPID relationships, command-line arguments, and inspecting process context (for example via /proc/<pid>/status). Without this, conclusions about “multiple DHCP instances” are not technically meaningful.
This discussion concerns firmware backend behavior, not UI-level experimentation.
For clarity: I am not a competitor. I actually consider the hardware well designed. The problem is the software/GUI layer, which is suitable for marketing or simplified use cases, but inadequate for serious engineering requirements.
At this point, only a technical response from Teltonika is relevant.
Partially, the reason of me even being in this discussion is learning more about devices themselves, from time to time I may type something nonsensical when trying to help someone out, but here I’m 100% curious to understand the meaning of all of this.
You began your thread with this statement, which sounded to me as if creating a new AP with a new subnet doesn’t lease out any IP addresses, which is definitely not the case, at least not for me.
I then read this question, and this as well:
It sounds like utilizing VLANs to create a new LAN network and assigning it to an interface is not a solution for you, meaning that you need a way to assign 2 subnets without the use of them, which, to my knowledge, is not possible. However, when creating the new LAN network, if I recall correctly, you may need to create a new firewall zone, since they’re both put under the same one on creation, look into that, please.
Sorry for sounding passive aggressive, I’m just passionate when it comes to situations like these as I really want to help people out as much as I can. I think the user Dainius has mentioned something towards the firewall-side of things.
Out of curiousity, if you have the time, could you please try double-checking the zones?
I would like to follow up once again. If the DHCP service truly works with two independent bridge interfaces as configured via the web UI, could you please share the corresponding backend/Linux configuration generated by that UI?
Otherwise, I would appreciate a clear statement that the setup available in the web interface does not work as expected, and that the positive results were obtained using a different configuration.
At the moment, we are still awaiting confirmation and feedback from our R&D team, as they are continuing their investigation into this matter. Once I receive any updates or additional information from them, I will be sure to inform you promptly.
Thank you very much for your patience and understanding while this is being reviewed. It is greatly appreciated.
If you recall, I’ve initially tried reproducing your issue with what information you’ve provided us with your first post, and was unable to get the same issue as you.
After further clarifications from your end, I ended up reaching out to our R&D, however, they weren’t able to reproduce this issue either. They ended up asking me to get a troubleshoot file from your device, where the issue is present and the file has been generated when it was present so it would be visible within the logs/config files, etc.
Since I was unable to get a troubleshoot file from you, unfortunately, but it doesn’t look like we can proceed with further investigation of this issue, unless you decide to change your mind.
I will not provide a troubleshooting file. Generating such a file would require additional effort on my side and, more importantly, would disrupt a currently functional and carefully configured setup. This is not reasonable given the current state of the discussion.
From the beginning, I explicitly asked you to provide evidence that this scenario was tested correctly on your side. You indicated that you already had the relevant setup available, which means you could have easily demonstrated that your test configuration matches the reported issue. This request was ignored.
From a technical standpoint, the problem is evident: the DHCP daemon configuration includes only a single bridge. The second bridge is never referenced in the DHCP configuration at all. Under these conditions, the daemon cannot operate correctly for a dual-bridge / dual-subnet setup. This directly contradicts the claim that the issue has been resolved or properly tested.
Additionally, as already noted earlier in this discussion, the same issue has been reported by another customer. This clearly indicates that the problem is not isolated and should be treated accordingly. Dismissing the issue or repeatedly asserting that everything is working as expected, without providing concrete evidence, is not an acceptable approach.
Therefore, I again ask you to provide the evidence previously requested:
The DHCP configuration as generated on your device (dnsmasq config)
The list of interfaces and bridges
The list of dnsmasq processes
Asking the customer to perform additional diagnostics while you are in a position to prove that the correct configuration was tested is not appropriate.This effectively shifts the burden back to the customer, unnecessarily prolongs the discussion, and does not reflect a professional support process.
Please provide the requested evidence demonstrating that the exact reported configuration was tested and functions correctly.