From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] OK, cpu server is up. In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-hpcguauhoxywxckozslbsibcqe" Date: Fri, 25 Apr 2003 11:10:40 -0400 Topicbox-Message-UUID: 99610766-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-hpcguauhoxywxckozslbsibcqe Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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. --upas-hpcguauhoxywxckozslbsibcqe Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Fri Apr 25 10:40:16 EDT 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Fri Apr 25 10:40:14 EDT 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 1726819B46; Fri, 25 Apr 2003 10:40:10 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id E2F6D19BA1 for <9fans@cse.psu.edu>; Fri, 25 Apr 2003 10:39:23 -0400 (EDT) Received: from ccs-mail.lanl.gov (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (8.12.9/8.12.9/(ccn-5)) with ESMTP id h3PEdNvE018199 for <9fans@cse.psu.edu>; Fri, 25 Apr 2003 08:39:23 -0600 Received: from maxroach.lanl.gov (maxroach.lanl.gov [128.165.250.187]) by ccs-mail.lanl.gov (8.12.9/8.12.9/(ccn-5)) with ESMTP id h3PEdNo5023184 for <9fans@cse.psu.edu>; Fri, 25 Apr 2003 08:39:23 -0600 From: ron minnich To: 9fans@cse.psu.edu Subject: Re: [9fans] OK, cpu server is up. In-Reply-To: <15c1d64edb07599e1ec4cb90cbbfdb68@caldo.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Fri, 25 Apr 2003 08:38:14 -0600 (MDT) 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 --upas-hpcguauhoxywxckozslbsibcqe--