Date: Tue, 2 Feb 93 04:30:10 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 #33
To: tcp-group-digest
TCP-Group Digest Tue, 2 Feb 93 Volume 93 : Issue 33
Today's Topics:
DOMAIN Server
Multi-Port RSPF
Ohio DNS updates
RDATE questions and comments (3 msgs)
RSPF docs/help needed
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: 02 Feb 93 06:06:34 CST
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: DOMAIN Server
To: <TCP-Group@UCSD.Edu>
I have JNOS 1.07b on 2 systems. I've setup one as a DNS. The other
has a DOM ADD KF5MG. When an IP address is added to the domain.txt file
as a result of a domain lookup, no time stamp is added. Has anyone else
noticed this? Is there a parm that needs to be set up to get the
time stamp added? 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: Mon, 1 Feb 93 09:37:37 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: Multi-Port RSPF
To: kf5mg@vnet.ibm.com, 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.
There seems to be some disagreement on this issue. I have maintained that when
a switch, gateway (whatever one might call it) has 2 ports its operating on
then it is in effect a multi-homed gateway and as such requires a seperate addr
for each port. This should solve the rspf problem since a station cant be
routed thru the same ip addr on two different interfaces. The analogy to
multihomed gateways comes straight out of the Comer/Stevens books. I believe
what Fred was trying to accomplish with rspf 2.1 was to solve the problem while
allowing a gateway to have a single ip addr on multiple networks. Again, I
think that if a gateway exists on 440 and 2 mtrs then there is a 440 network
and a 2 mtr network, not a single one. Walt
Walt Corey - kz1f@kz1f.legent.com
----------------------------------
| |
| Space for Rent apply within |
| |
----------------------------------
------------------------------
Date: Mon, 1 Feb 93 14:06:05 EST
From: barry@dgbt.doc.ca (Barry McLarnon)
Subject: Ohio DNS updates
To: tcp-group@ucsd.edu
> Not sure if Windsor, Ontario is in there too, but if not maybe the
> coordinator (isn't that you Barry?) can send that too?
All of the 600 or so IP addresses issued in Ontario *should* be in the
database, but no doubt a few have slipped through the cracks. Please
bring any exceptions to my attention. I consider it part of an address
coordinator's job to keep the nameserver database updated, even if his
area has little or no connectivity with other parts of the ampr.org domain.
Such connectivity can appear overnight! If he can't or won't do the updates,
he should be replaced by someone who will.
> Ron N8FOW
Barry
--
Barry McLarnon | Internet: barry@dgbt.doc.ca
Communications Research Center | AMPRnet: barry@bbs.ve3jf.ampr.org
Ottawa, Canada K2H 8S2 | PBBSnet: ve3jf@ve3jf.#eon.on.can
------------------------------
Date: Mon, 01 Feb 93 07:47:02 EST
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: RDATE questions and comments
To: crompton@NADC.NAVY.MIL (D. Crompton)
> 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.
You should get and read the RFC on the Network Time Protocol. NTP has
a lot of sophisticated filtering of clock offset and delay samples to
get accurate clock synchronization across a network. I believe that
its documented in RFC1305.
Across a busy campus internet, we routing sync our clocks with within
10 milliseconds or so. You can do pretty close to that over typical
56k and faster paths on the internet. I run it across my SLIP link as
well.
Louis A. Mamakos
wa3ymh
------------------------------
Date: Mon, 1 Feb 1993 08:33:34 -0600 (CST)
From: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
Subject: RDATE questions and comments
To: tcp-group@ucsd.edu (tcp/ip networking group)
Doug,
Thanks for the fix for the "stime()" call; perhaps now I can run rdate
regularly.
>By the way the problem with not parsing the text -
>
> at 0800 "writeall shutting down now"
This can be solved by putting a backslash before any internal quotes:
at 0800 "writeall \"shutting down now\""
works in my autoexec.nos file.
------------------------------
Date: Mon, 1 Feb 93 10:59:49 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: RDATE questions and comments
To: tcp-group@ucsd.edu
> This is one of the problems observed with OS/2 VDMs. Aparently, the
> time in low memory is not monotonic increasing at all times, resulting
> in days being insterted. Mike Bilow (N1BEE) check that the time went
> backwards by more than about 1/3 day before incrementing the day, but that
> patch caused the system to ignore midnight rollover and crash quickly.
> I used the same basic idea, except I (1) read upper, lower, upper
> in a loop until the upper value was stable (instead of calling biostime
> under os/2 and dpmi), and (2) ignore backwards time of <0x10000 ticks by
> holding the existing time rather than moving the time backwards. This
> seems to work better.
>
I don't know about Rdate, but there was/is a problem in KA9Q with the
Clock and Tick. They are incremented at interrupt time (interrupts
off), but are read (and the event queue updated) with interrupts on.
So, on an 8088 (which does single byte fetches) or 286/386 (which can do
word fetches), the middle or upper bytes can appear to go backwards.
Say we load the first (low order) byte, which just happens to have the
value 0xff. Then we are interrupted. The 0xff is incremented, and goes
to 0, the next octet is one higher. The clock interrupt returns.
We now load the second (and higher) order bytes. We think that we have
a clock value of 0x01ff, when the real value is 0x0100. The next time
we read the clock, we get 0x0101, and it seems to have gone backwards.
Since the same thing can happen at any of the 4 bytes in the Clock, this
can actually appear to go quickly forward and back entire months!
The solution is to always repeatedly read the clocks until you get two
in a row with the same value. Phil did this in some places, but not
everywhere. The same thing applies to time() and other MSDOS real time
values.
The other method would be to turn off interrupts while reading clock and
time values. Unfortunately, you can't make BIOS or DOS calls with
interrupts off, so you have to be a lot more careful with this method.
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: 02 Feb 93 06:01:52 CST
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: RSPF docs/help needed
To: <TCP-Group@UCSD.Edu>
Does anyone have any docs that cover RSPF? There appear to be
several different parms that need to be set. What are the suggested
values in different environments. Can someone send me some 'real life'
examples that they're using. 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
------------------------------
End of TCP-Group Digest V93 #33
******************************
******************************