Win XP discover/offer/req/ack loop (Help!)
dhcp1 at thehobsons.co.uk
Thu Aug 24 21:43:53 UTC 2006
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 :
possibly interspersed with :
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 18.104.22.168: wrong network.
>2) DHCPNAK on 192.168.1.3 to 00:14:38:9d:ce:0d via 22.214.171.124
>3) DHCPDISCOVER from 00:14:38:9d:ce:0d via 126.96.36.199
> DHCPOFFER on 188.8.131.52 to 00:14:38:9d:ce:0d via 184.108.40.206
>4) DHCPREQUEST for 192.168.1.3 (192.168.1.1) from 00:14:38:9d:ce:0d
>via 220.127.116.11: 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.
More information about the dhcp-users