This is normal behavior. well not really, that address is called a apipa address.

It's normal behavior for alot of O.S's to give itself an address in the 169.254.x.x range when they fail to get DHCP responses.

My guess is your library is doing this for you.

It's kind of like the ad-hoc of addressing, if all devices fail to get a dhcp response they will all be assigned to the same subnet, and can communicate with those apipa addresses.

My suspicion is that it may be your router. You can verify this by downloading a free DHCP server application for your OS. Plug in via Ethernet for the PC that's running the DHCP App, Turn off DHCP in the router. If it stops happening you know it's the router.

This is normal behavior. well not really, that address is called a apipa address.

It's normal behavior for alot of O.S's to give itself an address in the 169.254.x.x range when they fail to get DHCP responses.

My guess is your library is doing this for you.

It's kind of like the ad-hoc of addressing, if all devices fail to get a dhcp response they will all be assigned to the same subnet, and can communicate with those apipa addresses.

My suspicion is that it may be your router. You can verify this by downloading a free DHCP server application for your OS. Plug in via Ethernet for the PC that's running the DHCP App, Turn off DHCP in the router. If it stops happening you know it's the router.

Edit: Also, this may be a firmware caveat in the router. Check the router manufacturers website and see if any firmware updates are available. if it hangs with DHCP, most likely every customer with that firmware revision has had this problem. This sort of thing usually gets patched very quickly.