The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 May 1992 00:49:37 GMT
From:      yost@adobe.COM (David Yost)
To:        comp.protocols.appletalk,comp.protocols.ibm,comp.protocols.iso,comp.protocols.misc,comp.protocols.pcnet,comp.protocols.pup,comp.protocols.tcp-ip
Subject:   Stream Protocol Gateway

Is there any sort of standard or emerging standard
Stream Protocol Gateway across protocol stacks?
Example: a host on protocol stack X wants a stream
connection to address A on protocol stack Y, so it
connects to the gateway and asks to be connected to
address A on protocol stack Y, and then the gateway
makes that connection and copies stream data back
and forth.

Please reply to me via email or at least keep the
comp.protocols.misc newsgroup in the Newsgroups list.
Thanks.

 --dave yost
   Adobe


-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 May 92 02:57:14 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

In article <1992Apr29.220943.23196@spool.cs.wisc.edu> stuart@rennet.cs.wisc.edu (Stuart Friedberg) writes:
>
 [ a scenario that locks up SunOS 4.1 ]
>
>A recent version of Ultrix cheerfully created a connection between
>the new socket and itself.  That is, netstat reported the passive
>socket in LISTEN state and a single socket with local and remote
>addr's identical in ESTABLISHED state.

As it turns out, the LISTENing socket is unnecessary.  All you need
is to make a TCP socket bound to *.some_port_number, then try to
connect it to itself.

>Clearly, the SunOS behavior is wrong.  The Ultrix behavior is much
>more benign, but probably also incorrect.  For example, how can the
>TCP engine distinguish which direction of traffic a particular "incoming"
>packet refers to?  (I.e., the "two" sockets at each end are
>indistinguishable.)

It really doesn't need to distinguish directions.  TCP normally operates
as more-or-less independent send and receive sides, and although it is
a little surprising that Ultrix lets you loop them back on themselves,
I wouldn't necessarily call it objectionable.

Some investigation discloses that SunOS is also trying to establish
the same loopback-ed connection that Ultrix successfully manages.
What appears to happen, for those with Tahoe or later source, is this:

First, the local and remote addresses are fleshed out to
	localhost.portnum	localhost.portnum	CLOSED
Then, TCP chooses an initial send sequence number ISS (say, 1234),
enters SYN_SENT state, and sends a SYN segment to itself.

State:  SYN_SENT  snd_una 1234  snd_nxt 1235  rcvnxt ---
Send:	SYN	seq=1234

It is legal to receive a SYN when you are in SYN_SENT state, and 
so this segment is accepted.  Since there is no ACK, it causes
a transition to SYN_RECEIVED state rather than ESTABLISHED state,
and does not change snd_una.  It does, however, set "rcvnxt" to the
next expected sequence number.  It also forces a response:

State: SYN_RCVD  snd_una 1234   snd_nxt 1235  rcvnxt 1235
Send:  SYN ACK   seq=1234  ack=1235

Now, when this segment is received, interesting things happen.
Since rcvnxt is greater than the seq field of the segment, TCP
decides that it is at least a partial duplicate, and trims the SYN
off the front.  Since it is left with an empty packet, it
decides that the segment was not acceptable after all and, in
accordance with the RFC which says

        If an incoming segment is not acceptable, an acknowledgment
        should be sent in reply (unless the RST bit is set, if so drop
        the segment and return):

it sends a response again and drops the segment.  This all happens
before any ACK processing, so the (valid) ACK field is ignored,
and the TCP remains in the same state and sends the same SYN ACK
response to itself, again and again, locking up the system.

I would conjecture that Ultrix treats the trimmed segment as it would
any other dataless ACK segment (i.e., processes the ACK field), and
so enters ESTABLISHED state and avoids this behaviour.
Does the RFC permit it?  Well, maybe, because it also says

        In the following it is assumed that the segment is the idealized
        segment that begins at RCV.NXT and does not exceed the window.
        One could tailor actual segments to fit this assumption by
        trimming off any portions that lie outside the window (including
        SYN and FIN), and only processing further if the segment then
        begins at RCV.NXT.

and, after trimming off the duplicate SYN, the (empty) result segment
does begin at "rcvnxt", so maybe it *is* OK to process its ACK.

>What does Host Requirements suggest or mandate for this case?  I think
>it should be prohibited.

That would probably be the easiest way of correcting the situation, but
I don't think the RFCs address the issue of connecting to yourself at all.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 May 92 06:56:14 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: Negative ping times

In article <1992Apr29.000610.7443@unlv.edu> greg@duke.cs.unlv.edu (Greg Wohletz) writes:
>Some versions of ping have the following bug, they contained the line:
>
>#define LONG_MAX 0x7ffffffff
>
>One to many f's. 
>
>static char sccsid[] = "@(#)ping.c      5.6 (Berkeley) 6/1/90";
>
>Is at least one version that had this problem.  The result of this bug
>is to always report -1 as the min rtt.


That's a relief.

Someone almost had us "going" there with the possibility of ultra-violet color
jacket sheathed light pipes sporting Tachyonic Packet Transmission (TPT).  :-)


Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 May 1992 07:57:02 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

In article <1992Apr30.225714.29192@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
>As it turns out, the LISTENing socket is unnecessary.  All you need
>is to make a TCP socket bound to *.some_port_number, then try to
>connect it to itself.
>...
>It really doesn't need to distinguish directions.  TCP normally operates
>as more-or-less independent send and receive sides, and although it is
>a little surprising that Ultrix lets you loop them back on themselves,
>I wouldn't necessarily call it objectionable.

On the contrary, it's a perfectly acceptable operation and should be
dealt with as one.  Although the TCP specs say that each connection is
identified by two {host,port} pairs, i don't think you'll find anything
that says the two pairs have to be *different*.  Not clear what good
such a connection does anyone, though, other than to exercise this bug.

From the other discussion, what we have here is a TCP/IP
implementation that cannot handle receiving an ACKless SYN when in
the SYN_SENT state.  This is a perfectly legitimate event that must be
handled.  The only bearing the one sided connection has on the issue
is that it's a very easy way to reproduce the problem.  From the
sounds of things, the Sun TCP would hang just as well if you got two
different end points on two different machines connecting to each
other at exactly the same time.
						don provan
						donp@novell.com

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 May 92 12:16:20 GMT
From:      wswietse@wsbs06.bs.win.tue.nl (Wietse Venema)
To:        comp.protocols.tcp-ip
Subject:   Re: secure tftp

scottp@npg-sd.SanDiegoCA.NCR.COM (Scott Platenberg) writes:

>I am looking for info on "secure" tftp.  Can anyone help point me
>in the right direction?  Thanks.

As far as I know, the TFTP protocol has no provisions for security.

Hoewver, you can configure things such that TFTP is less dangerous.

- Run the daemon under an unprivileged UID, not root.

- Have the daemon do a chroot() to a subtree of the file system.
  You can use the BSD sources at ftp.uu.net if your tftpd does not
  support this feature.

- Use access control to restrict the number of hosts that may contact
  your tftp daemon. For example:

	cert.sei.cmu.edu:/pub/network_tools/tcp_wrapper.shar
	ftp.win.tue.nl:/pub/security/log_tcp.shar.Z

  are the sources to a simple daemon front-end program that implements
  access control and other security goodies for a large variety of IP
  services.

	Wietse 

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 May 92 14:25:28 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   LANtastic 4.1 & TCP/IP

In article <wihuri.704625404@polaris> wihuri@polaris.utu.fi writes:

  > HAS SOMEONE MADE A PACKET DRIVER OR LANBIOS WHICH WOULD ACCEPT
  > LANTASTIC AND TCP/IP-PROTOCOLS AT THE SAME TIME?

I believe that Artisoft is looking into this.  However, they don't
seem to be pursing it with any great speed.  I suggest that everyone
who wants Lantastic to cooperate with TCP/IP should contact Artisoft
technical support.  Tell them that you want a LANBIOS that runs over
packet drivers, and you want it last year.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 May 1992 15:36:32 GMT
From:      subbu@hpindda.cup.hp.com (MCV Subramaniam)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

>
>I recently locked up SunOS 4.1 by trying the following scenario:
>
>PLEASE DO NOT TRY THIS UNLESS YOU ARE WILLING TO POWERCYCLE YOUR MACHINE!
>
>create passive socket              local_host.local_port : *.*
>create new socket                                    *.* : *.*
>bind new socket to
> passive socket local address:     local_host.local_port : *.*
> (SO_REUSEADDR needed)
>attempt to connect new socket
> to passive socket as remote peer: local_host.local_port : local_host.local_port
>
>PLEASE DO NOT TRY THIS UNLESS YOU ARE WILLING TO POWERCYCLE YOUR MACHINE!

    We found this  problem a couple of years ago at HP, on all 4.3 BSD based
    machines (4.2 worked  correctly).  The problem  happens  because 4.3 TCP
    does not  treat  crossing  SYNs  correctly  (i.e.  if TCP_A  sends a SYN
    request  to TCP_B  and TCP_B  does  likewise,  and the SYNs  cross  each
    other).

    Particularly,  in your case, both the TCP  entities are in the same host
    and are  involved in a SYN|ACK  war, so the kernel goes into a loop.  We
    have submitted a fix to BSD for this problem.

>
>A recent version of Ultrix cheerfully created a connection between
>the new socket and itself.  That is, netstat reported the passive
>socket in LISTEN state and a single socket with local and remote
>addr's identical in ESTABLISHED state.
>
>Clearly, the SunOS behavior is wrong.  The Ultrix behavior is much
>more benign, but probably also incorrect.  For example, how can the
>TCP engine distinguish which direction of traffic a particular "incoming"
>packet refers to?  (I.e., the "two" sockets at each end are
>indistinguishable.)
>
>What does Host Requirements suggest or mandate for this case?  I think
>it should be prohibited.

    I agree. I think when an application tries to connect to itself, it
    should be treated as a special case, and disallowed.

-Subbu

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 May 92 18:35:17 GMT
From:      ddj@zardoz.club.cc.cmu.edu (Doug DeJulio)
To:        comp.protocols.tcp-ip,comp.sys.next.sysadmin,comp.sys.next.misc
Subject:   Re: Two NeXTstations won't talk to each other

In article <920429182542@pericles.ftp.com> jamie@vax.ftp.com (Jamie O'Keefe) writes:
>> The hardware guys here all seem to agree that the minimum distance
>> between thinwire connections should be 2.5 meters.
>
>I don't think that is it.  We have run one meter segments between
>pc's and had no problems.  

It's still worth checking out.  The PCs use different ethernet
hardware than the nexts.  It might be the problem.
-- 
Doug DeJulio
ddj@zardoz.club.cc.cmu.edu (NeXT, AMS/ATK and MIME mail welcome)

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 May 92 19:22:55 GMT
From:      djschoff@cibecue.az05.bull.com (Daniel J. Schoffelman)
To:        comp.protocols.tcp-ip
Subject:   "Connected" UDP

The Berkeley Sockets interface allows a program to
issue a connect() request on a UDP socket.  This has several
ramifications, depending on who you ask.

The obvious effect of this is that the program can now make
write() or send() requests, without specifying a destination.

W. Richard Stevens, in the book "UNIX Network Programming", p. 271,
says that "if the datagram protocol suports notification for invalid
addresses, then the protocol routine can inform the user process if
it sends a datagram to an invalid address.  For example, the
Internet protocols specify that a host should generate an ICMP port
unreachable message if it receives a UDP datagram specifying a UDP
port for which no process is waiting to read from."

He also says that a connected UDP socket can do a read() and recv()
request without needing to know where it came from.

In comparing the Socket calls to those in TLI/XTI, it is not clear
if the same kind of capabilities exist in TLI/XTI, concerning the
ability to "connect" connectionless fds.  Do the UDP RFCs require
sending back the ICMP "port unreachable" message in such a circumstance,
or do they even envision such a thing?

For System V-based, stream implementations where the Berkeley sockets
calls are also supported, how do they accommodate the concept of
"connected" UDP sockets?

(Does anybody know of real uses of connected UDP sockets?)

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 May 1992 20:34:11 GMT
From:      scoggin@daisy.udel.edu (John K Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Searching for Phone Number of Comdisco

I am searching for the phone number of Comdisco Software, authors of a network
simulation package (PLANET, I believe).  Anyone familiar with them and/or
their product?

	- John

-------------------------------------------------------------------------
John K. Scoggin, Jr.			Email:   scoggin@udel.edu
Supervisor, Network Operations			 scoggin@delmarva.com
Delmarva Power & Light Co.		Voice:	 302-451-5200
P.O. Box 6066				Fax:	 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary.  Void where prohibited by law (or common sense).

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 May 92 23:31:52 GMT
From:      c60a-km@congo.Berkeley.EDU (Ahmon Dancy)
To:        comp.protocols.tcp-ip
Subject:   Information on Telnet protocol


Greetings.  I am looking for some information on the telnet protocol.
I really don't know what I'm looking for either.  I wrote a program
that does something like:

connect(socket, &server, sizeof(server)); 
and read(socket, buffer, sizeof(buffer));

What read returns is 3 and the buffer contains three control characters. 
I was hoping more for something like "login: "... ya know?  

Does anyone know what I'm talking about?

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 May 1992 02:12:04 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: A PC with 2 Ethernet interfaces?

In article <jpc.704664163@avdms8.msfc.nasa.gov>, jpc@avdms8.msfc.nasa.gov
 (J. Porter Clark) wrote:
>Does anybody out there know of hardware and software which would allow
>a PC to have two physical Ethernet interfaces which run
>simultaneously?  This setup would also need a socket-based programming
>interface which would allow reading and writing to each interface from
>the same application program.  Oh, yes, it needs to support TCP/IP.

KA9Q would fit the bill.

It's in ftp.ucsd.edu:hamradio/packet/tcpip/ka9q/ .

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 May 92 03:43:48 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

In article <1992May1.075702.8362@novell.com> donp@novell.com (don provan) writes:
>From the other discussion, what we have here is a TCP/IP
>implementation that cannot handle receiving an ACKless SYN when in
>the SYN_SENT state.

Hmm, no, I don't think that is the problem I described.

The (Tahoe and later) BSD implementations, as well as recent SunOS ones,
do properly handle the received SYN when in SYN_SENT state.
The problem occurs later, when the TCP receives what it believes to be
a redundant SYN ACK.  It drops the SYN, and then fails to process the
remaining ACK.  If it went ahead and processed the ACK anyway, I believe
that the reflexive connection would be established without any problem.
The RFCs are unclear about what is the "correct" thing to do, although
in this instance it is clear that ignoring the ACK leads to undesirable
behaviour.

>From the
>sounds of things, the Sun TCP would hang just as well if you got two
>different end points on two different machines connecting to each
>other at exactly the same time.

Sorry if I gave that impression.  If the problem were related to 
SYN in SYN_SENT state, then I would agree with you.  However, I don't
think that two different hosts could reproduce the problem that I
am trying (apparently, not very successfully) to communicate.

-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 May 1992 06:37:29 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Information on Telnet protocol

In article <1992May1.233152.20189@pasteur.Berkeley.EDU> c60a-km@congo.Berkeley.EDU (Ahmon Dancy) writes:
>Greetings.  I am looking for some information on the telnet protocol.

See RFC's 854 "Telnet Protocol Specification" and 855 "Telnet Option
Specifications".  And see RFC 1060 "Assigned Numbers" for the list of
option codes and references to their specifications.

>I really don't know what I'm looking for either.  I wrote a program
>that does something like:
>
>connect(socket, &server, sizeof(server)); 
>and read(socket, buffer, sizeof(buffer));
>
>What read returns is 3 and the buffer contains three control characters. 
>I was hoping more for something like "login: "... ya know?  

Telnet includes a mechanism for sending option codes to negotiate different
operating modes (e.g. whether the client host should do local echoing).
Those three bytes were a request to set an option, and it's waiting for you
to respond with agreement or disagreement.

RFC's can be FTPed from NIC.DDN.MIL, as well as many archive sites.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 May 92 23:17:38 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcpip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: VT220 Emulation

markus@edfd.uucp (Markus Gruenkorn (MAGIC)) writes:

>Is there any public domain telnet available which is capable of a 
>VT220 emulation or more. We only have NCSA telnet (VT100 emulation) 
>and need a VT220 emulation.

If all you need is telnet, then mskermit 3.11 will do the job (together
with a suitable packet driver). If you're used to using the FTP server,
then kermit won't be enough and you'll have to buy a commercial program
such as BWNFS or PC/TCP. If you want to transfer files with mskermit, you'd
need a kermit server on your host machine.

MSkermit can be obtained from many places - there are several SIMTEL
echo sites in Germany, and it was posted to c.b.i.p a while back.

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
Vapourware is the programming industry's answer to solid-state computers.

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 May 92 20:31:52 GMT
From:      schmidt@net4.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   recv/send vs. read/write

Hi,

	On pages 134-135 of John Bloomer's book Power Programming with
RPC he seems to imply that a call to recv() and send() on a socket
descriptor will not return until the requested number of bytes have
been received or sent (unlike read() or write(), which may send or
receive less than the requested amount).  However, after reading the
Sun OS man page for recv/send I don't feel confident that this is a
correct distinction.

	My question is: are these really the semantics of send/recv,
and if so, where is that be documented, and is it a portable
assumption?

	Thanks,

		Doug
--
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | schmidt@ics.uci.edu
And say to all the world: "This was a man."         | ucivax!schmidt
   -- In loving memory of Terry Williams (1971-1991)| (714) 856-4101

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 May 92 21:54:55 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: recv/send vs. read/write

>	On pages 134-135 of John Bloomer's book Power Programming with
>RPC he seems to imply that a call to recv() and send() on a socket
>descriptor will not return until the requested number of bytes have
>been received or sent (unlike read() or write(), which may send or
>receive less than the requested amount).

In all the BSD sources I've seen read/recv go through the same kernel
function, soreceive, as do write/send (sosend), so I can't believe
there's any difference.

Beware of other errors in this book.  On pp. 333-335 his description of
SIGPIPE is totally wrong.  This signal is never generated for a read on
a connection-oriented socket (only for a write) and is never generated
for a connectionless protocol (e.g., UDP) as he describes.  He also thinks
every SOCK_STREAM socket uses TCP and every SOCK_DGRAM socket uses UDP,
even in the Unix domain!  The first sentence on p. 122 exemplifies some
of this: "Let's look at a connection-oriented server, TCP_AF_UNIXserver.c,
that uses the UDP transport and UNIX domain addressing."

	Rich Stevens  (rstevens@noao.edu)

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      4 May 92 07:18:07 GMT
From:      wihuri@polaris.utu.fi (Pauli Wihuri)
To:        comp.protocols.tcp-ip
Subject:   Re: LANtastic 4.1 & TCP/IP

nelson@crynwr.com (Russell Nelson) writes:
>In article <wihuri.704625404@polaris> wihuri@polaris.utu.fi writes:
 
>  > HAS SOMEONE MADE A PACKET DRIVER OR LANBIOS WHICH WOULD ACCEPT
>  > LANTASTIC AND TCP/IP-PROTOCOLS AT THE SAME TIME?
 
>I believe that Artisoft is looking into this.  However, they don't
>seem to be pursing it with any great speed.  I suggest that everyone
>who wants Lantastic to cooperate with TCP/IP should contact Artisoft
>technical support.  Tell them that you want a LANBIOS that runs over
>packet drivers, and you want it last year.

I just heard from finnish company which imports Artisoft LANtastic
into Finland that Artisoft has bought it's biggest rival and which has
already some support to TCP/IP. Is this by any chance true? Is there
by ane chance any hope?

Thank you all who answered my question.

Pauli Wihuri
wihuri@utu.fi
University of Turku
Computing Centre

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      4 May 92 11:55:34 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Over Token-Ring


Thanks to all who responded.  We will look for the publically available
packet drivers and also checkout the products from FTP Software.  Again,
many thanks

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      4 May 92 13:31:33 GMT
From:      MADJK@rohvm1.rohmhaas.com (John G Kinker)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   CMU Bootpd and AIX/6000 V3.1.5

I'm trying to use the public domain Bootp server from CMU with AIX V3.1.5 on an
RS/6000.  This code compiles and runs fine under HP/Apollo Domain and it
compiles and executes under AIX.  BUT under AIX it fails to return a response
to a client machine because the ioctl(SIOCSARP) call to temporarily stuff the
arp cache with the client's hardware and ip addresses fails due to an "Invalid
argument".  Has anyone seen and resolved this problem or can someone point me
to documentation that might indicate what the proper arguments to the SIOCSARP
call are under AIX?

John Kinker                                             madjk@rohmhaas.com
Computer Systems Associate                                    215-785-8752

Rohm and Haas Company - Research Division - PO Box 219 - Bristol, PA 19007

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      4 May 92 14:44:26 GMT
From:      wucolin@popeye.CIS.McMaster.CA (Colin Wu)
To:        comp.sys.next.sysadmin,comp.sys.next.misc,comp.protocols.tcp-ip
Subject:   Re: Two NeXTstations won't talk to each other - SOLVED!!!!

First a BIG THANK YOU to all those who replied either on the net or via email!  

Those who suggested it was a problem with the wire get the big cigar.  It  
indeed was the co-ax.  One of the rooms that this leg runs through is our  
conference room which has three connections in it.  These, for aesthetic  
reasons, were the fancy wall jack type where the cable going to the equipment  
can be disconnected.  Well, when the leg was first installed and tested, the  
drops (for lack of a better word) were not plugged in, and the leg came in just  
under the limit, so we forgot about the plug-in 'drops'.  So guess what  
happened.  Somebody decided to actually use one of these connections in the  
conference room (what nerve! ;-) ) and immediately put the leg over spec. and  
our two NeXTs into separate universes.

At least I discovered it before the weekend!

Again, big thank you to all.
--
   __     _             _            Colin Wu
  /  )   //            ' )   /       Network Analyst
 /    __|/  o ____      / / / . .    Computing & Information Services
(__/ (_) \_<_/ / <_    (_(_/ (_/_    McMaster University
email:	wucolin@popeye.CIS.McMaster.CA	(NeXTmail welcome)
	wucolin@McMaster.CA		(Generic email only)

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      4 May 92 15:35:23 GMT
From:      berman@williams.EDU (Mark Berman)
To:        comp.protocols.tcp-ip
Subject:   SLIPping on DOS using NCSA Telnet


Does anyone know of, or have, a cookbook for implementing SLIP using NCSA
Telnet on DOS. There appear to be drivers out there, but no documentation
on getting it all to work.

Mark Berman
Williams College, Technical Services
Mark.Berman@Williams.Edu

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 May 1992 17:21:46 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.dcom.lans.ethernet,comp.protocols.tcpip
Subject:   Re: PCRoute: 10baseT and Novell questions

In article <1992Apr30.160918.11672@cton.uucp> cton!ken@uunet.uu.net writes:

>	1) does it work ok with the western digital 10baseT cards?

The last time I looked, it supported the 8003E and EB cards; the media
interface is transparent.

>	2) what does it do with the Novell packets in a mixed
>	   Novell and Unix environment?

Ignores them. Otherwise, I'd have a few boxes set up with it.

-- 
Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
The Chariman of the Board and the CFO speak for SCI. I'm neither.
"Always remember, that someone, somewhere, is making a product that will
make your product obselete." Georges Doriot, founder of American R & D.

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      4 May 92 18:05:48 GMT
From:      craig@fred.gi.alaska.edu (Craig Helmuth)
To:        comp.protocols.tcp-ip
Subject:   Re: Negative ping times

In article <10351@gollum.twg.com> oldera@twg.com (Ed R. Alcoff) writes:
>In article <36382@ogicse.ogi.edu> mwitt@ogicse.ogi.edu (Mike Witt) writes:
>>
>>Frank,
>>
>>Sometimes on a very fast optical link, packets can actually
>>exceed the speed of light.  This has been known to cause negetive
>>"ping" times, as well as an occasional ack for a packet that has not 
>>yet been sent.
>>
>>It's nothing to worry about.
>>
>>-Mike
>
>What -exceeds the speed of light!?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   (see below)
>
>Gimme a break!  I am taking this with tongue in cheek as that
>is how I hope it was meant... Warp Factor 9 Mr Zulu.
>
>Cheers,
>
>Ed Alcoff
>Product Line Manager
>The Wollongong Group, Inc.
>
>......
>.......
>......
>......
>.....
>.....
>..........
>
To be entirely picky, some things do go faster than light - it depends
on the medium the e-m radiation is in.  For example, the speed of light
(optical) through a brick wall (not glass brick!) is slower than the
California National Guard...

Ask a sumpercomputer vendor's engineering people for the speed of
electrical current.  Multimode optical fiber has an index of refaction
of about 1.46, which implies a speed of light in optical fiber of
       (300,000 km/sec)/1.46 = 205,000 km/sec

Of course this may have nothing to do with negative PING times...   ;-)

 Craig Helmuth, Network Manager  |  craig@fred.gi.alaska.edu
          Geophysical Institute  |  fncah@alaska.bitnet
 University of Alaska Fairbanks  |  "Its all FANTASY...until its HISTORY"
ObDis: My employer fully sanctions & endorses what I say (with $$$)...NOT!

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      4 May 92 19:14:29 GMT
From:      nedeljn@flint.cs.orst.edu (Nenad Nedeljkovic - Nesha)
To:        comp.protocols.tcp-ip
Subject:   Transfer rate for large messages (Ethernet)

I am writing an application across an Ethernet based network of Sun 
sparcstations using TCP sockets. I have trouble explaining following 
experimental results:

Time to send 1Kbyte message from one workstation to another = ~1ms  (OK)

Time to send 5Kbyte message from one wotkstation to another = ~5ms  (OK)

Time to send 10Kbyte message from one wotkstation to another = ~100ms (???)

My only guess is that there are more collisions for large messages but I would 
not expect such degradation of performance.

Any help would be appreciated.

Nesha

-- 
Nenad Nedeljkovic                        -------------------------------
   Internet: nedeljn@flint.cs.orst.edu  | Department of Computer Science  
   Phone:    (503) 737 - 5571 (office)  | Oregon State University           
             (503) 752 - 7632 (home) 	| Corvallis, OR 97331

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      4 May 92 20:24:35 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Transfer rate for large messages (Ethernet)

In article <1992May04.191429.13117@CS.ORST.EDU> nedeljn@flint.cs.orst.edu (Nenad Nedeljkovic - Nesha) writes:
>I am writing an application across an Ethernet based network of Sun 
>sparcstations using TCP sockets. I have trouble explaining following 
>experimental results:
>
>Time to send 1Kbyte message from one workstation to another = ~1ms  (OK)
>
>Time to send 5Kbyte message from one wotkstation to another = ~5ms  (OK)
>
>Time to send 10Kbyte message from one wotkstation to another = ~100ms (???)
>
>My only guess is that there are more collisions for large messages but I would 
>not expect such degradation of performance.
>
>Any help would be appreciated.
>
>Nesha

How are measuring the transfer?  Are you monitoring the wire, or just
using events at the socket interface?

Unless the transfer is significantly larger than the TCP window and local
kernel buffering, you have to be careful not to measure local buffering
effects.  I've seen FTP report small files transferred in 0 seconds!
(that's a pretty high transfer rate ;-} )  Also, be careful that the
clock resolution is fine enough to give you meaningful numbers.

Art

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      4 May 92 23:42:38 GMT
From:      robinson@mdivax1.uucp (Jim Robinson)
To:        comp.protocols.tcp-ip,bc.general,bc.unix,bc.bcnet
Subject:   1992 IFIP Conference - UPPER LAYER PROTOCOLS, ARCHITECTURES AND APPLICATIONS


I am posting this for a friend. Please direct all enquiries to the
conference email address: ifip92@vancouver.osiware.bc.ca

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

                  1992 IFIP International Conference
                               on
       UPPER LAYER PROTOCOLS, ARCHITECTURES AND APPLICATIONS

                         May 27 to 29, 1992
	             (Tutorials : May 25 to 26)

                 University of British Columbia
                        Vancouver, Canada

                          Sponsored by:
                     IFIP Working Group 6.5
 
                           Hosted by :
                   University of British Columbia
                           OSIware Inc.

+------------------------------------------------------------------------+
|                          PLEASE NOTE                                   | 
|                                                                        | 
| This email announcement is a repeat of one that was distributed in     |
| February. It contains more detailed information on the conference as   |
| well as a registration form that you can print off and return by mail. |
| We regret that due to our not being able to accept credit card         |
| payment, you CANNOT register via email.                                |
|                                                                        |
| A hardcopy registration kit containing the same information has        |
| already been mailed to everybody that responded to the February        |
| announcement. If you have received the hardcopy version, then          |
| you should use the registration form contained in the                  |
| registration kit rather than the electronic version contained here.    |
|                                                                        | 
| If you have been expecting to receive the hardcopy registration kit,   |
| and have not received it by April 15 1992, then you can use this       |
| email version of the form to register.                                 |
|                                                                        | 
| We apologize if this is a duplicate message resulting from your being  |
| on more than one of our distribution lists.                            |
|                                                                        |
| Conference Email Address : <ifip92@vancouver.osiware.bc.ca>            |
|                                                                        |
+------------------------------------------------------------------------+

CONFERENCE PROGRAMME
--------------------

The conference will provide an international forum for the exchange of 
information on the technical, economic, and social impacts and experiences 
with upper layer protocols, architectures and distributed applications. The 
format of the conference will be two and a half days of conference paper 
presentations and one half a day of workshops.

CONFERENCE FEE : $325 CDN before April 24, $360 CDN after April 24.

TUESDAY MAY 26, 5:00-7:00 Wine and Cheese Welcome

WEDNESDAY MAY 27

8:45-9:00   Opening remarks by Einar Stefferud, Conference Chair

9:00-10:30  SESSION I - APPLICATION LAYER DEVELOPMENT ENVIRONMENTS

Touring Machine: A Software Platform for Distributed Multimedia Applications.
M. Arango et al., USA

Automating Specification of Network Applications: Issues for the Composite 
Systems Approach. Stephen Fickas and B. Robert Helm, USA

ELROS - An Embedded Language for Remote Operations Service.
M.L. Branstetter, J.A. Guse, and D.M. Nessett, USA

11:00-12:30  SESSION II - GROUP COMMUNICATION

Developing International Standards for OSI Group Communication.
Steve Benford, Jacob Palme and Murray Turoff

Environment Support for Cooperative Working.  
Manel Medina and Tom Rodden Lancaster University Spain/England

A Framework for Modeling Collaborations. Harrick M. Vin and Mon-Song Chen,USA

2:00-3:30    SESSION III - PRESENTATION LAYER

Measuring the performances of an ASN.1 compiler. 
Christian Huitema and Ghislain Chave, France.

Coding Rules for High Speed Networks. Martin Bever and Ulrich Schaffer,Germany

Generating Object-Oriented Telecommunications Software using ASN.1 Descriptions.
Juha Koivisto and James Reilly, Finland

4:00-5:30   SESSION IV - ELECTRONIC MAIL 1

Design and implementation of a mobile-access system to X.400 services.  
Marcel Baveco and Bertjan Teunissen, The Netherlands

X.400 Interconnection Considerations. Christopher Lueder, USA

Internet Multimedia Mail: Emerging Standards for Interoperability.
Nathaniel S. Borenstein, USA

THURSDAY, MAY 28th

9:00-10:30    SESSION V - NETWORK MANAGEMENT

On Managing to be Managed. Owen Newman, USA

MHS Routing Framework. Cristian Constantinof, Canada

A Generic Management Information Base Browser. 
G. Pavlou, J. Cowan and J. Crowcroft, England

9:00-10:30    SESSION VI - APPLICATION LAYER MODELS AND ARCHITECTURES

Object-Oriented Modeling of the Application Layer Structure.
Magdalena Feldhoffer, Germany

Application Context definition for a specific application layer protocol 
and rapid prototyping with Estelle. 
C.T. Nguyen, Ph. Hunel,and M.C. Vialatte, France

Object-Oriented Design for Distributed Systems and OSI Standards.
Gregor v. Bochmann, Stephane Poirier and Pierre Mondain-Monval Canada

11:00-12:30   SESSION VII - DIRECTORY SERVICES

A Directory Model to support Cross-Context Naming and Addressing.
Gita Gopal and Sze-Ying Wuu, USA

Applying OSI Directory Naming Architecture to Integrated Network Management.  
Xinxin Zhang and Dominique Seret, France

Representing Authorization Information in the X.500 Directory.
Wolfgang Prinz, Germany

11:00-12:30   SESSION VIII - COMMUNICATIONS PROTOCOLS

Concurrent Multicast Checkpointing. Erwin Mayer, USA

Concatenation: A Contribution to High Speed Protocols.
Christiane Feder-Andres and Dieter Riexinger, Germany

Document Oriented Communication Model for Medical Applications.
Christian Gayda, Germany

2:00-5:30     WORKSHOPS

Multimedia Mail 
Upper Layer Protocols in Ultra High Speed Networks
Mail Network Management
Dialup OSI Stack
Resource Discouvery
Security
Group Communications
Application development environments
Mail Network Backbones
Common Global Addressing

7:00 BANQUET DINNER WITH GUEST SPEAKER : PROF. DAVID J. FARBER

FRIDAY, May 29th

9:00-10:30   SESSION IX - ELECTRONIC MAIL 2

Inmarsat-C Interworking with X.400. 
P.J. Fransen, H. Maatman,G.H. Kruithof, The Netherlands

Design of an integreated X.400 filestore. 
L. Duchien, Valerie Gay, Eric Horlait  France

MYME: A Pilot Development for the Distributed Management of
Heterogeneous E-Mail Systems. 
G. Altomare, P. Pennelli,A. Pepe, D. Rotondi Valenzano Italy

11:00-12:30   SESSION X - FINAL SESSION

A Model of Security in Open Telecooperation, Rudiger Grimm, Germany

A Dynamic Tester for use with OSI Networks, Nasser Modiri, USA

The Future of OSI: A Modest Prediction. Marshall T. Rose, USA

2:00-3:30	WORKSHOP REPORTS

4:00-5:00	BUSINESS MEETING	

Conference Co-Chairs      Program Co-Chairs         Organizing Committee Chair
--------------------      -----------------         --------------------------

Einar Stefferud (US)      Gerald Neufeld (CA)       Neil Koorland (CA)
Christian Huitema (FR)    Bernhard Plattner (CH)

                          Program Committee

Jun Adachi (JP)           Erik Huizer (NL)          Peter Schicker (CH)     
Raj Ananthanpillai (US)   Neil Koorland (CA)        Einar Stefferud (US)   
Gregor Bochmann (CA)      Hannes Lubich (CH)        Mike Schwartz (US)      
David Chappell (US)       James McHugh (US)         Marshall Rose (US)      
Frank Ferrante (US)       Manuel Medina (ES)        Douglas Terry (US)      
James M. Galvin (US)      Barbara Nelson (US)       Pedro Veiga (PT)       
Ruediger Grimm (DE)       Juan Saras (ES)           Brian Wideen (CA)       
Christian Huitema (FR) 

TUTORIAL PROGRAMME
------------------

A comprehensive tutorial program will be held on the two days preceding the
conference. 

+-----------------------------------------------------------------------------+
|              Practical Perspective on OSI Networking                        |
|                          Marshall T. Rose                                   |
|                                                                             |
|               OSI Security Techniques and Standards                         |
|                            Warwick Ford                                     |
|                                                                             |
|    OSF's Distributed Computing Environment (DCE): Concepts and Protocols    |
|                           David Chappell                                    |
|                                                                             |
|Secure Communication Using X.500 Services for X.400 and Privacy Enhanced Mail|
|                          James M. Galvin                                    |
|                                                                             |
|                X.400 / X.500 - Where are we Today ?                         |
|                           Erik Skovgaard                                    |
|                                                                             |
|                               ASN.1                                         |
|                           Bancroft Scott                                    |
+-----------------------------------------------------------------------------+

TUTORIAL 1  PRACTICAL PERSPECTIVE ON OSI NETWORKING  ($390.00 CDN)

Instructor : Marshall T. Rose, Dover Beach Consulting Inc.
Date       : Monday 25 May  9:00 - 5:00 and Tuesday 26 May 9:00 - 5:00 (2 days)

Who Should Attend

A basic familiarity with networking and OSI is assumed: this course is NOT 
an introduction to, or a tutorial on, OSI.  Detailed knowledge of the protocols 
is not required, but experience with implementing networking protocols is 
very helpful.  Experience with the "C" programming language is also useful.

Overview

This two day course provides a practical perspective on the issues involved 
in developing and deploying OSI networks:  it is concerned with "filling in 
the gaps" between "what the standards say" and "how a system 
implements OSI".  The talk does not focus on architecture, nor on vendor 
offerings or specific implementations, rather it deals with system issues such 
as explaining how much knowledge the transport layer must have, or why 
certain OSI protocol combinations do not interwork.

Instructor

Marshall T. Rose is Principal at Dover Beach Consulting, Inc., a California-
based computer-communications consultancy.  He spends half of his time 
working with clients, and the other half involved in self-supported, openly-
available projects.  Rose lives with internetworking technologies, such as 
TCP/IP, OSI, network management, and directory services, as a theorist, 
implementor, and agent provocateur.

TUTORIAL 2      OSI SECURITY TECHNIQUES AND STANDARDS  ($265 CDN)

Instructor : Warwick Ford, Bell-Northern Research
Date       : Monday 25 May  9:00 -5:00 

Who Should Attend

Engineers, technical managers, and technically-oriented marketing or 
purchasing staff of corporations and government agencies involved in 
buying, developing, or selling computer communications products.  A basic 
understanding of Open Systems Interconnection  (OSI) is assumed.  No prior 
knowledge of security  techniques is needed.

Overview

Part I - Security Techniques
This part of the tutorial provides the necessary technical background
to understand the contents of the OSI Security Standards.  Topics include :  
Security Services, Introduction to Cryprographic Techniques, Key 
Management, Architectural Placement Options, Authentication 
Confidentiality and Integrity, Access Control, Non-repudiation, Security 
Management

Part II - Open Systems Security Standards (ISO/IEC and CCITT)
This part of the tutorial describes the international standards  which have 
been developed, or are in development, relating to security in open systems 
networking.  Topics include : The OSI Security Architecture, Security 
Frameworks, Lower Layers Security, Generic Upper Layers Security, Security 
Management, Message Handling Systems Security, Directory Systems 
Security, Other Applications Security, Security Techniques Standards, 
Standards Timescale Overview

Instructor

Warwick Ford is with Bell-Northern Research Ltd in Ottawa, Canada.  At 
BNR he manages a department responsible for OSI upper layers and security 
standards.  He is an active participant in several ISO and CCITT  committees 
developing security standards.  Prior to joining BNR in 1987, Dr. Ford 
worked for 16 years with the Australian Government, in the Department of 
Defence and the CSIRO research organization.

TUTORIAL 3  SECURE COMMUNICATION USING X.500 SERVICES FOR X.400 AND 
PRIVACY ENHANCED MAIL  ($265 CDN)

Instructor :  James M. Galvin, Trusted Information Systems Inc.
Date       :  Tuesday, 26 May 9:00 - 5:00

Who Should Attend

Engineers, technical managers with an understanding of Open Systems 
Interconnection X.400 and X.500 concepts;  a basic knowledge of security 
techniques and issues is an asset.  .Many of the security services specified 
in the OSI protocols do or could make use of certificates as defined by the 
Directory Authentication Framework.  Attendees of this tutorial will have a 
thorough understanding of the technology and will be able to apply it to 
other applications and environments.

Overview

We will examine the Directory Authentication Framework , its technology 
and its key component, certificates, in detail.  Privacy Enhanced Mail, an 
openly available implementation of the technology, will be used to study its 
operational aspects.  Certificates, as used in PEM and defined by the 
Directory Authentication Framework, are expected to be the most widely 
deployed mechanism in support of security services.  Topics include :  
Directory Authentication Framework, Privacy Enhanced Mail,  Privacy 
Enhanced Mail versus Directory Authentication Framework, Message 
Handling Systems Security Services (X.400), Privacy Enhanced Mail, Privacy 
Enhanced Mail versus Message Handling Systems Security, Operational 
Issues

Instructor

James M. Galvin is a Senior COMSEC Scientist at Trusted Information 
Systems, Inc, in Glenwood, Maryland.  Dr. Galvin's responsibilities 
emphasize communications security, especially computer networks, 
architectures, policies, and procedures.  He is a principal in the development 
of TIS openly available implementation of Privacy Enhanced Mail.  He is 
Executive Director of the Internet Engineering Task Force Security Area 
Advisory Group, and Chair of the OSI Implementor's Workshop Security 
Special Interest Group.

TUTORIAL 4  OSF'S DISTRIBUTED COMPUTING ENVIRONMENT (DCE): CONCEPTS AND 
PROTOCOLS    ($265 CDN)

Instructor : David Chappell, Chappell & Associates
Date       : Monday, 25 May 9:00 - 5:00

Who Should Attend

The tutorial is aimed at anyone needing an introduction to DCE. This includes 
those who must implement, support, market, plan for, or write about DCE or 
distributed systems in general. A general knowledge of networking 
fundamentals is assumed, and some background in a high-level programming 
language will be helpful, but is not required. 

Overview

DCE was created by the Open Software Foundation (OSF) as a vendor-
neutral infrastructure for distributed computing. Among the vendors 
promising support for DCE are IBM, Digital Equipment Corporation, Hewlett 
Packard, and many others. DCE is also included in Atlas, the Unix 
International architecture for distributed computing. Running over any 
transport protocol, DCE provides solutions for the key problems in creating 
distributed systems. This tutorial provides an introduction to DCE, with a 
description of each of its component technologies: a protocol for remote 
procedure call, a distributed file system, a directory service, and several 
more. The goal is to give participants an understanding of what services DCE 
provides and of how those services are provided.

Instructor

David Chappell is principal of Chappell & Associates, a training and 
consulting firm focused on vendor-neutral networking. He has written and 
taught many courses on distributed computing and related topics and has 
served as a consultant on numerous communications projects.  He has 
chaired the Upper Layers Special Interest Group of the National Institute of 
Standards and Technology (NIST) OSI Implementors  Workshop from 1988 
until 1990.  

TUTORIAL 5      X.400 / X.500 - WHERE ARE WE TODAY ? ($265 CDN)

Instructor : Erik Skovgaard, PSC (Pacific) Inc.
Date       : Tuesday 26 May 9:00 - 5:00

Who Should Attend

Although this tutorial is technical in nature, anyone with an interest in 
messaging and directory standards can participate.  The emphasis will be on 
the services specified in the standards.  Participants are expected to have a 
basic knowledge of X.400 and X.500 services and architectures.

Overview

This one-day tutorial will provide a brief overview of the CCITT X.400 and 
X.500 recommendations with a particular emphasis on the enhancements 
expected to be approved at the end of 1992.  Several pragmatic issues will 
also be discussed.

Instructor

Erik Skovgaard has been active in X.400 and X.500 from the start.  He 
participated in generating the first North American OSI profile at NIST's 
X.400 SIG where he was active during the first four years of activity.  He 
has been a member of the X.400 API Association and lately also technical 
editor for the standards group. Currently, he teaches and provides consulting 
services to vendors and users of X.400, X.500 and EDI products in both 
North America and Europe.  

TUTORIAL 6  THE "NEW" ASN.1  ($265 CDN)

Instructor :  Bancroft Scott, Open Systems Solutions Inc.
Date       :  Monday, 25 May 9:00 - 5:00

Who Should Attend

The intended audience of this tutorial are those who have an interest in 
ASN.1, its encoding rules, and where they are going.  This is not an 
introductory ASN.1 tutorial, so you will benefit most if you already have 
some knowledge of ASN.1.  The last two hours or so covers the macro 
replacement notation in depth; you will benefit most from this part of the 
tutorial if you have a good understanding of the ANY DEFINED BY and macro 
notations.

Overview

This one day tutorial covers the most significant changes that are occurring 
in the area of ASN.1 and its encoding rules.  You will learn what the 
changes are the reasons behind them, their benefit to you, and how to take 
advantage of them.

Instructor

Bancroft Scott of Open Systems Solutions, Inc. is the ISO editor for ASN.1 
and the encoding rules of ASN.1, as well as the ANSI Packed Encoding 
Rules Project editor.  He has had over 16 years in the software industry, 
with the last 9 years concentrating in data communications.

SOCIAL PROGRAMME
----------------

A number of social events have been planned to give you maximum opportunity to 
meet other delegates.  Events include a wine and cheese reception party for 
delegates and accompanying persons the evening before the conference, a 
traditional West Coast Salmon Barbeque at the UBC Museum of 
Anthropology and an optional evening Harbour Cruise of Vancouver with 
dinner.  In addition, accompanying persons may sign up for conference 
social events as well as 1/2 day tours of Vancouver.

Evening Harbour Dinner Cruise, Wednesday May 27 Cost - $75.00 CDN incl tax

One of the best ways to see Vancouver is from the water.  Vancouver's 
beautiful harbour bustles with activity.  A deluxe motor coach will take you 
to the marina to embark on a scenic cruise.  See Vancouver Harbour, English 
Bay and False Creek,  featuring the city's fabulous skyscape, the North 
Shore Mountains, Stanley Park, miles of beaches and the fjord-like splendor 
of Indian Arm, while enjoying West Coast cuisine.  A cash bar will be 
available for alcoholic beverages.  Cruise is from 7:00 - 10:30 pm.  

Tours for Accompanying Persons

Wednesday, May 27  

CITY OF VANCOUVER TOUR (3 hrs) $CDN 32.00 including taxes.
Multi-lingual commentated tour of beautiful Vancouver.  Get oriented to the 
city.  See Stanley Park and the Vancouver Aquarium, downtown Vancouver, 
and Queen Elizabeth Park's quarry garden and Bloedel Conservatory. 

Thursday, May 28  

GRANVILLE ISLAND TOUR (3 1/2 hrs) $CDN 20.00 including taxes
A vibrant city market place, Granville Island with it's farmers market and 
crafts stores is a local and tourist favorite spot for shopping, 
eating, strolling and people-watching. Tour the Granville Island Brewery and 
sample some beer.

Friday, May 29  

NORTH-SHORE/GROUSE MOUNTAIN TOUR (3 hrs)  $CDN 35.00 including taxes.
An exciting skyride taking you from sea level to 3700 feet at the top of 
Grouse Mountain for a spectacular view of the harbour, city, and Gulf 
Islands.  Then a short journey to the Capilano Suspension Bridge. 

GENERAL INFORMATION 
-------------------

Accommodation

Reasonably priced accommodation for conference delegates is available on 
campus at UBC's Walter Gage Residence.  Within easy walking distance 
from the conference venues, dining and recreation facilities, the 
accommodations are modern self-contained suites.  The single suite includes 
a bedsitting room with single bed and private washroom.  The double suite 
includes a bedroom with double bed, living room and private washroom.  
The deluxe suite consists of a bedroom with twin beds, living room with 
sofa bed, telephone, TV, private washroom and kitchenette.

For delegates preferring to stay off-campus, the Sheraton Inn Plaza 500 
Hotel is providing conference room rates. The Sheraton Inn is a 20 minute
drive or bus ride from the UBC campus. All other Vancouver hotels are located at
least 20 minute drive or bus ride from the conference location.

Fees Include

The conference fee includes all coffee breaks, lunches, wine and cheese 
reception, and salmon barbecue at the UBC Museum of Anthropology.  Also 
included are a conference programme, the pre-print version of papers while 
at the conference and a published edition of the papers to follow after the 
conference,  Space is limited so register early.
Tutorial fees include all coffee breaks, lunches, and handout materials.

Cancellations and Substitutions

Substitutions for conference or tutorials may be made at any time.  There is 
a $50 CDN cancellation fee for conference attendance and each tutorial, 
provided 20 days written notice is given.  
Cancellation of Tours, or accommodation at Walter Gage Residence 
received in writing up to 48 hours prior to check-in date will receive a refund 
minus $15 CDN cancellation fee.  
Hotel and travel cancellations are according to hotel and airline policies.  

Arrival and Departure Times

The conference officially starts with a wine and Cheese Reception from 5:00 
- 7:00 pm on Tuesday, May 26th and finishes at 5:00 on Friday, May 29th.  
Conference presentations begin at 9:00 am each day of the conference. 

Your conference confirmation letter will include information about getting to 
UBC, a campus map, and more detailed programme information.


REGISTRATION
------------

Attached below is the Conference Registration form which includes a request
for Accommodation.

When completing the registration form, indicate which tutorials, or
accompanying persons programmes you wish to sign up for.  Also indicate which 
conference social programmes you will be attending to assist us with catering 
plans.

====================  ULPAA '92 REGISTRATION FORM =====================

TITLE : ________  FIRST NAME :  _________________________________________

LAST NAME :  ____________________________________________________________

COMPANY/INSTITUTION : ___________________________________________________

STREET/P.O. BOX : ________________________________________________________

          _______________________________________________________________

CITY : __________________________ STATE/PROVINCE : ______________________

COUNTRY : ______________________________  POSTAL/ZIP CODE : _____________

PHONE : _____________________________ FAX : _____________________________

DIETARY RESTRICTIONS : __________________________________________________

CONFERENCE and TUTORIAL EVENTS
                                                  Please indicate   Price

ULPAA '92 Conference Registration (Before April 24)         ______   $325

ULPAA '92 Conference Registration (After April 24)          ______   $360

Tutorial 1 Practical Perspectives on OSI Networking (2 days)______   $390

Tutorial 2 OSI Security Techniques & Standards              ______   $265

Tutorial 3 Secure Communications Using X 500                ______   $265

Tutorial 4 OSF's DCE:  Concepts & Protocols                 ______   $265

Tutorial 5 X.400 / X.500 - Where are we Today ?             ______   $265

Tutorial 6 ASN.1                                            ______   $265

Wine and Cheese Reception - Tuesday, May 26                 ______   free

Evening Harbour Cruise & Dinner - Wednesday, May 27         ______    $75

Salmon BBQ Dinner - Thursday, May 28                        ______    free

                            DELEGATE REGISTRATION SUBTOTAL  ______

ACCOMPANYING PERSONS PROGRAMME EVENTS                      Number     Price

Tour 1 City of Vancouver - Wednesday, May 27               _______    $32

Tour 2 Granville Island Tour - Thursday, May 28            _______    $20

Tour 3 North Shore - Grouse Mountain - Friday, May 29      _______    $35

Salmon BBQ Dinner - Thursday, May 28                       _______    $35

Evening Harbour Cruise & Dinner  - Wednesday, May 27       _______    $75


                       ACCOMPANYING PERSONS SUBTOTAL       _______


                TOTAL AMOUNT ENCLOSED FOR EVENTS            _________

MAKE OUT A CHEQUE, BANK DRAFT OR MONEY ORDER FOR THE TOTAL AMOUNT IN 
CANADIAN DOLLARS to ULPAA '92 and mail it with this form to :

          ULPAA '92 IFIP CONFERENCE SECRETARIAT 
          5961 Student Union Blvd 
          Vancouver, B C 
          CANADA
          V6T 2C9  

NOTE: Accommodation must be requested and paid for separately below.

Terms and Conditions

All fees are in Canadian funds including all applicable taxes.
Please make your cheque, bank draft, or money order payable to ULPAA '92
Credit card payments cannot be accepted for registration fees.
Queries regarding conference registration should be addressed to the 
ULPAA '92 IFIP Conference Secretariat.  Tel .: (604) 822 - 1050  
                                        FAX :  (604) 822 - 1069

-- REQUEST FOR ACCOMMODATION - WALTER GAGE COMPLEX - UNIVERSITY OF BC------

                                                                 Rate/Night
Single room (single bed) ..........................................$47.00
Suite (double bed)................................................ $63.00
Deluxe suite (twin beds; living room.............................. $80.00
with TV, telephone, sofa-bed; kitchenette)
(All rates quoted in Canadian Funds and subject to applicable taxes).

If requesting a Suite, please complete the following:

NUMBER OF ADULTS _____________ NUMBER OF CHILDREN _____________

A one-night deposit is required ($47.00, $63.00, or $80.00 CDN)

I authorize a one night room deposit for $ __________________  

by: (circle one)      VISA  MASTERCARD  or enclosed BANK DRAFT   
                                       (payable to UBC Conference Centre)

CARD NO.: ____________________________________ EXPIRY DATE : ____________

CARDHOLDER NAME: _______________________________________________________

CARDHOLDER SIGNATURE : _________________________________________________
                                      For office use only : HAL #G20519A

Terms and Conditions for Accommodation

Payment in full due in Canadian funds at check-in by cash, traveller's 
cheques, VISA, or MasterCard (no personal cheques). 
Cancellations received in writing up to 48 hours prior to check-in date 
will receive a refund minus $15.00 cancellation fee. 
Queries regarding accommodation should be addressed to the UBC Conference
Centre, Reservations Office.  Tel:  (604)822-1010.  Fax:  (604)822-1001.

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

ALTERNATE ACCOMMODATION
-----------------------

SHERATON INN PLAZA 500 (20 minute drive from UBC campus)
500 West 12th 
Vancouver, B.C.			

TOLL FREE NUMBER: 1-800-325-3535 (USA and Canada only)
TEL             : (604) 873-1811

CONFERENCE RATE: $88.00 Per Night single or double occupancy
RESERVATION ID : IFIPS92 Conference

The hotels below do not have IFIP Conference Rates.  They are provided
to give you a sample of hotels and prices available in the Vancouver area.
All of them are located about 20-30 minutes from the UBC Campus.

RAMADA VANCOUVER CENTER
(604) 872-8661
898 West Broadway
Vancouver, B.C
$95.00 PER NIGHT
RATING:  AAA-3 Diamonds

HOLIDAY INN-CENTRE
(604) 879-0511
711 West Broadway
Vancouver, B.C.
$125.00 PER NIGHT
RATING:  AAA-3 Diamonds

DELTA PLACE
(604) 687-1122
645 Howe Street
Vancouver, B.C.
$205.00 PER NIGHT
RATING: Five Stars

WESTIN BAYSHORE
(604) 682-3377
1601 West Georgia Street
Vancouver, B.C. 
$190.00 PER NIGHT
RATING:  AAA-4 Diamonds

PAN PACIFIC HOTEL
(604) 662-8111
300 999 Canada Place
Vancouver, B.C.
$250.00 PER NIGHT
RATING:  AAA-5 Diamonds



-- 
Jim Robinson
robinson@mdivax1.mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson


-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      5 May 92 02:03:27 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

Please forgive my posting rather than mailing this, but Mr. Subramaniam
does not appear to be mailable from here.

In article <6200047@hpindda.cup.hp.com> subbu@hpindda.cup.hp.com (MCV Subramaniam) writes:
>    We found this  problem a couple of years ago at HP, on all 4.3 BSD based
>    machines (4.2 worked  correctly).  The problem  happens  because 4.3 TCP
>    does not  treat  crossing  SYNs  correctly  (i.e.  if TCP_A  sends a SYN
>    request  to TCP_B  and TCP_B  does  likewise,  and the SYNs  cross  each
>    other).

I am curious about this statement, because according to my reading of pre-Tahoe
BSD releases, it was they (i.e., 4.2 and early 4.3 systems) that had the
bug relating to crossing SYNs.  If one of those received a SYN when in
SYN_SENT state, they always assumed that the ACK field was valid.
Of course, it normally would be (because the received segment would normally
be a SYN ACK segment), but in the case of crossing SYNs it would not.

However, as I say, this bug existed in the old code, and was fixed in
Tahoe (and SUN has picked up the fix), which is backwards from the way
described above.  Hence, my confusion.  Did you have another bug in mind?

-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      5 May 92 06:51:03 GMT
From:      solensky@animal.clearpoint.com (Frank T. Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re: Transfer rate for large messages (Ethernet)

In article <1992May04.191429.13117@CS.ORST.EDU> nedeljn@flint.cs.orst.edu (Nenad Nedeljkovic - Nesha) writes:

   I am writing an application across an Ethernet based network of Sun 
   sparcstations using TCP sockets. I have trouble explaining following 
   experimental results:

   Time to send 1Kbyte message from one workstation to another = ~1ms  (OK)
   Time to send 5Kbyte message from one wotkstation to another = ~5ms  (OK)
   Time to send 10Kbyte message from one wotkstation to another = ~100ms (???)

   My only guess is that there are more collisions for large messages but I
   would not expect such degradation of performance.

That would be one factor.  Another possibility is that the 10 KB message
exceeds your TCP window size ( 8 KB default? ), so that you have to have the
beginning portion of your message ACKed before you can finish moving the
message down into the kernel and complete the procedure call  (I'm assuming
that you're measuring the amount of time for a send() call to complete rather
than looking at time it takes for the message to actually be sent and
acknowledged).


--
				-- Frank Solensky / Clearpoint Research
Red Sox magic number: 144

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 5 May 1992 10:00:04 CET
From:      <MPACE@ESOC.BITNET>
To:        comp.protocols.tcp-ip
Subject:   Reliable broadcast

Hi netters, I have started an activity to design and implement a reliable
broadcast layer using UDP.

I would like to know if some of you has any experience with such protocols
providing me with inputs such as:
- reference material I can look at in order to understand the issues related
  with this kind of protocols, possible solutions, practical experiences, etc.
  (including fault-tolerance issues related with that).
- you personal experience with the design and the implementation of such
  protocol, problems encountered, suggestions, etc.

The reliable broadcast protocol I have to design and implement will be used
in a system where near real-time broadcast of data is needed, and reliability
of delivery is necessary for some components of the system.

Any info will be appreciated. Cheers.

-------------------------------------------------------------------------
Marco Pace, Software Engineer
ESOC, Robert-Bosch-Strasse 5, D-6100 Darmstadt, Germany
E-mail: MPACE@ESOC.BITNET
Voice:  +49 (0)6151 903065
Fax:    +49 (0)6151 904065
-------------------------------------------------------------------------

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 May 1992 12:00:31 GMT
From:      peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: Transfer rate for large messages (Ethernet)

solensky@animal.clearpoint.com (Frank T. Solensky) writes:

>In article <1992May04.191429.13117@CS.ORST.EDU> nedeljn@flint.cs.orst.edu (Nenad Nedeljkovic - Nesha) writes:
 
>   I am writing an application across an Ethernet based network of Sun 
>   sparcstations using TCP sockets. I have trouble explaining following 
>   experimental results:
 
>   Time to send 1Kbyte message from one workstation to another = ~1ms  (OK)
>   Time to send 5Kbyte message from one wotkstation to another = ~5ms  (OK)
>   Time to send 10Kbyte message from one wotkstation to another = ~100ms (???)
 
>   My only guess is that there are more collisions for large messages but I
>   would not expect such degradation of performance.
 
>That would be one factor.  Another possibility is that the 10 KB message
>exceeds your TCP window size ( 8 KB default? ),

I wonder if this is an interaction with delayed acks and the Nagle
algorithm - isn't the default ack delay 100mS for some implementations?
It would be very helpful to see a more complete graph of performance
versus message size - I strongly doubt that there is a simple trend here
that can be captured with three data points. More details on how you
measured things would be useful, as well.

[see January IEEE Communications, "Layering Considered Harmful" or
something like that, for what may be a similar problem. The figures to
the article (without which it doesn't make sense) are I think in the
March issue.]

				Peter Desnoyers
-- 

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 May 1992 12:48:41 GMT
From:      mishkin@apollo.HP.COM (Nathaniel Mishkin)
To:        comp.protocols.tcp-ip
Subject:   Re: "Connected" UDP

In article <1992May01.192255.22236@catfish.az05.bull.com>, djschoff@cibecue.az05.bull.com (Daniel J. Schoffelman) writes:
>...
>He also says that a connected UDP socket can do a read() and recv()
>request without needing to know where it came from.

I don't have the book so I don't know if it mentions that another property
of connected UDP sockets is that UDP datagrams arriving at the socket
that are not *from* the address to which the socket is connected are
automatically discarded (i.e., not enqueued on the socket).

>...
>(Does anybody know of real uses of connected UDP sockets?)

Well if it weren't for the above property, *I'd* be using them (in my
RPC implementation) because at least the last time I did the measurements,
doing a send() on a connected UDP socket was significantly faster than
doing a sendto() on an unconnected socket.  (I think this has to do with
the fact that sendto() is layered on send(), not vice versa, as I had
guessed it would before I actually looked at the code.)

-- 
                    -- Nat Mishkin
                       Distributed Object Computing Program / East
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 May 1992 17:55:39 GMT
From:      bradley@mdd.comm.mot.com (Michael Bradley)
To:        comp.protocols.tcp-ip
Subject:   VMTP status

Would like to know the status both as a standard
and implementations of VMTP (Versatile Message
Tranaction Protocol - RFC 1045).
 
 Thanks
   Michael Bradley



-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      5 May 1992 14:46:06 +0200
From:      wolf@grasp1.univ-lyon1.fr (Christophe Wolfhugel)
To:        comp.sys.sun.wanted,comp.protocols.tcp-ip
Subject:   Cheating with IP routing

I'd like to have a service similar to IP analysers that exist under SunOS,
but with some particularities:

- instead of doing analysis I wish to have a socket interface (or socket like)
  for applications to bind with the traffic (TCP or UDP),

- the IP layer should consider all traffic arriving (with the MAC
  address of the Sun) as local, and thus give it to the applications instead
  of rerouting it properly,

- applications should be able to get the destination address of a datagram,
  or be able to retrieve it for a stream socket with either a modified
  accept() or a new system call.

Do such packages/functionnalities exist? Please respond by email, I'll
summarize for the net if there is interest.

-- 
Christophe Wolfhugel      | "X.400: An introduction to snail-email", available
wolf@grasp1.univ-lyon1.fr | soon in all good bookstores!

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      5 May 92 18:47:39 GMT
From:      gentry@predator.engin.umich.edu (Denton Gentry)
To:        comp.protocols.tcp-ip
Subject:   Re: Transfer rate for large messages (Ethernet)


In article <peterd.705067231@pjd.dev.cdx.mot.com>, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
> 
> >In article <1992May04.191429.13117@CS.ORST.EDU> nedeljn@flint.cs.orst.edu (Nenad Nedeljkovic - Nesha) writes:
 
> >   Time to send 1Kbyte message from one workstation to another = ~1ms  (OK)
> >   Time to send 5Kbyte message from one wotkstation to another = ~5ms  (OK)
> >   Time to send 10Kbyte message from one wotkstation to another = ~100ms 
> >That would be one factor.  Another possibility is that the 10 KB message
> >exceeds your TCP window size ( 8 KB default? ),
> 
> I wonder if this is an interaction with delayed acks and the Nagle
> algorithm - isn't the default ack delay 100mS for some implementations?
> It would be very helpful to see a more complete graph of performance
> versus message size - I strongly doubt that there is a simple trend here
> that can be captured with three data points. More details on how you
> measured things would be useful, as well.
>
> 				Peter Desnoyers
> -- 

  In 4.3 BSD ACKs are delayed until either 35% of the window has filled 
or 200 ms have passed. This could be a factor. There is some discussion of 
the effect of delayed ACKs on throughput in Van Jacobsen's paper 
_Congestion_Avoidance_and_Control_. Specifically look at figure 9 for a 
graph of throughput where the receiver is using delayed ACKs vs a 
receiver sending immediate ACKs.

Denny Gentry
University of Michigan

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 May 1992 18:47:52 GMT
From:      barrydm@dryden.dfrf.nasa.gov (Mark Barry)
To:        comp.protocols.tcp-ip
Subject:   Who Uses QUICK MAIL?


I'm just curious about who uses Quick Mail.  If your site does, please
respond to me directly at:

barrydm@dryden.dfrf.nasa.gov


- Mark Barry
NASA/Edwards AFB

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 May 1992 20:13:17 GMT
From:      wrk@icd.ab.com (Wm. R. King)
To:        comp.protocols.tcp-ip
Subject:   How to contact the NIC?

How do you contact the NIC when you can't send them mail. This is what happened
today.

From Mailer-Daemon@nic.ddn.mil  Tue May  5 16:03:44 1992
Date: Tue, 5 May 92 16:02:15 EDT
From: Mailer-Daemon@nic.ddn.mil (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
To: <wrk@icd.ab.com>
Content-Length: 4005

   ----- Transcript of session follows -----
554 <hostmaster@nic.ddn.mil.>... Mail loop detected
554 sendall: too many hops (30 max)

   ----- Unsent message follows -----
Return-Path: <wrk@icd.ab.com>
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27638; Tue, 5 May 92 16:02:15 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27635; Tue, 5 May 92 16:02:13 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27632; Tue, 5 May 92 16:02:12 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27626; Tue, 5 May 92 16:02:10 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27623; Tue, 5 May 92 16:02:09 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27620; Tue, 5 May 92 16:02:08 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27617; Tue, 5 May 92 16:02:06 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27614; Tue, 5 May 92 16:02:04 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27606; Tue, 5 May 92 16:02:02 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27602; Tue, 5 May 92 16:01:58 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27599; Tue, 5 May 92 16:01:56 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27596; Tue, 5 May 92 16:01:55 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27591; Tue, 5 May 92 16:01:53 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27588; Tue, 5 May 92 16:01:52 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27585; Tue, 5 May 92 16:01:51 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27581; Tue, 5 May 92 16:01:50 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27576; Tue, 5 May 92 16:01:49 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27568; Tue, 5 May 92 16:01:46 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27565; Tue, 5 May 92 16:01:45 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27562; Tue, 5 May 92 16:01:44 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27558; Tue, 5 May 92 16:01:43 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27555; Tue, 5 May 92 16:01:41 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27549; Tue, 5 May 92 16:01:40 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27546; Tue, 5 May 92 16:01:36 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27542; Tue, 5 May 92 16:01:34 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27536; Tue, 5 May 92 16:01:32 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27532; Tue, 5 May 92 16:01:31 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27529; Tue, 5 May 92 16:01:29 EDT
Received: from NIC.DDN.MIL by nic.ddn.mil (4.1/SMI-4.1)
	id AA27521; Tue, 5 May 92 16:01:27 EDT
Received: from odin.icd.ab.com by nic.ddn.mil (4.1/SMI-4.1)
	id AA27517; Tue, 5 May 92 16:01:23 EDT
Received: from siskin.icd.ab.com by odin.icd.ab.com (4.1/CIS-2.12)
	id AA11977; Tue, 5 May 92 16:02:45 EDT
Date: Tue, 5 May 92 16:02:45 EDT
From: wrk@icd.ab.com (Wm. R. King)
Message-Id: <9205052002.AA11977@odin.icd.ab.com>
To: hostmaster@nic.ddn.mil.
Subject: nameserver update for AB.COM

<messaged deleted>



Thanks for the help!
Bill King




-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 May 92 22:02:05 GMT
From:      djschoff@cibecue.az05.bull.com (Daniel J. Schoffelman)
To:        comp.protocols.tcp-ip
Subject:   Re: "Connected" UDP

In my original posting, my main question concerned the concept of
"connected" UDP fds in the TLI/XTI world.  There is really no such
concept in this world, in my reading of the specs.

On systems implemented on top of STREAMS, how is the concept of
connected UDP implemented, if you chose to put Sockets on top of
this?  I assume this has been done already in System V.

I can find no reference to the concept of "connected" UDP in the UDP
standards, at least not in the RFCs.  If, as W. Richard Stevens says
in "UNIX Network Programming", an ICMP message must be sent back on
receipt of a datagram to a connected UDP socket (in the case the sender
is not one of the connectees), how is this done?

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Tue,  5 May 92 13:20:45 +0700
From:      kondrat@inpbox.inp.nsk.su (Igor V. Kondratiev)
To:        comp.protocols.tcp-ip
Subject:   LPR from VAX/VMS to System V(WIN TCP & priveleged sockets)

Hi, folks!

Help me to resolve a problem, please:

I'm attempting to port NCSA's LPR-client from DOS to VAX/VMS.
So, I didn't found any tools in WIN TCP/IP to create privileged (<1023) socket.
I suppose because of that lack LPD server on System V (running on AT-386SX)
refuses to talk with client.

 Immediately after the call of connect(...), netstat shows the socket state
FIN_WAIT_2. Server closes connection after the very first command "\2lp\n"
with a message "Malformed from address".

Have anybody any opinions or skills to resolve this situation?

Thanks in advance, Igor V. Kondratiev




-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      6 May 92 01:16:11 GMT
From:      matthews@mis.uswest.com (John Matthews)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Printing for SNA,NOVELL,TCP/IP,APPLETALK

Can anyone give me any good ideas or strong recommendations for existing
products that would allow people in different environments to share
printers?  The big question that we're getting alot is "How can I
print jobs from the Mainframe to a LAN printer at a remote site?"

I am aware of a product from Novell that will allow Appletalk,TCP/IP
and Novell printers to be shared.  Can anyone tell me how stable it is
in a production environment?  Can you easily spool jobs from
Novell<-->UNIX, Novell<-->Appletalk, and UNIX<-->Appletalk?

I don't know a whole lot about SNA attached printers, but they're what
we need to provide.  What are good strategies for setting up printing
with this Novell software?  Someone was telling me that with the
source-route bridging (via Cisco) and AttachMate, I can define a
virtual printer that is locally attached to a PC and then redirect
LPT1 to a Novell printer.  Is anyone doing this and if so, is it stable?
Has anyone thought of other ways of providing mainframe printing?
I should also mention that they primarily want to use the LAN printers
for short printouts.

Does anyone know if McData provides SNA<-->TCP/IP printing yet?  Is it
stable?

				Thanks in advance,
					John Matthews
					matthews@mis.uswest.com

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      6 May 1992 07:54:09 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: "Connected" UDP

In article <1992May05.220205.12800@catfish.az05.bull.com> djschoff@cibecue.az05.bull.com (Daniel J. Schoffelman) writes:
>I can find no reference to the concept of "connected" UDP in the UDP
>standards, at least not in the RFCs.  If, as W. Richard Stevens says
>in "UNIX Network Programming", an ICMP message must be sent back on
>receipt of a datagram to a connected UDP socket (in the case the sender
>is not one of the connectees), how is this done?

You won't find anything about this in the RFC's, because they don't concern
themselves with application program interfaces, only the protocol that goes
out over the network.  The concept of "connected" UDP is purely an artifact
of a programming model, and doesn't affect the protocol.  The host
receiving a UDP datagram doesn't know whether it was sent from a connected
or unconnected socket.  The ICMP Port Unreachable should *always* be sent
when there is no process listening on the destination port.  The only
relationship between this and connected sockets is that the original UDP
sending host will usually just ignore the ICMP response if there's no
connected socket, since there's nothing useful to do with it.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 May 1992 09:59:40 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: "Connected" UDP

mishkin@apollo.HP.COM (Nathaniel Mishkin) writes:

.....

>I don't have the book so I don't know if it mentions that another property
>of connected UDP sockets is that UDP datagrams arriving at the socket
>that are not *from* the address to which the socket is connected are
>automatically discarded (i.e., not enqueued on the socket).
 
>Well if it weren't for the above property, *I'd* be using them (in my
>RPC implementation) because at least the last time I did the measurements,
>doing a send() on a connected UDP socket was significantly faster than
>doing a sendto() on an unconnected socket.  (I think this has to do with
>the fact that sendto() is layered on send(), not vice versa, as I had
>guessed it would before I actually looked at the code.)


I've changed SunRPC 4.0 clnt_udp.c in such a way that it uses connect()/send()
when possible. This has given us much approved NIS recovery (seconds,
rather than minutes). The SunRPC mechanism will always reply from
the port the messages was originally send to, but the host address
might be different in the case of multihomed hosts. I've had to
adopt the code to something plausible in that case. The problem is
that the socket UDP model (and probably the TLI model, as well) has
no provision to ask for the local destination (as getsockname() does for
connected TCP/IP sockets). This makes it impossible to use that
address as the source address in a reply. Named and ntpd work around this
problem binding to one socket for each IP interface. This only works
when the daemons are started after configuring all the interfaces
but that is not always the case.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 May 92 13:07:35 GMT
From:      morss@eksignal.kodak.com (Charlie Morss)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   FTP protocol

I'm looking for the FTP protocol. We need to implement
an FTP server/client on a 680x0 system and will probably 
be doing it from scratch, any help would be greatly appreciated.


Thanks,

-Charlie
-- 
-----------------------------------------------------------------
Charlie Morss                               Voice: (716) 726-5461
morss@eksignal.kodak.com                      Fax: (716) 726-4850 
-----------------------------------------------------------------

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      6 May 92 13:44:02 GMT
From:      craven@kira.msu.edu (Dean Craven)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Looking for net simulation/testing software

Are there any software packages (commercial or free) which would be useful
for testing network devices and TCP/IP protocol implementations?  Our
needs seem to fall into two categories:

 1) network analysis (packet capture and decode) AND simulation (packet
    editing and error/load simulation)

 2) testbeds to test protocol implementations like the TCP/IP suite

We are aware of the typical net analyzers (Sniffer, Lanalyzer, FTP
Software's product).  These products don't seem to provide much simulation
or error generation capability.  We are also looking into some "high-end"
net analyzers (Tekelec "Chamelan 100" and Wandel & Goltermann "DA-30") which
do provide some simulation function.  We are wondering if there are any
software products (which don't require proprietary specialized hardware)
that could be used to simulate arbitrary network traffic/error conditions
and (perhaps in a separate package) provide protocol testing capabilities.

Please respond via email.  Thanks.

-----------------------------------------------------------------------------
Dean Craven					craven@egr.msu.edu
Michigan State University			...!uunet!frith!craven
-----------------------------------------------------------------------------

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      6 May 92 16:34:00 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable broadcast

An interesting problem. You didn't post enough information to know
just how to solve the problem. Many of these ideas depend on the
semantics of the data you're sending, which maybe tells you why
there's no standard for doing "reliable broadcast."  The following is
a list of things to think about when constructing your protocol...

  Broadcast UDP vs TCP:

Don't focus on doing broadcast until you've clearly identified your
communication requirements. Maybe broadcast will be the most
efficient, but don't start with that assumption.  Instead, look at the
communication and reliability requirements and what they'll do to your
message traffic.

Also keep in mind that TCP has been subjected to all sorts of
engineering hacks to deal with transmission unreliability and host to
host flow control. If you plan to use as much network bandwidth as
possible you might want to just use TCP rather than try to reinvent
it.

  How do you detect lost messages:

To send a message reliably you need an acknowledgement from the
recipient. This means you need a list of recipients whether you're
using broadcast or not. Part of your protocol will need to determine
which hosts are expecting to receive messages.

  How do you handle lost messages:

This depends on how the system interprets its data. Usually you need
to do retransmissions, though there are special cases depending on the
semantics of the data.

In some systems, each message simply updates some information, so the
data in the latest message makes previous information irrelevant.
Thus, you can time-stamp your messages and either retransmit them or
replace them with later data when messages get lost. A variant would
be to establish a broadcast schedule and just transmit the latest
data periodically regardless of whether it has changed or not. Then
you never really retransmit, though you might broadcast in cases
where you didn't really need to.

  Flow Control:

You need a way to insure that the sender isn't going to send too much
data for the recipients to handle. In UDP you don't know if the
message was lost because of a network glitch or because the recipient
was too busy to receive it. If the sender is sending data too fast,
then the retransmissions are going to make things worse, not better.
Depending on your application, this could be a good reason to use TCP
instead of broadcast UDP.

  How do you handle duplicate messages:

When you retransmit a message, you might be dealing with a lost
acknowledgement. Thus, the recipient will get two copies of the
message. You can usually use timestamps or serial numbers to detect
duplicate messages.

In some systems, each message is an "event" that may cause a
transition in a state machine. If so, you should design your state
machines to tolerate multiple messages indicating the same event.
This makes your state machine part of the protocol, which might be a
good idea if the state machine is designed to trigger on datagrams
anyway.

The worst case is if the system can't tolerate either duplicates
or lost messages. The system depends on a clean, unambiguous
stream of data. If this is true, then you'll probably do best
by discarding the broadcast UDP idea and simply implementing
a TCP oriented service.

  How do you detect recipients that have died:

Once in a while one of your processors will crash. The broadcasting
program needs to handle the case when the dead processor was one
that required reliable transmission.

  Most of protocol design consists of getting the error cases to work
correctly. Be sure to look at cases where communications suffer
serious failures and insure that the protocol software can recover
without making things difficult for the rest of the network.

Rick.
smith@sctc.com          arden hills, minnesota

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      6 May 92 16:46:51 GMT
From:      Dean.Roth@mixcom.mixcom.com (Dean.Roth)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Any experience with AIX, X.25 *and* SLIP?


I am considering having remote PCs communicate with
an AIX host via an IP stream over SLIP and an X.25 connection.

Is anyone doing this?
Is it reliable?
Any hints or cautions you wish to share?

Thank you.

Dean

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 May 1992 17:43:23 GMT
From:      les@chinet.chi.il.us (Leslie Mikesell)
To:        comp.dcom.lans.ethernet,comp.protocols.tcpip
Subject:   Re: PCRoute: 10baseT and Novell questions

In article <1992May4.172146.2128@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:

>>	2) what does it do with the Novell packets in a mixed
>>	   Novell and Unix environment?
 
>Ignores them. Otherwise, I'd have a few boxes set up with it.

But there is code to support bridging as well - if you aren't all TCP/IP
why not just bridge the segments?  Broadcast packets should be the
only thing that might be forwarded in error when you base the decision
on the ethernet address.

Les Mikesell
 les@chinet.chi.il.us

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      6 May 92 20:56:59 GMT
From:      pstevens@Metaphor.COM (Paul Stevens)
To:        comp.protocols.tcp-ip
Subject:   Use of well known ports

I am looking into what it would take to port an XNS based application
to TCP/IP.  This is a heavily distributed application that makes liberal
use of well known ports for both broadcasting information and for locating
various services.

Presumably, I could use well known TCP/IP ports either from the 512-1023
range (i.e. privilledged ports) or from the range >5000.  However,
how can I be assured that other applications will not use these ports?
How do other applications solve this problem?  Do they let the choice
of the well known port(s) be configured by each site into /etc/services
(or its non-Unix equivalent)?

Also, is there any generic equivalent to the Sun-RPC portmapper daemon.
That is, a service that can be used to discover what port a non-RPC based
service is using?

Thanks for any insight you can provide.

+------------------------------------------------------------------------+

   Paul Stevens                        {apple|decwrl}!metaphor!pstevens
   Metaphor Computer Systems           pstevens@metaphor.com
   Mountain View, CA

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 May 1992 00:36:43 GMT
From:      jbartas@telebit.com (John Bartas)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Re: Looking for net simulation/testing software

In article <1992May6.134402.11477@msuinfo.cl.msu.edu> craven@kira.msu.edu (Dean Craven) writes:
>Are there any software packages (commercial or free) which would be useful
>for testing network devices and TCP/IP protocol implementations?  Our
>needs seem to fall into two categories:
>
> 1) network analysis (packet capture and decode) AND simulation (packet
>    editing and error/load simulation)
>
> 2) testbeds to test protocol implementations like the TCP/IP suite
>

	I have been looking for Beta sites for just such a software
package. I call it Lantest, and I wrote it when I was a consultant doing
lots of NDIS and Packet Drivers. Lantest is designed to exersize and help
debug these drivers & the underlying hardware. I would like to release Lantest
to the Public Domain (Under FSF's "Copyleft" agreement), but have been 
slowed up by two things:

1) Lantest is largly untested outside my lab - thus I would like to
release it to a few sites that would provide helpfull feedback before
doing a general release. No point in publicly embarassing myself :-)

2) I need someone to donate FTPable disk space for it, so I can tell 
people where to get it.

	Lantest's main function is to generate network traffic in a 
variety of controled ways to stress the driver software and the
underlying media. It will also capture packets and display the
hex, but does not do any sophisticated protocol analysis - Netwatch
is more usefull for that. Lantest is designed to work over any device
that can xfer datagrams & supports some sort of broadcast capability. It
is protocol independant, however it should be trivial to adapt it to run
on a Netbios or UDP/IP stack.

	Lantest is available as an MS-DOS zip file of about 300K. This 
includes all sources and the user manual. Hardware requirements are at least
2 PCs (can use up to 26 for really complex tests) Ethernet or Token
ring hardware, and either NDIS or Packet Drivers for your hardware.

	Anyone who would like to try this out, or for more detailed info,
contact me:

jbartas@telebit.com

or call (408) 257-3414 (my home office) between 9am-9pm California
time.

-JB-

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
John Bartas  | "We have met the enemy, and he is us". -Pogo
jbartas@telebit.com  - These are my opinions, not my employer's.


-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 May 1992 01:07:54 GMT
From:      bms@bdt.com (Vance Chin)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Are Interlan NTS-10's worth using?


	I have access to some NTS-10's.  My friend wants to use them
with a sun running sun os 4.1.1.  Are these boxes obsolete? (circa 1984)
Can they be upgraded with new roms?  What protocols does it speak? Do
you need one?

Thanks in advance...

Vance Chin

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 May 92 01:15:29 GMT
From:      yohan@picasso.cssc-syd.tansu.oz.au (Yohan Jeevaratnam)
To:        comp.protocols.tcp-ip
Subject:   Socket options under TLI

Hello world,
				I am trying to use the Transport Layer Interface(TLI) provided by SunOs, with a tcp/ip  underlying protocol suite. 
				Most of the TLI calls seem to work fine ( though there are a couple of exceptions), however the problem I've encountered is that I would really like to set some socket options. In the tcp/ip paradim I would use "setsockopt", however with TLI I can`t see any documentation on how to toggle socket options through the TLI interface.
				If anyone has any knowledge on this I would very keen to here from you.
				Thank You
						Yohan
 _--_|\   Yohan Jeevaratnam							yohan@tansu.oz.au
/      \  Customer Application R&D                   Phone: +612- 395 3216
\_.--._/  Integrated Network Products Unit           Fax  : +612- 395 3225  
      v   Telecom Australia, Sydney, Australia.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 May 1992 04:03:03 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: Negative ping times


This condition represents the pingultimate in data transfer.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 7 May 1992 09:53:31 EDT
From:      Peter M. Weiss <PMW1@psuvm.psu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: Any list's of NICs

In article <1992May7.120116.15980@linus.mitre.org>, dkb@bistromath.mitre.org
(Daryl K. Baker) says:

>Does any one have a list of Network Information Centers, preferable
>one that includes NICs of foreign and international nets.

I just did a quickie WHOIS NIC at the nic.ddn.mil.  There were 243
"hits".  Also, another search argument might be NIS.

/Pete
--
Peter M. Weiss                     | not affiliated with psuvm.psu.edu|psuvm
31 Shields Bldg - PennState Univ.  | "Connectivity is more than a Connection"
University Park, PA USA 16802-1202 | E. Michael Staman, _The Circuit_, Apr 92

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      7 May 92 11:11:17 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   ip over token-ring

Recently, Martin McCormick (u1906ad@unx.ucc.okstate.edu) asked about any
publically available software which is capable of sending IP packets
over token-ring.

First, if you mean "public domain", I don't know of any.

However, there are a couple of (possible) solutions which may be of some
use:

1. LAN WorkPlace for DOS (version 4.0), from Novell.  Once you load the
ODI driver for your token-ring board, you load in the other necessary
software in more-or-less this order (sorry, my cubicle is packed up for
a move, so the docs aren't handy):  LSL.COM (Link Service Layer), the
MLID (Multiple-Link Interface Driver - in my case, NI6510.COM for my
Racal-Interlan NIC), IPXODI.COM (IPX interface), and NETx.COM (for
Novell).  Somewhere in this stack you load IPTUNNEL.COM, which (if I
recall) will encapsulate your IPX packets inside of IP packets, before
they even leave your workstation.  You'll need at least NetWare v.3.11
to get set up - that is, if you want your Novell fileserver to unwrap it
at the other end....

2. Again, Novell NetWare 3.11.  You should also be able to set up an XT
with 2 NICs one for Ethernet and one for token-ring.  Set this box up as
a (I believe Novell calls it a remote bridge, but it'll likely behave as
a router) system to interconnect token-ring to Ethernet.

Now, I'm making a heck of a lot of assumptions here, based of the very
basic nature of the original question.  Apologies if I'm just wasting
bandwidth.

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      7 May 1992 06:14:05 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Use of well known ports

In article <2176@cronos.metaphor.com> pstevens@Metaphor.COM (Paul Stevens) writes:
>Presumably, I could use well known TCP/IP ports either from the 512-1023
>range (i.e. privilledged ports) or from the range >5000.  However,
>how can I be assured that other applications will not use these ports?
>How do other applications solve this problem?  Do they let the choice
>of the well known port(s) be configured by each site into /etc/services
>(or its non-Unix equivalent)?

I think that's a common solution.

>Also, is there any generic equivalent to the Sun-RPC portmapper daemon.
>That is, a service that can be used to discover what port a non-RPC based
>service is using?

While the portmapper uses RPC to communicate (with both the servers
requesting that a port be assigned and the clients that want to find out
what port was assigned to a server), there's no requirement that the
application protocol be RPC-based.  Your server simply requests a port from
the portmapper and then uses the ordinary mechanisms for binding to the
port.  And clients query the portmapper for the port and then use an
ordinary connect call to that port.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      7 May 92 10:15:33 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.protocols.tcp-ip
Subject:   VT5250 terminal and TCP/IP terminalserver in connection with AS400?


Hey guys !
We have a large network based on TCP/IP! Now I would like to
know if a terminalserver exists which allows me to connect a
VT5250 terminal (twin ax) to. In our network we have an AS400
equipped with IBMS TCP/IP and an ethernet card. Additionally we have
12 VT5250 terminals. It would be nice to use the VT5250 terminals
in connection with a terminalserver, so that we can connect to our
AS400 from different places in the network! We did not find a terminalserver
which offers this possibility yet!

Any help would be appreciated!
-- 
------ < MAGIC > ------

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      7 May 92 10:17:42 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.os.os2.misc,comp.os.os2.networking,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   OS2 and VT5250 emulation ?


Hi guys !
I would like to know if there is an VT5250 emulation for OS2 out there.
We have a large network based on TCP/IP including AS400, PC's,
a MVS host, and different kinds of unix workstations. It would be nice
to connect from a PC with OS2 directly to a AS400. I read the deskription
of the IBM's TCP/IP package and could not find a VT5250 emulation !

Any information would be appreciated!
-- 
------ < MAGIC > ------

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 May 1992 12:01:16 GMT
From:      dkb@bistromath.mitre.org (Daryl K. Baker)
To:        comp.protocols.tcp-ip
Subject:   Any list's of NICs

Does any one have a list of Network Information Centers, preferable
one that includes NICs of foreign and international nets.

Thanks
Daryl Baker
dkb@mitre.org

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 May 1992 15:29:14 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Use of well known ports

In article <2176@cronos.metaphor.com> pstevens@Metaphor.COM (Paul Stevens) writes:
>How do other applications solve this problem?  Do they let the choice
>of the well known port(s) be configured by each site into /etc/services
>(or its non-Unix equivalent)?

You might want to look at RFC 1078, "TCP Port Service Multiplexer".
Won't work with UDP-based things, though...  (I'm also unsure how
widely it is implemented.)
-- 
ISDN, n:  Incredibly Slow and Dumb      | Henry Spencer @ U of Toronto Zoology
Networking                              |  henry@zoo.toronto.edu  utzoo!henry

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 May 92 15:35:27 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket options under TLI

In article <1992May7.011529.26583@picasso.cssc-syd.tansu.oz.au> yohan@picasso.cssc-syd.tansu.oz.au (Yohan Jeevaratnam) writes:
>Hello world,
>I am trying to use the Transport Layer Interface(TLI) provided by SunOs, with
>a tcp/ip  underlying protocol suite. 
>Most of the TLI calls seem to work fine ( though there are a couple of
>exceptions), however the problem I've encountered is that I would really like
>to set some socket options. In the tcp/ip paradim I would use "setsockopt",
>however with TLI I can`t see any documentation on how to toggle socket
>options through the TLI interface.

Perhaps t_optmgmt() with the T_NEGOTIATE flag may do what you want.
It lets you set (but not reset!) the REUSADDR and KEEPALIVE flags, 
which is of limited use since they appear to both default to "ON" when
you use TLI.
However, it also lets you configure the send and receive buffer sizes,
which you may find useful.  Other options appear to be inaccessible
except through the socket interface.

To use t_optmgmt with TCP, you must #include <nettli/tcp_tli.h>, which
defines the "struct tt_soopt" options structure that contains the option
settings.  I think it works something like this:

	struct t_optmgmt *req, *ret;
	struct tt_soopt  *opt;

	req = (struct t_optmgmt *)t_alloc(fd, T_OPTMGMT, T_OPT);
	req->flags = T_NEGOTIATE;
	req->opt.len = req->opt.maxlen;  /* I think you have to do this */

	opt = (struct tt_soopt *)req->opt.buf;
	opt->tts_reuseaddr = 1;		/* yes */
	opt->tts_keepalive = 0;		/* no */
	opt->tts_sendsize  = 16 * 1024; /* supplying <=0 for buffer sizes */
	opt->tts_recvsize  = 16 * 1024; /* leaves them unchanged, but I   */
					/* don't know if that behaviour is */
					/* guaranteed in the future        */

	ret = (struct t_optmgmt *)t_alloc(fd, T_OPTMGMT, T_OPT);

	(void) t_optmgmt(fd, &req, &ret);
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      7 May 92 16:54:33 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   TCP testing


	Some number of years ago, I read a document describing some of the
early TCP "connectathon" testing sessions.  You got points for being able
to do certain things (i.e. open a telnet connection), points for crashing
other people's TCPs with legal packets, for withstanding having illegal
packets thrown at you, for noticing (if not actually doing anything with)
set option bits, etc, etc.  I can no longer remember where that document
is, or what it was called.  It might have been an RFC, but I looked through
the indicies and didn't see anything that looked like it.

	Can somebody help me identify and/or locate this document?
-- 
roy@alanine.phri.nyu.edu (Roy Smith)
Public Health Research Institute
455 First Avenue, New York, NY 10016, USA
"This never happened to Bart Simpson."

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 May 92 17:25:24 GMT
From:      chase@SBAND.ED.ray.com (Tom Chase)
To:        comp.protocols.tcp-ip
Subject:   TCP connections / code bug?



	Help! I am having a problem detecting the loss of TCP/IP 
connections with a software application I have written.  The software 
uses all non-blocking I/O.  The host is a SUN IPX.  Once a connection 
has been made, and I shut off the computer that I am connected to,  
send() still returns the byte count of what I am trying to write, read() 
still returns "EWOULDBLOCK", select does not return any read/write/except
file descriptors,  and netstat still shows that the socket connection is 
"ESTABLISHED".  I am not receiving a SIGPIPE.

	What am I not doing?  Do I need to maintain application handshaking
on top of TCP?  Am I not invoking setsockopt with the SO_KEEPALIVE option 
correctly or to the correct protocol?


			Thanks,  Tom


-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 May 92 19:12:25 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket options under TLI

In article <1992May7.113526.26503@jarvis.csri.toronto.edu> I (Brian Thomson) write:
[ concerning accessing socket options through the SunOS 4.1.1 TLI interface ]
>
>To use t_optmgmt with TCP, you must #include <nettli/tcp_tli.h>, which
>defines the "struct tt_soopt" options structure that contains the option
>settings.  I think it works something like this:
>
>	struct t_optmgmt *req, *ret;
>	struct tt_soopt  *opt;
>
>	req = (struct t_optmgmt *)t_alloc(fd, T_OPTMGMT, T_OPT);
>	req->flags = T_NEGOTIATE;
>	req->opt.len = req->opt.maxlen;  /* I think you have to do this */
>
>	opt = (struct tt_soopt *)req->opt.buf;

etc.

It has been pointed out to me by mail, that the above will not work
properly in 4.1.1.  Instead, you must supply the tt_soopt structure
manually, as t_alloc() will not allocate one for you (although it is
supposed to!).

That is, you must do something like 

       struct t_optmgmt *req, *ret;
       struct tt_soopt  *opt;

       req = (struct t_optmgmt *)t_alloc(fd, T_OPTMGMT, 0);
       req->flags = T_NEGOTIATE;
       opt = (struct tt_soopt *)req->opt.buf = calloc(1, sizeof *opt);
       req->opt.len = req->opt.maxlen = sizeof *opt; 


The reason, for the curious among you, is that t_alloc determines the
size of the options buffer by consulting the "info.options" field
returned by a t_getinfo.  It uses the same value when allocating
an options buffer for a t_connect() request.  In the current SunOS,
this value is 0, because the implementation does not permit options
to be specified in a TCP t_connect.  Unfortunately, this is not
the right value for t_optmgmt purposes.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      7 May 92 19:47:42 GMT
From:      doug@happy.vf.ge.com (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   TLI vs. connected vs. unconnected vs. streams

I've been programming in sockets lately and they are simple to implement
and program.. However, I have a few questions.. What are people's onpinions
on the various TCP/IP and udp interfaces available.  I'm on a sparc 1+
and have access to TLI, sockets, and streams... 
  Which ones are faster?  
  Obviously TCP is more robust the udp, but what about TLI vs. streams vs sockets
  It seems that TLI is built right on top of the socket interface in suns. 
So what would be the advantage of using TLI over plain sockets.

  Also, what's a good book to learn streams programming, since I can't seem
to get a darned thing out of the man pages on our sun. Is it worth it to use
streams instead of sockets?  I'm looking toward the future when sockets will
be implemented on top of streams for the new SunOS coming our (Sys V).


-- 
 ___			|	GE software developer
( / ) _       _,	|	doug@happy.vf.ge.com
_/_/ <_>_/_/_<_>	|	uunet!crdgw1!ge-dab!happy.vf.ge.com!doug
             <_>	|	2B | !2B > The_Question
________________________|______________________________________________________

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 May 1992 21:48:00 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP testing

 roy@alanine.phri.nyu.edu (Roy Smith) writes:
>
>	Some number of years ago, I read a document describing some of the
>early TCP "connectathon" testing sessions.  You got points for being able
>to do certain things (i.e. open a telnet connection), points for crashing
>other people's TCPs with legal packets, for withstanding having illegal
>packets thrown at you, for noticing (if not actually doing anything with)
>set option bits, etc, etc.  I can no longer remember where that document
>is, or what it was called.  It might have been an RFC, but I looked through
>the indicies and didn't see anything that looked like it.

The great tcp BAKEOFF.  Last place I saw it was on a yellowed sheet of
paper in the bottom of a box of historical things I was saving.  But
I remember bakeoff being part of the name.

Erick
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 May 1992 21:57:59 GMT
From:      jon.taylor@EMCB.CC.UTAH.EDU (JON M. TAYLOR)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Having trouble with NET14.exe

	I've just FTP'd NET14.EXE for MS-DOS, which is supposed to let you 
use anything that normally talks over serial ports (I.E. term programs, 
external transfer protocols a la DSZ, etc.) with TCP/IP networks.  Upon 
reading what was laughably called documentation (Maybe I got the wrong 
file?  It was only 2-3 pages long...), I was clueless as to how to use 
this.  Is there anyone out there who has gotten this thing to work and can 
give me some pointers?  Thanks for any help.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#DEFINE QUOTE ("The only real sin lies in hurting other people unnecessarily.
Hurting YOURSELF is not sinful - just stupid." - Robert A. Heinlein)
#DEFINE NAME "Jon M. Taylor"
#DEFINE IMAIL_ADDRESS "JON.TAYLOR@M.CC.UTAH.EDU"
#INCLUDE <std_disclaimer.h>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 May 1992 00:55:50 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

In article <1992May1.234348.14613@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
>In article <1992May1.075702.8362@novell.com> donp@novell.com (don provan) writes:
>>From the other discussion, what we have here is a TCP/IP
>>implementation that cannot handle receiving an ACKless SYN when in
>>the SYN_SENT state.
>
>Hmm, no, I don't think that is the problem I described.
>
>The (Tahoe and later) BSD implementations, as well as recent SunOS ones,
>do properly handle the received SYN when in SYN_SENT state.
>The problem occurs later, when the TCP receives what it believes to be
>a redundant SYN ACK.  It drops the SYN, and then fails to process the
>remaining ACK.

Sorry, i can see now i was a bit lax in my discussion.  The problem i
see is that the SunOS cannot handle "crossing SYNs", which i described
somewhat obtusely as "receiving a SYN without an ACK while in SYN-SENT
state".  That phrasing does make it sound like the problem is right
there where that SYN is processed, although you have obviously tracked
the actual bug a little further along.  All i meant to describe was
the function that was not being handled: crossing SYNs.  Sorry for the
confusion.

>The RFCs are unclear about what is the "correct" thing to do...

If you mean the RFC doesn't specifically discuss a port establishing a
connection to itself, then i suppose that's true.  The RFC does,
however, explain how to handle all of the state transitions involved
in this case.  This case is *not* as unusual as it first seems.  Since
TCP is a symetric protocol, a TCP port can talk to itself as well as
it can talk to any other TCP port in the IP internet.

>>From the
>>sounds of things, the Sun TCP would hang just as well if you got two
>>different end points on two different machines connecting to each
>>other at exactly the same time.
>
>Sorry if I gave that impression.  If the problem were related to 
>SYN in SYN_SENT state, then I would agree with you.  However, I don't
>think that two different hosts could reproduce the problem that I
>am trying (apparently, not very successfully) to communicate.

I don't see anything in your discussion that would be any different in
cross connecting two different ports simultaneously instead of trying
to connect a single port to itself.  The two lone SYNs would still
move both the end points from SYN-SENT to SYN-RECEIVED, both would
respond with a SYN-ACK, both end points would still received the
SYN-ACK in SYN-RECEIVED state, the SYN would still be stripped because
it would still be duplicate data, each SYN-ACK would still be rejected
because it was "empty" (which is the real blunder: there's nothing
wrong with an empty packet, particularly one carrying ACK
information!) and another SYN-ACK would be sent in response, and the
ACK information on the SYN-ACK would still be ignored.  Am i missing
something?  As far as i can see, the only difference is you'd hang
*two* nodes and melt down the copper between them, as well.  (Well,
actually i imagine that the small latency while waiting for the
packets to cross the ethernet would probably make it slightly less of
a problem with two nodes, but then it wouldn't sound so dramatic.)

I know it *looks* really different and special when there's only one
end point, but i think when you consider it you'll realize that this
case isn't really significantly different than the case that has two
different end points (except, of course, that the problem would be
*much* harder to reproduce if you had to get two machines that finely
synchronized).
						don provan
						donp@novell.com

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      8 May 92 04:04:32 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP testing

In article <1992May7.214800.23150@watserv1.waterloo.edu> eengelke@sail.uwaterloo.ca (Erick Engelke) writes:
>
>The great tcp BAKEOFF.  Last place I saw it was on a yellowed sheet of
>paper in the bottom of a box of historical things I was saving.  But
>I remember bakeoff being part of the name.

RFC 1025, "TCP and IP bake off."  Found it with WAIS in no time flat.

(WAIS is described in comp.infosystems.wais, clients can be ftp'd
from think.com:/wais)
--
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
      MSEN Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 741 1120
"Not to panic.  Networking will eventually get to Michigan.  Remember
 the decades it took IBM to discover virtual memory."  Randy Bush

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 May 1992 04:55:13 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Use of well known ports

In article <Bnw0Cs.M5p@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes:
> In article <2176@cronos.metaphor.com> pstevens@Metaphor.COM (Paul Stevens) writes:
> >How do other applications solve this problem?  Do they let the choice
> >of the well known port(s) be configured by each site into /etc/services
> >(or its non-Unix equivalent)?
> 
> You might want to look at RFC 1078, "TCP Port Service Multiplexer".
> Won't work with UDP-based things, though...  (I'm also unsure how
> widely it is implemented.)


At least one workstation vendor ships it in the standard release.
It is easy to implement and a good idea.


Vernon Schryver,  vjs@sgi.com


-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      8 May 92 13:37:05 GMT
From:      taybh@hpsgm2.sgp.hp.com (Tay Beng Hang)
To:        comp.protocols.tcp-ip
Subject:   Re: "Connected" UDP

>In comp.protocols.tcp-ip, barmar@think.com (Barry Margolin) writes:
>In article <1992May05.220205.12800@catfish.az05.bull.com> djschoff@cibecue.az05.bull.com (Daniel J. Schoffelman) writes:
>>I can find no reference to the concept of "connected" UDP in the UDP
>>standards, at least not in the RFCs.  If, as W. Richard Stevens says
>>in "UNIX Network Programming", an ICMP message must be sent back on
>>receipt of a datagram to a connected UDP socket (in the case the sender
>>is not one of the connectees), how is this done?
>
>You won't find anything about this in the RFC's, because they don't concern
>themselves with application program interfaces, only the protocol that goes
>out over the network.  The concept of "connected" UDP is purely an artifact
>of a programming model, and doesn't affect the protocol.  The host
>receiving a UDP datagram doesn't know whether it was sent from a connected
>or unconnected socket.  The ICMP Port Unreachable should *always* be sent
>when there is no process listening on the destination port.  The only
>relationship between this and connected sockets is that the original UDP
>sending host will usually just ignore the ICMP response if there's no
>connected socket, since there's nothing useful to do with it.

In fact, there is some use of this ICMP Port Unreachable message. The process
can use connected UDP socket to find out whether the destination (port)
is reachable, ie. whether there is a process waiting for messages at the
remote port. If there is no process opened at the remote port, then an
ICMP Port Unreachable message will be generated by the remote host. In this 
case, the process who bind to the connected UDP socket will be informed 
when the local host receives a ICMP Port Unreachable message. 
This is done by a Connection Refused (ECONNREFUSED) error when the process
tries the next send()/write() as discussed in Steven's book in pg 271 & 442.  
Only process who connects to the unreachable destnation is informed. 
According to the book "The Design and Implementation of 4.3BSD OS" pg 352, 
I undestand that this is used in host-name lookup routine in 4.3BSD to detect 
the absence of a nameserver at boot time, allowing it to fall back to local 
host table. If I am wrong, please correct me. Thanx.

Best regards,
 ____________________________________________________________________________
| Beng-Hang Tay                       | Telnet:    520 8732                  |
| Singapore Networks Operation        | Phone:     (65) 279 8732             |
| Hewlett-Packard Singapore Pte. Ltd. | Fax:       (65) 272 2780             |
| 1150 Depot Road                     | Internet:  taybh@hpsgm2.sgp.hp.com   |
| Singapore 0410                      |            taybh@hpsgnlc.sgp.hp.com  |
| Republic of Singapore		      |                                      |
 ----------------------------------------------------------------------------

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 May 92 13:35:35 BST
From:      ian@vnet.ibm.com (Ian Stirling)
To:        comp.os.os2.misc,comp.os.os2.networking,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   OS2 and VT5250 emulation ?

In <1992May7.101742.5623@edfd.uucp> Markus Gruenkorn (MAGIC writes:
>Hi guys !
>I would like to know if there is an VT5250 emulation for OS2 out there.
>We have a large network based on TCP/IP including AS400, PC's,
>a MVS host, and different kinds of unix workstations. It would be nice
>to connect from a PC with OS2 directly to a AS400. I read the deskription
>of the IBM's TCP/IP package and could not find a VT5250 emulation !
>
>Any information would be appreciated!
>--
>------ < MAGIC > ------
>

There is 5250 emulation built into the OS/2 Communications Manager.
In OS/2 1.x, this came as part of the EE package.  In 2.0 it has been
split off into a separate package called Extended Services.

Cheers,
Ian Stirling                      Internet: ian@vnet.ibm.com
CICS/ESA Systems Facilities         Bitnet: ian at vnet
IBM UK Labs Ltd, Hursley, England IBMIPnet: ian@stirling.hursley.ibm.com

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      8 May 92 15:17:01 GMT
From:      rich@progress.COM (Rich Lenihan)
To:        comp.protocols.tcp-ip
Subject:   1's vs. 0's in broadcast address

I'm setting up an NIS server on a very heterogenous network and
was wondering about the precise distinction between using a
broadcast adress with a host part of all 0's and a broadcast
address with a host part of all one's.  We've got a class C
network of the form 123.123.123.999 where 999 is the host part.
The server is a Sun that uses a broadcast address of 123.123.123.0,
but many of the clients use a broadcast address of 123.123.123.255.
When given a choice, I've always set the system up to use all ones,
but many of them came preconfigured to use all zero's (and if it
works, why fix it?)

The way I understand (or misunderstand) it is that the zero's form
is a "placeholder", meaning this network but not any specific host
on this network and the one's form means any host on this network.
To me, this sounds functionally equivalent.  Is there something
else here that I'm missing?  Am I opening my network up to some hellacious 
broadcast storms by having mixed forms on the same network?  Like I said, 
everything seems to work fine (for now), except for one or two clients
that just won't bind (but I'm not sure that's a problem with the addressing).

Thanks...

-Rich
--
Rich Lenihan                 UUCP: mit-eddie!progress!rich
Progress Software Corp.      Internet: rich@progress.com

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 May 1992 15:39:27 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip
Subject:   getting Internet country codes

Recently someone sent me a list of all the coutry codes i.e. the suffixes on
Internet addresses for all the different countries.  I imagine this info is
maintained by the NIC but how would I go about getting the latest version of
this info?  Is it available via anonymous FTP from the nic, or is there a
mailing list to be on? 

Thanks and sorry if this is not the right place to ask this...

***********************************************************************
Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
rgoldstone@oavax.csuchico.edu

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      8 May 92 16:00:14 GMT
From:      Dean.Roth@mixcom.mixcom.com (Dean.Roth)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp,comp.unix.aix
Subject:   SLIP or PPP with X.25 - can anyone help???


Here's what I want to do:


  [PC]-[modem]-----{X.25}------[AIX]
      ^
      |
 SLIP or PPP


I want (business) applications on remote PCs to use TCP/IP
as the communications layer. 

Getting a PC and the AIX system to talk via SLIP when they
are hardwired or through a modem has not been a problem.
Applications on the PCs and the AIX system currently communicate using
file transfers, which is less than ideal interprocess communications.

I don't see how to make this work through X.25. Can it?

Dean Roth

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 May 92 16:14:40 GMT
From:      rla@media03.UUCP (Raymond van der Laan)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP/IP toolkits for PC's


Programmer's toolkits for DOS-TCP/IP programs:

Name        Price       Requirements          Sockets     RPC   DLL  TSR
========================================================================
Sun         $300*       Sun PC-NFS            Yes         Yes   No   Yes**

FTP         $700*       PC/TCP Kernel ($300*) Yes         Yes   Yes  Yes?

NetManage   $565        Chameleon ($450)      Yes         No*** Yes  No

Distinct    $495        ?                     Yes         Yes   Only No

TurboSoft   $60****     Kernel ($30****)      No?         No?   No   Yes
                         + packet/NDIS/ODI driver
=========================================================================

* estimated from Dutch prices
** no interface to DOS-applications
*** separate toolkit, $565
**** AUS $

Memory requirements are for all significantly less than Sun, about 1/2
to 1/4 amount of K's.
Turbosoft has 3Com BAPI and NetBIOS (soon) interfaces.

I hoped to put more names in the list, but I guess this is it....

I think FTP and/or Turbosoft are the best candidates to solve our needs.
(remember, we need to write a TSR which contains all network-related
code and is accessed from a DOS-application via an interrupt.)

-- 
Raymond van der Laan           Email: sun4nl!media01!rla
Mediasystemen BV               Tel. : +31 23-319075            
Haarlem                        Fax  : +31 23-315210
The Netherlands                                   
                                    'There is no masterplan.
                                     This is what we do now.'
                                            - Stuart Adamson

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      8 May 92 16:47:37 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

In article <1992May8.005550.5029@novell.com>, donp@novell.com (don provan) writes:
|> In article <1992May1.234348.14613@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
|> >In article <1992May1.075702.8362@novell.com> donp@novell.com (don provan) writes:
|> >>From the other discussion, what we have here is a TCP/IP
|> >>implementation that cannot handle receiving an ACKless SYN when in
|> >>the SYN_SENT state.
|> >
|> >Hmm, no, I don't think that is the problem I described.
|> >
|> >The (Tahoe and later) BSD implementations, as well as recent SunOS ones,
|> >do properly handle the received SYN when in SYN_SENT state.
|> >The problem occurs later, when the TCP receives what it believes to be
|> >a redundant SYN ACK.  It drops the SYN, and then fails to process the
|> >remaining ACK.
|> 
|> Sorry, i can see now i was a bit lax in my discussion.  The problem i
|> see is that the SunOS cannot handle "crossing SYNs", which i described
|> somewhat obtusely as "receiving a SYN without an ACK while in SYN-SENT
|> state".  That phrasing does make it sound like the problem is right
|> there where that SYN is processed, although you have obviously tracked
|> the actual bug a little further along.  All i meant to describe was
|> the function that was not being handled: crossing SYNs.  Sorry for the
|> confusion.
|> 
|> >The RFCs are unclear about what is the "correct" thing to do...
|> 
|> If you mean the RFC doesn't specifically discuss a port establishing a
|> connection to itself, then i suppose that's true.  The RFC does,
|> however, explain how to handle all of the state transitions involved
|> in this case.  This case is *not* as unusual as it first seems.  Since
|> TCP is a symetric protocol, a TCP port can talk to itself as well as
|> it can talk to any other TCP port in the IP internet.
|> 
|> >>From the
|> >>sounds of things, the Sun TCP would hang just as well if you got two
|> >>different end points on two different machines connecting to each
|> >>other at exactly the same time.
|> >
|> >Sorry if I gave that impression.  If the problem were related to 
|> >SYN in SYN_SENT state, then I would agree with you.  However, I don't
|> >think that two different hosts could reproduce the problem that I
|> >am trying (apparently, not very successfully) to communicate.
|> 
|> I don't see anything in your discussion that would be any different in
|> cross connecting two different ports simultaneously instead of trying
|> to connect a single port to itself.  The two lone SYNs would still
|> move both the end points from SYN-SENT to SYN-RECEIVED, both would
|> respond with a SYN-ACK, both end points would still received the
|> SYN-ACK in SYN-RECEIVED state, the SYN would still be stripped because
|> it would still be duplicate data, each SYN-ACK would still be rejected
|> because it was "empty" (which is the real blunder: there's nothing
|> wrong with an empty packet, particularly one carrying ACK
|> information!) and another SYN-ACK would be sent in response, and the
|> ACK information on the SYN-ACK would still be ignored.  Am i missing
|> something?  As far as i can see, the only difference is you'd hang
|> *two* nodes and melt down the copper between them, as well.  (Well,
|> actually i imagine that the small latency while waiting for the
|> packets to cross the ethernet would probably make it slightly less of
|> a problem with two nodes, but then it wouldn't sound so dramatic.)
|> 
|> I know it *looks* really different and special when there's only one
|> end point, but i think when you consider it you'll realize that this
|> case isn't really significantly different than the case that has two
|> different end points (except, of course, that the problem would be
|> *much* harder to reproduce if you had to get two machines that finely
|> synchronized).
|> 						don provan
|> 						donp@novell.com

The commonality between the two scenarios is that the laddr,lport,
raddr,rport are identical.  The key discriminators are the send and receive
sequence numbers.  In the case with two end points, RFC 793 even has
an example discussing the "cross SYN" case with two distinct end
points (page 32).  The difference with one end point is that you are
sharing the send and receive sequence numbers.  Unlike the example
in the RFC, you can't simply handshake the sequence numbers and 
consider the connection established (i.e. sequence numbers are incremented
during the handshake).

I'm sure you can patch TCP to make this work, but what is gained?
In fact, as you stated in an earlier posting, the value of a single
end-point connection is not extremely clear.  By short-circuiting 
the user at the time the connection is requested, we would no longer
have to debate the logistics of supporting this seemingly worthless feature.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 May 1992 16:48:17 GMT
From:      ddk@beta.lanl.gov (David D Kaas)
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.unix.questions
Subject:   What to user for an Internet gateway?

  We are going to set up a gateway to the Internet and would
appreciate some suggestions on a platform.  We will probably
have a cisco router as a network connections that will be
connected to a Unix workstation.  The Internet connection
will initially be T1 and the internal network will
be ethernet.  Maybe 20 concurrent interactive users, mail,
usenet news and file transfers in the mega byte range.
We have not decided yet whether remote users will be able
to transfer files to internal machines or use the gateway
for store and forward.  There will be probably be some
computing to remote Crays.  Initially most work will be
from internal machines to the Internet, however in the next
year or so remote access from the Internet is expected
to become the major user.
  What size machien? disk? memory? Is ther anything
special we should look for?

Thank You
Dave Kaas
Boeing Computer Services Richland
D. O. E. Richland
a
(509) 376-6386
ddk@lanl.gov
-- 
Dave Kaas - D.O.E. Richland, Wa.
ddk@beta.lanl.gov

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 May 92 19:01:26 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

In article <1992May8.005550.5029@novell.com> donp@novell.com (don provan) writes:
>
>I don't see anything in your discussion that would be any different in
>cross connecting two different ports simultaneously instead of trying
>to connect a single port to itself. 

Thanks for persevering, the message finally got through.
I was, umm, mistaken when I insisted that the self-loop was necessary.

It is indeed possible for two nodes to enter this state, and if they try
enough, it is surprisingly easy.  I just got a pair of Sparcstation
IPCs to send each other 1700 packets per second while sitting in
SYN-RCVD.

As far as pointing the finger goes, I agree with you that the
ACK field really should be processed.  In fact, I don't really see
that there is ever a valid reason for not processing an ACK field
(as long as one is present).  The apparent logic behind the RFC
recommendation, is that if the segment is entirely outside the window,
then it is probably an old duplicate, and should be discarded.
Under those circumstances, though, it really can't hurt to re-process
an old ACK you've already seen before, so why not do the ACK processing
anyway?

That behaviour would still be RFC complaint, because as I mentioned
earlier, the RFC gives two alternative ways of handling a segment
that is not at the left window edge.  You can follow

        If an incoming segment is not acceptable, an acknowledgment
        should be sent in reply (unless the RST bit is set, if so drop
        the segment and return):

          <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

        After sending the acknowledgment, drop the unacceptable segment
        and return.

which means you discard the ACK, or you can be more forgiving, and follow

        In the following it is assumed that the segment is the idealized
        segment that begins at RCV.NXT and does not exceed the window.
        One could tailor actual segments to fit this assumption by
        trimming off any portions that lie outside the window (including
        SYN and FIN), and only processing further if the segment then
        begins at RCV.NXT.

which means you do end up processing the ACK.

So, is the first alternative an RFC bug?  Well, no.  Notice that it
specifies sending ACK-only (i.e., SYN-less!) segment in reponse before
dropping the received segment.  Now, somewhere on the road between
4.3 and Tahoe, the code

    dropafterack:
        /*
         * Generate an ACK dropping incoming segment if it occupies
         * sequence space, where the ACK reflects our state.
         */
        if (tiflags & TH_RST)
                goto drop;
        if (tp->t_inpcb->inp_socket->so_options & SO_DEBUG)
                tcp_trace(TA_RESPOND, ostate, tp, &tcp_saveti, 0);
        tcp_respond(tp, ti, tp->rcv_nxt, tp->snd_nxt, TH_ACK);
        return;

mutated into

    dropafterack:
        /*
         * Generate an ACK dropping incoming segment if it occupies
         * sequence space, where the ACK reflects our state.
         */
        if (tiflags & TH_RST)
                goto drop;
        m_freem(m);
        tp->t_flags |= TF_ACKNOW;
        (void) tcp_output(tp);
        return;

The original code sends a SYNless ACK, as per the RFC.
The new code will send a SYN along with, if the TCP has not yet reached
ESTABLISHED state, and this is not correct.

So .... (finally taking a long breath), proceeding with ACK processing
is one RFC-compliant fix for the problem, and putting the tcp_respond()
call back is a second one.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 May 1992 20:38:21 GMT
From:      pmetzger@snark.shearson.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Proxy FTP server wanted


[I posted a request like this a few days ago but apparently we've been
having news server problems of various kinds keeping our posts from
getting out, so...]

For a firewall machine, I'm looking for a proxy ftp server for BSD
unix, that is, an ftp server that a client can connect to and then
specify another FTP server on the other side of the firewall to
connect to.  I've seen such proxy FTP servers in use, so I know that
at least a few implementations do indeed exist. (The general paradigm
I've seen seems to be to implement a new command called "SITE" that
tells the server to open a command connection to a remote ftp daemon
on the named site and then start forwarding commands to that site,
with the proxy daemon intercepting and forwarding the data connection
to the client.)

If anyone has such a beastie, or somethign similar, I'd very much
appreciate getting a hold of it.

Thanks in advance...


--
Perry Metzger		pmetzger@shearson.com
--
"That government governs best which governs least."
		-- Thomas Jefferson, former US President and early libertarian.
Restore the American Dream: Vote Libertarian!
Libertarian Party info: Phone 1-800-682-1776, E-Mail 345-5647@mcimail.com

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 May 1992 20:48:54 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP/IP toolkits for PC's

rla@media03.UUCP (Raymond van der Laan) writes:
>
>Programmer's toolkits for DOS-TCP/IP programs:
>
>Name        Price       Requirements          Sockets     RPC   DLL  TSR
>========================================================================
>Sun         $300*       Sun PC-NFS            Yes         Yes   No   Yes**
>
>FTP         $700*       PC/TCP Kernel ($300*) Yes         Yes   Yes  Yes?
>
>NetManage   $565        Chameleon ($450)      Yes         No*** Yes  No
>
>Distinct    $495        ?                     Yes         Yes   Only No
>
>TurboSoft   $60****     Kernel ($30****)      No?         No?   No   Yes
>                         + packet/NDIS/ODI driver
>=========================================================================
>
>I think FTP and/or Turbosoft are the best candidates to solve our needs.
>(remember, we need to write a TSR which contains all network-related
>code and is accessed from a DOS-application via an interrupt.)

Your price lists ought to consider what happens if you consider site
licensing.  As a rough guestimate, PC-NFS and PC/TCP drop by about 50%
or more under site licensing policies.  I think you might also want
to consider Beame&Whiteside, Novell Lan WorkPlace for DOS and a few
others who already have considerable market share.

If you are going for low cost, look at WATTCP, it's about the same
price as TurboSoft for the toolkit but free distribution.

Most developers end up having to support multiple stacks.  It's not
hard, just an annoyance because each has slightly different rules.

Erick
 
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      8 May 92 23:21:04 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP testing

roy@alanine.phri.nyu.edu (Roy Smith) writes:

>	Some number of years ago, I read a document describing some of the
> early TCP "connectathon" testing sessions.  You got points for being able
> to do certain things (i.e. open a telnet connection), points for crashing
> other people's TCPs with legal packets, 
> It might have been an RFC, but I looked through
> the indicies and didn't see anything that looked like it.

RFC 1025, "TCP AND IP BAKE OFF", by J. Postel.  The point scores are
divided up by division:

      Featherweight Division

         1 point for talking to yourself (opening a connection).

         1 point for saying something to yourself (sending and receiving
         data).

         1 point for gracefully ending the conversation (closing the
         connection without crashing).

         2 points for repeating the above without reinitializing the
         TCP.

         5 points for a complete conversation via the testing gateway.

	 [[[ This is the "flakeway", which purposely drops, corrupts,
	   duplicates and reorders packets at random ]]]

      Middleweight Division

         2 points for talking to someone else (opening a connection).

         2 points for saying something to someone else (sending and
         receiving data).

         2 points for gracefully ending the conversation (closing the
         connection without crashing).

         4 points for repeating the above without reinitializing the
         TCP.

         10 points for a complete conversation via the testing gateway.

      Heavyweight Division

         10 points for being able to talk to more than one other TCP at
         the same time (multiple connections open and active
         simultaneously with different TCPs).

         10 points for correctly handling urgent data.

         10 points for correctly handling sequence number wraparound.

         10 points for correctly being able to process a "Kamikaze"
         packet (AKA nastygram, christmas tree packet, lamp test
         segment, et al.).  That is, correctly handle a segment with the
         maximum combination of features at once (e.g., a SYN URG PUSH
         FIN segment with options and data).

         30 points for KOing your opponent with legal blows.  (That is,
         operate a connection until one TCP or the other crashes, the
         surviving TCP has KOed the other.  Legal blows are segments
         that meet the requirements of the specification.)

         20 points for KOing your opponent with dirty blows.  (Dirty
         blows are segments that violate the requirements of the
         specification.)

         10 points for showing your opponents checksum test is faulty or
         disabled.

      Host & Gateway IP Division

         25 points for doing fragmentation and reassembly.

         15 points for doing loose source route option.

         15 points for doing strict source route option.

         10 points for doing return route option.

         10 points for using source quench messages.

         10 points for using routing advice messages.

         5 points for doing something with the type of service.

         5 points for doing something with the security option.

         5 points for doing something with the timestamp option.

         5 points for showing that a gateway forwards datagrams without
         decreasing the time to live (showing a gateway is faulty).

         5 points for showing that a gateway forwards datagrams with the
         time to live equal zero (showing a gateway is faulty).

         10 points for showing that a gateway or hosts checksum test is
         faulty or disabled (showing a gateway is faulty).

      Bonus Points

         10 points for the best excuse.

         20 points for the fewest excuses.

         30 points for the longest conversation.

         40 points for the most simultaneous connections.

         50 points for the most simultaneous connections with distinct
         TCPs.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      9 May 1992 12:41:30 -0500
From:      rick@hydepark.com (Rick Watson)
To:        comp.protocols.tcp-ip
Subject:   Announcing MacSLIP

[ Apologies if you get this more than once. ]
[ My regular news poster seems to be stuck. ]

Hyde Park Software is pleased to announce the availability of 
MacSLIP -- a SLIP Link Access Protocol Module for MacTCP. 

MacSLIP allows you to extend the network connectivity of your 
Macintosh to locations that might not be accessible to a LocalTalk
or Ethernet network via a modem connection over the telephone
or a hardwired connection to a SLIP Server. SLIP (Serial Line IP)
is a protocol that allows many simultaneous IP connections to run
over a single serial connection to a SLIP Server (a terminal
server or other host that supports SLIP). Instead of running a single
terminal emulator session over your serial port, MacSLIP allows you
to run simultaneous Telnet, FTP, News, Mail, and other MacTCP based
applications. You can even run XWindows although XWindow based
applications tend to require lots of bandwidth.

MacSLIP supports normal SLIP connections as well as connections that
allow TCP Header Compression (CSLIP).  TCP Header Compression is a 
method for compressing the headers of TCP/IP datagrams to improve
performance over relatively slow serial lines. Not all SLIP Servers
support CSLIP but MacSLIP will work either way.

MacSLIP's connection script facility allows automated modem dialing,
logging into a SLIP Server, establishing a SLIP session, etc.
The script facility will write a log of the connection process for
easy debugging of your script. Sample scripts are provided.  During
the connection, a script status dialog appears to notify the user of
the progress of the connection. The script can write messages to a
status area and can prompt the user for passwords or connection data.
The incoming character stream from the serial port is also displayed. 

The script facility supports sending strings, matching strings read
 from the serial port to control script execution, simple counters,
timers, loops, prompting for user input, and a status dialog to inform
the user of the script's progress. 

You can configure your Mac to use a static IP address or you can get
an IP address from your SLIP Server via the bootp protocol. 

Included in the package is Netstat, an application designed for
monitoring TCP connections to your Macintosh. Netstat displays all
open TCP connections' source and destination IP addresses, TCP ports,
and connection state. You can view all the internal counters that
MacTCP keeps for each connection as well as global MacTCP and MacSLIP
counters. 

Requirements:

- Any Macintosh running System 7 or a Mac-II class Mac running System 6.0.7.
- MacTCP 1.1 (or MacTCP 1.1+ for a Mac Plus)
- A serial connection to a SLIP Server via modem or hardwired connection.

Availability:

We will begin taking orders immediately (Mon-Fri 8-5 CDT) with
shipping scheduled to begin the week of May 25. Sales and support are
being provided by

    TriSoft
    1825 East 38 1/2 
    Austin, Texas 78722
    Sales: (800) 531-5170
    Support and Info: (512) 472-0744
    FAX: (512) 473-2122

Individual copies are $49.95 + shipping + sales tax if applicable.
Questions about MacSLIP and other pricing may also be sent to:

    info@hydepark.com

Rick Watson
Hyde Park Software




-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      9 May 1992 06:54:16 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connections / code bug?

In article <9205071725.AA11256@SBAND.ED.RAY.COM> chase@SBAND.ED.ray.com (Tom Chase) writes:
>	Help! I am having a problem detecting the loss of TCP/IP 
>connections with a software application I have written.  The software 
>uses all non-blocking I/O.  The host is a SUN IPX.  Once a connection 
>has been made, and I shut off the computer that I am connected to,  
>send() still returns the byte count of what I am trying to write, read() 
>still returns "EWOULDBLOCK", select does not return any read/write/except
>file descriptors,  and netstat still shows that the socket connection is 
>"ESTABLISHED".  I am not receiving a SIGPIPE.

How long did you wait?  TCP detects that the other end has died by waiting
for a timeout when sending a packet, retransmitting it several times, and
not receiving an acknowledgement.  To prevent connections from closing
prematurely due to transient network problems (for instance, when a router
goes down it may take a couple of minutes for alternate routes to be
discovered), these timeouts are usually set fairly high (RFC 1122,
Requirements for Internet Hosts, recommends that it be no less than 100
seconds).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      9 May 1992 07:14:45 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: 1's vs. 0's in broadcast address

Please, someone create a FAQ for this group!

In article <1992May8.151701.20290@progress.com> rich@progress.COM (Rich Lenihan) writes:
>The way I understand (or misunderstand) it is that the zero's form
>is a "placeholder", meaning this network but not any specific host
>on this network and the one's form means any host on this network.
>To me, this sounds functionally equivalent.  

No, they aren't equivalent.  The 0 address is used when you want to refer
to the subnet as an independent entity.  Such addresses aren't intended to
be used as destination addresses in packets, but they're useful in network
databases.  For instance, routing protocols use them to name subnets.

The all 1 host part, on the other hand, is used to refer to all the hosts
on the subnet.

In the original TCP design, the all 0 form was also used as the broadcast
address.  This ended up being included in many BSD releases, even after the
TCP spec was adopted with all 1 being the standard.  Sun has refused to
change their default, presumably for compatibility reasons.

>					      Is there something
>else here that I'm missing?  Am I opening my network up to some hellacious 
>broadcast storms by having mixed forms on the same network?  Like I said, 
>everything seems to work fine (for now), except for one or two clients
>that just won't bind (but I'm not sure that's a problem with the addressing).

Our network mostly uses the all 1 address, but occasionally a machine is
misconfigured and uses Sun's default.  I haven't noticed any broadcast
storms due to this in a long time.  Some systems now recognize both
broadcast address style, but only send the form that they're configured
for, and maybe SunOS does this.

However, I recommend that you configure your Suns so that they send the
correct type of broadcast.  You never know when you're going to install a
system that doesn't recognize the nonstandard form.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      9 May 92 12:34:39 GMT
From:      scoggin@daisy.udel.edu (John K Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy FTP server wanted

In article <PMETZGER.92May8153821@snark.shearson.com> pmetzger@shearson.com writes:
>
>For a firewall machine, I'm looking for a proxy ftp server for BSD
>unix, that is, an ftp server that a client can connect to and then
>specify another FTP server on the other side of the firewall to
>connect to.  I've seen such proxy FTP servers in use, so I know that
>at least a few implementations do indeed exist. (The general paradigm
>I've seen seems to be to implement a new command called "SITE" that
>tells the server to open a command connection to a remote ftp daemon
>on the named site and then start forwarding commands to that site,
>with the proxy daemon intercepting and forwarding the data connection
>to the client.)
>
>If anyone has such a beastie, or somethign similar, I'd very much
>appreciate getting a hold of it.
>
>Thanks in advance...
>

You might call your friendly neighborhood Sun Microsystems rep and ask about
IGATEWAY.  They have both Telnet and FTP proxies.

	- John

-------------------------------------------------------------------------
John K. Scoggin, Jr.			Email:   scoggin@udel.edu
Supervisor, Network Operations			 scoggin@delmarva.com
Delmarva Power & Light Co.		Voice:	 302-451-5200
P.O. Box 6066				Fax:	 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary.  Void where prohibited by law (or common sense).

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 May 92 13:27:08 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connections / code bug?

>How long did you wait?  TCP detects that the other end has died by waiting
>for a timeout when sending a packet, retransmitting it several times, and
>not receiving an acknowledgement.  To prevent connections from closing
>prematurely due to transient network problems (for instance, when a router
>goes down it may take a couple of minutes for alternate routes to be
>discovered), these timeouts are usually set fairly high (RFC 1122,
>Requirements for Internet Hosts, recommends that it be no less than 100
>seconds).

I was watching this the other day with tcpdump and vanilla SVR4
(Lachman TCP/IP) took 9 minutes to detect a timeout for a LAN
connection when the plug was pulled on one end.  It did a total
of 14 retransmissions, with the time between retransmissions being
65 seconds for the last 7.

	Rich Stevens  (rstevens@noao.edu)

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 May 92 03:40:11 GMT
From:      amanda@visix.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Use of well known ports

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> At least one workstation vendor ships it in the standard release.
> It is easy to implement and a good idea.

Agreed.  The one thing that I would like to see added to it, however, is
the ability for programs to dynamically register (and deresgister) services
with it, instead of requiring a human being to go edit a file in /etc...

I'd also love to see a UDP equivalent (a generalized version of Sun's
portmapper that used names instead of centrally-administered "program
numbers", for example)...

Resource location and access point determination are two of the big
places where I have to reluctantly admit that OSI has something going
for it...


Amanda Walker						      amanda@visix.com
Visix Software Inc.				    ...!uupsi!visix.com!amanda
-- 
"Speak in French when you can't think of the English for a thing--
 turn out your toes as you walk-- and remember who you are!"
		--Lewis Carroll

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      10 May 92 15:57:00 GMT
From:      philip@cs.vu.nl (Philip Homburg)
To:        comp.protocols.tcp-ip
Subject:   Router Discovery protocols


I'm looking for information about the use of router discovery protocols.

I was very pleased when I found out about RFC-1256 (ICMP Router Discovery
Messages), implemented support for this protocol in my TCP/IP
implementation and wrote a deamon that listens to RIP packets and
broadcast router advertisements.

However, I recently read some cisco manuals and found out that cisco
has it's own UDP based router discovery protocol.

I am looking for information about the future of these protocols: is
the cisco protocol to be replaced with the ICMP based protocols?
Are there known implementations from vendors. Are there pd implementations
for SunOs, etc.
Of course I would be interrested in an interoperatability test also.




						Philip

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      10 May 92 18:52:17 GMT
From:      nedeljn@flint.cs.orst.edu (Nenad Nedeljkovic - Nesha)
To:        comp.protocols.tcp-ip
Subject:   Large Messages with TCP (again)

A week ago I posted a question regarding transmission of large messages
with TCP, between Sun workstations connected over Ethernet.
Thanks to all the people who responded to my message, but I am still
puzzled. Art Mellor suggested monitoring the packets on the wire, and 
although I've done that, things are still far from clear.
I am sending the output from 

	etherfind -t -v proto tcp and between ruby sard 

produced when a message of 40,000 bytes is sent from ruby to sard.

0.03 TCP from ruby to sard seq 4F691A09, ack 5208FA0D, window 50000, 1460 bytes
0.03 TCP from ruby to sard seq 4F691FBD, ack 5208FA0D, window 50000, 1460 bytes
0.03 TCP from ruby to sard seq 4F692571, ack 5208FA0D, window 50000, 1176 bytes
0.03 TCP from ruby to sard seq 4F692A09, ack 5208FA0D, window 50000, 1460 bytes
0.03 TCP from ruby to sard seq 4F692FBD, ack 5208FA0D, window 50000, 1460 bytes
0.03 TCP from ruby to sard seq 4F693571, ack 5208FA0D, window 50000, 1176 bytes
0.03 TCP from ruby to sard seq 4F693A09, ack 5208FA0D, window 50000, 1460 bytes
0.03 TCP from ruby to sard seq 4F693FBD, ack 5208FA0D, window 50000, 1460 bytes
0.04 TCP from ruby to sard seq 4F694571, ack 5208FA0D, window 50000, 1176 bytes
0.04 TCP from ruby to sard seq 4F694A09, ack 5208FA0D, window 50000, 1460 bytes
0.04 TCP from ruby to sard seq 4F694FBD, ack 5208FA0D, window 50000, 1460 bytes
0.04 TCP from ruby to sard seq 4F695571, ack 5208FA0D, window 50000, 1176 bytes
0.04 TCP from ruby to sard seq 4F695A09, ack 5208FA0D, window 50000, 1460 bytes
0.04 TCP from ruby to sard seq 4F695FBD, ack 5208FA0D, window 50000, 1460 bytes
0.04 TCP from ruby to sard seq 4F696571, ack 5208FA0D, window 50000, 1176 bytes
0.04 TCP from ruby to sard seq 4F696A09, ack 5208FA0D, window 50000, 1460 bytes
0.05 TCP from ruby to sard seq 4F696FBD, ack 5208FA0D, window 50000, 1460 bytes
0.05 TCP from ruby to sard seq 4F697571, ack 5208FA0D, window 50000, 1176 bytes
0.05 TCP from ruby to sard seq 4F697A09, ack 5208FA0D, window 50000, 1460 bytes
0.05 TCP from ruby to sard seq 4F697FBD, ack 5208FA0D, window 50000, 1460 bytes
0.05 TCP from ruby to sard seq 4F698571, ack 5208FA0D, window 50000, 1176 bytes
0.05 TCP from ruby to sard seq 4F698A09, ack 5208FA0D, window 50000, 1460 bytes
0.05 TCP from ruby to sard seq 4F698FBD, ack 5208FA0D, window 50000, 1460 bytes
0.05 TCP from ruby to sard seq 4F699571, ack 5208FA0D, window 50000, 1176 bytes
0.05 TCP from ruby to sard seq 4F699A09, ack 5208FA0D, window 50000, 1460 bytes
0.06 TCP from ruby to sard seq 4F699FBD, ack 5208FA0D, window 50000, 1460 bytes
0.06 TCP from ruby to sard seq 4F69A571, ack 5208FA0D, window 50000, 1176 bytes
0.06 TCP from ruby to sard seq 4F69AA09, ack 5208FA0D, window 50000, 1460 bytes
0.06 TCP from ruby to sard seq 4F69AFBD, ack 5208FA0D, window 50000, 1460 bytes
0.06 TCP from sard to ruby seq 5208FA0D, ack 4F697571, window 44456, 
0.06 TCP from sard to ruby seq 5208FA0D, ack 4F69B571, window 50000, 
------> BIG DELAY !!!!!!!!!
0.60 TCP from ruby to sard seq 4F69B571, ack 5208FA0D, window 50000, 216 bytes
0.62 TCP from sard to ruby seq 5208FA0D, ack 4F69B649, window 50000,

If some kind soul can explain this delay I will be very grateful.
Is there any way to get around this problem in software?
What is particularly strange about all this, is that when a message 
is sent from some other workstation (not ruby), delay becomes significant
only for much larger messages (~100K). My system administrator says
that there is no difference between that workstation (ruby) and the others, 
but that doesn't seem to be true. Where should I look for the difference?

Thanks, 

Nesha

-- 
Nenad Nedeljkovic                        -------------------------------
   Internet: nedeljn@flint.cs.orst.edu  | Department of Computer Science  
   Phone:    (503) 737 - 5571 (office)  | Oregon State University           
             (503) 752 - 7632 (home) 	| Corvallis, OR 97331

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 May 1992 23:34:47 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Large Messages with TCP (again)

In article <1992May10.185217.27100@CS.ORST.EDU>, nedeljn@flint.cs.orst.edu (Nenad Nedeljkovic - Nesha) writes:
> A week ago I posted a question regarding transmission of large messages
> with TCP, between Sun workstations connected over Ethernet.
> Thanks to all the people who responded to my message, but I am still
> puzzled. Art Mellor suggested monitoring the packets on the wire, and 
> although I've done that, things are still far from clear.
> I am sending the output from 
> 
> 	etherfind -t -v proto tcp and between ruby sard 
> 
> produced when a message of 40,000 bytes is sent from ruby to sard.
> 
>0.03 TCP from ruby to sard seq 4F691A09, ack 5208FA0D, window 50000, 1460 bytes
>0.03 TCP from ruby to sard seq 4F691FBD, ack 5208FA0D, window 50000, 1460 bytes
>0.03 TCP from ruby to sard seq 4F692571, ack 5208FA0D, window 50000, 1176 bytes
>0.03 TCP from ruby to sard seq 4F692A09, ack 5208FA0D, window 50000, 1460 bytes
>0.03 TCP from ruby to sard seq 4F692FBD, ack 5208FA0D, window 50000, 1460 bytes
>0.03 TCP from ruby to sard seq 4F693571, ack 5208FA0D, window 50000, 1176 bytes
> ...

The 1176 byte packets may be an unfortunate result of some kind of buffering.
Contemplate the sum 1460+1460+1176.

TCP from a Sun to a Silicon Graphics IRIS is terribly slow, unless you
reduce the IRIS receive window.  We think it is an unfortunate interaction
among the Sun 4KB buffering, the IRIS 60K TCP window, the IRIS 4.3BSD
delayed ACKs, and perhaps an oddity in the Sun silly-window-syndrome
avoidance code.

>0.06 TCP from ruby to sard seq 4F69AA09, ack 5208FA0D, window 50000, 1460 bytes
>0.06 TCP from ruby to sard seq 4F69AFBD, ack 5208FA0D, window 50000, 1460 bytes
>0.06 TCP from sard to ruby seq 5208FA0D, ack 4F697571, window 44456, 
>0.06 TCP from sard to ruby seq 5208FA0D, ack 4F69B571, window 50000, 
> ------> BIG DELAY !!!!!!!!!
> 0.60 TCP from ruby to sard seq 4F69B571, ack 5208FA0D, window 50000, 216 bytes
> 0.62 TCP from sard to ruby seq 5208FA0D, ack 4F69B649, window 50000,

How big is the delay? How are you measuring it?  How are you generating
the traffic?--by FTP or rcp?  If so, could the delay be disk delays on
the receiver?


Vernon Schryver,


-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 May 92 04:05:48 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: Large Messages with TCP (again)

In <kkf6c20@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>TCP from a Sun to a Silicon Graphics IRIS is terribly slow, unless you
>reduce the IRIS receive window.  We think it is an unfortunate interaction
>among the Sun 4KB buffering, the IRIS 60K TCP window, the IRIS 4.3BSD
>delayed ACKs, and perhaps an oddity in the Sun silly-window-syndrome
>avoidance code.

I'm not sure what Vernon considers "terribly slow".  Using our tsock program
(ttcp with a few more options) I get about 650 KB/sec sending 128K messages
from a Sun 670MP running SunOS 4.1.2 to a SGI 4d/320 running IRIX 4.0.4.
This is using default 60K buffering on SGI and 4K on Sun.
 
It doesn't look like Sun -> SGI does that bad. 
 
One of the extra options we have in tsock is to do SO_SNDBUF/SO_RCVBUF
to specified values.  When I lower the SGI's buffer to 4k, I get about
550 KB/sec, so it doesn't seem that SGI's larger default buffer size hurts
Sun -> SGI transfers.  If I raise the Sun to a 51k buffer (the largest
it will let me set), I get 930 KB/sec., so larger buffers on the Sun
definitely help.

I get similar results sending from a Sun 4/470 running SunOS 4.1.1.

Steve Jay
shj@ultra.com  ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130	"Home of the 1 Gigabit/Second network"

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      11 May 92 06:21:46 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

In article <42769@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
>The commonality between the two scenarios is that the laddr,lport,
>raddr,rport are identical.  The key discriminators are the send and receive
>sequence numbers.  In the case with two end points, RFC 793 even has
>an example discussing the "cross SYN" case with two distinct end
>points (page 32).  The difference with one end point is that you are
>sharing the send and receive sequence numbers.  Unlike the example
>in the RFC, you can't simply handshake the sequence numbers and 
>consider the connection established (i.e. sequence numbers are incremented
>during the handshake).

I know that intuition seems to indicate that this is the case, but
it's not.  Since TCP is symetric, the send and receive sequence
numbers act independently and the fact that a port connecting to
itself will supply the sequence number for both directions from the
same sequence counter is immaterial.  It's just as if both sides of a
two ported connection happened to pick the same initial sequence
number.  If you write out the events in a crossing SYN in that case,
you'll see that the fact that they both start at the same sequence
number doesn't have any effect on the outcome.

>I'm sure you can patch TCP to make this work, but what is gained?

Compliance, i guess.  And, who knows?, maybe someday someone will come
up with a TCP application the takes advantage of crossing SYNs.  Since
it's already been shown to be simple to fix, i'm not going to worry
much about *whether* it should be fixed.
						don provan
						donp@novell.com

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 May 1992 06:35:28 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

In article <1992May8.150125.12401@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
>The apparent logic behind the RFC recommendation, is that if the
>segment is entirely outside the window, then it is probably an old
>duplicate, and should be discarded.  Under those circumstances,
>though, it really can't hurt to re-process an old ACK you've already
>seen before, so why not do the ACK processing anyway?

I don't have my spec with me to follow you exactly, but the "modern"
recommendation is to process *all* ACK information to prevent exactly
this type of problem.  It can also come up during data transfer in odd
cases (two way data flow, simultaneous crossing ACKs lost, subsequent
ACKs always piggybacked on retransmitted data).

In this particular case, though, i think there may just be a misreading
of the spec.  After all, the "empty" packet being discarded is, after
trimming, just a typical ACK-only packet.  I mean, if this packet is
"entirely outside the window", wouldn't nearly all simple ACK packets
also have to be discarded for being outside the window?

I'll try to remember to look this up tomorrow to see if what i just
said is silly....
						don provan
						donp@novell.com

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      11 May 92 18:28:31 -0700
From:      ewilts@galaxy.gov.bc.ca (Ed Wilts)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Catalog of Resources

In article <1992May11.235251.18159@morrow.stanford.edu>, BA.CGB@forsythe.stanford.edu (Clif Baker) writes:
> 
> The April 20th issue of Network World [pg 31] has the start of an
> article by Skip MacAskill.  The subject is an INTERNET CATALOG.
> 
> The catalog is a compiled listing of internet resources brought
> together by Jerry Martin of the NIC at Ohio State University.  The
> title of the work is "There's Gold in Them Thar Networks" <--- no
> cracks, I didn't make the title!!  :-)
> 
> I'm missing the end of the article which probably has the "if you
> want this call/write to" information.
> 
> Do any of you have the information on how to obtain the guide?

This sounds the same as RFC 1290.  Available at an FTP site near you...

-- 

Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
EWilts@Galaxy.Gov.BC.CA   |   Ed.Wilts@BCSystems.Gov.BC.CA   |   (604) 389-3430

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 May 1992 07:06:05 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Large Messages with TCP (again)

In article <1992May11.040548.15182@ultra.com>, shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
> In <kkf6c20@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> >TCP from a Sun to a Silicon Graphics IRIS is terribly slow, unless you
> >reduce the IRIS receive window.  We think it is an unfortunate interaction
> >among the Sun 4KB buffering, the IRIS 60K TCP window, the IRIS 4.3BSD
> >delayed ACKs, and perhaps an oddity in the Sun silly-window-syndrome
> >avoidance code.
> 
> I'm not sure what Vernon considers "terribly slow".  Using our tsock program
> (ttcp with a few more options) I get about 650 KB/sec sending 128K messages
> from a Sun 670MP running SunOS 4.1.2 to a SGI 4d/320 running IRIX 4.0.4.
> This is using default 60K buffering on SGI and 4K on Sun.
>  
> It doesn't look like Sun -> SGI does that bad. 
>  ...


650KB is "rather slow".  950KB is "ok, but not fast".  1150 KB is "ok".

"Terribly slow" was < 100KBytes/sec.  Packet traces showed a retransmission
every 4KBytes.  I think the last we tried was SunOS 4.0.something on a few
Sun 4's, and I haven't heard the customer complaints lately, so maybe
something changed.


Vernon Schryver,  vjs@sgi.com


-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      11 May 92 14:09:55 GMT
From:      danson@lgc.com (Doug Anson)
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing MacSLIP

In article <a63175bb@hydepark.com>, rick@hydepark.com (Rick Watson) writes:
|> [ Apologies if you get this more than once. ]
|> [ My regular news poster seems to be stuck. ]
|> 
|> Hyde Park Software is pleased to announce the availability of 
|> MacSLIP -- a SLIP Link Access Protocol Module for MacTCP. 
|> 
|> MacSLIP allows you to extend the network connectivity of your 
|> Macintosh to locations that might not be accessible to a LocalTalk
|> or Ethernet network via a modem connection over the telephone
|> or a hardwired connection to a SLIP Server. SLIP (Serial Line IP)
|> is a protocol that allows many simultaneous IP connections to run
|> over a single serial connection to a SLIP Server (a terminal
|> server or other host that supports SLIP). Instead of running a single
|> terminal emulator session over your serial port, MacSLIP allows you
|> to run simultaneous Telnet, FTP, News, Mail, and other MacTCP based
|> applications. You can even run XWindows although XWindow based
|> applications tend to require lots of bandwidth.
|> 
|> MacSLIP supports normal SLIP connections as well as connections that
|> allow TCP Header Compression (CSLIP).  TCP Header Compression is a 
|> method for compressing the headers of TCP/IP datagrams to improve
|> performance over relatively slow serial lines. Not all SLIP Servers
|> support CSLIP but MacSLIP will work either way.
|> 
|> MacSLIP's connection script facility allows automated modem dialing,
|> logging into a SLIP Server, establishing a SLIP session, etc.
|> The script facility will write a log of the connection process for
|> easy debugging of your script. Sample scripts are provided.  During
|> the connection, a script status dialog appears to notify the user of
|> the progress of the connection. The script can write messages to a
|> status area and can prompt the user for passwords or connection data.
|> The incoming character stream from the serial port is also displayed. 
|> 
|> The script facility supports sending strings, matching strings read
|>  from the serial port to control script execution, simple counters,
|> timers, loops, prompting for user input, and a status dialog to inform
|> the user of the script's progress. 
|> 
|> You can configure your Mac to use a static IP address or you can get
|> an IP address from your SLIP Server via the bootp protocol. 
|> 
|> Included in the package is Netstat, an application designed for
|> monitoring TCP connections to your Macintosh. Netstat displays all
|> open TCP connections' source and destination IP addresses, TCP ports,
|> and connection state. You can view all the internal counters that
|> MacTCP keeps for each connection as well as global MacTCP and MacSLIP
|> counters. 
|> 
|> Requirements:
|> 
|> - Any Macintosh running System 7 or a Mac-II class Mac running System 6.0.7.
|> - MacTCP 1.1 (or MacTCP 1.1+ for a Mac Plus)
|> - A serial connection to a SLIP Server via modem or hardwired connection.
|> 
|> Availability:
|> 
|> We will begin taking orders immediately (Mon-Fri 8-5 CDT) with
|> shipping scheduled to begin the week of May 25. Sales and support are
|> being provided by
|> 
|>     TriSoft
|>     1825 East 38 1/2 
|>     Austin, Texas 78722
|>     Sales: (800) 531-5170
|>     Support and Info: (512) 472-0744
|>     FAX: (512) 473-2122
|> 
|> Individual copies are $49.95 + shipping + sales tax if applicable.
|> Questions about MacSLIP and other pricing may also be sent to:
|> 
|>     info@hydepark.com
|> 
|> Rick Watson
|> Hyde Park Software
|> 
|> 
|> 

Is this really legal on the Internet?

-- 
-------------------------------------------
Doug Anson					
Internet: danson@lgc.com			
Phone:	  713-579-4739
SNAIL:    Landmark Graphics Corporation LGC	
	  333 Cypress Run			
	  Houston, TX 77094			
-------------------------------------------

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      11 May 92 14:31:42 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Large Messages with TCP (again)

I wrote a shell script that called ttcp in a nested loop, changing all
of the options in ttcp to see which one was the fastest.

In the middle of the loop, the time went from < 1 second to 15 or 30
seconds. There was no pattern that I could see.

I then looped on one particular test (keeping the parameters the
same), and noticed that occasionally the transfer times increased
significantly. The CPU usage at this time indicated less than 100% of
the CPU. I believe a page fault was the cause.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 May 1992 19:07:53 GMT
From:      ddb0248@mcnews.mcdata.com (David Beal)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Need *lots* of TCP connections on Interactive SVR3

Does anyone know of a STREAMS-based TCP/IP implementation that will
run on Interactive SVR3 version 3 and will support *a lot* of 
simultaneous TCP connections (like 500 to 1000) ?

Also, any advise on the amount of resources (RAM, STREAMS, buffers, etc.)
needed to achieve this amazing requirement would be appreciated.

Thanks!

Dave Beal
McDATA Corporation
ddb@mcdata.com


-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 May 1992 20:30:57 GMT
From:      pst@cisco.com (Paul Traina)
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing MacSLIP

In article <1992May11.140955.20064@lgc.com> danson@lgc.com (Doug Anson) writes:

   In article <a63175bb@hydepark.com>, rick@hydepark.com (Rick Watson) writes:
   |> ---- ---- Software is pleased to announce the availability of 
   |> ------ -- a SLIP Link Access Protocol Module for MacTCP. 
   
   [entire text of product announcement repeated by Mr. Anson]

   Is this really legal on the Internet?

Did you need to reproduce the whole thing?
Clues are available at major retailers, please get one.
--
Our apparent freedom to do whatever we like shows how whatever we choose
serves the economy.	-- Raoul Vaneigem, _The Book of Pleasures_

Have a fuel-air enema, you'll feel much better.  -- Dan Guilderson

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 May 1992 20:58:15 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: ip over token-ring


I would like to thank everybody who posted and E-mailed me responses 
concerning how to send TCP-IP packets over Token-Ring.  I asked whether
there were any public domain packages which would allow me to do this and
received many responses.  I hope that I responded individually to all of them,
but I may have missed a few.  What I did was to down-load the Clarkson 
packet-driver routines from NCSA's FTP cite.  One of the drivers is  
IBMTOKEN.COM which seems to work with the Token-Ring board which is Installed.
After also down-loading NCSA telnet, I was able to configure it according to
instructions and get, what appears to be an error-free configuration.  
At this time, it is also function-free until we get another test setup 
on our Novel system so that I can test with it.  Right now, there are no 
other TCP speaking systems on the network so I can only guess that it is
working.  Again, thanks to all who responded with suggestions.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 May 1992 21:08:20 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: VT5250 terminal and TCP/IP terminalserver in connection with AS400?


The question was asked whether there were any terminal servers which would
work with a VT52 terminal.  The 3Com line of terminal services should do
so.  

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 May 1992 23:52:51 GMT
From:      BA.CGB@forsythe.stanford.edu (Clif Baker)
To:        comp.protocols.tcp-ip
Subject:   Internet Catalog of Resources

Folks,

The April 20th issue of Network World [pg 31] has the start of an
article by Skip MacAskill.  The subject is an INTERNET CATALOG.

The catalog is a compiled listing of internet resources brought
together by Jerry Martin of the NIC at Ohio State University.  The
title of the work is "There's Gold in Them Thar Networks" <--- no
cracks, I didn't make the title!!  :-)

I'm missing the end of the article which probably has the "if you
want this call/write to" information.

Do any of you have the information on how to obtain the guide?

Clif

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      12 May 92 01:27:15 GMT
From:      dwb@austin.apple.com (David W. Berry)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.mac.misc,comp.lang.postscript
Subject:   Re: Berkeley LPD to Appletalk Postscript print servers?

>  Does anyone know if any software for the Macintosh exists that can 
 receive
>  LPD requests from a UNIX host (via MacTCP) and re-spool them using 
 appletalk
>  protocols to a postscript printer that is localtalk or ethertalk 
attached?

Any macintosh running any A/UX >= 2.0 can also do this.

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 May 1992 08:10:08
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP/IP toolkits for PC's

In article <2773@media03.UUCP> rla@media03.UUCP (Raymond van der Laan) writes:

    
    Programmer's toolkits for DOS-TCP/IP programs:
    
    Name        Price       Requirements          Sockets     RPC   DLL  TSR
    ========================================================================
    FTP         $700*       PC/TCP Kernel ($300*) Yes         Yes   Yes  Yes?

Actually, our US list is $500 for the Dev. Kit, and $200 for the kernel.
We recommend that developers buy the complete PC/TCP instead of just the
kernel, since that way they have many more applications to prove their
configuration is right with.  Also, TSR support is a definite YES.  We
include an example in source-code form.

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


-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 May 1992 03:20:25 GMT
From:      joer@137.148.5.52 (Joe Rosenfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: A PC with 2 Ethernet interfaces?

In article <1992May2.021204.21557@cs.sfu.ca> skl@cs.sfu.ca (Samuel Lam) writes:
>From: skl@cs.sfu.ca (Samuel Lam)
>Subject: Re: A PC with 2 Ethernet interfaces?
>Keywords: PC Ethernet interfaces TCP IP socket
>Date: Sat, 2 May 1992 02:12:04 GMT
 
>In article <jpc.704664163@avdms8.msfc.nasa.gov>, jpc@avdms8.msfc.nasa.gov
> (J. Porter Clark) wrote:
>>Does anybody out there know of hardware and software which would allow
>>a PC to have two physical Ethernet interfaces which run
>>simultaneously?  This setup would also need a socket-based programming
>>interface which would allow reading and writing to each interface from
>>the same application program.  Oh, yes, it needs to support TCP/IP.
 
>KA9Q would fit the bill.
 
>It's in ftp.ucsd.edu:hamradio/packet/tcpip/ka9q/ .
 
>...Sam
>-- 
>Samuel Lam <skl@cs.sfu.ca>
>Network Support Group, Centre for Systems Science
>Simon Fraser University, Burnaby, B.C., Canada

I am not disputing this, but if you are running a PC then you might also 
wish to investigate the files in pktmux11.exe, located at sunee.uwaterloo.ca 
in the pub/wattcp (or pub/wattcp/uploads) directory.  This program allows 
multiple sessions off of a SINGLE ethernet interface and is certainly 
interesting enough to ftp anonymously and give it a whirl.  It also works in 
Windows, with Desqview, and using different tcpip drivers concurrently.


Regards-
Joe

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 May 1992 03:39:46 GMT
From:      joer@137.148.5.52
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing MacSLIP

In article <PST.92May11123057@lager.cisco.com> pst@cisco.com (Paul Traina) writes:
>From: pst@cisco.com (Paul Traina)
>Subject: Re: Announcing MacSLIP
>Date: Mon, 11 May 1992 20:30:57 GMT
 
>In article <1992May11.140955.20064@lgc.com> danson@lgc.com (Doug Anson) writes:
 
>   In article <a63175bb@hydepark.com>, rick@hydepark.com (Rick Watson) writes:
>   |> ---- ---- Software is pleased to announce the availability of 
>   |> ------ -- a SLIP Link Access Protocol Module for MacTCP. 
>   
>   [entire text of product announcement repeated by Mr. Anson]
 
>   Is this really legal on the Internet?
 
>Did you need to reproduce the whole thing?

Anal retentive ...

>Clues are available at major retailers, please get one.

I dunno ... hmmm ... could he afford one?

>--
>Our apparent freedom to do whatever we like shows how whatever we choose
>serves the economy.     -- Raoul Vaneigem, _The Book of Pleasures_
 
>Have a fuel-air enema, you'll feel much better.  -- Dan Guilderson

Precisely the proper prescription.  Hope he takes it.

Ice

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 May 92 15:03:22 GMT
From:      amanda@visix.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing MacSLIP

danson@lgc.com (Doug Anson) writes:
> Is this really legal on the Internet?

It was certainly very bad manners...


Amanda Walker						      amanda@visix.com
Visix Software Inc.				    ...!uupsi!visix.com!amanda
-- 
"When's the last time you read an X header for documentation?"
		--Andrew Bernard

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 May 1992 15:04:47 GMT
From:      ralphd@Newbridge.COM (Ralph Doncaster)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP/IP toolkits for PC's

In article <2773@media03.UUCP> rla@media03.UUCP (Raymond van der Laan) writes:
>
>I think FTP and/or Turbosoft are the best candidates to solve our needs.
>(remember, we need to write a TSR which contains all network-related
>code and is accessed from a DOS-application via an interrupt.)
>
FTP's performance is far less than Sun's NFS.
Doing compiles on a 486-33 of files NFS mounted off a Sun Sparc based server, was 2-3x faster than the same compiles on the same machine using FTP's nfs.
(also, if memory serves me correct, SUN's product can be loaded into high mem, but not all of FTP's can)
I'm not saying everyone will get that kind of performance difference, but it's worth comparing.

-- 
Ralph Doncaster, Newbridge Networks, 600 March Rd.,Kanata, ON (613)591-3600
ralphd@newbridge.com   home: 225-8992; 4 Glendridge Rd, Nepean, ON, K2G 2Z5

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      12 May 92 18:26:26 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR from VAX/VMS to System V(WIN TCP & priveleged sockets)


In article <AAjiX1g0m0@inpbox.inp.nsk.su>,  kondrat@inpbox.inp.nsk.su (Igor V. Kondratiev) writes:
|>Hi, folks!
|>
|>Help me to resolve a problem, please:
|>
|>I'm attempting to port NCSA's LPR-client from DOS to VAX/VMS.
|>So, I didn't found any tools in WIN TCP/IP to create privileged (<1023) socket.

WIN/TCP includes LPR and LPD, but if you really want to do this on your own,
try calling 'rresvport()' as documented in the WIN/TCP programmer's guide.
Note that this requires the SYSPRV privilege.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      12 May 92 19:42:30 GMT
From:      ehrlich@cs.psu.edu (Dan Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP vs Host Routes

Hello all.  I am trying to set up an SS1 that will have two IPCs dialing up
and using PPP.  I have installed the ethernet addresses into the ARP cache
of the SS1 but hosts not on the same subnet can not find a route to the
IPCs.  Adding a host route does nothing useful.  
--
Dan Ehrlich - Sr. Systems Programmer - Penn State Computer Science
<ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 May 92 20:50:34 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP is not proprietary

Can someone please explain to me why John Gantz believes TCP/IP to be
proprietary?  In his current "White Paper to Management" in
"Networking Management" 5/92, he continually refers to TCP/IP as
proprietary, then he admits that "OSI products aren't ready yet or
cost too much".

He spends a fair bit of time wondering "what does it mean to be
open".  Well, here's a reasonable definition, John: "If it's an open
system, then there exists free market competition."  TCP/IP and the
Internet is an example of what happens when you let people find the
best solution to their problem.  OSI is an example of what happens
when you dictate a solution.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 May 1992 21:26:38 GMT
From:      schneck@Physik.TU-Muenchen.DE (Bernhard Schneck)
To:        comp.protocols.tcp-ip
Subject:   Wanted: SLIP for SunOS 4.1.1/4.1.2

Hi,

(I asked the same question on comp.sys.sun.wanted a week ago and got
one pointer to PCNFS (seems to include a SLIP server for sparcs) and
several "me too"s ...)

what is the current version of (compressed) SLIP for sparcs running
SunOS4.1.1 or 4.1.2?

All I found are the slip-4.0 (for 4.0.x) and cslipbeta (no complete SUN
support, references to slip-4.0 ??) packages.

Thanks,
\Bernhard.
--
Bernhard Schneck        Internet: Bernhard.Schneck@Physik.TU-Muenchen.DE
TU Muenchen Physik
8046 Garching           "There is no problem so big that it cannot be
Germany                 run away from"                  Illusions, Richard Bach

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      12 May 92 23:56:57 GMT
From:      oldera@twg.com (Ed R. Alcoff)
To:        comp.protocols.tcp-ip
Subject:   Re: LANtastic 4.1 & TCP/IP

Artisoft has announced a "letter of intent" to acquire Performance
Technology, a San Antonio, Texas company who shared PC Magazine's
Editor's Choice award with LANtastic in the most recent issue.

I am not in a position to comment on whether or not they are
"competitors"- we have been working with P.T. for the last 3 years.

Both companies' products interoperate with our TCP/IP for DOS.

Ed Alcoff
Product Line Manager
The Wollongong Group, Inc.

e-mail:oldera@twg.com
(415) 962-7240

#std. disclaimer: these opinions are my own and are not 
my employer's.


-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 May 1992 03:18:36 GMT
From:      rsivaram@vela.acs.oakland.edu (SIVARAMAN R)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Help needed in using 'depca'...



To all packet driver gurus,
	I am trying to install the packet driver 'depca' 
developed by clarkson university but finding some problems.
I am using the digital's depca card and running decnet in my 
machine. After loading the depca program sometimes my machine
crashes. My purpose is to run telnet after loading depca.
Once I use telnet all network drives are not getting recognized.
I am also unable to use the 'sethost' program to connect to
the network. I would really appreciate if someone could 
help me out
thanks in advance
-siva 






-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      13 May 92 14:47:15 -0600
From:      dan@gacvx2.gac.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing MacSLIP

In article <1992May12.150322.656@visix.com>, amanda@visix.com (Amanda Walker) writes:
> danson@lgc.com (Doug Anson) writes:
>> Is this really legal on the Internet?
> 
> It was certainly very bad manners...
> 
> 
> Amanda Walker						      amanda@visix.com
> Visix Software Inc.				    ...!uupsi!visix.com!amanda
> -- 
> "When's the last time you read an X header for documentation?"
> 		--Andrew Bernard

In the new NSFnet acceptable use policy, in the section, "Specifically
Acceptable Uses", number 7 is:

7.	Announcements of new products or services for use in research or
instruction, but not advertising of any kind.

As a person who supports reasearchers who have been pushing for SLIP access for
some time, this announcement was of interest to me and of course them.  If
taken as a new product announcement it would be acceptable for transport over
the NSFnet, however USENET has other rules than just the ones that the use of
NSFnet for some news transmissions impose.  Check news.newusers.questions for
those.

Don't forget to ask all the people with 2400 baud UUCP news feeds as well first
before posting anything.  I hear they really don't want any news, since they
have to pay for receiving it if they want it or not. :-)

-- 
Dan Boehlke                    Internet:  dan@gac.edu
Campus Network Manager         BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)933-7596

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 May 1992 05:17:55 GMT
From:      Lawrie.Brown@adfa.oz.au
To:        comp.protocols.tcp-ip
Subject:   Anyone had experience with Secure TCP?

I am supervising a research project that is concerned with adding security
and authentication extensions to TCP/IP based network tools. To date we have
been involved in the design and implementation of extensions to Telnet 
and FTP to provide these features. I am now interested in providing generic
security extensions to the TCP layer to supply authentication and encryption
of information exchanged., which may then be invoked by any applications 
requiring this service. I am aware of the SDNS project, and am interested
in hearing from anyone who has experience implemeting its, or any other
protocol extensions to TCP (or equivalent) to provide this type of security.

Thankyou in anticipation.

Dr Lawrie Brown

-----
Dr Lawrie Brown,		        Phone: +61 6 2688816
Dept. Computer Science, UC, UNSW,   	Fax:   +61 6 2688581
Australian Defence Force Academy,   	Telex: ADFADM AA62030
Canberra ACT 2600. AUSTRALIA	    	Email: Lawrie.Brown@adfa.oz.au

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 May 1992 05:41:18 GMT
From:      Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
To:        comp.protocols.tcp-ip
Subject:   MacSLIP

In defense of Rick Watson, I would like to say as one of his beta testers that
MacSLIP is a *wonderful* product.  It has transformed my Mac PowerBook from a
toy into the useful engine I had intended it to be.  It is easily worth the
$50 he is asking for it, and long overdue.

If I had not been a beta tester, I would have found the announcement about
MacSLIP to be perhaps *the* most important message on this newsgroup this
year.  Perhaps Rick should have asked a beta tester to post the announcement
instead of doing so himself, or perhaps he should have omitted prices.
However, ignoring those minor nits for now, let me reiterate that this is a
*great* product.  I would have cheerfully paid quite a bit more for it.

As a side note for anyone who is considering SLIP on a Mac PowerBook, let me
also recommend the Global Village PowerPort V.32 modem.  You can get it mail
order for under $500.  It has V.32 and V.42bis with a maximum throughput of
38400 bps.  It also has 9600 bps FAX capability and some nice FAX software to
go with it.  The only negatives are no V.32bis and it uses an external dongle
for the phone interface (the modem itself is internal).  However, it's
presently *the* V.32 internal modem option for the PowerBook.

At under $2000 for a complete configuration (PowerBook, MacTCP, MacSLIP, and
modem), this is a great portable TCP/IP station for the hacker on the move!

Disclaimer: I have no relation to any of the above vendors other than being a
*very* happy user.


-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 May 92 12:28:43 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Help needed in using 'depca'...

In article <1992May13.031836.24311@vela.acs.oakland.edu> rsivaram@vela.acs.oakland.edu writes:

   To all packet driver gurus,
           I am trying to install the packet driver 'depca' 
   developed by clarkson university but finding some problems.
   I am using the digital's depca card and running decnet in my 
   machine. After loading the depca program sometimes my machine
   crashes.

Sigh.  Siva, packet drivers have version numbers because they change.
The change because they're deficient in some way.  Perhaps the
deficiency you're experiencing has already been fixed.  How would I
know, from reading your posting?

Please, folks, when you're reporting a possible bug in software,
ALWAYS include the version number of the software.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      13 May 92 13:16:32 GMT
From:      pathak@mitre.org (Heeren Pathak)
To:        comp.protocols.tcp-ip
Subject:   Re: MacSLIP

In article <MS-C.705735678.662824084.mrc@Tomobiki-Cho.CAC.Washington.EDU>,
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
> 
> If I had not been a beta tester, I would have found the announcement about
> MacSLIP to be perhaps *the* most important message on this newsgroup this
> year.  Perhaps Rick should have asked a beta tester to post the announcement

The debate is not the importance to the announcement, just the legality. 
It is my understanding that Internet is not supposed to be used for
commerical product announcements.  If I want to read about products, I can
pick up one of the trade rags.

-------------------------------------------------------------------------
Heeren Pathak                      | Television is a device that permits
pathak@mitre.org                   | people who haven't anything to do to
Mitre Corporation                  | watch people who can't do anything.
(617) 271-7465                     |	               	-- Fred Allen
-------------------------------------------------------------------------
Disclaimer: Mine not Mitre's.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      13 May 92 14:18:12 GMT
From:      pierson@ketje.enet.dec.com (Jacques Pierson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Help needed in using 'depca'...

Siva, You should not try to load *both* a depca DLL and a Packet Driver at
the same time. The way to go is load DLL and get DLL_PKT (can't remember
for sure but I think it is included in the version 10 distribution of Packet
Drivers)
to be loaded on top of DLL. Then you can use Packet Driver based software
without messing up the DLL.

Jacques Pierson
DEC Brussels, Belgium

I only speak for myself, not for DEC.
 

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      13 May 92 15:49:14 GMT
From:      alberti@mudhoney.micro.umn.edu (Albatross)
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing MacSLIP

In <1992May12.150322.656@visix.com> amanda@visix.com (Amanda Walker) writes:

>danson@lgc.com (Doug Anson) writes:
>> Is this really legal on the Internet?
 
>It was certainly very bad manners...

You want bad manners?  He contacted us here at the University of Minnesota a
month ago and asked for a copy of the source to our public domain Mac SLIP
for "his own little project".  Next thing you know he's selling a Mac SLIP
product.  VERY bad manners.

--
Bob Alberti: Computer & Information Services U of MN | aka: Albatross | Unitar-
E-mail     : alberti@boombox.micro.umn.edu           | Metropolis BBS | ian/
Disclaimer : My employer does not mean what I say.   | (612) 721-1870 | Univer-
Minnesota  : Where butter is a spice.                | BBSing as art. | salist!

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      13 May 92 16:00:39 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: MacSLIP

In article <1992May13.131632.24674@linus.mitre.org>, pathak@mitre.org (Heeren Pathak) writes:
|> In article <MS-C.705735678.662824084.mrc@Tomobiki-Cho.CAC.Washington.EDU>,
|> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
|> > 
|> > If I had not been a beta tester, I would have found the announcement about
|> > MacSLIP to be perhaps *the* most important message on this newsgroup this
|> > year.  Perhaps Rick should have asked a beta tester to post the announcement
|> 
|> The debate is not the importance to the announcement, just the legality. 
|> It is my understanding that Internet is not supposed to be used for
|> commerical product announcements.  If I want to read about products, I can
|> pick up one of the trade rags.

FLAME ON

Please stop the complaining.  The announcement should have been made to
comp.newprod where anyone interested in new products could have seen it.
In this case it wasn't.  If it concerns you please type 'n' and forget
it.  If it really concerns you, MAIL the offender, don't just sit back 
and post complaints.  If there are multiple offenders (not this case)
then maybe a post is in order.  Point out that there are FAQs on how to use
the net.  Postings should be of a general interest.  If a communication
is directed at a single person, it should be mailed.

FLAME OFF

Thanks, I needed that.
-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      13 May 92 16:49:00 GMT
From:      gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
To:        comp.protocols.tcp-ip
Subject:   Token Ring Information


	Can anyone point me at online source of token-ring
	information.  General management, standards, ip over
	token ring, etc... 

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 May 1992 16:56:30 GMT
From:      pst@cisco.com (Paul Traina)
To:        comp.protocols.tcp-ip
Subject:   Re: MacSLIP

In article <1992May13.131632.24674@linus.mitre.org> pathak@mitre.org (Heeren Pathak) writes:

   It is my understanding that Internet is not supposed to be used for
   commerical product announcements.

The Internet may be used for whatever the heck the sites wish to use
it for.  Remember,  usenet >>> internet >>> NSFnet.  NSFnet has the
AUP.  You may have gotten his email or posting via a non-NSFnet path
(unlikely,  but possible).

However, conventional USENET/mailing-list manners requests that
product announcements be restricted to comp.newprod and its approriate
relayed mailing list.
--
Our apparent freedom to do whatever we like shows how whatever we choose
serves the economy.	-- Raoul Vaneigem, _The Book of Pleasures_

Have a fuel-air enema, you'll feel much better.  -- Dan Guilderson

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      13 May 92 18:27:07 GMT
From:      bwebb@gelac.lockheed.com (Mr. Barry W. Webb)
To:        comp.protocols.tcp-ip
Subject:   Ada Implementation of TCP/IP

Interested in corresponding with anyone who has knowledge of
an operational version of TCP/IP implemented in Ada.  Please
respond via the email address below.

Thanx in advance

-- 

Barry W. Webb                          UUCP: ...!gatech!warlord!gelac!bwebb
Lockheed Aeronautical Systems Company  Internet: bwebb@gelac.lockheed.com
Marietta, Georgia  30063-0670          Phone: (404) 494-6952    Fax: 6989

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 May 1992 18:38:31 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: 1's vs. 0's in broadcast address

In article <ufu55INNr9d@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
   In the original TCP design, the all 0 form was also used as the
   broadcast address.  This ended up being included in many BSD
   releases, even after the TCP spec was adopted with all 1 being the
   standard.  Sun has refused to change their default, presumably for
   compatibility reasons.

Solaris 2.0 Beta (Sun's SPARC port of SVR4) still defaults to using 0s
for broadcasts, and I've reported it as a bug.

But the recent release of Sun's own PC-NFS defaults to 1s.  This will
introduce compatibility with the standards and the rest of the world,
but inconsistency with the rest of Sun's products.  I wonder if
PC-NFS's behavior is a vanguard of correctness for the rest of Sun, or
an isolated (un)slip-up that will be "fixed" in the next release?

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 May 1992 20:53:23 GMT
From:      alberti@mudhoney.micro.umn.edu (Albatross)
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing MacSLIP

In <1992May13.154914.26451@news2.cis.umn.edu> alberti@mudhoney.micro.umn.edu (Albatross) writes:
>You want bad manners?  He contacted us here at the University of Minnesota a
>month ago and asked for a copy of the source to our public domain Mac SLIP
>for "his own little project".  Next thing you know he's selling a Mac SLIP
>product.  VERY bad manners.

First I'd like to apologize for the previous message.  It wasn't my business
and I shouldn't have posted it.

Second I'd like to make the point that I was not making an accusation of
illegality, I was upset by what I understood to be a misrepresentation, and
when I said 'bad manners' that's what I meant.  It turns out I misunderstood
the exchange of information which had taken place, and spoke out of turn.
I apologize for posting before understanding.
--
Bob Alberti: Computer & Information Services U of MN | aka: Albatross | Unitar-
E-mail     : alberti@boombox.micro.umn.edu           | Metropolis BBS | ian/
Disclaimer : My employer does not mean what I say.   | (612) 721-1870 | Univer-
Minnesota  : Where butter is a spice.                | BBSing as art. | salist!

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      13 May 92 20:59:35 GMT
From:      christos@dworkin.wustl.edu (Chris Papadopoulos)
To:        comp.protocols.tcp-ip
Subject:   TCP ack-only vs. window update packets


	Can someone explain to me the exact differences between TCP
ack-only and window update packets? Why aren't window update packets
acknowledgments? (they are reported differently by netstat -s).
In a unidirectional connection what type of packet would be sent to ack
data? The TCP inplementation I am looking at is the SunOS 4.0.3 TCP.
	Thanks,

Christos.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 May 1992 21:03:45 GMT
From:      scoggin@daisy.udel.edu (John K Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

In article <705703834snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>Can someone please explain to me why John Gantz believes TCP/IP to be
>proprietary?  In his current "White Paper to Management" in
>"Networking Management" 5/92, he continually refers to TCP/IP as
>proprietary, then he admits that "OSI products aren't ready yet or
>cost too much".
>
>He spends a fair bit of time wondering "what does it mean to be
>open".  Well, here's a reasonable definition, John: "If it's an open
>system, then there exists free market competition."  TCP/IP and the
>Internet is an example of what happens when you let people find the
>best solution to their problem.  OSI is an example of what happens
>when you dictate a solution.
>
>-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
>Crynwr Software            Crynwr Software sells packet driver support.
>11 Grant St.               315-268-1925 Voice
>Potsdam, NY 13676          315-268-9201 FAX

I believe that you will find this particular individual comments on a wide
range of subjects, including "Open Systems", PCs, networks, etc.  He is a
consultant.  I doubt VERY MUCH that he has any real first-hand experience
in most of the subject areas he comments on.  It seems that a lot of these
guys read each others' articles - it becomes kind of a feedback loop.  What
you get in most of these articles is whatever is "Politically Correct" at
the time.  These magazines were hyping ISDN as the grand solution a few years
ago.  

My advice - take anything you read in these mags with a grain of salt...

	- John

-------------------------------------------------------------------------
John K. Scoggin, Jr.			Email:   scoggin@udel.edu
Supervisor, Network Operations			 scoggin@delmarva.com
Delmarva Power & Light Co.		Voice:	 302-451-5200
P.O. Box 6066				Fax:	 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary.  Void where prohibited by law (or common sense).

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 May 1992 21:48:52 GMT
From:      bjd7p@uvacs.cs.Virginia.EDU (Bert J. Dempsey)
To:        comp.protocols.misc,comp.multimedia,comp.protocols.tcp-ip
Subject:   STREAM protocol

	Does anyone have pointer(s) to articles/other documents 
	   on the DARPA STREAM protocol?

	It was first proposed in IEN 119 as "ST" back in 1979,
	   but there is now an on-going implementation effort (?)
	   doing multimedia across STREAM gateways in the Internet.

	Any pointers appreciated.........


-- 
Bert Dempsey   (bjd7p@uvacs.cs.Virginia.EDU)
Computer Science, University of Virginia

  "There are approximately 250 mice per gallon."
		

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 May 92 05:55:35 GMT
From:      amanda@visix.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: MacSLIP

Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU> writes:
> If I had not been a beta tester, I would have found the announcement about
> MacSLIP to be perhaps *the* most important message on this newsgroup this
> year.

Should everyone who has written a SLIP module for the Mac now post a long
posting full of sales-speak about their product?  I'm sure that the other
vendors would be happy to oblige if this is indeed now the appropriate way to
use this mailing list/newsgroup...

What I suggested to Rick in email, and what I will reiterate here in public,
is that I would have been far more pleased to see his note in comp.newprod,
biz.comp.software, etc., with a short pointer article here and in places like
comp.sys.mac.comm.  I would have been even more pleased if he had waited until
his actual shipping date to announce it.  As it was, I found his posting to
be rather unprofessional.

> However, ignoring those minor nits for now, let me reiterate that this is a
> *great* product.  I would have cheerfully paid quite a bit more for it.

That's fine.

It's not, however, the only ball in the court, as should become quite apparent
at InterOp next week.  InterCon's been shipping their own SLIP for years.  As
another example, a product I have been testing has a much nicer UI and seems
to have noticeably better performance characteristics than "MacSLIP".  This
doesn't mean that I'm going to brag about it or rag on Rick's in this forum,
however.

Let's leave the product promos, etc. to the shows and commercial groups,
and keep this one free for technical issues.  Everything has its place.

> At under $2000 for a complete configuration (PowerBook, MacTCP, MacSLIP, and
> modem), this is a great portable TCP/IP station for the hacker on the move!

Indeed.

> Disclaimer: I have no relation to any of the above vendors other than being a
> *very* happy user.

Disclaimer: I used to work for InterCon, and am probably biased in their
favor.  I'm also a Usenet/ARPANET oldtimer, though, and I hate to see
marketing flash invade technical groups.

Grump grump,

Amanda Walker						      amanda@visix.com
Visix Software Inc.				    ...!uupsi!visix.com!amanda
-- 
"An architecture in hand is worth 4 or 5 in vapor."	--Eugene Miya

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      14 May 92 11:44:50 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   ip exercise

Hi folks.  I'm trying to get a comprehensive understanding of routing
and subnet masks.  I've already got a "fee" for subnet masks, but feel
that knowing a/any/all solutions to the following hypothetical situation
will help clarify this area:

Hypothetical Situation:
----------------------

You have 3 LANs, each one with 139 PCs and one Novell fileserver.  Most
of the traffic is local to each LAN segment, but each segment is bridged
to a backbone segment for the occasional inter-LAN traffic.

Next you get a Unix host, and decide that everyone needs access via
Telnet from their PCs using a multiprotocol stack (IPX/SPX & TCP/IP,
the vendor right now is probably unimportant).  You realize, "Egads, I
need a block of IP addresses, and in the future I may want to connect my
Unix host to the Internet," so you decide to take the politically
correct move, and apply to the NIC as appropriate.

The NIC learns you only have 140 * 3 + 1 (421) nodes and feels that 2
Class C networks (254 * 2) should suffice.  But will it?

Now you have a conundrum:  You can't (or shouldn't) break any of your
segments and stick a router or bridge in the break as you want to keep
your Netware users' performance at an optimum.  Yet, you have only 2
Class C's not 3.  What to do, what to do....

Is there a way to keep the existing configuration (removing the bridges
if necessary), add on multiport/redundant routers as necessary, set up
subnet masks, and keep both the users and the NIC happy?

Diagram:
          LAN A                       -
        |-------------T--|       --   |
         (140 nodes)  |---------|Br|--|  ------
          LAN B                  --   |--|Unix|
        |-------------T--|       --   |  ------
         (140 nodes)  |---------|Br|--|
          LAN C                  --   |
        |-------------T--|       --   |
         (140 nodes)  |---------|Br|--|
                                 --   |
                                      -

Replies to this newsgroup or direct will be appreciated.  I'll try to
summarize any direct replies to this newsgroup.

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 May 1992 07:34:25 GMT
From:      gsl@iti.gov.sg (Goh Soon Liong)
To:        comp.protocols.tcp-ip
Subject:   TCP push flag


Hello there,

I like to find out about the use of the PUSH flag of the CODE field in the
TCP header. My feeling is that this flag is set when the communication is in
a non-blocking mode, i.e., the PUSH flag is set by a fcntl call with a
O_NDELAY flag or a setsockopt call with a TCP_NODELAY flag. Can somebody
please verify this? If I am wrong, could somebody tell me how is the PUSH 
flag set using socket library calls.

Thanks in advance.

Goh Soon Liong
gsl@iti.gov.sg

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 May 1992 12:56:45 GMT
From:      mollett@lexmark.com (Vic Mollett)
To:        comp.os.os2.misc,comp.os.os2.networking,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: OS2 and VT5250 emulation ?

In article <19920508.053508.747@almaden.ibm.com> ian@vnet.ibm.com writes:
>In <1992May7.101742.5623@edfd.uucp> Markus Gruenkorn (MAGIC writes:
>>Hi guys !
>>I would like to know if there is an VT5250 emulation for OS2 out there.
>>We have a large network based on TCP/IP including AS400, PC's,
>>a MVS host, and different kinds of unix workstations. It would be nice
>>to connect from a PC with OS2 directly to a AS400. I read the deskription
>>of the IBM's TCP/IP package and could not find a VT5250 emulation !
>>
>>Any information would be appreciated!
>>--
>>------ < MAGIC > ------
>>
>
>There is 5250 emulation built into the OS/2 Communications Manager.
>In OS/2 1.x, this came as part of the EE package.  In 2.0 it has been
>split off into a separate package called Extended Services.

If you want to use the IBM TCP/IP 1.2 package for OS/2, you can use tn3270 or
pmant (which does PM 3270) to connect with an AS/400.  Although you use 5250
style hardware to connect via the twinax, 3270 works just fine thru TCP/IP.

>
>Cheers,
>Ian Stirling                      Internet: ian@vnet.ibm.com
>CICS/ESA Systems Facilities         Bitnet: ian at vnet
>IBM UK Labs Ltd, Hursley, England IBMIPnet: ian@stirling.hursley.ibm.com


-- 

                                             /\    Vic Mollett
 These opinions are my own and do not       /  \   Lexmark International, Inc.
 necessarily reflect those of my employer.  \  /   mollett@lexmark.com

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      15 May 1992 01:11:05 -0700
From:      tli@skat.usc.edu (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Practicality of using ICMP redirects

In article <1992May14.221421.3442@emr1.emr.ca> fillmore@emr1.emr.ca (Bob Fillmore 992-2832) writes:
    We have a problem with a shortage of IP addresses that we want to solve
    by configuring several subnets of our class B IP network on one Ethernet
    backbone.  We would like to do this by configuring the extra subnets
    as secondary addresses on a Cisco router interface attached to the backbone,
    and turning on ICMP redirects in the router.
    
    This all sounds fine in theory, but I would like to know how many TCP/IP
    implementations recognize the ICMP redirect messages.  Is anyone else
    out there doing this on their network?

    Thanks for any information.
    
The router will not issue redirects unless the source and the next hop
are on the same subnet.  

Tony Li
cisco Engineering
-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      14 May 92 13:56:39 GMT
From:      pgk@pacersoft.com (Paul Kamp)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.mac.misc,comp.lang.postscript
Subject:   Re: Berkeley LPD to Appletalk Postscript print servers?


In article <447@jumbo.Apple.COM>, dwb@austin.apple.com (David W. Berry) writes:
> 
> >  Does anyone know if any software for the Macintosh exists that can 
 receive
> >  LPD requests from a UNIX host (via MacTCP) and re-spool them using 
 appletalk
> >  protocols to a postscript printer that is localtalk or ethertalk 
> attached?
> 
> Any macintosh running any A/UX >= 2.0 can also do this.
> 
Pacer's PacerPrint software provides support for Unix users to send their
print requests throught the Unix spooler to printers out on the AppleTalk.
It is implemented using either the Berkeley or Sys V depending on the
Unix implementation.  We can access printer on either Localtalk or
EtherTalk.

I am pretty sure that Helio's EtherShare and IPT's Ushare do this also.

Paul Kamp
Pacer Software, Inc.
pgk@pacersoft.com


-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 May 1992 14:08:22 GMT
From:      kreidler@convex.rz.uni-duesseldorf.de (Homer Simpson)
To:        comp.protocols.tcp-ip
Subject:   cxi - Networkadapter

Does anyone know about a packet driver for an cxi networkadapter
for the ibm pc?

Thanks

Kay Kreidler, Department Of Chemistry
Heinrich Heine University Duuesseldorf, Germany

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      14 May 92 14:22:42 GMT
From:      jakob@ptt-iat (Jakob Schripsema)
To:        comp.protocols.tcp-ip
Subject:   Problem with printer connected to a terminal server


When I try to use a printer connected to a terminal server from a Unix box
I run into a problem I don't understand. Basically I write a program that
connect to the appropriate port of the terminal server, sends the data and
disconnects:
	....
	connect(..)
	send_data(..)
	close(..)
	....
For low speed printers I lose the last part of the data. Inserting a sleep
(e.g. sleep(30)) BEFORE the close cures the problem. I've seen this problem
with a UB ASM100 terminal server (Unix box is a Unisys U6000/55 SVR3) and
a Spider Systems terminal server (Unix box is a Unisys U6000/65 SVR4). It
seems as if the terminal server discards it's internal buffers after the data
has been transmitted and the connection is closed.
Has anyone else seen this problem and maybe knows a better solution ??
Inserting a sleep requires tuning, because the delay depends on the printer
speed.

Jakob Schripsema

------------------------------------------------------------
Jakob Schripsema    Informatievoorziening & Automatisering    PTT Telecom
P.O.Box 188         9700AD Groningen                      The Netherlands
Internet: jakob%ptt-iat@nluug.nl                phone@desk: +31 50 855537

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      14 May 92 15:08:41 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ack-only vs. window update packets

In article <23178@olympus.wustl.edu> christos@dworkin.wustl.edu (Chris Papadopoulos) writes:
>
>	Can someone explain to me the exact differences between TCP
>ack-only and window update packets? Why aren't window update packets
>acknowledgments? (they are reported differently by netstat -s).

Both types of information are contained in all packets, once the
connection is established.  The question is whether it just repeats old
data, or actually updates it.
Assume a TCP sends two segments in a row.  The second one
may or may not contain old (retransmitted) data,
may or may not contain new data, may or may not update the ack pointer
from the value in the previous segment, and may or may not open up
the window.  These are independent of one another.

Let 1 = yes, 0 = no, X = don't care.  Then I *think* the following is
accurate.  Because of the don't cares, some segments qualify for more
than one category, and are counted more than once.

OLD     NEW     NEW     WINDOW
DATA    DATA    ACK     UPDATE                 type

 X       X      X       X               'total packets received'
 1	 0	X	X               'completely duplicate packets'
 0       1      X       X               'packets received in sequence'
 1       1      X       X               'some dup. data'
 X       1*     X       X               'data after window'
 X       1**    X       X               'window probe'
 0       0      0       0               'dup ack'
 0       0      1       X               'ack packet'
 0       0      0       1               'window update'

*  New data is outside current window.
** Subset of previous case where window is closed and new data is at edge.

Pursuant to my recent droning in this newsgroup, it would be consistent 
with the spec if the last 3 rows didn't care about OLD DATA, but
many current implementations will drop segments containing old data but
no new data.

>In a unidirectional connection what type of packet would be sent to ack
>data? The TCP inplementation I am looking at is the SunOS 4.0.3 TCP.

Both, probably.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 May 1992 16:06:47 GMT
From:      karches@utdallas.edu (Tom Karches)
To:        comp.protocols.tcp-ip
Subject:   Re: Berkeley LPD to Appletalk Postscript print servers?

In article <660@pacvax.UUCP> pgk@pacersoft.com (Paul Kamp) writes:
>
>In article <447@jumbo.Apple.COM>, dwb@austin.apple.com (David W. Berry) writes:
>> 
>> >  Does anyone know if any software for the Macintosh exists that can 
 receive
>> >  LPD requests from a UNIX host (via MacTCP) and re-spool them using 
 appletalk
>> >  protocols to a postscript printer that is localtalk or ethertalk 
>> attached?
>> 
>> Any macintosh running any A/UX >= 2.0 can also do this.
>> 
>Pacer's PacerPrint software provides support for Unix users to send their
>print requests throught the Unix spooler to printers out on the AppleTalk.
>It is implemented using either the Berkeley or Sys V depending on the
>Unix implementation.  We can access printer on either Localtalk or
>EtherTalk.
>
>I am pretty sure that Helio's EtherShare and IPT's Ushare do this also.
>
>Paul Kamp
>Pacer Software, Inc.
>pgk@pacersoft.com
>

MachTen from Tenon Intersystems will do this also, in addition to allowing
access to printers connected to Unix systems from an Appletalk network.

It also happens to be 4.3BSD Unix with a Mach kernel that runs on any
Mac with 128K roms and 4MB of memory.

A satisfied user,

Tom Karches

-- 
-------------------------------------------------------------------------------
Tom Karches          |"If rap music had been around when I was a kid,
karches@utdallas.edu | I would have become a musician instead of a politician."
---------------------'----------------------------------- Richard Nixon

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      14 May 92 16:50:57 GMT
From:      craig@fred.gi.alaska.edu (Craig Helmuth)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

In article <705703834snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>Can someone please explain to me why John Gantz believes TCP/IP to be
>proprietary?  In his current "White Paper to Management" in
>"Networking Management" 5/92, he continually refers to TCP/IP as
>proprietary, then he admits that "OSI products aren't ready yet or
>cost too much".
>
>He spends a fair bit of time wondering "what does it mean to be
>open".  Well, here's a reasonable definition, John: "If it's an open
>system, then there exists free market competition."  TCP/IP and the
>Internet is an example of what happens when you let people find the
>best solution to their problem.  OSI is an example of what happens
>when you dictate a solution.
>
>-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
>Crynwr Software            Crynwr Software sells packet driver support.
>11 Grant St.               315-268-1925 Voice
>Potsdam, NY 13676          315-268-9201 FAX
>
John Gatnz has a history of being "a bubble off" imho.  As a longtime
InfoWorld reader, he always seemed to be blathering about something
that was silly.

However, he can be useful to listen to (take your maalox first!), in
the same way a movie reviewer you consistently never agree with can be
useful: take what he says and assume the opposite...

 Craig Helmuth, Network Manager  |  craig@fred.gi.alaska.edu
          Geophysical Institute  |  fncah@alaska.bitnet
 University of Alaska Fairbanks  |  "Its all FANTASY...until its HISTORY"
ObDis: My employer fully sanctions & endorses what I say (with $$$)...NOT!

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 May 1992 19:00:38 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: 1's vs. 0's in broadcast address


When I first noticed that Sunos defaulted to all 0's, I thought that they
were really behind the times.  Then I got to thinking about it, a little.
If one has a network with some old early BSD hosts that use the 0's default
broadcast address and those hosts can't be changed to use the all 1's address,
then a default of all 0's will automatically work with those older systems.
A mixture of the two types of hosts on a network is a good invitation for
an ARP or broadcast storm.

Martin McCormick WB5AGZ   Stillwater, OK
O.S.U. Computer Center Data Communications Group

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 May 1992 19:01:23 GMT
From:      danglert@source.asset.com (Terry Dangler)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   TCP/IP Wrapper

Hi folks,
Is anyone running TCP/IP wrapper on rs/6000 with aix 3.1.7 ?
any problems?
thanks
terry dangler


-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 May 1992 19:33:23 GMT
From:      mike@gordian.com (Michael A. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with printer connected to a terminal server

In article <139@ptt-iat>, jakob@ptt-iat (Jakob Schripsema) writes:
> 
> When I try to use a printer connected to a terminal server from a Unix box
> I run into a problem I don't understand. Basically I write a program that
> connect to the appropriate port of the terminal server, sends the data and
> disconnects:
> 	....
> 	connect(..)
> 	send_data(..)
> 	close(..)
> 	....
> For low speed printers I lose the last part of the data. Inserting a sleep
> (e.g. sleep(30)) BEFORE the close cures the problem. I've seen this problem
> with a UB ASM100 terminal server (Unix box is a Unisys U6000/55 SVR3) and
> a Spider Systems terminal server (Unix box is a Unisys U6000/65 SVR4). It
> seems as if the terminal server discards it's internal buffers after the data
> has been transmitted and the connection is closed.
> Has anyone else seen this problem and maybe knows a better solution ??
> Inserting a sleep requires tuning, because the delay depends on the printer
> speed.

  There are two possibilities:

  1) The terminal server itself is accepting the data (ie the host sends 
     the data and server acks it). You can prove/disprove this relatively
     easy with a network analyzer. If this is the case, your servers'
     implementation is defective and you should complain to your vendor.
  2) The Unix implemenation of close() does not map directly to the
     TCP concept of FIN. When a user calls close, pending data to the
     server is only kept around for a limited amount of time. If the
     consuming TCP is slow (as in the case of a slow printer) the host
     TCP may timeout and ditch the rest of the data waiting to go out
     to the printer. There is a hack in most socket based TCP's which addresses
     (although not deterministically) this problem. You can set the socket
     option O_LINGER to be a greater value like 30 seconds. This has the
     benifit that it will only linger around till the FIN's are exchanged
     or the timeout happens. One other possible solution is to use 
     shutdown(2) tell the host TCP you want to shut the connection down
     (ie send FIN when there is no more data to be sent). You can probably
     test for the server shutting down its side of the connection by doing
     a read(2) on the socket which should give an EIO or ENXIO or EOF (it 
     really depends on how its implemented on your host, I'm not sure) when
     the server sends its FIN.

Number 2 is more than likely your problem. We have in fact seen this problem
when doing the exact same application with a terminal server. Give either 
of these things a try, and your problem should to away.
-- 

		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      14 May 92 20:23:05 GMT
From:      mgic@mixcom.mixcom.com (mgic)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Wanted: X.25 gateway vendors



I have looked in every applicable publication available in
my organization and I cannot find ads for X.25 gateway products. 
(I have received email from 1 vendor.)

What publications do they advertise in?
Has there been a review somewhere of products?
Vendors, talk to me! Thank you.

Dean Roth
Mortgage Guaranty Insurance Corp. (MGIC)
(414) 347-4805

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      14 May 92 20:30:40 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with printer connected to a terminal server


In article <139@ptt-iat>, jakob@ptt-iat (Jakob Schripsema) writes:
|>When I try to use a printer connected to a terminal server from a Unix box
|>I run into a problem I don't understand. Basically I write a program that
|>connect to the appropriate port of the terminal server, sends the data and
|>disconnects:
|>	....
|>	connect(..)
|>	send_data(..)
|>	close(..)
|>	....
|>For low speed printers I lose the last part of the data. Inserting a sleep
|>(e.g. sleep(30)) BEFORE the close cures the problem. I've seen this problem
|>with a UB ASM100 terminal server (Unix box is a Unisys U6000/55 SVR3) and
|>a Spider Systems terminal server (Unix box is a Unisys U6000/65 SVR4). It
|>seems as if the terminal server discards it's internal buffers after the data
|>has been transmitted and the connection is closed.
|>Has anyone else seen this problem and maybe knows a better solution ??
|>Inserting a sleep requires tuning, because the delay depends on the printer
|>speed.

This is a problem common to a number of terminal servers. Another approach
is to append a large number of ASCII NUL characters to the data, which
flushes the data out of the server before the server sees the FIN.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 May 1992 22:14:21 GMT
From:      fillmore@emr1.emr.ca (Bob Fillmore 992-2832)
To:        comp.protocols.tcp-ip
Subject:   Practicality of using ICMP redirects

We have a problem with a shortage of IP addresses that we want to solve
by configuring several subnets of our class B IP network on one Ethernet
backbone.  We would like to do this by configuring the extra subnets
as secondary addresses on a Cisco router interface attached to the backbone,
and turning on ICMP redirects in the router.

This all sounds fine in theory, but I would like to know how many TCP/IP
implementations recognize the ICMP redirect messages.  Is anyone else
out there doing this on their network?

Thanks for any information.

-- 
Bob Fillmore, Central Computing & Communications   email: fillmore@emr.ca
  Information Management Branch,                   BIX:   bfillmore      
  Energy, Mines, & Resources Canada                Voice: (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4  FAX:   (613) 996-2953    

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 08:54:32 GMT
From:      basien@pemcom.pem-stuttgart.de (Tillmann A. Basien)
To:        comp.protocols.tcp-ip
Subject:   IP-Adresse from /dev/ttyp??

Hy netlanders,
	I want to write an application, which always knows terminal
	who is using it.
	With serial lines there is no problem, because the configuration
	does not change.
		/dev/tty1a connected to terminal 1
		/dev/tty2a connected to terminal 2
	But if I use the application on the net, my devices are
	/dev/ttyp??.
	So I can not say which terminal is using the application.
	The application has to select different printers on PC. The PC are
	on the net with TCP/IP and a terminal emulation.

	My question: Is there any solution to get the IP-Adress of the PC
	true a special function call? For example with ioctl() or similar
	in the network-library.

	Thanks for any comment

	Tillmann



-- 
Dipl.-Ing. Tillmann A. Basien           PEM Programmentwicklungsgesellschaft
Management & Development Department                   fuer Microcomputer mbH
Vaihinger Str.49, PostBox 810165
FRG 7000 Stuttgart 80             voice: +49-711-713045  fax: +49-711-713047

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      15 May 1992 09:50:24 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Practicality of using ICMP redirects

In article <1992May14.221421.3442@emr1.emr.ca> fillmore@emr1.emr.ca (Bob Fillmore 992-2832) writes:
>We have a problem with a shortage of IP addresses that we want to solve
>by configuring several subnets of our class B IP network on one Ethernet
>backbone.  We would like to do this by configuring the extra subnets
>as secondary addresses on a Cisco router interface attached to the backbone,
>and turning on ICMP redirects in the router.
>
>This all sounds fine in theory, but I would like to know how many TCP/IP
>implementations recognize the ICMP redirect messages.  Is anyone else
>out there doing this on their network?

All IP implementations are required to recognize ICMP redirects, and I
believe that most do.

However, I don't think redirects will do what you want, if you're expecting
them to allow hosts to communicate directly when they are on different
logical subnets but the same physical network.  Redirects are only sent
when a router receives a packet for which there's a better router on the
same subnet.  The redirect sends the IP address of the better router, not
the MAC address of the destination.  IP provides no way for host on
different logical subnets to communicate without going through a router.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 13:10:45 GMT
From:      hofer+@rchland.ibm.com (Kent Hofer)
To:        comp.protocols.tcp-ip
Subject:   SO_SNDTIMEO and SO_RCVTIMEO

Hello.
The subject questions are SO_SNDTIMEO and SO_RCVTIMEO. Could someone
please enlighten me on why these socket options were defined and never
implemented?  What was the original intent of the options?  Why were
they not implemented?

1) Were they intended to provide an API interface to say "I only want to
wait so long for my input or output operation to complete?

 or

2) Were they intended to provide an API interface to set some TCP
protocol timers, and if so, which ones?

These unimplemented options always intrigue me - if anyone would care to
offer history on other unimplemented stuff relating to sockets, I'd be
glad to get it.

Thanks!

Kent Hofer
hofer@rchland.ibm.com

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 13:11:22 GMT
From:      sat@tridom.uucp (Stephen Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: Practicality of using ICMP redirects

In article <1992May14.221421.3442@emr1.emr.ca>, fillmore@emr1.emr.ca (Bob Fillmore 992-2832) writes:
|> We have a problem with a shortage of IP addresses that we want to solve
|> by configuring several subnets of our class B IP network on one Ethernet
|> backbone.  We would like to do this by configuring the extra subnets
|> as secondary addresses on a Cisco router interface attached to the backbone,
|> and turning on ICMP redirects in the router.
|> 
|> This all sounds fine in theory, but I would like to know how many TCP/IP
|> implementations recognize the ICMP redirect messages.  Is anyone else
|> out there doing this on their network?

I don't know how cisco routers deal with this problem specifically, but most
routers would _NOT_ send redirects in the situation you describe. What
"gateway" would the router direct the sender to use? Since there isn't
another gateway involved, the only address that the router could put
in the redirect is the ultimate destination.

Even if you did find a router that would create such a redirect, it 
wouldn't help the host who receives it. That host still wouldn't know
how to reach that destination directly. (Otherwise the host would never
have sent it to the router in the first place.)

There may be a clever way out of the problem, but at first glance it looks
like you have only two choices:

    1)  Only use hosts that understand multiple subnets on the same
        cable and configure them appropriately. (I didn't mean to imply
        that all choices were practical ;) )

    2)  Resign yourself to the fact that all traffic that "crosses"
        subnets is going to have to go through a router.

Stephen Thomas

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 14:07:55 GMT
From:      glen@Cayman.COM (Glen B. Glater)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.mac.comm
Subject:   Re: Berkeley LPD to Appletalk Postscript print servers?

In article <660@pacvax.UUCP> pgk@pacersoft.com (Paul Kamp) writes:

  >In article <447@jumbo.Apple.COM>, dwb@austin.apple.com (David W. Berry) writes:
  >> 
  >> >  Does anyone know if any software for the Macintosh exists that can 
 receive
  >> >  LPD requests from a UNIX host (via MacTCP) and re-spool them using 
 appletalk
  >> >  protocols to a postscript printer that is localtalk or ethertalk 
  >> attached?
  >> 
  >> Any macintosh running any A/UX >= 2.0 can also do this.
  >> 
  >Pacer's PacerPrint software provides support for Unix users to send their
  >print requests throught the Unix spooler to printers out on the AppleTalk.
  >It is implemented using either the Berkeley or Sys V depending on the
  >Unix implementation.  We can access printer on either Localtalk or
  >EtherTalk.
  >
  >I am pretty sure that Helio's EtherShare and IPT's Ushare do this also.
  >
  >Paul Kamp
  >Pacer Software, Inc.
  >pgk@pacersoft.com

Cayman Systems' GatorPrint software also does lpr to PAP translation,
allowing any computer with the LPR command suite to print to AppleTalk 
based printers.

For systems that do not have LPR native (such as System V UNIX), we 
provide a program that provides you with this functionality.
Lprclient.shar can be ftp'd from our server at ftp.cayman.com.

VMS based machines need some sort of TCP/IP stack before they can print
to AppleTalk printers in this manner.  Process Software and TGV both
make TCP/IP software for VMS. 

GatorPrint works with both of those products.

If you have questions, you can send mail to support@cayman.com.

Glen
--

	*************************************************************
	Glen B. Glater				Phone: (617) 494-1999         
	Technical Support Engineer		Fax:   (617) 494-5167         
	Cayman Systems Inc.			Internet: glen@cayman.com     
	26 Landsdowne Street			AppleLink:  CAYMAN.TECH	      
	Cambridge, MA   02139            SneakerNet:  3rd cube on the left    

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 May 1992 14:28:49 GMT
From:      koelman@cuby.stc.nl (Ton Koelman)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   EGP between Cisco and BBN T/20


Hi,

We're trying to setup EGP between a Cisco and a T/20 from BBN.
Hello messages are exchanged but no reachability info is
exchanged. BBN claims that the Cisco should be put in active 
mode but I see no way of configuring that. 

Any solutions anyone? Help appreciated!

Ton K.

--
Ton Koelman   e-mail: koelman@stc.nl  (NeXT Mail Welcome!)
SHAPE Technical Centre, P.O. Box 174, 2501 CD  The Hague
The Netherlands  (voice: 31-70-3142429, fax: 31-70-3142111)

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 15:52:30 GMT
From:      bill@falcon.cs.uofs.edu (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

In article <1992May13.210345.14684@udel.edu>, scoggin@daisy.udel.edu (John K Scoggin) writes:
|> 
|> My advice - take anything you read in these mags with a grain of salt...
|> 

My doctor would never allow me a grain of salt large enough to make 
the information in most trade rags palatable.  It is, of course, 
rather scary to think that a lot of decision makers make decisions 
based on this information.

bill

-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 16:07:46 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

Aren't Mil. Specs. proprietary ;-)?
-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 16:22:48 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Practicality of using ICMP redirects

In article <1992May14.221421.3442@emr1.emr.ca>, fillmore@emr1.emr.ca (Bob Fillmore 992-2832) writes:
|> We have a problem with a shortage of IP addresses that we want to solve
|> by configuring several subnets of our class B IP network on one Ethernet
|> backbone.  We would like to do this by configuring the extra subnets
|> as secondary addresses on a Cisco router interface attached to the backbone,
|> and turning on ICMP redirects in the router.
|> 
|> This all sounds fine in theory, but I would like to know how many TCP/IP
|> implementations recognize the ICMP redirect messages.  Is anyone else
|> out there doing this on their network?
|> 
|> Thanks for any information.
|> 
|> -- 
|> Bob Fillmore, Central Computing & Communications   email: fillmore@emr.ca
|>   Information Management Branch,                   BIX:   bfillmore      
|>   Energy, Mines, & Resources Canada                Voice: (613) 992-2832
|>   588 Booth St., Ottawa, Ontario, Canada  K1A 0E4  FAX:   (613) 996-2953    

This was discussed a while back.  All hosts have to support IP redirects
butttttt, the new destination must be on the same IP network or the
orignating host won't ARP for it.  ICMP Redirects are used by routers
to tell hosts that a better route through a different router exists
for an IP packet that the host sent to the router.  This lets hosts
only worry about their default router instead of getting involved in
routing topology discovery.

What you want to do is different and the hosts won't do it.  The cisco
can however be attached to each subnetwork and route between them.  The
problem with this is that each packet goes through the router and
appears on the Ethernet twice.
-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 May 92 16:37:59 GMT
From:      amanda@visix.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing MacSLIP

dan@gacvx2.gac.edu writes:
> 7.	Announcements of new products or services for use in research or
> instruction, but not advertising of any kind.

This is precisely why I suggested (and maintain) that the appropriate
approach is to place short note here pointing at a source for more
information, rather than posting several screenfuls of marketing-speak.

As it was, it looked a lot like advertising to me.  While there were
probably no ill intentions on Rick's part (he seems like a nice enough
guy), I thought the posting was borderline at best.  Informative, but
still borderline.

However, it's pretty much a moot point.  We've now used up more time,
energy, and bandwidth arguing about it than the article in question took
up.  I have nothing more to say about it.

Amanda Walker						      amanda@visix.com
Visix Software Inc.				    ...!uupsi!visix.com!amanda
-- 
"Mr. Bell, after careful consideration of your invention, while it is a
 very interesting novelty, we have come to the conclusion that it has no
 commerical possibilities."   -- J.P. Morgan, to Alexander Graham Bell

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 19:56:54 GMT
From:      rick@ut-emx.uucp (Rick Watson)
To:        comp.protocols.tcp-ip
Subject:   Re: Announcing MacSLIP

From article <1992May13.154914.26451@news2.cis.umn.edu>, 
alberti@mudhoney.micro.umn.edu (Albatross) writes:

 > In <1992May12.150322.656@visix.com> amanda@visix.com (Amanda Walker) writes:
 > 
 > >danson@lgc.com (Doug Anson) writes:
 > >> Is this really legal on the Internet?
 
 > >It was certainly very bad manners...
 > 
 > You want bad manners?  He contacted us here at the University of Minnesota a
 > month ago and asked for a copy of the source to our public domain Mac SLIP
 > for "his own little project".  Next thing you know he's selling a Mac SLIP
 > product.  VERY bad manners.
 > 
 > --
 > Bob Alberti: Computer & Information Services U of MN | aka: Albatross | Unitar-
 > E-mail     : alberti@boombox.micro.umn.edu           | Metropolis BBS | ian/
 > Disclaimer : My employer does not mean what I say.   | (612) 721-1870 | Univer-
 > Minnesota  : Where butter is a spice.                | BBSing as art. | salist!

This is a TOTAL MISREPRESENTATION of what happened. Here is the
complete unedited original message that I sent to Minnesota:

 > From rick Wed Mar  4 16:07:25 1992
 > To: grg@boombox.micro.umn.edu
 > Subject: Re: MacTCP and serial connections
 > 
 > Hi,
 > 
 > I'm curious about the status of your SLIP LAP.  As you may or may
 > not know, I've got a LAP that is in beta test. 
 > 
 > Do you know how you are going to release your LAP: commerical, shareware,
 > freeware?  
 > 
 > What features do you support: connection script, compressed tcp headers, etc?
 > 
 > --Rick Watson
 > 

and from a subsequent message:

 > My main interest in taking MacSLIP commercial is for the experience so this
 > is not really a problem.  When do you think you will be ready to release?
 > 
 > (from grg)
 > > I can send you our preliminary documentation, or the lap itself if you'd like to
 > > see it.
 > 
 > I would be very interested in taking a look at both.

I never received ANY sources from Minnesota, nor did I ever receive a
complete copy of their software. 

Rick Watson
Hyde Park Software

P.S. I'm sorry my original posting about the availability of MacSLIP 
was thought to be too commercial. I should have been more careful
about striking a balance between advertising and letting people
know that something useful was available.


-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 21:44:58 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP self-loop problem

In article <1992May8.150125.12401@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
>As far as pointing the finger goes, I agree with you that the
>ACK field really should be processed.  In fact, I don't really see
>that there is ever a valid reason for not processing an ACK field
>(as long as one is present).  The apparent logic behind the RFC
>recommendation, is that if the segment is entirely outside the window,
>then it is probably an old duplicate, and should be discarded.

While i agree that this is probabably what authors were thinking, i
think there are two important points to be made.  First, this thought
does not apply to this case.  Although the SYN is old, the ACK is not.
Once the SYN is dropped in accordance to the first paragraph on page
69 ("...only the new parts should be processed"), the resulting packet
is acceptable: length zero, SEG.SEQ == RCV.NXT, hence acceptable by
either the first or the second acceptability test.

Further, though, i think it's now accepted that the author's thoughts
on this point were, in fact, slightly off.  Since ACK information may
be updated in any retransmission, i believe the recommended practice
is to accept the packet's ACK information as long as SND.UNA < SEG.ACK
and IRS <= SEG.SEQ <= RCV.NXT+RCV.WND.  (URG information should be
similarly accepted.)  (Unfortunately, although this seems obvious to
me now and i do remember the protocol gods making some specific
decisions on this point, i've never been able to find reference in any
RFC that backs my position.)
				Yours in total agreement,
						don provan
						donp@novell.com

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 22:51:09 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

>In article <1992May13.210345.14684@udel.edu>, scoggin@daisy.udel.edu (John K Scoggin) writes:
>|> 
>|> My advice - take anything you read in these mags with a grain of salt...
>|> 
>
In article <10709@platypus.uofs.uofs.edu> bill@platypus.uofs.edu writes:

>My doctor would never allow me a grain of salt large enough to make 
>the information in most trade rags palatable.  It is, of course, 
>rather scary to think that a lot of decision makers make decisions 
>based on this information.
>
    
    This (the magazine article's author) guy sounds almost as
    OTL as the IBM marketing genius who came up with their 
    infamous sales slogan...warning customers about the "dangers of
    getting locked into open systems".   


-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 May 92 11:25:32 +0700
From:      kondrat@inpbox.inp.nsk.su (Igor V. Kondratiev)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: LPR & priveleged ports on VAX/VMS

Here included all useful advices concerning the theme of
"Priveleged sockets, TCP, VMS & LPR".

During this talks was found the accurate decision for problem.
Please take into your account this info, if You interested in any TCP
applications portings.

_______________________________________________________________________________

Date: Sun, 10 May 1992 10:22:29 -0500
From: larry hughes <hughes@logos.ucs.indiana.edu>

   I'm attempting to port NCSA's LPR-client from DOS to VAX/VMS.
   So, I didn't found any tools in WIN TCP/IP to create privileged (<1023) socket.
   I suppose because of that lack LPD server on System V (running on AT-386SX)
   refuses to talk with client.

The LPR client needs to bind() to a privileged port (<1023 as you say).
You don't need special tools for this, you just specify an unused port
number in the sockaddr_in structure.  You could start at 1023 and 
keep decrementing until the bind() succeeds, meaning the port is unused.

   Immediately after the call of connect(...), netstat shows the socket state
   FIN_WAIT_2. Server closes connection after the very first command "\2lp\n"
   with a message "Malformed from address".

This is normal; when a connection is closed by the server, it will
stay in FIN_WAIT_2 for a (usually short) period of time, often less
than a minute.  The time period is determined by the round-trip packet
time between the TCP endpoints.

Does this help?

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        || 
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

_______________________________________________________________________________

Date: Sun, 10 May 92 13:17:22 -0400
From: Stephen C. Trier <trier@odin.INS.CWRU.Edu>
Organization: Case Western Reserve University, Cleveland, OH (USA)

Surely you can select a local port number for the connection?  Just write
a for-loop to start at 1023 and work its way down to 512, trying each one
as you go.  If it returns an in-use error, try the next one.

The whole concept of "privileged ports" is a BSD thing.  It has no official
existence, and the protocols have no recognition of it.  On a machine
without the articifical BSD limitation, you can just use those ports freely.
-- 
Stephen Trier        Dumb error message of the month:
CWRU IRIS/INS         "Mar  1 18:07:18 ziggy xntpd[65]: Clock appears to
trier@ins.cwru.edu     be 86398 seconds slow, something may be wrong"

______________________________________________________________________________

Date: Mon, 11 May 92 13:53:44 EDT
From: palter@cs.Buffalo.EDU (Bill Palter)

There are two ways you can get a reserved port on WIN/TCP for VMS.

	1) Call the rresvport (port) routine. The port arg is a pointer 
	   to an integer. On input it contains the highest 
	   number reserved port you want, and on output it contains
	   the number of the port that was allocated. The routine
	   returns a socket (so it should be called instead of socket).

	2) You can issue a BIND call with the port number you want to 
	   use after you create the socket with  SOCKET, and before you
	   connect the socket to the remote side with CONNECT.

Bill Palter
Software Eng.
The Wollongong Group
Palter@twg.com

_______________________________________________________________________________

Date: Tue, 12 May 92 09:30:35 -0500
From: "Larry Hughes" <hughes@logos.ucs.indiana.edu>

This part of the code has me confused:

   if (bind(connection_id, (struct sockaddr_in *)&sa, sizeof sa)<0)
    if (bind(PRINTER_PORT, (struct sockaddr_in *)&sa, sizeof sa)<0)
      {int so;

       for (so=MAX_PRIV_PORT; so>=0; so--)
       if (bind(so, (struct sockaddr_in *)&sa, sizeof sa)<0)
         printf("%d: no\n", so);
       else
         printf("%d: OK\n", so);
      }
     else printf("yes!");

because there are 3 binds taking place.  There really should only be
one, in a loop until it succeeds.  For example:

      int port;

      /* Create the socket */
      if ((connection_id=socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0)
      {
        perror("socket");
        exit(1);
      }
      printf("open socket %d\n", connection_id);

      /* Bind it to a reserved port */
      sa.sin_addr.s_addr = INADDR_ANY;
      sa.sin_family = AF_INET;
      port = MAX_PRIV_PORT;
      errno = 0;
      do 
      {
        sa.sin_port = htons(--port);
        if (bind(connection_id, struct sockaddr_in *)&sa, sizeof(sa)) == 0)
          break;
      } while (port && (errno == EADDRINUSE || errno == EADDRNOTAVAIL));

      if (!port) 
      {
        printf("no privileged ports available\n");
        exit(1);
      }
      else if (errno)
      {
        perror("bind");
        exit(1);
      }

Does this help?  Please let me know...good luck!

 //==================================================================\\
||     Larry J. Hughes, Jr.                 hughes@indiana.edu        ||
||      Indiana University           "The person who knows everything ||
||  University Computing Services           has a lot to learn."      ||
 \\===================================================================//

_______________________________________________________________________________

Be attentive:

The above advice lead to crash the node when executed connect() after bind();
The decision is later;

_______________________________________________________________________________

Date: Tue 12 May 92 14:18:34-EDT
From: Bill Palter <palter@eco.twg.com>
Organization: The Wollongong Group, Inc., East Coast Operations
Address:      2010 Corporate Ridge Drive, Suite 550, McLean, VA 22102
Phone:        703-847-4500 (Voice); 703-847-4520 (Fax)

	What is the valuse of errno after the bind? (do a perror to get 
the text of the error message. Also do you have privs enabled, to bind to a port
less then 1024 you need privs enabled.

bill
_______________________________________________________________________________

Date: Wed, 13 May 92 09:24:57 -0500
From: "Larry Hughes" <hughes@logos.ucs.indiana.edu>


  2: attempt to bind() without special privs causes the execution
     of perror("bind") (see text above)

Yes, in VMS terms, you must have SYSPRV to bind to a port
less than 1024.

  3: attempt to bind() with turned-on privs causes the all-over
     VAX-cluster abortion at the moment of connect().(see text above)

I don't understand what you mean...can you elaborate?

Also, I didn't see the error messages that you refer to
when you said "(see text above)".  What were the bind()
and connect() error messages?

 //==================================================================\\
||     Larry J. Hughes, Jr.                 hughes@indiana.edu        ||
||      Indiana University           "The person who knows everything ||
||  University Computing Services           has a lot to learn."      ||
 \\===================================================================//

_______________________________________________________________________________

Date: Thu 14 May 92 12:47:27-EDT
From: Bill Palter <palter@eco.twg.com>
Organization: The Wollongong Group, Inc., East Coast Operations
Address:      2010 Corporate Ridge Drive, Suite 550, McLean, VA 22102
Phone:        703-847-4500 (Voice); 703-847-4520 (Fax)

	When you call bind the sin structure should be set up as follows

	sa.sin_addr.s_addr = INADDR_ANY;
	sa.sin_port = htons (any_value_under 1024)

	When you call connect it should be set up as

	sa.sin_addr.s_addr = remote address(from gethostbyname or rhost)
	sa.sin_port = htons (515);

	If you pass the same value to connect as you did to bind (with address
set to INADDR_ANY) WIN/TCP 5.1 will crash, this is fixes in 5.2


Bill

_______________________________________________________________________________


That's accurate decision, all errno==0, connections established, no errors.


Igor V.Kondratiev, Software engineer,
CSD of Institute of Nuclear  Physics, Russia.




-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      15 May 92 23:11:29 GMT
From:      scottp@npg-sd.SanDiegoCA.NCR.COM (Scott Platenberg)
To:        comp.protocols.tcp-ip
Subject:   performance


  Sorry about the FAQ, but I am interested in investigating performance
issues and did not save the information posted here the last time the
discussion came up.  Can someone send me a summary of performance issues
that have been discussed here in the recent past and pointers as to 
where to investigate?   I have heard of "fat-pipe extensions" and am
tracking down the relevant RFC's.  I would be interested in smart-card
performance improvements, Van Jacobsen speed-records, etc...  Thanks a ton.
Scott
--
Scott Platenberg                            NCR, NPG-San Diego
scottp@npg-sd.SanDiegoCA.NCR.com   The Networked Computing Resource of AT&T
                                     9900 Old Grove Road, San Diego, CA

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      16 May 1992 00:13:48 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-Adresse from /dev/ttyp??

Time for my standard response:

No, you can't easily get the IP address of the other end of an
rlogin/telnet session.  Performing an ioctl() on the pty won't work,
because the pty isn't directly connected to the network.  The pty is
connected to a server process (usually rlogind or telnetd), and that
process has a connection to the network, and it's doing the forwarding
between the pty and the network connection.  Only the server processes know
which network connections go with which ptys.

What you can do is replace rlogind and/or telnetd with a version that
records the address somewhere.  We have a version of telnetd that looks up
the remote address and port number in a database of terminal locations, and
stores the information in /usr/spool/ttyloc/tty???.  Then, to find your
location you just read the appropriate file.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      16 May 92 01:54:06 GMT
From:      davis@unidata.ucar.edu (Glenn P. Davis)
To:        comp.protocols.tcp-ip
Subject:   Dreaming of IP Multicasting

Greetings.

We are working on a TCP/IP based for distributing meterological data
to sites around the country.  The sites are on different IP networks.
This is would be a good use of IP Multicasting, if or when such becomes
available.

So the question is, can I reasonably expect commonly available systems
to support IP Multicasting? If so, when? (Your best guess will do..)
How about on the routers? NSFnet Backbone?

Reply to me and I'll summarize.

Thanks

Glenn P. Davis
UCAR / Unidata
PO Box 3000                   3300 Mitchell Lane, Suite 170
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 May 1992 11:03:29 GMT
From:      steves@truevision.com (Steve Spicklemire)
To:        comp.protocols.tcp-ip
Subject:   Help with adding class C network

Hi,

	I'm just learning this TCP/IP stuff so if this is a FAQ, just
point me in the direction of the archive that has it! (Is there a place
to look on the net where you can find where to look on the net for 
archived FAQs?) 

	On our campus we have (at this point) a single class C network.
We have Macs, PCs, and a VMS Vax. They are all living on a single logical
ethernet which spans three buildings. (There are several bridges and
repeaters, and two runs of optical fiber that make this possible). At
this point we can all talk to each other. PCs can see Novell servers from
anywhere, Macs can see other Macs and printers, and anybody can ftp or
telnet the Vax from their workstation). We have just installed a
CISCO router to get to internet over a leased line. (I'm posting
this note through a UUCP connection from a kind company that let's 
me use it!) That's all not working quite right yet, but I see no
reason why it shouldn't in our current configuration, and I'm confident
we can get it to work as we are currently set up. 

Our problem is this, we are running out of IP addresses! We need another 
class C address. We're in luck! when we got our official IP address from 
the NIC. we got *two* class C addresses, thinking that would be 'enough' 
for now. They said that getting a class B address would be much harder 
(which I understand! In the *long* run, we might only need 10 class C 
addresses to get an IP address for every man/woman/child on campus, with 
some left over for servers etc.!) My question: What is the 'right' way
to have multiple class C IP networks running in an environment such as
ours? I'm reading in Comer's book 'Internetworking with TCP/IP', that    
what we need is to have a 'gateway' between our various networks
to handle packets that need to cross from one class C to another. (I
suppose we could use the Vax for this, or the RS6000 we're getting this
summer.) But what does this do to the Mac/PC situation. I understand that
telnet and ftp should still work (since the gateway will clearly
route IP!) but what about Novell and EtherTalk packets? Can they get
through an IP gateway? I'm assuming a structure like this:

                        gateway
                      -------------
   -------------------|  RS 6000  |----------------------
   |    |    |    |   -------------     |     |     |   |
  PC   Mac  PC   PC                    PC    Mac   Mac Mac


Where the gateway has *two* ethernet cards, and there are really *two*
ethernets. Is there anyway to have a 'logical' gateway, something like this:

  ---------------------------------------------------------
  |     |     |     |      |  |     |     |     |     |    |
 PC    Mac   PC   Vax     RS6000   Mac   PC    Mac   Mac  Mac 

Where the Macs and PCs on the left belong to one class C and the Macs
and PCs on the right belong to the other? I know this adds traffic 
(but not too much since *most* of our traffic is non/IP and there are
smart bridges between buildings that keep internal traffic within a 
building at the ethernet level). This 'logical' gateway would do the
IP stuff (getting from one class C address to another) but leave the 
ether free to carry any other protocols it likes. Does this have
a prayer of working? If not, is there any way to have a single gateway
route all my protocols? (will it be *so* busy doing that, that it cannot
get any other useful work done?)

thanks for any help/ideas!
(sorry if this is really dumb, gotta start somewhere!)
-steve

-- 
Steve Spicklemire
steves@truevision.com (daily)
Dept. of Mathematics and Physics, Univ of Indianapolis (sometimes)
(317) 788-3313

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      16 May 92 12:02:01 GMT
From:      ngo-cm@cube.harvard.edu (Thomas Ngo)
To:        comp.protocols.tcp-ip
Subject:   Re: Berkeley LPD to Appletalk Postscript print servers?


[Couldn't find original article]
someone>  Does anyone know if any software for the Macintosh exists
someone>  that can receive LPD requests from a UNIX host (via MacTCP)
someone>  and re-spool them using appletalk protocols to a postscript
someone>  printer that is localtalk or ethertalk attached?

You can do this for FREE if you use CAP 6.x (Columbia AppleTalk
Package).  I believe the canonical US site is rutgers.rutgers.edu.

CAP permits a Unix host to transmit and receive Appletalk packets.  We
have been using it for months, with no problems.  We use it to export
Unix volumes as Appleshare volumes, and spool to Appletalk printers,
plus a couple of incidental things.

--Tom

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 May 1992 18:05:02 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with adding class C network

Steve,

You could acheive what you want by making the cisco router you already
have also act as a logical gateway between the two class C networks
that you have on your bridged Ethernet backbone.  (You don't even need
to get a second Ethernet card for the cisco.)

Talk to cisco Technical Support and they will show you how to do it.

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      17 May 1992 11:11:24 -0700
From:      jamin@usc.edu (Sugih Jamin)
To:        comp.protocols.tcp-ip
Subject:   tcplib 0.9.1: A Library of TCP Internetwork Traffic Characteristics

Hello,

There is a new version (0.9.1) of tcplib on jerico.usc.edu 
(128.125.51.6), under ~ftp/pub/jamin/tcplib.

The difference between this version and the previous version is
a bug fix in the conversation arrival time code.

Following is the orginal release note of tcplib.  The papers 
[Caceres91] and [Danzig92] cited in the tech report are also available
for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/traffic. The file
traffic.ps.Z is for [Caceres91] and the files journal.part[1-4].ps.Z 
are for [Danzig92].

=======================================================================
The following technical report and the source library it describes are
available for anonymous ftp from jerico.usc.edu:~ftp/pub/jamin/tcplib.
(Jerico's IP address is 128.125.51.6.) The directory contains the 
following files:

  README
  libtcp_ds31_ultrix41.a.Z
  libtcp_hp90_hpux847.a.Z   /* not supported anymore because we 
                               lost access to our hp machine. */
  libtcp_sun3_sunos411.a.Z
  libtcp_sun4_sunos411.a.Z
  brkdn_dist.h
  tcpapps.h
  tcplib.1
  tcplib.tar.Z
  tcplibtr.ps.Z

All you need to transfer to use the library are: README, brkdn_dist.h, 
tcpapps.h, tcplib.1, and one of libtcp* that matches your setup.  You
need tcplib.tar.Z only if you must generate the library yourself.  
The file tcplibtr.ps.Z is the PostScript version of the tech. report 
which is introduced below:


    tcplib: A Library of TCP Internetwork Traffic Characteristics

                 Peter B. Danzig       Sugih Jamin

                    Computer Science Department, 
                 University of Southern California,
                 Los Angeles, California 90089-0781

                     traffic@excalibur.usc.edu

                            USC-CS-91-495

1. Introduction
  When simulating computer networks, it is necessary to specify the 
traffic between network nodes.  Typically, simulation studies of 
wide-area tcp/ip networks model traffic as a combination of Poisson 
processes and maximal rate streams--corresponding to telnet traffic 
and large file transfers respectively.  Such traffic models are 
justified when the modeler wants to show, for example, that his flow 
control or gateway scheduling algorithm responds well to worst case 
traffic or when essentially nothing is known about the real network
traffic.  However, such models do not reveal how similarly robust 
algorithms respond to the common case load.
  This paper describes tcplib, a library to help generate realistic 
tcp/ip network traffic.  Tcplib is motivated by our observation that 
present-day wide-area tcp/ip traffic cannot be accurately modeled with 
simple analytical expressions, but instead requires a combination of 
detailed knowledge of the end-user applications responsible for the 
traffic and certain measured probability distributions [Caceres91].  
We collected three-day traces of wide-area Internet traffic at UC 
Berkeley, University of Southern California, and Bell Communications 
Research.  Our study identified that out of more than 35 different 
application programs, ftp, smtp, nntp, vmnet, telnet, and rlogin are
responsible for 96% of wide-area tcp/ip bytes.  Two related studies, 
one at University College London and the other at Lawrence Berkeley 
Laboratory, identified a subset of these six applications as 
responsible for most of their wide-area tcp traffic [Crowcroft91] 
[Paxson91]. Tcplib models five of these six applications.  It excluded 
vmnet, an IBM mail exchange application , because it was absent from 
three of the five traces.  Furthermore, since telnet and rlogin have 
essentially the same characteristics, we have included in tcplib only 
routines describing telnetUs.  Additionally, we included characteristics 
of phone conversations based on the study reported in [Brady65] and a 
distribution of conversations composition breakdown derived from several 
stub-network traces.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 May 1992 00:52:48 GMT
From:      wwestlun@ustb.cnde.iastate.edu (Warren Westlund)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Stream help on Unix-PC link

Hello Netlanders,
  I have been working on some C code on a Unix based DEC workstation.  I need to have two-way
communication between the DEC and a Dell PC (IBM clone.)  Anyway, before I attempted the link between
those two, I tried to link up two DEC's with a little two-way stream.  However, I can only seem to hear on
one side, and talk on the other.  Does anyone have any C code software for this that I could look at?  Or
Anything else which may help me.  Please E-Mail responses.
  Many thanks!

-Warren-



-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      17 May 92 07:55:18 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with adding class C network

steves@truevision.com (Steve Spicklemire) writes:

>to handle packets that need to cross from one class C to another. (I
>suppose we could use the Vax for this, or the RS6000 we're getting this
>summer.) But what does this do to the Mac/PC situation. I understand that
>telnet and ftp should still work (since the gateway will clearly
>route IP!) but what about Novell and EtherTalk packets? Can they get
>through an IP gateway? I'm assuming a structure like this:
The VAX or the RS/6000 could not route the Ethertalk and Novell packets,
but why you don't use your Cisco for this purpose? The Cisco should have
more than enough spare power for this, and its capable of routing Novell IPX
and many other protocols, as well as bridging those protocols, which aren't
routable.

>  ---------------------------------------------------------
>  |     |     |     |      |  |     |     |     |     |    |
> PC    Mac   PC   Vax     RS6000   Mac   PC    Mac   Mac  Mac 

This is possible, but ......

>Where the Macs and PCs on the left belong to one class C and the Macs
>and PCs on the right belong to the other? I know this adds traffic 
>(but not too much since *most* of our traffic is non/IP and there are
>smart bridges between buildings that keep internal traffic within a 
>building at the ethernet level). This 'logical' gateway would do the
That's right, but what you always get through is broadcasts, and multicasts.
It's really better to segment the net by routers, as failures like
braodcast or multicast storms are localized. also broadcasts are seen
in the software at every host, so many broadcasts on the net will steal
you processing power.

>IP stuff (getting from one class C address to another) but leave the 
>ether free to carry any other protocols it likes. Does this have
>a prayer of working? If not, is there any way to have a single gateway
>route all my protocols? (will it be *so* busy doing that, that it cannot
Yes, your CISCO box could do that, and it has enough processing power to
do that with many interfaces.

Klaus
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@bl.physik.uni-muenchen.de

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      17 May 92 10:04:10 GMT
From:      alexis@panix.com (Alexis Rosen)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   Looking for info on Xyplex XP-CC8

[Sorry for the scattershot, but comp.dcom.servers isn't quite ready yet...
 Followups to comp.dcom.lans.misc, for lack of a better place.]

I have just been offered a (probably) good deal on a Xyplex XP-CC8. I know
nothing about this unit, and I have a few questions.

1) Rather than irking the whole net, is the maker of this equipment liable to
   be helpful to me, perhaps by sending a new manual? Does anyone have their
   telephone number, so that I can find out myself, or know where I could dig
   it up?

2) The singe _key_ requirement is that I be able to get BOTH modem control and
   hardware handshaking on the ports AT THE SAME TIME. Many cheap terminal
   servers such as the lantronix can't do this. Can the Xyplex?

3) Our needs are pretty simple. We want rlogins and/or telnets to a single
   host. It would be very nice if it supported transparent telnet so that UUCP
   would work. Auto connections would be nice. 38.4kbps would be helpful. Etc.
   Any comments about the reliability of such a unit and its ability to handle
   features such as the ones I mentioned would be appreciated.

Mail would be great, but I read these groups too.

Hm... While I'm at it... Anyone have any used equipment for sale that _does_
meet the requirements listed above?

Thanks,
--
Alexis Rosen   Owner/Sysadmin,
PANIX Public Access Unix & Internet, NYC.
alexis@panix.com
{cmcl2,apple}!panix!alexis

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      17 May 92 14:54:17 GMT
From:      bill@uofs.uofs.edu (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

In article <1992May15.160746.16198@tridom.com>, mwr@tridom.uucp (Mark Reardon) writes:
> Aren't Mil. Specs. proprietary ;-)?
> -- 

No..  Nothing created thru the use of TAX dollars is proprietary.

bill



-- 
     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      17 May 92 19:31:19 GMT
From:      wb8foz@skybridge.SCL.CWRU.Edu (David Lesher)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

# > Aren't Mil. Specs. proprietary ;-)?
# 
# No..  Nothing created thru the use of TAX dollars is proprietary.

Err,
Well, mostly as a result of books written by Phillip Agee (hope that's
spelled correctly) an ex-CIA case officer and the Pentagon Papers;
secrets are!

You sign this non-disclosure agreement with Uncle Sam. Then if you
write an expose, and don't get approval PRIOR to publishing it, Uncle
Sam gets all your royalty $$$. This is a civil procedure designed to
skirt the fact that we don't have an Official Secrets Act as does the
British Empire.

[tcp-ip this is not - followups to a.f.u, please.]
--
A host is a host from coast to coast..wb8foz@skybridge.scl.cwru.edu
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 May 1992 02:34:01 GMT
From:      ccrick@brolga.cc.uq.oz.au (Rick Ernst)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Connectionless Transport Protocol?

Hi Netters,

I am looking for some information regarding the connectionless
transport protocol. I have found some reference to ISO 8473 but
have had no luck in finding a copy on the net. Any information
regarding the protocol or directions on where to find it would
be greatly appreciated. 

If enough interest is shown I will post a summary.

Please reply via e-mail. (ccrick@cc.uq.oz.au)

Thanks in advance,

Rick.

----------------------------------------------------------------
Rick Ernst                    e-mail: ccrick@cc.uq.oz.au
Workstation Support
Prentice Computer Centre
University of Queensland, Australia


--
------------------------------------------------------------
Rick Ernst      	email: ccrick@brolga.cc.uq.oz.au
Prentice Computer Centre
University of Queensland, St Lucia 4072, Austalia

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 May 1992 03:38:01 GMT
From:      shin@wide.ad.jp (Shin YOSHIMURA)
To:        comp.org.acm,comp.org.ieee,comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc,comp.unix.wizards
Subject:   INET '92




                   ADVANCE PROGRAM & REGISTRATION

                              INET '92
                International Networking Conference
                            Kobe, Japan
                          June 15-18, 1992

ORGANIZATION
Conference, Program, and Advisory Committees

        Conference Committee Chair: Hideo Aiso, Japan
        Regional Conference co-chairs
                Richard Mandelbaum, USA
                Frode Greisen, Denmark
                Jun Murai, Japan
                Stefano Trumpy, Italy
        Program Committee Chair: Haruhisa Ishida, Japan
        Program regional co-chairs
                John Demco, Canada
                Dennis Jennings, Ireland
                Hide Tokuda, Japan/USA
                Enzo Puliatti, UNDP/Italy
        Tutorial Committee Chair: Deborah Estrin, USA
        Advisory Committee Chair: David Farber, USA
        Internet Society Liaison: Larry Landweber, USA

COSPONSORS
ACM SIGCOMM     EDUCOM          RARE
CONNET          FARNET          TISN
CNI             IPSJ            WIDE
CREN            IEEE COMP SOC
EARN            JAIN

CORPORATE SUPPORT
Advanced Network & Services, Inc.
Apple Computer
Cisco
Digital Equipment Corporation
International Business Machines
Novell

Ministry of International Trade and Industry of Japan
Minitsry of Posts and Telecommunications of Japan
United Nations Development Program

INVITATION
The second international conference focusing on worldwide issues of
research and academic networking--INET'92--is scheduled for June
15-18, 1992 in Kobe, Japan.  University, industry and government
represntatives from around the world are invited to meet and discuss
important issues related to planning, implementing, managing and
funding national, regional and international networks.

>FROM Hideo Aiso, General Conference Chair
Welcome to Japan.  It is a great honor to host INET'92 in our
country.  Development of the Internet and its related facilities in
Japan started in 1984 and has grown rapidly with the help of many
individuals from the international networking community.  INET is
the successor to the Academic Networking Workshops and carries on
the excellent history of this work.  We are especially pleased that
INET is now also the annual conference of the Internet Society, and
extend a special invitation to all members of this new organization
for international networking.

The Conference Committee, with the special efforts of Professors
Haruhisa Ishida and Jun Murai, and the assistance of distinguished
members from many countries, has prepared an excellent program that
highlights advances in networking research and application which
will contribute to peace and happiness in the world.

A special thanks is due to the many coumpanies in Japan and in other
countries whose financial support makes this conference possible.

I invite all networks everywhere to join us in Kobe in June for
INET'92.

>FROM Vinton G. Cerf, President, Internet Society
Dear INET'92 Participants:
It is a special pleasure to invite you to Kobe for the first INET
Conference sponsored by the Internet Society.  The rapid expansion
of the international networking community provides many
opportunities for personal growth and sharing of experiences.  The
first INET to be held in the Pacific Basin promises to meet the high
standard of previous conferences.  The Program Committee under the
direction of Professor Ishida has prepared an excellent selection of
papers and reports covering a wide range of topics that will be of
interest to networkers from a variety of geographic and proessional
backgrounds.  In addition to the regular conference schedule, the
annual meeting of the Internet Society will take place on Monday,
June 15.  I hope to see you in Kobe.


                          INET'92 PROGRAM

MONDAY, JUNE 15

8:30-17:30
TUTORIALS

The Evolution of the MAN (Metropolitan Area Network)
Nicholas Maxemchuk

Protocols for Distributed Computing Over Gigabit Networks
David Farber and Guru Parulkar

Mobile Communications
Stephen Deering

Entry-level Technologies
Enzo Puliatti and Stefano Trumpy

17:30-18:30  Internet Society Annual
Meeting

TUESDAY, JUNE 16

10:00-11:00  Opening Remarks
Hideo Aiso, Vint Cerf, Larry Landweber and Jun Murai

11:00-12:00  KEYNOTE ADDRESS
Toshitada Doi, Sony Corporation

12:00-13:30  Lunch

Program note:  The conference program is divided into four parallel
tracks:
R       Regional
P       Policy
A       Applications
T       Technology
S       Special Session on Japan

13:30-15:00  PARALLEL SESSIONS
R1  Africa/Middle East
Chair:  Mike Lawrie (ccml@hippo.ru.ac.za)
S1  Japan
Chair:  Jun Murai  (jun@wide.ad.jp)
A1  Libraries in the Global Information Infrastructure
Chair:  Paul Evan Peters (paul@cni.org)
T1  ATM From Desktop to Wide-Area
Chair:  Juha Heinanen (jh@datanet.tele.fi)

15:30-17:00  PARALLEL SESSIONS
R2  Latin America & Caribbean
Chair:  Tadao Takahashi (tadao@ethos1.ansp.br)
P1  Network Connection Policy
Chair:  Steve Goldstein (goldstein@nsf.gov)
A2  Networks & Social Change
Chair: Tomaz Kalin (kalin@ijs.ac.mail.yu)
T2  Mobile Networking
Chair:  Mario Toko (mario@mt.cs.keio.ac.jp)

18:00  Welcome Reception/Cruise

WEDNESDAY, JUNE 17

8:30-10:00  PARALLEL SESSIONS
R3  Asia & Pacific
Chair:  Kilnam Chon (chon@cosmos.kaist.ac.kr)
P2  Privacy
Chair:  Marc Rotenberg (rotenberg@washofc.cpsr.org)
A3  Entry Level/Low-Cost Solutions
Chair:  Randy Bush  (randy@m2xenix.psg.com)
T3  Networks:  The Next Generation
Chair:  Eric Manning (emanning@engr.uvic.ca)

10:30-11:30  KEYNOTE ADDRESS
"Communication and the Recreation of Community:  Challenges for
Global Networking"
Michell Kapor, President, Electronic Frontier Foundation

11:45-13:15  PARALLEL SESSIONS
R4  Eastern Europe
Chair:  Peter Bakonyi  (h25bak@ella.hu)
P3  Appropriate Use:  Hacking & Cracking
Chair:  Steve Hardcastle-Kille (kille@cs.vcl.ac.uk)
A4  Application of Future Technologies
Chair:  Shigeki Gogo (goto@ntt-20.ntt.jp)
T5  Measurement & Management
Chair:  Bernhard Stockman (boss@sunet.se)

13:15-14:45  Lunch

14:45-16:15  PARALLEL SESSIONS
R5  Europe
Chair:  Kees Neggers (neggers@surfnet.nl)
P4  Network Security
Chair:  Stephen Crocker  (crocker@tis.com)
A5  Computer-Supported Collaborative Work
Chair:  Yutaka Matsushita  (on@inst.keio.ac.jp)
T6  Current Technologies
Chair:  Hideo Miyahara (miyhara@ics.osaka-u.ac.jp)

16:45-18:15  PLENARY PANEL
"Future of the Internet"
Chair:  Richard Mandelbaum  (rma@cs.rochester.edu)

19:00  BANQUET

THURSDAY, JUNE 18

8:30-10:00  PARALLEL SESSIONS
R6  North America
Chair:  Laura Breeden  (breeden@farnet.org)
P5  Network Globilization
Chair:  Barry Leiner  (bleiner@ads.com)
A6  Distance Education
Chair:  Rolf Nordhagen (rolf.nordhagen@use.uio.no)
T6  Multi-Media
Chair:  Jon Crowcroft  (j.crowcroft@cs.ucl.ac.uk)

10:30-11:30  KEYNOTE ADDRESS
"Future Directions in Networking"
Colin J. Bell, Managing Director,
International Data Network Services, Cable & wireless PLC

11:30-13:00  PLENARY PANEL
"Worldwide Internet Issues"
Chair:  Bob Kummerfeld  (bob@cs.su.oz.au)

                         CONFERENCE EVENTS

All participants and accompanying persons are invited to attend the
following social programs.  We hope the programs will provide an
opportunity to renew old friendships and to create new ones with
colleagues from all over the world.

WELCOME RECEPTION/CRUISE
"Luminous Kobe" Gourmet Cruise in the Harbor
Date:  June 16 (Tuesday)
Time:  18:00
Itinerary:  Kobe Portopia Hotel Naka- Tottei "Luminous Kobe"
Fee:  Included in the registration fee

BANQUET
Date:  June 17 (Wednesday)
Time:  19:00
Place:  Kobe Portopia Hotel
Fee:  Included in the registration fee

                        HOTEL ACCOMMODATIONS

The following hotels are holding rooms for the Inet conference.
Rooms should be reserved by completing and sending the enclosed
Registration Form, indicating the name of the desired hotel, the
number of rooms needed and the duration of stay. A deposit of JPY
10,000 is required to secure a reservation.  Double rooms (one large
bed) may not be available at all hotels.  Early reservation is
recommended to assure your first choice of accommodation.

Name of Hotel                   Single          Twin/Double
Hotel Okura                     Y18,020         Y27,810
--10 min. wlk from Motomachi Station
Kobe Portopia Hotel             Y15,500         Y27,000
--Next to the Conference Center
Hotel Gaufres Ritz              Y12,000         Y22,000
--Next to the Conference Center
Hotel Monterey Kobe             Y12,360         Y22,660
--5 mim. walk to Sannomiya Station
Sannomiya Terminal Hotel        Y10,094         Y19,982
--In Sannomiya Station
Kobe Tokyu Inn                  Y10,197         Y18,746
--5 min. walk from Sannomiya Station
Green Hill Hotel 2              Y8,858          Y16,686
--15 min. walk from Sannomiya Station
Chisan Hotel                    Y8,400          Y16,000
--3 min. walk from Kosaku Kobe Station
Kobe Sanside Hotel              Y7,200          Y13,200
--5 min. walk from Sannomiya Station
Kobe Toverside Hotel            Y6,489          Y12,978
--15 min. walk from Motomachi Station

Note:  Room charges include breakfast, serivce charge and tax.  (no
refunds will be given for unused breafast meal couponsl.)  Pre/Post
conference accommodation will be arranged on requet. Write to JTB
Kobe Sannomiya Office, Event & Convention Center when applying.
Please refer to page 11.

           CONFERENCE REGISTRATION AND HOTEL RESERVATIONS

Please complete the registration form and send it to
jcom@wide.ad.jp.  PAYMENT MUST BE MADE BY CREDIT CARD IF USING THE
ELECTRONIC REGISTRATION FORM. Information on payment and
cancellation fees follow.

Conference participants who are members of the Internet Society will
receive a special registration rate.  Participatns who are not
members of the Internet Society will recieve, as part of their
registration fee, membership in the Society for the remainder of
calendar year 1992.

The registration form also serves as a reservation for hotel
accommodations.  A deposit of JPY10,000 is required.

Several optional tours have been arranged.  (Descriptions follow)
The registration form contains space for tour selection and payment.
Additional information on tour opportunities may be requested by
checking the proper box on the registratoin form.

In order to obtain the early registration discount, your form and
payment for registration, hotel deposit, and other fees must be
received by the conference service prior to May 1, 1992.

ON SITE REGISTRATION
A Registration and Information desk will be open at the
International Conference Center in Kobe commencing the afternoon of
Sunday, June 14, 1992 and extending through the conference period.
It is recommended that all participants complete registration prior
to May 1 in order to avoid higher fees.

CONFIRMATION OF REGISTRATION
A letter confirming conference registration and hotel accommodation
will be sent to each participant upon receipt of completed
registration form and accompanying payment.  This letter should be
presented at the Registration Desk in the Conference Center upon
arrival.

REGISTRATION FEES COVER
The registration fees cover attendance to all conference sessions,
except the tutorials.  Also included are the Welcome
Reception/Cruise and Banquet, luncheons and coffee breaks,
conference materials including the program with abstracts and other
conference publications.

An accompanying person may attend the Welcome Reception/Cruise and
Banquet. Attendance at the conference sessions is NOT included in
this fee.

PAYMENT OF FEES
All payments must be in Japanese yen. Cash, bank draft, wire
transfer and international credit cards are acceptable.  Personal
checks will not be accepted.

Please select payment method and provide necessary information as
shown on the registration form.

For direct wire transfer, funds should be sent to the following
address:
Account name:  INET'92
Ordinary Account No:  1735535
Bank Name:  The Fuji Bank, Ltd. Kobe
Branch
Address:  1-3-1 Sannomiya-cho, Chu-ku
Kobe 650, JAPAN
Tel:  81-78-331-7921

CANCELLATION AND REFUNDS
In the case of cancellation, written notification should be sent to
the reigstration Office.  Refunds will be made after deducting
expenses and chancellation charges according to the schedule below.
Cancellation requests must be received by the Registration Office on
or before the dates indicated.

Registration Fee                Refund after deduct.
-On or before May 31            JPY5,000(admin)
-From June 1 to June 13         50% of reg fee
-On June 14                     No refund

Hotel Deposit and Tour Fee

Hotel
-On or before May 1             Full Refund
-From May 2 to 9 days
before 1st night of stay        JPY2,000
-From 8 to 2 days before
1st night of stay               JPY4,000
-Within 1 day or no notice      100% of room daily charge

Tours
-On or before May 1             Free
-From May 2 to 21 days
before departure                JPY2,000
-From 20 to 1 day
before departure                50% of fare
-On departure date or
no notice given                 100% of fare

                        GENERAL INFORMATION

OFFICIAL TRAVEL AGENT
JTB (Japan Travel Bureau) has been appointed official travel agent
for the Conference to handle all travel arrangements and hotel
accommodations both to and within Japan.  Confirmation of hotel
accommodation and tour registration will be forwarded to you by JTB.
Any relevant inquiries should be forwarded to you by JTB.  Any
relevant inquiries should be directly addressed to:

JTB Kobe Sannomiya Office
Event & Convention Center
7-7-1, Kumoi-dori, Chuo-ku,
Kobe 651, Japan
Tel:  81-78-231-4422
Fax:  81-78-261-8417

E-MAIL FACILITIES AT INET'92
Terminals configured for Internet access will be available at the
Conference Center.

PASSPORT AND VISA REQUIREMENTS
All foreign visitors entering Japan must possess a valid passport.
Participants requiring visas should apply IMMEDIATELY to Japanese
consular offices or diplomatic missions in their countries in order
to avoid delay in travel to the conference.  Additional information
is available from local travel agents.

CLIMATE AND CLOTHING
The weather in Kobe during the period of the conference is expected
to be mild, with average temperatures of 18C to 22C (64F to 72F).
We recommend bringing light clothing and be prepared for rain.

FOREIGN EXCHANGE AND TRAVELER'S CHECKS
It is recommended that participants purchase travelers' checks in
Japanese yen before leaving their own countries. The Registration
Desk at the Conference Center will accept cash only in Japanese yen.
Foreign currency can be exchanged at most banks, at the New Tokyo
International Airport (Narita), at Osaka International Airport, and
also at major hotels in Kobe.

                ACCESS TO THE CONFERENCE SITE

Kobe is located about 600km west of Tokyo, near Osaka.  It is
recommended that flight arrangements be made directly into Osaka
International Airport.

OSAKA INTERNATIONAL AIRPORT TO KOBE
The Kobe conference center is located approximately one hour from
the Osaka International Airport.  A taxi from the Osaka Airport to 
the Kobe hotels takes approximately one hour and costs JPY 10,000.

A limousine bus (JPY 680, 40 minutes) will take you to the SANNOMIYA
Station in downtown Kobe where you catch the PORTLINER (subway
JPY220, 15 minutes) to the SHIMIN-HIROBA Station (the subway stop
for the Internation Conference Center Kobe).  Taxis can then take
you to your hotel.

NAGOYA INTERNATIONAL AIRPORT TO KOBE
A limousine bus (JPY660, 45 minutes) can take you from the Nagoya
Airport to the Nagoya Station where you can catch the Shinkansen
(Bullet) train to Shin-Kobe Station (JPY7,500, 100 minutes)

TOKYO TO KOBE

BY AIR
A flight from Narita International Airport takes about one hour to
the Osaka International Airport.  Refer to the above section for
transportation from Osaka to Kobe.

SHINKANSEN (BULLET) Train
>From the Narita airport, take either the Japan Railway train
(JPY3,000, 60 minutes) or the limousine bus (JPY2,500, 90 minutes)
to the Tokyo Station where you catch the Shinkansen (Bullet) Train.
(A taxi from Narita Airport to Tokyo Station costs about JPY15,000
and takes 60 to 90 minutes.)

The "Bullet" trains run six to ten trains every hour.  The trip to
the SHIN KOBE Station takes about three to four hours. A reserved
regular seat is JPY14,000.

A taxi from Shin-Kobe Station to the Conference Center is JPY 1,500
and takes about 15 minutes.

For the adventurer, take the subway (JPY160, 5 minutes) to SANNOMIYA
Station (downtown Kobe), then take the Portliner (JPY220, 15
minutes) to SHIMIN-HIROBA Station (International Conference Center
Kobe).


                SECRETARIAT: For General Inquiries

Japan & Pacific Rim
WIDE Project, Inet'92 secretariat
5322 Endo, Fujisawa
Kanagawa 252, Japan
Phone:  81-466-48-9433
Fax:  81-466-49-1101
EMail:  inet92@wide.ad.jp

North America
EDUCOM, Inet'92 secretariat
1112 16th Street, NW
Washington, DC  20036, USA
Phone:  1-202-872-4200
Fax:  1-202-872-4318
EMail:  inet92@educom.edu

Europe
UNI-C, Inet'92 secretariat
DTH, bygning 305
DK-2800 Lyngby, Denmark
Phone:  45-45-93-83-55
Fax:  45-45-93-02-20
EMail:  inet92Wvm.uni-c.dk

For Accommodations and Tours
JTB kobe Sannomiya Office
Event & Convention Center
7-7-1, Kumoi-dori, Chuo-ku,
Kobe 651, Japan
Phone:  81-78-231-4422
Fax:  81-78-261-8417


                     INET '92 REGISTRATION FORM


SEND COMPLETED REGISTRATION FORM BY POSTAL MAIL, FAX OR EMAIL 
Postal Mail:
c/o JTB Communications, Inc.
Kobe F bldg, 8 Floor
1-3-1 Sannomiya-cho, Chuo-ku
Kobe 650, Japan
Fax:  81-78-321-3175
EMail:  jcom@wide.ad.jp
Phone:  81-78-321-3171

1. Participant
   Title:                                       {Prof./Dr./Mr./Ms.}
   Family name:
   First name:
   Middle name:

   Affiliation:
   Internet Society Member #:

   Mailing Address:                             {Home/Office}
   Address line1:
   Address line2:
   Address line3:
   Country:
   Postal Code:
   Telephone:
   Facsimile:
   Telex:

2. Accompanying Person(s) (if any)
                First Name,     Last Name,      Middle Name
   Name1:
   Name2:
   Name3:
   Name4:

3. Hotel Reservations
   Name of Hotel 1st choice:
   Name of Hotel 2nd choice:
   Room type:                                   {Single/Twin/Double}
   Room Rate:
   Check in Date:               June
   Check out Date:              June

   I am arranging my own accomodation:          {yes/no}
   My conference address will be:

4. Conference and Hotel Fees

                        ITEM                                    Fees (JPY)

-----------------------------------------------------------------------
Registration Fee Internet Society Member before May 1, 1992     60000
                                         after May 1, 1992      65000
                 ------------------------------------------------------
                 Non-member              before May 1, 1992     65000
                                         after May 1, 1992      70000
                 ------------------------------------------------------
                 Accompanying Person     before May 1, 1992     10000
                                         after May 1, 1992      15000
-----------------------------------------------------------------------
Tutorials        The Evolution of the MAN                       50000
                 ------------------------------------------------------
                 Distributed Computing/Gigabit Networks         50000
                 ------------------------------------------------------
                 Mobile Communications                          50000
                 ------------------------------------------------------
                 Entry-Level Technologies                       50000
-----------------------------------------------------------------------
Technical Visit  Transportation Fee & Lunch for ATR              9000
-----------------------------------------------------------------------
Accomp.          Kobe Afternoon Tour                             8300
Persons          ------------------------------------------------------
Program          Himeji Castle and Kikkoman Takasago Plant      12900
                 ------------------------------------------------------
                 Japanese Tea Ceremony                           7300
-----------------------------------------------------------------------
Post Conf.       Tour   Kyoto One Day                           18900
                 Optional Stay           Single Room            14000
                                         Twin Room              27000
-----------------------------------------------------------------------
Hotel Deposit                                                   10000
-----------------------------------------------------------------------

5. Fee Calculation

   Registration
        No. of Persons
                Internet Society Member:
                Non-member:
                Accompanying Person:

        Amount (registration):

   Tutorials
        No. of Persons
                The Evolution of MAN:
                Distributed Computing/Gigabit Networks:
                Movile Communications:
                Entry-Level Technologies:

        Amount (tutorial):

   Technical Visit
        No. of Persons:
        Amount (tech. visit):

   Accompanying Persons Pgrogram
        No. of Persons
                Kobe Afternoon Tour:
                Himeji Castel:
                Tea Ceremony:
        Amount (APP):

   Post Conference Tour
        No. of Persons
                Kyoto One Day tour:
        Optional Stay
                Single room:
                Twin room:
        Amount (pct):

   Hotel Deposit
        Amount (deposit):

   Total Amount:


6. Payment
   The method of Payment                {bank draft/bank transfer/credit card}
   Card:                                {VISA/Amex/Master/Diners}
   Card Holder's Name:
   Card No:
   Expiration Date:
--
Shin Yoshimura
The University of Tokyo

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 May 1992 03:42:42 GMT
From:      shin@wide.ad.jp (Shin YOSHIMURA)
To:        comp.org.acm,comp.org.ieee,comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc,comp.unix.wizards
Subject:   INET '92: Tutorials



      INET'92  Tutorials on  Monday, June 15, 9:00 - 5:00

------------------------------------------------------------------
 About the Tutorials     Tutorial Chair: Deborah Estrin (USC, USA)
------------------------------------------------------------------

I. Introduction
                    
We have organized four diverse and stimulating  tutorials. 

     Dr. Nicholas Maxemchuk of AT&T Bell Laboratories will describe standards, 
state of the art, and future trends in Metropolitan Area Network 
technologies. Dr. Maxemchuk is one of the world's foremost experts in many 
aspects of communications, and in particular MANs. He brings a unique and 
powerful blend of theory and practice to his teaching. In addition to his 
extensive list of research publications, he developed the Manhattan Street 
Network, a very innovative and now-widely-studied MAN architecture. 
Attendees will obtain fundamental understanding of the technology 
underlying: (a) the IEEE 802.6 (DQDB) standard, and (b) alternative MAN 
architectures that may be adopted and interconnected in the future. 
            
     Professors Farber and Parulkar, from University of Pennsylvania and 
Washington University respectively,  are primary developers of the shared 
memory approach  to distributed computing.  In this tutorial they integrate 
their expertise in high speed networking and  distributed computing to 
address the design of the higher level systems that will make use of gigabit 
networks. Attendees will learn about  Inter-Processor Communications (IPC), 
network protocols designed to support IPC, and host-network interface 
requirements and architecture. 

     Dr. Stephen Deering of Xerox Palo Alto Research Center is at the center of 
design and testbed activities in mobile communications. Whereas many 
tutorials in this area address only transmission  technologies, Deering will 
share his expertise in the media access control, network, internetwork, and 
routing issues that must be addressed in order to enable mobility. He will be 
joined by Dr. Fumio Teraoka of SONY-CSL/WIDE, who is an expert on
lower-level, wireless,  transmission techniques.

     In a tutorial designed especially for more recent, and prospective, adopters 
of internet technologies, Enzo Puliatti and Stefano Trumpy will survey entry-
level communicaton technologies.  This tutorial will be ideal for those 
who are proposing or implementing new networks based on entry level technology
and for those who wish to learn the current state-of-the-art of this
technology.

II. Speaker Biographies

[A] Stephen Deering received his B.Sc. (1973) and M.Sc. (1982) from the
University of British Columbia, and his Ph.D. (1991) from Stanford
University.  He has been studying, designing and implementing computer
communication protocols since 1978, including work on X.25 software
for connecting to public networks, on the first implementation of the
X.400 protocol suite for e-mail, and on advanced-functionality transport
protocols for distributed systems.  As part of his doctoral research, he
developed several new routing protocols for efficient and scalable
internetwork multicasting that are now being deployed in the TCP/IP
Internet.
     Dr. Deering is currently a member of the research staff at
the Xerox Palo Alto research Center, where he is conducting research
on protocols to support wireless and mobile computers.  He is an active
member of the Internet End-to-End Protocols Research Group and of the
Internet Engineering Task Force, and is an Observer on the ANSI X3S3.3
and IEEE 802.11 committees.

[B] Dr. David J. Farber is a Professor of Computer and Information Science and
of Electrical Engineering at the University of Pennsylvania where he
is leading research in ultra-high speed networking.
     He was formerly with the University of Delaware, the University of
California in Irvine, Scientific Data Systems, the Rand Corporation,
and Bell Telephone Laboratories. Twenty years ago, he was a founder of
and is a Vice President of Caine, Farber and Gordon, Inc - a leading
supplier of software engineering tools.
     Professor Farber currently serves on the Board of Trustees of the
Electronic Frontier Foundation, on the Computer Science and
Telecommunications Board (CSTB) of the National Research Council,
chairs the NSF/DARPA/CNRI Gigabit Testbed Initiatives Co-ordination
Committee and is an Editor of the Prentice Hall Series in Innovative
Computing.  He is a member of the ACM, Sigma XI and a Senior Member of
the IEEE. 
     Professor Farber's recent research work has concentrated in ultra high speed
networking and the implications of that on processor interconnect,
protocols and software. This has created several joint study
agreements with industrial research laboratories such as Bellcore and
the RBOCS (Project Dawn - with MIT), IBM and Bellcore (Project Aurora
- with MIT), and to becoming one of the principals of the NSF/Darpa
research project in Gigabit Networking and Chairman of the
Coordination Committee.
     Professor Farber is one of the earliest contributors to and an
internationally recognized authority in the field of local computer
networks and distributed computer systems. He was responsible for the
design of the Distributed Computer System (DCS), one of the first
operational distributed systems with one of the first token ring local
networks. He was one of the authors of the SNOBOL programming language
and was responsible for the start of the PL/1 Language effort.  

[C] Dr. Nicholas Maxemchuk received the B.S.E.E. degree from
the City College of New York, and the 
M.S.E.E. and Ph.D. degrees from the
University of Pennsylvania.
     He is currently the Head of the Distributed Systems Research
Department at AT&T Bell Laboratories, where he has been since 1976.
Prior to joining Bell Laboratories he was at the RCA David Sarnoff
Research Center in Princeton, NJ for eight years.
     Dr. Maxemchuk has been on the adjunct faculties
of Columbia University and the University of Pennsylvania.
He has served as the Editor for Data Communications for
the IEEE Transactions on Communications, as a Guest
Editor for the IEEE Journal
on Selected Areas in Communications, and is currently
on JSAC's Editorial Board.  He has been
on the program committee for numerous conferences
and workshops, and was the Program Chairman for 1987
and 1990 workshops on Metropolitan Area Networks.
     He was awarded the RCA Laboratories Outstanding
Achievement Award in 1970, the Bell Laboratories Distinguished
Technical Staff Award in 1984, and the IEEE's 1985 and 1987 Leonard
G. Abraham Prize Paper Award.

[D] Dr. Guru M. Parulkar is an Assistant Professor of Computer Science at
Washington University in St. Louis.  His research emphasis has been on
the design, specification, and implementation of protocols to support
distributed computing applications involving visualization,
multimedia, and collaboration as components on high speed networks.
      Dr. Parulkar holds the Ph.D. in Computer Science from the University
of Delaware (1987), the M.Tech.  in Electrical Engineering from the
Indian Institute of Technology, Bombay (1983), and the B.E.  in
Electronics and Communications from the University of Indore (1981).
He was the recipient of the Frank A. Pehrson Graduate Student
Achievement award in Computer and Information Sciences at the
University of Delaware in 1987.  His Ph.D. thesis, supervised by
Professor David Farber, explored a novel high speed reliable
switch-basd local area network architecture with flooding as a network
access protocol.
     Dr. Parulkar has published his research work in major IEEE and ACM
conferences, participated in a number of panels and workshops on high
speed networking, and participated in the Internet Engineering Task
Force. He has also served on a number of IEEE and ACM conference
program committees, is a guest editor for the IEEE JSAC special issue
on Gigabit Network Protocols and Applications, and is a technical
editor for the IEEE Networks Magazine.

[E] Mr. Vincenzo Puliatti is coordinator of the "Regional Programme for
Communication and Information for Development and Integration"
for Latin America at the United Nations Development Programme.
UNDP the "branch" of the UN which provide technical cooperation
to developing countries.
     Mr. Puliatti is managing developmental projects aimed to the
establishment of data communication networks in developing
countries since 1988. Thanks to these projects a number of
countries in Latin America established national networks
connected internationally with a low cost investment. As a direct
result it was possible the creation of a large base of users in
the short run. Bolivia, Ecuador, Peru and Cuba established such
national networks, while countries like Costa Rica and Brazil
established "sectorial networks" targeted toward specific sectors
of the society such as Non-Governmental Developmental
Organizations. All the project counterparts soon become self
sustained with cost sharing from their own users and  full
Internet international connectivity is soon expected.
     Mr. Puliatti also leaded a project at the United Nations
Development Programme in New York that led to the connection of
the UNDP network with the Internet, becoming UNDP the first
organization of the UN with a full Internet link. Mr. Puliatti is
now actively working for the establishment of Internet
connectivity for most of the UNDP offices in the world. UNDP is
present in 136 countries and territories.

[F] Dr. Fumio Teraoka is interested in network architecture and distributed operating system.
     He received his B.S. and M.S. degrees from Keio University in
1982 and 1984, respectively.
When he was a student of Keio university,
he joined a project called "S&Tnet", a campus network connecting several
VAXes based on 4.1BSD Unix which did not support networking.
He worked in Canon Inc. between 1984 and 1988.
He joined the establishment of Sony Computer Science Laboratory Inc. in 1988.
In Sony CSL, he contributed to the Muse OS, an object-oriented distributed
operating system, on basic design and prototype implementation in 1988
and 1989.
     Currently, he is very interested in rebuilding network architecture
supporting host mobility, continuous media communication, high speed
reliable links, etc.

[G] Mr. Stefano Trumpy earned his  degree  in  mechanical
engineering at University of Pisa in Feb 69. He joined CNUCE
in 1971 where he worked  for several years  in the  domain  of computer
languages  and applications  in  the  field of  engineering.
In 1975 he joined a project involved in the  design and operations of a
software system for the flight control  of  a  geostationary
satellite.
     Since 1983  he  has served as the Director of  the  Institute
CNUCE  of the National Research Council  of Italy and is  active in
the  field  of computing  and networking.  He is   the  EARN
DIrector of  Italy and national member to the COSINE  policy
Group involved in the realization of a common infrastructure
in Europe based on ISO-OSI.  He is also the Technical  Coordinator  of  the
UNESCO  RINAF  (Regional  Informatics  Network  for  Africa) project.

========================================================================
     Tutorial Abstracts
========================================================================

The Evolution of MAN
	   N. F. Maxemchuk (ATT, USA)
--------------------------------------------------------------------------
     We will discuss why changes in the communications environment is
causing	LAN's (Local Area Networks) to evolve into MAN's (Metropolitan
Area Networks).	 We will also discuss the possible extinction of one
or both	of these species by higher speed WAN's (Wide Area Networks).
The body of the	tutorial will be divided into three epochs, the	past,
the present, and the future.
     A short time will be spent examining the past. The most popular of
the bus	and ring LAN's will be described, including Ethernet and the
slotted	and token-passing loops.  It is	assumed	that most attendees
are familiar with this class of	network.  The objective	is to explain
why the	access protocols that thrived in this environment are unable
to adjust to the longer	distances spanned by a MAN, and	why the	basic
topologies are unable to cope with the changes in user requirements.
     A longer time will be spent describing the current generation of
networks.  FDDI	will be	described, but most of the discussion will be
directed toward	the IEEE 802.6 MAN standard, DQDB.  The	objective is
to show	how the	new generation of networks has improved	upon the past,
and how	they plan on coexisting	with the evolving high speed WAN's.
There will also	be a discussion	of some	of the problems	encountered in
the DQDB protocol, and the solutions to	these problems.
     For the future, the current generation of networks will not meet the
throughput and reliability requirements	that are evolving, and
therefore, must	continue to change.  It	will be	shown that alternative
topologies and protocols can meet the changing requirements.  A	case
study will be presented	comparing a specific grid topology, the	MAN-
hattan Street Network (MSN), and DQDB.
     MAN will continue to exist as a distinct entity. The scientific
reason is the finite speed of light.  Higher transmission rates	reduce
the delivery time of finite size messages by a greater amount over a
smaller	distance.  As a	result,	higher speeds can be used in a LAN
than in	a MAN, and higher speeds can be	used in	a MAN than in WAN.
The economic reason is that a buck can be made.	 There are more	types
of networks in place in	a metropolitan area than in wider areas.  In
addition to the	telephone network, most	areas have CATV	networks.  The
application of alternate technologies to MAN's will be discussed.
-------------------------------------------------------------------------

Protocols for Distributed Computing Over Gigabit Networks
     David J. Farber (University of Pennsylvania, USA) &
     Guru M. Parulkar (Washington University in St. Louis, USA)
--------------------------------------------------------------------------
     The tutorial will present results of recent research on innovative
communication paradigms and their impact on underlying protocols to
support demanding distributed computing over emerging Gigabit
networks. The tutorial presumes the following:

* Gigabit networks are viable and will constitute an important
  infrastructure for research and development in various disciplines
  of science, engineering, business, and liberal arts. 

* A typical distributed computing application in the future will
  involve multiple supercomputers, special purpose compute engines,
  and powerful graphics workstation. Such applications may also
  involve multimedia, real-time visualization, and computer supported
  collaboration.   

     These trends have forced researchers to reconsider distributed
computing paradigms, workstation architectures, protocol designs and
their implementations, and other building blocks of computing and
networking.  A number of research groups have been actively working on
these and other related topics with promising results.  The purpose of
this tutorial is to review research in these areas and help understand
implications of early results on future of distributed computing and
networking.  The emphasis of the tutorial will be on distributed
shared memory model, protocols that go between the application and
(inter)network layer, and host-network interface design and
implementation.  High speed switching or networking technologies
will not be the main subject of this tutorial. The tutorial consists
of three main parts as summarized in the following paragraphs. 

   Introduction and Interprocess Communication Models

     This part will include characterization of emerging gigabit networks
and distributed computing applications, traditional interprocess
communication (IPC) paradigm based on message passing and I/O model,
network as memory paradigm and distributed virtual memory model.
A few recently proposed example distributed memory systems will be
also presented. 

   Protocol Engineering and Example Protocols

     The protocol engineering will address the issues of functionality and
basic interface, control mechanisms, and implementation options of
communication protocols aimed at supporting IPC over high speed
networks. A number of proposed and existing protocols will be
considered in this context.  

   Multimedia Workstation Architecture and  Host-network Interfacing

     We will present design and implementation of host-network
interfacing. A number of prototype interfaces will also be considered,
especially existing implementations will be contrasted with proposed
ATM interfaces and hardware based protocol engines.
--------------------------------------------------------------------------

Mobile Data Communications
     Stephen Deering (Xerox Palo Alto Research Center, USA)
--------------------------------------------------------------------
     The proliferation of mobile computers has created a demand for data
communication services that no longer bind a computer to a single
network connection point, or to any (wired) connection point at all.
In this tutorial, we examine the problems that mobility presents
for data networks and protocols, and we describe current and potential
future solutions from the commercial, academic, and standards worlds.
     The emphasis of the tutorial is on protocols and services above the
physical layer, although we survey the various physical technologies
that can be used to support mobile computing, such as conventional and
cellular modems, portable LAN adapters, infra-red and radio LANs
available commercially and currently being specified by IEEE, ETSI, and
other standards bodies, and future wireless telecommunications services
such as PCS, DECT, and Iridium.  We do not, however, delve into the
analog details of wireless technologies, such as modulation schemes,
frequency allocation, or antenna design.
     We examine the media-access (MAC) protocols being used or proposed for
wireless LANs and MANs, and we look at some special features often
requested of data links intended for mobile computers, including
header and data compression, battery-efficient protocols, and support
for real-time (e.g., voice) traffic along with traditional data traffic.
     Mobility across multiple data links, whether wired or wireless, raises
issues of addressing (including both address portability and dynamic
address acquisition), authentication, auto-configuration,
mobility-sensitive routing or bridging, seamless link-to-link (or
cell-to-cell) "hand-off", and establishment of communication with and
without a wired infrastructure.  We review a number of proposals for
dealing with those issues, in the context of popular protocol suites,
such as TCP/IP, IPX, AppleTalk, and OSI/GOSIP.
     We also look at proposed methods for enabling a mobile computer to
locate and negotiate access to nearby network resources when operating
away from "home", for enabling concurrent access to both nearby and home
resources, and for ensuring privacy of communication with home.  Finally,
we examine ways in which network applications and protocols can be
designed to cope with extended periods of no network access at all.
--
Shin Yoshimura
The University of Tokyo

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 May 1992 04:18:24 GMT
From:      shige@wide.AD.JP (Shigeki Yoshida)
To:        comp.org.acm,comp.org.ieee,comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc,comp.unix.wizards
Subject:   Program for INET'92



                     Program for INET'92

Monday, June 15

   9:00-14:00  Internet Society Board of Trustees Meeting
  14:00-17:00  Internet Society Advisory Council meeting (with Trustees) 
  17:00-18:00  Open membership meeting (with Council & Trustees)

Tuesday, June 16

 Opening Session                                                Main Hall
  10:00-10:30  Opening remarks (H. Aiso, Keio Univ., Japan ;
                     L. Landweber, Univ. of Wisconsin, USA)
  10:30-10:45  About the Internet Society (Vint Cerf, CNRI, USA)
  10:45-11.00  About the Conference (H.Ishida, Univ. of Tokyo, Japan;
                                     Jun Murai, Keio Univ., Japan)
  11:00-12:00  Keynote address: Toward Multimedia Networking
                     by Toshitada Doi (Sony, Japan)
  
  12:00- 1:30  Lunch
  
 Parallel Sessions 
   1:30- 3:00  Sessions R1, P1, A1, T1 in 4 parallel tracks
   3:00- 3:30  Coffee Break(1)
   3:30- 5:00  Sessions R2, P2, A2, T2 in 4 parallel tracks
  
   6:00- 8:00  Reception --- "Luminous Kobe" Gourment Cruise in the Harbor

Wednesday, June 17 

   8:30-10:00  Sessions R3, P3, A3, T3 in 4 parallel tracks
  10:00-10:30  Coffee Break(2)
  10:30-11:30  Keynote Address: Communication and the Re-creation of
                Community: Challenges for Global Networking
                  by Mitchell D. Kapor
                     (Electronic Frontier Foundation, USA)       Main Hall
  11:45- 1:15  Sessions R4, P4, A4, T4 in 4 parallel tracks
   1:15- 2:45  Lunch
   2:45- 4:15  Session R5, P5, A5, T5 in 4 parallel tracks
   4:15- 4:45  Coffee Break(3)
   4:45- 6:15  Panel Discussion W1 [Chair: Richard Mandelbaum]
                 Future of the Internet                          Main Hall
   7:00- 9:00  Banquet at the Kobe Portpia Hotel (Everybody is invited)

Thursday, June 18 

   8:30-10:00  Sessions R6, P6, A6, T6 in 4 parallel tracks
  10:00-10:30  Coffee Break(4)
  10:30-11:30  Keynote Address: Data Highways: A driver's view
                 (Dennis Tsichritzis, GMD, Germany)              Main Hall
  11:30- 1:00  Closing Panel discussion W2 [Chair: Bob Kummerfeld]
                 World-wide Internet issues                      Main Hall
------------------------------------------------------
   1:00-8:00  Technical Visit to ATR Laboratories(Lunch included)
   2:00-5:00  Promotion of Network Connectivity in the Asia/Pacific Region
                 (to be organized by APCCIRN)
   2:00-5:00  BOF meetings
               
===========Sessions and Topics =====================================

Regional Sessions (R1-R6)                                          

  R1: Africa/Middle East (Chair: Mike A. Lawrie)                     Room 501
                                                  Tuesday, June 16, 1.30-3.00
    RINAF: A Network Interconnection Project of Academic and Research
           Institutions in Africa
           (L.Abba, S.Giordano & Stefano Trumpy, CNUCE, Italy)
    Academic and Research Networking in Southern Africa--The UNINET-ZA
           Experience (V.A.Shaw, UNINET-ZA, South Africa)
    RIO: An Operational Network in 6 Sub-Saharian Countries of Africa and
           Three South Pacific Islands
           (Pascal Renaud and Monique Michaux, ORSTOM, France)
    Research Networks in Egypt and Cooperation with Arab States
           (Ahmad Bassit, ENSTINET, Egypt)

  R2: Latin America and Carribbean (Chair: Tadao Takahashi)           Room 501
                                                   Tuesday, June 16, 3.30-5.00
    Developing Methodologies for Assuring the Primacy of User Concerns in
    Network Planning: A New Study of a Large Population of Scientists in Chile
           (Stephen R. Ruth, George Mason University, USA &
            Florencio Utreras, University of Chile, Chile)
    The Organization of American States Hemishere-wide Networking Initiative
           (Saul Hahn, OAS, USA)
    Information Systems in Latin America 
           (Carlos A. Afonso, IBASE/ALTERNEX, Brazil)     

  R3: Asia & Pacific (Chair: Kilnam Chon)                             Room 501
                                                Wednesday, June 17, 8.30-10.00
    A Review of Educational and Research Networking Activity in Southeast
         Asia and the Pacific 
           (John Hine, Victoria Univ., New Zealand)
    High Speed Networking--- A Korean Approach
           (Yanghee Choi, Seoul National Univ., Korea)
    Academic Networking in China (Hu Daoyuan, Tsinghua Univ., China)

  R4: Eastern Europe (Chair: Peter Bakonyi)                           Room 501
                                                Wednesday, June 17, 11.45-1.15
    Networking in the Baltic Countries : the BALTBONE Project
           (Sergei Rotanov, Latvian Academy of Sciences, Latvia; Ants Work,
            Estonia & Laimutis Telksnys, Lithania)
    Research and Academic Networking in the Czech and Slovak Federal Republic
           (Jan Gruntorad, CTUP, CSFR)
    HUNGARNET: The Hungarian Academic and Research Network
           (Peter Bakoyni & Laszlo Csaba, Hungarian Academy of Sciences,
            Hungary)
    RELCOM Network (Alexei A. Soldatov and V.V. Bardin, KIAE, Russia)
    NASK --- Research and Academic Network in Poland
           (Daniel Jozef Bem, Tech. Univ. of Wroclaw, Poland)           
    Romanian Academic Network:Present Status & Future Developments
           (Paul-Dan Cristea, Gheorghe Pascovici & Nicolae Popovici,
            Polytechnic Institute of Bucharest, Romania) 

  R5: Europe (Chair: Kees Neggers)                                   Room 501
                                                Wednesday, June 17, 2.45-4.15
    Euro-Networking: Technical Overview 
           (Francois Fluckiger, CERN, Switzerland)
    The COSINE Project (Dai R. H. Davies, RARE/CPMU, Netherlands)
    Europe: Organizational Overview
           (Thomas Kalin, RARE, Netherlands)
    EBONE---The European Backbone
           (Bernhard Stockman, SUNET/NORDUnet, Sweden)

  R6: North America (Chair: Laura Breeden)                           Room 501
                                                Thursday, June 18, 8.30-10.00
    Update on Canadian Networks (John Curley, NRC, Canada)
    High Performance Computing and Communications Project
           (Stephen C. Wolff, NSF, USA)
    United States Networking-- A Regional Perspective
           (Glenn Ricart, SURAnet/Uinv. of Maryland, USA)
    MEXnet: the Mexican Initiative (Hugo Garcia, MEXnet A.C., Mexico)
-------------------------------------------------------------------

Special session on Japan [the Host Country] (S1)                     Room 502
                                                  Tuesday, June 16, 1.30-3.00
    Academic Internetworking in Japan (Haruhisa Ishida, Univ. of Tokyo, Japan)
    WIDE Project Overview (Jun Murai, Keio Univ., Japan)
    Newtwork Module Structure for Heterogeneous Datalinks
           (Akira Kato & Kaoru Hieda, Keio Univ., Japan)
    ISDN Internet for FIPTH: Fast IP to The Home---Development of MLP-over-
         ISDN Protocol---(Ken-ichiro Murakami; Toshiharu Sugawara, NTT, Japan)
-------------------------------------------------------------------
       
Policy Sessions (P2-P6)                                             

  P2: Network Connection Policy: Mini-Panel Discussion (Chair: Steve Goldstein)
                                                                    Room 502
                                                 Tuesday, June 16, 3.30-5.00
    Connectivity within the Internet---A Commentary
           (Geoff Huston, AARNET, Australia; Elise Gerich, MNI, USA &
            Bernard Stockman, SUNET/NORDnet, Sweden )
    Coordination Issues in Global Research Networks
           (Peter T. Kirstein, UC London, UK)
    Regulation and Provisioning of International Telecommunications:
           The Framework, Current Developments, and Relationships to Internet
           (Anthony-Michael Rutkowski, Sprint International, USA)

  P3: Privacy (Chair: Marc Rotenberg)                                Room 502
                                               Wednesday, June 17, 8.30-10.00
    Communications Privacy: Implications for Network Design
           (Marc Rotenberg, CPSR, USA)
    The Underpinnings of Privacy Protection 
           (Frank M. Tuerkheimer, Univ. of Wisconsin, USA)
    Privacy Protection and Telecommunication Regulation
           (Tsuyoshi Hiramatsu, Kansei Gakuin Univ., Japan)
    Public Support for Privacy
           (Simon Davies, Privacy International, Australia)
    Communication Privacy Challenges
           (David H. Flaherty, Univ. of Western Ontario, Canada) 

  P4: Appropriate Use --- Changing Perception with Network Growth    
           (Chair: Steve Hardcastle-Kille)                           Room 502
                                               Wednesday, June 17, 11.45-1.15
    Civil Liberties in Cyberspace (Mitchell D. Kapor, EFF, USA)
    Internet Appropriate Use Policies: A Practical Approach
           (Sergio F. Heker, Princeton Univ., USA)
    The CERT/CC Experience: Past, Present and Future
           (Barbara Y. Fraser & Richard D. Pethia, SEI/CMU, USA) 

  P5: Network Security (Chair: Stephen D. Crocker)                   Room 502
                                                Wednesday, June 17, 2.45-4.15
    Overview of Internet Security Developments 
           (Stephen D. Crocker, Trusted Information Systems, USA)
    An Overview of Internet Privacy Enhanced Mail (PEM)
           (Stephen Kent, BBN, USA)
    Cryptographic Support for a Gigabit Network
           (Jonathan Smith, Univ. of Pennsylvania, USA)

  P6: Globalization of Networks (Chair: Barry Leiner)                Room 502
                                                Thursday, June 18, 8.30-10.00
    CCIRN: Evolution and Accomplishments (W.E. Bostwick, CCIRN/FNC, USA)
    Intercontinental Engineering and Planning Group: INET'92 Report
           (Geoff Huston, AARNET, Australia)
    The Relationship of Commercial Networks to Research & Education
           Networks (Allan H. Weis, ANS, USA)
----------------------------------------------------------------------
       
Applications Sessions (A1-A6)                                     
   
  A1: The Role of National Libraries in the Evolving Global Information
      Infrastructure and Environment                                 Room 301
                                                  Tuesday, June 16, 1.30-3.00
           (Paul Evan Peters, Coalition for Networked Information, USA;)
            David Russon, British Library, UK, Pamela Q. J. Andre, National
            Agricultural Library, USA & Eric Wainwright, National Library of
            Australia, Australia)

  A2: Networks and Social Change ( Chair: Tomaz Kalin)               Room 301
                                                  Tuesday, June 16, 3.30-5.00
    Computer-Mediated Communication: A Potential Tool for Organizational
           Change (Sylvia Wilbur, QMW College, UK &
                   Hannes H.Lubich, ETHZ, Switzerland)
    RELCOM, An Appropriate Technology Network 
           (Larry Press, California State Univ., USA)         
    K12 Network: Global Education through Telecommunications
           (Janet Murray, K12net, USA)

  A3: Entry Level / Low-cost Solutions (Chair: Randy Bush)           Room 301
                                               Wednesday, June 17, 8.30-10.00
    FidoNet(tm): Use, Technology and Tools (Randy Bush, PSG, USA)
    UUCP Networking in an Institutional, National and International Context
           (Juan Miguel Stefanich, CNEA, Argentina)
    Low Cost IP Networking (Alan P. Barrett, Univ. of Natal, South Africa)
    From FidoNet to Internet: the Evolution of a National Network
           (F. Jacot Guillarmod, Rhodes Univ., South Africa)     

  A4: Network Management (Chair: Shigeki Goto)                       Room 301
                                               Wednesday, June 17, 11.45-1.15
    Configuration Detection in Computer Networks within an Organization
           (Yuko Murayama, WIDE/Keio Univ., Japan)  
    A Multiagent Diagnostic System for Internetwork Problems
           (Toshiharu Sugawara and Ken-ichiro Murakami, NTT, Japan)
    Intelligent Network Management
           (K. Jayanthi, G. Mansfield, M. Murata, K. Higuchi, AICSL, Japan; 
            B. Chakraborty, Y. Nemoto and S. Noguchi, Tohoku University, Japan)

  A5: Computer Supported Collaborative Works (Chair: Yutaka Matsushita)
                                                                     Room 301
                                                Wednesday, June 17, 2.45-4.15
    Cooperative work using advanced B-ISDN video workstations
           (Tohru Hoshi, Kenjiro Mori, Yasuhiro Takahashi and
            Takeshi Ishizaki, Hitachi, Japan)
    Supporting Encounters and Interactions in a Virtual Environment
           (Norihiko Matsuura, Go Fujino, Ken-ichi Okada and Yutaka Matsushita,
            Keio Univ., Japan)
    Dynamics of Electronic Collaboration 
           (Martyne Hallgren, Cornell Univ., USA)

  A6: Computer-mediated Communication-based Distance Education
           (Chair: Rolf Nordhagen)                                   Room 301
                                                Thursday, June 18, 8.30-10.00
    Third Generation Distance Education 
           (Bengt Olsen, KOMunity Software, Sweden)
    Creating Collaborative Environments in Education and Training---
           waiting for Electropolis (Morten Soeby, Univ. of Oslo, Norway)
    Virtual Classrooms for the 1990's (Andrew Feenberg, SDSU, USA)
------------------------------------------------------------------------

Technology & Services Sessions (T1-T6)                               

  T1: ATM from Desktop to the Wide-Area Network (Chair: Juha Heinanen)
                                                                     Room 401
                                                  Tuesday, June 16, 1.30-3.00
    ATM Technology for Local Area Networks (Robert Hinden, SUN, USA)
    Local ATM Development and Standardization
           (Paul Tsuchiya, Bellcore, USA)  
    ATM Techniques for High Speed Data Communication
           (Ichiro Inoue, Shin-Ichiro Chaki and Naotaka Morita, NTT, Japan)

  T2: Advanced Networking Technology (Chair: Mario Tokoro)           Room 401
                                                  Tuesday, June 16, 3.30-5.00
    TBA (Stephen Deering, Xerox PARC, USA)
    Host Migration in Virtual Internet Protocol
            (Fumio Teraoka, Sony CSL, Japan)
    Report from the Routing and Addressing Group (Phill Gross, IETF/IESG, USA)

  T3: Network Technologies --- the Next Generation (Chair: Eric Manning)
                                                                     Room 401
                                               Wednesday, June 17, 8.30-10.00
    The International Backplane---The Distributed Computer of 2001
            (David Farber, Univ. of Pennsylvania, USA)
    ESnet, the Next Generation (Jim Leighton, ESnet, USA)
    Next Generation Lightwave Transmission Technology-- Towards simple and
         Flexible Networks-- (Hideki Ishio, NTT, Japan)

  T4: Network Operation and Measurement (Chair: Bernhard Stockman)    Room 401
                                                Wednesday, June 17, 11.45-1.15
    An Internet Gateway in a Corporate Environment: Operational Experience
         and Demographics (Howard L. Funk, IBM, USA) 
    Traffic Analysis of Trans-Atlantic Traffic
           (Ian Wakeman, Dave Lewis & Jon Crowcroft, UC London, UK)
    An Analysis of International Academic Research Network Traffic between
         Japan and Other Nations
           (Toshiya Asaba, Recruit, Japan; K. Claffy, Univ. of California, USA,
            Osamu Nakamura, Univ. of Tokyo, Japan & Jun Murai, Keio Univ., 
            Japan) 

  T5: Addressing and Flow Control (Chair: Hideo Miyahara)             Room 401
                                                 Wednesday, June 17, 2.45-4.15
    Efficient and Flexible Hierarchical Address Assignment
           (Paul F. Tsuchiya, Bell Core, USA)
    The CWR Scheme (Ortwin M. Rose, Univ. of Karlsruhe, Germany)
    Flow Control in High-Speed Networks with Long Delays
           (Srinivasan Keshav, AT&T Bell Labs, USA)

  T6: MultiMedia (Chair: Peter Kirstein)                              Room 401
                                                 Thursday, June 18, 8.30-10.00
    QOS Control of Continuous Media Communications
           (Yoshito Tobe, Toshiba, Japan; Stephen T. C. Chou and Hideyuki
            Tokuda, CMU, USA)
    Multimedia Conferencing: from prototype to national pilot 
           (Mark J. Handley & Steve R. Wilbur, UC London, UK)    
    Practical Problems with Implementing Multisite Multimedia Conferencing
         Internationally (Claudio Topolcic, NRI, USA)
    Software Codecs and Works Station Video Conferences 
           (Christian Huitema & Thierry Turletti, INRIA, FRANCE)
------------------------------------------------------------------

Plenary Panel Discussion Sessions                                 Main Hall

  W1: Future of the Internet (Chair: Richard Mandelbaum)
                                                Wednesday, June 17, 4.45-6.15
        Vint Cerf (CNRI, USA), David Farber (Univ. of Pennsylvania, USA),
        Frode Greisen (UNI-C, Denmark), Kees Neggers (SURFNET, Netherlands),
        Jun Murai (Keio Univ., Japan)        
  W2: World-wide Internet Issues (Chair: Bob Kummerfeld)
                                                 Thursday, June 18, 11.30-1.00
        Tadao Takahashi (CNPq, Brazil), Bijan Jain (IIT Delphi, India),
        Enzo Puliatti (UNDP, Italy), Stefano Trumpy (CNUCE, Italy), 
        Carl Malamud (USA)



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

Workshop for Developing Countries

  Sunday, June 14 

      [organized by Enzo Puliatti (UNDP, Italy)
                and Stefano Trumpy (CNUCE, Italy)]

    The objective of  the workshop  is  to provide  participants
    with information and  international  contacts that will help
    to faciliate their activities in such areas as:
    - international connectivity to their country;
    - establishment of national network;
    - improvement of existing networks;
    - identification of new  technologies that could facilitate
      their activities.
 
       9:00   Opening and introduction of the participants
              [Scope of the workshop, connections with the conference
              program, countries and experiences represented]
                (E. Puliatti, UNDP, Italy & S. Trumpy, CNUCE, Italy)

      10:00   Computer communication: history and lessons
              [A history of the technological evolution and a
              critical analysis of the key points relevant for
              developing countries] (Joe Choy, NCAR, USA)

      11:00   Importance of the access to distributed Knowledge in
              technologically emerging countries
              [Impact of the distribution of the information may
              have  in the  society of technologically  emerging
              countries.  What kind  of information is available
              and how you can get it]
                (G.Sadowsky, New York Univ. USA &
                 L.Press, California State Univ., USA)

      12:00   How to build a national network
              [Necessary steps, resources, partners and institutions
              that may help]
                (Mike Lawrie, Rhodes Univ., South Africa)

      13:00   Break

      14:00   International connectivity
              [Possible choices; contact points in different regions]
                (Proposed speaker: Rundy Bush, PSG, USA)

      15:00   National PTTs: partners or contenders?
              [Importance of the PTTs in technologically emerging
              countries, problems and experiences]
                (Proposed speaker: Juna Carlos Torres)

      16:00   Round table discussion
              [Discussion and concluding remarks]
                (Chairing: E. Puliatti, S. Trumpy plus other speakers)

    
================================e===================================== 

  Tutorials (Chair: Deborah Estrin, Univ. of Southern California, USA)
  
    9:00 - 5:00  Monday, June 15

  1. The Evolution of the MAN (Metropolitan Area Network)
       (N.Maxemchuk, AT&T Bell Laboratories, USA)  
  2. Protocols for Distributed Computing Over Gigabit Networks
       (David Farber, Univ. of Pennsylvania & Guru M. Parulkar,
        Washington Univ., USA)
        Introduction and Interprocess Communication Models
        Protocol Engineering and Example Protocols
        Multimedia Workstation Architecture and Host-network Interfacing
  3. Mobile Data Communications (Stephen Deering, Xerox PARC, USA
                             and Fumio Teraoka, Sony CSL, Japan.)
  4. Entry-level Technologies (Chair: Enzo Puliatti and Stefano Trumpy)

    The focus is on robust and  low cost  technologies
    which  may be usefull to realize national networks
    in  technologically  emerging   countries  and  to
    connect them to international ones.
    Demostrations  will  be   organized   during   the
    tutorial.
 
       9:00   Connectivity alternatives at a local, domestic
              and international level [The point will be treated with
              special reference to the situation in developing countries]
                (Ted Hope, Costa-Rica)

      10:00   Internetworking: how to integrate different
              platforms [Best options and evolutionary processes]
                (Daniel Karrenberg, CWI, Netherlands)

      11:00   The last mile problem
              [Packet radio, low cost satellite links, error corrections
              protocols, etc.; demos are planned]
                (Proposed speaker: Charlie Clements)

      13:00   Break

      14:00   A close view to free or low cost communication packages
              and tools [Fidonet, UUCP, PCroute, PC TCP and other TCP/IP
              options]
                (TBA)

      15:00   Global access to library and related resources
              [Information on what it is available, where and how
              the information is accessible; demo are planned
              of catalog access, more intelligent services such us
              WAIS, electronic journals and CWIS]
                (Art St. George, Univ. of New Mexico, USA))

      17:00   A solution to integrate e-mail systems using public packet
              or circuit switched services
              [RFC822 mail is usually transported on top of complex
              stacks, such as TCP/IP, DECNET, etc. that are not economi-
              cally convenient when used over switched facilities. This
              tutorial proposes some solutions for integrating the RFC822
              mail system of a country in the international system in a
              very economical way.]
                (Francesco Gennai)
  

--
Shigeki Yoshida, WIDE Project, JAPAN (shige@wide.ad.jp)

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      18 May 92 08:34:47 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: 1's vs. 0's in broadcast address

In article <1992May14.190038.27629@unx.ucc.okstate.edu> martin@datacomm.ucc.okstate.edu (Martin McCormick) writes:
>
>When I first noticed that Sunos defaulted to all 0's, I thought that they
>were really behind the times.  Then I got to thinking about it, a little.
>If one has a network with some old early BSD hosts that use the 0's default
>broadcast address and those hosts can't be changed to use the all 1's address,
>then a default of all 0's will automatically work with those older systems.
>A mixture of the two types of hosts on a network is a good invitation for
>an ARP or broadcast storm.

I have heard many people speak about broadcast storms. I guess this means
that there are excessive broadcast messages on the net then. My questions:

1.  Can someone give a brief explanation of the mechanism of broadcast
    storms? (please include an example)
2.  How can I detect that there are such storms on my network?
3.  How can I prevent broadcast storms?

Regards,
-Roger

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      18 May 92 13:59:28 GMT
From:      moshek@FibHaifa.com (Moshe Kochinski)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   Debug information using Sun sparc station


Hi netters,

I would like to collect statistics, such as the number of rejected frames,
the number of retransmissions etc, while doing ftp between two Sun sparc
stations.
Thanks in advance for any information,

-- 
Moshe Kochinski
------------------------------------------------------------------
Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL
phones: +972-4-313665/620              Fax: +972-4-550266
e-mail: moshek@FibHaifa.com   or     moshek@fibronics.UUCP
------------------------------------------------------------------

-- 
Moshe Kochinski
------------------------------------------------------------------
Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL
phones: +972-4-313665/620              Fax: +972-4-550266

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 May 1992 15:08:04 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with adding class C network

In article <1992May16.110329.18325@truevision.com> steves@truevision.com (Steve Spicklemire) writes:
|
|But what does this do to the Mac/PC situation. I understand that
|telnet and ftp should still work (since the gateway will clearly
|route IP!) but what about Novell and EtherTalk packets? Can they get
|through an IP gateway? I'm assuming a structure like this:
|
|                        gateway
|                      -------------
|   -------------------|  RS 6000  |----------------------
|   |    |    |    |   -------------     |     |     |   |
|  PC   Mac  PC   PC                    PC    Mac   Mac Mac
|
|
|Where the gateway has *two* ethernet cards, and there are really *two*
|ethernets. Is there anyway to have a 'logical' gateway, something like this:
|
|  ---------------------------------------------------------
|  |     |     |     |      |  |     |     |     |     |    |
| PC    Mac   PC   Vax     RS6000   Mac   PC    Mac   Mac  Mac 
|
|Where the Macs and PCs on the left belong to one class C and the Macs
|and PCs on the right belong to the other?

This is fine - there is no reason that two logical networks (machines with
different class C network number) can't be set up on the same cable.

 I know this adds traffic 
|(but not too much since *most* of our traffic is non/IP and there are
|smart bridges between buildings that keep internal traffic within a 
|building at the ethernet level). This 'logical' gateway would do the
|IP stuff (getting from one class C address to another) but leave the 
|ether free to carry any other protocols it likes. Does this have
|a prayer of working?

It should work fine, provided your physical cabling stays within spec of
a single 'network'. All machines will be able to see each others packets
(within the limitations of your smart bridges), but the IP-number based
machines will ignore packets from machines from different logical
networks, unless they are passed through the router machine.
|
|thanks for any help/ideas!
|(sorry if this is really dumb, gotta start somewhere!)

Not dumb at all. Unlike most newsgroups, these are intended for questions
and answers as well as soap-box oratory by those that want to give
their opinion without being asked for it!

(oops - duck!)

-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 May 1992 19:53:26 GMT
From:      speth@vxdesy
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietory

In article <1992May13.210345.14684@udel.edu>, scoggin@daisy.udel.edu (John K Scoggin) writes:
> In article <705703834snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
 ...
> I believe that you will find this particular individual comments on a wide
> range of subjects, including "Open Systems", PCs, networks, etc.  He is a
> consultant.  I doubt VERY MUCH that he has any real first-hand experience
> in most of the subject areas he comments on.
...

I would like to thank that "particular individual," Russ Nelson, for
developing the packet driver interface which makes possible the internet
connection which I am now using!  

Jan Speth                                                 SPETH@VXDESY.DESY.DE
Deutsches Elektronen Synchrotron, Hamburg 

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      18 May 92 20:08:58 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: 1's vs. 0's in broadcast address

In article <BOB.92May13143756@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
   Solaris 2.0 Beta (Sun's SPARC port of SVR4) still defaults to using
   0s for broadcasts, and I've reported it as a bug.

I spoke too soon, and somewhat inaccurately.  We had Solaris 2.0 Beta
installed on a disk, but it wasn't running at the time I posted this
article - that machine was needed for another project, running SunOS
4.1.1 or 4.1.2.  So I mounted Solaris 2.0 Beta's filesystems on the
machine under 4.1.1, and browsed the manual pages, where I found this
in ifconfig(1m):

     broadcast address
                    (inet only) Specify the  address  to  use  to
                    represent  broadcasts  to  the  network.  The
                    default broadcast address is the address with
                    a  host  part  of  all  0's...

Fortunately (unfortunately?) the software behaves correctly, rather
than as the manual page describes.  As I saw when I had that machine
running Solaris 2.0 Beta again:

# ifconfig -a
lo0: flags=49<UP,LOOPBACK,RUNNING> mtu 8232
        inet 127.0.0.1 netmask ff000000
le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
        inet 137.175.2.6 netmask ffffff00 broadcast 137.175.2.255
        ether 8:0:20:7:73:e4
#

So my diagnosis was in error, because I believed the documentation
rather than checking the actual behavior of the software (a common
enough mistake, but I should know better).  Solaris 2.0 Beta appears
to behave correctly when selecting a default broadcast value, using
all 1s as prescribed in the relevant RFCs.  I have modified my message
to Sun to report a documentation bug, rather than a software bug.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      18 May 92 20:59:10 GMT
From:      rbr@pdx.csd.mot.com (Bob Rose)
To:        comp.protocols.tcp-ip,comp.protocols.pcnet,comp.protocols.ppp,mot.comp.sys.mac,comp.sys.mac.comm
Subject:   SLIP for PC or MAC

Can anyone direct me to a public domain SLIP implementation for a MAC or PC?
What about PPP?  Appreciate your help.

================================================================================
Robert Rose                           Motorola Computer Group
				      Commercial Systems Division
rbr@pdx.cds.mot.com		      12655 S.W. Center Street - Suite 400
Voice: (503) 643-6247 		      Beaverton, Oregon 97005
================================================================================

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      18 May 1992  22:36:06  +0200
From:      Erik Naggum <erik@naggum.no>
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Connectionless Transport Protocol?

This is an FAQ candidate.

ISO standards are not available on the net, because they carry a
copyright notice, and cost real money.  ISO depends on the proceeds from
the sale of standards.  Many would wish them to be freely available, but
those who do usually did not write them or sponsor their development.
ISO's wishes about the distribution of their material must be respected,
even though it would be better (for some values of "better") if they
were available for free.

Maybe someone would like to take up the task of buying standards and
describing them in a way which would not infringe ISO's copyright, and
then distribute these documents freely?

Personally, I would love to see the standards available electronically,
even if that cost money, too, but so far, no such luck.  It may be
because we in the Information Technology corner of ISO are very, very
special: our tools are capable of talking about our standards.

It's particularly ironic in the field of document processing and related
communication (JTC 1/SC 18), where we work on document description
languages and processing and interchange of electronic documents, and we
communicate within the working groups on paper, and the standards are
forever bound to paper.  It's kind of sad right now, but it's not in my
long-term interest to override ISO's copyright.

You can order ISO standards from your national ISO member body, usually
your national standards body, information about which you can get from
ISO, Geneva, Switzerland.  There are numerous companies specializing in
getting you the standards you want: fast, reliably, and very expensively.

Best regards,
</Erik>
--
Erik Naggum       |  +47-295-0313     |  ISO 8879 SGML     |  Memento,
Naggum Software   |   "fuzzface"      |  ISO 10744 HyTime  |  terrigena.
Boks 1570, Vika   | <erik@naggum.no>  |  JTC 1/SC 18/WG 8  |  Memento,
0118 OSLO, NORWAY | <enag@ifi.uio.no> |  SGML UG SIGhyper  |  vita brevis.

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      18 May 1992  23:58:46  +0200
From:      Erik Naggum <erik@naggum.no>
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietory

Jan Speth <speth@vxdesy.WITHOUT.DOMAIN> writes:
|
|   Russell Nelson <nelson@crynwr.com> writes:

You left out an important part of Russ Nelson's article, Jan:

||  Can someone please explain to me why John Gantz believes TCP/IP to
||  be proprietary?  In his current "White Paper to Management" in
||  "Networking Management" 5/92, he continually refers to TCP/IP as
||  proprietary, then he admits that "OSI products aren't ready yet or
||  cost too much".
 
 John K Scoggin <scoggin@daisy.udel.edu> writes:
|   > I believe that you will find this particular individual comments on a wide
|   > range of subjects, including "Open Systems", PCs, networks, etc.  He is a
|   > consultant.  I doubt VERY MUCH that he has any real first-hand experience
|   > in most of the subject areas he comments on.
|   ...

Note that "this particular invididual" refers to John Gantz, which
Russ asks _about_, and John Scoggin answers _about_.

|   I would like to thank that "particular individual," Russ Nelson, for
|   developing the packet driver interface which makes possible the internet
|   connection which I am now using!

Although that's nice, Russ was never "that particular individual".  I
think you should apologize to John Scoggin for insinuating that he
regards Russ that way.

(I'm posting this because I was somewhat perplexed by your comment, and
thought maybe others would be, too.)

Best regards,
</Erik>
--
Erik Naggum       |  +47-295-0313     |  ISO 8879 SGML     |  Memento,
Naggum Software   |   "fuzzface"      |  ISO 10744 HyTime  |  terrigena.
Boks 1570, Vika   | <erik@naggum.no>  |  JTC 1/SC 18/WG 8  |  Memento,
0118 OSLO, NORWAY | <enag@ifi.uio.no> |  SGML UG SIGhyper  |  vita brevis.

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      19 May 92 06:48:37 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-Adresse from /dev/ttyp??

In article <v1k3sINNp4r@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>Time for my standard response:
>
>No, you can't easily get the IP address of the other end of an
>rlogin/telnet session.  Performing an ioctl() on the pty won't work,
>because the pty isn't directly connected to the network.  The pty is
>connected to a server process (usually rlogind or telnetd), and that
>process has a connection to the network, and it's doing the forwarding
>between the pty and the network connection.  Only the server processes know
>which network connections go with which ptys.
>
>What you can do is replace rlogind and/or telnetd with a version that
>records the address somewhere.  We have a version of telnetd that looks up
>the remote address and port number in a database of terminal locations, and
>stores the information in /usr/spool/ttyloc/tty???.  Then, to find your
>location you just read the appropriate file.
>-- 
>Barry Margolin
>System Manager, Thinking Machines Corp.
>
>barmar@think.com          {uunet,harvard}!think!barmar

On SunOS the 'who' command shows the name or address of the host you came
from. Isn't it possible then to use this information? I don't know what
other UNIX flavors offer, so my hack may be Sun specific.

Regards,
-Roger
(I speak for myself)

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      19 May 1992 07:39:39 GMT
From:      smckinty@sunicnc.France.Sun.COM (Steve McKinty - Sun ICNC)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for PC or MAC

In article <1164@mcspdx.pdx.csd.mot.com>, rbr@pdx.csd.mot.com (Bob Rose) writes:
   > Can anyone direct me to a public domain SLIP implementation for a MAC or PC?
   > What about PPP?  Appreciate your help.
   > 
Do you really need PD, or just free? If the latter, try the KA9Q NOS package
for the PC. It was written as software for ham radio use, but works fine as
a general SLIP implementation (and as a TCP/IP over ethernet as well). Its
not PD (copyrighted by KA9Q et al. so you can't sell it) but it should
be freely available by FTP.

Steve

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 May 92 16:29:43 GMT
From:      wayne@ultra.com (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Why are 16-bit length fields SIGNED?

I have noticed that in the BSD header file netinet/ip.h, ip_len is
declared as a signed short.  Likewise, netinet/udp.h has uh_ulen
declared as a signed short.  This is also true in AT&T SVR4.

Can somebody please explain why this isn't a bug?

    Wayne Hathaway               domain: wayne@Ultra.COM
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134           direct: Hey, you!

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 May 1992 18:48:34 GMT
From:      jackb@mdd.comm.mot.com (Jack Brindle)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for PC or MAC

In article <1164@mcspdx.pdx.csd.mot.com> rbr@pdx.csd.mot.com (Bob Rose) writes:
>Can anyone direct me to a public domain SLIP implementation for a MAC or PC?
>What about PPP?  Appreciate your help.
>
>================================================================================
>Robert Rose                           Motorola Computer Group
>				      Commercial Systems Division
>rbr@pdx.cds.mot.com		      12655 S.W. Center Street - Suite 400
>Voice: (503) 643-6247 		      Beaverton, Oregon 97005
>================================================================================

To my knowledge, there are now three implementations of SLIP for the Mac for
use with MacTCP. All three are commercial. They are:
MacSLIP from Trisoft ($49.95) - ph (512) 472-0744
Versaterm's SLIP driver, comes with Versaterm, not available seperately.
Intercon' SLIP driver. Available soon in their "Tools & Toys TCP/IP"
utilities package. $149, they claim availability May or June.

Reviews on both MacSLIP and the Versaterm SLIP are both quite good. I'm 
currently waiting for my Versaterm upgrade. By the way, Versaterm is an
awfully good terminal package, it would be worthwhile to pick it up even
without the SLIP driver. 

Jack Brindle
ham radio: wa4fib
internet: jackb@mdd.comm.mot.com
Motorola's Mobile Data Division


-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 May 1992 18:57:23 GMT
From:      cam@mbunix.mitre.org (McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Overhead for SMTP?

Am looking for information on the overhead required to send mail using SMTP
(including the IP and TCP overhead).  Any ideas on where I can find an
analysis of this, or of the "efficiency" of SMTP vs. X.400, would be
appreciated.

Colleen McLaughlin
C2 Communications
MITRE Corp.


-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 May 1992 20:23:42 GMT
From:      a722756@pan.mc.ti.com (W. D. Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary


In article <1992May15.160746.16198@tridom.com>, mwr@tridom.uucp (Mark Reardon) writes:
|> Aren't Mil. Specs. proprietary ;-)?
|> -- 
|> Mark
|> 
|> ---------------------------------------------------------------------
|> | Mark Reardon           |  AT&T Tridom                             |
|> | mwr@eng.tridom.com     |  840 Franklin Court                      |
|> |                        |  Marietta, GA 30067                      |
|> ---------------------------------------------------------------------
|>  

By definition Mil specs are **not** proprietary.
-- 

Regards.
 
Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 May 92 22:56:21 GMT
From:      peter@frcs.Alt.ZA (Peter Greenwood)
To:        comp.dcom.lans,comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Network diagnostic tool: what to buy?


We're looking for a tool that provides diagnostic capabilities that
will enable us to maintain and troubleshoot our LAN (Ethernet running
IP and IPX, 40 Novell file servers (2.15 & 3.11), 60 UNIX machines,
about 2000 PCs).  Network General's "Sniffer Network Analyser" looks
very promising.

What's your experience?  What else is available that can do as good or
better a job as Sniffer?

Peter Greenwood
 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Peter Greenwood
peter@frcs.alt.za                  ...!uunet!{m2xenix,ddsw1}!frcs!peter

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      19 May 92 23:13:27 GMT
From:      domenikos@delni.enet.dec.com
To:        comp.protocols.tcp-ip
Subject:   SNMP Training Seminars Offered (june)


DTC is offering the following SNMP seminars in June
in Boston:

SNMP Technical Introduction  

 Presents the Simple Network Management Protocol (SNMP) architecture &
framework, model & components, and communication standards used to exchange
information between the network management stations and the agents of the
various network applications. Particularly,important to network consultants, 
network managers and others who have a basic understanding of TCP/IP and
need to understand the SNMP technology
					   Date: June 15-16 1992

Network Management Application Development using SNMP

 Describes how to develop client and agent modules. 
It is a programming course, particularly important to network application 
developers who need to incorporate SNMP support into their applications
	
					   Date: June 17-19 1992
	
For detailed information and
registration please contact DTC at:
Tel: (617) 684-0060
FAX: (617) 684-0072

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      19 May 92 23:34:32 GMT
From:      moliver@pyramid.com (Mike Oliver)
To:        comp.protocols.tcp-ip
Subject:   Re: Why are 16-bit length fields SIGNED?

In article <1992May19.162943.14100@ultra.com> wayne@ultra.com (Wayne Hathaway) writes:
>I have noticed that in the BSD header file netinet/ip.h, ip_len is
>declared as a signed short.  Likewise, netinet/udp.h has uh_ulen
>declared as a signed short.  This is also true in AT&T SVR4.

From the comments in BSD netinet/ip.h, half a dozen lines up from the
definition of ip_len:

	We declare ip_len and ip_off to be short, rather than u_short
	pragmatically since otherwise unsigned comparisons can result
	against negative integers quite easily, and fail in subtle ways.

The comment is there in SVR4 too.  I don't know how far back it goes.

>Can somebody please explain why this isn't a bug?

It's a matter of opinion.  If you want to send a UDP datagram or IP
packet containing more than 32K octets, it might well be (the cause of)
a bug.  The comment suggests (to me at least) that someone couldn't be
bothered to the job properly, or perhaps didn't/couldn't trust their
compiler.

Regards, Mike.

moliver@pyramid.com
{allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 May 1992 00:20:20 GMT
From:      dsbarr@modula.cs.psu.edu (Dave Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

In article <1992May19.162342@pan.mc.ti.com> a722756@pan.mc.ti.com (W. D. Rolph) writes:
>
>In article <1992May15.160746.16198@tridom.com>, mwr@tridom.uucp (Mark Reardon) writes:
>|> Aren't Mil. Specs. proprietary ;-)?
>
>By definition Mil specs are **not** proprietary.

Just out of date.  :-/   Guess who's the biggest purchaser of electron
tubes?

--Dave
-- 
Dave Barr            | -- NewsGrazer, a NeXTstep(tm) news reader, posting --
dsbarr@cs.psu.edu    | NOT!

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 03:34:21 GMT
From:      4carroll_j@spcvxb.spc.edu
To:        comp.protocols.tcp-ip
Subject:   tcp-ip source code




        Hi,
             I  was  wondering  if anyone was aware of  a  public  domain 
        version  of  tcp-ip. This source code needs to be written  for  a 
        multi-tasking,  multi-user  operating system. I am aware  of  and 
        have partially reviewed the NCSA and KQ9 versions, but they  were 
        both written for DOS (single-tasking, single-user).
        
             I am currently in the process of developing a tcp-ip package 
        for the QNX operating system. This is a unix clone that does  not 
        have tcp-ip (if you can imagine such a beast!). I would therefore 
        like  the  source I have described to use it as a sort  of  "tem-
        plate". Any comments/suggestions would be considered helpful.
        
        Thanks
        Jim C.
        (4carroll_j@spcvxa.spc.edu)

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      20 May 1992 05:15:08 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-Adresse from /dev/ttyp??

In article <1992May19.064837.1327@medtron.medtronic.com> rh0083b@medtronic.COM (Roger Hunen) writes:
>On SunOS the 'who' command shows the name or address of the host you came
>from. Isn't it possible then to use this information? I don't know what
>other UNIX flavors offer, so my hack may be Sun specific.

That information comes from /etc/utmp, which (in SunOS) only has 16 bytes
for the hostname field.  That's frequently insufficient to hold an entire
domain name, although many people are in fact using scripts that run who(1)
to get this information.  If all the places they login from have short
enough names, it should work.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 10:24:20 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   ip addr. via logon

Recently, Tillmann A. Basien (1365@pemcom.pem-stuttgart.de) asks how to
get the IP address of a user's terminal.

I'm not sure how helpful this is, but I've set up something on my HP
9000 model 827S running HP-UX 8.02 which will do for you much the same
as it does for me.

I use "who -u" and extract the last field using sed.  After this, do
what you will....

My application of who -u is to determine if users are on the local LAN
or coming in over terminal servers.  If the latter, then a subroutine
script kicks in.

Works great for me!  Any comments on how (non)standard this switch for
"who" is?

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 May 1992 06:05:39 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-Adresse from /dev/ttyp??

In article <1992May19.064837.1327@medtron.medtronic.com>
rh0083b@medtronic.COM (Roger Hunen) writes: 
>On SunOS the 'who' command shows the name or address of the host you came
>from. Isn't it possible then to use this information? I don't know what
>other UNIX flavors offer, so my hack may be Sun specific.

If you are using DNS, and someone logs in from a remote system that
has a long hostname (say medtron.medtronic.com), part of it will get
chopped.  You won't know for sure exactly where it came from, since
part of the name might not be enough to know what domain it really is.

Warner

-- 
Warner Losh		imp@Solbourne.COM
"Something grabbed a hold of my hand/ I didn't know it had my hand/
 but that's when all my troubles began" TMBG

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 06:09:56 GMT
From:      fontsda@handve.enet.dec.com (Daniel Au Yeung)
To:        comp.protocols.tcp-ip
Subject:   Look for CMU TCP/IP and SLIP for VAX/VMS


I am looking for a pointer to the FTP sites that have the CMU TCP/IP and SLIP for VAX/VMS.

Thanks a lot.

Daniel

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 May 1992 12:04:52 GMT
From:      bschmidt@bnr.ca (Ben Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: Berkeley LPD to Appletalk Postscript print servers?

In article <660@pacvax.UUCP> pgk@pacersoft.com (Paul Kamp) writes:
>
>In article <447@jumbo.Apple.COM>, dwb@austin.apple.com (David W. Berry)
 writes:
>> 
>> >  Does anyone know if any software for the Macintosh exists that can 
 receive
>> >  LPD requests from a UNIX host (via MacTCP) and re-spool them using 
 appletalk
>> >  protocols to a postscript printer that is localtalk or ethertalk 
>> attached?
>> 
>> Any macintosh running any A/UX >= 2.0 can also do this.
>> 
>I am pretty sure that Helio's EtherShare and IPT's Ushare do this also.
                                              ^^^^^^^^^^^^
Yup. IPT's uShare and Partner (with the print spooler option) work well in this
mode.  I believe that Wollongong's MacNFS client, MacPathWay also includes lpr
code, but I couldn't swear that it works in the requested direction
(UNIX-->Mac-->LW)

--
Ben Schmidt       Information Technology, Bell-Northern Research
bschmidt@bnr.ca   FAX:613-763-3283  /* My opinions, not BNR's */

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 13:05:43 GMT
From:      Richard.E.Brown@dartmouth.edu (Richard E. Brown)
To:        comp.protocols.tcp-ip
Subject:   IEEE Survey

IEEE Members:

The May/June 1992 issue of THE INSTITUTE (a tabloid insert mailed with
IEEE Spectrum) featured a reader survey asking about using the Internet
as a mechanism to distribute information.  The questions of the survey
are reproduced below.

If you feel strongly about these issues (and, of course, if you're an
IEEE member), then you can mail or fax this survey to them at the
address below.

Rich Brown                    E-Mail: richard.e.brown@dartmouth.edu
Manager of Special Projects   AppleLink address:  A0183
Dartmouth College             Telephone: 603/646-3648
6028 Kiewit Computer Center   Fax: 603/646-2810
Hanover, NH 03755-3523 USA         

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

Reader Survey - Part 2 - May/June 1992

1. If all or portions of THE INSTITUTE were available on Internet or a
similar network, would you be able to receive it?
                         o  Yes      o  No

   Would you want to?    o  Yes        o  Maybe      o  No     


   If yes or maybe, what other materials would you sometimes want to
receive?

   o  Reports of IEEE Board Meetings
   o  IEEE meeting notices
   o  Candidates' biographies/position statements
   o  Other: 



2. Are there other supplemental listings and materials that are or have
been published in THE INSTITUTE or IEEE Spectrum that you would like to
be able to receive via a network like Internet?

                                                                 yes  
no
   Advanced tables of contents of Proceedings/Transactions        o    
o
   Educational short courses/videos                               o    
o
   Book reviews                                                   o    
o
   New and recent publications                                    o    
o
   Software reviews                                               o    
o
   Hardware focus reports                                         o    
o
   Guide for authors                                              o    
o
   Calendar                                                       o    
o
   New standards listings                                         o    
o
   IEEE position papers                                           o    
o
   Other:


Reader Survey
THE INSTITUTE
345 East 47th St, 11th Floor
New York, NY 10017-2394 USA
Fax: 212-705-7543 or 212-705-7589

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      21 May 1992 01:56:25 -0700
From:      tli@skat.usc.edu (Tony Li)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: split horizon algorithm: impact on multi-ip addresses on network port

art@acc.com (Art Berggreen) writes in response to
a722756@pan.mc.ti.com (W. D. Rolph) writes:

    >      2)  What is the impact of split horizon algorithms on networks
    >             with multiple ip addresses supportted by a single ethernet tap?
    
    Here I assume you mean multiple IP addresses for different IP subnets on a
    single physical address. (rather than multiple IP addresses from the same
    subnet)
    
    If you treat each IP subnet as a separate IP network and perform RIP with
    split horizon on each subnet, things work fine.  Since RIP update are usually
    broadcast on LANs, the receiving end needs to use the source IP address
    to associate the update with one (if any) of the subnets it is logically
    attached to.
    
You might note that this is NOT the way a cisco operates.  A cisco
will send out one RIP update per network number (not subnet) that
appears on that interface, and that split horizon is done on a
per-interface basis.  If the router has a route out that interface,
then it will not be advertised out that interface.  This has the great
advantages in that it does not generate multiple updates per
interface, thus saving bandwidth, it does not confuse other routers
which could be listening to all updates, and it does not confuse hosts
which believe that they already know about all subnets that exist on
the cable.

This has the following implications:
	- all routers on the wire must know about all subnets
	  configured on that wire
	- hosts which are wire-tapping RIP must be prepared to accept
	  RIP updates from all addresses on that wire OR must have
	  static routes to all subnets on that wire pointing to their
	  own interface

    >      3)  What are the implications for environments with a single
    >             ethernet but two ip address spaces?
    
    Here I assume you mean two totally unrelated IP network numbers on a single
    wire (such as a class B and a class C).  Most modern IP implementations
    work on IP addresses and netmasks, and for the most part don't differentiate
    between different subnets and different networks.  In this case, the rules
    in part 2) above work the same.
    
Again, cisco does things a little differently.  A cisco will assume
that with two subnets of different major nets on the same wire, you
want two sets of updates.  Each set of updates will contain the
subnets for that particular major net.

Tony
-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 May 1992 14:54:17 GMT
From:      a722756@pan.mc.ti.com (W. D. Rolph)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   split horizon algorithm: impact on multi-ip addresses on network port

I wonder if I couyld ask for some thought from those more knowledgeable
than I on the split horizon algorithm for RIP.  I in particular am
curious about:
 
      1)  What is the split horizon algorithm?  Comer is a bit thin on
             the topic

      2)  What is the impact of split horizon algorithms on networks
             with multiple ip addresses supportted by a single ethernet tap?

      3)  What are the implications for environments with a single
             ethernet but two ip address spaces?

Thanks for your thoughts, appreciate any input you can give!
-- 

Regards.
 
Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 May 1992 15:38:03 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip source code

In article <1992May19.233421.2926@spcvxb.spc.edu> 4carroll_j@spcvxb.spc.edu writes:
>             I  was  wondering  if anyone was aware of  a  public  domain 
>        version  of  tcp-ip. This source code needs to be written  for  a 
>        multi-tasking,  multi-user  operating system. I am aware  of  and 
>        have partially reviewed the NCSA and KQ9 versions, but they  were 
>        both written for DOS (single-tasking, single-user).

The KA9Q code does adequate locking and works fine in a multi-tasking
multi-user environment, assuming you implement its locking primitives
in suitable ways.  This message is brought to you courtesy of a home-grown
80-port terminal server running (slightly old) KA9Q TCP/IP code fitted
into a cut-down V7 Unix kernel.
-- 
ISDN, n:  Incredibly Slow and Dumb      | Henry Spencer @ U of Toronto Zoology
Networking                              |  henry@zoo.toronto.edu  utzoo!henry

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 May 1992 15:41:33 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-Adresse from /dev/ttyp??

In article <vcn8sINNp2t@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>>On SunOS the 'who' command shows the name or address of the host...
>
>That information comes from /etc/utmp, which (in SunOS) only has 16 bytes
>for the hostname field.  That's frequently insufficient to hold an entire
>domain name...

I did one small hack here that can be helpful:  if the name won't fit, our
login processing is intelligent about what portion to keep.  If the name
ends in ".toronto.edu" or ".utoronto.ca", it's left-justified; if the
name ends in something else, it's right-justified (so we see the more
global parts of the name, which are typically more informative).
-- 
ISDN, n:  Incredibly Slow and Dumb      | Henry Spencer @ U of Toronto Zoology
Networking                              |  henry@zoo.toronto.edu  utzoo!henry

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 16:01:19 GMT
From:      gdox@informatik.tu-chemnitz.de (Guntram Dox)
To:        comp.protocols.tcp-ip
Subject:   What is "variable length subnetting" ?


Hi ,

I found the term "variable length subnetting" in a quite new TCP/IP- Tutorial
from IBM. But there was not much text about it.   

Is somebody out there, who can explain how "variable length subnetting" exactly
works ? I 've looked for a rfc, but nothing. A new feature ? Who does support
it yet ?

Thanks in advance,
Guntram

---------------------------------------------------------------------
Guntram Dox                     guntram.dox@informatik.tu-chemnitz.de
Fachbereich Informatik 21res89               
(Dep. of Computer Science)
TU Chemnitz, Germany                                

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 16:03:25 GMT
From:      mrb@mitre.org (Michael R. Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP between Cisco and BBN T/20

I've been able to get a BBN T/20 and Cisco router to
exchange reachability information.  WRT the Cisco router,
you should make sure that you use the T/20's ASN in
setting up the Cisco.  Likewise for the T/20.  Other than
that, all you should have to do is identify each other as
neighbors.

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 May 1992 16:07:13 GMT
From:      david@aim1.aztec.co.za (David Mason)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Telnet sessions immediately terminated by host

I'm trying to connect a Specialix terminal server to a Targon/31
model 15 (SVR4.0.0.11).  The main purpose is simply to provide sessions
to the host on dumb ascii terminals.  But I have to hold down the enter key
and only get a login: on about the 5'th try or so.  The initial telnet
sessions come up, (IP number, esc character etc), but I don't get a login.
Instead the message "Connection closed by remote host" is generated
by the terminal server.  Keeping the enter key down, and thus streaming
"enters" to the terminal server causes multiple attempts at a telnet
connection, and eventually after 5-10 tries the login comes up.

I have configured the ports on the terminal server to do silent telnets,
which means as soon as the terminal server sees DTR or the user hits
return, an attempt is made to telnet to a (previously configured) host.
It works fine to my Dell SVR4 machine, but not to the Targon.

I have been careful to check that the IP number and host names of the
terminal server and the hosts file of the Targon are in sync.  I also
added the terminal server into hosts.equiv.  Nothing seems to help.

Anybody out there seen this problem?  I'd be glad for your help.

-- 
David Mason                david%aim1.uucp@psg.com 
Unix System support      
Aztec Information Systems, Cape Town, South Africa
**** Please do not reply to address "david@aim1.aztec.co.za" ****

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 16:39:16 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: split horizon algorithm: impact on multi-ip addresses on network port

In article <a722756.706373657@pan.mc.ti.com> a722756@pan.mc.ti.com (W. D. Rolph) writes:
>I wonder if I couyld ask for some thought from those more knowledgeable
>than I on the split horizon algorithm for RIP.  I in particular am
>curious about:
> 
>      1)  What is the split horizon algorithm?  Comer is a bit thin on
>             the topic

Split horizon basically tries to avoid sending the same information back
to the source you got it from, for two reasons:

    A) If the source still have the same information, it is redundant and
       wastefull of bandwidth.

    B) If the source no longer has the information, it is misleading and can
       cause convergence problems (like count-to-infinity).

There are two important flavors of split horizon.  The first, "simple" or
"basic" split horizon just omits information learned from a source when
sending updates toward the source.  The second is "poisoned" split horizon
and basically states "for this destination, since I'd just route to you,
don't bother routing to me".  This form helps to avoid the propagation of
stale information and helps avoid some of the convergence problems.  It is
common to use poisoned split horizon when topology is changing and simple
split horizon when the topology stabilizes.

>      2)  What is the impact of split horizon algorithms on networks
>             with multiple ip addresses supportted by a single ethernet tap?

Here I assume you mean multiple IP addresses for different IP subnets on a
single physical address. (rather than multiple IP addresses from the same
subnet)

If you treat each IP subnet as a separate IP network and perform RIP with
split horizon on each subnet, things work fine.  Since RIP update are usually
broadcast on LANs, the receiving end needs to use the source IP address
to associate the update with one (if any) of the subnets it is logically
attached to.

>      3)  What are the implications for environments with a single
>             ethernet but two ip address spaces?

Here I assume you mean two totally unrelated IP network numbers on a single
wire (such as a class B and a class C).  Most modern IP implementations
work on IP addresses and netmasks, and for the most part don't differentiate
between different subnets and different networks.  In this case, the rules
in part 2) above work the same.

>Thanks for your thoughts, appreciate any input you can give!
>-- 
>
>Regards.
> 
>Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263

Art

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 17:00:37 GMT
From:      dean@towers.rn.com (Dean Riddlebarger)
To:        comp.protocols.tcp-ip
Subject:   Kbridge location?


I must have trashed the kbridge ftp site announcement in my last
housecleaning pass.....can some kind soul email the site info to me?

Thanks!

-- 
<*>  Dean Riddlebarger                        The bus came by,             <*>
<*>  Ameritech Information Systems             And I got on,               <*>
<*>  317-488-3067     dean@towers.rn.com      That's when it all began...  <*>

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 18:53:45 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: split horizon algorithm: impact on multi-ip addresses on network port

In article <a722756.706373657@pan.mc.ti.com>, a722756@pan.mc.ti.com (W. D. Rolph) writes:
|> I wonder if I couyld ask for some thought from those more knowledgeable
|> than I on the split horizon algorithm for RIP.  I in particular am
|> curious about:
|>  
|>       1)  What is the split horizon algorithm?  Comer is a bit thin on
|>              the topic

Please see the RFC on RIP (RFC 1058) for a good discussion of split horizon.
The idea is that if you learned a route from a particular interface, don't 
advertise it back out that interface.  This avoids the problem of ping ponging
when the real route is lost.  (If a pear losses a route but thinks you can
reach it, then it will forward the packet to you.  You in turn think the pear
is the best route so you forward the packet to the pear who immediately returns
it.  This continues until time to live expires.)

|> 
|>       2)  What is the impact of split horizon algorithms on networks
|>              with multiple ip addresses supported by a single ethernet tap?

??? All useful networks have more than one ip address on them, one for each
host.  If the question is "What about hosts with multiple IP address on the
same physical connection?", I understand.  Those hosts will receive the RIP
updates (sent to the broadcast address for ethernet) and process it by relating
the routes advertised to the originator router.  Since it is assumed that all
other hosts on that physical network also received the packet, the new routes
learned would not be advertised.  Note that the route to the networks directly
connected to would not be learned.  Since they are not learned split horizon
has no effect on their advertisement.
|> 
|>       3)  What are the implications for environments with a single
|>              ethernet but two ip address spaces?

??? I think this is how I interpreted your first question.

|> 
|> Thanks for your thoughts, appreciate any input you can give!
|> -- 
|> 
|> Regards.
|>  
|> Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263

If I can help or if I answered the wrong question just let me know and I'll
try again.

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 19:30:34 GMT
From:      pbh@athena.mit.edu (Paul B Hill)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP/IP toolkits for PC's

Note that the FTP product does not support a socket API nor the RPC API under
Windows.

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 19:44:44 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: What is "variable length subnetting" ?

Variable length subnetting takes advantage of the fact that the subnet
mask is generally not distributed off of the subnet.  This allows a
subnet to be made into many subnets by legthening the mask.  This
is useful when there are some subnets with many hosts and others
with just a few.  The RFC on OSPF discusses this (since OSPF does
distribute the MASK off the subnet!).

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      20 May 92 19:49:46 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: split horizon algorithm: impact on multi-ip addresses on network port

People around here are getting a good laugh about my reference to fruit.
Sorry, I meant to say (and should have spelled correctly) peer, not pear.
-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      20 May 1992 20:16:04 GMT
From:      xcc@ira.uka.de (Thomas Weinstein)
To:        comp.protocols.tcp-ip
Subject:   SLIP/PPP dialup software

Sorry if this is a FAQ:

	Is there any dialup software that can be used with SLIP/PPP
	on a Sun 4 running Sun OS 4.1.1?
	I succeeded installing SLIP on my machine and can make
	SLIP connections, but have to dial up manually (with kermit).
	I'm in search for something like the Dialup IP 2.0 package,
	but this runs only with SUN OS 3.5 and the authors told me
	there is no update.

	Please send answers/comments/suggestions as E-Mail to
	xcc@ira.uka.de

Thank You in Advance

Thomas



-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 May 1992 21:49:42 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

In article <10717@platypus.uofs.uofs.edu> bill@uofs.uofs.edu (Bill Gunshannon) writes:
> No..  Nothing created thru the use of TAX dollars is proprietary.

That's the theory. Unfortunately, it's not always true. Look at the little
block of italic text at the end of just about any article in NASA Tech Briefs
for example.
-- 
Peter da Silva                                                      `-_-'
/* No comment */                                                     'U` 
Ferranti International Controls Corporation                    Have you hugged
Sugar Land, TX  77487-5012    +1 713 274 5180                  your wolf today?

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 May 92 22:34:41 GMT
From:      woo@ra-next.arc.nasa.gov (Alex Woo x6010 227-6 rm 315)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   NFS for 486 DOS PC

This posting is for a colleague.  Send replies directly to
	koga@ames.arc.nasa.gov

We are looking for a software package which provides NFS client
capabilities for a 486 PC with a 3COM 3C503 ethernet card.
It should work with MS Windows.  

We would also like X-windows emulation in the same package.

Please send information to either koga@ames.arc.nasa.gov and
schreine@ra-iris.arc.nasa.gov.  Or FAX the information to
the number below.

Thanks.
--
==============================================================
Alex Woo, MS 227-6               woo@ames.arc.nasa.gov
NASA Ames Research Center        NASAMAIL      ACWOO
Moffett Field, CA 94035-1000     SPANET        24582::WOO
(415) 604-6010 (FAX) 604-4357   {hplabs,decwrl,uunet}!ames!woo
==============================================================

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      21 May 92 00:25:04 GMT
From:      sean@trane.UUCP (Sean Gallagher)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   wanted: rcp software for the Macintosh

We are trying to resolve a nasty connectivity problem between UNIX and
the Macintosh. Due to forces beyond our control, FTP has turned out to
be unworkable and NFS is not an option either.

So, we are interested in finding RCP software that runs on the Mac. 
Something that behaves like an rcp demon would be very nice, but we could
also live with just client software which has a nice human interface.


Any suggestions as to vendors or products would be much appreciated.

-Sean Gallagher
-- 
 ---------------------------------------------------------------------------- 
  Sean Gallagher	[ pacbell!trane!sean ]     [ trane!sean@PacBell.Com ]
                        [ and remember to use \! in csh instead of ! ]

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 May 1992 02:48:13 GMT
From:      ken@cujo.curtin.edu.au (Ken Taylor)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for PC or MAC

rbr@pdx.csd.mot.com (Bob Rose) writes:
: Can anyone direct me to a public domain SLIP implementation for a MAC or PC?
: What about PPP?  Appreciate your help.

NCSA/BYU Telnet 2.4.19 for the Macintosh impements SLIP Telnet and FTP clients
This is a TOP product (I use it all day everyday)

It is available via anonymous ftp from bert.cs.byu.edu

Ken
-- 
Ken Taylor        | ken@cujo.curtin.edu.au        |"Who is king over my domain?
User Consultant   | Ken_Taylor@qmcc.curtin.edu.au | What's the force that has
Computing Centre  | Snail: GPO Box U1987, Perth   | kept me sane?"
Curtin University |        Western Australia 6001 |             - Happy Rhodes

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 May 1992 09:43:02
From:      backman@ftp.com  (Larry Backman)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP/IP toolkits for PC's

In article <1992May20.193034.22545@athena.mit.edu> pbh@athena.mit.edu (Paul B Hill) writes:

 >> Note that the FTP product does not support a socket API nor the RPC API under
 >> Windows.

Note that the upcoming PCTCP 2.1 release will have an implementation of
the upcoming (and maybe just announced) WinsockAPI DLL.  This DLL was
designed by a consortium of vendors to allow Windows sockets applications
to use a binary DLL interface to different vendor's TCP stacks.

FTP, Sun, Novell, Netmanage, Wollogong, etc. were all involved in this
standard.

We decided a while back it was better to take our time and write a conformant
sockets DLL than to release a proprietary one which would need its interface
changed down the road.  Unfortunately; what looked like a Feb/March 
release for the WinSockAPI API specification dragged on through May/June.
Thats the breaks in the world of standards.


Larry Backman
FTP Software
backman@ftp.com


-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      21 May 92 10:47:23 GMT
From:      gek@ncn.uucp (gek)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Telnet sessions immediately terminated by host

Subject: Telnet sessions immediately terminated by host
Message-ID: <david.706378033@aim1>
Keywords: telnet
Organization: Aztec Information Systems
Date: Wed, 20 May 1992 16:07:13 GMT
Lines: 26

>I'm trying to connect a Specialix terminal server to a Targon/31
>model 15 (SVR4.0.0.11).  The main purpose is simply to provide sessions
>to the host on dumb ascii terminals.  But I have to hold down the enter key
>and only get a login: on about the 5'th try or so.  The initial telnet
>sessions come up, (IP number, esc character etc), but I don't get a login.

This is a bug in the TOS 4.0.11, solved in a patch called 4.0.13.
(btw. TOS 4.0.11 is based in SVR3 NOT SVR4)

-- 
      nuug!gek@ncn.uucp
       Geir Kristensen
  Siemens Nixdorf D10/UNIX
+47 2 749558 / FAX +47 2 740987

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 May 1992 14:55:09 GMT
From:      zrhk0390@awssg6.rus.uni-stuttgart.de (Andreas Wierse)
To:        comp.protocols.tcp-ip,comp.lang.c++
Subject:   Sockets represented as Objects in C++?


Hi,

a few weeks ago I read something about using C++ classes
to represent the TCP-sockets as objects. I have no idea where I
read about it (maybe some newsgroup or a printed publication),
sorry, but it would be nice, if anybody else could remember and
point me to it :-)

Thanks in Advance

Andreas Wierse


/*--------------------------------------------------------------------------*/
/* Andreas Wierse                                                           */
/* Institut fuer Computeranwendungen II                                     */
/* Abteilung Computersimulation und Visualisierung                          */
/* (Institute for Computerapplications II                                   */
/* Department Computersimulation and Visualization)                         */
/*-------------------------+------------------------------------------------*/
/* Rechenzentrum           | wierse@rus.uni-stuttgart.de                    */
/* Universitaet Stuttgart  | Tel.: ++49-711-685-5796                        */
/* Allmandring 30          | Fax:  ++49-711-682357                          */
/* 7000 Stuttgart 80       |                                                */
/*-------------------------+------------------------------------------------*/
-- 
/* Computer Center         | Andreas Wierse                                 */
/* University of Stuttgart | E-Mail:  wierse@rus.uni-stuttgart.de           */
/* Allmandring 30          | Tel.: ++49-711-685-5796   Fax: ++49-711-682357 */
/* 7000 Stuttgart 80       | Institute for Computerapplications II          */

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 May 1992 15:05:18 GMT
From:      greg@cityzoo.acs.umbc.edu (Greg Sylvain,Lib 007a,3929,6758737)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domain
Subject:   The proper use of res_send and dn_expand ?!?!?!?!

	Hi all,

	Has anyone ever used res_send to get answer from the nameserver before?
I've been going from the Comer book, and looking at the message layouts, 
but they don't seem to match up.  Worse yet, I can't find any code examples 
using this function to tell me if I'm using it correctly or not.  I think I'm 
calculating the offests wrong into the answer section of the response from 
res_send, but I'm not sure.

	If anyone has ever used this function, could they send me a small 
coding example of it, or pointing me in the direction of where to 
find some.

	Thanks in advance for any help,
	greg



Greg Sylvain			UUCP: 			...!{uunet}!umbc3!greg
Academic Computing Services	Internet (arpa): 	greg@umbc3.umbc.edu
Systems Programmer		Phone :			410 - 455 - 3929

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      21 May 92 15:58:33 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

In article <id.2GXP.9JI@ferranti.com>, peter@ferranti.com (Peter da Silva) writes:
|> In article <10717@platypus.uofs.uofs.edu> bill@uofs.uofs.edu (Bill Gunshannon) writes:
|> > No..  Nothing created thru the use of TAX dollars is proprietary.
|> 
|> That's the theory. Unfortunately, it's not always true. Look at the little
|> block of italic text at the end of just about any article in NASA Tech Briefs
|> for example.
|> -- 
|> Peter da Silva                                                      `-_-'
|> /* No comment */                                                     'U` 
|> Ferranti International Controls Corporation                    Have you hugged
|> Sugar Land, TX  77487-5012    +1 713 274 5180                  your wolf today?

Or UCSD (a public Univ.) P system (remember PASCAL?).

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      21 May 92 16:02:24 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: split horizon algorithm: impact on multi-ip addresses on network port

In article <l1mpdpINNbil@skat.usc.edu> tli@skat.usc.edu (Tony Li) writes:
>    
>Again, cisco does things a little differently.  A cisco will assume
>that with two subnets of different major nets on the same wire, you
>want two sets of updates.  Each set of updates will contain the
>subnets for that particular major net.
>
>Tony

Hi Tony!

IMHO, the days of distinquishing between nets and subnets by looking at
the "class" of the network are fading and will eventually be completely
controlled by netmasks.

Art

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 May 1992 18:28:28 GMT
From:      jost@sybus.com (Mike Jost)
To:        comp.protocols.misc,comp.protocols.snmp,comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Dynamic IP address learning

 
   After having followed news groups on the net for quite sometime and 
 also having learned many valuable things I find myself thrust into finding
 an answer to a problem that is beyond the scope of my knowledge, so it 
 is with great expectation that I turn to the collective wisdom of the
 Internet. 

 PROBLEM:   Installing a SNMP managed network device for the first time.
            Since this is the initial installation the box does not have
	    an IP address configured. Out of band management is over
	    an async port from a network management station running
	    SNMP over slip. How can the box dynamically learn its
	    IP address? RARP is not a possibility because slip does
	    not support it.


 SITUATION: Theses boxes used to have an embedded configuration
	    menu system. Marketing has proposed that this be 
	    totally eliminated and configuration be off loaded
	    to the NMS.


 Has anyone encountered a similar situation or knows of an information
 source that I can consult. Any help will be greatly appreciated.

 Thanks in advance,
			Mike j.


	 
	 jost@sybus.com


-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      21 May 92 18:31:26 GMT
From:      berman@nlm.nih.gov (Lew Berman)
To:        comp.protocols.tcp-ip
Subject:   Re: Network diagnostic tool: what to buy?

In article 1473@frcs.Alt.ZA, peter@frcs.Alt.ZA (Peter Greenwood) writes:
>
>We're looking for a tool that provides diagnostic capabilities that
>will enable us to maintain and troubleshoot our LAN (Ethernet running
>IP and IPX, 40 Novell file servers (2.15 & 3.11), 60 UNIX machines,
>about 2000 PCs).  Network General's "Sniffer Network Analyser" looks
>very promising.
>
>What's your experience?  What else is available that can do as good or
>better a job as Sniffer?
>
>Peter Greenwood
> 
>
>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>Peter Greenwood
>peter@frcs.alt.za                  ...!uunet!{m2xenix,ddsw1}!frcs!peter


Are there any public domain tools similar to Sniffer?

Lew Berman
National Library of Medicine
Bethesda, MD

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      21 May 92 18:58:00 GMT
From:      mtayler@pilot.njin.net (Mark Tayler)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc
Subject:   Questions on ftp, ftp servers, kermit


On campus we have the following systems :
   SUN IPC  running Solaris 1.0
   AT&T 3b2 600 running Sys V r3.2.1
   IBM PS/2s running DOS 5.0 (some with windows)

These systems are connected via ethernet and will we be to INTERNET
shortly.  
Help in the following topics would be appreciated.

1)	Any good books describing TCP/IP for both user and programmer
2)	Where can I get ftp for the above systems ?
        I need both programs (sources or binaries) and documentation.
3)	Any good books on Kermit for both users and programmers.
4)	Where can I find the latest version of kermit .
5)	Where can I find information of ftp servers


I am fairly new at this, as you can probably tell, and I appreciate
any information that is available.

Thanx
Mark T.

 
******************************************************************************
*  Mark L. Tayler                                 System Administrator:      *
*  mtayler@pilot.njin.net                         County College of Morris   *
*                                                 (201) 328-5778    (VOICE)  *
*                                                 (201) 328-5058    (DATA)   *
*                                                 No Net Access Yet !!!!     *
******************************************************************************

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      21 May 92 19:19:07 GMT
From:      mtayler@pilot.njin.net (Mark Tayler)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip.domains,comp.protocols.nfs
Subject:   Questions on NFS for DOS & UNIX

I have a few questions about the product NFS if anyone can help me.
We are getting a SUN IPC in the very near future.

1) Does NFS come with the SUN O/S (Solaris 1.0) or must we buy it?
2) Is NFS a commercial product ?
3) Is there any freeware that does NFS or sharing of direcories or 
   filesystems for either UNIX or DOS ?
4) If so, are there any ftp sites for information ?

All any help is always appreciated.

Mark T

******************************************************************************
*  Mark L. Tayler                                 System Administrator:      *
*  mtayler@pilot.njin.net                         County College of Morris   *
*                                                 (201) 328-5778    (VOICE)  *
*                                                 (201) 328-5058    (DATA)   *
*                                                 No Net Access Yet !!!!     *
******************************************************************************

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 May 1992 19:47:07 GMT
From:      rexm@trailbossadvtech.uswest.com (Rex Mammel)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: split horizon algorithm: impact on multi-ip addresses on network port

>      3)  What are the implications for environments with a single
>             ethernet but two ip address spaces?
 
>Here I assume you mean two totally unrelated IP network numbers on a single
>wire (such as a class B and a class C).  Most modern IP implementations
>work on IP addresses and netmasks, and for the most part don't differentiate

In IGRP I have had the experience where when I added a secondary 
address on a router interface the secondary address couldn't route to the primary
address. I debugged IGRP and sure enough there was no route being distributed 
out that interface for the primary address.  I added a staic route and 
things started working (there must be a better way.)  

If split horizon is similar in RIP then perhaps a similar fix would be needed,
or of course some configuration change to the RIP software.
-- 

What is really cool is when a different form of music comes along and
blows away all your previous assumptions and reference points.  - Jeff Beer
---------------=================>>>>>> * <<<<<<=============--------------------

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 May 1992 22:08:47 GMT
From:      kbridge@magnus.acs.ohio-state.edu (Doug Karl)
To:        comp.protocols.tcp-ip
Subject:   Re: Kbridge location?

Kbridge,  or OSU KarlBridge can be found on:

nisca.acs.ohio-state.edu.  It is an advanced protocol filtering bridge program.
Ethernet to Ethernet on a 286/386 clone.  NetTek has been setup to market
the hardware aprox $1100 and software is available free via ftp.

Version 2.0 is soon to come out (in local beta test) which supports filters for:

	1) Several Ethernet Protocols
	2) IP address and/or IP subnet
	3) IP socket number (incomming and/or outgoing)
	4) Decnet Address and/or Decnet area
	5) Decnet Object Number and/or Object Name
	6) AppleTalk Request Strings (ie looking for LaserWriter...)
	7) AppleTalk Reply Strings (ie Rm478LaserWriter)
	8) AppleTalk Zone Names

Ver 2.0 also has SNMP Support for MIB II, Ethernet Interface MIB and Bridge MIB

Other Suggestions will be welcome:  Considering LAT and LAVC type filters.
ANY INTEREST?


ALSO: FYI Futures: (No guarentees! just what we are currently working on):

	1) Generic IP Tunneling (ie tunnel any Ethernet Protocol over IP
		including IP itself)

	2) Support for Wireless ethernet (ala NCR Wavelan) can setup
	   Ethernet <-> KBridge <-> Air <-> KBridge <-> Etherent 
		Air = Up to 5 miles spread spectrum RF at aprox 2 Mbits/second

	3) Support for OSU's Advanced Remote Monitoring MIB which does:
		Number of Packets
		Number of Bytes
		Packet Distribution
			and
		Network Loading Historgram
		 
		 	For Each Protocol on each:
				Network
				Ethernet Address
				Ethernet to Ethernet connection
					and/or
				IP to IP Connection (machines/subnets/nets)

	    Yes it takes up alot of memory, we do alot of tricks.
	    Watch for draft MIB to be uploaded soon.

	4) RMON support (OSU's MIB is currently a superset)


-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      21 May 92 23:59:51 GMT
From:      srgpgct@grace.dsir.govt.nz
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietory

In article <23154K@erik.naggum.no>, Erik Naggum <erik@naggum.no> writes:
> Jan Speth <speth@vxdesy.WITHOUT.DOMAIN> writes:
> |
> |   Russell Nelson <nelson@crynwr.com> writes:
> 
> You left out an important part of Russ Nelson's article, Jan:
> 
> ||  Can someone please explain to me why John Gantz believes TCP/IP to
> ||  be proprietary?  In his current "White Paper to Management" in
> ||  "Networking Management" 5/92, he continually refers to TCP/IP as
> ||  proprietary, then he admits that "OSI products aren't ready yet or
> ||  cost too much".
 
 John K Scoggin <scoggin@daisy.udel.edu> writes:
> |   > I believe that you will find this particular individual comments on a wide
> |   > range of subjects, including "Open Systems", PCs, networks, etc.  He is a
> |   > consultant.  I doubt VERY MUCH that he has any real first-hand experience
> |   > in most of the subject areas he comments on.
> |   ...
> 
> Note that "this particular invididual" refers to John Gantz, which
> Russ asks _about_, and John Scoggin answers _about_.
> 
> |   I would like to thank that "particular individual," Russ Nelson, for
> |   developing the packet driver interface which makes possible the internet
> |   connection which I am now using!
> 
> Although that's nice, Russ was never "that particular individual".  I
> think you should apologize to John Scoggin for insinuating that he
> regards Russ that way.
> 
> (I'm posting this because I was somewhat perplexed by your comment, and
> thought maybe others would be, too.)

I disagree! I think that maybe John Scoggin should have proof-read what he 
wrote. I also initially got the same impression, and only because I am aware 
of Russ's reputation I re-read the article, and only then understood what 
was intended to be said.

Gary Turner.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 00:29:47 GMT
From:      joe@crl.ucsd.edu (Joe)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   tcp-ip security question

I am new to this, but:

I was recently reading through the DARPA internet RFC's discussing
the varied internet protocols (c.f., RFC 0791, 0793), and an obvious
security problem occured to me. A hacker who knew what he was doing
could write a dumb monitoring program to "eavesdrop" on live
IP-encapsulated datagrams, filtering for certain specific IP-address
to IP-address packets, and then monitoring the contents of those
packets. If those packets turned out to be the login sequence of
a telnet process, the monitor program could simply record the password
phase. Ouch.

Is this a major problem, or am I a dummy?

Joe.
-- 
*****************************************************************
   Joseph Kraska   :		joe@crl.ucsd.edu
                   :		joe@crl.bitnet	
*****************************************************************

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 01:29:25 GMT
From:      ggw@wolves.uucp (Gregory G. Woodbury)
To:        comp.protocols.tcp-ip
Subject:   How to firewall a sub-net, or can routers do it?

FAQ Time!

My office (up at the nearby University) has a disconnected tcp-ip subnet
that I have been keeping clean and up-to-date with a real, assigned
subnet number (152.3.16.xxx).  We have been wanting to go full internet
connected for several years but have faced budget and wire problems
until recently.   Now, the university network is in the basement,
waiting for me to plug in and be just a bridge away from the fiber
backbone!

BUT

(There had to be a catch to this, right?)  My boss is not exactly the
most trusting soul in the world, and we do have some data sets that
require certain amounts of protection, so I can't just plug in the net
and go without satisfying his (paranoid?) demands.

What I have come up with is something like the following:

sub-net-cloud      router     host      bridge      internet-etc....
|-|--|-|--|---------|  |--------|--------|   |--------->

with the idea being that the rest of the world can see 
"host" but not the stuff in "sub-net-cloud" because the "router" only
lets machines in sub-net-cloud communicate when they initiate the
connection.  Except that "host" can reach into "sub-net-cloud" to
deliver mail or other services.  "Internet-etc" should only be able to
see "host" for email delivery.

This implies that "router" should be able to look into the packets and
classify them by service type and port before deciding that the packet
can be passed. (Yes, I understand that it slows things down a lot.)  It
will still let machines in "sub-net-cloud" get nameservice from
"internet-etc" and to telnet out to internet-etc, but prevent intruders
from getting to anywhere except "host".

Is this correct?  Is this all wet?  Is this silly?  What is available to
act as "router"?   [I'm thinking of a dedicated '286 with PC-Router?]

Any advice will be appreciated.  Here or to ggw@cds.duke.edu :-)

-- 
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...duke!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu     ggw%wolves@duke.cs.duke.edu
[The line eater is a boojum snark! ]           <standard disclaimers apply>

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 02:08:16 GMT
From:      dank@blacks.jpl.nasa.gov (Dan Kegel)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

joe@crl.ucsd.edu (Joe) writes:
>A hacker who knew what he was doing
>could write a dumb monitoring program to "eavesdrop" ...
>If those packets turned out to be the login sequence of
>a telnet process, the monitor program could simply record the password
>phase. Ouch.
>Is this a major problem, or am I a dummy?

It's major.  A standard for encrypted telnet is on the way.
Tell your Unix vendor you want it in their next release.
- Dan K.

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 02:31:17 GMT
From:      mvanheyn@copper.ucs.indiana.edu (Marc VanHeyningen)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Re: tcp-ip security question

In article <1375@cogsci.ucsd.EDU> joe@crl.ucsd.edu (Joe) writes:
>I am new to this, but:
> [ ... ]
>                                A hacker who knew what he was doing
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is a redundant phrase, no? :-)
(I assume you've already received tons of email about the distinction
between "hacker" and "cracker")

>could write a dumb monitoring program to "eavesdrop" on live
>IP-encapsulated datagrams, filtering for certain specific IP-address
>to IP-address packets, and then monitoring the contents of those
>packets. If those packets turned out to be the login sequence of
>a telnet process, the monitor program could simply record the password
>phase. Ouch.

Provided she had a machine attached to a portion of the network which
carried those packets, sure.  Email, files moved or utilized via a
network... anything sent unencrypted could be gotten.
-- 
Marc VanHeyningen    mvanheyn@indiana.edu  (mvanheyn@iubacs.BITNET)
Indiana University
Computer Science              TAKE BACK AMERICA!!!!!
Generic Grad Student          (wait, did anybody save the receipt?)

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 08:29:35
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Network diagnostic tool: what to buy?

In article <1992May21.183126.15005@nlm.nih.gov> berman@nlm.nih.gov (Lew Berman) writes:

    In article 1473@frcs.Alt.ZA, peter@frcs.Alt.ZA (Peter Greenwood) writes:
    >
    >...What else is available that can do as good or better a job as Sniffer?

Depends on what particular network monitoring tasks you want to do.

There are a number of hardware-based network monitors, some of which are
sold as a complete package, including LAN interface and PC, or as an
add-on to a PC you already have: Novell's LANAlyzer was the first,
Spider's SpiderMonitor, Network General's Sniffer and Hewlett-Packard's
product have all been on the market for quite a while too.  Some support
either Ethernet or 802.5, some are Ethernet only.  Prices range from in
excess of $30K (complete PC with add-on parsers) to $5K (supply your
own PC, only basic parsers).

The hardware monitors have varying levels of packet parsing; some include
quite a few as shipped, others require you to buy add-ons.  They all make
a point of being able to capture all traffic from a 100%-loaded Ethernet,
but the can only do this as long as they have buffer space available, and
the amount varies.  They can usually do a fairly good job of diagnosing
hardware errors, and most have traffic generation facilities.

There are also a number of software LAN monitors, which run on PCs with
commercial LAN interfaces: FTP Software's LANWatch was the first, Wollongong
sells Win/Watch, Intercon has WatchTower for MACs, Neon has a product, etc.
Some support NDIS or Packet drivers, some only go direct to the hardware.
The software alone costs between $500 and $1500 in quantity one, some vendors
offer discounts in quantity.

The commercial interfaces used by the software monitors don't usually
capture as much of a fully-loaded net as the hardware monitors can; the
actual performance varies with the monitor, the interface, and the PC you
install it on.  I've tested our LANWatch as capturing a burst rate of 6000+
packets per second on a 20Mhz 386 with an Interlan NI5210.  They typically
include all parsers in the basic package, and some supply source code so
you can modify or add parsers and filters.  They typically don't do as well
diagnosing hardware errors, and don't include traffic generation.
    
    Are there any public domain tools similar to Sniffer?

The MIT "Netwatch" software-only monitor was originally distributed free
with the PC-IP package, and has since been evolved somewhat as a separate
item.  It is similar to the Sniffer in that it captures packets and displays
them, but it doesn't perform at the same level, nor does it parse packets
as completely (assuming you buy the appropriate add-on parsers for your
Sniffer), and it doesn't do traffic generation.
    
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901


-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 06:25:01 GMT
From:      jrosen@vms.macc.wisc.edu (Jay Rosenbloom, MACC, UW-Madison)
To:        comp.protocols.tcp-ip
Subject:   Attack of the Killer ICMP Address Mask Replies

Has anyone dealt with the following problem?  When a station on our
admittedly oversized campus ethenet broadcasts an ICMP address mask
request, 100s of machines try to respond simultaneously.  First comes
a wave of ARP requests for the hardware address of the machine that
issued the request.  The mask requesting host manages to respond to a
number of these causing a wave of address mask replies.  The repliers
are all kinds of machines: SunOS, Ultrix, NeXT, Iris, AIX, PCs (not
sure what software yet).  Some of these (I won't name names) do the
following: they reply by sending an IP unicast to the ethernet
broadcast address.  This causes some machines to try to forward these
datagrams and send ICMP redirects.  Not too cool.

Yes, I admit that anyone who builds an ethernet as large as ours is probably
asking for this sort of problem (let this be a lesson to those who are still
trying to decide between bridging and routing).  mea culpa...

RFC1122 (Internet Host Requirements) says that a host should
not answer address mask requests unless specifically configured to do so.

from RFC1122  sec 3.2.2.9:

   A system MUST NOT send an Address Mask Reply unless it is an authoritative
   agent for address masks.  An authoritative agent may be a host or a
   gateway, but it MUST be explicitly configured as a address mask agent.
   Receiving an address mask via an Address Mask Reply does not give the
   receiver authority and MUST NOT be used as the basis for issuing Address
   Mask Replies.

   With a statically configured address mask, there SHOULD be an additional
   configuration flag that determines whether the host is to act as an
   authoritative agent for this mask, i.e., whether it will answer Address
   Mask Request messages using this mask.

[ ... stuff omitted ...]

   DISCUSSION
      Hosts that casually send Address Mask Replies with invalid address
      masks have often been a serious nuisance.  To prevent this, Address
      Mask Replies ought to be sent only by authoritative agents that have
      been selected by explicit administrative action.

I think I know how to disable the address mask requests in some cases, but as
the RFC points out this really isn't where the problem lies.

Can anyone (any developers out there?) give an example of how to disable ICMP
address mask replies on any one of the systems I listed above?  I'm *really*
interested an answer to the preceding but I'm not holding my breath; we'll be
moving a lot of our LANS to a routed backbone this summer.


.............................................................................
Jay Rosenbloom               Phone: 608-262-9421         jrosen@macc.wisc.edu
Univ. of Wisconsin-Madison   Fax:   608-262-4679         jrosen@wiscmac3
Madison Academic Computing Center,  1210 W. Dayton St., Madison, WI  53706

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 12:53:55 MDT
From:      rarobert@ursa4.cs.utah.edu (Robin Roberts)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Re: tcp-ip security question

The following are comments/answers to some of the questions that have
been flying around - 

1.  The anarchist discussion belongs on another group.  Let's move it off.

2.  The DES encryption algorithm (and products that support it) are under
U.S. export restrictions.  There may be some countries that we can export
it to (NATO countries, or "friendlies" like the Brits and Canadians),
but it is otherwise completely restricted.  Of course, the algorithm
is published in the open literature...

3.  If you're worried about people eavesdropping on your network, there
are several things you can do.  As someone said, try physical security.
If the configuration allows, you can put your network cable in a pressurized
conduit (to prevent external penetration).  You can physically secure
the network wiring closets, servers, etc.  You can employ encryption
in many different ways - such as at the Data Link Level (e.g. all net
traffic is encrypted), application level (user's can choose to use it
or not), or the more formal security additions to the ISO suite such
as SP3 and/or SP4 which offer things like encryption of network addresses
and header information.  It's like someone else said... it depends on
the threat, and how much time/money you are willing to spend to protect
yourself.  

   Frankly, if you perceive that someone is THAT interested in your
data, you may also consider the RF emanation problem.  If I wanted to
steal your information, it's probably easier for me to sit outside your
office with about $200 worth of stuff from Radio Shack in my car...
and pick up the emanations from your monitor.  It may be much easier 
than trying to get a sniffer attached to your network.

   Bottom line:  don't be paranoid about security.  Sit down with your
users, company/organization management, and computer administrators.
Decide what you think are realistic threats.  Establish some type of
security policy - you'd be amazed at how much you can do with some
reasonable rules and procedures.  Decide how much you are willing to
devote to security issues - in terms of time, money, and resources.
Arrange your threats in priority order - and decide what technical
mechanisms you need (over and above the security procedures) and can
afford.  Be realistic - the worst security is the kind that people won't
use.  (For instance, you should make people change their passwords 
frequently, but not TOO frequently!  Don't let people choose their own
passwords, but don't give them "R6@erY7q", either.)  

   Once you have a policy and some mechanisms in place, review your 
threats.  Evaluate the threats against your policy/mechanisms, and recognize
that you probably can't plug all the holes.  Have senior management 
sign-off on the policy and the remaining vulnerabilities... and make
it a company practice to review the policy/mechanisms that are in place
against a new threat survey at least once each year.

   Sorry to ramble on for so long...   rr.




-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 06:57:42 GMT
From:      wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.unix.bsd
Subject:   Civilizing rdump?  Cheap bridges?  How not to swamp an Ethernet


Has anybody modified rdump to be civilized about the amount of network
bandwidth it uses?  The folkks we share our subnet with recently
acquired a 5 GB 8mm tape, so they've been doing Level 0 dumps of all
their machines across the network on Friday afternoons.  Arrgh.
I've got a diskless workstation, which loses entirely, but even the
people doing simple telnets get hosed when they  do this.

Part of the problem is educating them not to do it, of course, and I'm
planning to get a bridge
	     (any recommendations for a cheap local bridge?)
which will provide some isolation, but their local users are also
getting killed by rdumps, and when we start doing backups we'd rather
not run into the same problem.

Has anybody modified rdump to limit itself to a reasonable fraction of
the network bandwidth, like 50%, so that other applications can work also?
It probably wasn't a big issue back when it was written, since tape
drives were slower and TCP/IP performance was much slower, but these
days it's easy to suck up most of 10 mb/s.

	       Thanks;  Bill
-- 
				Pray for peace;      Bill
#Bill Stewart +1-908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M312 Holmdel NJ
# I'm trying to get sendmail working right; apologies if mail to me bounces.

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      23 May 1992 00:51:22 -0700
From:      tli@skat.usc.edu (Tony Li)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: split horizon algorithm: impact on multi-ip addresses on network port

In article <1992May22.144311@pan.mc.ti.com> a722756@pan.mc.ti.com (W. D. Rolph) writes:
    
         2)  First Cisco configuration:
     
                 primary address 157.87.0.2, secondary 192.31.38.91
    
                     no RIP packets were sent out the 192.31.38.0 space

This is cisco bug CSCdi03638.  This is fixed in 8.3(3) and 9.0(1).
Please contact customer service and upgrade your router.

         3)  Second Cisco configuration:
                 157.87.0.2 on ethernet port 0
                 192.31.38.85 on ethernet port 1
    
                      Catatonic collapse of the network

Any configuration with two different ethernet interfaces on the same
cable is going to confuse the router.

-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Friday, 22 May 1992 17:11:40 EDT
From:      Jerry Bryan <BRYAN@wvnvm.wvnet.edu>
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

In article <1375@cogsci.ucsd.EDU>, joe@crl.ucsd.edu (Joe) says:
>
>I am new to this, but:
>
>I was recently reading through the DARPA internet RFC's discussing
>the varied internet protocols (c.f., RFC 0791, 0793), and an obvious
>security problem occured to me. A hacker who knew what he was doing
>could write a dumb monitoring program to "eavesdrop" on live
>IP-encapsulated datagrams, filtering for certain specific IP-address
>to IP-address packets, and then monitoring the contents of those
>packets. If those packets turned out to be the login sequence of
>a telnet process, the monitor program could simply record the password
>phase. Ouch.
>
>Is this a major problem, or am I a dummy?
>
This is an old and well-known problem.  How serious it is depends on
the environment.  A standard solution (sort of) is to isolate people
on separate LAN segments using routers and/or bridges so that a snooper
could at most see the traffic on the local segment.  In some cases
this can mean multiple LAN segments in a single building because of
the diversity of users (payroll office vs. engineers, for example)
who might otherwise be on the same LAN segment.

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 13:49:11 GMT
From:      hardiman@csd4.csd.uwm.edu (Paul V Hardiman)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

In article <dank.706500496@blacks.jpl.nasa.gov> dank@blacks.jpl.nasa.gov (Dan Kegel) writes:
>joe@crl.ucsd.edu (Joe) writes:
>>A hacker who knew what he was doing
>>could write a dumb monitoring program to "eavesdrop" ...
>>If those packets turned out to be the login sequence of
>>a telnet process, the monitor program could simply record the password
>>phase. Ouch.
>>Is this a major problem, or am I a dummy?
>
>It's major.  A standard for encrypted telnet is on the way.
>Tell your Unix vendor you want it in their next release.
>- Dan K.


We consider this a major security exposure, especially with respect to
administrative databases on our IBM mainframe.  We've despaired of
getting encryption supported in our large very heterogeneous network.
Thus we're now looking at "smart card" security for all users who
want to access our administrative mainframe via TCP/IP.

Paul Hardiman
University of Wisconsin - Milwaukee
hardiman@csd4.csd.uwm.edu

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 14:31:17 GMT
From:      kbridge@magnus.acs.ohio-state.edu (Doug Karl)
To:        comp.protocols.tcp-ip
Subject:   Re: How to firewall a sub-net, or can routers do it?

Try an advanced protocol filtering bridge, cheap, efficient, and very flexible.
We use it in 40+ building to provide a ping'able and SNMP'able generic bridge.
We also use it to provide differing levels of security; Internet authentication,
IP subnet filtering, Server Name filtering, etc.

OSU KarlBridge can be found on: nisca.acs.ohio-state.edu.
	A commercial version is also availabile for $1195 with %15
	Educational discount, this includes hardware and software
	with support and warranty for 1 year.

FROM THE BROCHURE:

The OSU KarlBridge is a full featured protocol filtering bridge for Ethernet.
It has the most extensive filtering capability of any bridge or router
available.  It will filter packets by any Ethernet protocol or Ethernet
address and also IP Socket (incomming and/or outgoing), IP address, IP Subnet,
AppleTalk Server Name, AppleTalk Zone Name, DECnet Object and DECnet address.

Features:
	1) Ping'able with SNMP support for MIB-II, Ethernet-like Interface MIB,
	   and Bridge MIB.
	2) Can be configured to filter specific packets by protocol, address
	   server name and zone name by the use of easy to understand menus.
	3) Provides protection against erroneous Ethernet packets, that a
	   standard bridge does not provide.
	4) Leaks are greatly reduced compared to standard bridges, due to
	   unique filtering and timed-learning algorithms.
	5) Works on any Thin or Thick Ethernet with 10BASE-T optional.
	6) Very good packet forwarding rate; 8100 packets per second.
		(If you choose to use your own clone this may vary)
	7) Excellent packet forwarding delay; 140 uS (for small packets)
		(If you choose to use your own clone this may vary)
	8) Easily upgraded, since the code and filters are on standard PC
	   compatible bootable floppy.

Any questions....  Send e-mail to kbridge@osu.edu

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 14:46:22 GMT
From:      okorf@cs.tu-berlin.de (Oliver Korfmacher)
To:        comp.protocols.tcp-ip,de.comm.internet
Subject:   A services FAQ [TCP/IP]

A simple FAQ: were can I get the LATEST and completest list of
a) assigned protocol numbers (Internet Protocol)
b) assigned port numbers (tcp, udp, unix)

The list I am actually using is derived from the rfc1060 - is this
really the newest one? Has anybody some semi/in official add-ons?

Thanks, Oliver

	Oliver Korfmacher (okorf@netcs.com, whois OK11)

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 15:46:29 GMT
From:      bateman@hamel.epm.ornl.gov (Ken Bateman)
To:        comp.protocols.tcp-ip
Subject:   How common is RPC support?

I'm thinking about using RPC for a program I am working on.  I
would like the program to be able to run on as many different
kinds of machines as possible.  If I implemented the program with
RPC, would there be a lot of machines out there that couldn't run
it?

------------------------------------------------------
Ken Bateman                       bateman@msr.ornl.gov
"We are a hedge.  Please move along"  -anonymous ninja

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 15:51:58 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

In article <1375@cogsci.ucsd.EDU> joe@crl.ucsd.edu (Joe) writes:
   A hacker who knew what he was doing could write a dumb monitoring
   program to "eavesdrop" on live IP-encapsulated datagrams...

This is not a TCP/IP issue.  Any data on a broadcast network like
Ethernet, or passing through unsecured equipment (bridges, routers,
etc), are vulnerable.  You can eavesdrop DECnet, Ethertalk, XNS, or
anything else, so long as you have physical access to the medium that
carries the traffic.

If you're going to tar TCP/IP with a broad "security" brush, make sure
your brush is wide enough to include other protocol families, and
well-enough aimed to hit the cable but not the data on the cable.

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 15:56:22 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: split horizon algorithm: impact on multi-ip addresses on network port

In article <1992May21.160224.431@acc.com>, art@acc.com (Art Berggreen) writes:
|> In article <l1mpdpINNbil@skat.usc.edu> tli@skat.usc.edu (Tony Li) writes:
|> >    
|> >Again, cisco does things a little differently.  A cisco will assume
|> >that with two subnets of different major nets on the same wire, you
|> >want two sets of updates.  Each set of updates will contain the
|> >subnets for that particular major net.
|> >
|> >Tony
|> 
|> Hi Tony!
|> 
|> IMHO, the days of distinquishing between nets and subnets by looking at
|> the "class" of the network are fading and will eventually be completely
|> controlled by netmasks.
|> 
|> Art

That conclusion assumes that people one the net move to the latest and
greatest of technologies.  Instead they tend to follow the old creed,
"If it ain't broken, don't fix it."  RIP (which doesn't support subnet
masks) has been around for a long time and since it works in many
networks, it won't disappear soon.  My HO.

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 16:34:27 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Network diagnostic tool: what to buy?

In article <1992May21.183126.15005@nlm.nih.gov>, berman@nlm.nih.gov (Lew Berman) writes:
|> In article 1473@frcs.Alt.ZA, peter@frcs.Alt.ZA (Peter Greenwood) writes:
|> >
|> >We're looking for a tool that provides diagnostic capabilities that
|> >will enable us to maintain and troubleshoot our LAN (Ethernet running
|> >IP and IPX, 40 Novell file servers (2.15 & 3.11), 60 UNIX machines,
|> >about 2000 PCs).  Network General's "Sniffer Network Analyser" looks
|> >very promising.
|> >
|> >What's your experience?  What else is available that can do as good or
|> >better a job as Sniffer?
|> >
|> >Peter Greenwood
|> > 
|> >
|> >-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|> >Peter Greenwood
|> >peter@frcs.alt.za                  ...!uunet!{m2xenix,ddsw1}!frcs!peter
|> 
|> 
|> Are there any public domain tools similar to Sniffer?
|> 
|> Lew Berman
|> National Library of Medicine
|> Bethesda, MD

I have the following from previous requests.  I have tried the Beholder
collection and have been quite happy.

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

Delft University (Netherlands) is home to an incredible suite of
simple but effective network tools which could be used by good guys
or bad guys alike.  The menu driven front ends will scare anyone who
thought you had to be intelligent to use a packet grabber.

Contact JPMvOorschot@et.tudelft for details.  Jan may have some
other good ideas on the subject. 

Erick

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

For those who didn't figure it out already, that's "et.tudelft.nl".

	Leendert
--
Leendert van Doorn 			   		<leendert@cs.vu.nl>
Vrije Universiteit / Dept. of Math. & Comp. Sci.	+31 20 5484477
Amoeba project / De Boelelaan 1081A
1081 HV Amsterdam / The Netherlands

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

Yes, FTP Software has one which meets both the "cheap" and "good quality"
tests for a ethernet packet/traffic analyzer, which as you might have guessed,
runs on several DOS boxes. Even cheaper (free with your own labor at cost) is
Van Jacobson et alia's tcpdump, which runs on Sun boxes and Ultrix boxes, and
may run on other boxes. 

 
#include <std/disclaimer.h>
Eric Brunner 4bsd/RT Project
uucp: uunet!practic!brunner or brunner@practic.com
trying to understand multiprocessing is like having bees live inside your head.

----------------------------------------------------------------------------
I gave an address omitting the .nl country domain.
Thanks Leendert for supplying it. 

North Americans can get copies of the software from sunee.uwaterloo.ca
in pub/wattcp/delft.  The ca specifies Canada, so please schedule the
ftp's for nighttime when the lines are less conjested.

Erick

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


hi,

yes, your mail would bounce, see my signature for a correct email
address.
I will give a short list of the Software we are developing . You can
you them if you like , no guaranties. 

    Beholder   --   SNMP-able network monitor. Ethernet, PC-based.
    Gobbler    --   ethernetpacket grabber and analyser, PC-based.
    Spectre    --   ethernet host monitor, PC-based.
    Sage       --   Source code SNMP tool, C-source + sockets.


Get them using anonymous ftp from

    dutepp0.et.tudelft.nl

J

-- Ir. Jan van Oorschot.             --- Email: JPMvOorschot@et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
--
Jan van Oorschot



-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 16:37:22 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

The best security is physical security.  Can't read what you can't see.
-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      22 May 1992 16:39:10 GMT
From:      jstevens@crick.ssctr.bcm.tmc.edu (Jason Philip Stevens)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question


In article <1992May22.134911.1319@uwm.edu>, hardiman@csd4.csd.uwm.edu (Paul V Hardiman) writes:
|> In article <dank.706500496@blacks.jpl.nasa.gov> dank@blacks.jpl.nasa.gov (Dan Kegel) writes:
|> >joe@crl.ucsd.edu (Joe) writes:
|> >>A hacker who knew what he was doing
|> >>could write a dumb monitoring program to "eavesdrop" ...
|> >>If those packets turned out to be the login sequence of
|> >>a telnet process, the monitor program could simply record the password
|> >>phase. Ouch.
|> >>Is this a major problem, or am I a dummy?
|> >
|> >It's major.  A standard for encrypted telnet is on the way.
|> >Tell your Unix vendor you want it in their next release.
|> >- Dan K.
|> 
|> 
|> We consider this a major security exposure, especially with respect to
|> administrative databases on our IBM mainframe.  We've despaired of
|> getting encryption supported in our large very heterogeneous network.
|> Thus we're now looking at "smart card" security for all users who
|> want to access our administrative mainframe via TCP/IP.

Hmm.  I see your point if the hacker has physical access to the Net and can
plug in a Sniffer of some kind;  but I just read on alt.security that if a
cracker just has a stolen account on a UNIX machine that the network access
of that machine should be blocked to him (unless he's got root, in which case
network problems would be the _least_ of your worries) because of a privileged
system call.  Am I off base, or is this not true?

-jps

-- 
Jason Stevens			Internet:  jstevens@bcm.tmc.edu
Network User Services		Voice:  (713) 798-7370
Baylor College of Medicine	Opinions expressed are mine alone.


-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 16:44:25 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Civilizing rdump?  Cheap bridges?  How not to swamp an Ethernet

Try running the rdump with nice (see manual pages).  It slows it down
and lets you control how much.

HP makes a low cost, very reliable, two port local bridge.

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 18:21:31 GMT
From:      wls@cray.csd.uwm.edu (Bill Stapleton)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

In article <12007@gazette.bcm.tmc.edu>, jstevens@crick.ssctr.bcm.tmc.edu (Jason Philip Stevens) writes:

> Hmm.  I see your point if the hacker has physical access to the Net and can
> plug in a Sniffer of some kind;  but I just read on alt.security that if a
> cracker just has a stolen account on a UNIX machine that the network access
> of that machine should be blocked to him (unless he's got root, in which case
> network problems would be the _least_ of your worries) because of a privileged
> system call.  Am I off base, or is this not true?

True as far as it goes.  But here and at other schools, there are hundreds of
machines on the net, from PCs on up.  How hard is it to wander into a lab and
"become root" on a PC?  In addition, I think you have it a bit backwards, when
looked at in our environment:  Root usage on some department's back room lab
machine is not really a general concern (to us at least :-), whereas network
problems can be quite serious indeed.

--
Bill Stapleton
     wls@csd4.csd.uwm.edu
     uwmcsd4!wls

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 18:43:11 GMT
From:      a722756@pan.mc.ti.com (W. D. Rolph)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: split horizon algorithm: impact on multi-ip addresses on network port


I would like to thank all of you who followed up on my request for clarification
of my confusiuon, it helped alot.  In particular I would like to thank Tony Li
for his explicit comments about Ciscos.
 
For those of you who are interested benefit, heres the problem and our present
status to date.  I found it particularly enlightening in trying to decode the
Cisco's behavior:
 
    1)  Previous configuration - A microVAX II running UCX 1.3a with routing
            enabled supporting:
 
              a)128.247.125.23    going to the remote site through a vitalink
                     bridge

              b)192.31.38.85      locally to support the present class c address
                     space

              c)157.87.0.2        locally supporting the new class b space

                address space b and c are supported using DECs psuedo interface
                  which allows multiple ip addresses out a single tap
                observation of RIP packets shows split horizon is being
                   supported at the ip address space level (each address space is
                   managed independently as if it were independently attached to
                   the ethernet)
                broadcasts are made to either 157.87.255.255 or 192.31.38.255

     2)  First Cisco configuration:
 
             primary address 157.87.0.2, secondary 192.31.38.91

                 no RIP packets were sent out the 192.31.38.0 space
                 RIP packets in the 157.87.0.0 space were sent to ip address
                      255.255.255.255
                 The ucx software in a neighboring VAX lost contact with its
                      ethernet board every four hours requiring rebooting the VAX
                 OS/2 servers running Lanman over TCP/IP would freeze

     3)  Second Cisco configuration:
             157.87.0.2 on ethernet port 0
             192.31.38.85 on ethernet port 1
             Broadcasts set to 157.87.255.255 and 192.31.38.255

                  Catatonic collapse of the network
                  Arp tables completely munged (pcs would talk to the cisco
                    instead of the server they were attempting to access, 
                    although both were in the same ip space)
                  Cisco interface 0 would talk to Cisco interface 1 in seemingly
                    endless loops
                  No communications through the serial port was successful

     4)  Third Cisco configuration:
             same as above with ICMP redirects off and proxy-arp off

                  Collapse of Network

I am very confused at why the Cisco does not seem to be able to support two ip
address spaces cleanly while the VAX can.  In the interim, we are back to using
the MicroVAX II as our gateway and the Ciscos are making nice book ends,

I believe that what we will do is reconfigure the internal routing between the
class c and the class b space over a VAX and only let the Cisco support
communication out 157.87.0.2, but even here I am concerned that the Cisco will
perform some operation which is unexpected and which will collapse our network.

Thoughts, condolences or help would be most appreciated - in the interim, beware
of Ciscos bearing two ip spaces!!
-- 

Regards.
 
Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      22 May 92 19:17:22 GMT
From:      mcovingt@athena.cs.uga.edu (Michael A. Covington)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Human accountability; was: Re: tcp-ip security question

> don't be paranoid about security

Further to Robin Roberts' very worthwhile posting, I'd like to add that
the element of _human_ responsibility is often neglected at computer sites.

Being technologists, we easily get into the habit of thinking that the
machine should be able to keep itself secure by purely technological means.

The converse of this, often asserted by crackers, is: "The machine let me
do it so I didn't know it was wrong!"

One thing we are working on at Georgia is communicating to every user that
_people_ are responsible for what they do.  The machine will block many but
not all illegitimate actions.  For various good reasons there will always
be machines running with less than the maximum possible security measures.
This doesn't mean that people are welcome to crack them.

-- 
==========================================================================
Michael A. Covington, Ph.D. |  mcovingt@uga.cc.uga.edu  |  ham radio N4TMI
Artificial Intelligence Programs | U of Georgia | Athens, GA 30602  U.S.A.
==========================================================================

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 19:54:14 GMT
From:      jmcarli@srv.PacBell.COM (Jerry M. Carlin)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Re: tcp-ip security question

In article <1992May22.125355.5361@hellgate.utah.edu> rarobert@ursa4.cs.utah.edu (Robin Roberts) writes:
>2.  The DES encryption algorithm (and products that support it) are under
>U.S. export restrictions.  There may be some countries that we can export
>it to (NATO countries, or "friendlies" like the Brits and Canadians),
>but it is otherwise completely restricted.  Of course, the algorithm
>is published in the open literature...

Also of course, the best implementations of DES are available from
Europe/Australia and the like but the government does not care and
loves to play 'lets pretend' and "don't confuse us with the facts
since we don't care about what is really going on; we only care about
what we'd like to believe the world is really like".

-- 
Jerry M. Carlin	(510) 823-2441 jmcarli@srv.pacbell.com
Alchemical Engineer and Virtual Realist

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 May 1992 20:31:21 GMT
From:      rich@gtsi.com (Richard Lawrence)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

>packets. If those packets turned out to be the login sequence of
>a telnet process, the monitor program could simply record the password
>phase. Ouch.
>
>Is this a major problem, or am I a dummy?

You are not a dummy and it is a major problem. C2 requires that the password
be encrypted as passed to the host. NFS makes feeble attempts to do this
as well.
-- 
I'm too sexy for my .sig

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 May 1992 13:46:09 GMT
From:      schneck@Physik.TU-Muenchen.DE (Bernhard Schneck)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-Adresse from /dev/ttyp??

henry@zoo.toronto.edu (Henry Spencer) writes:

>I did one small hack here that can be helpful:  if the name won't fit, our
>login processing is intelligent about what portion to keep.  If the name
>ends in ".toronto.edu" or ".utoronto.ca", it's left-justified; if the
>name ends in something else, it's right-justified (so we see the more
>global parts of the name, which are typically more informative).

Wouldn't it be better to put the IP address (maybe dotted quad format so
dumb applications don't get confused) in the ut_host field and let the
programs sort out the host name, if they want it?

>-- 
>ISDN, n:  Incredibly Slow and Dumb      | Henry Spencer @ U of Toronto Zoology
>Networking                              |  henry@zoo.toronto.edu  utzoo!henry

But still better than analog lines ...

\Bernhard.
--
Bernhard Schneck        Internet: Bernhard.Schneck@Physik.TU-Muenchen.DE
TU Muenchen Physik
8046 Garching           "There is no problem so big that it cannot be
Germany                 run away from"                  Illusions, Richard Bach

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      24 May 92 11:08:14 GMT
From:      stefan@meki.toppoint.de (Stefan Mehne)
To:        comp.protocols.tcp-ip,comp.lang.c++
Subject:   Re: Sockets represented as Objects in C++?

zrhk0390@awssg6.rus.uni-stuttgart.de (Andreas Wierse) writes:
>Hi,
>a few weeks ago I read something about using C++ classes
>to represent the TCP-sockets as objects. I have no idea where I
>read about it (maybe some newsgroup or a printed publication),
>sorry, but it would be nice, if anybody else could remember and
>point me to it :-)

I think you read it in the german unix-magazin "UNIX-Magzin" from M&T !?


Ciao
	Stefan

-----------------------------------------------------------------------------
| Stefan Mehne                  | stefan@meki.toppoint.de (postmaster@tpki) |  
| Harriesstrasse 17, 2300 Kiel  | ...!uniol!tpki!meki!stefan                | 
|       *** A mind is like a parachute, it only works when open ***         |
-----------------------------------------------------------------------------

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 May 1992 14:52:51 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.lans
Subject:   IEEE802.5 packet checking questions

	I'm implementing IEEE802.5 frame format for a TCP/IP link layer
on a PC, and have a few curly questions. I'm hoping that people who don't
want to touch a PC might be able to help with the protocol questions, and those
that know about the PC drivers might be able to help me with the rest!

RFC 1042 requires that TCP/IP stacks on 802.5 token ring networks need to
understand and reply to 802.5 XID and TEST messages. From the 802.2 LLC
spec, I can't work out what order to check the incoming packet in.

Should I check to see if the packet is sent to DSAP=170 first, then check
for XID/TEST messages if the first check passes, or the reverse? Does anybody
know whether XID and TEST messages tend to be sent to global or NULL DSAP
addresses exclusively, or might they be sent to any SAP?

For the PC bits, the stack will be working initially over the token ring ODI
driver using the ODIPKT shim to give a packet driver interface. Does
anybody kow whether the ODI driver, or maybe IBM's LAN Support Package that
sits underneath it, handles the XID/TEST messages? - might I never see them
at all (esp. if they are not sent to DSAP 170)?

I'd appreciate any thoughts you might have. Email replies might be best -
I'll summarize to anyone who requests it, and post the summary if more than
4 people request it.

Thanks - 
-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 May 92 20:58:14 GMT
From:      arnej@Lise.Unit.NO (Arne Henrik Juul)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-Adresse from /dev/ttyp??

In article <schneck.706628769@Physik.TU-Muenchen.DE>,
schneck@Physik.TU-Muenchen.DE (Bernhard Schneck) writes:
 > henry@zoo.toronto.edu (Henry Spencer) writes:
 > 
 > >I did one small hack here that can be helpful:  if the name won't fit, our
 > >login processing is intelligent about what portion to keep.  If the name
 > >ends in ".toronto.edu" or ".utoronto.ca", it's left-justified; if the
 > >name ends in something else, it's right-justified (so we see the more
 > >global parts of the name, which are typically more informative).
 > 
 > Wouldn't it be better to put the IP address (maybe dotted quad format so
 > dumb applications don't get confused) in the ut_host field and let the
 > programs sort out the host name, if they want it?

I have a patched BSD telnetd that does exactly this, but since I'm
lazy, I use the dotted quad always. It is triggered by a WANT_NUM
#define, and is available via anonymous ftp:
   ugle.unit.no : /pub/unix/network/telnet-92a.tar.Z

I also made another, related patch: I check that it is possible to do
reverse-lookup in the DNS to find the name of the machine, and
disallow anyone who aren't properly registered. This has actually made
some departments of the university register their machines in the DNS,
only a couple of year late :-) I encourage everyone to run this
version.

It works eminently on our suns and decstations, and should be possible
to compile on other architectures too (at least I know unicos works).
Use and enjoy!

    Arne H. Juul, arnej@lise.unit.no
                  student & unix fundamentalist

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 May 1992 02:12:55 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions on ftp, ftp servers, kermit

mtayler@pilot.njin.net (Mark Tayler) writes:

>Help in the following topics would be appreciated.
>
>1)	Any good books describing TCP/IP for both user and programmer

	Doug Comer's Internetworking with TCP/IP VOL 1.
	    It's not a book of details, rather it tells you the
	    basics everyone else expects you to know.  Use it like
	    one of those 2-cassette packages to learn a foreign
	    language.   

	Andrew Tanenbaum's Computer Networks.  (Prentice Hall)
	    This is a great introduction to all types of networkingm,
	    including TCP/IP.  Unlike Comer's book, this compares
	    important details and differences between networks and
	    how/why to OSI.  My copy is almost 10 years old, and I'm
	    about ready to buy a new revision, Andy's just that good.

	Both Andy and Doug's books give you the knowledge you need
	to tackle installation manuals, conversations, magazines, and
	RFC's.  If you don't know what an RFC is, you haven't read these
	books!

	Richard Steven's Unix Network Programming (Prentice Hall)
	    It is a good hands-on introduction, a must for your
	    programmers.  You should first understand the stuff
	    in either Comer or Tanenbaum.

>3)	Any good books on Kermit for both users and programmers.

	Cristine M Gianone's Kermit book (Prentice-Hall)
	    is the authoritative reference.  She gives an excellent
	    description of things you never dreamt Kermit could
	    do, and her style is unusually easy to read.  Being
	    listed in the acknowledgements does not influence my
	    opion of this book :-)


>4)	Where can I find the latest version of kermit .

	watsun.cc.columbia.edu

Erick
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      25 May 92 02:48:31 GMT
From:      larose@cs.utk.edu (Brian LaRose)
To:        comp.protocols.tcp-ip
Subject:   4.3 network software upgrade trouble..


   I am trying to install the 4.3-tahoe patches on my IBM RT which runs
   slip on 4.3 AOS.  After installing the /usr/sys/netinet/in.h and trying
   to recompile my kernal, the file /usr/sys/krpc/klm_lockmgr.c 
   gives the following error:

   INADDR_LOOPBACK: Identifier is undeclared.

   So, it appears the file /usr/sys/netinet/in.h excludes a definition that
   earlier versions included.   Could it be that I need to upgrade my
   rpc package?  or could it be that I've err'ed in the installation?

   HELP!

   thanks in advance!!!
   brian


-- 
    -------------------------------------
    | Brian LaRose |  974-3647          |
    | Ayres 217    |  larose@cs.utk.edu |
    -------------------------------------
    

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      25 May 92 03:48:55 GMT
From:      rafee@rangkom.MY (M Rafee Yusoff)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Multiprotocol Routers

Hi,

I am considering purchasing multiprotocol routers.  I already have
a few X.25 switches (OST).  Any comments or, better yet,  a competitive 
analysis of the different products would be appreciated.  Even the features
that I should consider would be a great help - I don't have much exposure
in this range of products/technology.

Please e-mail reponse to me directly, cuz I get news late (2-3 weeks via
tape).  My e-mail address is uunet!mimos.ism.MY!rafee.

Thanks

Rafee Yusoff
Malaysian Institute of Microelectronic Systems
MIMOS

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      25 May 92 10:08:42 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   pd sniffers

Recently, James B. VanBokkelen (jbrb@ftp.com) replied to Lew Berman
(berman@nlm.nih.gov) regarding commercial and PD sniffers.

James mentions that Netwatch is from MIT and doesn't do packet
generation.

I may be mistaken (won't be the first time), but isn't Netwatch
originally from the University of Delft, Netherlands, and hasn't it been
superceded by The Beholder?

At any rate, it might be worth mentioning that we recently had a strange
problem on our network which the drivers for our Racal-Interlan NI6510's
couldn't handle worth a darn (until recently).

We had PC's running IPX which would spontaneously slow down, so much so
that doing a DIR on a network drive would display one filename every few
seconds or so.  Only a reboot would clear this problem.

Users running ODI to support IPX and TCP/IP would spontaneously lock up,
bad enough to require a cold boot.  A chat with RI back in January
revealed that this problem was recently (read:  within 2 weeks prior)
reproduced in their lab (for ODI) and a patch was available.  I
downloaded this patch pronto and made my users very happy.

Unfortunately, the IPX user group was coordinating hoop-jumping with RI.
 I believe they've had at least one patch (as a result of a high-level
meeting between our company and theirs), and, I believe, at least one
update since.

Now, this only addresses the symptoms and not the cause, but at least we
were able to get somewhere.  We had Novell's LANalyzer and found that,
aothough it could detect the fact that we had illegal length packets (4K
and greater - believe largest was 6K) running around our Ethernet, the
largest packet that the LANalyzer could generate was 2K.  In fact, after
calling around to verious sniffer vendors, none could generate packets
greater than 2K.

Enter the Clarkson packet drivers and a utility, PKTSEND.  A simple,
no-brainer utility like this confirmed our suspicions on a small test
LAN.

This made me feel pretty good, as once I had the patch for the ODI
driver, not only could it handle a single illegal-length packet, but
pounding it with 100 such packets at the touch of a key without even a
hiccup was rather reassuring, while the IPX-only users basically went to
sleep when only one such packet came down the wire.

This made our group feel especially good, as various companies, not the
least of which was the vendor, kept pointing fingers everywhere else
(e.g., wrong firmware version on NIC, several times over; must be the
TCP/IP and UNIX (even though the IPX users were already running Enet
II)).

I again felt extra relief, as it a) had nothing to do with TCP/IP, and
b) appears that the odd PC NI6510 is dumping packets containing a chunk
of DOS RAM onto the LAN.  Fun, wow.

Sorry for rambling, but my points are this:  1. Trust your instincts,
even if you are being told otherwise;  2. A tool can still be
simple to be effective (or, you don't need a bulldozer for a little
dirt).

Jim Carroll (william.mercer@canrem.uucp)
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      25 May 92 07:24:15 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-Adresse from /dev/ttyp??

In article <vcn8sINNp2t@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992May19.064837.1327@medtron.medtronic.com> rh0083b@medtronic.COM (Roger Hunen) writes:
>>On SunOS the 'who' command shows the name or address of the host you came
>>from. Isn't it possible then to use this information? I don't know what
>>other UNIX flavors offer, so my hack may be Sun specific.
>
>That information comes from /etc/utmp, which (in SunOS) only has 16 bytes
>for the hostname field.  That's frequently insufficient to hold an entire
>domain name, although many people are in fact using scripts that run who(1)
>to get this information.  If all the places they login from have short
>enough names, it should work.

Right. I just ran into the 16-byte limit the hard way. Also, not all UNIXes
provide the host info in the who output. This still leaves us with the
where-did-I-come-from problem :-(.

Regards,
-Roger
(I speak for my own)

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      25 May 92 14:36:46 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.protocols.tcp-ip
Subject:   NDIS


Hi guys!
I would like to know what ndis means! If it is a protokoll
stack I would like to have a specifikation! Over all any 
information which explains the word NDIS exactly is appreciated!

-- 
------ < MAGIC > ------

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      25 May 92 15:15:27 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Netwatch (was pd sniffers)

william.mercer@canrem.com (william mercer) writes:
>I may be mistaken (won't be the first time), but isn't Netwatch
>originally from the University of Delft, Netherlands, and hasn't it been
>superceded by The Beholder?

NetWatch is a program I wrote at MIT in the early 80's as part of PC/IP. It
was the first network sniffer/analyzer program for the IBM PC. It's
exactly what James described.

-- 
		- john romkey			ELF Communications
USENET/UUCP/Internet:  romkey@ELF.com

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      26 May 92 05:57:46 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: Look for CMU TCP/IP and SLIP for VAX/VMS

In article <6889@shodha.enet.dec.com> fontsda@handve.enet.dec.com (Daniel Au Yeung) writes:
>
>I am looking for a pointer to the FTP sites that have the CMU TCP/IP and SLIP for VAX/VMS.

The correct name of the product is "CMU/Tek-IP", and the current version is
V6.6-5 for all VMS 5.* systems.

Note the "Tek" in the name; that is because (from the manual):

``	Since the software was originally developed by Tektronix, a license
	agreement is still necessary before we can distribute it.  As a
	result of that, we have to regulate the software and that being so,
	we must ship the software to individual sites instead of making it
	available via FTP.  There is a small fee in the neighborhood of $150.
	This covers our expenses which include mag tapes, TK50s, printing
	costs, shipping, phone bills, and the time it takes to arrange the
	licenses.  For this price you receive a tape containing the CMU/Tek
	software "suite" and a hardcopy of the manual.
''

Appended to this article are two of the items I found in comp.os.vms from
which I ordered this package.  Given that I've received > 20 emails during
the past 24 hours asking about this, it's apparent there IS a lot of interest
in the CMU/Tek solution, hence this posting.

BTW, the product works VERY nicely and has solved a major problem for my
site; the CMU/Tek-IP package brings VMS (finally) into compliance with the
real world (TCP/IP).  Among the system that can FINALLY talk to our VAXen
are included Suns, SGIs, HP-UXs, Amigas, Macs with A/UX, PCs running the
Wollongong TCP/IP, etc etc etc

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-------------------- begin enclosures

[ BTW, Glenn is the DECUS program librarian ]

From: EVERHART@ARISIA.dnet.ge.com
Newsgroups: comp.os.vms
Subject: Re: VAx - pc file transfer
Message-ID: <9202101459.AA20274@aitgw.ge.com>
Date: 10 Feb 92 15:07:54 GMT

For a site needing inexpensive file transfer between vax and PC over
Ethernet at high speeds, I would suggest the following:
1. CMU TCP/IP for the VAX, which gives Telnet and FTP support among
	other things and is quite robust. Costs $150 to order,
	approximately; send mail to Ms. Karen Heilman,
	R635KH55@vb.cc.cmu.edu, 412-268-5896, Carnegie
	Mellon University, UCC Bldg Rm 124,
	4910 Forbes Ave., Pitsburgh, PA 15213-3890 USA
(there's a license and it is not freely distributable, but it is very
inexpensive and good stuff).
2. NCSA Telnet for the PC, free from zaphod.ncsa.uiuc.edu and other
	FTP sites (or on recent DECUS L&T SIG tapes). 

These between them give high speed file moving AND high speed multiple
terminal connections and are at prices most sites can well afford. I have
not heard of any free DECnets for PC. These are rumored to exist for Mac,
but have not so far as I know been transferred.

	Another avenue might be using a floppy on the vax and the PCX
software to read/write MSDOS materials from VMS, but I suspect Herr Drobnitzky
will prefer to avoid buying new hardware for a VAX 750.

Glenn Everhart
Everhart@Arisia.dnet.ge.com

 ps - if you are not up to VMS 5.4, you will want to ensure you order a
version of CMU TCP/Ip that will work on whatever VMS version you have.
Such things exist which support VMS V4 and on, though the VMS V4 suppoorting
releases were considerably more complex to install. The VMS V5 version is
VMSinstallable and goes in very simply.

-------------------- second enclosure

[NOTE: I don't understand what Bob means by "... don't need a completely
reliable package ..." since it appears to work fine per his own admission!  ]

Newsgroups: comp.os.vms
Subject: Re: cmu/tek?
Message-ID: <1992Apr11.034443.9953@iscnvx.lmsc.lockheed.com>
Date: 11 Apr 92 03:44:43 GMT
References: <1992Apr9.173608.3505@titan.uucp>
Sender: news@iscnvx.lmsc.lockheed.com (News)
Reply-To: marshall@force.ssd.lmsc.lockheed.com
Distribution: usa
Organization: LMSC, Sunnyvale, California
Lines: 235

In article <1992Apr9.173608.3505@titan.uucp>, rrebello@titan.uucp (Rod Rebello
-- CAD Development) writes:
>I've read postings that mention a tcp package called cmu/tek.  Is this
>a commercial or freeware package?  Where could I get a copy or more
>information about it?

It's nearly free; it costs $125, and is well worth it if you don't need
a completely reliable TCP/IP package. We use CMU/TEK at our site for our
basic TCP/IP needs (i.e., FTP and TELNET, plus a few other things like
SMTP, NNTP, LPR, and LPD). Here is a flyer that came with our copy of
version 6.5 of the software. The current version is 6.6-5, but the 
information below is still applicable :

==============================================================================
CMU/Tek-IP 6.5 Package Information Flyer (PIF) -- Currently under construction
==============================================================================

OVERVIEW:
==============================================================================
CMU/Tek-IP is  an implementation  of the  TCP/IP protocol  stack for VAX/VMS
systems.  It is not blazingly fast.  It is not terribly efficient.  What it
is is affordable and very nearly public domain.  For $125 dollars you can
get a  site license,  a mag-tape,  and user  manual.   The distribution tape
includes,  in  addition  to  the binaries  and everything  else, all sources
required to rebuild the complete package.  Sites running the software are
encouraged to develop the software and send any improvements back to CMU
where they will be incorporated into the next release.

CMU stands for Carnegie-Mellon University, by the way.

ORGANIZATION:
==============================================================================
CMU/Tek-IP runs as an ACP.  The TCP process handles input from the networks
and services user requests through the IP: device.  Because the TCP/IP is
implemented as a detatched user process it can not achieve the same
performance as other, in-kernel TCPs can, due to process context switching
overhead.  On the other hand, a TCP running in a detatched process is
easier to debug and makes code development a snap.   Typical FTP speed on
a loaded EtherNet bewteen two 3100s is not unreasonable:

%FTP-I-DATA_RATE, Transfered 8748794 bytes in 00:06:45.18 = 21592 bytes/Second

CONFIGURATIONS SUPPORTED:
==============================================================================
CMU/Tek-IP 6.5 will run on any VAX system with VMS 5.0 or greater.  No
network devices are required although the use of at least one is advocated.

USER APPLICATIONS:
==============================================================================
Finger:
-------
The finger service provides information about users on remote systems, such
as when they last logged in and whether they have any new mail.  Finger
comes in both client and server forms.

FTP:
----
CMU/Tek includes an implementation of the File Transfer Protocol as
specified in RFC #959.  Both client and server programs are provided.
With FTP, the VMS system may exchange files with any other host on the same
internet (TCP/IP network).  FTP currently supports ASCII and BINARY, as
well as PAGE structured file transfers.

The FTP client uses the SMG$ terminal interface to provide command line
editing and recall.  The input is parsed by the DCL parser so that using
FTP is similar to using any other VMS utility.  In the 6.5 release, the FTP
client no longer has difficulty processing lowercase and slashes in
filenames when parsing command lines.

IPNCP:
------
The IP Network Control Program is a generaly purpose program which includes
commands to start-up and shutdown parts of the network, resolver domain
names into addresses or other resource records, turn network logging on and
off, display newtwork connections and statistics, kill connections, etc...
Also included are PING, RDATE and other miscellaneous utility commands.
TraceRoute and NTP are being added currently.

LPR:
----
This is the CMU/Tek implementation of the Unix remote printer software.
It allows the VMS host to both print remotely and print files locally for a
remote host.  Two additional commands have been added since version 6.4:
LPRM (remove remote job) and LPQ (display remote queue).

Mailer:
-------
Message Exchange (MX) is electronic mail distribution software for VAX systems
running VMS V5.0 or later.  MX interfaces with VMS MAIL for sending and
receiving messages on the local system, with CMU-Tek TCP/IP or DEC
VMS/ULTRIX Connection for Internet mail delivery, and with Jnet for
BITNET mail delivery.  It also provisionally supports DECUS UUCP.
In addition to mail routing and delivery, MX also includes support for
handling mailing lists and a server for distributing files via E-mail.

Talk:
-----
Talk is an interactive two-party, two-person comunications program
Talk is not included on the distribution tape but is available via
anonymous FTP from DRYCAS.CLUB.CC.CMU.EDU (128.2.232.11).

Telnet:
-------
This is the remote login service specified by RFC #854.  Both a client and
server are provided.  Another Telnet server has been implemented within the
ACP itself to provide more efficient Telnet communication.  The following
Telnet options have been implemented:  Terminal_Type, Terminal_Speed,
Toggle_Flow_Control, Location_Number, Window_Size.  The line_mode option is
currently in the works.


SERVICES:
==============================================================================

Internet Protocols:
-------------------
CMU/Tek provides client access to TCP,UDP,ICMP and raw IP services through
the IP: device.  Applications may communicate with the IP device through
the standard VMS QIO interface.

DECWindows Transport:
---------------------
VMS systems running the DECWindows software can use this transport to
redirect graphics over the TCP/IP network.  For instance, a large VAX
running a simulation could send it's graphic output across the network to a
small workstation with a graphics monitor.  You can also use the transport
on a CMU/Tek system to display graphics which it receives from some other
machine on the network.

Socket Emulation Library:
-------------------------
This is an experimental Unix-like interface to the IP: driver.  It is a
shared run-time library which will hopefully, in conjunction with the VAX-C
RTL, allow unix C programs to be compiled, linked and executed on your VMS
system.

Domain Name Resolver:
---------------------
This is a demon that runs as a detatched process and resolves domain names
into IP addresses and other type of information for the local host.  It
works by accepting domain names from a mailbox and then sending out Name
Queries to Domain Name Servers in an attempt to resolve them.  The
resulting answers are returned to the requester and then cached for later
retrieval.  The IPACP makes extensivee use of the Name Resolver.

Domain Name Server:
-------------------
This server allows the the VAX to act as a Domain Name Server and resolve
domain names within it's zome of authority

SNMP:
-----
The Simple Network Management Protocol provide a method to remotely monitor
network entities.  SNMP support has been added in 6.5, although no client
applications have been written, as of yet.  Most of the standard objects
were included in the 6.5 SNMP code, except for routing info and the ARP
cache.

IP Transports:
==============================================================================
CMU/Tek-IP can provide TCP/IP communication over several differant mediums.
IP transports are implemented as run-time loadable shared images so that
sites can design and use their own IP transports.  The transport interface
is specified in the 6.5 manual.

EtherNet:
---------
The XEDRV.EXE transport allows CMU/Tek-IP to send and receive data over any
EtherNet driver which uses the Digital EtherNet QIO interface.  This
includes, of course, all Digital EtherNet cards.  TCP/IP happily co-exists
on your EtherNet card with both DECNet and LAT.

DECNet:
-------
The DNDRV.EXE transport will encapsulate IP datagrams inside of DECNet
packets.  In this manner you may create a TCP link between two machines
connected by a DECNet link (which may in turn be running over an
Ethernet or a serial line or what-have-you).

SLIP:
-----
IP transport over a Serial Line.

X.25:
-----
This transport, X25DRV.EXE, which is currntly being worked on, will talk IP
over an X.25 link

DOCUMENTATION:
==============================================================================
Documentation come in the form of a single white, glue-bound manual which
includes chapters on Installation, System Management, Organization,
Programming, IPNCP, FTP, Telnet, Finger, LPR, Error Messages, Transport
Design and various other sundry items.

SUPPORT:
==============================================================================
Officially there is no support for the package.  Unofficially there is alot
of support.  The package maintainer, Bruce Miller, is available to answer
any or all questions, accept bug fixes and new code, debug problems, and
generally explain things.  You can reach him at 4910 Forbes Ave, Pittsbugh
PA  15213;  phone (412) 268-7560.  Your chances of reaching him are best if
you call between noon and midnight, Pittsbugh time.  There is also an e-mail
list which you can join which will provide you with both a discussion forum
and a source of up-to-date news.  To join the list, send mail to
cmu-tek-tcp-reqest@andrew.cmu.edu with the mail address you want added to
the list.  Now all list mail will be forwarded to you.  To post to the
list, send your message to cmu-tek-tcp@andrew.cmu.edu.

ORDERING INFORMATION:
==============================================================================
To order CMU/Tek-IP 6.5, contact Karen Heilman (read: Car-in Hile-Man):
Karen Heilman, UCC-124, 4910 Forbes Ave., Pittsburgh,  PA 15213.
Phone: (412) 268-5896

The package is available on both 1600 bpi magtape and TK50s

Bear in mind that your tape will be sent only when we have a signed
site license and either a check or P.O. in hand.  A new agreement is
required for each release.  We ship by UPS ground.  Shipping is in-
cluded in the price.

$125 for the site license, tape, shipping and manual.
 add $25 if you want it on TK50
 add $25 for P.O.
 add $50 for outside U.S.

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

=============================================================================
Bob Marshall                     \\     
Lockheed Missiles & Space Co.     \\       "In my occupation
Sunnyvale, CA                      \\       There ain't no vacation
marshall@force.ssd.lmsc.lockheed.com\\      I'm a professional fool"
"I tell the truth 'cept when I lie"  \\
=============================================================================

-------------------- end enclosures

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      25 May 92 11:11:58 +1200
From:      hamish@waikato.ac.nz
To:        comp.protocols.tcp-ip
Subject:   rexec using read/write problems.


I have a problem with rexec, and getting a connection using sockets between a
sparc 1 running SunOS 4.1.1, and a Netware 3.11 server using the NLM compiler.
Basically, using sockets I can open a connection to the rexec port, and send
the rexecd the command string, but it never answers. (The connection is from
the NW --> Sparc).

Eventually the read (waiting for the rexec response) times out and gives an EOF
indication. Using etherfind there is a packet sent and recieved to create the
connection (From calling connect), and 1 send for calling write to send the
rexec command buffer, but then the connectoin sits and spins. Any forther
writes get a reset connectino packet from the sparc. 

Now the man pages say to send an encrypted password in the command buffer. Is
this necessary? I have some code that works on a PC (From wattcp), that uses
plain text passwords. Sometimes that works, and sometimes it too times out. 

Can anyone help?

TIA

-- 
==============================================================================
|  Hamish Marson   <h.marson@waikato.ac.nz>                                  |
|  Programmer (n/5), School of Computing and Mathematical Sciences           | 
|  University of Waikato,                                                    |
|  Hamilton, New Zealand.                                                    |
|Disclaimer:  Anything said in this message is the personal opinion of the   |
|             finger hitting the keyboard & doesn't represent my employers   |
|             opinion in any way. (ie we probably don't agree)               |
==============================================================================
  Q. If Nuclear Tests are so safe, why don't the French do them under Paris?

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      25 May 92 11:26:13 +1200
From:      hamish@waikato.ac.nz
To:        comp.protocols.tcp-ip
Subject:   Re: rexec using read/write problems.

In article <1992May25.111158.8248@waikato.ac.nz>, hamish@waikato.ac.nz writes:
> 
> I have a problem with rexec, and getting a connection using sockets between a

Sorry. Ignore this waste of bandwidth. I suddenly realised what I did wrong. In
re-writing the rexec code I used strlen to get the length of the command
buffer. Stupid really. It returned 0 every time :)


-- 
==============================================================================
|  Hamish Marson   <h.marson@waikato.ac.nz>                                  |
|  Programmer (n/5), School of Computing and Mathematical Sciences           | 
|  University of Waikato,                                                    |
|  Hamilton, New Zealand.                                                    |
|Disclaimer:  Anything said in this message is the personal opinion of the   |
|             finger hitting the keyboard & doesn't represent my employers   |
|             opinion in any way. (ie we probably don't agree)               |
==============================================================================
  Q. If Nuclear Tests are so safe, why don't the French do them under Paris?

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      26 May 92 12:06:49 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

In article <dank.706500496@blacks.jpl.nasa.gov> dank@blacks.jpl.nasa.gov (Dan Kegel) writes:

    joe@crl.ucsd.edu (Joe) writes:
    >A hacker who knew what he was doing
    >could write a dumb monitoring program to "eavesdrop" ...

One can also buy a commercial LAN monitor, or FTP freeware from the Internet.

    >Is this a major problem, or am I a dummy?
    
    It's major.  A standard for encrypted telnet is on the way.
    Tell your Unix vendor you want it in their next release.

This is not just a TCP/IP issue; you've got the same problem with any other
protocol that sends unencrypted data over a broadcast LAN (e.g. Netware,
LAN Manager, OSI, XNS...).

The problem with encrypted Telnet is that it is likely to fall afoul
of the same U.S. Government restrictions that have hindered vendors
from shipping Kerberos.  As I understand it, the Gov't. will require
an export license for any product that can DES encrypt the
datastream.  With the recent change in focus from "evil == geography" to
"evil == useage", this means a US version and an everywhere else version
(expensive).

Anyone in a position to comment on how the "you can't export dynamic
routing" vs. "Unix *needs* routed" battle came out?  Is it even settled?

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

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 May 92 14:38:04 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   pd sniffers

In article <199225.1070.8388@dosgate> william writes:

   James mentions that Netwatch is from MIT and doesn't do packet
   generation.

   I may be mistaken (won't be the first time), but isn't Netwatch
   originally from the University of Delft, Netherlands, and hasn't it been
   superceded by The Beholder?

MIT did netwatch, Delft does netmon and netcapt.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 May 1992 17:54:32 GMT
From:      mitton@dave.enet.dec.com (Dave Mitton)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.lans
Subject:   Re: IEEE802.5 packet checking questions


In article <1992May24.145251.12517@atlas.abccomp.oz.au>, paul@atlas.abccomp.oz.au (Paul Brooks) writes:
>From: paul@atlas.abccomp.oz.au (Paul Brooks)
>Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.lans
>Subject: IEEE802.5 packet checking questions
>Date: 24 May 92 14:52:51 GMT
>
>
>	I'm implementing IEEE802.5 frame format for a TCP/IP link layer
>on a PC, and have a few curly questions. I'm hoping that people who don't
>want to touch a PC might be able to help with the protocol questions, and those
>that know about the PC drivers might be able to help me with the rest!

	Your questions are really about 802.2 frame formats, which is 
not necessarily (except in your responsibility) 802.5 Token Ring specific.

>RFC 1042 requires that TCP/IP stacks on 802.5 token ring networks need to
>understand and reply to 802.5 XID and TEST messages. From the 802.2 LLC
>spec, I can't work out what order to check the incoming packet in.
>
>Should I check to see if the packet is sent to DSAP=170 first, then check
>for XID/TEST messages if the first check passes, or the reverse? Does anybody
>know whether XID and TEST messages tend to be sent to global or NULL DSAP
>addresses exclusively, or might they be sent to any SAP?

	Per the 802.2 spec, XID and TEST messages may be sent to any DSAP.
The NULL SAP is typically used to communicate with the node without
requiring an active DSAP.	

>For the PC bits, the stack will be working initially over the token ring ODI
>driver using the ODIPKT shim to give a packet driver interface. Does
>anybody kow whether the ODI driver, or maybe IBM's LAN Support Package that
>sits underneath it, handles the XID/TEST messages? - might I never see them
>at all (esp. if they are not sent to DSAP 170)?

.. now this is Token Ring specific...
	In my experience; all IBM TR cards, and any TI TMS380 cards that
have the LLC microcode active, will respond to XID and TEST to the Null SAP.

I'm not sure what happens if you send to a specific DSAP or the Global SAP....
I would hope that the user of the SAP receives the packet, though the microcode
may attempt to handle it itself.  It's awfull hard to get good documentation
on exactly what does get done with these.

	Dave Mitton.
	Token Ring Program
	Digital Equipment Corp.


-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      26 May 92 18:53:36 GMT
From:      scottp@npg-sd.SanDiegoCA.NCR.COM (Scott Platenberg)
To:        comp.protocols.tcp-ip
Subject:   nic comparison request


  Does anyone have some literature comparing available network adaptors?
It doesn't have to be limited to a specific bus architecture, though I
have a keen interest in MCA cards.  I've heard of reference to the LANCE
chip set and I would like to know more so if you can help me out I
would appreciate it.  Thanks for the pointers.
Scott
--
Scott Platenberg                            NCR, NPG-San Diego
scottp@npg-sd.SanDiegoCA.NCR.com   The Networked Computing Resource of AT&T
                                     9900 Old Grove Road, San Diego, CA

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      26 May 92 22:25:44 GMT
From:      cohen@brodmann.iaf.uiowa.edu (Gregg A. Cohen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs
Subject:   help with error codes of PC-NFS

Can one of you who has sucessfully installed PC NFS or had troubles and
gotten them resolved tell me what the following error messages mean (they
are not listed in the reference manuals)

PRO0025E Failed to bind
(Right after the MS DOS LAN Manager Netbind v1.1 entry)

NFS908F Configuration error - LANMAN Netbind must be run before NET INIT
{PC-NFS is installed]
NFS000F : PC-NFS is disabled. (Can't start network: check configuration)
(... needless to say, this one IS in the manual, and yes, this is a legal
install)

I also notice that if I try to run nfsconf, I don't get any of my configuration
parameters showing up in the "N" option.  If I reboot the PC without the
NFS stuff in the config and autoexec, I can see the parameters just fine
in the nfsconf output.

FYI
Clone 386/25 MHz
WD-FASST 7000 SCSI controller
Cardinal VGA732A video controller
MicroSoft Bus mouse
HP EtherTwist 16 Twisted Pair Ethernet card
ODS Twisted Pair hub/controller

Thanks for the help


--
Gregg Cohen			/\/\		cohen@brodmann.iaf.uiowa.edu
Department of Psychiatry  	\/\/		(319)353-6358  if you be lucky
University of Iowa		/\/\		Mental health is more than a 
Iowa City, IA 52242		\/\/		state of mind!!

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      27 May 92 00:00:18 GMT
From:      jwang@white.toronto.edu (Jingwen Wang)
To:        comp.protocols.tcp-ip
Subject:   Reliable UDP code wanted


   I am looking at implementing a communication library using UDP in order
to have the better response time than stream sockets. Has anyone already
done something on this? 

   Any pointers are appreciated.


-- 
  {}
{}(){} -----> Jingwen Wang, Univ. of Toronto       (416)-978-1675 (office)
  {}          jwang@snow.white.toronto.edu         1-800-ASK-wang (home)

--
  {}
{}(){} -----> Jingwen Wang, Univ. of Toronto       (416)-978-1675 (office)
  {}          jwang@snow.white.toronto.edu         1-800-ASK-wang (home)


-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 May 1992 04:41:14 GMT
From:      nigelc@cognos.com (Nigel Campbell)
To:        comp.protocols.tcp-ip
Subject:   troubleshooting idiot guide

Does anyone have an idiots guide for solving problems
for TCP/IP (target boxes SunSparc,Rs/6000,Aviion,HPUX and
MPEix,SCO or Ultrix). For VAX/VMS TGV Multinet or 
Wollongong are the main vendors of interest, thanks.



-- 
Nigel Campbell          Voice: (613) 738-1338 ext 3016    P.O. Box 9707
Cognos Incorporated       FAX: (613) 738-0002             3755 Riverside Dr.
Database and Connectivity MCI: nigel campbell || 307-4729 Ottawa, Ontario
UUnet: nigelc@cognos.COM                                  CANADA  K1G 3Z4

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      27 May 92 06:21:45 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip,de.comm.internet
Subject:   Re: A services FAQ [TCP/IP]

In article <1992May22.144622.9339@cs.tu-berlin.de> okorf@cs.tu-berlin.de (Oliver Korfmacher) writes:
>A simple FAQ: were can I get the LATEST and completest list of
>a) assigned protocol numbers (Internet Protocol)
>b) assigned port numbers (tcp, udp, unix)
>
>The list I am actually using is derived from the rfc1060 - is this
>really the newest one? Has anybody some semi/in official add-ons?

As far as I know RFC 1060 is the latest official list.

Regards,
-Roger
(I speak for myself)

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      27 May 92 07:59:13 GMT
From:      albr@castle.ed.ac.uk (Alasdair Bruce)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Interfacing to TCP/IP

Hi,

	I am involved in developing a distributed message passing
system on   a  network of   UNIX  workstations.   The  underlying
protocol I intend  using is TCP/IP.    The  aim is to  port  this
system across as many platforms  as possible (UNIX or otherwise).
I therefore  would like to  know a little more  about  what's out
there  and what is  likely to stay  out there as regards standard
interfaces to TCP/IP.

	Personally, I am comfortable  using the socket  interface
of BSD, however,  rumour has it that  Sys V is leading the `race'
and becoming ever more popular in  its use than BSD variants (cf.
SunOS 5).  This presumably means that use  of TLI as an means  of
running the TCP/IP protocol  will become  more common.  Does this
imply that the socket interface will fall by the way-side, become
less  well supported, become   less  efficient than the  services
provided by TLI, ... ?

	If anyone out there  has a list  (however small) of which
platforms support which interfaces to TCP/IP I would like to hear
from you. For example, I have immediate access to the following:

System						Sockets    TLI
------                                          -------    ---

Sun SPARCs (SLC/ELC/SS2) running SunOS 4.1          yes    yes
Sequent Symmetry running DYNIX V3.1.4               yes     no
Silicon Graphics running IRIX System V.3            yes     no

	Here we appear  to have two  System  V(ish)  Unices which
interface to TCP/IP only through a BSD  communications interface.
I will summarise any results I receive of course. Many thanks for 
your time. 

	-Alasdair-

				Alasdair Bruce: albr@epcc.ed.ac.uk
						(+44 31 650 5021)

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 May 1992 11:41:47 GMT
From:      ga@herts.eve.rdg.dec.com (Giles Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: NDIS

NDIS is the "Microsoft/3COM LAN Manager Network Driver Interface Specification"
If defines a function call interface to a network device driver in a PC.
Markus, if you can send me mail at ga@rdg.dec.com, I can mail you a copy of the
spec.

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 May 1992 18:08:10
From:      ljm@vax.ftp.com  (leo j mclaughlin iii)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP is not proprietary

In article <1992May15.160746.16198@tridom.com> mwr@tridom.uucp (Mark Reardon) writes:

>Aren't Mil. Specs. proprietary ;-)?

..on the other hand, they don't describe TCP/IP... ;-).

enjoy,
leo j mclaughlin iii
ljm@ftp.com


-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      27 May 92 14:32:13 GMT
From:      apple@drvax3.msfc.nasa.gov (Kathleen Applegate)
To:        comp.protocols.tcp-ip
Subject:   Re: NDIS

ga@herts.eve.rdg.dec.com (Giles Atkinson) writes:

>NDIS is the "Microsoft/3COM LAN Manager Network Driver Interface Specification"
>If defines a function call interface to a network device driver in a PC.
>Markus, if you can send me mail at ga@rdg.dec.com, I can mail you a copy of the
>spec.

3COM published a great article in "3TECH", Winter 1991 called
"NDIS Concepts".  For a text file copy, FTP it from
gatekeeper.3com.com:

     /adapters/drivers/ndisconc.zip

You might also want to get ndi201.zip from the same source.
This is a technical description of what you need to know to 
write an NDIS driver.

--
Kathleen Applegate                     |  New Technology Inc.
Senior Analyst                         |  700 Boulevard South, #401
drvax3!apple@freedom.msfc.nasa.gov     |  Huntsville, AL  35802


-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      27 May 92 16:31:40 GMT
From:      mtayler@pilot.njin.net (Mark Tayler)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Connecting ethernet to tokenring.

We currently have both token ring and ethernet on campus.
We want to run TCP/IP on both platforms.  
We also want to connect the token ring to the ethernet.

The configuration is as follows:

Campus wide ethernet with:
	10baseT hubs connected by fiber optic.

2 seperate token ring labs with:
	IBM PS/2 Model 80 server for each connected to
	16 IBM PS/2s 55sx on token ring, (each lab)

I have the following Questions:

1) Has anyone out there connected ethernet to token ring
   and how did they do it.

2) What additional hardware and software will I need.

3) Is there an inexpensive solution, perhaps using the model
   80 servers as protocol converters, each one with a
   token ring and ethernet card in them.

Any and all help will be appreciated.

******************************************************************************
*  Mark L. Tayler                                 System Administrator:      *
*  mtayler@pilot.njin.net                         County College of Morris   *
*                                                 (201) 328-5778    (VOICE)  *
*                                                 (201) 328-5058    (DATA)   *
*                                                 No Net Access Yet !!!!     *
******************************************************************************

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 May 1992 16:36:36 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: troubleshooting idiot guide

In article <1992May27.044114.22303@cognos.com> nigelc@cognos.com (Nigel Campbell) writes:
>Does anyone have an idiots guide for solving problems
>for TCP/IP [...] Wollongong are the main vendors of interest, thanks.

Unofficial WIN/TCP for VMS troubleshooting guide:

	Have you rebooted the machine, and does the problem still
	exist?

At least that was the running joke among Wollongong support when I was
there to solve almost any problem.

:-)

Warner
-- 
Warner Losh		imp@Solbourne.COM
"Something grabbed a hold of my hand/ I didn't know it had my hand/
 but that's when all my troubles began" TMBG

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      27 May 92 16:47:28 GMT
From:      ccganzhorn@mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting ethernet to tokenring.

In article <May.27.12.31.40.1992.19120@pilot.njin.net>, mtayler@pilot.njin.net (Mark Tayler) writes:
|> We currently have both token ring and ethernet on campus.
|> We want to run TCP/IP on both platforms.  
|> We also want to connect the token ring to the ethernet.
|> 
|> The configuration is as follows:
|> 
|> Campus wide ethernet with:
|> 	10baseT hubs connected by fiber optic.
|> 
|> 2 seperate token ring labs with:
|> 	IBM PS/2 Model 80 server for each connected to
|> 	16 IBM PS/2s 55sx on token ring, (each lab)
|> 
|> I have the following Questions:
|> 
|> 1) Has anyone out there connected ethernet to token ring
|>    and how did they do it.
|> 
|> 2) What additional hardware and software will I need.
|> 
|> 3) Is there an inexpensive solution, perhaps using the model
|>    80 servers as protocol converters, each one with a
|>    token ring and ethernet card in them.
|> 
|> Any and all help will be appreciated.
|> 
|> ******************************************************************************
|> *  Mark L. Tayler                                 System Administrator:      *
|> *  mtayler@pilot.njin.net                         County College of Morris   *
|> *                                                 (201) 328-5778    (VOICE)  *
|> *                                                 (201) 328-5058    (DATA)   *
|> *                                                 No Net Access Yet !!!!     *
|> ******************************************************************************

I know Wellfleet for sure and I believe cisco as well can route IP from token
ring to ethernet and back.  Routed protocols aren't such a bother as generically
bridging token ring traffic to ethernet.  The best translation bridge I currently
know of is the IBM 8209.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IS&DP Network Services		AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 May 92 17:38:33 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-Adresse from /dev/ttyp??

In article <1992May25.072415.8831@medtron.medtronic.com>, rh0083b@medtronic.COM (Roger Hunen) writes:
   Right. I just ran into the 16-byte limit the hard way. Also, not all UNIXes
   provide the host info in the who output. This still leaves us with the
   where-did-I-come-from problem :-(.

I haven't been following this thread carefully, so I apologize if this
is superfluous, but you could hack the telnetd source (assuming it's
available for you) to store the IP address in your own table, or to 
create an environment variable for it which can be passed to /bin/login,
etc. etc.

telnetd is the only thing that really knows where you came from, via
getpeername(), and it writes it into /etc/utmp. 

Come to think of it, since only 16 bytes are stored in utmp, you could
modify telnetd to store the IP address instead of the hostname, thereby
guaranteeing that it will fit in entirety.
 
 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        || 
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 May 92 19:24:21 GMT
From:      chris@frcs.Alt.ZA (Chris Old)
To:        comp.protocols.tcp-ip
Subject:   Negotiation terminal type in telnet

I notice that when telnetting from a Unix machine (svr4) to another,
telnet somehow manages to tell the remote machine what terminal I am
using.  Great.

Now I want to do the same when telnetting from a DOS machine running KA9Q
to the same Unix box.  Looking through the KA9Q source, I see that all
the hooks are there, but I need to know what "DO DON'T WILL WON'T"
negotiation I should use.

The May '83 RFC 854 doesn't have this info.  Is there a later RFC for
telnet?  Does anyone know offhand what the negotiation should look like?

All help much appreciated,
chris

PS: I realise that the DOS machine doesn't strictly have a terminal type,
but we have already added various hacks to KA9Q to send special chars for
the various key strokes, and have written a terminfo entry for type
'ka9q'.  What we want is to avoid the user having to 'export TERM=ka9q'.

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      27 May 92 21:17:09 GMT
From:      brian@osl.or.gov (Brian McBee)
To:        comp.protocols.tcp-ip,alt.sys.sun
Subject:   Need help setting up SLIP connection

I am trying to set up a dial-up SLIP connection from my home machine, a PC 
running KA9Q, and a Sparcstation on the LAN at work.  I have gotten the Sunos 
SLIP package and installed it on the Sun, rebuilding the kernel.  Here is the 
layout:

   ______                              ___________        __________
  |      |         phone line         |           |      |          |
  | PC   |----------------------------| Netblazer |      |   SUN    |
  | KA9Q |          Network B         |           |      |          |
  |______|                            |___________|      |__________|
   home                                     |                 |
   machine                                 ============================
                                                  Network A

The way it is currently set up, I don't have the option of making a SLIP 
connection to the Netblazer, as we have the ports set up to auto-telnet to the 
Sparc machine.

1.  Is it possible to make the SLIP connection over the Telnet connection from 
the Netblazer the the Sparc?

2.  Since the Sun is effectively acting as a router, does the network B from 
the Sun to my PC need to be a different subnet than the Network A above?

3.  When I finish the connection and am ready to hang up, how do I tell the 
Sun to lose the SLIP interface?  Or do I just hang up?

4.  Is there anything else I need to know to get this working?

I assume this is all very easy to do, but the documentation that came with the 
SLIP package is minimal.

Thanks,
brian@opac.osl.or.gov

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      27 May 92 22:02:03 GMT
From:      4carroll_j@spcvxb.spc.edu
To:        comp.protocols.tcp-ip
Subject:   tcp-ip source

Hi,
	Wow, I posted a question about 2 weeks ago a received a flood
of responses. I would just like to say thank-you to all the people 
who took the time to answer my post. 

	My origianl question was if there were any multi-user, multi-tasking
public domain tcp-ip source packages available for downloading. I mentioned
that I already had access to KA9Q, and NCSA, but for various reasons these
packages were not suitable. I also mentioned that I was developing a
tcp-ip implementation for Qnx (a [distant] Unix cousin).

	Here is a distillment of the responses I received in private email.

	1. KA9Q is not public domain. It is available for nominal fee for
		commercial use from it's author.

	2. KA9Q has been sucessfully ported by a number of users to multi-user
		multi-tasking operating systems.

	3. The source code to the Berkely Unix tcp-ip implementation is available
		for anonymous ftp from ftp.uu.net.

	4. Quantum Software has a beta version of tcp-ip available for Qnx.
		(Qnx is the operating system we use in-house).

	Anyone wishing further details, or the text of the mail I received this
information from, please email me and I would be happy to help.

BFN
Jim C.
(4carroll_j@spcvxa.spc.edu)

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 May 1992 01:26:18 GMT
From:      shin@nc.u-tokyo.ac.jp (Shin YOSHIMURA)
To:        fj.meetings,alt.inet92,comp.org.acm,comp.org.ieee,comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc,comp.unix.wizards
Subject:   INET '92

Originate-From: lhl@cs.wisc.edu (L.H. Landweber)


                            INET'92
                         June 15-18, 1992
                           Kobe, Japan
 
You still have the chance to join your 400 colleagues from around the world
who have registered for INET'92, the first official conference of the 
Internet Society. At the  conference you will meet key persons involved 
with planning, designing, funding, operating and using the world-wide 
networks for research and education.
 
We now have a high class program for the conference as well as tutorials
and a workshop for developing countries. The first general meeting of
the Internet Society will also take place at the conference.
 
The program and registration information can be ordered from
inet92@wide.ad.jp, inet92.educom.edu or inet92@vm.uni-c.dk.
 
You should note that several airlines have affordable fares to Japan,
please check with your travel agency.
 
If you have time to spend in Japan before or after the conference we
are happy to advise you of things to see and places to go.  Japan is in
the rainy season so don't forget to bring your umbrella or raincoat.
The temperature will be mild but on shiny days it will be hot and you
will need half-sleeve shirts or T-shirts.
 
See you in Kobe in three weeks.
--
吉村 伸

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 May 1992 02:15:05 GMT
From:      karl@empirical.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Commercial hype -- Was Re: SNMP Training Seminars Offered (june)

In article <1992May19.231526.16711@ryn.mro4.dec.com> domenikos@delni.enet.dec.com writes:
>From: domenikos@delni.enet.dec.com
>Subject: SNMP Training Seminars Offered (june)
>Date: 19 May 92 23:13:27 GMT
 
>DTC is offering the following SNMP seminars in June
>in Boston:

Now, I am more liberal than most.  I don't mind people on the network who 
make commercial statements as long as they are merely part of an otherwise 
useful message.

However, this stuff hyping SNMP courses is pure advertising.  And you post
it every month!

Please stop posting it, or at least put it into something useful.
For example, why don't you do something like Marshall's "Simple Times",
give it away for free, and perhaps make a passing mention of your courses?

By-the-way, I can't remember ever seeing your name at an SNMP working
group meeting, on a MIB document, or at any IETF meeting.

			--karl--


-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      28 May 92 02:23:48 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting ethernet to tokenring.

Along with the Wellfleet and cisco routers that have already been
mentioned, Proteon can do the routing from one media to the other.
Be aware that bridge solutions can have problems here because of 
the differences in the media.  I like bridges for many applications,
but for this I prefer a router.  

Just consider what to do with a
maximum size token ring packet bound for an ethernet host.  A router
would perform IP fragmentation but a bridge would either truncate
or drop the packet.  Either solution is unacceptable.  If the MTU
is set down to the ethernet max. then token ring to token ring
packets are kept artificially low.  This may seem like a minor 
problem but it is an example of the kinds of problems that can
occur when bridging dissimilar media.

Good luck.
-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      28 May 92 02:26:47 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Negotiation terminal type in telnet

In article <1992May27.192421.5193@frcs.Alt.ZA>, chris@frcs.Alt.ZA (Chris Old) writes:
|> I notice that when telnetting from a Unix machine (svr4) to another,
|> telnet somehow manages to tell the remote machine what terminal I am
|> using.  Great.
|> 
|> Now I want to do the same when telnetting from a DOS machine running KA9Q
|> to the same Unix box.  Looking through the KA9Q source, I see that all
|> the hooks are there, but I need to know what "DO DON'T WILL WON'T"
|> negotiation I should use.
|> 
|> The May '83 RFC 854 doesn't have this info.  Is there a later RFC for
|> telnet?  Does anyone know offhand what the negotiation should look like?
|> 
|> All help much appreciated,
|> chris
|> 
|> PS: I realise that the DOS machine doesn't strictly have a terminal type,
|> but we have already added various hacks to KA9Q to send special chars for
|> the various key strokes, and have written a terminfo entry for type
|> 'ka9q'.  What we want is to avoid the user having to 'export TERM=ka9q'.

RFC 1091 details terminal type negotiation.
-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      28 May 92 04:31:46 GMT
From:      mtayler@pilot.njin.net (Mark Tayler)
To:        comp.protocols.tcp-ip
Subject:   What is SLIP ?

I have been following this newsgroup for about a month
and have seen mention of SLIP. I have a few questions about
this software, such as :

1)  What is slip, and what will it allow me to do ?
2)  Are there ftp sites for slip, and if so where ?
3)  Are there any RFCs for slip, and if so where ?

Any and all help  is appreciated.


******************************************************************************
*  Mark L. Tayler                                 System Administrator:      *
*  mtayler@pilot.njin.net                         County College of Morris   *
*                                                 (201) 328-5778    (VOICE)  *
*                                                 (201) 328-5058    (DATA)   *
*                                                 No Net Access Yet !!!!     *
******************************************************************************

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 May 92 06:44:46 GMT
From:      arnej@lise.unit.no (Arne Henrik Juul)
To:        comp.bugs.4bsd,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.unix.bsd
Subject:   A new, patched BSD telnet

After some counseling with friends, I have made a new, patched BSD
telnet package available on our ftp server:
    ugle.unit.no:/pub/unix/network/telnet-92b.tar.Z
If people can't ftp there, mail me and I'll send an uuencoded version
in mail. (Patches will be very big, so I don't really think it's worth
the bother).

This version has support for the telnet client on SGI's Irix4.0.1, and
on the Dolphin m88k SVr3.2 in addition to Ultrix, SunOS, Unicos etc.
which are in the telnet.91.03.25 package. Also, a couple of bugs are
fixed:

A missing parameter to send_will in the state.c file is corrected,
thanks to Brad Strand at Cray.

Support has been added to telnetd.c to allow writing the decimal
dotted-quad internet address to the utmp file, for systems with only
16 bytes space in the host field.

Last, a bug in the telnet client which caused the SEND command to fail
was fixed. This was done by a hacker here at the University (Tor
Egge).

I hope as many people as possible will try this out, also on more
machines than those already supported. I do not think Irix is very
hard to support fully (I'm working on this), and also system V
machines with some berkeley extensions should be easy (I'm working on
HP-UX at least).

I'll act as coordinator of this package for the time being, as it
doesn't seem anyone else wants to. So send your bug reports to me and
I'll do the best I can.

Note: Followup is set to comp.bugs.4bsd !


Sincerely yours,
    Arne H. Juul, arnej@lise.unit.no

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      28 May 92 14:02:10 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercial hype -- Was Re: SNMP Training Seminars Offered (june)

In article <karl.18.707019305@empirical.com> karl@empirical.com (Karl Auerbach) writes:
>   However, this stuff hyping SNMP courses is pure advertising.  And you post
>   it every month!

I don't see anything wrong with it. He just said the course was
available. He didn't mention a price.

Last time he posted a message, I registered for the course.

Without the posting, I would not know the course was available.
I posted a query here asking about the course and if any others were
available. I received no response. As far as I can tell, this is the
only course on writing SNMP applications.


If there was a newsgroup advertising tutorials, I wouldn't read it. 
It makes sense posting a special interest tutorial in the the snmp
newsgroup. 

Cross-posting it to the tcp-ip newsgroup is questionable, however.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      28 May 92 15:29:34 GMT
From:      sob@hsdndev.UUCP (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting ethernet to tokenring.

In article <1992May28.022348.2798@tridom.com> mwr@tridom.uucp (Mark Reardon) writes:
>Along with the Wellfleet and cisco routers that have already been
>mentioned, Proteon can do the routing from one media to the other.

also 3Com & HP...


I ran some performance tests between a number of vendor's router boxes in the
last 2 months - the results are on hsdndev.harvard.edu in pub/ndtl

Scott

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      28 May 92 15:30:50 GMT
From:      sob@hsdndev.UUCP (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting ethernet to tokenring.

In article <1992May28.022348.2798@tridom.com> mwr@tridom.uucp (Mark Reardon) writes:
>Along with the Wellfleet and cisco routers that have already been
>mentioned, Proteon can do the routing from one media to the other.

oops - and Ascom Timeplex  (all for IP routing)

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 May 1992 23:07:48 GMT
From:      speth@vxdesy.desy.de
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   CUTCP in Windows 3.1

I just got Windows 3.1 installed and running off a Novell 3.11 server.  I felt
like "kicking the tires" a bit, so I tried running CUTCP telnet from inside
Windows.  It actually worked for a few minutes....and then all of a sudden
dropped the connection, and Windows, and landed at DOS; this happened several
times, alway after a few minutes.

I'm running DOS 5.0 with the Windows 3.1 supplied versions of HIMEM.SYS, LSL, 
IPXODI and NETX.  I'm using ODIPKT for the packet driver interface of CUTCP.

Any suggestions? 
Jan

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      29 May 92 08:00:55 GMT
From:      lucien@integow.uucp (Lucien de Freitas)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.misc
Subject:   Is there a KERMIT supporting TCP/IP ?


Hi,

I'm desperately seeking for a UNIX version of KERMIT which 
includes built-in-TCP/IP network support.

I have release 3.11 of MS-DOS KERMIT which includes built-in 
TCP/IP network support and I'm very happy with it. But now I
need the same features for a UNIX machine.

I wonder if anybody knows a version of KERMIT for a UNIX machine
which also includes built-in TCP/IP networking support or any 
network support at all.


-- 
+-------------------------------------------------------------------+
| UUCP: ..!uunet!mcsun!hp4nl!integow!lucien or  lucien@integow.uucp |
| Lucien de Freitas, Integrity software architects & consultants,   |
|        Pelmolenlaan 16, 3447 GW Woerden, Netherlands,             |
|           tel +31 3480-30131, fax +31 3480-30182                  |
+-------------------------------------------------------------------+

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      29 May 92 08:27:24 GMT
From:      rachelw@spider.co.uk (Rachel Willmer)
To:        comp.protocols.tcp-ip
Subject:   French name for TFTP?


Should the name of TFTP in French be Trivial File Transfer Protocol,
or something like Protocol Simplifie de Transfert de Fichier?

Please email.
Rachel

--

Rachel Willmer                             Spider Systems 
rachelw@spider.co.uk                       Spider Park, Stanwell Street
+44 31 554 9424                            Edinburgh, Scotland

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 May 1992 10:16:27 GMT
From:      shige@wide.AD.JP (Shigeki Yoshida)
To:        fj.meetings,alt.inet92,comp.org.acm,comp.org.ieee,comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc,comp.unix.wizards
Subject:   The remainder of Accompany Peron Programs at INET'92.


To INET'92 participant:

  You still have a chance to reserve an Accompany Person Programs and
a Post Conference Tour at INET'92; there are some remainder of those
programs without "Kobe Afternoon Tour".

From INET '92 REGISTRATION FORM:

                        ITEM                                    Fees (JPY)
-----------------------------------------------------------------------
Accomp.          Himeji Castle and Kikkoman Takasago Plant      12900
Persons          ------------------------------------------------------
Program          Japanese Tea Ceremony                           7300
-----------------------------------------------------------------------
Post Conf.       Tour   Kyoto One Day                           18900
-----------------------------------------------------------------------

--
Shigeki Yoshida, WIDE Project, JAPAN (shige@wide.ad.jp)

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 May 1992 17:45:01 GMT
From:      jaapjl@tab00.larc.nasa.gov (J Lee Jaap)
To:        news.newusers.questions,comp.protocols.tcp-ip
Cc:        temp23@lub001.lamar.edu
Subject:   Re: Routing on the Internet

In article <1992May28.235135.1206@lub001.lamar.edu> temp23@lub001.lamar.edu writes:

   How is routing handled on the Internet? 

Try comp.protocols.tcp-ip, to which I'm sending this post.
news.* is for discussion of news, user and admin stuff.
-jlj
--
J Lee Jaap <jaapjl@tab00.larc.nasa.gov> {+1 804/864, or FTS 928}-2148
employed by, not speaking for, AS&M Inc, at NASA LaRC, Hampton VA 23665-5225

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      29 May 92 18:11:07 GMT
From:      dave@netmgr.mmc.com (David A. Rageth)
To:        comp.protocols.tcp-ip
Subject:   IP over partial mesh Frame Relay

I was wondering if there were any problems running IP over a partial
mesh Frame relay network using OSPF routing.  Does anyone have
any experience and know off-hand?

-- 
x++++++++++++++++++++++++++++++++++++++++x
 x            David Rageth                x
  x   Internet : dave@mmc.com              x
   x   voice    : (303)977-4584             x
    x   fax      : (303) 971-1259            x
     x   USMail   : Martin Marietta           x
      x              P.O. Box 179 m/s 1084     x
       x              Denver, Colorado          x
        x                               80201    x
         x++++++++++++++++++++++++++++++++++++++++x

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      29 May 92 19:47:52 GMT
From:      apollo@buengc.bu.edu (Doug A. Chan)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   Need help with performance on long-delay paths!

I'm currently taking care of a WAN which includes a link between the US
and Japan.  The link currently has 256K bandwidth with approx. 128ms
round trip delay.  However, recently, our carrier had a undersea fiber
repeater failure and our link was routed over satellite.  Our 128ms
round trip delay became 600ms after the re-route.

Using rcp to copy files between the US and Japan nodes, our average
thruput on that 256kbps link w/128ms delay was about 120kbps.
That's about 50% utilization!  Not very impressive at all.

Now, when that link was routed over satellite, the thruput dropped to
33kbps (13% utilization).

FYI, here's our test setup:

            USA node                                    Japan node

   [PC]-----[ROUTER]-----[BWM]==================[BWM]-----[ROUTER]-----[PC]

PC: 386/33 SCO Unix machines
ROUTER: Cisco MGS
BWM: Network Express NE3000 Bandwidth Managers (additional bandwidth
        disabled)
-----: Ethernet
=====: 256kpbs link

1- What can be done to improve thruput under normal circumstances?
   (that is, over fiber with 128ms round-trip delays)
2- Is 'rcp' just not very good at handling long delay paths?
   (as far as I know, rcp is UDP based, so all flow control/error
    checking handled in rcp...) 
3- What can be done to handle the really large delay situations?

4- Can anyone point out some other WAN test results/papers?

Thanks!
-Doug
apollo@buengc.bu.edu

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      29 May 92 21:09:40 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with performance on long-delay paths!

In article <87305@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
>I'm currently taking care of a WAN which includes a link between the US
>and Japan.  The link currently has 256K bandwidth with approx. 128ms
>round trip delay.  However, recently, our carrier had a undersea fiber
>repeater failure and our link was routed over satellite.  Our 128ms
>round trip delay became 600ms after the re-route.
>
>Using rcp to copy files between the US and Japan nodes, our average
>thruput on that 256kbps link w/128ms delay was about 120kbps.
>That's about 50% utilization!  Not very impressive at all.
>
>Now, when that link was routed over satellite, the thruput dropped to
>33kbps (13% utilization).
>
>FYI, here's our test setup:
>
>            USA node                                    Japan node
>
>   [PC]-----[ROUTER]-----[BWM]==================[BWM]-----[ROUTER]-----[PC]
>
>PC: 386/33 SCO Unix machines
>ROUTER: Cisco MGS
>BWM: Network Express NE3000 Bandwidth Managers (additional bandwidth
>        disabled)
>-----: Ethernet
>=====: 256kpbs link

Sounds like you are being limited by TCP window size.  A 256Kbps link
with 600msec roundtrip is about a 20Kbyte deep pipe.  If the TCP
window is only 4k, then the best you should do is about 20% (ignoring
packet overheads).  This tends to agree with you numbers.  A 4k
window would not be suprising for a PC.

>1- What can be done to improve thruput under normal circumstances?
>   (that is, over fiber with 128ms round-trip delays)

Both cases would improve with increased windows.  Also, multiple TCP
sessions will be able to use more bandwidth until the link saturates.

>2- Is 'rcp' just not very good at handling long delay paths?
>   (as far as I know, rcp is UDP based, so all flow control/error
>    checking handled in rcp...) 

RCP uses TCP.

>3- What can be done to handle the really large delay situations?

Larger windows.

>4- Can anyone point out some other WAN test results/papers?
>
>Thanks!
>-Doug
>apollo@buengc.bu.edu

Art

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      29 May 92 21:19:59 GMT
From:      ccganzhorn@mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with performance on long-delay paths!

The problem you're running into is probably because TCP uses the round
trip time to calculate how fast it should transmit.  It is an attempt to
avoid congestion.  Unfortunately, the algorith doesn't take into account
that the delay might be due to latency rather than congestion.  

That is probably the cause but I don't know how one would tune the TCP
on the machines to deal with it.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IS&DP Network Services		AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      29 May 92 23:12:42 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with performance on long-delay paths!

In article <1992May29.211959.12104@mmm.serc.3m.com> ccganzhorn@mmm.com ("Charles Ganzhorn") writes:
>The problem you're running into is probably because TCP uses the round
>trip time to calculate how fast it should transmit.  It is an attempt to
>avoid congestion.  Unfortunately, the algorith doesn't take into account
>that the delay might be due to latency rather than congestion.  

No, actually the roundtrip time calculations are used to determine how
long to wait before RETRANSMITTING.  The window determines how much
data can be in flight without an acknowledgement.  Modern TCPs do reduce
their transmit window if a timeout occurs, but I think the problem is window
size.

>That is probably the cause but I don't know how one would tune the TCP
>on the machines to deal with it.
>
>Charles.

Art

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      29 May 92 23:18:09 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over partial mesh Frame Relay

In article <1992May29.181107.6862@den.mmc.com> dave@netmgr.mmc.com (David A. Rageth) writes:
>I was wondering if there were any problems running IP over a partial
>mesh Frame relay network using OSPF routing.  Does anyone have
>any experience and know off-hand?
>

If IP sees the FR network as a single, multipoint network, then OSPF
requires a full mesh connectivity.  If IP sees the FR network as a
bunch of independent point-to-point links (and OSPF advertise them that
way), OSPF will work.  The first model seems to be the one most
router vendors are using.

Art

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 May 92 23:42:41 GMT
From:      thsssxs@iitmax.iit.edu (Semir Sirazi)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Extensions to existing MIBS



	Hello there, we are just beginning to get involved with SNMP and are
	interested in adding management capabilities to our upcoming product.
	What we are interested in is how does one go about extending a MIB,
	whether it is standard or experimental. That is to say, if we wanted
	to add some objects to an existing MIB, where does that information
	reside relative to the MIB we are trying to extend. It seems to violate
	standards if we add it directly to the MIB. It seems to lose continuity
	if we have the new objects in our enterprise subtree. And it seems 
	redundant to copy the entire MIB into our enterprise subtree. Am I
	missing a very important point here? 

	Any help here would be greatly appreciated.

	Please send responses directly back to thsssxs@iitmax.iit.edu

				Keith Zimmerman

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      29 May 92 23:47:41 GMT
From:      tjg01@thdhub.UUCP (Terry Gardner)
To:        comp.protocols.tcp-ip
Subject:   A class addresses (not assigned)

My company wants to use A class addresses that are not sanctioned
by the keepers of Internet addresses. We have a B class address
assigned to us, but the security folks don't want to have to
deal with the subnet masks. They would rather use an entire octet
to "subnet". We have a large corporate networking environment and
over 200 hosts across the country. My question is: What are the
ramifications of using an A class address that is not assigned to
us by the Internet people, with a possible gateway to Internet?
Another question is: Is there anything special about the 192.x.x.x address?
I've been told (by a vendor) that 192 is the A class part used in
networks NOT connected to the internet.
-- 
"VMS is a text-only adventure game. If you win, you can use UNIX".
terry@thdhub					Terry J. Gardner

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      30 May 92 03:26:04 GMT
From:      mwitt@ogicse.ogi.edu (Mike Witt)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over partial mesh Frame Relay

In article <1992May29.231809.13500@acc.com> art@acc.com (Art Berggreen) writes:
>
>If IP sees the FR network as a single, multipoint network, then OSPF
>requires a full mesh connectivity.  If IP sees the FR network as a
>bunch of independent point-to-point links (and OSPF advertise them that
>way), OSPF will work.  The first model seems to be the one most
>router vendors are using.
>
>Art

I wonder if I'm missing something here.  My understanding was that
most initial FR services will offer only "permanent virtual 
circuits."  Wouldn't "switched virtual circuits" be necessary to
achieve the possibility of a "full mesh".  I would have assumed
that advertising each PVC as a point-to-point link would be
only reasonable strategy for frame relay.

Mike





-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      30 May 92 03:48:24 GMT
From:      apollo@buengc.bu.edu (Doug A. Chan)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with performance on long-delay paths!

In article <1992May29.210940.13166@acc.com> art@acc.com (Art Berggreen) writes:
>In article <87305@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
>>thruput on that 256kbps link w/128ms delay was about 120kbps.
>>That's about 50% utilization!  Not very impressive at all.
>>Now, when that link was routed over satellite, the thruput dropped to
>>33kbps (13% utilization).
>Sounds like you are being limited by TCP window size.  A 256Kbps link
>with 600msec roundtrip is about a 20Kbyte deep pipe.  If the TCP
>window is only 4k, then the best you should do is about 20% (ignoring
.
I've thought about that possibility but it is hard to say since I don't
know the internals of Lachman's TCP/IP implementation for SCO Unix.
I always thought that the window size can go up to a full 64K as long
as there isn't dropped/timed-out packets.  Hmmm, maybe I should check the
the number of packet retransmissions?

I believe the NE3000 plays a part in the delay as well since the bandwidth
manager also acknowledges every frame of data it receives.

>>1- What can be done to improve thruput under normal circumstances?
>Both cases would improve with increased windows.  Also, multiple TCP
>sessions will be able to use more bandwidth until the link saturates.
.
Yes, but how?
.
>>2- Is 'rcp' just not very good at handling long delay paths?
>>   (as far as I know, rcp is UDP based, so all flow control/error
>RCP uses TCP.

I've always thought it was based on datagrams (UDP).  I guess I'll have
to check into that again.
Thanks for the input!

---
-Doug
apollo@buengc.bu.edu
.

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 May 1992 04:44:52 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with performance on long-delay paths!

In article <87305@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
+---------------
| Using rcp to copy files between the US and Japan nodes, our average
| thruput on that 256kbps link w/128ms delay was about 120kbps.
| That's about 50% utilization!  Not very impressive at all.
+---------------

Your TCP window size was probably too small. Note that many older Berkeley-
based TCP's have a default window advertisement of only 4096 bytes, and
some PC implementations advertise even less.

A good TCP should be able to get one window's worth of data per round-trip
time. Even with only a 4K window, that's (4096*8)/0.128 = 256 Kb/s. Now if
your round-trip time was actually 256ms, or your offered window was only 2048
bytes, your 120 Kb/s throughput would make sense.

+---------------
| Now, when that link was routed over satellite, the thruput dropped to
| 33kbps (13% utilization).
+---------------

You said 600ms, and (4096*8)/0.600 = 54.6 Kb/s, which is what you should be
getting. Hmmm... Both sets of numbers are consistent with your PC-based TCP
advertising only a 2048-byte window. Obviously the first thing you should
investigate...

+---------------
| 1- What can be done to improve thruput under normal circumstances?
|    (that is, over fiber with 128ms round-trip delays)
+---------------

Increase the offered window to *at least* 4096 bytes, preferably 8K or more.
With the larger window, you should be able to saturate the 256 Kb/s link.

+---------------
| 2- Is 'rcp' just not very good at handling long delay paths?
|    (as far as I know, rcp is UDP based, so all flow control/error
|     checking handled in rcp...) 
+---------------

Wrong-o, "rcp" uses TCP, and all flow-control/error-retransmission is in TCP.

+---------------
| 3- What can be done to handle the really large delay situations?
+---------------

Really large window sizes. ;-}  ;-}  Seriously, see RFC 1072 "TCP Extensions
for Long-Delay Paths" and RFC 1185 "TCP Extension for High-Speed Paths".

+---------------
| 4- Can anyone point out some other WAN test results/papers?
+---------------

Last November (1991), Thomas Skibo of University of Illinois implemented an
experimental version of RFC 1072/1185 in the Silicon Graphics 4D/310, and
with 256 KB windows was able to get a sustained 31 Mb/s of "ttcp" over an
800 mile T3 (45 Mb/s) link with a round-trip delay of ~25ms. The layout was:

			  <-------- 800 mi --->
              100 Mbit/s          45 Mbit/s        100 Mbit/s
 SGI 4D/310  <----FDDI--> NSC <-----DS3-----> NSC <---FDDI---> SGI 4D/310
(University of Illinois) router              router (Bell Labs, Murray Hill,NJ)

Without the large-window extensions, the theoretical maximum for TCP with
a 25ms round-trip delay is (64K * 8) / 0.025 = 21 Mb/s.

About two months previous to this, Van Jacobson and Dave Borman had publicly
demonstrated a sustained ~9 Mb/s over a 36ms round-trip delay link (~1000 mi),
with interoperation between two completely independent implementations of
RFC 1072/1185, on a Cray (running Dave's code) and a Sun (running Van's):

            FDDI            T3 backbone        Ethernet
           100Mb/s            45Mb/s            10Mb/s
  Cray YMP -------> PSC ENSS --....--> DC ENSS ---------> SparcStation-2
  Pittsburgh                              Educom National Net '91
Supercomputer                                 Conference
   Center                                    Washington, DC

They were using 512KB windows (due to a buffer limit in their routers). The
limiting factor was almost certainly the 10 Mb/s Ethernet on the show floor.

So, "We have the technology..."          ["We" == "the networking industry"]


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673 <-- New number!
2011 N. Shoreline Blvd.		"Please make a note of it..."
Mountain View, CA  94043


-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      30 May 92 05:07:16 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over partial mesh Frame Relay

In article <37962@ogicse.ogi.edu> mwitt@ogicse.ogi.edu (Mike Witt) writes:
>In article <1992May29.231809.13500@acc.com> art@acc.com (Art Berggreen) writes:
>>
>>If IP sees the FR network as a single, multipoint network, then OSPF
>>requires a full mesh connectivity.  If IP sees the FR network as a
>>bunch of independent point-to-point links (and OSPF advertise them that
>>way), OSPF will work.  The first model seems to be the one most
>>router vendors are using.
>>
>>Art
>
>I wonder if I'm missing something here.  My understanding was that
>most initial FR services will offer only "permanent virtual 
>circuits."  Wouldn't "switched virtual circuits" be necessary to
>achieve the possibility of a "full mesh".  I would have assumed
>that advertising each PVC as a point-to-point link would be
>only reasonable strategy for frame relay.
>
>Mike

If you view FR as a public network that has a very large population
of nodes that you only have occassional communication with, then
you wouldn't want PVCs nailed up between everyone.  Here SVCs
would lend themselves to general connectivity.

But if the FR is used to create "virtual networks" connecting a
more constrained set of nodes (typically bridge/routers), then
it is feasable to fully connect that set of nodes with PVCs.  In
this model, the "virtual network" has one IP (sub)net number which
is used for routing.  The appropriate PVC (and associated DLCI)
is resolved from the next-hop IP address.

If the FR connectivity is not full mesh, routing gets more difficult.
One can deal with this by treating the FR net as a large collection
of p-p links, but this tends to cause an increase in routing topology
information (especially for OSPF).

Unfortuneatly, the pricing of FR services seems to encourage people
not to fully interconnect their nodes with PVCs.  This may save some
in PVC related charges, but careful traffic engineering must be done to
avoid having lots of traffic taking multiple hops across the FR net.

Art

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      30 May 92 05:31:31 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with performance on long-delay paths!

In article <87355@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
>In article <1992May29.210940.13166@acc.com> art@acc.com (Art Berggreen) writes:
>>Sounds like you are being limited by TCP window size.  A 256Kbps link
>>with 600msec roundtrip is about a 20Kbyte deep pipe.  If the TCP
>>window is only 4k, then the best you should do is about 20% (ignoring
>.
>I've thought about that possibility but it is hard to say since I don't
>know the internals of Lachman's TCP/IP implementation for SCO Unix.
>I always thought that the window size can go up to a full 64K as long
>as there isn't dropped/timed-out packets.  Hmmm, maybe I should check the
>the number of packet retransmissions?

I doubt a PC would default that large a window.  I think SUNs still default
to 8K.  Also, remember that the receiving end controls the ultimate maximum
window size.  The transmitter may use a smaller window than is offered
for various reasons (such as congestion).

>I believe the NE3000 plays a part in the delay as well since the bandwidth
>manager also acknowledges every frame of data it receives.

If the underlying channel limits the amount of data in flight to less than
the amount needed to fill the pipe, then there not much you can do.  This
is especially bad if data is just dropped after a point.  If this is true,
it will look like congestion to TCP.  At best, the TCP will keep it's
transmit window down, at worst, TCP will perform lots of retransmitting.

>>>1- What can be done to improve thruput under normal circumstances?
>>Both cases would improve with increased windows.  Also, multiple TCP
>>sessions will be able to use more bandwidth until the link saturates.
>.
>Yes, but how?
>.
>>>2- Is 'rcp' just not very good at handling long delay paths?
>>>   (as far as I know, rcp is UDP based, so all flow control/error
>>RCP uses TCP.
>
>I've always thought it was based on datagrams (UDP).  I guess I'll have
>to check into that again.

SUNs RPC (and NFS) is based on UDP.

>Thanks for the input!
>
>---
>-Doug
>apollo@buengc.bu.edu
.
Art

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 May 1992 05:31:39 GMT
From:      karl@ddsw1.mcs.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: A class addresses (not assigned)

In article <1992May29.234741.1386@thdhub.UUCP> tjg01@thdhub.UUCP (Terry Gardner) writes:
>My company wants to use A class addresses that are not sanctioned
>by the keepers of Internet addresses. We have a B class address
>assigned to us, but the security folks don't want to have to
>deal with the subnet masks. They would rather use an entire octet
>to "subnet". We have a large corporate networking environment and
>over 200 hosts across the country. My question is: What are the
>ramifications of using an A class address that is not assigned to
>us by the Internet people, with a possible gateway to Internet?

Hmmmmm....

IF you firewall the network from the Internet with a machine which DOES NOT
route packets, and the firewall is on registered space, then you are ok.

HOWEVER -- this means you can't FTP, Telnet etc. from the machines on the
unregistered side.  Users would have to log into the firewall, which is on
registered space, and do their thing from there.

Things are likely to get real interesting if you try to do this and route
packets out to the Internet which have someone else's Class A address --
"interesting" being defined as (probably) being unable to talk to anyone
(at best they won't be able to find a route back to you) to really p*ing 
off the rightful owners of that address space.

BTW, 200 hosts is nothing really.  You certainly won't be able to justify a
"real" class A assignment with only 200 hosts involved...

You could use a Class B address and subnet it like a class C.  This would 
give you an entire octet for the subnet, and another for the host portion.
This is actually a rather popular thing; it makes for relatively simple 
configuration and doesn't confuse people like strange subnetting (i.e. 
28 bit or something similar) does.

>Another question is: Is there anything special about the 192.x.x.x address?
>I've been told (by a vendor) that 192 is the A class part used in
>networks NOT connected to the internet.

Someone's not thinking.  From my system (ifconfig):

eth0: flags=23<UP,BROADCAST,NOTRAILERS>
	inet 192.160.127.2 netmask ffffff00 broadcast 192.160.127.255

That's a quite-legitimate, registered IP address.  Its first octet is 192.
This is a class >C< address, not a class A.  MCS.COM has assigned
192.160.127.x as our class "C" space.

Class A addresses run up to 126.  127 is reserved.

Last I heard, something like up to 53 were assigned, although I don't have
hard statistics on this.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 May 1992 11:05:56 GMT
From:      weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT])
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting ethernet to tokenring.

mtayler@pilot.njin.net (Mark Tayler) writes:

>We currently have both token ring and ethernet on campus.
>We want to run TCP/IP on both platforms.  
>We also want to connect the token ring to the ethernet.
 
>The configuration is as follows:
 
>Campus wide ethernet with:
>	10baseT hubs connected by fiber optic.
 
>2 seperate token ring labs with:
>	IBM PS/2 Model 80 server for each connected to

Which Server-Software ? Novell ? Lan-Manager ? Vines ? NFS ?

>	16 IBM PS/2s 55sx on token ring, (each lab)
 
>I have the following Questions:
 
>1) Has anyone out there connected ethernet to token ring
>   and how did they do it.

Yes. Put an ethernet card in my Novell 3.11 file-server, installed
TCPIP routing - that's it.

>2) What additional hardware and software will I need.

Depends on what you already have. If your servers run Novell 3.11,
you don't need additional software. I don't know about other
systems in detail.
If you can't utilize your servers as routers, then you have several
alternatives:
- take an additional PC, put two cards in it and run one of the
  available routing packages on it - I've heard of ka9q and pcroute.
- dito, but purchase novells internet router. It comes with a
  Runtime-3.11 (so you need at least a 386) and should have the routing
  capabilities of the regular Netware 3.11.
- If you need high performance over the link - or have lots of money to spend -
  purchase a real router. CISCO is often mentioned here, but there are 
  others, too.

I'm sure I left some alternatives..

But however you solve that routing problem, be prepared, that your
favorite [free|public-domain|commercial] TCPIP client package refuses to run 
on token ring. There are approaches to solve such problems, but that depends
on the specific client software.

>3) Is there an inexpensive solution, perhaps using the model
>   80 servers as protocol converters, each one with a
>   token ring and ethernet card in them.

See above

Hope this helps

Regards

Christoph Weber-Fahr

-- 
  Christoph Weber-Fahr                  |  E-Mail:  weber@rhrk.uni-kl.de 
  Universitaet Kaiserslautern,  KIT/IVS |  S-Mail:  Postfach 3049
  Tel. 0631/205-3391                    |           D-6750 Kaiserslautern
--------------------------  My personal opinion only    ---------------------

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 May 1992 21:54:11 GMT
From:      dsbarr@ratfor.cs.psu.edu (Dave Barr)
To:        comp.protocols.tcp-ip
Subject:   RFC 1312 - Message Send Protocol II

	Simple question, has anyone written an implementation of this
protocol for a Unix system?  I need this protocol, not something "like"
it, unless there is clear documentation on the protocol used.
	I am looking to implement this on several platforms, and do not
wish to re-invent this new wheel.

--Dave
-- 
Dave Barr            | I'd rather be rich than stupid.
dsbarr@cs.psu.edu    | Do not taunt Happy Fun Ball.

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 May 1992 23:20:15 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: A class addresses (not assigned)

tjg01@thdhub.UUCP (Terry Gardner) writes:
>My company wants to use A class addresses that are not sanctioned
>by the keepers of Internet addresses. We have a B class address
>assigned to us, but the security folks don't want to have to
>deal with the subnet masks. 
>My question is: What are the
>ramifications of using an A class address that is not assigned to
>us by the Internet people, with a possible gateway to Internet?

	We've done screening network firewalls for customers with
exactly the configuration you're talking about. It works OK as long
as you don't want to talk to an "outside" machine that's already
on one of the illigitimate "inside" networks.

	The firewall is set up with static routes to subnets "inside"
that it wants to talk to, and a default route to "outside" - obviously
traffic will have problems with this, but in the configurations we
have done (remember, the customer is interested in security over
connectivity) all applications that want to talk to The Internet
go through forwarding servers that run on the gateway machine(s). FTP
and telnet and name service, and, of course mail, all work fine, but
there's an extra step involved in telnetting out of the "inside"
network (which is also good, since you can put authorization and
access control in at that point).

mjr.

mjr.

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 May 1992 23:22:05 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Civilizing rdump?  Cheap bridges?  How not to swamp an Ethernet


	I have a simple hack called "rmtread"/"rmtwrite" that copies
its standard input/output to/from a remote tape. It'd be easy to patch
a little delay into it, then tar, dump, cpio and all those could work
just fine, only slower.

mjr.

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      31 May 1992 01:45:33 GMT
From:      geoff@tyger.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1312 - Message Send Protocol II

Quoth dsbarr@cs.psu.edu (in <Bp33IC.CyG@cs.psu.edu>):
#
#	Simple question, has anyone written an implementation of this
#protocol for a Unix system?  I need this protocol, not something "like"
#it, unless there is clear documentation on the protocol used.
#	I am looking to implement this on several platforms, and do not
#wish to re-invent this new wheel.

Here you are.....


X-Sun-Data-Type: shell-script
X-Sun-Data-Description: shell-script
X-Sun-Data-Name: msp2unix.cshar
X-Sun-Content-Lines: 1474
X-Sun-Content-Length: 32702

#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh to create the files:
#	msgclnt.c
#	msgserv.c
# This archive created: Wed May 27 18:18:41 1992 by geoff, Sun Microsystems PC-NFS Engineering
#
#
export PATH; PATH=/bin:$PATH


if test -f msgclnt.c ; then
echo shar: will not over-write existing file msgclnt.c
else
echo shar: extracting msgclnt.c, 16741 characters
sed 's/^X//' > msgclnt.c <<'SHAR_EOF'
X/*
X * msgclnt.c
X *
X * Copyright (c) 1992 Sun Microsystems, Inc. 
X *
X * This is a client implementation of the Message Send protocol
X * defined in RFC1312. This implementation may be freely
X * copied, modified, and redistributed, provided that this
X * comment and the Sun Microsystems copyright are retained.
X * Anyone installing, modifying, or documenting this
X * software is advised to read the section in the RFC which
X * deals with security issues.
X */
X#include <sys/types.h>
X#include <sys/time.h>
X#ifdef SVR4
X#include <sys/select.h>
X#include <memory.h>
X#define bcopy(from, to, howmuch)	memcpy(to, from, howmuch)
X#endif
X#include <sys/socket.h>
X#include <sys/sockio.h>
X#include <netinet/in.h>
X#include <net/if.h>
X#include <arpa/inet.h>
X#include <netdb.h>
X#include <stdio.h>
X#include <string.h>
X#include <ctype.h>
X#include <time.h>
X
Xchar *prog;			/* points to program name for messages */
Xint debug = 0;
Xint verbose = 0;
Xchar *empty_arg = "";		/* used to encode an empty message part */
X
Xint msg_len = 0;		/* the cumulative length of the message */
Xchar msg[1024];			/* message assembly buffer */
X
X/*
X * types for all procedures. for ANSI standard C, these should
X * be edited into full-blown prototypes.
X */
Xvoid usage();
Xint main();
Xvoid assemble_message();
Xvoid do_line();
Xvoid tcp_msg();
Xvoid udp_msg();
Xvoid broadcast_msg();
Xvoid find_broadcast_addresses();
Xvoid filter();
X
Xextern char *getlogin();
Xextern char *ttyname();
X
X
Xvoid
Xusage()
X{
X	fprintf(stderr, "usage: %s [-t][-d][-v][-rN][-pN] recipient ['message']\n", prog);
X	fprintf(stderr, "  -t    - use TCP; default is UDP. (ignored for broadcasts)\n");
X	fprintf(stderr, "  -d    - turn on debugging (implies -v)\n");
X	fprintf(stderr, "  -v    - verbose mode\n");
X	fprintf(stderr, "  -rN   - UDP retransmissions (default: 3)\n");
X	fprintf(stderr, "  -pN   - use port N (default: 18)\n");
X	fprintf(stderr, "  recipient may have any of the following forms:\n");
X	fprintf(stderr, "   user           - broadcast for user at any host\n");
X	fprintf(stderr, "   user@host      - directed to user at given host\n");
X	fprintf(stderr, "   @host          - default dest. at given host\n");
X	fprintf(stderr, "   @              - default dest. on all hosts\n");
X	fprintf(stderr, "   user:term@host - user logged in to term on host\n");
X	fprintf(stderr, "   :term@host     - specified terminal on host\n");
X	fprintf(stderr, "   :all@host      - all terminals on given host\n");
X	fprintf(stderr, "   :all           - all terminals on all hosts\n");
X	fprintf(stderr, "If there is no message argument, ");
X	fprintf(stderr, "the message is read from standard input.\n");
X}
X
Xint
Xmain(argc, argv)
Xint argc;
Xchar *argv[];
X{
X
X	int	use_tcp = 0;
X	int	retries = 3;
X	short port = 0;
X	int broadcasting = 0;
X
X	char *recipient;
X	char *user;
X	char *term;
X	char *host;
X	char *msg_text;
X
X	struct sockaddr_in sin;
X	struct servent *sp;
X	struct hostent *hp;
X	struct netent *np;
X
X
X	prog = *argv++;
X	argc--;
X
X	/* process options:
X	 * -d (debug)
X	 * -t (use TCP)
X	 * -rN (set retransmission count)
X	 * -pN (use port N instead of 18)
X	 */
X
X	while(argc && *argv[0] == '-') {
X		(*argv)++;
X		switch (toupper(*argv[0])){
X			case 'D':
X				debug++;
X				verbose++;
X				break;
X			case 'V':
X				verbose++;
X				break;
X			case 'T':
X				use_tcp++;
X				break;
X			case 'R':
X				(*argv)++;
X				retries = atoi(*argv);
X				break;
X			case 'P':
X				(*argv)++;
X				port = atoi(*argv);
X				break;
X			default:
X				usage();
X				exit(1);
X				/*NOTREACHED*/
X		}
X		argv++;
X		argc--;
X	}
X	if((argc < 1) || (argc > 2)) {
X		usage();
X		exit(1);
X		/*NOTREACHED*/
X	}
X
X	/*
X	 * Rip apart the recipient field and set the user, term,
X	 * and host pointers.
X	 */
X	recipient = argv[0];
X
X	msg_text = argc == 2 ? argv[1] : NULL;
X
X	if(debug) printf("recipient is '%s'\n", recipient);
X
X	host = strchr(recipient, '@');
X	if(host == NULL)
X		host = empty_arg;
X	else
X		*host++ = '\0';
X
X	term = strchr(recipient, ':');
X	if(term == NULL)
X		term = empty_arg;
X	else
X		*term++ = '\0';
X	if(!strcmp(term, "all"))	/* external form is "all" */
X		strcpy(term, "*");		/* protocol uses "*" */
X
X	user = recipient;
X
X	if(debug) printf("user = '%s', term='%s', host = '%s'\n",
X		user, term, host);
X
X	broadcasting = (host[0] == '\0');
X
X	sin.sin_family = AF_INET;
X
X	/*
X	 * compute the port to use: consult /etc/services, but if not
X	 * found use 18 (from the RFC). the -pN option overrides
X	 */
X
X	if(port == 0) {
X		sp = getservbyname("message", (use_tcp ? "tcp" : "udp"));
X		if(sp)
X			sin.sin_port = sp->s_port;
X		else
X			sin.sin_port = htons(18);	/* from the RFC */
X	}
X	else
X		sin.sin_port = htons(port);
X
X 
X	if(debug) printf("using port %d\n", htons(sin.sin_port));
X
X	/*
X	 * check to see if we're broadcasting; if so, ignore use_tcp and
X	 * build a broadcast address. otherwise build an address for
X	 * the designated host
X	 */
X
X	if(broadcasting) {
X		if(use_tcp)
X			fprintf(stderr, "%s: broadcast requested, so -t is ignored\n", prog);
X		use_tcp = 0;
X	}
X	else {
X		hp = gethostbyname(host);
X		if(hp == NULL) {
X			/* XXX need to add stuff to handle dotted IP addresses */
X			fprintf(stderr, "%s: unknown host: %s\n", prog, host);
X			exit(2);
X		}
X		memcpy((char *)&sin.sin_addr, (char *)hp->h_addr, hp->h_length);
X	}
X
X	/*
X	 * now assemble the message. note that this procedure will only
X	 * return if the assembly is successful
X	 */
X	assemble_message(user, term, msg_text);
X
X	/*
X	 * if broadcast, invoke broadcast_msg
X	 */
X	if(broadcasting) {
X		broadcast_msg(&sin, retries);
X		exit(0);
X		/*NOTREACHED*/
X	}
X
X
X	/*
X	 * if requested, attempt to send message via TCP
X	 */
X	if(use_tcp)
X		tcp_msg(&sin);
X	/*
X	 * If tcp_msg returns, it means that it was unable to bind
X	 * to the port on the server. In this case, revert to UDP.
X	 */
X	udp_msg(&sin, retries);
X	exit(0);
X}
X
X/*
X * assemble_message assembles a complete message in the buffer
X * msg and stores the length in msg_len. Note that, as defined
X * by the RFC, the message buffer includes embedded nulls.
X */
X
Xvoid
Xassemble_message(user, term, msg_text)
Xchar *user;
Xchar *term;
Xchar *msg_text;
X{
X	char *cp;
X	int i;
X	int j;
X	char linebuff[256];
X	struct utmp *utp;
X	char *dp;
X
X	cp = msg;
X
X	*cp++ = 'B';	/* per RFC */
X	msg_len = 1;
X
X#define APPEND(s)	{strcpy(cp, s); j = strlen(s); cp += j; *cp++ = '\0'; msg_len += j + 1; }
X
X	filter(user);
X	APPEND(user);
X	filter(term);
X	APPEND(term);
X
X	if (msg_text)
X		do_line(msg_text, &cp, &msg_len);
X	else {
X		while(gets(linebuff) != NULL) {
X			do_line(linebuff, &cp, &msg_len);
X		}
X	}
X	
X	*cp++ = '\0';
X	msg_len++;
X
X	dp = getlogin();
X	if (dp == NULL) {
X		APPEND(empty_arg);
X	} else {
X		APPEND(dp);
X	}
X	if(debug) printf("sender username is '%s'\n", (dp ? dp : empty_arg));
X	dp = ttyname(2); /* check standard error */
X	if (dp == NULL) {
X		APPEND(empty_arg);
X	} else {
X		APPEND(dp);
X	}
X	if(debug) printf("sender terminal is '%s'\n", (dp ? dp : empty_arg));
X	
X	sprintf(linebuff, "%ld", time(NULL));
X	APPEND(linebuff);
X	if(debug) printf("cookie is '%s'\n", linebuff);
X
X	/*
X	 * In this version, we always generate an empty signature part
X	 */
X	if(debug) printf("signature is '%s'\n", empty_arg);
X	APPEND(empty_arg);	/* null signature */
X
X
X	if(debug) printf("total message length is %d\n", msg_len);
X	if(msg_len > 512) {
X		fprintf(stderr, "%s: message (inc. control fields) exceeds 512 byte limit\n", prog);
X		exit(2);
X	}
X}
X
Xvoid
Xdo_line(linebuff, cpp, msg_lenp)
Xchar *linebuff;
Xchar **cpp;
Xint *msg_lenp;
X{
X	int j;
X	char *cp = *cpp;
X	int msg_len = *msg_lenp;
X
X	filter(linebuff);
X	j = strlen(linebuff);
X	if((msg_len + j) > (512-28-3)) {
X		fprintf(stderr, "%s: message (inc. control fields) exceeds 512 byte limit\n", prog);
X		exit(2);
X		/*NOTREACHED*/
X	}
X	strcpy(cp, linebuff);
X	cp += j;
X	*cp++ = '\015';
X	*cp++ = '\012';
X	msg_len += j + 2;
X
X	*cpp = cp;
X	*msg_lenp = msg_len;
X}
X
X/*
X * tcp_msg(sp)
X *      sp points at a sockaddr_in which contains the
X *      port to be used.
X *
X * Send the assembled message using TCP. If the attempt is
X * successful, the program exits with a status of 0. If a client-
X * side error occurs (e.g. unable to open a socket) the program
X * exits with a positive non-zero status. If it proves impossible
X * to connect to the server, an error message is displayed and
X * the procedure returns. This allows the caller to retry using
X * UDP.
X */
X	 
Xvoid
Xtcp_msg (sp)
Xstruct sockaddr_in *sp;
X
X{
X	int	s;
X	int on = 1;
X	struct sockaddr_in sin;
X	char rcvbuf[256];
X	int rval;
X
Xif(debug) printf("invoked tcp_msg()\n");
X
X	if((s = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
X		fprintf(stderr, "%s: unable to open socket.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X
X	sin.sin_family = AF_INET;
X	sin.sin_addr.s_addr = htonl(INADDR_ANY);
X	sin.sin_port = htons(0);
X
X	if(bind(s, &sin, sizeof sin) < 0) {
X		fprintf(stderr, "%s: unable to set local socket address.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X
X	if(connect(s, sp, sizeof (*sp)) < 0) {
X		fprintf(stderr, "%s: unable to connect to TCP server.\n", 
X			prog);
X		perror("Reason");
X		return;
X		/*NOTREACHED*/
X	}
X
X	if(verbose)
X		printf("sending message...\n");
X	if(write(s, msg, msg_len) < 0) {
X		fprintf(stderr, "%s: unable to send message.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X		/*
X		 * wait for reply
X		 */
X	rval = read(s, rcvbuf, 256);
X	if(rval < 1) {
X		fprintf(stderr, "%s: no reply received.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X	rcvbuf[rval] = '\0';
X	if(debug) printf("reply:'%s'\n", rcvbuf);
X	if(rcvbuf[0] == '+') {
X		if(verbose) printf("message delivered to recipient\n");
X		exit(0);
X		/*NOTREACHED*/
X	} else {
X		if(verbose) printf("message not delivered\n");
X		exit(5);
X		/*NOTREACHED*/
X	}
X}
X
X/*
X * udp_msg(sp, r)
X *      sp points at a sockaddr_in which contains the
X *      port to be used.
X *      r is the retry count to be used.
X *
X * Send the assembled message to a specific destination using UDP.
X * This procedure will never return - it always exits with an
X * appropriate status code.
X */
X
Xvoid
Xudp_msg (sp, r)
Xstruct sockaddr_in *sp;
Xint r;
X
X{
X	int	s;
X	int on = 1;
X	struct sockaddr_in sin;
X	fd_set ready;
X	struct timeval to;
X	char rcvbuf[256];
X	int rval;
X
Xif(debug) printf("invoked udp_msg(...,%d)\n", r);
X
X	if((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
X		fprintf(stderr, "%s: unable to open socket.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X
X	sin.sin_family = AF_INET;
X	sin.sin_addr.s_addr = htonl(INADDR_ANY);
X	sin.sin_port = htons(0);
X
X	if(bind(s, &sin, sizeof sin) < 0) {
X		fprintf(stderr, "%s: unable to set local socket address.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X	while(r--) {
X		if(verbose)
X			printf("sending message...\n");
X		if(sendto(s, msg, msg_len, 0, sp, sizeof(*sp)) < 0) {
X			fprintf(stderr, "%s: unable to send message.\n", prog);
X			perror("Reason");
X			exit(3);
X		}
X		if(r) {
X			/*
X			 * wait for reply or timeout
X			 */
X			to.tv_sec = 2;
X			to.tv_usec = 0;
X			FD_ZERO(&ready);
X			FD_SET(s, &ready);
X			rval = select(20, &ready, (fd_set *)0, (fd_set *)0, &to);
X			if(rval < 0)
X			 	fprintf(stderr, "%s: interrupt\n", prog);
X			if(rval == 1) {
X			/* XXX to do  : read and decode result */
X				if(verbose)
X					printf("%s: message receipt acknowledgement received\n", prog);
X				break;
X			}
X			/*
X			 * falling through, must be interrupt or timeout
X			 */
X		}
X	}
X	if(debug) printf("closing and exiting\n");
X	close(s);
X	exit(0);
X	/*NOTREACHED*/
X}
X
X/*
X * find_broadcast_addresses
X *
X * This procedure is used by broadcast_msg to determine all of the
X * network interfaces configred on the local system, so that the
X * message can be broadcast over each of them. This logic is derived
X * from the SunOS documentation, and has also been tested on SVR4:
X * anyone porting this program to significantly different systems
X * should check this area carefully.
X *
X * The procedure uses the SIOCGIFCONF ioctl to retrieve the
X * interfaces. For each one, it retrieves the flags via SIOCGIFFLAGS.
X * For a point-to-point interface, the peer address is fetched using
X * SIOCGIFDSTADDR. For a broadcast inteface, the broadcast address
X * is obtained using SIOCGIFBRDADDR. The addresses are accumulated
X * in the array if_a, and if_n holds the count of addresses found.
X */
X
X#define INTERFACES 32
Xint if_n;
Xstruct sockaddr_in if_a[INTERFACES];
X
Xvoid
Xfind_broadcast_addresses(s)
Xint s;
X{
X	struct ifconf ifc;
X	struct ifreq *ifr;
X	char buf[4096];
X	int n;
X
X	if_n = 0;
X
X	ifc.ifc_len = sizeof buf;
X	ifc.ifc_buf = buf;
X
X	if(ioctl(s, SIOCGIFCONF, (char *)&ifc) < 0) {
X		fprintf(stderr, "%s: SIOCGIFCONF failed.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X	ifr = ifc.ifc_req;
X	n = ifc.ifc_len/sizeof(struct ifreq);
X	if(debug)
X		printf("checking %d interfaces returned by SIOCGIFCONF...\n",
X			n);
X
X	for (; --n >= 0; ifr++) {
X		if(ifr->ifr_addr.sa_family != AF_INET)
X			continue;
X		if(ioctl(s, SIOCGIFFLAGS, (char *)ifr) < 0){
X			perror("SIOCGIFFLAGS");
X			continue;
X		}
X		if((ifr->ifr_flags & IFF_UP) == 0 ||
X		   (ifr->ifr_flags & IFF_LOOPBACK) ||
X		   (ifr->ifr_flags & (IFF_BROADCAST|IFF_POINTOPOINT)) == 0)
X			continue;
X		if(ifr->ifr_flags & IFF_POINTOPOINT) {
X			if(ioctl(s, SIOCGIFDSTADDR, (char *)ifr) < 0) {
X				perror("SIOCGIFDSTADDR");
X				continue;
X			}
X			bcopy((char *)&ifr->ifr_dstaddr, (char *)&if_a[if_n++],
X				sizeof ifr->ifr_dstaddr);
X		} else if(ifr->ifr_flags & IFF_BROADCAST) {
X			if(ioctl(s, SIOCGIFBRDADDR, (char *)ifr) < 0) {
X				perror("SIOCGIFBRDADDR");
X				continue;
X			}
X			bcopy((char *)&ifr->ifr_broadaddr, (char *)&if_a[if_n++],
X				sizeof ifr->ifr_broadaddr);
X		}
X	}
X	if(debug)
X		printf("found %d interfaces\n", if_n);	
X	if(if_n == 0) {
X		fprintf(stderr, "%s: no applicable network interfaces\n", prog);
X		exit(3);
X		/*NOTREACHED*/
X	} 
X}
X
X/*
X * broadcast_msg(sp, r)
X *      sp points at a sockaddr_in which contains the
X *      port to be used.
X *      r is the retry count to be used.
X *
X * Broadcast the message 'r' times over all network interfaces.
X * This procedure never returns: it will eventually exit with a suitable
X * status code. Broadcasts are sent at intervals of 2 seconds.
X * (It might be advisable to make this parameter adjustable.)
X *
X * Normally a broadcast message will not elicit a reply. However
X * if it does, we assume that we've reached the right destination
X * and we quit without further ado.
X */
X
Xvoid
Xbroadcast_msg (sp, r)
Xstruct sockaddr_in *sp;
Xint r;
X
X{
X	int	s;
X	int on = 1;
X	struct sockaddr_in sin;
X	fd_set ready;
X	struct timeval to;
X	char rcvbuf[256];
X	int rval;
X	int i;
X
Xif(debug) printf("invoked broadcast_msg(...,%d)\n", r);
X
X	if((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
X		fprintf(stderr, "%s: unable to open socket.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X
X	i = 1;
X	if(setsockopt(s, SOL_SOCKET, SO_BROADCAST, &i, sizeof i) < 0) {
X		fprintf(stderr, "%s: unable to configure socket for broadcast.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X
X	find_broadcast_addresses(s);
X
X	sin.sin_family = AF_INET;
X	sin.sin_addr.s_addr = htonl(INADDR_ANY);
X	sin.sin_port = htons(0);
X
X	if(bind(s, (struct sockaddr *)&sin, sizeof sin) < 0) {
X		fprintf(stderr, "%s: unable to set local socket address.\n", prog);
X		perror("Reason");
X		exit(3);
X	}
X	while(r--) {
X		for (i = 0; i < if_n; i++){
X			if_a[i].sin_port = sp->sin_port;
X			if(verbose) printf("sending message to %s\n",
X				inet_ntoa(if_a[i].sin_addr));
X			if(sendto(s, msg, msg_len, 0, &(if_a[i]),
X			   sizeof if_a[i]) < 0) {
X				fprintf(stderr, "%s: unable to send message.\n", prog);
X				perror("Reason");
X				exit(3);
X			}
X		}
X		if(r) {
X			/*
X			 * wait for reply or timeout
X			 */
X			to.tv_sec = 2;
X			to.tv_usec = 0;
X			FD_ZERO(&ready);
X			FD_SET(s, &ready);
X			rval = select(20, &ready, (fd_set *)0, (fd_set *)0, &to);
X			if(rval < 0)
X			 	fprintf(stderr, "%s: interrupt\n", prog);
X			if(rval == 1) {
X			/* XXX to do  : read and decode result */
X				if(verbose)
X					printf("%s: message receipt acknowledgement received\n", prog);
X				break;
X			}
X			/*
X			 * falling through, must be interrupt or timeout
X			 */
X		}
X	}
X	if(debug) printf("closing and exiting\n");
X	close(s);
X	exit(0);
X	/*NOTREACHED*/
X}
X
X/*
X * As noted in the RFC, it is important to filter out control
X * chracters and suchlike, since there may exist terminals
X * which will behave in bizarre and security-violating ways
X * if presented with certain control code sequences. The
X * server will also be filtering messages, but it is incumbent
X * upon a well-written client implementation to send only "clean"
X * messages. After all, there may exist servers which will reject
X * any message which does not filter cleanly.
X *
X * It is an open question as to how the filtering should be done.
X * One approach might be to squeeze out any invalid characters
X * silently. This would make debugging difficult. This implementation
X * replaces all non-printable characters with '?' characters.
X */
X
Xvoid
Xfilter(text)
Xchar *text;
X{
X	while (*text) {
X		if(!isprint(*text) && !isspace(*text))
X			*text = '?';
X		text++;
X	}
X}
X
SHAR_EOF
len=`wc -c < msgclnt.c`
if test $len != 16741 ; then
echo shar: msgclnt.c was $len bytes long, should have been 16741
fi
fi # end of overwriting check

if test -f msgserv.c ; then
echo shar: will not over-write existing file msgserv.c
else
echo shar: extracting msgserv.c, 13475 characters
sed 's/^X//' > msgserv.c <<'SHAR_EOF'
X/*
X * msgserv.c
X *
X * Copyright (c) 1992 Sun Microsystems, Inc. 
X *
X * This is a server implementation of the Message Send protocol
X * defined in RFC1312. This implementation may be freely
X * copied, modified, and redistributed, provided that this
X * comment and the Sun Microsystems copyright are retained.
X * Anyone installing, modifying, or documenting this
X * software is advised to read the section in the RFC which
X * deals with security issues.
X */
X#include <sys/types.h>
X#include <sys/time.h>
X#include <sys/stat.h>
X#include <utmp.h>
X#ifdef SVR4
X#include <sys/select.h>
X#endif
X#include <sys/socket.h>
X#ifndef SVR4
X#include <sys/ttycom.h>
X#endif
X#include <sys/wait.h>
X#include <sys/sockio.h>
X#include <netinet/in.h>
X#include <net/if.h>
X#include <arpa/inet.h>
X#include <netdb.h>
X#include <stdio.h>
X#include <fcntl.h>
X#include <string.h>
X#include <signal.h>
X#include <ctype.h>
X#include <time.h>
X#include <memory.h>
X
Xchar *prog;
Xint debug = 0;
Xint verbose = 0;
Xint use_console = 0;	/* XXX currently unused */
Xchar *empty_arg = "";
X
Xchar * recipient;
Xchar * recip_term;
Xchar * sender;
Xchar * sender_term;
Xchar * msg_text;
Xchar * cookie;
Xchar * signature;
X
Xchar console[] = "/dev/console";
X/* utmp globals */
Xstruct utmp utmp;
XFILE *utmp_file;	/* stream for utmp, also non-0 indicates valid entry */
X
X
X/*
X * types for all procedures
X */
Xvoid usage();
Xvoid handle_udp();
Xvoid handle_tcp();
Xint main();
X#ifdef SVR4
Xvoid reaper();
X#else
Xint reaper();
X#endif
Xvoid udp_ack();
Xvoid ack();
Xvoid nak();
Xchar *deliver();
Xint rip_apart_message();
Xint check_cache();
Xvoid filter();
Xchar *do_cmd();
Xchar * first_utmp_entry();
Xvoid next_utmp_entry();
Xchar *send_to_term();
X
X
Xvoid
Xusage()
X{
X	fprintf(stderr, "usage: %s [-d][-pN]\n", prog);
X/* XXX	fprintf(stderr, "usage: %s [-d][-pN][-c]\n", prog); */
X	fprintf(stderr, "  -d    - turn on debugging\n");
X	fprintf(stderr, "  -pN   - use port N (default: 18)\n");
X/* XXX	fprintf(stderr, "  -c    - ignore terminal and use console\n"); */
X
X}
X
Xint
Xmain(argc, argv)
Xint argc;
Xchar *argv[];
X{
X
X	short port = 0;
X	int tcpsock1;
X	int tcpsock2;
X	int udpsock;
X	int i;
X	fd_set ready;
X	int nfds = getdtablesize();
X
X	struct sockaddr_in sin;
X	struct servent *sp;
X
X
X	prog = *argv++;
X	argc--;
X
X	/* process options:
X	 * -d (debug)
X	 * -pN (use port N instead of 18)
X	 */
X
X	while(argc && *argv[0] == '-') {
X		(*argv)++;
X		switch (toupper(*argv[0])){
X			case 'D':
X				debug++;
X				verbose++;
X				break;
X			case 'C':
X				use_console++;
X				break;
X			case 'P':
X				(*argv)++;
X				port = atoi(*argv);
X				break;
X			default:
X				usage();
X				exit(1);
X				/*NOTREACHED*/
X		}
X		argv++;
X		argc--;
X	}
X	if(argc != 0) {
X		usage();
X		exit(1);
X		/*NOTREACHED*/
X	}
X
X	if(!debug) {
X		if(fork())
X			exit(0);
X		for(i = nfds-1; i >= 0; --i)
X			close(i);
X		(void)open("/dev/null", O_RDWR);
X		dup2(0, 1);
X		dup2(0, 2);
X#ifdef SVR4
X		setsid();
X#else
X/* NB - setsid() also works in SunOS but maybe not other BSD-derived code */
X		i = open("/dev/tty", O_RDWR);
X		if(i >= 0){
X			ioctl(i, TIOCNOTTY, 0);
X			close(i);
X		}
X#endif
X/* XXX todo - add code to use SYSLOG if we're not in debug mode */
X	}
X
X	signal(SIGCHLD, reaper);
X
X	sin.sin_family = AF_INET;
X
X	/*
X	 * compute the port to use: consult /etc/services, but if not
X	 * found use 18 (from the RFC). the -pN option overrides
X	 */
X
X	if(port == 0) {
X		sp = getservbyname("message", "udp");
X		if(sp)
X			sin.sin_port = sp->s_port;
X		else
X			sin.sin_port = htons(18);	/* from the RFC */
X	}
X	else
X		sin.sin_port = htons(port);
X
X	sin.sin_addr.s_addr = INADDR_ANY;
X
X	if(debug) printf("%s: using port %d\n", prog, htons(sin.sin_port));
X
X
X
X	tcpsock1 = socket(AF_INET, SOCK_STREAM, 0);
X	if(bind(tcpsock1, (struct sockaddr *)&sin, sizeof sin) < 0) {
X		if(debug) perror("bind (TCP)");
X		exit(99); /* XXX */
X	}
X	listen(tcpsock1, 5);
X
X	udpsock = socket(AF_INET, SOCK_DGRAM, 0);
X	if(bind(udpsock, (struct sockaddr *)&sin, sizeof sin) < 0) {
X		if(debug) perror("bind (UDP)");
X		exit(99); /* XXX */
X	}
X
X	if(debug) printf("entering main loop...\n");
X	while(1) {
X		FD_ZERO(&ready);
X		FD_SET(udpsock, &ready);
X		FD_SET(tcpsock1, &ready);
X		i = select(nfds, &ready, (fd_set *)0, (fd_set *)0, (struct timeval *)0);
X		if(debug) printf("----------------------------------------------------------\nselect returned %d\n", i);
X		if(i <= 0) {
X			if(debug)perror("select");
X			continue;
X		}
X		if(FD_ISSET(udpsock, &ready))
X			handle_udp(udpsock);
X		else if(FD_ISSET(tcpsock1, &ready)) {
X			tcpsock2 = accept(tcpsock1, (struct sockaddr *)0,
X				(int *)0);
X
X			if(debug)
X				printf("forking....\n");
X
X			if(fork() == 0) {
X				close(tcpsock1);
X				close(udpsock);
X				handle_tcp(tcpsock2);
X				exit(0);
X			}
X		}
X	}
X}
X
X#define CACHE_ENTRIES 32
X
Xstruct mc_entry {
X	struct sockaddr_in mc_addr;
X	char mc_cookie[48];
X};
X
Xint mc_used = 0;
Xint mc_next = 0;
Xstruct mc_entry mcache[CACHE_ENTRIES];
X
Xint
Xcheck_cache(cookie, addrp)
Xchar *cookie;
Xstruct sockaddr_in *addrp;
X{
X	int i;
X	if(mc_used) {
X		for (i = 0; i < mc_used; i++) {
X			if(!strcmp(cookie, mcache[i].mc_cookie) &&
X			   !memcmp((char *)addrp, (char *)&mcache[i].mc_addr,
X				sizeof(*addrp)))
X				return(1);
X		}
X	}
X	memcpy((char *)&mcache[mc_next].mc_addr, (char *)addrp, sizeof(*addrp));
X	strcpy(mcache[mc_next].mc_cookie, cookie);
X
X	mc_next++;
X	if(mc_next > mc_used) mc_used = mc_next;
X	mc_next = mc_next % CACHE_ENTRIES;
X	return(0);
X}
X
Xvoid
Xhandle_udp(s)
Xint s;
X{
X	char buff[1024];
X	int buflen;
X	struct sockaddr_in from;
X	int fromlen;
X	char *txt;
X
X	fromlen = sizeof (from);
X
X	if(debug) printf("%s: udp msg received\n", prog);
X
X	buflen = recvfrom(s, buff, 1024, 0,
X		 (struct sockaddr *)&from,  &fromlen);
X
X	if(buflen < 0) {
X		perror("recvfrom");
X		return;
X	}
X	if(rip_apart_message(buff, buflen)) {
X		fprintf(stderr, "%s: malformed message\n", prog);
X		return;
X	}
X	if(check_cache(cookie, &from)) {
X		if(debug) printf("duplicate message\n");
X		return;
X	}
X
X	if(debug)
X		printf("forking....\n");
X
X	if(!debug) {
X		if(fork() != 0)
X			return;
X	}
X
X	if((txt = deliver()) == NULL && *recipient) {
X		udp_ack(s, &from, "OK");
X	}
X	if(!debug)
X		exit(0);
X}
X
Xvoid
Xhandle_tcp(s)
Xint s;
X{
X	char buff[1024];
X	int buflen;
X	struct sockaddr_in peer;
X	int peerlen;
X	char *txt;
X
X	if(debug) printf("%s: tcp msg received\n", prog);
X
X	peerlen = sizeof peer;
X	if(getpeername(s, &peer, &peerlen) < 0) {
X		perror("getpeername");
X		exit(99);
X	}
X
X	buflen = read(s, buff, 1024);
X	if(buflen < 0) {
X		perror("read");
X		nak(s, "Read error");
X		return;
X	}
X	if(rip_apart_message(buff, buflen)) {
X		fprintf(stderr, "%s: malformed message\n", prog);
X		nak(s, "Message format error");
X		return;
X	}
X	if((txt = deliver()) != NULL) {
X#ifdef notyet
X		nak(s, txt);
X		return;
X#endif
X	}
X	ack(s, "OK");
X}
X
X
X/* Note the type difference here */
X
X#ifdef SVR4
Xvoid
Xreaper()
X{
X	int i, j;
X	i = wait(&j);
X	return;
X}
X#else
Xint
Xreaper()
X{
X	union wait status;
X	while(wait3(&status, WNOHANG, 0) > 0) continue;
X	return(0);
X}
X#endif
X
Xvoid udp_ack(s, to, msg)
Xint s;
Xstruct sockaddr_in *to;
Xchar *msg;
X{
X	char buff[128];
X	if(debug)
X		printf("sending ack\n");
X	sprintf(buff, "+%s", msg);
X	(void)sendto(s, buff, strlen(buff) + 1, 0,
X		(struct sockaddr *)to, sizeof (*to));
X}
X
Xvoid ack(s, msg)
Xint s;
Xchar *msg;
X{
X	char buff[128];
X	if(debug)
X		printf("sending ack\n");
X	sprintf(buff, "+%s", msg);
X	(void)write(s, buff, strlen(buff) + 1);
X}
X
Xvoid nak(s, msg)
Xint s;
Xchar *msg;
X{
X	char buff[128];
X	if(debug)
X		printf("sending nak\n");
X	sprintf(buff, "-%s", msg);
X	(void)write(s, buff, strlen(buff) + 1);
X}
X
Xint
Xrip_apart_message(buff, buflen)
Xchar *buff;
Xint buflen;
X{
X	char *cp1;
X	char *cp2;
X	char *lim;
X
X
X	recipient = NULL;
X	recip_term = NULL;
X	sender = NULL;
X	sender_term = NULL;
X	msg_text = NULL;
X	cookie = NULL;
X	signature = NULL;
X
X	if(buff[0] != 'B')
X		return(1);
X
X	lim = &buff[buflen];
X
X	cp1 = buff;
X	cp1++;				/* point at recipient */
X
X/*
X * Gather up recipient
X */
X	cp2 = cp1;
X	while (*cp2 && cp2 < lim)
X		cp2++;
X	if(cp2 >= lim) return(1);	/* over-length */
X	recipient = cp1;
X	cp1 = cp2;
X	cp1++;
X	if(debug)
X		printf("recipient   = '%s'\n", recipient);
X
X
X
X/*
X * Gather up recip_term
X */
X	cp2 = cp1;
X	while (*cp2 && cp2 < lim)
X		cp2++;
X	if(cp2 >= lim) return(1);	/* over-length */
X	recip_term = cp1;
X
X	/* toss preceding "/dev/" if any */
X	if (strncmp(recip_term, "/dev/", strlen("/dev/")) == 0)
X		recip_term += strlen("/dev/");
X	cp1 = cp2;
X	cp1++;
X	if(debug)
X		printf("recip_term  = '%s'\n", recip_term);
X
X
X/*
X * Gather up msg_text
X */
X	cp2 = cp1;
X	while (*cp2 && cp2 < lim)
X		cp2++;
X	if(cp2 >= lim) return(1);	/* over-length */
X	msg_text = cp1;
X	cp1 = cp2;
X	cp1++;
X	if(debug)
X		printf("msg_text    = '%s'\n", msg_text);
X
X
X/*
X * Gather up sender
X */
X	cp2 = cp1;
X	while (*cp2 && cp2 < lim)
X		cp2++;
X	if(cp2 >= lim) return(1);	/* over-length */
X	sender = cp1;
X	cp1 = cp2;
X	cp1++;
X	if(debug)
X		printf("sender      = '%s'\n", sender);
X
X
X/*
X * Gather up sender_term
X */
X	cp2 = cp1;
X	while (*cp2 && cp2 < lim)
X		cp2++;
X	if(cp2 >= lim) return(1);	/* over-length */
X	sender_term = cp1;
X	cp1 = cp2;
X	cp1++;
X	if(debug)
X		printf("sender_term = '%s'\n", sender_term);
X
X
X/*
X * Gather up cookie
X */
X	cp2 = cp1;
X	while (*cp2 && cp2 < lim)
X		cp2++;
X	if(cp2 >= lim) return(1);	/* over-length */
X	cookie = cp1;
X	cp1 = cp2;
X	cp1++;
X	if(debug)
X		printf("cookie      = '%s'\n", cookie);
X
X/*
X * Gather up signature
X */
X	cp2 = cp1;
X	while (*cp2 && cp2 < lim)
X		cp2++;
X	if(cp2 >= lim) return(1);	/* over-length */
X	signature = cp1;
X	cp1 = cp2;
X	cp1++;
X	if(debug)
X		printf("signature   = '%s'\n", signature);
X
X	return(0);
X}
X
X
X/*
X * delivers the message; returns NULL if OK, otherwise
X * a string describing the problem
X */	
Xchar *deliver()
X{
X	char *cp;
X	int only_one;
X	char *retval;
X
X	while(cp = strchr(msg_text, '\015'))
X		*cp = ' ';
X
X	filter(msg_text);
X	if(debug) printf("delivering message....\n");
X
X	/* set only_one to false only if recip_term is "*" */
X	only_one = 1;
X	if (strcmp(recip_term, "*") == 0) {
X		only_one = 0;
X	}
X
X	/* go through utmp entries, sending to appropriate ones */
X	if (retval = first_utmp_entry())
X		return(retval);
X
X	do {
X		if (debug) printf("evaluating utmp entry %s %s...\n",
X			utmp.ut_name, utmp.ut_line);
X		/* check for wrong recipient */
X		if (*recipient) {
X			if (strncmp(recipient, utmp.ut_name,
X					sizeof(utmp.ut_name))) {
X				continue;
X			}
X		}
X		else {
X			/* no recipient; if no term force console */
X			if (*recip_term == '\0') {
X				if (strncmp("console", utmp.ut_line,
X						sizeof(utmp.ut_line))) {
X					/* nope, wrong term */
X					continue;
X				}
X			}
X		}
X
X		/* check for wrong term */
X		if (*recip_term) {
X			/* specific term or "*" */
X			if (strcmp(recip_term, "*")) {
X				/* specific term */
X				if (strncmp(recip_term, utmp.ut_line,
X						sizeof(utmp.ut_line))) {
X					/* nope, wrong term */
X					continue;
X				}
X			}
X		}
X
X		/* passed all tests, send it */
X		retval = send_to_term(utmp.ut_line);
X
X		/* see if once is enough */
X		if (only_one && (retval == NULL))
X			break;
X
X	} while (next_utmp_entry(), utmp_file);	/* keep going if more entries */
X	
X	return(NULL);
X}
X
X/*
X * first_utmp_entry
X *
X * opens utmp, calls next_utmp_entry and returns NULL if open is successful;
X * returns error string if open fails.
X */
Xchar *
Xfirst_utmp_entry()
X{
X	memset((char *) &utmp, 0, sizeof(utmp));
X	utmp_file = fopen("/etc/utmp", "r");
X	if(utmp_file == NULL) {
X		perror("fopen /etc/utmp");
X		return("unable to open /etc/utmp\n");
X	}
X	next_utmp_entry();
X	return NULL;
X}
X
X/*
X * next_utmp_entry
X *
X * sets up next utmp entry with utmp_ok != 0,
X * closes file and utmp_ok == 0 if none.
X */
Xvoid
Xnext_utmp_entry()
X{
X	while (fread((char *) &utmp, sizeof(utmp), 1, utmp_file) == 1) {
X		if (*utmp.ut_line && *utmp.ut_name) {
X			return;		/* utmp_file is non-NULL */
X		}
X	}
X	/* if we get here, we're at eof; close & zero utmp_file */
X	(void) fclose(utmp_file);
X	utmp_file = NULL;	/* indicates no more entries */
X}
X
Xchar *
Xsend_to_term(term)
X	char *term;
X{
X	/*
X	 * write to specific terminal if any, else console
X	 */
X	char device[32];
X	struct stat statbuf;
X	int rc;
X	FILE *stream;
X	time_t aclock;
X
X	sprintf(device, "/dev/%s", term);
X	if (stat(device, &statbuf)) {
X		perror("stat");
X		return("unable to stat %s", device);
X	}
X	
X	if (! (statbuf.st_mode & (S_IWGRP | S_IWOTH))) {
X		if (debug) printf("won't write to %s because mode is %o\n",
X			device, statbuf.st_mode);
X		return("won't write because of mode");
X	}
X
X	stream = fopen(device, "w");
X	if(stream == NULL) {
X		perror("fopen");
X		return("unable to write to %s", device);
X	}
X	time(&aclock);
X	if(debug) printf("writing to %s\n", device);
X	fprintf(stream,
X		"\7\n---------\nConsole message from %s on %s%s---------\n",
X		sender, asctime(localtime(&aclock)), msg_text);
X	rc = fclose(stream);
X	if (rc) {
X		perror("fclose");
X		return("unable to close %s", device);
X	}
X	if(debug) printf("delivery successful\n");
X	return NULL;
X}
X
X/*
X * As noted in the RFC, it is important to filter out control
X * chracters and suchlike, since there may exist terminals
X * which will behave in bizarre and security-violating ways
X * if presented with certain control code sequences. The
X * client may also be filtering messages, but it is incumbent
X * upon a well-written server implementation not to rely on being
X * sent only "clean" messages.
X *
X * It is an open question as to how the filtering should be done.
X * One approach might be to squeeze out any invalid characters
X * silently. This would make debugging difficult. This implementation
X * replaces all non-printable characters with '?' characters.
X */
X
Xvoid
Xfilter(text)
Xchar *text;
X{
X	while (*text) {
X		if(!isprint(*text) && !isspace(*text))
X			*text = '?';
X		text++;
X	}
X}
SHAR_EOF
len=`wc -c < msgserv.c`
if test $len != 13475 ; then
echo shar: msgserv.c was $len bytes long, should have been 13475
fi
fi # end of overwriting check

exit 0
#	End of shell archive

---------------------------------------+--------------------------------------
     Geoff Arnold, PC-NFS architect    | If you're in the New England area, I
      (geoff.arnold@East.Sun.COM)      | hope that I'll see you at "From All
SunSelect, a Sun Microsystems Business | Walks Of Life" in Boston on 5/31.

END OF DOCUMENT