The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for January 1988 (374 messages, 172999 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/01.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 00:53:11 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: EtherTalk broadcast invasion

Gee, it's too bad EtherTalk doesn't use an ethernet multicast address, rather
than using the (global) broadcast address.  This way, only those who feel they
are interested would have to listen for this stuff.

By the way, how did this "big-lan@suvm.bitnet" address escape on to the
internet?  This is a little unfriendly.

louie

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 01:02:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: subnetting zero-numbers

From: nomad@cs.orst.edu (Lee Vincent Damon)

       I have just finished reading rfc950 (finally). I notice in this
    doc that the "zero address" of each subnet is supposed to remain 
    unused, along with the "all-one" address.  When I issued numbers
    on my subnet I knew about the all ones, but not about the zeros. None
    of our machines have complained so I was wondering if the zero's
    "this net" requirement has been removed and we just have an old doc?

If viewed in isolation, there is no intrinsic reason why the zero
host address should be banned; unfortunately, things like this can
never safely be viewed in isolation.  The problem comes from the
historical use of that address as a broadcast address by some hosts
(chiefly, 4.2BSD-derived systems).  Even though the standards now
specify an "all ones" broadcast address, many hosts still treat
the "all zeros" host address as a broadcast.  So, you might have
some hosts that are sending packets as link-level broadcasts when
they are meant to be sending unicasts, and other hosts that may
refuse to receive or forward packets addressed to the all zeros
host.

Further, some systems use an all-zeros host part to refer to the
network rather than a specific host; e.g., 128.45.1.1 is a host
but 125.45.0.0 is a network.

In summary, use of the zero host address can lead to confusion
and chaos.  As a general principle of address space engineering
(a discipline I just invented), it is always a bad idea to use
the "zero" address for a real object.  You're likely to find
it used by mistake.

By the way, the zero subnet number is also a bad idea, for
similar (but not identical) reasons.

-Jeff

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 02:41:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping clocks

Phill,
 
Meanwhile what happens over here in Europe? Since you officially leap
at 7pm EST and UK is 5 hours advance on you - it sounds as if the UK
(as the 'owner' of the long. 0 just east of the centre of London all
associated with the high tech work on timekeeping done here over 200
years ago so as to sail the seas with better effect to found and hold
the empire.....) is the point of origin for the world leaping. Prehaps
Dave knows more detail.
 
Happy new year from the time-centre of the universe - (and of course
that is why we invented Dr. Who and the Time Lords...)
John

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jan 88 13:45:55 -0500
From:      robb <robb@PARK-STREET.BBN.COM>
To:        Craig Partridge <craig@NNSC.NSF.NET>
Cc:        tcp-ip@SRI-NIC.ARPA, robb@PARK-STREET.BBN.COM
Subject:   Re: ICMP type #7?

Craig,

	Could I bother you for a little more information?  You say

    "Looking at one of the CSNET machines, I discovered that out of 170,000
	IP packets received, ... "

	By CSNET machine, you mean host, rather than gateway, right?
	
	How recently did you notice this occurrence and can you give a historical
perspective to this problem (not noticed/not looked for a week/month ago)?

	Is it possible to find out where some of these ICMP messages are coming
from and what the contents of some of these messages might be?

	I ask these questions because I want to see if it is, perhaps,
our gateways that are, say, sending out an incorrect ICMP message in
response to some problem (ttl expire, redirect, whatever).

	Thank you.

robb.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 08:16:36 GMT
From:      dupuy@westend.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Ever since the leap second (23:59:60 GMT Jan 1, 1988) the realtime clocks on
Sun-3s have been behaving strangely.  When booting /vmunix, just after the
message about using nn buffers, the kernel prints out a little message like the
above.  That's not too bothersome for us, since we use rdate and ntpd to keep
our Suns' clocks in synch anyhow.

What is bothersome is that the system clocks have started to slew wildly.
Using a little program I hacked up, I have found that there are spurious deltas
showing up in adjtime(2) on *ANY SUN-3* which has had its time set or adjusted
since the leap second.  Running the following program a few times:

adjtime.c
---------
#include <sys/time.h>

struct timeval delta = { 0, 0 },
	    olddelta = { 0, 0 };

main ()
{
	if ( adjtime (&delta, &olddelta) == -1)
		perror ("adjtime");

	printf ("adjust %d.%d, oldslew %d.%d\n", delta.tv_sec, delta.tv_usec,
					olddelta.tv_sec, olddelta.tv_usec);
}

I get results like this:

Script started on Fri Jan  1 02:14:18 1988

finest# alias adj '/src/local/local/netdate/adjtime; date'
finest# adj
adjust 0.0, oldslew -1490.-143408
Fri Jan  1 02:15:26 EST 1988
westend# adj
adjust 0.0, oldslew 0.0
Fri Jan  1 02:15:32 EST 1988
westend# adj
adjust 0.0, oldslew -1729.-961408
Fri Jan  1 02:15:46 EST 1988
westend# 

westend# date 8712311650
Thu Dec 31 16:50:00 EST 1987
westend# adj
adjust 0.0, oldslew 0.0
Thu Dec 31 16:50:09 EST 1987
westend# adj
adjust 0.0, oldslew 0.0
Thu Dec 31 16:50:29 EST 1987
westend# adj
adjust 0.0, oldslew 0.0
Thu Dec 31 16:50:48 EST 1987

script done on Thu Dec 31 16:50:49 1987

As can be seen, every ten to fifteen seconds, some monstrous time adjustment
gets added in by the kernel.  This is *not* being done by ntp or any other time
daemon - it even happens in single user mode.  It can also be seen that after
the date is reset to 1987 (GMT) this behavior disappears, and time stabilizes.
The silly message when booting disappears as well.

So it looks like the guilty party is /sys/sundev/clock.c.  But not having
source code, what can I do?

Other observations: Our Sun-2s (bless their little obsolete cpus) have not even
stuttered since the leap second went down.  Their TOD clock code seems to be
just fine.

So will someone with access to Sun kernel sources please help me out?  This is
a serious bug, and I imagine Sun will have a patched OBJ/clock.o for binary
sites eventually, but in the meantime, it is stretching the resources of ntpd
to even keep the machines within a *minute* or so of true time.  The poor
machines which aren't running ntp are okay until they are rebooted, or someone
foolishly tries to set their time, but once that happens, their watch gears get
unsprung.

@alex
---
arpanet: dupuy@columbia.edu
uucp:	...!seismo!columbia!dupuy

---
arpanet: dupuy@columbia.edu
uucp:	...!seismo!columbia!dupuy

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 08:23:52 GMT
From:      dupuy@westend.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Forgot to give the versions for which this problem exists:

SunOS 3.2
@(#)clock.c 1.1 86/07/07

and

SunOS 3.4
@(#)clock.c 1.2 86/10/08
---
arpanet: dupuy@columbia.edu
uucp:	...!seismo!columbia!dupuy

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jan 88 20:20
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@NSS.Cs.Ucl.AC.UK>
To:        Mills <@NSS.Cs.Ucl.AC.UK:Mills@louie.udel.edu>
Cc:        tcp-ip <@NSS.Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa>
Subject:   Re:  Leaping clocks
Dave,
 
One hour after sending my 'Empire time' msg (Stars Wars is showing on
the TV at this moment) I heard on the 'news' that Paris and not London
pushed the leap button. I'll console myself with the knowledge that we
are both part of the ECC. Years ago I worked at the National Physical
Laboratory Teddington and I thought the atomic clock there had some
national role.
 
Missing has been the education of why we have leap seconds. I assume
they are always positive and are because of either or both - the Earth
does not rotate at a smooth constant rate year by year, the rotation is
slowing down (and the Moon moving further away). 
 
John
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 17:05:53 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: EtherTalk broadcast invasion

As it stands, I see it as an excelent argument for IP routers in the great
router vs. bridge debate.  From what you say, it appears that you can't
have more than 250 MACs using EtherTalk anywhere in your bridged Ether,
and if you have even a hundred, people will notice.  Presumably the 8-bit
node ID is *really* built-in, even if the 20 broadcasts in less than a
second aren't?  Or, do they do it quickly because the defense protocol
breaks down when two nodes try to defend the same address at the same
time?  Whichever, I assume that it won't be long before they lose a big
order because of it, and set some engineers to work on inserting a slightly
more global world-view.

jbvb

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 18:33:46 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/SMTP ULTRIX <-> MULTICS PROBLEM

This may sound somewhat ridiculous but try padding the message so that the data
length is either modulo 2 or modulo 4 bytes (octets) in length.  Not all DEC
interfaces are necessarily byte oriented.

Merton Campbell Crockett
EATON Information Management Systems

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 18:45:55 GMT
From:      robb@PARK-STREET.BBN.COM (robb)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP type #7?


Craig,

	Could I bother you for a little more information?  You say

    "Looking at one of the CSNET machines, I discovered that out of 170,000
	IP packets received, ... "

	By CSNET machine, you mean host, rather than gateway, right?
	
	How recently did you notice this occurrence and can you give a historical
perspective to this problem (not noticed/not looked for a week/month ago)?

	Is it possible to find out where some of these ICMP messages are coming
from and what the contents of some of these messages might be?

	I ask these questions because I want to see if it is, perhaps,
our gateways that are, say, sending out an incorrect ICMP message in
response to some problem (ttl expire, redirect, whatever).

	Thank you.

robb.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 88 19:30:16 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP on RSTS/E

Bill,  You should contact Phil Denzer at Process Software in 
Amherst, MA.  They do a lot of PDP-11 based TCP/IP stuff.
They are at 413-549-6994.

Dan
-------

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 1988 02:09 EST
From:      Charles Jerian <cpj@citi.umich.edu>
To:        dupuy@columbia.edu, tcp-ip@sri-nic.arpa
Subject:   adjtime issue
The following script shuts off the automatic adjtime from the
hardware clock every 30 secs
for suns
if  [ x$1 = "xoff" ]
then echo "dosynctodr/W 0"|adb -k -w /vmunix /dev/mem
else if [ x$1 = "xon" ] 
then echo "dosynctodr/W 1"|adb -k -w /vmunix /dev/mem
else  echo "dosynctodr/D" |adb -k /vmunix /dev/mem 

fi
fi
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 01:56:58 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Alex,

The problem is that the leap second occured in a leap year, an event probably
unanticipated by Sun. Not to worry, it is easily fixed by simply stacking 
another penny on the pendulum, as was done by the Big Ben keepers. You may
have to use the old-fashioned kind before they started adding all that
aluminum goop. Old Pence are the best kind, but they are rather hard to find.

Dave

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 04:20:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping clocks

Dave,
 
One hour after sending my 'Empire time' msg (Stars Wars is showing on
the TV at this moment) I heard on the 'news' that Paris and not London
pushed the leap button. I'll console myself with the knowledge that we
are both part of the ECC. Years ago I worked at the National Physical
Laboratory Teddington and I thought the atomic clock there had some
national role.
 
Missing has been the education of why we have leap seconds. I assume
they are always positive and are because of either or both - the Earth
does not rotate at a smooth constant rate year by year, the rotation is
slowing down (and the Moon moving further away). 
 
John

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 06:27:09 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re:  WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Whew.  I was pinging umd1.umd.edu at leap second time, hoping to catch it in
the act (wonder how many others were doing the same thing?), when suddenly
the time difference started hurtling into outer space.  For a moment I
wondered if Dave Mills had added a leap minute instead of second, but no,
our SUNs had all gone mad.  It was a great relief to hear that someone
else saw the same thing.

I believe I have a fix for this..  Probably the easiest way to
distribute it without annoying SUN too much is as a binary patch.
Say:

# adb -w -k /vmunix /dev/mem
resettodr+0xca?X
	(It should contain 0x536efff4, a subqw #1,a6@(-0xc) instruction.)
	(Change it to NOP's in the /vmunix file with...)
.?W 4e714e71
	(and in the running kernel (this seems to be safe) with...)
./W 4e714e71
$q
#


For those who have source, the relevant module is sun3/clock.c.
The line in resettodr() reading

	t += MONTHSEC(--mon, year);

breaks, since MONTHSEC evaluates the --mon twice in leap years.
It could change to

	mon--;
	t += MONTHSEC(mon, year);

This appears to work on our SUNs running 3.3.


				Stuart Levy, Minn. Supercomputer Center
				slevy@uc.msc.umn.edu

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 07:02:28 GMT
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping clocks

Leap seconds are inserted once per year, on the average. They keep UTC
(Coordinated Universal Time, as broadcast by WWV) within 0.7 seconds of
another time scale, UT1.  UT1 is the time as determined by astronomical
observations of the rotation of the earth, corrected for an annual
fluctuation of about +/- 30 milliseconds caused by seasonal movement of
atmospheric mass and a slight annual distortion in the shape of the earth
caused by solar tidal effects.

Basically, the problem is that the second was defined to be too short with
respect to the average rotation rate of the earth, so additional seconds
have to be inserted periodically into UTC to allow the earth to "catch up".

As you point out there is also a very long term trend having to do with the
transfer of angular momentum from the earth's rotation to the moon. However,
this amounts only to about 1 millisecond per century.

References: Reference Data for Radio Engineers, Howard Sams & co.

Phil

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 07:09:00 GMT
From:      cpj@CITI.UMICH.EDU (Charles Jerian)
To:        comp.protocols.tcp-ip
Subject:   adjtime issue

The following script shuts off the automatic adjtime from the
hardware clock every 30 secs
for suns
if  [ x$1 = "xoff" ]
then echo "dosynctodr/W 0"|adb -k -w /vmunix /dev/mem
else if [ x$1 = "xon" ] 
then echo "dosynctodr/W 1"|adb -k -w /vmunix /dev/mem
else  echo "dosynctodr/D" |adb -k /vmunix /dev/mem 

fi
fi

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 08:13:10 GMT
From:      lear@aramis.rutgers.edu (eliot lear)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip books

Dr. Hedrick has written an introduction to TCP-IP which is perfect
for the beginner.  The documentation is located on INTERNET host
TOPAZ.RUTGERS.EDU [128.6.4.194] located in pub/tcp-ip-docs.  In that
same directory is a group of relavent RFCs such as RFC 791.
-- 
Eliot Lear
[lear@rutgers.edu]

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 13:35:08 GMT
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP on RSTS/E


I believe that in some incarnation the PC/IP package ran on PDP-11s
under unix.  The software of course nowadays runs on PCs and makes no
use of Unix (or Unix-like) system calls except I think for _exit()
which is provided in the microsoft C library for DOS.  If you have
a C compiler, it might be worth trying to compile the  PC/IP programs
on your PDP-11.

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 16:22:17 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping clocks

Phil,

In that reference (Seventh Edition, 1985) it also points out that on 1 January
1972 the NBS reference was retarded ten seconds with respect to the International
Atomic Time (TAI) scale maintained by the BIH. Since leap seconds have been
syncronized since then, I conclude the whole thing is a plot to make sure
the rest of the world is always ahead of us.

Dave

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 20:09:51 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Response to Long Distance NFS Query


Sure, and I remeber running DECX for days and having things turn up
100 % OK, but then having the machine blow up with hardware errors
five minutes after the normal OS was booted.  There's no diagnostic
like actually trying to use the system.

-Ron

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 20:19:31 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: UVax Ultrix Blues also Pyramid-98xe Blues


I believe TAC's only offer a window for the buffer they have.  The interesting
thing is that they don't slide the window when data has been received, they
wait until the buffer is full (empty) until they open the window up to the
full buffer size.  What this causes is usually a sequence of available window
that goes 64, 32, 0, 64, 32, 0, 64, 32, 0...

-Ron

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 88 22:03:47 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re:  WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

I forgot to mention in sending out the SUN kernel binary patch that
it ONLY works in leap years -- if you just apply the patch, it will break
in January 1989.  Probably everybody will have an official SUN fix by then
but you might want to keep a note of what changed, just in case.

					Stuart

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 88 08:25:17 GMT
From:      kre@munnari.oz (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

In article <8801020627.AA19752@uc.msc.umn.edu>,
slevy@UC.MSC.UMN.EDU (Stuart Levy) writes:
> I believe I have a fix for this..  Probably the easiest way to
> distribute it without annoying SUN too much is as a binary patch.

Then, In article <8801022203.AA25123@uc.msc.umn.edu>,
slevy@UC.MSC.UMN.EDU (Stuart Levy) writes again:
> I forgot to mention in sending out the SUN kernel binary patch that
> it ONLY works in leap years -- if you just apply the patch, it will break
> in January 1989.

Here's an alternative (binary) patch that will work in both leap years,
and in boring old ordinary years.


# adb -w -k /vmunix /dev/mem
resettodr+0xca?X
	(It should contain 0x536efff4, a subqw #1,a6@(-0xc) instruction.
	If you applied Stuart's patch it will contain 0x4e714e71, 2 nop's
	so put back the subw in both the kernel a.out, and memory)
.?W 536efff4
./W 536efff4
	(next, apply a slightly better fix)
resettodr+0xc0?i
	(it should contain "bnes resettodr+0xca", which we will change to be
	"bnes resettodr+0xce" and avoid the incorrect subw)
.?w 660c
	(now verify that its correct)
.?i
	(and assuming it is "bnes resettodr+0xca", change the running kernel)
./w 660c
$q

I can't verify that this actually fixes the reported problem, but it clearly
does fix a bug, and should have the same effect this year as Stuart's fix,
while not hurting next year.  I used SunOS 3.4 to do this, in case other
versions of SunOS deviate (3.3 is apparently the same), here is the original
section of binary ...

_resettodr+0xa6:                        movw    a6@(-0x10),d0
_resettodr+0xaa:                        moveq   #3,d1
_resettodr+0xac:                        andw    d1,d0
_resettodr+0xae:                        andl    #0xffff,d0
_resettodr+0xb4:                        bnes    _resettodr+0xca
_resettodr+0xb6:                        subqw   #1,a6@(-0xc)
_resettodr+0xba:                        cmpw    #2,a6@(-0xc)
_resettodr+0xc0:                        bnes    _resettodr+0xca	<<<< change this to
_resettodr+0xc2:                        movl    #0x263b80,d0
_resettodr+0xc8:                        bras    _resettodr+0xde
_resettodr+0xca:                        subqw   #1,a6@(-0xc)
_resettodr+0xce:                        moveq   #0,d0		<<<< branch to here
_resettodr+0xd0:                        movw    a6@(-0xc),d0
_resettodr+0xd4:                        lea     _monthsec:l,a0
_resettodr+0xda:                        movl    a0@(-4,d0:l:4),d0
_resettodr+0xde:                        addl    d0,d7

kre

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      03 Jan 88 16:25:05 EST (Sun)
From:      dm@bfly-vax.bbn.com
To:        Robert Elz <munnari!kre@uunet.uu.net>
Cc:        tcp-ip@sri-nic.ARPA, dm@bfly-vax.bbn.com
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Could someone explain to the rest of us why adding a leap-second had
any effect on Sun workstations other than making their clock be off by
one second (more than usual)?  Or is 1988 one bit too much in some
data structure?
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 88 21:25:05 GMT
From:      dm@BFLY-VAX.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Could someone explain to the rest of us why adding a leap-second had
any effect on Sun workstations other than making their clock be off by
one second (more than usual)?  Or is 1988 one bit too much in some
data structure?

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 88 23:15:17 GMT
From:      slevy@UC.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

It wasn't the leap second, just the fact that 1988 is a leap year.
SUN-3's contain a date-and-time clock chip, and there's kernel code
to translate UNIX time <=> the clock chip's format.  In leap years,
the code broke and loaded garbage into the chip.  Later, on reading it
back, it noticed that the chip contained an invalid date.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 00:16:11 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   clocks

This business of leap seconds makes me wonder.  The last I read about times
on the network, the entire issue of leap seconds was ignored; RFC 868 simply
says "the number of seconds since 00:00 1 January 1900".  None of the examples
indicate any leap seconds (but were they any before May 1983?).  So, what are
the time servers returning, the 32-bit value with leap seconds or without
them?  I hope it's the latter!
-------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 00:31:00 GMT
From:      ks@pur-ee
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

In article <8801032141.AA15091@ucbvax.Berkeley.EDU> dm@BFLY-VAX.BBN.COM writes:
>
>Could someone explain to the rest of us why adding a leap-second had
>any effect on Sun workstations other than making their clock be off by
>one second (more than usual)?  Or is 1988 one bit too much in some
>data structure?

The Sun3 and the software for its Time of Day chip has been developed since
the last leap year.  If the system clock drifts from the time of day
clock, it is, by default, resynced.  A routine converts the YYMMDD.HHMMSS.THT
from the TOD chip to unix time in seconds from the beginning of time
(00:00 Jan 1 1970 GMT).  This routine did this incorrectly during leap years.
A "--mon" was used in an argument to a MACRO, and in leap years, that argument
got evaluated twice.

Can you say time bomb?

						Kirk Smith

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 01:31:09 GMT
From:      ks@ee.ecn.purdue.edu  (Kirk Smith)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!
In article <8801032141.AA15091@ucbvax.Berkeley.EDU> dm@BFLY-VAX.BBN.COM writes:
>
>Could someone explain to the rest of us why adding a leap-second had
>any effect on Sun workstations other than making their clock be off by
>one second (more than usual)?  Or is 1988 one bit too much in some
>data structure?

The Sun3 and the software for its Time of Day chip has been developed since
the last leap year.  If the system clock drifts from the time of day
clock, it is, by default, resynced.  A routine converts the YYMMDD.HHMMSS.THT
from the TOD chip to unix time in seconds from the beginning of time
(00:00 Jan 1 1970 GMT).  This routine did this incorrectly during leap years.
A "--mon" was used in an argument to a MACRO, and in leap years, that argument
got evaluated twice.

Can you say time bomb?

						Kirk Smith
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 02:33:13 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  clocks

Mark,

Before 1 January 1972, when the international time scales were rationalized
and leap-seconds introduced, the time standards were corrected at appropriate
intervals to maintain time with respect to Earth rotation to within 100 ms
or so. This fact, along with the fact that atomic clocks were rare near the
beginning of the century, makes it meaningless to consider leaps before that
date. There have been maybe a dozen leap seconds since then, all positive;
however, I don't have the dates handy at the moment.

In 1980, when IEN-142 was published, and again in 1983, when its successor
was published, it didn't seem like such a big deal to tell time down to the
milliseconds, especially since the precision provided by the protocol was
only to the second. Since these documents were published, protocols and
measurement techniques have evolved to the point that events can be synchronized
with high reliability to within a couple of milliseconds over campus LANs and
within a couple of hundred milliseconds over typical Internet paths. Thus,
it comes as no surprise that the leap-second issue has now become important.
See RFC-956, -957 and -958 for further discussion on timetelling in the
Internet and a description of the Network Time Protocol (NTP) which makes
all this possible.

I considered the issue of whether to build in leap-second corrections for
NTP, at least back to their inception in 1972 and decided against it. For
just about any purpose, it is not necessary to order events with respect
to what I will call archival time to better than a second; however, when
that becomes necessary, the user would have to insert the leaps as necessary
and using archival information telling when they were made.

In fact, the time scale NTP uses really concides with International Atomic
Time (TA-NBS). After leap-second corrections TA-NBS becomes UTC-NBS as
broadcast. TA-NTP concided with TA-NBS just after the original correction
was inserted prior to 1 January 1972. The rest is history.

Dave

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 04:01:00 GMT
From:      mp@allegra
To:        comp.protocols.tcp-ip
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

If anyone has a patch for sun4's, please send it along; we don't yet
have source code or much knowledge of the assembly language.  A
short-term workaround, for both sun3's and sun4's, is to minimize
reliance on the tod clock: run rdate as soon as possible after booting,
and patch the kernel variable dosynctodr to be 0 so that the unix date
is not periodically copied (well, actually, it's adjtime'd) from the
incorrect info in the todr.  This workaround may result in
the unix date running a bit slow due to missed clock interrupts.

    Mark Plotnick
    Department of Solar Calendars
    allegra!mp

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 05:01:21 GMT
From:      allegra!mp@ucbvax.Berkeley.EDU  (Mark Plotnick)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!
If anyone has a patch for sun4's, please send it along; we don't yet
have source code or much knowledge of the assembly language.  A
short-term workaround, for both sun3's and sun4's, is to minimize
reliance on the tod clock: run rdate as soon as possible after booting,
and patch the kernel variable dosynctodr to be 0 so that the unix date
is not periodically copied (well, actually, it's adjtime'd) from the
incorrect info in the todr.  This workaround may result in
the unix date running a bit slow due to missed clock interrupts.

    Mark Plotnick
    Department of Solar Calendars
    allegra!mp
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jan 88 13:32
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@NSS.Cs.Ucl.AC.UK>
To:        Mills <@NSS.Cs.Ucl.AC.UK:Mills@louie.udel.edu>
Cc:        TCP-IP <@NSS.Cs.Ucl.AC.UK:TCP-IP@sri-nic.arpa>, Mark Crispin <@NSS.Cs.Ucl.AC.UK:MRC@panda.panda.com>
Subject:   Re:  clocks
Dave,
 
Your extensive and timely(!) knowledge about time-keeping makes me wonder
if you are thinking of applying for Swiss nationality. The Swiss have
great respect for clocks. They have that great engineering principle -
if its working don't muck it about. As far as I know they are alone in Europe
in NOT changing there time + or - 1 hour each year; they must be miffed by all
this 1 second leaping done at infrequent intervals.
 
John
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 16:19:53 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Leaping-clock Sunshines

Folks,

I have received several requests for the power-grid graphs mentioned in my
recent message on leaping clocks. They can be found on louie.udel.edu in
~ftp/pub/clock.bit and ~ftp/pub/leap.bit with the usual anonymous login.
Both of these are Sun-format bitmaps suitable for the screenload program
consisting of 41472 octets and must be retrieved in image (binary) mode.
The first graph shows the offset in milliseconds of the eastern power
grid from nominal UT for the day preceeding the 30 June 1985 leap second
and the day one week later. The second shows the offset on 30 June and
1 July. Note that radio reception conditions happened to be so bad during
and after the leap that both the WWVB and WWV clocks had dropped out of
synchronization for three hours following the leap. This further supports
the requirement that the leap should be scheduled in advance not only in
all timekeeping hosts, as is done now in the NTP-speaking world and
fuzzballs, but also in the radio clocks themselves. This in fact should
not be hard to do, since all radio clocks known to me already have a
firmware-driven microprocessor inside.

Dave

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 17:45:43 GMT
From:      bzs@bu-cs.bu.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Oops, I lost the original note so I sent a reply to unix-wizards.
Anyhow, I found that adb'ing the kernel (or via sources) and setting
the variable 'dosynctodr' to zero (it's a flag which defaults to one)
that this problem seems to be ameliorated. I still am not sure what's
causing it or if it's related to the leap-second or not but sections
of the source which slew the clock seem to always check dosynctodr
first.  It shouldn't affect using adjtime from outside the kernel.

I would consider this an emergency patch until someone from Sun sheds
some light on the issue of what's really going on but the systems I've
applied this patch to have been keeping time fine. I'm sure there's
some negative consequence to this patch (always have to set time on
boot? not sure.) I agree tho, I've had systems getting off by an hour
or more of late.

	-Barry Shein, Boston University

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 17:50:35 GMT
From:      bzs@bu-cs.bu.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Urgh, the nice thing about all these patches is one gets so many to
choose from. Stu Levy's looks better than mine (mine: to turn off
dosynctodr), if you applied mine undo it (trivial) and try his.

I'm copying the note so it nullifies my advice on Unix-wizards also.

	-Barry Shein, Boston University

Date: Sat, 2 Jan 88 00:27:09 CST
From: slevy@uc.msc.umn.edu (Stuart Levy)
To: tcp-ip@sri-nic.arpa, westend!dupuy@columbia.edu
Subject: Re:  WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

Whew.  I was pinging umd1.umd.edu at leap second time, hoping to catch it in
the act (wonder how many others were doing the same thing?), when suddenly
the time difference started hurtling into outer space.  For a moment I
wondered if Dave Mills had added a leap minute instead of second, but no,
our SUNs had all gone mad.  It was a great relief to hear that someone
else saw the same thing.

I believe I have a fix for this..  Probably the easiest way to
distribute it without annoying SUN too much is as a binary patch.
Say:

# adb -w -k /vmunix /dev/mem
resettodr+0xca?X
	(It should contain 0x536efff4, a subqw #1,a6@(-0xc) instruction.)
	(Change it to NOP's in the /vmunix file with...)
.?W 4e714e71
	(and in the running kernel (this seems to be safe) with...)
./W 4e714e71
$q
#


For those who have source, the relevant module is sun3/clock.c.
The line in resettodr() reading

	t += MONTHSEC(--mon, year);

breaks, since MONTHSEC evaluates the --mon twice in leap years.
It could change to

	mon--;
	t += MONTHSEC(mon, year);

This appears to work on our SUNs running 3.3.


				Stuart Levy, Minn. Supercomputer Center
				slevy@uc.msc.umn.edu

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 17:57:43 GMT
From:      rob@PRESTO.IG.COM (Rob Liebschutz)
To:        comp.protocols.tcp-ip
Subject:   IEEE Network Magazine

Does anyone know where (or if) IEEE Network Magazine can be purchased
in the Bay area?  Computer Literacy carries various other IEEE
magazines, but not this one.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 1988 23:22-EST
From:      bassen@ifi.uio.no        (Tor Sverre Lande)
To:        Michael St. Johns <STJOHNS@SRI-NIC.ARPA>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: UVax ULTRIX Blues
Well, there is a couple of more hints using TCP/IP on Ultrix.

1. If you also are running DECNET do ALL the DECNET-stuff before
"ifconfig" in rc.local. The DECNET-software changes your
ehternet-adress so if you do "ifconfig" before "ncp ...." your TCP/IP
will never work. Did you ever think hardware ethernet-addresses should
be unique?!?

2. If you are using subnets and have a gateway taking max. 576 bytes
packets between your subnets there is an undocumented kernel-option
NETCONSERVE setting max packetsize to 576 to all non-local subnets.
This is the same option as SUBNETSARELOCAL in 4.3bsd.

-Bassen
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 18:30:22 GMT
From:      bzs@bu-cs.bu.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


It's starting to look like a leap-year, not a leap-second bug, a macro
expanding to add some value twice instead of once (quick analysis.)

Don't believe everything you read on the net (joke.)

	-B

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 19:29:14 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping clocks

Does that mean we get to put Dave in space?  Gee, I think he is already
high enough!  :-)

dennis

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 21:32:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re:  clocks

Dave,
 
Your extensive and timely(!) knowledge about time-keeping makes me wonder
if you are thinking of applying for Swiss nationality. The Swiss have
great respect for clocks. They have that great engineering principle -
if its working don't muck it about. As far as I know they are alone in Europe
in NOT changing there time + or - 1 hour each year; they must be miffed by all
this 1 second leaping done at infrequent intervals.
 
John

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 21:34:45 GMT
From:      mark@nova.usc.edu (Mark A. Brown)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!


Here's a binary patch for the leap year bug that will work for Sun 4s.

# adb -w -k /vmunix /dev/mem
resettodr+0x110?X
	(It should contain 0xba276001, a sub %i5, 0x1, %i5 instruction.
	(Change it to a nop in both /vmunix and kernel memory)
.?W 0x1000000
./W 0x1000000
	(To make yourself feel better, do the following)
.?i
./i
	(If they're nop's, things should now be better)
$q

We are running the SYS4 GAMMA release, but things should be the same
for SYS4 3.2.  If not, here's the original GAMMA binary and you can go from
there.

_resettodr+0xf0:                srl     %i5, 0x10, %i5
_resettodr+0xf4:                orcc    %g0, %i1, %g0
_resettodr+0xf8:                bne     _resettodr + 0x120
_resettodr+0xfc:                sub     %i5, 0x1, %i5
_resettodr+0x100:               sll     %i5, 0x10, %i5
_resettodr+0x104:               srl     %i5, 0x10, %i5
_resettodr+0x108:               cmp     %i5, 0x2
_resettodr+0x10c:               bne,a   _resettodr + 0x120
_resettodr+0x110:               sub     %i5, 0x1, %i5	     <<< change to nop
_resettodr+0x114:               sethi   %hi(0x263800), %o5
_resettodr+0x118:               ba      _resettodr + 0x134
_resettodr+0x11c:               add     %o5, 0x380, %i3
_resettodr+0x120:               sll     %i5, 0x10, %i5
_resettodr+0x124:               srl     %i5, 0x10, %i5
_resettodr+0x128:               sub     %i5, 0x1, %i3
_resettodr+0x12c:               sll     %i3, 0x2, %i3
_resettodr+0x130:               ld      [%i3 + %l7], %i3
_resettodr+0x134:               add     %i4, %i3, %i4
_resettodr+0x138:               mov     %i4, %o0



	Mark

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 88 22:09:00 GMT
From:      karn@JUPITER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Leap second list

I just had a most enjoyable chat with Mr. Kerry Kingham of the US Naval
Observatory.  Kerry provided me with the following list of leap seconds.
Each took place on the very last minute of the last day of the indicated
month:

June 1972
December 1972
December 1973
December 1974
December 1975
December 1976
December 1977
December 1978
December 1979
June 1981
June 1982
June 1983
June 1985
December 1987

It turns out that there is a very amusing reason for the obvious patterns
you see here. The original BIH policy was to declare leap seconds at the end
of the year whenever possible, using the June date only when necessary to
stay within the +/- 0.8 second UTC-UT1 limit.

However, it seems that the French eventually rebelled at having to come in
to work, thereby missing their New Year's Eve parties year after year, so in
1981 they decided to "anticipate" the need for a year-end leap second by
doing it in June. That one took UTC as far behind UT1 as it has ever been
(-0.78 seconds), just barely within the limit.  (Fortunately WWV UT1
corrections (which only go to +/- 0.7 sec) could still handle this because
their absolute values are truncated down to the next lower 100 ms multiple.)

I mentioned the griping we've heard from various parties about what leap
seconds do to radio clocks, and he says "Oh, that's nothing". He then told
me about how several very upset people called him up once to ask why there
was no leap second in that year. It seems that they had systems with a
hardwired "positive leap second every December 31st" rule -- and some of
those systems were in orbit! He then took great pleasure in letting them
know that it is also possible to have NEGATIVE leap seconds...

Kerry also improved my understanding of UT1. It is based on raw observations
of the earth's rotation angle (defined as UT0) corrected for the effects of
polar wandering.  The earth's rotational poles wander over a roughly
circular path every 14 months or so. This is caused by changes in the
earth's mass distribution (solar tides, seasonal atmosphere mass shifts,
melting snow caps, etc). The amplitude of the polar variation is roughly the
size of a baseball diamond, and it causes small changes in the observer's true
latitude and longitude -- therefore affecting the observer's astronomical
observations on the order of +/- 30 ms.

Phil

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 00:41:09 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP on RSTS/E


    ....  If you have a C compiler, it might be worth trying to compile
    the  PC/IP programs on your PDP-11.

All fine, except that PC-IP is 1) dependent on an 18 ticks/sec clock in a
lot of places 2) very 808x-dependent in the tasking, timer and display
modules and 3) has a built-in hardware driver which would need a complete
re-write for another interface/architecture.  The problem with RSTS is
that DEC has never done anything to ease user-written device drivers,
and there was nothing like the VMS XE driver to allow user programs to
get at the raw ethernet the last I knew.  It would be a good place to
start, but it won't be a short job.

jbvb

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jan 88 08:44:09 EST
From:      Jim Petty <PETTY@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Subscription
Please add me to the tcp-ip subscription list.

Thankx Jim
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 04:16:29 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping clocks

Dennis,

Gee, I thought I presented my position to you when you were at DARPA, as
well as your predecessor Barry Leiner and his predecessor Vint Cerf,
not to mention assorted ears at DCEC and NOSC. I would be pleased to
demonstrate things Internet, including fuzzballs, leaping clocks and
other packet poppers, in orbit or other equally exotic place. How about
the African bush using HF radio, or in a submarine under the Arctic
using sonar, or on the Moon using laser or in China using OSCAR satellite?
As for orbit, gotta fix the boosters first. Maybe the Russians would launch
a fuzzsputnik. We could say it represented critical technology and set them
back fifteen years.

Dave

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 04:22:00 GMT
From:      bassen@IFI.UIO.NO (Tor Sverre Lande)
To:        comp.protocols.tcp-ip
Subject:   Re: UVax ULTRIX Blues

Well, there is a couple of more hints using TCP/IP on Ultrix.

1. If you also are running DECNET do ALL the DECNET-stuff before
"ifconfig" in rc.local. The DECNET-software changes your
ehternet-adress so if you do "ifconfig" before "ncp ...." your TCP/IP
will never work. Did you ever think hardware ethernet-addresses should
be unique?!?

2. If you are using subnets and have a gateway taking max. 576 bytes
packets between your subnets there is an undocumented kernel-option
NETCONSERVE setting max packetsize to 576 to all non-local subnets.
This is the same option as SUBNETSARELOCAL in 4.3bsd.

-Bassen

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 06:11:58 GMT
From:      melohn@Sun.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Santa's PSN 7 status

After catching up on my mail over the holidays, it appeared as though
everyone now believes the problems related to "stuck VCs" have been
fixed. However, when I drop my host Sun.COM back to the non-patched
version of our kernel (the one that doesn't attempt to kludge around
the BBN bug by always sending an RR with each packet) I still notice
"stuck VCs", easily reproduceable on one-way VCs between us and
machines on IMPs 11 and 68. Either the latest version of Andy's patch
has not been fully deployed, or it too does NOT fix the problem.

On the 128 byte packet problem; we are in the process of getting
packet traces from the ARPAnet to see exactly what the packet traffic
looks like when we appear to lose the 128 byte packets. I should point
out that this too only appears to happen between us and 1822 hosts
running the new end to end; I suspect that we will find another PSN
7.0 bug at the root cause of this problem. More as soon as I have
the traces.

We are in the process of testing a new version of our software to
handle multiple incoming VCs from the same IP host. Because multiple
VCs are used for X.25 loopback by the PSN under the new end to end, we
feel we have little choice but to support them. I do feel that
requiring this support without any warning that such support would be
required by the new end to end was a mistake, one that our mutual
customers may have to live with until we can test and manufacture
a new software release. It also conceptually wastes VCs, which are
limited resources in many X.25 implementations, because it encourages
in many more cases two or more one-way VCs between host pairs where
a single VC would have existed under the old end to end.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 07:39:33 GMT
From:      map@GAAK.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP on RSTS/E


   Date: Mon,  4 Jan 88 19:41:09 EST
   From: "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>

       ....  If you have a C compiler, it might be worth trying to compile
       the  PC/IP programs on your PDP-11.

   All fine, except that PC-IP is ...

You missed the point earlier in that message where the author said
that they thought it had originally been done on PDP11s.  That's
actually where the author went wrong.  The PCIP code was originally
designed for the MS-DOS environment and is therefore probably
completely unsuited to conversion to RSTS.  The MIT UNIX V6 code on
the other hand ... :-\

					... The problem with RSTS is
   that DEC has never done anything to ease user-written device drivers,
   and there was nothing like the VMS XE driver to allow user programs to
   get at the raw ethernet the last I knew.
I heard rumors (shortly after you left the RSTS community James, and
shortly before I did) that such an interface was in the offing.  I
have not heard what came of that.

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 13:44:09 GMT
From:      PETTY@MITVMA.MIT.EDU (Jim Petty)
To:        comp.protocols.tcp-ip
Subject:   Subscription

Please add me to the tcp-ip subscription list.

Thankx Jim

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 14:18:21 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: 300 Megabit/second national network?


"A Research and Development Strategy for High Performance Computing",
November 20, 1987, is a product of the Federal Coordinating Council on
Science, Engineering, and Technology (FCCSET - pronounced "fixit"[!])
Committee on Computer Research and Appications, an organ of the Office
of Science and Technology Policy.  The report treats four topics:

                High performance computers,
                Software technology and algorithms,
                Networking, and
                Basic research and human resources.

Federal agencies participating in the Networking section included NSF,
NASA, NBS, DHHS, DoE, NIH, DARPA, and NRL.  They solicited white papers
from users and providers of network services in late 1986, and held a
workshop in February 1987 at which six working groups drawn from
industry, universities, and government addressed networking requirements
and future alternatives, special requirements for supercomputer
networks, internet concepts, future standards and service requirements,
computer network security, and the government role in networking; the
networking portion of the FCCSET report is a distillation of the white
papers and six working group reports.

The participating Federal agencies named above are distributing the
report; if you send me your postal address I'll mail you a copy.

-s

PS: The report is also being reprinted in the Proceedings of the recent
2nd TCP/IP Interoperability Conference, organized by Advanced Computing
Environments, 21370 Vai Avenue, Cupertino, CA 95014.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 18:35:03 GMT
From:      Stevens@A.ISI.EDU (Jim Stevens)
To:        comp.protocols.tcp-ip
Subject:   IP & TCP Precedence


2 Questions about IP & TCP Precedence:

(1) The IP Request For Comments (RFC-791) and IP Military Standard
(MIL-STD-1777) specify that Type Of Service (TOS) including
precedence is a parameter that can be passed from the upper layer
protocols to IP during a SEND operation and can be passed from IP to
the upper layer protocols during a RECEIVE operation.

How many IP implementations support this?

How many people actually use this?


(2) The TCP Military Standard (MIL-STD-1778) specifies the actions that
TCP is to perform based upon the precedence passed up from IP in the
TOS.  The TCP Request For Comments (RFC-793) allows implementations to
optionally perform precedence based upon the TOS passed up from IP.

How many TCP implementations support this?

How many people actually use this?



Jim
-------

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 20:59:56 GMT
From:      jsloan@wright.EDU (John Sloan)
To:        comp.sys.encore,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Problems with Encore Annex server


We're having some problems with our Encore Annex terminal servers
talking to our SUN-3/280S timesharing system. We're hoping someone
can give us some advice on where to start troubleshooting. We'll
call Encore and/or Sun, but first we'd like to know where the problem
is likely to be so we know what questions to ask. Any help would be
appreciated. If its a case of RTFM, feel free to flame a bit, but
please provide a reference. BTW, other than this small glitch,
we're very happy with out Annex servers. I have paperwork on
my desk to purchase four more.

SYMPTOMS

While using vi on the SUN through an Annex, the terminal freezes up.
No amount of control keys of any flavor will free it. The status line
on the terminal indicates that the NO SCROLL key is NOT active.  We can
break back to the annex and open another terminal session, and kill our
previous incarnation. Meanwhile, users continue to access the SUN both
through the same Annex and another Annex without any problems.

The problem is fairly rare, showing up on the average less than once a
day.  It has occurred on both Annexes.  It has never been observed
while connecting to either our VAX 750 or 785 or our SUN-3/180S,
although the 380S is our main system and so just may be more likely to
exhibit the problem. It has never been reported to occur outside of vi.
It has never been reported while using the same model terminal on a
direct connect line.

It happened (twice :-( ) while editing this posting, which is unusual.

When you kill the previous session, you can recover the file as usual
with the -r switch. Killing vi is not enough, though, as the csh is
also hungup, so you must kill -9 that as well.

SPECIFICS

Terminal	WYSE 60 (although we believe that it has occurred
			on other makes and models, we don't have
			the evidence to back this up)
Annex		Annex-UX
		Software Rel 2.1
		Harward Rev 1.4
		ROM Rev 0305
Sun-3/280S	Vanilla SunOS 3.4
Command		rlogin

TROUBLESHOOTING

The only thing that looks significant (to me) is that when the problem
occurs, a "netstat" on the annex shows

Active Connections
Proto	Recv-Q	Send-Q	Local Address		Foreign Address	(state)
tcp	0	71	(192.26.92.245).750	odin.login	ESTABLISHED

where the Send-Q (here, 71) grows by one each time you hit a key. Hence,
it seems that the input is being queued but is not being sent. Still,
thr problem could be at either end.

On "odin", a netstat shows that the Recv-Q and Send-Q of the same socket
are empty (which is expected).

On the annex, a "netstat -i" shows 1 alignment error, 1 interface
reset, and 29 TX DMA Underruns, but these numbers do not grow when
the problem reoccurs, so it seems unlikely that they have anything
to do with it. Likewise with some error counts under "netstat -s".

If there is a way to take force a crash dump on the Annex we don't
know what it is, and besides would be reluctant to do so while other
users were on it being productive.

If anyone has had similar difficulties, or even better, has some notion
of how to further troubleshoot this, we'd appreciate hearing from you.
We don't have ethernet diagnostic equipment, but this has the smell of
a software problem, almost like an XON/XOFF problem where the XON back
to the annex is getting lost (nope, we have yet to find any evidence of
this).

Again, the problem could be at either end.

Thanks for any hints at all.

-- john

John Sloan                     Wright State University Research Center
jsloan@SPOTS.Wright.Edu       3171 Research Blvd., Kettering, OH 45420
...!cbosgd!wright!jsloan               (513) 259-1384   (513) 873-2491
Logic Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
-- 
John Sloan                     Wright State University Research Center
jsloan@SPOTS.Wright.Edu       3171 Research Blvd., Kettering, OH 45420
...!cbosgd!wright!jsloan               (513) 259-1384   (513) 873-2491
Logic Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 21:17:51 GMT
From:      bkc@CLUTX.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Remote Virtual Disk


Help! I am looking for a program(s) that will redirect MS-DOS file I/O commands
to another system such as unix.  I have heard that there is a system somewhere
called Remote Virtual Disk (RVD) that allows a user to map an MS-DOS disk drive
to the root of a remote Unix system. Does anyone know where I can find this
software or something that does the same thing?

Please reply to 
Brad Clements
bkc@clutx.clarkson.edu
bkc@clutx.bitnet

Thanks!

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 22:24:33 GMT
From:      lekash@ORVILLE.NAS.NASA.GOV (John Lekashman)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP & TCP Precedence


	2 Questions about IP & TCP Precedence:
	
	(1) The IP Request For Comments (RFC-791) and IP Military Standard
	(MIL-STD-1777) specify that Type Of Service (TOS) including
	precedence is a parameter that can be passed from the upper layer
	protocols to IP during a SEND operation and can be passed from IP to
	the upper layer protocols during a RECEIVE operation.
	
	How many IP implementations support this?
	
	How many people actually use this?
	
I did a socket option to the kernel to allow a user program
to set different values for the type of service.   Currently
this only consists of allowing it to set the value of that
byte in the header.  My feeling is that this should have some sort
of abstraction of what sort of service is desired, and the
TCP will cause the IP layer to set this byte value appropriately.
The exact details of what sorts of service one might ask for,
and appropriate TOS byte settings for such are not worked out.

One major reason is attempting to figure out authentication 
mechanisms in a connectionless environment, ie preventing
every random who feels like it setting his own personal 
workstation to get high bandwidth, low delay, high reliability,
which then results in lossages to those who do the 'right thing'
whatever that happens to be.  Still, the setting allows us
to send ftp data traffic over satellite channels, and telnet,
acks and such over terrestrial lines.  (with appropriate software
switches in gateways and bridges.

Maybe we'll even use it beyond the lab one day, if we get 
smart enough TCP's everywhere, which deal with satellites well.

					john
	

	

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 88 23:25:41 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   MILNET/?/UMDNET/SURA/GWU-GATE traffic question

LANL is used by a number of folks on (or with access to) the Internet.
When they cannot 'telnet' to our hosts here, they start calling us up
and telling us how to do our job.  So far, none of the suggestions have
been very appealing.  The current problem causing some users grief manifests
itself as follows:

	1. A user on GWUVM.GWU.EDU attempts to telnet to MILNET-GW.LANL.GOV.
	2. The connection times out.
	3. The user is pissed and calls us up.

I have tried various things on our end to find out what is going on.  Here
are the things I found out when the problem was first reported:

	1. I could talk to GWUVM.GWU.EDU from our subnets but not
	   directly from MILNET-GW.LANL.GOV.
	   This made absolutely no sense.

	2. I sent 100 ICMP ECHO request's from MILNET-GW.LANL.GOV
	   and 100 reply's were received.  But, of the 100 reply's
	   received about 20% had DUPLICATE SEQUENCE NUMBERS!

I was getting curious.

	3. I sent a more sophisticated ICMP ECHO packet with out much
	   hope of a response.  This one is coded up with the IP RECORD
	   ROUTE option.  Some hosts on the Internet actually respond
	   to these, like our 4.3BSD hosts (a local modification),
	   and A.ISI.EDU.  I wish others would.

	   Low and Behold, back came the following IP header and option:

	   x00: x4f001400	IP header
	   x04: x86450000	    "
	   x08: x11010000	    "
	   x0c: x80a401ea	IP source	GWU-GATE host GWUVM.GWU.EDU
	   x10: x1a00005a 	IP destination 	MILNET host MILNET-GW.LANL.GOV
	   x14: x01072728	IP option field	NOP | RR option header
	   x18: x80080a0e	The		UMDNET host TRANTOR.UMD.EDU
	   x1c: x81020101 	route		UMD-BOGON-NET host 129.2.1.1
	   x20: x80a70101	traversed	SURA host 128.167.1.1
	   x24: x80a70201	as		SURA host 128.167.2.1
	   x28: x80a70102	far		SURA host 128.167.1.2
	   x2c: x80a72101	as		SURA host 128.167.33.1
	   x30: x80a72101	allowed		SURA host 128.167.33.1
	   x34: x80a72101	by		SURA host 128.167.33.1
	   x38: x80a72101	option.		SURA host 128.167.33.1

Unfortunately, thats all you get in an IP option.

So, what's going on?  For sure, if a packet has to hop around in the
SURA network before it (goes to/comes from) GWU-GATE, its going to take
some time.  Maybe get lost?  Maybe get duplicated?

What kind of network media/link levels do packets traverse here? I want to
make sure that LANL doesn't acquire (as in purchase) any hardware/protocols
that behave as above.  Maybe we already have.  Yikes!

Phil Wood  (cpw@lanl.gov)

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 01:48:42 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re:Remote Virtual Disk

That is the name of a protocol included in the MIT PC-IP distribution.
It allows creation of virtual DOS volumes on Unix systems, but 1) it
doesn't allow read/write sharing of those volumes, and 2) it requires
Unix source code and kernel modifications to install.  I've never used
it on a PC, but I've used Unices sharing disks via the same protocol,
and there were some unloveable aspects about spinup-spindown...

I don't know how you get the source for the Unix side.  I'd start
with the contact for PC-IP at MIT (the Microcomputer Office), and
see if they can help/redirect you.

jbvb

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jan 88 08:07:24 est
From:      snorthc@NSWC-OAS.ARPA
To:        bkc@clutx.clarkson.edu, tcp-ip@sri-nic.ARPA
Subject:   Re:  Remote Virtual Disk
I looked into RVD several months ago.  It is a large [code size] system
that does not appear to be in production use anywhere (rumored to still
be used in a UNIX host - UNIX host fashion at its birthplace, MIT).
I would suggest you consider one of the following commercial products:
	NFS;
	NetBios/TCP;
	Locus "DOS Merge".
(If my job depended on making the best choice I would choose NFS, if you
want the choice with the most future/potential choose NetBIOS/TCP)

	Best of luck, let us know how you work your problem out,
	Stephen Northcutt (snorthc@nswc-g.arpa)

Caveat: I have been looking at the problem you describe for several months
and am not completely satisfied with any of the alternatives.
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 04:23:13 GMT
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP on RSTS/E


While the display code and the network interface code (which live in
their own separate library modules) are rather dependent on
characteristics of the PC and DOS, I would say the rest of the code is
rather machine and OS independent even though small chunks of assembly
code would have to be rewritten for a given target machine.

I thought the PCIP code was developed under a Darpa grant for the DOS
environment but that the starting point was a package which ran under
PDP11 Unix and there is a comment in the tasking package to this effect.

However, once I asked Jerry Saltzer why the event flag was cleared by the
scheduler and not left for the task to clear so that useful information
could be passed via the event flag to the task and he mentioned in reply
that the tasking piece at least was running on Multics in 1966 (I may have
the year off) so that large chunks of the code have run in at least
3 different environments.  I think I saw that Tim Maroney ported the
code to the Macintosh so that chunks of PCIP have run in at least
4 very different environments.  

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 05:36:07 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  IP & TCP Precedence

Jim,

The fuzzball implementation supports TOS in IP and transport-level clients.
The mapping is controlled by arguments to the IP function calls. TOS is
interpreted by the queueing discipline as a priority, so that all IP packets
with a TOS octet value of x are serviced before any TOS with value x-1. There
are additional features for fairness and even a lie or two. The scheme should
not be considered as conforming to specification, but as an experiment in
queueing disciplines driven by pragmatic considerations. The NSFNET Backbone
presently supports this discipline, which is currently in evaluation.

Dave

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 06:00:07 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Virtual Disk

Brad:

Softronics offers a product called Softerm PC which includes a "seamless disk"
or "remote virtual disk" capability.  In release 2.00.09 of the software, I
was able to access the disk on our DDN gateway VAX running bsd 4.3.  They
were some problems with the implementation:

    1.  The procedure that you create for the "seamless disk" had to log
	you in to the correct account on the host system.  (MS-DOS wanted
	to interpret the "/" in the UNIX path name as a MS-DOS switch.)
    2.  The files name had to follow MS-DOS naming conventions and file
	name length restrictions.
    3.  The file name had to be all upper case characters unless you used
	the UNIX upper/lower case translation capability by logging in
	using upper case characters in which case you could access files
	with lower case names.

I currently use release 2.10.02 but haven't gotten around to retesting to
see if they corrected the above problems.

Merton Campbell Crockett

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1988 1359-EST
From:      franceus@TYCHO.ARPA  (Paul Franceus)
To:        tcp-ip at sri-nic.arpa
Subject:   TOD clock problem on Sun 3.
I have been reading this discussion with interest.  It seems that we have a very
interesting manifestation of this problem.  Here we have 4 Sun 3's (3 160s and a
260).  Two of the machines appear to be keeping proper time (the 260 and one of
the 160s) while the other 2 are both messed up.  Also, on the two that are 
wrong, the clock is skewing at different rates.  Seems rather strange to me,
does this make sense to anyone?

Paul Franceus
Natl. Computer Security Center
-------

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 10:31:23 GMT
From:      whna@cgch.UUCP (Heinz Naef)
To:        comp.protocols.tcp-ip,comp.sources.wanted,comp.unix.questions
Subject:   Application Programming Interface for FTP

Did anyone develop a (limited) FTP client, implemented as a C programming
library, usable from within application programs to allow them to request
standard FTP servers in the network to send or receive a file?

Do any standard semantics exist for such an application programming interface?

Any comments are welcome.

Regards,
Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.62, P.O.Box, CH-4002 Basel, Switzerland
uucp: cgch!whna - bitnet: whna%cgch.uucp@cernvax.bitnet
                  phone: (+41) 61 37 26 75
                  fax:   (+41) 61 36 43 54 (Attn: H.Naef, R-1032.5.62)

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 13:07:24 GMT
From:      snorthc@NSWC-OAS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Virtual Disk

I looked into RVD several months ago.  It is a large [code size] system
that does not appear to be in production use anywhere (rumored to still
be used in a UNIX host - UNIX host fashion at its birthplace, MIT).
I would suggest you consider one of the following commercial products:
	NFS;
	NetBios/TCP;
	Locus "DOS Merge".
(If my job depended on making the best choice I would choose NFS, if you
want the choice with the most future/potential choose NetBIOS/TCP)

	Best of luck, let us know how you work your problem out,
	Stephen Northcutt (snorthc@nswc-g.arpa)

Caveat: I have been looking at the problem you describe for several months
and am not completely satisfied with any of the alternatives.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 14:47:36 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Virtual Disk

Brad:

I forgot to mention in the previous missive that Softerm PC does not support
any of the TCP/IP suite of protocols but you do have your choice of

	1.  Crosstalk
	2.  Hayes-verify
	3.  Kermit
	4.  Softrans
	5.  Xmodem
	6   Xmodem-CRC

Softrans is a Softronics home-brew file transfer protocol with an encoding
algorithm which allows you to transfer 8 bit binary data over links which only
support 7 bit data transfers.  (They include source for Softrans so that you
can adapt it to your host system).

Merton Campbell Crockett

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 15:22:50 GMT
From:      zgel05@apctrc.UUCP (George E. Lehmann)
To:        comp.protocols.tcp-ip
Subject:   Spooky Routing by Sun TCP/IP

Tulsa, Oklahoma
Keywords: routing, tcp/ip, telnet, ftp


We have a bunch of Suns configured on several seperate nets something like:
            +-----------------+
            | VM running KNET |
            +-----------------+
                    |
     ---------------+----------+----------+--------------- 193.9.200 Ethernet
                               |          |
                           +---+---+  +---+---+
                           | Sun A |  | Sun B |
                           +---+---+  +---+---+
                               |          |
                    -----------+----------+--------- 193.9.202 Ethernet

We have a problem where VM tries to talk to Sun B using Sun A as a router,
but Sun B responds to VM using its 193.9.200 interface.  Since VM does not
have the 193.9.200 interface for Sun B defined, it ignores the response.

Questions: Is the Sun trying to be smart, recognizing it can get to the
193.9.200 net in one less hop by using a different interface to respond on?
If so, is there a way to turn off this smartness without unplugging the
second interface?

Any answers to these questions, or general enlightenment in this area will
be greatly appreciated.
-- 
George Lehmann,  ...!uunet!apctrc!zgel05
Amoco Production Co., PO BOX 3385, Tulsa, Ok  74102  ph:918-660-4066
Standard Disclaimer: Contents are my responsibility, not AMOCO's.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 16:12:36 GMT
From:      budd@bu-cs.BU.EDU (Philip Budne)
To:        comp.sys.encore,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Problems with Encore Annex server

Sun 3.4 has known TCP window problems.  I don't remember ever seeing
problems of this nature between our 280 and Annexen, but we did
between Sun 3.4 and WISCnet.  We now run 4.3 TCP code in our Suns.

Try using tcpdump to view the traffic between the two systems.

	Phil Budne, Boston University

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 18:59:00 GMT
From:      franceus@TYCHO.ARPA (Paul Franceus)
To:        comp.protocols.tcp-ip
Subject:   TOD clock problem on Sun 3.

I have been reading this discussion with interest.  It seems that we have a very
interesting manifestation of this problem.  Here we have 4 Sun 3's (3 160s and a
260).  Two of the machines appear to be keeping proper time (the 260 and one of
the 160s) while the other 2 are both messed up.  Also, on the two that are 
wrong, the clock is skewing at different rates.  Seems rather strange to me,
does this make sense to anyone?

Paul Franceus
Natl. Computer Security Center
-------

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 19:39:33 GMT
From:      nasa@ms.uky.edu (Eric Freeman)
To:        comp.protocols.tcp-ip
Subject:   ping with routing

I have heard of a version of ping that shows routing information.  If anyone
knows information about it or has it could they please mail it to me.  Much
thanks in advance.

				Eric Freeman

-------------------------------------------------------------------------------
			  	      
Eric Freeman		        	  		"A spirit with a vision
freeman@dftnic.gsfc.nasa.gov  		  		 is a dream with a 
freeman@ssvs.gsfc.nasa.gov				 mission"
nasa@e.ms.uky.edu					       Neil Peart

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 20:15:52 GMT
From:      nowicki@SUN.COM (Bill Nowicki)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote Virtual Disk


	I am looking for a program(s) that will redirect MS-DOS file
	I/O commands to another system such as unix.

Why not use PC-NFS? Just call 1-800-334-SUNM (1-800-334-7866) and give
them Master Card or Visa, and it will be shipped in 48 hours.  

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 20:42:06 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   ip/icmp/echo messages

While waiting for 4.3 BSD source code, I have been reading rfc's, etc, 
trying to figure out:

	 1)  whether icmp echo/reply messages can be sent with ip headers 
		 that specify strict source routing (via raw sockets only?),
	 2)  whether this would be useful in creating a looptest tool for 
		 customer service to check out specific serial links, and
	 3)  who has already implemented such an animal (probably only
		 about 50,000 people or so?).  I understand there's a program
		 called "ping" which uses echo.  Is it what I'm looking for?
		 Where can I get it?

Thanks in advance.

Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826           
Largo, FL, 34649-9981   

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 21:07:13 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   ARPANET UPGRADE


It has been determined that some ARPANET host sites have had difficulty cutting
over to the new End-to-End protocols (PSN 7.0).  For this reason, a
cut back to the old End-to-End protocols is being considered for
Sunday, 16 January.

Site representatives who feel this will cause disruption of network
services, user software changes, or need more time to prepare for the
cutover, are asked to contact Annette Bauman, ABauman@DDN1.ARPA,
(703) 285-5445/(AV) 356-5445 or Bobby Powell, SCCMGR@DDN1.ARPA, 
(703) 285-5228/(AV) 356-5228.  If no response is received by 14 January,
we will proceed as planned. 
-------

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 21:17:52 GMT
From:      tom@tsdiag.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Objectivity


Gary,

My comment directed at identifing the problem, not your product.
I am glad to hear your comments that the problem is being worked on.

I just don't like it when people say that X.25 is trash when the real problem
is the configuration a carrier will allow or problems with a vendor's product.

Good luck fixing the problem.
-- 
Thomas A. Moulton, W2VY          Life is too short to be mad about things.
Home: (201) 779-W2VY             Packet: w2vy@kd6th  Voice: 145.190 (r)
Work: (201) 492-4880 x3226       FAX:  (201) 493-9167
Concurrent Computer Corp.        uucp: ...!ihnp4!hotps!ka2qhd!w2vy

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 88 22:37:53 GMT
From:      ROMKEY@XX.LCS.MIT.EDU (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP on RSTS/E

> All fine, except that PC-IP is 1) dependent on an 18 ticks/sec clock in a
> lot of places 2) very 808x-dependent in the tasking, timer and display
> modules and 3) has a built-in hardware driver which would need a complete
> re-write for another interface/architecture.  The problem with RSTS is

It's not *that* much of a problem. The 18 ticks/second clock is parametrized
in a constant in a header file so that all references to ticks can
be done as seconds * (ticks/second). It's not really a problem through
most of the code.

The 8086 dependencies are simply that there's some assembly code. In
the tasking package, you need to rewrite the code which does a context
switch. The timer code isn't 8086 dependent, and anyone who might be
porting PC/IP to another system would probably through out the entire
display package, anyway.

Any hardware drivers would have to be rewritten from scratch, anyway, since
it's a different set of hardware.

PC/IP origially ran on a PDP-11. If porting it back to a PDP-11 turns out
to be difficult, it shouldn't be because of architectural problems
or because of 8086 dependencies. PC/IP was derived from the PDP-11
V6 Unix code Mike Patton mentioned in a later message. I don't know if you
can still find someone at MIT who can or will give you that code.
				- john romkey
-------

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 00:23:32 GMT
From:      DLE@CSL.SRI.COM (David L. Edwards)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with Encore Annex server


The TCP window problem in Sun 3.4 has been patched by Sun.  The problem
was that it was possible to get a negative window size which some
hosts, such as Tops-20, would hang the connection. 

The Sun bug fix ID is unix/3.4/kernel/tcp.seq.  The bug report
number was 1006132 and it was fixed in 3.4.2.  It is available
via anonymous FTP from several places.

David Edwards, SRI International

-------

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1988 05:55-EST
From:      GBELING@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Cc:        GBELING@A.ISI.EDU
Subject:   laep time units
hi, 
that was an interesting discussion on problems we encountered too with our 
sun zoo. but suddenly the leap-second leped to my eye: what does the 
german watch maker industry about this problem? 
so i leaped to the conclusion to ask somebody about this. 
what i got back was no answer but a question:
  
from the cuickoo clock cuckoos labor union:
unfortunately this leap second falls just in the time of our greatest 
activity. because we cannot break what shall we do in this additional time?
play leapfrog with ourselves??? 
  
this leads me to another reason for this additional time unit: 
for me as an user this is just introduced to make me look older than i am. 
regards gerd beling FRG
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 03:17:30 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: IP & TCP Precedence

Jim,  As you must have figured out by now, no one supports the precedence
and TOS fileds in any meaningful way.  Those fileds were defined 15 years
ago because they knew they had to be reserved up front if anyone could
ever figure out how to use the information they purport to convey.
Now we finally see one soul (Dave Mills, the tireless experimenter) using
those fields to see if he can make some improvements in gateway behaviour.

The trouble is that everyone has to play the "game" if those parameters
are ever to have any use.  The ISO equivalent protocols have also
defined those parameters and I see no use of them there, either.

Dan
-------

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1988 0918-EST
From:      hsw@TYCHO.ARPA  (Howard Weiss)
To:        tcp-ip at sri-nic.arpa
Subject:   Official Sun Patch for TOD problems.

	I received this message via the UNIX-WIZARDS mailing list and it
looks like it was not distributed to TCP-IP.  This is claimed to be
the official SUN patch for Sun OS 3.2, 3.3, 3.4, 3.5.

Howard Weiss

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


From: Chuq Von Rospach <chuq@plaid.Sun.COM>
Subject: Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!
Date: 5 Jan 88 21:57:40 GMT
Sender: news@sun.uucp
Keywords: TOD, clock, ntp, date
To:       unix-wizards@SEM.BRL.MIL

In article <5203@columbia.edu> dupuy@columbia.edu (Alexander Dupuy) writes:
>Ever since the leap second (23:59:60 GMT Jan 1, 1988) the realtime clocks on
>Sun-3s have been behaving strangely.  When booting /vmunix, just after the
>message about using nn buffers, the kernel prints out a little message like the
>above.

here's the official sun3 patch. The official sun4 patch will be posted as
soon as it gets released and I get approval.

Chuq
Sun Tech Support
============================================
There exists a problem for all Sun3 (68020) machines running SunOS
Releases 3.0-3.5, 4.0beta1, and all Sun4 (SPARC) machines running SunOS
Release Sys4-3.2 FCS and 4.0beta1.

As of Jan 1 00:00 1988, the clock routine in the kernel will put the
clock chip into an uncertain state if you attempt to set the date.
The visible effects of this is to 1) cause the message

        WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

to appear while booting vmunix, and to 2) cause the system date to start
to drift widely. Any attempts to actually *set* the date will have only a
temporary effect (i.e., the date you set will be good for about 30 seconds).

In order to solve this problem, you must patch both the kernel and system
object files.

==============================================================================

          Sun3 System Patch
          Releases 3.2, 3.3, 3.4, 3.5

As root, run the follwing command:

          echo 'resettodr+c0?i' | adb /vmunix - | grep reset

You should see the following printed out:

          _resettodr+c0:      bnes      _resettodr+0xca

If you see instead:

          _resettodr+c0:      bnes      _resettodr+0xce

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following commands:

          cp /sys/OBJ/clock.o /sys/OBJ/clock.o-
          echo 'resettodr+c0?w 660c' | adb -w /sys/OBJ/clock.o

          echo 'resettodr+c0?w 660c' | adb -w /vmunix

Reboot and then *set* the date.

If you build kernels for your system, also rebuild your kernel.

Chuq "Fixed in 4.0" Von Rospach                   chuq@sun.COM                  Delphi: CHUQ

                       What do you mean 'You don't really want to hurt her?'
                                    I'm a Super-Villian! That's my Schtick!

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

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Thu 7 Jan 88 13:09:50-PST
From:      Doug <Faunt@SPAR-20.SPAR.SLB.COM>
To:        DLE@CSL.SRI.COM
Cc:        budd@BU-CS.BU.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Problems with Encore Annex server
We got that, thanks. 
-------
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu 7 Jan 88 14:10:47-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Stevens@A.ISI.EDU
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: IP & TCP Precedence
Why do you ask?
-------
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 10:09:28 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: MILNET/?/UMDNET/SURA/GWU-GATE traffic question


You're being misled by one of the technical differences between SURANET
and MILNET.  GWUVM is a host (128.164.1.234) on one of the campus
networks (128.164) connected via SURANET (128.167) to the rest of the
Internet. SURANET, like most (but not all) mid-level nets in the NSFNET,
is composed of IP routers (in SURANET'S case, Proteon P4200s) linked
together by serial lines.

What Record Route is showing you is the packet traveling from
128.167.33.1 - presumably the GWU_campus_net-to-SURANET P4200 gateway at
GWU - (but why it spent so much time there I don't understand) to
128.167.11.2 - the next P4200 (which happens to be at NSF) - to the
principal node of SURANET at University of Maryland, College Park, where
it is loaded onto MILNET. That is in fact the most direct route there
is.  Thereafter, there is quite possibly as much "hopping around" on the
packet's way to LANL via MILNET, but because MILNET uses a distinct
communications subnet (based on the PSNs) that operates below the
IP level, that's all invisible to Record Route.  I.e., since P4200s are
gateways as well as packet switches, each has a "host" number and so
leaves a fewmet for Record Route, but Record Route can't see the MILNET
packet switches.

From just behind the SURANET gateway at NSF, I see RTTs of 1500 ms or so
to MILNET-GW.LANL.GOV; this seems totally unreasonable.  Perhaps there
is congestion at the UMd gateway to MILNET which, combined with the
suspect behavior of the SURANET gateway at GWU, might cause your users'
connections to time out.  I suspect the SURANET folks are conducting
their own investigation and we'll hear from them in due course...

-s

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 10:55:00 GMT
From:      GBELING@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   laep time units

hi, 
that was an interesting discussion on problems we encountered too with our 
sun zoo. but suddenly the leap-second leped to my eye: what does the 
german watch maker industry about this problem? 
so i leaped to the conclusion to ask somebody about this. 
what i got back was no answer but a question:
  
from the cuickoo clock cuckoos labor union:
unfortunately this leap second falls just in the time of our greatest 
activity. because we cannot break what shall we do in this additional time?
play leapfrog with ourselves??? 
  
this leads me to another reason for this additional time unit: 
for me as an user this is just introduced to make me look older than i am. 
regards gerd beling FRG

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jan 88 16:01 5
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Happy New Year and   *  h e l p  *
     Happy New Year and I have a question.

     We have a back bone ethernet around the campus.  Off of this is the 
occasional diskless workstation farm.  These are Sun systems.  That's 
the topology.

     We also have a set of Class B internet addresses.  The back bone 
has been given a subset of these addresses and we want to use a 
different subset for the off back bone diskless systems.  

     We have been waiting for Sun OS 3.4 to come so that we could use 
subnets which seems to be the solution to separating things.  We now 
have 3.4 but can't get any of the diskless wonders to boot when we put 
the class B addresses up.  HOWEVER, booting seems to work just fine when
the diskless ethernet segments are given a class C address and the back
bone a class B address.  We believe we are having a tough time making
Sun OS 3.4 work with subnets but aren't sure.  It's hard to tell with
UNIX and we only have a moderate level of expertise here. 

     One more fly in the ointment is that we have a ComputerVision 
system which is a Sun diskless wonder farm off a disk server which is 
running Sun OS 3.2 and isn't likely to change any time soon. 
ComputerVision is a little behind. 

     Question:

     1) Has anybody made subnets or a similar configuration to the 
        above work with Sun OS 3.4?  If so, HOW? (*help*)

                             or

     2) If I bring this mess up with class B addresses on the back bone
        and class C addresses on the diskless segments, will packets  
        with class C addresses ever escape on to the back bone?  These 
        diskless systems are to be allowed to log in to other machines 
        which are on the back bone.  The problem is that we are 
        scheduled to be connected to JVNCNet REAL soon and I don't want 
        addressing snafus because we can't get Sun OS to work or because 
        it doesn't work.  Right now I very willing to believe that 
        problem is us and not Sun but one never knows.


                          * h e l p *

Chris Johnson
Northeastern University.
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 13:50:47 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   Re: ping with routing

In article <7987@g.ms.uky.edu> nasa@ms.uky.edu (Eric Freeman) writes:
:I have heard of a version of ping that shows routing information.  If anyone
:knows information about it or has it could they please mail it to me.  Much
:thanks in advance.

Me too, please.

Larry Swift                     UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 14:18:00 GMT
From:      hsw@TYCHO.ARPA (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   Official Sun Patch for TOD problems.


	I received this message via the UNIX-WIZARDS mailing list and it
looks like it was not distributed to TCP-IP.  This is claimed to be
the official SUN patch for Sun OS 3.2, 3.3, 3.4, 3.5.

Howard Weiss

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


From: Chuq Von Rospach <chuq@plaid.Sun.COM>
Subject: Re: WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!
Date: 5 Jan 88 21:57:40 GMT
Sender: news@sun.uucp
Keywords: TOD, clock, ntp, date
To:       unix-wizards@SEM.BRL.MIL

In article <5203@columbia.edu> dupuy@columbia.edu (Alexander Dupuy) writes:
>Ever since the leap second (23:59:60 GMT Jan 1, 1988) the realtime clocks on
>Sun-3s have been behaving strangely.  When booting /vmunix, just after the
>message about using nn buffers, the kernel prints out a little message like the
>above.

here's the official sun3 patch. The official sun4 patch will be posted as
soon as it gets released and I get approval.

Chuq
Sun Tech Support
============================================
There exists a problem for all Sun3 (68020) machines running SunOS
Releases 3.0-3.5, 4.0beta1, and all Sun4 (SPARC) machines running SunOS
Release Sys4-3.2 FCS and 4.0beta1.

As of Jan 1 00:00 1988, the clock routine in the kernel will put the
clock chip into an uncertain state if you attempt to set the date.
The visible effects of this is to 1) cause the message

        WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!

to appear while booting vmunix, and to 2) cause the system date to start
to drift widely. Any attempts to actually *set* the date will have only a
temporary effect (i.e., the date you set will be good for about 30 seconds).

In order to solve this problem, you must patch both the kernel and system
object files.

==============================================================================

          Sun3 System Patch
          Releases 3.2, 3.3, 3.4, 3.5

As root, run the follwing command:

          echo 'resettodr+c0?i' | adb /vmunix - | grep reset

You should see the following printed out:

          _resettodr+c0:      bnes      _resettodr+0xca

If you see instead:

          _resettodr+c0:      bnes      _resettodr+0xce

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following commands:

          cp /sys/OBJ/clock.o /sys/OBJ/clock.o-
          echo 'resettodr+c0?w 660c' | adb -w /sys/OBJ/clock.o

          echo 'resettodr+c0?w 660c' | adb -w /vmunix

Reboot and then *set* the date.

If you build kernels for your system, also rebuild your kernel.

Chuq "Fixed in 4.0" Von Rospach                   chuq@sun.COM                  Delphi: CHUQ

                       What do you mean 'You don't really want to hurt her?'
                                    I'm a Super-Villian! That's my Schtick!

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

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 15:56:00 GMT
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.")
To:        comp.protocols.tcp-ip
Subject:   Happy New Year and   *  h e l p  *


     Happy New Year and I have a question.

     We have a back bone ethernet around the campus.  Off of this is the 
occasional diskless workstation farm.  These are Sun systems.  That's 
the topology.

     We also have a set of Class B internet addresses.  The back bone 
has been given a subset of these addresses and we want to use a 
different subset for the off back bone diskless systems.  

     We have been waiting for Sun OS 3.4 to come so that we could use 
subnets which seems to be the solution to separating things.  We now 
have 3.4 but can't get any of the diskless wonders to boot when we put 
the class B addresses up.  HOWEVER, booting seems to work just fine when
the diskless ethernet segments are given a class C address and the back
bone a class B address.  We believe we are having a tough time making
Sun OS 3.4 work with subnets but aren't sure.  It's hard to tell with
UNIX and we only have a moderate level of expertise here. 

     One more fly in the ointment is that we have a ComputerVision 
system which is a Sun diskless wonder farm off a disk server which is 
running Sun OS 3.2 and isn't likely to change any time soon. 
ComputerVision is a little behind. 

     Question:

     1) Has anybody made subnets or a similar configuration to the 
        above work with Sun OS 3.4?  If so, HOW? (*help*)

                             or

     2) If I bring this mess up with class B addresses on the back bone
        and class C addresses on the diskless segments, will packets  
        with class C addresses ever escape on to the back bone?  These 
        diskless systems are to be allowed to log in to other machines 
        which are on the back bone.  The problem is that we are 
        scheduled to be connected to JVNCNet REAL soon and I don't want 
        addressing snafus because we can't get Sun OS to work or because 
        it doesn't work.  Right now I very willing to believe that 
        problem is us and not Sun but one never knows.


                          * h e l p *

Chris Johnson
Northeastern University.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 15:58:44 GMT
From:      ncs-med!pwcs!quest!cnt!rod@umn-cs.arpa  (rod merry)
To:        tcp-ip@sri-nic.arpa
Subject:   gated/RIP info request
I'm looking for background information, specs, RFCs, or source on
the protocols supported by "gated".  My understanding is that RIP
is among these, if not, I'm real interested in getting info on it
too.  Please respond directly and I will summarize.

Thanks in advance
rod
-- 
Rod Merry                               rod@cnt.MN.ORG
Computer Network Technology             {quest|meccts}!cnt!rod
9440 Science Center Drive		     
Minneapolis, MN 55428                        (612)535-8111
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 16:08:59 GMT
From:      jbs@eddie.MIT.EDU (Jeff Siegal)
To:        comp.protocols.tcp-ip
Subject:   RARP or BOOTP for BSD wanted

We need one of these protocols so our Cisco terminal server can
determine its IP address when it boots up.  Any suggestions?

Jeff Siegal

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 17:46:52 GMT
From:      hedrick@aramis.rutgers.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   bootp/rarp

I am sending a copy of bootp to Jeff under separate cover.  We recommend
using bootp rather than rarp where possible:
  - it is designed to go through gateways.  You can boot a large
	network of cisco equipment from a single boot host (or from
	more than one, as long as they are all on one subnet) if
	if want to.  THis may be convenient for networks where it
	is not practical to have servers at each location.
  - it does not need a kernel change to install.  Rarp does not use
	TCP or UDP, so you need to hack some kernel tables if your
	system doesn't already implement it.  Note that Sun, which
	does claim to implement it, often can't be used to boot
	cisco equipment, because Sun's RARP drops all but one request
	when it gets several at once.
Bootp requests that your kernel have an ioctl to install a new
ARP table entry.  This is needed in order to get the response back
to the requestor.  Obviously the requestor is not yet in a position
to respond to an ARP request.  4.3, and most vendor-supplied versions
of 4.2, has such a call.

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 18:08:04 GMT
From:      vasilis+@andrew.cmu.EDU (Vasilis Apostolides)
To:        comp.protocols.tcp-ip
Subject:   Re: Official Sun Patch for TOD problems.


Thanks, since I now subscribe to the tcp-ip bboard it isn't necessary to mail 
me more related stuff. Anyway, the official Sun patch doesn't help us since it 
only covers versions 3.2 and there after (so binary patch doesn't directly 
apply to older suns -- v3.0!)

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 19:33:22 GMT
From:      chuq@plaid.Sun.COM (Chuq Von Rospach)
To:        comp.protocols.tcp-ip
Subject:   Sun TOD Clock bug Patches for all releases

[These are the official patches from Sun for all known affected releases
 in the field. If you have any questions or problems, please call Sun
 Tech Support]

There exists a problem for all Sun3 (68020) machines running SunOS
Releases 3.0-3.5, and all Sun4 (SPARC) machines running SunOS
Release Sys4-3.2 FCS and Sys4-3.2L GAMMA. This problem does not
exist for Sun-2's.

As of Jan 1 00:00 1988, the clock routine in the kernel will put the
clock chip into an uncertain state if you attempt to set the date.
The visible effects of this is to 1) cause the message
  
        WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE!  
  
to appear while booting vmunix, and to 2) cause the system date to start
to drift widely. Any attempts to actually *set* the date will have only a
temporary effect (i.e., the date you set will be good for about 30 seconds).
  
In order to solve this problem, you must patch both the kernel and system
object files.

==============================================================================

	Sun3 System Patch
	Releases 3.2, 3.3, 3.4, 3.5
  
  This is for Diskful and Server Machines only. Diskless machines need to
  be fixed on the server.

As root, run the follwing command:

	echo 'resettodr+c0?i' | adb /vmunix - | grep reset

You should see the following printed out:

	_resettodr+c0:	bnes	_resettodr+0xca

If you see instead:

	_resettodr+c0:	bnes	_resettodr+0xce

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following commands:

	echo 'resettodr+c0?w 660c' | adb -w /vmunix

Reboot and then *set* the date.

If you build kernels for your system, or are a server for diskless clients,
do, as root

	cp /sys/OBJ/clock.o /sys/OBJ/clock.o- 
	echo 'resettodr+c0?w 660c' | adb -w /sys/OBJ/clock.o


and then rebuild your kernel and/or the kernels for your diskless clients.

==============================================================================

        Sun3 System Patch
	Release SunOS Release 3.0

  This is for Diskful and Server Machines only. Diskless machines need to
  be fixed on the server.

As root, run the following command:

        echo 'todset+0xb4?i' | adb /vmunix -

You should see the following printed out:

        _todset+0xb4:   bnes    _todset+0xbe

If you see instead:

        _todset+0xb4:   bnes    _todset+0xc2

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following command:

        echo 'todset+0xb4?w 0x660c' | adb -w /vmunix

Reboot and then *set* the date.

If you build kernels for your system, or are a server for diskless clients,
do, as root

        cp /sys/OBJ/clock.o /sys/OBJ/clock.o-
        echo 'todset+0xb4?w 0x660c' | adb -w /sys/OBJ/clock.o

and then rebuild your kernel and/or the kernels for your diskless clients.

==============================================================================

	Sun4 System Patch
	Release Sys4-3.2 FCS, Sys4-3.2L GAMMA
  
  This is for Diskful and Server Machines only. Diskless machines need to
  be fixed on the server.
	
	echo 'resettodr+0x110?i' | adb /vmunix -

You should see the following printed out:

	_resettodr+0x110:               sub     %i5, 0x1, %i5

If you see instead:

	_resettodr+0x110:               sub     %i5, 0x0, %i5

the patch has already been applied to this system.
Proceed with the rest of the patch procedure anyway!

If you do not see either of these messages, go no further with this patch,
and please contact Sun Microsystems Customer Service.

If you do see either of those messages, then run, as root,
the following command:

	echo 'resettodr+0x110?W ba276000' | adb -w -k /vmunix /dev/mem

Reboot and then *set* the date.

If you build kernels for your system, or are a server for diskless clients,
do, as root

	cp /sys/sun4/OBJ/clock.o /sys/sun4/OBJ/clock.o- 
	echo 'resettodr+0x110?W ba276000' | adb -w /sys/sun4/OBJ/clock.o 

and then rebuild your kernel and/or the kernels for your diskless clients.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 88 20:23:58 GMT
From:      larry@sbo.UUCP (Larry Mullen)
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Virtual Disk


	We also market a product to provide a virtual disk for PCs. The
name is PC Interface. It supports multiple PCs over RS232, or LAN under tcp/ip,
or xns. It will allow the PC users to set up multiple virtual disks on our
Unix system, based on a Unix login and password. Users can also use the PCs
as virtual terminals. Apparently, it was developed by Locus, but part of it 
must be ported to the Unix which you connect to.

							Larry Mullen

							...mot!nud!sbo!larry

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jan 88 01:33:52 EST
From:      gross@gateway.mitre.org (Phill Gross)
To:        tcp-ip@sri-nic.arpa
Subject:   Leaping Lizards

Since the leaptime issue has hung around until Christmas (for Orthodox 
Christians, that is), I thought it would be appropriate to give wider 
distribution to a private note I exchanged earlier.  (The note below 
was originally in response to a comment about "Pope Julian's" calendar.)

> Actually, it was Pope Gregory XIII who, in 1582, revised the Julian calendar
> by lopping out 10 days.  He declared that Oct 5th, 1582 would become Oct
> 15th.  The extra ten days had accumulated because the year is actually 
> 365.2425 solar days long, not 365.25 as Caesar and all our elementary 
> school texts claim.  (Actually, the year is 365 days, 5 hours, 48 minutes 
> and 48 seconds, which is 365.242216 solar days, but who's to quibble?)
>