The strange DHCP “NAK” REPLY
This morning I turned on my notebook and found there was no Internet, output from ipconfig shows the wireless adapter had a self-assigned address instead of one from router. It was working fine yesterday…
I turned on my Nexus 7, it is working, so the problem is not at the wireless access point or the router, the focus should be on the notebook. I launched Network Monitor and captured DHCP packets generated by “ipconfig /renew”, it doesn’t look like the DHCP server was in a good mode:
Basically notebook asked for an offer for IP address, DHCP server gave one, notebook requested confirmation, and DHCP server rudely rejected with a NAK reply.
I was suspecting this must has something to do with the static IP address assignment I setup on the router. To be able to use IP address instead of machine name for device-to-device communication, each device will get a fixed address from router based on its mac address. On the notebook, I changed the wireless adapter to use a static IP to be able to login to the router and deleted the static IP rule for the notebook, then changed the wireless adapter back to dynamic IP. After disconnect/re-connect wireless adapter, everything worked fine.
I think I also know what caused this problem. Yesterday I was running a VMware Workstation virtual machine on the notebook, and changed its virtual network adapter from NAT to bridged to do some test. This means it will get IP address from my home-network router, using the notebook’s wireless adapter. Somehow this upsets the DHCP server with static IP rule setup for the notebook. Originally the notebook will get 192.168.1.102 from router by the static IP rule, yesterday the virtual machine was getting 192.168.1.108 after I changed its network adapter to bridged mode. Looks like there is a bug in router firmware, where it gave 192.168.1.108 as offer and then rejected it later as it found out 192.168.1.102 should be given based on notebook’s mac address.
I think I will leave the notebook to get dynamic ip address from DHCP server to avoid this from happening again.