From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rymes To: development@lists.ipfire.org Subject: Re: [PATCH] bug#10629: Prevent dynamic and fixed leases overlapping Date: Thu, 18 Feb 2021 11:05:32 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4186530660654054582==" List-Id: --===============4186530660654054582== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 18, 2021, at 10:29 AM, Bernhard Bitsch wr= ote: >=20 >> Gesendet: Donnerstag, 18. Februar 2021 um 16:18 Uhr >> Von: "Michael Tremer" >>=20 >>>> On 18 Feb 2021, at 14:01, Adolf Belka (ipfire-dev) wrote: >>>=20 >>> On 18/02/2021 14:06, Michael Tremer wrote: >>>=20 [snip] >>> The only thing that would be more difficult is if the user expands an exi= sting dynamic range that already overlaps with two fixed leases so that it no= w overlaps with four fixed leases. It will be difficult to determine which we= re the original existing and which are the new overlapped leases without havi= ng a parameter stored in a file that counts which leases were overlapping whe= n the Core Update upgrade is carried out. That could be done but I think the = simplest will be that any overlap due to a change in the dynamic range should= just get a warning and not an error. Does that sound okay. >>=20 >> Oh yeah, difficult question. >>=20 >> I did not assume that this was very dynamic before. >>=20 >> Potentially it is a good solution to simply split the pool in the backend = and not tell the user. So in the configuration instead of writing 192.168.0.1= 00-192.168.0.200, you would add a break for every static lease: >>=20 >> * 192.168.0.100 - 192.168.0.105 >> * 192.168.0.107 - 192.168.0.112 >> * 192.168.0.114 - 192.168.0.200 >>=20 >> In this example, 192.168.0.106 and 192.168.0.113 would be static leases. >>=20 >> That would make the solution transparent for the user, but a pain for the = developer. >>=20 >=20 > I do not think, that pools are right tool for the problem. Address pools ar= e used with a slight different semantic in dhcpd. This difference may increas= e in future. > Not mentioning the effort to split the set of possible IP addresses and to = verify this process. [snip] This was my original suggestion for how to handle this, and at the time I ope= ned the big, it was my understanding that this was the proper way to handle t= his. Others have arrived at a different conclusion, and to me it seems like m= ore of a style thing than a functional thing. Using multiple range definitions to exclude fixed addresses also has the bene= fit of allowing a user to keep a host=E2=80=99s address the same, which can b= e very helpful in instances where a lot of work may be required to change a h= ost=E2=80=99s IP. Tom --===============4186530660654054582==--