From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Jeff Sickel In-Reply-To: Date: Tue, 13 Mar 2012 10:04:48 -0500 Content-Transfer-Encoding: 7bit Message-Id: <92935DD0-93A5-4C1F-B69A-229DF176E036@corpus-callosum.com> References: <4bcaf3f315b12c3ac74aaa5b2c02cc2e@chula.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] pxeboot & tftpd Topicbox-Message-UUID: 67c3bb20-ead7-11e9-9d60-3106f5b1d025 Also note: Some old 9fans mails requested help solving DHCP errors showing up like: !Discover(hwa01_204e7f518eeb via 192.168.0.239): no binding :: 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. -jas On Mar 13, 2012, at 6:52 AM, Yaroslav wrote: > Yes, tftpd becomes none and calls newns(2), thus the only way to have > /net.alt populated for it is through /lib/namespace, as you figured > out. > -- > - Yaroslav > >