🚀 go-pugleaf

From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Fri, 12 Jul 91 10:28:08 EST
Subject: Re: Flat ampr.org

> But do note that I was talking about how the _rest_ of the  
> _internet_, not the ham network, will deal with routing to us....
> 
> You were clear only insofar as you want to take care of ham-to-ham  
> routing.
Ta!
Legally, the Internet _cannot_ route to us, or do anything with us, unless
the administrators/users of every Internet site get an amateur licence.
Surely they would only want to route to us if they needed that route
for something.

As 44.x.x.x sites, we must ensure that anything we pass on must originate
from an amateur. This excludes the Internet.

Wrt the Internet/44.x.x.x gateways, they are in a tricky situation which
needs a lot of thought. Fortunately the ipip & axip encapsulation effectively
hide the Internet from the ham sites, and make it appear as a link layer
like AX.25.

And vice versa, because `normal' Internet sites currently don't know how
to route to any 44.x.x.x sites, we can ensure non-amateurs cannot bypass
the brickwall of the gateways *. I want it kept that way.

* except by SMTP. Solution, don't run SMTP on the gateways. Tony ah6bw
thought having gateways running SMTP would allow hams on the Internet to
use the gateways. But we have no guarantee that Joe Random Internet user
is an amateur.

Final thought, and if you're a pessimist, skip this paragraph. How similar
are all packet operators' licenses? Here in Oz, any license allows you
packet operation, but with my license level I might not be able to transmit
packet in another country. However, with these gateways I might be able to
do just that. Time to bury my head in the sand.....
[ Imagine a gateway in country X transmitting on 10m. I'm not allowed to
  do that. ]

Bye all,
	Warren vk1xwt


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Thu, 11 Jul 91 23:30:43 EDT
Subject: TMP File fix OK


I have implemented Mike W's TMP file fix into PA0GRI NOS 0618 1.7 and
it works fine. Also caught the Watch Dog problem.

Mike may be able to explain this better but Rob's suggestion to
comment out the two functions and let it default to Borland code
is a BUST! Apparently NOS must do it's own internal directory 
change?? Anyhow within a few hours I had 150 openned TMPxx.$$$
files in my directory. Unless I am wrong based on this it is an
absolute requirement to use NOS code to create TMP files as opposed
to Borland code - that is unless you want abandoned TMP files left
all over your disk!

Thanks for the fix(es) Mike. Hopefully Borland will make this TMP
file stuff more robust someday soon. 

Gerrard please include Mike's code in your version. Also please add
a config.h define for 'axip'. No need having it in there for general
users who would never use it.

Doug


----
From: landont@lafsun.lafayette.edu (Trevor Landon)
Date: Thu, 11 Jul 91 17:21:26 EDT
Subject: 

Hello,
   I have two questions to ask the group...

1)  Is there differences in the way that different versions of ka9q
handle a packet driver?  I can run the generic Phil Karn version
(910614) without any problems, but when I try to use either paogri 1.6h
or g1emm 1.6 I have problems.  I seems like the nos quits listening
to the packet driver after about 5 minutes...  Do you know why this is
happening?

2)  What is the propper method to set up the netmask and broadcast?
We are running a class b network.  The following is a copy of how
one of our suns is configured...

le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
	inet 139.147.8.7 netmask ffffff00 broadcast 139.147.8.0
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000

But when I tried configuring the nos like that nothing worked.  The
following is a copy of how our netmask is setup now, but I am sure that
there is a problem with it.  It still quits listening after a while.

Net> ifconfig
tr         IP addr 139.147.24.3 MTU 1500 Link encap Ethernet
           Link addr 10:00:5a:31:b9:32
           flags 0 trace 0x0 netmask 0x0000ff00 broadcast 0.0.24.0
           sent: ip 159 tot 159 idle 0:00:00:52
           recv: ip 124 tot 6147 idle 0:00:00:01
loopback   IP addr 127.0.0.1 MTU 65535 Link encap None
           flags 0 trace 0x0 netmask 0xffffffff broadcast 255.255.255.255
           sent: ip 154 tot 154 idle 0:00:00:00
           recv: ip 154 tot 154 idle 0:00:00:00
encap      IP addr 0.0.0.0 MTU 65535 Link encap None
           flags 0 trace 0x0 netmask 0xffffffff broadcast 255.255.255.255
           sent: ip 0 tot 0 idle 0:03:09:59
           recv: ip 0 tot 0 idle 0:03:09:59


Any suggestions would helpfull.

Thank-you,
Trevor
landont@lafsun.lafayette.edu


----
From: Jay Maynard <S0JM@ADMIN.HSC.UTH.TMC.EDU>
Date:  Thu, 11 Jul 91 16:55 CDT
Subject: Re: Stabilizing NOS!

> I have been thinking about the glue which would allow multiple
> copies of NOS running on ONE machine under DV to talk to each other.
> This could be done through the DV mailboxes, I believe. This might
> allow several cut down versions of NOS to exist on one machine which
> couldn't support all the options at once. Maybe one copy could be pretty
> much dedicated to being a domain server, others handling POP etc etc ..

Hm. Do you envision having multiple virtual machines, each with a specific
IP address, each doing one (or a limited number of) function(s), or would
only one be visible to the outside world?

I was thinking more along the lines of rewriting the socket code in terms
of DV's IPC facilities (mailboxes, semaphores, ???) and running only one
copy of the protocol stack; this simplifies the clients to being simple,
single-tasking kinds of things (though not the servers). Am I off base here?
In particular, am I oversimplifying the task?

...Jay


----
From: andyw@aspen.cray.com (Andy Warner)
Date: Thu, 11 Jul 91 16:46:22 CDT
Subject: Re: Stabilizing NOS!

Jay writes:
> I'm not sure we can kill both birds with one stone, but maybe we can kill
> one and injure one...I've been mulling the possibilities of a Desqview-
> specific version of NOS. There's a freely-available DV interface library
> available (I think from wuarchive.wustl.edu, but don't hold me to that),
> and that might allow having the clients and servers split out from the NOS
> kernel and protocol code, and run in separate DV tasks - thus, on a machine
> with either LIM 4.0 hardware or a 386, allowing separate address spaces for
> each one. I haven't done anything about this yet, mainly because I haven't
> had much opportunity to play with it, but also from a lack of an idea where
> to start on such a breakup. Anyone else out there thought about something
> like this?
> 
> ...Jay, K5ZC

I have been thinking about the glue which would allow multiple
copies of NOS running on ONE machine under DV to talk to each other.
This could be done through the DV mailboxes, I believe. This might
allow several cut down versions of NOS to exist on one machine which
couldn't support all the options at once. Maybe one copy could be pretty
much dedicated to being a domain server, others handling POP etc etc ..

Now the gotcha - I don't have DesqView on my PC at home, I've never
worked with DesqView's mailboxes & I don't really have the time, but
none of these things invalidate the idea..

-- 
andyw.	(W0/G1XRL)

andyw@aspen.cray.com	Andy Warner, Cray Research, Inc.	(612) 683-5835


----
From: brian@ucsd.edu (Brian Kantor)
Date: Thu, 11 Jul 91 13:49:33 -0700
Subject: Stop This! (ITZOK@DAMA)

Will whoever is relaying tcp-group to itzok@dama PLEASE STOP!!!?!?!?!?!?!
That destination is NOT on the UCSD mailing list so I can't delete it,
and I got seventy-four copies of this message this morning:

>From @CUNYVM.CUNY.EDU:postmaster@yubgef51.bitnet Thu Jul 11 13:32:12 1991
>Received: from cunyvm.cuny.edu by ucsd.edu; id AA25621
>	sendmail 5.64/UCSD-2.1-sun via SMTP
>	Thu, 11 Jul 91 12:48:26 -0700
>Received: from yubgef51.bitnet by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9176; Thu, 11 Jul 91 15:46:23 EDT
>Date: Thu, 11 Jul 1991 13:53 +0200
>From: PMDF Mail Server <Postmaster%yubgef51.bitnet@CUNYVM.CUNY.EDU>
>Subject: Undeliverable mail: temporarily unable to deliver
>To: tcp-group-relay@ucsd.edu
>Message-Id: <0F20565BA0002550@yubgef51.bitnet>
>X-Envelope-To: tcp-group-relay@ucsd.edu
>Status: R
>
>Your message could not be delivered to:
>
>    iztok%dama
>
>Your message has been enqueued and undeliverable for 6 days.
>The mail system will continue to try to deliver your message
>for an additional 6 days.
>
>The beginning of your message follows:
>
>Received: from PUCC.PRINCETON.EDU (VMMAIL@PUCC) by yubgef51.bitnet with
> PMDF#10165; Fri, 5 Jul 1991 10:27 +0200
>Received: from PUCC by PUCC.PRINCETON.EDU (Mailer R2.08 R208004) with BSMTP id
> 1093; Fri, 05 Jul 91 00:32:43 EDT
>Received: from ucsd.edu by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with TCP;
> Fri, 05 Jul 91 00:32:41 EDT
>Received: by ucsd.edu; id AA28167 sendmail 5.64/UCSD-2.1-sun Thu, 4 Jul 91
> 19:17:23 -0700 for dave
>Received: from cunyvm.cuny.edu by ucsd.edu; id AA28160 sendmail
> 5.64/UCSD-2.1-sun via SMTP Thu, 4 Jul 91 19:17:19 -0700 for
> /usr/mail/listhandler tcp-group
>Received: from ESOC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP
> id 9746; Thu, 04 Jul 91 22:17:06 EDT
>Received: from ESOC (BTITMARS) by ESOC.BITNET (Mailer R2.07) with BSMTP id
> 5755; Fri, 05 Jul 91 04:17:30 CET
>Date: Fri, 05 Jul 91 04:10:13 CET
>From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@CUNYVM.CUNY.EDU>
>Subject: New WNOS Version 2.B
>To: tcp-group@ucsd.edu
>Errors-to: tcp-group-relay@ucsd.edu
>Message-id: <9107050217.AA28160@ucsd.edu>
>X-Envelope-to: iztok%dama
>Precedence: junk
>Organization: European Space Agency


----
From: "John R. Ackermann" <jra@lawday.daytonoh.ncr.com>
Date: Thu, 11 Jul 91 13:47:40 EDT
Subject: RE: Stabilizing NOS!

> 
> Since I was specifically mentioned on this one, I think I should say
> something.  I cannot agree that it is proper to "stabilize" NOS at the
> source level by stripping things out of it.  I am currently maintaining
> two versions which are in distribution in New England, and these are
> made from the same source except for the CONFIG.H file.  If you want a
> version on NOS with a, b, and c, but not with x, y, and z, then the
> CONFIG.H file lets you do this with compile-time defines and undefines.
> 

If you're suggesting that we build a standard NOS out of the current
source base, I agree -- as long as we use a snapshot that's stable and
has all the bugs worked out of it.  (I don't think the user community
can cope with more than about two updates per year).

But if everyone who wants to run NOS needs a) to know all about the
various experimental parts of the code (so they can figure out what to
leave out) and b) needs to build their own executable (or rely on some
local idea of a "standard" version), NOS is never going to make it into
the mainstream.  This ain't unix... C compilers don't come built into
the system. 

Don't get me wrong... I'm <not> against all the goodies that are
being added to NOS.  But my perception is that most of them do not need
to be in the version that Joe Ham is running.  If he has a stable
program that's well enough documented to actually let him install and
use it himself, he can take advantage of the various gateways and
servers that are being added to the full-blown version of the code.

John  AG9V


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Fri, 12 Jul 91 00:08:13 EDT
Subject: Ops - TMP File


I may have spoken to soon onthe fact that Mike's fix was working.
It seems to work fine with this test - 

With Enviroment - SET TMP=c:\tmp

With NOS in  /TMP directory do a dir - 
leave display (F10) and do a cd to another directory - 
do another dir etc. etc.

Files close fine. Tmp files are only found and close in defined
TMP directory.

NOW the problem. I have a large mailist. About 20 expansions in alias
file.

When I send mail using external BM - 'm' at NOS prompt - and then
quit back to NOS. The system churns for a few minutes and starts
sending mail - much of which is deposited in my own /spool/mail
for POP pickup. 

After this I have a trail of openned files in my /tmp directory.
Also after each POP to my system the TMP files grow. This is with
NO cd command. The system is in the /tmp directory.

Either I did something wrong OR...  - I followed Mike's message
and had no compile errors. Just went over it again - Yes it was
the corrected one. The first test (above first para.) should be
a good test for this should it not? And also confirm that it indeed
is compiled in.

Is it possible that Gerrard made some change in 0618 1.7? Is the
fix based on this version?

Doug


----
From: Bdale Garbee <bdale@col.hp.com>
Date: Thu, 11 Jul 91 21:19:16 MDT
Subject: Re: Flat ampr.org

> As 44.x.x.x sites, we must ensure that anything we pass on must originate
> from an amateur. This excludes the Internet.

Not in the US.  The FCC rules state (plus or minus the ruckus surrounding the
1-900 phone number fiasco) that the responsibility for the content of traffic
on the amateur packet network lies with the station that originally enters
said traffic into the amateur packet system.  Most messages from a non-ham to
a ham that originate on Internet and are gatewayed to packet are perfectly OK,
as long as the gateway operator screens for inappropriate content before 
allowing the message to flow through the gateway.

If the gateway operator chooses not to screen the content, that's OK too as 
long as nothing inappropriate goes through the gateway, and is intercepted
by the FCC.  (read into this statement whatever connotations you prefer)

> Final thought, and if you're a pessimist, skip this paragraph. How similar
> are all packet operators' licenses? Here in Oz, any license allows you
> packet operation, but with my license level I might not be able to transmit
> packet in another country.

I don't consider this a problem, either.  If I run a gateway that allows you 
to put mail on the air in the US, such that I am the station injecting the
traffic into the amateur packet network, my neck is on the block if I pass
something "inappropriate" to the amateur service. 

Bdale


----
From: andyw@aspen.cray.com (Andy Warner)
Date: Thu, 11 Jul 91 17:05:49 CDT
Subject: Re: Stabilizing NOS!

Jay replied:
> To my rambling:
> > I have been thinking about the glue which would allow multiple
> > copies of NOS running on ONE machine under DV to talk to each other.
> > This could be done through the DV mailboxes, I believe. This might
> > allow several cut down versions of NOS to exist on one machine which
> > couldn't support all the options at once. Maybe one copy could be pretty
> > much dedicated to being a domain server, others handling POP etc etc ..
> 
> Hm. Do you envision having multiple virtual machines, each with a specific
> IP address, each doing one (or a limited number of) function(s), or would
> only one be visible to the outside world?

Yes, I envisage multiple virtual NOSs - all in the same box. How you
configure it, what you make available to the outside world is your
option... sort of like a loopback interface, but between different
copies of NOS.

> I was thinking more along the lines of rewriting the socket code in terms
> of DV's IPC facilities (mailboxes, semaphores, ???) and running only one
> copy of the protocol stack; this simplifies the clients to being simple,
> single-tasking kinds of things (though not the servers). Am I off base here?
> In particular, am I oversimplifying the task?

This can certainly be done (whether NOS lends itself to it is another
matter). I believe this concept is central to QuarterDeck's new product
DesqView/X (or the networking port underneath).

-- 
andyw.

andyw@aspen.cray.com	Andy Warner, Cray Research, Inc.	(612) 683-5835


----
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Thu, 11 Jul 91 7:13:42 HST
Subject: Re: New(er) NOS 0618

> Hello Tony and others
> > 
> > Just installed it here.
> > 
> > I ended up changing my global/default IP address to 128.171.41.31 and
> > did an 'ifconfig ax0 ipaddress 44.14.1.2' for the radio port and
> > things work.  I also don't have to do an 'ifconfig' for each axip
> > interface this way.
> > 
> > Tony
> >  
> I found out: the default used for ip/ip is de first found interface exclu-
> ding localhost and encap. This means that the last defined interface its
> IP address is used as the originating ip address (100 % chance of being wrong)
> But as with previous discussions with Phil: Pick the worst guess , that is the 
> best one to take, more wrong is inpossible!!! That is logic....

Aha.  So since the last interface I assign is an axip interface and it
uses the global IP address (which I've defined to be the Internet
reachable address), that's why it works?

Tony


----
From: "James C Walker(Cap'n)" <70007.4651@CompuServe.COM>
Date: 11 Jul 91 11:52:10 EDT
Subject: Test address

For some reason, the Internet gateway from Compuserve isn't posting
correctly. This is a test to see which name works.
 
Cap



----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Thu, 11 Jul 91 09:22:19 EDT
Subject: Re: New(er) NOS 0618


I have compiled nos_0618 ver 1.7 PA0GRI under BC2.0 with no compilation
errors. It sails right thru. A complete compile took 18 minutes on an
HP Vectra QS20 (386 20MHZ - Landmark CPU 26) with an 800K smartdrive
and using BCC (not BCCX). I would be interested in knowing other's
compile time and system/config. Based on what I see here it seems possible
that a complete compile could be 5 minutes or less on an optimized 486-33
or 50!

That's the good news - now the bad. The tempfile function is broken.
That is under BC2.0. I guess we knew that. I had made the fix that
Kelvin suggested on the prior version and it ran fine. I (GUESS?) Mikes's
fix is the 'temporary' way to go, but I am confused, he has made
corrections on corrections. Think I will wait for the dust to settle
alittle. I don't expect that Borland will do anything very fast, if
they do. In any event be warned that the latest PA0GRI compiled under
BC2.0 without changes will create TMP files until your disk or number
of directory entries overflows!!

Doug


----
From: Jay Maynard <S0JM@ADMIN.HSC.UTH.TMC.EDU>
Date:  Thu, 11 Jul 91 11:03 CDT
Subject: Re: Stabilizing NOS!

Mike Bilow, N1BEE, writes:
> Finally, a comment about whether NOS should be ported to a GUI.  Maybe,
> and I hope you find the masochist to do it.  My suggestion is to worry
> about NOS memory consumption first, perhaps by using some kind of DOS
> extender.  NOS does a lot of things that do not go over very well in
> protected mode, but there are a lot of different approaches.  For example,
> maybe we would find that it is easier to put the code into extended
> memory, rather than the data in the traditional method.  But the big
> problem facing NOS right now is memory, not screen appearance and user
> interfacing.

I'm not sure we can kill both birds with one stone, but maybe we can kill
one and injure one...I've been mulling the possibilities of a Desqview-
specific version of NOS. There's a freely-available DV interface library
available (I think from wuarchive.wustl.edu, but don't hold me to that),
and that might allow having the clients and servers split out from the NOS
kernel and protocol code, and run in separate DV tasks - thus, on a machine
with either LIM 4.0 hardware or a 386, allowing separate address spaces for
each one. I haven't done anything about this yet, mainly because I haven't
had much opportunity to play with it, but also from a lack of an idea where
to start on such a breakup. Anyone else out there thought about something
like this?

...Jay, K5ZC


----
From: brian@ucsd.edu (Brian Kantor)
Date: Thu, 11 Jul 91 08:05:06 -0700
Subject: 

Path: ucsd!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!CS.UCL.AC.UK!J.Crowcroft
From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
Newsgroups: comp.protocols.tcp-ip
Subject: growing pains...
Message-ID: <9107111222.AA00847@ucbvax.berkeley.edu>
Date: 10 Jul 91 14:58:57 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 290








UCL.CS                                                      J. Crowcroft
Request for Comments:  ????                                          UCL
                                                               July 1991



                     address Revolution protocol
                                or
              Converting 32 bit internet addresses into
                     32 Bit Internet Addresses.

Status of this Memo

   This memo suggests an Experimental Protocol for the Internet
   communities.  Distribution of this memo is inexcusable.

Table of Contents

   1. Introduction...........................................    1
   1.1 Motivation............................................    2
   2. Protocol Overview......................................    2
   3. Operation of the Protocol..............................    3
   4. Network Considerations.................................    3
   5. Implementation Model...................................    4
   6. Constructing aRp Data Fields...........................    4
   7. Discussion.............................................    4
   8. Prototype Experience...................................    5
   9. References.............................................    5
   10. Acknowledgements......................................    6
   11. Authors' Addresses....................................    6
   12. Whitespace............................................    7

1.  Introduction

   This document describes the Address Revolution Protocol (aRp)
   and its operation over the Internet. 

Crowcroft                                                       [Page 1]

RFC ????                              aRp                     June 1990

1.1  Motivation

   The motivation behind the implementation of an aRp 
   implementation is fourfold:


      1.  The Internet is running out of address space.

      2.  Network Management staff at campus and regionals
          networks would revolt if they have to reassign all
          host addresses.

      3.  THe backbone management would revolt if all routers
          had to change addresses.

      4.  Very few people have connections off site at anyone time
          compared with onsite [CrowINET91, USC-SIGCOMM91, PaxBER91]

   The need for address re-use is clear. 

2. Protocol Overview

Once the Internet Address Space has become exhausted, the line of
least resistance is to start allocating addresses from the beginning
again. The question then arises:

How may a host on net A talk to a host on net A, when it is a
different net A?

The answer is to reuse an address on the network next to net A that is
different (e.g. Net B), and not currently in use to leave net B.

The aRp protocol is used to query the hosts on net B as to who has a
net B address not currently in use for non-net-B access. (If there is
no net B host, this procedure can be recursed from net B to net C, or
else iterated by a designated Net B aRp server reporting to the Net A
host which net C might be queried fruitfully [In CCITT terminology,
recursion and iteration are known as "chaining and referral"
respectively].

Now, like ARP, aRp uses caching. Unlike ARP, all aRp messages are
broadcast.

aRp messages are either requests or responses. When a host on net A
needs a non-net A address to communicate, it sends a broadcast aRp
request. Routers attached to net A, and net C forward this broadcast.

Any host that is participating in aRp on net C, and is not currently
part of a conversation off net C may send an aRp response, with their
C address. This is sent as a directed broadcast to net  (via the
appropriate router).

Hosts on net A now cache all the net C addresses they glean from
these responses.

Cache timeouts should be sufficiently long to bound the number of
broadcasts, but sufficiently short to allow the borrowed host
addresses to revert to their real owner if they need to re-enter the
Internet. A cache invalidation scheme is for future study.

Crowcroft                                                       [Page 2]

RFC ????                              aRp                     June 1990

3. Operation of the Protocol

The aRp packet is a similar format to the ARP packet (see  section 6),
but is encapsulated in an IP packet. For example, on an ethernet, a
request packet would look like this:

ar$hrd) = ares_hrd$Ethernet
(ar$pro) = ET(IP)
(ar$hln) = length(EA(X))
(ar$pln) = length(IPA(X))
(ar$op)  = ares_op$REQUEST
(ar$sha) = EA(X)
(ar$spa) = IPA(X)
(ar$tha) = don't care
(ar$tpa) = IPA(Y)

The inclusion of the hardware addresses makes possible the complete
obfuscation of bridging and routing functionality in so called
brouters.

4.  Network Considerations

Broadcasts are usually considered a BAD THING. But it is hard to find out 
an address when you dont know who to ask, and harder still, when you dont
know how to reach this unknown host.

Sufficiently ingenious caching should provide a large help - it is
certinasy the case that most networks are hierarchically ordered both
topologically, and in terms of the traffic patterns.

Crowcroft                                                       [Page 3]

RFC ????                              aRp                     June 1990

5.  Implementation Model

Routers may have to be changed to accommodate a hiatus of chaos just
after the introduction of aRp.

6.  Constructing aRp Data Fields

These are filled in very much as in ARP.


7.  Discussion

Basically, the idea is that there is a pool of globally unique
addresses already allocated. All new addresses are duplicates. Hosts
wishing to communicate on the Internet in the "new" address space
borrow from the old one.

Although this is not an entirely serious article (:-), there may be
something in this. A not dissimilar system was in use in the Universe
project for interconnecting Cambridge Rings, where bridges performed
a port mapping function.

One possible implementation choice must be made for hosts on net C
that have todecide when to reploy to an aRp request. The name address
Revolution protocol suggests a mechanism itself: 

A round roster/robin mechanism could be made starting at the lowest
host address and moving up through the address space (modulo Hubble's
constant).

Crowcroft                                                       [Page 4]

RFC ????                              aRp                     June 1990



8.  Prototype Experience

This has been hard to gain, as we have yet to convince anyone of the
soundness of this scheme.


9.  References

RFC 826   Plummer, D.C.  Ethernet Address Resolution Protocol: Or converting
      network protocol addresses to 48.bit Ethernet address for transmission
      on Ethernet hardware.  1982 November; 10 p. (Format: TXT=22026 bytes)

INET91 Wakeman/Crowcroft, Some traffic analysis of UK-US data., INET
91 conference, June 1991

SIGCOMM 91, USC/BNSD paper on traffic

PAX91, Vern Paxson, "Traffic models of Widea area TCP/IP", available
anonymous ftp.

Cambridge Distributed Systems, Needham et al.




Crowcroft                                                       [Page 5]

RFC ????                              aRp                     June 1990


10.  Acknowledgements

       The Author would like to thank his parents for their valuable
       contribution.


11. Authors' Addresses

   Jon Crowcroft
   Subliminal Science Department
   University College London
   Gower Street
   London WC1E 6BT GB

   EMail:  jOn@CS.uCl.AC.UK





Crowcroft                                                       [Page 6]

RFC ????                              aRp                     June 1990





















































Crowcroft                                                      [Page 7]



----
From: Michael Chace <mikec@praxis.co.uk>
Date: Fri, 12 Jul 91 10:25:15 +0100
Subject: RE: Stabilizing NOS!

>>>>> Regarding RE: Stabilizing NOS!; mikebw@idsvax.uucp,
        mikebw%idsvax%anomaly.sbs.com%swlvx2.msd.ray.com%samsung%uunet@ukc.ac.uk said:

mikebw> As to documentation, I would agree that it is inadequate for new users.


	As regards this, my TCP/IP Beginner's Information Package was
	FTP'd to thumper some months ago and so it should be on
	ucsd.edu. It covers a mixture of NET and NOS documents plus
	others on the NOS mailbox and IP over NET/ROM etc.

	The file was put in /incoming called beginner.zip but I presume
	it must now be in the docs directory ?


73. Mike (G6DHU)


----
From: Samuel Lam <skl@wimsey.bc.ca>
Date: Fri, 12 Jul 91 05:27 PDT
Subject: Re: WD8003EP on Zenith 159

>What does work, but I don't understand, is to set the card to
>D0000 (851968) and tell the driver that it is at D000 (53248).

That's because the card is dealing in byte addresses while the
driver is dealing in paragraph addresses.  Since a paragraph
is 16 bytes, paragraph number 0xd000 and byte number 0xd0000
are the same.

...Sam
-- 
<skl@wimsey.bc.ca>


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <mikebw@idsvax.ids.com>
Date: Thu, 11 Jul 91 02:48:50 EST
Subject: Watchdog bug in PA0GRI NOS

The watchdog timer is set in PC.C to count 300 ticks, with the comment that
this is 300 seconds.  However, the counter is decremented by the ISR on
Int 1Ch, which is chained off IRQ0.  This means that the watchdog is only
running for 300 ticks at 1/18 second per tick, a lot less than intended.
This leads to frequent unexpected reboots with watchdog enabled, often as
a result of doing relatively harmless things.  Changing the values to which
WDCurr and WDTick are enabled to 3000 instead of 300 solves the problem.
-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA
               mikebw@idsvax.ids.com


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Fri, 12 Jul 91 10:13:39 EDT
Subject: TMP file more...

I have played with the code some more and can only confirm my earlier
findings. The DIR command seems to work correctly but other services
that use TMP files leave them openned.

I poked thru the code and I noticed that the dodir function both
fcloses and unlinks the TMP file. Other services fclose but do not
unlink?? At least that is what I was able to determine. Maybe that's
a clue... But it did work.

Is the function in pc.c to remove TMP files used? It is not called
anywhere in the NOS code. Tried compile with and without with no
dif.

At the moment I am periodically deleting the TMP files - get about 20
an hour. Mostly from incoming POP.

Doug


----