Re: [9fans] OK, cpu server is up.

[David Presotto <presotto@closedmind.org>]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

yes, dhcpd makes the entry.

Its not intentional security thing just 9load being minimal.  However,
over the years, 9load has become so friggin big that I might as well
put ARP into it too, it'ld hardly be noticable.

Dhcpd loading the arp cache is just there because it has to be.
Otherwise the responses might not work.  That's because if the
broadcast flag isn't set in the client requests, replies are
unicast.  If the reply is unicast, the server has to ARP to get
the clients ether address.  Since the client hasn't gotten its
address yet, it can't answer the ARP...

Of course, once 9load gets an address, it should be ready to
answer ARPs.  That way we could separate the dhcp server and
tftp server.  On my infinite list.

[-- Attachment #2: Type: message/rfc822, Size: 2291 bytes --]

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] OK, cpu server is up.
Date: Fri, 25 Apr 2003 08:38:14 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0304250836140.8939-100000@maxroach.lanl.gov>

On Fri, 25 Apr 2003, Charles Forsyth wrote:

> dhcpd makes an arp entry which is what probably allows
> it to work: tftpd ends up using that entry and 9load is never asked.

Did you verify that dhcpd makes that arp entry? I had made that
assumption.

It's an interesting way of ensuring that if someone talks to your dhcpd,
they can only talk to your machine from that point on. Is this an
intentional security thing, I wonder.

Or is it due to the fact that somebody once had a building of diskless Sun
nodes and one day had 50 or 100 of them home to the wrong bootp server
(happened to me once ...)

ron