The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1989)
DOCUMENT: TCP-IP Distribution List for January 1989 (262 messages, 137199 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1989/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:      3 Jan 89 16:15:00 GMT
From:      stanonik@NPRDC.ARPA (Ron Stanonik)
To:        comp.protocols.tcp-ip
Subject:   imp messages cause system crash, 4.3bsd

Description:
	imp "interface reset" and "imp going down" messages
	occassionally cause the system to crash.  The proximate
	cause is a call to hostcompress (from hostreset) which
	empties the hosttable (sc->imp_hosts), but fails to clear
	a hosttable pointer (sc->imp_hostq).  If hostq was zero
	when the hostreset occured (ie, no active connections),
	then no problem, otherwise the kernel eventually tries
	to reference into the hosttable using hostq (which is
	probably no longer a hosttable mbuf) and gets a segmentation
	fault.
Repeat-By:
	Hard to repeat.  We groveled around in crash dumps.  If
	you have an ecu, you might try hitting the reset button
	while you have active imp connections.  Depending on what
	ends up in the hostq mbuf, you might crash.
Fix:
	The Berkeley networking updates contained a fix in hostslowtimo
	to clear hostq before calling hostcompress.  We moved the
	clearing of hostq into hostcompress.

RCS file: RCS/if_imphost.c,v
retrieving revision 1.2
diff -c -r1.2 if_imphost.c
*** /tmp/,RCSt1013362	Tue Jan  3 07:14:57 1989
--- if_imphost.c	Fri Dec 30 07:30:28 1988
***************
*** 179,191 ****
  hostcompress(unit)
  	int unit;
  {
  	register struct mbuf *m, **mprev;
  
! 	mprev = &imp_softc[unit].imp_hosts;
  	while (m = *mprev) {
! 		if (mtod(m, struct hmbuf *)->hm_count == 0)
  			*mprev = m_free(m);
! 		else
  			mprev = &m->m_next;
  	}
  }
--- 179,195 ----
  hostcompress(unit)
  	int unit;
  {
+ 	struct imp_softc *sc;
  	register struct mbuf *m, **mprev;
  
! 	sc = &imp_softc[unit];
! 	mprev = &sc->imp_hosts;
  	while (m = *mprev) {
! 		if (mtod(m, struct hmbuf *)->hm_count == 0) {
  			*mprev = m_free(m);
! 			if (sc->imp_hostq == m)
! 				sc->imp_hostq = 0;
! 		} else
  			mprev = &m->m_next;
  	}
  }
***************
*** 223,230 ****
  			} else {
  				any = 1;
  				hostrelease(hp);
- 				if (sc->imp_hostq == m)
- 					sc->imp_hostq = 0;
  			}
  		    }
  		}
--- 227,232 ----

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 89 20:39:31 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Go-Ahead Considered Harmless??

Can someone refresh my memory -

When a TELNET connection is first opened, what is the state of
Go-Ahead?  Is it enabled and does it have to be negotiated away?  Or
can it just be ignored?

Has anyone experience problems with TAC114 and having lock-ups between
the TAC and a terminal?

Mike

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 89 21:46:48 GMT
From:      gryphon!cadovax!ucla-an!medivax!jgb@elroy.jpl.nasa.gov  (J. Grant Bristow)
To:        tcp-ip@sri-nic.arpa
Subject:   Interactive rsh

I hope this is the appropriate newsgroup to post this request, but
I couldn't find a more appropriate one.

I need a version of rsh that communicates interactively.  I need to
execute a remote (and interactive) command, pass the TERM environment
variable, and setup ptys and such on the remote machine.  Much like
what rlogin does.  In addition, it would be nice to be able to pass
signals across the network, also.  The remote command would act just
like the user rlogin'd to that machine then executed the command from
the system prompt.  Of course, when the command completed, the user would
be returned to their local host.

It seems like a stupid thing to do, but for naive and non-technical users,
it could be a life-saver.  All I want to do is bring the power of another
computer, easily to some users on their local machines.  I guess I'm trying
to "hide" the network from them.

Is this unreasonable to ask?  Has this been done?  Is there a better way?

Grant Bristow
System Administrator, Dept. of Medicine, UCLA

-- 
Grant
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 89 22:19:08 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Conclusion of "MILNET, EGP, ROUTING, PSN 7.0, RFNM BLOCKAGE"

It appears that the problems Node 90 was having on the MILNET, resulting in 'RFNM blockage', were due to broken memory in the C30 that caused
an incorrect packet size to be used in the checksum calculation.

None of my surmises were correct.  But, it was fun while it lasted.  4 Weeks.

Phil,  cpw@lanl.gov

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Jan 89 15:12 EST
From:      "I am only an egg." <JOHNSON@nuhub.acs.northeastern.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Information request.
     Hi folks.  Happy New Year.

     Sorry to bother the whole list with this but I wasn't sure what 
else to do.

     I'm looking for people who are running Wollongong and/or NRC FUSION 
on VMS.  I'm looking for the usual war stories and the answer to 
"Which should I buy?".  I need a good replacement for CMU TCP/IP which 
was a temporary fix to another vendor's product that didn't work.

     Thanks much.

Chris Johnson
Northeastern University.
Internet: johnson@nuhub.acs.northeastern.edu
BITNET:   johnson@nuhub
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 89 14:13:43 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  Go-Ahead Considered Harmless??

[Warning: long discourse, but maybe worth it to protocol hackers of
a middling level of expertise.]

Mike,

Since I blundered into expounding Telnet the other day, I suppose I
might as well take a shot at this one too.  Under the original theory
of Go-Ahead, they are supposed to be used until their suppression is
negotiated (Suppress Go-Ahead Option).  GA is supposed to tell the
telnet process receiving it to do whatever is the appropriate act to
unlock the keyboard of the NVT.  It is supposed to be sent by the other
telnet end whenever it knows that keyboard input is the next thing that
needs to happen.  The definition of when they are supposed to be used
is inherently loose, so it is hard to pin a problem on any setting of
this option, unless you are actually using a 2741-like terminal that
really locks its keyboard, and a telnet implementation that can drive
such a terminal.

There was NEVER any rule that said that a telnet process should ever
actively lock the keyboard of its NVT!!  That was a feature of the IBM
2741 terminal family (and some others) which unfortunately couldn't be
turned off.  2741's aren't even supposed to be supported by TACs
nowadays - they were weird in lots of ways and the extra code to
support them ate up memory - and I don't know of a way for GA-related
nonsense (e.g., a broken host Telnet) to "legitimately" lock up a
telnet driving a normal full-duplex terminal.  Were this to occur, I
would suspect some kind of brokenness in the TAC.  I'd be inclined to
look for the brokenness elsewhere in the protocol interactions first
(or even in the hardware), but, who knows, bizarre things happen
sometimes.

The Host Requirements RFC is taking the position that Go-Ahead is
obsolete and should be treated as always suppressed, independent of the
setting of the SGA option.  I'll append the text at the end of this
message for the sake of interested parties.

One quasi-lockup I have seen with TACs in the past, not specifically
114, is really a host problem of dealing with TCP window behavior of
the TAC, which is "strange" compared to what some implementors seem to
expect.  (It does not behave like UNIX.  This seems to be a difficult
concept for some to get a handle on.)  The TAC is more likely than
'most' hosts to present zero windows, often has small windows, tends to
have window sizes that jump around, and has a (sometimes) varying
low-frequency component to its 'maximum window' offered during various
portions of the lifetime of a connection.  I think all this stems from
the TAC being a rather buffer-starved animal.  When it is heavily
loaded, the small buffers per terminal port mean small windows which
fill up with one (submaximal) packet.

I *think* that some implementations have gotten into trouble by
overreacting to the zero windows, maybe immediately going into a 2
minute zero window probe cycle.  This isn't a lockup but it's an
excessive wait for a small buffer (maybe 32 or 64 bytes) to drain.  If
the zero window probe code in the host is totally broken, then it might
actually lock up.  RFC 793 (unfortunately, in my view) seems to justify
immediately going to a 2 minute timer when a zero window occurs.  I
think I believe that one should use an exponential backoff from RTO to
2 minutes.  If the TAC sends a new ACK with updated window when the
buffer drains, the host should come off its zero window probe.  Of
course, this ACK might get lost - improbable if host and TAC are on
same subnet, more likely if a busy gateway is in between.  Failure of
the TAC to spit out this window update ACK is an imaginable contributor
to lockup or quasi-lockup.

I've spent a few minutes trying to figure out what interactions exist
between Jacobson style TCP and TACs but did not get far, so far.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

----------

         [Host Requirements RFC Draft]

         5.4.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858

            The Telnet Go Ahead (GA) signal is obsolete; server Telnet
            implementations should not try to support sending GA
            commands.  A server Telnet should always accept negotiation
            of the Suppress Go Ahead option (i.e., reply "WILL Suppress
            Go Ahead" to "DO Suppress Go Ahead").

            User Telnet implementations that do not explicitly negotiate
            the Suppress Go Ahead option from the server must accept,
            but may ignore, GA commands.

            DISCUSSION:
                 Half-duplex ("locked-keyboard") line-at-a-time
                 terminals for which the Go-Ahead mechanism was designed
                 have largely disappeared from the scene.  This is
                 fortunate, since it turned out to be difficult or
                 impossible to implement sending the Go-Ahead signal in
                 existing operating systems, even those systems that
                 support native half-duplex terminals.  The difficulty
                 was that the Telnet server code does not typically have
                 access to information about whether the user process is
                 blocked awaiting input from the Telnet connection,
                 i.e., it cannot reliably determine when to send a Go-
                 Ahead.

                 Telnet Server hosts do not generally implement sending
                 GA commands.  Therefore, even when the Suppress Go
                 Ahead option is not negotiated, a User Telnet should
                 not expect a Server to ever send a GA, or believe a GA
                 that it receives.

                 There is a class of half-duplex terminals that is still
                 commercially important: "data entry terminals," which
                 interact in a full-screen manner.  However, supporting
                 data entry terminals using the Telnet protocol does not
                 require the Go Ahead signal; see Section 5.4.3.2.

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Jan 89 00:33
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK>
To:        "I am only an egg." <@nss:JOHNSON@nuhub.acs.northeastern.edu>
Cc:        tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: Information request.
Chris,
 
 
We first had version 2 of the Wollongong product some 2 years ago. It
was so bad I went out and bought the CMU TCP/IP. Then it seems as if a
SWAT team moved into the company because version 3 came out and that
was a big Win (if you know your Wollongong product that was a pun).
My immediate needs were for IP/TCP/FTP/STMP but now moving into the
other godies provided eg domain name servers. The company is good at
tracking the continuing developments (lke the Van J improvements to
TCP) and I understand that the changes for VMS V5 will be available
in the UK real soon now.
 
John Laws
Distributed Information System Div
RSRE Malvern
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 89 20:05:47 GMT
From:      stewarta@sco.COM (Stewart I. Alpert)
To:        comp.dcom.lans,comp.sources.wanted,comp.protocols.tcp-ip
Subject:   tn3270


Does anyone know where I can get the sources to tn3270? 

thanks,

stewarta@sco.COM	...!uunet!sco!stewarta
@ucscc.ucsc.edu:stewarta@sco.COM

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 89 20:12:00 GMT
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.")
To:        comp.protocols.tcp-ip
Subject:   Information request.


     Hi folks.  Happy New Year.

     Sorry to bother the whole list with this but I wasn't sure what 
else to do.

     I'm looking for people who are running Wollongong and/or NRC FUSION 
on VMS.  I'm looking for the usual war stories and the answer to 
"Which should I buy?".  I need a good replacement for CMU TCP/IP which 
was a temporary fix to another vendor's product that didn't work.

     Thanks much.

Chris Johnson
Northeastern University.
Internet: johnson@nuhub.acs.northeastern.edu
BITNET:   johnson@nuhub

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 89 22:54:08 GMT
From:      paul.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!palmieri@rutgers.edu  (Amigo)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Interactive rsh
In article <545@medivax.UUCP> jgb@medivax.UUCP (J. Grant Bristow) writes:

> I need a version of rsh that communicates interactively.  I need to
> execute a remote (and interactive) command, pass the TERM environment
> variable, and setup ptys and such on the remote machine.  Much like
> what rlogin does.  In addition, it would be nice to be able to pass
> signals across the network, also.  The remote command would act just
> like the user rlogin'd to that machine then executed the command from
> the system prompt.  Of course, when the command completed, the user would
> be returned to their local host.

Well, I agree.  It would be nice if such a thing existed.  Securely,
that is.  It does exist under SunOS...it is a program called "on" and
uses a special remote execution daemon which has had many security
problems, the most disturbing of which have not been fixed in Sun's
newest OS release.  In fact, the daemon that runs this show comes
commented out of Sun's services file but appears on the distribution.
As you can tell, I am a little upset about that, but that's another
story.  I don't know if such a thing exists on the VAX (I assume
that's what you're using...), but if it does, I would advise you to
check for any and all holes...the way to beat Sun's version is
dishearteningly trivial.
-- 
					
					Tom Palmieri
					  `Amigo'

=============================== Mail Addresses ================================
UUCP: {backbone}!rutgers!aramis.rutgers.edu!palmieri
Internet: palmieri@aramis.rutgers.edu
===============================================================================
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Jan 89 10:33:00 PST
From:      hjs@lindy.Stanford.EDU (Harry Saal)
To:        chris@salt.acc.com, tcp-ip@sri-nic.ARPA
Subject:   Re: Toshiba T3200 and the LANalyzer
Page A-7 of the LANalyzer documentation lists various machines and speeds
that the EXOS 225 and 325 boards are known to work at.  As you can see,
the older 225 board has many many limitations due to either 16 bit slots
or higher than 6 Mhz bus speed.  The T3200 runs with a 12 Mhz bus (although
I've been told there is an undocumented BIOS call which will slow the CPU
and the bus down to 6 Mhz), and the only full size slot is a 16 bit connector.
I would doubt very much if the 225 will run in a T3200 at its full speed.
On the other hand, if Excelan claims it will, then obviously you either
have a bad board (they should replace it) or a bad Toshiba (they should
replace it).

If you had bought NGC's Sniffer Model 300, which includes the T3200 plus
the full extra 3MB of expanded memory, fully supported, you wouldn't have
integration problems like this. This is the reason we are not in the business  
of selling a board level product. (For a good laugh, try running stuff --
just about ANYTHING) in the recent IBM PS/2 Model 30/286. This is clearly
the "PCjr" of AT-clones. It takes a special effort to make something so
totally incompatible with existing AT cards, and I guess only IBM can
afford to put the requisite number of engineers to the task! I think it
must never have been tested with actual 16-bit cards with memory mapped
buffers.
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 89 03:27:38 GMT
From:      iglesias@orion.cf.uci.edu (Mike Iglesias)
To:        comp.protocols.tcp-ip
Subject:   Re: Information request.

In article <8901042354.AA01166@ucbvax.Berkeley.EDU> JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") writes:
>...
>     I'm looking for people who are running Wollongong and/or NRC FUSION 
>on VMS.  I'm looking for the usual war stories and the answer to 
>"Which should I buy?".  I need a good replacement for CMU TCP/IP which 
>was a temporary fix to another vendor's product that didn't work.

We've been running WIN/TCP since version 2.3, and have had very few
problems with it.  We've been running the current release, WIN/TCP
v5.0, for about 3 weeks now with no problems.  V5.0 runs on VMS
v5.0 on uniprocessors only - the release for SMP systems is currently
in beta-test.


Mike Iglesias
University of California, Irvine

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 89 08:33:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: Information request.

Chris,
 
 
We first had version 2 of the Wollongong product some 2 years ago. It
was so bad I went out and bought the CMU TCP/IP. Then it seems as if a
SWAT team moved into the company because version 3 came out and that
was a big Win (if you know your Wollongong product that was a pun).
My immediate needs were for IP/TCP/FTP/STMP but now moving into the
other godies provided eg domain name servers. The company is good at
tracking the continuing developments (lke the Van J improvements to
TCP) and I understand that the changes for VMS V5 will be available
in the UK real soon now.
 
John Laws
Distributed Information System Div
RSRE Malvern

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 89 11:22:20 GMT
From:      brent@uwovax.uwo.ca (Brent Sterner)
To:        comp.protocols.tcp-ip
Subject:   FUSION TCP/IP s/w *NOT* reliable !!!

This is a simulated cross-post.  It was posted to comp.os.vms earlier this am.

SUMMARY: Do *NOT* purchase FUSION IP s/w for VMS 5.x and SMP at this time!
=======     -----          ---------------------------------
Details:
   Our site took advantage of an offer from DEC to acquire a 6230 and chose
to exchange our 8600 and 8550 in the process.  Our site also runs other
systems (UNIX, CDC NOS/VE, ETA PIPER, etc.), so we decided a proprietary
terminal protocol was *not* the thing to use.  So we elected to use TCP/IP
instead of LAT.  Fortunately, there seemed to be 3rd party IP s/w available
for VMS 5.x and SMP.  We ordered the FUSION s/w.
   I will not go into the functionality problems which exist.  They are
worthy of a separate posting anyway.  But the FUSION s/w has caused repeated
SYSTEM CRASHES ever since it was installed.  I did not expect perfection the 
first time around, BUT I DID EXPECT SOME RESPONSIVENESS TO PROBLEM REPORTS.
We have been continually trying to get in touch with technical people inside
FUSION.  They *appear* to be stonewalling us.
   We are beginning to look at alternatives.  If anyone is running IP for
5.x and SMP successfully, please let me know (email to me please).  We are
very displeased with the *perceived* response FUSION has given to our problems.
   In fact, it is interesting to note that perception is at least as important
as fact.  Our sense of frustration would be much alleviated if FUSION would at
least talk to us, whether or not they were actually making progress with our
problems.  It is also interesting to note that DEC have been *VERY* cooperative
in examining our crash dumps and suggesting ways to capture more information
to assist FUSION.  DEC is to be commended here (London Ontario area).
   I will follow up this posting as things develop.  Brent.

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 89 11:58:38 GMT
From:      van@HELIOS.EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Re: Go-Ahead Considered Harmless??

> I've spent a few minutes trying to figure out what interactions exist
> between Jacobson style TCP and TACs but did not get far, so far.

Bill -

The 20 line comment preceeding the relevant code in tcp_output
probably makes it hard to find (I keep telling Mike Karels that
C is self documenting -- he insists on these huge block comments
that just use up screen real estate when you're trying to read
the code :-).  Take a look at the code below the comment that
starts "TCP window updates are not reliable,...".  If the timer
setup in tcp_setpersist seems obscure, see the 30 or so lines of
comment in tcp_input that start with the line "srtt is stored as
fixed point with 3 bits ...".  (Some other code relevant to
poor, buffer-starved TACs, but not with zero windows, is
associated with the sender's estimate of the peer's receive
buffer size, max_sndwnd.  See the comment starting "Sender silly
window avoidance..." in tcp_output.)

The code does just what you thought it should -- probe with
exponential backoff from the current RTO -- and has done this in
every version of BSD since 4.1c.  There is no 2 minute timer and
never has been.  There is a 5 second minimum interprobe time
(which seems to accommodate the human response time in the usual
zero window cause on a local net -- ^S on a terminal -- and is
effectively a nop on a long haul net).  Attached is a trace of
what happens when the window goes to zero (obtained by starting
an ftp from a file on yak to a terminal window on okeeffe then
^S'ing the window).  Note the first probe goes out 5 sec after
the zero window is announced, there are 3 probes at 5 sec
spacing (it takes 2 backoffs to ramp the 1 sec rto above the
minimum interprobe time), then pure binary exponential after
that (if you don't want to compute them, the deltas between probe
sends are 5, 5, 5, 8, 16, 32 & 64 sec starting from the zero-window
ack at 00:56:14.65 and the probe at 00:56:19.48).

If your comment referred to interaction between slow-start
and/or congestion avoidance and TACs, the answer is there isn't
any.  The only 4BSD congestion algorithm that comes into play
with TACs is John Nagle's small packet avoidance algorithm
(which is essentially the computation of "idle" and the line
"if ((idle || tp->t_flags & TF_NODELAY) &&" below the comment
starting "Sender silly window avoidance..." in tcp_output) and
by all reports this is an unmitigated win.

 - Van


00:56:14.31  okeeffe.1064 > yak.ftp-data: . ack 114177 win 4096
00:56:14.31  yak.ftp-data > okeeffe.1064: . 116225:116737(512) ack 1 win 4096
00:56:14.32  yak.ftp-data > okeeffe.1064: . 116737:117249(512) ack 1 win 4096
00:56:14.32  yak.ftp-data > okeeffe.1064: . 117249:117761(512) ack 1 win 4096
00:56:14.32  yak.ftp-data > okeeffe.1064: P 117761:118273(512) ack 1 win 4096
00:56:14.45  okeeffe.1064 > yak.ftp-data: . ack 116225 win 2048
00:56:14.51  okeeffe.1064 > yak.ftp-data: . ack 117761 win 512
00:56:14.65  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:19.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:19.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:24.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:24.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:29.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:29.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:37.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:37.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:53.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:53.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:57:25.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:57:25.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:58:29.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:58:29.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 89 14:58:11 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Interactive rsh


*It seems like a stupid thing to do, but for naive and non-technical users,
*it could be a life-saver.  All I want to do is bring the power of another
*computer, easily to some users on their local machines.  I guess I'm trying
*to "hide" the network from them.

*Is this unreasonable to ask?  Has this been done?  Is there a better way?

*Grant Bristow
*System Administrator, Dept. of Medicine, UCLA



how about something like the X window system? this allows you to access
the resources of other machines, and will give you a window interface
which your users may find easier to deal with (so i am told, i am not sure
i believe it).


stev knowles
ftp software
stev@ftp.com
...!ftp!stev

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 89 15:43:18 GMT
From:      wash08!hjf98@uunet.uu.net  (hjf98)
To:        tcp-ip@sri-nic.arpa
Subject:   Network Monitor

We have a multi-vendor Ethernet network of NCR Towers, VAXen, and
PC LAN's, all using TCP/IP.  I'm looking for a network monitor
to analyze the load on the network.  What equipment do some of you
use for this purpose?  I have heard of the "Sniffer" from Network
General (very expensive), and of course, the Excelan LANalyzer.
Any comments on these?

-- 
Harry J. Foxwell -- Sr. Systems & Network Engineer
American Chemical Society --------- Washington, DC
Phone: (202) 872-6022 --------- uunet!wash08!hjf98
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 89 18:33:00 GMT
From:      hjs@LINDY.STANFORD.EDU (Harry Saal)
To:        comp.protocols.tcp-ip
Subject:   Re: Toshiba T3200 and the LANalyzer

Page A-7 of the LANalyzer documentation lists various machines and speeds
that the EXOS 225 and 325 boards are known to work at.  As you can see,
the older 225 board has many many limitations due to either 16 bit slots
or higher than 6 Mhz bus speed.  The T3200 runs with a 12 Mhz bus (although
I've been told there is an undocumented BIOS call which will slow the CPU
and the bus down to 6 Mhz), and the only full size slot is a 16 bit connector.
I would doubt very much if the 225 will run in a T3200 at its full speed.
On the other hand, if Excelan claims it will, then obviously you either
have a bad board (they should replace it) or a bad Toshiba (they should
replace it).

If you had bought NGC's Sniffer Model 300, which includes the T3200 plus
the full extra 3MB of expanded memory, fully supported, you wouldn't have
integration problems like this. This is the reason we are not in the business  
of selling a board level product. (For a good laugh, try running stuff --
just about ANYTHING) in the recent IBM PS/2 Model 30/286. This is clearly
the "PCjr" of AT-clones. It takes a special effort to make something so
totally incompatible with existing AT cards, and I guess only IBM can
afford to put the requisite number of engineers to the task! I think it
must never have been tested with actual 16-bit cards with memory mapped
buffers.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 89 21:57:11 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Toshiba T3200 and the LANalyzer


*of selling a board level product. (For a good laugh, try running stuff --
*just about ANYTHING) in the recent IBM PS/2 Model 30/286. This is clearly
*the "PCjr" of AT-clones. It takes a special effort to make something so
*totally incompatible with existing AT cards, and I guess only IBM can
*afford to put the requisite number of engineers to the task! I think it
*must never have been tested with actual 16-bit cards with memory mapped
*buffers.


that is strange, we have one here, and have tested (and run) it with
both western digital 8003E and Interlan 5210 ethernet cards. we also
tried a BICC card, but it was an older rev (3.0? they are on at least
5.0 now) and it didnt work. while it is true these are not 16 bit
boards, i have not noticed any compatibility problems with the
machine. i have run both PC/TCP and LANWatch on the IBM Model 30/286
with no problems (other that the stupid screws on the case. this is
*not* one of the "PS/2 take apart with a quarter" machines.  and i
admit the was the connectors are attached to the motherboard leaves
something to be wished for (the same with the model 25).

as a side note, we have also run wd8003, ni5210 and DLINK cards in
our t3200's running LANWatch and PC/TCP. neither have given us any
problems.


stev knowles
ftp software
stev@ftp.com
617-868-4878

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 89 23:54:48 GMT
From:      mws%beta@LANL.GOV (Mitchel W Sukalski)
To:        comp.protocols.tcp-ip
Subject:   connection between ARP and ICMP...


I'm in a slight dilemma here, and I was wondering if anybody out in
netland can help me?  I'm looking for documentation (RFCs, IENs, etc.)
that validates the behavior I'm going to describe.

I have a router with two network interfaces.  I'm trying to connect from
machine A, on one of the networks, to machine B, on the other network.
The router does not have an ARP entry for machine B, and when it receives
the first packet from machine A, it sends a "host unreachable" destination
unreachable ICMP message to machine A.  Simultaneously, it generates
an ARP request for machine B.

Some of the folks I have talked to have stated that it is the duty of 
the receiving machine, machine A in this case, to ignore the host
unreachable messages and use a timeout mechanism instead (reporting the
error condition upon timeout, perhaps).  As I see it, that makes sense
for an active connection (to avoid reacting to a transient network problem),
but upon opening a connection, an application, such as telnet,
should take heed of the error immediately and let the user take
the necessary recovery action.

In any case, I have been unable to find any documentation that says the
above behavior is within specification.  I have found ample statements to
the effect that the packet can be dropped, and an ARP request generated;
then, it is up to the transport protocol to resend the packet.  If the
ARP module has not gotten a reply, then the router could send a host
unreachable message.

I'd appreciate any insights or references.

Thanks in advance,

Mitch Sukalski
Communications Group, C-4
Los Alamos National Laboratory

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 02:03:28 GMT
From:      robert@SPAM.ISTC.SRI.COM (Robert Allen)
To:        comp.protocols.tcp-ip
Subject:   Is there a bug in SunOS 3.4's route program?



	While testing gated over a synchronous serial link running HDLC
    between a Sun 3/75 (running SunOS 3.4) and an HP 330 (running HP-UX 6.01),
    I've discovered what appears to be a bug in the program "route" on the
    Sun.  I'm hoping that somone can authoritativly confirm or deny that this
    is a bug, and help me with my dilemma.

			Here is the hardware situation
			------------------------------
	HP 330			sync serial line	Sun 3/75
	hdlc0 = 192.100.1.1  <========================> zss0 = 192.100.1.2

	On the HP I type "add route 192.100.1.0 192.100.1.1 0".  The result
    I get from a netstat -r -n is "192.100.1 192.100.1.1 U"

	On the Sun I type "add route 192.100.1.0 192.100.1.2 0". The result
    I get from a netstat -r -n is "192.100.1 192.100.1.2 UH".  Note that
    the route is shown as being a HOST route, not a network route.  This is
    wrong.

	In order to try and figure out why this was happening, I took the src
    to route.c on the Sun (sccsid = 1.1 86/02/05 SMI, from UCB 4.8 83/08/21)
    which we have, and put in some printf statements.  Note that I believe
    this src may be for 3.2, not 3.4 which I'm running on my Sun.

	I discovered several things which surprised me:

	(1) gethostbyname() now seems to take decimal dot notation in addition
	to human-readable names.

	(2) using the a.out (on the Sun) created by compiling my `instrumented'
	route.c file, I can execute the "route add" command mentioned above and
	end up with a network route ("192.100.1 192.100.1.1 U") as I desire and
	expect.  This route can also be deleted by using the a.out.

	(3) The correct network route added on the Sun via a.out, CANNOT be
	removed by the route command, returning a "not in table" diagnostic.
	The two binaries, route and a.out, do not produce compatible table
	entries when given the same input.

	After adding the network route on the Sun via a.out and on the HP
    via route, I can telnet across the link as I would expect.

	This tells me that I either have some bad "route" binaries floating
    around, or a bug/feature was introduced in the 3.4 SunOS version of route.

	In closing, I have two questions:
	(1) why does gethostbyname take decimal dot notation now in addition to
	names (is it because we're using yellow pages?)?

	(2) Why is the route binary behaving differently, and erroneously at
	that, than a binary compiled from the src?

    Thanks in advance for any help,

    Robert Allen
    robert@spam.istc.sri.com
    415-859-2143

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 02:36:27 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   routing hash table sizes on 4.3bsd

I started wondering about the efficiency of the routing table hash
algorithm used in 4.3bsd.  So I wandered over to my friendly neighborhood
gateway, built a modified netstat -r to dump chain lengths, and went at
it.  The good news is that the hash was quite even; each of the buckets
had about the same number of entries.  The bad news is that since the
machine was not configured with 'option GATEWAY', there were only 8
such buckets; this meant that the 672 routing entries (looking at the
network table only) were divided up just 8 ways...  So I ran the regular
netstat -r to get a snapshot of the table, built a small awk simulator
of the hash, and experimented with different numbers of buckets.  The
chart below shows the number of searches of each depth, for different
numbers of buckets.  8 and 64 are the choices with 4.3bsd, including
the latest copy I have of the network updates; clearly, neither is optimal.

	8:	 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 1 0 1 0 0 0 1 0 0 1 0 0 0 0 1 0 0 0 0 0 0 1
	64:	 0 0 0 1 2 2 7 5 10 8 8 6 2 2 6 3 1 1
	512:	 195 126 49 17 2
	1024:	 390 114 18
	2048:	 552 57 2

Actually, 8 buckets isn't just suboptimal; it's absurd.  Here's a different
way to look at 8 buckets; this time, the counts are the number of entries
hashed to each bucket:

	78   84   92   76   99   76   80   87

For 64, the numbers look like this:

	    8   11   15   12   12   11   10   16
	   16   12   15    7   14    6    8   10
	    8   11   18    9   12    7    9   10
	   16   13    9    9   13   12    9   12
	    6    7    7   10   11   10    7    9
	    4    7   10   14   17   15   15   15
	    9   15    9    8   11    5   11    5
	   11    8    9    7    9   10   11   10

Better, but still a fair number of searches of length 10 or more.

512 looks decent, but I'd recommend going to 1024 or 2048 buckets.
They're relatively cheap; each one only costs 8 bytes.  I also tried
a few prime numbers; some of them helped a bit, but the cost of the
division as opposed to the mask operation probably makes it not
worthwhile.

For some oddball cases, it might pay to try to smarten up the hash a
bit; nothing much is going to help a system with an order of magnitude
fewer buckets than entries, though.


		--Steve Bellovin
		smb@ulysses.att.com
		att!ulysses!smb

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 04:58:31 GMT
From:      buck@siswat.UUCP (A. Lester Buck)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   basic info about Network File System (NFS)

[I just turned on my feed for these two newsgroups, so I hope
this is the right place to ask about Network File Systems]

I need to learn about NFS but only know the small bits I
have picked up by reading various (other) newsgroups.
Could someone please recommend good technical publications
on NFS?  I am looking for a reasonably detailed discussion of
the concepts and capabilities, but light on implementation
specific details.  Any specific reference to Sun documentation
that I could order would be terrific.

Now a few specific questions:

Can NFS handle the idea of records in files, as on mainframes?
(I hear Intel has some implementation for this.  I guess VMS
must have handled it somehow, too.)
Is this done by putting some record layering code in the
file pipeline, or what?  References would be great.

Can NFS handle different character codes (i.e., ASCII to/from
EBCDIC) between machines?  Not the simple case of all text
or all binary, but say a database with binary fields and
character fields within a record.  Again, is there a hook
for a filter within the file data stream.  Or is there
no way to handle such things transparently?

What prompted these questions:

I am doing some contract driver work for a local company just
getting its feet wet in Unix (AIX).  They are a massive IBM
customer and want their new RT workstations to have access to
seismic data sets on the mainframes (MVS).  IBM is looking
for a testbed for their planned implementation of NFS on mainframes,
and they want to experiment on this company's
machines.  I told them I didn't know zip about NFS, but
they had me sit in on the meeting anyway and now I am interested
in learning more.

Thanks for any help,

-- 
A. Lester Buck		...!uhnix1!moray!siswat!buck

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 05:01:52 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, mws%beta@LANL.GOV
Subject:   Re: connection between ARP and ICMP...

I think it's very wierd to say "host unreachable" because you don't
have an ARP table entry.  In my view unreachable should mean that you
really can't get to the host, not that your internal cache needs
refreshing.  There's no question that it is a bug for hosts to break a
connection when they get an unreachable while a connection is open.
There may be a transient routing problem that will clear up shortly.
The recommended approach is to save the error message but keep
retrying.  If you end up timing out, then you print the error based on
the most recent unreachable.  Thus the unreachable does accomplish
something: it gives you some information about what is wrong, which is
useful in generating an intelligent error message.  But you sure don't
want to break the connection the first time you get an unreachable.
(Doing so is a common bug in TCP/IP implementations, however.)  I've
heard claims that when you are first setting up a connection, you
should pay attention to unreachables.  A user who is in the middle of
a connection likely has time invested in his context and is willing to
wait in hopes of continuing.  But when you're first trying a
connection, you don't, and it's silly to make people wait for a minute
to time out of a connection attempt when you know that there's no
route available to the destination.  That sounds sort of plausible to
me, but I think I might still wait for a timeout.  I my opinion, both
the gateway and the host are behaving suboptimally in your example.
I'm not sure they are flatly wrong, but I'd try to get them changed.
I think the host should ignore the unreachables, or use them only as a
basis for error messages.  And I think the gateway shouldn't issue
them for a missing ARP table entry.  (Indeed probably it shouldn't
issue them at all, because of the number of buggy host
implementations.)

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1989 10:22 EST
From:      tmac@sol.engin.umich.edu
To:        stewarta%sco.uucp@uunet.uu.net, tcp-ip@sri-nic.arpa
Subject:   Re:  tn3270
	From uunet.uu.net!stewarta%sco.uucp Thu Jan  5 16:00:19 1989
	From: stewarta%sco.uucp@uunet.uu.net
	Sender: tcp-ip-relay@sri-nic.arpa
	To: tcp-ip@sri-nic.arpa
	Date: 4 Jan 89 20:05:47 GMT
	Organization: The Santa Cruz Operation, Inc.
	Message-Id: <1243@viscous>
	Subject: tn3270
	
	 
	Does anyone know where I can get the sources to tn3270?
	 
	thanks,
	 
	stewarta@sco.COM      ...!uunet!sco!stewarta
	@ucscc.ucsc.edu:stewarta@sco.COM
	
I think you can anonymous ftp them from devvax.tn.cornell.edu

	Tom McLeary

--------------------------------------------
Thomas McLeary     tmac@caen.engin.umich.edu
Univ. of Michigan
Computer Aided Engineering Network

UUCP:  tmac%caen%mailrus.uucp
--------------------------------------------
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Jan 89 20:14:42 PST
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        tcp-ip@sri-nic.ARPA
Subject:   Commercialism
I thought there were some guidelines concerning "commercialism" in this forum.
Although this is negative, I find this crass commerialism inappropriate for
this forum.  To identify and advise this community of problems with a vendor's
product is one thing--to advertise that a product should or should not be
purchased is quite another.

> From tcp-ip-RELAY@SRI-NIC.ARPA Fri Jan  6 16:58:26 1989
>  .
>  .
>  .
> Date: 5 Jan 89 11:22:20 GMT
> From: sunkisd!sobeco!attcan!utgpu!watmath!julian!uwovax!brent@bloom-beacon.mit.edu  (Brent Sterner)
> Subject: FUSION TCP/IP s/w *NOT* reliable !!!
> Message-Id: <1202@uwovax.uwo.ca> 
> Sender: tcp-ip-relay@sri-nic.arpa
> To: tcp-ip@sri-nic.arpa
> 
> This is a simulated cross-post.  It was posted to comp.os.vms earlier this am.
> 
> SUMMARY: Do *NOT* purchase FUSION IP s/w for VMS 5.x and SMP at this time!
> =======     -----          ---------------------------------
> Details:
>  .
>  .
>  .
>    I will not go into the functionality problems which exist.  They are
> worthy of a separate posting anyway.  But the FUSION s/w has caused repeated
> SYSTEM CRASHES ever since it was installed.  I did not expect perfection the
> first time around, BUT I DID EXPECT SOME RESPONSIVENESS TO PROBLEM REPORTS.
> We have been continually trying to get in touch with technical people inside
> FUSION.  They *appear* to be stonewalling us.
>    We are beginning to look at alternatives.  If anyone is running IP for
> 5.x and SMP successfully, please let me know (email to me please).  We are
> very displeased with the *perceived* response FUSION has given to our problems.
>    In fact, it is interesting to note that perception is at least as important
> as fact.  Our sense of frustration would be much alleviated if FUSION would at
> least talk to us, whether or not they were actually making progress with our
> problems.  It is also interesting to note that DEC have been *VERY* cooperative
> in examining our crash dumps and suggesting ways to capture more information
> to assist FUSION.  DEC is to be commended here (London Ontario area).
>    I will follow up this posting as things develop.  Brent.

Why not bore us with the details and let us decide for ourselves whether or not
to purhase the product.  Does the product work without SMP (Symetric Multi
Processing) enabled?  Does the product attempt to use the SMP features or
is it only advertised to operate in an SMP environment?  Why is DEC unusually
responsive?

Merton Campbell Crockett

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 15:22:00 GMT
From:      tmac@SOL.ENGIN.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  tn3270


	From uunet.uu.net!stewarta%sco.uucp Thu Jan  5 16:00:19 1989
	From: stewarta%sco.uucp@uunet.uu.net
	Sender: tcp-ip-relay@sri-nic.arpa
	To: tcp-ip@sri-nic.arpa
	Date: 4 Jan 89 20:05:47 GMT
	Organization: The Santa Cruz Operation, Inc.
	Message-Id: <1243@viscous>
	Subject: tn3270
	
	 
	Does anyone know where I can get the sources to tn3270?
	 
	thanks,
	 
	stewarta@sco.COM      ...!uunet!sco!stewarta
	@ucscc.ucsc.edu:stewarta@sco.COM
	
I think you can anonymous ftp them from devvax.tn.cornell.edu

	Tom McLeary

--------------------------------------------
Thomas McLeary     tmac@caen.engin.umich.edu
Univ. of Michigan
Computer Aided Engineering Network

UUCP:  tmac%caen%mailrus.uucp
--------------------------------------------

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 15:48:19 GMT
From:      mo@prisma.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   Your router's behaviour

I would argue in the strongest possible terms that
is purely and simply broken.  UNREACHABLE messages
imply some kind of real failure or pathology (congestion),
not that someone simply hasn't gotten an ARP back.
I understand that they may not want to hang on to a packet
because of buffering, so they can simply drop it silently.
Telling someone the host is unreachable is simply not true
in your example.

	-Mike O'Dell

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 16:14:13 GMT
From:      brent@uwovax.uwo.ca (Brent Sterner)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   FUSION IP s/w reliability: "improving" ?


   This is a further posting about VMS 5.0 instability and FUSION ip s/w.
   In an earlier posting I wrote:
> SUMMARY: Do *NOT* purchase FUSION IP s/w for VMS 5.x and SMP at this time!
> =======     -----          ---------------------------------
	At this time FUSION has been logged into our system on several
	occasions.  I understand that a patch has been developed to fix
	the system crashes.  Whether we get it installed before the end
	of our working day remains to be seen.  (Our time zone is a 3 hour
	offset from their's.  This seems to have had some impact on FUSION's
	ability to talk to us.)  After this patch is installed we will be
	in a better position to judge their ability to address other apparent
	shortcomings in their s/w.
>    I will not go into the functionality problems which exist.  They are
> worthy of a separate posting anyway.
	I will post this list at a later date.  There seems to be some
	committment at this time from the technical people in FUSION to
	look into the list.  But solving the crashes obviously takes
	precedence.  Once FUSION comments on our list of their apparent
	shortcomings (which we may be able to work around), I will better
	be able to comment on their product.
>    In fact, it is interesting to note that perception is at least as important
> as fact.  Our sense of frustration would be much alleviated if FUSION would at
> least talk to us, whether or not they were actually making progress with our
> problems.  It is also interesting to note that DEC have been *VERY* cooperative
> in examining our crash dumps and suggesting ways to capture more information
> to assist FUSION.  DEC is to be commended here (London Ontario area).
	It is precisely this perception which has now changed.  FUSION's
	technical people are talking to our technical people.  I don't know
	as I write this that their patch will fix the crash problem.  But
	now I feel better about the situation!
>    I will follow up this posting as things develop.  Brent.
	You can count on that!  b.
--
Brent Sterner
Technical Support Manager, Academic Systems
Network    <BRENT@uwovax.uwo.ca>
Telephone  (519)661-2151 x6036
Last Gasp  Computing & Communications Services, Natural Sciences Building
           The University of Western Ontario, London, Ontario, Canada  N6A 5B7

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 16:51:17 GMT
From:      subbu@hpindda.HP.COM (MCV Subramaniam)
To:        comp.protocols.tcp-ip
Subject:   Re: connection between ARP and ICMP...

Mitchel,

I think ICMP unreachable message should not be generated if the gateway 
can find a route to the destination. If there is no routing entry by which
the gateway can access the destination, then the gateway should not ARP for
the destination at all, but just send the Unreachable message to the source.

Hope this helps.

-Subbu

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 17:16:26 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        news.misc,comp.protocols.tcp-ip
Subject:   VERY strange behavior at USENET/BITNET gateway


      The following message was returned to me by mail, in response to
a USENET posting to comp.society.futures.  Somehow, a strange form
of address translation was applied to the CONTENT of the message, resulting
in an attempt to interpret the 1988 election returns as Internet
addresses.

					John Nagle

   ====
From @cunyvm.cuny.edu:MAILER-DAEMON@wisdom.bitnet Thu Jan  5 20:35:12 1989
Received: from labrea.Stanford.EDU by glacier.stanford.edu with TCP; Thu, 5 Jan 89 20:35:02 PST
Received: from cunyvm.cuny.edu by labrea.stanford.edu with TCP; Thu, 5 Jan 89 20:34:56 PST
Message-Id: <8901060434.AA15336@labrea.stanford.edu>
Received: from wisdom.bitnet by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7800; Thu, 05 Jan 89 23:33:43 EST
From: Mail Delivery Subsystem <MAILER-DAEMON%WISDOM.BITNET@cunyvm.cuny.edu>
Date: 4 Jan 89 17:40:03 GMT
Subject: Returned mail: Unable to deliver mail
Received: from cunyvm.bitnet by wisdom.bitnet; Fri, 6 Jan 89 06:32:46 -0200
To: jbn%glacier@labrea.stanford.edu
Status: R

   ----- Transcript of session follows -----
554 "|/usr/new/fanews fa.futures futures-list"... Address too long: Bad file num
554 "|/usr/new/fanews fa.futures futures-list"... Address too long: Bad file num

   ----- Unsent message follows -----
Received: from cunyvm.bitnet by wisdom.bitnet; Fri, 6 Jan 89 06:32:46 -0200
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.01) with BSMTP id 4248; Thu,
 05 Jan 89 23:32:21 EST
Received: from multimax.encore.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with
 TCP; Thu, 05 Jan 89 23:32:03 EST
Received:  by multimax.encore.com (5.59/25-eef)
    id AA03285; Wed, 4 Jan 89 14:45:29 EST
Received: from UCBVAX.Berkeley.EDU by multimax.encore.com (5.59/25-eef)
    id AA03266; Wed, 4 Jan 89 14:45:08 EST
Received: by ucbvax.Berkeley.EDU (5.61/1.33)
    id AA25695; Wed, 4 Jan 89 11:15:08 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for info-futures-mail@encore.com (info-futures@encore.com)
    (contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 Jan 89 17:40:03 GMT
From: jbn%glacier@wisdom.bitnet  (John B. Nagle)
Organization: Stanford University
Subject: Election results (was re: voting system)
Message-Id: <17973@glacier.STANFORD.EDU>
References: <2604@ficc.uu.net>, <292@gloom.UUCP>
Sender: info-futures-request@wisdom.bitnet
To: info-futures@encore.com


 Here is the final national vote tally for the 1988 presidential
 election:

 Candidate            Party                             Votes     %
 ==================================================,
        ===================George.Bush.Republican.48@wisdom.bitnet,
        881@wisdom.bitnet,
        011.53.37.Michael.Dukakis.Democratic.41@wisdom.bitnet,
        828@wisdom.bitnet, 350.45.67.Ron.Paul.Libertarian.431@wisdom.bitnet,
        499.0.47.Lenora.Fulani.New.Alliance.218@wisdom.bitnet,
        159.0.24.David.Duke.Populist.48@wisdom.bitnet,
        267.0.05.Eugene.McCarthy.Consumer.30@wisdom.bitnet,
        510.0.03.James.Griffin.American.Independent.27@wisdom.bitnet,
        818.0.03.Lyndon.LaRouche.National.Economic.Recovery.25@wisdom.bitnet,
        082.0.03.William.Mara.Right.to.Life.20@wisdom.bitnet,
        497.0.02.Ed.Winn.Workers.League.18@wisdom.bitnet,
        579.0.02.James.Warren.Socialist.Workers.13@wisdom.bitnet,
        338.0.01.Herbert.Lewin.Peace.and.Freedom.10@wisdom.bitnet,
        312.0.01.Earl.Dodge.Prohibition.7@wisdom.bitnet,
        984.0.01.Larry.Holmes.Workers.World.7@wisdom.bitnet,
        719.0.01.Willa.Kenoyer.Socialist.3@wisdom.bitnet,
        800.0.00.Delmar.Dennis.American.3@wisdom.bitnet,
        456.0.00.Jack.Herer.Grassroots.1@wisdom.bitnet,
        949.0.00.Louie.Youngkite.Independent.372.0.00.John.Martin.Third.World.As
        934.0.01[Statistics.quoted.from.the.Associated.Press]@wisdom.bitnet

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 18:45:17 GMT
From:      hubcap!ncrcae!secola!mgreene@gatech.edu  (Mike Greene)
To:        tcp-ip@sri-nic.arpa
Subject:   Information about Network Solutions Corporation

Does anyone have any information about a company named "Network Solutions"?
I understand that they have (may have) TCP/IP conformance test suites. Any
info would be helpful e.g., address or phone number.

Thanx.

  
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 20:12:56 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: routing hash table sizes on 4.3bsd


Another thing I'd suggest to anyone thinking of redoing the routing lookup
routines is something I've put in my own code that seems to work pretty well.

Each time you find the entry you're looking for in a hash chain, move that
entry to the top of the list.  When a router sees a given address it is very
likely to see that same address again fairly soon, so this constitutes a
cheap form of caching that should reduce the average search length.

Depending on how expensive the hash function is, it might also be worthwhile
to put a very small direct-mapped cache on top of the whole lookup function.
This would help greatly when handling rapid bursts of data between the same
two points.

Phil

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 22:18:51 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: Your router's behaviour

I'm surprised that no one has made the obvious observation: this behavior is
completely broken for the simple reason that it is a gross violation of the
layering of the TCP/IP suite. ARP and IP are fundamentally independant - IP
can exist without ARP as can ARP without IP. This behavior adds cross-protocol
dependancies which do not belong there.

	Vince Fuller, Stanford Networking
-------

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 22:30:39 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        news.misc,comp.protocols.tcp-ip
Subject:   Re: VERY strange behavior at USENET/BITNET gateway

I've seen things like this happen if the blank line(s) between the
header and the body weren't truly blank but had spaces in it.

Something which happens (at least with UREP) is that files coming
in from BITNET-land have lines which are supposed to be truly
empty instead contain some number of blanks.  You would think this
would be non-destructive, but the header parser in the news software
gets confused and thinks that the first part of the body is actually
part of the header.

On a related note, sending out files with truly empty lines cause
those "records" to disappear.
-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- Now I know how Zonker felt when he graduated ...
<--          Stop!  Wait!  I didn't mean to!

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 89 23:24:40 GMT
From:      mailrus!wasatch!cs.utexas.edu!sm.unisys.com!csun!polyslo!steve@ames.arc.nasa.gov  (Steve DeJarnett)
To:        tcp-ip@sri-nic.arpa
Subject:   named question

	We're running bind/named 4.8, and we are serving as the primary 
nameserver for our campus.  The people in charge of our network (which gets
name service from us) claim that we are giving out bogus information for
addresses whose TTL has gone to 0.

	So, my question is:

Should named, when the TTL of an address mapping goes to 0, go back out and get
a confirmation of the address, or should it simply give the address as
non-authoritative (the network hardware is Ungermann-Bass)?

Currently, our Pyramid gives the non-authoritative response, and the UB software
gets upset and doesn't like that.  Anyone care to venture a guess as to who is
right here???

	Thanks in advance,

-------------------------------------------------------------------------------
| Steve DeJarnett            | Smart Mailers -> steve@polyslo.CalPoly.EDU     |
| Computer Systems Lab       | Dumb Mailers  -> ..!ucbvax!voder!polyslo!steve |
| Cal Poly State Univ.       |------------------------------------------------|
| San Luis Obispo, CA  93407 | BITNET = Because Idiots Type NETwork           |
-------------------------------------------------------------------------------
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 89 13:37:48 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  connection between ARP and ICMP...

A year or so ago on this list, someone suggested that "Host Unreachable"
should be returned when there was no response after some number of ARP
retries.  On a network where there's no direct indication that a packet
was received, this seems as good a method as any to detect dead hosts.
I don't believe it would be a layering violation, any more than translating
ARPAnet "Host Dead" status into "Host Unreachable" is -- it's just implementing
a well-defined network layer service.

On the other hand, to send "Host Unreachable" immediately just because there's
no ARP response in the cache is clearly broken.  It should make some attempt
to contact the host before saying this.

	Stuart Levy

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 89 15:34:08 GMT
From:      andrew@stl.stc.co.uk (Andrew Macpherson)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip,comp.bugs.4bsd
Subject:   Re: 'Talk' command and protocol (useable replacement)

In article <786@faui10.informatik.uni-erlangen.de> eckert@faui10.UUCP (Toerless Eckert) writes:
| I have previosly posted a request for a replacement for talk, but that
| was only to comp.sources.wanted. Maybe that was the wrong audience.
| Does someone on this lists knows if there is a suitable replacement for
| talk, that does not suffer from the above mentioned problems ?

Look out for "Phone" which has a nicer user interface, and gets round your
complaints.  let's see:

Ah yes, written by: J. Broome  UCB 1985.

I think I got it from the news network, but there must be somewhere nearer
you to get it.
-- 
Andrew Macpherson                          PSI%234237100122::andrew
andrew@stl.stc.co.uk        - or -         ...!mcvax!ukc!stl!andrew
"It is always a great mistake to treat the individual on the chance
that he may become a crowd" -- Mr Justice Codd: (A.P.Herbert)

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 89 16:42:57 GMT
From:      slf@well.UUCP (Sharon Lynne Fisher)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: basic info about Network File System (NFS)


There's a newsgroup for NFS called either comp.dcom.nfs or comp.protocols.nfs.
(Most likely the latter; I'm just too lazy to look it up.)  Geoff Arnold, the
Sun guy in charge of NFS, hangs out there.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 89 22:21:03 GMT
From:      IRWIN@pucc.Princeton.EDU (Irwin Tillman)
To:        comp.protocols.tcp-ip,news.misc
Subject:   Re: VERY strange behavior at USENET/BITNET gateway

In article <10836@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes:

>I've seen things like this happen if the blank line(s) between the
>header and the body weren't truly blank but had spaces in it.
>
>Something which happens (at least with UREP) is that files coming
>in from BITNET-land have lines which are supposed to be truly
>empty instead contain some number of blanks.  You would think this
>would be non-destructive, but the header parser in the news software
>gets confused and thinks that the first part of the body is actually
>part of the header.

Yup.  I've found that the following situation will exhibit the
problem.  (I've tried it with inews, version B 2.11, patchlevel 14.)

Feed inews an article in which the separator line contains whitespace
AND make sure that the body of the article begins with a line containing
only whitespace.  You'll find that the second line of the body will be
concatenated with the last header.

There are several ways that sites moving news from VM to UNIX can deal
with the problem.  I'm using a news batcher on the VM side written by
Thomas Habernoll;  it does the EBCDIC->ASCII conversion, and produces
truly blank lines.  Then I send the batch as a binary file.  Another way
is to change the whitespace lines to truly blank lines once they arrive
on the UNIX side.

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 89 00:45:36 GMT
From:      jim@aob.aob.mn.org (Jim Anderson)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for an Altos 2086

I have an Altos 2086 (currently running XENIX 3.4b with Worknet).  I
am looking at converting to running Ethernet, with TCP-IP, so I can
connect easier to a Sun network in-house.  Does anybody know if I can
get TCP-IP for the 2086 (Note this is not the Series 2000 style machine),
who from, and approximately how much this may cost?  I doubt I will
be able to get NFS support, but telnet/rlogin and ftp/rcp would be
sufficient.

Thanks,
	Jim
-- 
Jim Anderson			(612) 636-2869
Anderson O'Brien, Inc		New mail:jim@aob.mn.org
2575 N. Fairview Ave.		Old mail:{rutgers,gatech,amdahl}!bungia!aob!jim
St. Paul, MN  55113		"Fireball... Let me see... How did that go?"

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 89 15:55:26 GMT
From:      yee@ames.arc.nasa.gov (Peter E. Yee)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip,comp.bugs.4bsd
Subject:   Re: 'Talk' command and protocol (useable replacement)

In article <924@acer.stl.stc.co.uk> "Andrew Macpherson" <andrew@stl.stc.co.uk> writes:
>In article <786@faui10.informatik.uni-erlangen.de> eckert@faui10.UUCP (Toerless Eckert) writes:
>| ... Does someone on this lists knows if there is a suitable replacement for
>| talk, that does not suffer from the above mentioned problems ?
>
>Look out for "Phone" which has a nicer user interface, and gets round your
>complaints.  let's see:

I have the sources to phone (obtained from Jonathan back whenever).  If there
is enough interest, I could make them available for anonymous ftp or mail them
to some people (if the number of interested folks is few).   If it came out
in 1985, and was posted to the net, it's probably in an archive somewhere,
but I never can seem to find archives for mod and comp.sources.

							-Peter Yee
							yee@ames.arc.nasa.gov
							ames!yee

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 08:11:17 GMT
From:      reschly@BRL.MIL ("Robert J. Reschly Jr.")
To:        comp.protocols.tcp-ip
Subject:   Re: Network Monitor


      Harry,

   As with nearly every simple answer, the answer is "Well, it depends".
I am at home as I type this and my notes are at work, so what follows is
from memory.  I don't think there are any glaring deficiencies, though
I have become somewhat fuzzy about prices.

   Last spring two of my co-workers and I conducted and in-depth
evaluation of offerings from Cabletron, Network General, Excelan,
Hewlett Packard (those being the major players at the time) and looked
at a few other lesser known offerings.  The only current contender I
know about that we did not look at directly was the Spyder Systems (UK)
offering.  Also, since we looked last spring, Network General claims to
have significantly improved the underlying hardware capability with
their latest offering.

   We started out looking for a box which could do everything for us.
After sifting through the literature, talking with some of the engineers
designing various units, and playing with several of the boxes, our
judgement was that a box meeting all of our criteria did not exist.  The
units with the best software were unable to give us the hardware
performance we sought.  The units with satisfactory hardware capabilities
were sorely lacking in the software department.  Given that we were and
still are driven more by hardware considerations (i.e. Guarantee the box
can capture the bits, then worry about the protocol stack.  We can
decode a protocol stack if need be, but the best software in the world
will not necessarily do us any good if the hardware misses bits....) and
we already had some software in house for looking at protocol stacks
(our homebrew gateway software, and Van Jacobson's tcpdump for Sun 3's),
we settled on buying two of the Cabletron units.  Once we resigned
ourselves to buying a box strictly on hardware considerations, the
additional features of the HP unit (~2.5x the capture buffer, and disk
based configurations) were not enough to make up for the cost
difference.  All of us would have dearly loved to be able to recommend
the Network General box though....

   Cabletron, LAN Specialist:  Their "better" offering.  It's underlying
hardware is good enough to capture anything on the network, and is able
to drive the wire at greater than 90% saturation.  It also has some
rather nice cable/transceiver testing capabilities.  Has enough buffer
memory for ~260 Maximum Segment Size (MSS) sized packets in capture
everything mode.  It is severely lacking when dealing with anything
other than the link layer, needs a VT200 compatible terminal (requires
function keys out to F20, and uses scrolling and paging keys -- yeech!),
and has no nonvolatile storage (no saved configurations).  It is,
however, relatively cheap: ~$5,000.

   Hewlett Packard:  I forget the model number, but it is the "portable"
unit with the attached keyboard and ~7inch monochrome CRT.  Typical HP.
A solidly built, self-contained, closed box.  Also able to capture
anything on the wire, and able to drive the wire to greater than 90%
saturation.  Has enough buffer memory for ~650 MSS sized packets in
capture everything mode.  Has a floppy disk and an optional 10MB(?) hard
disk available.  The disks can be used to store configuration
information, and traffic dumps, though the box is not fast enough to use
the disk to extend buffer memory without risking missing some of the
bits.  Like much of HP's fancier equipment, suffers from "softkeys on
the brain".  Other than flipping a few bits in filters and entering
names, the keyboard might just as well not be present.  Also loses when
it comes to anything above the link layer.  Priced around $18,000.

   Excelan, LANalyzer:  This unit does not stand out in my mind.  It is
probably best summarized as the Sniffer's baby brother.  I don't recall
any of us noting any glaring deficiencies, just that it was not as
flexible, or as featureful as the Sniffer.  My only other recollection
was observing that the mount for the transceiver cable jack looked
rather flimsy.  The unit we played with was in a Toshiba 286 based
portable I think.  I believe this box comes in somewhere between $15,000
and $18,000.

   Network General, Sniffer:  Slick.  We all fell in love with the
amount of software support this box offered.  It could dump nearly
anything it captured all the way up the stack to the application level.
It was all menu based, but the menuing software was probably the easiest
to use and least obtrusive software of any we have run across.  We
seldom noticed it, per se, as we rummaged around with the system.  The
box we evaluated was a Compaq 286 system bundled up and sold as a
package by Network General.  Oh, if only the system was a bit heftier in
the hardware department.  We were overrunning it even on a relatively
lightly loaded network.  At least it was honest enough to let us know
when it was dropping packets (by beeping and keeping a tally) rather
than silently discarding them.  *sigh*  The other nice feature of the
Sniffer was that it could be configured for different networks.  It
could also do ARCnet and IBM 4Mb token ring I believe.  These features
were of no interest to us so we did not evaluate them.  This box ran
around $19,000 to $21,000 configured for Ethernet, I think.

   Last September at INTEROP'88 I saw a new version of the Sniffer being
demonstrated.  I have not had a chance to play with this box myself, nor
have I received the set of owners manuals I was promised, so everything
which follows is based on what the market droid I talked to said and my
fuzzy recollections of the spec sheets.  This version has been reworked
substantially, and offers several interesting features.  The new version
is built around a Compaq 386 box, and everything hangs off the back of
the Compaq as a plug-in module.  The Ethernet hardware has been beefed
up and can now support several (up to 6?) megabytes of capture buffer
memory in the add-on module.  With that much memory, even if they can
only capture 256 (they ought to get at least 512) packets per megabyte,
that is still more packets than even the HP can do.  Network General now
supports six(?) differing network technologies.  The add on module can
be configured in several ways.  It can be configured with any one or two
different network interface modules, or one interface module and a hard
disk.  The latter is particularly interesting in secure computing
environments because that means you can buy a floppy only Compaq with no
permanent storage, and N network modules with the permanent storage in
the module.  This way, configurations and such can be saved between
sessions, and can be locked up when not in use without also tying up the
computer.  If this box truly meets the claims made for it, it is the
hands down winner with no reservations whatsoever.  I only wish it had
been available six months sooner....  *MOBY sigh*  Price: around $11,000
for the Compaq (gosh, is the Compaq that much? -- seems a bit steep) and
$10,000 to $15,000 for the network modules.

   The only other real contender I know of is the Spyder Systems box.
I have overheard several people claiming it is a pretty good box, and
from what I have read of it, I suspect it's software is somewhere
between the LANalyzer and the old Sniffer.  I have no information about
it's hardware capabilities though, and don't know if it is a dedicated
or hosted implementation.  Not only that, but I don't know what it costs.
Probably worth a look before making any decisions.

   I hope you find this useful.

				Later,
				    Bob 
   --------
Phone:  (301)278-6678   AV: 298-6678    FTS: 939-6678
Arpa:   reschly@BRL.MIL (or BRL.ARPA)   UUCP: ...!brl-smoke!reschly
Postal: Robert J. Reschly Jr.
        U.S. Army Ballistic Research Laboratory
        Systems Engineering and Concepts Analysis Division
        Advanced Computer Systems Team
        ATTN: SLCBR-SE  (Reschly)
        APG, MD  21005-5066             (Hey, *I* don't make 'em up!)

****  For a good time, call: (303) 499-7111.   Seriously!  ****

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Mon,  9 Jan 89 17:57:13 -0500 (EST)
From:      Walter Lloyd Wimer III <ww0n+@andrew.cmu.edu>
To:        tcp-ip@sri-nic.arpa, pcip@louie.udel.edu
Subject:   Updated RFC1048 BOOTP server now available

Well, no surprise, bootpd 2.0 had a few bugs.  A new improved version,
bootpd 2.1, is now available for anonymous FTP from lancaster.andrew.cmu.edu
(128.2.13.21).  The new server can be found in pub/bootp.2.1.tar.

Bug fixes and improvements in version 2.1 include:

o  The definition of "access to the bootfile" has been changed to require the
   public read access bit to be set.  This is required by tftpd(8), so the
   server will not reply with a file which a client cannot obtain via TFTP.
o  The RFC1084 bootfile size tag has been implemented.  It allows either
   automatic or manual specification of the bootfile size in 512-octet blocks.
o  Generic tags now work as advertised.
o  A subtle bug which caused strange parsing behavior under certain conditions
   has been fixed.
o  The RFC1048 vendor information now has the correct byte order on
   little-endien machines such as the VAX.
o  Failure to specify the bootfile home directory and/or default bootfile in
   the configuration file no longer causes server crashes.  The server now
   makes a reasonably intelligent choice if this configuration information is
   missing.  This is documented in the man page.
o  BOOTP requests from clients which already know their IP addresses no longer
   cause server crashes.



Please direct questions, comments, and bug reports to
Walt Wimer <ww0n@andrew.cmu.edu> or Drew Perkins <ddp@andrew.cmu.edu>.



Good luck,

Walt Wimer
Network Development
Carnegie Mellon University
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 09:40:51 GMT
From:      whna@cgcha.uucp (Heinz Naef)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Standard (RFC) for IP-over-SNA

I'm wondering if there is an RFC for the IP-over-SNA connectivity feature of
both the existing IBM VM/SP TCP/IP Rel. 1.2 Program Product (5798-FAL) and the
future IBM MVS TCP/IP Product. I would expect a public domain specification
similar to RFC 877 ("Describes a standard for the transmission of IP Datagrams
over Public Data Networks"). 

The only vague information which can be obtained from the IBM literature is
that LU type 0 is used; but LU type 0 is defined to be application specific.
In the manuals there is no reference at all to related publications which
would describe implementation details of this particular encapsulation method.

To allow implementers of independent network hardware to include this 
connectivity option in their products, an Internet Request For Comments (RFC)
which describes the formats and protocols used for IP-over-SNA encapsulation
is required. 

Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.58, P.O.Box, CH-4002 Basel, Switzerland
  Internet: whna%cgch.uucp@uunet.uu.net   - Phone: (+41) 61 697 26 75
  BITNET:   whna%cgch.uucp@cernvax.bitnet - Fax:   (+41) 61 697 32 88
  UUCP:     cgch!whna

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 12:39:30 GMT
From:      DEDOUREK@UNB.CA
To:        comp.protocols.tcp-ip
Subject:   Re: Re: VERY strange behavior at USENET/BITNET gateway

> Something which happens (at least with UREP) is that files coming
> in from BITNET-land have lines which are supposed to be truly
> empty instead contain some number of blanks.  You would think this
Perhaps some of you would take a hand in convincing IBM that an
empty line should exist.  My system (MVS TSO on an IBM 3090 etc.)
refuses to store "zero length" records.  (Lines are of course
"records".)
 <empty line>
On another note, perhaps the standards should be more careful
to define things like "blank line".  My interpretation would be
"a line with zero or more blanks, but no other characters".

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 12:48:28 GMT
From:      goldstei@NSIPO.NASA.GOV (Steve Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercialism

Darn it,

I **like** this kind of crass reverse commercialism.  It's still one person's
opinion.  The guy was burned, and he is warning the rest of us.  The message:

"SUMMARY: Do *NOT* purchase FUSION IP s/w for VMS 5.x and SMP at this time!"

dosen't say flat-out not to buy the product, but quite responsibly advises not
to buy it "at this time". 

For my part, I'd welcome similar stories of poor vendor responsiveness and
products whose performance does not meet the vendor's hype.  I can still
decide whether or not to follow the advice.

Re:"To identify and advise this community of problems with a vendor's
product is one thing--to advertise that a product should or should not be
purchased is quite another."

Steve Goldstein

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 13:57:59 GMT
From:      brent@uwovax.uwo.ca (Brent Sterner)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: FUSION IP s/w patch FIXES RELIABILITY PROBLEM !!!!!!!

In article <1201@uwovax.uwo.ca>, brent@uwovax.uwo.ca (Brent Sterner) writes:
  ... welllll, I won't go into all that again.  Suffice to say that
a) we *finally* got in touch with a technical person,
b) that technical person exhibited *none* of the traits which caused the
   original flame (which, in my experience, has always been true of technical
   people; they are without exception always ready to help :-) :-) :-) :-),
c) we got the patch last Friday, installed it, and reloaded, annndddd finally

D) 	THE SYSTEM HAS BEEN RUNNING JUST FINE EVER SINCE !!!!!

   Now, I'm not quite sure exactly what *was* going on down there.  (We're
'way up here in the great white north.)  Perhaps the front line telephone
filters were a bit too efficient.  Whatever, it doesn't matter now.  The system
is stable, and we can get on with investigating functionality problems.

   My thanks to all who mailed sympathy cards and who suggested alternative
s/w.  Having started the process of looking at other solutions, we will likely 
follow this through.

   Finally, THANKYOU to Jeffrey Busma who got us out of this one with intact
skin.  Brent.

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 18:32:37 GMT
From:      bin@primate.wisc.edu (Brain in Neutral)
To:        comp.protocols.tcp-ip
Subject:   Re:  tn3270

> 	Does anyone know where I can get the sources to tn3270?
> 	
> I think you can anonymous ftp them from devvax.tn.cornell.edu

Or ucbarpa.berkeley.edu, in pub/tn3270.tar.Z.

If you want to make it run under Ultrix, you need to do some tweaking.

Paul DuBois
dubois@primate.wisc.edu
bin@primate.wisc.edu

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 18:32:48 GMT
From:      kincl%hp-iag@HP-SDE.SDE.HP.COM (Norman Kincl)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Monitor


> Last spring two of my co-workers and I conducted and in-depth
> evaluation of offerings from Cabletron, Network General, Excelan,
> Hewlett Packard ...

Lots can happen in that time.

> Hewlett Packard:  I forget the model number, 

The model number is HP 4972A.

>                           Has a floppy disk and an optional 10MB(?) hard
> disk available.

A 20MB hard disk is standard.  Up to two additional hard disks (10, 20
or 40MB) can be added.

>                                                         Also loses when
> it comes to anything above the link layer.

We have a TCP/IP protocol interpreter that runs on the HP 4972A ( part
number HP 18221A).  It decodes the level 3 and 4 protocols of TCP,
DUP, IP, ICMP, ARP and RARP.

Other features include the use of an IP address list that allows users
to define names to be used in the display of information.  Addresses
that do not have a user-defined name are displayed in dotted-decimal
notation.  The interpreter will also flag checksum errors and illegal
frame lengths.

Also included are utilities that allow users to capture conversations,
trigger on events for further analysis (capture ICMP messages of
specific type, capture one conversation start to finish, capture
trivial window problems, and so on).

You can do things like display the login time, time to first data
transfer, number of frames that carry only one byte of data, number of
frames with more than one byte of data, number of acknowledgements and
total connect time.


-Norm Kincl
 Information Archirtecture Group, Hewlett-Packard

(I don't make or sell these things---call your local sales office if
you want real details.)

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 20:45:05 GMT
From:      wisner@killer.DALLAS.TX.US (Bill Wisner)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip,comp.bugs.4bsd
Subject:   Re: 'Talk' command and protocol (useable replacement)

The sources to phone are already available for anonymous FTP. I put them
up on EDDIE.MIT.EDU earlier this year. I think they're /pub/phone.tar.Z
or something similar.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 22:20:35 GMT
From:      gc@ewok.amd.bnl.gov (Graham Campbell)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: VERY strange behavior at USENET/BITNET gateway


	Status: RO
	
	On another note, perhaps the standards should be more careful
	to define things like "blank line".  My interpretation would be
	"a line with zero or more blanks, but no other characters".
	
Quoting from RFC822, page 5

	It is separated from the headers by a null line (i.e., a line
	with nothing preceding the CRLF)
	
You may argue that such a definition was not well enough thought out
since it does not acknowlege the MVS problem with null lines, but it 
seems like a pretty clear definition to me.

Graham

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 22:46:57 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Monitor

In article <8901091832.AA05477@hp-iag.HP.COM>,
	kincl%hp-iag@HP-SDE.SDE.HP.COM (Norman Kincl) writes:
> 
> [nice features of HP network monitors...]
>
> -Norm Kincl
>  Information Archirtecture Group, Hewlett-Packard

Some of the "dedicated" network monitors are indeed quite nice.

However, for utility and fexibility, it is hard to beat a "native"
monitor which runs on a significant number of the hosts in your
network.  Imagine how handy it is to reach out across a few gateways to
a workstation on the troubled network, and tell that workstation to
snoop on the wire.  Think how it is to watch for damaged packets at
many places along a cable, without having to crawl into ceilings or
floors, or to make any cabling changes.  Think about not having to lug
a fragile box all over creation.  (I assume boxes built to HP standards
are not really fragile, but things that cost lots tend to seem
fragile.)  Since such a monitor is "just" software, one can hope
to get a good deal if you need more than a single monitor.

Such native monitors are available for at least one company's UNIX
workstations.  They are not quite as fast as some (but not all)
dedicated monitors, but they are more programmable by users.  (You just
start hacking in C.)  Monitors for PC's might be useful, if the PC runs
a real operating system, so that you can rsh/rlogin/telnet/sethost/...
to the PC and then run the monitor.  (Or have a remote monitoring
deamon.)

Vendors of workstations tend to like native monitors.  We can tell
customers with problems to "do such and such and send me the results."
This is handy for finger pointing :-) and as well as for finding bugs.

Might one expect a network management system to include network
monitors for all of the levels?

Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 89 22:51:53 GMT
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercialism

In article <8901091248.AA00853@nsipo.arc.nasa.gov> goldstei@NSIPO.NASA.GOV (Steve Goldstein) writes:
>For my part, I'd welcome similar stories of poor vendor responsiveness and
>products whose performance does not meet the vendor's hype.  I can still
>decide whether or not to follow the advice.

I think that the tcp-ip mailing list (and newsgroup) is a fine place
for exchanging information about vendor products, regardless of
whether the experiences related are positive or negative. In my
opinion, sharing information is a good thing and should continue to
happen.

HOWEVER...I've seen several instances of cases where someone basically
tries to hold a vendor hostage by complaining in a public forum about
features they want to see added, or about bugs which they've never
bothered to ask or inform the vendor about. I think that this sort of
behaviour is as bad or worse than some of the blatant or not-so
blatant commercial messages various vendors post, too.

The line between an advertisement and an informational message from a
vendor is a thin one. So is the line between an unjust damaging
message and an informational message from a user.
-- 
			- john romkey
romkey@asylum.uucp	romkey@xx.lcs.mit.edu	romkey@asylum.sf.ca.us

"Maybe Acid would help."

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 09:01:36 GMT
From:      rm@SPIDER.CO.UK (Richard McBride)
To:        comp.protocols.tcp-ip
Subject:   RE Network Monitors

>I am looking for a network monitor to analyze the load on the network.
>What equipment do some of you use for this purpose.
 
>           Harry J. Foxwell
>           American Chemical Society

As well as the Sniffer and the LANalyser another network monitor to consider
is the SpiderMonitor. This differs from the other monitors on the market
because it uses an intelligent network board with its own processor
rather than a dumb board. The board has its own multitasking executive which
allows it to gather station statistics at the same time as monitoring network
load. The load can be displayed graphically over a specified time period.
The monitor can also capture and decode packets and traffic generate while
this network monitoring is going on.

Having an intelligent board means that the statistics are gathered
continuously even when the PC which the board is plugged into is running
another DOS program. Multitasking also means that the monitor is not dedicated
to measuring things like the network load in exclusion to capturing data
about other aspects of the network. It is far more useful to be able to look
at network load and a table of station traffic than just network load.

The machine has been designed to be good at collecting statistical information
about the network as well as capturing and decoding packets. Decoding seems
to be the area which other network monitor manufacturers like Data General
have concentrated on.

They tend to be weaker on collecting tables of statistics about traffic sent by
machines on the LAN.

Hope you find this useful
                          Richard.

Richard McBride   rm@spider.co.uk    ...!uunet!ukc!spider!rm
Spider Systems                          Spider Systems Inc
Edinburgh                               12 New England Executive Park
UK                                      Burlington  MA 01803
031 554 9424                            (617) 270 3510

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 10:04:55 GMT
From:      hanst@htsa.uucp (Hans Trompert)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip,comp.bugs.4bsd
Subject:   Re: 'Talk' command and protocol (useable replacement)

In article <20431@ames.arc.nasa.gov> yee@ames.arc.nasa.gov.UUCP (Peter E. Yee) writes:
>I have the sources to phone (obtained from Jonathan back whenever).  If there
>is enough interest, I could make them available for anonymous ftp or mail them
>to some people (if the number of interested folks is few).   If it came out
>in 1985, and was posted to the net, it's probably in an archive somewhere,
>but I never can seem to find archives for mod and comp.sources.

We sure are interested, and I think many others are interested as well.
But we have no access to anonymous ftp, so why dont you post it on the net
if many people are interested.

-- 
                       Hans Trompert
                       Algemene Hogeschool Amsterdam
                       Technische en Maritieme Faculteit
                       hanst@htsa.uucp.nl

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Jan 89 20:18:54 PST
From:      hjs@lindy.Stanford.EDU
To:        rm%SPIDER.CO.UK@CUNYVM.CUNY.EDU (Richard McBride)
Cc:        tcp-ip@SRI-NIC.ARPA, hjs@lindy.Stanford.EDU
Subject:   Re: RE Network Monitors
Your statement that the SpiderMonitor uses an intelligent board w.
microprocessor whereas "the others" (LANalyzer and Sniffer) use
"dumb boards" is totally false. All three products use boards that
have something at least as powerful as an 80186, 10 Mhz, and 512KB of
RAM. The top-of-the-line LANalyzer has even more horsepower on-board.

Please try and be more careful about making statements about the products
of competitors in a public forum. Here you will get caught. Unfortunately
spreading wrong competitive information directly rarely is! Welcome to
the U.S.A. Spider!
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 13:14:51 GMT
From:      jsdy@hadron.UUCP (Joseph S. D. Yao)
To:        comp.protocols.tcp-ip
Subject:   Uniq <=> Ultrix

I'm hoping that this will sound familiar to someone, who will then
send me mail (since I don't get this far in my .newsrc often).

A problem was reported to and observed by me, in sending certain mail
messages from VAXen running Ultrix 2.2 to a VAX running System V
Release 2 Version 2 (modified by me) with Uniq's Passage software
(again modified by me in places, to make it work at all).  After a
number of observations, it became obvious that only "large" (not yet
quantified) messages were failing, and the SMTP program on the Uniq
side was getting an error message, "URESET - network connection
aborted and reset".  Similarly large messages worked fine among Ultrix
2.2 machines.

The Ultrix 2.2 machines are running a - possibly early - version of
BSD 4.3 network code, while the Uniq code appears to be slightly
modified BSD 4.1.

Instrumentation of the Uniq side shows that the TCP level is receiving
several packets perfectly reasonably, then all of a sudden getting a
packet whose sequence number is 1024 more than expected!  At this
point, of course, it stops and waits for the next one ... which never
arrives.  This 1024 over is not a bit set - it is whatever-odd-number
plus 1024 (i.e., there is bit carry and so forth).  Since attempts to
re-receive the "proper" packet fail, it then times out and resets the
connection.

Any takers?  Mucho obligato if so.  Thanks to all...

	Joe Yao		jsdy@hadron.COM (not yet domainised ???)
	hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM}
	arinc,att,avatar,blkcat,cos,decuac,dtix,\
	ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy
	kcwc,lepton,netex,netxcom,phw5,rlgvax,	 /
	seismo,sms,smsdpg,sundc,uunet		/

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 13:26:37 GMT
From:      rogers@ofc.Columbia.NCR.COM (H. L. Rogers)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercialism

In article <8901091248.AA00853@nsipo.arc.nasa.gov> goldstei@NSIPO.NASA.GOV (Steve Goldstein) writes:
>Darn it,
>
>I **like** this kind of crass reverse commercialism.  It's still one person's
>opinion.  The guy was burned, and he is warning the rest of us.  The message:
>
>"SUMMARY: Do *NOT* purchase [*********] s/w for VMS 5.x and SMP at this time!"
>

The really sad thing about this situation is that it exists at all.
I mean, the fact that any company will produce a poor quality product
and then make it worse by not responding to calls for support is 
inexcusable.  This represents a complete lack of professional ethics.

My own experience with this particular company (you will note that 
I have asterick'ed the brand name above...sorry, I *do* have _some_ 
ethics :-)) was also bad.  No...bad is the wrong word.  I finally 
threw their salesman out the door and told him never to come back
(really...I actually escorted him to the door!).  We acquired the 
source and fixed it ourselves...had to change about 95-98% of the 
code, by our estimates.  I believe some of the original includes 
were okay!

For their sake, I hope some of this "reverse comercialism" wakes them
up.  I try to put the shoe on the other foot and imagine what I would
do after reading these reports of poor product quality.  I would be
totally embarrassed and proceed to do everything I could to correct
the situation.  On the other hand, I was associated with this
particular company for three years before I finally gave up.  I
doubt they will get the message.

Well, this type of posting requires a special disclaimer:  My
opinions are my own and in no way represent those of my employer.
Any actions I have taken in the past with regard to supplier
relations is not necessarily supported by my employer.
-- 
HL Rogers    (hl.rogers@ncrcae.Columbia.NCR.COM)

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 14:33:09 GMT
From:      ece-csc!ncrcae!secola!mgreene@ncsuvx.ncsu.edu  (Mike Greene)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP-IP protocol conformance test suites
Could anyone provide information about TCP/IP protocol test suites and/or NVLAP test labs. I believe UNISYS (or DCA) provides some public domain software suiteson Ultrix. I am actually looking to run this on NCR's Unix systems.

Also, any information on a billable TCP/IP conformance testing service would be appreciated. Thanx.  
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 14:40:14 GMT
From:      gc@EWOK.AMD.BNL.GOV (Graham Campbell)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: VERY strange behavior at USENET/BITNET gateway


	Status: RO
	
	On another note, perhaps the standards should be more careful
	to define things like "blank line".  My interpretation would be
	"a line with zero or more blanks, but no other characters".
	
Quoting from RFC822, page 5

	It is separated from the headers by a null line (i.e., a line
	with nothing preceding the CRLF)
	
You may argue that such a definition was not well enough thought out
since it does not acknowlege the MVS problem with null lines, but it 
seems like a pretty clear definition to me.

Graham


----- End Forwarded Message -----

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89   20:33 EST
From:      MARSHALL%JHUHYG.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP @ SRI-NIC.ARPA
Subject:   BITNET mail follows
OPTIONS: ACK    LOG    LONG     NOTEBOOK *




Date: 10 January 89, 20:00:42 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
To:   TN3270-L IBM 3270 Emulation Discussion      TN3270   at TERMINUS.UMD.EDU

Date: 10 January 89, 20:00:42 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   TN3270-L IBM 3270 Emulation Discussion List TN3270   at TERMINUS.UMD.EDU
      IBM PC Networking Discussion List           IBM-NETS at UGA
      ARPA TCP-IP Discussion List                 TCP-IP   at SRI-NIC.ARPA
      PC-IP Arpa Discussion List                  PCIP     at UDEL.EDU
      IBM TCP/IP for VM Discussion List           IBMTCP-L at CUNYVM

Re: 3com PCS/TCP-NS and TN3270

Sorry for the multiple posting.

We are begining to use PCS/TCP, a package designed for a 3Com network, and
wanting to use TN3270.  Line mode on an IBM VM/CMS system is fun, but...

Has anyone *actually* combined any of the various TN3270 packages and
this telnet?  Perhaps more properly stated, has someone used a TN3270
and the driver and etc. from this package.

It does not have a TN3270 of it's own.

If so, I'd like to know and if wanted I'll post any results.

                                                       -Marshall

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
Date: 10 January 89, 20:00:42 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   TN3270-L IBM 3270 Emulation Discussion List TN3270   at TERMINUS.UMD.EDU
      IBM PC Networking Discussion List           IBM-NETS at UGA
      ARPA TCP-IP Discussion List                 TCP-IP   at SRI-NIC.ARPA
      PC-IP Arpa Discussion List                  PCIP     at UDEL.EDU
      IBM TCP/IP for VM Discussion List           IBMTCP-L at CUNYVM

Re: 3com PCS/TCP-NS and TN3270

Sorry for the multiple posting.

We are begining to use PCS/TCP, a package designed for a 3Com network, and
wanting to use TN3270.  Line mode on an IBM VM/CMS system is fun, but...

Has anyone *actually* combined any of the various TN3270 packages and
this telnet?  Perhaps more properly stated, has someone used a TN3270
and the driver and etc. from this package.

It does not have a TN3270 of it's own.

If so, I'd like to know and if wanted I'll post any results.

                                                       -Marshall

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 18:24:30 GMT
From:      rogers@ofc.Columbia.NCR.COM (H. L. Rogers)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: FUSION IP s/w reliability: "improving" ?

In article <1212@uwovax.uwo.ca> brent@uwovax.uwo.ca (Brent Sterner) writes:
>
>							       I don't know
>	as I write this that their patch will fix the crash problem.

I predict the patch will fix the crash problem.  I also predict it will
break something else.
-- 
HL Rogers    (hl.rogers@ncrcae.Columbia.NCR.COM)

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 19:41:59 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: FUSION IP s/w reliability: "improving" ?


       This is reminiscent of the troubles that I had with FUSION software
about five years ago, when they offered an IP/TCP for the IBM PC.  They
were satisfied with a product that worked across an Ethernet connected
to a Berkeley UNIX system; the notion that their product should work in
a broad Internet environment was completely foreign to them at the time.

       One hopes by now that their horizons have broadened.

					John Nagle

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 20:51:46 GMT
From:      murayama@CS.UCL.AC.UK (Yuko Murayama, +44-1-387-7050 ext.3695)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Monitor


Just from curiosity, can any of those monitors have its own
IP address and send out a packet ( a probe or some kind)
to the net?    Or are they listen-only?

Yuko

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Jan 89 20:51:46 +0000
From:      Yuko Murayama (+44-1-387-7050 ext.3695) <murayama@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Network Monitor

Just from curiosity, can any of those monitors have its own
IP address and send out a packet ( a probe or some kind)
to the net?    Or are they listen-only?

Yuko
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 21:18:39 GMT
From:      hunaid@opus.cray.com (Hunaid Engineer)
To:        comp.protocols.tcp-ip
Subject:   Public domain SNMP???


Is there a public domain version of the SNMP agent available?

 - Hunaid

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 22:32:23 GMT
From:      JDB@BUSTER.NRC.COM (Jeffrey D. Busma)
To:        comp.protocols.tcp-ip
Subject:   RE:FUSION and SMP


> > 
> > "SUMMARY: Do *NOT* purchase FUSION IP s/w for VMS 5.x and SMP at this time!"
> > 


	A timing bug was found in relation to VMS 5.x and SMP at the University
	of Western Ontario. Apparently the 3 CPUs of the 6230 provided
	just the right sequence of events for this to show up.

	The following PATCH is (strongly) recommended for any SMP or 
	ASMP VAXes currently running FUSION 3.3


	$ set default fns_base:[bin]
	$ link/map/full/noexe fustart.stb 	! Ignore warning message
	$ edit fustart.map
		search for 'os_fwq_rem' and write down hex location
		(Assume for this *example* the location is C12345)

	$ patch fustart.exe
	$ define os_fwq_rem=C12345	! Remember C12345 is ONLY AN EXAMPLE
	$ deposit/instruction os_fwq_rem+29
	'bicl2 #7,R0'
	'rsb'
	exit
	update
	



------

------------------------------------------------------------------------------
Jeffrey D. Busma					Network Research Corp.
jdb@nrc.com                                             1620 Federal Ave. #2
jdb@nrcvax.UUCP                                         LA, CA, 90025,  USA
jdb@buster.nrc.com 					

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 89 22:58:28 GMT
From:      ingr!b11!sale@uunet.uu.net  (Ed Sale)
To:        tcp-ip@sri-nic.arpa
Subject:   Questions about 4.3BSD bind() on a multiple ethernet system.
I have been reading through the 4.3BSD manuals and cannot determine how the
bind() system call works on AF_INET sockets when more than one ethernet (and
hence more than one internet address, I think) exists on a system.  If I am
programming a server which listens on port "X" for incoming requests and needs
to listen on both nets, do I have to open two sockets and bind port "X" on each
socket with internet address "A" in the sockaddr_in structure of one and
internet address "B" in the other; or can I just open one socket and bind it
to port "X" with the internet address in the sockaddr_in structure set to
INADDR_ANY?  If I bind a socket with the internet address of INADDR_ANY, which
internet address is returned?  Which internet address is placed in the source
address part of the IP header/trailer sent on that socket?  How does the
kernel determine which one I get?  Does the kernel keep separate UDP and TCP
port tables for each internet address?  There are no answers to these questions
that I can find in the manuals that I have.

I would have tried to experiment some, but I don't have access to a two
ethernet machine, yet.  The reason that I am asking is that I will be
implementing a version of TCP/IP that must run on systems with more than
one local network attached that must support 4.3BSD IPC system calls as well.

Thanks in advance.
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 00:21:04 GMT
From:      root@lilink.UUCP (The Super User)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP for an Altos 2086

In article <180@aob.aob.mn.org> jim@aob.aob.mn.org (Jim Anderson) writes:
>I have an Altos 2086 (currently running XENIX 3.4b with Worknet).  I
>am looking at converting to running Ethernet, with TCP-IP, so I can

As far as I know Altos itself does not support TCP-IP on ANY of its machines.
Ditto for RFS. This includes 386/2000's of which we have 1. I have contacted
Altos on this and I have been getting "real soon now...." for the last several
months. However that is only for the 386/2000 box. If you have a
286 based box I think you are out in the cold (as I am). 

Third party vendors may have  addressed this problem already but I have
found none. If anyone knows of such an implimentation for ANY Altos machine
I for one would like to hear from them.



-- 
Michael R. Johnston
System Administrator   {..!philabs!mergvax! | ..!uunet!ispi!} lilink!mikej
LILINK - Public Access Xenix   (516) 872-2137  1200/2400 8N1  Login: new

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 01:33:00 GMT
From:      MARSHALL@JHUHYG.BITNET
To:        comp.protocols.tcp-ip
Subject:   BITNET mail follows

OPTIONS: ACK    LOG    LONG     NOTEBOOK *




Date: 10 January 89, 20:00:42 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
To:   TN3270-L IBM 3270 Emulation Discussion      TN3270   at TERMINUS.UMD.EDU

Date: 10 January 89, 20:00:42 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   TN3270-L IBM 3270 Emulation Discussion List TN3270   at TERMINUS.UMD.EDU
      IBM PC Networking Discussion List           IBM-NETS at UGA
      ARPA TCP-IP Discussion List                 TCP-IP   at SRI-NIC.ARPA
      PC-IP Arpa Discussion List                  PCIP     at UDEL.EDU
      IBM TCP/IP for VM Discussion List           IBMTCP-L at CUNYVM

Re: 3com PCS/TCP-NS and TN3270

Sorry for the multiple posting.

We are begining to use PCS/TCP, a package designed for a 3Com network, and
wanting to use TN3270.  Line mode on an IBM VM/CMS system is fun, but...

Has anyone *actually* combined any of the various TN3270 packages and
this telnet?  Perhaps more properly stated, has someone used a TN3270
and the driver and etc. from this package.

It does not have a TN3270 of it's own.

If so, I'd like to know and if wanted I'll post any results.

                                                       -Marshall

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
Date: 10 January 89, 20:00:42 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   TN3270-L IBM 3270 Emulation Discussion List TN3270   at TERMINUS.UMD.EDU
      IBM PC Networking Discussion List           IBM-NETS at UGA
      ARPA TCP-IP Discussion List                 TCP-IP   at SRI-NIC.ARPA
      PC-IP Arpa Discussion List                  PCIP     at UDEL.EDU
      IBM TCP/IP for VM Discussion List           IBMTCP-L at CUNYVM

Re: 3com PCS/TCP-NS and TN3270

Sorry for the multiple posting.

We are begining to use PCS/TCP, a package designed for a 3Com network, and
wanting to use TN3270.  Line mode on an IBM VM/CMS system is fun, but...

Has anyone *actually* combined any of the various TN3270 packages and
this telnet?  Perhaps more properly stated, has someone used a TN3270
and the driver and etc. from this package.

It does not have a TN3270 of it's own.

If so, I'd like to know and if wanted I'll post any results.

                                                       -Marshall

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Jan 89 07:52:43 EST
From:      Frank Kastenholz <KASTEN%MITVMA.MIT.EDU@MITVMA.MIT.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Re: Commercialism
Speaking as an ex-vendor (I used to be development manager for KNET/VM
from Spartacus/Fibronics) this type of "feedback" is good - IF the vendor
gets it ((judging by the mail, they may have got the feedback but it may
not have sunk in (or they are bad at double talk while they attempt to
fix bugs:-).

Anyway, there were many mane many problems with KNET when I took it over
and the feedback we got through some of the people on the net was very useful
in A) tracking and fixing problems, B) determining which problems were
most important and C) convincing higher management that we really did have
a problem and there weren't just "one or two small problems" (The "KNET is a
pile of festering horse ....." types of messages were the most helpful here).

I was glad for the feedback. I would think that any vendor would be, IF
they truly were interested in serving the needs of their customers. And if
not, well Adam Smith and Charles Darwin would probably ensure their early
demise.

Frank Kastenholz
Ex KNET Slave

P.S. I know that there are still one or two functional deficiencies in KNET :-)
but I have been gone for over a year. I wanted to fix them. I even started
doing some of it. I left Fibronicus. I wonder if there is any correlation
there? Hmmmmmmmmmmm
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 04:18:54 GMT
From:      hjs@LINDY.STANFORD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: RE Network Monitors

Your statement that the SpiderMonitor uses an intelligent board w.
microprocessor whereas "the others" (LANalyzer and Sniffer) use
"dumb boards" is totally false. All three products use boards that
have something at least as powerful as an 80186, 10 Mhz, and 512KB of
RAM. The top-of-the-line LANalyzer has even more horsepower on-board.

Please try and be more careful about making statements about the products
of competitors in a public forum. Here you will get caught. Unfortunately
spreading wrong competitive information directly rarely is! Welcome to
the U.S.A. Spider!

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 05:04:28 GMT
From:      mike@BRL.MIL (Mike Muuss)
To:        comp.protocols.tcp-ip
Subject:   Re:  Uniq <=> Ultrix

Two suggestions:

1)  check for trailers handling.  (use "ifconfig xx0 -trailers")

2)  check the offered TCP MSS -vs- what is getting sent.

A Sun running "TCPDUMP", or an ethernet analyzer, will be helpful.
	Best,
	 -Mike

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 08:04:04 GMT
From:      jsdy@hadron.UUCP (Joseph S. D. Yao)
To:        comp.protocols.tcp-ip
Subject:   Re: Uniq <=> Ultrix

In article <828@hadron.UUCP> I (Joseph S. D. Yao) write:
>...
>Instrumentation of the Uniq side shows that the TCP level is receiving
>several packets perfectly reasonably, then all of a sudden getting a
>packet whose sequence number is 1024 more than expected!  ...

Many thanks to the several people who immediately suggested an answer
that seems to exactly fit the problem:
	Ed Frankenberry <ezf@BBN.COM>
	Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
	cpw%sneezy@LANL.GOV (C. Philip Wood)
	map@gaak.LCS.MIT.EDU (Michael A. Patton)
	"Mark D. Eggers (219) 239-7258" <CF4A8X%IRISHMVS.BITNET@UICVM.UIC.EDU>
	Mike Muuss <mike@BRL.MIL>

Apparently, as I'd suspected, Ultrix 2.2 TCP/IP is 4.3BSD-alpha.  It
offers "trailers" by default.  If a large packet is sent, 1024 bytes
are sent in a "trailer", which the Uniq (4.1BSD) TCP or IP (I think
the latter) doesn't recognize ... hence my symptom of suddenly finding
sequence numbers boosted by 1024.  The universally proffered solution
was to put "-trailers" as an argument to 'ifconfig' in the system
initialisation file "/etc/rc.local".  It was suggested that the Ultrix
implementation of trailers, being 4.3-alpha, might be incomplete; or
that Uniq TCP/IP, being older, probably doesn't understand trailers.

This is not surprising.  I'd already changed the net broadcast address
to all-zeroes, since the Uniq implementation of all-ones is incomplete.

I'll try this tomorrow.  If you don't hear from me again on this, this
is the final answer.

Mike Muuss, as always, thinks up more possibilities.  I don't under-
stand his second suggestion, so I'll include it verbatim and let him
elucidate, if he wants.

> 2)  check the offered TCP MSS -vs- what is getting sent.

He also adds:

> A Sun running "TCPDUMP", or an ethernet analyzer, will be helpful.

	Joe Yao		jsdy@hadron.COM (not yet domainised)
	hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM}
	arinc,att,avatar,blkcat,cos,decuac,dtix,\
	ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy
	kcwc,lepton,netex,netxcom,phw5,rlgvax,	 /
	seismo,sms,smsdpg,sundc,uunet		/

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 12:52:43 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercialism

Speaking as an ex-vendor (I used to be development manager for KNET/VM
from Spartacus/Fibronics) this type of "feedback" is good - IF the vendor
gets it ((judging by the mail, they may have got the feedback but it may
not have sunk in (or they are bad at double talk while they attempt to
fix bugs:-).

Anyway, there were many mane many problems with KNET when I took it over
and the feedback we got through some of the people on the net was very useful
in A) tracking and fixing problems, B) determining which problems were
most important and C) convincing higher management that we really did have
a problem and there weren't just "one or two small problems" (The "KNET is a
pile of festering horse ....." types of messages were the most helpful here).

I was glad for the feedback. I would think that any vendor would be, IF
they truly were interested in serving the needs of their customers. And if
not, well Adam Smith and Charles Darwin would probably ensure their early
demise.

Frank Kastenholz
Ex KNET Slave

P.S. I know that there are still one or two functional deficiencies in KNET :-)
but I have been gone for over a year. I wanted to fix them. I even started
doing some of it. I left Fibronicus. I wonder if there is any correlation
there? Hmmmmmmmmmmm

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Jan 89 21:26:23 -0500
From:      Mike Brescia <brescia@BBN.COM>
To:        "John G. Ata" <Ata@radc-multics.arpa>
Cc:        tcp-ip@sri-nic.arpa, gw-fire@BBN.COM
Subject:   Re: Massive redirects

     ... For example, all ARPANET traffic would oscillate
     between MCLEAN-MB.DDN.MIL and CAMBRIDGE-MB.DDN.MIL with the gateways
     redirecting to each other.

Can you please tell us when this happened, or whether it still goes on?  If it
is the current version, then there may be some configuration problem.  If it
was a previous version, you may have been bitten by a transition between
versions, or an old load-sharing table.

Was this problem noted at the host you sent mail from, that is, 26.0.0.18
radc-multics.arpa?

Can you tell whether the redirects you received were the subtype 'net' or
subtype 'host'?  Would your host act differently based on this distinction?

In general, if you find such a 'smoking gun' type of problem, this one or
another, please call the NOC, 800-492-4992, and be prepared to report times
and explicit addresses.  Any other detail, such as your local routing table,
may be useful also.  If you wish to report via email, I suggest you use the
mailing list 'gw-fire@bbn.com'.

Mike Brescia
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 16:20:00 GMT
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        comp.protocols.tcp-ip
Subject:   Massive redirects


We had temporarily switched over to the new EGP gateway and noticed that
the gateways couldn't make up their mind as to who was handling a
particular network.  For example, all ARPANET traffic would oscillate
between MCLEAN-MB.DDN.MIL and CAMBRIDGE-MB.DDN.MIL with the gateways
redirecting to each other.  This doesn't seem very productive.  We have
since then switched back to the older gateways which seem to work ok.
Hopefully, this will be fixed before the mandatory switchover later on
this month.

                              John G. Ata

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 16:22:12 GMT
From:      craig@CWH.CAM.NBS.GOV (Craig Hunt)
To:        comp.protocols.tcp-ip
Subject:   Routing Problems on Milnet

The routing problem which began to affect us at the end of
November has returned.  We are not receiving routes from milnet.
Originally, the problem existed intermittently for about two
weeks.  After installing a new gated which provided a larger max
packet size for egp the problem went away.  The problem
reappeared sometime last night after a three week period during
which we believed the problem was resolved.  Is anyone else who
upgraded to the lastest gated still seeing this problem?  Did
something change on milnet yesterday?  I have notified the NOC,
but I would like to know if we are unique or if others are seeing
these problems.

---Craig
   hunt@enh.nbs.gov
   (301)975-3827 

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 16:51:33 GMT
From:      brooks@Apple.COM (Kevin Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Monitor

In article <8901091832.AA05477@hp-iag.HP.COM> kincl%hp-iag@HP-SDE.SDE.HP.COM (Norman Kincl) writes:
>
>> Last spring two of my co-workers and I conducted and in-depth
>> evaluation of offerings from Cabletron, Network General, Excelan,
>> Hewlett Packard ...
>
>Lots can happen in that time.
>
>>                                                         Also loses when
>> it comes to anything above the link layer.
>
>We have a TCP/IP protocol interpreter that runs on the HP 4972A ( part
>number HP 18221A).  It decodes the level 3 and 4 protocols of TCP,
>DUP, IP, ICMP, ARP and RARP.

This may be a bit misleading, the HP 4972A does not actually decode the tcp/ip
protocol suite rather it displays or I should say tags each field as to what the
code in the field represents not what the code means.  This means that you still
need to decode the protocol stack your self but your saved the time of counting
bytes.  I would not call this protocol decode.  The Excelan product has very 
similar protocol decode features.

I did a fairly extensive evaluation of the HP 4972a, the Network General
Sniffer, FTP's lanwatch, and the Excelan Lanalyzer.  If anyone is interested 
in seeing a copy of my report send me email and I'll send you a copy.
Kevin Brooks
A/UX Specialist, Apple Computer		   APPLELINK: BROOKS3
UUCP: {mtxinu,sun,nsc,voder}!apple!brooks  DOMAIN: brooks@apple.apple.com
CSNET: brooks@apple.CSNET 		   ARPA: brooks%apple@csnet-relay.ARPA

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 17:00:51 GMT
From:      brooks@Apple.COM (Kevin Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Monitor

In article <8901110133.AA02616@ucbvax.Berkeley.EDU> murayama@CS.UCL.AC.UK (Yuko Murayama, +44-1-387-7050 ext.3695) writes:
>
>Just from curiosity, can any of those monitors have its own
>IP address and send out a packet ( a probe or some kind)
>to the net?    Or are they listen-only?
>
>Yuko

You don't actually asign an IP address to the monitors since TCP/IP is not
there game, but they all have their own ethernet address and can all transmit
packets out.  You can define the bytes in the packet if you need to, to say
simulate an IP address and some type of request.  The Excelan is the only
monitor that can transmit and monitor the net at the same time.
Kevin Brooks
A/UX Specialist, Apple Computer		   APPLELINK: BROOKS3
UUCP: {mtxinu,sun,nsc,voder}!apple!brooks  DOMAIN: brooks@apple.apple.com
CSNET: brooks@apple.CSNET 		   ARPA: brooks%apple@csnet-relay.ARPA

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 17:03:16 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: VERY strange behavior at USENET/BITNET gateway


      The SMTP standard seems clear on the division between header and
body of a message.  Difficulties in some implementations in dealing with
such a standard are irrelevant.   Such problems must be dealt with in
individual implementations.  

					John Nagle

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 17:13:11 GMT
From:      tdh@moriaMoria.Sp.Unisys.Com (Thomas Hintz)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: basic info about Network File System (NFS)

In article <369@siswat.UUCP>, buck@siswat.UUCP (A. Lester Buck) writes:
> Can NFS handle the idea of records in files, as on mainframes?
> ...
> Is this done by putting some record layering code in the
> file pipeline, or what?  References would be great.
> Can NFS handle different character codes (i.e., ASCII to/from
> EBCDIC) between machines?  Not the simple case of all text
> or all binary, but say a database with binary fields and
> A. Lester Buck		...!uhnix1!moray!siswat!buck

NFS doesn't have 'hooks' persay.  NFS files appear as normal data
files to the system.  A NFS implementaion can choose to filter files
in special ways depending on some context of the file (ie. the same file
named several ways could trigger different filters).  I reality, I
don't know an NFS that does that, but then I don't know IBM's NFS.

I may be porting NFS to UNISYS 1100 series mainframes soon.  The same
conversion problems exist: 1100 data files occur in many forms.  If we
do this, we may choose to allow filtering of files by both name context,
and by data content since 1100 files also have 'SDF' words to describe
each record.  Sounds messy.
-- 
- - - -
Thomas D. Hintz				(612) 687-2684
UNISYS					tdh@moria.sp.unisys.com
Network Engineering			..!com50!mscunx!moria!tdh

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 20:08:45 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: basic info about Network File System (NFS)

In article <10266@well.UUCP>, slf@well.UUCP (Sharon Lynne Fisher) writes:
> 
> There's a newsgroup for NFS called either comp.dcom.nfs or comp.protocols.nfs.
> (Most likely the latter; I'm just too lazy to look it up.)  Geoff Arnold, the
> Sun guy in charge of NFS, hangs out there.

You're too kind, Sharon. The newsgroup is indeed comp.protocols.nfs,
but I'm hardly "the Sun guy in charge of NFS". I'm just the PC-NFS
architect.

Geoff

-- 
Geoff Arnold, Sun Microsystems Inc.  | "It is well known that the longer one
PC Dist. Sys. Group (home of PC-NFS) |postpones a pleasure, the greater the
UUCP: {hplabs,decwrl...}!sun!garnold |pleasure when it arrives. Therefore, if
ARPA: garnold@sun.com                |one postpones it forever..." (Smullyan)

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 22:23:03 GMT
From:      tcs@BRL.MIL (Terry Slattery, SECAD)
To:        comp.protocols.tcp-ip
Subject:   PSN weirdness

Hi,
We've just seen some very strange behavior from some PSNs on the milnet and
would like some suggestions on how to proceed from here.

Synopsis:
	BRL internal hosts have been able to to talk to ARDEC.ARMY.MIL
(ARDEC.ARPA, addr 26.1.0.45) in the past.  However, for the last week or so,
the connections to them have been horrible to this site.  We can ping
26.0.0.45 (a TAC) with good turn-around times (< 500ms), but cannot ping
ardec at all.  The only other host on that PSN that we can contact is
TCACCIS-BAY.ARPA (26.2.0.45, also < 500ms). Testing from other milnet hosts
(usna.mil) shows that they can reach ardec, but that the round trip times
are vary quite widely (500ms - 5 sec).  Pings to the two working node 45
hosts also exhibit a long round trip time for the first few packets and then
stabilize at < 500ms.  Pings to other hosts around the milnet show no such
behavior.  Routes from both BRL-GATEWAY and USNA are identical.  Ardec can
occasionally reach BRL hosts, but we can not reach them.  In the recent
past, we have had problems maintaining connections to them.  Host
connections via other PSNs are fine.  

Could there be a PSN or line problem which would cause this type of
behavior?  Talking to the Milnet CONUS NOC was fruitless ("Maybe your
terminals are incompatible; your machine is running UTX and they are
running BSD.")  Milnet NOC was able to telnet to both hosts so they claim
the problem is with one of us (also suggesting that we checking host
tables, etc.)

Anyone have any suggestions?

	-tcs

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 89 23:12:00 GMT
From:      dick@ccb.ucsf.edu (Dick Karpinski)
To:        comp.protocols.tcp-ip
Subject:   Print and Disk servers for IBM PCs et al

Our departmental IBM PC network folks are setting up IBM Token Ring
systems around campus.  They usually have a single server set up
per ring to provide both printing and disk service.  In some cases,
they use another "server" to gateway to an Ethernet for TELNET and
FTP.  Are products or freeware available to permit either printing
or shared network disk space across the gateway (the IP router just
mentioned above as the second server)?  Can these users be well 
served in the TCP world?  Could they do as well with $200 Ethernet
boards as with the more expensive token ring boards??

Dick

Dick Karpinski  Manager of Minicomputer Services, UCSF Computer Center
UUCP:  ...!ucbvax!ucsfcgl!cca.ucsf!dick        (415) 476-4529 (11-7)
BITNET:  dick@ucsfcca or dick@ucsfvm           Compuserve: 70215,1277  
USPS:  U-76 UCSF, San Francisco, CA 94143-0704   Telemail: RKarpinski   
Domain: dick@cca.ucsf.edu  Home (415) 658-6803  Ans 658-3797

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 89 02:26:23 GMT
From:      brescia@BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Massive redirects


     ... For example, all ARPANET traffic would oscillate
     between MCLEAN-MB.DDN.MIL and CAMBRIDGE-MB.DDN.MIL with the gateways
     redirecting to each other.

Can you please tell us when this happened, or whether it still goes on?  If it
is the current version, then there may be some configuration problem.  If it
was a previous version, you may have been bitten by a transition between
versions, or an old load-sharing table.

Was this problem noted at the host you sent mail from, that is, 26.0.0.18
radc-multics.arpa?

Can you tell whether the redirects you received were the subtype 'net' or
subtype 'host'?  Would your host act differently based on this distinction?

In general, if you find such a 'smoking gun' type of problem, this one or
another, please call the NOC, 800-492-4992, and be prepared to report times
and explicit addresses.  Any other detail, such as your local routing table,
may be useful also.  If you wish to report via email, I suggest you use the
mailing list 'gw-fire@bbn.com'.

Mike Brescia

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Jan 89 18:40:10 -0500
From:      Mike Brescia <brescia@BBN.COM>
To:        Craig Hunt <craig@cwh.cam.nbs.gov>
Cc:        tcp-ip@sri-nic.arpa, gated-people@devvax.tn.cornell.edu
Subject:   Re: Routing Problems on Milnet

     The routing problem which began to affect us at the end of
     November has returned.  We are not receiving routes from milnet.

Please return a note with some specific information, including the list of
'core' or 'trusted' gateways with which you run EGP, and your own gateway
addresses.  What operating system and release version are you running?

Are you running a version or port of unix to which the following message
refers?  I think Bruce Cole is talking about a unix based on 4.2BSD.

The latest gated (I have one which is newer than version 1.3.1.36), when run
in 4.3BSD, makes use of the sendsockopt(2) option SO_SNDBUF and SO_RCVBUF to
enable receipt and sending of large packets.

--- forwarded msg ---

Date: Thu, 12 Jan 89 14:34:48 CST
From: Bruce Cole <cole@cs.wisc.edu>
Message-Id: <8901122034.AA04544@oz.cs.wisc.edu>
Received: by oz.cs.wisc.edu; Thu, 12 Jan 89 14:34:48 CST
To: cal@okc-unix.arpa
Cc: egp-people@BBN.COM, dave@cs.wisc.edu, cole@cs.wisc.edu
In-Reply-To: Charles Leach's message of Thu Jan 12 09:20:01 1989
Subject: EGP Broken?

In addition to insuring that your EGP routing daemon can handle packet sizes
larger than 2048, Unix sites need to adjust their kernel to handle the larger
size.  In net/raw_cb.h, redefine RAWSNDQ & RAWRCVQ to be something like 4096.
With that change I am now able to receive routing updates from the butterflies
which are longer than 2048 bytes.


---- end fwd msg ---

Apologies to those of you who have already seen this on egp-people or
gated-people.  Also, thanks to Bruce for this other info, and I hope he is not
too miffed that I did not ask his permission before redistributing this.

Good hunting,
Mike
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 89 12:08:58 GMT
From:      rm@SPIDER.CO.UK (Richard McBride)
To:        comp.protocols.tcp-ip
Subject:   Re: Re Network Monitors

Thanks for correcting me.

It is true that the LANalyser uses an 80186 or 286 on board. As for the
Sniffer I have no indication on the spec sheets I have which processor
it uses. It was my mistake classifying these boards as dumb.

The message I was trying to get over was the benefits of multitasking on the
board rather than any comparison of hardware. I apologise for any confusion
caused.

Richard McBride
Software Engineer
Spider Systems

Disclaimer:

These comments are my own and do not necessarily reflect those of Spider
Systems. I don't need their help to screw up.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 89 14:27:58 GMT
From:      murayama@CS.UCL.AC.UK (Yuko Murayama, +44-1-387-7050 ext.3695)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Monitor


> From: Kevin Brooks <brooks@apple.com>
 
> You can define the bytes in the packet if you need to, to say
> simulate an IP address and some type of request.

Thank you for the reply.  So am I correct in that this simulated
packet should not be an Ethernert ARP reuqest, because it may cause the
confusion in the net?

Yuko

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Jan 89 14:27:58 +0000
From:      Yuko Murayama (+44-1-387-7050 ext.3695) <murayama@Cs.Ucl.AC.UK>
To:        Kevin Brooks <brooks@apple.com>
Cc:        tcp-ip@sri-nic.arpa, murayama@Cs.Ucl.AC.UK
Subject:   Re: Network Monitor

> From: Kevin Brooks <brooks@apple.com>

> You can define the bytes in the packet if you need to, to say
> simulate an IP address and some type of request.

Thank you for the reply.  So am I correct in that this simulated
packet should not be an Ethernert ARP reuqest, because it may cause the
confusion in the net?

Yuko
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 89 14:56:32 GMT
From:      zwang@CS.UCL.AC.UK (Zheng Wang, Ext: 3701)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions about 4.3BSD bind() on a multiple ethernet system.



 >If I bind a socket with the internet address of INADDR_ANY, which
 >internet address is returned?  Which internet address is placed in the
 >source address part of the IP header/trailer sent on that socket?
 >kernel determine which one I get?

Unfortunately, the internet address seems to be chosen at
random. Both addresses are possible.

 >Does the kernel keep separate UDP and TCP
 >port tables for each internet address?

No, the port can receive messages from both addresses.

Zheng

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Jan 89 14:56:32 +0000
From:      Zheng Wang (Ext: 3701) <zwang@Cs.Ucl.AC.UK>
To:        Ed Sale <ingr!b11!sale@uunet.uu.net>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Questions about 4.3BSD bind() on a multiple ethernet system.


 >If I bind a socket with the internet address of INADDR_ANY, which
 >internet address is returned?  Which internet address is placed in the
 >source address part of the IP header/trailer sent on that socket?
 >kernel determine which one I get?

Unfortunately, the internet address seems to be chosen at
random. Both addresses are possible.

 >Does the kernel keep separate UDP and TCP
 >port tables for each internet address?

No, the port can receive messages from both addresses.

Zheng
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 89 21:23:01 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: Questions about 4.3BSD bind() on a multiple ethernet system.


 >If I bind a socket with the internet address of INADDR_ANY, which
 >internet address is returned?  Which internet address is placed in the
 >source address part of the IP header/trailer sent on that socket?
 >kernel determine which one I get?

The internet address, unless specifically bound, is assigned based on the
address of the interface that the packets will be sent through.  The 
interface is selected based on the routing table.


Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 89 22:53:33 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.sys.proteon
Subject:   Humongous RIP exchanges


	I tracked some local reachability problems back to a RIP
interaction between my cisco jvnc-net router and one of my local
p4200s.  I had one or two of my 18 local subnets that were coming and
going in the cisco routing table.
	My campus backbone is a Pronet-80 with p4200s on it.  The
jvnc-gw lives on one subnet and gets its other local subnet routes
from a backbone p4200.  This p4200 insisted it had routes to all my
valid subnets and all the other hosts on campus agreed.  Why were some
local subnet routes in my cisco jvnc-gw coming and going?

	My cisco jvnc-gw advertises, using RIP, about 325 networks
onto this subnet that are reachable thru jvncnet.  My p4200 advertises
all the other 17 local subnets, one other external link, and was
sending poison reverse entries for all the jvncnet nets (325 entries!)
back out onto this poor subnet.  Turns out I had the p4200 in question
configured to send net routes, which is unnecessary, but it set up
this interesting problem.  So here was a cisco and a p4200 each RIPing
over 300 entries every 30 sec.  To make matters worse, the two routers
were synchronized, spewing forth RIP updates simultaneously.

	I am not sure whether the p4200 is able to process all the
cisco table entries.  There are 325 entries and I haven't done a
line-by-line comparison.  (A little more time with SNMP would help.)
However, I know the cisco wasn't able to process all the p4200
entries.  I know that because I could easily eyeball 18 subnet
entries.  The Sun hosts on this same subnet had no trouble keeping all
18 subnets in their tables, but they weren't trying to process 325
table entries at the same time they were trying to send 325 table
entries.
	I reconfigured the p4200 to stop sending all those poison
reverse routes back out to the jvnc-gw.  That dropped the update size
to 19 entries.  The cisco has no trouble now.

	So long as only one router is sending mega RIP updates there
is no problem.  I fixed the situation by reconfiguring my p4200, but
what if this p4200 needed to advertise all the arpanet connectivity?
The regional router and the arpanet router would get sync'ed together,
get overloaded trying to send and receive at the same time, and
reachability would get flaky.

	Has anyone else seen symptoms like these trying to juggle 300
net entries between external well-connected routers using RIP?  How
are others dealing with this situation?  EGP?  Defaults?  Which router
is improperly synchronizing?

	Kent England, Boston University

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 89 23:40:10 GMT
From:      brescia@BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing Problems on Milnet


     The routing problem which began to affect us at the end of
     November has returned.  We are not receiving routes from milnet.

Please return a note with some specific information, including the list of
'core' or 'trusted' gateways with which you run EGP, and your own gateway
addresses.  What operating system and release version are you running?

Are you running a version or port of unix to which the following message
refers?  I think Bruce Cole is talking about a unix based on 4.2BSD.

The latest gated (I have one which is newer than version 1.3.1.36), when run
in 4.3BSD, makes use of the sendsockopt(2) option SO_SNDBUF and SO_RCVBUF to
enable receipt and sending of large packets.

--- forwarded msg ---

Date: Thu, 12 Jan 89 14:34:48 CST
From: Bruce Cole <cole@cs.wisc.edu>
Message-Id: <8901122034.AA04544@oz.cs.wisc.edu>
Received: by oz.cs.wisc.edu; Thu, 12 Jan 89 14:34:48 CST
To: cal@okc-unix.arpa
Cc: egp-people@BBN.COM, dave@cs.wisc.edu, cole@cs.wisc.edu
In-Reply-To: Charles Leach's message of Thu Jan 12 09:20:01 1989
Subject: EGP Broken?

In addition to insuring that your EGP routing daemon can handle packet sizes
larger than 2048, Unix sites need to adjust their kernel to handle the larger
size.  In net/raw_cb.h, redefine RAWSNDQ & RAWRCVQ to be something like 4096.
With that change I am now able to receive routing updates from the butterflies
which are longer than 2048 bytes.


---- end fwd msg ---

Apologies to those of you who have already seen this on egp-people or
gated-people.  Also, thanks to Bruce for this other info, and I hope he is not
too miffed that I did not ask his permission before redistributing this.

Good hunting,
Mike

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 04:04:47 GMT
From:      loganj@byuvax.bitnet
To:        comp.sys.mac,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   BYU Telnet v2.2.3 available

BYU Telnet v2.2.3. is available for anonymous ftp from the zaphod
system at NCSA, ip number 128.174.20.50.

The following improvements have been made:

1. The "color" item under the "session" menu is now working properly.

2. The ftp local "help" command is working properly.

3. FTP prompting is working much better, it now echos keystrokes for
   all prompts except password.

4. The ftp put (or send) command now accepts two arguments properly.

5. If your config.tel file specifies "commandkeys = yes" the
   "session" menu wasn't displayed or working properly, but it is now.

6. The correct version number (2.2.3) is now displayed in the "About"
   dialog.

Known problems:

1. Sometimes the ftp document cursor "flashes" several times, then
   remains displayed even though an ftp transaction is not active.
   This is an annoyance, but not fatal - we are looking into the
   problem, it is not a problem with the original NCSA Telnet v2.2.

2. Sometimes the connection to some systems drops for no apparent
   reason.  We are working on the problem.

3. It does not work properly with the "NCSA Settings" file that is
   created by the original v2.2.

Again, thanks to Tim and others at NCSA for making this available.

Regards,
jim

bitnet:    loganj@byuvax
internet:  loganj@yvax.byu.edu

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 10:04:23 GMT
From:      mec@ardent.com
To:        comp.protocols.tcp-ip
Subject:   Reconciling /etc/hosts, yp, and named?

How do you reconcile /etc/hosts, yellow pages, and named?

Some of our customers want yellow pages.  Some want a named.  And some
of them are happy with /etc/hosts and probably don't want anything more
complicated/fragile than a small /etc/hosts file.  How can we offer
yellow pages and named at the same time?  How can we make everybody
happy?

Pointers to specific RFCs and software welcomed.

E-Mail to me and I'll summarize to the net.

Michael Chastain  mec@ardent.com    "He who dies with the most
Ardent Computer   uunet!ardent!mec  FRIENDS wins."

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 14:05:10 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   PSN weirdness

Hmm... Hey Dave (Mills)!  You got your satellite hunter tool handy?   

Seriously, I'll ask the PSN gurus to take a look at recent performance
stats.  

Do you have any data on direct pings from your gateway to these hosts?
(As opposed to sliding through the gateway from one of your internal
hosts?)   

After a quick look at the NIC records, my guess is that a substantial
number of those hosts are X.25 basic service customers.  But, you
should be able to ping at least the first 4 ports (all 1822).   

Mike

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 14:46:14 GMT
From:      tom@tut.cis.ohio-state.edu (Tom Easterday)
To:        comp.protocols.tcp-ip
Subject:   Bridge Communications Inc. terminal servers


Is anyone out there running Bridge Communications Inc. terminal servers?

We have some here and I would very much like to talk with someone else
about some things.  Post a phone number to the net and I will call.
Thanks in advance.


		 Tom

		  

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 15:13:40 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   dda0: Call Cleared LCN x cause code 9 diag code 88

Environment: Vax780, ACC6250 interface, X.25 connection to PSN 26.5.0.3

"dda0: Call Cleared LCN x cause code 9 diag code 88"

Ever since the new PSN software was installed on our Milnet IMP, we've
been getting thousands of these messages, often several a minute.

From what I can see, they are not an error, but instead represent a
change in the PSN software that now advises me that a host is down by
blowing the X.25 connection out of the water instead of just letting
it time out.

The difficulty is that each and every one of these cleared calls causes 
a message to get printed on the console, and we're wasting trees.

I've ADB-hotpatched a null into the beginning of the print string in the
system kernel to stop the messages, and perhaps at some later time I'll
take the printf out or modify the conditions under which it squirts out.

Any insight or advice on this?  Am I doing the right thing by ignoring
and suppressing these messages, or is there really something wrong?

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 USA
			brian@ucsd.edu ucsd!brian BRIAN@UCSD

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 18:22:12 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   Re:  Reconciling /etc/hosts, yp, and named?

Ultrix 3.0 (and 2.4) seem to have simplified this problem by instituting
a control file (/etc/svcorder) to specify what service(s) and which order.
i.e.  BIND, YP, LOCAL  for name resover, yellow pages, and/or local /etc/hosts.

The system functions (gethostbyxxx) use this file to determine where to
look, and in what order, for resolving hosts names.

This seems like as good an approach as any.

------------------------------------------------------------------------
Scott W. Rogers		Computer Sciences Corporation - Systems Division
AT&T: (703) 876-1363	3160 Fairview Park Dr. - Falls Church, VA 22152
Fax:  (703) 876-4072	Internet: scottr@csc-lons.ARPA
------------------------------------------------------------------------

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 18:34:41 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  Reconciling /etc/hosts, yp, and named?

When you find the answer let us all know.

My feeling is that a gethostby{name,addr} routine should have a heirarchy
of lookup which could be configurable.  But the default would be something
like:

	/etc/hosts could contain the following kinds of entries:
		hostname
		+hostname
		+
	Order would be important.
	Then gethostby{name,addr} would do the following:
	
	Unless directed by some environment variable or other policy
	mechanism:
		open /etc/hosts and attempt to resolve the name
		by searching sequentially through /etc/hosts
		if the name is found and has the prefix '+' goto
		the "YP domainname server for that host"
		if the name is not found and the standalone '+' is
		found then try the YP server.
		If all the above has failed then go for the Internet
		Domain nameserver pointed to by /etc/resolv.conf or
		whatever mechanism.  If there is no pointer to 
		an Internet Domain nameserver then I guess you are done!
		

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 18:35:04 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Reconciling /etc/hosts, yp, and named?

| From: mec@ardent.com (Michael Chastain)
| 
| How do you reconcile /etc/hosts, yellow pages, and named?

  The way that Sun has things set up works pretty well.  Additionally, if
you went that route you'd be operationally compatible with Sun OS on this
issue.  This second point is nearly as important as the original
problem.  People will spend no end of time bitching at your company if
they have to something weird and different on your machines for no
functional gain.  That works its way toward a dissatisfied customer base
Real Quick.

  In any case, their gethostby*() routines try to resolve names via YP
and if YP isn't available, use /etc/hosts.  Ypserv if forked off normally
will deal with a dbm version of /etc/hosts created from /etc/hosts.  But,
if YP is forked off with a "-i" flag, when a resolution request comes
down the line that ypserv can't handle, it hands it off to the name
server and then returns it's results as if it had figured out the answer.

  These layers of operation mean that you have to run YP and BIND if you
want BIND functionality, but normally that's not a problem.  Two
particular problems are worth mentioning however (below I outline a
scheme that doesn't suffer this problem):

    1. The YP protocol doesn't have the ability to return the answer ``I
  can't tell if the host exists or not - I timed out trying to get the
  answer for you'' I.e. a name server request timed out.  This occurs as a
  pathological problem when a gateway to a large chunk of the network goes
  out.  A client application will attempt to resolve a name, the request
  will end up in ypserv's hands, ypserv gets a time out from named, but
  because ypserv can't send that answer back to the client, ypserv simply
  exits.  Meanwhile, the client, not getting any response to its query,
  figures it got dropped by the network and retransmits its request ...
  Forever.  So you get a ypserv getting forked off once per second or so
  forever.

    Normally this isn't a problem because the client involved is someone
  typing ``telnet foo'' and they get tired after a while and hit ^C.  But
  when the client is an automated program like sendmail which doesn't get
  tired you have problems.  We've had situations where multiple sendmails
  will be running on multiple client machines and the combined YP traffic
  has dozens of ypservs being forked off per second.  The load average
  slowly climbs up past 16 as more and more sendmails hang waiting on name
  resolution and pretty soon the server machine crashes.

    It turns out that sendmail is basically the sole problem point along
  these lines in a standard configuration.  Bill Nowicki at Sun solved the
  problem by putting timeouts around all gethostby*() calls and we haven't
  had a problem since.  He set the timeout to 90 seconds which I feel is
  high, but that just means you have transient loads on your sever for 90
  seconds for each sendmail that times out.  Obviously a better solution
  would be to extend the YP protocol, but that would require a lot of work.

    2. The second problem is also associated with sendmail: MX records.  If
  you use sendmail in the configuration above, you get better service than
  if you just had a host table because you're getting name/address
  resolution for every host in the domain system that's on the internet,
  but you don't get to mail to hosts which have MX records set up.

    Bill Nowicki's solution here is to run a different version of sendmail
  that interfaces to the name server directly.  In fact, he simply uses the
  sendmail from Berkeley for this.  Note that this also solves the problem
  above since sendmail no longer goes through ypserv.  This has the
  disadvantage of requiring that you provide two sendmail binaries, but
  since you can compile them both from the same sources, that's not to
  great a problem.

  In the final analysis, I think that YP's best use is as a distributed
user/group/id name service.  I don't think that it makes a great
distributed host name/address service now that the DOMAIN system is
available.  It does have the significant advantage that you can simply
edit an old style host table and generate a YP host database from that
which is simpler than dealing with name server databases, but this is
only an advantage for an isolated network since any networks connected to
the internet will eventually be forced to setting up a name server
somewhere, and once you have a name server somewhere, it's trivial to set
up most of your hosts to either contact that name server or run a
secondary name server neither of which require complicated name server
databases.

  Given this and the fact that the DOMAIN system is here to stay, I'd say
that I'd be tempted to set up the library routines to try to contact a
name server first, use YP second, and finally look in /etc/hosts.  This
means that there'll be a slight delay any time anyone tries to resolve
something, but people will put up with lower performance a lot better
than lower functionality or ease of use.  Besides, the delay shouldn't be
that bad.

  You could do something like keeping track of what you're using in the
library so that an application would only suffer a delay on the first
resolution, but that would mean that if the name server or YP were
temporarily unavailable when an application first started it wouldn't use
either when service came back.  This would be a severe problem if the
application in question were a daemon or server of some sort.  Moreover,
it would lead to unpredictable behavior from a user's perception (two
people sitting next to each other might start the same application a
couple of seconds apart and one would get host table lookups throughout
the execution of the application while the other got name service.  People
would not be happy.

  I think that the best place to put the automatic switch is in the
res_*() routines.  In that configuration you could use stock BSD code for
everything except the res_*() routines which would have your additions to
lookup YP.  The res_*() routines already back off to host table lookups if
a name server can't be contacted - all you'd have to do is insert a YP
stage in between.

  Finally, I'd just use the standard MX sendmail in the above
configuration.  It's MX queries would time out if there wasn't a name
server available and it's subsequent res_*() for address would go through
the above automatic switch between BIND, YP, and host table lookup.

  Hope this helps.

Casey

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 18:51:18 GMT
From:      kwilliam@secola.Columbia.NCR.COM (Karen Williams)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Security

I think that topic has been discussed here before, but . . .

Do the TCP/IP standards allow for encryption of data?  In other
words, can a data capture/analyzer see everything, or is there
some level of security provided for?

Thanks for the info!

			Karen Williams
			NCR, SE - Columbia
			kwilliam@secola.Columbia.NCR.COM

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 21:21:53 GMT
From:      oleary@GODOT.PSC.EDU (dave o'leary)
To:        comp.protocols.tcp-ip
Subject:   Re:  dda0: Call Cleared LCN x cause code 9 diag code 88

Brian, 

we get the dda0: Call cleared msgs all the time on our ACC 5250 machine
on the Arpanet.  Somebody at ACC told me that it was nothing to woohrry
about, I think it may even be the normal open and close of X.25 circuits.
I haven't dealt with any problems on that for a while (since Arpa went
to 7.0 actually) so the stuff isn't too clear in my memory.  We are still
getting the msgs after many months.

					dave

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 89 23:50:28 GMT
From:      brooks@Apple.COM (Kevin Brooks)
To:        comp.protocols.tcp-ip
Subject:   slip configuration



I have an interesting question regaurding slip configuration.  If your topology
looks like the picture below should you configure a new network address for the
slip connections or use the same address as exist on the local net?


                 host A 		   host B (128.11.0.1)
		|      |                     |           |
     local net  |      |           slip conn |           | local net
    192.11.0.1	|      |---------------------| 

                     What should the ip numbers be for 
		     the slip interfaces on these two hosts?

Should slip connections have there own slip network number assigned?
Can you just assign different host numbers for each, keeping the net
numbers the same?  If the network numbers for each of the 2 hosts were
of a different class would they be able to communicate?  I guess I could
set this up and just try it but I just know someone out there is a slip
expert and knows the answers.  


Kevin Brooks
A/UX Specialist, Apple Computer		   APPLELINK: BROOKS3
UUCP: {mtxinu,sun,nsc,voder}!apple!brooks  DOMAIN: brooks@apple.apple.com
CSNET: brooks@apple.CSNET 		   ARPA: brooks%apple@csnet-relay.ARPA

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 01:50:30 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Reconciling /etc/hosts, yp, and named?


The only real way to make things work is to replace yp with pure named
service for hostname service only (of course, if you punt yp
completely, you'll probably be better off).  For 4.0, you can get
a shared library from SUN that has the 4.8 resolver code in it, and
still has everything else handled by yp.  For 3.5, you basically have
to throw away the SUN network utilities and recompile them from
source, linking them against a libc built with the 4.8 resolver code.  
We did that for our systems, and it wasn't too bad considering we had
4.3 sources.  You just can't make things work right by calling the resolver
routines from yp.  

You also have to get a completely new copy of sendmail as well, because
even if you replace all the yp calls with named calls, you must have
MX support, and the distributed sendmail doesn't do that.  You can 
also get an MX capable sendmail from SUN, though you are probably
better off compiling 5.59 or 5.61 yourself...

					Thanks,
					   Milo

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89   10:33 EST
From:      MARSHALL%JHUHYG.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP @ SRI-NIC.ARPA
Subject:   BITNET mail follows
OPTIONS: ACK    LOG    LONG     NOTEBOOK *




Date: 14 January 89, 10:26:04 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   ARPA TCP-IP Discussion List                    TCP-IP   at SRI-NIC.ARPA

Subject: Bridge Communications Terminal Servers  (would you believe 3Com?)

Tom Easterday writes:

> Is anyone out there running Bridge Communications Inc. terminal servers?

If you want to know, we got 'em.  A slue more on the hospital side of our
net...

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
Date: 14 January 89, 10:26:04 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   ARPA TCP-IP Discussion List                    TCP-IP   at SRI-NIC.ARPA

Subject: Bridge Communications Terminal Servers  (would you believe 3Com?)

Tom Easterday writes:

> Is anyone out there running Bridge Communications Inc. terminal servers?

If you want to know, we got 'em.  A slue more on the hospital side of our
net...

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 05:58:40 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   dda0: Call Cleared LCN x cause code 9 diag code 88

A quick look at the driver code reveals that it prints the message
anytime a connection is cleared without completing.  I.e.  what would
usually be considered "abnormal" aborts.  I think if I were getting as
many messages as were mentioned, I'd probably either comment the lines
out, or do some filtering to select only *real* aborts.  

Mike

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 08:35:58 GMT
From:      tsmith@USNA.MIL ("Timothy G. Smith ", Systems Staff)
To:        comp.protocols.tcp-ip
Subject:   Bfly redirect problem


NOTE: this message has many lines longer than 80 cols- find a wide
screen and it will be a whole lot easier to read.

I have been noticing the alleged massive redirects problem(s) for the
last few days and had not managed to find Mike Brescia's "smoking gun"
until a few minutes ago...

I have been poking around with brl's latest version of ping and have
come across some strange behavior.

Take alook at the ouput from pinging several hosts below. In
particuliar note the addresses we are being redirected to 

(New addr:0x1100141a)

this looks to me like someone up at brl decided to
output 26.20.0.17 (MCLEAN-DCEC-MB.DDN.MIL) in backwards hex notation.

Likewise

(New addr:0x6800151a) corresponds to 26.21.0.104 (RESTON-DCEC-MB.DDN.MIL).

It looks to me like the bflys are redirecting us back and forth from
one to the other. Anyone agree? Anyone else got any data to compare?
Anyone got a solution?

thanks,
	Tim Smith -[hp]ostmaster and general network person
US mail:ECSD/CADIG mailstop: 11G	E-mail:
	US Naval Academy		internet:tsmith@USNA.MIL
	Annapolis, MD 21402			 tsmith@USNA.NAVY.MIL (RSN)
MaBell :(301)267-4413			uucp	:...!uunet!usna!tsmith
Autovon:     281-4413


PING 129.97.129.72 (129.97.129.72): 56 data bytes
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
4  5  00 5400 880f   0 0000  fe  01 0a90 1a070066 81618148
64 bytes from 129.97.129.72: icmp_seq=0 time=1084 ms
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Redirect Network (New addr: 0x1100141a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
4  5  00 5400 8e0f   0 0000  fe  01 0490 1a070066 81618148
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
4  5  00 5400 940f   0 0000  fe  01 fe8f 1a070066 81618148
64 bytes from 129.97.129.72: icmp_seq=1 time=2300 ms
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Redirect Network (New addr: 0x1100141a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
4  5  00 5400 9a0f   0 0000  fe  01 f88f 1a070066 81618148
64 bytes from 129.97.129.72: icmp_seq=2 time=1572 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
4  5  00 5400 a10f   0 0000  fe  01 f18f 1a070066 81618148
64 bytes from 129.97.129.72: icmp_seq=3 time=2127 ms
64 bytes from 129.97.129.72: icmp_seq=4 time=1174 ms
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Redirect Network (New addr: 0x1100141a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
4  5  00 5400 a60f   0 0000  fe  01 ec8f 1a070066 81618148
64 bytes from 129.97.129.72: icmp_seq=5 time=915 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
4  5  00 5400 ae0f   0 0000  fe  01 e48f 1a070066 81618148
^C36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Destination Net Unreachable
----129.97.129.72 PING Statistics----
7 packets transmitted, 6 packets received, 14% packet loss
round-trip (ms)  min/avg/max = 915/1528/2300



PING neat.ai.toronto.edu (128.100.1.65): 56 data bytes
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Redirect Network (New addr: 0x1100141a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 3526   0 0000  fe  01 61fa 1a070066 80640141 
64 bytes from 128.100.1.65: icmp_seq=0 time=863 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 3826   0 0000  fe  01 5efa 1a070066 80640141 
64 bytes from 128.100.1.65: icmp_seq=1 time=897 ms
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Redirect Network (New addr: 0x1100141a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 3b26   0 0000  fe  01 5bfa 1a070066 80640141 
64 bytes from 128.100.1.65: icmp_seq=2 time=890 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 3e26   0 0000  fe  01 58fa 1a070066 80640141 
64 bytes from 128.100.1.65: icmp_seq=3 time=802 ms
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Redirect Network (New addr: 0x1100141a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 4126   0 0000  fe  01 55fa 1a070066 80640141 
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 2800 4426   0 0000  1d  06 39db 1a070066 80e40102 
TCP: from port 25, to port 26068 (decimal)
64 bytes from 128.100.1.65: icmp_seq=4 time=833 ms
----neat.ai.toronto.edu PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 802/857/897

PING uunet.uu.net (192.12.141.129): 56 data bytes
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 4727   0 0000  fe  01 672d 1a070066 c00c8d81 
64 bytes from 192.12.141.129: icmp_seq=0 time=671 ms
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Redirect Network (New addr: 0x1100141a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 4f27   0 0000  fe  01 5f2d 1a070066 c00c8d81 
64 bytes from 192.12.141.129: icmp_seq=1 time=507 ms
36 bytes from MOFFETT-FLD-MB.DDN.MIL (26.20.0.16): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 3900 5127   0 0000  1d  11 91c6 1a070066 81631402 
UDP: from port 53, to port 53 (decimal)
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 5727   0 0000  fe  01 572d 1a070066 c00c8d81 
64 bytes from 192.12.141.129: icmp_seq=2 time=511 ms
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Redirect Network (New addr: 0x1100141a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 6327   0 0000  fe  01 4b2d 1a070066 c00c8d81 
64 bytes from 192.12.141.129: icmp_seq=3 time=570 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Redirect Network (New addr: 0x6800151a)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 5400 6c27   0 0000  fe  01 422d 1a070066 c00c8d81 
64 bytes from 192.12.141.129: icmp_seq=4 time=483 ms
----uunet.uu.net PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 483/548/671

Here the top of a dump from gated on our milnet gateway (if anyone
wants the rest ask and I will mail to you [provided the bflys
cooperate]):

	GATED version 1.3.1.36 memory dump at Sat Jan 14 02:02:49 1989


	INTERFACE STATS:

	Interface: imp0			metric: 0
	Address: 26.7.0.102
	Up-down transitions: 0
	Net Number:    26.0.0.0		Net Mask:    ff000000
	Subnet Number: 26.0.0.0		Subnet Mask: ff000000
	Reconstituted Metric (RIP ONLY): NOT APPLIED (uses true metric)
	Flags: <UP|INTERFACE>
	Fixed Metrics:
	RIP:	NONE
	HELLO:	NONE
	Active gateways on interface:	NONE

	Interface: ex0			metric: 0
	Address: 192.12.31.1
	Up-down transitions: 0
	Broadcast Address:   192.12.31.255
	Net Number:    192.12.31.0		Net Mask:    ffffff00
	Subnet Number: 192.12.31.0		Subnet Mask: ffffff00
	Reconstituted Metric (RIP ONLY): NOT APPLIED (uses true metric)
	Flags: <UP|BROADCAST|INTERFACE|NOHELLOOUT>
	Fixed Metrics:
			RIP:	NONE
			HELLO:	NONE
	Active gateways on interface:	NONE

	EGP status:
		N_remote_nets: 4		defaultegpmetric: 255
		Autonomous System: 214

		Neighbor: 26.21.0.104		Interface: 26.7.0.102
		Hello interval: 62		Poll interval: 186
		State: <NEIGHBOR>		Reachability: <NG_UP|ME_UP>
		Poll net: 26.0.0.0		Flags: <>

		Neighbor: 26.20.0.17		Interface: 26.7.0.102
		Hello interval: 62		Poll interval: 186
		State: <NEIGHBOR>		Reachability: <NG_UP|ME_UP>
		Poll net: 26.0.0.0		Flags: <>

		Neighbor: 26.1.0.40		Interface: 26.7.0.102
		Hello interval: 62		Poll interval: 186
		State: <NEIGHBOR>		Reachability: <NG_UP|ME_UP>
		Poll net: 26.0.0.0		Flags: <>

		Neighbor: 26.3.0.75		Interface: 26.7.0.102
		Hello interval: 62		Poll interval: 186
		State: <NEIGHBOR>		Reachability: <NG_UP|ME_UP>
		Poll net: 26.0.0.0		Flags: <>

		Neighbor: 26.1.0.65		Interface: 26.7.0.102
		Hello interval: 62		Poll interval: 186
		State: <NEIGHBOR>		Reachability: <NG_UP|ME_UP>
		Poll net: 26.0.0.0		Flags: <>

	Martian networks:
		224.0.0.0 223.255.255.0 192.0.0.0 191.255.0.0 128.0.0.0 
		127.0.0.0 

-----------------------------------------------------------
	ROUTING TABLES:		626 nets

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 09:06:20 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 8556
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 8556; Fri, 13 Jan 89 11:46:51 MST
Date:         Fri, 13 Jan 89 10:04:23 GMT
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
Comments:     Warning -- original Sender: tag was tcp-ip-relay@SRI-NIC.ARPA
From:         ubvax!ardent!mec%AMES.ARC.NASA.GO@CUNYVM.CUNY.EDU
Subject:      Reconciling /etc/hosts, yp, and named?
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>

How do you reconcile /etc/hosts, yellow pages, and named?

Some of our customers want yellow pages.  Some want a named.  And some
of them are happy with /etc/hosts and probably don't want anything more
complicated/fragile than a small /etc/hosts file.  How can we offer
yellow pages and named at the same time?  How can we make everybody
happy?

Pointers to specific RFCs and software welcomed.

E-Mail to me and I'll summarize to the net.

Michael Chastain  mec@ardent.com    "He who dies with the most
Ardent Computer   uunet!ardent!mec  FRIENDS wins."
.
QUIT

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 11:40:45 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 0337
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 0337; Fri, 13 Jan 89 13:03:45 MST
Date:         Fri, 13 Jan 89 14:46:14 GMT
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
Comments:     Warning -- original Sender: tag was tcp-ip-relay@SRI-NIC.ARPA
From:         Tom Easterday <tom%TUT.CIS.OHIO-STATE.EDU@CUNYVM.CUNY.EDU>
Subject:      Bridge Communications Inc. terminal servers
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>


Is anyone out there running Bridge Communications Inc. terminal servers?

We have some here and I would very much like to talk with someone else
about some things.  Post a phone number to the net and I will call.
Thanks in advance.


         Tom


.
QUIT

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Sat, 14 Jan 89 17:09:22 EST
From:      Nick Gimbrone <NJG@CORNELLA.ccs.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Re: VERY strange behavior at USENET/BITNET gateway
>> Something which happens (at least with UREP) is that files coming
>> in from BITNET-land have lines which are supposed to be truly
>> empty instead contain some number of blanks.  You would think this
>Perhaps some of you would take a hand in convincing IBM that an
>empty line should exist.
This is not an IBM problem. The IBM software has no problem treating
the line of blanks as a "null line". In this case it sounds more like
a UREP problem. UREP is the one who is trying to do cross protocol
conversions, thus it is UREP's job to convert between "null lines" and
"blank lines". Remember, if it came via UREP from an IBM system then
it was talking BSMTP, not SMTP (and thus "null lines" are represented
as "blank lines"). In the case of IBM's VM TCP/IP package the translation
between these two forms occurs just fine (a true "null line" is send on
SMTP when recieved on the BSMTP side, etc).
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 13:30:58 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 1925
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 1925; Fri, 13 Jan 89 19:33:10 MST
Date:         Fri, 13 Jan 89 15:13:40 GMT
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
Comments:     Warning -- original Sender: tag was tcp-ip-relay@SRI-NIC.ARPA
From:         Brian Kantor <brian%UCSD.EDU@CUNYVM.CUNY.EDU>
Subject:      dda0: Call Cleared LCN x cause code 9 diag code 88
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>

Environment: Vax780, ACC6250 interface, X.25 connection to PSN 26.5.0.3

"dda0: Call Cleared LCN x cause code 9 diag code 88"

Ever since the new PSN software was installed on our Milnet IMP, we've
been getting thousands of these messages, often several a minute.

From what I can see, they are not an error, but instead represent a
change in the PSN software that now advises me that a host is down by
blowing the X.25 connection out of the water instead of just letting
it time out.

The difficulty is that each and every one of these cleared calls causes
a message to get printed on the console, and we're wasting trees.

I've ADB-hotpatched a null into the beginning of the print string in the
system kernel to stop the messages, and perhaps at some later time I'll
take the printf out or modify the conditions under which it squirts out.

Any insight or advice on this?  Am I doing the right thing by ignoring
and suppressing these messages, or is there really something wrong?

    Brian Kantor    UCSD Office of Academic Computing
            Academic Network Operations Group
            UCSD B-028, La Jolla, CA 92093 USA
            brian@ucsd.edu ucsd!brian BRIAN@UCSD
.
QUIT

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 14:20:23 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 2115
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 2115; Fri, 13 Jan 89 19:40:48 MST
Date:         Fri, 13 Jan 89 16:21:53 EST
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
From:         dave o'leary <oleary%GODOT.PSC.EDU@CUNYVM.CUNY.EDU>
Subject:      Re:  dda0: Call Cleared LCN x cause code 9 diag code 88
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>

Brian,

we get the dda0: Call cleared msgs all the time on our ACC 5250 machine
on the Arpanet.  Somebody at ACC told me that it was nothing to woohrry
about, I think it may even be the normal open and close of X.25 circuits.
I haven't dealt with any problems on that for a while (since Arpa went
to 7.0 actually) so the stuff isn't too clear in my memory.  We are still
getting the msgs after many months.

                    dave

.
QUIT

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 15:15:11 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 2988
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 2988; Fri, 13 Jan 89 21:28:32 MST
Date:         Fri, 13 Jan 89 13:22:12 est
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
From:         "Scott W. Rogers" <scottr%CSC-LONS.ARPA@CUNYVM.CUNY.EDU>
Subject:      Re:  Reconciling /etc/hosts, yp, and named?
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>

Ultrix 3.0 (and 2.4) seem to have simplified this problem by instituting
a control file (/etc/svcorder) to specify what service(s) and which order.
i.e.  BIND, YP, LOCAL  for name resover, yellow pages, and/or local /etc/hosts.

The system functions (gethostbyxxx) use this file to determine where to
look, and in what order, for resolving hosts names.

This seems like as good an approach as any.

------------------------------------------------------------------------
Scott W. Rogers        Computer Sciences Corporation - Systems Division
AT&T: (703) 876-1363    3160 Fairview Park Dr. - Falls Church, VA 22152
Fax:  (703) 876-4072    Internet: scottr@csc-lons.ARPA
------------------------------------------------------------------------
.
QUIT

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 15:33:00 GMT
From:      MARSHALL@JHUHYG.BITNET
To:        comp.protocols.tcp-ip
Subject:   BITNET mail follows

OPTIONS: ACK    LOG    LONG     NOTEBOOK *




Date: 14 January 89, 10:26:04 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   ARPA TCP-IP Discussion List                    TCP-IP   at SRI-NIC.ARPA

Subject: Bridge Communications Terminal Servers  (would you believe 3Com?)

Tom Easterday writes:

> Is anyone out there running Bridge Communications Inc. terminal servers?

If you want to know, we got 'em.  A slue more on the hospital side of our
net...

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
Date: 14 January 89, 10:26:04 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   ARPA TCP-IP Discussion List                    TCP-IP   at SRI-NIC.ARPA

Subject: Bridge Communications Terminal Servers  (would you believe 3Com?)

Tom Easterday writes:

> Is anyone out there running Bridge Communications Inc. terminal servers?

If you want to know, we got 'em.  A slue more on the hospital side of our
net...

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 89 22:09:22 GMT
From:      NJG@CORNELLA.CIT.CORNELL.EDU (Nick Gimbrone)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: VERY strange behavior at USENET/BITNET gateway

>> Something which happens (at least with UREP) is that files coming
>> in from BITNET-land have lines which are supposed to be truly
>> empty instead contain some number of blanks.  You would think this
>Perhaps some of you would take a hand in convincing IBM that an
>empty line should exist.
This is not an IBM problem. The IBM software has no problem treating
the line of blanks as a "null line". In this case it sounds more like
a UREP problem. UREP is the one who is trying to do cross protocol
conversions, thus it is UREP's job to convert between "null lines" and
"blank lines". Remember, if it came via UREP from an IBM system then
it was talking BSMTP, not SMTP (and thus "null lines" are represented
as "blank lines"). In the case of IBM's VM TCP/IP package the translation
between these two forms occurs just fine (a true "null line" is send on
SMTP when recieved on the BSMTP side, etc).

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 89 03:33:16 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Security

In article <207@secola.Columbia.NCR.COM>, kwilliam@secola.Columbia.NCR.COM (Karen Williams) writes:
> 
> Do the TCP/IP standards allow for encryption of data?

There are no encryption provisions in the standard protocol suite at
the IP or TCP level.  It's possible to encrypt at the link level (i.e.,
the Blacker Front End), and of course at the application level.  See
RFC 1040 for some movement in that direction.

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1989 14:57-EST
From:      CERF@A.ISI.EDU
To:        ucsdhub!hp-sdd!ncr-sd!ncrcae!secola!kwilliam@SDCSVAX.UCSD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP/IP Security
Karen,

The TCP/IP standards allow for encryption at several levels.
At applications level (e.g. secure mail) and at any level above
IP. The gateways have to see the IP headers in the clear to
provide routing and type of service handling. TCP/IP nets are
also operated regularly with link encryption.

Vint Cerf
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 89 11:26:23 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 4164
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 4164; Sat, 14 Jan 89 00:21:53 MST
Date:         Fri, 13 Jan 89 18:51:18 GMT
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
Comments:     Warning -- original Sender: tag was tcp-ip-relay@SRI-NIC.ARPA
From:         Karen Williams
              <ucsdhub!hp-sdd!ncr-sd!ncrcae!secola!kwilliam@SDCSVAX.UCSD.EDU>
Subject:      TCP/IP Security
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>

I think that topic has been discussed here before, but . . .

Do the TCP/IP standards allow for encryption of data?  In other
words, can a data capture/analyzer see everything, or is there
some level of security provided for?

Thanks for the info!

            Karen Williams
            NCR, SE - Columbia
            kwilliam@secola.Columbia.NCR.COM
.
QUIT

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 89 13:50:33 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 5065
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 5065; Sat, 14 Jan 89 01:39:30 MST
Date:         Fri, 13 Jan 89 18:35:04 GMT
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
Comments:     Warning -- original Sender: tag was tcp-ip-relay@SRI-NIC.ARPA
From:         Casey Leedom <gauss.llnl.gov!casey%LLL-WINKEN.LLNL.GOV@CUNYVM.CUNY.EDU>
Subject:      Re: Reconciling /etc/hosts, yp, and named?
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>

| From: mec@ardent.com (Michael Chastain)
|
| How do you reconcile /etc/hosts, yellow pages, and named?

  The way that Sun has things set up works pretty well.  Additionally, if
you went that route you'd be operationally compatible with Sun OS on this
issue.  This second point is nearly as important as the original
problem.  People will spend no end of time bitching at your company if
they have to something weird and different on your machines for no
functional gain.  That works its way toward a dissatisfied customer base
Real Quick.

  In any case, their gethostby*() routines try to resolve names via YP
and if YP isn't available, use /etc/hosts.  Ypserv if forked off normally
will deal with a dbm version of /etc/hosts created from /etc/hosts.  But,
if YP is forked off with a "-i" flag, when a resolution request comes
down the line that ypserv can't handle, it hands it off to the name
server and then returns it's results as if it had figured out the answer.

  These layers of operation mean that you have to run YP and BIND if you
want BIND functionality, but normally that's not a problem.  Two
particular problems are worth mentioning however (below I outline a
scheme that doesn't suffer this problem):

    1. The YP protocol doesn't have the ability to return the answer ``I
  can't tell if the host exists or not - I timed out trying to get the
  answer for you'' I.e. a name server request timed out.  This occurs as a
  pathological problem when a gateway to a large chunk of the network goes
  out.  A client application will attempt to resolve a name, the request
  will end up in ypserv's hands, ypserv gets a time out from named, but
  because ypserv can't send that answer back to the client, ypserv simply
  exits.  Meanwhile, the client, not getting any response to its query,
  figures it got dropped by the network and retransmits its request ...
  Forever.  So you get a ypserv getting forked off once per second or so
  forever.

    Normally this isn't a problem because the client involved is someone
  typing ``telnet foo'' and they get tired after a while and hit ^C.  But
  when the client is an automated program like sendmail which doesn't get
  tired you have problems.  We've had situations where multiple sendmails
  will be running on multiple client machines and the combined YP traffic
  has dozens of ypservs being forked off per second.  The load average
  slowly climbs up past 16 as more and more sendmails hang waiting on name
  resolution and pretty soon the server machine crashes.

    It turns out that sendmail is basically the sole problem point along
  these lines in a standard configuration.  Bill Nowicki at Sun solved the
  problem by putting timeouts around all gethostby*() calls and we haven't
  had a problem since.  He set the timeout to 90 seconds which I feel is
  high, but that just means you have transient loads on your sever for 90
  seconds for each sendmail that times out.  Obviously a better solution
  would be to extend the YP protocol, but that would require a lot of work.

    2. The second problem is also associated with sendmail: MX records.  If
  you use sendmail in the configuration above, you get better service than
  if you just had a host table because you're getting name/address
  resolution for every host in the domain system that's on the internet,
  but you don't get to mail to hosts which have MX records set up.

    Bill Nowicki's solution here is to run a different version of sendmail
  that interfaces to the name server directly.  In fact, he simply uses the
  sendmail from Berkeley for this.  Note that this also solves the problem
  above since sendmail no longer goes through ypserv.  This has the
  disadvantage of requiring that you provide two sendmail binaries, but
  since you can compile them both from the same sources, that's not to
  great a problem.

  In the final analysis, I think that YP's best use is as a distributed
user/group/id name service.  I don't think that it makes a great
distributed host name/address service now that the DOMAIN system is
available.  It does have the significant advantage that you can simply
edit an old style host table and generate a YP host database from that
which is simpler than dealing with name server databases, but this is
only an advantage for an isolated network since any networks connected to
the internet will eventually be forced to setting up a name server
somewhere, and once you have a name server somewhere, it's trivial to set
up most of your hosts to either contact that name server or run a
secondary name server neither of which require complicated name server
databases.

  Given this and the fact that the DOMAIN system is here to stay, I'd say
that I'd be tempted to set up the library routines to try to contact a
name server first, use YP second, and finally look in /etc/hosts.  This
means that there'll be a slight delay any time anyone tries to resolve
something, but people will put up with lower performance a lot better
than lower functionality or ease of use.  Besides, the delay shouldn't be
that bad.

  You could do something like keeping track of what you're using in the
library so that an application would only suffer a delay on the first
resolution, but that would mean that if the name server or YP were
temporarily unavailable when an application first started it wouldn't use
either when service came back.  This would be a severe problem if the
application in question were a daemon or server of some sort.  Moreover,
it would lead to unpredictable behavior from a user's perception (two
people sitting next to each other might start the same application a
couple of seconds apart and one would get host table lookups throughout
the execution of the application while the other got name service.  People
would not be happy.

  I think that the best place to put the automatic switch is in the
res_*() routines.  In that configuration you could use stock BSD code for
everything except the res_*() routines which would have your additions to
lookup YP.  The res_*() routines already back off to host table lookups if
a name server can't be contacted - all you'd have to do is insert a YP
stage in between.

  Finally, I'd just use the standard MX sendmail in the above
configuration.  It's MX queries would time out if there wasn't a name
server available and it's subsequent res_*() for address would go through
the above automatic switch between BIND, YP, and host table lookup.

  Hope this helps.

Casey
distributed host name/address service now that the DOMAIN system is
available.  It does have the significant advantage that you can simply
edit an old style host table and generate a YP host database from that
which is simpler than dealing with name server databases, but this is
Received: from BYUADMIN by ADMIN.BYU.EDU (Mailer R2.01A) with BSMTP id 5010;
 Sat, 14 Jan 89 01:38:36 MST
Received: from SRI-NIC.ARPA by ADMIN.BYU.EDU (IBM VM SMTP R1.2) with TCP; Sat,
 14 Jan 89 01:38:29 MST
Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri, 13 Jan 89
 11:38:13 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.33)
    id AA07164; Fri, 13 Jan 89 11:11:05-0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
    (contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 Jan 89 18:35:04 GMT
From: gauss.llnl.gov!casey@lll-winken.llnl.gov  (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Subject: Re: Reconciling /etc/hosts, yp, and named?
Message-Id: <16587@lll-winken.LLNL.GOV>
References: <1737@ardent.UUCP>
Sender: tcp-ip-relay@sri-nic.arpa
To: tcp-ip@sri-nic.arpa

| From: mec@ardent.com (Michael Chastain)
|
| How do you reconcile /etc/hosts, yellow pages, and named?

  The way that Sun has things set up works pretty well.  Additionally, if
you went that route you'd be operationally compatible with Sun OS on this
issue.  This second point is nearly as important as the original
problem.  People will spend no end of time bitching at your company if
they have to something weird and different on your machines for no
functional gain.  That works its way toward a dissatisfied customer base
Real Quick.

  In any case, their gethostby*() routines try to resolve names via YP
and if YP isn't available, use /etc/hosts.  Ypserv if forked off normally
will deal with a dbm version of /etc/hosts created from /etc/hosts.  But,
if YP is forked off with a "-i" flag, when a resolution request comes
down the line that ypserv can't handle, it hands it off to the name
server and then returns it's results as if it had figured out the answer.

  These layers of operation mean that you have to run YP and BIND if you
want BIND functionality, but normally that's not a problem.  Two
particular problems are worth mentioning however (below I outline a
scheme that doesn't suffer this problem):

    1. The YP protocol doesn't have the ability to return the answer ``I
  can't tell if the host exists or not - I timed out trying to get the
  answer for you'' I.e. a name server request timed out.  This occurs as a
  pathological problem when a gateway to a large chunk of the network goes
  out.  A client application will attempt to resolve a name, the request
  will end up in ypserv's hands, ypserv gets a time out from named, but
  because ypserv can't send that answer back to the client, ypserv simply
  exits.  Meanwhile, the client, not getting any response to its query,
  figures it got dropped by the network and retransmits its request ...
  Forever.  So you get a ypserv getting forked off once per second or so
  forever.

    Normally this isn't a problem because the client involved is someone
  typing ``telnet foo'' and they get tired after a while and hit ^C.  But
  when the client is an automated program like sendmail which doesn't get
  tired you have problems.  We've had situations where multiple sendmails
  will be running on multiple client machines and the combined YP traffic
  has dozens of ypservs being forked off per second.  The load average
  slowly climbs up past 16 as more and more sendmails hang waiting on name
  resolution and pretty soon the server machine crashes.

    It turns out that sendmail is basically the sole problem point along
  these lines in a standard configuration.  Bill Nowicki at Sun solved the
  problem by putting timeouts around all gethostby*() calls and we haven't
  had a problem since.  He set the timeout to 90 seconds which I feel is
  high, but that just means you have transient loads on your sever for 90
  seconds for each sendmail that times out.  Obviously a better solution
  would be to extend the YP protocol, but that would require a lot of work.

    2. The second problem is also associated with sendmail: MX records.  If
  you use sendmail in the configuration above, you get better service than
  if you just had a host table because you're getting name/address
  resolution for every host in the domain system that's on the internet,
  but you don't get to mail to hosts which have MX records set up.

    Bill Nowicki's solution here is to run a different version of sendmail
  that interfaces to the name server directly.  In fact, he simply uses the
  sendmail from Berkeley for this.  Note that this also solves the problem
  above since sendmail no longer goes through ypserv.  This has the
  disadvantage of requiring that you provide two sendmail binaries, but
  since you can compile them both from the same sources, that's not to
  great a problem.

  In the final analysis, I think that YP's best use is as a distributed
user/group/id name service.  I don't think that it makes a great
distributed host name/address service now that the DOMAIN system is
available.  It does have the significant advantage that you can simply
edit an old style host table and generate a YP host database from that
which is simpler than dealing with name server databases, but this is
only an advantage for an isolated network since any networks connected to
the internet will eventually be forced to setting up a name server
somewhere, and once you have a name server somewhere, it's trivial to set
up most of your hosts to either contact that name server or run a
secondary name server neither of which require complicated name server
databases.

  Given this and the fact that the DOMAIN system is here to stay, I'd say
that I'd be tempted to set up the library routines to try to contact a
name server first, use YP second, and finally look in /etc/hosts.  This
means that there'll be a slight delay any time anyone tries to resolve
something, but people will put up with lower performance a lot better
than lower functionality or ease of use.  Besides, the delay shouldn't be
that bad.

  You could do something like keeping track of what you're using in the
library so that an application would only suffer a delay on the first
resolution, but that would mean that if the name server or YP were
temporarily unavailable when an application first started it wouldn't use
either when service came back.  This would be a severe problem if the
application in question were a daemon or server of some sort.  Moreover,
it would lead to unpredictable behavior from a user's perception (two
people sitting next to each other might start the same application a
couple of seconds apart and one would get host table lookups throughout
the execution of the application while the other got name service.  People
would not be happy.

  I think that the best place to put the automatic switch is in the
res_*() routines.  In that configuration you could use stock BSD code for
everything except the res_*() routines which would have your additions to
lookup YP.  The res_*() routines already back off to host table lookups if
a name server can't be contacted - all you'd have to do is insert a YP
stage in between.

  Finally, I'd just use the standard MX sendmail in the above
configuration.  It's MX queries would time out if there wasn't a name
server available and it's subsequent res_*() for address would go through
the above automatic switch between BIND, YP, and host table lookup.

  Hope this helps.

Casey
.
QUIT

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 89 15:04:28 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 5556
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 5556; Sat, 14 Jan 89 02:34:09 MST
Date:         Fri, 13 Jan 89 23:50:28 GMT
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
Comments:     Warning -- original Sender: tag was tcp-ip-relay@SRI-NIC.ARPA
From:         Kevin Brooks <brooks%APPLE.COM@CUNYVM.CUNY.EDU>
Subject:      slip configuration
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>



I have an interesting question regaurding slip configuration.  If your topology
looks like the picture below should you configure a new network address for the
slip connections or use the same address as exist on the local net?


                 host A            host B (128.11.0.1)
        |      |                     |           |
     local net  |      |           slip conn |           | local net
    192.11.0.1    |      |---------------------|

                     What should the ip numbers be for
             the slip interfaces on these two hosts?

Should slip connections have there own slip network number assigned?
Can you just assign different host numbers for each, keeping the net
numbers the same?  If the network numbers for each of the 2 hosts were
of a different class would they be able to communicate?  I guess I could
set this up and just try it but I just know someone out there is a slip
expert and knows the answers.


Kevin Brooks
A/UX Specialist, Apple Computer           APPLELINK: BROOKS3
UUCP: {mtxinu,sun,nsc,voder}!apple!brooks  DOMAIN: brooks@apple.apple.com
CSNET: brooks@apple.CSNET            ARPA: brooks%apple@csnet-relay.ARPA
.
QUIT

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Jan 89 20:44:59 est
From:      Barry Shein <bzs@pinocchio.encore.com>
To:        info-nets@think.com, info-futures@multimax.encore.com, tcp-ip@sri-nic.arpa
Subject:   Network Violence

Steve Jackson at BYUETIBM.BITNET (I assume that's Brigham Young
University?)  decided he didn't want a mailing list address forwarded
through his system anymore.

Rather than requesting some change he simply began forwarding every
message back to the entire INFO-FUTURES list (around 250 people plus
USENET.) I am attempting to get information from him to find this
entry since it's not at all obvious which one needs to be changed.

I would suggest removing any address referencing BYUTEIBM.BITNET from
all mailing lists until this organization can assure the network that
responsible administration has been restored to this node (not to
mention saving yourself from this kind of abuse.)

In fact, being as BYUTEIBM does not appear anywhere in my mailing list
it might simply be BITNET's own internal choice of routing which is
causing this problem, very disturbing.

Attached is an interchange with him which should make clear his
purely malicious intentions...

	-Barry Shein

From: BYUETIBM.BITNET!SEJ@talcott.harvard.edu
Date:         Sat, 14 Jan 89 16:31:06 MST
Subject:      Re: Undelivered mail
To: <encore!pinocchio!bzs@harvunxw.BITNET>
In-Reply-To:  Your message of Sat, 14 Jan 89 16:25:21 MST

>
>
>What's going on here? Why is this list receiving these Resent-From:'s
>which seem to be from you? Please explain.
>
>        -Barry Shein

They end up dropping into my system punch queue and I just want
someone to change the routing that they take!  I get alot of them
and don't want them anymore.


Steve Jackson


-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Sun, 15 Jan 89 20:55 EST
From:      "John L. Jamison x8545" <JAMISON%campus.swarthmore.edu@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   TALK for VMS, with TCP/IP

Hi,

Does anyone know of an implementation of TALK for VMS, assuming that
VMS has TCP/IP available.  Specifically, we have Wollongong TCP/IP 5.0,
and I'd like to have the TALK capability also available for VMS users.

Thanks in advance for any help,

-John


-------------------------------------------------------------------
John Jamison                            Jamison@swarthmr.bitnet
System and Network Manager              jamison@campus.swarthmore.edu
Swarthmore College
Swarthmore, PA 19081                    (215) 328-8508

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Jan 89 02:38:27 MST
From:      Mark McCall <MCCALL%RADC-TOPS20.ARPA@CUNYVM.CUNY.EDU>
To:        "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>
Subject:   GOSIP
I have been out of touch for a few months and need some info.  Can anyone tell
me if GOSIP has been approved as a FIPS and when.  Thanks.

Capt. James McCall
Communications Computer Systems Staff Officer Course
Keesler AFB, MS
-------
.
QUIT
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 89 19:57:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Security

Karen,

The TCP/IP standards allow for encryption at several levels.
At applications level (e.g. secure mail) and at any level above
IP. The gateways have to see the IP headers in the clear to
provide routing and type of service handling. TCP/IP nets are
also operated regularly with link encryption.

Vint Cerf

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 89 21:18:31 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   YP, /etc/hosts, domains


     My workstation is a NeXT that seems to have more or less vanilla SUN type
networking software.

     I was forced to turn on YP in order to get any form of domain lookups to
work at all.  I set up an /etc/resolv.conf file and rebooted, but still no
host lookups would work unless the entry was in /etc/hosts.

     Since that time, I've been continuously forced to ask the owner of the YP
server just to get the most trivial things done, like getting new services
added to the list for (development) software only I use.  My workstation's
/etc/services file is completely ignored.  I've not lunk my password file into
the YP namespace, and I have no interest in any of the "features" of YP.

     In other words, I'd dearly love to turn YP off, if only I could get
ordinary domain lookups working.  How do I do this?  Do I have to run a domain
server too, just to get the resolver working?

     Also, while I have everybody's attention, how do I load private
information into my machine's resolver's cache?  I want to put in certain RR's
that only my machine should know.  They're totally outside of the domain my
machine lives in.  I just want the cache at startup to have these RR's (with
more or less infinite timeouts) as if they came from the outside.  In the
TOPS-20 world, this was done by a "CLOAD <file>" in DOMAIN:RESOLV.CONFIG.

     Yet another thing; how do I persuade Unix to use uppercase or mixed case
for hostnames?  My machine's hostname is set to "Tomobiki-Cho" (and is
reported as such by hostname), but gethostbyname("Tomobiki-Cho") insists upon
returning an all lowercase string.  It even does this for hostnames in the
outside world whose domain servers are known to return uppercase strings in
the RR's!

-------

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 89 22:47:30 GMT
From:      TCP-IP-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 4875
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 4875; Sun, 15 Jan 89 11:28:47 MST
Date:         Sat, 14 Jan 89 17:09:22 EST
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
From:         Nick Gimbrone <NJG%CORNELLA.CCS.CORNELL.EDU@CUNYVM.CUNY.EDU>
Subject:      Re: Re: VERY strange behavior at USENET/BITNET gateway
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>
In-Reply-To:  Message of Mon,
              09 Jan 89 08:39:30 AST from
              <DEDOUREK%UNB.CA@CORNELLC.ccs.cornell.edu>

>> Something which happens (at least with UREP) is that files coming
>> in from BITNET-land have lines which are supposed to be truly
>> empty instead contain some number of blanks.  You would think this
>Perhaps some of you would take a hand in convincing IBM that an
>empty line should exist.
This is not an IBM problem. The IBM software has no problem treating
the line of blanks as a "null line". In this case it sounds more like
a UREP problem. UREP is the one who is trying to do cross protocol
conversions, thus it is UREP's job to convert between "null lines" and
"blank lines". Remember, if it came via UREP from an IBM system then
it was talking BSMTP, not SMTP (and thus "null lines" are represented
as "blank lines"). In the case of IBM's VM TCP/IP package the translation
between these two forms occurs just fine (a true "null line" is send on
SMTP when recieved on the BSMTP side, etc).
.
QUIT

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 00:30:38 GMT
From:      TCP-IP-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 4788
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 4788; Sun, 15 Jan 89 10:32:47 MST
Date:         Sat, 14 Jan 89 10:33:00 EST
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
From:         MARSHALL%JHUHYG.BITNET%CUNYVM.CUNY.EDU@CUNYVM.CUNY.EDU
Subject:      BITNET mail follows
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>

OPTIONS: ACK    LOG    LONG     NOTEBOOK *




Date: 14 January 89, 10:26:04 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   ARPA TCP-IP Discussion List                    TCP-IP   at SRI-NIC.ARPA

Subject: Bridge Communications Terminal Servers  (would you believe 3Com?)

Tom Easterday writes:

> Is anyone out there running Bridge Communications Inc. terminal servers?

If you want to know, we got 'em.  A slue more on the hospital side of our
net...

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
Date: 14 January 89, 10:26:04 EST
From: Marshall Albert Bryan     (301) 955-3445       MARSHALL at JHUHYG
To:   ARPA TCP-IP Discussion List                    TCP-IP   at SRI-NIC.ARPA

Subject: Bridge Communications Terminal Servers  (would you believe 3Com?)

Tom Easterday writes:

> Is anyone out there running Bridge Communications Inc. terminal servers?

If you want to know, we got 'em.  A slue more on the hospital side of our
net...

      Academic Data Center, User Specialist/Communications Manager
      School of Hygiene and Public Health, Johns Hopkins University
      615 North Wolfe Street,
      Baltimore, Maryland   21205-2179
.
QUIT

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Jan 89 10:02:05 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Cc:        mec@ardent.com, gauss.llnl.gov!casey@lll-winken.llnl.gov
Subject:   Re: Reconciling /etc/hosts, yp, and named?

>     1. The YP protocol doesn't have the ability to return the answer ``I
>   can't tell if the host exists or not - I timed out trying to get the
>   answer for you'' I.e. a name server request timed out.  This occurs as a
>   pathological problem when a gateway to a large chunk of the network goes
>   out.  A client application will attempt to resolve a name, the request
>   will end up in ypserv's hands, ypserv gets a time out from named, but
>   because ypserv can't send that answer back to the client, ypserv simply
>   exits.  Meanwhile, the client, not getting any response to its query,
>   figures it got dropped by the network and retransmits its request ...
>   Forever.  So you get a ypserv getting forked off once per second or so
>   forever.
> 
>     Normally this isn't a problem because the client involved is someone
>   typing ``telnet foo'' and they get tired after a while and hit ^C.  But
>   when the client is an automated program like sendmail which doesn't get
>   tired you have problems.  We've had situations where multiple sendmails
>   will be running on multiple client machines and the combined YP traffic
>   has dozens of ypservs being forked off per second.  The load average
>   slowly climbs up past 16 as more and more sendmails hang waiting on name
>   resolution and pretty soon the server machine crashes.

    This discussion leaves out an important point.  The vast number of ypservs
is not just a local problem.  Your load average may go up and sendmails hang,
but you are also potentially blasting dozens or hundreds of packets per second
across the network.  Furthermore, there are situations in which this
situation is stable.  There's a case where a host in Hawaii was sending to
a nameserver in Oklahoma (using the wrong address) and used up a considerable
portion of the bandwidth on the NSFNET backbone and on two regional networks
for more than a day before the bug was tracked down.

Craig
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 01:55:00 GMT
From:      JAMISON@campus.swarthmore.EDU ("John L. Jamison x8545")
To:        comp.protocols.tcp-ip
Subject:   TALK for VMS, with TCP/IP


Hi,

Does anyone know of an implementation of TALK for VMS, assuming that
VMS has TCP/IP available.  Specifically, we have Wollongong TCP/IP 5.0,
and I'd like to have the TALK capability also available for VMS users.

Thanks in advance for any help,

-John


-------------------------------------------------------------------
John Jamison                            Jamison@swarthmr.bitnet
System and Network Manager              jamison@campus.swarthmore.edu
Swarthmore College
Swarthmore, PA 19081                    (215) 328-8508

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 09:33:00 CST
From:      <hacke@mdc.com>
To:        "tcp-ip%sri-nic.arpa" <tcp-ip%sri-nic.arpa@cunyvm.cuny.edu>
Subject:   RE:      GOSIP
James:

GOSIP is now a FIPS: See FIBS PUB 145 - Government Open System Interconnection Profile (GOSIP)

Keith Hacke
hacke@mdc.com

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 05:18:45 GMT
From:      MCCALL@RADC-TOPS20.ARPA (Mark McCall)
To:        comp.protocols.tcp-ip
Subject:   GOSIP

I have been out of touch for a few months and need some info.  Can anyone tell
me if GOSIP has been approved as a FIPS and when.  Thanks.

Capt. James McCall
Communications Computer Systems Staff Officer Course
Keesler AFB, MS
-------

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 10:37:00 EST
From:      "CRAIG HUNT" <hunt@enh.nbs.gov>
To:        "brescia" <brescia@bbn.com>
Cc:        <tcp-ip@sri-nic.arpa>,<gated-people@devvax.tn.cornell.edu>, <support@twg.com>
Subject:   More Milnet routing problem
As I previously stated on these lists my computer is still having
problems receiving routes from milnet.  I recieved a few letters back
stating that other people are also seeing some problems.  In addition a
request was made that I supply more details about my specific problem. 
Here are the details: 

The computer is a Vax 8250 running VMS 4.7 and the Wollongong 3.2 TCP/IP
package.  We are connected to milnet IMP 19 on port 0 using standard
X.25 service over a 56 Kb line with an ACC ACP6250 interface on the Vax.
We upgraded to the lastest gated from Wollongong on December 20th. 

The routing problem started at the end of November and was intermittent
until installing the new gated on December 20th.  At that time the
routing problem appeared to go away but we continued to monitor the
routing table every day.  On Tuesday, January 10th the routing table
appeared ok but when the table was checked on Wednesady the 11th there
were no routes via milnet. Unfortunately we did not have tracing on for
gated.  The NOC and others were contacted to see if anything had changed
on the network or if others were reporting problems.  The night of the
11th the vax was rebooted with tracing on gated. The routes flowed in
from milnet but by the next morning there were no milnet routes in the
table. The trace was reviewed and showed that several routing update
packets were received from 26.1.0.40.  The last update was received at
22:51 on Wednesday the 11th.  The protocol continued to exchange hello/I
hear you messages and NR poll messages.  We would receive polls from
26.1.0.40 and send replies.  After three unanswered NR polls we dropped
26.1.0.40, acquired 26.1.0.65, sent 3 unanswered polls, acquired
26.3.0.75, sent 3 unanswered polls, acquired 26.1.0.40 ...  You get the
picture. We haven't received an update since Wednesday the 11th, despite
restarts and reboots. 

The problem does not appear to be related to any one core gateway because 
they all give the same result.  I suspected X.25 because we saw many 
errors on dda0, however on Friday the 13th (oh no!!) the NOC applied 3 
X.25 patches to our PSN and the errors on dda0 dropped to nothing. I 
contacted Wollongong on Friday after the NOC patches had no effect on 
the routing problem but have been unable to connect with anyone because 
of the holiday weekend.  I am now pursuing Mike Brescia's idea that the 
kernal code may need to be updated to supported the larger egp packet 
size in the same way that gated was updated.

If anyone out there has a TWG system which is successfully receiving EGP 
routing updates, please let me know how you are doing it.  Below are the 
EGP lines from my gated.conf.

Thanks for any help,
---Craig

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

#
# setup EGP configuration
#
autonomoussystem 49
egpmaxacquire   1
egpneighbor     26.1.0.40
egpneighbor     26.1.0.65
egpneighbor     26.3.0.75
#
#
egpnetsreachable 129.6.0.0 26.0.0.0

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 06:06:34 GMT
From:      TCP-IP-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 8340
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 8340; Sun, 15 Jan 89 19:42:25 MST
Date:         Sun, 15 Jan 89 13:18:31 PST
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
From:         Mark Crispin <mrc%SUMEX-AIM.STANFORD.EDU@CUNYVM.CUNY.EDU>
Subject:      YP, /etc/hosts, domains
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>

     My workstation is a NeXT that seems to have more or less vanilla SUN type
networking software.

     I was forced to turn on YP in order to get any form of domain lookups to
work at all.  I set up an /etc/resolv.conf file and rebooted, but still no
host lookups would work unless the entry was in /etc/hosts.

     Since that time, I've been continuously forced to ask the owner of the YP
server just to get the most trivial things done, like getting new services
added to the list for (development) software only I use.  My workstation's
/etc/services file is completely ignored.  I've not lunk my password file into
the YP namespace, and I have no interest in any of the "features" of YP.

     In other words, I'd dearly love to turn YP off, if only I could get
ordinary domain lookups working.  How do I do this?  Do I have to run a domain
server too, just to get the resolver working?

     Also, while I have everybody's attention, how do I load private
information into my machine's resolver's cache?  I want to put in certain RR's
that only my machine should know.  They're totally outside of the domain my
machine lives in.  I just want the cache at startup to have these RR's (with
more or less infinite timeouts) as if they came from the outside.  In the
TOPS-20 world, this was done by a "CLOAD <file>" in DOMAIN:RESOLV.CONFIG.

     Yet another thing; how do I persuade Unix to use uppercase or mixed case
for hostnames?  My machine's hostname is set to "Tomobiki-Cho" (and is
reported as such by hostname), but gethostbyname("Tomobiki-Cho") insists upon
returning an all lowercase string.  It even does this for hostnames in the
outside world whose domain servers are known to return uppercase strings in
the RR's!

-------
.
QUIT

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Jan 89 11:35:18 EST
From:      Howard Gilbert <GILBERT%YALEVM.BITNET@CORNELLC.ccs.cornell.edu>
To:        Mark Bodenstein <MAB@CORNELLC>
Subject:   Re: Standard (RFC) for IP-over-SNA
Re: The question of an RFC for IP-over-SNA (which the current IBM TCP/IP
product supports.)  This is forwarded from the Bitnet-based discussion
list for the IBM TCP/IP product.

Mark Bodenstein
Cornell University

----------------------------Original message----------------------------
The current IBM LU 0 version of IP over SNA is not a suitable basis
for standardization.  It supports only mainframe to mainframe connections
and is based on what is now obsolete protocol.  What is needed is an
RFC for IP over LU 6.2 SNA based on a PU 2.1, APPN, or subarea
routing.  This would then define a protocol which every IBM device
from the PC to midrange to mainframe could use with or without the
presence of a mainframe.  The current LU 0 connection on the mainframe
would then migrate to APPCCMD or Common Program Interface-Communications
(CPI-C of SAA) to conform to this standard.

The transport of IP over APPC is fairly trivial.  Since there is no
broadcast in SNA, it is necessary to translate the subnet portion of
the IP address into an LU name.  Since APPC is half-duplex, it may be
necessary to run two parallel sessions.   Presumably you would flush
the buffer with every IP packet and never confirm. Mapped conversations
look appropriate.  I see no need for PIP data.  The rest is
fill-in-the-blanks.

Adding the SNA network as a supported subnet protocol to IP would
make TCP/IP more accessable in large commercial shops.  However, most
such organizations may not need internet access.  They need to connect
widely scattered internal non-IBM equipment across their existing
SNA wide area network which already ties all corporate locations
together.  As such they need a PC based SNA router in the remote
location which LU 0 cannot supply.  They probably cannot afford and
do not require a separate IP based communications link to the
mainframe or between the remote nodes given that the SNA links are
already in place and connect everyone.
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 06:38:29 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   phone(1)

We have Jonathan Broome's phone(1) program sort of running (well,
let's call it limping) on sun.soe.clarkson.edu, and I'd like to invite
anyone who wants to check out their installation to phone me.  As of the
moment, adding a third party is broken, but then, "All the world's a Vax",
you know.  :-)
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
"I saved the whales!" - Rebecca L. Nelson, 3.5 years old, on receiving her
Christmas present of a whale "adoption" certificate.  Bless her liberal heart.

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 07:38:42 GMT
From:      tcp-ip-RELAY@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   (none)

HELO ADMIN.BYU.EDU
TICK 9342
MAIL FROM:<TCPIP-L@BYUADMIN.BITNET>
RCPT TO:<WTCPIPPB@UIAMVS>
DATA
Received: by BYUADMIN (Mailer R2.01A) id 9342; Sun, 15 Jan 89 22:09:28 MST
Date:         Sun, 15 Jan 89 20:44:59 est
Reply-To:     <TCP-IP%SRI-NIC.ARPA@CUNYVM.CUNY.EDU>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L%BYUADMIN.BITNET@CUNYVM.CUNY.EDU>
From:         Barry Shein <bzs%PINOCCHIO.ENCORE.COM@CUNYVM.CUNY.EDU>
Subject:      Network Violence
To:           "WCC Participate Redistribution (U Iowa)" <WTCPIPPB@UIAMVS>


Steve Jackson at BYUETIBM.BITNET (I assume that's Brigham Young
University?)  decided he didn't want a mailing list address forwarded
through his system anymore.

Rather than requesting some change he simply began forwarding every
message back to the entire INFO-FUTURES list (around 250 people plus
USENET.) I am attempting to get information from him to find this
entry since it's not at all obvious which one needs to be changed.

I would suggest removing any address referencing BYUTEIBM.BITNET from
all mailing lists until this organization can assure the network that
responsible administration has been restored to this node (not to
mention saving yourself from this kind of abuse.)

In fact, being as BYUTEIBM does not appear anywhere in my mailing list
it might simply be BITNET's own internal choice of routing which is
causing this problem, very disturbing.

Attached is an interchange with him which should make clear his
purely malicious intentions...

    -Barry Shein

From: BYUETIBM.BITNET!SEJ@talcott.harvard.edu
Date:         Sat, 14 Jan 89 16:31:06 MST
Subject:      Re: Undelivered mail
To: <encore!pinocchio!bzs@harvunxw.BITNET>
In-Reply-To:  Your message of Sat, 14 Jan 89 16:25:21 MST

>
>
>What's going on here? Why is this list receiving these Resent-From:'s
>which seem to be from you? Please explain.
>
>        -Barry Shein

They end up dropping into my system punch queue and I just want
someone to change the routing that they take!  I get alot of them
and don't want them anymore.


Steve Jackson


.
QUIT

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 10:55:44 GMT
From:      rob@inmos.co.UK (Robin Pickering)
To:        comp.protocols.tcp-ip
Subject:   Ethernet throughput


I realise that this is probably an often asked question, but I am trying to
build up some relative performance figures for LAN hardware/software
configurations.

Has anyone got a sensible (preferably experimentaly derived) figure
for performance of TCP/IP over Ethernet.

This is beginning to sound like a 'how long is a piece of string question',
so lets define it a bit better and say:
    Single ethernet segment, no bridges or routers
    10 Workstations running TCP/IP,UDP and NFS (Sun 3's say)
    Thick wire ethernet (if that makes a difference)

If anyone has any figures for another environment, I am just as interested
but please specify the environment.

Rob Pickering
JANET(UK): ROB@UK.CO.INMOS
ARPA:      rob@inmos.co.uk ( or rob%inmos.co.uk@nss.cs.ucl.ac.uk)
UUCP:      rob@inmos.co.uk (...uunet!mcvax!ukc!inmos!rob)

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 14:11:06 GMT
From:      steve@umiacs.UMD.EDU (Steven D. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re:  Reconciling /etc/hosts, yp, and named?


   It seems to me that the following combinations of DNS/YP/host table usage
are valid:

	1) You're using the domain name system.  In this case, *all* host
	lookups should go through the DNS.  The only exception here is that
	at boot time, you'll need to be able to fall back on the host table
	so that you can do a host name lookup to configure your network
	interface.  Other than that, you *never* fall back on the host
	tables, as host table information is out-of-date, wrong, and won't
	be around for too much longer.  I'd rather have no answer than a
	wrong one, though I suppose this is something of a religious issue.

	   Similarly, sendmail should do MX lookups, and do them through the
	DNS directly, with nothing serving as an intermediary.

	   This approach is always the right one, irrespective of whether or
	not you're also running YP.  Since YP has no concept of soft
	failures, there's no way for ypserv -i ever to work 100% correctly.
	And, after all, if you're using the DNS, your host information is
	all being served by a DNS server, and you have no need to keep
	duplicate host information around in YP.  (There may actually be a
	few exceptions to this in highly security-conscious environments,
	where perhaps the existence of some hosts is not to be advertised to
	the outside world.  I'm not sure how to handle those cases.  What do
	other people think?)


	2) You're not using the domain name system.  This breaks down into
	two cases:

		2A) You're also not using YP.  All lookups go to /etc/hosts.
		(Note that it's important for your customers to be able to
		purge YP entirely from their systems without causing any
		catastrophes.)

		2B) You're using YP.  Do whatever most other YP servers do
		in terms of falling back on host tables when necessary.


   I think that Sun is moving toward this approach.  It's possible to get
SunOS 4.0.1 C libraries that do host lookups through the DNS, and YP lookups
for everything else; they're available for anonymous FTP from uunet.  I
think they may come on the Sun distribution tapes in the future, though you
shouldn't take my word on that.  (Could someone from Sun confirm or deny
this rumor?)

   If you software follows these rules, is is my opinion that it will work
in accordance with the letter and spirit of the domain RFCs.  I'm sure that
others will (and, indeed, already have) beg to differ.  Does the Hosts
Requirements RFC have anything to say on this matter?

	-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

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 15:33:00 GMT
From:      hacke@MDC.COM
To:        comp.protocols.tcp-ip
Subject:   RE:      GOSIP

James:

GOSIP is now a FIPS: See FIBS PUB 145 - Government Open System Interconnection Profile (GOSIP)

Keith Hacke
hacke@mdc.com

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 15:37:00 GMT
From:      hunt@ENH.NBS.GOV ("CRAIG HUNT")
To:        comp.protocols.tcp-ip
Subject:   More Milnet routing problem

As I previously stated on these lists my computer is still having
problems receiving routes from milnet.  I recieved a few letters back
stating that other people are also seeing some problems.  In addition a
request was made that I supply more details about my specific problem. 
Here are the details: 

The computer is a Vax 8250 running VMS 4.7 and the Wollongong 3.2 TCP/IP
package.  We are connected to milnet IMP 19 on port 0 using standard
X.25 service over a 56 Kb line with an ACC ACP6250 interface on the Vax.
We upgraded to the lastest gated from Wollongong on December 20th. 

The routing problem started at the end of November and was intermittent
until installing the new gated on December 20th.  At that time the
routing problem appeared to go away but we continued to monitor the
routing table every day.  On Tuesday, January 10th the routing table
appeared ok but when the table was checked on Wednesady the 11th there
were no routes via milnet. Unfortunately we did not have tracing on for
gated.  The NOC and others were contacted to see if anything had changed
on the network or if others were reporting problems.  The night of the
11th the vax was rebooted with tracing on gated. The routes flowed in
from milnet but by the next morning there were no milnet routes in the
table. The trace was reviewed and showed that several routing update
packets were received from 26.1.0.40.  The last update was received at
22:51 on Wednesday the 11th.  The protocol continued to exchange hello/I
hear you messages and NR poll messages.  We would receive polls from
26.1.0.40 and send replies.  After three unanswered NR polls we dropped
26.1.0.40, acquired 26.1.0.65, sent 3 unanswered polls, acquired
26.3.0.75, sent 3 unanswered polls, acquired 26.1.0.40 ...  You get the
picture. We haven't received an update since Wednesday the 11th, despite
restarts and reboots. 

The problem does not appear to be related to any one core gateway because 
they all give the same result.  I suspected X.25 because we saw many 
errors on dda0, however on Friday the 13th (oh no!!) the NOC applied 3 
X.25 patches to our PSN and the errors on dda0 dropped to nothing. I 
contacted Wollongong on Friday after the NOC patches had no effect on 
the routing problem but have been unable to connect with anyone because 
of the holiday weekend.  I am now pursuing Mike Brescia's idea that the 
kernal code may need to be updated to supported the larger egp packet 
size in the same way that gated was updated.

If anyone out there has a TWG system which is successfully receiving EGP 
routing updates, please let me know how you are doing it.  Below are the 
EGP lines from my gated.conf.

Thanks for any help,
---Craig

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

#
# setup EGP configuration
#
autonomoussystem 49
egpmaxacquire   1
egpneighbor     26.1.0.40
egpneighbor     26.1.0.65
egpneighbor     26.3.0.75
#
#
egpnetsreachable 129.6.0.0 26.0.0.0

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 16:35:18 GMT
From:      GILBERT@YALEVM.BITNET (Howard Gilbert)
To:        comp.protocols.tcp-ip
Subject:   Re: Standard (RFC) for IP-over-SNA

Re: The question of an RFC for IP-over-SNA (which the current IBM TCP/IP
product supports.)  This is forwarded from the Bitnet-based discussion
list for the IBM TCP/IP product.

Mark Bodenstein
Cornell University

----------------------------Original message----------------------------
The current IBM LU 0 version of IP over SNA is not a suitable basis
for standardization.  It supports only mainframe to mainframe connections
and is based on what is now obsolete protocol.  What is needed is an
RFC for IP over LU 6.2 SNA based on a PU 2.1, APPN, or subarea
routing.  This would then define a protocol which every IBM device
from the PC to midrange to mainframe could use with or without the
presence of a mainframe.  The current LU 0 connection on the mainframe
would then migrate to APPCCMD or Common Program Interface-Communications
(CPI-C of SAA) to conform to this standard.

The transport of IP over APPC is fairly trivial.  Since there is no
broadcast in SNA, it is necessary to translate the subnet portion of
the IP address into an LU name.  Since APPC is half-duplex, it may be
necessary to run two parallel sessions.   Presumably you would flush
the buffer with every IP packet and never confirm. Mapped conversations
look appropriate.  I see no need for PIP data.  The rest is
fill-in-the-blanks.

Adding the SNA network as a supported subnet protocol to IP would
make TCP/IP more accessable in large commercial shops.  However, most
such organizations may not need internet access.  They need to connect
widely scattered internal non-IBM equipment across their existing
SNA wide area network which already ties all corporate locations
together.  As such they need a PC based SNA router in the remote
location which LU 0 cannot supply.  They probably cannot afford and
do not require a separate IP based communications link to the
mainframe or between the remote nodes given that the SNA links are
already in place and connect everyone.

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 17:13:45 GMT
From:      cwm@TWG.COM (Chris Moore)
To:        comp.protocols.tcp-ip
Subject:   Re: GOSIP


> I have been out of touch for a few months and need some info.  Can anyone tell
> me if GOSIP has been approved as a FIPS and when.  Thanks.

Yes, it has been approved and published.  My copy is dated August 24, 1988.  You
should be able to order it from NTIS as FIPS PUB 146.

  - Chris

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 18:45:17 GMT
From:      kappa!hd@rice.edu  (Hubert D.)
To:        tcp-ip@sri-nic.arpa
Subject:   callable ftp libraries - results
In November I requested info on "callable ftp libraries" in the public domain.

The conclusion garnished from the replies indicates the only option
available is to cull the necessary code from either NCSA telnet or Phil
Karn's KA9Q. 

Hubert Daugherty
======================
From dab@vax.ftp.com Tue Nov 22 15:08:46 1988
	Unfortunately, the TCP that's in the MIT/CMU package was designed
specifically for telnet.  It has certainly been used for other TCP based
applications, but one of the features that it doesn't have is the ability
to have more than one TCP connection.  Since FTP uses separate control and
data connections, life's a bitch.  To do an FTP requires that you first fix
the TCP.  Stanford took the MIT code many years back, made the TCP multiple
connection, and wrote an FTP for it.  I don't know where to get that code
though.  I suppose I could have missed that someone made the MIT/CMU TCP
multiple connection.  If so, then boy is my face red.

						David Bridgham
======================
From jsm@phoenix.princeton.edu Tue Nov 22 16:42:48 1988
	Try NCSA telnet, avail from zaphod.ncsa.uiuc.edu.  It has its
own drivers, to it can ride on top of the pc-ip package.  It includes
server ftp, so you can ftp back to the pc.  Versions exist for the mac
and the ibm-pc. 

I think there may be more pc-ip stuff on husc6.harvard.edu -- don't
know if ftp is there.

Also, the kaq70 (sp) tcp-ip package is similar to the mit-cmu package,
but includes ftp I think. I am trying to find it -- maybe there is
copy on simtel20.arpa.

	Hope this helps,
		Scott

======================
From SRA@xx.lcs.mit.edu Wed Nov 23 00:28:52 1988
	Just as a historical note.  As you may be aware, the MIT PC-IP code
was eventually taken into the commercial world by its original
authors.  They named their company after the first product in the
PC-TCP line that was a significant enhancement over the PD MIT code:
FTP Software.

The FTP spec is a real bear to completely implement, so don't be
surprised if you don't find anything....

--Rob
======================
From mfryba@phoenix.princeton.edu Sun Nov 27 18:16:12 1988
	I'm not sure this is what you mean, but have you tried NCSA Telnet/FTP?
I think it is vastly superior to either CMU or MIT implementations.

Marty Ryba (slave physics grad student)
They don't care if I exist, let alone what my opinions are!
==================================================================end.
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 18:50:41 GMT
From:      lane@DUPHY4.Drexel.Edu (Charles Lane)
To:        comp.protocols.tcp-ip
Subject:   SYNs that don't get ACKed

I've noticed that our mailer is getting a number of SYN
packets directed at it (~2/hr...from west coast hosts)
that it can never seem to ACK and get a connection going.

The sequence of events is like this (Us = 129.25.1.103, port 25, SMTP;
Them = CRVAX.SRI.COM)

Them:  SYN              SMTP server process starts, and:
                        Us: ACK SYN
....        about 1 min later   ...
Them:  SYN  (duplicate)
                        Us: ACK SYN

this repeats (retransmitted SYNs in, retransmitted ACK SYNs out)
until finally one (or both) get fed up and time out.

The best explanation that I can come up with is that the ACK SYN's
aren't getting back to CRVAX.  Could this be a routing problem?
We've observed this behaviour with a number of hosts, and the best
explanation we've thought of so far is that the packets are coming in
over a `good' route and going out over a `bad' route.

I'd appreciate any comments or suggestions.

                                --Charles Lane
                                lane@duphy4.drexel.edu
                                cel@cithex.caltech.edu
                                lane@duphy1.bitnet

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 21:02:47 GMT
From:      stewart@mitel.misemi (John Stewart)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Ethernet Address Question.



Help!

I need some help in registering my company for a block of Ethernet addresses.

Seemingly this was done a few years ago, before my time. The people who
did the registering have long since departed, and a letter sent to the 
Ethernet registration office mentioned in the VII specs was returned unopened.

So, how do I find out what our assigned block of addresses is, or how do I 
register for a new set?

My company's name and address is:

	Mitel Corporation,
	350 Legget Drive, P.O. Box 13089,
	Kanata, Ontario,
	Canada K2K 1X4.
	(613) 592-2122.


Thanks in advance for any help received.

John Stewart.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 89 22:28:17 GMT
From:      alden@sphere.mast.ohio-state.edu (Dave Alden)
To:        comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Working version of PHONE for Sun's (under SunOS 4.0)

Hello,
  I've hacked up phone so that it runs under SunOS 4.0 on sun-3's
and sun-4's (I haven't check to see if it triggers the "watchdog
reset" bug on the 4/110 under 4.0 - sorry).  You can retrieve it
via anonymous ftp to "sphere.mast.ohio-state.edu" (128.146.7.200)
and cd into pub/phone.  I've put both a sharfile (containing the
patches and version.c) and the new source in there.  The sharfile
is available both compressed and uncompressed, but the original
source is only available in compressed format.  It didn't have a
version number, so I created one, the original is called version
1.00 and my "fixed-up" version is called 1.01.
  If you find any bugs, I'd appreciate you letting me know - I would
like to keep this version as bugfree as possible.  I'm also thinking
about making some additions to it to improve it's usefulness.
----------------------------------------------------------------------------
 Dave Alden, System Programmer @ Department of Mathematics
 The Ohio State University; 231 W 18th Avenue, Columbus OH USA 43210
 Internet: alden@sphere.mast.ohio-state.edu
 UUCP:     ...!{att,pyramid,killer}!osu-cis!sphere.mast.ohio-state.edu!alden
 BITNET:   ALDEN@OHSTPY

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 89 00:36:06 GMT
From:      dxj@bridge2.3Com.Com (Dave Jordan)
To:        comp.protocols.tcp-ip
Subject:   Re: Bridge Communications Inc. terminal servers

In article <31176@tut.cis.ohio-state.edu> Tom Easterday <tom@cis.ohio-state.edu> writes:
>
>Is anyone out there running Bridge Communications Inc. terminal servers?
>
>We have some here and I would very much like to talk with someone else
>about some things.  Post a phone number to the net and I will call.
>Thanks in advance.
>
>
Hi Tom,

I'm a marketing engineer here at 3Com (formerly Bridge) who works with
the Comm Servers.  You can contact me with your questions or you can
phone our Customer Support Organization at (415)696-2099.

regards,

Dave Jordan
Sr. Marketing Engineer
3Com Corp.
Enterprise Systems Division
2081 N. Shoreline Blvd.
Mountain View, CA  95052-8145
(415)694-2871
UUCP:...!sun!bridge2!dxj

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 89 08:17:47 GMT
From:      steve@polyslo.CalPoly.EDU (Steve DeJarnett)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   BIND/Named question


	I posted this once before, but never got any responses (except for
a question), so I'm going to try it again.

	The question:  Should named, when the TTL of an address mapping goes 
to 0, go back out and get a confirmation of the address, or should it simply 
give the address as non-authoritative??

	As it stands now, we give out a non-authoritative answer, which the
network hardware interprets as an invalid address.  It appears that their
software wants a fully-authoritative answer before it will make the connection.
(The network hardware in question is Ungermann-Bass).

The people in charge of our network (which gets name service from us) claim
that we are giving out bogus information for addresses whose TTL has gone to
0.  They contend that if the TTL of the address has gone to 0 that named 
should check this address and reset its TTL (thus, theoretically making it
authoritative) before issuing the response.

	The software is BIND 4.8 running on a Pyramid 98x.  No other systems 
seem to be upset by this, but the UB NIU's want more solid confirmation (it
appears).

	Any comments, suggestions of references to find the answer, or 
(hopefully) straight answers?? (authoritative answers??  :-) 

	Thanks in advance,

-------------------------------------------------------------------------------
| Steve DeJarnett            | Smart Mailers -> steve@polyslo.CalPoly.EDU     |
| Computer Systems Lab       | Dumb Mailers  -> ..!ucbvax!voder!polyslo!steve |
| Cal Poly State Univ.       |------------------------------------------------|
| San Luis Obispo, CA  93407 | This quote currently under repair.             |
-------------------------------------------------------------------------------

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 89 13:41:28 GMT
From:      haven!aplcen!aplcomm!trn%aplcomm.jhuapl.edu@purdue.edu  (Tony Nardo)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: More Milnet routing problem
In article <8901170328.AA10051@ucbvax.Berkeley.EDU> hunt@ENH.NBS.GOV ("CRAIG HUNT") writes:
>As I previously stated on these lists my computer is still having
>problems receiving routes from milnet.  I recieved a few letters back
>stating that other people are also seeing some problems.  In addition a
>request was made that I supply more details about my specific problem. 
>Here are the details: 
>[details omitted]

May as well add to the detail level:

	Configuration:
		warper.jhuapl.edu (128.244.176.48), a Sun 4/110 running
		SunOS 4.0, which communicates thru the local APL gateway
		system aplvax.jhuapl.edu (26.2.0.102).

	Problem:
		I have quite frequently lost communications with various
		sites (in particular, two nodes at CMU) while in the middle
		of "ftp" or "telnet".  On the last few occasions, I have
		had a second window "pinging" the target remote site.  When
		the connection dies, "ping" reports:

		    36 bytes from 26.21.0.104: icmp_type = 3 (Dest unreachable)

		followed by some form of longword dump.  The most freqently
		occuring dump (side notes in "[]" are mine) is of the form:

		    x00: x45000024
		    x04: x1cb50000
		    x08: x08010000
		    x0c: x1a150068	[26.21.0.104]
		    x10: x80f4b030	[128.244.176.48]
		    x14: x030076d2
		    x18: x00000000
		    x1c: x45000054
		    x20: xe4390000
		    x24: xfd011cc5
		    x28: x80f4b030	[128.244.176.48]
		    x2c: x********	[hex value of target node]

		After some period ranging from a few minutes to a couple hours,
		"ping" eventually starts successfully polling again.  I have
		verified that the target systems were alive during the hiatus,
		but have yet to verify if the same can be said for those
		systems' local gateways.
 
I sent a shorter description of this problem description (sans longword dump)
to StJohns@beast.ddn.mil, but have yet to receive a message acknowledgement.

Hope this helps.
-------				----------------			-------
ARPA,	trn@aplcomm.jhuapl.edu,		UUCP:	{backbone!}mimsy!aplcomm!trn
BITNET:	trn@warper.jhuapl.edu

	    "Thank God I'm only watching the game, controlling it."
				"One Night In Bangkok" (_Chess_)
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 89 13:44:47 GMT
From:      eric@systech.uucp (Eric Lighthart)
To:        comp.protocols.tcp-ip
Subject:   IP on Arcnet?

I'm interested in finding an implementation of IP on top of the Arcnet
link protocol.  Have you seen/used/created one?  Please reply directly:

	Eric Lighthart, SW Dev. Mgr.
	Systech Corp., 6465 Nancy Ridge Dr., San Diego, CA, 92121
	(619) 453-7400 x 255
	systech!eric@{ucsd|uunet}
	...!{ucsd|uunet}!systech!eric

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 89 15:03:00 GMT
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        comp.protocols.tcp-ip
Subject:   Re: Bfly redirect problem


          We've had flip-flop redirects here, but only on one network.
We used to get them on ARPANET destined packets, but haven't in a while.
Looks like something is definitely wrong.  Anyways, here is a log of
redirects over the last three days (note this is over a weekend, so not
much traffic was probably going through):

Log >sc1>as_logs>net_log from 1989-01-14 09:51:27.453483 to 1989-01-17 09:50:19.428283

1989-01-14  Sat  est
12:48:25 5548177  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
12:48:26 5548179  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
12:48:33 5548183  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
12:48:34 5548185  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
12:48:35 5548188  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
12:48:35 5548190  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
12:48:36 5548192  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
12:48:36 5548194  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
12:48:36 5548196  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
12:48:37 5548199  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
12:48:37 5548201  1 ==
12:48:38 5548203  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
12:48:38 5548205  1 ==
12:48:38 5548207  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
12:48:39 5548209  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
12:48:39 5548211  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
12:48:41 5548213  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
12:48:41 5548215  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
12:48:42 5548217  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
12:48:43 5548219  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
12:48:43 5548221  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
12:48:44 5548223  1 ==
12:48:44 5548225  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
12:48:44 5548227  1 ==
12:48:44 5548229  1 ==
12:48:45 5548231  1 ==
12:48:45 5548233  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
12:48:45 5548236  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
12:48:46 5548238  1 ==
12:48:46 5548240  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
12:48:47 5548242  1 ==
12:48:47 5548245  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
12:48:47 5548247  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
12:48:48 5548249  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
13:02:14 5548258  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
13:02:15 5548260  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
13:02:31 5548266  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
13:33:30 5548315  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
13:33:31 5548317  1 ==
13:33:32 5548319  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
13:33:33 5548321  1 ==
13:33:33 5548323  1 ==
14:51:34 5548365  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
19:28:41 5548596  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
19:28:41 5548598  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
19:44:47 5548613  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
21:25:39 5548730  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
21:25:39 5548732  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.

1989-01-15  Sun  est
01:12:06 5548835  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
02:31:24 5548904  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
02:31:25 5548906  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
02:35:33 5548917  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.

1989-01-16  Mon  est
13:28:03 5550477  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
13:28:05 5550479  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
13:38:14 5550492  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
14:27:37 5550551  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
14:27:38 5550553  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
14:40:36 5550568  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
14:48:22 5550579  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
14:48:24 5550581  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
14:48:28 5550584  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
15:02:22 5550598  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
15:02:24 5550600  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
15:09:03 5550618  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
15:43:26 5550669  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
15:43:27 5550671  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
15:43:28 5550673  1 ==
15:43:34 5550677  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
15:52:45 5550688  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
15:52:45 5550690  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:51:52 5550744  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:51:53 5550746  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:51:54 5550748  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:51:54 5550750  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:51:54 5550752  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:51:56 5550755  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:51:56 5550757  1 ==
16:51:56 5550759  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:51:57 5550761  1 ==
16:51:57 5550763  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:51:58 5550766  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:51:58 5550768  1 ==
16:51:58 5550770  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:51:59 5550772  1 ==
16:51:59 5550774  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:52:01 5550777  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:52:01 5550779  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:52:02 5550781  1 ==
16:52:02 5550783  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:52:03 5550786  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:52:03 5550788  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:52:04 5550790  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:52:05 5550792  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:52:06 5550794  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:52:07 5550796  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:52:09 5550798  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:52:09 5550800  1 ==
16:52:09 5550802  1 ==
16:52:10 5550804  1 ==
16:52:10 5550806  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:52:10 5550808  1 ==
16:52:10 5550810  1 ==
16:52:10 5550812  1 ==
16:52:11 5550814  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:52:12 5550816  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:52:12 5550818  1 ==
16:52:12 5550820  1 ==
16:52:13 5550822  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:52:13 5550824  1 ==
16:52:13 5550826  1 ==
16:52:13 5550828  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:52:13 5550830  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:52:14 5550832  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:52:14 5550834  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:52:14 5550837  1 ==
16:52:15 5550839  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:52:15 5550841  1 ==
16:52:15 5550843  1 ==
16:52:16 5550846  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
16:52:18 5550848  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
16:52:19 5550850  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
16:52:20 5550852  1 ==
18:54:06 5550990  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
18:54:09 5550992  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
18:54:25 5550998  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
18:54:26 5551000  1 ==
18:54:26 5551002  1 ==
19:51:44 5551058  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
19:51:45 5551060  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
20:01:29 5551070  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
20:59:55 5551151  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
20:59:55 5551153  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
21:00:19 5551160  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
21:00:19 5551162  1 ==
23:07:39 5551282  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
23:07:42 5551284  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
23:16:14 5551297  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.

1989-01-17  Tue  est
02:04:13 5551439  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
02:04:13 5551441  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
02:32:53 5551464  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
02:49:29 5551479  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
02:49:30 5551481  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
02:57:00 5551501  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
02:57:02 5551503  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
02:57:03 5551505  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
02:57:04 5551507  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
02:57:04 5551509  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
02:57:04 5551511  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
02:57:05 5551514  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
02:57:05 5551516  1 ==
02:57:06 5551518  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
02:57:07 5551521  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
02:57:07 5551523  1 ==
02:57:07 5551525  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
02:57:08 5551527  1 ==
09:49:38 5551943  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
09:49:38 5551945  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
09:49:57 5551950  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
09:49:57 5551952  1 ==
09:49:57 5551955  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through AERONET-GW.ARPA by CAMBRIDGE-MB.DDN.MIL.
09:49:59 5551957  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
09:49:59 5551959  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.
09:50:01 5551961  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through MCLEAN-MB.DDN.MIL by AERONET-GW.ARPA.
09:50:03 5551963  1 in    icmp: Packet to LOUIE.UDEL.EDU redirected through CAMBRIDGE-MB.DDN.MIL by MCLEAN-MB.DDN.MIL.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 89 16:21:41 GMT
From:      cole@unix.SRI.COM (Susan Cole)
To:        comp.protocols.tcp-ip
Subject:   changing timeout for tcp connections?

Excuse me if this topic has been around -- I don't usually follow
this group.

Since December, our Arpanet connections are failing much more often than
they succeed, particularly to distant sites.  I am told that the
timeout for these connections is around 30 seconds, and ping reveals
round-trip times to be upwards of a minute.  Furthermore, there doesn't
seem to be any way to increase the timeouts if one doesn't have source
code for uucico, tn, etc.

Surely many brilliant people have come up with ways of dealing with
this situation (other than using long-distance phone calls for all
connections).  Would anyone care to share them?

Thanks - Susan


-- 
- Susan Cole

USENET:  ...!hplabs!sri-unix!cole
ARPA:    cole@unix.sri.com

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 89 17:11:07 GMT
From:      subbu@TOVE.UMD.EDU (MCV Subramaniam)
To:        comp.protocols.tcp-ip
Subject:   A TCP Bug?



Hi,

I am working with TCP/IP for HP UNIX systems. We seem to have hit upon a 
case in which TCP goes in an infinite loop. I am describing the case below:

Consider TCP_A and TCP_B communicating. TCP_B has dropped some data sent
from TCP_A. Suppose TCP_A has its state variables as : <snd_una,snd_nxt,
snd_max> as <100, 300, 300>. When the timer pops, a segment <100,200> is 
retransmitted (assuming that the segment size is 100--for simplicity). In
the meantime, TCP_B sends some data over to TCP_A. This data arrives after
the retransmission is done. At this stage, TCP_A has its state variables
as <100, 200, 300>. When TCP_A sends an ACK for the data, the sequence
number in the packet is going to be 200 (at least, 4.3BSD does this).

TCP_B, in the meanwhile has received the retransmitted data, and has 
updated its rcv_nxt to 300 (it had a hole in the reassembly queue). Now,
when the ACK from TCP_A comes in with a sequence number 200, it is 
dropped!

Now consider the scenario when both TCP_A and TCP_B have dropped each 
other's data, and have retransmitted at the same time. Both their acks are
going to be dropped, and counter ACKs are going to be generated for
both of them (In tcp_input(), control is tranferred to dropafterack!)

Thus there will only be these ACKs going back and forth, and no useful
work is done.

This is a rare possibility, but then it occured on one of our machines
(with the two TCPs being on the same machine) and caused our system
to hang. We have now found out that we got into such a situation
because of another bug (we were dropping packets unnecessarily), but
then this *can* happen in reality.

A possible workaround for this can be in the retransmit code, to
save the value of snd_nxt vbefore calling tcp_output(), and then
restore it on return. But then this has problems when communicating
with a TCP that does not have reassembly queues (performance problems
-- we have tried it out).

A better solution may be to put in a better (?) value of sequence number
in a pure ACK packet.

Do other flavors of TCP have this problem? Or is it only on 4.3?
I would be interested in getting comments in this regard.

Thanks.

-Subbu (subbu@hpindlm.hp.com)
(408)447-2693.

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 89 17:50:23 GMT
From:      rminnich@super.ORG (Ronald G Minnich)
To:        comp.protocols.tcp-ip
Subject:   Re: YP, /etc/hosts, domains

In article <MS-C.600902311.377401575.mrc@SUMEX-AIM.Stanford.EDU> mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin) writes:
>     In other words, I'd dearly love to turn YP off, if only I could get
>ordinary domain lookups working.  How do I do this?  Do I have to run a domain
>server too, just to get the resolver working?
well, i had this problem too. I have two possible solutions:
1) You got yp source? Then build a hot-wired ypbind/ypserv pair that only
   look at your machines IP address. Bingo, you have your own private servers,
   but the domain name is still the same as your networks (important for 
   lots of things). This works well here. 
2) No yp source? Set up your own yp domain, like crispin.org or something,
   but this is messier; you have to set domainname and all that and make
   sendmail work right. I don't like this approach too much. 
3) Fix up /etc/rc so that it does a ypset to your host, and have your
   own maps built for only your host, and get rid of all but the host.*
   maps. This gets messy too, and you have to keep making sure that 
   (1) only you and no one else binds to your host
   (2) you STAY bound to your host (ypbind will move you around as it 
       sees fit)

after messing with (1), (2), and (3), i stuck with (1). Note that there 
are several funny bugs in some ypservs (Ultrix comes to mind) so you have
to check out the source of your source. 
Specific example: yp uses dbm, not ndbm, but ypserv calls dbm_close when 
it switches maps (with a char * yet!!)(should be DBM *;found in xinu & ultrix)
Newest sun source shows it calling dbmclose, but still with a char * argument.
(dbmclose takes no arguments)
   If you want c-diffs for what i had to do here let me know. I am 
pretty sure Stanford has a source license, right :-)?
ron
rminnich@super.org
P.S. yp to me always seems to have been a good first cut, but i think
     it is time for another go at the whole problem. hesiod, anyone?

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 89 18:17:26 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address Question.

Ethernet (and other 802.2 type network) address assignment is now
done by the IEEE Standards office.  You have to get a "REQUEST FORM".
Try calling tehm at (212)-705-7960

Bill Westfield
cisco Systems.
-------

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 89 00:51:11 GMT
From:      TYSON@SRI-NIC.ARPA (Mabry Tyson)
To:        comp.protocols.tcp-ip
Subject:   Re: SYNs that don't get ACKed

>Date:     Mon, 16 Jan 89 13:50:41 EST
>From:     lane (Charles Lane) @ DUPHY4.Drexel.Edu
>Subject:  SYNs that don't get ACKed
>To:       tcp-ip @ DUPHY4.Drexel.Edu
 
>The best explanation that I can come up with is that the ACK SYN's
>aren't getting back to CRVAX.  Could this be a routing problem?
>We've observed this behaviour with a number of hosts, and the best
>explanation we've thought of so far is that the packets are coming in
>over a `good' route and going out over a `bad' route.


[Note, while I am at SRI, I don't have any control or direct access to 
CRVAX.SRI.COM or SRI-GW.ARPA.]

I looked into the problem of connecting between SRINET and DREXEL
today.  From IU.AI.SRI.COM (on the Arpanet directly), I could ping
129.25.1.103.  The response time was on the order of 1 to 4 seconds.
I set up another host (that is on SRINET) to go through the same
gateway that CRVAX.SRI.COM uses (SRI-GW.ARPA).  When I tried to ping
from there, I couldn't get through (and got a message from SRI-GW
indicating that destination was an unreachable network).

From IU, I found out that it was going through JVNCA.CSC.ORG to get to
DREXEL.  That immediately set off alarms for me as we had routing
problems to RUTGERS behind the same gateway a week or so earlier.

As I recall, on one day, our EGP info was that we should use JVNCB.CSC.ORG
to get to Rutgers but we couldn't get through.  If we changed it to
route through JVNCA, we got through.  (On the previous day, the problem
was exactly reversed: EGP told us to use JVNCA but packets to it didn't
work while JVNCB did work.)  At that time, JVNCB had an arpanet
address (according to domain info) of 10.18.0.16.  Now when I look up
that host, it no longer shows an Arpanet address.

I don't know what route SRI-GW.ARPA is using to get to DREXEL.  Maybe it,
or the gateway it routes to still, thinks it should try JVNCB.CSC.ORG
(on the old(?) Arpanet address)???  I suspect the situation with the JVNCnet
is in flux and you should be patient with it for awhile.

P.S.  FYI: The network configuration at SRI will be changing beginning
on Feb. 11.  I think SRI-NIC.ARPA will be basically unaffected but
network connectivity to all other hosts at SRI may encounter problems.
SRI will be available through BARRNET (part of NSFNet) when the
Arpanet dies (which looks like it will be sooner than I think it
should be!) but it isn't yet set up.
-------

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Jan 89 11:54:36 -0500
From:      jchao@BBN.COM
To:        "John G. Ata" <Ata@radc-multics.arpa>
Cc:        "Timothy G. Smith (Systems Staff)" <tsmith@cad.usna.mil>, brescia@BBN.COM, tcp-ip@sri-nic.arpa, jchao@BBN.COM, mb-transition@BBN.COM
Subject:   Re: Bfly redirect problem
Tim and Jim 

Thank you for reporting and forwarding the redirects log. 
We are trying to understand the problem and hope to resolve it 
soon.  To help us track down the problem we would appreciate 
it very much if you could in the future include in the log the 
source and destination IP addresses of the original packets 
(if they are readily available).  It would also be extra nice 
if a short description or a simple diagram be included in the
msg showing how your host/gw is connected to Arpanet/Milnet/Internet.  

We suspect a possible configuration problem on the reston-dcec-mb.ddn.mil
gateway (10.6.0.20, 26.21.0.104) and we have temporarily turned 
loadsharing off for that gatewayw.  This should solve the looping redirects 
between reston-dcec-mb.ddn.mil and mclean-mb.ddn.mil as reported by Tim 
for now. We are studying John's report.  It may be a transition problem 
related to LSI11 GGP extrap hop and interaction between
ICMP net redirects from Butterfly Mailbridges (loadsharing) 
and ICMP net redirects from LSI11 EGP servers.

Please cc future msgs to mb-transition@BBN.COM.  Thank you for your 
assistence and cooperation.

John Chao
BBNCC Gateway Development

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 89 06:44:34 GMT
From:      Gene.Hastings@BOOLE.ECE.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   SRI on Barrnet? (Was: Re: SYNs that don't get ACKed)

Will SRI-NIC have an address that is not on net 10 or net 26?

Gene

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Jan 89 17:35:23 PST
From:      cire|eric <cire@cisco.com>
To:        agate!bionet!lear@ucbvax.Berkeley.EDU (Eliot Lear)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: SYNs that don't get ACKed

There was a slight communications problem.  Seems that
a change was requested that caused a name to change
instead of addresses changing.  So what happened was
there were two nodes that had the address 10.18.0.16,
JVNCB.CSC.ORG and FORD.CSC.ORG.  The later is a 
cisco box that indeed is connected to the ARPAnet.

I know all of this because Bob A. from JVNC was out today
visiting cisco and we happened to talk about it.  He
is working with the appropriate people to get this fixed.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 89 10:17:38 GMT
From:      sw0l+@ANDREW.CMU.EDU ("Steven L. Waldbusser")
To:        comp.protocols.tcp-ip
Subject:   CMU SNMP Distribution Available


  I am now releasing CMU's SNMP Distribution.  The following (from the README
file) explains it all.

  The files in this directory compromise the 0.9 release of the CMU SNMP
distribution.  This includes the SNMP/ASN.1 library, several client
applications, an SNMP agent, and supporting documentation.

This code was written with efficiency and portability in mind.  The
applications compile and run on the following systems: IBM PC/RT running ACIS
Release 3, Sun3/50 running SUNOS 3.5, and the DEC microVax running Ultrix 2.2.
They are expected to run on any system with a Berkeley socket interface.

The agent compiles into about 10 KB of 68000 code.  This distribution includes
a full agent that runs on a Kinetics FastPath2/3/4, and is built into the KIP
appletalk/ethernet gateway.  The machine independent portions of this agent
also run on CMU's IBM PC/AT based router.

The applications are designed to be useful in the real world.  Snmpstatus
collects several pieces of information and presents them in a useful format
and is good for everyday status monitoring.  The rest of the tools are simpler,
but still interpret input and output symbolicly (they can be used without
referencing the RFC's!).
For instance, snmpstatus returns:
[128.2.56.220]=>[Kinetics Fastpath2] Up: 1 day, 4:43:31
Recv/Trans packets - Interface: 262874/39867 | IP 47432/34587

The rest of the applications typically present a variable in a form similar
to the following:
Name: interfaces.ifTable.ifEntry.ifType.1
INTEGER: ethernet-csmacd(6)

For further information, please consult the man pages.

This distribution is coprighted by CMU, but may be use and sold without
permission.  Consult the copyright notices for further information.

The distribution is available by anonymous FTP from the host
lancaster.andrew.cmu.edu (128.2.13.21) as the files pub/cmu-snmp.9.tar, and
pub/kip-snmp.9.tar.  The former includes the libraries and the applications,
and the latter is the KIP SNMP agent.

Please direct questions, comments, and bug reports to sw0l+snmp@andrew.cmu.edu.

There is a gateway at CMU running the agent.  Feel free to query it.  You
can access as netdev-kbox.cc.cmu.edu (128.2.56.220) with community name
"public".


Steve Waldbusser
Network Development
Carnegie-Mellon University

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 89 16:54:36 GMT
From:      jchao@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Bfly redirect problem

Tim and Jim 

Thank you for reporting and forwarding the redirects log. 
We are trying to understand the problem and hope to resolve it 
soon.  To help us track down the problem we would appreciate 
it very much if you could in the future include in the log the 
source and destination IP addresses of the original packets 
(if they are readily available).  It would also be extra nice 
if a short description or a simple diagram be included in the
msg showing how your host/gw is connected to Arpanet/Milnet/Internet.  

We suspect a possible configuration problem on the reston-dcec-mb.ddn.mil
gateway (10.6.0.20, 26.21.0.104) and we have temporarily turned 
loadsharing off for that gatewayw.  This should solve the looping redirects 
between reston-dcec-mb.ddn.mil and mclean-mb.ddn.mil as reported by Tim 
for now. We are studying John's report.  It may be a transition problem 
related to LSI11 GGP extrap hop and interaction between
ICMP net redirects from Butterfly Mailbridges (loadsharing) 
and ICMP net redirects from LSI11 EGP servers.

Please cc future msgs to mb-transition@BBN.COM.  Thank you for your 
assistence and cooperation.

John Chao
BBNCC Gateway Development

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 89 18:28:23 GMT
From:      mann@SPAM.ISTC.SRI.COM (Dale Mann)
To:        comp.protocols.tcp-ip
Subject:   Re:  SRI-NIC address

SRI-NIC address's will not change with the restructuring of the network
here at SRI.

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 89 21:36:06 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip
Subject:   Re: SYNs that don't get ACKed

Yes, since around December, 10.18.0.16 has been a black hole for
packets.  Looking at my ARPANET routing tables even now, I see that it
is still my only ARPANET route to Rutgers.  One problem that I believe
we faced was the instability of this gateway, or so it seemed.

Regarding what JVNCB is, I know JVNCB to be a Vax.  When I telnet to
10.18.0.16, I get connected to a Cisco box.  As of today, I also see
that the host information agrees with me.
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 89 21:38:59 GMT
From:      KLH@SRI-NIC.ARPA (Ken Harrenstien)
To:        comp.protocols.tcp-ip
Subject:   Re: SRI on Barrnet?

SRI-NIC's addresses (26.0.0.73 and 10.0.0.51) are not changing.
Strictly speaking, the NIC machine is not owned by SRI, and this will
be emphasized when its official name becomes NIC.DDN.MIL as part of the
overall transition to domain names.  (It's already a recognized nickname.)

Of course, someday NIC.DDN.MIL may be moved behind a gateway, but if
this happens we will definitely publicize it well in advance as widely
as possible, so don't worry.

--Ken
-------

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 89 01:35:23 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: SYNs that don't get ACKed


There was a slight communications problem.  Seems that
a change was requested that caused a name to change
instead of addresses changing.  So what happened was
there were two nodes that had the address 10.18.0.16,
JVNCB.CSC.ORG and FORD.CSC.ORG.  The later is a 
cisco box that indeed is connected to the ARPAnet.

I know all of this because Bob A. from JVNC was out today
visiting cisco and we happened to talk about it.  He
is working with the appropriate people to get this fixed.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 89 14:11:20 GMT
From:      prc@maxim.ERBE.SE (Robert Claeson)
To:        comp.protocols.tcp-ip
Subject:   Tektronix emulating TELNET that works with Sun's PC-NFS?

I'm looking for a TELNET that emulates at least Tek 4014 but preferrably
Tek 4105 or 4107. It has to work with Sun's PC-NFS (rev 3.0). Any help
appreciated.

Thanks,

Robert
-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
"No problems." -- Alf
Tel: +46 758-202 50  EUnet:    rclaeson@ERBE.SE  uucp:   uunet!erbe.se!rclaeson
Fax: +46 758-197 20  Internet: rclaeson@ERBE.SE  BITNET: rclaeson@ERBE.SE

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 89 21:57:33 GMT
From:      craig@CWH.CAM.NBS.GOV (Craig Hunt)
To:        comp.protocols.tcp-ip
Subject:   Re: More Milnet routing problem

The milnet routing problem I reported earlier on this list may be
largely resolved. (Note my caution. Overconfidence tripped me up
before.)  If progress has been made it has largely been the
result of advice I received on this list and the help of
Wollongong support staff.  The version of gated which Wollongong
is currently providing resolved the problem I had with receiving
routing updates.  The updates began to flow which moved us to
a new phase of the problem.

In the second phase of the problem we noted that the size of the
routing table varied widely.  By looking at the egp trace we
determined that if we aqiured different neighbors we got very
different routing updates.  We were still using the old LSI-11
gateways so we "re-homed" to the BMB gateways.  This was done this
morning and so far, so good.  We seem to have complete routing
tables and to be keeping them.

Wish us luck.

---Craig 

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 89 23:27:01 GMT
From:      shaver@atanasoff.cs.iastate.edu (Dave Shaver)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Looking for information on LAN terminal servers (dumb host <=> LAN)

We have one host here in the department that we can't hookup to our
LAN.  (Our LAN consists mostly of VAXen, Suns, etc).  One solution we
have come up with is to purchase a LAN terminal server and hook the
ports on it to this non-LANed host.

We'd like to be able to use telnet to connect to these ports connected
to the terminal server.  The server would translate the telnet session
to the host via the serial ports.  Thus, on the LAN side, it looks like
a normal telnet session.  On the host side, it looks like a normal
hard-wired terminal session.

We plan to one day junk this host, so we'd like to have the option of
hooking up normal ASCII terminals to this server at a later time.  The
idea being that users could sit at the server and give the (IP) address
of the host they want to talk with and it would start a telnet
session.  (I assume this is the original intent of most ``terminal
servers'' out there.)  Thus, if possible, this server must do
bidirectional telnet sessions.

So, enough background.  There are several companies that make boxes
somewhat like this.  We're looking for comments on ANY terminal
servers.  Good, bad, or otherwise.  We're also open to other ideas on
how to get this host onto the LAN.  If the box doesn't speak telnet,
we'd also be open to anything else.

Please MAIL responses and I'll summarize for the net.  Thanks in
advance for your time and comments/ideas.  (Please let me know in your
mail if I may include your name in the summary.)

				Cheers,

/\  Dave Shaver  -=*=-  CS Systems Support Group, Iowa State University
\\  UUCP:  {hplabs!hp-lsd,uunet!umix!sharkey}!atanasoff!shaver
\/  Internet: shaver@atanasoff.cs.iastate.edu

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 89 01:05:28 GMT
From:      jumbo!jdd@decwrl.dec.com  (John DeTreville)
To:        tcp-ip@sri-nic.arpa
Subject:   Time to port Berkeley TCP/IP?
Can anyone help estimate how long a port of of the Berkeley TCP/IP
software would take to a non-Unix operating system?

The port would be to an operating system used locally that is not Unix,
that does not resemble Unix at all internally, but whose system call
interface is a superset of 4.2BSD.  Therefore, I imagine that the
difficulty would lie in porting the Berkeley kernel support.

Has anyone ever done such a port, or can anyone estimate the difficulty?
(It obviously depends on the details of our operating system; assume for
starters that it has a reasonably flexible environment internally.)

I'd appreciate any responses, comments, or advice.

Cheers,
John DeTreville
DEC SRC, Palo Alto
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 89 06:46:07 GMT
From:      idall@augean.OZ (Ian Dall)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for Sys V.2.2


Is there available a version of TCP-IP and or SLIP that can be added
to a vanilla SysV.2.2? There may not ever be Sys V.3 for this machine.
This is for a binary only site but there would be no problems in
adding pseudo drivers and or real drivers if that is the way to
impliment it. Adding extra system calls would probably be too
difficult but if there are any implimentations done like that they
might be of interest.

Naturally  a public domain solution would be preferred but otherwise
I would be prepared to pay (but not a lot).

Sorry if this is a silly or impossible request!

Thanks in advance.

-- 
 Ian Dall           life (n). A sexually transmitted disease which afflicts
                              some people more severely than others.
idall@augean.oz

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 89 15:31:23 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Reverse Path Forwarding (or broadcasting with subnets)


We are in the process of porting a proprietary PC networking 
system to an IP based system. One of the thing we would like to
do is use IP routers to forward broadcast messages to "all nodes"
of our network. We are defining "all nodes" to be "all systems
on my (subnetted) network". When a node broadcasts to the network address,
RFC922 states that routers should forward this broadcast to all
applicible networks. In other words, the broadcast 36.255.255.255
should reach all members of (subnetted) network 36, whether
they live on the same ethernet cable as the broadcaster or not.


I have noticed that some routers do not implement the 
algorithm (Reverse Path Forwarding) that allows this to happen.

Does anyone know of an implementation 
that does reverse path forwarding?


Bill VerSteeg
DCA
1000 Alderman Drive
Alpharetta Ga. 30201

P.S. To the vendor to which I have been talking about this problem-
     Notice how nice I was here and didn't shamelessly rake you over 
     the coals in public. Wasn't that nice?

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 89 19:22:13 GMT
From:      stewart@mitel.misemi (John Stewart)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Ethernet address info thanks.


Thanks to all those who responded to my question concerning the 
application for a block of ethernet addresses for manufacturers.
I have included the final information here for those who are interested.

Rumor has it that we had a block assigned to us well before my time,
with nobody able to find the documentation. So...

10 points to those people who gave me the following name and address:

  Mr. Vincent Condello          Telephone: (212) 705-7960
  IEEE Standards Office                    (212) 705-7092
  345 E. 47th Street
  New York, NY 10017

I phoned, and was given the phone number (201) 562-3812, so I guess
the offices have moved lately. I left my name and number. Lo and behold,
the next day I got a call from the office, they had looked up our 
company name (Mitel), found it, and had the information sitting in front
of them. A quick note on my companys letterhead was all that I needed
to get a copy of this information. 

Thanks!

John Stewart.
Computer Internetworking Manager,
Mitel Corp.

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 89 00:03:46 GMT
From:      polyof!john@nyu.edu  ( John Buck )
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Time to port Berkeley TCP/IP?
In article <13523@jumbo.dec.com>, jdd@jumbo.dec.com (John DeTreville) writes:
> Can anyone help estimate how long a port of of the Berkeley TCP/IP
> software would take to a non-Unix operating system?
> The port would be to an operating system used locally that is not Unix,
> that does not resemble Unix at all internally, but whose system call
> interface is a superset of 4.2BSD.
> John DeTreville


Having transplanted 4.3 (very similary to 4.2) BSD networking into System
5 release 3.1, I think I can shed some light on what is involved.

The ip, tcp, udp stuff is pretty staight forward, but it all relies
on the "mbuf" memory allocator and sockets.

The operating system you are porting to should have some scheme for
dynamically allocating kernel data space.  If it doesn't, then you will
have to devise a scheme.  (IE allocate a big array, set a network data
usage limit, and sub-divide the array yourself).

The "socket" code is also straight forward to port (it doesn't use much
Unix support -- it's self containted).

The only problem you will run into is probably the Unix Domain sockets.
(IE sockets connected to names in your filesystem.)  If you don't care
about them, forget them.  (I think the only thing that really uses
them is the "lpd - line printer spooler", which can easily be re-written
to not use them.)

You will also need to write an physical device driver for whatever hardware
transport (physical layer) you are using.  If it's ethernet, then you'll
need special read, write, ioctl, init routines.  If you already have
a driver (source code) for the hardware, adding the necessary hooks should
not be too difficult.

Oh, yes, I hope you have a good C compiler, or you'll be coding some
things in assembler... bcopy, bcmp, in_cksum, etc. etc.

John Buck
john@polyof.poly.edu
john@polygraf.bitnet
trixie!polyof!john
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 89 02:48:13 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Reverse Path Forwarding (or broadcasting with subnets)

As far as I know, cisco routers (the only ones I know in detail) do
not implement RFC922 (reverse path forwarding for broadcasts).  If
they did, I would disable it.  There are two many machines that still
don't know about subnets.  Thus it is very hard to know when a host
really wants a site-wide broadcast as compared to one on the local
subnet.  I also think 922 may be overly optimistic about preventing
loops.  But this is just a guess.  At any rate, I think if you want to
do a wide-area broadcast, you should be looking at IP multicasting,
not at network-wide broadcasts.  Multicasting is still viewed as
experimental, and is not widely implemented.  However I think you'd
stand a much greater chance of getting router vendors to implement
that than the RFC 922 scheme.  On the other hand, if I were doing a
product which I wanted to sell to people other than network wizards
(i.e. people whose network contains systems may be a year or two
behind the latest proposals), I'd not assume any kind of broadcasting
outside of the local physical network.  Also, beware of the various
odd configurations that people sometimes create, such as multiple
networks or subnets on a single cable.

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 89 13:30:14 GMT
From:      wrd3156@fedeva.UUCP (Bill Daniels)
To:        comp.protocols.tcp-ip
Subject:   Beginner Questions

I am new to the world of high-speed networking with Ethernet/tcp-ip and have a
few questions.  Most of my concerns are due to an inability to reconcile the
high speed local area net with remote internet connections.  I am planning
one network for our development work and yet another net for production
work.  I would also like to be able to finally make use of the multitude of
postings offering access to various archive sites through anonymous ftp.

(1) From my brief encounters with the Ultrix Networking manuals, I have a 
pretty good understanding of how a local network is set up and have actually
connected two uVaxen by means of an ethernet.  How does one establish
themselves as an internet node, electrically/mechanically that is? (I have
already asked for an internet address.)

(2) Since ftp works locally over an ethernet using tcp-ip, how does an
anonymous ftp connect to a remote site (analogous to uucp dialups)?
Does it tcp-ip over dial-ups?  

(3) How does one rlogin or telnet to a host on a remote network?  What 
advantage does this have over tip/cu?

I am sure that responses to these questions will generate even more questions
from me.  I do appreciate any help you might be able to give me.

-- 
bill daniels
federal express, memphis, tn
{hplabs!csun,gatech!emcard,mit-eddie!premise}!fedeva!wrd3156

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 89 15:06:16 GMT
From:      ron@hardees.rutgers.edu (Ron Natalie)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for information on LAN terminal servers (dumb host <=> LAN)

I'd recommend CISCO for the "milking machine" application.  We have a
CPU (it's a COMTEN front end to an IBM) that is a real bear.  Chuck Hedrick
spent a lot of time fine tuning the telnet server in the CISCO to make it
work well when milking.  In addition, he's put out some new TELNET options
to make milking more palatable when going from TERMINAL->SERVER->TERMINAL.

Configuring of the lines on the Cisco is straight forward and the modem
control signals are handled properly so that when the host hangs up the
connection goes away and when the connection goes away the host sees
"carrier" drop.  Cisco also allows a rotary to be bound to a different
address than the server so you can treat the rotary as a host in itself
rather than having to telnet to the server and then select or using funny
TCP ports.

-Ron

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 89 17:14:01 GMT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   JVNCnet information

<<<<< Long >>>>>

Folks,

In order to clarify some questions about JVNCB and Ford, I attach the
current configuration of the JVNCnet network.  The JVNCnet network has
been and still is in the process of a complete upgrade.  We appologize
for any inconvenience that are the effect of this upgrade.  We have in 
the past, and are committed in the future to provide the best service 
possible.

1.) Current configuration:

1.a) Number of gateways:

	Cisco routers		17
	VAXs			13
	UB routers		 6
				--
				36

1.b) Number of communication links:

	T1 lines:		 9
	56kbps lines:		13
	Satellite links:	 3
	Others (fiber/ether):	 1

1.c) Routing protocols:
	IGP:	RIP and IGRP

1.d) External national and international networks:

	Arpanet (connected to a VAX8600, JVNCA, and to a Cisco router,
		Ford).
	NSFnet (NSS8).
	NORDUnet (connected via Cisco router)
	JANET (scheduled to be connected to Cisco router)

1.e) Other means of access:

	Bitnet (via JVNCC.CSC.ORG)
	Telenet
	Dial-in

1.f) Total traffic matrix for the month of December:

	Total number of packets in and out:		531,787,838

	Percent of traffic in and out of NSFnet:	22.32%
	Percent of traffic in and out of ARPANET:	 3.36%
	Percent of traffic in and out of JVNCnet (internal): 74.32%

	Traffic is sampled once a day from each gateway and stored in
	database.  Note that the amount of traffic, not only internal
	but within the NSFnet system too (not shown here) is one of
	the most actively used regional networks.

1.g) Hours of operation:
	24 hours/ 7 days a week

1.h) Topology:


		connection to NORDUnet@Sweden
		|
		|
		Trillian	Arthur		JVNCB	JVNC-Siemens
		Cisco		Cisco		VAX	Cisco
		|		|		|	|
		|		|		|	|
 ================================================== Ethernet, 128.121.50
		|	    |		  |	|
		|	 JVNCA		  |	|
		|	 VAX		  |	JVNC-njit (UB)
		|	    |		  |
		FORD-------PSN16- - - -	ZAPHOD
		Cisco			Cisco
		|			  |
		|			  |
		|			  |
 ================================================ Ethernet, 128.121.54
		|		  |
		NSFnet		
		NSS8		  |
				JVNC-janet- - -> connection to JANET/UK


	JVNCA----> Rutgers, U. of Penn., IAS, MIT (4 T1 lines)
	JVNCB----> NYU, Penn State ( 2 T1 lines)
	Arthur---> Directly connected: Yale, UMASS (2 56kbps lines)
		   In a ring: All 56kbps lines except Brown-MIT
			      MIT to Harvard, and MIT to JVNC

				T1 line
			  |---------------------------|
			  |			  T1  | T1
			JVNC-Yale-Wesleyan-Brown----MIT-----Harvard
			|			             |
			|			             |
 UMASS-Northeastern-BostonU-----------|
				|
				Dartmouth

	Trillian---> Nordunet, Columbia, Montclair State, Princeton
		     ( 3 56kbps lines, 1 T1 ).

	JVNC-Siemens-> Scheduled for connection Jan89.
			Connected on a Fiber link, with ethernet modems.
	JVNC-NJIT--> NJIT, Stevens, UMDNJ (56kbps lines).

2.) Scheduled changes:

The following are estimated dates for up coming upgrades.

First week of February:

	* JVNCA connection to the PSN changing to ZAPHOD.

First week of March:

	* Rutgers, NJIT, UMDNJ and Stevens Tech, re-connected using 
	  Cisco routers.

Early February:

	* Connection to JANET.

Early March:

	* Re-connect Nordunet to another Cisco router.

There will be more changes to the network topology.  Stay tunned.


					-- Sergio


PS: for more information about the JVNCnet network send mail to:
	"JVNCnet-nic@jvnca.csc.org"

    for operational problems send mail to:
	"JVNCnet-noc@jvnca.csc.org"

    Or contact (609) 520-2000, Network Operations.



-----------------------------------------------------------------------------
Sergio Heker				tel:	(609) 520-2000
Internet: "heker@jvnca.csc.org"		Bitnet:	"heker@jvnc"
JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager
-----------------------------------------------------------------------------

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 89 19:02:42 GMT
From:      jkp@cs.hut.fi (Jyrki Kuoppala)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP for an Altos 2086 (and 3068)

In article <176@lilink.UUCP>, root@lilink (The Super User) writes:
>
>As far as I know Altos itself does not support TCP-IP on ANY of its machines.
>Ditto for RFS. This includes 386/2000's of which we have 1. I have contacted
>Altos on this and I have been getting "real soon now...." for the last several
>months. However that is only for the 386/2000 box. If you have a
>286 based box I think you are out in the cold (as I am). 
>
>Third party vendors may have  addressed this problem already but I have
>found none. If anyone knows of such an implimentation for ANY Altos machine
>I for one would like to hear from them.

We have three Altos 3068 machines here running SVR2.2 with Excelan
Ethernet card and TCP/IP software.  We've been told that by Excelan
that the software was ported by Altos.  However, Altos doesn't support
the Excelan product anymore and we have been unable to get even the
unlinked device driver object files for the Excelan card.

As the 3068 is a Motorola-based system, I don't know if the Excelan
solution is available for intel-based systems.

The Excelan TCP/IP library isn't very compatible with anything (I've
heard that it resembles 4.1 BSD somewhat).  However, it should be
possible to make a library of your own which would be very much like
the BSD 4.3 socket library; there are no system calls involved, the
sockets are used as devices.  I have decompiled the socket() etc.
calls back to C, and the rhost() and the like should probably be
replaced with gethostbyname() from 4.3BSD.

If someone other still has these 3068 machines w/ Excelan still lying
around, we have at least finger server / client and the
open-network-stream function to emacs done here, which I could
probably put for anonymous ftp if someone's interested.

If someone from Altos is listening, we'd be very interested to have
the Excelan TCP/IP software device drivers so we could get a newer
kernel in use (we have source for a newer one, but we can't use it
'cause we don't have the unlinked drivers).

>Michael R. Johnston
>System Administrator   {..!philabs!mergvax! | ..!uunet!ispi!} lilink!mikej
>LILINK - Public Access Xenix   (516) 872-2137  1200/2400 8N1  Login: new
-- 
Jyrki Kuoppala    Helsinki University of Technology, Finland.
Internet :        jkp@cs.hut.fi jkp%finhut.bitnet@cunyvm.cuny.edu
BITNET :          jkp@finhut.bitnet        Gravity is a myth, the Earth sucks!

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jan 89 10:09:56 -0800
From:      bostic%okeeffe.Berkeley.EDU@ucbvax.Berkeley.EDU (Keith Bostic)
To:        tcp-ip@sri-nic.arpa
Subject:   V1.76 (new version of sendmail available)
Subject: new version of sendmail available
Index: usr.lib/sendmail 4.3BSD-tahoe

A new version of sendmail is now available on ucbarpa.berkeley.edu, in
~ftp/4.3/sendmail.tar.Z.  This version fixes all of the security problems
that we are aware of as well as having several minor cleanups.  A faster
and cleaner version of rmail is also provided as well as new, name server
oriented configuration files.  If you have any problems with it, contact me.

Keith Bostic
bostic@okeeffe.berkeley.edu
uunet!bostic
415-642-4948

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 89 04:06:03 GMT
From:      lhl@CS.WISC.EDU (L.H. Landweber)
To:        comp.protocols.tcp-ip
Subject:   sigcomm '89


                      CALL FOR PAPERS
                 ACM SIGCOMM '89 SYMPOSIUM
         Communications Architectures and Protocols
                       Austin, Texas
                   September 20-22, 1989
                 (Tutorials September 19th)

The  symposium  provides  an  international  forum  for  the
presentation  and discussion of communication network appli-
cations and technologies, as well  as  recent  advances  and
proposals  on  communication architectures, protocols, algo-
rithms, and performance models.  Authors are invited to sub-
mit  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, distri-
buted operating systems and databases,  protocol  specifica-
tion, 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 accepted papers
will be expected to sign an ACM copyright release form.  The
Proceedings  will  be  distributed at the symposium and pub-
lished 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.
Mohamed  Gouda,  Computer Sciences Department, University of
Texas at Austin, Austin  TX  78712,  USA;  Telephone:  (512)
471-9532; EMAIL: gouda@cs.utexas.edu

For more information about the symposium, contact  Dr.  L.H.
Landweber,  General  Chair, Computer Sciences Dept., Univer-
sity of Wisconsin, 1210 W. Dayton St.,  Madison,  WI  53706;
Tel: (608) 262-1204; EMAIL: landweber@cs.wisc.edu.

                    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 US dollars.

                      IMPORTANT DATES

Deadline for paper submission: March 20, 1989
Notification of acceptance:  May 19, 1989
Camera-ready manuscript due: June 19, 1989

                    SYMPOSIUM COMMITTEE

General Chair:  L.H. Landweber, University of Wisconsin, USA
Program Chair:  M. Gouda, University of Texas, USA
Local Arrangements: M. Gouda, University of Texas, USA

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jan 89 16:01:00 -0500
From:      Andy Malis <malis@BBN.COM>
To:        Terry Slattery (SECAD) <tcs@brl.mil>
Cc:        tcp-ip@sri-nic.arpa, lkoke@brl.mil, eskimo@brl.mil, malis@BBN.COM
Subject:   Re: PSN weirdness
Terry,

I haven't seen a follow-up on the TCP-IP list since your original
message (I just got back from vacation) and I'm curious if you
are still experiencing the problem with ARDEC.ARPA.  I have a
ping running right now and the average time is running around 380
ms.  I'm getting about the same average for 26.0.0.45 as well
(this is through two gateways between the BBN internal net and
the MILNET).

Experiencing a longer round trip time for the first ping or two
is to be expected; the PSNs are in the process of setting up a
subnet end-to-end virtual circuit.  Once the connection has been
established, data flows.

The behavior you described (two hosts at the same PSN having
widely differing operating characteristics) usually points to
problems with an individual host: either a problem in the host
itself, or a hardware problem with its access line or port (on
either end of the line).

The folks at the CONUS NOC are usually very good at solving this
sort of problem, and are assisted by development folks up here in
Cambridge when necessary.  I suggest giving them another try if
this is still an ongoing problem.  If that fails, mail to tcp-ip
certainly gets attention, since it is read by both folks at the
DDN PMO and in BBNCC.

Regards,
Andy Malis
Manager, BBNCC PSN Development Support
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 89 17:37:04 GMT
From:      jpe@romeo.cs.duke.edu (John P. Eisenmenger)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: VERY strange behavior at USENET/BITNET gateway

In article <8901151801.AA12681@ucbvax.Berkeley.EDU> NJG@CORNELLA.CIT.CORNELL.EDU (Nick Gimbrone) writes:
>>> Something which happens (at least with UREP) is that files coming
>>> in from BITNET-land have lines which are supposed to be truly
>>> empty instead contain some number of blanks.  You would think this
>>Perhaps some of you would take a hand in convincing IBM that an
>>empty line should exist.
>This is not an IBM problem. The IBM software has no problem treating
>the line of blanks as a "null line". In this case it sounds more like
>a UREP problem.

It is a UREP problem.  If I remember correctly (though I never handled
mail with UREP -- just batch jobs, plus I'm now at a different site)
files come in using Fortran Carriage control characters.  The UREP
software doesn't handle this correctly at all, which leads to horrible
printouts and such.  I traced the problem to the routing rdr uses to con-
vert from IBM to UNIX formats.

In addition to the blanks on blank lines, you'll find that UREP REQUIRES
a 66 line page for printouts, and counts lines internally.  It keeps this
line count in order to simulate a form-feed by (you guessed it) sending
lots of blank-filled lines to output.

I rewrote the FCC stuff to (almost) match the output from fpr (I just used
\r instead of backspacing for overstrike).  This gave us correct printouts
and decreased the output file sizes.

-John
 jpe@dukee.egr.duke.edu

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 89 18:50:01 GMT
From:      dpm@k.gp.cs.cmu.edu (David Maynard)
To:        comp.protocols.tcp-ip
Subject:   SLIP problems

I am trying to set up a SLIP connection between two machines.  I had to
slightly modify the protocol (just quoting more characters) because the line
passes through a terminal concentrator that traps some characters.  I am
also unable to use hardware flow control because of the concentrator.

I have things working to the point that 'ping' seems to work in both
directions.  Telnet from host-a to host-b works fairly reliably (hangs very
occasionally).  However, other programs (and telnet in the opposite
direction) hang sometime after the connection is established.  When I look
at netstat on host-a, the hung connections have characters waiting in the
Send-Q.  On host-b, the queues are empty; however, "netstat -s" reports that
the number of ip packets with "data size < data length" has increased.  Even
after these connections hang, I can still ping host-b and establish new
telnet connections from a to b (or continue to use existing telnet
connections).  

I am assuming that some kind of flow control problem is preventing certain
types of packets from being received properly on host-b.  However, I don't
know enough about tcp-ip to know what types of packets to suspect.  I would
suspect long ones, but some of the connections hang with only 2 characters
in the Send-Q.  I also tried reducing the SLMTU for the line to 128 with no
noticeable improvement.  

I would appreciate any hints as to where the problem might be.  I would also
appreciate possible workarounds if I can't find a real solution.  

Host-a is a Sun-2/120 running SunOS3.5.  Host-b is a Sun-3/75 also running
3.5.  Both hosts are running Van Jacobson's tcp software.  

Thanks,
David
 ---
 David P. Maynard (dpm@cs.cmu.edu)
 Dept. of Electrical and Computer Engineering
 Carnegie Mellon University
 Pittsburgh, PA  15213
 ---
 Any opinions expressed are mine only.  I haven't asked the ECE department
 or CMU what they think.
 ---
-- 

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 89 21:00:28 GMT
From:      wstef@beta.eng.clemson.edu (W. Gregg Stefancik)
To:        comp.protocols.tcp-ip
Subject:   POP servers and clients

Are their any POP servers or clients in the public domain?  Do any of the
mail user agents such as MH or ELM have an option to use POP instead of
dealing a mail file?  Please reply via mail.

W. Gregg Stefancik < wstef@eng.clemson.edu >

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 89 21:01:00 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN weirdness

Terry,

I haven't seen a follow-up on the TCP-IP list since your original
message (I just got back from vacation) and I'm curious if you
are still experiencing the problem with ARDEC.ARPA.  I have a
ping running right now and the average time is running around 380
ms.  I'm getting about the same average for 26.0.0.45 as well
(this is through two gateways between the BBN internal net and
the MILNET).

Experiencing a longer round trip time for the first ping or two
is to be expected; the PSNs are in the process of setting up a
subnet end-to-end virtual circuit.  Once the connection has been
established, data flows.

The behavior you described (two hosts at the same PSN having
widely differing operating characteristics) usually points to
problems with an individual host: either a problem in the host
itself, or a hardware problem with its access line or port (on
either end of the line).

The folks at the CONUS NOC are usually very good at solving this
sort of problem, and are assisted by development folks up here in
Cambridge when necessary.  I suggest giving them another try if
this is still an ongoing problem.  If that fails, mail to tcp-ip
certainly gets attention, since it is read by both folks at the
DDN PMO and in BBNCC.

Regards,
Andy Malis
Manager, BBNCC PSN Development Support

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 89 22:43:13 GMT
From:      tcs@BRL.MIL (Terry Slattery, SECAD)
To:        comp.protocols.tcp-ip
Subject:   Re:  PSN weirdness

Thanks for your inquiry.

Yes, things have gotten much better in the last week.  There have been
problems with our PSN which may have been part of the problem.  The
symptoms of the PSN problem is messages from the PSN to our gateway
which indicate insufficient resources in our PSN for connections to
some sites.  A trouble ticket has been issued in Mike Muuss' name for
this problem.  It is still open at this time and we are still getting
these advisory packets from the PSN.

The behavior I noted in my message to the list was not due to problems
with a specific host (or so it seemed).  Both had proper routes to the
other and could be pinged from a third host (usna.mil).  These pings
had reasonable round trip times.  The aberrant behavior was only
between ardec.arpa and hosts at BRL.  We could occasionally get
packets through by starting a pinging from ardec.arpa.

Anyway, the problem I reported seems to have been resolved since ping
round trips are now reasonable (< 500ms).  Our PSN is also being
reloaded tonight with new software, presumably to fix the problem with
insufficient resources.

	-tcs

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 89 23:49:23 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        u3b.tech,u3g.misc,comp.sys.att,comp.protocols.tcp-ip
Subject:   Internet Worm and other 3B TCP/IP security fixes available

Quoted (with permission) from the AT&T UNIX System Support and Update News:

			TCP/IP WORM PROTECTION

Recently the Internet (TCP/IP) community experienced a worm that
disrupted many computers on that network.  At the same time, two other
security bugs were reported that did not share the spotlight with the
worm.  Any of these security holes has the potential of allowing
unauthorized users access to a system, and the potential for them to
become superusers.  Fixes are available to all TCP/IP customers for the 
following AT&T Enhanced WIN*/3B TCP/IP products:

              Machine              TCP/IP Release
              -------              --------------
                3B2                     2.2
                3B2                     2.1
                3B2                     1.1
                3B15                    2.1
                3B15                    1.1
                3B20                    2.1
                3B20                    1.1


Please call your hotline to obtain the fixes.  

Fixes for the AT&T 6386 WGS TCP/IP Release 1.0 will be provided in a free
maintenance release.  This release will be sent automatically to existing
customers in late January, 1989.

*WIN (Wollongong Integrated Networking) is a trademark of The Wollongong
Group.

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 89 01:59:12 GMT
From:      ka@june.cs.washington.edu (Kenneth Almquist)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: BIND/Named question

> 	I posted this once before, but never got any responses (except for
> a question), so I'm going to try it again.

I'm not an expert on this stuff, but since I haven't seen any responses
I'll give it a try.

> 	The question:  Should named, when the TTL of an address mapping goes
> to 0, go back out and get a confirmation of the address, or should it simply
> give the address as non-authoritative??

The TTL (time to live) field is "a 32 bit signed integer that specifies
the time interval that the resource record may be cached before the source
of the information should again be consulted," (rfc 1035) so I believe
that you should discard the address from your cache when the time goes
to zero, and fetch it from the source if you later need the address
again.

If your name server is authoritative for the domain being queried, then
the TTL field doesn't apply.  You don't have to "go back out and get a
confirmation of the address" because you have your own copy of the entire
database for the domain.  So I assume that your question refers to queries
which are sent to a name server which is not authoritative for the domain
being queried.

The AA (authoritative answer) bit "specifies that the responding name
server is an authority for the domain name in question section." (rfc 1035)
So a name server should not set the AA bit in responses that it generates
from its cache.

> 	As it stands now, we give out a non-authoritative answer, which the
> network hardware interprets as an invalid address.  It appears that their
> software wants a fully-authoritative answer before it will make the
> connection.  (The network hardware in question is Ungermann-Bass).

Now this I don't understand at all.  If a piece of software wants an
authoritative answer and you aren't authoritative for the domain being
queried, then the software shouldn't be sending queries to you.  (It is
possible that someone is lying to it about which name servers are
authoritative.)  And I don't think that their software has any business
insisting on authoritative answers in the first place.

> The people in charge of our network (which gets name service from us) claim
> that we are giving out bogus information for addresses whose TTL has gone to
> 0.  They contend that if the TTL of the address has gone to 0 that named 
> should check this address and reset its TTL (thus, theoretically making it
> authoritative) before issuing the response.

I believe that this is correct, except for the comment about making it
authoritative.

> 	The software is BIND 4.8 running on a Pyramid 98x.  No other systems 
> seem to be upset by this, but the UB NIU's want more solid confirmation (it
> appears).

You mean they aren't upset under normal conditions.  Distributing data
which has exceeded its Time To Live will cause problems when the network
changes (making the data invalid), and setting the Authoritative Answer
bit in answers which aren't authoritative can confuse people who are
trying to diagnose name server problems.  It's probably worth fixing your
software so it doesn't do these things, but that won't help with the
problems of the UB NUI's.  Unless there is some reason for the NUI's to
insist on authoritative answers (and I can't think of any), you should
fix the NUI software.  If that is not possible, you might stick a WELL
DOCUMENTED hack into your name server to check whether the requester is
an NUI, and to set the AA bit if it is.
				Kenneth Almquist

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 89 02:50:03 GMT
From:      csn1717@UX.ACSS.UMN.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Beginner Questions

In article <437@fedeva.UUCP>, wrd3156@fedeva.UUCP (Bill Daniels) writes:

|                                                How does one establish
| themselves as an internet node, electrically/mechanically that is?
| 
| (2) Since ftp works locally over an ethernet using tcp-ip, how does an
| anonymous ftp connect to a remote site (analogous to uucp dialups)?
| Does it tcp-ip over dial-ups?  
| 
| (3) How does one rlogin or telnet to a host on a remote network?  What 
| advantage does this have over tip/cu?

Given that "ftp works locally using tcp-ip" (thus probably telnet/rlogin),
your site is quite ready for Internet connectivity.  However, before you
can ftp/telnet/rlogin to a remote site, you'll need to find a site which
is already connected to the Internet, and is willing to forward packets 
for you. (By Internet, here I mean some network that is connected, 
directly or indirectly, to the Nsfnet or Arpanet backbone, and by 
packet switching --- which would exclude the present Bitnet and UUCP, 
and to a certain extent, CSnet.)

Note that connecting your site to the Internet is more of an administrational 
than a technical matter...

Technically, connection to your peer (the host which is already on
the Internet) are usually by means of a leased phone line, though in essence
any suitable transmission media of "any" data rate should work. (well,
actually, 9600bps is merely acceptable as far as performance is concerned.)
Since tcp/ip is just a software subsystem, surely it can be implemented
over switched (dial-up) lines --- you just need a driver to get the packets
off the line. (There is a package called "slip", implementing the serial line 
internet protocol. I haven't had experience with it, so I don't know 
whether it would work over dialups... I'd like to know though, so could
someone please enlighten?!)

Advantage over tip/cu?  well, too many, too many!! With tip/cu, you only
connect to one machine; with telnet/rlogin, you can possibly connect to 
hundreds of thousands, when given the right permissions and right routes...
And more importantly, file transfers work a lot better!

Have Fun! ;-)

Aaron Y. T. Cheung
University of Minnesota

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 89 02:51:57 GMT
From:      gore@eecs.nwu.edu (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Dial-up SLIP?

I heard about dial-up SLIP, but no details.  All I know is that Telebit
people are looking forward to it (my words), and that there was a version
developed by BBN and/or CSNET.

Is there any more information available?  Is the code available?

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,gargoyle,att}!nucsrl!gore

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Jan 89 12:40:35 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tank!nucsrl!gore@handies.ucar.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Dial-up SLIP?

> I heard about dial-up SLIP, but no details.  All I know is that Telebit
> people are looking forward to it (my words), and that there was a version
> developed by BBN and/or CSNET.

> Is there any more information available?  Is the code available?

Jacob:

    There are several implementations around, in vary forms of stability.
To my knowledge only the CSNET one is currently being distributed, and
only to CSNET members (the code was developed using CSNET revenue).  Other
sites with dial-up IP software include the University of Tokyo and BRL.

The CSNET software is described in a paper being given next week
at the Winter USENIX conference.  [L. Lanzillo and C. Partridge,
"Implementation of Dial-up IP for UNIX Systems," Proc. 1989 Winter
USENIX, San Diego, Calif.]. The key features are:

    - It drops into binary BSD distributions (e.g. SUN)

    - It makes connections on demand. When a packet hits your dial-up
	gateway for a remote site that isn't currently connected,
	the gateway will dial the phone and establish the link
	(while the datagram waits).  Note that the delay in dialing
	the phone is long enough that you probably don't want to
	do more than one such dial-up hop (i.e. dial-up IP works
	best with star topologies).  When the dial-up link has
	been idle for a few minutes, the line hangs-up.

    - There are some basic access controls so that the phone link
	can only be established at times that you agree to incur
	charges, and only by hosts that you chose to allow to
	establish the connection.  These facilities are optional,
	and once the link is up, anyone can use it.  (We'd like
	to put in traffic filtering but are still dithering about
	the best way to do it).

I believe the U. Tokyo software is similar [ J. Murai and A. Kato,
"Current Status of JUNET," Future Generation Computer Systems, Vol. 4,
No. 3, October 1988].  The BRL software (last I heard) requires more
active user intervention -- i.e. you dial the phone and then start
SLIP over it. Phil Karn also supports some form of dial-up SLIP with
his KA9Q package (he's used it to connect to the CSNET dial-up IP
gateway).

Craig

PS: My impression, based on very little testing, is that all these
implementations are culturally compatible and that with a tiny bit
of work, we could probably make them all interoperate.
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Jan 89 15:13:50 -0500
From:      Leo Lanzillo <leo@SH.CS.NET>
To:        Jacob Gore <tank!nucsrl!gore@handies.ucar.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Dial-up SLIP?


        >> I heard about dial-up SLIP, but no details.  All I know is
        >> that Telebit people are looking forward to it (my words), and
        >> that there was a version developed by BBN and/or CSNET.

        >> Is there any more information available? Is the code available?

CSNET offers its members Dialup IP access to relay.cs.net.
 
This service gives sites part-time Internet access.  Upon receipt of an
IP packet destined for the Internet, it automatically checks to see if 
the line is up and dials relay.cs.net if necessary.  It also allows 
users to manually bring up the link.

We have been using it at CSNET for about 6 months to give IP
access to sites which could previously only handle electronic
mail.

The code is based on Rick Adam's slip as distributed with BSD
UNIX.  We are monitoring the development of the Point to Point
standard and expect to convert to that protocol when it becomes
finalized.

To CSNET members, we distribute source code which runs under Ultrix, 
Sun 3.x and BSD UNIX.  Sites can use it either to access relay.cs.net, 
or to set up their own dialup IP network.

Contact the CSNET Coordination and Information Center (cic@sh.cs.net)
for more details.

Leo Lanzillo
CSNET Staff.
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 89 13:34:55 GMT
From:      jallen@uxrd14.UUCP (Jon Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Security

In article <207@secola.Columbia.NCR.COM> kwilliam@secola.Columbia.NCR.COM (Karen Williams) writes:
>Do the TCP/IP standards allow for encryption of data?  In other
>words, can a data capture/analyzer see everything, or is there

The commercial versions that I have worked with do not do any encryptiong.
A LAN analyzer will see all (including passwords).  I work primarily with 
the Wollongong and AT&T versions of TCP/IP.

Jon Allen
att!acpy01!jallen

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 89 15:34:48 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Worm and other 3B TCP/IP security fixes available

Just what exactly were these security holes?  Would these fixes be
applicable to other Vendor's products?  Or is this a forum for proprietary
missives.

Phil Wood, cpw@lanl.gov

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 89 17:40:35 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Dial-up SLIP?


> I heard about dial-up SLIP, but no details.  All I know is that Telebit
> people are looking forward to it (my words), and that there was a version
> developed by BBN and/or CSNET.
 
> Is there any more information available?  Is the code available?

Jacob:

    There are several implementations around, in vary forms of stability.
To my knowledge only the CSNET one is currently being distributed, and
only to CSNET members (the code was developed using CSNET revenue).  Other
sites with dial-up IP software include the University of Tokyo and BRL.

The CSNET software is described in a paper being given next week
at the Winter USENIX conference.  [L. Lanzillo and C. Partridge,
"Implementation of Dial-up IP for UNIX Systems," Proc. 1989 Winter
USENIX, San Diego, Calif.]. The key features are:

    - It drops into binary BSD distributions (e.g. SUN)

    - It makes connections on demand. When a packet hits your dial-up
	gateway for a remote site that isn't currently connected,
	the gateway will dial the phone and establish the link
	(while the datagram waits).  Note that the delay in dialing
	the phone is long enough that you probably don't want to
	do more than one such dial-up hop (i.e. dial-up IP works
	best with star topologies).  When the dial-up link has
	been idle for a few minutes, the line hangs-up.

    - There are some basic access controls so that the phone link
	can only be established at times that you agree to incur
	charges, and only by hosts that you chose to allow to
	establish the connection.  These facilities are optional,
	and once the link is up, anyone can use it.  (We'd like
	to put in traffic filtering but are still dithering about
	the best way to do it).

I believe the U. Tokyo software is similar [ J. Murai and A. Kato,
"Current Status of JUNET," Future Generation Computer Systems, Vol. 4,
No. 3, October 1988].  The BRL software (last I heard) requires more
active user intervention -- i.e. you dial the phone and then start
SLIP over it. Phil Karn also supports some form of dial-up SLIP with
his KA9Q package (he's used it to connect to the CSNET dial-up IP
gateway).

Craig

PS: My impression, based on very little testing, is that all these
implementations are culturally compatible and that with a tiny bit
of work, we could probably make them all interoperate.

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 89 20:13:50 GMT
From:      leo@SH.CS.NET (Leo Lanzillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial-up SLIP?



        >> I heard about dial-up SLIP, but no details.  All I know is
        >> that Telebit people are looking forward to it (my words), and
        >> that there was a version developed by BBN and/or CSNET.

        >> Is there any more information available? Is the code available?

CSNET offers its members Dialup IP access to relay.cs.net.
 
This service gives sites part-time Internet access.  Upon receipt of an
IP packet destined for the Internet, it automatically checks to see if 
the line is up and dials relay.cs.net if necessary.  It also allows 
users to manually bring up the link.

We have been using it at CSNET for about 6 months to give IP
access to sites which could previously only handle electronic
mail.

The code is based on Rick Adam's slip as distributed with BSD
UNIX.  We are monitoring the development of the Point to Point
standard and expect to convert to that protocol when it becomes
finalized.

To CSNET members, we distribute source code which runs under Ultrix, 
Sun 3.x and BSD UNIX.  Sites can use it either to access relay.cs.net, 
or to set up their own dialup IP network.

Contact the CSNET Coordination and Information Center (cic@sh.cs.net)
for more details.

Leo Lanzillo
CSNET Staff.

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 89 20:24:14 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   RFC-1073 TELNET Window Size Option

Has anyone implemented RFC-1073, TELNET Window Size Option?  We have an client
end implementation (for VAX VMS, not UNIX) and would love to test it against
someone's server.

Drew

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 89 20:28:31 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   re: POP servers and clients

I don't know about POP servers/clients, but a publicly available server and
client for the Interactive Mail Access Protocol (IMAP2) described in RFC 1064
is available for non-commercial usage.  The current software is:
 . servers: BSD Unix (written in C), DEC-20 (written in assembly language)
 . clients: portable (written in C), Xerox Lisp, TI Common Lisp

The portable client is available for BSD Unix; ports for the Macintosh,
MS-DOS, and NeXT are in the works (the BSD Unix version runs on the NeXT as
is, but no fancy window/menus).  An earlier version of the portable client
runs on the DEC-20.

IMAP is much more powerful than POP; I like to say that IMAP is to POP the way
a BMW is to a tricycle.

Contacts for the software are Mark Crispin (mrc@Blake.ACS.Washington.EDU) and
Bill Yeager (yeager@SUMEX-AIM.Stanford.EDU).

-- Mark --

-------

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jan 89 07:25:11 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   watch that capitalization

In today's New York Times business section there is an ad for
Interface '89 Plus, which includes a note for

	INTERnet(sm)

which is their show network.

Craig
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 89 08:57:40 GMT
From:      vixie@decwrl.dec.com (Paul A Vixie)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial-up SLIP?

Ultrix 3.0 (and perhaps earlier, I don't know) supports dial-up SLIP, in a way.
If /usr/new/slattach is run without arguments (as a login shell, e.g.) then it
tries to look up the name of the user who runs it in the /etc/sliphosts file.
If given an argument, it looks up its argument.  The /etc/sliphosts file has 
entries of the general form:

	destination gateway netmask speed tty modemtype phonenum logininfo

"destination" is the key which /usr/new/slattach looks for (see above); there
should also be a name or alias in your DNS or /etc/hosts matching this.
"gateway" is the name of your end of the SLIP link, and should also be
a name or alias in your DNS or /etc/hosts file.  "netmask" is obvious, though
it's not _generally_ useful for a point-to-point link in my opinion.  "speed"
is either the baud rate to use (if it's an outgoing entry) or "any" for
incoming entries.  "tty" is a /dev/ttyXX name, and no, multiple ttys aren't
well-supported.  "modemtype" and "phonenum" are used in conjunction with the
/etc/acucap file which supports generic modem dialing (also used for uucp and
tip).  "logininfo" is a "chat script" similar to the one used by UUCP in L.sys.

The result is that if you can arrange to execute a specific "slattach" command
whenever you want to get connected to your SLIP neighbor, then Ultrix 3.0 has
"dial-up SLIP".  The CSNET implementation is better in this regard since it is
able to make the call when you try to send a packet toward your SLIP neighbor.

Both the Ultrix and the CSNET dial-up SLIP implementations are proprietary in
one way or another: to get the Ultrix one you need an Ultrix machine (a VAX or
a DECstation 3100); to get the CSNET one you need to be a CSNET member.

A publically redistributable dial-up SLIP is still very much needed.  But a
publically-redistributable generic modem dialer is also very much needed --
4.3bsd uucp and tip both still makes you relink binaries to support a new
kind of modem.  (What decade is this, again?)
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 89 12:25:11 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   watch that capitalization


In today's New York Times business section there is an ad for
Interface '89 Plus, which includes a note for

	INTERnet(sm)

which is their show network.

Craig

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jan 89 17:47:01 EST
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Tom Corsetti <dftsrv!tomc@ames.arc.nasa.gov>, tcp-ip@sri-nic.arpa
Subject:   Re: beginnings of subnetting a class B net
Tom Corsetti asks:

>I have a question about subnetting.  We are currently using
>255.255.0.0 as our net mask for our class b network.  That is, we're
>not subnetting.  ....
>                                   There is one group that we have
>assigned a subnet address to.  They have a ring of apollos, one of which
>has two network interfaces.  They are trying to isolate the traffic
>amoung their apollos behind the machine with two interfaces.  In other
>words, they are trying to use the apollo with 2 ethernet boards as a
>gateway for the rest of the machines.  Here's the problem (finally):
>They can't get the rest of the net to talk to them through the gateway.
>Does every machine on the lan have to set up explicite routing information
>to know to send packets destined for their subnet address to their gateway?
>Is there a way to get their apollo gateway to advertise that it is a gateway
>for the other machines?  This problem is compounded by the fact that everyone
>else on the net has a subnet mask of 255.255.0.0, while they're trying
>to set up a subnet where the mask is 255.255.255.0 on the SAME class b
>address space.  Has anyone met up with this problem before?  Any words
>of wisdom are highly appreciated.  I really want to get a good understanding
>of this stuff.  Thanks very much in advance!

This will work *IF*:  1) the Apollo doing the gateway handles subnets
correctly, and 2) the Apollo will handle proxy ARPs on the main net.

The first is the big one - not many vendors have this right yet.  You
need to set a subnet mask on the back side interface, and not on the
front one.  Then (if it isn't implied by the interface configuration)
you have to add a routing entry pointing to the second interface for the
subnet address, with the subnet mask.  This is what usually isn't possible;
routing entries are usually "host" or "network", not "subnet".

Proxy ARP will handle the hosts on the main network; they assume, from
their configuration, that they can directly ARP to these systems.

Doug Nelson
Michigan State University
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 89 15:35:09 GMT
From:      tomc@dftsrv.gsfc.nasa.gov (Tom Corsetti)
To:        comp.protocols.tcp-ip
Subject:   beginnings of subnetting a class B net

Hi There!
I have a question about subnetting.  We are currently using 
255.255.0.0 as our net mask for our class b network.  That is, we're 
not subnetting.  We have filtering bridges separating the buildings,
but no dedicated routers (except for the ones that give us our connection
to the internet).  There are almost 400 hosts on the lan.  The mixture
is a heterogenious one consisting of both 4.2 and 4.3 bsd, system V,
IBM PCs, Macs, Vaxen running VMS, AIX machines.. etc.  Alot of these
systems don't understand subnets.  There is one group that we have
assigned a subnet address to.  They have a ring of apollos, one of which
has two network interfaces.  They are trying to isolate the traffic 
amoung their apollos behind the machine with two interfaces.  In other
words, they are trying to use the apollo with 2 ethernet boards as a
gateway for the rest of the machines.  Here's the problem (finally):
They can't get the rest of the net to talk to them through the gateway.
Does every machine on the lan have to set up explicite routing information
to know to send packets destined for their subnet address to their gateway?
Is there a way to get their apollo gateway to advertise that it is a gateway
for the other machines?  This problem is compounded by the fact that everyone
else on the net has a subnet mask of 255.255.0.0, while they're trying
to set up a subnet where the mask is 255.255.255.0 on the SAME class b
address space.  Has anyone met up with this problem before?  Any words
of wisdom are highly appreciated.  I really want to get a good understanding
of this stuff.  Thanks very much in advance!
                                                     - Tom Corsetti
-- 
  Tom Corsetti                 * * * *   internet - tomc@dftsrv.gsfc.nasa.gov
  NASA/Goddard Space Flt Ctr    * * *    decnet   - dftnic::tomc
  Greenbelt Maryland           * * * *   bitnet   - tomc at dftbit

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 89 17:16:10 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: POP servers and clients

Drop a note to Postmaster@ics.uci.edu and ask about the current release
of MH.  This includes a POP client and server.  MH is available under no
licensing restrictions whatsoever (other than the usual "don't sue us"
disclaimer).  It is also somewhat more common than similar protocols
such as IMAP2, since POP has been around for the last 4+ years...

/mtr

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 89 18:16:34 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP problems

We saw some funky asymetrical slip behaviour, and the same short packet
observation when we forgot to turn of XON/XOFF on the modem we were
using.

-Ron

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 89 18:27:55 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Dial up SLIP


there is an IETF working group dealing with this, but i havent seen
much on it in awhile. this will be in the public domain, and several
vendors have expressed an interest in supporting the resulting spec
(if it meets their needs).


stev knowles
stev@ftp.com

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 89 19:41:03 GMT
From:      eplrx7!mcneill@louie.udel.edu  (mcneill)
To:        tcp-ip@sri-nic.arpa
Subject:   Special Internet address

One machine on our LAN caused a lot of havoc.  It was mistakenly placed on
the network before it's networks file had been configured correctly.  It
thought that it's network address was 192.9.200.0.  I seem to remember
seeing somewhere "never use x.x.x.0 address" (where x ranges from 0 to
255).  Is my memory correct?  If that is an untouchable address why is it?

thanks

-- 
    Keith D. McNeill              |    E.I. du Pont de Nemours & Co.
    eplrx7!mcneill@uunet.uu.net   |    Engineering Physics Laboratory
    (302) 695-7395                |    P.O. Box 80357
                                  |    Wilmington, Delaware 19880-0357
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jan 89 12:05:38 -0800
From:      Steve Goldstein <goldstei@nsipo.nasa.gov>
To:        mogul@decwrl.dec.com (Jeffrey Mogul)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: pecial Internet address
Folks,

I just found the time to look it up in my "Installing UNIX on the Sun 
Workstation", 19 September 1986, Revision A of 10 October 1986, Chapter 2--
Getting started, page 9:

	"Please remember that:

		* You can use Sun Microsystems' default network number 
		(192.9.200) if you have not been assigned a network number
		by ARPA, or if you are not connected to a higher level Network."

Then, later on (page 27) the address 192.9.200.11 is suggested, and on page 28,
192.9200.1 [sic].

Now, how many WS's do you think come on line with 192.9.200.0 loaded as
default?

--SG

Re:One machine on our LAN caused a lot of havoc.  It was mistakenly placed
on
    the network before it's networks file had been configured
correctly.  It
    thought that it's network address was 192.9.200.0.  I seem to
remember
    seeing somewhere "never use x.x.x.0 address" (where x ranges from 0
to
    255).  Is my memory correct?  If that is an untouchable address why
is it?
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 89 00:57:01 GMT
From:      kolk@polya.Stanford.EDU (Dan Kolkowitz)
To:        news.groups,comp.protocols.tcp-ip,comp.unix.wizards,comp.misc
Subject:   CALL FOR DISCUSSION: comp.protocols.kerberos

Here I propose the creation of the newsgroup:

      comp.protocols.kerberos

This is to promote discussion and exchange of ideas on the kerberos 
authentication system from Project Athena at M.I.T.  The first public release 
became available today through anonymous ftp from there.  Since the 
authentication is protocol based and not specfically tied to Unix the 
kerberos people and I thought comp.protocols.kerberos to be the most 
appropriate place for the kerberos group.  

The date this proposal is posted: Jan. 25, 1989

There will be a discussion period of two weeks (until Feb. 8, 1989) to
hear people's suggestions, wishes, ideas, and flames. Please note the
Follow-up: field and send your Follow-ups to news.groups. 

Following Feb. 8, 1989, there will be a 30-day Yes/No voting period.
I'll post a Call For Vote message as a reminder. Please direct all
Yes/No answers to me (kolk@jessica.stanford.edu).

Thanks.

Dan Kolkowitz
Systems Development 
Academic Informaion Resources
Stanford University, Stanford, Ca.  94305-3090
(415) 723-5414
kolk@jessica.stanford.edu

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 89 02:46:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: pecial Internet address

From: mcneill@eplrx7.UUCP (mcneill)

    One machine on our LAN caused a lot of havoc.  It was mistakenly placed on
    the network before it's networks file had been configured correctly.  It
    thought that it's network address was 192.9.200.0.  I seem to remember
    seeing somewhere "never use x.x.x.0 address" (where x ranges from 0 to
    255).  Is my memory correct?  If that is an untouchable address why is it?

I thought we had put this prohibition into RFC950, but on a quick read
I couldn't find it (we did prohibit subnet number 0).

Anyway, I can tell you why you shouldn't do it: because in spite
of the standard for broadcasting (RFC919) which specifies the
use of an ``all-ones'' broadcast address, many hosts (derived
at some point from 4.2BSD) still use the x.x.x.0 address for
broadcasting (if they also understand subnets, that is).

So, using x.x.x.0 or x.x.x.255 is likely to confuse some hosts
and perhaps lead to broadcast storms ... which you don't want.

-Jeff

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 89 14:27:39 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: pecial Internet address

>    One machine on our LAN caused a lot of havoc.  It was mistakenly placed on
>    the network before it's networks file had been configured correctly.  It
>    thought that it's network address was 192.9.200.0.  I seem to remember
>    seeing somewhere "never use x.x.x.0 address" (where x ranges from 0 to
>    255).  Is my memory correct?  If that is an untouchable address why is it?
 
>I thought we had put this prohibition into RFC950, but on a quick read
>I couldn't find it (we did prohibit subnet number 0).

It may not have made it into the Subnet spec, but gateway requirements
RFC-1009 says:

(section 2.1): ...
	 
      There are certain special cases for IP addresses, defined in the
      latest Assigned Numbers document [23].  These special cases can be
      concisely summarized using the earlier notation for an IP address:

      ...

      The following two are conventional notation for network numbers,
      and do not really represent IP addresses.  They can never be used
      in an IP datagram header as an IP source or destination address.

         (h)   {<Network-number>, 0}

            Specified network (no host).

         (i)   {<Network-number>, <Subnet-number>, 0}

            Specified subnet (no host).

      Note also that the IP broadcast address, which has primary
      application to Ethernets and similar technologies that support an
      inherent broadcast function, has an all-ones value in the host
      field of the IP address.  Some early implementations chose the
      all-zeros value for this purpose, which is not in conformance with
      the specification [23, 49, 50].

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 89 14:56:00 GMT
From:      acm@RELAY.PROTEON.COM
To:        comp.protocols.tcp-ip
Subject:   time warp?!

Can anyone explain why the time reported by ncar is so far different from
the other time servers in the recommended list?  I have seen it as much as
45 seconds removed from the others when they were answering.
     -Al Marshall, Proteon
          acm@proteon.com

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 89 16:00:00 GMT
From:      acmb@RELAY.PROTEON.COM
To:        comp.protocols.tcp-ip
Subject:   Special Internet address


     One machine on our LAN caused a lot of havoc.  It was mistakenly
     placed on the network before it's networks file had been configured
     correctly.  It thought that it's network address was 192.9.200.0.  I
     seem to remember seeing somewhere "never use x.x.x.0 address" (where x
     ranges from 0 to 255).  Is my memory correct?  If that is an
     untouchable address why is it?

    Keith D. McNeill              |    E.I. du Pont de Nemours & Co.

Keith,
My part of the history of that comes from MIT LCS and the initial work of
ProNET-10 that was done as v2lni.  The format of the token ring had a
sensitivity to bit dropping (in the Manchester code) that caused a token to
become a beginning-of-message which would cause all machines in the ring to
experience an interrupt.  That was clearly undesirable so we concluded it
should not be used as an address.  The bit dropping was related to what the
cables do to differential Manchester encoding.  There were other reasons
discussed at the time, but I think one of them was that some interfaces had
intended to use 0 as the broadcast address and was not to be used for
anything else.  We had initially used 0 as broadcast and with this problem
cause discovered we concluded that 0 was VERY bad for broadcast and
inverted the bits to give 255 (0xFF) for the broadcast.  

Those discussions took place at MIT about 1980-81 and the removal of one
more address from those used out of 255 was not expected to be missed by
anyone.  Thus the recommendation is to not use address 0 for any node and
this carries over to other networks that use 8 bit addressing.

        -Alan Marshall, VP Proteon Inc.
         2 Technology Drive             CCMAIL: acm at proteonwebo
         Westboro, MA  01581-5008       ARPANET: acm@Proteon.com
                tel: (508)898-2120      MHS: acm @ ProteonW

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 89 17:54:00 GMT
From:      phil@bcscal.UUCP (Phil Kemp)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Telnet problems to SUN

I am using a UNIX-PC connected to a VAX as a terminal, via a hardwire
connection to a multiplexor, and then invoking telnet to log in to a SUN
attached to a TCP/IP network linking everthing together. ( except my PC )

The problem I'm having is that while I can do file transfers via kermit
to the VAX with no problem, I cannot pass data to the SUN in anything
but the smallest amounts. cu's put and take seem to overrun the SUN's
tty interface buffers, Kermit will simply not work, I cannot even get
the files started and Xmodem/Zmodem will not work either.

I suspect the problem to be in the telnet protocol's handling of data
and packet sizes. I have tried setting binary and charmode on telnet to
no avail.

Has anyone done anything like this before and been successful? My
objective is get uucp working between my machine and the remote SUN. 
If there is a good reference on the innards of Telnet  between the VAX
and the SUN, I would sure like to know about it.

Please E-mail any help to me and I will try and summarize if there is a
decent solution.

Thanks in advance.

Phil Kemp
Boeing Computer Services, Calgary
Voice - (403)-269-8281
phil@bcscal.uucp



-- 
Phil Kemp
Boeing Computer Services, Calgary
Voice - (403)-269-8281
phil@bcscal.uucp

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 89 18:27:34 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial up SLIP

I missed the last meeting, but I believe the group has decided that
the protocol for doing IP over serial lines (including dialups)
will not be the existing SLIP protocol.

_Ron

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 89 20:19:58 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip,sci.crypt
Subject:   Information wanted on the Blacker Front End

I'm looking for information on the Blacker Front End.  (The BFE is an
A1-level crypto box for TCP/IP.)  I've seen the document in the DDN
Protocol Handbook; I'm looking for an operational overview.  There was
a paper presented at the 1988 IEEE Symposium on Security and Privacy by
C. Weissman; unfortunately, the text was not received in time to be
included in the proceedings.  If anyone has that paper, or other,
similar papers, or a pointer to Weissman, I'd appreciate it.  I'm
neither eligible for, nor interested in, any classified material.

		--Steve Bellovin
		AT&T Bell Laboratories

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 89 03:17:11 GMT
From:      jon@BITSY.MIT.EDU (Jon Rochlis)
To:        comp.protocols.tcp-ip
Subject:   MIT Athena Kerberos Authentication System available for FTP


What is Kerberos and why is it needed?

In an open network computing environment a workstation cannot be
trusted to identify its users correctly to network services.  Software
on the workstations may not be trustworthly, so being a privileged
user on a workstation is not a meaningful test of authenticity.
Source network addresses are so easily forged that they are are
meaningful either.  Passwords sent uncrypted on the network are
vulnerable to wiretappers.  Kerberos provides an alternative approach
whereby a trusted third-party encryption-based authentication service
is used to verify users' identities.  Much more information is
available with the documentation (see below).

How to get it:

The first public release of the Kerberos Authentication System is ready
for retrieval.  Initial distribution will be by anonymous
FTP; eventually 9-track tapes will be available.

To retrieve the distribution, ftp to ATHENA-DIST.MIT.EDU (18.71.0.38),
login as anonymous (password whatever you like, usually your
username@host), then cd to pub/kerberos.

Retrieve README.ftp, it has directions on how to get to the rest of the
software.

Distribution is split compressed tar files (xxx.Z.aa, xxx.Z.ab, ...).

If you would like to retrieve documents separately, you can get them
from pub/kerberos/doc (documents) or pub/kerberos/man (manual pages).
If you prefer hardcopy of the documentation, send your address and request
to "info-kerberos@athena.mit.edu".

If you would like to be put on the Kerberos e-mail list
("kerberos@athena.mit.edu"), send your request to
"kerberos-request@athena.mit.edu".

I would like to thank the following people for their assistance in
getting Kerberos in shape for release:

Andrew Borthwick-Leslie
Bill Bryant
Doug Church
Rob French
Dan Geer
Andrew Greene
Ken Raeburn
Jon Rochlis
Mike Shanzer
Bill Sommerfeld
Jennifer Steiner
Win Treese
Stan Zanarotti

FYI, the copyright notice:

  Copyright (C) 1989 by the Massachusetts Institute of Technology

   Export of this software from the United States of America is assumed
   to require a specific license from the United States Government.
   It is the responsibility of any person or organization contemplating
   export to obtain such a license before exporting.


WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
distribute this software and its documentation for any purpose and
without fee is hereby granted, provided that the above copyright
notice appear in all copies and that both that copyright notice and
this permission notice appear in supporting documentation, and that
the name of M.I.T. not be used in advertising or publicity pertaining
to distribution of the software without specific, written prior
permission.  M.I.T. makes no representations about the suitability of
this software for any purpose.  It is provided "as is" without express
or implied warranty.

--------
John Kohl
MIT Project Athena/Kerberos Development Team

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 89 07:03:02 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.protocols.tcp-ip
Subject:   Kerberos Authentication System now available


     Kerberos is finally out.  Now there's something that can be
done about passwords in the clear, the vast holes in NFS, and such.
See below.

					John Nagle

>From: John T Kohl <jtkohl@ATHENA.MIT.EDU>

The first public release of the Kerberos Authentication System is ready
for retrieval.  Initial distribution (this week) will be by anonymous
FTP; eventually 9-track tapes will be available.

To retrieve the distribution, ftp to ATHENA-DIST.MIT.EDU (18.71.0.38),
login as anonymous (password whatever you like, usu. your
username@host), then cd to pub/kerberos.

Retrieve README.ftp, it has directions on how to get to the rest of the
software.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 89 14:00:30 GMT
From:      tinker@ultra.UUCP (Don Tinker)
To:        comp.protocols.tcp-ip
Subject:   Request to be added to mailing list


Please add me to your mailing list.  Thanks,

	Don Tinker	tinker@ultra.com

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 89 14:13:53 GMT
From:      chip@ateng.ateng.com (Chip Salzenberg)
To:        news.groups,comp.protocols.tcp-ip,comp.unix.wizards,comp.misc
Subject:   Re: CALL FOR DISCUSSION: comp.protocols.kerberos

According to kolk@polya.Stanford.EDU (Dan Kolkowitz):
>Here I propose the creation of the newsgroup:
>      comp.protocols.kerberos

Is there traffic to warrant a group?  Where?

If not, perhaps it should go through the mailing list phase first.
-- 
Chip Salzenberg             <chip@ateng.com> or <uunet!ateng!chip>
A T Engineering             Me?  Speak for my company?  Surely you jest!
	  "It's no good.  They're tapping the lines."

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 89 15:56:03 GMT
From:      jec@macs.UUCP (John Carswell)
To:        comp.protocols.tcp-ip,comp.sys.mac,comp.protocols.misc
Subject:   TCP/IP for the Mac ???


     I need a little help.  I am working on my senior research here at Stetson
University trying to get a Macintosh to talk to its choice of a Sun, a
microVAX or a VAX.  What I am looking for is a TCP/IP driver for the Mac.  I
would prefer it to be in the form of a driver which is installed with the
system (ie. dropped in the system folder) an available through an
implementation of BSD 4.3 sockets.
     Of course, being a student, I need it to be FREE (I might
be able to find some funding, but only as a last resort).  Does anyone out
there have any recomendations or information on how I can get my hands on
such a package ??????  Any and all info would be appreciated.


							Thanx in Advance,

							John Carswell


Send replies to :      jec@macs.UUCP
or			...!uflorida!ki4pv!macs!jec

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 89 16:02:00 GMT
From:      ml@gandalf.UUCP
To:        comp.protocols.tcp-ip
Subject:   Dialup SLIP/Generic Modem Dialer

>Message-Status: 000601918028 norm unread

I happened to see a copy of some of the recent postings in this group.
I was interested to see a request for a generic modem dialer.  If wrote
  a program, DIALER, originally as a front-end for brain-dead UUCP.
  It's available for anyone that wants it.  I've integrated DIALER into
  HDB UUCP, and it seems to work quite well.  DIALER also runs as a standalone
  program, and could more-or-less be trivially integrated into a SLIP
  implementation.
If anyone is interested, contact me.
Marcus Leech
Gandalf Data Ltd

ml@gandalf.UUCP
...spl1!scs!gandalf!ml

#include <std_disclaimer>

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 89 17:18:03 GMT
From:      fokas@qucis.queensu.CA (Elias Fokas)
To:        comp.databases,comp.dcom.lans,comp.lsi,comp.protocols.tcp-ip,comp.software-eng,comp.std.internat,comp.std.misc
Subject:   Network Definition Language


                                  Abstract

                         Network Definition Language (NDL)


The ever increasing complexity and popularity of computer networks
are a challenge to the network designer. Not only can he not afford
any compromise of quality, but also he is required to design and
maintain larger networks in less time.

Evidently, the use of an appropriate software tool will facilitate
the designer's job.

We think that the kernel of any such tool should consist of a means
to completely and explicitly define the network, i.e. a Network
Definition Language.

Conceptually, NDL will:

1. enforce user defined semantic and syntactic restrictions on the
structure of the network (i.e. a network may only contain previously
defined components which may be interconnected only in certain patterns).

2. introduce a user defined level of abstraction (i.e. the same network
might be "viewed" as a set of nodes and links or as a set of real life
components).

3. isolate network-related algorithms from the actual representation
and storage of the network in the computer's memory. Once the network
is defined, any algorithm can be applied to it.

4. link any network (or network component) to a user defined "data base"
(the term is used metaphorically), containing any information the user
deems relevant (i.e. anything from the price and availability of an
ethernet adaptor to the transmission characteristics (bps, distance,
reliabilty, cost per byte etc) of a physical medium) to that particular
network (or network component).

5. provide a means of embeding functional and non-quantifiable attributes
in the definition of a network (or its components). For instance, if a
node fails and this node happens to be the administrative mainframe
the damage is considerable; whereas, if this node is the fileserver
of the secretarial services LAN, the damage is not so severe.

Preliminary research on the subject is under way. However, we have not
yet found any referernce to the aforementioned concepts.

Ifyou have heard of anything, even vaguely, related to this subject or
have some comment or opinion, however general, please sent e-mail
to FOKAS@QUCIS or write to:

        Elias Fokas,
        Dept. of Computer and Information Science,
        Qeen's University,
        Kingston, Ontario
        Canada, K7L3N6

Areas related to this research include: Object-oriented languages,
hardware description languages, network design, software tools,
and expert systems.

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 89 23:55:07 GMT
From:      ddk@beta.lanl.gov (David D Kaas)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   netbios over tcp-ip


	We currently have a very large lan based on Ungermann-Bass
hardware/software with netbios/msnet over xns.  We have over 3000
IBM PCs, network file servers, and serveral network based prgrams,
mail, spreadsheets...  We have put some UNIX workstations on the 
network that run TCP-IP.  We are looking at hardware/software to
run MSDOS programs under UNIX.  Are there any hardware/software
systems available to allow connections between these protocols? 
Any boards to insert in a UNIX workstation or IBM PC/AT/2 that
will run both protocols?
Thanks ahead for any help..

	Dave Kaas
	Boeing Computer Services Richland
	D. O. E. Richland, WA
	BOX 300 m/s a1-05
	RICHLAND, WA 99352

	(509) 376-6386

	E41126%RLVAX3.XNET@LANL.GOV
	OR
	ddk@beta.lanl.gov

-- 
Dave Kaas - D.O.E. Richland, Wa.
	e41126%rlvax3.xnet@lanl.gov

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 89 00:40:38 GMT
From:      andrew@mitisft.Convergent.COM (Andrew Knutsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial up SLIP


	Dial up SLIP is also available on the Convergent S/Series, under
system V.3.  Lachman Associates has the code, and may sell it;  also,
they may have sold it to SUN.  This version is dial-on-demand, and uses
HDB uucp dialing code.

Andrew Knutsen
Convergent

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 89 00:36:42 GMT
From:      rshah@indetech.UUCP (Raj Shah)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   UNMA vs Netview presentation


A few weeks ago there was a posting on one of these newsgroup about a 
conference/lecture/presentation about UNMA and Netview.  If I remeber
right, this event was scheduled to take place in Washington DC on 
Feb 9th, 1989.   

As I will be in the area that week I would like to attend.  However I
don't have any more information.  Will some one who saved the above
announcement please send me a copy.  

Thanks in advance.



-- 
Raj Shah                          {sun,umix,pacbell}!indetech!mdierker
Independence Technologies
42705 Lawrence Place                  FAX: 415 438-2034
Fremont, CA 94538                     Voice: 415 438-2005

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 1989 21:46-EST
From:      CERF@A.ISI.EDU
To:        lhl@CS.WISC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: sigcomm '89
Larry,

how would you feel about a special one-day workshop after
the SIGCOMM 89. Dave Mills and I have been thinking about
having such a workshop to focus on "Limits of the Internet" -
to try to helpfocus attention on areas needing research.
In theory, this would also be helpful to ISO since much of
the ISO protocol base is patterned like the TCP/IP internet.

We'd probably make it an invitational workshop - applicants
to send in short statements of areas of interest or positions
(2 pages) and limit to 75 or so.

I need to check with Mohamed Gouda, too, of course, but I want
to get your reaction first.

Vint
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 89 19:20:34 GMT
From:      wisner@cheops.cis.ohio-state.edu (Bill Wisner)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial up SLIP

A protocol called SLFP, developed at MIT, has been added to the Atari ST port
of KA9Q TCP/IP by a University of Michigan person, and has been implemented
on Michigan's MERIT network. It allows dial-up Internet access like SLIP,
but with an interesting twist. When an ST with KA9Q dials into MERIT, both
ends automatically begin talking SLFP. But MERIT dynamically allocates
the ST an IP address. The address assigned is different every time a
connection is made.

I'm told that there are plans to eventually allow for dynamic DNS updates:
when a host connects and is told its IP address, PTR and A records with a
TTL of zero will be added to a nameserver for the duration of the connection.
When the connection is broken, PTR and A records will be removed, leaving
only an MX record.

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 89 21:22:00 GMT
From:      jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial up SLIP


    Date: 29 Jan 89 19:20:34 GMT
    From: cheops.cis.ohio-state.edu!wisner@tut.cis.ohio-state.edu  (Bill Wisner)

    A protocol called SLFP, developed at MIT, has been added to the Atari ST port
    of KA9Q TCP/IP by a University of Michigan person, ...

Cool.  Any idea offhand where I might find source etc? (For both ends)
Is the U of M person Howard Chu?

Thanks for any info.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 02:46:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: sigcomm '89

Larry,

how would you feel about a special one-day workshop after
the SIGCOMM 89. Dave Mills and I have been thinking about
having such a workshop to focus on "Limits of the Internet" -
to try to helpfocus attention on areas needing research.
In theory, this would also be helpful to ISO since much of
the ISO protocol base is patterned like the TCP/IP internet.

We'd probably make it an invitational workshop - applicants
to send in short statements of areas of interest or positions
(2 pages) and limit to 75 or so.

I need to check with Mohamed Gouda, too, of course, but I want
to get your reaction first.

Vint

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 06:17:32 GMT
From:      johnan@ism780c.isc.com (John Antypas)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial up SLIP

>    A protocol called SLFP, developed at MIT, has been added to the Atari ST port
>    of KA9Q TCP/IP by a University of Michigan person, ...

Could you send me the UofM info when you find it?

Thanks.

-- 
John Antypas -- Interactive Systems 
...!{haddock, uunet, sdcrdcf}!ism780c!johnan johnan@ism780c.isc.com
All Statements (C) 1989 John Antypas -- Interactive can't have them!
They're mine!  Do you hear????  All mine!!

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 06:22:37 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   FTP "STRU VMS" extension


    One of the problems with implementing FTP under VMS is mapping VMS
file types into FTP TYPEs and STRUctures. Within the confines of the
FTP protocol specification, it isn't possible to, for all VMS file
types (e.g. ISAM files), FTP them in a particular fashion (i.e. TYPE I
or STRU R) and between two VMS machines and get the same file you
started with.

    MultiNet has a non-standard extension to FTP to allow
transfer of arbitrary VMS files between consenting VMS machines
called "STRU VMS". We have an agreement with one other VMS TCP
vendor to implement STRU VMS in a compatible fashion.

    STRU VMS works by prefixing the file contexts with a structure
which describes the RMS attributes of the file, and then sending the
contents of the file, uninterpreted, by using VMS block I/O.  The
structure is designed to allow the addition of new RMS attributes,
while still preserving upward and downward compatibility with the
original specification.

    I would be interested in hearing from any other VMS FTP
implementors, including our competitors, for the purpose of starting a
discussion about the proposed extension to FTP. When we reach a
consensus about how STRU VMS should work, we will publish the
resulting specification in RFC form.

						Kenneth Adelman
						TGV, Incorporated

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Jan 1989  14:42 MST
From:      Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
To:        Crawford%wo3.worms-emh1.army.mil@WORMS-EMH1.ARMY.MIL
Cc:        packet-radio@WSMR-SIMTEL20.ARMY.MIL, TCP-IP@SRI-NIC.ARPA
Subject:   TCP Info - ka9q TCP/IP
    Has there been a change to location for TCP info [at Simtel20]?  I have
    been trying to acces PD1:<MISC.KA9Q-TCPIP> with no success for
    the last week.  Where should I look?  Is there a way to get
    a complete list of all the directories on PD1?
    73, Jerry DA2CY/K7UPJ

Yes, the <MISC> directory was moved to the PD2: device as part of a
disk reorganization to equalize storage.

The ka9q TCP/IP files are in the PD2:<MISC.KA9Q-TCPIP> directory.

--Keith Petersen
Maintainer of the CP/M & MSDOS archives at wsmr-simtel20.army.mil [26.0.0.74]
DDN: w8sdz@wsmr-simtel20.army.mil
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 13:37:52 GMT
From:      trn@warper.jhuapl.edu (Tony Nardo)
To:        comp.protocols.tcp-ip
Subject:   CAMBRIDGE-MB and RESTON-DCEC-MB playing "Gateway ping-pong"?

Since Thursday (1/27), I've noticed that the our link from the MILNET to the
ARPANET has once again become rather fragile.  Quite frequently, I've had
network connections drop.  Invariably, after being disconnected, an attempt
to "ping" the target node will yield either

	36 bytes from 26.21.0.104: icmp_type = 3 (Dest unreachable)
    or	36 bytes from 26.1.0.49: icmp_type = 3 (Dest unreachable)

followed by eight longwords in hex format.

Since my target node is always the same, it would seem that the Butterflys at
CAMBRIDGE-MB and RESTON-DCEC-MB are still grabbing control of network packet
routing from each other.

Perhaps more infuriating, I've noticed that if I "ping" the offending gateway
I can the reconnect to the target system almost immediately.  "pinging" each
of these gateways in the background also seems to make my connections to other
sites survive a little better.  (I don't *like* doing this, but I also don't
like watching ftp choke after I've transferred >200 Kb of a 300 Kb file. :-(  )

Question: is there any information that a person who is *not* on a gateway
system (like myself) can gather which would help track or solve this problem?
-------				----------------			-------
ARPA,	trn@aplcomm.jhuapl.edu,		UUCP:	{backbone!}mimsy!aplcomm!trn
BITNET:	trn@warper.jhuapl.edu

	programming (v): the art of debugging a blank sheet of paper.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 16:13:33 GMT
From:      abstine@sun.soe.clarkson.edu (Arthur Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

From article <890129222237.9d@TGV.COM>, by adelman@TGV.COM (Kenneth Adelman):
> 
>     I would be interested in hearing from any other VMS FTP
> implementors, including our competitors, for the purpose of starting a
> discussion about the proposed extension to FTP. When we reach a
> consensus about how STRU VMS should work, we will publish the
> resulting specification in RFC form.
> 
> 						Kenneth Adelman
> 						TGV, Incorporated
Dale Moore & Co at CMU have done this with CMU/TEK FTP. They use 
STRU PAGE to accomplish the same thing between two machines using 
CMU FTP. You might want to talk to him about it
(Dale.Moore@moore.fac.cs.cmu.edu) and find out the internals of it.

art stine
sr network engineer
clarkson u

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 17:59:56 GMT
From:      hpda!hpwala!johns@ucbvax.Berkeley.EDU  (John Silva)
To:        tcp-ip@sri-nic.arpa
Subject:   Status on NCSA Telnet ??

   Can anyone update us on the status of the latest version of the NCSA Telnet
program ??  I remember reading that the next version was due out
this January and it would include support for BOOTP, SLIP, and the ability
to use arbitrary ports (other than the telnet port, 23).  Should we just
watch here for an upcoming announcement ??

   Thanks,
	John Silva
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 18:21:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension

Ken,

Wollongong's WIN/TCP for VMS has had FTP extensions for transmitting
arbitrary file types for quite awhile.  When we first announced this --
probably in the info-vax list -- there was a question about using a
public standard.  At the time, we had our focus on functionality, but
are more than somewhat interested in moving to an inter-operable spec,
as always...

Dave Crocker
VP, Engineering
The Wollongong Group, Inc.

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 19:12:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Worm and other 3B TCP/IP security fixes available

A small point of clarification, to the note sent by Brian Kantor, concerning
the timing of software releases to close the worm-exploited security holes.

We provided AT+T with fixes immediately after the worm attack was diagnosed
and they made it available to their requesting hotline customers also
immediately.  The reference to the January, 1989 release is for customers
NOT directly requesting the software.

Dave Crocker
VP, Engineering
The Wollongong Group, Inc.

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 19:37:28 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension

Kenneth,

The aproach you suggest works against interoperability and therefore must
be approached with suspicion.  If STRU VMS, then also STRU MVS?  What if
you want to FTP an ISAM file from a VMS to an MVS system? Is this 
infeasible?

Bob Braden

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 89 23:14:30 GMT
From:      peters@CC.MSSTATE.EDU (Frank W. Peters)
To:        comp.protocols.tcp-ip
Subject:   Subnets on an unsubnetted network

Hello,

     A recent posting by Tom Corsetti brought to mind several questions 
which we wrestled with and often left unanswered.

     We, like Mr. Corsetti, have a large un-subnetted class B network.  
Addresses on this network are assigned in a subnetted fashion (that is,
all of the nodes in a given building have the same third octet to allow
for subnetting at a later date).

     In a couple of buildings on campus we have Sun servers with two
ethernet cards and diskless workstations 'behind' them to provide nfs
traffic isolation.  Each network of clients has its own 'subnet' of the
campus class B network.

     We are not exactly sure about how to configure the gateway suns
to allow them to be subnetted (for the clinets on one side) and still
have full connectivity with the unsubnetted campus network. 

     As it now stands we have the following problems:

(1) Broadcast Addresses: As it now stands, the subnetted machines address
    broadcasts to (say) 130.18.64.255 instead of the common address of
    130.18.255.255.  Is there any reason why we can't take advantage of
    the broadcast option of the UNIX ifconfig command to have a subnet mask
    of 255.255.255.0 and a broadcast of 130.18.255.255?  should the broadcast
    be the same on BOTH sides of the gateways?  Does it matter if its the
    same?  That is, can the broadcast be x.x.255.255 on the campus side and
    x.x.y.255 on the client side?
 
    As it now stands, every time a subnetted machine on the 130.18.64.0 net
    (which is really part of the unsubnetted campus net) sends a broadcast 
    the subnetted machines on (say) the 130.18.48.0 net (which is also part
    of the same campus net but, because of subnetting, THINKS its on a
    seperate subnet) don't recognize the broadcast and attempt to arp the
    130.18.64.255 broadcast address.

(2) Routing (1):  Given a gateway sun that is on the unsubnetted campus backbone
    but that THINKS it is on a subnetted network, how do we convince it that
    it can reach a machine directly that is not on its 'subnet'?  That is,
    how do we convince a subnetted gateway machine on the 130.18.64.0 portion
    of the backbone that it can directly reach a machine on the 130.18.48.0
    portion?  As it is now configured all packets of this sort are routed to
    our proteon routed...which turns right around and sends it back out the
    same interface.  Gross huh?

(3) Routing (2):  Are there any options besides proxy arp to allow the gateway 
    suns to grab packets off of the backbone and routing them through their
    client sides?  This is basically the common problem of an unsubnetted
    machine sending a packet to a machine that is not REALLY on the same wire.
    We have a public domain proxyarpd package for suns but can't get it to
    compile on a sun 4.

(4) Sorta-Subnetting:  This is a possibility that may solve all of our 
    problems if I only understood it.  I note that (on a Sun at any rate) it
    is possible to assign subnet masks (and subnetting alltogether) on an
    interface basis.  What would it mean to have a gateway with two subnets
    for the same network on two different interfaces?  Would it help?  Would
    it WORK? How about one interface subnetted and one not (thats pretty much
    what we logically want)?

     Any comments or suggestions would be welcome.  Please don't suggest 
subnetting the campus backbone though.  We just don't have the budget for 
the routers yet.

                    Thanks
                    Frank Peters

=====================================================================
Systems Programmer                 |   Mississippi State University
Phone:    (601) 325-2942           |   Computing Center and Services
Internet:  peters@CC.MsState.Edu   |   Post Office Drawer CC
BITNET:    PETERS@MSSTATE.BITNET   |   Mississippi State, MS.  39759
=====================================================================

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 00:02:43 GMT
From:      mec@ardent.com (Michael Chastain)
To:        comp.protocols.tcp-ip
Subject:   Reconciling /etc/hosts, yp, and named?  (SUMMARY)

Here's the summary of responses to my question, "how do you reconcile
/etc/hosts, yp, and named".  Thanks to all ~25 respondents.

We haven't made a decision for our product yet, but we're leaning
towards the "/etc/svcorder" solution.



SHORT SUMMARY

Don't invent your own weird or different scheme for this problem.

Don't use a yp map for a service provided by the Domain Name System.
At least make it possible for customers who hate yp to configure their
systems to not use it.

Look at Ultrix 3.0 /etc/svcorder; look at SunOS 4.0; look at Hesiod
(a BIND extension from MIT project Athena).

Get Sendmail 5.59.  You'll need it for MX support anyways.  Use BSD
rather than Sun source, because having sendmail call YP loses big-time.



LONG SUMMARY

Three people described the Ultrix 3.0 scheme, which is: "a control file
(/etc/svcorder) to specify what service(s) and which order.  i.e.
BIND, YP, LOCAL  for name resolver, yellow pages, and/or local
/etc/hosts".  [This looks like the best scheme to me.]

Casey Leedom <casey@gauss.llnl.gov> posted a good description of SunOS
4.0, which I'll summarize:

The resolution order is:

	Yellow pages
	Name server
	/etc/hosts

The major problem with this is that "the YP protocol doesn't have the
ability to return ... a name server request timed out".  This causes
programs like sendmail to get stuck in a loop talking to a YP server.
In the specific case of sendmail, which is the major victim, the
problem can be avoided by using BSD 5.59 sendmail and the following
resolver order:

	Name server
	/etc/hosts

[I think Sun's solution is inferior to /etc/svcorder, but a lot of
people have Suns and probably like this arrangement.]

Anti-yp quotes: Milo Medin <medin@nsipo.nasa.gov> writes "if you punt
yp completely, you'll be better off" and "you just can't make things
work right by calling the resolver routines from yp".  Steve Miller
<steve.mimsy.umd.edu> writes "Note that it's important for your
customers to be able to purge YP entirely from their systems without
causing any catastrophes".  Craig Partridge <craig@nnsc.nsf.net> warns
that if your sendmail uses yp name resolution, and a name server goes
down, "you are also potentially blasting dozens or hundreds of packets
per second across the network.  Furthermore, there are situations in
which this situation is stable."  [Punting yp certainly simplifies the
problem, and I gather there are a lot of arguments pro and con this
position.  I don't want to start a yp war on the net!  Enlighten me via
e-mail if you must!]

Casey also makes an important point about choosing an existing scheme
instead of inventing our own:

"People will spend no end of time bitching at your company if they have
to do something weird and different on your machines for no functional
gain."

[Agreed!]

Michael Chastain  mec@ardent.com    "He who dies with the most
Ardent Computer   uunet!ardent!mec  FRIENDS wins."

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 00:33:10 GMT
From:      dab@opus.cray.com (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension

Kenneth Adelman writes:

>     MultiNet has a non-standard extension to FTP to allow
> transfer of arbitrary VMS files between consenting VMS machines
> called "STRU VMS". We have an agreement with one other VMS TCP
> vendor to implement STRU VMS in a compatible fashion.
> 
 ...
>     I would be interested in hearing from any other VMS FTP
> implementors, including our competitors, for the purpose of starting a
> discussion about the proposed extension to FTP. When we reach a
> consensus about how STRU VMS should work, we will publish the
> resulting specification in RFC form.
> 

Rather than extend the STRU command of ftp to add "STRU VMS", how
about doing it through the SITE command instead?  From RFC959, pg 33:

    SITE PARAMETERS (SITE)

	This command is used by the server to provide services
	specific to his sytem that are essential to file transfer
	but not sufficiently universal to be included as commands in
	the protocol.  The nature of these services and the
	specification of their syntax can be stated in a reply to
	the HELP SITE command.

It seems to me that the SITE command is the one to use when adding
non-standard extensions to FTP.  (I've just finished expanding our
ftp server to allow "SITE UMASK", "SITE CHMOD", "SITE IDLE" and
"SITE HELP".  UMASK and CHMOD do the expected UNIX stuff, IDLE can
be used to change the length of the idle timer, which gets reset
everytime something happens, and if it goes off it closes the
connection.  In 4.3BSD this defaults to 15 minutes.  HELP is used
to find out the syntax for using these site specific commands)

Note that any BSD based ftp does not support the "site" command,
but they do support the "quote" command, so you can still make
use of the site command by issuing commands like "quote SITE UMASK".

		-Dave Borman
		Cray Research, Inc.

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 02:28:46 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension


    I was hoping that I wouldn't have to defend the need for a "STRU VMS"
but here goes...

> The aproach you suggest works against interoperability and therefore must
> be approached with suspicion.  If STRU VMS, then also STRU MVS?  What if
> you want to FTP an ISAM file from a VMS to an MVS system? Is this
> infeasible?

    The idea is to provide a 'standard' way of transfering an arbitrary
VMS file UNINTERPRETED through the network. There are two reasons for this:

    1) Performance. Take your nearest VMS FTP and look at the ASCII mode
       performance as compared to the BINARY mode performance. Any
       transformation between VMS disk blocks and something like STRU Page
       is going to have a similar impact. The extra pass you have to make
       at the data can really matter on a small VAX.

    2) The need for such an extension to FTP is already recognized by
       many VMS TCP vendors. What I want is a 'standard' which will
       allow each of these different *VMS* FTP implementations to
       speak the same language.

    There is also another advantages to my proposal:

       Implementation of it is already very close to what most vendors
       provide in a non-interoperable fashion. Hopefully the small
       amount of work required to convert to the standard would
       encourage other vendors to adopt it as well. A standard without
       any implementations isn't any good to the community at large.

    This is *NOT* an attempt to solve a very difference problem such
as FTPing beasts like ISAM files between VMS and MVS. Even if FTP
contained a specification to allow any of today's VMS file types to be
FTPed, we're back in the same boat when DEC adds a NEW file type.

> Rather than extend the STRU command of ftp to add "STRU VMS", how
> about doing it through the SITE command instead?  From RFC959, pg 33:

    I'm aware of the SITE command, but my understanding was that
the SITE command was reserved for `non-standards', whereas this
proposal would only be useful as an extension to the protocol. As I
said above, I'm looking for more than just us to implement this.

    Perhaps what we need to add to FTP is a "STRU O VMS", where O is
short for operating system, and the resulting structure is the
VMS-specific one defined...

    I'm not sure this is appropriate to involve the entire TCP-IP list
in this discussion.  Anyone interested receiving copies of future
correspondance, please send mail to stru-vms-request@tgv.com.

							    Ken

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 06:59:45 GMT
From:      KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension

Just to throw a little more fuel on the STRU VMS fire:

I think you make a valid (though orthogonal) point about interoperability
in the face of "non-traditional" files.  At the moment we have interoperable
ways of moving ASCII text, raw BINARY bytes and (at least in some FTP
implementations) BINARY variable length records.  It would also be nice
to be able to interoperably move files such as ISAM and TEXT with non-imbeded
print-control but we don't even have any standards for the interoperable
representation of the data.

In the meantime, there are 2 issues that the VAX/VMS FTP world needs to deal
with:
	1) The ability to transfer, in a transparent fashion, arbitrary
	   VAX/VMS files to/from other cooperating machines.

	2) The ability to take advantage of the knowledge that both sides in
	   the FTP transfer are VAX/VMS machines to maximize the FTP
	   throughput by not having to do any data conversion before putting
	   the file data "on-the-wire".

The suggestion of a STRU VMS was consistent with semantics of the STRU
command.  Interoperability is not sacrificed as long as non-VAX/VMS
sites continue to (correctly) reject the STRU VMS command. All the
VAX/VMS clients that will adhere to this standard will attempt to use
STRU VMS when first communicating with the server but upon the rejection
of the STRU VMS command will revert to the interoperable behavior.  The
result we have is that clients that support STRU VMS will initially ask
servers for STRU VMS.  If they receive a success, then this "enhanced-VMS"
FTP communication mode will be used.  If they receive a failure, well then
we are back to the current situation (where STRU VMS doesn't exist).

There have been suggestions that the SITE command be used for this extension.
I am not overly enthusiastic about this -- the transfer mode implied by
STRU VMS is really exclusive of STRU [F, R or P] and not something orthogonal.
When you are no longer in STRU VMS then you want to explictly be in
STRU [F, R or P].

There has also been a suggestion of using STRU P for this extension.
Semantically it feels better to me than using the SITE command but, as
Ken Adelman has already pointed out, in conforming to the FTP STRU P
specification we lose a considerable amount of efficiency.

In conclusion, what we are asking for here is NOT anything intended to
be interoperable with non-VMS sites (although the way VMS clients need
to be written will ensure interoperability with non-VMS sites).  We need
some way of allowing consenting sites (I would assume these to be exclusively
VAX/VMS sites) to dynamically "upgrade" their class of FTP service.

David
-------

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 07:21:22 GMT
From:      bc@halley.UUCP (Bill Crews)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: netbios over tcp-ip

In article <328@lakesys.UUCP> deanr@lakesys.UUCP (Dean Roth) writes:
>Check with Excelan. I seem to recall the company having a
>NETBIOS - TCP/IP product.

Yes, they do, as do Ungermann-Bass, Bridge Communications (oops, that's 3Com
now), and others.

-bc
-- 
Bill Crews                        bc@halley.UUCP
(512) 244-8350                    ..!rutgers!cs.utexas.edu!halley!bc

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Jan 89 18:03:29 EST
From:      Cyndi Mills <cmills@ccy.bbn.com>
To:        tcp-ip@sri-nic.arpa
Subject:   FTP "STRU VMS" extension
> We don't need to add vendor propriatary stuff to FTP.  Binary
> and network ascii seem sufficient to me.  Encoding and decoding before
> and after a binary file transfer can be used ...
> ... (In UNIX terms, encoding == dump, decoding == restore).

In theory, I agree with Phil.  Any type of compression/encryption/encoding
program that includes O/S-specific file information can have as its output a
file.  The contents of the file may be transferred via FTP to another machine
which runs a program to reverse the algorithm to decompress/decrypt/format the
result into a file.

This approach treats FTP as a bulk-transport mechanism, NOT as an intelligent
file-transfer mechanism that converts between file representations, but is
handy for several applications, such as distributing software among like-minded
O/S (the compressed .z files under UNIX come to mind.)

The drawback is that it usually requires a two-step process. How do you
transfer an entire directory tree, for example, within FTP, if a requirement
for that transfer is that the O/S-specific attributes of each file is preserved
across the transfer?  The user must remember to decode each file upon exiting
FTP, but he may not know the names of all the files in the transferred
directory or how many there are.  This can complicate automated procedures.
Also, the intermediate undecoded files can pose problems in naming space and
disk space.

The first purpose of the SITE VMS or STRU VMS command is to allow a
pre-specified two-step process to be performed automatically within the FTP
command to each file AS IT IS TRANSFERRED, where this process is so common that
it might be applied to every file in a directory.  This eliminates the two-step
process, the problems of storing or naming an intermediate file, and the
problems of applying this process in automated scripts or to entire directory
trees.

Second, if you are implementing an O/S-specific command, I applaud the attempt
to have it be the same across multiple TCP/IP implementations, to improve
interoperability.  Since you are trying to specify a useful VMS "protocol
extension" as an ad-hoc standard, you might consider including not only the RMS
headers, but flags to indicate compression and/or encryption that might be
optionally implemented.  Or a field to specify a procedure, command file, or
program to be executed upon completion of each individual file transfer to
perform these and/or other conversions.

Sample command: > SITE VMS ENCRYPT COMPRESS
style		> SENDTREE [LOCALDIR] [REMOTEDIR]

						Cyndi Mills

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 1989 19:47-EST
From:      CERF@A.ISI.EDU
To:        cpw%sneezy@LANL.GOV
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Loose and Strict source routing
Phil,

Unless I'm badly mistaken, there isn't any guarantee that
a non-source-routed internet packet has a valid source
address. Of course, responses to such a spoofed packet may
not make it back to the origin unless a cooperating gateway
helps out, or the source is on an Ethernet and is operating
in promiscuous mode. I suggest that, if source authentication
is an issue, you will need stronger tools/mechanisms than
avoiding the use of source routing of either type.

The general problem of authentication in the Internet is
very important, applies to many areas including, for example,
various control methods (e.g. network management subsystems)
and will probably require some form of cryptographic protection
to solve. The cryptography need not be used to conceal
information - merely to provide an unforgeable authentication
of the source.

Vint Cerf
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 15:12:50 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Loose and Strict source routing

RFC 1009 states that it is important for gateways to implement both the
Loose and Strict Source Route IP options (Page 13).  Why?

Hacker's in the know have indicated that, with those tools, they can
bypass IP address checks which various hosts have set up to attempt a
source host access check.

Is it worth considering not honoring these options in a production
environment such as MILNET and ARPANET?   Or, could Hosts be required
to have an operating system option which allows an administrator to
signal that these packets be dropped?  What other ways are there to
defend against this kind of internet spoofing?

Are there other ways to spoof a source address in an Internet
environment besides LSRR and SSRR?

Phil Wood, cpw@lanl.gov

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 15:52:54 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension

We don't need to add vendor propriatary stuff to FTP.  Binary
and network ascii seem sufficient to me.  Encoding and decoding before
and after a binary file transfer can be used when the file is some form of
random access, master indexed, indexed, mostly empty, massively addressable
database.  (In UNIX terms, encoding == dump, decoding == restore).

Phil Wood,  cpw@lanl.gov

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 18:31:16 GMT
From:      sandy@TOVE.UMD.EDU (Sandy Murphy)
To:        comp.protocols.tcp-ip
Subject:   terminating connections

A few months ago I posted a message to this list asking for comments of the
difference between the ISO TP and TCP connection establishment services --
specifically, the reason for / necessity for TCP's symmetric system.
Encouraged by the number of kind people who had very interesting answers,
I would like to pose a similar question (you knew there was a reason to
ignore such requests!):

TCP and ISO TP differ in how they handle connection termination.  TCP
performs a graceful close, ensuring that data in transit is received 
before the connection is closed.  ISO moves this up to the session layer
with the two session entities doing their own exchange of I'm-done-transmitting
messages.  Since TCP accomplishes the graceful close by FIN messages
that are given sequence numbers one greater than the last data sent,
it looks to me like TCP is doing something similar.  That is, it is 
as if TCP were inserting its own I'm-done-transmitting message in the
data stream.  Because the session layer can count on the transport layer
to deliver data in sequence, it need only check the data for the
I'm-done message.  But TCP must devote considerable processing to
ensure that the FIN is acted upon at the appropriate time, etc.

Does anyone have any comments on whether this belongs in the transport
or session layers, further effects of doing it TCP's (ISO's) way,
agreements/disagreements with my interpretation, etc.

--Sandy Murphy

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 19:49:22 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension


	
	    I'm aware of the SITE command, but my understanding was that
	the SITE command was reserved for `non-standards', whereas this
	proposal would only be useful as an extension to the protocol. As I
	said above, I'm looking for more than just us to implement this.

Actually, the SITE command is intended for operating-system-specific
extensions.  It is the place I would have put (and DID put, in the UCLA
ACP in 1975) put such operating-system-specific extensions to FTP as
those you propose.  SITE provides a legal way to make system-specific
extensions without breaking the rest of the standard.  Of course, the
multiple vendors of network code for VMS should agree on the SITE
parameters for this purpose!
   ...
   
	    I'm not sure this is appropriate to involve the entire TCP-IP list
	in this discussion.  Anyone interested receiving copies of future
	correspondance, please send mail to stru-vms-request@tgv.com.
	
Actually, issues of interoperability and standards, vs. ad hoc protocol
extensions (nice word), seems like a very appropriate issue for this 
forum.

Bob Braden
	

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 20:03:12 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension

Phil Wood suggests that anything other than binary (and network ascii,
but by extension we could even do without that) is unnecessary for FTP
since we can have encode and decode filters in a pipeline at either end
of an FTP transfer.  The problem with this suggestion is that FTP does
not support in any standard fashion the idea of reading from or writing
to a filter.  Without some such mechanism, I'd have to *log in* on the
remote system, encode the file, then log out, run FTP to get it in
binary mode, then run the decode.  But maybe I just have FTP read
access and not login priviliges on the remote system!

One alternative to the STRU VMS suggestion is to bury a set of
permitted filters in the remote filename space supported by a
particular implementation, e.g. something suitably gross like:
	FTP> bin
	FTP> put "|encode foo.bar;3" "|decode foo.bar" 
VMS implementations would then only have to agree on the syntax and
function of the filters they supported (note that "|decode myfile.txt"
is a legal Unix file name, but not a legal VMS file name, so there is
no ambiguity).

Note that the different VMS FTP implementations already have non-null
mappings from the ftp-allowed file specifications to the local file
names.  For example, TWG's FTP server allows pseudo-Unix remote file
names, and translates them into valid VMS filespecs ("|decode foo.bar"
currently becomes "9cdecode$7afoo.bar;1").

I prefer STRU VMS.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 20:07:49 GMT
From:      mrc@TOMOBIKI-CHO.CAC.WASHINGTON.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Unix TCP connectivity problems


     I cannot verify this 100%, but observation suggests that if Unix receives
an ICMP Network Unreachable message it causes select() and/or read() to return
an error.  Most applications programs consider this condition to indicate a
fatal loss of connectivity and they blast the connection away.

     I've observed this problem with SUNs, VAXen, and NeXT machines.

     I've had telnet and rlogin sessions suddenly blow away in the middle of
typein/echoing (with no human-noticable echo delays).  Since Unix doesn't have
the PDP-10 concept of "detached jobs" this means I lose whatever work I was
doing at the time.  I can reconnect back immediately.

     I've seen client/server interactions where the server got the error and
in the course of cleaning up sent a text string that got to the client!

     Can anyone shed any light on this?  What can applications programs do to
protect against this?  Is there a kernel patch that keeps intermittant errors
(a gateway spazz?) from blowing away healthy connections?

     I wish I could provide more details, but until we get our network monitor
I can't say for sure what it is that is biting us.  I know that it hits me
several times a day.

-------

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 20:18:21 GMT
From:      davec@CSUFRES.CSUFRESNO.EDU (David C. Choweller)
To:        comp.protocols.tcp-ip
Subject:   sites

Does anyone know if there is a list of internet sites available, sorted
geographically?
David C. Choweller      (California State University, Fresno)

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 20:21:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension

Ahem!!

Back to first principles:  If there is a strong constituency and multiple
implementations, a standard should be developed.

When we first came out with our upgrade to FTP, to allow transfer of
arbitrary VMS files, there were no other implementations to talk to and
we STILL had customers demanding that we create/conform to a standard.

Certainly, it is reasonable to try to bury the VMS-ness into a clean
framework, preferably permitting addition of other operating systems.
However, based upon the feedback we got some months ago, there is no doubt
in my mind that we need to make the spec public and certified.

Dave Crocker
The Wollongong Group, In.c

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 21:15:10 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnets on an unsubnetted network

OK, you've got a central network with 130.18.1 to 130.18.63, and
a Sun connecting this network to a small Ethernet with 130.18.64 on
it.  What I think you want to do (and I confess I haven't tried
this) is:

  on the interface to your small Ethernet, leave things as a
	normal subnet, i.e. subnet mask 255.255.255.0, and
	broadcast address 130.18.64.255.

  on the interface on the central network, set the broadcast address
	(it's a parameter to ifconfig) to 130.18.255.255.  I think
	you want to leave the subnet mask as 255.255.255.0.  If
	you try to use a subnet mask of 255.255.0.0 on this
	interface, routing is likely to get very confused.

  route add 0 <your address on the main network> 0

  run the proxy ARP daemon.  (I'm sure I heard somebody say there
	was a version that worked under 4.0.  It's got to be completely
	different than the 3.2 version.)

The "route add" will cause your Sun to treat any address it doesn't
know about as being attached directly to your main network.  This
assumes that any gateways you have to connect you offsite will respond
to ARP requests for addresses offcampus.  If your exterior gateway
doesn't have a complete proxy ARP implementation (I've heard rumors
that this is true for Proteon), then you're going to have to do

  route add 130.18.1.0 <your address on the main network> 0
  route add 130.18.2.0 <your address on the main network> 0
  ... 

for all subnets on the main network.  Or if you have one gateway
somewhere that knows all your subnets, run routed and get routes from
it.

I don't see any way to make things work unless you can get proxy
ARP running.  However if you have a Sun (or other system with
similar facilities) anywhere else on the network, you can do

  arp -s <hostname> <etheraddress> pub

for every host on your subnet.  This causes the machine to do
a kind of hard-wired proxy ARP.  When it sees an ARP request
for <hostname> it will respond with <etheraddress>.  <Etheraddress>
should be the address of the Sun that's acting as the gateway
to your subnet.  You can't do this on that Sun itself, because
it needs to know the actual Ethernet addresses of those machines.

By the way, I'm not sure that this whole business is really the right
way to do things.  The moment you have different machines on your main
network with different subnet masks, things will get very exciting.
The ICMP subnet mask broadcasts will tend to cause machines to
randomly change subnet masks.  I think I'd set up every machine that
knows about subnet masks to use a mask of 255.255.255.0.  Then use the
"route add 0" commands as described above to tell it to use the main
network for all the subnets.

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 21:24:20 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: netbios over tcp-ip

PC DOS emulation on UNIX machines generally comes in two flavors.  Flavor
number one is a board that has an 80X86 on it that you stuff in your whatever
computer (for example the SUN Integrated Personal Computer) that runs your
DOS applications for you.  Flavor number two is that if you happen to be
running UNIX on a 80386, then you are probably running Interactive Systems
port of UNIX (386/ix, though it may have someone elses name on it).  The
80386 has enough smarts to run virtual 8086s in user mode so it's just
a matter of software.  386/ix has this thing with the Phoenix BIOS that
runs DOS applications under UNIX via this method.

As for the XNS stuff.  My condolences.  SUN probably makes a package
that might work.  You could try to start using TCP on your PC's :-)

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 89 23:03:29 GMT
From:      cmills@CCY.BBN.COM (Cyndi Mills)
To:        comp.protocols.tcp-ip
Subject:   FTP "STRU VMS" extension

> We don't need to add vendor propriatary stuff to FTP.  Binary
> and network ascii seem sufficient to me.  Encoding and decoding before
> and after a binary file transfer can be used ...
> ... (In UNIX terms, encoding == dump, decoding == restore).

In theory, I agree with Phil.  Any type of compression/encryption/encoding
program that includes O/S-specific file information can have as its output a
file.  The contents of the file may be transferred via FTP to another machine
which runs a program to reverse the algorithm to decompress/decrypt/format the
result into a file.

This approach treats FTP as a bulk-transport mechanism, NOT as an intelligent
file-transfer mechanism that converts between file representations, but is
handy for several applications, such as distributing software among like-minded
O/S (the compressed .z files under UNIX come to mind.)

The drawback is that it usually requires a two-step process. How do you
transfer an entire directory tree, for example, within FTP, if a requirement
for that transfer is that the O/S-specific attributes of each file is preserved
across the transfer?  The user must remember to decode each file upon exiting
FTP, but he may not know the names of all the files in the transferred
directory or how many there are.  This can complicate automated procedures.
Also, the intermediate undecoded files can pose problems in naming space and
disk space.

The first purpose of the SITE VMS or STRU VMS command is to allow a
pre-specified two-step process to be performed automatically within the FTP
command to each file AS IT IS TRANSFERRED, where this process is so common that
it might be applied to every file in a directory.  This eliminates the two-step
process, the problems of storing or naming an intermediate file, and the
problems of applying this process in automated scripts or to entire directory
trees.

Second, if you are implementing an O/S-specific command, I applaud the attempt
to have it be the same across multiple TCP/IP implementations, to improve
interoperability.  Since you are trying to specify a useful VMS "protocol
extension" as an ad-hoc standard, you might consider including not only the RMS
headers, but flags to indicate compression and/or encryption that might be
optionally implemented.  Or a field to specify a procedure, command file, or
program to be executed upon completion of each individual file transfer to
perform these and/or other conversions.

Sample command: > SITE VMS ENCRYPT COMPRESS
style		> SENDTREE [LOCALDIR] [REMOTEDIR]

						Cyndi Mills

END OF DOCUMENT