Subject: Re: Cobalt kernel with ramdisk? (fwd)
To: None <email@example.com>
From: Andrew Gillham <firstname.lastname@example.org>
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! :-)
> 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 Gillham | NetBSD ist Affengeil.
email@example.com | Nachts ist es kaelter
I speak for myself, not for my employer. | als draussen.