Access Point for DHCPless network without backfeeding DHCP

I am frequently working in many different sites that have ethernet-only networks with no DHCP.

I would like to be able to quickly set up my SFT1200 router as an access point where I can plug into an existing, wired non-DHCP network and

  1. Access the general internet
  2. Access other devices on the network.

Right now I have it set up so I plug a cat5 cable into the LAN port, configure the LAN interface with the proper IP address, set the correct gateway, and configure a DNS server.

Then, I enable DHCP, allowing it to provide the 1-5 wifi connected devices to pull DHCP.

However, while this looked like it was working, I quickly realized it was also broadcasting DHCP over the existing network, giving devices connectivity to itself that are connected elsewhere in the system with DHCP enabled.

This cannot happen, as it is a security issue and will also break important systems. What are my options?

I dont think they will appreciate beaming their network in the air.

1 Like

... isn't supported here, ask gl.inet

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

1 Like

It's our networks, we manage all the sites, so yes we do. It's for temporary setups.

The router is running open-wrt 18.06

It is running GLInet knockoff version, you have to ask them.

no dude, it's running butchered up openwrt, based on a vendor SDK.

I'll bite, 18.06 is 6+ years old, and EOL, please upgrade to openwrt 23.05.

when you've given up, read How do GL-iNet devices become supported by official OpenWrt releases?


Alright, this will have to be a next month thing, I really dont have time to learn how to flash firmware to the damn thing. Will come back to this post if at some point I find time to take a week off.

Don't worry, you won't have to.

1 Like

I'll first reiterate what was already said about the firmware -- this is indeed a question for GL-Inet as the router isn't supported by the official OpenWrt project.

However, on a more general note, if the AP is intended to be a bridge mode device (aka a dumb AP), there is no way to prevent a back-feed of the DHCP server if one is enabled on the AP. The only way to avoid this would be to use the device in routed mode where the downstream network is a different subnet than the upstream network and connectivity is handled by means of routing rather than bridging/switching. That being said, if your upstream network is 'smart' enough, it can be configured such that it blocks rogue DHCP servers, but that is a function of the upstream network, not your AP.

Hopefully that information will help you figure out the best way to handle your specific situation.

1 Like