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
>
>
