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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Apr 1992 22:02:46 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        alt.wais,alt.cd-rom,comp.ai,comp.multimedia,comp.protocols.tcp-ip
Subject:   current.cites - Library Technology Watch newsletter

This newsletter is now available for anonymous FTP (from a.cni.org)
and in a WAIS server noted below.  Current issues are sent to the
PACS-L mailing list, which is available on finer news sites as
"bit.listserv.pacs-l".

(:source 
   :version  3 
   :database-name "current.cites"
   :ip-name "wais.cic.net"
   :tcp-port 210
   :cost 0.00 
   :cost-unit :free 
   :maintainer "emv@wais.cic.net"
   :description "

Date: Wed, 1 Apr 92 11:04:04 PST
From: rtennant@library.Berkeley.EDU (Roy Tennant)
Subject: Current Cites "charter"

* * * *   CURRENT CITES  * * * *                        
                                                                              
Current Cites is a monthly publication of the Library Technology Watch        
Program -- The Library, University of California at Berkeley.                  
 
                                                                             
Over 30 journals in librarianship and computer technology are scanned
for selected articles on electronic publishing, optical disk
technologies, computer networks and networking, information transfer,
expert systems and artificial intelligence, and hypermedia and
multimedia.  Brief annotations accompany most of the citations.

The Library Technology Watch Program was created to increase the
technical knowledge of Library staff, optimize staff time devoted to
learning about technical issues, and monitor the changing electronic
environment as it applies to library systems and services. Participants
include Teri Rinne, David Robison, Vivienne Roumani, Lisa Rowlison,
Mark Takaro, and Roy Tennant, all of the University of California,
Berkeley Library.

The Editor of Current Cites is David F. W. Robison, who can be reached
at drobison@library.berkeley.edu or drobison@ucblibrar.bitnet. If you
would like more information about the Library Technology Watch Program,
contact Roy Tennant, The Library, 130 Doe, University of California,
Berkeley, CA 94720 or rtennant@library.berkeley.edu, or
rtennant@ucblibra.bitnet.

"
)

--
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
      MSEN Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 741 1120

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 92 15:03:26 EST
From:      spe@icf.hrb.com (Steven P. Eberly)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc,comp.unix.questions
Subject:   TCP socket questions (SUNOS)

I have a couple socket programming questions (SUNOS 4.1 environment):


The BSD "select" and SYS5 "poll" can be setup to return when a socket or
TLI endpoint is ready for writing. Does this mean that the TCP send buffer
is empty or that at least one byte can be written to it?

The number of bytes in the TCP receive buffer can be read using ioctl, can
the number of bytes in the TCP send buffer be check? Is there a way to
know when all data in the TCP send buffer has been successfully sent,
without a user level ack?

Is there a method to flush the TCP transmit and receive buffers?

It appears as though the TCP keep-alive does not start until after a large
period of inactivity. What are the time value(s) for keep-alive, are they
configurable on a socket-by-socket or only a system wide basis?

What happens if keep-alive fails, ... signal?

-- 
   |				Steve Eberly
 --+--				spe@icf.hrb.com
   |	
   |	

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Apr 1992 16:05:52 GMT
From:      Edward Vielmetti <emv@msen.com>
To:        news.announce.newgroups,news.groups,alt.gopher,alt.wais,comp.protocols.tcp-ip,bit.listserv.cwis-l
Subject:   RFD:  comp.infosystems.gopher

This is a request for discussion and a proposal for a new newsgroup,
"comp.infosystems.gopher", to replace the existing group "alt.gopher".

For more information see alt.gopher or look at the distribution on
boombox.micro.umn.edu:/pub/gopher/.  There is a demonstration system
which you can connect to by telnetting to 
	consultant.micro.umn.edu
and logging in as "gopher"; the services there are also available as a
native application for Macs, PCs, NeXT machines, VMS, IBM mainframes,
X Windows, and of course a Unix shell.  

Gopher is a distributed information system; menus within a gopher 
can be made up of resources on the local system, on other gophers,
or even to other non-gopher systems via gateways.  There are front
ends in place for telnet, WAIS, finger, FTP, archie, and other internet
resources.  Building your own gopher is as easy as making a few links
to other systems that you like and putting some ordinary text files
out in a public area.  

This is *not* a call for votes; Usenet protocol suggests about a month's
worth of discussion to make sure that the name is right and to get
people aware that there's something going on.  If you want to discuss
substantive matters the group alt.gopher is ready there to take them.
On the other hand if you want to argue about names, that's what news.groups
is for.  (This name was suggested by the reaction to the 
"comp.infosystems.wais" vote that's in progress; WAIS and gopher fill
a similar sort of need on the net so it seems reasonable to put them
close together in the hierarchy.)  When a real call for votes is
issued, you will know about it.
-- 
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
      MSEN Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 741 1120

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 92 02:49:21 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Telnet option codes

In the process of adding telnet client support to a locally developed
application I have com across a few option codes not defined in my telnet.h.
Can anyone tell me what option codes 31, 33, 35, and 36 are?

Frank.
--
___________________________________________________________________
Frank I. Reiter                Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 92 03:47:08 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Telnet ECHO option

In the course of adding telnet client ability to another application I've
discovered that the telnetd at a local IRIX system sends out a DO ECHO request.

I can understand that a telnet client would want characters echoed back to it
(as indeed mine does), but I cannot udnerstand why a telnetd would want a
telnet client to echo back everything it receives.  At present we reply WONT
ECHO.

Can anyone shed any light on this?

Frank.
--
___________________________________________________________________
Frank I. Reiter                Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 92 05:08:15 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip, "Frank I. Reiter" <Frank@mindlink.bc.ca>
Subject:   re: Telnet ECHO option

Indeed.  I've been fighting this battle for a long time -- 15 years in
fact.  It is foolish and ridiculous for Telnet servers to send IAC DO
ECHO and for Telnet clients to send IAC WILL ECHO, but both types of
software persist.  So do individuals who claim this is reasonable
behavior.

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 1992 09:27:43 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet ECHO option

In article <11203@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>In the course of adding telnet client ability to another application I've
>discovered that the telnetd at a local IRIX system sends out a DO ECHO request.

Sounds like the implementor of that telnetd was confused about the meaning
of the Telnet ECHO option.  He probably thought he was telling the client
telnet to perform local echoing.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 92 14:03:41 GMT
From:      johna@mobdig.ncal.mobdig.com (John Antypas)
To:        comp.protocols.tcp-ip
Subject:   Service of PSI

Just thought I'd throw this out to the net to get others views on this.

We've been a PSI dialup IP customer for about a year now and on the
whole, been quite pleased with them -- when things work.  I'm not
saying PSI is "at fault" directly, but over the last six months, the
point-of-presense we use in San Fransisco has gone down several times and
stayed that way for and hour or more -- in some cases several hours.

Perhaps this is all one can expect from a dialup IP arrangment -- the
real solution may be a leased circuit but I'm short about $10K a year
right now.  

Does anyone else in Netland, a) have these problems with PSI b)
have similar POP problems with the other two dialup IP providers.
Perhaps it's time to switch?  

As I said, perhaps this the best we can get in this arrangment, but
at points, we're simply down without a cost-effective backup and I
wonder if other providers have solutions.


-- 
John Antypas / Software Engineer
MobileDigital Corp -- Wireless Network Wizards (this one in training...)
90s:  johna@mobdig.com   80s: ...!{uupsi, rtech}!mobdig!johna

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Apr 1992 18:27:43 GMT
From:      jik@athena.mit.edu (Jonathan I. Kamens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP socket questions (SUNOS)

I don't know 100% if my answers are correct for SunOS TLI; I am fairly certain
they are correct for more "traditional" (i.e. BSD :-) socket implementations.

In article <1992Apr2.150326.19039@icf.hrb.com>, spe@icf.hrb.com (Steven P. Eberly) writes:
|> The BSD "select" and SYS5 "poll" can be setup to return when a socket or
|> TLI endpoint is ready for writing. Does this mean that the TCP send buffer
|> is empty or that at least one byte can be written to it?

It means that there is room for at least one byte in the kernel buffer.

|> The number of bytes in the TCP receive buffer can be read using ioctl, can
|> the number of bytes in the TCP send buffer be check? Is there a way to
|> know when all data in the TCP send buffer has been successfully sent,
|> without a user level ack?

No.

|> Is there a method to flush the TCP transmit and receive buffers?

Not short of doing a shutdown() or close() on the socket, no.

-- 
Jonathan Kamens						jik@MIT.Edu
MIT Information Systems/Athena		    Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
	{and ONLY correspondence related to the newsgroup}
		 to news-answers-request@MIT.Edu.)

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 92 18:57:03 GMT
From:      mjs@s4mjs.UUCP (M.J.Shannon)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Commercial Internet connections

A client of mine wants/needs to get Internet connected.  What I need to
know is who all offers such a commercial connection to Internet.  I've
heard that UUNET sells connections to Alter-Net, and I believe PSI has
some similar capability.  Who else is in the game?

I'd appreciate company names and phone numbers; extra points for a
technical contact's name.

Please email as well as post, and when I've collected the info from the
vendors, I'll summarize to comp.dcom.lans (unless someone tells me of a
better newsgroup I missed).

	Thanks much,
-- 
--------------+ <Delapsus Resurgam: When I fall I shall rise. --(10cc)>
Marty Shannon | My opinions are just that.  You may share them.  No one
mjs@s4mjs.uucp| speaks for me, and I speak only for myself -- no matter
--------------+ where I post from.  Get it?		Post no flames.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 92 21:44:10 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Telnet option codes - a list

Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>Can anyone tell me what option codes 31, 33, 35, and 36 are?

A while ago, I needed similar info, so I mailed Jon Postel. Here, for
the benefit of the Usenet, is the list he sent back.  RFC 1060 was
current then, and still is, so there isn't a public more "official"
list than this one.

Date: Tue, 20 Aug 91 13:25:34 PDT
From: postel@isi.edu
Message-Id: <9108202025.AA07975@bel.isi.edu>
To: ian@unipalm.co.uk
Subject: Re:  Telnet option numbers

Ian:

Hi.  The next edition of Assigned Numbers will include the telnet options.

--jon.


Options  Name                                              References
-------  -----------------------                           ----------
   0     Binary Transmission                                [110,JBP]
   1     Echo                                               [111,JBP]
   2     Reconnection                                        [42,JBP]
   3     Suppress Go Ahead                                  [114,JBP]
   4     Approx Message Size Negotiation                    [133,JBP]
   5     Status                                             [113,JBP]
   6     Timing Mark                                        [115,JBP]
   7     Remote Controlled Trans and Echo                   [107,JBP]
   8     Output Line Width                                   [40,JBP]
   9     Output Page Size                                    [41,JBP]
  10     Output Carriage-Return Disposition                  [28,JBP]
  11     Output Horizontal Tab Stops                         [32,JBP]
  12     Output Horizontal Tab Disposition                   [31,JBP]
  13     Output Formfeed Disposition                         [29,JBP]
  14     Output Vertical Tabstops                            [34,JBP]
  15     Output Vertical Tab Disposition                     [33,JBP]
  16     Output Linefeed Disposition                         [30,JBP]
  17     Extended ASCII                                     [136,JBP]
  18     Logout                                              [25,MRC]
  19     Byte Macro                                          [35,JBP]
  20     Data Entry Terminal                             [145,38,JBP]
  22     SUPDUP                                           [26,27,MRC]
  22     SUPDUP Output                                       [51,MRC]
  23     Send Location                                      [68,EAK1]
  24     Terminal Type                                     [128,MS56]
  25     End of Record                                      [103,JBP]
  26     TACACS User Identification                           [1,BA4]
  27     Output Marking                                     [125,SXS]
  28     Terminal Location Number                            [84,RN6]
  29     Telnet 3270 Regime                                 [116,JXR]
  30     X.3 PAD                                            [70,SL70]
  31     Negotiate About Window Size                      [139,DW183]
  32     Terminal Speed                                     [57,CLH3]
  33     Remote Flow Control                                [58,CLH3]
  34     Linemode                                            [9,DB14]
  35     X Display Location                                 [75,GM23]
  36     Environment Option                           [RFC-XXXX,DB14]
  37     Authentication Option                        [RFC-XXXX,DB14]
  38     Encryption Option                            [RFC-XXXX,DB14]
 255     Extended-Options-List                              [109,JBP]

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

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 92 21:47:21 GMT
From:      srikanth@cs.tulane.edu (R. Srikanth)
To:        comp.protocols.tcp-ip
Subject:   finger protocol

Hi,

I am looking for some information on how the finger protocol works.
Does anyone have any information on the finger protocol or know where
one can get this information ?

Thanks in advance.

Srikanth
-- 


srikanth@rex.cs.tulane.edu
Dept of Computer Science,
Tulane University,
New Orleans, La - 70118


GOOOOOOO SAINTS !!!!!!

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 92 23:05:05 GMT
From:      clunie@bloch.ohsu.edu (David Clunie)
To:        comp.protocols.tcp-ip
Subject:   Firewall machines - documents ?


I remember someone mentioned recently a document describing how
to setup Internet firewall machines, and I though it was available
on cert, but I can't find it.

Does anyone have this or know where to get it ?

Thanks ... david (clunie@ohsu.edu)

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 1992 23:58:34 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: finger protocol

In article <1992Apr3.214721.29917@cs.tulane.edu> srikanth@cs.tulane.edu (R. Srikanth) writes:
>I am looking for some information on how the finger protocol works.


See RFC 1196.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 92 00:57:24 GMT
From:      xwu@ACSC.COM (Xinhua Wu)
To:        comp.protocols.tcp-ip
Subject:   client fails if runs on server machine

What might be the reasons for a client-server application working when
the client and the server running on different machines but not working
when they are running on a same machine?

We are using IBM RS/6000.  Communication between the client and the
server is handled by using TCP sockets.  The client side is implemented
as a kernel extension.  The same problem had happened a few times when
we were using AIX 3.1 and we didn't find the reason.  Now we are working on
a newer version of the application for AIX 3.2.  Everything seemed fine
until we ran the application on a single machine where it has never worked.

One symptom for the problem is:  A call to recv() on the client side
received nothing due to error "no body" (i.e., the packet contains
no data part: m_type != MT_DATA).  But when the client and the server
are running on different machines, that's not the case (i.e.,
m_type == MT_DATA).

Before the above recv() failure, we have fp_poll() on sockets.  Another
symptom is:  During the whole delay period (fp_poll delays some time and
we try fp_poll several times when needed) the machine hangs.
This symptom is not present if we use two machines (first fp_poll()
succeeds).

Any help will be very much appreciated.  Thanks in advance,

-- 
Xinhua Wu
xwu@acsc.com

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Apr 92 06:50:35 GMT
From:      hgv@herring.network.com (Harry G. Varnis)
To:        comp.protocols.tcp-ip
Subject:   Sockets vs TLI in Future SunOS (Was: Re: TCP socket questions (SUNOS)


In SunOS 4.1.x TLI is implemented as a library while socket functions are system calls.
Not too long ago there was some discussion about this positioning being reversed in
the future.  Would someone summarize the discussion, please?  I didn't care about
TLI much at the time, but...things change.

Has anyone noticed problems with the TLI library?  In particular with data loss if
one's "sends" are larger than 4K?

Thanks,

-- 
Harry Varnis         <hgv@anubis.network.com>          +1 612 493 1042

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 92 09:42:24 GMT
From:      torkel@bibsyst.no (Torkel Hasle)
To:        comp.protocols.tcp-ip,comp.unix.programmer,comp.unix.sysv386
Subject:   Re: Problem with System V IP Sockets

In article <9527@pluto.dss.com> cat@pluto.dss.com (Iain Wacey) writes:
>
> I am writing a program under System V that takes in data and sends it
>across to a terminal server using IP sockets. The problem is that if any
>data remains to be sent to the server when I close the socket the data
>is droped instead of delivered.

You have to set the SO_LINGER flag with function call setsockopt().
The value of l_linger in struct linger determines the time the socket 
will wait. According to W. Richard Stevens (Unix Network Programming),
the value og l_linger does not matter, as long as it is nonzero.

+----------------------------------------------------------------------+
!   Torkel Hasle, Bibliotek-Systemer A/S, N-3250 Larvik, Norway        !
!   tel: +47 34 82 202 fax: +47 34 85 185 uucp: torkel@bibsyst.no      !
+----------------------------------------------------------------------+

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Saturday, 4 Apr 1992 14:56:46 CDT
From:      <K3006E7@ALIJKU11.BITNET>
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Question: installing NCSA

I wish to use the NCSA v2.3.03 FTP and TELNET package on our
IBM PC.  I am having very much trouble getting it to work.
Right now, our hardware is:
           "4-Dimension Quick BROM Version 6.0
            Ether Board 16 V1.31 200-5009A"
which is hooked up to the ethernet.
In the config.sys, IPCUST.SYS and IFCUST.SYS are loaded.  In
the autoexec.bat, the commands:
               NE2000.com 0x60 0x3 0x300
               ETHDRV
I think these are old "FTP Software"  that was put into our
hard-disk when the local administrator hooked up our pc to
the network.  Unfortunatly, he left absolutely no documentation
behind.
In anycase, we use the pc mostly to log onto to the local system
running VM/XA SP release 2.1.  But the trouble starts when I try
to log directly to other machines with the old "FTP Software" TN
command, such as archie at Rutgers or McGill, which do not run
VM-style operating systems.
I therefore would like to install NCSA from scratch, and learn to
configure it correctly.  If anyone could point me in the right
direction as to literature, or installation software, I would
greatly appreciate it|  I need information such as:
     what is this IPCUST.SYS and IFCUST.SYS, is this
     necessary for the NCSA telnet?
     which drivers should I use for our Ether card as
     stated above?  and what are the options I should
     try (interrupt levels, etc.)?
     Is there any software out there that does this
     automatically in regards to installation?
     etc, etc

Any and all information would be greatly appreciated.  I prefer
personal e-mail since I suspect these questions are probably
irritatingly juvenile for most readers.  But if you feel it is
of general interest, I will look forward to your followup posts.
Thank you.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Apr 1992 17:14:16 GMT
From:      scoggin@daisy.udel.edu (John K Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Re: Service of PSI

In article <1992Apr03.140341.20828@mobdig.ncal.mobdig.com> johna@mobdig.ncal.mobdig.com (John Antypas) writes:
>Just thought I'd throw this out to the net to get others views on this.
>
>We've been a PSI dialup IP customer for about a year now and on the
>whole, been quite pleased with them -- when things work.  I'm not
>saying PSI is "at fault" directly, but over the last six months, the
>point-of-presense we use in San Fransisco has gone down several times and
>stayed that way for and hour or more -- in some cases several hours.
>
>Perhaps this is all one can expect from a dialup IP arrangment -- the
>real solution may be a leased circuit but I'm short about $10K a year
>right now.  
>
>Does anyone else in Netland, a) have these problems with PSI b)
>have similar POP problems with the other two dialup IP providers.
>Perhaps it's time to switch?  
>
	a.  Yes, we have had two distinct problems.  The NetBlazer in
	    Reston VA POP hanging on several occasions and loss of
	    the T-1 linking Reston to the rest of the Internet.  Could
	    it be that PSI doesn't build any redundancy into their
	    net?  Can't tell - they don't have a topology map in any
	    of the normal places.
	b.  Can't comment on this.  PSI is our first Internet service
	    provider.

>As I said, perhaps this the best we can get in this arrangment, but
>at points, we're simply down without a cost-effective backup and I
>wonder if other providers have solutions.
>
>
	I'm not really complaining.  A certain amount of pain is probably
	due to the dialup nature of the service and the difficulties that
	it presents to the carrier in terms of monitoring.

	What HAS annoyed me was PSI knocking links down for maintenance
	without notification.  It happened a few weeks ago in the middle of
	a big FTP - I was slightly PO'd and let them know it!

	All in all, though, I find their service to be acceptable.  Their
	tech support has been nothing short of outstanding (thanks, Mark
	Fedor!).

>-- 
>John Antypas / Software Engineer
>MobileDigital Corp -- Wireless Network Wizards (this one in training...)
>90s:  johna@mobdig.com   80s: ...!{uupsi, rtech}!mobdig!johna

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

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 92 19:16:01 GMT
From:      mikec@cardinals (Mike Catalanotti)
To:        comp.protocols.tcp-ip, srikanth@cs.tulane.edu (R. Srikanth)
Subject:   Re: finger protocol

Well,  The FINGER protocol is really no different than any other of the
protocols lying on the TCP/IP stack.  It's at layer 5 (Session) of the
OSI model.  I don't know what info you want in paricular but I'll try:

I just recently wrote a finger daemon for OS/2, and in and of itself, 
the code is no longer than a page (using Sockets libraries).  Basically
it is a service (at the UDP layer) that sits and listens for incoming
STREAM requests via port 79.  Upon a finger request, it just blasts out
any text back to the asker.  It's no different that, say, SMTP, FTP,
TELNET, etc., except that it listens for requests on s different port
than those other services.

If you need any other info, detailed or not, write me back directly if
you can and I'll try to help out.

Mike Catalanotti
Systems Software Engineer
Cabletron Systems, Inc.

mikec@mikec1.ctron.com  -or-  mikec@ctron.com

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 92 19:21:23 GMT
From:      ewilts@mr.gov.bc.ca (Ed Wilts)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall machines - documents ?

In article <1992Apr3.230505.6667@ohsu.edu>, clunie@bloch.ohsu.edu (David Clunie) writes:
> 
> I remember someone mentioned recently a document describing how
> to setup Internet firewall machines, and I though it was available
> on cert, but I can't find it.
> 
> Does anyone have this or know where to get it ?
> 
> Thanks ... david (clunie@ohsu.edu)

ftp to research.att.com.  Get file /dist/Secure_Internet_Gateway.ps

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

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 92 06:45:23 GMT
From:      mju@mudos.ann-arbor.mi.us (Marc Unangst)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Tunnel driver or PPP for SysVr4/386?

I'm trying to get PPP running on my SysVr4/386 (ESIX) system.  Before
I go ahead and try to port the SunOS PPP implementation, has anyone
done this before?  Is there a free PPP out there somewhere that
compiles on SysVr4/386?

Failing that, I anticipate the most difficult part of SunOS PPP to
port will be the tunnel driver, simply because the device-driver
semantics are likely to be very different.  So, has anyone implemented
an IP tunnel driver on SysVr4?

-- 
Marc Unangst                | You know that funny-looking bump on your
mju@mudos.ann-arbor.mi.us   | leg?  It's your kneecap.  Leave it alone.
<backbone>!sharkey!mudos!mju|

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 92 15:07:18
From:      vixie@pa.dec.com (Paul A Vixie)
To:        comp.unix.ultrix,comp.unix.bsd,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   GATEKEEPER.DEC.COM'S address is wrong in the root servers

the NIC made a boo-boo in the root zone glue, mixing up the address records
of GATEKEEPER.DEC.COM and GATEKEEPER.CALERA.COM.  one of the three DEC.COM
servers (DECUAC.DEC.COM) has become confused about GATEKEEPER.DEC.COM's 
address, but the other two (GATEKEEPER.DEC.COM and CRL.DEC.COM) are OK.

chances are very good that if you try to ftp to GATEKEEPER.DEC.COM, you will
find yourself connected to a SunOS 4.1 machine whose name also happens to be
"gatekeeper" but which does not have anonymous FTP.  if this happens, you 
will have to exit from ftp and retry with "ftp 16.1.0.2".  16.1.0.2 is the
right address for GATEKEEPER.DEC.COM.

we regret the inconvenience.  we're doing everything we can, which is nothing.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Ready, Fire, Aim"
<vixie@pa.dec.com> decwrl!vixie
<paul@vix.com>     vixie!paul          alt.pink.bunny.boom.boom.boom moderator

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Apr 1992 12:14:58 GMT
From:      scoggin@daisy.udel.edu (John K Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall machines - documents ?

In article <1992Apr4.112123.384@mr.gov.bc.ca> ewilts@mr.gov.bc.ca (Ed Wilts) writes:
>In article <1992Apr3.230505.6667@ohsu.edu>, clunie@bloch.ohsu.edu (David Clunie) writes:
>> 
>> I remember someone mentioned recently a document describing how
>> to setup Internet firewall machines, and I though it was available
>> on cert, but I can't find it.
>> 
>> Does anyone have this or know where to get it ?
>> 
>> Thanks ... david (clunie@ohsu.edu)
>
>ftp to research.att.com.  Get file /dist/Secure_Internet_Gateway.ps
>
>-- 
>Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
>EWilts@MR.Gov.BC.CA   |   Ed.Wilts@BCSystems.Gov.BC.CA   |   (604) 389-3430

Only one problem - that paper describes an approach which requires some pretty
specialized resources (like AT&T DataKit, for example).  For a little more
practical approach, see "Practical Unix Security" by Simson Garfinkel and
Gene Spafford (of Purdue fame).  The publisher is O'Reilly & Associates,
800-338-6887 (707-829-0515 for you folks offshore).  The ISBN is 
0-937175-72-2.  Chapter 14 is devoted to the care and feeding of firewall
machines.  Highly recommended.

There are also several commercially available systems available.  Sun's
consulting division markets "IGATEWAY" which provides proxy Telnet and FTP.
I believe that Advanced Networks & Services (ANS), the NSFnet folks, market
one called ANSgate.  Finally, Raptor Systems markets a more complete package,
including both firewall and intruder detection systems.

Hope this helps.

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

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 92 14:55:45 GMT
From:      iglesias@hydra.acs.uci.edu (Mike Iglesias)
To:        vmsnet.networks.tcp-ip.misc,comp.protocols.tcp-ip
Subject:   Re: BSD TALK protocol documented?

In article <1992Apr2.134420.1@indyvax.iupui.edu> harvey@indyvax.iupui.edu writes:
>Is there a formal specification for the BSD TALK protocol available anywhere?
>The new one, not the old one (i.e., the one that works between big-endian and
>little-endian systems).  I need to write a server and client to run under a
>non-Unix operating system.

There doesn't appear to be an RFC on the talk protocol, but you could
pick up a copy of the sources from one of the BSD source archives 
(gatekeeper.dec.com or uunet.uu.net) and use the source as your guide.


Mike Iglesias                        Internet:    iglesias@draco.acs.uci.edu
University of California, Irvine     BITNET:      iglesias@uci
Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
Distributed Computing Support        phone:       (714) 856-6926

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 92 17:34:16 GMT
From:      hgschulz@gaia.cs.umass.edu (Henning Schulzrinne)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD TALK protocol documented?

As part of the networking class I'm teaching right now, I have students
program the talk part (using the standard talkd server). It seems to
serve as a good example since it uses both datagram and stream services,
name lookup, features issues of host/network data representation,
client/server architecture, etc. As part as the project description, I
have assembled a reasonably detailed "protocol" description, deduced
from the Berkeley sources and some experiments. Interested parties are
welcome to request the project writeup by e-mail.
---
Henning Schulzrinne  (hgschulz@cs.umass.edu)
Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst
Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 92 01:37:18 GMT
From:      subhodip@paul.rutgers.edu (SUBHODIP GHOSH)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   TROLL-NETWORK SIMULATOR/DATAGRAM FORWARDER

I am looking for the utility "troll" - network simulator/datagram. It think it comes
with the unix software for SUN machines.I need to do some performmence benchmark of
the client/server protocols using UDP.

Some more details about the utility:

Troll is an application designed to simulate the various quirks and vagaries of a network envirnment.The troll forwards UDP datagrams between processes, possibly dropping,
delaying,garbling,and/or duplicating those datagrams.

Does anyone know from where I can get the relevant files.
OR is there a ftp site where I can get the files, OR is there any public domain 
copy of this software available..

Send me e-mail .

Thanks.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 92 02:52:58 GMT
From:      ittai@news.ans.net (Ittai Hershman)
To:        comp.protocols.tcp-ip
Subject:   Re: Firewall machines - documents ?

>I believe that Advanced Networks & Services (ANS), the NSFnet folks, market
>one called ANSgate.

It is called "Interlock".  We will be demonstrating Interlock in the
ANS booth at Interop East next month (it was first announced at Interop '91).

-Ittai

PS: Please don't send me mail for more information on Interlock:
    please use our "info@ans.net" address instead.  Thanks...

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Apr 1992 12:40:15 GMT
From:      a722756@pan.mc.ti.com (W. D. Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: TCP/IP BSD-sockets for Windows 3.x


In article <477@kommu.UUCP>, anderl@kommu.UUCP (Horst Anderl) writes:
|> Where can I get a TCP/IP BSD-socket library for MS-Windows 3.x?
|> 

HP in thier ARPA services 2.1 for the pc has available sockets for use under
Windows 3.0.  Unfortunately they do not have a part number, and can not sell it
to you (or couldn't to me in any event).  ARPA services 2.1 will be the basis for
the upcoming release of Pathworks TCP/IP from DEc, and is reuputed to include the
windows based socket libraries and program development software.

A windows based socket library is also reputedly available from Frontier
Technologies for their SUPT TCP product.
-- 

Regards.
 
Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Apr 1992 19:51:29 GMT
From:      garnett@news.Colorado.EDU (Santiago de la Paz)
To:        comp.protocols.tcp-ip
Subject:   Prepending custom IP headers

I need to generate IP packets which have a source address that is not at
all related to the machine which is generating them.  This would be a simple
task if it were not for the fact that the kernel tacks an IP header auto-
matically to my data.

I seem to remember several threads on this topic, and that specifying
IPPROTO_RAW for the protocol of a SOCK_RAW socket was one way of doing it
with certain kernels patched for traceroute.  The kernel I wish to do
this under is a SunOS4.1.1 kernel, which already supports the use of
traceroute, so can I make my own headers in this situation?  If so, how?
Does the kernel examine the data in a send() to ensure that a valid IP
header is present, and prepend its own header if not?

Many thanks for any information...

~james

James Garnett                                   garnett@boulder.Colorado.EDU
UnixOps/Distributed Computing                       ...!ncar!boulder!garnett
University of Colorado at Boulder                            +1 303 492 0264

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 92 21:10:33 GMT
From:      psirakis@yoko.rutgers.edu (Psirakis Alexander)
To:        comp.protocols.tcp-ip
Subject:   Question on bind-socket



I  am currently working on a term project concerning network programming.

I want to bind a second socket descriptor (sockt2) to a port that is
already assigned to another socket (sockt).
I tried to use the setsockopt system call, with arguments SOL_SOCKET and
SO_REUSEADDR. The setsockopt is correctly executed and I also test it
with the getsockopt system call.
But when I try to bind the same port address to the second socket descriptor 
the bind system call fails ("address already in use").

The critical code segment is the following:


	sockt = socket(AF_INET, SOCK_DGRAM, 0);
	bind(sockt, &addr, sizeof(addr), 0);
	length = sizeof(addr);
	getsockname(sockt, &addr, &length);
	optval=1;
	temp=sizeof(optval);
	setsockopt(sockt,SOL_SOCKET,SO_REUSEADDR,(char *)&optval, sizeof(optval);
	optval=0;
	getsockopt(sockt,SOL_SOCKET,SO_REUSEADDR,(char *)&optval, (int *)&temp);
	sockt2 = socket(AF_INET, SOCK_DGRAM, 0);
	if (bind(sockt2, &addr, sizeof(addr)) != 0)
	     ^  perror("Binding local socket");
             |
           here is the fail!!!


I appreciate any kind of help
Thank you

Alexander Psirakis
e-mail: psirakis@yoko.rutgers.edu

                

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Apr 1992 21:15:24 GMT
From:      chris@gargoyle.uchicago.edu (Chris Johnston)
To:        comp.protocols.tcp-ip
Subject:   tcp printer servers

    Anyone used any of the tcp printer servers?  With a Sun?  With
LPD?  Do they work?  With a laserjet?  Postscript?  NeWSprint?  The
marketing info is summarized below.

    The Microplex M200 sits on the ethernet and has three ports, one
parallel at 50 kBps and two serial at 38.4 kbps.

    The Milan Fastport has three flavors of ethernet ports, one
parallel port and one 38.4k baud serial port.  It also has a switch to
fully support Adobe's fancy parallel protocol.

thanks,
cj


-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 92 21:53:35 GMT
From:      thorinn@diku.dk (Lars Henrik Mathiesen)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet ECHO option

Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>In the course of adding telnet client ability to another application
>I've discovered that the telnetd at a local IRIX system sends out a
>DO ECHO request.
 
>I can understand that a telnet client would want characters echoed
>back to it (as indeed mine does), but I cannot udnerstand why a
>telnetd would want a telnet client to echo back everything it
>receives.  At present we reply WONT ECHO.

The 4.3BSD telnetd (from which the IRIX version probably derives) does
not want the echoes. The reason for the WILL ECHO is given in this
comment in the source:

	/*
	 * Is the client side a 4.2 (NOT 4.3) system?  We need to know this
	 * because 4.2 clients are unable to deal with TCP urgent data.
	 *
	 * To find out, we send out a "DO ECHO".  If the remote system
	 * answers "WILL ECHO" it is probably a 4.2 client, and we note
	 * that fact ("WILL ECHO" ==> that the client will echo what
	 * WE, the server, sends it; it does NOT mean that the client will
	 * echo the terminal input).
	 */

This server first sends WILL ECHO and WILL SGA, and then the DO ECHO.
When talking to one flavor of sane clients, the 4.3BSD one among them,
it gets a WONT ECHO back, and everything is fine.

The 4.2BSD client is (was?) broken, however, and takes DO ECHO as a
request to start echoing terminal input itself --- which it is willing
to do. The command is really a request to echo the server output back,
and there are client programs that are willing to do that, as well;
after all, TELNET is supposed to be a symmetrical protocol. To handle
both cases, if the 4.3BSD server gets a WILL ECHO in response, it
sends out _both_ WILL ECHO and DONT ECHO --- the former seems to be
needed to get a 4.2BSD client back in the correct state, and the
latter will prevent the other clients from echoing the server output
back.

In my opinion, this way of checking for client 4.2-ness is vastly
bogus, even though it does not involve technically incorrect TELNET
behavior. It will identify some reasonable TELNET clients as the
deeply broken 4.2BSD one, while it doesn't detect the similar deep
brokenness of some terminal concentrators which do answer DONT ECHO
but still don't understand about output flushing.

But to address your problem: DONT ECHO is the right thing to answer to
a 4.3BSD-derived telnetd, if you want it to use TELNET SYNCH.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 92 22:51:00 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Prepending custom IP headers

In article <1992Apr6.195129.22522@colorado.edu> garnett@news.Colorado.EDU (Santiago de la Paz) writes:
>
>I seem to remember several threads on this topic, and that specifying
>IPPROTO_RAW for the protocol of a SOCK_RAW socket was one way of doing it
>with certain kernels patched for traceroute.  The kernel I wish to do
>this under is a SunOS4.1.1 kernel, which already supports the use of
>traceroute, so can I make my own headers in this situation? 

Looking at our 4.1, it appears that IPPROTO_RAW overwrites the supplied
source IP address with the socket's address, if it has been bound, or
(eventually) the outgoing interface address if it hasn't.  In either case,
the result is a valid address for the sending host.

To do what you want to do, you need direct access to the interface output
routines, and I believe NIT is the only way to get that.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 92 23:07:28 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on bind-socket

In article <Apr.6.17.10.32.1992.6859@yoko.rutgers.edu> psirakis@yoko.rutgers.edu (Psirakis Alexander) writes:
>I want to bind a second socket descriptor (sockt2) to a port that is
>already assigned to another socket (sockt).
>I tried to use the setsockopt system call, with arguments SOL_SOCKET and
>SO_REUSEADDR. The setsockopt is correctly executed and I also test it
>with the getsockopt system call.
>But when I try to bind the same port address to the second socket descriptor 
>the bind system call fails ("address already in use").

SO_REUSEADDR does not mean what you think it means.
Don't let that worry you, though, few people do know what it is for.

Basically, SO_REUSEADDR lets you have two sockets with *similar*
local & foreign address bindings, but nothing will allow you to have
two *identically* bound sockets, and that is what you are trying to do.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 00:21:46 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   WHOIS at nic.dn.mil

I've been playing around with whois and I wonder if some netland wizard could
explain something to me:

When I do a lookup on MIT.EDU (the example given in the documentation I am
reading) there is all sorts of information, but when I do a lookup on ubc.ca or
sfu.ca, two local universities, there is no match.

Why would that be?

Frank.
--
___________________________________________________________________
Frank I. Reiter                Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Apr 92 01:14:18 GMT
From:      sss@netcom.com (Small Systems Solutions)
To:        comp.protocols.tcp-ip
Subject:   Re: WHOIS at nic.dn.mil

In article <11285@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>I've been playing around with whois and I wonder if some netland wizard could
>explain something to me:
>
>When I do a lookup on MIT.EDU (the example given in the documentation I am
>reading) there is all sorts of information, but when I do a lookup on ubc.ca or
>sfu.ca, two local universities, there is no match.

What are you looking for? The University of California at Berkeley is

	BERKELEY.EDU

and as for 'sfu', I have no idea what you mean.  San Francisco State
University? The University of California at San Francisco?

Remember the expression "Garbage in, garbage out" ???


-- 
Small Systems Solutions                   1563 Solano Avenue, Suite 123
sss@netcom.com                                  Berkeley, CA 94707-2116

The above-expressed opinions aren't necessarily

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 02:05:40 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Re: WHOIS at nic.dn.mil

> Small Systems Solution writes:
> 
> What are you looking for? The University of California at Berkeley is
> 
>         BERKELEY.EDU
> 
> and as for 'sfu', I have no idea what you mean.  San Francisco State
> University? The University of California at San Francisco?
> 
> Remember the expression "Garbage in, garbage out" ???

Yes, and I also know that .ca means Canada.  Apparently you are thinking of
California.  UBC is the University of British Columbia, and SFU is Simon Fraser
University.

Data in, garbage out.

Frank.
--
___________________________________________________________________
Frank I. Reiter                Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 03:26:25 GMT
From:      jjm13@po.cwru.edu (Jeff Murphy)
To:        comp.protocols.tcp-ip
Subject:   Re: WHOIS at nic.dn.mil

In article <11286@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:

>> Small Systems Solution writes:
>> 
>> What are you looking for? The University of California at Berkeley is
>> 
>>         BERKELEY.EDU
>> 
>> and as for 'sfu', I have no idea what you mean.  San Francisco State
>> University? The University of California at San Francisco?
>> 
>> Remember the expression "Garbage in, garbage out" ???
 
>Yes, and I also know that .ca means Canada.  Apparently you are thinking of
>California.  UBC is the University of British Columbia, and SFU is Simon Fraser
>University.
 
>Data in, garbage out.
 
>Frank.

Try it *without* the .CA on the end.  Those sites are listed as UBC and SFU 
in the nic database, *not* as UBC.CA and SFU.CA.

A little garbage got in there somewhere...

Jeff

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Apr 1992 07:17:30 GMT
From:      smd@uunet.ca (Sean Doran)
To:        comp.protocols.tcp-ip
Subject:   Re: WHOIS at nic.dn.mil

jjm13@po.cwru.edu (Jeff Murphy) writes:

>Try it *without* the .CA on the end.  Those sites are listed as UBC and SFU 
>in the nic database, *not* as UBC.CA and SFU.CA.

Close, but this is not quite what was being looked for.  The records
that one can get with "whois ubc" or "whois sfu" are NET ones, not DOM
ones, which is what was being searched for.  The NET records will only
tell you about 137.82.0.0 (NET-UBC) and 142.58.0.0 (NET-SFU), and not
about the domains ubc.ca or sfu.ca.

The NIC does not list sites under CA-DOM in the whois database, but
(as with all valid top-level-domains) lists a DOM record for CA.

Authoritative information about any registered domain in .ca can be
found for anonymous ftp at cs.ubc.ca:/ca-domain,
relay.cdnnet.ca:/ca-domain, clouso.crim.ca:/CAnet/ca-domain, and
ftp.cs.utoronto.ca (ftp.cs.toronto.edu) in /ca-domain.  We also mirror
this information, and make it available at ftp.uunet.ca:/ca-domain.  

	Sean.

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1992 20:47:13 -0700
From:      vlachopo@nunki.usc.edu (Panagiotis Vlachopoulos)
To:        comp.protocols.tcp-ip
Subject:   SRP - CRC


Hi Netters,
I am searching for two things:

(1)     A simulation of the Selective Repeat Protocol written in ANY
computer language. It will be used to calculate and plot the efficiency
of the protocol vs. buffer size. (I know it's in Tanenbaum, but I'd
rather have it in anything else than Pascal).
(2)     A piece of code that calculates CRC's for a given generator.

As I'm not reading this group I would like to have any responses
sent to panosv@theseas.ntua.gr
Thanx in advance :-)

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 09:26:12 GMT
From:      liam@dcs.qmw.ac.uk (William Roberts)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on bind-socket

In <Apr.6.17.10.32.1992.6859@yoko.rutgers.edu> psirakis@yoko.rutgers.edu 
(Psirakis Alexander) writes:

>I want to bind a second socket descriptor (sockt2) to a port that is
>already assigned to another socket (sockt).

Stop right there. You absolutely cannot do this because it just isn't possible 
given the semantics and implementation of BSD sockets. If I guess correctly 
about what you want to do, you are going to need to open two separate sockets, 
one for each address, and then use select() rather than recvfrom() to find out 
when datagrams are available.

>I tried to use the setsockopt system call, with arguments SOL_SOCKET and
>SO_REUSEADDR. The setsockopt is correctly executed and I also test it
>with the getsockopt system call.

SO_REUSEADDR is about something else (possibly waiving the "twice 
mean-segment-lifetime" delay on TCP sockets which prevents accidental 
acceptance of delayed traffic?), it isn't relevant to your problem anyway.
--

% William Roberts                 Internet:  liam@dcs.qmw.ac.uk
% Computer Science Department     
% Queen Mary & Westfield College  UUCP:      liam@qmw-dcs.UUCP
% Mile End Road                   Telephone: +44 71 975 5234
% LONDON, E1 4NS, UK              Fax:       +44 81-980 6533

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 10:35:21 GMT
From:      ian@spider.co.uk (Ian Heavens)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP & UDP/IP throughput on FDDI

Does anyone have figures or references for the performance on appropriate
hardware of TCP and UDP over FDDI?

thanks

ian


---
Ian Heavens				ian@spider.co.uk                 
Spider Systems Ltd			
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 554 9424 (Ext 4166)
--

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Apr 1992 14:18:01 GMT
From:      srp@modcomp.uucp (Steve Pietrowicz)
To:        comp.protocols.tcp-ip
Subject:   Packet sniffer for IBM-PC?

Is there a PD packet sniffer available for the PC?  If so, where can I
get it?

Thanks

Steve

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 15:39:01 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on bind-socket

In article <Apr.6.17.10.32.1992.6859@yoko.rutgers.edu>, psirakis@yoko.rutgers.edu (Psirakis Alexander) writes:
|> 
|> 
|> I  am currently working on a term project concerning network programming.
|> 
|> I want to bind a second socket descriptor (sockt2) to a port that is
|> already assigned to another socket (sockt).
|> I tried to use the setsockopt system call, with arguments SOL_SOCKET and
|> SO_REUSEADDR. The setsockopt is correctly executed and I also test it
|> with the getsockopt system call.
|> But when I try to bind the same port address to the second socket descriptor 
|> the bind system call fails ("address already in use").
|> 
|> The critical code segment is the following:
|> 
|> 
|> 	sockt = socket(AF_INET, SOCK_DGRAM, 0);
|> 	bind(sockt, &addr, sizeof(addr), 0);
|> 	length = sizeof(addr);
|> 	getsockname(sockt, &addr, &length);
|> 	optval=1;
|> 	temp=sizeof(optval);
|> 	setsockopt(sockt,SOL_SOCKET,SO_REUSEADDR,(char *)&optval, sizeof(optval);
|> 	optval=0;
|> 	getsockopt(sockt,SOL_SOCKET,SO_REUSEADDR,(char *)&optval, (int *)&temp);
|> 	sockt2 = socket(AF_INET, SOCK_DGRAM, 0);
|> 	if (bind(sockt2, &addr, sizeof(addr)) != 0)
|> 	     ^  perror("Binding local socket");
|>              |
|>            here is the fail!!!
|> 
|> 
|> I appreciate any kind of help
|> Thank you
|> 
|> Alexander Psirakis
|> e-mail: psirakis@yoko.rutgers.edu
|> 
|>                 

In order to make your code work you must select the SO_REUSEADDR on
the second socket (sockt2).  

It is not clear what you intend to do with this feature, however, you
need to understand that all incoming data will only go to one of 
the sockets (depending on what level of BSD sockets you are running,
either all incoming data will go to the first one defined or all incoming
data will go to the last one defined).

If you had planned to use this for load-leveling across processes then
a fork operation is sufficient to make the socket available to 
subordinate processes.

If you are trying to set up an IPC mechanism then you need to bind
unique local ports (or possibly just unique IP addresses, if you are
writing a special multi-homing application) in order to pass information 
between the socket pair.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 15:54:42 GMT
From:      caxbf@pkinbg.UUCP ( Bernd Fohringer   )
To:        vmsnet.networks.tcp-ip.misc,comp.protocols.tcp-ip
Subject:   Configuring Wallfleet Routers

Hey,

is there anyone in the field who has experiences in configuring a Wallfleet
Link Node Communication Server Modell 2002 for advanced IP requirements ???

What we like to do is the same we did with the Cisco Routers before.
We want to open certain TCP/UDP ports for IP-broadcast-propagation 
(e.g. DOMAIN or RWHO).


 ==============================================================================
 Bernd Fohringer                                 Phone: 0049 911 526-3735
 Philips Kommunikations Industrie                Fax:   0049 911 526-2063
 Nuernberg, West Germany                   Mail: caxbf@pki-nbg.philips.de
					     or: caxbf@pkinbg.uucp
 ==============================================================================
--
 ==============================================================================
 Bernd Fohringer                                 Phone: 0049 911 526-3735
 Philips Kommunikations Industrie                Fax:   0049 911 526-2063
 Nuernberg, West Germany                   Mail: caxbf@pki-nbg.philips.de

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 17:05:28 GMT
From:      880274d@aucs.acadiau.ca (Ralph I. Doncaster)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sniffer for IBM-PC?

srp@modcomp.uucp (Steve Pietrowicz) writes:

>Is there a PD packet sniffer available for the PC?  If so, where can I
>get it?
 
>Thanks
 
>Steve
Mit's netwatch if quite good.
you'll need drivers.zip and pcippkt.arc from /ka9q dir in
sun.soe.clarkson.edu.
(This was as of about 2 months ago; could have changed by now.
-Ralph

--
|Ralph Doncaster, Acadia Univ.     ph & fax: (902)542-3010      |
|880274d@aucs.acadiau.ca   ASU box 6585, Wolfville, NS B0P 1Z1  |

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 19:33:34 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose A. Vela A.)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where has the Bootp command gone in recent Net.exe

wmah@ersys.edmonton.ab.ca (Wayne Mah) writes:

>Just a note on bootp for KA9Q (or NOS).  The version I have allocates
>memory for the bootp via static array is thus is limited to hold only
>12 bootp entries.  Hopefully the code has been modified to allocate
>this structures dynamically in a newer version.  Otherwise, if you
>have more than 12 bootp clients you are out of luck.


 Sorry what version is that you called 'new' ??

 Thank you...

 Bye

 _____________________________________________________________________________
 Jose Angel Vela Avila. 
  Instituto Tecnologico y de Estudios Superiores de Monterrey
    I.T.E.S.M
  Mexico.
  ___               _    ___  _         __
 (   >             ' )  /    //        /  )  josevela@mtecv2.mty.itesm.mx
  __/________    _  (  / _  // __.    /--/   josevela@tecmtyvm.mty.itesm.mx
 / /  (_)  \_)__</_  \/ </_</_(_/|_  /  ( o  josevela@tecmtyvm.BITNET
<_/

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Apr 1992 20:05:41 GMT
From:      vittallo@ssd.comm.mot.com (John Vittallo)
To:        comp.protocols.tcp-ip
Subject:   gethostent() how does it know

I am trying to use gethostent() on both a UNIX R3 V7 and vmexgen target 
VME board, but type are not working.  For example on the UNIX host which 
is named eagle,  I currently have  a hard-coded line that says 
gethostbyname("eagle") but I want to use gethostent(). What will 
gethostent use as the host in the hostfile.  Should I have an entry 
in the /etc/hosts file that says 

eagle 1.1.1.4
host 1.1.1.4 ?

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 92 23:51:18 GMT
From:      hom00@ccc.amdahl.com (Harold O Morris)
To:        comp.protocols.tcp-ip
Subject:   tn3270 Failure - Not Enough Fields?

We are running a version of tn3270 - seems to be 4.1.1, and about 3 years
old (but I find the same version - at least is called 4.1.1, on ftp.uu.net).
It works on most applications, but on one it always fails.  This application
has a very large number of single-character fields (kind of like checkmarks),
and one theory a colleague had was that some array was designed to
accommodate too few fields, if I just knew where to look.

If anyone has heard of such a problem, or knows where I should look for
the most current version of tn3270, I would appreciate hearing from you.

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 92 06:49:00 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sniffer for IBM-PC?

880274d@aucs.acadiau.ca (Ralph I. Doncaster) writes:
>srp@modcomp.uucp (Steve Pietrowicz) writes:
>>Is there a PD packet sniffer available for the PC?  If so, where can I
>>get it?
>Mit's netwatch if quite good.
>you'll need drivers.zip and pcippkt.arc from /ka9q dir in
>sun.soe.clarkson.edu.
>(This was as of about 2 months ago; could have changed by now.
>-Ralph
And there is our wonderfull tool called 'The Gobbler'.
It is a development of the Beholder group.
It can capture, filter, store and view all packets on ethernet, and
this operation can even be controlled via SNMP!!

Get it and try it!

using anonymous ftp:
Host: dutepp0.et.tudelft.nl
path: /pub/Gobbler
name: gobbler.zip

Or using the mailserver at dnpap@dnpap.et.tudelft.nl:
put in the subject or body of the mail:
send /Gobbler/gobbler.zip 
and expect to receive four parts...

Greetings, Alfred
>--
>|Ralph Doncaster, Acadia Univ.     ph & fax: (902)542-3010      |
>|880274d@aucs.acadiau.ca   ASU box 6585, Wolfville, NS B0P 1Z1  |
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 92 08:09:41 GMT
From:      frank@rniwi.rni.sub.org (Frank Mogaddedi)
To:        comp.protocols.tcp-ip
Subject:   NIS, broadcast, etc. Need help

Dear World,
I hope this is the group to post to.

I have the following situation:
I have one Token-Ring Network, running Novell3.11
Connected to that are 3 *nix-Boxes only capable of ethernet-connections,
integrated into the TR thru 3 Novell-3.11 Routers.

ftp, rlogin, telnet, nfs etc. all work fine over the net. I currently
have the nets set up as 4 different class A Networks, 1.0.0.0, 2.0.0.0
3.0.0.0 and 4.0.0.0. I feel this is OK, since we don't plan to go
outside of the office-buildings to the world.

Now my problem: I would like to only have one NIS(YP) Server.
How can I do this? How do I convince th other machines to look beyond
their own net? What has the broadcast-address to do with it?

I have tried to read the manuals concerning addresses, broadcasts etc.,
but I don't understand them fully.

I can change the IP-Addresses, if necessary, but I understand that I still
need subnetworks, since the novell-router doesn't do what I hav been said
is called 'source-routing' on ethernet..

Anybody out there who can help?

Thanks in advance
	Frank Mogaddedi
-- 
+-----------------------------------------------------------------------------+
| e-mail: frank@rniwi.rni.sub.org | Disclaimer: "Read my lips" (George Bush)  |
|	  Beauty is only skin-deep, but ugliness goes clean to the bone	      |
|			Maybe life is but a nightmare?			      |

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 92 08:26:01 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP & UDP/IP throughput on FDDI

In article <1992Apr7.103521.8796@spider.co.uk>, ian@spider.co.uk (Ian Heavens) writes:
> Does anyone have figures or references for the performance on appropriate
> hardware of TCP and UDP over FDDI?


"appropriate hardware" for what purpose?

Many common VME FDDI systems get 25-35Mbits/sec measured by ttcp.  Others
get considerably more.  Van Jacobson at Interop91 reported filling the
fibre with special hardware on HP machines with TCP.  I've heard one super
computer company gets 70Mbit/sec, perhaps measured by nettest, with
relatively standard hardware.

UDP is now faster or slower, depending on various things.

In less than 18 months, FDDI will be as commonly saturated by UNIX
workstations as ethernet was in 1989.  Just as with ethernet, the problem
is not hardware, but software.  This can be seen in one VME card which does
more about twice as well depending on firmware and host.  Just as is still
true with ethernet, some people will claim 30% is a lot or that special
hardware is needed to get above 50%.  (Both have been false for FDDI for
more than 6 months.)

Then again, doesn't Spider make bridges and routers?  If you're talking
about the packet/second rates which bridge & router guys care about, I
don't know.  A ring with 3,000 reasonably sized packets per second is in
collapse, but 3,000 p/s is a puny number for the current bridge guys.


Vernon Schryver,  vjs@sgi.com

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Apr 1992 10:20:26 GMT
From:      wolfgang@wsrcc.com (Wolfgang S. Rupprecht)
To:        comp.protocols.tcp-ip
Subject:   terminal concentrators

I'm looking for the measured throughput figures for various terminal
concentrators.  How many full-speed connections can the various
vendor's TCs handle before 1) output slows down and 2) input gets
dropped?  I saw several reviews of various router's throughputs.
Hopefully there is something similar for TC's.

-wolfgang
-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 92 12:41:57 GMT
From:      chris@visionware.co.uk (Chris Davies)
To:        comp.protocols.tcp-ip,comp.windows.x,comp.unix.admin,comp.dcom.lans.misc
Subject:   Re: LAN and WAN speeds (summary)

In article <9204021327.AA10923@poohbear.visionware.co.uk> I wrote:
> Considering a link speed of around 64 or 128 kbit/sec.
> We're planning to run IP over the link; I'd imagine a
> couple of rlogin sessions at any one time, plus several (6 or so?) X
> display servers, etc.

I'd like to thank all those who emailed me with comments.  It appears
that a fair number of sites run X over 64kbit and 128kbit likes.  Some
people find the speed acceptable, others find it "alright".  The
prinicpal difficulty occurs if you try to manipulate (or use) large
bitmaps.

The consensus was that about 5-10 xterms would work over a 64kbit link
without too many problems.  However, my question was rather like the
"how long's a piece of string" one.

NFS/RFS was considered a no-no (however, I believe it depends on all
sorts of things like buffer size, etc).

Regarding routers, Cisco, or Morning Star's Snaplink appeared to be the
main contenders to a NetBlazer (as I expected).  All of these use PPP
in varying degrees.  SnapLink and NetBlazers support on-demand dialup
IP; I don't know about the Cisco.

Again, thanks to those who replied.

Chris
-- 
         VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
  Tel +44 532 788858 x238.  Fax +44 532 304676.  Email chris@visionware.co.uk
------------ "VisionWare:   The home of DOS/SQL/UNIX/X integration" -----------

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 92 14:04:29 GMT
From:      Thomas.Tornblom@nexus.comm.se (Thomas Tornblom)
To:        comp.protocols.tcp-ip
Subject:   Support for IP options (or lack thereof)


How come so many TCP/IP products doesn't support IP properly?

I'm doing some experiments with the "Loose Source and Record Route"
option and have become a bit depressed about the performance of
some more or less well known implementations of TCP/IP.

Please note that according to RFC-791 the implementation if IP options
is by no mean optional, only the use of them.

I have had various machines crash painfully by sending a perfectly
valid IP datagram to it. I even managed to crash two machines with the
same datagram! 

This was SunOS 4.1.1b before I applied patch 100149-3 (mclput panic).

SunOS 4.0.2 on a 386i doesn't forward datagrams with LSRR option.

ka9q handled the options OK but forgot to recompute the IP checksum
before forwarding the datagram.

The Cayman gatorbox wont route LSRR datagrams. 

NCSA Telnet with MacTCP on a NuvoLINK SC SCSI-Ethernet adapter dies
horribly when LSRR datagrams are in the neighborhood.

Thomas
--
Real life:      Thomas Tornblom           Email:  Thomas.Tornblom@nexus.comm.se
Snail mail:     Communicator Nexus AB     Phone:  +46 18 171814
                Box 857                   Fax:    +46 18 696516
                S - 751 08 Uppsala, Sweden

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Apr 1992 15:21:40 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp printer servers

Why not get an HP LaserJet with the appropriate TCP/IP card?  You can
then plug the printer directly onto the TCP/IP network.

- Steve Kao

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Apr 1992 16:22:58 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   default address mask selection for a point-to-point network?

In RFC-1122 section 3.2.2.9 we see

  (b)  Until it has received an Address Mask Reply, the host SHOULD
       assume a mask appropriate for the address class of the IP
       address, i.e., assume that the connected network is not
       subnetted.

The implementation is obvious for a connection a broadcast network
like an Ethernet - just derive the mask from the IP address of the
interface.  But a point-to-point network connection (PPP, SLIP, or
whatever) has two IP addresses, one each for the "local" and "remote"
ends of the link.

From which address (local or remote) should a host infer the default
subnet address mask for a point-to-point network?

(My opinion: it should look at the remote address, because that's
where it looks for routing decisions.)

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 92 16:25:05 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on bind-socket

In article <1992Apr6.190727.3157@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes:
|> In article <Apr.6.17.10.32.1992.6859@yoko.rutgers.edu> psirakis@yoko.rutgers.edu (Psirakis Alexander) writes:
|> >I want to bind a second socket descriptor (sockt2) to a port that is
|> >already assigned to another socket (sockt).
|> >I tried to use the setsockopt system call, with arguments SOL_SOCKET and
|> >SO_REUSEADDR. The setsockopt is correctly executed and I also test it
|> >with the getsockopt system call.
|> >But when I try to bind the same port address to the second socket descriptor 
|> >the bind system call fails ("address already in use").
|> 
|> SO_REUSEADDR does not mean what you think it means.
|> Don't let that worry you, though, few people do know what it is for.
|> 
|> Basically, SO_REUSEADDR lets you have two sockets with *similar*
|> local & foreign address bindings, but nothing will allow you to have
|> two *identically* bound sockets, and that is what you are trying to do.
|> -- 
|> 		    Brian Thomson,	    CSRI Univ. of Toronto
|> 		    utcsri!uthub!thomson, thomson@hub.toronto.edu

The constraint is two identical "connected" sockets not two identical
"bound" sockets.  See earlier posting on why the original code failed.

Please note this is not an endorsement of the original poster's technique,
rather, this is merely an attempt to properly identify the constraint.

If you are bored and would like a little test to shake-down your tcp
implementation:  bind two tcp sockets (SOCK_STREAM) to the same local
address (loopback works fine) and the same port (choose any free port), be
sure to select the SO_REUSEADDR on the socket used in the second bind.  Issue
a listen on one of the sockets and then issue a connect on the other
socket using the same address you used in the bind.  If you get an 
error on the connect, then your tcp implementation is OK.  If not .......
  
WARNING - you may not want to do this on a production system.........

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 92 17:00:42 GMT
From:      andersen@unidoct.chemietechnik.uni-dortmund.de (Frank-Uwe Andersen)
To:        comp.protocols.tcp-ip
Subject:   NE1000-Standard: description wanted!

Hello wizards!

After a long period of searching for a NE1000-description without ANY success
(I phoned NOVELL and other manufacturers and distributors) I decided to give
it a try on the news system. What I need in detail is:

Which commands does a "standard" NE1000-compatible ethernet-card (e.g. D-link
model DE-100) understand? 
Programming in machine language, which codes do I have to use to tell
the card which IP-adress it is going to have and which codes tell the card
to read one "packet" of data from the net?
A full table of commands either on machine-level or at the driver-label
(this means one level upwards) would be even more useful....

All of the officials I have spoken to seemed to be worried about a potential
concurrent programmer who could program better software than they did.........

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Apr 1992 17:31:49 GMT
From:      mtcusa@tigger.jvnc.net (Multilingual Technogies Corporation)
To:        comp.protocols.tcp-ip
Subject:   Trouble with NCSA TCP/IP for MS-DOS

TO:    Anyone
FROM:  Mark Zeiger   mtcusa@tigger.jvnc.net
DATE:  April 8, 1992
RE:    Trouble with NCSA Telnet for MS-DOS

We are trying to set up IBM compatible PCs to talk with our SCO Unix
TCP/IP network.

HARDWARE:
    Fountain 486/33 ISA with 512K VGA
                  or
    Fountain 386/33 ISA with 256K VGA

    SMC (aka Western Digital) 8003E Ethercard PLUS Elite with settings:
        Software setting:   Int 5    I/O Addr 0x240   Base Mem 0xce00:0
                                  or
        Hardwire setting    Int 5    I/O Addr 0x300   Base Mem 0xca00:0

        Thin COAX

PROBLEMS:
    1. Can not communicate with any SCO Unix system on network. NCSA
       Telnet will not recognize any systems.

    2. Hooked up two computers running NCSA Telnet only and isolated from
       rest of network. Left one computer in server mode. When I tried to
       connect with other computer using NCSA Telnet, server showed message:

             Packet received for invalid port -- reset sent
                 Port 23

       Server remained in server mode and second computer retruned to DOS.

    3. ON 486 ONLY - when exitting NCSA Telnet, all screen functions lost.
       Computer is active (i.e. DIR A: shows floppy being accessed), but I
       must reboot computer to regain display.

OBSERVATIONS:
    1. Using PKTALL showed packets being received by NCSA Telnet when it
       was pinged from a SCO Unix computer.

    2. All problems were consistent no matter what combination of hardware/
       software settings were used (except for problem 3 naturally).

If anybody has any suggestions, we would really appreciate your help. Please
respond via email to Mark Zeiger at mtcusa@tigger.jvnc.net or we may be
reached locally if you're in New Jersey at Multilingual Technologies
Corporation at (201) 808-3344.

Thanks

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 92 19:41:02 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: default address mask selection for a point-to-point network?

In article <BOB.92Apr8122251@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
|> In RFC-1122 section 3.2.2.9 we see
|> 
|>   (b)  Until it has received an Address Mask Reply, the host SHOULD
|>        assume a mask appropriate for the address class of the IP
|>        address, i.e., assume that the connected network is not
|>        subnetted.
|> 
|> The implementation is obvious for a connection a broadcast network
|> like an Ethernet - just derive the mask from the IP address of the
|> interface.  But a point-to-point network connection (PPP, SLIP, or
|> whatever) has two IP addresses, one each for the "local" and "remote"
|> ends of the link.
|> 
|> From which address (local or remote) should a host infer the default
|> subnet address mask for a point-to-point network?
|> 
|> (My opinion: it should look at the remote address, because that's
|> where it looks for routing decisions.)

Point-to-point links typically show up in routing tables as "host entries"
and not as "network entries".   Therefore, the "mask" associated with 
routing is 32-bits, i.e. must match the complete IP address.

The 32-bit mask would explicitly eliminate one from responding to 
an ICMP Address Mask Request because an "all 1's" response is illegal.
Additionally, one would assume that you would not issue a mask request
for either of the addresses because the full mask is already known.

The one interesting point in your request is the possibility of the
local and remote IP address for a point to point link to be in 
different subnets.  This seems like an odd configuration, however,
it seems that you would use the subnet assigned to the local address
in order to be consistent with other interfaces (on the curious side, 
where would you get the remote subnet mask from, another routing table entry).

RFC950 seems to indicate that the authors considered this feature to
be a LAN broadcast tool and not a WAN or point-to-point tool.  Consequently,
there is no reference to implications in a point-to-point world.
In fact does anyone really use the ICMP Address Mask Request on point-to-
point links (does it even make sense)?

If what you really want is to advertise information about the network
(or subnet) accessible via the point-to-point link, which matches the
network (or subnet) in the point-to-point link IP address, then define
another routing table entry which explicitly defines the information
you want to disseminate.
 

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 92 23:11:16 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on bind-socket

In article <40625@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
>In article <1992Apr6.190727.3157@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes:
>|> 
>|> SO_REUSEADDR does not mean what you think it means.
>|> Don't let that worry you, though, few people do know what it is for.
>|> 
>|> Basically, SO_REUSEADDR lets you have two sockets with *similar*
>|> local & foreign address bindings, but nothing will allow you to have
>|> two *identically* bound sockets, and that is what you are trying to do.
>
>The constraint is two identical "connected" sockets not two identical
>"bound" sockets.  See earlier posting on why the original code failed.

Sorry, this is not correct in BSD or SunOS.
The second bind will fail whether or not SO_REUSEADDR is specified,
even if it is specified for the correct (the second) socket.
The only time you may have two sockets with exactly the same local and
foreign addresses and ports is when they are both "brand new" and 
completely unbound.

As a demonstration, I tried the first part of your suggested:

>If you are bored and would like a little test to shake-down your tcp
>implementation:  bind two tcp sockets (SOCK_STREAM) to the same local
>address (loopback works fine) and the same port (choose any free port), be
>sure to select the SO_REUSEADDR on the socket used in the second bind.  Issue
>a listen on one of the sockets and then issue a connect on the other
>socket using the same address you used in the bind.  If you get an 
>error on the connect, then your tcp implementation is OK.  If not .......

Here it is:
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

main(){
	struct sockaddr_in addr;
	int i,j;
	int one = 1;

	bzero((char *)&addr, sizeof addr);
	addr.sin_family = AF_INET;
	addr.sin_port   = htons(12321);
	addr.sin_addr.s_addr   = inet_addr("127.0.0.1");

	i = socket(PF_INET, SOCK_STREAM, 0);

	if(bind(i, (char *)&addr, sizeof addr)<0)
		perror("bind1");

	j = socket(PF_INET, SOCK_STREAM, 0);

	setsockopt(j, SOL_SOCKET, SO_REUSEADDR, &one, sizeof one);

	if(bind(j, (char *)&addr, sizeof addr)<0)
		perror("bind2");
	
}

I think you will agree that this follows your plan.  It fails with

    bind2: Address already in use

under SunOS4.1.  It fails in the same way if I create SOCK_DGRAM sockets,
too.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 05:35:13 GMT
From:      pwickman@cerebus.cc.edu (Paul J. Wickman)
To:        comp.protocols.tcp-ip
Subject:   ping question


	Does anybody have the code for the Sun/IBM/whatever version
of ping?  The one that can report "host is alive" in addition to the
verbose mode?


--
Paul J. Wickman - Systems/Network Administrator, Computer Science Dept.
Carroll College	 Waukesha, WI 53186
Internet: pwickman@carroll1.cc.edu	Phone: 414-524-7343

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 13:38:34 GMT
From:      xeee01@mixcom.com (Aniruddh Chawda)
To:        comp.protocols.tcp-ip
Subject:   One physical wire, multiple logical networks question


I have run into a situation where there is one physical
network, but a need to have multiple logical networks.
(Product testing and evaluation.)

If different computers are attached to the same wire, but
use different network addresses, is a router required
so that they will talk to each other?

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 14:36:37 GMT
From:      dletcher@umaxc.weeg.uiowa.edu (Drew Letcher)
To:        comp.dcom.sys.cisco,comp.dcom.lans,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   IBM 3270/telnet to non-IBM machine


Problem:  IBM mainframe telnet uses 3270 protocol encapsulated
in the telnet protocol.  Which is only useful if you telnet to another
IBM mainframe.  We have a full screen application that people can access
through telnet.  But our telnet server does not support 3270/telnet.

Q1: Does anyone know of a way to convert 3270/telnet into telnet using
    another emulation such as VT100?

Q2: Does anyone know of a tn3270 telnet daemon for IBM PC compatibles?


-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 14:51:40 GMT
From:      sblair@upurbmw.dell.com (Steven C. Blair "Unix Network Services")
To:        comp.protocols.tcp-ip
Subject:   Re: One physical wire, multiple logical networks question

In article <1992Apr09.133834.14574@mixcom.com>, xeee01@mixcom.com (Aniruddh Chawda) writes:
> 
> If different computers are attached to the same wire, but
> use different network addresses, is a router required
> so that they will talk to each other?

Not if you want to set the subnet masks very wide(255.255.0.0(example),
and do something really nasty like having one host do route advertising
for all the other networks, as well as doing a bunch of arp -s addr
to fake stuff out. A fairly normal thing to do to a class B network, when
*and only when* one needs to do some testing. Best way is to take a
machine, put 2 interfaces in it, and fake it out(UNIX/routing information)
via the second interface.

good luck,

-- 
Steven C. Blair    DELL UNIX NETWORK OPERATIONS        sblair@dell.com
==========================================================================
"One form to rule them all, one form to find them, one form to bring them"
	"all and in the darkness rewrite the hell out of them."
                       -- Sendmail ruleset 3 comment from DEC

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 15:00:19 GMT
From:      psirakis@yoko.rutgers.edu (Psirakis Alexander)
To:        comp.protocols.tcp-ip
Subject:   bind-socket #2



Thanks to everyone who answered to my question concerning the 
the "bind" of two or more socket descriptors to the same local port.

I thought that this is possible by using the "setsockopt" system
call with "SO_REUSEADDR" as an argument.

I tried all the possibly correct sequencies of system calls (socket, bind, 
setsockopt etc) but always the same result:
              "Address already in use"

So I came to the conclusion that this is impossible to be done (at least at 
the SunOS where I am working).

Again thank you 

Alexander Psirakis
e-mail: psirakis@yoko.rutgers.edu

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Apr 1992 15:19:41 GMT
From:      aep@icd.ab.com (Alexander E. Pensky)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on bind-socket

In article <1992Apr8.191115.26347@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes:
> >|> 
> >|> Basically, SO_REUSEADDR lets you have two sockets with *similar*
> >|> local & foreign address bindings, but nothing will allow you to have
> >|> two *identically* bound sockets, and that is what you are trying to do.
> >
> >The constraint is two identical "connected" sockets not two identical
> >"bound" sockets.  See earlier posting on why the original code failed.
> 
> Sorry, this is not correct in BSD or SunOS.
> The second bind will fail whether or not SO_REUSEADDR is specified,
> even if it is specified for the correct (the second) socket.
> The only time you may have two sockets with exactly the same local and
> foreign addresses and ports is when they are both "brand new" and 
> completely unbound.

Sorry, Brian, this is not correct either.  If SO_REUSEADDR is specified,
you may have two sockets bound to the same local address, as long as their
remote addresses are different.  This is true if both are bound to the
same local address, but one has connected to a remote port and the other 
has not. It is also true when both are connected to two different remote ports.
Thus SO_REUSEADDR can be used in a client-server design when a client wants
to use several servers simultaneously, but would like to use the same local
port number for all the connections.

> 
> As a demonstration, I tried the first part of your suggested:

[example program deleted...]

Wrong demonstration.  At the time of the second bind(), both sockets
will have the same complete address, that is,

	Local=(127.0.0.1,12321), Remote=(*,*)

Better demonstration: After binding the first socket, connect() it to
some port that another program is listening on, _then_ try to bind() the
second socket.  The addresses will then be:

	Socket i: Local=(127.0.0.1,12321), Remote=(Somehost,Someport)
	Socket j: Local=(127.0.0.1,12321), Remote=(*,*)

and the second bind() will succeed.
	

 -----------------------------------------------------------------------------
 Alex Pensky    	(aep@icd.ab.com)		         (216)646-5211
 Allen-Bradley Company             747 Alpha Drive, Highland Heights, OH 44143
 -----------------------------------------------------------------------------

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Apr 1992 15:51:24 GMT
From:      bourman@hpcc01.corp.hp.com (Bob Bourman)
To:        comp.protocols.tcp-ip
Subject:   Re: programming tools for TCP/IP on PCs





	FTP Software Inc.
	P.O.Box 150
	Boston, Ma. 02142-9922



-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Apr 1992 19:56:43 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: default address mask selection for a point-to-point network?

In article <40635@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
   In article <BOB.92Apr8122251@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
      From which address (local or remote) should a host infer the
      default subnet address mask for a point-to-point network?

   one would assume that you would not issue a mask request for either
   of the addresses because the full mask is already known.

Though RFC-1122 section 3.2.2.9 talks about ICMP Address Mask
transactions, it was the only place I could find *any* discussion of
decisions leading to picking a particular address mask size and shape.

   The one interesting point in your request is the possibility of the
   local and remote IP address for a point to point link to be in
   different subnets.  This seems like an odd configuration, 

Not at all, here's an example from a Sun.  du0 is our dialup link to
OARnet, and du1 is a fabricated link to the old ohio-state.arpa:

3:27pm> ifconfig -a
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 137.175.2.11 netmask ffffff00 broadcast 137.175.2.255
        ether 0:c0:7:0:0:1e
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000
du0: flags=51<UP,POINTOPOINT,RUNNING>
        inet 137.175.2.11 --> 131.187.1.12 netmask ffff0000
du1: flags=51<UP,POINTOPOINT,RUNNING>
        inet 137.175.2.11 --> 192.5.58.18 netmask ffff0000
3:27pm>

It's very common for point-to-point links to run between networks.  In
such a case, the routing tables look like

3:27pm> netstat -rn | egrep du\|table\|Flag
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
192.5.58.18          137.175.2.11         UH       0      0          du1
131.187.1.12         137.175.2.11         UH       0      24         du0
default              131.187.1.12         UG       10     10051      du0
3:27pm>

As you note from du1's ifconfig above, our PPP software's behavior
(which I'm questioning) is to deduce a default netmask based on the
address class of the local end of the wire.

   however, it seems that you would use the subnet assigned to the
   local address in order to be consistent with other interfaces

The need for consistency between interfaces is, I think, an artifact
of deficiencies in some vendors' 4.3BSD-based code, or perhaps in
4.3BSD itself.  I haven't examined tahoe, reno, BSDI, or 4.4 to see
what they do.  I don't believe non-4.3 IP implementations (e.g. in a
real router) require or enforce netmask consistency between
interfaces.

And besides, which other local non-point-to-point interface should I
choose as my sample netmask?  The example above shows one Class-A and
one Class-B with Class-C style subnetting.

   (on the curious side, where would you get the remote subnet mask
   from, another routing table entry).

Since PPP's IPCP lacks an address mask negotiation option, we depend
upon the user to set it from the daemon startup command line if (a)
they care and (b) the default was inappropriate.

   In fact does anyone really use the ICMP Address Mask Request on
   point-to-point links (does it even make sense)?

I don't think so, and I don't think it even makes sense.  But some
software (e.g. routed) cares about the mask it sees on "up"
interfaces, so we try to set the masks appropriately when we ifconfig
the point-to-point interface.

   If what you really want is to advertise information about the
   network (or subnet) accessible via the point-to-point link, which
   matches the network (or subnet) in the point-to-point link IP
   address, then define another routing table entry which explicitly
   defines the information you want to disseminate.

Today, our users with gated set the netmask explicitly from the pppd
command line, if the default is inappropriate, before starting gated.
This gets the correct information disseminated.  And BSD netmasks are
stored in per-interface information, not in the routing table.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 20:02:51 GMT
From:      tneff@bfmny0.BFM.COM (Tom Neff)
To:        comp.windows.x,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Cannot create address for system xxxxx

Can anyone tell me what the error message

	Cannot create address for system xxxxx

means, where 'xxxxx' is the name of another system on the network?  I am
getting this from X clients I try to attach to other systems' servers.
What is likely to be misconfigured?  Thanks in advance...

-- 
"Why don't you get me some coffee while   ||[]||   Tom Neff
  I'm looking over your application?"      /\/\    tneff@bfmny0.BFM.COM

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 20:41:25 GMT
From:      pmarimut@eos.ncsu.edu (PERAM  MARIMUTHU)
To:        comp.protocols.tcp-ip
Subject:   getpeername...help

How can I use the getpeername function to get the name of the machine
that is connected to a socket. The following code returns the internet
address (a.b.c.d) correctly but not the name.

                getpeername(msgsock,(struct sockaddr *)&peer,&length)
                printf("%s\n",inet_ntoa(peer.sin_addr));

so far its OK-----

What should I do next?


Thanks

peram

pmarimut@eos.ncsu.edu

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 21:12:30 GMT
From:      cmo@pogo.wv.tek.com (Christine Olsen)
To:        comp.protocols.tcp-ip
Subject:   SNMP MIBs

I know that MIBs are kept on venera.isi.edu.  Does
anyone know if there are other machines where MIBs
are kept?

Please reply via email: cmo@pogo.wv.tek.com


Thank you for any help on this.


Christine Olsen
Tektronix, Inc.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 22:00:41 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Minimal ping object?


	What is the absolute cheapest pingable object I can put on an
ethernet?  I supose to be practical, I should limit the field to
commercially available devices, but just for fun, let's assume I was
willing to build or modify something as long as it's reasonable (and no,
I'm not exactly sure what the limits of reasonable are).
-- 
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."

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 92 22:16:00 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: default address mask selection for a point-to-point network?

In article <BOB.92Apr9155631@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
|> In article <40635@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
|>    In article <BOB.92Apr8122251@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
|>       From which address (local or remote) should a host infer the
|>       default subnet address mask for a point-to-point network?
|> 
|>    one would assume that you would not issue a mask request for either
|>    of the addresses because the full mask is already known.
|> 
|> Though RFC-1122 section 3.2.2.9 talks about ICMP Address Mask
|> transactions, it was the only place I could find *any* discussion of
|> decisions leading to picking a particular address mask size and shape.
|> 
|>    The one interesting point in your request is the possibility of the
|>    local and remote IP address for a point to point link to be in
|>    different subnets.  This seems like an odd configuration, 
|> 
|> Not at all, here's an example from a Sun.  du0 is our dialup link to
|> OARnet, and du1 is a fabricated link to the old ohio-state.arpa:
|> 
|> 3:27pm> ifconfig -a
|> le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
|>         inet 137.175.2.11 netmask ffffff00 broadcast 137.175.2.255
|>         ether 0:c0:7:0:0:1e
|> lo0: flags=49<UP,LOOPBACK,RUNNING>
|>         inet 127.0.0.1 netmask ff000000
|> du0: flags=51<UP,POINTOPOINT,RUNNING>
|>         inet 137.175.2.11 --> 131.187.1.12 netmask ffff0000
|> du1: flags=51<UP,POINTOPOINT,RUNNING>
|>         inet 137.175.2.11 --> 192.5.58.18 netmask ffff0000
|> 3:27pm>
|> 
|> It's very common for point-to-point links to run between networks.  In
|> such a case, the routing tables look like
|> 
|> 3:27pm> netstat -rn | egrep du\|table\|Flag
|> Routing tables
|> Destination          Gateway              Flags    Refcnt Use        Interface
|> 192.5.58.18          137.175.2.11         UH       0      0          du1
|> 131.187.1.12         137.175.2.11         UH       0      24         du0
|> default              131.187.1.12         UG       10     10051      du0
|> 3:27pm>

This was my initial point.  From a routing perspective, a point-to-point
link uses full 32-bit addressing.  In this configuration the network mask
associated with the interface is not used in any routing decisions.

|> 
|> As you note from du1's ifconfig above, our PPP software's behavior
|> (which I'm questioning) is to deduce a default netmask based on the
|> address class of the local end of the wire.
|> 
|>    however, it seems that you would use the subnet assigned to the
|>    local address in order to be consistent with other interfaces
|> 
|> The need for consistency between interfaces is, I think, an artifact
|> of deficiencies in some vendors' 4.3BSD-based code, or perhaps in
|> 4.3BSD itself.  I haven't examined tahoe, reno, BSDI, or 4.4 to see
|> what they do.  I don't believe non-4.3 IP implementations (e.g. in a
|> real router) require or enforce netmask consistency between
|> interfaces.
|> 
|> And besides, which other local non-point-to-point interface should I
|> choose as my sample netmask?  The example above shows one Class-A and
|> one Class-B with Class-C style subnetting.
|> 

I probably wasn't clear here.  The ICMP Address Mask Response code dips
into the *ia* structure to find the subnet mask.  This structure contains
the interface address subnet mask for the local IP address.  By "consistent"
I meant to use the same code for all interfaces (i.e. supply the subnet
mask of the corresponding local IP address), including point to point links.
(NOTE - this is what you should get from a BSD-based solution).  I did not 
mean to imply that you would use the mask from a different interface.....

|>    (on the curious side, where would you get the remote subnet mask
|>    from, another routing table entry).
|> 
|> Since PPP's IPCP lacks an address mask negotiation option, we depend
|> upon the user to set it from the daemon startup command line if (a)
|> they care and (b) the default was inappropriate.
|> 
|>    In fact does anyone really use the ICMP Address Mask Request on
|>    point-to-point links (does it even make sense)?
|> 
|> I don't think so, and I don't think it even makes sense.  But some
|> software (e.g. routed) cares about the mask it sees on "up"
|> interfaces, so we try to set the masks appropriately when we ifconfig
|> the point-to-point interface.

May I ask what particular piece of software cares?  My limited view of
the world has seen code which special cases point to point links and
looks at them as src/dest pairs rather than src/mask pairs.  Are there
SNMP managers which flag an interface as a bogus point to point link if the
subnet mask is not what was expected?  Even if they did, is this a major
problem (i.e. can't the manager reset the mask or, worst case, isn't this
a one time change to some initialization script (if you made an error
the first time))?

|> 
|>    If what you really want is to advertise information about the
|>    network (or subnet) accessible via the point-to-point link, which
|>    matches the network (or subnet) in the point-to-point link IP
|>    address, then define another routing table entry which explicitly
|>    defines the information you want to disseminate.
|> 
|> Today, our users with gated set the netmask explicitly from the pppd
|> command line, if the default is inappropriate, before starting gated.
|> This gets the correct information disseminated.  And BSD netmasks are
|> stored in per-interface information, not in the routing table.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Apr 1992 23:05:33 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS, broadcast, etc. Need help

frank@rniwi.rni.sub.org (Frank Mogaddedi) writes:

>Connected to that are 3 *nix-Boxes only capable of ethernet-connections,
>integrated into the TR thru 3 Novell-3.11 Routers.
 
>ftp, rlogin, telnet, nfs etc. all work fine over the net. I currently
>have the nets set up as 4 different class A Networks, 1.0.0.0, 2.0.0.0
>3.0.0.0 and 4.0.0.0. I feel this is OK, since we don't plan to go
That's really ok, as long as you didn't want to connect to the world,
but even in this case its better to get a official net. You don't know
what the future brings to you, maybe you decide in the future to
connect to the net ? As I know you can get a Class C net at no more
cost as writing a letter, as long as you didn't connect.

>Now my problem: I would like to only have one NIS(YP) Server.
>How can I do this? How do I convince th other machines to look beyond
>their own net? What has the broadcast-address to do with it?
NIS didn't work outside a net or subnet, as broadcast wouldn't forwarded
by the routers. With some routers you could do some hacks, to let them
forward, but I suspect this isn't possible with your Novell boxes.

Maybe a explicit "ypset server" works. At least this works with my
CDC boxes, but I don't do it regularly, I only tried it sometimes for
debugging purposes.

It's generally a bad idea to have only one NIS server, as you get a
single point of failure. This wouldn't matter, as long as your homedirs
are at the same server, but if your homedirs are spread over your boxes,
you could avoid complete failure. In my configuration (10 Unix-boxes 
on two subnets, and numerous X-Terms) I did have at least two NIS
servers on every subnet.

>I can change the IP-Addresses, if necessary, but I understand that I still
>need subnetworks, since the novell-router doesn't do what I hav been said
>is called 'source-routing' on ethernet..
Yes you need subnetworks, or hostroutes, if there's only one Unix-box
after each Novell Box. Wouldn't it simpler to connect the three Unix-boxes
with Ethernet, and use one Novel Box to connect them to your TR ?
Or is it a matter of distance or cabling?

Sincerely,
Klaus Steinberger
--
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

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Apr 1992 23:20:11 GMT
From:      mike@gordian.com (Michael Thomas)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   LPR on a terminal server, Opinions?


   I am considering writing a LPRd for a terminal/printer server (from
 RFC 1179).  The obvious win with implementing LPR within a terminal server
is that no special host software is needed. The loses, however, appear to be
many. The basic problem is that LPR expects another unix system on the remote
side with spooling capabilities, and various output filters. A terminal
server is a limited environment though (how many have you seen with 100 meg
drives? ;-).
   What I am interested in hearing is whether some of the options which
LPR supports are dispensable or work-aroundable on the server/host side:

   1) The control file, seems to come second (after the data file).
      On a terminal server, there isn't any spool area, and this
      means that a terminal server would have to ignore it. 
 	a) Is there a way to get the control file to come before the
	   data file, and if so how.
	b) If (a) cannot be worked around, how serious a limitation would
	   this be? (Ie no server generated banner pages, none of the
	   various filtering options, etc)
   2) Assuming (1) can be worked around, there are several options which
      would _never_ be implemented on the terminal server (Troff-X, DVI,
      plot/raster filters etc). Would an LPRd which lacked these features
      be a serious hinderance? Would it be possible to work around these
      by having the host side (ie LPR side) pre format the data stream and
      send it to the LPRd raw?

Comments greatly welcomed. 
-- 


		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)

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 92 00:22:28 GMT
From:      u8551044@ucsvc.ucs.unimelb.edu.au
To:        comp.protocols.tcp-ip
Subject:   FTP not timing out?

Hello,
subject: FTP not timing out?

When one of our machines crash (host A), a decstation ds5200, 
ultrix v4.2 (rev. 96), scripted ftp processes on other machines get into
in an idle state and stay this way for days. When host A is rebooted, the 
processes on hosts B and C doing scripted ftps do not abort, they remain is 
an idle state (don't chew up cpu).

Unfortunately we are testing a new package on A (which used to be
healthy), so I am trying to work out why the ftp processes on B and C
do not time out or fail as I think they should. The crash simply hangs A.

I do a regular (scripted) anonymous ftp to get files off host A 
"decstation ds5200, ultrix v4.2 (rev. 96)" from host B 
(VAX/VMS version V5.4-2).

I do an anonymous ftp to place files regularly (in a script) from
host C "OS/MP 4.1A.2 UNIX (SunOS 4.1 compatible)" to host A.

ie:  C execs ---> put--> A
     B execs <--get <--- A

Any ideas appreciated,
many thanks,
Greg Chenhall, The University of Melbourne, GMC@unimelb.edu.au

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 92 01:00:52 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on bind-socket

In article <1992Apr9.151941.25074@icd.ab.com> aep@icd.ab.com (Alexander E. Pensky) writes:
>In article <1992Apr8.191115.26347@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes:
  [ concerning an example where two sockets are created and bound to the
    same address ]
>> The second bind will fail whether or not SO_REUSEADDR is specified,
>> even if it is specified for the correct (the second) socket.
>> The only time you may have two sockets with exactly the same local and
>> foreign addresses and ports is when they are both "brand new" and 
>> completely unbound.
>
>Sorry, Brian, this is not correct either.  If SO_REUSEADDR is specified,
>you may have two sockets bound to the same local address, as long as their
>remote addresses are different.

Yes, that is exactly what I said.  Are you confused because I used the
word "foreign" instead of "remote"?  Or did you forget that the original
question did not involve any connect() calls, and so the foreign addresses
could not have been bound?

This has all gone on far longer than it should have, and I apologize to
all you long-suffering readers for having yet another teeter at the totter,
but I will include here (in my final bleat on the subject!) an explanation
of SO_REUSEADDR that I concocted some time ago.  It refers to "wildcards",
which are addresses or ports that have not yet been bound (either through
bind() or connect(), as appropriate), or and address that has been explicitly
set to INADDR_ANY, all of which 'netstat' represents with an asterisk:

--------------------------------------------
If you try to bind a socket, and you specify an explicit port number
in the bind(), and the socket is either non-TCP or is not in LISTEN state,
and the socket does not have SO_REUSEADDR, the system will complain if
the result would clash with an existing socket, interpreting the wildcards
as wild for matching purposes.

If any of those conditions are not met, eg. if SO_REUSEADDR has been set,
or it is a UDP socket, or a TCP socket that has been listen()'ed,
the system will complain only if there exists another socket
with the exact same local + remote addresses and ports. "Exact" means
that if one is a wildcard, the other also has to be a wildcard in
order to clash.


						Bindings
Eg,					local		foreign
Step 1: create a TCP socket             *.*             *.*         CLOSED

Step 2:bind() it:                       *.11992         *.*         CLOSED
 I specified INADDR_ANY for the
 address, and 11992 for the port

Step 3: listen()                        *.11992         *.*         LISTEN

Step 4:accept connection                *.11992         *.*         LISTEN
 This creates a second socket   localhost.11992 localhost.2345      ESTABLISHED
 bound as shown

Step 5:close the listener       localhost.11992 localhost.2345      ESTABLISHED

If I try to bind another socket to
                        *.11992         *.*
without REUSEADDR, the wildcards will match the ESTABLISHED socket and
the bind() call will fail.

With REUSEADDR, I will succeed unless there is another socket already
around with the *exact same bindings*, i.e. unless I didn't close the
old listener socket.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 1992 02:46:35 GMT
From:      wen-king@cs.caltech.edu (Wen-King Su)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP not timing out?

In article <1992Apr10.102228.2982@ucsvc.ucs.unimelb.edu.au> u8551044@ucsvc.ucs.unimelb.edu.au writes:
>Hello,
>subject: FTP not timing out?
[[ ftp didn't time out and exit after the server machine died ]]

The problem could be that "KEEPALIVE" is not enabled when socket is opened
by the ftp program.  It is often disabled by default to conserve bandwidth.

If you are interested in a more flexible solution, my I recommend that
you try the FSP software.  FSP is a connection-less, state-less, and
UDP-based internet archive server.  If the server dies during a transfer,
the transfer will automatically resume where it left off after the server
comes back.  Though the software is specifically designed for use in the
distribution of ftp-busting, high-demand materials, it will work quite
well for your application.  I have a copy of it on the public access ftp
archive on wuarchive.wustl.edu.  Compared to ftp, you will find the user
interface more suitable for shell scripts, and the software more suitable
for writing specialized client utilities.  Below is the INFO file that
comes with the software. 

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

	FSP is a set of programs that implements a public-access archive
	similar to an anonymous-FTP archive.  It is not meant to be a
	replacement for ftp; it is only meant to do what anonymous-ftp
	does, but in a manner more acceptible to the provider of the
	service and more friendly to the clients. 

	Providing anonymous-FTP service can be costly --- each active
	session consumes one process slot in the OS and one stream socket
	entry in the network sub-system.  The servers can also run
	concurrently, adding to the system load.  A popular archive site
	can easily be overwhelmed as a result.  Some were forced to
	shutdown or and some impose inconvienent access restrictions. 

	Unlike FTP, FSP is connection-less and virtually state-less.  One
	server handles requests from all clients machines.  Each active
	client machine takes up 16-bytes in a dynamically extensible
	table.  Since only one server runs at any time, the load added
	to the server machine is no more than one.

	In exchange for allowing site operators to keep their sites open
	and do away with cumbersome access restrictions, this is what the
	clients accept with FSP: 

	 1) Lower transfer rate.  The maximum rate is 1 kbyte per UDP
	    message round-trip time between the client and the server.
	
	In addition to the potential for more abundant sites and more
	accessible sites, this is what the clients gain with FSP:

	 1) Robustness.  Since FSP is connectionless, flucturations in
	    the network will not abort a FSP transaction.  Furthermore,
	    the 16-bytes of data for each client can be regenerated at
	    any point during any transaction.  Thus, if the server goes
	    down at any point during a transaction, the transaction will
	    resume when the server is restarted.  (like NFS) 

	 2) Friendlier user interface.  FSP does not have its own command
	    interpretor like FTP.  Since it is connectionless, there is
	    no reason to carry much information from one command to the
	    next, and the commands can all be made into individual unix
	    programs.  For instance, there is one program you run to list
	    the directory and another you run to download a file. 

	 3) Client protection.  FSP oversees a directory structure similar
	    to that of an anonymous-FTP.  However, a directory created
	    via FSP transaction is owned by the client machine that issued
	    the creation request.  The client can create and delete files
	    and subdirectories in that directory.  In addition, the client
	    can enable any of the two attributes for that directory: 

		A) Give all other clients the permission to create files
		   and subdirectries.

		B) Give all other clients the permission to delete files
		   and subdirectories.

	    Note: A subdirectory can be deleted if it is empty and the
		  client owns the subdirectory.

	 4) Server protection.  FSP server does not spawn sub-programs.
	    It will accept only paths that are downward relative to its
	    designated working directory.  On systems with symbolic links,
	    the server will follow symbolic links, but it does not follow
	    uplinks ("..").  Clients cannot create symbolic links and
	    care should be taken so that other users on the server machine
	    cannot create symbolic links in the server's work space. 

	    It is also fairly difficult to formuate an attack to force a
	    shutdown of a FSP site by actions of a rogue site.  About the
	    only way to distrupt a FSP service is to flood the FSP site
	    with network packets.  FSP server prevents itself from
	    'counter-flooding' by filtering for legitimate requests using
	    the following method:

		A) Each request message contains a key.  For each client,
		   server database contains the keys to be used for the
		   next client request and for the previous client request.

		B) If the next request does not contain a key that matches
		   either of the two keys, it is accepted only if at least
		   one minute has elapsed since the last time a request
		   is accepted.  If the key does match the old key
		   (retransmit) it is accepted if the elapse time is
		   greater than 3 seconds.

		C) Every request message accepted is acknowledged with
		   one reply message.  The reply message contains a new
		   key to used for the next request.  The new key is
		   computed by the server with a pseudo-random number
		   generator. 

	    Flooding is a ballant violation of network etiquette because
	    a site can be subjected to flooding attack whether it has FSP
	    running or not, and flooding congests every link and gateway
	    between the rogue client and the server.  As a further measure
	    of protection, the server loads a table of rogue clients on
	    startup.  The server will not respond to requests from any of
	    those clients.

    The software set:

	common_def.h	This C header file contains definitions common to
			both the server code and the client code.

	client_def.h	This C header file contains definitions for the
			client code.

	server_def.h	This C header file contains definitions for the
			server code.

	udp_io.c	This file contains the lowest level routines that
			deal with the unix inet sockets.  This file is
			used by both the server code and the client code.

	server_main.c	Main routine and dispatch loop for the server.
	server_host.c	Routines for maintaining client database.
	server_file.c	Routines for file i/o.
	server_lib.c	Routines for inet socket i/o.

	client_lib.c	Core routines of the client library.
	client_util.c	Supplementry routines of the client library.
	client_lock.c	udp packet multiplexing mechanism.

	bsd_src/	Directory containing additional sources derived
			from those in public archive on uunet.uu.net.  It
			contains a BSD random/srandom routine, a modified
			BSD globbing routine, a modified "ls" source.

	fcdcmd.c	These compiles into individual client utilities.
	fgetcmd.c	Those with a "cmd" in their name will do their
	flscmd.c	own globbing on their argv base on directory
	fprocmd.c	information obtained from the server.
	frmcmd.c
	frmdircmd.c
	fcatcmd.c
	fmkdir.c
	fput.c
	fver.c
	fgrab.c

    Compilation:

	FSP has been compiled and tested on a SS-2 running SunOs 4.1.1,
	a HP-9000 running HP UNIX, a VAX-780 running 4.3-tahoe, and a 386
	box running system-V UNIX with old Excelan ethernet interface.
	It has also been compiled on a variety of machines by over a
	hundred users across the net. 

	To compile the software, you must first successfully complete a
	"make" in the bsd_src directory.  You may have to change a few
	files.  In particular, you may have to edit "Makefile" and "tweak.h"
	in bsd_src directory. 

	When that is done, you can edit the Makefile on the top directory
	and run "make" in the top directory.  You may have to read through
	the rest of this document first before making changes to the Makefile.

    Server Administration:

	The only things you need for setting up a FSP server is a work
	directory for the service and and the FSP server itself (fspd).
	fspd can run independently or it can be run under inetd.  When
	running independently, fspd waits for messages through a UDP
	socket whoes port number is defined in the Makefile.  When running
	under inetd, fspd is involked as in.fspd.  inetd will spawn fspd
	when a message arrives for the FSP socket.  The fspd process will
	take over and stick around to wait on additional messages.  After
	it has become idle for 2 minutes, fspd will exit and return control
	to inetd. 

	Sample setup for inetd operation:

	    In /etc/services file:

		fsp             21/udp          fspd

	    In /etc/inetd.conf file:

		fsp dgram   udp wait ftp /usr/etc/fspd in.fspd

	    In this sample, the same port number for ftp is used for the
	    fsp socket.  There will not be a conflict because ftp uses
	    stream protocol, and fsp uses UDP protocol.  The fspd program
	    in this example is ran under user 'ftp'. 

	In addition, fspd will accept these flags:

	    -h absolute_path    Set fsp work directory.  Overrides the
				compiled-in default.

	    -p udp_port_number  Set UDP port number.  Overrides the
				compiled-in default.

	    -u uid_number       Assume this uid after startup.  If present,
				fspd will attempt a setuid() to this uid
				number.  It will exit if setuid() fails.

	    -d                  Turn on debug mode.  The stdio files will
				remain open in debugging mode.

	When fspd starts, it chdir to its work directory where it looks
	for (and reads in if found) a list of internet numbers in the
	standard 4-part form: ddd.ddd.ddd.ddd in the file ".ROGUE_HOSTS".
	This file is prepared by the FSP maintainer, and is used to
	indicate that fspd should not respond to any requests from these
	machines.   After that, it begins to service any requests it gets
	on the UDP socket.

	If a file .OWN.XXXXXXXX, where XXXXXXXX is an 8-digit hex number,
	exists in a directory in fspd's work space, the directory is owned
	by the machine whoes inet number is XXXXXXXX, where the number
	is printed as a hexadecimal number.  If no such file exists, the
	directory has no owner.  (Note, the 'dot' files are hidden from
	clients).

	If the file .FSP_OK_DEL does not exists in a directory, only the
	owner is allowed to remove items from that directory. 

	If the file .FSP_OK_ADD does not exists in a directory, only the
	owner is allowed to add items into that directory. 

	Thus, you typically want to protect the top directory by leaving
	out the .FSP_OK_DEL, .FSP_OK_ADD files, and .OWN.XXXXXXXX files
	in the top directory. 

	Clients do not get to read the directory information directly.
	Instead, fspd maintains a directory listing in the file .FSP_CONTENT
	in each directory.  When a client requests information for a
	directory, the .FSP_CONTENT file is created if it doesn't exist,
	and it is rebuilt if it is out of date.  The information is
	accessed by having the client read the directory listing file.
	Care is taken so that the client will not get corrupted entries
	when the directory is changed while the listing is being read. 

	Files being uploaded are first written to a temporary file in the
	work directory: .TXXXXXXXXYYYY where XXXXXXXX is the inet number
	of the client, and YYYY is the port number of the client program.
	When upload is compelete, the file is moved into the intended
	location. 

	An 'alarm' interrupt will cause fspd to dump its current client
	database into the file .HTAB_DUMP in the work directory.  This
	can be useful for debugging and for catching rogue clients.

    Client utilities:

	All inter-command states are kept in these four shell environment
	variables.

	    FSP_PORT		Port number of the fspd you wish to contact.
	    FSP_HOST		Host name or number of the fspd.
	    FSP_DIR		Your current working directory in the archive.

	When multiple client utilities are run at the same time on the
	same client machine, packet multiplexing mechanisms can be used
	to enable concurrent access to the same fsp database.  If none
	of the mechanisms are selected at compile time, FSP_LOCALPORT
	can be used to ensure that only once client utility can run at
	any time.  In this case, FSP_LOCALPORT can be set to any port
	number not current used on the client machine.

	FSP_TRACE can be set if you want status reports be printed while
	files are being transferred.  FSP_DELAY variable can be used to
	set the retransmit interval for client utilities (in thousandth
	of a second).  The retransmit rate is adjusted in an exponential
	manner, until the retry rate reaches 5 mintes per retry.

	FSP_BUF_SIZE can be set to a positive number less than or equal
	to 1024.  When set, it determines the size of data to be send for
	each request during file and directory information transfer.  The
	default is 1024.  Some sites are connected via links that cannot
	transmit buffers containing 1024 bytes of data in addition to the
	header information.  Setting FSP_BUF_SIZE to a lower value will
	allow these sites to access fsp archives.

	A typical setup looks like this:

	    setenv FSP_PORT	 21
	    setenv FSP_HOST	 131.215.131.97
	    setenv FSP_DIR	 /
	    setenv FSP_TRACE
	    setenv FSP_DELAY	 3000
	    setenv FSP_BUF_SIZE  1024

	(All examples will be in csh.  However, it is assumed that similar
	 things can be done with other shells)

	For commands that do globbing using remote directory info, normal
	shell globbing needs to be turned off.  In csh, it can be done
	with a set of aliases: 

	    alias fcd setenv FSP_DIR \`\(set noglob\; exec fcdcmd \!\*\)\`
	    alias fls    \(set noglob\; exec flscmd    \!\*\)
	    alias fget   \(set noglob\; exec fgetcmd   \!\*\)
	    alias fgrab  \(set noglob\; exec fgrabcmd  \!\*\)
	    alias fcat   \(set noglob\; exec fcatcmd   \!\*\)
	    alias frm    \(set noglob\; exec frmcmd    \!\*\)
	    alias frmdir \(set noglob\; exec frmdircmd \!\*\)
	    alias fpro   \(set noglob\; exec fprocmd   \!\*\)
	
	In addtion, this alias is useful:

	    alias fpwd echo \$FSP_DIR on \$FSP_HOST port \$FSP_PORT

	Commands:

	    fver	display server's version number.
	    fcd		change current remote directory, like cd.
	    fls		list directory.  works like ls.
	    fget	get the named files.
	    fgrab	get the named file and delete it from remote directory.
	    fput	put the named files.
	    fcat	get the named files and send them to stdout.
	    fmkdir	make named directories.
	    frm		delete named files.
	    frmdir	delete named directories.

	    fpro	no arg: display directory protection modes.
			    +c: give others permission to create new items.
			    -c: deny others permission to create new items.
			    +d: give others permission to delete old items.
			    -d: deny others permission to delete old items.

    ***********************************************************************

    This is a free software.  Be creative; make your own macros and tools
    and let me know of any bugs and suggestions.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 1992 06:04:23 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: default address mask selection for a point-to-point network?

In article <BOB.92Apr8122251@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
> In RFC-1122 section 3.2.2.9 we see
> 
>   (b)  Until it has received an Address Mask Reply, the host SHOULD
>        assume a mask appropriate for the address class of the IP
>        address, i.e., assume that the connected network is not
>        subnetted.
> 
> The implementation is obvious for a connection a broadcast network
> like an Ethernet - just derive the mask from the IP address of the
> interface.  But a point-to-point network connection (PPP, SLIP, or
> whatever) has two IP addresses, one each for the "local" and "remote"
> ends of the link.
> 
> From which address (local or remote) should a host infer the default
> subnet address mask for a point-to-point network?
> 

Presumably the IP numbers for each end have the same (sub)network number
portion (making the cable a "network of two hosts"), the answer is,
I would hazard, "either".
 
Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 1992 06:05:17 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Minimal ping object?

 roy@alanine.phri.nyu.edu (Roy Smith) writes:
>	What is the absolute cheapest pingable object I can put on an
>ethernet?  I supose to be practical, I should limit the field to
>commercially available devices, but just for fun, let's assume I was
>willing to build or modify something as long as it's reasonable (and no,
>I'm not exactly sure what the limits of reasonable are).


By your definition it must have an Ethernet interface.
A minimal hardware configuration would be a smart ethernet card (one
with built-in processor) and wire it up to a power supply.  But
since you asked for cheapest, grab a klunker 8088 pc and a cheap
Ethernet board.  You can pick up the pc cheaper than the ethernet
card.  If it has a packet driver you can run some free PC based
TCPs in less than 64K total system memory.  Total cost should be
about $200 US (guessing here).

Erick

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

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 1992 06:17:41 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: getpeername...help

In article <1992Apr9.204125.9519@ncsu.edu> pmarimut@eos.ncsu.edu (PERAM  MARIMUTHU) writes:
>How can I use the getpeername function to get the name of the machine
>that is connected to a socket. The following code returns the internet
>address (a.b.c.d) correctly but not the name.

As far as the socket library is concerned, the "name" of a TCP or UDP
socket is its IP address and port.

>What should I do next?

To convert an IP address into a host name, use gethostbyname().
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 92 13:34:39 GMT
From:      subbarao@phoenix.Princeton.EDU (Kartik Subbarao)
To:        comp.protocols.tcp-ip
Subject:   Re: getpeername...help

In article <kuaco5INN72u@early-bird.think.com> barmar@think.com (Barry Margolin) writes:

>To convert an IP address into a host name, use gethostbyname().

You meant gethostbyaddr().

	-Kartik

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 92 14:52:48 GMT
From:      wswietse@wsbs06.bs.win.tue.nl (Wietse Venema)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: LPR on a terminal server, Opinions?

mike@gordian.com (Michael Thomas) writes:


>   I am considering writing a LPRd for a terminal/printer server (from
> RFC 1179).  The obvious win with implementing LPR within a terminal server
>is that no special host software is needed. The loses, however, appear to be
>many. The basic problem is that LPR expects another unix system on the remote
>side with spooling capabilities, and various output filters. A terminal
>server is a limited environment though (how many have you seen with 100 meg
>drives? ;-).

There may be a simpler alternative. This is what we do:

Some terminal servers allow you to "reverse" one or more ports. The 
result is that a connection to a user-defined socket number on the
terminal server gives bidirectional access to one of its serial ports.

On the UNIX host we run a trivial program that connects a pty (master
end) to the above-mentioned socket on the terminal server. The link
is bidirectional.

In order to access the printer, the lpd daemon opens the pty (slave
end) just like any hard-wired serial port. 

    lpd <--> pty <--> daemon <--> server <--> printer

This setup works fine with our postscript printers.

	Wietse

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 1992 15:06:18 GMT
From:      swhite@tybse1.uucp (William C. "Spike" White)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Question: installing NCSA


I can probably help you out.  I administer  a TCP/IP LAN that currently 
includes FTP Software's PC/TCP running on one PC and NCSA Telnet running on two
other PC's.

And you're right.  It sounds like you inherited a lot of bogusity.  IFCUST.SYS
and IPCUST.SYS are used by the PC/TCP software -- they aren't needed by
NCSA Telnet.  I can check on ETHDRV, I forget which one uses that.

And I think you've got the best idea.  Remove all that crud and install
NCSA Telnet from scratch.  If you had complete docs, etc. to PC/TCP, I'd
say install it since it's a more complete implementation.

If you want more info, write.  I tried to send e-mail (USENET & Internet), but 
it bounced both ways.

-- 
Spike White
e-mail: swhite@afseo.eglin.af.mil uunet!sci34hub!tybrin4!tybse1!swhite

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 1992 15:58:36 GMT
From:      petav@Physik.TU-Muenchen.DE (Peter Averkamp)
To:        comp.protocols.tcp-ip
Subject:   Re: ping question

pwickman@cerebus.cc.edu (Paul J. Wickman) writes:


>	Does anybody have the code for the Sun/IBM/whatever version
>of ping?  The one that can report "host is alive" in addition to the
>verbose mode?

I have a derivative of the berkeley ping, that responds with 0 or 1,
respectively, especially for scripts. It's called 'isup'.
( You see the point: if `isup mymachine` then doobeedoo... )
Drop me a mail if this is of any use for you.

- Peter -

--
Peter Averkamp,                      | email:
Physics Department E20               | petav@radon.e20.physik.tu-muenchen.de
Techn. Univ. of Munich               | Phone: ++49 (89) 3209-2408
D-8046 Garching, Germany             | Fax:   ++49 (89) 3209-2338

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 92 16:14:43 GMT
From:      matthews@advtech.uswest.com (John Matthews)
To:        comp.protocols.tcp-ip
Subject:   Utility to trace processes sending packets?

Does anyone know of a utility or way to figure what processes are
sending what packets or what active sockets belong to what processes?

				John Matthews
				matthews@advtech.uswest.com

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 92 19:01:23 GMT
From:      spacelab@milton.u.washington.edu (Jessie Chang)
To:        comp.unix.admin,comp.protocols.tcp-ip,comp.sys.mips
Subject:   tftp time out booting X terminal

Hi there,
   I encountered a problem when I try to boot several ( 3 at least)NCD
terminals all at the same time. ( Performed a power failure test) 

I use a MIPS R3330 as their configuration and font server.  Some of NCDs will
time out on tftp and kick into PROM mode and some will come up without being 
able to load fonts files.

   I try to change the /etc/inetd.conf's tftp from wait to nowait.  That causes
me more problrem due to the race condition.  I can't change the time-out
value in NCD since it is in the PROM.

Any suggestion, 

Thanks 

----
Jessie Chang     spacelab@u.washington.edu    (206)882-4003
Clinical Information System Group, SpaceLabs, Inc.
Redmond, WA

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 92 19:29:00 GMT
From:      rex@nbc1.ge.com (Rex Espiritu)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Terminal Servers

Subject: TCP/IP Terminal Servers (possibly w/ LAT, too)

We're currently exploring and evaluating possible TCP/IP Terminal Servers
for our network.  We're just in the initial stages...  So, product literature
and/or recommendations/advantages/disadvantages would be greatly appreciated.
-- 
M. Rex Espiritu, Jr.                      Carnegie Group, Inc.
espiritu@cgi.com                          5 PPG Place
Voice: 412 642-6900 x233 FAX: -6906       Pittsburgh, PA  15222

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 1992 19:38:51 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: getpeername...help

In article <kuaco5INN72u@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>To convert an IP address into a host name, use gethostbyname().

Shouldn't that be gethostbyaddr?

Warner
-- 
Warner Losh		imp@Solbourne.COM
If it can't be done with Emacs, you are being too ambitious.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 92 22:04:52 GMT
From:      pjangli@afterlife.ncsc.mil (Philip Anglin)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR on a terminal server, Opinions?

In article <3293@svin02.info.win.tue.nl> wswietse@bs.win.tue.nl writes:
>mike@gordian.com (Michael Thomas) writes:
>
>
>>   I am considering writing a LPRd for a terminal/printer server (from
>> RFC 1179).  The obvious win with implementing LPR within a terminal server
>>is that no special host software is needed. The loses, however, appear to be
>>many. The basic problem is that LPR expects another unix system on the remote
>>side with spooling capabilities, and various output filters. A terminal
>>server is a limited environment though (how many have you seen with 100 meg
>>drives? ;-).
>
>There may be a simpler alternative. This is what we do:
>
>Some terminal servers allow you to "reverse" one or more ports. The 
>result is that a connection to a user-defined socket number on the
>terminal server gives bidirectional access to one of its serial ports.
>
>On the UNIX host we run a trivial program that connects a pty (master
>end) to the above-mentioned socket on the terminal server. The link
>is bidirectional.
>
>In order to access the printer, the lpd daemon opens the pty (slave
>end) just like any hard-wired serial port. 
>
>    lpd <--> pty <--> daemon <--> server <--> printer
>
>This setup works fine with our postscript printers.
>
>	Wietse

We have this type of setup, but it breaks all the time (broken pipes).
The program is some public-domain thing called collect that our
terminal server vendor gave us.

-- 
Name:         Philip J. Anglin
Mail address: pjangli@afterlife.ncsc.mil
Disclaimer:   Opinions stated are those of the author alone,
              not the Department of Defense or the U.S. Government.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Apr 92 00:13:47 GMT
From:      johnw@medisg.Stanford.EDU (John Wiederhold)
To:        comp.protocols.tcp-ip
Subject:   PD FTP without Telnet, List of PD Packages, and FAQ?


This is a probably all included in a FAQ (or should be) but I haven't
seen one for this group.

I'm looking for a FTP program for msdos that uses packet drivers but
does not require a telnet session first, like NCSA does.  Public
domain is prefered, but commercial is ok too.  We looked at FTP Software's
PC/TCP package but it requires to much resident memory for the device
drivers, etc.  I'm looking for a program that includes the TCP/IP stack
internally like NCSA.


I'm also interested in a list of the different Public domain TCP/IP
packages out there.  I know of NCSA and Clarkson, and that Kermit
supports one telnet session.  Whatelse is out there?  What are the advantages
and disadvantages of each?


-Thanks..
John Wiederhold



-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Apr 1992 04:42:00 GMT
From:      karl@ddsw1.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   LPD backend on a PC?

Has anyone written a publically-available backend for LPD which runs on a
PC?  Ideally it would spool to local fixed disk storage and then despool to
the printer.

Source is preferred, of course...

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

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 92 23:44:21 GMT
From:      sob@hsdndev.UUCP (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   FDDI & token ring router & bridge tests at Harvard


Well, its that time again.  I'm starting a new round of router &
bridge tests.  This round will deal with FDDI & token ring using the
following arangements: (DUT = Device Under Test, a router or a bridge)

    -------------  -----------  --------------
   /             \ |         | /              \
  < fddi ring #1  >|   DUT   |<  fddi ring #2  >
   \             / |         | \              /
    -------------  -----------  --------------

    --------------  -----------  ---------------
   /              \ |         | /               \
  < token ring #1  >|   DUT   |<  token ring #2  >
   \              / |         | \               /
    --------------  -----------  ---------------

    --------------  -----------        -----------  ---------------
   /              \ |         |        |         | /               \
  < token ring #1  >|   DUT   |==WAN===|   DUT   |<  token ring #2  >
   \              / |         |        |         | \               /
    --------------  -----------        -----------  ---------------

          -----------  ---------------  -----------
up to-----|         | /               \ |         |----- up to
  6  -----|   DUT   |<   fddi ring     >|   DUT   |-----   6
Enets-----|         | \               / |         |----- Ethernets
          -----------  ---------------  -----------

    --------------  -----------  -----------  -----------  --------------
   /              \ |         | /           \ |         | /              \
  < token ring #1  >|   DUT   |<  fddi ring  >|   DUT   |<  token ring #2 >
   \              / |         | \           / |         | \              /
    --------------  -----------  -----------  -----------  --------------

Tests will be run using a number of protocols to measure throughput and
aggregate packet handling ability.  The tests will be run in the Harvard
Network Device Test Lab in Cambridge MA.

The results of the tests will be reported during my tutorial and at a BOF
on Wed night at Interop in DC in May.  The results will also be put
on hsdndev.harvard.edu for anonymous FTP and appear in an article in Data
Communications.

If you have any suggestions for specific tests please let me know.

The tests are open to all vendors who would like to show up, there is no
fee.  There two required and one suggested condition for inclusion:

required:
	1/ the router or bridge hardware and software must be available to
	customers within 3 months of Interop or at the next "normal"
	software release if a calandar-based schedule is used.
	2/ all results of the tests will be reported unless superceded
	during the test period with other results. (i.e. you are allowed
	to fix bugs)

suggested:
	a vendor representative should be present during the tests to
	do the device setup to ensure that it is done correctly.

Please contact me via email at the address below or via phone at
617-495-3864 if you would like to be included.


	Scott Bradner
	sob@harvard.edu

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Apr 1992 01:55:18 GMT
From:      caugherd@cs.rpi.edu (Dan Caugherty)
To:        comp.protocols.tcp-ip
Subject:   *HELP* with PC/IP utility NetWatch!!!

To Whom It May Concern --

I have a question regarding M.I.T.'s Netwatch.  I'm currently using an
IBM-AT compatible with a 3com 501 board and MS C 5.0.  When I run a
newly compiled version of Netwatch, no packets are displayed; however,
when I run the same executable (compiled, etc.  2 years ago -- well
before I had even heard of the package, and when its name was still
NETWATCH.EXE, not 3NETWATC.EXE, PNETWATC.EXE, etc.), it will display
any packets that I care to see.  (Interesting twist: when I run my
newly-compiled version first, the older version fails to display
anything as well!)  Has anyone else had this problem?  Also, can
anyone suggest steps for its correction?  I'm planning on adding
IGP-sniffing capabilities to the package (for credit in a Networking
Software course), so I could use all the replies I can get.

Gratefully yours,

Dan Caugherty   caugherd@cs.rpi.edu   C.S. Dept.,
Rensselaer Polytechnic Institute, Troy, NY  12180-3590
----------------------------------------------------------------------

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Apr 1992 02:26:03 GMT
From:      freed@tfs.com (Erik Freed)
To:        comp.protocols.tcp-ip
Subject:   VMTP/XTP availability

I am interested in the experiences of anyone who has implemented/ported/ or
written applications using VMTP. I am investigating this protocol for internal
use and while I know that it is an RFC and was I think proposed as a standard
for inclusion in the internet suite, I have heard very little other that the
original V kernel stuff as far as real world usage. It seems better that its
limited acceptance warrants. Am I missing something? 

I am also interested in xtp which seems to be owned or at least implemented
by a company called Protocol Engines that was going to use VLSI to speed
up some of these protocols. Any knowledge of this company or users of XTP
would also be welcome. 
	Thanks in advance,
-- 
		-Erik Freed (freed@tfs.com)

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 92 05:25:09 GMT
From:      sklower@diva.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: default address mask selection for a point-to-point network?

In article <BOB.92Apr9155631@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
(A reasonably accurate analysis of deficiencies of subnetting provided
with 4.3BSD per se):
>The need for consistency between interfaces is, I think, an artifact
>of deficiencies in some vendors' 4.3BSD-based code, or perhaps in
>4.3BSD itself.  I haven't examined tahoe, reno, BSDI, or 4.4 to see
>what they do.

I'm grateful that Bob acknowledges that Berkeley may have rectified
historical shortcomings.  This restriction was removed in the
4.3-reno release, the ATT free parts of which have been available for
anonymous ftp since the summer of 1990.

>And BSD netmasks are stored in per-interface information,
>not in the routing table.

This has also been fixed since the summer of 1990.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Apr 1992 14:06:20 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: Minimal ping object?

In article <1992Apr9.220041.15081@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes:

>	What is the absolute cheapest pingable object I can put on an
>ethernet?  I supose to be practical, I should limit the field to
>commercially available devices, but just for fun, let's assume I was
>willing to build or modify something as long as it's reasonable (and no,
>I'm not exactly sure what the limits of reasonable are).

An 8088 clone with an 8-bit NIC, running NCSA Telnet in server mode (booted
from a floppy)? No monitor or keyboard needed, so it should be about $300
or so; less if you have one holding a door open somewhere.

You might see if The Beholder (from tudelft) responds to pings (I haven't
looked at it closely enough yet; it does incorporate some SNMP stuff, so
it should answer a ping). It should fit on a floppy, too.

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

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Apr 1992 14:14:09 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: PD FTP without Telnet, List of PD Packages, and FAQ?

In article <1992Apr11.001347.26908@leland.Stanford.EDU> johnw@medisg.Stanford.EDU (John Wiederhold) writes:

>This is a probably all included in a FAQ (or should be) but I haven't
>seen one for this group.

Ah, but there are *so many* frequently ask questions....  :-)

>I'm looking for a FTP program for msdos that uses packet drivers but
>does not require a telnet session first, like NCSA does.

????? Which version of NCSA are you using? 2.3b (beta) at least includes
an FTPBIN program which does not require running the TELBIN program first.
I've used it occasionally, and it seems to work fine.


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

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 92 15:00:04 GMT
From:      pnessutt@qii.sialis.com (Robert A. Monio)
To:        comp.unix.admin,comp.protocols.tcp-ip,comp.sys.mips
Subject:   Re: tftp time out booting X terminal

In article <1992Apr10.190123.22693@u.washington.edu> spacelab@u.washington.edu writes:
>   I encountered a problem when I try to boot several ( 3 at least)NCD
>terminals all at the same time. ( Performed a power failure test) 
>
>I use a MIPS R3330 as their configuration and font server.  Some of NCDs will
>time out on tftp and kick into PROM mode and some will come up without being 
>able to load fonts files.

We have 2 RS1210s and we've encountered the same problem.  Apparently tftpd
can't handle having multiple requests for the same file at the same time.
We were told by MIPS to boot each unit individually so as to avoid the
problem.  I don't know if this is a fix or not but it does seems to work.

>   I try to change the /etc/inetd.conf's tftp from wait to nowait.  That causes
>me more problrem due to the race condition.  I can't change the time-out
>value in NCD since it is in the PROM.

Hmm.  I hadn't thought of trying this, although I think I'll stay away from
it based on the problems your having.  Good luck in resolving your situation.

 -Bob


-- 
 Robert A. Monio                         "We've always earned our money the
 Quality Institute International, Inc.    old-fashioned way.. 
 pnessutt@qii.sialis.com                  WE BEAT PEOPLE FOR IT!"
 ..uunet!rosevax!sialis!qii!pnessutt         -- Paul Ellering, "Legion of Doom"

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 92 21:57:24 GMT
From:      venkat@metrix.UUCP (D Venkatrangan)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   IP using 802.3 framing and DSAP=SSAP=6

Hi tcpipers,

I am trying to determine the following about 802.3 framing.

1. RFC 1060 (Assigned Numbers) assigns a Link Service Access Point (LSAP)
   value of 6 for DOD IP.  Is this use of LSAP recommended/prevalent?

2. The other method of encapsulating IP over 802.3 is through the
   SNAP encapsulation (using LSAP of 170).  On this, the RFC says:

	   At an ad hoc special session on "IEEE 802 Networks and ARP", held
	   during the TCP Vendors Workshop (August 1986), an approach to a
	   consistent way to send DoD-IP datagrams and other IP related
	   protocols (such as the Address Resolution Protocol (ARP)) on 802
	   networks was developed, using the SNAP extension (see RFC-1010 and
	   RFC-1042 [90]).

   Does this mean that the first method above is "Obsolete"

3. I have a customer who has reported problems because the NFS he is
   running is based on the first method of IP framing.  He reports that
   "dataless HPs" use the first method of framing.  Should we take into
   effect the existence of framing of the first type?

4. If we have the first method of framing, does the IP header immediately
   follow the LLC Control Field?  We have a DSAP of 6, SSAP of 6 and a
   Control field of 3 -- is this followed by the IP Version number and
   header length byte?

Thanks very much for any information on this subject.

Please respond directly to venkat@metrix.com


---------------------------------------------------------------------------
D. Venkatrangan
Metrix Inc.			One Tara Blvd, Nashua, NH 03062
venkat@metrix.com		VOICE: (603) 888-7000 FAX: (603) 891-2796
---------------------------------------------------------------------------



-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 92 04:19:31 GMT
From:      as6n@uvacs.cs.Virginia.EDU (Ambar Sarkar)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   sockets and asynchronous message passing.

Dear ____________

   I am trying to use non blocking asynchronous datagram message passing 
on sockets. Typically, on SunOS 4.1.1, I need to do the following steps:

0. sock = socket(AF_INET, SOCK_DGRAM, 0);

1. fcntl( sock, F_SETFL, (FASYNC|FNDELAY)) 
   FASYNC: Generates SIGIO/SIGPOLL on receiving message.
   FNDELAY: Nonblocking

2. fcntl( sock, F_SETOWN, getpid()) 
   To identify myself as the recipient.

Assume I have already installed the handler and enabled interrupts.

Since F_SETOWN and FASYNC are just not there in fcntl.h, 
I tried the following on the local sysv3.2 and it works(NOT!).

0. sock = socket(AF_INET, SOCK_DGRAM, 0);

1. ioctl(sock, FIOASYNC, &one)  	/* int one = 1 */
   should generate SIGPOLL ?

2. ioctl(sock, FIONBIO, &one)  		/* int one = 1 */
   make receive non blocking.

3. ioctl(sock, SIOCSPGRP, &pidno) 	/* int pidno = getpid() */
   should deliver SIGPOLL to me?

FIONBIO works, I get nonblocking recvfrom.
I have no idea what is happening with steps 1 and 3. Just cannot get 
to generate the SIGPOLL on receipt of a message on socket!
The same sequence of steps work on SunOS, however.

So what have I missed in the first place? I admit being naive.

Any help/suggestion will be appreciated.

Ambar Sarkar(as6n@virginia.edu)

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 92 06:51:57 GMT
From:      tony@suite.sw.oz.au (Tony McGrath)
To:        comp.protocols.tcp-ip
Subject:   RDP (Reliable Datagram Protocol) implementation needed.

I am looking for implementations of RDP for Unix, either socket
based or STREAMS. If you have such a beast, could you let me
know by email and/or send me a copy of it.

Also, I would be happy to see any code for the Loader Debugger Protocol
(RFC-909) as well.

Tony McGrath				Phone: +61 2 698 2322
Senior Software Engineer		Fax:   +61 2 699 9174
Softway Pty Ltd				Email: tony@softway.sw.oz.au

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Apr 1992 09:43:37 GMT
From:      bill@chaos.cs.umn.edu ()
To:        comp.unix.admin,comp.protocols.tcp-ip,comp.sys.mips
Subject:   Re: tftp time out booting X terminal

pnessutt@qii.sialis.com (Robert A. Monio) writes:

>In article <1992Apr10.190123.22693@u.washington.edu> spacelab@u.washington.edu writes:
>>   I encountered a problem when I try to boot several ( 3 at least)NCD
>>terminals all at the same time. ( Performed a power failure test) 
>>
>>I use a MIPS R3330 as their configuration and font server.  Some of NCDs will
>>time out on tftp and kick into PROM mode and some will come up without being 
>>able to load fonts files.
 
>We have 2 RS1210s and we've encountered the same problem.  Apparently tftpd
>can't handle having multiple requests for the same file at the same time.
>We were told by MIPS to boot each unit individually so as to avoid the
>problem.  I don't know if this is a fix or not but it does seems to work.
 
>>   I try to change the /etc/inetd.conf's tftp from wait to nowait.  That causes
>>me more problrem due to the race condition.  I can't change the time-out
>>value in NCD since it is in the PROM.
 
>Hmm.  I hadn't thought of trying this, although I think I'll stay away from
>it based on the problems your having.  Good luck in resolving your situation.

i'm going to have to agree on it being the tftp server. we have the same
problems using ibm 130 xstations, and an rs6k mod 550. when i fire up 
the bootpd and tftp processes to allow the xstations to boot, if i turn them
all on at once, then most will fail to start.

--
bill@chaos.cs.umn.edu

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 92 15:21:10 GMT
From:      tjg01@thdhub.UUCP (Terry Gardner)
To:        comp.protocols.tcp-ip
Subject:   Reverse telnet


What is 'reverse telnet'? I've seen it advertised by some PC net software
vendors, but I've never heard of it.

-- 
Terry Gardner, terry@thdhub, terry%thdhub@uunet
Senior Network Systems Programmer @ The Home Depot, Inc.
404-433-8211 x 5124 Message Generated with GNU Emacs 18.58...
Aborting, Retrying, Failing, and Ignoring.....

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Apr 92 17:01:48 GMT
From:      pct@leo.stanford.edu (Peter C Tam)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Intel EtherExpress 16/16TP Clarkson Driver


HI,
  I am looking for a better, improved, bug fixed version of Intel EtherExpress
16/16TP FTP spec/Clarkson packet driver than the one provided by the hardware
vendor.
  Thanks for any help........

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 92 19:03:19 GMT
From:      battle@cs.utk.edu (David Battle)
To:        comp.protocols.tcp-ip
Subject:   mayonnaise

In draft-ietf-rreq-iprouters-03.txt Philip Almquist seems to have allowed:

225   mayonnaise                                                             |
226                     A thick salad dressing or condiment made with oil    |
227                     and egg                                              |

What does this have to do with Requirements for IP Routers?

-David L. Battle
battle@cs.utk.edu

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 92 19:34:59 GMT
From:      ddb0248@mcnews.mcdata.com (David Beal)
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   ARP over FDDI and "canonical bit order"

OK, somebody straighten me out here.  I'm reading the "Proposed Standard
for the Transmission of IP Datagrams over FDDI Networks" (RFC 1188), and I'm
confused.   The document says 

	"In order to not preclude interoperability in a bridged environment,
	the hardware addresses in ARP packets (ar$sha, ar$tha) must be
	carried in 'canonical' bit order...the addresses must be bit-reversed
	within each octet."

The origin of this requirement is presumably the fact that on FDDI,
bytes are transmitted msb first, while on ethernet, they're transmitted
lsb first, plus the fact that the IEEE inexplicably chose to assign
MAC addresses by saying "this is the first bit transmitted", rather
than saying "this is the most significant bit".

I understand that following the above rule should make a FDDI host 
work with a host on a bridged ethernet, because when forwarding
a frame between the dissimilar media, the bridge would maintain *bit
transmission order* on the MAC destination and source addresses,
but would maintain *most-significant/least-significant bit order* on
the remainder of the frame.  Therefore, when either of the boxes receives
an ARP request, he would use the canonically ordered source hardware
address as the destination address of his reply.  OK, fine.

But now what happens when two FDDI hosts try to talk to each other ?
When one host receives a ARP request and tries to use the canonically
ordered source hardware address as the destination of his reply,
it's in the wrong bit order to put out on the FDDI network.  The responding
host can't detect that the other host is also on FDDI, because the
document says that all ARP frames transmitted on FDDI should contain
a hardware type field of 1, which makes everybody look like they're
on ethernet.

Is this standard broken, or am I confused ?  And, while we're at it,
how does this work on token ring, which has the same bit order as FDDI ?

(Please reply by email; I'll summarize.)

- Dave Beal
  McDATA Corporation
  Broomfield, CO 
  ddb@mcdata.com

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Apr 1992 21:19:28 GMT
From:      fontenot@ravl.rice.edu (Dwayne Jacques Fontenot)
To:        comp.protocols.tcp-ip
Subject:   socket-based IPC question: EINTR

Hello,

What is the proper way to handle EINTR? Currently, I am ignoring it,
but I suspect there is a better way. I can't find much information
on it..and none on how to handle in in the man pages or in the
"Advanced" Socket-based IPC tutorial.

thank you for your time,

Dwayne Fontenot (fontenot@ravl.rice.edu)


-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Apr 1992 23:07:00 GMT
From:      mark_silbernagel@mentorg.com
To:        comp.protocols.tcp-ip
Subject:   Re: tftp time out booting X terminal



In deep, dark recesses of memory I seem to recall that *some* tftp daemons had
a sort of security check where too many requests in a short period would cause
tftpd to stop for a while. The assumption was that it was an attack across the
net.

It was discovered to be a pain when they found that the new, fast workstations
could ask for that many in a very short period of time.

Or, maybe it was inetd protecting tftpd with that mechanism.

You get the idea.

If you're wondering, I'd recommend asking the server's vendor.

Mark

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Apr 1992 01:05:20 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: mayonnaise

 David> == David Battle <battle@cs.utk.edu> 

 David> In draft-ietf-rreq-iprouters-03.txt Philip Almquist seems to
 David> have allowed:

225   mayonnaise                                                             |
226                     A thick salad dressing or condiment made with oil    |
227                     and egg                                              |

 David> What does this have to do with Requirements for IP Routers?

I believe the technical term for this is a "joke" or, to be more
precise, "humorous glossary entry inserted because the author or editor
was feeling rather whimsical".

If you have problems with this, do not, I repeat do not, look in the Sun
_Customer Distributed BugsList_, December 1990 edition, and do not look
at the copyright page, and most definitely do not look at the entry
which reads "SPAM(R) is a registered trademark of a pork product packed
only by Geo A. Hormel & Co. Corp."

I also encourage you not to investigate any RFC issued on April 1st of
any year (particularly RFC 1149 and RFC 1097).

Oh, and :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
--
Christopher Davis <ckd@eff.org> |    ECONOMIC OBSERVATIONS DEPARTMENT
System Manager & Postmaster     |  "There's always something going out of
Electronic Frontier Foundation  |      business in Central Square."
+1 617 864 0665  NIC: [CKD1]    |   -Rita Marie Rouvalis <rita@eff.org>

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 92 03:40:39 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: ARP over FDDI and "canonical bit order"

In article <1992Apr14.193459.28218@mcnews.mcdata.com>, ddb0248@mcnews.mcdata.com (David Beal) writes:
> OK, somebody straighten me out here.  I'm reading the "Proposed Standard
> for the Transmission of IP Datagrams over FDDI Networks" (RFC 1188),...

An ARP frame on the ring contains two addresses in the MAC header (one
often broadcast) in FDDI bit order.  An FDDI ARP frame also contains MAC
addresses in its body, but in ethernet bit order.

All FDDI stations expect this, and do what's necessary.  There's no
reason for them to be confused.
 
>                                                          ... The responding
> host can't detect that the other host is also on FDDI, because the
> document says that all ARP frames transmitted on FDDI should contain
> a hardware type field of 1, which makes everybody look like they're
> on ethernet.

The reasoning behind bridges is that you can't tell if the other guy is on
the same fiber as you, on an ethernet bridged to your fiber, or even a
fiber bridged to an ethernet bridged to your fiber.

Thus, we all transmit hardware type 1 in ARP packets, but many of us are
prepared to accept 6.

As long as everyone uses packet sizes <= 1500 bytes, everything works
fine.  The bridges reverse the bits of the MAC headers as they copy between
ethernet and fiber.  That is among the easy parts of making an FDDI
bridge.


> Is this standard broken ....


Things work just fine, as long as everyone is willing to give up as much
as 60% of their performance by not using 4KByte frames.


Vernon Schryver,  vjs@sgi.com

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 92 13:04:11 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   cheap rarp server

We are running LAN WorkPlace for DOS ver. 4.0 on a handful of PCs, and
we expect that number to grow significantly by the end of this year.
We are fairly committed to LWP 4.0 because of cost, flexibility and
ORACLE client-server support.

We also have 4 UNIX-base hosts: HP 827s, HP 817s, SCO UNIX/386 and DG
AViiON AV200.  Given the choice between RARP server and BOOTP server,
the first 3 support BOOTP service only and the last supports BOOTP
service only.  Currently, the PCs don't use RARP, but by the end of the
year, I expect things will be getting messy.

Now for the question.

I would like to set up _somewhere_ on the LAN another RARP server (or
more), but would like a cheap way of doing it, e.g., on an 8088 PC with
LAN board, for example.

If anybody is aware of any software for the PC, or of any code which can
be ported to the HP or SCO platforms - heck, any cheap suggestions -
could you please direct me to the appropriate source.

Many thanks.

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

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 92 14:04:54 GMT
From:      jcc@gna.axis-design.fr (Jean-Christophe Collet)
To:        comp.protocols.tcp-ip
Subject:   proxyarp sources described in RFC 1027 ?

Hello folks,

In the RFC 1027, Carl Mitchell & Quaterman described a set of modifications
to apply in BSD 4.3 sources that implement the proxyarp.
It mentions an ftp site (sally.utexas.edu), but it does not exist anymore!
Does anybody there who knows where I could find those diffs ?
Any help would be greatly appreciated.
Please reply by Email.

Thanx a lot in advance

-- Jean-Christophe (aka "Jessie")
   jcollet@expdat.gna.org

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 92 15:06:17 GMT
From:      d3ky03w@shoes.BELL-ATL.COM (Sheets)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Sun routing software

Is this a bug with Sun's routing software (and if so, is there a patch)?

I assign two default routers to a Sun so that if router 1 is down it will look
to router 2 for any packet routing.  This did not work, but does work on
HP 9K series 300 and 700 running hpux 8.05 and 8.07 (the Suns are running 4.1.1).
If router 1 is down, the Sun will either time out or recieve an ICMP source
quench message.  The HP will look in its routing table for an alternate gateway,
whereas the Sun does not.  The Sun will allow you to enter multiple default
routers in the routing table.

The routers are Wellfleet LN and/or CN at release 5.5


Alan Sheets (d3ky03w@shoes.bell-atl.com)

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Apr 92 15:28:49 GMT
From:      demon@sequent.com (Dave Richards)
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: ARP over FDDI and "canonical bit order"

In article <1992Apr14.193459.28218@mcnews.mcdata.com> ddb0248@mcnews.mcdata.com (David Beal) writes:
>And, while we're at it,
>how does this work on token ring, which has the same bit order as FDDI ?

I thought Token Ring used the same order as FDDI too.  However, when we
started doing our interoperability testing, we found that it was not true.
I added a new flag to our ARP implementation which is defined during
initialization which indicates whether the interface uses canonical or
non-canonical MAC addresses.  Currently Ethernet, IEEE 802.3 and FDDI use
the canonical form and IEEE 802.5 uses the non-canonical form.  Which
is a pain, because I'm starting to turn bytes upside down in my sleep. :-)

	Dave Richards
	Sequent Computer Systems

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 92 17:03:23 GMT
From:      car@public.BTR.COM (Carlos Rimola-Sarti  car@btr.com)
To:        comp.protocols.tcp-ip
Subject:   Screen Sharing via TCP/IP


I am looking for a "screen sharing" program that runs on an PC using
TCP/IP (e.g. FTP Software).  Something along the lines of Carbon Copy
would do.  The only packages that I have heard of all use serial lines.

Any help would be appreciated..

+---------------------------------------+-----------------------------------+
| Carlos Rimola-Sarti                   |         email: rimola@csisdn.com  |
| Connective Strategies Inc.            |                      car@btr.com  |
| ISDN PRI Connectivity Group           |         phone:      415-903-2585  |
 +---------------------------------------+-----------------------------------+

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 92 17:50:05 GMT
From:      koning@koning.enet.dec.com (Paul Koning)
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: ARP over FDDI and "canonical bit order"


In article <1992Apr14.193459.28218@mcnews.mcdata.com>, ddb0248@mcnews.mcdata.com (David Beal) writes:
|>OK, somebody straighten me out here.  I'm reading the "Proposed Standard
|>for the Transmission of IP Datagrams over FDDI Networks" (RFC 1188), and I'm
|>confused.   The document says 
|>
|>	"In order to not preclude interoperability in a bridged environment,
|>	the hardware addresses in ARP packets (ar$sha, ar$tha) must be
|>	carried in 'canonical' bit order...the addresses must be bit-reversed
|>	within each octet."
|>
|>...
|>But now what happens when two FDDI hosts try to talk to each other ?
|>When one host receives a ARP request and tries to use the canonically
|>ordered source hardware address as the destination of his reply,
|>it's in the wrong bit order to put out on the FDDI network.  The responding
|>host can't detect that the other host is also on FDDI, because the
|>document says that all ARP frames transmitted on FDDI should contain
|>a hardware type field of 1, which makes everybody look like they're
|>on ethernet.
|>
|>Is this standard broken, or am I confused ?  And, while we're at it,
|>how does this work on token ring, which has the same bit order as FDDI ?
|>
|>(Please reply by email; I'll summarize.)
|>
|>- Dave Beal
|>  McDATA Corporation
|>  Broomfield, CO 
|>  ddb@mcdata.com

No, it's not broken.  It's not surprising you get confused; address encoding
is one of the most confusing aspects of the various LAN standards.

The way it works is that you have to do the necessary transformation between
the canonical form address in the ARP message and the address that the FDDI
MAC is going to put on the wire.  In some MACs, you can put them in a mode
where the addresses (DA and SA) are in fact given to the chip in canonical
form and the chip flips them.  In other MACs, you get to do the job in the
device driver.  That takes 6 lookups in a 256-byte table; obviously, the
place to do that is in ARP processing, not in the main data packet transmit
loop...

For token ring it would be nice if the same approach had been used, but 
unfortunately there were already a lot of implementations out before people
realized the problem.  So there ARP messages are sent with backwards
addresses.  Then again, there are so many other strange things that token
ring to anything else bridges have to do anyway, that ARP repair is a 
minor problem by comparison.  Not so for FDDI...

	paul

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 92 20:26:17 GMT
From:      dburr@nixhub.UUCP (Donald Burr)
To:        comp.protocols.tcp-ip,comp.sys.mac.misc,comp.sys.mac.comm,comp.unix.misc
Subject:   NET (i.e. ka9q) for Mac -- where is it?


I am running the KA9Q Internet Protocol Package, v890421.1 + kd8wk.3a on
my AT&T UNIXPC.  Since I have a direct serial line connection with my Mac,
I would like to be able to run TCP/IP over it.  I heard from somewhere
that a version of the KA9q package was ported to the Mac.

Unfortunately, I haven't been able to successfully find a copy.  Then
again, I only know of a few major Mac FTP sites.  The stuff I'm looking
for is probably on some small FTP site that has some Mac stuff on it
somewhere...

If anyone can locate the site that has the KA9Q package for the Mac,
I'd appreciate it greatly.  Or, if you have the stuff yourself and would
be willing to mail a copy, that would be acceptable too.

Please send email to dburr@sbphy.physics.ucsb.edu.  I know it's not in
my .signature yet, but that's because it's a new account.

many Thanks in advance!
 
+-----------------------------------+-----------------------------------------+
: Donald Burr, System Administrator : dburr@gnu.ai.mit.edu <==New!   INTERNET :
: NixBBS Public Access UNIX         : dburr%nixhub.UUCP@uunet.uu.net ======== :
: Carpinteria, CA  USA              : America Online: DonaldBurr              :
: UUCP: ...!uunet!nixhub!dburr      : Send all flames to /dev/null            :
+-----------------------------------+-----------------------------------------+

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Apr 1992 20:37:55 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Screen Sharing via TCP/IP

 car@public.BTR.COM (Carlos Rimola-Sarti  car@btr.com) writes:
>
>I am looking for a "screen sharing" program that runs on an PC using
>TCP/IP (e.g. FTP Software).  Something along the lines of Carbon Copy
>would do.  The only packages that I have heard of all use serial lines.
>

FTP to sunee.uwaterloo.ca and get pub/wattcp/telnetd.zip.  It provides
VT100 or VT200 emulation for remotely controlling your pc.  Since
both the local and remote keyboard can enter keystrokes and watch
the screen, this is a good solution for remotely controlling networks
or providing consulting.

Erick

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

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Apr 1992 20:38:01 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: mayonnaise

In article <CKD.92Apr14210342@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>225   mayonnaise                                                             |
>226                     A thick salad dressing or condiment made with oil    |
>227                     and egg                                              |
>
>I believe the technical term for this is a "joke" or, to be more
>precise, "humorous glossary entry inserted because the author or editor
>was feeling rather whimsical".

Actually, i think the correct term is "cute", usually used in a
derogatory manner implying that the author is either not mature
enough or not funny enough.
						don provan
						donp@novell.com

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 92 21:22:01 GMT
From:      jlundell@vixvax.mgi.com
To:        comp.protocols.tcp-ip
Subject:   Two Novice Questions

Hi,

I have two very novice questions. 

First, could someone tell me the semantics of the 32 bit TCP/IP address,
a.b.c.d. My guess is that they are related to the given network & domain.

Second, could someone also tell me in laymans terms what & how one would
use a socket. My understanding is that a socket is a 3-level address --
network, host/node, & port. How is this different than simply requesting
the services of a well defined port???

Thanks in advance!

================================================================================
| Jim Lundell                                                                  |
| System Software Engineer              Internet:   jlundell@mgi.com           |
| Management Graphics, Inc.             Voice Mail: (612) 851-6174             |
| 1401 East 79th Street                 Operator:   (612) 854-1220             |
| Minneapolis, MN  55425                Fax:        (612) 851-6159             |
================================================================================

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Apr 1992 22:46:39 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: mayonnaise

In article <1992Apr15.203801.10478@novell.com> donp@novell.com (don provan) writes:
>In article <CKD.92Apr14210342@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>>225   mayonnaise                                                            
 [...]
>>I believe the technical term for this is a "joke" or, to be more
 [...]
>
>Actually, i think the correct term is "cute", usually used in a
>derogatory manner implying that the author is either not mature
>enough or not funny enough.

If maturity is what makes people come up with OSI-like standards (or
the whole standardize-first-test-later approach, for that matter),
I'll stick with the immaturity of the Internet world, thank you.

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 1992 03:32:41 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Two Novice Questions

In article <1992Apr15.162201.1778@vixvax.mgi.com> jlundell@vixvax.mgi.com writes:
>I have two very novice questions. 

I could give simple answers in this followup, but I think you would be
better served by getting a good book, such as "Unix Network Programming" by
Stevens, or "Internetworking with TCP/IP" by Comer.  They can do a much
more thorough job than is possible in this medium.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Apr 1992 07:48:23 GMT
From:      chuck@comp.vuw.ac.nz (Chuck Qun Zheng)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: Sun routing software


> Is this a bug with Sun's routing software (and if so, is there a patch)?
 
> I assign two default routers to a Sun so that if router 1 is down it
 will look
> to router 2 for any packet routing.  This did not work, but does work
 on
> HP 9K series 300 and 700 running hpux 8.05 and 8.07 (the Suns are
running 4.1.1).

You guess right. It is a bug, told by a Sun Technical Manager.  He suggested
me to use gated.  I set up gated on both Sun3 & Sun4 router (Sun3 as primary),
and can complete my rlogin across networks even when a router is down.  NFS/
kernel code can handle this situation as well, provided you got DNS right.

One sad news is that sun automounter cannot cope with this.  I am looking for
amd some time later
-- 
---------------
Chuck Qun Zheng
Telecom Corperate Office of New Zealand
Wellington, New Zealand

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 14:19:43 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   pd ftp without telnet

Recently johnw@medisg.Stanford.EDU (John Wiederhold) writes:

(request for PD or commercial FTP software package....)

John, we're currently using Novell's (formerly Excelan's) LAN WorkPlace
for DOS which runs over Novell's ODI.  Pretty good, allows for a wide
variety of NICs.  I selected this over Beame & Whiteside, FTP Software,
Wollongong, and another one (the name of which escapes me now) for
reasons of cost (about CA$1800.00 for 10-user pkg.), compatibility
(allows for Novell's IPX protocol concurrently), flexibility (didn't
need to buy a package specific to my needs or hardware, like FTP
Software), and support (corporate commitment to Novell, Oracle support
extremely desireable for client-server).  I suppose I should mention
memory:  No drivers get loaded from CONFIG.SYS, and the requisite ones
can be loaded/unloaded in a BAT file.  Caveat:  There's a known bug in
TELAPI.EXE which doesn't release two file handles upon unloading from
RAM, hence if, for example, your FILES=30 (in CONFIG.SYS), then you'll
notice odd problems (e.g., File Creation Error) after your 15th unload.
Of course, you can up your FILES= value to delay the problem, but the
probability of going in and out of telnet this many times is low.
Hmm...just realized that telnet isn't the issue here.  Since FTP.EXE
doesn't need TELAPI.EXE, you're all set.

Having said that, you may want to consider Beame & Whiteside's TCP/IP
package.  This was the one serious contender against LWP, but because
the Oracle support was lacking....  One of the bonus features of this
vendor's package is that it can use the Clarkson packet drivers.  In
fact, I've seen a history file (which was included in the PD sniffer
developed at on of the universities in Holland - "Netcure," perhaps?)
which mentioned Carl Beame's contribution to the Clarkson packet
drivers.  Naturally, B&W claim that their implementation is the fastest
performer, a claim I cannot prove or disprove.  If you're already using
Clarkson packet drivers, this may be the ticket for you.

A question to all (putting on the Corporate Hat):  If we were to move to
Clarkson packet drivers, whose neck would be on the line for support?

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

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 11:55:09 GMT
From:      bill@falcon.cs.uofs.edu (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: mayonnaise

In article <CKD.92Apr14210342@loiosh.eff.org>, ckd@eff.org (Christopher Davis) writes:
|> 
|> If you have problems with this, do not, I repeat do not, look in the Sun
|> _Customer Distributed BugsList_, December 1990 edition, and do not look
|> at the copyright page, and most definitely do not look at the entry
|> which reads "SPAM(R) is a registered trademark of a pork product packed
|> only by Geo A. Hormel & Co. Corp."
|> 
|> I also encourage you not to investigate any RFC issued on April 1st of
|> any year (particularly RFC 1149 and RFC 1097).
|> 
|> Oh, and :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

And especially, Do Not under any circumstances look up RECURSION in the old
UCSD PASCAL Manual from Softech Microsystems.

There are a lot of frustrated stand-up comics in the computer biz.   :-)

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>   

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 15:10:49 GMT
From:      neerma@cod.NOSC.MIL (Merle A. Neer)
To:        comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: ARP over FDDI and "canonical bit order"

>|>for the Transmission of IP Datagrams over FDDI Networks" (RFC 1188), and I'm
>|>confused.   The document says 
>|>
>|>	"In order to not preclude interoperability in a bridged environment,
>|>	the hardware addresses in ARP packets (ar$sha, ar$tha) must be
>|>	carried in 'canonical' bit order...the addresses must be bit-reversed
>|>	within each octet."
>|>


All this talk about bit-swapping has me paranoid. I have an FDDI ring
and some ethernets..I have Timplex bridges connecting the two. My
hosts do no swapping of bits...neither do the bridges....all works well.
That is to say, if I generate a packet from my Ether host to the
FDDI host's 48 bit FDDI address, it gets there...yeah, sure bit 40
shows up first...but, who cares once the 48 bit address is put back 
together it looks just like new! I can understand the concern with
multicast since apparantly multicast numbers are defined in terms of
transmitted bit order (WHY?)...so mulitcasts on token and ether are
different...so if I want to form a group of FDDI hosts and ethernet
hosts I have to bit swap if I want to follow IEEE addressing scheme...but
I could do this without any swapping at the bridges and certainly without
swapping the whole damn world....



Where am I losing it? I am trying real hard to understand the problem
that bit swapping solves but (obviously) having difficulty..

Also, is bit swapping at the bridges prevalent in other products?

Merle

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Apr 1992 17:26:41 GMT
From:      merlyn@iWarp.intel.com (Randal L. Schwartz)
To:        comp.protocols.tcp-ip
Subject:   Re: mayonnaise

In article <10682@platypus.uofs.uofs.edu>, bill@falcon (Bill Gunshannon) writes:
| And especially, Do Not under any circumstances look up RECURSION in the old
| UCSD PASCAL Manual from Softech Microsystems.

And especially, no, not ever, no, do *not* look at more than half of
the glossary entries in "Programming Perl".  Things like:

	Regular Expression:   /Oh s.*t./

(And yes, recursion and iteration *both* have Hofstaeder-like
definitions.)

| There are a lot of frustrated stand-up comics in the computer biz.   :-)

Hey, I've been doing technical documentation since 1978.  *Every time*
I get to the glossary, I've wanted to throw in a joke term or two, but
it never made it past the editor.  "Programming Perl" released a lot
of pent-up tensions. :-)

Just another technical (joke) writer,
-- 
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III      |
| merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn |
\=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 18:44:44 GMT
From:      werme@alliant.com (Ric Werme)
To:        comp.protocols.tcp-ip
Subject:   Re: mayonnaise

In article <1992Apr15.203801.10478@novell.com> donp@novell.com (don provan) writes:
>In article <CKD.92Apr14210342@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>>225   mayonnaise                                                             |
>>226                     A thick salad dressing or condiment made with oil    |
>>227                     and egg                                              |
>>
>>I believe the technical term for this is a "joke" or, to be more
>>precise, "humorous glossary entry inserted because the author or editor
>>was feeling rather whimsical".
>
>Actually, i think the correct term is "cute", usually used in a
>derogatory manner implying that the author is either not mature
>enough or not funny enough.

Another possibility is that the author wanted to see how many people were still
reading spec all the way into the index.  I remember one spec with a line to
the effect "If you read this sentence, please let me know."  The author wanted
to verify his suspicion that the marketroids never based their plans on what
the engineers were doing.
-- 
| A pride of lions               | Eric J Werme                   |
| An odd lot of programmers      | uucp: mit-eddie!alliant!werme  |
| A Constitution of Libertarians | Phone: 508-486-1214            |

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 20:05:02 GMT
From:      catone@drachma.wharton.upenn.edu (Tony Catone)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Question: installing NCSA

In article <92095.145647K3006E7@ALIJKU11.BITNET> K3006E7@ALIJKU11.BITNET writes:
   In the config.sys, IPCUST.SYS and IFCUST.SYS are loaded.  In
   the autoexec.bat, the commands:
		  NE2000.com 0x60 0x3 0x300
		  ETHDRV
   I think these are old "FTP Software"  that was put into our
   hard-disk when the local administrator hooked up our pc to
   the network.  Unfortunatly, he left absolutely no documentation
   behind.

You can order the doc from FTP Inc if you want it.  Ipcust.sys and
ifcust.sys are two device drivers that FTP Inc's PC/TCP package (and
Interdrive) use to hold IP numbers and other site configuration.
Ethdrv is the generic ethernet kernel for PC/TCP.  You can buy
versions of PC/TCP either for use with a specific ethernet card, or
for any ethernet card that supports a packet driver (FTP Inc created
and maintains the packet driver spec).  The latter version requires
ethdrv to be loaded before PC/TCP will successfully run.  The
advantage is that one can unload ethdrv and free memory for other
applications with the "inet unload" command.

If you get the documentation, you will find that PC/TCP does vt100,
vt2xx, vt3xx and tn3270 emulation.  If you are having problems, you
are using the wrong commands.  There is a lot not to like about
PC/TCP, but it certainly does connect up to archie systems, standard
unix boxes, etc.  with very little difficulty.

That said, we used to use PC/TCP almost exclusively, but now have
switched to NCSA Telnet as our standard telnet/ftp application.  NCSA
has a nicer interface, more flexibility, and new versions and features
appear with more speed than PC/TCP.  In addition, the advantages of
having source code available are obvious.  There are several versions
of the NCSA doc for 2.3, but none are really great (though all are
much better than the 2.2 doc).  I have been working in my spare time
to clean up the doc and fix some of its errors, give it a real table
of contents and an index, etc (amusingly enough, I use the same
editor/formatter package FTP Inc used to create their 2.05 doc).  If
anyone is interested in this, drop me a note and I will post to the
group when it is done (give it two to three weeks, I think, the end of
the semester is pretty busy).

Commenting out the line in the autoexec.bat that loads ethdrv will
solve your problem.  You can leave the ipcust.sys and ifcust.sys lines
in the config.sys if you want to be able to run PC/TCP also (just load
and unload the generic kernel as you need), but they take up a few K
of memory and you may as well remove them if you just want NCSA
(that's what we do).  Drop a line if you need more specifics.


- Tony
  catone@dmark.wharton.upenn.edu

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 21:59:27 GMT
From:      manmetha@gauss.rutgers.edu (Manju Mehta)
To:        comp.protocols.tcp-ip
Subject:   Evaluating Routers


Hi Netters,
	We are in the process of evaluating routers for a WAN we need
to set up. Any suggestions as to what brands may be better than others
will be appreciated. Any notes on comparisons based on
COST/PERFORMANCE, ease of configuration, ease of setup, etc. would be
most welcome.

	Any and All responses welcome,
		Thanx,


MAN.

manmetha@gauss.rutgers.edu

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 22:10:16 GMT
From:      meb@BEAU.ATLANTA.DG.COM (Michael Brown)
To:        comp.protocols.tcp-ip
Subject:   tcp protocols (like rpc)

Does anyone know of any other higher-level protocols like RPC, that run on TCP/IP?
Apollo's NCS is another example...

-----------------
Michael E. Brown
meb@atlanta.dg.com

switch( opinion ){
case MINE:
	printf( "YES\n" );
	break;
case OTHERS:
	printf( "NO\n" );
	break;
}

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 22:34:12 GMT
From:      rlk@VisiCom.COM (Bob Kitzberger)
To:        comp.protocols.tcp-ip
Subject:   Re: mayonnaise

In article <10682@platypus.uofs.uofs.edu> bill@platypus.uofs.edu writes:
>|> 
>|> I also encourage you not to investigate any RFC issued on April 1st of
>|> any year (particularly RFC 1149 and RFC 1097).
>|> 
>|> Oh, and :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
>
>And especially, Do Not under any circumstances look up RECURSION in the old
>UCSD PASCAL Manual from Softech Microsystems.

...nor look up "camels" in "Programming Perl",  

...nor "laziness", "hubris", "great programmer", and "impatience" in the 
same book.    

...nor more apropos for this group, "carrier pigeon" in the same book. 

...nor "squirrel" in the original K&R C...


Any more, and this'll belong in alt.folklore.something-or-other

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
			+1 619 457 2111    FAX +1 619 457 0888

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 22:47:01 GMT
From:      thsssxs@iitmax.iit.edu (Semir Sirazi)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   SNMP and TCP/IP over TokenRing



		Hello out there, I will state in advance that I am new to this
	forum, and want to follow proper etiquette. Please inform me if I 
	don't do so.

		I have been sorting through news and mail from years and
	months past and have not come across what I am looking for. Maybe
	someone out there can give me a little direction.

		What I am looking for is a SNMP agent and accompanying
	protocol stacks (TCP|UDP/IP) that run over a TOKEN-RING network. Is 
	there is a commercial or public domain package that anybody knows of
	that provides libraries, toolkits, or source code, that will allow
	me to embed this functionality into an INTEL based system.  
	
		I would appreciate any information that you might have that
	could steer me in the right direction.

					Thanks,
						Keith Zimmerman

		Please send all responses to:

				Keith Zimmerman
				thsssxs@iitmax.iit.edu

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 92 23:04:27 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Negative ping times

What is it that causes ping to report negative times like the following?

PING 128.189.1.2: 56 data bytes
64 bytes from 128.189.1.2: icmp_seq=0. time=-500. ms
64 bytes from 128.189.1.2: icmp_seq=1. time=-560. ms
64 bytes from 128.189.1.2: icmp_seq=2. time=-800. ms
64 bytes from 128.189.1.2: icmp_seq=3. time=-580. ms

----128.189.1.2 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms)  min/avg/max = -800/-610/0

Frank.
--
___________________________________________________________________
Frank I. Reiter                Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 92 06:03:36 GMT
From:      mwitt@ogicse.ogi.edu (Mike Witt)
To:        comp.protocols.tcp-ip
Subject:   Re: Negative ping times


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

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 92 09:29:16 GMT
From:      stephan@cs.kuleuven.ac.be (Stephan Biesbroeck)
To:        comp.dcom.lans.misc,comp.protocols.tcpip
Subject:   PC integrating in a TCP/IP network ???


Hello,

I an looking for a sort of inventory of products (public domain and
commercial) to integrate PC's in a tcp/ip network.
I once saw a list on the net describing packages such as ka9q, pcroute, ...
Can someone send me that list. Or give me any pointers to products to
integrate a PC in a TCP/IP network ???

Thanks,

Stephan Biesbroeck
KULnet
Katholieke Universiteit Leuven
stephan@cs.kuleuven.ac.be

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 92 14:59:04 GMT
From:      Frank@mindlink.bc.ca (Frank I. Reiter)
To:        comp.protocols.tcp-ip
Subject:   Re: Negative ping times

> Mike Witt writes:
> 
> Frank,
> 
> Sometimes on a very fast optical link, packets can actually
> exceed the speed of light.

I figured that's all it was.  Thanks Mike.  <Grin>

Frank.
--
___________________________________________________________________
Frank I. Reiter                Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 92 15:09:57 GMT
From:      Dean.Roth@mixcom.mixcom.com (Dean.Roth)
To:        comp.protocols.tcp-ip
Subject:   3B2 client-server latency problem


I'm new to an organization that has a server running on
a 3B2.  I've seen a large latency between when data is
sent by a client and when the read in the server completes.

I created test client and server programs that simply 
exchange a 1K block of data. When run on any machine
other than the 3B2 the latency between write and read 
is nearly zero. However, when both the client and server
operate on the 3B2 there is a 1-2 second lag between the
client's write and when the server's read completes.

I've never worked with a 3B2 before. Is this behavior
characteristic of this machine?  The software is using 
the socket API.  Thank you.

Dean

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Apr 1992 16:52:57 GMT
From:      ratlifc@prometheus.stu.rpi.edu (Christian A. Ratliff)
To:        comp.protocols.tcp-ip
Subject:   Re: 3B2 client-server latency problem

In article <1992Apr17.150957.17268@mixcom.com> Dean.Roth@mixcom.mixcom.com  
(Dean.Roth) writes:
}
}I'm new to an organization that has a server running on
}a 3B2.  I've seen a large latency between when data is
}sent by a client and when the read in the server completes.
}
 [stuff deleted]
}I've never worked with a 3B2 before. Is this behavior
}characteristic of this machine?  The software is using 
}the socket API.  Thank you.
}


  Yeah. This is _very_ characteristic since every packet has to pass from  
kernel space into user space and then into kernel space and then into user  
space again while going through the etherd. It's thoroughly annoying for  
those of us who want fast networking and use 3B2s.


--------
Christian A. Ratliff               Rensselaer Polytechnic Institute
ratlic@rpi.edu                     113 9th St.  Troy, NY 12180
ratlifc@eclipse.its.rpi.edu        <NeXT Mail Accepted at all addresses>

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 92 18:26:24 GMT
From:      chinson@chin.cs.ucla.edu (Chinson Yi)
To:        comp.protocols.tcp-ip
Subject:   Router Info. Request


Hello, Fellow Netters 

We are looking for good high performance routers.  Cisco and Wellfleet
came to our attention.  I would like to hear from Cisco and Wellfleet users 
regarding its reliability, performance, and other maintenance related 
issues.  I would like to hear about other router recommendations also.

Thanks in advance

-- 
   /\~ /\      O\_  "I think my golf ball landed around here."
 ~/\/\/  \~  +--\\\                          
~~ ~~~~~ ~~  |  /|@       
/      \   \ !  \ \  Chinson Yi (chinson@cs.ucla.edu 310-206-3584)

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 92 19:54:27 GMT
From:      tksjmi@sybil.cs.Buffalo.EDU (JoAnn Illuzzi)
To:        comp.protocols.tcp-ip
Subject:   MacTCP 2.0 availability?


 Has anyone received MacTCP version 2.0?  I thought it had been
 announced as available a while back, but I only see MacTCP 1.1
 for single user and site license use.

 Input/clarification appreciated
 JoAnn

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 92 20:26:39 GMT
From:      cage@cbnewsd.cb.att.com (charles.gerlach)
To:        comp.protocols.tcp-ip
Subject:   Re: 3B2 client-server latency problem

In article <rr#vfbr@rpi.edu> ratlifc@eclipse.its.rpi.edu writes:
>In article <1992Apr17.150957.17268@mixcom.com> Dean.Roth@mixcom.mixcom.com  
>(Dean.Roth) writes:
>}
>}I'm new to an organization that has a server running on
>}a 3B2.  I've seen a large latency between when data is
>}sent by a client and when the read in the server completes.
>}
 [stuff deleted]
>}I've never worked with a 3B2 before. Is this behavior
>}characteristic of this machine?  The software is using 
>}the socket API.  Thank you.
>}
>
>
>  Yeah. This is _very_ characteristic since every packet has to pass from  
>kernel space into user space and then into kernel space and then into user  
>space again while going through the etherd. It's thoroughly annoying for  
>those of us who want fast networking and use 3B2s.
>
>

Multiple passes through the kernel/user boundry was a characteristic of 
the initial 3B releases.  These were numbered R1.x.  I believe starting 
with Release 2.1, tcp was re-implemented using streams and this problem 
no longer exists.  The only applications that make multiple passes in 
the newer are those that use the pty subsystem.  And in SVR4 that was 
taken care of.

The current release is 3.2 for SVR3 systems.  If you are running a release 
that is older than R3.2, I would strongly recommend you figure out how to 
get yourself upgraded.  (R3.0 was O.K, but R3.2 is better.)  R3.2 has been 
out for several years now, so hopefully it is readily available.  

If you are still suffering with etherd, you have my admiration.  R3.2 will
not solve all your problems, but at least it will be closer (by about 5 
years of development).

				Chuck Gerlach
				NCR
				cag@iwlcs.att.com

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 92 20:57:31 GMT
From:      kohjin@marina.prug.or.jp (Kohjin Yamada JR1EDE)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP CD-ROM by SRI International

Hello all netlanders,

 Does someone have an access to "TCP/IP CD" from SRI International?
I would like to know how to order from overseas.
		(FYI, SRI stands for Standford Research Institute.)
Their E-mail address or any kind of input will be appreciated.

 Thanks, Kohjin
-- 
      *---/---*         E-mail: {uunet}!reseau!sting!jh1ynw!marina!kohjin
    *----/----*         CIS: Kohjin Yamada, JR1EDE [76662,111]
  Q-----T------H        AMPR: kohjin@jr1ede.marina.ampr [44.129.20.128]
*------/|-------*       PBBS: JR1EDE@JR1EDE.11.JNET1.JPN.AS "Share and Enjoy!"

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Apr 92 09:19:01 GMT
From:      cmf851@huxley.anu.edu.au (Albert Langer)
To:        comp.protocols.tcp-ip
Subject:   Re: CONS over TCP or TP4

My proposal to run OSI CONS over TCP and TP4 doesn't seem to have aroused
much indignation or enthusiasm, except for a minor objection concerning
(a) suggested implementation method to delimit Protocol Data Units (PDUs) 
as required for OSI, cf the continuous byte stream usually seen by TCP users.

I would still appreciate any comments on the main theme.

Meanwhile I am cross-posting to comp.protocols.tcp-ip, with follow-ups
to comp.protocols.iso, in the hope that somebody might be able to
authoritatively settle the technical issue concerning TCP.

My suggestion was to SEND the last octet of each PDU with both the
PUSH flag and URGENT flag in a separate buffer by itself, so it
will be delivered as the last octet in an IP or whatever segment,
that has both PUSH and URGENT flags, with the URGENT pointer pointing
to the last octet of the segment. The next segment would either be
similar, for a complete next PDU, or else would have neither PUSH nor URGENT
flags and would therefore belong to an incomplete next PDU which would not 
generate a signal to the destination user until the end octet of that 
next PDU was itself received in a segment that has both PUSH and
URGENT flags.

In article <1992Apr17.000825.6489@novell.com> donp@novell.com 
(don provan) quotes me and writes:

>>But note that I said the urgent pointer could be used to "mark the END octet"
>>of the Protocol Data Unit (emphasis added).
>
>The point is that only the last urgent pointer in the data stream is
>preserved.  If either the sending or receiving TCP implementation
>happened to have two of your PDUs together in the same queue, it would
>be perfectly legitimate (almost mandatory, actually) for it to pitch
>the earlier of the two urgent pointers.  In that case, you'd lose your
>end of PDU information for the first PDU.

Thanks for the follow up. I appreciate the advice as it will be VERY useful 
if correct, to avoid blundering down a dead-end, and there is no harm done 
if it turns out to be wrong. But I'm still not convinced (and therefore
perhaps still in danger of blundering down that dead-end unless somebody
can settle the issue :-)

I still maintain that having ensured there will be two separate IP or
whatever segments at the desired boundary between PDUs is sufficient to
ensure there will be two separate READ buffers, and that is sufficient
to ensure the PDU boundary can be detected.

According to RFC 793 (on TCP):

"If a PUSH is seen before the buffer is filled the buffer will be returned
partially filled and PUSH indicated".

"If there is urgent data the user will have been informed as soon as it
arrived via a TCP-to-user signal."

"Note that data following the urgent pointer (non-urgent data) cannot
be delivered to the user in the same buffer with preceding urgent data
unless the boundary is clearly marked for the user."

My interpretation of the above is that with any correctly implemented TCP,
the user should be able to determine that particular READ buffers include
exactly one end octet of a PDU (and hence that any other READ buffers were 
part of the previous PDU). 

There are clear warnings in RFC 793 that:

"The number of times the sending user's TCP signals urgent will not
necessarily be equal to the number of times the receiving user will
be notified of the presence of urgent data."

and also that PUSH cannot be used as a PDU delimiter.

My proposal does not rely on either of PUSH or URGENT separately, but
on a VERY restricted use for the two together.

I believe the two combined should work as described above
and I am sufficiently confident of that to keep arguing back against
people who are undoubtedly more familiar with TCP than I am.

On the other hand, my practical experience with TCP is ZERO, so I
would certainly welcome any explanation of where I have misunderstood.

Also, if I have understood the RFC correctly, it still might be the
case that there are widespread implementations that do not enforce
separate READ buffers in the way implied by the RFC, and I would 
appreciate any information about that.

BTW, any takers on CONS over TCP?


-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Apr 1992 13:45:45 GMT
From:      tkevans@fallst.UUCP (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Utility to trace processes sending packets?

leonard@telcom.arizona.edu (Aaron Leonard) writes:

>In article <1992Apr10.161443.16134@advtech.uswest.com>,
>matthews@advtech.uswest.com (John Matthews) writes:
>|>Does anyone know of a utility or way to figure what processes are
>|>sending what packets or what active sockets belong to what processes?
 
>Try:
 
>$ MULTINET SHOW /CONNECTIONS=(ALL,PROCESS)/CONTINUOUS
 
>(Oh ... you're not running VMS+MultiNet?  Then what operating system
>*are* you running?)

In SunOS, use 'etherfind'
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 92 15:20:12 GMT
From:      scoggin@daisy.udel.edu (John K Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Internet Capacity Planning

We  have built a fairly large internet internet carrying TCP/IP, SNA, and
DECnet.  Currently, planning is done by the seat of the pants.

Does anyone have any methodology they would like to share pertaining to
capacity planning of TCP/IP and/or multi-protocol internets?

Many thanks for any info.  If there is sufficient response, I will summarize
to the net...

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

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Apr 1992 23:03:35 GMT
From:      matthews@advtech.uswest.com (John Matthews)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.mac,comp.lang.postscript
Subject:   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?

I know that TOPS can do this and that I can buy other products that will
spool to a PC that has a serial/parallel attached printer but I was hoping
to find something that would allow me to use all existing localtalk/ethertalk
attached laserwriters the way TOPS does.  I am just wondering if there are
any other intelligent software solutions besides TOPS, Mt Xinu, and Cayman
GatorBox.  In other words, I'm wondering if there are any other solutions
that run on the Mac-side.

				Thanks in advance,
					John Matthews

-- 
John Matthews               Internet:  matthews@uswest.com
10305 Dover St.  #732       UUCP:      uunet!uswest.com!matthews
Broomfield, CO  80237       Phone:     (303) 438-1474

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Apr 92 01:33:50 GMT
From:      cariapa@Tied-House.Stanford.EDU (Sandeep Cariapa)
To:        comp.protocols.tcp-ip
Subject:   rarpd checking software

Hello, 
	I'm looking for something that would broadcast a REVarp request (given an
Ethernet address) and return the following: 
1. An internet address corresponding to the ethernet address I specified.
2. The hostname (or IP address) of the machine with the rarpd server that
responded to my request.

	This seems trivial, but I haven't been able to find any PD software that
does it. I've also been looking through my references (Stevens, Comer vol I, the
Sun Networking Manual, and the trusty man pages) but couldn't find anything to
help me write something on my own.  

	I guess my first question is whether any PD software is available. My
second question is directed to the net.gurus (you know who you are!). What 
books can I look at for help? Does Comer vol II contain a more detailed
explanation of the implementation of these protocols? 
 
	I believe other netters would be interested in a summary, so yes, I will
post one. 
Gracias,

-- 
 Sandeep Cariapa, cariapa@eecf.stanford.edu, (415) 723-1004 (work address)
 System programmer, EECF, Stanford University. 
 If you can't convince 'em, confuse 'em.

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 02:13:42 GMT
From:      pytlik@cs.umb.edu (Marek Pytlik)
To:        comp.protocols.tcp-ip
Subject:   Text on RPC

Can anyone recommend beginners text on RPC coding? 
Please reply by email. to pytlik@cs.umb.edu.
Thanks






-- 
Marek 

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 1992 03:22:54 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Utility to trace processes sending packets?

In article <1992Apr19.134545.12263@fallst.UUCP> tkevans%fallst@wb3ffv.ampr.org writes:
>>In article <1992Apr10.161443.16134@advtech.uswest.com>,
>>matthews@advtech.uswest.com (John Matthews) writes:
>>|>Does anyone know of a utility or way to figure what processes are
>>|>sending what packets or what active sockets belong to what processes?
>In SunOS, use 'etherfind'

Read the question again...

I've used etherfind many times, and I've never seen process IDs in its
output.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Apr 1992 03:39:00 GMT
From:      larry@reg.triumf.ca (Lawrence Clarke)
To:        comp.protocols.tcp-ip
Subject:   Re: pd ftp without telnet

In article <199216.1070.8085@dosgate>, "william mercer" <william.mercer@canrem.com> writes...
> 
>Having said that, you may want to consider Beame & Whiteside's TCP/IP
>package.  This was the one serious contender against LWP, but because
>the Oracle support was lacking....  One of the bonus features of this
>vendor's package is that it can use the Clarkson packet drivers.  In
>fact, I've seen a history file (which was included in the PD sniffer
>developed at on of the universities in Holland - "Netcure," perhaps?)
>which mentioned Carl Beame's contribution to the Clarkson packet
>drivers.  Naturally, B&W claim that their implementation is the fastest
>performer, a claim I cannot prove or disprove.  If you're already using
>Clarkson packet drivers, this may be the ticket for you.
> 

Where can I get more info on B&W's tcp/ip programs?



-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 04:10:33 GMT
From:      libes@cme.nist.gov (Don Libes)
To:        comp.protocols.tcp-ip
Subject:   Re: mayonnaise

In article <174@visicom.com> rlk@VisiCom.COM (Bob Kitzberger) writes:
>>And especially, Do Not under any circumstances look up RECURSION in the old
>>UCSD PASCAL Manual from Softech Microsystems.
>
>...nor look up "camels" in "Programming Perl",  
>...nor "laziness", "hubris", "great programmer", and "impatience" in the 
>same book.    
>...nor more apropos for this group, "carrier pigeon" in the same book. 
>...nor "squirrel" in the original K&R C...
>
>Any more, and this'll belong in ....

"Life with UNIX"?  Being as it was, a collection of garbage
accumulated by this poster and a friend over their lifetimes, the
book's index includes the obligatory recursive reference (done a
little differently than the 'usual' way) as well as particularly
unique ones for "OSF", "VMS", and numerous other subjects.  I guess
that's why the index was 26 pages - in a reduced font, no less.

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 12:05:50 GMT
From:      bill@banana.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp printer servers

k@hprnd.rose.hp.com (Steve Kao) writes:

>Why not get an HP LaserJet with the appropriate TCP/IP card?  You can
>then plug the printer directly onto the TCP/IP network.
 
>- Steve Kao

Does such an item exist?  I am aware only of the ethernet interface card
that supports only netware.

bill
-- 
these ravings are in no way sanctioned by federal express corp
bill daniels			| voice:  (901)797-6328
federal express corp		| fax:    (901)797-6388
box 727-2891, memphis, tn 38194 | email:  bill@banana.fedex.com

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Apr 92 21:21:56 PDT
From:      MAC@cup.portal.com (Michael Alan Casteel)
To:        comp.protocols.tcp-ip
Subject:   Sockets and broken TCP connections

Some quick questions on TCP connections via Sockets:

1. HP-UX docs say that SO_KEEPALIVE is needed to detect broken 
   connections, enabling 'end of file' for receivers and SIGPIPE
   for senders. Is this usual, not just HP-UX?

2. Does KEEPALIVE impose an unpleasant network overhead?

3. Since my current program (apparently) does not set SO_KEEPALIVE,
   there are TWO processes extant right now, both showing that they
   are connected on the SAME local port # (the first one, six days
   old, predated a crash on the remote computer). This doesn't seem
   right; surely only the current connection is really receiving on
   that port #? (The remote port #s are different).
--------Hmmm....and, Thanks In Advance for Enlightenment

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Apr 1992 14:52:51 GMT
From:      Edward Vielmetti <emv@msen.com>
To:        news.announce.newgroups,news.groups,comp.protocols.tcp-ip,alt.bbs.internet,ba.internet
Subject:   RFD:  comp.internet.access

this is a 2d time revised charter for a proposed new Usenet newsgroup.
i think it's pretty much ready to go for the "request for discussion"
phase. 

comp.internet.access
 
  With the explosion of internet growth, there's a great interest in
  getting people connected to the net.  comp.internet.access will try to
  help people get on the net, providing information about connections
  anywhere from low speed dialup access to high speed dedicated links.
 
  Some of the expected questions to be answered are
    - how do I register an MX record for my internet bbs?
    - where is a local public access or "Freenet" site in my area?
    - who has a good deal on SLIP or PPP internet connections?
    - what does it take to build a metro area IP net of my own?
    - how about internet-connected BBS systems?
 
  Part of the group's charter is to work for the development of user
  access guides and "yellow pages" directories to help answer these
  questions, not just for sites in the USA but for locations around the
  world.  Junk questions like "looking for an open terminal server in
  Cheese City" will be firmly but vigorously pointed towards the
  extensive Frequently Asked Questions list(s).  (hey, one per area
  code, right?)
  
  The group will be unmoderated.  

  Discussion is currently going on in alt.bbs.*,
  comp.protocols.tcp-ip, random comp.sys.* groups, and in a zillion
  other places on the net.  On the Well, the "..." conference (Polly?)
  Trade periodicals that cover this topic include John Quarterman's
  _Matrix News_, Jack Rickard's _Boardwatch Magazine_, and others.
  There is a frequently asked questions posting in "alt.bbs.internet"
  which covers a bit of this, plus the "nixpub" and "pubnet" lists.

tnx.  thinking about the "comp.internet.services" is going to take a
little longer, I want to try to get the gopher vote started and the
WAIS vote counted before I tackle that one.

--Ed

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Apr 1992 15:34:51 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Capacity Planning

In article <1992Apr19.152012.16453@udel.edu> scoggin@daisy.udel.edu (John K Scoggin) writes:
>We  have built a fairly large internet internet carrying TCP/IP, SNA, and
>DECnet.  Currently, planning is done by the seat of the pants.
>
>Does anyone have any methodology they would like to share pertaining to
>capacity planning of TCP/IP and/or multi-protocol internets?


This is an excellent question.  Please post to the group as there is probably
information, here, that will help everybody.

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

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 19:06:00 GMT
From:      dwal@kimbark.uchicago.edu (David Walton)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 2.0 availability?

In article <1992Apr17.195427.25794@acsu.buffalo.edu> tksjmi@sybil.cs.Buffalo.EDU (JoAnn Illuzzi) writes:
>
> Has anyone received MacTCP version 2.0?  I thought it had been
> announced as available a while back, but I only see MacTCP 1.1
> for single user and site license use.

MacTCP 1.1 is the latest version; it was released in late
September/early October.  If you want information on ordering it,
contact APDA at 800-282-2732.

David

-- 
David Walton            Internet: d-walton@uchicago.edu
University of Chicago   {  Any opinions found herein are mine, not  }
Computing Organizations {  those of my employers (or anybody else). }

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 19:11:32 GMT
From:      avalon@coombs.anu.edu.au (Darren Reed)
To:        comp.protocols.tcp-ip
Subject:   Re: Utility to trace processes sending packets?

barmar@think.com (Barry Margolin) writes:

>In article <1992Apr19.134545.12263@fallst.UUCP> tkevans%fallst@wb3ffv.ampr.org writes:
>>>In article <1992Apr10.161443.16134@advtech.uswest.com>,
>>>matthews@advtech.uswest.com (John Matthews) writes:
>>>|>Does anyone know of a utility or way to figure what processes are
>>>|>sending what packets or what active sockets belong to what processes?
>>In SunOS, use 'etherfind'
 
>Read the question again...
 
>I've used etherfind many times, and I've never seen process IDs in its
>output.

You probably need one of the ofiles variants to do this although
they will usually just associate a port/ip pair with a pid and user
and dont have continuous output, etc.

darren

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 20:23:48 GMT
From:      schansen@amc.com (Scott Hansen)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   SLIP Question.

I'm just starting to look into SLIP for remote access to
four or five sites.  The remote offices will be using PCs
to access a couple of UNIX machines (Sequent and Pyramid)
at our central office.  

One of the reasons for looking at SLIP over just dial-in is
remote printer support using 'lpd'.  I plan on using FTP's
PC/TCP+ on the PCs, but I'm undecided on how to handle the
4 or 5 incoming lines.  Is there such a thing as a 'SLIP
Server'?  Or do I have to hang the modems off a UNIX
machine which supports SLIP?

Any pointers or general help would be appreciated.

-Scott
-- 
==============================================================================
Scott Hansen (schansen@amc.com)           Sysop...:  The Crystal Chip 
Applied Microsystems Corporation          BBS.....:  (206) 226-6550    
Redmond, Washington  98073                Voice...:  (206) 882-5322

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 20:55:40 GMT
From:      ntm1477@dsacg4.dsac.dla.mil (Jared McNeal)
To:        comp.protocols.tcp-ip
Subject:   Slip on interactive 3.0


                Running Slip on UNIX INTERACTIVE version 3.0 ip/386

THIS IS A MODEM TO MODEM HOOKUP.
TCP/IP version  1.3
CAN I RUN NFS IF YES ON WHICH SYSTEM.
   
   A. Server-1 

    1. No Ethernet card
    2. tcpip is running
    3. slip is configured in the Kernel
    4. when the sysadm menu ask for HOST name what should i enter :
       My Host choices are:
         a. server-1 (this system)
         b. server-2
         c. slip1 with it's own address.
         d. slip2 with it's own address.
         e. what is your suggestion ?
    5. When the sysadm menu ask for HOST TARGET name what should i enter :
       My Host choices are:
         a. server-1 (this system)
         b. server-2 (the system with the net connection)
         c. slip1 with it's own address.
         d. slip2 with it's own address.
         e. what is your suggestion ?
    6. When the system asked for broadcast address ? what should i put?
    7. When the system asked for netmask i put 255.255.128.0 ?
       a.  what should i put ?
    8. When the system asked for gateway address ? what should i put?
-----------------------------------------------------------------------------
   A. Server-2 

    1. Connected to the net througt a netcard.
    2. tcpip is running
    3. slip is configured in the Kernel
    4. when the sysadm menu ask for HOST name what should i enter :
       My Host choices are:
         a. server-1 (system with no net card)
         b. server-2 (system with the net card)
         c. slip1 with it's own address.
         d. slip2 with it's own address.
         e. what is your suggestion ?
    5. When the sysadm menu ask for HOST TARGET name what should i enter :
       My Host choices are:
         a. server-1 (system with no net card)
         b. server-2 (the system with the net connection) (this system)
         c. slip1 with it's own address.
         d. slip2 with it's own address.
         e. what is your suggestion ?
    6. When the system asked for broadcast address ? what should i put?
    7. When the system asked for netmask i put 255.255.128.0 ?
       a.  what should i put ?
    8. When the system asked for gateway address ? what should i put?



			  Thank you 
			  Jared A McNeal
			  DSAC-TMA
			  please post on net and Email

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 20:56:46 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Servers

In article <1992Apr10.192900.19246@nbc1.ge.com>, espiritu@cgi.com (Rex Espiritu) wrote the following:
>Subject: TCP/IP Terminal Servers (possibly w/ LAT, too)
>
>We're currently exploring and evaluating possible TCP/IP Terminal Servers
>for our network.  We're just in the initial stages...  So, product literature
>and/or recommendations/advantages/disadvantages would be greatly appreciated.

Xylogics' Annex III terminal server is excellent.  It supports TCP/IP as
well as LAT.  Let me know if you need their number and I'll forward it
to you.

-- 
      Jesse W. Asher        NIC Handle:  JA268         Phone: (901)386-5061
                       Health Sphere of America Inc.
	       5125 Elmore Rd., Suite 1, Memphis, TN 38134
 Internet: jessea@homecare.COM                 UUCP: ...!banana!homecare!jessea

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 20:57:57 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp printer servers

In article <2480010@hprnd.rose.hp.com>, k@hprnd.rose.hp.com (Steve Kao) wrote the following:
>Why not get an HP LaserJet with the appropriate TCP/IP card?  You can
>then plug the printer directly onto the TCP/IP network.

Where can one find such a card?  I've never know that they had one.  Is
it from HP?  If not, do you have a phone number of the vendor?  Thanks.

-- 
      Jesse W. Asher        NIC Handle:  JA268         Phone: (901)386-5061
                       Health Sphere of America Inc.
	       5125 Elmore Rd., Suite 1, Memphis, TN 38134
 Internet: jessea@homecare.COM                 UUCP: ...!banana!homecare!jessea

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Apr 1992 21:57:32 GMT
From:      schmidt@ics.uci.edu (Doug Schmidt)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Info about ``Is Layering Harmful'' article...


Hi,

	I recently read the article ``Is Layering Harmful?'' by
Crowcroft et al. in the January 1992 issue of IEEE Network Magazine.
It appears that all the figures (1-7?) are missing.  Does anyone have
information on where to obtain these figures?!

	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

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 92 23:36:59 GMT
From:      ctdean@talaris.com (Chris Dean)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp printer servers


In article <1992Apr20.120550.29163@banana.fedex.com> bill@banana.fedex.com (bill daniels) writes:

>k@hprnd.rose.hp.com (Steve Kao) writes:
>
>>Why not get an HP LaserJet with the appropriate TCP/IP card?  You can
>>then plug the printer directly onto the TCP/IP network.
 
>>- Steve Kao
>
>Does such an item exist?  I am aware only of the ethernet interface card
>that supports only netware.

I believe that there are some third party (that is, not HP) people who
make TCP interfaces.   I don't know who, and I don't know how long
they've been shipping.

You also could buy a "Printer server in a box".  These devices have
special host software that send print jobs to a black box connected to
the Ethernet.  The black box then sends the the job through a parallel
port to the printer.  Milan is a good company to call, they make a
~ $1000 box.

If you want to spend some more serious money, you could buy a QMS or
Talaris printer that sits on the Ethernet.  I leave it to others to
comment on which is better.

Chris
-------------------------------------------------------------------------
Christopher T. Dean / Talaris Systems Inc. / Internet: ctdean@talaris.com

My opinions are my own, not my employers.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Apr 1992 00:38:52 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Standalone front-ends for SMTP, LPD, etc...

We would like to integrate some heavily hacked scripts that currently use
various non-IP transport mechanisms (OSI and UUCP) with TCP/IP. The easiest
way to do this would be to hook the TCP transport mechanisms in as routes
in our database. So, we need standalone client and server programs that will
operate like "uux". That is, you could do:

	smtp jaguar peter@jaguar.ferranti.com << \!
	<headers>

	<body>
	!

And have the program "smtp" send the message with appropriate error checking
and reporting. Similarly we'd like to use the LPD protocol. We also need
matching server programs to transfer stuff the other way.

The TCP/IP implementations we're building on top of are fairly old Lachman
and Excelan versions, and don't come with a usable sendmail (not that
sendmail can be easily hooked in in this fashion).

Suggestions?
-- 
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX  77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Apr 1992 02:42:27 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp printer servers

In article <1992Apr20.205757.13455@homecare.COM>, jessea@homecare.COM
 (Jesse W. Asher) wrote:
>In article <2480010@hprnd.rose.hp.com>, k@hprnd.rose.hp.com (Steve Kao) wrote:
>>Why not get an HP LaserJet with the appropriate TCP/IP card?  You can
>>then plug the printer directly onto the TCP/IP network.
>
>Where can one find such a card?  ... Is it from HP?

Yes, it's a recent HP product.  It's available for the whole
HP LaserJet line except for the IIP and IIIP.

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

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 92 10:31:22 GMT
From:      HEGE@finabo.abo.fi (Kaj H{ggman DC)
To:        comp.protocols.tcp-ip
Subject:   European Gateway Site requested

Hi!

I'm posting this for a friend in Greece who doesn't have access to
Usenet News. I hope I'm in the right newsgroup!
If you have bitnet-access, please reply to CDAZ02@GRTHEUN1
(Tom Lanaras).
Thanx!

 -=HeGe=-
Kaj H{ggman             Internet: Hege@abo.fi       Bitnet: Hege@finabo
]bo Akademi University  (Hepnet/span) Decnet/funet: (21905::)abovax::hege 
Computing Center        X.400: s=hege o=abo prmd=inet admd=fumail c=fi  
SF-20500 ]bo, FINLAND   Phone : +358-21-654467  Telefax : +358-21-654497
------------------------------------------------------------------------

From:	BITNET%Tom Lanaras CDAZ02   at GRTHEUN1 20-APR-1992 18:33:37.30
Subj:	wishes...
 
I have one question I would like to ask:
   Our University is an Interntet Class B site and is currenly
   looking to find a European site to support us, i.e. we would like
   to get a direct line to a site somewhere in Europe and pass
   our traffic through that site. We have no experience how to
   find such a site. Any suggestions/contact persons would be most
   welcome.
 
Regards
 
Tom

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Apr 1992 12:54:57 GMT
From:      jkshah@eos03a-16pa.eos.ncsu.edu (JYOTI KAMLESH SHAH)
To:        comp.windows.x,comp.protocols.tcp-ip
Subject:   How to get the Internet Address ?

Hi !

I am trying to find the procedure and/or requirements to get the internet
address for our org here.

Could some one point me to the right source ?

Thanks a bunch.

PS: comp.windows.x : Probably not the right newsgroup for this, but just
in case.

-Kamlesh




-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Apr 1992 13:31:08 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: Standalone front-ends for SMTP, LPD, etc...

In article <id.302P.9AC@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
=We would like to integrate some heavily hacked scripts that currently use
=various non-IP transport mechanisms (OSI and UUCP) with TCP/IP. The easiest
=way to do this would be to hook the TCP transport mechanisms in as routes
=in our database. So, we need standalone client and server programs that will
=operate like "uux". That is, you could do:
=
=	smtp jaguar peter@jaguar.ferranti.com << \!
=	<headers>
=
=	<body>
=	!
=
=And have the program "smtp" send the message with appropriate error checking
=and reporting. Similarly we'd like to use the LPD protocol. We also need
=matching server programs to transfer stuff the other way.

Have you considered uucp over TCP/IP? Or is is possible with your systems?
(Mine have instructions on how to set it up, but I never succeeded in 
getting it working.) That would let you use uux itself, with the server
stuff already in place.

=The TCP/IP implementations we're building on top of are fairly old Lachman
=and Excelan versions, and don't come with a usable sendmail (not that
=sendmail can be easily hooked in in this fashion).
=
=Suggestions?

I've got some Interlan v1.0 code....  I installed smail3, but haven't
been able to get the SMTP stuff working through the old Interlan code
(real wierd problem; it would originate a connection, but not respond 
to one); even had odd behavior under the newer package on another system.
Smail3 might help, or at least provide hackable source.

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

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 92 14:22:17 GMT
From:      glen@Cayman.COM (Glen B. Glater)
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 <1992Apr19.230335.16710@advtech.uswest.com> matthews@advtech.uswest.com (John Matthews) 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?

I know that you said that you were looking for things besides (list deleted)
but I wanted to make sure that everyone understood that this is exactly
what GatorPrint from Cayman Systems does.

Thanks.
--

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

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Apr 92 22:17:23 PDT
From:      MAC@cup.portal.com (Michael Alan Casteel)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP printer server

Regarding HP's new TCP/IP interfaces:

HP recently introduced 'Jet Direct' interface cards with TCP ethernet
support for Laserjets (IIs and IIIs). There are three cards (I don't
have the part numbers on me), two 'XIO' cards for anything but a IIIsi
(not II/IIIP's) and one 'MIO' card for the IIIsi. The two XIO cards
are BNC and 10-base-T respectively; the MIO card goes all three
ways.

The MIO card can be configured from the IIIsi front panel, the XIO
cards require bootp for configuration (e.g., IP address). They have
SNMP.

The only price I have heard is $895, although there is a promo in
the mail offering ONE for $199, presumably a try it-you'll like it
deal.

The card works. We've been testing TCP printer connections to HP's
MPE OS, and got our software working using one of the external boxes
(Emulex). The external boxes seem to have: (1) n-port configurations;
we've been testing a 4-port-plus-parallel-port box; (2) Serial and
maybe parallel (e.g. Centronics) interfaces; (3) local intelligence
for configuration, maybe security, LAT, telnet, etc.

HP's card plugs in to the printer, so it might offer higher data
rate than an external connection (particularly a serial one). The
HP 3000 code we had working with the Emulex server just worked with
the HP TCP card. Be careful: I think the Lan Man and Novell cards
are also called 'Jet Direct' now. BTW, HP has picked a fixed TCP
port address for the TCP cards.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 92 16:40:40 GMT
From:      cranch@novell.com (Christopher Ranch)
To:        comp.sys.dec,comp.protocols.tcp-ip
Subject:   Re: need DEC LAT code

In article <1992Apr16.230909.1273@cton.uucp> nicholas@cton.cton.com (Nick Hennenfent) writes:
>I need the names/addresses of companies that sell licensed DEC LAT.
>
>I will post a listing of what I receive. Thanks.
>

You email bounced.  The only place you can license LAT is from DEC.

Chris
---
Chris Ranch
Internetworking Products Division
Novell, Inc.  San Jose, CA
(408)473-8667  cranch@novell.com

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 92 16:42:46 GMT
From:      cranch@novell.com (Christopher Ranch)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: need SPX,IPX code

In article <1992Apr16.231113.1347@cton.uucp> nicholas@cton.cton.com (Nick Hennenfent) writes:
>I need the names/address of companies (if any) selling
>SPX/IPX code for a project I am working on.
>
>I will post a listing of what I receive. Thanks.
>

Your email bounced.  Contact our Austin TX developer relations group at
512-345-8380 for licensing info.

Chris
---
Chris Ranch
Internetworking Products Division
Novell, Inc.  San Jose, CA
(408)473-8667  cranch@novell.com

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 92 20:01:59 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Capacity Planning

I have just been asked to evaluate two products called LANSIM and SOFTBENCH for doing network planning.  They claim to be useful in playing the design what if games.  The company is called internetiX, and can be reached at 301 420 7900.

They claim in the documentation I was given that their customers include such people as NATO, several banks and even the 802.5 committee.  The products allow the evaluation of using bridges, routers, and repeaters, and can use LAN Analyzers such as the Network General Sniffer, to determine an existing networks characteristics.  When I am done with my evaluation I will see if I can post my results here (after all they won't belong to me).

-- 
Mark

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

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 92 20:38:26 GMT
From:      christos@dworkin.wustl.edu (Chris Papadopoulos)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   Lance chip questions


	I have some questions about the AMD Am7990 Ethernet controller
and the device driver on SunOS 4.0.3.

	In my throughput measurements, I get a maximum of 7.5 Mbps between
two Sparcstation 1 workstations. I suspect that the Lance chip is the reason
I cannot get more. The network driver code says that only one packet at a time
is transferred to the transmit descriptor ring, so back-to-back transmission
cannot happen. Can anyone enlighten me on this? What kind of throughput are
you getting/are possible with the chip? 

	One more thing: anyone knows what the memory bandwidth of a
Sparc 1 is?

	Thanks in advance.

Christos.

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Apr 92 21:32:00 GMT
From:      klassen@sol.UVic.CA (Melvin Klassen)
To:        comp.windows.x,comp.protocols.tcp-ip
Subject:   Re: How to get the Internet Address ?

In article <1992Apr21.125457.23150@ncsu.edu>
  jkshah@eos03a-16pa.eos.ncsu.edu (JYOTI KAMLESH SHAH) writes:
>
>I am trying to find the procedure and/or requirements to get the internet
>address for our org here.
 Perhaps, "Sam_Moore@NCSU.EDU" is the local guru!
>
A private E-mail response to Jyoti "bounced",
because the name-server (GYRO.CC.NCSU.EDU) has **no** A nor MX records
for the host 'eos03a-16pa.eos.ncsu.edu'.
Also, E-mail to 'jkshah@c00313-11pa.eos.ncsu.edu' bounces, i.e.,
______________________________________


From MAILER-DAEMON@eos03a.eos.ncsu.edu Tue Apr 21 14:11:17 1992
Return-Path: <MAILER-DAEMON@eos03a.eos.ncsu.edu>
Received: from eos03a.eos.ncsu.edu by sol.UVic.CA (4.1/SMI-4.0.3-UVic-2.24MX)
	id AA16450; Tue, 21 Apr 92 14:11:13 PDT
Received: by eos03a.eos.ncsu.edu (5.65b/SAM 07-20-90 10:07:54)
	id AA23765; Tue, 21 Apr 92 17:11:05 -0400
Date: Tue, 21 Apr 92 17:11:05 -0400
Subject: Returned mail: Service unavailable
From: MAILER-DAEMON@eos03a.eos.ncsu.edu (Mail Delivery Subsystem)
Posted-Date: Tue, 21 Apr 92 17:11:05 -0400
Message-Id: <9204212111.AA23765@eos03a.eos.ncsu.edu>
To: klassen@sol.UVic.CA
Status: R

   ----- Transcript of session follows -----
While talking to mailer.eos.ncsu.edu:
>>> HELO eos03a.eos.ncsu.edu
<<< 553 Local configuration error, hostname not recognized as local
554 <jkshah@c00313-11pa.eos.ncsu.edu>... Service unavailable

   ----- Unsent message (used to be after this -- KLASSEN) -----

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 92 22:50:26 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: SLIP Question.

alberti@mudhoney.micro.umn.edu (Albatross) writes:

>In <1992Apr20.202348.3972@amc.com> schansen@amc.com (Scott Hansen) writes:
 
>>remote printer support using 'lpd'.  I plan on using FTP's
>>PC/TCP+ on the PCs, but I'm undecided on how to handle the
>>4 or 5 incoming lines.  Is there such a thing as a 'SLIP
>>Server'?  Or do I have to hang the modems off a UNIX
>>machine which supports SLIP?
 
>It's a script-driven program for calling and connecting
>to SLIP servers in a relatively painless manner

Wrong end!

Yes, there are hardware slip servers available. Many boxes sold as
terminal multiplexors will do the job, and the Telebit Netblazer is just
going into use at our site (cam-du1.pipex.net) to support our dial-up
customers using PPP or slip.

You're probably better off doing this than using a Unix machine.

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.

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 92 23:07:54 GMT
From:      hari@maverick.uswest.com ( HariKumar Krishnan)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP stream Socket question...



Hi netfolks,

I am using BSD stream sockets to talk over two HP-UX machines.

1) Scenario/question:

I pull the plug on the second machine (Machine down).
I tried to establish connection (socket) to the second
machine from the first using the connect() call. Since
I had not set non-blocking on the socket, I get an ETIMEDOUT after
1 min and 20 sec (A long wait).

Question 1: Do I have control over this timer, like reduce it to
like 10 seconds.
Question 2: Whether the other machine is down or the Lan is down 
(pull the cable out), I get the same ETIMEDOUT error. Is there anyway
of finding out that the machine is down as opposed to the Lan??

2) Scenario:
I am connected to the other machine and have been passing data back
and forth. I now pull the plug on the second machine. I am still
able to send data till my local buffers fill up. I expected to
see an EPIPE, which did not occur. How can I receive an error
and if so can I make the same distinction mentioned above 
(Lan down or Machine down).


I would appreciate any knowledge on the above scenarios.
Thanks in advance.
Hari

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Apr 1992 00:56:19 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Lance chip questions

christos@dworkin.wustl.edu (Chris Papadopoulos) writes:
}	I have some questions about the AMD Am7990 Ethernet controller
}and the device driver on SunOS 4.0.3.
}	In my throughput measurements, I get a maximum of 7.5 Mbps between
}two Sparcstation 1 workstations. I suspect that the Lance chip is the reason
}I cannot get more. The network driver code says that only one packet at a time
}is transferred to the transmit descriptor ring, so back-to-back transmission
}cannot happen. Can anyone enlighten me on this? What kind of throughput are
}you getting/are possible with the chip? 

The transmit descriptor ring is merely a list of N structures (consisting
of flags, length, & address) which is accessed by the Lance circularly.
When a packet is read for transmission all that need be done is filling
in those fields -- the Lance then copies the packet from memory to the
ethernet.  If you have the packets ready, there should be plenty of time
to setup the next ring descriptor entry.  However, the major problem
with the Lance (in my estimation) is that it has a 600ns memory access
cycle (minimum).  At 1.25MB/s<1> (10Mb/s), you need to transmit a byte every
800ns, since the Lance fetches 2 bytes/access this means at full tilt the
Lance does a 600ns cycle every 1600ns which takes 37.5% of your bus
bandwidth.

Of course, SunOS may very well be copying the packet around between
buffers enough that it can't get the packets assembled in the 62.5%
(or less) that it has left.

------------------------
<1> Of course, with the interpacket gap, preamble, CRC, etc. you can't actually
    put 1.25MB of data on the ether, but you can do > 90% of that.

John

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Apr 1992 02:39:50 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Lance chip questions

In article <22255@olympus.wustl.edu>, christos@dworkin.wustl.edu (Chris Papadopoulos) writes:
> 
> 	I have some questions about the AMD Am7990 Ethernet controller
> and the device driver on SunOS 4.0.3.
> 
> 	In my throughput measurements, I get a maximum of 7.5 Mbps between
> two Sparcstation 1 workstations. I suspect that the Lance chip is the reason
> I cannot get more. The network driver code says that only one packet at a time
> is transferred to the transmit descriptor ring, so back-to-back transmission
> cannot happen. Can anyone enlighten me on this? What kind of throughput are
> you getting/are possible with the chip? 


AMD 7990 LANCE's have a not especially standard, call it "polite", response
to collisions.  Instead of starting 9.6 usec after the previous packet,
they often wait up to a couple dozen and then they use the "deferral" rules.

Consequently, we have found that systems Silicon Graphics Inc. makes using
7990's on modest ethernets (ie. diameters less than 20 usec) are faster
than systems SGI makes using other ethernet controllers, as measured
by ttcp.  Systems which only transmit on quiet ethernets are faster with
other ethernet chips.

I have no idea about other vendors performance.  7.5Mbit/sec TCP (you don't
say if raw or TCP) is close to the mystical, practically maximal value of
1MBytes/sec TCP/IP/ethernet.  If you want much more than 1MByte/sec, you're
going to have to use some other medium.


Vernon Schryver,  vjs@sgic.om


-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 02:47:48 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Lance chip questions

In article <1992Apr22.005619.23318@news.iastate.edu>, john@iastate.edu (John Hascall) writes:
> ...
>                                      ...  However, the major problem
> with the Lance (in my estimation) is that it has a 600ns memory access
> cycle (minimum).  At 1.25MB/s<1> (10Mb/s), you need to transmit a byte every
> 800ns, since the Lance fetches 2 bytes/access this means at full tilt the
> Lance does a 600ns cycle every 1600ns which takes 37.5% of your bus
> bandwidth.
> 
> Of course, SunOS may very well be copying the packet around between
> buffers enough that it can't get the packets assembled in the 62.5%
> (or less) that it has left.


No fast system that uses LANCE's lets the LANCE lock up a major, shared bus
for as long as the LANCE would like.  You build whatever silicon is
necessary to fool the poor, slow thing into thinking it has the bus all to
itself for as long as it thinks it needs it.

I'm told by hardware experts (I'm not) that all (most?) other ethernet
controllers are just as slow.  (It should be noted that the current
generation of hardware experts I consult have difficulty counting
nanoseconds except on their fingers.)


Vernon Schryver,  vjs@sgi.com

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Apr 1992 03:03:59 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip
Subject:   Re: pd ftp without telnet

In article <19APR199220393926@reg.triumf.ca> larry@reg.triumf.ca (Lawrence Clarke) writes:
>
>Where can I get more info on B&W's tcp/ip programs?
>
>
Beame & Whiteside Software Ltd. is available at:
(416) 765-0822
or 1-800 INFO NFS


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Apr 1992 03:05:57 GMT
From:      johnson@tigger.jvnc.net (Steven L. Johnson)
To:        comp.protocols.tcp-ip
Subject:   Two IP subnets connected via a different network

Could someone point me to a concise (or not so concise)
description of the routing issues involved when trying
to connected two or more subnets of a given IP network
via a different IP network or multiple IP networks.

Any pointers are appreciated.

-Steve

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 16:04:22 -0700
From:      ewilts@galaxy.gov.bc.ca (Ed Wilts)
To:        bc.general,comp.protocols.tcp-ip
Subject:   TCP/IP & Internet training

We're currently looking for a firm that is willing (for a fee of course) to
teach some end-user TCP/IP courses.  Not the techie stuff that most TCP/IP
courses offer but real novice topics:  NFS, Telnet, FTP, Archie, Usenet News,
etc.  We've got the techies trained - now it's the end users turn.

Any info greatly appreciated.
-- 

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

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 08:06:07 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets and broken TCP connections

In article <57732@cup.portal.com> MAC@cup.portal.com (Michael Alan Casteel) writes:
>1. HP-UX docs say that SO_KEEPALIVE is needed to detect broken 
>   connections, enabling 'end of file' for receivers and SIGPIPE
>   for senders. Is this usual, not just HP-UX?

This is normal.  The TCP protocol doesn't provide a way to detect that the
other end has died (as opposed to closing cleanly) unless this end tries to
send data on the connection.  If the other end has rebooted this will cause
it to send a reset response; if the other end is still down the sender will
time out waiting for an acknowledgement (this latter use of keepalives is
controversial, since temporary network failures may appear like the other
end has crashed, so you'll lose your connection when you shouldn't).

>2. Does KEEPALIVE impose an unpleasant network overhead?

No.  For each connection with SO_KEEPALIVE set, there will be two packets
every N seconds while the connection is idle.  I think N is something like
30.

>3. Since my current program (apparently) does not set SO_KEEPALIVE,
>   there are TWO processes extant right now, both showing that they
>   are connected on the SAME local port # (the first one, six days
>   old, predated a crash on the remote computer). This doesn't seem
>   right; surely only the current connection is really receiving on
>   that port #? (The remote port #s are different).

It's right.  Connections are identified by the tuple <local address, local
port, remote address, remote port>.  There's no problem with two process
sharing the same local port with different remote ports.  In fact, it's
quite common; inetd normally forks a separate process for each connection
to a service, and each server for a given service will have the same local
port (e.g. all telnetd processes will have connections using local port
23).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 14:43:55 EST
From:      "william mercer" <william.mercer@canrem.com>
To:        comp.protocols.tcp-ip
Subject:   beame & whiteside tcp

Earlier Lawrence Clarke (larry@reg.triumf.ca) wanted to know how to
contact Beame & Whiteside regarding their TCP/IP suite.  I thought it
would be preferrable to post it here:

        Beame & Whiteside
        PO Box 8130
        Dundas, Ontario
        Canada
        L9H 5E7

My contact there is Graham Wright.  For the next couple weeks he can be
reached at: wright@blackadder.cis.mcmaster.ca

After May 7 or 8, he can be reached at wright@bws.com

Having just finished speaking with Graham on the phone, he corrected me
by saying that Beame & Whiteside (Carl Beame) didn't have any say in the
design of the Clarkson packet drivers, but they had found some bugs and
provided some fixed code.  In other words, these folks appear to be
intimately acquainted with the Clarkson packet drivers.

Hope this is of value to someone out there.

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

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 11:28:32 GMT
From:      sater@cs.vu.nl (Hans van Staveren)
To:        nlnet.misc,comp.org.sug,comp.sys.sun.misc,comp.unix.admin,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   CALL for PAPERS SUG-NL Technical Meeting 1992


		SUG-NL Technical Meeting 1992

		  September 23rd, Rotterdam



		     CALL for PAPERS


The Dutch Sun User Group will organize its yearly Technical
Meeting on 23rd of September in Rotterdam.  At the same time and
location a big exhibition organised by Sun Nederland will be
held.  This means that Technical Meeting participants will also
be able to visit the exhibition and have a look at the broad
range of SPARC/Solaris based products available there.

The Technical Meeting will run with two tracks in parallel. One
concentrating on all aspects of system maintenance and
networking; the other on new and promising technologies in
hardware and software. Sun/SPARC users and manufacturers of
SPARC based products are encouraged to participate in the
conference with technically oriented presentations.

The Technical Meeting gives you the opportunity to share your
experience and views with a broad technically competent
audience. Also, if you know somebody who might contribute to the
program, let the Program Committee know. The Program Committee
can be reached by telephone +31 33 501234 (ask for: Marja Arons),
by email (tm92pc@sun.nl) or surface mail (see later).

Submissions should be in the form of extended abstracts (400 to
800 words) and be sufficiently complete to allow the Program
Committee to understand and evaluate the submission.  Abstracts
should include:

  1. Name and address
  2. Title of the paper
  3. Time needed for presentation
  4. Audio visual requirements

Abstracts should be submitted by electronic mail to

	tm92pc@sun.nl

or surface mail to

	TM'92 Programmacommissie
	SUG-NL secretariaat
	Postbus 1270
	3800 BG  Amersfoort


Deadlines:

   Abstracts Due:		June 1, 1992

   Notification to Authors:	June 30, 1992

   Final Papers Due:		August 15, 1992



Program Committee:


Jim van Keulen		Vrije Universiteit, Amsterdam
Gerard van Ruiten	Sun Microsystems Nederland b.v.
Francois Staes		Universitair Instituut Antwerpen
Hans van Staveren	Vrije Universiteit, Amsterdam
Maarten Westenberg	Sun Microsystems Nederland b.v.

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 12:16:09 GMT
From:      hoeh@nrm6.UUCP (THOMAS HOEH)
To:        comp.protocols.tcp-ip
Subject:   socket test suite

Hello,

is there a test suite avaliable to test the correct
socket implementation on a specific system ?

Best regards

   Thomas Hoeh  (hoeh@nrm6.uucp)

-- 
Thomas Hoeh                       UUCP:  hoeh@nrm6.uucp
SIEMENS Corp,. Munich, Germany           (...uunet!mcsun!unido!nrm6!hoeh)
Systems Engineering               voice: +89 4144 5727, fax: +89 4144 5962

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 12:56:00 GMT
From:      dwatts@ki.com (Dan Watts)
To:        comp.protocols.tcp-ip
Subject:   Re: need DEC LAT code

In article <1992Apr21.164040.24001@novell.com> cranch@novell.com (Christopher Ranch) writes:
>In article <1992Apr16.230909.1273@cton.uucp> nicholas@cton.cton.com (Nick Hennenfent) writes:
>>I need the names/addresses of companies that sell licensed DEC LAT.
>>
>>I will post a listing of what I receive. Thanks.
>
>You email bounced.

Same thing happened to me.

> The only place you can license LAT is from DEC.

True.  But you can license LAT binaries from third parties, some of whom
have gotten a license for the LAT spec.

We're one of them:

  ki Research, Inc
  6760 Alexander Bell Dr.
  Columbia, MD 21046
  800-945-4454
  410-290-0355
  410-290-0397 FAX
  support@ki.com

Contact us for a free evaluation copy.

We supply LAT/DECnet/MOP for Mips, SGI, IBM AIX, IBM OS/2, Sequent, Sun,
DEC Ultrix, DG Aviion, DG AOS/VS, Alliant, Ardent, Modcomp, SCO, Harris,
Interactive Systems, Unisys, Encore, ICL, Stellar/Ardent/Stardent,
Tektronix XD88 and some others.

Our DECnet if full function [endnode/level 1 routing/level 2 routing]
and supports both Ethernet and DDCMP connections.  We fully support
NICE [in and out], event log sinking, and UNIX<->DEC mail gateway.

Our LAT supports incoming/outgoing lat connections, incoming/outgoing
printer connections, seperate groups for incoming and outgoing,
user defined services such as our LATtoTelnet gateway, and LAT
tunneling across a WAN via DECnet.

Our MOP product supports downloading MOP devices, manual loop,
automatic loop, assisted loop, and remote console.

The user and program library interface are identical on all platforms.
Each protocol has it's own application interface allowing customers to
write their own applications.  There are also APIs to NICE and Netwatch.

The product set also comes with a network scope [NetWatch] and analasys
tool [DEPICT]; a VT340 emulator; sethost script language; DECnet/ULTRIX
programming library among other things.

Dan
-- 
##################### Naturism, Grin and Bare It ######################
# CompuServe: >INTERNET:uunet.UU.NET!ki.com!dwatts  Dan Watts         #
# UUCP      : ...!uunet!ki.com!dwatts               ki Research, Inc. #
#######################################################################


-- 
##################### Naturism, Grin and Bare It ######################
# CompuServe: >INTERNET:uunet.UU.NET!ki.com!dwatts  Dan Watts         #
# UUCP      : ...!uunet!ki.com!dwatts               ki Research, Inc. #
#######################################################################

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1992 01:24:50 -0700
From:      tli@skat.usc.edu (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP subnets connected via a different network

In article <1992Apr23.070135.20394@cs.columbia.edu> ji@cs.columbia.edu
(John Ioannidis) writes: 

    The Internet at large can only route packets to one location (well,
    you can have more than one routers connecting you to your regional or
    whatever, but they are still essentially one location).  Remember, IP
    routing is still done based on the network part of the IP address.
    Until core and regional routers start using netmasks with routes
    (hopefully as part of the Great Plan Of Internet Restructuring :-) )
    
I would hope that this does NOT happen.  I can see it now: thousands
of network administrators inject all of their subnets into the
Internet backbone....  and the subsequent explosion of the routing
tables shuts the entire network down.

I wonder if it would ever restart?

-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Apr 1992 14:02:45 GMT
From:      george@mitchell.cit.cornell.edu (George Boyce)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP and Slip ?

ehanson@batman.acslab.umbc.edu (Mr. Erik Hanson; ARTS-SCI (UGRAD)) writes:
   >Mike.Alexander@umich.edu (Mike Alexander) writes:
   >It's a new LAP layer for MacTCP.  This lets you use everything that
   >supports MacTCP, at least in principle.  Because a SLIP line is so much

   Um... I'm sure this has been asked, but I must have missed it. Do
   you have to buy VersaTerm to get the SLIP tool? If so, how much is
   VersaTerm? If not, how much is the SLIP tool?

I called Synergy Software and got the following information. Version
4.6.2 of versaterm (3.6.2 of pro) will have mactcp slip. You can
upgrade for $20 and it is due out in 2 weeks (they are waiting for the
documentation to be printed). [Obviously Mike is beta testing it.]

They plan to have a seperate product called versatilities (?) which is
mactcp slip and other stuff packaged seperately from versaterm. Expect
to see it in about 2 months with "special" packaging/pricing for
universities. No other details available right now.

George


-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Apr 92 14:47:25 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: SLIP Question.

In article <1992Apr21.225026.483@unipalm.co.uk>, ian@unipalm.co.uk (Ian Phillipps) writes:
|> alberti@mudhoney.micro.umn.edu (Albatross) writes:
|> 
|> >In <1992Apr20.202348.3972@amc.com> schansen@amc.com (Scott Hansen) writes:
 
|> >>remote printer support using 'lpd'.  I plan on using FTP's
|> >>PC/TCP+ on the PCs, but I'm undecided on how to handle the
|> >>4 or 5 incoming lines.  Is there such a thing as a 'SLIP
|> >>Server'?  Or do I have to hang the modems off a UNIX
|> >>machine which supports SLIP?
 
|> >It's a script-driven program for calling and connecting
|> >to SLIP servers in a relatively painless manner
|> 
|> Wrong end!
|> 
|> Yes, there are hardware slip servers available. Many boxes sold as
|> terminal multiplexors will do the job, and the Telebit Netblazer is just
|> going into use at our site (cam-du1.pipex.net) to support our dial-up
|> customers using PPP or slip.
|> 
|> You're probably better off doing this than using a Unix machine.
|> 
|> 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.

We have a Telebit Netblazer at our site.  We also have a number of Unix machines
running SLIP.  Without exception (at least I haven't heard one) the Unix machines
are better SLIP servers than the Netblazer. Not surprising since the Netblazer is
based on a 80386 and our Unix box is a dual processor 88100 with a boat load
of memory.  The revision of the Netblazer software we have does not support VJ
compression very well (it becomes confused easily) though Telebit is working
on the problem (has it fixed?). If you already have a UNIX machine that can
support SLIP you're probably better off using it.  If you have to buy a server,
one of the available terminal multiplexors may be more cost effective if that's
your only use for the machine.

-- 
+------------------------------------------------------------------+
| John A. Scott                       | Phone: +1 919 248 5995     |
| Data General                        | Email: scott@dg-rtp.dg.com |
| 62 TW Alexander Drive               |                            |
| Research Triangle Park, NC 27709    |                            |
+------------------------------------------------------------------+
                                                       


-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 16:28:51 GMT
From:      ken@racerx.uucp (Ken Hardy)
To:        comp.protocols.tcp-ip
Subject:   RPC Sun<-->Vax (Apollo)

We are investigating the use of RPC between Sun Sparcs and DEC Vaxen
(VMS), which apparently have a derivative of Apollo's RPC
implementation.  Are there any problems with this?  The documentation
is a bit unclear in explaining the use of and need for the Vax's
Location Broker vs. the Sun's port mapper.  Will these two systems be
able to talk to each other's RPC, or are these two incompatible
implementations?

I'm told that Vax's NFS will work with Suns, but it is possible that
the NFS product has Sun's RPC coded right into it, not using the
general Vax RPC.  Just conjecturing, obviously, while awaiting
elucidation.

Ken Hardy
ken@bridge.com  (racerx!ken)

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 16:50:03 GMT
From:      ching@brahms.amd.com (Mike Ching)
To:        comp.protocols.tcp-ip
Subject:   Re: Lance chip questions

In article <jrj9ask@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Apr22.005619.23318@news.iastate.edu>, john@iastate.edu (John Hascall) writes:
>> ...
>>                                      ...  However, the major problem
>> with the Lance (in my estimation) is that it has a 600ns memory access
>> cycle (minimum).  At 1.25MB/s<1> (10Mb/s), you need to transmit a byte every
>> 800ns, since the Lance fetches 2 bytes/access this means at full tilt the
>> Lance does a 600ns cycle every 1600ns which takes 37.5% of your bus
>> bandwidth.
>> 
>> Of course, SunOS may very well be copying the packet around between
>> buffers enough that it can't get the packets assembled in the 62.5%
>> (or less) that it has left.
>
>
>No fast system that uses LANCE's lets the LANCE lock up a major, shared bus
>for as long as the LANCE would like.  You build whatever silicon is
>necessary to fool the poor, slow thing into thinking it has the bus all to
>itself for as long as it thinks it needs it.
>
>I'm told by hardware experts (I'm not) that all (most?) other ethernet
>controllers are just as slow.  (It should be noted that the current
>generation of hardware experts I consult have difficulty counting
>nanoseconds except on their fingers.)
>
>
>Vernon Schryver,  vjs@sgi.com


The 1992 version of our Ethernet product data book has advanced
information for a controller which transfers data in 80ns. More
fingers than the average hardware engineer but a step in the
right direction.

Mike Ching

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Apr 1992 17:47:30 GMT
From:      tracys@hpindda.cup.hp.com (Tracy Steelhammer)
To:        comp.protocols.tcp-ip
Subject:   Re: Info about ``Is Layering Harmful'' article...

the figures made it in the March issue (vol 6, no. 2, Mar 92, p 8).

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 17:49:41 GMT
From:      jjason@inetnode.austin.ibm.com (Jason Hernandez /2113674)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: SLIP Question.

I was on a team that recently finished doing a 16 line Home Terminal
program that had need for SLIP. After looking at devices like the
Telebit Netblazer, hanging modems off a UNIX box, etc. A Xyplex 1600
terminal server (!!!!) did the job. Not only did it do the normal
terminal service, but it has a really slick SLIP implementation.

The terminal server acts as a SLIP gateway, and the end effect is that
your machine at home becomes "just another node" on the network - same
addressing, same subnet mask, same nameserver, etc. It looks at the
source address in the first packet your machine at home sends, and from
then till when you hang up, it does routing for you.

Why is this GREAT? It allows the user to come in any port and not have
to even think about their name or address. It doesn't change. The
terminal server does the work. We set up 16 phone lines in a rotary to
a bank of Why is this GREAT? You can very easily make a 16 phone line
rotary since the specific input port is not a concern.

If you're worried about security, check out the ACM-1600 from Security
Dynamics. It's simple and effective. (And Expensive...) The Xyplex 1600
is a little more expensive than the competition, but their service has
been PHENOMINAL! Recommended.

I need to point out that I am not affiliated with the companies mentioned.
Their gear did the job, which is why I typed all this.

Yours,
(^.^) Jason

///////////////////////// Jason Hernandez \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\Network Engineer and Practicioner of Arcane Magic////////////
IBM AWD, Austin Texas. jjason@inetnode.austin.ibm.com   AUSVM6(JJASON) 
The above statements are fictional and do not represent any living
entity, or for that matter, my employer. Of course, I happen to be a
figment of your overactive imagination...
-- 
///////////////////////// Jason Hernandez \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\Network Engineer and Practicioner of Arcane Magic////////////
IBM AWD, Austin Texas. jjason@inetnode.austin.ibm.com   AUSVM6(JJASON) 
The above statements are fictional and do not represent any living

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 17:59:15 GMT
From:      thsssxs@iitmax.iit.edu (Semir Sirazi)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   MIT & CMU TCP/IP stacks



	I am currently evaluating TCP/IP stacks from various vendors and 
	am wondering what kind of experiences anyone has had with either
	CMU's or MIT's TCP/IP.

	To give a little background, I am looking to get my hands on a 
	protocol stack that will provide the "easiest" integration into
	an embedded system. This embedded system will be utilizing an Intel
	386DX processor in protected mode running the Vtrx 32 Operating System,
	talking to a TokenRing Network.  So obviously any OS and Ethernet 
	dependencies will cause a lot of heartache. Eventually SNMP will
	also come into the picture.

	If you have any positive or negative experiences that may shed some
	light on this subject, I would appreciate hearing from you.

			Thank you very much,

						Keith Zimmerman

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 18:23:20 GMT
From:      tkochie@tkochie.austin.ibm.com
To:        comp.protocols.tcp-ip
Subject:   SUN network kernel timing measurements

I am interested in any kernel timing (path length in microseconds) measurements
that may have been done on a sparcstation2 running any flavor of SunOs. 
The methods used to obtain the numbers would also be needed. At a minimum
I need the time from when the ethernet driver receives a receive interrupt
to when the packet is queued to the ipintrq queue. 

---
Tom Kochie                        awdnet:   tkochie@tkochie.austin.ibm.com 
IBM PSPA AIX System Performance   Internet: tkochie@wizards.austin.ibm.com
11400 Burnet Road, 9003/9632      vnet:     TKOCHIE at AUSTIN
Austin, TX  78758-3493            phone:    (512) 838-2685, tie 678, fax 8-8344
-- 

Tom Kochie                        awdnet:   tkochie@tkochie.austin.ibm.com 
IBM PSPA AIX System Performance   Internet: tkochie@wizards.austin.ibm.com
11400 Burnet Road, 9003/9632      vnet:     TKOCHIE at AUSTIN

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Apr 1992 19:35:33 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Standalone front-ends for SMTP, LPD, etc...

In article <1992Apr21.133108.22462@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:
> Have you considered uucp over TCP/IP? Or is is possible with your systems?

We are currently using it, and getting pretty good transfer rates. It just
doesn't have enough end-to-end feedback, and in addition is causing
reliability problems (read: crashes) on one of our systems.

> Smail3 might help, or at least provide hackable source.

I've already picked up enough "hackable" source from the net for this
system (which interfaces with a very nice OSI based network) that I'm
pretty reluctant to dive into yet another all-in-one program. They are
very rarely built out of the sorts of components that would make the
effort pay off.
-- 
Peter da Silva                                                      `-_-'
Programmer, network firefighter, thrillseeker                        'U` 
Ferranti International Controls Corporation                    Have you hugged
Sugar Land, TX  77487-5012    +1 713 274 5180                  your wolf today?

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Apr 1992 19:53:03 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp printer servers

In comp.protocols.tcp-ip, bill@banana.fedex.com (bill daniels) writes:

> k@hprnd.rose.hp.com (Steve Kao) writes:
 
>> Why not get an HP LaserJet with the appropriate TCP/IP card?  You can
>> then plug the printer directly onto the TCP/IP network.
 
>> - Steve Kao
 
> Does such an item exist?  I am aware only of the ethernet interface card
> that supports only netware.
 
> bill

I have a new basenote in comp.periphs.printers that explains how to
order the TCP/IP card for the II, IID, III, IIID, or IIISi.  It lists
all the part numbers and options you need.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 92 22:44:30 GMT
From:      venkat@metrix.UUCP (D Venkatrangan)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: Real time traffice generator

In article <4dsOzMW00WB58xOJ1X@andrew.cmu.edu> sb7c+@andrew.cmu.edu (Shikhar Bajaj) writes:
>Does anyone know of a traffic generator (for Sun OS preferably) which will
>generate "real time traffic."  In other words, if I specify that I want a
>Poisson process with an average arrival rate of 1 msec, the process will
>generate traffic adhereing to the 1 msec parameter (plus or minus some
>small epsilon).  I know that such stringent time constraints may require
>a real-time OS or simply a hardware solution, but I hope that something
>already exists out there.  Thanks for any help.
>
>
>Shikhar

We have developed a full-featured software-only traffic generator for SunOS
4.0.3 and up.  It has a number of features including a msec delay spec.
It allows you to define up to 100 packets with different delays between
each packet.  Each packet can be hand-crafted or "imported" from existing
packet traces.  You can also send entire packet traces, (captured through a
companion protocol analyzer product).  You can also use its programming
features to wait for a certain packet to arrive before sending a response.

If interested, you may call Metrix Network Systems Inc., at (603) 888-7000
for an evaluation copy.

---------------------------------------------------------------------------
D. Venkatrangan
Metrix Inc.			One Tara Blvd, Nashua, NH 03062
venkat@metrix.com		VOICE: (603) 888-7000 FAX: (603) 891-2796
---------------------------------------------------------------------------


-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 92 11:03:50
From:      chip@cs.widener.edu (Chip Page)
To:        comp.protocols.tcp-ip
Subject:   TCP terminal server port name.


Hello,

	I have a terminal server question.  We have Emulex Performance
4000 terminal servers that support both LAT and TCP/IP connections.
We have used these servers to connect to VAXes, but are now starting
to get into Unix machines.  The first machine will be a Motorola (Sys
V based).  
	With a LAT connection to VMS, I can use the $getdvi(tt,
tt_accpornam) system service to get the terminal server name and
physical port name, of the tt terminal.  We use this to set up certain
chars to each particular terminal, as well as other administrative tasks.

	With TCP/IP, I have not found a way to do this.  This is what I 
gather is happening.  The physical port gets mapped to a noreserved (high)
tcp server port.  It then goes out on the net to connect to the
destination node, tcp port 23.  What I need to do, is be able to find
(for my terminal) the tcp service port on the terminal server, and then
find the physical port it is mapped to.  
	I see the remote port on the netstat display, so I think it is
available.  Once I figure out how to get this number, I need to get the
mapping info from the terminal server.  I heard that SNMP may be used
to do this, and I'll look into that next (I never used it before).  

	Any info would be greatly appreciated.  Thank you.
--
| Chip Page   --   chip@cs.widener.edu   +------------------------------------|
|----------------------------------------+  Backwards words, say to used I.   |
| Widener University | Users Inc.        | Again go I there.  Shit - oh !     |
| Chester, Pa.       | Valley Forge, Pa. +___________________ - George Carlin |
 

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Apr 1992 07:01:35 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP subnets connected via a different network

In article <1992Apr22.030557.20446@tigger.jvnc.net> johnson@tigger.jvnc.net (Steven L. Johnson) writes:
>Could someone point me to a concise (or not so concise)
>description of the routing issues involved when trying
>to connected two or more subnets of a given IP network
>via a different IP network or multiple IP networks.
>
>Any pointers are appreciated.
>
>-Steve

The Internet at large can only route packets to one location (well,
you can have more than one routers connecting you to your regional or
whatever, but they are still essentially one location).  Remember, IP
routing is still done based on the network part of the IP address.
Until core and regional routers start using netmasks with routes
(hopefully as part of the Great Plan Of Internet Restructuring :-) )

Given what's available now, here are some solutions:

1. Get a bunch of Class C addresses for your satellite sites, and let
the Internet do the routing. Of course, "if everybody did that what
would happen to the routing tables?" (hint: it's already happening).

2. Have all packets from the outside world routed to one of your
sites, then *tunnel* packets to the other site(s):

I can best explain this with an example. Let's say you have two
satellite sites and one main site:


       . . . . . . . . Main Site  . . . . . . . . . . . . .
       . 						  .
       . 						  .
       .                         .------------.	       	  .
       . 			 | "tunneler" |           .
       . 			 `-----+------' 	  .
       . 		               |                  .
       .    ---------------+-----------+-----   	  .
       .       ethernet    |    			  .
       . 		   |                              .
       .              .----+-----.      		  .
       .              | router-M |      		  .
       .              `----||----'      		  .
       . . . . . . . . . . || . . . . . . . . . . . . . . .
	        	   ||
                     To/From Regional
	        	   ||

                       ...Rest of Internet...

       	       	 ||                             ||
           To/From Regional               To/From Regional
       	       	 ||                             ||
       . Site A .||. . . . .          . Site B .||. . . . .
       .         ||        .	      .         ||        .
       .     .---||---.    .	      .     .---||---.    .
       .     |router-a|    .	      .     |router-b|    .
       .     `---+----'    .	      .     `---+----'    .
       .         |         .	      .         |         .
       .  -------+-------  .	      .  -------+-------  .
       .   ethernet,       .	      .   ethernet,       .
       . subnets A1, A2... .	      . subnets B1, B2... .
       .                   .	      .                   .
       . . . . . . . . . . .	      . . . . . . . . . . .


Needless to say, all three sites have the same network number
(otherwise this wouldn't be a problem!). Also needless to say, the
routers shown have addresses on your network and on whatever regional
they happen to be on. Subnets A1, A2, etc. are at Site A, and subnets
B1, B2, etc. are at Site B.

Now, the routes are set up in such a way that:

(a) Any packets in any site that are destined for other hosts at the
same site naturally stay at that site (obviously!).

(b) Packets to the outside world are routed through the site router(s)
(again, obviously!).

(c) Packets at Sites A or B that are destined for the Main Site are
picked up by router-a or router-b, respectively, and put on the
corresponding site's regional. Now, the Internet sees packets destined for
your network, and routes them accordingly to your Main Site.

(d) The tricky part is what happens to an IP packet originating at the
Main Site (or a packet from the outside world that is first routed to
the Main Site) that is destined to, say, Site B. Well, the machine
labeled "tuneller" picks it up (i.e., internal routes are set up to
route packets for subnets A1, A2, B1, B2, etc, to "tuneller").
"Tunneler" then encapsulates the packet inside another IP packet and
sends it to router-a, using, of course, router-a's address on the
regional. Router-a now gets the encapsulated packet, strips the
encapsulation header, and dumps the resulting IP packet onto its local
ethernet. Now, since this was a packet that *was* destined for this
part of the network, it just stays there and finds its destination.

The encapsulation is done using, for example, the IPIP
("IP-within-IP") protocol, IP protocol number 94. The only
implementations of IPIP I know of are, of course, my implemention done
on Mach 2.5 (but readily compilable into any BSD-derived unix), and
Phil Karn's implementation in his KA9Q package.

The semantics of the encapsulation are simple:

To send out an encapsulated packet, you just tack on another 20-octet
IP header. (OK, Phil, you won, happy now? :-) ) The protocol type is
94, the source address is the tuneller's IP address, the destination
address is the other endpoint's IP address, and the TTL field is
MAXTTL. Actually, before tacking on the header, check the ttl field,
and if it's zero, drop the packet and send an ICMP Time Exceeded. This
can only happen when there is a tunelling loop, so it may also be a
good idea to log the fact that it happened. Now, when you receive an
IPIP packet, you just strip the header and feed the packet back in the
IP output queue.

Back to routing. There is no need for router-a or router-b to
encapsulate packets destined for the main site. If either of them gets
an IP packet destined for the other router, it encapsulates it using
the other router's "regional" address (it's kinda stupid to have to go
through the main site if all you want to do is just send packets from
one satellite site to another). Also, ideally, you want the tuneller's
functionality to exist in router-M, but since router-M is probably a
Cisco box (or whatever), chances are that it won't exist for a while.
(Cisco, are you listening?) If your satellite sites are smaller than
the main site, chances are that you can get away with using a Unix box
for routers a and b. You really want the decapsulation done on
router-[ab], otherwise (i.e., if the situation is the the same as in
the main site), you'll need a couple of extra IP addresses, one for
the "inner" side of the router, and one for the tunneler/untuneller,
neither of which can be from your network number; they have to be the
regional's, or a separate class C network, which brings us back to
point (1.) above. Of course, if your unix box does not have the right
kind of interface to talk to whatever wire the regionals will be
giving you at the satellite sites, you may not have a choice.
Remember, the tuneller back at the Main Site sends the encapsulated
packets to some other address on the internet which is not from its
own network. Now, the regional may be able to give you three
(sequential) addresses for your "router-x" (now an cheap cisco and a
unix box, really). The whole thing would look like this:



       	       	 ||
       . Site A .||. . . . . . . . . . . . . . . . . .
       .         ||address on regional               .
       .     .---||---.     			     .
       .     |router-a|     			     .
       .     `---+----'     			     .
       .         |address(es) on local subnet(s)     .
       .         |				     .
       .         |   .------------.	       	     .
       .         |   | tunneler-a |                  .
       .         |   `-----+------' 	             .
       .         |         |address on regional	     .
       .         |         |			     .
       .         |         |			     .
       .         |         |			     .
       .         |         |			     .
       .         |         |			     .
       .  -------+---------+--------------	     .
       .   ethernet,        			     .
       . subnets A1, A2...  			     .
       .                    			     .
       . . . . . . . . . . . . . . . . . . . . . . . .


Of course, there must be a host route on router-a for tunneler's
address through the LAN interface, but that's not hard to do! Note how
traffic would flow in this case: router-a would still be the default
router to the world, so traffic from any host at Site A to any outside
host (either at the Main site, or somewhere else on the network) goes
through router-a. Traffic from the outside world to Site A would only
be tunneled traffic to tunneler-a, which would pick it up, decapsulate
it, and deliver it locally. Now, to tunnel to Site B, simply set
routes to those subnets to be tunneler-a, which will happily
encapsulate and tunnel to Site B.

-----------

Now, where does one get the code for all that. Well, I could send out
the code for my Mobile-IP stuff, parts of which can be used to do the
tunelling, but we changed some of the packet formats at the San Diego
IETF, and I haven't had a chance to incorporate the changes in the
code, test a new release, and make it available (and chances are that
I won't for another couple of months, as I'm writing my dissertation).

This turned out to be longer than I had expected -- I hope people find
it useful. 

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027







-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 92 08:37:48 GMT
From:      frisbie@flying-disk.com (Alan Frisbie)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: need DEC LAT code

In article <1992Apr21.164040.24001@novell.com>, 
cranch@novell.com (Christopher Ranch) writes:
> In article <1992Apr16.230909.1273@cton.uucp> 
> nicholas@cton.cton.com (Nick Hennenfent) writes:
>>
>>I need the names/addresses of companies that sell licensed DEC LAT.
>>
>>I will post a listing of what I receive. Thanks.
>>
> 
> You email bounced.  The only place you can license LAT is from DEC.
> 

This is what you would expect, but it is wrong.   Under what I
believe is a unique arrangement with DEC, you can obtain a LAT
license (and, I believe, code), from:

      Meridian Technology Corporation
      11 McBride Corporate Center Drive, Suite 250
      Chesterfield, Missouri 63005-1406

      (314) 532-7708 (Voice)
      (314) 532-3242 (FAX)

--  Alan E. Frisbie               Frisbie@Flying-Disk.Com
--  Flying Disk Systems, Inc.
--  4759 Round Top Drive          (213) 256-2575 (voice)
--  Los Angeles, CA 90065         (213) 258-3585 (FAX)

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 92 12:31:13 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   4.3BSD Reno socket changes

4.3BSD Reno changed the socket address structures by changing the
short integer family into a 1-byte family and a 1-byte length.
The msghdr structure for sendmsg()/recvmsg() also changed: the
old access rights became control information, and a flag variable
was added to the end of the structure.

What I was wondering is now that the Reno changes have been out for
almost 2 years, and with increased interest in the 386 versions of
BSD (which have these Reno changes), and since the POSIX 1003.12
group seems to be starting with the Reno changes also,

   - have any other systems incorporated these changes?

I know SunOS 4.* has not, and SVR4 has not.  What about SunOS 5.*,
Ultrix, HP/UX, OSF/1, etc.?  Any information appreciated.

	Rich Stevens  (rstevens@noao.edu)

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 92 14:26:28 GMT
From:      xavier@srt-poste.fr (Xavier Saliou)
To:        comp.protocols.tcp-ip
Subject:   Informations on RFC1001 & 1002

Keywords: TCP/IP Netbios



I would like to know how I can get the RFC 1001 & 1002 taht describe the implemetation of Netbios over TCP/IP Thanks

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Apr 1992 14:47:48 GMT
From:      doug@cc.ysu.edu
To:        comp.protocols.tcp-ip
Subject:   SysV lp-> bsd lpr TCP interface ?

Has anyone written an interface module to connect System V lp to
a BSD lpd on a remote system ?

I didn't see anything in the comp.sources.* indexes.

I also know about an lpr-like  command that connects directly to a
remote remote lpd (Rich Stevens Unix Network Programming book has
code for this).

But has anyone done it "right" ?  I have a NCR Tower with WIN-TCP,
and there's libraries for both TLI and sockets.

Thanks in advance, Doug.
-- 
Doug Sewell, Tech Support, Computer Center, Youngstown State University
doug@cc.ysu.edu	   doug@ysub.bitnet	<internet>!cc.ysu.edu!doug
We've had 4 years of domestic policy failure.  Fire Bush this November.

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 92 15:34:32 GMT
From:      meb@BEAU.ATLANTA.DG.COM (Michael Brown)
To:        comp.protocols.tcp-ip
Subject:   TCAP protocol

I'm looking for information on the protocol, TCAP.  TCAP stands for 
Transaction Capabilities Protocol, and is used primarily in telephony.
Any pointers to documents, code (if available) would be appreciated.
-----------------
Michael E. Brown
meb@atlanta.dg.com

switch( opinion ){
case MINE:
	printf( "YES\n" );
	break;
case OTHERS:
	printf( "NO\n" );
	break;
}

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Apr 1992 16:31:00 GMT
From:      brown@chinchilla.cc.ucf.edu (Bill Laughner-Brown)
To:        comp.protocols.tcp-ip
Subject:   Why should my company get Internet access?

I'm not certain that this is the group that this post belongs, but here 
goes...  I'm planning on proposing Internet access for my company.  What I 
need is some specific reasons why a company would benefit by Internet 
access.  I know the reasons why I use the Internet (News, Info, file 
transfer, e-mail communication between my peers), but how do I put that in a 
form palatable to the corporate big-wigs?  Also I would like some 
information about specific Internet access providers (like PSINet, etc...).  
What's involved (logistically and pricewise) with obtaining access?  Our 
company is currently setting up TCP/IP on our Netware Internetwork so that 
we can telnet to our big machines.  It would be nice if along with that 
effort, outside connectivity could be effected as well.

Thanks in advance,

Bill Brown                           Maynard(R) - An Archive Company
Internet: brown@chinchilla.cc.ucf.edu
MCIMail via Internet: Bill_Brown%Maynard_Electronics_Inc@mcimail.com
no speakada Maynard.  jes' me.

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 1992 16:40:31 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: rfc854

In article <RG.92Apr23113559@nymph.msel.unh.edu> rg@msel.unh.edu (Roger Gonzalez) writes:
>Note: I don't consider this a wizardly question, but since nobody answered it
>on c.u.q, here I am!

It's also not a Unix question.  Since it's a TCP/IP question,
comp.protocols.tcp-ip would be more appropriate, and I've directed
followups there.

>Basically, I'm implementing a server that will take input from telnet clients.
>It needs to operate on chars rather than lines (it supports a emacs-like
>command editing interface).
>
>To kick telnet into character mode, I assume that there is some
>DO/DONT/WILL/WONT type negotiation that needs to go on.  I grabbed rfc854,
>which specifies how to do the negotiation, but neglects to mention what the
>codes for specific options are.

The SUPPRESS-GO-AHEAD and ECHO options are often used to negotiate this.
Sending DO SUPPRESS-GO-AHEAD and DONT ECHO will generally put the client
telnet into character mode.  This isn't officially specified, but some
implementors have inferred it.  A more recent development is LINEMODE, but
not all TELNET clients are as likely to implement it (RFC 1116, which
describes LINEMODE, mentions how the aforementioned interpretation of SGA
and ECHO can be inferred).

>Could someone either tell me what the standard option codes are, or point me
>to a place where it is documented..

Since the option mechanism was designed to be extensible, the individual
options were not put in RFC 854 so that it wouldn't have to be revised
frequently.  Each option is documented in its own RFC, and the Assigned
Numbers RFC (the latest is RFC 1060) lists all the standard options and
references the appropriate RFC.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 92 17:05:23 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP terminal server port name.

In article <CHIP.92Apr23110350@ashley.cs.widener.edu> chip@cs.widener.edu (Chip Page) writes:
>	With a LAT connection to VMS, I can use the $getdvi(tt,
>tt_accpornam) system service to get the terminal server name and
>physical port name, of the tt terminal.  We use this to set up certain
>chars to each particular terminal, as well as other administrative tasks.
>
>	With TCP/IP, I have not found a way to do this.  This is what I 
>gather is happening.  The physical port gets mapped to a noreserved (high)
>tcp server port.  It then goes out on the net to connect to the
>destination node, tcp port 23.  What I need to do, is be able to find
>(for my terminal) the tcp service port on the terminal server, and then
>find the physical port it is mapped to.  
>	I see the remote port on the netstat display, so I think it is
>available.  Once I figure out how to get this number, I need to get the
>mapping info from the terminal server.  I heard that SNMP may be used
>to do this, and I'll look into that next (I never used it before).  

There's no easy way on Unix (which I assume is what you're using -- it
would be nice if people specified) to find the TELNET connection associated
with a user login session.  The problem is that the user process is talking
to a pty, the pty is talking to a telnetd process, and it's that telnetd
process that is talking to the telnet connection.  This indirect connection
between the user process and the network makes accessing the info
difficult.

What we did when we wanted terminal identification was to modify telnetd,
since it is the one program that has direct access to both the network
connection and the pty.  It extracts the terminal port number from the TCP
remote port number, looks this up in a file of terminal locations, and then
writes that information into the appropriate /usr/spool/ttyloc/ttyXX.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Apr 1992 18:07:58 GMT
From:      cherkus@resin.zk3.dec.com (Dave Cherkus)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3BSD Reno socket changes

OSF/1 supports both the 4.3 and the 4.3 reno interfaces.  If
_SOCKADDR_LEN is defined before <sys/socket.h> is included,
the 4.3 reno definition of sockaddr is used and calls that 
care about the structure (i.e. accept...) are mapped by 
#defines to new names (i.e. naccept...).

Dave

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Apr 1992 18:31:53 GMT
From:      mike@gordian.com (Michael Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP terminal server port name.

In article <CHIP.92Apr23110350@ashley.cs.widener.edu>, chip@cs.widener.edu (Chip Page) writes:
|> 
|> 	With TCP/IP, I have not found a way to do this.  This is what I 
|> gather is happening.  The physical port gets mapped to a noreserved (high)
|> tcp server port.  It then goes out on the net to connect to the
|> destination node, tcp port 23.  What I need to do, is be able to find
|> (for my terminal) the tcp service port on the terminal server, and then
|> find the physical port it is mapped to.  

   Aside from SNMP (which may be able to get the information with the char
mib), Telnet allows for two different IAC's to be negotiated for:

   LOCATION: (23) Tells the remote location of the box/port.
   TERMTYPE: (24) Tells the terminal type (e.g. vt100...)

   I have no idea whether Emulex supports either of these IAC's but the
Lantronix box does. Most telnetd's support TERMTYPE, but not as many
support LOCATION (the sources are probably available to the Berkeley 
telnetd and would be pretty easy to hack).
   One other means you might have is if you are using dedicated connections
there may be a way to telnet to a particular port instead of 23, and
thus on the server you could map each port to, say, 1000-100n and just
mung /etc/inetd.conf. Given this you would know the destination port and
the location (via the IP address of the box). I have seen people use
this tact, although it is sort of messy.

|> 	I see the remote port on the netstat display, so I think it is
|> available.
    You're barking up the wrong tree. The source port is essentially 
random. Emulex may give some rhyme or reason to it, but don't count on
it (multiple sessions are probably going to dork that assumption).
-- 


		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)

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 92 20:51:06 GMT
From:      johnson@tigger.jvnc.net (Steven L. Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP subnets connected via a different network

ji@cs.columbia.edu (John Ioannidis) writes:

>The Internet at large can only route packets to one location (well,
>you can have more than one routers connecting you to your regional or
>whatever, but they are still essentially one location).  Remember, IP
>routing is still done based on the network part of the IP address.
>Until core and regional routers start using netmasks with routes
>(hopefully as part of the Great Plan Of Internet Restructuring :-) )

This assumes that the backbone I wish to use to connect separate
subnets is the NSF T1 or T3 backbones (or a commercial provider).
In the case of the NSF backbones, isn't this related to EGP (or
BGP???) being used to redistribute routes?  And possibly with the
commercial providers simply a policy decision?

Would the use of OSPF or IGRP on a private 'backbone' address this
problem?  I seem to remember a previous discussion that BARRNet was
using OSPF to route (internally) via subnet rather than just the
network part of the IP address.

-Steve

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Apr 92 20:59:13 GMT
From:      pdh@netcom.com (Phil Howard )
To:        comp.protocols.tcp-ip
Subject:   FTP servers: ls output inconsistent

When I do a "mget *" it works fine on some FTP servers but not on others.
I'm not sure if this does an "ls *" or not but I tried it and found that
the output differs as well, and correlates with the problem.

The output from "ls *" (as typed from the FTP client while connected)
for a directory with a subdirectory might give files either of two ways:

[case 1]

subdir/file1
subdir/file2
subdir/file3


[case 2]

subdir:
file1
file2
file3


Now the question is, which is right?  Case 1 works and case 2 fails with
the client I am using.  Is it my client that is broken, or the server that
gives the output in case 2?
-- 
/***********************************************************************\
| Phil Howard  ---  KA9WGN  ---  pdh@netcom.com   |   "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Apr 1992 21:36:31 GMT
From:      fff@wimsey.bc.ca (Fred Fierling)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp printer servers

In article <CTDEAN.92Apr20163659@ares.talaris.com> ctdean@talaris.com (Chris Dean) writes:
>
>In article <1992Apr20.120550.29163@banana.fedex.com> bill@banana.fedex.com (bill daniels) writes:
>
>You also could buy a "Printer server in a box".  These devices have
>special host software that send print jobs to a black box connected to
>the Ethernet.  The black box then sends the the job through a parallel
>port to the printer.  Milan is a good company to call, they make a
>~ $1000 box.

We (Microplex) make such a device too.  For more info on our M200/M201
printer servers: info@microplex.com.
-- 
Fred Fierling    fff@wimsey.bc.ca       Tel: 604 875-1461   Fax: 604 875-9029

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 92 23:26:32 GMT
From:      ronm@slc.slac.stanford.edu
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP & Internet training

In article <1992Apr22.160422.446@galaxy.gov.bc.ca>, ewilts@galaxy.gov.bc.ca (Ed Wilts) writes:
> We're currently looking for a firm that is willing (for a fee of course) to
> teach some end-user TCP/IP courses.  Not the techie stuff that most TCP/IP
> courses offer but real novice topics:  NFS, Telnet, FTP, Archie, Usenet News,
> etc.  We've got the techies trained - now it's the end users turn.
> 
> Any info greatly appreciated.
> -- 
> 
> 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

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Apr 1992 00:15:21 GMT
From:      zee@fwi.uva.nl (Daniel M. van der Zee (I89))
To:        comp.protocols.tcp-ip
Subject:   Probably a very simple question

Hi all,

I've been trying to create a simple telnet program on my mac using tcp. When i
use it to connect to an ftp socket everything seems to work well (At least,
i get an error message back from the ftp server on illegal input). When i 
connect to the telnet socket (23, i believe) I just get the message 
"IAC WILL 24" and no matter what i do, nothing more happens. I read some
of the rfc articles but can't find what i do wrong.
Can someone give me a hint n how to get to a "login:" prompt?

Thanks,

Daniel van der Zee
zee@fwi.uva.nl

PS. If you post a reply, please e-mail me a copy. News gets erased very quickly
over here (2 days).




-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Apr 1992 08:00:30 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP subnets connected via a different network

In article <1992Apr23.205106.1597@tigger.jvnc.net> johnson@tigger.jvnc.net (Steven L. Johnson) writes:
>ji@cs.columbia.edu (John Ioannidis) writes:
>
>> [...]
>>The Internet at large can only route packets to one location (well,
>>you can have more than one routers connecting you to your regional or
>>whatever, but they are still essentially one location).  Remember, IP
>>routing is still done based on the network part of the IP address.
>>Until core and regional routers start using netmasks with routes
>>(hopefully as part of the Great Plan Of Internet Restructuring :-) )
>> [...]
>
>This assumes that the backbone I wish to use to connect separate
>subnets is the NSF T1 or T3 backbones (or a commercial provider).
>In the case of the NSF backbones, isn't this related to EGP (or
>BGP???) being used to redistribute routes?  And possibly with the
>commercial providers simply a policy decision?

Well, I wouldn't call it "simply". Distributing subnet routes rather
than network routes greatly increases not only the size of the
routing tables, but also the amount of routing information you have to
pass back and forth. 

>
>Would the use of OSPF or IGRP on a private 'backbone' address this
>problem?  I seem to remember a previous discussion that BARRNet was
>using OSPF to route (internally) via subnet rather than just the
>network part of the IP address.
>
>-Steve

The other set of questions is, if a lot of sites want to use this
feature, it *will* increase the routing tables and traffic; if not a
lot of sites want it, then the regionals/backbones/whatever will have
no real reason to put the mechanism in place. 

The point is that the tunneling solution works without much help from
the service providers, (just a couple of addresses), and can be used
*now*. The tunneling solution also works no matter how many regionals,
backbones, etc. you have to cross. For instance, it is unlikely that
EUnet would want to exchange subnetted routing information with the
NSFnet or CIX or whatever, so if you *really* want some of your
subnets in europe, you really don't have much choice.

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 13:49:52 GMT
From:      timmy@btcase.bt.co.uk (Tim Gibbons)
To:        comp.protocols.tcp-ip
Subject:   Wanted : Commercial version of SLIP

Does anyone know of a commercial version of SLIP for a
Sun SPARCstation 2 ? i.e. an implementation that is guaranteed robust and
fully supported by the vendor. If so, could they please give me
details.

Thanks 

Tim Gibbons  
-- 

Tim Gibbons                   	
usenet: timmy@btcase.bt.co.uk  

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 14:50:19 GMT
From:      baileyaj@zetbok.prl.philips.nl (Alister Bailey)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   SunOS TFTP/UDP checksum


Can anyone tell me how to turn ON the UDP checksum when used
by Sun's TFTP in OS4.1? It seems to default to zero and as 
far as I can tell there is no option for the command line or
in /etc/inetd.conf to turn it on.

Please reply direct.
               Thanks in advance. - Al.

==================================================================
Alister Bailey               internet: baileyaj@prl.philips.nl
  (An Englishman in exile)  intention: Al@snow.mountain.skiing
==================================================================

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 14:57:47 GMT
From:      dsbarr@modula.cs.psu.edu (Dave Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Probably a very simple question

In article <1992Apr24.001521.11033@fwi.uva.nl> zee@fwi.uva.nl (Daniel M. van der Zee (I89)) writes:
>Hi all,
>
>I've been trying to create a simple telnet program on my mac using tcp. When i
>use it to connect to an ftp socket everything seems to work well (At least,
>i get an error message back from the ftp server on illegal input). When i 
>connect to the telnet socket (23, i believe) I just get the message 
>"IAC WILL 24" and no matter what i do, nothing more happens. I read some
>of the rfc articles but can't find what i do wrong.
>Can someone give me a hint n how to get to a "login:" prompt?

Take a look at RFC 1143: "The Q Method of Implementing TELNET Option
Negotiation"  The IAC WILL 24 is a part of the telnet negotiations.

--Dave
-- 
Dave Barr            | "The Moral Majority" is neither.
dsbarr@cs.psu.edu    | .*\.([^.]+)\.\1\.\1$

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 15:04:52 GMT
From:      drawson@sagehen.Tymnet.COM (Dick Rawson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCAP protocol

TCAP is part of SS7 (signalling system number 7, also "CSS7").
It is published by ANSI as T1.114-1988.  SS7 is a BIG PROTOCOL!
Committee T1 approved T1.114-1992, but ANSI hasn't published that
edition yet.

Dick Rawson

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 15:38:07 GMT
From:      nelsonc@cs.rpi.edu (Chris Nelson)
To:        comp.unix.programmer,comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   telnetd problem

I'm working on a telnet client based on the BSD source from Feb 1991
which I pulled off the net.  The way my client works, I want telnetd
to NOT echo.  I've modified telnet.c so that my client declines the
servers offer to ECHO and I've injected code to trace the protocol so
I know what WILL/WONT/DO/DONT things are sent and recieved.

When the session begins, my client receives WILL ECHO, sends DONT
ECHO, and receives WONT ECHO.  When my client transmits the user id,
it is not echoed.  So far, so good.  However, after the client has
transmitted the user password, subsequent data is echoed.  It appears
that the ioctl calls which restore normal character display after
suppressing the display of the password are causing telnetd to resume
echoing without a telnet protocol exchange (WILL, etc.).  This is on
Sun OS 4.<something> and I've tried it with Sun's telnetd ver 1.24 and
1.25.

If worse comes to worse, I can do "echo cancelation" in the client by
remembering what was sent and not sending it to the terminal when it
is received from the net but I'd rather not have to go to this trouble.

Is this a known problem with Sun's telnetd?  Do other telnetds not have
this problem?  Any help and information is appreciated.

                                    Chris
------------------------------+----------------------------------------------
Chris Nelson                  |  Rens-se-LEER is a county.
Internet: nelsonc@cs.rpi.edu  |  RENS-se-ler is a city. 
CompuServe: 70441,3321        |  R-P-I is a school in Troy!
-- 
------------------------------+----------------------------------------------
Chris Nelson                  |  Rens-se-LEER is a county.
Internet: nelsonc@cs.rpi.edu  |  RENS-se-ler is a city. 
CompuServe: 70441,3321        |  R-P-I is a school in Troy!

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 16:12:51 GMT
From:      wayne@ultra.com (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Two Ethernets, one or two MAC addresses?

Random question of the day: If you have a Sun workstation with two
Ethernet interfaces, SunOS will always program the interfaces so that
they use the same 48-bit MAC address on both networks.

Does anybody know the trade-offs in doing this versus using unique MAC
addresses on the two nets?  (In other words, why did Sun choose to do
it this way, and does anybody else do it differently?)

Thanks much.

    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!

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 17:37:47 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Lance chip questions

In article <22255@olympus.wustl.edu>, christos@dworkin.wustl.edu (Chris Papadopoulos) writes:
|> 
|> 	I have some questions about the AMD Am7990 Ethernet controller
|> and the device driver on SunOS 4.0.3.
|> 
|> 	In my throughput measurements, I get a maximum of 7.5 Mbps between
|> two Sparcstation 1 workstations. I suspect that the Lance chip is the reason
|> I cannot get more. The network driver code says that only one packet at a time
|> is transferred to the transmit descriptor ring, so back-to-back transmission
|> cannot happen. Can anyone enlighten me on this? What kind of throughput are
|> you getting/are possible with the chip? 
|> 
|> 	One more thing: anyone knows what the memory bandwidth of a
|> Sparc 1 is?
|> 
|> 	Thanks in advance.
|> 
|> Christos.

The LANCE is not the problem.  I have programmed a LANCE to stream 64 byte packets on an ethernet (14k plus packets per second) and measured it using a Sniffer and another LANCE board in promiscuous mode.  If the inner packet gap (IPG in the LANCE documentation) is longer than the minimum 9.6 microseconds I would be surprised.  This testing was done to test out a bridge product that also used a LANCE.  

I suspect the lower than maximum rate you are seeing is because the Sparc is probably trying to use a real protocol stack such as TCP/IP.  If so then both hosts must transmit and collisions will occur.  The LANCE documentation states if a collision is detected, "TENA will remain asserted for at least 32 (but not more than 40) additional bit times."  It goes on to explain that this is called a JAM. Then the LANCE performs what is called, "truncated binary exponentail backoff".
This simply means that a delay before retransmission is calculated.  The formula is delay = slot_time * random_number.  slot_time is 512 bit times (51.2 microseconds) and random_number is chosen from 0 and 2 ^^k.  k is the min of 10 and the number of this retransmission.  

Note also that when a collision occurrs both Sparcs will do this algorithm.  Since the first random numbers will be either 0, 1, or 2, there is a one third chance you will see another collision.  

As for the statment that only one packet is transferred to the descriptor ring at a time, this is not a limitation of the LANCE.  Either the driver is simply stating that it has to be invoked for each packet or (horror :-)) the LANCE is only configured to have one transmit descriptor.  I hope the first is true but I have no way of knowing.

Hope this helps with your understanding of what your seeing.

-- 
Mark

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

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 17:49:04 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: need DEC LAT code

It is my understanding that DEC has now licensed someone else to license LAT so that they don't have to deal with it.  Unfortunately, I don't know who but I'm sure DEC does :-).  When we received our license for LAT at Racal-Milgo we were told by DEC that we received the first license and as such, the first attempt of transfering LAT technology.  The only thing we received of value were the license to sell and the protocol spec.  The tape delivered was pretty useless.  I hope this has changed since then.  




If not, I would recommend ki researches product.  I have talked with several people who have used the different host implementations to provide LAT conectivity to non DEC hosts and all have been satisfied.  I myself have only used the ki SUN package but they have a good reputation.  BTW, I am not now, nor have I ever been affiliated with ki in any way other than as a user of their product.

-- 
Mark

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

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 18:03:14 GMT
From:      hgschulz@cs.umass.edu (Henning Schulzrinne)
To:        comp.protocols.tcp-ip
Subject:   User locator service?

For some applications, it is important to find out which physical
workstation a user is located at (examples:  talk, packet voice, shared
whiteboard, etc.) finger does not provide that information easily,
except by exhaustively searching all machines. rwho is too expensive in
large networks since the whole user list is broadcasted periodically.
For a locator service, it would suffice to broadcast a specific location
request only on demand.  Thus, my question: has anybody developed a
protocol/software **in the Unix socket domain** that would locate a user
on a local network or within a domain?

Niceties to have: idle time, whether the user is remote logged in
through that machine or on the console (important for things like shared
whiteboards and packet voice).
---
Henning Schulzrinne  (hgschulz@cs.umass.edu)
Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst
Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 19:59:15 GMT
From:      stevec@caldwr.water.ca.gov (Steve Croft)
To:        comp.protocols.tcp-ip
Subject:   net managers

We are considering purchasing either HP OpenView or Sun's SunNet
Manager.  Does anyone have any comments about either of these
packages, pro or con?  Or any other packages they feel would be
superior?  Thanks!

Steve Croft
stevec@water.ca.gov
-- 
Steve Croft                        |
California Dept of Water Resources |  If what I said is wrong,
stevec@water.ca.gov                |  then it's not what I meant!

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Apr 1992 21:40:41 GMT
From:      johnh@mlb.semi.harris.com (John R. Hegstrom)
To:        comp.protocols.tcp-ip
Subject:   Mainframe printing over tcp net

Does anyone know of a way to get IBM Mainframe print jobs	
to a remote PC across a tcp-ip network?  We want to	
replace 3270 terminals and SNA controllers and printers
with PC equipment.  TN3270 with ftp's PC-TCP for terminal
access works great, ftp file transfers are file, but how
can we get print distributed?

We would prefer to get print output to disk for processing/viewing
on the PC and subsequent printing.

Anyone using LPR/LPD between an IBM and a PC?  Any other ideas?

John Hegstrom
jrh@mlb.semi.harris.com
Harris Semiconductor

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 22:17:47 GMT
From:      manmetha@gauss.rutgers.edu (Manju Mehta)
To:        comp.protocols.tcp-ip
Subject:   MAC - UNIX connectivity


Hi Netters,

	We have to write an application on the macintosh (client)
which would communicate with a remote AIX host. We are considering
the protocol that would best suit our purpose.

i.e. is TCP/IP available on the MACS (not being familiar with the
MACS). If so, I guess sockets would serve our purpose.


If we decide to write the MAC side of the appliaction using
APPLETALK, is there a product to do the translation between
APPLETALK and TCP/IP?

I've also heard a buzzword 'SLIP' floating around. What is 	  
SLIP, and would it be suitable for such a setup as ours?

Any other avenues that I could think of to get MAC-UNIX connectivity?

Any and all responses would be appreciated.


Thanx,


MAN.


manmetha@gauss.rutgers.edu
-- 
MAN

email : manmetha@gauss.rutgers.edu

MAKE NO PLANS. TAKE LIFE ONE DAY AT A TIME.

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Apr 92 22:31:58 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: Mainframe printing over tcp net

   Does anyone know of a way to get IBM Mainframe print jobs	
   to a remote PC across a tcp-ip network?  We want to	
   replace 3270 terminals and SNA controllers and printers
   with PC equipment.  TN3270 with ftp's PC-TCP for terminal
   access works great, ftp file transfers are file, but how
   can we get print distributed?

Check with your TCP/IP vendor for the big blue machine.  Some
vendors are starting to come out with solutions for redirecting
JES and CICS printing over TCP/IP and/or IPX.  It's been a long
time in coming...

 //======================================================================\\
||      Larry J. Hughes, Jr.       ||          hughes@indiana.edu         || 
||       Indiana University        ||                                     ||
||  University Computing Services  ||   "The person who knows everything  ||
||   750 N. State Road 46 Bypass   ||      has a lot to learn."           ||
||     Bloomington, IN  47405      ||                                     ||
||        (812) 855-9255           ||   Disclaimer: Same as my quote...   ||
 \\======================================================================//

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 22:53:07 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: MAC - UNIX connectivity

In article <Apr.24.18.17.46.1992.12041@gauss.rutgers.edu> manmetha@gauss.rutgers.edu (Manju Mehta) writes:
>i.e. is TCP/IP available on the MACS (not being familiar with the
>MACS). If so, I guess sockets would serve our purpose.
>
   Yup...you can get it from Apple if the MAC's are reasonably
   current.  
>
>If we decide to write the MAC side of the appliaction using
>APPLETALK, is there a product to do the translation between
>APPLETALK and TCP/IP?
>
    The most common is Cayman's Gatorbox.  Without knowing what you
    intend on doing, can't say it is guaranteed, but I'd be very
    surprised if it wouldn't.  

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 92 00:19:20 GMT
From:      mark@verdix.com (Mark Lundquist)
To:        comp.protocols.tcp-ip
Subject:   Arcane TCP question...

In RFC 793, the TCP functional spec., p. 72, there is something that I
can't figure out.

We're checking the ACK field on an incoming segment.  The spec states:

        SYN-RECEIVED STATE

          If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state
          and continue processing.

            If the segment acknowledgment is not acceptable, form a
            reset segment,

              <SEQ=SEG.ACK><CTL=RST>

            and send it.

In other words, if our this ACK acks our SYN... But shouldn't the test
be "SND.UNA < SEG.ACK", rather than "=<"?  If SEG.ACK = SEG.UNA, then
the other side has not acked our SYN.  Next, the spec states:

        ESTABLISHED STATE

          If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK.
          Any segments on the retransmission queue which are thereby
          entirely acknowledged are removed.
	  ...
          If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored.

Here is the test ("SND.UNA < SEG.ACK") that I would have also expected to
see for the SYN-RECEIVED state.  But then it says the ACK is a
duplicate if it's less than SND.UNA.  Shouldn't that be "<=" instead?

BTW, the 4.3BSD source for TCP does the ACK test in SYN-RECEIVED per
the RFC (i.e. the test that I think is incorrect).

Can somebody set me straight?


Also on the subject of the BSD code, a question about a macro defined
in tcp_fsm.h:

#define	TCPS_CLOSED		0	/* closed */
...
#define	TCPS_TIME_WAIT		10	/* in 2*msl quiet wait after close */
..
#define	TCPS_HAVERCVDFIN(s)	((s) >= TCPS_TIME_WAIT)

The name TCPS_HAVERCVDFIN suggests that it asks "have we received a
FIN on this connection?", and that's the way it seems to be used in
tcp_input.c.  But first of all, TIME_WAIT is the highest numbered
state, so if this is what they meant then why have a macro instead of
just testing (tp->t_state == TCPS_TIME_WAIT)?  More importantly, it
would seem to me that to test if you have received a FIN you would
test whether you were in one of CLOSE_WAIT | LAST_ACK | CLOSING
| TIME_WAIT.

Can anybody set me straight on this one?

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 92 00:41:11 GMT
From:      MLONG@isucard.card.iastate.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Mainframe printing over tcp net

In article <johnh.1@mlb.semi.harris.com>                                                                                                              
johnh@mlb.semi.harris.com (John R. Hegstrom) writes:                                                                                                  
                                                                                                                                                      
>Does anyone know of a way to get IBM Mainframe print jobs	                                                                                           
>to a remote PC across a tcp-ip network?  We want to	                                                                                                 
>replace 3270 terminals and SNA controllers and printers                                                                                              
>with PC equipment.  TN3270 with ftp's PC-TCP for terminal                                                                                            
>access works great, ftp file transfers are file, but how                                                                                             
>can we get print distributed?                                                                                                                        
>                                                                                                                                                     
>We would prefer to get print output to disk for processing/viewing                                                                                   
>on the PC and subsequent printing.                                                                                                                   
>                                                                                                                                                     
>Anyone using LPR/LPD between an IBM and a PC?  Any other ideas?                                                                                      
>                                                                                                                                                     
>John Hegstrom                                                                                                                                        
>jrh@mlb.semi.harris.com                                                                                                                              
>Harris Semiconductor                                                                                                                                 
>                                                                                                                                                     
                                                                                                                                                      
On the other ideas question - we are running distrubuted printing to our PC                                                                           
printers by using OS/2 with Extended Services.  We set up RSCS and pointed                                                                            
it to an LU in VTAM, which is pointed to an LU on the OS/2 station, which is                                                                          
then run set up as a printer in Comunication Manager.  Then you just attach                                                                           
the LU to whichever OS/2 to queue you want the jobs to print out on.  It                                                                              
works quite well for text print outs, but have been unsuccesful so far at                                                                             
printing graphics from SAS Graph.                                                                                                                     
Of course this process will require SNA, but it sounds like alot of the router                                                                        
vendors will/are routing SNA over a TCP/IP network.                                                                                                   
                                                                                                                                                      
We are also using these OS/2 machines as LAN Servers, so the HP LJ printers are                                                                       
printing out host and PC jobs seemlessly.  We are pleased with this setup.                                                                            
                                                                                                                                                      
Thanks                                                                                                                                                
Mike Long                                                                                                                                             
Iowa State University                                                                                                                                 

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Apr 1992 03:46:59 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: User locator service?

In article <46977@dime.cs.umass.edu> hgschulz@cs.umass.edu (Henning Schulzrinne) writes:
>For some applications, it is important to find out which physical
>workstation a user is located at (examples:  talk, packet voice, shared
>whiteboard, etc.) finger does not provide that information easily,

Check out the GNU finger program. When properly installed, it works
great. It also supports a -face option, so you can put your mugshot
online and people fingering you can also see what you look like!

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 92 04:01:51 GMT
From:      dwatts@ki.com (Dan Watts)
To:        comp.protocols.tcp-ip
Subject:   Re: need DEC LAT code

In article <38066@flying-disk.com> frisbie@flying-disk.com (Alan Frisbie) writes:
>In article <1992Apr21.164040.24001@novell.com>, 
>cranch@novell.com (Christopher Ranch) writes:
>> In article <1992Apr16.230909.1273@cton.uucp> 
>> nicholas@cton.cton.com (Nick Hennenfent) writes:
>>>I need the names/addresses of companies that sell licensed DEC LAT.
>> You email bounced.  The only place you can license LAT is from DEC.
>This is what you would expect, but it is wrong.   Under what I
>believe is a unique arrangement with DEC, you can obtain a LAT
>license (and, I believe, code), from:
>      Meridian Technology Corporation
>      11 McBride Corporate Center Drive, Suite 250
>      Chesterfield, Missouri 63005-1406
>      (314) 532-7708 (Voice)
>      (314) 532-3242 (FAX)







You can also license it directly from DEC or if
all you need is to be able to run LAT on your system,
contact one of the third parties that have licensed
 LAT [ki is one of these].




-- 
##################### Naturism, Grin and Bare It ######################
# CompuServe: >INTERNET:uunet.UU.NET!ki.com!dwatts  Dan Watts         #
# UUCP      : ...!uunet!ki.com!dwatts               ki Research, Inc. #
#######################################################################

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Apr 1992 05:46:22 GMT
From:      karches@utdallas.edu (Tom Karches)
To:        comp.protocols.tcp-ip
Subject:   Re: MAC - UNIX connectivity

In article <Apr.24.18.17.46.1992.12041@gauss.rutgers.edu> manmetha@gauss.rutgers.edu (Manju Mehta) writes:
>
>Hi Netters,
>
>	We have to write an application on the macintosh (client)
>which would communicate with a remote AIX host. We are considering
>the protocol that would best suit our purpose.
>
>i.e. is TCP/IP available on the MACS (not being familiar with the
>MACS). If so, I guess sockets would serve our purpose.
>

TCP/IP is available through a system extension called MacTCP. It is
available through APDA (Apple Programmers and Developers Association)
and is also packaged with some commercial and PD Mac TCP/IP software.

NFS file sharing can be done with a product called NFS/SHARE from 
Intercon Inc.

>
>If we decide to write the MAC side of the appliaction using
>APPLETALK, is there a product to do the translation between
>APPLETALK and TCP/IP?
>

What you need is a router. A hardware solution is a GatorBox from 
Cayman Systems. A product called Mach10 from Tenon Intersystems
will actually encapsulate TCP/IP packets inside of LocalTalk packets
and allow access between a connected Appletalk and Ethernet network.
It also happens to be a full implementation of BSD 4.3 Unix with a 
Mach kernel that runs on at minimum a Macintosh Plus with 4 meg.
of RAM.

>I've also heard a buzzword 'SLIP' floating around. What is 	  
>SLIP, and would it be suitable for such a setup as ours?

SLIP stands for Serial Line Internet Protocol. It allows TCP/IP
packets to be passed on a serial line. My guess (not knowing your 
application) that it might be too slow.

>
>Any other avenues that I could think of to get MAC-UNIX connectivity?
>
>Any and all responses would be appreciated.
>

I would follow the traffic on comp.sys.mac.comm


>
>Thanx,
>

Anytime.


>
>MAN.
>
>
>manmetha@gauss.rutgers.edu
 
-- 
-------------------------------------------------------------------------------
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

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Apr 1992 10:39:09 GMT
From:      salah@jitney.ecn.purdue.edu (Salah Benabdallah)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   CMU-tek tcp/ip



I received this message from a friend of mine...
Help is needed right away.

Many Thanks
Salah Benabdallah

===========================Message ==================================

 Hello,
  We installed the CMU-tek tcp/ip V6.6. As a Nameserver, we gave the 
name and the address of a DNS on the same LAN.
  The problem now is that 'telnet' and 'ftp' hang, unless you explicitly
  give the address, example
  $ telnet  192.68.138.11  --- connects
  $ telnet  carthago.rsinet.tn   --- hangs.

 The IPNCP command  HOSTNM :
   IPNCP> hostnm  192.68.138.11
 should reply by giving the correct name : carthago.rsinet.tn
 but instead, it also hangs.

 Any suggestions ?!
 Thank you, and we appreciate your help.

Please reply to : salah@ibnrochd.rsinet.tn (Salah Benabdallah) or
                : kamel@alyssa.rsinet.tn (Kamel Saadaoui)

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 92 17:35:49 +1200
From:      lin@lincoln.ac.nz
To:        comp.protocols.tcp-ip
Subject:   off-campus network loading assessment


We are trying to monitor off-campus network performance over a period and 
find the bottlenecks.

Does anyone know of a utility or a way to assess off-campus network loading?


Katherine

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 92 01:41:58 GMT
From:      news@iscnvx
To:        comp.os.vms,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: CMU-tek tcp/ip

>  We installed the CMU-tek tcp/ip V6.6. As a Nameserver, we gave the 
>name and the address of a DNS on the same LAN.
>  The problem now is that 'telnet' and 'ftp' hang, unless you explicitly
>  give the address, example
>  $ telnet  192.68.138.11  --- connects
>  $ telnet  carthago.rsinet.tn   --- hangs.
>
> The IPNCP command  HOSTNM :
>   IPNCP> hostnm  192.68.138.11
> should reply by giving the correct name : carthago.rsinet.tn
> but instead, it also hangs.

There is a mailing list available for CMU-TEK; you can post a question
to this mailing list and usually get back numerous responses within a
day or so, often directly from the developers. To subscribe to the mailing
list, send a one-line message to cmu-tek-tcp-request@cmutek.cc.cmu.edu.
The message should merely contain the word SUBSCRIBE. Subsequently you can
send your questions to cmu-tek-tcp@cmutek.cc.cmu.edu. I've found this
resource to be extremely useful.

As for your particular question, I had a similar experience (though not
identical to what you describe - in my case it didn't hang, it just timed
out after about thirty seconds and said something like 'no such name'). 
What worked for me is to add this line to the end of my NAMRES.CONFIG file :

Variable:RECURSE:1

Give it a try; it can't hurt. Also you may want to turn on detailed logging
for the NAMRES process so you can see what's going on. See HELP NAMRES LOG
in IPNCP for more information.

=============================================================================
Bob Marshall                        Clouseau: "Does your dog bite?"
Lockheed Missiles & Space Co.       Innkeeper:"No..."
Sunnyvale, CA                       Clouseau: "Nice doggie!"
                                    Dog:      "Rowr, rowr, rowr, chomp!"
marshall@force.decnet.lockheed.com  Clouseau: "You said your dog doesn't bite!"
                                    Innkeeper:"That is not my dog."
=============================================================================

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 92 02:02:28 GMT
From:      mayor@bayes.ece.cmu.edu (Gilberto S. Mayor)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and OSI

Hi,

I am trying to mach the TCP/IP protocols and the OSI seven layers model.
I would like to receive some sugestions.

OSI                      TCP/IP

---------           ----------- 
Transport               TCP
---------            ----------
Network                 IP
---------           ----------- 
Data Link
---------            ----------
Physical           Physical+ ARP/RARP

And what about the UNIX BSD socket interface ?
Which layer does it belong to ? Session layer ?
Thanks in advance,

Gilberto

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 92 03:17:07 GMT
From:      refling@sloth.eng.uci.edu (John P. Refling)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Help with FTP's PC/TCP Kernel, please.


I have a piece of software which "interfaces" with FTP's
PC/TCP kernel.  I have no idea what this is or where to
get it, or a public domain equivalent for the IBM PC.

Any help is appreciated.  Please e-mail to me at:

refling@sloth.eng.uci.edu
--
-----------
John Refling, refling@sloth.eng.uci.edu

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Apr 1992 03:46:37 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Two Ethernets, one or two MAC addresses?

In article <1992Apr24.161251.8246@ultra.com> wayne@ultra.com (Wayne Hathaway) writes:
>Does anybody know the trade-offs in doing this versus using unique MAC
>addresses on the two nets?  (In other words, why did Sun choose to do
>it this way, and does anybody else do it differently?)

Some protocols, notably XNS, require it -- an Ethernet address is supposed
to be the address of a *machine*, not a network interface.

There's nothing particularly wrong with it, unless perhaps you have the
two nets connected by a bridge and the bridge gets confused.

On at least some Suns, the add-on Ethernet interfaces don't even *have*
Ethernet addresses of their own -- they have no address PROM, and must
be programmed with an address by the host before they are used.
-- 
ISDN, n:  Incredibly Slow and Dumb      | Henry Spencer @ U of Toronto Zoology
Networking                              |  henry@zoo.toronto.edu  utzoo!henry

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 92 00:26:25 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Two Ethernets, one or two MAC addresses?

In article <BnAqHs.BAC@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <1992Apr24.161251.8246@ultra.com> wayne@ultra.com (Wayne Hathaway) writes:
>>Does anybody know the trade-offs in doing this versus using unique MAC
>>addresses on the two nets?  (In other words, why did Sun choose to do
>>it this way, and does anybody else do it differently?)
>
>Some protocols, notably XNS, require it -- an Ethernet address is supposed
>to be the address of a *machine*, not a network interface.
>
>There's nothing particularly wrong with it, unless perhaps you have the
>two nets connected by a bridge and the bridge gets confused.

Or if one of the physical networks has a small address space, such as
ARCNET's 1 byte physical addresses.  Can't run XNS or DECNET on those...

						don provan
						donp@novell.com

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 92 00:51:12 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP servers: ls output inconsistent

In article <6=8jxrk.pdh@netcom.com> pdh@netcom.com (Phil Howard ) writes:
>When I do a "mget *" it works fine on some FTP servers but not on others.
>I'm not sure if this does an "ls *" or not but I tried it and found that
>the output differs as well, and correlates with the problem.

Case 2, with the "subdir:" lines, is just completely wrong.  It's
suppose to return a list of file names, and "subdir:" ain't one.
Looks like some lamebrain piped his directory utility's output to the
FTP connection as the implementation of NLST in his FTP server.

There's been quite a bit of debate over the years about what a "file
name" is , and i don't think it's been really been settled.
Some people fell that the file name should be just the file name as it
appears in its directory (e.g., the UNIX name without any path).  Some
people feel that the file name should be relative to the "current
working directory".  Personally, i think the only reasonable file name
is the complete location of the file, free of any context like the
current working directory.  Since nowadays the UNIX file system is
the lingua franca between FTP servers and clients, this debate has
become somewhat moot.
						don provan
						donp@novell.com

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 92 12:10:02 GMT
From:      baileyaj@zetbok.prl.philips.nl (Alister Bailey)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: SunOS TFTP/UDP checksum


Thanks to everyone who responded - problem solved.
The consensus was that the offending variable is hiding in 
/sys/netinet/in_prot.c (which it was) and adb can be used to 
hack udp_cksum in /vmunix and /dev/kmem.
Cheers - Alister.
==================================================================
Alister Bailey               internet: baileyaj@prl.philips.nl
  (An Englishman in exile)  intention: Al@snow.mountain.skiing
==================================================================

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 92 17:30:01 GMT
From:      lcuff@tenon.com (Leonard Cuff)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.mac.misc,comp.lang.postscript
Subject:   Re: Berkeley LPD to Appletalk Postscript print servers?

matthews@advtech.uswest.com (John Matthews) 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?
 >  
 >  I know that TOPS can do this and that I can buy other products that will
 >  spool to a PC that has a serial/parallel attached printer but I was hoping
 >  to find something that would allow me to use all existing localtalk/ethertalk
 >  attached laserwriters the way TOPS does.  I am just wondering if there are
 >  any other intelligent software solutions besides TOPS, Mt Xinu, and Cayman
 >  GatorBox.  In other words, I'm wondering if there are any other solutions
 >  that run on the Mac-side.

The product my company makes, MachTen, Unix for the Macintosh, will do this.
More information available from

info@tenon.com


Leonard
-- 
Leonard Cuff          +Tenon Intersystems+                 lcuff@tenon.com

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Apr 92 17:54:41 GMT
From:      gauthier@ug.cs.dal.ca (Paul Gauthier)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.unix.sysv386
Subject:   Abort/Retry/Ignore on NFS mounted UNIX drive from DOS machine

Help!

I have a bunch of 486 machines running DOS 5.0 and FTP Software's TCP/IP and
NFS packages on an ethernet made up of WD Elite 16+ cards. Also on the network
is a 486 runnins SCO UNIX v.3.2.2 and TCP/IP, NFS. The DOS machines all mount
a part of the UNIX drive as their F: drive.

The DOS machines sit in a fairly tight loop scanning directories for new
files to appear. Very soon after bringing everybody online the DOS machines
start to crap out with Abort/Retry/Ignore error messages on their F: drives.

Any, I repeat *any*, information on what might be going wrong would place me
forever in your debt :-) We have no idea why this is happening, and no idea
where to start looking for the problem. To top it all off, this problem seems
only to be occuring consistantly in our production environment, not in our
developement setup (it happens there, but not frequently enough to be a
problem, and not reproducably).

Thanks,	
	PG
-- 
============================================================================
Paul Gauthier / gauthier@ug.cs.dal.ca      | "All general statements have
Phone: (902)462-8217    Fax: (902)420-1675 |  exceptions."
   ... I'm a .sig virus, copy me to the stdin of your shell; rm -r *; ...

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 92 18:40:29 GMT
From:      bansal@cis.ksu.edu (Vivek Bansal)
To:        comp.protocols.tcp-ip
Subject:   FAQ list.....

Is there a FAQ list for this newsgroup ? 
If so please let me know how can I get hold of a copy please...

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Apr 1992 00:27:18 GMT
From:      zbig@wariat.org (Zbigniew J. Tyrlik)
To:        comp.protocols.tcp-ip
Subject:   POP3 & NNTP server on Interactive 3.0



Has anybody installed POP3 server and NNTP 1.5.11 server on Interactive
3.0 ? I need to serve couple PC accessing my machine through packet
drivers & winQvtnet under Win3.1.... 

I am looking for configuration files. FTP access is OK...

Thanks for the help...

_zjt

-- 
********************************************************************
Zbigniew J. Tyrlik             wariat!zbig           zbig@wariat.org
IBM PC SIG Sysop - Cleveland Free-Net    aa609@cleveland.freenet.edu
Akademia Pana Kleksa   Public Access UNI* Cleveland,  (216)-932-3708
E-mail, news feeds, shell accounts   UnixBBS 1.02 distribution point 
********************************************************************

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Apr 1992 06:50:16 GMT
From:      peterd@tscc2.macarthur.uws.edu.au (Peter Degotardi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   simple dos mail package

I need a mail package that uses packet drivers.
The environment requires that I issue the command :-
	mail userid@host < textfile    (ala *nix)
Anyone know of such a beastie ??
--
Peter Degotardi        (__)   *  University of Western Sydney, Macarthur
PC Support Programmer  /00\   *  Teaching and Services Computing Centre
Fax    +61 46 26-6937   oo    *  Campbelltown, New South Wales, Australia !
Email  p.degotardi@uws.edu.au *  Just in case - 'My opinions are all mine !'

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Apr 92 15:48:34 PDT
From:      nader@cup.portal.com (Nader - al-Twaijri)
To:        comp.protocols.tcp-ip
Subject:   IP Encapsulation

before i invest in equipment, leased, line, etc.. i would appreciate it if
anyone would like to share their experiences with x.25 products that supports
IP encapsulation: performace, advantages, disadv.., brand names, service
you're using..  of course, i wud like to hear from sites that are actually
using this setup.. pls e-mail me, thanx

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Apr 1992 09:05:12 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: Informations on RFC1001 & 1002

In article <1399@srtp.UUCP> xavier@srt-poste.fr writes:
>I would like to know how I can get the RFC 1001 & 1002 taht describe the 
>implemetation of Netbios over TCP/IP Thanks

Send 2 mail messages to service@nic.ddn.mil

In the first message the subject must be 'RFC 1001' (without the quotes!),
in the second message 'RFC 1002'. You'll be mailed the RFCs.

Regards,
-Roger

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 92 11:21:06 GMT
From:      rla@media03.UUCP (Raymond van der Laan)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
Subject:   The final quest for TPC/IP API's for PC's

This is a quest for TCP/IP toolkits available for PC's that
communicate with Unix-hosts. The main reason for
posting this is that I want a final list of all vendors
that supply such toolkits (NetManage Chameleon, FTP etc.)

I just received Sun's PTK 2.0. The fact that I need 100K of TSR's
to make my application work (besides the .SYS drivers), and
that I can not communicate between applications and my
network-code (which I want to be a TSR) makes me desperately
seeking for another Toolkit.

I want to know:
* memory: what does it produce (like Sun: 150K for the simplest program?)
* possibility for network-code to be TSR, let application do interrrupt to acces this TSR
* compatibility (boards)
* price
* requirements
* experiences from users

Please email or fax, I'll summarize.

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

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 92 16:01:33 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.protocols.tcpip,comp.protocols.tcp-ip.ibmpc
Subject:   VT220 Emulation

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.

I would appreciate any kind of information!
-- 
------ < MAGIC > ------

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 92 18:09:26 GMT
From:      gjm@bio.vu.nl (Gijs Mos)
To:        comp.protocols.tcp-ip
Subject:   DECNET over ETHERNET for VME

I'm looking for a DECNET implementation (phase 4 (5???)) over Ethernet for
a VME computer. Preferably the ethernet card should be intelligent and
handle the protocol locally.
Any pointers?

Thanks in advance,
Gijs Mos
GJM@DASC.NL

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 1992 21:25:15 GMT
From:      karl@lvs.eng.sun.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Informations on RFC1001 & 1002


>I would like to know how I can get the RFC 1001 & 1002 taht
> describe the implemetation of Netbios over TCP/IP Thanks

Since I see that someone has already posted how to get the documents
all just add this warning:

There are not a great number of implementations of these protocols.  And of 
those that exist, only a few use the P or M node protocols.

			--karl--

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 92 21:54:26 GMT
From:      scottp@npg-sd.SanDiegoCA.NCR.COM (Scott Platenberg)
To:        comp.protocols.tcp-ip
Subject:   uucp over tcp

Sorry about the faq, but is there an RFC for uucp over tcp/ip?  Please let
me know. Thanks.
Scott
ps. Is there a faq list for this group somewhere?
--
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

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 92 21:58:17 GMT
From:      scottp@npg-sd.SanDiegoCA.NCR.COM (Scott Platenberg)
To:        comp.protocols.tcp-ip
Subject:   secure tftp

I am looking for info on "secure" tftp.  Can anyone help point me
in the right direction?  Thanks.
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

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Apr 92 00:06:10 GMT
From:      greg@duke.cs.unlv.edu (Greg Wohletz)
To:        comp.protocols.tcp-ip
Subject:   Re: Negative ping times

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.

						--Greg

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 92 15:57:46 GMT
From:      anderson@mayo.edu (Alfred I. Anderson)
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 <1992Apr29.144325.16186@maccs.dcss.mcmaster.ca> wucolin@popeye.CIS.McMaster.CA (Colin Wu) writes:

>Within the same office we have two NeXTstations on the same piece of thin co-ax  
>which is in turn connected to the campus ethernet.  These two NeXTstations  
>*will not* talk to each other.  I mean I can't even PING one from the other;  
>and yet, from all other machines on campus (including machines on the same thin  
>co-ax) I can PING, telnet, mail, etc. to *both* of these machines!  As far as I  
>can tell both machines have identical setups.  SO WHAT GIVES?!

Is the cable distance between the two systems too short?  What is the 
minimum distance spec....1 meter?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alfred Anderson                Internet:    anderson@Mayo.edu
Mayo Foundation
-----------------------------------------------------------------

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 92 17:26:02 GMT
From:      kimmel@nic.umass.edu (Matt Kimmel)
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 <anderson.27@mayo.edu> anderson@mayo.edu (Alfred I. Anderson) writes:
>In article <1992Apr29.144325.16186@maccs.dcss.mcmaster.ca> wucolin@popeye.CIS.McMaster.CA (Colin Wu) writes:
>
>>Within the same office we have two NeXTstations on the same piece of thin co-ax  
>>which is in turn connected to the campus ethernet.  These two NeXTstations  
>>*will not* talk to each other.  I mean I can't even PING one from the other;  
>>and yet, from all other machines on campus (including machines on the same thin  
>>co-ax) I can PING, telnet, mail, etc. to *both* of these machines!  As far as I  
>>can tell both machines have identical setups.  SO WHAT GIVES?!
>
>Is the cable distance between the two systems too short?  What is the 
>minimum distance spec....1 meter?

The hardware guys here all seem to agree that the minimum distance
between thinwire connections should be 2.5 meters.

-Matt

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Apr 1992 19:47:19 GMT
From:      wucolin@popeye.CIS.McMaster.CA (Colin Wu)
To:        comp.protocols.tcp-ip
Subject:   Re: Two NeXTstations won't talk to each other

In article <1992Apr29.174008.27112@nic.umass.edu> kimmel@nic.umass.edu (Matt  
Kimmel) writes:
> 
> In article <anderson.27@mayo.edu> anderson@mayo.edu (Alfred I. Anderson)  
 writes:
> >In article <1992Apr29.144325.16186@maccs.dcss.mcmaster.ca>  
 wucolin@popeye.CIS.McMaster.CA (Colin Wu) writes:
> >
> >Is the cable distance between the two systems too short?  What is the 
> >minimum distance spec....1 meter?
> 
> The hardware guys here all seem to agree that the minimum distance
> between thinwire connections should be 2.5 meters.
> 
> -Matt
I've tried changing that parameter as well.  The result was not encouraging!

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

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Apr 1992 20:05:15 GMT
From:      jam@hela.iti.org (Jonathan A. Morell)
To:        comp.org.acm,comp.org.ieee,comp.protocols.iso,comp.protocols.tcp-ip,comp.std.internat
Subject:   RFI Deployment of Integration Technology

               REQUEST FOR INFORMATION: RESEARCH ON
             DEPLOYMENT OF "INTEGRATION TECHNOLOGIES"

We define "integration technology" as information technology whose
purpose is to help different elements of an organization work in a more
highly coordinated fashion.  Networking technology is a good example, as
are distributed data bases and object management architectures.

The Industrial Technology Institute, under the sponsorship of DARPA, is
researching methods for improving the deployment of such technologies. 
By way of this message we are soliciting opinions about critical issues in the
deployment of integration technology.  We would like the views of
newsgroup readers and of their colleagues who may not personally read
these messages.

Our interest is in identifying critical activities that must be taken by each
of the parties with an interest in deployment  -  vendors, users, and third
parties (academia, standards bodies, government, etc.)  To spur discussion,
below is a brief overview of how we see the problem.

1-   Critical events, whatever they are, take place along the entire
     technology development life cycle, from initial research, through
     research and development, to implementation by end-users.  Vendors,
     users and third parties play different roles at different times along this
     life-cycle.

2-   Integration technologies have three characteristics that make their
     deployment problematic, i.e. a heavy emphasis on 1- conformance to
     standards, 2- common interfaces, and 3- a relatively large critical mass
     of users.

     1- Conformance to standards is required for interoperability among
     diverse products.  Standards are needed so that users can pick the
     exact mix of technology that will meet their needs; have some
     insurance against technological obsolescence; and have the ability to
     continuously improve their systems as new technology becomes
     available.

     2- Common interfaces in a company's computing environment are
     important so that different users, employing different applications, can
     interact.  Achieving this goal requires a high level, wide-spread
     consensus within an enterprise concerning how data should be
     structured, what should be available, and how interfaces should be
     designed.

     3- Many technologies provide value with a small number of users,
     and increase in value with the number of users.  Not so with
     integration technology, whose value inherently depends on a large
     number of users in a given setting.

Given this situation, what activities and events are critical to deployment,
and what roles must the various parties play at different times in the
technology life cycle?

Jonathan A. Morell
Industrial Technology Institute
PO Box 1485
Ann Arbor, MI 48106
(313) 769-4395 fax 4064
jam@iti.org

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Apr 92 20:22:35 GMT
From:      nur@dgbt.doc.ca (Nur Serinken)
To:        comp.protocols.tcp-ip
Subject:   Kerberos BSD sockets for Mac help

I have been trying to compile Kerberos Mac bsd socket
library. I have a problem about locating some of the include files
Can someone give pointers where these files can be found.

MacTcp version 1.1
MPW  C version 3.2
Kerberos distribution version ver 920211/mac

bsd sockets are in the non-mit/lib/bsd.

When I compile these I get the following files not found message;

ip_Interface.h
tcp_Interface.h
net_errno.h
nm_resolve.h
udp.h
mtypes.h

any ideas ?. 

Or I need BSD socket libs for mac, if someone can mail me compiled
and made library I will be very happy.

Nur  Serinken       | Communications Research Centre -DRL
		    | PO Box 11490 Stn "H"
                    | Ottawa, ON K2H 8S2
Voice-(613) 998-2289| Canada
Fax  -(613) 990-7987| 
INTERNET: nur@dgbt.doc.ca
-- 
Nur  Serinken       | Communications Research Centre -DRL
		    | PO Box 11490 Stn "H"
                    | Ottawa, ON K2H 8S2
Voice-(613) 998-2289| Canada

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 92 22:09:43 GMT
From:      stuart@rennet.cs.wisc.edu (Stuart Friedberg)
To:        comp.protocols.tcp-ip
Subject:   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!

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.

Stu Friedberg (stuart@cs.wisc.edu)

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 92 22:25:42 GMT
From:      jamie@vax.ftp.com (Jamie O'Keefe)
To:        comp.protocols.tcp-ip,comp.sys.next.sysadmin,comp.sys.next.misc
Subject:   Re: Two NeXTstations won't talk to each other

kimmel@nic.umass.edu (Matt Kimmel) writes:

 >The hardware guys here all seem to agree that the minimum distance
 >between thinwire connections should be 2.5 meters.
 >
 >-Matt

I don't think that is it.  We have run one meter segments between
pc's and had no problems.  

However unlikely it is, maybe both machines have the same hardware
address?   

I think the best thing you should do is get a Network/Protocol
Analyzer and see what the two hosts are sending to one another.
If you have a pc then there are a number of public domain packages
out there.  Netwatch (MIT) is one, I think.  You can run LANWatch if
you have a copy.  Network General Sniffers and Novell's Lananalyzer
are a few other commercial offerings.

jamie
--
Jamie O'Keefe		FTP Software, Inc.	Technical Support
Phone: 01-617-246-2920	Fax: 01-617-245-7943	Email: jamie@ftp.com

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 92 09:16:44 GMT
From:      wihuri@polaris.utu.fi (Pauli Wihuri)
To:        comp.protocols.tcp-ip
Subject:   LANtastic 4.1 & TCP/IP

Hi folks!

We have about the largest network of PC computers using LANtastic
(MS-DOS based network software, about 1000 micros connected) here in
the University of Turku, Finland. It was cheap software, you know.
They sold an unlimited version to us.

The problem which has been raising up from time to time is following:

We have mainframes (many SUN SPARCstations and a couple of VAX/VMS
machines) which are using TCP/IP. We use public domain NCSA-software
to get terminal sessions to the mainframes. We are about to choose
Visionware's XVision-software based on FTP Software Inc's software to
X-sessions from Microsoft Windows on microcomputers. Actually this
message is written with it from a intel's 486/33 machine. We use
mainly Western Digitals software configurable ethernet-cards (ELITE
PLUS).

BUT there is no chance to have LANtastic and TCP/IP-software loaded
together using the same ethernet-card, is there? This is the question
to you.

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

If not, does somebody know if there will ever come any solution to
this problem? If someone distantly remembers someone having asked this
same question before, please give me pointer to the fellow!

Mr. Pauli Wihuri
Computer Centre
University of Turku
Finland

ps. please any hint accepted with great gratitude...this could save us
lot of bucks from shifting to another network...

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Apr 1992 12:36:24 GMT
From:      stevea@i88.isc.com (Steve Alexander)
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:
>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
[ System hangs ]

We fixed this a few years ago by using a special case check in the TCP connect 
code:
	If laddr == faddr and lport == fport, return EADDRINUSE.

I don't know if this is the ideal behavior, but it's better than hanging the
machine :-> I'm open to suggestions for better ways to handle it.

-- 
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 92 13:26:35 GMT
From:      wucolin@popeye.CIS.McMaster.CA (Colin Wu)
To:        comp.protocols.tcp-ip
Subject:   Re: Two NeXTstations won't talk to each other

In article <920429182542@pericles.ftp.com> jamie@vax.ftp.com (Jamie O'Keefe)  
writes:
> I think the best thing you should do is get a Network/Protocol
> Analyzer and see what the two hosts are sending to one another.
> If you have a pc then there are a number of public domain packages
> out there.  Netwatch (MIT) is one, I think.  You can run LANWatch if
> you have a copy.  Network General Sniffers and Novell's Lananalyzer
> are a few other commercial offerings.

That was going to be my next step  (no pun intended).  We have both the Sniffer  
and an Excelan LanAlyzer.  I'll post my findings.
--
   __     _             _            Colin Wu
  /  )   //            ' )   /       Network Analyst
 /    __|/  o ____      / / / . .    Computing & Information Services
(__/ (_) \_<_/ / <_    (_(_/ (_/_    McMaster University
email:	wucolin@popeye.CIS.McMaster.CA	(NeXTmail welcome)
	wucolin@McMaster.CA		(Generic email only)

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 92 15:19:28 GMT
From:      venkat@metrix.UUCP (D Venkatrangan)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   info on loopback configuration

Hi.

I am looking for information on a particular protocol, initiated from
the link level on Ethernet with Ethertype 0x9000.  I have read somewhere
that it is called "Loopback Configuration".  The segment contains aside
from TCP/IP stations, a few Cisco routers.  Any information or pointers
to where I can this info is most appreciated.

---------------------------------------------------------------------------
D. Venkatrangan
Metrix Inc.			One Tara Blvd, Nashua, NH 03062
venkat@metrix.com		VOICE: (603) 888-7000 FAX: (603) 891-2796
---------------------------------------------------------------------------


-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 92 15:49:51 GMT
From:      u1906ad@unx.ucc.okstate.edu (11906)
To:        comp.protocols.tcp-ip
Subject:   TCP Over Token-Ring


I have been charged with the responsibility for finding software which 
will send tcp-ip packets over Token-Ring.  Does publically available software
exist, anywhere, for ftp, and what is it called?
It must run on an IBM Token-Ring card in a PC/XT.  If no such software exists,
this is also important to know.

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

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Apr 92 16:09:18 GMT
From:      ken@cton.cton.com (Ken Seefried III)
To:        comp.dcom.lans.ethernet,comp.protocols.tcpip
Subject:   PCRoute: 10baseT and Novell questions

-----

Two quick questions about PCRoute:

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

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

Many thanks...

				- ken 

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 92 19:52:47 GMT
From:      anderson@mayo.edu (Alfred I. Anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Over Token-Ring

In article <1992Apr30.154951.25449@unx.ucc.okstate.edu> u1906ad@unx.ucc.okstate.edu (11906) writes:


>I have been charged with the responsibility for finding software which 
>will send tcp-ip packets over Token-Ring.  Does publically available software
>exist, anywhere, for ftp, and what is it called?
>It must run on an IBM Token-Ring card in a PC/XT.  If no such software exists,
>this is also important to know.
 
>Martin McCormick WB5AGZ   Stillwater, OK
>O.S.U. Computer Center Data Communications Group


Martin,  I use this every day.  From my Mod 80 under DOS, I go out over IBM 
Token Ring using the TCP/IP drivers obtained from Clarkson.  This goes 
through a Cisco router to bridge to ethernet.

The NCSA software can be obtained from "ftp.ncsa.uiuc.edu" by anonymous 
ftp.  You'll get the Telenet and FTP software designed to work with the 
packet drivers.  I use the IBMTOKEN packet drivers to convert the NCSA 
ethernet calles into token ring calls.  Works great.

There is an excellent description of using the Clarkson packet drivers at "
boombox.micro.umn.edu" it is called pkt.doc (sorry, dont have the 
subdirectory handy).

Good luck!

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 92 20:02:43 GMT
From:      jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
To:        comp.protocols.tcp-ip
Subject:   A PC with 2 Ethernet interfaces?

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.

Send mail, I'll summarize and post to the net if anything develops.
--
J. Porter Clark    jpc@avdms8.msfc.nasa.gov or jpc@eb23.msfc.nasa.gov
NASA/MSFC Communications Systems Branch

END OF DOCUMENT