DHCP configuration problem

Question

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;
}
}

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 08:57

score 0 · Answer 1 · answered Sep 12 '11 at 09:06

0

On windows it is:

ipconfig /release
ipconfig /renew

answered Sep 12 '11 at 09:06

cstamas

6,607
24
42

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 09:44

score 0 · Accepted Answer · answered Sep 12 '11 at 14:59

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).

DHCP configuration problem

2 Answers2