From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 13 Mar 2012 11:10:56 -0400 To: jas@corpus-callosum.com, 9fans@9fans.net Message-ID: In-Reply-To: <92935DD0-93A5-4C1F-B69A-229DF176E036@corpus-callosum.com> References: <4bcaf3f315b12c3ac74aaa5b2c02cc2e@chula.quanstro.net> <92935DD0-93A5-4C1F-B69A-229DF176E036@corpus-callosum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] pxeboot & tftpd Topicbox-Message-UUID: 67c8271e-ead7-11e9-9d60-3106f5b1d025 > I don't think there was a concise description of what the solution was > in the prior threads. Here's a small attempt: > > The DHCP discovery error occurs because dhcpd will only only provide > an IP address on the subnet for the inquiry. In this case a device > defaults to ip=192.168.0.239 ipmask=255.255.0.0 when in discovery mode. > The device may have broadcast a src=0.0.0.0, but you'll probably find > that your ipboot logs never show it. > > Given that the broadcast subnet mask is 255.255.0.0, you'll need to > have an entry in your ndb local/external/etc file that can resolve > the inquiry like > > ipnet=catch-net ip=192.168.0.0 ipmask=255.255.0.0 > > or some higher level network. Doing so will allow dhcpd to respond > and not flood ipboot with failed discovery messages. > > I've only seen this kind of behavior from certain devices (e.g. routers) > that force a default ip&mask so they can be configured by an end user. > You'd think that with tools like cec(8) and zeroconf available there > would be a better solution for discovering and initializing a device. this is a feature, not a bug. this is in case you have an unsegmented physical network with two ip networks, and two dhcp servers. along these lines, ... at coraid, we migrated internal networks with an overlay network. this required changing dhcpd to answer questions for *any* network connected. in our case we had two addresses on ether0, and with our small change to dhcp, we served 'em both up. - erik