Thank you for your reply. It was just really to make it like every other
router Iâve used. Itâs not a âproblemâ as such.
â
Alec Robertson
On 25 December 2016 at 11:03:35, Albert ARIBAUD (***@free.fr)
wrote:
(TL;DR: skip to last paragraph of my reply)
Hi Alec,
Le Sat, 24 Dec 2016 18:13:46 -0500
Post by Alec RobertsonI understand what youâre saying but I was suggesting this should be a
feature enhancement. All the other routers I have used work the way I
have described, be it NETGEAR, Asus, Huawei, etc.
Oh, ok. I was misled by the negative form in your message subject, which
I read as pointing a perceived misbehavior as opposed to suggesting a
new one.
So, have I got it right that your point can be summed up as follows:
"1. Right now, dnsmasq's DHCP server feature allocates IP based on
either one of the two following (summarized) strategies:
a) Select the IP based on a hash of the MAC, or
b) Select the oldest free IP available.
2. It is suggested to add a strategy which would be summarized as:
c) Select the lowest free IP."
If so, then I'm sorry about the misunderstanding: while I could have
helped on a perceived or real misbehavior diagnosis, I am not involved
in any part of developing dnsmasq so my feedback on a feature request
would be worthless.
However, I do have a question about this feature request; please bear
with me for a minute there.
I do understand that strategy c above is easily implemented (it's
basically a context-insensitive loop) as opposed to the other two, so
it makes sense to implement that when developing a DHCP server from
scratch, I do not see what benefit it brings to a DHCP server which
already has two allocation options in place. IOW, what does option c
bring that options a or b don't?
Obviously, option c reduces the number of different IPs allocated over
time with respect to option b, as option b goes through the whole
range while option does not. But then, option a also keeps the number
of allocated IPs to a minimum.
There is a difference, though, between options c and a: option c keeps
that minimum set of IPs tight, whereas option a (possibly) spreads the
set over the whole range.
So, the real distinguishing feature of option c is "keep the allocated
IPs as grouped near the range base as possible".
But that's a /characteristic/, not a /benefit/ -- at least, I cannot
see the benefit yet.
So I suspect there is something in the currently available options a
and b which causes an issue in your use of dnsmasq to the point of
making you want to see option c implemented.
Now, this something may actually be solved by implementing option c, or
it may be a symptom of another problem for which there is a better
solution than option c.
As I don't remember having seen a similar request (I might have missed
it, though), I suspect that it is not widely seen as a solution, which
makes me lean toward the "there is a better solution" side, but that's
only a hunch; hence my questioning, to either get rid of a false hunch,
or see it confirm and get to a better solution to your problem.
And for that, we need the problem laid out (as opposed to laying out the
perceived solution)
So the question becomes in fact why is a 'tight low range' IP
allocation strategy needed exactly, or more precisely, what is the
problem that you have which dnsmasq's existing IP allocation strategies
cause, or at least do not solve?
Amicalement,
--
Albert.