[9fans] pxeboot & tftpd

[9fans] pxeboot & tftpd

[Jeff Sickel]

I've been taking the time to finally setup pxeboot for a few new projects.  Oddly, or maybe not, I'm wanting to run dhcpd and tftpd on /net.alt instead of /net.  Doing so highlights a subtle point that I've clearly missed in the whole namespace documentation and network configuration.

ip/dhcpd -x /net.alt works perfectly well but ip/tftpd -x /net.alt will fail unless you've got a custom /lib/namespace  or /cfg/$sysname/namespace that includes something similar to the following:

# alt networks
bind -b '#l1' /net.alt
bind -b '#I1' /net.alt
mount -a /srv/cs_net.alt /net.alt
mount -a /srv/dns_net.alt /net.alt


There may a better way, but so far that's the only thing I've found to make tftpd work off of /net.alt.

-jas

Re: [9fans] pxeboot & tftpd

[erik quanstrom]

> ip/dhcpd -x /net.alt works perfectly well but ip/tftpd -x /net.alt will fail unless you've got a custom /lib/namespace  or /cfg/$sysname/namespace that includes something similar to the following:
>
> # alt networks
> bind -b '#l1' /net.alt
> bind -b '#I1' /net.alt
> mount -a /srv/cs_net.alt /net.alt
> mount -a /srv/dns_net.alt /net.alt
>
>
> There may a better way, but so far that's the only thing I've found to make tftpd work off of /net.alt.

that's pretty much the standard way of doing things.

is there any reason you wouldn't want the namespace
on a machine using net.alt *not* to include those
binds and mounts?

- erik

Re: [9fans] pxeboot & tftpd

[Yaroslav]

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

Re: [9fans] pxeboot & tftpd

[Jeff Sickel]

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

Re: [9fans] pxeboot & tftpd

[erik quanstrom]

> 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