Subject: Re: Cobalt kernel with ramdisk? (fwd)
To: None <thorpej@zembu.com>
From: Andrew Gillham <gillhaa@ghost.whirlpool.com>
List: tech-net
Date: 04/06/2000 00:23:15
Jason R Thorpe writes:
> 
> Sorry it's taken me a couple of days to get back to you... This week has
> been a little hectic (already! :-)

No problem.  

> So, the whole point of SO_DONTROUTE is to send it to the "right network"
> immediately.  It's *intended* that the packet not be forwarded.  That is
> why the TTL gets set to 1; it guarantees that an IP gateway will not
> forward the packet to another network.  If the network specified in the
> destination address is not directly attached to the machine, the
> transmission fails.

Right, I understand this in the "normal" case.  My question was related
to the BOOTP/DHCP case.

> Perhaps I'm missing something in your configuration, here (since I didn't
> see any of the messages on this thread until this one was forwarded to me),
> but if your DHCP server is on the same IP subnet as your DHCP client, all
> should be fine.  If you need to forward the request to a DHCP server on
> another IP subnet, use a DHCP gateway program.  NetBSD includes both a
> DHCP relay (dhcrelay) and a BOOTP relay (bootpgw).

Yup, and bootpgw actually works.  The "problem" I have with this is that
my Cisco is configured with "ip helper-address x.x.x.x", yet won't
forward a TTL=1 DHCP packet. (or at least the one generated by the kernel)

So is NetBSD "doing the right thing" here, or not?  Using tcpdump on my
i386-current (1.4W) box, the TTL on a DHCP packet appears to be 16.
In src/usr.sbin/dhcp/common/packet.c ip_ttl is set to 16 explicitly.
So, I guess the "bug" is that a machine is fully able to DHCP via dhclient,
but the same machine can't NFS boot via DHCP because of the TTL.

I think this is a bug.

> If you think about it, it would be quite a goof to blindly forward
> a packet from 0.0.0.0 to 255.255.255.255 to another IP subnet.  And
> I would say that the Linux-based firmware on the Cobalt is QUITE WRONG
> to tell the IP gateway on the network that doing so would be Just Fine.

Hmm, I agree that blindly forwarding 255.255.255.255 broadcasts is bad,
but most systems have to be forced to do it. :-)

Seriously though, there appears to be a "mismatch" between what dhclient
does and what nfs_bootdhcp.c does.

-Andrew
-- 
-----------------------------------------------------------------
Andrew Gillham                            | NetBSD ist Affengeil.
gillham@whirlpool.com                     | Nachts ist es kaelter
I speak for myself, not for my employer.  | als draussen.