Bug 12050 - Core 129: it is not possible to add fixed leases anymore => problem with 'dhcp.cgi'
Summary: Core 129: it is not possible to add fixed leases anymore => problem with 'dhc...
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all Linux
: Will affect all users Major Usability
Assignee: Florian Bührle
QA Contact:
URL:
Keywords:
: 12081 12082 (view as bug list)
Depends on:
Blocks: 12082
  Show dependency treegraph
 
Reported: 2019-04-13 09:37 UTC by Matthias Fischer
Modified: 2023-03-08 14:07 UTC (History)
10 users (show)

See Also:


Attachments
Adding new fixed leases with one 'add' click (2.21 KB, patch)
2019-04-13 13:03 UTC, Bernhard Bitsch
Details
Adding new fixed leases with one 'add' click (2.19 KB, patch)
2019-04-13 23:56 UTC, Bernhard Bitsch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Fischer 2019-04-13 09:37:08 UTC
Since Core 129 you can't add new fixed leases.

See: https://forum.ipfire.org/viewtopic.php?f=27&t=22598

Steps to repoduce:

1. Add and activate a test entry for a fixed lease, e.g.:
MACID 01:02:03:04:05:06, IP-Address 192.168.100.34.

2. Click add.

3. New entry - marked yellow - appears on top of the existing list.

4. After changing screens - or refreshing the page - the new entry is gone and the unchanged (old) list is still there.

Reverting back to 'dhcp.cgi' from Core 128 fixes the problem.

Best,
Matthias
Comment 1 Bernhard Bitsch 2019-04-13 12:19:10 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).
Comment 2 Bernhard Bitsch 2019-04-13 13:03:15 UTC
Created attachment 669 [details]
Adding new fixed leases with one 'add' click

Not being Fermat ( :) ), I supply a patch for the bug.
Comment 3 Michael Tremer 2019-04-13 17:22:19 UTC
Bernhard, could you please submit your patch to the ML?
Comment 4 Matthias Fischer 2019-04-13 21:10:33 UTC
Tested.

Sorry, the patch didn't work.

The first entry in the existing list was deleted.

Best,
Matthias
Comment 5 Bernhard Bitsch 2019-04-13 21:59:05 UTC
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".
Comment 6 Matthias Fischer 2019-04-13 23:12:56 UTC
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
Comment 7 Bernhard Bitsch 2019-04-13 23:56:06 UTC
Created attachment 670 [details]
Adding new fixed leases with one 'add' click
Comment 8 Bernhard Bitsch 2019-04-13 23:57:52 UTC
Comment on attachment 670 [details]
Adding new fixed leases with one 'add' click

Bug in first patch should be corrected.
Comment 10 Bernhard Bitsch 2019-04-18 21:50:49 UTC
Comment on attachment 670 [details]
Adding new fixed leases with one 'add' click

Patch does not conform to development rules and is therefore refused.
Comment 11 Wayne 2019-05-10 01:45:21 UTC
Seeing this bug in core 131 fresh install. Cannot manually add more than one fixed lease.
Comment 12 Bernhard Bitsch 2019-05-10 11:06:02 UTC
Wayne, you're invited to solve this problem.
Suggestions are my postings in the forum and the patches of Matthias.
Comment 13 Wayne 2019-05-10 23:46:29 UTC
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.
Comment 14 Bernhard Bitsch 2019-05-11 20:02:11 UTC
Thx for your workaround.
This may help in verification of a possible fix.
Comment 15 Michael Tremer 2019-05-16 16:54:39 UTC
*** Bug 12081 has been marked as a duplicate of this bug. ***
Comment 16 Bene 2019-05-16 18:22:50 UTC
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 :-(
Comment 17 Ryan Naylor 2019-05-16 19:19:55 UTC
*** Bug 12082 has been marked as a duplicate of this bug. ***
Comment 18 Ryan Naylor 2019-05-16 19:32:39 UTC
Big thank you to matthias.fischer@ipfire.org for a work around.  This got me around a critical blocker in my environment.
Comment 19 Ryan Naylor 2019-05-16 19:36:46 UTC
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
Comment 20 Ryan Naylor 2019-05-16 20:00:02 UTC
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.
Comment 21 Matthias Neuhaus 2019-05-17 06:52:40 UTC
@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 ;)
Comment 22 Bernhard Bitsch 2019-05-17 11:12:31 UTC
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
Comment 23 Wayne 2019-05-17 13:52:25 UTC
@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
Comment 24 Ryan Naylor 2019-05-17 15:33:07 UTC
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.
Comment 25 Bernhard Bitsch 2019-05-17 16:10:05 UTC
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"
Comment 26 Bernhard Bitsch 2019-05-20 15:46:52 UTC
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.
Comment 27 Bernhard Bitsch 2019-05-20 21:22:34 UTC
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.
Comment 28 Bernhard Bitsch 2019-05-28 12:46:09 UTC
I've posted a patch some days before to the devel list.
Comment 29 Michael Tremer 2019-05-28 12:47:14 UTC
(In reply to Bernhard Bitsch from comment #28)
> I've posted a patch some days before to the devel list.

Yes I know.
Comment 30 Bernhard Bitsch 2019-05-28 12:57:01 UTC
(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.
Comment 31 Tad Marko 2019-06-26 18:30:04 UTC
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.
Comment 32 Adolf Belka 2023-02-24 11:17:33 UTC
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.
Comment 33 Adolf Belka 2023-03-08 14:04:37 UTC
(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
Comment 34 Adolf Belka 2023-03-08 14:07:50 UTC
The fix was released into Core Update 133

https://blog.ipfire.org/post/ipfire-2-23-core-update-133-has-been-released