Hi, Can someone please help me out on this.
Thanks and regards, Sathya On Mon, Dec 21, 2009 at 8:09 PM, sathya sai <sathyasai.esh...@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.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 >> > >
