|
|
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?) > > This means that under Caesar's rules, in every century you were adding about > .75 too many days. By the 1500's, this amounted to approximately the > aforementioned 10 days. To keep things straight in the future, Gregory > added the rule that henceforth centesimal years would be leap years only > when divisible by 400. This cleverly means that you only add 97 days every > 400 years, instead of 100, which is more like it (.2425 x 400 = 97). > > Of course, Britain and the colonies didn't catch on until September 1752, > which meant they had to chop out 11 days (try typing `cal 1752' on your local > Unix box). This plays havoc with the biographers of our founding fathers, > most of whom were born before the British date switch but died after it. > Since the Eastern Orthodox and the Roman Catholics had mutually > excommunicated each other, Russia didn't catch on until after the 1917 > revolution. >
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 7 Jan 88 22:22:54 GMT From: jth@cuuxb.ATT.COM (6414~) To: comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: What is the procedure to simulate the limits of protocols?
In article <4431@caip.rutgers.edu> schen@caip.rutgers.edu (Shin Chen) writes: > >I would like know how one goes about finding the theoretical and real >limits (maximum, minimum,and average) of various protocols. This includes >equipment, methodology and/or ideas. >- Shin Chen Misha Shwarz of Columbia University has written a good text on the subject. It's more on the analysis side but it's part of the answer to your question. Protocol venders should be able to provide benchmark data (caveat emptor) on their products. Joe Heneghan
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 7 Jan 88 22:41:14 GMT From: ROMKEY@XX.LCS.MIT.EDU (John Romkey) To: comp.protocols.tcp-ip Subject: Re: Remote Virtual Disk
A recent message contained some disinformation about RVD. RVD is the Remote Virtual Disk protocol, which was designed and implemented at the MIT Lab for Computer Science several years ago. It is a DISK sharing protocol rather than a FILE sharing protocol. It sends requests to a server for reading and writing disk blocks by offset into the disk. Because it is a disk sharing protocol, it sits below the filesystem, so although you could share a disk between a UNIX and an MS-DOS system, it wouldn't be useful because there would either be a UNIX or an MS-DOS filesystem on that disk that one of the two systems wouldn't understand. RVD was originally written for 4.2BSD. The VAXen at LCS all had small disks (RK07's) and we wanted to have some disk servers to share things like UNIX which didn't change very often, and to have some large private disks for individual projects. RVD doesn't provide any synchronization between disk accesses. Since synchronization would really have to occur at a filesystem level and RVD is below the filesystem, this is fairly reasonable. RVD allowed disks to be accessed as read only or read write (shared or exclusive). Nobody ever wrote the companion synchronization protocol that would be needed to allow multiple writers, so we never used it in this mode. Also, RVD was never a part of PC/IP. I wrote a PC/IP RVD client as a hack, and a few people around LCS started using it. But we never got RVD packaged up and stabilized as much as we felt was necessary in order to include it in PC/IP, largely because of all the UNIX modications that were necessary. There were some references to it in the PC/IP documentation, though. I don't believe that MIT ever had an 'official' release of RVD, though a few copies were slipped to people. Anyway, RVD is not useful for sharing filesystems between UNIX and MS-DOS because it's a disk protocol and not a file protocol, and because it wouldn't allow multiple writers. To get back to the desired goal, I would recommend one of two approaches: NFS - currently only available from Sun or SMB over NETBIOS - put up a NETBIOS SMB server on the UNIX system and get NETBIOS for the PC and run the PC LAN program. NETBIOS for the PC is available from many vendors and there are a few people out there working on it for UNIX (try Syntax). - john romkey -------
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 7 Jan 88 23:42:39 GMT From: beadel@OSWEGO.OSWEGO.EDU (Edward.F.Beadel@oswego.oswego.edu, Jr.) To: comp.protocols.tcp-ip Subject: Re: Need TCP/IP on RSTS/E
>> ... 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.
In the RSTS/E V9.4 Programming Manual (DEC Order Number AA-EZ09A-TC {
including AD-EZ09A-T1,T2}) the aboved problem is addressed: " In order to
increase the flexibility of Ethernet on RSTS/E, DIGITAL has provided a
direct interface to the Ethernet data link layer for RSTS/E users. This
interface resembles the interface provided for the DMC/DMR communications
devices, and can be programmed with or without DECnet/E on the system."
(page 11-3)
This allows use of both UNIBUS controllers (DELUA and DEUNA) as device XE:
and the Q-bus controller (DEQNA) as device XH:.
Edward F. Beadel, Jr.
RSTS SIG Steering Committee
UNIGIG rep to DECUS PDP-11 Task Force
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 00:49:50 GMT From: BILLW@MATHOM.CISCO.COM (William Westfield) To: comp.protocols.tcp-ip Subject: Xerox's XNS protocols....
Is there on line documentation anywhere for the XNS protocols ? At the moment, Id especially like to get a sort of overview on how the whole thing works... Thanks Bill W -------
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 00:58:20 GMT From: Stevens@A.ISI.EDU (Jim Stevens) To: comp.protocols.tcp-ip Subject: Why IP & TCP Precedence Query
Michael Padlipsky wanted to know why I asked about IP & TCP Precedence. Well, I am trying (for quite a while now actually) to complete an RFC on a new protocol called Transaction Transport Protocol (TTP). TTP differs from TCP and UDP by providing reliable message delivery instead of reliable byte stream or unreliable packet delivery. Anyway, one of the optional TTP services is precedence and preemption. Note that the optional TTP service is more than just a field reservation since the draft TTP RFC actually describes the processing which is performed at the TTP level based upon the TOS. I propose to get the priority level out of the precedence field within the IP Type Of Service (TOS) field. In fact, my TTP packet format includes the IP TOS within the TTP pseudo header of information which is obtained from the IP layer and is TTP checksummed (similar to UDP & TCP pseudo headers except that the zero octet is replaced by the IP TOS). My question to the TCP-IP distribution list was prompted when a reviewer questioned whether the IP TOS field was available from all IP implementations. Since no one has said otherwise, I presume that the IP TOS is available in all IP implementations. As pointed out by John Lekashman <lekash@orville.nas.nasa.gov>, authentication is required for fair TOS processing by IP to prevent people from setting their priority to the highest possible and thus hogging the network. Also as pointed out by Dan Lynch <LYNCH@A.ISI.EDU>, the IP TOS processing would have to be implemented by everyone if the TOS parameters are ever to have any use. I feel that precedence makes more sense at the Transport Level since the authentication issues are simpler than at the Internet Level and also since fewer people would have to implement precedence for it to make sense. Jim P.S I have been asked if I could forward any responses I got to the TCP-IP distribution list. Well so far all of the responses that I have received were also CC'd to the list. P.P.S I feel that there is a flaw to TCP's use of precedence and security. The TCP Military Standard (MIL-STD-1778) specifies the processing to be performed based upon the IP precedence field and security options. (I believe that the TCP RFC also specifies the use of the IP TOS and Security options but do not have a copy of the RFC with me to check right now). The use of the IP fields is fine and dandy since it is a standard and since it saves space in the TCP header. Unfortunately, TCP does not checksum the IP precedence field or the security options. Thus these fields could have been changed or corrupted en route between the 2 TCP implementations and this change would not be detected by TCP. You could say that the IP header checksum would detect this sort of error. Well if we must depend upon the IP header checksum why does TCP have a checksummed pseudo header at all? I am sure that the reason we have the TCP pseudo header is to detect if IP corrupted the addresses and protocol number. I am also sure that the reason why the TCP pseudo header does not include the precedence and security fields is just an oversight. -------
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 01:01:11 GMT From: andre@nrc-ut.UUCP (Andre' Hut) To: comp.protocols.tcp-ip Subject: Re: WWV update
In article <8712241814.AA06202@trantor.UMD.EDU> louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") writes:
>Hey, if we're gonna insist on an advance-warning-leap-second, then we really
>should insist on having the YEAR be transmitted as well. Please!
Yeah! And how about a checksum too? Every once and awhile, my heathkit clock sets itself to
the "correct" time, but it is several hours off.
--
-----------------------------------------------------------------------------
sdcsvax-\ ihnp4-\
\ \
Andre' Hut sdcrdcf!psivax!nrcvax!nrc-ut!andre
/ / /
hplabs--/ ucbvax!calma-/ /
utah-gr!uplherc/
Network Research Corporation
923 Executive Park Dr. Suite C
Salt Lake City, Utah 84117
-----------------------------------------------------------------------------
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 06:16:25 GMT From: gamiddleton@watmath.waterloo.edu (Guy Middleton) To: comp.protocols.tcp-ip Subject: where to get POP?
I know this has been discussed here before, but I can't find my copy. Can anybody tell me where to get POP (and what it does, exactly)? Thanks. -Guy Middleton, University of Waterloo Institute for Computer Research gamiddleton@math.waterloo.edu, watmath!gamiddleton
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 08:08:06 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Leaping Lizards
Phill, Wonderful, I love it! Now, we have something going. Pure Science and Pure History have to be one and the same. My Wife, the History Major, salutes you. Remeber, the Roman roads go straight as the arrow and do bob from bot to top; however, the Scots, being more sneaky, snake form side to side... Dave
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 13:14:32 GMT From: steve@BRILLIG.UMD.EDU (Steve D. Miller) To: comp.protocols.tcp-ip Subject: Re: MILNET/?/UMDNET/SURA/GWU-GATE traffic question
Subject: Re: MILNET/?/UMDNET/SURA/GWU-GATE traffic question From: Stephen Wolff <steve@note.nsf.gov> 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. Indeed, that is the most direct route there is. However, one of the restrictions under which we at UMCP operate is that we can never ever forward packets from ARPANET, NSFNET, SURANET, et al. directly to MILNET. (Otherwise, we'd effectively be a mailbridge.) The only packets that can cross our MILNET gateway are those with an IP source address on network 128.8. (There is a hack in the kernel on maryland-gw.arpa (a 4.3BSD host) that enforces this restriction.) A quick peek at the UMCP ARPANET gateways tells me that they're routing MILNET traffic via DCEC-MILNET-GW.ARPA, at least for the moment. I don't have access to the UMCP SURANET gateways, so I don't know exactly what they want to do with MILNET traffic, but I assume they send it to the ARPANET gateways. If someone from SURANET is reading this, and could check the routing, that would be good... -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 14:34:44 GMT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: Application Programming Interface for FTP
Yes, I have such a thing (I think), I'll mail it to you under a separate letter when I dig it out. -Ron
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 14:47:24 GMT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: Happy New Year and * h e l p *
We have much the same situation and are also on JvNCnet. We just run 3.2 on everything and tell them that they are on a class B net and let the routers do ARP spoofing. We use CISCO, but most of the popular gateways support this mode of operation. The only area where any level of trickery arises is when a host has interfaces on two subnet cables. All of our Suns run 3.2. We decided to hold out until 4.0 rather than spending the semester debugging 3.4 which doesn't really offer any increased features (just bugs). -Ron
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 16:51:38 GMT From: ron@MANTA.NOSC.MIL (Ron Broersma) To: comp.protocols.tcp-ip Subject: Re: Happy New Year and * h e l p *
I have had similar (painful) experiences with trying to get the subnet support on Sun OS 3.4 to work. I saw similar problems with the early attempts at getting subnets in 4.2 BSD and I assume that the Sun code has the same problems. I was able to fix the 4.2 problems because I had sources for it. I don't have Sun sources so I have had a hard time isolating the problem in Sun OS. Of course, all these problems were fixed in 4.3 which supports subnets very well in my experience. From what I can tell, it looks like the routing code is very braindamaged. On a host with multiple interfaces on the same Class B net (but all on different subnets) it cannot seem to figure out what's the right net interface to use when installing a route. It often gets the wrong one. I also found that I had to turn off routed because it was making important routes just disappear. At this point I've sort of given up on subnet support in Sun OS until my sources arrive (soon, I hope). Once I have sources I'm sure I'll be able to track down the problem and get a better understanding of what's going on. --Ron (ron@nosc.mil)
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 16:54:34 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Net Management meeting on Jan 21
There will be a meeting of the network management working group to describe the work in process and delineate schedules for accomplishments in this year. The final agenda wil be announced by Jan 15. The meeting will take place at the Santa Clara Marriott hotel (on the corner of Great America Parkway and Mission College Blvd in Santa Clara. It is about 5 miles from San Jose airport.) If you wish to attend please send me a message or call anyone at Advanced Computing Environments (408-996-2042) to sign up for the meeting. This meeting is open to all and is scheduled to run from 9-5. Dan -------
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 17:48:09 GMT From: jimbys@tybalt.caltech.edu (James V. Bys) To: tcp-ip@sri-nic.arpa Subject: tn3270
A while ago there was posted (I hope in this newsgroup) the location of a tn3270 package available via anonymous ftp. I have misplaced this location. Could someone remind me of it? Thanks! James V. Bys California Institute of Technology Internet address: jimbys@iago.caltech.edu
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 18:11:02 GMT From: long@yale.UUCP (H. Morrow Long) To: comp.protocols.tcp-ip Subject: Query on ICMP redirect handling when received by 4.3BSD hosts
We (Yale CS and EE depts) are preparing for an NFSNET (actually JVNCnet) gateway that will be added to the local network configuration in addition to our ARPAnet gateway. We have successfully used Gated to replace the the EGP daemon on our local backbone and we would like to have the gateway used for reaching default routes be dynamically switched (between JVNCnet and ARPAnet) by using ICMP redirects. Unfortunately looking at the 4.3BSD code it appears that although sending ICMP redirects from a 4.3BSD gateway is fairly developed the receiving of an ICMP redirect by a 4.3BSD host merely marks the fact that the route was obtained dynamically from an ICMP redirect but the redirect is never aged and removed (timed out). The 4.3BSD routed has a comment inside main.c in the infinite for loop where select is called to wait for RIP input and process() is called if there is rip input that says 'handle ICMP redirects' but there is code in the 4.3BSD routed that appears to handle ICMP redirects. Is this true? Is there a version of routed that does? H. Morrow Long long-morrow@cs.yale.edu
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 21:39:07 GMT From: BILLW@MATHOM.CISCO.COM (William Westfield) To: comp.protocols.tcp-ip Subject: Re: ip/icmp/echo messages
I don't know about 4.3 unix, but I can answer your questions in a more general sense. 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? Cisco systems gateways and terminal severs have a ping command that fully supports (both loose and strict) source routes, timestamps, and record route. A number of design decisions were made so that these would be maximally useful. 1) Can icmp echo/reply messages can be sent with ip headers that specify strict source routing. Yes, of course you can send ICMP messages with source routes. However, it is not clearly defined what should happen when, say, and ICMP echo request with options is received. The ICMP spec says that you should just swap the IP source and destination addresses and send the packet. However, if the packet has a source route, you might want to use the reverse route for the echo reply, and this requires more processing. In the cisco products, source routes are reversed, but record route and timestamp pointers are left unchanged (so you can see both paths). 4.3 bsd sends out the echo reply with no options whatsoever... Another problem is that very many systems, including gateways, do not fully (or correctly) support IP options. In the case of a source routed packet, it will probably just get dropped along the way, even if the path is good. Record route and timestamps just won't get filled in. An additional problems is that the IP header really isn't quite big enough. It could be really useful to have a loose source route and a record route in the same packet, but they would only be able to hold a total of 8 hops, which is not enough to be useful. 2) whether this would be useful in creating a looptest tool for customer service to check out specific serial links, and Well, the PING command all by itself is about the single most useful network debugging tool we have found. It isn't clear how useful adding option support to it is. I guess potentially this would allow you to debug more of a network from some specific site, especially if you have gateways that cannot be remotely logged into. And yes, it is especially useful for debugging serial links. Cisco's ping process wont reply to a ping addressed to a 'down' interface, even if the ping arrives and would be sent out on an 'up' interface. This is a useful feature, as it potentially lets you tell which side of a link is down, but I think that it is not common. Bill Westfield cisco Systems. -------
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 88 21:59:15 GMT From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) To: comp.protocols.tcp-ip Subject: Re: RARP or BOOTP for BSD wanted
A BOOTP server for 4.x BSD is available via anonymous FTP from lancaster.andrew.cmu.edu. "cd" to directory "pub" and get bootp.tar in binary mode. The server is a slightly improved version of Bill Croft's (Stanford) original code. Drew
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 9 Jan 88 01:23:28 GMT From: JLarson.pa@XEROX.COM To: comp.protocols.tcp-ip Subject: Re: Xerox's XNS protocols....
They are in hardcopy form (bound gray booklets w/graphics). The protocols you probably are most interested in are; Internet Transport Protocols, XSIS 028112 Courier: The Remote Procedure Call Protocol, XSIS 038112 Time Protocol, XSIS 088210 Clearinghouse Protocol, XSIS 078404 Authentication Protocol, XSIS 098210 They can be obtained by sending US mail to; Xerox Corporation 475 Oakmead Parkway Sunnyvale, CA 94086 ATTN: Pam Cance
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 9 Jan 88 03:18:02 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Happy New Year and * h e l p *
Ron's commands might leave the impression that Rutgers does not support subnets on our Suns. Our copy of SunOS 3.2 does support subnets. (It is quite easy to do this, even without source.) While we use proxy ARP on our cisco gateways to do some of the subnet routing, where we choose to do so we do it by telling the hosts explicitly that it should treat all routes as local (route add 0.0.0.0 `hostname` 0). Of course this is not practical for hosts with interfaces on more than one Ethernet.
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 9 Jan 88 04:07:32 GMT From: dpk@bway.UUCP (Doug Kingston) To: comp.protocols.tcp-ip Subject: Re: Happy New Year and * h e l p *
By default, Sun does not initialize the netmask with ifconfig e.g. ifconfig le0 `hostname` netmask 255.255.255.0 This needs to be done on the server only, since a 3.3 or 3.4 SunOS diskless node will make a ICMP netmask request. I am interested in knowing if this is the problem. -Doug-
-----------[000114][next][prev][last][first]----------------------------------------------------
Date: 9 Jan 88 04:09:52 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Application Programming Interface for FTPFTP Software's PC/TCP Developer's Kit (V2.0) has such an interface. I didn't do it, but I'm not now aware of any others, or any standard to follow. There are a dozen or more functions you can call, like ftp_stor() and so forth. jbvb
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 9 Jan 88 15:42:38 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: Leaping Lizards
Dave: Be careful what you say! Scotland has great scenery and you need curves to have a place for a lay by so the tourists can stretch their legs and enjoy the view. Anyway, its sometimes difficult to go in a straight line after consuming the Water of Life and its wiser to snake the road and keep the vehicles off the berm. Merton
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Jan 88 00:46:55 -0500 From: Jeffrey C Honig <jch@devvax.tn.cornell.edu> To: long@yale-zoo.arpa (H. Morrow Long) Cc: tcp-ip@sri-nic.arpa, gated-people@devvax.TN.CORNELL.EDU Subject: Re: Query on ICMP redirect handling when received by 4.3BSD hosts
> We (Yale CS and EE depts) are preparing for an NFSNET (actually JVNCnet) > gateway that will be added to the local network configuration in > addition to our ARPAnet gateway. We have successfully used Gated > to replace the the EGP daemon on our local backbone and we would > like to have the gateway used for reaching default routes be dynamically > switched (between JVNCnet and ARPAnet) by using ICMP redirects. > Unfortunately looking at the 4.3BSD code it appears that although > sending ICMP redirects from a 4.3BSD gateway is fairly developed the > receiving of an ICMP redirect by a 4.3BSD host merely marks the fact > that the route was obtained dynamically from an ICMP redirect but the > redirect is never aged and removed (timed out). The 4.3BSD routed > has a comment inside main.c in the infinite for loop where select > is called to wait for RIP input and process() is called if there is > rip input that says 'handle ICMP redirects' but there is code in the > 4.3BSD routed that appears to handle ICMP redirects. Is this true? > Is there a version of routed that does? Gated will time out routes learned by ICMP redirect. Jeff
-----------[000117][next][prev][last][first]----------------------------------------------------
Date: 9 Jan 88 23:39:43 GMT
From: tsmith@USNA.MIL ("Tim G. Smith", Mechanical)
To: comp.protocols.tcp-ip
Subject: Manufacturers of networking equipmentDoes anyone know of a good source of information about manufacturers of networking equipment? I have been reading Data Communications magazine but I would like to find other (more TCP/IP oriented) sources of information. If anyone out on the net has any experience with networking manufacturers I am currently trying to gather some info on who manufactures reliable, reasonably priced 9.6-64 kb modems suitable for use with SLIP. I am also interested in hearing about experiences with microwave or laser transmision of either TCP/IP or SLIP over short (up to 2 miles) distances. Thanks, Tim Smith E-Mail :<tsmith@usna.mil> US mail:Tim Smith CADIG mailstop: 11G US Naval Academy Annapolis, MD 21402 Tel # :(301)267-4413
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 10 Jan 88 06:55:32 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Leaping Lizards
Merton, Nonsense, and mind ye haggis, m'boy. Wee ken I spent the year teaching the lads computer science at Edinburgh a few years back. Why, e'en the sheep did mow the fuzz on Arthur's tail and the thistle's ball and thus became the fuzz-ball. 'Ta and a round to fair Robert, but mind the tee shot on the fourteenth... Dave
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 10 Jan 88 18:20:20 GMT From: slevy@UC.MSC.UMN.EDU (Stuart Levy) To: comp.protocols.tcp-ip Subject: Re: Happy New Year and * h e l p *
> By default, Sun does not initialize the netmask with ifconfig > e.g. ifconfig le0 `hostname` netmask 255.255.255.0 > > This needs to be done on the server only, since a 3.3 or 3.4 SunOS > diskless node will make a ICMP netmask request. Be aware that there may be a bootstrapping problem with this. The ICMP netmask request is broadcast, not sent only to the server, and SUNs (3.3 at least) take the first reply received. So if there are subnet-capable machines that haven't got the word yet, they might propagate wrong broadcast masks. If you wire the netmask into the server, and then either take other hosts down or feed them the right mask, just once, everything should work after that :->.
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 10 Jan 88 22:18:39 GMT From: srg@quick.COM (Spencer Garrett) To: comp.protocols.tcp-ip Subject: Re: Why IP & TCP Precedence Query
I think one of the biggest warts in TCP/IP is the stupid checksum spec. Including noncontiguous, and sometimes nonexistent, fields in the checksum insures that they will be slow and awkward to compute. If you're designing a new protocol, PLEASE have the checksum include all of, and only, your header and data. If you feel you can't trust your IP level to check its own header checksum, then please recompute the ip checksum yourself; don't pluck bits of that header out and pretend they're your own. If the IP header got mangled, you shouldn't even see the packet. If that's not true, you need to fix your IP module. Let's hear it for layering.
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 03:26:39 GMT From: Stevens@A.ISI.EDU (Jim Stevens) To: comp.protocols.tcp-ip Subject: Pseudo-Headers & Checksumming
Spencer Garrett responded to my message about TCP/IP Precedence &
Preemption and raised a very interesting point about pseudo-headers
and checksumming. Garrett's message follows:
> I think one of the biggest warts in TCP/IP is the stupid
> checksum spec. Including noncontiguous, and sometimes
> nonexistent, fields in the checksum insures that they will be
> slow and awkward to compute. If you're designing a new
> protocol, PLEASE have the checksum include all of, and only,
> your header and data. If you feel you can't trust your IP
> level to check its own header checksum, then please recompute
> the ip checksum yourself; don't pluck bits of that header out
> and pretend they're your own. If the IP header got mangled,
> you shouldn't even see the packet. If that's not true, you
> need to fix your IP module. Let's hear it for layering.
Since I am designing a new protocol, I am interested in people's
comments on the implementation difficulty of using pseudo-headers.
In addition, I am interested in any responses on why we have
pseudo-headers which are checksummed at all in TCP. Especially in
light of the fact that there are other IP fields which TCP could use
but does not checksum. Two such IP fields are precedence (within
IP type of service) and security options.
Is the old "End to End Argument" a reason for having pseudo-headers?
(Reference "End-to-End Arguments in System Design" by J.H. Saltzer,
D.P. Reed, and D.D. Clark, ACM Transactions on Computer System, Nov
1984.)
Does the pseudo-header checksumming issue have anything in common
with the issue of whether the ARP packets should have their own
checksum in addition to relying upon the Ethernet checksum?
(Remember all the messages on this subject on TCP-IP about a year or
so ago.)
If we are worried about implementation efficiency, should we place
the checksum field at the end of the protocol packet (i.e. a protocol
data unit for a particular protocol) as well as make the data to be
checksummed contiguous? For example, David Cheriton's Versatile
Message Transaction Protocol (VMTP) places the checksum at the very
end of the VMTP packets (even after the user data) to allow the
checksum "to be calculated as part of a software copy or hardware
transmission or reception as expected in an intelligent network
interface". (Quotes are from Cheriton's July 1987 Preliminary
Version 0.3 description of VMTP.)
Jim Stevens
-------
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 03:27:01 GMT From: carrs@TROUT.NOSC.MIL (Stephen M. Carr) To: comp.protocols.tcp-ip Subject: Forwarded: RE: Forwarded: Leaping Lizards
-------
Forwarded mail follows:
From yx0quinn@nardacva.arpa Sun Jan 10 09:52:03 1988
Message-Id: <8801101751.AA05806@trout.nosc.mil>
Date: 10 Jan 88 12:49:00 EST
From: "NEAL_QUINN" <yx0quinn@nardacva.arpa>
Subject: RE: Forwarded: Leaping Lizards
To: "carrs" <carrs>
Reply-To: "NEAL_QUINN" <yx0quinn@nardacva.arpa>
Steve,
Just some historical clarification: the Pope was worried that Easter
had been steadily marching closer to winter as the years wore on, thus moving
it further away from the traditional renewal period of the year, the commence-
ment of Spring. He not only adjusted the calendar, but also 'floated' the
day of Easter by making it the first Sunday after the first full moon after
the Vernal Equinox, thereby keeping it in line with the pagan rites that at
that time were providing fierce competition in the plebicite.
Also, there were two major adjustments to what is now the Julian cal-
endar: The first by Gaius Julius Caesar, who stole days from February to make
his one of the longest months, and another by Augustus Caesar, who also followed
suite.
R,
NAQJR
------
-------
-----------[000123][next][prev][last][first]----------------------------------------------------
Date: 11 Jan 88 07:46:41 GMT
From: cheriton@PESCADERO.STANFORD.EDU ("David Cheriton")
To: comp.protocols.tcp-ip
Subject: Re: Pseudo-Headers & ChecksummingVMTP has no need for pseudo headers a la TCP because the "entity identifiers", the transport-level endpoints, are (inter)network level independent as is the rest of the packet. The data to be checksummed is contiguous as well. Putting the checksum anywhere except at the very end of the packet seems disasterous if you want to look good on a 100 megabit network. David Cheriton
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 17:16:36 From: Leonard D Woren <LDW@MVSA.USC.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: tn3270
The original message on how to get tn3270 was posted before I
subscribed to tcp-ip, but I have a copy that was forwarded to me when
I was trying to get tn3270. The original posting was from Greg
Minshall on 17 Aug 87. The specifics are:
host - arpa.berkeley.edu (10.0.0.78) I was unable to get this to
work, but ucbarpa.berkeley.edu did work.
directory - pub
file - tn3270.tar (>700K)
- compress(1) version in tn3270.tar.Z (>300K)
It can also be obtained on a diskette, but I can't find the info on
that right now.
/Leonard
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 15:05:42 GMT From: narten@PURDUE.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: Pseudo-Headers & Checksumming
>VMTP has no need for pseudo headers a la TCP because the "entity identifiers", >the transport-level endpoints, are (inter)network level independent as is the >rest of the packet. One other important implication of the independence between the VMTP and IP layer concerns ICMP errors. The ICMP spec requires that the first 64 bits (8 bytes) of the transport level header be returned along with the IP header. In protocols like TCP/UDP, the 8 byte source/destination pair is actually part of the IP header, and by careful arrangement of the transport header fields, source/destination ports reside at the beginning of the packet. Because of the pseudo header, TCP/UDP actually get back 12 bytes of useful transport header information. Errors such as src quench and port unreachables can then matched up with the protocol control block that originates the offending datagram. In newer protocols like VMTP, I wonder if 8 bytes of transport header is sufficient. According the packet format given in the 86 SIGCOMM paper, entity identifiers are 32 bits long, hence the source/destination identifiers would use up all 64 bits of data. This leaves no room for other possibly important information like the forwarded entity identifier. Without the forwarded entity identifier field, ICMP error processing would appear to be much more difficult if not impossible in some cases. For instance, consider a request to read a file. The request would first go to the directory server, which might forward the request to a second server which answers the query directly. If the second server is unreachable, where would ICMP errors go? Most likely, they go back to the first server (not the originating client). The server would not be able to match the source entity indentifier with any of its own, and the ICMP error would likely be ignored. Meanwhile, the client originating the request retransmits a few times and finally times out. Is ICMP useful to newer protocols, and if not, can the Internet operate effectively without it? Thomas
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 15:56:45 GMT From: fedor@NISC.NYSER.NET (Mark Fedor) To: comp.protocols.tcp-ip Subject: Re: Query on ICMP redirect handling when received by 4.3BSD hosts
/etc/routed does not listen to ICMP redirects. If you want your routing daemon to listen to redirects, use gated. You can make gated run just like a "routed -q" with a very simple config file of: HELLO no RIP quiet EGP no Good luck, Mark Fedor
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 16:21:46 GMT From: fedor@NISC.NYSER.NET (Mark Fedor) To: comp.protocols.tcp-ip Subject: Re: gated/RIP info request
Gated supports RIP as described in the UNIX routed man page (with some HELLO-like extensions), HELLO (formal specs, RFC 891); Beware that the HELLO in gated has changed to parallel the NSFNet fuzzballs, so RFC 891 is out of date. Gated also supports EGP (kirton's EGP). EGP (formal specs, RFC 904, Kirton's EGP under UNIX, RFC 911) Mark
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 16:40:15 GMT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: Pseudo-Headers & Checksumming
You seem to imply that you can throw the IP addresses away when you get to the TCP layer. The TCP port numbers are only significant when paired with the ip addresses as well. You must remember this information somewhere, so you need the pseudoheader. Since the idea of the checksum is to prevent insidious little errors that "can't" happen (it's a little useless for error correction as it is a very weak), you really want to cover all the relevent
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 17:42:48 GMT From: mckenney@distek4..istc.sri.com (Paul E. McKenney) To: comp.protocols.tcp-ip Subject: Re: Pseudo-Headers & Checksumming
In article <8801111505.AA02117@percival.cs.purdue.edu> narten@PURDUE.EDU (Thomas Narten) writes: >Is ICMP useful to newer protocols, and if not, can the Internet >operate effectively without it? Better yet: Can ICMP be used by newer protocols that cannot fit the source information into eight bytes? High-speed hosts with lots of memory to burn could use the IP `Identification' field to help match ICMP replies with recently-sent packets, but only as long as they never send more than 65536 packets per RTT. This would not interfere with the normal use of this field (as an aid in reassembling datagrams). Furthermore, a host could unilaterally make this use of the field, no cooperation is required. If it is necessary to support more than 65536 packets per RTT, a new IP OPTION field analogous to the SATNET `Stream Identifier' could be defined -- at a cost of an additional 32 to 64 bits per packet, of course! Thanx, Paul
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 18:55:14 GMT From: rfox@amelia.nas.nasa.gov (Richard Fox) To: comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: What is the procedure to simulate the limits of protocols?
In article <1477@cuuxb.ATT.COM> jth@cuuxb.UUCP (Joe Heneghan) writes: >In article <4431@caip.rutgers.edu> schen@caip.rutgers.edu (Shin Chen) writes: >> >>I would like know how one goes about finding the theoretical and real >>limits (maximum, minimum,and average) of various protocols. This includes >>equipment, methodology and/or ideas. >>- Shin Chen >Misha Shwarz of Columbia University has written a good text on the >subject. It's more on the analysis side but it's part of the answer to >your question. Protocol venders should be able to provide benchmark >data (caveat emptor) on their products. > Joe Heneghan Do you know where we can get a copy of this document? I would be interested in reading this document, because one of things that I am doing is trying to find the real limts on certain protocols and hardware and I have found that it is not easily modeled by any sain computation. thanks rich .
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: 11 Jan 88 19:44:54 GMT From: JLarson.pa@XEROX.COM To: comp.protocols.tcp-ip Subject: Re: Xerox's XNS protocols....
As it turns out, there are two XNS introduction documents (in hardcopy form only); Xerox Network Systems Architecture: Introduction to Xerox Network Systems, XNSG 058504 General Information Manual, XNSG 068504 The first is a short overview, whereas the second is quite long (~200 pages) with discussions of many of the different protocols. They (and other XNS documentation) can be had by sending a message with your US mail address to Hilary Cornell <HCornell.osbunorth@Xerox.com>. Please allow 10 working days for delivery.
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 88 01:16:36 GMT From: LDW@MVSA.USC.EDU (Leonard D Woren) To: comp.protocols.tcp-ip Subject: Re: tn3270
The original message on how to get tn3270 was posted before I
subscribed to tcp-ip, but I have a copy that was forwarded to me when
I was trying to get tn3270. The original posting was from Greg
Minshall on 17 Aug 87. The specifics are:
host - arpa.berkeley.edu (10.0.0.78) I was unable to get this to
work, but ucbarpa.berkeley.edu did work.
directory - pub
file - tn3270.tar (>700K)
- compress(1) version in tn3270.tar.Z (>300K)
It can also be obtained on a diskette, but I can't find the info on
that right now.
/Leonard
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 88 06:31:14 GMT From: km@emory.uucp (Ken Mandelberg) To: comp.protocols.tcp-ip Subject: KA9Q TCP/IP for Unix-PC?
I understand there is a version of KA9Q TCP/IP for
the AT&T Unix-PC. Can someone send me the information
about it (like where to get it). My interest is in using
it with SLIP over an async modem.
--
Ken Mandelberg | {decvax,sun!sunatl,gatech}!emory!km UUCP
Emory University | km@emory BITNET
Dept of Math and CS | km@emory.ARPA ARPA,CSNET
Atlanta, GA 30322 | Phone: (404) 727-7963
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jan 88 12:30 CDT From: <RLW5809%TAMSTAR.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Please remove my name from the TCP-IP Discussion List
Please remove my name from the TCP-IP-L list.
Thanks!
RLW5809@TAMVENUS
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 88 13:17:09 GMT From: hls@oce-rd1.oce.nl (Harry Schreurs) To: comp.unix.wizards,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Need help implementing IEN 116 nameserver
Currently we use the IEN 116 nameserver which was recently
sent to com.sources.unix for our Bridge terminal servers.
We also have terminal servers from Ungermann-Bass in use ( NIU's ).
We are now changing the XNS based software for these terminal servers
to TCP/IP based software. Although it should be possible to use
the above mentioned nameserver, the NIU's refuse to work with
our nameserver.
After some studying we found that the NIU's only accept responses
from our nameserver where the the IP identification has the value 0x4944 !!
This however is impossible with 4.3 BSD. I'am not able to specify the value
in the identification field of the IP header.
In ip_output.c I found the following code:
===================================================
/*
* Fill in IP header.
*/
if ((flags & IP_FORWARDING) == 0) {
ip->ip_v = IPVERSION;
ip->ip_off &= IP_DF;
ip->ip_id = htons(ip_id++);
ip->ip_hl = hlen >> 2;
} else
hlen = ip->ip_hl << 2;
===================================================
The IP identification in an outgoing IP packet is given the
value of the variable ip_id which is afterwards incremented.
So I cannot assign a specific value without modifying the
source of ip_output.c
Any Suggestions?
===============================================================================
Harry Schreurs | DISCLAIMER: This note does not
Oce Nederland B.V., Research & Development | necessarily represent the position
p.o. box 101, 5900 MA Venlo | of Oce-Nederland B.V. Therefore
The Netherlands telex 58037 Oce NL | no liability or responsibility for
hls@oce.nl or ..!uunet!mcvax!oce-rd1!hls | whatever will be accepted.
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 88 14:13:00 GMT From: W8SDZ@SIMTEL20.ARPA (Keith Petersen) To: comp.protocols.tcp-ip Subject: KA9Q TCP/IP for Unix-PC?
The latest version (871225.4) of the KA9Q TCP/IP package is available via standard anonymous FTP from SIMTEL20: Filename Type Bytes CRC Directory PD1:<MISC.KA9Q-TCPIP> NELSON.ARC.2 BINARY 7413 B587H NET_BM.ARC.7 BINARY 19127 122CH NET_DES.ARC.5 BINARY 26249 1336H NET_DOC.ARC.5 BINARY 143157 42C5H NET_PC.ARC.3 BINARY 126524 0DEEH <--for IBM-PC NET_SRC.ARC.8 BINARY 302422 0A1DH TNC_ASH.ARC.4 BINARY 57076 F2ECH TNC_LDR.ARC.4 BINARY 15790 0D43H TNC_TNC1.ARC.4 BINARY 52127 B5F7H TNC_TNC2.ARC.4 BINARY 49542 0413H --Keith
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 88 15:21:38 GMT From: EWR@SEED.AMS.COM (Betsy Ramsey) To: comp.protocols.tcp-ip Subject: VAX/VMS and cisco AGS Gateways
The AMS has a cisco Systems AGS-1E1D Internet gateway (soft- ware version 6.1(1)) that connects our Ethernet local area network to the Arpanet over a DDN X.25 connection. We're having problems getting our CMU/Tek TCP/IP software (V6.2) on our VAX/VMS (V4.6) systems to communicate successfully through the gateway. Our TOPS-20 TCP/IP software does not have this problem. If you have a cisco Systems AGS gateway (any model) connected to your Ethernet, and you are running any brand of TCP/IP software on a VAX/VMS system, I'd appreciate hearing from you. In particular, I'd like to know the following: o What AGS model and software revision are you using? o What TCP/IP software and version are you running on your VMS system? o Are you having any problems with the combination of the two? My apologies to those users who are reading this message on more than one list. Betsy Ramsey American Mathematical Society Providence, RI 401-272-9500 Internet: EWR@SEED.AMS.COM -------
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 88 17:30:00 GMT From: RLW5809@TAMSTAR.BITNET To: comp.protocols.tcp-ip Subject: Please remove my name from the TCP-IP Discussion List
Please remove my name from the TCP-IP-L list.
Thanks!
RLW5809@TAMVENUS
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 12 Jan 88 17:37:27 GMT From: Stevens@A.ISI.EDU (Jim Stevens) To: comp.protocols.tcp-ip Subject: Re: Pseudo-Headers & Checksumming
Ron,
Sorry if I did not explain myself sufficiently.
The IP RFC 791 Receive Packet interface to Higher Level Protocols
specifies that the following information is to be made available to the
Higher Level Protocols:
RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
where:
BufPTR = buffer pointer
prot = protocol
result = response
OK = datagram received ok
Error = error in arguments
len = length of buffer
src = source address
dst = destination address
TOS = type of service (including precedence)
opt = option data (including security/compartment information).
Now although TCP can use all of this information, in actual common use
only the prot, len, src, and dst parameters are normally used.
Note that TCP does NOT need a pseudoheader to receive this information,
rather the pseudoheader is ONLY used to verify that the most common
information passed to TCP from IP is End-to-End correct.
Thus the question(s) under consideration is(are) not whether TCP (and other
transport protocols) need the information which is passed from IP to
TCP.
Rather the questions under consideration are:
1. Since TCP (and other transport protocols) need this information
from IP, should TCP trust the information to be correct and not have
been corrupted along the way.
2. If TCP cannot trust IP to delivery the information 99.9999999%
correct, why does TCP only specify part of the IP information in the
pseudo-header instead of all of the passed information.
Jim Stevens
-------
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 1988 12:39-PST From: Steve Deering <deering@pescadero.stanford.edu> To: Thomas Narten <narten@purdue.edu> Cc: end2end-interest@venera.isi.edu, tcp-ip@sri-nic.arpa Subject: Re: Pseudo-Headers & Checksumming
From: Thomas Narten <narten@purdue.edu>: ...According the packet format given in the 86 SIGCOMM paper, entity identifiers are 32 bits long, hence the source/destination identifiers would use up all 64 bits of data. This leaves no room for other possibly important information like the forwarded entity identifier. Without the forwarded entity identifier field, ICMP error processing would appear to be much more difficult if not impossible in some cases. The VMTP header format has changed significantly since the SIGCOMM paper was written. Entity identifiers are now 64 bits long, and the client entity id is the first field of the header, which means it (and it alone) is returned in ICMP messages. That works out well, because the client entity id is all that is needed to identify the appropriate protocol control block, both at the client end and the server end, as well as in any intermediate forwarders. Steve Deering
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 05:05:57 GMT From: minshall@VIOLET.BERKELEY.EDU To: comp.protocols.tcp-ip Subject: Re: tn3270
Jim,
You *can* ftp tn3270, but I would suggest buying it by mail.
It is a fairly large body of code (something like 350Kbytes compressed);
additionally, it is useful for the University to have some idea of
tn3270 usage in the world (for when the University makes future development
plans).
The following is a canned message on how to acquire tn3270
via the mail:
-----
New versions of the tn3270 and mset commands, used to logon to CMS from
unix, has been available since the late summer of 1987.
New features are:
o Error messages, in English, overlay a portion of the
screen when the user types an erroneous entry (invalid
control sequence, attempt to enter data in an "input
disallowed" field, etc.).
o Ability to "escape to shell". This, by itself, is
mostly useful in an MS-DOS (or non-BSD) system.
o An Application Programming Interface (API). This allows
programs, running under Unix or MS-DOS, to read and
write the 3270 screen, and to send keystrokes (3270)
to tn3270. This makes use of the "escape to shell"
feature. Included in the (beta) distribution is a
program which uses the API to receive files sent from
the IBM host (we don't supply the IBM side at this point,
and the rather stupid protocol is likely to change in
the future).
o Yale ASCII/7171/4994 "transparent" mode should now
be fully implemented. SAS-Graph, for example,
supports doing graphics to TEK terminals over
this interface. Locally, we use the X windowing
system terminal emulator (xterm), which provides
some TEK emulation, to display SAS-Graph graphics
on our workstations.
o Mset now prints out program function (PF) keys in
numerical order.
o Various bugs have been fixed.
To obtain the source for tn3270, send a check for $100.00 (US) payable
to "Regents of the University of California" to:
Campus Software Office
295 Evans Hall
UC Berkeley, CA 94720
USA
Specify that you are ordering tn3270.
This version will run under MS-DOS if the PC has the Ungermann-Bass
smart TCP board (NIU).
This version will compile under MS-DOS if you have: 512K of memory;
Microsoft C version 4.0; Microsoft MASM 4.0; the Ungermann-Bass "socket
emulation library"; and Polymake from Polytron (Hillsboro, Oregon).
Greg Minshall
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 05:36:14 GMT From: brian@sdcsvax.UCSD.EDU (Brian Kantor) To: comp.protocols.tcp-ip Subject: routing problems? Core gateways?
I can't ping SEISMO.CSS.GOV from our host 'SDCSVAX.UCSD.EDU' at 26.5.0.3. I can ping SEISMO quite nicely from our neighbor on the same IMP (NOSC.MIL at 26.0.0.3). We are both using the same default gateway at 26.2.0.73, which seems to be the way the packets are going. I guess that SEISMO could have different routes back to SDCSVAX than they do back to NOSC, but I don't know WHY they'd have them, since we're both on the same IMP. SEISMO isn't an isolated case - I can't ping any of the following hosts from SDCSVAX, but I can from NOSC: uxe.cso.uiuc.edu 128.174.5.54 mcc.com 10.3.0.62 ius2.cs.cmu.edu 128.2.254.176 cs.utah.edu 10.0.0.4 There are others. And there are hundreds of mail messages waiting in our queue because we can't get to their nameservers to get delivery addresses. (There ARE hosts on network 10 that I can ping, btw, such as UCBVAX.) I called the Milnet NOC, and they seemed to think that it's a core gateway problem and told me to call BBN. BBN assures me that they were already working on the problem - seems that they see a problem with one of the gateways, but I don't know what that problem would be. I'd like to understand what's going on, as well as get it fixed. The only thing I can think of is that NOSC is connected to the IMP with 1822, and we're connected with X.25, but don't quite see how that would make a difference either. NOSC is running EGP for our 128.54 network, so I don't think that's the problem - if indeed that is even relevant, since we're dealing directly with network 26 source addresses in the pings. Oh yeah, we've been having this sort of problem since Friday. I'm not sure it's always the same hosts. I'm stumped. Anybody got any ideas? Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA brian@sdcsvax.ucsd.edu (619) 534-6865
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 13:14:02 GMT From: kre@munnari.oz (Robert Elz) To: comp.protocols.tcp-ip Subject: Re: bootp/rarp
I have a small box that has a prom monitor, and wants to use some protocol to discover its IP address (or might want to, if it hasn't been configured). I currently use rarp, and would like to add bootp as an alternative. My problem is that bootp requires sending udp to the IP broadcast address, and that is something which (unfortunately) isn't a constant. That is, on many cables in the world, packets with 255's in them will be forwarded, or dropped, or just about anything other than what you would hope. There are many networks that still use 0's as the broadcast address, regardless of whether or not that's the right thing to do. I don't much like this as a solution, but I'm contemplating sending the broadcast to 255.255.255.255 initially, and if that works, fine. If there's no response, I'll try 0.0.0.0 and see if that might happen to succeed. Then alternate. I'm not sure if 4.2 really accepted 0.0.0.0 as a broadcast address, or only net.0, and I no longer have virgin 4.2 sources around to check it. Anyone know for sure? Also, any opinions on mangling bootp this way? Please don't bother saying "ignore the 0 stuff", that's not acceptable. kre
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 16:47:54 GMT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: VAX/VMS and cisco AGS Gateways
We have a large number of VMS machines connected to the ARPANET using CISCO gateways (ours is an 1822 DH interface). The TCP software we use is Wollengong WIN/TCP 3.something. The CISCO version is somewhere around 6.0 I suspect, but we've not had any problems even with CISCO version 5 and the Wollongong Version 2 TCP. Something is most likely misconfigured. You might try calling CISCO customer support. -Ron
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 19:02:13 GMT From: hans@umd5.umd.edu (Hans Breitenlohner) To: comp.protocols.tcp-ip Subject: Re: MILNET/?/UMDNET/SURA/GWU-GATE traffic question
This is an attempt to explain some of the strangeness which was reported
in and around SURA-net land.
As far as I can tell from the fragments of information, the packet
traversed the following path:
milnet-gw.lanl.gov 26.0.0.90
Milnet ???
some milnet to arpa gateway
Arpanet 56 kb serial
umd.umd.edu/trantor.umd.edu 10.8.0.20/128.8.10.14
UMD subnet 128.8.10 Ether
bogon-gw.umd.edu 128.8.10.41/129.2.1.1
UMD-BOGON-NET 129.2 Ether
sura1 gateway at U of Md 129.2.1.2/128.167.1.1
SURA subnet 128.167.1 Ether
sura2 gateway at U of Md 128.167.1.2/128.167.2.1
SURA subnet 128.167.2 56 kb serial
sura gateway at George Washington 128.167.2.2/128.164.1.1
GWU campus net Ether
gwuvm.gwu.edu 128.164.1.234
>
> so far, so good
>
GWU campus net Ether
sura gateway at GWU 128.164.1.1/128.167.2.2
SURA subnet 128.167.2 56 kb serial
sura2 gateway at U of Md 128.167.2.1/128.167.1.2
SURA subnet 128.167.1 Ether
sura1 gateway at U of Md 128.167.1.1/128.167.33.1
SURA subnet 128.167.33 56 kb serial
sura gateway at NRL 128.167.33.2
SURA subnet 128.167.33 56 kb serial
sura1 gateway at U of Md 128.167.33.1
>
> and so on, ad infinitum (or nearly so) between sura1 and sura-NRL.
>
Trantor is a Vax running 4.3 BSD. Bogon-gw, sura1 and sura2 are Proteon
p4200 routers running release 7.4 of their software, which honors the
'record route' option. The remaining sura gateways are Proteon p4200
routers running release 7.3 of their software, which ignores the 'record route'
option. This shows the usefulness of this IP option, and makes us wish more
software packages would honor it.
The following is educated guesswork, since I never got to see things in this
state, and since I do not have access to gateways outside the University of
Maryland. Apparently the gateway at NRL was advertising net 26 reachability
with a small hop count. There was a static route configured in it,
and routing and advertising are not easily separated in that software.
This is a bad situation at any time, and for several reasons. Apparently
it was aggravated by local Ethernet problems at NRL, which caused the gateway
to decide that the Ethernet was down, and send the packet to its default
network gateway, which was pointing back to sura1 at U of Md.
The fact that the packet arrived at all is likely a result of NRL's ethernet
problems being transient, or of the fact that the routing information between
the two gateways got straightened out and the packet was returned along the
route by which it was sent out. Since no date/time was given with the
problem report it is hard to verify any of this.
This seems adequate to explain the extraordinary delays and the packet loss
reported. I am at a loss to explain the duplicated packets. Perhaps someone
else can help out with that.
The problem has been resolved, and traffic between SURA-net and Milnet should
perform much better now. The sura1 gateway will no longer believe
net 26 advertisements from NRL, and I understand that the static route will
also be removed from the gateway there. Ironically this is a leftover from
past attempts by various other groups to confine Milnet traffic to their
local connections.
Thanks to cpw for reporting the problem and providing useful information.
In a case like this, where the problem was clearly confined to one net
(128.167) it would likely be faster and more effective to contact the
administrator of the net in question directly. The necessary information
can be obtained using the 'whois' utility (as in 'whois 128.167.0.0').
For more information on it and other services provided by the NIC you might
want to get a copy of "DDN NEW USER GUIDE", Publication # NIC 50001. If you
can not get it through your network administrator, use the NIC's toll free
phone number 800-235-3155 to order one.
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 19:34:34 GMT From: merlin@hqda-ai.UUCP (David S. Hayes) To: comp.protocols.tcp-ip,comp.sources.wanted Subject: Re: gated/RIP info request
In article <8801111621.AA00905@nisc.nyser.net>, fedor@NISC.NYSER.NET (Mark Fedor) writes: > > Gated supports RIP as described in the UNIX routed man [deleted] > Gated also supports EGP (kirton's EGP). EGP (formal specs, > RFC 904, Kirton's EGP under UNIX, RFC 911) This looks like it's just the sort of thing one would want in a gateway Sun system. Can anyone tell me where I can get the code for 'gated'? I can FTP if necessary. T i A, -- David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900 UUCP: *!uunet!cos!hqda-ai!merlin ARPA: ai01@hios-pent.arpa
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Jan 88 23:40 EDT From: <BEAME%MCMASTER.BITNET@CUNYVM.CUNY.EDU> To: tcp-ip@sri-nic.arpa Subject: Re: TCP/IP Terminal servers on VMS Vaxen
Here at McMaster University, we have 2 780s, 1 785 and 1 8600 each equipted
with an IVECS card. We also have several CS/100s connected to other services.
Most of our 8600 access is through Ethernet with our own PC based terminal
emulator.
Here is a small list of problems/requirements of the IVECS cards.
1. A UNIBUS. Newer Vaxen don't have UNIBUSes.
2. Each IVECS card can emulate up to 6 DMF-32s and also takes up one CSR and
vector for each emulated DMF. We had problems finding room when we added
the IVECS card to the 8600 which already had lots of RS232 DMZ access.
3. You require a NCS/150 or NCS/150 AT to download the software to the
cards and do any network management.
4. You can only do TELNET or RLOGIN so file transfer must be accomplished
via serial protocols like Kermit. (We use Kermit on our PCs).
5. Currently, hitting Control-S with-out a Control-Q may lose data.
I quess I should give some good points too.
1. We have very little problem with the cards.
2. The Vax is off-loaded of all the TELNET TCP/IP processing.
- Carl Beame
BEAME@MCMASTER.BITNET
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 19:54:27 GMT From: adam@hyper.lap.upenn.edu (Adam Feigin) To: comp.protocols.tcp-ip Subject: Missed article on D. Comer's TCP/IP book
Sorry to have to ask.....
I missed the article referencing Doug Comers new book on TCP/IP, although
I caught one of the followups. Could someone please send me relevant info
about it (Title, Publisher, ISBN #, etc.)
Thanks in advance.
Adam
------------------------------------------------------------------------------
ARPAnet: {root,adam}@{hyper,apollo}.lap.upenn.edu
UUCP: {harvard,decwrl,rutgers,ihnp4}!super.upenn.edu!hyper.lap.upenn.edu!adam
Adam Feigin
Network Administrator
Language Analysis Project
University of Pennsylvania
-----------------------------------------------------------------------------
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 20:22:56 GMT From: Stevens@A.ISI.EDU (Jim Stevens) To: comp.protocols.tcp-ip Subject: ANSI drafts
T. Knowles of CAP Scientific, UK published a paper entitled "Security in Military OSI Networks" in the IEE 2nd International Conference on Secure Communication Systems during October 1986. Knowles states that "In the USA ANSI have fairly advanced drafts for [security] enhancements to the Transport and Presentation Layers". Does anyone know of these drafts and how I could get a copy? Thanks, Jim Stevens -------
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 20:39:00 GMT From: deering@PESCADERO.STANFORD.EDU (Steve Deering) To: comp.protocols.tcp-ip Subject: Re: Pseudo-Headers & Checksumming
From: Thomas Narten <narten@purdue.edu>: ...According the packet format given in the 86 SIGCOMM paper, entity identifiers are 32 bits long, hence the source/destination identifiers would use up all 64 bits of data. This leaves no room for other possibly important information like the forwarded entity identifier. Without the forwarded entity identifier field, ICMP error processing would appear to be much more difficult if not impossible in some cases. The VMTP header format has changed significantly since the SIGCOMM paper was written. Entity identifiers are now 64 bits long, and the client entity id is the first field of the header, which means it (and it alone) is returned in ICMP messages. That works out well, because the client entity id is all that is needed to identify the appropriate protocol control block, both at the client end and the server end, as well as in any intermediate forwarders. Steve Deering
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 13 Jan 88 23:42:15 GMT From: stever@videovax.Tek.COM (Steven E. Rice, P.E.) To: comp.dcom.modems,comp.protocols.tcp-ip,comp.protocols.misc,comp.mail.misc Subject: Information wanted on "safe" mappings for serial transmissions.
I am looking for information on character mappings that are used or have
been used to allow the transfer of binary (8-bit) data through channels
that cannot pass all byte values. There are, of course, the various Hex
schemes, which simply encode each byte as two ASCII characters, but the
efficiency seems to be poorer than is necessary. Is there a standard
8-bit to 6-bit mapping (in which 3 bytes are encoded as 4 characters for
transmission) that avoids these problems?
The mapping used in UUENCODE and UUDECODE has problems with some BITNET
sites, which change some of the special characters. Frank daCruz wrote
in his book on Kermit that if they had it to do all over again, they
wouldn't be quite so ambitious with their use of the character set
(characters from space through tilde are used, as well as various
control characters).
I would like to be able to map arbitrary data streams to a "safe"
set of characters for transmission through a potentially-hostile
serial path. I was thinking of using the upper- and lower-case
letters (52), the digits 0 through 9 (10), and the "+" and "-"
signs (2), for a total of 64 characters. Is this safe, or will I
find some network node converting all my lower-case letters to
upper case?
I'm certain there are many of you who have faced just such a problem.
If you can shed any light on the issue, please send email to me at the
address below. Thanks!
Steve Rice
-----------------------------------------------------------------------------
* Every knee shall bow, and every tongue confess that Jesus Christ is Lord! *
new: stever@videovax.tv.Tek.com
old: {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 88 10:24:59 PST From: DDN Reference <NIC@SRI-NIC.ARPA> To: action@SRI-NIC.ARPA Cc: nic@SRI-NIC.ARPA Subject: [The Mailer Daemon <Mailer@SRI-NIC.ARPA>: Message of 13-Jan-88 15:48:24]
Action folks,
Hmmm, I noticed that the message indicates that it could not mail to
TCP-IP@SRI-NIC.ARPA. Can someone please investigate. This is not my
area of expertise, so I have no idea what could have gone wrong.
Nan
---------------
Date: Wed, 13 Jan 88 15:48:35 PST
From: The Mailer Daemon <Mailer@SRI-NIC.ARPA>
To: NIC@SRI-NIC.ARPA
Subject: Message of 13-Jan-88 15:48:24
Message failed for the following:
tcp-ip@SRI-NIC.ARPA: No such directory name
------------
Date: Wed, 13 Jan 88 15:48:24 PST
From: DDN Reference <NIC@SRI-NIC.ARPA>
Subject: Annonuncement of latest GOSIP profile
To: tcp-ip@SRI-NIC.ARPA, ietf-interest@GATEWAY.MITRE.ORG,
internics@SRI-NIC.ARPA, iso@NRTC.NORTHROP.COM, isode@NRTC.NORTHROP.COM
cc: nic@SRI-NIC.ARPA, mulvenna@ICST-ECF.ARPA, ebel@DCA-EMS.ARPA
Message-ID: <12366378943.34.NIC@SRI-NIC.ARPA>
Dear Network Colleagues,
We are sending the following announcement to you because many of you
will be very interested in reading the documents mentioned, if you have
not already done so.
Elizabeth Feinler,
DDN Network Information Center
---------------------------------------------------------------------
A Federal Information Processing Standard (FIPS) has been issued by the
National Bureau of Standards (NBS) for GOSIP in the Federal Register,
V52, No. 208, Oct. 28, 1987. [See below for obtaining
documents/files.]
This FIPS proposes a Federal Information Processing Standard for a
Government Open Systems Interconnection Profile (GOSIP), and, in
essence, spells out the policy of the Federal government including the
DoD transition from TCP/IP to ISO international protocols.
GOSIP is to be used by Federal government agencies when acquiring
computer network products and services and communications systems or
services that provide equivalent functionality to the protocols defined
in the GOSIP documents.
Currently, GOSIP supports the Message Handling Systems (MHS) and File
Transfer, Access, and Management applications (FTAM). GOSIP also
supports interconnection of the following network technologies: CCITT
Recommendation X.25; Carrier Sense Multiple Access with Collision
Detection (IEEE 802.3): Token Bus (IEEE 802.4); and Token Ring (IEEE
802.5). Additional applications and network technologies will be added
to later versions of the GOSIP document or vendor products in which
such protocols are embedded.
The proposed transition from TCP/IP to international protocols is
expected to have considerable impact and has been given a great deal of
thought and review by the Government. It may well have impact on your
activities, making it particularly important that you are aware of the
adopted policy and the GOSIP FIPS itself.
If you have questions or wish to respond, the details for how to do so
are included in the Federal Register issue or in the NIC online file
[PROTOCOLS:GOSIP-FEDREG.TXT].
Gerry Mulvenna (MULVENNA@ICST-ECF.ARPA) at NBS is available to answer
questions you might have about the GOSIP FIPS, and is willing to
forward formal responses received via electronic mail to the Director,
ICST.
--------------------------------------------------------------------
DOCUMENT PATHNAMES AT SRI-NIC.ARPA [26.0.0.73 or 10.0.0.51]
1. PROTOCOLS:GOSIP-FEDREG.TXT (contains the Federal Register
announcement of the FIPS)
2. PROTOCOLS:GOSIP-V1.DOC (contains GOSIP profile itself)
3. PROTOCOLS:OSDIR-7-87.TXT (contains OSD directive to
proceed with policy within DoD)
4. PROTOCOLS:GOSIP-FIPS-DRAFT.TXT (contains the GOSIP FIPS draft)
All files are available from the DDN Network Information Center host,
SRI-NIC.ARPA, via FTP (using the anonymous login convention), KERMIT,
or SERVICE (the NIC's automatic electronic mail service). Hardcopy is
available from NTIS and also from the DDN NIC. (NIC copies may be
obtained for the cost of reproduction and handling.) Call the NIC at
800-235-3155 or 415-859-3695 if you need further assistance obtaining
either the online or hardcopies.
-------
-------
-------
-------
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jan 88 10:51:21 PST From: NIC Operations <ACTION@SRI-NIC.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: FIPS
Dear Network Colleagues,
We are sending the following announcement to you because many of you
will be very interested in reading the documents mentioned, if you have
not already done so.
Elizabeth Feinler,
DDN Network Information Center
---------------------------------------------------------------------
A Federal Information Processing Standard (FIPS) has been issued by the
National Bureau of Standards (NBS) for GOSIP in the Federal Register,
V52, No. 208, Oct. 28, 1987. [See below for obtaining
documents/files.]
This FIPS proposes a Federal Information Processing Standard for a
Government Open Systems Interconnection Profile (GOSIP), and, in
essence, spells out the policy of the Federal government including the
DoD transition from TCP/IP to ISO international protocols.
GOSIP is to be used by Federal government agencies when acquiring
computer network products and services and communications systems or
services that provide equivalent functionality to the protocols defined
in the GOSIP documents.
Currently, GOSIP supports the Message Handling Systems (MHS) and File
Transfer, Access, and Management applications (FTAM). GOSIP also
supports interconnection of the following network technologies: CCITT
Recommendation X.25; Carrier Sense Multiple Access with Collision
Detection (IEEE 802.3): Token Bus (IEEE 802.4); and Token Ring (IEEE
802.5). Additional applications and network technologies will be added
to later versions of the GOSIP document or vendor products in which
such protocols are embedded.
The proposed transition from TCP/IP to international protocols is
expected to have considerable impact and has been given a great deal of
thought and review by the Government. It may well have impact on your
activities, making it particularly important that you are aware of the
adopted policy and the GOSIP FIPS itself.
If you have questions or wish to respond, the details for how to do so
are included in the Federal Register issue or in the NIC online file
[PROTOCOLS:GOSIP-FEDREG.TXT].
Gerry Mulvenna (MULVENNA@ICST-ECF.ARPA) at NBS is available to answer
questions you might have about the GOSIP FIPS, and is willing to
forward formal responses received via electronic mail to the Director,
ICST.
--------------------------------------------------------------------
DOCUMENT PATHNAMES AT SRI-NIC.ARPA [26.0.0.73 or 10.0.0.51]
1. PROTOCOLS:GOSIP-FEDREG.TXT (contains the Federal Register
announcement of the FIPS)
2. PROTOCOLS:GOSIP-V1.DOC (contains GOSIP profile itself)
3. PROTOCOLS:OSDIR-7-87.TXT (contains OSD directive to
proceed with policy within DoD)
4. PROTOCOLS:GOSIP-FIPS-DRAFT.TXT (contains the GOSIP FIPS draft)
All files are available from the DDN Network Information Center host,
SRI-NIC.ARPA, via FTP (using the anonymous login convention), KERMIT,
or SERVICE (the NIC's automatic electronic mail service). Hardcopy is
available from NTIS and also from the DDN NIC. (NIC copies may be
obtained for the cost of reproduction and handling.) Call the NIC at
800-235-3155 or 415-859-3695 if you need further assistance obtaining
either the online or hardcopies.
-------
-------
-------
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 03:17:21 GMT From: mtune!petsd!pedsga!tsdiag!dennisb@rutgers.edu To: tcp-ip@sri-nic.arpa Subject: Mischa Schwartz - Protocols and Analysis
Someone out there was looking for
Telecommunication Networks: Protocols, Modeling and Analysis
by Mischa Schwartz - ISBN 0-201-16423-X.
I have seen it in most B.Dalton bookstores in the NJ and NYC area. With the
ISBN number, any book store can order it.
Spose
Dennis
--
Dennis Lee Black Concurrent Computer Corp
Cust Serv, Data Comm Sup
40 Pine Street
Neptune, New Jersey 07756
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 03:40:00 GMT From: BEAME@MCMASTER.BITNET To: comp.protocols.tcp-ip Subject: Re: TCP/IP Terminal servers on VMS Vaxen
Here at McMaster University, we have 2 780s, 1 785 and 1 8600 each equipted
with an IVECS card. We also have several CS/100s connected to other services.
Most of our 8600 access is through Ethernet with our own PC based terminal
emulator.
Here is a small list of problems/requirements of the IVECS cards.
1. A UNIBUS. Newer Vaxen don't have UNIBUSes.
2. Each IVECS card can emulate up to 6 DMF-32s and also takes up one CSR and
vector for each emulated DMF. We had problems finding room when we added
the IVECS card to the 8600 which already had lots of RS232 DMZ access.
3. You require a NCS/150 or NCS/150 AT to download the software to the
cards and do any network management.
4. You can only do TELNET or RLOGIN so file transfer must be accomplished
via serial protocols like Kermit. (We use Kermit on our PCs).
5. Currently, hitting Control-S with-out a Control-Q may lose data.
I quess I should give some good points too.
1. We have very little problem with the cards.
2. The Vax is off-loaded of all the TELNET TCP/IP processing.
- Carl Beame
BEAME@MCMASTER.BITNET
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 10:06:00 CST From: "Rick Watson" <ccaw001@utadnx.cc.utexas.edu> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: ether packet type 90-00
If I send a properly formatted packet of type 90-00 to DEC ethernet controllers, DEUNA, DEQNA, DELUA, etc, the packet will be forwarded, according to the manual, by the controller, to wherever you set in the forwarding address field. Does anyone know for sure if in the case of VMS, Ultrix and BSD 4.3 if it is always the case that the packet is forwarded by the controller and not the port driver? The reason I ask is that I seem to get different timing and response results when I am "pinging" interfaces owned by Ultrix and VMS. The "Loop Message Format" is described in the DELUA manual, among others. Rick Watson University of Texas Computation Center arpa: ccaw001@utadnx.cc.utexas.edu uucp: ...seismo!ut-sally!ut-emx!rick bitnet: ccaw001@utadnx span: utspan::ccaw001 phone: 512/471-8220 471-3241
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 07:05:51 GMT From: dag@hub.ucsb.edu (Darren Daggit) To: comp.protocols.tcp-ip Subject: Re: routing problems? Core gateways?
In article <4481@sdcsvax.UCSD.EDU> brian@sdcsvax.UCSD.EDU (Brian Kantor) writes:
>I can't ping SEISMO.CSS.GOV from our host 'SDCSVAX.UCSD.EDU' at
>26.5.0.3. I can ping SEISMO quite nicely from our neighbor on the same
>IMP (NOSC.MIL at 26.0.0.3). We are both using the same default gateway
>at 26.2.0.73, which seems to be the way the packets are going.
>
>SEISMO isn't an isolated case - I can't ping any of the following hosts
>from SDCSVAX, but I can from NOSC:
>
> uxe.cso.uiuc.edu 128.174.5.54
> mcc.com 10.3.0.62
> ius2.cs.cmu.edu 128.2.254.176
> cs.utah.edu 10.0.0.4
Brian,
I can get to all of these hosts, and haven't seen any problems routing to them.
We are sending stuff through SDSC to the NSFNET backbone and on from there,
so things probably aren't touching the same piece of ethernet cable that you
are on, but the systems are reachable.
There have been reported problems that affect at least one of these systems
(cs.utah.edu). The gateway psc.psc.edu has evidently been in trouble over
the past few days, and things haven't been shuttled around the way they
should.
>There are others. And there are hundreds of mail messages waiting in
>our queue because we can't get to their nameservers to get delivery
>addresses. (There ARE hosts on network 10 that I can ping, btw, such
>as UCBVAX.)
I don't have my map of how the UCSD campus is connected to SDSC at hand, but
UCBVAX may not be a good example. If you are routing things through the least
number of hops then stuff to UCBVAX probably isn't going to your default
gateway, the fastest route would be through the SDSC Proteon and out to the
BARRNET (There are two R's in BARRNET aren't there?) backbone. Is this right?
I have noticed that when the SDSC link into the NSFNET goes down we can still
get to the BARRNET, so the SDSC Proteon is routing things correctly in that
respect.
>I called the Milnet NOC, and they seemed to think that it's a core
>gateway problem and told me to call BBN. BBN assures me that they were
>already working on the problem - seems that they see a problem with one
>of the gateways, but I don't know what that problem would be.
That is probably the PSC.PSC.EDU gateway, maybe it is effecting more than
one site.
I hope this helps,
--darren
> Brian Kantor
> UCSD Office of Academic Computing
> Academic Network Operations Group
> UCSD B-028, La Jolla, CA 92093 USA
> brian@sdcsvax.ucsd.edu (619) 534-6865
-----------------------------------------------------------------------------
Darren Griffiths BITNET - DAG@SBITP
Systems Manager ARPA - DAG@NOBBS.UCSB.EDU
Physics Computer Services (128.111.8.50)
University of California HEPNET - NOBBS::DAG
Santa Barbara, CA 93106 13326::DAG
(805)961-2602
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 15:42:39 GMT From: narten@purdue.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: Pseudo-Headers & Checksumming
Where can one find more recent information on VMTP than the SIGCOMM paper? Thomas
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 15:46:25 GMT From: miket@ccicpg.UUCP (Mike Tracy) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Adaptors for thinwire to thickwire
This probably won't help your immediate problem of connecting a
thin-lan to a normal ethernet cable, but I was reading about
a product called LattisNet. It apparently is a twisted pair ethernet.
It uses a star type of topology and phone lines (unshielded twisted pairs)
to make a low cost ethernet.
Does anyone know if the system is any good ?
Michael D. Tracy Computer Consoles Incorporated
(714)458-7282 9801 Muirlands Boulevard
Irvine, CA 92718
{allegra!hplabs!felix,seismo!rlgvax}!ccicpg!miket
-----------[000160][next][prev][last][first]----------------------------------------------------
Date: 14 Jan 88 16:06:00 GMT
From: ccaw001@UTADNX.CC.UTEXAS.EDU ("Rick Watson")
To: comp.protocols.tcp-ip
Subject: ether packet type 90-00If I send a properly formatted packet of type 90-00 to DEC ethernet controllers, DEUNA, DEQNA, DELUA, etc, the packet will be forwarded, according to the manual, by the controller, to wherever you set in the forwarding address field. Does anyone know for sure if in the case of VMS, Ultrix and BSD 4.3 if it is always the case that the packet is forwarded by the controller and not the port driver? The reason I ask is that I seem to get different timing and response results when I am "pinging" interfaces owned by Ultrix and VMS. The "Loop Message Format" is described in the DELUA manual, among others. Rick Watson University of Texas Computation Center arpa: ccaw001@utadnx.cc.utexas.edu uucp: ...seismo!ut-sally!ut-emx!rick bitnet: ccaw001@utadnx span: utspan::ccaw001 phone: 512/471-8220 471-3241
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 16:28:57 GMT From: mminnich@UDEL.EDU (Mike Minnich) To: comp.protocols.tcp-ip Subject: Re: bootp/rarp
> I'm not sure if 4.2 really accepted > 0.0.0.0 as a broadcast address, or only net.0, and I no longer have > virgin 4.2 sources around to check it. Robert, Last I tried using 0.0.0.0 as a BOOTP broadcast address in a 4.2 environment, most if not all of our Unix UDP servers went belly-up, into some kind of tight loop. Since at the time I was interested in making BOOTP work, I decided to use a hard-wired (non-broadcast) IP address and wait for 4.3 to resolve the broadcast problem. Hope this helps. mike PS - I didn't try net.0, but I would strongly suspect that it would work.
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 16:30:31 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Pseudo-Headers & Checksumming
Thomas,
"Real soon now" Dave Cheriton will submit an RFC on VMTP [we hope].
Bob Braden
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 17:37:10 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: gated/RIP info request
David S. Hayes writes: > This looks like it's just the sort of thing one would want in a > gateway Sun system. Can anyone tell me where I can get the code > for 'gated'? I can FTP if necessary. > > T i A, As long as the "gateway Sun system" is connecting the same class of network number with the same subnet mask you are probably right. Sun systems can only act as gateways between networks of the same class and subnet mask. Maybe a Sun could gateway between a class C non-subnetted network and a class B network with subnetmask == 255.255.255.0. Phil Wood (cpw@lanl.gov)
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 17:52:29 GMT From: brian@sdcsvax.UCSD.EDU (Brian Kantor) To: comp.protocols.tcp-ip Subject: Re: routing problems? Core gateways?
Well, we're a little closer to the solution - at least we know what the real problem is, although not the cause. As I said, we're X.25 connected to our Milnet IMP. That requires that we have an X.25 virtual circuit for each separate host or gateway on the Milnet that we want to talk to. If we are the first person to send a packet to that address, we open the VC in the range from 1 to 32. If the distant host is the first to send a packet to us, the IMP must open the VC in the range 64-33. If a VC is open already (no matter whether the IMP or our interface opened it), it will be used. If a VC is idle for a configurable length of time (currently 60 seconds), the circuit will be closed. It seems that our problem is caused by the IMP not being able to open VCs to us. We CAN open outgoing VCs, but if the first packet from a host or gateway on the Milnet is originated by them instead of us, then the VC connection won't happen and things don't work. Our problem with Seismo and other hosts is that they are on the far side of gateways to the Arpanet, so that packets from them to us must pass through a minimum of TWO gateways - one from them to Arpa, then one of the Arpa-Milnet mailbridges - in order to get to us. That means that since the ICMP echo response (as well as all other traffic from them to us) might well come to our host through a different mailbridge than the one through which we send the packets to them, they might indeed wind up seeing our packets but we won't see theirs, because the X.25 VC from the IMP for that mailbridge couldn't be opened. Clear as mud, eh? We think it started after the IMP was reloaded after a power failure last Saturday. The NOC has somebody looking into it, they tell me. In the meantime, we're working around the problem by sending a single ping packet to each of the seven mailbridges once every 45 seconds. That's sufficient to keep the X.25 virtual circuits active so people can get to us. It doesn't cure the problem, but it's a whole lot more livable this way. Deep gratitude to Mike Brescia of BBN who helped figure out what's going on - or not going on, in this case. Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 14 Jan 88 17:54:19 GMT From: terrell@musky2.EDU (Roger Terrell) To: comp.protocols.tcp-ip,comp.os.vms Subject: I need a good "manual" for tcp/ip
I am trying to set up TCP/IP on a VAX 11/780, but have not attempted this sort of thing before. Can anyone tell me of a good reference for it? The information that I need is not technical info on how it works, etc. (although that wouldn't hurt), but I need information on configuring it: How to set up configuration files etc. I am using CMU TCP/IP. If you don't know of a reference work, but would be willing to give a few tips from your own experience, please e-mail me anyway. Thanks, Roger -- Roger Terrell Muskingum College ...cbosgd!musky2!terrell (UUCP) New Concord, OH 43762
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 02:33:05 GMT From: slevy@UC.MSC.UMN.EDU (Stuart Levy) To: comp.protocols.tcp-ip Subject: Re: gated/RIP info request
> Sun systems can only act as gateways between networks of the same > class and subnet mask. > Phil Wood (cpw@lanl.gov) Are you sure about that? We use SUN-3's as gateways between class-B and class-C nets, and they seem to work just fine. There -is- a restriction that only one network can be subnetted (can gateway among subnets of a single net, can gateway also onto class A/B/C non-subnetted nets, but cannot gateway between subnets of two different nets). This is true under SUN 3.3 at least.
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 03:13:34 GMT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: Need help implementing IEN 116 nameserver
That's probably not the bug. We use a perfectly normal sun kernel with an IEN116 nameserver with the UB products. The problem that we have is that the UDP checksum code in the UB box is defective. If you do not have udp checksumming turned on (you leave the checksum field zero), the box doesn't realize that you are not computing checksums and ignores you. The quick solution is to turn on checksums on the machine that is providing name service (on BSD UNIX poke _udpcksum to 1). -Ron
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 03:19:57 GMT From: harvisr!sob@husc6.harvard.edu (Scott Bradner) To: tcp-ip@sri-nic.arpa Subject: Re: LattisNet
I've been testing the LattisNet product for the last 2 months. It seems to work just fine. There was some badmouthing of this product by a-large-computer-company, saying that it did not run at 10MB. I have seen no reason to feel that might be true. I have tested a sun 3/60 connected via LattisNet to Harvard's backbone & see no change in throughput or error counts when compaired to a sun direct connected to the backbone. Scott
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 04:05:33 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: gated/RIP info request
< in reference to Sun's as gateways > I know for sure that they only have one place in memory for a subnet mask. Maybe, if you do not subnet, things work. I also know that we have to trash (logically, for the indefinite future) the IPC boards from Sun. We have a class B subnetted with 6 bits for net and 10 for host. I know that's a strange way to subnet. But, hey, that's the way DEC does it! We also have a Class C subnetted with 3 bits for subnet and 5 bits for host (now thats more like it). It cuts down on the plethora of broadcasts/arps/rarps/ICMP-Redirects/ICMP-Mask-replys from every host known to man, when ONE Sun client boots! Oh, oh. I'm beginning to feel stressed! Is this time for a flame on banner? No, I must maintain some kind of decorum. I'll just cut the remainder of this message, and save it for later. Actually, its pretty good ..., nah. One does have a choice though, there are other's out there that make real IP routers. Phil Wood cpw@lanl.gov
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 04:27:52 GMT From: garrett@udel.EDU (Joel Garrett) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Adaptors for thinwire to thickwire
In article <9177@ccicpg.UUCP> miket@ccicpg.UUCP (Mike Tracy) writes: ... >thin-lan to a normal ethernet cable, but I was reading about >a product called LattisNet. It apparently is a twisted pair ethernet. >It uses a star type of topology and phone lines (unshielded twisted pairs) >to make a low cost ethernet. > >Does anyone know if the system is any good ? > Actually, Lattisnet allows you to run ethernet protocols over Fiber, Twisted Pairs (shielded and unshielded). We will be using the Shielded Twisted Pair host modules to give us Ethernet over our equivalent to IBM's shielded pairs cable in our new building. The local var for Synoptics just came out this past monday to perform a live test on a sample of our cabling and using some of our ethernet equipment that will end up on the new building network. All worked like a charm! Joel Garrett Center for Composite Materials University of Delaware garrett@udel.edu
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jan 88 11:47:01 CST From: Bryan McWilliams <OPRBBDM%TCSVM.BITNET@CUNYVM.CUNY.EDU> To: lattisnet <TCP-IP@SRI-NIC.ARPA> Subject: Re: Adaptors for thinwire to thickwire
1) I have two lattisnets installed; can't say enough goood about the product. It's easy to install, and vey reliable. e 2) Thin wire to thick wire -- just use a reducer.
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jan 88 11:00:43 EST From: Ken Pogran <pogran@ccq.bbn.com> To: oconnor@sccgate.scc.com Cc: brian@sdcsvax.ucsd.edu, tcp-ip@sri-nic.arpa Subject: Re: routing problems? Core gateways?
Mike, I can confirm that PSN 7.0 has NOT been installed in the MILNET yet, and there's no chance that that PSN was accidentally reloaded with PSN 7.0 software (hosts on that node wouldn't be able to communicate AT ALL with the rest of the MILNET if that had happened!). I'm not plugged in to the trouble-shooting process on the MILNET, so I can't speculate on what Brian's problem might actually be. I agree with you that the external symptoms do resemble the ARPANET PSN 7 "stuck VC" problem, but I think the explanation has to turn out to be quite different. Regards, Ken P.S.: With regard to the point that "only Sun users experienced the 'hung VC' problem with PSN 7.0", it's fair to say that Sun's was the only X.25 implementation that we FOUND on the ARPANET that encountered that problem; it's possible that other implementors could have made the same design decisions that Sun made and could have had the problem, too. But, as I said above, that's a PSN 7 problem and certainly isn't what Brian's seeing on the MILNET right now.
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 08:30:14 GMT From: melohn@SUN.COM (Bill Melohn) To: comp.protocols.tcp-ip Subject: Re: gated/RIP info request
To clarify: Suns running version 3.3 or later of the Sun Operating System can in fact route packets between class A, B, C, or any combination thereof. There is only ONE subnet mask possible in the 3.X series of releases, so if you are routing between two subnetted networks of any class, the subnet masks must be the same. Routing between a subnetted network and a non-subnetted net is never a problem, and the entire restriction will dissappear in release 4.0, which uses the 4.3 subnetting code.
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 12:34:00 GMT From: cball@ishmael.UUCP To: comp.protocols.tcp-ip Subject: Re: Adaptors for thinwire to thickw
>/* Written 10:46 am Jan 14, 1988 by miket@ccicpg.UUCP in ishmael:comp.protocols.tcp-ip */ >... It[Latisnet] apparently is a twisted pair ethernet. >It uses a star type of topology and phone lines (unshielded twisted pairs) >to make a low cost ethernet. > >Does anyone know if the system is any good ? I am also very interested from anyone with experience with this, or any similar system. It doesn't seem especially cheap at $600+/node[from Digital Review, which gave a positive review], but the twisted pair star configuration sounds worthwhile. We frequently shuffle Sun nodes between offices; running and re-running coax that can't be touched during office hours is a real pain. Also, our experience is that thin ethernets with direct connections to workstations are only marginally reliable. Charles Ball Intermetrics, Inc. cball@inmet.com
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 15:20:35 GMT From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) To: comp.protocols.tcp-ip Subject: Re: routing problems? Core gateways?
Brian, Your problem is similar to the one we experience with PSN 7.0 software. In our case, the incoming VC would be created but only one packet would be received. If we pinged the origin of the VC, traffic would begin flowing. The problem was attributed to the new PSN code expecting an X.25 RR after the first packet which our X.25 didn't provide. This was a change from PSN 6 behavior. We also set up a periodic pinging of the mailbridges in order to keep mail flowing (the suggestion came from BBN). What is dissimilar is the fact that we are an Arpanet node while you are Milnet. I didn't think PSN 7.0 was to be installed in the Milnet just yet so unless someone slipped up reloading your PSN I don't know how you could have the same problem as us. We are using Sun's X.25 in our gateway and were told that only Sun users experienced the "hung VC" problem with PSN 7.0. I'd be interested to know whether or not you have the resources to determine whether you get no incoming packets on the bad VCs or just one. Mike
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 16:00:43 GMT From: pogran@ccq.bbn.COM (Ken Pogran) To: comp.protocols.tcp-ip Subject: Re: routing problems? Core gateways?
Mike, I can confirm that PSN 7.0 has NOT been installed in the MILNET yet, and there's no chance that that PSN was accidentally reloaded with PSN 7.0 software (hosts on that node wouldn't be able to communicate AT ALL with the rest of the MILNET if that had happened!). I'm not plugged in to the trouble-shooting process on the MILNET, so I can't speculate on what Brian's problem might actually be. I agree with you that the external symptoms do resemble the ARPANET PSN 7 "stuck VC" problem, but I think the explanation has to turn out to be quite different. Regards, Ken P.S.: With regard to the point that "only Sun users experienced the 'hung VC' problem with PSN 7.0", it's fair to say that Sun's was the only X.25 implementation that we FOUND on the ARPANET that encountered that problem; it's possible that other implementors could have made the same design decisions that Sun made and could have had the problem, too. But, as I said above, that's a PSN 7 problem and certainly isn't what Brian's seeing on the MILNET right now.
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 17:47:01 GMT From: OPRBBDM@TCSVM.BITNET (Bryan McWilliams) To: comp.protocols.tcp-ip Subject: Re: Adaptors for thinwire to thickwire
1) I have two lattisnets installed; can't say enough goood about the product. It's easy to install, and vey reliable. e 2) Thin wire to thick wire -- just use a reducer.
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 18:04:26 GMT From: lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) To: comp.protocols.tcp-ip Subject: Re: LattisNet
We've been using Lattisnet for about fifty machines, and it seems to work pretty well. When it was first installed, there were some packet dropping problems, and they came out and installed some sort of additional buffering. Perhaps you have an older version, or else the lower cost, less buffered version. Maybe when the machine count goes to a hundred, we might have a different story to tell, (ie its time to buffer more.) However, single point to point transfers seem to run as fast between machines on the Lattisnet as those not on it. This was tried only with sun 3/260's and SGI irises, so far. john
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 19:24:19 GMT From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) To: comp.protocols.tcp-ip Subject: Re: bootp/rarp
I'm pretty sure that the original 4.2bsd only supported net.0. I'm sure Mike Karel's will correct me if I'm wrong... We were faced with the same problem when we implemented a BOOTP for PCIP (IBMPC). My solution was to use 255.255.255.255 as the defautl, as was specified by the RFC. However I left a hook to extend it to net.0 if desired. With PCIP, the IP address is normally stored on a disk and is loaded into memory at boot time. All programs use the IP address in memory, not the disk. Thus, my BOOTP program modified the IP address in memory after it found the address. However, it figures out which broadcast address to use by seeing what is in memory when it starts, which is the IP address on the disk. If the address is 0.0.0.0, it uses the default of 255.255.255.255. However, if it is stored as net.0 or net.subnet.0, it uses that as the address. This is not per the spec, but I couldn't think of anything it would break. Currently all of our PC's are configured to use 128.2.0.0 since we still have plenty of 4.2 machines. Of course if you are using a ROM and can't even store this much info (i.e. you don't have an EEPROM or battery backed up memory or...) then I don't think there is going to be much you can do. Drew
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 19:45:46 GMT From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) To: comp.protocols.tcp-ip Subject: lattisnet
We've been using Lattisnet for quite some time now (2 years?). In fact, we were one of their initial beta testers. We aren't using the thinwire stuff yet, but we are using their system over our IBM cabling system and over fiber. We have a few hundred connections to multiple lattisnets and have never had a single hardware failure. Our campus backbone is also a lattisnet box. I can't say enough good things about the product. We are very happy with it and we are using it in almost all future ethernet connections, as well as converting many old connections to it. It's ease of use and maintenance are great since it gives us a star shaped ethernet in centralized wire closets. As far as cost goes, it is a bit more expensive. However, we feel the additional cost is small compared to what we get in maintainability. In the long run it may even be cheaper when we factor in technician time for installation and maintenance. Drew
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 22:01:44 GMT From: tim@Data-IO.COM (The Daemon's Slave) To: comp.mail.misc,comp.dcom.lans,comp.protocols.tcp-ip Subject: 3COM mail <-> Unix Mail?
Does anyone know of some hardware/software that will allow one to have a 3com_mail to Unix_mail gateway? Even a gateway to VMS_mail would help. Any suggestions or pointers will be much appreciated as we need this as soon as possible. -- <tim@Data-IO.COM> ..uunet Tim Rosmus (Sys Admin) ..sun!fluke----------\ | Data I/O Corporation ..uw-beaver------------!tikal!pilchuck!tim 10525 Willows Road N.E. ..decvax!microsoft---/ Redmond, WA (206)881-6444
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 88 22:02:44 GMT From: lm@arizona.edu (Larry McVoy) To: comp.protocols.tcp-ip,comp.sources.wanted,comp.unix.questions Subject: Re: Application Programming Interface for FTP
In article <571@cgcha.cgch.UUCP> whna@cgch.UUCP (Heinz Naef) writes:
>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?
>
How about
/*
* send a file via ftp
*
* Bugs - no error checking/handling
* - password is in cleartext
*/
send(host, user, passwd, file)
char* host;
char* user;
char* passwd;
char* file;
{
FILE* ftp;
ftp = popen("ftp", "w");
fprintf(ftp, "open %s\n", host);
fprintf(ftp, "%s\n", user);
fprintf(ftp, "%s\n", passwd);
fprintf(ftp, "put %s\n", file);
pclose(ftp);
}
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: 16 Jan 88 00:44:43 GMT From: mike@devvax.JPL.NASA.GOV (Mike Tankenson) To: comp.protocols.tcp-ip Subject: Ethernet loopback interface problem
I have a question about the loopback interface found on our Sun workstations. Our problem is that when we do a netstat -a, a bunch of the following connections are formed (ie. dozens): Active connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 loopback.2703 loopback.sunrpc TIME_WAIT tcp 0 0 loopback.2702 loopback.sunrpc TIME_WAIT tcp 0 0 loopback.2701 loopback.sunrpc TIME_WAIT . . . These go away after awhile, but we can't figure out why they should be there in the first place. Here is our entry for loopback: 127.0.0.1 loopback lb localhost loghost datehost Here's some more funny stuff. One another Sun we have an entry of: 127.0.0.1 loghost me loopback localhost and there's no loopback connections created during a netstat -a! What could be the difference? We are running Sun OS 3.3 on our 'problem' Sun, and 3.4 on our 'good' Sun. Thanks in advance. --mike -- Mike Tankenson Telos/Jet Propulsion Laboratory - NASA 4800 Oak Grove Drive, Pasadena, CA. 91109 (818) 354-1447 Uucp: seismo!cit-vax!jplpro!mike Arpa: jplpro!mike@cit-vax.ARPA -or- mike@jplpro.JPL.NASA.GOV
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: 16 Jan 88 22:53:55 GMT From: bzs@BU-CS.BU.EDU (Barry Shein) To: comp.protocols.tcp-ip Subject: Ethernet loopback interface problem
Netstat will report the first name on the line in the host table (actually, the "official name" as returned by gethostbyaddr() which will be the first name after the numeric address. See 'man gethostent' for details.) You can change it if you like by just reordering the names and rebuilding the yellow pages (cd /etc/yp;make). -Barry Shein, Boston University
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: Sun, 17 Jan 88 21:32:25 -0500 From: Robert Hinden <hinden@PARK-STREET.BBN.COM> To: Thomas Narten <narten@PURDUE.EDU> Cc: Mills@LOUIE.UDEL.EDU, tcp-ip@SRI-NIC.ARPA, hinden@PARK-STREET.BBN.COM Subject: Re: Not a good day for EGP
Thomas, In fact, both Purdue gateways (Butterfly and LSI-11) have been up with out any restarts for a month or more. See attached status reports. Bob gstatus: 10/31/86 10:23 For documentation, type "gstatus \?" Beginning at Sun Jan 17 21:24:58 1988 (EST) Source Host: 10.2.0.82 (Arpanet inoc.bbn.com) Butterfly Gateway 91 PURD-BF 10.0.0.37 (Arpanet) Sun Jan 17 21:25:05 1988 (EST) Version 3.10 Gateway Number 32, Autonomous System 60 Last restart: 11/30 09:23 Interfaces: UP: PURD-BF 10.0.0.37 (Arpanet) UP: PURD-BF 128.210.2.1 (purdue-ccnet) UP: PURD-BF 128.10.2.200 (Purdue-CS) UP: PURD-BF 128.211.0.51 (purdue-cs-cyp) UP: PURD-BF 192.5.91.60 (purdue-ecn1) Gateway 16 PURDUE 10.2.0.37 (Arpanet) Sun Jan 17 21:25:09 1988 (EST) Version 1008.2 Last restart: 12/18 10:24 Features on: THR EGP RUP sequence number = 044630 Memory: 80784 bytes in use, 123368 bytes idle, 1680 bytes free Interfaces: UP: PURDUE 10.2.0.37 (Arpanet) (since 12/18 10:24) output q: 2, allocated: 48, data size: 1006 UP: PURDUE 192.5.48.6 (purdue-cs-net) (since 12/18 10:24) output q: 0, allocated: 31, data size: 1600 gstatus terminated at Sun Jan 17 21:25:09 1988 (EST)
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 1988 19:32-EST From: CERF@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: [The Mailer Daemon <Mailer@A.ISI.EDU>: Message of 9-Jan-88 ...]
Sigh - second attempt.
-v
Begin forwarded message
Date: Sat 9 Jan 88 10:48:39-EST
From: The Mailer Daemon <Mailer@A.ISI.EDU>
To: CERF@A.ISI.EDU
Subject: Message of 9-Jan-88 10:48:29
Message failed for the following:
tcp-ip@venera.isi.edu.#Internet: 550 <tcp-ip@venera.isi.edu>... User unknown
------------
Date: 9 Jan 1988 10:48-EST
Sender: CERF@A.ISI.EDU
Subject: SIGCOMM
From: CERF@A.ISI.EDU
To: tcp-ip@VENERA.ISI.EDU
Message-ID: <[A.ISI.EDU] 9-Jan-88 10:48:27.CERF>
With apologies to those of you who are not SIGCOMM members (you
should be!!), I am using this distribution list to clarify a
statement I made in the most recent Computer Communications Review
(the quarterly publication of ACM/SIGCOMM).
In that issue, I described a debate in which it was proposed, I
thought, to drop "conferences with papers" from the ACM/SIGCOMM
activities and to concentrate on focused workshops. In fact, I
misunderstood Dave Clark's suggestion. He was merely pointing out
that we should have only one such "paperful" conference sponsored
by SIGCOMM - other activities ought to be workshop in format.
Jose Garcia-Luna from SRI International also pointed out his objections
to dropping all conference activity from SIGCOMM - and hastened to
remind me that we have such a conference scheduled in October 88
(SIGCOMM 88 at Stanford University).
So, having been "reset" by two people whose opinions I certainly
respect, I intend to pursue the single, high-quality SIGCOMM
conference approach and to retain Datacomm in its workshop form.
Now, if you'll excuse me, I have go go charter a boat in Bimini...
Vint
-------
--------------------
End forwarded message
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 88 14:48:28 GMT From: sadler@shorty.UUCP To: comp.unix.wizards,comp.protocols.tcp-ip Subject: TCP/IP implementation over AT&T's STARLAN
The University of Wisconsin - Madison has recently recieved a few
3b1s through AT&T's University Grant Program. While we are glad
to have also been given a bunch of Ethernet cards with Wollingong
TCP/IP, we didn't get as many cards as machines. We recieved
enough Starlan cards to make up the ballance, though. This leads
up to my question.
Has anyone implemented TCP/TP on Starlan? I have been told by a
couple of friends that they had seen this at a USENIX a few years
ago, but they were not sure who had done it.
Does anyone know about this implementation of TCP/IP? If noone does, I
probably will end up doing this adaptation of the Wollingong software.
With that second part in mind, does anyone know anything about the starlan
driver and the Ethernet driver for the 3b1 computer?
All help is greatly appreciated.
Jonathan Sadler
Computing Systems Labratory
Computer Science Department
University of Wisconsin - Madison
+-------------------+-------------------+-------------------------------------+ ! Home ! Work ! On the Nets !
+-------------------+-------------------+-------------------------------------+ ! 1402 Regent #330 ! 1210 W. Dayton !Internet: sadler@{cs.wisc.edu !
! Madison, WI 53711 ! Madison, WI 53706 ! csd4.milw.wisc.edu} ! ! (608) 257-7549 ! (608) 262-2389 !UUCP: sadler@uwvax.UUCP !
+-------------------+-------------------+-------------------------------------+
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 1988 19:53-EST From: CERF@A.ISI.EDU To: Stevens@A.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Pseudo-Headers & Checksumming
Jim, I am going through a bunch of messages serially so I haven't yet seen any responses to your checksum query (if any). The pseudo-header was an attempt to fashion a true end/end checksum at the TCP level which included everything necessary at the TCP level to be sure you were getting a valid packet from the putative origin. We considered replicating information from the IP header in the TCP header as a way of making the TCP header easier to checksum, but the header was already so big, we decided to try the pseudo-header approach instead. It's possible that we just went too far on the "end/end" road and could have left some of the information covered in the TCP checksum out (that is, left it to IP level), but at the time, there was great concern that the IP level would only be checked host-gateway, gateway-gateway and gateway-host, not really end/end. So many times we found problems with lower level subsystems by doing end/end checking that we allowed ourselves the "awkward" luxury of the TCP pseudo-header. I seem to recall a recent exchange on TCP-IP in which the TCP level checksum proved very helpful in protecting against some LAN problems arising at the IP level, but that only underscores the value of end/end, not necessarily making an argument for the pseudo-header we chose for TCP. Really, my recollection of the pseudo header was to avoid making the TCP and IP headers redundant. Vint Cerf
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 88 16:50:41 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: A good day for timewarps
Folks, Two of the four Internet timetellers normally synchronized to NBS radio time have blown their springs. ISI (128.9.2.129) is ticking one year in the past and NCAR (128.116.64.3) is ticking one day in the future. The remaining two, UMD1 (128.8.10.1) and FORD1 (128.5.0.1), are presently in-chime with NBS; however, access to FORD1 is frequently unstable due to network problems. Since all NSFNET Backbone fuzzballs except U Maryland are synchronized to NCAR, these tockers will also be ticking one day in the future. At ISI the system startup file must be updated to the present year. Apparently, probably due to known hardware problems, the file was restored as of last year. At NCAR the bugfix I left on the disk there must be installed. Cornell was notified of the NCAR bug last week but so far has not installed the fix. I cannot do either of these things from here. Dave
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 88 18:17:39 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Not a good day for EGP
Folks, I am used to seeing some amount of trash in the core gateway routing tables, but this morning it has gotten out of hand. At the end of this message is a summary of the world according to the PURDUE LSI-11 core gateway. The first part shows the neighbors which at one time were up, but are at the moment offline, crashed or worse. The second part shows a mess of 68 apparently bogus nets (!) presently sloshing over all Internet corespeakers at the moment. I constructed this list from the full PURDUE routing table by deleting all named networks and all unnamed networks in the range 128.x.x.x, 129.x.x.x and 192.x.x.x. Some of the remainder are marked unreachable, so are not included in PURDUE routing updates sent to its neighbors. The others are in fact now sloshing all over the Internet, overflowing routing tables and crashing at least three EGPspeakers known to me. From the hop counts and first-hop gateways listed, I suspect counting-to-infinity is in progress on the MILNET side of the mailbridges, so the bogons might eventually evaporate from the core tables. However, the three EGPspeakers I watch are now crashing at intervals of a few hours, so the bogon generator may be barking at those intervals or less. I strongly suspect a malformed EGP update is being sent to a core gateway, which results not only in broken tables, but a malformed EGP update being sent back to the remaining EGP population. While my crashed EGPspeakers may deserve additional anti-bogon insulation, the bogonspeakers should be found and fried ASAP. Could it be that some list of gateways within an EGP update has overflowed a count field or broken a parser? Dave Gateway 16 PURDUE 10.2.0.37 (Arpanet) Sun Jan 17 09:52:25 1988 (EST) Neighbors: DOWN: golden-gateway.stanford.edu 10.1.0.11 (Arpanet) (EGP or indirect via EGP) DOWN: gateway.rice.edu 10.4.0.62 (Arpanet) (EGP or indirect via EGP) DOWN: a.cs.uiuc.edu 10.3.0.37 (Arpanet) (EGP or indirect via EGP) DOWN: rita.acs.washington.edu 10.1.0.91 (Arpanet) (EGP or indirect via EGP) DOWN: iu.ai.sri.com 10.5.0.2 (Arpanet) (EGP or indirect via EGP) DOWN: ISTC 10.1.0.107 (Arpanet) DOWN: gold.bacs.indiana.edu 10.7.0.37 (Arpanet) (EGP or indirect via EGP) DOWN: princeton.edu 10.7.0.96 (Arpanet) (EGP or indirect via EGP) DOWN: oberon.usc.edu 10.0.0.121 (Arpanet) (EGP or indirect via EGP) DOWN: ngp.utexas.edu 10.0.0.62 (Arpanet) (EGP or indirect via EGP) DOWN: think.com 10.4.0.6 (Arpanet) (EGP or indirect via EGP) DOWN: lad 10.6.0.62 (Arpanet) (EGP or indirect via EGP) DOWN: YALE 10.2.0.9 (Arpanet) (EGP or indirect via EGP) DOWN: 10.7.0.62 (Arpanet) (EGP or indirect via EGP) DOWN: 192.5.48.18 (purdue-cs-net) (EGP or indirect via EGP) DOWN: potomac.ads.com 10.5.0.25 (Arpanet) (EGP or indirect via EGP) DOWN: xn.ll.mit.edu 10.2.0.10 (Arpanet) (EGP or indirect via EGP) DOWN: columbia.edu 10.3.0.89 (Arpanet) (EGP or indirect via EGP) DOWN: teknowledge-vaxc 10.5.0.11 (Arpanet) (EGP or indirect via EGP) DOWN: utah-arpa-gw 10.3.0.4 (Arpanet) (EGP or indirect via EGP) DOWN: VAN 10.5.0.63 (Arpanet) (EGP or indirect via EGP) DOWN: TEST2 10.2.0.63 (Arpanet) (EGP or indirect via EGP) DOWN: 10.7.0.111 (Arpanet) (EGP or indirect via EGP) DOWN: 10.0.5.91 (Arpanet) (EGP or indirect via EGP) DOWN: att 10.5.0.89 (Arpanet) (EGP or indirect via EGP) Network Table: 193.252.102 4 hops (ext) via MILLBL 10.0.0.68 (Arpanet) 207.255.92 6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 125 Unreachable 127 Unreachable 159.249 5 hops (ext) via MILBBN 10.5.0.5 (Arpanet) 159.183 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 135.251 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.250.89 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 191.151 6 hops (ext) via MILISI 10.2.0.22 (Arpanet) 19 Unreachable 207.252.253 6 hops (ext) via MILISI 10.2.0.22 (Arpanet) 100 6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 159.250 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 143.151 4 hops (ext) via MILLBL 10.0.0.68 (Arpanet) 159.59 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.250.115 5 hops (ext) via MILARPA 10.2.0.28 (Arpanet) 207.250.83 6 hops (ext) via MILSAC 10.2.0.80 (Arpanet) 207.252.247 4 hops via MILDCEC 10.7.0.20 (Arpanet) 159.255 4 hops (ext) via MILLBL 10.0.0.68 (Arpanet) 207.255.40 6 hops (ext) via MILSAC 10.2.0.80 (Arpanet) 207.252.98 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 135.239 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 159.164 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 159.254 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.255.253 6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.255.167 6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 193.255.57 6 hops (ext) via MILISI 10.2.0.22 (Arpanet) 126 Unreachable 159.167 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 193.252.249 Unreachable 199.253.7 6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.252.220 6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 84 1 hop (ext) via umn-rei-uc 10.2.0.94 (Arpanet) 42 Unreachable 159.89 6 hops (ext) via MILISI 10.2.0.22 (Arpanet) 207.255.234 6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.253.52 4 hops (ext) via MILLBL 10.0.0.68 (Arpanet) 143.180 5 hops (ext) via MILBBN 10.5.0.5 (Arpanet) 193.252.205 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 199.250.83 4 hops (ext) via MILLBL 10.0.0.68 (Arpanet) 159.235 4 hops via MILDCEC 10.7.0.20 (Arpanet) 143.252 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.252.215 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.253.88 5 hops (ext) via MILBBN 10.5.0.5 (Arpanet) 143.250 6 hops (ext) via MILISI 10.2.0.22 (Arpanet) 207.253.217 6 hops (ext) via MILISI 10.2.0.22 (Arpanet) 207.252.249 5 hops (ext) via MILBBN 10.5.0.5 (Arpanet) 159.180 6 hops (ext) via MILISI 10.2.0.22 (Arpanet) 207.252.242 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 159.243 4 hops (ext) via MILLBL 10.0.0.68 (Arpanet) 131.237 4 hops (ext) via MILLBL 10.0.0.68 (Arpanet) 199.255.174 5 hops (ext) via MILARPA 10.2.0.28 (Arpanet) 159.149 6 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 61 Unreachable 207.252.172 4 hops via MILDCEC 10.7.0.20 (Arpanet) 60 Unreachable 207.255.51 6 hops via MILDCEC 10.7.0.20 (Arpanet) 199.253.217 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 199.253.202 5 hops (ext) via ISI 10.3.0.27 (Arpanet) 195.253.219 6 hops (ext) via MILISI 10.2.0.22 (Arpanet) 207.253.147 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.253.89 5 hops (ext) via ISI 10.3.0.27 (Arpanet) 207.252.255 6 hops (ext) via MILISI 10.2.0.22 (Arpanet) 207.243.181 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 63 Unreachable 159.210 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 159.62 5 hops (ext) via MILDCEC 10.7.0.20 (Arpanet) 207.250.17 5 hops (ext) via MILARPA 10.2.0.28 (Arpanet)
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 88 21:10:31 GMT From: narten@PURDUE.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: Not a good day for EGP
>Neighbors: > > DOWN: 192.5.48.18 (purdue-cs-net) (EGP or indirect via EGP) The list of "down" neighbors may be a bit deceiving. The machine 192.5.48.18 hasn't peered with Purdue LSI gateway since before Christmas. I would suggest that the LSI gateway hasn't been rebooted in over a month and that the entry is old, but... >However, the three EGPspeakers I watch are now crashing at intervals >of a few hours, so the bogon generator may be barking at those >intervals or less. Perhaps the definition of "crashed" needs to be examined. According to my own logs, the Purdue gateway has flawlessly responded to ICMP echoes every 15 minutes for the last 3 days. Although the gateway can probably reboot and completely rebuild all its route tables in only a few minutes, it seems unlikely that I would miss every one of the crashes. Thomas
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 88 21:17:54 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Agenda for Netman meeting on 21 Jan
The meeting set for this coming Thursday, Jan 21, at the Santa Clara Marriott has the following agenda: 9:00 Presentation of Architecture, Amatzia Ben-Artzi 10:30 Presentation of mapping from ISO to TCP/UDP, Marshall Rose Noon Lunch 1:30 Presentation of "Profile", Jim Robertson Then it will open up to a general discussion of managed objects and plans for implementation. Lee LaBarre wil act as discussion leader. If you are planning on attending and have not yet notified me, please do so. Either by email or by calling Advanced Computing Environments at 408-996-2042. Dan -------
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 00:32:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: [The Mailer Daemon <Mailer@A.ISI.EDU>: Message of 9-Jan-88 ...]
Sigh - second attempt.
-v
Begin forwarded message
Date: Sat 9 Jan 88 10:48:39-EST
From: The Mailer Daemon <Mailer@A.ISI.EDU>
To: CERF@A.ISI.EDU
Subject: Message of 9-Jan-88 10:48:29
Message failed for the following:
tcp-ip@venera.isi.edu.#Internet: 550 <tcp-ip@venera.isi.edu>... User unknown
------------
Date: 9 Jan 1988 10:48-EST
Sender: CERF@A.ISI.EDU
Subject: SIGCOMM
From: CERF@A.ISI.EDU
To: tcp-ip@VENERA.ISI.EDU
Message-ID: <[A.ISI.EDU] 9-Jan-88 10:48:27.CERF>
With apologies to those of you who are not SIGCOMM members (you
should be!!), I am using this distribution list to clarify a
statement I made in the most recent Computer Communications Review
(the quarterly publication of ACM/SIGCOMM).
In that issue, I described a debate in which it was proposed, I
thought, to drop "conferences with papers" from the ACM/SIGCOMM
activities and to concentrate on focused workshops. In fact, I
misunderstood Dave Clark's suggestion. He was merely pointing out
that we should have only one such "paperful" conference sponsored
by SIGCOMM - other activities ought to be workshop in format.
Jose Garcia-Luna from SRI International also pointed out his objections
to dropping all conference activity from SIGCOMM - and hastened to
remind me that we have such a conference scheduled in October 88
(SIGCOMM 88 at Stanford University).
So, having been "reset" by two people whose opinions I certainly
respect, I intend to pursue the single, high-quality SIGCOMM
conference approach and to retain Datacomm in its workshop form.
Now, if you'll excuse me, I have go go charter a boat in Bimini...
Vint
-------
--------------------
End forwarded message
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 00:53:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Pseudo-Headers & Checksumming
Jim, I am going through a bunch of messages serially so I haven't yet seen any responses to your checksum query (if any). The pseudo-header was an attempt to fashion a true end/end checksum at the TCP level which included everything necessary at the TCP level to be sure you were getting a valid packet from the putative origin. We considered replicating information from the IP header in the TCP header as a way of making the TCP header easier to checksum, but the header was already so big, we decided to try the pseudo-header approach instead. It's possible that we just went too far on the "end/end" road and could have left some of the information covered in the TCP checksum out (that is, left it to IP level), but at the time, there was great concern that the IP level would only be checked host-gateway, gateway-gateway and gateway-host, not really end/end. So many times we found problems with lower level subsystems by doing end/end checking that we allowed ourselves the "awkward" luxury of the TCP pseudo-header. I seem to recall a recent exchange on TCP-IP in which the TCP level checksum proved very helpful in protecting against some LAN problems arising at the IP level, but that only underscores the value of end/end, not necessarily making an argument for the pseudo-header we chose for TCP. Really, my recollection of the pseudo header was to avoid making the TCP and IP headers redundant. Vint Cerf
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 02:19:11 GMT From: mrose@gonzo.twg.COM (Marshall Rose) To: comp.protocols.tcp-ip Subject: Draft memo for Netman meeting on 21 Jan 88
A copy of the draft memo which will be discussed at the January
21st Netman meeting has been posted to the GWMON list. If you are
not on the list, but are planning to attend, please drop me a note
and I will send you a copy of the draft.
Comments on the draft will be solicited (and encouraged!) on
Thursday's meeting.
/mtr
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 02:32:25 GMT From: hinden@PARK-STREET.BBN.COM (Robert Hinden) To: comp.protocols.tcp-ip Subject: Re: Not a good day for EGP
Thomas, In fact, both Purdue gateways (Butterfly and LSI-11) have been up with out any restarts for a month or more. See attached status reports. Bob gstatus: 10/31/86 10:23 For documentation, type "gstatus \?" Beginning at Sun Jan 17 21:24:58 1988 (EST) Source Host: 10.2.0.82 (Arpanet inoc.bbn.com) Butterfly Gateway 91 PURD-BF 10.0.0.37 (Arpanet) Sun Jan 17 21:25:05 1988 (EST) Version 3.10 Gateway Number 32, Autonomous System 60 Last restart: 11/30 09:23 Interfaces: UP: PURD-BF 10.0.0.37 (Arpanet) UP: PURD-BF 128.210.2.1 (purdue-ccnet) UP: PURD-BF 128.10.2.200 (Purdue-CS) UP: PURD-BF 128.211.0.51 (purdue-cs-cyp) UP: PURD-BF 192.5.91.60 (purdue-ecn1) Gateway 16 PURDUE 10.2.0.37 (Arpanet) Sun Jan 17 21:25:09 1988 (EST) Version 1008.2 Last restart: 12/18 10:24 Features on: THR EGP RUP sequence number = 044630 Memory: 80784 bytes in use, 123368 bytes idle, 1680 bytes free Interfaces: UP: PURDUE 10.2.0.37 (Arpanet) (since 12/18 10:24) output q: 2, allocated: 48, data size: 1006 UP: PURDUE 192.5.48.6 (purdue-cs-net) (since 12/18 10:24) output q: 0, allocated: 31, data size: 1600 gstatus terminated at Sun Jan 17 21:25:09 1988 (EST)
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 03:04:55 GMT From: narten@PURDUE.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: Not a good day for EGP
>In fact, both Purdue gateways (Butterfly and LSI-11) have been up with out >any restarts for a month or more. See attached status reports. In that case, the extra bogus nets (or some other recent problem) may be causing the EGP servers to "burp" periodically. Three times in the last 4 days, the Butterfly EGP decided that we (128.211.1.1) were no longer an EGP neighbor, and restarted the neighbor aquisition protocol. In each case, events happened suddenly and without warning; no cease commands were received, and we had not even declared the Butterfly down for lack of responses to hellos & polls. I am fairly certain that this had not happening even once in the entire preceding month. I can't speak for the LSI-11 gateway, because we aren't peering with it anymore. Thomas
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 13:10:46 GMT From: swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) To: comp.protocols.tcp-ip Subject: Re: A good day for timewarps
I'd like to ask everyone **not** to use NCAR.NSF.NET (128.116.64.3) or any of the other *.nsf.net fuzzballs as time servers. Granted time service doesn't take too many resources, the NCAR fuzzball is a central node in NSFNET, with about 30-40 institutions on the other side of the ethernet it is connected to and lots of traffic going through it on its point-to-point links. It is already so congested that it spasms from time to time. A few cycles here and there at this point make a tremendous difference in the survivability of NSFNET. So PLEASE use one of the others to NTP-peer with. Scott
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 17:18:42 GMT From: asjoshi@phoenix.Princeton.EDU (Amit S. Joshi) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.ibm.pc,rec.ham-radio.packet Subject: Turbo C port of the KA9Q TCP/IP
Hello,
I have received a number of requests for the Turbo C port of the KA9Q
TCP/IP code. I have been mailing it out but now I am swamped. I thought
that only a few people would be interested in the code when I made the
offer to mail out copies. I shall therefore post the stuff to the net.
I would like to warn everybody that the version I have ported is NOT the
Christmas release. I am not using it for a packet radio, in fact I am
only using things to the socket level and so I have no plans to port the
Christmas release either. Also since I am not using most of the features
I have not tested them extensively. I am reasonably certain everthing
works over the ethernet with the 3COM board (I have used that portion),
but the rest I know that it compiles - I have fixed all the problems
that cropped in the ethernet portion and fixed similar code in other
places similarly.
My apologies to those people who requested and had to wait and then get
this message. I'll probably post to comp.protocols.tcp-ip.ibmpc unless I
get messages to the contrary soon.
--
Amit Joshi BITNET | Q3696@PUCC.BITNET
USENET | {seismo, rutgers}\!princeton\!phoenix\!asjoshi
"There's a pleasure in being mad... which none but madmen know!" - St.Dryden
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 17:40:58 GMT From: NIC@SRI-NIC.ARPA (DDN Reference) To: comp.protocols.tcp-ip Subject: ARPANET UPGRADE
The PSN 7.0 New End-to-End Deployment to the ARPANET
is now complete. The ARPANET is permanently running the
New End-to-End protocol, with no cutback to the Old End-to-End
anticipated, except if emergency conditions should arise. A
message from Ken Pogran describing the recent corrective actions is
"attached".
Minor problems are still being cleaned up, but none, we believe,
which seriously impact any users. Should problems arise or
persist, however, please continue to send messages to
ARPAUPGRADE@BBN.COM, call the BBN Hotline at (800) 492-4992 or DCA
at (703) 285-5445/5228.
We thank everybody for their past and continued cooperation
in this endeavor.
Ken Turkewitz (BBNCC), Russ Mundy (DCA), Annette Bauman (DCA)
------------------message from Ken Pogran---------------
Here's the latest on the trials and tribulations of the ARPANET
Beta Test of PSN 7 and the New End-to-End Protocol:
In a message entitled "Santa's PSN 7 status" that I sent on
23 December, I announced that BBN had found the solution to the
"stuck VC" problem afflicting Sun hosts connected to the ARPANET
with X.25, and that we had also determined that the "128 byte"
problem was a host problem. Well, Santa turned out to be a
Grinch, because we were dead wrong on both counts.
However, both problems have now (cross your fingers!) been fixed,
along with a few others. The problems (and their resolutions)
are as follows.
1. "Stuck VCs." See my previous messages for a detailed
description of the problem. In essence, asymmetric traffic
flows originating from an 1822-connected host and destined to
an X.25-connected host could result in a "deadly embrace",
with the destination host and the PSN each waiting for the
other to do something. Although this case sounds obscure, it
in fact corresponds to traffic flows from the MILNET (and
perhaps some other networks) across 1822-connected gateways
to the ARPANET and then to X.25-connected hosts -- a common
situation. This problem specifically afflicted Sun hosts,
due to implementation choices Sun made in their X.25 code.
After much discussion, our designers were convinced
that Suns's implementation choices were in fact reasonable (our
apologies to Bill Melohn at Sun for our being hard over in
the other direction at first) and that the PSN's behavior
needed to change to more closely resemble that under the Old
End-to-End protocol (which obviously did not result in a
deadly embrace).
Accomplishing the desired change in behavior in the PSN
turned out to be a lot more complex than we thought; we went
through several iterations of "fixes" each of which we
thought would do it but each of which turned out to be
incomplete in handling some obscure case or other and was
therefore incorrect. (The 1822-X.25 interoperability module
in the PSN is, in effect, a level 3 protocol converter
tightly integrated into the End-to-End Protocol machinery,
and it has all the complexity that protocol converters
typically have. The ultimate "fix" involves a design change
rather than a simple coding fix; the design issues are
probably worth an RFC at some point.) Last weekend we bit the
bullet and designed and coded a much more complex change,
which was tested at selected nodes early this week, with
complete success. The "stuck VC" dragon has, we believe,
finally been slain. Our apologies to everyone on the ARPANET
with an X.25-connected Sun who's been waiting for a fix to
this problem, and our thanks to Bill Melohn of Sun and Bob
Enger of Contel for their patience, which we sorely tried.
2. The "128 byte" problem. X.25 packets of length 128 or
multiples thereof appeared to be "lost" under certain
circumstances. The circumstances under which such packets
were "lost" were, again, communication FROM an 1822-connected
host TO an X.25-connected host. Upon looking at the line
between a PSN and a Sun host with a datascope, we saw "pings"
of such packets going into the Sun, with no response from the
Sun, and concluded it was a Sun problem. Sun looked more
closely than we and noticed that the packet the PSN sent had
the "M" bit set, indicating this was one packet of a
multi-packet sequence, but the PSN never sent another packet.
This was, in fact, another PSN 1822-X.25 interoperability bug
which has now been found and fixed.
3. The HDH problem affecting Yale and Rice. There were several
bugs in the PSN 7 HDH interface code that kept Yale and Rice
off the air a good bit of the time since PSN 7 was deployed.
These bugs, too, have now been found and fixed.
-------
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 21:46:27 GMT From: nowicki@SUN.COM (Bill Nowicki) To: comp.protocols.tcp-ip Subject: Subnet support in SunOS 3.3
Last week there were several incorrect messages to this list about the IP subnet support in SunOS releases. As developer of this software, I would like to brave the flames and clear up the misconceptions. All SunOS releases support any number of any combination of Class A, B, or C internet addreses, and will route between them. Release 3.3 and beyond (3.5 is the current release) support any number of non-subnetted networks (standard subnet masks), and any number of interfaces on a subnetted IP network (a single non-standard mask). 3.3 was to support sites like Berkeley and Stanford, that tend to have a single class A or B network number, with routers connecting the various subnets together, and connecting them to the outside world (e.g. Arpanet). Suns can be used for any of these routing functions. Some more esoteric configurations with multiple (DIFFERENT) non-standard netmasks on the same machine are supported in a release that is currently in Beta test. ALL releases since 3.3 handled (and never forwarded) all six kinds of broadcast addresses. As described in RFC950, subnets of all zeros should not be used, and a single netmask should be used throughout a single IP network number. Some specific examples of supported configurations are given in the release documentation; in general it is a good idea to read the manual first before posting a message to a world-wide distribution list. -- Bill Nowicki Sun Microsystems
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 21:49:06 GMT From: karn@FALINE.BELLCORE.COM (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Fun and Games with TCP/IP
I posted this note on the USENET amateur packet radio group last weekend, and a few people suggested that this group might appreciate it also. Phil From: karn@faline.bellcore.com (Phil R. Karn) Newsgroups: rec.ham-radio.packet Subject: Amateur TCP/IP path contest Message-ID: <1712@faline.bellcore.com> Date: 15 Jan 88 22:29:27 GMT Organization: Bell Communications Research Now that TCP/IP is really starting to take off in the amateur world, I think it would be fun to start a running contest. The goal is to see who can come up with the most complex, ad-hoc Internet path involving one or more amateur packet radio links. This is inspired by Mike O'Dell's famous "worst wire" contest. The only requirement is that the path must actually work! At a minimum, you must successfully complete a three-way TCP handshake and then successfully close the connection. To start things off, I'd like to describe an experiment we did last weekend. As many of you know, Telenet has this nifty service called PC Pursuit. From any Telenet access number, you may connect to a remote dialout modem in in something like 6 metropolitan areas. As long as you use it only during evenings and weekends, it costs $25/month -- flat rate! Several amateur TCP/IP groups have begun using PC Pursuit to link their otherwise isolated "islands", with excellent results. Last weekend Al, WB0MPQ (another resident of Warren, NJ) dialed up a PC Pursuit link to Brian, WB6RQN, in the Maryland suburbs of DC. While the link was up, I had Bob, WA3PXX, telnet briefly to a Bellcore machine named "sabre" in Navesink, NJ. The path was as follows: Node, location Link/Subnetwork ---- ---- ---------- wa3pxx.ampr (PC/XT) 222.06 Mhz AX.25 link duplex RF repeater Gaithersburg, MD(?) 223.66 Mhz AX.25 link wb6rqn.ampr (PC/AT) Germantown, MD SLIP on 1200 baud dialup phone line (C&P Tel) Telenet dialer port Washington, DC GTE Telenet X.25 network Telenet TIP port Rahway, NJ SLIP on 1200 baud dialup phone line (NJ Bell) wb0mpq.ampr (PC/XT) Warren, NJ 147.525/430.05 Mhz full duplex AX.25 link switch.ka9q.ampr (PX/XT) Warren, NJ KA9Q shack Ethernet sun.ka9q.ampr (Sun 3/75) SLIP on 9600 bps dialup phone line (NJ Bell) Micom terminal switch Piscataway, NJ T-1 leased line (portion) (NJ Bell) Micom terminal switch Morristown, NJ hardwired RS-232 line doomsday.bellcore.com (Sun 2/170) Lab Ethernet Ethernet repeater Machine room central Ethernet DEC Lan Bridge Building backbone Ethernet Ethernet repeater Building "core" Ethernet Vitalink Translan T-1 leased line (portion) (NJ Bell) Vitalink Translan Piscataway, NJ T-1 leased line (portion) (NJ Bell) Vitalink Translan Navesink, NJ building backbone Ethernet DEC Lan Bridge Building wing Ethernet DEC Lan Bridge Lab Ethernet sabre.bellcore.com (Vax 11/750?) ...and back. This was a direct end-to-end connection; the TCPs on wa3pxx.ampr and sabre.bellcore.com spoke directly to each other. Excluding the endpoints themselves, the path their IP datagrams took included: 8 Ethernets 5 IP gateways (2 Suns, 3 PC's running KA9Q net.exe) 4 radio frequencies on 3 amateur bands 3 dialup phone links (2 @ 1200 baud, 1 @ 9600 baud) 3 T-1 digital leased lines with multiplexors 3 Vitalink Translan IIIs 3 DEC Translan 100s 2 Micom terminal switches 2 Ethernet repeaters 1 full duplex RF repeater 1 public X.25 network (Telenet) 1 partridge in a pear tree :-) So...can anybody top this? Who will be the first to include an amateur satellite link in a TCP/IP path once AMSAT Phase 3-C is launched later this year? 73, Phil
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 22:46:39 GMT From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) To: comp.protocols.tcp-ip Subject: TN3270 RFC
Good afternoon! I have heard rumblings for the past couple of weeks about an RFC detailing negotiations and options for TN3270 specifically, but I was wondering if there is any "hard" date when something like this will be around. Anyone have the inside line on this? Thanks in advance, Chris Vandenberg ACC (chris@acc-sb-unix.arpa)
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 88 22:54:05 GMT From: philipp@GMUVAX2.GMU.EDU (Philip Prindeville) To: comp.protocols.tcp-ip Subject: Where to find... supdup and tn3270 specs
Hi. I need to know whatever happened to the ad hoc tn3270 group -- did they ever produce and RFC and if so where can it be FTPd from? Also, is there a formal description of SUPDUP that doesn't presume PDP-10 assembly language programming (or indeed, NCP and 9 bit bytes)? I've never hacked on a PDP-10 (I guess I've been unlucky :-), and I'm using TCP (aren't we all?). Thanks, -Philip
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 88 07:13:40 EST From: Bruce Crabill <BRUCE%UMDD.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: TN3270 RFC
My understanding is that it was sent to Jon Postel back in November or
December and is currently sitting on his desk.
Bruce
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 03:59:39 GMT From: kopaz@rdlvax.RDL.COM (John 'Echo' Kopaz) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.sys.ibm.pc,comp.unix.questions Subject: Help!!! token rings
prelude: i know very little about nets and stuff (enough to be dangerous).... question: what would be required (hw/sw) to connect a token ring of pc's to an ethernet of suns, vaxen, and an alliant? i want to be able to rlogin from the pc's and/or submit jobs to mdqs. i would also like to to stick to tcp/ip as transfer/internet protocols on the token ring (if i can...). query: can pc-nfs do this??? ( it would be nice to have all systems under nfs.....) background: we are running bsd4.3 on the vax, the current sun release, and a bsd4.2 derivative on the alliant ( all these under nfs ). we are running desk view on the pc's ( also trying other multitasking dos ). plead: where would i look to gain knowlage in this area? texts, papers, etc... ( taking the prelude into concideration ) respond: via email please ( i don't have time to read the news all the time.:-) disclamer: the spelling is mine. signature:
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 04:07:48 GMT From: kopaz@rdlvax.RDL.COM (John 'Echo' Kopaz) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.sys.ibm.pc,comp.unix.questions Subject: Help!!! token rings
( sorry about the multiple post. this one includes my .sig....)
prelude: i know very little about nets and stuff
(enough to be dangerous)....
question: what would be required (hw/sw) to connect a token ring of pc's
to an ethernet of suns, vaxen, and an alliant? i want to be
able to rlogin from the pc's and/or submit jobs to mdqs. i
would also like to to stick to tcp/ip as transfer/internet
protocols on the token ring (if i can...).
query: can pc-nfs do this??? ( it would be nice to have all systems
under nfs.....)
background: we are running bsd4.3 on the vax, the current sun release, and
a bsd4.2 derivative on the alliant ( all these under nfs ).
we are running desk view on the pc's ( also trying other
multitasking dos ).
plead: where would i look to gain knowlage in this area?
texts, papers, etc... ( taking the prelude into concideration )
respond: via email please ( i don't have time to read the news all the
time.:-)
disclamer: the spelling is mine.
signature:
___ ,, __ ,, _ ,
( > / / ` / ' ) /
__/______/_ ____ /-- _. /_ __ /-< _____ __. __.
/ / (_) / /_/ / <_ (___, (__/ /_(_) / ) (_) /_)_(_/|_/ |_
<_/ / (|
john a. kopaz [aka echo.] '
research scientist by association / test specimen
voice: 213-410-1244 -- fax: 213-216-5940 -- corporeal: rdl
arpa : kopaz@rdlvax.rdl.com 5721 w. slauson ave.
uucp : ...!{psivax,csun,sdcrdcf,ttidca}!rdlvax!kopaz culver city, ca 90320
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 88 13:53:06 -0500 From: Andy Malis <malis@CC5.BBN.COM> To: "Barry D. Hassler" <wrtfac!hassler@LOGNET2.ARPA> Cc: malis@CC5.BBN.COM, tcp-ip@SRI-NIC.ARPA Subject: Re: IP class B and C to X.25 address translation
The following message didn't seem to make it out of my host when
I sent it the first time. Since this is a topic that comes up
from time to time, I thought I would resend it.
Andy
------- Forwarded Message
To: "Barry D. Hassler" <wrtfac!hassler@LOGNET2.ARPA>
cc: malis,tcp-ip@sri-nic.arpa
Subject: Re: IP class B and C to X.25 address translation
In-reply-to: Your message of Sun, 27 Dec 00 19:87:13 +0000.
<7137.8712280332@wrtfac.cdc.com>
Date: Mon, 28 Dec 87 11:44:33 -0500
From: Andy Malis <malis@cc5.bbn.com>
Barry asked the following:
Has there been any standardization on the translation of
Class B or C IP addresses to X.25 addresses? I am aware
of the translation standard for Class A addresses, but
have not seen any for B or C.
Barry,
There is an informal standardization for Class B: the first two
octets of the IP address are the network number, the third octet
is treated identically to the second octet of Class A addresses,
and the fourth octet is treated identically to the fourth octet
of Class A addresses. The third octet of Class A addresses is
dropped completely in Class B addresses.
There is absolutely no standardization for Class C, because there
are so few local network address bits to play with. The host
network software support person for Class C nets must provide his
or her own mapping between the Class C addresses and X.25
addresses for that net. For example, the five most significant
bits of the fourth octet of the Class C address could be the host
number, and the three least significant bits the PSN number. It
is a compromise between the number of PSNs on the network and the
maximum number of hosts on a PSN.
Regards,
Andy
------- End of Forwarded Message
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 16:24:00 CST From: "CALVIN R. GEORGE" <george@eglin-vax.arpa> To: "tcp-ip" <tcp-ip@sri-nic.ARPA> Subject: POSIX
Pardon me for bugging this community but can someone point me to a POSIX interest group or tell me where I can get a recent stab at the POSIX standard? I understand that NBS has accelerated their efforts and may be ahead of IEEE in coming up with a standard. Any help would be appreciated. thanks, Calvin George ------
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 12:13:40 GMT From: BRUCE@UMDD.BITNET (Bruce Crabill) To: comp.protocols.tcp-ip Subject: Re: TN3270 RFC
My understanding is that it was sent to Jon Postel back in November or
December and is currently sitting on his desk.
Bruce
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jan 88 17:32:04 EST From: Doug Nelson <08071DEN%MSU.BITNET@CUNYVM.CUNY.EDU> To: zgel05@apctrc.uucp, tcp-ip@sri-nic.arpa Subject: Re: Spooky Routing by Sun TCP/IP
>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? Is the Sun responding to the KNET using its 193.9.202 address (it should be)? If so, it shouldn't matter that the response comes back on the "wrong" interface. What version of the KNET software are you running? I have seen cases where it refuses to acknowledge other nodes that aren't listed in its tables, and I suspect this is another symptom of that problem. I also think that this may be fixed in the latest KNET release. So, the answer may not be that the Sun is being too smart, but that the KNET is being too dumb. Doug Nelson Michigan State University Computer Laboratory
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 15:35:35 GMT From: larry@pdn.UUCP (Larry Swift) To: comp.protocols.tcp-ip Subject: multicast
Is there any way a socket can be specified as a multicast to (specifically)
two destinations rather than one or all (ie, broadcast)?
Larry Swift UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207 Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 16:52:50 GMT From: EWR@SEED.AMS.COM (Betsy Ramsey) To: comp.protocols.tcp-ip Subject: VAX/VMS TCP/IP and cisco AGS Gateway
I am still having problems using the VMS CMU TCP/IP software with our cisco systems AGS-1E1D (DDN X.25) gateway, but I'd like to thank those who have responded with suggestions. (Please keep them coming!) I'd also like to say that the support people at cisco have been very responsive, even though the problem is almost certainly with the CMU software, not their gateway (which is working fine with our DEC-20s on the same Ethernet as the VAXs). -------
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 18:53:06 GMT From: malis@CC5.BBN.COM (Andy Malis) To: comp.protocols.tcp-ip Subject: Re: IP class B and C to X.25 address translation
The following message didn't seem to make it out of my host when
I sent it the first time. Since this is a topic that comes up
from time to time, I thought I would resend it.
Andy
------- Forwarded Message
To: "Barry D. Hassler" <wrtfac!hassler@LOGNET2.ARPA>
cc: malis,tcp-ip@sri-nic.arpa
Subject: Re: IP class B and C to X.25 address translation
In-reply-to: Your message of Sun, 27 Dec 00 19:87:13 +0000.
<7137.8712280332@wrtfac.cdc.com>
Date: Mon, 28 Dec 87 11:44:33 -0500
From: Andy Malis <malis@cc5.bbn.com>
Barry asked the following:
Has there been any standardization on the translation of
Class B or C IP addresses to X.25 addresses? I am aware
of the translation standard for Class A addresses, but
have not seen any for B or C.
Barry,
There is an informal standardization for Class B: the first two
octets of the IP address are the network number, the third octet
is treated identically to the second octet of Class A addresses,
and the fourth octet is treated identically to the fourth octet
of Class A addresses. The third octet of Class A addresses is
dropped completely in Class B addresses.
There is absolutely no standardization for Class C, because there
are so few local network address bits to play with. The host
network software support person for Class C nets must provide his
or her own mapping between the Class C addresses and X.25
addresses for that net. For example, the five most significant
bits of the fourth octet of the Class C address could be the host
number, and the three least significant bits the PSN number. It
is a compromise between the number of PSNs on the network and the
maximum number of hosts on a PSN.
Regards,
Andy
------- End of Forwarded Message
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 20:59:14 GMT From: german@UXC.CSO.UIUC.EDU (Gregory German) To: comp.protocols.tcp-ip Subject: Help!!! token rings
I am currently un-aware of any PC NFS products that would work with the
4Mbs Token Ring. If there is such a product please let me know.
I a currently using the IBM TCP/IP for the PC to TELNET, FTP, etc to
from other TCP/IP machines on our network. The IBM software includes
an IP gateway between Token Ring, IBM PC Network (new cards) and ethernet.
The IBM software is part of Program Number 5798-FAL. It has a fair number of
TCP/IP based programs which I will not detail here. The TELNET emulates an
h19u ascii terminal or uses tn3270 if talking to a VM host. TFTP and FTP
are available, though there is no server mode for FTP. There are also
several commands to deal with mail from the PC that I have not played with,
but they seem based on the Rand Mail Handler as far as the user interface
is concerned and use SMTP to POP server.
Though I haven't tried it you could probably also gateway with a Proteon
p4200 with both 4Mbs token ring and ethernet.
I belive FTP has suport for TCP/IP on the token ring, though I am uncertain
what they recomend at the gateway between token ring and ethernet.
Hope this helps some,
Greg German (german@uxc.CSO.UIUC.EDU) (217-333-8293)
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801
Office: 181 Digital Computer Lab.
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 21:25:42 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: IP class B and C to X.25 address translation
Andy -
For the record, PANDA and BBN TOPS-20's implement class C
PSN addresses as being in old ARPANET 8-bit format; that is, the
low order 6 bits is the PSN number and the high order 2 bits is
the host number. This is relatively simple to change, though,
and to my knowledge no TOPS-20 system is on a class C PSN network.
All TOPS-20's use 1822 instead of X.25 when talking to PSN's.
-- Mark --
-------
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 22:07:00 GMT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Where to find... supdup and tn3270 specs
Date: Mon, 18 Jan 88 17:54:05 est
From: philipp@gmuvax2.gmu.edu (Philip Prindeville)
Hi.
I need to know whatever happened to the ad hoc tn3270
group -- did they ever produce and RFC and if so where can it
be FTPd from? Also, is there a formal description of SUPDUP
that doesn't presume PDP-10 assembly language programming (or
indeed, NCP and 9 bit bytes)? I've never hacked on a PDP-10
(I guess I've been unlucky :-), and I'm using TCP (aren't
we all?).
SUPDUP is RFC734. It does not use 9-bit bytes for transmission; it uses
8 bit bytes and works today over TCP and CHAOS (and any other 8-bit
meduim). (It took me all of two hours to convert the ITS SUPDUP server
and/or user to TCP from NCP.) Many of the definitions look like they
deal with 12 or 36 bit quantities, but view them as logical fields
instead of parts of a 36 bit word. I have written and maintained user
ends of SUPDUP for PDP-11s (many years ago) so things aren't really that
PDP-10/ITS specific.
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 22:10:22 GMT From: CASNER@VENERA.ISI.EDU (Stephen Casner) To: comp.protocols.tcp-ip Subject: Re: A good day for timewarps
Folks, The system startup file for WWVB.ISI.EDU has been reentered to bring it up to 1988, so it should once again be ticking the correct time. -- Steve -------
-----------[000219][next][prev][last][first]----------------------------------------------------
Date: 19 Jan 88 22:24:00 GMT
From: george@EGLIN-VAX.ARPA ("CALVIN R. GEORGE")
To: comp.protocols.tcp-ip
Subject: POSIXPardon me for bugging this community but can someone point me to a POSIX interest group or tell me where I can get a recent stab at the POSIX standard? I understand that NBS has accelerated their efforts and may be ahead of IEEE in coming up with a standard. Any help would be appreciated. thanks, Calvin George ------
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 88 22:31:44 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: Where to find... supdup and tn3270 specs
Philip Prindeville -
I wrote the SUPDUP RFC (RFC 734) 10 years ago. It doesn't
require any knowledge of PDP-10 assembly language programming,
although it was written in a day when PDP-10 conventions were
more widely understood. Today, I would probably write it a bit
differently.
However, it isn't that difficult to understand octal numbers
or even the n,,m format. n,,m is a way of specifying a 36-bit
quantity, where n is the more significant 18 bits and m is the
least significant 18 bits. PDP-10's are big-endian, so the number
120,,54 is equivalent to 00012000054 bit is easier to understand.
36-bit quantities are only used in the terminal code registers
sent at startup. They're sent as 6-bit bytes (in our example, as
00 01 20 00 00 54) and on a byte-oriented machine I'd store them
in the least significant 6 bits of 6 consecutive 8-bit bytes.
If you bothered to read the RFC, you'd realize that there
are no NCP dependencies at all; the connections are 8-bits. A
9 and 12-bit character set for keyboard INPUT are possible for
operating systems which swallow them. The rules for folding
such characters down are well defined in the RFC, and if a
client SUPDUP doesn't want to send such characters it doesn't
have to (all it has to do is not set the bit saying it has such
a keyboard).
People who have never seen a line of PDP-10 assembly code
have read, understood, and implemented Unix code based on the
SUPDUP RFC. Give it a try.
-- Mark --
-------
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 00:52:31 GMT From: dave@vdelta.UUCP (Dave Arnold) To: comp.protocols.tcp-ip,comp.lang.c Subject: C binding interfaces for TCP/IP
I am new to TCP/IP, so please excuse me if this is elementary, but... Could someone please tell me what approach is taken for applications programs to use a TCP/IP network? More specifically, what does a C program look like that is doing network I/O on a TCP/IP network? Is the source code for the FTP client portable across all systems on the ARPA Internet? Are there efforts underway to standardize a C language interface for TCP/IP? I have asked a particular vendor about this for VAX/VMS, and all he said was "You get a QIO interface". Great, so when we migrate to OSI, we will have to rewrite all our software. How does BSD sockets and streams fit into this? We would like to create a "Virtual network runtime library", that would allow application programs to interface to any kind of network. Has such a model already been suggested? Does anybody think that this idea is not feasable? Thanks in advance. Dave Arnold dave@arnold.UUCP
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 88 15:16 MDT From: <STGEORGE%UNMB.BITNET@CUNYVM.CUNY.EDU> To: tcp-ip@sri-nic.arpa Subject: Hop problem
Can anyone tell me the status of thw work being done to get around the limitation of TCP/IP to a hop of 15 nodes? Thanks.
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 13:44:43 GMT From: dunigan@ORNL-MSR.ARPA (Tom Dunigan 576-2522) To: comp.protocols.tcp-ip Subject: seeking experiences with IBM 9370 tcp/ip
Our IBM types are planning on installing and evaluating an IBM 9370,
including an Ethernet tcp/ip connection. We would be interested
in the experiences of others with the 9370 tcp/ip. (Is the
software just the wiscnet stuff?)
thanks
Tom Dunigan
dunigan@ornl-msr.arpa
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 15:21:00 GMT From: stanonik@NPRDC.ARPA (Ron Stanonik) To: comp.protocols.tcp-ip Subject: imp->psn upgrade, ecu override
Our imp (26) was recently upgraded to a psn. Our interface
was an lhdh through an ecu to an ecu at the imp. Our interface
is still an lhdh through an ecu, but the former ecu at the
imp was replaced by something that came with the psn. What's
puzzling is that the folks doing the installation had us set
our ecu to override ("disable error overflow induced reset").
At one time it was very important not to override because we'd
lose rfnm's and without an imp reset our operating system
(4.1bsd, 4.2bsd?) would hit an rfnm limit and not open any
more network connections. Since the imp-to-psn switch, we've
noticed lost rfnm's again (and coincidently our operating system,
4.3bsd, going comatose). Maybe this will go away with the
recent 1822-to-x.25 fixes to the psn's, but we still wonder
if our ecu should be set to override? Any ideas?
Thanks,
Ron Stanonik
stanonik@nprdc.arpa
-----------[000225][next][prev][last][first]----------------------------------------------------
Date: 20 Jan 88 15:56:36 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Help!!! token ringsWe do indeed have products for token rings: One for the IBM TOKREUI software interface (which is emulated by some other vendors), and one for the Proteon P1340/1344 card in native mode. As of this moment, the TOKREUI version supports source-routing on bridged rings, the P1340 doesn't yet. We don't include an NFS, but we do have Telnets (including TN3270), Rlogins, SMTP mail (no POP), FTP client & server, TFTP client/server, LPR, REXEC, RSH, RCP, Finger, etc. Our software can use any IP router that has an interface for 802.5, including P4200s, IBM software, or RTs with 4BSD and multiple interfaces. James VanBokkelen FTP Software Inc.
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 16:11:09 GMT From: jtn@potomac.ads.com (John T. Nelson) To: comp.protocols.tcp-ip Subject: Re: ARPANET UPGRADE
> The PSN 7.0 New End-to-End Deployment to the ARPANET > is now complete. The ARPANET is permanently running the > New End-to-End protocol, with no cutback to the Old End-to-End > anticipated, except if emergency conditions should arise. A > message from Ken Pogran describing the recent corrective actions is > "attached". > > Minor problems are still being cleaned up, but none, we believe, > which seriously impact any users. > > Ken Turkewitz (BBNCC), Russ Mundy (DCA), Annette Bauman (DCA) Our site is seriously impacted. Our machine (potomac.ads.com) is unable to talk to the ARPAnet (except sun.com which is an X.25 site like us, running the DDN software provided by Sun. I take it from the above message that BBN no longer feels the problem is with the 7.0 PSN software but rather with the sites. -- John T. Nelson UUCP: sun!sundc!potomac!jtn Advanced Decision Systems Internet: jtn@potomac.ads.com 1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611 "Hi... My name is Hobbes. I'm the product of a malicious 5-year old's twisted and destructive imagination. Would YOU like to be my friend?"
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 17:23:00 GMT From: WWB.TYM@OFFICE-1.ARPA (Bill Barns) To: comp.protocols.tcp-ip Subject: Which gateway boxes can do this?
We might want to set up an IP net along the following lines. Money will be tight at first, but maybe will grow (with usage). For the configuration I am now envisioning, a gateway box with the following characteristics would seem to be in order. I would like to hear any information on which of the gateway gadgets on the market can do most or all of the below listed things in a reasonable fashion. Opinions on the relative merits of vendor's implementations, support, etc., would also be of interest. Description: This box should be an IP Gateway (Router) capable of interfacing to: (1) ARPANET or MILNET PSN using both 1822DH and DDN X.25 style interfaces. [There is an issue of port availability which may require DH initially. X.25 is ultimately desired. Naturally we would not want to have to buy different boxes at that point.] (2) Ethernet. 1 initially, possibly 2. (3) Another of its own kind at a very distant point, preferably via an assortment of leased line types such as 9.6 voice grade modem, 50kb analog, 56kb DDS, whatever the demand eventually warrants. It is probable that a large proportion of the IP traffic will cross this wire!! (4) Public data network such as TYMNET, for the purpose of performing function (3). This is not indispensable but would be very nice to have, e.g., have permanent VC through the PDN to connect the 2 (or possibly more) geographically separate gateway boxes. There is a chance that help with certification can be arranged if someone thinks they have the code but hasn't gotten to certification yet. Of course, in return for help we would expect concessions. Beyond the link interface requirements, all the obvious protocol requirements for an IP gateway apply. Support for DECNET would be nice to have. The product as a whole must be supported by the vendor, i.e., we want somebody else to fix bugs and deal with evolution of the protocol world. I am in rather a hurry to get at least some generalities together for the end users. I know who some of the potential vendors would be, but probably not all, and in some cases the descriptive info I have just isn't very clear. Thus I would be appreciative of any definite statements or educated guesses about who can actually deliver such a thing. Proteon, cisco Systems, and probably Sun seem to be in the ballpark. There are hints that Ford Aerospace and possibly Bridge may have something. If there's anyone else I should talk to, let me know who and where. Please reply directly. I will summarize to net if requested. Thanks in advance for all information and assistance. Bill Barns ARPA: WWB.TYM@OFFICE-1.ARPA
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 17:37:35 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Where to find... supdup and tn3270 specs
Some people think SUPDUP is a swell protocol. Why doesn't one of them take the time to write a reasonable protocol RFC on SUPDUP, without assuming 36-bit machines. Then the rest of the Internet world can find out how wonderful SUPDUP is. Bob Braden
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jan 88 22:44:32 EST From: Nick Gimbrone <NJG%CORNELLA.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: seeking experiences with IBM 9370 tcp/ip
>Our IBM types are planning on installing and evaluating an IBM 9370, >including an Ethernet tcp/ip connection. We would be interested >in the experiences of others with the 9370 tcp/ip. (Is the >software just the wiscnet stuff?) The IBM TCP/IP for VM product (5798-FAL, or just FAL for short :-) has its roots in the Wiscnet package. BUT (a big but) the code has been extensively worked on by IBM Yorktown. The current FAL product is faster, more stable, and in all around better than Wiscnet ever was. I would not make any negative assumptions based upon earlier experiences with the Wiscnet code. On the hardware side (the 9370 and its ethernet controler) I'm afraid I cann't offer any words of wisdom. For discussions of FAL software (and related hardware issues) you might want to join the IBMTCP-L list hosted at CUNYVM.CUNY.EDU (or CUNYVM.BITNET). (I believe you subscribe by sending a one line mail file containing 'SUB IBMTCP-L <your name>' to LISTSERV@CUNYVM.CUNY.EDU, but I may be wrong.)
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 20:12:53 GMT From: hrp@ishmael.CRAY.COM (Hal Peterson) To: comp.protocols.tcp-ip Subject: C binding interfaces for TCP/IP
There is a /usr/group technical committee working on a standard Network Interface, probably for eventual inclusion in POSIX. The chairman of the Network Interface Technical Committee is Steve Albert, reachable at ihnp4!research!ssa. I don't know if this does you any immediate good for VMS, but it may provide a model for your virtual network runtime library. Hal Peterson / Cray Research / 1345 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-5884
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 21:02:01 GMT From: mdm@trwrb.UUCP (Michael D. Marcinkevicz) To: comp.protocols.tcp-ip Subject: Info on DECnet-TCP/IP gateway hardware & software
What hardware/software are you using for your DECnet-TCP/IP gateway?
We will soon be acquiring the DEC ULTRIX DECnet-TCP/IP gateway
software package. Any information you have on your evaluation
of the product or third party vendors for the MicroVax II or Sun Microsystems
machines would be greatly appreciated. ALSO, any other third-party equipment
that performs DECnet-TCP/IP routing would be helpful.
At the end of the discussions, I'll distribute a summary of comments
received.
Michael Marcinkevicz (213) 812-2154
TRW Space and Defense Sector, Communications services
trwrb!mdm@trwind.TRW.COM (ARPA)
...{decvax,ihnp4,ucbvax}!trwrb!mdm (UUCP)
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 21:02:15 GMT From: mdm@trwrb.UUCP (Michael D. Marcinkevicz) To: comp.protocols.tcp-ip Subject: Re: seeking experiences with IBM 9370 tcp/ip
We'll be installing ACCES/MVS on our 3090-400 and 3084QX to allow
us a TCP/IP interface for our IBM hosts and the rest of the net (LAN).
I'll post our evaluation when complete.
Michael Marcinkevicz (213) 812-2154
TRW Space and Defense Sector, Communications services
trwrb!mdm@trwind.TRW.COM (ARPA)
...{decvax,ihnp4,ucbvax}!trwrb!mdm (UUCP)
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 21:11:27 GMT From: jsq@longway.UUCP (John S. Quarterman) To: comp.protocols.tcp-ip Subject: Re: POSIX
>Pardon me for bugging this community but can someone point me to a >POSIX interest group or tell me where I can get a recent stab at the >POSIX standard? Yes: std-unix@uunet.uu.net, requests to std-unix-request@uunet.uu.net; also distributed as newsgroup comp.std.unix on USENET. I'm the moderator. There are various paper mailing lists and levels of participation in the various committees. I will send you in a separate message a copy of my semi-monthly posting on that subject. Most people on the TCP-IP list are probably not interested. >I understand that NBS has accelerated their efforts and may be ahead of >IEEE in coming up with a standard. Yes. There will be a report on that in comp.std.unix in the next few days.
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 21:16:00 GMT From: STGEORGE@UNMB.BITNET To: comp.protocols.tcp-ip Subject: Hop problem
Can anyone tell me the status of thw work being done to get around the limitation of TCP/IP to a hop of 15 nodes? Thanks.
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: 21 January 1988 0640-PST (Thursday) From: stanonik@nprdc.arpa (Ron Stanonik) To: tcp-ip@sri-nic.arpa Subject: Re: imp->psn upgrade, ecu override
Excuse my confusion, imp to psn is just a name change. What happened here was a "complete swap-out of the old C-30 IMP/PSN which a new C-30 IMP/PSN in the new "standard configuration". Still the question remains, why set the ecu to override? The new c-30 should still respond to an error induced reset from the ecu (rejnp frame?), right? Thanks, Ron stanonik@nprdc.arpa
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 22:42:20 GMT From: dlnash@EMX.UTEXAS.EDU (Donald L. Nash) To: comp.protocols.tcp-ip Subject: Re: IBM Token Ring <--> IP world
> The following article came through the TCP/IP discussion group yesterday. > Enjoy, > > DR Thanks, Dan. I think info-tcpip is gatewayed to comp.protocols.tcpip, which I read. I probably saw this and didn't notice it. I'll have to read c.p.tcpip more carefully. Don
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 88 23:10:05 GMT From: carrs@TROUT.NOSC.MIL (Stephen M. Carr) To: comp.protocols.tcp-ip Subject: C-KERMIT For Honeywell DPS-6 & Tandem NonStop TXP
-------
Ladies/Gentlemen,
1. Forgive me for bothering this forum for a query that is not
inline with TCP/IP. Under the circumstances, however, this
target audience is likely to be able to help me more than any
other forum I am aware of.
2. We need to identify and procure a working version of Columbia
University's C-KERMIT that will execute on a Honeywell DPS-6
under the GCOS6 Mod 400 Version 3.1 operating system.
3. If we cannot locate a current executable copy of C-KERMIT,
our lives become somewhat difficult, as we own no C compiler for
the DPS-6, and the Navy procurement process may have us waiting
until the millenia to legally obtain one.
4. Failing procurement of an executable copy, perhaps somebody
at Columbia University would be kind enough to answer this
question, "How can we obtain the source code for C-KERMIT that
will execute on the Honeywell DPS-6?"
4. Similarly, we have need to identify and procure a copy of C-
KERMIT which will execute on the TANDEM NonStop TXP. Guess which
two machines we wish to transfer files between in a nonnetworked
direct asynchronous modem linked environment?
5. Again, my apologies, but any help would be greatly
appreciated, and will no doubt save you money as taxpayers.
Very Respectfully,
Steve Carr
LCDR, SC, USN
Navy Management Systems Support Office (Code 42A)
Naval Air Station
Norfolk, Virginia 23511-6694
MILNET: carrs@trout.nosc.mil
MILNET: navmasso42a@nardacva.arpa
(804) 445-2171, AUTOVON 565-2171
(804) 445-1595, AUTOVON 565-1595 (extension 36)
-------
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 01:31:22 GMT From: don@SRI-LEWIS.ARPA (Donald Holman) To: comp.protocols.tcp-ip Subject: Serial Line address assignment and user authenitcation.
To all,
This mobile host/circuit switched IP discussion seems to crop up every
six months or so. At the risk of re-kindling this fire. Here's another
perspective on this matter.
DISCLAIMERS
Since neither of us attended the "slip" discussion at Monterey East,
please correct us if there are any new developments.
This is probably as much of an issue in network management as in link
layer protocols. Please accept our apologies if we posted to the
incorrect forum.
INTRODUCTION
Over the past several months, there have been numerous discussions
concerning PC-based IP primarily tailored for academic and business
environments. Unfortunately, the current serial line IP implementations
do not appear to be entirely suited for military applications --
specifically, where a network must respond dynamically to architectural
changes.
The particular architecture which the past discussions have focused on
have been in connecting mobile nodes to pre-specified and fixed network
ports. Additionally the discussions have centered on the attachment of
PC's (e.g. IBM PC class machines) running some variant of SLIP (Rick
Adams, KA9Q, etc..).
There appears to be a more general problem which we would like to see
addressed; that of connecting hosts/PC's to a subnet via any available
network port on any PSN. We envision the host would have sufficient
processing power to support more sophisticated link layer protocols than
just simple framing. The discussion below focuses on the ability to
dial-up a PSN, use some network service, disconnect because the PSN
failed, dial-up another PSN, and gain immediate network access. Of
course, the requirement is on the ability to gain access via any node
without manual intervention and without excessive bandwidth consumption
due to routing table updates.
While there are protocols for acquiring a newly connected neighbor, they
do not appear to be entirely suited for large low speed networks where
hosts are not statically connected to the network but may randomly
appear at any network port. What we mean by low speed is the use of 16
kbps trunks, and 2.4 kbps host-to-subnet links. This is partially
governed by the requirement to keep telephone line costs low. The other
is availability during times of conflict.
Ideally the situation which we would like to have is to configure a
single host/PSN with the network configuration and be able to drop in
new machines without knowing their addresses, a priori.
Fully realizing that there are many issues at stake, we would like to
concentrate on a particular issue and system concept -- that of mobile
PC nodes using dial-up IP to any one of a set of ports available
throughout a fairly stable subnet.
The PC's will probably be replaced by high performance workstations in
the near future -- but the problem set remains the same. Similarly, this
discussion is not advocating the use of SLIP, X.25 or any other serial
line protocol, rather we are attempting to define a systems model for
use in a dynamic network.
BACKGROUND
The environment which we envision using a serial line protocol is in
connecting PC's to a relatively static backbone network consisting of
packet switches and dedicated nodes providing resources such as mail
queuing, computing services, distributed databases, etc.. Since, for
our use, this application is in the military arena the line protocol for
connecting into the subnet should be self configuring, be highly robust,
and not cause instabilities within the subnet.
Additionally, these PC's will dial into the backbone using voice-grade
commercial/tactical (low bandwidth) circuits. Our focus is on the
problem of connecting mobile PC's to this fairly static subnet. (For
now we're not going to entertain any of the complexities of subnet
partitioning or self reconfiguration.)
PC's should be able to dial into any available port at any PSN or
resource server and be able to immediately acquire available computing
resources. The service provided by the subnet to the PC should include
virtual connection services (e.g. TCP) and not just message/mail
forwarding (UUCP, CSNET Phonenet)
Circuit switched IP is a related matter but we'll assume for now that
the subnet is linked together using leased-lines and circuit switched IP
applies only on the PC to subnet data link. Under this model the user
is aware of a set of phone numbers or network entry points for accessing
the network.
DEFICIENCIES OF CURRENT APPROACHES
Present point-to-point link layer implementations either assume that
there is a pre-specified host at the remote end or that some negotiation
will occur specifying who the remote host is and if the host has the
proper access privileges. Another method, described by Bill Westfield
as the Gateway model, will accept packets from any IP host and is
managed by sending the appropriate routing updates. This method can be
viewed as extending routing mechanisms to the mobile host.
The problem with most existing point-to-point links is reconfiguration
of interfaces to accept different source and destination ends. This
does not occur dynamically and requires user intervention. With most
point-to-point links one must first specify a source and destination
interface address. Unfortunately, this binding of names to physical
devices forces the network to be static in nature. For example, current
SLIP implementations, BBN PSN's, and commercially available gateway
serial interfaces all require addresses to be assigned before the
interfaces become active. Most (if not all) X.25 links require a fixed
X.121 address.
Even if the host operator was able to reconfigure the machine's
interface, he/she would still need to determine what its interface
address should be and what the address of the PSN port is. For dynamic
situations it would be difficult to manage and distribute addresses at
the host level. This is particularly true in a military environment
during times of conflict when the network topology becomes very dynamic.
The gateway model of determining remote addresses and updating the
routing tables may be an answer for small nets. However, when nets are
large and many PC's dial into the network only to exit shortly after
(e.g. as in a tactical arena), the network may become congested with
routing updates. The convergence of the routing protocols must be quick
to minimize instabilities. In general, the ability to support arbitrary
hosts using the gateway model is gained at the risk of network
instability. Resources distant from the host may not be attainable
until routing information propagates to the server providing the
requested service. With low speed trunking, the network may do little
else than to update routing tables, especially if the radius was large
and the frequency of host connection/disconnection was high. (If anyone
has performed analytic or quantitative analysis of this situation,
pointers are greatly appreciated.)
A compromise between the two above methods is to have the calling PC
identify itself and to have the PSN port accept variable destination
ends within a given set of addresses. However, the deficit we see with
this approach is that addresses are still statically bound on the host
end. Given this approach the PC would be unable to use an access point
on a different PSN without incurring routing updates. Furthermore, the
set of addresses with access point would need to support may be large.
Our experience has been with BBN PSN's, cisco's, Sun IR and DDN X.25
products, and Rick Adam's SLIP. These require binding of addresses to
interfaces. If both ends of the interfaces have not been configured
with the proper addresses, the interfaces will not transport packets.
Current discussions have focused on stable address spaces -- the PC's
have a fixed address, the subnet ports have fixed addresses, and the
routing updates constitute the transport of these pre-assigned addresses
and their state. What would be nice is if there was a protocol for
having the network assign addresses dynamically having the dial-up hosts
conform automatically to this address. The idea of not binding network
addresses to either network access points or to the hosts may have
applicability.
DYNAMIC ADDRESS ASSIGNMENT
A method which may be suitable for the described network architecture
(static low speed backbone and roving dial-up PC's) but has not seen
much discussion, is dynamic address assignment rather than route
updating or fixed address assignment. Under this method a the network
access point is given a pool of addresses which it can freely delegate
to calling PC's and to the PSN ports. These address pools are assigned
by the subnet administrator at the time of system generation and are
available for assignment. The PC is required to abide by the assigned
address or risk having its packets dropped. The benefit of this
approach is that no routing updates need occur and authentication
becomes manageable -- away from the idea of authentication based on
addresses. What is proposed here is that an internet address is bound
to an interface after a calling PC is validated for access, and that the
address is re-used when the calling PC disconnects or the link fails.
This also requires the allocation of a pool of addresses large enough to
support the anticipated number of dial-up hosts. This could be
supported through subnetting, making the movement of PC hosts
transparent to the network layer routing protocols. This approach will
help preserve the stability of the subnet in terms of routing and
minimizing network flow changes only to user data packets.
This requires the interfaces to be able to communicate without knowing
what its network layer addresses should be. This shouldn't be a problem
as LAPB already supports this, there are two implicit addresses for a
point-to-point link -- DTE and DCE.
While X.25 is designed to address this issue of calling up a network and
gaining network access, it addresses only the host to subnet connection
and not how the subnet manages its external ports or performs the
routing of packets. This is an issue which we would like to discuss
with others. We are sure the ISO network layer working groups have
worked on this issue and we would be interested in hearing from them
concerning this subject.
Because the address pool is managed by the subnet, the user's need not
be concerned with low level details about attaching to the network.
They need only be concerned if they have appropriate access privileges.
The link to the network will be established automatically.
This dynamic address assignment model assumes that the host computer has
no services to offer the network, and that the network resources are
used by the PC and not vice versa. That is, the PC is a strict client,
and there is no need to seek out servers on the PC by other users or by
the network. Additionally, services which the PC will subscribe to are
offered by the subnet through resource servers which are stable and have
"well-know" addresses.
Since this model assumes a strict client-server relationship, the PC
will not be providing any services to the network. It is merely a
consumer. For the most part, this strict model is sufficient when PC
hosts are used. Again the feasibility of this model is dependent upon
servers which;
1.) are stable within the network,
2.) support name/service lookup,
4.) are capable of validating user accounts/passwords,
which as an entity provide a distributed authentication
and resource server capabilities.
3.) will offer services such as queuing up and retrieving mail,
(perhaps running a POP-like protocol), providing disk space,
distributed databases, etc..
In most networks, there are existing resources which are non-mobile or
their locations are fixed. If the architecture can support a distributed
maintenance of accounts this access and authentication scheme will allow
a user to log into any point in the network and access network services.
As with other approaches, a solid authentication mechanism needs to be
established to control network access. For network management, a
mechanism also needs to be developed to determine exactly who has
attached and what its new address is.
AUTHENTICATION
Allowing a PC to arbitrarily log into any point in the network requires
that the network support a distributed authentication mechanism. To
accomplish this the use of distributed authentication servers will
probably be required. The authentication servers must:
1.) maintain, through periodic updates, a table of users and
passwords of valid users that are allowed access to the network.
(it should be possible to derive this from the network passwd file)
2.) receive and validate authentication packets from login hosts.
3.) allow the authenticated PC user to modify the existing authentication
password.
When a PC enters the network it passes an authentication packet into the
network port where this packet is received and forwarded to the nearest
authentication server for validation. If authentication is successful,
the PC is permitted access to the network. If authentication is
unsuccessful then the network notifies the PC and access is not
permitted and the port reclaimed after several unsuccessful attempts to
gain access.
After authentication, the responsibility for seeking out services will
remain with the PC -- where the services are held, how "expensive" the
service is in terms of cost, transmission time, reliability, load, etc..
From a network wide perspective, transcending the layers, there should
be resource/name servers for informing the PC where it can locate files
and other pertinent information. Through the resource servers, the PC
is able to contact other servers for specific information.
Access control could be maintained by the authentication server which is
a network layer authentication mechanism. Some monitoring of
individuals currently logged onto the network may be performed at this
layer to map users to addresses or perhaps to notify recently logged on
users of important events which may have transpired since last login.
In a truly distributed environment, login into the net will also result
in updates containing resource locations be sent to the PC identifying
where and what kind of resources can be found at the current moment.
ADDITIONAL REQUIREMENTS
In order to support the before mentioned slip access and authentication
mechanisms the development of a higher layer protocol must occur. It is
this protocol which will support the passing of authentication
information to and from the network. As well, a distributed
authentication-server must be developed which is capable of maintaining
distributed account/password file information and authenticating client
requests.
In addition, a higher layer protocol and server must be developed which
will support the concept of an information/resource service. It is the
job of these resource servers to provide information, upon request, to
the PC indicating at what point in the subnet information such as mail
or data base updates (etc.) can be retrieved and what the cost
associated with this information might be.
SUMMARY
To summarize the above, we see the requirement for:
1) Serial line IP protocol for support of dynamic address assignment to
minimize routing table updates and address/configuration problems.
2) user authentication based upon a distributed authentication server.
3) resource servers, which are capable of providing information
on request to the PC, informing the PC the whereabouts of mail
and other services.
There appears to be many benefits to this approach for the given
architecture, and perhaps many drawbacks. While this idea is
conceptually no different than the idea of dialing up to your local
computer via a dumb terminal, we leverage the multiplexing features of
existing protocols such as IP. This approach does imply that the
resources at the host may not be used optimally, but for a military
application, the need for survivability may preempt efficiency
requirements.
Any comments will be appreciated.
Jointly,
Don Holman
Danny Lee
SRI International.
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 88 08:02 5 From: "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET> To: tcp-ip@SRI-NIC.ARPA Subject: Sun OS 3.4 and subnets
Hi!
In regards to my problem of getting subnets working on Sun OS 3.4
using diskless workstations on one side of a server and a campus
back-bone ethernet of the other, we're up.
The credit for getting us up this far goes the Vance Morrison. We
got the diskless workstation side up first and THEN turned on the
ethernet interface to the back-bone. Now the server can talk to the
back-bone and the diskless wonders can talk to the server.
Next problem is that the diskless boxes don't seem to be able to
reach the back-bone. We get one of two responses depending on what we
tell the server. Ether a diskless station trying to TELNET to the
back-bone will come up with 'network unreachable' OR TELNET wil say
'Trying....' and sit there.
We're soooo close but no prize yet. Any more ideas? We've tried
various hand routings on the server but only get one of the above two
responses.
Thanks.
Cheers,
Chris Johnson
Northeastern University
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jan 88 08:22:58 EST From: Ken Pogran <pogran@ccq.bbn.com> To: sundc!potomac!jtn@seismo.css.gov Cc: arpaupgrade@bbn.com, tcp-ip@sri-nic.arpa Subject: Re: ARPANET UPGRADE
John, On the contrary! We have you listed as a host afflicted by the "Stuck VC" problem, for which a fix was deployed to the "affected nodes" (it hasn't been distributed net-wide yet). If you're still not "on the air", then something's gone wrong that we will investigate. It's also not the case that BBN believes that the remaining problems are all site/host problems. We're working on several problems that aren't "show-stoppers", for which we and/or the sites have developed work-arounds -- the ECU problem mentioned by Charles Hedrick at Rutgers, for example. These are problems that had been put on the back burner while we worked to resolve the show-stoppers described in our previous messages. Ken Pogran
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 03:44:32 GMT From: NJG@CORNELLA.BITNET (Nick Gimbrone) To: comp.protocols.tcp-ip Subject: Re: seeking experiences with IBM 9370 tcp/ip
>Our IBM types are planning on installing and evaluating an IBM 9370, >including an Ethernet tcp/ip connection. We would be interested >in the experiences of others with the 9370 tcp/ip. (Is the >software just the wiscnet stuff?) The IBM TCP/IP for VM product (5798-FAL, or just FAL for short :-) has its roots in the Wiscnet package. BUT (a big but) the code has been extensively worked on by IBM Yorktown. The current FAL product is faster, more stable, and in all around better than Wiscnet ever was. I would not make any negative assumptions based upon earlier experiences with the Wiscnet code. On the hardware side (the 9370 and its ethernet controler) I'm afraid I cann't offer any words of wisdom. For discussions of FAL software (and related hardware issues) you might want to join the IBMTCP-L list hosted at CUNYVM.CUNY.EDU (or CUNYVM.BITNET). (I believe you subscribe by sending a one line mail file containing 'SUB IBMTCP-L <your name>' to LISTSERV@CUNYVM.CUNY.EDU, but I may be wrong.)
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 04:20:56 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: A good day for timewarps
Steve, Great. NCAR is apparently ticking to-date as well. Have you any idea why I can't barge into the WWVB fuzzy and refertilize its disk? All stations, be advised reports from our commando unit operating in Vienna, VA, has just liberated a WWVB clock (which used to tick at Linkabit). Said clock and commando also sighted leaving Metroliner Wilmington, DE. There are persistent rumors to effect this clock may soon tick from U Delaware. This was a very clean operation with the only casulty a Property Control Officer and a DSSW beancounter or two. Dave
-----------[000243][next][prev][last][first]----------------------------------------------------
Date: 21 Jan 88 07:57:00 GMT
From: JOHNSON@nuhub.acs.northeastern.EDU ("I am only an egg.")
To: comp.protocols.tcp-ip
Subject: Sun OS 3.4 and subnets
Hi!
In regards to my problem of getting subnets working on Sun OS 3.4
using diskless workstations on one side of a server and a campus
back-bone ethernet of the other, we're up.
The credit for getting us up this far goes the Vance Morrison. We
got the diskless workstation side up first and THEN turned on the
ethernet interface to the back-bone. Now the server can talk to the
back-bone and the diskless wonders can talk to the server.
Next problem is that the diskless boxes don't seem to be able to
reach the back-bone. We get one of two responses depending on what we
tell the server. Ether a diskless station trying to TELNET to the
back-bone will come up with 'network unreachable' OR TELNET wil say
'Trying....' and sit there.
We're soooo close but no prize yet. Any more ideas? We've tried
various hand routings on the server but only get one of the above two
responses.
Thanks.
Cheers,
Chris Johnson
Northeastern University
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 10:29:28 GMT From: jmg@cernvax.UUCP (jmg) To: comp.protocols.tcp-ip,comp.lang.c Subject: Re: C binding interfaces for TCP/IP
In article <25@vdelta.UUCP> dave@vdelta.UUCP (Dave Arnold) writes: >Are there efforts underway to standardize a C language interface for TCP/IP? >I have asked a particular vendor about this for VAX/VMS, and all he said was >"You get a QIO interface". Great, so when we migrate to OSI, we will have >to rewrite all our software. How does BSD sockets and streams fit into this? We decided to define a set of routines for using a transport service, called Common Applications Transport Service (CATS). It was oriented towards OSI, but has been implemented on top of DECNET also. If I have understood it correctly it is more oriented towards streams than sockets, although we think that it could go onto both. The routines have been put onto various computers and operating systems, and there is quite a lot of interest: physicists also want to avoid changing their programs more than necessary. Of course, the OSI TP4 is not really meant to be used directly by programmers, and there are thus no defined programming interfaces. However, in the real world people chase after efficiency, speed etc., which they feel is better by avoiding such things as presentation and session level. (if that does not start a religious war then nothing will!)
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 13:16:12 GMT From: larry@pdn.UUCP (Larry Swift) To: comp.protocols.tcp-ip Subject: Re: Subnet support in SunOS 3.3
In article <8801182146.AA03342@speed.sun.com> nowicki@SUN.COM (Bill Nowicki) writes:
>Last week there were several incorrect messages to this list about the
>IP subnet support in SunOS releases. As developer of this software, I
>would like to brave the flames and clear up the misconceptions.
Unfortunately, your messsage didn't offer any help to those having the
problems. I inferred that you thought the problems were imaginary or
due to ill-informed users. However, one of Sun's own reps has
acknowledged some difficulties in the subnet routing area. Can you
surmise what it is that is causing (at least several people) problems?
Larry Swift UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207 Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 13:22:58 GMT From: pogran@CCQ.BBN.COM (Ken Pogran) To: comp.protocols.tcp-ip Subject: Re: ARPANET UPGRADE
John, On the contrary! We have you listed as a host afflicted by the "Stuck VC" problem, for which a fix was deployed to the "affected nodes" (it hasn't been distributed net-wide yet). If you're still not "on the air", then something's gone wrong that we will investigate. It's also not the case that BBN believes that the remaining problems are all site/host problems. We're working on several problems that aren't "show-stoppers", for which we and/or the sites have developed work-arounds -- the ECU problem mentioned by Charles Hedrick at Rutgers, for example. These are problems that had been put on the back burner while we worked to resolve the show-stoppers described in our previous messages. Ken Pogran
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 14:16:53 GMT From: sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) To: comp.protocols.tcp-ip Subject: SUPDUP for 4.3bsd Unix: request for sources
With all of this talk of SUPDUP, does anyone have an implementation for 4.3bsd Unix. There was, I recall, a 4.2 implementation, but I didn't need it, then. Sean McLinden Decision Systems Laboratory University of Pittsburgh
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 14:17:48 GMT From: robert@pvab.UUCP (Robert Claeson) To: comp.protocols.tcp-ip Subject: TLI and Sockets
Is there anything that would make a program running on a System V Release 3 machine, using TLI, to communicate with a program running on a machine using Sockets? -- Robert -- Robert Claeson, System Administrator, PVAB, Box 4040, S-171 04 Solna, Sweden eunet: robert@pvab uucp: sun!enea!pvab!robert
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 14:34:00 GMT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: Where to find... supdup and tn3270 specs
Date: Wed, 20 Jan 88 09:37:35 PST
From: braden@venera.isi.edu
Some people think SUPDUP is a swell protocol. Why doesn't one of them
take the time to write a reasonable protocol RFC on SUPDUP, without
assuming 36-bit machines. Then the rest of the Internet world can
find out how wonderful SUPDUP is.
As MRC said, SUPDUP does not assume 36-bit machines. Depending on what
level of abstraction you choose to take, the RFC either does or does not
assume 36 bit machines. What the RFC does is abstract various
quantities into 36 bit words and uses some PDP-10 notation conventions.
That's an abstraction, one of many possible abstractions, and in many
senses just as valid as any other abstraction (e.g., one that assumes
Vaxen or 68000s) one might use to (re)write the RFC with.
Maybe what you are asking for is an appendix which describes how to
pack, unback and interpret the 36-bit quantities for "normal" machines?
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 14:39:17 GMT From: perry@MCL.UNISYS.COM (Dennis Perry) To: comp.protocols.tcp-ip Subject: Re: A good day for timewarps
Dave, I am disappointed. Beancounters usually are high priority and to only take out two of them is not very good field operations :-) dennis
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 15:47:16 GMT From: gross@GATEWAY.MITRE.ORG (Phill Gross) To: comp.protocols.tcp-ip Subject: Re: POSIX
There are indeed some very interesting things happening in the POSIX arena these days and NBS is very involved in many aspects of the work. If no one from NBS responds to you directly, send me a note and I will give you a name to contact. In the meantime, for those who want to find out more basic information, there is an informative introductory document entitled `POSIX Explored' from /usr/group. The address given in the document is: /usr/group 4655 Old Ironsides Dr. #200 Santa Clara, CA 95054 408-986-1645 Phill Gross
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 21:26:00 EST From: <enger@bluto.scc.com> To: "sundc!potomac!jtn" <sundc!potomac!jtn@seismo.css.gov> Cc: <arpaupgrade@bbn.com>,<pogran@ccq.bbn.com>, <tcp-ip@sri-nic.arpa> Subject: PSN 7 problems still arise.
Even though patches have been developed, they don't seem to stay deployed. I have lost track of the number of times that I have had to call the NOC to have "the patches" down loaded again. Perhaps this "fleeting patch" syndrome is all that afflicts ADS? Bob Enger
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 16:44:37 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: A good day for timewarps
Dennis, Yeah, but I sure got funny looks as I hauled the clock and antenna through Union Station. I just told the doorperson the antenna was a new-model M16 and got wonderful service. It seems to be working okay at the moment, so its appearance on the net should be eminent (sic). Dave
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 17:13:37 GMT From: lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) To: comp.protocols.tcp-ip Subject: Re: Hop problem
From tcp-ip-RELAY@SRI-NIC.ARPA Thu Jan 21 00:40:29 1988 Received: Thu, 21 Jan 88 00:40:26 PST by orville.nas.nasa.gov (5.54/1.2) Received: Thu, 21 Jan 88 00:41:41 PST by ames-nas.arpa (5.51/1.2) Message-Id: <8801210841.AA12538@ames-nas.arpa> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed 20 Jan 88 14:17:55-PST Received: from UNMB.BITNET by CUNYVM.CUNY.EDU ; Wed, 20 Jan 88 17:17:52 EST Date: Wed, 20 Jan 88 15:16 MDT From: <STGEORGE%UNMB.BITNET@CUNYVM.CUNY.EDU> Subject: Hop problem To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa Status: RO Can anyone tell me the status of thw work being done to get around the limitation of TCP/IP to a hop of 15 nodes? Thanks. Said work is complete, in that the current limit is 255, assuming all intervening gateways only decrement the time to live by one. This has always been the state. Perhaps the particular IP you are running initializes the time to live at 15, assuming this to be an upper limit. There is also the existence of an implementation of a routing protocol called RIP, which assumes a distance of 16 is infinite. Perhaps this is causing you some problem. All you need do is correct all machines to initialize the ttl field to be more than 15, and you will win. I doubt seriously if anyone is trying actively to repair this as a default case. john
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 20:14:07 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: Where to find... supdup and tn3270 specs
Page 3 of RFC 734, "INITIALIZATION", in the very first paragraph describes completely how to pack, unpack, and interpret the 36-bit quantities in terms of 8-bit bytes. The SUPDUP protocol itself uses 8-bit bytes in transmission over the network. I doubt the critics of the SUPDUP RFC have ever bothered to read it; it's so much easier to criticize based on hearsay and the dread sequence "PDP-10". -------
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 20:36:04 GMT From: km@emory.uucp (Ken Mandelberg) To: comp.protocols.tcp-ip Subject: SLIP on Annex Box
Does anyone know if the Annex Box does SLIP? I guess it could do it
completely in the box which would seem ideal. Alternately it could let
one of the Unix hosts treat the connection like a tty and handle the
substance.
--
Ken Mandelberg | {decvax,sun!sunatl,gatech}!emory!km UUCP
Emory University | km@emory BITNET
Dept of Math and CS | km@emory.ARPA ARPA,CSNET
Atlanta, GA 30322 | Phone: (404) 727-7963
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 88 23:47:47 GMT From: pogran@ccq.bbn.COM (Ken Pogran) To: comp.protocols.tcp-ip Subject: Re: ARPANET UPGRADE
John, With regard to the problem you reported, being unable to communicate with 1822-connected ARPANET hosts (including gateways): It turns out that the PSN's "community-of-interest" word for your host was set incorrectly, which had exactly the effect you reported: the PSN allowed you to communicate with other X.25-connected hosts, but prohibited you from communicating with 1822-connected hosts. Our troubleshooter reports that we've corrected the problem, and that one of your folks has confirmed that you can now communicate normally with 1822-connected hosts. The "community-of-interest" word is a per-host configuration item in the PSN; unfortunately we can't tell how it came to be set wrong. Most likely it occurred in the (all-too-manual) process of setting up the PSN 7 configuration items based on the existing PSN 6 configuration. Our apologies. Ken Pogran
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 01:45:54 GMT From: narten@PURDUE.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: An even worse week for EGP....
The trouble with bogus networks slipping into the core tables has
apparently returned. Has anyone fingered a culprit?
In my seemingly endless explorations of the EGP code in gated, I have
discovered yet another tidbit. These comments apply directly to egpup
as well, from which gated claims ancestory.
1) Totally bogus nets are slipping into the core tables. By bogus, I
mean neither class A, B or C. When encountered during the processing
of an EGP network reachability update, one cannot determine how many
bytes the address is supposed to be. Gated chokes when it receives
them in updates and tosses the partially processed update.
2) EGP detects the "problem" with the data, and assumes that the
entire packet is bad (even though it installs all the routes up to the
bogus one). After 4 such updates in a row, gated sends a cease command
to the gateway it was peering with, and goes back into neighbor
acquisition state. Meanwhile, any routes you are advertising to the
core get marked ureachable for 60 seconds.
This has happened at our site many (1-2 dozen times) since last
Thursday. (e.g. the problem doesn't seem to be going away).
3) If you are running Kirton's EGP, or an old version of gated, none
of these events will be logged anywhere. In other words, if it is
happening to you, you probably aren't even aware of it.
4) The code in gated, egpup and the BBN core gateways apparently all
allow non class A, B, C nets to slip into updates [which side of the
fence do fuzzballs and vendor gateways sit on??] The problem is no
doubt code of the following type:
if (is_classA_net(net)) then
/* do class A stuff */
else if (is_classsB_net(net)) then
/* do class B stuff *
else
/* must be a class C net */
/* do class C stuff */
endif
For egpup users, I strongly urge that the following patch be applied
to rt_egp.c. It will prevent egp from sending out reachability updates
for non-A,B,C nets.
*** rt_egp.c Thu Jan 21 20:02:20 1988
--- /usr/src/local/etc/egp/rt_egp.c Mon Nov 10 19:05:38 1986
***************
*** 128,135 ****
if( in_isa( current_gw)) n_bytes = 3;
else if( in_isb( current_gw)) n_bytes = 2;
! else if (in_isc( current_gw)) n_bytes = 1;
! else return(ERROR);
bcopy( (u_char *)¤t_gw+4-n_bytes, nrp, n_bytes);
nrp += n_bytes;
--- 128,134 ----
if( in_isa( current_gw)) n_bytes = 3;
else if( in_isb( current_gw)) n_bytes = 2;
! else n_bytes = 1;
bcopy( (u_char *)¤t_gw+4-n_bytes, nrp, n_bytes);
nrp += n_bytes;
***************
*** 152,159 ****
/* copy net addr */
if( in_isa( net_pt->net)) n_bytes = 1;
else if( in_isb( net_pt->net)) n_bytes = 2;
! else if (in_isc( net_pt->net)) n_bytes = 3;
! else return(ERROR)
bcopy(&net_pt->net, nrp, n_bytes);
nrp += n_bytes;
} /* end for each net */
--- 151,157 ----
/* copy net addr */
if( in_isa( net_pt->net)) n_bytes = 1;
else if( in_isb( net_pt->net)) n_bytes = 2;
! else n_bytes = 3;
bcopy(&net_pt->net, nrp, n_bytes);
nrp += n_bytes;
} /* end for each net */
For gated users, the same basic patch applies. Look in the file
rt_egp.c, routine rt_NRnets(). I would supply the patch, but I am
running a beta test version of gated that's different than everyone
elses.
I am skeptical that the above fixes really get at the heart of the
problem. Some of the nets that are appearing apperently don't really
exist, but they are technically valid Internet addresses.
Thomas
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 02:26:00 GMT From: enger@BLUTO.SCC.COM To: comp.protocols.tcp-ip Subject: PSN 7 problems still arise.
Even though patches have been developed, they don't seem to stay deployed. I have lost track of the number of times that I have had to call the NOC to have "the patches" down loaded again. Perhaps this "fleeting patch" syndrome is all that afflicts ADS? Bob Enger
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 02:50:37 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: A good day for timewarps
Scott, I concur with your feeling that the NCAR fuzzball should be protected from cycle stealers as much as possible, but maybe you are missing something. First, application-level services, including NTP, are run at the lowest priority level in the multi-level scheduler, so that packet-forwarding functions always take precedence. Furthermore, the memory allocations are disjoint, so that even relatively large numbers of UDP users do not impact the resources used by packet-forwarding functions. Notwithstanding the above, I would very much recommend the use of the backbone fuzzies to provide time service directly to their Ethernet population simply to avoid those time-service packets transiting the seriously overloaded backbone links to other time servers removed from the backbone. As you know, the fuzzballs are carefully synchronized to various radio clocks using their local-net routing protocol, so there is no need for time-service packets between them or for timewatchers to chime any but the nearest fuzzball as the ethernet flies. What I think is a much more productive strategy is to suggest to your timewatchers to avoid the urge to chime any particular fuzzball with multiple hosts on the same network. Far better to chime with one host using NTP and then redistribute time locally. It would seem that each backbone fuzzball could serve as chimee for any or all the nets it normally serves in its respective configuration. This would avoid the chimepackets even coming near the overloaded serial lines. Dave
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 03:19:50 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: An even worse week for EGP....
Thomas, The fuzzbugs do not currently perform a sanity check on IP net numbers appearing in EGPspeak or hellospeak messages; however, they do sport a martian filter that tosses packets with unsane IP addresses should they appear. You make a good point that the martian filter should also be expressed in a sanity check for routing data as well. Today the situation I complained about last Sunday happened again, with nets 207-something figuring very prominently in the noise. I tried to catch a MILNET gateway in the act, but without success before the wickedness evaporated from the core tables. Dave
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 05:06:35 GMT From: morgan@navajo (Bob Morgan) To: comp.protocols.tcp-ip Subject: Telnet-to-Telenet? (long)
I'm with the Networking Systems organization at Stanford. We're investigating possibilities for connecting our campus-wide TCP/IP/Ethernet-based network (SUNet) to some X.25 networks. We envision a gateway box that would have one or more X.25 trunks on one side and an Ethernet interface on the other. We've figured out a few things, found out some other things, and now are casting about for fellow travelers (or maybe clever entrepreneurs). (In the following, please excuse if my X.25 terminology isn't correct; I'm not as familiar with it as I should be.) We would like to provide the following services: * Outgoing terminal connections from SUNet machines to service providers (such as Dialog) on X.25 PDNs (such as Telenet) (Yes, this is the long-awaited Telnet-to-Telenet service 8^) * Outgoing terminal connections from SUNet machines to various campus hosts that don't support TCP/IP/Ethernet but do support X.25 * Incoming terminal connections from X.25 PDNs to SUNet hosts * Terminal connections from X.25-only campus hosts to SUNet hosts There are some problems with setting up something like this, mostly having to do with trying to connect an anarchic, "free" network (SUNet/Internet) to metered, pay-as-you-go networks (PDNs). In particular: * Some campus hosts already have direct PDN (Telenet) lines and support users who place "collect" calls to those hosts. PDN charges are eaten by the host-providing organization, or (in some cases, I think) charged back to users through host usage charges. They would like to continue this sort of service, through this new box. This means that we somehow have to a) restrict collect calls to a specific set of IP hosts, and b) capture the information about connections to be able to do billing. * On the other hand, other hosts that don't want to worry about collect calls might still like to receive connections from users who pay their own PDN charges, so these connections should be possible to any SUNet host. But we'd just as soon not provide access through our facilities to the entire Internet from any Telenet PAD, so we'd like to restrict the IP-side destinations to just Stanford. * We expect that outgoing calls (SUNet-to-PDN) will be collect only, but once again we would prefer that these calls originate only at Stanford, not anywhere in the Internet. * As much as possible, we'd like to insulate users from logging in six times and entering long strings of numbers to make connections. For example, I'd like to just say "> telnet dialog" from my Unix system and have it all happen. This means that the gateway should have some ability to translate names and addresses across the two types of nets. We're testing a Develcon system which is basically a port selector with an X.25 card and a Telnet-server/Ethernet card installed in it. This works fine for making the basic connections, and to some extent for handling the name translation issue. But it's very difficult to make it deal with the access-control (password protection is the prime method) and cross-net accounting issues. It's not really their fault, as it seems to me that no IP terminal server vendor is dealing with access control in a comprehensive way. Another approach, of course, is to take a Sun or a VAX with an X.25 board and munge it to do some of these things. Maybe all it would take is rewriting Telnet client and server modules to be more picky. We would, of course, prefer an off-the-shelf solution. Also, there's some concern about how well something like this would scale up if the service became popular. So: is anybody doing anything like this? It sure looks to me like a market opportunity here, folks. Suggestions, solutions, flames may be sent to me and I'll digest and repost, etc. Thanks, - RL "Bob" Morgan Stanford Networking morgan@jessica.stanford.edu
-----------[000263][next][prev][last][first]----------------------------------------------------
Date: 22 Jan 88 05:31:02 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: SLIP on Annex BoxI know that Proteon rebundles the Annex server and resells it themselves. They've done a lot with SLIP, so they would be a reasonable place to ask. (Jon, are you out there?) -Philip
-----------[000264][next][prev][last][first]----------------------------------------------------
Date: 22 Jan 88 05:44:08 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: Where to find... supdup and tn3270 specs
Some people think SUPDUP is a swell protocol. Why doesn't one of them
Yes, I think supdup is a great protocol. That is why I asked. However,
I didn't realize I was opening up Pandora's box when I asked...
take the time to write a reasonable protocol RFC on SUPDUP, without
assuming 36-bit machines. Then the rest of the Internet world can
find out how wonderful SUPDUP is.
As MRC said, SUPDUP does not assume 36-bit machines. Depending on what
level of abstraction you choose to take, the RFC either does or does not
assume 36 bit machines. What the RFC does is abstract various
quantities into 36 bit words and uses some PDP-10 notation conventions.
That's an abstraction, one of many possible abstractions, and in many
senses just as valid as any other abstraction (e.g., one that assumes
Vaxen or 68000s) one might use to (re)write the RFC with.
Given that is a networking protocol, the most reasonable representation
would be how the bits (bytes, or octets) appear 'on the wire', not how
they pack into a particular machine's word.
In view of the number of RFCs in print, we should know by now how to
express an idea without reverting to assembly language (for any processor,
whether esoteric or commonplace)...
-Philip
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 1988 10:57-EST From: CLYNN@G.BBN.COM To: narten@PURDUE.EDU Cc: egp-people@PARK-STREET.BBN.COM, tcp-ip@SRI-NIC.ARPA Subject: Re: An even worse week for EGP....
I also noticed strange network numbers a couple months ago. When I ask about it, I was told that the bogus numbers were coming from a gateway which had a noisy line to the net. Maybe the protocol being used didn't have a checksum, maybe it was turned off, maybe it wasn't "strong enough". Once the information gets into a table, it would be propogated. I didn't get the impression that the problem had a very high priority; the "only" adverse effect would be to use a slot in routing tables, and since it was a bogus net, nobody should be using it, and they should time out. I suspect that, given the dynamic and evolving nature of the Internet, any code which assumes "otherwise <something valid>" will cause us problems before too long. E.g., the new internet multicast addresses, the new IP and TCP options that we would like to create, etc. Charlie
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 11:20:00 EST From: <yurcik@nrl-lcp.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Cc: yurcik Subject: ACM SIGCOMM Mtg. Washington DC 2/22/88
Following is an announcement for TCP developers and maintainers who are in the Washington D.C. area or will be visiting the area on 2/22/88. This open informal meeting includes a talk and is intended for discussions of technical issues and past experiences. DC SIGCOMM NASA/GSFC Association for Computing Machinery Washington, D.C. Chapter Special Interest Group on Data Communication and the NASA/Goddard Space Flight Center NETWORK ROUNDTABLE #1/SEMINAR ----------------------------- DATE: Monday, February 22, 1988 TIME: 1:15 p.m. to 5:00 p.m. PLACE: Goddard Space Flight Center Building 8 Auditorium Greenbelt, MD 20771 Directions: From the Baltimore-Washington Parkway, take the Greenbelt Road/NASA exit. Turn left onto Greenbelt Rd.; Goddard's main gate will be on the left at the nth stoplight. RESERVATIONS: For security reasons, non-U.S. citizens and foreign nationals wishing to attend should make arrangements in advance through their embassy. CONTACTS: For additional information, contact Sol Broder, Head, Advanced Data Flow Technology Office at (301)286-7088 or Brian Lev at (301)286-9514. PROGRAM: 1:15-1:30 Greeting/Introduction Broder/NASA Gardner/SIGCOMM, Chair 1:30-2:00 Seminar D. Clark/MIT 2:00-4:00 Roundtable - Site Presentations 2:00-2:20 University of Maryland G. Ricart 2:40 George Mason University B. Peters 3:00 GSFC S. Broder 3:20 MITRE Chandler/Cerva 3:40 George Washington Univ. D. Preuss 4:00 NRL R Saenger 4:00-5:00 Discussion of Misc. Technology Concerns, Plans for Future Meetings, Format, Content. GUEST SPEAKER: Dr. David Clark, MIT TOPIC: "Network Throughput - Where Are the Limits?" ROUNDTABLE: Area facility network managers and implmentors will have an opportunity to share experiences and discuss technology issues. ------
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 13:51:43 GMT From: mechgam@tness1.UUCP (Gary Mink 713+521-6958) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Adaptors for thinwire to thickwire
3Com has a product called the Multiconnect, a Modular Multiport Repeater.
My product information sheet says, "Repeater Modules provide connections
to Thick Ethernet, Thin Ethernet, Fiber and Twisted Pair..." The
Multiconnect can have 15 modules of different types in any combination.
Does anybody have any experience with this unit?
--
Gary A. Mink
Southwestern Bell Telephone Co. (713) 521-6958
mechgam@tness1!uucp
{ihnp4,bellcore,killer,petro}!tness1!mechgam
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 14:11:00 GMT From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: Where to find... supdup and tn3270 specs
Date: Fri, 22 Jan 88 00:44:08 EST
From: "Philip A. Prindeville" <PAP4@AI.AI.MIT.EDU>
Given that is a networking protocol, the most reasonable representation
would be how the bits (bytes, or octets) appear 'on the wire', not how
they pack into a particular machine's word.
In view of the number of RFCs in print, we should know by now how to
express an idea without reverting to assembly language (for any processor,
whether esoteric or commonplace)...
I think MRC was right. Have you read the RFC, or are you making attacks
based on hearsay? There is no, absolutely no, assembly language in the
RFC. As for your "on the wire" argument, TCP and IP don't even do that.
TCP and IP abstract the bytes into headers which are displayed and
discussed in the RFC as headers, not bytes on a wire. They describe how
those headers appear on the wire, just as the SUPDUP RFC describes how
the 36 bit quantities appear on the wire. I'm really trying to avoid
making disparaging remarks about people's inability to convert between
abstractions.
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 15:57:00 GMT From: CLYNN@G.BBN.COM To: comp.protocols.tcp-ip Subject: Re: An even worse week for EGP....
I also noticed strange network numbers a couple months ago. When I ask about it, I was told that the bogus numbers were coming from a gateway which had a noisy line to the net. Maybe the protocol being used didn't have a checksum, maybe it was turned off, maybe it wasn't "strong enough". Once the information gets into a table, it would be propogated. I didn't get the impression that the problem had a very high priority; the "only" adverse effect would be to use a slot in routing tables, and since it was a bogus net, nobody should be using it, and they should time out. I suspect that, given the dynamic and evolving nature of the Internet, any code which assumes "otherwise <something valid>" will cause us problems before too long. E.g., the new internet multicast addresses, the new IP and TCP options that we would like to create, etc. Charlie
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 16:20:00 GMT From: yurcik@NRL-LCP.ARPA To: comp.protocols.tcp-ip Subject: ACM SIGCOMM Mtg. Washington DC 2/22/88
Following is an announcement for TCP developers and maintainers who are in the Washington D.C. area or will be visiting the area on 2/22/88. This open informal meeting includes a talk and is intended for discussions of technical issues and past experiences. DC SIGCOMM NASA/GSFC Association for Computing Machinery Washington, D.C. Chapter Special Interest Group on Data Communication and the NASA/Goddard Space Flight Center NETWORK ROUNDTABLE #1/SEMINAR ----------------------------- DATE: Monday, February 22, 1988 TIME: 1:15 p.m. to 5:00 p.m. PLACE: Goddard Space Flight Center Building 8 Auditorium Greenbelt, MD 20771 Directions: From the Baltimore-Washington Parkway, take the Greenbelt Road/NASA exit. Turn left onto Greenbelt Rd.; Goddard's main gate will be on the left at the nth stoplight. RESERVATIONS: For security reasons, non-U.S. citizens and foreign nationals wishing to attend should make arrangements in advance through their embassy. CONTACTS: For additional information, contact Sol Broder, Head, Advanced Data Flow Technology Office at (301)286-7088 or Brian Lev at (301)286-9514. PROGRAM: 1:15-1:30 Greeting/Introduction Broder/NASA Gardner/SIGCOMM, Chair 1:30-2:00 Seminar D. Clark/MIT 2:00-4:00 Roundtable - Site Presentations 2:00-2:20 University of Maryland G. Ricart 2:40 George Mason University B. Peters 3:00 GSFC S. Broder 3:20 MITRE Chandler/Cerva 3:40 George Washington Univ. D. Preuss 4:00 NRL R Saenger 4:00-5:00 Discussion of Misc. Technology Concerns, Plans for Future Meetings, Format, Content. GUEST SPEAKER: Dr. David Clark, MIT TOPIC: "Network Throughput - Where Are the Limits?" ROUNDTABLE: Area facility network managers and implmentors will have an opportunity to share experiences and discuss technology issues. ------
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 17:05:58 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: An even worse week for EGP....
Dave, Thomas: Could you be more specific about the 207-something net that is figuring in the noise. I understand DIA has been performing some tests for the DoDIIS communi- ty and could be using MILNET for some of the testing. What better test data could you find than unclassified source listings which are stored in directory [207,7] on DoDIIS IAS if you wanted to test FTP between systems. Something of a knee-jerk reaction on my part since the device handler and line interface module software that I deliver to DIA and the DoDIIS community is normally stored in the following directories: [ 7,7] Generation Command Files, Task Images [107,7] Object Modules [207,7] Source Listings, Task Image Maps [307,7] Source Modules I've given you the full list of directories in case any of it might correspond with the addresses you're seeing. Merton Campbell Crockett AN/GYQ-21(V) Program EATON Corporation Information Management Systems
-----------[000272][next][prev][last][first]----------------------------------------------------
Date: 22 Jan 88 17:14:08 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Hop problemIs an initial TTL of 64 large enough these days? (particularly given some of the things the packet-radio people are talking about - I saw a 30+ hop routing posted on pc-ip recently). jbvb
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 18:28:39 GMT From: MLY@XX.LCS.MIT.EDU (Richard Mlynarik) To: comp.protocols.tcp-ip Subject: UN*X SUPDUP
In the directory wheaties.ai.mit.edu:/ps/mly/supdup/ the files supdup.c, supdup.h, supdupd.c, supdup-login.c, Makefile. The supdup-login file is needed because brain-dead un*x /bin/login won't pass through the TERMCAP environment variable. This might be fixed in 4.3 for all I know. The implementation in those files is a lot closer to the spec than the 4.2 implementation by David Brigham upon which it is based. It is not as featureful as it might be, due to the obvious deficiencies of un*x compared to obsolete operating systems. -------
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 18:43:09 GMT From: tsudik@MALIBU.USC.EDU (Gene Tsudik) To: comp.protocols.tcp-ip Subject: (none)
I have been experiencing what maybe a bug (or "feature") of 4.3 IP code when trying to define new IP options. The new option that I've defined doesn't seem to bother IP an any higher-level protocols when the packets are relatively short. But, as soon as fragmentation is required, e.g. FTP large file, the connection goes dead. My guess is that the reassembly is never completed at the receiving end. a My question is: has anyone been playing with option definition in 4.3 IP and, if so, has a similar problem occurred? Also, is there an obvious place(s) to look for bugs when defining options? Any common blunders people experience when doing that ? Gene Tsudik USC Network Lab
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 21:21:14 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: An even worse week for EGP....
Merton, The typical "207 net" has a second octet whis is close to 255 (decimal), like 255, 254, 253 and 252. I even tried decoding it in ASCII, but that didn't parse well. I then went after the NSFNET gateways, since these dudes now squawk upwards of 120 nets and may expose scaling bugs if any non-core gateway does; however, these gateways are on ARPANET. I have not yet uncovered definitive evidence that would implicate MILNET dudes, although what evidence there is points that way. Dave
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 88 21:23:51 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: An even worse week for EGP....
Charlie, THose protocols known to me (EGP, RIP, hellospeak) all have reasonably competent checksums. At one time GGP had no checksums, but has since evolved to have them (Mike B, is my head cross-threaded?). Dave
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 88 00:18:49 GMT From: MRC@PANDA.PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: Where to find... supdup and tn3270 specs
Please read the goddamn RFC before flaming any further. There is NO "reversion" to assembly language. SUPDUP was first implemented for a particular operating system. It transmitted a few of that operating system's registers from client to server. Those registers are 36-bit quantities. As transmitted on the wire, each register is 6 bytes, with the most significant two bits zero in each byte. The first byte contains the most signifiant 6 bits, the second the next, ... The registers themselves are described as 36-bit values. That is because that is what they are. You could think of them as a series of bytes, but that obscures their original representation. Furthermore, these registers are dealt with ONCE -- at startup -- in the entire SUPDUP transaction and are used nevermore. 99.9% of the time these registers will contain constants wired into the program, with the possible exception of screen width and height. The intellectual laziness expressed by certain individuals (who obviously have not read the RFC beyond a fleeting glimpse) is a prime example of why the Japanese and the Koreans are taking over America's markets. -------
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 88 03:28:32 GMT From: mrose@gonzo.twg.COM (Marshall Rose) To: comp.protocols.tcp-ip Subject: Re: TLI and Sockets
Perhaps I have misunderstood the question, but... Sockets and TLI are both local mechanisms used for allowing processes to talk to the network. If both are speaking TCP, then you can not tell, but looking at the network traffic, whether one is using sockets or TLI or anything else. However, the two programs which are talking, one using sockets and the other TLI may be very different. Now, if you question really was: "I have a program written to use Berkeley sockets but I want to run it on a SVR3 machine which only has streams, what can I do?" Then the answer is that some people who are "heavy into Streams/TLI" have written libraries on top of TLI which make it look like sockets. The inverse operation, making sockets look like TLI is probably not possible without adding a bit of functionality to sockets. /mtr
-----------[000279][next][prev][last][first]----------------------------------------------------
Date: 23 Jan 88 05:28:27 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: UN*X SUPDUP
In the directory wheaties.ai.mit.edu:/ps/mly/supdup/
the files supdup.c, supdup.h, supdupd.c, supdup-login.c, Makefile.
The supdup-login file is needed because brain-dead un*x /bin/login
won't pass through the TERMCAP environment variable. This might
be fixed in 4.3 for all I know.
In 4.3BSD, if /bin/login is called with the -p argument, it preserves
the environment it is called with.
The implementation in those files is a lot closer to the spec than
the 4.2 implementation by David Brigham upon which it is based.
It is not as featureful as it might be, due to the obvious deficiencies
of un*x compared to obsolete operating systems.
Does this version also gobble up column 80 to avoid bizarre wrap modes,
or does it do The Right Thing (whatever that is...)?
-Philip
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 88 23:16:36 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: WWV update
Andre', You get sixty bits, one per second in each minute, to code everything. Right now each minute is separate, but coded so you can compare one minute to the next. In principle, you don't need a checksum, since you have a built-in majority decoder capability. Heath insists that two frames (minutes) in ten be identical to achieve lock. You can do much better than this, even without changing the format, with a little imagination and spare microprocessor cycles. Dave
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 88 23:20:24 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Time synchronization and distribution plan
Folks, There is good news for clockwatchers, timewarpers and chron daemons. All radio clocks known to me are now finally repaired and ticking to standard time. Also, venerable WWVB ticker dcn1.arpa (aka pogo), which some of you may fondly remember from years past, has resumed this life. There is even a NTP secondary time server on the European MILNET which is keeping pretty good time. There are a half-dozen or so gents who have scrounged up an old PDP11-compatible system and volunteered additional GOES or WWV servers as well. It may be time (!) to bring some order to the clockwatching business. A treaty is suggested in this note. As in the telephone systems NTP uses a model of stratified clocks and servers. A primary server is one directly synchronized to a radio clock, so it can keep accurate time even in the absence of NTP itself. However, from long experience with such things, the radio clocks sometimes feature scrambled time due radio propagation conditions or broken logic. Thus, the primary servers ordinarily run NTP with a couple of their buddies as a sanity check. Should the radio clock itself become suspect, time synchronization shifts to the NTP peer group. Secondary servers are synchronized with NTP using special filtering and deglitching mechanisms ordinarily accurate to a few tens of milliseconds, even across intransigent gateways. NTP can be used in either a remote-procedure-call (asymmetric) mode, in which a client sends a single message to the server and receives the time in reply, or a distributed (symmetric) mode, in which the protocol runs continuously and time is continuously compared between the peers and corrected as required. The asymmetric mode is designed for casual use, such as setting the time and date when a PC comes up, for example, while the symmetric mode is designed for more accurate and precise applications, such as transaction timestamping and time redistribution. This note is concerned only with use of the symmetric mode. Not everybody can chime with a primary server, since this would eventually lead to severe congestion and degraded service. Therefore, a system of hierarchical time servers is suggested. Assume that each of the 400-odd networks now active has a secondary time server synchronized to one or more primary servers and providing time service to other hosts in its community. In order to provide the highest robustness, the secondary server should chime with more than one primary server, perhaps three, so we are talking about 1200 peer paths. The existing LSI-11 fuzzball gateways can support at least 60 peer paths each, so some twenty primary servers would be needed. At the moment NTP chimes one packet each direction per peer per minute, so the aggregate time traffic works out to about one packet each direction per fuzzball per second. It is planned to introduce NTP protocol modifications that would reduce this rate by a factor of ten. The twenty-odd primary servers should be located at strategic spots designed to minimize the impact of the NTP traffic itself, yet provide low delay dispersion for their customers. The existing and planned NSFNET Backbone sites would seem ideal candidates and, indeed, time-synchronized fuzzballs are already installed at seven of these sites. Without admitting agenda on how the time-synchronization capability came to pass or on the likely disposition of the fuzzballs once the new NSFNET Backbone is deployed, I suggest a nucleus of timetellers is already in place. Additional timetellers are now ticking on ARPANET and local nets gatewayed to ARPANET, MILNET and elsewhere. At the U Delaware campus and at several other campuses known to me, one or more relatively inexpensive WWV clocks are installed as backups should connectivity to a primary server be lost for one reason or another. The WWV clocks are distinctly inferior in accuracy and reliability with respect to the WWVB and GOES clocks now used at the primary servers; however, as some may remember, there have been occasions over the last several years when all primary servers in the experimental system were down and the entire NTP-speaking Internet was synchronized to a dinky WWV clock on my desk at home. I suspect several institutions that cherish accurate time will install GOES, WWVB or even GPS clocks and join the NTP chorus as well, so there may be in fact no need for an overt program to buy and install additional clocks. I saved specific recommendations for last. I suggest an appropriate first step is that those sites with good connectivity to an NSFNET regional system chime NTP with the NSFNET Backbone fuzzball serving that regional system. Other sites may wish to choose one or another fuzzball listed below. However, it is most important to understand that time service is provided by each of these gizmos on a secondary basis only, is still in an experimental phase and may be limited or curtailed should it interfere with the primary functions of the machine. Speaking for myself and I suspect the other operators listed, we would expect users to set up their own time-redistribution network, perhaps using the 4.3 bsd ntpd daemon specifically designed for this purpose, and to avoid ganging up on the servers with many hosts from the same net. We would also expect users planning long-term use of the servers to express their intent to the operators and comply with requests to reaffiliate with other servers should that become necessary. Finally, we are looking for volunteers to install additional primary servers and join the chorus as well. Name Address Clock Operator and notes -------------------------------------------------------------------------- Primary servers umd1.umd.edu 128.8.10.1 WWVB Mike Petry (petry@trantor.umd.edu) U Maryland (gatewayed to NSFNET Backbone, ARPANET PSNs 17 and 20 and MILNET PSN 57. wwvb.isi.edu 128.9.2.129 WWVB Steve Casner (casner@isi.edu) ISI (gatewayed to ARPANET PSN 22) ncar.nsf.net 128.116.64.3 WWVB Scott Brim (swb@devvax.tn.cornell.edu) NCAR (NSFNET Backbone gateway) dcn1.arpa 128.4.0.1 WWVB Dave Mills (mills@udel.edu) 10.2.0.96 U Delaware (directly connected to ARPANET PSN 96) ford1.arpa 128.5.0.1 GOES Fred Ball (ball@ford-vax.arpa) Ford Research (gatewayed via 9600-bps line to ARPANET PSN 111. Secondary servers (please do NOT chime with these except by permission) macom1.arpa 192.5.8.1 NTP Woody Woodburn (woody@macom2.arpa) 10.0.0.111 Linkabit, Vienna, VA swamprat.arpa 192.5.8.2 NTP Woody Woodburn (woody@macom2.arpa) Linkabit, Vienna, VA patch.arpa 26.6.0.2 NTP Dave Park (dpark@dca-eur.arpa) USECOM Stuttgart, FRG gw.umich.edu 35.1.1.1 NTP Hans-Werner Braun (hwb@mcr.umich.edu) U Michigan (WWV backup) xyzzy.umich.edu 35.1.1.3 NTP Hans-Werner Braun (hwb@mcr.umich.edu) U Michigan libra.rice.edu 128.42.1.64 NTP Paul Milazzo (milazzo@rice.edu) 10.4.0.62 Rice U dcn6.arpa 128.4.0.6 NTP Dave Mills (mills@udel.edu) Newark, DE (WWV backup) sdsc.nsf.net 192.12.207.1 NTP Scott Brim (swb@devvax.tn.cornell.edu) San Diego Supercomputing Center uiuc.nsf.net 128.174.5.14 NTP Scott Brim (swb@devvax.tn.cornell.edu) National Center for Supercomputing Aplications psc.nsf.net 128.182.1.2 NTP Scott Brim (swb@devvax.tn.cornell.edu) Pittsburg Supercomputing Center cornell.nsf.net 128.84.238.50 NTP Scott Brim (swb@devvax.tn.cornell.edu) Cornell U (NYSERNET) jvnc.nsf.net 128.121.50.20 NTP Scott Brim (swb@devvax.tn.cornell.edu) John von Neumann Center (JVNCNET) nsfnet-gw.umd.edu 128.8.10.6 NTP Mike Petry (petry@trantor.umd.edu) U Maryland (SURANET) Corrections or additions to this list would be appreciated Dave
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 24 Jan 88 12:46:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Hop problem
The 30+ packet radio hop was a deliberate attempt at maximizing the number of nets/hops the packet traversed. I think 64 is still a reasonable maximum. We should be trying hard to design the system so the maximum hop count is far less than 64, of course. Vint
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: Sun, 24 Jan 88 22:24:52 -0500 From: Mike Brescia <brescia@PARK-STREET.BBN.COM> To: "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU> Cc: tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM Subject: Re: Hop problem
The Internet Protocol Time to Live (TTL) field was introduced as a way of
detecting and supressing loops. Ideally, a packet would be timed as it passes
from source host through gateways, packet switches, satellite links and to the
destination, and further within the destination while awaiting fragments for
reassembly in the IP layer. Since clocks are not yet universally syncronized,
the only thing we see being done is decreasing the TTL within each gateway.
The IP spec. states that a gateway must decrease this field by at least 1
(otherwise it could possibly live forever).
Now, when the TTL is viewed as a field decremented by each gateway a packet
passes, it appears to be a hop count field. Packet radios or packet switches
are actual hops in a network, but do not alter the TTL field, even though we
sometimes saw queueing delays in the Arpanet in the 10-20 second range.
packet-radio people are talking about ... a 30+ hop routing
I think Phil Karn said something about that path being only about 10 seconds
long. Also, I expect that the radio hops were not doing gateway functions, so
they did not count the IP TTL field.
mike
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: 24 Jan 88 16:27:41 GMT From: jqj@hogg.cc.uoregon.EDU To: comp.protocols.tcp-ip Subject: Re: Time synchronization and distribution plan
As a matter of principal, I don't think it is appropriate to design a time synchronization system for longterm use as strictly hierarchical. That makes it too susceptible to Byzantine failures on the parts of nodes high in the hierarchy, that cause problems for very large subtrees. It would make the time synchronization system particularly inappropriate in a military/tactical environment, for example. Although one may not like the specific algorithms, I prefer the Cornell (Schneider, Toueg, etc.) approach, that attempts to achieve consensus among a set of peers at any level. For practical purposes, it is probably acceptable to model the system as a hierarchy of SETS of time servers, each set having 5 to 10 members. Presumably, algorithms can be chosen to insure that the probablility of Byzantine failure of the whole SET is acceptably low. However, this implies that we should design a system in which the core/primary timeservers expect to be queried not by a large number of mutually independent secondary servers, but by a large number of members of sets of secondaries. For example, we might have a set of secondaries on a given regional network all of whom attempt to achieve consensus among themselves but who also all query the primaries as a time reference. Note that it implies also that any given secondary must plan to query several primaries (to detect Byzantine failures in the primaries). Correspondingly, it implies more network traffic unless we are careful in the placement of servers. I think this suggests at least a 3-level rather than 2-level hierarchy of time servers, where level 3 is generally individual networks or small groups of such networks, and level 2 is large (wellconnected) subsets of the whole Internet. Comments? P.S. I would also like to see more thought given to how we should cope with situations in which the radio timebases are inaccurate or inconsistent.
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: 24 Jan 88 20:26:05 GMT From: carrs@TROUT.NOSC.MIL (Stephen M. Carr) To: comp.protocols.tcp-ip Subject: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
-------
Ladies/Gentlemen,
1. We are about to lay the keel for networking at this command
and we must devise a game plan for MILNET and local TCP/IP
interconnectivity.
2. Among other incompatibilities, we have some unknowns in the
form of a WANG VS-300, a community within the command that has
procured and started installation of an ARCNET with I believe
Novell Netware, and many Honeywell DPS-6 minicomputers.
3. My objective is to try to implement an IEEE 802.3 Ethernet as
a backbone network gatewayed into a MILNET PSN. All other
networks in the command would be gatewayed into this backbone
Ethernet. This backbone Ethernet would have no hosts directly
connected to it, only gateways. The networks with hosts directly
connected would be subnets. This is the game plan that Mike
Karels, UC Berkeley suggested to me at the UNIX Berkeley
Networking symposium at Techmart that Advanced Computing
Environments held in August 1987. I have to believe that he
knows what he is talking about.
4. My problem is that we are complete neophytes when it comes to
TCP/IP internet as well as local networking. We cannot afford to
spend a lot of taxpayer funds making lots of mistakes trying to
learn what is going on.
5. Unfortunately, we are confronted with several problems.
a. The command has a WANG VS-300 which I don't know how we
are going to connect via TCP/IP. Is there anybody out there that
can tell me if there is a TCP/IP solution out there or in the
wings for a WANG VS-300? The vendor is promising the moon, but
WANG sales representatives promised me this same moon about 12
months ago. They are going to brief us on Tuesday, 26 January
1988 with their latest promises. I would sure appreciate some
straight skinny from any other users out there that have any
experiences with getting a WANG VS-300 singing on the internet!
I would like to go to this meeting armed with comments from this
forum if at all possible.
b. Some forces within the command that are concerned with
PCs have procured and are already installing an ARCNET with
Novell Netware. I don't know much about ARCNET, and I seem to
remember seeing some comment about it about 2 months ago in this
forum. I see no evidence to indicate to me that you can get the
ARCNET/Novell Netware to interoperate via TCP/IP at the present
time. Again, any comments from users having experience in trying
to get the ARCNET to sing along with TCP/IP in an internet
environment would be most appreciated.
c. We have some 18 or more Honeywell DPS-6s in this command
that we are going to have to internet also. There are already a
few IEEE 802.3 Ethernets installed on aircraft carriers servicing
the DPS-6 hardware onboard. My understanding is that this is
actually Bridge Communications Corporation's IEEE 802.3
hardware/software with a Honeywell label on it. In any event, we
as a CDA (Central Design Agent) must be able to emulate this
Ethernet environment on our aircraft carriers. Problem! I
understand that they have implemented XEROX XNS in this IEEE
802.3 environment vice TCP/IP. Does anybody make a gateway or
protocol converter that will allow Honeywell DPS-6s singing XNS
on an Ethernet to communicate TCP/IP with the internet?
6. We seem to be off to the races with all of the hardware and
software necessary to build our own Tower of Babel. My objective
is to somehow, some way, see if we cannot get all of this to
interoperate via TCP/IP and the MILNET.
7. Many thanks to the dozen or so folks that responded to my
plea for help on KERMIT for the Honeywell DPS-6! We did draw
down the object code, but for some reason, the source is not
available. We seem to be making progress as a result of your
help. Your immediate response was most appreciated!
8. Any suggestions, comments, or recommended alternatives
regarding our TCP/IP internetworking dilemma will be most
appreciated.
Very Respectfully,
Steve Carr
LCDR, SC, USN
Navy Management Systems Support Office (Code 42A)
Naval Air Station
Norfolk, Virginia 23511-6694
MILNET: carrs@trout.nosc.mil
MILNET: navmasso42a@nardacva.arpa
(804) 445-2171, 445-1595 (extension 36)
AUTOVON: 565-2171, 565-1595 (extension 36)
-------
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: 24 Jan 88 20:46:15 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Time synchronization and distribution plan
jqj, While I can understand your concern about Byzantine agreement, there may never be enough primary servers that everybody can play with very many of them, so I think we are stuck with a hierarchy, even if we quibble on the number of strata (to borrow the telephonic term). I am concerned about broken radio clocks, hosts, networks and leap-seconds, as witness the experiments I reported in RFCs 956-958 which were repeated recently with interesting results. I have no problem in organizing subsets of clocks which might run Byzantine algorithms in order to determine the truthtellers and falsehood speakers; however, my main concern is the accuracy and stability of the basic time service itself. I have taken a statistical approach which attempts to maximize the quality of the data using signal filtering and smoothing techniques which detect and discard outlyers due to broken clocks and are based on the assumption that at least half the clocks are tracking the same random variable and the rest are uniformly distributed over the observation interval (see RFC-956). These algorithms have been extensively simulated and tested in prototype implementations now running and have proved extremely resilient to noisy networks, broken clocks and jittery gateways but not, I admit, to broken programmers. Dave
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 02:05:00 GMT From: W8SDZ@SIMTEL20.ARPA (Keith Petersen) To: comp.protocols.tcp-ip Subject: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
Steve, I saw your note in the TCP/IP newsgroup and I think we have what you need to run TCP/IP on ARCNET. The following files are available via standard anonymous FTP from SIMTEL20: Filename Type Bytes CRC Directory PD1:<MSDOS.PCIP> BOOTP.ARC.1 BINARY 15088 6A80H DOC.ARC.1 BINARY 622913 53C7H INCLUDE.ARC.1 BINARY 38768 D21FH INSTALL.BAT.1 ASCII 2354 9BC2H PCIP-DIS.TXT.1 ASCII 2334 19ACH PPP.ARC.1 BINARY 6768 407BH README..1 ASCII 4931 DF58H ROOT.ARC.1 BINARY 8494 5070H SRCCMD.ARC.1 BINARY 228864 F269H SRCDEV.ARC.1 BINARY 6768 6298H SRCLIB.ARC.1 BINARY 331417 C8C3H TARREAD.EXE.1 BINARY 17704 D35AH WATCH.EXE.1 BINARY 34304 E21FH The files above are the CMU PCIP package. In addition to those you will need the ARCNET-specific files (be careful when extracting as some member filenames are the same as those in other ARCs). Filename Type Bytes CRC Directory PD1:<MSDOS.ARCNET-PCIP> ARCNET.ARC.1 BINARY 19889 4B5CH ARCNET-RFC.TXT.1 ASCII 5622 E04CH CUSTOM.ARC.1 BINARY 16061 8391H INCLUDE.ARC.1 BINARY 9294 7B81H INTERNET.ARC.1 BINARY 17017 A921H Here is a message from the author of the ARCNET version. Please contact him for further details. Date: Saturday, 9 January 1988 23:46-MST From: Philip A. Prindeville <PAP4@AI.AI.MIT.EDU> To: w8sdz@SIMTEL20.ARPA Re: New Release of KA9Q TCP/IP Package I saw your posting to pcip about ka9q. I've used simtel20.arpa many times, and I very much appreciate it's function. It the same spirit (I hope), I've done some work on the mit/cmu pc/ip that I think many people will find use for, including fragmentation and reassembly in IP, support for ARCnet hardware, and currently a supdup.sys console driver for ms-dos and multiple connection tcp. -Philip
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 02:55:45 GMT From: gt-eedsp!emory!km@gatech.edu (Ken Mandelberg) To: tcp-ip@sri-nic.arpa Subject: KA9Q TCP/IP on a Mac?
I just tried running the current release of KA9Q TCP/IP
(fresh off of simtel20) on a Mac. Specifically it was
a Mac Plus with 1 Meg of memory, running System 4.2 and
Finder 6.0.
The TCPIP program comes up with a console window and a
KA9Q logo and prompt, which immediately line feeds itself
up and off the screen (with no input from the keyboard).
The program is unresponsive and the Mac has to be rebooted.
Any suggestions?
--
Ken Mandelberg | {decvax,sun!sunatl,gatech}!emory!km UUCP
Emory University | km@emory BITNET
Dept of Math and CS | km@emory.ARPA ARPA,CSNET
Atlanta, GA 30322 | Phone: (404) 727-7963
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 03:24:52 GMT From: brescia@PARK-STREET.BBN.COM (Mike Brescia) To: comp.protocols.tcp-ip Subject: Re: Hop problem
The Internet Protocol Time to Live (TTL) field was introduced as a way of
detecting and supressing loops. Ideally, a packet would be timed as it passes
from source host through gateways, packet switches, satellite links and to the
destination, and further within the destination while awaiting fragments for
reassembly in the IP layer. Since clocks are not yet universally syncronized,
the only thing we see being done is decreasing the TTL within each gateway.
The IP spec. states that a gateway must decrease this field by at least 1
(otherwise it could possibly live forever).
Now, when the TTL is viewed as a field decremented by each gateway a packet
passes, it appears to be a hop count field. Packet radios or packet switches
are actual hops in a network, but do not alter the TTL field, even though we
sometimes saw queueing delays in the Arpanet in the 10-20 second range.
packet-radio people are talking about ... a 30+ hop routing
I think Phil Karn said something about that path being only about 10 seconds
long. Also, I expect that the radio hops were not doing gateway functions, so
they did not count the IP TTL field.
mike
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 03:36:27 GMT From: van@LBL-CSAM.ARPA (Van Jacobson) To: comp.protocols.tcp-ip Subject: new version of tcpdump available
There's a new version of tcpdump (v1.17) available for anonymous ftp from internet host lbl-rtsg.arpa (128.3.254.68), compressed tar file tcpdump.tar.Z. There are no major changes but several bug fixes and a couple of new flags. In addition to the tcpdump update, a couple of new trace analysis awk scripts have been added. This version was compiled -fswitch so it should work on Sun-3s without a 68881. And no, the source still isn't available (but will be soon I hope). - Van
-----------[000291][next][prev][last][first]----------------------------------------------------
Date: 25 Jan 88 03:54:31 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
Date: Sun, 24 Jan 1988 19:05 MST
Cc: tcp-ip@sri-nic.arpa
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
[ ... ]
The files above are the CMU PCIP package. In addition to those you
will need the ARCNET-specific files (be careful when extracting as
some member filenames are the same as those in other ARCs).
Filename Type Bytes CRC
Directory PD1:<MSDOS.ARCNET-PCIP>
ARCNET.ARC.1 BINARY 19889 4B5CH
ARCNET-RFC.TXT.1 ASCII 5622 E04CH
CUSTOM.ARC.1 BINARY 16061 8391H
INCLUDE.ARC.1 BINARY 9294 7B81H
INTERNET.ARC.1 BINARY 17017 A921H
I will take this chance to clarify a few things (my fault: I was
too lazy to write a README). The ".ARC" extension means ARChive,
the format the files are grouped as; previous users of SIMTEL20
will recognize this. The first two files above are the device
driver for an ARCnet interface (PDI, DATAPOINT, or SMC) and the
accompanying RFC that describes IP over ARCNET. CUSTOM includes
some generic modifications to support memory (not IO) mapped
devices (which ARCNET IFs tend to be). INCLUDE and INTERNET
are changes to the standard distribution that offer increased
functionality to IP and ICMP -- some of that functionality was
required to support ARCNET, but is not ARCNET specific. For
instance, fragmentation/reassembly had to be added to get decent
performance out of ARCNET, but will work equally well with
pronet, ethernet, and token ring. The files in INCLUDE, INTERNET,
and CUSTOM are meant to replace their counterparts in the CMU
distribution in \INCLUDE, \SRCLIB\INTERNET, and \SRCCMD\CUSTOM
respectively. You may want to back up these files before
replacing them.
Enjoy,
-Philip
-----------[000292][next][prev][last][first]----------------------------------------------------
Date: 25 Jan 88 04:43:55 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
[ ... ]
forum. I see no evidence to indicate to me that you can get the
ARCNET/Novell Netware to interoperate via TCP/IP at the present
time. Again, any comments from users having experience in trying
to get the ARCNET to sing along with TCP/IP in an internet
environment would be most appreciated.
Your assumption about TCP/IP & NETWARE co-existance is correct: they
don't (at this time). The actual standard for IP over ARCNET is
quite new. You can get a copy of my draft RFC as "pub/arcnet.rfc"
on the host gmu90x.gmu.edu (via anonymous/ftp). John Romkey of
FTP Software, Inc. devised a standard LLC level access method for
applications to access a network interface that is not datalink
or hardware dependent (see the PCIP archives for details). Novell
supports this interface for several network types (including
ethernet), and could be convinced to support it on ARCnet as well
(if you have the bucks to make it worth their while).
I had intended to write such a driver myself, but haven't had time.
Should someone care to provide me with such software, I will make
a version of PCIP to utilize it concurrently with Netware.
Lastly, ARCNET packets do contain sufficient information to
demultiplex IP and Netware protocols, so they can be run over
the same wire.
Good luck in resolving you situation,
-Philip
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: Mon, 25 Jan 88 11:44:43 EST From: Steve Carmody <STC@BROWNVM> To: TCP-IP@SRI-NIC.ARPA Subject: ip router for appletalk/pc-network (broadband) or token ring
I'm looking for an IP router to connect appletalk (twisted pair network) to pc-network channel on a broadband system. Such a unit would probably be built on a PC of some sort. In PC's, PC Network cards and token ring cards have the same software interface, so something that connected appletalk to token ring could probably be made to work. Does any one have/know of a router that connects to these two media? Does anyone have code for a PC that drives IP into any of the Appletalk cards that are available for PC's? thanks for any help or information.
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 08:10:45 GMT From: macg@alberta.UUCP (Mike MacGregor) To: comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.iso Subject: Bulk data transfer
This is my second attempt at posting this: Does anyone have a bibliography on bulk data transfer protocols handy ? ( Bulk data = at least 50 Mbits, more like 200 Mbits ) How about past experiences/attempts, etc., particularly on LANs ? Mail direct - I'll summarize for the net if response warrants. uucp: macg@alberta Innately analog: (403)432-3978 ean: macg@pembina.alberta.cdn disclaimer: I'm saving all my opinions for my thesis.
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 13:46:29 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: Time synchronization and distribution plan
This discussion concerning time synchronization is interesting but I must be missing the point somewhere. For the dissemmination (sp) of message traffic I fail to see why it is important to be synchronized within 1 or 2 milliseconds. If time is important, such as for real-time ranging data, it would seem that one should purchase a WWV receiver and interface which ain't all that expen- sive. The biggest problem will be clock "jitter" introduced by programmers like myself who used the JFFO (DECSystem 10) instruction to decode the 48 bit BCD milliseconds since start of year for timestamping real-time data. The cause of the "jitter" was a side effect of the JFFO instruction which should have been found immediately except everyone was impressed by an actual use for the JFFO instruction. I digressed. The solution is sites and subnets with "real-time" requirements should have their own WWV receivers with only "nominal" pinging of the net to verify the WWV receiver has not failed. The rest can use their time of day clocks since time isn't that important. Merton Campbell Crockett
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 15:35:10 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Time synchronization and distribution plan
Merton, I don't know where you are as the ionosphere flies, but in my corner of this world I sure would not trust my WWV receiver to stamp my archives. I would trust my WWVB receiver rather more, except just now even that signal has dropped below the floor and the clock is almost a second off. I did in fact suggest exactly the model you mention, using a more-or-less reliable local radio clock and verifing sanity with nominal pinging of its friends. Now, about the protocol to accomplish those pings... I started in this hokey business mostly to support accurate performance measurement and analysis of the Internet; however, as time ticked on it became an end in itself and lots of fun as well. Maybe you don't care about time to the millisecond, but then you probably don't do any computerized trading, wide-area monitoring and so forth. For example, with the system now in place I have been able to compare timestamped error reports collected from several packet switches and merge them into a scenario accurate to within the flight time of packets between switches. Last night I killed first one radio clock and then another untill all WWVB primary radio clocks were disabled. I verified all the primary and secondary time servers switched their hierarchical allegance until the ultimate backup WWV clocks at U Michigan and U Delaware kicked in. So far as I could tell, all time servers maintained synchronization to within a few tens of milliseconds throughout the experiment. However, in this case all clocks were observably sane. The next experiment is to insanitize a couple of them and verify the rest toss them out of the club. Dave
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 16:21:00 GMT From: stev@ftp.COM (Stev Knowles) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
In article <315728.880124.PAP4@AI.AI.MIT.EDU>, PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") writes:
>
> [ ... ]
> forum. I see no evidence to indicate to me that you can get the
> ARCNET/Novell Netware to interoperate via TCP/IP at the present
> time. Again, any comments from users having experience in trying
> Your assumption about TCP/IP & NETWARE co-existance is correct: they
> don't (at this time). The actual standard for IP over ARCNET is
>
> -Philip
sorry, but i was under the impression that Novell offered a card for their
file server (a micom interlan NP-600) that allowed for tcp-ip access from any
novell netware to a tcp-ip ethernet. i am under the impression that they
are running tcp-ip buried inside their own packets, and the file server
is stripping them out and passing them to the NP600. i have seen this
work for ethernet, and was under the impression that it worked for all the
networking schemes that novell supported.
stev knowles
ftp software inc.
617 868 4878
/*
all comments are mine
*/
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 18:24:48 GMT From: halley!bc@im4u.utexas.edu (Bill Crews) To: tcp-ip@sri-nic.arpa Subject: Re: TLI and Sockets
In article <349@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: > >Is there anything that would make a program running on a System V >Release 3 machine, using TLI, to communicate with a program running >on a machine using Sockets? Sockets and TLI are *interfaces*, not protocols. Socket-based and TLI-based applications intercommunicate all the time with no problem. In fact, many OSes on the Internet have neither sockets nor TLI and still intercommunicate. -bc -- Bill Crews Tandem Computers bc@halley.UUCP Austin, Texas ..!rutgers!im4u!halley!bc (512) 244-8350
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 18:27:47 GMT From: hassler@nap1.arpa (Barry D. Hassler) To: comp.protocols.tcp-ip Subject: Re: IP class B and C to X.25 address translation
Its been some time since I sent out my original message concern-
ing the subject, and I have received a few responses to my ques-
tion, but noone answered the question I asked (maybe I asked it
poorly).
My original question concerned the translation from IP addresses
to X.25 addresses for X.25 links, such as those on MILNET (each
answer I received told me about subnetting, which I do under-
stand). The X.25 standard used by DDN contains an appendix out-
lining the address translation, but it only works properly for
Class A addresses. The algorithm itself can be found in
NETINFO:X25.DOC.1 on sri-nic.arpa.
The algorithm used is as follows (copied out of X25.DOC, appendix
A):
------------------------------------------------------
A-8
A-5 Derivation of DDN X.25 Addresses
All DDN hosts are assigned addresses by the Administration.
The address of a DDN host may be obtained from the Network
Information Center (NIC), represented as an ASCII text string in
what is called "host table format". This section describes the
process by which DDN X.25 addresses in the format described in
Section 2.1.1 may be derived from addresses in NIC host table
format.
A NIC host table address consists of the ASCII text string
representations of four decimal numbers separated by periods,
corresponding to the four octets of a thirty-two bit Internet
address. The four decimal numbers are referred to in this
section as "n", "h", "l", and "i." Thus, a host table address
may be represented as "n.h.l.i" Each of these four numbers will
have either one, two, or three decimal digits and will never have
a value greater than 255. For example, in the host table address
"10.2.0.124", n=10, h=2, l=0, and i=124. To convert a host table
address to a DDN X.25 address:
1. If h < 64, the host table address corresponds to
the DDN X.25 physical address
ZZZZ F IIIHHZZ (SS)
where:
ZZZZ = 0000
as required in Section 2.1.1.1.1;
F = 0 because the address is a physical
address;
III is a three decimal digit
representation of "i", right-adjusted
and padded with leading zeros if
required;
HH is a two decimal digit representation
of "h", right-adjusted and padded
with leading zeros if required;,
ZZ = 00
and
(SS) is optional, as described in Section
2.1.1.1.4.
A-9
In the example given above, the host table address
10.2.0.124 corresponds to the DDN X.25 physical
address 000001240200.
2. If h > 64 or h = 64, the host table address
corresponds to the DDN X.25 logical address
ZZZZ F RRRRRZZ (SS)
where:
ZZZZ = 0000
as required in Section 2.1.1.1.1;
F = 1 because the address is a logical
address;
RRRRR is a five decimal digit
representation of the result "r" of
the calculation
r = h * 256 + i
(note that the decimal representation
of "r" will always require five
digits);
ZZ = 00
and
(SS) is optional, as described in Section
2.1.1.1.4.
Thus, the host table address 10.83.0.207
corresponds to the DDN X.25 logical address
000012145500.
In both cases, the "n" and "l" fields of the host table
address are not used.
-------------------------------------------------------------
Note that while this algorithm can be used on class B and C ad-
dresses, it maps out to duplicate X.25 addresses for certain
Class B and C addresses, since it only takes into account the
second and fourth octets of the address.
Are there any other standards being used for this translation
that will provide a one-to-one mapping of both class B and C ad-
dresses to X.25 addresses? I am running a quickly growing net-
work of hosts, and have receiveed several requests already for
X.25 connections to our gateway. I am very concered about the
address translations for our class B network addresses (subnetted
of course). I use portions of the third octet (depending upon the
size of the subnet, and whether or not it needs to be subnetted
further) for the subnetwork number and find that that octet does
not enter in the X.25 address at all. Therefore, If I would have
two X.25 hosts behind my gateway with addresses 129.48.1.1 and
129.48.32.1, they would both have the same X.25 address:
000011228900.
-BDH
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 20:16:36 GMT From: clyde!watmath!grand!jwkhong@rutgers.edu (James W. Hong) To: tcp-ip@sri-nic.arpa Subject: TCP/IP references
I am currently working on implementing TCP/IP on an experimental distributed operating system. I intend to communicate with TCP/IP on BSD 4.3 UNIX systems. Could someone direct me to tutorials or references (other than RFCs)regarding implementation of TCP/IP? Thanks in advance James W. Hong Dept. of Computer Science University of Waterloo 519-885-1211 x6178
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 88 23:56:41 GMT From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) To: comp.protocols.tcp-ip Subject: Banyan TCP/IP bridge
Good afternoon, Has anyone heard of(or did I just imagine it...) Banyan offeringa TCP/IP software bridge for their PC stuff? I remember reading about the proposed product but was wondering is it yet released and, if so, what's the feel of this particular animal? Thanks for any comments you may have, Chris VandenBerg ACC (chris@acc-sb-unix.arpa)
-----------[000302][next][prev][last][first]----------------------------------------------------
Date: 26 Jan 88 01:35:00 GMT
From: Hampton@DOCKMASTER.ARPA ("David R. Hampton")
To: comp.protocols.tcp-ip
Subject: BSD and IP optionsI ran into similar problems last October when working with options in 4.2 BSD. I believe I had to patch both the fragmentation and reassenbly routines to get things running. The most common problem I found was references to the size of a 'standard' IP header [sizeof(ipasfrag)], instead of references to the size of the current datagram's header [ip->ip_hl*4]. If you need more specifics, drop me a note and I'll look them up. David +--------------------------------------------------------------+ | David R. Hampton Ma Bell:(301) 859-4537 | | Hampton @ Dockmaster.ARPA | +--------------------------------------------------------------+
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 08:47:27 GMT From: garcia@TSCA.ISTC.SRI.COM To: comp.protocols.tcp-ip Subject: NEW CALL FOR PAPERS--SIGCOMM 88
Enclosd is the call for papers for SIOGCOMM 88. Please note the new
deadline for paper submission of MARCH 19. The event will be a
symposium consisting of paper sessions and panel sessions organized in
one track at a time. We are planning to have the final version of the
proceedings available at the conference (for those of us still waiting
for the SIGCOMM '87 proceedings this could be an added incentive).
Please contact Prof. Landweber at your earliest convenience to arranage
paper submissions or panel sessions.
JJ
----------
CALL FOR PAPERS
ACM SIGCOMM '88 SYMPOSIUM
Communications Architectures and Protocols
Stanford University, California
August 16-18, 1988
The symposium provides an international forum for the presentation and
discussion of communication network applications and technologies, as
well as recent advances and proposals on communication architectures,
protocols, algorithms, and performance models. Authors are invited to
submit full papers concerned with both theory and practice. The areas
of interest for the symposium include, but are not limited to the
following: analysis and design of computer network architectures and
algorithms, innovative results in local area networks,
computer-supported collaborative work, network interconnection and
mixed-media networks, high-speed networks, resource sharing in
distributed systems, distributed operating systems and databases,
protocol specification, verification, and analysis.
Papers should be about 20 double-spaced pages long and should have an
abstract of 100-150 words. All submitted papers will be reviewed and
will be judged with respect to their quality and relevance. Authors of
selected papers will be expected to sign an ACM copyright release form.
The Proceedings will be distributed at the symposium and published as a
special issue of SIGCOMM Computer Communication Review. A few of the
submitted papers will be selected for publication in the ACM
Transactions on Computer Systems.
Submit 5 copies of each paper to the program chairman: Dr. Lawrence H.
Landweber, Computer Sciences Department, University of
Wisconsin-Madison, 1210 West Dayton Street, Madison, Wisconsin 53706,
USA; Telephone: (608) 262-1204; EMAIL: lhl@parmesan.wisc.edu.
For more information about the symposium, contact
Dr. J.J. Garcia-Luna, General Chair, SRI International, 333
Ravenswood Ave., EK 319, Menlo Park, CA 94025, USA; Tel: (415)
859-5647; EMAIL: garcia@tsca.istc.sri.com; telex: 33486.
STUDENT PAPER AWARD
Papers submitted by students will enter a student-paper award contest.
Among the accepted papers, a maximum of four outstanding papers will be
awarded (1) full conference registration and (2) a travel grant of
$500.00 US dollars.
IMPORTANT DATES
Deadline for paper submission: March 19, 1988 (NEW DEADLINE!)
Notification of acceptance: April 20, 1988
Camera-ready manuscript due: May 18, 1988
SYMPOSIUM COMMITTEE
General Chair: J.J. Garcia-Luna-Aceves, SRI International, USA
Program Chair: L.H. Landweber, University of Wisconsin-Madison, USA
Local Arrangements: E. Feinler, SRI International, USA, and
D. Cheriton, Stanford University, USA
Tutorials Chair: N. Shacham SRI International, USA
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: Tue, 26 Jan 88 14:02:16 EST From: Bob Dixon <TS0400%OHSTVMA.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: Banyan TCP/IP bridge
As of the latest release of Banyan VINES software, a Banyan server will do
IP routing between any interconnection of Banyan servers and associated
micros. It will pass VINES packets inside IP packets to enable server-to-
server communications, if desired. Micros may be connected via either
token ring or ethernet to the server, and must at present use FTP, inc
software for tcp/ip communications. Banyan is now offering a server license
for FTP software which saves considerably in the $ dept.
Banyan plans to incorporate the FTP software into the server, making it part
of VINES, and hence more integrated for the user. Also, a gateway between
the Banyan mail system and SMTP is under development.
Now if only all this were available "today".
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000305][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 1988 1524-EST From: jpcodes@TYCHO.ARPA (Jim P. Codespote) To: tcp-ip at sri-nic.arpa Subject: Questions on MIL-STD-1778 (TCP)
I am trying to implement TCP in Ada. I am following the Military
Standard 1778 and I am having trouble following some of the events and actions.
My problem is what happens in a "net deliver" in an established state? (9
I found that the decision table is switched with the "net deliver" table
in the close wait state. Assuming I am useing the right table now, what should
happen when; seq num status is valid,
$OA
-------
-----------[000306][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 1988 1557-EST From: jpcodes@TYCHO.ARPA (Jim P. Codespote) To: tcp-ip at sri-nic.arpa Cc: jpcodes Subject: Questions on MIL-STD-1778 (TCP).
I am trying to implement TCP in Ada. I am following the Military
Standard 1778 and I am having some trouble in understanding it. My problem
is what happens in a "net deliver" in an established state? (9.4.6.1.5)
I found that the decision table is switched with the "net deliver"
table in the close wait state. Assuming I am using the right table now,
what should happen when; seq num status is valid, rst is on, sec prec
match is yes, syn in window is no, and ack status test2 is none? Does
this mean only data is being delivered? If so, why does the standard
say "no action"? Or, does this mean the only way data gets accepted is
if the segment contains an "ack"?
Is the standard in error or am I just missing the point? I would
greatly appreciate any suggestions. Thank you.
Please respond at jpcodes@TYCHO.ARPA
Jim Codespote
-------
-----------[000307][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 10:57:17 GMT From: ihnp4!tapa!larry@ucbvax.Berkeley.EDU (Larry Pajakowski) To: tcp-ip@sri-nic.arpa Subject: Whither Prime 63xx TCP/IP
We are looking for TCP/IP and Ethernet support for a Prime 63xx (6355?) computer. This is about our last hope else its going to be RS-232. Thanks Larry Pajakowski ihnp4!tapa!larry
-----------[000308][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 12:44:08 GMT From: backman@interlan.UUCP (Larry Backman) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
>> [ ... ] >> forum. I see no evidence to indicate to me that you can get the >> ARCNET/Novell Netware to interoperate via TCP/IP at the present >> time. Again, any comments from users having experience in trying >> Your assumption about TCP/IP & NETWARE co-existance is correct: they > >sorry, but i was under the impression that Novell offered a card for their >file server (a micom interlan NP-600) that allowed for tcp-ip access from any >novell netware to a tcp-ip ethernet. i am under the impression that they >are running tcp-ip buried inside their own packets, and the file server >is stripping them out and passing them to the NP600. i have seen this [] Disclaimer - I am prejudiced, this is my product. Micom - Interlan is shipping a Netware\TCP gateway. The gateway consists of an NP600 board placed within the file server. This board runs our standard TCP image. The gateway also consists of processes within the file server that act as daemons (FTPD, RWHOD, SMTPD, etc.). An additional process, the NETBIOS listener, is used to communicate with workstations. Workstations ( up to 31) talk to the file server and ultimately the gateway via NETBIOS. Application programs (FTP, TELNET et. al) ported from Bsd 4.3 encapsulate socket calls within NETBIOS NCB's and send the socket calls to the gateway where they are passed to the NP600. There are no TCP packets encapsulated within Netware IPX packets, instead socket calls are encapsulated within NETBIOS RPC's. Any Novell supported subnet can talk to TCP hosts using the gateway. I have seen it running on at least 6 different types of media, including ARCNET, and assume that it is running on at least another 6 types. For more information, please contact me directly. Larry Backman Micom - Interlan
-----------[000309][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 13:05:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Hop problem
Mike, the "packet radio" referenced was not the DARPA packet radio but the amateur packet radio. I don't know how those systems handle the TTL field. The DARPA packet radio system didn't pay any attention to TTL except at gateways since the packet radio net was "below" the IP protocol level. The amateur system, however, probably operates at the IP level like some of the more recent combined packet switch/gateways such as the Proteon 4200, Cisco boxes, and so on. Vint
-----------[000310][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 13:09:15 GMT From: Staff.Hershman@KL.GBA.NYU.EDU (Ittai Hershman) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
Date: 25 Jan 88 16:21:00 GMT
From: spdcc!ftp!stev@husc6.harvard.edu (Stev Knowles)
Organization: FTP Software Inc., Cambridge, MA
Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
> Your assumption about TCP/IP & NETWARE co-existance is correct: they
> don't (at this time). The actual standard for IP over ARCNET is
>
> -Philip
sorry, but i was under the impression that Novell offered a card for their
file server (a micom interlan NP-600) that allowed for tcp-ip access from any
novell netware to a tcp-ip ethernet. i am under the impression that they
are running tcp-ip buried inside their own packets, and the file server
is stripping them out and passing them to the NP600. i have seen this
work for ethernet, and was under the impression that it worked for all the
networking schemes that novell supported.
stev knowles
The Micom-Interlan TCP Gateway will work with any Novell supported
networking schemes, but does not run TCP directly to the client PCs.
The way it works is that the server contains whatever card is used to
talk to the clients (eg: ethernet, starlan, arcnet (I suppose)), and
additionally an NP600A (with a chip serialized to the TCP Gateway
software). Communication between client and server is done using the
Novell protocol and then converted to TCP/IP by the server and sent to
the ethernet backbone via the NP600A.
This has the added interesting property that only a single IP number is
needed for up to 32 simultaneous client PCs, making the administration
of "subnets" (I mean it in the sense of a PC lab, or a floor of offices)
much easier. It is also very cost effective, because you can buy very
cheap networking cards (Starlan in my case) for the client PCs. On the
negative side, some speed is obviously lost to the gatewaying.
-Ittai
-------
-----------[000311][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 13:13:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
NOVELL Netware and TCP/IP have been made to interoperate by Novell. My understanding of the method is that the file server in the Novell Netware system also has TCP/IP implemented. A user's PC forms a connection using Netware to a server process in the machine that also runs the file server and that process permits a TCP/IP connection to be formed going to the desired destination. I do not know any of the details of the software or how one conveys the desired IP destination to the TCP/IP server. It may behave like TELNET piggybacking (where you log into a host and TELNET back out again, specifying where you want to go to the User Telnet). Vint Cerf
-----------[000312][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 15:47:26 GMT From: morrison@accuvax.nwu.edu.UUCP (Vance Morrison ) To: comp.protocols.tcp-ip Subject: Re: Banyan TCP/IP bridge
Hello, Yes Banyan has anounced that it will be offering TCP/IP capabilities in its PC server. Unfortuately the product is not out yet. It was originally scheduled for release in late December, but now it looks like it will be out this April (but don't hold your breath). The TCP/IP capability is part of release 3.0 of Vines and Banyan has literature describing this and well as other new features of 3.0. From what I have been able to discover from my reading, is that Vines has integrated the TCP/IP protocols into Vines. This immediately means that Vines can route IP packets through the Banyan LAN, as well as route Vines packets across the internet. At present Banyan is not making products that use this new capability. Instead it has made deals with others (FTP Software Inc.) to provide products that will make the TCP capablities useful (namely telnet, ftp etc). These user products exist today. One product that is conspicuously absent, however is a internet mail bridge that will link into Banyan's local mail system. Banyan has provided the hooks for doing this, but at present will not release the name of any company that is working on it. In its simplest form, this is a simple piece of software, but without it Banyan's mail system will be cut off from the rest of the internet, severly limiting its usefulness. I have no doubt that such a product will come out, but frankly it may take a while (> 6 months) Vance Morrison morrison@accuvax.nwu.edu morrison@nuacc.bitnet morrison@northwestern.arpa
-----------[000313][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 17:02:54 GMT From: jimp@cognos.uucp (Jim Patterson) To: comp.protocols.tcp-ip,comp.lang.c Subject: Re: C binding interfaces for TCP/IP
In article <25@vdelta.UUCP> dave@vdelta.UUCP (Dave Arnold) writes:
>Are there efforts underway to standardize a C language interface for TCP/IP?
Sun has developed a definition called RPC (Remote Procedure Call)
which is becoming a defacto standard in some environments. RPC is
designed to support the function-call paradigm across TCP/IP
networks. Sun has published the protocol to encourage its
implementation on other systems. In conjunction with RPC, Sun has
an excellent protocol called XDR (eXternal Data Representation)
to deal with data conversions between different machine
architectures in a flexible but structured manner.
While I've studied these protocols a bit, I don't have any direct
experience with them. I also don't know if anyone has implemented
them on VAX/VMS systems (but I suspect that this has been done).
You might contact Sun Microsystems to get more information about
RPC and XDR.
--
Jim Patterson Cognos Incorporated
UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707
PHONE:(613)738-1440 3755 Riverside Drive
Ottawa, Ont K1G 3Z4
-----------[000314][next][prev][last][first]---------------------------------------------------- Date: Wed, 27 Jan 88 0:01:25 EST From: Mills@UDEL.EDU To: Bob Dixon <TS0400%OHSTVMA.BITNET@cunyvm.cuny.edu> Cc: TCP-IP@sri-nic.arpa Subject: Re: Banyan TCP/IP bridge
Bob, Do you access a Banyon server with a Batcher multiplexor, or is there another way to giggle the gigabits? Dave
-----------[000315][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 19:02:16 GMT From: TS0400@OHSTVMA.BITNET (Bob Dixon) To: comp.protocols.tcp-ip Subject: Re: Banyan TCP/IP bridge
As of the latest release of Banyan VINES software, a Banyan server will do
IP routing between any interconnection of Banyan servers and associated
micros. It will pass VINES packets inside IP packets to enable server-to-
server communications, if desired. Micros may be connected via either
token ring or ethernet to the server, and must at present use FTP, inc
software for tcp/ip communications. Banyan is now offering a server license
for FTP software which saves considerably in the $ dept.
Banyan plans to incorporate the FTP software into the server, making it part
of VINES, and hence more integrated for the user. Also, a gateway between
the Banyan mail system and SMTP is under development.
Now if only all this were available "today".
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000316][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 19:04:49 GMT From: hubcap@gatech.edu (Mike Marshall) To: tcp-ip@sri-nic.arpa Subject: pmdf - wollongonkulator
Hello - I would appreciate it if anyone who is running WIN/TCP 3.0 and pmdf 2.3 in a VMS environment would be willing to send me a copy of their pmdf.cnf file. I fooled around with the one here some today, trying to get it to work a certain way, and I had no luck. I feel like I would have more success if I had a few examples to go by. Even if you are not running the exact release levels that we are, I would appreciate a glance at your pmdf.cnf files... Thanks all - -Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap
-----------[000317][next][prev][last][first]---------------------------------------------------- Date: Wed, 27 Jan 88 00:14:40 EST From: "Philip A. Prindeville" <PAP4@AI.AI.MIT.EDU> To: carrs@TROUT.NOSC.MIL Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
Date: Mon, 25 Jan 88 10:43:37 CST
From: timk@ncsa.uiuc.edu (Tim Krauskopf)
Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
Our software may be of some help to you and is already paid for by
various state and federal taxpayers. It will not be too difficult to
write an ARCNET driver for the PC version of NCSA Telnet if you can
You can take an existing driver for PCIP and re-write it. This would be
fairly quick, and save you having to learn a lot about the COM 9026 chip.
I think Keith posted previously about where to get this and the related RFC.
get just a little help from the company. Your biggest problem will be
to find a gateway from ARCNET to Ethernet (802.3) to get out to the IP
world. You could use our base to write a simple-minded gateway for an
AT-class machine and forward all IP to some "smarter" host.
I know of no other ARCNET TCP/IP gateways. Novell does have a TCP/IP
[ ... ]
I know of someone who has written an ARCNET driver for KA9Q. This makes
a fairly decent (albiet low-performance, ~200pkt/sec) gateway. There
is also a pronet driver floating around, for ARCnet<->pronet... I'm
not sure about the availability (though it is PD), but if you're
interested, send me mail and I'll put you in touch.
-Philip
-----------[000318][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 20:24:00 GMT From: jpcodes@TYCHO.ARPA (Jim P. Codespote) To: comp.protocols.tcp-ip Subject: Questions on MIL-STD-1778 (TCP)
I am trying to implement TCP in Ada. I am following the Military
Standard 1778 and I am having trouble following some of the events and actions.
My problem is what happens in a "net deliver" in an established state? (9
I found that the decision table is switched with the "net deliver" table
in the close wait state. Assuming I am useing the right table now, what should
happen when; seq num status is valid,
OA
-------
-----------[000319][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 20:57:00 GMT From: jpcodes@TYCHO.ARPA (Jim P. Codespote) To: comp.protocols.tcp-ip Subject: Questions on MIL-STD-1778 (TCP).
I am trying to implement TCP in Ada. I am following the Military
Standard 1778 and I am having some trouble in understanding it. My problem
is what happens in a "net deliver" in an established state? (9.4.6.1.5)
I found that the decision table is switched with the "net deliver"
table in the close wait state. Assuming I am using the right table now,
what should happen when; seq num status is valid, rst is on, sec prec
match is yes, syn in window is no, and ack status test2 is none? Does
this mean only data is being delivered? If so, why does the standard
say "no action"? Or, does this mean the only way data gets accepted is
if the segment contains an "ack"?
Is the standard in error or am I just missing the point? I would
greatly appreciate any suggestions. Thank you.
Please respond at jpcodes@TYCHO.ARPA
Jim Codespote
-------
-----------[000320][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 21:00:26 GMT From: dan@MITRE-BEDFORD.ARPA (Willhite) To: comp.protocols.tcp-ip Subject: (none)
We are running a SUN3/60 under SUN UNIX 3.5. It is on an ethernet LAN connected by back-to-back gateways to a proprietary LAN. The proprietary LAN transmits TCP/IP utilizing the security option. From the documentation we have been able to uncover, no UNIX implementation utilizes this option. We have written code on The SUNS at the socket level utilizing SUN UNIX without the security options, but we have determined that they are necessary. We need to know if there is some way, at the socket level, to force SUN UNIX to transmit using security options. Is it also possible to force the option on the system to use top secret for all transmissions? We would also be interested to know if there are any other operating environments which DO implement the security option. Thank you. Dan (dan@mitre-bedford.arpa)
-----------[000321][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 88 23:02:52 GMT From: pogran@ccq.bbn.COM (Ken Pogran) To: comp.protocols.tcp-ip Subject: Re: IP class B and C to X.25 address translation
Barry,
How about the mapping that Andy Malis suggested in his message of
19 January?
There is an informal standardization for Class B: the first two
octets of the IP address are the network number, the third octet
is treated identically to the second octet of Class A addresses,
and the fourth octet is treated identically to the fourth octet
of Class A addresses. The third octet of Class A addresses is
dropped completely in Class B addresses.
There is absolutely no standardization for Class C, because there
are so few local network address bits to play with. The host
network software support person for Class C nets must provide his
or her own mapping between the Class C addresses and X.25
addresses for that net. For example, the five most significant
bits of the fourth octet of the Class C address could be the host
number, and the three least significant bits the PSN number. It
is a compromise between the number of PSNs on the network and the
maximum number of hosts on a PSN.
We've just put in a small "campus-area" Class B network of C/30
PSNs using this mapping.
If my memory serves me correctly (and it turns out that I'm the
author of the text in the DDN X.25 spec that you quoted -- though
not the originator of the algorithm), an earlier draft of the DDN
X.25 spec contained both Class A and Class B mappings. In review,
it was pointed out to us that since this was a _DDN_ X.25 spec,
and DDN was a Class A network, there was no need for a Class B
mapping in the DDN-specific document. In retrospect, it would
have been a good idea to put out the Class B mapping as an RFC at
the same time the DDN spec was published!
I think it's now time to put out that RFC ...
Ken Pogran
-----------[000322][next][prev][last][first]---------------------------------------------------- Date: 27 Jan 88 00:03:50 GMT From: lyndon@ncc.UUCP (Lyndon Nerenberg) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
In article <8801242026.AA29303@trout.nosc.mil>, carrs@TROUT.NOSC.MIL (Stephen M. Carr) writes: > [...] > 5. Unfortunately, we are confronted with several problems. > a. The command has a WANG VS-300 which I don't know how we > are going to connect via TCP/IP. Is there anybody out there that > can tell me if there is a TCP/IP solution out there or in the > wings for a WANG VS-300? The vendor is promising the moon, but > WANG sales representatives promised me this same moon about 12 > months ago. They are going to brief us on Tuesday, 26 January > 1988 with their latest promises. I would sure appreciate some > straight skinny from any other users out there that have any > experiences with getting a WANG VS-300 singing on the internet! > I would like to go to this meeting armed with comments from this > forum if at all possible. After having dealt with Wang regarding communications software on a number of occasions, all I can suggest is that you believe absolutely NOTHING they say... I highly doubt Wang will come out with Ethernet at any time. They have been promising this to us for over two years... As a result of the above, we decided to purchase their 2780RJE software to (at least) allow file transfer. As it turns out, their "IBM Standard 2780 RJE software won't talk to our Convergent Technologies 2780 RJE package", according to the Wang salesman. I know the CT software works, but I have been unable to get the VS65 to talk to it, so I guess (for once) the Wang salesman was not lying! Of course, I'd really like to know why they didn't tell us this prior to our purchasing the software (this configuration was in the spec) ... I have also been unable to get their X.25 software working in the same environment. If we could get this to function at least the Wang users would be able to call out to another host, although this doesn't even begin to approach the flexibility of having TCP/IP. We *did* find a solution though. We are scrapping the VS65, and replacing the workstations with PC/XT's (clones actually) running the Wang WP under MS-DOS. The clones have a replacement keyboard identical to the Wang keyboard. The VS65 will be replaced by a Sun 3/280. The clones will be running PC/NFS, allowing them to share file system space on the Sun. They can also telnet to any host on the Ethernet and can ftp files around as well. The *best* part of all this is the Sun + the PC's + the NFS cards and all the glue costs 30% less than the VS65 alone... I know this won't directly solve your problem, but I hope it gives you (and others) a bit of insight into alternatives to the very restricted Wang operating environment. [ Wow, I feel better now :-) ] --lyndon
-----------[000323][next][prev][last][first]----------------------------------------------------
Date: 27 Jan 88 04:38:03 GMT
From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
[ .... ]
My understanding of the method is that the file server in the
Novell Netware system also has TCP/IP implemented. A user's PC
forms a connection using Netware to a server process in the
machine that also runs the file server and that process permits
a TCP/IP connection to be formed going to the desired destination.
Well, I meant something more along the lines of each PC being its own
IP host (rather than TCP being a resource a remote server provides [I
hesitate to call the server a translating gateway]) where a user
could have both file service and TCP/IP software (say SMTP), without
the two applications fighting for the interface's interrupt...
-Philip
-----------[000324][next][prev][last][first]---------------------------------------------------- Date: 27 Jan 88 07:55:39 GMT From: HANK@BARILVM.BITNET (Hank Nussbacher) To: comp.protocols.tcp-ip Subject: Need help in filling in the gaps
I am trying to compile comparative rate tables for
- the cost of 64kb digital service in various countries
- the cost of a 56/64kb link to the USA or a T1 line to the USA
If you can help me fill in the gaps or have information about a country I
have not included, please send it to me. Once I have finished the work,
I will repost the final result.
Please reply directly to me and not to the list.
Thanks,
Hank
Cost comparison of 64kb digital service
in various countries
=======================================
Country 5km 10km 200km 500km
----------------+---------+---------+---------+---------+
Austria | 683.8 | 1025.6 | 4346.2 | 6141 |
Belgium | 372.5 | 683 | 1652 | 3304 |
Denmark | 174.6 | 293.9 | 1770.5 | 2139.8 |
France | 614 | 828.8 | 5241.8 | 6838.6 |
Germany | 795.2 | 1337.3 | 8385.5 | 11638.6 |
Norway | 242.2 | 242.2 | 602.5 | 869.6 |
Spain | 1507.9 | 2356.5 | 4996.9 | 6713.1 |
Sweden | 332.2 | 387.6 | 2214.8 | 2380.9 |
Switzerland | 758.8 | 1523.5 | 6604.4 | 8810.3 |
United Kingdom | 412.6 | 515.3 | 824.3 | 1128.5 |
----------------+---------+---------+---------+---------+
Average | 589.4 | 919.4 | 3663.9 | 4996.4 |
----------------+---------+---------+---------+---------+
Israel 1823 2136 14011 32761 (<50 lines)
Israel 1077 1077 1077 1077 (>50 lines)
Notes:
1) Rates are in dollars per month.
2) Sources: a) Report #219, "Tariff Analysis - National Digital Services
at 64kb and 2Mb, Claude Laurens, La Gaude, France,
December 14th, 1987
b) Israeli prices based on Sifranet and leased line price
sheets, Bezek, August 15th, 1987
International rates for high speed links to the USA
===================================================
Country 56/64kb 1.544M
----------------+---------+---------+
UK - MCI | 4654 | 40540 |
UK - BTI | 5943 | 45045 |
France | 6017 | 49557 |
Netherlands | | |
Germany | 9939 | 86746 |
Belgium |11500 | 115008 |
Norway | | |
Sweden | | |
Denmark | | |
Japan | | |
Spain | | |
Switerland | 8823 | |
Ireland | | |
Israel |13548 | |
Notes: 1) All rates are rates for connecting to the east coast in the
USA.
2) The rates only reflect half of the cost. The other half is
the rate for the link from the United States to the stated
country
3) All rates are cost per month in US dollars
-----------[000325][next][prev][last][first]---------------------------------------------------- Date: 27 Jan 1988 15:30:13 CST From: Link Verstegen@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: LINK@GUNTER-ADAM.ARPA Subject: Final Draft of AF LAN Interface/Security Module Specification
The final draft of the AF LAN Interface/Security Module Equipment Performance Specification is out for review. As before, the document is contained in the file [LAN-EPS]LAN.EPS.1 on the Gunter-Adam.ARPA. You can either log into the account and use kermit or modem to download the file or you can FTP it to your host. Again, the account is LAN-EPS and the password is LAN-EPS. You can address any comments to LAN-EPS@GUNTER-ADAM.ARPA. If you have anything you do not wish to share with the rest of the community, please address them to LINK@GUNTER-ADAM.ARPA. In either case, I will promptly respond with the disposition of your comments. Of specific interest are the technical issues of using Commercial Off The Shelf (COTS) MS-DOS software across a LAN and the implementation of the security controls. Any insights on either portion of the acquisistion are welcomed. Will it, as proposed, fit your needs? The contract award is planned for June 1, 1988, so we need your comments in the next two weeks or so to get them included. /| /| ===================/ |=================/ |=================== Link N. Verstegen Link@Gunter-ADAM.ARPA Computer Systems/Network Engineer HQ SSC/PRS (205)279-5151 Gunter AFS, AL 36114-6343 AV 446-5151 -------
-----------[000326][next][prev][last][first]---------------------------------------------------- Date: Wed, 27 Jan 88 14:34:49 EST From: Bob Dixon <TS0400%OHSTVMA.BITNET@CUNYVM.CUNY.EDU> To: Mills@UDEL.EDU, Bob Dixon <TS0400%OHSTVMA.BITNET@cunyvm.cuny.edu> Cc: TCP-IP@sri-nic.arpa Subject: Re: Banyan TCP/IP bridge
Dave,
I'm not sure I understand your question, but Banyan servers connect to
PC LANs via ethernet, token ring etc. as with any microcomputer net server.
Users on a PC have access to disks on the server by designating them as if
they were local disks on the PC. To deal with the internet, you must have
FTP, Inc software on the PC which provides all the usual tcp/ip services.
The Banyan server just routes the packets as needed. I feel that I am not
understanding what you are getting at. There are no multiplexors, etc
involved.
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000327][next][prev][last][first]---------------------------------------------------- Date: Wed, 27 Jan 88 10:55:39 P From: Hank Nussbacher <HANK%BARILVM.BITNET@CNUCE-VM.ARPA> To: earntech@cearn, tcp-ip@sri-nic.ARPA, telecom@xx.lcs.mit.edu Subject: Need help in filling in the gaps
I am trying to compile comparative rate tables for
- the cost of 64kb digital service in various countries
- the cost of a 56/64kb link to the USA or a T1 line to the USA
If you can help me fill in the gaps or have information about a country I
have not included, please send it to me. Once I have finished the work,
I will repost the final result.
Please reply directly to me and not to the list.
Thanks,
Hank
Cost comparison of 64kb digital service
in various countries
=======================================
Country 5km 10km 200km 500km
----------------+---------+---------+---------+---------+
Austria | 683.8 | 1025.6 | 4346.2 | 6141 |
Belgium | 372.5 | 683 | 1652 | 3304 |
Denmark | 174.6 | 293.9 | 1770.5 | 2139.8 |
France | 614 | 828.8 | 5241.8 | 6838.6 |
Germany | 795.2 | 1337.3 | 8385.5 | 11638.6 |
Norway | 242.2 | 242.2 | 602.5 | 869.6 |
Spain | 1507.9 | 2356.5 | 4996.9 | 6713.1 |
Sweden | 332.2 | 387.6 | 2214.8 | 2380.9 |
Switzerland | 758.8 | 1523.5 | 6604.4 | 8810.3 |
United Kingdom | 412.6 | 515.3 | 824.3 | 1128.5 |
----------------+---------+---------+---------+---------+
Average | 589.4 | 919.4 | 3663.9 | 4996.4 |
----------------+---------+---------+---------+---------+
Israel 1823 2136 14011 32761 (<50 lines)
Israel 1077 1077 1077 1077 (>50 lines)
Notes:
1) Rates are in dollars per month.
2) Sources: a) Report #219, "Tariff Analysis - National Digital Services
at 64kb and 2Mb, Claude Laurens, La Gaude, France,
December 14th, 1987
b) Israeli prices based on Sifranet and leased line price
sheets, Bezek, August 15th, 1987
International rates for high speed links to the USA
===================================================
Country 56/64kb 1.544M
----------------+---------+---------+
UK - MCI | 4654 | 40540 |
UK - BTI | 5943 | 45045 |
France | 6017 | 49557 |
Netherlands | | |
Germany | 9939 | 86746 |
Belgium |11500 | 115008 |
Norway | | |
Sweden | | |
Denmark | | |
Japan | | |
Spain | | |
Switerland | 8823 | |
Ireland | | |
Israel |13548 | |
Notes: 1) All rates are rates for connecting to the east coast in the
USA.
2) The rates only reflect half of the cost. The other half is
the rate for the link from the United States to the stated
country
3) All rates are cost per month in US dollars
-----------[000328][next][prev][last][first]---------------------------------------------------- Date: 27 Jan 88 14:54:05 GMT From: nelson@sun.com (Russ Nelson) To: tcp-ip@sri-nic.arpa Subject: booting using tftp
Is anyone out there booting PCs using tftp? Is it possible to cram tftp into the 8K that is available on the NI5210 (for example)? We want to be able to boot machines from anywhere on our network. Floppies won't do for three reasons: the license restricts the operating system to a single machine, users need access to machines that they don't have an operating system for, and users can't be trusted not to trash floppies. -- ------------------------------------------------------------------------------ AT&T: (315)268-6591 BITNET: NELSON@CLUTX Internet: nelson@clutx.clarkson.edu GEnie: BH01 Compu$erve: 70441,205
-----------[000329][next][prev][last][first]---------------------------------------------------- Date: 27 Jan 88 16:50:38 GMT From: malis@CC5.BBN.COM (Andy Malis) To: comp.protocols.tcp-ip Subject: Re: IP class B and C to X.25 address translation
Barry, To reiterate my earlier message on the subject: for Class B, use the same algorithm, but replace the Class A second octet with the Class B third octet; in other words, treat the Class B number's octets as n1.n2.h.i and use the Class A algorithm. There is no standard for Class C - you have to roll your own algorithm by dividing up the last octet into h and i bits. It's your choice as to which bits are h and which are i. Once you've done that, again follow the Class A algorithm. Regards, Andy
-----------[000330][next][prev][last][first]---------------------------------------------------- Date: 27 Jan 88 17:04:04 GMT From: jonab@CAM.UNISYS.COM (Jonathan P. Biggar) To: comp.protocols.tcp-ip Subject: Re: Questions on MIL-STD-1778 (TCP).
> I found that the decision table is switched with the "net deliver" >table in the close wait state. Assuming I am using the right table now, >what should happen when; seq num status is valid, rst is on, sec prec >match is yes, syn in window is no, and ack status test2 is none? Does >this mean only data is being delivered? If so, why does the standard >say "no action"? Or, does this mean the only way data gets accepted is >if the segment contains an "ack"? You are right about the tables being switched. For your second question, I am assuming that you really mean rst is off. (If you do mean rst is on, then the last line of the table should be used and the connection should be reset and closed.) In this case what is happening is that the connection is probably receiving an old duplicate SYN packet from the other end. The only packets that do not have ACK set are an SYN packet generated from an active open request, or a RST packet in reponse to a SYN-ACK packet received on a closed connection. Since RST is not on, the only valid packet that can be received here is a duplicate SYN. Note that even though this packet may contains a SYN, the SYN is not in the window because the 'sv.rcv_next' variable was already incremented past the SYN sequence number by the action procedure record_syn. The proper response to a packet containing a duplicate SYN is just to ignore it. By the way, I have just completed a CRAD contract from DCA to develop MIL-STD implementations of TCP and IP in Ada. The code has been tested for conformance to MIL_STD 1777 and 1778. I believe that the code is available for free from DCA. If you are interested in it, let me know and I will find out how you can acquire it. Jon Biggar jonab@cam.unisys.com Distributed Architectures Branch Unisys Defense Systems Camarillo, CA
-----------[000331][next][prev][last][first]---------------------------------------------------- Date: 27 Jan 88 18:16:17 GMT From: estrin@rt234.usc.EDU (Deborah L. Estrin) To: comp.protocols.tcp-ip Subject: Visa paper draft Finally available
A DRAFT of the visa protocol paper mentioned long ago is now ready for
limited distribution.
Those of you who requested copies via usmail will receive
them shortly. Those who requested copies via email, are asked
to ftp it over to save the mail systems. If this is not possible
for you let me know and i will send email or usmail.
The draft isavailable by anonymous ftp on oberon.usc.edu in pub/draft_visa.tex
It is still a Draft so we recommend that you only look at it if
you are seriously interested in providing us with some feedback
with the understanding that it is not finished and is not intended for broad
distribution.
thank you, Deborah Estrin (and co-authors Jeff Mogul of Digital and
Gene Tsudik of USC)
-----------[000332][next][prev][last][first]---------------------------------------------------- Date: 27 Jan 88 19:34:49 GMT From: TS0400@OHSTVMA.BITNET (Bob Dixon) To: comp.protocols.tcp-ip Subject: Re: Banyan TCP/IP bridge
Dave,
I'm not sure I understand your question, but Banyan servers connect to
PC LANs via ethernet, token ring etc. as with any microcomputer net server.
Users on a PC have access to disks on the server by designating them as if
they were local disks on the PC. To deal with the internet, you must have
FTP, Inc software on the PC which provides all the usual tcp/ip services.
The Banyan server just routes the packets as needed. I feel that I am not
understanding what you are getting at. There are no multiplexors, etc
involved.
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000333][next][prev][last][first]---------------------------------------------------- Date: 27 Jan 88 21:30:13 GMT From: Link@SRI-NIC.ARPA, Verstegen@GUNTER-ADAM.ARPA To: comp.protocols.tcp-ip Subject: Final Draft of AF LAN Interface/Security Module Specification
The final draft of the AF LAN Interface/Security Module Equipment Performance Specification is out for review. As before, the document is contained in the file [LAN-EPS]LAN.EPS.1 on the Gunter-Adam.ARPA. You can either log into the account and use kermit or modem to download the file or you can FTP it to your host. Again, the account is LAN-EPS and the password is LAN-EPS. You can address any comments to LAN-EPS@GUNTER-ADAM.ARPA. If you have anything you do not wish to share with the rest of the community, please address them to LINK@GUNTER-ADAM.ARPA. In either case, I will promptly respond with the disposition of your comments. Of specific interest are the technical issues of using Commercial Off The Shelf (COTS) MS-DOS software across a LAN and the implementation of the security controls. Any insights on either portion of the acquisistion are welcomed. Will it, as proposed, fit your needs? The contract award is planned for June 1, 1988, so we need your comments in the next two weeks or so to get them included. /| /| ===================/ |=================/ |=================== Link N. Verstegen Link@Gunter-ADAM.ARPA Computer Systems/Network Engineer HQ SSC/PRS (205)279-5151 Gunter AFS, AL 36114-6343 AV 446-5151 -------
-----------[000334][next][prev][last][first]---------------------------------------------------- Date: Thu, 28 Jan 88 08:52:24 -0500 From: adrion@SH.CS.NET To: iab@isi.edu, npag@udel.edu, steve@note.nsf.gov, tcp-ip@sri-nic.ARPA, csnet-ec@SH.CS.NET Cc: adrion@cs-umass.ARPA, cosepup@postgres.Berkeley.EDU Subject: Help...looking for network anecdotes
I am on the NAS/COSEPUP Panel on Information Technology and the Conduct of Science. We are preparing our final report. One of the key recommendations will be for an expanded and stable internet. We really need some anecdotes on how networks have enabled scientific research. We need examples of how new research or breakthroughs are directly attributable to networks. There are numbers of examples to support our other recommendations, such as the isolation of cold viruses using supercomputers, how computer graphics have helped to discover minimal surfaces and aid in the design of new molecules and organisms, how special purpose architectures have aided in the real-time analysis of data, etc. We need similar examples for computer networks, even if they involve only mundane uses such as EMail. Any anecdotes will be gratefully accepted. Thanks in advance. Rick Adrion
-----------[000335][next][prev][last][first]---------------------------------------------------- Date: 28 Jan 88 02:58:15 GMT From: tsudik@MALIBU.USC.EDU (