Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


We have following setup: User comes to building, he gets address from range for unknown clients ( and can only get to our web site. We call it anonymous range. Let's say our user acquired address and won§t get past the local network.

Then he must go and register his MAC address and is assigned new fixed IP from address range. DHCP configuration is updated and reloaded. User then "gets to the Internet" because this range is not blocked by firewall. ipconfig /release /renew routine worked every time.

What happened this week: After user registers his MAC and DHCPD reloads he still gets the address, which is wrong, because he should get let's say (his MAC and this address are fixed in config). Effect being he can't get to the Internet. When looking at daemon.log I see that there is REQUEST for address and DHCP server ACKonwledges it. Once occurred on Windows 7 and once on tablet running Android 3.0.

This never happened before and we can't figure out how to solve this. Reinstalling Windows helps but that is just stupid, can't ask that from users.

shared-network NET {

subnet netmask {
            option routers;
            host tomas3 { hardware ethernet cc:52:af:97:55:25; fixed-address tomas3.nat.b.c.d; }
            option routers;
            allow unknown-clients;
share|improve this question
You're going to have to rewrite this question MUCH CLEARER, as it stands it's very difficult to understand what you're saying. – Chopper3 Sep 12 '11 at 8:57

On windows it is:

ipconfig /release
ipconfig /renew
share|improve this answer
Hi, we've tried that and it does not help, Windows still asks for address he used have, which is wrong in our case. – zeratul021 Sep 12 '11 at 9:44
up vote 0 down vote accepted

We already figured out what was the problem. We didn't use fixed IPv4 address but FQDN. We noticed that name server configuration wasn't reloading because of wrong rndc access right. So reverse lookup didn't yield valid IPv4 and therefore a fall-through in DHCP configuration occurred (to our anonymous range).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.