# DHCP gets NAK from a ghost apperently...

## Hexorg

Hello. I live in the dorms where internet access is delivered through some routers(IP: 10.1.1.1) to the rooms. From there, I used to have my own router,(PI: 192.168.2.1) connecting 4 of my computers. Recently that router stopped working, so I unplugged it, and plugged my gentoo box laptop directly into the wall socket of the dorm's router, however, I can't seem to make dhcpcd use the lease. The offer comes from it, but so does a NAK from  192.168.2.1... but router is unplugged... IT'S HAUNTING ME!!!!

Anyway, I guess it has maybe to do with some dhcpcd caching of some sort? I tried to delete .info and lease files for eth0, but nothing helps. Here's dhcpcd -d eth0:

```
/ #dhcpcd -d eth0

dhcpcd[7490]: version 5.2.10 starting

dhcpcd[7490]: eth0: using hwaddr 00:23:8b:fb:1c:96

dhcpcd[7490]: eth0: executing `/lib64/dhcpcd/dhcpcd-run-hooks', reason PREINIT

dhcpcd[7490]: eth0: executing `/lib64/dhcpcd/dhcpcd-run-hooks', reason CARRIER

dhcpcd[7490]: eth0: broadcasting for a lease

dhcpcd[7490]: eth0: sending DISCOVER (xid 0x75614e46), next in 4.85 seconds

dhcpcd[7490]: eth0: offered 10.1.2.195 from 10.1.1.1

dhcpcd[7490]: eth0: sending REQUEST (xid 0x75614e46), next in 3.31 seconds

dhcpcd[7490]: eth0: NAK: from 192.168.2.1

dhcpcd[7490]: eth0: executing `/lib64/dhcpcd/dhcpcd-run-hooks', reason NAK

dhcpcd[7490]: eth0: broadcasting for a lease

dhcpcd[7490]: eth0: sending DISCOVER (xid 0x15dad9b8), next in 4.12 seconds

dhcpcd[7490]: eth0: offered 10.1.2.195 from 10.1.1.1

dhcpcd[7490]: eth0: sending REQUEST (xid 0x15dad9b8), next in 4.82 seconds

dhcpcd[7490]: eth0: NAK: from 192.168.2.1

dhcpcd[7490]: eth0: executing `/lib64/dhcpcd/dhcpcd-run-hooks', reason NAK

^Cdhcpcd[7490]: received SIGINT, stopping

dhcpcd[7490]: eth0: removing interface

dhcpcd[7490]: eth0: executing `/lib64/dhcpcd/dhcpcd-run-hooks', reason STOP

```

I pressed ctrl+c or it'd keep doing that until timeout

----------

## Hu

Phantoms cannot generate NAKs.  You probably have a rogue DHCP server on your network that is incorrectly canceling addresses.  You can confirm this by monitoring the actual network traffic with net-analyzer/tcpdump.  The address 192.168.2.1 is not that uncommon among devices used on small LANs, so you are probably getting stepped on by somebody else with the same style router that you disconnected.  Some DHCP clients can be configured to ignore select servers, which will work around the rogue server, but only for the machines which are configured to ignore it.  To fix the problem, you must find and disconnect/reconfigure the rogue DHCP server.  If you can determine its MAC address, your local network administrator may be able to map out its physical location.  If other students are also affected, that should provide additional motivation for him or her to help you.

----------

## Hexorg

I just tried connecting windows machine to the same plug, and it worked, wouldn't that mean that it's some setting error?

----------

## TJNII

Not necessarily.  I would sniff the traffic with wireshark under both Linux and Windows to see what you are getting on the wire.  Windows may just be ignoring the rogue NAK.  I would also compare the MAC address of the 192.168.2.1 on the network with your router.

----------

