Re: [9fans] Missing ARP reply in 9load

Re: [9fans] Missing ARP reply in 9load

[Russ Cox]

9load is single threaded; responding to
ARP queries would be fairly difficult.
I did think we sent out an ARP broadcast
as soon as we got our BOOTP address though,
to initialize the caches of anyone who was
listening.

Re: [9fans] Missing ARP reply in 9load

[Boyd Roberts]

Russ Cox wrote:

> 9load is single threaded
so then 3rd ed has threads?  i remember (rob?) saying that plan 9
did not have threads because it was unecessary and beyond the 
capabilities of most programmers.  or am i confused?

writing code for windows is basically thread programming.  well,
it's event driven state stuff like X and that's why it's _extremely_
difficult to write a solid windows program.  and then there's the 
environment:

     CreateProcess() has 10 args, two of them structs.


--
Boyd Roberts                            boyd@psycho-basket-case.org

     ``I come over here to kill them cocksuckers, not work for 'em''

           -- Moon Dog, _Pettibone's Law_, John Keene

Re: [9fans] Missing ARP reply in 9load

[William K. Josephson]

On Wed, Jul 19, 2000 at 10:25:05PM +0200, Boyd Roberts wrote:

> > 9load is single threaded
> so then 3rd ed has threads?  i remember (rob?) saying that plan 9
> did not have threads because it was unecessary and beyond the 
> capabilities of most programmers.  or am i confused?

I think you have mis-remembered slightly:

>From: "rob pike" <rob@plan9.bell-labs.com>
>Subject: Re: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)
>Date: Mon, 8 May 2000 00:33:33 -0400
>To: 9fans@cse.psu.edu
>
>Alef was dropped because it was too laborious to maintain two compilers
>and sets of libraries across an ever-growing list of architectures.  The
>concurrent programming aspects of Alef were simulated by a new thread
>library for C, and that is what we use now.  The syntax isn't as pretty but
>the semantics is very close.
>
>-rob

Re: [9fans] Missing ARP reply in 9load

[presotto]

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

they aren't options 128 and 129, they're suboptions 128 and 129 in
the vendorinfo option, 0x2b (43).  I believe the correct ISC is:

	option-43 80:04:<4 bytes of fs addr>:81:04:<4 bytes of auth server addr>;

I'm assuming ISC will add the count to this.

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

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] Missing ARP reply in 9load
Date: Wed, 19 Jul 2000 14:09:17 +0200
Message-ID: <20000719140917.E3081@cackle.proxima.alt.za>

I had been wondering why the 2ed CPU server managed to load its
kernel over the wire when I ran the modified CMU BOOTPd, but not
when using ISC's DHCPd.

Ted Lemon evidently does not enter the ethernet information from the
DHCP requester in the ARP tables, as CMU BOOTPd does (and promptly
deletes, which I always thought a little suspicious).

Of course, I'm not running the most recent version of the DHCP server,
perhaps things have changed in the recent past, but I wonder if 9load
should not address this problem, and respond to ARP requests for its
freshly acquired IP address, irrespective.

I guess standards should be followed here, although I have never
really faced this problem, or seen an RFC addressing it.  I believe
one must allow for the possibility that the TFTP server is running
on a different host from the DHCP server, and could not conceivably
be expected to know the ethernet address of the TFTP client.

Russ?  I don't think I am as confortable with Plan 9 sources as to
undertake to fix this.

This for Rob Presotto, whom I remember frequenting the ISC DHCP
mailing list when I still did: I have

	option option-128 c0:60:20:86;
	option option-129 c0:60:20:85;

in dhcpd.conf and ISC DHCPd seems happy, but I still get prompted for
the address of the authenticator and file server once I've net booted
9pcdisk.gz and selected IL.

I think this ties up with Forsyth's comments about bootargs=, but I
thought one would avoid distributing information in plan9.ini files
wherever possible.  While asking, what maginc incantantion will
persuade a 3ed AUTH server to use itself rather than a third party?

++L

Re: [9fans] Missing ARP reply in 9load

[Lucio De Re]

On Wed, Jul 19, 2000 at 12:10:54PM -0400, presotto@plan9.bell-labs.com wrote:
> 
> they aren't options 128 and 129, they're suboptions 128 and 129 in
> the vendorinfo option, 0x2b (43).  I believe the correct ISC is:
> 
> 	option-43 80:04:<4 bytes of fs addr>:81:04:<4 bytes of auth server addr>;
> 
> I'm assuming ISC will add the count to this.

The format I got to work, eventually, is:

	option vendor-encapsulated-options 80:04:<4 bytes of fs addr>:81:04:<4 bytes of auth server addr>;

Thanks, Rob, for the help.

++L

Re: [9fans] Missing ARP reply in 9load

[Lucio De Re]

On Wed, Jul 19, 2000 at 02:01:16PM -0400, Steve Kotsopoulos wrote:
> 
> fyi, presotto@plan9.bell-labs.com is Dave Presotto
> rob@plan9.bell-labs.com is Rob Pike
> 
My apologies, I somehow got it into my head that Dave's name was also
Rob.  I have no idea where it came from and I am highly embarrassed
:-(

++L

[9fans] Missing ARP reply in 9load

[Lucio De Re]

I had been wondering why the 2ed CPU server managed to load its
kernel over the wire when I ran the modified CMU BOOTPd, but not
when using ISC's DHCPd.

Ted Lemon evidently does not enter the ethernet information from the
DHCP requester in the ARP tables, as CMU BOOTPd does (and promptly
deletes, which I always thought a little suspicious).

Of course, I'm not running the most recent version of the DHCP server,
perhaps things have changed in the recent past, but I wonder if 9load
should not address this problem, and respond to ARP requests for its
freshly acquired IP address, irrespective.

I guess standards should be followed here, although I have never
really faced this problem, or seen an RFC addressing it.  I believe
one must allow for the possibility that the TFTP server is running
on a different host from the DHCP server, and could not conceivably
be expected to know the ethernet address of the TFTP client.

Russ?  I don't think I am as confortable with Plan 9 sources as to
undertake to fix this.

This for Rob Presotto, whom I remember frequenting the ISC DHCP
mailing list when I still did: I have

	option option-128 c0:60:20:86;
	option option-129 c0:60:20:85;

in dhcpd.conf and ISC DHCPd seems happy, but I still get prompted for
the address of the authenticator and file server once I've net booted
9pcdisk.gz and selected IL.

I think this ties up with Forsyth's comments about bootargs=, but I
thought one would avoid distributing information in plan9.ini files
wherever possible.  While asking, what maginc incantantion will
persuade a 3ed AUTH server to use itself rather than a third party?

++L