Shutterstock

When working in technical support, you never know what is going to cause issues.

The IT guy in this story gave a great example of this. His team kept getting calls about network slowness, and they couldn’t get to the bottom of it. Finally, he looked deep into the logs and found a device flooding the network with DHCP traffic.

After digging deeper, his team found that it was a single phone that was sending out the DHCP traffic, so they disabled the phone, and that fixed the problem.

While this was a pretty unlikely cause of the problem, it is good that they got to the bottom of it. Read through the full story below if you love unusual tech issues.

Hello IT, Have you tried turning if off and back on again?

From Whirlwind Computing – a fictional service provider so good it will really blow your socks off.

Ok, let’s see what this IT company does.

The company affected is one we can recognize is a care-home of sorts…

Actors:
$Me – Calling the shots… remotely
$Nerds – My minions… experts in their craft
$Phone – Calling the shots… onsite
$Director – Also calling the shots… onsite

Complaints of a slow network are very common for support teams.

Scene:
This place started bubbling up to the top of the support queue with multiple requests of something is just really off with the network with reports of it being slow, dragging, and just being an absolute dog when it comes to being on wifi.

That’s weird because wifi coverage was very good as the wire-flavoured spark wranglers made sure it passed muster and the mustard.

Something always goes wrong, eventually.

We sent techs multiple times to bless the creaking network and also to make an assuring presence that nothing was being a problem.

Murphy clearly had other plans as we were wrong about what was wrong the first four times they went out.

When the director demands it gets fixed, it is time to take a deep dive.

The Director got involved and told the reps to fix the network or he’s replacing everything as it’s impeding actual business operations and making the whole team very hot, cross, and bothered.

I grabbed the laptop and camped out staring at the all-knowing Shark of the Wires, filtering by Arp, Dns (always DNS) then Dhcp… wait a second!

Well, this is odd.

Why is 192.168.4.27 sending out DHCP ACKS to DHCP requests?

I took a closer look at the Mac address which showed it was a phone, but why on earth would it be doing the DHCP thing?

So, one phone was causing the problems?

I assembled the Nerd HerdTM and they swept the building with the precision of a highly trained black-ops team as there were 20 of them to check, so I give them full credit for finding it within 7 minutes.

One reboot later and things started to swim back into service while the phone was off-hook and strangely, it hasn’t been a problem ever since.

You wouldn’t think that a phone would do this type of thing.

We have well 1500 phones deployed, this is the first and hopefully last time one of them became the embodiment of DHCP with a flair for the dramatic.

The lesson here is that if there’s ever an event for what feels like a rogue DHCP server, check the phones, you never know what you might find.

If there is one thing you learn when working in tech support, it is that you never know it all. A phone shouldn’t be causing these issues, but apparently that is just what happened.

Read on to see what the other people in the comments think of this story.

Windows has a way to watch for this.

This person has some questions.

I haven’t heard of this happening either.

Here is another fix.

The source of the problem is always the last place you look. In this case, it was just one phone out of the thousands that they had.

Apparently, however, there are a number of solutions to this type of issue, according to the people in the comments.