Win XP discover/offer/req/ack loop (Help!)

[Simon Hobson]

Jeff A. Earickson wrote:

>Do you mean tcpdump from the ISC DHCP server, or some networky
>packet sniffer on the 202 subnet?

My experience says that if you can capture both at the same time then 
that's very useful - you can see what's happening on the remote 
network, as well as what the relay agent is doing in between.

>   Our network guy is contemplating
>the idea that somebody attached a rogue dhcp/wireless/NAT device
>to the 202 subnet and disrupted traffic there.  This issue just
>started today.  Since it is near the start of school, new people
>and new devices are showing up on our network...

I'm struggling to see how it would cause the effect you describe. The 
most likely is that someone has connected some 'consumer grade' 
device that defaults to DHCP - in which case it would be offering 
rfc1918 addresses (usually 192.168.0.0/24 or 192.168.1.0/24). If that 
was the case I would expect you would see multiple requests for a 
totally incorrect network :

discover
offer 137.146.202.39
request 192.168.x.y
nack
discover
offer 137.146.202.39
request 192.168.x.y
nack

possibly interspersed with :

discover
offer 137.146.202.39
request 137.146.202.39
discover
...

Every time the device does a dhcp discover, the remote router is most 
likely to get a reply back first. The device will request the bogus 
address and get nacked. It then goes back to doing a discover.

If the device does manage to pick up your genuine servers offer, when 
it does a request to confirm it, the remote router will nack it.


Then Jeff wrote :

>1) DHCPREQUEST for 192.168.1.3 (192.168.1.1) from 00:14:38:9d:ce:0d
>via 137.146.202.1: wrong network.
>...
>2) DHCPNAK on 192.168.1.3 to 00:14:38:9d:ce:0d via 137.146.202.1
>...
>3) DHCPDISCOVER from 00:14:38:9d:ce:0d via 137.146.202.1
>     DHCPOFFER on 137.146.202.39 to 00:14:38:9d:ce:0d via 137.146.202.1
>...
>4) DHCPREQUEST for 192.168.1.3 (192.168.1.1) from 00:14:38:9d:ce:0d 
>via 137.146.202.1: wrong network
>
>The offering gets lost, and the box tries again.  Why the request got
>lost is a mystery.

This is significantly different to your original posting - and it 
does indeed look like there is a rogue dhcp server. IIRC, the 
192.168.1.1 in those lines is the address of the server that made the 
offer being requested.

So that is all consistent with someone having plugged in a device 
doing dhcp. Time to look at the traffic on the remote network (your 
network switches may have sufficient debugging capabilities) and see 
where the dhcp traffic comes from. Once you have a mac address you 
can pin down the switch port and work out the physical location. 
First step is to simply disable the port - at which point the phone 
may ring and you can speak to the culprit. Otherwise you will have to 
pay a visit - but I believe in most places the use of 'clue by four' 
is frowned upon !

>Question: does ISC DHCP (or the RFCs) have any protocol for dealing with
>machines that repeatedly decline/loose/ignore an offered number?

Not that I'm aware of.