HAM Radio 3/hamradioversion3.0examsandprograms1992.iso/tcp/grinost/readme07.txt

Text File | 1991-09-22 | 9KB | 188 lines

September 22, 1991

By Mike Bilow, N1BEE
     AX.25: N1BEE @ KA1RCI.RI.USA.NA
     Internet: [e-mail]
     Amprnet: [e-mail] [44.104.0.20]
     Fidonet: MIKE BILOW, 1:323/120
     Standard post: Forty Plantations, Cranston, RI 02920-5554, USA


For GRINOS/GRINOS-S KA9Q 910618/PA0GRI 910822v1.7h/N1BEE 910921v0.72


     All users of GRINOS/GRINOS-S are invited to join the grinos@n1bee
mailing list.  This is what I use to distribute advisories and updates.
There is no requirement that you actually use GRINOS in order to join the
mailing list.  Just send a message to me and you will be added.  Users
accessible to me via the Amprnet will receive their updates that way, and
others via the conventional packet BBS forwarding system.


     I. KA9Q/PA0GRI changes

     Despite the new feature added by PA0GRI which allows selecting not
to include the AXIP (Internet wormhole AX.25 encapsulation) code at
compile time, actually taking the code out causes NOS to fail to
recognize IP frames for itself, although they trace perfectly.  This is
a fairly serious bug somewhere, but the AXIP code remains in the N1BEE
executables just to keep them working.


     II.  N1BEE changes

          A.  TCP backoff limit
              (as of N1BEE 910903v0.70-alpha test)

     After much controversy, I have made major changes to the backoff
clamp that first appeared several versions ago.  Most importantly, the
command name has been changed to "tcp bblimit" instead of the old
"tcp blimit".  This is to avoid confusion with a similarly named but
functionally different command that is in wide use with the releases of
G1EMM code from Brian Ellsworth, KA1JY.  In addition, this new clamp
command has a minimum value of 10.  This is not to imply that such a low
minimum value is appropriate when using the linear backoff algorithm,
but rather to prevent users from accidentally setting the clamp to grossly
inappropriate values.  The default of 31 is probably a good choice; 31 was
also the maximum in previous versions, but now the clamp can be set as
high as 32767 (which is tantamount to disabling it).

     The new "tcp bblimit" command can also be used to clamp exponential
backoffs now, although it will be rtt dependent and therefore different
for each channel.  When used for exponential backoff, tcp bblimit values
greater than 31 will be ignored, and a clamp of 31 imposed; this is a
restriction of the original NOS code, and is not under my control.


          B. Domain name translation
             (as of N1BEE 910805v0.61-alpha test)

     In order to facilitate better handling of RSPF, although not in any
way specific to it, translation of IP addresses to domain name is now
inhibited for all addresses with a last octet of 0 or 255.  This usually
affects only screen displays of routing tables and the like.  However,
traces of RSPF update frames, which would frequently include addresses
of this form, would hang NOS while attempting to translate these bogus
addresses into domain names by searching the DOMAIN.TXT file.  Although
these hangs were temporary, they were very annoying, and are eliminated.
The applies, of course, only when "domain translate" has been turned on.


          C. ARP bug fix
             (as of N1BEE 910919v0.71-beta test)

     ARP requests generated by other hosts but seen by GRINOS which
claimed to be from [0.0.0.0] and seeking [0.0.0.0] would crash GRINOS,
even though GRINOS was doing nothing other than monitoring them.  All
ARP processing is now prevented on such frames, which are intercepted
and discarded if either sender or target address is [0.0.0.0].


          D. RSPF bug fix
             (as of N1BEE 910919v0.71-beta test)

     The very frustrating RSPF bug that caused routes to go "tentative"
forever seems to have been repaired.  This was in connection with the
record keeping related to the ping processes started by RSPF.  An added
line is provided (probably on a temporary basis) in the display from
"rspf status" in order to show the counts for Nrspfproc and Keeprouter.
While occasional excursions from zero are normal, these counters should
return to zero after excursions and should nearly always display as
zero.  Persistent non-zero values for these counters, RSPF routes going
permanently tentative, and so forth, should be reported.

     In addition, Walt, KZ1F, has been making significant progress on
cleaning up some of the dirty pointer code in RSPF.  This should also
add to the stability of NOS as a whole.

     While the Rhode Island LAN has been running what I call "The World's
Largest RSPF Net," it should be understood that the feature is experimental.
Anyone wishing to do their own experiments, with the permission of their
local switch administrator, is encouraged to contact me for more information.
It should be understood that fairly drastic consequences for an entire RSPF
network can easily ensue from just one RSPF host that is set up incorrectly.


          E. Ottowa PI driver now standard
             (as of N1BEE 910921v0.72)

     Due to some demand by the group in Dayton, Ohio, I have made the
Ottowa PI driver a standard feature of the large version of GRINOS.
The small version will not be affected.  Since I have no hardware on
which to test the driver, I am running pretty much blind.  Inquiries
can be directed to the Dayton group liaison by Internet to address
<[e-mail]> or by AX.25 to AG9V @ N8ACV.OH.USA.NA.
He may not be able to help you, but he cannot possibly know any less
than I do about it, and he will be in a better position to commiserate
with you.


          F. NNTP client support withdrawn
             (as of N1BEE 910921v0.72)

     The inclusion of the Ottowa PI driver meant that something had to
go, preferably something large.  Although I had hopes of encouraging some
experimentation with NNTP via Amprnet, I know of no one actually using
NNTP with my executables.  In order to keep the memory requirements at a
reasonable level, in addition to the need to be able to link successfully
into a DOS executable with a 64K near data segment, support for NNTP is
now ended.  The small version of GRINOS is again unaffected, as the NNTP
client support was never in it.


          G. Compression method changed
             (as of N1BEE 910921v0.72)

     Previous releases of GRINOS executables have been compressed with
PKLITE v1.12 after preprocessing with HDROPT v1.12 per the documentation
from PKware.  Serious problems have been observed with several versions,
which I believe are related to bugs in HDROPT.  For example, this release
of GRINOS-S.EXE will crash immediately on my machine (a 386 running QEMM)
with a general protection fault if HDROPT is used, but appears to work
correctly otherwise.  Therefore, use of HDROPT will be discontinued.  The
resulting files will be slightly larger on disk as a result, but will not
occupy a different amount of space once loaded into memory.


     III. Documentation

          A. From PA0GRI

     I have a copy of Gerard's original documentation for his v1.7h, which
is the basis for my v0.7x series.  I am in the process of editing it and
trying to correct any inconsistencies produced by my customizations.  When
it is available, I will announce that fact and post it in the usual places.


          B. Sample AUTOEXEC.NOS

     In response to numerous requests, I am binding a sample AUTOEXEC.NOS
into the distribution ZIP files.  Almost no one will be able to use it as
is, but it should provide some general hints and a place to start.  I am
going to write it as if the user was taking part in our POP system at
switch.w1cg-9.ampr.org [44.104.0.2], and in our RSPF experiment so that
users can see how that is done here.  As explained, the RSPF system should
not be used except as part of an organized test, and POP requires making
arrangements with the postmaster of some POP server.  I am a believer in
very short and simple AUTOEXEC.NOS files.


     IV. Support and distribution

     The ChowdaNet BBS has now joined Fidonet with address 1:323/120, but
file requests are not supported at this time.  In order to operate with
the network front-end software, we have switched the modems.  Callers
wishing to restrict their connection to 9600 baud using V.32/V.42bis
should now call [phone].  Callers wishing to permit any speed
connection should call [phone], which will automatically hunt to
the other line if busy.  The 0334 line is at this time answered by a
Telebit Trailblazer modem, which will allow 19200 baud PEP with another
PEP-compatible modem, but only 2400 baud MNP5/V.42 for regular modems.

     ChowdaNet remains the official landline central distribution point
for all GRINOS executables and source.  Executables only are posted for
FTP on the Amprnet at New England sites wb6nil.ampr.org [44.56.0.64] and
switch.w1cg-9.ampr.org [44.104.0.2].  These are what I guarantee to be
current, although posts may have been made to other sites.