From: Adolf Belka <ahb.ipfire@gmail.com>
To: development@lists.ipfire.org
Subject: Re: Re: Testing required for modified dhcp.cgi file related to bug 10743
Date: Wed, 18 Nov 2020 12:39:20 +0100 [thread overview]
Message-ID: <77077ef2-fc9f-07a7-55b9-518fd7b78b1f@gmail.com> (raw)
In-Reply-To: <3b26cc1c-0213-0d10-589f-a7f0e0f7c1a5@rymes.com>
[-- Attachment #1: Type: text/plain, Size: 5519 bytes --]
I have had a quick scan through bug 10629. I think it makes sense for it to be dealt with separately from 10743.
Bug 10743 has been my learning experience for HTML and CGI and also expanding on my limited Perl knowledge.
Based on my experience with bug 10743 I would be willing to work on bug 10629.
However I see that Bernhard has been involved in looking at this in the past and currently the bug is assigned to Michael. I don't want to tread on anyone's toes if they want to continue working on it but if they agree I would be happy to pick it up and give it a go.
Regards,
Adolf.
On 17/11/2020 03:56, Tom Rymes wrote:
> I wasn't going to say anything, as I don't want to go expanding the scope of the work, but this last comment reminded me that there is another outstanding "bug" with regard to DHCP, namely #10629
>
> https://bugzilla.ipfire.org/show_bug.cgi?id=10629
>
> Below you were mentioning how the subnet and pool portions of the file and that bug revolves around that same area. Namely, unless the user remembers to keep the fixed leases separate from the lease pool, then DHCP can issue duplicate addresses that conflict with the fixed addresses. This requires the device with the fixed address to be offline, so it's not a show-stopper.
>
> It's probably something for another day, but seeing as you're in the file and dealing with the range definition, I figured I'd mention it.
>
> Tom
>
> On 11/16/2020 8:14 AM, Adolf Belka wrote:
>> Hi All,
>>
>> I have now modified the dhcp.cgi file changes so that the pool declaration is only made around the range statement. All other options apply to all clients in a subnet.
>>
>> If no range values are on the dhcp page then the pool declaration is not added into dhcpd.conf
>>
>> I now only have "deny known-clients" to be added. The "deny unknown-clients" option seemed to be redundant in the context of IPFire. If you have a range statement together with a deny unknown-clients statement then the only clients that could access the range would be known-clients but in IPFire these are always clients with fixed leases, which are from outside the range. Using deny unknown-clients makes sense if you have host declarations that do not include a fixed-address which can be created in other dhcpd server setups but not in IPFire.
>>
>> I have tested this out with and without ranges specified and it worked for me. Also all the other options were correctly applied to the fixed leases as well this time.
>>
>> However the proof of the pudding is in the eating by other people as well so would appreciate your testing and feedback again.
>>
>> The modified dhcp-core151-new.cgi file is attached.
>>
>> Regards,
>>
>> Adolf
>>
>>
>> On 14/11/2020 23:13, Adolf Belka wrote:
>>> Hi Matthias,
>>>
>>> I have added your feedback into bugzilla.
>>>
>>> After I read your input and looked at my changes I had one of those
>>> "Duh, that's so obvious, why on earth did I do that"
>>> moments. I know the error I made and I have a reasonable idea of how I can fix it.
>>>
>>> Will send out a diff once I have made and tested the changes.
>>> Thanks very much for the help, much appreciated.
>>>
>>> Regards,
>>> Adolf.
>>>
>>>
>>> On 14/11/2020 17:26, Matthias Fischer wrote:
>>>> Hi,
>>>>
>>>> Tested - sorry, didn't work - 'dhcp' wouldn't start. Perhaps my fault. I
>>>> have suspected something like this for my machine.
>>>>
>>>> /var/log/messages tells me:
>>>>
>>>> ...
>>>> Nov 14 16:36:27 ipfire dhcpd: /etc/dhcp/dhcpd.conf line 16: Pool
>>>> declaration with no address range.
>>>> Nov 14 16:36:27 ipfire dhcpd: }
>>>> Nov 14 16:36:27 ipfire dhcpd: ^
>>>> Nov 14 16:36:27 ipfire dhcpd: Pool declarations must always contain at least
>>>> Nov 14 16:36:27 ipfire dhcpd: one range statement.
>>>> Nov 14 16:36:27 ipfire dhcpd: /etc/dhcp/dhcpd.conf line 30: Pool
>>>> declaration with no address range.
>>>> Nov 14 16:36:27 ipfire dhcpd: }
>>>> Nov 14 16:36:27 ipfire dhcpd: ^
>>>> Nov 14 16:36:27 ipfire dhcpd: Pool declarations must always contain at least
>>>> Nov 14 16:36:27 ipfire dhcpd: one range statement.
>>>> Nov 14 16:36:27 ipfire dhcpd: Configuration file errors encountered --
>>>> exiting
>>>> ...
>>>>
>>>> And...yes... [Hrm!]...I'm running 'dhcpd' on GREEN and BLUE with NO
>>>> address pools. Only fixed leases.
>>>>
>>>> Anything I can do to test this without address ranges?
>>>>
>>>> Best,
>>>> Matthias
>>>>
>>>> On 14.11.2020 13:29, Adolf Belka wrote:
>>>>> Hi all,
>>>>>
>>>>> I created a modified dhcp.cgi file for bug 10743. This gives the opportunity to add deny unknown-clients or deny known-clients to the dhcpd.conf file for the green and blue subnets.
>>>>>
>>>>> Unfortunately one of the bug originators has decided to move away from IPFire and will not carry out any testing of this modification to confirm it works before I create a patch and submit it.
>>>>>
>>>>> The modification provides a radio button set to green and blue that offers:-
>>>>>
>>>>> allow all clients
>>>>> deny unknown-clients
>>>>> deny known-clients
>>>>>
>>>>> The allow all clients option gives the same setup as currently and is the default setting for the radio button set.
>>>>>
>>>>> The modified dhcp.cgi file is attached. I would appreciate it if you could test this out and let me know if there are any unexpected outcomes.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Adolf.
>>>>>
>>>>
prev parent reply other threads:[~2020-11-18 11:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-14 12:29 Adolf Belka
2020-11-14 16:26 ` Matthias Fischer
2020-11-14 16:40 ` Adolf Belka
2020-11-14 22:13 ` Adolf Belka
2020-11-16 13:00 ` Aw: " Bernhard Bitsch
2020-11-16 13:14 ` Adolf Belka
2020-11-17 2:56 ` Tom Rymes
2020-11-18 11:39 ` Adolf Belka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77077ef2-fc9f-07a7-55b9-518fd7b78b1f@gmail.com \
--to=ahb.ipfire@gmail.com \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox