EDIT:
We have following setup: User comes to building, he gets address from range for unknown clients (192.168.100.0/25) and can only get to our web site. We call it anonymous range. Let's say our user acquired address 192.168.100.16 and won§t get past the local network.
Then he must go and register his MAC address and is assigned new fixed IP from 192.168.40.0/22 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 192.168.100.16 address, which is wrong, because he should get let's say 192.168.40.156 (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 192.168.100.16 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 192.168.40.0 netmask 255.255.252.0 {
option routers 192.168.40.1;
...
host tomas3 { hardware ethernet cc:52:af:97:55:25; fixed-address tomas3.nat.b.c.d; }
...
}
range 192.168.100.2 192.168.100.126;
option routers 192.168.100.1;
allow unknown-clients;
}
}
On windows it is:
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).