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 August 1990 (420 messages, 236876 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/08.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 01:34:36 GMT
From:      twg.com!david@princeton.edu  (David S. Herron)
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:
>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)

>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.

There's a fairly inexpensive box available for Amiga which encodes and
decodes the transmission formats used to send pictures from satellites,
and used by the wire services on shortwave-TELEX.  One of these hooked
to an Amiga sitting on ether (ether has been available for years, along
with TCP/IP & NFS) could grab current weather maps from satellite
and make them available over NFS.  Then when Craig gets one of his
fantasies again his software can just get the picture from wherever
it was stashed by the Amiga.

No need to buy the data from Alden either..
-- 
<- David Herron, an MMDF weenie, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 01:35:02 GMT
From:      bellcore-2!envy!karn@rutgers.edu  (Phil R. Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   re: Are Commercial TCPs Berkeley Code Or Custom?

In article <9007272321.AA09325@asylum.sf.ca.us>, romkey@asylum.sf.ca.us
(John Romkey) writes:
|> Phil Karn rolled his own [TCP] in KA9Q (he'll correct
|> me if I'm wrong).

True. My TCP was written from scratch starting in late 1985. Its first
platform, believe it or not, was the Xerox 820, a 64K CPM Z-80 system.
It moved fairly quickly to the PC after that. In the next several
years various refinements such as the Van Jacobson mods were added. It
is fairly stable now, although I recently improved the slow-start code.

My TCP is probably the only one that was written essentially on a
dare. In 1985 the amateur packet radio community was swept by a raging
protocol war that would bring smiles of recognition to this group.  In
one camp were the connection-oriented ISO/CCITT/X.25 lackeys, and in
the other were the Internet TCP/IP people, the only ones who knew what
they were doing (nah, I'm not biased :-)). One of the more rabid
members of the opposing camp stridently argued that TCP was so
incredibly complicated that I could NEVER cram it into anything less
than a full-blown VAX, to say nothing of personal computer hardware
that could be afforded by the average radio ham.

Not one to be told I couldn't do something, I sat down with RFC-793
and started coding.  I had it limping along in a month or two, in time
to show at the ARRL Computer Networking Conference in February 1986.
However, the whole project quickly got into my blood, and over 5 years
later I'm still at it. And the guy who had originally challenged me has
still not conceded defeat.

I *strongly* agree that you can't write a good TCP in a vacuum.  Much
of my early testing took place over a SLIP link which revealed some,
uh, gaps in RFC-793's wisdom on round trip timing algorithms.  Our
CSNET/X.25Net connection to ARPANET at the time was marvelous for
stress testing my IP reassembly and TCP retransmission and
resequencing code. And running on a slow, memory starved machine gave
one a strong incentive to write tight code...

Phil
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Wed, 01 Aug 90 10:58:00 -0400
From:      barns@gateway.mitre.org
To:        tcp-ip@nic.ddn.mil
Cc:        barns@gateway.mitre.org
Subject:   Re: IBM/HP-UX FTP session hangs on PORT command
I'm concerned that the replies I've seem posted didn't talk about the
difference between local ports and remote ports.

Any system can have whatever notion of reserved local ports that it cares
to adopt.  It should not be necessary, and in my opinion it is wrong, for
one system (call it A) to know or care about the reserved ports, if any,
of some other system (call it B).  It isn't very convenient for me to test
it, but I think that a vanilla BSD UNIX behaves as I describe, i.e., will
let any of its users connect to port 1000 of a remote host, but won't let
a user use local port 1000 without having the requisite privilege.

When system A sends an FTP PORT command to the server on system B, the
port number mentioned is a port number on system A.  System B ought to
believe whatever system A asserts about port numbers on system A, even
if that port number is used differently on system B or elsewhere.  It's the
responsibility of system A to pick a reasonable port number (for example,
system A shouldn't choose the port number used by a server that
system A supports).  But if system A thinks that 1000 is a reasonable
port number, system B should be willing to talk to system A's port 1000.

Note that FTP PASV also handles the ports this way.  When system A
sends a PASV command to system B, system B responds with a port number
on system B, chosen by system B according to whatever local rules
apply there.  System A doesn't need to know why system B made whatever
choice it made.  System A should just connect to the port on system B
that system B chose.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 05:40:34 GMT
From:      sdd.hp.com!samsung!munnari.oz.au!mtiame!ubeaut!mwp@ucsd.edu  (Michael Paddon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are Commercial TCPs Berkeley Code Or Custom?
From article <32140@cup.portal.com>, by Will@cup.portal.com (Will E Estes):
> 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....)

The Berkeley code is not public domain; it is copyrighted by the
Regents of the University of California. However, the BSD code *is*
freely available as source. Obviously you can't sell it, but you can
sell any modifications you make to it.

A fair amount of the socket layer is missing from the BSD distribution
because there is AT&T code embedded in it.

From what I've seen of the Exelan and Wollongong IP implementations,
much has been borrowed from the BSD code, so it is likely that they
are both based on it originally.



As for how easy it is to port... I've been doing this for the last six
months, on and off, onto NCR towers under System V.

We rewrote the socket interface as a library/driver combination,
pulled out unix domain sockets and the NS protocols and hacked select
severely. The SLIP driver needed a complete reworking because it is far
too BSD dependent. The mbuf code required extensive thought.
Inetd, syslogd, rsh, rcp and other utilities needed to be hacked.

Another problem was that the BSD code is not bug free. Has anybody
noticed how in_losing() interacts with SLIP?

Getting all that working was about 2-3 man months worth of effort.
Since then, we've been porting to the 850 multiprocessor tower. This
is much more difficult because the BSD code never (and could never)
be designed with that architecture in mind.

In summary, porting IP from BSD sources is straightforward but not
trivial. 

					Michael

-------------------------------------------------------------------
|                     |     EasyNet:  meo78b::paddon              |
|                     |     Internet: paddon@meo78b.enet.dec.com  |
|  Michael Paddon     |     ACSnet:   mwp@ubeaut.oz.au            |
|                     |     ACSnet:   mwp@munnari.oz.au           |
|                     |     Voice:    +61 3 895 9392              |
-------------------------------------------------------------------
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 09:22:41 GMT
From:      mcsun!unido!tub!fauern!tumuc!guug!rup@uunet.uu.net  (Rupert Grafendorfer)
To:        tcp-ip@nic.ddn.mil
Subject:   DECNET Boot-protocol for DOS-machines

Hiho.
Does anybody know where I can get the specs for the DECNET Boot-protocol?
Thanx.
-rup
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 09:24:44 GMT
From:      uhccux!querubin@ames.arc.nasa.gov  (Antonio Querubin)
To:        tcp-ip@nic.ddn.mil
Subject:   Proxy RIP???
This may seem like an oddball question but perhaps other people have run into
similar situations:

We have a VAX with two ethernet boards running Fusion's Networking System (FNS).
After receiving some replies on the net and some calls to FUSION,
we think we have it finally setup to route between our campus backbone and our
subnet.  Unfortunately, FNS doesn't know RIP and so packets can't find their
way to our subnet without hard-coding a route into one of the gateways on the
backbone (which our network administrators have resisted doing for good reason).
We do however have a PC on the subnet running KA9Q which does understand and
send RIP packets.  Is there some way of having KA9Q do something like a 
'proxy RIP' for the VAX so that the campus network knows that the VAX is a 
gateway for our subnet?

Specifics:  the campus backbone has a subnet of 128.171.1.0, the VAX's 
addresses are 128.171.1.99 and 128.171.11.2, our subnet is 128.171.11.0, and
the PC has an address of 128.171.11.16.

After going through the RIP RFC, it seems that a host is to interpret a RIP
message as routes through the originating host to another host or network.
Suppose on the PC I have in the autoexec.net file for KA9Q:
route add default lan 128.171.11.2
route add [128.171.11.0]/24 lan
(where 'lan' is the ethernet port).

If I send out RIP broadcasts to 128.171.1.255 from the PC, the VAX should
pick it up and route it to the backbone through it's 128.171.1.99 port.  But
will the backbone hosts interpret that as a route through 128.171.1.99 or as
a route through 128.171.11.16?  My understanding of the RFC indicates the 
latter case is correct and therefore probably confuses the gateways since 
they're expecting to see a subnet of 1 instead of 11 on that segment.  Am I
correct on this and therefore can't do what I want to do OR is there perhaps
some other standard way of doing this?  Is it possible for example to have
FNS do a proxy ARP for the entire subnet?
Seems like the gateways still wouldn't know which ports to send packets out
on although individual hosts with only one port might be able to make a
a connection.  Are there any other possible ways to do this?

Antonio Querubin, Jr.
querubin@uhccux.uhcc.hawaii.edu
querubin@uhccux (BITNET)
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 09:32:42 GMT
From:      cs.utexas.edu!samsung!munnari.oz.au!uhccux!querubin@tut.cis.ohio-state.edu  (Antonio Querubin)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for SUN

Does anyone know where I might be able to find a public domain package that
implements SLIP on a SUN SPARC and works with the rest of the built-in TCP/IP
routines?

Antonio Querubin, Jr.
querubin@uhccux.uhcc.hawaii.edu
querubin@uhccux (BITNET)
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 09:48:15 GMT
From:      zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uniwa!toivo@tut.cis.ohio-state.edu  (Toivo Pedaste)
To:        tcp-ip@nic.ddn.mil
Subject:   tcpdump
I'm runing tcpdump on a sun3 with sunos4. It seem to work fine apart
from no showing DNS (port domain) request packets. It show the replies
just fine but absolutely no requests. Any suggestions.
-- 
	Toivo Pedaste				ACSNET:   toivo@uniwa.uwa.oz
	WARCC,					INTERNET: toivo@uniwa.uwa.oz.au
	University of Western Australia		Phone:    (09) 382 0245
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Aug 90 16:55:06 PDT
From:      postel@venera.isi.edu
To:        philmtl!atha!aupair.cs.athabascau.ca!lyndon@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  Is there a spec for "uucp-path 117/tcp" ?

Hi.

See RFC-915.

How could one figure that out?  See RFC-1060 "Assigned Numbers", look on
page 10, see that port 117 is associated with reference 44, look on page
68 to see that reference 44 is RFC-915.

--jon.
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 16:24:23 GMT
From:      usc!samsung!xylogics!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Serious Routing Problems
In article <9007311833.AA22548@nsipo.arc.nasa.gov>, 
medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
> 
> Kent, I'm a little confused here.  Line flapping should be fixed by
> having hystersis in the up/down line protocol.

	Yes, I was just wanting to point out that using the cisco
recommended settings for keepalive and update/holddown timers, a
20 second line outage will stimulate a route lossage of 4.5 minutes.

	I'm not faulting cisco for this, they have to recommend
*something* to their customers without knowing all details of
a particular situation.  There are trade-offs that I won't elaborate.
As I said, Chuck Hedrick has already posted details on
issues involved in shortening timers in IGRP for the bold-hearted
network managers out there that would like faster convergence.

> 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.

	Right, I was just looking for demonstrated corroboration.
I must be belaboring the obvious, so let's move on to other topics
like expanded network addressing or open routing or S.I.N/dual IS-IS.

	--Kent
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 17:48:47 GMT
From:      att!tsdiag!daved@ucbvax.Berkeley.EDU  (Dave Danielson)
To:        tcp-ip@nic.ddn.mil
Subject:   NOVELL <--> TCP/IP gateway
I am looking for information of bridging NOVELL LANs to a TCP-IP
environment.  I am trying to *transparently* get file transfers
and eventually e-mail from inside of the NOVELL LAN to systems
over TCP/IP ethernet (no slip available %-P).  I would
appreciate anybody's experiences with this configuration.  I
would be more than happy to do the socket programming (if
available) but the end result must be transparent to the end
user.  I have heard of a MICOM board to accomplish this but
don't know if its good or bad or if there are better ways to do
this.
Thanks in advance for any help....
Dave
-- 
Dave Danielson (daved@tsdiag.ccur.com)  Concurrent Computer Corporation 
FAX   : 201/870-5952               2 Crescent Place  Oceanport,NJ 07728
UUCP  : ucbvax!rutgers!petsd!tsdiag!daved           PHONE: 201/870-4137
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 18:40:26 GMT
From:      excelan!barrey@ames.arc.nasa.gov  (Barrey Jewall)
To:        tcp-ip@nic.ddn.mil
Subject:   Tahoe/Reno naming conventions (WAS Re: tcpdump on 4.3 Reno?)
In article <1368@necis.UUCP> adamm@necis.UUCP (Adam S. Moskowitz) writes:
>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:

>} 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.

>AdamM



Like it matters, anyway, but...

I-80 Doesn't go to Tahoe, but US Hwy 50 does...

We now return you to your regular newsgroup content.

Barrey


+================================================================+
+  San Francisco Giants -  5 1/2  Games Back and Gaining !!      +
+					Hummmm Baby!!!           +
+===============================++===============================+
+ Barrey Jewall                 ++ "My opinions are my opinions" +
+ barrey@novell.com	        ++ (rather self-evident, eh?)    +
+ Novell, Inc.- San Jose, Calif.++				 +
+===============================++===============================+
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 18:57:25 GMT
From:      rgt@lanl.gov  (Richard Thomsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Networking protocols at high speed (800 MBits/sec)

This may not be the best group(s) to put this out on, so please email me
some advice (no flames, OK?).

There is an ANSI standards group (X3T9.3) that is working on a fibre channel
that is to carry data at 800 MBits per second.  It is commissioned to carry
SCSI, IPI, and HIPPI on it at these speeds.  It meets every month in both
working groups and plenaries.  It started as an extension of the HIPPI
standards group, done in the same committee as HIPPI and IPI, and is
designed to give HIPPI speeds to SCSI and IPI, and do all three on fibre.
SCSI is in another X3T9 group, so is somewhat related.  FDDI is in X3T9.5.

HIPPI, for those that do not know, is a 32-bit parallel channel that will
carry data at speeds of 800 MBits/second for up to 25 meters.  The HIPPI
physical standard is out for its second public review, and the next layers,
including the 802.2 encapsulation layer, is currently in process.

I and others desire to run networking protocols over this fibre channel.
However, the committee is dominated by people with experience on channels
to disks and tapes, and do not work the same way as networking protocols.
For example, they do not like layering, and want physical circuit switched
data transfer instead of datagrams.  They are building a standard that will
contain all information from the physical level (lasers and fibre) up to
the application interface to SCSI, IPI, etc., although the document itself
will be split into clauses that specify each "layer".  It includes parts of
the networking and transport layers.

I am trying (with various levels of success) to get datagram service on this
fibre channel.  They have agreed to put datagram service on in general,
although it is not exactly what I desired.  I have also been repetedly
pushed to figure out how to use their circuit based methods to do datagrams
so they do not have to support datagrams directly.

Here at Los Alamos, we are building a new network, in which we plan to run
TCP/IP for now, with migration to OSI in the future.  To do this, I am
planning on putting both on 802.2, and putting 802.2 on the fibre channel.
However, it is a very discouraging effort, and others have given up on
fibre channel due to the domination by the channel people.

If there is anyone on these newsgroups who is interested in running either
TCP/IP and/or OSI on fibre channel, it may pay you to look into the fibre
channel effort.  With enough support, it may be possible to either sway
the committee to a standard more conducive to this effort, or to come up
with a different protocol on the basic physical layer that will be defined.
In either case, there are those in the committee who are quite set in their
ways, and hope to get this standard nailed down in the quite near future.
It is almost too late to get things changed, but there is a little hope
that things will improve.

If anyone is interested in the fibre channel or HIPPI efforts, please send
me email on the subject, since I do not read these newsgroups in general.
It would be best if many networking people would come to the fibre
channel meetings to see what is going on and to give their input.  It seems
to me that they are trying to solve problems that were solved in the
networking efforts 25 years ago, but will not listen to me.  Also, I
have only a little experience in all this, so could use some help and
advice.  If a large number of manufacturers add fibre channel ports to
their machines and workstations, it will be a channel that networks will
wish to use, and it would be best to get your ideas in now.

IBM seems to be very committed to the fibre channel project, and there are
usually 9-12 IBM people from 5 IBM sites at the meetings.  However, these
are disk and tape people in general, not networking people.  Other companies
include Cray Research, CDC, Amdahl, DEC, LLNL, NCR, Sun, Unisys, etc.
My last notes show 50 people from 29 companies attending.  If desired, I
can email a copy of the last minutes that I received on email, although
I doubt they would make much sense without background information.

						Richard Thomsen
						rgt@lanl.gov
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 19:24:30 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump on 4.3 Reno?
In article <1368@necis.UUCP> adamm@necis.UUCP (Adam S. Moskowitz) writes:
> Reno is the next town north of Tahoe on I-80 hence the name.

Tahoe isn't on I-80.  Reno is the next nearest place to go for
gambling from the bay area, however.

--
Warner Losh		imp@Solbourne.COM
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 19:57:16 GMT
From:      att!cbnewsl!wts@ucbvax.Berkeley.EDU  (wts)
To:        tcp-ip@nic.ddn.mil
Subject:   Question:TCP-IP Problems?


I am posting this for a colleague. Any help you can provide will be greatly
appreciated.  Please email response directly to her.
__
	Has anyone experienced TCP crashes while doing a TCP send function?
	We are utilizing MICOM Interlan TCP/IP software, version 2.1, which
	randomly crashes while performing a send() of data to connected
	clients.  Once this occurs, it is impossible to do a "netstat" or
	to remotely log in to the affected machine.  The other PC's
	(all AT&T386 UNIX v.3.2.2) can communicate with each other through the 
	network with no problems.  If you have any suggestions or helpful hints,
	please send information to att!winken!laf.

	Lynn F. Andrews
	AT&T Federal Systems Research & Development  Burlington, NC
	UUCP: att!winken!laf   Phone: 919-228-3257
__
William T. Sykes  AT&T Federal Systems Advanced Technologies  Burlington, NC
UUCP: att!burl!wts  att!cbnewsl!wts
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Aug 90 00:54:15 EDT
From:      "Bill Rubin" <RUBINM@IBM.COM>
To:        rogue.llnl.gov!oberman@lll-winken.llnl.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Ports 1000-1023 reserved?
R. Kevin Oberman 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.  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

But, on the other hand, we do not have this problem with any
implementation other than HP's, so the case can be made that they
should do what everyone else does, too.

I just checked the RFC, and it is true, it does say that the ports are
reserved.  However, that RFC is dated 3/90, and I believe this problem
has been around longer than that.  The previous "Assigned Numbers" RFC,
1010, did not include this restriction.

As both Dan Barton and I have already said, our new VM product,
shipping later this year, solves this problem.

Bill Rubin
IBM TJ Watson Research
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 22:58:13 GMT
From:      mephisto!bbn.com!wbe@rutgers.edu  (Winston Edmond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 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)

In article <1990Jul27.202346.2089@ibmpa> brunner@ibmsupt.UUCP () writes:
>Alex, this posting _really is_ using the list and gatewayed newsgroup(s)
>for commercial purposes.

Except that "selling" something for essentially the distribution cost alone
sounds pretty much like a non-profit activity, even if it is being done by a
for-profit company.
 -WBE
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 00:20:47 GMT
From:      usc!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!procyon.cis.ksu.edu!jfy@ucsd.edu  (Joseph F. Young)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for traceroute for SunOS4.0.3

I am looking for traceroute for SunOS 4.0.3 on Sun3s and 4s.
Does anyone have such a beast up and running? 

If you do, I would be interested in hearing from you.
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Aug 90 08:46:46 -0400
From:      H. Craig McKee <mckee@community-chest.mitre.org>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump on 4.3 Reno?
>(Adam S. Moskowitz)
>
>The story, as I heard it from the nameless gradual student who claims 
                                            ^^^^^^^
Freudian slip ??  I believe you meant occasional or habitual.

Regards - Craig
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 02:28:39 GMT
From:      barmar@think.com  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ports 1000-1023 reserved?
In article <1628@excelan.COM> donp@novell.com (don provan) writes:
>I don't even understand what prompted some misguided soul to
>add the extra, unnecessary code needed to make this check.

I suspect that it is trying to prevent users from spoofing standard
services.  For instance, mail can normally be forged by opening a
connection to port 25.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 03:44:52 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: Looking for traceroute for SunOS4.0.3
In article <1990Aug2.002047.762@maverick.ksu.ksu.edu> jfy@procyon.cis.ksu.edu (Joseph F. Young) writes:

   I am looking for traceroute for SunOS 4.0.3 on Sun3s and 4s.
   Does anyone have such a beast up and running? 

I have it running.  Get uunet.uu.net:/networking/traceroute_pkg.tar.Z
which includes new kernel .o's and all the sources you need.  Manavendra
K. Thakur <thakur@zerkalo.harvard.edu> put it together from the original
source distribution and Sun-supplied new kernel modules.  When he announced
this Manavendra said:

"Because installing traceroute requires kernel mods, some people are
understandably reluctant to begin fooling with it.  To help things
along a little, I have collected *all* the code you need to compile
and install traceroute on a Sun 3, Sun 3x, Sun 4, or Sun 4c.

"The package includes sources for the two kernel modules that need
compiling (ip_icmp.c and raw_ip.c, patched and made available by Bill
Nowicki at Sun) as well as the traceroute executable (traceroute.c),
already patched for LSRR.  I've also included the contents of the
original traceroute.tar package as released by Van Jacobson.

"I wrote a Makefile and README that might help people compile and
install this software."

Worked good for me.

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
comp.text.sgml	ISO 8879 SGML, structured documents, markup languages
			yes votes to sgml-yes@math.lsa.umich.edu
			 no votes to  sgml-no@math.lsa.umich.edu
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Aug 90 08:29:08 EDT
From:      Mary Byrne <mbyrne@BBN.COM>
To:        tcp-ip@nic.ddn.mil
Cc:        mbyrne@BBN.COM
Subject:   remove me please
Please remove me from list.
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Aug 90 12:33:43 PDT
From:      postel@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ports 1000-1023 reserved or IBM/HP-UX FTP session hangs on PORT
Hi.

Barns and Provan are correct.

--jon.

Bill Barns says:

   I'm concerned that the replies I've seem posted didn't talk about the
   difference between local ports and remote ports.

   Any system can have whatever notion of reserved local ports that it cares
   to adopt.  It should not be necessary, and in my opinion it is wrong, for
   one system (call it A) to know or care about the reserved ports, if any,
   of some other system (call it B).  It isn't very convenient for me to test
   it, but I think that a vanilla BSD UNIX behaves as I describe, i.e., will
   let any of its users connect to port 1000 of a remote host, but won't let
   a user use local port 1000 without having the requisite privilege.

   When system A sends an FTP PORT command to the server on system B, the
   port number mentioned is a port number on system A.  System B ought to
   believe whatever system A asserts about port numbers on system A, even
   if that port number is used differently on system B or elsewhere.  It's the
   responsibility of system A to pick a reasonable port number (for example,
   system A shouldn't choose the port number used by a server that
   system A supports).  But if system A thinks that 1000 is a reasonable
   port number, system B should be willing to talk to system A's port 1000.

   Note that FTP PASV also handles the ports this way.  When system A
   sends a PASV command to system B, system B responds with a port number
   on system B, chosen by system B according to whatever local rules
   apply there.  System A doesn't need to know why system B made whatever
   choice it made.  System A should just connect to the port on system B
   that system B chose.


Don Provan says:

   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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
						

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Aug 90 10:27:03 EDT
From:      Alex McKenzie <mckenzie@BBN.COM>
To:        tcp-ip@nic.ddn.mil
Subject:   An announcement from DCA
I have nothing to do with this announcement.  I am hoping this reposting
is a public service, since I can't tell who the original was sent to.
My apologies if this ends up being a duplicate (I have not yet seen one
on tcp-ip at the time of this posting).

Alex McKenzie

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

Date: Wed, 1 Aug 90 13:56:01 PDT
From: DDN Reference <NIC@nic.ddn.mil>
Subject: DDN MGT Bulletin 75
To: MGT: ;
cc: nic@nic.ddn.mil
Message-ID: <12610403626.38.NIC@NIC.DDN.MIL>

***********************************************************************
DDN MGT Bulletin 75               DCA DDN Defense Communications System   
1 Aug 90                          Published by: DDN Network Info Center
                                      (NIC@NIC.DDN.MIL)  (800) 235-3155


                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the NIC.DDN.MIL host [192.67.67.20]
using login="anonymous" and password="guest".  The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

          DEFENSE DATA NETWORK MAILBRIDGES/CORE GATEWAYS


DDN Management Bulletin 74 defined MILNET gateway and host addressing
assignments for acquiring Exterior Gateway Protocol (EGP) service and
access to subscribers on the Internet.  Please correct the Internet
address given in that bulletin for the Randolph AFB, TX mailbridge to
read 26.3.0.101.  DDN Management Bulletin 74 incorrectly had this
address as 26.30.0.101 (the correct host port is three, NOT thirty).

In addition, it is emphasized that the 800 number provided in
Bulletin 74 should only be used for questions concerning address
assignments.   All other problems (e.g., line outages and cross-network
connection difficulties) should be first referred to the MILNET
Trouble Desk serving the geographic area of the subscriber as follows:

    A.  CONUS/Western hemisphere, except Washingon, DC and Alaska: 
        1-800-451-7413 or (202) 486-1982 or (DSN) 231-1787

    B.  Europe:  (DSN) 314-430-5532/5534 or (ETS) 430-5532/5534 or 
        (MIL) 2729-5532/5534 or (International) 011-49-711-687-7766 
        and 011-49-680-5532/5534

    C.  Pacific:  (DSN) 315-456-1472/1473/1474 or (Commercial)
        808-656-1472/1473/1474 and 808-624-3744


2.  The following is an update on actions being taken to alleviate
problems being encountered with the mailbridges:

    A.  The seventh mailbridge at Randolph is scheduled for activation on 
6 Aug 90.

    B.  Cutover to the new assignments listed in DDN Management
Bulletin 74 is scheduled for 10-12 Aug 90.

    C.  Selected Air Force concentrators have been modified to access only 
a primary EGP server; this has resulted in a reduced demand for EGP 
service.  Other gateway administrators are encouraged to take the same 
action if at all possible.

    D.  Software changes have been deployed and successfully tested with 
Air Force concentrator gateways that permit negotiated EGP update polling 
for up to sixty minute intervals (versus the defacto default of three 
minute intervals).  Other gateway administrators are encouraged to use this 
new feature as well.

    E.  A positive exchange was held with Army, Navy, Air Force, and 
industry representatives on 20 Jun 90.  This resulted in a common 
understanding of the complexities associated with gateway protocols and 
Internet routing issues and laid the groundwork for implementation of 
protocols beneficial to all.

    F.  An extended outage of the communications link between the
mailbridge in McLean, VA and the Internet node at College Park, MD has
had an adverse impact on traffic between the MILNET and the Internet,
as well as on network gateway updates from the Internet.  This outage
forces all traffic and updates to traverse the mailbridge at Moffett
Field, CA and results in the inability to handle the offered traffic
load and occasional loss of EGP updates.  The restoration of this
vital link is being actively pursued and we are evaluating the
feasibility of establishing other alternate paths between the MILNET
and the Internet.  We are also working with the Army to off-load a
major MILNET/Internet host traffic flow directly to the Internet.


3.  Request widest dissemination of the above information.  POC is Mr. Wayne 
Grindle, DOD, (DSN) 356-5030 or (703) 285-5030 or Mr. Dennis Morris, DRFD, 
(DSN) 356-5221 or (703) 285-5221.

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 11:23:32 GMT
From:      uhccux!virtue!comp.vuw.ac.nz!munnari.oz.au!metro!ipso!hitech!clyde@ames.arc.nasa.gov  (Clyde Smith-Stubbs)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP for Xenix wanted
Can anyone recommend a TCP/IP implementation for Xenix other than
SCO's broken TCP? Preferably to run on a WD8003 (Ethercard Plus) board.
Please reply by e-mail (no incoming news at present).

Clyde Smith-Stubbs	 | HI-TECH Software,	   | Voice: +61 7 300 5011
clyde@hitech.ht.oz.au	 | P.O. Box 103, Alderley, | Fax:   +61 7 300 5246
...!nwnexus!hitech!clyde | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 300 5235
Hick's Law of Systems Programming: Don't test for errors you can't handle.
-- 
Clyde Smith-Stubbs	 | HI-TECH Software,	   | Voice: +61 7 300 5011
clyde@hitech.ht.oz.au	 | P.O. Box 103, Alderley, | Fax:   +61 7 300 5246
...!nwnexus!hitech!clyde | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 300 5235
Hick's Law of Systems Programming: Don't test for errors you can't handle.
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Aug 90 16:09:38 EDT
From:      Darrel Beach <beach@server.af.mil>
To:        tcp-ip@nic.ddn.mil
Cc:        beach@server.af.mil, beach@ddnuvax.af.mil
Subject:   HELP
For all those reading this:
  If youanswered some queries I recently posted to TCP/IP, or were continuing
a discussion directly with me, please resend anything you sent in the last
four days.  I was out and lightning took its toll yesterday.
  Thanks
Darrel Beach
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 12:29:08 GMT
From:      mbyrne@BBN.COM (Mary Byrne)
To:        comp.protocols.tcp-ip
Subject:   remove me please

Please remove me from list.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Aug 90 16:33:00 EDT
From:      TANNERC@CRL.AECL.CA
To:        tcp-ip@NIC.DDN.MIL
Subject:   Telnet - Trouble with Control S
One of our users wants to TELNET from a VAX running Wollongong TCP-IP to
another system (a CDC Cyber 990) and run the EMACS editor on the remote
system. Unfortunately, TELNET uses Control S for flow control purposes.

Is their any way to tell TELNET to pas CONTROL-s just as it does any other
character. We tried toggling the XON parameter with no success. We are running
WIN/TCP vs 5.0, and the NOS/VE 1.5.1 on the CDC.

Thanks for your help.

 Chris Tanner
AECL-Chalk River           TANNERC@CRL.AECL.CA
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 14:27:03 GMT
From:      mckenzie@BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   An announcement from DCA

I have nothing to do with this announcement.  I am hoping this reposting
is a public service, since I can't tell who the original was sent to.
My apologies if this ends up being a duplicate (I have not yet seen one
on tcp-ip at the time of this posting).

Alex McKenzie

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

Date: Wed, 1 Aug 90 13:56:01 PDT
From: DDN Reference <NIC@nic.ddn.mil>
Subject: DDN MGT Bulletin 75
To: MGT: ;
cc: nic@nic.ddn.mil
Message-ID: <12610403626.38.NIC@NIC.DDN.MIL>

***********************************************************************
DDN MGT Bulletin 75               DCA DDN Defense Communications System   
1 Aug 90                          Published by: DDN Network Info Center
                                      (NIC@NIC.DDN.MIL)  (800) 235-3155


                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the NIC.DDN.MIL host [192.67.67.20]
using login="anonymous" and password="guest".  The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

          DEFENSE DATA NETWORK MAILBRIDGES/CORE GATEWAYS


DDN Management Bulletin 74 defined MILNET gateway and host addressing
assignments for acquiring Exterior Gateway Protocol (EGP) service and
access to subscribers on the Internet.  Please correct the Internet
address given in that bulletin for the Randolph AFB, TX mailbridge to
read 26.3.0.101.  DDN Management Bulletin 74 incorrectly had this
address as 26.30.0.101 (the correct host port is three, NOT thirty).

In addition, it is emphasized that the 800 number provided in
Bulletin 74 should only be used for questions concerning address
assignments.   All other problems (e.g., line outages and cross-network
connection difficulties) should be first referred to the MILNET
Trouble Desk serving the geographic area of the subscriber as follows:

    A.  CONUS/Western hemisphere, except Washingon, DC and Alaska: 
        1-800-451-7413 or (202) 486-1982 or (DSN) 231-1787

    B.  Europe:  (DSN) 314-430-5532/5534 or (ETS) 430-5532/5534 or 
        (MIL) 2729-5532/5534 or (International) 011-49-711-687-7766 
        and 011-49-680-5532/5534

    C.  Pacific:  (DSN) 315-456-1472/1473/1474 or (Commercial)
        808-656-1472/1473/1474 and 808-624-3744


2.  The following is an update on actions being taken to alleviate
problems being encountered with the mailbridges:

    A.  The seventh mailbridge at Randolph is scheduled for activation on 
6 Aug 90.

    B.  Cutover to the new assignments listed in DDN Management
Bulletin 74 is scheduled for 10-12 Aug 90.

    C.  Selected Air Force concentrators have been modified to access only 
a primary EGP server; this has resulted in a reduced demand for EGP 
service.  Other gateway administrators are encouraged to take the same 
action if at all possible.

    D.  Software changes have been deployed and successfully tested with 
Air Force concentrator gateways that permit negotiated EGP update polling 
for up to sixty minute intervals (versus the defacto default of three 
minute intervals).  Other gateway administrators are encouraged to use this 
new feature as well.

    E.  A positive exchange was held with Army, Navy, Air Force, and 
industry representatives on 20 Jun 90.  This resulted in a common 
understanding of the complexities associated with gateway protocols and 
Internet routing issues and laid the groundwork for implementation of 
protocols beneficial to all.

    F.  An extended outage of the communications link between the
mailbridge in McLean, VA and the Internet node at College Park, MD has
had an adverse impact on traffic between the MILNET and the Internet,
as well as on network gateway updates from the Internet.  This outage
forces all traffic and updates to traverse the mailbridge at Moffett
Field, CA and results in the inability to handle the offered traffic
load and occasional loss of EGP updates.  The restoration of this
vital link is being actively pursued and we are evaluating the
feasibility of establishing other alternate paths between the MILNET
and the Internet.  We are also working with the Army to off-load a
major MILNET/Internet host traffic flow directly to the Internet.


3.  Request widest dissemination of the above information.  POC is Mr. Wayne 
Grindle, DOD, (DSN) 356-5030 or (703) 285-5030 or Mr. Dennis Morris, DRFD, 
(DSN) 356-5221 or (703) 285-5221.

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 15:12:47 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!romp!auschs!awdprime!sandino.austin.ibm.com!jeffe@tut.cis.ohio-state.edu  (Peter Jeffe 512.823.4091)
To:        tcp-ip@nic.ddn.mil
Subject:   bug in BSD tahoe res_send()?
I'm not sure if this is a bug, but in BSD tahoe res_send.c (6.21), the
following code looks fishy:

|	for (retry = _res.retry; retry > 0; retry--) {
|	   for (ns = 0; ns < _res.nscount; ns++) {
|... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
|#if	BSD >= 43
|			if (_res.nscount == 1 || retry == _res.retry) {
                                              !!!^^^^^^^^^^^^^^^^!!!
|				/*
|				 * Don't use connect if we might
|				 * still receive a response
|				 * from another server.
|				 */
|				if (connected == 0) {
|					if (connect(s, &_res.nsaddr_list[ns],
|					    sizeof(struct sockaddr)) < 0) {
|	[ #ifdef DEBUG ]
|						continue;
|					}
|					connected = 1;
|				}
|				if (send(s, buf, buflen, 0) != buflen) {
|	[ #ifdef DEBUG ]
|					continue;
|				}
|			} else {
|	[ connect() to no_addr (0.0.0.0) and sendto(_res.nsaddr_list[ns]) ]

The problem (?) is that while (retry == _res.retry) we only query the first
host, since we connect() the first time through, and then keep send()ing to
whomever we're connected to, until we decrement retry and fall through to
the sendto() call.  So if we've got 3 nameservers defined in resolv.conf,
and all of them are down, we query in the following order:

	1, 1, 1,  1, 2, 3,  1, 2, 3

Now, I don't know if this was intended, but it jes' don't seem right to
me.  Especially since the virtual-circuit code doesn't act the same.
Personally, I'd chuck the connect()/send() stuff and just do the sendto()
(or at least do it only on (_res.nscount == 1) if you really think it's
more efficient).  What say ye all?

-------------------------------------------------------------------------------
Peter Jeffe   ...uunet!cs.utexas.edu!ibmchs!auschs!sandino.austin.ibm.com!jeffe
        first they want a disclaimer, then they make you pee in a jar,
                   then they come for you in the night
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 16:55:08 GMT
From:      cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!atha!aupair.cs.athabascau.ca!lyndon@tut.cis.ohio-state.edu  (Lyndon Nerenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is there a spec for "uucp-path 117/tcp" ?
In article <12@aupair.cs.athabascau.ca>, I asked:

> Several of our machines list the service "uucp-path" on tcp port 117.
> Does anyone have a reference describing what this service does?

Thanks to the several people who directed me to:
  
  RFC915  Elvy, M.A.; Nedved, R.  Network mail path service.  1984 December;

-- 
     Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
         {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca
                           Practice Safe Government
                                 Use Kingdoms
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 17:39:15 GMT
From:      cunixf.cc.columbia.edu!cunixe.cc.columbia.edu!jbaltz@rutgers.edu  (Jerry B. Altzman)
To:        tcp-ip@nic.ddn.mil
Subject:   ethernet addr listing
(excuse the novitiate)

From where can I get a listing of what ethernet-address headers mean which
manufacuturer, machine type, &c?

Respond by mail, I'll post sources if asked.

Thanks!

//jbaltz
--
jerry b. altzman  "I didn't do it, and when I did I wasn't"      212 854 8058
jbaltz@columbia.edu   "there, and you deserved it."      jauus@cuvmb (bitnet)
NEVIS::jbaltz (HEPNET)                    ...!rutgers!columbia!jbaltz (bang!)
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 17:55:51 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!aplcen!jhunix!roskar@ucsd.edu  (Veljko Roskar)
To:        tcp-ip@nic.ddn.mil
Subject:   Free and commercial software for FTP/TELNET on the Mac

Could someone please point out to me where I can get the National
Center's for Supercomputing Applications versions of ftp and 
telnet for the Mac.

Does this software support ftp while using telnet?
Does it have any Tektronix emulation?

I am aware that there is a commercial product that "sits" on top
of the new VersaTerm's comm toolbox, but I have no idea about where
I can buy it or who makes it.

Eternal thanks for help on this.

P.S. If any of you know of good and cheap ethernet boards that work with
the above mentioned products and fit in the SE/30, please recommend some.

This is for my advisor. It's important that I keep him happy.


Thank you so.



-- 
Best regards,
Veljko Roskar                            | roskar@jhuvms.bitnet
Department of Chemical Engineering       | roskar@jhuvms.hcf.jhu.edu  
The Johns Hopkins University, Baltimore  | uunet!mimsy!aplcen!jhunix!roskar
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 18:03:06 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!stiatl!bagend!bvsatl!bvs@ucsd.edu  (bvs)
To:        tcp-ip@nic.ddn.mil
Subject:   Testing IP option implementation
Hello Folks-

I am in the process of debugging some IP kernel code, and I need a way
to send packets with IP options. Rather than jump right in and
starting to write code, I thought
I might save some time by asking around.

So-  Does anyone know of an application that sends packets that have ip
options set? 

I read in the "traceroute" source code that there is/was a version
of this program that sends out packets with the source routing option
set. Is this true? If it is true, where can I get this version?

Thanks in advance-
Bill VerSteeg
bvs@nrc.com
or
(.....)!gatech!galpb!bagend!bvsatl!bvs
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 21:27:30 GMT
From:      uhccux!virtue!comp.vuw.ac.nz!munnari.oz.au!bruce!labtam!cnw01!nigel@ames.arc.nasa.gov  (Nigel Harwood)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: WIN/TCP Sessions Hanging
In article <1443@ukpoit.co.uk>, ian@ukpoit.co.uk (Ian J Spare) writes:
> WIN TCP/IP rel 4.0.0.2 and NCR Tower 400 and 500's under REL 3.
> When an rlogin or telnet drops [...] 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.

I have sometimes noticed this on our EXELAN TCP/IP running on NCR
Tower 600 1.03 and Tower 650 2.01.

-- 
<<<<<<<<<<<<<<<<<<<<<<<<<  Nigel Harwood  >>>>>>>>>>>>>>>>>>>>>>>>>>>
<< Post:  Coles Myer Ltd, PO Box 2000 Tooronga 3146, Australia     >>
<< Phone: +61 3 829 6090  E-mail: nigel@cnw01.storesys.coles.oz.au >>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 22:57:18 GMT
From:      joshua@athertn.Atherton.COM (Flame Bait)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Books on RPC programming?

In article <296@uucs1.UUCP> gaf@uucs1.UUCP () writes:
>I'm rather a novice at this remote procedure call stuff (Sun RPC variety),
>and am looking for reference material.
>
>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").

Get a copy of the SunOS 4.1 documenation for RPC.  I thought it was
much better than the stuff available with 3.X.

Also, Springer-Verlag has a book planned for July 1990 called "Remote 
Procedure Call Programming-Writing Networked Applications" by J. Corbin.
ISBN 97247-1  (order by calling 1-800-SPRINGER).  Does anybody have
this book?  Is it any good?  What level of programmer is aimed at?
And finally is J. Corbin on the net?

I've got no connection to Springer-Verlag or Sun.  My info comes from an
ad on page 126 of the May/June 1990 SunTech Journal.  I would like to 
know if others think this book is worth getting.  Email to me and I'll
summarize to the net.

Joshua Levy (joshua@atherton.com)

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Aug 90 09:56 PDT
From:      CUSGMXD@OAC.UCLA.EDU
To:        "tco-ip@nic.ddn.mil" <tcp-ip@NIC.DDN.MIL>, "tco-ip@nic.ddn.mil" <tcp-ip@NIC.DDN.MIL>
Subject:   Re: (COPY) Sample mail MCIMAIL to the Internet, test
> this is a test
Hello! With whom are we actually communicating?
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 05:43:22 GMT
From:      zaphod.mps.ohio-state.edu!van-bc!skl@tut.cis.ohio-state.edu  (Samuel Lam)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: bug in BSD tahoe res_send()?
In article <3010@awdprime.UUCP>, jeffe@sandino.austin.ibm.com
 (Peter Jeffe 512.823.4091) wrote:
>I'm not sure if this is a bug, but in BSD tahoe res_send.c (6.21), the
>following code looks fishy:
...
>|			if (_res.nscount == 1 || retry == _res.retry) {
>                                             !!!^^^^^^^^^^^^^^^^!!!

(What a coincident!)  I also nailed this one within the last month,
as it had caused us grief around here for a long time and I finally
gotten around to it.  I think this is definitely a bug, but my
analysis is different from yours.

I fixed it by changing the problem line from

    if (_res.nscount == 1 || retry == _res.retry) {
                          **
to

    if (_res.nscount == 1 && retry == _res.retry) {
                          **

as this fix made sense to me at the time.  i.e. The condition become
"if we only have one name server, *then* if this is also our first
attempt to use it, then <do ...>".

I have talked to the Berkeley person in charge of 4.4 about this (Mike)
at the Vancouver IETF this week, and he commented that the 4.3-tahoe
BIND is a couple years old and suggested that I take a look at the
4.4-reno BIND (to be available shortly) to see if the bug is still
there before I post a note to the BIND mailing list about it.

...Sam
-- 
Internet: <skl@wimsey.bc.ca>	UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.ca!skl
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 05:51:44 GMT
From:      hpcc01!hpcea!hpldsla!manoj@hplabs.hpl.hp.com  (Manoj Joshi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Excelan Lan Workplace and Packet Drivers?
Let me know if you do find out some way. I could test this either!

manoj

manoj@hpldas5.hp.com
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 07:28:46 GMT
From:      corbin@nibroc.Eng.Sun.COM (John Corbin)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Books on RPC programming?

In article <28186@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes:
>Also, Springer-Verlag has a book planned for July 1990 called "Remote 
>Procedure Call Programming-Writing Networked Applications" by J. Corbin.
>ISBN 97247-1  (order by calling 1-800-SPRINGER).  Does anybody have
>this book?  Is it any good?  What level of programmer is aimed at?
>And finally is J. Corbin on the net?

The book will not be out until November 1990.  The title has been changed
to "The Art of Writing Distributed Applications using Remote Procedure Calls".
The ISBN is still the same.  Of course I think that the book is good, but
that is my biased opinion.

The book is aimed at an experienced C programmer.  You do not need prior
networking experience or familarity with the UNIX operating system.
It is a reference book with examples and should be useful to both new and
experienced users of Sun's RPC Library.

Here is the table of contents:

Chapter		Title
1		Introduction and Overview
2		eXternal Data Representation
3		RPC Protocol
4		RPC Programming
5		Low Level RPC Programming
6		Additional RPC Library Features
7		Rpcgen
8		Developing RPC-based Distributed Applications
9		Future Directions of RPC Programming

Appendicies:
1		Sun RPC Information (getting program and authentication numbers)
2		XDR Specification
3		RPC: Protocol Specification
4		Differences Between the RPC Library on SunOS 4.0 and 4.1

I am on the net and any feedback on the book would be appreciated.

John Corbin (jcorbin@Sun.COM)

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 09:41:42 GMT
From:      mcsun!ub4b!bbl!caj@uunet.uu.net  (Johan Casier)
To:        tcp-ip@nic.ddn.mil
Subject:   Booting DOS machines from UNIX servers
Hi,

does anybody know of a product that makes it possible to boot a
diskless DOS pc and download PC-NFS from a UNIX NFS server over tcp-ip ?
 
Johan Casier.  
caj@bbl.be  

I.M.X. - The Open Systems Experts
Information Management Systems & Services 	TEL. +32 2 7254950
Imperiastraat 10				FAX. +32 2 7254605
1930 Zaventem
Belgium
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Aug 90 17:18:16 PDT
From:      postel@venera.isi.edu
To:        cunixf.cc.columbia.edu!cunixe.cc.columbia.edu!jbaltz@rutgers.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  ethernet addr listing

See pages 38-40 of RFC-1060.

	Date: 2 Aug 90 17:39:15 GMT
	From: cunixf.cc.columbia.edu!cunixe.cc.columbia.edu!jbaltz@rutgers.edu 	(Jerry B. Altzman)
	Subject: ethernet addr listing
	To: tcp-ip@nic.ddn.mil

	(excuse the novitiate)

	From where can I get a listing of what ethernet-address headers
	mean which manufacuturer, machine type, &c?

	Respond by mail, I'll post sources if asked.

	Thanks!

	//jbaltz
	--
	jerry b. altzman
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 13:57:26 GMT
From:      news@psuvax1.cs.psu.edu  (Dan &)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for traceroute for SunOS4.0.3
In article <EMV.90Aug1204452@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:

Edward> In article <1990Aug2.002047.762@maverick.ksu.ksu.edu> jfy@procyon.cis.ksu.edu (Joseph F. Young) writes:

Edward>    I am looking for traceroute for SunOS 4.0.3 on Sun3s and 4s.
Edward>    Does anyone have such a beast up and running? 

Edward> I have it running.  Get uunet.uu.net:/networking/traceroute_pkg.tar.Z
Edward> which includes new kernel .o's and all the sources you need.  Manavendra
Edward> K. Thakur <thakur@zerkalo.harvard.edu> put it together from the original
Edward> source distribution and Sun-supplied new kernel modules.  When he announced
Edward> this Manavendra said:

Does anyone know if this will work as distributed under SunOS 4.1?

Thnaks.
--
Dan Ehrlich <ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 15:08:15 GMT
From:      mcsun!hp4nl!fwi.uva.nl!casper@uunet.uu.net  (Casper H.S. Dik)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for traceroute for SunOS4.0.3
ehrlich@cs.psu.edu (Dan &) writes:


>Does anyone know if this will work as distributed under SunOS 4.1?

>Thnaks.
>--
>Dan Ehrlich <ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176

Traceroute requires NO kernel mods in SunOS 4.1.

So forget about using ip_icmp.o and raw_ip.o if you run SunOS 4.1
--
Casper H.S. Dik				VCP/HIP: +31205922022
University of Amsterdam     |		casper@fwi.uva.nl
The Netherlands             |		casper%fwi.uva.nl@hp4nl.nluug.nl
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 16:21:24 GMT
From:      usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!mathcs.emory.edu!osdjd@ucsd.edu  (Dan J. Doyle {EUCC})
To:        tcp-ip@nic.ddn.mil
Subject:   Termcap for 3163 ALA


Anybody know of a termcap entry written for an ibm 3163
using ALA mode?  Thanks...

Dan Doyle           	| osdjd@mathcs.emory.edu 		Internet
Emory University    	| {rutgers,ogicse,gatech}!emory!osdjd	UUCP
Info. Tech. Division	| osdjd@emory				BITNET
Atlanta, Ga 30322   	| 404-727-0038			
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 16:49:31 GMT
From:      sparkyfs!davy@ames.arc.nasa.gov  (David Curry)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for traceroute for SunOS4.0.3
In article <Fx_3brd1@cs.psu.edu> ehrlich@cs.psu.edu (Dan &) writes:
>In article <EMV.90Aug1204452@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>
>Edward>    I am looking for traceroute for SunOS 4.0.3 on Sun3s and 4s.
>Edward>    Does anyone have such a beast up and running? 
>
>Does anyone know if this will work as distributed under SunOS 4.1?
>

SunOS 4.1 has the appropriate things in the kernel.  I FTP'd traceroute
from ftp.ee.lbl.gov, compiled it, and it runs just fine under unmodified
SunOS 4.1.

--Dave Curry
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 16:53:31 GMT
From:      intercon!news@uunet.uu.net  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   3B2 SLIP?
Strange question of the day.  Does anyone have or know of a SLIP for AT&T's
3B2?
--
Kurt Baumann
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 19:29:21 GMT
From:      helios.ee.lbl.gov!horse.ee.lbl.gov!mccanne@ucsd.edu  (Steven McCanne)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcpdump
In article <1990Aug1.094815.9462@uniwa.uwa.oz> toivo@uniwa.uwa.oz (Toivo Pedaste) writes:
>I'm runing tcpdump on a sun3 with sunos4. It seem to work fine apart
>from no showing DNS (port domain) request packets. 

This probably was due to a bug that we've fixed for the next release.
If a protocol appeared twice in /etc/services, tcpdump would just pick
the first one (i.e. 'domain 53/tcp' and 'domain 53/udp').

In the meantime, saying 'port 53' should work.  

Also, using '-d' might shed some light on what went wrong.

Steve
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 90 19:33:13 GMT
From:      jhc@m2jhc.uucp (James H. Coombs)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Books on RPC programming?

In article <140113@sun.Eng.Sun.COM> corbin@sun.UUCP (John Corbin) writes:
>In article <28186@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes:
>
>The book will not be out until November 1990.  The title has been changed
>to "The Art of Writing Distributed Applications using Remote Procedure Calls".
>The ISBN is still the same.  Of course I think that the book is good, but
>that is my biased opinion.

Do you discuss techniques for getting a server to fork() copies of
itself, one per client?  I have been looking through the RPC 4.0
distribution and am beginning to think that the RPC communications
model has been implemented too strictly to permit the reasonable use of
fork().  I can modify the code to implement an optional fork, but then
I find that the server does not shut down when the client shuts down.
I have no trouble implementing these requirements (e.g., keepalives)
when working at the socket level.

If you have a way to do this, I would like to hear about it.  Also, if
you have comments on the RPC communications model, that would be
interesting.  Perhaps you do this already, but it would useful to
include a critique of RPC in your book: what is it good for and what is
it not good for, how should it be improved?

Thanks.  --Jim

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 90 04:18:32 GMT
From:      sdd.hp.com!elroy.jpl.nasa.gov!mahendo!poseur.JPL.NASA.GOV!earle@ucsd.edu  (Greg Earle - Sun JPL on-site Software Support)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: bug in BSD tahoe res_send()?
In article <1199@van-bc.wimsey.bc.ca>, skl@van-bc.wimsey.bc.ca (Samuel
Lam) writes:
>>I'm not sure if this is a bug, but in BSD tahoe res_send.c (6.21), the
>>following code looks fishy:
>...
>>|			if (_res.nscount == 1 || retry == _res.retry) {
>>                                             !!!^^^^^^^^^^^^^^^^!!!
> 
>(What a coincidence!)  I also nailed this one within the last month,
>as it had caused us grief around here for a long time and I finally
>gotten around to it.  I think this is definitely a bug, but my
>analysis is different from yours.
> 
>I fixed it by changing the problem line from
> 
>    if (_res.nscount == 1 || retry == _res.retry) {
>                          **
>to
>    if (_res.nscount == 1 && retry == _res.retry) {
>                          **
>
>as this fix made sense to me at the time.  i.e. The condition become
>"if we only have one name server, *then* if this is also our first
>attempt to use it, then <do ...>".

Yes, this is a bug.  But I do not think that your fix is the correct one;
for a better fix, use the res_send.c that comes with any BIND 4.8.2 version
that you can find (I believe several versions of BIND that purport to being
`BIND 4.8.2.x' abound; perhaps someone could make a definitive statement on
the situation?).  I chose the one from University of Toronto; you can get it
via anonymous FTP from neat.AI.Toronto.EDU, in `utbind.tar.Z'.  Examine the
code and you will see where this problem is dealt with directly.  The
connect()-ed socket is dis-connect()-ed if the resolver gets ECONNREFUSED
from the first round of nameserver queries.

In any case, this topic is fodder for the BIND mailing list, not the
comp.protocols.tcp-ip.domains newsgroup.  Use FTP to ucbarpa.Berkeley.EDU to
retrieve the archives of the BIND mailing list to find the original discussion
of this problem, and the solution proposed by the person whose fix is in the
U. of Toronto version.

--
	- Greg Earle
	  Sun Microsystems, Inc. - JPL on-site Software Support
	  earle@poseur.JPL.NASA.GOV	(Direct)
	  earle@Sun.COM			(Indirect)
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 90 08:30:47 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet - Trouble with Control S
In article <566262D2F87F806F57@CRL.AECL.CA> TANNERC@CRL.AECL.CA writes:
>Is their any way to tell TELNET to pas CONTROL-s just as it does any other
>character. We tried toggling the XON parameter with no success. We are running
>WIN/TCP vs 5.0, and the NOS/VE 1.5.1 on the CDC.

WIN/TCP for VMS is now at rev 5.1 (plus some patches that should be
available).  To get around the ^S problem, you need to add "SET
TERM/NOTTS" to your login on the VMS system.  This has the bad effect
of allowing your terminal to receive too much data, but does make
emacs work right.  This info is current as of release 3.2, but I don't
recall any changes that would make this break under 5.0.  5.1 changed
the terminal control code, so all bets are off for that version (ie, I
haven't tried it there).

Have fun....

Warner
--
Warner Losh		imp@Solbourne.COM
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 90 09:08:46 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!rpi!uupsi!sunic!tut!funic!santra!news@ucsd.edu  (Jyrki Kuoppala)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ports 1000-1023 reserved?
In article <1628@excelan.COM>, donp@novell.com (don provan) writes:
>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'm not familiar with the HP bug, but sounds like it's a kludge to fix
the same security problem that an UCB-bug-fixes posting fixes in
September 1987.  If the kind of checking that HP does is not done, it
may be possible to exploit the security weakness to some other
machines; I wonder if HP themselves have left the UCB-fix unapplied
becaused they 'fixed' it the other way.

The exact nature of the security problem is left as
an exercise to the reader.  

By the way, IMHO the UCB fix is also a horrible kludge, as is the
concept of the privileged TCP/IP ports altogether, but it was an
useful kludge at the time and it still is.

>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.

Yes, although it does close a security hole in some environments.

//Jyrki
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 90 14:01:27 GMT
From:      rti!dg-rtp!mav39!kean@mcnc.org  (Brian Kean)
To:        tcp-ip@nic.ddn.mil
Subject:   FTP PASV command problems
I have been trying to conduct third-party transfers with FTP which 
requires that one of the two FTP daemons support the PASV command.
Many nodes on the network claim that they support the PASV command 
but when the other FTP daemon tries to connect to the inetaddr,port 
returned in the reponse of PASV, their is no process listening.

I have had these problems with these nodes in particular:
	nic.ddn.mil
	nnsc.nsf.net

Is anyone familiar with this problem? Does anyone know someone at these 
nodes that might be able to answer my questions?
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 90 19:37:32 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!sloth.mlb.semi.harris.com!jdr@ucsd.edu  (Jim Ray)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP solutions for hp-3000
Anyone out there know of or has experience with TCP/IP boards and software
for the HP-3000 computer?

Specifically, I am interrested in FTP/TELNET and possibly the r(sh,login)
commands.

Send information me and I will post with summary.

Thanks,

Jim Ray                                Harris Semiconductor
Internet:  jdr@slopoke.mlb.semi.harris.com     PO Box 883   MS 62B-022
Phone:     (407) 729-5059              Melbourne, FL  32901
--
Jim Ray                                Harris Semiconductor
Internet:  jdr@mlb.semi.harris.com     PO Box 883   MS 62B-022
Phone:     (407) 729-5059              Melbourne, FL  32901
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 90 23:23:39 GMT
From:      snorkelwacker!usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@tut.cis.ohio-state.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  ethernet addr listing
In article <9008040018.AA26630@bel.isi.edu> postel@VENERA.ISI.EDU writes:
>	From where can I get a listing of what ethernet-address headers
>	mean which manufacuturer, machine type, &c?
>
>See pages 38-40 of RFC-1060.

Note that the RFC1060 tables are, as I understand it, based on observation
rather than access to the IEEE database.  Unless things have changed lately,
the actual database is considered confidential and is not available.  So
you can't get a complete and authoritative listing.
-- 
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
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Aug 90 12:57:05 pst
From:      jwb%dstos3.dsto.oz.au@pucc.PRINCETON.EDU (John Bennett - Defence Science & Technology, Organisation)
To:        lvarian%pucc.princeton.edu@fang.oz.au
Subject:   Re Network Temperature Protocol
Forwarded to TCP-IP for John Bennett
----------------------------Original message----------------------------
Hi,

I am mailing this because I can't post from my host.  You may care to post it
for me.

Because of the confusion over Celsius/Fahrenheit conversion, it may be useful
to know of the system used in Australia to accustom people to the new way of
thinking when we went metric  :-)

 0-9  deg C =   ?   Tens      (sorry, I forget this one)
10-19 deg C = Tingling Teens
20-29 deg C = Temperate Twenties
30-39 deg C = Thirsty Thirties
40-49 deg C = Fiery Forties

JB,      "Lord Warden of the Sync Ports"      (DSTO Network Manager)

John Bennett,                                 E-mail : jwb@dstos3.dsto.oz.au
Head, Networks Group                          Phone  : +61 8 259 5292
Information Systems Branch                    FAX    : +61 8 259 5177
DEFENCE SCIENCE AND TECHNOLOGY ORGANISATION   Postal : Bld 73 Labs Area
AUSTRALIA                                              PO Box 1600 Salisbury
                                                       South Australia  5108
                                                       AUSTRALIA
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 90 05:12:01 GMT
From:      sdd.hp.com!samsung!cs.utexas.edu!texbell!netdev!alex@ucsd.edu  (Alex Huppenthal)
To:        tcp-ip@nic.ddn.mil
Subject:   Open Network Architechure / CONCERT

 I'm looking for information regarding CONCERT and Open Network
 Architecture. I've been told that this has to do with TMN in 
 the EC. If you have information on this or can point to the 
 sources for these specifications I'd appreciate it.

 Thank you in advance,

 -Alex

     Alex            Internet:  alex@comsys.COM
     Huppenthal          UUCP:  {cs.utexas.edu!texbell}!netdev!alex 
     Communication Systems Research  6045 Buffridge Tr, Dallas, TX 75252  
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 90 06:42:13 GMT
From:      math.mit.edu!drw@bloom-beacon.mit.edu  (Dale R. Worley)
To:        tcp-ip@nic.ddn.mil
Subject:   Want source for nslookup
Is the source for nslookup publically available, and if so, where?

Thanks,

Dale			drw@math.mit.edu
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Aug 90 15:09:24 PDT
From:      braden@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Zero manufacturer code in SNAP?
	From tcp-ip-RELAY@NIC.DDN.MIL Sun Jul 22 05:40:28 1990
	Date: 20 Jul 90 18:31:49 GMT
	From: agate!shelby!portia.stanford.edu!jessica.stanford.edu!morgan@ucbvax.Berkeley.EDU  (RL "Bob" Morgan)
	Organization: Academic Information Resources
	Subject: Re: Zero manufacturer code in SNAP?
	References: <1990Jul17.010234.12077@portia.Stanford.EDU>, <9272@goofy.Apple.COM>
	Sender: tcp-ip-relay@nic.ddn.mil
	To: tcp-ip@nic.ddn.mil

...

	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.

I want to comment on this.  The decision of the Host Requirements Working
Group on this matter was not prompted by a desire to impede the adoption
of 802.3 as an Ethernet replacement, but rather by the desire to make 
things interoperate as well as possible, recognizing that existing
usage is predominantly Ethernet.  Indeed, we rather assumed that over
the long term 802.3 will gradually replace Ethernet, and that some
future Host Requirements revision might interchange the Ethernet 
and 802.3 requirements (i.e., MUST 802.3, MAY Ethernet).  I believe
that the perceived advantage of using an international standard over
a vendor standard will be the force driving this change -- the same
forces driving OSI to replace TCP/IP (he said with a straight face).

Bob Braden
 



-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Aug 90 15:18:30 -0400
From:      rich@gateway.mitre.org (Richard Verjinski)
To:        tcp-ip@nic.ddn.mil
From: primerd!ENI!S61!JB@bloom-beacon.mit.edu
Subject: An SMTP Question

>From: primerd!ENI!S61!JB@bloom-beacon.mit.edu
>I have an SMTP implementation that may or may not have a problem concerning
>null characters in the mail data.  RFC 821 states that the mail data may
>contain any of the 128 ASCII character codes.  This statement implys that
>the null character must also be handled as mail data.  Is this correct.

>I spoken with some people about this and they do not know of any implementation
>that supports this.  We have a customer who feels this is a problem.  The
>mail text with a null will truncate that line of the mail data since we
>are using C string functions.  Any comments or pointers will be appreciated.


The MIL-STD-1781 SMTP specification shows the BNF for an SMTP string on
page 20. 

  <string> ::= <char> | <char> <string>
  <char>   ::= <c> | \<x>
  <c>      ::= any of the 128 ASCII characters, but not any of the <special>
               or <sp>
  <x>      ::= any of the 128 ASCII characters (no exceptions)
  <special>::=  ... the spec shows all the characters and also says:
                (ASCII codes 0 through 31 inclusive and 127)
  <sp>     ::= the space character (ASCII code 32)

From this information I think that it is safe to say that the NULL
character can be passed as data, but must be preceded by the "\"
character.

Anybody disagree?

Rich 

******************************************************************
Rich Verjinski    The MITRE Corporation  rich@gateway.mitre.org
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Aug 1990 16:14:56 PDT
From:      Ken Harrenstien <klh@NISC.SRI.COM>
To:        primerd!ENI!S61!JB@bloom-beacon.mit.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: An SMTP Question
    I have an SMTP implementation that may or may not have a problem concerning
    null characters in the mail data.  RFC 821 states that the mail data may
    contain any of the 128 ASCII character codes.  This statement implys that
    the null character must also be handled as mail data.  Is this correct.

Yes, that is exactly what the RFC means.  Correct implementations do exist.

--Ken
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 90 10:29:32 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   bulletin boards systems


what bboards systems interfaces
do people use out there?...we currently use 
notes & bbc (mh based)....

thanks

jon 

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 90 11:03:00 GMT
From:      primerd!ENI!S61!JB@bloom-beacon.mit.edu
To:        tcp-ip@nic.ddn.mil
Subject:   An SMTP Question

I have an SMTP implementation that may or may not have a problem concerning
null characters in the mail data.  RFC 821 states that the mail data may
contain any of the 128 ASCII character codes.  This statement implys that
the null character must also be handled as mail data.  Is this correct.

I spoken with some people about this and they do not know of any implementation
that supports this.  We have a customer who feels this is a problem.  The
mail text with a null will truncate that line of the mail data since we
are using C string functions.  Any comments or pointers will be appreciated.

-------------------------------------------------------------------------------
John Bradley
UUCP: csnet-relay!s61.prime.com!jb
Internet: jb@s61.prime.com
Disclaimer: These opinions are my own and not my employers.
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Aug 90 18:20:46 PDT
From:      postel@venera.isi.edu
To:        rich@gateway.mitre.org, tcp-ip@nic.ddn.mil
Subject:   An SMTP Question

Richard Verjinski:

Sure do disagree.

Read the first paragraph under the DATA command on page 21 of RFC-821.

The syntax you cited applies to the "header fields" of 821 not to the
mail data.

--jon.
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Aug 90 16:37 EDT
From:      Leonard N. Foner <Foner@YUKON.SCRC.Symbolics.COM>
To:        primerd!ENI!S61!JB@bloom-beacon.mit.edu, tcp-ip@nic.ddn.mil
Cc:        Foner@YUKON.SCRC.Symbolics.COM
Subject:   An SMTP Question
    Date: 6 Aug 90 11:03:00 GMT
    From: primerd!ENI!S61!JB@bloom-beacon.mit.edu


    I have an SMTP implementation that may or may not have a problem concerning
    null characters in the mail data.  RFC 821 states that the mail data may
    contain any of the 128 ASCII character codes.  This statement implys that
    the null character must also be handled as mail data.  Is this correct.

    I spoken with some people about this and they do not know of any implementation
    that supports this.  We have a customer who feels this is a problem.  The
    mail text with a null will truncate that line of the mail data since we
    are using C string functions.  Any comments or pointers will be appreciated.

    -------------------------------------------------------------------------------
    John Bradley
    UUCP: csnet-relay!s61.prime.com!jb
    Internet: jb@s61.prime.com
    Disclaimer: These opinions are my own and not my employers.

The Symbolics Lisp Machine implementation supports NULs in messages just
fine, thank you.  Only languages which try to use NUL as an end-of-string
indicator, rather than representing strings using counts, tag bits, or both,
should suffer from this problem.

Of course, this means that those with mailers           Shh!  Invisible ink!
that can't handle this are doomed to miss some          Don't tell anybody
of the contents of messages certain troublemakers       who uses UNIX or C
might like to send.  Inside this message, for example.  to write mailers!
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Aug 90 11:29:32 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   bulletin boards systems

what bboards systems interfaces
do people use out there?...we currently use 
notes & bbc (mh based)....

thanks

jon 
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Aug 90 17:14:49 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        sdd.hp.com!uakari.primate.wisc.edu!aplcen!jhunix!roskar@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Free and commercial software for FTP/TELNET on the Mac
Just in case my moderately stupid sendmail can't sort out the return address,
I'll send this to the list.  Besides, NCSA and InterCon deserve the plugs.

I got NCSA Telnet from zaphod.ncsa.uiuc.edu via anonymous FTP.  It's in
a reasonably obvious directory.  I've used both self-contained and MacTCP
versions.  Both work well.  NCSA Telnet supports an FTP server, but not a
client.  That means you can Telnet to a place then have it connect back to
your Macintosh via FTP.  So you can't use anonymous FTP.

I'm now using TCP/Connect II from InterCon.  Overall I like it a lot.  It has
everything NCSA Telnet has plus an FTP client, mail, news, and even SNMP.  For
more on it, contact Amanda Walker (amanda@intercon.com or
intercon!amanda@uunet.uu.net).  She helped me decide to buy it and has been
helpful with the many nits I've picked since I got it.

	Bob

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

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 90 17:38:12 GMT
From:      att!cbnewsj!ssid@ucbvax.Berkeley.EDU  (Sameer Siddiqui)
To:        tcp-ip@nic.ddn.mil
Subject:   Billing System for Ethernet
Hi All,

 I am looking for a software package that can provide some
 sort of a billing system for Ethernet Networks. THis may
 be of the type that listens to and counts packets and 
 provides the Bytes sent by workstations etc for billing
 and charge back purposes. I could hack something together
 with the existing stuff but it would be nice to know if
 something like that is commercialy available.

Thanks,
Sameer Siddiqui
HO 1K-613
AT&T Bell Labs, Holmdel, NJ.
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 01:59:58 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.sys.mac.apps,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: NCSA Telnet Setup Keys

>> Aagh!  It's so annoying!  Following on from my posting last week
>> asking if anyone knew how to stop NCSA Telnet 2.3.2 defaulting to ^C
>> ^S ^Q for interrupt/flow control (which conflicts with Emacs)

	It seems to me that what is needed is some way (possibly an
extension to the Telnet protocol?) for the host end to let the terminal end
know that the tty has been put into raw mode.  I don't see any fundemental
reason why this can't be done.  Comments?
--
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!"

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Aug 90 10:39:25 -0400
From:      craig@NNSC.NSF.NET
To:        tcp-ip@nic.ddn.mil
Subject:   on-line copy of IEEE LCN Program

Has anyone got an on-line copy of the program for the 15th IEEE Local Computer
Networks Conference?  If so, could you e-mail it to me?  I want to
add it to the SIGCOMM bibliography.

Thanks!

Craig

craig@bbn.com or craig@nnsc.nsf.net
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue 7 Aug 90 09:50:12-CDT
From:      Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL>
To:        tsuchiya@thumper.bellcore.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: more on growth
I have to agree with your premise that larger network spaces are underutilized.
In the Air Force we use less than 1% of our allocated class B space if you
look at the fact that we just fielded a bunch of concentrators that right
now have at most 20 hosts using the class B network we got for them.  However,
we are subnetting, and hope to get AF bases to use some of that space and
turn in their class Cs if they have them, or just start fresh.  There aren't
too many bases that would need more than one 2000 host subnet (we are subnet-
ting on 5 bits), so that still would mean 3-4% utilization...

And of course the Milnet hasn't even put a 1% dent in the class A network,
and never will.

-Matt

My statements are my own, and not necessarily representative of the time of
day (or the Government either).
-------
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 10:18:19 GMT
From:      oscsunb!manhandler.oar.net!kannan@tut.cis.ohio-state.edu  (Kannan Varadhan)
To:        tcp-ip@nic.ddn.mil
Subject:   How does an application like telnet utilise a multi-homed machine?

We are trying to represent a multi-homed machine in a zone file as a
machine having multiple A records.  We'd like to be aware of the
implications this might have on different application programs like
telnet and ftp.

My understanding is that sendmail, if it detects multiple MXs of equal
weight, picks up one RR at random, and pops the mail over to that
machine.

Is there some such load-balancing feature built onto telnet, ftp, mail
transfer agents etc. when multiple A records for the same FQDN are
seen?  Or, do they pick up the first A record (call it the primary
Address), try it, if it fails, then try the other addresses in the
order specified in the zone file?

Can we rely on named returning all the addresses for a given machine in
the order specified?

Does the answer depend on the version of telnet, ftp, mail transport
agent, named etc. one uses?

The reasoning is that we'd like not to have any load-balancing built in.
We'd like users to try the primary address.  If that fails for some
reasons in the underlying network, we'd like the application to then try
the secondary addresse(es) until all of the addresses have been
exhaustively tried.

For the record, the named that will answer for the multiple A records
will be BIND 4.8.2, the one with the UofToronto mods.  At this point, I
cannot say much about the versions of other application software out
there in the void, but I suspect a little of everything.

Any pointers on which RFCs to look at would be appreciated too,

Please mail me the answers....I'll summarise the replies within a
week.  I would actually be trying some of this by experimentation too,
so I'll post whatever I find to the tcp-ip list,

Kannan
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Aug 90 17:01 EST
From:      Bob Stodola <STODOLA@fccc.edu>
To:        info-vax@sri.com, tcp-ip@nic.ddn.mil
Subject:   Ethernet configuration problem
We have encountered an ethernet configuration problem that we cannot find in
any of the books and our local (DEC) network specialist is unable to shed any
light on.  If anyone has an answer, I would appreciate a direct reply as
I am not on this list.

We have a DESPR (DIGITAL's thinwire repeater) attached to a DELNI which is
attached to a thickwire coax (<300m) via an H4000 tranceiver.  Thinwire devices
on the DESPR segment and thickwire devices on the DELNI can see the rest of the
network, but not each other.  At first we thought this to be a communications
problem between a Silicon Graphics and Sun TCP/IP, but then it happened again
in another location with equipment from Western Digital, MIPS, Xyplex and DEC,
so I guess there is something basically wrong with the configuration.  If any-
one has the answer, I'd greatly appreciate it.

Reply to:
  stodola@fccc.edu               Robert K. Stodola, Manager
                                 Research Computing Services
  Phone: (215) 728-3660          The Fox Chase Cancer Center
                                 7701 Burholme Avenue
                                 Philadelphia, PA  19111
                                 USA

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Aug 90 10:33:14 +0200
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Easing FTP
Often, data made accessible by FTP is too scarcely described.
To some people with only batch access to FTP, getting at the right
directory and filenames with correct syntax may be very difficult and
turnaround time consuming.
It would help them (and the others too) if the procedure were described
in the most precise terms of the FTP commands to use (e. g. cut and paste!).
Thanks for the care.

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD@BLIULG11 on EARN/BITNET
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 14:39:25 GMT
From:      craig@NNSC.NSF.NET
To:        comp.protocols.tcp-ip
Subject:   on-line copy of IEEE LCN Program


Has anyone got an on-line copy of the program for the 15th IEEE Local Computer
Networks Conference?  If so, could you e-mail it to me?  I want to
add it to the SIGCOMM bibliography.

Thanks!

Craig

craig@bbn.com or craig@nnsc.nsf.net

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 15:00:12 GMT
From:      gertjan@westc.UUCP (Gertjan van Oosten)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   WIN/TCP for VMS, ping and privileges

I remember reading in one of these groups (being: comp.protocols.tcp-ip,
comp.os.vms) that some privileges were necessary for the 'ping' command for
WIN/TCP for VMS to be able to be run successfully.
The reason for this, was that ping uses raw sockets to achieve its goal.

What I forgot (to remember and to save) is:

"What exactly are these privileges?"

If someone could please enlighten me, I would be very grateful.

Sincerely,
--
-- Gertjan van Oosten, gertjan@westc.uucp  OR  mcsun!hp4nl!westc!gertjan
-- West Consulting bv, Phoenixstraat 49, 2611 AL  Delft, The Netherlands
--                     P.O. Box 3318,    2601 DH  Delft
-- Tel: +31-15-123190, Fax: +31-15-147889
-- 
-- Gertjan van Oosten, gertjan@westc.uucp  OR  mcsun!hp4nl!westc!gertjan
-- West Consulting bv, Phoenixstraat 49, 2611 AL  Delft, The Netherlands
--                     P.O. Box 3318,    2601 DH  Delft
-- Tel: +31-15-123190, Fax: +31-15-147889

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 18:31:00 GMT
From:      cs.utexas.edu!ut-emx!linus!GLOWWORM.LispM.SLCS.SLB.COM!7thSon@CS.YALE.EDU  (Chris Garrigues)
To:        tcp-ip@nic.ddn.mil
Subject:   IP over ISDN?

I'm trying to get a sense of how close ISDN is to being something out of
which I could get something useful.  We already have a PRI here at work,
and apparently I can get a BRI to my home from Southwestern Bell, but
neither of these are very interesting to me or my users unless it's
possible to run IP over ISDN.

Has a binding of IP to ISDN been defined?

If so, what hardware and software do I need to gateway my Ethernet into
the PRI here at work, and my MacII into a BRI at home?

If not, does anyone know how far into the future we're talking?


Chris
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 19:15:28 GMT
From:      wotk!root@uunet.uu.net  (Superuser)
To:        tcp-ip@nic.ddn.mil
Subject:   detecting peer close()
I have a BSD 4.3 tahoe system and I have the source code.

If I have a connected socket connection, how can I tell
when the other end has done a close()?

As best as I can tell from the source, the bit in so_state
represented by SS_ISCONNECTED is toggled off. Since I have
source is it fair to just check this bit?

Also I am doing non-blocking i/o with read. Would read()
return 0 when the other end closes or -1 with errno set?

Thanks,

Nick Hennenfent				Voice  404 475-2725
Computone Products			FAX    404 343-9735
1100 Northmeadow Parkway		Usenet ...!uunet!wotk!{nickh,root}
Suite 150
Roswell, GA 30076
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 19:17:45 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!NSTN!daniel@ucsd.edu  (Daniel MacKay)
To:        tcp-ip@nic.ddn.mil
Subject:   Wellfleet mailing list created at NSTN
Hello.

NSTN is the regional provider of Internet services for the province of
Nova Scotia, Canada.  We're using Wellfleet Link Nodes (in Canada
called Newbridge 3108s) as the provincial backbone gateway machines.

We haven't found a central source of support or contact for Wellfleet
customers, so we've decided to become one.  NSTN has establised
a Wellfleet interest mailing list.

Please forward subscription requests to 

	wellfleet-request@nstn.ns.ca

and articles to 

	wellfleet@nstn.ns.ca

I'm looking forward to hearing from you.
--
	Daniel MacKay				daniel@nstn.ns.ca
	NOC Manager, NSTN Operations Centre	Voice: 902-494-NSTN
	Communications Services
	Dalhousie University
	Halifax, N.S.  CANADA
	B3H 4H8					uunet!nstn.ns.ca!daniel
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 22:13:22 GMT
From:      corbin@nibroc.Eng.Sun.COM (John Corbin)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Books on RPC programming?

In article <46559@brunix.UUCP> jhc@iris.brown.edu (Jim Coombs writes:
>Do you discuss techniques for getting a server to fork() copies of
>itself, one per client?  I have been looking through the RPC 4.0
>distribution and am beginning to think that the RPC communications
>model has been implemented too strictly to permit the reasonable use of
>fork().  I can modify the code to implement an optional fork, but then
>I find that the server does not shut down when the client shuts down.
>I have no trouble implementing these requirements (e.g., keepalives)
>when working at the socket level.
>
>If you have a way to do this, I would like to hear about it.  Also, if
>you have comments on the RPC communications model, that would be
>interesting.  Perhaps you do this already, but it would useful to
>include a critique of RPC in your book: what is it good for and what is
>it not good for, how should it be improved?

I have not implemented a service that forks copies as you described above
and the book does not specifically discuss this subject.  The book has a
section on implementing your own svc_run() routine and why you might want
to do it.

Something I forgot to mention in my original posting is that the book
is based upong the 4.0 release of the RPC Library and that I am
a novice user of the socket based API.  I typically use the RPC Library
in its vanilla form when programming applications (for portability reasons).

I don't beleive that the RPC model was implemented too tight to allow
the reasonable use of fork().  I don't know if you have already thought of
this, but if you want one server process per client, you could have the
parent process register via the portmapper.  When it gets a request from
a client, it could spawn a child process that would bind to a different
port number than the parent process.  The child would not register itself
with the portmapper.  The child would attach itself to a port using the
necessary socket calls and then pass the socket descriptor into the
svcXXX_create() routine.  The child would specify a zero for the protocol
argument to the svc_register() routine to prevent the child service from
being registered with the portmapper and thus unregistering the parent.  The
child would then return its portnumber to the parent process which in turn
would return the portnumber to the client.  The client would then have to
bind to this portnumber (i.e. passing in a filled in sockaddr_in, including
the port number, to the clntXXX_create() routine.  From then on you should
be able to use the vanilla RPC routines.  One of the advantages of the RPC
library is that it allows you to do your own binding if you don't want to
take advantage of the portmapper.  For those of you that don't want to mess 
around with the socket API, you could register the children using
dynamic program numbers.

A potential problem of having one server process per client is that
you have now limited the number of clients that your service can handle
(bounded by max processes per user).  Another approach is to do dynamic
load balancing on your server by spawning X processes to handle incoming
requests.  Where X is a dynamic variable dependent upon the incoming
request rate (or some averaged value) and of course application specific
information (weighting of remote procedures).  I have not done a rigorous
study on this so I can't give you hard numbers.  Some potential problems
with this approach is that the port can become the bottleneck (if using UDP)
and you will have to modify the svc_run() routine.

An alternative to forking is the use of light weight processes or threads.
When 4.0 first came out, I looked at spawning light weight processes
for every incoming request to a server.  The problem with doing this under
4.0 was that certain system calls would still block the entire server
(i.e. reading data from a disk file).  Sun provided a special library
of non-blocking system calls that could be used but then you had to
modify your application to handle non-blocking system calls.  This could be
a problem if you are using a special purpose library for which you don't
have the source for (ex: ISAM library).  The fix for this is to make
the LWP primitives available as true system calls.  I am just getting
into the issues of true multi-threaded servers and do not have any
examples or insight to provide. 

John Corbin	(jcorbin@Sun.COM)
NFS Group
Sun Microsystems
(These are my opinions and should not be construed as coming from my employer)

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 22:57:56 GMT
From:      ethome.et.iupui.edu!hummer.iupui.edu!StG@iuvax.cs.indiana.edu  (Scott Griepentrog)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA KA9Q
In article <1990Jul26.011643.8982@pmsmam.uucp> wwm@pmsmam.UUCP (Bill Meahan) writes:
>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 develop
>for amateur radio packet radio operations.  Others have found additional uses.
>-- 

Is there C source to said program available?  I need to get an IP driver
working on OS9 in the near future.  Better yet, has anybody already done
this for OS9 (OSK)?  I happen to be using OS9 on a Mega ST - though I
would imagine the ST version mentioned is under TOS.

Thanks-

StG
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Aug 90 6:09:03 EDT
From:      fgan@BBN.COM
To:        tcp-ip@nic.ddn.mil
Cc:        rie@rufvax.ffm.fgan.de
Subject:   TCP/IP and ISDN
Hallo,

is there anybody who has experience with TCP/IP running over
ISDN or who has information about this topic ?

Please send answers to rie@rufvax.ffm.fgan.de

Thanks

Christian Riechmann
co FGAN/FFM
D-5307 WACHTBERG
E-MAIL: rie@rufvax.ffm.fgan.de
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Aug 1990 00:09:52 +0200
From:      Erik Naggum <erik@naggum.uu.no>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: An SMTP Question
In article <130400009@S61.Prime.COM>, John Bradley writes:
> I have an SMTP implementation that may or may not have a problem concerning
> null characters in the mail data.  RFC 821 states that the mail data may
> contain any of the 128 ASCII character codes.  This statement implys that
> the null character must also be handled as mail data.  Is this correct.

That's what the standard says.  I regard it as correct, and sendmail
(et al) as broken.  Yet another design flaw and disregard of standards
in sendmail.  Flame...

> I spoke with some people about this and they do not know of any
> implementation that supports this.  We have a customer who feels
> this is a problem.  The mail text with a null will truncate that
> line of the mail data since we are using C string functions.  Any
> comments or pointers will be appreciated.

I think it's _wrong_ to use C string functions with Internet stuff.  I
made my own string library for use with network stuff.  Would've been
easier to do with C++ than C, but it still works pretty neatly.
((short*)string)[-1] is a length word.  (256 bytes in a string is a
little short of the goal, when RFC 821 says minimum maximum length of
lines is 1000 characters.)  Some very neat and usual expressions don't
work this way.

In fact, I think it's about as appropriate to use UNIX and C standard
ways of doing things with the Internet as it would be with ASN.1 BER,
but it tends to work most of the time, so people don't care.  Aarrgghh!!

[Erik Naggum]  (a.k.a. "that damn purist")

PS: I hope that mailing to tcp-ip and namedroppers is going to get rid
of the ucbvax bogosity of using my Path field in the From header.  Sorry
about the problem.  I didn't know this was done to my articles.
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Aug 1990 00:18:28 +0200
From:      Erik Naggum <erik@naggum.uu.no>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: An SMTP Question
In article <9008061918.AA16065@gateway.mitre.org>, Richard Verjinski writes:
> The MIL-STD-1781 SMTP specification shows the BNF for an SMTP string on
> page 20. 
> 
> <string> ::= <char> | <char> <string>
> <char>   ::= <c> | \<x>
> <c>      ::= any of the 128 ASCII characters, but not any of the <special>
> 		  or <sp>
> <x>      ::= any of the 128 ASCII characters (no exceptions)
> <special>::=  ... the spec shows all the characters and also says:
> 		   (ASCII codes 0 through 31 inclusive and 127)
> <sp>     ::= the space character (ASCII code 32)
> 
> From this information I think that it is safe to say that the NULL
> character can be passed as data, but must be preceded by the "\"
> character.
> 
> Anybody disagree?

Yes.  We're talking about RFC 822 message contents, not RFC 821
envelope contents.  I also think it was a bad idea for RFC 821 to
specify its own syntax.

That glorious bogosity award hack called sendmail fails at this, as
well, incidentally.

[Erik Naggum]
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 04:13:50 GMT
From:      usc!samsung!munnari.oz.au!metro!natmlab.dap.csiro.au!megadata!andrew@ucsd.edu  (Andrew McRae)
To:        tcp-ip@nic.ddn.mil
Subject:   RARP and multiple interfaces question.
I have the following configuration:

                   192.1.2
      ----+---------------------------+------- Ethernet #1
         |||                         |||
      +-------+                   +-------+
      |       |                   |       |
      |   A   |                   |   B   |
      |       |                   |       |
      +-------+                   +-------+
         |||                         |||
      ----+---------------------------+------- Ethernet #2
                  192.1.3

Where A is a Sun Sparcstation, and B is a custom box.
Each machine has two network interfaces, onto two
nets (physically and IP-network-number separate). Machine
B wishes to boot from machine A, and may not know its
IP address. So it uses broadcasts RARP on first one
net, and then the other if the first doesn't reply.
The hosts file is:

      192.1.2.1      a1   # Machine A network 1
      192.1.3.1      a2   # Machine A network 2
      192.1.2.2      b1   # Machine B network 1
      192.1.3.2      b2   # Machine B network 2

and the ethers file is:

      xx:xx:xx:00:00:01       a1  # a2 as well
      xx:xx:xx:00:00:02       b1

The question is: Does B have to have two separate Ethernet
addresses so that A can distinguish the RARP broadcasts
on each net? If B has only ONE ethernet address, and it
broadcasts on net #1, will the RARP server (rarpd on Sun) be
smart enough to know that it shouldn't reply with an IP
address that doesn't match the network the broadcast came in on?
Or doesn't it care?

If B has two ethernet addresses, then the problem is solved,
but I know there is some confusion about whether it is `the
right thing' to have the same ethernet address on all
network interfaces, or whether it is correct to have
different ethernet addresses on each interface. Some
boxes (I think Suns fall into this category) don't have
a separate ethernet address PROM for each interface, but
only have a master PROM.

Thanks,

Andrew McRae			inet:	andrew@megadata.mega.oz.au
Megadata Pty Ltd,		uucp:	..!uunet!megadata.mega.oz.au!andrew
North Ryde  2113		Phone:	+61 2 805 0899
NSW    AUSTRALIA		Fax:	+61 2 887 4847
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 07:55:38 GMT
From:      usc!jarthur!elroy.jpl.nasa.gov!suned1!efb@ucsd.edu  (Everett Batey)
To:        tcp-ip@nic.ddn.mil
Subject:   WIN MPE, how to SMTP inward
Two tries at the manual .. and still no luck sending mail via a WIN/TCP
MPE/V ( HP3000 ) gateway.  Trying to send SMTP to a user on an MPE/V
host which seems to answer SMTP. The hosts I have tried have included
the gateway and local hosts.  A typical failure was a user, me, on
HPDESK as Everett F BATEY / TSTSTE / 00 by way of the gateway, 
BLD363.NSWSES.NAVY.MIL .. have been using excaped percent sign separated
BATEY\%00\%TSTSTE@BLD363.NSWSES.NAVY.MIL .. I have also per the book,
tried shortened names without the local/sublocal addresses and all I
ever see is User Unknown when I do sendmail -v to the address .. I have
tried all sorts of guesses at how MPE could have the usernames, all to 
no avail .. 

Any MPE - WIN/TCP users out there ??? /Ev/

-- 
 +  efb@suned1.nswses.Navy.MIL efb@elroy.JPL.Nasa.Gov  efb@voodoo.bitnet  +
 +  efb@suned1.UUCP | Gold Coast Sun Users | Vta-SB-SLO DECUS |  WA6CRE   +
 +  Statements, Opinions, MINE, NOT Uncle Sam_s | News Postmaster DNS guy +
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 10:09:03 GMT
From:      fgan@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and ISDN

Hallo,

is there anybody who has experience with TCP/IP running over
ISDN or who has information about this topic ?

Please send answers to rie@rufvax.ffm.fgan.de

Thanks

Christian Riechmann
co FGAN/FFM
D-5307 WACHTBERG
E-MAIL: rie@rufvax.ffm.fgan.de

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 14:30:12 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!spdcc!merk!alliant!linus!linus!mbunix.mitre.org@ucsd.edu  (Gibbons)
To:        tcp-ip@nic.ddn.mil
Subject:   looking for info on IBM TCP/IP for MVS

I would like to talk with anyone having experience with the
IBM TCP/IP product running on a large scale MVS host.
If you know a site running the product please e-mail me.
Thanks -- Chuck


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Charles J. Gibbons              ARPA: gibb@mitre-bedford.ARPA
The MITRE Corporation                or  cjg@mitre-omaha.ARPA
1510 Wall Street              USENET: linus!mbunix!gibb
Bellevue, NE  68005        Phone: 402/292-5889 or AV 271-4125
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 14:59:33 GMT
From:      sdd.hp.com!usc!venera.isi.edu!gremlin!nrtc.nrtc.northrop.com!wdarden@ucsd.edu  (Bill Darden <sdd.hp.com!usc!venera.isi.edu!gremlin!nrtc.nrtc.northrop.com!wdarden@ucsd.edu>)
To:        tcp-ip@nic.ddn.mil
Subject:   IP for IBM S-38's and 400's?
Hi all,

I would appreciate TCP/IP hardware and software recommendations for
IBM S-38 and 400's.

Thanks,

BiLL.....

(213) 541-2020
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 17:35:56 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!ut-emx!ibmchs!auschs!awdprime!elric.austin.ibm.com!swise@ucsd.edu  (The Diet Coke Guy)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: detecting peer close()
In article <10@wotk.UUCP> you write:
>I have a BSD 4.3 tahoe system and I have the source code.
>
>If I have a connected socket connection, how can I tell
>when the other end has done a close()?
>
>As best as I can tell from the source, the bit in so_state
>represented by SS_ISCONNECTED is toggled off. Since I have
>source is it fair to just check this bit?

Yes, you can use this bit to detect whether the peer is still connected.

>
>Also I am doing non-blocking i/o with read. Would read()
>return 0 when the other end closes or -1 with errno set?

read() returns 0 when you read on a socket that has had the peer do a close().

********
Steve Wise - IBM Advanced Workstation Division - Austin, Tx.
swise@elric.austin.ibm.com
AUSVMQ(SWISE)
uunet.UU.NET!cs.utexas.edu!ibmchs!auschs!elric.austin.ibm.com!swise
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 19:11:36 GMT
From:      harvisr!sob@husc6.harvard.edu  (Scott Bradner)
To:        tcp-ip@nic.ddn.mil
Subject:   time for more router bashing
Well it's that time of year again.  We are getting ready to do another
run of network device tests.  We plan to test four types of devices.

a/ Ethernet to Ethernet local routers
b/ Ethernet to Ethernet local bridges
c/ Ethernet to xx routers
d/ Ethernet to xx bridges
	where "xx" = 4 & 16MB token ring, FDDI, serial link, etc

We plan to test as many Ethernet to Ethernet local routers as we can get
before Interop.  We will post the results just before Interop.

After Interop, we will then test the other devices.

For the Ethernet to xx type devices we want to do a simple (for us) setup:

              -----             -----
    ==========| D |xxxxxxxxxxxxx| D |==========
              -----             -----
  where ==== is an ethernet
        xxxx is the other type network

We would then test between the Ethernets.  i.e. we are not ready to
generate FDDI & count FDDI packets.  This may or may not yield useful
information where "xxx" = FDDI.

The tests will include as many protocols as we can do, at least TCP/IP
and DECNET, with IPX & AppleTalk Phase II on the short list.

We want to do the range of tests that the IETF Benchmarking Methodology
Working Group is recommending.  This includes:
	device throughput at various packet sizes
	a graph of output vs input from  0 pps to max legit pps
		for packet size on network
	effect of 1% error packets on throughput
	effect of various filtering options on throughput
	device latency
	bidirectional throughput
		(send equal # of packets through the device from
		 each side)
	throughput with multi channels of data through multi-port device

There are other tests that the WG is looking at that are not yet defined
enough for us to do yet.  If you want to join the WG mailing list send a
request to "bmwg-request@harvisr.harvard.edu".

We expect to get some of the tests done before Interop the rest after.

Now here is why this is being posted:

a/ If you build a bridge or router that you are willing to have tested (abused?)
   please send me a note.  Since we will only be doing the Ethernet
   to Ethernet local routers before Interop, please hold off on the
   notes about the rest until after Interop.
	The testing will start the week of Aug 20th.
   We will want the router(s) { we are willing to do more than one
   type per vendor } for a few days. The ideal is to have a vendor
   person come and set things up (so we don't get it wrong somehow)
	{also I don't want to read that much documentation all at once}

   NOTE: All test results on this first batch will be made public,
   after Interop we may be willing to do tests on prototype devices
   where the results are private, but ONLY for prototype devices.
   We do want to encourage the development cycle but not to encourage
   vendors suppressing information.

b/ If you have an opinion on the tests described please let me know
   what it is (There may be no way to do the test that you would
   like, but it is useful to know if we are off the mark.

If there is an interest in another testing & results talk at Interop like
I did last year & someone manages to reserve a space, I'll be glad to get
something ready.

PLEASE send mail directly to me (sob@harvard.edu).  I'm going off for
a week in sunny New Orleans for SHARE (the IBM user's group) and the
newsgroup(s) will have expired by the time I get back. (not enough disk
space).  Do not expect any reply until I get back.

   ----- please don't call, I will not be in for a week and a half
	and don't want my voicemail to overflow.

		Scott Bradner
		Dan Lanciani
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 20:41:57 GMT
From:      jhc@m2jhc.uucp (James H. Coombs)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Books on RPC programming?

In article <140323@sun.Eng.Sun.COM> corbin@sun.UUCP (John Corbin) writes:

>I don't beleive that the RPC model was implemented too tight to allow
>the reasonable use of fork().  I don't know if you have already thought of
>this, but if you want one server process per client, you could have the
>parent process register via the portmapper.  When it gets a request from
>a client, it could spawn a child process that would bind to a different
>port number than the parent process.  The child would not register itself
>with the portmapper.  The child would attach itself to a port using the
>necessary socket calls and then pass the socket descriptor into the
>svcXXX_create() routine.....

This is interesting.  From my perspective, however, I have not gained
much by using RPC if I have to go do this much work at the socket
level.  In part, my evaluation is due to the fact that I frequently
send lists through the network.  RPC's ability to send and reconstruct
lists is attractive in some ways, but I really need Inheritance C
objects, not C structures.  So I have to traverse the list, build a new
list of objects, and free the memory from the original list.  I don't
really consider this a criticism of RPC, but it does limit its
utility.  It's just much simpler to read data from a socket into local
variables, allocate an object, and then initialize the object with the
data.  If I have to deal with sockets anyway, then I may as well do the
whole thing with sockets.  I say this not to convince anyone of
anything in particular, just to expose a line of reasoning that may be
interesting to others.  Happy to hear what I have forgotten, missed,
etc.

>An alternative to forking is the use of light weight processes or threads.

This too is interesting.  I am using c-tree.  I do have the source
code, but I cannot spend a lot of time making modifications.  The other
major problem with LWP is its (current?) lack of portability.

Thanks for the discussion.  --Jim

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 22:22:41 GMT
From:      elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!bill@decwrl.dec.com  (Bill Daniels)
To:        tcp-ip@nic.ddn.mil
Subject:   does anyone have timed source?
I am in dire need of the timed source.  We use mainly DEC machines and DEC
didn't see fit to include timed in their ultrix distribution.

I remember seeing something about a different time server protocol (tcp-ip
novice here) that has advantages over timed.  Can anyone furnish details
or sources.

Our site does not have access to the Internet so any archive sites would 
have to allow mail connections.

Also, a telephone number was posted recently for the "Naval Observatory??"
dial-in ULTRA-clock.  There was supposed to be access to an async serial
data stream that provides a means for a computer to grab an accurate time.
Does anyone remember or know the telephone number?

bill daniels
-- 
bill daniels
federal express, memphis, tn
{zardoz!dhw68k,mit-eddie!premise}!fedeva!bill
bill@fedeva.UUCP
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 22:33:19 GMT
From:      uc!shamash!timbuk!cs.umn.edu!dmshq!com50!quest!pwcs!intern!markh@tut.cis.ohio-state.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Connecting stuff via telnet servers

	We just picked up some CMC TranServer telnet servers here, and they
work just great as terminal servers, but we also want to run modems and 
printers off of them.  What I'm looking for is information on how to configure
te modems (all Trailblazer+), the servers, lp{r,d}, and uucp to work together.
Any ideas, suggestions, experiences?
	
Mark Holden
markh@pwcs.StPaul.Gov (UUCP)	City of St. Paul,  Public Works
holdenm@thor.acc.stolaf.edu	25 West 4th St Room 700
(612) 292 - 6009		St. Paul, MN  55102
No user servicable parts, refer servicing to authorized service personnel
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 90 23:51:38 GMT
From:      gauss.llnl.gov!casey@lll-winken.llnl.gov  (Casey Leedom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for a few good terminal servers ... (summary) (long!)

  I'd like to thank everyone who responded to my posting regarding our
need for a really good terminal server.  We've decided on a Xylogics
Annex IIe because it comes closest to satisfying all our needs.  Note
that this is not a negative comment on the other terminal servers
described herein: our needs were very stringent (perhaps even
excessive).  I think that many people would be happy with other terminal
servers.

  First, a copy of my original posting:

| From: casey@gauss.llnl.gov (Casey Leedom)
| 
|   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.

  And now the responses.  My comments are contained in double brackets:
[[ ... ]].

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

Date: Mon, 23 Jul 90 21:47:15 EDT
From: latzko@elbereth.rutgers.edu (Alex Latzko)

I would suggest you take a look at the cisco sts-10x.  If fulfills most if
not all of you wants except for #18 dialback.

If you can live w/o full hardware flow control it will do you fine. It can
only be controlled by the remote end modem, but it has been my experience
( 16 V.32 and some tb+ ) you really can't overrun its input ports 

[[Our use is going to include a lot of file transfer and graphics --
including grabbing bitmaps from remote terminals.  This combined with the
fact that some times remote net connections hang for short periods of
time almost demand flow control in both directions.  I think it's
somewhat silly to cheap out on providing one RS232 signal that's
potentially so valuable when one of the major jobs of a terminal server
is dealing with RS232 robustly ...]]

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

Date: Mon 23 Jul 90 19:24:35-PDT
From: William "Chops" Westfield <BILLW@mathom.cisco.com>

I think you are more or less out of luck.  Here is the data for cisco
terminal servers, though - I think we come close...

[[And indeed they do.  They came in second *for our use*.  Thanks Bill
for a great response!]]

    1.	There shall be a minimum of eight (8) EIA232 serial interfaces
	and one (1) Ethernet interface.

Our 10 port box would suffice.

    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.

This can be done.  We don't have the guts to drive all the lines
continuously and simultaneously at 38.4kpbs (this would be asking quite a
lot - 80k interrupts/second!)

[[Yes, it is and I don't think anyone's terminal server that I got
information on could handle it.  I had to ask though!]]

A larger chassis (eg 16 or 32 lines) can take a 30 MHz 68020 processor,
which might do that.  It would be expensive.  We do have enough umph in
the small box to run all ten lines at somewhere between 9600 and 19200,
although I don't know the exact rate.  Isn't this about the speed
trailblazers run at?  [[Trailblazers yes, Telebit T2500s [current PROMs]
yes.  I haven't seen the new 6.00 PROMs yet, but they're almost sure to
go up to 38.4Kbps because of the V.42bis support.]]

    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.)

We support DTR/CD and CTS simultaneously.  This is enough for the modem
to flow control the terminal server.  Typically, there is no need for
flow control in the other direction - the terminal server has a full page
interrupt level buffer, and is pretty quick...

[[See comments above on Alex Latzko's letter.  Full flow control was one
of the reasons we ended up deciding on the Annex IIe over the Cisco.  For
those whose needs aren't quite as demanding as ours, the Cisco would
probably be a fine choice.]]

    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.

Doable.  BREAK can still be used as an escape character.  It would be a
minor software modification to support 8bit clean + BREAK transparency.

[[Not having BREAK be transparent shouldn't be a major problem since it's
not clear what data character should be transmitted across an
rlogin/telnet session in response to it.  I suppose the terminal server
could send a settable interrupt character with the TCP URGENT or OUT OF
BAND bit set ...  Whatever.  Other terminal servers described below are
also not transparent to BREAK.]]

    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.

    9.	Shall respect ICMP redirects.

Does all of these.

    8.	Shall listen to RIP for routing information.

This is contrary to the recommendations of the hosts requirements RFC, and we
have no plans of doing it.  We do support "proxy arp", and are planning on
support for a router discovery process.

[[We've had this argument with Cisco before, so I won't go into it in too
much depth.  The name of the game is interoperability.  RIP *is* bad.  So
what?  It's in use in too many places (including here) to ignore.  Cisco
would make a lot of customers happy if they'd just give in and add RIP
support to their products.  You'll be able to take it out again in a
couple of years when the customer base needing it dies away.  This is
something that Cisco has spent more time and effort fighting than would
have been required to have implemented it and generated good customer
vibes.

This was another reason why we chose the Annex IIe over the Cisco.]]

   10.	Shall incorporate Van Jacobson/Michael Karels TCP/IP
	improvements: Slow start, retransmit timing, round trip timer,

Has karn/jacobson retransmit timing and round trip timer.  Slow start is
not particularly applicable to terminal servers.  Our ACK/WINDOW/Segment
size strategy is compatible with this algorithm (watch out for terminal
servers that advertise very small windows or segment sizes!).

[[Some of our people will be dialing in to the terminal server and then
connecting up to hosts all across the InterNet (one of the reasons we
want passworded logins.)  If we're doing file up loading, won't slow start
be applicable?  I'm very vague in this area, so I might be totally out to
lunch.]]

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.

We do the latter.  We invented the concept.  Addresses can be selected by
the user, and are subject to authentication.

   12.	SLIP with header prediction (RFC1144).  More performance...

We are thinking about this one.  So far, there wouldn't be much for us to
talk to.  The same is true of PPP, in its various incarnations.

   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.

Done.

   14.	Respond to ICMP ECHO requests.  Useful for determining if the
	terminal server is up, etc.

Done.  Also has built in PING command and TRACEROUTE capability (available
from "enabled" mode) and extensive debugging facilities.  You can also
telnet into the terminal servers and issue any commands (fully implemented
pty equivalents, with access control and login capability, of course.)

   15.	AppleTalk/EtherTalk gateway capabilities.

Aysnc Appletalk support is something under consideration.

   16.	More than eight (8) EIA232 serial interfaces.  We might want to
	expand the modem pool in the future.

3 models available now: 10 ports, 16-32 ports, 16-96 ports.  The 16-32
port box with 32 ports is about the same price/line as the 10 port box,
and you could get that 30 Mhz 68020 I was talking about.  It is worth
noting that our 10 port box is running out of room for new software
features.  Things "under consideration" may not make it onto that
hardware platform.  You can alway use extra ports for local terminals
or async printers...

   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 ...

Hmm.  There is some small chance that we could support a top speed other
than 38.4.  Not much.  We would have to see more demand for it.  For
quite a while, I'd expect "burst of 57.6k" to get smoothed out to less
than 38.4k average, by the modems.  In order to get much use out of that
sort of speed, you are probably talking about applications where average
throughput is more important than burst throughput anyway.

[[I'm sure that you're right.  It was a fantasy desire.]]

   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.

Under consideration.  You can go a long way by toggling DTR and supporting
"ATDTphonenumber"...

   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.

LAT is available now.

Other intersting things available now or soon:
=============================================

Extended security features: support for full audit trail (including
connections) from login to logout.  Per-user access-lists.  SLIP allowed
only for certain users.  unix wtmp format accounting output.

Interfaces other than ethernet (token ring, sync serial)

Separate access control for incoming and outgoing connections.

"one word" connection capability.

Other things under consideration:
=================================

XRemote: NCD's scheme for compressing X packets (similar to Jacobson TCP
	 compression.)  Use X terminals at home.

TN3270:	 Talk to IBM systems.

Security: kerberos, "smart card" security services.

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

From: Pushpendra Mohta <pushp@CERF.NET>
Date: Mon, 23 Jul 90 19:53:48 PDT
Organization: CERFnet, La Jolla, CA

In a word , get the cisco terminal server.  For routing needs get the
TRouter product.

[[Never heard of the ``TRouter product.'' What is it and what does it
have to do with a terminal server??]]

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

From: Bob Stewart <stewart@xyplex.com>
Date: Tue, 24 Jul 90 09:37:08 EDT

{Fair warning:  I'm an architect-type engineer who doesn't work directly
on terminal servers, so I can be amazingly ignorant of practical details.}

You should probably take a look at the Xyplex terminal server.  It's
good, but I know it doesn't meet all your requirements.  Some it may meet
in the future, some probably never.  A guy I just talked to said he
doesn't believe there is one that has all you want.

[[Probably not, but that's why I sent a note out describing the features
we wanted.]]

I know we don't listen to RIP.  There is a significant portion of the
Internet community that believes that is absolutely a wrong thing to do
(balanced by a group that believes it is necessary...).  We support
rlogin, Telnet, binary mode, LAT, SLIP, Domain, SNMP, etc.

[[See comments above on Bill Westfield's letter.]]

Our 16-port unit has an aggregate character throughput of about 21K
char/sec, which won't run 8 38.4K ports flat out.  I know we're working
on software performance improvements, but at some point it takes hardware
changes.

We don't have both modem control and hardware flow control at the same
time.  We're considering it.  We believe the DECserver 300 has the
performance and the hardware signals, but it doesn't have Telnet.  To
remain competitive, that means we probably have to meet those
capabilities when we believe they're going to support Telnet.

If any of this sounds interesting, you can call 508-264-9900, tell them
where you are and they'll fix you up with anything from glossy brochures
to a glossy salesman.  Our Marketing people have some say as to what
Engineering builds, and they do respond to pressure from customers.

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

From: rls@apd.net.com (Richard Siegel)
Date: Tue, 24 Jul 90 08:38:38 PDT
Organization: Network Equipment Technologies

I used to be the product manager for the T2500 when I worked at Telebit,
so I guess I may have some credibility :-)

I now work for N.E.T., which, among other things makes some good terminal
servers! If I can send you a whole set of data, but I guess the first
question is: is this just for TCP/IP or is it for a general DECNET type
environment. Currently we have quite a few (non-LAT) DEC environment
terminal servers, with plans to get into the TCP/IP market later this
year.

Let me know what your needs are, and I can connect you with one of our sales
people.

[[We're interested in TCP/IP and only passingly interested in LAT.
Richard realized this after rereading my original posting and followed up
his original response:]]

I reread the full text of your needs (should have done that before my
first mail!), and I think we will probably have something you'd like
later this year, but your immediate needs may be met by someone like
Datability's Vista box. They are in New York, I think the number is (212)
807-7800.

[[I sent off for information on this, but never received anything.  I
guess some companies just don't like selling things ...]]

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

From: telebit!cec@uunet.UU.NET (Cerafin E. Castillo)
Date: Tue, 24 Jul 90 12:25:17 PDT
Organization: Telebit Corp., Sunnyvale CA 94089

>   10.	Shall incorporate Van Jacobson/Michael Karels TCP/IP
>	improvements: Slow start, retransmit timing, round trip timer,
>	etc.
>
>DESIRED FEATURES:
>   11.	SLIP (RFC1055).
>
>   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.

	You're asking for quite a lot.  The Annex IIe is the best for the
dial-up IP connectivity you want since it include VJ SLIP (CSLIP) AND
PPP in a future upcoming revision of code.  SNMP is already there.  The
only other terminal server I know of which comes close is the one offered
by Cisco.

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

From: bob@MorningStar.Com
Date: Tue, 24 Jul 90 10:47:00 EDT

   DESIRED FEATURES:
      11.	SLIP (RFC1055).
      12.	SLIP with header prediction (RFC1144).

You might as well also spec PPP (RFC1134) while you're at it.  Most of
them will be doing it within a few months anyway.

[[You're probably right.  But since this isn't going to be a formal
spec/bid process, I'll just have to remember to ask.  So far, I don't
think that any of the terminal servers I've received information on
implement PPP yet.  I can't tell for sure because I didn't ask explicitly
for PPP and all I've received are volunteered notes that some are
considering it, etc.]]

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

From: daniel@nstn.ns.ca (Daniel MacKay)
Date: 	Thu, 26 Jul 1990 14:35:50 -0300

I highly recommend the Xylogics Annex IIs.  They're well-built, tech 
support is great, prices are great, and they're very, very smart.

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

From: powell@wraith.wtp.contel.com (Mike Powell "CFS Net Ops)
Date: Fri, 27 Jul 90 10:48:17 EDT
Organization: Contel Federal Systems

Try cisoc STS-10 10 ports all of what you need MSM 32 ports all
of what you need and the ASM 32 port min 96 max all of what you need.

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

From: uunet!dciem!gandalf!carr@lll-winken.llnl.gov (Dave Carr)
Date: Fri, 27 Jul 90 10:22:44 EST

[[This was a response I wasn't exactly prepared for.  I think this is far
more than what we're interested in, but someone will probably find the
very comprehensive description of the Gandalf Switch products interesting
in any case ...  It looks like anyone interested in supporting hundreds
of dialins should take a serious look at this.]]

We make a full line of terminal servers which can support from 8 to 1920
users.  The larger model, STARMASTER, is a data switch with integrated
terminal servers.  Our lower cost entry level switch, ACCESS SERVER,
handles from 8 to 64 users.

Both product lines support:

(a) Dumb subscriber cards (Time division multipled);
(b) Intelligent subscriber cards;
(c) Wide Area cards (stat-mux);
(d) LAT Interfaces;
(e) TCP/IP Interfaces;

In addition, they support switching, contention, modem pools, etc, all the
things one expects from a data switch.

We are a multi-national company with revenues around $170,000,000, direct
sales and support (enough of the sales junk).

> ABSOLUTE MUSTS:
>   1.	There shall be a minimum of eight (8) EIA232 serial interfaces
> 	and one (1) Ethernet interface.

We can support from 8 to 1920 interfaces.  We can support multiple
Ethernet, Stat-Mux interfaces.  Unsure about exact number, but more than
32.

>   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.

This is a slight problem.  Currently we only go to 19200 bps.  However, we
do customer specials.  There exists a customer special to support 38400
bps.  It will probably have to be ported to the latest release.  Also, the
gateway channel cards would need modifications.  

Don't get too worried about specials.  We do lots!  Contact a Gandalf
Sales person, and he will write up a special request and get a quote.


>   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.)

Not sure on this one.  It would have to be one of our intelligent subscriber
cards.  Check with Sales.

>   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.

No problem.  In fact, subscriber could use BREAK or DOUBLE BREAK to either
disconnect or WINK to another session.  We support 4 alternate sessions
per subscriber via WINK.

>   5.	Shall support TCP/IP telnet protocol.  Shall support BSD rlogin
> 	protocol.

Yes.

>   6.	Shall support passworded logins.

To the data switch I presume.  Yes.  Per subscriber, service, etc.

>   7.	Shall use BIND for host name lookup.

Yes.

>   8.	Shall listen to RIP for routing information.

Yes.

>   9.	Shall respect ICMP redirects.

Yes.

>  10.	Shall incorporate Van Jacobson/Michael Karels TCP/IP
> 	improvements: Slow start, retransmit timing, round trip timer,
> 	etc.

Yes.

> 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.

Supports SLIP, but do not know to what degree.

>  12.	SLIP with header prediction (RFC1144).  More performance for the
> 	above ...

No.  Not in current release.

>  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.

No.  I believe the direction here is towards ISO (CMIP/CMOT).  
It too is not yet supported.  We have network management via RS-232.

>  14.	Respond to ICMP ECHO requests.  Useful for determining if the
> 	terminal server is up, etc.

Yes.

>  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.)

No support for APPLETALK.

>  16.	More than eight (8) EIA232 serial interfaces.  We might want to
> 	expand the modem pool in the future.

No problem.  Up to 1920.

>  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 ...

We support 64 Kbps SYNCHRONOUS only, and only on point-to-point connections.
The gateway card would need special s/w to support 64 Kbps.

>  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.

YES!  Chargeable option however.

>  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.

YES!  We have LAT gateway cards.  Actually the same card as Ethernet.
Great for sparing cards.

Now, I don't work in the data switch/terminal server area any more, so my
information may not be accurate.  Best to check with our sales office.

The STARMASTER offers great connectivity, more so than typical terminal
servers.

I take it from your address, you are in California.  Here's our 2 offices
in California.

1065 East Hillside Blvd, Suite 300, Foster City, CA 94404   (415) 571-6100
1    Newport Place,      Suite 800, Newport Bch. CA 92660   (714) 752-8181

Or, e-mail me with specific questions and I'll try and get the answers
right from the engineer.

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

From: Neil Gorsuch <uninet!neil%zardoz.uucp@ICS.UCI.EDU>
Date: Sat, 28 Jul 90 16:16:16 PDT
Organization: Uninet Peripherals, Santa Ana, CA, USA

[[This looks like a very interesting approach, but I have yet to hear
back on a list of questions I had.  I'll try to remember them here and
insert them for your reference.]]

This is a little different that what you were probably thinking, but
we have a SCSI based serial port expansion unit that could hang off of
something like a diskless SLC, or even for that matter, an old 3/50.
For more information, call (800)433-6784 and ask for marketing.  A big
advantage is that it uses the tty drivers already in the workstation
and can therefore do a lot of stuff that ethernet terminal servers
can't do.  Someone here could even probably arrange an eval unit if
you wanted to try it out.  I seem to recall someone saying that you
have almost a 1,000 Sun 3's lying around, maybe this would be a good
use for one.

[[It is different and since UNIX tty drivers are typically pretty bad,
we're a little leery.  I'm working to have hardware flow control made a
standard part of the BSD tty driver which should improve the situation
tremendously.  I think that recent versions of Sun's OS tty drivers
support hardware flow control so this may not be such a bad solution --
except that I think we want a little more oomph than a Sun 3/50 ... :-)

Which versions of SunOS does this device work with and which versions
support *REAL* RTS/CTS hardware flow control?  The tty(4) manual page
from SunOS 4.0.3c seems to imply that CRTSCTS just causes the tty driver
to make RTS follow CTS which isn't at all what we want.]]

>ABSOLUTE MUSTS:
>    1.	There shall be a minimum of eight (8) EIA232 serial interfaces
>	and one (1) Ethernet interface.

Yep [[non-disclosure information deleted]].

>    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.

Current model, 30,000 characters (not bits) per second.  Next month's
model, over 100,000 characters per second.  Baud rates to over 150K baud.

[[Is this synchronous or asynchronous???]]

>    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.)

We already support ALL model signals, including flow control on ALL modem
signals.  Including CD, RTS CTS, DTR, RTS.

>   16.	More than eight (8) EIA232 serial interfaces.  We might want to
>	expand the modem pool in the future.

[[non-disclosure information deleted.  Essentially ``in progress.'']]

>   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 ...

The only reason we stop at 150K baud is that the driver chips we picked
on the first model start looking like triangle waves above that.  We will
also be shipping synchronous versions/expansion upgrades that go up to
European T1 speeds.

[[Neil included large chunks of my posting points and fundamentally said
the following:]]

Whatever you can put in Sunos 4.1 or whatever else workstation you use.
We currently support Sun's, Solbournes, DECstations, VAXstations,
Aviions.  IBM 6000, HP, and NeXT ports are in progress.

[[That is, anything that the host OS supports can be made to work.  Thus
listening to RIP, Domain service, passworded logins, etc. are all host OS
questions.]]

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

From: Robert Claeson <prc@erbe.se>
Date: Tue, 31 Jul 90 08:06:44 GMT

[[Note that Robert is *NOT* an employee of Xylogics.  I had to ask him
because his review of the Xylogics Annex IIe's capabilities was so
glowing ... :-)]]

The Annex IIe from Xylogics.

> ABSOLUTE MUSTS:
>   1.	There shall be a minimum of eight (8) EIA232 serial interfaces
> 	and one (1) Ethernet interface.

The Annex IIe has 16 or 32 RS423/RS232C serial interfaces, one parallel
(Centronics and Dataproducts, software selectable) and one Ethernet or
Token Ring 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.

All serial ports can be individually configured with speeds from 50 up
to 38400 bps. Our experience is that the Annex IIe has enough power to
drive all lines at the top speed.

>   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.)

The Annex IIe (it's not upcoming, it's already here) supports
DTR/DCD/RTS/CTS simultaneously on all serial ports.

>   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.

Supported in the Annex IIe. Users can use the BREAK key to escape out to
the command level of the terminal server.

>   5.	Shall support TCP/IP telnet protocol.  Shall support BSD rlogin
> 	protocol.

[[Redundant information from earlier letters deleted.]]

Both are supported, complete with all options (except for X Display Location).

>  16.	More than eight (8) EIA232 serial interfaces.  We might want to
> 	expand the modem pool in the future.

16 or 32 serial interfaces available. The Annex 3 will have from 8 to 64
(expandable/reconfigurable) serial ports.

>  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 ...

38.4 Kbps is the maximum in the Annex IIe. Don't know about future Annex
models, though...

>  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.

Not supported. We use modems with built-in dial back capabilities.

>  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.

The Annex IIe will support both TCP/IP and LAT later this year. It's a
software-only upgrade.

[[And in response to a letter I wrote Robert:]]

From: Robert Claeson <prc@erbe.se>
Date: Tue, 31 Jul 90 20:15:12 MDT

:   Thanks for the comprehensive answer to my posting.  (Do you work for
: Xylogics?)

No.

: Since you mentioned the Annex III,

Really, Annex *3*. They will switch from Roman numerals to Arabic ones
with the Annex 3.

: do you know what time frame is on availability and what major
: additional features it will have with respect to the Annex IIe?  Just
: curious.

Oh well... The one thing that I know is that it will have two slots into
which one can plug various cards. There will be cards with 8, 16 or 32
serial ports to start with. All with full modem control, of course.
That's about what I know.

: I'm planning on cutting an order for an Annex IIe within about two
: weeks if I can convince management to come up with the money.

I convinced our management by referring to other Annex sites. The Annex
has a tremendously high availability (ours have never failed), and the
best network functionality and administration I've seen. The new software
(5.0.3) supports a macro/menu system, SNMP and a bunch of other neat
stuff. In other words, the Annex'es has paid for themselves long ago when
compared with cheaper terminal servers.

Another thing is that Xylogics has a commitment to LAT and OSI
networking, with the best TCP/IP on the market currently available.  Of
course, simultaneous use of TCP/IP, LAT and OSI will be supported
(according to the salesman I use to speak to). It seems like that one
will need the Annex 3 to get OSI, though. The I, II and IIe models
doesn't have enough CPU power and memory to cope with it (which makes me
wonder how other terminal server vendors intend to put TCP/IP, OSI with
CLNS, CONS, TP0, TP2, TP4, CMIP, VTP and possibly also LAT in the 512 K
other use, and have it run by a cheap 16 bit CPU. I don't trust anyone
but Xylogics when they say that OSI networking, especially when compared
with TCP/IP, is a though application if one wants all the facilities
required by GOSIP/SOSIP/CEN/CENELEC/CEPP or whatever it's called in each
country.

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

From: Jack O'Neil <oneil@Xylogics.COM>
Date: Tue, 31 Jul 90 20:08:09 edt
	
From your posting, it looks like you don't think Annex IIe's are
available.  They had been in short supply but are available through our
distributors now.  Should you decide on an Annex, I know Andataco has the
IIe.  You can reach them at 619/453-9191..

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

From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
Date: Tue, 07 Aug 90 18:01:21 +0100

Casey, I've been on travel for the past 2 weeks, so here's my comments on
your note.  You can probably guess what I'll say:
	 
	 
	 
  ABSOLUTE MUSTS:
     1.	There shall be a minimum of eight (8) EIA232 serial interfaces
 	and one (1) Ethernet interface.

The Annex IIe certainly supports this.  A new model is coming out soon as
well, and it will have more ports at a lower price.
	 
     2.	Serial interfaces shall handle at least 38.4K bits/second on al l
	lines.  If two terminal servers are equivalent in other features,
	the one with the highest throughput (serial and Ethernet) will be
	selected.

The IIe can certainly handle this.  The new model is LOTS faster.
	 
     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.)

The IIe and the new product both support this.
	 
     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.

Yes, the Annexes let you do this.  You can set up the box to do this.
Even so that a connect on the port does a binary TCP open (not even
telnet negotiation if you want).  Break can be used to knock the user bak
to the cli anyways.
	 
     5.	Shall support TCP/IP telnet protocol.  Shall support BSD rlogin
	protocol.

Of course.  And full telnet options as well!
	 
     6.	Shall support passworded logins.

You probably know about the security server.  Not only can you prompt for
anything you want, on port connection, or remote logon initiation, but
also on in bound connection.  And, you an encrypt the security server-annex
transactions so that eaves droppers can't fake requests/responses.
	 
     7.	Shall use BIND for host name lookup.

Of course.  And you can have 2 servers set up in case the first fails.  It
even uses the TTL values on the RR's to cache things.  
	 
     8.	Shall listen to RIP for routing information.

Yes, and this can be disabled as well.
	 
     9.	Shall respect ICMP redirects.
	 
Yes, and ages them if routing is enabled.

    10.	Shall incorporate Van Jacobson/Michael Karels TCP/IP
	improvements: Slow start, retransmit timing, round trip timer,
	etc.

The latest annex code has the full 4.3 Tahoe TCP in it.  Not 4.3 release, but
Tahoe.
	 
   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.
	 
Yup.

    12.	SLIP with header prediction (RFC1144).  More performance for the
	above ...
	 
This runs in house, but isn't the current release.  Expect this and PPP
support by InterOp...

    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.
	 
Yes, and you can set up various community names.  I don't think you can
provide a list of hosts to listen from only, but a weird community name
can do most of what you want, without requiring host info to be kept in
all the servers.

    14.	Respond to ICMP ECHO requests.  Useful for determining if the
	terminal server is up, etc.
	 
Come come now, my dog does this right!

    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.)
	 
Yuk.  There is a way to do this with a Unix program that you can get from
Webster Computer Corp. and running rtelnet on the Unix system.  This maps
the annex RS232 port into a pty like /dev/tty1 or the such, so anything
that you can do with an directly attached Unix RS232 port you can do with
an Annex RS232 port.  We're trying to support this at Ames, though
Appletalk at 9600 is really going to be UGLY!  A better way is to support
Iptalk, and use a a device which talks to SLIP, and thus not have to deal
with Appletalk at all in the server...

    16.	More than eight (8) EIA232 serial interfaces.  We might want to
	expand the modem pool in the future.
	 
Well, it's hard to buy things for just 8 ports anyways.

    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 ...
	 
I don't think you get any kind of good error rate here.  Better to go
with ISDN.  The Xylogics people are working on serial sync capability 
too though.

[[We can only hope that the people at Telebit are also working on this
problem.  Currently the T2500s only go up to 19.2Kbps but with
V.32bis/V.42bis they're going to have to support at least 38.4Kbps (thus
my requirement for 38.4Kbps.)]]

    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.
	 
Since the security server can also net management commands, you should be
able to do this depending on how the modem is configured.  We use this
sort of thing now so that when a user signs on, the security server OK's
him to connect to the annex, but also resets the remote slip address, so
no matter what port he dials into, he gets the same address.  This is
pretty easy since you get the source code to the management utilities and
the security server.

    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.

Also supported in the next release, with a LAT-TCP gateway.  Bletch!

In addition, the annex software slices bread, and I don't think anyone
else has a Unix interface that makes people not have to learn yet another
environment.  We love 'em here.

[[They certainly look like the ticket for us.  I've asked for information
on the upcoming Annex 3 to decide whether we want to wait for that, but
since that's not an announced product, there's not much I'll be able to
say in this summary about it, so I'll end things here.  Besides, this is
already much longer than it should be ...  Casey]]
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 00:41:24 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!deakin.OZ.AU!jgm@ucsd.edu  (John Moorfoot)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Booting DOS machines from UNIX servers
In article <123@bbl.be> caj@bbl.be (Johan Casier) writes:
>does anybody know of a product that makes it possible to boot a
>diskless DOS pc and download PC-NFS from a UNIX NFS server over tcp-ip ?

Dirk Koppen (dksoft@incom.de) has a BOOT-PROM for Western Digital
EtherCard PLUS or 3COM 3C503 cards that will do this.
----------------------------------------------------------------------------
! John Moorfoot   Computing Services, Deakin University, Geelong, Victoria !
! E-Mail jgm@deakin.OZ.AU                                Phone 052 471 545 !
----------------------------------------------------------------------------
--
----------------------------------------------------------------------------
! John Moorfoot   Computing Services, Deakin University, Geelong, Victoria !
! E-Mail jgm@deakin.OZ.AU                                Phone 052 471 545 !
----------------------------------------------------------------------------
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 01:04:12 GMT
From:      pacbell.com!tandem!moe!kevinr@ucsd.edu  (Kevin J. Rowett)
To:        tcp-ip@nic.ddn.mil
Subject:   re: Are Commercial TCPs Berkeley Code Or Custom?

In article <1990Aug1.013502.25874@bellcore-2.bellcore.com>,
karn@envy.bellcore.com (Phil R. Karn) writes:
|> 
|> In article <9007272321.AA09325@asylum.sf.ca.us>, romkey@asylum.sf.ca.us
|> (John Romkey) writes:
|> |> Phil Karn rolled his own [TCP] in KA9Q (he'll correct
|> |> me if I'm wrong).
|> 
|> True. My TCP was written from scratch starting in late 1985. Its first

Not to mention the hundreds of AR people who've tested and improved Phil's
work over the last few years.  KA9Q TCP/IP can't be considered a contribution
by one person, although the orignator does write some very fine code!

N6RCE

|>I *strongly* agree that you can't write a good TCP in a vacuum.

>Phil
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 01:10:22 GMT
From:      pacbell.com!tandem!moe!kevinr@ucsd.edu  (Kevin J. Rowett)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Temperature Protocol

In article <7688@gollum.twg.com>, david@twg.com (David S. Herron) writes:
|> In article <1990Jul26.144406.19495@ux1.cso.uiuc.edu>
kline@ux1.cso.uiuc.edu (Charley Kline) writes:
|> >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)
|> 
|> There's a fairly inexpensive box available for Amiga which encodes and
|> decodes the transmission formats used to send pictures from satellites,

One can buy an adapter for a PC which will receive HF WEFAX for $99.
It produces GIFF files.  Seems like that's a pretty easy way to 
make some data available.

KR
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 03:11:53 GMT
From:      barmar@think.com  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: An SMTP Question
In article <9008061918.AA16065@gateway.mitre.org> rich@GATEWAY.MITRE.ORG (Richard Verjinski) writes:
>The MIL-STD-1781 SMTP specification shows the BNF for an SMTP string on
>page 20. 
...
>From this information I think that it is safe to say that the NULL
>character can be passed as data, but must be preceded by the "\"
>character.

The original question was about mail data.  The BNF you referenced was for
the arguments to SMTP commands such as "RCPT TO:".  SMTP doesn't parse the
data after a DATA command; the only thing that has to be escaped there is a
line containing a single period.  In addition, if SMTP is being used to
transfer RPC-822 messages (the usual case) some of the header fields have
quoting requirements like the ones you described, but there are still no
restrictions on the message body.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 11:15:20 PDT (Thu)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        mtiame!ubeaut!mwp@munnari.oz.au
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: Are Commercial TCPs Berkeley Code Or Custom?
   Date: 1 Aug 90 05:40:34 GMT
   From: decwrl!ucsd.edu!sdd.hp.com!samsung!munnari.oz.au!mtiame!ubeaut!mwp  (Michael Paddon)

   The Berkeley code is not public domain; it is copyrighted by the
   Regents of the University of California. However, the BSD code *is*
   freely available as source. Obviously you can't sell it, but you can
   sell any modifications you make to it.

4 out of 5 network companies do it. I believe that you can sell it;
however, you have to credit the source of the software. Of course,
the difference here is rather a moot point; nobody sells the Berkeley
code without making a bunch of changes too, unless they're selling a
4.xBSD system.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
King Kong died for your sins.
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 11:46:26 GMT
From:      att!devildog!ses15!luis@ucbvax.Berkeley.EDU  (Luis Albisu)
To:        tcp-ip@nic.ddn.mil
Subject:   SENDMAIL saying message being deferred!
I have been experimenting with sendmail for the first time and am running
into a small problem that I'm sure someone can answer right off the top of
their head.  I've networked a SUN workstation and a 3B2/600 using TCP/IP.  
The SUN is running SUN TCP/IP and the 3B2 is running Wollongong TCP/IP 
Rel 3.0.

Whenever I send a messages from the SUN to the 3B it never arrives.  When
I issue the command: sendmail -bp -v, it says that the mail is deferred.  
Mail from the 3B2 to the SUN goes through without any problem.

I've looked in the documentation and find no reference to deferring mail 
under sendmail or sendmail.cf. 

I would appreciated it if someone could point out what's causing this.

Thanks in advance!

Luis F. Albisu
AT&T Federal Systems
EMAIL   - att!ses15!luis  OR  luis@ses15.att.com
ATTMAIL - lfalbisu
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 12:01:17 GMT
From:      psuvm!pmw1@psuvax1.cs.psu.edu  (Peter M. Weiss)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: looking for info on IBM TCP/IP for MVS
Please check the listserv archives on the IBMTCP-L stored at PUCC.bitnet
or PUCC.PRINCETON.EDU.  There are quite a few references to IBM MVS and TCP.

/Pete
--
Peter M. Weiss                   | pmw1@psuvm or @vm.psu.edu
31 Shields Bldg (the AIS people) | not affiliated with PSUVM | VM.PSU.EDU
University Park, PA USA 16802    | Disclaimer -* +* applies herein
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 14:20:00 GMT
From:      primerd!ENI!RELAY!ARIEL@BLOOM-BEACON.MIT.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP and ISDN


There is an internet list for discussion of the use of TCP/IP
and friends on the ISDN.

To subscribe, send a note (content will be ignored!) to:

   TCP-ISDN-Subscribe@List.Prime.COM

and you will be automatically added to the list. Other
correspondence should be sent to TCP-ISDN-Request@List.Prime.COM

Robert Ullmann
Prime Computer, Inc.
Ariel@Relay.Prime.COM
+1 508 879 2960 x1736
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 16:51:31 GMT
From:      sdd.hp.com!elroy.jpl.nasa.gov!suned1!efb@ucsd.edu  (Everett Batey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Serious Routing Problems
In article <9007311833.AA22548@nsipo.arc.> ("Milo S. Medin") writes:
  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.

Milo .. wish we didnt spend so much time 15min to days at a time unable to
get routing off our 137.24 net thru our net 26 VAX .


-- 
 +  efb@suned1.nswses.Navy.MIL efb@elroy.JPL.Nasa.Gov  efb@voodoo.bitnet  +
 +  efb@suned1.UUCP | Gold Coast Sun Users | Vta-SB-SLO DECUS |  WA6CRE   +
 +  Statements, Opinions, MINE, NOT Uncle Sam_s | News Postmaster DNS guy +
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 20:42:28 GMT
From:      mcsun!ukc!axion!vision!ukpoit!ian@uunet.uu.net  (Ian J Spare)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: WIN/TCP Sessions Hanging
In article <1035@cnw01.storesys.coles.oz.au> nigel@cnw01.storesys.coles.oz.au (Nigel Harwood) writes:
>I have sometimes noticed this on our EXELAN TCP/IP running on NCR
>Tower 600 1.03 and Tower 650 2.01.
>

OK !! Some confusion on my part , I have some new info !!

While at a client site I saw the same problem with their PC's ( PCs on WIN and
INET on DPX2 ) the problem must be related to the use of PC-XT's for Telnet.

The silence and few e-mails I received refuting my observations CANNOT be 
correct, this is a general problem effecting use of XT's for TELNET.

I cannot as replicate the problem using rlogin or 286 or 386 PC's. 

The finger of suspicion points firmly at the XT.

Come on netters !!! Loads of people must be able to duplicate this !!! 
Somebody out there knows all about it !!!

  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 -------------------------------
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 90 23:10:27 GMT
From:      logicon.com!tots!tep@nosc.mil  (Tom Perrine)
To:        tcp-ip@nic.ddn.mil
Subject:   KA9Q or PC-NFS?

OK, I'll admit it. I've been watching people asking about KA9Q TCP/IP
for over a year and thinking: "Boy am I glad I don't need to network
any PCs." :-)

Guess what.

I need to find a UDP/IP protocol suite that I can run on a 386 with a
3Com 503(?) ethernet card to allow someone to write a PC application
that can communicate with an application on a Sun via UDP.

Does the KA9Q stuff provide the hooks I need to write my own PC
application that uses UDP? Is it a socket-style interface?

Does Sun's PC-NFS provide such hooks? I don't need NFS, but I know
that NFS is built on top of UDP. Can I get to the UDP interface?

(Sheepishly)
Thanks,
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.
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 90 00:28:24 GMT
From:      CAPUANO%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU ("Vincenzo G. Capuano")
To:        comp.protocols.tcp-ip
Subject:   10BaseT

Hi,
I am looking for Twisted Pair Ethernet hardware products. I would like
to know the name of the companies that sell these products, and also
I would like to know if the SynOptics Model 2530 is a 10BaseT multiport.

Thanks,
Vincenzo G. Capuano

capuano@icnucevm.cnuce.cnr.it

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 90 01:46:09 GMT
From:      shelby!morrow.stanford.edu!Valinor.Stanford.EDU!vaf@decwrl.dec.com  (Vince Fuller)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Serious Routing Problems
-----

Kent,
  To follow-up on Milo's comments about routing protocols - BARRNet has been
running OSPF for several months now and we are pleased with it for a variety
of reasons, one of which being its ability to quickly re-route around failures.
When a line flap occurs somewhere in the system, the OSPF part of
BARRNet recovers quickly and things stabilize within a matter of
seconds. Unfortunately,
the non-OSPF part of BARRNet is not so fortunate - the non-SPF protocols
that it
runs immediately go into hold-down when a line flap occurs, partitioning the
network for the duration of the hold-down period (several minutes). We
find this 
very annoying and is one of the (many) reasons that we have been pushing
so hard
for widespread implementation of OSPF.

	Vince Fuller, BARRNet technical coordinator
	(BARRNet is an equal-opportunity vendor basher)
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Aug 90 01:28:24 MET
From:      "Vincenzo G. Capuano" <CAPUANO%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU>
To:        TCP-IP List <tcp-ip@nic.ddn.mil>
Subject:   10BaseT
Hi,
I am looking for Twisted Pair Ethernet hardware products. I would like
to know the name of the companies that sell these products, and also
I would like to know if the SynOptics Model 2530 is a 10BaseT multiport.

Thanks,
Vincenzo G. Capuano

capuano@icnucevm.cnuce.cnr.it
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Aug 90 12:12:38 EDT
From:      fks@vax.ftp.com (Frances Selkirk)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: WIN/TCP Sessions Hanging

I thought this was the natural result of not properly ending a telnet
session. It has happened with my 286. If I get bumped out of a telnet
session, I always log back in and do a ps to see if there's anything
that needs to be killed.


Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Aug 90 13:09:56 EDT
From:      David T. Miller <dtm@ulana.mitre.org>
To:        tcp-ip@nic.ddn.mil
Cc:        dtm@mbunix.mitre.org
Subject:   PC-NFS for Excelan

Does anyone know of PC NFS package that will run on 
Excelan's LAN Workplace for DOS TCP/IP?

Also, does anyone know of drivers that will support FTPs
PC/TCP over a Excelan 205T Ethernet board.

Thanx.  Please send replies directly to me.


============================================================================
David T. Miller          E-mail:  dtm@mitre.org
MITRE Corporation        Phone:   617/ 271-3993
----------------------------------------------------------------------------
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 90 15:40:59 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 10BaseT
In article <9008100012.AA17850@ucbvax.Berkeley.EDU>, CAPUANO%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU ("Vincenzo G. Capuano") writes:

> I am looking for Twisted Pair Ethernet hardware products. I would like
> to know the name of the companies that sell these products, and also
> I would like to know if the SynOptics Model 2530 is a 10BaseT multiport.

The 2530 is the old LattisNet and is not 10BaseT. Synoptics has not yet
announced any similar 10BaseT product, but they tell us that it's coming soon.
(Is soon next month or next decade? I don't know.)

Synoptics and Cabletron make 10BaseT products which we have found perform well,
but I'm sure that there are many others.

					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.
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 90 16:09:58 GMT
From:      dino!cs.iastate.edu!hascall@uunet.uu.net  (John Hascall)
To:        tcp-ip@nic.ddn.mil
Subject:   Should FTP command SMNT change working dir?

   Well, the subject just about says it all.  (SMNT mounts a file system).
My opinion is that it should NOT change the working directory, but I wanted
to know what was proper/common/expected.  RFC959 did not seem to give adequate
guidance on this point.

many thanks,
John Hascall  /  john@iastate.edu  /  hascall@atanasoff.cs.iastate.edu
Project Vincent  /  Iowa State University  /  Ames, IA
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 90 17:37:39 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!grebyn!yml@ucsd.edu  (Yermo M. Lamers)
To:        tcp-ip@nic.ddn.mil
Subject:   Where can I find sample AT&T Network Streams source code?
I am using SCO Unix System V and their Lachman associates TCP/IP
package which has both the 'socket' and the 'AT&T Network Streams'
programming interfaces.

I have a server/client pair working using the sockets programming
interface. I would, however, like to get a similar server/client pair to
work using the Network Streams interface.

Does anyone know where I can find a sample server/client pair written using 
Network Streams on top of TCP/IP? 

The sample code present in the manuals does not illustrate the specifics of
binding TCP/IP addresses using Network Streams.

E-mail replies to yml@grebyn.com will be greatly appreciated.

Thank you in advance,

Yermo Lamers
yml@grebyn.com
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 90 19:39:04 GMT
From:      zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!perand@tut.cis.ohio-state.edu  (Per Andersson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Software assigned Ethernet Addresses
In article <119@mytardis.UUCP> jb@mytardis.UUCP (John Bartas) writes:
>
>.. build an ethernet board without an address prom and assign the
> address via software,.... no one else that I knew of did it.

There is a norwegian company that does this. On the other hand, they only
make large mini-computers, so every computer has a individual system number.
This gives two bytes in the ethernet address. The last is pointing out the
number of cards in the machine. So there is no problems exchanging a broken
card, which is probably the main reason to do this. ( ethernet does not
imply IP, not that John claimed so, but to save others the time of a posting)

Per
-- 
---
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
perand@admin.kth.se, @nada.kth.se 
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 90 19:48:03 GMT
From:      usc!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!kodak!spoelhof@ucsd.edu  (Gordon Spoelhof)
To:        tcp-ip@nic.ddn.mil
Subject:   Assistance needed - please review
In one of my projects, I am using Sybase on Sun workstations for a distributed
application.  The database physically resides on one Sun 4/490 and the
application runs on Sun 4/SLCs.  The database is approximately 1GByte.  The
4/490 is outfitted with two 1GByte drives - one for database, the other for OS
and space for server based applications.  In the metropolitan area the
network is a collection of T bridged Ether segments.  Remote sites are TCP/IP
connected over leased 9.6Kbps/64Kbps lines via Cisco routers.  In general,
the network is multi-segment, multi-subnetted.

Questions:

    1.  Does anyone operate Sybase over a wide area TCP/IP network?  If
	so what are your experiences?
    2.  Does anyone operate Sybase over a multi-segment (routed) network?
	If so are there any problems?
    3.  Do you see any major flaws?  Is there any way to improve the system's
	reliability?  Performance?

Please send responses back to my E-mail address (spoelhof@kodak.com).

Thanks in advance!

Sincerely,

Gordon Spoelhof,
Computer Technology Consultant
Eastman Kodak Co. - Information Technology Management

Disclaimer:        "Neither my wife nor my employer endorse opinion according
                   to Gordi..."

Internet:          spoelhof@Kodak.COM
Telephone:         716-781-5576
Secretary:         716-724-1365 (Sharon Hancock)
FAX:               716-781-5799
US Mail:           Gordon Spoelhof
                   CIS/ITM 2-9-KO
                   Eastman Kodak Co
                   343 State Street
                   Rochester, NY 14650-0724
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 90 06:47:01 GMT
From:      sunquest!vesta.sunquest.com!gavron@arizona.edu  (Ehud Gavron)
To:        tcp-ip@nic.ddn.mil
Subject:   RIP and EGP and Movies

	   In the new movie Flatliners, after one of the med. students
	becomes brain dead, the other guys say "We lost R.I.P."  Now
	one of you real tcp/ip gurus correct me, but if we're talking
	about crossing the line between life and death, shouldn't they
	be using EGP instead???

	:-) :-)   <--- for the NSP impaired (Network Smilie Protocol)

	Ehud

/----------------------------------------------------------------------------\
| Ehud Gavron, Systems analyst  | gavron@vesta.sunquest.com      (Internet)  |
| Sunquest Information Systems  | uunet!sunquest!gavron          (UUCP)      |
| 930 N. Finance Center Drive   | gavron@lampf                   (BITNET)    |
| Tucson, Arizona, 85710        | (602)722-7546/885-7700 x.2546  (AT&Tnet)   |
|----------------------------------------------------------------------------|
|           your cute quote here                                             |
\----------------------------------------------------------------------------/
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 90 16:18:23 GMT
From:      usc!wuarchive!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!dino!cs.iastate.edu!hascall@ucsd.edu  (John Hascall)
To:        tcp-ip@nic.ddn.mil
Subject:   Magic cookies over Telnet
Greetings again from water-logged Iowa:

   (As you may recall from a previous message) I added the option
XDISPLOC to our Telnet (passes your DISPLAY environment variable to the
remote machine) which is all fine and dandy except that you have to do
an "xhost +remote.machine.foo.bar" before you telnet so the other end
can draw on your local display (bummer!).

   What I was thinking of doing was passing the magic-cookie to the
remote-end through another Telnet option.  Has anyone else thought
about/done this (I didn't find a RFC)?  Does any one have any comments
on the good/badness of this?

   On a possibly related note (if this turns out to be `a good thing')
what is the process for writing a RFC?

As always, many thanks,
John Hascall  /  Project Vincent  /  Iowa State University  /  Ames IA
john@iastate.edu  /  hascall@atanasoff.cs.iastate.edu
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 90 16:43:36 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!uflorida!mephisto!prism!gs26@ucsd.edu  (Glenn R. Stone)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Magic cookies over Telnet
In <2432@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes:

> What I was thinking of doing was passing the magic-cookie [DISPLAY variable]
>to the remote-end through another Telnet option.  Has anyone else thought
>about/done this (I didn't find a RFC)?  Does any one have any comments
>on the good/badness of this?

This smells more like what rlogin does...  Telnet doesn't need to be passing
environment variables, since I might (and do, occasionally) be telnetting
to a VMS machine, or (angels and ministers of grace defend us) a CYBER...

Rlogin's Bugs section in TFM already says it should propogate more of the
environment... how much more is open to debate, but it already says that
rows and columns are supported on some systems.... hmmm.. p'raps there
is a need for xrlogin, to propogate such neat things as color, stty settings,
etc?  I don't think all this info needs to be in the standard package, 
simply because the vast majority of what's going on out there is still being
done on damn-3a's and Real PC's with a serial port out the back. (you wouldn't
believe the number of old 4.77mHz boxes still being pounded on every day on
this campus... but I digress.)

If the env-variable passing is already there, it shouldn't be too hard to
extend rlogin into xrlogin, and drop One More File into ..../contrib...

-- Glenn R. Stone
gs26@prism.gatech.edu
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Aug 90 09:03:05 -0500
From:      dab@berserkly.cray.com (David Borman)
To:        tcp-ip@nic.ddn.mil
Cc:        usc!wuarchive!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!dino!cs.iastate.edu!hascall@ucsd.edu
Subject:   Re: Magic cookies over Telnet
>    (As you may recall from a previous message) I added the option
> XDISPLOC to our Telnet (passes your DISPLAY environment variable to the
> remote machine) which is all fine and dandy except that you have to do
> an "xhost +remote.machine.foo.bar" before you telnet so the other end
> can draw on your local display (bummer!).
> 
>    What I was thinking of doing was passing the magic-cookie to the
> remote-end through another Telnet option.  Has anyone else thought
> about/done this (I didn't find a RFC)?  Does any one have any comments
> on the good/badness of this?

> As always, many thanks,
> John Hascall  /  Project Vincent  /  Iowa State University  /  Ames IA
> john@iastate.edu  /  hascall@atanasoff.cs.iastate.edu

There is a new telnet option, the "Telnet Environment Option" that allows
you to pass arbitrary information between the two ends of a telnet
connection.  It has not been issued as an RFC yet (but will be real
soon...), but it is available from the internet-drafts directory on
various machines.  This option was designed with this sort of thing
in mind, to help keep down the proliferation of telnet options.  The
XDISPLOC option could have been implemented using the ENVIRON option,
(but the ENVIRON option wasn't defined yet...).

			-David Borman, dab@cray.com
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 90 05:04:04 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!sloth.mlb.semi.harris.com!jdr@ucsd.edu  (Jim Ray)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP solutions for the HP-3000
Sorry for the delay, but things have been crazy at work.

I received many responses from my earlier post concerning TCP/IP solutions
for the HP-3000.

The following response sums it up:

> From: Walter Underwood <wunder@hp-ses.sde.hp.com>
> 
> Talk to The Wollongong Group.  I think the product is called WIN/H3000.
> It uses the HP-written TCP/IP in the MPE kernel, and adds the basic 
> services.  Current releases of MPE talk Ethernet in addition to 802.3,
> but you may need to enable it.
> 
> It should work fine with other systems, though you will need to put
> the other addresses into the MPE network directory (local equivalent
> of a host table).  Because the terminal interfaces on the 3000 are
> half-duplex, the TELNET client is half-duplex.  Don't expect to login
> to a full-duplex host from the 3000 and enjoy it.  The terminal
> hardware just won't support it.  I'm pretty sure that the MPE/XL
> machines have full-duplex terminal support, so things wil get better
> in the future.
> 
> Walter "a TCP/IP user, not an MPE user" Underwood

I'm now off talking to Wollongong about the possibility of having the
HP run DNS ( Domain Name Services ) for host name lookups.  Initial
repose from the Wollongon sales-person was "I'm sure we have it ".  I'm
not quite so confident. If I find anything else out, I'll post.


Many thanks to:
     Walter Underwood <wunder@hp-ses.sde.hp.com>
     Harry Page <bbs@actrix.co.nz>
     Craig Warren <ccw@deakin.OZ.AU>
     Walt Howard <howard@ee.utah.edu>
     Ed Alcoff  <oldera@obelix.twg.com>
     Chris Webster <WEBSTER@AC.DAL.CA>
--
Jim Ray                                Harris Semiconductor
Internet:  jdr@mlb.semi.harris.com     PO Box 883   MS 62B-022
Phone:     (407) 729-5059              Melbourne, FL  32901
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Aug 1990 12:21:54 PDT
From:      Ole J. Jacobsen <ole@csli.stanford.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   RFC T-shirts
Hi,

Sorry to bother those of you who already know about this from the IETF
list, but I was told that several RFC authors may not be on that list.

We at Interop Inc. would like to honor the many people who have contributed
to the RFC process over the years. Each author will receive a T-shirt with
their (ONE favorite if there are several) RFC number on it.  I need to know
your RFC number by this Friday, August 17, (if not I'll have to pick one
for you if you are among those who have written several). All shirts will
be XL unless I receive special requests otherwise. (I'll try, but no promises).
The shirts will be ready for INTEROP 90, October 8-12 in San Jose.


Ole J Jacobsen, Editor and Publisher
ConneXions--The Interoperability Report 
Interop, Inc.
480 San Antonio Road, Suite 100
Mountain View, CA 94040
USA
Phone: (415) 941-3399   FAX: (415) 949-1779
ole@csli.stanford.edu

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 90 13:22:51 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Magic cookies over Telnet
In article <12461@hydra.gatech.EDU> gs26@prism.gatech.EDU (Glenn R. Stone) writes:
   In <2432@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes:
      What I was thinking of doing was passing the magic-cookie
      [DISPLAY variable] to the remote-end through another Telnet
      option.  Has anyone else thought about/done this (I didn't find
      a RFC)?

   This smells more like what rlogin does...  Telnet doesn't need to
   be passing environment variables, since I might be telnetting to a
   VMS machine, or a CYBER...

Please don't use rlogin, which is a BSD-centric UNIXism, as a basis
for anything.  Instead, look at RFC1091 terminal type negotiation.
The client might look at the environment to decide how to negotiate,
but it shouldn't assume that the server knows or cares what an
environment is.  Clients on "environment"less machines should know
other ways to find out what terminal types they're to claim to
support.
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 90 14:05:15 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!ssg0!petej@ucsd.edu  (Peter M. Jansson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 10BaseT
According to a local distributor here, SynOptics offers a model 3030
10BaseT chassis, 3333 Retimer, and 3308 10BaseT host adapter (12 ports)
now.  There is no product like the 2530 (integral concentrator) at this
time for 10BaseT.  HP recently began advertising something called an
EtherTwist 10BaseT concentrator; I called for the information and got
content-free glossies, with instructions on obtaining the name of my local
dealer.
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 90 16:00:19 GMT
From:      attcan!lsuc!jim@uunet.uu.net  (Jim Mercer)
To:        tcp-ip@nic.ddn.mil
Subject:   is user@iguana == user@iguana.UUCP or user@iguana.local.domain?
[ Followups to comp.mail.misc, as this issue does not limit itself to one
  area ]

i registered iguana as a name with the UUCP mapping project which i understand
are the maintainers of the .uucp pseudo-domain.  this was done a while ago:

u.can.on.2:#W      iguana!merce (Jim Mercer); Thu Dec 28 00:31:23 EST 1989

recently, i have been receiving mail for user@iguana.???.???.edu,
user@iguana.???.com, etc. etc.

now, what's the deal here?

as i see it someone one on a machine under one of these domains sends mail
to user@iguana (meaning user@iguana.local.domain) but for some reason it
goes to user@iguana.UUCP (and i mean that explicitly as i have seen in the
headers where it changes from iguana.local.domain to iguana.uucp in the
>Received: lines)

is this a TCP/IP MX'er problem?
is this a sendmail problem?
does this happen every time someone sets up a new sub-domain with an
identical name to that of a .uucp site?

thus far i have received around 8 messages this way.

my action so far has been to attempt to reroute the message and inform the
postmasters of the various sites.

i deleted the mail so i don't have an example for you.  if this discussion
still lives and i get another bounced message, i'll post the relevant parts.

-- 
[ Jim Mercer  jim@lsuc.On.Ca  || ...!uunet!attcan!lsuc!jim    +1 416 947-5258 ]
[ Systems Facilitator - Law Society of Upper Canada, Toronto, Ontario, CANADA ]
[ Standards are great. They give non-conformists something to not conform to. ]
[      The opinions expressed here may or may not be those of my employer     ]
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 90 17:32:00 GMT
From:      sdd.hp.com!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Magic cookies over Telnet
In article <12461@hydra.gatech.EDU> gs26@prism.gatech.EDU (Glenn R. Stone) writes:
>> What I was thinking of doing was passing the magic-cookie [DISPLAY variable]
>>to the remote-end through another Telnet option...
>
>This smells more like what rlogin does...  Telnet doesn't need to be passing
>environment variables, since I might (and do, occasionally) be telnetting
>to a VMS machine, or (angels and ministers of grace defend us) a CYBER...

This is why Telnet options are --> options <--, so that systems which don't
understand a particular option can reject it.  Modern telnet can do
everything rlogin can, and better, and it's a documented standard.
-- 
It is not possible to both understand  | Henry Spencer at U of Toronto Zoology
and appreciate Intel CPUs. -D.Wolfskill|  henry@zoo.toronto.edu   utzoo!henry
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 90 19:48:07 GMT
From:      shelby!neon!neon!gumby@decwrl.dec.com  (David Vinayak Wallace)
To:        tcp-ip@nic.ddn.mil
Subject:   Magic cookies over Telnet

   Date: 13 Aug 90 13:22:51 GMT
   From: bob@MorningStar.Com (Bob Sutterfield)

   Please don't use rlogin, which is a BSD-centric UNIXism, as a basis
   for anything.  Instead, look at RFC1091 terminal type negotiation.

Or better, look at protocols like SUPDUP, which gets away from
terminal NAMES and just talks about terminal CAPABILITIES.

It amazed me that when Unix finally got a window system, the first
thing implemented was an emulator for a specific kind of terminal!
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 90 20:23:02 GMT
From:      edsews!edsdrd!man@uunet.uu.net  (Marc Nurmi)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP strangeness
I've set up a dialup SLIP connection between two Suns running
4.1 SunOS, and it has been working fine.  I have noticed, however,
that the Sun that I'm dialed into is sending a bunch of packets 
(45, to be exact) over the SLIP link every 30 seconds.  At first, 
I thought this was routing information generated by gated (which is 
running at both ends), but these packets are still generated, even 
if gated is brought down.

Does anyone know what this information is, and what might be 
generating it???

Also, is there a tool like etherfind available for serial IP links?
"netstat" gives me packet counts for information flowing across the
SLIP link, but I was wondering if there was some way to look at
this information.

Oh, by the way, I'm not sure if it matters or not, but I'm running
the SLIP compression routines (CSLIP), and am using a pair of
Telebit T2500 modems in PEP mode.  My main concern here is that
these unexplained packets appear to be effecting the throughput
of the SLIP link.  Any assistance is greatly appreciated!

-- 
Marc Nurmi - man@edsdrd.eds.com
... uunet!edsr!edsdrd!man
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Aug 90 08:32:30 EDT
From:      fks@vax.ftp.com (Frances Selkirk)
To:        attcan!lsuc!jim@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  is user@iguana == user@iguana.UUCP or user@iguana.local.domain?
The program here for posting news also replaces .com with .UUCP. News is 
the only place I have ever seen this happen. I correct it in the FROM line
while editing my messages. This is not elegant, but it works. 



-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Aug 90 19:58:46 -0700
From:      earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
To:        tcp-ip@nic.DDN.MIL
Subject:   The case of the phantom KEEPALIVEs
I don't want to start the religious war over KEEPALIVEs again, but ...

Has anyone ever run across this kind of behavior?  If so, please respond to
millis%sunpeaks.Central@Sun.COM (a.k.a. millis@sunpeaks.Central.Sun.COM).
BTW, the 2 machines described in question are running SunOS 4.0.3, which I
think has a 4.3BSD-Tahoe-ish TCP (but not all the latest goodies; they were
added in SunOS 4.1).  Thanks.

------- Begin Included Message

I have a Sybase application which fails occasionally because of TCP resets.
Here's the details:

The application is split across 2 machines - client and server.

1- Client (Sun-4/330) negotiates a TCP connection to the server (Sun-4/280)
   (Sybase TCP port)

2- Client uses the TCP connection to send transactions and recieve
   transactions from the server.

3- The connection stays open (by design), even during long periods of idleness.

4- The application sends transactions asychronously, every few minutes
   typically.

5- The above behavior may continue indefinitely; at least it is SUPPOSED to.

6- TCP KEEPALIVE is turned ON on the server, but OFF on the client.
   Therefore, during idle periods, the server TCP sends a KEEPALIVE every 75
   seconds, which the client dutifully acknowledges.

7- HOWEVER, the server TCP occasionally "misses" sending a KEEPALIVE;
   sometimes 1 or more 75-second intervals will pass with no KEEPALIVES seen
   from the server.  Sometimes the KEEPALIVES resume, but sometimes they seem
   to go away permanently.

8- Server TCP seems to believe that KEEPALIVES always go out, even when they
   really don't.

9- After failing to receive acknowledgements from 8 consecutive "phantom"
   KEEPALIVEs, the TCP port on server is abruptly closed.

10- Sometime later, the client attempts to send another transaction.

11- Server TCP responds immediately with a RESET, since the connection no
    longer exists.

12- Client ack's the RESET, and the Sybase application crashes with a
    "connection reset by peer" error.

Thus, if the application routinely has idle periods of longer than 11 minutes,
15 sec (9*75 sec), the application is at risk of being brought down by this
connection reset problem.

Both client and server are running SunOS 4.0.3; a 4.1 upgrade will not be
possible for several months, for other reasons.

The KEEPALIVE idle period and the KEEPALIVE connection timeout are set in
sys/netinet/tcp_timer.h (on Suns): (the defaults have not been changed)

#define TCPTV_KEEP      ( 75*PR_SLOWHZ)         /* keep alive - 75 secs */
#define TCPTV_MAXIDLE   (  8*TCPTV_KEEP)        /* maximum allowable idle

I was told by someone that I cannot change TCPTV_KEEP or TCPTV_MAXIDLE -
changes made to tcp_timer.h will not affect how the kernel makes.

Finally, the questions:

1-      Has anyone seen anything like this?  Why would the server occasionally
        fail to send KEEPALIVES?

2-      I have trouble believing that I cannot change TCPTV_KEEP or
        TCPTV_MAXIDLE (perhaps "cannot" is really "should not"?).
	Is this really true?

3-      I want to increase TCPTV_MAXIDLE, as a Band-aid.  The only
        major sideffect that I can think of is that truly dead connections
        (the machine at the other end has died) will take longer to time out.
        Any other bad side effects?

------- End of Included Message

--
	- Greg Earle
	  Sun Microsystems, Inc. - JPL on-site Software Support
	  earle@poseur.JPL.NASA.GOV	(Direct)
	  earle@Sun.COM			(Indirect)
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 90 10:23:21 GMT
From:      gertjan@westc.UUCP (Gertjan van Oosten)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   WIN/TCP for VMS, ping and privileges [repost]

I remember reading in one of these groups (being: comp.protocols.tcp-ip,
comp.os.vms) that some privileges were necessary for the 'ping' command for
WIN/TCP for VMS to be able to be run successfully.
The reason for this, was that ping uses raw sockets to achieve its goal.

What I forgot (to remember and to save) is:

"What exactly are these privileges?"

If someone could please enlighten me, I would be very grateful.

Sincerely,

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 90 10:52:56 GMT
From:      eru!luth!sunic!mcsun!hp4nl!ooc.uva.nl!matthew@bloom-beacon.mit.edu  (Matthew Lewis)
To:        tcp-ip@nic.ddn.mil
Subject:   University/company wide directory service?
Hello!  We are looking for a way to provide mail directory services for a
private wide-area network, in such a way that a user would be able to type in
a name, and get back the person's mail address.  In addition, or alternately,
to be able to send to an ambiguous address, and have it delivered, or to get
back a message with the correct address.

In the ideal world, there would be a Macintosh and/or PC interface for use
with POP or IMAP.

I saw some discussion over such systems in news a while back, but discovered
(to my horror :-) that I misplaced the messages.

Thanks in advance,

Matthew Lewis
Net Admin, CICT/OOC
Univ. of Amsterdam
-- 
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
+31-20-52 51 220				1013 KS  Amsterdam
Internet: matthew@ooc.uva.nl			The Netherlands
UUCP:	  uunet!mcsun!hp4nl!uvabick!matthew
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 90 11:35:01 GMT
From:      gertjan@westc.UUCP (Gertjan van Oosten)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   WIN/TCP for VMS, ping and privileges [repost]

I remember reading in one of these groups (being: comp.protocols.tcp-ip,
comp.os.vms) that some privileges were necessary for the 'ping' command for
WIN/TCP for VMS to be able to be run successfully.
The reason for this, was that ping uses raw sockets to achieve its goal.

What I forgot (to remember and to save) is:

"What exactly are these privileges?"

If someone could please enlighten me, I would be very grateful.

Sincerely,
-- Gertjan van Oosten, gertjan@westc.uucp  OR  mcsun!hp4nl!westc!gertjan
-- West Consulting bv, Phoenixstraat 49, 2611 AL  Delft, The Netherlands
--                     P.O. Box 3318,    2601 DH  Delft
-- Tel: +31-15-123190, Fax: +31-15-147889

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 90 11:38:36 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!tmsoft!mshiels@ucsd.edu  (Michael A. Shiels)
To:        tcp-ip@nic.ddn.mil
Subject:   Socket interface for Netbios?
Is there any problem increasing the size of the sockaddr structure?  I am
working on a socket interface for Netbios which will allow the full 16 bytes
names.  But the sockaddr structure only has 14 bytes of address? 
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 90 15:40:23 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!ncrcae!wingo@ucsd.edu  (Dave Wingo)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp/ip terminal server request
I am looking for any information you can give me on the terminal server vendorDatability. I know that they relatively new to the tcp/ip terminal business.
Have you had experience with them?
How about in their previous life as LAT terminal server supplier?
 
Any comments would be greatly appreciated... Thanks in advance....

David Wingo - NCR Corp. Phone (803) 791-6476
                        wingo@Columbia.NCR.COM
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 90 20:39:05 GMT
From:      hughes@silver.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: WIN/TCP for VMS, ping and privileges [repost]

In article <1242@westc.UUCP> gertjan@westc.UUCP (Gertjan van Oosten) writes:
>What I forgot (to remember and to save) is:
>
>"What exactly are these privileges?"

SYSPRV does it.

 //=========================================================================\\
||       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...    ||
 \\==========================================================================//

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 90 20:59:33 GMT
From:      van-bc!ubc-cs!alberta!atha!aupair.cs.athabascau.ca!lyndon@ucbvax.Berkeley.EDU  (Lyndon Nerenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Location of in.h in SVR4
Would someone who has access to a machine running SVR4 please let
me know what directory in.h is located in? Thanks.

-- 
     Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
         {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca
                           Practice Safe Government
                                 Use Kingdoms
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 90 22:50:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   any RARP server in public domain?


        Is there any RARP server exist in public domain?
        Please email to me directly. I will summarize if enough interest.
        Thanks.

- Beng Hang Tay (email: taybengh@nusdiscs.bitnet)
  Department of Information Systems and Computer Science
  National University of Singapore
  Kent Ridge
  Singapore 0511
  Republic of Singapore

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 90 02:23:15 GMT
From:      imp@dancer.Solbourne.COM (Warner Losh)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: WIN/TCP for VMS, ping and privileges [repost]

In article <54428@iuvax.cs.indiana.edu> hughes@silver.ucs.indiana.edu
(larry hughes) writes: 
>In article <1242@westc.UUCP> gertjan@westc.UUCP (Gertjan van Oosten) writes:
>>"What exactly are these privileges?"
>
>SYSPRV does it.

You must have CMKRNL and SYSPRV (according to the documentation).  If
it happens to work with just SYSPRV, you may have found a bug.  Future
releases may reinstated the restriction.  For releases prior to 5.1,
it requires BOTH CMKRNL and SYSPRV.  5.1 may just require SYSPRV for
your installation, but it is documented as requiring both privs.  It
is best to follow the documenation.%

Warner
--
% Don't ask me where in the doc set.  I don't work for them
anymore....
--
Warner Losh		imp@Solbourne.COM
Me?  I'm the onion rings.

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Aug 90 14:50 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   any RARP server in public domain?

        Is there any RARP server exist in public domain?
        Please email to me directly. I will summarize if enough interest.
        Thanks.

- Beng Hang Tay (email: taybengh@nusdiscs.bitnet)
  Department of Information Systems and Computer Science
  National University of Singapore
  Kent Ridge
  Singapore 0511
  Republic of Singapore
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Aug 90 18:47:41 -0700
From:      chris@salt.acc.com (Chris VandenBerg)
To:        tcp-ip@nic.ddn.mil
Subject:   problems when using SUN resolver
Good evening folks,
		  I was hoping someone would
help me out with a problem that occurs when
one stops using host tables on a SUN4 and 
installs the resolver. I'm getting name service
quite nicely now but I have an application that
core dumps with the message "call to undefined
procedure _gethostent somehexaddress". Is the 
call different in the libc with the resolver
to get your own address? It seems strange that
it would change.
		thanks in advance,
				chris vandenberg
				chris@salt.acc.com
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Aug 90 16:49:37 PDT
From:      braden@venera.isi.edu
To:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Cc:        iab@venera.isi.edu, iesg@venera.isi.edu, irsg@venera.isi.edu
Subject:   IAB Report for July 1990
The following IAB Report was published in the July 1990 Internet Monthly
Report, which uses a somewhat restricted mailing list.  We are hereby 
sending this same report to the Internet community.

    Bob Braden, for the IAB
    
_________________________________________________________________________

IAB REPORT -- July 1990

The IAB held a two-day meeting at BBN in Cambridge, MA on June 28-29,
1990.  The Internet Engineering Steering Group (IESG) joined the second
day of the meeting.

A. INTERNET NUMBER REGISTRATION AND CONNECTED STATUS

    At this meeting, the IAB developed recommendations to the Federal
    Networking Council (FNC) on the procedures for registration of
    Internet network and autonomous system numbers, and concerning the
    notion of "connected status".  These recommendations, which have
    been published in RFC-1174, were motivated by the increasing
    internationalization of the Internet.  The IAB gratefully
    acknowledges the efforts of Elise Gerich of MERIT, who prepared
    early drafts of these recommendations for our consideration.

    Essentially, the IAB recommended that authority to assign IP
    network and autonomous system numbers be distributed on an
    international basis.  A central registry (Internet Registry) would
    continue to allocate blocks of numbers, to avoid any duplication,
    but actual registration and assignment of numbers would be
    accomplished by delegated registries.  The details of procedures,
    particularly the nomination of delegated registries, remain to be
    fully specified.

    The second recommendation concerned "connected status."  The IAB
    recommended that this concept be retired, and that all networks
    which have been assigned Internet numbers be entered into the
    Domain Name System database(s) regardless of the status of their
    physical connectivity.  In addition, for each network, a statement
    describing the nature of the traffic this network would inject into
    the Internet should be collected and stored by the Internet
    Registry and made available to all interested parties.  This
    information would be used by network managers and operators to
    configure routing controls to accept or reject routes from
    networks, based on the type of traffic each network sends.  It is
    important to note that this concept operates on route set-up and
    not on a per-packet basis.

    The Federal Networking Council has responded positively to these
    suggestions and is now considering various means to implement
    them.

B. ANSI STANDARDIZATION

    Members of the IAB were also in attendance at an ANSI X3S3.3
    meeting held on June 27 at Data General Corporation.  The question
    of introducing the core TCP/IP protocols (IP,ICMP,UDP,TCP) into
    ANSI standardization was discussed at length.  At the conclusion of
    the meeting, the proposal for introduction of the protocols was
    tabled, pending the formation of a joint IAB/ANSI working party to
    consider all of the ramifications that such a move might have on
    both ANSI and IAB procedures and prerogatives.

    The IAB considers it essential, for example, that any changes to
    these core protocols be subject to the same rigorous treatment that
    any Internet Protocol receives.  In particular, implementation,
    testing and the availability of public domain implementations lie
    at the heart of the Internet Protocol standardization process but
    are largely outside the ANSI process. In the usual course of events
    within the ANSI environment, the introduction of a protocol for
    ANSI standardization transfers to ANSI all future authority for
    further evolution of the protocol.  The IAB proposed a modus
    operandi which would leave the basic standardization activity
    within the Internet community, including resolution of any
    objections to standardization arising during ANSI balloting.  Since
    this is not fully consistent with the ANSI rules as we now
    understand them, the matter requires further examination.

C. RARE NETWORKSHOP

    The IAB agreed to participate in the planning of the RARE Networkshop
    now scheduled for May, 1991 in Blois, France.

D. STANDARDS ACTIONS

    Following IESG recommendation, the IAB designated the
    Point-to-Point Protocol (PPP) Initial Configuration Options as a
    Proposed Standard, and it was subsequently published in RFC-1172.
    The base PPP specification, a Draft Standard, was republished with
    minor updates as RFC-1171.

    The Simple File Transfer Protocol (SFTP, RFC-913) and the Resource
    Location Protocol (RFC-887) were moved from Proposed Standard to
    Experimental.  These protocols, which had been labelled Proposed
    prior to last year's tightening of the Internet standards process,
    are not currently in the Internet standards track.
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 90 16:08:39 GMT
From:      rti!mozart!sasjfp@mcnc.org  (Jeffrey L. Phillips)
To:        tcp-ip@nic.ddn.mil
Subject:   GATED source
Does anyone have the source to gated.  I've been looking for it for some time
and only have a mail connection to the net.  So far, I've been unsuccessful.

Thanks in advance.
-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

"Just because I don't know what it means doesn't mean I'm lying." 
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 90 16:49:06 GMT
From:      psuvm!pmw1@psuvax1.cs.psu.edu  (Peter M. Weiss)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet Session Takeover?
We are very concerned about unauthorized and/or illegal use of resources
on our TCP hosts by taking advantage of weaknesses in the TCP
specifications and/or implementations.

For TCP session initiation and for already established TCP connections
to TCP hosts, what will the products do when receiving packets with
acknowledgement sequence numbers greater than expected, including
maximal acknowledgement sequence numbers?

This might occur when an unauthorized client host attempts to spoof an
TCP server host (assume that the client knows the higher level
transaction protocol such as TN3270 and specific transaction dialogues).
How is it possible, for a rogue host, by misrepresenting its IP address
and/or guessing the acknowledgement numbers, to either initiate a TCP
session with various TCP products or invade an ongoing legitimate
session?

Peter M. Weiss,
SE For TP
Penn State University - Management Services
31 Shields Bldg
University Park, PA 16802
814 863 1843
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 90 17:54:09 GMT
From:      att!cbnewsl!sar0@ucbvax.Berkeley.EDU  (stephen.a.rago)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Location of in.h in SVR4
In article <65@aupair.cs.athabascau.ca>, lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes:
> Would someone who has access to a machine running SVR4 please let
> me know what directory in.h is located in? Thanks.

on both my 3b2 and my 386, it's in /usr/include/netinet.

Steve Rago
sar@attunix.att.com
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 90 18:52:49 GMT
From:      att!hriso!devildog!ses15!luis@ucbvax.Berkeley.EDU  (Luis Albisu)
To:        tcp-ip@nic.ddn.mil
Subject:   SENDMAIL DEFERRED MESSAGE ANSWER
Thanks to all of the folks that responded to my message requesting
assistance with the sendmail command.  I was getting a mail is being
deferred message from sendmail.

The problem turned out to be my machine name.  The machine which was
rejecting the mail was called 600g.  Apparently, when a remote machine name
starts with numerics and your local machine send it mail, sendmail sees the
numerics and interprets it.

I saw this when I ran sendmail with the -v command.  As soon as the machine
was renamed to sms600 and the sendmail process was killed and restarted 
the problem disappeared.

Again, thanks to all that helped me figure this out!!!!

Luis F. Albisu
AT&T Federal Systems
EMAIL   - att!ses15!luis   
        - luis@ses15.att.com
ATTMAIL - lfalbisu
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 90 21:31:46 GMT
From:      ibmsupt.uucp!bullhead!brunner@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Token Ring frame sizes?
Michael,

I guess I should have read all three of your postings before replying to the
first one (in the order I received them). I've replied in a seperate posting
to the token-ring analyser query. The first half of this posting is in reply
to the frame-size query (subject line in this posting), the second half to
the source routing query.

I use the Ethernet MTU in the drivers I work on (IBM/4.3 for the RT line, and
OSF/1 for the PS/2), and since the OS/2 ethernet driver is really an (oldish)
IBM4.3 driver, it is possible that their token-ring driver derives from the
same token-ring drivers in use on the PS/2 with a ROMP processor. If so, it
too uses the Ethernet MTU, 1500.

>I believe that most TCP/IP implementations will use Ethernet size frames.
>Am I wrong?

I don't think so, but bear in mind that _most_ of the token-ringers I've
communicated with (in IBM) don't view TCP/IP as their primary suite of
protocols to support and tend to say things like "load balancing and (tcp)
connection management (forcing a re-arp for a route when tcp reports failure,
something Van Jacobson is working on the the current 4.4 post-alpha code)
will be done by NETBIOS", etc., etc.

RFC1042 is being revised, presently there is a "son of 1042" in draft form.

1042 as is on MTU:
- The Maximum Transmission Unit (MTU) differs on the different types of
- IEEE 802 networks.  In the following there are comments on the MTU
- for each type of IEEE 802 network.  However, on any particular
- network all hosts must use the same MTU.  In the following, the terms
- "maximum packet size" and "maximum transmission unit" are equivalent.

Son-of-1042 as is on MTU:
- The Maximum Transmission Unit (MTU) differs on the different types of
- IEEE 802 networks.  In the following there are comments on the MTU
- for each type of IEEE 802 network.  However, on any particular
- network all hosts must use the same MTU.  In addition, if different
- types of IEEE 802 networks are connected via transparent link layer
- bridges, all hosts on all of these networks should use the same MTU.
- In the following, the terms "maximum packet size" and "maximum
- transmission unit" are equivalent.

I think that there will be problems ahead as non-ip token-ring developers
will try to optimize for high-bandwidth applications (video, etc) using
larger frame-sizes. Further complications are in order as source-routing
bridges (a known evil) are replaced with source-routing-transparent bridges
(a recent compromise at the 802 bridge meeting), however, that is seperate
from the MTU issue.

You can expect to see implementations which hold a token for up to 10ms
in the blind pursuit of big frames on what are essentially propriatary
networks.

>I think Novell actually goes up to 4KB frames.  How about Appletalk?

I don't know, there is an appletalk working group in the IETF, the mailing
list is apple-ip@apple.com, subscribe in the usual fashion. This working
group addresses ip/appletalk issues, e.g., ip over appletalk, gateways,
appletalk over ip (for the deranged pranksters) and so forth.


On source routing, first, some document identifiers:

Token-Ring Network Architecture Reference IBM SC30-3374-02, 3rd edition,
September 1989 (my abreviation "TRARCH")
Local Area Network Technical Reference (IBM SC30-3383-2) 3rd edition,
September 1988 (my abreviation "LANTR")

Question 1: Is the length of the routing information field 18? or 30?

Page 2-6 of TRARCH defines the routing information field as a "2-byte
routing control field and up to eight 2-byte route designators". I think
that "bytes" here should be understood to be "octets", but it is clear
that IBM defines the rif as being a variable sized element of the MAC
frame, 2 =< sizeof(RIF) =< 18. What this means in real life is that no
more than 8 bridges in a token-ring. When I last spoke with Radia Perlman
I learned that the number of bridges (equivalent to the size of the RIF)
varies from draft to draft of the IEEE 802.5 working group. I've probably
munged her message, but I'll assume 8 hops max until I learn otherwise.

Because TRARCH defines the IBM token-ring (802.5 with multi-ring extensions
and a presumption of with source route briges, not transparent bridges,
from a host's point of view, I assume that the current and near-future IBM
bridge implementors will discard frames with a larger routing information
field.

Question 2: What is the allocation of bits within each of the eight 2-byte
routes, how many bits designate the bridge and how many designate the ring.

Again, TRARCH, page 2-10. Each ring in a multi-ring network has a unique
ring identifier (12 bits), each bridge has a not-necessarily-unique bridge
identifier (4 bits).

Again, I've cross posted to the tcp-ip list, there are _always_ people who
know more than I do, a fact of life I'm happy with.

P.S. I have to live with the UB implementation of the 802.5 network adaptor,
your milage may vary.
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.
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 90 21:41:06 GMT
From:      ecsgate!stat.appstate.edu!combstm@mcnc.org
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip terminal server request
In article <6444@ncrcae.Columbia.NCR.COM>, wingo@ncrcae.Columbia.NCR.COM (Dave Wingo) writes:
> I am looking for any information you can give me on the terminal server 
> vendor Datability. I know that they relatively new to the tcp/ip terminal 
> business.
>
> How about in their previous life as LAT terminal server supplier?
>
As a LAT server from the first server in 1989, the servers have been rock solid
for us, with no hardware failures on any of the units.
>  
> Have you had experience with them?

We have seven of the Datability servers, all which are dual protocol LAT/TCP-IP
oriented.  Three of them are 128 port boxes, 3 are 32 port, 1 is 24 port.  We
also have 29 DECservers (200s) on the same network as the Datability, so we can
compare the DECserver to the Datability server.

To support our terminals we use RS423 ports, RS232 ports, and an NPT protocol
card.  The protocol card allows a user on a DECserver to access the TCP/IP
service provided by the NPT card in a Datability server.  Some of the servers
have an intermixed set of 423, and 232 cards.  To access the terminal servers
we use dial up access, direct modem, direct terminal connection, and have
printers hanging off the terminal servers.  We also use a Datability server to
frontend a 16-line bank of dialup modems. 

To connect the Datability servers to our network we use
thickwire and thinwire connections to ethernet.

Datability as a vendor has been very easy for us to deal with.  They support
what they sell, both from the hardware side, as well as the software side.  We
ran into a problem in December, 1989, on our network, where a certain type
bridge was either passing runt and/or oversized ethernet packets.  Datability
called into the server at our site to see what the problem was, and immediately
applied a patch to the Datability software to trash the invalid packets.  In
this same situation, we received a complete terminal server replacement to
attempt to address this problem, overnight delivery, no charge.  

We have standardized on the Datability server based on price (as opposed to DEC
servers) support, and features.  There is no right to copy license to buy as
the LAT/TCP comes on a chip in the server.  I do not like the idea of buying
hardware just to get to buy 1 or 2 licenses to have software to make it run. 
The boot time for the server is about 5 seconds.  This makes it a good
candidate for satellite rooms on an ethernet network, which is what we are
doing with the servers.  Our users are able to dial into our dialin bank and
access other hosts on the INTERNET where they have accounts, without signing
onto the local host computers.

I am not affiliated with Datability, nor do I receive any compensation from
them.  However, the product is a useful, stable addition to our networking
effort at this time on our campus.

- Terry               
  Bitnet:    COMBSTM@APPSTATE
  Internet:  COMBSTM@Conrad.Appstate.Edu
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 90 22:04:30 GMT
From:      eru!luth!sunic!chalmers!imtws3!petr@bloom-beacon.mit.edu  (Peter T|rnqvist IMT)
To:        tcp-ip@nic.ddn.mil
Subject:   Connecting two LANs using a 1 Mbps line

The company I work for has just installed brand new PABXs
in two of the main locations here in Sweden. We have a leased
2 Mbps link between the PABXs that gives us almost 30 simultaneous
voice connections. We don't need all that capacity for voice;
we would like to use about half of it for voice and the rest for data.
So we told the telephone company about it and they came up with
a $7-80.000 multiplexor solution that compressed voice and
could give us a lot of synchronous lines. However, we just
wanted to steal 15 time slots from the PABXs and use them
for data.

Finally, I asked Motorola/Codex and they have also
multiplexors but they have no direct G.703/G.704 connection
to a PABX. Instead they have a $5000 thing called Integrator that
has one G.703/G.704 interface to the line and one to the PABX (or mux),
and one V.35 interface to the computer equipment that you want
to connect. (The Integrator is not a Motorola/Codex product;
it is made by an Australian company called Sitek (I think)).

After a lot of fighting with the telephone company
(they first told us that this was impossible)
we will try the Integrator and probably the bridge/router
ACS 4100 from ACC.

So...

1) Anyone with experience of the "Integrator" or
something with similar functionality?

2) Anyone with experience of the ACS 4100 from ACC?
Or other ACC products? Is it fast enough for
a 1 Mbps line when routing TCP/IP?
Does it deserve to be called a "router?

3) A Vitalink costs about twice as much. Is it worth it?

4) I just heard of a box from WellFleet that combined
the functions of an Integrator, Router and Bridge and
also compressed voice but unfortunately I don't think
it was (yet) certified for use here in Sweden and it
was a lot more expensive than an Integrator and a router/bridge.
What about Cisco, do they have something like this?

Peter Tornqvist
Industri-Matematik Teknik AB
+46 31 290250
petr@im.se
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 90 23:07:27 GMT
From:      lim@cwlim.INS.CWRU.Edu (Hock-Koon Lim)
To:        comp.protocols.tcpip,comp.protocols.appletalk
Subject:   Telnet session close by ICMP message...


   Many users on our network complaint about their telnet session closed by
the remote host without any warning.  After many days of sniffing the network
with the sniffer, we found that they are some ICMP message that might by the
cause of these problem.  

  Said system A has a telnet session window open to system B.  System A and B
could be running Ultrix v3.0 or IBM RT running BSD 4.3 or SunOS 3.5. There
are few MacOS systems with a Dove SCSI Ethernet device that run MacTCP v1.1.
The Mac System C some time send out an ICMP message with 
"Destination unreachable, Host unreachable" to system A.  The ICMP message from
C tell A that host B is unreachable. When this happen, system just close the
telnet connection to system B without any warning.  The question is why system
C send out this kind of ICMP message to A?  It is not his business at all.
Other mac on the network with other Ethernet card and MacTCP does not do that
Only Mac with Dove SCSI Ethernet card do.   Is any one seen this kind of ICMP
message before?

Thanks,


-- 
Hock-Koon Lim, Information Network services
Case Western Reserve University; Cleveland, Ohio, USA  44106   
(216) 368-2982        lim@ins.cwru.edu

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 00:38:56 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!mel.dit.csiro.au!yarra!chris@ucsd.edu  (Chris Jankowski)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP/Ethernet Protocol Analyser - which to buy
I need a TCP/IP/Ethernet protocol analyser for general troubleshooting
work in multivendor enviroment. It must be portable as I often work at
customer sites. It must also be good at decoding protocols. I don't
want to spend months ploughing through rims of hex dumps.
I used Sniffer a few times and I was very happy with it.
It has good intuitive user interface and decodes protocols nicely.
I would love to get one but people who sell it here in Australia
charge A$35k for a working set based on portable Compaq 386.
On the other hand I know that a working analyser can be built
for around A$6k here using a $2k software product from FTP Software
and a PC portable with an Ethernet card. I am sure there exist something 
in between as well. Is Sniffer so much better to justify 6 times higher
price? What are the deficiencies of the low end products?

I would appreciate your comments based on your experiences with available 
products, their strengths and weaknesses and value for money factor.
Comparisons to Sniffer, which I know and is probably a top end benchmark
in this area will be especially useful.

Many thanks in advance. I shall summarise to the net.

      -m-------   Chris Jankowski - Senior Systems Engineer chris@yarra.oz{.au}
    ---mmm-----   Pyramid Technology Corporation Pty. Ltd.  fax  +61 3 820 0536
  -----mmmmm---   11th Floor, 14 Queens Road                tel. +61 3 820 0711
-------mmmmmmm-   Melbourne, Victoria, 3004       AUSTRALIA       (03) 820 0711

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Aug 90 11:14:40 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        ibmsupt.uucp!bullhead!brunner@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Token Ring frame sizes?
Note that some versions of some IBM 802.5 TCP/IP products have
required that the RIF they receive indicate a willingness to handle
2052-byte frames, before they'll talk to the other end.  PC/TCP
advertises TCP MSSs on the local subnet based on this packet size.
The concept of 802.5 <-> 802.3 "MAC-layer bridges" has an underlying
flaw.  See pub/msb_vs_lsb/* on vax.ftp.com for the details.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Aug 90 10:13:58 -0400
From:      tmallory@BBN.COM
To:        Chris Jankowski <swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!mel.dit.csiro.au!yarra!chris@ucsd.edu>
Cc:        tcp-ip@nic.ddn.mil, tmallory@BBN.COM
Subject:   Re: TCP/IP/Ethernet Protocol Analyser - which to buy
Chrys,

When we looked at ethernet analyzers a few years ago, the Sniffer was clearly
the best of the portables, primarily because of its user interface and the
fact that it worked.  We did not select it because our own requirements were
more oriented towards performance testing, and the best product in that area
is the HP Lanalyzer(which is transportable :-).  I will give you a brief
picture of the Lanalyzer:

The HP is the ONLY analyzer that can keep up, 100%, with anything being
transmitted up to the maximum capacity of the wire, in real-time.  It can tell
you if that the average traffic is 10,373 pps: most others top out around 3000
pps.

The HP's buffer for storing packets is average: like all(most?) of them, it
will store back-to-back packets until the buffer is filled.

The HP's transmitter and receiver are essentially independent.

The HP has support for 16 full-size, fully specified packets for transmission.  
   Most other analyzers only allow 1 packet for transmission, and many do not
   allow you to specify the full contents of the packet(I think one allows
   more packets, but not fully specifed=zero padded).

The maximum packet transmission rate is about 10k packets per second, which is
slightly lower than the Excelan product, but respectable.  It will tell you
exactly what the traffic rate is while transmitting at this rate.  The Excelan
product was very difficult to use(and I think could only send a single, not
fully specified, packet at high speed).

You can write simple programs with loops, received packet matching, counters,
timers, and sending of the predefined test packets.

The packet decoding on the HP is an extra package.  You should look at a
current version to see if it suits your needs.

The packet filtering is pretty good, though not quite as general as some of the
others(though I think it can look at ANY byte in the packet).

If your operation gets large enough, a Sniffer and an HP make a good
combination.

Tracy
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 05:35:42 GMT
From:      auspex!ntrlink!pjj@uunet.uu.net  (Patrick Johnston)
To:        tcp-ip@nic.ddn.mil
Subject:   : Double Byte Charaters for tn3270
I am looking for an implementation of TN3270 that has been modified to
support Double Byte Charater Sets (Kanji, Chinese, Hongul, etc). I
would like to know if anyone has made this product or if there is
something in the public domain.

I am interested in any OS (Ultrix, SUNos, DOS, etc.) or any one of
the above languages.  Please respond to me directly.  If there is a good
response I will summarize for the NET.


------------------------------------------------------------------
Patrick Johnston	Manager, International Marketing & Support
pjj@interlink.com	Interlink Computer Sciences
sun!ntrlink!pjj		47370 Fremont Blvd
			Fremont, California 94538
voice:	415/657-9800	fax:    415/659-6381
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 07:11:49 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Token Ring frame sizes?
In article <1990Aug15.213146.2836@ibmpa> brunner@ibmsupt.UUCP () writes:
+---------------
| You can expect to see implementations which hold a token for up to 10ms
| in the blind pursuit of big frames on what are essentially propriatary
| networks.
+---------------

10ms? That's easy. Any big, fast NFS server with lots of clients very well
may have more than 10ms (125 Kbytes, on FDDI) of data ready to go when the
token arrives.

And frame size has nothing to do with it; all of the packets might be small.
On FDDI any station is permitted to send multiple packets per token, up to
the limits of T_Opr (roughly speaking).


-Rob

p.s. The default T_Opr -- max "operational" time per token rotation -- for
FDDI is 165ms, which is just over 2 Mbytes. [O.k., it;s really T_Max, but in
the absence of any real-time guys, the negotiated T_Opr will just be T_Max.]


-----
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
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 14:13:58 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP/Ethernet Protocol Analyser - which to buy

Chrys,

When we looked at ethernet analyzers a few years ago, the Sniffer was clearly
the best of the portables, primarily because of its user interface and the
fact that it worked.  We did not select it because our own requirements were
more oriented towards performance testing, and the best product in that area
is the HP Lanalyzer(which is transportable :-).  I will give you a brief
picture of the Lanalyzer:

The HP is the ONLY analyzer that can keep up, 100%, with anything being
transmitted up to the maximum capacity of the wire, in real-time.  It can tell
you if that the average traffic is 10,373 pps: most others top out around 3000
pps.

The HP's buffer for storing packets is average: like all(most?) of them, it
will store back-to-back packets until the buffer is filled.

The HP's transmitter and receiver are essentially independent.

The HP has support for 16 full-size, fully specified packets for transmission.  
   Most other analyzers only allow 1 packet for transmission, and many do not
   allow you to specify the full contents of the packet(I think one allows
   more packets, but not fully specifed=zero padded).

The maximum packet transmission rate is about 10k packets per second, which is
slightly lower than the Excelan product, but respectable.  It will tell you
exactly what the traffic rate is while transmitting at this rate.  The Excelan
product was very difficult to use(and I think could only send a single, not
fully specified, packet at high speed).

You can write simple programs with loops, received packet matching, counters,
timers, and sending of the predefined test packets.

The packet decoding on the HP is an extra package.  You should look at a
current version to see if it suits your needs.

The packet filtering is pretty good, though not quite as general as some of the
others(though I think it can look at ANY byte in the packet).

If your operation gets large enough, a Sniffer and an HP make a good
combination.

Tracy

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 15:56:29 GMT
From:      shelby!helens!baroque!jim@decwrl.dec.com  (James Helman)
To:        tcp-ip@nic.ddn.mil
Subject:   CSLIP + Telebits + SunOS (was Re: Telebit T1000 vs T1500 (Summary))
pbiron@weber.ucsd.edu (Paul Biron) writes: 

      I got one reply from someone at Telebit, who explained
      at little bit about PEP itself, and specifically about
      Telebit's and SLIP.  The jist of his message was that
      Telebit's don't handle SLIP very well -- it causes
      thrashing between small and large packets

      Telebit (or someone they've
      donated a mass of TB's to) is working on ways to
      improve their performance on SLIP 

This is probably Van Jacobson's CSLIP (SLIP + header compression), the
beta version of which has been available for more than half a year
(from ftp.ee.lbl.gov).  I believe the header compression is supposed
to make single character TCP/IP packets much smaller, hopefully small
enough to fit into one of Telebit's micro-short packets, rather than
requiring a largely unused 256 byte long packet.

I have CSLIP running on our Sun-3's (SunOS 4.0.3 w/Rayan
Zachariassen's driver for streams).  Now, I'm looking for modems.

Questions:

1) Does anyone have any experience running the beta CSLIP on Telebits?
If so, how well does it work (throughput and interactivity) and with
what models, settings, etc? 

2) Will SLIP's successor, PPP, have different modem requirements?

3) Does CSLIP beta work with SunOS 4.1?

4) The System V streams stuff in SunOS 4.0 slowed down the serial
ports considerably.  How much CPU horsepower does it take to service a
port around 9600 or 19.2K?  Is SunOS 4.1 any better?

Thanks,

Jim Helman
Department of Applied Physics			Durand 012
Stanford University				FAX: (415) 725-3377
(jim@KAOS.stanford.edu) 			Voice: (415) 723-9127
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 17:32:35 GMT
From:      voder!dtg.nsc.com!my@ucbvax.Berkeley.EDU  (Michael Yip)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Token Ring frame sizes?  (FDDI also)

I agree with Rob from Silicon Graphic.

One can hold the token for a very long time (Limited by T_Opr for
the particular station).  In our FDDI Lab in National Semiconductor,
I once tried to do the same experiment.  I specificed a very large
value of T_Req on every station, let the ring started.  When the ring
started, the FDDI token was rotating very very fast.  It rotated once
per T_Ring_Latency.  Then I started a station to transmit frames, not 
large ones but many many small or medium size frames.  That station had
so many frames to transmit until T_Opr expired and forced to release
the token and not transmitting.  The result?  The token rotated so slow
that I could count it myself by looking at Token Counter display on my 
program.  The conclusion ... yes, it is possible to hold the token for
a very long time.  If the station is capable to do so.  

-- Mike

PS: So Rob, can we go graceful insertion of a station into a FDDI
    concentrator by holding the token and let the station into the ring?
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 18:20:28 GMT
From:      hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu  (Lars Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP/Ethernet Protocol Analyser - which to buy
In article <64884@yarra.oz.au> chris@yarra.oz.au (Chris Jankowski) writes:
>              Is Sniffer so much better to justify 6 times higher price?
Yes. If not, they would have gone out of business a long time ago.

>What are the deficiencies of the low end products?

In order to keep up with the traffic in promiscusous mode, you must have
[1] a powerful CPU on the ethernet card
[2] a large RAM on the ethernet card
[3] hardware address filtering in order to capture traffic with multiple
    destination addresses that do not form a multicast group.

This means that standard commercial ethernet PC cards are not the right
thing to use. The special-engineered ethernet card is most of the
premium cost.

But the Sniffer's display and decoding software is also much more
comprehensive than what is offered with the lowend devices.

We have dozens of SUNs around here. They all come with the "Etherfind"
and "traffic" utilities, right ? Yet when we need to look at the network
traffic, we go and get the Sniffer, and put it on the desk next to that
Sun.

If you have used a Sniffer, you'll never be happy with a lowend monitor.
If you can't afford the Sniffer, you'll learn to live with what you can
afford.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 18:24:28 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!mips!atha!aupair.cs.athabascau.ca!lyndon@ucsd.edu  (Lyndon Nerenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Location of in.h in SVR4
In article <65@aupair.cs.athabascau.ca> I wrote:
> Would someone who has access to a machine running SVR4 please let
> me know what directory in.h is located in? Thanks.

Thanks to everyone for the quick response. The verdict is it's
located in <netinet/in.h>.

To those of you who helpfully pointed out the find command, would you please
tell me the option to find that will make it look for files on a machine
I don't have?

-- 
     Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
         {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca
                           Practice Safe Government
                                 Use Kingdoms
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 18:47:52 GMT
From:      astph!astph.uucp@psuvax1.cs.psu.edu  (Joe Broniszewski)
To:        tcp-ip@nic.ddn.mil
Subject:   AT bus Ethernet cards
We are going to install a 10BaseT network in the next few months
and I need som advice on ethernet cards.  We are running ISC UNIX
2.2.  Please email me comments on your experience with these cards.
Especially WD, 3Com, Interlan, and UB.  Are there substantial advantages
of having 16 bit cards over 8 bit?  Are cards with lots of RAM worth the
extra bucks?  Thank you for your help.

---
Joe Broniszewski     (814) 234-8592x4
astph!joe@psuvax1    psuvax1!astph!joe
Philadelphia Phillies
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 20:12:04 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!ark1!pokey!snorthc@ucsd.edu  (Stephen Northcutt)
To:        tcp-ip@nic.ddn.mil
Subject:   Designer Colored Thinnet
The organization here is modeled after the feudal (futile?) system.
Every group of 10 or more workers is their own empire with
their own network.  Of course we keep a central organization
(my group) so that there is someone to blame when things go wrong.

The problem I am seeking help with is spaghetti cabling.  All
these little nets, and subnets, and multi-port repeaters and
bridges and routers are hard to keep track of. Especially
since many groups want their own cable.  So along the halls
are many strands of cable, the older cables are not even labled,
but we don't allow that anymore.

We would be too far gone to be saved except for one thing.  The
ceiling insulation here is asbestos (cough cough).  So soon we
have to move out, while they disbestos us.  As part of that
effort the contractors are going to rip  out all of the wires.

When we rewire, we want to be much smarter about how we do it.
One thing that might help is colored cable.  I know where to
get thick ethernet in yellow, blue, metallic yellow and orange.
Does anyone know of a source for thinnet (rg-58a) in colors.
Yes, we will have labels, but it would be better to have some
idea what a cable does, at any point.  Also, then the Autocad
drawings we make could be adjusted to match cables.  It would
also be better for phone support... instead of "are you on the
48 or the 49 subnet", we could ask "are you connected to the 
blue cable or the yellow cable".  Finally, we could assign
groups that give us a lot of grief *special* colors.

Thank You

===================================================================
Stephen Northcutt (snorthc@relay.nswc.navy.mil)
Work: (703) 663-7745
Home: (703) 371-4184
Paper Mail: Code E41, NSWC, Dahlgren VA 22448
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 22:56:23 GMT
From:      dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!samsung!munnari.oz.au!goanna!minyos!monu6!jwb@ucsd.edu  (Jim Breen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Connecting two LANs using a 1 Mbps line
In article <969@imtws3.im.se>, petr@imtws3.im.se (Peter T|rnqvist IMT) writes:
> 
> .......... Instead they have a $5000 thing called Integrator that
> has one G.703/G.704 interface to the line and one to the PABX (or mux),
> and one V.35 interface to the computer equipment that you want
> to connect. (The Integrator is not a Motorola/Codex product;
> it is made by an Australian company called Sitek (I think)).
> 
> After a lot of fighting with the telephone company
> (they first told us that this was impossible)
> we will try the Integrator and probably the bridge/router
> ACS 4100 from ACC.
> 
> So...
> 
> 1) Anyone with experience of the "Integrator" or
> something with similar functionality?
> 
Sure have. We (Monash) have four of them as we do exactly the
same as you propose on our two intercampus 2Mbps links. We pull
out 768k for the cisco-cisco links and leave the rest for voice,
etc. They have worked faultlessly from day one.

> 
> 4) I just heard of a box from WellFleet that combined
> the functions of an Integrator, Router and Bridge and
> also compressed voice but unfortunately I don't think
> it was (yet) certified for use here in Sweden and it
> was a lot more expensive than an Integrator and a router/bridge.

We heard of this too, however:

(a) it was T1 only, not G.703.
(b) it had not yet got certification for PABX attachment (a
lengthy and tricky process here.

> What about Cisco, do they have something like this?
 Haven't heard of anything.

BTW, the Integrator (the company is Scitec) can operate on 48V
DC, and thus sit in the PABX's power float.

-- 
   _______            Jim Breen ($B%8%`(J) (jwb@monu6.cc.monash.edu.au) Dept of 
  /o\----\\     \O             Robotics & Digital Technology. Monash University
 /RDT\   /|\   \/|  <:O____/       PO Box 197 Caulfield East VIC 3145 Australia
O-----O        _/_\   /\ /\            (ph) +61 3 573 2552 (fax) +61 3 573 2745
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Aug 90 10:52:18 -0500
From:      jbvb@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: TCP/IP/Ethernet Protocol Analyser - which to buy
    From: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu  (Lars Poulsen)

    This means that standard commercial ethernet PC cards are not the right
    thing to use. The special-engineered ethernet card is most of the
    premium cost.

Lars, at least as of last winter Sniffers used a 3Com 3C505 interface
that may have been modified, but not much; a customer reported being
able to load and run both WIN/PC and PC/TCP for the 3C505 on it just
fine.  A LANAlyzer does use a special interface, but both cards are
based on 82586 chips.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 09:40:00 CDT
From:      "Kathy Rinehart c60191 x3899" <rinehart@aedc-vax.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Cc:        "rinehart" <rinehart@aedc-vax.af.mil>
Subject:   TCP/IP intro class offered before October 1
Help!

     One of my colleagues just learned that an introduction class to TCP/IP 
was cancelled.  Due to a variety of reasons, he is VERY interested in a class 
that someone could recommend, particularly one in the US and preferably one 
offered before October 1.  Since the TCP/IP knowledge that I have acquired has 
been through OJT or reading, I have no idea what may be available.  Can anyone 
help us?

    Thank you for any help you can provide.  

						Kathy Rinehart
						Rinehart@AEDC-VAX.AF.MIL
						Phone (615) 454-3899
						AV 340-3899


-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 05:31:03 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Token Ring frame sizes?  (FDDI also)
In article <1379@cuckoo.nsc.com> my@cuckoo.UUCP (Michael Yip) writes:
+---------------
| PS: So Rob, can we go graceful insertion of a station into a FDDI
|     concentrator by holding the token and let the station into the ring?
+---------------

Not really. (At least I don't think so.)

Remember, you can't just "hold" the token; you have to send frames at
least every L_Max (3.5us), in order to reset other stations' TVX timers.
(Of course, you can send properly formatted "void" frames, but then,
why waste ring bandwidth? ;-}  )


-Rob
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Aug 90 11:38 EDT
From:      James Dryfoos- PostMaster <DMPM%DUKEMC.BITNET@ncsuvm.ncsu.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Port 37 time conversion routine wanted.
I am wondering if there is a c-routine out there for converting
the machine readable date-time protocol which is generated on
port 37 into either an ascii representation or a vax-vms equivalent
binary date-time value?

Please send replies directly to me as I am not subscribed to this
list.

Thanks Jim

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
*  James Dryfoos  -- Medical Informatics - Duke University Medical Center     *
*                                                                             *
*  VMS Systems Programmer -- Postmaster - Duke Electronic Medical Post Office *
*  DMPM@DUKEMC.BITNET     -- Duke Medical Postmaster BITnet address           *
*  DMPM@DUKEMC.MC.DUKE.EDU - Duke Medical Postmaster INTERnet address         *
*  DRYFO001@DUKEMC.BITNET -- Personal BITnet Address                          *
*  DRYFO001@DUKEMC.MC.DUKE.EDU -- Personal INTERnet Address                   *
*  Box 2914 D.U.M.C. Durham, NC 27710 USA, EARTH--(919) 684-6421/fax 684-8675 *
*                                                                             *
*  My PLAN is to get through this day!!!!!!                                   *
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Aug 1990 13:12-EDT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   chip bug or bad dream ?
Hi all,
after painful efforts I tracked down a problem in my ethernet
driver (for Mach/DECStations).  It would look like the Amd7990
loses the content of the CSR1 register, which the spec say it 
would not (not even across RESET).

I have looked at CSR1 and found it had the wrong content after
	1) the chip reports a MISS packet
	2) I send STOP to CSR0
	3) I perform the INIT sequence (e.g. INIT, wait for done)
	4) I restart the chip
Since the chip was stuck at this point, I conjecture CSR1 was wrong
already at point 3).
Resetting the CSR1 value and restarting from 3) got it working
again.

I have looked at my code over and over again, and I can find no way
in which the value that I see in the register (0x48) could have got
there intentionally. Indeed, the RAP register is not ever touched
after power up time !  And the machine was fully functional and 
continued to work after I dropped into the kernel debugger and fixed
the registers by hand.

Sooo, can anyone confirm the chip can violate the requirement that
CSR1 stays set ?   Or deny it ?
[Might also depend on the revisions: my pmax is one of the first ones,
 and the problem does not show up (yet?) on a newer machine.]
Pointers&illuminations are most welcome.

Incidentally, I have another horror story for the same chip, would
anyone at AMD care to hear it ?
sandro-

 Alessandro Forin / School of Computer Science / Carnegie-Mellon University
 Schenley Park / Pittsburgh, PA 15213 / Ph: (412) 268-6861
 ARPA: af@cs.cmu.edu
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Aug 90 13:58:02 EDT
From:      SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
To:        TCP/IP List <tcp-ip@nic.ddn.mil>
Subject:   Packet driver specifications
I am a little unfamiliar with packet drivers. I understand that they
are some sort of software interface to network adapter cards.
What standard interface(s) are they written to?  How may I obtain a copy of
the specs for the interface(s)?

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 10:38:30 GMT
From:      attcan!lsuc!becker!bdb@uunet.uu.net  (Bruce D. Becker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Location of in.h in SVR4
In article <65@aupair.cs.athabascau.ca> lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes:
>Would someone who has access to a machine running SVR4 please let
>me know what directory in.h is located in? Thanks.

	On Commodore Amiga Unix its path is

		/usr/include/netinet/in.h

	This is the same place as it is in BSD Unix,
	I believe.

-- 
  ,u,	 Bruce Becker	Toronto, Ontario
a /i/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `\o\-e	 UUCP: ...!uunet!mnetor!becker!bdb
 _< /_	 "I still have my phil-os-o-phy" - Meredith Monk
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 13:18:54 GMT
From:      o.gp.cs.cmu.edu!DALE.FAC.CS.CMU.EDU!moore@pt.cs.cmu.edu  (Dale Moore)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Magic cookies over Telnet
In article <12461@hydra.gatech.EDU>, gs26@prism.gatech.EDU (Glenn R.
Stone) writes:
|> In <2432@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes:
|> 
|> > What I was thinking of doing was passing the magic-cookie [DISPLAY
variable]
|> >to the remote-end through another Telnet option.  Has anyone else thought
|> >about/done this (I didn't find a RFC)?  Does any one have any comments
|> >on the good/badness of this?
|> 
|> This smells more like what rlogin does...  Telnet doesn't need to be passing
|> environment variables, since I might (and do, occasionally) be telnetting
|> to a VMS machine, or (angels and ministers of grace defend us) a CYBER...
|> 

See RFC 1096  for one way to pass the DISPLAY environment variable
from telnet client to telnet server.

Dale Moore
Senior Research Systems Programmer
School of Computer Science
Carnegie Mellon University
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 13:32:14 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: : Double Byte Charaters for tn3270

On Thu, 16 Aug 90 05:35:42 GMT you said:
>I am looking for an implementation of TN3270 that has been modified to
>support Double Byte Charater Sets (Kanji, Chinese, Hongul, etc). I
>would like to know if anyone has made this product or if there is
>something in the public domain.
>
>I am interested in any OS (Ultrix, SUNos, DOS, etc.) or any one of
>the above languages.  Please respond to me directly.  If there is a good
>response I will summarize for the NET.

On my side, I would be most pleased if I knew those that implement
single byte fully. That's supporting the 192-character set.
I am mostly interested in DOS and Mac, but also SUNos and Ultrix.
Including those in the summary would be nice.
Is porting TN3270 from one version to another easy?
As to the question "Which EBCDIC?", I have a paper for anyone interested,
including translation tables of many codes to/from ISO 8859.

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD@BLIULG11 on EARN/BITNET

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 13:53:06 GMT
From:      hpcc01!hpcuhb!hpsqf!hpopd!ian@hplabs.hpl.hp.com  (Ian Watson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: AT bus Ethernet cards
I got a WD8003EB for my SCO Unix box.  Instead of good ol' jumpers to set the
IRQ vector, I/O address and so on, it's done by a s/w config program.  Which
runs on DOS.  Hmmm.  Now, I DO have a DOS box to do this, but it seems a bit
dumb for WD to assume their cards are only for DOS m/c's.  It was a but of a 
fiddle, but now that it's in, it's OK.  I can't vouch for its performance,
though, as I only ever have it lightly loaded.

Ian Watson, HP Pinewood, England
ian@hpopd.HP.COM, ian@hpopd.HP.CO.UK, {the_world}!hplabs!hpopd!ian
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 14:40:00 GMT
From:      rinehart@AEDC-VAX.AF.MIL ("Kathy Rinehart c60191 x3899")
To:        comp.protocols.tcp-ip
Subject:   TCP/IP intro class offered before October 1

Help!

     One of my colleagues just learned that an introduction class to TCP/IP 
was cancelled.  Due to a variety of reasons, he is VERY interested in a class 
that someone could recommend, particularly one in the US and preferably one 
offered before October 1.  Since the TCP/IP knowledge that I have acquired has 
been through OJT or reading, I have no idea what may be available.  Can anyone 
help us?

    Thank you for any help you can provide.  

						Kathy Rinehart
						Rinehart@AEDC-VAX.AF.MIL
						Phone (615) 454-3899
						AV 340-3899

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 16:09:31 GMT
From:      jhh1@ra.MsState.Edu (Jim Harfst)
To:        comp.protocols.appletalk,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Telnet and FTP over Localtalk through Kinetics Fastpath

I have a person who wants to do Telnet and FTP sessions on a PC connected to
a Localtalk net bridged to TCP/IP by a Kinetics Fastpath.  

I have heard that this is possible using NCSA Telnet if I get a packet driver
for the Localtalk
card.  But, lo and behold, I can't find one anywhere.  Can someone please tell
me where I can FTP one from, or has anyone hacked one that they can send me?

Any help would be appreciated.


Thanks in advanced.

Jim Harfst
Mississippi State University

jhh1@ra.msstate.edu

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 17:12:00 GMT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   chip bug or bad dream ?

Hi all,
after painful efforts I tracked down a problem in my ethernet
driver (for Mach/DECStations).  It would look like the Amd7990
loses the content of the CSR1 register, which the spec say it 
would not (not even across RESET).

I have looked at CSR1 and found it had the wrong content after
	1) the chip reports a MISS packet
	2) I send STOP to CSR0
	3) I perform the INIT sequence (e.g. INIT, wait for done)
	4) I restart the chip
Since the chip was stuck at this point, I conjecture CSR1 was wrong
already at point 3).
Resetting the CSR1 value and restarting from 3) got it working
again.

I have looked at my code over and over again, and I can find no way
in which the value that I see in the register (0x48) could have got
there intentionally. Indeed, the RAP register is not ever touched
after power up time !  And the machine was fully functional and 
continued to work after I dropped into the kernel debugger and fixed
the registers by hand.

Sooo, can anyone confirm the chip can violate the requirement that
CSR1 stays set ?   Or deny it ?
[Might also depend on the revisions: my pmax is one of the first ones,
 and the problem does not show up (yet?) on a newer machine.]
Pointers&illuminations are most welcome.

Incidentally, I have another horror story for the same chip, would
anyone at AMD care to hear it ?
sandro-

 Alessandro Forin / School of Computer Science / Carnegie-Mellon University
 Schenley Park / Pittsburgh, PA 15213 / Ph: (412) 268-6861
 ARPA: af@cs.cmu.edu

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 17:58:02 GMT
From:      SSJACK@ECUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   Packet driver specifications

I am a little unfamiliar with packet drivers. I understand that they
are some sort of software interface to network adapter cards.
What standard interface(s) are they written to?  How may I obtain a copy of
the specs for the interface(s)?

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

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 18:46:37 GMT
From:      tiamat!jim@uunet.uu.net  (Jim O'Connor)
To:        tcp-ip@nic.ddn.mil
Subject:   rlogind server doesn't die when client goes away
Were's the situation:  We have an HP 9000/835 running HP-UX 7.0, an Annex II
terminal server, and a few 386PC's running SCO Xenix with TCP/IP from SCO.
If we do rlogins such as:

Client		Server
--------	------------
Annex II	HP 835
Xenix		Xenix
Xenix		HP 835

and the client end of the connection crashes (only one of the 386's is on a
UPS, and none of the Annex terminal servers are), the server end of the
connection NEVER goes away, unless the processes are killed by hand or the
server machine is rebooted.

Is this the "normal" behavior, or am I missing something completely obvious?

Thanks for any help.
------------- 
James B. O'Connor			jim@tiamat.fsc.com
Ahlstrom Filtration, Inc.		615/821-4022 x. 651
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Aug 90 15:32:14 +0200
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        Patrick Johnston <auspex!ntrlink!pjj@UUNET.UU.NET>, TCP-IP@NIC.DDN.MIL, ARPA TCP-IP Discussion Redistribution <TCP-IP@UTDALLAS>
Subject:   Re: : Double Byte Charaters for tn3270
On Thu, 16 Aug 90 05:35:42 GMT you said:
>I am looking for an implementation of TN3270 that has been modified to
>support Double Byte Charater Sets (Kanji, Chinese, Hongul, etc). I
>would like to know if anyone has made this product or if there is
>something in the public domain.
>
>I am interested in any OS (Ultrix, SUNos, DOS, etc.) or any one of
>the above languages.  Please respond to me directly.  If there is a good
>response I will summarize for the NET.

On my side, I would be most pleased if I knew those that implement
single byte fully. That's supporting the 192-character set.
I am mostly interested in DOS and Mac, but also SUNos and Ultrix.
Including those in the summary would be nice.
Is porting TN3270 from one version to another easy?
As to the question "Which EBCDIC?", I have a paper for anyone interested,
including translation tables of many codes to/from ISO 8859.

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD@BLIULG11 on EARN/BITNET
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 19:57:52 GMT
From:      zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@tut.cis.ohio-state.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Designer Colored Thinnet
In article <1990Aug16.201204.15627@relay.nswc.navy.mil>,
 snorthc@pokey.nswc.navy.mil (Stephen Northcutt) writes:
> 
> The problem I am seeking help with is spaghetti cabling.  All
> these little nets, and subnets, and multi-port repeaters and
> bridges and routers are hard to keep track of. Especially
> since many groups want their own cable.  So along the halls
> are many strands of cable, the older cables are not even labled,
> but we don't allow that anymore.
> 
> ...
> When we rewire, we want to be much smarter about how we do it.
> One thing that might help is colored cable.

	You have stumbled on the reason why so many of us are
enamored of Ethernet on twisted pair.

	One subnet: one multiport concentrator.  Someone wants
to move to another subnet?  No problem.  Where is the other end
of this wire?  No problem.  What color wire is it?  Who cares?

	We tried designer colored thick net two years ago.  We
installed six cables throughout the building with barrel connectors
here and there.  Very modular and adaptable.  But we gave up and 
went to UTP Ethernet and then to 10BaseT.

	There are nice adaptors that convert from thin to 10BaseT
and I don't mean baluns.  You can mix in thin-net, but you don't
have to run thin coax in the walls.

	You can afford it.  Hell, you can't afford not to.

	--Kent
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Aug 90 20:33:49 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!funic!santra!news@ucsd.edu, tcp-ip@NIC.DDN.MIL
Subject:   Re:  Talking to cisco routers with Unix machines
>In article <9008142108.AA03724@jade.berkeley.edu> of mail.sun-nets, 42-5360)CLIFF%edu (CLIFF <(Cliff Frost {415})) writes:
>
>>Has anyone had any experience using SLIP and/or PPP from a Sun
>>(a 3/50 or SPARCstation) at 56 or 64Kbits/sec?  I'm interested
>>in using one of the serial ports to do this.

Yes, we do have such a beast. We initially developed it on a Sun-3/50 and later
migrated to SS-1's. Several early (and quite buggy!) versions got out to a
variety of people. We recently redid the whole thing and that hasn't been
released yet. One of the main reasons it hasn't gone out yet is that we
depend on Sun's lower layer; i.e., we have been using the synchronous zs
driver they supply with their Sunlink products. Yes, we have our own, but I'm
not enthusiastic about maintaining that one. Much easier to use a tiny piece
of Sunlink. Except for the license problems....

						Torben
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Aug 90 20:40:48 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        BILLW@mathom.cisco.com, sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!funic!santra!news@ucsd.edu
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Talking to cisco routers with Unix machines
>    >Has anyone had any experience using SLIP and/or PPP from a Sun
>    >(a 3/50 or SPARCstation) at 56 or 64Kbits/sec?  I'm interested
>    >in using one of the serial ports to do this.
>
>You really do NOT want to do this.  The zippy CPU in a sparcstation
>is much better off doing user stuff, rather than trying to service
>13000 interupts/second.  Servicing interrupts is not something that
>most risc processors are good at.  I've heard people complain about
>the impact of much slower SLIP connections.

I disagree. We did this on a Sun-3/50 and sure, you could feel it. On an
SS-1, the impact isn't what I'd call major. We use the on-board serial ports
at 56Kbps in a couple of cases and we don't see a really noticeable impact
from it. We've actually gone a good bit higher than this on an SS-1 :-)
It all depends on what you're after. If you happen to have an SS-1 handy
and you're willing to give up a little chunk of the CPU, go for it. Under
normal circumstances, you won't notice it. My feeling is that the load is
about the same as you get if you add a reasonably active process to your
SS-1.

>You would be better off getting a sync serial interface, which only
>interrupts the CPU per frame, or a stand alone router box.

We're actually playing with this. We have hardware that allows us to run
serial lines out of an SS-1 at a full 2.048Mbps. Neat. And the SS-1 is fast.
Hopefully, we'll manage to get a hold of a Cisco pretty soon so we can test
interoperability.

					Torben
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Sat 18 Aug 90 21:24:39-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!funic!santra!news@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Talking to cisco routers with Unix machines
    >Has anyone had any experience using SLIP and/or PPP from a Sun
    >(a 3/50 or SPARCstation) at 56 or 64Kbits/sec?  I'm interested
    >in using one of the serial ports to do this.

You really do NOT want to do this.  The zippy CPU in a sparcstation
is much better off doing user stuff, rather than trying to service
13000 interupts/second.  Servicing interrupts is not something that
most risc processors are good at.  I've heard people complain about
the impact of much slower SLIP connections.

You would be better off getting a sync serial interface, which only
interrupts the CPU per frame, or a stand alone router box.


    To extend, has anyone written software to talk to Cisco routers at 64
    kbits/sec ?  I understand that Cisco's support SLIP, but can that be
    run at 64 kbit/s ?

The maximum speed of an async SLIP line on a cisco terminal server is
38400 bps.  Faster than that we like to do frame-at-a-time sync serial
too (and you use a router instead of a terminal server.)


    I suppose the protocol Cisco routers use to talk to each other is not
    any standard protocol but Cisco's own.  Are the protocol specs
    available ?  If not, would Cisco object to someone reverse-engineering
    the protocol ?

We have told people the spec.  I don't know whether anyone has
actually done anything with it.  The current software also supports
the IETF Point-to-Point protocol for IP on sync serial lines, which is
probably a better idea.

    A local PTT here offers a service to connect company LANs together
    with Cisco routers; if a general-purpose Unix machine could talk the
    Cisco protocol and route the traffic (perhaps also DECNET traffic) one
    could save the money needed to buy the Cisco router.  Well, perhaps I
    shouldn't have said that because I suppose it's not in the best
    interests of Cisco ;-)

This sort of thing is exactly what the PPP spec is supposed to solve.
This is tcp-ip, you don't have to be nice to cisco.  Actually, you
don't have to be nice to us on the cisco mailing list either  :-)

Bill Westfield
cisco Systems.
-------
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 90 22:51:26 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!funic!santra!news@ucsd.edu  (Jyrki Kuoppala)
To:        tcp-ip@nic.ddn.mil
Subject:   Talking to cisco routers with Unix machines
In article <9008142108.AA03724@jade.berkeley.edu> of mail.sun-nets, 42-5360)CLIFF%edu (CLIFF <(Cliff Frost {415})) writes:

>Has anyone had any experience using SLIP and/or PPP from a Sun
>(a 3/50 or SPARCstation) at 56 or 64Kbits/sec?  I'm interested
>in using one of the serial ports to do this.

To extend, has anyone written software to talk to Cisco routers at 64
kbits/sec ?  I understand that Cisco's support SLIP, but can that be
run at 64 kbit/s ?

I suppose the protocol Cisco routers use to talk to each other is not
any standard protocol but Cisco's own.  Are the protocol specs
available ?  If not, would Cisco object to someone reverse-engineering
the protocol ?

A local PTT here offers a service to connect company LANs together
with Cisco routers; if a general-purpose Unix machine could talk the
Cisco protocol and route the traffic (perhaps also DECNET traffic) one
could save the money needed to buy the Cisco router.  Well, perhaps I
shouldn't have said that because I suppose it's not in the best
interests of Cisco ;-)

//Jyrki
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 90 03:58:24 GMT
From:      cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@tut.cis.ohio-state.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Talking to cisco routers with Unix machines
In article <1990Aug18.225126.3678@santra.uucp> jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
>To extend, has anyone written software to talk to Cisco routers at 64
>kbits/sec ?  I understand that Cisco's support SLIP, but can that be
>run at 64 kbit/s ?

There is no reason why you couldn't run SLIP at FDDI bit rates, should
you really want to. :-)  I'd guess that 64kbaud is synchronous rather
than async, in which case SLIP's applicability is a bit more dubious,
but the idea is not impossible even so.

>I suppose the protocol Cisco routers use to talk to each other is not
>any standard protocol but Cisco's own...

In the long run they will probably use PPP, I would think.  What they
use *now* is a different question; it may well be proprietary.
-- 
It is not possible to both understand  | Henry Spencer at U of Toronto Zoology
and appreciate Intel CPUs. -D.Wolfskill|  henry@zoo.toronto.edu   utzoo!henry
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 90 20:39:01 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Talking to cisco routers with Unix machines
In article <12614941747.9.BILLW@mathom.cisco.com>, BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
> 
> You really do NOT want to do this.  The zippy CPU in a sparcstation
> is much better off doing user stuff, rather than trying to service
> 13000 interupts/second.  Servicing interrupts is not something that
> most risc processors are good at....


Well, just to pick nits ...

One of some RISC CPUs' claims to fame is low interrupts latency.  I have
intimate knowledge of a 16MHz RISC on a VME FDDI board that that takes an
interrupt/frame, for all frames including BEACON and CLAIM.  That's about
one frame every 3 microseconds.  The interrupt handler is limited to about
1.5 usec/interrupt, to ensure that there are cycles left over for talking
to the host and other things, while handling the 300,000 interrupts/second.

I remember the sales pitch for another RISC CPU about 4 years ago, where
they claimed you could start the work of an interrupt routine in 1 cycle.
It turned out to be true, although only for interrupt handlers like TLB-
miss handlers that need few registers.



Vernon Schryver
vjs@sgi.com
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 90 10:36:12 -0700
From:      Anne Wilson <acw@cisco.com>
To:        tcp-ip@nic.ddn.mil
Subject:   cisco and G.703(was Connecting two LANs using a 1 Mbps line)

What we suggest people use is the G.703 to RS449 or V.35 converto
convertor device made by Martis, who are a Finnish company.  This is
certified for use in the UK and all of the Nordic countries (I'm trying
to find out what the certification position is for other countries).
It is sold by the PTT among others in Sweden.  This performs the
same functions as the Sitek box mentioned, is smaller, and cheaper (at
least it is in sterling ..). We have a number of customers
succesfully using the Martis box in the UK - other than that we 
have no commercial interest in Martis.

Anne Wilson
Chernikeeff Telecom Ltd (the cisco distributor in the UK)
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 90 09:53:21 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
Cc:        TCP/IP List <tcp-ip@nic.ddn.mil>
Subject:   Re: Packet driver specifications
    From: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu

    I am a little unfamiliar with packet drivers. I understand that they
    are some sort of software interface to network adapter cards.
    What standard interface(s) are they written to?  How may I obtain a copy
    of the specs for the interface(s)?

It is a DOS-specific low-level interface that assumes contiguous packet
buffers and enforced standards for MAC-layer demultiplexing.  The spec
was originally designed by John Romkey; I maintain it these days.  You
can get it via anonymous FTP from vax.ftp.com, in pub/packet-d.* (ascii
is, .prn is formatted for an HP Laserjet with TMS Proportional II font,
.prn is Borland Sprint).

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 1990 12:11:49 PDT
From:      Ole J. Jacobsen <ole@csli.stanford.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet Driver
For an overview of the Packet Driver, see the article by John Romkey
on p 18 of the July 1990 issue (Vol. 4, No. 7) of ConneXions.


Ole J Jacobsen, Editor and Publisher
ConneXions--The Interoperability Report 
Interop, Inc.
480 San Antonio Road, Suite 100
Mountain View, CA 94040
USA
Phone: (415) 941-3399   FAX: (415) 949-1779
ole@csli.stanford.edu

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 90 10:15:35 EDT
From:      dgw%saturn.ACC.COM@salt.acc.com (Debby Wyron)
To:        tcp-ip@nic.ddn.mil
Subject:   Remove from mail list

	Please remove me from the mailing list for tcp-ip@nic.ddn.mil.
	Thanks you.
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      20 August 1990 1316-PDT (Monday)
From:      stanonik@nprdc.navy.mil (Ron Stanonik)
To:        tcp-ip@nic.ddn.mil
Cc:        stanonik@nprdc.navy.mil
Subject:   wollongong win/3b bug
We've run into what appears to be a bug in wollongong's
release 3.0 tcp/ip for at&t 3b2's (sysVr3.2.2).  The problem is that
connect complains "socket operation on non-socket".  The
conditions underwhich this occurs are that the socket was
obtained using rresvport() and the file descriptor was
previously used for reading a file (say, /etc/services).

Here's an outline of a program producing the error:

fd = open("/etc/services", 0)
read(...)	/* eg, lookup the service name */
close(fd)
fd = rresvport(...)	/* get's same descriptor as previous read() */
connect(fd, ...)

Apparently, wollongong's read() sets WIN_CANTSYNC (via win_sync), but
doesn't set s_used.  rresvport() doesn't modify the _win_sockinfo[] entry.
connect() (win_sync actually) finds WIN_CANTSYNC and gives up.

I'm not sure how best to fix this:
1) rresvport() appears to be in error because it doesn't fill in the
_win_sockinfo[] entry.
2) read() appears to be in error for calling _win_sync when the descriptor
is for a normal file.
3) _win_sync appears to be in error because it sets WIN_CANTSYNC, but
not s_used (if the descriptor is for a normal file).

Any reason to prefer one fix over the other?


Unrelated Questions

While digging around I noticed that the wollongong socket library
(built on top of tli) only pushes tirdwr onto the stream during
accept(), so if you're porting some bsd code which uses socket(),
bind(), connect(), then tirdwr tirdwr won't be pushed.  I thought
tirdwr was required before read/write/close would work properly?

I noticed that applications (eg, ftp, telnet, etc) included in
the wollongong distribution seem to always pop timod before
pushing tirdwr.  Why?  The sysV network programmer's guide doesn't
mention pop'ing timod being neccessary.

I noticed that telnetd seems to pop tirdwr then push timod (apparently
to undo the popd timod, push tirdw by tcplisten).  The sysV
network programmer's guide seems to say that pop'ing tirdwr closes
the connection.  Not so?

Thanks,

Ron Stanonik
stanonik@nprdc.navy.mil
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 1990 11:28-EDT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Re: chip bug or bad dream ? (dream)
The AMD people sent me a mail that cleared up the air: there is a
little note in the spec of the effects of the STOP bit that 
states explicitly "CSR1, CSR2 and CSR3 must be reloaded when the STOP
bit is set".  Needless to say, I had not noticed [lesson: always read 
on to the next page!!].

Apologies to AMD for the rumoring, and BTW I am finding them most
responsive and cooperative.  Thanks!

sandro-
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 90 16:55:57 EDT
From:      Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU>
To:        Jim O'Connor <tiamat!jim@uunet.uu.net>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: rlogind server doesn't die when client goes away
>Were's the situation:  We have an HP 9000/835 running HP-UX 7.0, an Annex II
>terminal server, and a few 386PC's running SCO Xenix with TCP/IP from SCO.
>If we do rlogins such as:  [list omitted]
>and the client end of the connection crashes [...], the server end of the
>connection NEVER goes away, unless the processes are killed by hand or the
>server machine is rebooted.
>
>Is this the "normal" behavior, or am I missing something completely obvious?

This is "normal" behavior for TCP connections.  There is no mechanism in the
TCP protocol spec for detecting a broken connection, unless the working end
attempts to send more data across the connection.  That will eventually
trigger a timeout, or, if the other host has been restarted, it will send a
reset, immediately closing the connection.

Many Unix systems (most BSD-based systems) have a mechanism called
"keep-alive" built into the TCP code.  A periodic probing of the
connection is done to see if it is still alive.  The probe is a single
data byte just outside the valid data window; on a good connection, this
triggers an ACK packet in response.  If the connection is gone, a reset
will be sent in response.  The keep-alive can have a negative effect,
however, in cases where both end systems are still alive, but the
network is temporarily disrupted due to a network problem of some sort.

Doug Nelson
Michigan State University
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 90 17:07 EDT
From:      James Dryfoos- PostMaster <DMPM%DUKEMC.BITNET@ncsuvm.ncsu.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   RFC 868 and DayLight Savings time.
RFC 868 does not mention how daylight saving time is to be handled.
Does anyone have official advise?
Does the GMT vary with DST?  What will port 37 give
me after DST changes?  Does the number of seconds that port 37 reports change
by 3600 or does an application receiving it have to know whether or not
to modify what it gets.
I am guessing that right now since I have to add 4 hours to what I get that
in the fall after DST changes I will have to add 5.  Is this correct?
This is based on the assumption GMT does not vary and it is up to the local
system to adjust (it should be this way).

Please send responces directly to me at DMPM@DUKEMC.MC.DUKE.EDU as
I am not subscribed to this list.

Thanks.

Jim Dryfoos
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 90 17:50:01 EDT
From:      cajungat@med.unc.edu (Dwayne P. Shrum)
To:        tcp-ip@nic.ddn.mil
Subject:   test
msg
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 90 15:28:00 GMT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: chip bug or bad dream ? (dream)

The AMD people sent me a mail that cleared up the air: there is a
little note in the spec of the effects of the STOP bit that 
states explicitly "CSR1, CSR2 and CSR3 must be reloaded when the STOP
bit is set".  Needless to say, I had not noticed [lesson: always read 
on to the next page!!].

Apologies to AMD for the rumoring, and BTW I am finding them most
responsive and cooperative.  Thanks!

sandro-

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 90 15:51:46 GMT
From:      snorkelwacker!spdcc!jin@tut.cis.ohio-state.edu  (Jerry Natowitz)
To:        tcp-ip@nic.ddn.mil
Subject:   rsh protocol?
I'd greatly appreciate any documentation or pointer there to on
the rsh protocol.  I'm trying to implement both the command and
daemon on a PDP-11 running RSX using Process Software TCP/IP.

Thanks in advance,

Jerry
-- 
     Jerry Natowitz
     Guest user on:
ARPA jin@ursa-major.spdcc.com
UUCP {ima,harvard,rayssd,linus,m2c}!spdcc!jin
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 90 17:36:12 GMT
From:      acw@CISCO.COM (Anne Wilson)
To:        comp.protocols.tcp-ip
Subject:   cisco and G.703(was Connecting two LANs using a 1 Mbps line)


What we suggest people use is the G.703 to RS449 or V.35 converto
convertor device made by Martis, who are a Finnish company.  This is
certified for use in the UK and all of the Nordic countries (I'm trying
to find out what the certification position is for other countries).
It is sold by the PTT among others in Sweden.  This performs the
same functions as the Sitek box mentioned, is smaller, and cheaper (at
least it is in sterling ..). We have a number of customers
succesfully using the Martis box in the UK - other than that we 
have no commercial interest in Martis.

Anne Wilson
Chernikeeff Telecom Ltd (the cisco distributor in the UK)

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 90 20:42:38 GMT
From:      kinsey@CSUN1.CS.UGA.EDU (Kevin Kinsey)
To:        comp.protocols.tcp-ip
Subject:   a tcp-ip connection problem


	  
	     
a query of sorts :
	Does anyone know of a file-transfer method using tcp/ip
	from the mac to a non-tcpip host?

	This is a stange setup, but we are exploring methods for
	file transfer between our many appletalk networks (connected	
	to a campus ethernet backbone via gatorboxes) and MUSIC 
	(that awful IBM Op Sys for VM). Since MUSIC doesn't support	
	tcp/ip (tcp/ip -> VM ->(translation) -> MUSIC), normal file
	transfer methods don't work.

	Does anyone know of a functioning work-around? Does anyone have
	any ideas at all? There is the method that MS-DOS kermit uses to
	work around this, but the mac doesn't have an equivalent of
	interrupt 15 (i don't think).

	Any help would be great.

	kevin kinsey		kinsey@csun1.cs.uga.edu [128.192.4.5]
	ucns
	university of georgia

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 90 20:48:54 GMT
From:      smiles@ferrari.nmc.ed.ray.com (Kevin Ruddy)
To:        comp.protocols.tcp-ip
Subject:   Routing methods

Our organization would like to set some guidelines pertaining to routing.

The three choices we see are as follows: default routing, proxy ARP, and RIP.
Proxy ARP appears to be a poor solution.  RIP would work fine, but there's
the issue of maintaining routing daemons on many hosts.  Default routing
along with ICMP redirects might work as well, but that could be a bad idea,
too.

What is a good solution?  Default routing involves a minimum configuration
on hosts, but if the router should change ...  And then there will always be
OSPF, right?  Anyone have some solid answers?  Thanks in advance ...

Kevin Ruddy
smiles@ferrari.nmc.ed.ray.com

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 90 20:55:57 GMT
From:      08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogind server doesn't die when client goes away

>Were's the situation:  We have an HP 9000/835 running HP-UX 7.0, an Annex II
>terminal server, and a few 386PC's running SCO Xenix with TCP/IP from SCO.
>If we do rlogins such as:  [list omitted]
>and the client end of the connection crashes [...], the server end of the
>connection NEVER goes away, unless the processes are killed by hand or the
>server machine is rebooted.
>
>Is this the "normal" behavior, or am I missing something completely obvious?

This is "normal" behavior for TCP connections.  There is no mechanism in the
TCP protocol spec for detecting a broken connection, unless the working end
attempts to send more data across the connection.  That will eventually
trigger a timeout, or, if the other host has been restarted, it will send a
reset, immediately closing the connection.

Many Unix systems (most BSD-based systems) have a mechanism called
"keep-alive" built into the TCP code.  A periodic probing of the
connection is done to see if it is still alive.  The probe is a single
data byte just outside the valid data window; on a good connection, this
triggers an ACK packet in response.  If the connection is gone, a reset
will be sent in response.  The keep-alive can have a negative effect,
however, in cases where both end systems are still alive, but the
network is temporarily disrupted due to a network problem of some sort.

Doug Nelson
Michigan State University

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 90 22:20:15 GMT
From:      dc@lupine.NCD.COM (Dave Cornelius)
To:        comp.bugs.4bsd,comp.sys.tahoe,comp.protocols.tcp-ip
Subject:   BSD tcp: multiple acks (with fix)

A sniffer trace of the MIT X windows demo 'maze', run on a lightly-loaded
host, connected via TCP to an X server on a heavily loaded (or slow)
host reveals a bug in the TCP ack generation in 4.2/4.3-tahoe derived
TCP implementations.  The result of the bug is that a TCP which
receives many small packets can appear to send an ACK for each
incoming packet.  These acks have the property that the <ack> field
_advances_ and the <window> field _declines_ by the same amount:
the length of the last incoming segment.

The problem is that the available window in the receiver can
be less than the window which was advertised to the sender.
The code in tcp_output.c computes the difference between
these two quantities, and leaves the result in a c-language int.
This item is potentially negative, in the case cited above.
The code then uses this negative int in a comparison with
a unsigned short (t_maxseg), and also in an expression
involving division by an unsigned long (sb_hiwat).  The latter usage
coerces the negative int to an unsigned, which steers
the comparison against 35% of the max window the wrong way,
resulting an outgoing ack for each segment received, (at
least until the receiving socket buffer is drained).

Granted, the 'maze' demo makes poor use of the TCP connection
by causing the host to emit enough 20-byte TCP packets to fill
the X-server's TCP window.  The BSD TCP code causes a few more
packets than necessary to be generated in reply to the client's
bombardment :-)

Repeat by:
(1) On host A:
	run the MIT X server, and
	5-10 processes each running 'main();{while (1) ;}'

(2) On host B:
    run 'maze -display hosta:0'

(3) With an ethernet analyzer, watch the traffic.  Watch the acks returning
    from host A after the bombardment of 20-byte X packets from host B.

This problem has been observed on:
Sun 3/50(sunos3.5) and SparcStation1(sunos 4.1)



Old code from tcp_output.c (near line 158 in 4.3.tahoe)

<	win = sbspace(&so->so_rcv);
<
<[ .... several state checks omitted... ]
<
<	/*
<	 * Compare available window to amount of window
<	 * known to peer (as advertised window less
<	 * next expected input).  If the difference is at least two
<	 * max size segments or at least 35% of the maximum possible
<	 * window, then want to send a window update to peer.
<	 */
<	if (win > 0) {
<		int adv = win - (tp->rcv_adv - tp->rcv_nxt);
<
<		if (so->so_rcv.sb_cc == 0 && adv >= 2 * tp->t_maxseg)
<			goto send;
<		if (100 * adv / so->so_rcv.sb_hiwat >= 35)
<			goto send;
<	}


Modified code:
>	win = sbspace(&so->so_rcv);
>
>[ .... several state checks omitted... ]
>
>	/*
>	 * Compare available window to amount of window
>	 * known to peer (as advertised window less
>	 * next expected input).  If the peer could make some use
>	 * of the window update, and the difference is at least two
>	 * max size segments or at least 35% of the maximum possible
>	 * window, then want to send a window update to peer.
>	 */
>	if (win > 0) {
>		int adv = win - (tp->rcv_adv - tp->rcv_nxt);
>
>-->		if (adv >= 0) {
>			if (so->so_rcv.sb_cc == 0 && adv >= 2 * tp->t_maxseg)
>				goto send;
>			if (100 * adv / so->so_rcv.sb_hiwat >= 35)
>				goto send;
>-->		}
>	}

-----------
Dave Cornelius                          Network Computing Devices
                                        350 North Bernardo Ave
dc@ncd.com   -or-                       Mountain View, CA, 94043
{uunet,ardent,mips}!lupine!dc           415-694-0675

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 90 22:39:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Is Asynchoronous IO supported in WIN/TCP fro VMS and SYSV?


        Is asynchoronous i/o supported in WIN/TCP for VMS and SYSV? i.e.
is the signals SIGIO and SIGURG supported? For TCP OOB, is WIN/TCP support
SIGURG and related ioctl() parameters in SYSv and VMS?
        Please direct the mail to me. I will summarize if enough interest.
        Thanks.

        Regards.

- Beng Hang Tay (email: taybengh@nusdiscs)

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 00:39:02 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Routing methods
First, the question you were asking seems to be about finding your
gateway, not about routing.  At the moment there is no good way for
hosts to find gateways.  Which way you use will depend upon the
specific capabilities of your host.  Ideally you need two things:

  - find a gateway when you start a connection
  - discover a gateway that has gone down and move to a new one

Default routing and proxy ARP will both do that, and both require
essentially the same kind of implementation.  For default routing,
your implementation needs the following features:

  - the ability to declare multiple default gateways, and to use
	any one that is up

  - a way of detecting when the current gateway is down, usually
	because the upper layers detect a timeout.  (Another way
	is to ping all gateways that are in use.)

Unfortunately the Unix TCP/IP implementations I've looked at are
unable to use more than one default.  Thus there's no way to go to
backup routes.  In addition default routes requires you to configure
in a list of default gateways.

Proxy ARP has no problem finding the gateway.  You don't need to
configure anything, and it can find any gateway that is up.  However
most Unix implementations do not have the ability to clear the current
ARP entry when there is a timeout.  Indeed the versions of BSD that
I've seen will keep a failed ARP entry forever if there is some
program attempting to use it.

RIP will do the job.  My main objections are (1) we don't use RIP for
routing and (2) I don't like listening to broadcasts on diskless
machines.  When a broadcast is sent, every machine on the network
pages in its rip daemon at the same time.  

An alternative to RIP is cisco's gateway discovery daemon.  Each
gateway sends a periodic broadcast.  There's a priority so you can
prefer some gateways over others.  From a host's point of view it has
roughly the same features as RIP, but work no matter what routing
protocol you are using, and is small enough that you could put it in
the kernel or lock down the daemon in memory.

In my opinion the best solution is a gateway discovery broadcast, but
done as ICMP and implemented in the kernel.  But putting it in the
kernel, diskless systems don't have the synchronized swapin problem.
The last IETF actually agreed to get a gateway discovery ICMP out the
door, so there's some hope.  

Until then, there is no ideal gateway discovery method.  You have to
choose which of the existing methods has the fewest disadvantages in
your enviornment.  You may well end up using different ones on
different types of host.

On our Suns, we use proxy ARP.  I use this rather than defaults
primarily because it requires the minimum amount of configuration.
However I've done kernel hacking to make it work:

  - ARP entries time out after 20 min, even if they are in use.

  - when an upper layer times out, ARP entries are cleared

  - NFS timeouts trigger ARP clearing, not just TCP timeouts

  - our cisco gateways have an "arp-delay" parameter.  This delays
	ARP responses.  It lets	us choose which gateway will win if
	several answer.  (With most implementations, the last ARP
	response to arrives wins.)  [cisco did not adopt this
	feature, reportedly because they didn't think they could
	explain to customers what it did.]

I think my next choice would be the cisco gateway discovery thing,
particularly if you machines have disks.  I might also consider trying
to put it into the kernel for diskless machines.

Maybe we can all agree to lean on the vendors to implement the new
gateway discovery ICMP.
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 01:08:14 GMT
From:      bacchus.pa.dec.com!deccrl!decvax.dec.com!ima!minya!jc@decwrl.dec.com  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP strangeness
> Oh, by the way, I'm not sure if it matters or not, but I'm running
> the SLIP compression routines (CSLIP), and ...

Hmmm... The folks around where I'm working have been discussing adding
a compression feature to SLIP, and a bit of investigation turned up no
evidence that anyone had done it.  This passage makes it sound like it
has been done.  Does anyone know details?  Is the source available for
copying or purchasing (under or over the table ;-)?

I've been thinking of subroutinizing the heart of compress as a way of
getting the job done, though with the latest fuss over the legality of
using compress, this may not be an option.  Of course, I could always
hack up a compress routine of my own; even a dumb one would have to 
give a measurable improvement over all the null and repeated bytes in
the typical IP header.  But getting it already done would be so much
faster, y'know.

-- 
Zippy-Says: I was there when ELMER FUDD met HAMLET on the MOON.
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 02:56:34 GMT
From:      usc!samsung!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!mahendo!wlbr!mh@ucsd.edu  (Mike Hoegeman)
To:        tcp-ip@nic.ddn.mil
Subject:   is  there a SLIP implementation for  interactive i386 unix ??

Does any kind soul know of a slip implementation for interactive's i386
unix ? If you do please drop me a note. Thanks a bunch.

-mike hoegeman, mh@wlbr.imsd.contel.com
--
-------------------------------------------------------------------------------
Mike Hoegeman               email: mike@wlv.imsd.contel.com  tel: (818)706-4145
Contel Federal Systems      31717 La Tienda Dr, Westlake Village CA. 91359
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Aug 90 07:40:45 EDT
From:      Frank J. Robey <fjr@ulana.mitre.org>
To:        snmp@nisc.nyser.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Information wanted about SNMP based Network Managers


Hi,

I'm interested in hearing about people's experiences with SNMP based network
managers. Specifically, any horror stories about incorrect implementations or
things that did not work like they should, areas that weren't implemented at
all, etc. I would also like to hear about the good things that people did. I
don't necessarily need to know vendor names, I'm just trying to gather info
about SNMP managers in general.

please e-mail me directly and I'll summarize for the net.

thanks,

Frank J. Robey
The MITRE Corporation
fjr@mitre.org

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 90 14:39 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Is Asynchoronous IO supported in WIN/TCP fro VMS and SYSV?

        Is asynchoronous i/o supported in WIN/TCP for VMS and SYSV? i.e.
is the signals SIGIO and SIGURG supported? For TCP OOB, is WIN/TCP support
SIGURG and related ioctl() parameters in SYSv and VMS?
        Please direct the mail to me. I will summarize if enough interest.
        Thanks.

        Regards.

- Beng Hang Tay (email: taybengh@nusdiscs)
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Aug 90 11:00:37 -0400
From:      hal@gateway.mitre.org (Hal Feinstein)
To:        -v@gateway.mitre.org, tcp-ip@nic.ddn.mil
Subject:   TCP port 2 ... hu?

We've been sorting through a lot of raw IP header traces here and 
I noticed a lot of activity specifying TCP port 2.
Now this is a mystery.  RFC 1060 says ports 2-4 are unassigned.  
From the activity I'd guess they are being used by someones
workstation cluster and arn't really supposed to be out in the
internet but got there through a destination host addressing error.

Has there been systems built that use TCP port 2 for something or
does nayone know of someone using TCP port 2 for something?

			Tnx    -Hal


-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 05:02:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   How TCP differentiate node/process crash with network partition??


        Does anybody know how TCP differentiate node/process crash with
network partition problem? In particular, when socket return these 3 errors:
ENETDOWN (network is down), ENETUNREACH (network is unreachable) and
ENETRESET (network dropped connection on reset)? I also would like to know
how TCP detect and handle all these problems?
        I can't find any details about exception detection and handling from
most of the materials. Please helps!!
        Any repsonse please direct to me. I will summarize to the net if
enough interest. Thanks.

        Regards.

- Beng Hang Tay (email: taybengh@nusdiscs)

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Aug 90 21:02 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   How TCP differentiate node/process crash with network partition??

        Does anybody know how TCP differentiate node/process crash with
network partition problem? In particular, when socket return these 3 errors:
ENETDOWN (network is down), ENETUNREACH (network is unreachable) and
ENETRESET (network dropped connection on reset)? I also would like to know
how TCP detect and handle all these problems?
        I can't find any details about exception detection and handling from
most of the materials. Please helps!!
        Any repsonse please direct to me. I will summarize to the net if
enough interest. Thanks.

        Regards.

- Beng Hang Tay (email: taybengh@nusdiscs)
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Aug 90 18:09:35 PDT
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        Frank J. Robey <fjr@ulana.mitre.org>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Information wanted about SNMP based Network Managers
Given that some articles are appearing about it,
this week, I don't think I am giving away any secrets to 
mention that the group which is sponsoring an SNMP demo for
the Interop conference held a "hot staging" at NSL's OpenLab
facility, two weeks ago, and held another staging on the
East coast, last week.  About 30 vendors and about 45 SNMP
implementations were tested at OpenLab.  (There is an enormous
interoperability matrix that grew on one of the whiteboards
over the course of the week.)

It would be foolish to assert that all implementations worked
perfectly, but it certainly is clear that the protocol is
real, solid, etc.  
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Aug 90 09:03:58 +0200
From:      root@edfder1.edf.fr (Operator)
To:        tcp-ip@nic.ddn.mil
Cc:        dernetad@edfder1.edf.fr
Subject:   Please remove me from the distribution list, Thanks

I don't have anything to do whith this kind of messages !!!

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 16:55:37 GMT
From:      wuarchive!usc!bbn.com!craig@decwrl.dec.com  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM '90 Update
[This is a reminder that the advance registration deadline is 1 September.
Also, please note that the hotel has extended its registration deadline
for the SIGCOMM rate until August 30th].



                       SIGCOMM '90 - General Information


      SIGCOMM is the annual conference of the ACM Special Interest  Group
      in  Computer Communication.  This year's conference will be held at
      the University City Sheraton Hotel in  Philadelphia,  Pennsylvania,
      September  24-27th.  This program contains the advance schedule for
      the conference, registration information,  and  hotel  information.
      If  you  have  any  questions, feel free to contact the SIGCOMM '90
      conference committee, at 215-898-0016 or sigcomm90@cis.upenn.edu.


      SIGCOMM Conference Committee
           General Chair: Prof. David J. Farber (Univ. Pennsylvania)
           Program Chair: Phil Karn (Bellcore)
           Tutorial Chair: Prof. Magda El-Zarki (Univ. Pennsylvania)
           Local Arrangements: Dan Finnigan (Univ. Pennsylvania)
           Publicity Chair: Craig Partridge (Bolt Beranek and Newman)
           Advisors: Prof. Larry Landweber (Univ. Wisconsin), Prof. Chris
             Edmondson-Yurkanan (Univ. Texas),
             Dr. Vint Cerf (CNRI)

      SIGCOMM Program Committee
      Phil Karn (Bellcore), Ernst Biersack (Bellcore), Vint Cerf  (CNRI),
      Doug  Comer  (Purdue),  Jon  Crowcroft (Univ. College London), Gary
      Delp (IBM), John Demco (CDNnet),  Magda  El-Zarki  (Univ.  Pennsyl-
      vania), Zygmunt Haas (AT&T), Raj Jain (DEC), Larry Landweber (Univ.
      Wisconsin), Craig Partridge (BBN), Guru Parulkar (Washington  Univ.
      St.  Louis),  Larry L. Peterson (Univ. Arizona), Steve Pink (SICS),
      Marshall T. Rose (PSI), Harry Rudin (IBM), Jonathan M. Smith (Univ.
      Pennsylvania)



                   Tutorials: September 24th [9 AM to 5 PM]

      Tutorial #1: Protocols for High-Speed Networks
      Instructors: Harry Rudin and Van Jacobson

      Part A: High-Performance, Transport-Level Protocols (Rudin)

      Made possible by progress in  fiber-optic  and  VLSI  technologies,
      networks  offering  increasing  transmission capacity at decreasing
      error rates are becoming available.  New applications would benefit
      from this bandwidth but software protocol processing rates have not
      kept up with available raw transmission speed.  The presentation is
      a  comparative  survey of techniques used at the transport layer in
      eight representative protocols, most  of  which  were  designed  to
      improve  the  protocol  processing  rate.   The  protocols  are the
      relevant portions of the APPN, Datakit, Delta-t,  NETBLT,  OSI/TP4,
      TCP,  VMTP, and XTP architectures.  The main functions covered are:
      connection management, acknowledgements, flow  control,  and  error
      handling.

      Part B: Efficient TCP Implementation (Jacobson)

      Network protocol processing time has long been viewed as THE deter-
      miner  of  perceived  network  performance.   For at least one well
      known suite, the TCP and IP Internet protocols, recent  measurement
      has  shown  this  view  to be false:  The protocol *implementation*
      affects perceived performance, as does the way in which the network
      interface hardware interacts with the entire software/hardware sys-
      tem it is a part of.   But there is no inherent  performance  limit
      in  the TCP/IP protocols themselves.  In fact, a Unix TCP/IP imple-
      mentation has been constructed  that  runs  at  a  essentially  the
      information-theoretic  minimum  time  for  the  the  problem  being
      solved.
      This tutorial will describe an efficient TCP/IP  implementation  in
      agonizing  detail.   It  will describe where time goes in a typical
      implementation and what can be done  in  the  protocol  and  system
      software  to  reclaim  that  time.  It will discuss how the network
      interface hardware affects processing time and what hardware archi-
      tectures lead to cheap, efficient processing.
      Familiarity  with  the  TCP  and  IP  protocols  will  be  assumed.
      Although the implementation described will be based on a real, pro-
      duction, Berkeley Unix TCP/IP, no Unix  kernel  expertise  will  be
      assumed,  only  familiarity with operating system issues and imple-
      mentations.

      Harry Rudin received the B.E. and D.Eng. degrees from Yale  Univer-
      sity, where he also taught until 1964.  He worked at Bell Telephone
      Laboratories in the area of data communications until 1968.   Since
      then  he has been doing research in computer communications systems
      at the  Zurich  Research  Laboratory,  IBM  Research  Division,  in
      Rueschlikon,  Switzerland.   His interests are high-speed protocols
      and the use of formal description techniques for protocol  develop-
      ment.   He is a Fellow of the IEEE, Chairman of IFIP WG6.1, gives a
      graduate course on computer networks at the Swiss Federal Institute
      of  Technology  in  Zurich, and is a senior editor of Computer Net-
      works and ISDN Systems magazine.

      Van Jacobson received a MS in Physics and a BS in Mathematics  from
      the  University of Arizona in 1972.  Since then he has been a Staff
      Scientist in the Real  Time  Systems  Group  of  Lawrence  Berkeley
      Laboratory, developing high performance, distributed, data acquisi-
      tion and control systems.  Since 1984 his research has concentrated
      on  network  protocols  and  the  dynamics of large-scale networks.
      Since 1985 he has served as an adjunct lecturer in Computer Science
      at the University of California, Berkeley, and Stanford University.

      Tutorial #2: Object-Oriented Network Management and Control

      Instructors: Aurel Lazar and Mark W. Sylor

      The objective of this tutorial is to present a structured  approach
      to  problems  arising  in  network management and control.  Object-
      oriented modeling of communication networks.  Knowledge representa-
      tion,  entity/relationship  models for data representation.  Models
      of network management and control.  Managed and  managing  objects.
      Performance management.  Computational models for data abstraction.
      The OSI Information Model  and  the  Management  Information  Base.
      Knowledge  based monitoring and control.  Modeling examples of real
      networks.  DECnet - EMA Entities, TCP/IP - MIB definitions.   Exam-
      ples  will  also be drawn from AT&T's UNMA and IBM's Netview.  Sup-
      porting capabilities and architectures: testing, down/line loading,
      event logging, time service and naming.

      Aurel A. Lazar is a Professor of Electrical Engineering and  Direc-
      tor  of  the  Telecommunication  Networks  Laboratory  at  Columbia
      University.  He received the Dipl.-Ing.  degree  in  communications
      engineering  (Nachrichtentechnik)  from  the  Technische Hochschule
      Darmstadt, Darmstadt, Federal Republic of Germany, in 1976, and the
      Ph.D.  degree  in  information  sciences and systems from Princeton
      University, Princeton,  NJ,  in  1980.   During  the  80's  he  was
      involved  in  the  design and implementation of integrated networks
      supporting video, voice and data services.  Most recently,  he  was
      the  chief architect of MAGNET II a metropolitan area network based
      on Asynchronous Time Sharing.  Currently he is leading  the  design
      and  implementation of a real-time traffic control architecture for
      integrated networks.

      Mark W. Sylor is a member of the Enterprise Management Architecture
      group  at  Digital Equipment Corperation in Littleton, MA, where he
      works on the EMA Entity Model,  and  the  Phase  V  DECnet  Network
      Management  Specification. He has been a member of the ISO and ANSI
      committees working on OSI System Management, and was  formerly  the
      ANSI T5.4 ad-hoc group leader on the Structure of Management Infor-
      mation (SMI).  Mark has been involved with the design and implemen-
      tation of many of Digital's Network Management systems, in particu-
      lar the NMCC/DECnet Monitor, where he was  the  principle  designer
      and development supervisor.  Mark earned a B.A. degreee at S.U.N.Y.
      at Geneseo in 1971 and an M.S. degree at the  University  of  Notre
      Dame in 1975, both in Mathematics.



                     Technical Program: September 25-27th

      MONDAY, September 24th
      RECEPTION [7 PM to 9 PM]


      TUESDAY, September 25th

      Keynote Address: SIGCOMM AWARD Winner [9:00 - 9:30]

      Session #1: Congestion Control [10:00 - 12:00] Chair: Jon Smith
       Random Drop Congestion Control, A. Mankin (Mitre)
       A Stop-and-Go Queueing Framework for Congestion  Management,  S.J.
       Golestani (Bellcore)
       Virtual Clock: a new traffic control algorithm for packet  switch-
       ing networks, L. Zhang (Xerox PARC)
       Dynamic Adaptive Windows for High Speed Data Networks: Theory  and
       Simulations, D. Mitra (AT&T Bell Laboratories)

      Lunch [12:00 - 1:30]

      Session #2: Applications and  Distributed  Systems  [1:30  -  3:00]
      Chair: Larry Peterson
       Efficient At-Most-Once Messages Based on Synchronized  Clocks,  L.
       Shrira, J. Wroclawski, B. Liskov (MIT)
       Uniform Access to Internet Directory Services,  D.  Comer  (Purdue
       Univ.) and R.E. Droms (Bucknell Univ.)
       A Data Processing Performance Model for the OSI Application  Layer
       Protocols, T. Shiroshita (NTT)

      Session #3: MANs and WANs [3:30 - 5:00] Chair: Jon Crowcroft
       A Simple Multiple Access Protocol for Metropolitan Area  Networks,
       J.O. Limb (Hewlett-Packard)
       The BBN Dual Bus Protocol: Performance in a Wide Area Network,  W.
       Edmond, K. Seo, M. Leib, C. Topolcic (BBN)
       Machnet: A Simple Access Protocol for High Speed or Long Haul Com-
       munications, P. Jacquet, P. Muhlethaler (INRIA)

      SIGCOMM Business Meeting [5:15 - 6:00]


      WEDNESDAY, September 26th

      Session #4: Multimedia  Protocols  and  Protocol  Testing  [9:00  -
      10:30] Chair: Guru Parulkar
       Mechanisms for Integrated Voice and Data Conferencing, C. Ziegler,
       G. Weiss (Brooklyn College)
       Link Access Blocking in Very  Large  Multi-Media  Networks,  J.-F.
       Labourdette, G. Hart (Columbia Univ.)
       Protocol Conformance Test Generation Using Multiple UIO  Sequences
       with Overlapping, B. Yang, H. Ural (University of Ottawa)

      Session #5: High-Speed Switching [11:00  -  12:30]  Chair:  Zygmunt
      Haas
       Gauss: a simple high  performance  switch  architecture  for  ATM,
       R.J.F. de Vries (PTT Research, Netherlands)
       Protocol Implementation on  the  Nectar  Communication  Processor,
       E.C.  Cooper,  P.A.  Steenkiste,  R.D. Sansom, B.D. Zill (Carnegie
       Mellon Univ.)
       Pulsar: Non-blocking Packet Switching with  Shift-Register  Rings,
       G.J. Murakami, R.H. Campbell, M. Faiman (Univ. of Illinois)

      Lunch [12:30 - 2:00]

      Session #6: Routing and Flow Control [2:00 - 3:30] Chair: Raj Jain
       A Theoretical Analysis of Feedback Flow Control, S. Shenker (Xerox
       PARC)
       Shortest Path First with Emergency Exits, Z.  Wang,  J.  Crowcroft
       (University College London)
       Shortest Paths and Loop-Free Routing in Dynamic Networks, B. Awer-
       buch (MIT)

      Session #7: Gigabit Protocols [4:00 - 5:30] Chair: Craig Partridge
       Transport Protocol Processing at GBPS rates, N. Jain, M.  Schwartz
       (Columbia University)
       Architectural Considerations for a New  Generation  of  Protocols,
       D.D. Clark, D.L. Tennenhouse (MIT)
       Multiplexing Issues in Transport Protocol Design,  D.C.  Feldmeier
       (Bellcore)

      Banquet [6:30 - 8:00]


      THURSDAY, September 27th

      Session #8: Routing [9:00 - 10:30] Chair: Steve Pink
       Avoiding Name Resolution Loops and Duplications in Group  Communi-
       cations,  L.  Liang,  G.W. Neufeld, S.T. Chanson (Univ. of British
       Columbia)
       Design  of  Inter-Administrative  Domain  Routing   Protocols   L.
       Breslau, D. Estrin (USC)
       Topology Distribution Cost vs. Efficient  Routing  In  Large  Net-
       works, A. Bar-Noy, M. Gopal (IBM Watson)

      Session #9: LAN Issues [11:00 - 12:30] Chair: John Demco
       Efficient Use of Workstations for Passive Monitoring of Local Area
       Networks, J. Mogul (DEC)
       Performance Analysis of FDDI Token Ring Networks: Effect of Param-
       eters and Guidelines for Setting TTRT, R. Jain (DEC)
       Frame Content Independent Stripping for Token Rings, H.  Yang,  K.
       K. Ramakrishnan (DEC)

      Lunch [12:30 - 2:00]

      Session #10: Protocol Design [2:00 - 3:30] Chair: Ernst Biersack
       Fast Connection Establishment in High Speed Networks, I. Cidon, I.
       Gopal, A. Segall (IBM Watson and Technion)
       Reliable Broadband Communications Using a Burst Erasure Correcting
       Code, A.J. McAuley (Bellcore)
       An Inclusive Session Protocol for Distributed  Applications,  V.S.
       Sunderam (Emory Univ.)





      SIGCOMM '90 wishes to  thank  our  host  site,  the  University  of
      Pennsylvania  for  its  considerable  support  in  putting  on this
      conference.

      SIGCOMM '90 would also like to acknowledge the generous support  of
      the   following   corporations:  Advance  Computer  Communications,
      Bellcore, FTP Software,  Digital  Equipment  Corporation's  Network
      Systems Lab, and Interop Inc.

      Mark your calendars for SIGCOMM '91, September 3-6, 1991 at ETH Zurich,
      in Zurich, Switzerland.

*******************************************************************************

		    SIGCOMM '90 Advance Registration Form

    mail to: SIGCOMM '90, attn: Dan Finnigan, University of Pennsylvania,
	329 Moore Bldg, 200 South 33rd St, Philadelphia, PA 19104, USA

NAME ____________________________________

AFFILIATION _____________________________

ADDRESS _________________________________

     ____________________________________

     ____________________________________

Phone: __________________________________

E-mail: _________________________________

SIGCOMM/ACM Member # ____________________


Tutorials: 	before 9/1          after 9/1

    Members        $175               $230
    Non-Members    $230               $280
    Students       $100               $100   
    [student tutorial rates on space available basis]

	    Tutorial #1 ___  or Tutorial #2 ___                    $_____


Conference:     before 9/1          after 9/1

    Members        $230               $280
    Non-Members    $280               $330
    Students       $100               $100

								   $_____

							Total      $_____


    dietary restrictions   ___ kosher  ___ vegetarian



*******************************************************************************

		    SIGCOMM '90 Hotel Registration Form

    mail to: University City Sheraton Hotel, 36th and Chestnut St,
	    Philadelphia, PA 19104  (215-387-8000)

	Registration must be received 8/30 to ensure these rates


NAME ____________________________________     ___ Single $80 + tax

AFFILIATION _____________________________     ___ Double $90 + tax

ADDRESS _________________________________     Univ. of Pennsylvania CIS rate

     ____________________________________

     ____________________________________     

Phone: __________________________________ 

Arrival Date: ___________________________

Departure Date: _________________________


to guarantee arrival after 4PM please provide credit card information

Card Name & Number _______________________________   Expires _______

Name on Card _________________________________   Signature _________________
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 17:00:38 GMT
From:      appenzell.cs.wisc.edu!tim@speedy.wisc.edu  (Tim Theisen)
To:        tcp-ip@nic.ddn.mil
Subject:   Compressed SLIP on Ultrix 4.0
Since there has been considerable interest in running SLIP on DecStations,
I thought that I would share my experience with running Van Jacobson's
Compressed SLIP on my Decstation.  I have made the necessary changes to
run Compressed SLIP under Ultrix 4.0.  These include modifications to
match the way that ultrix handle mbufs.  I also fixed a problem that
occasionally caused panics on my DecStation.

I run the SLIP code daily and I am quite pleased with it.  I am making
my changes available to anyone who would like to use them.  Remember,
cslip is still a beta test version for hard-core network kernel hackers.
Also, I have NOT added any symmetric multiprocessing code.  This should
be installed on single processor machines only.

You pick up the whole distribution with my modifications.  Or, if you
already have the original cslip distribution, you can pick up the diffs
and use patch to update your sources.

cslip for ultrix 4.0 is available via anonymous ftp from shorty.cs.wisc.edu.

	pub/cslip.ultrix4.diffs.Z (just my modifications)
	pub/cslipbeta.tar.Z       (distribution with changes)

...Tim
--
Tim Theisen             Department of Computer Sciences
tim@cs.wisc.edu         University of Wisconsin-Madison
uwvax!tim               1210 West Dayton Street
(608)262-0438           Madison, WI   53706
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 18:31:20 GMT
From:      ddk@lanl.gov (David D Kaas)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Is lpd available on VMS?


	We have serveral UNIX based workstations that are connected
by ethernet to a DEC 785 running VMS.  The only common protocols we
currently support are TCP/IP.  We would like to transfer print
and plot files from the UNIX machines to the VMS machine.  Has anybody
ported lpd to VMS?  If not, is there any other program available to do
this?  Thanks in advance.

Thank You
Dave Kaas
D. O. E. Richland
Richland, Wa
(509) 376-6386
ddk@beta.lanl.gov
e41126%rlvax3.lanl.gov

-- 
Dave Kaas - D.O.E. Richland, Wa.
	e41126%rlvax3.xnet@lanl.gov

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 19:04:25 GMT
From:      usenet.ins.cwru.edu!abvax!sgtech!adnan@tut.cis.ohio-state.edu  (Adnan Yaqub)
To:        tcp-ip@nic.ddn.mil
Subject:   DEC Plays the Royalty Card
FYI:

In the August 1990 edition of Data Communications there is an article
titled "DEC Plays the Royalty Card" which describes how DEC has
patented its Local Area Transport (LAT) protocol and is now enforcing
its patent with licenses.  According to the article, "DEC's strategy
for enforcing its patent on LAT is to levy a royalty on every
LAT-based terminal server a third-party vendor makes.  Under the
licensing terms DEC announced last November, vendors wanting to use
LAT would have to pay $15 for each terminal port on every terminal
server they sell."

The article also said the DEC is seeking retroactive royalties.  It
went on to say that at press time 21 vendors have signed licensing
agreements and another 80 are in negotiations.  However, it mentioned
that two of the largest LAT terminal server manufacturers, Datability
Software Systems Inc. and Emulex Corp., have so far resisted DEC's
licensing program.
--
Adnan Yaqub (adnan@sgtech.uucp)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 19:36:48 GMT
From:      att!oucsace!oucsace.cs.ohiou.edu@ucbvax.Berkeley.EDU  (Dilip Tripathy)
To:        tcp-ip@nic.ddn.mil
Subject:   Need help with tcp-ip on an hp running MPE/XL



	Help!!

	   We are trying to communicate over an ethernet lan from a QNX
	box to an HP3000 running MPE/XL.  We are trying to use tcp-ip.
	We have tried several commercial packages (CMC and FASTech) which
	provide Berkeley socket development tools.  HP has told us that 
	their NETIPC protocol will communicate with a socket.  We have
	had no luck in doing this.  We have been told from two different
	HP sources conflicting stories on compatibility between NETIPC
	and Berkeley sockets.  One source says it will work, the other
	says it won't .  If knowledgable person out there knows
	the truth on this matter your help would be GREATLY appreciated.
	Does, or doesn't, NETIPC speak Berkeley sockets?  If so, what's
	the magic word that gets it to work?  If not then are there
	alternative protocols we can consider?  Any info is useful.  Please
	help set us straight.


	Thanks,


	Dilip and Jeff
	The Gap Eastern Distribution Center
	3434 Mineola Pike
	Erlanger, KY 41018 
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 90 20:05:16 GMT
From:      cunixf.cc.columbia.edu!cs.columbia.edu!ji@rutgers.edu  (John Ioannidis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: is  there a SLIP implementation for  interactive i386 unix ??
In article <57159@wlbr.IMSD.CONTEL.COM> mh@wlbr.imsd.contel.com.UUCP (Mike Hoegeman) writes:
>
>Does any kind soul know of a slip implementation for interactive's i386
>unix ? If you do please drop me a note. Thanks a bunch.
>

I believe InterActive is shipping SLIP with the host-based TCP/IP for 
release 2.2 of their software. 

If you want to look at actual code, I have a very rudimentary (read: somewhat
buggy) SLIP package for release 2.0.2 that I wrote last fall. You'll have 
to hack it a bit to integrate it in your environment. Other people have
also played with it.

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 5510
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 90 10:14:00 EDT
From:      "NEAL QUINN" <yx0quinn@nardacva.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Please remove me from the distribution list.  Tnx for the info.


-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 90 07:51:56 GMT
From:      pacbell.com!pacbell!ditka!kls@ucsd.edu  (Karl Swartz)
To:        tcp-ip@nic.ddn.mil
Subject:   Sun on 2 related Ethernets
The following diagram is a greatly simplified version of my current
network configuration:

                            +-------+    +-------+
                            |  Sun  |    |  VAX  |
                            +-------+    +-------+
                                |            |
    Ethernet A  ------+---------+------------+------ ...
                      |
                      |
      The        +---------+    +---------+
    Internet ----|  cisco  |    |  Sun-4  |
                 +---------+    +---------+
                      |              |
                      |              |
    Ethernet B  ------+---------+----+-------+------ ...
                                |            |
                            +-------+    +-------+
                            |  Sun  |    |  VAX  |
                            +-------+    +-------+

Ethernet A has a class B IP address and supports several hundred
machines, carrying DECnet, Appletalk, XNS, and probably other
stuff in addition to IP traffic.  Physically it is broken into a
number of segments connected via bridges.  Addresses are assigned
with subnets in mind though at present everybody (except bridges
and the cisco router) thinks the network is not subnetted.

Ethernet B is one of these subnets.  With the cisco doing proxy
ARPs, machines on this Ethernet haven't a clue that they aren't
on the main Ethernet.  Nothing exciting so far.

But now I'd like to put a second Ethernet board in the Sun-4 that
is our server and connect it to Ethernet A.  This guy is a server
for machines on both Ethernets and for various reasons having a
direct path to both nets seems to make sense.  (It won't publicize
these paths -- traffic from other machines will go via the cisco.)

How do I configure the two ports?  In particular, will the netmask
influence the broadcast address (since everybody else thinks the
broadcast address matches a full class B broadcast I don't want
the netmask interfering) and what is the simplest way to handle
the (static) routing?

Here's my first stab:

  ifconfig le0 134.79.112.16 netmask 255.255.240.0 broadcast 134.79.255.255 #B
  ifconfig le1 134.79.16.104 netmask 255.255.0.0   broadcast 134.79.255.255 #A

Will the broadcast be what I say or will it be changed according
to the netmask and address?

And can I get away with being clever, having two routes to the
134.79.112.0 subnet?  I'm hoping that the software will see le0 as
a better way to get to one part of the net reachable via le1, though
I'll be quite surprised if it actually works.  The alternative is
something like

  ifconfig le1 134.79.16.104 netmask 255.255.240.0 broadcast 134.79.255.255 #A
  route add 134.79.32.0 134.79.16.104 0
  route add 134.79.48.0 134.79.16.104 0
    ...

which I'd just as soon avoid if feasible.

Any answers as well as pointers on other things I might have missed
will be greatly appreciated.

BTW, for what it's worth, the Sun-4 server is a SPARCserver-390 and
is currently running SunOS 4.1.

-- 
Karl Swartz			 |UUCP	uunet!apple!zygot!ditka!kls
1-408/223-1308			 |INet	zygot!ditka!kls@apple.com
"I never let my schooling get in |BIX	kswartz
the way of my education."(Twain) |Snail	1738 Deer Creek Ct., San Jose CA 95148
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Aug 90 11:55:00 EDT
From:      TANNERC@CRL.AECL.CA
To:        tcp-ip@NIC.DDN.MIL
Subject:   WIN/TCP's LPD and Fortran Files
I am testing out the LPD option of WIN/TCP vs 5.1 on a VAX (VMS 5.3). One
of the client machines is a Control Data Cyber 990 running NOS/VE. We would
like to pass files using Fortran Carriage Control characters (in column 1)
to printers on the VAX.

Does a
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Aug 90 12:01:00 EDT
From:      TANNERC@CRL.AECL.CA
To:        tcp-ip@NIC.DDN.MIL
Subject:   WIN/TCP's LPD and Fortran Files
1. Please excuse my previous incomplete message. I pressed the wrong key.

2. I am testing the LPD option of WIN/TCP vs 5.1 on a VAX (VMS 5.3) and
it appears to be working well. One if its clients is a Control Data Cyber
990 running NOS/VE. We would like to pass files using Fortran Carriage Control
Characters from this machine to printers on the VAX (using the -f option
on the lpr command).

It appears as if the WIN/TCP LPD does not recognize this parameter. Has anybody
run into this, and is their a suitable work around?

Thanks in advance for your help.

Chris Tanner                    Tannerc@crl.aecl.ca
AECL-Chalk River
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 90 11:26:10 GMT
From:      gavron@alpha.sunquest.com (Ehud Gavron)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: Is lpd available on VMS?

In article <60724@lanl.gov>, ddk@lanl.gov (David D Kaas) writes...
> 
>	We have serveral UNIX based workstations that are connected
>by ethernet to a DEC 785 running VMS.  The only common protocols we
>currently support are TCP/IP.  We would like to transfer print
>and plot files from the UNIX machines to the VMS machine.  Has anybody
>ported lpd to VMS?

	The MultiNet product, produced by TGV Incorporated (1-800-TGV-3440)
	offers what you're looking for, and much much more.

	Contact me offline for more details.
> 
>Dave Kaas
>ddk@beta.lanl.gov
>e41126%rlvax3.lanl.gov
> 
	Ehud

/----------------------------------------------------------------------------\
| Ehud Gavron, Systems analyst  | gavron@vesta.sunquest.com      (Internet)  |
| Sunquest Information Systems  | uunet!sunquest!gavron          (UUCP)      |
| 930 N. Finance Center Drive   | gavron@lampf                   (BITNET)    |
| Tucson, Arizona, 85710        | (602)722-7546/885-7700 x.2546  (AT&Tnet)   |
|----------------------------------------------------------------------------|
|           your cute quote here                                             |
\----------------------------------------------------------------------------/

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 90 18:59:01 GMT
From:      naitc!karl@uunet.uu.net  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   PC/NFS and Packet Drivers, Alternate Telnet's
Well, we're getting there.

I have PC/NFS working with the Clarkson packet drivers.  I have NCSA Telnet
working with same (all the way to 2.3b8).  That's fine.

What isn't fine is that I can't manage coexistance.  I have tried the NCSA
version from Clarkson that is supposed to work with PC/NFS, and all I get is
a hung session when I connect (it does initialize properly).  Curiously
enough, I can hit <ALT>M a few times and get on, but it appears that no
processing is taking place until I go away from the display screen!

Needless to say, this is a real bummer.

Does anyone have any ideas for coexistance on these?  I'd really like to be
able to use NCSA Telnet and PC/NFS simultaneously, 'cause the Telnet that
Sun supplies with PC/NFS stinks to high heaven, and some of our users really
want things like the Tek mode and 3270 capability....

Ideas or further suggestions solicited.

--
Karl Denninger	AC Nielsen
kdenning@ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 90 19:16:42 GMT
From:      ncrlnk!ciss!lawday!jra@uunet.uu.net  (John.Ackermann@Dayton.NCR.COM)
To:        tcp-ip@nic.ddn.mil
Subject:   Ethernet FTP drivers needed
Forgive me if this doesn't make a lot of sense; I'm just getting my big toe
wet in the waters of internetworking!

I am running the ka9q ham radio TCP/IP software on both a unix and an ms-dos
system.  I have ethernet cards for both machines.

The ka9q software I'm using supports drivers written to the FTP standard, so
if I can find these drivers to match my machines and cards, I should be in 
business.

Can anyone point me to FTP drivers for a Novell NE-1000 card (pc) and --
probably the tougher one -- an Exelan 201 ethernet card running on an NCR
Tower 32/450 (with NCR's value-added SVR2 OS)?

Thanks for your help.



-- 
John R. Ackermann, Jr.						 (513) 445-2966
Law Department, NCR Corporation			     	     VoicePlus 622-2966
Dayton, Ohio					  John.Ackermann@Dayton.NCR.COM
         ***** Amateur Radio: ag9v@n8acv or ag9v@ag9v.AMPR.ORG *****
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 90 22:40:52 GMT
From:      genie!scooter@cgl.ucsf.edu  (Scooter Morris)
To:        tcp-ip@nic.ddn.mil
Subject:   Router Experiences Requested: Wellfleet vs. Cisco
Hi,
	We are in the process of evaluating routers for our network,
	which is a reasonably complicated one.  We currently use IP
	(of course), XNS, Ethertalk, Decnet, etc., etc.  We have a
	Cisco which is performing quite well, but seems much more
	expensive than the competing Wellfleet models.  We would
	like to get input from user's of both of these routers about
	the company's responsiveness, the performance, and the
	capabilities of the routers.  Our eventual goal is to
	use these routers to form an FDDI backbone and to route
	onto multiple ethernets.

	Thanks in advance,
		Scooter Morris
		Genentech, Inc.
		scooter@genie.gene.com
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 90 00:22:07 GMT
From:      n8emr!vlink01!root@tut.cis.ohio-state.edu  (V-Link System Administrator)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP & TCP/IP
Could some answer some questions on SLIP for me.  I am justing finding out
what TCP/IP is all about.

If a *NIX machine is running TCP/IP at location A, and also location B, how
does SLIP work between them.  What is it purpose?    

If Location A is hooked to a ethernet could location B get to whatever
applications that Location is doing via SLIP.  Please email me some 
information concerning SLIP and the use, please.

Thanks.

-- 
V-Link Corporation             | V-Link Sys Admin
1828 Darrow Drive              |----------------------------------
Powell, OH   43065-9261        | Local : root
(614)792-6363                  | Remote: root@vlink01.UUCP
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 90 02:18:20 GMT
From:      wisner@hayes.fai.alaska.edu (Bill Wisner)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: Is lpd available on VMS?

Wollongong's TCP/IP package also has an lpd implementation.

Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775
"In fact, Penn State is a subsidiary of McDonalds that sells degrees instead
of hamburgers." -- Paul Callahan <callahan@crabcake.cs.jhu.edu>

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Aug 90 12:04:54 -0500
From:      mrf@ftp.com
To:        genie!scooter@cgl.ucsf.edu  (Scooter Morris)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Router Experiences Requested: Wellfleet vs. Cisco
We have a Wellfleet router in our support area at FTP Software.  We
initially had some difficulty getting it configured, but Wellfleet
was very helpful.  They updated our software, and now the router
works well.

We are routing ethernet to Token Ring.  Unfortunately, our ethernet
is not very busy yet, so I cannot give you much information about
the performance of the router under stress.  However, I can tell
you that they have been very responsive to our difficulties, even
ones that turned out to be our own fault.

Margaret Forsythe
Technical Support Manager
FTP Software, Inc.

mrf@ftp.com
(617) 246-0900 x100
FAX:  (617) 246-0901

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 23 August 1990 9:36am ET
From:      "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   IBM VM TCP/IP performance (part 1)
A month ago, I wrote a very short message to this group concerning
NIS.NSF.NET, saying "It certainly has a *terrible* implementation
of TCP/IP."  I quickly received the following private message:

> From: "Bill Rubin" <RUBIN%YKTVMZ.BITNET@CUNYVM.CUNY.EDU>
> To:   09998was@ibm.cl.msu.edu
> Subject: Re: How to get RFC documents
>
> I am probably asking for trouble here, but would you like to tell me
> exactly what you find so distasteful about our TCP/IP product?  We have
> a very large number of customers who I believe are very satisfied with
> it.  If you don't like our anonymous FTP implementation, I can believe
> that, it's nothing to be proud of, but it's better than nothing, which
> is what we offered before we added the feature.  Perhaps you should
> have just said we have a *terrible* implementation of anonymous FTP.

Well, I spent about 15 hours benchmarking NIS.NSF.NET against other
machines on the internet, carefully documenting the packet traces,
and passing my observations on to IBM.  I did this at my own expense,
as a matter of curiousity, because I thought that the folks who were
sending the messages were "real programmers" who were really interested
in getting it right (a Jay Elinsky was also involved).

Instead, my messages were sent to Merit, the operator of NSF.NET,
causing a political uproar.  I personally do not appreciate finger pointing
as a substitute for action, and in this case it was grossly unjustified.

Let's keep the record straight: the folks at Merit *are* "real programmers".
In the past, when I have uncovered a problem they have stayed up until
5:30 in the morning tracking it down (and I suspect without overtime).
The internet has been vastly improved during the tenure of their operation
of the NSF net.

The NIS.NSF.NET hardware was contributed by IBM, and I understand
that the software is the latest IBM release.  My benchmark was carefully
conducted for a direct comparison of the TCP/IP implementations,
under the worst possible circumstances to make implementation flaws
stand out clearly.  The failures demonstrated are plainly of the
host, and not of the environment.

As to the "very satisfied" customers, I will point out that MSU has
not yet installed the VM TCP/IP product, even though it came "free"
with other products.  And I occasionally read "IBMTCP-L" on bitnet.
'Nuf said.

On to the results....

Bill Simpson
    09998was@ibm.cl.msu.edu
    09998was@msu.bitnet
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 90 06:31:54 GMT
From:      gavron@alpha.sunquest.com (Ehud Gavron)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: Is lpd available on VMS?

In article <1990Aug23.021820.18667@hayes.fai.alaska.edu>, wisner@hayes.fai.alaska.edu (Bill Wisner) writes...
#Wollongong's TCP/IP package also has an lpd implementation.
# 
	That's like saying "And Yugo also sells cars..."

	:-)

	Ehud

/----------------------------------------------------------------------------\
| Ehud Gavron, Systems analyst  | gavron@vesta.sunquest.com      (Internet)  |
| Sunquest Information Systems  | uunet!sunquest!gavron          (UUCP)      |
| 930 N. Finance Center Drive   | gavron@lampf                   (BITNET)    |
| Tucson, Arizona, 85710        | (602)722-7546/885-7700 x.2546  (AT&Tnet)   |
|----------------------------------------------------------------------------|
|           your cute quote here                                             |
 \----------------------------------------------------------------------------/

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 23 August 1990 11:53am ET
From:      "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   IBM VM TCP/IP performance (part 2)
The benchmark was conducted over the noisiest line I know of, at slow
speeds, with small packets, with both large and small windows, to
encourage packet loss and demonstrate transmission and syncronization
handling.  With the exception of NIC.NSF.NET, all testing was done
on a single connection, one test at a time, to eliminate modem
or time of day variability.

The packet size was 232 bytes.  Maximum transfer bandwidth was:
at 9600 bps: 768 bytes/second
at 1200 bps:  96 bytes/second

NIS.NSF.NET [35.1.1.48] is an IBM 4381P02 running VM/HPO-5 FAL 1.2.1
(according to Merit -- there is no host DNS record).
I understand it to be a lightly loaded machine.  The traces show
less than MSS sized packets, too many retransmissions, timeouts of
20 seconds or more, and failure to combine ACKs with bidirectional data.
The 10 minute transmission timeout causes many RFCs to be unavailable
over serial lines (but may be configurable).  The dir LIST facility
is excrutiatingly slow.

at 9600 bps: 320, 353, 299, 382 bytes/second
at 1200 bps:  54,  49

MERIT.EDU [35.1.1.42] is a Sun running "FTP server (version 4.115 ..."
(again, no host record)
I understand it to be a heavily loaded machine and therefore to
be running rather slow in its response times.  It is located
on the same ethernet as NIS.NSF.NET, so I thought that it would
make a good comparison for round trip baseline.

at 1200 bps:  77,  85

TERMINATOR.CC.UMICH.EDU [35.1.33.8] is a Sun-3/160 running
"FTP server (version 4.172 ..."
It is located a little farther away (6 hops) in another building at UMich.
The distance didn't seem to have any effect.

at 1200 bps:  92

So I thought that I'd try a little farther!
THUMPER.BELLCORE.COM [128.96.41.1] is 8 hops father away than NIS.NSF.NET,
over NSFnet and JVNCnet.  The host record says it is a VAX-8650
running BSD4.2, but the FTP message was "SunOS 4.1", so who knows?

at 1200 bps:  84

The next week, just for jollies, I tried NIC.DDN.MIL.
It's often difficult to get to, through some incredibly congested
gateways.  I did this at 16:00 EDT, which should be right in the
middle of their working day out west.  I pinged it for 10 minutes,
in 20 sec intervals for a srtt of 2.420 sec and mdev of 0.605 sec;
not counting that 2/3 of the packets were lost!  The host record says
it's a DEC 2060 running Tops20.

at 1200 bps:  73,  78,  74,  76


CONCLUSION:
IBM-FAL for VM runs at 1/2 the speed of many of its competitors.
It fails to meet several host requirements, not just for TCP/IP
but for FTP and SMTP as well.

Unfortunately, the only product which I am aware of with worse performance
is Spartacus KNET, also for VM.

For the good of the user community, I would recommend to Merit that
the RFC mirror be moved to a more capable machine.

Bill Simpson
    09998was@ibm.cl.msu.edu
    09998was@msu.bitnet
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 90 13:38:18 GMT
From:      mcsun!unido!uniol!hewett@uunet.uu.net  (Andy Hewett)
To:        tcp-ip@nic.ddn.mil
Subject:   The LPI interface between IP and a Streams device driver, where?
Environment
	Interactive Unix 386/ix 2.02 (V.3.2)
      	but probably also generic SysV.3.2

Does anybody know how I can get hold of a description of the 
Link Provider Interface which is used for passing messages 
between the IP driver and a Streams device driver?  The structures
are to be found in /usr/include/sys/lihdr.h (on 386/ix) and are
rather loosely described in llc(7).  Sorry if I'm a bit confused about
terms here but llc(7) calls this interface the "Link Provider Interface 
(LPI)" and lihdr.h calls it "Data Link Level Interface" !?!?!

I have figured out enough to get a driver for an ISDN card working with
tcp/ip, but there are several details that evade me (particularly the LSAP
portion of the remote address passed down from IP in a DL_UNITDATA_REQ).

In the next version of the driver I would like to get these details
straight and be able to link into the llc(7) driver if possible to 
avoid duplicate code. Does anybody have any information or hints on 
how to use the llc driver?

Perhaps I should mention that I have the Streams manuals (Primer,
Programmers Guide), Network Programmers Guide and BCI Driver Reference
Manual but they don't have anything on these topics.

Thanks in advance.

Andy Hewett.

-- 
/--------------------------------------------------------------------------\
| Andy Hewett                           	|  FB-10 Informatik        |
|                                       	|  Universitaet Oldenburg  |
| INET: hewett@informatik.uni-oldenburg.de	|  Postfach 2503           |
| UUCP: hewett@uniol.UUCP               	|  2900 Oldenburg          |
|      ... uunet!unido!uniol!hewett     	|  West Germany            |
| BITNET/EARN: 716697@DOLUNI11			|  TEL: (0441) 7982990/1   |
| Please use bitnet for Huge mail.		|  FAX: (0441) 7982155	   |
\--------------------------------------------------------------------------/
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Aug 1990 13:36:04 MEST
From:      Jochen Kornitzky <korni@sietec1.sietec.de>
To:        Karl Denninger <karl@naitc.uucp>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: PC/NFS and Packet Drivers, Alternate Telnet's
+---- Karl Denninger about "PC/NFS and Packet Drivers, Alternate Tel" :
|
| I have PC/NFS working with the Clarkson packet drivers.  I have NCSA Telnet
| working with same (all the way to 2.3b8).  That's fine.
| 
| What isn't fine is that I can't manage coexistance.  ...
| 
| Does anyone have any ideas for coexistance on these? 
|
+----

The problem lies in the packet driver. Although it is designed to serve
multiple clients it is unable to provide several clients with
THE SAME packets. This is neccessary because the PC/NFS adaptor (PACKET.SYS)
registers for ALL types of incoming packets (also those for the telnet
running in foreground).

We have a solution here that consists of a modified packet driver.
This one is able to deliver incoming packets to ALL clients that have
registered for a specific type by just copying it to the various
client areas.

The modification changes only HEAD.ASM common to every
ethernet card driver. For us it works fine with PC/NFS with WD8003E card.

If there is great interest I'd like to know where to post it otherwise
Karl, just ask me to send it to you.

	Jochen

-- 
+--Jochen Kornitzky-------+---------------------------------------+-----------+
|                         |                                       |        .  |
|  SMAIL:                 |  EMAIL:                               |  .        |
|  Sietec GmbH & Co. OHG  |                                       |        .  |
|  z.Hd. Jochen Kornitzky |  korni@sietec1.sietec.de              |     .     |
|  Nonnendammallee 101    |  ...!uunet!unido!sietec1!korni        |           |
|  D-1000 Berlin 13       |  Postmaster for *.sietec.de           |  .     .  |
|  Germany                |                                       |           |
+-------------------------+---------------------------------------+-----------+
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 90 16:04:27 GMT
From:      09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
To:        comp.protocols.tcp-ip
Subject:   IBM VM TCP/IP performance (part 1)

A month ago, I wrote a very short message to this group concerning
NIS.NSF.NET, saying "It certainly has a *terrible* implementation
of TCP/IP."  I quickly received the following private message:

> From: "Bill Rubin" <RUBIN%YKTVMZ.BITNET@CUNYVM.CUNY.EDU>
> To:   09998was@ibm.cl.msu.edu
> Subject: Re: How to get RFC documents
>
> I am probably asking for trouble here, but would you like to tell me
> exactly what you find so distasteful about our TCP/IP product?  We have
> a very large number of customers who I believe are very satisfied with
> it.  If you don't like our anonymous FTP implementation, I can believe
> that, it's nothing to be proud of, but it's better than nothing, which
> is what we offered before we added the feature.  Perhaps you should
> have just said we have a *terrible* implementation of anonymous FTP.

Well, I spent about 15 hours benchmarking NIS.NSF.NET against other
machines on the internet, carefully documenting the packet traces,
and passing my observations on to IBM.  I did this at my own expense,
as a matter of curiousity, because I thought that the folks who were
sending the messages were "real programmers" who were really interested
in getting it right (a Jay Elinsky was also involved).

Instead, my messages were sent to Merit, the operator of NSF.NET,
causing a political uproar.  I personally do not appreciate finger pointing
as a substitute for action, and in this case it was grossly unjustified.

Let's keep the record straight: the folks at Merit *are* "real programmers".
In the past, when I have uncovered a problem they have stayed up until
5:30 in the morning tracking it down (and I suspect without overtime).
The internet has been vastly improved during the tenure of their operation
of the NSF net.

The NIS.NSF.NET hardware was contributed by IBM, and I understand
that the software is the latest IBM release.  My benchmark was carefully
conducted for a direct comparison of the TCP/IP implementations,
under the worst possible circumstances to make implementation flaws
stand out clearly.  The failures demonstrated are plainly of the
host, and not of the environment.

As to the "very satisfied" customers, I will point out that MSU has
not yet installed the VM TCP/IP product, even though it came "free"
with other products.  And I occasionally read "IBMTCP-L" on bitnet.
'Nuf said.

On to the results....

Bill Simpson
    09998was@ibm.cl.msu.edu
    09998was@msu.bitnet

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 90 17:59:06 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!ub!sunybcs!palter@ucsd.edu  (Bill Palter)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: WIN/TCP's LPD and Fortran Files
In article <46D0FB332D7F204855@CRL.AECL.CA>, TANNERC@CRL.AECL.CA writes:
> 1. Please excuse my previous incomplete message. I pressed the wrong key.
> 
> 2. I am testing the LPD option of WIN/TCP vs 5.1 on a VAX (VMS 5.3) and
> it appears to be working well. One if its clients is a Control Data Cyber
> 990 running NOS/VE. We would like to pass files using Fortran Carriage
Control
> Characters from this machine to printers on the VAX (using the -f
option
> on the lpr command).
> 
> It appears as if the WIN/TCP LPD does not recognize this parameter.
Has anybody
> run into this, and is their a suitable work around?
> 
> Thanks in advance for your help.
> 
> Chris Tanner                    Tannerc@crl.aecl.ca
> AECL-Chalk River








	The current release does not support fortran charrage control files,
 the next release should support them.






Bill Palter
Palter@twg.com
The Wollongong Group
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Aug 90 23:17 EST
From:      Bob Stine <0004219666@mcimail.com>
To:        "E Drew Einhorn ADV.SCI.Inc" <unmvax!ariel.unm.edu!hydra.unm.edu!einhorn@ucbvax.berkeley.edu>
Cc:        tcp ip <tcp-ip@nic.ddn.mil>
Subject:   Re: need enhanced ping
Drew,

The capabilities and availability of various flavors of ping
and related tools are described in RFC 1147.

- Bob Stine

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 90 18:37:34 GMT
From:      09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
To:        comp.protocols.tcp-ip
Subject:   IBM VM TCP/IP performance (part 2)

The benchmark was conducted over the noisiest line I know of, at slow
speeds, with small packets, with both large and small windows, to
encourage packet loss and demonstrate transmission and syncronization
handling.  With the exception of NIC.NSF.NET, all testing was done
on a single connection, one test at a time, to eliminate modem
or time of day variability.

The packet size was 232 bytes.  Maximum transfer bandwidth was:
at 9600 bps: 768 bytes/second
at 1200 bps:  96 bytes/second

NIS.NSF.NET [35.1.1.48] is an IBM 4381P02 running VM/HPO-5 FAL 1.2.1
(according to Merit -- there is no host DNS record).
I understand it to be a lightly loaded machine.  The traces show
less than MSS sized packets, too many retransmissions, timeouts of
20 seconds or more, and failure to combine ACKs with bidirectional data.
The 10 minute transmission timeout causes many RFCs to be unavailable
over serial lines (but may be configurable).  The dir LIST facility
is excrutiatingly slow.

at 9600 bps: 320, 353, 299, 382 bytes/second
at 1200 bps:  54,  49

MERIT.EDU [35.1.1.42] is a Sun running "FTP server (version 4.115 ..."
(again, no host record)
I understand it to be a heavily loaded machine and therefore to
be running rather slow in its response times.  It is located
on the same ethernet as NIS.NSF.NET, so I thought that it would
make a good comparison for round trip baseline.

at 1200 bps:  77,  85

TERMINATOR.CC.UMICH.EDU [35.1.33.8] is a Sun-3/160 running
"FTP server (version 4.172 ..."
It is located a little farther away (6 hops) in another building at UMich.
The distance didn't seem to have any effect.

at 1200 bps:  92

So I thought that I'd try a little farther!
THUMPER.BELLCORE.COM [128.96.41.1] is 8 hops father away than NIS.NSF.NET,
over NSFnet and JVNCnet.  The host record says it is a VAX-8650
running BSD4.2, but the FTP message was "SunOS 4.1", so who knows?

at 1200 bps:  84

The next week, just for jollies, I tried NIC.DDN.MIL.
It's often difficult to get to, through some incredibly congested
gateways.  I did this at 16:00 EDT, which should be right in the
middle of their working day out west.  I pinged it for 10 minutes,
in 20 sec intervals for a srtt of 2.420 sec and mdev of 0.605 sec;
not counting that 2/3 of the packets were lost!  The host record says
it's a DEC 2060 running Tops20.

at 1200 bps:  73,  78,  74,  76


CONCLUSION:
IBM-FAL for VM runs at 1/2 the speed of many of its competitors.
It fails to meet several host requirements, not just for TCP/IP
but for FTP and SMTP as well.

Unfortunately, the only product which I am aware of with worse performance
is Spartacus KNET, also for VM.

For the good of the user community, I would recommend to Merit that
the RFC mirror be moved to a more capable machine.

Bill Simpson
    09998was@ibm.cl.msu.edu
    09998was@msu.bitnet

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 90 22:50:20 GMT
From:      cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bcars85!linegar@tut.cis.ohio-state.edu  (Derick Linegar)
To:        tcp-ip@nic.ddn.mil
Subject:   Doing default routing on 2 interfaces ???

I have an interesting routing question. First the setup:

A hosts with 2 ethernet interfaces, IP forwarding disabled, and not
running any routing daemons, such as routed or gated. I am trying 
to make this host smart by doing default routing & proxy-ARPing on
both interfaces. (See scenario)


Scenario:

		     Internet
		         |
		    -----------
			|
			|
		     +-------+
		     |  A    |
		     | Host  |
		     |  B    |
		     +-------+
			|
			|
		   ------------- 42.128 subnet
		     |
		     |
		  +-------+
		  |  A    |
		  | router|
		  |  B    |
		  +-------+
		     |
		     |
		  Other 42 subnets


Now, I figured by adding 2 default routes (1 for each interface) the
machine would ARP on both interfaces, and whoever responds first, it
will use. No go, as I found out, it will always use the first default
route in the routing table. 

I then decided to do default routing on one interface (A on the hosts) and
tell the machine how to get to network 42 through interface B on the hosts
to the "gateway" router. (route add net 42.0.0.0 router-address-A 1) This
also does not seem to work, as the hosts ARP's on interface A!

I got this setup to work, but by adding manually all the subnets on net 42!
I cannot see this to be an acceptable solution, as we have tons of subnets,
and adding them statically, I consider to be a bad idea (especially when
we have multiple paths to these subnets).

Why can't I add a static route for the hosts, telling it how to route
for all other subnets on 42, (except for the directly connected one) to
the router? I can live with one static route for all other subnets, but
adding one for each subnet is perversive...

				-derick-
--
#include <disclaimer.h>
Derick Linegar,     Internet Systems 4P27,              Bell-Northern Research 
BITNET: LINEGAR@BNR.ca                                  P.O. Box 3511 Station C
UUCP:   ...uunet!bnrgate!bcars85!linegar		Ottawa ONT. K1Y 4H7
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 90 23:02:07 GMT
From:      unmvax!ariel.unm.edu!hydra.unm.edu!einhorn@ucbvax.Berkeley.EDU  (E Drew Einhorn ADV.SCI.Inc)
To:        tcp-ip@nic.ddn.mil
Subject:   need enhanced ping
To support debugging I would like to obtain an enhanced version of
ping.  If one is not available I would like to try writing one.  I
would prefer starting from a working vanilla version of ping.  Is the
source available for anonymous ftp?

Desired features include:

	1)  Turning on the record route option in the IP header of the
	ICMP echo request packet.

	2)  Decoding the route recorded in the ICMP echo reply
	generated by the request.  Use pointer queries to obtain the
	name of networks/machines/gateways from nameserver(s).  Will
	try gethostbyaddr() first, my FM collection is not consistent
	about whether gethostbyaddr() talks to nameservers(s) or only
	examines /etc/hosts.

	3) Collect statistics by measuring round trip time to first
	IP address on route, 2nd address on route, ...

Thanks

--
 einhorn@hydra.unm.edu
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 90 01:54:52 GMT
From:      cs!samadams.princeton.edu@princeton.edu  (Tom Reingold)
To:        tcp-ip@nic.ddn.mil
Subject:   Are sockets the wave of the future?
At my job, we are about to write some applications for running over
TCP/IP on Unix hosts.  We would like to think ahead with portability in
mind.  One day, our code may run on a non-unix host.  And if we write
it in sockets, we may run against a version that is built upon and
supports only STREAMS.  Or will we?

1. What implementations are built on STREAMS?

2. Are they new or old?

3. Are all TCP/IP suites done with sockets nowadays?

4. Is there a reason to consider implementing our code in STREAMS?

5. Currently, our hosts run System V release 3.[23] and have both
libraries.  Which is "the way" to go?

--
	Tom Reingold
	tr@samadams.princeton.edu
	rutgers!princeton!samadams!tr
	201-577-5814
	"Brew strength depends upon the
	 amount of coffee used." -Black&Decker
-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 90 03:50:07 GMT
From:      dimacs.rutgers.edu!action.rutgers.edu!dpz@seismo.css.gov  (David Paul Zimmerman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: need enhanced ping
I can help you with 1) and 2).  A couple of years ago I made modifications to
the Berkeley ping to allow writing and reading of route-record packets.  That
is dimacs.rutgers.edu:~ftp/pub/ping.shar.  I also found that 4.3BSD hosts
didn't do the right thing per the RFCs with ICMP echo request packets that had
record-route set (and by association, timestamp request packets also).
dimacs.rutgers.edu:~ftp/pub/rr.shar are kernel changes to 4.3BSD to deal with
that.  Although I've submitted both back to Berkeley, I don't know if they've
made 4.3-Tahoe, -Reno, or 4.4.  I've also gotten a report of a portability bug
for rr.shar, but haven't dealt with it yet (change the caddr_t definition of
"opts" to u_char *).

			David (from the Norse meaning "hacker of wire")
-- 
David Paul Zimmerman                                     dpz@dimacs.rutgers.edu
Systems Programmer						    rutgers!dpz
Rutgers Univ Center for Discrete Math and Theoretical Computer Science (DIMACS)
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 90 04:17:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: need enhanced ping

Drew,

The capabilities and availability of various flavors of ping
and related tools are described in RFC 1147.

- Bob Stine

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Aug 90 10:34:41 MDT
From:      E Drew Einhorn ADV.SCI.Inc <einhorn%hydra.unm.edu@ariel.unm.edu>
To:        0004219666%mcimail.com%ucbvax@unmvax.cs.unm.edu, einhorn%hydra.unm.edu%ariel.unm.edu@unmvax.cs.unm.edu
Cc:        <tcp-ip@nic.ddn.mil>, ip@mcimail.com, tcp@mcimail.com
Subject:   Re: need enhanced ping
Thanks
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Aug 90 11:19:12 EDT
From:      David Rankin <drankin%westford.ccur.com@RELAY.CS.NET>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Please remove me from this list.

Please remove me from this mailing list.

David
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Aug 90 15:12:12 EDT
From:      "James H. Coombs" <JAZBO@brownvm.brown.edu>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        CS!SAMADAMS.PRINCETON.EDU@PRINCETON.EDU
Subject:   Re: Are sockets the wave of the future?

>
>Date:         Fri, 24 Aug 90 01:54:52 GMT
>From:         Tom Reingold <cs!samadams.princeton.edu@PRINCETON.EDU>
>
>At my job, we are about to write some applications for running over
>TCP/IP on Unix hosts.  We would like to think ahead with portability in
>mind.

>3. Are all TCP/IP suites done with sockets nowadays?

Definitely not.

>5. Currently, our hosts run System V release 3.[23] and have both
>libraries.  Which is "the way" to go?

Sun now states that no new applications should be developed at the socket
level.  They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1).  RPC
has several advantages:

1. The library is available through ftp.
2. You can work at a high level with minimal concern for networking details.
3. Client and server can be bound together into a single process without
   modifying the code (although you may want to eliminate the code that
   would normally establish a connection).
4. Various transport mechanisms may be used under the RPC interface.  The
   package supports sockets and raw buffers.  Future versions will probably
   use TIL(?), which in turn provides some independence from lower levels.
5. The application-specific protocol can be developed relatively invisibly
   by defining c-type structures.  The programmer does not have to think
   about sending a long, using htonl(), etc.  If it is convenient to change
   a long to a short, then rebuilding the application should update both the
   client and the server (assuming the proper make dependencies).  One is
   less likely to try to send a long to a process that is waiting for a short.

On the down side:

1. It is a little trickier to do something like have the server fork
   immediately after accepting a connection.
2. There may remain a need to drop down to the transport layer for such
   details as keepalive options on sockets.

Whatever you decide, you should take a good look at RPC.  I haven't been fully
converted yet, but I will certainly be influenced by the library even if I
decide to stay with sockets (and my object-oriented server building block).

--Jim

Dr. James H. Coombs
Chief Architect
Institute for Research in Information and Scholarship (IRIS)
Brown University, Box 1946
Providence, RI 02912
jazbo@brownvm.bitnet
Acknowledge-To: <JAZBO@BROWNVM>
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 90 13:52:21 GMT
From:      amdcad!mozart.amd.com!neihart@ucbvax.Berkeley.EDU  (Carl Neihart)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Doing default routing on 2 interfaces ???
In article <linegar.651451820@bcars85> linegar@bcars85.bnr.ca (Derick Linegar) writes:
>
>Why can't I add a static route for the hosts, telling it how to route
>for all other subnets on 42, (except for the directly connected one) to
>the router? I can live with one static route for all other subnets, but
>adding one for each subnet is perversive...

I do not know what kind of router you are using, but if you are using cisco
routers, add an ethernet interface in the router and connect it to the internet
directly.  You will be able to accomplish the necessary routing arrangement very 
cleanly with this setup.  Unfortunately, Unix systems are not designed to have
multiple ethernet interfaces cleanly.


   __            _    _ __
  /  )          //   ' )  )      /           _/_
 /    __.  __  //     /  / _  o /_  __.  __  /
(__/ (_/|_/ (_</__   /  (_</_<_/ /_(_/|_/ (_<__

+-----------------------------------------------------------+
| Carl Neihart, Sr. Networking Engineer                     |
| Advanced Micro Devices, Inc.                              |
| Austin, Texas                                             |
| voice   (512) 462-4050                                    |
| fax     (512) 462-5156                                    |
| E-mail address:   neihart@mozart.AMD.COM                  |
+-----------------------------------------------------------+
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 90 15:58:49 GMT
From:      afsg!ron@uunet.uu.net  (Ron Flax)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP & Routing
What is the proper way to set up routing for a SLIP link on a Class C
network.  Suppose the network number is 192.33.20 and the SLIP link is
between a SLIP server at 192.33.20.201 and a SLIP client at
192.33.20.202.  Also suppose that the server has an ethernet
interface at address 192.33.20.4 and can talk to a gateway at
192.33.20.1 to get to the outside world over that interface.

What should the routes be on the SLIP server and client machines so
that traffic from the client can pass to the ethernet side and beyond
of the server machine?

Do I need to setup a netmask? and if so what would be
reasonable in this case?

Thanks in advance.

--
Ron Flax
ron@afsg.apple.com	
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 90 19:12:12 GMT
From:      JAZBO@BROWNVM.BROWN.EDU ("James H. Coombs")
To:        comp.protocols.tcp-ip
Subject:   Re: Are sockets the wave of the future?


>
>Date:         Fri, 24 Aug 90 01:54:52 GMT
>From:         Tom Reingold <cs!samadams.princeton.edu@PRINCETON.EDU>
>
>At my job, we are about to write some applications for running over
>TCP/IP on Unix hosts.  We would like to think ahead with portability in
>mind.
 
>3. Are all TCP/IP suites done with sockets nowadays?

Definitely not.

>5. Currently, our hosts run System V release 3.[23] and have both
>libraries.  Which is "the way" to go?

Sun now states that no new applications should be developed at the socket
level.  They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1).  RPC
has several advantages:

1. The library is available through ftp.
2. You can work at a high level with minimal concern for networking details.
3. Client and server can be bound together into a single process without
   modifying the code (although you may want to eliminate the code that
   would normally establish a connection).
4. Various transport mechanisms may be used under the RPC interface.  The
   package supports sockets and raw buffers.  Future versions will probably
   use TIL(?), which in turn provides some independence from lower levels.
5. The application-specific protocol can be developed relatively invisibly
   by defining c-type structures.  The programmer does not have to think
   about sending a long, using htonl(), etc.  If it is convenient to change
   a long to a short, then rebuilding the application should update both the
   client and the server (assuming the proper make dependencies).  One is
   less likely to try to send a long to a process that is waiting for a short.

On the down side:

1. It is a little trickier to do something like have the server fork
   immediately after accepting a connection.
2. There may remain a need to drop down to the transport layer for such
   details as keepalive options on sockets.

Whatever you decide, you should take a good look at RPC.  I haven't been fully
converted yet, but I will certainly be influenced by the library even if I
decide to stay with sockets (and my object-oriented server building block).

--Jim

Dr. James H. Coombs
Chief Architect
Institute for Research in Information and Scholarship (IRIS)
Brown University, Box 1946
Providence, RI 02912
jazbo@brownvm.bitnet
Acknowledge-To: <JAZBO@BROWNVM>

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 90 19:21:31 GMT
From:      nraoaoc@jupiter.nmt.edu (NRAO Array Operations Center)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   ftp problems with CMU-TEK TCP/IP

We are running CMU-TEK TCP/IP V6.4 on our VAXes (VMS V5.1-1), and are
finding that when transferring files from a VAX to a UNIX system, mget 
fails at something over 100 files. I can't find anything in the documentation 
about limitations on numbers or total size of file transfers. Has anyone
seen this sort of behavior, or know what might be causing it?

Thank you. 
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                    Socorro NM
                            rmilner@zia.aoc.nrao.edu

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 90 20:35:20 GMT
From:      swrinde!cs.utexas.edu!sun-barr!newstop!jethro!germania.Sun.COM!rodk@ucsd.edu  (Rod King (Sun HQ Consulting))
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <2117@rossignol.Princeton.EDU> tr@samadams.princeton.edu (Tom Reingold) writes:
>At my job, we are about to write some applications for running over
>TCP/IP on Unix hosts.  We would like to think ahead with portability in
>mind.  One day, our code may run on a non-unix host.  And if we write
>it in sockets, we may run against a version that is built upon and
>supports only STREAMS.  Or will we?

With respect to Unix systems, System V r4 (SVr4) presents the
Transport Level Interface (TLI). This is the transport layer interface that
will obsolete sockets; there will be STREAMS modules existing underneath
the interface. TLI is modeled after the ISO Transport Service Definition
(ISO 8072), so presumably, if your non-unix host has a similiar facility,
porting shouldn't be that bad.

>3. Are all TCP/IP suites done with sockets nowadays?
SVr4 (or at least Sun's version) will be using STREAMS.

I'm not sure of the commercial availability of TLI in a Unix system
(SunOS 4.1, the current version, does NOT support it).

By the way, if your application can use some sort of RPC facility, then
you can be shielded from all of this.

If you want some TLI documentation, refer to "Network Programming Guide",
from Sun Microsystems  (part 800-3850-10).

Good luck!

Rod
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 90 22:00:21 GMT
From:      haven!uvaarpa!murdoch!paisley!rja7m@louie.udel.edu  (Ran Atkinson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
The network interfaces specified by the System V Interface Definition
and by the X/Open consortium are based on the STREAMS with TLI (Transport
Level Interface) that were originally developed at AT&T.

Since the System V socket-library is built on top of STREAMS/TLI, 
an application written to use sockets will probably be slower on
a System V system that the same application written using STREAMS/TLI
natively.  In general I think that the STREAMS/TLI approach is better
because details of the transport protocol used are appropriately hidden
unlike BSD sockets.

Certainly a lot of good software is out there using sockets and I don't
think that the socket library will disappear anytime soon, but for new
software I really think that STREAMS/TLI are a better approach --
especially if developing for a System V platform.
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 90 03:46:45 GMT
From:      kramden.acf.nyu.edu!brnstnd@nyu.edu  (Dan Bernstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <9008242107.AA19843@ucbvax.Berkeley.EDU> JAZBO@BROWNVM.BROWN.EDU ("James H. Coombs") writes:
> > From:         Tom Reingold <cs!samadams.princeton.edu@PRINCETON.EDU>
    [ portability: sockets vs. streams ]
> > Which is "the way" to go?
> Sun now states that no new applications should be developed at the socket
> level.  They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1).  RPC
> has several advantages:

For comparison, here's how my auth package measures up to your criteria.

> 1. The library is available through ftp.

The same is true of auth. /comp.sources.unix/volume22/auth/* on uunet.

> 2. You can work at a high level with minimal concern for networking details.

The same is true of auth. auth-util/* are sample applications, including
(for example) a shell script adaptation of trivial inews. 76 lines, with
comments and better error checking than the original.

> 3. Client and server can be bound together into a single process without
>    modifying the code (although you may want to eliminate the code that
>    would normally establish a connection).

auth is based on a client-server model, not a single-process RPC model,
so this does not apply. See below.

> 4. Various transport mechanisms may be used under the RPC interface.

The same is true of auth. The c.s.unix version of auth is based on
sockets; the same interface can be set up over practically any two-way
communications medium. You don't have to change code to use this. Note
that auth uses RFC 931 for authentication; it eliminates mail and news
forgery above TCP. auth-util includes a small set of wrappers that you
can put around sendmail to achieve this extra security with no effort.

> 5. The application-specific protocol can be developed relatively invisibly
>    by defining c-type structures.

The auth programmer doesn't have to bother thinking about a protocol. He
need only use the software techniques he's comfortable with for writing
data to a file. The same techniques work for transferring data over the
network through auth.

> On the down side:
> 1. It is a little trickier to do something like have the server fork
>    immediately after accepting a connection.

This is an advantage of auth, again reflecting a difference in
philosophy. auth was designed for a client-server model, so it doesn't
naturally adapt to single procedures run on different machines as part
of the same program. RPC was designed for remote procedure call, so it
doesn't naturally adapt to the (perhaps more common) client-server case.

> 2. There may remain a need to drop down to the transport layer for such
>    details as keepalive options on sockets.

The same is true for auth. This is only a reflection of the ``problem''
that a high-level interface cannot anticipate all the possible
extensions of the low-level interface it's based on.

> Whatever you decide, you should take a good look at RPC.  I haven't been fully
> converted yet, but I will certainly be influenced by the library even if I
> decide to stay with sockets (and my object-oriented server building block).

Whatever you decide, you should take a good look at auth. I have been
fully converted, as I wrote the package. If you want to develop
client-server applications and be sure that they'll work on the
networks of the UNIX of the future, auth is the way to go.

---Dan
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 90 21:12:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Did BSD4.3 implemented TCP send() as a synchoronous send??


        Did BSD4.3 implementation of TCP send as a synchoronous send,
i.e. the sender (application process) is un-block only after the message
is sent and acknowledged by the receiver?? If it is not, when the sender
is un-block? After the message has been copied to the kernel buffer or
after the kernel is able to push the message out and before receive ACK
from the receiver.
        Please send the response to me directly. I will summarize if there
is enough interest.
        Thanks

- Beng Hang (email: taybengh@nusdiscs)

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 90 21:59:49 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM's FAL and poor performance

>A month ago, I wrote a very short message to this group concerning
>NIS.NSF.NET, saying "It certainly has a *terrible* implementation
>of TCP/IP."  I quickly received the following private message:
 ...
>Well, I spent about 15 hours benchmarking NIS.NSF.NET against other
>machines on the internet, carefully documenting the packet traces,
>and passing my observations on to IBM.  I did this at my own expense,
>as a matter of curiousity, because I thought that the folks who were
>sending the messages were "real programmers" who were really interested
>in getting it right (a Jay Elinsky was also involved).

I think in all fairness, you first need to identify yourself.  I have
looked at the Bitearn Nodes database ans was unable to find you listed
as a contact person at MSU.  Can you please describe your position at
the MSU computer center.

>Instead, my messages were sent to Merit, the operator of NSF.NET,
>causing a political uproar.  I personally do not appreciate finger pointing
>as a substitute for action, and in this case it was grossly unjustified.
>
>Let's keep the record straight: the folks at Merit *are* "real programmers".
>In the past, when I have uncovered a problem they have stayed up until
>5:30 in the morning tracking it down (and I suspect without overtime).
>The internet has been vastly improved during the tenure of their operation
>of the NSF net.

I cannot attest to how good the people at Merit are, but I can to the
quality of the people at IBM behind the Tcp/Ip package.  I have not
seen a CERT advisory yet for IBM's VM or MVS Tcp/Ip software but I
have seen quite a few for SunoS (rcp and sendmail to name just 2
recent ones).  To date I have not seen a report where IBM has violated
any IP "rules" and does things fast and loose.  I have seen cases of
vendors called to task in this list and others for ignoring certain
RFC rules, and people have to scramble to make things work around
them.

The people who wrote IBM's TCP/IP code are not reformed Cobol
programmers, but rather true programmers at the bit level.  They
understand all the intricacies of IP and know how to optimize code.

>The NIS.NSF.NET hardware was contributed by IBM, and I understand
>that the software is the latest IBM release.  My benchmark was carefully
>conducted for a direct comparison of the TCP/IP implementations,
>under the worst possible circumstances to make implementation flaws
>stand out clearly.  The failures demonstrated are plainly of the
>host, and not of the environment.

I would like to ask you some questions.  Did you determine whether
Merit is using an IBM 8232 to connect their channel to the Ethernet
or a BTI ELC or ELC2?  The difference is quite astounding.  Did you
check the level of activity on their Ethernet at the time?  If they
had 40% activity, there would be collisions which would cause a
slower response time.  Did you check the VM environment at Merit?
Are their disks fast enough?  Are they properly balanced?  Is Tcp/Ip
getting its full share of the resources?  A simple case where the
anonymous FTP disks you tried to get to being on the same disk pack
as swapping and being located at a sector far enough away, would
cause a slower response time (high seek time and head travel time).

You may be right that Merit "overall" is slower than some other
hosts you have looked at, but that does not mean that the Tcp/Ip
software of IBM is to blame.  It could be the IBM hardware, the
IBM mainframe or IBM VM software mis-optimization.  I will go out
on a limb and state that it is probably not the Tcp/Ip software
which is to blame but perhaps some other aspect, which may explain
why IBM forwarded your note to Merit.

>
>As to the "very satisfied" customers, I will point out that MSU has
>not yet installed the VM TCP/IP product, even though it came "free"
>with other products.  And I occasionally read "IBMTCP-L" on bitnet.
>'Nuf said.

Can you identify some non-satisified customers?  I am a satisified
customer.

>
>NIS.NSF.NET [35.1.1.48] is an IBM 4381P02 running VM/HPO-5 FAL 1.2.1
>(according to Merit -- there is no host DNS record).
>I understand it to be a lightly loaded machine.  The traces show
>less than MSS sized packets, too many retransmissions, timeouts of
>20 seconds or more, and failure to combine ACKs with bidirectional data.
 ...
>CONCLUSION:
>IBM-FAL for VM runs at 1/2 the speed of many of its competitors.
>It fails to meet several host requirements, not just for TCP/IP
>but for FTP and SMTP as well.

Can you elaborate which RFCs it fails to comply to especially in the
FTP and SMTP category?

>Bill Simpson
>    09998was@ibm.cl.msu.edu
>    09998was@msu.bitnet

Let's try to keep this a little bit balanced.

Hank Nussbacher

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 90 22:00:34 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <1990Aug24.220021.10122@murdoch.acc.Virginia.EDU>, rja7m@paisley.cs.Virginia.EDU (Ran Atkinson) writes:
> ...[one of many paeans to TLI]...


AT&T and others have been selling TLI with socket libraries for almost 4 years.
For about that long, I've been asking about performance and compatibility.
I have been privately told many unflattering stories, but have still not
found any customers or vendors who will speak publically or authoratively.

How fast are TCP user-process-to-user-process byte transfer over TLI?
How compatible are the several socket libraries and kernel-emulators?

A good TCP-with-sockets benchmark is the BRL benchmark "ttcp".  Since ttcp
compiles and runs directly over 4.3BSD compatible systems, it would be a
good measure of both speed and compatibilty.  FTP is not interesting in
this context, because it measures many things, not least file system
performance.  Ttcp is available from several places via FTP.  At least one
vendor, and rumor has it others soon, ship both source and object for ttcp
in standard products.


Vernon Schryver
vjs@sgi.com
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 90 22:00:42 GMT
From:      mcsun!inria!ircam!mf@uunet.uu.net  (Michel Fingerhut)
To:        tcp-ip@nic.ddn.mil
Subject:   Hosts whose IP numbers end in 0........
Our LAN is a class B network, 129.102.0.0, and I had the unfortunate idea to
choose *legal* IP numbers for some of our main hosts of the form 129.102.nn.0,
(nn != 0).  It's legal for a machine, since the HOST part, nn.0, is definitely
NOT zero.

Turns out some major gateways (sorry, no names) filter out such numbers,
thinking these are broadcasts or some such.  Well, they are not.

I can see 3 solutions:

1.  Changing the numbering scheme of our (several dozen) machines.
2.  Changing the RFC describing the internet addressing scheme
3.  Fixing those gateways.

So, what about (3), guys 'n gals, before I suggest (2) is done?
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 90 23:04:24 GMT
From:      clyde.concordia.ca!news-server.csri.toronto.edu!neat.cs.toronto.edu!rayan@uunet.uu.net  (Rayan Zachariassen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
Regardless of what the wave of the future is, presently if you write to
the TLI interface you won't be able to compile your code on a socket-only
system whereas if you use the socket interface you'll be portable to most
TLI systems (since they usually come with socket interface libraries).
If you aren't concerned about optimal efficiency, writing to the socket
interface now would be more portable.
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 01:34:37 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <9008242107.AA19843@ucbvax.Berkeley.EDU>, JAZBO@BROWNVM.BROWN.EDU
("James H. Coombs") writes:
> 
> Sun now states that no new applications should be developed at the socket
> level.  They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1). RPC
> has several advantages:
>

This is very disturbing. The Sun RPC is propriatary and I don't believe a part
of the DOD protocol suite. It is also NOT the RPC in the OSF DCE. As a result I
don't think software written for the SUN RPC is going to be very portable when
compared to socket or stream binding.

We've already seen a bit of this attitude in the Sun network management
software. It supports access only by RPC, not SNMP. This makes out Suns more
difficult to manage than most any box on the net which is manageable!

					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.
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 02:10:07 GMT
From:      zaphod.mps.ohio-state.edu!mips!btr!btr.btr.com!bfong@tut.cis.ohio-state.edu  (Beda Fong bfong@btr.com)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP + SUN3 + T2500
Hello net land,

Can someone with SLIP experience summarize what software should
be used to run SLIP on a:

	1) Sun3 running 4.0.3, with T2500
	2) Sun3 running 4.1, with T2500

The questions I have at this time are:

	Which version of SLIP to use? Or should we use CSLIP?
	Which tip to use?
	Which routed to use? Or which gated to use?
	Must one run dns? What to look out for?
	Do things work better on 4.0.3 or 4.1?
	What else is needed?
	Is there a place to get the whole package from one place?

Can we get all the necessary software from UUNET or does
one need to look elsewhere?

I am new to SLIP and what's necessary to make it work right.
Could someone who has SLIP running well on a Sun3 summarize
his(her) experience?

Thanks in advance.
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Aug 90 13:12 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Did BSD4.3 implemented TCP send() as a synchoronous send??

        Did BSD4.3 implementation of TCP send as a synchoronous send,
i.e. the sender (application process) is un-block only after the message
is sent and acknowledged by the receiver?? If it is not, when the sender
is un-block? After the message has been copied to the kernel buffer or
after the kernel is able to push the message out and before receive ACK
from the receiver.
        Please send the response to me directly. I will summarize if there
is enough interest.
        Thanks

- Beng Hang (email: taybengh@nusdiscs)
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 02:59:17 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
Sun RPC is proprietary?  (1) RFC 1057 documents the spec. (2) I'm
reasonably sure that they posted an implementation of RPC to the
network some time ago, and later on a revised version.  I'm still not
sure I'd write applications intended to be portable using it, but they
may be right.  The advantage is that you could move to ISO or anything
else by changing the lower layers, and the application would not be
affected.  I get the impression this is the reason they made that
recommendation.
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Aug 90 23:59:49 O
From:      Hank Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM's FAL and poor performance
>A month ago, I wrote a very short message to this group concerning
>NIS.NSF.NET, saying "It certainly has a *terrible* implementation
>of TCP/IP."  I quickly received the following private message:
...
>Well, I spent about 15 hours benchmarking NIS.NSF.NET against other
>machines on the internet, carefully documenting the packet traces,
>and passing my observations on to IBM.  I did this at my own expense,
>as a matter of curiousity, because I thought that the folks who were
>sending the messages were "real programmers" who were really interested
>in getting it right (a Jay Elinsky was also involved).

I think in all fairness, you first need to identify yourself.  I have
looked at the Bitearn Nodes database ans was unable to find you listed
as a contact person at MSU.  Can you please describe your position at
the MSU computer center.

>Instead, my messages were sent to Merit, the operator of NSF.NET,
>causing a political uproar.  I personally do not appreciate finger pointing
>as a substitute for action, and in this case it was grossly unjustified.
>
>Let's keep the record straight: the folks at Merit *are* "real programmers".
>In the past, when I have uncovered a problem they have stayed up until
>5:30 in the morning tracking it down (and I suspect without overtime).
>The internet has been vastly improved during the tenure of their operation
>of the NSF net.

I cannot attest to how good the people at Merit are, but I can to the
quality of the people at IBM behind the Tcp/Ip package.  I have not
seen a CERT advisory yet for IBM's VM or MVS Tcp/Ip software but I
have seen quite a few for SunoS (rcp and sendmail to name just 2
recent ones).  To date I have not seen a report where IBM has violated
any IP "rules" and does things fast and loose.  I have seen cases of
vendors called to task in this list and others for ignoring certain
RFC rules, and people have to scramble to make things work around
them.

The people who wrote IBM's TCP/IP code are not reformed Cobol
programmers, but rather true programmers at the bit level.  They
understand all the intricacies of IP and know how to optimize code.

>The NIS.NSF.NET hardware was contributed by IBM, and I understand
>that the software is the latest IBM release.  My benchmark was carefully
>conducted for a direct comparison of the TCP/IP implementations,
>under the worst possible circumstances to make implementation flaws
>stand out clearly.  The failures demonstrated are plainly of the
>host, and not of the environment.

I would like to ask you some questions.  Did you determine whether
Merit is using an IBM 8232 to connect their channel to the Ethernet
or a BTI ELC or ELC2?  The difference is quite astounding.  Did you
check the level of activity on their Ethernet at the time?  If they
had 40% activity, there would be collisions which would cause a
slower response time.  Did you check the VM environment at Merit?
Are their disks fast enough?  Are they properly balanced?  Is Tcp/Ip
getting its full share of the resources?  A simple case where the
anonymous FTP disks you tried to get to being on the same disk pack
as swapping and being located at a sector far enough away, would
cause a slower response time (high seek time and head travel time).

You may be right that Merit "overall" is slower than some other
hosts you have looked at, but that does not mean that the Tcp/Ip
software of IBM is to blame.  It could be the IBM hardware, the
IBM mainframe or IBM VM software mis-optimization.  I will go out
on a limb and state that it is probably not the Tcp/Ip software
which is to blame but perhaps some other aspect, which may explain
why IBM forwarded your note to Merit.

>
>As to the "very satisfied" customers, I will point out that MSU has
>not yet installed the VM TCP/IP product, even though it came "free"
>with other products.  And I occasionally read "IBMTCP-L" on bitnet.
>'Nuf said.

Can you identify some non-satisified customers?  I am a satisified
customer.

>
>NIS.NSF.NET [35.1.1.48] is an IBM 4381P02 running VM/HPO-5 FAL 1.2.1
>(according to Merit -- there is no host DNS record).
>I understand it to be a lightly loaded machine.  The traces show
>less than MSS sized packets, too many retransmissions, timeouts of
>20 seconds or more, and failure to combine ACKs with bidirectional data.
...
>CONCLUSION:
>IBM-FAL for VM runs at 1/2 the speed of many of its competitors.
>It fails to meet several host requirements, not just for TCP/IP
>but for FTP and SMTP as well.

Can you elaborate which RFCs it fails to comply to especially in the
FTP and SMTP category?

>Bill Simpson
>    09998was@ibm.cl.msu.edu
>    09998was@msu.bitnet

Let's try to keep this a little bit balanced.

Hank Nussbacher
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Aug 90 07:41:20 EDT
From:      Robert Craig <ROBERT@VM1.MCGILL.CA>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: IBM's FAL and poor performance
Mr. Simpson, if you did *that* much work, it would
seem to be in order to post a comparison of vendor
implementations, noting exactly where they fail in
compliance to the host requirements and in robustness,
performance, and other areas.  That would be constructive.

Your posting is inflammatory, filled
with unsubstantiated innuendo, and more typical of a
rumour-monger than of someone interested in learning
and in helping others.

If the tone of your original note to the supporters of TCP/IP
in IBM containing the results of your testing was in the
same vein, I don't wonder that you received no response from them
(as I intuit from the bitterness in your note).

For the record, we run FAL 1.2.1 on a 4381 with a BTI ELC.
We began with an 8232 and performance *was* abysmal.
It is much better now...
Note that IBM has replaced the
8232 with an improved product (3172?  I don't recall the
model number off-hand).

Robert Craig                          domain: robert@vm1.mcgill.ca
Senior Network Analyst                bitnet: robert@mcgill1
McGill University Computing Centre    Tel: (514) 398-3710
805 Sherbrooke St. W.                 FAX: (514) 398-6876
Montreal, Quebec H3A 2K6              CORISQ: (514) 398-RISQ
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 06:17:44 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?

I bet the OSF/HP/Apollo/DCE and Netwise people, to name only 2, would not
be happy to be declared out of the race to define the standard RPC protocol.
Last I heard from them, they are each defining The Emerging Standard.


Vernon Schryver,    vjs@sgi.com
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 06:53:46 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <Aug.25.22.59.16.1990.22640@athos.rutgers.edu>
hedrick@athos.rutgers.edu (Charles Hedrick) writes: 
>The advantage is that you could move to ISO or anything
>else by changing the lower layers, and the application would not be
>affected.  I get the impression this is the reason they made that
>recommendation.

The disadvantage is that you can't write programs like FTP or sendmail
using the RPC protocol.  Not programs that will interoperate with
other FTP's and sendmails, at any rate.

While RPC is good for some things, it is not the answer to all the
networking problems.  Sometimes you just gotta write at a fairly low
level to interoperate with other programs.

Warner
--
Warner Losh		imp@Solbourne.COM
Me?  I'm the onion rings.
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 07:57:41 GMT
From:      pacbell.com!mips!bridge2!bvj@ucsd.edu  (B.V. Jagadeesh)
To:        tcp-ip@nic.ddn.mil
Subject:   Networking Conference-91 Call for papers

Papers are solicited for the Silicon Valley Networking conference
to be held April 23rd to 25th 1991 at Santa Clara convention center, CA.
Papers are solicited in the following areas.
 
 Distributed Systems
 Internetworking
 Network Management
 X-windows
 Advanced File servers
 High Speed Networking
 Standards activities
 PC Networking.
  
  This conference is run by the same people who succesfully organised
  Systems Design and Networking Conference (SDNC) for the last three years. 
  The conference typically attracts over 300 networking professionals every 
  year and is a nice forum to discuss system design architecture and other
  networking system aspects.
   
   If you are interested in presenting a paper, please send me an abstract
   of the paper before Oct-1st 1990. If you have any questions about the
   conference, please send me email.

   Thanks
   /Jagadeesh
   Technical Program Chairman
   bvj@ESD.3Com.com
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 11:41:20 GMT
From:      ROBERT@VM1.MCGILL.CA (Robert Craig)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM's FAL and poor performance

Mr. Simpson, if you did *that* much work, it would
seem to be in order to post a comparison of vendor
implementations, noting exactly where they fail in
compliance to the host requirements and in robustness,
performance, and other areas.  That would be constructive.

Your posting is inflammatory, filled
with unsubstantiated innuendo, and more typical of a
rumour-monger than of someone interested in learning
and in helping others.

If the tone of your original note to the supporters of TCP/IP
in IBM containing the results of your testing was in the
same vein, I don't wonder that you received no response from them
(as I intuit from the bitterness in your note).

For the record, we run FAL 1.2.1 on a 4381 with a BTI ELC.
We began with an 8232 and performance *was* abysmal.
It is much better now...
Note that IBM has replaced the
8232 with an improved product (3172?  I don't recall the
model number off-hand).

Robert Craig                          domain: robert@vm1.mcgill.ca
Senior Network Analyst                bitnet: robert@mcgill1
McGill University Computing Centre    Tel: (514) 398-3710
805 Sherbrooke St. W.                 FAX: (514) 398-6876
Montreal, Quebec H3A 2K6              CORISQ: (514) 398-RISQ

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 16:42:18 GMT
From:      kramden.acf.nyu.edu!brnstnd@nyu.edu  (Dan Bernstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <1990Aug26.065346.13988@Solbourne.COM> imp@dancer.Solbourne.COM (Warner Losh) writes:
> In article <Aug.25.22.59.16.1990.22640@athos.rutgers.edu>
> hedrick@athos.rutgers.edu (Charles Hedrick) writes: 
> >The advantage is that you could move to ISO or anything
> >else by changing the lower layers, and the application would not be
> >affected.
> The disadvantage is that you can't write programs like FTP or sendmail
> using the RPC protocol.  Not programs that will interoperate with
> other FTP's and sendmails, at any rate.

auth provides that advantage without that disadvantage! Again, it was
designed for client-server applications, unlike RPC. From the README:

  This package provides two benefits. The first is a secure user-level
  implementation of RFC 931, the Authentication Server; unless TCP itself
  is compromised, it is impossible to forge mail or news between computers
  supporting RFC 931. The second is a single, modular interface to TCP.
  Programs written to work with authtcp and attachport don't even need to
  be recompiled to run under a more comprehensive network security system
  like Kerberos, as long the auth package is replaced.

The base package includes authtcp, a generic TCP client; attachport, a
generic TCP server; authd, a daemon supporting RFC 931; and authuser, a
compatibility library letting you take advantage of RFC 931 from older
applications.

authutil is a big pile of miscellany illustrating how to use auth.
Directories: aport - support programs for authtcp and attachport, making
server control easy; clients - various sample Internet clients,
including a short shell script implementation of trivial inews (with
RFC 931 security, of course); sendmail-auth - a small set of wrappers
you can put around sendmail to achieve full username tracking; servers -
various sample Internet servers, including a secure fingerd that
wouldn't have let RTM in; tam - Trivial Authenticated Mail, a complete
mail system in just 200 lines of code; and util - various short
utilities that everyone should have.

> While RPC is good for some things, it is not the answer to all the
> networking problems.

Agreed. It was designed for remote procedure call and does that quite
reasonably.

> Sometimes you just gotta write at a fairly low
> level to interoperate with other programs.

I don't think this is true: auth's interface is very high level.

---Dan
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 17:16:41 GMT
From:      uc!cs.umn.edu!peiffer@tut.cis.ohio-state.edu  (Tim Peiffer (The Net Guy))
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hosts whose IP numbers end in 0........
In article <1990Aug25.220042.29632@ircam.ircam.fr> mf@ircam.ircam.fr (Michel Fingerhut) writes:
>(nn != 0).  It's legal for a machine, since the HOST part, nn.0, is definitely
>NOT zero.

	I disagree.  The same set of documents known as RFC's also describe
	subnetting practices.  It lists nn.0 as host '0' of subnet 'nn'.
	Therefore the host part is zero.  BTW, do not forget the host
	numbered 255.

>1.  Changing the numbering scheme of our (several dozen) machines.
>2.  Changing the RFC describing the internet addressing scheme
>3.  Fixing those gateways.
>So, what about (3), guys 'n gals, before I suggest (2) is done?


	You have have a maximum number of 254 different hosts to
	change.  Considering you presently have internet connectivity
	converging on zero, this option is relatively painless.
	Considering that the number of routers and gateways exceeds
	254, fixing your net is probably the most efficient solution.

	The RFC is the spec on how to do it right.  Specs are 
	broken all the time, but the results are not guaranteed to
	work.  If you have a better idea, it would take a while to
	promulgate this around the world to all vendors, etc.  This
	is one of the longer (and painful) methods of fixing things.

	As to #3, you wish to fix something that is not broken?  I 
	am confused.

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
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 18:43:30 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: Hosts whose IP numbers end in 0........
In article <1990Aug25.220042.29632@ircam.ircam.fr> mf@ircam.ircam.fr (Michel Fingerhut) writes:

   1.  Changing the numbering scheme of our (several dozen) machines.
   2.  Changing the RFC describing the internet addressing scheme
   3.  Fixing those gateways.

Only a dozen machines?  You are using name servers, right?  Change
the numbers, it's a lot easier than changing the code...

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
(who is going to help change the numbers of 100's of hosts in the
 next week or so as we get off of a class A net onto a class B)
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 19:29:05 GMT
From:      zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!perand@tut.cis.ohio-state.edu  (Per Andersson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hosts whose IP numbers end in 0........
In article <EMV.90Aug26134330@stag.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>(who is going to help change the numbers of 100's of hosts in the
> next week or so as we get off of a class A net onto a class B)

Just both of you be careful if you have diskless clients. At least in the sun
case it tftp:s the image whos filename is the IP-adress in hex. Maybe we
should compose a list for 'How to do it'

Per
( Migrating a class A and two class C nets to a B net someday soon.... )


-- 
---
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
perand@admin.kth.se, @nada.kth.se 
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 19:33:47 GMT
From:      maytag!gamiddle@iuvax.cs.indiana.edu  (Guy Middleton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hosts whose IP numbers end in 0........
In article <1990Aug26.171641.14037@cs.umn.edu> peiffer@cs.umn.edu (Tim Peiffer (The Net Guy)) writes:
> 
> 	I disagree.  The same set of documents known as RFC's also describe
> 	subnetting practices.  It lists nn.0 as host '0' of subnet 'nn'.
> 	Therefore the host part is zero.  BTW, do not forget the host
> 	numbered 255.

This is only true if you use a subnet mask of 255.255.255.0; if your subnets
use (for example) nine bits for a host-part, nn.0 is fine.

Also, nothing in the RFCs obliges anybody to use subnets.
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 19:42:37 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!perand@ucsd.edu  (Per Andersson)
To:        tcp-ip@nic.ddn.mil
Subject:   Managing the network

I've seen some questions on network management, but no answers. Now is the
time to change that. Send a mail about the products you know, and I'll make
a summary. I know a little about Sunnet manager, psi-snmp, Retix, Vitalink
and cmu/mit snmp already. Our network consists today of Bridge bridges,
Decserver 200s, VMS vaxes, Suns, Decstations, Fastpath 4s, Macs and soon
snmp talking terminal servers (probably Xyplex). I have a feeling a summary
is wanted, so no 'mail one to me' letters please. Rather 'dont send a summary
to the net because it's not wanted' letters if thats the way you feel.

Per
-- 
---
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
perand@admin.kth.se, @nada.kth.se 
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Monday, 27 August 1990 0:23am ET
From:      "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM's FAL and poor performance
> Date: Sun, 26 Aug 90 07:41:20 EDT
> From: Robert Craig  <ROBERT@VM1.MCGILL.CA>
> Mr. Simpson, if you did *that* much work, it would
> seem to be in order to post a comparison of vendor
> implementations, noting exactly where they fail in
> compliance to the host requirements and in robustness,
> performance, and other areas.  That would be constructive.

Actually, I had tried to post a *concise* numerical presentation,
without detailed verbiage describing the specific failings I found.
I did send those details privately to IBM.  If there is enough interest,
I would be glad to post a synopsis here.  (it will be rather long.)

Moreover, the analysis would be limited to NIS.NSF.NET, as that is what
I looked at.  Analysis of many vendors' implementations would take a lot
more work than *that*.  Perhaps your organization is interested in
funding a series of such research?

My effort was merely to confirm my prior subjective observation with
objective, concrete numbers.

> Your posting is inflammatory, filled
> with unsubstantiated innuendo, and more typical of a
> rumour-monger than of someone interested in learning
> and in helping others.

Actually, the posting was well substantiated with several megabytes of
packet traces.  I deleted most of them a week or so ago, but if you'd
like, I'd be glad to flood your personal mailbox with the 300,000 or so
remaining (I think that would be a bit much for the entire mailgroup).
Send me a private message if you're sure you want them.

> If the tone of your original note to the supporters of TCP/IP
> in IBM containing the results of your testing was in the
> same vein, I don't wonder that you received no response from them
> (as I intuit from the bitterness in your note).

Unfortunately, your intuition is wrong.  If you had read part 1 carefully,
you would have realized that many messages were exchanged.  In fact,
10 of the now 17 hours devoted to this little project have been message
handling.  The "bitterness" arises from the virtual storm of mail due
to the political finger-pointing that arose in private messages.

> For the record, we run FAL 1.2.1 on a 4381 with a BTI ELC.
> We began with an 8232 and performance *was* abysmal.
> It is much better now...

For the record, I don't know nor care about the specific *hardware*
which was being compared.  (How was I to know, with no host DNS
record, and no announcement in the FTP welcome message.)
The hardware is whatever IBM chose to demonstrate their best to the
internet community.  I merely noted the machines which were being
compared, in very little detail, so that others would understand
the basis for comparison (more hops, heavy load, etc).

I am glad that with a different machine you have had better performance
(your notation means nothing to me).  I have been informed FAL performs
reasonably well with certain hardware in a direct connection with a
high bandwidth.  That does not speak to the issue of the internet as
a whole, where links may be lossy, gateways congested, etc.

I also have a number of messages saying that they have given up
entirely on NIS.NSF.NET, including one with a much more direct
connection than I have.  Also, messages thanking me for the posting....

Bill Simpson
   09998was@ibm.cl.msu.edu
   09998was@msu.bitnet
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 21:34:06 GMT
From:      sdd.hp.com!mips!twg.com!david@ucsd.edu  (David S. Herron)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hosts whose IP numbers end in 0........
In article <1990Aug26.171641.14037@cs.umn.edu> peiffer@cs.umn.edu (Tim Peiffer (The Net Guy)) writes:
>In article <1990Aug25.220042.29632@ircam.ircam.fr> mf@ircam.ircam.fr (Michel Fingerhut) writes:
>>(nn != 0).  It's legal for a machine, since the HOST part, nn.0, is definitely
>>NOT zero.
>
>	I disagree.  The same set of documents known as RFC's also describe
>	subnetting practices.  It lists nn.0 as host '0' of subnet 'nn'.
>	Therefore the host part is zero.  BTW, do not forget the host
>	numbered 255.

But .. But ...

Subnet numbers don't have to be on 8 bit boundries.  Sounds to me as if
the routers in question are assuming them to *BE* on 8 bit boundries
just like you are.

Or the network in question might not be subnetted at all.

It's not very correct for a router to assume such things for networks
it isn't attached to.  On the other hand if it does know the subnet
mask and broadcast address for a subnet then it's fair for it to
filter out broadcasts from that subnet.
-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 22:05:25 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:   looking for old dusty RFCs & working on anonymous FTP RFC

I'm searching for a complete set of RFCs, including the real old
ones from the early 1970's.  In particular, I'd like to be pointed
to a place where I can get copies of all of the RFCs mentioned in
Appendix III of RFC 959, "RFCs on FTP".

What I'm trying to do is to gather historical material for an RFC
on anonymous FTP.  RFC 959 doesn't talk about where the convention
of specifying "anonymous" as a password comes from, nor was there
anything that I could easily dredge up in any other RFC that I have
found.  Any relevant ephemera which would help me pin down how things
have changed and developed over time would be most welcome.

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
moderator, comp.archives
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 90 23:10:24 GMT
From:      cs.utexas.edu!sun-barr!newstop!exodus!page@tut.cis.ohio-state.edu  (Bob Page)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
> Sun RPC is propriatary

What does proprietary mean to you?  The RPC/XDR specs have been
published for some time as RFCs 1057 (RPC) and 1014 (XDR).  RPC/XDR
source code (from Sun) is available for ftp from many places, like
titan.rice.edu.  A freely redistributable NFS implementation was built
(not by Sun, but by members of the Internet community) on top of the
RPC/XDR source code.  Some vendors have products based on the source.

> We've already seen a bit of this attitude in the Sun network management
> software. It supports access only by RPC, not SNMP.

Whoa -- Reality check.  Last October at Interop '89, a Sun workstation
running SunNet Manager was in the ACE (now Interop Inc) booth
monitoring _all_ the network gateways (cisco, SynOptics, Proteon,
etc).  A number of vendors (SynOptics, Cabletron, Network General,
Xyplex, and more) were running SunNet Manager in their respective
booths to show how they interoperated with the product.  The package
was also running in the show's SNMP Interoperability booth.  All this
communication was done via SNMP, not RPC.

> Disclaimer: Don't take this too seriously. I just like to improve my typing
> and probably don't really know anything useful about anything.

Sounds like good advice.

..bob
--
Bob Page	Sun Microsystems, Inc.		page@eng.sun.com
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 00:48:43 GMT
From:      sdd.hp.com!mips!prls!pyramid!ctnews!mitisft!burton@ucsd.edu  (Philip Burton)
To:        tcp-ip@nic.ddn.mil
Subject:   GOSIP I Errata !!??
Are the NIST Stable Implementators's Agreements (SIA) stable enough?

I am the product line manager for data comm for Unisys' Distributed Systems
Division, (CTOS/BTOS) and we are trying to come to grips with this issue:

Now that August 15, 1990 has come and gone, what does GOSIP I really mean?
Is Version 1, Edition 1 of the SIA what implementors should have built, or
was it Version 1 Edition 4 or Version 3 Edition <latest>?

Unisys is concerned about what edition of the SIA is being specified by GOSIP.
We can release a product only so frequently.  It is possible to make
maintenance/support/update/patch releases quarterly, but is the effort either
justifiable or necessary?  The impact on the customer base is great, and there
is significant expense associated with each upgrade.

We were under the impression that NIST would produce one (exactly one) stable
implementors' agreement and that implementors would build to that set of   
agreements.

It is understandable that in the beginning there was a need for some errata, but
we are concerned about the proposed wording being placed into GOSIP version 1,
which would make compliance to GOSIP 1 a "moving target."  The reference to the
SIA in GOSIP 1 (FIPS 146) is to versiion 1, without reference to a specific
edition. NIST proposes modifying FIPS 146 to reference "NIST Special Publication
500-177, Stable Implementation Agreements for Open Systems Interconnection
Protocols, Version 3."  (Version 3 is the latest edition available from the
Government Printing Office.)

Do you share our concerns, or believe that there is no cause for concern?

Phil Burton
Unisys Corporation
(408) 435 3791

burton@mitisft.Convergent.COM (Internet)

PMB1/NGen-mktg  (Unisys internal mail system)
 
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 00:53:51 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb@ucsd.edu  (David Collier-Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM's FAL and poor performance

  More light, less heat, people!

  This was a criticism of observed performance: it should have carried a
disclaimer that that is exactly what it was.  Speculation about the hardware
configuration, the disk layout or the particular software product is
inadvisable.  
  Lets stick to facts: machine a is amazingly slow and doesn't do X.
machine b on the same net isn't...


--dave (if you haven't noticed I just attacked both sides, 
	you're not paying attention (:-)) c-b
ps: Criticism, even indirect, of any vendor is liable to cause
    unkindnesses in return mail.  Criticism of at least two will
    and do cause unkindnesses to your president. Facts are necessary,
    if insufficent, in such cases.]
-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | "And the next 8 man-months came up like
CANADA. 416-223-8968  |   thunder across the bay" --david kipling
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 00:54:29 GMT
From:      sun-barr!newstop!east!hinode!geoff@decwrl.dec.com  (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
Quoth brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (in <8076:Aug2616:42:1890@kramden.acf.nyu.edu>):
#auth provides that advantage without that disadvantage! Again, it was
#designed for client-server applications, unlike RPC.

[smiley mode on]

Dear Dan, 

	You seem to understand these things, so maybe you can help me
with a little semantic problem. Every time I feed a .x file to rpcgen,
it insists on spitting out client and server stubs, which I find
convenient for building my distributed applications.  Yet you say that
RPC wasn't designed for client-server applications.  I'm confused...

Geoff Arnold
PC-NFS architect


-- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM)   --

To receive a full copy of my .signature, please dial 1-900-GUE-ZORK.
Each call will cost you one zorkmid.
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 06:09:01 GMT
From:      09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
To:        comp.protocols.tcp-ip
Subject:   Re: IBM's FAL and poor performance

> Date: Sun, 26 Aug 90 07:41:20 EDT
> From: Robert Craig  <ROBERT@VM1.MCGILL.CA>
> Mr. Simpson, if you did *that* much work, it would
> seem to be in order to post a comparison of vendor
> implementations, noting exactly where they fail in
> compliance to the host requirements and in robustness,
> performance, and other areas.  That would be constructive.

Actually, I had tried to post a *concise* numerical presentation,
without detailed verbiage describing the specific failings I found.
I did send those details privately to IBM.  If there is enough interest,
I would be glad to post a synopsis here.  (it will be rather long.)

Moreover, the analysis would be limited to NIS.NSF.NET, as that is what
I looked at.  Analysis of many vendors' implementations would take a lot
more work than *that*.  Perhaps your organization is interested in
funding a series of such research?

My effort was merely to confirm my prior subjective observation with
objective, concrete numbers.

> Your posting is inflammatory, filled
> with unsubstantiated innuendo, and more typical of a
> rumour-monger than of someone interested in learning
> and in helping others.

Actually, the posting was well substantiated with several megabytes of
packet traces.  I deleted most of them a week or so ago, but if you'd
like, I'd be glad to flood your personal mailbox with the 300,000 or so
remaining (I think that would be a bit much for the entire mailgroup).
Send me a private message if you're sure you want them.

> If the tone of your original note to the supporters of TCP/IP
> in IBM containing the results of your testing was in the
> same vein, I don't wonder that you received no response from them
> (as I intuit from the bitterness in your note).

Unfortunately, your intuition is wrong.  If you had read part 1 carefully,
you would have realized that many messages were exchanged.  In fact,
10 of the now 17 hours devoted to this little project have been message
handling.  The "bitterness" arises from the virtual storm of mail due
to the political finger-pointing that arose in private messages.

> For the record, we run FAL 1.2.1 on a 4381 with a BTI ELC.
> We began with an 8232 and performance *was* abysmal.
> It is much better now...

For the record, I don't know nor care about the specific *hardware*
which was being compared.  (How was I to know, with no host DNS
record, and no announcement in the FTP welcome message.)
The hardware is whatever IBM chose to demonstrate their best to the
internet community.  I merely noted the machines which were being
compared, in very little detail, so that others would understand
the basis for comparison (more hops, heavy load, etc).

I am glad that with a different machine you have had better performance
(your notation means nothing to me).  I have been informed FAL performs
reasonably well with certain hardware in a direct connection with a
high bandwidth.  That does not speak to the issue of the internet as
a whole, where links may be lossy, gateways congested, etc.

I also have a number of messages saying that they have given up
entirely on NIS.NSF.NET, including one with a much more direct
connection than I have.  Also, messages thanking me for the posting....

Bill Simpson
   09998was@ibm.cl.msu.edu
   09998was@msu.bitnet

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Aug 90 13:49:32 CDT
From:      pdurrant@ub.d.umn.edu (Paul Durrant)
To:        tcp-ip@nic.ddn.mil
Subject:   DESUBSCRIBE
SIGN-OFF
Please remove me from this list.

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Aug 90 15:37 C
From:      CLEBER%SBU.UFRGS.ANRS.BR@UICVM.uic.edu
To:        TCP-IP@NIC.DDN.MIL
Subject:   KA9Q by Bdale Garbee
    Could anyone tell me if KA9Q Internet Software Package source
code is available. If yes, what's the places that i can get it
by FTP.
    Thanks in advance,
    Cleber Weishheimer.

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Aug 90 18:41:27 -0500
From:      mrf@ftp.com
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: Hosts whose IP numbers end in 0........

The fact that has been overlooked in your reading of the Host
Requirements RFC (which I agree is wonderful) is which portions
of an IP address are which.  On a Class B network (the kind in
question) which is not subnetted, the last TWO (2) bytes of the
address are the host format.

	NN.NN.HH.HH   }  2 bytes of net and 2 of host.

If this address is 129.126.52.0, the net portion is 129.126 and the
host portion is 52.0 (or 3400 hex) which is in fact non-zero.  This
should therefore be a legal address on the net (in theory).  The
broadcast address on this net would be 129.126.255.255, and the
network address would be 129.126.0.0.  There would be no conflict
between these addresses and the host address of 129.126.52.0.

However, I am not surprised that this is rejected by several
implementations, and do not think that this would be advisable on a
class B network, because I do not think it would lend itself to later
subnetting.  The best thing for this person to do is to probably only
use the 2nd host byte (unless he will have over 254 machines) and
leave the first byte 0.  This will allow him to less painfully put in
subnetting later if necessary.  Or, decide now on what his eventual
network needs will be and start off with the correct values in place
for subnetting (i.e give every host in one building a host value of 
1.nn, another building or floor 2.nn, etc.).  This might also help
when network problems arise to make it easier to locate the failing
machine (just a suggestion).

Just because something is legal doesn't mean it works (and vice
versa). 

Margaret Forsythe, Technical Support Manager, FTP Software, Inc.
mrf@ftp.com       (617) 246-0900 x100        FAX: (617) 246-0901

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Aug 90 14:48:25 EDT
From:      Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU>
To:        Kent England, <usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: Hosts whose IP numbers end in 0........
>    I didn't see anybody cite chapter and verse of the Host
>Requirements RFC and considering the hours spent on that fine document,
>I think it would be a shame not to cite the official bible of the
>Internet (ok, one of the bibles...):
>
>-----------------------------
>        From RFC 1122 Sec 3.2.1.3  Addressing: RFC-791 Section 3.2;
>
>            "IP addresses are not permitted to have the value 0 or -1 for
>            any of the <Host-number>, <Network-number>, or <Subnet-
>            number> fields (except in the special cases listed above).
>            This implies that each of these fields will be at least two
>            bits long."
>------------------------------
>
>        I therefore conclude that a host part of zero is never a legal source
>address.
>So I think the petitioner should change the addresses on his hosts and
>not bother his
>router vendor.  Isn't the Host Requirements RFC wonderful?  This only
>took five minutes
>to research and that included checking the commentary in RFC 1127.   :-)

Great work, Kent, but nothing in here says that the address xx.yy.zz.0 is
invalid in a class B network!  As others have pointed out, the network can
be subnetted other than with 8 bits of subnet mask, or may not even be
subnetted.  If, for example, there were only 6 bits of subnet mask, then
the host address is zero only if zz mod 4 is zero *and* the 4th byte is zero.
And if the subnet mask was 10 bits long, then the 4th byte should never be
0, 64, 128, or 192 (or any of the corresponding broadcast addresses).

I think the router vendor in question should be "bothered", and bring their
implementation up to the HR RFC and GR RFC specs......

Doug Nelson
Michigan State University
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Aug 90 16:10:08 EDT
From:      Michael A. Patton <MAP@lcs.mit.edu>
To:        usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Hosts whose IP numbers end in 0........
   Date: 27 Aug 90 16:32:47 GMT
   From: usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)

Hi Kent, that's quite a return address you have there and you're only
next door :-).

	   I didn't see anybody cite chapter and verse of the Host
   Requirements RFC and considering the hours spent on that fine
   document, I think it would be a shame not to cite the official
   bible of the Internet (ok, one of the bibles...):

A laudable ambition, but the original poster said he had consulted the
RFCs and not found anything outlawing what he's doing, I don't think
you did either :-).

	[Quotes from RFCs removed]
	   I therefore conclude that a host part of zero is never a
   legal source address.  So I think the petitioner should change the
   addresses on his hosts and not bother his router vendor.

Except that you missed the point of the original poster.  He is not
subnetting and therefore has sixteen bits of host number.  Some of his
hosts are assigned (non-zero) sixteen bit numbers that happen to have
all the last eight bits zero.  According to all the specs this is
legal.  His problem comes in that some gateways (I assume not under
his control) are configured to discard all packets with addresses
having the low eight bits of the address zero.  My reading of this
would be that what he is doing is legal, and the maintainers of the
intervening routers are doing something wrong.  But to follow the "Be
conservative in what you send, liberal in what you accept" policy
would suggest not using such host addresses even though they should be
valid.  That's what we do here.

	    __
  /|  /|  /|  \		Michael A. Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Aug 90 19:05:44 CDT
From:      "Lt. Matt Jonson" <jonson@server.af.mil>
To:        tcp-ip@nic.ddn.mil
Cc:        beach@ddnuvax.af.mil
Subject:   Re: IP numbers that end in 0 ...
In message <63256@bu.edu.bu.edu>
usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu (Kent England)
writes:

>   I didn't see anybody cite chapter and verse of the Host Requirements RFC
>and considering the hours spent on that fine document, I think it would
>be a shame
>not to cite the official bible of the Internet (ok, one of the bibles...):
>
>-----------------------------
>        From RFC 1122 Sec 3.2.1.3  Addressing: RFC-791 Section 3.2;
>
>            "IP addresses are not permitted to have the value 0 or -1 for
>            any of the <Host-number>, <Network-number>, or <Subnet-
>            number> fields (except in the special cases listed above).
>            This implies that each of these fields will be at least two
>            bits long."
>------------------------------
>
[...]
>I therefore conclude that a host part of zero is never a legal source address.
>So I think the petitioner should change the addresses on his hosts and
>not bother his
>router vendor.  Isn't the Host Requirements RFC wonderful?  This only
>took five minutes
>to research and that included checking the commentary in RFC 1127.   :-)


And this is all correct, you cannot have a <Host-number> of 0.  However, you
can have a final OCTET of 0 legally if you are subnetting (for instance) a
class B on LESS THAN 8 bits.

For instance, 5 bit <Subnet-number> and 11 bit <Host-number> from class B:

BBBBBBBB.BBBBBBBB.SSSSSHHH.HHHHHHHH
10000011.00111111.00001001.00000000

This should be a legal address, because it is on subnet 1, and is host #256.
The dotted decimal notation is 131.63.9.0 !!! which is the type of situation
that I believe the person who posted the question was talking about.  This
is a legal number, but there may be some old broken routers out there that
still think it is bad because they don't know subnetting (?)

Similary, one could generate an address that (dotted-decimally) ended in 255,
that should also be technically legal, but may just as well be filtered by
a gateway that didn't know any better.

Conclusion:  May be wise to avoid creating host addresses that have an all 1
or all 0 fourth octet if you don't have the time to hunt down routers that
filter on what they assume is an errant broadcast.  Contrarily, it would be
nice if someone actively pursued broken implementations...


(Lt) Matt Jonson
AF DDN Program Office
jonson@server.af.mil

And yes, those were my words, not the government's.
(They don't pay me enough to speak for them too)

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 16:32:47 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: Hosts whose IP numbers end in 0........

	I didn't see anybody cite chapter and verse of the Host Requirements RFC
and considering the hours spent on that fine document, I think it would
be a shame
not to cite the official bible of the Internet (ok, one of the bibles...):

-----------------------------
	From RFC 1122 Sec 3.2.1.3  Addressing: RFC-791 Section 3.2;

            "IP addresses are not permitted to have the value 0 or -1 for
            any of the <Host-number>, <Network-number>, or <Subnet-
            number> fields (except in the special cases listed above).
            This implies that each of these fields will be at least two
            bits long."
------------------------------

	The special cases are:

            (a)  { 0, 0 }		[only during initialization]
            (b)  { 0, <Host-number> }	[only during initialization]
            (c)  { -1, -1 }		[limited bcast; never source-addr]
            (d)  { <Network-number>, -1 }	[directed bcast; never source-addr]
            (e)  { <Network-number>, <Subnet-number>, -1 }	[directed
bcast; never source-addr]
            (f)  { <Network-number>, -1, -1 }	[directed bcast; never
source-addr]
            (g)  { 127, <any> }		[loopback addr; never outside a host]


	I therefore conclude that a host part of zero is never a legal source address.
So I think the petitioner should change the addresses on his hosts and
not bother his
router vendor.  Isn't the Host Requirements RFC wonderful?  This only
took five minutes
to research and that included checking the commentary in RFC 1127.   :-)

	--Kent
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 16:49:35 GMT
From:      usc!bbn.com!clements@ucsd.edu  (Bob Clements)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: looking for old dusty RFCs & working on anonymous FTP RFC
emv@math.lsa.umich.edu (Edward Vielmetti) writes:

>What I'm trying to do is to gather historical material for an RFC
>on anonymous FTP.  RFC 959 doesn't talk about where the convention
>of specifying "anonymous" as a password comes from, nor was there
>anything that I could easily dredge up in any other RFC that I have
>found.

To the best of my knowledge, I invented the use of "anonymous"
as a username (not as a password).  This was in the FTP server for
TENEX in the NCP (pre-TCP) days.  Probably late in 1972.

The implementation was simple.  You could read (or write) any
file that was world-readable (writable) in the file system.  The
server logged all transactions, for both anonymous and "real"
users.  It logged the passwords used by "anonymous", which were
supposed to be real user idents so one could contact the user if
he was having problems.

There was a configuration file and there had to actually be a
username "anonymous" in the system password file, otherwise the
FTP feature was disabled.  So sites that didn't like the idea
didn't need to have it turned on.

This was largely as a debugging and testing aid.  Us early FTP
implementors could test against each other's implementations
without needing to actually get a password on every machine.
(Machines weren't all Unixes in those days, so there were lots of
implementations and lots of word lengths and lots of file types.)
Other users found it useful, too, so we left it in.

Another feature added in that version was a "NUL" device.
Reading from it gave you a megabit of data, for speed testing.

In those days there were only a half dozen sites on the ARPANET
and security was not a big problem.  We joked that anyone who
could spell "anonymous" was probably OK.  A simpler time.

>--Ed
>Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
>moderator, comp.archives


Bob Clements, K1BC, clements@bbn.com   (w) 617-873-3612
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 16:55:03 GMT
From:      uc!shamash!timbuk!cs.umn.edu!dmshq!com50!rosevax!atc!sstat!moria!bas@tut.cis.ohio-state.edu  (Brian Strop)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA TELNET or Clarkson's version
Where can I obtain the NCSA or Clarkson TELNET executables?
Also, what version are they and does either support TN3270?
Thanks in advance.  I need the Internet address in numeric
form also (i.e. 128.100.10.1, for example).

                       Brian Strop
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 17:21:00 GMT
From:      psuvm!barilvm!bimacs!yariv@psuvax1.cs.psu.edu  (yariv yehuda)
To:        tcp-ip@nic.ddn.mil
Subject:   OSI security and management model

 Hello ISOland!! I need your help and advice.

 I am interested in the OSI security architecture and security management.
 If you can furnish me with information about the following subjects
 it will be *most* appreciated:


 o Known design problems in the architecture definition and the security
   management model of OSI as described in parts 2 and 4 of the OSI-model.
   Known "holes" in the model? Undefined subjects and "left out"
   ones?

 o Are these security and management models being implemented? By whom?
   How advanced is the research of those teams working on it?
   Have they published any reports?

 o Any known papers (besides the standards) that deal with those subjects?

 o Any references to "validity proofs" of any OSI-model/protocol/service,
   especially about security matters.


 Please E-Mail me (yariv@bimacs.bitnet). If enough interest, I will
 summerize to the net.


                 Thanks in advance.
                                                Yariv
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 18:16:56 GMT
From:      amazon.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <PAGE.90Aug26161024@swap.Eng.Sun.COM>, page@Eng.Sun.COM (Bob Page) writes:

> What does proprietary mean to you?  The RPC/XDR specs have been
> published for some time as RFCs 1057 (RPC) and 1014 (XDR).  RPC/XDR
> source code (from Sun) is available for ftp from many places, like
> titan.rice.edu.  A freely redistributable NFS implementation was built
> (not by Sun, but by members of the Internet community) on top of the
> RPC/XDR source code.  Some vendors have products based on the source.

*Sigh* This one depends on your definition of "proprietary". I once was bashed
for saying that DECnet is not proprietary. It's specs have been published and
are freely available. There are several implementations. But DEC owns DECnet
and, until SUN places RPC in the pulic domain, SUN owns RPC. It's
implementations are many and on many systems, but it is still owned by Sun.
Frankly, this is a bogus issue and I should not have raised it.
 
>> We've already seen a bit of this attitude in the Sun network management
>> software. It supports access only by RPC, not SNMP.
> 
> Whoa -- Reality check.  Last October at Interop '89, a Sun workstation
> running SunNet Manager was in the ACE (now Interop Inc) booth
> monitoring _all_ the network gateways (cisco, SynOptics, Proteon,
> etc).  A number of vendors (SynOptics, Cabletron, Network General,
> Xyplex, and more) were running SunNet Manager in their respective
> booths to show how they interoperated with the product.  The package
> was also running in the show's SNMP Interoperability booth.  All this
> communication was done via SNMP, not RPC.

Sorry, but you're wrong. The SunNet Manager recieves SNMP from all of the
various sources. But I have another SNMP manager. (Several, in fact.) And guess
what? I can monitor my routers (Wellfleet, cisco, Proteon) and my VMS systems.
But not Suns. Why? Sun does not have an SNMP agent. When I complained to my Sun
salesbeing I was told that I didn't need one. SunNet Manager accesses the data
from Suns by RPC. The problem is that I don't want SunNet Manager. I personally
prefer others.

But the bottom line is that both streams and sockets are much more "portable"
than RPC (at least for now).
 
>>> Disclaimer: Don't take this too seriously. I just like to improve my typing
>>> and probably don't really know anything useful about anything.
>> 
>> Sounds like good advice.

That's why it's there.

						Kevin
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 18:37:00 GMT
From:      CLEBER%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU
To:        comp.protocols.tcp-ip
Subject:   KA9Q by Bdale Garbee


    Could anyone tell me if KA9Q Internet Software Package source
code is available. If yes, what's the places that i can get it
by FTP.
    Thanks in advance,
    Cleber Weishheimer.

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 18:48:51 GMT
From:      alfonso@mtecv2.mty.itesm.mx (Alfonso Jesus Trevino Cantu)
To:        comp.protocols.tcp-ip
Subject:   RPC compilation (SUN sources)


  I've got the sources for using RPC. The sources are the public domain sourc
es from SUN. I took'em from a server in the USENET.
  I would like to know which steps i should take to compile them, cause we're
interested in compiling them in a Macintosh.

  Thank you in advance
Alfonso

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 19:29:02 GMT
From:      kramden.acf.nyu.edu!brnstnd@nyu.edu  (Dan Bernstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <2487@east.East.Sun.COM> geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
> Quoth brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (in <8076:Aug2616:42:1890@kramden.acf.nyu.edu>):
> #auth provides that advantage without that disadvantage! Again, it was
> #designed for client-server applications, unlike RPC.
> Dear Dan,
> 	You seem to understand these things, so maybe you can help me
> with a little semantic problem. Every time I feed a .x file to rpcgen,
> it insists on spitting out client and server stubs, which I find
> convenient for building my distributed applications.  Yet you say that
> RPC wasn't designed for client-server applications.  I'm confused...

Dear Geoff,

Let me illustrate with a trivial example: TAM, Trivial Authenticated
Mail, included in authutil. It is a complete mail system, including a
short shell script for sending mail, a shorter shell script daemon to
receive mail on port 209, programs to set up, print, and empty your
TAMbox, and scripts that convert TAM to regular mail and easy-to-read
formats. It uses an extensible protocol. It is much more secure than
sendmail: since it is implemented on top of auth, *all* forgeries above
TCP are stopped. (Most, if not all, forgeries at a typical university
are done without breaking TCP. auth completely eliminates that problem.)

TAM is short enough to be bugfree, doesn't run as root, and includes the
niceties you'd expect of a friendly mail system: sending you copies of
what you send out, including the TCP address of received mail in case of
DNS trouble, not loading the header with mounds of junk, and reading
mail with no delay.

All the code necessary to set up TAM, including security checks,
/etc/services and /etc/rc.local modifications, and comments, takes 241
lines. That's 5K. In contrast, the README, protocol description, and man
pages take 12K.

Finally, TAM will be trivial to port to any communications system
supporting the same interface for reliable, sequenced, two-party stream
communication.

Try to set up an RPC-based mail system with the features listed above.
You'll quickly appreciate the fact that RPC and client-server are quite
different concepts.

---Dan
``Networking systems so powerful that you can send mail around the
world, with a minimal risk of forgery, in just 5K of code including the
mail reader. Science fiction!''     ---hypothetical Internet guru, 1988
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 19:38:51 GMT
From:      oscsunb!kannan@tut.cis.ohio-state.edu  (Kannan Varadhan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hosts whose IP numbers end in 0........
Thus spake kwe@bu-it.bu.edu (Kent England)
> 	From RFC 1122 Sec 3.2.1.3  Addressing: RFC-791 Section 3.2;
> 
>            "IP addresses are not permitted to have the value 0 or -1 for
>             any of the <Host-number>, <Network-number>, or <Subnet-
>             number> fields (except in the special cases listed above).
>             This implies that each of these fields will be at least two
>             bits long."
>
>	The special cases are:
>
>		[...7 special cases...]
>
>	I therefore conclude that a host part of zero is never a legal source address.

The gentleman said earlier:
: From: mf@ircam.ircam.fr (Michel Fingerhut)
: Date: 25 Aug 90 22:00:42 GMT
: Organization: IRCAM, Paris (France)
: 
: Our LAN is a class B network, 129.102.0.0, and I had the unfortunate idea to
: choose *legal* IP numbers for some of our main hosts of the form 129.102.nn.0,
: (nn != 0).  It's legal for a machine, since the HOST part, nn.0, is definitely
: NOT zero.

Given that he has not explicitly mentioned his subnet masks, and that he
mentions that his "HOST part" is "nn.0", his <network-number> becomes
129.102, and his <host-number> becomes nn.0.

On the face of it, therefore, I'd be inclined to say, he has a point.

>So I think the petitioner should change the addresses on his hosts and
>not bother his
>router vendor.  Isn't the Host Requirements RFC wonderful?  This only
>took five minutes
>to research and that included checking the commentary in RFC 1127.   :-)

Aye, that it is :-)


Kannan


PS:  I'd actually be more inclined to think that he probably subnetted
his router configurations by mistake, and should very, very carefully
check them up before barking up the rouing tree.
-- 
Kannan Varadhan, Internet Engineer, OARNet
Ohio Supercomputer Center, Columbus, OH 43212	+1 (614) 292-4137
email:	kannan@oar.net	|  osu-cis!malgudi.oar.net!kannan
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 19:46:34 GMT
From:      mcsun!hp4nl!nikhefk!werner@uunet.uu.net  (Werner Vogels)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <Aug.25.22.59.16.1990.22640@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
>Sun RPC is proprietary?  (1) RFC 1057 documents the spec. (2) I'm
>reasonably sure that they posted an implementation of RPC to the
>network some time ago, and later on a revised version.  I'm still not
>sure I'd write applications intended to be portable using it, but they
>may be right.  The advantage is that you could move to ISO or anything
>else by changing the lower layers, and the application would not be
>affected.  I get the impression this is the reason they made that
>recommendation.

Don't think you can move to OSI by just "changing a few layers". There
is a lot of layer specific information crossing layer boundaries so if
you view RPC as session and XDR as presentation layer there is a lot
the be changed.

You should read the last part of M.T. Rose's The Open Book on this subject.

Sun's RPC isn't the only RPC mechanisme in the world. See the current ACM
SIGOP issue for a comparison of about 10 of them. Sun has the advantage
that all the NFS implementers had to use SUN RPC to be interconnectable. And
when it's there why not use it for other things as well??? But this doen't
mean it has been chosen by the network community as being the best possible
interface for writing client/server software. (for those who think SUN
invented remote procedure calls, it was there before SUN was born, developed,
as many amazing things, by XEROX PARC)

I hate to say it, but if you want a really safe bet, use sockets. Every
system will have a socket libary hanging around for the next ten years.


Werner H.P. Vogels

Software Expertise Centrum                      
Haagse Hogeschool, Intersector Informatica     tel: +31 70 618419
Louis Couperusplein 2-19, 2514 HP Den Haag     E-mail: werner@nikhefk.nikhef.nl
The Netherlands                                     or werner@hhinsi.uucp
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 20:22:36 GMT
From:      aplcen!haven!ncifcrf!lhc!usenet@uunet.uu.net  (Jules P. Aronson)
To:        tcp-ip@nic.ddn.mil
Subject:   tacacs spec

Does anyone have a source for the tacacs specifications. TACACS is a
protocol, developed by DOD, to authenticate user id and passwords.

	    Thank you
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 20:30:24 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
Your complaint about SunNet has nothing to do with the portability or
lack thereof of RPC.  RPC -- whatever Sun may say -- is not an
alternative to streams or sockets.  Streams and sockets are ways of
accessing the IP or TCP level directly.  RPC imposes on top of that a
data encoding standard and some other communications standards.  It's
roughly comparable to ASN.1 plus a bit of mechanism to identify
applications.

I certainly agree with your complaint that Sun should have implemented
host monitoring using SNMP, but not because of any unportability in
RPC.  RPC is at least as portable as ASN.1.  Indeed at the time the
SNMP standard was issued, Sun had already posted RPC to the net, and
everybody had to write ASN.1 parsers in order to implement SNMP.  So
SNMP would have been more portable if it had been written using RPC.
But it wasn't.  So the problem with rolling your own network
monitoring protocol on top of RPC isn't that RPC is unportable, but
that you're rolling your own network monitoring protocol when there
already exists a standard one.

At any rate, it seems clear that the advice to use RPC is for people
who are writing their own applications.  Nobody claims that RPC is
going to replace raw TCP for implementing FTP.  Give me a break.  The
claim is that if you want to write a high-level application, RPC
handles issues of data portability between different architectures
(byte order, floating point format, etc.), and will allow you to move
between TCP/IP and ISO when RPC is implemented over ISO.  That still
seems reasonable advice.  However RPC is not unique in this.  There
are competing mechanisms at the same.  Since one of the primary goals
of the industry groups is to make sure that Sun doesn't ever repeat
their success with NFS, you can be sure hell will freeze over before
OSF or anyone else adopts RPC.  But at the moment there is specific
alternative with overwhelming support.  Since NFS is so widely
available, and having NFS means that you have to have RPC, that seems
to guarantee wide support for RPC.  Thus until the industry converges
on a single alternative, RPC seems a reasonable choice.

Of course this doesn't address the original question, which is
whether to use sockets or streams to access TCP.  I'm going to do
that in a separate response.
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 21:09:48 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Sockets vs streams.  An attempt to answer the original question
Before we got diverted, the original question was whether code that
needs to access the network should use sockets or streams.  Since
then, I've looked up the streams documentation in SunOS 4.1.  I'm
going to assume that's typical of what streams is like, but of course
that could be wrong.  So take this with a grain of salt.

In my opinion, if you want to support a full range of systems, you're
going to have to deal with both sockets and streams.  So that's not
the basic design choice.  It's also not a big issue anyway.  All
network code that I've seen has subroutines for doing the low-level
network operations such as openning connections.  These are not
complex subroutines.  Maybe half a page each.  They just do the right
combination of socket, bind, connect, etc.  So the streams version is
going to have another version of the subroutine to open a connection,
that uses t_bind and t_connect instead of bind and connect.  Big deal.
Similarly, data transfer subroutines can use send and recv for
Berkeley and t_snd and t_rcv for the streams version.

The real issue seems to be not this, but the problem that streams
doesn't fit the normal Unix view of I/O.  At least in SunOS 4.1, you
can't do read and write on a stream.  Thus the special t_snd and t_rcv
calls for I/O.  Sockets allow you to use either special send and recv
calls, which allow more detailed control over network-level handling,
or normal read and write.  But SunOS provides a streams module you can
push that gives you read and write.  It can't deal with out of band
data, but if you know your application doesn't use OOB, it might be
usable.

It seems clear that you can get streams/sockets compatibility by doing
everything with subroutines and supplying streams and sockets versions
for everything.  But there are two questions that can really only be
answered by people who have experience with using streams:

(1) What is the performance penalty for using the read/write interface
in streams?  With sockets, the send/recv interface is at the same
level as the read/write interface, so there's no reason to expect any
performance penalty for using read and write.  Indeed it's very rare
that you see programs using send and recv.  This allows you to use
things like printf, and to set primary input or output to a socket.
With a stream, if you want to do this, you have to push on the
read/write interface.  I could imagine ways of implementing it that
wouldn't result in any more overhead than doing the low-level I/O, but
there's no way to know whether this will happen in real
implementations other than trying it.  If read/write turns out to be
unacceptable under streams, then you'll need to go to the approach of
using subroutines or macros for your low-level code, so that you can
supply both socket and streams versions.  (By the way, the original
ATT claim was that sockets were a terrible wart on Unix, and streams
were "clean".  I'm not sure what -- if anything -- that meant.  It
seems to me that sockets makes network I/O look a lot more like normal
file I/O than streams do.)

(2) Is it a good idea to use the "sockets library"?  Comments have
been made about both overhead and portability.  Again, this is an
issue that only experience can settle.  Most applications of sockets
that I've seen use read and write.  In this case, all you need the
sockets library for is to open and close the connection.  Once it's
open, you're going to use read and write directly, which will not need
to pass through any sockets emulation.  So this seems to reduce to the
previous question, of whether the read/write interface to streams has
too much overhead.  Whether it makes sense to use the sockets library
for opening and closing seems to reduce to the issue of how good the
sockets libraries are and how compatible the streams implementations
are.  Clearly streams itself is just a framework.  It's only the
actual device drivers and streams modules that determine whether two
implementations look at all alike.  One could imagine a world in which
each streams implementation looks different, but all their socket
emulation libraries are fairly compatible.  One could also imagine a
world in which everyone used the same streams code, but the socket
libraries are very flaky.  In the first case, you'd be better off to
use sockets, in the second you'd be better off to use streams.

Since it's hard to get reliable information on any of these topics, I
think I'd make sure that my code is designed in such a way that you
can handle either case.  That is, I'd run all network operations --
opening, closing, and actual I/O -- through low-level subroutines or
macros that are designed so you can implement them with either sockets
or streams.
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 21:51:37 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!wuarchive!emory!stiatl!bagend!bvsatl!root@ucsd.edu  (Super user)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?

Any obituaries for the sockets programming interface are a bit premature.

I admit that for many systems, Streams are preferable to sockets. However
most streams based systems also layer a sockets interface on top of
the "native" streams. "Why is this?", you may ask. How many public domain
programs do you see using the sockets interface? How many do you see
using the streams interface? 
People who want to make their jobs easier will try to
build upon the existing code base. Much of that code base written to
run on sockets. 

In addition to the inertia of all that existing code, some
systems only support the sockets interface. For instance, many embedded
systems are fairly lean implementations that do not include a streams
implementation. I would bet that most routers, terminal servers,
etc are built on sockets interfaces. If you had to add a new capability
(like SNMP for instance) to such a device, you would use the existing 
services.

There are a lot of weird devices now supporting TCP/IP. For instance,
I just worked on a implementation team that ported TCP/IP (and sockets)
to HP BASIC workstations, believe that or not.  It was difficult
enough to make a usable BASIC->sockets interface. Streams for basic would
be incredibly weird. In order
to bring a large number of diverse systems into the internet fold, there
must be a least common denominator. Right now, sockets appears to be
the least common demoninator. It is not pretty, but it works.

Besides, the awkward style provides a certain amount of job security (8-)).


Bill VerSteeg
Network Research Corp
bvs@nrc.com
-- 
Bill VerSteeg
internet	bvs@nrc.com
UUCP		gatech.edu!galbp!bagend!bvsatl!bvs
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 21:59:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Summary: Is Asyn. I/O supported in WIN/TCP for VMS?


        Previously, I posted a mail regarding asyn. IO in WIN/TCP for VMS and
SYSV. Below is the extract of the mail:
>>
>>        Is asynchoronous i/o supported in WIN/TCP for VMS and SYSV? i.e.
>>is the signals SIGIO and SIGURG supported? For TCP OOB, is WIN/TCP support
>>SIGURG and related ioctl() parameters in SYSv and VMS?
>>        Please direct the mail to me. I will summarize if enough interest.
>>        Thanks.
>>
>>        Regards.
>>
>>- Beng Hang Tay (email: taybengh@nusdiscs)

        So far only 2 people responsed. Both are talking on VMS aspect.
The conclusion is Yes. U can do asynch IO using QIO interface only. However,
nobody seems to sure how do it using ioctl(). At last, I did a test and found
out that it also can be done (VMS only) as follow:

        on = 1;
        ioctl(socket, FIONBIO, &on);

        Thanks for all the people who help.

- Beng Hang (email: taybengh@nusdiscs)


Here are the 2 responses I got:
==========================================
WIN/TCP for VMS does not support asynch I/O in the same mannor that
Unix does it.  It is possible to do it using a QIO interface that is
completely non-portable outside of the VMS world.  It is possible to
write stuff that will reply to urgent stuff however.  I have no clue
how it is done on SYS V.

Warner
--
Warner Losh             imp@Solbourne.COM

============================================
Under VMS, the only way (to my knowledge) that you can get asynchronous
functionality (via ASTs) is by doing $QIOs to the socket handle (which
is actually a standard VMS channel, luckily enough).  I've done it, it's
not that bad, but the docs fully descriptive (in my opinion).

If anyone has figured out how to do this via ioctl() please let me
know.

 //=========================================================================\\
||       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...    ||
 \\==========================================================================//

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      28 August 1990 0630-PDT (Tuesday)
From:      stanonik@nprdc.navy.mil (Ron Stanonik)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
> Dear Dan,
> 	You seem to understand these things, so maybe you can help me
> with a little semantic problem. Every time I feed a .x file to rpcgen,
> it insists on spitting out client and server stubs, which I find
> convenient for building my distributed applications.  Yet you say that
> RPC wasn't designed for client-server applications.  I'm confused...

RPC seems suitable for networking your application if your application
can be implemented using function call/return.  It doesn't seem suitable
for networking your application if your application simply blasts a variable
(and perhaps voluble) amount of text to the user's screen (or into a file).
The non-network implementation of such usually consists of write/puts/printf
to stdout, but RPC doesn't seem to contain a stream type, such that you keep
reading from it until EOF.

Ron Stanonik
stanonik@nprdc.navy.mil
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 90 23:37:36 GMT
From:      logicon.com!tots!tep@nosc.mil  (Tom Perrine)
To:        tcp-ip@nic.ddn.mil
Subject:   PC-NFS performance

I am working on a system that will require "real-time" data transfer
from a Sun IPC to a 386 PC-clone (20 or 25 MHz) via Ethernet. For us,
in this case, "real-time" means 500-1000 byte packets, 10 per second,
from the Sun to the PC. The PC and Sun will be on a dedicated
Ethernet, i.e.  *nothing* else on that wire.

I'm planning to use UDP to communicate between the Sun-side
application and an application on the PC written using the PC-NFS
Programmer's Toolkit.

Unfortunately, someone has convinced people around here that PC-NFS
"won't do real-time" and that we must "write our own Ethernet protocol
stack" to get the performance we need. :-(

Obviously, I am looking for performance ammunition to avoid this
incredible folly. Does anyone have any performance info on
applications written using the PC-NFS Programmer's Toolkit?

Or, failing that, has anyone used any other application-callable
library for MS-DOS that will let me use UDP at this data rate?

HELP!

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.
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 00:34:57 GMT
From:      usc!wuarchive!chris@ucsd.edu  (Chris Myers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: KA9Q by Bdale Garbee
CLEBER%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU writes:

>    Could anyone tell me if KA9Q Internet Software Package source
>code is available. If yes, what's the places that i can get it
>by FTP.
>    Thanks in advance,
>    Cleber Weishheimer.

The KA9Q package is available for anonymous FTP from wuarchive.wustl.edu
[128.252.135.4] in the directory /mirrors/misc/ka9q-tcpip.

Chris Myers
Archive Maintainer
-- 
Chris Myers                                Internet: chris@wugate.wustl.edu
Software Engineer                              UUCP: ...!uunet!wugate!chris
Office of the Network Coordinator                BITNET: chris@wunet.bitnet
Washington University in Saint Louis                 Phone: +1 314 726 7390
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 01:11:14 GMT
From:      messy!mo@bellcore.com  (Michael O'Dell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sun not inventing RPC...
There is a REALLY good reason why XDR and Courier look similar...

Duff's law:
	Don't waste time having good ideas when you can steal better ones!

	-Mike
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 02:13:36 GMT
From:      adelphi!promark!mark@uunet.uu.net  (Mark J. DeFilippis)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP or something like it wanted.  Can anyone help me out?


I have been developing several TLI and Socket based TCP and UDP
applications at work and I want to use the bulk of the event
driven side of the TCP connection based servers I have written
in an application I am working on at home.

What I have is two 386 boxes.  One running SCO XENIX 386, the other
AT&T Unix system V.4.1.  Between them I only have smart serial boards
which run up to 19.2.  I heard of public domain SLIP available but
don't know where to get it, and are patches available that will allow
it to run with both operating systems named above. (Heck, I will
throw the Xenix out if I need to).  Someone mentioned KA9Q and I have seen
this package on osu-cis (Ohio State), but is this what I need? At this time
I have no way to access FTP but have 9600bps modem... can annon uucp...
I would appreciate it if somoene more educated in this stuff would
point me in the right direction.

BTW, I rarely get to read news at all anymore so email would really
be appreciated.  Thanks in advance.


-- 

Mark J. DeFilippis
UUCP: uunet!adelphi!promark!mark
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Aug 90 13:59 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Summary: Is Asyn. I/O supported in WIN/TCP for VMS?

        Previously, I posted a mail regarding asyn. IO in WIN/TCP for VMS and
SYSV. Below is the extract of the mail:
>>
>>        Is asynchoronous i/o supported in WIN/TCP for VMS and SYSV? i.e.
>>is the signals SIGIO and SIGURG supported? For TCP OOB, is WIN/TCP support
>>SIGURG and related ioctl() parameters in SYSv and VMS?
>>        Please direct the mail to me. I will summarize if enough interest.
>>        Thanks.
>>
>>        Regards.
>>
>>- Beng Hang Tay (email: taybengh@nusdiscs)

        So far only 2 people responsed. Both are talking on VMS aspect.
The conclusion is Yes. U can do asynch IO using QIO interface only. However,
nobody seems to sure how do it using ioctl(). At last, I did a test and found
out that it also can be done (VMS only) as follow:

        on = 1;
        ioctl(socket, FIONBIO, &on);

        Thanks for all the people who help.

- Beng Hang (email: taybengh@nusdiscs)


Here are the 2 responses I got:
==========================================
WIN/TCP for VMS does not support asynch I/O in the same mannor that
Unix does it.  It is possible to do it using a QIO interface that is
completely non-portable outside of the VMS world.  It is possible to
write stuff that will reply to urgent stuff however.  I have no clue
how it is done on SYS V.

Warner
--
Warner Losh             imp@Solbourne.COM

============================================
Under VMS, the only way (to my knowledge) that you can get asynchronous
functionality (via ASTs) is by doing $QIOs to the socket handle (which
is actually a standard VMS channel, luckily enough).  I've done it, it's
not that bad, but the docs fully descriptive (in my opinion).

If anyone has figured out how to do this via ioctl() please let me
know.

 //=========================================================================\\
||       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...    ||
 \\==========================================================================//
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Aug 90 08:20 EST
From:      David Greenfield <0004020699@mcimail.com>
To:        members of standard committees <tcp-ip@nic.ddn.mil>
Subject:   Data Communications Magazine
Are you active in the standard's process? Are you interested
in telling informed MIS, and network Managers what's really
happening in your standard's committee? If so then give me, Dave Greenfield, 
a buzz at 212-512-2699 or to the MCI Mail account 402-0699.
I'm the LANs and Internetworking editor at Data Communications 
Magazine. Each month we cover the hottest events in the different
standards committees. From 802 to ANSI to the IETF, the Standard's Watch 
has it all. So drop me a line and lets get the word
out on your committee today.
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 06:10:38 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!sun-barr!newstop!exodus!melohn@ucsd.edu  (Bill Melohn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
>In article <9008242107.AA19843@ucbvax.Berkeley.EDU>, JAZBO@BROWNVM.BROWN.EDU
>("James H. Coombs") writes:
> 
> Sun now states that no new applications should be developed at the socket
> level.  They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1). RPC
> has several advantages:


If this is stated in any Sun documentation or sales literature, it is
in error. Sun Microsystems supports both the sockets and TLI network
programming interfaces, as well as Sun RPC. In our SunOS 4.1 release
TLI is implemented as a "compatiblity module" to the native socket
implementation.  In SVR4, sockets are implemented as a "compatiblity
module" within the streams framework. All Internet services in both
implementations are written using the socket interface.
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 07:49:51 GMT
From:      mcsun!i2unix!inria!ircam!mf@uunet.uu.net  (Michel Fingerhut)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hosts whose IP numbers end in 0........
Michael Patton indeed explains much better than I did what I intended to say...
We are NOT subnetting, the gateway filtering us out is at ANOTHER site, out of
(my) control.

Michael Fingerhut
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Aug 90 16:32:48 CDT
From:      darrel beach <beach@ddnuvax.af.mil>
To:        tcp-ip@nic.ddn.mil
Cc:        beach@ddnuvax.af.mil, beach@ddnuvax.af.mil
Subject:   Help on a uvax/ultrix problem

Well here's one for the unix gurus with the right secret puzzle ring. 
We have a uvax II with ultrix 3.0.  We use Milnet TACs to upload binary
files and frequently use the @B I S command on the TAcs to put the TAC
into binary input mode.  We appear to have a problem in that whenever
the DO BINARY is negotiated from the TAc to the uvax, the uvax puts the
pty into raw mode.  At least I get the same symptoms if I login to the
uvax and do a 'stty raw' as I get when I do an @B I S on the TAC.

We normally use zmodem, specifically rz on the uvax.  I tried creating
a script as follows:
/*
rz
stty cooked
*/
I called it tacrz and tried it but it didn't work.  I still couldn't
get the uvax to do anything but echo after the receive file was
finished.  Anybody got any ideas on what I can do.  How about writing a
c routine to exec rz then make a curses noraw call???

Can I access the socket used for the telnet session and force the TAC
out of binary mode by giving it an IAC DON'T BINARY and hope the
response causes the uvax to do what I want??  Any other ideas?

Darrel Beach
...there's just too much to grok
-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Tue 28 Aug 90 16:03:04-EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        usc!bbn.com!clements@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: looking for old dusty RFCs & working on anonymous FTP RFC
Bob--

What a relief.  Here all these years I'd been feeling vaguely guilty about
"Anonymous FTP", having gotten the impression somewhere along the line that
one of the TENEX jocks at the NIC had done it as a generalization of the
USER NETML, PASS NETML trick I'd invented in RFC 491 to let netmail be
"free" but still accounted for, and now I find you willing to take the blame--
er, uh, credit.  (I could still swear the line about anybody who could spell
"anonymous" was OK was one of mine, though.)

One thing does bother me: if you had the anonymous trick in the arsenal at
the time, why didn't you make "sndmsg" try it when it got the "You must
login first" code from Multics's Server FTP, instead of making me go off
and come up with RFC 491?  Not that I'm disputing your "priority" to the
invention of Anonymous FTP, of course, just wondering.  (I think the timing's
off for you to have been the one who generalized the canned-account-for-mail
gambit if you were using anonymous for EARLY debugging, so presumably it
wasn't the case that anonymous wasn't in the arsenal at the time and I'm
still off the hook.)

cheers, map
-------
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 13:17:47 GMT
From:      oscsunb!osc.edu!henryc@tut.cis.ohio-state.edu  (Henry Clark)
To:        tcp-ip@nic.ddn.mil
Subject:   Cray gated and Network Systems Routers

We have a network configuration which looks like:

     Network A                      Network B
    -----------                    -----------
         |                              |
       -----          ------          -----
       |Sun|----------|Cray|----------|NSC|
       -----          ------          -----

We're currently using Network A as the default route to the Cray, but
we'd like to switch to using Network B as the default route.  We're trying 
to use gated on the Cray to listen to information from the NSC router and 
set its default route there, but if the NSC box dies, then the default should
switch (temporarily :-)) back to the Sun.

As a test of the default route changing ability of gated, we ran a test
between a Sun (on Network B) and the NSC box and gated properly changed
the default route to the NSC, and then reverted back to the old route 
when we disabled the NSC box.  However, the Cray, using similar configuration
information for gated, fails to do this even when it heard of a lower
cost route (of 2 versus 13) through the NSC box.  I've included the
configuration file for gated at the bottom of this message for the Cray.
Normally the Cray uses static routing - will gated override these static
routes when it is running?

On a separate note, has anyone ever examined the route metrics issued
from a NSC box via SNMP?  The results are most interesting (well, I'd 
never heard of a route metric of 80 :-)).

Thanks,
Henry
henryc@[osc.edu,oar.net]

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

gated config file for the Cray:

RIP	pointopoint  <--- supplier so it will time out the interface
HELLO	no
EGP	no

sourceripgateways  131.187.194.1    <---  NSC box adress

trustedripgateways 131.187.194.1 128.146.17.2  <--- NSC box and the Sun

defaultgateway     128.146.17.2 rip metric 13 active  <--- the Sun

donotlistenhost    128.146.17.2 intf all proto rip  <---  the Sun

passiveinterfaces  131.187.193.5  <--- special interface for Cray

=========================================================
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 13:20:00 GMT
From:      0004020699@MCIMAIL.COM (David Greenfield)
To:        comp.protocols.tcp-ip
Subject:   Data Communications Magazine

Are you active in the standard's process? Are you interested
in telling informed MIS, and network Managers what's really
happening in your standard's committee? If so then give me, Dave Greenfield, 
a buzz at 212-512-2699 or to the MCI Mail account 402-0699.
I'm the LANs and Internetworking editor at Data Communications 
Magazine. Each month we cover the hottest events in the different
standards committees. From 802 to ANSI to the IETF, the Standard's Watch 
has it all. So drop me a line and lets get the word
out on your committee today.

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 17:33:00 EDT
From:      "NEAL QUINN" <yx0quinn@nardacva.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   UNSUBSCRIBE
	Secend request:  please remove me from this mailing list.

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 14:00:37 GMT
From:      tiamat!jim@uunet.uu.net  (Jim O'Connor)
To:        tcp-ip@nic.ddn.mil
Subject:   timed and timedc source
To the point:

Is the source for the TCP/IP time synchronization programs "timed" and
"timedc" publically available?

If not, is there a publically available program that does clock sync's
over TCP/IP?

Thanks.
------------- 
James B. O'Connor			jim@tiamat.fsc.com
Ahlstrom Filtration, Inc.		615/821-4022 x. 651
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 14:35:26 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP numbers that end in 0 ...
I have adopted the habit of avoiding using as host addresses anything
that, in any 8-bit aligned piece of the "host part" of an IP address,
are 0x00, 0x01, 0xFE, or 0xFF.  Such addresses may well be legal,
particuarly when correctly interpreted in light of non-8bit subnet
masking, but there's always the odd machine out there who wants to
take things differently.  If there will ever be disagreements they
will be in the boundary conditions.  It's quicker and easier to avoid
problems in advance than to cite RFCs at the new box on the network.

An exception can be observed in my adopted convention of numbering
"things that are only gateways and perform no other `host' functions"
as host 0x01.  This hasn't yet proved to be a problem.
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 14:38:05 GMT
From:      ingr!b11!brien@uunet.uu.net  (Brien Gilliam)
To:        tcp-ip@nic.ddn.mil
Subject:   Test Suites for TCP/IP
I am looking for information on the availability (vendor and prices) of 
verification/compliancy test suites for the following applications...

	TCP/IP

	o FTP
	o TFTP 
	o Telnet
	

	Berkeley(isms)

	o Rlogin
	o Rcp
	o Rsh
	o Sockets Programming Library

Thanks,

Brien Gilliam 				Intergraph Corporation
(205)730-4028				One Madison Industrial Park
..uunet!ingr!b11!topcat!brien		Huntsville, AL 35807
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 13:26:42+0100
From:      Frank Elsner <elsn4000@w107zrz.zrz.tu-berlin.de>
To:        General Network Forum <info-nets@think.com>
Cc:        "TCP/IP Discussion" <tcp-ip@nic.ddn.mil>
Subject:   sendmail.cf
I've a few questions about ruleset 0 in sendmail.cf

The following is defined in sendmail.cf:

# Supersmart relay.  Used when all other attempts to deliver fail
DSmailgzrz.tu-berlin.de
# UUCP relay host
DRmailgzrz.tu-berlin.de

The following rule from ruleset 0 works correct:
R$*<@$*.UUCP>$*		$#tcp$@$[$R$]$:$1<@$2.UUCP>	uucp mail

but the following rule also works correct:
R$*<@$*.UUCP>		$#tcp$@$S$:$1@$2.UUCP		user@host.UUCP

The question for me is "Why do both rules work correctly ?"
What is the meaning of the "[" and "]" on the RHS ?
Why are sometimes "<" and ">"  on the RHS and sometimes not ?

Thanks for enlightning a sendmail beginner.
Frank Elsner
Postmaster at  Central Computing Center
               Technical University Berlin (West, until Oct 3)

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 15:53:45 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP numbers that end in 0 ...

	I've seen two articles now that suggest that it is legitimate to
filter directed broadcasts if the gateway thought they were. Note that it
is wrong to do so, at least for destinations, in the first place. It is
perfectly legitimate for me to address a broadcast packet to a remote network.
	I could see where a gateway might arguably drop packets whose source
address is a broadcast address, but that's a little more intrusive than I'd
want a gateway to be. The host can and should take responsibility for that
sort of checking. A gateway should just do ttl, checksum and routing and
leave everything else alone.
	So even if these routers did have the right sense of what a broadcast
packet on a remote network is, which they can't have, they should not be
discarding those packets.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 16:24:00 GMT
From:      sdd.hp.com!samsung!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
In article <Aug.27.17.09.46.1990.14447@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
>...  (By the way, the original
>ATT claim was that sockets were a terrible wart on Unix, and streams
>were "clean".  I'm not sure what -- if anything -- that meant.  It
>seems to me that sockets makes network I/O look a lot more like normal
>file I/O than streams do.)

It is important to distinguish "streams" (Dennis Ritchie's term for his
revised non-block-device i/o system) from "STREAMS" (what AT&T put into
System V).  Dennis's streams cleaned up a lot of mess, and improved
performance to boot.  But as Dennis is rumored to have said, "`streams'
means something different when shouted".

The way to do i/o on Dennis's streams was with "read" and "write".
Network i/o, in general, looked *exactly* like local device i/o.  This
is the way it should be, unlike what both Berkeley and AT&T have done
(both have reluctantly conceded that most people want to use "read"
and "write" and have made that work, but their hearts were clearly
elsewhere).
-- 
TCP/IP: handling tomorrow's loads today |Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads tomorrow|  henry@zoo.toronto.edu   utzoo!henry
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 17:46:35 GMT
From:      oscsunb!manhandler.oar.net!kannan@tut.cis.ohio-state.edu  (Kannan Varadhan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How does an application like telnet utilise a multi-homed machine?
After an interminable delay, for which I apologise, here's a summary of
what I found on appications connecting to multi-homed hosts.

The question (paraphrased) was:
How do applications like telnet and ftp handle multiple addresses to a
given host?  Do they, should they, try the different addresses?
Can one, as the one who manages a machine, specify the order in which
users will see the different addresses, say, via named and the DNS?

Basically, the consensus is that 

a)	named is not required or guaranteed to return multiple addresses
in the given order. [RFC 1034, Page 30]

b)	It is upto to the resolver to specify the order in which
addresses are to be preferred. [RFC 1034 Pg 30, RFC 1123 sections 2.3, 6.1.3.4]

	This can be done via an `address' line in the resolv.conf file,
	a sortlist in your named.boot file, for bind software, or some
	`logical' something incantations for VMS systems.  Other
	machines, software etc., I expect have this too, though I
	didn't get into gory details.

c)	4.2 BSD based (or older) software will only return or use one address
	per name, because of a static host table concept.  
	4.3 BSD based software, and other miscellaneous software use
	multiple addresses, if given them.  PC based applications
	typically do not use the multiple addresses.  PCIP from FTP
	software orders the addresses, and uses then picks one up.

d)      There is no load-balancing etc. of the network numbers
involved.  Applications are not also required to try all the different
addresses. [RFC1034]

e)	The relevant RFCs are Page 30 of RFC 1034, Sections 2.3, 5.3.4
and 6.1.3.4 of RFC 1123, the HRRFC.  I have placed sections of the RFC
at the end of this message, FYC.

Thanks go to
		 jbvb@vax.ftp.com (James Van Bokkelen)
		 emv@math.lsa.umich.edu (Edward Vielmetti)
		 kim@lut.fi (Kimmo Suominen)
		 braden@venera.isi.edu
		 Kraig R. Meyer <kmeyer@wrl.dec.com>
		 MARC@UNB.CA
		 Mark Towfigh <towfiq@interlan.interlan.com>
	and	 John Chanbers <ll-xn!minya!jc@ima.ima.isc.com>

Kannan

-----
I have copies of the responses I received.  In case anyone is
interested, send me some mail, and I'll forward them to you.

-----
Bob Braden and Kriag Meyers pointed me to sections of the RFC, which
follow...

From [RFC 1034], Domain Concepts and Facilities, Page 30

      based function.  Given a character string, the caller wants
      one or more 32 bit IP addresses.  Under the DNS, it
      translates into a request for type A RRs.  Since the DNS does
      not preserve the order of RRs, this function may choose to
      sort the returned addresses or select the "best" address if
      the service returns only one choice to the client.  Note that
      a multiple address return is recommended, but a single
      address may be the only way to emulate prior HOSTS.TXT
      services.



And, from the HRRFC, [RFC1123], APPLICATIONS LAYER -- GENERAL,

   2.3  Applications on Multihomed hosts

      When the remote host is multihomed, the name-to-address
      translation will return a list of alternative IP addresses.  As
      specified in Section 6.1.3.4, this list should be in order of
      decreasing preference.  Application protocol implementations
      SHOULD be prepared to try multiple addresses from the list until
      success is obtained.  More specific requirements for SMTP are
      given in Section 5.3.4.

      When the local host is multihomed, a UDP-based request/response
      application SHOULD send the response with an IP source address
      that is the same as the specific destination address of the UDP
      request datagram.  The "specific destination address" is defined
      in the "IP Addressing" section of the companion RFC [INTRO:1].

      Similarly, a server application that opens multiple TCP
      connections to the same client SHOULD use the same local IP
      address for all.


      5.3.4  Reliable Mail Transmission

         When it succeeds, the mapping can result in a list of
         alternative delivery addresses rather than a single address,
         because of (a) multiple MX records, (b) multihoming, or both.
         To provide reliable mail transmission, the sender-SMTP MUST be
         able to try (and retry) each of the addresses in this list in
         order, until a delivery attempt succeeds.  However, there MAY
         also be a configurable limit on the number of alternate
         addresses that can be tried.  In any case, a host SHOULD try at
         least two addresses.

         The following information is to be used to rank the host
         addresses:

         (1)  Multiple MX Records -- these contain a preference
              indication that should be used in sorting.  If there are
              multiple destinations with the same preference and there
              is no clear reason to favor one (e.g., by address
              preference), then the sender-SMTP SHOULD pick one at
              random to spread the load across multiple mail exchanges
              for a specific organization; note that this is a
              refinement of the procedure in [DNS:3].

         (2)  Multihomed host -- The destination host (perhaps taken
              from the preferred MX record) may be multihomed, in which
              case the domain name resolver will return a list of
              alternative IP addresses.  It is the responsibility of the
              domain name resolver interface (see Section 6.1.3.4 below)
              to have ordered this list by decreasing preference, and
              SMTP MUST try them in the order presented.


         6.1.3.4  Multihomed Hosts

            When the host name-to-address function encounters a host
            with multiple addresses, it SHOULD rank or sort the
            addresses using knowledge of the immediately connected
            network number(s) and any other applicable performance or
            history information.

            DISCUSSION:
                 The different addresses of a multihomed host generally
                 imply different Internet paths, and some paths may be
                 preferable to others in performance, reliability, or
                 administrative restrictions.  There is no general way
                 for the domain system to determine the best path.  A
                 recommended approach is to base this decision on local
                 configuration information set by the system
                 administrator.

            IMPLEMENTATION:
                 The following scheme has been used successfully:

                 (a)  Incorporate into the host configuration data a
                      Network-Preference List, that is simply a list of
                      networks in preferred order.  This list may be
                      empty if there is no preference.

                 (b)  When a host name is mapped into a list of IP
                      addresses, these addresses should be sorted by
                      network number, into the same order as the
                      corresponding networks in the Network-Preference
                      List.  IP addresses whose networks do not appear
                      in the Network-Preference List should be placed at
                      the end of the list.
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 19:12:06 GMT
From:      att!dptg!mtune!rkh@ucbvax.Berkeley.EDU  (Robert Halloran)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Setting Netmask Subnet bits on AT&T machine using TWG TCP/IP
In article <9008281051.AA19113@ucbvax.Berkeley.EDU> CSSNET@NUSDISCS.BITNET writes:
>I am working on a AT&T 3B/4000 machine running on UNIX SYS V Rel 3.1.5.
>We are currently running ENHANCED TCP/IP WIN/3B Rel 2.1.1.
>
>We are using a Class B internet address, and we would like to set our subnet
>mask to 255.255.255.0 instead of the default 255.255.0.0.

You have my sympathy; the release 2.x WIN code for 3B systems doesn't support
subnetting.  Ifconfig, BTW, is in /usr/etc.  The first 3B release from Wollongong
supporting subnets is release 3; the current version on the 3b2 line is 3.0.1.
I do not know if an upgrade is available for the '4000.

						Bob Halloran
=========================================================================
Internet: rkh@mtune.dptg.att.com		UUCP: att!mtune!rkh		
Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed.
Quote: "How do you know when a politician is lying?  His lips move." 
	- M-m-max Headroom
       "Read my lips - no new taxes..."  - G. Bush, 1988
=========================================================================
-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 20:05:05 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
>The real issue seems to be not this, but the problem that streams
>doesn't fit the normal Unix view of I/O.  At least in SunOS 4.1, you
>can't do read and write on a stream.

Well, yes, you can, actually.  You have programs that do "read()" and
"write()" on terminals under SunOS 4.x, right?  If so, they're doing
"read()" and "write()" on streams.... 

What you can't do in SunOS 4.1 - nor in the S5R3 systems from which much
of that code came - is "read()" and "write()" on *TLI* streams that
don't have the "tirdwr" module pushed atop them.  That module, which you
mention, actually comes from S5R3.

In S5R[34], streams isn't really the equivalent of sockets, streams
*plus TLI* is.

(I wouldn't be at all surprised to find that in the Research UNIX
streams code, you *can* do "read()" and "write()" on streams used for
network connections.  I don't know if this is the case, but I wouldn't
be surprised if it were....)
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 21:22:41 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!merk!alliant!linus!think.com!barmar@ucsd.edu  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <725@exodus.Eng.Sun.COM> melohn@mrbill.Eng.Sun.COM (Bill Melohn) writes:
>>In article <9008242107.AA19843@ucbvax.Berkeley.EDU>, JAZBO@BROWNVM.BROWN.EDU
>>("James H. Coombs") writes:
>> Sun now states that no new applications should be developed at the socket
>> level.
>If this is stated in any Sun documentation or sales literature, it is
>in error.

It's stated in *boldface* at the beginnings of chapters 10 and 11 of the
SunOS 4.1 Network Programming Guide:

    WARNING:  Socket-based interprocess communication (IPC), while still
    supported, is no longer the preferred framework for transport-level
    programming....

    If you are building a new network application that requires direct
    access to transport facilities, use the TLI mechanisms....  New
    programs should not be based on sockets.

Are you saying that Sun does not actually suggest that TLI be preferred
over sockets for new programs?

Of course, if a program is intended to be portable to other systems that
only have sockets then Sun's recommendation should be ignored.  And Sun
will have to continue to support sockets for the foreseeable future, so
such programs will also be portable to SunOS.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 21:33:00 GMT
From:      yx0quinn@NARDACVA.NAVY.MIL ("NEAL QUINN")
To:        comp.protocols.tcp-ip
Subject:   UNSUBSCRIBE


	Secend request:  please remove me from this mailing list.

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 22:26:35 GMT
From:      ncrlnk!ncrstp!npdiss1!mercer@uunet.uu.net  (Dan Mercer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP numbers that end in 0 ...
In article <13391@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
:
:	I've seen two articles now that suggest that it is legitimate to
:filter directed broadcasts if the gateway thought they were. Note that it
:is wrong to do so, at least for destinations, in the first place. It is
:perfectly legitimate for me to address a broadcast packet to a remote network.
:	I could see where a gateway might arguably drop packets whose source
:address is a broadcast address, but that's a little more intrusive than I'd
:want a gateway to be. The host can and should take responsibility for that
:sort of checking. A gateway should just do ttl, checksum and routing and
:leave everything else alone.
:	So even if these routers did have the right sense of what a broadcast
:packet on a remote network is, which they can't have, they should not be
:discarding those packets.
:-- 
:					+-DLS  (dls@mentor.cc.purdue.edu)


I disagree - it is a perfectly legitimate function for routers to
perform message filtering.  Before we hooked to the Internet,  we set
up our routers to prohibit certain types of traffic - it was far
easier to manage the change in the one router than have to migrate it
through the entire net (dozens,  nay scores, of machines).  In
addition,  the functionality we wanted to restrict we only wanted to
restrict to outsiders.

-- 

Dan Mercer
Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer)
"MAN - the only one word oxymoron in the English Language"
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      29 August 1990 0643-PDT (Wednesday)
From:      stanonik@nprdc.navy.mil (Ron Stanonik)
To:        auspex!guy@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Re: Sockets vs streams.  An attempt to answer the original question
Wollongong's win 3b implementation of tcp/ip (on our 3b2's running
sysVr3) seems to only push tirdwr for the accept socket call.  We've
installed a couple of bsd programs (syslog and lpr), which use
read/write and seem to work just fine.

Anybody know what tirdwr does?  Gather/scatter packets to satisfy
the read/write size argument?  Some oob handling?

Ron Stanonik
stanonik@nprdc.navy.mil

ps. Is there anyway to get a list of all the modules pushed onto
a stream.  I_LOOK only lists the top most module.
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 90 23:47:00 GMT
From:      CSSNET@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Setting Netmask Subnet bits on AT&T machine using TWG TCP/IP


S O S !!!


I am working on a AT&T 3B/4000 machine running on UNIX SYS V Rel 3.1.5.
We are currently running ENHANCED TCP/IP WIN/3B Rel 2.1.1.

We are using a Class B internet address, and we would like to set our subnet
mask to 255.255.255.0 instead of the default 255.255.0.0.

I am quite surprised that our WIN/TCP package does not have the "ifconfig"
command, although the "route" command is included. Or have I missed anything?

Thus, I wonder if it is possible to set the subnet mask without the "ifconfig"
command.

Had anyone encountered this problem?  If so, please reply directly to my
BITNET address, as I am not monitoring this list.

Any help or advice will be greatly appreciated.

--------------------------------------------------------------------------------
Tan Hsiao Wei
Department of Information Systems and Computer Science
National University of Singapore
BITNET: tanhw@nusdiscs.bitnet
     or tanhw%nusdiscs.bitnet@cunyvm.cuny.edu
--------------------------------------------------------------------------------

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Aug 90 09:48:23 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
    The way to do i/o on Dennis's streams was with "read" and "write".
    Network i/o, in general, looked *exactly* like local device i/o.  This
    is the way it should be, unlike what both Berkeley and AT&T have done
    (both have reluctantly conceded that most people want to use "read"
    and "write" and have made that work, but their hearts were clearly
    elsewhere).

I would say rather that using read/write on network connections is
the way most people would *like* it to be.  The reality is that on
most systems the local filesystem is a pretty tame beast compared to
a network connection.  Unless the OS/language combination's
read/write was designed with network connections in mind (which means
boolean flag arguments and wide variations in behaviour depending on
them), use of read/write is likely to result in a cantankerous and
unreliable network application...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Aug 90 08:44:46 MDT
From:      "Doug McCallum" <dougm@ico.isc.com>
To:        stanonik@nprdc.navy.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re(2): Re: Sockets vs streams.  An attempt to answer the original question
In reply to your message of 29 August 1990 0643-PDT (Wednesday)
-------
> Anybody know what tirdwr does?  Gather/scatter packets to satisfy
> the read/write size argument?  Some oob handling?

All tirdwr does is get rid of the protocol part of the TLI (actually TPI)
messages.  Read/write can only deal with what are called M_DATA messages.
The protocol between TLI and TPI (Transport Provider Interface) has another
message block type (M_PROTO) in front of the data.  It also interprets
disconnects.  Anything else, like an expedited data message (T_EXDATA_IND)
is a fatal error.

> ps. Is there anyway to get a list of all the modules pushed onto
> a stream.  I_LOOK only lists the top most module.

Not in V.3.

Doug McCallum
Interactive Systems Corp.
dougm@ico.isc.com
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 03:01:16 GMT
From:      mentor.cc.purdue.edu!dls@purdue.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP numbers that end in 0 ...
In article <563@npdiss1.StPaul.NCR.COM>, mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) writes:
> I disagree - it is a perfectly legitimate function for routers to
> perform message filtering. ...

	Well, first of all, the original poster's description suggests that
this is the default behaviour of the router, and not the result of some
arbitrary packet filtering.
	Secondly, sure, you can filter packets and many routers will let
you do that arbitrarily ("ok, no packets with a "7" in the 47th data byte--
I always hated those."]. The price you pay for that explicit nonconformance
to the protocol is that you can't interoperate with other systems. IP doesn't
include packet filtering and to the extent that you do it, you reduce the
ability of your users to talk IP with other hosts. Certainly the more
carefully you do it, the less impact it will have, but it's not free and if
you don't consider all the legitimate uses that might be affected, your users
lose. Following the spec, on the other hand, probably won't get you into
trouble. I'm not a packet filtering fan... :-)
	And finally, in this case in particular (remote gateway), you CAN'T
know whether the address is a broadcast address or not, since the mask isn't
available to you. If you take the "we know better than you" approach and
discard packets that look like they may use broadcast addresses, you won't
be able to talk to perfectly legitimate, conforming, IP hosts.  You'd get
what you deserved, but your unsuspecting users and anyone who has to route
through you would be the ones who really get it.
	The only conservative, and thus wise, way for a gateway to route
a packet that has a different network number than any of its interfaces is
to look at the piece it needs to for routing (first 2 octets for Class B)
and leave the host part to the magic of gateways that know something about
it. That keeps them from getting in the way when new things, like subnetting,
come along.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Aug 90 15:47 H
From:      <CSSNET%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Setting Netmask Subnet bits on AT&T machine using TWG TCP/IP

S O S !!!


I am working on a AT&T 3B/4000 machine running on UNIX SYS V Rel 3.1.5.
We are currently running ENHANCED TCP/IP WIN/3B Rel 2.1.1.

We are using a Class B internet address, and we would like to set our subnet
mask to 255.255.255.0 instead of the default 255.255.0.0.

I am quite surprised that our WIN/TCP package does not have the "ifconfig"
command, although the "route" command is included. Or have I missed anything?

Thus, I wonder if it is possible to set the subnet mask without the "ifconfig"
command.

Had anyone encountered this problem?  If so, please reply directly to my
BITNET address, as I am not monitoring this list.

Any help or advice will be greatly appreciated.

--------------------------------------------------------------------------------
Tan Hsiao Wei
Department of Information Systems and Computer Science
National University of Singapore
BITNET: tanhw@nusdiscs.bitnet
     or tanhw%nusdiscs.bitnet@cunyvm.cuny.edu
--------------------------------------------------------------------------------
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 05:24:30 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!nelson@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Clarkson packet drivers 7.x now available
The 7.x release of the Clarkson collection of packet drivers is now
available.  The summary is given below.  In addition to the new
drivers and bug fixes, a switch has been added that lets you use
Novell without econfiging your server.

Summary:
	New drivers: UB PC/NIC, LocalTalk, Tiara, NTI.
	Bugs fixed: 3c505, 3c503, wd8003e, nb, ne1000.
	Bug found but not fixed: 3c523.

The packet drivers are for MS-DOS, and serve to hide the difference between
network cards, and allow multiple protocol stacks to access the same card.
Most often people are interested in running Novell's Netware and TCP/IP
at the same time.

		The Clarkson packet driver collection

Availability

The Clarkson collection of packet drivers is available by FTP, by
archive-server, and by modem.  They come in two flavors -- executables
only (drivers.arc), and source+executables (driverss.arc).  All of the
following instructions apply to both drivers.arc and driverss.arc.

Mail:

I distribute the packet drivers on a 1.2 MB 5.25" disk, or a 720K 3.5"
disk.  You can send me a check for $20, or you can send me a purchse
order and I will bill you for $22.  NY residents add 7% sales tax,
overseas orders add $3 for shipping.  If you send a check, please be
sure it is in US dollars -- the bank charges me $15 to convert checks
drawn in foreign currencies.

	Russell Nelson
	11 Grant St.
	Potsdam, NY 13676

FTP:

sun.soe.clarkson.edu:/pub/ka9q/drivers.arc
grape.ecs.clarkson.edu:/e/tcpip/drivers.arc

Archive-server:

Send mail to archive-server@sun.soe.clarkson.edu and put the following
command as the body of your message:
	help
This will send you a help message.  Reading this help message will tell
you how to fetch the packet drivers.

Modem:

Call the Clarkson Heath User's Group's BBS: (315)268-6667, 8N1,
1200/2400 Baud, 24 hours.  Change to file area 24 and download drivers.arc.

-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
We won the cold war.  The Russians spent trillions defending their stuff,
then they found that they didn't have any stuff.  Will we avoid the same trap?
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Aug 90 10:30 EST
From:      David Greenfield <0004020699@mcimail.com>
To:        Standard Committee members <tcp-ip@nic.ddn.mil>
Subject:   Data Commmunications Retraction
.
In an attempt to provide reliable and effective
coverage of the current standards development,
a message was posted on 08-27. It has since
been brought  to my attention that no matter how innocent,
or how beneficial such a request was, it was still for
commercial purposes and violated the use of the Internet.
Consequently, please ignore the request and rest assured
that such postings will not occur in the future.
.
Sincerely,
.
Dave Greenfield
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 06:34:42 GMT
From:      swrinde!cs.utexas.edu!sun-barr!newstop!exodus!melohn@ucsd.edu  (Bill Melohn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In article <1990Aug28.212241.10099@Think.COM> barmar@think.com (Barry Margolin) writes:
>Are you saying that Sun does not actually suggest that TLI be preferred
>over sockets for new programs?

Yes. Sun makes no official recommendation as to whether users should
use the socket or TLI method of accessing the network. Both are fully
supported in SunOS, and both have useful features, as does the RPC
method. In fact, we use all three methods in various peices of the
utilities bundled with the operating system. A bug report has now been
filed on the warning message at the beginning of Chapter 10 and 11 in
the Network Programmers Guide.
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Aug 90 16:33 C
From:      CLEBER%SBU.UFRGS.ANRS.BR@UICVM.uic.edu
To:        TCP-IP@NIC.DDN.MIL
Subject:   RPC/XDR source code
    I know that RPC/XDR source code is available for FTP in
TITAN.RICE.EDU. Could anyone tell me what are the files that
i must get from there.
    Is there some NFS implementation available ?
    Thanks in advance,
    Cleber Weissheimer.

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Aug 90 18:12:35 PDT
From:      postel@venera.isi.edu
To:        ietf-hosts@nnsc.nsf.net, ietf-rreq@jessica.stanford.edu, tcp-ip@nic.ddn.mil
Cc:        postel@venera.isi.edu
Subject:   Hosts whose IP numbers end in 0...
Hi.

I believe the following analysis by David L Stevens is correct.  Some
discussion like this should be added to all requirements documents and
other descriptions of address filtering and/or broadcast addresses.

--jon.

~~~~~~~~~         ----- Begin Included Message -----        ~~~~~~~~~~
Date: 29 Aug 90 16:31:45 GMT
From: usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu  (David L Stevens)
Subject: Re: Hosts whose IP numbers end in 0........
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil


	A point of clarification, since several people have sent me e-mail
on the topic...

	When I say "shouldn't" regarding filtering, I mean in the RFC-speak
sense of "it's a bad idea." I don't mean it's contrary to any RFC, so you
don't need to point out to me that some say it's fine for gateways to filter
broadcast packets.
	Beyond that, there is the fact that it is impossible to do it right
in the case we were talking about, and THAT is just plain wrong. A gateway
that isn't directly attached or administered by the same people as an
arbitrary IP address CANNOT answer the question "is this a broadcast?" so
it doesn't matter whether an RFC says you can or not; in practice, you can't.
	Here's why: suppose you're a gateway and you don't have anything to
do with the network 128.210 and you get a datagram with either source or
destination as, say, "128.210.1.127". Is that a broadcast packet or not?
	Well, if my subnet mask is 255.255.255.128, the host part is all
1's and it's a broadcast. If my subnet mask is 255.255.255.0, it's a host.
The remote gateway can't know what the mask is.

	"But WAIT!" you say. "What about an ICMP mask request??" The question,
then, is, to where do you send such a mask request? Well, the only address on
that net (in general) you know is 128.210.1.127, so that's you're only choice.
But if it's a host, it won't (in general) answer, because only gateways
are required to answer mask requests [rfc 950; 1122 says some hosts may not
reply]. And, of course, if you don't get an answer, it doesn't mean it's a
host-- maybe the datagram was lost. Besides, you'd be committing the sin you're
trying to prevent-- sending a directed broadcast. And then, would you keep this
around or send a mask request for every routed packet-- just completely
impractical.
	So, even though RFC's say you can filter broadcast packets, the case
in point doesn't allow it on the grounds that you cannot compute "is this a
broadcast?" and it is clearly wrong for the router to drop the packet. "Wrong"
in the sense that it inhibits legitimate use of the Internet. We have a clear
demonstration of that.

	Philosophically, it's wrong because it flattens the hierarchical
address space by requiring the internal structure of networks to be visible
to the outside world for things to work. I assert that the only machines that
can have any legitimate interest in the host part of an IP address are those
under the same administration as the address in question. If I want to allow a
host on your net to send broadcasts on mine, who benefits by some other
gateway (yours or an intervening one) filtering it?? Only my networks can
suffer from the broadcasting and if I don't filter it, nobody should...

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

~~~~~~~~~         ----- End Included Message -----        ~~~~~~~~~~
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 14:01:36 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hosts whose IP numbers end in 0........
In article <1990Aug28.074951.21126@ircam.ircam.fr>, 
mf@ircam.ircam.fr (Michel Fingerhut) writes:
> Michael Patton indeed explains much better than I did what I intended
to say...
> We are NOT subnetting, the gateway filtering us out is at ANOTHER
site, out of
> (my) control.
> 
> Michael Fingerhut

	Mike's pretty good at that.

	I was wrong to assume anything about subnetting since you didn't say
anything about using subnets.  As others pointed out, those addresses would
cause legal problems if you ever were to subnet, but that is beside the point.
It does beg the question of how you avoid this problem with arbitrary subnet
length changes.  That can wait for more experience with variable subnet
routing protocols.  :-)

	It did occur to me that if a router were configured with subnetting
assumed (as others pointed out), then the router would probably need to take
precedence over the host's idea of subnetting (assuming the class B were
really subnetted), so in the long run, particularly for those who are planning
migrations from bridged to routed environments, these sorts of addresses are
to be avoided.  (Beside your point again, I know.)

	From the above, I get the impression that the router that is doing
the filtering is not part of your class B and, therefore, should not have any
idea of your subnetting or not.  I would be interested to find out more about
the source of this behaviour.  Is it a bug, or is the router vendor addressing
some other issue?

	--Kent
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 15:13:41 GMT
From:      eagle!news@ucbvax.Berkeley.EDU  (Betty Jo Armstead)
To:        tcp-ip@nic.ddn.mil
Subject:   auth as a replacement for rpc

 A few days back someone mentioned auth which seemed to be a replacement
 for rpc.  I am interested in finding out more information about
 auth.

--
Betty Jo Armstead              SVERDRUP Technology Inc.
21000 Brookpark Rd.Ms 142-2
Nasa Lewis Research Center
Cleveland Ohio 44135           From: xxbja@csduts1.lerc.nasa.gov
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 15:30:00 GMT
From:      0004020699@MCIMAIL.COM (David Greenfield)
To:        comp.protocols.tcp-ip
Subject:   Data Commmunications Retraction

.
In an attempt to provide reliable and effective
coverage of the current standards development,
a message was posted on 08-27. It has since
been brought  to my attention that no matter how innocent,
or how beneficial such a request was, it was still for
commercial purposes and violated the use of the Internet.
Consequently, please ignore the request and rest assured
that such postings will not occur in the future.
.
Sincerely,
.
Dave Greenfield

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 16:31:45 GMT
From:      usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hosts whose IP numbers end in 0........

	A point of clarification, since several people have sent me e-mail
on the topic...

	When I say "shouldn't" regarding filtering, I mean in the RFC-speak
sense of "it's a bad idea." I don't mean it's contrary to any RFC, so you
don't need to point out to me that some say it's fine for gateways to filter
broadcast packets.
	Beyond that, there is the fact that it is impossible to do it right
in the case we were talking about, and THAT is just plain wrong. A gateway
that isn't directly attached or administered by the same people as an
arbitrary IP address CANNOT answer the question "is this a broadcast?" so
it doesn't matter whether an RFC says you can or not; in practice, you can't.
	Here's why: suppose you're a gateway and you don't have anything to
do with the network 128.210 and you get a datagram with either source or
destination as, say, "128.210.1.127". Is that a broadcast packet or not?
	Well, if my subnet mask is 255.255.255.128, the host part is all
1's and it's a broadcast. If my subnet mask is 255.255.255.0, it's a host.
The remote gateway can't know what the mask is.

	"But WAIT!" you say. "What about an ICMP mask request??" The question,
then, is, to where do you send such a mask request? Well, the only address on
that net (in general) you know is 128.210.1.127, so that's you're only choice.
But if it's a host, it won't (in general) answer, because only gateways
are required to answer mask requests [rfc 950; 1122 says some hosts may not
reply]. And, of course, if you don't get an answer, it doesn't mean it's a
host-- maybe the datagram was lost. Besides, you'd be committing the sin you're
trying to prevent-- sending a directed broadcast. And then, would you keep this
around or send a mask request for every routed packet-- just completely
impractical.
	So, even though RFC's say you can filter broadcast packets, the case
in point doesn't allow it on the grounds that you cannot compute "is this a
broadcast?" and it is clearly wrong for the router to drop the packet. "Wrong"
in the sense that it inhibits legitimate use of the Internet. We have a clear
demonstration of that.

	Philosophically, it's wrong because it flattens the hierarchical
address space by requiring the internal structure of networks to be visible
to the outside world for things to work. I assert that the only machines that
can have any legitimate interest in the host part of an IP address are those
under the same administration as the address in question. If I want to allow a
host on your net to send broadcasts on mine, who benefits by some other
gateway (yours or an intervening one) filtering it?? Only my networks can
suffer from the broadcasting and if I don't filter it, nobody should...

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 16:49:31 GMT
From:      netcom!jbreeden@apple.com  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   PC/IP as a BOOTP server
I've heard a rumor that PC/IP (and I guess FTP's PC/TCP) can be used as
a BOOTP server. Is this true? If so, can someone point me to a "how to"
doc?

Thanx in advance;
-- 
 John Robert Breeden, 
 netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden
 -------------------------------------------------------------------
 "The nice thing about standards is that you have so many to choose 
  from. If you don't like any of them, you just wait for next year's 
  model."
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 17:18:32 GMT
From:      ncis.tis.llnl.gov!lance.tis.llnl.gov!guerra@uunet.uu.net  (Frank Guerra)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for SYS V
I recall that someone not too recently was looking for a SLIP implementation
for a 3b2.  I don't recall seeing any responses to his query.  Therefore, I'd 
like to ask again if there is such an animal.  E-mail is preferred but not
absolutely necessary.

Frank
guerra@lance.tis.llnl.gov
Lawrence Livermore National Laboratory
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Aug 90 16:57:51 +0100
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu (David L Stevens)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Hosts whose IP numbers end in 0........

However, the network wide broadcast addresses will always be broadcasts
and grounds for potential filtering.  Something like 128.102.255.255 will
always be a broadcast no matter what subnet scheme is in use, unless
you are doing something really weird(!)...  Packets to this address should
NEVER be forwarded...


					Thanks,
					   Milo
-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 19:33:00 GMT
From:      CLEBER%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU
To:        comp.protocols.tcp-ip
Subject:   RPC/XDR source code


    I know that RPC/XDR source code is available for FTP in
TITAN.RICE.EDU. Could anyone tell me what are the files that
i must get from there.
    Is there some NFS implementation available ?
    Thanks in advance,
    Cleber Weissheimer.

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 21:04:25 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
>RPC seems suitable for networking your application if your application
>can be implemented using function call/return.  It doesn't seem suitable
>for networking your application if your application simply blasts a variable
>(and perhaps voluble) amount of text to the user's screen (or into a file).

Actually, there is an application I use that uses RPC to blast variable
amounts of text into a file; it's the UNIX copy program.  Since my
machine is diskless, any such copies go over NFS, which runs atop
RPC....

This does, of course, involve more than just the RPC code; it also
involves code that sits atop RPC, including code that turns "read()"s
and "write()"s into the NFS requests sent over RPC.  As such, you might
have to write similar stuff yourself if you were to use RPC for bulk
data transport in your application, and it wouldn't plug into "read" and
"write" in most UNIX systems without some work.
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 21:11:17 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
>Are you saying that Sun does not actually suggest that TLI be preferred
>over sockets for new programs?

I suspect what he's saying that that different people within Sun say
different things, and that he doesn't agree with the authors of those
statments in chapters 10 and 11.  Which of those people speak for Sun,
if any, is a different matter.  (Sun is sufficiently large that it's not
clear the statement "Sun says XXX" is necessarily meaningful; even if
one particular Sun document says "do XXX", that may not mean it's
official corporate policy.)

>Of course, if a program is intended to be portable to other systems that
>only have sockets then Sun's recommendation should be ignored.  And Sun
>will have to continue to support sockets for the foreseeable future, so
>such programs will also be portable to SunOS.

And S5R4 has a sockets interface, at least for TCP/UDP/IP (given that
Berkeley has, I think, modified the sockets interface for ISO - just as
AT&T had to modify the STREAMS/TLI interface for TCP, by putting in the
notion of an "urgent mark" - I don't know whether, even if you can use
the sockets library to talk to other protocols, you would do so in the
same way you did under 4.3-Reno or 4.4BSD).

And then you can look forward to POSIX's networking interfaces; I don't
know if either of them (DNI in particular) will look like sockets,
STREAMS+TLI, or none of the above....
-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 21:21:23 GMT
From:      ux1.cso.uiuc.edu!dino!fs-1.iastate.edu!iastate.edu!john@iuvax.cs.indiana.edu  (Hascall John Paul)
To:        tcp-ip@nic.ddn.mil
Subject:   Problem retrying "connect"
Given the following code:

	[... socket(), getservbyname(), sin <- values ...]

        while (connect(s, &sin, sizeof(sin)) < 0) {
		perror("connect");
		if (++retry > RETRY) exit(1);
		sleep(2);
	}

If the server (to which I am trying to connect) is not there, I get:

	connect: Connection refused             <-- expected
	connect: Invalid argument		<-- WHY??
	    :
	    :
	connect: Invalid argument

What am i forgetting here?

Thanks,
John Hascall  /  john@iastate.edu  /  hascall@atanasoff.cs.iastate.edu
-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 21:36:52 GMT
From:      bcstec!voodoo!yo.uucp@uunet.uu.net  (howie)
To:        tcp-ip@nic.ddn.mil
Subject:   Questions about the use of ping.

A couple of questions about the use of ping:


1) Because ping uses ICMP packets, we are not getting a true picture of how
   long it takes for data to be transferred to another machine, True?

   Is there an easy way to determine the transfer time of data, other 
   than setting up a connection with FTP, and moving some test data?


2) The man page for ping warns against using ping in shell scripts.  Is it
   really that dangerous to use ping automatically, if the number of packets 
   is limited to say, 3?

   This would be helpful to our users, but we don't want to cause undue
   congestion.


3) Is there an alternative to the standard BSD ping that we should consider
   using?



				thanks for any help,
--
				       howie              

				       uw-beaver!ssc-vax!voodoo!howie 
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 90 22:09:26 GMT
From:      ucselx!petunia!csuchico.edu!csuchico.edu!robin@ucsd.edu  (Robin Goldstone)
To:        tcp-ip@nic.ddn.mil
Subject:   how do I get RFC's?
Yes, this is a stupid question!  I though that RFC's were available
from sri-nic.arpa (nic.ddn.mil).  I FTP'd there but can't figure out
how to manipulate my way through the directory structure...  Can
someone e-mail me the correct procedure for retrieving RFC's?

Thanks!
Robin Goldstone, Systems Software Specialist
California State University, Chico Computing Services
robin@csuchico.edu
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 00:00:40 GMT
From:      usc!wuarchive!kuhub.cc.ukans.edu!jian@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Look for PING source code
I don't know if here is the right place to post my request. Anyway, can 
can someone in this news group tell me where I can get the PING source
code via ftp anonymous. I would appreciate any helps.

Jian Q. Li
jian@kuhub.cc.ukans.edu
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 00:01:07 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Problem retrying "connect"

	If memory serves, a failed connect(2) in 4.2 systems would leave
the socket in an unusable state. The fix is to close the socket and start
all over from socket(2). We had this problem once upon a time too...
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 01:14:17 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!mtiame!ubeaut!mwp@ucsd.edu  (Michael Paddon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP & Routing
From article <425@afsg.apple.com>, by ron@afsg.apple.com (Ron Flax):
> What is the proper way to set up routing for a SLIP link on a Class C
> network.  Suppose the network number is 192.33.20 and the SLIP link is
> between a SLIP server at 192.33.20.201 and a SLIP client at
> 192.33.20.202.  Also suppose that the server has an ethernet
> interface at address 192.33.20.4 and can talk to a gateway at
> 192.33.20.1 to get to the outside world over that interface.
> 
> What should the routes be on the SLIP server and client machines so
> that traffic from the client can pass to the ethernet side and beyond
> of the server machine?
> 
> Do I need to setup a netmask? and if so what would be
> reasonable in this case?

[This question probably shouldn't be in this newsgroup]

On client:
	route add default 192.33.20.201 1

On server:
	route add default 192.33.20.1 1

This assumes the client's only network connection is the SLIP link.
You will want the server machine to know all about local hosts (via
BIND or Hesiod preferably) and the gateway to know about whatever foreign
hosts you want to talk to.

No you don't need to setup a netmask.

					Michael

-------------------------------------------------------------------
|                     |     EasyNet:  meo78b::paddon              |
|                     |     Internet: paddon@meo78b.enet.dec.com  |
|  Michael Paddon     |     ACSnet:   mwp@ubeaut.oz.au            |
|                     |     ACSnet:   mwp@munnari.oz.au           |
|                     |     Voice:    +61 3 895 9392              |
-------------------------------------------------------------------
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Aug 90 08:22:44 MDT
From:      "Doug McCallum" <dougm@ico.isc.com>
To:        bruce!mlacus!paulb@munnari.oz.au
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TLI, NLI, DLI - Request for information
In reply to your message of 30 Aug 90 06:45:51 GMT
-------

> TLI - Transport Layer Interface.

This is part of V.3 and V.4 UNIX.  X/Open's XTI interface in XPG3 is based
on TLI.

> NLI - Network Layer Interface

There isn't a current NLI.  There is a draft of NPI (Network Provider
Interface) that is currently being updated by UNIX International (OSI
Working Group). NPI will become the network protocol interface for V.4.

> DLI - Datalink Interface

DLPI (Data Link Provider Interface) is currently undergoing revision within
the same UI working group.  There is no user level interface defined at
present.

> I believe they were defined by AT&T for Unix environments and perhaps proposed
> in industry standard forums (UI?).  However I would like to know (particularly
> for NLI and DLI):

AT&T did the original specifications.  The refinement has been picked up by
UI in the OSI Working Group.

> What is there acceptance status?

They will exist for V.4 UNIX.  TLI/TPI appears to be done.  The others are
being finalized within UI.

> Where are the specs available from?

UI or AT&T.

> What implementations are available?

TLI has been around for several years in the UNIX System V Release 3.  It
was refined and adopted by X/Open in XPG3.  UNIX V.4 also comes with TLI.
Ultrix 4.0 is supposed to have an XTI (X/Open TLI) interface in it but I
don't have that version yet.

I don't know of any NPI implementations other than possibly AT&T's OSI
implementation which I suspect uses NPI but don't have any concrete proof
of.

DLPI implementations (to earlier drafts) are in the V.4 system and are used
by the TCP/IP that is part of the V.4 source release.

> Are they applicable to non-Unix environments?

No reason they couldn't be but they do assume a STREAMS type of structure
for the provider level interface since the provider is defined in terms of
STREAMS.

TLI definitely isn't restricted to UNIX.  TLI is the user level interface.
TPI is the STREAMS level interface for implementing protocols that can be
used by TLI.  A TLI implementation doesn't need to have an exactly TPI
conformant protocol implementation under it as long as it has the same
semantics from the programmer's perspective.

Does this help?

Doug McCallum
Interactive Systems Corp.
dougm@ico.isc.com

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Aug 90 09:41:15 EST
From:      schoff@uu.psi.com (Martin L. Schoffstall)
To:        BLOOM-BEACON.MIT.EDU!eru!hagbard!sunic!mcsun!inria!ircam!mf@uu.psi.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe -> USA -> Europe...
Costs in many cases are dominated by tarriffed circuit costs which
are in decided through various government mechanisms with or without
state (or meta-state) monopolies present.  Today it would appear
that circuits to the US are in many cases cheaper than intra-European
circuits.

While some hope for a solution in 92, I have in my office, (unfortunately
I am not in my office at this moment), an ECC ruling essentially providing
for competition in Northern European countries in value added data
services, but allowing state controlled monopolies in Southern Europe
(including France) to continue to exert tight controls for some years
passed 92.

While my French is mediocre (I've been focusing on my Latin at the instigation
of Vint Cerf), I believe that I have conveyed the basics fairly.

Marty
---------

> Date: 30 Aug 90 09:14:35 GMT
> From: uupsi!BLOOM-BEACON.MIT.EDU!eru!hagbard!sunic!mcsun!inria!ircam!mf  (Michel Fingerhut)
> Organization: IRCAM, Paris (France)
> Subject: Internet routing Europe -> USA -> Europe...
> Message-Id: <1990Aug30.091435.1982@ircam.ircam.fr>
> Sender: uupsi!nic.ddn.mil!tcp-ip-relay
> To: nic.ddn.mil!tcp-ip
> 
> While trying to find whether we (in France, Europe) could reach a site
> in Germany (Europe), I got the following route from traceroute:
> 
>    1  ircam-gw (129.102.0.1)  0 ms  0 ms  0 ms
>    2  fnet-gw.inria.fr (192.44.64.26)  370 ms  550 ms  480 ms
>    3  sophia-gw.inria.fr (192.5.60.250)  540 ms  350 ms  290 ms
>    4  cisco.atlantic.fr (192.33.170.1)  1430 ms  1160 ms  490 ms
>    5  wormhole.Princeton.EDU (128.112.128.114)  680 ms  710 ms  410 ms
>    6  ford-gateway.jvnc.net (130.94.0.66)  480 ms  530 ms *
>    7  nss.jvnc.net (192.12.211.1)  910 ms  640 ms  650 ms
>    8  Pittsburgh.PA.NSS.NSF.NET (129.140.69.8)  400 ms  500 ms *
>    9  Ithaca.NY.NSS.NSF.NET (129.140.74.5)  630 ms  720 ms  760 ms
>   10  lan.cornell.site.psi.net (192.35.82.1)  790 ms  900 ms  930 ms
>   11  cornell.syr.pop.psi.net (128.145.30.1)  1100 ms  530 ms *
>   12  albpop.syr.pop.psi.net (128.145.20.2)  740 ms  760 ms  590 ms
>   13  albpop.nyc2.pop.psi.net (128.145.80.1)  780 ms  920 ms  830 ms
>   14  nyc2.nyc1.pop.psi.net (128.145.42.2)  700 ms  500 ms  580 ms
>   15  * nyc_P.lan.nyc1.pop.psi.net (128.145.213.1)  1410 ms  1090 ms
>   16  nyc1.cuny.pop.psi.net (128.145.14.1)  790 ms  590 ms  910 ms
>   17  128.145.254.5 (128.145.254.5)  920 ms  740 ms  710 ms
>   18  iracs1.ira.uka.de (192.54.104.49)  1310 ms  1140 ms  1190 ms
>   
> I.e.: Paris -> South France -> NJ -> PE -> Ithaca (upst. NY--hi, alma matter!) ->
>       Syracuse (upst. NY)   -> NYC, NY  -> ? -> Deutschland
> 
> Why this contorted route?  Is it cost-effective?

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Aug 90 12:19:15 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM Hotel Update

No sooner did the conference hotel extend its registration deadline than it
filled up.  SIGCOMM '90 has made arranges at a hotel down the street from
the conference hotel to handle the overflow.

So, if you are planning to attend SIGCOMM '90, and have not yet made a
hotel reservation, call the Penn Towers Hotel at 215-387-8333, and ask
for the SIGCOMM '90 rate.

Craig Partridge
Publicity Chair, SIGCOMM '90
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 06:45:51 GMT
From:      swrinde!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!mlacus!paulb@ucsd.edu  (Paul Bandler)
To:        tcp-ip@nic.ddn.mil
Subject:   TLI, NLI, DLI - Request for information
Can anyone please provide me with information regarding the status of the
following API's?

TLI - Transport Layer Interface.
NLI - Network Layer Interface
DLI - Datalink Interface

I believe they were defined by AT&T for Unix environments and perhaps proposed 
in industry standard forums (UI?).  However I would like to know (particularly 
for NLI and DLI):

What is there acceptance status?
Where are the specs available from?
What implementations are available?
Are they applicable to non-Unix environments?

Please email info as postings take a long time to filter down here.  I'll 
summarize if there is sufficient interest.


Thanks in anticipation,

Paul Bandler
ACUS - Australian Centre for Unisys Software
Fax: +61-3-267-4692
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 09:14:35 GMT
From:      eru!hagbard!sunic!mcsun!inria!ircam!mf@bloom-beacon.mit.edu  (Michel Fingerhut)
To:        tcp-ip@nic.ddn.mil
Subject:   Internet routing Europe -> USA -> Europe...
While trying to find whether we (in France, Europe) could reach a site
in Germany (Europe), I got the following route from traceroute:

   1  ircam-gw (129.102.0.1)  0 ms  0 ms  0 ms
   2  fnet-gw.inria.fr (192.44.64.26)  370 ms  550 ms  480 ms
   3  sophia-gw.inria.fr (192.5.60.250)  540 ms  350 ms  290 ms
   4  cisco.atlantic.fr (192.33.170.1)  1430 ms  1160 ms  490 ms
   5  wormhole.Princeton.EDU (128.112.128.114)  680 ms  710 ms  410 ms
   6  ford-gateway.jvnc.net (130.94.0.66)  480 ms  530 ms *
   7  nss.jvnc.net (192.12.211.1)  910 ms  640 ms  650 ms
   8  Pittsburgh.PA.NSS.NSF.NET (129.140.69.8)  400 ms  500 ms *
   9  Ithaca.NY.NSS.NSF.NET (129.140.74.5)  630 ms  720 ms  760 ms
  10  lan.cornell.site.psi.net (192.35.82.1)  790 ms  900 ms  930 ms
  11  cornell.syr.pop.psi.net (128.145.30.1)  1100 ms  530 ms *
  12  albpop.syr.pop.psi.net (128.145.20.2)  740 ms  760 ms  590 ms
  13  albpop.nyc2.pop.psi.net (128.145.80.1)  780 ms  920 ms  830 ms
  14  nyc2.nyc1.pop.psi.net (128.145.42.2)  700 ms  500 ms  580 ms
  15  * nyc_P.lan.nyc1.pop.psi.net (128.145.213.1)  1410 ms  1090 ms
  16  nyc1.cuny.pop.psi.net (128.145.14.1)  790 ms  590 ms  910 ms
  17  128.145.254.5 (128.145.254.5)  920 ms  740 ms  710 ms
  18  iracs1.ira.uka.de (192.54.104.49)  1310 ms  1140 ms  1190 ms
  
I.e.: Paris -> South France -> NJ -> PE -> Ithaca (upst. NY--hi, alma matter!) ->
      Syracuse (upst. NY)   -> NYC, NY  -> ? -> Deutschland

Why this contorted route?  Is it cost-effective?
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 10:12:39 GMT
From:      usc!samsung!munnari.oz.au!metro!pta!yarra!chris@ucsd.edu  (Chris Jankowski)
To:        tcp-ip@nic.ddn.mil
Subject:   Summary: TCP/IP/Ethernet Protocol Analyzer - which to buy (long)

Original question:

>I need a TCP/IP/Ethernet protocol analyzer for general troubleshooting
>work in multivendor enviroment. It must be portable as I often work at
>customer sites. It must also be good at decoding protocols. I don't
>want to spend months ploughing through rims of hex dumps.

I should have probably stressed that I am not particularly interested 
in network management, monitoring and collecting statistics.

I received about 15 responses - many thanks. It seems that nearly every
available solution is a class of its own which is an obvious sign that
the market is not mature yet.

1. Sniffer from Network General
===============================

   Shines where ease of use and high quality decodes are at premium.
   Also very good intuitive user interface and very good presentation 
   of decoded packets.
   Expensive. No traffic generation.

   (This is my choice - I need to work fast and deliver results quickly.
   Decodes and presentation are crucial. I do not need generate packets
   nor am I concerned with performance tests)

dhs@hpctdlb.hp.com - Don Schoenecker writes:
 Best feature - Ease of use. "windows" interface. 
 Limited functionallity for testing, but very good decodes.
 Decodes available for most protocols.
 New Ethernet stats package.
 Ethernet, Token Ring, Arcnet, Starlan interfaces

ccc121e@monu6.cc.monash.edu.au - Dave Schwarz writes:
 The other thing to check is how you buy it, we just bought the card and soft
 ware and put it in a t3200 we had, which saved us about $7000 for a start.

lars@spectrum.cmc.com - Lars Poulsen writes:
 If you have used a Sniffer, you'll never be happy with a lowend monitor.
 If you can't afford the Sniffer, you'll learn to live with what you can
 afford.


2. HP LANalyzer - model HP4972A
===============================
   
   A class of its own. Highest speed, great packet generator (programmable).
   Expensive. 

dhs@hpctdlb.hp.com - Don Schoenecker writes:
 Best feature - Performance is designed to be able to handle the
 worst case situations and still offer full functionallity.
 stats are the best there is. Ethernet performance ananlysis
 is complete and has many graphical displays. TCP/IP and DECnet
 performance analysis allow measurements of throughput,
 response times, lost packets, and other items for the network 
 and transport protocols. (The only analyzer with the capability :-)
 Traffic generation - 16 messages completely definable, for 
 easy stimulus response testing with programs.
 There is a "syntax directed" programming language. It uses 
 softkeys and is very straight forward. Useful for active testing
 like sending ping messages and counting or timing events.
 Good decodes - XNS, Novell, TCP/IP, NFS, DECnet, OSI
 Ethernet and Starlan interfaces

tmallory@bbn.com - Tracy Mallory writes:
The HP is the ONLY analyzer that can keep up, 100%, with anything being
transmitted up to the maximum capacity of the wire, in real-time.  It can tell
you if that the average traffic is 10,373 pps: most others top out around 3000
pps.
The HP's buffer for storing packets is average: like all(most?) of them, it
will store back-to-back packets until the buffer is filled.
The HP's transmitter and receiver are essentially independent.
The HP has support for 16 full-size, fully specified packets for transmission.  
   Most other analyzers only allow 1 packet for transmission, and many do not
   allow you to specify the full contents of the packet(I think one allows
   more packets, but not fully specifed=zero padded).
The maximum packet transmission rate is about 10k packets per second, which is
slightly lower than the Excelan product, but respectable.  It will tell you
exactly what the traffic rate is while transmitting at this rate.  The Excelan
product was very difficult to use(and I think could only send a single, not
fully specified, packet at high speed).
You can write simple programs with loops, received packet matching, counters,
timers, and sending of the predefined test packets.
The packet decoding on the HP is an extra package.  You should look at a
current version to see if it suits your needs.
The packet filtering is pretty good, though not quite as general as some of the
others(though I think it can look at ANY byte in the packet).
If your operation gets large enough, a Sniffer and an HP make a good
combination.


3. LANWatch from FTP Software.
==============================

   Software package to be used with a standard card in a standard PC.
   Very good value for money if you can live with it or you cannot afford
   the two above. The software costs some 6% of the price of a full Sniffer
   set. Maybe good choice if you do not do anything fancy and already have
   a 386 portable with an Ethernet card.
   Several checks are missing in decodes (like eg. checking of checksums)
   and presentation is nowhere near that of a Sniffer full display mode.

jbvb@ftp.com - James B. VanBokkelen writes:
Our performance depends on the speed of the PC and network interface
you use.  On a 20Mhz 386 with an Interlan NI5210 interface, I've
benchmarked LANWatch capturing bursts of 200 packets (the board can
only buffer 40 or so) at a rate of 6300 pps (at 60 bytes long, this
represents 40% of the bandwidth).  The long-term average capture rate
is normally bound by the display, which can only handle on the order
of 100-180 pps.  Filtering is done on the board wherever possible,
and I've never seen a situation on our in-house net where a LANWatch
with a filter set up missed any of the desired packets, unless the
long-term rate of packets passing the filter was more than the screen
could handle.
If you want a traffic generator, we don't have one.  If you want
menus as a user interface, you'll prefer the Sniffer, otherwise you
may prefer us.  We include all the protocol parsing source code in
the basic price.  We provide source for the off-line analysis tools.
The parsing tree and filtering we ship are pretty complete for IP,
XNS, Banyan VINES, Ethertalk and 802.2/CLNP/TP, less so for Netware
and DECNet.  We don't parse ISO session or above, or SNA.  We have an
SMB parser, but we only invoke it where we know how SMB is
encapsulated on a particular transport - if you know details of SMB
over 'x', adding it is likely to be pretty simple.


4. Excalan (Novell) LANalyzer 
=============================
   I went through a demo diskette and was not impressed with the quality
   off decodes. Also expensive. Monitoring oriented.

dhs@hpctdlb.hp.com - Don Schoenecker writes:
 Best feature - Good general purpose package. Better 
 than other PC analyzers for performance. 
 Good Decodes
 Medium Ethernet stats
 Ethernet and Starlan interfaces


5. Spider Systems, Spider monitor
=================================
   I went through a demo diskette and was not impressed with the quality
   off decodes. Also expensive. Monitoring oriented. Supports remote slave
   monitoring stations.

dhs@hpctdlb.hp.com - Don Schoenecker writes:
 Best feature - multi tasking within a PC. It does
 not tie up you PC while it does network measurements.
 Good Ethernet stats, medium decodes.
 Ethernet and Token Ring interfaces


6. HP LanProbe - Network segment monitor. 
=========================================

dhs@hpctdlb.hp.com - Don Schoenecker writes:
 Best feature - Remote monitoring of network operations. 
 Good Ethernet stats.
 Network mapping (physical location of devices) 
 Limited decodes
 (There are other devices similar to this, but I do not know details.)
 i.e. Excelan (Novell) LanTern, and one the runs on a vax.


7. ????? from Cabletron.
========================

sung@mcnc.org - Wayne Sung writes:
I just looked at a unit by Cabletron. The decode is actually better than 
Network General.  However, the software is so new (the hardware is a modified 
ethernet board that Intel already sells) that many features are missing. 
Given time, this should be a good product.


8. Public domain (PC based) software:
=====================================

sung@mcnc.org - Wayne Sung writes:
The low end jobs like MIT Netwatch are useful for spotting grossly out 
of line situations, as well as for new installations where you wonder 
if any packets are getting out at all. What you live with is that if 
you use the pc to process anything it will not do much above about
20 packets a second (the other commercial units do all the work with 
on-board processors and use the pc as a console terminal and/or long 
term storage). We keep some Netwatches running mostly to catch total 
stoppages. There is enough decode in Netwatch to see some idea of what
is happening but you could not troubleshoot any protocol related 
problems with it.


9. Workstation based solutions - those are not portable yet (:-)).
==============================

jmccabe@orville.nas.nasa.gov - Jim McCabe writes:
NetVisualiser
Silicon Graphics now has a protocol analyzer that has a very good graphical
interface and can do some network monitoring as well.  It sells for around
$25K in the U.S., and is superior to the other systems I have used (Sniffer,
Lanalyzer, HP, NNStat).  It may also be the platform for a more complete
SNMP-based network management system.  Another benefit is that you get
a workstation with it - and a fairly powerful one at that.  This system
also has remote monitoring stations which allow you to have one or more
displays that are at fixed locations (like your desk) and several monitors
at strategic points in your network (or your customers' networks).  Thus 
you dont have to move the display around, as you do with the Sniffer or 
Lanalyzer.

sung@mcnc.org - Wayne Sung writes:
...Any upper layer decoding can be done on a workstation (in fact tcpdump
on a Sun decodes a whole lot better than any of them). These workstation 
based products also give a different kind of portability, since there 
should be more of them.

Has anybody heard about this software? I only know Etherfind from Sun.

To be fair I did omit one response from gmdzi!koepke@relay.eu.net as 
their product called Ethenex does not have any protocol decoding 
capabilities.

Again many thanks to all respondents and I hope that this summary will
help others to make their choices.

      -m-------   Chris Jankowski - Senior Systems Engineer chris@yarra.oz{.au}
    ---mmm-----   Pyramid Technology Corporation Pty. Ltd.  fax  +61 3 820 0536
  -----mmmmm---   11th Floor, 14 Queens Road                tel. +61 3 820 0711
-------mmmmmmm-   Melbourne, Victoria, 3004       AUSTRALIA       (03) 820 0711

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Aug 90 17:33:03 PDT
From:      donp@xlnvax.novell.com (don provan)
To:        tcp-ip@nic.ddn.mil
Subject:   Revising IP on ARCNET
I'm revising RFC-1051, which describes how to send IP over ARCNET, and
i'd like to hear from anyone who would be interested in that topic.

In a nut shell, RFC-1051 describes a datalink protocol for ARCNET
which is incompatible with the more common datalink protocol used with
other internetwork protocols, such as Novell's IPX.  In order for IP
to be transported across ARCNET networks used by other protocols, the
encapsulation technique must be changed.
						don provan
						donp@novell.com
-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 10:59:36 GMT
From:      mcsun!ukc!reading!minster!forsyth@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sun not inventing RPC...
In <26228@bellcore.bellcore.com> Mike O'Dell writes:
>There is a REALLY good reason why XDR and Courier look similar...
>
>Duff's law:
>	Don't waste time having good ideas when you can steal better ones!
>
>	-Mike

True enough, but surely the key words are `good' and `better'!
You must seek the source of, and distil, the `better ideas'
from the model, not blindly copy all the bad ideas too.
(`Consult the genius of the place in all')
Failing that, you must at least make a good job of the theft!
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 15:08:12 GMT
From:      csusac!croft@ucdavis.ucdavis.edu  (Steve Croft)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet keymapping
I'm using NCSA Telnet 2.3 and want to remap some of the VT100 keys...
The 'readme23.tel' seems to indicate that a keymap file is a simple ascii
file with 445 lines, each line position in the file represents a key.  A
value in that line will indicate the value to produced by that key
(confused yet?).

I have two question related to this:  if you have a keyfile defined, can
you include only those keys which you want remapped or do you need all keys
defined?  Also, what if you want a key to produce a string of values (like
a VT100 function key); I assume you would just put the string of values on
the line, but the documentation is unclear about this.

The documentation is a little sparse and no sample file was included.


Thanks,
Steve
stevec@water.ca.gov
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 15:27:30 GMT
From:      retix!frank@uunet.uu.net  (Frank Guerrero)
To:        tcp-ip@nic.ddn.mil
Subject:   Use of RFCs
Simple question: What are the restrictions regarding distribution of RFCs?
In particular, our company is creating a product based on an RFC and we'd
like to include it in our manual for reference. Has any body gone through
a similar need in using RFCs, eg, in a textbook? Rather than polluting
the net, could you please e-mail your experiences and I'll summarize.

Thanks
frank@retix.com
-- 
Frank Guerrero, Retix - The Internetworking Company
		2644 30th Street, Santa Monica CA 90405 (213) 399-1611
                USENET:		{cepu,ttidca,rutgers,oliveb}!retix!frank
                Internet:	frank@retix.com
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 16:19:15 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM Hotel Update


No sooner did the conference hotel extend its registration deadline than it
filled up.  SIGCOMM '90 has made arranges at a hotel down the street from
the conference hotel to handle the overflow.

So, if you are planning to attend SIGCOMM '90, and have not yet made a
hotel reservation, call the Penn Towers Hotel at 215-387-8333, and ask
for the SIGCOMM '90 rate.

Craig Partridge
Publicity Chair, SIGCOMM '90

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 16:45:38 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!roy@ucsd.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Questions about the use of ping.
In article <227@voodoo.UUCP> howie@yo.uucp (howie) writes:
> The man page for ping warns against using ping in shell scripts.  Is it
> really that dangerous to use ping automatically, if the number of packets 
> is limited to say, 3?

	I have a shell script which is run by cron every hour.  It gives 100
pings to each of 4 hosts on our campus-wide LAN, and massages the output
before logging it for later perusal.  It lets me spot long-term trends in
packet lossage on each of two point-to-point links that connect me with the
University backbone.  I've been doing this for at least a year without any
ill effects that I've noticed.  My feeling is that the man page warning is
unwarranted.

	As an example of how useful this is, looking near the end of the
current log file, I see that something bad happened last night that I need
to look into.

Wed Aug 29 13:46:34 EDT 1990 100 100 0% 60/87/740
Wed Aug 29 14:46:33 EDT 1990 100 100 0% 60/110/920
Wed Aug 29 15:46:32 EDT 1990 100 99 1% 60/107/980
Wed Aug 29 16:46:31 EDT 1990 100 100 0% 60/87/600
Wed Aug 29 17:46:31 EDT 1990 100 100 0% 60/83/620
Wed Aug 29 18:46:32 EDT 1990 100 94 6% 60/82/520
Wed Aug 29 19:46:32 EDT 1990 100 92 8% 60/90/520
Wed Aug 29 20:46:31 EDT 1990 100 87 13% 60/180/1020
Wed Aug 29 21:46:32 EDT 1990 100 81 19% 60/108/680
Wed Aug 29 22:46:32 EDT 1990 100 88 12% 60/133/800
Wed Aug 29 23:46:32 EDT 1990 100 82 18% 60/91/400
Thu Aug 30 00:46:32 EDT 1990 100 88 12% 60/131/780
Thu Aug 30 01:46:33 EDT 1990 100 89 11% 60/85/400
--
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!"
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 16:45:55 GMT
From:      att!dptg!mtunf!fstop@ucbvax.Berkeley.EDU  (Paul Hanson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Summary: TCP/IP/Ethernet Protocol Analyzer - which to buy (long)
Have you heard of or seen the product called LANCE from an outfit named Micro
Tech? I am evaluating remote monitoring systems. This is the best one I've seen
so far. They just came out to give me a slide show. I intend to see and perhaps
buy one in the near future.

I need to centrally monitor a number of Ethernet LANs around the country.
There are many products that have the excellent statistics, topology maps,
reports etc. but which are designed to operate with a specific vendors bridges
or routers (e.g. Vitalink WAN Manager, Wellfleet's SNMP NMS, Cabletron, 
Racal Interlan's LANCentral). There are only a few that have been designed
to use their own monitoring probe. Micro Tech is the only one that I know of
that has announced product. They just started shipping their product,
LANCE, in June.

the LANCE network management station software wants to run on a high res,
color graphics workstation with a multitasking operating system (e.g. SUN
SPARCstation 1+). You can contact the company directly. In Anaheim, CA,
their number is 800-999-9MTI or 714-970-0300.

Paul Hanson
AT&T Bell Labs
West Long Branch, NJ
(201) 870-7559
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 16:55:46 GMT
From:      att!dptg!mtunf!fstop@ucbvax.Berkeley.EDU  (Paul Hanson)
To:        tcp-ip@nic.ddn.mil
Subject:   Need SLIP-to-Ethernet device

I am looking for names and manufacturers of a device that will do the
following function for me. I think this fucntion may be done by a terminal
server, but I look at it as a router.

I have several remote hosts that can talk SLIP. I want to bring those SLIP
connections into one place, via RS-232 or equivalent, and be able to
converse with a device which does not support multiple SLIP interfaces, but
which does support TCP/IP via an Ethernet interface. So I envision a device
with SLIP interface ports on one side and Ethernet on the other. It should
be able to bridge/route (?) between the SLIP devices and Ethernet device.

Please send replies to me directly.  fstop@mtunf.att.com

Thanks.

Paul Hanson
AT&T Bell Labs
West Long Branch, NJ
(201) 870-7559
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 17:47:06 GMT
From:      kramden.acf.nyu.edu!brnstnd@nyu.edu  (Dan Bernstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: auth as a replacement for rpc
In article <1990Aug29.151341.3999@eagle.lerc.nasa.gov> xxbja@csduts1.lerc.nasa.gov (Betty Jo Armstead) writes:
>  A few days back someone mentioned auth which seemed to be a replacement
>  for rpc.  I am interested in finding out more information about
>  auth.

(I couldn't get mail through to you.)

It isn't a replacement for RPC. It's an entirely different philosophy.
auth is meant for client-server applications; RPC is meant for remote
procedure call applications. The acid test for RPC is whether you know
beforehand what the code on the other end is doing. If you don't, you
should stick to a pure client-server model.

auth was published in comp.sources.unix volume 22. It uses RFC 931 to
identify the user on the remote end, though of course you can run it
without this feature. A companion package, authutil, is in the same
volume; it illustrates various uses of auth. Both packages should work
on any BSD variant.

---Dan
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 18:10:10 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!mips!ultra!ted@ucsd.edu  (Ted Schroeder)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Problem retrying "connect"
In <1990Aug29.212123.12889@fs-1.iastate.edu> john@iastate.edu (Hascall John Paul) writes:

>Given the following code:

>	[... socket(), getservbyname(), sin <- values ...]

>        while (connect(s, &sin, sizeof(sin)) < 0) {
>		perror("connect");
>		if (++retry > RETRY) exit(1);
>		sleep(2);
>	}

>If the server (to which I am trying to connect) is not there, I get:

>	connect: Connection refused             <-- expected
>	connect: Invalid argument		<-- WHY??
>	    :
>	    :
>	connect: Invalid argument

>What am i forgetting here?

My manual page (SunOS 4.0.3c) says you get EINVAL when "namelen is not the size
of a valid address for the specified address family".  I'd guess
that the connect mucked up the sin somehow.

      Ted Schroeder                   ted@Ultra.com
      Ultra Network Technologies      ...!ames!ultra!ted
      101 Daggett Drive           
      San Jose, CA 95134          
      408-922-0100

Disclaimer:  I don't even believe what I say, why should my company?
-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 18:13:30 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!uc!noc!ns!logajan@ucsd.edu  (John Logajan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: how do I get RFC's?
robin@csuchico.edu (Robin Goldstone) writes:
>I though that RFC's were available from sri-nic.arpa (nic.ddn.mil).
>can't figure out how to manipulate my way through the directory structure...

From the "main" directory (the one you end up in at FTP startup) I think
you merely    cd RFC:    <---note that the colon is *mandatory*

The RFC's will be under that directory as text (RFCXXXX.TXT) files.

-- 
- John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428
- logajan@ns.network.com, 612-424-4888, Fax 612-424-2853
-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 18:14:07 GMT
From:      agate!garnet.berkeley.edu!cliff@ucbvax.Berkeley.EDU  (Cliff Frost)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Questions about the use of ping.

In article <227@voodoo.UUCP>, howie@yo.uucp (howie) writes:
|> 
|>    Is there an easy way to determine the transfer time of data, other 
|>    than setting up a connection with FTP, and moving some test data?

If you want very simple memory to memory tests, you can send data to
the TCP (or UDP) discard port.  Tom Ferrin's "netout" does this for
TCP, it is available for anonymous ftp from jade.berkeley.edu (128.32.136.9).

|> 2) The man page for ping warns against using ping in shell scripts.  Is it

Calculate how much of your user's bandwidth you'll be using.  A few pings
on an ethernet are obviously trivial.

|> 3) Is there an alternative to the standard BSD ping that we should consider
|>    using?

Ping is more of a network management tool than a throughput tool, although
it is useful sometimes to give an idea of latency.  For network management
you want to use SNMP as much as possible.  There is an SNMP mailing list. 
Mail to snmp-request@nisc.nyser.net to join it.

	Cliff Frost                   (415) 642-5360
	Central Computing Services    <cliff@berkeley.edu>
	University of California      CLIFF AT UCBCMSA
	Berkeley, CA 94720
-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 18:47:48 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
In article <9008291448.AA14069@ftp.com> jbvb@ftp.com writes:
>    The way to do i/o on Dennis's streams was with "read" and "write".
>    Network i/o, in general, looked *exactly* like local device i/o.  This
>    is the way it should be...
>
>I would say rather that using read/write on network connections is
>the way most people would *like* it to be.  The reality is that on
>most systems the local filesystem is a pretty tame beast compared to
>a network connection.  Unless the OS/language combination's
>read/write was designed with network connections in mind (which means
>boolean flag arguments and wide variations in behaviour depending on
>them), use of read/write is likely to result in a cantankerous and
>unreliable network application...

Only if you have a cantankerous and unreliable network. :-)  True, the
network interface is more complex than most device interfaces (although
whether it is more complex than the tty interface, in particular, is a
debatable point!)... but most applications don't care.  They just want
to open a connection to service X on machine Y and reliably send bits
back and forth.  The complexities have to be present for the occasional 
sophisticated customer, but the simple customer shouldn't have to worry
about them.  The Unix tty interface is quite complex, but most programs
can ignore most of it -- if they want to print an error message, they
just say "fprintf(stderr, ..." and it works.  That's the way the network
interface should be too:  some simple way to open a connection (I find
it impossible to comprehend why 4BSD doesn't have an open-connection-to-
service-X-on-machine-Y library function, given how stereotyped and how
messy this job is), read/write for i/o, close for shutdown (and ioctl
for option setting etc. for those who care).  That's all most customers
want.

The networking facilities in Eighth/Ninth/Tenth Edition Unix within
Bell Labs are existence proofs that this approach can and does work.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 19:00:34 GMT
From:      unmvax!ariel.unm.edu!hydra.unm.edu!einhorn@ucbvax.Berkeley.EDU  (E Drew Einhorn ADV.SCI.Inc)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP down for 30 sec once every 180 sec!!
My slip connection goes down for 30 sec once every 180 sec.  I have
tried the connection at 9600 and 19200, the results are identical.
Tests are done by doing a ping -sv from each end of the link to the
host at the opposite end of the link.  The machines are connected by a
null modem cable.

One machine is a Sparcstation 1.  The other is a Mac IIci.  The Mac is
running A/UX 2.0.  I am using the slip executables provided by Apple.
The Sun is running SunOS 4.0.3c.  The slip is the version by Rayan
Zachariassen of the University of Toronto.

How can I determine which machine is causing the problem?  I hope it's
the Sun, cause I have the source and can probably fix it once I
diagnose the problem.  If it's on the Mac end I'll may have to wait for
Apple to get around to fixing it.

--
 einhorn@hydra.unm.edu
-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 19:38:39 GMT
From:      sun-barr!newstop!grapevine!panarthea!koreth@apple.com  (Steven Grimm)
To:        tcp-ip@nic.ddn.mil
Subject:   Easy-to-use socket library (was Re: Sockets vs streams. An attempt to answer the original question)
henry@zoo.toronto.edu (Henry Spencer) writes:
>(I find
>it impossible to comprehend why 4BSD doesn't have an open-connection-to-
>service-X-on-machine-Y library function, given how stereotyped and how
>messy this job is)

I wrote just such a library a few years ago; lots of people have found it
very useful.  Here it is again; everyone should feel free to pass it on
and use it in whatever they like.  There is no separate man page, but there
are comments at the start of each function, which should be adequate.

---
"                                                  !" - Marcel Marceau
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
koreth@ebay.sun.com	...!sun!ebay!koreth

---
/*
** SOCKET.C
**
** Written by Steven Grimm (koreth@ebay.sun.com) on 11-26-87
** Please distribute widely, but leave my name here.
**
** Various black-box routines for socket manipulation, so you don't have to
** remember all the structure elements.
*/

#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <stdio.h>
#include <ctype.h>

#ifndef FD_SET		/* for 4.2BSD */
#define FD_SETSIZE      (sizeof(fd_set) * 8)
#define FD_SET(n, p)    (((fd_set *) (p))->fds_bits[0] |= (1 << ((n) % 32)))
#define FD_CLR(n, p)    (((fd_set *) (p))->fds_bits[0] &= ~(1 << ((n) % 32)))
#define FD_ISSET(n, p)  (((fd_set *) (p))->fds_bits[0] & (1 << ((n) % 32)))
#define FD_ZERO(p)      bzero((char *)(p), sizeof(*(p)))
#endif

extern int errno;

/*
** serversock()
**
** Creates an internet socket, binds it to an address, and prepares it for
** subsequent accept() calls by calling listen().
**
** Input: port number desired, or 0 for a random one
** Output: file descriptor of socket, or a negative error
*/
int serversock(port)
int port;
{
	int	sock, x;
	struct	sockaddr_in server;

	sock = socket(AF_INET, SOCK_STREAM, 0);
	if (sock < 0)
		return -errno;

	bzero(&server, sizeof(server));
	server.sin_family = AF_INET;
	server.sin_addr.s_addr = INADDR_ANY;
	server.sin_port = htons(port);

	x = bind(sock, &server, sizeof(server));
	if (x < 0)
	{
		close(sock);
		return -errno;
	}

	listen(sock, 5);

	return sock;
}

/*
** portnum()
**
** Returns the internet port number for a socket.
**
** Input: file descriptor of socket
** Output: inet port number
*/
int portnum(fd)
int fd;
{
	int	length, err;
	struct	sockaddr_in address;

	length = sizeof(address);
	err = getsockname(fd, &address, &length);
	if (err < 0)
		return -errno;

	return ntohs(address.sin_port);
}

/*
** clientsock()
**
** Returns a connected client socket.
**
** Input: host name and port number to connect to
** Output: file descriptor of CONNECTED socket, or a negative error (-9999
**         if the hostname was bad).
*/
int clientsock(host, port)
char *host;
int port;
{
	int	sock;
	struct	sockaddr_in server;
	struct	hostent *hp, *gethostbyname();

	bzero(&server, sizeof(server));
	server.sin_family = AF_INET;
	server.sin_port = htons(port);

	if (isdigit(host[0]))
		server.sin_addr.s_addr = inet_addr(host);
	else
	{
		hp = gethostbyname(host);
		if (hp == NULL)
			return -9999;
		bcopy(hp->h_addr, &server.sin_addr, hp->h_length);
	}

	sock = socket(AF_INET, SOCK_STREAM, 0);
	if (sock < 0)
		return -errno;

	if (connect(sock, &server, sizeof(server)) < 0)
	{
		close(sock);
		return -errno;
	}

	return sock;
}

/*
** readable()
**
** Poll a socket for pending input.  Returns immediately.  This is a front-end
** to waitread() below.
**
** Input: file descriptor to poll
** Output: 1 if data is available for reading
*/
readable(fd)
int fd;
{
	return(waitread(fd, 0));
}

/*
** waitread()
**
** Wait for data on a file descriptor for a little while.
**
** Input: file descriptor to watch
**	  how long to wait, in seconds, before returning
** Output: 1 if data was available
**	   0 if the timer expired or a signal occurred.
*/
waitread(fd, time)
int fd, time;
{
	fd_set readbits, other;
	struct timeval timer;
	int ret;

	timerclear(&timer);
	timer.tv_sec = time;
	FD_ZERO(&readbits);
	FD_ZERO(&other);
	FD_SET(fd, &readbits);

	ret = select(fd+1, &readbits, &other, &other, &timer);
	if (FD_ISSET(fd, &readbits))
		return 1;
	return 0;
}
-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 90 23:57:56 GMT
From:      groucho!davis@handies.ucar.edu  (Glenn P. Davis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future?
In <9008281330.AA00189@atlantic.nprdc.navy.mil> stanonik@NPRDC.NAVY.MIL (Ron Stanonik) writes:

>RPC seems suitable for networking your application if your application
>can be implemented using function call/return.  It doesn't seem suitable
>for networking your application if your application simply blasts a variable
>(and perhaps voluble) amount of text to the user's screen (or into a file).
>The non-network implementation of such usually consists of write/puts/printf
>to stdout, but RPC doesn't seem to contain a stream type, such that you keep
>reading from it until EOF.

>Ron Stanonik
>stanonik@nprdc.navy.mil

Sun RPC includes a provision for 'batched' rpc's. The procedure call
doesn't wait for a return.
We have an set of applications based on Sun RPC which use this to "blast 
variable and voluble amounts of data at a server.

Glenn P. Davis
UCAR / Unidata
PO Box 3000                   1685 38th St.
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643
-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 01:24:17 GMT
From:      usc!samsung!munnari.oz.au!metro!solar.card.inpu.oz.au!rodney@ucsd.edu  (Rodney Campbell)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for SUN SPARC
Does anyone know of or have the latest version of slip for Sun Sparc
Machines. I have a copy of Beta Slip for SunOS 4.0 from 
Rayan Zachariassen <rayan@ai.toronto.edu>
and it works but I don't know how to set the line speed that this will run
at so if anyone has a fix for the SLIP I am running or a newer version of
SLIP that they can EMail me I would be most appreciative.
	       Thanks in advance..	    	Rodney....
______________________________________________________________________

Rodney Campbell			MHSnet: rodney@solar.card.inpu.oz.au
Telecom Australia		Snail:  8th Floor, 91 York Street
Corporate Customer Division		Sydney 2000.
Integrated Network Products Unit	PO Box A226,Sydney South 2000.
Customer Applications Research 	Phone:  +61 02 364 3346
	& Development		Fax:	+61 02 262 3813
______________________________________________________________________
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 09:51:52 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!uc!noc!ns!logajan@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re: how do I get RFC's?
The last few times I have ftp-ed to NIC.DDN.MIL, cd has returned an error
message "xcd command unknown" or something of that sort. Despite this, I
have been in the requested directory. So, if you get this error message,
check around before getting frustrated.
-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 10:00:47 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu  (Henry Spencer)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
    ....  The complexities have to be present for the occasional sophisticated
    customer, but the simple customer shouldn't have to worry about them.  The
    Unix tty interface is quite complex, but most programs can ignore most
    of it -- if they want to print an error message, they just say
    "fprintf(stderr, ..." and it works.  That's the way the network interface
    should be too:  some simple way to open a connection (I find it impossible
    to comprehend why 4BSD doesn't have an open-connection-to-service-X-on-
    machine-Y library function, given how stereotyped and how messy this job
    is), read/write for i/o, close for shutdown (and ioctl for option setting
    etc. for those who care).  That's all most customers want.

I see where our viewpoints differ: I am selling applications to end-users,
and I intend to support them.  Most of the end-users who use our Development
Kit for one-off or in-house applications are probably quite satisfied with
open/read/write/close.  However, I am careful to advise any OEMs who develop
for resale to pay close attention to the flags and error codes...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 08:57:39 PDT
From:      postel@venera.isi.edu
To:        drw@BOURBAKI.MIT.EDU, math.mit.edu!drw@bloom-beacon.mit.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Unknown TCP/IP options

Dale Worley:

The statement has been made that the only options that will ever exist
with out a length field are the end-of-options (0) and no-operation (1)
options.  All other options now and defined in the future will have a
length field as their second byte.

	"					so we should establish the
	convention that the '2' bit (second-lowest) is 0 if the option has no
	argument and 1 if it does.

	Is this a good idea?"

NO.  This is a bad idea.  Just treat special case option codes 0 and 1. Look
for the length field for all other option codes.

--jon.
-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 08:03:49 MDT
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        mcsun!ukc!reading!minster!forsyth@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Sun not inventing RPC...
>>Duff's law:
>>	Don't waste time having good ideas when you can steal better ones!

> True enough, but surely the key words are `good' and `better'!


And who was it that said:

	 "'Better' is the enemy of 'good'."
	 
Phil
	
-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 08:48:10 -0400
From:      tmallory@BBN.COM
To:        "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
Cc:        tcp-ip@nic.ddn.mil, tmallory@BBN.COM
Subject:   Re: Hosts whose IP numbers end in 0........


> However, the network wide broadcast addresses will always be broadcasts
> and grounds for potential filtering.  Something like 128.102.255.255 will
> always be a broadcast no matter what subnet scheme is in use, unless
> you are doing something really weird(!)...  Packets to this address should
> NEVER be forwarded...

If YOUR router(no interface on 128.89.0.0) ALWAYS filters 128.89.255.255
before MY router sees it, I will have to look elsewhere for transit service.
ALL bits in the host part of the address must be considered to have only local
significance.  The fact that 128.89.255.255 must be recognized as the
broadcast address by all hosts(and routers) on my network allows for
interoperability on my network.  It's nobody else's business.  Packets to this
address MUST never be forwarded when received from an interface on this
network, and MAY never be forwarded to this network if I choose to have them
filtered.

After all that, if this flies in the face of router requirements specified
beyond rfc1009, my apologies.  It doesn't seem right that all one's in the
host field(or all 0's for that matter), is grounds for always filterring
packets to someone else's network.  I probably can accept filtering packets
whose source address is a broadcast address, but I'd prefer that to also be a
local issue.

(Hardware broadcast addresses, on the other hand, need the absolute filtering
we've been talking about.)

Tracy
-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 09:17:29 PDT
From:      braden@venera.isi.edu
To:        math.mit.edu!drw@bloom-beacon.mit.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Unknown TCP/IP options
	From tcp-ip-RELAY@NIC.DDN.MIL Fri Aug 31 08:43:17 1990
	Date: 31 Aug 90 05:23:28 GMT
	From: math.mit.edu!drw@bloom-beacon.mit.edu  (Dale R. Worley)
	Organization: MIT Dept. of Mathematics, Cambridge, MA, USA
	Subject: Unknown TCP/IP options
	Sender: tcp-ip-relay@nic.ddn.mil
	To: tcp-ip@nic.ddn.mil

	Is there any standard for how a TCP/IP implementation ignores options
	that it does not understand and/or implement?

Dale,

Yes.  Please see sections 3.2.1.8, 4.1.3.2, and 4.2.2.5 of RFC-1122 for option
processing in IP, UDP, and TCP, respectively.

Bob Braden


-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 09:41:21 PDT
From:      braden@venera.isi.edu
To:        ietf-hosts@nnsc.nsf.net, ietf-rreq@jessica.stanford.edu, postel@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Hosts whose IP numbers end in 0...
	From @jessica.stanford.edu:postel@venera.isi.edu Wed Aug 29 18:16:23 1990
	Date: Wed, 29 Aug 90 18:12:35 PDT
	From: postel@ISI.EDU
	To: ietf-hosts@nnsc.nsf.net, ietf-rreq@jessica.stanford.edu,
	        tcp-ip@nic.ddn.mil
	Subject: Hosts whose IP numbers end in 0...
	Cc: postel@ISI.EDU

	Hi.

	I believe the following analysis by David L Stevens is correct.  Some
	discussion like this should be added to all requirements documents and
	other descriptions of address filtering and/or broadcast addresses.

	--jon.

	~~~~~~~~~         ----- Begin Included Message -----        ~~~~~~~~~~
	Date: 29 Aug 90 16:31:45 GMT
	From: usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu  (David L Stevens)
	Subject: Re: Hosts whose IP numbers end in 0........
	Sender: tcp-ip-relay@nic.ddn.mil
	To: tcp-ip@nic.ddn.mil


		A point of clarification, since several people have sent me e-mail
	on the topic...

		When I say "shouldn't" regarding filtering, I mean in the RFC-speak
	sense of "it's a bad idea." I don't mean it's contrary to any RFC, so you
	don't need to point out to me that some say it's fine for gateways to filter
	broadcast packets.
		Beyond that, there is the fact that it is impossible to do it right
	in the case we were talking about, and THAT is just plain wrong. A gateway
	that isn't directly attached or administered by the same people as an
	arbitrary IP address CANNOT answer the question "is this a broadcast?" so
	it doesn't matter whether an RFC says you can or not; in practice, you can't.

Jon and David,

Sorry, I think there is a confusion here.  Filtering out directed
broadcasts is neither a "bad idea" nor "impossible"!!  This means: those
broadcasts that the given gateway can legally and possibly detect.  Of
course, it does NOT mean breaking the rules about invisibility of
subnets outside a subnetted network, and it does NOT mean making
illegal assumptions about byte boundaries within subfields of the IP
address.

Jon thinks David and I are having an agreement, but I am unclear
about that.

Bob Braden

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 09:49:40 PDT
From:      jkrey@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Cc:        jkrey@venera.isi.edu
Subject:   Obtaining RFCs
Excerpt from RFC 1177 (FYI 4), "FYI on Questions and Answers -
Answers to Commonly asked "New Internet User" Questions":

   How do I obtain RFCs?

      RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
      RFC:RFCnnnn.TXT or RFC:RFCnnnn.PS (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" (or "Subject:
      RFC nnnn.PS" for PostScript RFCs).

      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 must be "SEND RFCnnnn.TXT-1", where nnnn
      is replaced by the RFC number.

      Requests for special distribution should be addressed to either
      the author of the RFC in question, or to NIC@NIC.DDN.MIL.  Unless
      specifically noted otherwise on the RFC itself, all RFCs are for
      unlimited distribution.



Joyce K. Reynolds
USC/Information Sciences Institute

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 10:15:04 pdt
From:      Walter Underwood <wunder@hp-ses.sde.hp.com>
To:        tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip
Subject:   Re: Are sockets the wave of the future?
>The non-network implementation of such usually consists of write/puts/printf
>to stdout, but RPC doesn't seem to contain a stream type, such that you keep
>reading from it until EOF.

NCS 2.0 has exactly that feature -- indeterminate-length
streams of typed data.  OSF cites that as one of the reasons
for adopting NCS 2.0 in the the OSF Distributed Computing
Environment.  See the OSF DCE Rationale.

wunder

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 9:24:55 CDT
From:      darrel beach <beach@ddnuvax.af.mil>
To:        tcp-ip@nic.ddn.mil
Cc:        beach@ddnuvax.af.mil, afc2s-saic@gunter-adam.af.mil
Subject:   Verdix security system
A simple question...
Has anyone heard of a system of products from a company called verdix
that will make a LAN a B1 system.  B1 meaning security acreditation to
have multi level things connected.  They make a Q-bus card and some
others, or so I've heard.  I'm just trying to pin down who these folks
are and what they really have.  The journals don't have a thing in the
way of ads or articles.

Darrel Beach
-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 05:23:28 GMT
From:      math.mit.edu!drw@bloom-beacon.mit.edu  (Dale R. Worley)
To:        tcp-ip@nic.ddn.mil
Subject:   Unknown TCP/IP options
Is there any standard for how a TCP/IP implementation ignores options
that it does not understand and/or implement?

Of course, that doesn't happen now, because there are only three
options, and all implementations are required to implement them, but
this might not always be true.  What I'm proposing is that an
implementation can ignore an unimplemnted option, which requires that
there be a convention to tell whether an option has an argument or
not.  If I remember correctly, among the current options, 0 and 1
don't have arguments, and 2 does, so we should establish the
convention that the '2' bit (second-lowest) is 0 if the option has no
argument and 1 if it does.

Is this a good idea?

Is it worth worrying about?

(Please reply by e-mail, as I don't read this newsgroup regularly.)

Dale Worley
drw@math.mit.edu
-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 10:31:41 EDT
From:      "Phillip G. Gross" <pgross@NRI.Reston.VA.US>
To:        Arnold Nipper --- XLINK <nipper@ira.uka.de>, "Phillip G. Gross" <pgross@NRI.Reston.VA.US>
Cc:        ripe@mcsun.eu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  Long lines...
Arnold,

Your 6 hop path is certainly more direct, but notice that it takes almost
5 seconds, while the more convoluted 18 hop path via Princeton and Cornell 
takes only little more than a second.  With that type of difference, I have 
a better understanding for routes via NSFnet for intra-European traffic.

Phill

>From:     Arnold Nipper --- XLINK <nipper%ira.uka.de@relay.cs.net>
>
>traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets
> 1  iracs1.ira.uka.de (129.13.1.1)  20 ms  0 ms  0 ms
> 2  ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1)  1020 ms  840 ms  1080 ms
> 3  Amsterdam.NL.EU.NET (134.222.1.1)  4120 ms *  3800 ms
> 4  Paris.FR.EU.NET (134.222.2.2)  4340 ms  4900 ms  3760 ms
> 5  fnet-gw.inria.fr (128.93.36.128)  3880 ms  3740 ms *
> 6  192.44.64.61 (192.44.64.61)  3980 ms  4960 ms *


  >From: Michel Fingerhut 
  >Organization: IRCAM, Paris (France)
  >
  >1  ircam-gw (129.102.0.1)  0 ms  0 ms  0 ms
  >.
  >.
  >.
  >18  iracs1.ira.uka.de (192.54.104.49)  1310 ms  1140 ms  1190 ms
-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 07:26:56 GMT
From:      mcsun!ukc!strath-cs!cs.glasgow.ac.uk!tommyk@uunet.uu.net  (Tommy Kelly)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <1990Aug30.091435.1982@ircam.ircam.fr mf@ircam.ircam.fr (Michel Fingerhut) writes:
}While trying to find whether we (in France, Europe) could reach a site
}in Germany (Europe), I got the following route from traceroute:...

Does this imply that you CAN actually telnet out to U.S. sites?

Is the UK the only place which is isolated from the rest of the world?

tk
-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 08:34:13 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI, NLI, DLI - Request for information



do any of TLI, NLI or DLI contain something with more functionality
than sockets - like a standard management interface, or a standard
packet filter or traceer interface - and i dont mean ioctl and nit
like vaguaries

if not, i suggest its just more noiseware to make unix less useful,
designed by manufacturers running scared from real open systems and
shareware...

jon.

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 09:51:13 GMT
From:      bigtex!texsun!netdev!alex@astro.as.utexas.edu  (Alex Huppenthal)
To:        tcp-ip@nic.ddn.mil
Subject:   Comparison of RPC and ROSE ?


  We are investigating networking alternatives. Remote Operations Services
  Elements ( ROSE - ISO ) , and Remote Procedure Call have been identified
  as two somewhat analogous capabilties, for ISO stacks and ARPA stacks,
  respectivly.

  I'm solicting information on the comparision of the two approaches to
  distributing applications over a network of non-homogenous computers.

  Concerns are:

	performance
	flexibility
	functionality
	programming tools ( rpcgen - like tools for ISO, or others )
	
  If you have an opinion that you'd like to share please respond. If you 
  have a pointer to information, articles or papers comparing these, I'd
  be very happy to receive them.

  Thank you,

  
     Alex            Internet:  alex@comsys.COM
     Huppenthal          UUCP:  {cs.utexas.edu!texsun}!netdev!alex 
     Communication Systems Research  6045 Buffridge Tr, Dallas, TX 75252  
-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 10:49:51 GMT
From:      eru!hagbard!sunic!mcsun!tuvie!iiasa!wnp@bloom-beacon.mit.edu  (wolf paul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe -> USA -> Europe...
In article <1990Aug30.091435.1982@ircam.ircam.fr> mf@ircam.ircam.fr (Michel Fingerhut) writes:
)While trying to find whether we (in France, Europe) could reach a site
)in Germany (Europe), I got the following route from traceroute:
)
)I.e.: Paris -> South France -> NJ -> PE -> Ithaca (upst. NY)->
)      Syracuse (upst. NY)   -> NYC, NY  -> ? -> Deutschland
)
>Why this contorted route?  Is it cost-effective?

Well, I guess it has to do with the cost of leased lines used for
internet connections. Since the bulk of internet activity takes place
in Europe, most European countries have more direct links to 
sites in the US than they have to sites in other European countries.

Since these leased lines are not really charged by volume but rather
have a fixed monthly charge regardless of traffic, it probably does not
affect the cost a whole lot.

The Austrian branch of EUnet will shortly be connected to the Internet
by a leased line from tuvie to mcsun; our organization may also get a
leased line to tuvie, thus any internet connections from here to
France will run via Holland. Mcsun is connected to the U.S.; unless
there is a direct connection from mcsun to some French site you talk
to directly, a connection from here to you would also run via the
U.S.
-- 
Wolf N. Paul, IIASA, A - 2361 Laxenburg, Austria, Europe
PHONE: +43-2236-71521-465     FAX: +43-2236-71313      UUCP: uunet!iiasa.at!wnp
INTERNET: wnp%iiasa.at@uunet.uu.net      BITNET: tuvie!iiasa!wnp@awiuni01.BITNET
       * * * * Kurt Waldheim for President (of Mars, of course!) * * * *
-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 09:34:13 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TLI, NLI, DLI - Request for information


do any of TLI, NLI or DLI contain something with more functionality
than sockets - like a standard management interface, or a standard
packet filter or traceer interface - and i dont mean ioctl and nit
like vaguaries

if not, i suggest its just more noiseware to make unix less useful,
designed by manufacturers running scared from real open systems and
shareware...

jon.
-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 12:48:10 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Hosts whose IP numbers end in 0........



> However, the network wide broadcast addresses will always be broadcasts
> and grounds for potential filtering.  Something like 128.102.255.255 will
> always be a broadcast no matter what subnet scheme is in use, unless
> you are doing something really weird(!)...  Packets to this address should
> NEVER be forwarded...

If YOUR router(no interface on 128.89.0.0) ALWAYS filters 128.89.255.255
before MY router sees it, I will have to look elsewhere for transit service.
ALL bits in the host part of the address must be considered to have only local
significance.  The fact that 128.89.255.255 must be recognized as the
broadcast address by all hosts(and routers) on my network allows for
interoperability on my network.  It's nobody else's business.  Packets to this
address MUST never be forwarded when received from an interface on this
network, and MAY never be forwarded to this network if I choose to have them
filtered.

After all that, if this flies in the face of router requirements specified
beyond rfc1009, my apologies.  It doesn't seem right that all one's in the
host field(or all 0's for that matter), is grounds for always filterring
packets to someone else's network.  I probably can accept filtering packets
whose source address is a broadcast address, but I'd prefer that to also be a
local issue.

(Hardware broadcast addresses, on the other hand, need the absolute filtering
we've been talking about.)

Tracy

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 19:53:33 -0400 (EDT)
From:      "Vincent M. Del Vecchio" <vd09+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Telnettable programs
I am trying to write a network daemon-type program which will not be called 
from inetd, but which other users can telnet to.  However, when I try to 
telnet, I get a connection refused.  I can write another program which will 
connect fine, but telnet seems to be looking for something else.  I looked at 
the code for inetd (which handles these things for most daemons) and it was a 
bit of a mess, but the only thing that I saw was that I might not have been 
setting socket options that I needed to.  Does anyone have any ideas?  The 
relevant portion of the code follows:


#include <string.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <errno.h> 

main()
  {  
    struct sockaddr_in sockad, oend;
    int sock, accepteds, size = sizeof (sockad), 
        osize = sizeof (oend), buf[100];

    if ((sock = socket(AF_INET, SOCK_STREAM, 0, 0)) == -1)
      perror ("creating socket"),
      exit(1);
    sockad.sin_family = AF_INET;
    sockad.sin_port = 3007;  /* The port we'll try to telnet to */
    sockad.sin_addr.S_un.S_addr = INADDR_ANY;
    if (bind (sock, &sockad, sizeof (sockad)) == -1)
      perror ("binding socket"),
      exit(1);
    if (getsockname (sock, &sockad, &size) == -1)
      perror ("Bad address for socket"),
      exit(1);
    printf ("%d\\n",sockad.sin_port);
    if (listen (sock,5) == -1)
      perror ("listening on socket"),
      exit(1);
    printf ("Waiting\\n");
    do
      {
        errno = 0;
        osize = sizeof (oend);
        accepteds = accept(sock, &oend, &osize);
      }
    while (accepteds == -1 && errno == EINTR);
    if (accepteds == -1)
      perror ("accepting on socket"),
      exit(1);
    printf ("Accepted");
    process(accepteds);
  }

It's not very well (or at all) commented, but it's fairly short.  It prints 
out the port number 3007, and "Waiting" and then sits... when I try to telnet, 
it says "Connection refused," and the program doesn't do anything; just keeps 
waiting.  I would very much appreciate any ideas.

TIA, and, as I don't read this board normally, please respond via email.
 If there is interest (please mail me also) I will summarize.

+----------------------------------------------------------------------------+
| Vincent Del Vecchio     \ vd09+@andrew.cmu.edu                             |
| Box 4872                 \ Reserved for another email address.             |
| 5125 Margaret Morrison St.\ Reserved for a quote                           |
| Pittsburgh, PA  15213      \ Reserved for a standard disclaimer            |
+----------------------------------------------------------------------------+
-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 14:06:53 MET DST
From:      Arnold Nipper --- XLINK <nipper%ira.uka.de@RELAY.CS.NET>
To:        "Phillip G. Gross" <pgross@NRI.RESTON.VA.US>
Cc:        ripe@MCSUN.EU.NET, tcp-ip@NIC.DDN.MIL
Subject:   Re:  Long lines...

>Hi,
>
>Many of you may have seen the following on the TCP-IP mailing list.  Anyone
>have any suggestions or comments?
>
>Thanks,
>Phill
>------- Forwarded Message
>
>Date: 30 Aug 90 09:14:35 GMT
>From: Michel Fingerhut <eru!hagbard!sunic!mcsun!inria!ircam!mf@bloom-beacon.mit.edu>
>Organization: IRCAM, Paris (France)
>Subject: Internet routing Europe -> USA -> Europe...
>To: tcp-ip@nic.ddn.mil
>
>While trying to find whether we (in France, Europe) could reach a site
>in Germany (Europe), I got the following route from traceroute:
>
   >1  ircam-gw (129.102.0.1)  0 ms  0 ms  0 ms
   >2  fnet-gw.inria.fr (192.44.64.26)  370 ms  550 ms  480 ms
   >3  sophia-gw.inria.fr (192.5.60.250)  540 ms  350 ms  290 ms
   >4  cisco.atlantic.fr (192.33.170.1)  1430 ms  1160 ms  490 ms
   >5  wormhole.Princeton.EDU (128.112.128.114)  680 ms  710 ms  410 ms
   >6  ford-gateway.jvnc.net (130.94.0.66)  480 ms  530 ms *
   >7  nss.jvnc.net (192.12.211.1)  910 ms  640 ms  650 ms
   >8  Pittsburgh.PA.NSS.NSF.NET (129.140.69.8)  400 ms  500 ms *
   >9  Ithaca.NY.NSS.NSF.NET (129.140.74.5)  630 ms  720 ms  760 ms
  >10  lan.cornell.site.psi.net (192.35.82.1)  790 ms  900 ms  930 ms
  >11  cornell.syr.pop.psi.net (128.145.30.1)  1100 ms  530 ms *
  >12  albpop.syr.pop.psi.net (128.145.20.2)  740 ms  760 ms  590 ms
  >13  albpop.nyc2.pop.psi.net (128.145.80.1)  780 ms  920 ms  830 ms
  >14  nyc2.nyc1.pop.psi.net (128.145.42.2)  700 ms  500 ms  580 ms
  >15  * nyc_P.lan.nyc1.pop.psi.net (128.145.213.1)  1410 ms  1090 ms
  >16  nyc1.cuny.pop.psi.net (128.145.14.1)  790 ms  590 ms  910 ms
  >17  128.145.254.5 (128.145.254.5)  920 ms  740 ms  710 ms
  >18  iracs1.ira.uka.de (192.54.104.49)  1310 ms  1140 ms  1190 ms
 > 
>I.e.: Paris -> South France -> NJ -> PE -> Ithaca (upst. NY--hi, alma matter!) ->
      >Syracuse (upst. NY)   -> NYC, NY  -> ? -> Deutschland
>
>Why this contorted route?  Is it cost-effective?
>
iThat's what I see doing a traceroute to 129.102.0.1:

traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets
 1  iracs1.ira.uka.de (129.13.1.1)  20 ms  0 ms  0 ms
 2  ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1)  1020 ms  840 ms  1080 ms
 3  Amsterdam.NL.EU.NET (134.222.1.1)  4120 ms *  3800 ms
 4  Paris.FR.EU.NET (134.222.2.2)  4340 ms  4900 ms  3760 ms
 5  fnet-gw.inria.fr (128.93.36.128)  3880 ms  3740 ms *
 6  192.44.64.61 (192.44.64.61)  3980 ms  4960 ms *

Arnold Nipper
********************************************************************************
Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de
XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe *  +49 721 608 4331
********************************************************************************
-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 14:49:16 GMT
From:      csusac!croft@ucdavis.ucdavis.edu  (Steve Croft)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet Key mapping
Thanks for the replies to my question about the Telnet key mapping.
I just grabbed 2.3b10 which seems to be the answer.  In fact, we 
already had a Kermit key mapping file to do what we wanted.  So, things
worked out.  Again, thanks!

Steve Croft
stevec@water.ca.gov
-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 15:13:25 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!zweig@ucsd.edu  (Johnny Zweig)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Unknown TCP/IP options
Ignoring Unimplemented TCP Options -- it's not just a good idea; it's the
Law.
-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 15:39:55 GMT
From:      att!hriso!devildog!jrallen@ucbvax.Berkeley.EDU  (Jon Allen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re(2): Re: Sockets vs streams.  An attempt to answer the original question
In article <9008291444.AA15182@violet.ICO.ISC.COM> dougm@ICO.ISC.COM ("Doug McCallum") writes:
...
>> ps. Is there anyway to get a list of all the modules pushed onto
>> a stream.  I_LOOK only lists the top most module.
>
>Not in V.3.

Actually it is not quite that bad.  You should have an idea of all the
possible modules that COULD be on a given stream (not many).  It is then 
trivial to write a little program which uses I_FIND to see if the module is on
the stream.  You could then query for modules by using a command such
as: ./ifind tirdwr < /dev/WHATEVER, or make it a subroutine in your
program.  I use this method to determine what modules are on a given
tty stream.


-Jon
-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 16:24:02 GMT
From:      mcsun!i2unix!inria!ircam!mf@uunet.uu.net  (Michel Fingerhut)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe -> USA -> Europe...
Wolf Paul writes:
> Since these leased lines are not really charged by volume but rather
> have a fixed monthly charge regardless of traffic, it probably does not
> affect the cost a whole lot.

Well, it is not true insofar as the end user (which I am).  As it
appears, the French backbone will charge us Internet mail by volume.
It has to do, apparently, with the cost of some line whose cost is
fixed, but which they intend to share "equally well" among users -- ie
the more you use it the more you pay for it.

He adds:
> The Austrian branch of EUnet will shortly be connected to the Internet
> by a leased line from tuvie to mcsun [in Holland]

Too bad.  Although there is a line from France to Northern Yurop, there is
no connection for academic sites from France to there.  There is no rerouting
through anywhere else, either.  So this means that THERE IS NO INTERNET
CONNECTION between any sites connected to mcsun and France.  Mail goes around,
I hope, but since I did not get to send any yet who knows.

I suppose that when the various backbones sort their differences, we'll have
to pay so as to get to Northern Y.  I hope *they* will have to pay to get to
us, but I suspect there is more interest in the connection from us out than
the converse.  So we loose..  Unless we give up on Northern Y. altogether
and look as always in the US for software.  So much for CEE, connectedness
and other grandiose ideas.
-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 17:11:23 GMT
From:      nipper@ira.uka.DE (Arnold Nipper --- XLINK)
To:        comp.protocols.tcp-ip
Subject:   Re:  Long lines...


>Hi,
>
>Many of you may have seen the following on the TCP-IP mailing list.  Anyone
>have any suggestions or comments?
>
>Thanks,
>Phill
>------- Forwarded Message
>
>Date: 30 Aug 90 09:14:35 GMT
>From: Michel Fingerhut <eru!hagbard!sunic!mcsun!inria!ircam!mf@bloom-beacon.mit.edu>
>Organization: IRCAM, Paris (France)
>Subject: Internet routing Europe -> USA -> Europe...
>To: tcp-ip@nic.ddn.mil
>
>While trying to find whether we (in France, Europe) could reach a site
>in Germany (Europe), I got the following route from traceroute:
>
   >1  ircam-gw (129.102.0.1)  0 ms  0 ms  0 ms
   >2  fnet-gw.inria.fr (192.44.64.26)  370 ms  550 ms  480 ms
   >3  sophia-gw.inria.fr (192.5.60.250)  540 ms  350 ms  290 ms
   >4  cisco.atlantic.fr (192.33.170.1)  1430 ms  1160 ms  490 ms
   >5  wormhole.Princeton.EDU (128.112.128.114)  680 ms  710 ms  410 ms
   >6  ford-gateway.jvnc.net (130.94.0.66)  480 ms  530 ms *
   >7  nss.jvnc.net (192.12.211.1)  910 ms  640 ms  650 ms
   >8  Pittsburgh.PA.NSS.NSF.NET (129.140.69.8)  400 ms  500 ms *
   >9  Ithaca.NY.NSS.NSF.NET (129.140.74.5)  630 ms  720 ms  760 ms
  >10  lan.cornell.site.psi.net (192.35.82.1)  790 ms  900 ms  930 ms
  >11  cornell.syr.pop.psi.net (128.145.30.1)  1100 ms  530 ms *
  >12  albpop.syr.pop.psi.net (128.145.20.2)  740 ms  760 ms  590 ms
  >13  albpop.nyc2.pop.psi.net (128.145.80.1)  780 ms  920 ms  830 ms
  >14  nyc2.nyc1.pop.psi.net (128.145.42.2)  700 ms  500 ms  580 ms
  >15  * nyc_P.lan.nyc1.pop.psi.net (128.145.213.1)  1410 ms  1090 ms
  >16  nyc1.cuny.pop.psi.net (128.145.14.1)  790 ms  590 ms  910 ms
  >17  128.145.254.5 (128.145.254.5)  920 ms  740 ms  710 ms
  >18  iracs1.ira.uka.de (192.54.104.49)  1310 ms  1140 ms  1190 ms
 > 
>I.e.: Paris -> South France -> NJ -> PE -> Ithaca (upst. NY--hi, alma matter!) ->
   >Syracuse (upst. NY)   -> NYC, NY  -> ? -> Deutschland
>
>Why this contorted route?  Is it cost-effective?
>
iThat's what I see doing a traceroute to 129.102.0.1:

traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets
 1  iracs1.ira.uka.de (129.13.1.1)  20 ms  0 ms  0 ms
 2  ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1)  1020 ms  840 ms  1080 ms
 3  Amsterdam.NL.EU.NET (134.222.1.1)  4120 ms *  3800 ms
 4  Paris.FR.EU.NET (134.222.2.2)  4340 ms  4900 ms  3760 ms
 5  fnet-gw.inria.fr (128.93.36.128)  3880 ms  3740 ms *
 6  192.44.64.61 (192.44.64.61)  3980 ms  4960 ms *

Arnold Nipper
********************************************************************************
Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de
XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe *  +49 721 608 4331
********************************************************************************

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 17:52:43 GMT
From:      eru!hagbard!sunic!eric@bloom-beacon.mit.edu  (Eric Thomas SUNET)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe -> USA -> Europe...
I don't want to sound mean, but this isn't an EEC problem, this is a french
problem. France is basically 5 years behind most other "rich" european
countries in terms of networking. There is a serious lack of TCP/IP
connectivity as you have mentioned. There is also a serious lack of decent
gateways between UUCP, the internet, BITNET, etc. Just yesterday I received
a message from some french UUCP site, through a gateway at ENS Lyon. The
'Return-Path:' field contained just the login name of the poster on the UUCP
machine, and the 'From:' field contained some UUCP routing information and no
host name. Needless to say it was impossible to reply to this message, apart
from the fact that RFC822 mailers don't know what to do with UUCP routing the
syntax of the field was simply invalid. I complained, but I doubt anything will
happen, meanwhile french users "in the know" make use of the CERN gateway,
because "it works", and french politicians are happy that the particular site
they are in charge of is getting more influence and that they have managed to
get some prestigious position in RARE Working Group so-and-so, and who cares
about the rest? :-)

  Eric

PS: Sweden is not part of the EEC, and I am not precisely enthusiastic about
    the way the EEC spends its networking money, but that is another story...
-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 18:22:55 GMT
From:      sdd.hp.com!samsung!munnari.oz.au!murdu!ucsvc.ucs.unimelb.edu.au!ltu!cchd@ucsd.edu  (Huw Davies - La Trobe University Computer Centre)
To:        tcp-ip@nic.ddn.mil
Subject:   CMU TCP/IP and name serving problems
I'm trying to set up CMU TCP/IP on our VAXes. I have it all working
with the exception of name serving. I can get the local name server
to resolve names of hosts on our network, but it refuses to resolve
names for hosts "out there". Is there something I need to change in the
configuration file? The documentation is rather thin on this area :-(

Huw Davies,
Senior Systems Programmer,
Computer Centre,
La Trobe University,
Bundoora,
Victoria 3083, Australia

Phone:  (03) 479-2515 International: +61 3 479-2515
ACSnet: cchd@latvax8.lat.oz
BITnet:	cchd@latvax8.lat.oz
ARPA:	cchd@latvax8.lat.oz.au
-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 18:32:05 GMT
From:      van-bc!ubc-cs!alberta!macg@ucbvax.Berkeley.EDU  (Mike MacGregor)
To:        tcp-ip@nic.ddn.mil
Subject:   4.0 NIT Bug

Apologies in advance, as this has probably been thoroughly
discussed here:

I built NNStat here the other day, and upon running it
was told:

NNStat: Fatal NIT error
Statspy depends on bug fix in nit_if.c

The code says that Van Jacobson has found and fixed the bug.
Can someone please ship me the fix, or point me to an archive ?
Please mail direct as I don't normally read this group.

Thanks in advance,
Mike MacGregor

macg@cs.UAlberta.CA
--
uucp: macg@alberta   analog: (403)461-3830   Mike MacGregor, Dept of Comp. Sci.
ean:  macg@cs.UAlberta.CA                    U of Alberta, Edmonton AB, T6G 2H1
            Virtual memory works fine, so long as it's mostly real.
-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 18:57:48 GMT
From:      att!devildog!jrallen@ucbvax.Berkeley.EDU  (Jon Allen)
To:        tcp-ip@nic.ddn.mil
Subject:   Window Field on SYN Packet
Concerning the window field on a SYN packet, what does a value of 0 mean?
Most machines (UNIX) that I have watched on the LANalyzer show a reasonable
value for this field in the SYN packet: 2048, 4096 or something like that:

	UNIX A			UNIX B
	========		======
	SYN 4096	->
			<-	SYN ACK 4096
	ACK 4096	->

I now am trying the talk to a MVS machine which sends me a SYN packet
with a window size of 0.  What does this mean?  It certainly confuses my
UNIX machines as they then send a SYN ACK with the window field having
a value of 53000 or so:

	MVS		UNIX
	=====		============
	SYN 0	->
		<-	SYN ACK 53215
	ACK 0	->

Things seem to go downhill rapidly after this point; what is happening here?
I would like to know what machine I need to do some fixing on.

-Jon Allen
-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Aug 90 16:21:52 +0200
From:      Piet.Beertema@mcsun.EU.net
To:        Arnold Nipper --- XLINK <nipper@ira.uka.de>
Cc:        ripe@mcsun.EU.net, tcp-ip@NIC.DDN.MIL, "Phillip G. Gross" <pgross@NRI.RESTON.VA.US>
Subject:   Re: Long lines...
		From: Michel Fingerhut
		Organization: IRCAM, Paris (France)
		Subject: Internet routing Europe -> USA -> Europe...

		While trying to find whether we (in France, Europe) could reach a site
		in Germany (Europe), I got the following route from traceroute:
	
		   >1  ircam-gw (129.102.0.1)  0 ms  0 ms  0 ms
		   >2  fnet-gw.inria.fr (192.44.64.26)  370 ms  550 ms  480 ms
		   >3  sophia-gw.inria.fr (192.5.60.250)  540 ms  350 ms  290 ms
		   .....
		Why this contorted route?  Is it cost-effective?
	
	That's what I see doing a traceroute to 129.102.0.1:
	traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets
	 1  iracs1.ira.uka.de (129.13.1.1)  20 ms  0 ms  0 ms
	 2  ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1)  1020 ms  840 ms 1080 ms
	 3  Amsterdam.NL.EU.NET (134.222.1.1)  4120 ms *  3800 ms
	 4  Paris.FR.EU.NET (134.222.2.2)  4340 ms  4900 ms  3760 ms
	 5  fnet-gw.inria.fr (128.93.36.128)  3880 ms  3740 ms *
	 6  192.44.64.61 (192.44.64.61)  3980 ms  4960 ms *
	
	Arnold Nipper

Right, that's what I expected: it's just a technical problem
(a gateway not announcing a route). In other words: there was
no need to send this problem to an extremely wide-reaching
mailing list. Contacting the managers of the first gateway
(@inria) could have solved the problem...
Anyway, we'll go after it and inform the people involved.


	Piet
-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 19:48:37 GMT
From:      sklower@ernie.Berkeley.EDU  (Keith Sklower)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
In article <1990Aug28.162400.17811@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>The way to do i/o on Dennis's streams was with "read" and "write".
>Network i/o, in general, looked *exactly* like local device i/o.  This
>is the way it should be, unlike what both Berkeley and AT&T have done
>(both have reluctantly conceded that most people want to use "read"
>and "write" and have made that work, but their hearts were clearly
>elsewhere).

I find this inaccurate, partronizing and tiresome.  I have worked around
Berkeley since 1978 and although was not a member of the actual unix group
in 1982 while TCP was being incorporated, attended their meetings and
seminars.

I assure you that it was the design goal then, that only
``sophisticated process'' would need a more elaborate mechanism to establish
a network connection, but that once having established one, that it should
be usable as a completely ordinary file descriptor by ``naive'' processes
like the date command, using read and write, and that the file descriptor
should be inherited by the normal unix means (fork & exec).

It sounds to me like Henry is attempting to rewrite history (for his
own possibly political motives).
-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Sep 90 07:35:03 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        jkrey@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Obtaining RFCs
Joyce:

                     ....  Login with FTP, username "anonymous" and
      password "guest".  ....

I realize that this is the standard "boilerplate" for your announcements
of the availability of new or revised documents; however, isn't the pre-
ferred form of an "anonymous" login to use one's own fully qualified user
name and address (user@host.domain) rather than "guest" as the password?

I have noticed that "guest" is not universally accepted as a password to
the anonymous FTP account but, using my own account as an example password,
"mcc@wlv.imsd.contel.com" appears to be universally accepted.

Merton

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 20:22:58 GMT
From:      usc!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!milton!mrc%Tomobiki-Cho.CAC.Washington.EDU@apple.com  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   sockets vs. streams

If "network I/O looks like local device I/O" under Unix then when the
h*ll do I have to worry about all the socket or streams crap?

If I want to connect to port 0.143 on host 128.95.112.69, why can't I
do something like
  open ("/tcp/128.95.112.69-0.143",O_RDWR|O_CREAT,0);
(O_RDWR for bidirectional and O_CREAT to mean an active connection
instead of a listening connection)???

Or better yet, fopen() and all the other stdio calls.

/dev/tcp instead of /tcp would have been OK too if you insist.  I
don't care about the internal operating system semantics, as long as a
filesystem interface is presented.

There seems to be a religion that for some reason it is evil for TCP
to use filesystem I/O calls, although the proponents of this religion
have never given me a good reason why.

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin  "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105   "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud          "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762  "Chigau.  Gaijin ja nai.
  /|\    | |/\| _______  /  \ MRC@CAC.Washington.EDU    Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 20:26:34 GMT
From:      eru!hagbard!sunic!mcsun!hp4nl!charon!piet@bloom-beacon.mit.edu  (Piet Beertema)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe -> USA -> Europe...

	>>Why this contorted route?  Is it cost-effective?
	>
	>Well, I guess it has to do with the cost of leased lines used
	>for internet connections.
It has nothing to do with costs, politics or such;
it's just a small technical problem (a gateway not
announcing a route) that can be solved quickly.


--
	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)
-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 21:25:45 GMT
From:      netnews.upenn.edu!scotty.dccs.upenn.edu!kehoe@rutgers.edu  (Brendan Kehoe)
To:        tcp-ip@nic.ddn.mil
Subject:   IEEE802.3 & ArcNet - ok now what?

 Well, we just installed an ArcNet setup for the pc's here in the lab. I'm
curious--the PC guy said that it runs TCP/IP. Are there any funky things we
can do between the ArcNet and regular Ethernet (with both DecNet & IP)? We're
ready to spend a few bucks on connectors on the like, but nothing major..this
is just experimentation for the hell of it, before people have to really use
the machines for anything serious.
 Thanks!

Brendan Kehoe | Soon: brendan@cs.widener.edu
For now: kehoe@scotty.dccs.upenn.edu | Or: bkehoe@widener.bitnet
-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 21:31:44 GMT
From:      noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@iuvax.cs.indiana.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams

	I don't want to get into a religious war, but I don't see where a
filesystem analogy to sockets holds up to any but the most shallow
interpretation. To use your naming, what does it mean if I type:

	cd /tcp//128.210.10.8
?
	What if I do an "ls /tcp"? Be careful-- all of the assigned addresses
aren't available in any one place. Not if NIC.DDN.MIL-- they only have the
network parts...
	How do you specify a local address binding when you care? How do you
specify that you don't care? What does a "seek" mean on a socket? How do you
send urgent data in TCP?
	In a UNIX implementation, by making the "tcp" a directory, you've
introduced a type of pseudo-device like no other that exists and without
it you lose some of the information you want in the name.

	I won't argue that sockets are the "right" way, and there are certainly
rough edges, but the filesystem analagy *is* artificial. The things you do to
files (ie, storage devices) aren't the things you do with sockets (ie,
communication media). To a degree, you can make the same argument with
terminals, but it doesn't seem to be pushing it quite as much there, to me.

	In Dr Doug Comer's operating system, Xinu, he uses an "open" that
specifies remote address/port names in the "filename" as "XXX.XXX.XXX.XXX:port"
and what would be the mode is instead the local port number, if nonzero. It
works ok, but the name space isn't even pretending to be part of the
filesystem. I don't think I've seen any mapping that makes a lot of sense to
me, though I used to be a NewCastle fan... :-)
	It doesn't surpise me that the socket interface is different, then.
I don't know if that qualifies as the explanation you wanted or not, and
perhaps there are better arguments to be made on both sides...

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 21:43:20 GMT
From:      eru!hagbard!sunic!mcsun!inria!ircam!mf@bloom-beacon.mit.edu  (Michel Fingerhut)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Long lines...  (was: Internet routing Europe -> USA -> Europe...)
Arnold Nipper (XLINK, Karlsruhe, Germany) points a traceroute from his
machine to ours that goes (as hoped):
		Germany -> Holland -> Paris
while the one I get (Paris -> Germany) goes through upstate NY.  Well,
THIS IS BECAUSE THE FRENCH GATEWAY DOES NOT ALLOW ACCESS TO HOLLAND
and therefore to the rest of what's connected to it.  It's a first to me
that the reverse is possible, but as they say in French ca me fait une
belle jambe.
-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 22:09:44 GMT
From:      noose.ecn.purdue.edu!en.ecn.purdue.edu!milton@iuvax.cs.indiana.edu  (Milton D Miller)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
The thing that came to my mind when I first saw this thread was the
multiplexed character driver in AIX.  This is basically a special file,
but allows additional path name component(s) can be added, which get
passed to the driver.  (For those who don't know, AIX is IBM's name for
UNIX.)  With that in mind, let me respond:

In article <13526@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>
>	I don't want to get into a religious war, but I don't see where a
>filesystem analogy to sockets holds up to any but the most shallow
>interpretation. To use your naming, what does it mean if I type:
>
>	cd /tcp//128.210.10.8
>?

You get 'Not A Directory', just like any other multiplexed character device.

>	What if I do an "ls /tcp"? Be careful-- all of the assigned addresses
>aren't available in any one place. Not if NIC.DDN.MIL-- they only have the
>network parts...

Same as above, you see a character special multiplexed file.
Someone will probably say you should get a list of all currently known
(ie in use) sockets, but there is no such model in the current AIX
(you could use a special IOCTL for that, I suppose).

>	How do you specify a local address binding when you care? How do you
>specify that you don't care? What does a "seek" mean on a socket? How do you
>send urgent data in TCP?

Open /tcp/whatever and use ioctl().  Seek is same as a tty, ie ignored.

>	In a UNIX implementation, by making the "tcp" a directory, you've
>introduced a type of pseudo-device like no other that exists and without
>it you lose some of the information you want in the name.
>
AIX already has these, and are used for '/dev/hft', the 'High Function 
Terminal', which is the graphics head and can have 16 different sessions.
In AIX 3.1, this is also used for /dev/pty, which creates a new pty if
you don't specify the additional argument.

>	I won't argue that sockets are the "right" way, and there are certainly
>rough edges, but the filesystem analagy *is* artificial. The things you do to
>files (ie, storage devices) aren't the things you do with sockets (ie,
>communication media). To a degree, you can make the same argument with
>terminals, but it doesn't seem to be pushing it quite as much there, to me.
>

[note about Xinu deleted]

>	It doesn't surpise me that the socket interface is different, then.
>I don't know if that qualifies as the explanation you wanted or not, and
>perhaps there are better arguments to be made on both sides...
>
>-- 
>					+-DLS  (dls@mentor.cc.purdue.edu)


As far as names, maybe /dev/net/tcp, that way you could also get
ip, udp, etc. in the same directory.  Or just leave everything in 
/dev.  Also, you would probably want some trailing path to be
an unbound socket, or would just tcp (with out an additional
component) be ok?

milton

Milton D. Miller II
ECN Consultant
Disclaimer: I was a coop student at IBM.
-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 22:52:32 GMT
From:      usc!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!unicorn!milton!Tomobiki-Cho!mrc@apple.com  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
I'm not convinced how much of this belongs in comp.protocols.tcp-ip
as opposed to a Unix discussion list.  This whole discussion must seem
absurd to someone using something other than Unix.

In article <13526@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	I don't want to get into a religious war, but I don't see where a
>filesystem analogy to sockets holds up to any but the most shallow
>interpretation.

Strange how many "shallow" non-Unix operating systems which accessed
TCP through the filesystem exist.  Are you familiar with any of them?
They did it quite cleanly.

>To use your naming, what does it mean if I type:
>	cd /tcp//128.210.10.8
>?

Nothing in particular.  It can be a no-op or some sort of invalid I/O
operation.

>	What if I do an "ls /tcp"?

You get whatever you get when you open the file "/tcp" for read and
attempt to interpret it as a disk directory.  Remember, ls is just a
user program.  If you were really clever, perhaps the file "/tcp"
could contain a netstat-type report.

>Be careful-- all of the assigned addresses
>aren't available in any one place. Not if NIC.DDN.MIL-- they only have the
>network parts...

Irrelevant.  At most, the directory /tcp would have the currently open
connections as its members.

>	How do you specify a local address binding when you care? How do you
>specify that you don't care?

Encode it in the filename as well, e.g. /tcp/FH-FP-LH-LP format where
any field can be blank and trailing hyphens can be omitted.

>What does a "seek" mean on a socket?

Either a no-op or some sort of invalid I/O error.

>How do you send urgent data in TCP?

Most user programs don't do so often, so an ioctl() of some sort is
alright.

>	In a UNIX implementation, by making the "tcp" a directory, you've
>introduced a type of pseudo-device like no other that exists and without
>it you lose some of the information you want in the name.

What you're really saying is that those of your religion don't want to
support unit-record file I/O and will if necessary rewrite history to
"prove" the argument that it's "meaningless".

>	I won't argue that sockets are the "right" way, and there are certainly
>rough edges, but the filesystem analagy *is* artificial.

Well, then, let's get rid of the /dev kludge and have a special
mechanism for every different device.  We've already started on that
golden path by having sockets and streams to do the same thing.  Let's
see, we can rewind tapes but not printers, I guess we need a different
mechanism for each of these too...

Which reminds me.  Even if you didn't want to encode the connection
parameters in the filename, you still could have had had /dev/tcp and
then some ioctl to open the connection.  No need for any new system
calls (socket(), connect(), listen(), etc.)

>The things you do to
>files (ie, storage devices) aren't the things you do with sockets (ie,
>communication media).

Strange, I distinctly remember doing the exact same things with
storage devices that I do with communications media.  It was real
neat, since I could use I/O redirection for debugging or multiple-use
software.

"Those who forget the past are condemned to repeat it."

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin  "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105   "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud          "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762  "Chigau.  Gaijin ja nai.
  /|\    | |/\| _______  /  \ MRC@CAC.Washington.EDU    Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 90 23:35:40 GMT
From:      bcstec!voodoo!yo.uucp@uunet.uu.net  (howie)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Questions about the use of ping.

Thanks to the folks who responded to my questions about ping.


Please note that our mailer is messed up.


You can email me at:  

	      howie@voodoo.uucp (no matter what the "reply to" field indicates)


	      thanks again for the help,


--
				       howie              

				       uunet!bcstec!voodoo!howie

END OF DOCUMENT