public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Tom Rymes <trymes@rymes.com>
To: development@lists.ipfire.org
Subject: Re: Testing required for modified dhcp.cgi file related to bug 10743
Date: Mon, 16 Nov 2020 21:56:38 -0500	[thread overview]
Message-ID: <3b26cc1c-0213-0d10-589f-a7f0e0f7c1a5@rymes.com> (raw)
In-Reply-To: <012d97d2-056d-829f-c2dc-8a6b374ea657@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4782 bytes --]

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.
>>>>
>>>

  reply	other threads:[~2020-11-17  2:56 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 [this message]
2020-11-18 11:39         ` Adolf Belka

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=3b26cc1c-0213-0d10-589f-a7f0e0f7c1a5@rymes.com \
    --to=trymes@rymes.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