JON HONEYBALL
Jon tells Microsoft what to do about Windows 10X, but first has to solve the mystery of an IP device going wrong on his home – or is it office? – network
Jon tells Microsoft what to do about Windows 10X, but first has to solve the mystery of an IP device going wrong on his home – or is it his office? – network.
Andre called up the stairs: “Netflix isn’t working on the TV”. Keeping one’s partner happy is obviously priority number one, so I scampered downstairs to see the issue. The TV is a 40in Samsung UHD/HDR model in our kitchen/ lounge, and we use its built-in Netflix app. And he was quite right: it was complaining about there being no data feed. I tried the Amazon app and that was dead too. Clearly something was amiss in IP-land.
Going to the TV network settings showed it had managed to obtain an IP address of 192.168.168.101, with a default gateway of 192.168.168.1. Which is odd, because my network runs on the 10.101.x.x range. The only explanation was that I had a rogue DHCP server on my network.
Now, I need to explain that my network is unusual, but has been designed this way for a good reason. My boundary router/firewall is in the data centre across the yard from the lab. There’s a 1Gbit fibre connection between the two buildings. Why did I put the boundary router in the data centre? It meant I could put backup servers in that building too, and have them within the realm of my internal network. In addition, there’s a 1Gbit dark fibre connection from my boundary router/firewall in the data centre to my house, some ten miles away. So there’s essentially a unified IP space spanning three physical locations, all interconnected on fibre. Access to this LAN is tightly controlled – no test devices join it, for example. And none of my team know the Wi-Fi password for the Meraki Wi-Fi units on the LAN, either. I keep a close eye on the IP allocations and which ports are in use in the main Meraki switch in the lab.
My first thought was that it must have been something stupid I’d done at home. So I went to the garage where the Cisco router and fibre boxes live, and unplugged the fibre to the lab. This would, of course, disconnect the LAN and take out the DHCP server that sits within the pfSense firewall at the data centre, but it would allow me to see whether this rogue DHCP server disappeared too. And that would indicate if it was physically located at the house, the lab or the data centre.
The intention was good, but in one of those weird twists of fate, this rogue DHCP server decided to play with my mind. I had my laptop set to an address of 192.168.168.102 on its Ethernet port and it was cheerfully pinging the 192.168.168.1 address. I disconnected the feed from the fibre and the 192.168.168.1 ping stopped. Ah, clearly this meant the problem was at the other end of the fibre, most likely in the lab. I reconnected the fibre feed and the ping resumed shortly after.
There was no choice: I had to get in the car and drive to the lab. Repeating the exercise, I could still see the rogue DHCP server. The next task was somewhat easier: I knew the MAC address of the device, so I could look up where it was on the ports of the Meraki 48-port switch. Well, that was easy enough, but it left me confused. It wasn’t in the lab. This required a quick SMS to Richard, who runs the Merula data centre across the yard. Despite it being a Saturday, he quickly answered. By logging into the Cisco routers, he ascertained that indeed it wasn’t in the lab. It wasn’t in the data centre, but it was on port six of the Cisco router back at my house. I could have logged into the Ciscos, but I leave that part of the infrastructure to Richard, who understands the dark art of Cisco routers far better than me.
Back into the car to drive home. Port six on the Cisco router was the feed from the fibre that fed into the house, so clearly it was somewhere in the house. I plugged my laptop back in and started pulling Ethernet from the main distribution switch, one at a time. The house is pretty well covered with Gigabit Ethernet – one feed goes to the roof space, to various cameras and then drops down the side of the house to rooms. One heads to the kitchen/lounge space. Another one goes over fibre to the garage, which has various bits in it. Disconnecting these didn’t stop the ping.
Of course, the last cable I pulled killed it. It was for an IP security camera mounted on the side of the main garage, near to where the fibre comes in. I plugged it back in and the ping resumed. I then plugged it into a spare port on the Cisco and Richard remote-confirmed that the MAC address had indeed appeared on the port. I did the only thing possible – I pulled the feed from that camera and went to the pub for a beer.
How did this IP camera go rogue and fire up its own DHCP server on my network on the 192.168.168.1 address? Well, it turns out that this camera (a somewhat elderly Y-cam Bullet HD camera) can be run over Wi-Fi. When you set it up on Wi-Fi, it creates a hotspot so you can connect your laptop to it. This, of course, requires a DHCP server on the camera to support the hotspot. I hadn’t even plugged in the Wi-Fi aerial, always using it over wired Ethernet. The camera had decided to launch its configuration and had crashed into a setup routine. Except it wasn’t really working, as there was no web management page on the 192.168.168.1 address. It had simply gone rogue and, in doing so, had managed to wreak havoc across my network.
There are some lessons to learn from this. Firstly, it’s much easier to fault-find this sort of issue if you have access to the monitoring on the ports of your switch. Knowing the MAC address of the offending device, I could have easily worked out where it was. This was easy to do in the lab on the big-boy’s-long-trousers
Meraki switch. But most switches in the home and SMB environment don’t have that sort of management interface capability.
Secondly, it is a good reminder that devices that try to be “helpful” by setting up their own Wi-Fi hotspots can turn out to be a liability when they go rogue. I’m coming to the conclusion that most IoT devices are really quite horrible in their implementations, and make far too many assumptions that don’t stack up in the real world.
Said camera has been forcibly removed from the side of the garage, and a Samsung Wisenet QNO-6020R replaced it. Which reminded me that another Y-cam died last year and was replaced by one of these nice 6020Rs. At least that time it just flatlined, rather than attempting to invade my network. That leaves four more of the Y-cams around the house, all fitted high up under the eaves. I can see some ladder work in my future to pull them off before they die too.
Oh, and to answer the obvious question – why, in my initial fault finding finding, did the rogue DHCP server disappear when hen I unplugged the fibre from the he house? I can’t explain that, other er than the camera appeared red to be going through an ongoing ngoing spasm of booting and d rebooting. Maybe it was coincidence. I prefer to believe that it was simply doing its best to ruin my day.
Facial recognition in a face mask era
I recently came across an interesting nteresting report from the e National Institute for Standards ndards and Technology (NIST) ) in the US about the effect that hat wearing a face mask
has on facial recognition algorithms ( pcpro.link/313mask).
According to this work, the most accurate algorithms have a failure rate of about 0.3%, meaning they’re correct 99.7% of the time. An image of a masked person causes the failure rate to rise from 0.3% to around 5%. Other “competent algorithms” fail under the same circumstances between 20% to 50% of the time. The size of the mask has a significant impact – the more you cover your nose, the worse the algorithms perform, as you’d expect. And there’s a suggestion that the colour of the mask matters too.
Clearly, this is a technology race. With the significant rise in the use of face masks due to the Ongoing Unpleasantness, it will have an effect on the facial-recognition systems used, not only by the authorities but also by businesses. For example, it’s long been held that Las Vegas casinos have serious face-recognition systems in place. I wouldn’t be surprised if large department stores along, say, Oxford Street use similar technology to aid and inform their in-store security teams. The rise of masking will clearly have the unfortunate (to them) side effect of making systems like this less effective. While rising from 0.3% to 5% might well be considered adequate, that sounds like a best-case scenario. A failure rate of 50% sounds more likely and renders it useless. I’m sure the vendors of such technology will be scrabbling to reassure their customers that their solution is still valid in the new masked era.
“Vendors will be scrabbling to reassure their customers that their solution is still valid”