I'm new to OpenWrt and I'm loving it so far.
I have OpenWrt firmware on an outdoor access point that has a dozen ipcam clients. 4 of the ipcams are responding to all DHCP requests and offering random leased ip addresses to the whole network. I want to configure the firewall on this access point to drop any dhcp offer packets (port 67) coming from any client on this wireless interface.
DHCP is provided by the "main" router indoors. When a new client connects to any wired port, or the outdoor wireless access point, or the indoor wireless router, the 4 ipcams each try to provide a leased ip to the new client on a subnet that is not used. There is no way on the ipcam to configure/disable its dhcp features. I would eventually replace these ipcams but for now i'm just trying to do a quick fix. Main router is stuck with TP-Link firmware and nearly zero useful settings.
I've tried for 2 hours now different kinds of firewall rules but I can't get anything working.
My network is 192.168.0.0/24 .... no other subnets. The ipcam will have an ip of 192.168.0.73 and it will reply from its same mac address saying its 192.168.175.1 offering 192.168.175.105. Wireshark confirms.
Are you certain about this? Seems like this would break the vast majority of networks, so it really seems unlikely that any camera vendor would be so shortsighted.
There is nothing you can do if you're working with a bridged AP/switch.
If you setup a second subnet, you can at least contain the damage.
So it won't be on this device...
This still seems entirely implausible that the camera is a) offering an IP on a different subnet than it is working, b) that it is acting as a DHCP server if it's also a DHCP client, and c) that if this is really what it's doing, that it cannot be disabled.
Have you unplugged your camera(s) and verified that the rogue DHCP server functionality really does stop?
Anyway, the only way you can deal with this would be to put the cameras on their own subnet. You can do this on your OpenWrt device by creating what is effectively a guest network on a dumb/bridged AP (this can be extended to ethernet, too, if needed). If your main router supports static routes, this won't be all that difficult to deal with. But if not, you'll need to have NAT masquerading enabled which might cause some complications.
What is the make/model of the camera(s) in question?
1 Like
set up the openwrt router as bridged (not NATed) with the main router.
https://openwrt.org/docs/guide-user/network/wifi/relay_configuration
That does not solve the problem because it would be L2 which cannot be easily filtered.
Camera is Eversecu without a model numbers. It's here: https://www.amazon.com/gp/product/B0BTSYQW4L
When unplugging the camera that rogue dhcp response does disappear. Wireshark shows the dhcp response coming from the camera's mac as well. I emailed the manufacturer whom basically said the settings page is all i got to work with. After a factory reset, the camera provides an access point to connect to for first time setup, and its own gateway is 192.168.175.1 and gives my phone an ip on the 192.168.175.0/24 subnet. Then after scanning+selecting a wifi it should connect to, it reboots and can provide rtsp and onvif to the NVR on the network. But it seems the initial dhcp server thats needed for first time setup for a direct connected client stays on forever and still acts as dhcp server even when it's a client. I even went as far as trying to un-squashfs the cameras backup settings download (which seems to be a .bin of the whole firmware) and i cant figure out the signature hash to get the camera to take in my modified firmware with dhcp disabled.
anyway, I'm going to try the route of putting those particular camera on a guest network that you linked to, thank you. But that's tomorrows mission.
At least one review on Amazon did warn that this camera would mess up your network.
I'd recommend trashing these things and getting something better.
2 Likes
