DHCP leases UI bug?

JeGr

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.

JeGr

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.

kharkins

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>

jimp

This might help

https://github.com/bsdperimeter/pfsense/commit/8d8f00903f5fe8992cc84ea2cbbc778492038957

NOYB

@jimp:

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

jimp

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>

serialchiller

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!

jimp

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.

serialchiller

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!

phil.davis

On GitHub, BSDperimeter changed to pfSense a while ago. So the link is now:
https://github.com/pfsense/pfsense/commit/8d8f00903f5fe8992cc84ea2cbbc778492038957