The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1 Jul 90 16:22:42 GMT
From:      Mills@udel.edu
To:        "Daniel B. Davison" <zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!uhnix2!davison@tut.cis.ohio-state.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  IP addresses of timechimers needed
Daniel,

See the file pub/ntp/clock.txt on louie.udel.edu. I thought a pointer to
this file was included in the ntp and xntp distributions, but maybe not.

I am the person who made rfc1119, rfc1128 and rfc1129 PostScript files and
I will speak firmly right back for reasons you will understand upon reading
them. If you need hardcopy, pass along your address.

Dave
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 90 00:05:40 GMT
From:      cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!scslwide!wsgw!wsserva!onoe@tut.cis.ohio-state.edu  (Atsushi Onoe)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: parallel networks routing question
In article <7042@star.cs.vu.nl> sater@cs.vu.nl (Staveren van Hans) writes:

> so two multihomed hosts connected with parallel networks.
> Further suppose that network B is preferable to network A, because of
> load, or because it is 10x as fast (FDDI vs Ethernet).
> How would one set up addressing and routing for such a configuration?

I think you can increase metric number for interface A.
For example,
	ifconfig FDDI B.1 ...
	ifconfig ETHER A.1 .... metric 1
	                        ^^^^^^^^
--
Atsushi Onoe	<onoe@sm.sony.co.jp>
   Workstation Div., SuperMicro Group, Sony Corporation.
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 90 00:44:19 GMT
From:      mcdchg!ddsw1!karl@rutgers.edu  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   MAC Email Services from Unix Systems
We're looking for a package (PD, Shareware or commercial is fine) that will
give us Email connectivity with Unix machines.

We have uShare loaded on a Sun workstation.  It comes with a Mail desk
accessory which, unfortunately, doesn't work at all (it gives System Bombs
and fails to write or delete messages).  This service DOES, however, permit
printer and file services, and those aspects appear to work properly.

We need email connectivity.  Ideally the package would interact with
the Unix system such that you could use Unix mailboxes, although I am
willing to settle for a daemon that reads the Unix mailbox and re-writes in
a Mac-style format somewhere else... or even something that is opened and
runs in the background receiving via SMTP (we have Multifinder on our
machines).

Help!  Commercial informaiton is fine, as are pointers to things or phone
calls (even from salesmen!).  We can FTP if needed as well.

This is a high priority item; any and all help appreciated.

Note that the reply address is NOT the same as where this message is being
posted from (I'm at home right now and prefer to receive replies at work).

Please email rather than post replies.

Thanks!

--
Karl Denninger (kdenning@ksun.naitc.com, <well-connected>!ddsw1!karl)
AC Nielsen, Bannockburn, IL	(708) 317-3285
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 90 03:29:12 GMT
From:      agate!shelby!lindy!ddaniel@apple.com  (D. Daniel Sternbergh)
To:        tcp-ip@nic.ddn.mil
Subject:   Finding whois responders
Is there any way to find out which hosts respond to whois requests?
I'm looking for a master list of hosts which handle whois, and the
sites they serve.  Does such a thing exist?  Is there a way (short of
sending whois requests to every host) of creating such a list?

Please send e-mail, since I do not read this newsgroup.

Many thanks,

	== Daniel ==

---------------------------
D. Daniel Sternbergh  
ddaniel@lindy.stanford.edu
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Jul 90 10:08:14 edt
From:      tsuchiya@thumper.bellcore.com (Paul Tsuchiya)
To:        forster@cisco.com, idunno!princeton.edu!tengi@louie.udel.edu, ietf-rreq@jessica.standord.edu, tcp-ip@nic.ddn.mil
Subject:   Re: non-contiguous masks

|> 
|> he ya go, campers. anyone wish to rise up and define a good reason to keep
|> non-contigious subnet bits, assuming we require the ability to have more
|> than one address on an interface . . . . . .
|> 

I beleive that there is a very good reason for keeping non-contiguous masks.
It turns out that there is a very efficient and flexible method of assigning
addresses that requires non-contiguous masks to work.  It is something that
I recently have proposed for ABOVE the network level (to address the issues
of both scaling and address depletion), but it can work perfectly well below
the network level.

The idea is very simple, and it works for any number of hierarchy levels.
Basicly, you assign addresses from the bottom up, as they are needed.
Initially, when a subnet needs some addresses (when it is first created),
you give it just enough address space to cover its needs (the first
multiple of two above the actual number of addresses they need).  In
other words, they have a mask that has just enough zeros to cover all
their hosts.  Later, when a subnet needs new addresses, what you do is
find a bit in their mask that 1) currently is a "1", and 2) can be changed
to a "0" without stealing addresses from some other subnet.  In other
words, you double their allocation of address space by flipping a mask
bit from a "1" to a "0".  By doing this, none of the subnet's existing
addresses are invalidated--they still match under the same routing
entry.  By only handing out addresses when they are needed, you use
the address space very efficiently (like, possibly over 50% utilization).

I will be talking about this at the UBC IETF meeting (plenary).  I would
love to come to router requirements and talk about it there specifically,
or if anyone is interested, I have a postscript paper (draft) that talks
about this stuff and some other interesting aspects of scaling.

Oh, and by the way, patricia still works just fine with non-contiguous
masks (at least the way I assign them).  In fact, I think the use of
non-contiguous masks speeds up patricia, because since you are packing
the meaningful information into a smaller number of bits, patricia
needs to sort through a fewer number of bits to get the right result.

PT

_________________________________________________________________
Paul F. Tsuchiya		Bellcore
tsuchiya@thumper.bellcore.com	435 South St.
201-829-4484			MRE 2L-281
201-267-9298 (FAX)		Morristown, NJ 07960
_________________________________________________________________ 
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Jul 90 10:10:09 EDT
From:      jbvb@vax.ftp.com (James Van Bokkelen)
To:        CSYSMAS@OAC.UCLA.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: What Size IP on TR?
   Date:    Fri, 29 Jun 90 15:41 PDT
   From: Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>

   An example is a RIF which says 2052 where there are routers to
   Ethernet (max IP packet size of 1500).  Any IP packet larger than
   1500 will get fragmented.

Most modern TCP implementations have Maximum Segment Size option handling
which attempts to avoid fragmentation when traversing routers.  If the
transport protocol you're concerned with is layered on UDP, you are
likely to find that you must tweak things manually.

At any rate, what I was saying was that there was a time when you
*had* to say "2052" in your RIF, or some IBM TCP/IP implementations
wouldn't talk to you at all.  Thus, you are likely to find that as
a widely-used default...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 90 10:43:44 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!umbc3!digennar@tut.cis.ohio-state.edu  (Mr. Jerry DiGennaro)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA software and Novell Servers

At Loyola College, we would like to put the NCSA telnet and ftp packages
on our Novell file servers so that users can get to the various servers.

Is this legal?

Will it work?  Is the NCSA software "sharable" by many users from the
server perspective?

What is the current version of the software?

Have I missed anything?

Thanks in advance.


Jerry DiGennaro			digennar@umbc3.umbc.edu
					(301) 532-5129
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 90 11:09:35 GMT
From:      bu.edu!dartvax!litle!tom@uunet.uu.net  (tom hampton)
To:        tcp-ip@nic.ddn.mil
Subject:   errno 77 on read of socket
We have been doing some high volume tests of ISC's latest release of
TCP/IP.  Things look pretty good except for an occaisional (1/1000)
error generated on a read of a socket -- errno 77, bad data packet.

What does this error mean?

Where should we look to fix it?
-- 
===============================================================================
 Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
 603 643 1832 
-------------------------------------------------------------------------------
 Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@litle.com  tom@litle.uucp  {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Jul 90 01:49:42 -0400
From:      ehj@psi.com (Eric Jensen)
To:        tcp-ip@nic.ddn.mil
Subject:   RATP (rfc916) - has anyone implemented it?
Greetings,

Can someone tell me:
 1) What implementations of RATP exist?
 2) What the experiance with those implementations has been?
 3) Is there something "better"?  (although rfc916 impresses me as
    well thought out (well written too))

Thank you,

eric
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Jul 90 23:32:57 EDT
From:      droms@hydra.bucknell.edu (Ralph E. Droms)
To:        tcp-ip@nic.ddn.mil
Subject:   Questions about TCP/IP protocol suite implementations

In connection with the work of the IETF Dynamic Host Confguration
working group, I'd like to conduct a small survey by asking the
following two questions:

1) Which router vendors implement BOOTP?  Which implementations would
break if the BOOTP protocol were enhanced by, say, a new set of BOOTP
operations?  Which implementations provide the forwarding function in
which broadcast BOOTP requests are retransmitted and the response(s)
returned by the router?

2) Which implementations of TCP/IP (either host or router or whatever)
would break if a new address class were introduced?  Which would break
if network address 0 were used as a special purpose address; e.g., if
network address 0 were used for packets destined for hosts on the same
subnet and packets with destination network address 0 were
specifically not forwarded by routers?

Please reply directly to me...

- Ralph Droms                 Computer Science Department
  droms@bucknell.edu          323 Dana Engineering
                              Bucknell University
  (717) 524-1145              Lewisburg, PA 17837
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 90 19:37:07 GMT
From:      netwrx1!mindel@uunet.uu.net  (Joshua L Mindel)
To:        tcp-ip@nic.ddn.mil
Subject:   Questionnaire:  Does your FTP provide "open", "verbose", and "quote"?

I'd like to determine whether the following three user commands are provided by
the vast majority of FTP client programs:  

		OPEN		-Establish a connection to the specified host
				 FTP server.  

		VERBOSE		-Toggle verbose mode.  Among other things, "on" 
				 displays FTP reply codes. Example reply codes
 				 visible with verbose mode on are:  
					220 Service ready
					331 User name ready
					230 User logged in
					450 Access denied 

		QUOTE		-Send the arguments specified verbatim
				 to the remote FTP server.

Can you help me out and let me know whether or not the package(s) you know
about provide these three functions?  Please respond via email to me directly, 
indicating:

	1. Name of the ftp software package 
	2. Operating system on which it runs.
	3. Whether your implementation provides these functions, but uses
	   different command names.

Thank you.
-------------------------------------------------------------------------------
Joshua L Mindel, Senior Analyst		Internet:  mindel%netwrx1@uunet.uu.net
NetWorks One				Usenet:	   uunet!netwrx1!mindel
Vienna, Virginia  USA			Phone:     (703) 827-7767
-- 
-------------------------------------------------------------------------------
Joshua L Mindel, Senior Analyst		Internet:  mindel%netwrx1@uunet.uu.net
NetWorks One				Usenet:	   uunet!netwrx1!mindel
Vienna, Virginia  USA			Phone:     (703) 827-7767
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 90 19:49:21 GMT
From:      usc!wuarchive!swbatl!uucigj@ucsd.edu  (Greg Jensen - UCI - 5-3531)
To:        tcp-ip@nic.ddn.mil
Subject:   PC to Sun sparc via slip/modem

	I would like to get a little clearer understanding about using a SL/IP
	connection between a PC and a Sun using a 2400 baud modem.  If I get
	a version of ka9q for the PC and I use the sliplogin for the Sun will I
	be able to make the connection and use say; ftp or telnet?  Which
	binary of ka9q for the PC do I need? (net.exe?).  Is there a version of
	slip available that allows dialout from the PC?  Am I correct in the
	understanding that to get ka9q to get connected to the Sun over the
	2400 baud modem that I have to use another comm package to actually
	dial the phone and get the connect, then back out of the comm package
	without hanging up and startup the ka9q program?  On the Sun side, I
	have a program that can be used as the program to be started after
	logging in named sliplogin.  I have added the appropriate parameters to
	the kernel and have successfully built a new vmunix. I tried the
	example test situation according to the following:

                stty -tostop
                sliplogin 192.12.180.1 192.12.180.2 < /dev/ttya &
                sliplogin 192.12.180.2 192.12.180.1 < /dev/ttyb &
	
	with a short cable with the appropriate wires crossed.  As soon as I
	start one it finishes, which I thought was supposed to continue until
	killed.  Am I supposed to have something else running?  Is this all
	that I need to let my PC communicate (other than the modems)?  Is there
	a better PD slip package, for both PC and Sun?

	To top this off is there a PD package available to accomplish an NFS
	mount on the PC? I would like to find out if the PC-NFS is possible
	over a serial line (via modem, not direct connect) and if it someone
	has donated it to the Public Domain.  Otherwise if this is possible
	what is the cost of such a program?

	Excuse these somewhat overpublished questions, but I have not been able
	to see the answers to all of these questions in one place. The basic
	question - what are the steps necessary to to accomplish this situation
	(connecting PC to Sun via modem using slip)?

      Gregg Jensen
   ---------------------------------------------------------------------- 
    These opinions are my own and do not necessarily reflect my companies.
      Southwestern Bell Telephone
      Send E-MAIL to the following address...
               ...!uunet!swbatl!uucigj
			   		- or you can try -
			   uucigj%gandalf.sbc.com@uunet.uu.net
   ---------------------------------------------------------------------- 
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 90 21:29:58 GMT
From:      netcom!netcom.uucp!jbreeden@apple.com  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   New AT&T Ethernet SIA chip
AT&T is rumored to be developing a new Ethernet SIA chip. Supposedly, and
this is third hand information, the chip has both 10BaseT and AUI outputs,
and can be changed via software, on the fly, between them. Also, it
doesn't appear that they have chosen a controller chip to mate with, but have
some way of interfacing with controllers from Intel, AMD, OR National;
ie: it works with all three.

Can anyone shed any light on this?  Does anyone have a phone number I can call?

Thanx in advance;
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Tue, 3 Jul 90 10:04:47 -0700
From:      chris@salt.acc.com (Chris VandenBerg)
To:        tcp-ip@nic.ddn.mil
Subject:   libc for SUN 4.0.3c
Good morning all,
	        I'm trying to get a SPARC/1 running with the resolver and I was told that I have to substitute a shared libc that the resolver, in
addition to adding the resolv.conf file. Does
anyone have one of these or know if one for
4.0.3c? And, does anyone know how this is set up
in SUNOS4.1? Please respond to me directly, I
don't want to waste bandwidth on so trivial a
request.
	Many thanks,
		    Chris VandenBerg
		    (chris@salt.acc.com)
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Tue, 03 Jul 90 08:55:12 PDT
From:      zsu@NISC.SRI.COM (Zaw-Sing Su)
To:        ora!minya!jc@BLOOM-BEACON.MIT.EDU (John Chambers)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Limited routing between IP networks.

John,

If I understand your problem correctly, EGP does exactly what you need 
for the star configuration.  Make your central set the "core".  For an 
arbitrary configuration, BGP is intended to solve the problem.  Talk to 
Guy Alms of IETF Interoperability Working Group.

Zaw-Sing
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 02:36:55 GMT
From:      uc!cs.umn.edu!wagner@tut.cis.ohio-state.edu  (Paul J. Wagner)
To:        tcp-ip@nic.ddn.mil
Subject:   network backups
I recently posted a request for information about the possibility of
backing up an Ultrix system to a VAX/VMS system over TCP/IP.  I
received responses regarding two current products, and a third
response containing a past summary of information about network backups
generally, from which I distilled the third item included here.
Edited summaries of the information I received follows. - Paul


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

1) From: nowicki@Legato.COM (Bill Nowicki)
           
You recently posted a note about network backups.  Our company recently
released a product that does that.  The first release is for SunOS, but
Ultrix is currently being tested, and VMS can be done on request.
Please contact us for more information, at 415-329-7880.

Thanks, Bill Nowicki
	Legato Systems
---------------------------
	Legato NetWorker: The Complete Backup and Recover Product

 Legato NetWorker is a unique, easy-to-operate product that protects
files against loss, network-wide.  At the same time, it speeds file
recovery so users never waste time re-creating valuable work.
 Legato NetWorker easily adapts to your environment.  It uses
industry-standard network protocols and no changes are made to the
operating system of any platform.  And as your network and volume of
files expands, NetWorker has the capacity and performance to handle
the load.
...
Available now: Call your local Unix software distributor or Legato at 
(415) 329-7880.



2) From: VANCE@TGV.COM (L. Stuart Vance)

Our MultiNet TCP/IP for VMS package supports an RMT (Remote MagTape) server,
allowing you to use the UNIX rdump and rrestore utilites to backup/restore
files from your ULTRIX box to your VMS system.  Please drop me a note if you
would like any additional information/details.

... the server allows UNIX systems that support the rdump and rrestore
utilities and PCs that have FTP Software's package (which has a port
of rtar) to access the VMS tape drive over the network.  Additionally
the RMT server allows you to rdump/rrestore to a VMS file (which you
can then copy to tape) if the rdump/rrestore directly to tape takes
longer than you'd like.


3) From: Alan Strassberg <plains!oetl1.SCF.LOCKHEED.COM!alan>
>From: tony@rata.vuw.ac.nz (Tony Martindale) - past summary re: network backups
 From:  Hans W. Barz, R.1032.3.34, CIBA-GEIGY, 4002 Basel, Switzerland
	 mail: whwb@cgch.uucp

 ... if you connect the systems
 with NFS you can write the backup with standard system backups to the
 central site. Retrieving a certain file for restore is awkward using
 NFS since the most backup routines scan through the whole backup (assuming
 it is a tape) to find the file. This delivers a high network load with a 
 low outcome.

 There is one similar solution around on top of Hyperchannel (at least for 
 VAX'es and IBM's) named HYPERTAPE (contact: MultiStream Systems 
 Incorporated, Denise Yegge, P.O.Box 497, Excelsior, Minnesota 55331, USA). 
 They had the plan to run it also on top of TCP/IP. This information is from 
 Feb. 1988, you may check if it is still true.

 *** note - I can find no entry for MultiStream Systems in the 1989-1990
Minneapolis, MN phone book - anyone know if this company still exists?
 - PJW ***


-- 
* Paul J. Wagner                Internet - wagner@cs.umn.edu              *
* Computer Science Department   UUCP	 - ...!rutgers!umn-cs!wagner      *
* University of Minnesota       or, 120 S. Michigan, Eau Claire, WI 54703 *
*     "think globally, act lexically"                                     *
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 02:38:38 GMT
From:      sunquest!gavron@uunet.uu.net  (Ehud Gavron)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Major bug in TALK on WIN/TCP for VMS
In article <28296.2689c707@vaxb.acs.unt.edu>, billy@vaxb.acs.unt.edu writes:
> Hi,
> 
> In WIN/TCP for VMS 5.1, TALK does not handle userids with numeric characters
> in them correctly.  
> 
> If anybody has any suggestions, please let me know. 

	Install MultiNet.  Its versions of TALK (as well as SMTP,
	FINGER, nameservice, R services, etcetera) all work as
	per the RFCs.

> Billy Barron                  Bitnet : BILLY@UNTVAX
> University of North Texas   Internet : billy@vaxb.acs.unt.edu
> 
> PS The ANONYMOUS account on TWG.COM gives a "User Authorization Failure"
>    message now.

	PS The ANONYMOUS account on TGV.COM (the developers of Multinet)
	   is full of useful information. :-)

	Ehud

-- 
| Ehud Gavron, Systems analyst  | sunquest!gavron@cs.arizona.edu (uucp)      |
| Sunquest Information Systems  | sunquest!gavron@uunet.uu.net   (alternate) |
| 930 N. Finance Center Drive   | gavron@sunquest.com            (domain)    |
| Tucson, Arizona, 85710        | (602)885-7700 x.2546           (AT&Tnet)   |
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 03:28:19 GMT
From:      ora!minya!jc@BLOOM-BEACON.MIT.EDU  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Limited routing between IP networks.
Well, here I am again with Yet Another Dumb Question...

The puzzle this week, which TFM doesn't seem to help much, comes from
a client who has various sets of machines, normally each set being one
IP network or subnet, or maybe two.  At times they want to interconnect 
the sets via a SLIP link, and when this is done, we should set up routing 
so that any machine in set A can talk to any machine in set B.  Later, 
and in generally overlapping, set B will be connected to set C, and any
machine in set B should talk to any machine in set C.

The tricky part that I can't answer is that they DON'T want the relation
to be transitive.  In the above case, machines in set A should not be
able to communicate with those in set C.  If they can, we don't get
the contract.  The most important configuration will be essentially
a star, with one central set having lots of links out to other sets,
but in fact, an arbitrary graph is a better picture to plan on.

Part of the problem, of course, is that it pretty much needs to be
automated.  If the solution requires any understanding of IP routing
on the part of the users, it won't work.  Solutions that require a
network hacker going in as super-user on each machine and adjusting
routing tables by hand are totally outside the ballpark.  We need
to provide a command of the form "Link host1 host2", which will
establish the link and set up the routing.  Later on another command
may be used to shut down the link (or more likely they will just
turn the modem off and walk away ;-).  

So can IP handle this?  More specifically, can any of the common routing
tools (arp, routed, gated, whateverd) be used so as to get the desired
limited routing.  If so, how might one do it?

I've been suggesting that they should pay me to rewrite routed and/or
gated to do the job the way they want.  This would probably be fun and
profitable and all that, but I suspect that it might be a waste, since
I do sorta have this suspicion that existing tools might already be up 
to the job, if I could decrypt the manuals.  (Let's see, they appear to 
be using mostly English words, and a syntax that is somewhat like that 
of English; the cleartext is likely in an Indo-European language... ;-)

-- 
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: [I've gotta get a new one of these some day.]
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 04:01:15 GMT
From:      hayes.fai.alaska.edu!wisner@decwrl.dec.com  (Bill Wisner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Major bug in TALK on WIN/TCP for VMS
In article <4875@sunquest.UUCP> gavron@sunquest.UUCP (Ehud Gavron) writes:

>	Install MultiNet.  Its versions of TALK (as well as SMTP,
>	FINGER, nameservice, R services, etcetera) all work as
>	per the RFCs.

There is no RFC for talk.

Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775
/* you are not expected to understand this */
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Tue, 03 Jul 90 10:36:40 EDT
From:      SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
To:        TCP/IP List <tcp-ip@nic.ddn.mil>
Subject:   What is tn3270?
What sort of animal is tn3270? Is it a standard protocol defined by
an RFC? What are its origins?

Thanks for you help.

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 08:36:20 GMT
From:      eru!luth!sunic!mcsun!hp4nl!star.cs.vu.nl!sater@bloom-beacon.mit.edu  (Staveren van Hans)
To:        tcp-ip@nic.ddn.mil
Subject:   parallel networks problem
Recently I posted a question to these groups to which, to my surprise,
I received no reactions at all. This seems strange since it addresses a
problem that many of us are going to face. Now there is of course the
possibility that this is so obvious that you were all embarrassed by
the question, but I doubt it.

Suppose part of a network looks like this

  ---------------------------------------------------------  network A
		|			|		|
	-----------------	-----------------   ----------
	|      A.1      |	|      A.2	|   |  A.3   |
	|    Host foo	|	|    Host bar	|   |Host zot|
	|      B.6	|	|      B.7      |   |        |
	-----------------	-----------------   ----------
		|			|
  --------------------------------------------------------- network B

so two parallel networks with some multihomed and some singlehomed hosts.
Further suppose that network B is preferable to network A, because of
load, politics or because it is 10x as fast (hint: FDDI vs Ethernet).
How would one set up addressing and routing for such a configuration?

Using the DNS address lookup you get two addresses for each machine,
but most software doesn't understand that currently and only uses the
first one. Now the documentation suggests that you can order the
addresses so that certain preferred networks come in front, but looking
at our bind source code shows that that is not implemented.

So host foo looks up host bar, and gets the address set (A.2, B.7).
Both addresses are on directly connected networks. How do you make
sure that either it uses B.7, or it uses A.2 but still routes it over
network B.

Ideally this should be done by the routing layer of course, but current
routing software will probably send a packet for A.2 onto network A, unless
a host route for A.2 points to B.7. You can of course set up all these
routes by hand, but if the network size increases this gets to be too
much trouble.

You could imagine that host bar propagates a host route for A.2 on
network B, and all hosts are persuaded that network A is expensive
by messing around with metrics, but that would lead to a proliferation
of host routes floating around the network, and maybe even propagating to
the rest of the Internet, which would be extremely undesirable.

How do people solve this? Do people actually have situations like this
already? Inquiring minds want to know.

	Hans van Staveren
	Vrije Universiteit
	Amsterdam, Holland
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Tue Jul  3 09:43:51 1990
From:      cctal!andrew@relay.EU.net
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP Info
	From andrew Wed Jun 27 12:00:24 1990
	To: ukc!nic.ddn.mil!tcp-ip-request
	Subject: SLIP Info
	Cc: andrew
	Date: Wed Jun 27 12:00:24 1990
	
	Second call for SLIP info
	=========================
	
	A couple of weeks ago, I posted to the net a request for people who were 
	using SLIP or ppp to mail me info on where they got it, what they had to
	do to it to make it work and what they are using it for, so that I could
	do a summary and post it to the net.
	
	The number of requests for the info far exceeded the contributions to the
	information and I notice that more questions about SLIP are turning up on
	the net, so I am taking this occasion to post for a second time to ask if
	anyone who missed or did not reply to the first posting and who is making
	SLIP or ppp work for its living could please mail me with the details.
	
	I have more or less got the info on the location of info on and the code 
	for SLIP and ppp (largely by my own researches) but I do need more on the
	implementation/management functions to make my report complete.
	
	Thanks if you contributed before and thanks if you are about to contribute.
	
	Andrew Hardie
	andrew@cctal.co.uk
	London, England
	

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 13:56:02 GMT
From:      sdd.hp.com!samsung!interlan.InterLan.COM!interlan.interlan.com!towfiq@ucsd.edu  (Mark Towfigh)
To:        tcp-ip@nic.ddn.mil
Subject:   Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)
Note the followup group is comp.protocols.tcp-ip, as I don't read
comp.unix.questions.

In article <1990Jul3.040115.12000@hayes.fai.alaska.edu>
wisner@hayes.fai.alaska.edu (Bill Wisner) writes:

   There is no RFC for talk.

I know this is true -- it's a problem because there are incompatible
versions of TALK out there.  Specifically, it seems there was a change
between the 4.2BSD talk/talkd and the one in 4.3BSD. I have a few
questions: does the current TALK daemon support both the old and new
versions?  And what about the client?  As far as I can make out, the
new talkd can tell the difference between the two protocols, and when
a remote user requests a connection, the local TALK daemon figures out
whether they are TALKing 4.2-style or 4.3-style, and then tells the
local user to run one of two programs, either /usr/ucb/talk or
/usr/old/talk.

All this aside, I have never seen this work with the 4.2 TALK, only
the 4.3 flavor.  Is there anyone out there running a system which can
talk in both styles, and deal with incoming and outgoing TALK
requests?
--
Mark Towfigh, Racal InterLan, Inc.                 towfiq@interlan.Interlan.COM
W: (508) 263-9929 H: (617) 488-2818                       uunet!interlan!towfiq

  "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 14:36:40 GMT
From:      SSJACK@ECUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   What is tn3270?

What sort of animal is tn3270? Is it a standard protocol defined by
an RFC? What are its origins?

Thanks for you help.

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 12:24:00 GMT+109:13
From:      "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Xerox 6085 and TCP/IP
Date sent:  3-JUL-1990 12:24:46 

Hi,
	Is there a realistic alternative to the expense of TCP/IP for Xerox 
6085's.  File transfer requirements are not really regular, and it seems to 
incur that kind of expense is overkill.

Thanks for any help,

Dave
================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 15:53:26 GMT
From:      snorkelwacker!bu.edu!dartvax!litle!tom@apple.com  (tom hampton)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Networking -- how do you make it work?
We have been banging away trying to get heterogeneous networking
over TCP/IP going at our shop.  We keep running into little snags,
we find problems and trudge on.  So, I ask:

1) Who out there is doing heterogeneous networking using
   Unix and other TCP/IP implemenations?

2) Is anyone having success doing networking on 386's?  If so, whose
   TCP/IP package are you using on the 386?

3) Do you have any specific advice on how we get this going faster?  For
   example, should we have a LAN analyzer (which one?) should we stick 
   with a certain box for development (Sun?)

4) Does anyone recommend building a TCP/IP module for general purpose
   use -- something that hides some of the complexity of the Berkely
   socket interface?

5) Do people hire consultants to do this sort of work??  Do you 
   recommend anyone in particular?

Your responses to these questions represents a valued resource to us, 
thanks for your time.
-- 
===============================================================================
 Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
 603 643 1832 
-------------------------------------------------------------------------------
 Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@litle.com  tom@litle.uucp  {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 18:17:59 GMT
From:      jik@athena.mit.edu  (Jonathan I. Kamens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)
In article <TOWFIQ.90Jul3095602@interlan.Interlan.COM>,
towfiq@interlan.Interlan.COM (Mark Towfigh) writes:
|> I know this is true -- it's a problem because there are incompatible
|> versions of TALK out there.  Specifically, it seems there was a change
|> between the 4.2BSD talk/talkd and the one in 4.3BSD. I have a few
|> questions: does the current TALK daemon support both the old and new
|> versions?

  No.  You have to run two different versions of talkd, one on the port
reserved for the old talk protocol, and one on the port reserved for the
new talk protocol.  On our system, old talk is 517 (with the service
name "talk"), and new talk is 518 (with the service name "ntalk").

  If you don't have the right daemons running on the right ports, then
talk clients are going to have trouble conversing with your machine.

|> And what about the client?

  Nope, the old talk client knows how to talk only to the old talk port,
and the new talk client knows how to talk only to the new talk port. 
Or, at least, that's how things *should* work, but alas, we live in an
imperfect world....

|> As far as I can make out, the
|> new talkd can tell the difference between the two protocols, and when
|> a remote user requests a connection, the local TALK daemon figures out
|> whether they are TALKing 4.2-style or 4.3-style, and then tells the
|> local user to run one of two programs, either /usr/ucb/talk or
|> /usr/old/talk.

  No, this isn't how it works, or at least not how it appears to be set
up in 4.3BSD.  There are two different talkd programs (/etc/talkd and
/etc/ntalkd is what we've got them named, but I don't know how universal
that is).  The hard-coded client name in the old talk daemon is
/usr/ucb/talk.old or /usr/old/talk, and the hard-coded client name in
the new talk daemon is /usr/ucb/talk.  The new talk daemon and the old
talk daemon don't know about each other, and don't know about each
other's protocols.

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 20:07:10 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)
There are two talk programs using two different protocols; the older
one still found on Suns and such is architecture and compiler dependent
and often won't work across heterogeneous hosts.  The newer talk will
work in such an environment but not everyone has it.  Since it's part
of the great Berkeley giveaway, you should get the newer talk and
install it.  It can coexist with the older talk because it lives on a
different port and has a different name.  4.3-Tahoe-BSD comes with both.
	- Brian
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 20:10:00 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: parallel networks problem
In article <7050@star.cs.vu.nl> sater@cs.vu.nl (Staveren van Hans) writes:
>Suppose part of a network looks like this
>
>  ---------------------------------------------------------  network A
>		|			|		|
>	-----------------	-----------------   ----------
>	|      A.1      |	|      A.2	|   |  A.3   |
>	|    Host foo	|	|    Host bar	|   |Host zot|
>	|      B.6	|	|      B.7      |   |        |
>	-----------------	-----------------   ----------
>		|			|
>  --------------------------------------------------------- network B
>
>so two parallel networks with some multihomed and some singlehomed hosts.
>Further suppose that network B is preferable to network A, because of
>load, politics or because it is 10x as fast (hint: FDDI vs Ethernet).
>How would one set up addressing and routing for such a configuration?

TOPS-20 had a concept (which I invented) called "preferred IP address"
and "preferred network" which answered this question.  There was, from
the beginning, a "default IP address" which was used in IP datagrams
where it was not obvious which local address of a multi-homed host was
best to use as the source IP address.

The problem was that very often network A would be a lower-speed
backbone and network B a higher-speed stub network.  The default
mechanism would ensure that host foo would use its A.1 address in
talking to host zot and host zowie on a network C (since the only way
to reach the B.6 address from outside of network B would be to go
through an A->B gateway, so you might as well use the A.1 address and
save a hop).  In talking to host bink which only had a B.8 address,
host foo would use its B.6 address.  The problem was which address to
use for bar.

Hence the "preferred" address and network, which would take precedence
in any choice between a "preferred" and any other (including the
default) address.  Foo and bar would make network A be "default" and
network B be "preferred."

I'm surprised Unix hasn't picked up on this yet.

 _____   | ____ ___|___   /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105
 _|_|_  -|- ||   __|__   /  / 6158 Lariat Loop NE   "Gaijin! Gaijin!"
|_|_|_|  |\-++-  |===|  /  /  Bainbridge Island, WA "Gaijin ha doko ka?"
 --|--  /| ||||  |___|    /\  USA 98110-2098        "Niichan ha gaijin."
  /|\    | |/\| _______  /  \ "Chigau. Gaijin ja nai. Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 21:11:12 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: parallel networks problem
You haven't gotten an answer because there's no good answer.  It
depends upon the routing and domain technology that you use, and even
then solutions tend to be kludges rather than general solutions.
We prefer to keep all routing knowledge in our routers, so generally
hosts do not run routing protocols.  Our routers do proxy ARP, so
we normally use default routes with a zero metric, i.e.

  route add default `hostname` 0

This causes all destinations to be treated as if they were on the
local Ethernet.  With more than one Ethernet address, I normally set
things up to use the default on the "preferred" Ethernet, and hardwire
routes for the specific subnets that I want on the other Ethernet.
Typically it's just the connected subnet, which of course happens
automatically.  The problem with this is that you don't automatically
change to take advantage of the secondary network if the primary one
is down.  However Ethernets so seldom go down that this isn't a
concern for me.  

In general the Internet has not solved the problem of how hosts find
routers, particularly with multiple Ethernets.  There are lots of
solutions known in principle, but the commonly used TCP/IP
implementations don't have the right features to use the known
solutions. 4.3 is a lot better than 4.2, but still doesn't really
supply all the necessary features.  The IETF hasn't helped, by failing
to specify a gateway-finding mechanism, such as the proposed "ICMP
wheres-my-gateway".
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 21:17:20 GMT
From:      umich!caen!math.lsa.umich.edu!math.lsa.umich.edu!emv@CS.YALE.EDU  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)

a word as to actual usage of these two talks across the nsfnet backbone -- in the
months where port-by-port statistics are kept on nis.nsf.net (the *PORTS files)
talk+ntalk (517+518) is in about the 0.2% - 0.3% range, with the amounts varying
quite substantially and talk generally having more traffic than ntalk.  Must be
lots of suns, I guess.  

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
comp.archives moderator
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 21:53:16 GMT
From:      dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   Xerox 6085 and TCP/IP

Date sent:  3-JUL-1990 12:24:46 

Hi,
	Is there a realistic alternative to the expense of TCP/IP for Xerox 
6085's.  File transfer requirements are not really regular, and it seems to 
incur that kind of expense is overkill.

Thanks for any help,

Dave
================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 22:06:13 GMT
From:      eru!luth!sunic!tut!kannel!kim@bloom-beacon.mit.edu  (Kimmo Suominen)
To:        tcp-ip@nic.ddn.mil
Subject:   Remote Printer Protocol (BSD lpd) documentation needed
I know this has been asked before in some newsgroup and I'm sorry to repeat
the question.  However I just ran into a problem which might be solved by this
RFC.

So - if anyone knows of a document describing the remote printer protocol also
known as lpd protocol (BSD lpd), would she/he be so kind and send me e-mail
telling where to get/access that document.  If it is described in a RFC then
the number of that RFC would be greatly appreciated.

Thanks for your attention
--
Kim              ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
"That's what    ( Kimmo    ! Lappeenranta U of Technology ! kim@lut.fi )
  *I* think."   ( Suominen ! Computing Centre  *  Finland ! KUULA::KIM )
                 ''''''''''''''''''''''''''''''''''''''''''''''''''''''
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 90 22:07:13 GMT
From:      uswat!matthews@boulder.colorado.edu  (John Matthews)
To:        tcp-ip@nic.ddn.mil
Subject:   Major Bug in QuickMail/MacTCP

We experienced a rather severe bug the other day with QuickMail.
We aren't sure why, but the Mac started broadcasting ~150 ARP
requests per second which put a tremendous load on every machine
attached to our ethernet.  The machine it was ARPing for responded
to almost every request.  The MAC appeared to ignore the responses
completely.  We called StarNine and told them about it.  They said
they had seen the problem before, but thought it only occurred if
you configured a default gateway and it went down.  This wasn't the
case for us because we didn't have a default gateway configured.
The host it was ARPing for was the primary mail server not a default
gateway.  They seemed to think it was a bug in MacTCP and not  
QuickMail but weren't sure.  Has anyone seen this bug before?
                        Thanks in advance, 
                                John Matthews 
                                matthews@uswat.uswest.com
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 90 00:08:32 GMT
From:      att!mcdchg!laidbak!obdient!bisnews!donl@ucbvax.Berkeley.EDU  (Donald P Leaman @ bisnews.UUCP)
To:        tcp-ip@nic.ddn.mil
Subject:   PD uucpd wanted
HELP!!!

We are looking for a PD product that will set up the NLS service
as a valid uucp device.  We have heard that there is a public-
domain package named/called 'uucpd' that will accomplish this simple
task for us.  Otherwise, if anyone knows how we can get our uucp to
start a TCP/IP connection, we would greatly appreciate any ideas or
pointers in the right direction.  I will be happy to post a summary of
responses if the case dictates.  We are running SCO UNIX 3.2 as I'm sure
this information will (could) be helpful.  Thanks in advance!

PS  Please email me directly, as I rarely read the news......


-- 
Donald P Leaman, Systems Engineer    | "Facts are stupid things"
Business Interactive Solutions, Inc. | -Ronald Reagan, 1988
Woodridge,IL [vox] (708)241-0010     |___________________________
E-mail:..clout!bisnews!donl (or) donl@bis.chi.il.us
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 90 04:21:23 GMT
From:      usc!samsung!munnari.oz.au!uniwa!aldetec!mawson@ucsd.edu  (Graeme Mawson)
To:        tcp-ip@nic.ddn.mil
Subject:   Clients/servers with TCP/IP on SysV
We have been trying to create a connection between two Unix machines running
SysV.  On one we have a client program sending connection requests and on the
other we have a server program listening for connection requests.  The machines
are connected via Ethernet using TCP/IP.  We have had no success - with the
client machine not receiving connection accepts from the server.  One 
fundamental problem seems to be binding a suitable well-known address to the
server.

Has anyone had any success with a similar arrangement?

Can anyone offer any advice/help?

Thanks in advance...
Graeme

...........................................................................
:  ___  :   Graeme Mawson - Electronic Engineer, Aldetec Pty Ltd (Perth)  :
:  \ /  :   Internet: mawson@aldetec.oz.au    ACSnet: mawson@aldetec.oz   :
:  -|-  :   ph. 61 +9 445-1888 x255			                  :
:  / \  :   Legendary quote: "Sometimes a cigar is just a cigar" - Freud  :
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 90 05:03:31 GMT
From:      netcom!bobb@apple.com  (Bob Beaulieu)
To:        tcp-ip@nic.ddn.mil
Subject:   Printing with TCP-IP

We just got a pyramid M1E (mips) based system (sysv) at work and have it
set up at work running informix 2.10.03K sql 4gl. It connected to a Plexus
P/60 (m68000) (sysv) via ethernet tcp-ip.

I am having no problem sending data to a printer on the Plexus in Informix
using the following command (while on the pyramid)::

report to pipe "cat |/usr/ucb/rsh <systemname> 'lp -d<printername>'"

But, what I can't do it send OPTIONS to a printer on the Plexus side from
the Pyramid? I've tried modifying/creating various interface script to
handle #of copies and various printer control options (compress,etc.)
and would appreciate any help ...

I would like to end up with a script that can take an 'lp -d<printername>'
command and send this, and any -o options on one system and send the
command thru the ethernet to the <printername> on another system.

Thanks for any help.

Bob Beaulieu
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 90 09:08:22 GMT
From:      njin!uupsi!sunic!sics.se!brad@rutgers.edu  (Brad Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Accessing Ethernet multicast in Unix.
I am working with some people who are doing some work where they
would like to use Ethernet multicasts from Unix (SunOS 4.x in
particular).  How does one go about doing this.  Some things I've
read seem to indicate that the ethernet drivers need to be modified
to support multicasting... is this true, and if so is their such a
modified driver available?

Thanks in advance,

Brad Smith
Swiss Federal Institute of Technology
brad@imhfhp14.epfl.ch
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 04 Jul 90 16:24:17 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        mcdchg!ddsw1!karl@rutgers.edu (Karl Denninger)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: MAC Email Services from Unix Systems
Cayman has a nice system called GatorMail which will provide this,
they are located in Cambridge, MA and via email at cayman.com.

Good Luck,

Marty
------------

 We're looking for a package (PD, Shareware or commercial is fine) that will
 give us Email connectivity with Unix machines.

 We have uShare loaded on a Sun workstation.  It comes with a Mail desk
 accessory which, unfortunately, doesn't work at all (it gives System Bombs
 and fails to write or delete messages).  This service DOES, however, permit
 printer and file services, and those aspects appear to work properly.

 We need email connectivity.  Ideally the package would interact with
 the Unix system such that you could use Unix mailboxes, although I am
 willing to settle for a daemon that reads the Unix mailbox and re-writes in
 a Mac-style format somewhere else... or even something that is opened and
 runs in the background receiving via SMTP (we have Multifinder on our
 machines).

 Help!  Commercial informaiton is fine, as are pointers to things or phone
 calls (even from salesmen!).  We can FTP if needed as well.

 This is a high priority item; any and all help appreciated.

 Note that the reply address is NOT the same as where this message is being
 posted from (I'm at home right now and prefer to receive replies at work).

 Please email rather than post replies.

 Thanks!

 --
 Karl Denninger (kdenning@ksun.naitc.com, <well-connected>!ddsw1!karl)
 AC Nielsen, Bannockburn, IL	(708) 317-3285
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 04 Jul 90 14:49:41 EDT
From:      Caleb Strockbine <QOP%CORNELLA.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP, for VMS)
Steve-

I've got one version of talk running already... the daemon doesn't
run all the time (some daemon, eh?) but instead it's called by the
"master internet daemon" called inetd, which also calls a bunch of
the other communication daemons, but only when they're necessary. As
far as I know, we don't have ntalk, which seems to be the newer version
of talk, so maybe I'll look for that so we'll be able to talk to
anyone.

I wondered about that message about Mac/Unix connectivity, and whether
that wasn't the same thing we're trying to do. Maybe I'm beginning to
get the hang of this!

-Caleb.
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Jul 90 16:28:14 EDT
From:      BDK@UNB.CA
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Ethernet - printer interfaces
There are a few companies that have parallel port to ethernet adapters.
The one with which we have experience is from a company called XIRCOM.
They can be reached at (818) 884-8755.
Brian Kaye
University of New Brunswick

On  Wed, 4 Jul 90 15:34:22 GMT  Ricard Wolf
<rochester!kodak!uupsi!sunic!lth.se!newsuser@RUTGERS.EDU> writes:

> Hi out there!
>
> I'm looking for some sort of interface/protocol converter that enables
> a generic parallel (Centronics-type) or serial (RS-232 etc) printer to
> be hooked up to an ethernet network. The unit shuold be able to handle
> a variety of protocols (ftp, telnet etc).
>
> Anyone know of anything?
>
> Please email any responses.
>
> Thanks in advance,
> --
> ---
> Ricard Wolf
>
> +--------------------------+-------------------------------------+
> | Ricard Wolf              | Lund Institute of Technology        |
> | email: e85rw@efd.lth.se  | If you can't buy 'em - build 'em !! |
> +--------------------------+-------------------------------------+
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 90 15:34:22 GMT
From:      rochester!kodak!uupsi!sunic!lth.se!newsuser@rutgers.edu  (Ricard Wolf)
To:        tcp-ip@nic.ddn.mil
Subject:   Ethernet - printer interfaces
Hi out there!

I'm looking for some sort of interface/protocol converter that enables
a generic parallel (Centronics-type) or serial (RS-232 etc) printer to
be hooked up to an ethernet network. The unit shuold be able to handle
a variety of protocols (ftp, telnet etc). 

Anyone know of anything?

Please email any responses.

Thanks in advance,
-- 
---
Ricard Wolf

+--------------------------+-------------------------------------+
| Ricard Wolf              | Lund Institute of Technology        |
| email: e85rw@efd.lth.se  | If you can't buy 'em - build 'em !! |
+--------------------------+-------------------------------------+
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 90 18:04:53 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: parallel networks problem
In article <7050@star.cs.vu.nl>, sater@cs.vu.nl (Staveren van Hans) writes:
> Recently I posted a question ...
> Further suppose that network B is preferable to network A, because of
> load, politics or because it is 10x as fast (hint: FDDI vs Ethernet).
> How would one set up addressing and routing for such a configuration?
> ...
> 	Hans van Staveren
> 	Vrije Universiteit
> 	Amsterdam, Holland


This problem exists within FDDI itself.  FDDI is a dual ring of two 100Mbit
counter rotating rings.  100Mbit/sec is only 10 times faster than 10MHz
ethernet, and so is not considered "fast" by some of us.  Notice that
workstations today are 100 times faster than in the early 1980's when 10MHz
ethernet became popular (i.e. 0.25-1.0 VUPS then and 5 to 200 VUPS now)
(1 VUPS=1 "MIPS"=1 VAX 11/780).

The birthday paradox ensures that either an FDDI ring will almost never be
"wrapped" or it will be partitioned too much of the time.  This means that
dual attached, dual-MAC stations could at least in principle push more
bytes than single-MAC stations.

Unfortunately, the only currently publically demonstrated and known scheme
for using both rings involves using two IP networks, one for each ring.
This works, but is at best a clunky kludge.  In the absense of some smarter
routing, applications must somehow split their traffic between two IP
hostnumbers.  There are applications for which this is not a hardship, but
it is in general far from satisfying.

Proposals for combining both rings into a single IP network have been made,
but to the best of my knowledge, there is no such single-IP network proposal
that has had all of the holes, gotchas, and boundary cases covered.  The
single-network proposals involve varying but substantial amounts of
complexity in the link layers, including extensions to ARP.

As far as I know, the current draft standards (ie. IETF) suggest using a
dual-IP-network until a single-IP-network scheme is completed and accepted.

It would be really swell if someone could solve the FDDI-ethernet load
balancing problem that at least two people have mentioned in recent months
in this forum.  It would make the trivial to implement dual-IP-network
solution for FDDI tolerable, eliminating the need for the complicated
ARP and other link layer extensions needed for the single-IP-network ideas.


Vernon Schryver
Silicon Graphics
vjs@sgi.com
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 90 18:49:41 GMT
From:      QOP@CORNELLA.BITNET (Caleb Strockbine)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP, for VMS)

Steve-

I've got one version of talk running already... the daemon doesn't
run all the time (some daemon, eh?) but instead it's called by the
"master internet daemon" called inetd, which also calls a bunch of
the other communication daemons, but only when they're necessary. As
far as I know, we don't have ntalk, which seems to be the newer version
of talk, so maybe I'll look for that so we'll be able to talk to
anyone.

I wondered about that message about Mac/Unix connectivity, and whether
that wasn't the same thing we're trying to do. Maybe I'm beginning to
get the hang of this!

-Caleb.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Jul 90 09:24:27 -0500
From:      konda@zeus.mgmt.purdue.edu (Suresh Konda)
To:        tcp-ip@nic.ddn.mil
Subject:   Unsubscribe
Please unsubscribe me from this list.  Thanks.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 5 July 1990  08:10-MDT
From:      "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To:        SSJACK%ECUVM1.BITNET@NCSUVM.NCSU.EDU
Cc:        WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject:   Unix tar uncompression
Jack,

The following files are available from this host via anonymous ftp or
by formatted requests from LISTSERV@RPIECS or LISTSERV@NDSUVM1:

PD1:<MSDOS.SQ-USQ>

COMPRS16.ARC  B   47101  880409  Unix-compatible compress/uncompress - 16 bit
DECOMP2.ZIP   B   17384  900430  Unix-compatible 16 bit uncompress, w/C source

PD1:<MSDOS.FILUTL>

PDTAR.ARC     B  117152  880614  Read/write TAR files on PC
TAR.ARC       B   37392  871208  Read Unix TAR files on a PC

PD1:<MSDOS.STARTER>

PK361.EXE     B  119598  880801  Fast file ARC make/extract PKPAK/PKUNPAK v3.61
PKZ110EU.EXE  B  140116  900402  Katz's ZIP archive package v1.10, export vers.
TARREAD.EXE   B   14928  870820  Read Unix TAR files on a PC

--Frank
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 02:57:17 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)
In article <EMV.90Jul3171720@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>a word as to actual usage of these two talks across the nsfnet
>backbone -- in the months where port-by-port statistics are kept on
>nis.nsf.net (the *PORTS files) talk+ntalk (517+518) is in about the
>0.2% - 0.3% range, with the amounts varying quite substantially and
>talk generally having more traffic than ntalk.  Must be 
>lots of suns, I guess.  

FYI, the talk/ntalk protocol is just used for connection setup.  Once
people agree to talk, both protocols contain "pointers" to TCP ports
to carry the actual conversation on.  In fact, these "pointers" are
what caused the inability for "talk" to function in a heterogeneous
environment (without all kinds of heuristic gyrations, that is).

-- 
Warner Losh			imp@Solbourne.COM
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 Jul 90 07:51:06 EDT
From:      SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
To:        TCP/IP List <tcp-ip@nic.ddn.mil>
Subject:   Unix tar uncompression
I need a means of uncompressing UNIX tar files for a PC. Is there a
PC based utility available for this?

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 Jul 90 10:48:49 EDT
From:      Jonathan Charles Cohn <jcohn@note2.nsf.gov>
To:        TCP-ip@NSF.GOV
Subject:   Re: parallel networks problem
OSPF does have some of the features required to put higher priority on 
certain networks.  However, I do not know how it interfaces with hosts
that are not multihomed.  

Jonathan Cohn
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 Jul 90 14:16:41 EDT
From:      Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU>
To:        SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu, TCP/IP List <tcp-ip@nic.ddn.mil>
Subject:   Re: Unix tar uncompression
>I need a means of uncompressing UNIX tar files for a PC. Is there a
>PC based utility available for this?

There may be others, but PC/tar is included in FTP Software's PC/TCP
package.  It will even use rsh or rexec to access a tar file on a Unix
system directly, without a separate file transfer step.

Note that tar does not compress/uncompress files.  If you are referring
to compressed tar files (*.tar.Z), you'll need to find a PC version of
uncompress (or zcat) as well.

Doug Nelson
Michigan State University
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 Jul 90 14:34:25 EDT
From:      Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU>
To:        SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu, TCP/IP List <tcp-ip@nic.ddn.mil>
Subject:   Re: What is tn3270?
>What sort of animal is tn3270? Is it a standard protocol defined by
>an RFC? What are its origins?

TN3270 refers to an implementation of the Telnet protocol in which both
parties agree to use the native 3270 byte stream to represent the host
and terminal data.  The agreement to use 3270 mode is done by standard
Telnet option negotiations.  A defacto standard exists for this option
negotiation, but has never been defined in an RFC, although a proposed
replacement has (see RFC 1041; don't know as it has been implemented).

Doug Nelson
Network Software Manager
Michigan State University
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 11:51:06 GMT
From:      SSJACK@ECUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   Unix tar uncompression

I need a means of uncompressing UNIX tar files for a PC. Is there a
PC based utility available for this?

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 14:54:22 GMT
From:      samt19!hq!terry@PENTAGON-AI.ARMY.MIL  (Terry Bernstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for Network Management Software
I am looking for a good network management software package. 

We manage an enterprise-wide LAN.  It consists of a broadband backbone
with numerous baseband segments.  On the broadband we use 3-Com
hardware.  We use several Sun 3/260s to manage the LAN.

We are looking for software to help us detect and isolate network
faults.  We currently use some in house developed software to 'ping'
network devices, but don't use the 3-Com management statistics
extensively.  

Sun-Net manager might fill our needs, but we aren't sure.  Any
comments on this software and other suggestions would be appreciated.

-- terry --
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 16:13:09 GMT
From:      maytag!gamiddle@iuvax.cs.indiana.edu  (Guy Middleton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: The history of net numbers
In article <57885@bbn.BBN.COM> mckenzie@labs-n.bbn.com (Alex McKenzie) writes:
> Since there have been a number of questions about the history of network
> number assignments, I've searched the "Assigned Numbers" RFCs to see
> what light they could shed on the subject.  Here's what I found:

A related question: in which document is the network number for the Central
University of Mars assigned?
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 Jul 90 20:52:26 EDT
From:      Harold Pritchett <HAROLD@uga.cc.uga.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: libc for SUN 4.0.3c
On Tue, 3 Jul 90 10:04:47 -0700 Chris VandenBerg said:
>Good morning all,
>	        I'm trying to get a SPARC/1 running with the resolver and I was told
> that I have to substitute a shared libc that the resolver, in
>addition to adding the resolv.conf file. Does
>anyone have one of these or know if one for
>4.0.3c? And, does anyone know how this is set up
>in SUNOS4.1? Please respond to me directly, I
>don't want to waste bandwidth on so trivial a
>request.

Hold on there a minute.  If anyone can get the resolver to work with 4.1,
please post it to the list.  We have not been able to get it to work either,
and so far we have not gotten any help from SUN as it appears they can't get
it to work either.

Harold C Pritchett         |  BITNET:  HAROLD@UGA
BITNET TechRep             |    ARPA:  harold@uga.cc.uga.edu
The University of Georgia  |    uucp:  gatech!ugacs!csun2!harold
Athens, GA 30602           |    fido:  1:370/60
(404) 542-3135             |     Bbs:  SYSOP at (404) 354-0817
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 18:10:57 GMT
From:      usc!sdd.hp.com!samsung!xylogics!bu.edu!dartvax!litle!tom@ucsd.edu  (tom hampton)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP slowdown and window field of packet
We are having a slow-down problem between two TCP/IP programs.

Both programs do fine for a while, transferring some 50,000 bytes/sec,
until all of a sudden, they appear to hang and transfer no more than
1/100th of that.  According to a crude packet monitor we have, the 
problem seems to occur when the window field of the packet gets set
down (we don't know by whom) to 0.

1) Has anyone had this problem before?  We fear it might have something 
   to do with an interacticion between Stratus (VOS) TCP/IP and ISC
   2.2 Unix for the 386.

2) Are we right in thinking that it has something to do with the 
   window field?

3) Any suggestions on how might complete our diagnosis, or, better yet
   treat the situation?


Thanks for your replies.

-- 
===============================================================================
 Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
 603 643 1832 
-------------------------------------------------------------------------------
 Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@litle.com  tom@litle.uucp  {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 18:16:41 GMT
From:      08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix tar uncompression

>I need a means of uncompressing UNIX tar files for a PC. Is there a
>PC based utility available for this?

There may be others, but PC/tar is included in FTP Software's PC/TCP
package.  It will even use rsh or rexec to access a tar file on a Unix
system directly, without a separate file transfer step.

Note that tar does not compress/uncompress files.  If you are referring
to compressed tar files (*.tar.Z), you'll need to find a PC version of
uncompress (or zcat) as well.

Doug Nelson
Michigan State University

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 18:34:25 GMT
From:      08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: What is tn3270?

>What sort of animal is tn3270? Is it a standard protocol defined by
>an RFC? What are its origins?

TN3270 refers to an implementation of the Telnet protocol in which both
parties agree to use the native 3270 byte stream to represent the host
and terminal data.  The agreement to use 3270 mode is done by standard
Telnet option negotiations.  A defacto standard exists for this option
negotiation, but has never been defined in an RFC, although a proposed
replacement has (see RFC 1041; don't know as it has been implemented).

Doug Nelson
Network Software Manager
Michigan State University

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 20:16:04 GMT
From:      ingr!b11!griffin@uunet.uu.net  (Tommy Griffin)
To:        tcp-ip@nic.ddn.mil
Subject:   telnet and pc's

We're experiencing some difficulty communicating between our
workstations and PCs using Telnet over TCP/IP.  The PCs are running
Sun's PC/NFS product through the 3-Com Ethernet card.

The problem occurs when a Telnet session has been established from a
PC to a workstation, and the workstation is generating a continuous
stream of output to be displayed by the PC.  The PC begins to display
the output, but instead of displaying a continuous stream of data, new
data is displayed at intermittent intervals with 1-20 second delays
between bursts of output.  The delay usually ramps up to 20 seconds
and stays there.

The problem seems to be caused by the PC's inability to receive and/or
process Ethernet/TCP frames which arrive within 5 milliseconds of each
other.  Our workstation sends output to the PC in TCP frames carrying
64 bytes of data.  The 512 byte TCP window offered by the PC's TCP
allows us to send up to 8 frames inside one window, so these frames
can arrive with very little inter-frame spacing.  When the PC drops a
frame, we have to retransmit the data that was lost.  The Jacobson
algorithm in our implementation of TCP causes us to *DOUBLE* our
retransmission timer each time we have to retransmit data.  We
eventually increase the retransmission timer to  its maximum value, 20
seconds, which explains why we're seeing bursts of data every 20
seconds.

We have some Sun workstations here, and a few PCs running Sun's
PC/NFS, and when we Telnet from the PCs to the Suns we don't see any
delay on continuous output from the Suns to the PCs.  So, we got out
our Ethernet Sniffer to figure out what the Suns are doing that we
aren't.

It seems that the Sun workstations somehow determine that they're
communicating with Sun PC/NFS on a 3-Com card, because they only allow
one TCP frame to be transmitted to the PC at a time.  They send a
frame, and wait for an acknowledgement (or a retransmission timeout),
then send another frame, and so on.  This occurs even if the frame
contains less data than the offered window size.

When we Telnet between Suns, or from Suns to our workstations, the
Suns transmit many small TCP frames containing data in the offered TCP
window before waiting for an acknowledgement.

We would like to communicate effectively between our workstations and
PCs with the Sun PC/NFS Telnet through the 3-Com Ethernet controller.

What we would like to know is how does the Sun workstation TCP
implementation determine that it is talking to 3-Com PC/NFS?  Does it
look at the Ethernet address to determine that the board came from
3-Com?  Is there something special in the TCP SYN packets that they
key on?

Any light that can be shed upon this matter would be greatly
appreciated.



Tom Griffin
griffin@ingr.com
-- 
______________________________________________________________________________
Tommy Griffin
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 20:59:59 GMT
From:      noose.ecn.purdue.edu!mentor.cc.purdue.edu!mace.cc.purdue.edu!du4@iuvax.cs.indiana.edu  (Ted Goldstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Throughput of IBM TCP/IP router

     I am investigating a proposal to connect a token ring backbone in
our building with a campus wide ethernet backbone through a dedicated
PC running IBM's tcp/ip router program.
     I understand that this PC could become a data bottleneck, but
have been unable to get a good feel for just how much traffic will
cause things to really slow down. We are looking at using an old dual
floppy IBM PC with a 16 Mbs token ring card and Ungerman bass ethernet
card as the router, and initial usage would propably be mostly FTP
transfers and maybe a few telnet sessions. As usage grew we would
upgrade the PC to an AT , to a 386 and so on.
     Does anyone out there with experience with this type of setup have
any insight as to whether we will be able to get adequate throughput?
Any ideas as to how one calculates the ablilty of a router to handle
a given load? Any information or pointer would be greatly appreciated.

-- 
Ted Goldstein                            E-mail: du4@mace.cc.purdue.edu
Network and Systems Admninistrator       Phone : (317) 494-9070
Purdue University School of Technology   Office: Knoy Hall, Rm G009
-Life is like a merry-go-round . . . they both have horses.
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 22:10:45 GMT
From:      usc!samsung!munnari.oz.au!goanna!minyos!chudich!rcora@ucsd.edu  (Robert Alessio)
To:        tcp-ip@nic.ddn.mil
Subject:   Dialin access to a TCP/IP network using Basic Rate ISDN & SLIP - experinces?

	Has anyone had any experience in using Basic Rate ISDN so
	to allow dialin access for a remote IBM PC at 64kb/s.
	
	This is to allow remote access to a TCP/IP network for the tranferring
	of compressed document images which are about 40kbytes per page.

	We intend to use a Basic Rate ISDN Terminal Adapter card which
	will appear to the IBM PC as a COM port.

	My first guess would be to use the SLIP protocol over the 64kb/s link.
	(Note, I have ever setup a SLIP link.)

	Which SLIP package would one recommend (PC/TCP plus)?
	Are there alternative protocols?
	How would you allocated an IP address for remote IBM PCs which could
	connect to a different SLIP gateway everytime they dialin?

P.S	Does any know about the availability of Group IV ISDN Fax Servers or
	cards for IBM PCs ?

Thanks inadvance

Robert Alessio             ACSnet: rcora@chudich.co.rmit.OZ.AU
Professional Officer       ARPA: rcora%chudich.co.rmit.OZ.AU@uunet.UU.NET
Department of Communication and Electrical Engineering
Royal Melbourne Institute of Technology
124 LaTrobe Street         UUCP: ...!uunet!munnari!chudich.co.rmit.OZ.AU!rcora
Melbourne, 3000            BITNET: rcora%chudich.co.rmit.OZ.AU@CSNET-RELAY
Victoria, Australia        Telephone: +61 3 660 2593      Fax: +61 3 662 1060
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 90 23:14:52 GMT
From:      cek@wsc-sun.boeing.com (Conrad Kimball)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NETBIOS and TCP/IP on a DOS PC?

Hello,

We have an ethernet connecting several DOS PC's (286 & 386) with a Tandem
host computer.  The PC's run a program that communicates with a package
on the Tandem using NETBIOS/XNS protocols.  My task is to integrate a
Unix-based optical disk file server (such as an Epoch-1) into this network.
Of course, the Unix-based file server speaks TCP/IP rather than NETBIOS/XNS.

My requirement is only this:  to be able to suspend the PC's PC-to-Tandem
session, perform an FTP transfer or two to/from the Unix-based file server,
and to resume the PC-to-Tandem session.  I hope this can be done using only
the existing Ungermann-Bass PC3020 NIU card in each PC.

Now, I know what TCP/IP, FTP, and NFS are all about (I come from the Unix
world), but I am woefully ignorant of PC LAN software (just what *is*
NETBIOS, anyway?).  I am aware of PC-based products such as PC-NFS and
various FTP packages, but not how they work inside.

One idea is that since the existing PC-to-Tandem link is at the NETBIOS
level, using XNS as a transport mechanism, perhaps TCP/IP could be a
substitute transport mechanism in place of XNS.  Assuming that this is
possible, and that such products exist, my hope is that this would leave
intact the current NETBIOS PC-to-Tandem functionality, and also open the
door to using FTP over the single ethernet card.

If I can't arrange for NETBIOS and FTP to coexist on a single ethernet
card, perhaps I can put 2 cards in each PC and run NETBIOS and FTP side-
by-side?

Any help will be most appreciated.  Please reply by e-mail.  If there is
sufficient interest I will post a summary in a week or two.

--
Conrad Kimball 		 Boeing Computer Services     (206) 865-6410   
Email: cek@wsc-sun.boeing.com or cek%wsc-sun@atc.boeing.com
UUCP:  uw-beaver!bcsaic!wsc-sun!cek
DISCLAIMER: The opinions expressed are my personal views and do not
	    necessarily reflect those of The Boeing Company.

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 00:52:26 GMT
From:      HAROLD@UGA.CC.UGA.EDU (Harold Pritchett)
To:        comp.protocols.tcp-ip
Subject:   Re: libc for SUN 4.0.3c

On Tue, 3 Jul 90 10:04:47 -0700 Chris VandenBerg said:
>Good morning all,
>	        I'm trying to get a SPARC/1 running with the resolver and I was told
> that I have to substitute a shared libc that the resolver, in
>addition to adding the resolv.conf file. Does
>anyone have one of these or know if one for
>4.0.3c? And, does anyone know how this is set up
>in SUNOS4.1? Please respond to me directly, I
>don't want to waste bandwidth on so trivial a
>request.

Hold on there a minute.  If anyone can get the resolver to work with 4.1,
please post it to the list.  We have not been able to get it to work either,
and so far we have not gotten any help from SUN as it appears they can't get
it to work either.

Harold C Pritchett         |  BITNET:  HAROLD@UGA
BITNET TechRep             |    ARPA:  harold@uga.cc.uga.edu
The University of Georgia  |    uucp:  gatech!ugacs!csun2!harold
Athens, GA 30602           |    fido:  1:370/60
(404) 542-3135             |     Bbs:  SYSOP at (404) 354-0817

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 02:36:48 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!mips!synoptics!sblair@ucsd.edu  (Steven C. Blair)
To:        tcp-ip@nic.ddn.mil
Subject:   bizarre PC/NFS <-> UNIX <-> PVCS problem encountered
We use a rather straightforward Source Code Control System here
for the PC based developers. They use PVCS from some company in
the USA, with PC/NFS from Sun onto our Sun servers.

I.E. Their setup looks like this:




--------------------Ethernet-----------------------------------------
			|				|
			|				|
		|===============|			|
		|		|			|
		|		| Sun 4/390		|
		|		| 7053 Controller	|
		|		| 2x 892Mb hitachi's	|
		|		| SUNOS 4.0.3		|
		|		| Heavy NFS Traffic	|
		|		|			|
		|		|			|
                |===============|			|
						|===============|
						|		|
						|		|
						|===============|
					ComPaq 386/33 PC DOS PC/NFS 3.0.1
				    ****>PVCS Source Code Control System<****
				        ****>used on each local node<****


Tonight, I'm sitting here waiting for the exabyte to finish seeking out to
the 10th record on the tape so I can restore their files, which somehow
"mysteriously" are now corrupted.

Things I know are fine:
=======================
1) network has no errors or crc problems on the Sun's for many days now(+21).
2) PC users flagrantly warm reboot their PC's for no good reasons(or few sometimes).
3) dmesg, fsck, etc, show no errors on the Sun's disks. Including a slow reboot to
do a second pass of fsck -p's( first was with fsck, followed by fsck -b 32).
4) Sometimes I've observered developers checking out whole trees, and getting frustrated
in the middle which leads them to #2. This can and has probably caused me to be doing
a level -0- restore(every night onto 8mm for s/w development to save my time).


The Software manager is convinced "beyond reasonable doubt" that the Sun's, PC/NFS or
the network is to blame. I'm not quite so sure to make that assessment/assumption yet.

I thought that I'd inquire onto the net before I'm convinced that anything other might
be at fault here(including human error). Since I use RCS for my code development, and
not the PC based tool, a call to the manufacturer was futile. The vendor said "We have
no problems in our code --**Your Network Is At Fault**". Yeah right, PVCS is obviously
staffed by rocket scientists from goverenment agencies.

Does anyone else have stories with PVCS, or the combination of it with some type of
"networked" disk service(s) that have had these type of problems??

If so, please contact me via the email addr below
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 03:38:15 GMT
From:      ora!minya!jc@bloom-beacon.mit.edu  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability
In article <30819@cup.portal.com>, thinman@cup.portal.com (Lance C Norskog) writes:
> 	2) If your SL/IP tosses packets when the hardware gives framing
> or lost-byte errors, SL/IP should be very reliable.  If you run SL/IP over
> modems, be sure to use MNP or some other error-corrected protocol.  These 
> modems are so cheap that it's pointless running on a raw one.

Be careful here.  Where I work, we've been running SLIP over some modems
that do MNP, and we use raw mode.  The reason is that the MNP comes with
software flow control, which means that any packet with a ^S causes the
link to die.  It usually doesn't take too long for such a packet to come
along.

I spent of bunch of time on the phone with Customer Support people at
the manufacturer (Codex), trying to figure out how to correctly configure
the modems, and all I got from them was "Of course you want flow control; 
you'll lose data without it."  They couldn't conceive of an application
that didn't care about lost data.  If there's a way to do MNP that lets 
*all* 8-bit values pass, they wouldn't or couldn't tell me how to do it.

If anyone out there knows how to do it, I wouldn't mind getting some
email on the subject...

-- 
Typos and silly ideas Copyright (C) 1990 by:
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Jul 90 08:44 EDT
From:      HWeiss@DOCKMASTER.NCSC.MIL
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: TCP/IP slowdown and window field packet
Sounds just like silly window syndrome!  Looks like one end of the
connection has exhausted all its buffers and has closed its incoming
packet window.  The other end keeps probing the zero window sending a
little bit more data and the zero window machine is still out of
buffers.  Usually what happens in this situation is that if you leave
the connection alone for a period of time, the buffer congestion will go
away, a bunch more packets will get delivered, the buffers will get
congested again, and you go around in circles.

There was a RFC written a number of years ago by Dave Clark commenting
on how to avoid this kind of situation.

Howard Weiss Sparta, Inc.
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Jul 90 09:08:26 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
Cc:        TCP/IP List <tcp-ip@nic.ddn.mil>
Subject:   Re: Unix tar uncompression
>I need a means of uncompressing UNIX tar files for a PC. Is there a
>PC based utility available for this?

Our PC/TCP product has a TAR.EXE which can assemble and disassemble
Unix-compatible tar files either locally or over the network.  Sun's
PC_NFS also has a network TAR.  If you want to "uncompress" a Unix
.tar.Z file (made by piping 'tar' into 'compress'), you'll have to
use 'uncompress' on the Unix system first.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Jul 90 11:56:01 -0400
From:      John.Curran@VEC.IMS.ABB.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Parallel network problem

Hmm.. Dual-ring FDDI certainly makes clear the long standing problem of multiple
interfaces.  I didn't see this as an FDDI-specific problem, since numerous sites
have run into the same thing with dual-ported ethernet hosts.  I presumed that
this would be solved (eventually) with some of the policy-based routing work
going on...  Is load-balancing actually a lower-layer activity?

---
John Curran
Asea Brown Boveri
Information Management Services
(203) 285-6520
jcurran@vec.ims.abb.com
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 06:32:42 GMT
From:      njin!munnari.oz.au!bruce!trlluna!ilium!andrews@rutgers.edu  (Murray Andrews)
To:        tcp-ip@nic.ddn.mil
Subject:   Can subnets be separated by another net?
I have a basic question about subnet routing that has probably been asked
many times but I can't locate an answer in any article sitting around
here so ....

Is it possible to route between subnets of a class B address when the
subnets are separated by another network?

For example, given the following topology:

          +---------+
          | Host C1 |
          +---------+ 192.9.200.5
               |
       --------+-----+----- Net 192.9.200 ----------+---------
                     |                              |
               +----------+ 192.9.200.1        +----------+ 192.9.200.2
               | Gate GB1 |                    | Gate GB2 |
               +----------+ 137.147.1.10       +----------+ 137.147.2.20
                    |                              |
       ------+------+-------               --------+---+------
             |                                         |
        +----------+ 137.147.1.11                 +----------+ 137.147.2.21
        | Host B11 |                              | Host B21 |
        +----------+                              +----------+


       ^     Subnet 1 of 137.147    ^     ^       Subnet 2 of 137.147     ^
       |____________________________|     |_______________________________|

Host C1, and gateways GB1 and GB2 all connect to the one network - in this
example a class C network with number 192.9.200 (don't worry - we are not
actually using this number).

Gateways GB1 and GB2 are gateways to 2 subnets of the the class B
network 137.147 with subnet mask 255.255.255.0. There is no connection
between the two subnets except via 192.9.200.

The question is does this work?

Can hosts on either subnet route to hosts on the other (e.g. B11 <-> B21)?

Can hosts on either subnet route to host C1?

Can C1 route correctly to both B11 and B21?

Can other networks gatewayed onto 192.9.200 successfully route to hosts
on the 137.147 subnets?

If it works is there anything special I have to do to the gateways?

If this works a *lot* of IP addresses can be saved.  If this doesn't work
the only alternative appears to be to get a class B address for each
subnet (since they have up to 1000-2000 PC's each).

Any help would be much appreciated.

--------------
Murray Andrews
Telecom Australia Research Labs. (m.andrews@trl.oz.au)
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Fri, 6 Jul 90 14:38:44 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        ietf@venera.isi.edu, snmp@nisc.nyser.net, snmp-wg@nisc.nyser.net, trans-wg@nisc.nyser.net, tcp-ip@nic.ddn.mil
Subject:   Forming a new IETF Working Group for an SNMP Terminal MIB
Hi,

    This is to attempt the creation of an IETF working group (WG) to define an 
experimental MIB for character-oriented terminal devices.  See the attached
proposed, preliminary WG charter for more information.  It contains a very
aggressive schedule to be kicked off with an organizational meeting in
Vancouver.

The mailing list is new and may not be in working order until Monday, so go
easy on our helpful friends at Digital.

	Bob Stewart
	Proposed Chair, IETF Character MIB WG

--------
Character MIB Working Group

Chairman:

	Bob Stewart/Xyplex  rlstewart@eng.xyplex.com

First Meeting:

	August, 1990

Mailing Lists:

	General discussion:  char-mib@decwrl.dec.com
	To subscribe:        char-mib-request@decwrl.dec.com

Description of Working Group:

    The Character MIB working group is chartered to define an experimental
MIB for character stream ports that attach to such devices as terminals and
printers.

    The working group must first decide what it covers and what terminology to 
use.  The initial thought was to handle terminals for terminal servers.  This 
directly generalizes to terminals on any host.  From there, it is a relatively 
close step to include printers, both serial and parallel.  It also seems 
reasonable to go beyond ASCII terminals and include others, such as 3270.  All 
of this results in the suggestion that the topic is character stream ports.

    An important model to define is how character ports relate to network 
interfaces.  Some (a minority) terminal ports can easily become network 
interfaces by running SLIP, and may slip between those states.

    Given the basic models, the group must select a set of common objects of 
interest and use to a network manager responsible for character devices 

    Since the goal is an experimental MIB, it may be possible to agree on a 
document in 3 to 9 months.  Most of the group's business can be conducted over 
the Internet through email.

Goals and Milestones:

1.  July 1990:  mailing list discussion of charter and collection of concerns.

2.  August 1990: First IETF Meeting: discussion and final approval of charter;
    discussion and agreement on models and terminology.  Make writing 
    assignments.

3.  November 1990:  First draft document, discussion, additional drafts,
    special meeting?

4.  December 1990:  Second IETF Meeting:  review latest draft and if OK,
    give to IESG for publication as RFC.

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 14:45:07 GMT
From:      mintaka!snorkelwacker!bu.edu!orc!inews!iwarp.intel.com!psueea!parsely!twiki!dalew@CS.YALE.EDU  (Dale A. Weber)
To:        tcp-ip@nic.ddn.mil
Subject:   ka9q via archive server?

    Is the _current_ version of the ka9q package (generic) available
anywhere via archive server? I don't have ftp access but might be able to
get a friend to grab it for me. Thanks in advance, E-Mail appreciated.

--
Internet: dalew@pdx.com OR dalew@twiki.pdx.com    # AS/400 Specialists
UUCP: ..!{sun!nosun, tektronix}!tessi!twiki!dalew #
WORK: A-38 Specialists Consulting Group, Inc.     # Voice: +1(503)226-1662
      P.O. Box 42157, Portland, OR 97242-0157 USA # FAX:   +1(503)774-6348
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 15:11:31 GMT
From:      snorkelwacker!usc!elroy.jpl.nasa.gov!zardoz.cpd.com!durin!frankh@tut.cis.ohio-state.edu  (Frank Halsema)
To:        tcp-ip@nic.ddn.mil
Subject:   PC POP and PC to Unix Printing
I have a set of P.C.'s that it is time to bring into the LAN world. I
would like to intergate them into our E-Mail and printer network.
However the P.C.'s belong to the business office which never has any
money. My E-mail is currently Quickmail for Mac, PCNFS for P.C., and
Unix SMTP for Sun et. al. The B.O. has told me they can not afford
PCNFS for there machines. So to help them out I am looking for a
public domain solution. I have heard of POP and would like to try it
but don't know where it is. I would also like a printing server for
P.C's if anyone has one. I also have recently lost my Internet
connection but still have uucp and I am connected to UUNET. 

Thanks!!

-- 
Frank Halsema                           UUCP: durin!frankh             
SPARTA, Inc.                   		Internet: frankh%durin@uunet.uu.net
23041 de la Carlota, Suite 400
Laguna Hills Ca, 92653     (714) 768-8161 EXT 339  (714)583-9114 FAX
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 15:25:10 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!ntvaxb!billy@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Resolution to WIN/TCP TALK problems
Hi,

About a week ago I posted a message about the WIN/TCP 5.1 for VMS TALK
program having problems with numeric userids, Wollongong has supplied me
with a new version of TALK that corrects the problem.  Anybody else out
there who has been experiencing this problem may want to contact Wollongong
about getting the corrected version.

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX system manager            THENET : NTVAX::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAX::BILLY
================================================================================
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 16:58:47 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!bionet!synoptics!sblair@tut.cis.ohio-state.edu  (Steven C. Blair)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: libc for SUN 4.0.3c
The routines for libc.so.1.3.1 for Sun 3's & Sun4's are located in
the sun directories on uunet.uu.net.

If you're going down the lloonngg road to sunos4.1, you have to
build the libc routines. Here's the information to do it from
the sun-managers email list:

The following instructions were issued a few weeks ago from Greg Earle@sun:
===========================================================================
As it appears that SunOS 4.1 is now reaching our users in reasonable
quantities, we offer the following announcement for our Internet customers:

Background:
As you may know, the normal /usr/lib/libc.so.* that ships with SunOS 4.x
contains the library routines gethostbyname(3) and gethostbyaddr(3) to do
host name and address resolution.  These routines normally reference the
`hosts' NIS (nee YP) map first, and then fall back to looking in the
/etc/hosts file.  By changing the NIS Makefile to invoke `makedbm' with the
`-b' option, one can arrange things so that NIS does lookups first to a DNS
(Domain Name Service) name server, via the resolver routines.  This is the
Sun supported way of doing things.

But many of Sun's Internet customers want to be able to use resolver-based
lookups without having to run NIS/YP.  In order to fill this void under
SunOS
4.0.x, Sun created `libc_resolv.so' versions of the shared C library with
the
gethostbyname()/gethostbyaddr() routines replaced by the equivalent
functions
from the BIND nameserver distribution's resolver library (plus supporting
functions).  These were made available via anonymous FTP on the host
`uunet.UU.NET', in the `sun-fixes' directory.

Now SunOS 4.1 has arrived, but there is no equivalent `libc_resolv.so'
available via this mechanism (anonymous FTP from `uunet.UU.NET').  This
message
addresses this situation.

Fortunately, 2 things in SunOS 4.1 have come to the rescue:

(1) There is a selectable software category in the 4.1 Full Install called
    `Shlib Custom' that enables one to build custom shared libraries.
    This software gets installed in /usr/lib/shlib.etc, with a README file
    containing instructions on how to build your own custom shared C
library.
    If you wish to build a version of libc.so with the resolver routines,
    make sure to select this category when installing SunOS 4.1.


(2) The version of /usr/lib/libresolv.a in 4.1 has been compiled with
    `cc -pic', thus producing position-independant code.

Thus, what follows is an additional set of comments that can be *directly*
*appended* (i.e., `cat <remainder-of-this-message> >> README') to the file
`/usr/lib/shlib.etc/README' which provides instructions on how to build a
libc.so.X.NN.1 that will use the resolver for hostname/hostaddr resolution.

Sun can make no guarantees on this, but this method has been in use on
Internet hosts running SunOS 4.1FCS for 3 weeks now, doing telnet, rlogin,
ftp, etc. to hosts that are not in the hosts table (on hosts that do not
run NIS/YP), and it works without any known problems.

One final note: the method described below applies to Sun's supported SunOS
4.1
version of the resolver library (libresolv.a), which is based on BIND 4.8.
As many of you are aware, there are `post-4.8' versions of BIND floating
around
out there.  We are aware of versions from UC Berkeley, University of
Toronto,
and University of Michigan, among others.  Although these versions cannot be
supported, it is our opinion that if the code for these customized versions
of
the resolver library adheres to proper shared library conventions, then if
the modules in these libraries are compiled with `cc -pic', the resulting
object modules should be usable in the manner described below for the
shipped
/usr/lib/libresolv.a.  A simple test will confirm whether this will work:

        % mkdir tmp ; cd tmp ; ar xv /path/to/your/custom/libresolv.a
        % ld -assert pure-text *.o

If there are non-PIC constructs in these objects, the assertion would tell
you
about them.  For more information about position-independant code and shared
libraries, please read Chapter 1 in the "Programming Utilities and
Libraries"
manual that is included in the SunOS 4.1 documentation set.  It is contained
in the binder labelled "Programmer's Overview - Utilities and Libraries" on
the spine.

Without further ado, here it is.  As mentioned, cut off below the line,
save to a file, and then append that file to /usr/lib/shlib.etc/README.

Supplemental instructions for building a shared libc.so that uses the
resolver
for hostname/addr resolution:

10. Extract the contents of libc_pic.a and /usr/lib/libresolv.a into the
    tmp directory:
        % cd tmp
        % ar x ../libc_pic.a
        % ar x /usr/lib/libresolv.a

    The libresolv.a (apparently) contains object modules that are position
    independant, so they can be added to the libc_pic modules without fear.

11. Remove the old routine to do the hostname/addr resolution:
        % rm gethostent.o

12. Remove the libresolv module that contains `strncasecmp' (which is now
    in the main C library, so it is redundant):
        % rm strcasecmp.o

13. As mentioned in step 5 above, edit the file `lorder-sparc' in the ..
    directory.  Remove the reference to `gethostent.o' and add the
    references to the resolver library routines by applying this patch:

        % diff -rc2 lorder-sparc.orig lorder-sparc
        *** lorder-sparc.orig   Thu Feb  8 05:27:46 1990
        --- lorder-sparc        Mon Apr  9 12:58:59 1990
        ***************
        *** 150,154 ****
          getwd.o
          getnetgrent.o
        ! gethostent.o
          ypxdr.o
          ttyname.o
        --- 150,161 ----
          getwd.o
          getnetgrent.o
        ! gethostnamadr.o
        ! sethostent.o
        ! res_query.o
        ! res_mkquery.o
        ! res_send.o
        ! res_debug.o
        ! res_comp.o
        ! res_init.o
          ypxdr.o
          ttyname.o

14. Continue as above, from steps 6 to 9.
------------
Steven C. Blair         Network Operations Center
SynOptics Communications Inc. Mountain View, California
INTERNET: sblair@synoptics.com  sblair@nevdull.synoptics.com
PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 17:21:48 GMT
From:      zaphod.mps.ohio-state.edu!samsung!interlan.InterLan.COM!interlan.interlan.com!solensky@tut.cis.ohio-state.edu  (Frank Solensky)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP slowdown and window field of packet
In article <499@litle.litle.com> tom@litle.litle.com (tom hampton) writes:
   We are having a slow-down problem between two TCP/IP programs.

   Both programs do fine for a while, transferring some 50,000 bytes/sec,
   until all of a sudden, they appear to hang and transfer no more than
   1/100th of that.  According to a crude packet monitor we have, the 
   problem seems to occur when the window field of the packet gets set
   down (we don't know by whom) to 0.

Two things come to mind that might explain what you're seeing --

a) a "zero window" problem:
  When the receiver of the data has no space left in its receive window,
the sender stops transmitting, waiting for some indication that it is safe to
resume.  See if the packet trace indicates that:

  1) the receiver sends out another ACK out with a non-zero window size
     shortly after some space opens up in the receive window (does your packet
     monitor display time intervals between the packets?).

  and/or

  2) if the sender sends a "zero-window" probe packet.  The sender should be
     allowing for the possiblity that the above ACK is lost and sends a single
     byte into what it believes to be a full window, expecting that the
     receiver will respond with an ACK with a non-zero receive window.  This
     should occur in about a single retransmit timer interval (see Host
     Requirements for Communications Layers [RFC 1122], section 4.2.2.17 --
     about halfway down page 92).

b) a variant of the "silly window" problem [which I'll refer to as the
   "weird window syndrome"].

   This will show up on your packet monitor as a significant number of "odd"
   sized packets.  Once the receive window has opened up a bit, the window
   size announced back to the sender is some non-intuitve value (eg: not a
   multiple of some power of 2 [or, in the true "silly window" case, some value
   that is very small relative to the receive window size]).  The sender
   transmits enough to fill up the receive window again, and allows the
   transmitting process to unblock until it tries to send at least this amount
   of data again.  This is illustrated below:  "W" is the TCP window size,
   "A" is the ack number, "L" is the length of the packet, "S" is the sequence
   number.

	sender  receiver
        -----   ------

	    <-- W=0, A=5000000
            <-- W=2048, A=5000000    say that a zero-window has just reopened.

 --> send(1024)             S=5006144 is put near end of an 8 KB send window
        L=1024,S=5000000 -->
 --> send(1024)             S=5007168, filling send queue again.
        L=1024,S=5001024 -->

	    <-- W=0, A=5002048
            <-- W=1662 (??), A=5002048

        L=1024,S=5002048 -->
        L= 638,S=5003072 -->   the first part of a queued 1 KB buffer is sent

            <-- W=3092, A=5003710

                     User's send window is now opened only to 1662 bytes.

        L= 386,S=5003710 -->   the end of 2nd buffer is sent but not yet acked.

 --> send(1024)      New requests from host application allow 1024-byte and
 --> send(1024)      638-byte buffer to be pulled into send queue.  The tail
                     of the buffer is pulled down after some space opens up
                     again in the send window.

           . . .
        L=1024 -->
        L=1024,S=5006144 -->  first send() from above
        L= 638,S=5007168 -->  second send()
        L= 386,S=5007806 -->  the remainder of second, once sender was
				unblocked.


     Soon afterwards, the system falls into a self-perpetuating cycle of
filling its send window with a weird-sized packet, transmitting and getting
an ACK back that might not correspond to the boundary of yet another buffer.
The sender's performace suffers as a result of trying to keep packets in synch
with both the announced window sizes and the implied boundaries between each
send() request in the transmitting application program (since the boundaries
of each entry on the send queue closely resemble the send requests of the
initiating process).

     I've seen packet traces a few months ago where this occurs with one of
the vendors you mentioned, but don't recall offhand what rev of software was 
being used at the time.  The lower bound of the performance degredation was
approximately where "silly window" conditions were matched -- about 35% of
the receive window.  I had brought their announced window size to their
attention at the time, so maybe the problem will be fixed Real Soon Now
(though, obviously, I'm not in a position to announce what their plans are).

     The way we worked around this is that when some but not all of
the data in the send queue is acknowledged, reduce the bytes-acked count
in tcp's input so that a queued buffer isn't "partially" acknowledged.  This
forces the send routine to hold off pulling weird-sized packets into memory
in the first place:  here, the second 638-byte packet shouldn't occur, since
the space in the send window won't be released until the rest of the data in
the first "fragmented" packet packet is acknowledged, thereby preventing the
send() request that had created the perpetuating fragment from starting.

     Hope this helps..

--
					-- Frank Solensky / Racal InterLan
Red Sox magic number: 80
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 18:53:43 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   PC PPP?
Does there exist a PC PPP (RFC1134) packet driver for use under NCSA
Telnet?  Whence might one acquire such a beast?
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 20:17:06 GMT
From:      logicon.com!tots!tep@nosc.mil  (Tom Perrine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Unix tar uncompression
In article <9007061308.AA11078@vax.ftp.com> jbvb@vax.ftp.com writes:
>>I need a means of uncompressing UNIX tar files for a PC. Is there a
>>PC based utility available for this?
>
>Our PC/TCP product has a TAR.EXE which can assemble and disassemble
>Unix-compatible tar files either locally or over the network.  Sun's
>PC_NFS also has a network TAR.  If you want to "uncompress" a Unix
>.tar.Z file (made by piping 'tar' into 'compress'), you'll have to
>use 'uncompress' on the Unix system first.
>
>James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
>FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

Implmentations of the (originally UNIX) utility "compress" are
available for several micro systems. I personally know of one for the
Amiga and one for the Mac. There should be one for PCs. Try
comp.sys.ibm.pc...

Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM
Logicon                                 |UUCP: nosc!hamachi!tots!tep
Tactical and Training Systems Division  |-or-  sun!suntan!tots!tep
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 21:09:20 GMT
From:      mephisto!prism!gs26@handies.ucar.edu  (Glenn R. Stone)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Unix tar uncompression
In <9007061308.AA11078@vax.ftp.com> jbvb@VAX.FTP.COM (James B. Van Bokkelen) writes:
>>I need a means of uncompressing UNIX tar files for a PC. Is there a
>>PC based utility available for this?
>Our PC/TCP product has a TAR.EXE which can assemble and disassemble
>Unix-compatible tar files either locally or over the network.
>....  If you want to "uncompress" a Unix
>.tar.Z file (made by piping 'tar' into 'compress'), you'll have to
>use 'uncompress' on the Unix system first.

If you happen to have a c compiler for the pc, you can get compress.c
off most any news archive site.... you can then uncompress large on the
pc without having to wait for uncompressed files to download.
Microsoft Quick-C can be had for peanuts..... if time is money, 
it's worth it.

-- Glenn R. Stone
gs26@prism.gatech.edu
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 22:07:43 GMT
From:      silver!sweeny@iuvax.cs.indiana.edu  (Brent Sweeny)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Netmasks
SSJACK@ECUVM1.BITNET writes:

>Which RFC(s) explains the interpretation and usage of netmasks?


it's RFC950, "Internet Standard Subnetting Procedure", August 1985.
--------------------
Brent Sweeny
Indiana University
sweeny@indiana.edu
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 22:28:23 GMT
From:      wuarchive!texbell!nuchat!abbadon@uunet.uu.net  (David Neal)
To:        tcp-ip@nic.ddn.mil
Subject:   Novell to tcp/ip gateways

Hello, I am looking for information on linking Novell networks
running netware into a tcp/ip based network of suns.

I want the pc users to be able to telnet into the ip network.

Mail and nfs mounting of disks is less important but would be useful.

David Neal
abbadon@nuchat.uucp
abbadon%nuchat@{texbell,bcm,rice,uunet}
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 90 23:37:51 GMT
From:      usc!samsung!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: MAC Email Services from Unix Systems

Consider MacMS from Stanford University.  Contact person is Bill
Yeager, e-mail address yeager@sumex-aim.stanford.edu.

It uses the IMAP protocol (RFC-1064) to access mail with a Unix system
as the central mail agent.  It's a neat package!

Unlike most POP-based systems it scales well for large mailboxes and
on lower-speed networks (e.g. cross-country or international).  Of
course, it also works quite well on high-speed networks.  One of the
best features is a unique message searching capability.

I have a compatible package for the NeXT computer: MailManager and the
novice-oriented EasyMail.

 _____   | ____ ___|___   /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105
 _|_|_  -|- ||   __|__   /  / 6158 Lariat Loop NE   "Gaijin! Gaijin!"
|_|_|_|  |\-++-  |===|  /  /  Bainbridge Island, WA "Gaijin ha doko ka?"
 --|--  /| ||||  |___|    /\  USA 98110-2098        "Niichan ha gaijin."
  /|\    | |/\| _______  /  \ "Chigau. Gaijin ja nai. Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 90 03:45:11 GMT
From:      agate!bionet!uwm.edu!cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!tmsoft!mshiels@ucbvax.Berkeley.EDU  (Michael A. Shiels)
To:        tcp-ip@nic.ddn.mil
Subject:   BSD 4.x networking code.
Where is the "definitive" place to grab a copy of the BSD 4.x networking code
from?
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 90 04:08:48 GMT
From:      fluke!gtisqr!stu@beaver.cs.washington.edu  (Stu Donaldson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: errno 77 on read of socket
In article <496@litle.litle.com> tom@litle.litle.com (tom hampton) writes:
>We have been doing some high volume tests of ISC's latest release of
>TCP/IP.  Things look pretty good except for an occaisional (1/1000)
>error generated on a read of a socket -- errno 77, bad data packet.

I had the same problem with the 2.0.2 distribution and ftp to a non-ISC
host.  Mainly to our PC's running NCSA_Telnet, and Excelan's FTP software.

I never had it between other systems, only when ftp'ing to the 386/ix
systems.  Interractive was very helpful and responded on the net once
with a suggestion, and then later via email requested some more info
on the problem.  Then no response or resolution from ISC.  I have just
learned to live with it.  People have to watch their FTP transfers here
and rerun it if something failed.

I was hoping that it was fixed in the 2.2 distribution.  (Oh, by the
way, I could not duplicate the problem between two ISC systems)
--
Stu Donaldson          UUCP: {smart-host}!gtisqr!stu
Engineering Manager    ARPA: gtisqr!stu@yang.cpac.washington.edu
Global Technology      Bell: (206) 742-9111
Mukilteo, Washington.


-- 
Stu Donaldson          UUCP: {smart-host}!gtisqr!stu
Engineering Manager    ARPA: gtisqr!stu@yang.cpac.washington.edu
Global Technology      Bell: (206) 742-9111
Mukilteo, Washington.
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Sat, 7 Jul 90 22:03:32 PDT
From:      earle@poseur.jpl.nasa.gov (Greg Earle - Sun JPL on-site Software Support)
To:        sblair@synoptics.COM, comp.protocols.tcp-ip
Cc:        chris@salt.ACC.COM, TCP-IP@nic.DDN.MIL
Subject:   Re: libc for SUN 4.0.3c
In TCP-IP/comp.protocols.tcp-ip article <21705@mvis1.com> you wrote:
>If you're going down the lloonngg road to sunos4.1, you have to
>build the libc routines. Here's the information to do it from
>the sun-managers email list:
>
>The following instructions were issued a few weeks ago from Greg Earle@sun:
>===========================================================================
> ... [My original posting deleted]

Please note that my original posting has undergone two revisions since then.
The main reason was to insert the instructions into the mainline README file
from the /usr/lib/shlib.etc directory; the other reasons were to correct minor
oversights and to provide extra information.

If anyone reading this wants to get the latest version of the file in question
(/usr/lib/shlib.etc/README), they can contact me at the following addresses.

--
	Greg Earle
	Sun Microsystems, Inc. - JPL on-site Software Support Engineer
	earle@poseur.JPL.NASA.GOV	(Direct)
	earle@Sun.COM			(Indirect)
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 90 22:46:53 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Parallel network problem
In article <5A07060B131D020F-MTAABB*John.Curran@VEC.IMS.ABB.COM>, John.Curran@VEC.IMS.ABB.COM writes:
> 
> ...  Is load-balancing actually a lower-layer activity?


That would seem to depend on whom you ask.

Notice that many people in X3T9.5 think all of network management belongs
in the link layer, including all necessary tools such as reliable circuits
that can pass tens of thousands of bytes between management agents.  (Yes,
there are those in X3T.5, the ANSI committee doing FDDI, who have been
publically very much not dismayed by the prospect of SMT (FDDI Station
MangemenT) information exceding the FDDI frame size.)

There are others who think that SMT is overly complicated, that none of the
optional frames will ever be implemented by enough vendors to be usable
even by those who favor link-layer network management, that the absense of
authentication and authorization for remote actions dooms any hope of using
remote acting SMT frames in any customer site where users are not trusted
(e.g. any university or large company) and so at almost any site that
really needs remote FDDI ring management, and that the last change that made
SRF's mandatory was unfortunate.

I think load-balancing belongs above the link layer somewhere closer to
the machinery that bangs windows and such, but then I'm contrary.


Vernon Schryver
vjs@sgi.com
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Sat Jul  7 20:56:34 1990
From:      sys320!svr%shiva@shakti.ernet.in
To:        uunet!nic.ddn.mil!tcp-ip@uunet.UU.NET
Subject:   Pl remove me

Please remove my name from the mailing list

uunet!shakti!shiva!raghavan

########################################################################
  note from the postmaster@host.ernet.in

  1] Users outside India are advised not to use E-mail address
     of the form  name%host@shakti.uu.net from the 25-MAY-1990.
     Please use instead address of the form 
     name%host@ncst.ernet.in

  2] Addresses of the form host!host!host ... !host!name will 
     however continue to work for sometime.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Sat, 07 Jul 90 23:05:35 +0100
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        zaphod.mps.ohio-state.edu!know!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu (Peter Elford)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?

	 In article <1867@trlluna.trl.oz>, m.andrews@trl.oz.au (Murray Andrews) writ
	es:
	 > I have a basic question about subnet routing that has probably been asked
	 > many times but I can't locate an answer in any article sitting around
	 > here so ....
	 > 
	 > Is it possible to route between subnets of a class B address when the
	 > subnets are separated by another network?
	 
	 The short answer is no.

Well, that's not quite right.  This depends on your routing protocol and how your
routers actually forward packets.
	  
	 > For example, given the following topology:
	 > 
	 >           +---------+
	 >           | Host C1 |
	 >           +---------+ 192.9.200.5
	 >                |
	 >        --------+-----+----- Net 192.9.200 ----------+---------
	 >                      |                              |
	 >                +----------+ 192.9.200.1        +----------+ 192.9.200.2
	 >                | Gate GB1 |                    | Gate GB2 |
	 >                +----------+ 137.147.1.10       +----------+ 137.147.2.20
	 >                     |                              |
	 >        ------+------+-------               --------+---+------
	 >              |                                         |
	 >         +----------+ 137.147.1.11                 +----------+ 137.147.2.
	21
	 >         | Host B11 |                              | Host B21 |
	 >         +----------+                              +----------+
	 > 
	 > 
	 >        ^     Subnet 1 of 137.147    ^     ^       Subnet 2 of 137.147    
	 ^
	 >        |____________________________|     |______________________________
	_|
	 > 
	 > Host C1, and gateways GB1 and GB2 all connect to the one network - in thi
	s
	 > example a class C network with number 192.9.200 (don't worry - we are not
	 > actually using this number).
	 > 
	 > Gateways GB1 and GB2 are gateways to 2 subnets of the the class B
	 > network 137.147 with subnet mask 255.255.255.0. There is no connection
	 > between the two subnets except via 192.9.200.
	 > 
	 > The question is does this work?
	 
	 No. The reasons is that the Gateways will only advertise a route to 137.147
	.0.0
	 (not to a particular subnet of that network) over the 192.9.200.0 subnet th
	ey
	 are connected too.
	 
Again, this depends on the routing protocol and routers.  It is certainly easy 
enough to configure the OSPF protocol to make this work.  In fact, the NASA
Science Internet network (built of Proteon p4200 routers) does exactly this.
We have 2 NSI routers seperated by a class C network, and both routers can
deal with parts of 128.161 on both "sides" of the class C net.  This is
a consequence of variable length subnet support, and how OSPF areas 
are configured.  


	.
	.
	.

	 The only way it *might* work is to give the interfaces that connect the two
	 gateways a second IP address (in this case from another subnet of 137.147) 
	 and use a bit of static routing in the hosts. Two subnets (from different n
	et
	 numbers would then share the same physical network).
	 
	 cisco routers support secondary interface addresses but will never generate
	 an
	 IP packet with the secondary IP address - which is why you might have to us
	e
	 some static routing. I've done something like this at Macquarie University 
	to
	 support CSIRO's links into that campus, but at that site it's a case of two
	 networks on the same cable, not a partititioned subnets (which is illegal
	 according to the RFC),

This is a real kludge, and any hosts on the net in the middle may cause problems 
because of improper handling of broadcast packets.  As I said, with the right 
routing protocol, this situation can work.  We actually discovered this 
accidentally one day, when we configured things in such a way that this 
behavior resulted, and then decided that it wasn't supposed to work!  After
thinking things through however, it was clear this was a topology the system
could support.

Now, I wouldn't go off recommending this approach to people, but it certainly can
be useful at times, especially during transitions, and for other reasons too.
So, Murray, the answer to your question is yes, given you have OSPF routers 
involved.  Otherwise, I think the kludges you need would be pretty ugly and
not work well.

OSPF is brought to you by the IETF, and is documented in RFC 1131.  Expect to
see a multivendor demo at InterOp this fall.  Ask for it by name, accept no
substitutes!  


							Thanks,
							   Milo

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 90 08:32:35 GMT
From:      zaphod.mps.ohio-state.edu!know!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu  (Peter Elford)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?
In article <1867@trlluna.trl.oz>, m.andrews@trl.oz.au (Murray Andrews) writes:
> I have a basic question about subnet routing that has probably been asked
> many times but I can't locate an answer in any article sitting around
> here so ....
> 
> Is it possible to route between subnets of a class B address when the
> subnets are separated by another network?

The short answer is no.
 
> For example, given the following topology:
> 
>           +---------+
>           | Host C1 |
>           +---------+ 192.9.200.5
>                |
>        --------+-----+----- Net 192.9.200 ----------+---------
>                      |                              |
>                +----------+ 192.9.200.1        +----------+ 192.9.200.2
>                | Gate GB1 |                    | Gate GB2 |
>                +----------+ 137.147.1.10       +----------+ 137.147.2.20
>                     |                              |
>        ------+------+-------               --------+---+------
>              |                                         |
>         +----------+ 137.147.1.11                 +----------+ 137.147.2.21
>         | Host B11 |                              | Host B21 |
>         +----------+                              +----------+
> 
> 
>        ^     Subnet 1 of 137.147    ^     ^       Subnet 2 of 137.147     ^
>        |____________________________|     |_______________________________|
> 
> Host C1, and gateways GB1 and GB2 all connect to the one network - in this
> example a class C network with number 192.9.200 (don't worry - we are not
> actually using this number).
> 
> Gateways GB1 and GB2 are gateways to 2 subnets of the the class B
> network 137.147 with subnet mask 255.255.255.0. There is no connection
> between the two subnets except via 192.9.200.
> 
> The question is does this work?

No. The reasons is that the Gateways will only advertise a route to 137.147.0.0
(not to a particular subnet of that network) over the 192.9.200.0 subnet they
are connected too.

> Can hosts on either subnet route to hosts on the other (e.g. B11 <-> B21)?
> 
> Can hosts on either subnet route to host C1?
> 
> Can C1 route correctly to both B11 and B21?
> 
> Can other networks gatewayed onto 192.9.200 successfully route to hosts
> on the 137.147 subnets?
> 
> If it works is there anything special I have to do to the gateways?

The only way it *might* work is to give the interfaces that connect the two
gateways a second IP address (in this case from another subnet of 137.147) 
and use a bit of static routing in the hosts. Two subnets (from different net
numbers would then share the same physical network).

cisco routers support secondary interface addresses but will never generate an
IP packet with the secondary IP address - which is why you might have to use
some static routing. I've done something like this at Macquarie University to
support CSIRO's links into that campus, but at that site it's a case of two
networks on the same cable, not a partititioned subnets (which is illegal
according to the RFC),

Peter Elford,
AARNet
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 90 13:28:14 GMT
From:      ora!minya!jc@uunet.uu.net  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Limited routing between IP networks.

From mail Wed Jul  4 01:45 EDT 1990
>From hp-ses.sde.hp.com!wunder  Wed Jul  4 01:45:06 1990 remote from mit-eddie
Received: by minya.uucp (smail2.5)
	id AA01293; 4 Jul 90 01:45:06 EDT (Wed)
Received: from HPLABS.HPL.HP.COM by EDDIE.MIT.EDU with SMTP (5.61/25-eef)
	id AA25341; Tue, 3 Jul 90 11:59:31 EST
Received: from hp-ses.sde.hp.com by hplabs.hpl.hp.com with SMTP
	(15.11.1.3/15.5+IOS 3.14) id AA16068; Tue, 3 Jul 90 09:59:40 pdt
Received: by hp-ses.sde.hp.com
	(15.11/15.5+IOS 3.21) id AA02795; Tue, 3 Jul 90 09:59:36 pdt
Date: Tue, 3 Jul 90 09:59:36 pdt
From: Walter Underwood <mit-eddie!hp-ses.sde.hp.com!wunder>
Message-Id: <9007031659.AA02795@hp-ses.sde.hp.com>
To: minya!jc@eddie.mit.edu
Subject: Re: Limited routing between IP networks.
Newsgroups: comp.protocols.tcp-ip
In-Reply-To: article <416@minya.UUCP> of Tue, 3 Jul 1990 03:28:19 GMT

| You may get into silliness with making mail work, since the
| destination may not be reachable.  I'm sure that HP would be glad to
| consult on this.  Maybe not for free, but we make it work for a 20,000
| node network ...

Actually, we have some Cisco gateways at work.  As near as I can tell,
they only work with LANs, and aren't set up to work across phone lines.
The configurations we need have set (subnets) that are geographically
quite remote from each other, and we are using (transient) SLIP links
across the phone system to establish connectivity.  If Cisco can do
this, I'd be interested in finding out how (or where to look in the
manuals or who to call to order any add-on stuff to make it work).

-- 
Typos and silly ideas Copyright (C) 1990 by:
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 90 16:48:40 GMT
From:      sun-barr!newstop!texsun!texbell!nominil!linimon@apple.com  (Mark Linimon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Signal-to-noise degradation on comp.protocols.tcp-ip
A discussion recently arose in comp.protocols.tcp-ip about its decreased
technical content.  I have some specific proposals to address this issue from
the Usenet side.

1. Create a periodic posting to refresh/establish Usenet community memory that:
   - states the purpose of comp.protocols.tcp-ip.
   - states the fact that the newsgroup/mailing list gateway exists.
   - suggests topics relevant to comp.protocols.tcp-ip.
   - points to appropriate sources for information about SLIP, Novell, and
     other networking technologies.
   - states how to get the RFCs.
   - points to the status, conditions, and location of sources from Berkeley,
     Phil Karn, Clarkson, and so on.
   - briefly points to the Usenet guidelines for posting and newgroup creation.
   [Yes, I'll volunteer to create this posting; I'll need assistance in
   gathering some of the information.  Email me directly.]
2. Create a Usenet-side newsgroup comp.protocols.slip.  I intend to issue
   the call for discussion in news.groups/news.announce.newgroups this week.
3. Call for discussion on splitting out other topics that do not _specifically_
   have to do with protocol implementation.  Two come to mind:
   - network set-up, interconection, and administration (comp.admin.tcp-ip?
     comp.protocols.tcp-ip.admin?)
   - meta-issues about the Internet proper (comp.internet?)

Summary: even though I am not a technical contributor to this list/group, I do
find it educational, and would rather not see it continue to become less
useable to the community of networking implementors.

Note that followups are directed to the Usenet group news.groups.  Interested
Internet-side readers should email to me and I'll summarize.
-- 
Mark Linimon / Lonesome Dove Computing Services / Southlake, Texas
{mic, texbell}!nominil!linimon              ||  "I said, welcome,
linimon@nominil.lonestar.org                ||   to the real world, kid"
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Jul 90 02:39:49 PDT
From:      Tony Staw - REO2-G/G9 830-3908  09-Jul-1990 1037 <staw@marvin.enet.dec.com>
To:        njin!munnari.oz.au!bruce!trlluna!ilium!andrews@rutgers.edu, tcp-ip@nic.ddn.mil
Subject:   RE:Can subnets be separated by another net?
This topology would also be supported by dual IS-IS routing, which like
OSPF supports variable-length subnet masks.

Tony
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Sun, 08 Jul 90 18:16:23 +0100
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu (Peter Elford)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?

Peter, I expect about 5-6 implementations there, though Proteon's is the
only real vendor shipping today.  I certainly don't want to speak for the
vendors on this; I'm sure they'll do it themselves.  This is just my best 
guess of course, based on meetings at IETF and such.

Note that it's a little tricky to implement variable length mask 
support unless the IP forwarder is designed to support it.  Most of the
vendor's I know who are supporting OSPF have or are rewriting their
forwarder code, and this is a major change in the way their routers
work, so it takes more than just OSPF itself if your forwarder doesn't
support this functionality already.

						Thanks,
						   Milo


-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 90 22:46:15 GMT
From:      zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu  (Peter Elford)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?
In article <9007080605.AA00749@cincsac.arc.nasa.gov>, medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
> 	 > Is it possible to route between subnets of a class B address when the
> 	 > subnets are separated by another network?
> 	 
> 	 The short answer is no.
> 
> Well, that's not quite right.  This depends on your routing protocol and how your
> routers actually forward packets.

.. diagram deleted ...

> 	 No. The reasons is that the Gateways will only advertise a route to 137.147
> 	.0.0
> 	 (not to a particular subnet of that network) over the 192.9.200.0 subnet th
> 	ey
> 	 are connected too.
> 	 
> Again, this depends on the routing protocol and routers.  It is certainly easy 
> enough to configure the OSPF protocol to make this work.  In fact, the NASA
> Science Internet network (built of Proteon p4200 routers) does exactly this.
> We have 2 NSI routers seperated by a class C network, and both routers can
> deal with parts of 128.161 on both "sides" of the class C net.  This is
> a consequence of variable length subnet support, and how OSPF areas 
> are configured.

We are still just exploding out of the stone age Internet wise down here, so
it was pretty safe to assume RIP and normal (ie. fixed length) subnet masks.

> 	 The only way it *might* work is to give the interfaces that connect the two
> 	 gateways a second IP address (in this case from another subnet of 137.147) 
> 	 and use a bit of static routing in the hosts. Two subnets (from different n
> 	et
> 	 numbers would then share the same physical network).
> 	 
> 	 cisco routers support secondary interface addresses but will never generate
> 	 an
> 	 IP packet with the secondary IP address - which is why you might have to us
> 	e
> 	 some static routing. I've done something like this at Macquarie University 
> 	to
> 	 support CSIRO's links into that campus, but at that site it's a case of two
> 	 networks on the same cable, not a partititioned subnets (which is illegal
> 	 according to the RFC),
> 
> This is a real kludge, and any hosts on the net in the middle may cause problems 
> because of improper handling of broadcast packets.  As I said, with the right 
> routing protocol, this situation can work. 

I wasn't recommending the kludge; just using it as an example of what the
problems associated with partitioning subnets (of the RFC950 flavour).
 
> Now, I wouldn't go off recommending this approach to people, but it certainly can
> be useful at times, especially during transitions, and for other reasons too.
>
> So, Murray, the answer to your question is yes, given you have OSPF routers 
> involved.  Otherwise, I think the kludges you need would be pretty ugly and
> not work well.

I think Milo is saying that unless you are keen enough to dive into OSPF 
then the answer is no !

> OSPF is brought to you by the IETF, and is documented in RFC 1131.  Expect to
> see a multivendor demo at InterOp this fall.  Ask for it by name, accept no
> substitutes!  

How many vendors do you expect to see Milo ? (genuine interest, no sarcasm)

Regards,
Peter Elford,
AARNet
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Jul 90 12:40:38 PDT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        lumsdon@dtoa1.dt.navy.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Wollongong TCP/IP ping question, VMS
> Under VMS (version 5.2), what privileges does PING require?
> Tech Support at Wollongong told me it was cmkrnl, but, when ping image
> is installed with that privilege, this message appears when trying to
> use ping (from regular user account; works fine from system account):
>   $ ping _node_
>   ping: socket: Permission denied
>
> I've played with it, and, will ping work when installed with only the
> sysprv privilege?

    Both WINS/TCP and MultiNet use 'SYSPRV' as the equivalent of the
UNIX 'root' user, so SYSPRV is required to create the raw socket
required by PING.  I'd be careful about installing arbitrary programs
with SYSPRV, as you may breach system-security by allowing someone to
use that program to overwrite system files.

    MultiNet's PING is installed with SYSPRV by default, and in order
not to cause a security breach, PING disables it on startup and
enables it only to create the socket.

						    Kenneth Adelman
						    TGV, Inc.
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Mon, 9 Jul 90 09:56:30 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        ingr!b11!griffin@uunet.uu.net  (Tommy Griffin)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: telnet and pc's
Two points:

1. The "retransmit increases steadily toward a limit, even when data
is eventually getting acknowleged" is a TCP bug that at least a
couple of "Van Jacobsen" TCPs can be provoked into demonstrating.
With the two I'm familiar with (SunOS 4.0.1, Ultrix 3.0) it normally
has to do with which ahead-of-sequence segment the receiver drops
first if buffers are tight (earliest sequence vs. latest).  In my
opinion, it would be worth the effort to fix it in the workstation.

2. Read the TCP section of RFC 1122 - it has somewhat to say about
the use of Nagle's algorithm to collect data into larger segments.
The gateway vendors (and the regional networks) won't be awfully
happy about bursts of back-to-back 64-byte packets.  Even if the
traffic is time sensitive, like X, a larger packet every 10ms
would suffice.

I can't really blame PC-NFS in this case - my TCP probably wouldn't do
much better under that kind of abuse.  A receiving TCP is rather limited
in what it can do to prevent overrun, or sender retransmit escalation.

To answer your original question, I hope the Sun Unix TCP isn't
looking at the 3Com manufacturer code in the destination Ethernet
address and slowing down (this would fail through routers, or if they
were talking to software which sets its own Ethernet address).  I
think what you're seeing is mostly the effect of code which attempts
to send as much data as possible in each segment...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Mon, 09 Jul 90 17:05:41 EDT
From:      bjp@mbunix.mitre.org
To:        tcp-ip@nic.ddn.mil
Cc:        bjp@mbunix.mitre.org
Subject:   Source for TCP/IP
    We are considering porting TCP/IP to a CMC FDDI card that will sit
in a single board VME box so that we can put a customized image storage
and retrieval system on an FDDI network.  Since many implementations of
TCP/IP already exist, I am interested in obtaining source for these
protocols, where the source represents an implementation known to be very
good for large volume throughput.  I am under the impression that most
implementations are in C.  Please correct me if I am wrong.

    I'd also like some input from implementors as to what bottle necks
have been found that have down graded performance in various TCP/IP
implementations.  Since I read the tcp-ip mailing list from a bulletin
board where archiving is under the controll of b-board administrators,
I would like all responses sent to:

                         bjp@mbunix.mitre.org

Thanks for your time.  Anything you send will be a big help.

                                     Sincerely
                                     bj Pease
                                     MITRE Corp.
                                     Bedford, MA
                                   
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 90 13:23:34 GMT
From:      dino!ux1.cso.uiuc.edu!herodotus.cs.uiuc.edu!morrison@uunet.uu.net  (Vance Morrison)
To:        tcp-ip@nic.ddn.mil
Subject:   Beta version of PCroute with packet driver support available
Hello,

There is a beta version of PCroute with packet driver support 
available on accvuax.nwu.edu (129.105.49.1) in pub/pcroute/exp.
In this directory you will find two files 'packpack.exe' and
'packslip.exe'.   These files are compiled versions of pcroute
the first configured to be used with two packet drivers, and
the second configured for one packet driver and one slip line.

In addition the pub/pcroute/exp directory is the standard PCroute
documentation modfied to include packet driver details, as well
as a file 'packet.txt' which is a sample installtion of the 
packpack.exe code.  

So if you have wanted to use PCroute, but didn't have WD8003E
cards here is your chance to try it out.  If you do try out the
code, please send me a note saying so (so I can know if anyone
really cares), and also send any comments/bugs of interest.
The code will not be nearly as speedy as the native driver, but
I am not sure how much (I estimate about 1/3 the speed).  Any 
comments/measurments on the speed would also be appreciated.

At present the source for the additional code is not available 
because it is easer for me to wait until I have had some feedback
and then simply integrate it into the standard release.


Vance
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Mon, 09 Jul 90 11:56:12 +0100
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        Tony Staw - REO2-G/G9 830-3908  09-Jul-1990 1037 <staw@marvin.enet.dec.com>
Cc:        njin!munnari.oz.au!bruce!trlluna!ilium!andrews@rutgers.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?

Tony, you are of course right.  All the modern IGP designers learned from
the mistakes of the past and do/will support variable length masks.  I was
just differentiating OSPF's support for this sample topology in
comparison to "old style" IGP's like RIP, IGRP, etc, which do not carry
around mask information with the route information.  But to be fair to them,
the routers IP forwarders didn't support variable length masks either,
with the possible exception of fuzzballs, which were trailblazers for 
many of the concepts now common in the Internet.

					Thanks,
					   Milo


PS The "old style" protocols are still adequate for many people's 
topologies, and are still widely used.  It's just that these days,
people want a lot more from their IGP's, like variable length mask 
support, authentication, multicast updates, rapid convergence, 
route tagging, low overhead, etc...  OSPF was built with all these goals 
in mind, whereas the others didn't have nearly as full of a plate 
requirements wise when they were built...  Of course, that's why the
IETF formed a working group to build such a protocol.  And Dual IS-IS 
should also be able to do those things as well...
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 90 15:23:31 GMT
From:      cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!geac!maccs!beame@tut.cis.ohio-state.edu  (Carl Beame)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: telnet and pc's
In article <8285@b11.ingr.com> griffin@b11.ingr.com (Tommy Griffin) writes:
>
>We're experiencing some difficulty communicating between our
>workstations and PCs using Telnet over TCP/IP.  The PCs are running
>Sun's PC/NFS product through the 3-Com Ethernet card.
>
>The problem occurs when a Telnet session has been established from a
>PC to a workstation, and the workstation is generating a continuous
>stream of output to be displayed by the PC.  The PC begins to display
>the output, but instead of displaying a continuous stream of data, new
>data is displayed at intermittent intervals with 1-20 second delays
>between bursts of output.  The delay usually ramps up to 20 seconds
>and stays there.
>
>The problem seems to be caused by the PC's inability to receive and/or
>process Ethernet/TCP frames which arrive within 5 milliseconds of each
>other.  Our workstation sends output to the PC in TCP frames carrying
>64 bytes of data.  The 512 byte TCP window offered by the PC's TCP
>allows us to send up to 8 frames inside one window, so these frames
>can arrive with very little inter-frame spacing.  When the PC drops a
>frame, we have to retransmit the data that was lost.  The Jacobson
>algorithm in our implementation of TCP causes us to *DOUBLE* our
>retransmission timer each time we have to retransmit data.  We
>eventually increase the retransmission timer to  its maximum value, 20
>seconds, which explains why we're seeing bursts of data every 20
>seconds.
>
>Any light that can be shed upon this matter would be greatly
>appreciated.
>
>
>Tom Griffin
>griffin@ingr.com

	At McMaster University they are running CS/100s  to the IBM 7171
and IVECS cards in the Vaxen. They had the same problem (originaly the 
IVECS cards had a 16 second retry time). What I did was allow the
Telnet window size to be changed. The CS/100s and IVECs cards buffer
up to 82 bytes per packet. By setting the window size to 82, everything works
and you can get reasonable through-put with telnet.

	Carl Beame
	Beame & Whiteside Software Ltd.
	Beame@McMaster.CA
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 90 17:03:26 GMT
From:      nems!dtoa1!lumsdon@mimsy.umd.edu  (Lumsdon)
To:        tcp-ip@nic.ddn.mil
Subject:   Wollongong TCP/IP ping question, VMS
Under VMS (version 5.2), what privileges does PING require?
Tech Support at Wollongong told me it was cmkrnl, but, when ping image
is installed with that privilege, this message appears when trying to
use ping (from regular user account; works fine from system account):
  $ ping _node_
  ping: socket: Permission denied

I've played with it, and, will ping work when installed with only the
sysprv privilege?

Thanks for any help.
--------------------------  Esther Lumsdon  --------------------------------
lumsdon@dtoa1.dt.navy.mil  lumsdon@dtrc.dt.navy.mil
lumsdon%dtrc.navy.mil@uunet.uu.net
"Wherever you go, there you are" -Buckaroo Bonzai
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 90 18:04:11 GMT
From:      wang!ice@uunet.uu.net  (Fredrik Nyman)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for PC TCP/IP ...
I'm looking for PC TCP/IP development packages to run under DOS (Windows).
Ideally it should support BSD sockets, SysV streams and its library
functions (listen(), accept(), socket() ...) should run fine under Windows.

What products are out there?
I know of SUN's PC-NFS and FTP Software's PC/FTP exist, but do they
match my requirements?

I'd be most grateful for any information.

-- 
Disclaimer: Wang doesn't care about my opinions, so why should you?
Internet: <ice@wang.COM>  <ice@emil.csd.uu.se>
BITNET:	  <ice@DRYCAS>  <ice@SEARN>  <ice@SEQZ51> (in order of preference)
USnail: Wang Labs, Inc., M/S 019-490, One Industrial Ave., Lowell, MA 01851
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 90 21:06:37 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Wollongong TCP/IP ping question, VMS
In article <2509@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil (Esther
Lumsdon) writes: 
>Under VMS (version 5.2), what privileges does PING require?

It requires CMKRNL and SYSPRV on all version of VMS and all version of
WIN/TCP for VMS through at least 5.1.

>Tech Support at Wollongong told me it was cmkrnl, but, when ping image
>is installed with that privilege, this message appears when trying to
>use ping (from regular user account; works fine from system account):
>  $ ping _node_
>  ping: socket: Permission denied
>
>I've played with it, and, will ping work when installed with only the
>sysprv privilege?

The problem is that Technical support gave you incomplete information.
WIN/TCP PING requires that you have both CMKRNL and SYSPRV in order
for certain calls that it makes to succeed.  If you don't have both of
these privs enabled, then you will get the error message that you see
above.

The good news is that as of release 5.1 you are supposed to be able to
install ping with privs.  Everything should work OK if you install the
ping image with CMKRNL and SYSPRV.
--
Warner Losh		imp@Solbourne.COM
Boycott Lotus.		#include <std/disclaimer>
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 90 23:49:08 GMT
From:      mentor.cc.purdue.edu!nelson@purdue.edu  (J. Nelson Howell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Novell to tcp/ip gateways
In article <25539@nuchat.UUCP> abbadon@nuchat.UUCP (David Neal) writes:
>
>Hello, I am looking for information on linking Novell networks
>running netware into a tcp/ip based network of suns.
>
>I want the pc users to be able to telnet into the ip network.

I also am looking for similar information.

Any pointers would be appreciated.  Thanks.


J. Nelson Howell                       | System Programmer
nelson@midas.mgmt.purdue.edu  Internet | Krannert Graduate School of Management
NELSON@PURCCVM                BITNET   | Purdue University
                                       | West Lafayette, IN
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 00:36:28 GMT
From:      hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu  (Lars Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?
In all our pride about how OSPF will allow you to build a network that
contains discontiguous subnets, lets not forget to explain to the new
people that this is not recommended, precisely because the earlier and
most widely available routing protocols do not deal well with such a
case.

Disjoint subnets can only be expected to work if all interconnections
between the disjoint subnets are under the same administration and is
running a routing protocol that passes the mask. The normal way to
implement the topology that was asked about, would be to have the
connecting network (C1 in the example) be anotehr class-C sized subnet
of the same class B network as the disjoint segments.

The most common case where clients ask about disjoint subnets, is where
an enterprise is geographically disjoint (say offices in Los Angeles,
Denver and Boston) and wants to attach each office separately to the
Internet, while assigning all host addresses out of the same class B
network number. This of course is utterly undesirable (would OSPF allow
it to be set up at all ?) and contravenes all the intentions for which
subnets were invented.

Thus, for "commercial use" the simple, practical and almost true answer
is that disjoint subnets are not allowed.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Jul 90 10:10 EST
From:      Bob Stine <0004219666@mcimail.com>
To:        Scott Ginsburg <usc!samsung!ginsburg@ucsd.edu>
Cc:        "tcp-ip@nic.ddn.mil" <tcp-ip@nic.ddn.mil>
Subject:   RE: IP routing and gateways
 > My questions are:
 
>       1.) Is it the case that I need to provide a default gateway
>           address for IP packets that aren't destined for someone
>           within my subnet?
 
Only if you want them to get there :-).  Seriously, you'll need some
sort of route table entry or entries for the networks that you reach
by gateway.
 
>        2.) Do I need to implement an IGP like RIP ...
>            ... (even though this device only has one network
>           interface) ...
 
I wouldn't.
 
>                               ... or is it OK to go to the same
>           gateway (default) every time?
 
Not really, but see below.
 
>       3.) If the answer to 2 is that it's not smart to go to the
>           same gateway every time, then is something like RIP (which
>           should be available on most Unix networks because of
>           routed) the way to go, or does the ICMP redirect take care
>           of it.
 
Bingo!  If you have a decent IP implementation, then it will populate
its local routing table when it gets ICMP redirects.  BSD 4.3 does this.
Probably alot of other IPs do, too.
 
- Bob Stine
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Jul 90 10:22:26 edt
From:      tsuchiya@thumper.bellcore.com (Paul Tsuchiya)
To:        hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?
> .............. 
> The most common case where clients ask about disjoint subnets, is where
> an enterprise is geographically disjoint (say offices in Los Angeles,
> Denver and Boston) and wants to attach each office separately to the
> Internet, while assigning all host addresses out of the same class B
> network number. This of course is utterly undesirable (would OSPF allow
> it to be set up at all ?) and contravenes all the intentions for which
> subnets were invented.
> 
> Thus, for "commercial use" the simple, practical and almost true answer
> is that disjoint subnets are not allowed.
> -- 
> / Lars Poulsen, SMTS Software Engineer
>   CMC Rockwell  lars@CMC.COM
> 

Hmmm.  Why is it <of course> utterly undesirable that one organization
in locations separated by the Internet not split up a Class B address?
The only reason I can think of is that Internet routers are incapable of
looking at subnet parts of the address--in other words, our Internet
routers (or routing protocols) are inadequate.  The thing just simply
wouldn't work.

However, I don't necessarily see something inherently bad about this.
I mean, given today's address structure (net.subnet.host), what are the
alternatives?

First, the organization could have multiple class C addresses? However,
this puts a load equal to subnetted class B addresses on the Internet.
Each router must maintain one routing table entry for each location.
But, it is highly unlikely that a single class C address will suffice
for a location, so the organization probably needs a different class B
address for every location.  We still haven't decreased the load on
the internet (one routing table entry for each location), but we have
managed to make bad use of our address space.

In other words, by not having protocols that allow the Internet routers
to look into the subnet, we have NOT decreased the amount of routing
overhead, but we HAVE used our limited address space poorly.

Does BGP have masks?  If so, it could look at the subnet part.  This
would at least allow use to use addresses a little more efficiently.
However, a more general, multi-level hierarchical address scheme 
coupled with an efficient address assignment scheme is what's needed.
Hear my ideas on this at the UCB IETF, or if you can't be there,
ask me and I'll send you a paper on the topic.

PT
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Jul 1990 07:07:31 MEST
From:      Jochen Kornitzky <korni@sietec1.sietec.de>
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet in MS-Windows ?
Does someone on the net knows a telnet (client) that works
under Microsoft-Windows ? (In a real window, with terminal
emulation, not dumb mode switching !)
Best thing would be if the product works with PC/NFS (Sun)
but also others would be interesting.

	Thanks,
		korni

-- 
+--Jochen Kornitzky-------+---------------------------------------+-----------+
|                         |                                       |        .  |
|  SMAIL:                 |  EMAIL:                               |  .        |
|                         |                                       |        .  |
|  Sietec GmbH & Co. OHG  |  korni@sietec1.sietec.de              |     .     |
|  Nonnendammallee 101    |  ...!uunet!unido!sietec1!korni        |           |
|  D-1000 Berlin 13       |  Postmaster for *.sietec.de           |  .     .  |
|                         |                                       |           |
+-------------------------+---------------------------------------+-----------+
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Jul 90 17:00:49 CDT
From:      darrel beach <beach@ddnuvax.af.mil>
To:        tcp-ip@nic.ddn.mil
Cc:        beach@ddnuvax.af.mil
Subject:   GOSIP from the grape vine
Now that implementation of GOSIP are appearing, or at are claimed, on
certain vendor's shelves, I have a question or two maybe someone can 
answer.  We've finally reached a point in tcp/ip where most (not all by
any means) can support DNS and host tables are fading away.  Now comes
GOSIP (with its 3 versions thus far).  It looks like at least for the
near future, the mapping between OR (originator/recipient) addresses to
some particular NSAP address is table driven, at least until directory
services is fully implemented by all.  Is this true, or have I missed
something??

There also seems to be the beginning of a plethora of so called
gateways to get from smtp based mail systems to X.400 based systems,
and might add full suite GOSIP x.400.  Now just how the heck you map
some particular X.400 address to some particular user@host internet
address  seems a little dicey.  From what I've seen, it looks like
another big table to do the mapping.  Has anybody implemented one
of these beasts and knows the definitive answer??

ciao,
Darrel Beach
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 12:46:30 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ark1!nems!dtoa1!lumsdon@ucsd.edu  (Lumsdon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Wollongong TCP/IP ping question, VMS
In article <1990Jul9.210637.4761@Solbourne.COM> imp@dancer.Solbourne.COM (Warner Losh) writes:
>In article <2509@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil (Esther
>Lumsdon) writes:
>>Under VMS (version 5.2), what privileges does PING require?
>
>It requires CMKRNL and SYSPRV on all version of VMS and all version of
>WIN/TCP for VMS through at least 5.1.
>
>The problem is that Technical support gave you incomplete information.
>WIN/TCP PING requires that you have both CMKRNL and SYSPRV in order
>for certain calls that it makes to succeed.  If you don't have both of

Actually, in playing with it before I posted, it worked from my account
(not the system account) when I didn't install it, and gave myself only
the SYSPRV privilege above normal privs (tmpmbx, etc.). The problem
is that Wollongong Tech Support gave me just plain incorrect information.

Is it safe to install PING with SYSPRV privilege? Will it compromise
my system security? Does Wollongong's PING do anything other than sending
ping at target? Is Wollongong's PING code written such that it uses
SYSPRV carefully? I'll call Wollongong and ask these questions, and
post answers to the net in a week or so.

--------------------------  Esther Lumsdon  --------------------------------
lumsdon@dtoa1.dt.navy.mil  lumsdon@dtrc.dt.navy.mil
lumsdon%dtrc.navy.mil@uunet.uu.net
"Wherever you go, there you are" -Buckaroo Bonzai
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Jul 90 11:15:10 +0100
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?

Lars, you are quite correct that use of non-contiguous subnets should
be with good reason.  In many cases, you can do something architecturally pure,
and avoid kludging, which is always a good idea.  But, there are valid
cases to do non-contiguous subnets as well.  As usual, the reason you need
really smart people is to tell the difference between the  cases.  I don't
think that the issue of older protocols not supporting such a configuration is
an issue.  Time moves on, and progress gets made.  In my environment, new
capabilities are eagerly received, and put to good use right away, because
we tend to operate close to the edge of the envelope anyway.  And of course,
at that point, the market tends to demand these new capabilities, and 
people implement them to be competitive.

Your case about the business with the disjoint offices all wanting
their own Internet interconnects while still using a single class B won't
work, but not because of OSPF, but because that organization's connections
to the various regional or brand X networks and those net`s connections to
each other typically use EGP, which does not allow the passing of 
subnet data.  If everyone was glued together by one supernetwork, all
running an IGP like OSPF, then yes, it could work.  But that's not
likely to be the way people's connections would work in any case.

					Thanks,
					   Milo
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 12:59:27 GMT
From:      mintaka!snorkelwacker!bu.edu!orc!inews!iwarp.intel.com!psueea!parsely!twiki!dalew@CS.YALE.EDU  (Dale A. Weber)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Unix tar uncompression
jbvb@VAX.FTP.COM (James B. Van Bokkelen) writes:

> >I need a means of uncompressing UNIX tar files for a PC. Is there a
> >PC based utility available for this?
> 
> PC_NFS also has a network TAR.  If you want to "uncompress" a Unix
> .tar.Z file (made by piping 'tar' into 'compress'), you'll have to
> use 'uncompress' on the Unix system first.

  There is a very good 16 bit [de]compress utility for MS/PC-DOS. I use it
all the time when dealing with compressed files from *NIX. It came without
documentation so I tested it carefully before installing it on my BBS, but
it works great and now my system can handle 12 bit _and_ 16 bit compressed
files, all on my MS-DOS machine. I have no idea where this program is from
or who the author is though.

--
Internet: dalew@pdx.com OR dalew@twiki.pdx.com    # The AS/400 Specialists
UUCP: ..!{sun!nosun, tektronix}!tessi!twiki!dalew #
WORK: A-38 Specialists Consulting Group, Inc.     # Voice: +1(503)226-1662
      P.O. Box 42157, Portland, OR 97242-0157 USA # FAX:   +1(503)774-6348
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 13:58:56 GMT
From:      usc!samsung!ginsburg@ucsd.edu  (Scott Ginsburg)
To:        tcp-ip@nic.ddn.mil
Subject:   IP routing and gateways
I'm trying to get a handle on IP routing and gateway visibility for a
device (not necessarily running Unix) on an Ethernet. This device is
part of a class C network, has a single Ethernet interface, and there
will probably be more than one IP gateway to either the outside world
(T1, etc) or another class C network within the same installation on
a different Ethernet backbone. My questions are:

	1.) Is it the case that I need to provide a default gateway
	    address for IP packets that aren't destined for someone
	    within my subnet?

	2.) Do I need to implement an IGP like RIP and maintain routing
	    tables (even though this device only has one network
	    interface) so that I choose the correct gateway to route
	    my outgoing packets to, or is it OK to go to the same
	    gateway (default) every time?

	3.) If the answer to 2 is that it's not smart to go to the
	    same gateway every time, then is something like RIP (which
	    should be available on most Unix networks because of
	    routed) the way to go, or does the ICMP redirect take care
	    of letting me know that one internal gateway is better than
	    another for an outgoing packet?

						Thanks in advance,
						Scott
-- 
------------------------------------------------------------------------- 
Scott Ginsburg WA2CJT	  Voice: 508-685-7200  FAX: 508-685-4940
Samsung Software America  Internet: ginsburg@samsung.com
Andover, MA
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 14:42:09 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!tut!jh@ucsd.edu  (Juha Heinanen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?

In article <1990Jul10.003628.5859@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:

   Thus, for "commercial use" the simple, practical and almost true answer
   is that disjoint subnets are not allowed.

Depends what you mean by "commercial use".  If an organization that
previously has had its own IP backbone decides to become a user of a
commercial IP backbone then the situation is excatly such that would
call for connecting geographically separate subnets over another
network.  

If this can't be done then the commercial backbone operator is not
likely to get the customer.  In Finland, for example, the commercial
DataNet IP backbone will certainly switch from IGRP to OSPF for this
very reason alone if it really can solve the acute problem.

In the ISO world of NSAP addresses each organization can have several
so called routing domains which could be assigned one for each
separate network component.
--
--	Juha Heinanen, Tampere Univ. of Technology, Finland
	jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 15:10:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   RE: IP routing and gateways


 > My questions are:
 
>       1.) Is it the case that I need to provide a default gateway
>           address for IP packets that aren't destined for someone
>           within my subnet?
 
Only if you want them to get there :-).  Seriously, you'll need some
sort of route table entry or entries for the networks that you reach
by gateway.
 
>        2.) Do I need to implement an IGP like RIP ...
>            ... (even though this device only has one network
>           interface) ...
 
I wouldn't.
 
>                               ... or is it OK to go to the same
>           gateway (default) every time?
 
Not really, but see below.
 
>       3.) If the answer to 2 is that it's not smart to go to the
>           same gateway every time, then is something like RIP (which
>           should be available on most Unix networks because of
>           routed) the way to go, or does the ICMP redirect take care
>           of it.
 
Bingo!  If you have a decent IP implementation, then it will populate
its local routing table when it gets ICMP redirects.  BSD 4.3 does this.
Probably alot of other IPs do, too.
 
- Bob Stine

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 15:58:39 GMT
From:      manta!gutman@nosc.mil  (Lewis M. Gutman)
To:        tcp-ip@nic.ddn.mil
Subject:   TCPIP PD network management?
I have  a Macintosh II with an Excelan EtherPort II N card running NCSA
Telnet 2.3 for the Macintosh.  

I'm looking for various network management utilities that will run from
my Macintosh that will provide the same functionality as ping, nslookup,
traceroute, netwatch, and any other management utilities for TCP/IP 
over Ethernet.  Public domain is preferred.

Does anyone have any information on such utilities?  Thanks.

Lew Gutman
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 16:47:38 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!jsivier@tut.cis.ohio-state.edu  (Jonathon Sivier )
To:        tcp-ip@nic.ddn.mil
Subject:   Programming editor needed
HELP!!!!

    I need a text editor which I can actually use.  I need an editor which has
as a minimum all the functunality of vi, including named buffers, fence matching
and macros.  If it has additional features that would be fine, but crippled
versions of vi like stevie do me no good.  I need an editor which will run, with
minimal differences, on a variety of machines and operating systems.  I
currently am using; a VAXStation running VMS, an SGI IRIS running UNIX, PC
clones running MS-DOS and a Commodore Amiga running AmigaDOS.  Since it needs to
run on a VAX it would be best if it didn't require an escape key since the
VAX keyboard has no escape.  Does Emacs use the escape key?  If so is there a
way around it?  Does Emacs do fence matching for C programing?  Is there a
version of vi for the VAX which allows you to remap the escape key to another
key?  Is there anything out there anywhere?  Please respond if you know of
something which fit's these ridiculous requirements be it freeware, shareware
or commercial.

    Thanks for your assistance.

    Jonathan

-- 

Jonathan Sivier
jsivier@ux1.cso.uiuc.edu
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 17:24:40 GMT
From:      hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu  (Lars Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Wollongong TCP/IP ping question, VMS
In article <2521@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil
   (Esther Lumsdon) writes:
> [PING requires SYSPRV]
>Is it safe to install PING with SYSPRV privilege?
>Will it compromise my system security?
A matter of definition :-) :-) If you install PING with privilege,
anybody can use PING. This is useful, but do you want them to ?
(I.e. you may not want to pay for that essentially useless traffic).
(But pings from OTHER sites are probably more disruptive than outgoing
pings).

>Does Wollongong's PING do anything other than sending ping at target?
You mean, are there trojan horses in commercial code ? Of course you
should be suspicious of anything for which you don't receive source
code. If you are REALLY worried, you could write your own PING instead
of using TWG's.

>Is Wollongong's PING code written such that it uses SYSPRV carefully?
Why would you be more suspicious of PING than of say the FTP daemon ?

The reason PING requires privilege, is that it connects to a "raw"
socket; i.e. it interfaces at a level of the network package where you
can send *anything you like*. To prevent user programs from forging
authentic looking datagrams that pretend to be from somewhere else, the
network kernel has been made to insist that only privileged programs do
these things.

>I'll call Wollongong and ask these questions, and
>post answers to the net in a week or so.
>
>--------------------------  Esther Lumsdon  --------------------------------
>lumsdon@dtoa1.dt.navy.mil  lumsdon@dtrc.dt.navy.mil
>lumsdon%dtrc.navy.mil@uunet.uu.net
>"Wherever you go, there you are" -Buckaroo Bonzai


-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 19:00:40 GMT
From:      att!watmath!watserv1!utgpu!cunews!bcars8!bnrgate!bcars85!jsparkes@ucbvax.Berkeley.EDU  (Jeff Sparkes)
To:        tcp-ip@nic.ddn.mil
Subject:   DUP and FM in tn3270 4.1.1

	The following diffs make the DUP and Field Mark keys work properly
under tn3270 4.1.1. Apply in tn3270/api.

*** /tmp/,RCSt1a29408	Tue Jul 10 14:58:50 1990
--- asc_ebc.c	Tue Jul 10 13:11:13 1990
***************
*** 30,36 ****
  /* 00 */   0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,
  /* 08 */   0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,
  /* 10 */   0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,
! /* 18 */   0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,
  /* 20 */   0x40,  0x5A,  0x7F,  0x7B,  0x5B,  0x6C,  0x50,  0x7D,
  /* 28 */   0x4D,  0x5D,  0x5C,  0x4E,  0x6B,  0x60,  0x4B,  0x61,
  /* 30 */   0xF0,  0xF1,  0xF2,  0xF3,  0xF4,  0xF5,  0xF6,  0xF7,
--- 30,36 ----
  /* 00 */   0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,
  /* 08 */   0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,
  /* 10 */   0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,  0x00,
! /* 18 */   0x00,  0x00,  0x00,  0x00,  0x1C,  0x00,  0x1E,  0x00,
  /* 20 */   0x40,  0x5A,  0x7F,  0x7B,  0x5B,  0x6C,  0x50,  0x7D,
  /* 28 */   0x4D,  0x5D,  0x5C,  0x4E,  0x6B,  0x60,  0x4B,  0x61,
  /* 30 */   0xF0,  0xF1,  0xF2,  0xF3,  0xF4,  0xF5,  0xF6,  0xF7,
*** /tmp/,RCSt1a29408	Tue Jul 10 14:58:51 1990
--- ebc_disp.c	Tue Jul 10 13:51:38 1990
***************
*** 27,33 ****
  /*00*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
  /*08*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
  /*10*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
! /*18*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
  /*20*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
  /*28*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
  /*30*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
--- 27,33 ----
  /*00*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
  /*08*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
  /*10*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
! /*18*/	0x00,	0x00,	0x00,	0x00,	0x9f,	0x00,	0x9e,	0x00,
  /*20*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
  /*28*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
  /*30*/	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
***************
*** 82,88 ****
  /*80*/	0x81,	0x82,	0x83,	0x84,	0x85,	0x86,	0x87,	0x88,
  /*88*/	0x89,	0x91,	0x92,	0x93,	0x94,	0x95,	0x96,	0x97,
  /*90*/	0x98,	0x99,	0xa2,	0xa3,	0xa4,	0xa5,	0xa6,	0xa7,
! /*98*/	0xa8,	0xa9,	0xe1,	0xea,	0xeb,	0xec,	0xef,	0xfe,
  /*A0*/	0xc1,	0xc2,	0xc3,	0xc4,	0xc5,	0xc6,	0xc7,	0xc8,
  /*A8*/	0xc9,	0xd1,	0xd2,	0xd3,	0xd4,	0xd5,	0xd6,	0xd7,
  /*B0*/	0xd8,	0xd9,	0xe2,	0xe3,	0xe4,	0xe5,	0xe6,	0xe7,
--- 82,88 ----
  /*80*/	0x81,	0x82,	0x83,	0x84,	0x85,	0x86,	0x87,	0x88,
  /*88*/	0x89,	0x91,	0x92,	0x93,	0x94,	0x95,	0x96,	0x97,
  /*90*/	0x98,	0x99,	0xa2,	0xa3,	0xa4,	0xa5,	0xa6,	0xa7,
! /*98*/	0xa8,	0xa9,	0xe1,	0xea,	0xeb,	0xec,	0x1e,	0x1c,
  /*A0*/	0xc1,	0xc2,	0xc3,	0xc4,	0xc5,	0xc6,	0xc7,	0xc8,
  /*A8*/	0xc9,	0xd1,	0xd2,	0xd3,	0xd4,	0xd5,	0xd6,	0xd7,
  /*B0*/	0xd8,	0xd9,	0xe2,	0xe3,	0xe4,	0xe5,	0xe6,	0xe7,
--
Jeff Sparkes		jsparkes@bnr.ca
Another feature is that the seats float, so that the airline can recover
them if the plane crashes into the ocean. -- Dave Barry
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 19:18:36 GMT
From:      hub.ucsb.edu!spectrum.CMC.COM!spectrum.cmc.com!lars@ucsd.edu  (Lars Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?
I wrote:
> The most common case where clients ask about disjoint subnets, is where
> an enterprise is geographically disjoint (say offices in Los Angeles,
> Denver and Boston) and wants to attach each office separately to the
> Internet, while assigning all host addresses out of the same class B
> network number. This of course is utterly undesirable (would OSPF allow
> it to be set up at all ?) and contravenes all the intentions for which
> subnets were invented.

Paul Tsuchiya <tsuchiya@THUMPER.BELLCORE.COM> replied:
PT>Hmmm.  Why is it <of course> utterly undesirable that one organization
PT>in locations separated by the Internet not split up a Class B address?
PT>The only reason I can think of is that Internet routers are incapable of
PT>looking at subnet parts of the address--in other words, our Internet
PT>routers (or routing protocols) are inadequate.  The thing just simply
PT>wouldn't work.
Indeed. The intent of IP is to route based on the network number, and
for most low-level routers not to have to know very many routes. Subnets
were invented to allow an organization to have multiple routes
internally while presenting only one logical point of entry to the
outside world.

PT>However, I don't necessarily see something inherently bad about this.
PT>I mean, given today's address structure (net.subnet.host), what are the
PT>alternatives?
PT>First, the organization could have multiple class C addresses? However,
PT>this puts a load equal to subnetted class B addresses on the Internet.
PT>Each router must maintain one routing table entry for each location.
The organization could be made to connect the disjoint subnets
internally; in the worst case, this could be done by tunnelling in the
routers. This is not too unlike the old ARPA/MIL/NSF geographical
overlay. Each backbone router will route packets to the multi-site
organization to the closest point of entry, and that router will get it
to where it needs to get to, either directly, or wrapped in an envelope
with the backbone address of the entrypoint router on the other end.

PT>... However, a more general, multi-level hierarchical address scheme 
PT>coupled with an efficient address assignment scheme is what's needed.
The ultimate in general, multilevel hierachical address schemes is
ISO-IP, with its address format codes etc. IMHO, that way leads to utter
madness.

PT>Hear my ideas on this at the UCB IETF, or if you can't be there,
PT>ask me and I'll send you a paper on the topic.
Yes, I would like to see the paper. 

-------
Similarly, Milo S. Medin (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
    says:
MM>I don't think that the issue of older protocols not supporting such a
MM>configuration is an issue.  Time moves on, and progress gets made.
but at the same time:
MM>Your case about the business with the disjoint offices ... won't
MM>work, ... because that organization's connections
MM>to the various regional or brand X networks and those net`s connections to
MM>each other typically use EGP, which does not allow the passing of 
MM>subnet data.  If everyone was glued together by one supernetwork, all
MM>running an IGP like OSPF, then yes, it could work.  But that's not
MM>likely to be the way people's connections would work in any case.
- which was exactly my point. The "real" commercial networks are always
years behind the state of the "art".

Don't get me wrong: I think OSPF is great, and we should move to deploy
it instead of EGP as quickly as we can, from the core out. But so long
as not even the regionals are up to that level of sophistication, EGP is
the commercial reality, and those of us whose job is to "get me
connected NOW" have to find ways to live within those constraints.

-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 90 20:13:52 GMT
From:      ulysses!atti07!althea!eddjp@ucbvax.Berkeley.EDU  (Dewey Paciaffi)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Over SNA Networks
If you have done TCP/IP communications over an SNA network, I'd
like to hear from you. My company is buying two rs/6000s and we would
like them to do TCP over our corporate SNA network.

I'd like to know what it took hardware and software-wise to make it
work, as well as how well it actually does work.
-- 
Dewey Paciaffi
eddjp@althea.UUCP
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Jul 90 10:05:26 -0700
From:      "Philip Almquist" <almquist@jessica.stanford.edu>
To:        usc!zaphod.mps.ohio-state.edu!mips!wyse!vsi1!altos!altos86!mickey@ucsd.edu (Michael Thompson)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: How to limit broadcasts between expensively connected networks?
Michael,
> My question is: is there any way to (at the gateways) limit broadcast traffic
> over expensive connections?

	In general, broadcasts on one of your nets will not be forwarded
across the SLIP line to the other net.  The only exception that I know
of is that cisco routers can be configured (using "helper-address" or
whatever they call it now).

	If you are using a routing protocol, it can (depending upon the
protocol and the rest of your topology) generate a fair amount of
traffic across the SLIP link.  By clever configuration or by using
static routing you can minimize eliminate this traffic.

	If I were you, I would try to diagnose the problem more fully.
I don't know what kind of routers you are using, but most include the
facility to trace packets going through them.  Although that is hardly
recommended for regular use (since it slows the routers to a crawl),
such a facility is very useful for diagnosing the sort of problem you
are seeing.
							Philip
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 00:22:39 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!wyse!vsi1!altos!altos86!mickey@ucsd.edu  (Michael Thompson)
To:        tcp-ip@nic.ddn.mil
Subject:   How to limit broadcasts between expensively connected networks?

I have two local area networks connected via a slip connection over X.25.
(I know it's a hack, but I do get reasonable throughput)

		     gateway-A			   gateway-B
      144.1       ---------------   X.25(slip)	----------------  192.68.19
      (ethernet)  | 200.2.10.1  |<<----------->>| 200.2.10.2   |  (ethernet)
    <<---------->>| 144.1.10.98 |		| 192.68.19.42 |<<--------->>
		  ---------------	        ----------------
		  gateway to 200.2.10           gateway to 200.2.10
		  gateway to 192.68.19	        gateway to 144.1

When the gateways are configured as above, I can ping any machine on the
192.68.19 network from anywhere on the the 144.1 network (and vice versa).
However, I notice a lot of traffic across the X.25 line that I am guessing are
broadcasts (maybe from rwhod and/or timed??).  These broadcasts seem to
originate from machines other than the gateways since if I don't make
them appear as gateways between 144.1 and 192.68.19 the traffic is eliminated.

My question is: is there any way to (at the gateways) limit broadcast traffic
over expensive connections?


				Thanks,

				-Michael
				mickey@altos.Altos.COM
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 00:32:23 GMT
From:      excelan!manoj@ames.arc.nasa.gov  (manoj @ Prod Mktg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Novell to tcp/ip gateways
In article <25539@nuchat.UUCP>, abbadon@nuchat.UUCP (David Neal) writes:
> 
> Hello, I am looking for information on linking Novell networks
> running netware into a tcp/ip based network of suns.
> I want the pc users to be able to telnet into the ip network.

Novell has a family of prodcts for DOS, OS/2 and Macintosh that allows you
concurrent access to both TCP hosts (telnet, ftp etc..) and also NetWare systems

call them for literature on LAN WORKPLACE they are not gateways in NetWare 
but direct connect from the client desktop itself..


	manoj goel,                             	0 0
        Product Marketing                        	 ^  
        Novell/Excelan Inc., San Jose, CA            	\_/	
  (408) 473-8369 (voice) / 433-0775 (fax)     Internet: manoj@novell.com 
___________________________________________________________________________
	"For every vision, there is an equal but opposite revision"

           
	manoj goel,                             	0 0
        Product Marketing                        	 ^  
        Novell/Excelan Inc., San Jose, CA            	\_/	
  (408) 473-8369 (voice) / 433-0775 (fax)     Internet: manoj@novell.com 
___________________________________________________________________________
	"For every vision, there is an equal but opposite revision"
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Jul 90 09:21:43 EDT
From:      hung@eniac.seas.upenn.edu (  Han  Hung)
To:        beach@ddnuvax.af.mil, tcp-ip@nic.ddn.mil
Subject:   Re:  GOSIP from the grape vine
t~?

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 05:51:11 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!kwang@ucsd.edu  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Questions on SNMP

Hi... SNMP folks,

	Since I don't have any experiences on Network Management, I might be
asking pretty dumb questions. But I am curious, so please help me to understand.

1. How much did they define standard mechanisms for the archival, retrieval
and remote retrieval of management data so far ??

2. How much has been done for monitoring and management across administrative
boundaries ??

3. How can a proxy daemon be used to shield the agents from redundant network
management request and respond using cached info ??  How can SNMP proxy be
used to shield network elements from elaborate access control polices ??

4. Since I am working at the Database company, I always have the question
in my mind. We have a powerful distributed database product on the network.
But, there is NO WAY to monitor each node's database activities from the remote
site.  Can we apply SNMP/CMOT/CMIP technology to allow to do that ??

Thanks.

					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 06:27:09 GMT
From:      news!cartan!ndmath!nstar!comcon!tim@iuvax.cs.indiana.edu  (Tim Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Unix tar uncompression
In article <9007061308.AA11078@vax.ftp.com>, jbvb@VAX.FTP.COM (James B. Van Bokkelen) writes:
> >I need a means of uncompressing UNIX tar files for a PC. Is there a
> >PC based utility available for this?
> 
> Our PC/TCP product has a TAR.EXE which can assemble and disassemble
> Unix-compatible tar files either locally or over the network.  Sun's
> PC_NFS also has a network TAR.  If you want to "uncompress" a Unix
> .tar.Z file (made by piping 'tar' into 'compress'), you'll have to
> use 'uncompress' on the Unix system first.
> 
The 16 bit compress distributed with BNEWS compiles fine on DOS.  And
works the same.

Tim Brown
nstar!comcon!tim
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Jul 90 16:15:22 -0400
From:      tmallory@BBN.COM
To:        Peter Elford <zaphod.mps.ohio-state.edu!know!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu>
Cc:        tcp-ip@nic.ddn.mil, tmallory@BBN.COM
Subject:   Re: Can subnets be separated by another net?

OSPF is not the only routing protocol with "advanced" subnet support:

BBN has extended the SPF-based routing protocol used by the BBN T/20 Internet
Router and the RIG(developed for DARPA and RADC) to use arbitrary hierarchical
subnet masks, in which the mask bits need not be contiguous.  It will handle
the separated subnet scenario with no problems.

Tracy Mallory
BBN
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 10:10:45 GMT
From:      eru!luth!sunic!mcsun!cernvax!chx400!poole@BLOOM-BEACON.MIT.EDU  (Simon Poole)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: GOSIP from the grape vine
In article <CMM.0.88.647647249.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes:
.....
>
>There also seems to be the beginning of a plethora of so called
>gateways to get from smtp based mail systems to X.400 based systems,
>and might add full suite GOSIP x.400.  Now just how the heck you map
>some particular X.400 address to some particular user@host internet
>address  seems a little dicey.  From what I've seen, it looks like
>another big table to do the mapping.  Has anybody implemented one
>of these beasts and knows the definitive answer??

There are quite a few RFC987/1148 gateways out there (RFC987/1148
describe the mapping of X.400(84)/(88) to RFC822 and vice versa). 
Currently the tables which control the address mapping have around 600
entries. The main problem with them is not so much the size*, but the
fact that changes to the tables and installation of them has to be 
globally coordinated. For example: in the RARE MHS project, installation 
of new tables happens every two months.

*if you have a reasonable mapping strategy you can keep the number of entries
per country to a sensible number, we have five (plus mappings for RFC822 
top level domains: edu etc.), Germany ~180.
-- 
------------------------------------------------------------------------
						Simon Poole
 poole@verw.switch.ch / poole@chx400.switch.ch / mcsun!chx400!poole
------------------------------------------------------------------------
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 09:38:00 GMT+109:13
From:      "VAXA::DBURKE" <dburke%vaxa.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Where is XEROX
Date sent:  11-JUL-1990 09:39:03 

Hi folks,
	After spending more than 2 hours chasing down various telephone numbers 
given to me by "XEROX", I still haven't found what I'm looking for.  If anyone 
knows a telephone number for purchasing "GATEWAY" services that runs on a XEROX 
8090 fileserver, (part of the 6085 workstation network) please point me to it.

Please, no COMPUTERLAND telephone numbers!!!!!

(HOW CAN I ORDER WHAT I CAN'T FIND???)

Thanks
Dave
================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 15:18:46 GMT
From:      vixie!asylum!sharon@decwrl.dec.com  (Sharon Fisher)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: GOSIP from the grape vine
In article <CMM.0.88.647647249.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes:
>Now that implementation of GOSIP are appearing, or at are claimed, on
>certain vendor's shelves, I have a question or two maybe someone can 
>answer.  

Really?  Who?
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 15:44:53 GMT
From:      dburke%vaxa.decnet@NUSC-NPT.NAVY.MIL ("VAXA::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   Where is XEROX

Date sent:  11-JUL-1990 09:39:03 

Hi folks,
	After spending more than 2 hours chasing down various telephone numbers 
given to me by "XEROX", I still haven't found what I'm looking for.  If anyone 
knows a telephone number for purchasing "GATEWAY" services that runs on a XEROX 
8090 fileserver, (part of the 6085 workstation network) please point me to it.

Please, no COMPUTERLAND telephone numbers!!!!!

(HOW CAN I ORDER WHAT I CAN'T FIND???)

Thanks
Dave
================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 20:15:22 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Can subnets be separated by another net?


OSPF is not the only routing protocol with "advanced" subnet support:

BBN has extended the SPF-based routing protocol used by the BBN T/20 Internet
Router and the RIG(developed for DARPA and RADC) to use arbitrary hierarchical
subnet masks, in which the mask bits need not be contiguous.  It will handle
the separated subnet scenario with no problems.

Tracy Mallory
BBN

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 20:20:06 GMT
From:      lll-crg.llnl.gov!booloo@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP routing and gateways
In article <10900710151001.0004219666NB4EM@mcimail.com> 0004219666@MCIMAIL.COM (Bob Stine) writes:
> 
>>       3.) If the answer to 2 is that it's not smart to go to the
>>           same gateway every time, then is something like RIP (which
>>           should be available on most Unix networks because of
>>           routed) the way to go, or does the ICMP redirect take care
>>           of it.
> 
>Bingo!  If you have a decent IP implementation, then it will populate
>its local routing table when it gets ICMP redirects.  BSD 4.3 does this.
>Probably alot of other IPs do, too.
> 
>- Bob Stine

The down side to this is that you (potentially) get lots of entries in your
routing table.  And if you lose the gateway to which you have been redirected, 
you may not be able to get back to the original gateway (although it is possible
that a routing redirect might be removed if the moon is just right...).

Just more food for thought.
mb

food
for 
line
eater
.
.
.
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 20:41:59 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How to limit broadcasts between expensively connected networks?

I have two local area networks connected via a slip connection over X.25.
(I know it's a hack, but I do get reasonable throughput)

		     gateway-A			   gateway-B
      144.1       ---------------   X.25(slip)	----------------  192.68.19
      (ethernet)  | 200.2.10.1  |<<----------->>| 200.2.10.2   |  (ethernet)
    <<---------->>| 144.1.10.98 |		| 192.68.19.42 |<<--------->>
		  ---------------	        ----------------
		  gateway to 200.2.10           gateway to 200.2.10
		  gateway to 192.68.19	        gateway to 144.1

$Begin Response$

	Well, correct me if I am wrong (I'm sure someone will ;-), but
the ONLY *IP* broadcasts that should be going across the gateways
should be directed IP broadcasts. a 144.1.255.255 bcast should not be
forwarded from 144.1 to 192.68.19...

Are your gateways configured to be brouters? That would be the likely
way I can think of where broadcasts - ARPs and other non-IP - might be
passed from gateway to gateway? Rwho, and timed, being IP based,
should not be propagating across the gateways/routers. If they are
indeed brouters, you might try digging deep into the back of the
manuals to find-out how to set-up filtering for the 'bridged' packets
of the brouter.

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | Honest! It is TCP/IP! ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 22:30:05 GMT
From:      usc!cs.utexas.edu!chinacat!chip@ucsd.edu  (Chip Rosenthal)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Novell to tcp/ip gateways
{{{ followups directed out of tcp-ip }}}

In article <1524@excelan.COM> manoj@excelan.COM (manoj @ Prod Mktg) writes:
>call them for literature on LAN WORKPLACE

Ha!  This is pretty funny.  Mr. Goel, why don't *you* try calling them
for literature.  I did a couple of weeks back.  The closest I ever got
was your voice mail system, and a few days later, a good round of telephone
tag with a sales critter.  I shudder to think that if it's this tough to
get sales help, what's it going to be like to get applications support?
Never did get to talk to anybody.  Needless to say, the client will not
be using Novell products for this project.

-- 
Chip Rosenthal                            |  You aren't some icon carved out
chip@chinacat.Unicom.COM                  |  of soap, sent down here to clean
Unicom Systems Development, 512-482-8260  |  up my reputation.  -John Hiatt
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 90 23:50:01 GMT
From:      usc!hacgate!ladcgw.ladc.bull.com!melb.bull.oz.au!sun0!sjg@ucsd.edu  (Simon J. Gerraty)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: telnet and pc's

In article <8285@b11.ingr.com> griffin@b11.ingr.com (Tommy Griffin) writes:
> We're experiencing some difficulty communicating between our
> workstations and PCs using Telnet over TCP/IP.  The PCs are running
> Sun's PC/NFS product through the 3-Com Ethernet card.
> [...]
> The problem seems to be caused by the PC's inability to receive and/or
> process Ethernet/TCP frames which arrive within 5 milliseconds of each
> other.  Our workstation sends output to the PC in TCP frames carrying
> 64 bytes of data.  The 512 byte TCP window offered by the PC's TCP
> allows us to send up to 8 frames inside one window, so these frames
> can arrive with very little inter-frame spacing.  When the PC drops a
> frame, we have to retransmit the data that was lost.  The Jacobson
> algorithm in our implementation of TCP causes us to *DOUBLE* our
> retransmission timer each time we have to retransmit data.  We
> eventually increase the retransmission timer to  its maximum value, 20
> seconds, which explains why we're seeing bursts of data every 20
> seconds.

I found very similar problems when trying to get various PC
telnets to communicate with a Pyramid 9810 (I think the model is
correct).  I was actually there to get a telnet that I had
written working with the Pyramid.  Other telnets in use at the
site were NCSA, and PC/NFS.  We had similar performance to what
you describe only worse.  The Pyramid would echo key-strokes to
the PC's within 5ms and in most cases the PC's would miss the
echo.  This resulted in very sporadic response appearing on the
user's screen.

The PC's involved were mostly 25MHz 386's using 16bit WD
Ethernet cards.  Interestingly, using an 8bit 3Com card on an
8MHz 286, got better performance!

My conclusion was that the faster PC/adapters were able to get
them selves ready to send another frame, just as the echo
arrived (and thus miss it), whereas the slower PC/adapter was
more often in a state where it could accept the echo.

In all cases however we usually got to a point where lots of
retries were occuring and apparent performance was poor.
Cutting the window size and segment size to a minimum helped but
did not solve the problem.

> [...]
> It seems that the Sun workstations somehow determine that they're
> communicating with Sun PC/NFS on a 3-Com card, because they only allow
> one TCP frame to be transmitted to the PC at a time.  They send a
> frame, and wait for an acknowledgement (or a retransmission timeout),
> then send another frame, and so on.  This occurs even if the frame
> contains less data than the offered window size.

The PC/NFS telnet does terminal type negotiation and declares
itself as type "SUN".  This may or may not be the flag the sun
notices, since in other respects the telnet connection seems
straight forward.
Mind you my telnet negotiates a type of VT220, and had no
problems with talking to Sun's (using WD or 3Com cards) so I may
be wrong.

> When we Telnet between Suns, or from Suns to our workstations, the
> Suns transmit many small TCP frames containing data in the offered TCP
> window before waiting for an acknowledgement.
> 
> We would like to communicate effectively between our workstations and
> PCs with the Sun PC/NFS Telnet through the 3-Com Ethernet controller.

As I indicated above, it isn't just PC/NFS you need to worry
about, nor is it just 3Com cards.

The suggestion I made to the Pyramid Tech rep. was (may be a bad
idea but here goes :-) 
Modify the IP implementation so that a frame is not transmitted
to an address from which a frame was most recently received or
to which a frame was most recently sent.
The assumption here is of course that on a host there will
always be IP datagrams waiting to be sent to multiple
destinations.  By ensuring that no destination is sent two
frames in a row, or that a frame is not sent to a destination
that we just received from, we effectively increase the delay
between frames to each destination without affecting the overall
throughput of the host.
This approach may be too simplistic, and something better might
be needed, but the simple fact is that even fast 386 PC's with
fast ethernet adapters cannot keep pace with many UNIX hosts.
Any UNIX vendor that wants their host to appear to perform well
when using PC's as telnet terminals, needs to pace its output to
each PC.

Sorry if this is all old hat...
--
Simon J. Gerraty
sjg@sun0.melb.bull.oz.au - NET
..!{hplabs,mcvax,nttlab,ukc,uunet}!munnari!sun0.melb.bull.oz.au!sjg - UUCP
#include <disclaimer>             /* imagine something *very* witty here */
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Jul 90 09:32:23 edt
From:      tsuchiya@thumper.bellcore.com (Paul Tsuchiya)
To:        hub.ucsb.edu!spectrum.CMC.COM!spectrum.cmc.com!lars@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Can subnets be separated by another net?
Lars Poulsen writes:

> The ultimate in general, multilevel hierachical address schemes is
> ISO-IP, with its address format codes etc. IMHO, that way leads to utter
> madness.

What is IMHO?

Also, ISO-IP addresses are the ultimate in administratively hierarchical
address assignment, but have a long ways to go still in having a
topologically meaningful hierarchical address.  But I'm working on them
too.

PT
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 90 05:34:43 GMT
From:      arizona.edu!leonard@arizona.edu
To:        tcp-ip@nic.ddn.mil
Subject:   new telnet client swallows CRLF's?
We have seen a problem with recent implementations of telnet client
talking to VMS/MultiNet.  What happens is that, in some cases, output
lines echo terminated by <cr> rather than with <cr><lf> - in other
words, multiple lines overwrite one on top of the other.

We have experienced the problem running telnet from a VAX running
the Dec. '89 release of Mt Xinu 4.3BSD into VAXen running MultiNet 
V2.1 and 2.2.  This problem did not manifest in prior releases of 
the Mt Xinu software, nor does it appear in telnets from the Mt 
Xinu machine into other systems.  Telnet FROM MultiNet into Mt 
Xinu works fine, as does rlogin from Mt Xinu into MultiNet.

Disconcertingly, the most recent software release from Sequent is
also seen to manifest the problem (Dynix V3.0.12[?].)
(That is, its telnet client behaves the same as Mt Xinu's does.)
I infer from this that the problem has crept into the most recent 
BSD "standard" telnet, and is now appearing in vendors' products.

It appears that what happens is this: the MultiNet side issues a 
<cr><lf><cr> sequence at the end of the line.  While this is clearly
not optimal (TGV says that this is a problem with the VMS terminal 
driver), one would think that the second <cr> should be an esthetic
noop.  The new telnet clients, however, output the line modulo the CRLF, 
so that such lines echo with only the CR.  This seems wrong to me, and is
painful to our users.

Can anyone verify or rebut my analysis, or offer a workaround?
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 90 06:45:10 GMT
From:      qualcom!jwn2@ucsd.edu  (John Noerenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   WIN/TCP for VMS 5.1 NTYDRIVER bug
When users paste long segments of text from one Mac application into a Telnet
window open to a VAX, the VAX regularly loses portions of the text.  I traced
this to improper coordination between NTYDRIVER and TTDRIVER in VMS, and
reported the problem to Wollongong.  TTDRIVER tries to xoff NTYDRIVER, but
NTYDRIVER ignores the request, throwing down characters while TTDRIVER catches
its breath.

When I called Wollongong's technical support, the guy I talked to mumbled
something about "oh that problem...review committee...mumble-mumble-mum..",
but that was 6 months ago.

Does anyone know if a patch exists for this?  I apologize if I'm bringing up
old news, but I've still got the bug, and I'm not getting any younger... 

Thanks from this poor, stranded luser in VMS-land!
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Jul 90 11:00:06 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        tsuchiya@thumper.bellcore.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Can subnets be separated by another net?
Paul Tsuchiya writes:

>Also, ISO-IP addresses are the ultimate in administratively hierarchical
>address assignment, but have a long ways to go still in having a
>topologically meaningful hierarchical address.  But I'm working on them
>too.

Seems to me that imbedding topological meaning in an address is not
necessarily a good idea.  That implies that as I move my portable around the
network (from hotel to hotel, or, worse yet, on a cross country trip with a
mobile phone), its address has to change.  We have that problem now with SLIP
connections.  A name service could track the change so you could always reach
me by name, but the more I move the more I have to change the name mapping,
and such mappings usually don't appreciate being changed very much.

*I*n *M*y *H*umble *O*pinion, hierarchical administration for initial address
assignment works nicely, such as with Domain Name Service or Ethernet global
addresses, but should really be independent of routing.  Of course, flat
addresses don't offer any built-in efficiencies for finding the right
neighborhood, like IP addresses do now...

Tradeoffs, tradeoffs, always tradeoffs.  Why can't there just be a right
answer? 

	Bob

-----------
Bob Stewart (rlstewart@eng.xyplex.com)
Xyplex, Boxborough, Massachusetts
(508) 264-9900

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Jul 90 11:40:41 edt
From:      tsuchiya@thumper.bellcore.com (Paul Tsuchiya)
To:        stewart@xyplex.com, tsuchiya@thumper.bellcore.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Can subnets be separated by another net?
From Bob Stewart:
> 
> Seems to me that imbedding topological meaning in an address is not
> necessarily a good idea.  That implies that as I move my portable around the
> network (from hotel to hotel, or, worse yet, on a cross country trip with a
> mobile phone), its address has to change.  We have that problem now with SLIP
> connections.  A name service could track the change so you could always reach
> me by name, but the more I move the more I have to change the name mapping,
> and such mappings usually don't appreciate being changed very much.
> 
> *I*n *M*y *H*umble *O*pinion, hierarchical administration for initial address
> assignment works nicely, such as with Domain Name Service or Ethernet global
> addresses, but should really be independent of routing.  Of course, flat
> addresses don't offer any built-in efficiencies for finding the right
> neighborhood, like IP addresses do now...
> 
> Tradeoffs, tradeoffs, always tradeoffs.  Why can't there just be a right
> answer? 
> 

Yes, tradoffs.  In my latest work, I have proposed 1) hierarchical
addresses reflecting the topological hierarchy, and 2) institutionalizing
multiple addresses to reflect, for instance, those cases where a
system is connected into the network in multiple places.  This latter
thing means that when you go to directory service or DNS, you get back
MULTIPLE ADDRESSES.  You pick one for your TCP connection (or whatever)
based on policy.  In other words, each address essentially represents
a different path, which you choose by picking an address.  I even
think that the list of valid addresses should be conveyed to the
destination by a TCP option in the call setup, and the destination
can send back in the call accept the list, possibly pruned by its
policy choices.

Well, I'm getting ahead of myself.  Anyway, what I have found is,
from a system's perspective, shoving part of the routing problem
into DNS is a GOOD tradeoff.  In general, I think we have concentrated
too much on automatic routing, and not enough on automatic address
management.  Our architecture and protocols do not take advantage of
the significant degree of freedom afforded by letting addresses be
more flexible--having multiple of them, changing them during a
transport connection, stuff like that.

Anyway, as I have said, read my paper.  It covers a lot of stuff.
Also, plan on getting sick and tired of my new-found religious
perspective.  It's been a while since I've had a soapbox to shout
from.

PT

ps.  IMHO.  I like that.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 90 18:06:07 GMT
From:      venus!yalevm!maine!shanley@CS.YALE.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Can't telnet to myself
Machine:   3B2-400
           Wollongong TCP/IP WIN*/3B Rel 3.0.1
           Unix V 3.1
 
Problem:   I can telnet out from the machine, but I can't telnet
           into the machine.
 
           example:  telnet me or telnet umofm.umeofm.maine.edu
                     neither works
 
           I can ftp in and out of the machine just fine.
 
Any help is appreciated.
 
Thanks!
 
Kevin Shanley
shanley@maine.caps.maine.edu
shanley@umofm.umeofm.maine.edu
 
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Jul 90 00:34:39 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        usc!samsung!ginsburg@ucsd.edu  (Scott Ginsburg)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IP routing and gateways
The Host Requirements RFC (lower layers, RFC 1122) has quite a bit to
say about this:

	1.) Is it the case that I need to provide a default gateway
	    address for IP packets that aren't destined for someone
	    within my subnet?

Yes.  Allowing several would be better than only one.

	2.) Do I need to implement an IGP like RIP and maintain routing
	    tables (even though this device only has one network
	    interface) so that I choose the correct gateway to route
	    my outgoing packets to, or is it OK to go to the same
	    gateway (default) every time?

It is quite acceptable to go to the first choice until you fail-over
to another in the default list based on upper-layer advice or failure
to reply to ARP, etc.  ICMP Redirect was designed to supplement the
default gateway with real-time advice about which gateway of all those
Oactive on the net at any given time is "best".  The intent was to allow
hosts to avoid hacking routing protocols...

	3.) If the answer to 2 is that it's not smart to go to the
	    same gateway every time, then is something like RIP (which
	    should be available on most Unix networks because of
	    routed) the way to go, or does the ICMP redirect take care
	    of letting me know that one internal gateway is better than
	    another for an outgoing packet?

The problem with implementing one routing protocol is that you'll
have to do them all (RIP, IGRP, OSPF, IS-IS....) before you have real
interoperability.  In particular, there are many people awaiting
their chance to be RIP's pallbearers (at least at their local sites).

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 90 21:08:53 GMT
From:      logicon.com!tots!tep@nosc.mil  (Tom Perrine)
To:        tcp-ip@nic.ddn.mil
Subject:   Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <9007121800.AA01850@xap> stewart@xyplex.com (Bob Stewart) writes:
>Paul Tsuchiya writes:

>Seems to me that imbedding topological meaning in an address is not
>necessarily a good idea.  That implies that as I move my portable around the
>network (from hotel to hotel, or, worse yet, on a cross country trip with a
>mobile phone), its address has to change.  We have that problem now with SLIP
>connections.  A name service could track the change so you could always reach
>me by name, but the more I move the more I have to change the name mapping,
>and such mappings usually don't appreciate being changed very much.
>
>*I*n *M*y *H*umble *O*pinion, hierarchical administration for initial address
>assignment works nicely, such as with Domain Name Service or Ethernet global
>addresses, but should really be independent of routing.  Of course, flat
>addresses don't offer any built-in efficiencies for finding the right
>neighborhood, like IP addresses do now...
>
>Tradeoffs, tradeoffs, always tradeoffs.  Why can't there just be a right
>answer? 
>
>	Bob

But there is a right answer! Everyone will now use PPP over...
	cellular telephone dial-ups!! :-)

I hate to admit it, but the cell-phone (phone system) model of
addressing does have many advantages for the *user*. No matter where
you go, your logical address (phone number) follows you.

Of course, this puts all of the burden on the switching system, and
the routing can often be far from optimal for a roaming cell phone
user. I imagine that the main reason that this works for cell phones
is that there is enough "excess" capacity in the switching system to
handle the (hopefully) relatively rare, inefficient cases of roaming
cell phones, which are a very small part of the switching load.

Is there anything that we can learn (read "steal") from this example?


Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM
Logicon                                 |UUCP: nosc!hamachi!tots!tep
Tactical and Training Systems Division  |-or-  sun!suntan!tots!tep
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 02:16:14 GMT
From:      ddl@husc6.harvard.edu  (Dan Lanciani)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: new telnet client swallows CRLF's?
In article <1990Jul11.223443.1@arizona.edu>, leonard@arizona.edu writes:
| We have seen a problem with recent implementations of telnet client
| talking to VMS/MultiNet.  What happens is that, in some cases, output
| lines echo terminated by <cr> rather than with <cr><lf> - in other
| words, multiple lines overwrite one on top of the other.
| 
| We have experienced the problem running telnet from a VAX running
| the Dec. '89 release of Mt Xinu 4.3BSD into VAXen running MultiNet 
| V2.1 and 2.2.  This problem did not manifest in prior releases of 
| the Mt Xinu software, nor does it appear in telnets from the Mt 
| Xinu machine into other systems.  Telnet FROM MultiNet into Mt 
| Xinu works fine, as does rlogin from Mt Xinu into MultiNet.
| 
| Disconcertingly, the most recent software release from Sequent is
| also seen to manifest the problem (Dynix V3.0.12[?].)
| (That is, its telnet client behaves the same as Mt Xinu's does.)
| I infer from this that the problem has crept into the most recent 
| BSD "standard" telnet, and is now appearing in vendors' products.
| 
| It appears that what happens is this: the MultiNet side issues a 
| <cr><lf><cr> sequence at the end of the line.  While this is clearly
| not optimal (TGV says that this is a problem with the VMS terminal 
| driver), one would think that the second <cr> should be an esthetic
| noop.  The new telnet clients, however, output the line modulo the CRLF, 
| so that such lines echo with only the CR.  This seems wrong to me, and is
| painful to our users.
| 
| Can anyone verify or rebut my analysis, or offer a workaround?

	I believe that you are seeing a bug that was introduced in
the "tahoe" release and later "fixed" in the 4.3 networking distribution.
(I say "fixed" rather than fixed because the code still doesn't do what
it appears to have been intended to do but in fact seems to do nothing at all.)
The following is mostly from memory, so check the sources carefully...
	In the tahoe telnet, look for the "case TS_CR" in the receiver state
machine.  Observe that the else clause can discard a newline when it
shouldn't.  Worse, note that the behavior will depend on how much
data was available when the last read of the network connection was
done!  That is, had the newline been in the same buffer as the CR,
it would not have been dropped and state TS_CR would not have been entered.
	Now examine the same case in the 4.3 networking distribution.
Note that the else clause has been changed such that if the character
is a newline and a few other things are true, the character is added
to the output queue.  On the other hand, if the character is not a newline
or any of the other things are not true, the character is *still* added
to the output queue as we fall through to the TS_DATA state.

				Dan Lanciani
				ddl@harvard.*
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Jul 90 13:37:50 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: How to limit broadcasts between expensively connected networks?
If the routers in use are actually 4bsd Unix systems, all the ones
I've ever seen forward both RIP and RWHO packets out all their
interfaces (SLIP included) by default.  I don't recall anything in
the manual pages which indicate that either broadcast can be
restricted to a subset of the attached interfaces, but my memory
isn't quite perfect, and I havn't read the source...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
 
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 15:21:00 EST
From:      "Murl McRae" <mcrae@mk6vms.nwscc.sea06.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   WIN/TCP Window Size
I need to change the TCP window size in WIN/TCP 3.2.  Can anyone tell me
if it can be changed and if so, how?  Thanks.

Murl McRae                              Naval Weapons Support Center
                                        Crane, Indiana

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 12:47:27 GMT
From:      eru!luth!sunic!mcsun!hp4nl!philapd!idcapd!cssnl!eric%cssoff.syssup.tds.philips.nl@bloom-beacon.mit.edu  (Eric van Rheenen)
To:        tcp-ip@nic.ddn.mil
Subject:   XID broadcast problems

Hello tcpip experts,

This is my second posting of this question, but I didn't get any response.
This is probably caused by a problem we had discovered by the machine that
supplies us with the news.

I have a problem with a network containing SUN's, ICL's and Motorola
Delta series 8000 computers using the tcpip protocol.

We have discovered that the SUN machines are sending XID broadcasts
in this tcpip environment. This resulted in a havy netload from the 
motorola machine, because the response was wrong. We have fixed this
problem, it doesn't respond anymore to this braodcasts :-).

The customer now wants the Motorola machine to respond
to this XID broadcasts in a proper way (for him).

In our opinion, the XID protocol and associated frames are not part of
the tcp/ip protocol. They are part of the OSI LLC protocol. Also the
MAC layer doesn't have an OSI stack to handle the messages for
processing. Thus ignoring the broadcasts is the best solution.

Question:
- Does anybody know why SUN has implemented XID broadcasts in a tcpip
  environment.

Eric van Rheenen
Philips Informatie Systemen Nederland B.V.
Tel  : +31 (0)55 - 43 3372      |  UUCP:  uunet!hp4nl!philapd!cssnl!eric
Fax  : +31 (0)55 - 43 3487      |  NET :  eric@syssup.tds.philips.nl
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 15:55:26 GMT
From:      nuchat!abbadon@uunet.uu.net  (David Neal)
To:        tcp-ip@nic.ddn.mil
Subject:   novell<->tcp/ip


I posted a message a few days ago about novell<-> gateways.

Since then, I have gotten several informational messages and quite
a few "Me too's!".

So, I am going to post two summary messages. One that is strictly
informational, i.e. I will pass along all the information for
vendors and ftp sites I have received.

The second will be more subjective, and will include my experiences
with testing the various solutions.

The first summary should be next Wednesday or so; I want to make sure
everyone who is going to reply has a chance to do so.

The next summary is probably a month away, because I work for a government
contractor and it takes five levels of signatures just to get a P.O.
to order test software. sigh.

-- 
David Neal
abbadon@nuchat.uucp
abbadon%nuchat@{rice, bcm, texbell, uunet}
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 17:39:45 GMT
From:      usc!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!mephisto!uflorida!novavax!rm1!schunich@ucsd.edu  (Geoffery Schunicht)
To:        tcp-ip@nic.ddn.mil
Subject:   SIGPIPE not received until second write

   I'm working on a project that needs to communicate over sockets to
other machines.  In doing initial testing of possible errors
encountered while using sockets I found that the SIGPIPE signal seemed
to be delayed by one write call when the server was killed off.  The
sockets are set up in the AF_INET address format, using the tcp
protocol and the type is SOCK_STREAM.  The client and server are in the
connected state, sending messages successfully.  If I kill off the
server, the client will make one write successfully (no errors at
all),  but the second will cause the SIGPIPE signal to occur.  We do
want to be able to handle the error and continue processing all other
incoming/outgoing data to those processes still up.  This will occur 
on all the BSD systems we are running, SUN4's, SUN3's, DEC3100, 5400,
etc.

    If has anyone seen this before, or know if there is some initial
set up for the socket or entire network that is missing please email
the solution.  I can get around the problem by doing a second write of
zero bytes right after the first, but this is wasting a system call.

                                           Thanks in advance.

					   Geoff Schunicht
--

uucp: ...novavax!rm1!schunich
schunich@rm1
Work: 305-846-6907
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 17:41:23 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <153@tots.UUCP>, tep@tots.UUCP (Tom Perrine) writes:
> I hate to admit it, but the cell-phone (phone system) model of
> addressing does have many advantages for the *user*. No matter where
> you go, your logical address (phone number) follows you.

In all of the cellular systems I've used so far, roaming is only half
automatic.  In particular, to place a call to a roamer, you have to dial
the roamer access number for the area where they are, and then dial their
phone number.  This amounts to source routing, which is even more of a
pain for mobile destinations than it is for "static" ones.  Bleah.

Maybe Motorola's proposed satellite-based cellular system will be better.

That's it!  We put the core gateways into geosynchronous orbit... :-)

--
Amanda Walker <amanda@intercon.com>
Postmaster With An Attitude
InterCon Systems Corporation
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 19:29:18 GMT
From:      shlump.nac.dec.com!eagle1.enet.dec.com!brunner@decuac.dec.com
To:        tcp-ip@nic.ddn.mil
Subject:   How to get RFC documents dealing with TCP-IP
I am sorta new to all of this. Can anyone give me a pointer to on-line
copies of the RFC (Request For Comments) documents. I am especially
interested in the ones that describe BOOTP and IP/UDP.

thanks! 

{ Rich Brunner / Digital Equipment Corporation / brunner@eagle1.enet.dec.com }
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 19:58:16 GMT
From:      miorelli@pwa-b.uucp (BoB Miorelli)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Request comments on VMS TCP/IP products


Our company currently has two non-communicating networks running on
a common Ethernet.  Our workstations and Unix boxes use TCP/IP and
our VMS systems use DECnet.  We would like to have the VMS machines
become part of the TCP/IP world.  

I am soliciting recommendations from people actually doing this.
I know of several products, but need to hear the good points and
horror stories about each one.  We will be using the standard
stuff such as telnet, rlogin, ftp, as well as some local code
using udp and unix sockets for communication.

Thanks for your input.

-- 

-->BoB Miorelli, Pratt & Whitney Aircraft
           also, H & R Block tax preparer and Instructor
pwa-b!miorelli

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 20:21:00 GMT
From:      mcrae@mk6vms.nwscc.sea06.navy.mil ("Murl McRae")
To:        comp.protocols.tcp-ip
Subject:   WIN/TCP Window Size

I need to change the TCP window size in WIN/TCP 3.2.  Can anyone tell me
if it can be changed and if so, how?  Thanks.

Murl McRae                              Naval Weapons Support Center
                                        Crane, Indiana

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 20:58:33 GMT
From:      phri!news@nyu.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Why does a wrong broadcast address cause arp-havoc?

	By watching with tcpdump, I can see that when an occassional IP
object gets configured with the wrong broadcast address, each time it sends
a broadcast packet, a flurry of arp requests are generated by various
machines on the network.  I sort of understand what is going on, but not
exactly.  We use a hostpart of .0.0 for broadcasts, but once in a while a
misconfigured box pops up with .255.255, which other machines then try to
arp for.

	What I don't understand is 1) why they bother to arp at all and 2)
why only some machines do it?  As I understand it, when a machine wants to
send an IP packet, it has to arp to find out what link-level address to put
in the ethernet dst field.  But why should a machine try to do an IP->ether
address resolution just because it receives an rwho packet sent to the
wrong IP broadcast address?  An rwho requires no response, so there really
isn't any reason to need to know where it came from.  As for the second
question, what is it about some machines that makes them arp for bad
broadcasts and others not?  In our particular case, we have a bunch of
Sun-3's, all running SunOS-3.5.2.  One of them runs a generic kernel, and
that's the only one that arps in response to .255.255 packets.  All our
other Suns run customized kernels, but the only customizations are to
delete device drivers they don't need; nothing (that I know of) has been
changed in the networking code, yet they don't arp .255.255's.  Why not?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 90 22:59:54 GMT
From:      ssc-vax!bcsaic!carroll@beaver.cs.washington.edu  (Jeff Carroll)
To:        tcp-ip@nic.ddn.mil
Subject:   porting Berkeley lpd code to sys V R3.2

	I would very much like to hear from anyone who has experience
porting BSD code to system V/386. I'm trying to get lpd, lpr, lpq, et
al. to run on our Intel 301s, which run Intel (Lachman) TCP/IP.
	The larger goal is to enable our Vax running WIN/TCP or MultiNet
to act as a print server for the 301s.
	Do I have to get *all* the BSD libraries and what not, or is
there an easier way to map the bsd system calls into the sys V and
Lachman libraries?
	How big a job is this?

	Jeff Carroll
	carroll@atc.boeing.com
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 90 00:22:06 GMT
From:      bellcore-2!envy!karn@bellcore.com  (Phil R. Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)

In article <269E07C3.604D@intercon.com>, amanda@mermaid.intercon.com
(Amanda Walker) writes:
|> Maybe Motorola's proposed satellite-based cellular system will be better.
|> 
|> That's it!  We put the core gateways into geosynchronous orbit... :-)

The satellites in Motorola's proposed "Iridium" system would NOT be in
geosynchronous orbit, they would be in low altitude polar orbits. As
such, the system is much more like the Multiple Satellite System (MSS)
that DARPA looked at a few years ago. Dave Mills was one of the
investigators.

Satellites in low altitude orbits move quite rapidly, so this will
present a very interesting problem in routing. On the other hand,
orbits are quite predictable, so at least you can compute your
connectivity matrix at any desired time in the future.

Back in the early days of communications satellites, it was not yet
clear that geostationary was the way to go at that time. Many paper
proposals for fleets of satellites in low earth orbit were made, but
they never went very far because of the limits of the ground station
technology in those days.

Phil
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 90 10:02:03 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does a wrong broadcast address cause arp-havoc?

broadcasts cause arp storms because of a combination of over
friendliness and confusion.  Suppose you've got a system that things
the broadcast address is 128.6.0.0 (an old 4.2 system).  Now you have
a system that sends using the correct broadcast address, which for my
local subnet is 128.6.4.255.  The old system will see this packet,
since it's a broadcast.  The IP input code will look, not recognize it
as a broadcast, and assume that 128.6.4.255 is a host.  Since most IP
code is capable of acting as a gateway, it will assume somebody is
trying to use it as a gateway, and thus try to forward the packet to
128.6.4.255.  This will cause it to send an ARP request for
128.6.4.255.  Another scenario is that you send a broadcast for
255.255.255.255 (the correct generic local broadcast).  An old host
may not recognize this as a broadcast.  It will think this is a packet
destined for network 255.  Since it doesn't have a route to network
255, it may try to send back an ICMP unreachable.  This will cause it
to ARP the original sender.  There are all sort of scenarios like
this.  They are complicated by various bugs.  E.g. one implementation
ended up sending ICMP errors to a broadcast address.  What's really
amusing is if somebody answer an ARP for 128.6.4.255 with a response
giving Ethernet address ff.ff.ff.ff.ff.ff.  In some sense this is
right.  However this can result in all sorts of mischief.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 90 00:57:09 GMT
From:      usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!gopnbg!tmpmbx!einoed!utopia!scuzzy!src@ucsd.edu  (Heiko Blume)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability / little flow control primer
jc@minya.UUCP (John Chambers) writes:

>Be careful here.  Where I work, we've been running SLIP over some modems
>that do MNP, and we use raw mode.  The reason is that the MNP comes with
>software flow control, which means that any packet with a ^S causes the
>link to die.  It usually doesn't take too long for such a packet to come
>along.

that's not correct. the modem to modem link should be settable to
100% transparent. mnp doesnt care about what data is sent over the line.
(at least if your modems are worth anything at all). your problem is
the flow control between the modems and the serial ports. you *should* use
hardware flow control (cts/rts). to do that your serial drivers must be
capable to do that. some unix implementations and especially many multiport
cards don't support that. it might be possible that some SL/IP implementations
support XON/XOFF flow control, but i wouldn't try that anyway. however
if you really want to use XON/XOFF your SL/IP must support it. (see below too).

>I spent of bunch of time on the phone with Customer Support people at
>the manufacturer (Codex), trying to figure out how to correctly configure
>the modems, and all I got from them was "Of course you want flow control; 
>you'll lose data without it."  They couldn't conceive of an application
>that didn't care about lost data.  If there's a way to do MNP that lets 
>*all* 8-bit values pass, they wouldn't or couldn't tell me how to do it.

i've never heard of codex, but anyway: i assume that these are fast modems
that use MNP class 5 or higher to yield speeds of 4800 bps or higher.
i'll go into some depths now as far as i know about my hardware.
however i think that good modems should work like this.
i use US Robotics Courier HST modems that implement MNP 5 to achieve 14000 bps.
to implement flow control HSTs offer a *lot* of options:

- transmit data flow control can be set to
  - flow control disabled
  - hardware (cts) flow control
  - software flow control (XON/XOFF)
  - hardware AND software flow control.

- received data (modem/other_host to host) software flow control can be
  - disabled
  - XON/XOFF to modem AND remote host
  - XON/XOFF to local modem only
  - HP protocol (ACK/NAK)

- received data hardware flow control can be
  - disabled
  - pass received data on rts high

remember that these are the options for *each* host/modem pair.
all these can be set in any combination to yield lots of funny results.
especially the XON/XOFF to modem AND remote host is dangerous, not to speak
of using hardware and software flow control simultaneously....
therefore i strongly recommend using rts/cts on both sides. otherwise
you'll have to do some serious planning/configuring.

have a look at your modems manual. if they don't support hardware flow control,
i'd buy other modems.

good luck!
-- 
Heiko Blume c/o Diakite   blume@scuzzy.mbx.sub.org    FAX   (+49 30) 882 50 65
Kottbusser Damm 28        blume@netmbx.UUCP           VOICE (+49 30) 691 88 93
D-1000 Berlin 61          blume@netmbx.de             TELEX 184174 intro d
                    "Have you bugged your source today?"
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 90 22:16:36 GMT
From:      usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Still Looking: Access to Internet
In article <71@nic.cerf.net> pushp@nic.cerf.net (Pushpendra Mohta) writes:

   A copy of CERFNet's acceptable use policy can be obtained by
   anonymous ftp to nic.cerf.net from the cerfnet/cerfnet_info
   directory in the file  cerfnet-accept-use-policy.txt.

A copy of a number of acceptable use policies can currently be
had from ftp.math.lsa.umich.edu:/pub/emv/acceptable-use/* .
I'm collecting more as I find them.  They are labelled according
to the site they were ftp'd from, in order to make it easier to
track down the original source.

Currently the collection looks like:

stag /s/ftp/pub/emv/acceptable-use % ls
cren            nic.cerf.net    nic.near.net    um.cc.umich.edu
farnet          nic.mr.net      nis.nsf.net

I'm sure there are more out there.

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
comp.archives moderator
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 09:02:00 CST
From:      "22950::NMS" <nms%22950.decnet@mdc.com>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   tcp over hyperchannel
 Does anyone have any experience using tcp over hyperchannel, in particular
 from IBM to non IBM computers?

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 03:29:36 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!srcsip!knowledge!pclark@tut.cis.ohio-state.edu  (Peter Clark)
To:        tcp-ip@nic.ddn.mil
Subject:   Beginner's info TCP & UDP
Quick question:
	Under what conditions would a programmer want to use a UDP connection
	over a TCP connection? What does UDP give you that TCP doesn't, that
	makes it worth losing (or implementing yourself) a reliable,
	guaranteed delivery layer?

	Pete Clark
	Honeywell SRC
	Minneapolis MN
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Jul 90 8:47:07 CDT
From:      darrel beach <beach@ddnuvax.af.mil>
To:        tcp-ip@nic.ddn.mil
Cc:        beach@ddnuvax.af.mil
Subject:   GOSIP and X.25

Thanks to everyone who responded to my last inquiry on GOSIP.  I'm
still not very knowledgeable about the OSI suite.  I have a couple more
simple (I hope) questions.  

   The first one has to do with X.25.  Is it possible or practical to
run both TCP/IP and the GOSIP suite over a single X.25 interface into a
network?? and ditto for ethernets??  I suppose ether is easy relative
to X.25.  I'm most familiar with the milnet (standard) brand of TCP/IP
over X.25, where CC is the first byte of call user data in call request
packets, and where datagrams are sent as complete packet sequences,
etc.  It would seem that in order to support BOTH suites over a single
X.25 interface, then it would be necessary ti parse which protocol is
being used, IP or ISO8473, after the PDU is received.  That doesn't
seem too practical.  Would a host now have to maintain a virtual
circuit table that includes info on what kinds of PDUs can be sent on
that vc (IP or 8473).  This assumes the X.121 addresses for a
dual protocol hosts is the same regardless of which suite is being
called.

In the case of Milnet, does anybody know how to address OSI suite
hosts?  Right now it looks like I just build a table of X.121
addresses.  Will there ever be an algorithmic derivation to get the
X.121 addresses??  Seems to be a knotty little topic, but maybe its
easier than it seems.

Darrel Beach
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 06:11:58 GMT
From:      snorkelwacker!ira.uka.de!fauern!tumuc!lan!charly.bl.physik.tu-muenchen.de!k2@tut.cis.ohio-state.edu  (Klaus Steinberger)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Why does a wrong broadcast address cause arp-havoc?
roy@alanine.phri.nyu.edu (Roy Smith) writes:


>	By watching with tcpdump, I can see that when an occassional IP
>object gets configured with the wrong broadcast address, each time it sends
>a broadcast packet, a flurry of arp requests are generated by various
>machines on the network.  I sort of understand what is going on, but not
>exactly.  We use a hostpart of .0.0 for broadcasts, but once in a while a
>misconfigured box pops up with .255.255, which other machines then try to
>arp for.
At first: Not the .255.255 boxes are misconfigured, all of youre other
	stuff is misconfigured. The official broadcast address is a
	host-part of all ones! There was an bug in Berkeley 4.2 networking
	code, which led to those all zero addresses!

>	What I don't understand is 1) why they bother to arp at all and 2)
>why only some machines do it?  As I understand it, when a machine wants to
>send an IP packet, it has to arp to find out what link-level address to put
>in the ethernet dst field.  But why should a machine try to do an IP->ether
>address resolution just because it receives an rwho packet sent to the
>wrong IP broadcast address?  An rwho requires no response, so there really
It's because IP-forwarding is normally enabled in the kernel. And some
machines think, if they are configured to all zeros broadcast, and they
see a all ones broadcast, that they must forward it. So they try to arp'
the address.

>isn't any reason to need to know where it came from.  As for the second
>question, what is it about some machines that makes them arp for bad
>broadcasts and others not?  In our particular case, we have a bunch of
>Sun-3's, all running SunOS-3.5.2.  One of them runs a generic kernel, and
>that's the only one that arps in response to .255.255 packets.  All our
>other Suns run customized kernels, but the only customizations are to
>delete device drivers they don't need; nothing (that I know of) has been
>changed in the networking code, yet they don't arp .255.255's.  Why not?
Maybe, you have disabled IP-forwarding in the customized kernels.

I think you should have a close look to all your equipment, if it's
able to use the .255.255 broadcast, and then you should switch to it.
It's hard to do, because you have to change all configurations in one shot,
but you will not run into trouble, if new machines are installed.
Most networking software is derived from Bsd 4.3, so the broadcast
will be configurable, but all defaults to .255.255. 

Sincerely,
Klaus Steinberger

Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende, D-8046 Garching, West Germany
BITNET:  K2@DGABLG5P            Internet: k2@charly.bl.physik.tu-muenchen.de
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 07:12:10 GMT
From:      eru!luth!sunic!liuida!prodix!martin@bloom-beacon.mit.edu  (Martin Wendel)
To:        tcp-ip@nic.ddn.mil
Subject:   Mailbox servers

I am interested in setting up mailbox servers on UNIX 
workstations/servers. I have looked at IMAP2 and it 
seems quite capable. However, after reading the docs 
on IMAP2 I learned that every mailbox must be connected 
to a defined user on one of the mailbox servers. I regard 
this as a security threat. It seems that IMAP2 was built 
to work on small sites consisting mainly of workstations 
and not on larger sites with servers, workstations and 
lots of small computers.

Is there anyone out there who has experience of mailbox
servers in large sites (I am talking ten or more subnets
and tenthousand mailboxes).

Thanks in advance

Martin.Wendel@UDAC.UU.SE
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Jul 90 13:02:14 EDT
From:      Caleb Strockbine <QOP%CORNELLA.BITNET@ricevm1.rice.edu>
To:        TCP-IP%NIC.DDN.MIL@ricevm1.rice.edu
Subject:   Re: How to get RFC documents dealing with TCP-IP
>I am sorta new to all of this. Can anyone give me a pointer to on-line
>copies of the RFC (Request For Comments) documents. I am especially
>interested in the ones that describe BOOTP and IP/UDP.

You can get RFCs by anonymous FTP from nic.mil.ddn (formerly sri-nic.arpa).
CD to the RFC: (the colon is necessary) directory. Then get all the RFCs
your heart desires. There's an index file that's pretty useful, especially
since you can use grep to find pretty much anything (assuming you're a
Unix type).

Good luck.

Caleb Strockbine
qop@cornella.cit.cornell.edu
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Jul 90 17:04:21 -0400
From:      Andy Malis <malis@BBN.COM>
To:        darrel beach <beach@ddnuvax.af.mil>
Cc:        tcp-ip@nic.ddn.mil, malis@BBN.COM
Subject:   Re: GOSIP and X.25
Darrel,

> Thanks to everyone who responded to my last inquiry on GOSIP.  I'm
> still not very knowledgeable about the OSI suite.  I have a couple more
> simple (I hope) questions.

I think I can help.

> The first one has to do with X.25.  Is it possible or practical to
> run both TCP/IP and the GOSIP suite over a single X.25 interface into a
> network?? and ditto for ethernets??  I suppose ether is easy relative
> to X.25.  

X.25 is actually easy, at least on the DDN.  I can't speak for ether.

> I'm most familiar with the milnet (standard) brand of TCP/IP
> over X.25, where CC is the first byte of call user data in call request
> packets, and where datagrams are sent as complete packet sequences,
> etc.  It would seem that in order to support BOTH suites over a single
> X.25 interface, then it would be necessary to parse which protocol is
> being used, IP or ISO8473, after the PDU is received.  That doesn't
> seem too practical.  

You're right, that's not the best way to do it.  If you check RFC
1060, p. 48 (X.25 type numbers), you'll see that ISO IP has its
own protocol ID (first byte of CUD in Call Request packets), CD.
So, to use ISO-IP, you just open an X.25 VC to another consenting
host using the ISO IP protocol ID.  You can even run IP and
ISO-IP in parallel between two hosts, over separate VCs of
course.  I have the impression that on the Milnet, ISO-IP usually
runs over Basic X.25, rather than Standard X.25, since there is
no need to interoperate with AHIP (1822) hosts, but either should
work as long as the two hosts agree.

> Would a host now have to maintain a virtual
> circuit table that includes info on what kinds of PDUs can be sent on
> that vc (IP or 8473).  This assumes the X.121 addresses for a
> dual protocol hosts is the same regardless of which suite is being
> called.

Yes, you should keep a VC table that lists the X.121 address on
the other end of the VC, and the protocol being used on the VC.
But you really have to do that anyway.  

Yes, on the DDN (Milnet), at least, the X.121 address is
independent of the protocol, since the PSNs don't care what
protocol you're running above X.25; they just need the address to
get the data to the right place.  The physical address is the
same.

> In the case of Milnet, does anybody know how to address OSI suite
> hosts?  Right now it looks like I just build a table of X.121
> addresses.  Will there ever be an algorithmic derivation to get the
> X.121 addresses??  Seems to be a knotty little topic, but maybe its
> easier than it seems.

If I understand your question correctly, I think the answer lies
in RFC 1069, which defines ISO-IP addresses for use in the
Internet.  Figure 3, on p. 7, shows the regular IP address
residing in octets 16-19 of the ISO-IP address.  Once you have
the regular IP address, you can use the regular algorithmic
derivation to get the Milnet X.121 address.

Andy Malis
BBN Communications
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 16:59:59 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: parallel networks problem
In article <7050@star.cs.vu.nl>, sater@cs.vu.nl (Staveren van Hans) writes:
> Recently I posted a question to these groups to which, to my surprise,
> I received no reactions at all. This seems strange since it addresses a
> problem that many of us are going to face. Now there is of course the
> possibility that this is so obvious that you were all embarrassed by
> the question, but I doubt it.
> 
> Suppose part of a network looks like this
> 
>   ---------------------------------------------------------  network A
> 		|			|		|
> 	-----------------	-----------------   ----------
> 	|      A.1      |	|      A.2	|   |  A.3   |
> 	|    Host foo	|	|    Host bar	|   |Host zot|
> 	|      B.6	|	|      B.7      |   |        |
> 	-----------------	-----------------   ----------
> 		|			|
>   --------------------------------------------------------- network B
> 
> so two parallel networks with some multihomed and some singlehomed hosts.
> Further suppose that network B is preferable to network A, because of
> load, politics or because it is 10x as fast (hint: FDDI vs Ethernet).
> How would one set up addressing and routing for such a configuration?
> 

	What is the Internet Protocol supposed to do?  In the TCP/IP
frame of reference, IP was designed to route internet datagrams from
source address to destination address.  IP understands interfaces.

	But applications understand hosts/servers/service-entities.
How does one tie an "entity" to a "set of addresses" as one moves
down the protocol stack?  How does one deal with so-called multi-homed
hosts?  The answer is, IP does not deal with the issue.  Should it?
Good philosophical question... and can of worms.

	Let us assume that IP should not deal with entities, only
interfaces (addresses).  Can the applications (or some other level
in the stack) deal with the translation of entity name to "ordered
set of addresses"?  I think they can.

	I would suggest that the place to attack this problem is in
the resolver.  I recall discussions in times past about whether the
name servers should be able to do this based on source address, but
it seemed to me at that time that that was impossible for the name
servers to do, since the source entity could be multi-homed.

	The resolver will need to be able to get some kind of
routing or preference metric from the network layer.  Many options.

	I would also suggest that there are many places in the
protocol stack where a domain name would work better than an ip-
address.  Of course, machines may have many names, but at least
we have the concept of canonical name.  We also have the concept
of multicast (implying groups of servers that are in some sense
equivalent).  So we are torn in search of the correct paradigm
and are tied to others' past decisions in the history of TCP/IP.
More grist for the philosophers...

	--Kent
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 17:02:14 GMT
From:      QOP@CORNELLA.BITNET (Caleb Strockbine)
To:        comp.protocols.tcp-ip
Subject:   Re: How to get RFC documents dealing with TCP-IP

>I am sorta new to all of this. Can anyone give me a pointer to on-line
>copies of the RFC (Request For Comments) documents. I am especially
>interested in the ones that describe BOOTP and IP/UDP.

You can get RFCs by anonymous FTP from nic.mil.ddn (formerly sri-nic.arpa).
CD to the RFC: (the colon is necessary) directory. Then get all the RFCs
your heart desires. There's an index file that's pretty useful, especially
since you can use grep to find pretty much anything (assuming you're a
Unix type).

Good luck.

Caleb Strockbine
qop@cornella.cit.cornell.edu

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Tue 17 Jul 90 01:57:15-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        mcrae@mk6vms.nwscc.sea06.navy.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: WIN/TCP Window Size
Mumble.  Someone has to ask... Just WHY do you want to change the window
size (and which one).  The window sizes offered by (and to) a system can
be carefully thought out by the implementors, and can have serious non-linear
effects on performance, thoughput, and even reliability of they are changed
very much.  There are better ways to solve most problems than changing the
window sizes...

BillW
-------
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 19:17:11 GMT
From:      pollux!ccruss@ucdavis.ucdavis.edu  (Russ Hobby)
To:        tcp-ip@nic.ddn.mil
Subject:   Network FAX Working Group
Due to the interest in being able to transmit FAX over TCP/IP networks,
the Internet Engineering Task Force has formed a new Working Group to
evaluate the needs and to come up with methods and protocols to accomplish
this task.

The WG charter has been included below and includes information on how
to be added to the WG maillist.  For more information contact the WG Chair.

Russ Hobby                              INTERNET: rdhobby@ucdavis.edu  
IETF Area Director - Applications       BITNET:   RDHOBBY@UCDAVIS  
                                        UUCP:  ...!ucbvax!ucdavis!rdhobby 
-----------------------------------------------------------
Network Fax Working Group

 Chairman:

         Mark H Needleman/University of California-DLA
         (mhn@stubbs.ucop.edu)

 Mailing Lists:

        General Discussion:  netfax@stubbs.ucop.edu
        To Subscribe:        netfax-request@stubbs.ucop.edu

 Anonymous FTP:

      /pub/netfax@stubbs.ucop.edu

 Description of the Working Group:

      The Network Fax Working group is chartered to  explore
 issues  involved  with  the  transmission  and  receipt  of
 facsimile across TCP/IP networks and to develop recommended
 standards  for  facsimile transmission across the Internet.
 The group is also intended to serve as a coordinating forum
 for people doing experimentation in this area to attempt to
 maximise the possibity for interoperability  among  network
 fax projects.

      Among the issues that need to  be  resolved  are  what
 actual  protocol or protocols will be used to do the actual
 data transmission between hosts, architectural  models  for
 the integration of fax machines into the existing internet,
 what  types  of  data  encoding should be supported, how IP
 host address to phone number conversion should be done  and
 associated issues of routing, and develeopment of a gateway
 system  that  will  allow  existing Group 3 and Group 4 fax
 machines to operate in a network enviornment.

      It is expected that the output of  the  working  group
 will be one or more RFC's documenting recommended solutions
 to  the  above  questions and possibly also describing some
 actual implementations.  The life of the working  group  is
 expected to be 18-24 months.

      It is also hoped th at some fax vendors,  as  well  as
 the  networking  community and fax gateway developers, will
 be brought into the effort.


 Goals and Milestones:

 1). August 1990:  First IETF Meeting:  review  and  approve
     charter  making  any  changes deemed necessary.  Refine
     definition of scope of  work  to  be  accomplished  and
     intial  set of RFC's to be developed.  Begin working on
     framework for solution.

 2). August - March 1991:  Continue work  on  definition  of
     issues  and protocols.  Work to be conducted on mailing
     list.

 3) March  -  August  1991:   First  draft  of  RFC  to   be
     completed.  To be discussed at IETF meeting and revised
     as necessary.  Make document and Internet draft.

 4) August - December 1991:   Continue  revisions  based  on
     comments   received   and   if  ok  give  to  IESG  for
     publication as RFC.

 5) January  -  March  1992:   Overlapping  with  activities
     listed above may be implementations based on ideas  and
     work  done  by  the working group.  If so revise RFC to
     include knowledge gained from such implementations.
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 20:32:22 GMT
From:      wotk!root@uunet.uu.net  (Superuser)
To:        tcp-ip@nic.ddn.mil
Subject:   UDP checksums
Does anyone know how to enable UDP checksums on a Sun 360.

Thanks.

Nick Hennenfent
Computone Products
1100 Northmeadow Parkway
Suite 150
Roswell, GA 30076

Voice 404 475-2725    FAX 404 343-9735    email ...!uunet!wotk!{root,nickh}
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 21:04:21 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: GOSIP and X.25

Darrel,

> Thanks to everyone who responded to my last inquiry on GOSIP.  I'm
> still not very knowledgeable about the OSI suite.  I have a couple more
> simple (I hope) questions.

I think I can help.

> The first one has to do with X.25.  Is it possible or practical to
> run both TCP/IP and the GOSIP suite over a single X.25 interface into a
> network?? and ditto for ethernets??  I suppose ether is easy relative
> to X.25.  

X.25 is actually easy, at least on the DDN.  I can't speak for ether.

> I'm most familiar with the milnet (standard) brand of TCP/IP
> over X.25, where CC is the first byte of call user data in call request
> packets, and where datagrams are sent as complete packet sequences,
> etc.  It would seem that in order to support BOTH suites over a single
> X.25 interface, then it would be necessary to parse which protocol is
> being used, IP or ISO8473, after the PDU is received.  That doesn't
> seem too practical.  

You're right, that's not the best way to do it.  If you check RFC
1060, p. 48 (X.25 type numbers), you'll see that ISO IP has its
own protocol ID (first byte of CUD in Call Request packets), CD.
So, to use ISO-IP, you just open an X.25 VC to another consenting
host using the ISO IP protocol ID.  You can even run IP and
ISO-IP in parallel between two hosts, over separate VCs of
course.  I have the impression that on the Milnet, ISO-IP usually
runs over Basic X.25, rather than Standard X.25, since there is
no need to interoperate with AHIP (1822) hosts, but either should
work as long as the two hosts agree.

> Would a host now have to maintain a virtual
> circuit table that includes info on what kinds of PDUs can be sent on
> that vc (IP or 8473).  This assumes the X.121 addresses for a
> dual protocol hosts is the same regardless of which suite is being
> called.

Yes, you should keep a VC table that lists the X.121 address on
the other end of the VC, and the protocol being used on the VC.
But you really have to do that anyway.  

Yes, on the DDN (Milnet), at least, the X.121 address is
independent of the protocol, since the PSNs don't care what
protocol you're running above X.25; they just need the address to
get the data to the right place.  The physical address is the
same.

> In the case of Milnet, does anybody know how to address OSI suite
> hosts?  Right now it looks like I just build a table of X.121
> addresses.  Will there ever be an algorithmic derivation to get the
> X.121 addresses??  Seems to be a knotty little topic, but maybe its
> easier than it seems.

If I understand your question correctly, I think the answer lies
in RFC 1069, which defines ISO-IP addresses for use in the
Internet.  Figure 3, on p. 7, shows the regular IP address
residing in octets 16-19 of the ISO-IP address.  Once you have
the regular IP address, you can use the regular algorithmic
derivation to get the Milnet X.121 address.

Andy Malis
BBN Communications

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 21:33:26 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ark1!nems!dtoa1!lumsdon@tut.cis.ohio-state.edu  (Lumsdon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Wollongong TCP/IP ping question, VMS
In article <1990Jul10.172440.15458@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
>In article <2521@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil
>   (Esther Lumsdon) writes:
>> [PING requires SYSPRV]
>>Is it safe to install PING with SYSPRV privilege?

[....]

>The reason PING requires privilege, is that it connects to a "raw"
>socket; i.e. it interfaces at a level of the network package where you
>can send *anything you like*. To prevent user programs from forging
>authentic looking datagrams that pretend to be from somewhere else, the
>network kernel has been made to insist that only privileged programs do
>these things.

Thank you for pointing this out.

Thanks for all responses. It has become a moot point. NCSA's tcp/ip
for MS-DOS requires (inexplicably) that the VAX PING the PC in order
to get communications to work after both machines have rebooted. We
are now using FTP Software's tcp/ip for MS-DOS, which has not exhibited
this strange behavior.

--------------------------  Esther Lumsdon  --------------------------------
lumsdon@dtoa1.dt.navy.mil  lumsdon@dtrc.dt.navy.mil
lumsdon%dtrc.navy.mil@uunet.uu.net
"Wherever you go, there you are" -Buckaroo Bonzai
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 90 23:44:52 GMT
From:      comp.vuw.ac.nz!newbery@uunet.uu.net  (Michael Newbery)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <269E07C3.604D@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:
>In all of the cellular systems I've used so far, roaming is only half
>automatic.  In particular, to place a call to a roamer, you have to dial
>the roamer access number for the area where they are, and then dial their
Not in New Zealand. Cell phones have their own area code which covers the
country. All cell calls cost the same per minute regardless of distance
(which is cheaper than the most expensive 'normal' toll step.)
As part of testing they placed a call, got in a plane and flew the length
of the country, keeping the circuit up during the entire journey.
(OK, so NZ is small, but it is bigger in area than the U.K. which does
require area access numbers).

--
Michael Newbery<newbery@rata.vuw.ac.nz>
Q: What do you do with a wombat?
A: Play wom with it!
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 00:32:42 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!mips!ultra!beau@ucsd.edu  (Beau James {Manager - SW Development - Ultra Networks})
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP checksums
In <5@wotk.UUCP> root@wotk.UUCP (Superuser) writes:

>Does anyone know how to enable UDP checksums on a Sun 360.

	# adb -k /vmunix /dev/mem
	...
	udp_cksum/W 1		; Enables UDP checksums on the running kernel
	udp_cksum?W 1		; Enables whenever this kernel is booted

UDP checksums must be enabled on both sending and receiving
machines before the software will compute and verify the
checksum.

Beau James				beau@Ultra.COM
Ultra Network Technologies		{sun,ames}!ultra.com!beau
-- 

Beau James				beau@Ultra.COM
Ultra Network Technologies		{sun,ames}!ultra.com!beau
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 01:02:34 GMT
From:      agate!shelby!portia.stanford.edu!jessica.stanford.edu!morgan@ucbvax.Berkeley.EDU  (RL "Bob" Morgan)
To:        tcp-ip@nic.ddn.mil
Subject:   Zero manufacturer code in SNAP?

Here's a question about SNAP that might be answered if I could ever
actually see the spec for it.  Then again, maybe not.

The 40-bit SNAP extension to IEEE 802.2 specifies a 24-bit
"organizationally unique identifier" that is apparently supposed to be
the same 24 bits that a manufacturer uses to form the upper part of a
48-bit unique IEEE 802 MAC address.  The other 16 bits are assigned by
the organization in any way it sees fit.

Now, IP on 802.2, as specified in RFC 1042, uses 24 bits of zeros to
fill this field.  The remaining 16 bits are filled with the same 16
bits used for the Ethernet type field (for IP and ARP frames).

The question is, has the all-zeros SNAP id been assigned by IEEE to
DoD, or the IAB, or some IP authority, to be administered by that
authority?  Or is the all-zeros id just a general purpose format for
translating Ethernet frames to 802.2/SNAP, to be used by anyone?
Those of you familiar with AppleTalk Phase II may get a glimmer of why
I'm asking.

Thanks,

 - RL "Bob" Morgan
   Networking Systems
   Stanford
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 01:14:17 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Beginner's info TCP & UDP
People tend to use UDP where (1) they plan to be making isolated
queries, such that the overhead packets used to set up and close a
connection would form most of the traffic (2) they need more
performance than they think they can get from TCP.  The domain system
is an example of the first category.  You send a one-packet query and
get back a one-packet response.  If you don't get a response, just try
again.  NFS is an example of the second category.  The folks at Sun
apparently believed that they couldn't get good enough performance out
of TCP to use it for swapping.  In most cases I recommend using TCP.
If you use UDP, you end up having to build retransmission algorithms
into your application.  In most cases you'll get better performance by
using TCP, whose algorithms have been well tuned (at least if you are
using a recent Berkeley TCP), rather than rolling your own.
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 01:14:40 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mailbox servers
In article <161@prodix.liu.se> martin@prodix.liu.se (Martin Wendel) writes:
>I am interested in setting up mailbox servers on UNIX 
>workstations/servers. I have looked at IMAP2 and it 
>seems quite capable. However, after reading the docs 
>on IMAP2 I learned that every mailbox must be connected 
>to a defined user on one of the mailbox servers. I regard 
>this as a security threat. It seems that IMAP2 was built 
>to work on small sites consisting mainly of workstations 
>and not on larger sites with servers, workstations and 
>lots of small computers.
>
>Is there anyone out there who has experience of mailbox
>servers in large sites (I am talking ten or more subnets
>and tenthousand mailboxes).

There is nothing in IMAP2 per se that requires that "every mailbox
must be connected to a defined user on one of the mailbox servers."

It is true that the current Unix IMAP2 server (and the DEC-20 one)
implement access authentication as defined users on the server.  If
by "security threat" you are worried about these credentials flowing
on the network, the way you address this is Kerberos.  There's no
reason why Kerberizing IMAPware should be any more difficult than
Kerberizing FTP (a solved problem).

If by "security threat" you are worried about people with mailboxes
being able to log in on the server as a timesharing user, there is
already a perfectly good mechanism to prevent this in Unix.

In any case, since the IMAP2 sources are available, there is no reason
why you cannot implement your own authentication mechanism.  Nothing
in the protocol forces defined users; there are merely two
authentication tokens commonly referred to as "user" and "password".

Please contact me if you have any specific questions.  IMAP2 was
specifically designed to scale in the way you suggest.  It certainly
scales for larger sites better than more traditional protocols.  I use
IMAP2 on 8 different servers, including a server in a foreign country.

 _____   | ____ ___|___   /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105
 _|_|_  -|- ||   __|__   /  / 6158 Lariat Loop NE   "Gaijin! Gaijin!"
|_|_|_|  |\-++-  |===|  /  /  Bainbridge Island, WA "Gaijin ha doko ka?"
 --|--  /| ||||  |___|    /\  USA 98110-2098        "Niichan ha gaijin."
  /|\    | |/\| _______  /  \ "Chigau. Gaijin ja nai. Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 03:04:22 GMT
From:      nic.cerf.net!pushp@ucsd.edu  (Pushpendra Mohta)
To:        tcp-ip@nic.ddn.mil
Subject:   DIAL n CERF (Was Re: Still Looking: Access to Internet)
> 
> In article <68@nic.cerf.net> of comp.dcom.modems I, pushp@nic.cerf.net (Pushpendra Mohta) wrote:
> >If you wish to consider dial up access for internet connectivity
> >I believe CERFNet can provide all of what you want at sites
> >at UCLA, CALTECH, UCI , San Diego and Oakland.
> >
> >
> >--pushpendra
> >CERFNet

In article <1990Jul14.154305.14154@uu.psi.com>of comp.dcom.modems ,
schoff@uu.psi.com (Martin Schoffstall) writes:
> Pushpendra:
> Could you describe the permission procedure that CERFNET goes through
> to provide Internet access to individuals?
> Could you describe contract requirements
> (if any) for those individuals, especially in the area of NSFNet limitations,
> etc...  Could you describe the costs?
> Just Curious.
> Marty
> ---------------



CERFNet has an approval procedure consistent with it's
Acceptable Use Policy (AUP) . This policy is the same as the 
NSFNet AUP. 

All applications are reviewed by the Chairperson
or his/her designees on a case-by-case. All accepted
applicants are bound by the contract to abide by the 
AUP.

Quotes and Negotiations are unique to each individual/organization
All interested in the dial up offering : DIAL n' CERF 
should contact CERFNet at help@cerf.net or at (619) 534-5087 

A complete description of costs and requirements will soon appear
in comp.newprod .

Mean while those curious may obtain a copy of the
DIAL n' CERF user agreement (contract) by anonymous ftp from 

nic.cerf.net:cerfnet/cerfnet_info/dial-n-cerf-agreement.txt.

This document includes a copy of the CERFNet AUP.

--pushpendra
CERFNet
(619) 534-5056
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Jul 90 10:05:26 PDT
From:      postel@venera.isi.edu
To:        brunner@eagle1.enet.dec.com, shlump.nac.dec.com!eagle1.enet.dec.com!brunner@decuac.dec.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  How to get RFC documents dealing with TCP-IP

Hi.

RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC).  Login
with FTP, username ANONYMOUS and password GUEST.

The NIC also provides an automatic mail service for those sites
which cannot use FTP.  Address the request to SERVICE@NIC.DDN.MIL
and in the subject field of the message indicate the RFC number,
as in "Subject: RFC nnnn".

RFCs can also be obtained via FTP from NIS.NSF.NET.  Using FTP, login
with username ANONYMOUS and password GUEST; then connect to the RFC
directory ("cd RFC").  The file name is of the form RFCnnnn.TXT-1
(where "nnnn" refers to the number of the RFC).

The NIS also provides an automatic mail service for those sites which
cannot use FTP.  Address the request to NIS-INFO@NIS.NSF.NET and leave
the subject field of the message blank. The first line of the text of
the message mist be "SEND RFCnnnn.TXT-1", where nnnn is replaced by
the RFC number.

--jon.
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Jul 90 10:07:31 pdt
From:      Walter Underwood <wunder@hp-ses.sde.hp.com>
To:        tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip
Subject:   Re: Beginner's info TCP & UDP
Hedrick's and Warnock's explanations are interesting, but I sent Pete
a rather different explanation for UDP's existance.  UDP is for
protocols that don't want or need byte streams.  It is for protocols
that need pure datagrams, often for request/response, and it is for
building custom protocols, like NTP.  TIME and DAYTIME are the classic
request/response examples -- if the reply is lost, TCP would
retransmit the old timestamp after a timeout, but with UDP, the
requestor times out, asks again, and gets a new timestamp.

A transaction protocol that supports idempotent requests would satisfy
a lot of the current users of UDP, but it would not obsolete UDP.

wunder

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Jul 90 10:08:21 PDT
From:      jkrey@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Cc:        jkrey@venera.isi.edu, shlump.nac.dec.com!eagle1.enet.dec.com!brunner@decuac.dec.com
Subject:   re: How to get RFC documents dealing with TCP-IP
BOOTP (Bootstrap Protocol) RFCs 951,1048,1084
UDP  (User Datagram Protocol) RFC 768
IP (Internet Protocol) RFC 791

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

RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC).  Login
with FTP, username ANONYMOUS and password GUEST.  The NIC also
provides an automatic mail service for those sites which cannot use
FTP.  Address the request to SERVICE@NIC.DDN.MIL and in the subject
field of the message indicate the RFC number, as in "Subject: RFC
nnnn".

RFCs can also be obtained via FTP from NIS.NSF.NET.  Using FTP, login
with username ANONYMOUS and password GUEST; then connect to the RFC
directory ("cd RFC").  The file name is of the form RFCnnnn.TXT-1
(where "nnnn" refers to the number of the RFC).

The NIS also provides an automatic mail service for those sites which
cannot use FTP.  Address the request to NIS-INFO@NIS.NSF.NET and leave
the subject field of the message blank. The first line of the text of
the message mist be "SEND RFCnnnn.TXT-1", where nnnn is replaced by
the RFC number.

Joyce K. Reynolds
USC/Information Sciences Institute

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 03:22:48 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <269E07C3.604D@intercon.com> amanda@mermaid.intercon.com
(Amanda Walker) writes:
+---------------
| In article <153@tots.UUCP>, tep@tots.UUCP (Tom Perrine) writes:
| > I hate to admit it, but the cell-phone (phone system) model of
| > addressing does have many advantages for the *user*. No matter where
| > you go, your logical address (phone number) follows you.
| 
| In all of the cellular systems I've used so far, roaming is only half
| automatic.  In particular, to place a call to a roamer, you have to dial
| the roamer access number for the area where they are, and then dial their
| phone number.  This amounts to source routing, which is even more of a
| pain for mobile destinations than it is for "static" ones.  Bleah.
+---------------

In fact, most of the current cellular romaing systems are 3/4-automatic... ;-}
Automatic for the roamer dialing out; that's half. But now many (most?)
cellular companies offer a hack such that if you dial a person's cellular
number in their home area *and* they're currently known to be roaming
somewhere (they've placed a roming call within the last 24 hours), the
home area system will give you an intercept recording which tells you
they're out of area... *and* gives you the roamer access number where
they are. Sort of an ICMP Redirect...   ;-}    ;-}


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 03:41:27 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Beginner's info TCP & UDP
In answering a beginner's question, hedrick@athos.rutgers.edu
(Charles Hedrick) writes:
+---------------
| People tend to use UDP where (1) they plan to be making isolated
| queries, such that the overhead packets used to set up and close a
| connection would form most of the traffic (2) they need more
| performance than they think they can get from TCP....
+---------------

I would add:

...(3) there are a very large number of clients accessing a single
    server, such that the cost of holding a connection open for each
    active client would be excessive. [The definition of "excessive"
    is system- and application-dependent.]

In some sense this is the same as Hedrick's #1, except that #1 refers
to conserving dynamic network bandwidth, and #3 to conserving quasi-
static server system resources "wired-down" by connections (sockets,
open-file slots, processes, etc.).


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 04:44:17 GMT
From:      hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu  (Lars Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   ARP described, for newcomers
In article <2604@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil (Esther Lumsdon) writes:
>                                                  ... NCSA's tcp/ip
>for MS-DOS requires (inexplicably) that the VAX PING the PC in order
>to get communications to work after both machines have rebooted. ...

Sounds like an ARP problem. Probably a configuration error. (I have
never used NCSA telnet, nor do I have an MS-DOS machine).

In order for an IP datagram to travel from one system on an ethernet to
another, it must contain the receiver's ethernet address (a unique 6-byte
number).  The upper level protocols do not know ethernet addresses; when
the datagram makes it to the ehernet device driver, it looks in a
special table to see if the ethernet address for the receiver's IP
address has been discovered. If not, it THROWS AWAY the datagram, and
instead sends a broadcast that means "I'm looking for IP address 1.2.3.4"
and expects to get back a response that says "I'm 1.2.3.4 and my
ethernet address is aa:bb:cc:dd:ee:ff". This information is now used to
fill in the table. So when the higher level protocol (TCP) retransmits
the lost segment, the table has been filled in.

It is just barely possible that the NCSA program doesn't "do" ARPs, but
fills in the table from information in received IP datagrams, such as
the above mentioned PING.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 05:03:16 GMT
From:      grw@sun.com  (Gregory Whitehead)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <64290@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes:
>In article <269E07C3.604D@intercon.com> amanda@mermaid.intercon.com
>(Amanda Walker) writes:
>+---------------
>| In article <153@tots.UUCP>, tep@tots.UUCP (Tom Perrine) writes:
>| > I hate to admit it, but the cell-phone (phone system) model of
>| > addressing does have many advantages for the *user*. No matter where
>| > you go, your logical address (phone number) follows you.
>| 
>| In all of the cellular systems I've used so far, roaming is only half
>| automatic.  In particular, to place a call to a roamer, you have to dial
>| the roamer access number for the area where they are, and then dial their
>| phone number.  This amounts to source routing, which is even more of a
>| pain for mobile destinations than it is for "static" ones.  Bleah.
>+---------------
>
>In fact, most of the current cellular romaing systems are 3/4-automatic... ;-}
>Automatic for the roamer dialing out; that's half. But now many (most?)
>cellular companies offer a hack such that if you dial a person's cellular
>number in their home area *and* they're currently known to be roaming
>somewhere (they've placed a roming call within the last 24 hours), the
>home area system will give you an intercept recording which tells you
>they're out of area... *and* gives you the roamer access number where
>they are. Sort of an ICMP Redirect...   ;-}    ;-}

Actually, GTE offers "Follow Me" Roaming in many foreign areas now.
The roamer simply registers in the foreign area (by dialing *18) and
all calls are forwarded automagically. It's pretty neat, but it sure
can surprise your friends... ;-)

-Greg
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Jul 90 12:28:55 EDT
From:      perry@MCL.Unisys.COM (Dennis Perry)
To:        intercon!news@uunet.uu.net, tcp-ip@nic.ddn.mil
Cc:        perry@mcl.unisys.com
Subject:   Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)

	Date: 13 Jul 90 17:41:23 GMT
	From: intercon!news@uunet.uu.net  (Amanda Walker)
	Organization: InterCon Systems Corporation, Herndon, VA

	.
	.
	In all of the cellular systems I've used so far, roaming is only half
	automatic.  In particular, to place a call to a roamer, you have to 
	dial
	the roamer access number for the area where they are, and then dial 
	their
	phone number.  This amounts to source routing, which is even more of a
	pain for mobile destinations than it is for "static" ones.  Bleah.
	
	Maybe Motorola's proposed satellite-based cellular system will be 
	better.
	
	That's it!  We put the core gateways into geosynchronous orbit... :-)
	
	--
	Amanda Walker <amanda@intercon.com>
	Postmaster With An Attitude
	InterCon Systems Corporation
	
_________________

Actually, thought along this line exist, i.e. put the gateways in the 
satellite.  We thought of doing this at DARPA when I was there and we also
explored such issues with the Multiple Satellite Program, an upto 200 node
packet switched global communications network.  With the demise of MILSTAR
perhaps the light satellite concept will gain momentum.

dennis
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 10:21:55 GMT
From:      hsi!stevens@uunet.uu.net  (Richard Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP checksums
In article <1990Jul17.003242.1556@ultra.com> beau@ultra.com (Beau James writes:
>
>UDP checksums must be enabled on both sending and receiving
>machines before the software will compute and verify the
>checksum.

Newer systems should start conforming to the Host Requirements RFC (1122),
meaning the receiver has to honor a checksum that was set by the sender:

         4.1.3.4  UDP Checksums

            A host MUST implement the facility to generate and validate
            UDP checksums.  An application MAY optionally be able to
            control whether a UDP checksum will be generated, but it
            MUST default to checksumming on.

            If a UDP datagram is received with a checksum that is non-
            zero and invalid, UDP MUST silently discard the datagram.
            An application MAY optionally be able to control whether UDP
            datagrams without checksums should be discarded or passed to
            the application.

/Richard Stevens
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Jul 90 15:16:26 EDT
From:      lazear@gateway.mitre.org
To:        tcp-ip@nic.ddn.mil
Cc:        smcleod@mwunix.mitre.org
Subject:   IP Multicasting questions
In looking at IP multicasting (RFC 1112) and its potential use in a
project of ours, a couple of questions came to mind:

	Is there a "reference" implementation?  For SunOS or 4.3BSD?
	How can we obtain a copy?

	Is there any interest or work in progress to extend the registration
	protocol to allow 3rd party joins?  That is, to convey the IP
	address of a system to be added to a multicast address.  We are
	thinking of a coordinating system that would best know which slave
	systems should be in which groups and would register and deregister
	them appropriately.

Thanks in advance for any help.

	Walt Lazear
	MITRE Corp.
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 14:52:53 GMT
From:      hpcc01!hpcuhb!hpsqf!hpopd!ian@hplabs.hpl.hp.com  (Ian Watson)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP Port state FIN_WAIT_1 : what's that ?
I sometimes get a hang for a long while (say an hour) when I have a client
close a sockets connection.  The server (SCO Unix 3.2) shows the TCP port state
according to 'netstat -i' as being FIN_WAIT_1 before the connection eventually
dies completely.  The server program has gone away at the time the connection
close was requested by the client, so I guess it's just at the TCP level that
the connection is almost closed but not quite.

Anyone any ideas ?

Ian Watson
ian@hpopd.HP.COM     hplabs!hpopd!ian
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 16:22:37 GMT
From:      obrien@aeroaero.org (Michael O'Brien)
To:        comp.protocols.tcp-ip
Subject:   Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)


In article <139016@sun.Eng.Sun.COM>, grw@cabernet.Eng.Sun.COM (Gregory
Whitehead) writes:
|> In article <64290@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes:
|> >In article <269E07C3.604D@intercon.com> amanda@mermaid.intercon.com
|> >(Amanda Walker) writes:
|> >+---------------
|> >| In article <153@tots.UUCP>, tep@tots.UUCP (Tom Perrine) writes:
|> >| > I hate to admit it, but the cell-phone (phone system) model of
|> >| > addressing does have many advantages for the *user*. No matter where
|> >| > you go, your logical address (phone number) follows you.
|> >Automatic for the roamer dialing out; that's half. But now many (most?)
|> >cellular companies offer a hack such that if you dial a person's cellular
|> >number in their home area *and* they're currently known to be roaming
|> >somewhere (they've placed a roming call within the last 24 hours), the
|> >home area system will give you an intercept recording which tells you
|> >they're out of area... *and* gives you the roamer access number where
|> >they are. Sort of an ICMP Redirect...   ;-}    ;-}
|> 
|> Actually, GTE offers "Follow Me" Roaming in many foreign areas now.
|> The roamer simply registers in the foreign area (by dialing *18) and
|> all calls are forwarded automagically.

The non-wireline services in California have recently banded together to
permit this in an even easier fashion, as I recall.  As best I can figure
out, they must all send any roamers who've acquired the system in to a
central clearinghouse all the time; anyone who calls your number back
in your home area gets forwarded to you ALL THE TIME, unless you
SPECFICALLY send a code that turns the service OFF.  The manual warns
that you'd better cancel this (or it self-cancels at midnight) when you
return home or you won't get any calls THERE, either.

Now THAT'S an ICMP redirect.
--
Mike O'Brien
obrien@aerospace.aero.org

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 16:39:49 GMT
From:      davel@vision.UUCP (Dave Lockwood)
To:        comp.protocols.tcp-ip
Subject:   Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)

In article <1990Jul16.234452.29721@comp.vuw.ac.nz> newbery@rata.vuw.ac.nz (Michael Newbery) writes:
>Not in New Zealand. Cell phones have their own area code which covers the
>country. All cell calls cost the same per minute regardless of distance
>(which is cheaper than the most expensive 'normal' toll step.)
>As part of testing they placed a call, got in a plane and flew the length
>of the country, keeping the circuit up during the entire journey.
>(OK, so NZ is small, but it is bigger in area than the U.K. which does
>require area access numbers).

Sorry, the UK does _NOT_ require area access numbers on celluar! As far as
I know there are three "area" codes - 0860 (which is for phones on the Cellnet
network) and 0836/0831 which are for phones on the Vodafone network. I have
one of the latter, and can be called anywhere in the UK (where there is
service) by dialling the _same_ code+number. This "network" code is often
confused as an "area" code...it isn't.

-- 
-------------------- I'm totally incommunicado, except for ---------------------
Dave Lockwood            ...!uunet!mcsun!ukc!vision!davel      davel@vision.uucp
Technical Consultant    ...!uunet!bulus3!bungia!vware!davel   davel@vware.MN.ORG
VisionWare Ltd,               G4CLI@GB7YHF.194.GBR.EU        dave@g4cli.ampr.org
57 Cardigan Lane,                  D.LOCKWOOD@ICLX            davel@vision.co.uk
Leeds, LS4 2LE,                     +44-532-788858                +44-831-494088
United Kingdom                      +44-532-304676                   "Hey, You!"
----------------------- VISIONWARE DOS/UNIX INTEGRATION ------------------------

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 16:55:40 GMT
From:      manoj@xlnvax.novell.com (manoj @ Prod Mktg)
To:        news.groups,comp.os.os2,comp.protocols.tcp-ip,news.announce.newgroups,comp.protocols.iso,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.dcom.lans,comp.protocols.ibm,comp.protocols.pcnet
Subject:   SECOND CALL FOR VOTES comp.sys.novell

[This group did not follow creation guidelines because there was no
 call for discussion for comp.sys.novell in news.announce.newgroups.
 There also currently exists a trial newsgroup named
 trial.comp.sys.novell.-eliot]
 


*** PLEASE READ THIS ENTIRE MESSAGE BEFORE REPLYING ***

This is the second call for votes for creation of a new group 
	comp.sys.novell

This group will be self-moderated.  This basically means that flamers and
obnixious people will be ignored by the rest of us.  

The voting period will last until 11:59 PM on Aug 10, 1990.

Charter for comp.sys.novell
---------------------------
	A forum to discuss technical and non-technical issues specific to 
the Novell's Netware family of Local Area and Wide Area Networking products.  
These include ELS NetWare, Netware286, Netware386, Portable Netware, 
Communication products, Database products, Development API's,
LAN WorkPlace family (TCP/IP) etc. etc. thus reducing the amount of time and 
multiple postings on multiple groups on protocols, lans, dcom, ibmpc, tcp-ip etc

Examples of topics to be discussed in this newsgroup include:

   "What are the networking cards, _____,  certified for NetWare 386"

   "What's wrong with this ___ code?, 
	
   "What toolkit calls, ______ are available?"

   "Has anyone managed to hook up a ___ successfully?"

   "What is the official, Novell-sanctioned method of doing ___?"

   "What are the specs for ___ file format?"

   "What applications are compatible on a _____ NetWare System?"

Examples of topics NOT to be discussed in this newsgroup include:

   "For sale: ___"

   "New product announcement: ___"

   "Novell's financial situation is ___"
-----------------------------------------------------------------------------

HOW TO VOTE
-----------

To cast a vote, send a mail message to manoj@novell.com with either of
the following subject lines:

TO VOTE YES:
   Subject: comp.sys.novell = YES 

TO VOTE NO:
   Subject: comp.sys.novell = NO
 
THE BODY OF THE MESSAGE WILL BE IGNORED.  Nothing placed in the body will
be used in counting votes.

No vote with an incorrect subject line will be counted!

ONLY votes MAILED to manoj@novell.com will count. Votes posted to the net
for any reason (including inability to get mail to manoj@novell.com) and 
proxy votes (such as having a mailing list maintainer claim a vote for 
each member of the list) will not be counted.

_______________________________________________________________________
	                                 		+---+
	manoj goel,                                  	| +-+-+
	Product Marketing              			+-+-+ |
        Excelan/Novell, San Jose, CA 		 	  +---+
	(408) 473-8369 (voice) / 433-0775 (fax)	/ manoj@novell.com
___________________________________________________________________________

>From manoj@excelan.COM Thu Dec 21 08:37:17 1989
Path: excelan!ames!ncar!announce-moderator
From: manoj@excelan.COM (manoj @ Prod Mktg)
Newsgroups: news.announce.newgroups,news.groups,comp.protocols.ibm,comp.protocols.nfs,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix,comp.dcom.lans,comp.os.os2,comp.protocols.tcp-ip.ibmpc,comp.unix.xenix
Subject: CALL FOR DISCUSSION ' comp.sys.netware'

			###################
                        CALL FOR DISCUSSION
		###################################
			comp.sys.netware
		###################################

Why add a new group? 

	A forum to discuss technical and non-technical issues specific to 
the Novell's Netware family of Local Area and Wide Area Networking products.  
These include Netware286, Netware386, Portable Netware, Communication products,
Database products, Excelan LAN WorkPlace family (TCP/IP) etc. etc.

	 The creation of this forum will allow the Novell Netware enthusiasts 
at USENET their own forum to discuss items of a non-technical nature 
(how to use software packages, what networking card to buy, etc) 
and items of a technical nature (what's wrong with this code?, how do I use 
this toolkit call?, etc.), thus reducing the amount of time spent sorting 
through multiple groups on protocols, lans, ibmpc, tcp-ip.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 17:07:28 GMT
From:      murthy@la.excelan.com (M.D. Srinivas Murthy)
To:        comp.protocols.tcp-ip
Subject:   Re: Beginner's info TCP & UDP


One important reason to use UDP is when broadcasting is needed. You cannot
send a broadcast packet with TCP. (One example: rwho)

Further if an application is designed as a state-less machine (like NFS)
one has to use UDP.

-murthy

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 17:17:19 GMT
From:      sgi!shinobu!odin!ajit@ucbvax.Berkeley.EDU  (Ajit Mayya)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: ARP described, for newcomers
In article <1990Jul17.044417.17807@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
>number).  The upper level protocols do not know ethernet addresses; when
>the datagram makes it to the ehernet device driver, it looks in a
>special table to see if the ethernet address for the receiver's IP
>address has been discovered. If not, it THROWS AWAY the datagram,
				      ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    No it doesn't. Atleast BSD based systems have a slot for hanging
    on to atleast one packet in the arp table entry. When the entry
    gets resolved, the packet is sent. Ofcourse, if it looks like there
    is going to be no incoming reply (after 3 retransmissions or whatever)
    the packet if freed up. Typically ARP resolution takes at most the
    order of milliseconds, and the packet is on its way without waiting
    for any retransmissions etc. 

    If two packets are sent to the same unresolved IP destintation,
    the first one will be queued. When the second one comes along, the
    first is dropped and the second is queued and so on and so forth.

    I haven't looked at the Host Requirements Document lately, but I
    think it requires implementations to hang on to atleast one packet.

-----------------------------------------------------------------------------
Ajit Mayya                  Silicon Graphics Inc., Advanced Systems Division
ajit@asd.sgi.com            Any opinions expressed above are mine, not SGI's
-----------------------------------------------------------------------------
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Jul 90 00:17:25 EDT
From:      Bruce Crabill <BRUCE@UMDD.UMD.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RFC1168
I'd hate to be the first to drag out the PostScript RFC soap box again, but
RFC1168 uses LaserWriter specific non-standard PostScript features (the
now infamous "letter" command).  I can't print it on our LPS40 printer.

                                       Bruce
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Jul 90 08:34:38 -0700
From:      mmeadows@qualcomm.com (Mike Meadows)
To:        tcp-ip@nic.ddn.mil
Subject:   POP3 Client for the PC.

I am looking for a client for the PC that uses the POP3 protocol.  I have
read about the existence of such programs, but I have been unable to 
locate one.  Any help would be greatly appreciated.

Michael Meadows
Qualcomm Inc.
mmeadows@qualcomm.com
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 90 22:18:45 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Beginner's info TCP & UDP

In article <Jul.16.21.14.16.1990.26321@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
>People tend to use UDP where (1) they plan to be making isolated
>queries... (2) they need more
>performance than they think they can get from TCP...

Doesn't it also get some use for things like packet voice, where timely
unreliable delivery is better than unpredictably-delayed reliable
delivery?

Agreed that the basic answer is "use TCP unless you have a very good
reason for UDP".  If nothing else, it's much easier to get a high-quality
implementation by using a pre-built one than by building it yourself.
-- 
NFS:  all the nice semantics of MSDOS, | Henry Spencer at U of Toronto Zoology
and its performance and security too.  |  henry@zoo.toronto.edu   utzoo!henry

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Tue, 17 Jul 90 23:38:24 GMT
From:      Mills@udel
To:        bellcore-2!envy!karn@bellcore.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Mobile TCP/IP (was Re: Can subnets be separated by another net?)
Phil,

MSS was to put up 240 satellites in 800-km orbits by flinging them from
the Shuttle at odd moments. They were to have steerable antennas and
operate at Etherspeeds. Assuming random (!) orbit inclinations, a ground
station would see about five satellites at a time and a satellite would
see about 35 other satellites at a time. The average crosslink between
the satellites would be about ten minutes.

For homework tonight, you get to design the crosslink acquisition and
routing algorithm. You also get to figure out how a new satellite not
knowing the orbit elements or ephemeris of the other satellites finds
its friends with a 5-degree beamwidth antenna.

There will be a test in the morning. Open book.

Oh, I forgot. The system is power-limited. The best routing may be achieved
with minimum-power routing, rather than minimum-distance. In other words,
take the usual linear metric (like hop count or delay) and square it. Then
construct the minimum path. Surprising things happen, like this can result
in the MAX number of hops, rather than the usual MIN.

I worked on the project for a short while, but have not seen the final report.
However, my simulations showed that the degree of connectivity quickly blows
away SPF algorithms and blows everything away with min-power routing.

Iridium is a rare metal probably ill used to build satellites with. You may
remember the ill-fated XTEN network that could be described as an Ethernet
radio operating at 10 GHz for metro-area coverage. Are we now seeing XTENs
in the sky?

Dave
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 00:38:52 GMT
From:      fanj@remb6489.wpd.sgi.com (Fan Jiao)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Info on Telnet 3270 needed


Does somebody know there are companies that ported Telnet 3270 into Apollo's,
DEC's, HP's, Sun's workstation, or MS-DOS machines?  If so I'd appreciate
any information on the product.

Thanks much in advance.
--
- Fan Jiao

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Jul 90 09:53:11 -0400
From:      barns@gateway.mitre.org
To:        dscott@gateway.mitre.org
Cc:        tcp-ip@nic.ddn.mil, barns@gateway.mitre.org
Subject:   Re: GOSIP and X.25

You probably saw Darrel B's message - What do you think of this set of
answers?  /Bill

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

Guess I'll take a shot at this set of questions.

     1. Is it possible or practical to run both TCP/IP and GOSIP protocols
     over a single X.25 interface?  Over a single Ethernet interface?

It is possible and practical if the implementor/vendor goes about it
properly.  This is very simple to do once one has gotten a firm grip
on the idea that it ought to be done.  There has been at least one
case of a vendor creating TCP/IP and OSI products that discombobulate
each other's X.25 interface, but I'm told that they know better now.

Separate virtual calls/circuits should be used for IP and OSI-CLNS
PDUs.  In the (normal) case of switched virtual calls, the called end
distinguishes calls on the basis of the protocol identifier as
described by CCITT X.244 and ISO TR 9577.  The OSI Network layer
protocols have distinct protocol identifiers embedded in the PDUs
(first octet) and further break-out of protocols within the family of
CLNS protocols is supposed to be done on the basis of those protocol
identifiers.  So, if for example the traffic between points A and B
consists of (DOD) IP, (OSI) CLNP, and (OSI) ES-IS, there should be
one or more distinct VCs carrying DOD IP, and one or more other VCs
carrying CLNP and ES-IS.  Yes, CLNP and ES-IS can be mixed on a
single VC, according to standards.  There is an issue with this relating
to military encryption gear which I'll discuss separately.  If there
were also OSI CONS communications going on, these would use one or more
VCs of their own also.

The Ethernet situation is convoluted to describe because of the variants
of link frame formats ("Ethernet" vs "802.3") but the principle is the
same.  For full interoperation, both frame formats must be recognized,
following which the protocol identification can be found in the right
places.

Since the VCs are "typed" to a higher-layer protocol (or family of them),
it isn't necessary to parse the PDUs to tell DOD IP from OSI.  The OSI
implementation has to do the right thing about parsing the NPDU and
processing it as CLNP, ES-IS, or whatever.

Yes, a host using X.25 has to have some kind of VC data structure with
upper-layer context information.  This was needed anyway for a valid
IP-over-X.25 implementation; it had to keep track of which VCs were
connected to which destinations, and it was supposed to also keep track
of the precedence level, and match up traffic accordingly.  Adding one
more matching criterion (protocol family) isn't a big deal in principle.

Re military E3: There is a problem with ES-IS in an MLS environment
because it doesn't carry a label.  Therefore it isn't considered
legitimate to put it on a "multilevel VC" to coin a phrase.  Therefore
the multiplexing rules in an MLS device must be different.  Therefore
the MLS crypto box has to know which set of rules you are playing by
at a given moment.  Therefore it is necessary to have a different
protocol ID for the two cases if a single crypto box is to handle both
kinds of attached device.  After considerable discussion, it was
concluded that the standard protocol ID for OSI CLNS should be used for
the case where the normal OSI CLNS rules apply, and a different one to
signal the case where non-labeled PDUs won't be passed.  Hex 81=Normal,
Hex CD=MLS.  Phase I BFE supports neither, Phase II will support CD,
Phase III will support both.  (All BFEs support DOD IP using Hex CC.)
I suspect there are still some issues to be sorted out with MLS routing
in general.

     2. MILNET addressing for OSI hosts

There are really two questions here - NSAP addresses and NSAP/SNPA
mapping.  I don't think there has been a public pronouncement on
NSAP address assignment but the general drift of the most recent
discussions I know of was essentially a straight GOSIP Version 2
addressing situation.  Regarding mapping, GOSIP requires that you
be able to configure static routes based on left subsets of NSAPs.
ES-IS is required to be available in the implementation, so you can
presumably find or set up some IS with the right information and
use that as a routing server for some set of ES's.  OSI routing
protocols are still not in concrete, but DP 10589 is probably a
fairly safe bet for intra-domain routing.

     3. Will there be an algorithmic derivation for X.121 addresses?

This is subnetwork dependent.  I don't think there is any expectation
that MILNET will ever be based on that type of scheme for OSI purposes
(unlike the IP case).  I believe that you should plan on using OSI
routing protocols to the extent available, and static mappings of
left subsets of NSAPs otherwise.
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Jul 90 10:17:30 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu  (Lars Poulsen)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: ARP described, for newcomers
Not all ARP implementations "throw away" the IP datagram that initiates
the ARP broadcast request; ours (and other PCIP derived DOS TCP/IPs) 
certainly don't.  Saving the IP datagram is a SHOULD in RFC 1122.

James B. VanBokkelen		26 Princess St., Wakefield, MA 01880
FTP Software Inc.		voice: (617) 246-0900 fax: (617) 246-0901
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Jul 90 10:17:31 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        morgan@jessica.stanford.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Zero manufacturer code in SNAP?
    From: agate!shelby!portia.stanford.edu!jessica.stanford.edu!morgan@ucbvax.Berkeley.EDU  (RL "Bob" Morgan)
    Subject: Zero manufacturer code in SNAP?
    
    The 40-bit SNAP extension to IEEE 802.2 specifies a 24-bit
    "organizationally unique identifier" that is apparently supposed to be
    the same 24 bits that a manufacturer uses to form the upper part of a
    48-bit unique IEEE 802 MAC address.  The other 16 bits are assigned by
    the organization in any way it sees fit.

The IEEE 802.2 document actually specifies the SNAP extension header as
the 3-byte OIU only.  RFC 1042 is where the extra two bytes come from,
and the authors chose to put a DIX Ethertype there.  They could have put
the beginning of an IP packet there instead, or their initials...
    
    The question is, has the all-zeros SNAP id been assigned by IEEE to
    DoD, or the IAB, or some IP authority, to be administered by that
    authority?  Or is the all-zeros id just a general purpose format for
    translating Ethernet frames to 802.2/SNAP, to be used by anyone?

They way I've heard it (I hope I'm right enough that Jon is saved a
post) the "all zeroes" OUI was owned by Xerox from the beginning.
When RFC 1042 was being worked out, the SNAP header was the only way
to run IP on 802.2 networks, because of our inability to obtain a SAP
value for ARP (one has been assigned for IP).  So, the authors went
looking for an OUI, and Xerox was forthcoming.

Yes, you can put Ethertype 809b into those two bytes and Appletalk away.
You might want to look at a paper by Roger Pfister, "Bridging Ethernet
Frames - Which OUI?", which can be found as pub/msb_vs_lsb/661-062.txt
on vax.ftp.com.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Jul 90 10:17:38 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        hedrick@athos.rutgers.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Why does a wrong broadcast address cause arp-havoc?
RFC 1122 says that 1) machines with only one IP address shall not
act as routers by default, 2) nobody shall forward or issue ICMP
error messages in response to packets that arrive via an IP or MAC
level broadcast, and 3) that everyone must be cognizant of the old
4bsd IP broadcast address as well as the correct (RFC 950) one.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 08:02:20 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Zero manufacturer code in SNAP?
morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
+---------------
| The question is, has the all-zeros SNAP id been assigned by IEEE to DoD,
| or the IAB, or some IP authority, to be administered by that authority?
+---------------

My understanding, which has no more authority in this case than "urban legend"
(and should probably be taken with the same degree of confidence), is that the
24-bit "organization" identifier was not originally intended to be identical
with the upper 24 (well, 23) bits of some assigned MAC address, but was to be
a separate space assigned/managed by IEEE.

(The obvious hack of making it be the same as a manufacturer's 23-bit unique
MAC-address prefix came later, if at all. [*Is* that the way the IEEE assigns
them?] After all, it *is* possible that a manufacturer could make more than
2^24 network interfaces and need some more addresses, so why mix SNAP IDs with
MAC addresses?)

So organizations had to request/register SNAP "organization IDs", and Xerox
Corporation [who at Xerox?] asked for(?) / was assigned(?) [by whom?] the
zero code. Xerox then said to the world, "We hereby state that we're going
to use the Xerox-registered Ethernet types..." [remember that Xerox still has
the registry for *Ethernet* type codes] "...in the 16-bit reserved-for-org-
anization field of SNAP organization code #0 (== Xerox), and we invite any
and all to do likewise".

And so at an after-dinner session at the Monterey TCP/IP Conference [the First,
or maybe Zero-th, Interop Conference], the "TCP/IP community" [the people in
that room, at least] agreed to cease using the LSAP code that had been assigned
by IEEE for IP, and agreed to use SNAP Org. Code 0 + EtherType on 802.2 links
and FDDI, in order to have not only IP but ARP and BOOTP and RARP, etc.

[The term "SNAPpy Xerox" was sometimes used as an irreverant handle for this
encoding, until RFC-1042 came out.]

Anyway, that's the way I heard it. I invite correction/historical_revision
by any who have more authoritative sources/memories. [Won't take much to be
more authoritative than the above...  ;-}  ]


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 14:47:13 GMT
From:      glratt@rice.edu  (Glenn Forbes Larrett)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Info on Telnet 3270 needed
As far as MS-DOS machines go, NCSA has       FTP Software
a PD 3270 emulator out and FTP Software's -->26 Princess Street
PC/TCP package has one as well.              Wakefield, MA 01880
                                             (617)-246-0900

	Glenn Larratt			glratt@uncle-bens.rice.edu
	Computing Resource Center	OCIS, Rice University
	Glenn Larratt			glratt@uncle-bens.rice.edu
	Computing Resource Center	OCIS, Rice University
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 14:52:15 GMT
From:      mcsun!cernvax!chx400!ethz!flog@uunet.uu.net  (Florian Gutzwiller)
To:        tcp-ip@nic.ddn.mil
Subject:   SL/IP ?

Who has experience with SL/IP on CONVEXes and Stardent Titan ?
I will summarize upon request.

Florian A. Gutzwiller                           phone:  +41 1 256 3542
Communication Systems Department                fax:    +41 1 261 5389
Swiss Federal Institute of Technology           inet:   flog@ks.id.ethz.ch
Zurich, Switzerland                             uucp:   flog@ethz.UUCP
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 15:11:56 GMT
From:      usc!sdd.hp.com!samsung!cs.utexas.edu!texbell!nuchat!abbadon@ucsd.edu  (David Neal)
To:        tcp-ip@nic.ddn.mil
Subject:   FDDI - a call for sources
Hello,

I'm looking for any and all information regarding FDDI.
Technical specs, hardware vendors, etc etc.

We want to implement an FDDI backbone with 10 megabit drops
to building backbones. Optimally, the FDDI ring would be
on microwave instead of fiber between NASA and us, as 
they are across the highway. Literally.

Thanks.



-- 
David Neal
abbadon@nuchat.uucp
abbadon%nuchat@{rice, bcm, texbell, uunet}
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 16:00:33 GMT
From:      usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!ohstpy!miavx1!pemurray@ucsd.edu  (Peter Murray)
To:        tcp-ip@nic.ddn.mil
Subject:   Network routing to/from a SLIP connection
I have what appears to be a network routing problem.  If not, please point
me in the right direction.

We just hooked up a SLIP connection between an IBM PC running KA9Q (the
release is a couple of months old, I'm not sure of the version number) and
a MicroVAX II running Ultrix 3.1.  Believe it or not, the connection from
the PC to the MicroVAX works!  (It took many long weeks to get there.)  :-)

This is the problem:  packets sent from the PC to anywhere but the MicroVAX
do not appear to be forwarded to the ethernet network.  Packets from the
network do not appear to be forwarded to the PC.  It seems like the
connection is only valid for the PC and the MicroVAX.

The setup:  we have a Class B network with a broadcast of 134.53.3.255 and
a subnet mask of 255.255.255.0.  The Ultrix box is the domain name server
for the subnet, but the PC's address is not in the tables.  I've been
using it's IP address to test the connections.  We are running 'routed'
(this was suggested by someone here as a possible problem).

Solutions already tried:  A friend of mine suggested that there was a 
problem with the SLIP protocol that was fixed if the SLIP machine was
on a subnet by itself.  I changed the IP address of the SLIP connection
so that it was in a different (unused) subnet, but this did not help.
I also looked for RFCs, but the only one I found dealing with SLIP 
(RFC 1055; "A Nonstandard for Transmission of IP Datagrams over Serial
Lines:  SLIP") was of no help.  DEC does not support SLIP, so the
Ultrix manuals haven't been very good.

I would very much like to hear how this has been solved at other sites.
SLIP seems to be a popular problem, and I will post a step-by-step method
of how I did it when (IF?) I can solve this one last problem.

Thanks in advance for your help...

Peter
-- 
Peter Murray            Neat UNIX Stunts #4:             pemurray@miavx1.bitnet
215 Foxfire Dr #308           csh> \(-            murrayp@apsvax.aps.muohio.edu
Oxford, OH 45056                       NeXT Mail:  pmurray@next4.acs.muohio.edu
513/523-5994                               
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 16:54:57 GMT
From:      joymrmn!root@uunet.uu.net  (Marcel D. Mongeon)
To:        tcp-ip@nic.ddn.mil
Subject:   Excelan Lan Workplace and Packet Drivers?
I have an Excelan 205T board in an SCO Xenix 386 machine
supporting the Lan Workplace software.  The board is hooked
up to a thinwire ethernet.  I have been trying (without
any success) to get some DOS based machines talking to this
board using other vendor's boards driven by appropriate
packet drivers.  I try both NETBIOS and FTP style calls to
the Excelan board and it doesn't respond.

The Excelan board is receiveing the packets because any of
the appropriate stat commands done before and after an
attempted link indicates that the excelan received packets --
it just didn't do anything with them!

I think that I am probably screwing up the IP and Ethernet
addresses.  Any suggestions?

-- 
|||  Marcel D. Mongeon          
|||  e-mail:    ... (uunet, maccs)!joymrmn!root  or
|||                                joymrmn!marcelm
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 17:58:27 GMT
From:      venus!yalevm!maine!shanley@CS.YALE.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Telnetd daemon doesn't get started
Equipment:  AT&T 3B2-400
            Unix V 3.1
            Wollongong TCP/IP WIN*/3B Interface Rel 3.0.1
 
Problem:    Can telnet out of the machine but can't telnet in.
            ie.  telnet me and telnet umofm.umeofm.maine.edu
                 doesn't work.
 
            ftp and ping are fine and telnet out of umofm is fine.
 
 
My senerio:  It seems that the telnetd daemon/server is not getting
             started.  I have played with the nlsadmin command with
             the following results:
 
             nlsadmin -x          tcp INACTIVE
             nlsadmin -i          net_spec already initializied
             nlsadmin -s          addresses not initializied for tcp
 
             I reloaded the software and I get the following error
             upon starting the network software:
 
             nlsadmin: addresses not initializied for tcp
 
 
Any and all help would be appreciated.  Thanks!
 
 
 
Kevin Shanley
System Administrator
Office of Facilities Management
University of Maine
Orono, Maine
shanley@umofm.umeofm.maine.edu
shanley@maine.caps.maine.edu
207-581-2681
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 01:24:12 PDT (Thu)
From:      root@asylum.sf.ca.us (Super user)
To:        knowledge!pclark@genbank.bio.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Beginner's info TCP & UDP
UDP has a lot less overhead than TCP. For simple transaction-based
protocols (request-response) that don't carry much data, UDP is much
simpler to use. TCP would have the additional overhead of setting up
and tearing down its connection, whereas UDP sends the request and
response and doesn't care about the ret.

In request-response protocols based on UDP, you have to worry about
three main things: what happens if a packet gets lost (solution: set a
timer and retransmit), what happens if you resend the request and
its action gets duplicated (solution: be careful about your protocol
design, or put sequence numbers in the packets), and what happens if
your data doesn't all fit in one packet (solution: IP fragmentation,
or split it across packets, or you lose). Splitting data across UDP
packets is often a good reason to start using TCP, since it already
has a lot of mechanism in it for dealing with this issue.

Not many applications use UDP for transferring lots of data. Those
applications are normally TCP-based. However, UDP is very convenient
for applications wishing to use a bulk data transport protocol with
different behaviour from TCP. This kind of work would be mostly
experimental, though.

SNMP, the main network management protocol for the Internet, is
layered on top of UDP. One advantage to this is that it allows those
vendors that might provide SNMP in their products that would otherwise
have no (IP) protocol stack (like an ethernet hub) to include SNMP
without having to implement a full TCP. While getting a TCP
implementation running today is easier than it was several years ago,
UDP is orders of magnitude simpler.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"There is no loyalty except loyalty to the party. There is no love except love
of Big Brother. All competing pleasures we will destroy." - 1984 (film)
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 19:54:15 GMT
From:      usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!scotty.dccs.upenn.edu!hagan@ucsd.edu  (John Dotts Hagan)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM VM TCP/IP GDDMXI
test

--Kid.
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 19:58:38 GMT
From:      usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!scotty.dccs.upenn.edu!hagan@ucsd.edu  (John Dotts Hagan)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM VM TCP/IP GDDMXI

We are trying to run GDDMXI under IBM VM TCP/IP FAL 1.2.2.

Has anyone gotten it to work?  I cannot get the demos to run (ex, GXDEMO1).

The problem we have is the remote X server (a DECstation 3100 running
Ultrix 3.1D and the DEC X server), cannot find the default font that
the GDDMXI is trying to use, ROM20.500.

When I edit the X DEFAULTS file on the VM system, as instructed, and configure
it to use a font on my DECstation:

gddmx*Hwdfont: fixed

I get the same error about the ROM20.500 font!  I don't think it is reading
the X DEFAULTS file at all!

If you have it working, and are willing to help, please send me mail and
include a phone number so we could compare our system with yours to find
out what we have wrong on our end!

Thanks!

--Kid.

(215) 898-9192
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 20:06:13 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   Unix POP3 mail client?
Any pointers to source for a BSD Unix POP3 mail client?  I've found several
servers, but no clients.		  - Brian
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 20:29:04 GMT
From:      van-bc!sl@ucbvax.Berkeley.EDU  (Stuart Lynne)
To:        tcp-ip@nic.ddn.mil
Subject:   Streams buffers under TCP/IP
We're just installed BIND 4.7 under SCO Xenix TCP/IP. All is running well
except that we are getting the occasional message from the kernel indicating
we need to allocate more streams buffers.

Does anyone know how to list the high water marks for streams buffer usage?
I'm sure there is a program to do it, I remember doing it last year. But
can't find the program. (That's the wonderful thing about Unix, there is a
program for everything.. if you can remember where the bloody thing is..)
I've looked the all my FM's but can't find anything.

For anyone out there running a Xenix site hooked up to the internet you will
probably want to get the new bind running. It works a lot better than the
stock version.
-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 21:10:10 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Unix POP3 mail client?
In article <15720@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes:
>Any pointers to source for a BSD Unix POP3 mail client?  I've found several
>servers, but no clients.		  - Brian


I don't know about POP3 clients, but there is a Unix IMAP client and
server on FTPHOST.CAC.WASHINGTON.EDU as pub/imap.tar.Z.
 _____   | ____ ___|___   /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105
 _|_|_  -|- ||   __|__   /  / 6158 Lariat Loop NE   "Gaijin! Gaijin!"
|_|_|_|  |\-++-  |===|  /  /  Bainbridge Island, WA "Gaijin ha doko ka?"
 --|--  /| ||||  |___|    /\  USA 98110-2098        "Niichan ha gaijin."
  /|\    | |/\| _______  /  \ "Chigau. Gaijin ja nai. Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 21:45:52 GMT
From:      daffy!gumby.cs.wisc.edu!upl@speedy.wisc.edu  (Undergrad Projects Lab)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for POP2 server source
Hi all!

I'm interested in finding a pop2 (Post Office Protocol - version 2) server.
I have found a pop3 server and I have it working -- This is good.  However
I have an application that is a pop2 client that I don't want to re-write.
Any information on an FTP location of said software would be greatly 
appreciated.

Thanks,
- Mark
P.S.	PLEASE PLEASE PLEASE do NOT respond to the account from which this
	article is being posted.  Instead, use the following account:
		mark.horn@mail.admin.wisc.edu
	-or-	harier!sparkie@cs.wisc.edu
	Thanks, again
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 90 23:08:44 GMT
From:      van-bc!sl@ucbvax.Berkeley.EDU  (Stuart Lynne)
To:        tcp-ip@nic.ddn.mil
Subject:   sw (was Re: Streams buffers under TCP/IP)
In article <918@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes:
>Does anyone know how to list the high water marks for streams buffer usage?
>I'm sure there is a program to do it, I remember doing it last year. But
>can't find the program. (That's the wonderful thing about Unix, there is a
>program for everything.. if you can remember where the bloody thing is..)
>I've looked the all my FM's but can't find anything.

My aged synapses finally came through... it's called "sw" which presumably
stands for stream watch.

Now the 64k$ question is does anyone have any detailed information on what
sw does? I've got my problem fixed (up'd the number of 128 and 256 byte
buffers) but while I'm looking it would be interesting to figure out what
the other things that sw is telling us about *really* mean. 

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Jul 90 2:54:58 GMT
From:      Mills@udel
To:        jbvb@vax.ftp.com
Cc:        hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  ARP described, for newcomers
James,

Harrumpth. I'm glad for you and add fuzzballs to the list of ARP-keepers.
There is at least one protocol (NTP) that ratchets poll interval up to
17 minutes. There is at least one vendor (*) that caches-out ARP entries
every 14 minutes. There is at least one sucker who spent some days chasing
that bog down. Read your SHOULD as REALLY, REALLY SHOULD.

Dave
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 07:06:00 EDT
From:      "RANDY CATOE" <randy@TWG.COM>
To:        "qualcom!jwn2" <qualcom!jwn2@ucsd.edu>
Cc:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RE: WIN/TCP for VMS 5.1 NTYDRIVER bug
Date sent:  19-JUL-1990 07:03:30 
>From:	ECOVAX::WINS%"<qualcom!jwn2@ucsd.edu>" 18-JUL-1990 07:47:52.83
>To:	RANDY
>CC:	
>Subj:	WIN/TCP for VMS 5.1 NTYDRIVER bug
>Date: 12 Jul 90 06:45:10 GMT
>Subject: WIN/TCP for VMS 5.1 NTYDRIVER bug
>Message-Id: <2706@qualcom.qualcomm.com>
>
>When users paste long segments of text from one Mac application into a Telnet
>window open to a VAX, the VAX regularly loses portions of the text.  I traced
>this to improper coordination between NTYDRIVER and TTDRIVER in VMS, and
>reported the problem to Wollongong.  TTDRIVER tries to xoff NTYDRIVER, but
>NTYDRIVER ignores the request, throwing down characters while TTDRIVER catches
>its breath.
>
>When I called Wollongong's technical support, the guy I talked to mumbled
>something about "oh that problem...review committee...mumble-mumble-mum..",
>but that was 6 months ago.
>
>Does anyone know if a patch exists for this?  I apologize if I'm bringing up
>old news, but I've still got the bug, and I'm not getting any younger... 
>
>Thanks from this poor, stranded luser in VMS-land!
We do indeed have a fix for this problem.I have arranged for it to be 
sent to you immediately.

Please accept my apology for any delay that we may have caused in responding
to you.

Randy Catoe
The Wollongong Group, Inc.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Jul 90 08:11:13 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   VAX ping & NCSA Telnet

>Thanks for all responses. It has become a moot point. NCSA's tcp/ip
>for MS-DOS requires (inexplicably) that the VAX PING the PC in order
>to get communications to work after both machines have rebooted. We
>are now using FTP Software's tcp/ip for MS-DOS, which has not exhibited
>this strange behavior.

I would sure like to see an explanation of this.  We use NCSA here on all
our connected PCs and we DO NOT have ping enabled on the VAX.NCSA doesn't
do anything different here than any other host on the network.  I can't
imagine why ping would be necessary on the VAX.

Can you elucidate???

bill gunshannon

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Jul 90 11:42:51 CDT
From:      stanley@visual1.tamu.edu (Stanley Guan)
To:        tcp-ip@nic.ddn.mil
Subject:   remove me from this list
Please remove me from this list! Thank you!
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 06:46:38 GMT
From:      barmar@think.com  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP checksums
In article <1812@hsi86.hsi.UUCP> stevens@hsi.com (Richard Stevens) writes:
>In article <1990Jul17.003242.1556@ultra.com> beau@ultra.com (Beau James writes:
>>UDP checksums must be enabled on both sending and receiving

>Newer systems should start conforming to the Host Requirements RFC (1122),
>meaning the receiver has to honor a checksum that was set by the sender:

The question was specifically about enabling checksums in current BSD
systems, in which case the caveat is correct.  Is this bug fixed in 4.4bsd?

Also, if the systems were conforming to the HR RFC it wouldn't be necessary
to turn on UDP checksums.  I believe the RFC also specifies that they MUST
be enabled by default, and SHOULD provide the ability for the application
or system administrator to disable them.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 12:17:00 EST
From:      "Murl McRae" <mcrae@mk6vms.nwscc.sea06.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RE: WIN/TCP Window Size
As requested by BILLW@mathom.cisco.com on 19-JUL-1990 08:31, here is
more information on my WIN/TCP window size question:
 
    The reason I wanted to change the window size was to see if that
would improve our Internet performance.  We have a very slow Internet link.
The average roundtrip time is around 1.5 seconds.  Our FTP transfer rate is
only about 9.6K bits/sec.  With the long roundtrip time we thought a larger
window might help increase FTP throughput so we wanted to change the window
(both send and receive) and run some tests.
     Since I posted the orginal message I have found out how to change the
window sizes.  I changed the sizes from 4096 to 8192 and we tried a few 
transfers.  The results were inconclusive.  I don't think the performance
changed.  I did notice that all of the other hosts in the test had receive
windows around 4K (obviously I am rather green at this stuff), so if we did
get any improvement it would be in one direction only.  So it looks to me
like I ought to return the window sizes to 4096 and leave them alone.
    Any other sugguestions on improving performance on a slow link would
be appreciated.  Our current link into MILNET is via sattelite.  We are
working on getting a land line, but that may take a while.  Thanks.
 
Murl McRae                                 Naval Weapons Support Center
                                           Crane, Indiana

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Jul 90 15:14:19 -0400
From:      George Williams <gwilliam@SH.CS.NET>
To:        Ian Watson <hpcc01!hpcuhb!hpsqf!hpopd!ian@hplabs.hpl.hp.com>
Cc:        tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET
Subject:   Re: TCP Port state FIN_WAIT_1 : what's that ?

Hello,

The close sequence in TCP is a symetrical exchange. That is the side issuing
close generates the following protocol exchange:

              close initiator      TCP             close receipient
             -----------------                    ------------------
  CLOSE REQ  =======>     
                            --------------------->
                                 fin(1)            
                                                                
                            <-------------------
                                fin(1) ack

     must insure now data
     in pipe.
                                                   usually notification
                                                          event      

                                                         <=======   CLOSE REQ
                               
                            <--------------------
                                fin(2)

                             -------------------->
   event notification           fin(2) ack

        The above is a full duplex close operation on a socket/port pair.
 

There are wait states associated with the above that I ommitted. But I think
it should be noted:

    () THe close sequence ideally operates on TCP socket pairs.
       It was designed to allow for the draining of data in transit 
       or in the pipeline. The sender of close can not send data but
       is resposible for all data the other side has in transient.

       This minimizes loss of data during close between two non-cooperative
       or non-peer applications. It allows even for simultaneous close
       operations since TCP queues the fin/acks until deliverable. That
       is the wait you probally are seeing.

    () You can be left with half open connections if this is not 
       implemented a spec'd. The RFC goes into details in this area.
       And there are implemetation tips.

    () Depending on the OS interface to TCP one might be able to get away
       with exiting without fully closing a connection, i.e. waiting for
       notification that the other side has closed. I would do this unless
       I wrote both side or am talking to peer applications that have a common
       higher level protocol.
  
       Some workarounds for violations of the above I have seen have included
       the Os generating an abort/close when a process exits,  and timers on
       TCP wait states to mention a few.
   
It used to be one of the most bug infested areas of TCP we ever ran across
depending on the vendor and the application/os interface.

If you a programming for multiple connections or concurrency this really is
a problem depending on whose TCP you use.

Additionally, that last 'fin ack' has no ack so it is a 'hole' in the protocol.
So if it get dropped ( have seen  this happen) via routers or bad bridge 
connections there is no recovery. So most vendors put in the timer ( 2 min
or 5 min etc. ) as a backup.
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 10:10:09 GMT
From:      eru!luth!sunic!nuug!hod!tommy@bloom-beacon.mit.edu  (Tommy Johansen)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP on Packet Radio
We are currently working with TCP/IP on Packet Radio. Our goal is to run 
TCP/IP from one Ethernet to another with as high speed as possible. At the 
moment we are able to communicate at 2400 baud. My questions are as follow:

            Is it possible to run at 64 kb speed?
            What kind of experience has bin ganed from simulare work? 
            Who delivers HW and SW?
            Is there anybody out there doing the same thing?

I'm interesting in anything witch has to do with TCP/IP on Packet Radio.
--
| Tommy Johansen                        | E-mail: tommy@tommy.uit.no          |
| University of Tromsoe,                | FAX   : +47 83 55418                |
| N-9000 Tromsoe                        | Tlf. work: +47 83 55419             |
| NORWAY                                | Tlf. priv: +47 83 73958             |
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Thu, 19 Jul 90 16:09:58 EDT
From:      lazear@gateway.mitre.org
To:        protocols@rutgers.edu, tcp-ip@nic.ddn.mil
Subject:   RPC experience
I'm interested in finding out people's experiences in using Sun's
RPC with existing applications.  That is, how they fared inserting
RPC into an application that was already written.  Please contact
me directly.

I'd also be interested in articles discussing the issues people have
dealt with when inserting RPC into applications.

	Walt Lazear
	MITRE Corp.

	703/883-6515
	lazear@gateway.mitre.org
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 13:11:13 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   VAX ping & NCSA Telnet


>Thanks for all responses. It has become a moot point. NCSA's tcp/ip
>for MS-DOS requires (inexplicably) that the VAX PING the PC in order
>to get communications to work after both machines have rebooted. We
>are now using FTP Software's tcp/ip for MS-DOS, which has not exhibited
>this strange behavior.

I would sure like to see an explanation of this.  We use NCSA here on all
our connected PCs and we DO NOT have ping enabled on the VAX.NCSA doesn't
do anything different here than any other host on the network.  I can't
imagine why ping would be necessary on the VAX.

Can you elucidate???

bill gunshannon

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 13:32:48 GMT
From:      garrett%oscar.ccm.udel.edu@louie.udel.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Problems with WIN/TCP v5.1...
Greetings, all...  We have just had the latest version of WIN/TCP (v5.1)
installed here at our site and I finally decided to sit down and learn how to
use the library/system call interface for VAXC...

Before I get into the details, we have the software installed on a 785 running
VMS v4.7 and VAXC v2.4

I have been following the examples in the WIN/TCP Programming Guide...

I found example source code in the directory TWG$TCP:[NETDIST.TUTORIAL.EXAMPLE]
(SERV.C, and CLIENT.C)

When I tried compiling these programs, I found that evidently some #include
files appeared to be missing from their correct locations.  Among these files
were:

twg$tcp:[netdist.include.sys]types.h
twg$tcp:[netdist.include.sys]errno.h
twg$tcp:[netdist.include.sys]netdb.h

I looked all through the [netdist...] directory tree for these files and could
not find them.  I took a look on the directory tree of an older version of
WIN/TCP (v3.2) and found files with the same name (sys/types2.h in v3.2 was
identical to the same file in v5.1, so I assumed the rest would be the same.
Is this a bad assumption) so I copied them to the appropriate location in the
v5.1 directory tree.

After copying these files, I was able to compile CLIENT.C and SERV.C, but got
the following warning in the process:

        typedef long    size_t;
%CC-W-DUPDEFINITION, Duplicate definition of "size_t".
                At line number 41 in TWG$TCP:[NETDIST.INCLUDE.SYS]TYPES.H;1.

Is this a bad thing?

Now, on to the linkage part...

As was suggested in the "Compiling, Linking and Running Network Code" section
of the manual, I added the following definitions to my login.com file to
make the link steps a little easier:

$ define lnk$library sys$library:vaxcrtl.olb
$ define lnk$library_1 tcp:[netdist.lib]libnet.olb
$ define lnk$library_2 tcp:[netdist.lib]libnetacc.olb

and then linked the two programs:

$ link serv
$ link client

When I linked CLIENT, though I was informed of some undefined symbols:

%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM,         _$EMUL
%LINK-I-UDFSYM,         _$MOVE

These symbols seem to be referenced extensively by modules SELECT, SEND,
RECEIVE, and WRITEV in LIBNETACC...

In fact, when you run the CLIENT program, it dies with an access violation in
the 1st library call (gethostbyname) in the program.

The SERV program is silent.  (I did a $run/det serv, as instructed by the
Programming Guide) The process it is in is still soundly sleeping, no real way
to know whether or not it is working until I can get the client part going.

Does anyone have any suggestions for me?  Is the problem because I copied the
OLD include files?  Maybe there's some special instructions for linking the
new stuff under VMS v4.7?  Maybe it's something else?  Thanks in advance for
any help y'all might be able to lend me here... All I want to do is get some
experience with writing client/server applications, and I can't even get
started yet... Grrr...  Take care, all...

+-------------------------------------+--------------------------------------+
| Joel J. Garrett, Research Associate |         Phone: (302)-451-2332        |
|   Center for Composite Materials    |   inet:  garrett@oscar.ccm.udel.edu  |
|       University of Delaware        |                - or -                |
|       Newark, Delaware 19716        |          garrett@udel.edu            |
+-------------------------------------+--------------------------------------+
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 15:10:55 GMT
From:      sun-barr!newstop!texsun!csccat!camdev!sscott@apple.com  (Steve Scott)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM/HP-UX FTP session hangs on PORT command
Hello, HP-UX fans!

The following is an excerpted note from one of my Big Blue Buddies with
all company proprietary info deleted  ;-)

I am not sure whether or not this is an HP or an IBM problem (although
my friend does not mention this sort of a failure on other vendor's
hardware/software).  

Maybe someone from within the HP labs can help here???

--------------- Excerpted mail begins --------------------------

Subject: FTP PORT command failure from HP nodes

Steve, we have seen a problem for a long time where FTP sessions from IBM
TCPIP to an HP node would fail when the FTP application issued a PORT command.
By testing the PORT command manually, I find that HP nodes are not accepting
port arguments where the first decimal portion of the port address is 3 or
less (ie PORT 192,25,80,1,3,200). I found nothing in the RFC indicating a
limit or restriction.

Is there some HP documentation about FTP PORT command limits or someone we can
call to resolve this?  (A remote site) has this problem too.

History:

    FTWENG is an IBM 43xx machine at IP address 192.25.80.1 via an
    8232 Ethernet interface box

    CAMDEV is an HP370 at IP address 192.25.80.50 running HP-UX 7.0


To see the problem, FTP from FTWENG to an HP node (CAMDEV) and issue

  QUOTE PORT 192,25,80,1,3,200

(this will fail)

  QUOTE PORT 192,25,80,1,4,200

(this will work)

------------------ Excerpted mail ends -------------------------------


Any ideas out there?

-- 
Steve Scott            UUCP: {texbell|texsun}!csccat!camdev!sscott
Motorola, Inc.         Internet : sscott@mot.com  Telephone : 1-817-232-6317
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 16:24:35 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!crdgw1!ge-dab!tarpit!ucf-cs!eola!goldfarb@ucsd.edu  (Benjamin I. Goldfarb)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability / little flow control primer
src@scuzzy.uucp (Heiko Blume) writes:

>i've never heard of codex, but anyway: i assume that these are fast modems
                     ^^^^^

Codex modems are made by Motorola.

-- 
------------------------------------------------------------------------------
Ben Goldfarb				uucp: {decvax,uflorida}!ucf-cs!goldfarb
University of Central Florida		Internet: goldfarb@eola.ucf.edu
Department of Computer Science		BITNET: goldfarb@ucf1vm.BITNET
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 16:25:37 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Problems with WIN/TCP v5.1...
In article <25049@nigel.udel.EDU> garrett@oscar.ccm.udel.edu writes:
>I have been following the examples in the WIN/TCP Programming
>Guide...

The programming guide doesn't match reality in all cases.  The thing
that you need to know to get programs to link is there is only one
library called TWGLIB.  It replaces LIBNET and LIBNETACC.  These
libraries are for use only by Euncie.  There should have been stuff in
the release notes about this, but my memory here is a bit faded.

>After copying these files, I was able to compile CLIENT.C and SERV.C, but got
>the following warning in the process:
>
>        typedef long    size_t;
>%CC-W-DUPDEFINITION, Duplicate definition of "size_t".
>                At line number 41 in TWG$TCP:[NETDIST.INCLUDE.SYS]TYPES.H;1.
>
>Is this a bad thing?

No.  size_t gets redefined from an unsigned int to a signed int (since
VAX-C has int == long).  Unless you are dealing with very large
objects, this shouldn't be a problem.  The original definition is in
something like SYS$LIBRARY:TYPES.H or some other include VAX-C include
file.  If you remove it from [NETDIST.INCLUDE.SYS]TYPES.H, then the
error will go away.  You can also change it to "typedef unsigned int
size_t".

Also, you should be using the types.h file from
twg$tcp:[netdist.include.sys] off the 5.1 tape.  It is not in the VMS
4.x installation saveset due to an oversite.  You can get it out of
the "B" saveset (fullname WIN_TCP051.B I think).

>As was suggested in the "Compiling, Linking and Running Network Code" section
>of the manual, I added the following definitions to my login.com file to
>make the link steps a little easier:

This section is wrong.  The libraries that you use have changed in
release 5.1.  You should add the following to your login.com

$ define LNK$LIBRARY SYS$LIBRARY:VAXCRTL.OLB
$ define LNK$LIBRARY TWG$TCP:[NETDIST.LIB]TWGLIB.OLB

>%LINK-W-NUDFSYMS, 2 undefined symbols:
>%LINK-I-UDFSYM,         _$EMUL
>%LINK-I-UDFSYM,         _$MOVE

These routines are found in LIBNET, so if you list that after the
LIBNETACC (for a second time), you shouldn't get errors.  However, you
will be better off in the long run by using TWGLIB.

Try these suggestions.  They should help.  All of the above is from
memory, since I no longer work for TWG.
--
Warner Losh		imp@Solbourne.COM
Boycott Lotus.		#include <std/disclaimer>
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 17:17:00 GMT
From:      mcrae@mk6vms.nwscc.sea06.navy.mil ("Murl McRae")
To:        comp.protocols.tcp-ip
Subject:   RE: WIN/TCP Window Size

As requested by BILLW@mathom.cisco.com on 19-JUL-1990 08:31, here is
more information on my WIN/TCP window size question:
 
    The reason I wanted to change the window size was to see if that
would improve our Internet performance.  We have a very slow Internet link.
The average roundtrip time is around 1.5 seconds.  Our FTP transfer rate is
only about 9.6K bits/sec.  With the long roundtrip time we thought a larger
window might help increase FTP throughput so we wanted to change the window
(both send and receive) and run some tests.
     Since I posted the orginal message I have found out how to change the
window sizes.  I changed the sizes from 4096 to 8192 and we tried a few 
transfers.  The results were inconclusive.  I don't think the performance
changed.  I did notice that all of the other hosts in the test had receive
windows around 4K (obviously I am rather green at this stuff), so if we did
get any improvement it would be in one direction only.  So it looks to me
like I ought to return the window sizes to 4096 and leave them alone.
    Any other sugguestions on improving performance on a slow link would
be appreciated.  Our current link into MILNET is via sattelite.  We are
working on getting a land line, but that may take a while.  Thanks.
 
Murl McRae                                 Naval Weapons Support Center
                                           Crane, Indiana

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 18:28:32 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!crdgw1!sunne!brownpc@ucsd.edu  (Paul C Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for Sun's
I am looking for a SLIP implementation that will allow two Sun-3's to
communicate
via a serial link. Sun tells me that the SLIP server provided with PC-NFS will
not do the trick, since the PC end of the link encodes routing data in the 
packets that a normal sun would not. They mentioned that there is a "gated"
deamon from Clarkson that replaces the "routd" supplied by Sun that does
the trick. Anyone know where I can find this?

I will summarize responses upon request.  Thanks in advance!


Paul C. Brown				brownpc@crd.ge.com
GE Corporate Research & Development
Schenectady, New York
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 18:48:01 GMT
From:      amazon.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  How to get RFC documents dealing with TCP-IP
In article <9007171705.AA12869@bel.isi.edu>, postel@VENERA.ISI.EDU writes:
> 
> RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
> RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC).  Login
> with FTP, username ANONYMOUS and password GUEST.
 
Jon! For anonymous logins, one should follow the printed instructions and enter
their username on their local system, not guest. While I doubt anyone at the
NIC ever looks at it, I do look at my anonymous logs and frequently contact
people having problems with the VMS syntax my system uses. If they just type
GUEST, as many do, I'm helpless. I know the system, but not the user.

Please be polite and enter your real ID if that's what is asked for. (And it
almost always is.)

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 18:59:22 GMT
From:      abvax!icd.ab.com!ejp@tut.cis.ohio-state.edu  (Ed Prochak)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Beginner's info TCP & UDP
In article <64291@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
> In answering a beginner's question, hedrick@athos.rutgers.edu
> (Charles Hedrick) writes:
> +---------------
> | People tend to use UDP where (1) they plan to be making isolated
> | queries, such that the overhead packets used to set up and close a
> | connection would form most of the traffic (2) they need more
> | performance than they think they can get from TCP....
> +---------------
> 
> I would add:
>  ...(3) there are a very large number of clients accessing a single
>     server, such that the cost of holding a connection open for each
>     active client would be excessive. [The definition of "excessive"
>     is system- and application-dependent.]
> 
> In some sense this is the same as Hedrick's #1, except that #1 refers
> to conserving dynamic network bandwidth, and #3 to conserving quasi-
> static server system resources "wired-down" by connections (sockets,
> open-file slots, processes, etc.).


I think Rob's condition is important in some cases.
 (at least that and the following was the justification
 I used for an application using UDP).

In addition:

...(4) preservation of record boundaries. TCP provides the data
     to the reciever as it is available. This means messages may
     be fragmented and it is up to the application to parse out
     record boundaries.  There are some applications that prefer
     to receive messages intact, making UDP the protocol of choice,
     in this case.

As usual, the case is one of
no single right answer.
It all depends on the situation.

(I hope someone summaries this thread.)

ed


Edward J. Prochak   Voice: work-(216)646-4663  home-(216)349-1821
               Email: {cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com
USmail: Allen-Bradley, 747 Alpha Drive, Highland Heights,OH 44143
As defined by a civil engineer named Wellington, ENGINEERING is
 "the ability to do for one dollar, what any damn fool can do for two."
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 19:14:19 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Port state FIN_WAIT_1 : what's that ?


Hello,

The close sequence in TCP is a symetrical exchange. That is the side issuing
close generates the following protocol exchange:

              close initiator      TCP             close receipient
             -----------------                    ------------------
  CLOSE REQ  =======>     
                            --------------------->
                                 fin(1)            
                                                                
                            <-------------------
                                fin(1) ack

     must insure now data
     in pipe.
                                                   usually notification
                                                          event      

                                                         <=======   CLOSE REQ
                               
                            <--------------------
                                fin(2)

                             -------------------->
   event notification           fin(2) ack

        The above is a full duplex close operation on a socket/port pair.
 

There are wait states associated with the above that I ommitted. But I think
it should be noted:

    () THe close sequence ideally operates on TCP socket pairs.
       It was designed to allow for the draining of data in transit 
       or in the pipeline. The sender of close can not send data but
       is resposible for all data the other side has in transient.

       This minimizes loss of data during close between two non-cooperative
       or non-peer applications. It allows even for simultaneous close
       operations since TCP queues the fin/acks until deliverable. That
       is the wait you probally are seeing.

    () You can be left with half open connections if this is not 
       implemented a spec'd. The RFC goes into details in this area.
       And there are implemetation tips.

    () Depending on the OS interface to TCP one might be able to get away
       with exiting without fully closing a connection, i.e. waiting for
       notification that the other side has closed. I would do this unless
       I wrote both side or am talking to peer applications that have a common
       higher level protocol.
  
       Some workarounds for violations of the above I have seen have included
       the Os generating an abort/close when a process exits,  and timers on
       TCP wait states to mention a few.
   
It used to be one of the most bug infested areas of TCP we ever ran across
depending on the vendor and the application/os interface.

If you a programming for multiple connections or concurrency this really is
a problem depending on whose TCP you use.

Additionally, that last 'fin ack' has no ack so it is a 'hole' in the protocol.
So if it get dropped ( have seen  this happen) via routers or bad bridge 
connections there is no recovery. So most vendors put in the timer ( 2 min
or 5 min etc. ) as a backup.

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 20:22:28 GMT
From:      ssc-vax!bcsaic!carroll@beaver.cs.washington.edu  (Jeff Carroll)
To:        tcp-ip@nic.ddn.mil
Subject:   SUMMARY: porting Berkeley lpd code to sys V R3.2
In article <27966@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes:
>
>	I would very much like to hear from anyone who has experience
>porting BSD code to system V/386. I'm trying to get lpd, lpr, lpq, et
>al. to run on our Intel 301s, which run Intel (Lachman) TCP/IP...

	In addition to the responses summarized below, I had someone
point me to the NCSA Telnet sources on tacky.cs.olemiss.edu. I'm not
going to try that port yet...

	As indicated below, source for "System V-ized" lpr is allegedly
available for anonymous ftp on acm.rpi.edu, though I haven't been able
to reach the ftp server on this machine. If anyone knows where else this
code can be found, I'd love to know about it.

	I don't have a working solution yet, but I am just now getting
around to answering all the email I elicited. Thanks to all who
responded!

	Jeff Carroll
	carroll@atc.boeing.com
_____________________________________________________________________________
From skl@wimsey.bc.ca Sun Jul 15 03:13:17 1990

I have done some porting of the BSD TCP/IP code to Xenix/V 386,
which "claims" to be System V compatible.

From: Arthur L. Martin <uw-beaver!rutgers!pawl.rpi.edu!night>
>	How big a job is this?

I rather big one.  I made a couple of attempts at it and gave up.  
However, I did run across a SysV port of lpr on an anonymous ftp
site.  I don't remember the site offhand, but I still have the
package lying around.  I can make it available for anonymous ftp
if you like.

--
--
Trip Martin
night@pawl.rpi.edu

From: uw-beaver!ames!daver.bungi.com!dlr (Dave Rand)

I have done this for 386/ix. If you would like the diffs, please let
me know!

-- 
Dave Rand
{pyramid|mips|sun|vsi1}!daver!dlr	Internet: dlr@daver.bungi.com

From: Paul Nulsen (some horrible bang-path addr that I accidentally
deleted)

A port has been done. It was announced recently by dlr@daver.bungi.com (Dave
Rand). I have copies of the diff files he provided.

Regards,
Paul Nulsen
pejn@wolfen.cc.uow.edu.au

From: hitachi!jon@uunet.UU.NET (Jon Ryshpan)
...
>	The larger goal is to enable our Vax running WIN/TCP or MultiNet
>to act as a print server for the 301s.
...

We do it with the this kluge.  The following shell script is the
"interface" in the SysV spooler system.  You also have to create a file
to be the printer for the spooler destination; /dev/null doesn't seem
to work, so we have a file called DUMMY in a convenient location.
Actually the file is /usr/spool/lp/DUMMY.  The only problem is that
each user who wants to print has to have an account on the vax.  Here
is the script:

#
# lp interface for submission to the vax for reprinting.
#

copies=$4
shift; shift; shift; shift; shift
files="$*"
i=1
while [ $i -le $copies ]
do
	for file in $files
	do cat "$1" | /usr/ucb/rsh vax lpr -P lsiNTX
	done
	i=`expr $i + 1`
done
exit 0
-- 

Many Thanks:	

Jonathan Ryshpan		<...!uunet!hitachi!jon>

M/S 420				(415) 244-7369  	
Hitachi America Ltd.
2000 Sierra Pt. Pkwy.
Brisbane CA 94005-1819

From: night@pawl.rpi.edu (Trip Martin)

Okay, I've made lpr available on clotho.acm.rpi.edu (128.113.10.204) in
~ftp/pub/lpr.tar.Z.  Enjoy!

-- 
--
Trip Martin
night@pawl.rpi.edu

(NOTE: I have been unable to raise this host via FTP. Anybody know more
about this code? jkc)

From: uw-beaver!rutgers!leonardo.intel.com!davidl (David D. Levine)

If you can wait a while for System V Release 4, there's a REAL easy way...
BSD compatibility and the BSD lp* utilities are BUILT INTO Release 4...
Contact your local Intel salesthing for details.

- David D. Levine, Intel IMSO Tech Pubs
  davidl@leonardo.intel.com
  "Think of it as evolution in action."

From: Stan Stead <stan@anes.ucla.edu>
	
	I have ported the lp* BSD code to a SysV Stardent computer.  It was 
greatly facilitated by porting the BSD libraries.  I have not tried to do
the port to an SCO SysV/386 but I assume that without the libraries,
it would be EXTREMELY difficult.
	Stan

From: David Fetrow <fetrow@milton.u.washington.edu>

 I don't know but, around here where we have similar problems, they bit the
bullet and wrote printer code for everything. All the systems can use "prt"
and the files are printer from VMS printer demons. The code, is howvere, a 
tad bit ugly.

 I think most of it is available via anonymous FTP.

-- 
 -dave fetrow-                     fetrow@bones.biostat.washington.edu
 dfetrow@uwalocke (bitnet)         {uunet}!uw-beaver!uw-entropy!fetrow 

I am looking for a port of the BSD lpd code for a ATT UNIX 386 PC.  I was
wondering if you had any answers about this??  I figure somebody must have
done it by now.

Thanks,
Sonya
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Canstar                                UUCP: {utai,utzoo,ncrcan}!canstar!sonya
3900 Victoria Park Ave.               other: sonya%canstar@utai.toronto.edu
North York, ON  L3T 3T3               Phone: (416) 756-4100 x258
Canada                                  Fax: (416) 756-3990


From: scocan!larryp@uunet.uu.net

I did it a while ago.  However, I could not overcome the inertia of
the company, and the Systems department never installed it.  As such
it has not been heavily tested, in particular, I do not guarantee that
all commands even work (I gave up to early), but I was able to submit
jobs over the net.  I also never got to the stage of investigating what
filters I needed, or how to set them up.  You are welcome to the code
if you want it.

I was porting to ISC 386/ix 1.0.6, using ISC's version of TCP.  You can
be sure some of the include files will be in different places, although
things should indeed work.

I defined a compat.h and a compat.c.  Lots of defines, and where necessary
I snaged BSD subroutines and stuffed them in compat.c.  I also wrote SYSV
emulations of flock, truncate and the like.

---
Larry Philps,	 SCO Canada, Inc (Formerly: HCR Corporation)
Postman:  130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
InterNet: larryp@sco.COM  or larryp%scocan@uunet.uu.net
UUCP:	 {uunet,utcsri,sco}!scocan!larryp
Phone:	 (416) 922-1937
Fax:	 (416) 922-8397



From: uw-beaver!harvard!uunet.UU.NET!munnari!ipso.rss.ips.oz.au!craigb (Craig Bevins)

It has already been done.  I have the patches and I can send them to you
if you haven't already found a solution.

Craig.
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Jul 90 08:58:11 -0700
From:      jqj@rt-jqj.Stanford.EDU
To:        apple.com!veizades@apple.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Zero manufacturer code in SNAP?

Transparent bridging of common protocols between FDDI and Ethernet is
currently impossible due to a conflict between various "standards" (notably
RFC1103 and draft successor, IEEE 802.d, and AppleTalk Phase II).

We were the people whom John Veizades refers to that verified that AppleTalk
II doesn't work across DEC FDDI-Ethernet "transparent" bridges.  At least one
other transparent FDDI to Ethernet bridge vendor currently has the same
implementation.

John suggests that bridges should have a small table indexed by EtherType
indicating whether packets should be translated from RFC1042-style 802.2/SNAP
to Ethernet format when going from FDDI to Ethernet.  Unfortunately, this does
not solve the problem.  Suppose my FDDI to Ethernet bridge knows that AARP
packets should go out on the coax as 802.3 so that AppleTalk II nodes can
understand them.  That means that my bridge is not transparent to AppleTalk I.
So it's not an feasible solution.

I believe that if Apple wants to play in the heterogenous bridging world,
they need to modify AppleTalk II specs in one of the following ways:

1/ an AT II node on 802.3+Ethernet media must listen to *both* RFC1042-style
   802.2/SNAP/AARP *and* to Ethernet/AARP packets sent to the Appletalk
   multicast address.  This corresponds to the requirement for IP hosts that
   appears in RFC1122 and states that any 802.3/802.2/IP speaker must also
   understand Ethernet encapsulation.
 OR
2/ the AT II spec must be modified so that AARP generates and expects the
   Apple OUI the same way AT II/DDP does.

Both proposals break currently fielded AppleTalk II implementations, so I
can see that Apple may be reluctant to adopt them.  But I think that at this
point it is unlikely that the IP-on-FDDI working group will radically change
their encapsulation requirements just to satisfy Apple, and I see no way for
bridge manufacturers to satisfy everyone's requirements simultaneously.

The alternative is a modification of both the definition of "transparent"
bridging and the IP-in-FDDI spec.

To reiterate, John is correct that, by the current de facto standard,
"transparent" 802.3->FDDI->802.3 bridges are not transparent to 802.3 packets
in RFC1042 format.  This is not a problem for IP, because of the specific
requirement that all receivers of RFC1042 format on an 802.3 medium also
understand Ethernet encapsulation.


JQ Johnson                              voice: 415-723-3078
Manager, Special Projects               Internet: jqj@jessica.stanford.edu
Networking and Communications Systems
Pine Hall Rm 125-A 
Stanford University
Stanford, CA 94305-4122
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 21:58:44 GMT
From:      hayes.fai.alaska.edu!wisner@decwrl.dec.com  (Bill Wisner)
To:        tcp-ip@nic.ddn.mil
Subject:   Changing inet MTU in 4.3bsd
The question, simply put, is how do I do it? We've had some problems
with the campus network here that experience indicates might be solved
if we lower the MTU from 1500. So...?

Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775
/* you are not expected to understand this */
-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 23:02:12 GMT
From:      apple.com!veizades@apple.com  (John Veizades)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Zero manufacturer code in SNAP?
The all-zeros Rorganizational unique identifierS (OUI) was not 
specifically intended to be used for translating Ethernet frames to 
802.2/SNAP.  Its original intention was (and is) not completely clear; all 
that was generally agreed upon was:

(1) The low-order 16 bits of the SNAP protocol discriminator indicated an 
Ethernet protocol type; and

(2) The format of the data part of the SNAP packet was the same as the 
format of the data part of the Ethernet packet of this protocol type.

This Rgeneral agreement,S as far as I know, was never written down.  
AppleTalk Phase 2 and TCP/IP both adopted this convention.  The 
unfortunate difference is that, on an Ethernet/802.3 data link, AppleTalk 
Phase 2 runs on top of 802.3 (and 802.2) and TCP/IP runs on top of 
Ethernet.  Thus for a TCP/IP Ethernet node to communicate with a TCP/IP 
802.2 node (on token ring or FDDI, say), some type of packet translation 
must be performed, whereas for an AppleTalk Phase 2 Ethernet node to 
communicate with any other AppleTalk Phase 2 802.2 node (on Ethernet, 
token ring or FDDI) no such translation need occur (in fact, such 
translation MUST NOT occur).

This makes it somewhat difficult to build a bridge that RtransparentlyS 
allows both forms of communication.  However all that really has to be 
done is for the bridge to contain a small table of Ethernet protocol types 
that either should, or shouldnUt be translated in this manner.  Obviously 
the smaller the table, and the less translation done, the better the 
overall performance.  Any bridge between Ethernet and an 802 media which 
does not translate any OUI zero packets will prevent TCP/IP nodes (and any 
others using the same OUI convention) from communicating between the two 
media.  Any bridge between Ethernet and an 802 media which translates all 
OUI zero packets will prevent AppleTalk nodes (and any others with an OUI 
of zero who donUt expect translation) from communicating between the two 
media.  In both cases, routers can of course be set up to accomplish the 
communication.

A somewhat equivalent problem could exist if two bridges are used to 
connect two Ethernet/802.3 data links across an 802 backbone (say FDDI).  
In this case, some type of translation/encapsulation of Ethernet 
(non-802.3) packets must be performed to allow them to be passed across 
the 802 backbone. There are many ways to do this, one of which seems to be 
translating all Ethernet packets to OUI zero packets, shipping them across 
the backbone, and then converting them back.  This however does not work 
for any OUI zero packets which start out on the Ethernet/802.3 data link.  
Such packets will not be translated on the way into the backbone, but will 
be incorrectly translated before being delivered on the destination 
Ethernet.  Such packets should be forwared entirely without translation.

In terms of actual product implementations, unfortunately DEC is already 
beta-siting an Ethernet-to-FDDI bridge which translates all OUI zero 
packets, and thus does not work with AppleTalk Phase 2.  They are aware of 
this issue.  At the recent 802 meetings in Denver, it became clear that 
this type of translation is not part of th 802.1d (Mac Bridging) standard, 
but is something that many bridge manufacturers wish to include as a 
non-802-standard option with their products.  Most have said they will 
have some type of translation (or non-translation) table to insure it is 
possible to work with all known protocols.


John Veizades and Alan Oppenheimer
Apple Computer, Inc.
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 23:26:25 GMT
From:      mtxinu!rtech!wrs!daahoud!hwajin@ucbvax.Berkeley.EDU  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP checksums
beau@ultra.com (Beau James {Manager - SW Development - Ultra Networks}) writes:
>In <5@wotk.UUCP> root@wotk.UUCP (Superuser) writes:
>>Does anyone know how to enable UDP checksums on a Sun 360.
>	# adb -k /vmunix /dev/mem
>	...
>	udp_cksum/W 1		; Enables UDP checksums on the running kernel
>	udp_cksum?W 1		; Enables whenever this kernel is booted

udpcksum not udp_cksum


hwajin@daahoud.wrs.com
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 90 23:58:01 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   re: How to get RFC documents dealing with TCP-IPREAD/NEW/FOLLOWUP
In article <9007171708.AA04346@akamai.isi.edu>, jkrey@VENERA.ISI.EDU writes:
> 
> RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
> RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC).  Login
> with FTP, username ANONYMOUS and password GUEST.  The NIC also
> provides an automatic mail service for those sites which cannot use
> FTP.  Address the request to SERVICE@NIC.DDN.MIL and in the subject
> field of the message indicate the RFC number, as in "Subject: RFC
> nnnn".
> 
> RFCs can also be obtained via FTP from NIS.NSF.NET.  Using FTP, login
> with username ANONYMOUS and password GUEST; then connect to the RFC
> directory ("cd RFC").  The file name is of the form RFCnnnn.TXT-1
> (where "nnnn" refers to the number of the RFC).
 
Boy! Where do I get off complaining about postings from Jon P. and Joyce R.?
But this one is simply wrong. The NIC is a DECsystem 20 or some such and the
"cd RFC" drops you into the RFC subdirectory of the PS: device. And that's not
where you need to go.

The correct command is "cd RFC:". This gets you to the full RFC list. I'm not
too sure just what PS:<RFC> is. It has one RFC in it (RFC1005 and a README that
I have not read.

I also restate my request to use your real ident, not GUEST when using
anonymous logins. Some systems do look at the log and I consider it good
manners! A few systems really want guest, but they don't ask for your real
ident.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 01:43:19 GMT
From:      mogul@wrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: WIN/TCP Window Size

In article <12606340619.9.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
>Mumble.  Someone has to ask... Just WHY do you want to change the window
>size (and which one).  The window sizes offered by (and to) a system can
>be carefully thought out by the implementors, and can have serious non-linear
>effects on performance, thoughput, and even reliability of they are changed
>very much.  There are better ways to solve most problems than changing the
>window sizes...

One reason to change the window size is if the segment size changes,
perhaps as a result of Path MTU Discovery.  Van Jacobson has pointed out
that the flow-control window size had better be an exact multiple
of the segment size, or performance will suffer.

I've drafted a few paragraphs on this topic for inclusion in the
forthcoming RFC on Path MTU Discovery.  In fact, I invite people
to comment on their wording.

(The rest of the document is draft-ietf-mtudisc-pathmtu-01.txt at
the usual place.)

Thanks
-Jeff

    (To be inserted at the end of section 6.4, "TCP layer actions"):
    
    Modern TCP implementations incorporate ``congestion advoidance''
    and ``slow-start'' algorithms to improve performance@cite[Jacobson1988].
    Unlike a retransmission caused by a TCP retransmission timeout, a
    retransmission caused by a Datagram Too Big message should not
    change the congestion window.  It should, however, trigger the
    slow-start mechanism (i.e., only one segment should be retransmitted
    until acknowledgements begin to arrive again).

    TCP performance can be reduced if the sender's maximum window size
    is not an exact multiple of the segment size in use (this is not
    the congestion window size, which is always a multiple of the
    segment size).  In many system (such as those derived from 4.2BSD),
    the segment size is often set to 1024 octets, and the maximum
    window size (the ``send space'') is usually a multiple of 1024
    octets, so the proper relationship holds by default.  If PMTU
    Discovery is used, however, the segment size may not be a
    submultiple of the send space, and it may change during a
    connection; this means that the TCP layer may need to change the
    transmission window size when PMTU Discovery changes the PMTU
    value.  The maximum window size should be set to the greatest
    multiple of the segment size (PMTU - 40) that is less than or equal
    to the sender's buffer space size.
    
    PMTU Discovery does not affect the value sent in the TCP MSS option,
    because that value is used by the other end of the connection,
    which may be using an unrelated PMTU value.

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 02:38:52 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Zero manufacturer code in SNAP?

It should be noted in passing that following is in the Host Requirements
standard, RFC-1122:

]      2.3.3  Ethernet and IEEE 802 Encapsulation
]
]         The IP encapsulation for Ethernets is described in RFC-894
]         [LINK:3], while RFC-1042 [LINK:4] describes the IP
]         encapsulation for IEEE 802 networks.  RFC-1042 elaborates and
]         replaces the discussion in Section 3.4 of [INTRO:2].
]
]         Every Internet host connected to a 10Mbps Ethernet cable:
]
]         o    MUST be able to send and receive packets using RFC-894
]              encapsulation;
]
]         o    SHOULD be able to receive RFC-1042 packets, intermixed
]              with RFC-894 packets; and
]
]         o    MAY be able to send packets using RFC-1042 encapsulation.
]
]
]         An Internet host that implements sending both the RFC-894 and
]         the RFC-1042 encapsulations MUST provide a configuration switch
]         to select which is sent, and this switch MUST default to RFC-
]         894.


Consider the implications.  Every vendor must offer ethernet TCP/IP
encapsulation, and that must be the default.  Adding support for 802.3
(RFC-1042) is not required, and does not increase the number of compliant
machines with which an implementation can interoperate.  Historically,
there were very few machines that used only RFC-1042.  (I think HP
used SAP, but that BICC (?) in the U.K. used RFC-1042.)

Supporting both RFC-894 and RFC-1042 does not make an implementation
faster, but code is not bad.  The reduction of the MTU in RFC-1042 is
about 1%, which should translate into around 10KBytes/second of lost
through-put for machines that are currenting get 1MByte/sec with
user-process-to-user-process TCP/IP/Ethernet.

Thus, there are no (or very few and exceptional) business reasons for a
vendor to offer RFC-1042 support, or even to continue existing RFC-1042
support.

RFC-1103 and its pending successor are a different story.


Vernon Schryver
Silicon Graphics
vjs@sgi.com
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 03:16:11 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   re: How to get RFC documents dealing with TCP-IP
In article <1990Jul19.165801.1@rogue.llnl.gov>, oberman@rogue.llnl.gov writes:
> In article <9007171708.AA04346@akamai.isi.edu>, jkrey@VENERA.ISI.EDU writes:
>> 
>> RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
>> RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC).  Login

As several people have pointed out, I should learn to read before posting. The
posting was absolutely correct. I was confusing nic.ddn.mil with nis.nsf.net.
My humblest apologies to all involved.
 
 					R. Kevin Oberman
 					Lawrence Livermore National Laboratory
 					Internet: oberman@icdc.llnl.gov
    					(415) 422-6955
 
 Disclaimer: Don't take this too seriously. I just like to improve my typing
 and probably don't really know anything useful about anything.
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Jul 90 15:18:25 -0700
From:      "Philip Almquist" <almquist@jessica.stanford.edu>
To:        sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Zero manufacturer code in SNAP?
Vernon,
> Every vendor must offer ethernet TCP/IP encapsulation, and that must be
> the default.  Adding support for 802.3 (RFC-1042) is not required, and
> does not increase the number of compliant machines with which an
> implementation can interoperate.  Historically, there were very few
> machines that used only RFC-1042.
> ...
> Thus, there are no (or very few and exceptional) business reasons for a
> vendor to offer RFC-1042 support, or even to continue existing RFC-1042
> support.

	This is not ENTIRELY true.  A host which supports RFC-894 must
be able to receive RFC-1042 packets if it wants to be unconditionally
compliant with the Host Requirements RFCs.  Only the ability to send
RFC-1042 packets is truly optional.

	This topic was debated at some length by the authors of Host
Requirements.  The requirements were rather carefully chosen to allow
for a transition to RFC-1042 in the long run without breaking everything
in the short run.
							Philip
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Jul 90 15:50:17 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        tcp-ip@nic.ddn.mil
Subject:   Routing Loop
Is anyone familiar with the following nodes:  192.80.214.1 and 192.80.214.254?
An nslookup PTR query returns a non-existent domain error.  The nodes appear
to be between the College Park Md NSF backbone node and SURANET.

As of 1400 PDT the nodes were involved in a routing loop.  A traceroute from
our site to wraith.wtp.contel.com, issm.iss.contel.com, or sccgate.scc.com
our Rightist brethren would reach College Park and then bounce back and forth
between the two nodes.

Any information would be appreciated.

Merton

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 06:49:40 GMT
From:      mcsun!unido!gtc!pemstgt!tb@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Excelan Lan Workplace and Packet Drivers?
root@joymrmn.UUCP (Marcel D. Mongeon) writes:

>I have an Excelan 205T board in an SCO Xenix 386 machine
>supporting the Lan Workplace software.  The board is hooked
>up to a thinwire ethernet.  I have been trying (without
>any success) to get some DOS based machines talking to this
>board using other vendor's boards driven by appropriate
>packet drivers.  I try both NETBIOS and FTP style calls to
>the Excelan board and it doesn't respond.
	We have installed 205T and 3C503 in DOS,UNIX and XENIX-Systems
	All is working. On DOS we HAVE PC NFS and LAN WORKPLACE, on XENIX
	LAN-WORKPLACE and SCO XENIX NET, on UNIX SCO TCP/IP and SCO NFS.
	As I know, you can't do NETBIOS-calls form DOS without a NETBIOS
	emulation on XENIX. This is a part of XENIX NET.

>The Excelan board is receiveing the packets because any of
>the appropriate stat commands done before and after an
>attempted link indicates that the excelan received packets --
>it just didn't do anything with them!
	Do have edited the proper files: /etc/hosts on DOS and XENIX
	What products do have installed on DOS.


If you can mail me some more information, i will try to answer you question
in a better way.

best regards

Tillmann
-- 
Dipl.Ing. Tillmann Basien                Programmentwicklung fuer Microcomputer
Vaihinger Str.49, PostBox 810165		      +49-711-713047	FAX
7000 Stuttgart 80- West Germany                       +49-711-713045	PHONE
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Jul 90 14:04:33 -0400
From:      bzs@world.std.com (Barry Shein)
To:        zaphod.mps.ohio-state.edu!uwm.edu!srcsip!knowledge!pclark@tut.cis.ohio-state.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Beginner's info TCP & UDP

>Quick question:
>	Under what conditions would a programmer want to use a UDP connection
>	over a TCP connection? What does UDP give you that TCP doesn't, that
>	makes it worth losing (or implementing yourself) a reliable,
>	guaranteed delivery layer?
>
>	Pete Clark

I assume you mean UDP over IP, not over TCP, otherwise it's not a
quick question, it's a strange question and needs some clarification.

Consider the following situations:

1. I have designed an application which embeds ECC integers and
sequencing into its packets. It's mostly a one-way protocol (on
request blasts a lot of data), so asynchrony is not particularly
useful. The ECC allows the remote end to detect and correct one or two
bit errors without resend. I have determined (?) that 99.99% of all
errors are one or two bit (of course, sequence errors might require
entire resends, but I can handle that.)

Why would I want TCP to also check every packet and silently resend
when most of the time I can correct without resend?

2. I am sending an animation which consists of 1Kx1Kx8 bit frames over
the network. I do some rudimentary checking (sequencing etc.) but,
more importantly, need to (usually) keep up with 30-frames/second.

A few bits in error might mean the image on the screen is "smudged" in
some tiny area for 1/30th of a second (this assumes a network
connection with few errors, tho not zero errors.)

Is it worth waiting and having TCP resend those packets? Or just let
the screen update on the next 30th of a second which will probably fix
the image (that is, would anyone notice a few small xmit errors?)

3. I am blasting data similarly to (2) over ethernet. Ethernet
hardware does a CRC on the data although, again, doesn't guarantee
sequencing (packets might be lost entirely, but if they get there
they're correct.)

4. Finally, UDP/IP can be implemented on a machine with raw access to
a network device in a (longish) afternoon. I've done it (the 3B2/HP
UDP/IP/TFTP source that floats around was written by me from scratch
and put into production over a weekend.)

There is value in getting a few bits across as a bootstrap.

Caveat: It is a fallacy that because UDP is much simpler and lower
overhead that it is therefore inherently faster. For example, the
lockstep protocol of TFTP/UDP is usually much, much slower (an order
of magnitude) than a decent FTP/TCP. Asynchrony is much more important
than mere CPU cycles. Ask the right questions!

(note that in the examples above I haven't excluded asynchrony.)

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Friday, 20 July 1990 1:08pm ET
From:      "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  How to get RFC documents
R Kevin Oberman writes:
> Please be polite and enter your real ID if that's what is asked for.

I can't speak about NIC.DDN.MIL, but the other site Jon mentioned,
NIS.NSF.NET, *requires* the use of guest as a password for anonymous.
Otherwise, it won't let you on.  This is quite disconcerting for those
of us who may type ahead the anonymous login sequence.  Presumably the
IBM they use has !@#$% software that is not configurable.  It certainly
has a *terrible* implementation of TCP/IP.

Bill Simpson
  09998was@ibm.cl.msu.edu
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 12:26:58 GMT
From:      usc!samsung!munnari.oz.au!mel.dit.csiro.au!smart@ucsd.edu  (Robert Smart)
To:        tcp-ip@nic.ddn.mil
Subject:   Come on guys, we've got to improve e-mail
Some time in the later 70s I installed a mail system from NIH on a
DECsystem-10. It included all sorts of wonderful things: you could
tell if mail you had sent had been read, and you could recall mail
if it hadn't been read. It had the advantage of being a standalone
system mail package. [My boss got me to rip it out: electronic mail
was not a suitable activity for computers!]. The fact is that we 
haven't made a lot of progress.

Before the flood starts again on the desirability of the sender
knowing if the recipient has read a message: When a mail message
goes through a gateway to a mail system that does not support
read-receipt a message will go back to the sender saying "mail
has parsed to an MTA or UA that will not give a read receipt".
If the user chooses to configure his user agent to not give
read receipts then the sender will get the same message. You
can conceal your activities as much as you like.

To make mail work properly there has to be a User Agent to User 
Agent protocol. The user should be able to look at the mail he
has sent and see which items have been read. We are trying to
use mail to build protocols between people and the picture
currently looks like this:

       human - - - - - - - human
         |                   |
      user-agent         user-agent
         |                   |
        MTA - - - - - - - - MTA
         |                   |
       etc

The lack of a user-agent to user-agent protocol limits the sort
of protocols that humans can build with this tool. The options
are protocols of the "I hope you get this (but don't much care)"
type and ones where the humans have to try to do by hand things
that the UA could do for them (e.g. say "Please let me know when
you've read this").

Mail can disappear for a variety of reasons: disk crashes, software
problems or because the recipient doesn't check his mail box. The
effect of this is twofold: some rely on e-mail to a dangerous
extent; and most look for other mechanisms for important communication.

The second thing we need to do is allow mail messages to contain
non-text information: graphics and sound in a standard form; and
attached files which will only be meaningful to the sender and
recipient systems but which intermediate systems will allow to pass.

Minor things that would be nice include encryption and unforgeable
signatures.

There are two ways to go:

 1) Get X.400 working.

 2) Upgrade the RFC standards.

There are problems with X.400. Does it cover the ground? Does it in
fact allow me to send my Macwrite document to another Mac? The 
protocol has so many options that the chances of frequent interoperability
seem slight. Also X.400 is just the bones of a mail system. I have
yet to see a convincing description of how it will be administered.
Even when it works it seems almost impossible to make it user friendly.
And when it goes wrong it is a major headache. I have configured a
few X.400 systems but none recently. Perhaps all this is changing?

Conversely I really like RFC822 and SMTP. When things go wrong you
can poke you head in and have a look and easily understand what is
going on. It is really not hard to extend the RFCs to make a
proper mail system. As George Michaelson pointed out a while ago: all
we need is a few extra optional headers, allow lines starting with
a "." in the body of the text to introduce sections of binary data in
btoa format:

    .sound
    ...junky looking stuff...
    .end sound

Or something like that.

SMTP can handle the Telnet equivalent of will/won't do/don't by just
issuing new commands and seeing if the receiver understands them.

	MAIL From:<x@y.z>
	250 x@y.z ok
	RWRA To:<a@b.c>
[RWRA means RCPT with Read Acknowledge]
	500 Command unrecognized
	RCPT To:<a@b.c>
	250 a@b.c ok
	DATA
	...etc

Since the receiving MTA didn't know about read-return requirements
the sending MTA can no longer guarantee that a read-return will come
back, and so will send back a neutral acknowledgement at this point.
Though the final user agent may actually obey the Read-acknowledge:
header in the message.

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

So what should we do, 1 or 2? Well, this is the age of competition
(ask Mikhail Gorbachev) so lets do both, and may the best solution
win. Since X.400 is out of the control of sensible people, it is
important that the extensions to SMTP/RFC822 be done in such a way
as to maximize interoperability with X.400. We want gateways where
sound and pictures and attached files if possible will go across.

Alternatively if we are definitely going X.400 then I would like to
see a description of how we are going to administer the monster.

Bob Smart <smart@mel.dit.csiro.au> or <uunet!munnari!ditmela.oz.au!smart>
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 12:38:43 GMT
From:      usc!samsung!umich!pmsmam!wwm@ucsd.edu  (Bill Meahan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP on Packet Radio
In article <1990Jul19.101009.5902@hod.uit.no> tommy@sfd.uit.no (Tommy Johansen) writes:
>We are currently working with TCP/IP on Packet Radio. Our goal is to run 
>TCP/IP from one Ethernet to another with as high speed as possible. At the 
>moment we are able to communicate at 2400 baud. My questions are as follow:
>
>            Is it possible to run at 64 kb speed?
>            What kind of experience has bin ganed from simulare work? 
>            Who delivers HW and SW?
>            Is there anybody out there doing the same thing?
>
>I'm interesting in anything witch has to do with TCP/IP on Packet Radio.
>--
>| Tommy Johansen                        | E-mail: tommy@tommy.uit.no          |
>| University of Tromsoe,                | FAX   : +47 83 55418                |
>| N-9000 Tromsoe                        | Tlf. work: +47 83 55419             |
>| NORWAY                                | Tlf. priv: +47 83 73958             |

Try checking into rec.ham-radio.packet.  There is much discussion of various
high-speed transmission schemes.  Currently, there are good, working 56KB
speed schemes.  Some enterprising types have gotten 2Mb on microwave.
Our local Packet interest group is developing 9600b units based on available
FAX modems.

You might also contact bdale@col.hp.com - he REALLY has his finger on the
pulse of Packet hardware!


-- 
Bill Meahan  WA8TZG		uunet!mailrus!umich!pmsmam!wwm
I don't speak for Ford - the PR department does that!

Any attempt at wit is liable to offend _somebody_!
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 14:19:16 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Network Temperature Protocol


Background.

As you may know, the UK has been undergoing nothing but a heatwave the 
last few days.

Motivation.

As part of a distributed computing experiment, we are considering
setting up a Sun workstation, with a bi-metallic strip and small coil
tempearture device, and providing a network wide reading, combined
with time of day service and cartesian location data.

Deliverable.

The intent is to deploy such a service across the Internet as a way of
detecting optimal vacation sites over the coming years of weather
disruption whilst conventional forecast techniques may not suffice.

An rfc (request for centigrade) may be forthcoming shortly.

 jon

(but seriously ... :-)

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Jul 90 20:25:27 MDT
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  How to get RFC documents
> the IBM they use has !@#$% software that is not configurable.  It certainly
> has a *terrible* implementation of TCP/IP.

I haven't any kind words for them either.  It might be disconcerting for
you.  It just plain pisses me off!  I go to the trouble of identifying
myself and !@#$%.  Geez!, what's the use.  Oh well, the Internet is on
the way out,  OSI is on the way in.  I'll be dead.

pHil
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 15:45:33 GMT
From:      phri!roy@nyu.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  How to get RFC documents dealing with TCP-IP
In <1990Jul19.114801.1@amazon.llnl.gov> oberman@amazon.llnl.gov writes:
> For anonymous logins, one should follow the printed instructions and enter
> their username on their local system, not guest. [...]  be polite and
> enter your real ID if that's what is asked for. (And it almost always is.)

	My experience is that you don't get prompted for your real ID until
after it is too late.  Maybe it's just my ftp implementation (SunOS-3.5.2
and MtXinu 4.3BSD systems) but I get prompted for the username (i.e.
anonymous) and then the password, and only then do I get the line which
requests that I "send ident as password".  For example:

----------------
Script started on Fri Jul 20 11:37:58 1990
alanine> ftp uunet.uu.net
Connected to uunet.uu.net.
220 uunet FTP server (Version 5.99 Wed May 23 14:40:19 EDT 1990) ready.
Name (uunet.uu.net:(null)): anonymous
Password (uunet.uu.net:anonymous): <<I typed "guest" here>>
331 Guest login ok, send ident as password.
230 Guest login ok, access restrictions apply.
ftp> quit
221 Goodbye.
alanine> ^Dexit

script done on Fri Jul 20 11:38:16 1990
----------------
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Jul 90 15:19:16 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Cc:        discussion@cs.ucl.ac.uk
Subject:   Network Temperature Protocol

Background.

As you may know, the UK has been undergoing nothing but a heatwave the 
last few days.

Motivation.

As part of a distributed computing experiment, we are considering
setting up a Sun workstation, with a bi-metallic strip and small coil
tempearture device, and providing a network wide reading, combined
with time of day service and cartesian location data.

Deliverable.

The intent is to deploy such a service across the Internet as a way of
detecting optimal vacation sites over the coming years of weather
disruption whilst conventional forecast techniques may not suffice.

An rfc (request for centigrade) may be forthcoming shortly.

 jon

(but seriously ... :-)
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Jul 90 21:43:15 EDT
From:      louie@sayshell.umd.edu (Louis A. Mamakos)
To:        tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re: Network Temperature Protocol
In article <9007210040.AA28109@ucbvax.Berkeley.EDU> you write:

>As part of a distributed computing experiment, we are considering
>setting up a Sun workstation, with a bi-metallic strip and small coil
>tempearture device, and providing a network wide reading, combined
>with time of day service and cartesian location data.

Actually, the facilities for doing most of this are already available on
the internet.  If you run NTP (network TIME protocol) on a host, you can
certainly provide the time of day service.  To determine the temperature,
you need only look at the drift rate of the clock relative to the a 
reference clock which corrolates rather nicely to the temperature of the
crystal in the clock of your computer.  You'll find that its trivial to
see day/night variations of the clock and hot vs. cold days.  All you need
do now is calibrate the drift rate to the temperature.

I'm sure Dave Mill can describe the use of NTP as an earthquake predictor
in another message.  This would be another important factor in picking
a location for a holiday.

louie
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 17:49:16 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Come on guys, we've got to improve e-mail
In article <1990Jul20.122658.23729@mel.dit.csiro.au> smart@manta.mel.dit.csiro.au (Robert Smart) writes:
> 2) Upgrade the RFC standards.

A user agent with the desired features can easily and properly be
implemented as a layer on top of RFC822/SMTP.  There is no need to
change that which is not broken.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 18:05:30 GMT
From:      tep@tots.UUCP (Tom Perrine)
To:        comp.protocols.tcp-ip
Subject:   Re: Come on guys, we've got to improve e-mail

I couldn't agree more about the lack of progress in SMTP protocol
enhancements to handle such things as return-receipt, multi-media
mail, etc.

I used Multics systems in the mid 70s which had the return-receipt
feature, which could of course be disabled by the recipient.

Encryption standards and multi-media standards are appearing. I know
of RFC1040 (Privacy Enhancements for Internet Electronic Mail) and
RFC1049 (A Content-type header field for Internet Messages), but I
know of *no* fielded systems that support either.

I agree that there is no "official" UA <-> UA protocol, other than,
perhaps, that information which is encoded in the header fields.

You might want to check out any of the following newsgroups:

comp.mail.headers	Gatewayed from the Internet header-people list.
comp.mail.mh		The UCI version of the Rand Message Handling system.
comp.mail.misc		General discussions about computer mail.
comp.mail.multi-media	Multimedia Mail.

comp.protocols.iso.x400	X400 mail protocol discussions.  (Moderated)
comp.protocols.iso.x400.gateway	X400 mail gateway discussions.  (Moderated)

I worked on designing some extenstions to SMTP for use over
dial-lines, but never took it any further. I like the "RWRA" SMTP
extension, but I think most limitiations for multi-media are in the UA
side of things.

Perhaps we need to take this discussion to one of the above
newsgroups, or start a new mailing list, perhaps mail-modernization or
somesuch?

Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM
Logicon                                 |UUCP: nosc!hamachi!tots!tep
Tactical and Training Systems Division  |-or-  sun!suntan!tots!tep
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
Home of the _Tower Operator Training System_ as seen in the SunTech Journal.

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 18:31:49 GMT
From:      agate!shelby!portia.stanford.edu!jessica.stanford.edu!morgan@ucbvax.Berkeley.EDU  (RL "Bob" Morgan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Zero manufacturer code in SNAP?

Ah, well, now we're getting somewhere.

John and Alan write:

> The all-zeros "organizational unique identifier" (OUI) was not
> specifically intended to be used for translating Ethernet frames to
> 802.2/SNAP.  Its original intention was (and is) not completely clear;
> all that was generally agreed upon was:
> 
> (1) The low-order 16 bits of the SNAP protocol discriminator indicated an 
> Ethernet protocol type; and
> 
> (2) The format of the data part of the SNAP packet was the same as the 
> format of the data part of the Ethernet packet of this protocol type.
> 
> This "general agreement," as far as I know, was never written down.  
> AppleTalk Phase 2 and TCP/IP both adopted this convention.

Well, not exactly.  Normal AppleTalk Phase 2 (AT2) DDP datagrams are
encapsulated using an OUI of 080007, which I assume has been assigned
to Apple.  Only AT2 ARP frames use an OUI of zero.  (Both use the
Ethertype for the last two bytes.)  I'm sure there's a good
explanation for this, but I'll admit it puzzles me.

So, as we've observed, AT2 DDP frames travel across a pair of
Ethernet-to-FDDI bridges just fine, and are received properly by AT2
devices on the second Ethernet.  This works because the bridge sees
the non-zero OUI and simply leaves the frame untouched.

AT2 AARP frames fail, however.  Because the bridge assumes that any
zero-OUI frame on the FDDI was originally an Ethernet-format frame
that was translated to 802.2/SNAP, it retranslates such a frame back
to Ethernet format when it forwards it onto the Ethernet.  An AT2
station ignores an Ethernet-encapsulated AARP, since it's only looking
for 802.2/SNAP.

Now, as Vernon points out:

> It should be noted in passing that following is in the Host Requirements
> standard, RFC-1122:
> 
> ]      2.3.3  Ethernet and IEEE 802 Encapsulation
> ]      ...
> ]         Every Internet host connected to a 10Mbps Ethernet cable:
> ]
> ]         o    MUST be able to send and receive packets using RFC-894
> ]              encapsulation;
> ]
> ]         o    SHOULD be able to receive RFC-1042 packets, intermixed
> ]              with RFC-894 packets; and
> ]
> ]         o    MAY be able to send packets using RFC-1042 encapsulation.

This ensures that IP stations, even if they prefer RFC-1042 (SNAP with
zero OUI) format, will properly receive Ethernet format.  Of course,
as Vernon notes, it effectively prevents RFC-1042 from ever being the
preferred format.

John and Alan continue:

> Thus for a TCP/IP Ethernet node to communicate with a TCP/IP 802.2
> node (on token ring or FDDI, say), some type of packet translation
> must be performed, whereas for an AppleTalk Phase 2 Ethernet node to
> communicate with any other AppleTalk Phase 2 802.2 node (on Ethernet,
> token ring or FDDI) no such translation need occur (in fact, such
> translation MUST NOT occur).  This makes it somewhat difficult to
> build a bridge that "transparently" allows both forms of
> communication.  However all that really has to be done is for the
> bridge to contain a small table of Ethernet protocol types that either
> should, or shouldnUt be translated in this manner.  Obviously the
> smaller the table, and the less translation done, the better the
> overall performance.

The combination of AppleTalks Phase 1 and 2, however, presents a
sticky situation for a such a bridge, where even the translation-table
method won't work.  After translation into 802.2/SNAP, an AT1 AARP
frame is identical to an AT2 AARP frame (except for destination MAC
address).  If the bridge, while forwarding from the 802 medium to
Ethernet/802.3, translates a zero-OUI, Ethertype 80F3 frame to
Ethernet encapsulation, AT2 breaks.  If it leaves it unchanged, AT1
breaks.  The bridge could dig even further, of course, to determine
whether the destination MAC address is broadcast (AT1) or multicast
(AT2).

Apple could solve the problem by fiddling with AT2 to either:

1) make AT2 stations receive Ethernet-encapsulated AARPs, or

2) use the Apple OUI for AARPs as well as DDPs.

Or we could all resign ourselves to using routers to connect between
heterogeneous LANs, which is probably the moral of this whole story.

 - RL "Bob" Morgan
   Networking Systems
   Stanford
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 21:06:36 GMT
From:      ladcgw.ladc.bull.com!hermes!fmayhar@uunet.uu.net  (Frank Mayhar)
To:        tcp-ip@nic.ddn.mil
Subject:   Documentation for the BSD lpd protocol?
Does anyone know if this exists, and where it can be found?  We've tried the
RFCs and it's not there.  We have to source to lpr/lpd, but it would be nice if
we could get documentation for the protocol itself, since we want to support
it on a non-Unix platform.

Thanks in advance.
-- 
Frank Mayhar  fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
              Bull HN Information Systems Inc.  Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045    Phone:  (213) 216-6241
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 21:33:35 GMT
From:      usc!snorkelwacker!spdcc!eli@ucsd.edu  (Steve Elias)
To:        tcp-ip@nic.ddn.mil
Subject:   call fo discussion: comp.dcom.fax
this is a call for discussion for a newsgroup called "comp.dcom.fax",
or just comp.fax.  there is currently an "alt.fax" newsgroup, but it's
my humble homey opinion that fax technology is real enough and 
interesting enough to warrant a "real" technical newsgroup.  fax
technology involves modems, graphics, printing, bus interfaces,
serial port interfaces, email, and "fax over internet".  etcetera.
i think that comp.fax might be a better idea than comp.dcom.fax, 
since there are some fax issues which have zero to do with datacomm,
such as graphics-ish stuff like dithering, and tcp-ish stuff like 
email2fax and fax2email.

perhaps these issues can be discussed individually in the "most relevant"
newsgroup for each area listed above.  and perhaps the alt.fax group
does have enough "propagation" such that it will do the job.  but if
a comp.fax group would include more people in the discussions, i think
it's worth considering.

what do you think?  please follow up to news.groups.

also, feel free to send junk (or funk) faxes to 
508 294 0101 or 508 294 7447.






-- 
/eli
eli@spdcc.com
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Jul 90 03:45:10 EDT
From:      R17G000 <R17G@UNB.CA>
To:        <TCP-IP@NIC.DDN.MIL>
Cc:        Aziz Zoman <R17G@UNB.CA>
Subject:   Unix POP3 mail client?
> Any pointers to source for a BSD Unix POP3 mail client?  I've found several
> servers, but no clients.		  - Brian

Clemson university has developed a POP3 server and client. The POP3
client implementation is for MS-DOS. They are available at:
      eng.clemson.edu


---------------------------------------------------------------+
Abdulaziz Al-Zoman             |          R17G@UNB             |
School of Computer Science     |            -or-               |
University of New Brunswick    |          r17g@unb.ca          |
F'ton, N.B                     |            -or-               |
CANADA   E3B 5A3               |          r17g@unb.bitnet      |
---------------------------------------------------------------+
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 90 23:59:37 GMT
From:      oliveb!orc!inews!cadev5!swilhel@apple.com  (Spence Wilhelm)
To:        tcp-ip@nic.ddn.mil
Subject:   Multinet TCP/IP
Has anyone had experience with Multinet TCP/IP for VAX VMS?
I would appreciate any information you have regarding their
support and service.

Spence Wilhelm				Intel Corporation
swilhel@cadev4.intel.com		Chandler, Arizona
KB5CYX					(602)554-5050

"Possibly the horror that Zaphod experienced at the prospect
 of being reunited with his deceased relatives led on to the
 thought that they might just feel the same way about him..."
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 90 00:25:32 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Documentation for the BSD lpd protocol?
In article <1990Jul20.210636.14924@ladc.bull.com> fmayhar@hermes.ladc.bull.com (Frank Mayhar) writes:

   Does anyone know if this exists, and where it can be found?  We've
   tried the RFCs and it's not there.  We have to source to lpr/lpd,
   but it would be nice if we could get documentation for the protocol
   itself, since we want to support it on a non-Unix platform.

sun.soe.clarkson.edu:/pub/ka9q/lprspec.txt

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
In Communism's central planning, citizens are told "you will make widgets".
In Capitalism's advertising, citizens are told "you will buy widgets".
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 90 02:15:25 GMT
From:      09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
To:        comp.protocols.tcp-ip
Subject:   Re:  How to get RFC documents

R Kevin Oberman writes:
> Please be polite and enter your real ID if that's what is asked for.

I can't speak about NIC.DDN.MIL, but the other site Jon mentioned,
NIS.NSF.NET, *requires* the use of guest as a password for anonymous.
Otherwise, it won't let you on.  This is quite disconcerting for those
of us who may type ahead the anonymous login sequence.  Presumably the
IBM they use has !@#$% software that is not configurable.  It certainly
has a *terrible* implementation of TCP/IP.

Bill Simpson
  09998was@ibm.cl.msu.edu

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 90 03:52:21 GMT
From:      ss01!jsm@princeton.edu  (John Scott McCauley Jr.)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
In article <9007210040.AA28109@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
>
>As part of a distributed computing experiment, we are considering
>setting up a Sun workstation, with a bi-metallic strip and small coil
>tempearture device, and providing a network wide reading, combined
>with time of day service and cartesian location data.
>

What ever happened to 'finger weather@hermes.ai.mit.edu'?
This reported the wind speed and temperature at the top of Tech^2,
at MIT. There was also 'finger coke@a.cmu.edu' which reported the
status of a coke machine at CMU.

	Scott

P.S. Don't come here -- some things here are hotter than 30 keV.
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Jul 1990 08:39-EDT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        tcp-ip@nic.ddn.mil
Cc:        Eddie.Caplan@CS.CMU.EDU
Subject:   Re: interesting uses of networking
The old 'coke' program that once ran in our department has been
resurvived and extended.  Its major lack in functionality is now 
covered, and the program appropriately renamed "jf" (junk food).
The man pages for jf and xmnm are included.
Enquiries about this important progress of the Computer Science
field should be directed to eddie.
sandro-
-----------------------------------------------------------------------------



JF(6/22/90)         UNIX Programmer's Manual          JF(6/22/90)



NAME
     jf - Inquire about availability of junk foods in CMU CS
     vending machines.

SYNOPSIS
     jf [coke | mnm | mm ] [-reset]

DESCRIPTION
     jf inquires about the availability of Coke/Diet-Coke and
     M&Ms in the CMU CS vending area to save addicts an abortive
     trip from their distant offices.

     With no argument or with single argument coke jf gives the
     status of the buttons of 16oz bottles in the CMU CS Coke
     machine.  With argument mnm or mm it will give an estimate
     of the number of servings of M&Ms left in the vending
     machine.

     Providing an argument to identify the machine and the argu-
     ment -reset allows the vending machine fillers to inform the
     server when the machines have been refilled.  This is
     currently applicable only to the M&M machine because the
     Coke interface is essentially self-monitoring.  Proper
     credentials are requested before a reset may be performed.


BUGS
     As of 22-June-90, only the M&M interface is working.  The
     Coke interface is still being prepared.


SEE ALSO
     xmnm(1)


HISTORY
     22-Jun-90  eddie caplan (egc) at Carnegie Mellon University
          Updated man entry to reflect the new Coke machine con-
          figuration.  Added BUGS section while the Coke inter-
          face is down.

     29-Oct-85  Ivor Durham (id) at Carnegie Mellon University
          Created man entry. Client and server software by David
          Nichols with contributions from Ivor Durham.  Coke
          machine interface by John Zsarnay and M&M machine
          interface by Mark Zaremsky.
-----------------------------------------------------------------------------



XMNM(6/22/90)       UNIX Programmer's Manual        XMNM(6/22/90)



NAME
     xmnm - X11 program to monitor the availability of M&Ms.

SYNOPSIS
     xmnm [-update <rate>] [-shape | -noshape] [X11 switches]

DESCRIPTION
     Using an X11 window, xmnm graphically and continuously
     inquires about the availability of M&Ms in the CMU CS vend-
     ing area to save addicts an abortive trip from their distant
     offices.

     With no -update argument xmnm will check the status of the
     M&M machine every 1200 seconds (20 minutes).  By providing
     the -update argument, users can cause the status to be
     checked less or more frequently.  To keep the junk food
     server from becoming flooded with status requests, xmnm
     enforces a minimum sleeptime of 60 seconds.

     The -shape and -noshape arguments indicate whether the X
     window should take on the form of the M&M machine.  By
     default, shaping will not be done.


COMMANDS
     Clicking any of the mouse buttons in the M&M window will
     cause an update to occur.  That is, the junk food server
     will be queried.


BUGS
     Shaping just doesn't work sometimes, even though the
     software thinks it can be done.  Different window managers,
     mismatched versions of X, etc. can all contribute to the
     problem.


SEE ALSO
     jf(1), X(1)


HISTORY
      9-Jul-90  eddie caplan (egc) at Carnegie Mellon University
          Created man entry.
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Jul 90 13:20:14 PDT
From:      earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
To:        beau@Ultra.COM, comp.protocols.tcp-ip
Cc:        tcp-ip@nic.DDN.MIL
Subject:   Re: UDP checksums
In comp.protocols.tcp-ip article <1990Jul17.003242.1556@ultra.com> you write:
>In <5@wotk.UUCP> root@wotk.UUCP (Superuser) writes:
>>Does anyone know how to enable UDP checksums on a Sun 360.
>
>	# adb -k /vmunix /dev/mem
>	...
>	udp_cksum/W 1		; Enables UDP checksums on the running kernel
>	udp_cksum?W 1		; Enables whenever this kernel is booted

Careful Beau.  This is true for SunOS 4.1, but for SunOS 4.0.3 and earlier
SunOS releases, the variable is "udpcksum" (no helpful underscore (^: )

Also, you need to say "adb -w -k /vmunix /dev/mem" or else your attempts to
write the new values will be somewhat futile ... (^:

--

-- 
	Greg Earle			| "This is Kraft.  It uses a blue box.
	Sun Microsystems, Inc.		|  This is Stouffer's.  It uses red.
	earle@poseur.JPL.NASA.GOV	|  The choice is yours."
	earle@Sun.COM			|  Pretty damn convincing argument, eh?
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 90 12:39:00 GMT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: interesting uses of networking

The old 'coke' program that once ran in our department has been
resurvived and extended.  Its major lack in functionality is now 
covered, and the program appropriately renamed "jf" (junk food).
The man pages for jf and xmnm are included.
Enquiries about this important progress of the Computer Science
field should be directed to eddie.
sandro-
-----------------------------------------------------------------------------



JF(6/22/90)         UNIX Programmer's Manual          JF(6/22/90)



NAME
     jf - Inquire about availability of junk foods in CMU CS
     vending machines.

SYNOPSIS
     jf [coke | mnm | mm ] [-reset]

DESCRIPTION
     jf inquires about the availability of Coke/Diet-Coke and
     M&Ms in the CMU CS vending area to save addicts an abortive
     trip from their distant offices.

     With no argument or with single argument coke jf gives the
     status of the buttons of 16oz bottles in the CMU CS Coke
     machine.  With argument mnm or mm it will give an estimate
     of the number of servings of M&Ms left in the vending
     machine.

     Providing an argument to identify the machine and the argu-
     ment -reset allows the vending machine fillers to inform the
     server when the machines have been refilled.  This is
     currently applicable only to the M&M machine because the
     Coke interface is essentially self-monitoring.  Proper
     credentials are requested before a reset may be performed.


BUGS
     As of 22-June-90, only the M&M interface is working.  The
     Coke interface is still being prepared.


SEE ALSO
     xmnm(1)


HISTORY
     22-Jun-90  eddie caplan (egc) at Carnegie Mellon University
          Updated man entry to reflect the new Coke machine con-
          figuration.  Added BUGS section while the Coke inter-
          face is down.

     29-Oct-85  Ivor Durham (id) at Carnegie Mellon University
          Created man entry. Client and server software by David
          Nichols with contributions from Ivor Durham.  Coke
          machine interface by John Zsarnay and M&M machine
          interface by Mark Zaremsky.
-----------------------------------------------------------------------------



XMNM(6/22/90)       UNIX Programmer's Manual        XMNM(6/22/90)



NAME
     xmnm - X11 program to monitor the availability of M&Ms.

SYNOPSIS
     xmnm [-update <rate>] [-shape | -noshape] [X11 switches]

DESCRIPTION
     Using an X11 window, xmnm graphically and continuously
     inquires about the availability of M&Ms in the CMU CS vend-
     ing area to save addicts an abortive trip from their distant
     offices.

     With no -update argument xmnm will check the status of the
     M&M machine every 1200 seconds (20 minutes).  By providing
     the -update argument, users can cause the status to be
     checked less or more frequently.  To keep the junk food
     server from becoming flooded with status requests, xmnm
     enforces a minimum sleeptime of 60 seconds.

     The -shape and -noshape arguments indicate whether the X
     window should take on the form of the M&M machine.  By
     default, shaping will not be done.


COMMANDS
     Clicking any of the mouse buttons in the M&M window will
     cause an update to occur.  That is, the junk food server
     will be queried.


BUGS
     Shaping just doesn't work sometimes, even though the
     software thinks it can be done.  Different window managers,
     mismatched versions of X, etc. can all contribute to the
     problem.


SEE ALSO
     jf(1), X(1)


HISTORY
      9-Jul-90  eddie caplan (egc) at Carnegie Mellon University
          Created man entry.

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 90 17:33:33 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  How to get RFC documents dealing with TCP-IP
>	My experience is that you don't get prompted for your real ID until
>after it is too late.  Maybe it's just my ftp implementation (SunOS-3.5.2
>and MtXinu 4.3BSD systems)

I think it is.  I don't know where the problem exists, but I seem to
remember seeing this start working more correctly, perhaps correlated
with a switch from a 4.2BSD-flavored implementation to a 4.3BSD-flavored
implementation.

Of course, if the implementations are reasonably vanilla 4.xBSD ones,
they don't do anything with the identification anyway....
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 90 18:38:44 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Routing Loop
In article <9007202250.AA03920@WLV.IMSD.CONTEL.COM>, mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
> Is anyone familiar with the following nodes:  192.80.214.1 and 192.80.214.254?
> An nslookup PTR query returns a non-existent domain error.  The nodes appear
> to be between the College Park Md NSF backbone node and SURANET.
> 
> As of 1400 PDT the nodes were involved in a routing loop.  A traceroute from
> our site to wraith.wtp.contel.com, issm.iss.contel.com, or sccgate.scc.com
> our Rightist brethren would reach College Park and then bounce back and forth
> between the two nodes.

Somebody should be a bit embarassed by this. 192.80.214 is a class-c network at
FIX-East, the government "meeting the the nets" at SURANET offices near UMD.

I can't speak for the cause of the loop, but it explains some problems I've
been seeing of late in getting to some SE US sites. And the lack of inverse
name entries is inexcusable unless there is some technical reason which I can't
fathom.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Jul 90 06:21:15 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        tcp-ip@nic.ddn.mil, ucrmath!spahn!stebbins@ucsd.edu
Cc:        stebbins@137.67.5.1
Subject:   Re:  Possible routing problem.
John:

It appears that the Sun system (ucrmath.ucr.edu) requires you to provide a
<CR> or two before it provides the login in prompt.  At least its required
when connecting from a 4.3BSD system.

Merton
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 90 01:33:08 GMT
From:      ucrmath!spahn!stebbins@ucsd.edu  (john stebbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Possible routing problem.
I just installed WIN/TCP 5.1 and am having a problem getting to one
particular node on the inet.  I've tried several other nodes and have
been successful on all of them.  Here's the particulars.  Our node accesses
the outside world through a gateway.  I have run route:

route add default <gateway> 1

That seems to get me everywhere but where I want to go.  I'm trying to 
reach ucrmath.ucr.edu (192.31.146.1).  It uses a gateway at ucsd.edu
(128.54.16.1).  What I get when I try to telnet in is:

Connected to 192.31.146.1
escape sequence is ^]


Then no login prompt.  It just sits there until my end times out.
I believe that the ucrmath end of things is functioning properly
because other people I know say that they have had no problem using
it.  If it is a routing problem, the next question is, is there
some list of routes available somewhere so that I can do this once
and be done with it forever?  Is there some other piece of software
I should be running that takes care of this problem for me?
The extent of my knowledge is only what I've been able to cram into
my head in the last 3 days, so assume I'm a novice and explain things
carefully if you respond to this.  Thanks in advance.

John Stebbins
stebbins@ucrmath.ucr.edu (school)
stebbins@137.67.5.1      (work {this is where I am most of the time})
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 90 06:43:37 GMT
From:      pacbell.com!tandem!moe!kevinr@ucsd.edu  (Kevin J. Rowett)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP on Packet Radio

In article <1990Jul20.123843.11703@pmsmam.uucp>, wwm@pmsmam.uucp (Bill
Meahan) writes:
|> speed schemes.  Some enterprising types have gotten 2Mb on microwave.

Someone Ring?

N6RCE
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Jul 90 13:09:10 GMT
From:      Mills@udel.edu
To:        Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Cc:        tcp-ip@nic.ddn.mil, discussion@cs.ucl.ac.uk
Subject:   Re:  Network Temperature Protocol
jon,

You don't need the bimetallic strip, just use the frequency-compensation
variable maintained by the Network Termperature Protocol. Of course, you
will need to calibrate your individual workstation quartz oscillator
against temperature, which you should insist be included in the specifications
of the workstation. With the local-clock model defined in N Time P Version 3,
the coefficient of temperature shoulc be in the order of 2500 per degree C.
Dennis Ferguson has already calibrated his workstation, which apparently is
not environmentally controlled. That gives you Ontario. You will need other
volunteers who agree to chime NTP and operate their workstation in ambient
environmental conditions.

We should expect objections and very little data from McMurdo Station. Heck,
you can expect objections from Delaware.

Dave
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Jul 90 17:59:36 GMT
From:      Mills@udel.edu
To:        louie@sayshell.umd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Network Temperature Protocol
Folks,

Louie refers to an incident where an NTP primary time server, perched almost
atop the Loma Pietra fault, mysteriously abandonded chime a couple of minutes
BEFORE the recent quake. We were tempted to investigate application of NTP
as earthquake predictor, until we learned that a fortuitous power failure
within BARRNET happened to quench its chime. Now, we are concentrating on
the nature of that precipitous failure as a possible earthwuake predictor.
Meanwhile, on the night of the quake, NTP turned out to be a useful monitoring
tool and provided much comfort that at least computers in the area, much less
people, were safe and that circuits out the Pacific were still operation.
Actually, what that was doing was confirming that the NASA Ames massive
single point of failure was still up. A UPS failure there later in the
evening conked out the entire Pacific.

Dave
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 90 18:23:43 GMT
From:      ucrmath!gibson!stebbins@ucsd.edu  (john stebbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Possible routing problem.
In article <9007221321.AA06463@WLV.IMSD.CONTEL.COM>,
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
|> John:
|> 
|> It appears that the Sun system (ucrmath.ucr.edu) requires you to provide a
|> <CR> or two before it provides the login in prompt.  At least its required
|> when connecting from a 4.3BSD system.
|> 
|> Merton

I tried the above and still got no response.  I did try this before, but I
thought I'd recheck since someone else thought of it too.  Thanks for the
effort.

John stebbins
stebbins@ucrmath.ucr.edu (school)
stebbins@137.67.5.1      (work)
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 90 20:17:45 GMT
From:      rothstein@NUTMEG.Enet.DEC.com (Lee Rothstein, 603-884-0039)
To:        alt.fax,comp.protocols.tcp-ip
Subject:   Re: fax relaying protocols

In article <3410@ursa-major.SPDCC.COM>, eli@spdcc.COM (Steve
Elias) writes...

> sam@ucbvax.BERKELEY.EDU (Sam Leffler) writes:
 
>>Are there any standards (ad hoc or otherwise) for the protocols that
>>vendors use to implement relaying?  By relaying, I mean the ability
>>to transmit a fax to a machine that then resends it to one or more
>>destinations.  This is done to cut down on phone costs; i.e. make one
>>long distance phone call to a machine that then relays the document
>>with local calls.

..
>i'm not even sure which parts of fax gatewaying or fax "repeating"
>would warrant standardization.  perhaps IETF ought to discuss this issue...

At the risk of revealing that I haven't understood much prior
discussion both in alt.fax and elsewhere in the industry, I
believe that the entire point of Group IV facsimile is to allow
the use of store and forward computer networks.  Now, this may
not be exactly what Sam Leffler had in mind, but it's a starting
point.

Recently there has been another copntribution to store and
forward facsimile.  The X.400 Application Programming Interface
Association (XAPIA) has issued standards for gateway interfaces
for both Group III and Group IV facsimile devices.  A gateway
interface spec implies interfacing facsimile devices to the MTA
(message transport agent).  XAPIA is supported by most of the
major email vendors: Digital, Retix, AT&T, Telemail ...  X/OPEN
has also agreed to mutually support the XAPIA standards.

More recently, I read a paper by a Japanese company (Fujitsu?)
in which they deal with facsimile devices as yet another type of
desktop device requiring interface to the UA (user agent) of an
X.400 MHS (message handling system).

The TCP/IP folk, as evidenced by recent disdcussion in alt.fax,
are also working on a standrad for interface of fax to email.

+---------------------------------------------------------+
| Lee Rothstein * UUCP: {purdue,ucbvax,hplabs,labrea,sun, |
|  pyramid,gryphon,angelo}!decwrl!nutmeg.dec.com!rothstein|
|   * Arpa/Domain Address: rothstein@nutmeg.enet.dec.com  |
+---------------------------------------------------------+

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 90 20:55:06 GMT
From:      dino!cs.iastate.edu!hascall@uunet.uu.net  (John Hascall)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet options XDISPLOC & NAWS (& #34)

SYN:

   I've just finished adding support for the TELNET options XDISPLOC
(X Display Location - RFC1096) and NAWS (Window Size - RFC 1073) to our
telnet/telnetd (for DECstations/Ultrix 3.1) and was wondering if anyone
else implements these options (there seem to be no examples on campus).
 
   Also, I couldn't find any mention of what telnet option #34 is, was
this number just skipped or what?
 
   Also, I was curious about just which options *are* common?
 
      Binary, echo, and sga?  Ttype?  Others? 
      
 
John Hascall
john@iastate.edu  |  hascall@atanasoff.cs.iastate.edu
FIN
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 04:55:40 EDT
From:      oleary@umd5.umd.edu (dave o'leary)
To:        tcp-ip@nic.ddn.mil
Subject:   Status of FIX-East/SURAnet move/Contel routing loop, etc.


Hi everybody.

Here's the scoop on the reported problems.  I think it is fixed, if it
isn't please let me know by dropping a note to ops@noc.sura.net or calling
us at our new network operations center, (301)982-3214.  Our move is 
basically completed now.  It didn't go as smoothly as we had hoped, but
it is almost over now anyway.  Sorry about any problems that were 
encountered during the last two weeks due to the move.  If you want to 
know the status of FIX East drop me a note.


## From: oberman@rogue.llnl.gov
## Subject: Re: Routing Loop
## Date: 21 Jul 90 18:38:44 GMT
## Sender: usenet@lll-winken.LLNL.GOV
## Organization: Lawrence Livermore National Laboratory
## 
## In article <9007202250.AA03920@WLV.IMSD.CONTEL.COM>, mcc@WLV.IMSD.CONTEL.COM
## (Merton Campbell Crockett) writes:
## > Is anyone familiar with the following nodes:  192.80.214.1 and 
## > 192.80.214.254?

Familiar?  Well, I know what machines answer those addresses anyway.
192.80.214.254 is the new address of the NSS on the FIX ethernet.
192.80.214.1 is a Proteon P4200 connecting into SURAnet.

## > An nslookup PTR query returns a non-existent domain error.  The nodes 
## > appear to be between the College Park Md NSF backbone node and SURANET.
## > 
## > As of 1400 PDT the nodes were involved in a routing loop.  A traceroute 
## > from our site to wraith.wtp.contel.com, issm.iss.contel.com, or 
## > sccgate.scc.com our Rightist brethren would reach College Park and then 
## > bounce back and forth between the two nodes.

The T1 from our NOC to Contel was cutover to the new site Friday afternoon,
and there were lots-o-bit errors.  It took a while to get it cleaned up
but it should be working and stable since early this morning our time.
I expect the route was flapping quite a bit, and slow EGP time outs,
and default routing, and all that stuff...well, routing loops happen.
Many thanks to Bob Enger and Mike Powell at Contel for their help and 
patience Friday night.  

## 
## Somebody should be a bit embarassed by this. 192.80.214 is a class-c 
## network at FIX-East, the government "meeting the the nets" at SURANET 
## offices near UMD.
## 
## I can't speak for the cause of the loop, but it explains some problems I've
## been seeing of late in getting to some SE US sites. And the lack of inverse
## name entries is inexcusable unless there is some technical reason which I 
## can't fathom.

The lack of reverse DNS was, pure and simply due to my lack of
applying for the domain.  Ths oversight has been corrected and the
servers should be working Real Soon Now.  Again, we are very sorry 
to those individuals who were inconvenienced during our move.  

## 					R. Kevin Oberman
## 					Lawrence Livermore National Laboratory
## 					Internet: oberman@icdc.llnl.gov
##    					(415) 422-6955
## 
## Disclaimer: Don't take this too seriously. I just like to improve my typing
## and probably don't really know anything useful about anything.

Something that distressed me during the cutover was watching the FIX
ethernet and seeing some hard core pinging going on - hundreds and
thousands of pings to nodes that were unreachable (no echo replies...)
from all over the place.  Throughout much of last week during the
cutover we were suffering from severe congestion on links between our
old and new offices.  To these irresponsible pingers (probably not
Kevin or MCC): I'm sure SURAnet's customers appreciated your
"troubleshooting" of our network during this time of scarce bandwidth.
Please be considerate in the future.  Run abusive throughput tests
only at night, if at all.

Thanks,

						dave o'leary
						SURAnet NOC Manager

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 90 02:33:26 GMT
From:      rbn@umd5.umd.edu  (Ron Natalie)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Possible routing problem.
This is probably one of those implementations that insists on looking
up you IP address and resolving it to a name before going any farther.
You're new machine probably is not in the IN-ADDR domain tree or the
servers are placed such that the name is not easily resolvable.
It just wastes time trying to figure it out.

-Ron
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 09:21:18 -0400
From:      bdr@ifs.umich.edu
To:        tcp-ip@nic.ddn.mil
Subject:   unsubscribe
please remove me from this list.   

thanks
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 10:03:31 PDT
From:      postel@venera.isi.edu
To:        dino!cs.iastate.edu!hascall@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Telnet options XDISPLOC & NAWS (& #34)

See page 51 of rfc-1060.

--jon.
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 11:19:57 -0400 (EDT)
From:      Craig_Everhart@transarc.com
To:        tcp-ip@nic.ddn.mil, smart@mel.dit.csiro.au (Robert Smart)
Cc:        nsb@thumper.bellcore.com
Subject:   Re: Come on guys, we've got to improve e-mail
For years I've been using an RFC{821,822}-compliant Internet mail system
that does almost all of what you suggest.

Check out RFC 1049 and its commentators.

Get yourself an Andrew source distribution from the X.V11R4
distribution.  There's a mail system that supports automatic
confirmation requests from users, among other things.  Its design
sidesteps privacy issues, since return-receipt notices go out only after
explicit confirmation with the receiving human user, and it's understood
that you don't get a NAK from any transport agent.

The Andrew mail stuff uses altered content-type information to embed any
ATK (Andrew ToolKit) object, presently including raster and line
graphics, line animations, styled and marked-up text, simple other-file
references, and so forth.

Soapbox aside, I think there's a lot of current work on improving e-mail
services (PEM, for example) that you're simply ignoring.

		Craig
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 08:42:42 EDT
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        J.Crowcroft@CS.UCL.AC.UK, Mills@LOUIE.UDEL.EDU
Cc:        discussion@CS.UCL.AC.UK, tcp-ip@NIC.DDN.MIL
Subject:   Re:  Network Temperature Protocol
 > From tcp-ip-RELAY@NIC.DDN.MIL Mon Jul 23 07:55:00 1990
 > From: Mills@udel.edu
 > To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
 > Cc: tcp-ip@nic.ddn.mil, discussion@cs.ucl.ac.uk
 > Subject:  Re:  Network Temperature Protocol
 > 
 > jon,
 > <stuff deleted>
 >
 > You will need other
 > volunteers who agree to chime NTP and operate their workstation in ambient
 > environmental conditions.
 > 
 > We should expect objections and very little data from McMurdo Station. Heck,
 > you can expect objections from Delaware.
 > 
 > Dave
 > 
Dave,

I'm afraid that your scheme probably won't work in New England (about 20 Miles
West of Boston) in the summer. The machines would need to be sealed against
humidity and other gunk in the "Ambient Environment" (I wonder what ozone, water, and
various unburned and partially burned hydrocarbons would do to the insides of
a Sparcstation?:-(. You would then have to pump cooled air into the machine so
that it doesn't melt from the heat, defeating the whole purpose of the scheme.

Of course, even if the machine could stand the outside, I doubt that the person
sitting at the keyboard could - unless s/he is a chain-smoking sauna freak.

Air Conditioning-ly Yours
Frank Kastenholz
Racal Interlan

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 12:08:48 PDT
From:      postel@venera.isi.edu
To:        CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu
Cc:        TCP-IP@nic.ddn.mil
Subject:   Is underscore legal in the local-part of an address?


Hi.

You are right, he is wrong.

--jon.
----- Begin Included Message -----
Date: Mon, 23 Jul 90 10:38 CDT
From: Michael Califf <CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu>
Subject: Is underscore legal in the local-part of an address?
To: TCP-IP@NIC.DDN.MIL

Sorry about posting here, feel free to aim me at a better list...

At least one of the INTERBIT (Internet-to-BITNET) gateways is
rejecting addresses which contain an underscore.  The postmaster
at the gateway says that this is because his software correctly
implements RFC821 which restricts addresses to letters, numbers,
and hyphens.

I have checked the RFC and it seems to be a little less
restrictive than that.  Have I missed something?

Thanks for any help/pointers,

Mike Califf                    (POSTMAST[ER])
Communications Software Coord  Internet: califfm@baylor.edu
Baylor University C.C.I.S.     Bitnet:   CALIFFM@BAYLOR


----- End Included Message -----

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 10:38 CDT
From:      Michael Califf <CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Is underscore legal in the local-part of an address?
Sorry about posting here, feel free to aim me at a better list...

At least one of the INTERBIT (Internet-to-BITNET) gateways is
rejecting addresses which contain an underscore.  The postmaster
at the gateway says that this is because his software correctly
implements RFC821 which restricts addresses to letters, numbers,
and hyphens.

I have checked the RFC and it seems to be a little less
restrictive than that.  Have I missed something?

Thanks for any help/pointers,

Mike Califf                    (POSTMAST[ER])
Communications Software Coord  Internet: califfm@baylor.edu
Baylor University C.C.I.S.     Bitnet:   CALIFFM@BAYLOR
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 09:55:14 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        bzs@world.std.com (Barry Shein)
Cc:        tcp-ip@nic.ddn.mil, zaphod.mps.ohio-state.edu!uwm.edu!srcsip!knowledge!pclark@tut.cis.ohio-state.edu
Subject:   Re: Beginner's info TCP & UDP
One point I would add, Barry: You (or another ranking net.guru) would
be quite capable of recognizing a special case of the sort you posit,
and using UDP appropriately.  However, you might miss the telltale
glint in your customer's eyes when you told him "alternative X can be
done in half the time, but it restricts the product to single
Ethernets".  The consequences of trying to hack a 'one-cable' design
into a 'coast-to-coast' application are painful to the whole network.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 13:02:07 PDT
From:      postel@venera.isi.edu
To:        CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Is underscore legal in the local-part of an address?
Oh.

In that case, you are wrong, and he is right.

--jon.

----- Begin Included Message -----
Date: Mon, 23 Jul 90 11:19 CDT
From: Michael Califf <CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu>
Subject: Re: Is underscore legal in the local-part of an address?
To: TCP-IP@NIC.DDN.MIL

Don't Panic -

It turns out that the INTERBIT site which was rejecting the messages
is rejecting them based on the (illegal) underscore in the domain part
of the address, NOT the (legal) underscore in the local-part.

I am taking measures locally to remove/replace the underscores from
the offending node names.

That'll teach me to O.K. node names before fully parsing the RFC's :-)

Sorry about that,

Mike Califf                    (POSTMAST[ER])
Communications Software Coord  Internet: califfm@baylor.edu
Baylor University C.C.I.S.     Bitnet:   CALIFFM@BAYLOR
----- End Included Message -----

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 11:19 CDT
From:      Michael Califf <CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Is underscore legal in the local-part of an address?
Don't Panic -

It turns out that the INTERBIT site which was rejecting the messages
is rejecting them based on the (illegal) underscore in the domain part
of the address, NOT the (legal) underscore in the local-part.

I am taking measures locally to remove/replace the underscores from
the offending node names.

That'll teach me to O.K. node names before fully parsing the RFC's :-)

Sorry about that,

Mike Califf                    (POSTMAST[ER])
Communications Software Coord  Internet: califfm@baylor.edu
Baylor University C.C.I.S.     Bitnet:   CALIFFM@BAYLOR
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 14:10:47 -0400
From:      bzs@world.std.com (Barry Shein)
To:        jbvb@vax.ftp.com
Cc:        tcp-ip@nic.ddn.mil, zaphod.mps.ohio-state.edu!uwm.edu!srcsip!knowledge!pclark@tut.cis.ohio-state.edu
Subject:   Beginner's info TCP & UDP

From: jbvb@vax.ftp.com  (James B. Van Bokkelen)
>One point I would add, Barry: You (or another ranking net.guru) would
>be quite capable of recognizing a special case of the sort you posit,
>and using UDP appropriately.  However, you might miss the telltale
>glint in your customer's eyes when you told him "alternative X can be
>done in half the time, but it restricts the product to single
>Ethernets".  The consequences of trying to hack a 'one-cable' design
>into a 'coast-to-coast' application are painful to the whole network.

The penalty for stupidity is death. Glints in the eye merely carry
heavy fines.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 20:36:21 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        postel@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
Jon:

The major problem with the TQP specification are in the examples at the end of
the RFC.  The +22 is excesively warm--the -3 is more appropriate of the two
examples.  There is enough medical evidence to suggest that +22 is not conducive
to mental activity.

MCC

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 90 08:59:58 GMT
From:      eru!luth!sunic!mcsun!cernvax!chx400!unizh!unizh.ifi.unizh.ch!zhou@bloom-beacon.mit.edu  ( ass bei richter)
To:        tcp-ip@nic.ddn.mil
Subject:   RPC Server
I have run into difficulties in implementing a distributed algorthm
using rpc(socket) in a sunstation network. My problems are:
1. How could I set up SERVERS among suns. Is it enough to set up one
server among serveral related machines? How? (My algorithm needs to
send packets to serveral suns.)
2. In a RPC manual, there is an example which said a server is needed to be 
able to run properly. But I tried to run it without server, it did
works too. Is a server necessary for all socket(lower) level applications?
3. Could I get some real application source code from you?
Any comments any pointers are greatly appreciated!!
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 17:48:54 PDT
From:      postel@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol


Network Working Group                                          J. Postel
Request for Comments: XXXX                                           ISI
                                                               July 1990

                     Temperature Quote Protocol

Status of this Memo

This RFC suggests an Experimental Protocol for the Internet community.
Hosts on the Internet that choose to implement a Temperature Quote
Protocol are encouraged to experiment with this protocol.

Introduction

A useful debugging and measurement tool is a temperature quote
service.  A temperature quote service simply sends a short message
(the temperature) without regard to the input.

TCP Based Temperature Quote Service

One temperature quote service is defined as a connection based
application on TCP.  A server listens for TCP connections on TCP port
16.  Once a connection is established a short message (the
temperature) is sent out the connection (and any data received is
thrown away).  The service closes the connection after sending the
quote.

UDP Based Temperature Quote Service

Another temperature quote service is defined as a datagram based
application on UDP.  A server listens for UDP datagrams on UDP port
16.  When a datagram is received, an answering datagram is sent
containing the temperature (the data in the received datagram is
ignored).

Temperature Syntax and Semantics

The temperature quote is the current temperature at the location of
the server reported in degrees Celsius (or centigrade).

It is transmitted as decimal digits represented as ASCII printing
characters, preceded with a plus or a minus sign.

Examples:

	+22		; a pleasant temperature for people
	-3		; a bit on the cool side
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 90 13:21:18 GMT
From:      bdr@IFS.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

please remove me from this list.   

thanks

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jul 90 10:17:56 I
From:      ken-ichiro murakami <MURAKAMI%ntt-20.ntt.jp@RELAY.CS.NET>
To:        ucrmath!gibson!stebbins@UCSD.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re:  Possible routing problem.
John,

TELNET negotiation failure may cause such problem.
If your TELNET client(WIN?) has TELNET negotiation debug option,
you could see what's going on.

Hope this helps.

-Ken

Ken-ichiro Murakami
NTT Laboratories
Tokyo, Japan
-------

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 90 20:19:37 GMT
From:      bacchus.pa.dec.com!kmeyer@decwrl.dec.com  (Kraig Meyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
In article <> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
||As part of a distributed computing experiment, we are considering
||setting up a Sun workstation, with a bi-metallic strip and small coil
||tempearture device, and providing a network wide reading, combined
||with time of day service and cartesian location data.

The idea of being able to find out about a network node's environment
has some good network management potential.  Back when I was at Merit
helping build the original Merit nodes, we started to design a module
which would sense temperatures in and and nearby the processor cabinet.
The idea was that an alarm in the NOC would sound when the temperature
was outside of an appropriate range, and the NOC could call a human to
either turn up the A/C, plug in a fan, or turn the node off.  (A fair 
number of our original campus backbone nodes were in poorly cooled phone
closets, broom closets, *steam tunnels*, etc. at the Univ. of Michigan).

We also toyed with the idea of hooking up a computerized weather station
to the RS-232 ports on some of our upstate nodes--we had found an 
extremely high correlation between certain DDS lines going out and 
thunderstorms on the western edge of the state.  Might give us enough
time to warn users :-)

Neither project ever came to fruition, but I seem to remember that there
were a couple sources for RS-232 interfaced weather stations (Edmund
Scientific, perhaps?)   And a simple temperature gauge is easy and 
relatively inexpensive to build--all that is needed is the appropriate 
thermistor, a basic analog-digital converter and some random electronics.
If I remember correctly, you could hook the appropriate thermistor directly
to the game paddle port on an Apple II and get relatively accurate temperature
readings (and you could, of course, locate the thermistor any place you
wanted).
*****************************************************************************
Kraig Meyer                                                kmeyer@wrl.dec.com
On parole from the University of Southern California.     All views expressed
are my own and may or may not be the same as those of Digital Equipment Corp.
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 90 21:00:56 GMT
From:      logicon.com!tots!tep@nosc.mil  (Tom Perrine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Come on guys, we've got to improve e-mail
In article <QaelKR30BwwOAC9N19@transarc.com> Craig_Everhart@TRANSARC.COM writes:
>For years I've been using an RFC{821,822}-compliant Internet mail system
>that does almost all of what you suggest.
>
>Check out RFC 1049 and its commentators.
>
>Get yourself an Andrew source distribution from the X.V11R4
>distribution.  There's a mail system that supports automatic
>confirmation requests from users, among other things.  Its design
>sidesteps privacy issues, since return-receipt notices go out only after
>explicit confirmation with the receiving human user, and it's understood
>that you don't get a NAK from any transport agent.
>
>The Andrew mail stuff uses altered content-type information to embed any
>ATK (Andrew ToolKit) object, presently including raster and line
>graphics, line animations, styled and marked-up text, simple other-file
>references, and so forth.
>
>Soapbox aside, I think there's a lot of current work on improving e-mail
>services (PEM, for example) that you're simply ignoring.
>
>		Craig

Well, its a little tough for some of us to track every system out
there :-) Are any of the Andrew "extensions" documented in RFCs? What
I'm getting at is that the Andrew mail system, even though it may be
widely/freely available, may not be an *interoperable* mail system,
until the extensions and conventions it uses are documented in some
place other than the source code (or accompanying system
documentation).

Don't get me wrong! It sounds *wonderful*, but I can't run Andrew
here, but I *would* like to hack some extensions into Emacs RMAIL and
mail modes. Specifically I would like to generate (and parse) the
headers(?) that I need for return-receipt and any other non-graphical
functionality I can find.

Sorry to carrty on with this here, but I think that this point goes
beyond just mail issues.

Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM
Logicon                                 |UUCP: nosc!hamachi!tots!tep
Tactical and Training Systems Division  |-or-  sun!suntan!tots!tep
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 90 21:53:59 GMT
From:      gauss.llnl.gov@lll-winken.llnl.gov  (Casey Leedom)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for a few good terminal servers ...

  We have a rack of eight (8) high speed modems (Telebit T2500s).  We're
looking for a high performance terminal server to hang these guys off
of.

  I'd appreciate any input anyone, vendor or user, may have on terminal
servers you think would satisfy our needs (or should be avoided at all
costs.)  Thanks in advance.  Please send email directly to
casey@gauss.llnl.gov.  I will summarize all responses.  (If you ask not
to be included in the summary I will respect your wishes.)

Casey

-----
ABSOLUTE MUSTS:
    1.	There shall be a minimum of eight (8) EIA232 serial interfaces
	and one (1) Ethernet interface.

    2.	Serial interfaces shall handle at least 38.4K bits/second on all
	lines.  If two terminal servers are equivalent in other features,
	the one with the highest throughput (serial and Ethernet) will be
	selected.

    3.	Serial interfaces shall support hardware modem control (DTR/CD)
	and hardware flow control (RTS/CTS) simultaneously.  (I.e don't
	even bother talking to me about the Xylogics Annex I or Annex
	II.  The upcoming Annex IIe does fulfill this requirement
	according to their marketing blurbs.)

    4.	Shall be able to set up completely transparent 8-bit clean
	connections.  Yes, I realize that once such a connection is set
	up the user wouldn't be able to escape out to other sessions.
	Tough.  Some of our applications need a clear channel.

    5.	Shall support TCP/IP telnet protocol.  Shall support BSD rlogin
	protocol.

    6.	Shall support passworded logins.

    7.	Shall use BIND for host name lookup.

    8.	Shall listen to RIP for routing information.

    9.	Shall respect ICMP redirects.

   10.	Shall incorporate Van Jacobson/Michael Karels TCP/IP
	improvements: Slow start, retransmit timing, round trip timer,
	etc.

DESIRED FEATURES:
   11.	SLIP (RFC1055).  It would be nice to be able to dial in and set
	up a SLIP connection.  Preferably this should be implemented
	either with subnetting (which means the terminal server will
	have to participate in RIP) or by the terminal server proxy ARPing
	for the remotely connected SLIP host.

   12.	SLIP with header prediction (RFC1144).  More performance for the
	above ...

   13.	SNMP monitoring/setup.  It's the wave of the future.  If SNMP
	setup is provided for, it shall be possible to restrict such
	SNMP access to a restricted list of authorized hosts.

   14.	Respond to ICMP ECHO requests.  Useful for determining if the
	terminal server is up, etc.

   15.	AppleTalk/EtherTalk gateway capabilities.  We have a lot of
	people with Macintoshes at home who would like to dial in and
	simply become part of the AppleTalk community for file sharing,
	printing, etc.  If such a facility is offered, it shall use
	AppleTalk Phase II.  (And no, I don't want to hear about Shiva
	modems.  We already have one high speed modem pool I don't see
	any point at all in fragmenting our resources.  If we need more
	modems, I just want to toss them on the already existing GENERAL
	PURPOSE modem pool.)

   16.	More than eight (8) EIA232 serial interfaces.  We might want to
	expand the modem pool in the future.

   17.	Greater than 38.4K bits/second.  Not likely, but with V.32bis
	(probably coming within a year) and V.42bis modem standards,
	we're looking at the possibility of achieving bursts of up to
	57.6K bits/second over the phone lines.  It sure would be nice to
	be able to get at that bandwidth ...

   18.	Dialback capabilities.  Since all modems tend to use at least
	slightly different commands, etc.  I don't hold out any hope
	at all for this, but it would be nice.

   19.	LAT.  We don't have any LAT users, but every once in a while we
	run into one.  We won't cry for a second if this isn't available.
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 90 21:59:36 GMT
From:      maytag!gamiddleton%watmath@iuvax.cs.indiana.edu  (Guy Middleton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is underscore legal in the local-part of an address?
Mike Califf writes:

> At least one of the INTERBIT (Internet-to-BITNET) gateways is
> rejecting addresses which contain an underscore.  The postmaster
> at the gateway says that this is because his software correctly
> implements RFC821 which restricts addresses to letters, numbers,
> and hyphens.

I think he may be a bit confused.  The elements of the hostname should be
letter-digit-hyphen, but the local-part (anything left of the @) may be
anything at all, but, if it contains any special characters from the set
<>()[]\.,;:@" or control characters, they must be escaped by a \, or else the
whole local-part must be enclosed in quotes.
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Jul 90 0:17:37 GMT
From:      Mills@udel.edu
To:        bacchus.pa.dec.com!kmeyer@decwrl.dec.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Network Temperature Protocol
Kraig,

You don't need an external transducer and don't want one. You want the
ambient environment of the CPU circuit board, which is reliably reported
by the quartz crystal resonant frequency, assuming it is calibrated.
For this appliation you want to maximize the temperature coefficient, rather
than minimize it, which is the usual practice.

As for knocking about in the steam tunnels, rewind history to circa late
fifties, when some of us installed miles of surplus field-telephone wire in 
the steam tunnels between the student dorms, along with broadcast carrier
transmitters. That 40-watt monster under Alice Lloyd was my contribution.

Dave
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Jul 90 13:37:13 -0700
From:      Doug Faunt N6TQS 415-688-8269 <faunt@cisco.com>
To:        LVARIAN@pucc.PRINCETON.EDU
Cc:        TCP-IP@NIC.DDN.MIL
Subject:   Network Temperature Protocol

   From: "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>

   Merton,  I think your Celsius to Farenheit converter may be overheated.
   +22 C = +72 F (fairly comfortable).  BTW, the temperature in Phoenix
   reached +50 C = +122 F about two weeks ago -- now that is hot!
     Lee Varian
     Princeton University
There was a comment in the military mailing list that it hit 62 C in
Australia not too long back.  THAT'S HOT!!

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Jul 90 16:21:16 -0700
From:      jqj@rt-jqj.Stanford.EDU (JQ Johnson)
To:        mailrus!uflorida!mlb.semi.harris.com!rtpvv1!rlb@tut.cis.ohio-state.edu, tcp-ip@nic.ddn.mil
Subject:   RE: Network Temperature Protocol
I'm afraid we're getting too serious about this "Temperature Quote Protocol"
stuff.  If anyone is tempted to get serious about it, they should write
an experimental MIB and offer temperature/humidity/... as SNMP variables,
not using yet another protocol.

The above in response to Bob's query:
>Is there already such a beast in the RFC's?

I do NOT believe there is an appropriate MIB yet.
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Jul 90 10:07:49 EDT
From:      "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Network Temperature Protocol
On Mon, 23 Jul 90 20:36:21 -0700 Merton Campbell Crockett said:
>The major problem with the TQP specification are in the examples at the end of
>the RFC.  The +22 is excesively warm--the -3 is more appropriate of the two
>examples.  There is enough medical evidence to suggest that +22 is not
>conducive
>to mental activity.

Merton,  I think your Celsius to Farenheit converter may be overheated.
+22 C = +72 F (fairly comfortable).  BTW, the temperature in Phoenix
reached +50 C = +122 F about two weeks ago -- now that is hot!
  Lee Varian
  Princeton University
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Jul 90 13:37:35 PDT
From:      jkrey@venera.isi.edu
To:        mark.horn@mail.admin.wisc.edu
Cc:        jkrey@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Looking for POP2 server source

Mark,

To FTP the POP2 sources, do anonymous login to host venera.isi.edu.

Retrieve:

~ftp/pub/pop.c (4.2bsd client program)
~ftp/pub/popd2.c (4.2+bsd server program)


Joyce K. Reynolds




-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 08:57:55 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <9007171938.aa18804@huey.udel.edu> Mills@udel writes:
+---------------
| You may remember the ill-fated XTEN network that could be described as
| an Ethernet radio operating at 10 GHz for metro-area coverage. Are we
| now seeing XTENs in the sky?
+---------------

Not exactly. The 10 GHz local radio was not so much an Ethernet as a whole
bunch of Localtalks...   ;-}   ;-}

XTEN was [supposed to be] closer to a "non-mobile digital cellular radio".
While the carrier frequency used for local distribution was indeed 10 GHz,
the data rate was a paltry 256 Kbits/sec, shared among all stations located
in a "cell", a 6-mile (max.) radius quarter-circle from a "local node" (that
is, an area of about 28 sq. mi.). [Cells could, of course, be smaller than
that, with careful power budgeting and re-use planning, just like today's
mobile cellular systems. But there were only four frequencies available for
re-use planning.] The traffic from the four cells of each local node was to
be gathered and sent to a "city node" (central office), via point-to-point
links not part of the allocation at 10 GHz. City traffic was then to be TDMA'd
via one or more satellite transponders at geo-sync.

Thus, nothing moved around. The routers would have been virtually identical
to today's IP routers, except maybe simpler since the physical plant was so
much more hierarchically laid out -- everything not local to a city went up
to a satellite and back.

The total "peak-busy-hour" traffic for New York City in 1992 was estimated
[in 1979] to be less than one FDDI's worth. And today a lot of people think
FDDI is slow. (SONET, here we come! ;-} )  The only historically safe guess
is that we'll continue to underestimate our networking bandwidth appetites...


-Rob

(p.s. Fall of 1979, my job at Xerox/XTEN was designing/evaluating multi-access
protocols for the 10 GHz local radio...)

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Jul 90 15:14:23 EDT
From:      hal@gateway.mitre.org (Hal Feinstein)
To:        tcp-ip@nic.ddn.mil
Subject:   FTP grade of service
Is there a knwon extension to FTP that allows a reqestor to request a
dispatching priority level from the target host.  For example, 
transfering very large files at night. A trickle-across mode is 
useful so as not to interfer with other users. If such a service
doesn't now exist it might be suitable as an additional parameter setup
during session initialization. Has this been considered before?
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Tue 24 Jul 90 15:20:09-EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        postel@venera.isi.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
Jon--

Since you did request comments, after all, I'd observe that it would be
more appropriate to offer Fahrenheit readings via TCP and UDP, reserving
Celsigrade/Centius for TP4 and CLNP whenever X.500 can furnish the necessary
SAPpiness.  (Perhaps Kelvin should be furnished via TP0.)  I mean, every
time we try to be international about things it only leads to difficulty,
as witness the subsequent messages re what 22C is....

Or should we be spec-ing a CF "gateway", to be contemporary?

Other than that, though, it seems to be one of the better protocols to come
along in some time, except for one technical omission, I believe.  Unless,
of course, the Host Requirements RFC specifies that UDP checksums will be
used for all protocols that don't say not to use 'em, since if one cares
enough about the temperature to ask, one presumably cares enough to want to
get it right.

So I urge the IAB not to progress the TQS to DIS [*] status without changing
it to Fahrenheit for both TCP and UDP, and explicitly requiring UDP checksums
(except for the UNIXtm "man" page, naturally, where total recall of all
remotely relevant context is always assumed).

   cheers, map

[*] Draft Internet Silliness
    (not to be confused with Draft International Sanctimoniousness)
-------
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 13:59:47 GMT
From:      sci34hub!eng3!joe@uunet.uu.net  (Joe LaRocque)
To:        tcp-ip@nic.ddn.mil
Subject:   How do you get a ENet Addr?
I have been given a 'chance to excell' by my boss. Simply put, how do
we go about getting a base EtherNet Address assigned to us? I seem to
recall that PARC is still in charge of these numbers. But, I know that
they have moved to San Diego and I no longer have a name or telephone
number for an individual that I can talk to about this request.

Before I forget....I know that we could get a set of proms from a mfg
who would take care of the problem for us. Our problem is that the new
system we are building requires as few surface mount structures as 
possible, so we will be assigning the EtherNet Address via software.

Thanks for your assist!

Joe
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 14:07:49 GMT
From:      LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To:        comp.protocols.tcp-ip
Subject:   Re: Network Temperature Protocol

On Mon, 23 Jul 90 20:36:21 -0700 Merton Campbell Crockett said:
>The major problem with the TQP specification are in the examples at the end of
>the RFC.  The +22 is excesively warm--the -3 is more appropriate of the two
>examples.  There is enough medical evidence to suggest that +22 is not
>conducive
>to mental activity.

Merton,  I think your Celsius to Farenheit converter may be overheated.
+22 C = +72 F (fairly comfortable).  BTW, the temperature in Phoenix
reached +50 C = +122 F about two weeks ago -- now that is hot!
  Lee Varian
  Princeton University

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 14:41:30 GMT
From:      bacchus.pa.dec.com!shlump.nac.dec.com!koning.enet.dec.com!koning@decwrl.dec.com  (Paul Koning)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Zero manufacturer code in SNAP?
::...
::
:: My understanding, which has no more authority in this case than "urban legend"
:: (and should probably be taken with the same degree of confidence), is that the
:: 24-bit "organization" identifier was not originally intended to be identical
:: with the upper 24 (well, 23) bits of some assigned MAC address, but was to be
:: a separate space assigned/managed by IEEE.
:: 
:: (The obvious hack of making it be the same as a manufacturer's 23-bit unique
:: MAC-address prefix came later, if at all. [*Is* that the way the IEEE assigns
:: them?] After all, it *is* possible that a manufacturer could make more than
:: 2^24 network interfaces and need some more addresses, so why mix SNAP IDs with
:: MAC addresses?)

I don't know about the "original intent".  However, the final result, as
described in IEEE standard 802.1A, is that the OUI (the SAME one) is used
to create individual MAC addresses, multicast addresses, and Protocol IDs.
There is only a single registry, and it is used for all of these purposes.

	paul koning
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Jul 90 18:57:38 EDT
From:      "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Network Temperature Protocol
On Tue, 24 Jul 90 15:22:37 GMT Boyd, Bob said:
>This would make it feasible for monitor manufacturers to make their
>equipment more accessible by having a standard protocol for reporting
>environmental conditions.  Is there already such a beast in the RFC's?

Bob,  Isn't this just another MIB for SNMP to deal with?
  Lee Varian
  Princeton University
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 15:22:37 GMT
From:      mailrus!uflorida!mlb.semi.harris.com!rtpvv1!rlb@tut.cis.ohio-state.edu  (Boyd,Bob)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
In article <9007240048.AA00668@bel.isi.edu>, postel@VENERA.ISI.EDU writes...
> 
> 
>Network Working Group                                          J. Postel
>Request for Comments: XXXX                                           ISI
>                                                               July 1990
> 
>                     Temperature Quote Protocol
> 
>Status of this Memo
> 
>This RFC suggests an Experimental Protocol for the Internet community.
>Hosts on the Internet that choose to implement a Temperature Quote
>Protocol are encouraged to experiment with this protocol.
> 
>Introduction
> 
>A useful debugging and measurement tool is a temperature quote
>service.  A temperature quote service simply sends a short message
>(the temperature) without regard to the input.
> 
>TCP Based Temperature Quote Service
..
> 
>Temperature Syntax and Semantics
> 
>The temperature quote is the current temperature at the location of
>the server reported in degrees Celsius (or centigrade).
> 
>It is transmitted as decimal digits represented as ASCII printing
>characters, preceded with a plus or a minus sign.
> 
>Examples:
> 
>	+22		; a pleasant temperature for people
>	-3		; a bit on the cool side

It seems to me that it would be more useful to establish this as a more general
environmental protocol rather than just temperature.  I would suggest
that the quote consist of a string of information separated by delimiters
such as "," or ";".  This way humidity and other more esoteric environmental
parameters could be checked -- such as "on emergency power", "particle count",
etc....

This would make it feasible for monitor manufacturers to make their
equipment more accessible by having a standard protocol for reporting
environmental conditions.  Is there already such a beast in the RFC's?

          Bob
-----------------------------------------------------------------
 Bob Boyd   Voice:     (919)549-3627     
 Harris Semiconductor Microelectronics Center

 E-Mail Address:      rlb@rtpark.rtp.semi.harris.com
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 15:43:26 GMT
From:      dino!hascall@uunet.uu.net  (John Hascall)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
In some article, mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
 
}The major problem with the TQP specification are in the examples at the end of
}the RFC.  The +22 is excesively warm-- ...
  
  Huh?  ((22 * 1.8) + 32) = 71.6

John Hascall
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 16:33:50 GMT
From:      noose.ecn.purdue.edu!molecules.ecn.purdue.edu!kelley@iuvax.cs.indiana.edu  (Stephen Kelley)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
Temperature should be in Kelvins.  


Steve Helpful
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 19:12:35 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!wuarchive!swbatl!texbell!cpsolv!rhg@ucsd.edu  (Richard H. Gumpertz)
To:        tcp-ip@nic.ddn.mil
Subject:   NAMED needs more consistency checks
It appears that we have finally tracked down a problem with the domain
CPS.COM sometimes showing up with an MX and sometimes not.  It was a
misconfigured secondary NS for CPS.COM: due to miscommunication, named at
that site wasn't configured with a "secondary" line telling it that it was an
authoritative NS for CPS.COM.  Therefore, it never fetched the zone
information from the primary server and instead responded to inquiries by
just returning whatever happened to be in its cache (usually just the NS
records obtained from a root DNS server and not the MX records which it was
supposed to have obtained by zone transfer from the primary NS).

This brings up an interesting point: maybe "named" and other DNS servers
should complain to a local administrator if they see an NS record go by
pointing at the local site when the local site hasn't loaded any
authoritative records for the zone.

Thanks to all who helped me track down the problem; it appears to be fixed as
of today.
-- 
  ==========================================================================
  | Richard H. Gumpertz    rhg@CPS.COM    (913) 642-1777 or (816) 891-3561 |
  | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 |
  ==========================================================================
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 19:37:52 GMT
From:      sci34hub!eng3!joe@uunet.uu.net  (Joe LaRocque)
To:        tcp-ip@nic.ddn.mil
Subject:   NDIS Document
Could someone Email a copy of the NDIS Document to me?
Thanks for the assist.

	Joe
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 20:37:13 GMT
From:      faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269)
To:        comp.protocols.tcp-ip
Subject:   Network Temperature Protocol


   From: "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>

   Merton,  I think your Celsius to Farenheit converter may be overheated.
   +22 C = +72 F (fairly comfortable).  BTW, the temperature in Phoenix
   reached +50 C = +122 F about two weeks ago -- now that is hot!
     Lee Varian
     Princeton University
There was a comment in the military mailing list that it hit 62 C in
Australia not too long back.  THAT'S HOT!!

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 21:00:30 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol

one the subject of temperature quotes...

One person has mentioned that the temperature of the system's
environment might be a good piece of *management* information...

Why not make it an extension to the system variables of the MIB and
let SNMP do the querry-response stuff rather than create a new
protocol?

While this discussion may have started-out as an arcane excercise ;-)
it seems as though arcane items like this might be quite useful.
(perhaps not as *fun* as the CMU coke machine ;-). Maybe the folks at
Leibert (sp) would like to put SNMP into their PDU's and air
conditioners and put them on the local LANs?

rick jones

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | But it IS TCP/IP - Honest!
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 21:03:44 GMT
From:      uhccux!querubin@ames.arc.nasa.gov  (Antonio Querubin)
To:        tcp-ip@nic.ddn.mil
Subject:   FNS routing
We're running the Fusion Network System package on a VAX with two ethernet
boards and are attempting to make it act as a router between our subnet and
the campus backbone.  Can anyone experienced in setting up FNS help us out?

One ethernet board has an IP address of 128.171.1.99 and attaches to the
campus backbone.  The other board is 128.171.11.2 and we have only one
PC running KA9Q on that side of the net.  (Other hosts on that side of the
net are running DECnet/LAT).  We want to pass packets through the VAX.

Here's the contents of our net.db file:

name:exists:state:route:hops:delay:maxpkt:options:comment
veva0:1:nrc$veva0:[ETHER]AA0004009A60::2000::DEVICE=XQB0:DELQA-VAXS3600-2
veva0:1:nrc$veva0:[INET]128.171.1.99::2000::GWY: UHNET
veva1:1:nrc$veva1:[ETHER]AA0004009A60::2000::DEVICE=XQA0:DELQA-VAXS3600-1
veva1:1:nrc$veva1:[INET]128.171.11.2::2000::GWY;SUBNET=255.255.255.0: Physics subnet
veva0:1:nrc$veva0:[INET]->128.171.1.100::2000:::ZEUS IS THE ROUTER

On our VAX we can ping both boards and any machine on either side of the VAX.
We can even ping off-campus through our router 128.171.1.100.  On our PC which
has an IP address of 128.171.11.16 we can ping 128.171.11.2 but cannot ping
128.171.1.99 nor anything else on that side of the VAX.  While I can force
a route in KA9Q to the VAX via a 'route add', the VAX just gobbles up the
packets and doesn't seem to do anything with them as far as we can tell. 

It seems that if FNS is smart enough to know which board to use to ping a 
particular address it ought to know how to pass packets it receives to the
right side of the network.  Are we missing something here and doing something
wrong or is FNS just brain-dead when it comes to routing?  We have the latest
version of the FNS package.  

Any help would be appreciated.  Thanks!

Antonio Querubin, Jr.
querubin@uhccux.uhcc.hawaii.edu
antonio_querubin-manoa@uhplato (BITNET)
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 21:03:59 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Temperature Quote Protocol
Rather than require the TQP server to ignore any data received, it
would be nice to allow some specification of which temperature(s)
(e.g., CPU box, disk drive, outside, operator) is desired.  This would
make it possible to have more than 1 temperature sensor per IP
address.

Similarly, the temperature quote returned should identify the
temperature(s) reported.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 22:57:38 GMT
From:      LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To:        comp.protocols.tcp-ip
Subject:   Re: Network Temperature Protocol

On Tue, 24 Jul 90 15:22:37 GMT Boyd, Bob said:
>This would make it feasible for monitor manufacturers to make their
>equipment more accessible by having a standard protocol for reporting
>environmental conditions.  Is there already such a beast in the RFC's?

Bob,  Isn't this just another MIB for SNMP to deal with?
  Lee Varian
  Princeton University

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 90 23:22:21 GMT
From:      groucho!davis@handies.ucar.edu  (Glenn P. Davis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
In <9007240048.AA00668@bel.isi.edu> postel@VENERA.ISI.EDU writes:



>Network Working Group                                          J. Postel
>Request for Comments: XXXX                                           ISI
>                                                               July 1990

>                     Temperature Quote Protocol

>Status of this Memo

>This RFC suggests an Experimental Protocol for the Internet community.
>Hosts on the Internet that choose to implement a Temperature Quote
>Protocol are encouraged to experiment with this protocol.

 ...and so on

You probably don't want to hear this, but there are a number of
protocols and formats for weather info defined by the
"World Meterological Organization" (WMO).


See, for example, WMO publication number 386, "Manual on the Global
Telecommunication System, Volume 1, Global Aspects, Part II" for the
protocols.

Of more relevance to this discussion is the specification of a
synoptic report (a weather report from a ground station).
This is contained in the WMO "Manual on Codes", publication No. 306.
The synoptic codes are code form "FM 12-VIII Ext." .

Here is an example:

^A^M^M
727 ^M^M
SMBZ4 SBBR 241200^M^M
AAXX 24124 ^M^M
83827 21225 80000 10110 20101 39900 40190 53012 7104/ 886// 333 ^M^M
20082 69974=^M^M^M
^M^M
^C

This is a report from "SBBR" (Brazilia) at 12:00 UTC on July 24.
"Control" characters are indicated using "^X", etc.
The actual report begins at line AAXX ...

I can't decode it, but somewhere we have some software that can :-).
Things like temperature, wind speed and direction, rel humidity, 
barometric pressure, cloud cover, etc are all in that line.

They devised these things in the days of 300 baud teletypes == expensive
bandwidth.

Cheers.

Glenn P. Davis
UCAR / Unidata
PO Box 3000                   1685 38th St.
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 00:51:39 GMT
From:      wang!fitz@uunet.uu.net  (Tom Fitzgerald)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is underscore legal in the local-part of an address?
[I know the original discussion is moot by this time, but anyway...]

gamiddleton@watmath.waterloo.edu (Guy Middleton) writes:
> The elements of the hostname should be
> letter-digit-hyphen, but the local-part (anything left of the @) may be
> anything at all, but, if it contains any special characters from the set
> <>()[]\.,;:@" or control characters, they must be escaped by a \, or else the
> whole local-part must be enclosed in quotes.

Periods are legal according to RFC 822.  Is this generally true in
implementations, or is this considered one of the glitches of RFC 822 that
nobody really pays attention to any more?

This actually makes a difference to us.  A programmer here wrote an e-mail
gateway strictly following RFC 822, in the belief that all other mailer
implementations in the world followed it strictly as well.  This has caused
a few problems already...

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 01:39:11 GMT
From:      excelan!bbaker@ames.arc.nasa.gov  (Brad Baker)
To:        tcp-ip@nic.ddn.mil
Subject:   Internetting Netbios Agent NBA (sources 1of1)
Sources for NBA  (OS2 and Unix)

Netbios Broadcast Agent
Effectively internets the Netbios Name service.

This program is useful for effectively combining netbios
networks that are separated on the internet.  
It could also be used to connect to a remote Unix SMB server
allowing for file and print services across the internet.
Written to the BSD 4.3 sockets interface.  It has been compiled
and run on 68XXX and SPARC Unix machines, as well as OS/2, with
no code changes. 

Included are the four files needed to build it:

makefile 	(os2)
name.h		(os2,unix)
nba.h		(os2,unix)
nba.c		(os2,unix)

See the documentation header in nba.c for more extensive info.

Cut, uudecode, then uncompress.

--- BEGIN cut here ---
begin 666 nba.Z
M'YV0(Q2, $&P((@V8=:4,9.&31D09M[( >%$2!"($D$\F?)"!@B! D%,*?.P
M"14B69P$<4'DR1",$]M(?$BF#)TP#>> >.,&!!TT:73.J2-&39DQ=$#*K,FF
M!QLS=4*F<3.&39V:(."$^:FS!8@Z<QZVJ<.&3IH6/^64"4,&Q-2J5Q\R=#@'
M)!8F3J $H8*D!Q<\;-QPH?/F#9LU:9)26?(EB9,A3'J00'$W[UXD*;B\M5I3
M@6/(58@4Z=$BB0L0I2<O;OR820K42;BTF3.F1@S-5#F7D9TTX$ V:<1HY0IB
M#IHW9-N*>1B6CMN>/Q\R22($1!DW=M+(X=GFNO,Y=.1,/6,7[W0A4WJ(F4.&
MQ@P7P,6 &".'3GSXP14TF7(^/9DWM(7!!AMSX">& D$PP<07_4E&F7G43?':
M9/OUEP)( XWQ1AMP-"07&V&<45= 0QC!1!!'I$?0"V. \$(0DRU5!ANOO? $
M'BYJ 9R+1\SAT0M$$*&@BT$6(4051Q"YT8]7S #"9)\Q$5H1%_H& G!NK $1
MB"*"Q(2)**KXPA!/N.C$$T2XV$004)CY1!(*3.?$$D,T082#7YZ8XH0JJ #"
M"B#\%=A@A1V6&!< RA ?%_31408>9;CP1E$LD !$I2JX@! <E:*0X((6*B"J
M"V-(6I0."AAD4%5/HE"BGA(^F6F+/LCJ0AERR"&J&V*$8:H:.B3 JZ]C"-NK
M"VB (&P8W2$KZ@C00@L"$U-IJ6$;"+E!AD[11KMKKSHH.^RO"B2 I9:3R4FG
MG2GL4"Y"<B@$*0A7.-;2%60VH1<5((S[:!G/@E"$$VD^800(:RY1A!%),%&$
MJ"^HH$ +%%=L\<489ZSQQAQWS+&HJA8TQ!MPY"'>&6@XY^IK,>20 PP4O6''
MC&RP $(25+E0;JHA@T %4$*]808==X2AUD%AY '"<A"I-:/2&G981EMA: L"
M&4&%%UP=CI)A,QS;95=36]%]U#,(88@A\T-1FYP&RLZY\8998SP4U'-PC7U:
M$LXAI+3<SC$]AV%>/P?"'<<YQ'/(&4V5E=%TV'Q'8L=Q[1,:#X&=1D9WB$>'
MHSUIZ$98;C@G=,PS#V@SSJ6*ZO'KL,<N.\:B)J!2$T6X@$0"(&#.%JX0>0A3
MO\>.(:H*+SQ;$T-NE)% $E!\0<014@31Q!=3:)% #3?8(-#R4SD/_1=($"$%
M]MK+ ,/W"X6?0&C1EW]^]@G@P#[S#V7_Q9%&&%&$% E P?BF5[WK90\U-XN?
M^="'0/B1;X'9JQ+XFI< _:T)"U!8PDGV$H3M=2\!$4,:'M(PEC9<;2MA,%P*
MM3(&A3@'>1#KDPQG2,,:VO"&.,RA#G68*C\184,XZ8D3F/40*(2AA38! 1':
MYX;$;&YT/=RA%*=(Q2K.,'G*8Z+SG' ]*13A"%_P8A02  ,\R" ',5C?"":X
MQ2X680H)(",>V((#-;+1=M>+@A2R$,<RPB &:;R?^[CX!3UF(8QOE",.:@ #
M.VJ1(GG<(R*G$ -%UJ".@J3@F42#/2KLI0I30.08_?A'1^+/=F@J0B<_&4HO
M3@$$9<0!#1J9R39^X0E6.)\8Y2@#' 1RC5K$8QB9T,HBC!(/,RAE+4&002I\
M83]+Z",>S$ &,\  A'YJ0ACFH*73B2$Q.@'+U(;'0A?Z) ]PB!0(8 A,_(% 
M"F3B)#3EV$@8F &;"-MF-\VP-'!^)2QMB<A$Y* AK,!0 1'K83ZY"0(["*@.
M9=")0"'Y!3"EZ#0_B^A#'&J5B/I$+5NYG%S2,*-ML4"A3X!"/(M@,T):= HV
MJUI;X)E*M.F$)P^Y@T3:@H(8V*"?=)A#"G2V3BRV<Y"A%((4GA $(@PA"%.@
M CT;&8-:VJZ84Y""%8A025+"0 96=0)6M4H$&4P5!C0(:RL[>%;['563K22"
M---(R[=N,914&((TU==(?(:G#E39RA.!6E2U?B$(;"WC+&F)4#_A:CL3*:A'
M)TI3T02OI(8K9Q)]5Y.)'-2N"3""2;[P/P"6L9(AQ!E'TT &-BC-"!)!R.?&
M*84RQ &BX"DL:+-J!=)*P;1FQ.=(Y#"SB1@!)U8Y&COOF 1]^1:X-,!G%497
M!SC 02)=>Z=M<?O"Y(%6"D8(96GE6 -\UO8,69.#8'FB7:C,04"ZO6,0AN#,
M\9;1!O@, E+2,#/KY.H-9;"9&XCHEIO>H7G*45K5YH:YB<BM)J=9;C!+5-_?
MRO$&^!QB=PIL.-&9 3A(*6QCSYG.AC[4HY^]HU@/*\U27C.U;6(+&=0R!YW\
M-K[!7+%86]Q(LX90P_G#57'?*04<GU+'0N"Q^O!YA.O@"KY %HF0TU W(AL9
MJ5^H2%3W,E49H-9/3G@#5J9P$SJ Q<H2/G(HG5 %!?$8!F'(<)N98&6OA.4A
M5YCO$J[&1">R-\WAHT@H'?/F&*S(3SASE!R:YYRJ;%,G!PTA1W$[O(I45$^7
M94-;''=C,J!0Q'85]!>H]X0J0$&1]63R=JH+ B$DQF:&[D$/0'"$5<.!(C;Y
M)H H0F! -T_43=AD$>2X6%,&>L50$#8OZ[G,%9OO"'-E=JA7+ 1E>]78OU[Q
M$)Q@A!;7$=L/6?%\I4K/Q38[E%"00A-:S-<8(HV;$LV(I2V:Z4WW9, ;]O1-
MK%,Z.2@MQ8]<,:E-/4\_Q#+5(:PU<FX=92-PZ<K9#N43G$"%@M\7X7YZPH&!
M%V:L4 &=#_%UN$.Y92H4P>)XB $9^OIC I-Y*P]Q=5!%W%@KVOSF.)?8.D$0
M!>X.=B3[96]XD(NK<('M*%,;IQ@4/)\-';W&XW1"KC>G$WP#;)TYS[K6;XA%
M\,BA#B&^;43I\(6A>V@B>UC<5T;W-@07YSCU(7$9W&40P,ZA[>,T#G;G Z(:
MNZL/.W"1GVBPM#PX2B=LX,D91!RQK3O^\0JM[>#J0-"'U%9#<B";>L]N=+74
M;6R%1UO3.41C@.*:#KJN.A%M%I$!O>$.4U/HTD7O4/&DS2$GW'=8@NZ&*#[^
M]SCO^E]#G*NR;]XA:%>[W?'>%KW'7>YT+\CRS^!VYSN'[X^./D&F[_;$NV'Q
MGV.#]M=^=^KG'>[7=\CW?_+WP(<PC84__)44+V*O@]TYQ9]*1$"0=H/8G_AR
M8'Q$)P<)8';(-W[<=WY[%S(?%B)S,'[>MWAQ1#PR)@?M)W@@X%/QYU$16'_#
M%S<<L@9DAP8SQG_*QW;FUWSHUR]M4':LM0-^I5ZC<T1FP5ZL55AUAX+5MX+@
ML15@ 8,A1#*2Q7I<,@<VHQ9FMFA-9U#)DX/EMX-[%P=DH"& 10= Z"=N4 =M
ML!P3<3IB!QZ#Y1WB@6)-*'TZJ(!Q5S546#I7V"]:R(4[P4]5,P>P-U!'L5.0
M5H;;=X8JN'>CLX96B$]9N(7 <SIAP#5PEQA*XWEXB(-F^(1HZ!Q& XAM.(AP
M:(AD@#4U.&!L  *,F'EYJ " AX$QX!%+)W\=>%#_%S=$! <B:(+^]X$LZ(HC
M6(*<A2LP>(*0V!9C@ 9&XXEW"(I;H#_\XS]%9F=IH =E(#0HL(JS*()?0()R
MD )=T'Y9=&36HTI3\#]6D 1#H$H.! 5/( 52%0,S< .--3&SLX[LV(XM #(]
M,S(E<S(I P(KDX$N S-AECHU<S,YLS-G\S-W,SA#4S1'XS=+(Q=.XUI-)S54
M8S58XW5;TS5?$S:L-4YEHW8&D39KTY!N S?],C=49C<ZL1EQ009[TS=)$Y*!
MPQR$8S..@SB&<74]TS@]H17U(3F4@QS.43::PSF> SI--SK>$8>H0S.K\X_J
MZ(Y,V90:4SL481&Z4Q"W.!%S(1<9,2[&HP"19D,@( )M-Q,B<#D#:69FP$\U
MY%UI8 ;:LA @8 1$@#U%0 5A)01"P$<X$$<A9(F%R$_?-'..DT*G&'+)DU [
M-Q(.$6+BI!-_^6YK<%/\=)5\1AOB 0>$(0<EV1,16" *E5%A@33TL6O9D@9P
M0!8P5QQ@ERR-R1 EI1,H4#97.0=Y !YE8$(($9KA])F]:#1"151^ I=R2053
MD 1:4 1(HS1,PT8))E+_A"LV(P:64S;+<XAET3NX<G5^HG?)D9 @X .S=B8,
MXS#VB)/,@BQ#U4-JR9;+$UIQN8W"29P/ UK Z9[#69P), -@-0+7@35F("IT
M '++,W_?EP#4] 4(P4WN,FUP*01)()P!='?*R(P%>J!K\!I@9I=9D +X])<Z
MD4XQH4^ZM99MR4_'<0?9D@=65:(GB@)X8#-YH*$H$*-XD (K$*,OV@(QD (I
M\ (H\*)5LI]K>8WN,Y]SB0)N\#4PB@)PD (MX /4- =?P*%;8*0[RFU$P*#"
MV04@P >SUE,@P ,\8(]4"@(E0!$+VJ 2HJ-6!9R0(05&BJ0!I*1,ZJ3;$J7@
M-*5N4*5GFJ4@8 *SY@=>"J9BFJ=D:J97BJ8Z*D'!!)Q), 7N^:99D:1+VJ1/
M:J=!A:=Z>JA\:@+V:&B"&J.$6J96BJ5IJJCN!)S%N51RF@!BH(S;$:.[Z5DI
M(*<V Z'+: 8HH )RJJ;ZJ2U!VGA3!(SP!1YU<)8)F7AW8)W*5458Y)\ ZI;*
MDH!]&'=Q!$I(,(Y4X"[_F4X!&JU\**"+IRSOPP03=P3:^JS\Y*V[**YQ) 1/
M\ 1,X"Y6E0!4( 55,&QQE*]5!5JAE2#;R*Y])*2_%D<5$01?< 6,(8[D2!#Y
MFDR-5!!ZZ2=5LW:/QGQ9L7<B)ZX6$07UB:_Z^K#+U*YLHD'3X3\&D:\U<#8%
M$4*:Y1S 80:$.:_Z\QC5EHWYF@ ^%;(5Y!)+T%3FT[$,&T>VRHS..#@M5(%?
M,!6F&FAQA"(#XTRWHTH.XP3B"D@?$6IQ%)ZJ%+4,,C!!6T<?X6X641QE=F:2
M%8I8FP 6(9<$<[-DI+-KZT50P 19 +#[RD8::["E-8YNBZ,"^Q $BU7/!%71
ME*\'QW)^0J'#4S9B!8QS<%U$25A=.93%=7?L=9O;$8KX)#K%%3<VH5/QLA.9
M!SP=2!C]\KD2T4VC.Q'6!W& :SM,0!ABQ:(:FJ\IPQ-S$*/6BJTI4#IO@ 9L
M0+NO42XAQ+FXXKE$D[JBVUEOMW>FRVB@J[K,FXK>A;>!*[M,0+LW>[MN$+PH
MT&;EVKN$@0:Y.Z,7H@#.V"O1N!;,FW;C6JX0VX-F]H W6[P;DBV\*&:3E1%C
M&R+>H;G@ZP30QK!FT1TP6+]^4L#,<1,<0DY'9$Z/TB'JM8F%];X"+"Y0:A9D
M<, 1VR\$%A;$-9(?-8<T.%@W"$,6G"2L&@8NN,$(W&H7X;^E,\(SR'MNT18H
M',!)HBS' 1Y?4($<'$+]>P9%68$1!<#D>L$)4!4D53H_G(D6V,&-R\1%#,5'
M7! YG,0J3,5.?%WU<< _]DI<[!Q>W%UP&P1(4 1-]3\=FZ]#BZOIR\)5>2& 
M)RIQ_ 6T:(()X(PKO+Z_,Q&]4I7NLL>RN"S=D<<$876TF*#6J[8C^Y[VZ<;)
M>*O-*(OJ.\=_(A):L#]5T#__(XKRFHY+Z92D[)3P&#+R^)'U>(\M\S)'J3K^
MV#H)H)$%(9!!4Y!&(Q8KR31FL)!00S(D]9!M$9%: YT4F146"7H9>38<V5]M
M0X]Q(Y)5=C<FJ3<WHY)_,S?<.3B:!I,](9.*<S8V^3@Y>3@[&9V8@\R;,Q&=
MDQA"*3JD8SK\M(](&<LZ,\JEG,_L>,JJ4K N\!*GEWJMMAUL,0;;Y!Q!0,0S
M7!"S-]!LT6H)@2NU8\L<-@76,[?&.7F5MX0!1A%/P"\I1,\#@LQB=G\V0\L$
M(5/F/-* L\W55<9*IS1EXRB]V$0&W8D]:*RG(])L<,\)(!I3, 12 #U4D 03
MARKE0M%@\P9GH%XFM-1BXU$3^RC, @>X=SHEZA-O !,&V1965QQ35C<\PZH$
M/84'K1.FJQ8RX2BGBWI4U];1JQ.BTSQ(,4[9D4)G '-%,YNB6RZKIF@Z@3A4
MEBS_P9+_5 <"PI "U=6HV8N/@T1!=1K7S&$UL8OE8KI,\W4]X3AE0#G ,UQ#
M)B.B"P()790RHC-Q!-K (]IJ<5O:X5$_$5(_<3=+W=3,8H\%^QJ9#5@[ 1WI
MG'@W72[0F[HI"8QUPU\>Q6@"_=5BYV]+4]8&#1ZN*;]@T0.GE4:O(5-^7096
M35*!33FBU]R+&%&0^YF5[(-S8-UXL$B-E (PR4]E(]X>O&':G0!3H6B,AC96
M7&/\%AY*<S<1 5CVQIS7&E6O=)62'6; :-5*T[+E,I!%N9;,^=5WT](!;C6.
M4S8%+IS!XQ"HG0"E/<.B/15V8!@SHQ.:W43?U]OA-K9"]]MO<--M'5-6@U.]
M?=GIK-9S\Q##'2^2G5'S)^,%:]R=?>+/_08%?=:]S9S +2#"C;KQ4JMA8.0>
M:A;-,\,M^QP")5N#-12.O4U\U\22N-]&6"YE;#-#5\,4G 1$8#,V42K>+'JB
M$QZ&L33 K24H,,<_CCEF_L!)=#?1<9-JD4YMV1:3\Q/,.>152>-D@SD]L=A&
MH\QO@.,/H>-L[<\$<06.[A;.<3>>5^13@^8Y7IL['I47(9%P )G]68#IO.C%
M,>4>A0+7(7:X]1IEX^HJ'>C,*1%O,Q5.'D UT0+78="I;II=\QK*_=99?C=B
M -T'O>1E8^D\#N5K@-J:?AW,*>VF3N3(+7J#[EKOC3:2",NF6S;-CN1F#1XG
MQ>H/495:'EOKM=DZ41.TKG3;-$XO_A S+8/O9<,W*#24ON ,V;)[3A-CY^L4
M;,0U]C78Q>@^\>_PS>?*\NT-[N>=CM:;WAQ:S9PH,,:O,6D>!1XS,>#142[T
M#E$0U1:*SK[ D^NC/A1E,1Z/;4X0/L,H@#6>=^Q+\\"7O=4SG<YC'))8(=B.
MC1!843:\CEZ<>.1)#AX?3M&0GGDR?SKF[NRYI=(4/_,V882&LQ PBQ3K?M^X
MPF@8S^,?'-:14CO^\TFN] +3T00-NA=&+59(G0 J8#MC>S?M/%O0L=5,4UP-
MCEVWITZ3/3DCK=E+;@-UA =X4"[,;#53@),M,EUI@".W"13-HQ-@#GLC#>9U
MU$LV\ (S@ ,_M22@B?E2K2WELL>5HVG<N19W-_#8A9%;W1)3X--WK]3;8=NV
M&=$Z\2B@<W?])4Y&J>$;P>$(OOI%T&_>?1!@X1R/DC7#HU1,Y510104V0ZY/
MQ00;'E.!33.K#^95\S=$A.+;I1TRGT(T5MXYM>DI+O-#/A6K#\*AK;^2G03\
M-!1BP&A6OGC4W!/$+]_!M=2U^LH&]6LJ3R6JZ+<9<\6H7CK;<O3B"KB +) %
M7$ 9.4L6<)KP$[^Q^EI:]%IR@V/#H(<T04*L6FWR#O&N0! $G$&6Y-J]0QN]
M)XZ$ >NR'33':=)_^>W<-;TQQP#YFW9R?4Q#G*"DU7?JB$(.M'H\L/3T#C '
MFV(+4E-95T "8@$L, $KH!;0 @4!<5PG?J8JHJ +F((@8-:4C1ZG)<K88%%X
M=4%E%80K& :94P\C8]CE#)(Y>Y38P!H=N!!JD"!0P#8X45+(@\DIX"V%X, D
MHKA.QP4< Z(N** T-<A&RMY7L"[ XZ=PJ.*7S@:336%.@S IY,&080;92S-*
M(N4NG65"$]-1LIO5*!O(2J)M0E5ABOP)"E ;B*XY9+<.!3DH8;L#$'"P/CR1
M>Z:RJ!J'< CA0E6,0L4U:P[A(ER%B8S:J8IBN-YD0 :< 3G@&")#'9CN3$=/
M&(6Q!I8TPV>8 S(@#+@!&? LU8Z[QP)W"O!(:[QMR"FIO6..;L!K8"^4#T>T
MMCKPVN; 'JLNN*(%B).)H#FR W @8A\AC@"Y,D8*(4KSVDX\@2$QC=WT?<8)
M&: \,N_P]#]&-_]:']5@ WN-,3V$=G@)9UM)<H3P8[XQ![1WL>H#[NL9UZXG
MO+\5%_^NH9!9;?K+S3$_CY+ATMF&.W >PO'UC!^H'.P& (2$D>7>X3X05Q8J
M!\J @6A#H6$S;M=?AES+DBC;P82,/S=$B'1%'#D=VF[(R;"@ I.<@^'K1 E1
M:40]Y8 $T=I6LW'2;O5I1:5X_WH"@P$>H,ND(,4A]Q4-V]T9"V6A:BPCL*#8
M)$)7"W]:KR=M-;QH%DP@,%IK+2X(G  5Z#. QGR86$SCB%R+[F8<8MKJ6XF+
MAS"2)MQ3L!8CM(-Q,BZ_H0#VPI]@EEH0<4<$]0F5U;<6'-OI('K)HBY^NFY'
M#:,;5UP:EF,L,J>GJ-567VF\3C-,VVW%.? "R"!G*A<# PD$@<=P<I[6%*A[
M=@\$# %?U!"9$ZV3>=V!(08%$V*Z4HA,.!ID( _@&RK#XDY#$' .TO!L/)VB
M%-]0'DD2/?*+/!H-]9('/EPVB6@MD*3Q/D_$V\0?G[D)O6B<++6ZL?!\1E:Q
M&1)AK/$.9M($T(9U 3'QSIPANHE5 L/&.-F'ST'1F($CDO;BB)^  LD,*TV$
MLC$4K,O>.1V:T3 *1Z6H^>9=1*$/P6&<R+\)Q)S>7MPK:A/GE>R>A*<V9H9/
M.Q(-(TU0@7=%3*#CDJ@=],HQUC:G=CC ''1J",X!+,"_M3$@/",3F%A7('59
M-0XY/#9"1[!'(Q $T  7, /F7XQS(4+%9NR'EU #7$ :49.OY%R @#;Y1UR 
ME[$9XHANU:N)PTP,0QY " H!!%B!]Q #?-K[< ))  L@R9<P&<].[0"23"!-
M.(:H8J_HR]Q[CDAR'KZV@.(A-)]:"(9:2< <"S0@8(@(LK 9@+)].(31Z"/.
M5QP!+)6O5HR!%J&55E^BJ!6ID@+5#E#BM*#CL  !6V +M  RH*6"90L( UU@
M#Y"F"M0'BJ6PA /)LHPU2V I+.] LKP#TK(+= &=F "TX-&P;UH!BK7!LI%H
MQEX2"0)ST %6.E)WZ<96B*,#'TYE$42"( ;3&4$4@L/CJ]$_$9;F^MTFXDPT
M$AD2A"6R(<G"Q<M Y\@>A<0H ]I$&!3 +A<B8(:,.[ &"&*]? @B@/-UHC4@
M-PY,2:0#8PE?3I2"M?H$9D'HER4,=YT&@DF=#J;#6A\24U4,RV6H1,H =%H\
M#>@,2+8E<C,/@OY29Z5#)W2'&N._S.+JRU<J*ZJ(AM]B*'VA"9P#T-$'#(O+
M:'<,1^PK2O0/)M8$AA=WVB&2E)J] C60 :HY.@Q'3>B963,FQ,2/B3#1T>H#
MFRED9AY+<P0#7  CL9MN,@:DK!8 !_@*S&@!=X"1T)(XHMDR4U(T;3\3!4P4
MB3@>W!O;])LM96P11,$) ]8=@?*+D4[FU48E%PK7)6(\G#,LI*!!A%DW[V:;
M!"1M4E1P):-2S1X"#P /6.,-( L?(!!:YY=28+.S=N:&N/"ED +(R9TCP':^
MSMGT K951 &>PE,V$4>CY4*0Y^[$"CR T80/.O "IH+SS!NND]&0 3%P/77#
MEWHL<J-[\L[7V78$A/C$"B+ ZB +$: [L>=7&A=H@'T&3VKBEHYD\'R>KG,]
MM(?W@ 9H9Z_B3W9,%C%/I.4XF&<;W -!P BPAKE4QXK6F22@/4$,V,8#FD 7
M*!5HH +T@4*QI/7HHB(%5:".@8&Z"V>DR%Y1OWA<(FB$6C(6ALAVWB)#7RO4
MCS&O0,;R+! ,_3HAYI+5T)T7![; QNI8U>B&WI_>@0N+D@IX@RH4AW8Z-_#$
M2M!SL E 3(B&F*G01"?"$R4[J;("H8!VH0!T6!Y\@U6T#<* >-5%M5@>E* '
M+8P60S+J1=7@5E2CL(2-FE$UN"RAF+MHHRJ+-#&:.SH%KM7"4EF](@Y,A9J 
M(XJAN[AOJW!TT*(O8*N>TPR$1K:*C_I1?B$O]\YWRD9R2:MX(W!$!**'PLI6
M?B6=E4W@0)MN$L9*'KOKCYX-BFDQ3=W!2EC8J@V9NQ1"2H42080A>/1L] H-
M5DAAR2%=:'E0_;3!-Z8XHR(71:2;\&S6@<5C2!4 ,LV#Y6>+_M+KDP>I">OQ
M-.XB5FW"-B >B<@6\"E!5)OFP;>X:+PI.'47[@I>;4)Q$HUPX1>03+/&"/BK
M(N N"I3&4UG,LSG(*X0P%5" T3@#B!!MR($S8 <BYC-UHP-U# PR<7HV^L0_
MM0/NPGTQU(;Z@!X<,%6#;N#";3"+2DW58'.@,0C2,G$4>;7'RF?P&DY'P#'P
MBQ""4I& J2DJ(*!6O0TNNL=R3;&J9/^!:]@,&$!3FP-T@F-TH+/(@9U*4P4;
M[D$!%..?T@I8TJ<X5:Y: 2O@H:: +0 #M)2L 0$GH 6<@-?@OO98&WRH5%5+
M 8H8,,CVV*%S;+E*J.BQ)?8"3P 9. &H(E\I4V::@<HJ@=(<I0.H"E6;(0+F
M*K\9?&2 "[@!$4!3XTBS6PMKH*Q&MX=P N  7#V:K70KO($T@ *@JE"QJX<U
M(2C6MGH''FN^8J665-Q-ULJZ B[KT<RLB77U+5:L&@8>Z_Q<3T<R7^G1)#)K
MIF<5):VF5;:&RQ)46QG-%R"#S:BP@LL*U :Y5^YJ1NCG-=31&2-<WRAQ[5++
M=2((*I_R&OB 6X #>_1HAI#I^5ROJ(&*:%ITMD:.Z-HN" (*ZV#.55SV5B@*
MQ5Q * $L[K6*'C#SZEUF1%@XFNF5MWI7+6I9N>C_#%+Y"K66U>ED,.-J'#$#
M>)4.Z-7'PE?!@O\*%R6@ZH1-8TDLJ>6Q3);1=5H:2VBY![*EA;66>P!;8I=F
MV04$JPB(*0/5#H15X1K]Z$!/*:Q]H%S$V ?'3U! ",BOTVCUL5,P"D]]AKVB
MI[4CA! QEQ7CX L9?'=R@,O]F>1AWVKLD'V#5@<%<%.K(U,C%*Z:LD3D-7B%
M',555Y^'@BPH('V""Q#P9'%AE$T!A+6LMM@7.\AB;).U1W,U8MY5\9!7<2J#
M?9]C%LMNF%D384TLJNRFW8&F2KA*)@?4CY0%M&7@-=0*O=EE#VR"7;"Y@J\.
MBW#A%;X:8=AJ$<C$%M8UFZ/:;+EX@VVPS(*'I1-E]6RB'62#]@TV6E;5-O(<
M+FQ2:*"*VHR.YXMD59\"HQ7(9KQ!6/L%U,\9^ DTM0]8!P+Q$+KJEY4(87;2
MDEF;\ 9)+1'9HH%BL&[:$>)B.ZV,K1V#-LZN/@1+9Q6LG8VT7PG7BDL0H /*
M2 E@ WC S_:+\16\Q"US%;0UUJ^: *>*8]64H^VVD':H?B4<2V[-+;I5M[X+
M>/E3I5A%=11)%;))9'/F%NA!VN8@"@.ULT;4HAY$&V85+LB$M_9(U:Y5"4HR
M\H"K!0^\-M?:(VVJ EZ#"4"C/DSD[EH?$&M]+;!ML\/V,QG;QX)LQ6P8"!<2
MU]EV!VBK:=4LM66SU[9<C $[X&)-;;OH8,8K[IBNEP8\5NM!P2=#%@8JAT$*
M'\]D$IDHR6[7Z$N2B,(&K>)L"[.&>=H$3P%"G<!<LAE3@&=)#^IA/8CJ:PA3
M/'6M'ELYD&S'K-AUL6AVVB8&H)L W"SS= %WAXFV4N.Z#NM#3SV3@)>*5J#X
M"E]#27>% >*'QMJC;Z(MOJ[-, ',L\I2,N:IH[X4+%FU<[?NWMQ^4GGSKL_=
MN]:V[Q(O/Q%U51KEI1K%P>HZASZH%)EBS'JS,8J:I)"P*WO)K@5%NVJ7@+3=
MS_MV/Z_<I;ETU^:&B[N[1=,L:_RYJ=?O(M[ B\="*^$%K89WD/U=ZKMXWZL;
MB*_=U=W:4-S[>K]N&+B\F;<X3#*B=28[+]P%O<A7](:+\FMZGR_J#;:KEZ01
M2,TWTH0 $M0NZ03F3 048!%,H<IS.201!8B5U\ ;49A1?0@O=JVBJO_Q!%  
MYCV3LK"L$BDJ8'G[5#ZU"85U YM?](N!07!9#2%%(S$,CQ7RBMB+C5.7/D&G
MQ%[(IKEPKY'2J,-T1AP%%XN?2' +:0XM9<X$804QA%U#\8V[734!A%[E"]82
M$]YUOOF*T\+8U1=")&*ET9&R=PG.NT]S7@<MHW)41<J:>N 2? =7K1+>#OOW
MM^:NH\NRT/ 5:UP-F,FJW@YFA2?*V+J[6CCWI) N7&._\*/2O3[X,8%@,SP@
MCUB4"@/2%)\48OXF.2U>#7:S,;8/O+"P>5#2T<Y9Q%"J5T!;KX")\<:&D'E#
MK"@]1?0D*C#Q(=ZB"L!]'=0\:C-Z43P+9?@$I#0ZEP39*IC7[16+U%:U0<]C
M!WK9AAC!?0H7BR#+N2#]S_H%JDITY^$Q$>0X*V>?\L5MX/*J'_=K?&?N?TF^
MRI870^/FJW>K+?[%O7%VK7+;^Y9O^2H?H!C;KIF@!GU&,7KNMGVTWU;?B@#K
MJHOII38L >EVL#K27#S)"NLXKK.P\\[.8[9IC\UM/CZQZ_9WY2YHG'@%+\3T
MQ_ X((/;@4Q<"S(>.+<'6<"PVV*Z(1IR%66\W]?Q0C&#^X[Q;3PVQ^RX8[CC
M.1Q"-!ZK*1M;\>$)L_E '0&B3WI%&JR""6-X24/_F M07SEYUG"OX 55=REK
MF5&#;">[@!(*+ZO24FY!09DBQ*XW,+N4<D_N+#^9A6DP+II_9YU[=(,[U $#
MA:/:*V:=!=[)G==] 9Y\%4(4 G?[*'E YE6AAM#8]B\=M$Y_[&CR#L>"!R18
M1+%06 2?Z,97B 1MG;VT>!NOR76B_(;"MB\5';R$8704WCNH?:>OXFVOWA?\
MJM>E81OE*[:ML;0VGN5@;4$8.O#)?:3PDBG/VOOV&EXA:F:DDPR!6(0TML:D
M0,=JQL1855S@%@)\AT#/"A*V&3Y18R3L9>,O$R8=9* TU]\X(H4]+3BVF<M4
MSOYC;RN1Y;$/N,X##=U-4(.\@<QB GB8]:'<7F0<T7!GC'C&R'[V:+IB[Z"1
M%7(SLLP.V?"V9X'KF)EH]_T"C;?@<F51],),,25N5H;)3YABR:QE]>\5>PN?
M>,5MW1!694:QB!G0:S@5<]15F 9:,?GR#MHWAKH[%0 'I!$L#B&R&!-FX:X+
MFA4I)(W-LT8;1T73K)15\]$4AL>8T Y1IHR;GW%4E,;783C#WVLL?XU;+U[1
MRSD!-.=KBT\DG,7E-\0.YITFQO5*LIQ*0\X;+Q3/,!)MCT* D1I?N:M%MR(1
MA"QJ*. M6VJ54ZT85S*XIL 22,M4.#LAAEM3];3SLY-P*MB@;1AHG!__8 7#
MO0R9^V)F_!R2PV@($,KNM )UV:.9;:'S&3##<Y8<G^2O=(Z]@MFE @QJ(S 3
M#;*.G=)*SE?3N1PS:O6KC,3H> :X*)3LV"KAFJ@!<E 5R-:UE1ID@(NE.7(;
M\,AEC"3?K$R]J"GR9O:W&3DA"]P\?9EG#$C6S._6KI9JZGRJ)[)US<F>&A^S
M:O>LI0\9EW;*;@ JLQ99C:DC<K&6Q\<:Y"3K7!UPLS1J7LI;NBE[:>HF5$@U
MK:[.*#DE9XQ+/8<CUHOV$Q(.]@C42@=85)S_<XG$16MF#C?,WVYR4D":?D(Q
MNY9W+8=Q[XYUIU<)4:\_GD &>FV1#5ZGF1:!:V=-F?4R$J(\;L"NNMD.YI+9
M="4, QNZ8%]E7$$J@(-W@*.\VC[OZ?P<10,LR/;28ZSZQIWO1&:H<O9*V3*[
M8KMLIRQ^BVN@MJ.G]67[Y-'1PMJ@6,%>KEEB,^4N/;2E-1G@RFQ98@!L9,;=
M]M-N1,PHP'$T:^[&C"5DLBAY4WMD6\4)=%Y9;<>%5;5VG9A<L3UK2>[:1LTV
M8S:KL:5YFTDJQ[;:/@DQ=\Z=$!TF0DPNV_4Y9Q?7R)R[L"]EQB=C*V/2#!# 
M,5_/8&6;@!L^?^3,+)+U*XYM0U(Z"5XQ@U")92MH7L\S+.SNI](LAB/V,+9'
MK-D>F6A1'9L!A=RNS;=YIQ+CF+F;UT!O_LT_2S@?842]A)4M<E;.4#@*0U_A
MNK&?\\V4L_=64:/KKW2=:\5(F&'<>3!Y9_!,!\XS>4:7YAE7IV>W!;HCAZ[.
M78$[5L_GX!6X[S/+'LE3F"5C(6TFF)#@:6 "A6$-L)J:^!#J7:U*(JPFZ^4Q
M"8>#49A]+;:KKU ?[[4ZK#7U/$;'CSI2OQ)U7,K8];F^UN:84S\$9JBL]?$)
MY<?*2+@^\+VZJ57UI[;@W=I5P^J';%<W.*I>@!.!@O];$+Z1<;;Y[M."6H-;
M:PX^D)$U!>?6K7IK2VQH[;2I=0&OU=FZQ-SP94V^DC:77MI.F5S[<!-NK-7U
MNI:V975CAY"35P8,8J\P/0(P6A=M/ERE73.]4\ UVPED+QW^K+VT%M_*EQ<M
MHVGMZB=HS&72=_82)Y\PD?VMD;@9=]I&>RI7Y6\MMI=R!IO6=AN?0.F\78OW
MMK8+>I&[A8SPF2V59=<4,.(\66ACY9@=J^UJ^5[9,'PS6V5)3K)C=A0EU)_[
M0H=NL$::WP"+KN/A6L"$:MBLC&2W7B[&!*%VWVZ?%9R+DXXFX$K8./ONT6W*
M@S1S'MX:&Y3#64.-O'_X\A8!S5O*0._QW)VUVG?&+M:;(&!O.7">5_B)?>7=
M>SZ#;\DMOG4U^9;<+QQ83Z/T'8G[,[^&4F6S$@?HG3?K$(A7KN(/(86,+:<,
MC)+0Z @7,$/">3F[?!ZIMFANC_"\P"@4-?#\D.)\7$E8K89RIL*"2!5 678#
M<2#/U="(><<VM""3T/;MHN;1099+>X85"K("&D14F5NW0T5G3ZA-EDEIR+J^
MO"E?0Y.C8"ALHF1M,1IXTH#G_:'PJ:9#U56KP"RPSK;!SL$K!-(MD :Z@ M0
M8(H6AC63DD4E"#C'+1EH^Q>57+S<6=IVVI[JI[F'%O6XC<;F-AL3SI@U#&AU
MHZ[ QJ4L)2$+K*J!Y3]VIQ/ Q59"*("G1O&@:[RC<TE6WA#\*TU!+,!SOC)4
M&! NP!UO-WO>J;CHC%WGO8+>(1 J;A %$R<'9/>N+; 7>2[WTL1;O^=,59^#
M'7ZN"04TC6&/Z:S><1B"?O5ZPD%7&@G]CRUT&-+0$[MM>4VL1==.]'+1T4.&
M!LO0R5B'LO4C6D,CZH3>A&F H\]1E?71\V]8F$3)8J*X.Z!\@V1++XJ(Z2PG
MQ_2,,-,-J5NXZ4& 8^5TM[#3UVI/-P$_O26O:>94$QX:3JG!7C>H\U"B3M;1
M>O&U"$L]"?@/,SQHAWI1S\I%^ZIN95S^U#TNK97JK\'5_7=;F]79.U>GS70;
MK%MLFX"Q[9%</YH;&Q)_YF%^O.^ZJ:;A>QT$(($=:N&0@[8([%"\=ESVPOYW
M5.<Z'[KJ/>DZAR:0$K+1QF.Z0?&^BA@4WXP(2L2<J#U#!<P!@N+;,WI'W>BU
M0Z;;=.MNT\.4US&T.WX,E-<TT-V[ZJ -"@*B0R/B),_>[:W0(BCL?5PN' ]5
MX\= E?>T^7<N=*)#IYI 1)8(1>5"IM?T+S5K]*9.7P%RELH7]39X K!JB;?$
MV>EM() G!%^H8VL9#Z08?;T-5)QV7FO]G )@98_%N,03%K[NX:T* *(,F%__
M"J16W9">L7C^:HP.&< K$(B*5R*-R])NM01NU%Z)U0GT9&#3\XJ;ITA%Y9(2
MNFE;#:J 5/^XVI!E&I%;+840@5#?:Y@LC@\9*H!7P %;'QXV7@K10);PIYI&
M$>.^I!5-_D4$X2@/,F?/4!W"T)CVWXJA0K.#*[5W3@J9C*4GZDP=K4M@[H: 
MR(@@ #\U\PA4J[::O#9HFJDPP ''YR?Z8/" %%1#)E0A[P>N.F(ZFPI.!+ZX
M7-5D>-XC-R%-W(K>!V:93NOA %2%262@E\* P).U([[GG5E#H&;ACB4?\1\^
M\7#X<'ZM6GOGT*5FO2*%J@CD!"C&MQNF:$!9A69M,%<U?)3O%53^5BVKP5XX
MM,&1G\FV_;65Q%&;WPPS52\&H*TZUSE82 S( %KOZ7E"YZ((<TF!B\2-M^M?
MB>+4#KG%(:0.)*V_GK9(#/2\8NE+9F%O,QK^C8_U*LODUWI%7.R[8[HW104?
MU)OZ7@_KH7W:%_;$'M>+'F0?]Y4]\#@HS3[;HWUI7RZH/=H?^=A^76G[MY$R
M2*J0M_C6O>+CB#"%\34^E:CI'7\%N'J//_-#?E=5^[>FY O[[E0K:,!K !0V
M'^>35K,?\W/^K>%4?L0,G'ZLJA@]+=#O8%:;UG/ZH@^833S2=UR0JV$K9@22
M>-Z EF U%,ZWW4+IUN'BN=58V*?0YX5VB.+<@M3.T:B^"8M ?^'_L(U4J*;H
MLH@IKY/5[=OKOA7%J/O/G-J (+K$T#YQ1^G?] :P_U^O*E1 +QKVY<(9%1\#
M]/?Y__C5_P&(_K'5J  "(*JET9T-E(CJE #H?JO>ZM:D?")R$:]@=4!M+9G6
MX+'I.\>'S/.X<$BN218RTB@:;0#"8S?<016,3'?_M4$2(!%1T[T7;("4EZO<
M?^75_;?3#3+V'QH0^OE2$][-0\Q9>,0:#8<$X$(2A?!0_*T!^M"M<3IP 2) 
MGS66 %SI7Z#%[2U;/4DZ,SK1:;<.$-C\53 0%Q38;%%<*: 3F -J7$Y>O+4#
M5FLFV3$WS5TQ.!@^=Y%9<[-;P!6\Z"JI2(#W:K%<^IG=YO_%? "@ ')VJ&UB
MBMMVP;TB@,+JQLH]!%Z!Z5=6.8 LU[@&I@UNN(L"%DD<$JY$884(.F52""!"
MTW5 H1JLY:6I(1X>R=<[$&Y\5P%R?.1#/D#XP0A*9JF7*#B -"D#WRF8N]@ 
MA94 B ?*(OE'1C4 VCJCX/B5T44$E$H1<@G&$0)@DS(L;&9N8*Z" L2!1!3(
M10<*:G9;2X:WO3SL3V T>3TPMH[TQS:8;%.:'.9U68*B6RG7@:UNLYM!( CJ
M8H ",94'"H %&@T0#L(2EQ<TIGD1+1G4T8*^[6X$7._&'BQ?O!PW9E<-:7'$
MQB; V75D(%Y'PR5SSYMS$+T5?-,;-,>=E6?4G/:FC^EE@(@V)\)17]U<,>C"
M87+B'$DF8\5<Q58'DW-17*_!AN0AX##:H!A8X06$%YY =@;R-QV>@ /B06&1
#F*@ 
 
end
--- END cut here ---
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jul 90 2:48:26 GMT
From:      Mills@udel.edu
To:        sgi!rpw3%rigden.wpd.sgi.com@ucbvax.berkeley.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Mobile TCP/IP (was Re: Can subnets be separated by another net?)
Rob,

Thanks for the interesting info. The primary reason my antenna was up at
the time you guys were fiddling was that I suspected you eventually
would intend to lay paw on the juicy amatuer radio allocation 10.0-10.5 GHz.
Fortunately, that push never came to shove. Now, about 220-222 MHz...

Dave
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 02:59:35 GMT
From:      elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com  (Michael O'Brien)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
Now, I may be going silly in my old age, but didn't SAIL used to have a port
number you could Telnet to that would give you the inside (machine room)
and outside temperatures through some digitally interfaced silliness?  Surely,
SAIL being the premier computer science installation that it is (was), there
MUST have been a protocol number duly assigned to this service...
--
Mike O'Brien
obrien@aerospace.aero.org
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jul 90 11:34:29 -0400
From:      phone-book@NNSC.NSF.NET
To:        tcp-ip@nic.ddn.mil
Subject:   Internet Managers' Phone Book

Hi,

The NSF Network Service Center (NNSC) is in the process of compiling a
phone book for network managers. The phone book will list the technical
contacts for all domains and IP addresses, along with indexes.
Our plan is to publish the phone book in late August and distribute it,
free of charge, to the technical contacts listed in it (others can
buy a copy at cost).

The phone book attempts to list the *technical* contacts for every
IP network and every DNS domain to at least the primary organization
level (i.e. foo.edu, but not necessarily cs.foo.edu).

If you are such a contact, by the time you see this note you should
have received an e-mail note from us, asking you to confirm the information
we have on you.  If you have not received such a letter please fill
out the template below and send it to us.

Note we've also listed some domains and IP network numbers for which
we lack an e-mail address to request contact names from.  (In some cases
it is because we couldn't reach DNS servers at the time we were accumulating
information -- it doesn't necessarily).  If you see your domain or
IP address in the list, please let us know.

Thanks!

The NNSC Phone-Book Project (phone-book@nnsc.nsf.net)

NAME:
ADDRESS:
PHONE:
FAX:
E-MAIL:

I am responsible for the following domains:

I am responsible for the following IP network numbers:

******************************

Domains/Network for which we lack e-mail addresses of contacts:

128.172
128.191
128.192
128.202
128.207
128.209
128.225
128.23
128.232
128.251
128.254
128.37
128.82
128.88
128.9
128.90
128.94
128.97
129.136
129.163
129.164
129.165
129.166
129.167
129.168
129.17
129.182
129.183
129.184
129.185
129.200
129.212
129.228
129.230
129.231
129.235
129.239
129.249
129.251
129.253
129.27
129.45
129.50
129.58
129.80
129.9
129.90
130.1-130.10
130.105
130.114
130.115
130.118
130.120
130.13
130.131
130.148
130.156
130.16
130.162
130.181
130.188
130.19
130.190
130.196
130.201
130.204
130.211
130.212
130.214
130.218
130.22
130.36
130.40
130.47
130.48
130.51
130.52
130.57
130.66
130.76
130.77
130.79
130.80
130.96
130.98
131.101
131.102
131.11
131.117
131.126
131.127
131.129
131.143
131.147
131.148
131.149
131.150
131.153
131.157
131.16
131.160
131.163
131.168
131.17
131.177
131.184
131.189
131.190
131.191
131.197
131.20
131.201
131.213
131.214
131.219
131.221
131.223
131.233
131.237
131.238
131.240
131.241
131.242
131.244
131.245
131.253
131.40
131.47
131.52
131.57
131.58
131.64
131.65
131.66
131.67
131.68
131.69
131.70
131.71
131.72
131.73
131.75
131.76
131.77
131.79
131.80
131.81
131.82
131.83
131.84
131.85
131.86
131.87
131.88
131.89-131.90
131.97
132.10
132.12
132.13
132.145
132.148
132.149
132.150
132.153
132.155
132.158
132.159
132.16
132.164
132.165
132.168
132.169
132.171
132.172
132.179
132.182
132.185
132.189
132.201
132.228
132.229
132.23
132.232
132.233
132.244
132.27
132.31
132.33
132.40
132.48
132.5
132.6
132.79-132.143
132.9
134.113
134.115
134.116
134.119
134.120
134.122
134.125
134.128
134.137
134.142-134.146
134.150
134.154
134.156
134.158
134.168
134.170
134.171
134.176
134.178
134.179
134.180
134.183
134.186
134.187
134.189
134.200
134.201
134.204
134.206
134.209
134.210
134.213
134.214
134.215
134.216
134.217
134.224
134.229
134.230
134.238
134.239
134.243
134.244
134.247
134.249
134.25
134.254
134.26
134.27
134.33
134.35
134.37-134.46
134.47
134.5
134.57
134.59
134.6
134.62
134.63
134.64
134.7
134.71
134.77
134.8
134.81
134.85
134.97
136.141
136.143
136.146
136.147
136.157
136.158
136.163
136.164
136.166
136.171
136.173
136.174
136.179
136.180
136.181
136.183
136.184
136.185
136.186
136.198
136.208
136.213
136.220
136.225
136.226
136.228
136.230-136.239
136.245
136.249-136.254
137.105
137.114
137.115
137.116
137.117
137.118
137.119
137.126
137.129
137.130
137.133
137.135
137.15
137.156
137.158
137.16
137.160
137.168
137.169
137.170
137.171
137.172
137.173
137.174
137.176-137.185
137.188
137.19
137.199
137.20
137.201
137.202
137.207
137.217
137.218
137.221
137.227
137.25-137.27
137.31
137.32
137.33
137.34
137.40
137.42
137.47
137.70
137.71
137.72
137.74
137.83
137.91
137.93
137.96
137.97
138.10
138.12
138.14
138.19
138.22
138.30
138.31
138.32
138.33
138.37
138.39
138.46
138.6
138.62
138.63
138.64
138.66
138.69
138.7
138.76
138.8
138.81
138.82
138.83
138.84
138.85
138.86
139.102
139.105-139.120
139.122
139.123
139.125
139.126
139.131
139.134
139.143
139.144
139.145
139.149
139.150
139.164
139.166
139.168
139.68
139.69
139.71
139.72
139.73
139.74
139.76
139.78
139.81
139.85
139.96
139.98
19
190.55
192.12.101
192.12.121
192.12.122
192.12.129
192.12.13
192.12.131
192.12.14
192.12.155-192.12.170
192.12.172
192.12.217
192.12.218
192.12.219
192.12.236
192.12.251
192.12.28
192.12.6
192.12.7
192.12.89
192.12.90
192.12.93
192.12.99
192.16.152
192.16.172
192.16.174
192.16.175
192.16.177
192.16.183
192.16.185-192.16-192.16.190
192.16.192-192.16.200
192.19.0-192.19.255
192.21.0-192.21.255
192.22.0-192.22.255
192.23.0-192.23.255
192.24.0-192.24.255
192.25.0-192.25.255
192.26.0
192.26.149
192.26.150
192.26.151
192.26.20
192.26.25
192.26.50-192.26.82
192.26.90
192.26.91
192.26.96
192.26.97
192.26.98
192.28.0-192.28.99
192.30.0-192.30.255
192.31.1
192.31.105
192.31.108
192.31.110
192.31.113
192.31.114
192.31.115
192.31.148
192.31.149
192.31.150
192.31.166
192.31.167
192.31.168
192.31.169
192.31.17
192.31.170
192.31.171
192.31.174
192.31.209
192.31.211
192.31.22
192.31.229
192.31.233
192.31.238
192.31.24
192.31.240
192.31.245
192.31.247
192.31.248
192.31.25
192.31.27
192.31.29
192.31.37
192.31.38
192.31.44
192.31.77
192.31.78
192.31.79
192.31.83
192.31.84
192.31.91
192.31.95
192.32.0-192.32.255
192.33.128
192.33.14
192.33.187
192.33.19
192.33.190
192.33.2
192.33.240
192.33.37-192.33.86
192.34.0-192.34.255
192.35.102
192.35.108
192.35.109-192.35.126
192.35.141
192.35.60
192.35.62
192.35.83
192.35.87
192.41.148
192.41.172
192.41.198
192.41.199
192.41.210
192.41.212
192.41.224
192.41.239
192.41.240
192.41.241
192.41.242
192.41.243
192.41.246
192.41.250-192.41.255
192.42.1
192.42.101
192.42.102
192.42.133
192.42.134
192.42.135
192.42.136
192.42.138
192.42.139
192.42.148
192.42.149
192.42.150
192.42.153
192.42.154
192.42.158
192.42.202
192.42.203
192.42.204
192.42.205
192.42.206
192.42.238
192.42.240
192.42.243
192.42.252
192.42.253
192.42.4
192.42.52
192.42.53
192.42.54
192.42.65
192.42.90
192.42.94
192.42.99
192.43.1-192.43.150
192.43.161
192.43.200
192.43.213
192.43.218
192.43.219
192.43.220
192.43.221
192.43.222
192.43.224
192.43.237
192.43.248
192.43.253
192.43.254
192.44.252
192.44.91-192.44.215
192.46.0-192.46.255
192.48.101
192.48.104
192.48.109
192.48.110
192.48.123
192.48.124
192.48.125
192.48.127-192.48.129
192.48.130-192.48.132
192.48.133
192.48.137
192.48.141
192.48.142
192.48.143
192.48.145
192.48.211
192.48.221
192.48.225
192.48.235
192.48.239
192.48.240
192.48.241
192.48.242
192.48.243
192.48.244
192.48.245
192.48.247
192.48.248
192.48.251
192.48.252
192.48.253
192.48.254
192.48.31
192.48.32
192.48.35-192.48.36
192.48.37
192.48.38-192.48.77
192.48.92
192.48.94
192.48.97
192.5.103
192.5.106
192.5.142
192.5.147
192.5.149
192.5.150
192.5.164
192.5.209
192.5.213
192.5.218
192.5.223
192.5.242
192.5.243
192.5.244
192.5.245
192.5.246
192.5.247
192.5.248
192.5.249
192.5.250
192.5.251
192.5.252
192.5.253
192.5.3
192.5.4
192.5.41
192.5.5
192.5.6
192.5.63
192.5.7
192.5.8
192.5.83
192.5.94
192.5.95
192.52.108
192.52.113
192.52.116
192.52.151
192.52.152
192.52.153
192.52.154
192.52.170
192.52.177
192.52.181
192.52.184
192.52.196
192.52.197
192.52.229
192.52.230
192.52.231
192.52.238
192.52.239
192.52.240
192.52.244
192.52.246
192.52.250
192.52.253
192.52.254
192.52.51-192.52.60
192.52.67
192.52.68
192.52.74
192.53.0-192.53.255
192.54.110
192.54.121
192.54.122
192.54.124
192.54.129
192.54.132
192.54.133
192.54.134
192.54.138
192.54.225
192.54.228
192.54.238
192.54.245
192.54.246
192.54.82
192.54.83
192.54.84
192.54.85
192.54.86
192.54.87
192.54.88
192.54.89
192.54.90
192.54.91
192.55.1-192.55.21
192.55.101
192.55.102
192.55.110
192.55.111
192.55.115
192.55.121
192.55.131
192.55.134
192.55.136
192.55.137-192.55.186
192.55.189
192.55.193
192.55.195
192.55.196
192.55.197
192.55.198
192.55.199
192.55.201
192.55.202
192.55.203
192.55.206
192.55.209
192.55.216
192.55.218
192.55.22-192.55.31
192.55.220
192.55.224
192.55.225
192.55.227
192.55.229
192.55.236
192.55.243
192.55.244
192.55.245
192.55.246
192.55.249
192.55.83
192.55.88
192.56.0-192.56.255
192.58.1
192.58.102
192.58.105
192.58.106
192.58.121
192.58.122
192.58.123
192.58.149
192.58.151-192.58.154
192.58.155
192.58.156-192.58.179
192.58.181
192.58.183-192.58.192
192.58.19-192.58.27
192.58.193
192.58.195
192.58.197
192.58.199
192.58.2
192.58.200-192.58.203
192.58.211
192.58.215
192.58.216
192.58.217
192.58.230
192.58.232-192.58.241
192.58.244
192.58.245
192.58.246
192.58.249
192.58.250
192.58.251
192.58.253
192.58.254
192.58.28-192.58.35
192.58.3
192.58.37-192.58.40
192.59.0-192.63.255
192.6.0-192.6.148
192.6.150-192.6.200
192.6.202-192.6.255
192.64.0-192.64.255
192.65.1-192.65.49
192.65.132
192.65.135
192.65.136
192.65.148
192.65.149
192.65.150
192.65.151
192.65.152
192.65.154-192.54.170
192.65.173
192.65.174
192.65.178
192.65.179
192.65.180
192.65.204-192.65.210
192.65.211
192.65.212
192.65.213
192.65.214
192.65.215
192.65.217
192.65.245
192.65.246
192.65.249
192.65.250
192.65.251
192.65.252
192.65.253
192.65.254
192.65.50
192.65.72
192.65.75
192.65.76
192.65.79
192.65.98
192.67.1
192.67.10
192.67.107-192.67.126
192.67.127
192.67.130
192.67.134
192.67.135
192.67.136-192.67.155
192.67.15
192.67.156
192.67.157
192.67.158
192.67.16
192.67.166
192.67.168
192.67.17
192.67.174
192.67.175
192.67.176
192.67.177
192.67.178
192.67.179
192.67.18
192.67.180
192.67.181
192.67.182
192.67.183
192.67.19
192.67.2
192.67.209
192.67.210
192.67.211
192.67.212
192.67.213
192.67.214
192.67.215
192.67.216
192.67.219
192.67.22
192.67.220
192.67.221
192.67.224
192.67.228
192.67.23
192.67.24
192.67.248
192.67.253
192.67.254
192.67.3
192.67.4
192.67.44
192.67.46
192.67.51
192.67.52
192.67.55
192.67.56
192.67.57
192.67.60
192.67.73
192.67.80
192.67.84
192.67.85
192.67.86
192.67.87
192.67.90
192.67.91
192.67.93
192.67.94
192.67.95
192.68.109
192.68.112
192.68.113
192.68.114
192.68.115
192.68.116
192.68.118-192.68.125
192.68.134
192.68.135
192.68.136
192.68.137
192.68.138
192.68.139
192.68.140
192.68.141
192.68.146
192.68.147
192.68.148
192.68.154
192.68.155
192.68.157
192.68.161
192.68.175
192.68.177
192.68.180
192.68.182
192.68.183
192.68.184
192.68.187
192.68.20
192.68.21
192.68.22
192.68.23
192.68.75
192.68.76-192.68.107
192.69.0-192.69.255
195.5.68
20
13.130.in-addr.arpa
14.33.192.in-addr.arpa
143.48.192.in-addr.arpa
152.16.192.in-addr.arpa
154.134.in-addr.arpa
158.132.in-addr.arpa
161.68.192.in-addr.arpa
172.128.in-addr.arpa
177.131.in-addr.arpa
181.130.in-addr.arpa
188.130.in-addr.arpa
188.16.192.in-addr.arpa
19.33.192.in-addr.arpa
192.128.in-addr.arpa
195.58.192.in-addr.arpa
201.132.in-addr.arpa
204.130.in-addr.arpa
212.130.in-addr.arpa
214.131.in-addr.arpa
235.129.in-addr.arpa
239.129.in-addr.arpa
24.31.192.in-addr.arpa
246.58.192.in-addr.arpa
27.31.192.in-addr.arpa
5.5.192.in-addr.arpa
50.65.192.in-addr.arpa
6.5.192.in-addr.arpa
64.131.in-addr.arpa
65.131.in-addr.arpa
66.131.in-addr.arpa
67.131.in-addr.arpa
68.131.in-addr.arpa
69.131.in-addr.arpa
7.12.192.in-addr.arpa
7.134.in-addr.arpa
70.131.in-addr.arpa
71.131.in-addr.arpa
72.131.in-addr.arpa
73.131.in-addr.arpa
75.131.in-addr.arpa
76.131.in-addr.arpa
77.131.in-addr.arpa
79.131.in-addr.arpa
8.5.192.in-addr.arpa
80.131.in-addr.arpa
80.67.192.in-addr.arpa
81.131.in-addr.arpa
82.128.in-addr.arpa
82.131.in-addr.arpa
83.131.in-addr.arpa
84.131.in-addr.arpa
85.131.in-addr.arpa
86.131.in-addr.arpa
87.131.in-addr.arpa
88.131.in-addr.arpa
9.128.in-addr.arpa
93.67.192.in-addr.arpa
97.128.in-addr.arpa
105.130.in-addr.arpa
115.134.in-addr.arpa
118.130.in-addr.arpa
121.12.192.in-addr.arpa
122.12.192.in-addr.arpa
125.48.192.in-addr.arpa
ALLIANT.COM
ALLIED.COM
AMOCO.COM
AlphaCDC.COM
BRS.COM
CAS.ORG
CSUHAYWARD.EDU
DSC.COM
GEORGETOWN.EDU
INTERLAN.COM
IPTECH.COM
KESMAI.COM
MALONE.EDU
MENTOR.COM
NM.ORG
NYNEXST.COM
PEREGRINE.COM
POLYGEN.COM
SCO.COM
SERI.GOV
StPaul.GOV
USI.COM
VSE.COM
-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 04:56:01 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Temperature Quote Protocol

      SIO Pier Weather:   Tue Jul 24 21:00:00 1990

        Air Temperature:  18.2 DegC  (64.8 DegF)

        Wind:   004.9 Mi/Hr   From 179.9 Degrees

        Barometer:                  29.89 Inches

        Water Temperature:
               Surface =  22.4 DegC  (72.3 DegF)
               Bottom  =  22.3 DegC  (72.1 DegF)

        Tide Gauge:                    05.58 Ft.

        Last Wave Data Record:  Tue Jul 24 19:14
               Sig Ht:  54.8 Cm   Period:  7 Sec
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jul 90 09:21:32 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        sci34hub!eng3!joe@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   How do you get a ENet Addr?
Joe (and anyone else who's interested),

The most recent communication I had from Xerox got me some protocol types.  As
of March 1990, the address was:

	Xerox Corporation
	Xerox Systems Institute
	475 Oakmead Parkway
	Sunnyvale, CA 94086

	(408) 737-4652

The letter was signed by Fonda Lix Pallone, Customer Administration.

That should get you to the right neighborhood.

	Bob

-----------
Bob Stewart (rlstewart@eng.xyplex.com)
Xyplex, Boxborough, Massachusetts
(508) 264-9900

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jul 90 09:42:21 EDT
From:      SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
To:        TCP/IP List <tcp-ip@nic.ddn.mil>
Subject:   NCSA KA9Q
Can someone elaborate on the acronyms (?) NCSA & KA9Q used when
discussing tn3270?

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jul 90 13:48:20 PDT
From:      postel@venera.isi.edu
To:        sci34hub!eng3!joe@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  How do you get a ENet Addr?

Hi.

Ethernet Address blocks are now assigned by the IEEE (212-705-7092).

Ethernet Types are still assigned by Xerox (408-737-4652).

--jon.
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 06:59:11 GMT
From:      zaphod.mps.ohio-state.edu!samsung!emory!km@tut.cis.ohio-state.edu  (Ken Mandelberg)
To:        tcp-ip@nic.ddn.mil
Subject:   CSLIP problem on SunOS 4.1
I just brought up the beta cslip code for SunOS 4.0 on SunOS 4.1.  on a
SS1. I changed nothing, it all slipped into the 4.1 kernel without
change.

When I test it doubled back on itself (null modem from ttya to ttyb),
all seems well until I try a telnet and cat a long file to he
terminal.  The output pauses on many multiples of around 250 bytes,
sometimes for several seconds. An "rsh cat" of the same file runs at
the baudrate with no hesitation, as do ftp's.

I also have a SunOS 4.0.x system (as it happens a 386i) running the
same cslip code. When I connect it to the 4.1 system, the telnet
problem only shows in one direction. If the output is generated on 4.1
the pauses occur. If I telnet from 4.1 to 4.0 and do the cat on 4.0,
there are no pauses.

I don't have an easy way to run a 4.0 kernel on the SS1 right now, so I
can't be completely sure that its not a sparc specific problem rather
than an OS interaction.

Any ideas.
-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: (404) 727-7963
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 07:02:59 GMT
From:      eru!luth!sunic!mcsun!ukc!slxsys!jpp@BLOOM-BEACON.MIT.EDU  (John Pettitt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
postel@VENERA.ISI.EDU writes:
>Network Working Group                                          J. Postel
>Request for Comments: XXXX                                           ISI
>                                                               July 1990

>Temperature Syntax and Semantics

>The temperature quote is the current temperature at the location of
>the server reported in degrees Celsius (or centigrade).

>It is transmitted as decimal digits represented as ASCII printing
>characters, preceded with a plus or a minus sign.

How about an international option:

For the UK it could say `Phew what a scorcher' if the temp
is over 68 F and `Brass Monkeys' if it is below.

This does assume that JNT will allow some nasty American protocol
on their network ...  (world == rutherford.ac.uk)


-- 
John Pettitt, Specialix International, 
Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781
Disclaimer: Me, say that ?  Never, it's a forged posting !
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 07:17:36 GMT
From:      uhccux!virtue!comp.vuw.ac.nz!munnari.oz.au!mel.dit.csiro.au!smart@ames.arc.nasa.gov  (Robert Smart)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Come on guys, we've got to improve e-mail
In article <159@tots.UUCP> tep@tots.Logicon.COM (Tom Perrine) writes:
>
>Perhaps we need to take this discussion to one of the above
>newsgroups, or start a new mailing list, perhaps mail-modernization or
>somesuch?
>
Comp.mail seems to be unused. It would be nice if people working on
the problem would let us hoi polloi know where we are headed. This is
such a complicated and multi-faceted problem that it can only be
solved correctly on the basis of wide public discussion. Three or
ten or even thirty experts in a back room are not going to understand
all the ramifications. I would like to see wide discussion before we
get to draft RFCs.

I apologise for being sexist. Come on gals as well.

I apologise for suggesting that X.400 designers are not sensible. I meant
that they weeren't sensible to the need for backward compatibility with
existing Internet mail systems. Even this is not true. Jacob Palme is
the only one that posts descriptions of X.400 meetings to the network and
those postings show a lot of common sense and good will.

I apologise for posting to the wrong newsgroup. Followups are directed
to comp.mail. Mail is important to the general workings of a TCP/IP
network and I am concerned that the people who care about the TCP/IP
suite have written SMTP/RFC822 off prematurely. I think that enhancing
SMTP will improve interoperability with X.400 mail and simultaneously
provide a backstop in case X.400 is not as successful as many obviously
expect.

I apologise for ignoring RFC1049 which is a relevant attempt to move
things in the right direction.

Bob Smart <smart@mel.dit.csiro.au> or <uunet!munnari!ditmela.oz!smart>
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 07:30:09 GMT
From:      eru!luth!sunic!mcsun!ukc!slxsys!iann@bloom-beacon.mit.edu  (Ian Nandhra)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
postel@VENERA.ISI.EDU writes:



>Network Working Group                                          J. Postel
>Request for Comments: XXXX                                           ISI
>                                                               July 1990

>                     Temperature Quote Protocol

>Status of this Memo

>This RFC suggests an Experimental Protocol for the Internet community.
>Hosts on the Internet that choose to implement a Temperature Quote

>    [ lots of stuff deleted, best get the real RFC....]

Now were getting somewhere. However TQP should be regarded as
a stepping stone to the more worthwhile Temperature Syncronisation Protocol
or TSP. There would obviously have to be a few regional variations
to cope with localised concentrations (outbreaks??) of SPARC stations, etc
but these could be agreed with a little give-and-take. Prehaps a
temperature standard of 19C would be acceptable to all. 

If sucessfully implemented, such a protocol would also contribute 
towards reducing Global Warming.

Ian.



-- 
Ian Nandhra,    Specialix, 3 Wintersells Road, Byfleet, Surrey, KT14 7LF, UK
{backbone}!mcsun!ukc!slxsys!iann                        iann@specialix.co.uk
Tel: +44 (0) 9323 54254     Fax: +44 (0) 9323 52781   Telex: 918110 SPECIX G
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jul 90 11:53:00 EDT
From:      <FILLMORE%EMRCAN.bitnet@ugw.utcs.utoronto.ca>
To:        tcp-ip@NIC.DDN.MIL
Subject:   BSMTP description wanted
Can someone direct me to a document that defines the BSMTP protocol,
or at least describes the differences between it and SMTP?
Thanks in advance.

________________________
Bob Fillmore, Systems Software & Communications     BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                         BIX:     bfillmore
  Energy, Mines, & Resources Canada                 Voice:   (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4   FAX:     (613) 996-2953
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jul 90 15:17:59 -0400
From:      vcerf@NRI.Reston.VA.US
To:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Cc:        iab@venera.isi.edu, iesg@NRI.Reston.VA.US
Subject:   RARE Networkshop Announcement
===============================================

Call for Papers and Conference Announcement. 

2nd Joint European Networking Conference
Blois, France 
May 13-16, 1991


Organized by RARE (Reseaux Associes pour la Recherche Europeenne)
in cooperation with :
  o EARN
  o EUnet (EUUG), 
  o Internet Activities Board,
  o Nordunet,
  o Ministere de la Recherche et de la Technologie (France)


Goals

This conference is a successor to the conference organized by EARN and RARE
in May 1990 at Killarney, providing a forum for the presentation and dis-
cussion of technical and strategic topics related to the provision of net-
working services in research and higher education, as well as corresponding
research and development activities.

The conference addresses mainly technical and managerial staff from local,
national and transnational service provision organizations, but will also
be of high interest to the research engineer, specialised users and members
of funding authorities.


Topics

The conference will cover a wide range of topics of actual interest to aca-
demic network service provision. As a key issue it will concentrate on 
"THE CHALLENGE OF THE WORKSTATION TO NETWORKING" : 
user aspects of a distributed workstation environment,
requirements on the local and wide-area infrastructure and related
services, impacts on management and service provision strategies.
Much emphasis will be placed on continuing and enhancing the discus-
sion between members of different networking communities, building on the
positive experience of Killarney.


Conference Venue

The event will take place in the historic region of the "Chateaux de la Loire"
at Blois, France. The conference itself will be organized in the
ancient building of the "Halle aux Grains", converted into a modern conference
center with ample space for small meetings in the margin of the conference.

The conference aims at an attendance of not more than 400 participants. A
first invitation with information on how to register will be distributed
in December. Places will be allocated on a first come - first served basis.
Please contact the RARE Secretariat if you wish to ensure that you will
receive an invitation.


Call for Papers, Proceedings.

As for RARE conferences in the past, the programme will be a combination of
sollicited and submitted papers. 1-page summaries of proposed papers should
arrive at the programme chair not later than Oct. 29. It is intended to
produce proceedings of the conference.

Topics for submitted papers: all papers fitting in the general outline of
the conference, in particular:
  - Emerging services and new applications
  - Information services
  - Distributed communications
  - The role of network service provision in a workstation environment:
           operations, management, security, user support
  - Workstations and the LAN/MAN/WAN infrastructure
  - Workstations and distributed applications/services
  - High performance technology and networking
  - OSI application layer services, transition
  - Access to services : from the national to the intercontinental level
           (fat pipes, backbones, service coordination)
  - TCP/IP and European connectivity
  - TCP/IP - OSI interworking
  - Standards, coordination and harmonization of protocols
  - User support strategies and facilities
  - Improving the efficiency of end-user services through coordination
  - Cosine progress
  - Network management:technology, operational issues
  - Security and privacy
  - The new situation in Europe: the impact on networking services
  - Policy issues and financial aspects


For further information contact:

			   	           Programme chair:
	
RARE Secretariat                           Prof. Juergen Harms
Postbus 41882                              CUI
NL 1009 DB Amsterdam                       12 rue du Lac
                                           CH-1207 Geneve
tel +31 20 592 5078                        tel +41 22 787 6580, 6581
fax +31 20 592 5043                        fax +41 22 735 3905
email raresec@nikhef.nl                    email harms@cui.unige.ch


Programme committee:
Vint Cerf         Juergen Harms      Christian Michau    Sven Tafvelin
Robert Cooper     Dennis Jennings    Claus Sattler	 Paul Van Binst
Marieke Dekker	  Sylvain Langlois   Peter Stone



-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 13:42:21 GMT
From:      SSJACK@ECUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   NCSA KA9Q

Can someone elaborate on the acronyms (?) NCSA & KA9Q used when
discussing tn3270?

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 13:58:21 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Temperature Protocol

In article <8078@ncar.ucar.edu>, davis@groucho.ucar.edu (Glenn P. Davis) writes:
> You probably don't want to hear this, but there are a number of
> protocols and formats for weather info defined by the
> "World Meterological Organization" (WMO).

I hope we don't have to use ASN.1 to encode them....

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 14:39:23 GMT
From:      Craig_Everhart@TRANSARC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Is underscore legal in the local-part of an address?

RFC822 says that periods are legal but somewhat restricted in
local-parts.  You can't legally have two periods following each other,
and you can't have the local-part begin or end with a period.  Thus,
	joe.blow@toaster.com
is legal, while
	joe..blow@toaster.com
	jane.smith.jr.@toaster.com
are not.  (The local-part is made up of a sequence of period-separated
``word''s, and an unquoted ``word'' may not contain a period.)

As to the ``phrase'' that precedes a route-addr, the syntax is slightly
different (a space-separated sequence of ``word''s), and a period
anywhere in it needs to be quoted.  This is traditionally done by
quoting the entire phrase text.  Thus,
	Joe Blow <joe@toaster.com>
	"Jane Smith Jr." <jane@toaster.com>
are legal, but
	Jane X. Smith <jane@toaster.com>
is not.

Then again, your programmer who believed that all other mailer
implementations strictly follow RFC 822 was a bit naive.  ``Liberal in
what you accept, conservative in what you generate.''

		Craig

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 15:34:29 GMT
From:      phone-book@NNSC.NSF.NET
To:        comp.protocols.tcp-ip
Subject:   Internet Managers' Phone Book


Hi,

The NSF Network Service Center (NNSC) is in the process of compiling a
phone book for network managers. The phone book will list the technical
contacts for all domains and IP addresses, along with indexes.
Our plan is to publish the phone book in late August and distribute it,
free of charge, to the technical contacts listed in it (others can
buy a copy at cost).

The phone book attempts to list the *technical* contacts for every
IP network and every DNS domain to at least the primary organization
level (i.e. foo.edu, but not necessarily cs.foo.edu).

If you are such a contact, by the time you see this note you should
have received an e-mail note from us, asking you to confirm the information
we have on you.  If you have not received such a letter please fill
out the template below and send it to us.

Note we've also listed some domains and IP network numbers for which
we lack an e-mail address to request contact names from.  (In some cases
it is because we couldn't reach DNS servers at the time we were accumulating
information -- it doesn't necessarily).  If you see your domain or
IP address in the list, please let us know.

Thanks!

The NNSC Phone-Book Project (phone-book@nnsc.nsf.net)

NAME:
ADDRESS:
PHONE:
FAX:
E-MAIL:

I am responsible for the following domains:

I am responsible for the following IP network numbers:

******************************

Domains/Network for which we lack e-mail addresses of contacts:

128.172
128.191
128.192
128.202
128.207
128.209
128.225
128.23
128.232
128.251
128.254
128.37
128.82
128.88
128.9
128.90
128.94
128.97
129.136
129.163
129.164
129.165
129.166
129.167
129.168
129.17
129.182
129.183
129.184
129.185
129.200
129.212
129.228
129.230
129.231
129.235
129.239
129.249
129.251
129.253
129.27
129.45
129.50
129.58
129.80
129.9
129.90
130.1-130.10
130.105
130.114
130.115
130.118
130.120
130.13
130.131
130.148
130.156
130.16
130.162
130.181
130.188
130.19
130.190
130.196
130.201
130.204
130.211
130.212
130.214
130.218
130.22
130.36
130.40
130.47
130.48
130.51
130.52
130.57
130.66
130.76
130.77
130.79
130.80
130.96
130.98
131.101
131.102
131.11
131.117
131.126
131.127
131.129
131.143
131.147
131.148
131.149
131.150
131.153
131.157
131.16
131.160
131.163
131.168
131.17
131.177
131.184
131.189
131.190
131.191
131.197
131.20
131.201
131.213
131.214
131.219
131.221
131.223
131.233
131.237
131.238
131.240
131.241
131.242
131.244
131.245
131.253
131.40
131.47
131.52
131.57
131.58
131.64
131.65
131.66
131.67
131.68
131.69
131.70
131.71
131.72
131.73
131.75
131.76
131.77
131.79
131.80
131.81
131.82
131.83
131.84
131.85
131.86
131.87
131.88
131.89-131.90
131.97
132.10
132.12
132.13
132.145
132.148
132.149
132.150
132.153
132.155
132.158
132.159
132.16
132.164
132.165
132.168
132.169
132.171
132.172
132.179
132.182
132.185
132.189
132.201
132.228
132.229
132.23
132.232
132.233
132.244
132.27
132.31
132.33
132.40
132.48
132.5
132.6
132.79-132.143
132.9
134.113
134.115
134.116
134.119
134.120
134.122
134.125
134.128
134.137
134.142-134.146
134.150
134.154
134.156
134.158
134.168
134.170
134.171
134.176
134.178
134.179
134.180
134.183
134.186
134.187
134.189
134.200
134.201
134.204
134.206
134.209
134.210
134.213
134.214
134.215
134.216
134.217
134.224
134.229
134.230
134.238
134.239
134.243
134.244
134.247
134.249
134.25
134.254
134.26
134.27
134.33
134.35
134.37-134.46
134.47
134.5
134.57
134.59
134.6
134.62
134.63
134.64
134.7
134.71
134.77
134.8
134.81
134.85
134.97
136.141
136.143
136.146
136.147
136.157
136.158
136.163
136.164
136.166
136.171
136.173
136.174
136.179
136.180
136.181
136.183
136.184
136.185
136.186
136.198
136.208
136.213
136.220
136.225
136.226
136.228
136.230-136.239
136.245
136.249-136.254
137.105
137.114
137.115
137.116
137.117
137.118
137.119
137.126
137.129
137.130
137.133
137.135
137.15
137.156
137.158
137.16
137.160
137.168
137.169
137.170
137.171
137.172
137.173
137.174
137.176-137.185
137.188
137.19
137.199
137.20
137.201
137.202
137.207
137.217
137.218
137.221
137.227
137.25-137.27
137.31
137.32
137.33
137.34
137.40
137.42
137.47
137.70
137.71
137.72
137.74
137.83
137.91
137.93
137.96
137.97
138.10
138.12
138.14
138.19
138.22
138.30
138.31
138.32
138.33
138.37
138.39
138.46
138.6
138.62
138.63
138.64
138.66
138.69
138.7
138.76
138.8
138.81
138.82
138.83
138.84
138.85
138.86
139.102
139.105-139.120
139.122
139.123
139.125
139.126
139.131
139.134
139.143
139.144
139.145
139.149
139.150
139.164
139.166
139.168
139.68
139.69
139.71
139.72
139.73
139.74
139.76
139.78
139.81
139.85
139.96
139.98
19
190.55
192.12.101
192.12.121
192.12.122
192.12.129
192.12.13
192.12.131
192.12.14
192.12.155-192.12.170
192.12.172
192.12.217
192.12.218
192.12.219
192.12.236
192.12.251
192.12.28
192.12.6
192.12.7
192.12.89
192.12.90
192.12.93
192.12.99
192.16.152
192.16.172
192.16.174
192.16.175
192.16.177
192.16.183
192.16.185-192.16-192.16.190
192.16.192-192.16.200
192.19.0-192.19.255
192.21.0-192.21.255
192.22.0-192.22.255
192.23.0-192.23.255
192.24.0-192.24.255
192.25.0-192.25.255
192.26.0
192.26.149
192.26.150
192.26.151
192.26.20
192.26.25
192.26.50-192.26.82
192.26.90
192.26.91
192.26.96
192.26.97
192.26.98
192.28.0-192.28.99
192.30.0-192.30.255
192.31.1
192.31.105
192.31.108
192.31.110
192.31.113
192.31.114
192.31.115
192.31.148
192.31.149
192.31.150
192.31.166
192.31.167
192.31.168
192.31.169
192.31.17
192.31.170
192.31.171
192.31.174
192.31.209
192.31.211
192.31.22
192.31.229
192.31.233
192.31.238
192.31.24
192.31.240
192.31.245
192.31.247
192.31.248
192.31.25
192.31.27
192.31.29
192.31.37
192.31.38
192.31.44
192.31.77
192.31.78
192.31.79
192.31.83
192.31.84
192.31.91
192.31.95
192.32.0-192.32.255
192.33.128
192.33.14
192.33.187
192.33.19
192.33.190
192.33.2
192.33.240
192.33.37-192.33.86
192.34.0-192.34.255
192.35.102
192.35.108
192.35.109-192.35.126
192.35.141
192.35.60
192.35.62
192.35.83
192.35.87
192.41.148
192.41.172
192.41.198
192.41.199
192.41.210
192.41.212
192.41.224
192.41.239
192.41.240
192.41.241
192.41.242
192.41.243
192.41.246
192.41.250-192.41.255
192.42.1
192.42.101
192.42.102
192.42.133
192.42.134
192.42.135
192.42.136
192.42.138
192.42.139
192.42.148
192.42.149
192.42.150
192.42.153
192.42.154
192.42.158
192.42.202
192.42.203
192.42.204
192.42.205
192.42.206
192.42.238
192.42.240
192.42.243
192.42.252
192.42.253
192.42.4
192.42.52
192.42.53
192.42.54
192.42.65
192.42.90
192.42.94
192.42.99
192.43.1-192.43.150
192.43.161
192.43.200
192.43.213
192.43.218
192.43.219
192.43.220
192.43.221
192.43.222
192.43.224
192.43.237
192.43.248
192.43.253
192.43.254
192.44.252
192.44.91-192.44.215
192.46.0-192.46.255
192.48.101
192.48.104
192.48.109
192.48.110
192.48.123
192.48.124
192.48.125
192.48.127-192.48.129
192.48.130-192.48.132
192.48.133
192.48.137
192.48.141
192.48.142
192.48.143
192.48.145
192.48.211
192.48.221
192.48.225
192.48.235
192.48.239
192.48.240
192.48.241
192.48.242
192.48.243
192.48.244
192.48.245
192.48.247
192.48.248
192.48.251
192.48.252
192.48.253
192.48.254
192.48.31
192.48.32
192.48.35-192.48.36
192.48.37
192.48.38-192.48.77
192.48.92
192.48.94
192.48.97
192.5.103
192.5.106
192.5.142
192.5.147
192.5.149
192.5.150
192.5.164
192.5.209
192.5.213
192.5.218
192.5.223
192.5.242
192.5.243
192.5.244
192.5.245
192.5.246
192.5.247
192.5.248
192.5.249
192.5.250
192.5.251
192.5.252
192.5.253
192.5.3
192.5.4
192.5.41
192.5.5
192.5.6
192.5.63
192.5.7
192.5.8
192.5.83
192.5.94
192.5.95
192.52.108
192.52.113
192.52.116
192.52.151
192.52.152
192.52.153
192.52.154
192.52.170
192.52.177
192.52.181
192.52.184
192.52.196
192.52.197
192.52.229
192.52.230
192.52.231
192.52.238
192.52.239
192.52.240
192.52.244
192.52.246
192.52.250
192.52.253
192.52.254
192.52.51-192.52.60
192.52.67
192.52.68
192.52.74
192.53.0-192.53.255
192.54.110
192.54.121
192.54.122
192.54.124
192.54.129
192.54.132
192.54.133
192.54.134
192.54.138
192.54.225
192.54.228
192.54.238
192.54.245
192.54.246
192.54.82
192.54.83
192.54.84
192.54.85
192.54.86
192.54.87
192.54.88
192.54.89
192.54.90
192.54.91
192.55.1-192.55.21
192.55.101
192.55.102
192.55.110
192.55.111
192.55.115
192.55.121
192.55.131
192.55.134
192.55.136
192.55.137-192.55.186
192.55.189
192.55.193
192.55.195
192.55.196
192.55.197
192.55.198
192.55.199
192.55.201
192.55.202
192.55.203
192.55.206
192.55.209
192.55.216
192.55.218
192.55.22-192.55.31
192.55.220
192.55.224
192.55.225
192.55.227
192.55.229
192.55.236
192.55.243
192.55.244
192.55.245
192.55.246
192.55.249
192.55.83
192.55.88
192.56.0-192.56.255
192.58.1
192.58.102
192.58.105
192.58.106
192.58.121
192.58.122
192.58.123
192.58.149
192.58.151-192.58.154
192.58.155
192.58.156-192.58.179
192.58.181
192.58.183-192.58.192
192.58.19-192.58.27
192.58.193
192.58.195
192.58.197
192.58.199
192.58.2
192.58.200-192.58.203
192.58.211
192.58.215
192.58.216
192.58.217
192.58.230
192.58.232-192.58.241
192.58.244
192.58.245
192.58.246
192.58.249
192.58.250
192.58.251
192.58.253
192.58.254
192.58.28-192.58.35
192.58.3
192.58.37-192.58.40
192.59.0-192.63.255
192.6.0-192.6.148
192.6.150-192.6.200
192.6.202-192.6.255
192.64.0-192.64.255
192.65.1-192.65.49
192.65.132
192.65.135
192.65.136
192.65.148
192.65.149
192.65.150
192.65.151
192.65.152
192.65.154-192.54.170
192.65.173
192.65.174
192.65.178
192.65.179
192.65.180
192.65.204-192.65.210
192.65.211
192.65.212
192.65.213
192.65.214
192.65.215
192.65.217
192.65.245
192.65.246
192.65.249
192.65.250
192.65.251
192.65.252
192.65.253
192.65.254
192.65.50
192.65.72
192.65.75
192.65.76
192.65.79
192.65.98
192.67.1
192.67.10
192.67.107-192.67.126
192.67.127
192.67.130
192.67.134
192.67.135
192.67.136-192.67.155
192.67.15
192.67.156
192.67.157
192.67.158
192.67.16
192.67.166
192.67.168
192.67.17
192.67.174
192.67.175
192.67.176
192.67.177
192.67.178
192.67.179
192.67.18
192.67.180
192.67.181
192.67.182
192.67.183
192.67.19
192.67.2
192.67.209
192.67.210
192.67.211
192.67.212
192.67.213
192.67.214
192.67.215
192.67.216
192.67.219
192.67.22
192.67.220
192.67.221
192.67.224
192.67.228
192.67.23
192.67.24
192.67.248
192.67.253
192.67.254
192.67.3
192.67.4
192.67.44
192.67.46
192.67.51
192.67.52
192.67.55
192.67.56
192.67.57
192.67.60
192.67.73
192.67.80
192.67.84
192.67.85
192.67.86
192.67.87
192.67.90
192.67.91
192.67.93
192.67.94
192.67.95
192.68.109
192.68.112
192.68.113
192.68.114
192.68.115
192.68.116
192.68.118-192.68.125
192.68.134
192.68.135
192.68.136
192.68.137
192.68.138
192.68.139
192.68.140
192.68.141
192.68.146
192.68.147
192.68.148
192.68.154
192.68.155
192.68.157
192.68.161
192.68.175
192.68.177
192.68.180
192.68.182
192.68.183
192.68.184
192.68.187
192.68.20
192.68.21
192.68.22
192.68.23
192.68.75
192.68.76-192.68.107
192.69.0-192.69.255
195.5.68
20
13.130.in-addr.arpa
14.33.192.in-addr.arpa
143.48.192.in-addr.arpa
152.16.192.in-addr.arpa
154.134.in-addr.arpa
158.132.in-addr.arpa
161.68.192.in-addr.arpa
172.128.in-addr.arpa
177.131.in-addr.arpa
181.130.in-addr.arpa
188.130.in-addr.arpa
188.16.192.in-addr.arpa
19.33.192.in-addr.arpa
192.128.in-addr.arpa
195.58.192.in-addr.arpa
201.132.in-addr.arpa
204.130.in-addr.arpa
212.130.in-addr.arpa
214.131.in-addr.arpa
235.129.in-addr.arpa
239.129.in-addr.arpa
24.31.192.in-addr.arpa
246.58.192.in-addr.arpa
27.31.192.in-addr.arpa
5.5.192.in-addr.arpa
50.65.192.in-addr.arpa
6.5.192.in-addr.arpa
64.131.in-addr.arpa
65.131.in-addr.arpa
66.131.in-addr.arpa
67.131.in-addr.arpa
68.131.in-addr.arpa
69.131.in-addr.arpa
7.12.192.in-addr.arpa
7.134.in-addr.arpa
70.131.in-addr.arpa
71.131.in-addr.arpa
72.131.in-addr.arpa
73.131.in-addr.arpa
75.131.in-addr.arpa
76.131.in-addr.arpa
77.131.in-addr.arpa
79.131.in-addr.arpa
8.5.192.in-addr.arpa
80.131.in-addr.arpa
80.67.192.in-addr.arpa
81.131.in-addr.arpa
82.128.in-addr.arpa
82.131.in-addr.arpa
83.131.in-addr.arpa
84.131.in-addr.arpa
85.131.in-addr.arpa
86.131.in-addr.arpa
87.131.in-addr.arpa
88.131.in-addr.arpa
9.128.in-addr.arpa
93.67.192.in-addr.arpa
97.128.in-addr.arpa
105.130.in-addr.arpa
115.134.in-addr.arpa
118.130.in-addr.arpa
121.12.192.in-addr.arpa
122.12.192.in-addr.arpa
125.48.192.in-addr.arpa
ALLIANT.COM
ALLIED.COM
AMOCO.COM
AlphaCDC.COM
BRS.COM
CAS.ORG
CSUHAYWARD.EDU
DSC.COM
GEORGETOWN.EDU
INTERLAN.COM
IPTECH.COM
KESMAI.COM
MALONE.EDU
MENTOR.COM
NM.ORG
NYNEXST.COM
PEREGRINE.COM
POLYGEN.COM
SCO.COM
SERI.GOV
StPaul.GOV
USI.COM
VSE.COM

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 16:02:03 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you get a ENet Addr?
In article <488@eng3.UUCP>, joe@eng3.UUCP (Joe LaRocque) writes:
> I have been given a 'chance to excell' by my boss. Simply put, how do
> we go about getting a base EtherNet Address assigned to us? I seem to
> recall that PARC is still in charge of these numbers. But, I know that
> they have moved to San Diego and I no longer have a name or telephone
> number for an individual that I can talk to about this request.
> 
> Before I forget....I know that we could get a set of proms from a mfg
> who would take care of the problem for us. Our problem is that the new
> system we are building requires as few surface mount structures as 
> possible, so we will be assigning the EtherNet Address via software.
> 
I believe that the IEEE now hand out these numbers, although Xerox still does
the actual work. But I am concerned with the idea that you are planning on
putting out a device which gets it's Ethernet address from software.

I don't have the Ethernet or 802.3 spec handy, but I believe that this is NOT
legal. And, even if it is, it's dangerous. It is critical that all Ethernet
devices have globally unique addresses. The hardware assignment of these
ainsures that there can NEVER be two the same. The portion of the spec allowing
software to reset this address is something I've always objected to, but it is
there.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 16:15:24 GMT
From:      mcsun!inria!cnca!scarpell@uunet.uu.net  (Claude Scarpelli)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NDIS Document
In article <492@eng3.UUCP> joe@eng3.UUCP (Joe LaRocque) writes:
>Could someone Email a copy of the NDIS Document to me?
>Thanks for the assist.
>
>	Joe

[Can't mail to you joe : eng3.UUCP appears to be an unregistered site in 
 the french backbone (inria.fr)]
 
I got this file from anonymous ftp at vax.ftp.com (~/pub/ndis-mac.v201.txt)
If you can't get it, email me and I'll send you my own copy (over 200 Kb)

	claude
-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jul 90 16:36:40 GMT
From:      Mills@udel.edu
To:        groucho!davis@handies.ucar.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Network Temperature Protocol
Glenn,

As you know, the WMO has a bunch of weather forecasting and reporting
formats used in the aviation and marine communities. For some years
venerable Miami short-wave station WBR70 broadcasted continuous
data on various frequencies receivable over significant portions of the
globe. While this station has since shut down, Halifax Radio CHU
presently broadcasts 75-baud radioteletype messages (along with
facsimile maps) on several frequencies. A little known fact is that
for some years anybody could TELNET to a magic port on one of my
machines (dcn6) and watch the weather flow (translated to ASCII, of course).
While I can't guarantee to continue that for my friends, due to shortage
of equipment, it sure would be interesting and maybe even useful if
some site or other could splice the weather wire and in effect resurrect
WBR70.

Dave
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 16:45:56 GMT
From:      brunix!rws@uunet.uu.net  (Central Scrutinizer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol


>Temperature should be in Kelvins.  
>Steve Helpful

Well, then I guess the sign bit would be kind of useless... :-}

rick s. <rws@cs.brown.edu>
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Jul 90 16:49:04 GMT
From:      Mills@udel.edu
To:        brian@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Temperature Quote Protocol
jon Postel,

If you will assign a port number, I will assign a thermocouple.

Dave
-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 18:40:17 GMT
From:      pacbell.com!tandem!moe!kevinr@ucsd.edu  (Kevin J. Rowett)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you get a ENet Addr?

In article <1990Jul25.090203.1@rogue.llnl.gov>, oberman@rogue.llnl.gov writes:
|> In article <488@eng3.UUCP>, joe@eng3.UUCP (Joe LaRocque) writes:
|> 
|> I don't have the Ethernet or 802.3 spec handy, but I believe that
this is NOT
|> legal. And, even if it is, it's dangerous. It is critical that all Ethernet
|> devices have globally unique addresses. The hardware assignment of these
|> ainsures that there can NEVER be two the same. The portion of the
spec allowing
|> software to reset this address is something I've always objected to,
but it is
|> there.

The IEEE spec makes a distintion between globally admin'ed 802.3 addresses
and locally admin'ed address.  It's actually a bit in the address field.
The caveat is that you can have some assurance global admin'ed addresses
won't conflict between vendors, but all bets are off if the address is
locally admin'ed.

In products we build, we give the board a default globally admin'ed 
address.  We still allow the end user to change the current address,
but the software will never let him pick a globally assigned
style address.

Unfortunetly, that aprt of the S/W hasn't been popular with our customers.

kevinr@Tandem.com
-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 18:50:18 GMT
From:      bywater!dagobah!mis@uunet.uu.net  (Mark Seiden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
kmeyer@wrl.dec.com (Kraig Meyer) writes:

>In article <> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
>||As part of a distributed computing experiment, we are considering
>||setting up a Sun workstation, with a bi-metallic strip and small coil
>||tempearture device, and providing a network wide reading, combined
>||with time of day service and cartesian location data.

>The idea of being able to find out about a network node's environment
>has some good network management potential.  Back when I was at Merit
>helping build the original Merit nodes, we started to design a module
>which would sense temperatures in and and nearby the processor cabinet.
>The idea was that an alarm in the NOC would sound when the temperature
>was outside of an appropriate range, and the NOC could call a human to
>either turn up the A/C, plug in a fan, or turn the node off.  

whether you want the temperature of your cpu board or the room temp is
open to debate.  i believe that large disks with motors and big power
supplies are the things which generate the most heat today.  anyway you can
place the sensor within a reasonable distance of the gadget (20 ft) using
an ordinary radio-shack type extension cable...

anyway such a gadget is commercially available...

Subject: /dev/thermometer

want to monitor the temperature in your machine room?

run a shell script if a certain temperature is exceeded, or a
particular rate of temperature increase is exceeded?

there is now such a gadget .. wiztemp-1.
-40 C through 88 C with .5 degree C resolution (that's 8 bits...)

chart recording software (c and postscript) furnished in source.

out of range conditions reported in a user-configurable fashion.
small package, connects to serial port (of sun, mac, pc, many unix
systems) -- velcro it to the side of your machine...

costs $250 including software.  avoiding one meltdown could easily
justify the cost...

2 yr mfrs warranty, 30 day money back guarantee.

available from 
Seiden and Associates, Inc
16 Woods End Rd
Stamford, CT 06905-2727
203 329 2722
mis@seiden.com


-- 
mark seiden, mis@seiden.com, 1-(203) 329 2722 (voice), 1-(203) 322 1566 (fax)
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 19:06:45 GMT
From:      ns-mx!jay.weeg.uiowa.edu!jnford@uunet.uu.net  (Jay Ford)
To:        tcp-ip@nic.ddn.mil
Subject:   multiple subnet masks on same net
We currently have a class-B number (128.255) with 8-bit subnetting (mask
255.255.255.0).  Some folks on our campus net have an interest in subdividing a
subnet into a bunch of 11-bit sub-subnets (mask 255.255.255.224).  The
sub-subnets will each contain a small number of systems (< 32), so full 8-bit
subnets would be sparsely used.

This probably requires a router which has interfaces with different masks, one
with 255.255.255.0 and one with 255.255.255.224.  We'd like to use a BSD system
as a router.  I don't think routed (the BSD RIP implementation) will deal with
the inconsistent masks, and it doesn't seem that gated likes them very well
either.

I'd appreciate some advice from anyone who's done this sort of thing.  It seems
like a fairly reasonable way to better utilize the address space, but the
standard software doesn't appear to support it.

Thanks.


Jay Ford,  Weeg Computing Center,  University of Iowa,  Iowa City,  IA  52242
jnford@jay.weeg.uiowa.edu  or  jnfordpb@uiamvs.bitnet,  319-335-5555
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 19:42:17 GMT
From:      messy!mo@bellcore.com  (Michael O'Dell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA KA9Q
In article <9007251721.AA16622@ucbvax.Berkeley.EDU> SSJACK@ECUVM1.BITNET writes:
>Can someone elaborate on the acronyms (?) NCSA & KA9Q used when
>discussing tn3270?
>
>========================================================================
>Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
>Systems Programmer                                 (919) 757 - 6401
>East Carolina University                          Greenville, NC 27858
>========================================================================

NCSA - No, i Can't Simulate Ascii (referring to the EBCDIC nature
	of the 3270)

KA9Q - Key Another 9 Queries (referring to a benchmark used in
	evaluating remote 3270 performance.

	-Mike
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 20:07:17 GMT
From:      oliveb!tymix!cirrusl!sunstorm!dhesi@apple.com  (Rahul Dhesi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Documentation for the BSD lpd protocol?
There is an amazing book out there that I haven't seen mentioned on
Usenet.  It is, "UNIX NETWORK PROGRAMMING" by W. RICHARD STEVENS.  It
is published by PRENTICE HALL and its ISBN is 0-13-949876-1.  At the
$41 price I paid, this book is a terrific 772-page gold-mine of
information.

This book includes comprehensive descriptions of BSD sockets, Xerox
XNS, and AT&T's System V Transport Layer interface.  There are chapters
TFTP, BSD lpd protocol, BSD rsh/rlogin protocol, BSD rmt (remote tape
drive) protocol, and a few miscellaneous topics such as remote
procedure calls, network performance, Internet/inetd services, and
security (including a pretty clear description of Kerberos).  If you
have any interest at all in networking in a BSD environment, you will
probably want to get a copy of your own right away.

Tons of real source code is included.

This isn't a commercial announcement, since I'm just a happy buyer of
this book.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 20:54:47 GMT
From:      ucrmath!gibson!stebbins@ucsd.edu  (john stebbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Routing problem solved.  Thanks.
Thankyou everyone who responded to my question about the problem I had
reaching ucrmath.  The problem seems to be with the way ucrmath responds
to the connection request.  Since my site doesn't exist on any name servers
anywhere, ucrmath hangs while waiting for a name resolution.  I fixed the 
problem by having the system administrator at ucr put a dummy name into
their hosts file for our site.  I also could have registered our site with
a name server somewhere.  I probably will still do that, as soon as I have
time and I figure out how its done.

John Stebbins
stebbins@ucrmath.ucr.edu or
stebbins@137.67.5.1
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90  00:58:00 EDT
From:      "Roger Fajman" <RAF@CU.NIH.GOV>
To:        FILLMORE%EMRCAN.BITNET@CU.NIH.GOV
Cc:        tcp-ip@SRI-NIC.ARPA.NIC.DDN.MIL
Subject:   Re:  BSMTP description wanted
> Can someone direct me to a document that defines the BSMTP protocol,
> or at least describes the differences between it and SMTP?
> Thanks in advance.

See the file CUVMB BSMTP, available from LISTSERV@BITNIC on BITNET.
It's somewhat out of date, but is pretty close to the truth.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 21:49:31 GMT
From:      glratt@rice.edu  (Glenn Forbes Larrett)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA KA9Q
In article <9007251721.AA16622@ucbvax.Berkeley.EDU> SSJACK@ECUVM1.BITNET writes:
>Can someone elaborate on the acronyms (?) NCSA & KA9Q used when
>discussing tn3270?

NCSA refers to the National Center for Supercomputing Applications at the
University of Illinois at Urbana-Champaign.

KA9Q - no clue



	Glenn Larratt			glratt@uncle-bens.rice.edu
	Computing Resource Center	OCIS, Rice University, Houston, Texas
-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 21:58:55 GMT
From:      silver!hughes@iuvax.cs.indiana.edu  (larry hughes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
In article <9007240048.AA00668@bel.isi.edu> postel@VENERA.ISI.EDU writes:
>
>
>Network Working Group                                          J. Postel
>Request for Comments: XXXX                                           ISI
>                                                               July 1990

I'd like to see the daemon take ntpd's lead, and modify the temperature
when it gets too hot or cold.   ;-)

 //=========================================================================\\
||       Larry J. Hughes, Jr.        ||        hughes@ucs.indiana.edu        ||
||        Indiana University         ||                                      ||
||   University Computing Services   ||   "The person who knows everything   ||
||    750 N. State Road 46 Bypass    ||      has a lot to learn."            ||
||      Bloomington, IN  47405       ||                                      ||
||         (812) 855-9255            ||   Disclaimer: Same as my quote...    ||
 \\==========================================================================//
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 21:59:33 GMT
From:      ncrlnk!ncrstp!npdiss1!montague@uunet.uu.net  (John Montague)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you get a ENet Addr?
In article <488@eng3.UUCP> joe@eng3.UUCPJoe LaRocque writes:
>I have been given a 'chance to excell' by my boss. Simply put, how do
>we go about getting a base EtherNet Address assigned to us? I seem to

By this request I believe you mean "How does one obtain an assignment of a
block of Universal LAN addresses?"  These addresses are assigned by the
IEEE Standards Office, 445 Hoes Lane, Piscataway, NJ  08854-4150; there
is a nominal fee ($1000).


>Before I forget....I know that we could get a set of proms from a mfg
>who would take care of the problem for us. Our problem is that the new
>system we are building requires as few surface mount structures as 
>possible, so we will be assigning the EtherNet Address via software.

Universally administered addresses must be uniquely assigned to a single
LAN node.  This normally accomplished by making a permanent address assignment
to a physical assembly in a non-volitile register (NOT battery backed-up RAM).
If you wish to assign addresses through software you should use "locally
administered addresses" which you may choose to be similar to the address
you have permanaently assigned to the hardware, differing only in the
"Address Administration" bit (the second most significant bit in the 48 bit
address: 0= universally administered, 1= locally administered).

Extreem care must be taken to ensure that duplicate addresses NEVER occur on
the network.

John Montague                          W0RUE
Manager, Standards & Architecture
NCR, Network Products Division, St. Paul, MN
john.montague@stpaul.NCR.COM
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 22:37:53 GMT
From:      usc!snorkelwacker!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: multiple subnet masks on same net
In article <1951@ns-mx.uiowa.edu>, jnford@jay.weeg.uiowa.edu (Jay Ford) writes:
> We currently have a class-B number (128.255) with 8-bit subnetting (mask
> 255.255.255.0).  Some folks on our campus net have an interest in
subdividing a
> subnet into a bunch of 11-bit sub-subnets (mask 255.255.255.224).  The
> sub-subnets will each contain a small number of systems (< 32), so full 8-bit
> subnets would be sparsely used.
> 
> This probably requires a router which has interfaces with different
masks, one
> with 255.255.255.0 and one with 255.255.255.224.  We'd like to use a
BSD system
> as a router.  I don't think routed (the BSD RIP implementation) will
deal with
> the inconsistent masks, and it doesn't seem that gated likes them very well
> either.
> 
> I'd appreciate some advice from anyone who's done this sort of thing. 
It seems
> like a fairly reasonable way to better utilize the address space, but the
> standard software doesn't appear to support it.
> 

	Most routing protocols don't carry the subnet mask along with the
routes in the update messages.  They assume that there is one consistent
subnet mask throughout the entire subnetted net.  RIP is like that.

	OSPF does understand variable length subnet masks and OSPF is in
the process of being implemented in parts of the Internet, so you have
some help and guidance from Milo Medin at NASA Ames and Dave O'Leary of
SURAnet to name two I know.  I've designed a variable length subnet mask
approach for OSPF, but I haven't implemented it.  I think it can be managed
in a relatively straightforward way, if you can explain the proper
configurations
to your user community.  Otherwise, rely on trusty proxy ARP.  :-)

	The gated people are working on OSPF for gated, so if you can
wait a little you can have a protocol that will run on a BSD system.

	If your friends were trying to make bigger, not smaller, subnets
then you could use the trick of layering several 8-bit subnets onto one
interface.  cisco calls their configuration "secondary interface", for example.
It's wise to tell all hosts on layered subnets that their mask is 255.255.0.0
and rely on proxy ARP.  Otherwise, suffer an extra hop thru the local router.
I doubt you would want to change your default subnet mask to 11 bits and do
a lot of layering to get 8 bit subnets.  This sort of trick is nice if you
don't want to go to OSPF or if you are migrating from a bridged to mixed
environment.

	AppleTalk DDP-IP gateways like the FastPath and the GatorBox can
use transparent subnetting, where a group of addresses are assigned to the
gateway for the LocalTalk network.  I don't know a way to exploit that for
you.

	--Kent
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 23:01:06 GMT
From:      bellcore-2!envy!karn@rutgers.edu  (Phil R. Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   RE: Network Temperature Protocol

In article <9007242321.AA21214@rt-jqj.Stanford.EDU>,
jqj@RT-JQJ.STANFORD.EDU (JQ Johnson) writes:
|> I'm afraid we're getting too serious about this "Temperature Quote Protocol"
|> stuff.  If anyone is tempted to get serious about it, they should write
|> an experimental MIB and offer temperature/humidity/... as SNMP variables,
|> not using yet another protocol.

I can't wait to see how you'll implement SNMP's SET operation, especially
for outdoor temperatures. Think of the applications... :-)

Phil
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 90 23:22:02 GMT
From:      bellcore-2!envy!karn@rutgers.edu  (Phil R. Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA KA9Q

In article <25700@bellcore.bellcore.com>, mo@messy.bellcore.com (Michael
O'Dell) writes:

|> KA9Q - Key Another 9 Queries (referring to a benchmark used in
|> 	evaluating remote 3270 performance.

Ah hem....

"KA9Q" is my FCC-assigned Amateur Radio callsign. From those globally-
unique four alphanumerics one can determine by inspection that it
belongs to the amateur radio service, that it was issued by the United
States government, that I initially obtained it while living in either
Illinois, Indiana or Wisconsin (I was in northern Illinois at the
time), and I hold an Extra Class license. And with a copy of the
(public) database it yields my full name, mailing address, station
address, date of birth and date of license expiration. How's that for
a compact personal address assignment scheme? :-)

Of course, Mike knew better since he's N4NLN ("Not Four New Lan Networks!"
- referring to Mike's views on IEEE 802 subgroup proliferation...)

--Phil
-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 11:21:58 -0700
From:      "Philip Almquist" <almquist@jessica.stanford.edu>
To:        uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: FNS routing
Antonio,
> It seems that if FNS is smart enough to know which board to use to ping a 
> particular address it ought to know how to pass packets it receives to the
> right side of the network.  Are we missing something here and doing something
> wrong or is FNS just brain-dead when it comes to routing?

	I have never used the Fusion software, but I did observe that
nothing in the command file you included looked like a command telling
Fusion that it was permitted to act as a router.  To quote from RFC-1122:

      The host software MUST NOT automatically move into gateway
      mode if the host has more than one interface, as the
      operator of the machine may neither want to provide that
      service nor be competent to do so.

						Philip
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 01:16:43 GMT
From:      usc!samsung!umich!pmsmam!wwm@ucsd.edu  (Bill Meahan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA KA9Q
In article <10229@brazos.Rice.edu> glratt@uncle-bens.rice.edu (Glenn Forbes Larrett) writes:
>In article <9007251721.AA16622@ucbvax.Berkeley.EDU> SSJACK@ECUVM1.BITNET writes:
>>Can someone elaborate on the acronyms (?) NCSA & KA9Q used when
>>discussing tn3270?
>
>KA9Q - no clue
>
KA9Q is the amateur radio callsign of Phil Karn (of Bellcore) who has written
a TERRIFIC implementation of the IP protocol suite for the PC (since adapted
by others to UNIX and the Atari ST).  Phil's program (the original version
known as NET or NET.EXE or just KA9Q - and the latest called NOS) was developed
for amateur radio packet radio operations.  Others have found additional uses.
-- 
Bill Meahan  WA8TZG		uunet!mailrus!umich!pmsmam!wwm
I don't speak for Ford - the PR department does that!

Any attempt at wit is liable to offend _somebody_!
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 08:11:37 -0400
From:      craig@NNSC.NSF.NET
To:        mills@udel.edu, tcp-ip@nic.ddn.mil
Subject:   re: Network Temperature Protocol

> A little known fact is that
> for some years anybody could TELNET to a magic port on one of my
> machines (dcn6) and watch the weather flow (translated to ASCII, of course).

Dave:
    
I've had this fantasy for about two years now that I'd someday convince
someone to take this sort of weather info (or perhaps satellite weather data
which some sites make available) and combine it with the MERIT geography
server, and allow me, on my bitmapped workstation, to pull up the current
weather map for some part of the country on my workstation screen.

Thus:
	
	csh% weather Princeton

would cause a weather map for the Princeton NJ area to appear on my screen
(and would have allowed me to diagnose that JvNC was down on Tuesday due
to thunderstorms causing power problems).

I mean, what are all this nifty data and these bitmap displays for except 
drawing useful pictures?

Craig
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 02:54:57 GMT
From:      news-server.csri.toronto.edu!utgpu!molnar@rutgers.edu  (Tom Molnar)
To:        tcp-ip@nic.ddn.mil
Subject:   tcpdump on 4.3 Reno?

I'd like to make use of tcpdump on the CA*net NSSes (IBM RTs running
a modified 4.3BSD similar to NSFnet).

The README of the March '90 release of tcpdump said:

  "Sat Mar  3 04:45:39 PST 1990
   
   This directory file contains yet another beta release of the
   source for tcpdump.  We are still in the middle of replacing the
   Sun NIT interface with an enhanced version of the CMU/Stanford
   packet filter that was distributed with 4.3bsd.  We hope that
   the next version of tcpdump will run an any 4bsd system, not just
   Suns.  Our intent is to include the new version with the 4.4bsd
   distribution. ..."

I don't yet have access to the 4.3 Reno distribution.  Could someone
please tell me if the new tcpdump is available yet?

Thanks in advance,
Tom
-- 
Tom Molnar
Unix Systems Group, University of Toronto Computing Services.
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 09:45:51 -0400
From:      heker@nisc.jvnc.net (Sergio F. Heker)
To:        craig@NNSC.NSF.NET, mills@udel.edu, tcp-ip@nic.ddn.mil
Cc:        heker@nisc.jvnc.net
Subject:   re: Network Temperature Protocol
Craig,

I think that would be a neat idea indeed (of course the archaic way of
calling our NOC would have also worked :-)  ).


						-- Sergio


___________________________________________________________________________

Sergio Heker				Voice:	(609)520-2000 (until 8/15)
Director, JvNCnet			Voice:	(609)258-2400 (after 8/15)
					E-mail:	"heker@nisc.jvnc.net"
__________________________________________________________________________

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 08:24:00 EDT
From:      woody@sparta.com (Robert "Woody" Woodburn)
To:        phone-book@NNSC.NSF.NET
Cc:        tcp-ip@nic.ddn.mil
Subject:   Internet Managers' Phone Book




NAME:  Robert A. Woodburn
ADDRESS: SAIC-CSEIC, 8619 Westwood Center Drive, Vienna, VA  22182
PHONE:  (703) 448-0210
FAX:    (703) 734-3323
E-MAIL: woody@sparta.com

I think I already mentioned this, but I administer

192.48.111 and 192.5.8

Thanks

wood y
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 04:34:08 GMT
From:      pacbell.com!tandem!moe!kevinr@ucsd.edu  (Kevin J. Rowett)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you get a ENet Addr?

In article <146@npdiss1.StPaul.NCR.COM>, montague@npdiss1.StPaul.NCR.COM
(John Montague) writes:
|> 
|> Universally administered addresses must be uniquely assigned to a single

Gosh the "I" in IEEE sure has grown.

I = institue ( as in it ain't a std till I say so)
I = International ( as in globally admin addresses)
I = Interplanetary ( as in universal)

Anyone got the MAC address of the HST?

kevinr@tandem.com
N6RCE
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 10:33 EST
From:      Paul Jones (919) 962-6501                   <ULTIMA%UNC.BITNET@ncsuvm.ncsu.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re:      Re: NCSA KA9Q
NCSA - National Center for Supercomputing Applications
       at University of Ill. Champlain-Urbana
KA9Q - Shortwave radio handle for it's developer. tcp/ip over packet
       radio (and a few other handy things too) from Phil Karns.
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 11:25:38 EDT
From:      Mike Muuss <mike@BRL.MIL>
To:        TCP-IP@nic.ddn.mil
Subject:   Serious Routing Problems
This is one of the most painful trips from Maryland to Boston I have
ever seen!
	-Mike

From:     Phil Dykstra <phil@BRL.MIL>

For ha ha's check this out:

traceroute to expo.lcs.mit.edu (18.30.0.212), 30 hops max, 40 byte packets
 1  ext328 (128.63.4.22)  21 ms  21 ms  26 ms
 2  MOFFETT-FLD-MB.DDN.MIL (26.20.0.16)  586 ms  632 ms  272 ms
 3  Palo_Alto.CA.NSS.NSF.NET (192.52.195.254)  238 ms *  200 ms
 4  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  426 ms  497 ms  261 ms
 5  Ann_Arbor.MI.NSS.NSF.NET (129.140.81.15)  275 ms  263 ms  367 ms
 6  Princeton.NJ.NSS.NSF.NET (129.140.72.17)  303 ms  257 ms  248 ms
 7  zaphod-gateway.jvnc.net (192.12.211.65)  271 ms  294 ms  250 ms
 8  hotblack-gateway.jvnc.net (130.94.0.67)  271 ms  384 ms  287 ms
 9  capital1-gateway.jvnc.net (130.94.1.9)  556 ms  472 ms  300 ms
10  cheesesteak2-gateway.jvnc.net (130.94.33.250)  459 ms  294 ms  666 ms
11  * * cheesesteak1-gateway.jvnc.net (130.94.32.1)  306 ms
12  * beantown2-gateway.jvnc.net (130.94.27.250)  335 ms  311 ms
13  near-gateway.jvnc.net (130.94.27.10)  335 ms  328 ms  385 ms
14  ihtfp.mit.edu (192.54.222.1)  774 ms *  353 ms
15  SEWAGE.MIT.EDU (18.68.0.8)  576 ms *  303 ms
16  * MOSS.LCS.MIT.EDU (18.10.0.11)  344 ms  365 ms

The MILNET throws it as far away as it possibly can, NSFNET spends
four (nice orderly) hops getting it to Princeton, and then JVNC
spends 7(!) hops getting it to Boston.

- Phil
-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 11:51:00 EDT
From:      <FILLMORE%EMRCAN.bitnet@ugw.utcs.utoronto.ca>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: BSMTP information
Thanks very much to everyone who replied with BSMTP information.
The file CUVMB BSMTP at NETSERVE@BITNIC documents the protocol.
I also found a program which implements the protocol:
    bsmtp in mod.sources at sh.cs.net
Thanks again for the help!

________________________
Bob Fillmore, Systems Software & Communications     BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                         BIX:     bfillmore
  Energy, Mines, & Resources Canada                 Voice:   (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4   FAX:     (613) 996-2953
-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 07:58:06 GMT
From:      aruit@idca.tds.PHILIPS.nl (A. de Ruiter)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.pcnet,comp.protocols.misc
Subject:   Remote File Access via NFS or SMB technologie


Hello World,

I am investigating the possibilities to intergrate remote file access in our
software implementation.  Our PC programs are communicating via NetBIOS and
TCP/IP with servers on UNIX systems.  On these UNIX systems we have besides
our own servers also a Name Server (NS), Server Message Block (SMB) and
Network File System (NFS) servers.  Currently the PC software calls the NS
with a logical document name and gets back with the UNIX system name and
the directory path on that UNIX system where that document is located.
After the location of the document is known it will be copied from that
UNIX system to the PC, to do all kind of actions on that document.

In the new implementation of this PC software we do not want to copy this
document, but do all the actions remotely.  To do this we need a PC-NFS or
PC-SMB version which can communicate via NetBIOS and/or TCP/IP with our
UNIX NFS or SMB servers.  Another requirement is that the "mount" and
"umount" of the remote file systems/directories must be possible to do
dynamically out of a C program.  We can do nothing with a PC-NFS or PC-SMB
versions which use "static" configuration files in which the UNIX system
names and directory paths are described.  In our PC applications users are
asking for different documents on different file systems on different
UNIX systems, so at runtime we need to find out where that document is
located and have to "mount" it to a PC drive.

I am searching for a redirector based on NFS or SMB technology to implement
remote file access through an existing private communication.  For example
the Microsoft MS-NET redirector does work correctly.  It is possible to
"mount" via function 5F subfunction 03 and "umount" via 5F subfunction 04.

If anybody know PC-NFS, PC-SMB or other applications which can do this,
or if you have suggestions to implement remote file access in another way,
please inform me.

--------------------------------------------------------------------------------
										|Philips Information Systems            
  _                       __            |Optical Filing Systems, Anton de Ruiter
 /_| __ /_ _  __  __/_   /__)   ./_ _  _|Post Office Box 245, V2-B2          
/  |/ /(_ (_)/ / (_/(-' / \ (_//(_ (-'/ |7300 AE  Apeldoorn, The Netherlands    
      __                 ____  ___      |---------------------------------------
     /__)/_ ./  ._  _     /   /___      |Internet: aruit@idca.tds.philips.nl    
    /   / //(_ //_)/_) __/_   ___/      |UUCP    : ..!mcsun!philapd!aruit       
              /                         |Phone   : +31 55 433514                
                                        |Fax     : +31 55 433488                
--------------------------------------------------------------------------------

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 15:14:21 EDT
From:      oravax!diomedes.UUCP!li@wrath.cs.cornell.edu (Li Gong)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: request to join the Internet mailing list


NIC Operations writes:
> Your address looks like it is aways from us. I'd suggest that you 
> check to see if you have a feed from comp.protocols.tcp-ip. If not
> send another message to tcp-ip-request and we'll add you to our list.
> 
> fmc
> -------

We don't have a local feed (at least not in the near future).  Please
add me to the list:

cornell!oravax!li   or  oravax!li@cu-arpa.cs.cornell.edu

Thanks!

Li
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 12:11:37 GMT
From:      craig@NNSC.NSF.NET
To:        comp.protocols.tcp-ip
Subject:   re: Network Temperature Protocol


> A little known fact is that
> for some years anybody could TELNET to a magic port on one of my
> machines (dcn6) and watch the weather flow (translated to ASCII, of course).

Dave:
    
I've had this fantasy for about two years now that I'd someday convince
someone to take this sort of weather info (or perhaps satellite weather data
which some sites make available) and combine it with the MERIT geography
server, and allow me, on my bitmapped workstation, to pull up the current
weather map for some part of the country on my workstation screen.

Thus:
	
	csh% weather Princeton

would cause a weather map for the Princeton NJ area to appear on my screen
(and would have allowed me to diagnose that JvNC was down on Tuesday due
to thunderstorms causing power problems).

I mean, what are all this nifty data and these bitmap displays for except 
drawing useful pictures?

Craig

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 12:43:06 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Temperature Protocol



 >	csh% weather Princeton
 
 >I mean, what are all this nifty data and these bitmap displays for except 
 >drawing useful pictures?

 Craig,

 joking aside, it would be a very low cost excerise for doing some
seriously accurate stats for global warming detection - this was at
the back of my mind when originally jesting...

 joking not aside, i thought only the English took the weather this
seriously; i mean sea shells and weather; i ask you:-)

 jon

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 14:44:06 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!kline@ucsd.edu  (Charley Kline)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
craig@NNSC.NSF.NET writes:
>I've had this fantasy for about two years now that I'd someday convince
>someone to take this sort of weather info (or perhaps satellite weather data
>which some sites make available) and combine it with the MERIT geography
>server, and allow me, on my bitmapped workstation, to pull up the current
>weather map for some part of the country on my workstation screen.


Here at the U of I I can run "wxmap" and then tell it I want a map centered
on Champaign and a current conditions map will appear on my X display,
complete with weather watch boxes and severe weather risk areas. Radar data
is coming soon.

The code was homegrown here in the cornfields. The weather data comes
from Alden Electronics, a reseller of government weather data. It all
comes out in the WMO format, with which I struggle every day.

Is this what you mean?

_____________________________________________________________________________
Charley Kline, KB9FFK/KT, PP-ASEL                            c-kline@uiuc.edu
University of Illinois Computing Services                      (217) 333-3339
-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 14:55:23 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   was: the BSD lpd protocol? Stevens' Book


 >There is an amazing book out there that I haven't seen mentioned on
 >Usenet.  It is, "UNIX NETWORK PROGRAMMING" by W. RICHARD STEVENS.  It
 >is published by PRENTICE HALL and its ISBN is 0-13-949876-1.  At the
 >$41 price I paid, this book is a terrific 772-page gold-mine of
 >information.

i second this - it is extremely complete, so far as a 1 hour scan could
tell, v. well written and excellent value - i wish there could be an
equivalent text for kernel hackery for bsd, svid and, say, mach. then
lots of people could stop paying out megabucks to go on commercial
courses...

the structure is very similar to a course i teach on comms. software,
and i think i'm gonna recommend it as a base text....

 jon

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 15:22:09 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uwm.edu!bbn.com!craig@ucsd.edu  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
In article <1990Jul26.144406.19495@ux1.cso.uiuc.edu> kline@ux1.cso.uiuc.edu (Charley Kline) writes:
>Here at the U of I I can run "wxmap" and then tell it I want a map centered
>on Champaign and a current conditions map will appear on my X display,
>complete with weather watch boxes and severe weather risk areas. Radar data
>is coming soon.

Charley:

    This is precisely the sort of thing I think would be a fun (and useful)
application to have generally available on the Internet.

Craig
-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 13:43:06 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        craig@nnsc.nsf.net
Cc:        mills@louie.udel.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol


 >	csh% weather Princeton

 >I mean, what are all this nifty data and these bitmap displays for except 
 >drawing useful pictures?

 Craig,

 joking aside, it would be a very low cost excerise for doing some
seriously accurate stats for global warming detection - this was at
the back of my mind when originally jesting...

 joking not aside, i thought only the English took the weather this
seriously; i mean sea shells and weather; i ask you:-)

 jon

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 15:33:00 GMT
From:      ULTIMA@UNC.BITNET (Paul Jones  962-6501, 919)
To:        comp.protocols.tcp-ip
Subject:   Re:      Re: NCSA KA9Q

NCSA - National Center for Supercomputing Applications
       at University of Ill. Champlain-Urbana
KA9Q - Shortwave radio handle for it's developer. tcp/ip over packet
       radio (and a few other handy things too) from Phil Karns.

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 16:46:10 GMT
From:      Mills@udel.edu
To:        bellcore-2!envy!karn@rutgers.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  NCSA KA9Q
Phil,

Not quite your perfect personal identifier, your callsign, since historically
the mapping has changed. I hold W3HCF, which does not divulge my Extra Class,
formerly held K2GUP, W8EJQ, GM5AWF and F0BCX in various countries and states.
In addition, lots of countries have gone out of business and new ones have
taken their places and callsigns. You can, however, assume the callsign
assignment is globally unique as long as you keep your history books up to
date.

Dave
-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 17:02:09 GMT
From:      Mills@udel.edu
To:        craig@nnsc.nsf.net
Cc:        mills@udel.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Network Temperature Protocol
Craig,

I've had this fantasy, too. Problem is our government wants to get out of the
distribution business leaving the commercial sector to make a buck. There are,
of course, various weather feeds, but it seems they are really intended for
for-profit distribution and then not in raw form, but various "value added"
forms. I pine for the old raw, ubiquitous broadcasts. At least CHU continues
to broadcast, even if it is specialized to the North Atlantic and Ice Patrol.

Dave
-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 17:03:51 GMT
From:      excelan!bbaker@ames.arc.nasa.gov  (Brad Baker)
To:        tcp-ip@nic.ddn.mil
Subject:   REPOST: NBA Netbios Broadcast Agent (1of2)
REPOST: In straight ascii file 1of2 (make+headers)


Sources for NBA  (OS2 and Unix)

Netbios Broadcast Agent
Effectively internets the Netbios Name service.

This program is useful for effectively combining netbios
networks that are separated on the internet.  
It could also be used to connect to a remote Unix SMB server
allowing for file and print services across the internet.
Written to the BSD 4.3 sockets interface.  It has been compiled
and run on 68XXX and SPARC Unix machines, as well as OS/2, with
no code changes. 

Necessary files are:

makefile 	(os2)
name.h		(os2,unix)
nba.h		(os2,unix)
nba.c		(os2,unix)

See the documentation header in nba.c for more extensive info.


#
#       makefile for OS/2 NBA
#
#-----------------------------------------------
#       Definitions for MSC 5.1 Compiler
#       /c              -- compile only (suppress linking)
#       /A$(model)      -- Specifies memory model
#       /Gs2            -- Disable stack probes, use 286 instructions
#       /Zl             -- Remove default library info
#       /DOS2           -- OS/2 environment
#       /DDDL           -- use of DDL
#       /W3             -- Maximum warning level
#-----------------------------------------------
#
# model can be = lfu - large code, far  data, SS != DS
#                lnu - large code, near data, SS != DS
#                sfu - small code, far  data, SS != DS
#                snu - small code, near data, SS != DS
#
# See MTDYNA.DOC for more details on this subject
#
model=lfu
#
# include paths - use multi-thread include files
#
XLNPATH=\xln\toolkit
TK_INCL=$(XLNPATH)\include
INCLUDE=-I. -I$(TK_INCL) -I\msc51\include\mt
#
# libpaths should be set in the LIB environment string
#
XLNLIBS=bsd43.lib crtlib.lib
MSLIBS=doscalls.lib
ALL_LIBS=$(XLNLIBS) $(MSLIBS)
#
# compile flags
#
CFLAGS=  /c /A$(model) /Ox /Zli /Gs2 /DDLL /DDEBUG /DOS2 /W3 $(INCLUDE)
#
# link flags
#
LFLAGS= /CO /NOD /MAP /NOI
LINKCMD=$(LFLAGS) $** + \xln\toolkit\os2lib\crtexe.obj,$@,$*.map,$(ALL_LIBS)


.c.obj:
        cl $(CFLAGS) $*.c > $*.err

nba.obj:	nba.c	nba.h 	name.h

##### Link commands ######

nba: 	nba.obj
	link $(LINKCMD);
	markexe WINDOWCOMPAT nba.exe



/*
----------------------------------------------------------------------------

        Copyright (C) 1990 Novell, Inc.
	
        This software may be freely copied and distributed, provided the 
        above copyright notice is included. It may not be sold, in whole
        or in part, without the prior written consent of Novell, Inc.

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

		NAME.H  header file for nba.c
*/

#define	IP_DGRAM_SZ	576
#define	IP_HDR_SZ	20
#define	UDP_HDR_SZ	8
#define SZ_BUFFER	(IP_DGRAM_SZ - IP_HDR_SZ - UDP_HDR_SZ)
#define	SZ_MAXPKTDATA	576	/* maximum data in a packet */

/****************************************************************************
 * Domain Name Packet Definitions
 ***************************************************************************/


#define	NM_REG_REQ	0x2910
#define	NM_RES		0xad80
#define	NM_QRY		0x0110
#define	NM_QRY_RES	0x8500
#define NM_QRY_RES1	0x8580
#define	NODE_STATUS_REQ	0x0010
#define	NODE_STATUS_RES 0x8400
#define	NM_OVR_REQ	0x2810
#define	NM_RLS_REQ	0x3010
#define PKT_MSK		0xfdf0	/* Mask of bits used for packet type. */
#define RCODE_MSK	0x000f	/* Mask of bits used for rcode */

/*
 * Mask values for NM_FLAGS. These values treat the fields,
 * OPCODE, NM_FLAGS, and RCODE as one word (16 bits).
 */

#define	NS_BROADCAST	0x0001
#define	NS_RESRVD1	0x0002
#define	NS_RESRVD2	0x0004
#define	NS_RA		0x0008
#define	NS_RD		0x1000
#define	NS_TC		0x2000	/* truncation bit */
#define	NS_AA		0x4000

/* error codes for RCODE field in packet header */

#define	FMT_ERR	0x1	/* Invalidly Formatted Request */
#define	SRV_ERR	0x2	/* Server Failure */
#define	IMP_ERR	0x4	/* Unsupported Request */
#define	RFS_ERR	0x5	/* Registration Refusal */
#define	ACT_ERR	0x6	/* Active erroe, name is owned by another node. */
#define	CFT_ERR	0x7	/* Name is in conflict */

/* type values */

#define	NS_A		0x0100	/* IP address RR */
#define	NS_NS		0x0002	/* Name Server RR */
#define	NS_NB		0x0020	/* General Name Service RR */
#define	NS_NBSTAT	0x0021	/* Node Status RR */
#define	NS_NULL		0x000a	/* NULL RR - see WACK definition */
#define NS_IN		0x0001  /* Internet class */

/* values for NB_FLAG field in RR data */

#define NS_GROUP	0x8000	/* Group Bit, 1 == Group Netbios Name */
#define NS_MNODE	0x4000
#define NS_PNODE	0x2000
#define NS_DRG		0x1000
#define NS_BNODE	0x0000
#define NS_CNF		0x0800
#define NS_ACT		0x0400
#define NS_PRM		0x0200

/* masks for NB_FLAG field in name data entry */

#define NS_GROUPMSK	~0x8000	/* Group Name Flag */
#define NS_ONTMSK	~0x6000	/* Owner Node Type */
#define NS_STATEMSK	~0x1d00	/* Name State Bits */


/****************************************************************************
 * Question Section trailer: preceded by a compressed Netbios name
 ***************************************************************************/

struct quest_trailer {
    unsigned short type;
    unsigned short class;
}; /* 4 bytes long */

/****************************************************************************
 * Resource Record trailer: preceded by a compressed Netbios name, followed
 * by a variable data section
 ***************************************************************************/

struct rr_trailer {
    unsigned short  type;
    unsigned short  class;
    unsigned long ttl;
    unsigned short  length;
}; /* 10 bytes long */

struct rr_info {
    struct rr_trailer	trailer;
    unsigned short       flags;
    long 		 nbaddr;
}; /* 16 bytes long */

struct nmpkt_hdr {
    unsigned short nm_tid;	/* transaction id */
    unsigned short status;	/* opcode, flags, return code */
    unsigned short qdcount;	/* number of question entries */
    unsigned short ancount;	/* number of answer records */
    unsigned short nscount;	/* number of authority records */
    unsigned short arcount;	/* number of additional records */
}; /* 12 bytes long */

struct namepkt {
    struct nmpkt_hdr header;	
    unsigned char records[SZ_BUFFER - sizeof(struct nmpkt_hdr)];
};

#define	NAME_SERVICE_UDP_PORT	137
/*
----------------------------------------------------------------------------

        Copyright (C) 1990 Novell, Inc.
	
        This software may be freely copied and distributed, provided the 
        above copyright notice is included. It may not be sold, in whole
        or in part, without the prior written consent of Novell, Inc.

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

	 NBA.H   header file for nba.c

*/

/******* "ignore" this stuff ******/
#ifndef FD_SET
#define	NBBY	8		/* number of bits in a byte */
/*
 * Select uses bit masks of file descriptors in longs.
 * These macros manipulate such bit fields (the filesystem macros use chars).
 * FD_SETSIZE may be defined by the user, but the default here
 * should be >= NOFILE (param.h).
 */
#ifndef	FD_SETSIZE
#define	FD_SETSIZE	32
#endif

typedef long	fd_mask;
#define NFDBITS	(sizeof(fd_mask) * NBBY)	/* bits per mask */
#ifndef howmany
#define	howmany(x, y)	(((x)+((y)-1))/(y))
#endif

#define	FD_SET(n, p)	((p)->fds_bits[(n)/NFDBITS] |= (1 << ((n) % NFDBITS)))
#define	FD_CLR(n, p)	((p)->fds_bits[(n)/NFDBITS] &= ~(1 << ((n) % NFDBITS)))
#define	FD_ISSET(n, p)	((p)->fds_bits[(n)/NFDBITS] & (1 << ((n) % NFDBITS)))
#define FD_ZERO(p)	bzero((char *)(p), sizeof(*(p)))
#endif
/**************** real stuff below here *****************/



typedef  	unsigned short 		USHORT;
typedef  	unsigned long  		ULONG;
typedef  	unsigned 				BOOL;

#define		TRUE						1
#define		FALSE 					0

#define 		NBA_WK_PORT  			3000   		/* an unassigned port */
#define 		BAQSIZE					100 
#define 		BAPKTLIFE    			5           /* packet life */
#define		SZ_NCBNAME				16
#define 		SOCKADDRSIZE  			sizeof(struct sockaddr_in)
#define 		AGENT_NAME_LEN 		11 
#define 		FILE_NAME_LEN  		80 


/* BA status codes */
#define 		BA_SEND					0
#define 		BA_REPLY 				1
#define 		BA_ERROR					-1

#define 		NS_RES_MASK				0x8000	/* mask for the NS response bit */

/* conversion macros */
	/* convert network order long to network order short */
#define 		NLtoNS(x)				htons((USHORT)ntohl(x)) 
	/* convert network order short to network order long */
#define 		NStoNL(x)				htonl((ULONG)ntohs(x))

struct ba_header {
	ULONG   	status;				/* command codes for BA agents */
	ULONG	  	time;					/* time stamp for packet expiration */
	ULONG 	ns_tid;				/* name service transaction id */
	ULONG 	ba_tid;				/* BA agent transaction id */
	ULONG  	host_addr;			/* BA agent address */
	ULONG 	client_addr;		/* NS client address   */
	ULONG 	client_port;		/* NS client port */
#define 		BAHEADERSIZE			sizeof(struct ba_header)
};

struct ba_pkt {
	struct 	ba_header baheader;
	struct 	namepkt   namepkt;
#define 		BAPKTSIZE				sizeof(struct ba_header) + SZ_BUFFER
};
-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 17:08:48 GMT
From:      excelan!bbaker@ames.arc.nasa.gov  (Brad Baker)
To:        tcp-ip@nic.ddn.mil
Subject:   REPOST: NBA Netbios Broadcast Agent (2of2)
REPOST: In straight ascii file 2of2 (source)


Sources for NBA  (OS2 and Unix)

Netbios Broadcast Agent
Effectively internets the Netbios Name service.

This program is useful for effectively combining netbios
networks that are separated on the internet.  
It could also be used to connect to a remote Unix SMB server
allowing for file and print services across the internet.
Written to the BSD 4.3 sockets interface.  It has been compiled
and run on 68XXX and SPARC Unix machines, as well as OS/2, with
no code changes. 

The necessary files are:

makefile 	(os2)
name.h		(os2,unix)
nba.h		(os2,unix)
nba.c		(os2,unix)

See the documentation header in nba.c for more extensive info.

/*
----------------------------------------------------------------------------

        Copyright (C) 1990 Novell, Inc.
	
        This software may be freely copied and distributed, provided the 
        above copyright notice is included. It may not be sold, in whole
        or in part, without the prior written consent of Novell, Inc.

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

        NBA.C  Netbios Broadcast Agent    by  Brad Baker

	This is SAMPLE source code, NOT a Novell product, 
        and will not be supported by the technical staff of Novell.

	DESCRIPTION:

	This program provides an example of how to forward name service
  	broadcasts to remote netbios networks connected via gateways or
	routers which do not usually forward such packets.  It is designed
	to be run in either Server mode or Agent mode.
		Server mode requires that this program (NBA) be run on the local
	network. It receives netbios name query broadcasts (status=0x110) and
	replies with a query response (status=0x8500), if the query name and
	internet address entry is found in the HOSTS file.  No reply packet
	is sent if the name is not found in the HOSTS file.
		Agent mode involves running one NBA on the local net, and one on
	the remote network.  The local NBA receives broadcasts on the local
	network, saves pertinent packet information such as client address,
	port, transaction ID, etc., in a control block (header).  The
	packet is then prepended with the NBA header, and then forwarded to
	the remote NBA.  When it is received, the remote NBA strips off
	the header, saves (enqueues) the header, and then the original
	(de-encapsulated) netbios packet is broadcast on the remote network.
	When the remote NBA receive a reply, if at all, to the broadcast,
	the header information is dequeued based on the the transaction id of
	the reply packet.  The destination address, port, and tid of the
 	reply packet is then set to the (client) values stored in the
	dequeued NBA header and the resulting packet is sent (directed) back
	to the the client node which made the original broadcast.
		This forwarding of the broadcast and reply packets, in effect,
	internets the name service.

	FEATURES/LIMITATIONS:

	*	NBA is written to be very portable.  It will run on 680xx
	        and Sparc Unix machines as well as 80286/386 OS2 machines and
		should be easily ported to DOS.

	*	This program makes extensive use of the HOSTS file.
		Entries must exist for BROADCAST, LOCALHOST, as well
		as any names requiring a response when running NBA in
		server mode.  If subnetting is in use on the network
		the BROADCAST address of the form WW.YY.0xff.0xff may
		not work on some BSD implementations.  In this case an
		appropriate subnet broadcast address should be used.
		A subnet broadcast address has the form:

         WW.XX.YY.ZZ   where

         WW.XX = the network portion address
            ZZ = the host portion address (all set)
            YY = for a node with a subnet mask of 0xfc, this
                 defines the upper 6 bits of the byte as the subnet
                 portion (set to the subnet value) and the lower
                 2 bits (both set) as part of the host portion.

         example:      subnet mask = 0xfc
                       network     = 0x82.0x39
                       broadcast on subnet 1 = 0x82.0x39.0x07.0xff

	*	In order to run NBA (port 137) on Unix requires	super-user privilige 
		The port value should only be changed during testing, and
		should always be 137 as this is the UDP name service port.

	*       When running NBA in server mode, entries in the HOSTS file
	        should be in upper case.

	*	Although an agent may receive NBA packets from any number
		of remote NBA agents, it will only forward broadcasts to one remote
		NBA agent.  In other words, an NBA will not simultaneously forward
		a packet to multiple remote NBA's.  This can be accomplished by
		running multiple NBA's on the local net (on different machines)
		each of which will receive broadcasts, but forward the packets to
		different remote agents/networks.

	ENHANCEMENTS:

		* Change the queuing mechanism to a more dynamic one. At 
                  present the queue is a static array.
		* Make this program run as a detached process, TSR, or
  		  PM application with an improved user interface.
		* Provide for the support of multiple remote agents as described in
		  the LIMITATIONS section above.

	BUILD TOOLS:

		OS2

		This program was built using Novell's Lan Workplace for OS/2 (BSD 4.3
		sockets), MSC 5.10, MS link 5.01.21, POLYTRON Polymake V3.1.

		UNIX

		C compiler

	BUILD INSTRUCTIONS:

		required files are:  nba.c, nba.h, name.h, makefile(os2)

		unix> cc nba.c
		os2> make nba

	USAGE:

		nba [[-d] [[-a]{ipaddr}] [[-p]{port}] [[-w]{wport}]]
	  	where 	ipaddr = the Internet Address of the remote NBA Agent.
		         port   = the port used for name service transactions.
		                  Default is 137 (UDP Name Service Port)
		         wkport = the "well known port" used for NBA
		                  transactions. Default is 3000
		         -d     = Debug flag.  Debug mode prints messages to
					         STDERR.

		examples:

		>nba
		runs in silent server mode, port 137

		>nba -d
		runs in debug server mode, port 137

		>nba -d -a130.50.5.115 -p2000 -w5000
		runs in agent mode (for testing), port 2000, NBA port 5000,
		forwarding broadcasts to the remote agent at address 130.50.5.115.


*/

#include <stdio.h>
#include <time.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <errno.h>
#include <signal.h>
#include "name.h"
#include "nba.h"
#ifdef OS2
#include <bsd43.h>
#endif

struct sockaddr_in sock = {AF_INET};
struct sockaddr_in bcast = {AF_INET};
struct sockaddr_in from = {AF_INET};
struct namepkt  nspkt;
struct ba_pkt   bapkt;
struct ba_header baheader;
struct ba_header baq[BAQSIZE];
struct hostent *host;
struct in_addr  inetaddr;
struct in_addr  inet_makeaddr();
ULONG           host_addr = 0L;
ULONG           bcast_addr = 0L;
ULONG           agent_addr = 0L;
ULONG           ipaddr;
ULONG           ipnet;
USHORT          baqindex = 0;
int             nspkt_size, bapkt_size;
USHORT          port = NAME_SERVICE_UDP_PORT;	/* the ns listen port */
USHORT          wkport = NBA_WK_PORT;	/* the ba listen port */
ULONG           batidx = 0;
int             len = sizeof(from);
int             debug = 0;
int             sig();
int             fd, fda;
char            myname[16];
char            othername[16];
BOOL            use_host_file = FALSE;
fd_set          sockset;

main(argc, argv)
	int             argc;
	char          **argv;
{
	char           *s;
	int             nfound;
	int             setres, optval;

	signal(SIGINT /* SIGHUP */ , sig);
	setbuf(stdout, 0);
	setbuf(stderr, 0);
	while (--argc > 0 && (*++argv)[0] == '-') {
		s = argv[0] + 1;
		switch (*s) {
		case 'd':
			debug = 1;
			fprintf(stderr, "debug enabled\n");
			break;
		case 'p':
			port = atoi(++s);
			break;
		case 'w':
			wkport = atoi(++s);
			break;
		case 'a':
#ifdef	OS2
			ipnet = inet_addr(++s);
			ipaddr = inet_network(s);
			ipaddr = htons((short) ipaddr);
			agent_addr = (ipaddr << 16) | ipnet;
			/* inetaddr = inet_makeaddr(ipnet,ipaddr);  */
			/* agent_addr = inetaddr.S_un.S_addr;		  */
#else
			agent_addr = inet_addr(++s);
#endif
			break;
		default:
			fprintf(stderr, "usage: %s nba [[-d] [[-a]{ipaddr}] [[-p]{port}] [[-w]{wport}]]\n", argv[0]);
			exit(1);
		}
	}

	if (!agent_addr)
		use_host_file = TRUE;

	/* get local network information */
	if (gethostname(myname, sizeof(myname) - 1)) {
		perror("nba: gethostname()");
		exit(1);
	}
	if (debug)
		fprintf(stderr, "nba: myname = %s\n", myname);
	if (strlen(myname) > 15) {
		fprintf(stderr, "nba: - name too long\n");
		exit(1);
	}
	host = gethostbyname(myname);
	if (host) {
		bcopy(host->h_addr, (char *) &host_addr, host->h_length);
	} else {
		perror("nba: gethostbyname() \n");
		exit(1);
	}

	if (debug)
		fprintf(stderr, "host_addr  :0x%lx\n", ntohl(host_addr));
	if (debug && (agent_addr))
		fprintf(stderr, "agent_addr :0x%lx\n", ntohl(agent_addr));

	/* get broadcast IP Address */
	host = gethostbyname("broadcast");
	if (host) {
		bcopy(host->h_addr, (char *) &bcast_addr, host->h_length);
	} else {
		perror("nba: gethostbyname() \n");
		exit(1);
	}

	cvt(myname);		/* convert to upper case */

	/* get and bind a socket for netbios name service */
	if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
		perror("nba: socket()");
		exit(1);
	}
	sock.sin_port = htons(port);
	sock.sin_addr.S_un.S_addr = 0l;
	if (bind(fd, &sock, sizeof(sock)) < 0) {
		perror("nba: bind()");
		exit(1);
	}
	/* get and bind a socket for agent receive */
	if ((fda = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
		perror("nba: socket()");
		exit(1);
	}
	sock.sin_port = htons(wkport);
	sock.sin_addr.S_un.S_addr = host_addr;
	if (bind(fda, &sock, sizeof(sock)) < 0) {
		perror("nba: bind()");
		exit(1);
	}
	/* process all Broadcast Repeater (BA) and Name Service (NS) packets */
	while (1) {
		FD_ZERO(&sockset);
		FD_SET(fd, &sockset);
		FD_SET(fda, &sockset);
		/* wait for a pkt on one of the two sockets */
		if ((nfound = select(32, &sockset, NULL, NULL, NULL)) < 0) {
			perror("nba: select()");
			exit(1);
		}
		/* test for NS socket has data */
		if (FD_ISSET(fd, &sockset)) {
			process_ns();	/* process NS packets */
		}
		/* test for BA socket has data */
		if (FD_ISSET(fda, &sockset)) {
			process_ba();	/* process BA packets */
		}
	}
}				/* ba */


/*
 * process_ba() - process incoming BA agent packets
 */

process_ba()
{
	int             i, chsent;


	/* read the socket */
	if ((bapkt_size = recvfrom(fda, &bapkt,
			      sizeof(struct ba_pkt), 0, &from, &len)) < 0) {
		perror("nba: recvfrom()");
		exit(1);
	}
	if (debug) {
		fprintf(stderr, "|-- NBA PKT -------------------------------\n");
		fprintf(stderr, "| size   = 0x%x\n", bapkt_size);
		fprintf(stderr, "| port   = 0x%x\n", ntohs(from.sin_port));
		fprintf(stderr, "| addr   = 0x%lx\n", ntohl(from.sin_addr.S_un.S_addr));
		fprintf(stderr, "|----------------------------------------\n");
	}
	/* set up the agent tid and change the pkt tid */
	bapkt.baheader.ba_tid = htonl(++batidx);
	bapkt.namepkt.header.nm_tid = NLtoNS(bapkt.baheader.ba_tid);

	/* enqueue the header */
	while (baenq(&bapkt)) {
	};			/* keep trying until success (a header
				 * expires) */

	/* forward (broadcast) the packet to local net */
	sock.sin_port = htons(port);
	sock.sin_addr.S_un.S_addr = bcast_addr;

	if ((chsent = sendto(fd, &bapkt.namepkt, (int) (bapkt_size - BAHEADERSIZE), 0,
			     &sock, SOCKADDRSIZE)) < 0) {
		perror("nba: sendto()");
		exit(1);
	}
	if (debug)
		fprintf(stderr, ">>> Broadcast 0x%x bytes to	Port:0x%x  Addr:0x%lx\n",
			chsent, ntohs(sock.sin_port), ntohl(sock.sin_addr.S_un.S_addr));


}				/* process_ba */


/*
 * process_ns() - process incoming name service packets
 */

process_ns()
{
	int             i, chsent;
	struct ba_header *phdr;


	/* read the socket */
	if ((nspkt_size = recvfrom(fd, &bapkt.namepkt,
			     sizeof(struct namepkt), 0, &from, &len)) < 0) {
		perror("nba: recvfrom()");
		exit(1);
	}
	/* if broadcast encapsulate the NS packet and send to BA agent */
	if (!(ntohs(bapkt.namepkt.header.status) & NS_RES_MASK)) {
		/* skip the broadcast if it came from this node */
		if (from.sin_addr.S_un.S_addr != host_addr) {

			if (debug) {
				fprintf(stderr, "|-- NETBIOS PKT --------------------------\n");
				fprintf(stderr, "| size = 0x%x\n", nspkt_size);
				fprintf(stderr, "| port = 0x%x\n", ntohs(from.sin_port));
				fprintf(stderr, "| addr = 0x%lx\n", ntohl(from.sin_addr.S_un.S_addr));
				fprintf(stderr, "| tid  = 0x%x\n", ntohs(bapkt.namepkt.header.nm_tid));
				fprintf(stderr, "| type = 0x%x\n", ntohs(bapkt.namepkt.header.status));
				fprintf(stderr, "|--------------------------------------\n");
			}
			/*
			 * if we are running in server mode process the pkt
			 * locally
			 */
			if (use_host_file) {
				respond_local(&bapkt.namepkt);
				return;
			}
			/* set up the baheader */
			baheader.client_addr = from.sin_addr.S_un.S_addr;
			baheader.client_port = NStoNL(from.sin_port);
			baheader.host_addr = host_addr;
			baheader.ns_tid = NStoNL(bapkt.namepkt.header.nm_tid);

			/*
			 * prepend the packet (in bapkt.namepkt) with the
			 * baheader
			 */
			bcopy((char *) &baheader, (char *) &bapkt, BAHEADERSIZE);

			/* send the packet to the other agent */
			sock.sin_port = htons(wkport);	/* BA "well known" port */
			sock.sin_addr.S_un.S_addr = agent_addr;	/* BA agent address     */


			if ((chsent = sendto(fd, &bapkt, (int) (nspkt_size + BAHEADERSIZE), 0,
					     &sock, SOCKADDRSIZE)) < 0) {
				perror("nba: sendto()");
				exit(1);
			}
			if (debug)
				fprintf(stderr, ">>> Sent 0x%x bytes to	Port:0x%x  Addr:0x%lx\n",
					chsent, ntohs(sock.sin_port), ntohl(sock.sin_addr.S_un.S_addr));
		}
	}
	/* not a broadcast. Lookup in the queue, set up reply pkt if found */
	else {
		if (debug) {
			fprintf(stderr, "|-- NETBIOS PKT --------------------------\n");
			fprintf(stderr, "| size = 0x%x\n", nspkt_size);
			fprintf(stderr, "| port = 0x%x\n", ntohs(from.sin_port));
			fprintf(stderr, "| addr = 0x%lx\n", ntohl(from.sin_addr.S_un.S_addr));
			fprintf(stderr, "| tid  = 0x%x\n", ntohs(bapkt.namepkt.header.nm_tid));
			fprintf(stderr, "| type = 0x%x\n", ntohs(bapkt.namepkt.header.status));
			fprintf(stderr, "|--------------------------------------\n");
		}
		/* dequeue based on the nm_tid */
		if (!(badeq(NStoNL(bapkt.namepkt.header.nm_tid), &bapkt))) {

			/* restore the pkt tid */
			bapkt.namepkt.header.nm_tid = NLtoNS(bapkt.baheader.ns_tid);

			/* send the packet to the remote client */
			sock.sin_port = NLtoNS(bapkt.baheader.client_port);
			sock.sin_addr.S_un.S_addr = bapkt.baheader.client_addr;

			if ((chsent = sendto(fd, &bapkt.namepkt, nspkt_size, 0,
					     &sock, SOCKADDRSIZE)) < 0) {
				perror("nba: sendto()");
				exit(1);
			}
			if (debug)
				fprintf(stderr, ">>> Sent 0x%x bytes to	Port:0x%x  Addr:0x%lx\n",
					chsent, ntohs(sock.sin_port), ntohl(sock.sin_addr.S_un.S_addr));
		}
	}
}				/* process_ns */


/*
 * baenq - enqueue a BA header. returns: 0 if success At present the queue is
 * just an array of headers.
 */
int 
baenq(header)
	struct ba_header *header;
{
	int             i;
	ULONG           t;

	/* place the header at an empty (expired) location */
	for (i = 0; i < BAQSIZE; i++) {
		time(&t);
		if ((t - baq[i].time) > BAPKTLIFE) {
			bcopy((char *) header, (char *) &baq[i], BAHEADERSIZE);
			baq[i].time = t;	/* time stamp the header */
			return (0);
		}
	}

	if (debug)
		fprintf(stderr, "XXX Queue full.\n");

	return (1);
}

/*
 * badeq - dequeue a baheader based on a BATID returns: 0 if success At
 * present the queue is just an array of headers.
 */
int 
badeq(tid, header)
	ULONG           tid;
	struct ba_header *header;
{
	int             i;
	ULONG           t;

	/* search for header ba_tid matching the tid */
	for (i = 0; i < BAQSIZE; i++) {
		time(&t);
		/* skip the dead ones */
		if ((t - baq[i].time) < BAPKTLIFE) {
			if (baq[i].ba_tid == tid) {
				bcopy((char *) header, (char *) &baq[i], BAHEADERSIZE);
				return (0);
			}
		}
	}

	if (debug)
		fprintf(stderr, "XXX Header not found.\n");

	return (1);
}


/*
 * cvt - convert MYNAME to upper case
 */

cvt(src)
	char           *src;
{
	int             i;

	for (i = 0; i < strlen(src); i++) {
		if (isalpha(src[i]))
			src[i] = toupper(src[i]);
	}

	/* fill with blanks */

	for (; i <= 15; i++)
		src[i] = ' ';
}

/*
 * sig - signal handling
 */

sig()
{
#ifdef OS2
	soclose(fd);
	soclose(fda);
#endif
	exit(1);
}


/*
 * dns2nb - convert DNS name to NETBIOS name
 */

dns2nb(dnsp, nbp)
	char           *dnsp;	/* ptr to a DNS name */
	char           *nbp;	/* ptr to a 16 byte buffer */

{
	unsigned char   idx;
	unsigned char   left;
	unsigned char   right;

	/*
	 * a compressed Netbios name is always 32 bytes long, so we can loop
	 * for a fixed amount, as long as the initial length byte is skipped
	 */

	for (dnsp++, idx = 0; (idx < SZ_NCBNAME); idx++, nbp++) {
		left = (*dnsp++ - 'A') << 4;
		right = (*dnsp++ - 'A');
		*nbp = left + right;
	}
}				/* end dns2nb() */


/*
 * nb2dns - convert NETBIOS name to DNS (first level encoded) name
 */

nb2dns(nbp, dnsp)
	char           *dnsp;	/* ptr to a 32 byte DNS name */
	char           *nbp;	/* ptr to a 16 byte buffer */

{
	unsigned char   idx;
	unsigned char   left;
	unsigned char   right;

	for (idx = 0; (idx < SZ_NCBNAME); idx++, nbp++, dnsp++) {
		*dnsp = (*nbp >> 4) + 'A';
		*(++dnsp) = (*nbp & 0x0f) + 'A';
	}
}				/* end dns2nb() */


/*
 * respond_local - look up name in the hosts file and respond to the query if
 * found.
 */

respond_local(nspkt)
	struct namepkt *nspkt;
{

	char            nbname[16];
	char            temp[17];
	char           *chp;
	struct rr_trailer *trailer;
	struct rr_info *info;
	int             count;


	dns2nb(nspkt->records, nbname);

	/* strip the trailing spaces (null terminate it) */
	for (chp = nbname; isalpha(*chp); chp++);
	*chp = 0;

	if (debug)
		fprintf(stderr, "Hosts file look-up of \"%s\" \n", nbname);

	/* get the address from the hosts file */
	host = gethostbyname(nbname);

	if (host) {
		if (debug)
			fprintf(stderr, "Address found : 0x%lx\n",
				ntohl(*(long *) host->h_addr));

		trailer = (struct rr_trailer *) ((char *) nspkt + nspkt_size - 4);
		nspkt->header.status = htons(NM_QRY_RES);
		nspkt->header.qdcount = 0;
		nspkt->header.ancount = htons(1);
		trailer->ttl = htons(1);
		trailer->length = htons(6);
		info = (struct rr_info *) trailer;
		info->flags = 0;
		info->nbaddr = ntohl(*(long *) host->h_addr);

		/* send the response packet (back) to the client */
		if ((count = sendto(fd, nspkt,
				    nspkt_size + sizeof(struct rr_info) - 4,
				  0, &from, sizeof(struct sockaddr))) < 0) {
			perror("nsd: sendto()");
			exit(1);
		}
		if (debug)
			fprintf(stderr, ">>> Sent 0x%x bytes to	Port:0x%x  Addr:0x%lx\n",
				count, ntohs(from.sin_port), ntohl(from.sin_addr.S_un.S_addr));

	} else {		/* gethostbyname() failed */
		if (debug)
			fprintf(stderr, "Address not found.\n");
	}
}
-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 17:23:46 GMT
From:      helios.ee.lbl.gov!horse.ee.lbl.gov!mccanne@ucsd.edu  (Steven McCanne)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump on 4.3 Reno?
In article <1990Jul26.025457.11527@gpu.utcs.utoronto.ca> molnar@gpu.utcs.utoronto.ca (Tom Molnar) writes:
>I don't yet have access to the 4.3 Reno distribution.  Could someone
>please tell me if the new tcpdump is available yet?

The new packet filter is not in the Reno distribution, but will definitely
make it into 4.4.  I currently have it up on our hp's running BSD Tahoe.
We'll include the filter with the next release of tcpdump, which should
be fairly soon...

Steve
-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 15:55:23 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        Rahul Dhesi <oliveb!tymix!cirrusl!sunstorm!dhesi@apple.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   was: the BSD lpd protocol? Stevens' Book

 >There is an amazing book out there that I haven't seen mentioned on
 >Usenet.  It is, "UNIX NETWORK PROGRAMMING" by W. RICHARD STEVENS.  It
 >is published by PRENTICE HALL and its ISBN is 0-13-949876-1.  At the
 >$41 price I paid, this book is a terrific 772-page gold-mine of
 >information.

i second this - it is extremely complete, so far as a 1 hour scan could
tell, v. well written and excellent value - i wish there could be an
equivalent text for kernel hackery for bsd, svid and, say, mach. then
lots of people could stop paying out megabucks to go on commercial
courses...

the structure is very similar to a course i teach on comms. software,
and i think i'm gonna recommend it as a base text....

 jon
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 20:23:39 GMT
From:      bellcore-2!envy!karn@rutgers.edu  (Phil R. Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol

In article <1990Jul26.144406.19495@ux1.cso.uiuc.edu>,
kline@ux1.cso.uiuc.edu (Charley Kline) writes:
|> Here at the U of I I can run "wxmap" and then tell it I want a map centered
|> on Champaign and a current conditions map will appear on my X display,
|> complete with weather watch boxes and severe weather risk areas. Radar data
|> is coming soon.
|> 
|> The code was homegrown here in the cornfields. The weather data comes
|> from Alden Electronics, a reseller of government weather data. It all
|> comes out in the WMO format, with which I struggle every day.

We also have one of the VSAT dishes on the roof, and one of my
colleagues has also been experimenting with displaying it on bitmap
screens. It's especially interesting to watch the radar maps when
thunderstorms roll through the area.

Unfortunately, even though the weather data comes from the government
the commercial resellers claim proprietary rights to it, so I'm not
sure it could be made freely available over the net. It's like RSA
claiming private patent rights to an invention developed with public
funds, but don't get me started on that...

Phil
-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 20:59:11 GMT
From:      rochester!spot!sma@rutgers.edu  (Susie Armstrong)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Temperature Quote Protocol
Here at WRC we've built a networked weather service which has been extremely
popular.  It consists of a weather station on the roof with a thermometer,
windcups, tipping bucket for rainfall, etc.  The station continuously feeds
information down a coax cable to a PC which exports the "weather service".
We have a couple of clients tools for various platforms (Xerox workstations
and Suns), which use a simple datagram-based protocol to periodically query
the PC "weather server".

Turns out there are lots of interesting things you can do with a packet worth
of snapshot data from such a weather server.  Client tools report obvious
things like current temperature, windspeed, etc and can also be smart enough
to manipulate the data to draw conclusions like how hard it is raining, wind
gusts, etc. (especially important to lunchtime runners in Rochester).

We have weather stations (and their corresponding PC servers) currently in
Webster and Tarrytown NY, Pasadena, Toronto, Dallas, and Atlanta, with El
Segundo and Cambridge, England in the process of installing one.  The project
originally started primarily because of one (JWright.wbst128@xerox.com)
person's interest in weather and remote instrumentation - it is now so popular
within Xerox that we've had to work hard with backoff algorithms and ways
of limiting the traffic.  Monitoring the traffic indicates the weather service
has at least 1000 users (most continuously polling the server).

There's a lot of weather junkies out there!

Cheers,
    Susie Armstrong
    System Sciences Lab
    Xerox Webster Research Center
    armstrong.wbst128@xerox.com
-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Jul 90 22:10:31 GMT
From:      Mills@udel.edu
To:        Charley Kline <swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!kline@ucsd.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Network Temperature Protocol
Charlie,

With all that horsepower you still struggle with WMO format? Zillions of
five-digit encoded obscurities? Surely a wee finite-state autonmaton such
as tinkered by one of my students can relieve that tension. Taking this
issue seriously, I personally eyeballed a PDP11/40 at Heathrow Airport
near London which tapped those digits from the weather wire and produced
a quite respectable English rendition suitable for automatic broadcast
by regions throughout the country. One of my radios has a feature that
announces its frequency in English. Strongly Japanese-accented English.

Dave
-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 23:07:30 GMT
From:      helios.ee.lbl.gov!ncis.tis.llnl.gov!lance.tis.llnl.gov!guerra@ucsd.edu  (Frank Guerra)
To:        tcp-ip@nic.ddn.mil
Subject:   Basic SLIP questions

   I'm hoping that the collective knowledge of the net.readers can shed some
light on my first real networking task.  I've been reading the protocols groups
for a couple of weeks now and know that most of this is well known and fairly
trivial, but I'd appreciate any insights.

   My first task has been to set up a SLIP connection.  Machine A is a PC
running Unix, machine B is a PC running bridge software (Emerging Technologies 
ET/Bridge), machine C is a PC with Telnet software, and Machine X is a Sun.
This is what it looks like:

----------------------------------------------------------------------------
Ethernet Backbone
----------------------------------------------------------------------------
                     ||                                   ||
                     || ethernet                          || ethernet
                     ||                                   ||
                   ------                               ------
                  |      |                             |      |
                  |      |                             |      |
                   ------                               ------
                 _________                             _________
                [Machine A]                           [Machine X]
                             |
                             | async modem
                             |
                      [SLIP interface A]


                             ^
                             |
                   ------    |/|                        ------
                  |      |     | async modem           |      |
                  |      |     |                       |      |
                   ------ [SLIP interface B]            ------
                 _________     |                        _________
                [Machine B]=============== ethernet ===[Machine C]

The goal is this : Machine B establishes a SLIP connection to Machine A.  With
that established, Machine C is then able to telnet to Machine X.

The static routing information for Machine A has three entries :

default 	<gateway machine> 1
Machine B	SLIP interface A 0
Machine C	SLIP interface A 0

The route table on Machine B has the single entry :

default 	SLIP interface B

since Machine B's only interface out is via SLIP interface B.

All of these machines are on the same network, 128.115.26.0.

The questions I have are this :

 - Is this legal?  Or is it more the case with a SLIP connection that it 
   requires it's own network in order to hang stuff other stuff off of the 
   connection?  It's been suggested that a new network number would need
   to be requested from the NIC.  I contend that only a subnet would need
   to be requested locally if at all.

- What needs to be in the routing table for SLIP interface B (Machine B)?
  It seems that it needs a default address to get out, but is there any more?

- The route table on Machine A has a network entry 128.115.0.0 that routes to 
  Machine A below the default route and above the entries for Machine B and 
  Machine C.  Hence it seems, that nothing will ever reach, and hasn't yet
  reached, either PC if it is being put on the ethernet instead.
  
- If another sub-net is required for the SLIP connection, how will the rest of
  the rest of the network know about it?  Will some other machine have to 
  create proxy ARPs for it, or is this taken care of by the SLIP daemon on the
  SLIP host?

- If anyone has had any experience or is using ET/Bridge, I'd appreciate any
  comments.

Thanks for any assistance.

Frank M. Guerra
guerra@lance.tis.llnl.gov
-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 90 23:22:28 GMT
From:      ssc-vax!bcsaic!carroll@beaver.cs.washington.edu  (Jeff Carroll)
To:        tcp-ip@nic.ddn.mil
Subject:   WIN/TCP 5.1 error...

I am getting a mystifying error (mystifying because there's nothing in
the docs about it) from WIN/TCP on my uVAX II.

%LPDSMB-F-FILEREAD,

What is happening? What should I check?

Jeff Carroll
carroll@atc.boeing.com
-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 00:18:36 GMT
From:      hpcc01!walasek@hplabs.hpl.hp.com  (Arthur Walasek)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM/HP-UX FTP session hangs on PORT command
>/ hpcc01:comp.protocols.tcp-ip / sscott@camdev.UUCP (Steve Scott) /  8:10 am  Jul 19, 1990 /
>
>
>Steve, we have seen a problem for a long time where FTP sessions from IBM
>TCPIP to an HP node would fail when the FTP application issued a PORT command.
>
>Any ideas out there?

Well Steve,

	Here is what we have found out.  IBM starts using port address for normal
	communications starting at port 1000 and working its way up.

	HP reserves up to port 1024 or system utilities and makes available ports
	after 1024.

	Therefore, when you first bring up the IBM and try to start ftp sessions,
	you have to error on the first 24 protected ports before any data will
	actually go across.

	I believe that the standard is to start at 1024, and therefore it is
	possibly an IBM problem....

	We have this problem too, and we set up the IBM to 25 transfers that will
	error, when TCP/IP comes up....  (really poor fix).


  If you need anymore information, or if I was too unclear, please mail
	me....
		
Arthur Walasek
Hewlett Packard
------------------------------
Ideas expressed are my own and are no way the expressions of Hewlett
Packard.
-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 00:19:27 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: POP Protocol
In article <270@nih-csl.nih.gov> tpersky@suntory.dcrt.nih.gov (Ted Persky) writes:

   Would anyone know which of the many mail packages out there
   implement the Post Office Protocol, POP?  

This is easily one of the most frequently asked questions on these
groups.  You should rummage through the comp.archives archives
(kept on cs.toronto.edu) for some recent announcements.

I'd like to see a newsgroup at some point to cover IMAP, POP, and
related protocols.

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
comp.archives moderator
-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Jul 90 08:20:09 -0400
From:      heker@nisc.jvnc.net (Sergio F. Heker)
To:        TCP-IP@nic.ddn.mil, mike@BRL.MIL
Cc:        heker@nisc.jvnc.net, net@nisc.jvnc.net
Subject:   Re:  Serious Routing Problems
Phil,

While the number of hops is large over JvNCnet (don't forget that the
network extends over eight states) I don't see a "serious routing loop" 
on your trace, in fact I don't see any routing loop.  

For your information, the JvNCnet network is a ring of T1s connecting 
backbone nodes colocated at the phone company point of presence with two 
cisco routers at each point of presence to add capacity and for reliability
purposes.  The backbone nodes are located at Trenton NJ, Newark, NJ, New
York City, New Haven, CT, Providence, RI, Boston, Mass and Philadelphia, PA.

On a test performed just now and attached below, 5 packets were lost of 
1000 with an average round trip of 51 ms on the path from one of our hosts
at the new JvNCnet headquarters at Princeton University and MIT.  This is 
quite reasonable.  

We have been monitoring access to NEARnet due to the importance of NEARnet as 
a whole and specially since the last three weeks we have experienced 
excellent performance.  This was also observed by the NSFNET NOC.  Previously
we were affected by a limitation to the amount of traffic carried by the
JvNCnet together with the routing table size (of about 300 networks) which
accounted for memory limitations.  Two major changes took place three
weeks ago on the JvNCnet cisco routers, the first one was an upgrade of all 
firmware (400 PROMS) to cisco 8.1 which improved the way cisco 7.1 handled 
changes of routing information.  The second change was a reduction of the 
cisco image running on the routers. We are very happy with the results and
the cooperation of cisco and the JvNCnet members as well as RCI our long
distance provider to make these changes expedioustly.

In anticipation of the installation of the new NSS for NEARnet, JvNCnet will
work with NEARnet in the installation of a temporary direct access T1 line
connecting NEARnet and JvNCnet directly at the JvNCnet NSS in Princeton.
The JvNCnet and NEARnet NOCs are working together to make this new NSS
transition become transparent to the users.

We always welcome comments on the network, however you should probably send 
them to a list more dedicated to this purpose than "tcp-ip".

If you do see a loop or a performance problem could you please send a message 
to our NOC.  We can be reached at "noc@nisc.jvnc.net".  

Thank you very much.

						-- Sergio

-- begin forwarded message --
	From owner-tcp-ip Thu Jul 26 18:24:56 1990
	Received: by nisc.jvnc.net (5.61/1.34)
		id AA01801; Thu, 26 Jul 90 18:24:54 -0400
	Received: from jvncb.csc.org by nisc.jvnc.net (5.61/1.34)
		id AA01797; Thu, 26 Jul 90 18:24:52 -0400
	Received: from NIC.DDN.MIL by jvncb.csc.org (5.61/1.34)
		id AA02895; Thu, 26 Jul 90 18:29:44 -0400
	Received: from WOLF.BRL.MIL by NIC.DDN.MIL with TCP; Thu, 26 Jul 90 08:42:22 PDT
	Received: by WOLF.BRL.MIL id aa14006; 26 Jul 90 11:33 EDT
	Date:     Thu, 26 Jul 90 11:25:38 EDT
	From: Mike Muuss <mike@BRL.MIL>
	To: TCP-IP@nic.ddn.mil
	Subject:  Serious Routing Problems
	Message-Id:  <9007261125.aa13838@WOLF.BRL.MIL>
	Status: RO

	This is one of the most painful trips from Maryland to Boston I have
	ever seen!
		-Mike

	From:     Phil Dykstra <phil@BRL.MIL>

	For ha ha's check this out:

	traceroute to expo.lcs.mit.edu (18.30.0.212), 30 hops max, 40 byte packets
	 1  ext328 (128.63.4.22)  21 ms  21 ms  26 ms
	 2  MOFFETT-FLD-MB.DDN.MIL (26.20.0.16)  586 ms  632 ms  272 ms
	 3  Palo_Alto.CA.NSS.NSF.NET (192.52.195.254)  238 ms *  200 ms
	 4  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13)  426 ms  497 ms  261 ms
	 5  Ann_Arbor.MI.NSS.NSF.NET (129.140.81.15)  275 ms  263 ms  367 ms
	 6  Princeton.NJ.NSS.NSF.NET (129.140.72.17)  303 ms  257 ms  248 ms
	 7  zaphod-gateway.jvnc.net (192.12.211.65)  271 ms  294 ms  250 ms
	 8  hotblack-gateway.jvnc.net (130.94.0.67)  271 ms  384 ms  287 ms
	 9  capital1-gateway.jvnc.net (130.94.1.9)  556 ms  472 ms  300 ms
	10  cheesesteak2-gateway.jvnc.net (130.94.33.250)  459 ms  294 ms  666 ms
	11  * * cheesesteak1-gateway.jvnc.net (130.94.32.1)  306 ms
	12  * beantown2-gateway.jvnc.net (130.94.27.250)  335 ms  311 ms
	13  near-gateway.jvnc.net (130.94.27.10)  335 ms  328 ms  385 ms
	14  ihtfp.mit.edu (192.54.222.1)  774 ms *  353 ms
	15  SEWAGE.MIT.EDU (18.68.0.8)  576 ms *  303 ms
	16  * MOSS.LCS.MIT.EDU (18.10.0.11)  344 ms  365 ms

	The MILNET throws it as far away as it possibly can, NSFNET spends
	four (nice orderly) hops getting it to Princeton, and then JVNC
	spends 7(!) hops getting it to Boston.

From "picasso.jvnc.net" to 18.10.0.11, 7/27/90 8:00am EST
.....
18 bytes from 18.10.0.11: icmp_seq=997. time=29. ms
18 bytes from 18.10.0.11: icmp_seq=998. time=31. ms
18 bytes from 18.10.0.11: icmp_seq=999. time=27. ms

----18.10.0.11 PING Statistics----
1000 packets transmitted, 995 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 26/51/932

______________________________________________________________________________

Sergio Heker				Phone #	(609)520-2000 (until 8/18)
Director, JvNCnet			Phone # (609)258-2400 (after 8/18)
					Email "heker@nisc.jvnc.net"
______________________________________________________________________________


-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Jul 1990 07:01 EST
From:      KONDA@VM.CC.PURDUE.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Please unsubscribe me from this list.
Thanks.
-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Jul 90 09:03:30 EDT
From:      hsw@sparta.com (Howard Weiss)
To:        TCP-IP@nic.ddn.mil, mike@BRL.MIL
Subject:   Re:  Serious Routing Problems
Here is another very strange route from sparta.com (137.39.6.2) connected
to Alternet/UUnet to brl.mil (McLean, Va. to Aberdeen, Md - roughly under
100 miles).  This path (Houston, San Diego, Palo Alto, and then back
across the county) seems to be the "normal" path taken for traffic from
Alternet via Suranet destined for the Milnet!

Howie

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

 1  annex.UU.NET (137.39.6.1)  340 ms  360 ms  300 ms
 2  janus.UU.NET (192.48.96.1)  300 ms  360 ms  360 ms
 3  sura6.sura.net (128.167.59.1)  360 ms  360 ms  360 ms
 4  192.80.214.254 (192.80.214.254)  360 ms  360 ms  360 ms
 5  Houston.TX.NSS.NSF.NET (129.140.75.9)  420 ms  420 ms  420 ms
 6  San_Diego.CA.NSS.NSF.NET (129.140.70.11)  480 ms  480 ms  420 ms
 7  Palo_Alto.CA.NSS.NSF.NET (129.140.77.6)  480 ms  480 ms  480 ms
 8  Palo_Alto.CA.NSS.NSF.NET (129.140.13.130)  480 ms  540 ms  480 ms
 9  BRL.MIL (26.2.0.29)  900 ms  1000 ms  1260 ms

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Jul 90 09:45:38 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: POP Protocol
Apropos of this, I am currently trying to:

1) Locate commercially supported PCMAIL, POP or IMAP servers (I know
of IBM's and Sun's, both intended for use with the vendor's DOS POP2
client, and the source-form POP server supplied by InterCon)

2) Jawbone big-system vendors into supporting servers for PCMAIL (two
supported OS/2 clients, a DOS due in a short while) or either version
of POP (several supported OS/2 and DOS clients, but I think they're
all POP2).

If you know of vendors I don't, send me e-mail.  I'll summarize.  If
you are a potential server vendor/supporter, you're welcome to get in
touch as well.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 05:58:24 GMT
From:      usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: whois Database

In article <90.207.20:58:20@ira.uka.de> nipper@iramu1.ira.uka.de (Arnold Nipper) writes:

   From: nipper@iramu1.ira.uka.de (Arnold Nipper)
   Organization: University of Karlsuhe, West-Germany

[Rough translation from the original German.  If you want a feed
of dnet.inet or any of the other German groups let me know.]

Now there's a new "whois" database.  It includes (among other
things) the information in NETWORK-CONTACTS.TXT.1 from nic.ddn.mil.
That includes all of the assigned network numbers as of about
a week ago.  Access the database remotely with

	whois -h iramu1.ira.uka.de <key>

or interactively as

	telnet iramu1.ira.uka.de [129.13.10.92] login: whois

Instead of "whois -h iramu1.ira.uka.de" you could also say
"telnet 129.13.10.92 43", this command connects you to the
whois port.  Doing it this way only lets you make one query.
(Only interesting for sites without name servers or corresponding
entries in /etc/hosts file.)

*******************************************************************************
Arnold Nipper ** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de
XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe * +49 721 608 4331
*******************************************************************************

--
[translation by]
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
comp.archives moderator
-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Fri 27 Jul 90 11:15:16-CDT
From:      Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL>
To:        emv@math.lsa.umich.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: whois Database

This posting from Germany brings up an interesting question:

Has anyone else created whois databases?
What machines?
Any on unix platforms?

Thanks in advance to any responses.

-Matt
-------
-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Jul 90 12:20:35 CDT
From:      darrel beach <beach@ddnuvax.af.mil>
To:        tcp-ip@nic.ddn.mil
Cc:        beach@ddnuvax.af.mil, afddn.cmd@gunter-adam.af.mil
Subject:   Those Milnet Mailbridges (clarification needed)



     Here's a query for the well informed GATEr on the internet.  It has to
Mail Bridges and the IGP they use, and how they use EGP.  First the drawing:

     The addresses are of course bogus and I'm hoping the picture is worth a
     thousand words because I'm not gonna describe it in detail:

		   +----------------------------------+
		   |                                  |
     Mailbridge    |                                  |   Mailbridge
     MB1    -------+       Milnet                     +------ MB2
     26.10.0.100   |       26.0.0.0                   |    26.2.0.2
		   |                                  |
		   |                                  |
    Router G1      |                                  |      Router G2
    to      -------+                                  +------to 192.50.50.0
    192.25.25.0 on |                                  |      on 26.1.0.50
    26.1.0.25      +-----+-----------------------+----+
			 |                       |
			 |                       |
			 |                       |
		    Router R1                Router R2
		    Gateway to               Gateway to
		    131.2.0.0                128.5.0.0 on
		    26.2.0.131               26.5.0.128


First let's assume the following:
	  R1 has only MB1 as an EGP neighbor
	  G1 has only MB1 as an EGP neighbor

	  R2 has only MB2 as an EGP neighbor
	  G2 has only MB2 as an EGP neighbor

	  MB1 and MB2 are using the IGP currently being used by the
	  Milnet Mailbridges.

The questions:
      1.  Is the following correct?
	  Its my understanding that MB1 does not provide the direct Milnet
	  address for EGP neighbors in its IGP exchange to MB2.  This would
	  result in the following routing table for R1:

	  192.25.25.0 via 26.1.0.25  at 2 hops;
	  128.5.0.0   via 26.2.0.2   at 3 hops;
	  192.50.50.0 via 26.2.0.2   at 3 hops;

	  If my understanding of what's in the IGP packets is correct, then
	  the effect is obvious and leads to Mailbridge bashing when a direct
	  route is available.

      2.  The real question is yet to come and is moot if I'm wrong about 1.

	  Let's change the neighboring of R1 to use both MB1 and MB2.  Let's
	  also say that R1 use a 10 minute poll and one mailbridge is polled
	  every 5 minutes, i.e. the polling is 180 degrees out of phase, wit
	  MB1 getting polled first.  After the first update R1's routing
	  table would be as follows:

	  192.25.25.0 via 26.1.0.25  at 1 hops;
	  128.5.0.0   via 26.2.0.2   at 2 hops;
	  192.50.50.0 via 26.2.0.2   at 2 hops;

	  When the update from MB2 was received, it would include the
	  following infomation:

	  192.25.25.0 via 26.1.0.25  at 1 hops;
	  128.5.0.0   via 26.5.0.128 at 1 hops;
	  192.50.50.0 via 26.1.0.50  at 1 hops;

	  So, would R1 now overwrite the existing routes with the new ones,
	  or maintain both routes and use the lowest hopcount??

	  And the real question is what do various implementations do under
	  such conditions???  If the routes get overwritten, which seems
	  logical to me, then you have a table that changes with every
	  update.  If you keep old routes when they're better than new ones,
	  you could never be sure the better route was still available.  I
	  guess there are several philosophies for handling this situation,
	  and I'd really like to know which is implemented by whom.

	  It must be apparent that the real question is what I describe in 1
	  the real scoop, or real poop.  I think it would be very dumb if
	  true, but I was actually told be someone (who shall now and always
	  remain nameless) I usually believe that 1 is the real scoop.  I was
	  also told, however, that it would soon change such that the IGP
	  exchanges would carry the info necessary to preclude 1 and let
	  everyone have direct routes where possible.

As usual, any info is appreciated, including flames IF THEY INCLUDE USEFUL
INFO.

Darrel Beach
....still only an egg after all this time
-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Jul 90 13:41 EST
From:      Electronic Mail Association <0002544290@mcimail.com>
To:        "tco-ip@nic.ddn.mil" <tcp-ip@nic.ddn.mil>
Subject:   test
this is a test

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Jul 90 12:52:24 EDT
From:      kate@tecnet1.jcte.jcs.mil
To:        tcp-ip@nic.ddn.mil
Subject:   novell, tcp, mac, suns, pcs
I am helping put together a mis plan that implements the machines in the
title. The sun will be running Sybase applications that the PCs and macs
need to get to. The sun is to act as a server of a sort. They are talking
about having a novell net also and the users need to be able to go between
tcp and novell easily. Actually, everything isn't in stone yet. Something
is needed to alow the pcs, macs and sun to be linked. Tops comes to mind
but the sun stuff isn't quite right yet. Does anyone out there have any
suggestions? The system has to be user friendly. Printers need to be hung
somehow so everyone can print. Does anyone know of a print server that can
be hooked to the network(not novell, just ethernet) or any other thoughts?

Thanks in advance. If you could mail to my mailbox, it would be easier. The
news I can read is tedious.

Kathi Samec
Kate@tecnet1.jcte.jcs.mil
-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 10:54:59 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you get a ENet Addr?
In article <1990Jul25.184017.192@tandem.com> kevinr@Tandem.COM writes:
+---------------
| In products we build, we give the board a default globally admin'ed 
| address.  We still allow the end user to change the current address,
| but the software will never let him pick a globally assigned
| style address.
+---------------

Notice that if are are running the Xerox NS (XNS) protocols on a multi-homed
host or gateway, you need to be able to set the physical address of all
Ethernet interfaces in the host to the same value, as XNS uses that address
as the host address. That is, in XNS the globally-unique "host address"
is a property of the *host*, not of the interface(s) as in TCP/IP.

[Reference: "Internet Transport Protocols", Xerox System Integration
Standard XSIS-028112, page 16]

What is often to simplify assignment of the "host address" is to use the
physical (globally administered) address off the "primary" network interface,
or if there is no reasonable notion of "primary", all the physical addresses
are read at boot time and the smallest/largest/one_in_slot#0/etc. is chosen
as "the" host address, and then that value is written back into *all* of the
network interfaces.

Clearly, your software restriction would prevent this.

+---------------
| Unfortunately, that part of the S/W hasn't been popular with our customers.
+---------------

I wonder why...   ;-}


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 11:05:13 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpdump on 4.3 Reno?


 >I don't yet have access to the 4.3 Reno distribution.  Could someone
 >please tell me if the new tcpdump is available yet?

btw. 'scuse my ignorance, but what is the origin of the 'tahoe', 'reno'
naming scheme - is't simply placenames?

thanks

 jon

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 11:07:58 GMT
From:      eru!luth!sunic!mcsun!unido!ms@BLOOM-BEACON.MIT.EDU  (Marc Sheldon)
To:        tcp-ip@nic.ddn.mil
Subject:   Socket emulation library for TLI
Some time ago somebody posted the adress for a ftp-site where
one could have gotten a socket emulation library for TLI.
I don't have that article anymore. Would somebody be so kind
and point me in the right direction ?

As i need this library for a test on monday i would really
appreciate any answers before that time.

Oh yes, could you please mail me the replies, i'll post a summary
if there is any interest.

Thanks,
	Marc

Marc R. Sheldon                             e-mail : ms@Uni-Dortmund.DE
University of Dortmund, CS-Department       BITNET : ms@UNIDO.bitnet
P.O.Box 500500                              voice  : +49 231 7552444
D-4600 Dortmund 50, (West)-Germany          FAX    : +49 231 7552386
-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 11:45:57 GMT
From:      mailrus!bbn.com!craig@tut.cis.ohio-state.edu  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   geography server
After mentioning the geography server I've gotten a number of queries
about it.

There's a section on it in the Internet Resource Guide, which can be
FTPed from nnsc.nsf.net.  The Geographic Name Server is part of Chapter
M (for Miscellaneous), section 3, so ftp the file:

    resource-guide/chapter.M/sectionM-3.ps
or
    resource-guide/chapter.M/sectionM-3.txt

where ps and txt get you the postscript and ascii versions respectively.

Craig
-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Jul 90 15:56:08 EDT
From:      root@popsrv.mail.cornell.edu (The Super-user)
To:        TCP-IP%NIC.DDN.MIL@ricevm1.rice.edu
Subject:   Re: IBM/HP-UX FTP session hangs on PORT command


q
-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 12:01:00 GMT
From:      KONDA@VM.CC.PURDUE.EDU
To:        comp.protocols.tcp-ip
Subject:   Please unsubscribe me from this list.

Thanks.

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 12:23:11 GMT
From:      abvax!sgtech!adnan@tut.cis.ohio-state.edu  (Adnan Yaqub)
To:        tcp-ip@nic.ddn.mil
Subject:   Where Have the On-line RFCs Gone?
I recently FTPed into nic.ddn.mil to grab an RFC only to find that
there where none there to be had.  This is the first time I have tried
to get an RFC via FTP.  Did I goof?  Have they been removed?  Have
they moved?

--
Adnan Yaqub (adnan@sgtech.uucp)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860
-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 12:26:40 GMT
From:      orc!bbn.com!mckenzie@decwrl.dec.com  (Alex McKenzie)
To:        tcp-ip@nic.ddn.mil
Subject:   BBN/Slate(TM) Academic Institution Discount Plan
Bolt  Beranek  and Newman, Inc. is pleased to announce an Academic Institution
Discount Plan for the BBN/Slate(TM) multimedia document communications system.
The  Plan  is  intended  to  foster  the understanding of BBN/Slate within the
academic community.  For this purpose  BBN  is  offering  the  software  at  a
substantially  reduced price of $100 per "active user" copy, to cover the cost
of distribution.

BBN/Slate software helps you  create,  edit,  communicate,  print  and  manage
multimedia  documents.   A BBN/Slate document may contain a number of powerful
media types, including:  Text, Geometric Graphics, Color Images, Scanned Black
&  White Images, Voice, Spreadsheets, Business Charts and Enclosures.  You may
print and file these documents as well as use electronic  mail  and  real-time
document conferencing to share these documents with others.

BBN/Slate  currently runs on five different types of workstations:  Sun 3, Sun
386i, Sun 4/SPARC under the SunView and  X11  window  systems,  the  IBM  RISC
System/6000 and the DEC VAXstation/Ultrix under the DECWindows window system.

To  find  out  more  information  about BBN/Slate and the Academic Institution
Discount Plan either write to:

		BBN Software Products
		10 Fawcett St.
		Cambridge, MA 02138

		Attn: BBN/Slate Academic Discount Program

or send electronic mail requests for information to:

		slate-academic@bbn.com

Please include your name and return surface mail postal address in either type
of request.
 
-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Jul 90 12:05:13 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump on 4.3 Reno?

 >I don't yet have access to the 4.3 Reno distribution.  Could someone
 >please tell me if the new tcpdump is available yet?

btw. 'scuse my ignorance, but what is the origin of the 'tahoe', 'reno'
naming scheme - is't simply placenames?

thanks

 jon

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 15:12:19 GMT
From:      gore!jacob@boulder.colorado.edu  (Jacob Gore)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: BBN/Slate(TM) Academic Institution Discount Plan
/ comp.protocols.tcp-ip / mckenzie@bbn.com (Alex McKenzie) /  Jul 27, 1990 /
> $100 per "active user" copy, to cover the cost of distribution.

This really isn't any of my business, but I can't help but wonder what you
guys use for distribution medium.  Sounds like gold-particle magnetic tape
:-)

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob
-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 15:34:41 GMT
From:      usc!wuarchive!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!kline@ucsd.edu  (Charley Kline)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
Mills@udel.edu writes:
>With all that horsepower you still struggle with WMO format? Zillions of
>five-digit encoded obscurities? Surely a wee finite-state autonmaton such
>as tinkered by one of my students can relieve that tension.

Oh lord no. I meant I struggled with the various categorization of
products by their WMO headers, some of which encapsulate an entire
product, others signify a set of products to follow, each of which to
be separated by ASCII RS characters, some have several products
separated by "zone codes" which seem to differ in syntax depending on
who is typing them in, and so on.

The kinds of things I parse are the SA observations, which I tried
writing a yacc grammar for but it was so full of ambiguities it wasn't
funny. My student wrote a chunk of code to convert them into little
data structures, which works fairly nicely. I also decode the Weather
Watch announcements, which are fixed-format enough that a perl program
can take a stab at pattern-matching them down to something useful.

>Taking this
>issue seriously, I personally eyeballed a PDP11/40 at Heathrow Airport
>near London which tapped those digits from the weather wire and produced
>a quite respectable English rendition suitable for automatic broadcast
>by regions throughout the country. One of my radios has a feature that
>announces its frequency in English. Strongly Japanese-accented English.

I'm trying to talk management here into a DECtalk box. Although the
geewhiz of talking computers has kind of lost its appeal these days;
everyone wants to see, not hear.  Another argument for the no-code
license, I guess.

Personal for Dave: What kind of radio is this? My latest acquisition is
an Icom IC-24AT, which doesn't speak but has that strongly Japanese
flavor nonetheless. For example in the manual. I love it for its size,
but the damn puts out five watts on high power, which is enough to get
the combination heat sink/belt clip hot enough to burn my hip.

_____________________________________________________________________________
Charley Kline, KB9FFK/KT, PP-ASEL                            c-kline@uiuc.edu
University of Illinois Computing Services                      (217) 333-3339
-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 23:21:18 PDT (Fri)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        Will@cup.portal.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: Are Commercial TCPs Berkeley Code Or Custom?
FTP Software's code isn't based on Berkeley's. It's based on MIT's
PC/IP, some of the primary authors of which (including me) founded
FTP. Internally, it bears little resemblance to PC/IP these days,
having been pretty heavily rewritten.

As for porting the Berkeley code, I find that people who don't know it
well take perhaps 4 months to bring up a port of it - it really wants
to live inside a UNIX kernel. They still find that this is cheaper and
faster than writing a TCP implementation from scratch. One of the
reasons is that the Berkeley code is a *very* good protocol engine
with a lot of time in the field. There are a lot of tricks to bringing
up a TCP implementation from scratch, some of which are decoding the
RFC's sufficiently well to get something "right", figuring out the
stuff that's not in the RFC's (one of the reasons behind writing the
Host Requirements RFC's, which represent "the wisdom of the ages"),
and testing against the great many other TCP's out there. Now, yes,
many of them are ports of the Berkeley code, but there have been
several versions of the Berkeley code with varying levels of protocol
compliance and bugginess, and many vendors manage to introduce their
own bugs in their ports because they don't really have a deep
understanding of what they're doing.

A few years ago, it was possible to have two different people go and
sit in different rooms and write TCP/IP implementations from scratch
and not have them interoperate at all, or have them interoperate
poorly and slowly. I believe this is largely still the case now - a
TCP written in a vacuum isn't worth much. There are a lot of issues
involved in getting this byte-oriented, sliding window protocol to
work over network media spanning less than 300 bps to over 100Mbps
from extremely noisy network links to perfect network transmission
media, with a variety of latencies and having to interoperate in a
world of many perhaps less than bug-free or well-tuned
implementations.

And then you want it to work well.

The Berkeley code represents a lot of experience rolled into one piece
of software. The edges that have to be glued into the system you roll
it into are pretty rough; it's not really designed for that, but what
you get is worth a lot, especially when real network wizards are
expensive and hard to find (and many have better things to do than
write "another" TCP implementation). Likewise, FTP Software has spent
a lot of time getting that experience into its code. A lot of FTP's
support time is dealing with *other* vendor's problems. A lot of
development work has gone into making code that's bulletproof (or at
least resistant) in the face of erratic behaviour on the part of its
network peers.

I think you'll find there are very few individual TCP's out there. The
vast majority are ports of the Berkeley code. Before 4.2BSD, there was
a 4.1 TCP from BB&N, which was rewritten (as I recall) into 4.2's
code, and for a while 4.2 shipped with both until only Berkeley's was
included. MIT's PC/IP was developed based on some code Dave Clark
wrote while on sabbatical in England and brought back to MIT with him;
this spawned a different line of UNIX TCP's, and a number of vendors
implementations are based on PC/IP. Most of these vendors have
probably put a lot of work into rewriting the TCP module, though,
because the one MIT provided was inappropriate and inadequate for
general purpose use. Phil Karn rolled his own in KA9Q (he'll correct
me if I'm wrong). I believe the NCSA telenet TCP is probably
independent, though I've never read the source code for it.

Then there are TCP's for other operating systems, like MIT's ITS (on a
PDP-10), the several varieties of Lisp Machines, Multics, and TOPS-20,
all of which are independent strains.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
King Kong died for your sins.
-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 17:57:33 GMT
From:      portal!cup.portal.com!Will@apple.com  (Will E Estes)
To:        tcp-ip@nic.ddn.mil
Subject:   Are Commercial TCPs Berkeley Code Or Custom?
Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan,
and FTP software written from scratch, or is the code basically just modified
Berkeley code?  Why is it so difficult to write a good TCP/IP?  I am
amazed that there are companies whose entire R&D seems to center around 
writing the TCP/IP protocol and supporting applications.  Is it really that
difficult?  You would think that if you started with the Berkeley stuff it
wouldn't be that difficult to improve it, or do legal restrictions prevent
you from using the Berkeley stuff as a base?  (You would think that it would
be pretty easy to license the Berkeley code from the owner if it isn't
public domain already....)

Will Estes        (sun!portal!cup.portal.com!Will)
-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 18:31:15 GMT
From:      swrinde!cs.utexas.edu!uwm.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Serious Routing Problems
In article <9007261125.aa13838@WOLF.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes:

> 
> From:     Phil Dykstra <phil@BRL.MIL>
> 
> For ha ha's check this out:
> 
> traceroute to expo.lcs.mit.edu (18.30.0.212), 30 hops max, 40 byte packets
>  1  ext328 (128.63.4.22)  21 ms  21 ms  26 ms
> ...
> 16  * MOSS.LCS.MIT.EDU (18.10.0.11)  344 ms  365 ms
> 
> The MILNET throws it as far away as it possibly can, 

	In defense of MILnet/NSFnet, it is extremely difficult to
make East/West routing work well.  This is not as bad as it seems
in context.  In other words, have a heart.   :-)

> NSFNET spends
> four (nice orderly) hops getting it to Princeton,

	Well, at least that part is working great.  Those Merit
folk do a good job.

> and then JVNC
> spends 7(!) hops getting it to Boston.
> 
	There is some history behind all this.  Might as well
discuss this here, since tcp-ip seems to be the catchall network
management list.  :-)

	Where to begin?  Way back when, NEARnet was but a gleam
in the eye, but those of us involved in the early stages of
NEARnet had confidence that it was the right thing to do.  +50
members and a year and a half later, I'd say we were right.  :-)

	But Internet access for this new network has been a 
tough nut and a chronic problem.  Would that there had been
a supercomputer center in Boston or that the backbone expansion
could have been expedited.  Spilt milk.

	We joined JvNCnet's Phase II backbone and have lived
on that for about a year, during a time of explosive traffic
growth.  The traffic growth, criticality of the connection,
and the large hopcount have resulted in less than ideal
connectivity.  I admit that this has gone on too long, but
I cannot recount for you all the things that have been attempted
and accomplished to remedy this situation.  At least the
traceroute terminated successfully.  That is an improvement.

	While we anxiously await an NSS in Boston, we have
discussed the matter most urgently with those in charge of
JvNCnet and we have come up with some changes to improve
our connectivity and reduce hopcount.  You should see results
from this redesign "soon".

	JvNCnet deserves our thanks for being a good neighbor
and trying their best to deal with a difficult situation,
during a period that has been difficult for them in dealing
with their own changes.  I think we have a plan that will work 
for the interim, but we can't really relax until the 
NEARnet NSS is up and running.  And we don't know when that
will be, but we are patient.  :-)

	But you still expect to get X distributions from MIT, no
matter what, eh?   :-)  I understand.

	--Kent
-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 18:33:51 GMT
From:      eplrx7!cristy@louie.udel.edu  (John Cristy)
To:        tcp-ip@nic.ddn.mil
Subject:   ARCNET <=> TCP/IP on UNIX

  Does anyone know about an ARCNET driver and card that can be attached
  to a UNIX system?  ARCNET is one of the cards/drivers that Novell uses in
  their LANS.  Untimately, I would like to attach an ARCNET LAN (IPX) to a
  LAN running ethernet (TCP/IP) and do the protocol conversion on the
  UNIX box.

--
The UUCP Mailer
-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 18:41:00 GMT
From:      0002544290@MCIMAIL.COM (Electronic Mail Association)
To:        comp.protocols.tcp-ip
Subject:   test

this is a test

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 19:16:56 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Where Have the On-line RFCs Gone?
In article <40@sgtech.UUCP>, adnan@sgtech.uucp (Adnan Yaqub) writes:
> I recently FTPed into nic.ddn.mil to grab an RFC only to find that
> there where none there to be had.  This is the first time I have tried
> to get an RFC via FTP.  Did I goof?  Have they been removed?  Have
> they moved?

Just looked and they are still there. 

ftp nic.ddn.mil
login anonymous
your-name
cd rfc:
ls

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Sat 28 Jul 90 03:13:33-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        portal!cup.portal.com!Will@apple.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Are Commercial TCPs Berkeley Code Or Custom?
    Are most of the commercial TCP/IPs sold by companies like Wollongong,
    Excelan, and FTP software written from scratch, or is the code
    basically just modified Berkeley code?

I would expect that most of the "large computer" commercial tcps are based
on some version of the Berkeley code.  Most of the PC TCPs are probably
based on the MIT PC/IP code, although these have mutated more.


    Why is it so difficult to write a good TCP/IP?

It's not.  But it isn't easy either.  Read the Host Requirements RFC
sometime.  It's much easier to copy code from someone who has it almost
right than to start from scratch.  I once made a bunch of improvemets to
the TCP for top20, but I reached the point where it would be easier to
port berkeley code than to start from scratch to implement some new
useful features. (Even though it would have meant figuring out a way
to integrate C into an all assembler OS.  Fortunately, I got a different
job about then... :-)

    I am amazed that there are companies whose entire R&D seems to center
    around writing the TCP/IP protocol and supporting applications.  Is it
    really that difficult?

Well, entire companies have been know to support applications that DON'T
involve a network.  It is clearly more difficult if there is a network too.
People want their applications (and their networks) without having to
understand anything about the underlying technology.  Making the network
invisible is very hard.  I wish more comercial companies put effort into
it.  (There ought to be a mail system easier to install than sendmail...)


    You would think that if you started with the Berkeley stuff it
    wouldn't be that difficult to improve it, or do legal restrictions
    prevent you from using the Berkeley stuff as a base?

Berkeley TCP/IP was (is?) developed under government contract, which makes
it pretty much available.  The problem used to be the pieces of unix that
it contained.  Of course, porting the code to a non-unix environment presents
opportunities for numerous bugs to creep in.  And keeping up with the rate
of change the tcp code goes through is pretty tough too.  And if you're
talking about improvements to the applications, you have to remember that
"improvement" is in the eye of the beholder...

BillW
-------
-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 20:23:46 GMT
From:      ibmsupt.uucp!bullhead!brunner@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   Marketing on tcp-ip (was Re: BBN/Slate(TM) ...)
In article <58504@bbn.BBN.COM> mckenzie@labs-n.bbn.com (Alex McKenzie) writes:
> (announces BBN's marketing for a multimedia product, deleted)

Alex, this posting _really is_ using the list and gatewayed newsgroup(s)
for commercial purposes.

Eric
Eric Brunner, Consultant, IBM AWD Palo Alto	(415) 855-4486
inet: brunner@monet.berkeley.edu		uucp: uunet!ibmsupt!brunner

trying to understand multiprocessing is like having bees live inside your head.
-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 22:01:03 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!lindh@ucsd.edu  (Andrew Lindh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you get a ENet Addr?
In article <1990Jul25.090203.1@rogue.llnl.gov>, oberman@rogue.llnl.gov writes
> .......
> putting out a device which gets it's Ethernet address from software.
> 
> I don't have the Ethernet or 802.3 spec handy, but I believe that this is NOT
> legal. And, even if it is, it's dangerous. It is critical that all Ethernet
> devices have globally unique addresses. The hardware assignment of these
> ainsures that there can NEVER be two the same.The portion of the spec allowing
> software to reset this address is something I've always objected to, but it is
> there.

Every DEC computer uses a software address!!! If you want to run DECnet
you have to change your address with software. I do not know if DEC
computers also have a hardware address. In this environment it is
very simple to have two computers with the same address...it drives
our bridges crazy!
-- 
Andrew Lindh, a student at the University of Hartford -- Computer Science
INTERNET: lindh@uhasun.hartford.edu | NOTE: All views here are MINE!!!
BITNET:   lindh@hartford.bitnet     | Not the school's or those of anyone else!
UUCP:     lindh@uhasun.uucp         | ---- When will I graduate???     "SYNFU!"
-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 22:11:31 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are Commercial TCPs Berkeley Code Or Custom?
: Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan,
: and FTP software written from scratch, or is the code basically just modified
: Berkeley code?

WIN/TCP for VMS version 5.1 is based on BSD 4.3
Mutlinet (by TGV, sometimes sold by Excelan) is based on BSD 4.3 Tahoe
Excelan?  Don't know for sure.
Fusion:  They wrote their own, then ported it to VMS

WIN/TCP for DOS version 4.1 is based on a very old version of IP/TCP written
	at MIT.  Most of the original code is gone now, but the copyright
	notices remain.
FTP software is also based on the MIT IP/TCP, but I don't know how much they
	have changed it.  Based on what I've seen from them at trade shows
	and on the net, I would guess that this is quite alot.  I also
	got the impression that is president had a great deal to do with
	the original IP/TCP implemetation.

The large number of people that use BSD is a reflection of its unrestrictive
licensing requirements.

Warner
--
Warner Losh		imp@Solbourne.COM
Boycott Lotus.		#include <std/disclaimer>
-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 22:13:59 GMT
From:      maverick.ksu.ksu.edu!herkimer.cis.ksu.edu!harv@rutgers.edu  (Harvard Townsend)
To:        tcp-ip@nic.ddn.mil
Subject:   Subnet/routing problems on SPARCstation

We are trying to implement a subnet in our department and are running into
problems. It seems like it should be so easy .... Our campus has a class B
network address, but no dept's have implemented any subnets with gateways up 
to this point. We want to subnet a number of X terminals on thin enet using a
Sun SPARCstation 1 with two enet interfaces as a gateway. Interface le0
is conneceted to the dept. backbone --  129.130.10 -- and le1 is the X
terminal subnet -- 129.130.11. Since there are no other subnets on campus,
all other systems just use 255.255.0.0 as the netmask. We can change all of
our systems (DEC, Harris, Sun, AT&T) to use 255.255.255.0, but have no
control over the other hosts on campus. Really, what we want is to have
all traffic for 129.130.11 to go through le1, and all OTHER traffic to go
out le0.  We have not hit on the right way to take care of the route
tables, however.

We have assigned an IP address for each interface according to the net 
they are connected to.  When we bring the the gateway up in single user mode,`
without starting routed, the route table lists le0 as the gateway for 
129.130.10 and le1 as the gateway for 129.130.11:

Routing tables
Destination		Gateway		...	Interface
localhost		localhost	...	lo0
129.130.10		orion 			le0
129.130.11		orion-x			le1

At this point, with a netmask of 255.255.255.0, any other network is not 
reachable. What we need now is to specify orion again (le0) as the gateway to
our campus net (ksunet -- 129.130) and then add the Proteon (campus gateway 
to off-campus sites via Midnet) as the default gateway for all other nets.
Also, when we bring it up to multi-user mode, the above subnet destinations 
are replaced by ksunet (129.130) and nothing can get to the X term subnet:

Routing tables
Destination		Gateway		...	Interface
localhost		localhost	...	lo0
129.130			orion 			le0
129.130   		orion-x			le1

Here's the diagram:

    X term		Dept. backbone -- 129.130.10
    ------             ================================ --> to campus net
    |    |                         |                        (129.130) and
    |    |                         |                        beyond
    ------                    -----------
       |                      |   le0   |
       |  129.130.11 subnet   |         |     le0 == 129.130.10.83 (orion)
   ---------------------------| le1     |     le1 == 129.130.11.1  (orion-x)
	       |              |         |
	    -------           -----------
	    |     |           SPARCstation
	    |     |
	    -------
	    X term

So, any ideas?  Thanks in advance,
______________________________________
Harvard Townsend, Systems Manager
Dept. of Computing & Information Sciences 
Kansas State University, Manhattan, KS 66506   (913)532-6350
Internet:  harv@herkimer.cis.ksu.edu
UUCP:      {rutgers, texbell}!ksuvax1!harv
AT&T Mail: attmail!htownsend
-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Sat, 28 Jul 90 03:06:55 EDT
From:      oleary@noc.sura.net (dave o'leary)
To:        tcp-ip@nic.ddn.mil
Subject:   routing to net 26

Currently there is no mailbridge connection at FIX East, and therefore
we do not inject routing information about Milnet networks into the
NSFnet here.  We are working with DCA and the staff at Mitre to bring
back the connection to the Mitre Mailbridge as an interim solution.
Further down the road (possibly September) there will be a mailbridge
connected directly to the FIX East ethernet here in our machine room.

This explains why packets to *any* host with Milnet-only connectivity
will traverse the NSFnet backbone to the NSS in Palo Alto (BARRnet),
where the Milnet routes are being advertised to the NSFnet.

Even when the East Coast FIX node is peering directly with the NSS, 
the NSS here accepts a route to net 26 only as a secondary (at least 
this is my understanding of the situation).  The East Coast mailbridge
node will be primary for those nets in the Eastern US, and the West 
coast node primary for the networks in the Western US.  However, 
net 26 is accepted as a primary advertisement at the BARRnet NSS, 
so as long as that peering is working, packets addressed to hosts 
on net 26 will go via the BARRnet NSS and Moffett Field Mailbridge, 
regardless of the geographic location of beginning and end points.

The situation is explained in more detail in RFC1133.

Thanks,

					dave o'leary
					SURAnet

					oleary@noc.sura.net
					(301)982-3214

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 23:15:11 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump on 4.3 Reno?
In article <9007271758.AA13923@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
>btw. 'scuse my ignorance, but what is the origin of the 'tahoe', 'reno'
>naming scheme - is't simply placenames?

"Tahoe' was the model name of the CCI system that they had to port the
4.3 system to, which had previously been almost exclusively a Vax-based
system.  Because of hardware architectural differences, they had to make
a bunch of changes so that it would run on the Tahoe, thus the name of
the release.

I'm told that the newer one is called 'Reno' because running it is 
taking a real gamble.  Snicker.
			- Brian
-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 90 23:27:50 GMT
From:      pacbell.com!tandem!moe!kevinr@ucsd.edu  (Kevin J. Rowett)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you get a ENet Addr?

In article <65311@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
|> In article <1990Jul25.184017.192@tandem.com> kevinr@Tandem.COM writes:
|> | address.  We still allow the end user to change the current address,
|> | but the software will never let him pick a globally assigned
|> | style address.
|> +---------------
|> as "the" host address, and then that value is written back into *all* of the
|> network interfaces.
|> 
|> Clearly, your software restriction would prevent this.

Not really, as the customer can set ther MAC address to any locally admin'ed
address they choose.

kevinr@Tandem.com
-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 00:49:27 GMT
From:      van-bc!mplex!fff@ucbvax.Berkeley.EDU  (Fred Fierling)
To:        tcp-ip@nic.ddn.mil
Subject:   SCO TCP/IP
We are running SCO Xenix 386 TCP/IP v1.0.1h (well, trying too!) and have noticed
a little 4 byte packet prepended to every full size packet on our SLIP link.
A datascope connected to the SLIP port shows this being transmitted (hex):

   c0  00 00 08 00  c0  45 00 00 2D ...

The second packet (starts with "45") fully conforms to RFC 791, but what is
that little runt doing there?
-- 
Fred Fierling     fff@eng.mplex.bc.ca     Tel: 604 875-1461  Fax: 604 875-9029
Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC   V5T 1A7,  Canada
-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 02:53:36 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you get a ENet Addr?
In article <1990Jul27.232750.22472@tandem.com> kevinr@Tandem.COM writes:
+---------------
| In article <65311@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
| |> In article <1990Jul25.184017.192@tandem.com> kevinr@Tandem.COM writes:
| |> | address.  We still allow the end user to change the current address,
| |> | but the software will never let him pick a globally assigned
| |> | style address.
| |> +---------------
| |> as "the" host address, and that value is written back into *all* of the
| |> network interfaces.
| |> Clearly, your software restriction would prevent this.
| Not really, as the customer can set ther MAC address to any locally admin'ed
| address they choose.
+---------------

But that completely negates all of the advantages of the known-unique
globally-administered addresses which come "for free" on each network
interface!

If you allow setting network physical addresses to any value [which, by
the way, nearly all of the hardware interfaces do], no customer ever has
to assign/hand_out/dis-ambiguate XNS addresses. All of the addresses on
all of the network boards on all of the hosts in his internet are globally
unique, and the "host addresses" that get used are merely a subset of the
globally-unique numbers available on each host. [Single-interface hosts
will default to the GU MAC address of their single interface, as usual.]

In what you propose, all of a sudden the *customer* is responsible for not
assigning any duplicate addresses ANYWHERE IN HIS/HER INTERNET, which may
span half the world and, which is worse, many different administrative
boundaries within the curtomer's own organization.

To me, this is a *major* loss of convenience and reliability, simply because
someone in your company decided that "customers [really, customer's network
software] can't be trusted to do it right."

PLEASE! We don't need any more "well-meaning" paternalism!


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 04:18:01 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   first alpha release 7.x of packet drivers
Hi.  The first alpha release 7.x of the Clarkson collection of PC
packet drivers is now available.  You can FTP it from
sun.soe.clarkson.edu, in pub/ka9q, as alpha.arc (you can also fetch it
by mail from archive-server).  Please note that this is an alpha test
release, and so should be kept far, far away from novice users.  The
two big improvements as of this release are delayed initialization
(lets you continue booting from a Novell drive using the boot rom's
driver), and Ethernet/802.3 conversion (lets you avoid econfiging your
Novell server).  We now have four new drivers, the Tiara LANCARD
driver, a Localtalk driver, NTI 16-bit driver and a Ungermann-Bass
PC/NIC driver.

See readme.1st and read.me for more details...

Please test these and report your experiences back to me, both good
and bad.  I'm pulling a Larry Wall -- I'm off on a week's vacation as
of tomorrow.  So, have lots of fun (I will!) and don't forget to mail
me a report.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
In Communism's central planning, citizens are told "you will make widgets".
In Capitalism's advertising, citizens are told "you will buy widgets".
-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 10:56:00 GMT
From:      bu.edu!transfer!crackers!cpoint!frog!msg!news@uunet.uu.net  (Alex Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol

If you're dead serious about it, you might think about CMOT.


-- 
Alex Brown
uunet!msg!alex
alex%msg.uucp@uunet.uu.net
-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 11:19:00 GMT
From:      bu.edu!transfer!crackers!cpoint!frog!msg!news@uunet.uu.net  (Alex Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
Steven Bellovin writes:
> Glenn P. Davis writes:
> > You probably don't want to hear this, but there are a number of
> > protocols and formats for weather info defined by the
> > "World Meterological Organization" (WMO).
> 
> I hope we don't have to use ASN.1 to encode them....

These codes were established for manual encoding of weather measurements 
reported by TTY;  most of them are now IA5 (ASCII) strings.  They aren't
easy to generate because many of the measurements are conditions such as
"partly cloudy" which are based on observer judgement.  The FAA is developing
a network of "Automated Weather Observation Systems" that establish 
uniform reporting algorithms.  Although the WMO messages aren't record-
oriented, other equivalent messages used internally in FAA systems are.
Haven't had to describe them with ASN.1 yet, but the day may come, because
the FAA is well underway in developing an ISO-stack real-time network for
air traffic information, weather, and other aviation data. 

BTW, this NTP is an example of how useless a toy protocol for automated data
collection can be.  If we're really serious about automated status or ambient
condition reporting, it should be done right, with Common Management Over TCP
(CMOT) which should eventually line up with ISO Common Management Info Svc 
and Protocol (CMIS/CMIP).  Sorry to have to say it here in the TCP lobby,
but this is the sort of thing that made real-world users nervous looking
at RFCs, leading to calls for the GOSIP mandates that many of you loathe.


-- 
Alex Brown
uunet!msg!alex
alex%msg.uucp@uunet.uu.net
-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 14:27:41 GMT
From:      usc!wuarchive!rex!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!peiffer@ucsd.edu  (Tim Peiffer (The Net Guy))
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Basic SLIP questions
In article <910@ncis.tis.llnl.gov> guerra@lance.tis.llnl.gov (Frank Guerra) writes:
>The questions I have are this :
> - Is this legal?  Or is it more the case with a SLIP connection that it 
>   requires it's own network in order to hang stuff other stuff off of the 
>   connection?  It's been suggested that a new network number would need

	This is legal.  The answer is different depending upon what type
	of net you are running.  From the net address 128.115.26.0,
	lll-labnet (128.115), you need only pick up a new *sub* network
	128.115.27 ??  from your local net administrator.  This is because 
	your particular network is a class B net.  If your particular lab 
	is to be isolated to 128.115.26, you could experiment with a different
	subnet mask, say 255.255.255.127.  If you chose this method, the
	8th bit of the host address would determine whether you are on 
	the slip network or not.
		Example:	128.115.26.10   local ethernet
				128.115.26.137  Slip ethernet (127+10)

>- What needs to be in the routing table for SLIP interface B (Machine B)?
>  It seems that it needs a default address to get out, but is there any more?

	As far as I can tell, you should have everything correct.

>  Machine C.  Hence it seems, that nothing will ever reach, and hasn't yet
>  reached, either PC if it is being put on the ethernet instead.

	Correct.
   
>- If another sub-net is required for the SLIP connection, how will the rest of
>  the rest of the network know about it?  Will some other machine have to 
>  create proxy ARPs for it, or is this taken care of by the SLIP daemon on the
>  SLIP host?

	As far as I can tell, this should be it.  You could think of doing
	proxy arps as an alternate.  Either method (subnet vs proxy arp) 
	should work.  Personally, I think the subnet mask is a much
	more efficient method of doing things. 


Tim Peiffer
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
MPLS MN 55455

-- 
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 17:25:18 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump on 4.3 Reno?
>"Tahoe' was the model name of the CCI system

Code name, actually - CCI machines were code-named after lakes (except
for one which was named after a pond).
-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 18:08:26 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: whois Database
In article <12609041797.18.AFDDN.JONSON@GUNTER-ADAM.AF.MIL> AFDDN.JONSON@GUNTER-ADAM.AF.MIL (Matt Jonson) writes:

   This posting from Germany brings up an interesting question:

   Has anyone else created whois databases?
   What machines?
   Any on unix platforms?

#!/bin/sh
whois -h iramu1.ira.uka.de $*		# german dnet
whois -h garcon.cso.uiuc.edu $*		# illinois, ph/qi nameserver
whois -h nic.ddn.mil $*			# ddn nic, tops-20
whois -h sh.cs.net $*			# csnet, csnet nameserver

I'm sure there are more..
-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 20:18:11 GMT
From:      mcdchg!laidbak!stevea@rutgers.edu  (Steve Alexander)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SCO TCP/IP
In article <5@mplex.UUCP> fff@mplex.UUCP (Fred Fierling) writes:
>We are running SCO Xenix 386 TCP/IP v1.0.1h (well, trying too!) and have 
>noticed a little 4 byte packet prepended to every full size packet 
>on our SLIP link.

SCO TCP/IP is derived from System V STREAMS TCP, which was originally
delivered to Lachman Associates (now a part of INTERACTIVE) by Convergent
Technologies in early 1987.  The 4-byte "runt" is a SAP identifier packet 
which was added by Convergent to support running non-IP protocols over the 
SLIP frame encapsulation.  It notifies the receiver that the next frame
is destined for the client bound to specified LSAP.  This code has never 
been used by Lachman for anything, but it survives in the SLIP driver to 
this day.  Obviously, it would only work between cooperating implementations.
I don't know if Convergent uses this for anything useful.

The 00 00 08 00 is 800 hex, which conveniently happens to be the Ethernet 
packet type for IP.  The idea was that network drivers would bind to SLIP
using the same SAP as they do for Ethernet.

I would expect that this "feature" will go away at some point, now that
we are committed to PPP.

Hope this clears up the mystery.

--
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 90 22:57:05 GMT
From:      news@psuvax1.cs.psu.edu  (Scott Schwartz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are Commercial TCPs Berkeley Code Or Custom?

In article <12609238094.10.BILLW@mathom.cisco.com> 
 BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:

   There ought to be a mail system easier to install than sendmail...

There is.  Rayan Zachariassen's Zmailer, even in alpha test,
is easier to use and more reliable than sendmail.
-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Jul 90 11:12:42 -0400
From:      Hans-Werner Braun <hwb@merit.edu>
To:        TCP-IP@nic.ddn.mil
Subject:   Re:  Serious Routing Problems
Any packet injected into the NSFNET backbone and destined towards MILNET
is currently only going via the only remaining NSFNET/DDN connection
at NASA Ames (FIX-West). This is in result of the FIX-East move at the
east coast two weeks or so ago and the MILNET connectivity there has not
been restored yet. It should be restored soon, I hope. To my knowledge
the regional networks as well as other agencies were aware of this. You
should really talk to the people who are responsible for your network
connectivity. I only quickly scan TCP-IP mailing stuff and am only seeing
these things by chance. Talking to your direct network provider should yield
faster and reliable responses.

	-- Hans-Werner

PS: To my knowledge, as soon as DCA signs off on their T1 link beween FIX-East
    and the Mailbridge site we can activate the east coast NSFNET/DDN 
    connection again. DCA is very cooperative here and is also keeping
    NSFNET staff well informed about the progress. Give it a few more days...

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Jul 90 3:39:51 EDT
From:      Phil Dykstra <phil@BRL.MIL>
To:        TCP-IP@nic.ddn.mil
Subject:   Re:  Serious Routing Problems
My original note was sent to an internal list; I didn't expect to
see it here.  Nonetheless, it has led to some interesting discussion.

To Sergio, note that no one used the term "loop".  Mike called it a
"problem" which I agree is debatable.  JvNC did get the packets there,
which one comes to appreciate when they are stuck behind a Buttergate.
Thanks for the informative reply.  I am somewhat aware of JvNCnet's
design.  Given the number of hops, I have to wonder how well the Cisco
routing protocol is doing, but then I don't know the net topology.
[Is an on-line map available?  I would very much like to see one.]

Thanks to Dave and Hans-Werner for the update on the FIX-East connection.
It will be nice when that is back on line.  And yes, every route I have
traced through the NSFNET Backbone has taken a very logical route.  The
Merit folks are doing a good job.

As of late last week up to now, the route from MOFFET-FLD to MIT has
started going via FEBA-WEST over WIDEBAND to BBN to MIT - a few less
hops.  This is perhaps even better than a direct Princeton to NEARnet
link, for the west coast, but that new link will be nice.

From my perspective (the MILNET), the number one problem is with the
Mailbridges (the "M" word).  Routes still flop around, and when they
do, you can get temporary net unreachables (which of course break
connections).  Some routes are hard to keep open for even ten minutes.
We have had numerous complaints from our own users and people comming
in from "outside".  We used to complain about this periodically last
Fall (to DCA or the folks at BBN), and while we grew tired of complaining,
the problem remains.

Looking forward to switching over to our ASNET connection to the world.

- Phil
-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Jul 90 13:40:30 -0500
From:      John S. Quarterman <jsq@tic.com>
To:        TCP-IP@NIC.DDN.MIL
Cc:        jsq@tic.com
Subject:   Re: was: the BSD lpd protocol? Stevens' Book
> >There is an amazing book out there that I haven't seen mentioned on
> >Usenet.  It is, "UNIX NETWORK PROGRAMMING" by W. RICHARD STEVENS.  It
> >is published by PRENTICE HALL and its ISBN is 0-13-949876-1.  At the
> >$41 price I paid, this book is a terrific 772-page gold-mine of
> >information.
>
>i second this - it is extremely complete, so far as a 1 hour scan could
>tell, v. well written and excellent value

See also the review in a recent issue of ConneXions.

> - i wish there could be an equivalent text for kernel hackery for bsd,

Leffler, Samuel J., McKusick, Marshall Kirk, Karels, Michael J., and
Quarterman, John S., The Design and Implementation of the 4.3BSD UNIX
Operating System, Addison-Wesley, Reading, MA, 1989, ISBN 0-201-06196-1.

> svid

Bach, M.J., The Design of the UNIX Operating System, Prentice-Hall,
Englewood Cliffs, NJ, 1986.

> and, say, mach.

Rumor has it that such is in progress.

> then lots of people could stop paying out megabucks to go on commercial
>courses...

Actually, the existence of such books tends to increase the number of
people who take such courses.

>the structure is very similar to a course i teach on comms. software,
>and i think i'm gonna recommend it as a base text....

Case in point....

John
--
John S. Quarterman
Texas Internet Consulting	jsq@tic.com	tel: +1-512-320-9031
701 Brazos, Suite 500	  uunet!longway!jsq	fax: +1-512-320-5821
Austin, TX 78701
-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Jul 90 09:38:14 EDT
From:      DBARTON@IBM.COM
To:        tcp-ip@nic.ddn.mil
Date:        Monday, 30 Jul 1990 09:37:25 EST
From:        Daniel Barton <DBARTON@IBM.COM>
To:          <TCP-IP@NIC.DDN.MIL>
Subject: Re: IBM/HP-UX FTP session hangs on PORT command

TCP/IP Version 2 for VM will start allocating ports at port number 1024,
to prevent this problem with the Hewlett Packard product.  Ports
1000-1023 are not restricted, and I am surprised that Hewlett Packard
does not have problems interoperating with other TCP/IP products than
VM.

A more graceful solution to the problem with the current VM code is to
reserve ports 1000-1023 using the PORT statement in the PROFILE TCPIP
configuration file.  This will prevent TCPIP from allocating the ports,
and prevent you from having to issue 24 errors to use up those ports.


Daniel Barton                    (Internet:  dbarton@ibm.com)
TCP/IP Development               (Bitnet:    dbarton@yktvmv.bitnet)
IBM Research Triangle Park, NC
-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 09:47:00 EDT
From:      "RANDY CATOE" <randy@TWG.COM>
To:        "qualcom!jwn2" <qualcom!jwn2@ucsd.edu>
Cc:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RE: WIN/TCP for VMS 5.3
Date sent:  30-JUL-1990 09:42:52 
>From:	ECOVAX::WINS%"<qualcom!jwn2@ucsd.edu>" 30-JUL-1990 09:33:42.03
>To:	RANDY
>CC:	
>Subj:	WIN/TCP for VMS 5.3
>
>From: John Noerenberg <qualcom!jwn2@ucsd.edu>
>Subject: WIN/TCP for VMS 5.3
>Message-Id: <2843@qualcom.qualcomm.com>
>Sender: tcp-ip-relay@nic.ddn.mil
>To: tcp-ip@nic.ddn.mil
>
>Week before last, I asked for help with Wollongong's NTYDriver for VMS
>and with NCSA Telnet.  Several offered advice and suggestions for which 
>I'm very grateful.
>
>But, fool that I am, I'm pushing on from VMS 5.1-1 to 5.3-2...or rather
>I'd like to.  I upgraded to 5.3-2 and tried to rebuild the Wollongong
>drivers.  Unfortunately, it was a bust.  Inetload tried to recalculate
>a new PTE offset.  This appeared to succeed, but when trying to load
>INDRIVER in SYSGEN, the status value returned by f$getdvi didn't agree
>with expectations.
>
>Has anybody gotten WIN/TCP to run under VMS 5.3?  Am I missing something
>obvious? (Like an upgrade for Wollongong?)
>
In order to install WIN/TCP after version 5.1-1b of VMS, WIN/TCP version 
5.02 or later is required; in that release DECwindows began to use the 
name "INDRIVER", which collided with the name of the WIN/TCP driver.

The latest version of WIN/TCP is 5.1, which works with VMS at least to
version 5.3.

Randy
................................................................................
.	J.R. Catoe			  --	----  	   ----
.	The Wollongong Group, Inc.        --    --  --    --
.	7799 Leesburg Pike                --    --  --    --
.	Suite 1100 North Tower        --  --    ----      --
.	Falls Church VA 22043         --  --    --  --    --
                                        --      --   --    ----
................................................................................

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 08:49:48 GMT
From:      qualcom!jwn2@ucsd.edu  (John Noerenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   WIN/TCP for VMS 5.3
Week before last, I asked for help with Wollongong's NTYDriver for VMS
and with NCSA Telnet.  Several offered advice and suggestions for which 
I'm very grateful.

But, fool that I am, I'm pushing on from VMS 5.1-1 to 5.3-2...or rather
I'd like to.  I upgraded to 5.3-2 and tried to rebuild the Wollongong
drivers.  Unfortunately, it was a bust.  Inetload tried to recalculate
a new PTE offset.  This appeared to succeed, but when trying to load
INDRIVER in SYSGEN, the status value returned by f$getdvi didn't agree
with expectations.

Has anybody gotten WIN/TCP to run under VMS 5.3?  Am I missing something
obvious? (Like an upgrade for Wollongong?)

Thanks for your advice and sympathy!

jwn2
-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Jul 90 16:19 EST
From:      Electronic Mail Association <0002544290@mcimail.com>
To:        "tcp-ip@nic.ddn.mil" <tcp-ip@nic.ddn.mil>
Subject:   ELECTRONIC MESSAGING '90

Marshall Rose suggested I send this to you for posting to all users. 
I hope this is of general interest to the group. Thank you!

* * * * * * *



ELECTRONIC MESSAGING '90:
    BEYOND INTERPERSONAL CORRESPONDENCE 

WHEN: October 22-24, 1990

WHERE: The Fairmont Hotel, San Francisco, Ca.

SPONSORED BY: The Electronic Mail Association

The Electronic Mail Association's annual conference expands to three days
for 1990. An exciting program that includes more than twice as many
speakers as ever before will examine such diverse topics as:

  o  Corporate Messaging Strategies
  o  End-User Training                
  o  Messaging Integration With EDI & FAX
  o  X.500 Directories
  o  CCITT Update
  o  LAN User Issues
  o  Gateways & Connectivity
  o  Groupware
  o  Portable Messaging
  o  Global Trends

John A. Young, President & Chief Executive Officer of Hewlett-Packard,
will deliver the keynote address.

Special new features at "Electronic Messaging '90:  Beyond Interpersonal
Correspondence" include a focused user/vendor discussion of upcoming
industry trends, led by EMA chairman Rich Miller, and a  Sunday night 
pre-conference user-to-user briefing on messaging terminology 
for those new to the industry.

*** CONFERENCE SPEAKERS *** 

Below is a partial list of confirmed speakers for Electronic Messaging '90: 

John A. Young, President & CEO, Hewlett-Packard
Hellene S. Runtagh, President, GE Information Services
Jose A. Collazo, Chairman & President, Infonet
Richard H. Miller, President, Rapport Communication, Inc. & Chairman, EMA
Peter W. Donaghy, Customer Service & Support Manager, Hughes Aircraft Co.
Michael D. Zisman, President, Soft Switch, Inc.
Donald M. Gilbert, Information Services Director, American Petroleum Institute
Kenneth Hutcheson, EDI Director, E.I. DuPont de Nemours & Chairman, X12
Richard Norris, Practice Leader for Logistics, Arthur D. Little, Inc.
Jeanne P. Bracken, Message Handling Systems Director, Pacific Bell
Donald Ryan, Vice President of ICS, BIS CAP International
Robert Johansen, Senior Research Fellow, Institute for the Future
Gursharan Sidhu, Technical Director, Apple Computer, Inc.
 
*** SCHEDULE OF EVENTS ***

MONDAY, OCTOBER 22

Plenary Panel Sessions:

Industry Trends & Perspectives
Business Case for Corporate Messaging Strategies

Luncheon

EDI & Messaging Integration Trends
User Perspectives on Messaging Trends


TUESDAY, OCTOBER 23

Keynote Address by John A. Young

Concurrent Panel Sessions:

Marketing Electronic Mail Inside the Corporation
Directories
End-User Training & Support
CCITT Update

Luncheon

Concurrent Panel Sessions:

IBM Messaging Update
Integration & Applied Messaging
Groupware
DEC Messaging Update
Integrating Information Services & Messaging
Portable Messaging

WEDNESDAY, OCTOBER 24

Concurrent Panel Sessions:

LAN Messaging Trends
Privacy & Security
Gateways & Connectivity
LAN User Issues 
Legal Issues in Messaging & EDI
Global Trends
Policy & Regulatory Issues
User/Vendor Industry Discussion

Adjourn
1 p.m.
 

*** REGISTRATION INFORMATION ***

Conference Fees
Regular Conference Fee
$695 (If received by 8/31 ... $645)
Special EMA Member Fee
$495 (If received by 8/31 ... $445)

Pre-registration is required.

The special member fee applies to all employees of member organizations
attending Electronic Messaging '90, so your membership may pay for itself
through the conference fee discounts. Contact the association for more
information about joining EMA.

Early Bird Discount

Registrants who pay the conference fee in full by August 31 may deduct
$50 from the conference fee.

Cancellations

All cancellations will be subject to a $50 processing fee. The balance of the
conference fee will be refunded provided written notice of cancellation is
received by EMA no later than October 15.

Hotel Accommodations

Electronic Messaging '90 will be held at The Fairmont Hotel, San Francisco, Ca.
Rooms are available at the special conference rate of $135 single/$155 double
(Main Bldg. Interior), $155 single/$180 double (Main Bldg. Exterior), 
$205 single/$225 double (Tower City View), $245 single/$265 double 
(Tower Bay View). Register with the hotel directly at 415/772-5000 before 
September 21, 1990 to guarantee the above rates and availability. Please note
that you are with the Electronic Mail Association room block.

Airline Reservations

American Airlines is the official airline for Electronic Messaging '90. For the
convention rate, please contact (or have your travel agent contact) the
American Airlines convention desk at 1-800-433-1750 and ask for star
file number S04O04E.

TO REGISTER OR TO RECEIVE FURTHER INFORMATION

Electronic mail is the easiest way to register! Please message, fax or mail
registration information to EMA at the address below. Information should 
include:

Name (Full, Middle Initial, Last)
Title
Company
Address
City, State, Zip
Telephone Number
Fax Number
Electronic Mail Address
Method of Conference Fee Payment (Member or Nonmember)

Electronic Mail Association
1555 Wilson Boulevard
Suite 555
Arlington, VA 22209-2405
Tel: 703/522-7111
Fax: 703/528-4251

AT&T Mail:     !EMA
CompuServe:    70007,2377
Dialcom:       63:PRD003
EasyLink:      62886257  
Envoy 100:     EMA
GEnie:         EMA
INET:          ema.association
MCI Mail:      EMA/2544290
SprintMail:    [ema/associates]
                mail/usa
 
FOR A COMPLETE LIST OF SPEAKERS, CONTACT EMA ELECTRONICALLY.


* * * * * 

Please let me know if there will be any problem posting this. Thanks again!

Amy Louviere
Director, Marketing
EMA

.
-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 12:42:10 GMT
From:      mcsun!hp4nl!charon!piet@uunet.uu.net  (Piet Beertema)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol

	If sucessfully implemented, such a protocol would also contribute 
	towards reducing Global Warming.
Wonder if it would help reducing temperature in more
exotic places too, like those mentioned below:

============================================================================
   Some consolation
   ----------------

   I wish to clear up the old question: "Which is hotter, heaven or hell?"

   Verse 26 of Chapter 30 of Isaiah defines the energy radiated heavenward
   by the sun and the moon in terms of the amount received by the earth:
   "Moreover the light from the moon shall be sevenfold, as the light from
   seven days". Thus, heaven receives from the moon as much energy as the
   earth does from the sun. If we add to that 49 times ("seven times seven")
   the earth's solar radiation falling on heaven, we have a total of 50 times
   the energy we receive from the sun. Using a known absolute temperature
   of the earth and the Stefan-Boltzmann fourth-power law, we arrive at the
   determined temperature of heaven: a less than paradisiacal 525 degrC.

   And the temperature of hell?

   Revelation 21:8 says: "The fearful shall have part in the lake which burns
   of fire and brimstone". Since brimstone (sulfur) has a boiling point of
   445 degrC, hell must be several degrees cooler. If it were not, it would
   be a vapor, not a lake.

   Therefore, heaven is hotter than hell by at least 80 degrC.
============================================================================

(Actually this story is a couple of years old already;
can't remember where I ever got it from).

--
	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)
-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 13:38:14 GMT
From:      DBARTON@IBM.COM
To:        comp.protocols.tcp-ip
Subject:   (none)

Date:        Monday, 30 Jul 1990 09:37:25 EST
From:        Daniel Barton <DBARTON@IBM.COM>
To:          <TCP-IP@NIC.DDN.MIL>
Subject: Re: IBM/HP-UX FTP session hangs on PORT command

TCP/IP Version 2 for VM will start allocating ports at port number 1024,
to prevent this problem with the Hewlett Packard product.  Ports
1000-1023 are not restricted, and I am surprised that Hewlett Packard
does not have problems interoperating with other TCP/IP products than
VM.

A more graceful solution to the problem with the current VM code is to
reserve ports 1000-1023 using the PORT statement in the PROFILE TCPIP
configuration file.  This will prevent TCPIP from allocating the ports,
and prevent you from having to issue 24 errors to use up those ports.


Daniel Barton                    (Internet:  dbarton@ibm.com)
TCP/IP Development               (Bitnet:    dbarton@yktvmv.bitnet)
IBM Research Triangle Park, NC

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 14:46:37 GMT
From:      dino!hascall@uunet.uu.net  (John Hascall)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are Commercial TCPs Berkeley Code Or Custom?
In article <32140@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:

}Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan,
}and FTP software written from scratch, or is the code basically just modified
}Berkeley code?  Why is it so difficult to write a good TCP/IP?
		 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   Try it sometime!!  It has taken me over a year of evenings (as many as
my wife will stand for :-) to put together a good solid ARP,IP,ICMP,UDP,TCP,DNS
under VAX/VMS (working entirely in assembly doesn't help!).  And that still
leaves all the "user" stuff (Telnet, FTP, etc...).  [And since the arrival
of 300+ DECstations, VAXes look to be dead here soon, sigh.]

   A big part of the difficulty is all those RFCs -- if you have a working
implementation and a new "good thing" comes out, it is usually not that hard
to add it (unless of course your code looks nothing at all like BSD's :-(
but to try to get all of those things working while more are being thought-up
every day is rather a losing battle.

   By my estimation, most (at least half) of the difficulty is in TCP.
The other half was reverse-engineering DEC's "backdoor" into the ethernet
driver.  Leaving the rest as the third half.

John Hascall  /  john@iastate.edu  /  hascall@atanasoff.cs.iastate.edu
-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 14:47:29 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bcars8!bnrgate!bcarh342!mleech@ucsd.edu  (Marcus Leech)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
In article <9007251236.aa03466@huey.udel.edu>, Mills@udel.edu writes:
> 
> globe. While this station has since shut down, Halifax Radio CHU
> presently broadcasts 75-baud radioteletype messages (along with
CHU is a station operated by our National Research Council to propagate
  time-of-day information, and NOTHING ELSE. It's also located in
  Ottawa, Ontario--not Halifax, Nova Scotia.  Canada does operate a
  number of shortwave services--you probably just got the callsign
  wrong, Dave.  There could, of course, be another CHU that I'm
  unaware of, but having two stations with the same callsign and
  completely different purposes would be too strange...


-----------------
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
VE3MDL@VE3JF.ON.CAN.NA         Ottawa, ON, CANADA      |necessarily BNRs
-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 16:01:16 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!masscomp!simon@ucsd.edu  (Simon Rosenthal)
To:        tcp-ip@nic.ddn.mil
Subject:   Availability of SNMP MIB for X.25

Hi:

	Can anyone out there point me to a SNMP MIB for an X.25 interface,
if such a creature exists.

	 Thanks in advance ..

- Simon
_______________________________________________________________________________
Simon Rosenthal: 				 ___________
Concurrent Computer Corporation 		/ _________/_        	
Westford, MA 01886 				/_/________/ /
Internet: simon@westford.ccur.com
-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 16:40:55 GMT
From:      mcsun!ukc!tcdcs!swift.cs.tcd.ie!ul.ie!bourkej@uunet.uu.net  (John Bourke)
To:        tcp-ip@nic.ddn.mil
Subject:   Spare some advice for an old ex-lepper
Hi,

We are trying to come to grips with the TCP/IP protocols before people
come screaming to us looking for services and advice.  At the moment we
have CMU on the Vax and PC's running 3COM TCP/IP.  We have no UNIX hosts,
no subnets, no gateways, no connection to the internet; no nothing.

Can anyone offer some words of wisdom from their expereinces, or, if you were
to start from scratch, what would you do different ?


John Bourke								 O-O
<bourkej@ul.ie>								  | 
Information Technology Department,					# _ #
University Of Limerick, Ireland.					 ###
-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 17:29:52 GMT
From:      artemis.ll.mit.edu!olsen@XN.LL.MIT.EDU  (Jim Olsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
>>In article <9007251236.aa03466@huey.udel.edu>, Mills@udel.edu writes:
>> Halifax Radio CHU presently broadcasts 75-baud radioteletype messages...

Marcus Leech writes:
>  CHU is a station operated by our National Research Council to propagate
>  time-of-day information, and NOTHING ELSE.

The Canadian Forces Halifax station is CFH.  It does indeed broadcast
radioteletype and facsimile weather reports and forecasts on a number
of HF frequencies.  For those interested, I have appended some
frequency information and a FAX schedule (perhaps out of date).  At
least here in New England, the CFH signals are quite strong and easily
received.

------
CFH Radioteletype frequencies (some part-time):
  75-baud radioteletype, 850-Hz shift: 4271, 6330, 6338, & 10536 kHz
  FEC radioteletype: 13351 kHz
------
Forwarded from rec.radio.shortwave:

From: roskos@IDA.ORG (Eric Roskos)
Subject: New CFH Fax Schedule
Date: 29 Jan 90 00:50:20 GMT
Organization: IDA, Alexandria, VA

A few mornings ago I happened to be up at 5AM when CFH sends its Fax
schedule, and thus recorded the current schedule.  According to a note
at the bottom, this is a new schedule as of 1/15/90, so here is the
current schedule.  (This was sent via Fax and is hand-transcribed below,
so any errors are probably mine.)

Note that while some of these charts are local to Nova Scotia in their
coverage, others, such as the surface analysis, cover the entire east
coast of the US.  The Surface Analysis is the old-fashioned hand-drawn
kind with the graphical symbols, rather than the digitally-produced NOAA
kind with the nearly (if not entirely) illegible small numbers -- it's
especially good if you're using a PK232 or other low-resolution device,
since the large lines and lettering make it easy to read by comparsion
to the NOAA charts.

	Canadian Forces Metoc Centre Halifax
	FMO Halifax, Nova Scotia B3K 2X0
		   Canada

	CFH Facsimile Broadcast Schedule
		Transmitting On
   LF: 122.5 KHz / HF: 4.271-6.330-10.536-13.510 MHz

No.   Trans Time Chart Description		      Valid Time
================================================================
WHF01 0001-0014Z Significant Weather Depiction		1200Z
----- 0015-0037Z Ice Chart				Latest
CFH01 0101-0114Z 850 MB Forecast Wind/Temp/Height	18Z/00Z
CFH04 0301-0312Z 500 MB Analysis			0000Z
CFH03 0312-0331Z Surface Analysis North			0000Z
CFH03 0331-0338Z Surface Analysis South			0000Z
WHF02 0401-0414Z Wave Analysis				0000Z
WHF03 0414-0427Z 12 Hr Significant Wave Prognosis	1200Z
CFH02 0427-0438Z 850 MB Analysis			0000Z
CFH05 0501-0514Z 24 Hr Isobaric Prognosis		0000Z
WHF04 0514-0527Z 24 Hr Significant Wave Prognosis	0000Z
WHF05 0601-0614Z Significant Weather Depiction		1800Z
WHF06 0614-0627Z 36 HR Significant Wave Prognosis	1200Z
CFH06 0701-0714Z 850 MB Forecast Wind/Temp/Height	18Z/00Z
CFH07 0801-0814Z 36HR Isobaric Prognosis		1200Z
CFH08 0814-0833Z NFLD SST -Wed-Sat- (NS OFA -Tue-)	Latest
		 NS SST -Sun-Thu- (NFLD OFA -Mon-Fri-)
CFH09 0901-0920Z Surface Analysis North			0600Z
CFH09 0920-0927Z Surface Analysis South			0600Z
CFH07 1000-1014Z 36 Hr Isobaric Prognosis (Repeat)	1200Z
----- 1014-1026Z CFH Test Chart -Tue-Thu-Sat-		-----
----- 1014-1026Z CFH Fleet Broadcast Schedule		-----
----- 1101-1123Z Ice Chart				Latest
WHF08 1201-1214Z Significant Weather Depiction		0000Z
----- 1301-1323Z Ice Chart				Latest
----- 1401-1423Z Ice Chart				Latest
CFH10 1423-1438Z 850 MB Forecast Wind/Temp/Height	06Z/12Z
CFH14 1501-1512Z 500 MB Analysis			1200Z
CFH13 1512-1531Z Surface Analysis North			1200Z
CFH13 1531-1536Z Surface Analysis South			1200Z
WHF09 1601-1614Z Wave Analysis				1200Z
WHF10 1614-1627Z 12 Hr Significant Wave Prognosis	0000Z
CFH11 1627-1638Z 850 MB Analysis			1200Z
CFH15 1701-1714Z 24 Hr Isobaric Prognosis		1200Z
WHF11 1714-1727Z 24 Hr Significant Wave Prognosis	1200Z
WHF13 1801-1814Z Significant Weather Depiction		0600Z
WHF12 1814-1827Z 36 Hr Significant Wave Prognosis	0000Z
CFH16 1901-1914Z 36 Hr Isobaric Prognosis		0000Z
CFH17 2000-2014Z 850 MB Forecast Wind/Temp/Height	06Z/12Z
WHF14 2014-2033Z NS SST (NFLD SST -Mon-Wed-Sat-)	Latest
WHF14 2101-2120Z NS OFA (NFLD OFA -Mon-Wed-Sat-)	Latest
CFH18 2120-2139Z Surface Analysis North			1800Z
CFH18 2139-2146Z Surface Analysis South			1800Z
----- 2201-2223Z Ice Chart				Latest
----- 2301-2323Z Ice Chart				Latest

-- 
Eric Roskos (roskos@IDA.ORG or Roskos@DOCKMASTER.NCSC.MIL)
-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 17:47:32 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!ultra!rajiv@ucsd.edu  (Rajiv Dhingra)
To:        tcp-ip@nic.ddn.mil
Subject:   ARP hardware address space values
Can someone tell me who assigns values for the field 'hardware
address space' which is present in ARP packets.  I am interested
in getting a couple of values assigned for us, Ultra. 

Thanks,

Rajiv Dhingra
  Ultra Network Technologies     domain: rajiv@Ultra.COM
  101 Daggett Drive            Internet: ultra!rajiv@Ames.ARC.NASA.GOV
  San Jose, CA 95134               uucp: ...!ames!ultra!rajiv
  408-922-0100
-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 18:08:00 GMT
From:      swrinde!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: BBN/Slate(TM) Academic Institution Discount Plan
In article <670007@gore.com> jacob@gore.com (Jacob Gore) writes:
>> $100 per "active user" copy, to cover the cost of distribution.
>
>This really isn't any of my business, but I can't help but wonder what you
>guys use for distribution medium...

The cost of distribution is mostly people time, not media cost.  Only if
you have actually done distribution (I have) do you have any idea how much
time and frustration is involved.
-- 
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry
-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 18:50:50 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Serious Routing Problems
In article <9007300339.aa00505@SPARK.BRL.MIL>, phil@BRL.MIL (Phil
Dykstra) writes:
> ... Given the number of hops, I have to wonder how well the Cisco
> routing protocol is doing, but then I don't know the net topology.

	Not too well in my opinion.  Chuck Hedrick from Rutgers posted some
very informative material in comp.dcom.sys.cisco about setting timers in IGRP
to speed convergence.  The timers are now settable in cisco configs.

	When lines flap for whatever reason, routes in IGRP go away and get
held down for many minutes, breaking TCP connections.  While caution must
be used, in many cases, shortening up the IGRP reaction times will prevent
line flaps from turning into big route lossage.  It all depends on how you have
your net set up.

	In my opinion, this will become a thing of the past with link
state protocols.  I'm anxious to see results from the OSPF early deployments
in NASA and SURAnet.

	Milo, Dave;  How does OPSF do when you have routes flapping?  Instant
convergence?

	--Kent
-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 18:52:31 GMT
From:      wotk!root@uunet.uu.net  (Superuser)
To:        tcp-ip@nic.ddn.mil
Subject:   Internet Access
Can someone tell me how my company can get connected to the Internet?
Is it even possible? I need details. Thanks.

Nick Hennenfent				Voice  404 475-2725
Computone Products			FAX    404 343-9735
1100 Northmeadow Parkway		Usenet ...!uunet!wotk!nickh
Suite 150
Roswell, GA 30076
-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 20:31:06 GMT
From:      hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu  (Lars Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: WIN/TCP 5.1 error...
In article <28900@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes:
>I am getting a mystifying error (mystifying because there's nothing in
>the docs about it) from WIN/TCP on my uVAX II.
>
>%LPDSMB-F-FILEREAD,
>
>What is happening? What should I check?

Decoding the message identifier according to normal rules says that
a component called LPDSMB (probably a print symbiont which is a client
for the Berkeley Line Printer Daemon; i.e. talking to a remote print
queue over the network) had a FILEREAD error.

Sounds to me like 

(1) You have a print queue connected to a printer on another system
(2) A file was submitted to this print spooler, and probably deleted
    while it was sitting in the queue (was the print server down for
    quite a while ?)

I would expect that you are getting this message on the console.
Does it say which file it had trouble reading ?
Is the file really gone ? 
Does it say what kind of error it got when trying to read it ?
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 21:19:00 GMT
From:      0002544290@MCIMAIL.COM (Electronic Mail Association)
To:        comp.protocols.tcp-ip
Subject:   ELECTRONIC MESSAGING '90


Marshall Rose suggested I send this to you for posting to all users. 
I hope this is of general interest to the group. Thank you!

* * * * * * *



ELECTRONIC MESSAGING '90:
    BEYOND INTERPERSONAL CORRESPONDENCE 

WHEN: October 22-24, 1990

WHERE: The Fairmont Hotel, San Francisco, Ca.

SPONSORED BY: The Electronic Mail Association

The Electronic Mail Association's annual conference expands to three days
for 1990. An exciting program that includes more than twice as many
speakers as ever before will examine such diverse topics as:

  o  Corporate Messaging Strategies
  o  End-User Training                
  o  Messaging Integration With EDI & FAX
  o  X.500 Directories
  o  CCITT Update
  o  LAN User Issues
  o  Gateways & Connectivity
  o  Groupware
  o  Portable Messaging
  o  Global Trends

John A. Young, President & Chief Executive Officer of Hewlett-Packard,
will deliver the keynote address.

Special new features at "Electronic Messaging '90:  Beyond Interpersonal
Correspondence" include a focused user/vendor discussion of upcoming
industry trends, led by EMA chairman Rich Miller, and a  Sunday night 
pre-conference user-to-user briefing on messaging terminology 
for those new to the industry.

*** CONFERENCE SPEAKERS *** 

Below is a partial list of confirmed speakers for Electronic Messaging '90: 

John A. Young, President & CEO, Hewlett-Packard
Hellene S. Runtagh, President, GE Information Services
Jose A. Collazo, Chairman & President, Infonet
Richard H. Miller, President, Rapport Communication, Inc. & Chairman, EMA
Peter W. Donaghy, Customer Service & Support Manager, Hughes Aircraft Co.
Michael D. Zisman, President, Soft Switch, Inc.
Donald M. Gilbert, Information Services Director, American Petroleum Institute
Kenneth Hutcheson, EDI Director, E.I. DuPont de Nemours & Chairman, X12
Richard Norris, Practice Leader for Logistics, Arthur D. Little, Inc.
Jeanne P. Bracken, Message Handling Systems Director, Pacific Bell
Donald Ryan, Vice President of ICS, BIS CAP International
Robert Johansen, Senior Research Fellow, Institute for the Future
Gursharan Sidhu, Technical Director, Apple Computer, Inc.
 
*** SCHEDULE OF EVENTS ***

MONDAY, OCTOBER 22

Plenary Panel Sessions:

Industry Trends & Perspectives
Business Case for Corporate Messaging Strategies

Luncheon

EDI & Messaging Integration Trends
User Perspectives on Messaging Trends


TUESDAY, OCTOBER 23

Keynote Address by John A. Young

Concurrent Panel Sessions:

Marketing Electronic Mail Inside the Corporation
Directories
End-User Training & Support
CCITT Update

Luncheon

Concurrent Panel Sessions:

IBM Messaging Update
Integration & Applied Messaging
Groupware
DEC Messaging Update
Integrating Information Services & Messaging
Portable Messaging

WEDNESDAY, OCTOBER 24

Concurrent Panel Sessions:

LAN Messaging Trends
Privacy & Security
Gateways & Connectivity
LAN User Issues 
Legal Issues in Messaging & EDI
Global Trends
Policy & Regulatory Issues
User/Vendor Industry Discussion

Adjourn
1 p.m.
 

*** REGISTRATION INFORMATION ***

Conference Fees
Regular Conference Fee
$695 (If received by 8/31 ... $645)
Special EMA Member Fee
$495 (If received by 8/31 ... $445)

Pre-registration is required.

The special member fee applies to all employees of member organizations
attending Electronic Messaging '90, so your membership may pay for itself
through the conference fee discounts. Contact the association for more
information about joining EMA.

Early Bird Discount

Registrants who pay the conference fee in full by August 31 may deduct
$50 from the conference fee.

Cancellations

All cancellations will be subject to a $50 processing fee. The balance of the
conference fee will be refunded provided written notice of cancellation is
received by EMA no later than October 15.

Hotel Accommodations

Electronic Messaging '90 will be held at The Fairmont Hotel, San Francisco, Ca.
Rooms are available at the special conference rate of $135 single/$155 double
(Main Bldg. Interior), $155 single/$180 double (Main Bldg. Exterior), 
$205 single/$225 double (Tower City View), $245 single/$265 double 
(Tower Bay View). Register with the hotel directly at 415/772-5000 before 
September 21, 1990 to guarantee the above rates and availability. Please note
that you are with the Electronic Mail Association room block.

Airline Reservations

American Airlines is the official airline for Electronic Messaging '90. For the
convention rate, please contact (or have your travel agent contact) the
American Airlines convention desk at 1-800-433-1750 and ask for star
file number S04O04E.

TO REGISTER OR TO RECEIVE FURTHER INFORMATION

Electronic mail is the easiest way to register! Please message, fax or mail
registration information to EMA at the address below. Information should 
include:

Name (Full, Middle Initial, Last)
Title
Company
Address
City, State, Zip
Telephone Number
Fax Number
Electronic Mail Address
Method of Conference Fee Payment (Member or Nonmember)

Electronic Mail Association
1555 Wilson Boulevard
Suite 555
Arlington, VA 22209-2405
Tel: 703/522-7111
Fax: 703/528-4251

AT&T Mail:     !EMA
CompuServe:    70007,2377
Dialcom:       63:PRD003
EasyLink:      62886257  
Envoy 100:     EMA
GEnie:         EMA
INET:          ema.association
MCI Mail:      EMA/2544290
SprintMail:    [ema/associates]
                mail/usa
 
FOR A COMPLETE LIST OF SPEAKERS, CONTACT EMA ELECTRONICALLY.


* * * * * 

Please let me know if there will be any problem posting this. Thanks again!

Amy Louviere
Director, Marketing
EMA

.

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 90 22:20:33 GMT
From:      shelby!portia.stanford.edu!ack.Stanford.EDU!pst@decwrl.dec.com  (Paul Traina)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol
Gee, in our part of California, making the server would be pretty trivial:

#!/bin/sh
#
set `date`

case $2 in
	Apr|May|Jun|Jul|Aug|Sep|Oct)
		echo "The weather today is really nice."
		echo "Take the day off from work and go to the beach or"
		echo "go for a bike ride."
		;;
	Mar)
		echo "The weather is ok today, but it will probably rain."
		echo "Go home early so you don't get caught in an afternoon"
		echo "shower."
		;;
	Dec|Jan|Feb)
		echo "It's cloudy today and really cold.  Don't expect"
		echo "temperatures to get above 70."
		;;
	Nov)
		echo "It's ok today,  but a little too cold for the beach."
		;;
esac
--
I told the priest - don't count on any second coming.
God got his ass kicked the first time he came down here slumming.
He had the balls to come, the gall to die and then forgive us -
No, I don't wonder what he thought it would get us.	-- Prieboy
-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Jul 90 11:33:13 -0700
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.arc.nasa.gov>
To:        usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu  (Kent    England)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Serious Routing Problems

Kent, I'm a little confused here.  Line flapping should be fixed by
having hystersis in the up/down line protocol.  It's been our
experience that OSPF in our system reroutes completely after about 3 seconds 
on average after the dead link is detected.  OSPF has it's timers
set up in a way as to avoid link flap causing a lot of simultaneous 
LSP flooding, due to deliberate jitter in the timers (LSP's being flooded
from all the gateways connected to a down net).

As for link up/downs going on every few seconds, we haven't had
experience with that sort of situation, but in the case of a link
that flaps every couple of minutes, that seems to work fine.
Because link-state protocols flood the topology information, and then
the routers recompute the routing tables more or less in parallel,
convergence can happen very quickly, and you also can do without
the complicated holddowns and such needed to prevent route looping
in vector-distance protocols.   This should be true for any reasonably
well implemented link-state protocol.  It's just easy to do this
part right.  You can certainly screw up in other ways, but if
you want fast convergance, fast enough to avoid lining up hundreds
of user TCP connections against a wall and killing them in rapid
sucession, you really need to use a link-state protocol.  This is
one reason why noone has bothered to build a new vector distance
IGP in quite some time.  Even the new proprietary IGP's these days 
are link-state based...

BARRNET also runs OSPF now, and those guys can tell you more 
about how it's performance has been.  

					Thanks,
					   Milo

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Jul 90 23:55:51 GMT
From:      Mills@udel.edu
To:        Marcus Leech <usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bcars8!bnrgate!bcarh342!mleech@ucsd.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Network Temperature Protocol
Marcus,

I knew that, but my keyboard didn't. Halifax Radio is CFH, not CHU. Boy, did
may pals pile on for that goof.

Dave
-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Jul 90 07:27:18 -0400
From:      aloh@BBN.COM
To:        beach@ddnuvax.af.mil
Cc:        aloh@BBN.COM, khuber@BBN.COM, rng@BBN.COM, dhaskin@BBN.COM, jwojcik@BBN.COM, afddn.cmd@gunter-adam.af.mil, tcp-ip@nic.ddn.mil
Subject:   Re: [darrel beach: Those Milnet Mailbridges (clarification needed)]
Darryl,

>>> I've stepped all over your message containing Mailbridge questions,
>>> hoping to leave footprints that include the right answers:

    Date: Fri, 27 Jul 90 12:20:35 CDT
    From: darrel beach <beach@ddnuvax.af.mil>
    To: tcp-ip@nic.ddn.mil
    Cc: beach@ddnuvax.af.mil, afddn.cmd@gunter-adam.af.mil
    Subject: Those Milnet Mailbridges (clarification needed)
    
    ...about those Mail Bridges and the IGP they use, and how they use EGP...

     (The addresses are of course bogus.)

		   +----------------------------------+
		   |                                  |
     Mailbridge    |                                  |   Mailbridge
     MB1    -------+       Milnet                     +------ MB2
     26.10.0.100   |       26.0.0.0                   |    26.2.0.2
		   |                                  |
		   |                                  |
    Router G1      |                                  |      Router G2
    to      -------+                                  +------to 192.50.50.0
    192.25.25.0 on |                                  |      on 26.1.0.50
    26.1.0.25      +-----+-----------------------+----+
			 |                       |
			 |                       |
			 |                       |
		    Router R1                Router R2
		    Gateway to               Gateway to
		    131.2.0.0                128.5.0.0 on
		    26.2.0.131               26.5.0.128


Let's assume the following:

	  R1 has only MB1 as an EGP neighbor
	  G1 has only MB1 as an EGP neighbor

	  R2 has only MB2 as an EGP neighbor
	  G2 has only MB2 as an EGP neighbor

	  MB1 and MB2 are using the IGP currently being used by the
	  Milnet Mailbridges.

>>> The relevent IGP (internal gateway protocol) used in the Mailbridge
>>> Gateways' autonomous system is called "spread".  The "internal gateway"
>>> is a gateway in the same autonomous system".  All, and only Mailbridge
>>> gateways are in the same, core, autonomous system.  Therefore all,
>>> and only Mailbridge gateways are "internal gateways" relative to their
>>> autonomous system.  (Previously, the IGP used between the Mailbridges
>>> was "GGP".  The IGP used in any autonomous system is not specified,
>>> but instead, is a choice left to the administrators of each autonomous
>>> system.)
>>>
>>> The "spread" protocol uses the same mechanisms as EGP, (i.e. the same
>>> format for Network Reachability messages, also called Updates) but has
>>> different algorithms for performing the autonomous system function of
>>> a core system, than the algorithms used for exchanging network
>>> reachability information with EGP peers in other autonomous systems
>>> ("external gateways").

The questions:
      1.  Is the following correct?
	  Its my understanding that MB1 does not provide the direct Milnet
	  address for EGP neighbors in its IGP exchange to MB2.  This would
	  result in the following routing table for R1:

	  192.25.25.0 via 26.1.0.25  at 2 hops;
	  128.5.0.0   via 26.2.0.2   at 3 hops;
	  192.50.50.0 via 26.2.0.2   at 3 hops;

	  If my understanding of what's in the IGP packets is correct, then
	  the effect is obvious and leads to Mailbridge bashing when a direct
	  route is available.

>>> This is incorrect!  Because, the IGP does indeed select optimal routes.
>>>
>>> EGP does not specify algorithms for route selection.  The function
>>> to optimize route selection is implemented by the IGP of an autonmous
>>> system acting as a core system.  The implementation of a particular
>>> IGP is indeed critical to the resulting route selection, and should
>>> not produce the (non-optimal!) results hypothesized above.
>>>
>>> In the Butterfly Mailbridge Gateways, the current implementation
>>> applies algorithms to both incoming (received) reachability
>>> information and on reachability information being transmitted.
>>> The purpose of these algorithms is to select optimal routes,
>>> which, in fact, is the point of applying the "autonomous system" 
>>> concept, to the "core system" concept.  (Some of these algorithms
>>> will be discussed in answer to the next question.)
>>>
>>> The routing selection results hypothesized in the question are known
>>> in the literature as the "extra hop problem".  This problem is
>>> is conceptually solved by the IGP in the autonomous system acting
>>> as a core system.  The IGP selects optimal routes and also supports
>>> consistent and complete network reachability information in each
>>> gateway in the core autonomous sytem.
>>>
>>> The reachability information received in EGP NR Updates is distributed
>>> within the core autonomous system gateways (between the Mailbridges only)
>>> by the autonomous system's IGP ("spread").  The same information, if
>>> received in EGP NR Updates, for indirect neighbors, is distributed in
>>> "spread" updates.  And, information received in "spread" updates is
>>> the same  information included in EGP NR Updates sent to external gateways
>>> ("acquired" EGP peers).  (I have used the words "reachability
>>> information" instead of "route" because the concepts of "hop count" and
>>> "distance" are associated with "route".)
>>>
>>> The reachability information used to build R1's routing table is:
>>>
>>> 192.25.25.0 via 26.1.0.25  at distance 0
>>> 128.5.0.0   via 26.5.0.128 at distance 0
>>> 192.50.50.0 via 26.1.0.50  at distance 0
>>>
>>> Note that what is commonly referred to as the "hop count" of a route
>>> is the "distance" associated with each "neighbor, net" pair
>>> contained in NR updates.  In fact, this "distance" is specified as a
>>> "metric whose definition is left to the designers of the autonomous
>>> system" (RFC 888) or "numbers depending on autonomous system
>>> architecture" (RFC 904).  The distance values in NR updates can
>>> only be compared with values from the same autonomous sytem.
>>> Distance values from different autonomous systems cannot be
>>> used as routing metrics.  It is actually misleading to interpret
>>> "distance" as a hop count.

      2.  The real question is yet to come and is moot if I'm wrong about 1.

	  Let's change the neighboring of R1 to use both MB1 and MB2.  Let's
	  also say that R1 use a 10 minute poll and one mailbridge is polled
	  every 5 minutes, i.e. the polling is 180 degrees out of phase, wit
	  MB1 getting polled first.  After the first update R1's routing
	  table would be as follows:

	  192.25.25.0 via 26.1.0.25  at 1 hops;
	  128.5.0.0   via 26.2.0.2   at 2 hops;
	  192.50.50.0 via 26.2.0.2   at 2 hops;

	  When the update from MB2 was received, it would include the
	  following infomation:

	  192.25.25.0 via 26.1.0.25  at 1 hops;
	  128.5.0.0   via 26.5.0.128 at 1 hops;
	  192.50.50.0 via 26.1.0.50  at 1 hops;

	  So, would R1 now overwrite the existing routes with the new ones,
	  or maintain both routes and use the lowest hopcount??

	  And the real question is what do various implementations do under
	  such conditions???  If the routes get overwritten, which seems
	  logical to me, then you have a table that changes with every
	  update.  If you keep old routes when they're better than new ones,
	  you could never be sure the better route was still available.  I
	  guess there are several philosophies for handling this situation,
	  and I'd really like to know which is implemented by whom.

>>> Note that EGP doesn't address the problem of route selection.
>>> Rather, EGP specifies how to exchange topological information: network
>>> reachability.  And, EGP information is only useful in a topology which
>>> is a tree (has no cycles).  This is because EGP does not specify
>>> how to prevent loops in the routing tables which the information is
>>> used to construct.
>>>
>>> The concept of a core system is to compromise on the question of where
>>> to store network reachability information (i.e. complete information in
>>> each reachable gateway vs. complete information in only one central
>>> gateway).  The core system is a set of multiple gateways, which is a
>>> subset of all gateways.  Each gateway in the core system contains
>>> complete network reachability information.
>>>
>>> The concept of an autonomous system provides for an IGP to maintain
>>> consistent and complete information within all the core system gateways,
>>> and to select optimal routes.
>>>
>>> EGP distinguishes between routes classified as "internal" (first hop
>>> through another gateway in this autonomous system (which,
>>> by definition is another Mailbridge); and "external" (first
>>> hop through a gateway in another autonomous system).
>>>
>>> The routes under discussion are all considered "external".
>>> The distinctive quality of a core system is that only gateways
>>> in a core system include routes through external gateways
>>> in their EGP Network Reachability Updates.
>>>
>>> Furthermore, EGP NR Updates (Network Reachability Updates), transmitted
>>> by a Mailbridge, are customized for each EGP peer.  The classic example
>>> is the requirement that routing information for networks reached
>>> through a first hop to a particular EGP peer is not sent back to that
>>> peer!
>>>
>>> This requirement prevents Mailbridge "M", which has a 4 hop route
>>> to net "X" through (first hop) gateway "A" from sending an NR Update
>>> to "A" which contains a 5 hop route to network "X" with first hop
>>> through Mailbridge "M".
>>>
>>> In the literature, this problem is called the "count to infinity",
>>> which occurs once "A" actually loses its original route (i.e.
>>> through loss of the hardware link to the next hop to network "X").
>>>
>>> Without this requirement (known as "split horizon"), when network "X"
>>> is no longer reachable through "A", the NR Update from "M" to "A" could
>>> contain a route to "X" through "M".  Then "A", also operating without
>>> "split horizon", could justifiably add 1 to the hop count and send a
>>> route to "X" through "A", back to "M".  A bogus route to "X" could
>>> therefore continue to be transmitted back and forth between "M" and "A",
>>> increasing one hop in each NR Update, until "M" or "A" decide that the
>>> distance has been incremented to "infinity".
>>>
>>> Note the misleading use of "hop count" and "distance" in this discussion
>>> of "count to infinity" and "split horizon"!  It follows the
>>> presentation of the problem and solution from the literature.
>>>
>>> Given the implementation of "split horizon", it is only reasonable
>>> to assume that other algorithms are applied.  In fact, one such
>>> requirement of the core system is that at any one time, only one route
>>> to a network is effective.  Periodically, the aggregate information
>>> received from EGP peers (direct neighbors) is reprocessed,
>>> to select the shortest route to each network, from among all routes
>>> to that network, received from all the EGP peers.  Such information,
>>> of course may time out, and the information is discarded once
>>> its lifetime has expired.  Therefore, periodically, the set of
>>> unique, optimal routes to each network may change!
>>>
>>> A particular EGP implementation is most effective if changes to
>>> routing tables (which may also be used to construct NR Updates!)
>>> only reflect changes to more optimal routes, and not simply
>>> arbitrary changes (i.e. most recently received routes).
>>>
>>> I chose a couple of random hosts registered on nic.ddn.mil,
>>> and queried the Mailbridge at 26.1.0.49, for routes to their
>>> nets.  Here are the results:
>>>
>>> net 128.63.0.0 via 26.3.0.29  distance 0
>>> net 129.49.0.0 via 26.20.0.16 distance 21
>>> 
>>> The gateway 26.30.0.29 is not a Mailbridge, it is a Milnet "stub"
>>> gateway.  The gateway 26.20.0.16 is the Mailbridge at NASA Ames
>>> Research Center.
>>>
>>> Note that one cannot distinguish between an "external"
>>> route such as 128.63.0.0 (i.e. slim.brl.mil) or an "internal"
>>> route such as 129.49.0.0 (i.e. krill.nosc.mil), from the IP
>>> net address.  Nor does the IP net address distinguish if the first
>>> hop to the net is through a direct neighbor ("acquired" EGP peer), or
>>> through an indirect neighbor (a neighbor which is listed as a first hop
>>> to some set of nets, in an EGP NR Update from a direct neighbor).
>>>
>>> Recall that EGP is performed between exterior neighbors (gateways
>>> in different autonomous systems).  The distinction between a
>>> direct (exterior) neighbor and an indirect neighbor is that a direct
>>> neighbor is an EGP peer, while an indirect neighbor is not an EGP peer,
>>> but is listed in the NR Update from a direct neighbor.  For a
>>> Mailbridge (in the core system!) a both direct and indirect neighbors
>>> are always exterior gateways.  For a gateway in a non-core autonomous
>>> system, an indirect neighbor may be an interior gateway (relative to
>>> the non-core autonomous system) or it may be an exterior gateway.
>>>
>>> It is dangerous to generalize from random observation of routes
>>> from Mailbridges!  It is easy to draw an incorrect conclusion if
>>> all the cases (indirect/direct/interior/exterior) are not observed!

Darrel Beach
....still only an egg after all this time

>>> ....You are hereby graduated to hatchling class, if I haven't
>>>     told you too many lies!
>>>
>>>                                         Tony Loh, aloh@bbn.com
-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 01:18:28 GMT
From:      att!cbnewsd!login@ucbvax.Berkeley.EDU  (h.reza.zarafshar)
To:        tcp-ip@nic.ddn.mil
Subject:   Ethernet board performance with TCP/IP on PC?

I am looking for a very high performance ethernet board that would go into
a 386/PC running AT&T UNIX/386 or some flavor there of.  I will be using
TCP/IP.  I can use either dumb or inteligent boards.  So far, I have not
found a good combination.  While the ones I have tried work, they do lack
performance. If any one has tried a successful and high performance combination,
I would appreicate it if you could tell me about your experience.  

Also, I have heard of this company called FTP supposedly located in Boston
that sells TCP/IP drivers for UNIX.  Does anyone know of them?  Has anyone
tried their product?

Since I don't normally read these newsgroups, I would appreciate it if you
would reply via e-mail to:

Reza Zarafshar,
att!iexist!reza
(708)979-8855
-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 01:36:00 GMT
From:      gaf@uucs1.UUCP (gaf)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Books on RPC programming?


I'm rather a novice at this remote procedure call stuff (Sun RPC variety),
and am looking for reference material.

The documentation which comes from our vendor(s) covers the basics well
enough to get some simple-minded applications going, but I'd like to
streamline them a bit.  For example, where I'm currently returning fixed-size
arrays back to the client, I'd rather return a variable-length array,
with variable length strings in it.  The docs I have don't get into this
sort of thing, nor into the mysteries of passing lists & trees (pointers)
between server and client.

The bookstores around here don't have any titles on the subject, so I'm
looking for some pointers to reading material from you old pros
(emphasis on "pro", not "old").

-- 
Guy Finney					It's that feeling of deja-vu
UUCS inc.   Phoenix, Az				all over again.
ncar!noao!asuvax!hrc!uucs1!gaf	sun!sunburn!gtx!uucs1!gaf

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Jul 90 09:28:35 PDT
From:      postel@venera.isi.edu
To:        tcp-ip@nic.ddn.mil, usc!zaphod.mps.ohio-state.edu!mips!ultra!rajiv@ucsd.edu
Cc:        jkrey@venera.isi.edu
Subject:   Re:  ARP hardware address space values


These numbers are assigned by the Internet Assigned Numbers Authority (IANA).
Semd email to IANA@ISI.EDU.  See page 46 of RFC-1060 for the current list.

--jon.
-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Jul 90 5:06:06 GMT
From:      Mills@udel.edu
To:        Jim Olsen <artemis.ll.mit.edu!olsen@xn.ll.mit.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Network Temperature Protocol
Jim,

Would be only that WBR70 continued its venerable broadcasts; but alas, Miami
Radio has faded into the past. However, intrepid squirrels will discover
yet a few 50-bps Baudot-coded WMO broadcasts from various European
countries and also the interesting air-america types from Middle America.
Gentleman, man your shortwave receivers.

Dave
-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Jul 90 11:19:08 EST
From:      Scott W. Rogers <rogers@osi540sn.gsfc.nasa.gov>
To:        tcp-ip@nic.ddn.mil
Subject:   Internet Access in Dallas, TX.

I am looking for an internet access point in or near Dallas, TX,
hopefully one on an NSFnet regional network capable of supporting
T1 access.  This connection would be required for one week to support
the 1991 UNIFORUM conference.  If anyone as any information, please
send mail to me directly at:

			Internet:	rogers@osi540sn.gsfc.nasa.gov
			UUNET:		uunet!osi540sn.gsfc.nasa.gov!rogers
			AT&T:  		(301) 572-8297

Thanks in advance.
-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Jul 1990 15:50:14 PDT
From:      Ken Harrenstien <klh@NISC.SRI.COM>
To:        Electronic Mail Association <0002544290@mcimail.com>
Cc:        klh@NISC.SRI.COM, tcp-ip@nic.ddn.mil
Subject:   Re: ELECTRONIC MESSAGING '90
It is no doubt meaningful that the interesting list of e-mail addresses
does not include an Internet address.
-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 09:34:55 GMT
From:      eru!luth!sunic!mcsun!piet@bloom-beacon.mit.edu  (Piet Beertema)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: whois Database

	Has anyone else created whois databases?
Yes: in Europe there is a body called "RIPE" for coordinating
IP networking in Europe. Amongst other things it has collected
information about IP networks, domains, etc.
The information is available via "whois -h NIC.EU.net".

	What machines?
The database resides on a SUN-4/280.
-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Jul 90 17:49:54 -0400
From:      bzs@world.std.com (Barry Shein)
To:        mcsun!ukc!tcdcs!swift.cs.tcd.ie!ul.ie!bourkej@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Spare some advice for an old ex-lepper

>Can anyone offer some words of wisdom from their expereinces, or, if you were
>to start from scratch, what would you do different ?

I'd have gone into poetics and put all my money into federal express
at $4.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 13:14:14 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: was: the BSD lpd protocol? Stevens' Book


 >Quarterman, John S., The Design and Implementation of the 4.3BSD UNIX
 >Operating System, Addison-Wesley, Reading, MA, 1989, ISBN 0-201-06196-1.
 
 >Bach, M.J., The Design of the UNIX Operating System, Prentice-Hall,
 >Englewood Cliffs, NJ, 1986.

 John,

useful references, i agree; i meant its a shame there isnt anything of
the level of detail of stevens' book for kernel work (i.e. Comer's
xinu, Tanenbaum's minix,  the old Lions version 6 unix text...level of
detail and annotated source; perhaps a book on Amoeba or MACH would be
instructive in OS and Comms terms, but i meant something useful for
the profssional programmer right now) 

 >>the structure is very similar to a course i teach on comms. software,
 >>and i think i'm gonna recommend it as a base text....
 
 >Case in point....

 the course i teach is a UK university course, and therefore *free* to
uk people who meet the entry requirements...

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 13:48:15 GMT
From:      uoft02.utoledo.edu!desire!anagram@tut.cis.ohio-state.edu  ('ANAGRAM')
To:        tcp-ip@nic.ddn.mil
Subject:   Reviews of CMU-Tek TCP/IP, please

I am looking for reviews of some of the more recent CMU-Tek TCP/IP packages. 
My company is interested in purchasing the software, but are a little leary
ofbuying such an inexpensive package (ever heard the saying you get what you
pay?).  I have tried local sources, but have either not been able to contact
them, or they no longer use it due to upgrades.  So, what can people tell me?

Thanks
Stephen P Potter
ANAGRAM@desire.wright.edu
-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 14:56:56 GMT
From:      mcsun!ukc!axion!vision!ukpoit!ukpoit.co.uk!ian@uunet.uu.net  (Ian J Spare)
To:        tcp-ip@nic.ddn.mil
Subject:   WIN/TCP Sessions Hanging
I have observed a problem ( or quirk :-) ) with our WIN/TCP and I would like to 
know if others see it as well. We have WIN rel 4.0.0.2 and NCR Tower 400 and
500's under REL 3.

Basically when an rlogin or telnet drops whether from line loss ( often caused 
by my Epsom PCe locking up ) or user request ( ie. on our annex terminal server)
the remote processes on the host remain. On UNIX this means after a time a 
number of phantom users with entries in utmp showing up and a number of shells
etc hanging around. From a sys adm point of view this is a nightmare, I can't 
tell if the users are logged in or where physically to look for the sessions.

DO YOU SEE THIS ????

Have you any tips/insights ???

Thanks

Ian

------------------------------------------------------------------------------
  Ian Spare                         |
  iT                                |        E-mail : ian@ukpoit.uucp
  Barker Lane                       |        BANG-STYLE : ......!ukc!ukpoit!ian
  CHESTERFIELD S40 1DY              |        VOICE : +44 246 214274
  Derbys, England                   |        FAX   : +44 246 214353
--------------------------------------------------------------------------------
      iT - The Information Technology Business Of The Post Office
-----------------------  In Tune With Technology -------------------------------
-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Jul 90 14:14:14 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        "John S. Quarterman" <jsq@tic.com>
Cc:        TCP-IP@nic.ddn.mil
Subject:   Re: was: the BSD lpd protocol? Stevens' Book

 >Quarterman, John S., The Design and Implementation of the 4.3BSD UNIX
 >Operating System, Addison-Wesley, Reading, MA, 1989, ISBN 0-201-06196-1.

 >Bach, M.J., The Design of the UNIX Operating System, Prentice-Hall,
 >Englewood Cliffs, NJ, 1986.

 John,

useful references, i agree; i meant its a shame there isnt anything of
the level of detail of stevens' book for kernel work (i.e. Comer's
xinu, Tanenbaum's minix,  the old Lions version 6 unix text...level of
detail and annotated source; perhaps a book on Amoeba or MACH would be
instructive in OS and Comms terms, but i meant something useful for
the profssional programmer right now) 

 >>the structure is very similar to a course i teach on comms. software,
 >>and i think i'm gonna recommend it as a base text....

 >Case in point....

 the course i teach is a UK university course, and therefore *free* to
uk people who meet the entry requirements...

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 16:06:36 GMT
From:      kevin@gtisqr (Kevin Bagley)
To:        comp.sys.mac.comm,comp.protocols.appletalk,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP-IP->DOS->EtherTalk->LaserWriter?



O.K., I'm not giving up.... yet.

Recently, I posted a request for information regarding printing from
386 machines running Interactive Unix over a TCP/IP network to a
Mac SE with Ethernet card to a Laserwriter connected via LocalTalk.

The responses I have received indicated we need to purchace a Gateway
such as the Shiva Fast Path, or the Cayman GatorBox, etc..  Naturally,
I am looking for alternatives since these devices are priced from $1500
to more than $2500.  My company doesn't want to pay those kind of prices.

I understand that EtherTalk and AppleTalk are available on DOS machines.
Is there a device/software that will convert TCP/IP into EtherTalk or
AppleTalk at the DOS machine level?  Would it be possible to make this
'back door' route function enough to print a file from one of the Unix
boxes to the Laserwriter?  How?

What about going the other direction?  Could we hang the Laserwriter off
of one of the Unix boxes with a serial line and print from the Mac to a
DOS machnine an then to a Unix box, and finally, to the Laserwriter?

Any help you have to offer will be greatly appreciated.

-- 
 _____  Kevin Bagley   Global Tech. Int'l Inc., Mukilteo WA 98275  206-742-9111
  )___)  _    _   _    UUCP: {smart-host}!gtisqr!kevin
_/___)  (_(__(_)_/_)_  "yisdersomenimororsesassesdenderisorses" (Mo's@Newport)
______________/        Disclaimer: "I did not say this. I am not here." (Dune)

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 16:24:04 GMT
From:      philmtl!atha!aupair.cs.athabascau.ca!lyndon@uunet.uu.net  (Lyndon Nerenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Is there a spec for "uucp-path 117/tcp" ?
Several of our machines list the service "uucp-path" on tcp port 117.
Does anyone have a reference describing what this service does?


-- 
     Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
         {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca
                           Practice Safe Government
                                 Use Kingdoms
-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 17:23:21 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: WIN/TCP 5.1 error...
My original reply to this bounced today, so I'll post instead:

In article <28900@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes:
>I am getting a mystifying error (mystifying because there's nothing in
>the docs about it) from WIN/TCP on my uVAX II.
>%LPDSMB-F-FILEREAD,
>What is happening? What should I check?

This is telling you that your lpd deamon can't read some file.  A
short chat with the author of lpr/lpd for win/tcp reveals that this
error is usually caused by the spool directory having the wrong
protections.  These directories should be readable and writable by the
[LPD] account, but no other accounts (to avoid security holes) should
be able to write to these directories.  See the appendix of the System
Admin guide for more details.

In article <1990Jul30.203106.22496@spectrum.CMC.COM>
lars@spectrum.CMC.COM (Lars Poulsen) writes: 
>Decoding the message identifier according to normal rules says that
>a component called LPDSMB (probably a print symbiont which is a client
>for the Berkeley Line Printer Daemon; i.e. talking to a remote print
>queue over the network) had a FILEREAD error.

Yes, it is a LPR/LPD protocol speaker for VMS.  LPD.EXE (the part of
the system that worries about talking lpr/lpd to neighbors) runs
effectively as SYSTEM.  It can put files into the queue with no
problems.  However LPDSMB runs as LPD so there can be a few protection
problems if the both the ownership of the spool directory (specified
with the /SPOOL_DIR=xxxx qualifier in the
TWG$TCP:[NETDIST.ETC]PRINTCAP file) isn't [LPD].  When setting the
ownership of a spool directory that may have files in it, you will
want to also set the ownerships of the files in that directory as
well.

Warner

--
Warner Losh		imp@Solbourne.COM
-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 18:53:09 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ports 1000-1023 reserved?
In article <9007301547.AA19807@ucbvax.Berkeley.EDU>, DBARTON@IBM.COM writes:

> TCP/IP Version 2 for VM will start allocating ports at port number 1024,
> to prevent this problem with the Hewlett Packard product.  Ports
> 1000-1023 are not restricted, and I am surprised that Hewlett Packard
> does not have problems interoperating with other TCP/IP products than
> VM.
 
I beg to differ. Please check RFC-1060 in the section "UNIX PORTS".

   By convention, ports in the range 256 to 1024 are used for "Unix
   Standard" services. 

This is "by convention", but in IP-land "by convention" is what is really done.
So HP has no problem with the vast majority of implementations since the
authors knew that all addresses up to 1024 were reserved. Only those designed
in strict compliance with the specs are going to have problems. And I doubt if
any implementation has ever worked by designing to the spec.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 19:51:51 GMT
From:      excelan!donp@ames.arc.nasa.gov  (don provan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ports 1000-1023 reserved?
In article <1990Jul31.115309.1@rogue.llnl.gov> oberman@rogue.llnl.gov writes:
>In article <9007301547.AA19807@ucbvax.Berkeley.EDU>, DBARTON@IBM.COM writes:
>
>> TCP/IP Version 2 for VM will start allocating ports at port number 1024,
>> to prevent this problem with the Hewlett Packard product.
> 
>I beg to differ. Please check RFC-1060 in the section "UNIX PORTS".
>
>   By convention, ports in the range 256 to 1024 are used for "Unix
>   Standard" services. 

OK, this discussion has gotten out of hand and i'm afraid some
innocent novice it going to believe some of this misinformation.

While it is true that ports lower than 1024 are reserved on many
systems, that has nothing whatsoever to do with the HP bug that's being
discussed here.  The port given in the FTP PORT command is a *remote*
port.  There's no justification at all for HP checking this port for
any range of any type for any reason.  It should just use the port
given.  I don't even understand what prompted some misguided soul to
add the extra, unnecessary code needed to make this check.

I applaud the IBM developers for making this simple change to
accommodate the HP implementation, but i want everyone to understand
that the HP implementation is, in fact, broken.
							don provan
							donp@novell.com
-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 20:10:37 GMT
From:      media-lab!snorkelwacker!spdcc!mirror!necntc!necis!adamm@EDDIE.MIT.EDU  (Adam S. Moskowitz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump on 4.3 Reno?
In article <16330@ucsd.Edu>, brian@ucsd.Edu (Brian Kantor) wrote:
} In article <9007271758.AA13923@ucbvax.Berkeley.EDU>
J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
}} btw. 'scuse my ignorance, but what is the origin of the 'tahoe', 'reno'
}} naming scheme - is't simply placenames?
} 
} "Tahoe' was the model name of the CCI system that they had to port the
} 4.3 system to . . .

True enough.

} I'm told that the newer one is called 'Reno' because running it is 
} taking a real gamble.  Snicker.

The story, as I heard it from the nameless gradual student who claims to have
though of the name "4.3-Reno" (and a slightly inebriated but reliable BSD
hacker verified this), was that it's all a joke. Reno is the next town north
of Tahoe on I-80 hence the name.

Reveal my sources? Never! Could I be wrong? Sure - I was slightly inebriated
at the time the story was told to me. :-)

AdamM
-- 
What are you going to do if you're all plowed and too wet | Adam S. Moskowitz
to dance?                                                 | adamm@necis.nec.com
                                                          | ...!uunet!harvard!\
(nobody)                                                  |  necntc!necis!adamm
-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 90 21:06:58 GMT
From:      pacbell.com!tandem!mytardis!jb@ucsd.edu  (John Bartas)
To:        tcp-ip@nic.ddn.mil
Subject:   Software assigned Ethernet Addresses

I lost the posting from the fellow who was going to build an ethernet
board without an address prom and assign the address via software,
but I once worked for a company that was going to do the same thing. 

Although they didn't find anything in the spec saying NOT to do it, I
was uneasy about the fact that although it seemed an obvious way of
reducing parts and cutting mfg costs, no one else that I knew of did
it. We even prototyped some boards and had them working in our labs
with commercial net protocols. Hand assigning unique ethernet numbers
to each board we brought up was a pain, but is was doable.

We gave up on the idea when we thought about booting via the net. We 
needed an address to start to boot, but we needed to be booted for software
to assign an address. Chicken and Egg. There were other problems too, 
but I left all my notes at the company and don't recall details. You
didn't mention what your machine was for, so maybe none of this applies
to you.

-JB-

-----------------------------------------------------------------------
    John Bartas      |   This space for rent.   
  NetPort Software   |

END OF DOCUMENT