Date: Mon, 6 Feb 2006 14:53:10 -0800 From: "David W. Hankins" <David_Hankins@isc.org> To: freebsd-stable@freebsd.org Subject: Re: dhclient in 6.0 Message-ID: <20060206225310.GA16149@isc.org> In-Reply-To: <43E44BAD.50601@mac.com> References: <20060203124325.5f512537.lists@yazzy.org> <57854.24.90.33.115.1138967941.squirrel@mail.el.net> <d8a4930a0602030429q50f6aa39o@mail.gmail.com> <54176.24.90.33.115.1138971301.squirrel@mail.el.net> <20060203130241.GJ44469@pegasus.dyndns.info> <c7aff4ef0602030524y3a2632d3w@mail.gmail.com> <60155.24.90.33.115.1138981486.squirrel@mail.el.net> <61418.24.90.33.115.1139004207.squirrel@mail.el.net> <20060204005501.GD7613@isc.org> <43E44BAD.50601@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 04, 2006 at 01:37:33AM -0500, Chuck Swiger wrote: > Howdy. Do you have a computer named HAL, by any chance? :-) No, but I do have one named 'goliath'. > OK, cool. Are you doing anything with regard to Zeroconf/Rendezvous? Not really, no, except when DHCP options appear to turn off IPv4LL, or that sort of thing. What did you have in mind? > would be nice if dhcpd would never get confused by it's own /var/db/dhcpd= =2Eleases > file. I don't get useful diagnostics when this happens, but every once i= n a > blue moon dhcpd will no longer hand out leases until I delete the leases = file > and restart it. =46rom this description it's hard to say what's happening. From your second descriptoin, I think it's pretty obvious you have a rogue client that's eating up your free leases. This actually is a well understood DHCP protocol D.O.S. There's not a lot that a DHCP server can do to withstand this kind of lease-starvation environment without causing protocol breakage in other areas. So the best practice is to keep track of your count of free leases, to make sure there are always enough. > It would also be good if dhcpd would reassign the same IP to the same mac= hine > (if the IP is not otherwise being used) if there was a prior lease matchi= ng the > client asking for a new lease, and not just when a client is trying to re= new an > existing lease. dhcpd tries hard - very hard - to find a lease to assign to the client it most recently was bound to. If you're having machines get new leases when they already had others in use, there are a small number of possible problem sets that describe this; 1a) The client is changing its identity every time. The server chooses the oldest free lease (the lease whose client has not returned in the longest span of time) to offer the client. Workaround: Kill the client's owner. 1b) The client is a PXE booting Windows system. PXE identifies itself to the server with no client identifier - the server identifies this by the hardware address uniquely. The Windows dhcp client uses a client identifier. dhcpd treats these as two discrete clients, so each gets their own lease. But, if it were this, you would know it because Windows' PXE environment that does the extra DHCP requests with the client identifier can't change the IP addressing at that point - so it reboots and tries again. So you'd know it if it were this because the client would never boot. 2) The client returns to an odd form of "INIT/BOUND" when it decides to renew its lease. dhcpd sends an ICMP echo request when a client is sensed to be in the INIT state - since the client is bound, this echo request succeeds, and the lease is marked 'ABANDONED' to avoid duplicate allocations (the server has falsely discovered a conflict). Workaround: disable ping-check. We're also looking at better ways to get around this, changing ping-check behaviour in a future release. 3) The client is RAS, and you don't have enough leases to sate its appetite for "stand-by addresses". Workaround: configure dhcpd to refuse to allocate leases to RAS. Search ISC's dhcp-server mailing list archives for example configs. If the above doesn't solve your problem I'd recommend digging up syslogs and dhcpd.leases contents and emailing dhcp-server@isc.org. > Please use snprintf() and not sprintf() whenever you're dealing with any = data > which is not known to be static and compiled in; using sprintf() on data = =66rom > the network is simply unwise. (Why yes, I happen to trust the security o= f the > OpenBSD code quite a bit more than the ISC code I've seen. People writin= g code > which runs as root should take great pains to avoid code patterns which c= ould > ever be exploitable.) Already done. Up until my tenure at ISC, in and around 3.0.1RC14 engineering, some includes/cf/* (system-local includes such as freebsd.h etc) used: #define vsnprintf(buf, size, fmt, list) vsprintf (buf, fmt, list) And a stub snprintf() that calls vsnprintf() within the sources. So astounding is this, when I encountered the problem in snprintf() overflowing the buffer it was given, my immediate reaction was "libc bug." It was more believable to me that someone optimized-out the bounds check than that our code #defined it away. Because really, who would do a thing like that? What a rude awakening that was. As far as I am aware, from my recent audits of the software, there do not currently exist any unbounded buffer utilizations. sprintf() is used, frequently, but it is gauged in each event as impossible to overflow (even if the contents of the arguments are maligned). The company line on this is that it must be "auditable within (n) lines of where it is used." Where (n) is derived from average employee edit buffer screen sizes. It is also the case that where snprintf() is used today, it results in truncated log lines (a matter of some controversy within ISC as to wether this should be allowed or not), but if and when used outside of logging format strings, an error is always asserted, and either an all-stop in the case where strings are not network-supplied, or the client is at least not replied to. This latter bit - what to do when it truncation ocurrs - is often ignored by the "strncpy/snprintf always!" school of thinking. Not overrunning buffer is good - not overrunning buffer and producing invalid protocol as a consequence is bad. What to do in these cases is pretty controversial. There's a substantive movement out there to never utilize the non-bounds-checking versions of these functions. ISC's position is to utilize these functions, but only when it's provably secure just by looking at it (not by digging into headers). > (Why yes, I happen to trust the security of the > OpenBSD code quite a bit more than the ISC code I've seen. Having been forced to debug much of ISC DHCP's code, I can appreciate that sentiment. My hands are somewhat tied in how much I can change how quickly while we're stuck in maintenance releases. > People writing code > which runs as root should take great pains to avoid code patterns which c= ould > ever be exploitable.) One of the other changes in regime that ISC's software engineering has brought to the ISC DHCP package is formal release engineering process. Something, I detect, the package was lacking in the years prior. Today, no change to source ever reaches release branches unless it undergoes peer review. This started happening upon the final release of 3.0.1. > One of the differences between the Linux folks and the locals on most BSD= forums > is a lack of platform-driven advocacy, although no doubt some people are > exceptions to that generalization. If you've found a platform that suits= you > well, by all means, enjoy it. I have no such compulsions. I use what my customers use to serve them with smoother transitions. > I try to make sure my code goes under FreeBSD, NetBSD, MacOSX/Darwin, Sol= aris, > Red Hat, and SuSE (not necessarily in that order), although I don't parti= cularly > view it as writing code for those platforms so much as making sure I don'= t write > platform-specific code except when I really have to. This thinking is dangerous. "The code is portable, your system is the problem" is the disease that sometimes precipitates. Only sometimes, mind you. Ironically, ISC DHCP was built from this mindset, from what I read. The result is not very portable, and people trying to make it so create static machinations of #ifdef'ery that ultimately collapse the entire package into an obscure singularity. The autoconf approach is the correct one, but this doesn't find these "niggling details" until they hit someone square in the jaw, after release...it just makes it easier to mop up the blood afterward. > I'd be happy to give you some feedback about the DHCP software, although = the > notion of doing things specificly for FreeBSD rather than for all the pla= tforms > one cares about strikes me as a bit odd. The environment in which it will be invoked (/etc/sysconfig in FreeBSD?), how and what the client should offer in terms of command, are important facets to industrial design of a product. I suppose I could be equally indifferent to everyone and produce a product that does not work well really anywhere at all. > > Up until this, to me, unusual news, I had been planning the future > > without FreeBSD in the picture at all. > >=20 > > It's surprising to me to think that someone still uses our client > > software on that platform. >=20 > Surprises often happen when one chooses not to pay attention. I see. I should be reading freebsd-arch, freebsd-net (which I was on), freebsd-stable, and freebsd-current, just to make sure I catch everything ISC-DHCP related. To be fair, I would then also have to monitor linux & the others approximations of each of these lists, for each of the distributions, and the meta-lists. Within all of this, when a "hit" is found for ISC DHCP within one of these lists, I would have to spend the time to differentiate between problems introduced by local features or alterations made in each of these operating systems (example: the ports patches set), and those within our software release. "The mountain must come to Mohammed." As it is, this single message from you, clearly on topic and easy to mark out, had to wait on the "Hankins queue" for six hours since I arrived at work this morning before I even started contemplating your statements. Perhaps if I had a staff of five, I would consider this option... building my own spy network to keep abreast of FreeBSD goings on. As yet, donators advocating ISC DHCP within open source operating systems have yet to provide that level of support. And honestly, if they did, I think I'd rather have five programmers than five mailing list filters. Instead, I build working relationships with contacts at each of these littany of environments, and try my best to be responsive and helpful when they throw items on their desk they need help with at us (or throw their users at our mailing lists). I return the favor as often as I am able - directing users with distribution-specific problems to those chains of support. I find this to be the only functional approach, the only approach that doesn't bury me in text. > FWIW, most people using FreeBSD are using the ISC version of DHCP, simply > because that is what came with FreeBSD-4.x and 5.x, along with some peopl= e who I'm aware of this. > are using ISC DHCP under 6.0 as well. That's what surprises me. > Either you choose to subscribe to the BSD mailing lists, or review the bug > database for PR's every once in a while, or perhaps even act as the maint= ainer > of the ISC DHCP port, or you choose not to do so. This is a case of black and white thinking. Why would I have entertained any of these options when I already had a great working relationship with Martin, and was being kept abreast of everything that hit his desk that also needed to hit mine? Why take custody of the DHCP (or BIND or INN or NTP) ports, when the existing maintainers are doing an admirable job, and this gives us more time to devote to development? Other than slimy marketing reasons, I mean. It is not a black and white choice. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD59NWcXeLeWu2vmoRAoVVAKCGBcfWrHdc7Rg4RReCoWFA8184OACgv046 Bz1ujOTmB+synAIJDsER93M= =Uva4 -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060206225310.GA16149>