DHCP issue

[xbipin]

i think something has gone wrong with dhcp coz what i had done is enabled dhcp on lan, then connected all my devices etc so they go ip from pfsense in range 192.168.0.2 - 0.200, then i created a static map for each mac id to each individual ip and then changed the dhcp dynamic pool to 0.111 - 0.250 but for some reason my ipad i had assigned to 0.26 bu it just wont connect and there is no other device on that ip also, systemlog shows dhcpd declined saying not found when the ipad requests for ip, if i remove the static mapping then dhcp should start giving ip from 0.111 onwards but due to something its giving ips starting from 0.189 onwards (earlier i had set a shorter range 0.189 - 250) which means it has remembered that setting but in spite of the new range i told it to give, its not following that and i cant get it to work on static map 0.26 and it might be its reading from some cache and new settings r not applied coz during earlier setup some device might have got 0.26 and now that might be on a different static map and when assigning 0.26 to ipad, dhcpd might be reading some cache and saying not found to avoid some conflict

[xbipin]

i get a lot od these also in my system log, all clients r on dhcp and nothing specified manually

the xx:xx:xx i have replaced

Sep 30 15:14:42 	kernel: arp: 192.168.0.160 moved from b8:17:c2:xx:xx:xx to 14:da:e9:xx:xx:xx on vr0
Sep 30 15:16:13 	kernel: arp: 192.168.0.160 moved from 14:da:e9:xx:xx:xx to b8:17:c2:xx:xx:xx on vr0
Sep 30 15:17:45 	kernel: arp: 192.168.0.160 moved from b8:17:c2:xx:xx:xx to 14:da:e9:xx:xx:xx on vr0

[jimp]

I split this into its own topic because it's not likely related to the topic you posted it under. Always start a new thread unless you're 100% certain the issue is the same.

The ARP messages mean there is an IP conflict on those IPs. Two things are trying to use the same IP. 14:da:e9 is an Asus device, b8:17:c2 is Apple.

[xbipin]

but the fact is there r no 2 devices using same as i have made a static map for each device and all devices set to dhcp and even if i set a static map for that ipad to say like 0.29 then it works all fine.

the asus mac might be of a repeater but dont the repeaters have no mac of its own as they simply repeat and they r not even supposed to get an ip at all

[jimp]

I don't know anything about your network or the devices on it. From what you've posted, you have an IP conflict of some sort, or the traffic is maybe taking two separate paths. The apple device and the asus device are both trying to use 192.168.0.160. How they both got 192.168.0.160 for an IP, I don't know.

Check the DHCP log, the DHCP lease database, and confirm those MACs are actually the devices you think they are.

[xbipin]

in the logs i just get this error and dhcp declines saying not found.

pfsense is connected to a netgear and dlink wireless access point set in bridge mode so they dont give out any ip but give coverage on each separate floors and they seem to behave just fine, now this asus repeater repeats the signal from the dlink accesspoint and the iphone connects to this dlink with the repeater helping in signal coverage so i guess the ipad once connected then is fine but if it goes out of coverage or switches off then the repeater takes over and that causes the mac id take over on same ip and when device is back again then iphone takes the same ip.

the above is for 160 but the main issue is ip 0.26 im not able to map to ipad mac id, i mean it gets assigned but when ipad requests the ip, dhcpd declines and says not found and in the logs i dont see this mac id changing error for 0.26 as this ipad connects to dlink directly, nothing in between so the mac id changing issue isnt there in that but just dhcpd wont give 0.26 to this ipad

[jimp]

The post the exact logs from DHCP, without that, nothing can really be determined.

Also the contents of /var/dhcpd/etc/dhcpd.conf

[xbipin]

can i give u access to the box rather than posting all mac id here in the forum

[jimp]

No, that is not a service we can do for forum users. If you want that level of service, you can subscribe to commercial support, or post a bounty for someone else to take a look at it.

You can partially obscure the MACs if you like, but you've already posted a couple of them and I doubt posting the remaining relevant ones would really do much in the way of harm. If you obscure them, at least leave the first three positions and the last one readable.

[xbipin]

dhcpd.conf

option domain-name "domain";
option ldap-server code 95 = text;
option domain-search-list code 119 = text;

default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
subnet 192.168.0.0 netmask 255.255.255.0 {
	pool {
		range 192.168.0.111 192.168.0.250;
	}

	option routers 192.168.0.1;
	option domain-name-servers 192.168.0.1;
	default-lease-time 600;
	max-lease-time 1200;

}
host s_lan_0 {
	hardware ethernet 00:22:15:xx:xx:ec;
	fixed-address 192.168.0.2;
}
host s_lan_1 {
	hardware ethernet 00:22:15:xx:xx:b7;
	fixed-address 192.168.0.3;
}
host s_lan_2 {
	hardware ethernet 00:22:15:xx:xx:34;
	fixed-address 192.168.0.4;
}
host s_lan_3 {
	hardware ethernet 00:23:54:xx:xx:2f;
	fixed-address 192.168.0.5;
}
host s_lan_4 {
	hardware ethernet 00:22:15:xx:xx:c1;
	fixed-address 192.168.0.6;
}
host s_lan_5 {
	hardware ethernet 00:22:15:xx:xx:a8;
	fixed-address 192.168.0.7;
}
host s_lan_6 {
	hardware ethernet 00:23:54:xx:xx:26;
	fixed-address 192.168.0.8;
}
host s_lan_7 {
	hardware ethernet 00:22:15:xx:xx:00;
	fixed-address 192.168.0.9;
}
host s_lan_8 {
	hardware ethernet 70:d4:f2:xx:xx:ca;
	fixed-address 192.168.0.21;
}
host s_lan_9 {
	hardware ethernet b8:17:c2:xx:xx:8b;
	fixed-address 192.168.0.22;
}
host s_lan_10 {
	hardware ethernet 24:ab:81:xx:xx:64;
	fixed-address 192.168.0.23;
}
host s_lan_11 {
	hardware ethernet 00:1c:c0:xx:xx:32;
	fixed-address 192.168.0.24;
}
host s_lan_12 {
	hardware ethernet f8:7b:7a:xx:xx:ea;
	fixed-address 192.168.0.25;
}
host s_lan_13 {
	hardware ethernet 00:19:e3:xx:xx:bf;
	fixed-address 192.168.0.27;
}
host s_lan_14 {
	hardware ethernet 00:26:9e:xx:xx:79;
	fixed-address 192.168.0.28;
}
host s_lan_15 {
	hardware ethernet 04:54:53:xx:xx:8e;
	fixed-address 192.168.0.29;
}
host s_lan_16 {
	hardware ethernet 00:0b:82:xx:xx:13;
	fixed-address 192.168.0.100;
}
host s_lan_17 {
	hardware ethernet 00:18:f8:xx:xx:9a;
	fixed-address 192.168.0.101;
}
host s_lan_18 {
	hardware ethernet 00:1b:09:xx:xx:21;
	fixed-address 192.168.0.102;
}
host s_lan_19 {
	hardware ethernet 00:1b:09:xx:xx:a5;
	fixed-address 192.168.0.103;
}
host s_lan_20 {
	hardware ethernet 00:1b:09:xx:xx:c0;
	fixed-address 192.168.0.104;
}

system log

Sep 30 21:14:30 	kernel: arp: 192.168.0.160 moved from b8:17:c2:xx:xx:8b to 00:1d:0f:xx:xx:cd on vr0
Sep 30 21:16:21 	kernel: arp: 192.168.0.160 moved from 00:1d:0f:xx:xx:cd to b8:17:c2:xx:xx:8b on vr0
Sep 30 21:19:23 	kernel: arp: 192.168.0.160 moved from b8:17:c2:xx:xx:8b to 00:1d:0f:xx:xx:cd on vr0
Sep 30 21:23:04 	kernel: arp: 192.168.0.23 moved from 14:da:e9:xx:xx:1d to 24:ab:81:xx:xx:64 on vr0
Sep 30 21:25:48 	kernel: arp: 192.168.0.23 moved from 24:ab:81:xx:xx:64 to 00:1d:0f:xx:xx:cd on vr0
Sep 30 21:25:57 	kernel: arp: 192.168.0.23 moved from 00:1d:0f:xx:xx:cd to 24:ab:81:xx:xx:64 on vr0
Sep 30 21:31:17 	kernel: arp: 192.168.0.23 moved from 24:ab:81:xx:xx:64 to 00:1d:0f:xx:xx:cd on vr0
Sep 30 21:31:29 	kernel: arp: 192.168.0.160 moved from 00:1d:0f:xx:xx:cd to b8:17:c2:xx:xx:8b on vr0
Sep 30 21:36:02 	kernel: arp: 192.168.0.160 moved from b8:17:c2:xx:xx:8b to 00:1d:0f:xx:xx:cd on vr0

[jimp]

There is no mapping in that config for 0.26, and the DHCP log would be more helpful than the system log.

[xbipin]

yes it wasnt working so i made a map to 0.29 to make it work, the person is offline as of now so by tomorrow ill move the static map to 0.26 and get u fresh logs of dhcp.

would it help to delete the  dhcplease files manually and reboot pfsense to make it forget about any cache etc or past leases

[xbipin]

bytheway r repeaters designed to work such that they move the mac to ip to theirs when device is off then again move device mac to p when its back on again?

[xbipin]

i delete the dhcplease files manually and also rebooted and still dhcp declines lease on static map 0.26

Sep 30 22:10:14 	dhcpd: DHCPDECLINE of 192.168.0.26 from 04:54:53:xx:xx:8e via vr0: not found
Sep 30 22:10:24 	dhcpd: DHCPDISCOVER from 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:24 	dhcpd: DHCPOFFER on 192.168.0.26 to 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:25 	dhcpd: DHCPREQUEST for 192.168.0.26 (192.168.0.1) from 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:25 	dhcpd: DHCPACK on 192.168.0.26 to 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:26 	dhcpd: DHCPDECLINE of 192.168.0.26 from 04:54:53:xx:xx:8e via vr0: not found
Sep 30 22:10:36 	dhcpd: DHCPDISCOVER from 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:36 	dhcpd: DHCPOFFER on 192.168.0.26 to 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:37 	dhcpd: DHCPREQUEST for 192.168.0.26 (192.168.0.1) from 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:37 	dhcpd: DHCPACK on 192.168.0.26 to 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:39 	dhcpd: DHCPDECLINE of 192.168.0.26 from 04:54:53:xx:xx:8e via vr0: not found
Sep 30 22:10:49 	dhcpd: DHCPDISCOVER from 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:49 	dhcpd: DHCPOFFER on 192.168.0.26 to 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:50 	dhcpd: DHCPREQUEST for 192.168.0.26 (192.168.0.1) from 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:50 	dhcpd: DHCPACK on 192.168.0.26 to 04:54:53:xx:xx:8e via vr0
Sep 30 22:10:51 	dhcpd: DHCPDECLINE of 192.168.0.26 from 04:54:53:xx:xx:8e via vr0: not found

[jimp]

04:54:53… Is rejecting the IP not the server.

[jimp]

What I mean by that is that the server is offering the client 0.26. The client is rejecting 0.26 and then asking for a different IP.

Why the client is rejecting 0.26, I don't know, but it's still something the client is doing, not the server.

As for the repeater changing the MAC, some might do that if they aren't in a true bridged mode. Under normal/desirable circumstances it shouldn't be doing that for client traffic.

[xbipin]

how is that possible coz its on dhcp and even if i static map to 0.29 then it will accept it and everything works

[jimp]

I don't know, but it's definitely the client rejecting the IP.

[pierob]

From RFC2131:
"If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server MUST mark the network address as not available and SHOULD notify the local system administrator of a possible configuration problem."

Maybe you can check on 04:54:53 system logs the reason why it declines the offer (e.g. what these other means are).

[jimp]

Yep, most likely it's already in use.