DHCP leases UI bug?
-
Interesting, that error implies that your DHCP config is somehow incomplete, that line is trying to pull in values from the start/end of the DHCP range and it's saying that the range itself may not exist at all.
If you take a config backup, what does the DCHP section of the config look like?
-
Gross, didn't actually think it was based on config being pulled. I merely thought it was from reading values from the leases file. Thanks Jimp for pointing that out, didn't see hat as I was browsing through the PHP file, I'll look into it and post ASAP.
-
Nope, that doesn't seem to fit:
<dhcpd><lan><range><from>172.27.1.80</from> <to>172.27.1.99</to></range> <defaultleasetime><maxleasetime><netmask><failover_peerip><gateway>172.27.1.1</gateway> <domain>test.lan</domain> <domainsearchlist>test.lan, mobile.test.lan</domainsearchlist> <ddnsdomain><tftp><ldap><next-server><filename><rootpath><numberoptions><enable><dnsserver>172.27.1.1</dnsserver> <dnsserver>172.27.1.2</dnsserver> <ntpserver>172.27.1.1</ntpserver> <ntpserver>172.27.1.2</ntpserver></enable></numberoptions></rootpath></filename></next-server></ldap></tftp></ddnsdomain></failover_peerip></netmask></maxleasetime></defaultleasetime></lan></dhcpd>
That seems pretty much OK to me. So it doesn't seem to be a problem related to the given range. Even if I change the range parameters, it is saved right (and shows up in the config) but the error resists. It always occurs after the first IP is given out. If the list is empty, the parsing seems to work.
-
Any more information on this?
I have the same problem and dhcpd config seems to be OK.
- <dhcpd>- <lan>- <range><from>172.16.1.121</from> <to>172.16.1.149</to></range> <defaultleasetime>3600</defaultleasetime> <maxleasetime>7200</maxleasetime> <netmask><failover_peerip><gateway>172.16.1.1</gateway> <domain><domainsearchlist><enable><ddnsdomain><tftp><ldap><next-server><filename><rootpath></rootpath></filename></next-server></ldap></tftp></ddnsdomain></enable></domainsearchlist></domain></failover_peerip></netmask></lan> <opt3>- <opt7>- <range><from>172.17.3.200</from> <to>172.17.3.244</to></range> <defaultleasetime>3600</defaultleasetime> <maxleasetime>7200</maxleasetime> <netmask><failover_peerip><gateway>172.17.3.1</gateway> <domain><domainsearchlist><enable><ddnsdomain><tftp><ldap><next-server><filename><rootpath></rootpath></filename></next-server></ldap></tftp></ddnsdomain></enable></domainsearchlist></domain></failover_peerip></netmask></opt7> - <opt10>- <range><from>172.17.4.200</from> <to>172.17.4.244</to></range> <defaultleasetime>3600</defaultleasetime> <maxleasetime>7200</maxleasetime> <netmask><failover_peerip><gateway>172.17.4.1</gateway> <domain><domainsearchlist><enable><ddnsdomain><tftp><ldap><next-server><filename><rootpath></rootpath></filename></next-server></ldap></tftp></ddnsdomain></enable></domainsearchlist></domain></failover_peerip></netmask></opt10></opt3></dhcpd>
-
This might help
https://github.com/bsdperimeter/pfsense/commit/8d8f00903f5fe8992cc84ea2cbbc778492038957
-
This might help
https://github.com/bsdperimeter/pfsense/commit/8d8f00903f5fe8992cc84ea2cbbc778492038957
Could you please explain a couple things for me?
-
It appears the dhcp config in the above posts are a range. So why would they not be an array and causing this php error? Mine is also a range. But unlike these others I do not get this error.
-
The patch you linked to starts on line 371. That code hunk in my status_dhcp_leases.php starts at line 350. Why the difference?
Thanks
2.0.1-RELEASE (i386)
built on Mon Dec 12 18:24:17 EST 2011
FreeBSD 8.1-RELEASE-p6 -
-
-
I don't know, but that's where the error is, so that's where the check went. The second guy had a "<opt3>" entry which could have led to this, but the fist one I still don't see how it would have landed on that error. Either way, it's more correct to test and bypass here than it would be to keep processing, so it's the right fix for the error at least.
-
This patch is against master (2.1), you're probably on 2.0.x.</opt3>
-
-
I'm sorry if this is a total noob question.
Will the proposed fix from the github link be persistent? I mean, will the fix remain in place after a reboot?
thanks! -
If you edit the change into the file, then yes it'll persist between reboots. It would be lost during a firmware upgrade if the new firmware doesn't already include this change.
-
Verry sorry to reply to an old topic, but did anyone document the github link above? I'm having the same problem again on one machine and it's quite annoying. Thanks for any help!
-
On GitHub, BSDperimeter changed to pfSense a while ago. So the link is now:
https://github.com/pfsense/pfsense/commit/8d8f00903f5fe8992cc84ea2cbbc778492038957