![f0110-03](https://article-imgs.scribdassets.com/3lmvvens5ccgll4q/images/fileOFBLCGM8.jpg)
![f0110-01](https://article-imgs.scribdassets.com/3lmvvens5ccgll4q/images/fileJDLT47SM.jpg)
I wanted to change some of the security cameras at home. At the lab, we fitted high-end Axis cameras over a decade ago. They proved an excellent investment and are still doing sterling work every day; I see no reason to change them. This is reassuring, because new, albeit higher-spec Axis cameras are priced in the “robust” corner of the price list.
At home, at roughly the same time, I went for no-name Chinese clones at around £100 each. These were adequate for the job, and supported Ethernet connection with power over Ethernet (PoE), which I consider essential for a security camera.
These cheap cameras also support a wireless connection. I happily ignored this, right up until the point where I found their failure mode. If the camera decided to crash and reset, it would come up assuming I wanted to connect via Wi-Fi. So it created a Wi-Fi hotspot and, to make this work, it had to have its own DHCP server to hand out an IP address to a connected laptop that was trying to do the setup and configuration.
You can see where this joke is going already. It even did this if there was an Ethernet cable plugged in, and it was receiving an IP address from the network. And now for the punchline: it wired up the internal DHCP server to the Ethernet cable, too, thus creating the IP mess that is two DHCP servers on the same network.
The end result is that suddenly other client devices wouldn’t connect because they were getting an IP address in the default 192.168.x.x range of the faulty camera’s DHCP server, not the 10.101.x.x