Please take it to the debian-user list, and don't post the question repeatedly.
sathya sai wrote: > Hi, > > Can someone please help me out on this. > > Thanks and regards, > Sathya > > On Mon, Dec 21, 2009 at 8:09 PM, sathya sai > <[email protected]>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 >>> <[email protected]> >>> 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 <[email protected]> wrote: >>> >> >>> >> On Mon, Dec 21, 2009 at 9:03 PM, sathya sai < >>> [email protected]> >>> >> 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 >>> >> >> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
