Re: Urgent: Query on dhclient in handling IP conflict

On Mon, Dec 21, 2009 at 8:09 PM, sathya sai <sathyasai.eshwar@gmail.com> wrote:

Hi Matt,

Thanks for your mail.

I had already thought on these possiblities. But the problem here is, we dont have control over neither our DHCP server (it can be either Windows or Linux based servers) nor the client PC which configures static IP (anybody in the subnet can configure the IPs on their wish). I hope, this is true with the real time deployment scenario.

Considering all these scenario, I felt that it would be better for our dhclient to do a ARP broadcast as per RFC 2131 to detect the IP conflict and send DHCPDECLINE in case of it. So that the DHCP server can understand the existance of duplicate address and respond with the newer address accordingly.

Could please let me know your thoughts on this, so that we can make your dhclient much more better on this.

Thanks and regards,
Sathya

On Mon, Dec 21, 2009 at 7:22 PM, Mathieu Trudel-Lapierre <mathieu.tl@gmail.com> wrote:

On Mon, Dec 21, 2009 at 8:22 AM, sathya sai <sathyasai.eshwar@gmail.com> wrote:
> Hi Paul,
>
> I hope, this is a common problem with the dhclient which would occur even
> on debian lenny.
>
> Thanks and regards,
> Sathya
>
> On Mon, Dec 21, 2009 at 6:47 PM, Paul Wise <pabs@debian.org> wrote:
>>
>> On Mon, Dec 21, 2009 at 9:03 PM, sathya sai <sathyasai.eshwar@gmail.com>
>> wrote:
>>
>> > Could you please help me out by directing this query to the appropriate
>> > forum.
>>
>> debian-user would be the appropriate forum.
>>
>> Please note that Debian etch is very old and will soon lose security
>> support. You should really upgrade to Debian lenny at your earliest
>> convenience. I'd suggest testing for the bug on both lenny and the
>> in-development release, squeeze.
>>

Without wanting to diminish what you've done (which certainly aims at
resolving a particular issue you might have been seeing), I think
there would be more elegant solutions to your problem than IP conflict
detection (although it could be nice to have, it would probably be
more effectively reported upstream).

TL;DR: There is another way to avoid conflicts without requiring *any*
development on dhcp3-server or dhcp3-client. You can use reservations
or change the IP pool range to resolve this issue.

Longer version:

What I'd do in this case is either of two solutions:

1- Rather simply, and to retain most of what has been done already;
change the DHCP range of IP addresses given out to "dynamic" clients
to something that doesn't contain the IP of the machines that are
statically assigned.

For example, set aside 2-31 for statically assigned systems, then
32-254 for dynamic assignment.

2- Slightly change the setup: have all the systems get an IP from
DHCP, but make sure that the IPs given out to the machines that should
be statically assigned are always the same. You can do this easily
using reservations, which is a matter of matching an IP to a
particular MAC address. In dnsmasq, that's done with /etc/ethers. In
dhcpd, it's done in dhcpd.conf in a special stanza.

Both these options address the same issue: systems will no longer be
assigned conflicting IP addresses. Additionally, there are some pretty
nifty things you could do with option 2 from then on, such as
dynamically building DNS information from the DHCP leases. Your
"servers" which as assigned the same IP all the time are always there,
and names of the "clients" (which could be new systems added from
visitors or whatever), could "publish" their desired name through DHCP
and have this information visible in DNS requests (just as you could
also do reverse DNS).

Sorry if this is rather verbose, just expressing a different way of
solving the situation.

With kind regards,

/ Matt