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.esh...@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 <p...@debian.org> wrote: > >> > >> On Mon, Dec 21, 2009 at 9:03 PM, sathya sai <sathyasai.esh...@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 >
