|
|
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 invasionGee, 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 invasionAs 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 DiskThat 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?) >