DHCP issue

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.

Metu69salemi

Do you happen to have any network printers or accesspoint's (or any other network-using device) which have this address as static?

johnpoz

or for that matter .26 setup on another interface on that box that is maybe not connected currently?

xbipin

there is nothing on 0.26 and never was also

johnpoz

Well it sure looks like the box is declining the .26 address. Why would it do that unless it believes there is something else on the .26?

If you say it accepts .29 – why not just change your reservation for it to be on .29?

jimp

Try to assign 0.26 to something that would give you more verbose DHCP logging output - like another pfSense box/vm, a linux box, etc.

If it also rejects 0.26 you'd at least get a better answer about why.

xbipin

there is nothing else on 0.26 because all devices r on dhcp, no static ip assigned to any devoce at all and nor does pfsense show it giving it out to any device because the pool starts and ends in a different range. all my deivces have static mapping in pfsense so there isnt anything magically conencting to it by any chance. i can always just use the 0.29 but if its a bug it needs to be traced and fixed, also if there is any other deivce with same ip then the dhcp gives a different message i guess, like not available or so which i guess any1 can try it out.

ill try to assign 0.26 to some other device and see what the logs show

jimp

It is not a bug on pfSense. If it is a bug, it's a bug on the DHCP client, not pfSense.

pfSense can't make a client tell pfSense to reject an IP - the client is generating that response - not the firewall. There is nothing to "trace" or fix.

xbipin

i just assigned the same 0.26 to a grandstream voip phone and it seems pfsense gave it out just fine this time and the phone was able to call out also without issues but as soon as i switch my ipad to 0.26, its the same old declining message.

also tried overlapping devices with same ip and it seems dhcpd says unavailable as message but not "not found"

jimp

There you have it then… it's a problem with the iPad DHCP client somehow. Why, it's difficult/impossible to say, but it's the client for sure.