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 (albert.arib...@free.fr) wrote: (TL;DR: skip to last paragraph of my reply) Hi Alec, Le Sat, 24 Dec 2016 18:13:46 -0500 Alec Robertson <alecrobertso...@gmail.com> a écrit: > I 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.
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss