Comments on: Fun with DHCP http://www.lafferty.ca/2008/03/19/fun-with-dhcp/ Rich Lafferty's OLD blog Thu, 05 Nov 2009 06:39:39 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Rich http://www.lafferty.ca/2008/03/19/fun-with-dhcp/comment-page-1/#comment-26591 Rich Thu, 20 Mar 2008 00:42:13 +0000 http://www.lafferty.ca/2008/03/19/fun-with-dhcp/#comment-26591 Well, only Windows hosts were affected today, but those same Windows hosts weren't affected yesterday. That's the response time at work. That none of the Macs were affected is probably the other side of the coin -- but now that I think about it, only the DNS server and domain name were getting updated by the rogue DNS server, so it was almost certainly tickling something Windows-specific. Still, that wasn't the part that was hard to figure out -- the tricky part was thinking to look at something that <i>hadn't</i> changed recently when something obvious had changed that morning. Well, only Windows hosts were affected today, but those same Windows hosts weren’t affected yesterday. That’s the response time at work. That none of the Macs were affected is probably the other side of the coin — but now that I think about it, only the DNS server and domain name were getting updated by the rogue DNS server, so it was almost certainly tickling something Windows-specific.
Still, that wasn’t the part that was hard to figure out — the tricky part was thinking to look at something that hadn’t changed recently when something obvious had changed that morning.

]]> By: gcrumb http://www.lafferty.ca/2008/03/19/fun-with-dhcp/comment-page-1/#comment-26583 gcrumb Wed, 19 Mar 2008 22:55:26 +0000 http://www.lafferty.ca/2008/03/19/fun-with-dhcp/#comment-26583 I recently had to deal with a similar situation, where $BOSS had been playing with some wifi hotspot software over the weekend, and didn't realise that he was running a DHCP server when he plugged his laptop into the network on Monday morning. We were lucky enough to have a managed switch that records which MACs are linked to each port. One thing I found peculiar, and which doesn't entirely jibe with your argument that physics comes into play where competing DHCP servers are concerned, is that <em>all</em> of the Windows machines got useless addresses from the hotspot application, and <em>all</em> of our Linux machines got useful addresses from the 'good' DHCPD. This in spite of the fact that latency to the 'bad' DHCPD was noticeably and consistently higher than to the 'good' one. I suspect that the truth is somewhere in the middle. For a given dhcp client implementation, results are probably consistent, but distance doesn't always seem to be the definitive factor. I recently had to deal with a similar situation, where $BOSS had been playing with some wifi hotspot software over the weekend, and didn’t realise that he was running a DHCP server when he plugged his laptop into the network on Monday morning. We were lucky enough to have a managed switch that records which MACs are linked to each port.

One thing I found peculiar, and which doesn’t entirely jibe with your argument that physics comes into play where competing DHCP servers are concerned, is that all of the Windows machines got useless addresses from the hotspot application, and all of our Linux machines got useful addresses from the ‘good’ DHCPD. This in spite of the fact that latency to the ‘bad’ DHCPD was noticeably and consistently higher than to the ‘good’ one.

I suspect that the truth is somewhere in the middle. For a given dhcp client implementation, results are probably consistent, but distance doesn’t always seem to be the definitive factor.

]]>