Summary: | Core 129: it is not possible to add fixed leases anymore => problem with 'dhcp.cgi' | ||
---|---|---|---|
Product: | IPFire | Reporter: | Matthias Fischer <matthias.fischer> |
Component: | --- | Assignee: | Florian Bührle <florian.buehrle> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | Major Usability | ||
Priority: | Will affect all users | CC: | adolf.belka, bbitsch, benediktkahl, florian.buehrle, grisey, matthias, mentalic, michael.tremer, rnaylor, tad |
Version: | 2 | ||
Hardware: | all | ||
OS: | Linux | ||
Bug Depends on: | |||
Bug Blocks: | 12082 | ||
Attachments: |
Adding new fixed leases with one 'add' click
Adding new fixed leases with one 'add' click |
Description
Matthias Fischer
2019-04-13 09:37:08 UTC
After adding a new lease, you are in editing mode. All fields are set right, but a second click ('update' ) is necessary. With determining the exact mode 'add/edit' this second click can be avoided for new entries ( new MAC/IP combination). Created attachment 669 [details]
Adding new fixed leases with one 'add' click
Not being Fermat ( :) ), I supply a patch for the bug.
Bernhard, could you please submit your patch to the ML? Tested. Sorry, the patch didn't work. The first entry in the existing list was deleted. Best, Matthias Was this entry identical in MAC and IP? If yes, the "addition" is treated as "edit" of this entry, this must be confirmed by clicking "update". Hi, No, the new entry was NOT identical. I always used 01:02:03:04:05:06 and a completely new IP-address. This combination works with 'dhcp.cgi' from Core 128. This new entry is added at the end of the list (because of the ip-address, its the next higher address in the list). But the first entry is deleted then. Best, Matthias Created attachment 670 [details]
Adding new fixed leases with one 'add' click
Comment on attachment 670 [details]
Adding new fixed leases with one 'add' click
Bug in first patch should be corrected.
=> https://patchwork.ipfire.org/patch/2201/ => https://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=e04818df2f5f827234c46c6c71dd258a64a9801a Comment on attachment 670 [details]
Adding new fixed leases with one 'add' click
Patch does not conform to development rules and is therefore refused.
Seeing this bug in core 131 fresh install. Cannot manually add more than one fixed lease. Wayne, you're invited to solve this problem. Suggestions are my postings in the forum and the patches of Matthias. Trying to help but I'm not a coder. My background is a few decades of control systems support. I did figure out a method to add leases though, which may be helpful. DHCP manual lease addition after first is entered by add/update. 1-Disable existing lease 2-Enter new lease data, uncheck enable box 3-Click add, lease appears in yellow at top of list 4-At bottom of lease list click enable box which creates a blank entry at bottom of list and looses your new entry. 5-Move the blank entry to top of list by clicking edit of the top lease, then update. Blank moves to top. 6-Add your new lease data again, uncheck enable. Then click add, update and blank line will be replaced with your new lease. Repeat as needed. Thx for your workaround. This may help in verification of a possible fix. *** Bug 12081 has been marked as a duplicate of this bug. *** This workaround doesn't solve the problem for me. But I was able to add 10 static leases, but can't add another one without another vanishing. Unfortunately my programming skills are absolutely basic. I can add entries to the fixleases file manually, which are written to /etc/dhcpd.conf as soon as I update anythin in dhcp cgi. But when I add any entry in the web interface, anotherone is overwritten. I had a look into dhcp.cgi, but as mentioned, my skills are too basic. May have someting to do with the iteration of the foreach loop or the sorting, but didn't really understand everything :-( *** Bug 12082 has been marked as a duplicate of this bug. *** Big thank you to matthias.fischer@ipfire.org for a work around. This got me around a critical blocker in my environment. This is also not working: "Note that IPFire's DNS server automatically adds the first word in the remark field as a host name entry for the IP address configured in this section." from https://wiki.ipfire.org/configuration/network/dhcp Workaround is to add the hostname in the hostnames after adding hostname to Edit Hosts, DNS stopped working altogether. I could not even go to the shutdown page. I had to login with ip fire's ip in the url and then I was able to reboot. Now everything is working - I have 2 fixed leases and both are defined in the Edit Hosts. @Wayne: Thanks a lot for this workaround - helps me a lot with Core 131 to add a new entry! (However you figured this out to be working lol) To clarify a bit deeper: If you already have some entries in your list, you modify only the most top entry - like @Bene described - when adding a new fixed lease, what is quite critical when the most top (== most important for me) lease vanishes ;) You're right! After reading and trying to comprehend the dhcp.cgi file I've located the problem in the "smashing" of add/edit operations with display comfort/sorted display. Idea in the actual file is to put the edited entry at top of the list, near the edit box. But I fear this collides with the sort order of the entries (an array). This just for comment from my side. I'll post results of my investigations here/in the dev list. Bernhard @Matthias: Glad to help! I've got the knack for working around bugs. Lots of experience with low installed base software on untested hardware/software combinations. Regards Wayne I think this is causing another issue with DHCP assigning duplicate ip addresses. DHCP is scoped to x.x.x.100 to x.x.x.200. After I rebooted and got my 2 static DHCP leases configured, I logged into my ESXi host to build a new cluster. I created a brand new VM and then cloned it 4 times expecting a dhcp ip address to be assigned by ipfire. This resulted in 3 of the machines receiving the same ip address. I confirmed that VMWare had configured a different mac address to each virtual nic. Since these were brand new, none of the mac addresses where part of my static records or applying the workaround for static leases. I will be testing this out in few minutes. Bernhard Bitsch's array "smashing" my also causing the first few dhcp leases to be the same ip address. Please do not mix up dhcpd and WUI dhcp.cgi. dhcp.cgi is the configuration page for dhcpd in IPFire. It manages dhcpd options, fixed leases at its own. State is exported to dhcp.conf, which is the configuration of dhcpd, the DHCP server daemon. The DHCP server leases IPs according to this config. Each different MAC should receive a different IP (if fixed leases and dynamic IP pools are disjunct!! ). You can monitor the leasing of IPs in the system log /var/log/messages or from the WUI Logs->System Logs section "DHCP server" I'll try to describe the solution for this bug in short: - in "Add" operation determine whether it is a new entry or modification of an exting entry. -- Add new entry at end of array of fixed leases ( push ) -- modify fields of existing array element KEY2 - because in both cases sort order can be broken, sort array of fixed leases Hope, this helps. A short fix can be: after line 445 in dhcp.gi insert open(FILE, ">$filename2") or die 'Unable to open fixed lease file.'; print FILE @current2; close(FILE); This retains the actual process insert the data for the new entry in the box, press "add" data are shown again, new entry is first row in list; press "update" The reason is just simple: every change to the list of leases must be saved to the file between two calls of dhcp.cgi Most this is done by sorting the entries. I've posted a patch some days before to the devel list. (In reply to Bernhard Bitsch from comment #28) > I've posted a patch some days before to the devel list. Yes I know. (In reply to Michael Tremer from comment #29) > (In reply to Bernhard Bitsch from comment #28) > > I've posted a patch some days before to the devel list. > > Yes I know. Sorry, this should not be a heads up post. My last post only described the fix, therefore I wanted complete the information. The problem still exists in core 132. I dug into it a little at the IPFire CLI and found that if I edited /var/ipfire/dhcp/fixleases directly, I could add more than one static lease, but they were not "active". If I go to the DHCP page in the GUI, they are all displayed. In the GUI, if I add a new one by clicking "Add" on a line in the "Current dynamic leases" section, that new one will be added, but the previously existing first line in the /var/ipfire/dhcp/fixleases is overwritten. It's the overwriting of the first line in /var/ipfire/dhcp/fixleases that seems to be the underlying problem. My workaround will be to manually add them all to /var/ipfire/dhcp/fixleases, with a dummy line at the top, add one more from the GUI and then save it to cause them all to be activated. Is this bug still valid for anyone now that we are on CU172? I have 26 entries in my fixed leases list and all have worked fine when I entered them and also when I have had to edit them. (In reply to Bernhard Bitsch from comment #27) > A short fix can be: > > after line 445 in dhcp.gi insert > open(FILE, ">$filename2") or die 'Unable to open fixed lease file.'; > print FILE @current2; > close(FILE); > > This retains the actual process > insert the data for the new entry in the box, press "add" > data are shown again, new entry is first row in list; press "update" > > The reason is just simple: every change to the list of leases must be saved > to the file between two calls of dhcp.cgi Most this is done by sorting the > entries. The patch mentioned by Bernhard above was committed on 5th June 2019 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=e4f9ea3c1650d369f8a764605203778bfea0d390 The fix was released into Core Update 133 https://blog.ipfire.org/post/ipfire-2-23-core-update-133-has-been-released |