Date: Sat, 30 Jan 93 04:30:09 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #30
To: tcp-group-digest


TCP-Group Digest            Sat, 30 Jan 93       Volume 93 : Issue   30

Today's Topics:
                 Domain Name Server ( DNS ) question
                      GRINOS 2.0M Bug? (2 msgs)
                           Multi-Port RSPF
                         RCS 5.5 on UCSD.Edu
                                RDATE
                     RDATE questions and comments
                             WNOS - PMNOS

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 30 Jan 93 05:21:54 CST
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: Domain Name Server ( DNS ) question
To: <TCP-Group@UCSD.Edu>

   When a user uses a domain name server to resolve an ip address, NOS
puts an entry in the users's domain.txt file.  It looks like this is a
permanent entry.  Will this entry ever be removed by NOS?  If an IP
address is updated on the DNS, how can the user, using the DNS get the
new IP address if he's made a permeant entry in his domain.txt file?
Thanks.

73's de Jack
| (817) 962-4409 | VM Office Systems | 5 West Kirkwood Blvd | MS 06-05-60 |
|  T/L  522-4409 | Performance Group | Westlake, Tx 76299   | Rm. 6569    |
vnet:jgrass@dalhqic2  ibmmail:usib34cd@ibmmail internet:kf5mg@vnet.ibm.com

------------------------------

Date: Fri, 29 Jan 1993 12:48:43 +0000 (GMT)
From: kelvin@thed.uk22.bull.com (Kelvin J. Hill)
Subject: GRINOS 2.0M Bug?
To: tcp-group@ucsd.edu

Ed,
   it's not a bug. I put that facility into my version of NOS many moons ago
so that a remote station could kick a NOS system and get thier own netrom
tables updated imediately. This would allow non-24 hour stations to come and
go at will, without waiting for 30 minutes for the next netrom broadcast.
Gerard has taken many of my changes and put them into his version and this is
how you have this functionality.
If you don't like the way it works, just locate the kick responder in the 
source code and remove the line that forces netrom to issue the broadcast.

Hope this helps....

Kelvin. (G1EMM)

------------------------------

Date: Fri, 29 Jan 1993 08:48:32 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: GRINOS 2.0M Bug?
To: ed@wa9yyf.ampr.org, tcp-group@ucsd.edu

(searching archives of remembered code from reading 3 years ago........)
I seem to recall that the netrom "beacon" was a feature added to the
remote kick command.   Another feature is it does a SMTP kick to that
station.


I believe the reasoning is if a station has been off the air, then doing
a remote kick should jump-start there getting back into the community.
Thus, sending a nodes broadcast ensures they have netrom routing to you,
the smtp kick will push any mail to them if you have been waiting for them
to come up, and any half-open tcp/netrom/ax25 sessions should be reset or
resumed (if you just lost radio contact, and neither side restarted).

I think this was added to NOS a few years ago by Phil.  So, no, its not
a bug, its a feature!   If you don't want netrom to beacon, consider
turning off netrom verbose (I think it has been in all versions for a
while).

milton

------------------------------

Date: 30 Jan 93 05:25:42 CST
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: Multi-Port RSPF
To: <TCP-Group@UCSD.Edu>

   I think I remember that RSPF was broke when it came to handling
multiple ports.  Is that still the case?  We've got users on both 2 mtrs
and 440.  Some are on both freqs.  Wondering if we can use RSPF in this
environment.  Thanks.

73's  de  Jack - kf5mg
AMPRnet         -  kf5mg@kf5mg.ampr.org       - 44.28.0.14
AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet        -  kf5mg@vnet.ibm.com         - home (817) 488-4386

------------------------------

Date: Fri, 29 Jan 93 12:14:46 EST
From: ron@chaos.eng.wayne.edu (Ron Atkinson )
Subject: RCS 5.5 on UCSD.Edu
To: tcp-group@ucsd.edu

I uploaded RCS 5.5 on UCSD.Edu.  Brian,  maybe you can moved it to the
hamradio/packet/ka9q  directory for Phil's code or whereever else you
feel it should go.

Ron N8FOW

------------------------------

Date: Fri, 29 Jan 93 15:14:11 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: RDATE
To: tcp-group@ucsd.edu

Looking over the code I suppose I could try - 

  i_state=dirps();
  stime(&rtime);
  restore(i_state);

Doug

------------------------------

Date: Fri, 29 Jan 93 12:36:12 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: RDATE questions and comments
To: tcp-group@ucsd.edu

I started using RDATE to set the time of our switch to a very
accurate server. In this way users can likewise interrogate the
switch for reasonably accurate time. I say reasonably becasue the
rdate routine does not take into account circuit time. I made a crude
modification to rdate to add some time based on the circuit time. I
also changed the maximum timeout to 2 minutes. I was wondering how
routines distribute time like this synchronize for high accuracy. 
Because of the unreliability of our AMPR circuits it is very hard
to determine one way times.

For some reason PC clocks are lousey! My inexpensive wristwatch is
far better. It is actually amazing! It stays within a few seconds over
many months. Most PC's seem to drift in minutes/week or even minutes/day.

Another problem that maybe someone could help me with is that the rdate
routine sets the system time with the C stime function. What happens on
my system is that it goes bonkers when this happens. AT commands that
are setup in the table will trigger when they shouldn't etc. What I
think is happenning is that interrupt driven routines that depend on the
system clock are getting bad data while stime is being performed.

How do I turn off interrupts around this stime function call? Has anyone else
seen this? Do you think this IS the problem?

Doug

------------------------------

Date: Fri, 29 Jan 93 10:55:24 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: WNOS - PMNOS
To: tcp-group@ucsd.edu

This is really to MikeC, but perhaps others with some history with
PMNOS can answer as well.
Mike, I have not heard of any problems with telnetting into PMNOS 1d.
In fact, I have had people do that at home to connect to the converse
bridge through me. If PMNOS just goes away, that means it crashed. The stack 
prooblem very early on was strictly for T1 and only affected the font mgr. All 
other "spawned processes" get a 4k (1 page) stack. Thats up from the couple of 
hundred needed in a non paging environment. ANyone else experiencing problems 
with telnet and PMNOS? Walt



Walt Corey - kz1f@kz1f.legent.com
----------------------------------
|                                |
| Space for Rent apply within    |
|                                |
----------------------------------

------------------------------

End of TCP-Group Digest V93 #30
******************************
******************************