The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 00:21:38 GMT
From:      wanning@fvr.usask.ca (Mandy Zhu)
To:        comp.protocols.tcp-ip
Subject:   bpf

Hello net friends,

I need to install BPF to my SunOS kernel but I don't have SunOS 
source code handy. Could anybody help me to get the if_le.o for
sun4c SunOS 4.1.1? I will appreciate your help.


-Mandy


ps. My email address: wanning@cs.usask.ca

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 01:49:38 GMT
From:      longyear@netcom.com (Alfred Longyear)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP/PPP FAQ location?

anderson@dseg.ti.com (John H. Anderson) writes:

>Could someone point me to where a FAQ or similar document is
>for SLIP and/or PPP.

The PPP protocol has a FAQ. It is regularly posted to the 
news group comp.protocols.ppp. It is also archived, along with
most of the other news group FAQ documents, on rtfm.mit.edu.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1994 09:36:45 +1000
From:      ggm@dingo.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE question

mas1@letterbox.rl.ac.uk (Martin Strange) writes:



>So although more or less any Unix OS can receive and process multicast packets
>nowadays, if you actually want to have a decent feed onto the MBONE (i.e a
>pruning supporting one) you really have to put it on a SunOS 4.1.x machine.
>Simply because the new stuff hasn't been ported to anything else yet.

Pruning code dropped into Ultrix 4.2 patches which themselves drop into
Ultrix 4.3 just fine. 

Thats's two flavours of box doing pruning right now. Rumour mill says 
a better release is around the corner anyway. 

-George
-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 02:37:14 GMT
From:      makarios@sactoh0.sac.ca.us (Alan R. Gross)
To:        comp.os.ms-windows.apps,comp.os.ms-windows.setup,comp.windows.ms,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: selective appearance of network group under windows

In article <welsbyp.28.000B8693@qdpii.ind.dpi.qld.gov.au> welsbyp@qdpii.ind.dpi.qld.gov.au (Peter Welsby) writes:
>In article <2kq55k$675@agate.berkeley.edu> ucbked@athena (Earl H Kinmonth) writes:
>>From: ucbked@athena (Earl H Kinmonth)
>>Subject: selective appearance of network group under windows
>>Date: 27 Feb 1994 12:54:12 GMT
 
>>I run WINQVT using Novell odi drivers under Windoze 3.1.  I offer a
>>bootup menu that allows Windoze with and without the network drivers
>>Is there an elegant (simple) way of causing the network.grp file to
>>appear only when the proper drivers have been loaded?
>
>Not to my knowledge.  You could, of course, write a program for us both...
>
>The difficulty is that Windows records all info about defined (and always 
>available) groups in PROGMAN.INI.  All listed groups will always appear.  The 
>contents of each group is defined (and is always available) in group_name.GRP. 
> All included program items will always appear.
>
>>I could, of course, have two progman.ini files with and ...
>>That is not what I would call an elegant approach....
>
>Sounds downright disasterous to me.  Make a change to one setup, and lose it 
>for all others...
>pete

    Well, here is a downright ugly solution, that might work, please keep
in mind that I'm not very familiar with progman.ini.
    1. rename win.com to winn.com, or netwin.com
    2. write a dos batch file called win.bat, and make sure it's in a dir
that is in the user's path.
    3. In your win.bat file, test for the network first, if network is not
loaded, then call winn.com or netwin.com, to execute the normal progman.ini.
If the net is loaded, then first copy progman.ini to progman.sav or some such
thing. After that,append the necessary lines to the end of progman.ini thusly:

echo "network=xxxx" >>c:\windows\program.ini
echo "network.grp" >>c:\windows\progman.ini

    These are just samples, I don't know exactly what needs to be added to
progman.ini, but echo statements as above allow you to append a line at
a time to your progman.ini file. 
	at the end, copy progman.sav back to progman.ini. This will of course
wipe out any changes that the end user has made in the meantime, but as a
tech who has to constantly "find" windows for folks, I like that....
    If real changes need to be made, you can do them by starting winn.com,
instead of using win.bat.
-- 
# Randall A. Gross                                A.R.Gross@Sprint.com    #
# Sacramento Public Access UNIX                makarios@sactoh0.SAC.CA.US #  
# "Never give a rifle to a melancholic bore." W.H. Auden     Ego Loquito  #

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 04:01:37 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.unix.aix,comp.unix.admin,comp.security.unix,comp.protocols.tcp-ip
Subject:   Re: Once more: How do I log outgoing TCP/IP-connections ?

In article <2ksscv$120k@fikyrsk2.kymmene.fi> kymmene.kh.gronja@elvi.vtkk.fi writes:
>> We have access to the Internet through one RS/6000 (AIX 3.2.4). I would 
>> like to keep log when and where users have connections out of our network. 

I know of no such facility in any common Unix implementation.

You could use a network monitor to capture all the outgoing connection
requests.  If the connection is still open when you try to trace it back,
you can use the PD tool "lsof" to find the process that has it open.
Or you could have your network monitor use ident whenever it sees a
connection request, and record the user name.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 17:22:00 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <1994Mar2.002321.1129@unipalm.co.uk> ian@unipalm.co.uk (Ian Phillipps) writes:
>Hmmm..
>I've certainly no idea what he means, and I don't think he does, either.

   Maybe he wants them to run tcp/ip over X.25 over a pair of sync
   modems.  Should be about half as fast as SLIP or PPP, but what the
   heck, the user knows best!!



-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Tue, 01 Mar 94 11:54:12 PDT
From:      Joe Ford <fordjb@wln.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know a TN5250 client for PC or Mac ???


In article <2kd1cc$s8d@hobbes.cc.uga.edu>, <edm@harpo.dev.uga.edu> writes:
(Gerry Winsor) writes:
> >David Sims (sims@sndsn1.sedalia.sinet.slb.com) wrote:
> >: Does anyone know of a robust TN 5250 client for PC or Mac ?? Can a TN 3270
> >: client be used with a re-mapped keyboard ?? If so, has anyone done this
> >: for a PC-TCP client for DOS/Windows or a Brown University TN3270 client
> >: for Macintosh ?? Any help would be most welcome. 

NetManage has a TN5250 client as part of their Chameleon product.
They just released two new versions, both Win 3.1-based.

Call Jim Verdi at 408-973-7171.

Joe Ford <fordjb@wln.com>


-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 94 12:44:19 -0400
From:      wadleigh@process.com
To:        comp.os.ms-windows.apps,comp.os.ms-windows.setup,comp.windows.ms,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: selective appearance of network group under windows

Why not make it simpler:

Windows startup is preceded by a batch file that tests for the network drive.
If the drive is not present (i.e. the network is not installed), it renames 
the appropriate workgroup files from *.GRP to *.GRX using an internal list.
If the drive is present, it renames the .GRX files to .GRP.  If the filenames
are already proper for the current state, the normal batch error handling skips
the operation.

After this, you start Windows normally.  Since Windows recognizes Group file by
the extension .GRP, those that were renamed to .GRX simply do not appear.

Not especially elegant, but at least simple.


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 20:27:14 -0800
From:      eddy@girtab.usc.edu (George Edmond Eddy)
To:        comp.protocols.tcp-ip
Subject:   Re: cluster mbufs

jagane@netcom.com (Jagane D Sundar) writes:

>In article <JIM.94Feb9115510@dewar.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:
>>In article <2j8kp3$j1i@linus.mitre.org> jfjr@mbunix.mitre.org (Freedman) writes:
>>
>>       Could some one explain to me the intricacies of cluster mbufs or show me
>>   where to find the information?
>>
>	Briefly, mbufs are 128 byte structures that can hold data. If the size
>	of the packet is bigger you can either chain mbufs together or use
>	clusters which are 1k(in 4.3 BSD) buffers. The mbuf flags has M_EXT
>	set and the data pointer points to the cluster instead of into itself.
 
>	Your best reference is the Berkeley Net/2 code available widely at
>	ftp sites. Use with 'Design of the 4.3 BSD Operating System" by
>	McKusick, Karels et al.

be aware that the mbuf code has changed a bit from 4.3 -> 4.4 (Net/2),
for example the addition of m_hdr and m_ext, etc.  but the concepts
are still quite applicable.

>	Jagane
>	to hol

- rusty
-- 

- rusty

eddy@usc.edu

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 16:43:27 -0500
From:      kenton@navaho.cc.bellcore.com (gidewall,kenton c)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   TCP/IP over modem line?

My company is designing a system that is running TCP/IP.  We had planned
on using SLIP or PPP (pretty much decided on PPP) for the asynchronous
connections via 14.4 or 28.8 modems.  One of our clients saw our design
and said that he doesn't want to be forced to use PPP or SLIP and wants
to run straight TCP/IP across the phone line.

Now, intuitively, I can say that you can't do this, or at least you
shouldn't.  However, I can't tell him why.  I've searched the net and
read a lot on SLIP and PPP.  All that I can tell is that nobody does 
TCP/IP across a phone line.  Any documentation or discussion just assumes
that *of course* you use SLIP or PPP when you have a phone line, but I
can't find the technical reason(s) why that is true.

Can someone tell me why we don't use straight TCP/IP over phone lines
and why we need/should use SLIP or PPP?  Any pointers to documentation 
on the subject would be helpful, as then it wouldn't just be me telling
him, I could show him.

Also, if you post your reply, please mail it to me too.  Our news feed
is always really slow and I won't see any posted replies for about a 
week.

Thanks in advance,
   Kenton Gidewall
   kenton@cc.bellcore.com

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 14:48:59 GMT
From:      yan@biochemistry.bioc.cwru.edu (Yan Xiang)
To:        cwru.ins.general,comp.sys.mac.comm,comp.sys.mac.apps,comp.protocols.tcp-ip
Subject:   Looking for Mac tcp/ip client/servers

Hello:

I am just about to receive a Macintosh and am looking for
all types of TCP/IP clients/servers/utilities for this new
machine.

I have previosuly only been familiar with IBM-PC and DOS, and
Windows tools for some of these things, and could therefore
really use some help.

I have already found:
WWW - NCSA Mosaic
Telnet - NCSA Telnet
Mail - Eudora and POPmail/Mac
Gopher - TurboGopher and MacGopherApp

If you think of interesting viewers or programs that I should
have please tell me the ftp sites and directory/filename.  If there is
sufficient interest then I will post a summary catalog by
item-type to the net.

Thank you,

Yan Xiang
yan@biochemistry.bioc.cwru.edu


--
Yan Xiang
yan@biochemistry.bioc.cwru.edu

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 14:56:35 GMT
From:      Doug.Bradley@launchpad.unc.edu (Doug Bradley)
To:        comp.protocols.tcp-ip
Subject:   SLIP (Help!) for PC, NT?

Any PD implementations of SLIP out there? 
Would appreciate any pointers, especially to PC, NT versions.

many tia,
doug
bradley@wg.com


--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 16:28:32 GMT
From:      aterczka@track.cslab.tuwien.ac.at (Alexander Terczka)
To:        comp.protocols.tcp-ip
Subject:   pop-client for unix ?


  I need a POP3 client for unix. where can I get the source ?
  My Unix (linux) has a POP3 Server but I could not find a client.
  Or is smail able to receive mails using POP3?

  Thank you in advance  		Alex
				aterczka@cslab.tuwien.ac.at
 				h9125200@obelix.wu-wien.ac.at

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 17:12:38 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 Address resolution for TCP/IP networks.

In article <2kt97r$sek@olivea.ATC.Olivetti.Com> rajn@sassella.ico.olivetti.com (Rajendran) writes:
>We are currently trying to implement an address resolution package
>for TCP/IP over X.25 and to achieve this objective
>I have recently acquired a document about Address resolution
>over X.25 Networks (xarp) called "X.121 Address resolution for IP 
>Datagram Transmission ove X.25 Networks." by Carl-H.Rokitansky,
>Fern University of Hagen , dated July 1990.In the status of the 
>document it says "This draft will be submitted to the RFC editor 
>as a standards document." However,looking through the list of RFC's I am
>unable to find the corresponding standard.Therefore, I would 
>like to know 
>
>	1. Is this document an RFC ? If yes , what is the 
>	   reference number?
>
>	2. If No is there an alternative relevant document
>	   which should be consulted ?
>
>	3. Does anyone know if there any implementation 
>	   ( public domain or comercial ) which uses this standard ?
>
>	4. What is  the position of this document vis-a-vis 
>	   RFC-1236 ( IP to X.121 Address Mapping for DDN ).
>
>I also have some other doubts which I hope sonmeone can clarify.
>
>	1.All the  procedures seem to demand an apriori knowledge
>	  of some 'xarp server' as call requests are made to this 
>	  server.Is there one in the internet which performs this 
>	  role ?
>
>	2. Is aging foreseen in the protocol ?
>	
>	3. Would it be difficult to consider a referral mechanism 
>	   wherein an xarp server returns the address of another
>	   xarp server which the sending node may or may not choose
>	   to contact ?
>
>	4.How are the different channels (PVC and SVC) handled ?
>	  For example if hosts A and B can communicate using
>	  both SVC and PVC other than using different subnets 
>	  how does a TCP application specify the type of channel
>	  to use ?
>	
>
>I would be obliged if I get my answers by e-mail eventhough
>I shall look through the newgroup for some time.
>
>Thank you in advance ,
>
>V.Rajendran (rajn@sassella.ico.olivetti.com)
>Please note that I use a different e-mail address and a 'reply to author'
>may not work.

Most of the work cited above has died.  There were some attempts to
prototype the protocols, but I don't think there is any more work
going on.  I haven't had time to follow things, but a generalized
solution to this problem are the kinds of things that the ROLC
working group of the IETF are dealing with.

Most of IP<->X.25 address mapping is done today using locally configured
table lookup.  In the US DoD, there are nets that use the DDN and
Blacker translation algorithms, but only limited use outside that
environment.

Art


-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 17:46:51 GMT
From:      jrv@truth.mitre.org (Van Zandt)
To:        comp.protocols.tcp-ip
Subject:   Internet availability studies?

I have proposed use of the Internet for distributing short messages 
over long distances.  My experiments with "ping" suggest the message
delivery times are short enough.  However, a question has now come
up regarding the _availability_ of the net (i.e. the fraction of the
time the network is available).  Can anyone point me toward studies
of Internet availability over intercontinental distances?

                     - Jim Van Zandt <jrv@mitre.org>

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 17:49:57 +0000
From:      alistair@ichthya.demon.co.uk (Alistair Bell)
To:        comp.protocols.tcp-ip
Subject:   Re: ? PC-based TCP/IP Decode Analyzer?

In article <2kstrf$6rt@liberator.et.tudelft.nl> ling@dutepp9.et.tudelft.nl writes:

>Inexpensive: Novell's LANalyzer might be what you're looking for.

Err... LANalyzer is very good (we use it) but it certainly isn't inexpensive
(it's about GBP 700 ($1000 to you Americans) here) and its TCP/IP decodes
aren't wonderful (e.g. it can't cope with NFS beyond the UDP level). However,
it's VERY good for such things as IPX and NetWare (unsurprisingly)

-- 
Alistair Bell,
Brown's Operating System Services Ltd.,
St. Agnes House,
Cresswell Park,
Blackheath,
London
SE3 9RD.
Tel. 081-852 3299.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 17:50:09 GMT
From:      hiren@li.loral.com (Hiren Chandiramani)
To:        comp.protocols.misc,,comp.protocols.iso,,comp.protocols.tcp-ip
Subject:   Wanted : Statistics on X.25 and TCP/IP


Hi,
Can anyone tell me where I can statistics on the number of nets/users using
X.25 ? I would also like to find the same information on TCP/IP. 

Any pointers to this information would be helpfull and greatly appreciated.

Thanks,
-Hiren Chandiramani
hiren@li.loral.com

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 94 23:10:08
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD-Sockets vs. AT&T TLI

> I have a server running AT&T's TLI interface (Solaris) in one end. Is
> it possible to use BSD-Sockets (HP) in the other end?

Of course. How do you think for instance a Solaris 2.x workstation talks to
a SunOS 4.1.3 workstation? Hint: The API doesn't matter as long as they speak
the same protocol.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 18:25:50 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: SYN-RECEIVED-->CLOSE-WAIT

In article <CLyIvr.uun@austin.ibm.com> peter@tkg.com writes:
>In rfc793, it says that a connection in the SYN-RECEIVED state
>should go to the CLOSE-WAIT state when it receives a FIN.

Well, yes, it *says* that on page 75, but actually back on page 72,
any packet without the ACK bit is dropped, and any packet with a legal
ACK moves a connection in SYN-RECEIVED state to ESTABLISHED state.
(There's no legal ACK which doesn't ACK the SYN.)  In other words, by
the time packet processing gets to page 75, the connection *can't* be
in SYN-RECEIVED state, so the transition from there to CLOSE-WAIT is
fictitious.  Ye Olde State Diagram on page 23 supports this by showing
no such transition.

>This
>is causing problems, since in the BSD implementation (and others
>I'm sure) the connection isn't presented to the user (via the
>accept() call) until it reaches the ESTABLISHED state.  This
>means that there is no way that the user process can close the
>connection once it goes into the CLOSE-WAIT state in this
>manner, since it doesn't have a file descriptor to it, and it
>doesn't know that it exists.

Yes, this would be a problem.  The connection *does* reach ESTABLISHED
state and is in that state from page 72 until it gets bumped from
ESTABLISHED to CLOSE-WAIT on page 75.  I don't know much about the BSD
code, but if the BSD implementation misses that first state
transition, that would explain why connections stuck in CLOSE-WAIT
state are such a common problem on BSD derived systems.

>The result is that you get CLOSE-WAIT connections hanging around
>forever on the LISTEN socket, taking up valuable queue space.
>It seems to me that this must be a known problem, or perhaps I'm
>not looking at it right.

The CLOSE-WAIT connections are a known problem that have been reported
on UNIX machines for as long as I can remember.  (I think 1983 was the
first time I heard of this problem...)

>In either case, can anyone tell me if
>there's a way out of this sad state of affairs?

It sounds to me that you've put your finger on the problem, and all
that's required now is a bug fix.  (I haven't heard of one, but, as I
say, I don't pay much attention to BSD patches.)

						don provan
						donp@novell.com

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 18:39:50 GMT
From:      MMORSE@nsf.gov (Michael Morse)
To:        comp.protocols.tcp-ip
Subject:   Re: INT14 Handling: What is needed?

>I have seen several NOS's that claim to support INT14.  My question is what 
>do they mean by support?

They mean that you can run the terminal emulator of your choice over their 
Telnet client.  Most telnet commands come with a reasonably capable terminal 
emulator of their own, but you may have a preference, or need a feature not 
supplied.  INT14 is the interface used between your third-party terminal 
emulator and the Telnet client provided with the TCP/IP package.

>Here's my problem:  I have a PC connected to a LAN using TCP/IP (10BaseT).  I 
>also have ProComm on my PC but no modem attached to a serial port.  There 
>are, however, modems attached to a terminal server elsewhere on the network.  
>I am using SUN PC-NFS on the PC.  What product(s) do I need to allow ProComm 
>to see the modem at the other end?

You probably don't need any products.  First, try just using PC-NFS's telnet 
command to connect to the terminal server.  If that works, it may be all you 
need.  I believe PC-NFS also includes a INT14 interface, so you could also 
run ProComm that way (you will need a version of ProComm that talks to 
INT14--not all do).

>If you have the answer using a different NOS, I would gladly accept it.

You may find that even though things kind of work, they don't work 
perfectly.  Things like CRLF processing (recently discussed) and 7 vs 8 bit 
transfer can mess up some file transfer utilities.

--Mike

Michael Morse                           Internet: mmorse@nsf.gov
National Science Foundation               BITNET: mmorse@NSF
1800 G St. N.W. Room 401               Telephone: (202) 357-7659
Washington, D.C.  20550                      FAX: (202) 357-7663

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 19:21:30 GMT
From:      sjs@ulysses.att.com (Steve Silverman[smb] MT 3F-114)
To:        comp.protocols.tcp-ip
Subject:   Course Advertisement

Some time ago I noticed an advertisement for a TCP/IP course
in Manchester, England given by a Dr. Carpenter.  

What is the protocol for such ads on the net.  I did not see any
comments that followed the ad.

Sorry if this has already been addressed.

I teach a course on TCP at Bell Labs that I would like to advertise as well
if possible.

steve silverman
sjs@mtketc1.att.com


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 94 19:58:28 GMT
From:      a09878@giant.rsoft.bc.ca (Curt Sampson)
To:        comp.protocols.tcp-ip
Subject:   Information on/FAQ for Part-Time Internet Connections Wanted

I'm looking for information on running "part-time" (not permanently
connected) connections to the Internet (via dialup SLIP or whatever).
Specifically, I'm interested in ways to deal with the
store-and-forward aspect that becomes necessary (news, mail, etc.),
thoughts about how the addresses should be set up for proper routing,
and the like. I'll take pointers to books, FAQ lists or whatever
you've got.

Is it practial to use dialup IP to run what would essentially be a
store-and-forward network, or is it best to stick to uucp for that?

cjs
--
Curt Sampson  a09878@giant.rsoft.bc.ca  
Fluor Daniel		  604 691 5458	
1444 Alberni Street			
Vanouver, B.C., V6G 2Z4			"Small cows work best." --Ty Bower

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 20:07:29 GMT
From:      melbye@stkh22.alcatel.no (Jan Olav Melbye)
To:        comp.protocols.tcp-ip
Subject:   BSD-Sockets vs. AT&T TLI

Hi folks !

I have a server running AT&T's TLI interface (Solaris) in one end. Is it possible
to use BSD-Sockets (HP) in the other end? 

-- Jan Olav


-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 21:10:38 GMT
From:      hiren@li.loral.com (Hiren Chandiramani)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Wanted : Statistics on X.25 and TCP/IP

Hi,
I am interested in collected statistics on the number of users/nets currently
using X.25 . I also need the same information for TCP/IP. 
I would appreciate it if someone can give me pointers as to where to find
this information. Any help is greatly appreciated.

Thanks

-Hiren Chandiramani
hiren@li.loral.com

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 94 22:08:58 GMT
From:      larry@dprmpt.dataprompt.com (Larry)
To:        comp.protocols.tcp-ip
Subject:   Traceroute program

I have used 'traceroute' on a SCO Unix system and found it to be a big
help.  I downloaded 'traceroute' from several archives archie told
me about, but it seems to be written exclusively for Suns (i.e.
BSD-style systems).

Is there a version around somewhere that has been ported to System V?
We are using Amdahl's UTS, but if it works on System V I can usually
coerce it to work on UTS.  Many thanks in advance for any pointers.

Please E-mail responses.  I will post a followup if I get any
feedback.
--
* - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
*     Larry Johnson                         VOICE:  (301) 622-0900          *
*     INTERNET: larry@dataprompt.com        UUCP:   ...!uunet!dprmpt!larry  *
* For a smashing good time, it's the Tonya HotLine 1-(900)-#*  (pound-star) *
* - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *


-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 00:23:21 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <2l0ctv$8r9@navaho.cc.bellcore.com>,
gidewall,kenton c <kenton@navaho.cc.bellcore.com> wrote:
>My company is designing a system that is running TCP/IP.  We had planned
>on using SLIP or PPP (pretty much decided on PPP) for the asynchronous
>connections via 14.4 or 28.8 modems.  One of our clients saw our design
>and said that he doesn't want to be forced to use PPP or SLIP and wants
>to run straight TCP/IP across the phone line.

Hmmm..
I've certainly no idea what he means, and I don't think he does, either.
SLIP stands for Serial Line Internet Protocol. All it is is a couple of
escaped sequences that tell you where a packet begins. Pretty minimal.

Ethernet, etc., are packet-oriented by their nature, so can pass IP
easily. A serial line isn't, and needs a little help. SLIP is about as
little help as you can give it. Without an end-of-packet marker, one
error and you're sunk.

>Can someone tell me why we don't use straight TCP/IP over phone lines
>and why we need/should use SLIP or PPP?  Any pointers to documentation 
>on the subject would be helpful, as then it wouldn't just be me telling
>him, I could show him.

The SLIP overhead is minimal. With Van Jacobsen compression, it's
negative!

Ian
-- 
Ian Phillipps. Tech support manager, Unipalm. News admin, pipex. Internic: IP4
"... we had no interoperability goal when designing ****.  Therefore the product
interoperates with itself." [A quote from a developer of a TCP/IP product.]
Name omitted to protect the guilty.

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 10:53:21 -0500
From:      ddj@gradient.gradient.com (Dave Johnson)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Solaris 2.3 tcp problems

We are seeing problems with TCP/IP connections on our
Solaris 2.3 server.  Just recently we found out about the
"ndd" command to tweak network driver parameters, and
it has been of some help, but the problems have not all
been solved.

First, Solaris 2.3 uses the range of 32768-65535 for port
numbers when you bind a socket with an unspecified port.
This caused problems with SMTP to at least one network
once the system has been up a while.  The attempts to
deliver mail would all fail with a timeout:

  Mar  1 16:50:09 gradient sendmail[24797]: AA02501: to=someone@austin.ibm.com,
	delay=1+01:40:25, stat=Deferred: Host netmail.austin.ibm.com is down

Attempting to connect to this machine from a SunOS 4.1.3 machine succeeded.
When I lowered the range of ports to 2048-32767, the mail
was delivered after the next attempt:

  # ndd -set /dev/tcp tcp_smallest_anon_port 2048
  # ndd -set /dev/tcp tcp_largest_anon_port 32767

Second, I'm seeing problems with SMTP and FTP specifically with
the host crimelab.crimelab.com.  Again the problems occur only
with the Solaris2.3 machine, but not with for example SunOS 4.1.3.
What I see is mail from crimelab.com will be delivered if the message
is tiny (5 lines maybe), but the connection times out otherwise.

  Mar  1 20:47:31 gradient sendmail[27501]: AA27501:
	SYSERR: net hang reading from crimelab.crimelab.COM:
	Connection timed out during collect with crimelab.crimelab.COM
  Mar  1 20:47:31 gradient sendmail[27501]: AA27501:
	message-id=<9403020132.AA27501@indy.gradient.com>
  Mar  1 20:47:31 gradient sendmail[27501]: AA27501:
	from=<bugtraq-owner@crimelab.crimelab.com>, size=0, class=0,
	received from crimelab.crimelab.COM (198.64.127.1)

In addition, if I use their anonymous FTP site, I can cd, pwd, dir,
and usually get small files, but attempting to download large files
consistently fails.  The destination file is not created, and
the connection never makes it out of SYN_RCVD state.

  ftp> get bugtraq_digest.V1.2
  200 PORT command successful.
  150 Opening BINARY mode data connection for bugtraq_digest.V1.2 (90511 bytes).
  ^Z
  Stopped (user)
  gradient=> netstat -a | grep crime
  indy.gradient.com.34853 crimelab.crimelab.COM.ftp-data  8694      0 25116      0 FIN_WAIT_2
  indy.gradient.com.3800 crimelab.crimelab.COM.ftp  8694      0  9660      0 ESTABLISHED
  indy.gradient.com.3808 crimelab.crimelab.COM.ftp-data     0      0 25116      0 SYN_RCVD


Finally, we see hundreds of sockets in FIN_WAIT_2 state after the
machine has been up a while.  Most of them are from PC Eudora
connecting to popper 1.831beta, although you'll notice one from
crimelab.crimelab.com.ftp-data stuck in FIN_WAIT_2 at the moment.
 Of course rebooting gets rid of these, but they should not be
backing up like this.

Does anyone have any suggestions for tuning tcp or ip to make these
problems go away?  We have put in all the latest mandatory patches,
to no avail.

For completeness, here are the values of the writable tcp and ip 
parameters at the moment:
--------------------------------
tcp_close_wait_interval = 240000
tcp_conn_req_max = 5
tcp_conn_grace_period = 500
tcp_cwnd_max = 32768
tcp_debug = 0
tcp_smallest_nonpriv_port = 1024
tcp_ip_abort_cinterval = 240000
tcp_ip_abort_interval = 120000
tcp_ip_notify_cinterval = 10000
tcp_ip_notify_interval = 10000
tcp_ip_ttl = 255
tcp_keepalive_interval = 7200000
tcp_maxpsz_multiplier = 1
tcp_mss_def = 536
tcp_mss_max = 65495
tcp_mss_min = 1
tcp_naglim_def = 4095
tcp_old_urp_interpretation = 1
tcp_rexmit_interval_initial = 500
tcp_rexmit_interval_max = 60000
tcp_rexmit_interval_min = 200
tcp_wroff_xtra = 32
tcp_deferred_ack_interval = 50
tcp_snd_lowat_fraction = 0
tcp_sth_rcv_hiwat = 0
tcp_sth_rcv_lowat = 0
tcp_dupack_fast_retransmit = 3
tcp_ignore_path_mtu = 0
tcp_rwin_credit_pct = 50
tcp_rcv_push_wait = 16384
tcp_smallest_anon_port = 2048
tcp_largest_anon_port = 32767
tcp_xmit_hiwat = 8192
tcp_xmit_lowat = 2048
--------------------------------
ip_rput_pullups = 0
ip_forwarding = 2
ip_respond_to_address_mask_broadcast = 0
ip_respond_to_echo_broadcast = 1
ip_respond_to_timestamp = 0
ip_respond_to_timestamp_broadcast = 0
ip_send_redirects = 1
ip_forward_directed_broadcasts = 1
ip_debug = 0
ip_mrtdebug = 0
ip_ire_cleanup_interval = 30000
ip_ire_flush_interval = 1200000
ip_ire_redirect_interval = 60000
ip_def_ttl = 255
ip_forward_src_routed = 1
ip_wroff_extra = 32
ip_cksum_choice = 1
ip_local_cksum = 0
ip_ire_pathmtu_interval = 600000
ip_icmp_return_data_bytes = 64
ip_send_source_quench = 0
ip_path_mtu_discovery = 0
ip_ignore_delete_time = 30
ip_ignore_redirect = 0
ip_output_queue = 1
------------------------------------

Thanks in advance,

	Dave Johnson
	Gradient Technologies, Inc.
	ddj@gradient.com

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 09:43:14
From:      bruceg@pdn.paradyne.com (Bruce Grunewald)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know a TN5250 client for PC or Mac ???

In article <2kd1cc$s8d@hobbes.cc.uga.edu> edm@harpo.dev.uga.edu (Ed Maioriello) writes:
>From: edm@harpo.dev.uga.edu (Ed Maioriello)
>Subject: Re: Anyone know a TN5250 client for PC or Mac ???
>Date: 22 Feb 1994 13:29:48 GMT
 
>In article <CLLA5E.Azn@hpwin052.uksr.hp.com> gerryw@hpwin052.uksr.hp.com (Gerry Winsor) writes:
>>David Sims (sims@sndsn1.sedalia.sinet.slb.com) wrote:
>>: Does anyone know of a robust TN 5250 client for PC or Mac ?? Can a TN 3270
>>: client be used with a re-mapped keyboard ?? If so, has anyone done this
>>: for a PC-TCP client for DOS/Windows or a Brown University TN3270 client
>>: for Macintosh ?? Any help would be most welcome. 
>>

The current release (4.0) of Chameleon by Netmanage has a tn5250 client. I 
can't make any claim for robustness as I have not tested 5250, but the rest of 
the package works well. This is a Windows package with Telnet, FTP (client 
and server), news reader, mail client, and a bunch of other stuff. You can get 
more info by getting the FAQ in comp.protocols.tcp-ip.ibmpc, including phone 
numbers for the vendor. Think it lists for $395, or $495 with NFS.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 94 13:50:14 -0500
From:      jeff <golano@delphi.com>
To:        comp.protocols.tcp-ip
Subject:   PPP under UnixWare 1.1

I just installed UnixWare v1.1 on my machine and have had nothing but problems
since; so I was hoping that somebody out there might be able to help.
This is a brief description of the problems I've been having:
 
1) When mail comes in via SMTP, the sockets will not close down after a
connection has ended. Instead, they remain in a "CLOSE_WAIT" state. The only
way I can clear up the sockets is to kill and restart the sendmail deamon.
After some debugging, it turns out that often our system does not send a
greeting to the remote host. Despite this, our systems says that a connection
has been established. The remote system, however, times out because it did not
receive the message.
 
2) About one sixth of all the packets I receive have an FCS-error.
 
3) Even though a remote system manages to establish a connection via SMTP, no
data flows across the line for lengthy periods.
 
4) I sometimes get an error message "Corrupt Control Block" when I do a
netstat.
 
5) FTP-ing is incredibly slow. I can usually get about 8-10K of data in. After
that, the connection just sits there. Eventually the remote hosts times out
and breaks the connection.
 
6) Telnet-ing is also slow. I can connect without any problem. However, the
screens are updated only very slowly; it usually transfers only very small
protions of the screen at a time, after which it sits for a while doing
nothing.
 
About the way the system is configured:
 
1) The computer is (serially via a Hayes Optima 28.8 Smartmodem connecting at
14.4) connected to an internet-provider. The connection is made using the
PPP-software that comes with UnixWare.
 
2) Aside from adding 2 Device-entries, 1 Systems-entry, 2 Host-entries and 1
PPP-entry, I have not altered the default config.
 
3) The PPP-paramters I have set are: "mru=1500 accm=000a0000 protcomp accomp
VJ". Both the mru and the van Jacobson compression are supported by our
provider.
 
Any help would be greatly appreciated. Please reply to pdl@intergroup.com, but
since I can't be all that sure that it will reach me beacuse of our problems,
please CC: this newsgroup
 
Peter Lange

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 05:50:29 GMT
From:      atm@cse.iitb.ernet.in (Amit Tilak Mehta)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Info

Ann Toh Hwee Choo (anntoh@gallery.ncb.gov.sg) wrote:

: Just wondering if anyone can provide me with a good ftp source for info.
: concerning TCP/IP stuffs. Can get here and there but all seem to be pretty
: loose info.
 
: Thanks in advance.

Try "nic.ddn.nil". It contains a whole lot of rfc and Internet Drafts
on TCP/IP.

Amit.
(amit@kedar.ee.iitb.ernet.in)

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 94 07:57:38 GMT
From:      jim@grimaldi.rutgers.edu (Jim Martin)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast IP

hlg9696@tamsun.tamu.edu (Han Lin Goh) writes:

>Looking for public domain or commercial DOS/Windows TCP/IP packages that
>implement multicast IP. Various SUN platforms already have that support but
>what about PCs?

	You might want to check out my IP Multicast extensions to
WATTCP. They can be retrieved via anonymous FTP from
ftp-ns.rutgers.edu in /pub/msdos/wattcp as mcast.zip (or was it
ipmulti.zip? I can't remember.) If you're looking for a commercial
implementation, check out the latest and greatest development kit from
FTP Inc.
							Jim

-- 
	Jim Martin			Internet: jim@noc.rutgers.edu
	Network Services		UUCP: {backbone}!rutgers!jim
	Rutgers University		Phone: (908) 932-3719

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 16:26:42 -0500
From:      phoff@panix.com (Phil Hoff)
To:        comp.protocols.tcp-ip
Subject:   traceroute for non-root user

Is there a version of traceroute to run on Sunos 4.1.3 where the
user does not have to be root? I noticed that on Next traceroute
has a permissions of 4755 and any user can run it. However on our
Suns only root can run it.


-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 09:41:28 +0000
From:      elatar@comptech.demon.co.uk (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

ian@unipalm.co.uk (Ian Phillipps) writes:

> 
> The SLIP overhead is minimal. With Van Jacobsen compression, it's
> negative!
> 

Is there actuallu any point in using a compression protocol with modern
modems?. V42bis seems to do a very good job on it's own. I ask this because
I am in the process of implementing a TCP/IP system for use over telephone
lines via modem. Have been looking at both SLIP and PPP. Have been told that
PPP is better, though I can't see why - it just seems to give more overhead
without any apparrent gain when used to carry a single protocol only, ie IP.

Adam

+------------------------------------+
|  email: adam@comptech.demon.co.uk  |
+------------------------------------+


-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 09:46:46 GMT
From:      lvegasae@donald.ensem.u-nancy.fr (Luis VEGA)
To:        comp.protocols.tcp-ip
Subject:   Re: FAQ Requested

In article <2ktv6c$l3f@hpchase.rose.hp.com>, mbeebe@repo.rose.hp.com (Mike Beebe) writes:
|>    If there is an FAQ for this group, I'd like to be e-mailed a copy.
|> 
|> --
|> "The difference between humans and animals is that you can pet 98% of
|>  an animal and still pull a G rating."
|> 
|> 					-- Overheard on FurryMUCK
|> 

I'd like to be e-mailed a copy too.

--
Luis V.

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Wed,  2 Mar 94 20:02:09 PST
From:      jalalsa@cup.portal.com (Sohail Ahmed Jalal)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   SEARCC COMPUTER CONFERENCE...CALL FOR PAPERS

----------------------------------------------------------------------
                     SEARCC COMPUTER CONFERENCE
----------------------------------------------------------------------
                    Karachi, November 27-30, 1994
                        ** Call for Papers **
                   ** Invitation to  Delegates **
----------------------------------------------------------------------
SEARCC '93 at Hong Kong in October 1993 attracted a large number of
IT Industry Leaders. Some of the leaders are Philippe Kahn, CEO Borland
International Inc., Dr Alan Ashton, CEO WordPerfect Corporation,
Umang Gupta, CEO Gupta Technology, Patricia Seybold, CEO Patricia Seybold
Group, Professor Dr. Henning Kagermann, Member Executive Board SAP AG.,
Professor Charles Kao, Vice Chancellor, Chinese University Hong Kong,
Dr. Gene Amdahl, President and Chairman Andor International.
  
SEARCC '94 similarly would be a major IT event.
Papers for this conference, projecting the following areas are solicited:
  
o   Software Development Methodologies and tools
o   Operating Systems and Operating Environments
o   Application of IT in various fields
o   Distributed Computing
o   Artificial Intelligence
o   Open Systems
o   Emerging Technologies
  
MANAGEMENT
o   National/ Regional IT policies
o   Academic/Professional Standards and Certification
o   Right Sizing
o   Quality Assurance and Total Quality Management
o   Cost Benefit Measurement of IT
o   Out Sourcing
o   Software Productivity Metrics
o   IT - A Tool for Competitive Edge
  
AUTHORS: Please submit papers, typewritten in English by April 15, 1994,
to the Conference Secretariat.
  
DELEGATES: Contact Conference Secretariat for details.
  
SEARCC '94 Conference Secretariat: Office No. 5 Sasi Arcade,
    Main Clifton Road, Karachi  75600, Pakistan.
    Phone No. (92-21) 5871819   Fax No. (92-21) 5681361, 571030.
  
  
  
  
  
  
-------------------------------------------
SEARCC Represents World's Hottest Economies
-------------------------------------------
Australia                   Pakistan
Canada                      Philippines
Hong Kong                   Singapore
India                       South Korea
Indonesia                   Srilanka
Malaysia                    Taiwan
New Zealand                 Thailand
-------------------------------------------
Parallel Events
-------------------------------------------
SEARCC EXPO'94
Theme:        Emerging Information Technologies
Exhibitors:   Book your stalls now to display your products in the
              fastest developing IT market.
Software
Competition:  For Students under 17 years.
-------------------------------------------
Organized by:
          South East Asia Regional Computer Confederation
-------------------------------------------
-------------------------------------------
Hosted by:
          The Computer Society of Pakistan
-------------------------------------------
-------------------------------------------
Sponsors:
          AST Computers
          AT&T/NCR
          Automated Business Systems
          IBM Pakistan
          Pak Arab Refinery Limited
-------------------------------------------
  
  
  
 

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 13:24:29 GMT
From:      kill@atik.no (Kim Lilliestierna)
To:        comp.protocols.tcp-ip
Subject:   SLIP on SUN Help

setup: SUN with SunOS 4.1.2 with the slip-4.0 package.
       PC with Trumpet V1.0a winsock ( internal slip )

Problem: telnet, ping etc works only to the machine where i "sliplogin".

any good sugestions ?

Kim Lilliestierna
kill@teknologi.agderforskning.no

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Mar 1994 18:28:51
From:      fks@ftp.com  (Frances K. Selkirk)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <2l0ctv$8r9@navaho.cc.bellcore.com> kenton@navaho.cc.bellcore.com (gidewall,kenton c) writes:

> My company is designing a system that is running TCP/IP.  We had planned
> on using SLIP or PPP (pretty much decided on PPP) for the asynchronous
> connections via 14.4 or 28.8 modems.  One of our clients saw our design
> and said that he doesn't want to be forced to use PPP or SLIP and wants
> to run straight TCP/IP across the phone line.

Well, whatever the physical layer is (SLIP, Ethernet, Token Ring) you
need some sort of packet encapsulation method for the TCP/IP data. The
SLIP packet structure is as simple as you can get, and PPP isn't
overly complex. 

Regards,

--
Frances K. Selkirk                                        fks@ftp.com
FTP Software, Inc.        Technical Support            (800) 382-4FTP
---------------------------------------------------------------------
Get our support newsletter from       | FTP support - support@ftp.com
ftp.ftp.com or our BBS (508-659-6240) | FTP sales   -    info@ftp.com


-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 22:48:05 -0500
From:      alek@ionews.io.org (Aleksandar Matijaca)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP with OS2?

In article <skolos.762318542@sfu.ca>,
Chester <skolos@gemini.csil.sfu.ca> wrote:
>HI
>
>I am currently using winsock.dll with windows to connect to a unix host,
>but I would like to run a native OS2 app to connect. Could someone point 
>out a good program that I can use or some where to start looking?
>
>THANKS
>
>--CHESTER
>aka CHET SKOLOS
>    skolos@sfu.ca
>


I believe that IBM's own TCP/IP for OS/2 offers a slip option.  However,
the windows programs would not be able to make use of the IBM's own TCP/IP
for OS/2.......

Alex. Matijaca
alek@io.org
Toronto, Ontario Canada



-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 23:10:33 -0500
From:      alek@ionews.io.org (Aleksandar Matijaca)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: LAN Workplace for DOS & NFS Client for LAN Workplace for DOS

In article <systex.96.2D70E60D@hookup.net>,
Lawrence Levin <systex@hookup.net> wrote:
>We are looking for a complete set of LAN (tcp/ip) software for our clients.  
>Having worked extensively with all of the shareware/freeware/PD stuff around, 
>I am more than pleased with it.  Unfortunately there doesn't appear to be a 
>comparable NFS product available to fulfill a key need.  We tried the new AIR 
>suite of LAN software.  Costs alot and doesn't even work.  I've been reading a 
>lot of neg. info on alt.winsock re: Chameleon.  Sounds like another mess for 
>lots of money.  Novell offers their LAN Workplace for DOS software which has 
>everything.  They also know how to sell & support the market.  Any feedback 
>from actual experience would be appreciated.
>Our environments are typically a SCO server with both terminals & PC's. The PC 
>users need _good_ terminal emulation software and also a simple NFS connection 
>so that they can access DOS data/programs on the server.  Performance must be 
>as good as Trumpet/WINSOCK, WS_FTP ... well you get the picture.  Any help 
>would be appreciated.
>TIA
>
>Lawrence Levin

There are some good products that come to mind.

My choices in alphabetic order :

	A) Beame & Whiteside, reasonable performance at a reasonable cost.
	Doesn't do anything superbly (except INT14 support which is
	outstanding), but it does not do anything badly either.

	B) Chameleon, expensive, the NFS option costs even more, WINDOWS ONLY.
	No TCP/IP services to your DOS applications, not even to the DOS
	BOXES under windows.

	C) PC-TCP from FTP.  Expensive, great product, good support, and the
	dubious award of the MOST MISERABLE INSTALLATION PROCEDURE EVER FOR
	ANY PIECE OF SOFTWARE CREATED BY HUMANS.  NFS syntax needs improvement.

	D) LAN workplace for DOS, Look under Beame & Whiteside, they OEM the
	stack from them :->

	E) PIPER/IP, Blazingly fast, least amount of memory (6k of lowmem),
	dos only, but they supply winsock.dll and a PCTCPAPI.DLL.  NFS is good
	and they are fully compatible with PC-TCP - for Sybase and ORACLE
	support.  No mailer....  COMPLETE BSD TCP/IP COMPILED FOR PC!!!
	you even get commands like ifconfig, netstat and other TCP/IP
	commands that you get on a UNIX box..  My rumour mill tells me that
	these are some ex-FTP programmers who started their own company..

My choice is PIPER/IP with a close second by Beame & Whiteside.

Alex. Matijaca
alek@io.org
Toronto, Ontario Canada



-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 14:50:49 GMT
From:      aboba@netcom.com (Bernard Aboba)
To:        comp.protocols.tcp-ip
Subject:   FAQs?

In response to the request for FAQs, I would note that a FAQ on use of  
TCP/IP on the IBM PC is available from:

file://netcom1.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip. 


This is updated monthly. 

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 15:06:16 GMT
From:      jmerge@atl.com (Jacque Mergens)
To:        comp.protocols.tcp-ip
Subject:   FAQ sheet

Can anyone send me a FAQ sheet for this news group?  My company only has 
a limited news feed.

	Jacque

	jmerge@atl.com

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 15:21:41 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Is there an OSPF RFC ?

RFC 1247

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 15:43:11 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip
Subject:   Re: Hardware fault on Wellfleet BLN

In article <762312907snx@legion.demon.co.uk>, andy@legion.demon.co.uk (Andy Leigh) writes:
 Hi,

 I've also posted this in comp.sys.wellfleet, but I thought I'd try here
 as well. It seems our Wellfleet BLN has developed a fault, and it won't
 boot up properly. I haven't seen the fault (I got rung at home) but I've
 got Usenet access from home hence the post.
...
 It seems the controller card (the one with the console port) is pulling
 down the rest of the system. Without it, of course the box won't boot,
 but with it the LED's seem dim.
...
<<<<

Whenever we had a SMRL or SMRF problem we had to replace them. You will
have to correllate the LED boot and post sequence with the info in the manual
to determine if it is actually the SMRL. Good idea to keep a set of WF
manuals at home, then you can ask virtually anyone to "read off" the LED
sequence over the phone if someone with enough expertise is not available
on site. Also, a dialup connection into WFs can be very helpful. We have
dialup into a terminal server which connects to about 50 BCNs, and BLNs.
We also have SLIP/PPP connections to run sitemanager remotely. The performance
for sitemanager over V.32bis is very reasonable and will be better still
when we move to V.34. As a matter of fact I am running xrn over V.32bis at
this time.

If you have a WF software, e.g.  OSPF, filters, sitemanager etc etc problem
do not hesitate to drop me a line.


-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 15:56:55 GMT
From:      dennis@cauchy.math.nwu.edu (Dennis Director)
To:        comp.protocols.tcp-ip
Subject:   Linux SLIP experience needed - help many people!

(This was previously posted to comp.os.linux.help
which has become almost useless from high volume
posting.)

Please solve many people's DIP/SLIP problems.

I have seen many, many postings regarding DIP/SLIP not working,
(with Linux)
especially when trying to upgrade to new versions.
I have had this problem myself, and went back to
a previous CDROM distributed system, which by the way,
although short a couple of features that I need,
is an impressively complete TCP/IP package (Thankyou).

Could someone please post version numbers for the following,
that are known to work together and make a working system? :

Linux kernel (something in the 99.15 I guess) patch level
libc version
NET-2D (net utilities) version
DIP version
route version
maybe Mosaic as well

and of course, ftp sites for each if possible!

I think a set of version numbers that are known to work together
would help a lot of people.  FAQs don't seem to present
this information or don't keep up the new kernels.

Thanks from all of us.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 16:10:36 GMT
From:      rturner@qms.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Solaris 2.2 / 802.3 TCP/IP


How do I configure Solaris 2.2 to use 802.2/802 SNAP frames for TCP/IP ?

Thanks!


---


/* Rt */




-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 16:12:12 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Load balancing on multiple paths

In article <2kobdi$d51@cronkite.cisco.com>, tli@cisco.com (Tony Li) writes:
 In article <id.4Q971.022@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:
...
JI> I am trying to find a set of HW configuration and protocols so that
JI> no single point of failure between the LANs causes the TCP connection
JI> to go down, not even momentarily and also take advantage of load
JI> balancing on the multiple paths. Can both these objectives be met ?
JI> Can I meet the first objective without meeting the second objective ?

TI> That depends what you mean by "go down". If you mean that you will not
TI> drop packets, no, there's no way to guarantee that. All routing protocols
TI> (so far ;-) have a significant convergence time. So you would at least see
TI> retransmissions.

TI> If you're trying to avoid breaking the TCP connection, then any routing
TI> protocol that converges within about 30s will work. That leaves OSPF and
TI> ISIS (and soon EIGRP). You could also get IGRP to do this, using a "highly
TI> non-standard configuration".

TI> Load balancing can be done in any case and is orthogonal to the convergence
TI> time.
...
<<<

If you want unbroken TCP connections then just a rapidly convergent routing
protocol may not be sufficient. The problem gets tricky if you have end-points
with multiple interfaces. I cannot get into details, but we had to add ES-IS
(OSPF "listeners") and virtual interfaces to end-systems to keep TCP connections
alive. The virtual interfaces are needed to keep a TCP connection alive even
when one of the real interfaces fails, and the OSPF "listener" is used for
dead-router detection and router discovery. You can use one-way default-route
broadcast to achieve the same goals.

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 17:21:35 GMT
From:      matt@picard.fnal.gov (Matt MacPherson)
To:        comp.protocols.tcp-ip
Subject:   68360 TCP/IP

I need a real-time kernel and TCP/IP implementation for the 68360. 
I've priced several commercial solutions only to find extremely high
prices.  Is there any source code available anywhere that I can use? 
Perhaps there is something for the 68332 that can be modified?  Perhaps
I could run a small free UNIX variant that would provide TCP/IP?

Basically I have a 68360 with built in ethernet capability and am now
looking for TCP/IP software to run on it in an embedded system that
does some A/D and data collection.

Any help or direction in this area would be greatly appreciated.  I'd
like to explore free software before commercial.

Matt MacPherson
Fermilab
matt@picard.fnal.gov

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 17:57:12 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: Solaris 2.3 tcp problems

ddj@gradient.gradient.com (Dave Johnson) writes:

>First, Solaris 2.3 uses the range of 32768-65535 for port
>numbers when you bind a socket with an unspecified port.
>This caused problems with SMTP to at least one network
>once the system has been up a while.  The attempts to
>deliver mail would all fail with a timeout:
 
>  Mar  1 16:50:09 gradient sendmail[24797]: AA02501: to=someone@austin.ibm.com,
>	delay=1+01:40:25, stat=Deferred: Host netmail.austin.ibm.com is down

This doesn't seem to be a Solaris problem, rather a AIX problem.

>Second, I'm seeing problems with SMTP and FTP specifically with
>the host crimelab.crimelab.com.  Again the problems occur only
>with the Solaris2.3 machine, but not with for example SunOS 4.1.3.
>What I see is mail from crimelab.com will be delivered if the message
>is tiny (5 lines maybe), but the connection times out otherwise.

I've been seeing teh same messages.  It seems that crimelab is another
Solaris 2.x machine, and I think it's 2.2 or earlier, unless they've
messed with the login program.

Casper

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 18:01:19 GMT
From:      jbotz@mtholyoke.edu (Jurgen Botz)
To:        comp.protocols.tcp-ip
Subject:   Multicast for Ultrix 4.3a?

Does the multicast software for Ultrix 4.2a on gregorio.stanford.edu work
with later releases of Ultrix (specifically, 4.3a), or has someone ported
this stuff to later Ultrix?  Thanks...

-- 
Jurgen Botz, jbotz@mtholyoke.edu | ``Accountability is the price of openness''
South Hadley, MA, USA            | - Daniel Geer


-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 18:59:50 GMT
From:      carlos@marin.cc.ca.us (Carlos Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: How does one apply for a tcp/ip address ?

Dan Angst (dangst@csn.org) wrote:
: SUNBORN@DELPHI.COM (sunborn@news.delphi.com) wrote:
: : If anyone could either email me or fax me at 203-549-5039 with information
: : as to how to apply for a tcp/ip address , it would be apprecaited.  
 
: : James McGovern
: : Command Systems
 
: Administered by the Network Informatin Center (NIC) phone 800.365.3642 or
: 703.802.4535...e-mail nic@nic.ddn.mil.
The correct number is: (800)444-4345

8^)-carlos

-- 
#	Carlos Robinson				College of Marin           #
#	Science Computer Center			Kentfield, CA  94904       #
#	Ph: (415) 485-9540			carlos@marin.cc.ca.us	   # 
#       Email: ...!{uunet,ames,decwrl}!marin.cc.ca.us!carlos               # 

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 20:08:00 GMT
From:      dswartz@pugsley.osf.org (Dan Swartzendruber)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <6S1P7Ij024n@comptech.demon.co.uk>, elatar@comptech.demon.co.uk (Adam Goodfellow) writes:
> ian@unipalm.co.uk (Ian Phillipps) writes:
> 
> > 
> > The SLIP overhead is minimal. With Van Jacobsen compression, it's
> > negative!
> > 
> 
> Is there actuallu any point in using a compression protocol with modern
> modems?. V42bis seems to do a very good job on it's own. I ask this because

You're confusing compression types.  VJ header compression doesn't refer to
actual byte-by-byte data compression.  It is more correctly an optimization
wherein the software doesn't need to send the entire IP header with each
packet.

> I am in the process of implementing a TCP/IP system for use over telephone
> lines via modem. Have been looking at both SLIP and PPP. Have been told that
> PPP is better, though I can't see why - it just seems to give more overhead
> without any apparrent gain when used to carry a single protocol only, ie IP.
> 
> Adam
> 
> +------------------------------------+
> |  email: adam@comptech.demon.co.uk  |
> +------------------------------------+
> 
 
-- 

#include <std_disclaimer.h>

Dan S.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 20:50:54 GMT
From:      sybesma@unirsvl.rsvl.unisys.com (Eric Sybesma)
To:        comp.protocols.tcp-ip
Subject:   all-one-bits versus all-zero-bits in broadcasting

Hi,
	Curious about broadcasting to networks.  What is the
difference between specifying, say a class C address
192.61.236.255 versus
192.61.236.0

	In Xenix, you can set a parameter on the netload call (-u)
that converts outgoing broadcast messages with X.X.X.0 to
X.X.X.255, or so I think.  What is the difference between one of
the other?

es
.
-- 
Eric Sybesma          |_sybesma@unirsvl.rsvl.unisys.com_|_(612) 635-3380_|
Unisys Corporation    |"Those who live in glass houses shouldn't."       | 
Roseville, MN 55113   | DISCLAIMER: All included Disclaimers are invalid.|

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 21:31:47 GMT
From:      Tom Sheppard <toms@bnr.ca>
To:        comp.protocols.tcp-ip
Subject:   Re: How do multi-homed hosts choose the interface?

In article <2kl3rr$21o@sophia.inria.fr> Christian Huitema,
huitema@mitsou.inria.fr writes:

> Last but not least: if you don't know how to chose, picking one at random is
> usually better than always picking the same one!

In RFC1122, section 3.3.4.3, pg.64 (Oct 1989) says:

"In the future, there may be a defined way for a
multihomed host to ask the gateways on all connected
networks for advice about the best network to use for a
given destination."

It's been four years.  Is anyone aware of the definitive way?

My problem is in picking one of three source addresses to connect to a
remote host on another network.  I can't afford the CPU cycles to run
an embedded gateway function so I'm trying to keep the multihomed
host just a host.  Since the destination is a remote host I know there
must be a gateway out there.  This gateway MAY have knowledge of the
best route.  Ideally, I would like to tell the gateway of the subnets
associated with my three interfaces, the destination IP address and have
the gateway return to me its hint on the best route.  This keeps my host
very simple and puts the burden for routing where it belongs, in the
gateway.

The local application probably doesn't even want to be bothered with 
selecting the TOS, so I may get no hints at all.  If the interfaces I use
are all equal, then maybe I can select an interface which has the fewest
number of connections being routed through it.  Of course this is no measure
of traffic rate, so maybe I should look at that too.  But this interface is
actually an I/O processor serving other devices too, so then I should look at
CPU consumption between the processors on those interfaces.  But CPU occupancy
is probably just as transient a measurement as packet rate.

Geez, this is complex.  Any hints appreciated.

Tom Sheppard

P.S.  Is there a working group looking at this?
      Is there any node on the Internet where I can do a full text search of
      all the RFCs, drafts, working group minutes, etc.?

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 22:00:24 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

Ian Phillipps (ian@unipalm.co.uk) wrote:

: Hmmm..
: I've certainly no idea what he means, and I don't think he does, either.
: SLIP stands for Serial Line Internet Protocol. All it is is a couple of
: escaped sequences that tell you where a packet begins. Pretty minimal.
 
: Ethernet, etc., are packet-oriented by their nature, so can pass IP
: easily. A serial line isn't, and needs a little help. SLIP is about as
: little help as you can give it. Without an end-of-packet marker, one
: error and you're sunk.

This lack of framing may make SLIP unreliable on noisy lines.

: >Can someone tell me why we don't use straight TCP/IP over phone lines
: >and why we need/should use SLIP or PPP?  Any pointers to documentation 
: >on the subject would be helpful, as then it wouldn't just be me telling
: >him, I could show him.
 
: The SLIP overhead is minimal. With Van Jacobsen compression, it's
: negative!

It is difficult to think of anything more minimal. 

Though over a telephone line (as opposed to a direct connection) something
slightly more sophisticated. e.g. with frame header and CRC; might be more
practical.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 22:03:44 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

Adam Goodfellow (elatar@comptech.demon.co.uk) wrote:
: ian@unipalm.co.uk (Ian Phillipps) writes:
 
: > 
: > The SLIP overhead is minimal. With Van Jacobsen compression, it's
: > negative!
: > 
 
: Is there actuallu any point in using a compression protocol with modern
: modems?. V42bis seems to do a very good job on it's own. I ask this because

There is the problem that using compression twice on data can actually result
in increasing the size. It depends on the interaction between compression
algorithms.

: I am in the process of implementing a TCP/IP system for use over telephone
: lines via modem. Have been looking at both SLIP and PPP. Have been told that
: PPP is better, though I can't see why - it just seems to give more overhead
: without any apparrent gain when used to carry a single protocol only, ie IP.

Framing, better error detection.

With slip you have no checksum on your frames.

Thus you are relying on your IP and TCP checksums.

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 22:47:22 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: ? PC-based TCP/IP Decode Analyzer?

In article <762544197snz@ichthya.demon.co.uk>,
Alistair Bell <alistair@ichthya.demon.co.uk> wrote:
>In article <2kstrf$6rt@liberator.et.tudelft.nl> ling@dutepp9.et.tudelft.nl writes:
 
>>Inexpensive: Novell's LANalyzer might be what you're looking for.
 
>Err... LANalyzer is very good (we use it) but it certainly isn't inexpensive
>(it's about GBP 700 ($1000 to you Americans) here) and its TCP/IP decodes
>aren't wonderful (e.g. it can't cope with NFS beyond the UDP level). However,
>it's VERY good for such things as IPX and NetWare (unsurprisingly)

Depends what you mean by inexpensive, of course... Compare that price
with any of the dedicated sniffer boxes, and it looks inexpensive.
In the same market is LANWatch from FTP software (details by email
but again unsurprisingly it majors in TCP/IP, and does less detailed
analysis of IPX).

For something rather cheaper, look at ETHLOAD and its relatives,
available from your favourite PC archive site. It may be called
ETHLD104.ZIP. It concentrates on monitoring traffic levels, but can do
some individual packet inspection, and has rudimentary packet
filtering.

Ian
-- 
Ian Phillipps. Tech support manager, Unipalm. News admin, pipex. Internic: IP4
"... we had no interoperability goal when designing ****.  Therefore the product
interoperates with itself." [A quote from a developer of a TCP/IP product.]
Name omitted to protect the guilty.

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 23:08:06 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <CM25A9.5zn@aston.ac.uk>,
Mark Evans <evansmp@mb48026.aston.ac.uk> wrote:
>Adam Goodfellow (elatar@comptech.demon.co.uk) wrote:
>: ian@unipalm.co.uk (Ian Phillipps) writes:
 
>: > The SLIP overhead is minimal. With Van Jacobsen compression, it's
>: > negative!
>: Is there actuallu any point in using a compression protocol with modern
>: modems?. V42bis seems to do a very good job on it's own. I ask this because
>There is the problem that using compression twice on data can actually result
>in increasing the size. It depends on the interaction between compression
>algorithms.

As another posting in this thread points out, VJ compression is doing
something rather different to ordinary data compression of the sort
you'll find discussed on comp.compression. It is very highly tuned to
TCP/IP (only TCP, not UDP) and reduces the normal header size down to 3
bytes.  This is a *big* win for telnet (etc.) sessions over SLIP.

The data is uncompressed, and will yield to V.42bis (or other)
compression. Read RFC 1144.

Ian
-- 
Ian Phillipps. Tech support manager, Unipalm. News admin, pipex. Internic: IP4
Many system managers claim that holes in an NNTP stream are more valuable than
the data. Van Jacobson, RFC 1144


-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 23:43:24 GMT
From:      mitton@dave.lkg.dec.com (Dave Mitton)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PCNFS over Token Ring (Source Route Bridging)


In article <1994Feb22.222433.384@cyantic.com>, mark@cyantic.com (Mark T. Dornfeld) writes:
<Data Communications just published a review of TCP/IP products for MS-DOS
<and SunSelect's PCNFS came up pretty short in the review.  The review
<concentrated on TCP/IP over Token Ring.

<Apparently all of the products set the source route bridge flag in the MAC
<header as a default.  This makes IP routing quite perilous if not impossible
<in many environments.  PC-NFS was the only product that did not allow the
<default to be changed so that the flag was not set.

<Mark T. Dornfeld, CYANTIC Systems             

	Personally I was puzzled by his claimed problem.  

IMHO (warning: I'm not an IP expert) any TCP/IP capable brouter attached to a
Token Ring should NOT be blindly bridging ARP frames just because they have a
SR explorer in them. (or any IP related frame)   If it's a true IP router, it
should perform all functions of a real router, inspite of any other bridging
behavior it knows.

	So I think his brouter is brain dead.  
(or he misexplained the problem)

	Typical Token Ring implementations will have many SR bridged rings
and SR explorers are a (ugly) necessity of life. 

-- 
Dave Mitton,					mitton@dave.enet.dec.com
Token Ring Program, Networks Engineering, Digital Equipment Corp.


-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 23:45:12 GMT
From:      john@lemon (John Gottschalk)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted : Statistics on X.25 and TCP/IP

Hiren Chandiramani (hiren@li.loral.com) wrote:

: Hi,
: Can anyone tell me where I can statistics on the number of nets/users using
: X.25 ? I would also like to find the same information on TCP/IP. 


I doubt that you can get accurate figures, but if you do then I am interested 
in having a copy. 

You would have to go to telecommunications companies to get statistics on the
number of X.25 users, and then they may only be able to tell you the number
of companies subscribed to X.25 or the number of X.25 lines, which is not the
same as the number of machines running programs that access it
(for example, we have many machines on TCP/IP, but the number of X.25 lines 
is an order of magnitude less - less is needed as the software that runs 
over X.25 is of a client/server type where only the server need run on 
a machine with X.25). Therefore there is an order of magnitude
less X.25 address compared to IP addresses, but this does not
necessarily state anything about the relative use of X.25 compared to
TCP/IP.

The relative popularity of X.25 varies greatly between countries. I hear
that in the US X.25 did not become as popular as in Europe or Australia.
Some say the reason is due to the breakdown of the US telecommunications
companies into regions meant that it was difficult for the various companies
to agree to interoperate to provide a nation-wide service. In Europe and 
Australia the competing telecommunications companies operate nation-wide and 
so can provide a nation-wide service. I read an article recently that stated 
that in Asia X.25 is by far the most popular form of data communications,
with TCP/IP WANs being very rare. 

To make things more complex, in some countries the TCP/IP network is
run over an X.25 backbone (such as New Zealand and the UK although I hear that
the UK is now setting up a TCP/IP network that does not run over X.25).
To make matters even more complex again, ISDN and X.25 are sometimes
considered as interchangeable when a user wants to run a connection-oriented
digital data communications network, with the telecommunications company
providing ISDN to X.25 routing. Therefore rather than just counting the
number of X.25 users it is perhaps wise to count the number of 
ISDN users as well. But then again, there are some places that run a TCP/IP 
network over ISDN.



					-- regards, John Gottschalk

===================================================================== 
John Gottschalk, 				john@citr.uq.oz.au
Project Manager, CiTR,				+61 7 365 4321 (phone)
Gehrmann Building,                     		+61 7 365 4399 (fax)
The University of Queensland, 4072,
Brisbane, Queensland, Australia,
===================================================================== 


-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1994 09:35:35 -0500
From:      martinw@epenviron.eapi.com (Martin Walker)
To:        comp.os.ms-windows.apps,comp.os.ms-windows.setup,comp.windows.ms,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: selective appearance of network group under windows

welsbyp@qdpii.ind.dpi.qld.gov.au (Peter Welsby) writes:

>In article <2kq55k$675@agate.berkeley.edu> ucbked@athena (Earl H Kinmonth) writes:
>>From: ucbked@athena (Earl H Kinmonth)
>>Subject: selective appearance of network group under windows
>>Date: 27 Feb 1994 12:54:12 GMT
 
>>I run WINQVT using Novell odi drivers under Windoze 3.1.  I offer a
>>bootup menu that allows Windoze with and without the network drivers
 
>>Is there an elegant (simple) way of causing the network.grp file to
>>appear only when the proper drivers have been loaded?
 
>Not to my knowledge.  You could, of course, write a program for us both...


>Sounds downright disasterous to me.  Make a change to one setup, and lose it 
>for all others...

you could use somthing like mks tools sed or som such to automatically
comment out the offending line for non-network windows loading (or
uncomment it for net loads), any other mods made by the user will remain
intact (assuming save on exit checked).
-- 
=========================================================================
Martin C. Walker                                         martinw@eapi.com
Project Lead                                         Voice (513) 629-2517
Eagle-Picher Industries Inc.                           Fax (513) 629-2449

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1994 09:37:15 -0500
From:      martinw@epenviron.eapi.com (Martin Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Avoid/Recover from "Bus Error"

wchen@netcom.com (Wen Chen) writes:

> 
>I am developing a client/server system that relies on socket communication on 
>TCP/IP.  The processes run great, most of the time, except once a while they 
>get themselves into a "Bus Error".  The client sides typically fail after they 
>lose their connection.
 
>My questions: is this problem preventable?  If not, how can the client 
>process recover from the connection failure, instead of exiting the program?

In my experience bus errors occur when you try to do a word operation on
an address that is not word aligned (or double-word op on a non-double
word address).  It sounds like this is a problem that needs to be fixed
not worked around ;-(
-- 
=========================================================================
Martin C. Walker                                         martinw@eapi.com
Project Lead                                         Voice (513) 629-2517
Eagle-Picher Industries Inc.                           Fax (513) 629-2449

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 02:21:04 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?

heading@signal.dra.hmg.gb (Anthony Heading) writes:

>  I want the two routing machines to use the FDDI network to
> talk to each other, but they steadfastly refuse to use anything
> but the ethernet.
 
> This makes me suspect that multiple A records
> are used by trying each address in the gethostbyjingo() structure
> in turn, but there seems to be no way of making the DNS server
> impose order onto those addresses.

Isn't this what the "sortlist" directive in named.boot is supposed to do?
Try sticking it on your nameserver.

The disadvantage to sortlist is that if your ethernet has routers to nets
other than the fddi net, then traffic to one of the multihomed systems may
go outside->router->ether->one-fddi-host->fddi->other-fddi-host, even
though the other-fddi-host has a leg on the ethernet.  This depends on
which multihomed host is preferred as a route to the fddi.

-- 
Tom Fitzgerald   Wang Labs   Lowell MA, USA   1-508-967-5278   fitz@wang.com
Pardon me, I'm lost, can you direct me to the information superhighway?

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 02:46:29 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

phoff@panix.com (Phil Hoff) writes:

> Is there a version of traceroute to run on Sunos 4.1.3 where the
> user does not have to be root? I noticed that on Next traceroute
> has a permissions of 4755 and any user can run it. However on our
> Suns only root can run it.

I use this program as a suid wrapper around traceroute on a SysV thing.
You may want to mess with the permitted options; this filters most out
because they could conceivably be used to mess up a net.  You may also need
to adjust the PATH, the pathname of the traceroute executable, and the
program's name for itself.


#include <stdio.h>

/* Max # of options plus # of options that take args plus 1 each for argv[0],
   hostname, terminating null and good luck */
#define MAXARGS		10

char *usagemsg =
"usage: trace [-options] [hostname]
   -n\t\tNumeric output - don't map IP addresses to hostnames
   -v\t\tVerbose output
   -w wait\tSet time to wait for responses; default 3 seconds
   -q count\tSet number of probe attempts for each hop; default 3
";

char *env [] = {
	"PATH=/etc",
	"IFS= \t\n",
	NULL
};

usage ()
{
	fprintf (stderr, usagemsg);
	exit (1);
}

main (argc, argv)
	char *argv [];
{
	char *args [MAXARGS];
	int opt, ap = 1;
	extern char *optarg;
	extern int optind;

	args [0] = "traceroute";
	while ((opt = getopt (argc, argv, "nvw:q:")) != -1) {
		if (ap >= MAXARGS - 2)
			usage ();
		switch (opt) {
		case 'n':  args [ap++] = "-n";				break;
		case 'v':  args [ap++] = "-v";				break;
		case 'w':  args [ap++] = "-w";	args [ap++] = optarg;	break;
		case 'q':  args [ap++] = "-q";	args [ap++] = optarg;	break;
		default:   usage ();
		}
	}
	if (optind != argc - 1)
		usage ();
	args [ap++] = argv [optind];
	args [ap] = NULL;
	execve ("/etc/traceroute", args, env);
	fprintf (stderr, "trace: exec (traceroute) failed\n");
	exit (1);
}


-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 05:22:21 GMT
From:      sybesma@unirsvl.rsvl.unisys.com (Eric Sybesma)
To:        comp.protocols.tcp-ip
Subject:   internet address forms

Hope this isn't in the faq....

what are the different forms an internet (CLASS A B C D)
can take.  I know

a.b.c.d. x < 256 is one, but is
a.b b< 256*256*256 also valid..?


What is a portable way (Unix and Xenix particularly )  to read
from the host file and tell if it is a good address or not...

does anyone have a gethostbyname.c that I can look at?

Thanks a lot

es

-- 
Eric Sybesma          |_sybesma@unirsvl.rsvl.unisys.com_|_(612) 635-3380_|
Unisys Corporation    |"Those who live in glass houses shouldn't."       | 
Roseville, MN 55113   | DISCLAIMER: All included Disclaimers are invalid.|

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 07:32:34 GMT
From:      sboden@uia.ac.be (Sven.Boden)
To:        comp.protocols.tcp-ip
Subject:   Where's the Magic???


After having read the article in
   BYTE, February 1994, p. 22-23, "Just Like Magic", by Tom R. Halfhill and
     Andy Reinhardt

I'm looking for more information on the product: Telescript, Magic Cap
and on the company "General Magic" that made them, anything on the same
subject is ok with me. According to the article the company is situated
in Mountain View, CA (but they forgets to mention other details).
So why the fuss?

Some excerpts from the article:

"What PostScript did for cross-platform, device-independent documents,
 Telescript aims to do for cross-platform, network-independent messaging.
 General Magic hopes Telescript will become a lingua franca for
 communications."

"Magic Cap represents General Magic's bid to take GUIs to the next
 conceptual level. While today's environments protect users from many
 details of the hardware and operating system. Magic Cap goes even
 further. For instance, no longer must users understand the differences
 between executable and non-executable files, directories and sub-
 directories, ...
   The new GUI was invented by ex-Apple engineers and General Magic
 cofounders Bill Atkinson and Andy Hertzfeld."

"Telescript, General Magic's communications-oriented programming language,
 lets developers write tools that permit casual users who know nothing
 about programming to create intelligent applications that seek out and
 retrieve information."

"a new GUI that's a radical departure from the Lisa-Macintosh-Windows
 model of the 1980s"

Could this be true?

General Magic is a startup company that counts Apple, AT&T, Matsushita,
Motorola, Philips, Sony, ...
And the product should be appearing 'in the next few months'

---

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 Mar 1994 21:26:35 -0800
From:      ace@tidbits.com (Adam C. Engst)
To:        cwru.ins.general,comp.sys.mac.comm,comp.sys.mac.apps,comp.protocols.tcp-ip
Subject:   Re: Looking for Mac tcp/ip client/servers

In article <yan.1.2D7355DA@biochemistry.bioc.cwru.edu>,
yan@biochemistry.bioc.cwru.edu (Yan Xiang) wrote:

> Hello:
> 
> I am just about to receive a Macintosh and am looking for
> all types of TCP/IP clients/servers/utilities for this new
> machine.
> 

Can I point you at:

ftp://ftp.tidbits.com/pub/tidbits/tisk/mactcp/

which has all of the Macintosh TCP/IP software that I know of? And if
there something that's not there that should be, let me know and I'll
upload it...

cheers ... -Adam

-- 
Adam C. Engst, TidBITS Editor -- ace@tidbits.com -- info@tidbits.com
Author of the Internet Starter Kit for Macintosh -- tisk@tidbits.com

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 94 18:52:13 -0500
From:      harvey@indyvax.iupui.edu (James Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: all-one-bits versus all-zero-bits in broadcasting

In article <CM21wv.InA@unirsvl.rsvl.unisys.com>, sybesma@unirsvl.rsvl.unisys.com (Eric Sybesma) writes:
> Hi,
> 	Curious about broadcasting to networks.  What is the
> difference between specifying, say a class C address
> 192.61.236.255 versus
> 192.61.236.0

The former is a standard form of broadcast address, the latter is not.
See RFC 1122 section 3.3.6.

> 	In Xenix, you can set a parameter on the netload call (-u)
> that converts outgoing broadcast messages with X.X.X.0 to
> X.X.X.255, or so I think.  What is the difference between one of
> the other?

One is standard, the other isn't.  You should use the standard forms of
broadcast addresses if possible.  The feature you are talking about appears
to be there for compatibility purposes.  I wouldn't use it unless I had a
good reason to.  If you don't have 4.2BSD (or derived) hosts or software
on your net you probably don't have to worry about it (with the exception
of making sure hosts use the right one -- as an example, SunOS 4.1.3 was
*still* using the long-obsolete zeros forms as the default).
--
James Harvey   harvey@iupui.edu   IUPUI OIT Technical Support/VMS/Unix/Networks
Disclaimer:  These are my own opinions.  I do not speak for Indiana University.
He who refuses to read history is doomed to repeat it.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1994 09:30:20 +0100
From:      korni@shogun.ncp.sietec.de (Jochen Kornitzky)
To:        comp.protocols.tcp-ip
Subject:   Any intrinsic perfomance limit with IP protocol ?

Hi,

I was told by some 'suits' :-) that IP protocol throuput/performance can be 
increased beyond "any" limit by using highspeed (FDDI and above) wires.
I "know" that there are certain limits in the IP protocol that apply
especially to point to point connections but I need strong arguments.

Any statements for this topic or pointers to literature (FAQ?)
are very much appreciated.

Jochen

BTW: Can someone drop me a short note on the highest FDDI point to point
thruput ?
-- 
       Jochen Kornitzky
SNAIL: Sietec GmbH & Co. OHG        EMAIL:             FON: +49-30-386 28125
       Nonnendammallee 101
       D-13629 Berlin (Germany)     korni@sietec.de    FAX: +49-30-386 28321

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 94 20:14:16 MST
From:      kruckenb%peruvian.cs.utah.edu@cs.utah.edu (Joseph Kruckenberg)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,vmsnet.networks.misc,comp.os.os2.networking,comp.sys.ibm.pc.hardware.networking
Subject:   Info on frame-relay needed ASAP - HELP!!!

I'm doing some research into frame-relay, and I'm having a very
difficult time finding information on it.  I need to find some sources
(magazines, books, or on-line) that explain what frame-relay is, its
capabilities, advantages and limitations, and applications where it
would be economically advantageous.

Please email me with any ideas you have, as soon as possible.  This
report (unfortunately) is due tomorrow and I'm having a very difficult
time getting enough info to write it up.

I have access to most major publications, as well as ftp sites and a
couple of libraries, so any sources you can think of would be great!!

Please email to:

kruckenb@peruvian.cs.utah.edu (the address on this posting).

Thanks for your help!
Pete.



























-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 14:37:19 GMT
From:      rmura@world.std.com (Ron Mura)
To:        comp.protocols.tcp-ip
Subject:   Microsoft TCP/IP (vs. NetBIOS)

Microsoft has announced support for TCP/IP in their products, such as
Windows for Workgroups and NT.  When we quizzed Microsoft, however,
they said that their software still writes to a NetBIOS interface,
even though TCP/IP is used over the network.

We've always been concerned about the effects of NetBIOS over our
routed WAN (broadcasting, non-routability, etc.).  To what extent does
Microsoft's use of TCP/IP remove the inherent problems of NetBIOS?  I
imagine there will be no problem routing the traffic, but would we
still suffer the effects of NetBIOS broadcasting?


-- 
- Ron Mura, Boston, Massachusetts              rmura@world.std.com


-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 14:50:14 GMT
From:      mike@engn.uwindsor.ca (Mike Drouillard,13310,1100,s)
To:        comp.protocols.tcp-ip
Subject:   How 2 give a machine 2 ip numbers

I need to move to a new ip number on my machines but need to do it gradually.

How then do I give a machine a second ip number so that when I move to it for real
my users won't experience any big headaches.

Specifically in more detail:

machine happy.fred.uwindsor.ca with ip address 137.207.20.3 needs to be known as
        happy.saly.uwindsor.ca with ip address 137.207.40.3 .

As you can see I want to change sub-domains from fred to saly (20->40>

I only have one ethernet interface. 

I would like to be able to telnet to either address and have the machine connect.

Please e-mail directly to mike@engn.uwindsor.ca or root@engn.uwindsor.ca
I will post the solution I get that works back here.
Thanks in advance.


-------------------------------------------------------------------------
Mr. Michael Drouillard               
System Manager CADCAM                        
University of Windsor            
Windsor,Ontario N9B 3P4
519-253-4232 X.3392  (Live & Machine)
519-973-7062         (FAX)
mike@engn.uwindsor.ca (e-mail)
root@engn.uwindsor.ca (e-mail)

"According to the man page, the UNIX sleep(1) command argument must be
 less than 2,147,483,647 seconds which translates to just over 68 years.
 Fortunately, I'm unlikely to encounter this limitation in my lifetime."
-------------------------------------------------------------------------


-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 15:37:44 GMT
From:      holemans@reks.uia.ac.be (Wim.Holemans)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: LAN Workplace for DOS & NFS Client for LAN Workplace for DOS

Anyone has more info on this PIPER/IP software ? Prices ?
Availability in Europe ? Information available via the net ?

Thanks,


-- 
-----------------------------------------------------------------------
Wim Holemans				phone + 32 3 820 22 03
Network/System manager			fax   + 32 3 820 22 44
U.I.A.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 16:26:17 GMT
From:      mwr@eng.tridom.com (Mark Reardon)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <2l0ctv$8r9@navaho.cc.bellcore.com>, kenton@navaho.cc.bellcore.com (gidewall,kenton c) writes:
|> My company is designing a system that is running TCP/IP.  We had planned
|> on using SLIP or PPP (pretty much decided on PPP) for the asynchronous
|> connections via 14.4 or 28.8 modems.  One of our clients saw our design
|> and said that he doesn't want to be forced to use PPP or SLIP and wants
|> to run straight TCP/IP across the phone line.
|> 
|> Now, intuitively, I can say that you can't do this, or at least you
|> shouldn't.  However, I can't tell him why.  I've searched the net and
|> read a lot on SLIP and PPP.  All that I can tell is that nobody does 
|> TCP/IP across a phone line.  Any documentation or discussion just assumes
|> that *of course* you use SLIP or PPP when you have a phone line, but I
|> can't find the technical reason(s) why that is true.
|> 
|> Can someone tell me why we don't use straight TCP/IP over phone lines
|> and why we need/should use SLIP or PPP?  Any pointers to documentation 
|> on the subject would be helpful, as then it wouldn't just be me telling
|> him, I could show him.
|> 
|> Also, if you post your reply, please mail it to me too.  Our news feed
|> is always really slow and I won't see any posted replies for about a 
|> week.
|> 
|> Thanks in advance,
|>    Kenton Gidewall
|>    kenton@cc.bellcore.com

I sent a longer answer to Kenton but in short SLIP is IP over serial,
or Serial Line IP.  The addition of the END character to the IP datagram
is so that the receiver will be able to determine when the entire datagram
has been received.  For more see RFC 1055.  Its only 6 pages long.

Mark

-- 
_____________________________________________
Mark Reardon   AT&T Tridom   (404-514-3383)
email: mwr@tridom.eng.tridom.com, attmail!tridom!mwr

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 16:56:17 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <CM254p.5w4@aston.ac.uk> evansmp@mb48026.aston.ac.uk (Mark Evans) writes:
>Ian Phillipps (ian@unipalm.co.uk) wrote:
>
> ...
>: Ethernet, etc., are packet-oriented by their nature, so can pass IP
>: easily. A serial line isn't, and needs a little help. SLIP is about as
>: little help as you can give it. Without an end-of-packet marker, one
>: error and you're sunk.
>
>This lack of framing may make SLIP unreliable on noisy lines.

SLIP does have framing.  That's about all SLIP has.

>: >Can someone tell me why we don't use straight TCP/IP over phone lines
>: >and why we need/should use SLIP or PPP?  Any pointers to documentation 
>: >on the subject would be helpful, as then it wouldn't just be me telling
>: >him, I could show him.
 
>: The SLIP overhead is minimal. With Van Jacobsen compression, it's
>: negative!
>
>It is difficult to think of anything more minimal. 
>
>Though over a telephone line (as opposed to a direct connection) something
>slightly more sophisticated. e.g. with frame header and CRC; might be more
>practical.

Nonsense.  Based purely on the number of installed systems using PPP and
SLIP over telephone lines, SLIP is more "practical" than PPP.

The only reasons PPP exist are 
    1. some people had bees in their bonnets about link layer error
	detection, esp. for UDP because a big UNIX vendor hadn't gotten
	with the program and turned on checksums for NFS.
    2. some people demanded error correction, most out of ignorance and
	superstition, some out of marketing reasons to pander to such
	superstion, some to be compatible (in a marketing sense) with
	their existing wide-area routers, and some in order to do things
	that might be easier with a reliable link layer.  LAPB still is
	not a real thing in PPP, although I suppose it will be eventually.
    3. people wanted to do more than IP over telephones.
    4. people wanted to mix and match different vendors' wide area routers.
    5. some people wanted fancier, (perhaps) more robust (semi-)automatic
	configuration (negotiation) mechanisms.

Yes, of course, any new installation should use PPP, if available.

Vernon Schryver    vjs@rhyolite.com

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 17:05:28 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?

In article <2l476s$nnf@shogun.ncp.sietec.de> korni@shogun.ncp.sietec.de (Jochen Kornitzky) writes:
>
>I was told by some 'suits' :-) that IP protocol throuput/performance can be 
>increased beyond "any" limit by using highspeed (FDDI and above) wires.
>I "know" that there are certain limits in the IP protocol that apply
>especially to point to point connections but I need strong arguments.

The 'suits' are approximately correctly.

There are no intrinsic limits to the rate at which you send or receive IP
datagrams, except those that might ultimately limit the speed of any
computation, such as limits imposed by the speed of light and the smallest
possible artifact we can make.   The human race is a long way away from
approaching those limits.

>BTW: Can someone drop me a short note on the highest FDDI point to point
>thruput ?

100Mbit/sec for a single TCP/IP connection is available in relatively
low cost UNIX workstations.  Several vendors can do 80Mbit/sec or more.
(Actually, the speed of light on FDDI is about 98Mbit/sec after 
accounting for headers, tokens, and so forth.)

You can buy systems that move about 1Gbit/sec using TCP/IP over
media other than FDDI.  200-500Mbit/sec is about to be common from
large system vendors.  I think Convex recent mentioned 30MByte/sec
file transfers.


Vernon Schryver    vjs@rhyolite.com

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1994 17:52:46 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: How 2 give a machine 2 ip numbers


In article <CM3Fvq.5oH@uwindsor.ca> mike@engn.uwindsor.ca 
(Mike Drouillard,13310,1100,s) writes: 

|I need to move to a new ip number on my machines but need to do it gradually.
|
|How then do I give a machine a second ip number so that when I move to it for real
|my users won't experience any big headaches.
|
|Specifically in more detail:
|
|machine happy.fred.uwindsor.ca with ip address 137.207.20.3 needs to be known as
|        happy.saly.uwindsor.ca with ip address 137.207.40.3 .
|
|As you can see I want to change sub-domains from fred to saly (20->40>
|
|I only have one ethernet interface. 
|
|I would like to be able to telnet to either address and have the machine connect.

Your posting doesn't mention what operating system you're using
(which in this case is significant.)  Assuming that you're using
VMS+MultiNet, as I am, do this:

  $ mu config
  > add pd0
  hardware device: pd0
  IP Address: 137.207.40.3
  IP Subnet Mask: 255.255.x.y
  > exit

Then reboot.  (Note: this is an unsupported feature.)

If you're running a less featureful implementation of TCP/IP, you may
be pretty much out of luck.

Regards,

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /



-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1994 18:27:53 GMT
From:      gvidi@spunky.next.com (Gridharan Vidi (HP))
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Testing & Performance

Hi,

	Where can I find information on "TCP/IP Testing and performance" ?

	Kindly pass all the relevant information to gri@next.com.

	Thanks in advance.

	Bye,Gri

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 18:38:44 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP with OS2?

>I believe that IBM's own TCP/IP for OS/2 offers a slip option.  However,
>the windows programs would not be able to make use of the IBM's own TCP/IP
>for OS/2.......


Bzzzzz.  Close, but not quite.

IBM TCP/IP 2.0 offers its TCP/IP services to DOS and Windows
(a la Winsock) sessions too.  It is the best of  all three
worlds.

This is also true of PC/TCP, LWP and TCP/2 for OS/2 from FTP
Novell and Essex.

Erick


-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 20:12:03 GMT
From:      sandeep@newsservercs.uwindsor.ca (Sandeep Kamat)
To:        comp.protocols.tcp-ip
Subject:   Info on client-server implementation ..


 Hello,

  I am instrested in developing an application which would work as
  follows


  There is a database on a machine  which has inforamtion concerning certain
  topic.Also a set of queries are setup on this database.Aserver is running
  on this machine which accpets connections form other machines over the
  internet.
   The users connecting to this server is given a choice of these queries
  and corresponding to the query posed is answered by the database and the
  answer is delivered to the user.
   



  I would highly appreciate if any one could give me a clue as how to proceed
  with it.I am sure similar application must be exsisting and if any one is
  aaware of the source code pl contact me.


 Thanks in advance.
  sandeep


-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 22:37:44 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

In article <2l30ai$4o4@panix2.panix.com> phoff@panix.com (Phil Hoff) writes:
>Is there a version of traceroute to run on Sunos 4.1.3 where the
>user does not have to be root? I noticed that on Next traceroute
>has a permissions of 4755 and any user can run it. However on our
>Suns only root can run it.

Sheesh.  This is at least the 2nd such request in a day.
This is UNIX.  Use The Power Of The System.

If you don't care about the potential damage traceroute can do to
remote systems, simply make it setuid=root.  It has no other commands
and no subshell, so it would be entirely safe.

(As for damage, consider what those UDP packets sent to random ports
will do if a program on the target happen to be using that UDP
port number.  True, it shouldn't be catastrophic, but it certainly
isn't friendly.)


Vernon Schryver    vjs@rhyolite.com

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 22:55:56 GMT
From:      epp4010@ultb.isc.rit.edu (E.P. Pylko)
To:        comp.protocols.tcp-ip
Subject:   Re: PC/NFS and DNS

In article <105054@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes:
>PC-NFS use DNS?  Maybe in the 6.0 release.  Right now it NIS.  What
>I did on my server is put all the PC-NFS systems in the NIS table and
>enable DNS.  The PCs are guarenteed to find their PCNFS server and will
>use DNS for any other host lookup.  Works fine so far.
>
>Dana Bourgeois

I've been told that version 5.1 of PC-NFS will have DNS. In the
meantime, renaming the rnmnis.exe and rnmnis.dll to rnmdns.exe and
rnmdns.dll seems to work most of the time.  The only problem I've had is
that with any program that needs DNS, I need to use 1.2.3.4, not
some.host.on.thenet.  :)

-- 
Eric Pylko                            Great minds talk about ideas.
epp4010@ultb.isc.rit.edu              Average minds talk about things.
epp4010@cs.rit.edu                    Simple minds talk about people.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 23:40:08 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?

In article <CM2H75.7ww@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>heading@signal.dra.hmg.gb (Anthony Heading) writes:
>
>>  I want the two routing machines to use the FDDI network to
>> talk to each other, but they steadfastly refuse to use anything
>> but the ethernet.
 
>> This makes me suspect that multiple A records
>> are used by trying each address in the gethostbyjingo() structure
>> in turn, but there seems to be no way of making the DNS server
>> impose order onto those addresses.
>
>Isn't this what the "sortlist" directive in named.boot is supposed to do?
>Try sticking it on your nameserver.
>
>The disadvantage to sortlist is that if your ethernet has routers to nets
>other than the fddi net, then traffic to one of the multihomed systems may
>go outside->router->ether->one-fddi-host->fddi->other-fddi-host, even
>though the other-fddi-host has a leg on the ethernet.  This depends on
>which multihomed host is preferred as a route to the fddi.
>
>-- 
>Tom Fitzgerald   Wang Labs   Lowell MA, USA   1-508-967-5278   fitz@wang.com
>Pardon me, I'm lost, can you direct me to the information superhighway?

	Get the bind 4.9.2 resolver code when it is released. The
	sorting is now done in gethostbyname and overrides any sorting
	done in the nameserver.

	4.9.2 is due to be released RSN.

	Mark.

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 23:46:51 GMT
From:      matt@metronet.com
To:        comp.protocols.kerberos,comp.protocols.tcp-ip
Subject:   TN3270 w/Kerberos??

Does anybody know of an implementation of TN3270 that incorporates
Kerberos (V4) authentication and DES encryption?


-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 23:58:38 GMT
From:      "Sharaaz Khan x 7195" <khan@twg.com>
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   ShareWare TCP/IP?

Hello readers,

Does anyone have any information as to WHERE I can
obtain a ShareWare or Public domain TCP/IP stack that 
will run in DOS?

Any help will be appreciated.

Sharaaz 

Sharaaz Khan
THE WOLLONGONG GROUP, INC.
khan@twg.com
Phone: (415)962-7140   fax:(415)969-5547

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 00:19:50 GMT
From:      dond@gold.gvg.tek.com (Don Davis)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Simple network Questions

I would like an overview of networking for connecting and IBM PC to other IBM's
SUNS, whatever. I need to know what is available, how much it costs, what the 
strengths and weaknesses, ect.  I haven't found the "FAQ's" that get this 
general and would appreciate very much a little assistance.

You can email me at dond@gvg.tek.com.
Thanks in advance. dd!


-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 00:37:52 GMT
From:      s913300@otto.bf.rmit.oz.au (Nga  Tran)
To:        comp.protocols.tcp-ip
Subject:   Help: what is X25 ??

Hai all,

Can someone please explain what is X25 ?? is there any FAQ ??

Thanks

TN

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 09:59:52 -0500
From:      alek@ionews.io.org (Aleksandar Matijaca)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <6S1P7Ij024n@comptech.demon.co.uk>,
Adam Goodfellow <adam@comptech.demon.co.uk> wrote:
>ian@unipalm.co.uk (Ian Phillipps) writes:
>
>> 
>> The SLIP overhead is minimal. With Van Jacobsen compression, it's
>> negative!
>> 
>
>Is there actuallu any point in using a compression protocol with modern
>modems?. V42bis seems to do a very good job on it's own. I ask this because
>I am in the process of implementing a TCP/IP system for use over telephone
>lines via modem. Have been looking at both SLIP and PPP. Have been told that
>PPP is better, though I can't see why - it just seems to give more overhead
>without any apparrent gain when used to carry a single protocol only, ie IP.
>
>Adam
>
>+------------------------------------+
>|  email: adam@comptech.demon.co.uk  |
>+------------------------------------+
>

PPP has several advantages, first of all it works at "link level" of the
protocol stack, and thus it is able to worry about the quality of the
line at PPP negotiation time, and enable compression if set up to do so.
In general, PPP is more robust, while SLIP IS NOT A STANDARD!!  After all
SLIP will be replaced one day!
With newer modems, I always turn off the compression, and everything works
quite nicely!!


Alex. Matijaca
ScotiaMcLeod Inc.
Toronto, Ontario Canada



-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 10:41:39 PST
From:      jaf@th.gov.bc.ca (Jeremy Fichtner)
To:        comp.protocols.tcp-ip
Subject:   ARP and Multiple subnets on 1 Enet

Greetings!

Here's a situation that confuses me.  Let's say ther are 1000 nodes on a bridged
network (ethernet.) and all you've got are 4 class c type allocations. ie subnet mask
= 255.255.255.0.  Will ARP work to resolve a XXX.XXX.1.XXX address if the ARPing host has an address of XXX.XXX.2.XXX?  I've heard conflicting views.  I would have thought that if ARP is a broadcast at the MAC level, the station should reply. Or is it that
the ARPing station automatically assumes that the other station is not local and tries
the default router.  If this is the case, what can be done to avoid hitting the router
all the time? I've heard the term "supernetting" but I'm afraid I'm not familiar with 
the concept. I'm going to be running into this very senario as we are installing IP
all over the office and 1 subnet isn't going to cut it.  Any and all wisdom that can
be given will be gratefully accepted.

Thanks All in advance,

Jeremy Fichtner

---
_______________________________________________________________________________
Jeremy Fichtner				jaf@vict0225.th.gov.bc.ca
Systems & Network Analyst		ua889@freenet.victoria.bc.ca
Ministry of Transportion & Hwys		Victoria B.C. Canada
(...speaking for myself of course!)


-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1994 09:36:02 +1030
From:      simon@wraith.internode.com.au (Simon Hackett)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

kenton@navaho.cc.bellcore.com (gidewall,kenton c) writes:

>Now, intuitively, I can say that you can't do this, or at least you
>shouldn't.  However, I can't tell him why.  I've searched the net and
>read a lot on SLIP and PPP.  All that I can tell is that nobody does 
>TCP/IP across a phone line.  Any documentation or discussion just assumes
>that *of course* you use SLIP or PPP when you have a phone line, but I
>can't find the technical reason(s) why that is true.
 
>Can someone tell me why we don't use straight TCP/IP over phone lines
>and why we need/should use SLIP or PPP?  Any pointers to documentation 
>on the subject would be helpful, as then it wouldn't just be me telling
>him, I could show him.

have you tried looking a the RFC that defines SL/IP? It's pretty damn
near being *precisely* TCP/IP "straight over the wire". Indeed, the 
only thing is does is use a known character to signify "end of packet",
and employs a simple escape code mechanism to encode bytes in the packet
which happen to be the same as the end of packet byte (hex C0).

You have to do _something_ like this, in order to be able to pass the
data over the wire and split it up into packets at the receiver. 

Since SL/IP does it perfectly well (and pretty-much minimally), why 
re-invent the wheel? It won't buy you any noticable difference in 
performance.

Also, sending data over the wire is only half the problem (probably the
easier half). The other half of the work is writing an interface driver
for your protocol stack (at both ends of your link) which takes an
IP packet and fires it down the serial line. That's not hard except that
you generally need to be a kernel guru for the operating systems concerned
in order to know where to wire in the changes.

Again, why re-invent the wheel when you can get SL/IP support for
nearly every TCP/IP protocol stack in the known universe?

Cheers,
	Simon Hackett
	simon@internode.com.au

-- 
      Simon Hackett,  Internode Systems Pty Ltd, Adelaide, Australia
      simon@internode.com.au   Ph +61 8 373 1020  Fax +61 8 373 4911

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 04:23:29 GMT
From:      Dan Kruss <dkruss@mcs.com>
To:        cwru.ins.general,comp.sys.mac.comm,comp.sys.mac.apps,comp.protocols.tcp-ip
Subject:   Re: Looking for Mac tcp/ip client/servers

yan@biochemistry.bioc.cwru.edu (Yan Xiang)

For my personal prefs:

Turbogopher has it over gopherapp

You MUST get Fetch to ftp
and MUST get Anarchie for the best archie client
and Nuntius for mail reading
Get Homer for chat

and start reading the newsgroups pertaining to internet.

--dan

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 08:11:07 GMT
From:      jel@xerver.icl.fi (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: Microsoft TCP/IP (vs. NetBIOS)

rmura@world.std.com (Ron Mura) writes:

>We've always been concerned about the effects of NetBIOS over our
>routed WAN (broadcasting, non-routability, etc.).  To what extent does
>Microsoft's use of TCP/IP remove the inherent problems of NetBIOS?  I
>imagine there will be no problem routing the traffic, but would we
>still suffer the effects of NetBIOS broadcasting?

Thus far Microsoft has been doing exactly what other PC TCP/IP vendors
have already been doing for years: broadcasts are used on the local LAN,
but various hacks are used to provide the NetBIOS name to IP address
mapping for names which reside in machines behind routers so that you 
will not have to pass broadcasts around a WAN.  The details differ from 
vendor to vendor but basically all the schemes require you to configure 
the mapping manually.  This works quite well for connection-oriented 
services (e.g. file and printer sharing), but not so nicely for
services, such as the LAN Manager domain concept, which are built around 
broadcast or multicast transmission over a fast medium: you either give 
them up or accept quite messy kludges.

In LAN Manager 2.1a Microsoft introduced the 'TCP/IP Hub/Node' service
which provided a mechanism for distributing multicast traffic around
a WAN. Although it was limited only to LAN Manager mailslot messages,
and did not even try to distribute arbitrary NetBIOS traffic, the
generated WAN load was often too excessive if you wanted even to approximate
the kind of service level you had on the local LAN.  Apparently this was
not a very successful approach since it is no longer supported in Windows NT,
which uses a different set of kludges to support the basic (minimal) NT 
domain services.

Future versions of Windows (NT) are supposed to contain new features
which make life much easier in the WAN environment - provided that you
wait for the vaporware to substantiate and then stick to the proprietary 
services implemented (only) by Microsoft software.

On the other hand, NetBIOS over TCP/IP in a WAN is really not too bad:
we use it internally quite a lot, and it has also been the approach we
have been offering to our customers already several years before Microsoft 
also accepted that it is a useful technology.
-- 
Jerry Lahti             !  tel. +358-0-567 3639
ICL Personal Systems Oy !  fax. +358-0-567 5400
P.O.Box 780             !  Email: jel@xerver.icl.fi (Internet) 
00101 Helsinki, Finland !  X400:  C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 09:18:37 GMT
From:      ib@iersv1.energietechnik.uni-stuttgart.de (Iris Butzbach)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.ultrix
Subject:   Wanted: pctcpd

Hello everybody,

does anyone know how to get the pcnfsd for Ultrix to run PCNFS?

Thanks a lot!

/----------------------------------------------------\/-------------------\
|         Iris Butzbach * IER Uni Stuttgart          ||             up    |
|     Hessbruehlstrasse 49a * 70565 Stuttgart        ||   What goes       |
| Phone: ++49 711 78061-54 * Fax:   ++49 711 7803953 ||                   |
| - - - - - - - - - - - - - - - - - - - - - - - - -  ||  must come        |
|     ib@iersv1.energietechnik.uni-stuttgart.de      ||            down   |
\----------------------------------------------------/\-------------------/


-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 11:06:38 GMT
From:      dunkel@cadis.de (Harald Dunkel)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: Solaris 2.3 tcp problems

ddj@gradient.gradient.com (Dave Johnson) writes:

>We are seeing problems with TCP/IP connections on our
>Solaris 2.3 server.  Just recently we found out about the
>"ndd" command to tweak network driver parameters, and
>it has been of some help, but the problems have not all
>been solved.
 
>First, Solaris 2.3 uses the range of 32768-65535 for port
>numbers when you bind a socket with an unspecified port.
>This caused problems with SMTP to at least one network
>once the system has been up a while.  The attempts to
>deliver mail would all fail with a timeout:
 
>  Mar  1 16:50:09 gradient sendmail[24797]: AA02501: to=someone@austin.ibm.com,
>	delay=1+01:40:25, stat=Deferred: Host netmail.austin.ibm.com is down
 
>Attempting to connect to this machine from a SunOS 4.1.3 machine succeeded.
>When I lowered the range of ports to 2048-32767, the mail
>was delivered after the next attempt:
 
>  # ndd -set /dev/tcp tcp_smallest_anon_port 2048
>  # ndd -set /dev/tcp tcp_largest_anon_port 32767

I had a similar problem with Solaris 2.2: A software router in our net 
(running on a Unix PC) thought the port number is a SIGNED short integer. 
Because all port numbers less than 1024 are protected I had no chance to 
receive any packages coming via the router on the Solaris 2.2 machine. To 
prove the error I wrote the following program (no warranty, do what you like 
with it):

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

main(argc, argv)
int argc;
char *argv[];
{
	struct sockaddr_in server;
	struct sockaddr_in client;
	struct servent *sp;
	struct hostent *hp;
	char hostname[64];
	int s;
	int count = 100;
	unsigned short local_port = 0x7FFE;

	static char buffer1[] = "Hello, world ...\n";
	static char buffer2[sizeof buffer1];

	if (argc < 2) {
		fprintf(stderr, "Usage: %s hostname\n", argv[0]);
		exit(1);
	}

	if ((sp = getservbyname("echo", "tcp")) == NULL) {
		fprintf(stderr, "echo/tcp: unknown service\n");
		exit(2);
	}
	if ((hp = gethostbyname(argv[1])) == NULL) {
		fprintf(stderr, "%s: unknown host\n", argv[1]);
		exit(3);
	}
	bzero((char *)&server, sizeof server);
	bcopy(hp->h_addr, (char *)&server.sin_addr, hp->h_length);
	server.sin_family = hp->h_addrtype;
	server.sin_port = sp->s_port;
	if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
		perror("socket()");
		exit(4);
	}
	printf("socket created\n");
	gethostname(hostname, sizeof hostname);
	if ((hp = gethostbyname(hostname)) == NULL) {
		fprintf(stderr, "%s: unknown host\n", hostname);
		exit(5);
	}
	bzero((char *)&client, sizeof client);
	bcopy(hp->h_addr, (char *)&client.sin_addr, hp->h_length);
	client.sin_family = hp->h_addrtype;
	client.sin_port = htons(local_port);
	while(bind(s, (char *)&client, sizeof client) < 0 && count-- > 0) {
		local_port++;
		client.sin_port = htons(local_port);
		putchar('*');
		fflush(stdout);
	}
	if (count <= 0) {
		perror("bind()");
		exit(7);
	}
	printf("bind(): SUCCESS! Using port number 0x%4.4X\n", local_port);
	if (connect(s, (struct sockaddr *)&server, sizeof(server)) < 0) {
		perror("connect()");
		exit(8);
	}
	printf("Connected to host %s\n", argv[1]);
	write(s, buffer1, sizeof buffer1);
	read(s, buffer2, sizeof buffer2);
	printf("result: %s\n", buffer2);
	close(s);
	printf("connection closed\n");
	return(0);
}

Starting with the local port number 0x7FFE it tries to build a connection
to the echo/tcp service on another machine. You should try to reach your
mail gateway on several architectures (SunOS 4.x, Solaris 2.x, HP-UX or 
what you like) by running it a few times.

Have fun

Harri
--
Harald Dunkel | dunkel@cadis.de  |  Harri's laws of software installation:
CADIS GmbH    | Kaiserstr. 100   |  1) Only install programs with odd minor
52134 Herzogenrath, Germany      |     release numbers.
+49 2407 9558-(fax? 44: 0)       |  2) Never even try version 1.0 .

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 12:49:59 GMT
From:      HANK@vm.biu.ac.il (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

After I read the article I sent the following letter to the editor.
[Only now do I see that the article has created a bit of a stir here.]
I suggest rather than all of us complaining about the poor testbed
we "educate" Data Communications so that they get it better the next
time.

To: 4162157@mcimail.com, ktolly@interlab.com

Letter to the Editor,

    I am quite sure that a  number of PC TCPIP vendors have  written
letters  about  your  February  1994  benchmarks.   Since  I have no
relationship  with  any  of  these  vendors  let  me start with your
article about APPC leaving TCP/IP in the dust.

    I  honestly  don't  think  you  proved  that APPC is faster than
TCP/IP.  How do  I know that  the Novell MPR  that was used  for the
TCP/IP test was not the delaying factor as compared to the IBM  APPN
Network Node router which was used in the APPC test?

    What  you  probably  did  prove  is  that PC TCP/IP vendors have
ignored the Token Ring market and have done close to no optimization
for Token Ring.  What you also  have proven is that FTP Software  is
not the fastest  nor the most  reliable (crashed with  window set to
1024 & 2048 bytes).  What I would have liked to see is an OS/2  test
where Ethernet is used to test IBM's APPC vs.  IBM's  implementation
of TCPIP.  Now that would be comparing apples to apples.

    I was also annoyed by your comment in the article "... using FTP
at the underwhelming rate of  about 1.7Mb/sec."  How do I  know that
the 3Com Etherlink III card is not the bottleneck and the cause  for
slow performance?  Is indeed the 3Com card the fastest card  around?
How do I  know that doing  the 1Mbyte FTP  GET was not  delayed by a
slow hard disk?  Was data kept in a buffer as it was in the APPC  vs
TCPIP  Token  Ring  test?   If  it  was  it  wasn't mentioned in the
article.

    I have done numerous benchmarks and have indeed found that on  a
single  segment  Ethernet  going  from  a  RAMDISK  on  a  large IBM
mainframe to /dev/null (memory) on a fast IBM RS/6000, I was able to
hit 4.8Mb/sec  (FTP binary  PUT).  This  might indeed  be indicative
that TCPIP and Ethernet have a symbiosis problem when attempting  to
reach wire speed.  Then again, everyone always says that an Ethernet
is saturated when it hits 60% so perhaps not even the new glory  boy
called APPC can do well on an Ethernet.

    Perhaps your benchmarks have shown  that Token Ring is indeed  a
speed champ when compared to a sluggish Ethernet.  But I think it is
too early  to categorically  state that  APPC is  faster than  TCPIP
until you start measuring apples to apples and not prunes to lemons.

Hank Nussbacher
Networking consultant
Rechov Hagefen 20
Ginot Shomron
Israel

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 13:33:30 GMT
From:      melbye@stkh22.alcatel.no (Jan Olav Melbye)
To:        comp.protocols.tcp-ip
Subject:   "dev/tcp" stream for HP ?????

Hi !

Do anyone know if HP support the "dev/tcp" streams module? 

-- Jan Olav Melbye

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 15:18:23 GMT
From:      goli@rasii.rchland.ibm.com (Srinivas Goli)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on client-server implementation ..


-- 
You should refer to the book

Unix Network Programming -- Richard Stevens
	Assuming that your need is to build on unix machines. The book has quite a few examples
of how to build client server applications along with source code. Another book which is equally
good is

Internetworking with TCP/IP Comer and David Stevens.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 15:31:21 GMT
From:      roger@ipswitch.UUCP (Roger C. Greene)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: LAN Workplace for DOS & NFS Client for LAN Workplace for DOS

holemans@reks.uia.ac.be (Wim.Holemans) writes:

>Anyone has more info on this PIPER/IP software ? Prices ?
>Availability in Europe ? Information available via the net ?

You can get more information by emailing to sales@ipswitch.com.

Roger


-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 16:18:56 GMT
From:      roger@ipswitch.UUCP (Roger C. Greene)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: LAN Workplace for DOS & NFS Client for LAN Workplace for DOS

alek@ionews.io.org (Aleksandar Matijaca) writes:

>	E) PIPER/IP, Blazingly fast, least amount of memory (6k of lowmem),
 [text deleted..]
>	My rumour mill tells me that
>	these are some ex-FTP programmers who started their own company..

Two of us used to work at FTP, but neither wrote code there.

Roger
roger@ipswitch.com

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 16:33:27 GMT
From:      thalerd@quip.eecs.umich.edu (Dave Thaler)
To:        comp.protocols.tcp-ip
Subject:   IP options

Can IP options be used by a user process?  Programs like traceroute
generate their own IP headers (without IP options), but don't seem
to work with IP options.

The only code I can find so far which uses IP options is the multicast
kernel extensions.

If IP options can be used by a user-level root process, does anyone
have example code for getting this to work?

--
Dave Thaler
CS Grad Student
University of Michigan

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 21:37:07
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: "dev/tcp" stream for HP ?????

> Do anyone know if HP support the "dev/tcp" streams module? 

HP has an unbundled STREAMS product. Their TCP/IP protocol stack can *not*
use it. In short, the answer is no.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 16:52:08 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Low cost terminal servers?

Does anyone have any experiences/recommendations on a low-cost TCP/IP
terminal server supporting at least two ports?  I am forwarding this
question for someone without USENET access.  If possible, please email
replies directly to him at: Rick_Moore@alpham.cerfnet.com (or I can
forward replies otherwise).

Thanks!



-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 17:02:32 GMT
From:      davidb@vnet.ibm.com
To:        comp.protocols.tcp-ip
Subject:   SLIP performance tuning



Can any one tell me of any existing documents showing how to tune slip for 
optimal performance, and or any programs to test its efficiency with
with different settings.


Thanks in advance,

David Bond
davidb@vnet.ibm.com




-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 17:33:49 GMT
From:      BJuliano@dormnet.stu1.uconn.edu (Bryan Juliano)
To:        comp.protocols.tcp-ip
Subject:   Good book on all protocols, for a programmer?

	I am doing some network analisys programming and I need a good 
reference book on all protocols, paticurally TCP/IP and IPX.  Books, RFCs PD 
dociment suggestions would be greatly appreciated.

Thanks,

Bryan 

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 17:57:03 GMT
From:      evansmp@mb4802.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: all-one-bits versus all-zero-bits in broadcasting

James Harvey (harvey@indyvax.iupui.edu) wrote:
: In article <CM21wv.InA@unirsvl.rsvl.unisys.com>, sybesma@unirsvl.rsvl.unisys.com (Eric Sybesma) writes:
: > Hi,
: > 	Curious about broadcasting to networks.  What is the
: > difference between specifying, say a class C address
: > 192.61.236.255 versus
: > 192.61.236.0
 
: The former is a standard form of broadcast address, the latter is not.
: See RFC 1122 section 3.3.6.
 
: > 	In Xenix, you can set a parameter on the netload call (-u)
: > that converts outgoing broadcast messages with X.X.X.0 to
: > X.X.X.255, or so I think.  What is the difference between one of
: > the other?
 
: One is standard, the other isn't.  You should use the standard forms of
: broadcast addresses if possible.  The feature you are talking about appears
: to be there for compatibility purposes.  I wouldn't use it unless I had a
: good reason to.  If you don't have 4.2BSD (or derived) hosts or software
: on your net you probably don't have to worry about it (with the exception
: of making sure hosts use the right one -- as an example, SunOS 4.1.3 was
: *still* using the long-obsolete zeros forms as the default).

A machine should accept both and regard them as broadcasts, i.e. never
generate an ICMP error if it is not listening to that port.
Only the 'all ones' type should be sent. In certain cases e.g. a router 
connected to a subnet, on which an 'all subnet' brodcast has been sent
there might be quite a bit of processing needed.

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      04 Mar 1994 18:41:50 GMT
From:      skelley@pecan.ee.vt.edu (Sean Kelley)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

Try 'ping -sRv <host>'. It isn't as fancy, but some of the
information is there. Sean.
--
Sean M. Kelley [skelley@birch.ee.vt.edu]
"Origami: a creative approach to paperwork"

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 19:31:07 +0000
From:      elatar@comptech.demon.co.uk (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

alek@ionews.io.org (Aleksandar Matijaca) writes:

> With newer modems, I always turn off the compression, and everything works
> quite nicely!!
> 
Hmm... Interesting... I have been looking at adding an extension to TCP to
reside between TCP and hosts to do optional data compression/decompression
on the fly on selected data, eg directory listings, News, Mail etc...
hopefully will be doing some tests soon. Obviously, it will only be useful
when compression is switched off on the modem.

BTW If anyone is interested in this - please email me - I should have the
implementation details finialised soon. (Its only intended for use over low
speed links ie upto around 100kbps)

Elatar

+------------------------------------+
| email: elatar@comptech.demon.co.uk |
+------------------------------------+


-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 20:52:51 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

In article <2l30ai$4o4@panix2.panix.com> phoff@panix.com (Phil Hoff) writes:
>Is there a version of traceroute to run on Sunos 4.1.3 where the
>user does not have to be root? I noticed that on Next traceroute
>has a permissions of 4755 and any user can run it. However on our
>Suns only root can run it.

So make it set-uid, as on the NeXT.  That's what we do.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 21:01:47 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: internet address forms

In article <CM2pL9.2s7@unirsvl.rsvl.unisys.com> sybesma@unirsvl.rsvl.unisys.com (Eric Sybesma) writes:
>what are the different forms an internet (CLASS A B C D)
>can take.  I know
>
>a.b.c.d. x < 256 is one, but is
>a.b b< 256*256*256 also valid..?

IP addresses are almost always written in a.b.c.d format.  Some systems
make use of IP addresses in hexadecimal AABBCCDD format (this is commonly
used as the filename of net-bootable kernels and configuration files).
I've never seen your a.b syntax used anywhere.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 21:29:35 GMT
From:      jas@talking.COM (Jim Shankland)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?

In article <2l476s$nnf@shogun.ncp.sietec.de> korni@shogun.ncp.sietec.de (Jochen Kornitzky) writes:
>Hi,
>
>I was told by some 'suits' :-) that IP protocol throuput/performance can be 
>increased beyond "any" limit by using highspeed (FDDI and above) wires.
>I "know" that there are certain limits in the IP protocol that apply
>especially to point to point connections but I need strong arguments.

If the ratio of bandwidth to latency is much higher than on today's
typical TCP/IP networks, you may not be able to have a big enough
TCP window to keep the data pipe filled.  Consider a 100 Gigabit
link with a 3 second latency, and ask yourself how many unacknowledged
bytes you need to have outstanding in order not to stall waiting
for an ACK.  The TCP header has room for only a 16-bit window
size ....

jas

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 21:40:23 GMT
From:      NADEL@litc.lockheed.com (Ron Nadel)
To:        comp.protocols.tcp-ip
Subject:   PC Traceroute

Does anyone know or and/or use a windows-based traceroute program?

Thanks,

Ron

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 22:12:43 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <2l7id8$oek@ionews.io.org> alek@ionews.io.org (Aleksandar Matijaca) writes:
> ...
>PPP has several advantages, first of all it works at "link level" of the
>protocol stack, and thus it is able to worry about the quality of the
>line at PPP negotiation time, and enable compression if set up to do so.
>In general, PPP is more robust, while SLIP IS NOT A STANDARD!!  After all
>SLIP will be replaced one day!
>With newer modems, I always turn off the compression, and everything works
>quite nicely!!


SLIP is just as much a standard as PPP.  SLIP has an RFC.  That PPP has
bunches of RFC's with half a dozen to be released this year or next does
not make PPP more standard, quite the contrary to rational people.

Both SLIP and PPP work 'at "link level"'.  There is no difference in that
regard, unless you are referring to the future PPP standards for bridging
link layer packets.  I have never heard of and doubt there ever will be
public domain or freely redistributable PPP implementations that support
bridging, except perhaps for Netbios.  You have to do too many other things
to make a useful bridge than just ship the packets.   Bridging PPP is a
game played by router box vendors and maybe Microsoft.

I have never heard of a PPP implementation that decides whether or not to
enable compression based on "the quality of the line at PPP negotiation
time."  Presumably you are talking about either VJ-header compression (as
in CSLIP) or CCP link layer compression, because it would not be practical
to toggle v.42bis modem compression on or offafter you have already started
exchanging LCP or authentication packets.  I suppose you could turn on
LCM, wait awhile, and then answer IPCP requests, but I can't imagine why.
I suppose that a PPP implementation that includes CCP could do the same,
perhaps choosing which compression protocol based on the error rates of
the links, perhaps refusing one that does not require LAPB if the link is
not as error free as the usual v.42 modem link, but since the CCP draft
is new and I don't think anyone is yet shipping an implementation of CCP,
I don't think that makes sense either.

PPP is not more robust than SLIP.  Reasonable arguments can be made that
it is more idiot proof, but it has more knobs and button for idiots to
toggle and twist, respectively, and so reasonable arguments can be made
that PPP is less robust.  PPP does have a link-layer checksum that most
varients of SLIP do not, and that does provide a small, almost
insignificant improvement over the normal IP, TCP, and UDP checksums for
most traffic, with NFS from some old versions of a big UNIX vendor's system
the solitary exception.

I, along with practically everyone else, find it best to turn on v.42bis
modem compression when using PPP.

Finally, when all else is equal, there are good reasons to pick PPP instead
of SLIP.


Vernon Schryver    vjs@rhyolite.com

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 22:15:30 GMT
From:      ascott@ad-1.naitc.com (Anthony Scott)
To:        comp.protocols.tcp-ip
Subject:   Batch file transfer tools wanted

Hi,

I am looking into better ways of doing batch file transfers
with TCP/IP... currently we are using ftp with a wrapper, but
it leaves much to be desired.  Any suggestions or information
will be appreciated.

Thanks,

Tony Scott

ascott@nis.nielsen.com
(708) 317 3493



-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 22:45:43 GMT
From:      paulf@panic.Eng.Sun.COM (Paul Fronberg [CONTRACTOR])
To:        ba.seminars,ba.internet,comp.security.misc,comp.protocols.tcp-ip,comp.unix.admin,comp.unix.internals,comp.unix.questions,comp.unix.bsd,comp.unix.solaris,comp.unix.sys5.r4,comp.infosystems.gopher,comp.infosystems.www
Subject:   SVNet March meeting delayed a week: panel discussion on Internet

The SVNet meeting that normally would be on March 9th has been rescheduled.
(We got bumped). The new date will be March 16th (third Wednesday). The
topic will be a panel discussion by several of the local Internet service
providers on Internet access, services, futures, etc. The official posting
will go out early next week.

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 23:33:13 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP and Multiple subnets on 1 Enet


In article <1994Mar4.104140.3582@vmsmail.gov.bc.ca>, jaf@th.gov.bc.ca 
(Jeremy Fichtner) writes:
|Greetings!

Howdy!  (Next time, could you try setting your right margin to 
70 or so?  Thanks.)

|Here's a situation that confuses me.  Let's say ther are 1000 nodes on a bridged
|network (ethernet.) and all you've got are 4 class c type allocations. ie subnet mask
|= 255.255.255.0.  Will ARP work to resolve a XXX.XXX.1.XXX address if the ARPing host 
|has an address of XXX.XXX.2.XXX?

The source station will not broadcast an ARP, because it doesn't believe that
the destination is on its local cable.

|  I've heard conflicting views.  I would have thought 
|that if ARP is a broadcast at the MAC level, the station should reply.

The point is that the ARP never gets sent.

| Or is it that
|the ARPing station automatically assumes that the other station is not local and tries
|the default router.

That's what will happen.

|  If this is the case, what can be done to avoid hitting the router
|all the time?

Nothing, really.  You can break your network into four equal-sized 
segments, and plug each segment into a separate port on a router.  
This will not prevent each packet going from one class C to another 
from bopping across a router, but at least it will prevent such packets 
from traversing your Ethernet twice.

| I've heard the term "supernetting" but I'm afraid I'm not familiar with 
|the concept.

You can see RFC-1338, "Supernetting: an Address Assignment and Aggregation 
Strategy", and also RFC-1519, "Classless Inter-Domain Routing".  This is the 
beginning of a move to get rid of the old class A/class B/class C distinctions, 
which would theoretically allow people with 4 Class C's to aggregate them
with a 255.255.252.0 mask.  However, all the thrust so far has been from the
router and backbone providers (to conserve router and backbone link resources),
and as far as I know, no one has really tried to do anything about implementing
CIDR on endsystems.

|I'm going to be running into this very senario as we are installing IP
|all over the office and 1 subnet isn't going to cut it.  Any and all wisdom that can
|be given will be gratefully accepted.

When assigning addresses, try to do so to make it easy to separate
into separate physical networks later on.  Accept the fact that inter-class-C
packets will move non-optimally.  When the traffic load gets too bad, install
a multiport router and partition your net.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 01:17:45 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options

In article <2l7nsn$q0o@zip.eecs.umich.edu> thalerd@quip.eecs.umich.edu (Dave Thaler) writes:
>Can IP options be used by a user process?  Programs like traceroute
>generate their own IP headers (without IP options), but don't seem
>to work with IP options.
> ...

Current versions of traceroute understand "-g", which invokes
lose-source-routing.


Vernon Schryver    vjs@rhyolite.com

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 01:24:08 GMT
From:      skamadol@erc.cat.syr.edu (Shyam Kamadolli Kamadolli)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   PPP from host accessed by telnet after dialup?


Hi all,

I access teh internet by dialling into a modem server which allows
me to telnet into an HP machine which is actually on the Internet.

Can I run PPP over my dialup line such that the remote machine is
the HP which I have used telnet to get into?

Thanks,
Shyam

shyam@utica.kaman.com

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1994 01:46:45 GMT
From:      tomw@kalpana.com (Tom Walsh)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does a host arp for itself?

In article 27302@alias.com, mark@alias.com (Mark Andrews) writes:
> We have a number of SGI boxes here and tcpdump shows that they arp for their
> own ethernet address. Why? Isn't is easier for the machine to lookup its
> own enet address?
> 
> The ifconfig output from one of the hosts is:
> 
> ec0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,FILTMULTI,MULTICAST>
> 	inet 192.XX.XX.XXX netmask 0xffffff00 broadcast 192.XX.XX.255


it is a cheap way of telling if someone on the net has your ip address.
its called gratuitous arp sometimes.
---
----------*----------*----------*---------*---------*---------*
Tom Walsh

"To Internet or not to Internet, That is the question"
#include <std.disclaim.h>
			( 408 ) 749-1600 ext 153
			( 408 ) 749-1690 ( FAX )
			internet: tomw@kalpana.com
				  tomw@netcom.com
---------*----------*----------*---------*---------*---------*



-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 02:11:09 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: internet address forms

>> a.b b< 256*256*256 also valid..?

barmar@think.com (Barry Margolin) writes:

> I've never seen your a.b syntax used anywhere.

inet_addr and inet_network accept it, though.  From the man page here....

    Values specified using the dot notation take one of	the following forms:

       a.b.c.d
       a.b.c
       a.b
       a

    When four parts are	specified, each	is interpreted as a byte of data and
    assigned, from left	to right, to the four bytes of an Internet address.
[...]
    When a two part address is supplied, the last part is interpreted as a
    24-bit quantity and	placed in the right most three bytes of	the network
    address.  This makes the two part address format convenient	for specify-
    ing	Class A	network	addresses as net.host.

Amazing but true.  I bet it's real popular with all those sites that use a
class A address on a single physical LAN.

We discovered this by investigating why, when we foolishly named a system
x400, "ping x400" tried to ping 0.0.4.0.

-- 
Tom Fitzgerald   Wang Labs   Lowell MA, USA   1-508-967-5278   fitz@wang.com
Pardon me, I'm lost, can you direct me to the information superhighway?

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 02:58:34 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <6sd2oaj024n@comptech.demon.co.uk> elatar@comptech.demon.co.uk writes:
>Hmm... Interesting... I have been looking at adding an extension to TCP to
>reside between TCP and hosts to do optional data compression/decompression
>on the fly on selected data, eg directory listings, News, Mail etc...
>hopefully will be doing some tests soon. Obviously, it will only be useful
>when compression is switched off on the modem.
>
>BTW If anyone is interested in this - please email me - I should have the
>implementation details finialised soon. (Its only intended for use over low
>speed links ie upto around 100kbps)
> ...

The CCP drafts might be interesting. 

CCP stands for "Compression Control Protocol," and is the IETF's effort
to do link-layer compression for PPP.  I think I correctly recall some
router box vendors talking about various kinds of CCP negotiated
compression on links as fast as T1 (about 1.5Mbit/sec).

Copies of the draft can be found in the usual places.  It is hoped that
a new, very slightly modified for MCP (PPP multi-link) will be agreed to
at the impending IETF meeting in Seattle.

Note also that "adding an extension to TCP" is not an easy thing to
contemplate.  90% of networking is politics, and the politics of such an
option for TCP would be ... let's say entertaining.  It's the unhappy
nature of network protocols that unless one gets enough other people to
agree with one's ideas, whether by working the standards committees or by
using a position at a large vendor to create a de facto standard, they go
no where.

Never mind that when possible, it would be more useful to amend IP
instead of TCP to do compression.

Note also that various people over the years have extended VJ header
compression to use splay trees and other techniques.

Note also that the really hard parts of compression over modem lines, even
messier than the standards committee politics, are dealing with patents.
See the comp.compression FAQ.

I've been running a form of PPP compression, "BSD Compress," (not
surprising if you read the draft or the IETF PPP mailing list), and I've
been unable to measure a difference on modems with v.42bis on or off.
They either do a little extra compression or turn their compression off.

Of course, even with link-layer compression, you still want VJ-header
compression.


Vernon Schryver    vjs@rhyolite.com

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 03:23:11 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?

korni@shogun.ncp.sietec.de (Jochen Kornitzky) writes:

> I was told by some 'suits' :-) that IP protocol throuput/performance can be 
> increased beyond "any" limit by using highspeed (FDDI and above) wires.
> I "know" that there are certain limits in the IP protocol that apply
> especially to point to point connections but I need strong arguments.

There are no "intrinsic" limits, but things get messy as you get up into
the high-bandwidth high-delay areas, and eventually the speed of light will
get you.  As RFC 1110 points out, it's dangerous to reuse sequence numbers
within a small multiple of the round-trip-time of a connection; there's a
tiny danger that earlier packets will be duplicated, delayed, and then
reinserted into the stream the next time the same sequence number comes by.

In a couple of ways we're already near the danger zone in one area, and in
it in another.  It's <theoretically> possible for a packet to be duplicated
in the Internet and hang around for up to 2 minutes (the maximum segment
lifetime decreed by RFC 1122).  To avoid re-using sequence numbers within 2
minutes, you're limited to approximately 36 MB/sec.  If there's any risk of
packets being fragmented, then it's not 100% safe to reuse IP (16-bit)
identification values within 2 minutes, which limits you to 2^16 packets
per 2 minutes; at 536 data bytes/datagram, this is about 300 KB/sec.  Any
faster, and there's a chance that 2 packets with the same ID will be
fragmented, and the fragments of one will be duplicated and hang around
long enough to be reassembled into the other.

In reality these aren't dangers as long as you don't reuse either sequence
numbers or identification values within a small multiple of the round-trip
time of a connection.  The faster the connection is, the faster wandering
packets will have their TTL drop and expire.

-- 
Tom Fitzgerald   Wang Labs   Lowell MA, USA   1-508-967-5278   fitz@wang.com
Pardon me, I'm lost, can you direct me to the information superhighway?

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 05:49:24 GMT
From:      craigp@world.std.com (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?

jas@talking.COM (Jim Shankland) writes:

>If the ratio of bandwidth to latency is much higher than on today's
>typical TCP/IP networks, you may not be able to have a big enough
>TCP window to keep the data pipe filled.  Consider a 100 Gigabit
>link with a 3 second latency, and ask yourself how many unacknowledged
>bytes you need to have outstanding in order not to stall waiting
>for an ACK.  The TCP header has room for only a 16-bit window
>size ....

This limitation was fixed a few years ago and many TCP
implementations now support the extensions.  See RFC 1323 which defines
the window scale option and the extended sequence space.  The window
size is now 32-bits and the sequence space is now effectively 64 bits.

Craig

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1994 07:58:16 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?

In article <CM5t1C.8w5@xinet.com> jas@talking.COM (Jim Shankland) writes:
    In article <2l476s$nnf@shogun.ncp.sietec.de> korni@shogun.ncp.sietec.de
	(Jochen Kornitzky) writes: 
    >I was told by some 'suits' :-) that IP protocol throuput/performance
 can be  
    >increased beyond "any" limit by using highspeed (FDDI and above) wires.
    >I "know" that there are certain limits in the IP protocol that apply
    >especially to point to point connections but I need strong arguments.
    
    If the ratio of bandwidth to latency is much higher than on today's
    typical TCP/IP networks, you may not be able to have a big enough
    TCP window to keep the data pipe filled.  Consider a 100 Gigabit
    link with a 3 second latency, and ask yourself how many unacknowledged
    bytes you need to have outstanding in order not to stall waiting
    for an ACK.  The TCP header has room for only a 16-bit window
    size ....
    
Which is why RFC 1323 exists.  

Tony

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 94 08:47:48 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

In article <CM41Iw.7nH@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>In article <2l30ai$4o4@panix2.panix.com> phoff@panix.com (Phil Hoff) writes:
>>Is there a version of traceroute to run on Sunos 4.1.3 where the
>>user does not have to be root? I noticed that on Next traceroute
>>has a permissions of 4755 and any user can run it. However on our
>>Suns only root can run it.
>
>Sheesh.  This is at least the 2nd such request in a day.
>This is UNIX.  Use The Power Of The System.
>
>If you don't care about the potential damage traceroute can do to
>remote systems, simply make it setuid=root.  It has no other commands
>and no subshell, so it would be entirely safe.
>
>(As for damage, consider what those UDP packets sent to random ports
>will do if a program on the target happen to be using that UDP
>port number.  True, it shouldn't be catastrophic, but it certainly
>isn't friendly.)
>
>
>Vernon Schryver    vjs@rhyolite.com

An ordinary user with sufficient knowledge does not need any root privileges 
or any traceroute or other setuid root binaries to throw random junk at UDP 
ports. Its quite easy to do. Traceroute really does not help a malicious 
user wreak havoc, they can do it just as easily (and more effectively) 
through other means. A simple C program using while(1) and sendto() to 
spam an UDP port on a remote machine can be run as non-root, and be more 
annoying than traceroute. I have seen such programs, they run as non-root 
and are quite trivial indeed.


-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1994 15:01:54 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?

In article <CM69Eq.HrJ@wang.com>, Tom Fitzgerald <fitz@wang.com> wrote:
}In a couple of ways we're already near the danger zone in one area, and in
}it in another.  It's <theoretically> possible for a packet to be duplicated
}in the Internet and hang around for up to 2 minutes (the maximum segment
}lifetime decreed by RFC 1122).  To avoid re-using sequence numbers within 2
}minutes, you're limited to approximately 36 MB/sec.  If there's any risk of
}packets being fragmented, then it's not 100% safe to reuse IP (16-bit)
}identification values within 2 minutes, which limits you to 2^16 packets
}per 2 minutes; at 536 data bytes/datagram, this is about 300 KB/sec.  Any
}faster, and there's a chance that 2 packets with the same ID will be
}fragmented, and the fragments of one will be duplicated and hang around
}long enough to be reassembled into the other.

   Well, a 536 byte datagram shouldn't be fragmented, but...

   In any event, you could, of course, "safely" send 65535 datagrams
   of 65492 bytes in 2 minutes (~36MB/s).  They'd be fragmented all
   to hell, but there'd be no danger of misassembly.

John


-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 18:09:28 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: internet address forms

In article <CM662M.G1L@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>barmar@think.com (Barry Margolin) writes:
>
>> I've never seen your a.b syntax used anywhere.
 
> ...
>                   I bet it's real popular with all those sites that use a
>class A address on a single physical LAN.

It's handy for class-D addresses. `ping 224.1` finds multicast-smart hosts.


Vernon Schryver    vjs@rhyolite.com

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1994 18:28:59 GMT
From:      sundar@ai.mit.edu (Sundar Narasimhan)
To:        comp.protocols.tcp-ip
Subject:   what is inet_netof supposed to return in a Class C network

Hi, I have an application that requires subnet level address identification.
I have a piece of code that breaks apart an internet address using
inet_netof and inet_lnaof, but after running the identical code on two
machines (both of which are subnetted class C, and have a netmask
of 0xffffff00 on their interfaces that I'm dealing with) inet_snetof
returns A.B.C.0 on one machine but A.B.0.0 on the other.

Sparc's running Solaris 2.2, and SGI's running Irix4.0.5 seem to exhibit
the former behavior but Sparcs/Suns running SunOS 4.1.3 seem to exhibit
the latter behavior. 

Can someone explain to me what the right thing to do is? (Is inet_netof
supposed to take the netmask into account, or NOT?)

Thanks.
(reply by email since I don't read this group often, and I doubt others
are interested. I can summarize if there's any interest).


-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 18:39:26 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options

> Current versions of traceroute understand "-g", which invokes
> lose-source-routing.

This option no longer works on many newer systems.  Two that I know
it doesn't work on are BSD/386 and Solaris 2.x.  It does work under
vanilla SVR4 and SunOS 4.1.x.

The reason is that traceroute uses the socket option IP_OPTIONS to set
the source route.  Newer kernels that support the IP_HDRINCL option for
a raw socket (which traceroute uses, if defined) *no longer* insert the
IP options specified by IP_OPTIONS into the outgoing IP header.  It's
asusmed the caller has already done that since the caller set IP_HDRINCL.
To get around this, traceroute needs to build the source route into its
IP header, and not specifiy the source route using IP_OPTIONS.  A nontrivial
fix from a quick glance.

But back to the original poster's question: traceroute is a good starting
point to see what you need to specify for IP_OPTIONS.

	Rich Stevens  (rstevens@noao.edu)

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 22:46:48 GMT
From:      a336dhal@cdf.toronto.edu (Dhaliwal Bikram Singh)
To:        comp.protocols.tcp-ip
Subject:   Am I adequate?


I used 60 feet of regular flat telephone type cable to
hook up two nodes using 10baseT.  My kernel on one
of machines is panicing, so I haven't been able
to able to do much testing on it.

Is this flat cable OK for a small network like this?

-bik
-- 
-a336dhal@cdf.toronto.edu
-bikram dhaliwal

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1994 10:26:28 -0500
From:      alek@ionews.io.org (Aleksandar Matijaca)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know a TN5250 client for PC or Mac ???

In article <bruceg.2.0009B8C2@pdn.paradyne.com>,
Bruce Grunewald <bruceg@pdn.paradyne.com> wrote:
>In article <2kd1cc$s8d@hobbes.cc.uga.edu> edm@harpo.dev.uga.edu (Ed Maioriello) writes:
>>From: edm@harpo.dev.uga.edu (Ed Maioriello)
>>Subject: Re: Anyone know a TN5250 client for PC or Mac ???
>>Date: 22 Feb 1994 13:29:48 GMT
 
>>In article <CLLA5E.Azn@hpwin052.uksr.hp.com> gerryw@hpwin052.uksr.hp.com (Gerry Winsor) writes:
>>>David Sims (sims@sndsn1.sedalia.sinet.slb.com) wrote:
>>>: Does anyone know of a robust TN 5250 client for PC or Mac ?? Can a TN 3270
>>>: client be used with a re-mapped keyboard ?? If so, has anyone done this
>>>: for a PC-TCP client for DOS/Windows or a Brown University TN3270 client
>>>: for Macintosh ?? Any help would be most welcome. 
>>>
>
>The current release (4.0) of Chameleon by Netmanage has a tn5250 client. I 
>can't make any claim for robustness as I have not tested 5250, but the rest of 
>the package works well. This is a Windows package with Telnet, FTP (client 
>and server), news reader, mail client, and a bunch of other stuff. You can get 
>more info by getting the FAQ in comp.protocols.tcp-ip.ibmpc, including phone 
>numbers for the vendor. Think it lists for $395, or $495 with NFS.

For TN5250 terminal emulation we use Rumba/400 Version 1.1.  It works with
anyone's WINSOCK.DLL that is 1.1 compliant.  Support is great, however it does
not support IBM's PCSUPPORT "client/server" connectivity.  Otherwise, even
diehard IBM Greenscreen types use it at our place, and they are quite happy
with it.  I can't remember the company name, but they advertise in most
mini computer magazines, Byte e.t.c.  The price is about $400 I believe.

	Regards, Alex.



-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 05:40:51 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

In article <1994Mar5.084748.28553@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>In article <CM41Iw.7nH@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
> ...
>>(As for damage, consider what those UDP packets sent to random ports
>>will do if a program on the target happen to be using that UDP
>>port number.  True, it shouldn't be catastrophic, but it certainly
>>isn't friendly.)
 
>An ordinary user with sufficient knowledge does not need any root privileges 
>or any traceroute or other setuid root binaries to throw random junk at UDP 
>ports. Its quite easy to do. Traceroute really does not help a malicious 
>user wreak havoc, they can do it just as easily (and more effectively) 
>through other means. A simple C program using while(1) and sendto() to 
>spam an UDP port on a remote machine can be run as non-root, and be more 
>annoying than traceroute. I have seen such programs, they run as non-root 
>and are quite trivial indeed.

Of course.
Exactly the same can be said of `ping -f`, which many systems do not 
allow the unwashed to use.  (Personally, I think that's too restrictive.)

The trouble with `ping -f` and `traceroute` is not that it is hard to do
dumb things with C or even perl.  The trouble is that `ping -f` and
`traceroute` are attractive nuisenses.  Some people think them cool and
run them indefinitely on all machines they can reach to most of the
machines they can name.  They are the same people who run at least one
`top` on every machine on which they have even a guest account.  They are
also people who either don't know enough to write the obvious bad programs
or know enough not to.


Vernon Schryver    vjs@rhyolite.com

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1994 15:35:29 -0500
From:      santhana@nova.umd.edu (Sathiya Santhana)
To:        comp.protocols.tcp-ip
Subject:   Transparent TCP/IP over X.25

We are designing a network that will involve a X.25 connection between 
two AIX RS/6000 machines (this X.25 connection will be over a satellite 
system running at 19.2k or 56k baud).

Each of these machines will also be connected to their own local LANs 
(token rings) and they will use TCP/IP to talk to other hosts on those 
LANs.

Our question is: can we configure the two AIX machines so that their X.25 
connection transparently transports TCP/IP packets?  We want that X.25 
connection to look logically like a TCP/IP LAN itself.  If not AIX, do
other vendors provide such capabilities?

Thanks in advance,

Santhana

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 07:44:17 GMT
From:      a336dhal@cdf.toronto.edu (Dhaliwal Bikram Singh)
To:        comp.protocols.tcp-ip
Subject:   Ping, eth0, WD8023, 99pl15, crashes

I am having some major problems getting my little mini-network
setup.  I have two identical WD80x3 cards (10baseT), and I have
hard wired the settings in the kernal:
IO addr=0x300
IRQ    = 9
Memory = 0xCC00

ping -c1 suedehead.org    gives:
ping suedehead (197.100.1.22): 56 data packets
eth0: bogus packet, status=0x0,nxpg=0x10,size=68 

I get this no matter what but only on one machine, the
other seems fine.

I think this card is a 16K card, since the DOS config for it lets
me set it at that (it is used, don't have any manuals).

I have two computers, identical except one has 8 megs , the other 4 megs.
The 4 meg machine crashes regularily if I try to ping it from the
8 meg machine, however the 8 meg machine never crashes regardless
of what I do.

In fact I can make the 4 meg machine crash by trying to rlogin or
ping from the 8 meg machine.  Both are running the same kernel.

here is my hosts file:

/etc# cat hosts
# /etc/hosts: List of hostnames and IP addresses
127.0.0.1                       localhost
197.100.1.21                    bigmouth.org    bigmouth
197.100.1.22                    suedehead.org   suedehead

here is my rc.inet1 for the 8 meg machine: (partial)

IPADDR="197.100.1.22"   # Your IP address
NETMASK="255.255.255.0" # Your netmask
NETWORK="197.100.1.0"   # Your network address
BROADCAST=""    # Your broadcast address (blank if none)
GATEWAY=""      # Your gateway address

and for the 4 meg machine:

IPADDR="197.100.1.21"   # Your IP address
NETMASK="255.255.255.0" # Your netmask
NETWORK="197.100.1.0"   # Your network address
BROADCAST=""    # Your broadcast address (blank if none)
GATEWAY=""      # Your gateway address

and my /etc/networks file:

loopback 127.0.0.0
localnet 197.100.1.0


Please help, this is really disturbing behaviour.  Is the smaller
machine crashing because of memory?

-- 
-a336dhal@cdf.toronto.edu
-bikram dhaliwal

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 09:33:24 GMT
From:      a336dhal@cdf.toronto.edu (Dhaliwal Bikram Singh)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping, eth0, WD8023, 99pl15, crashes: SOLUTION!

In article <1994Mar6.074417.17267@cdf.toronto.edu> a336dhal@cdf.toronto.edu (Dhaliwal Bikram Singh) writes:
>I am having some major problems getting my little mini-network
>setup.  I have two identical WD80x3 cards (10baseT), and I have
>hard wired the settings in the kernal:
>IO addr=0x300
>IRQ    = 9
>Memory = 0xCC00

I eventually figured out that the problems that I was having was
hard-ware related.  I went to the dianostic part of the CMOS setup
for the card, the card failed  4 of 5 memory tests, so I put the
cards memory from the low of 0xCC00 to 0xDD00.

Everything works great now.


                                                  
>
>ping -c1 suedehead.org    gives:
>ping suedehead (197.100.1.22): 56 data packets
>eth0: bogus packet, status=0x0,nxpg=0x10,size=68 
>
>I get this no matter what but only on one machine, the
>other seems fine.
>
>I think this card is a 16K card, since the DOS config for it lets
>me set it at that (it is used, don't have any manuals).
>
>I have two computers, identical except one has 8 megs , the other 4 megs.
>The 4 meg machine crashes regularily if I try to ping it from the
>8 meg machine, however the 8 meg machine never crashes regardless
>of what I do.
>
>In fact I can make the 4 meg machine crash by trying to rlogin or
>ping from the 8 meg machine.  Both are running the same kernel.
>
>here is my hosts file:
>
>/etc# cat hosts
># /etc/hosts: List of hostnames and IP addresses
>127.0.0.1                       localhost
>197.100.1.21                    bigmouth.org    bigmouth
>197.100.1.22                    suedehead.org   suedehead
>
>here is my rc.inet1 for the 8 meg machine: (partial)
>
>IPADDR="197.100.1.22"   # Your IP address
>NETMASK="255.255.255.0" # Your netmask
>NETWORK="197.100.1.0"   # Your network address
>BROADCAST=""    # Your broadcast address (blank if none)
>GATEWAY=""      # Your gateway address
>
>and for the 4 meg machine:
>
>IPADDR="197.100.1.21"   # Your IP address
>NETMASK="255.255.255.0" # Your netmask
>NETWORK="197.100.1.0"   # Your network address
>BROADCAST=""    # Your broadcast address (blank if none)
>GATEWAY=""      # Your gateway address
>
>and my /etc/networks file:
>
>loopback 127.0.0.0
>localnet 197.100.1.0
>
>
>Please help, this is really disturbing behaviour.  Is the smaller
>machine crashing because of memory?
>
>-- 
>-a336dhal@cdf.toronto.edu
>-bikram dhaliwal


-- 
-a336dhal@cdf.toronto.edu
-bikram dhaliwal

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 13:15:20 +0000
From:      elatar@comptech.demon.co.uk (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

vjs@calcite.rhyolite.com (Vernon Schryver) writes:

> In article <6sd2oaj024n@comptech.demon.co.uk> elatar@comptech.demon.co.uk writes:
> >Hmm... Interesting... I have been looking at adding an extension to TCP to
> >reside between TCP and hosts to do optional data compression/decompression
> 
> Never mind that when possible, it would be more useful to amend IP
> instead of TCP to do compression.
> 
> Note also that various people over the years have extended VJ header
> compression to use splay trees and other techniques.
> 
> I've been running a form of PPP compression, "BSD Compress," (not
> surprising if you read the draft or the IETF PPP mailing list), and I've
> been unable to measure a difference on modems with v.42bis on or off.
> They either do a little extra compression or turn their compression off.
> 
> Of course, even with link-layer compression, you still want VJ-header
> compression.
> 
> Vernon Schryver    vjs@rhyolite.com

Well After looking at the problem myself, I came to the conclusion that
there is absolutely no point at all in implementing compression at a level
lower than TCP, except perhaps when IP datagrams are having to go over a
slower link when links on either side are somewaht faster. As you say V42Bis
is very effective here. However the reason I see it as avantageous at a high
level is that you achieve compression on two fronts:

1. You reduce the amout of data being sent - of course!
2. Very usefully, you also reduce the number of packets being sent, so
   less packet header processing, while freeing up more processor time
   for the compression routines.

Also you reduce processor loading by serial interupt servicing.

At a low level, something as simple and quick as VJ header compression then
gives you throughput efficiency similar to sending compressed files via Z
modem you local BBS.

My interest is to cut down the loading caused by the increasing number of
home users on gateways, while giving a performance increase to end users.
Two conflicting needs, but two which can aided by compression at the TCP
level.

Bear in mind that on order to achieve useful compression with V42bis, your
computer<->modem baud rates have to be at least twice, and upto four times
the modem<->modem rate, this means lots of extra loading on serial
interrupts. Unfortunately, I'm not sure that serial interrupt priorities
have been appropriately upgraded in many OSs to reflect the higher baud
used.

Elatar

+------------------------------------+
| email: elatar@comptech.demon.co.uk |
+------------------------------------+


-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 15:26:52 GMT
From:      jbm@fokus.gmd.de (Joerg Micheel)
To:        comp.protocols.tcp-ip
Subject:   Multiple IP Addresses on a single Network Interface

-- 
--

"Until recently, 42 was supposed to be the answer to all questions.
 Now it's 53."

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 94 16:39:57 GMT
From:      first.ascent@mindlink.bc.ca (Alex Curylo)
To:        comp.protocols.tcp-ip
Subject:   [Q]: Best 20+ line terminal server for TCP/IP, ARA?

I'm collecting info on setting up a reasonably large (start 20 lines, plan
for 80 or so) dialin rack. Want it to run SLIP, PPP, and the usual shells,
plus I've caught snippets here and there that some new servers can also do
Appletalk Remote Access, which would be very cool indeed.

Any comments, positive or negative, on models of terminal server and methods
of accounting used with them, are welcomed. As are any other nuggets of
wisdom on hardware, software, or FAQs to do with setting up a dialup
provider.

aTdHvAaNnKcSe

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1994 20:00:30 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP and Multiple subnets on 1 Enet

In article <1994Mar4.104140.3582@vmsmail.gov.bc.ca> jaf@th.gov.bc.ca writes:

>Will ARP work to resolve a XXX.XXX.1.XXX address if the ARPing host has an
>address of XXX.XXX.2.XXX?
 ...
>Or is it that the ARPing station automatically assumes that the other
>station is not local and tries the default router.  If this is the case,
>what can be done to avoid hitting the router all the time?

On many Unix systems you can install a static route that bypasses the
router:

route add net XXX.XXX.1.0 `hostname` 0

This tells it to use itself as the gateway.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 21:11:52 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Transparent TCP/IP over X.25

In article <2ldeqh$5rb@nova.umd.edu> santhana@nova.umd.edu (Sathiya Santhana) writes:
>We are designing a network that will involve a X.25 connection between 
>two AIX RS/6000 machines (this X.25 connection will be over a satellite 
>system running at 19.2k or 56k baud).

  In general, you'd be better off running IP/Satellite directly.  The
X.25 stuff is getting in the way rather than helping you.

  Most TCP implementations lack the ability for the user to tune the
TCP timer parameters.  This is very unfortunate because over Satellite
links one usually wants different timer values than the default
values.  Similarly, success over X.25 is more likely if the timers are
tweaked.  Combining SATCOM and X.25 just enhances the need to tweak
the TCP timers.

Ran
atkinson@itd.nrl.navy.mil





-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Sun, 06 Mar 1994 22:18:15 GMT
From:      ogh@occab.win.net (Olof Haegerlund)
To:        comp.protocols.tcp-ip
Subject:   RFC 1006


Hi! 
Does anyone Know where I can get RFC1006??

Thanks!

Olof Haegerlund

Internet: ogh@occab.win.net
CompuServe: 100316.414@COMPUSERVE.com



-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 00:09:48 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?

john@iastate.edu (John Hascall) writes:

>   Well, a 536 byte datagram shouldn't be fragmented, but...

I believe it's okay to fragment datagrams of any size; the spec is that the
receiving host MUST be able to reassemble a 576-byte datagram (including
headers), and that senders should refrain from using larger datagrams
unless they know in advance that the receiver can handle them.

RFC 1051 for encapsulating IP on ARCnet required fragmenting at 253 bytes
or 508 bytes, depending on the type of hardware in use.  (That RFC is
indeed obsolete, but it was in effect for a few years.  The newer RFC added
a scheme for fragmentation and reassembly at the link layer.)

-- 
Tom Fitzgerald   Wang Labs   Lowell MA, USA   1-508-967-5278   fitz@wang.com
Pardon me, I'm lost, can you direct me to the information superhighway?


-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 10:38:16 -0600
From:      hardjosa@david.wheaton.edu (Joshua Harding)
To:        comp.protocols.tcp-ip
Subject:   Help needed w/ SLIP on Ultrix 4.3

 I am trying to install SLIP on our Ultrix system and having some
difficulties.  The first problem is that there are no real instructions on
how this should work.  My second problem is that when I try testing to see
if I can get a connection (via modem) from my Amiga, I have no reference.  I
can't tell if the problem in on the Ultrix side or the Amiga side (or both).
Ok, I suppose I might ask some more direct question if I expect a response.
Question 1:  Where can I find a decent (works and is relatively easy to
install) SLIP package for Ultrix?  Question 2: Where might I find a FAQ or
something similar to reference incase I run into trouble?
 Any help is greatly appreciated!

      The Amigo

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 15:26:44 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <6sd2oaj024n@comptech.demon.co.uk> elatar@comptech.demon.co.uk writes:
>> 
>Hmm... Interesting... I have been looking at adding an extension to TCP to
>reside between TCP and hosts to do optional data compression/decompression
>on the fly on selected data, eg directory listings, News, Mail etc...
>hopefully will be doing some tests soon. Obviously, it will only be useful
>when compression is switched off on the modem.

   That is a very dangerous assumption.  The SPECIFIC modem
   implementation of data compression makes your mileage vary a lot.

   SOME modems do a bit better job of compression--but only when they
   are talking to another modem from the same class of vendors.  Thos
   modems will provide a faster effective thruput with compression
   enabled than a poorer implementation would with it disabled.

  

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 11:03:25 -0500
From:      philp@universe.digex.net (Phil Perucci)
To:        comp.protocols.tcp-ip
Subject:   NFS over WAN?

Does NFS *always* work over the Internet?  I know it is slow...
                                           -----------------

but need to be clear on all of our options for data transfer.
Someone also mention AFS.  Does anyone know of this?

Any comments appreciated.


-- 
==============================================================================
 Phil Perucci             | "All postings are my own opinion - all comments
 Systems Programmer       |  are intended for research/educational purposes"
==============================================================================

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 03:49:42 GMT
From:      edgart@qucis.queensu.ca (Tim Edgar)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP, SNA, MAP, TOP, OSI : interoperability

I'm doing a study on the interoperability of various protocols (TCP/IP, SNA,
MAP, TOP and Oh!SI).  I need to know how complex the gateways/bridges/routers
need to be to connect any pair of protocols.

Can anyone point me to a (hopefully centralized) source?

any help is much appreciated,
Tim

edgart@qucis.queensu.ca




-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 94 04:04:13 GMT
From:      davidr@ee470.ee.mcgill.ca (Robinson David Paul Mr)
To:        comp.protocols.tcp-ip
Subject:   What is TCP/IP?

I am writing a paper that is a technical overview of TCP/IP for the layperson.
Can anyone recommend and good overview articles, books or papers here or
elsewhere that explain the basics.

Thanks.

David

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 06:23:23 GMT
From:      genie@con.Berkeley.EDU (Gene Choi)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   CSLIP with Sunos4.1.3 -- I_PUSH error


I'm trying to set up a CSLIP server on a Sparc 1 running SunOS 4.1.3.
I had it working under the same machine running SunOS 4.1.1, but recently
upgraded, breaking the server.  I added the necessary additions to
the kernel as I had done with 4.1.1, but am getting this error
when I log in:

starting slip login for slipaccount
sliplogin: I_PUSH: Not owner
   Connection closed by foreign host

So what is this deal with I_PUSH?  Anyone else successfully solved this
problem?  I'd like to hear some success stories from the net!

Oh and also, I tried modloading CSLIP instead of recompiling the kernel.
Unfortunately I got the exact same error as above.

-Gene
genie@xcf.berkeley.edu

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 16:49:35 -0600
From:      brianr@eicon.com (Brian Rheault)
To:        comp.protocols.tcp-ip
Subject:   update for ODIPKT?

Does anyone know if there is a a newer version of ODIPKT.COM 2.4 that is 
compatible with WFW 3.11. ODIPKT 2.4 just refuses to work under WFW.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 09:54:56 GMT
From:      micheel@fokus.gmd.de (Joerg Micheel)
To:        comp.protocols.tcp-ip
Subject:   Multiple IP Addresses on a single Network Interface

Hi,

I'm looking for source patches to SunOS 4.1 to support multiple
IP adresses on a single network interface. A solution similiar
to the ifconfig alias / SIOCAIFADDR mechanism in BSDI's BSD/386
(e.g. Net-2) or equivalent should be sufficient.

Thanks for any hints and pointers!
	Joerg

--

"Until recently, 42 was supposed to be the answer to all questions.
 Now it's 53."

GMD	German National Research Corporation for Mathematics and
FOKUS	Data Processing - Research Institute for Open Communication Systems
							Berlin, Germany

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 10:25:17 GMT
From:      guigon@h2.cad.cea.fr (Mr Guigon Bruno)
To:        comp.protocols.tcp-ip
Subject:   PLIP on Sun 4.1.3 ? HOW?

Bonjour,

Sometime ago, I heard about PLIP (parallel IP).
Could anyone point me to a package for SunOS 4.1.3 that can do that?

thanks in advance!
---
 ----------------------------------------------------------------- 
 Bruno Guigon           | Commissariat a l'Energie Atomique
 Guigon@h2o.cad.cea.fr  | Cadarache, France
 -----------------------------------------------------------------




-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 10:38:55 GMT
From:      huitema@mitsou.inria.fr (Christian Huitema)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <CM5v18.EzM@calcite.rhyolite.com>, vjs@calcite.rhyolite.com (Vernon Schryver) writes:

|> SLIP is just as much a standard as PPP.  SLIP has an RFC.  That PPP has
|> bunches of RFC's with half a dozen to be released this year or next does
|> not make PPP more standard, quite the contrary to rational people.
|> 

Sorry Vernon, I certainly don't want to let that pass. First and foremost, all
readers within this list should be aware that

         ********************************************************
         *   It is important to remember that not all RFCs      *
         *   are standards track documents, and that not all    *
         *   standards track documents reach the level of       *
         *   Internet Standard.                                 *
         ********************************************************

The reason why SLIP is a standard is not because it is published in an RFC,
but because that RFC (1055) is recognized as an elective Internet Standard
(standard number 47, to be precise). The fun part of this is that the June
1988 edition of RFC 1055 contains text that describes it as "A NONSTANDARD",
to the point of saying "It is not an Internet standard". In fact, SLIP belong
to a particular variety of Internet standards which where created before the
formalization of the IETF process and "grandfathered" in that process.

There are several stages in the Internet "standard track". The first
production of an IETF working group is labelled a "proposed standard" (PS).
After a period of 6 month to 2 years, the proposition can be elevated to
"draft standard" (DS). If after another 6 month to tow years period the
proposal demonstrated wide spread acceptance, implementation, industrial
usage, etc, it becomes a full Internet standard (S). The main PPP
specifications are currently at DS stage; several companion documents are at
PS stage.

PPP is a much more ambitious protocol than SLIP. Its main trust is to support
multiple protocol on a single line, which SLIP does not. This is of little use
for a modem connection, but is essential for a router to router connection
over serial lines, say a T1 line. There, you need to pass IP but also SNA,
IPX, NetBios, you name it. This is also the reason why the PPP working groups
are producing so many documents: you need to define a PPP control protocol for
each of these payloads.

Christian Huitema

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 12:03:46 GMT
From:      samson@chpi.edu.tw (Samson Chen)
To:        comp.protocols.tcp-ip
Subject:   Steven's new book!

Dear everyone,
	I bought W.R. Steven's new book, TCP/IP Illustracted, Volume 1, The 
protocols, yesterday. But I cannot find the other volumes. I'd like to know
how many volumes in the set. Have it(or those) been published or not.
Thanks.

--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
samson@chpi.edu.tw, Department of Complain Science
Chung-Hua Polytechnic Institute =|8-) <Fat Dragon>
300, Hsin-Chu, Taiwan ... eMail:samson@chpi.edu.tw

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 13:29:44 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Steven's new book!

>	I bought W.R. Steven's new book, TCP/IP Illustracted, Volume 1, The 
> Protocols, yesterday.  But I cannot find the other volumes. I'd like to know
> how many volumes in the set.  Have it (or those) been published or not?

Would you believe 7 volumes comprising 12 chapters? :-)
Seriously, Volume 1 is the only one so far.  Look for Volume 2 by
the end of 1994.  I have ideas for many more, but who knows ...

	Rich Stevens

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 22:09:49 -0500
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1006

In article <15@occab.win.net>, Olof Haegerlund <ogh@occab.win.net> wrote:
>Does anyone Know where I can get RFC1006??

ftp ftp.internic.net
cd rfc
get rfc1006.txt

--Dave
-- 
"Freedom of the press is guaranteed only to those who own one." -
A. J. Liebling

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 14:08:37 GMT
From:      bchappe@relay.nswc.navy.mil (Brett Chappell)
To:        comp.protocols.tcp-ip
Subject:   network monitoring/performance tools?

Can anyone point me to some public domain software that will
allow you to monitor tcp/ip traffic? Also, I'm interested in
any ttcp-like tools that test various network interfaces.

Thanks in advance.

Brett
bchappe@relay.nswc.navy.mil



-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 94 16:20:11 GMT
From:      daveb@jaws (David Breneman)
To:        comp.protocols.tcp-ip
Subject:   Re: What is TCP/IP?

Robinson David Paul Mr (davidr@ee470.ee.mcgill.ca) wrote:
: I am writing a paper that is a technical overview of TCP/IP for the layperson.
: Can anyone recommend and good overview articles, books or papers here or
: elsewhere that explain the basics.
: 

The bible is _Internetworking with TCP/IP Volume I; Principles,
Protocols and Architecture_ by Douglas E Comer, Prentice-Hall,
ISBN 0-13-468505-9.

--
David Breneman                        Email: daveb@jaws.engineering.dgtl.com
System Administrator,                 Voice: 206 881-7544  Fax: 206 556-8033
Product Development Platforms
Digital Systems International, Inc.        Redmond, Washington,  U. S. o' A.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 16:59:48 GMT
From:      cooker@ci.ua.pt (Fernando Cozinheiro)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware.networking,comp.sys.mac.comm
Subject:   Ethernet Address

Dear friends:

I need simple applications to get Ethernet addresses for Macintosh and
PC computers. Can anyone help me to find them?

Best regards.

--
Fernando Cozinheiro                               Email: cooker@ci.ua.pt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Universidade de Aveiro      Phone:
Centro de Informatica           Univ.Aveiro:  +351 34 370200 * Ext. 2254
3800 Aveiro                     Centro Inf.:  +351 34 370345
Portugal                    Telefax:  +351 34 28600

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 17:56:04 GMT
From:      mike@engn.uwindsor.ca (Mike Drouillard,13310,1100,s)
To:        comp.protocols.tcp-ip
Subject:   Re: How 2 give a machine 2 ip numbers


Everyone:
First, I would like to sincerely thank all those who responded to my 
email regarding "how 2 give a machine 2 ip addresses".

Suggestions ranged from a flat
"you idiot " (said politely ofcourse) 
you can't do that, use DNS Cname, to some code to modify my kernal. 

I apologize for not telling the OS I'm using. It is SunOS 4.1.3 (Solaris 1.1)
on a Sun Sparcstation 2.

I will mail this file to all who emailed me.
Thanks again everyone.

From the following list, I am going to probably upgrade my OS to Solaris 2.X
as this is a Sun Supported mechanism. 

Here then is a summary of what was suggested.

From: Berry Kercheval <kerch@parc.xerox.com>
> Well, what kind of machine *IS* it?
 
> Most machines only allow 1 IP address per netowrk interface.
 
> Why can you not just update your DNS server when you change the address?  Add > a CNAME record to point the old hostname at the new IP address.

From:  Aaron Leonard <LEONARD@Arizona.EDU>

> Your posting doesn't mention what operating system you're using
> (which in this case is significant.)  Assuming that you're using
> VMS+MultiNet, as I am, do this:
> 
>  $ mu config
>  > add pd0
>  hardware device: pd0
>  IP Address: 137.207.40.3
>  IP Subnet Mask: 255.255.x.y
> exit
 
> Then reboot.  (Note: this is an unsupported feature.)
 
> If you're running a less featureful implementation of TCP/IP, you may
> be pretty much out of luck.

From: Jochen Kornitzky <korni@shogun.ncp.sietec.de>

> Thats the problem. One interface can only belong to one IP address.
>Otherwise adress resolution (ARP) could not resolve the hardware adress.
 
> I don't see why it must be *numerically* the same adress. You just could
> use a name alias if the adress isn't hardwired anywhere. 

From Doug.McCallum@Central.Sun.COM Thu Mar  3 17:43:53 1994

> You don't mention which operating system you are using.  That is
> criticial information.  If you are using Solaris 2.x, you can add new
> pseudo interfaces quite easily.
 
> Assuming an le0 as your interface, you can add a second IP address by
> creating the file /etc/hostname.le0:1 and putting the second address
> as the contents of the file.  Then reboot.
 
> You can do things by hand with
>	ifconfig le0:1 plumb
>	ifconfig le0:1 137.207.40.3 netmask <your netmask> -trailers up


From: Stephane Bortzmeyer <bortzmeyer@cnam.cnam.fr>

> Always indicate the machine/operating system you use when you ask for help!
 
> If this is a regular Unix Berkeley machine, sorry, there's no way to do
> what you want. I changed my addresses one year ago, asked the same question 
> and got only negative replies. On Cisco routers, on the other hand, it's 
> easy :-)


From: NADEL@litc.lockheed.com (Ron Nadel)

> The best way to do this is to have your users use domain name service.  You 
> keep all the addresses in the nameserver database so they don't hard code
> anything with addresses, just names.  If you change a host's address, they
> don't see it.

From: MARK@ardsley.business.uwo.ca (Mark_Bramwell)

> 2 ip numbers is going to be tough, but you can give 2 hostnames the same ip 
> number.  If your users are using the host 'name', the DNS will respond ok.
 
> It is called the CNAME record.  That is how sites can have a central 
> machines respond to things like   newshost.uwo.ca, ftp.uwo.ca, gopher.uwo.ca 
> and they all point to the same box.

From tek@nokkonen.cs.uta.fi Fri Mar  4 07:10:10 1994


> Somehow you have to get more "interfaces" to your host. I assume you are
> talking about Unix host which is capable of routing.
> I have made similar hack few years ago. I installed SLIP driver to my
> SunOS and configured the old IP addresses to SLIP "interfaces" ( i had
> no corresponding hardware. Only SLIP "interface" drivers in kernel ).
> Then i added proxy-ARP entries to few hosts. These proxy-ARP servers
> answered the right ethernet address when someone asked the SLIP
> "interface" ethernet address :-) This way the packets destined to
> SLIP interfaces got to the right host but wrong interface (in this
> case the real ethernet interface of cource ). The kernel tries to
> route the SLIP interface destined packets to right interface and realize
> that packets are for the host itself.
> The same thing can be done nowadays with a virtual interface driver.
> I have saved an article about vif-driver from news. It is below.
> The code is also included. Hopely this helps.

	tek@cs.uta.fi
	Teppo Kuusisto

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


Article 27706 of comp.protocols.tcp-ip:
Newsgroups: comp.protocols.tcp-ip
Path: uta.fi!news.funet.fi!news.eunet.fi!dkuug!news.eunet.no!nuug!trane.uninett.no!sunic!pipex!howland.reston.ans.net!spool.mu.edu!sdd.hp.com!saimiri.primate.wisc.edu!relay!relay2!csmoko
From: csmoko@relay.nswc.navy.mil (Chuck Smoko - E81)
Subject: Re: Multiple IP Addresses on the Same Interface
Message-ID: <1993Dec31.014505.16967@relay.nswc.navy.mil>
Sender: news@relay.nswc.navy.mil
Organization: Naval Surface Warfare Center
References: <1993Dec26.074204.8193@aristo.tau.ac.il>
Date: Fri, 31 Dec 1993 01:45:05 GMT
Lines: 414

Dan,
I found this posting in my archives.  It describes just what you want.
I have it working, on Sunos 4.1.X w/ some small changes.  If you want
to runs on sunos, I can send the changes on request.

						chuck smoko

PS: I am posting because your e-mail address seems hosed, and I think
others may be interested.

> From ji Mon Feb 17 17:39:51 EST 1992
> From: ji@polaris.ctr.columbia.edu (John Ioannidis)
Subject: Multiple IP addresses on a single Ethernet interface
Date: 13 Feb 92 19:33:56 GMT
Status: OR

This is a topic that comes up once in a while on comp.protocols.tcp-ip
and other newsgroups. The question is, how to get a machine with one
network interface to respond to more than one IP addresses. 

The other day, a colleague forwarded to me a request from the
namedroppers mailing list for exactly that. Here's my response:

> In article <1992Feb1.082712.18549@mahler.ntt.jp> hitoaki@mahler.ntt.jp (Hitoaki Sakamoto) writes:
>    >In article <216@pivot.sbi.com> jordan@pivot.sbi.com (kuo-lin Hu) writes:
>    > >But it is just out of my curiousity that whether it is possible
>    > >I can assign dual IP addresses to a single controller?
 
>    >No,you can't.
> 
> Is this restriction common among UNIX TCP/IP implementations?
> Has anybody tried to modify this?
> 
> -- Kenji
> --
> Kenji Rikitake 
> kenji@macrofield.or.jp // kenji@macrofield.org // ...!uunet!reseau!kenji 

I have a solution than might suit you.  For my doctoral work (there's
a paper about it in this year's ('91) SIGCOMM, also available for
anonymous FTP from cs.columbia.edu:/pub/ji/sigcomm*.ps.Z), I've
developed what I call the "Virtual Interface" (VIF). To the networking
code, it looks like an interface. It gets ifattach()ed when you open
the /dev/vif* device, and then you can ifconfig it as you like. It
does not have an if_input procedure; it only has an if_output. Packets
that it receives (from higher-level protocols) which have its
IP address, it simply loops back (like any well-behaved if driver).
Packets that it receives that are destined for some other address, it
encapsulates in an encapsulation protocol I call IPIP (IP-within-IP,
protocol number IPPROTO_IPIP == 94), and sends it to another machine
that groks that encapsulation protocol. This feature you won't need,
but here's how to have multiple IP addresses on a machine with a
single real interface:

Let's say your primary interface's IP address is 198.3.2.1, and you
also want it to respond to addresses 198.4.3.2 and 198.5.4.3 (note
that these are three distinct class C addresses in three distinct
class C nets). Here are the ifconfigs:

  ifconfig le0 198.3.2.1 up -trailers	# config primary interface

  ifconfig vif0 198.4.3.2 up 		# config first virtual interface
  route delete net 198.4.3 198.4.3.2	# delete spurious route 
  route add host 198.4.3.2 198.4.3.2 0	# add route for this i/f

  ifconfig vif1 198.5.4.3 up		# config second virtual interface
  route delete net 198.5.4 198.5.4.3	# delete spurious route 
  route add host 198.5.4.3 198.5.4.3 0	# add route for this i/f

The route deletes are needed because the ifconfig creates a default
route to the interface's network, which can cause problems; all that's
needed is the (host) route to the interface's address. 

Now, get le0's ethernet address (say, 8:0:20:3:2:1), and add the
following static ARP entries:

  arp -s 198.4.3.2 8:0:20:3:2:1 pub
  arp -s 198.5.4.3 8:0:20:3:2:1 pub

This will cause any ARP requests for the VIF addresses to be replied
with your machine's ethernet address. 

Now, make sure your default route is to your segment's gateway,
throught the real interface. FInally, make sure your routers and/or
hosts on the same segment as yours know that 198.4.3.2 and 198.5.4.3
are on that cable. 

Here's what you've accomplished.

ARP requests for any of your host's addresses will be replied to with
the host's ethernet address (the real one, because that's what it is,
the virtual ones because of the public static arp entries). Packets
reaching your host with any of these addresses will be accepted by the
ip_input routine because they match the address of one of the host's
interfaces. Packets leaving your host can have any of its addresses
(real and virtual). 

The code for vif follows. To use it, put the stuff in netinet/if_vif.c
and netinet/if_vif.h, configure your kernel with the number of
virtual interfaces you want using a line like:

pseudo-device	vif4		# Virtual IP interface

in your configuration file, and two lines like

netinet/if_vif.c	optional vif device-driver
netinet/if_vif.hc	optional vif device-driver

in the files file. Also, add the appropriate entries in conf.c, so
that you can access the if_attach() routine when you open the device:


------------------------in conf.c------------------------------------------

add this in the appropriate place in the headers of conf.c:

--------------------
#include "vif.h"
#if NVIF > 0
int	vifopen(), vifclose(), vifread(), vifwrite(), vifselect(), vifioctl();
#else
#define vifopen		nodev
#define vifclose	nodev
#define vifread		nodev
#define vifwrite	nodev
#define vifselect	nodev
#define vifioctl	nodev
#endif
--------------------

then, way down in the definition for cdevsw[]:

--------------------
	vifopen,	vifclose,	vifread,	vifwrite,	/*31*/
	vifioctl,	nodev,		nodev,		0,
	vifselect,	nodev,
--------------------

Make sure you remember the correct major device number!

------------------------in conf.c------------------------------------------

Finally, here's the code. It has the tunneling pieces removed (you
need more code to use that anyway), and it comes from a Mach 2.6
kernel; it should compile on any berkeley-derived unix with minor
changes (most likely only in the includes). 

---------------------netinet/if_vif.h--------------------------------------
typedef struct 
{
	struct ifnet	vif_if;
	struct ifnet	*vif_sif;	/* slave interface */
	int		vif_flags;
} vif_softc_t;

#define	VIFMTU	(1024+512)
---------------------------------------------------------------------------

and
---------------------netinet/if_vif.h--------------------------------------
/*
 * HISTORY
 * $Log:$
 */
 
/*
 * $Header:$
 *
 * Virtual IP interface module. 
 */

#include <multicast.h>

#include "param.h"
#include "systm.h"
#include "mbuf.h"
#include "socket.h"
#include "errno.h"
#include "ioctl.h"

#include "../net/if.h"
#include "../net/netisr.h"
#include "../net/route.h"

#ifndef MACH
#include "../machine/mtpr.h"
#endif

#ifdef	INET
#include "../netinet/in.h"
#include "../netinet/in_systm.h"
#include "../netinet/in_var.h"
#include "../netinet/ip.h"
#endif

#ifdef NS
#include "../netns/ns.h"
#include "../netns/ns_if.h"
#endif

#include "in_pcb.h"

#include "ip_var.h"
#include "ipip.h"
#include "ipip_var.h"
#include "micp.h"
#include "micp_var.h"

#include "if_vif.h"
#include "vif.h"

vif_softc_t vif_softc[NVIF];

int vifs_inited = 0;

int	vifoutput(), vififioctl();

vifattach()
{
	register int i;
	register struct ifnet *ifp;
	
	for (i=0; i<NVIF; i++)
	{
		ifp = &vif_softc[i].vif_if;
		ifp->if_name = "vif";
		ifp->if_unit = i;
		ifp->if_mtu = VIFMTU;
#if	MULTICAST
		ifp->if_flags = IFF_MULTICAST | IFF_NOARP;
#else	MULTICAST
		ifp->if_flags = IFF_NOARP;
#endif	MULTICAST
		ifp->if_ioctl = vififioctl;
		ifp->if_output = vifoutput;
		if_attach(ifp);
	}
}

vifopen(dev, flag)
int dev, flag;
{
	int unit;
	
	if (!vifs_inited)
	{
		vifattach();
		vifs_inited = 1;
		printf("vif initialized\n");
	}
	
	unit = minor(dev);
	if ((unit < 0) || (unit >= NVIF))
	{
		return ENXIO;
	}
	
	return 0;
}

vifclose(dev, flag)
int dev, flag;
{
	return 0;
}

vifread()
{
	return ENXIO;
}

vifwrite()
{
	return ENXIO;
}

vifselect()
{
	return ENXIO;
}

vifoutput(ifp, m0, dst)
	struct ifnet *ifp;
	register struct mbuf *m0;
	struct sockaddr *dst;
{
	int s;
	register struct ifqueue *ifq;
	struct mbuf *m;
	struct sockaddr_in *din;
	
	if (dst->sa_family != AF_INET)
	{
		printf("%s%d: can't handle af%d\n", 
		       ifp->if_name, ifp->if_unit,
		       dst->sa_family);
		m_freem(m0);
		return (EAFNOSUPPORT);
	}

	din = (struct sockaddr_in *)dst;
	
	if (din->sin_addr.s_addr == IA_SIN(ifp->if_addrlist)->sin_addr.s_addr)
	{
		printf("%s%d: looping\n", ifp->if_name, ifp->if_unit);
		
		/*
		 * Place interface pointer before the data
		 * for the receiving protocol.
		 */
		if (m0->m_off <= MMAXOFF &&
		    m0->m_off >= MMINOFF + sizeof(struct ifnet *)) {
			m0->m_off -= sizeof(struct ifnet *);
			m0->m_len += sizeof(struct ifnet *);
		} else {
			MGET(m, M_DONTWAIT, MT_HEADER);
			if (m == (struct mbuf *)0)
			  return (ENOBUFS);
			m->m_off = MMINOFF;
			m->m_len = sizeof(struct ifnet *);
			m->m_next = m0;
			m0 = m;
		}
		*(mtod(m0, struct ifnet **)) = ifp;
		s = splimp();
		ifp->if_opackets++;
		ifq = &ipintrq;
		if (IF_QFULL(ifq)) {
			IF_DROP(ifq);
			m_freem(m0);
			splx(s);
			return (ENOBUFS);
		}
		IF_ENQUEUE(ifq, m0);
		schednetisr(NETISR_IP);
		ifp->if_ipackets++;
		splx(s);
		return (0);
	}

	return EHOSTUNREACH;
}

/*
 * Process an ioctl request.
 */
/* ARGSUSED */
vififioctl(ifp, cmd, data)
	register struct ifnet *ifp;
	int cmd;
	caddr_t data;
{
	int error = 0;

	switch (cmd) {

	case SIOCSIFADDR:
		ifp->if_flags |= IFF_UP;
		/*
		 * Everything else is done at a higher level.
		 */
		break;

	default:
		error = EINVAL;
	}
 return (error);
}

vifioctl(dev, cmd, arg, mode)
dev_t dev;
int cmd;
caddr_t arg;
int mode;
{
	int unit;
	
	unit = minor(dev);
	if ((unit < 0) || (unit >= NVIF))
	  return ENXIO;
	
	return EINVAL;
}
---------------------------------------------------------------------------- 

To use it, compile your kernel, and reboot. Then create the vif
device:

# mknod /dev/vif c 31 0

(or whatever major number it ended up being), and echo something into
it:

# echo > /dev/vif

This will cause the device to be opened, which will if_attach the
interfaces. If you feel like playing with the code, you may want to
kmem_alloc() the vif_softc structrure at open time, and use the minor
number of the device to tell it how many interfaces to create. 

Now you can go ahead and ifconfig etc. 

I'll be happy to answer minor questions, and hear about success and
failure stories, but I cannot help you if you don't already know how
to hack kernels.

Good luck! 

/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


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





-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 18:13:56 GMT
From:      kiran@cy.cs.olemiss.edu (Kiran)
To:        comp.protocols.tcp-ip
Subject:   help: Communication software.

I am writing a irc type communication software.
The problem is: it turned out to be a echo server and client.
I folk my server for each client connection, and am unable to write
to ALL the clients.
I have a global array of client sockts, and write() iteratively to
each of the clients. But this doesn't work. What has to be done in this 
case? 

Thanks for the help.
Kiran.
csgkk@sunvis2.vislab.olemiss.edu

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 18:38:44 GMT
From:      my00@gte.com (Michael Yuen)
To:        comp.protocols.tcp-ip
Subject:   TCP performance measurment

I want to evaluate TCP performance for several ATM switches. Are there any
methodologies, test equipment or software packages out there that I can use
to do this job?   How easily can I tweek the TCP perameters to acess
performance (i.e., propagation delay etc.). Thanks advance for any help.

-Mike

-- 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael Yuen                   Tel - (617)466-2919
GTE Labs                          Internet - my00@gte.com
40 Sylvan Road                 FAX - (617)466-2130
Waltham, MA 02254

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 19:13:39 GMT
From:      lchu@bluecross.on.ca (Louis Chu)
To:        comp.protocols.tcp-ip
Subject:   Re: Steven's new book!

In article <2lf572$as4@news.csie.nctu.edu.tw>,
Samson Chen <samson@chpi.edu.tw> wrote:
>Dear everyone,
>	I bought W.R. Steven's new book, TCP/IP Illustracted, Volume 1, The 
>protocols, yesterday. But I cannot find the other volumes. I'd like to know
>how many volumes in the set. Have it(or those) been published or not.
>Thanks.
>
>--
>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>samson@chpi.edu.tw, Department of Complain Science
>Chung-Hua Polytechnic Institute =|8-) <Fat Dragon>
>300, Hsin-Chu, Taiwan ... eMail:samson@chpi.edu.tw

 I believe it's the only one so far...great book though eh?

Lou.

-- 
Louis Chu                                              |
Technical Specialist, Ontario Blue Cross               | "Always keep you stick on the ice......"
lchu@bluecross.on.ca   --or--   uunet.ca!obc!lchu      |

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 94 19:23:08 GMT
From:      cherasar@pegasus.montclair.edu (Ken J. Cherasaro)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   BOOTPD for Solaris 2.3

Any information on the following topic would be greatly appereciated:

	I am looking for a BOOTP daemon which will run on a Sun
	box running Solaris 2.3.  I have tried compiling BOOTPD 2.1
	with no luck.  I am looking to use this for configuring PC's 
	running FTP's PC/TCP ver. 2.3.  


Thank you,
Ken J. Cherasaro

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~	Ken J. Cherasaro						~~
~~	Technical Analyst, Application Support				~~
~~	Electronic Data Systems (EDS)					~~

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 20:03:39 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

Vernon Schryver (vjs@calcite.rhyolite.com) wrote:

: (As for damage, consider what those UDP packets sent to random ports
: will do if a program on the target happen to be using that UDP
: port number.  True, it shouldn't be catastrophic, but it certainly
: isn't friendly.)

And I thought it used ICMP echo packets. I thought that was the
point of traceroute being setuid. Becuase creating an ICMP is
privileged, you can do things which are nasty.

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 21:44:09 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

> : (As for damage, consider what those UDP packets sent to random ports
> : will do if a program on the target happen to be using that UDP
> : port number.  True, it shouldn't be catastrophic, but it certainly
> : isn't friendly.)
>
> And I thought it used ICMP echo packets. I thought that was the
> point of traceroute being setuid. Becuase creating an ICMP is
> privileged, you can do things which are nasty.

It's suid root because it uses 2 raw sockets, each of which requires
superuser permission to create.  One is to read all received ICMP packets
(IPPROTO_ICMP), and the other lets it write its own *complete* IP packets,
IP header included (IPPROTO_RAW).  Traceroute normally writes its own UDP
datagrams, including the IP and UDP headers.

	Rich Stevens

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 94 22:11:25 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS over WAN?

In article <2lfj8d$q0c@universe.digex.net> philp@universe.digex.net (Phil Perucci) writes:
>Does NFS *always* work over the Internet?  I know it is slow...
>                                           -----------------
>

	Well as long as the links are up and you don't do anything
incredibly stupid like disable UDP checksums you should be okay. A big
UN*X vendor unfortunately diables UDP checksums by default. It is not
fun, but rhymes with fun, so that'll give you a clue about whose OS
does this bogosity.

	Be careful about security, use Kerberized NFS.

>but need to be clear on all of our options for data transfer.
>Someone also mention AFS.  Does anyone know of this?
>

	AFS is a hideous, horrible beast, and a real piece of sh*t! I
say this from experience! It is slow, unreliable, and the server
processes on the fileservers had to be restarted every week. (they
took 15 minutes to restart too.) It is only available for some
kernels, there is no free implementation for either servers or clients
(thus tossing interoperability out the window) and it does an evil
dynamic loading into kernel that would quite likely break if the
kernel was upgraded. An AFS filesystem can not be unmounted, trying to
do so more often than not panics the machine (at least uder Ultrix).
Client side afsd programs must always be running, and can not be
killed, even with kill -9. This makes shutdown complain, and makes
umount fail if you try to umount the fs containing the afsd cache
directory. AFS does not support sockets, named pipes (and most
probably not device files) at all. The partitions on the servers
containing the AFS filesystems can not be checked with fsck, The AFS
partitions must be checked with vfsck (an AFS tool), they are totally
non-standard. I.e. they have one file per AFS volume, which contains
inode numbers or somesuch, there is no un*x directory tree that is
directly accessible. Thus one can not access them locally as a un*x fs
like you could with an fs exported via NFS, you'd have to go through
AFS to access those files locally. That might cause conflicts or just
not be possible, the AFS site where I was did not have any servers
that were also clients. So the admins could not access the AFS files
on the servers themselves. There are serious race conditions in the
server code, server threads would often stomp on each other, crashing
the server and requiring an fs salvage operation (via vfsck), keeping
the server down for 15 minutes. At one point where I was they had a
couple of crashes per day. At UNLV we use Kerberized NFS, and the NFS
fileserver only crashed after over 200 days (!) of trouble-free
service, and this machine was also acting as a nameserver, etc. It
wasn't NFS that did it in, it was a parity error (hardware). Talk
about a major difference in reliability!

AFS, just say no!

>Any comments appreciated.
>
>
>-- 
>==============================================================================
> Phil Perucci             | "All postings are my own opinion - all comments
> Systems Programmer       |  are intended for research/educational purposes"
>==============================================================================



-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 23:24:52 GMT
From:      barryf@ulysses.iol.ie (Barry Flanagan)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q]: Best 20+ line terminal server for TCP/IP, ARA?

Alex Curylo (first.ascent@mindlink.bc.ca) wrote:
: I'm collecting info on setting up a reasonably large (start 20 lines, plan
: for 80 or so) dialin rack. Want it to run SLIP, PPP, and the usual shells,
: plus I've caught snippets here and there that some new servers can also do
: Appletalk Remote Access, which would be very cool indeed.
 
: Any comments, positive or negative, on models of terminal server and methods
: of accounting used with them, are welcomed. As are any other nuggets of
: wisdom on hardware, software, or FAQs to do with setting up a dialup
: provider.


I would highly recommend the Annex3 from Xylogics. We have a 16 port, and 
it does all we need and then some. Very reliable and easy to configure,etc.

sales@xylogics.com will get you more info.

-Barry Flanagan


--
   *********************************************************************** 
              IRELAND ON-LINE, West Wing, Furbo, Galway, Ireland
                 Tel: +353 (0)91 92727 * Fax: +353 (0)91 92726
            IOL Internet Services - Dublin: 671-5185 : Galway 92711

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 23:57:48 GMT
From:      kerch@parc.xerox.com (Berry Kercheval)
To:        comp.protocols.tcp-ip
Subject:   Re: What is TCP/IP?

daveb@jaws (David Breneman) writes:

>Robinson David Paul Mr (davidr@ee470.ee.mcgill.ca) wrote:
>: I am writing a paper that is a technical overview of TCP/IP for the layperson.
>: Can anyone recommend and good overview articles, books or papers here or
>: elsewhere that explain the basics.
 
>The bible is _Internetworking with TCP/IP Volume I; Principles,
>Protocols and Architecture_ by Douglas E Comer, Prentice-Hall,
>ISBN 0-13-468505-9.


Well, *actually*, the TCP/IP bible is the collection of RFC's.

Comer is, however, a highly regarded exegesis of them. (Hint: What is
the difference between Torah and the Pentateuch?)

I'd add a recommendation for Stevens' "TCP/IP Illustrated" for
understanding the protocols in depth.

  --berry

--

Berry Kercheval :: kerch@parc.xerox.com 
"...start with Plan 9, which is free of sin..." -Mark V. Shaney


-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 01:04:34 +0000
From:      elatar@comptech.demon.co.uk (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:

> In article <6sd2oaj024n@comptech.demon.co.uk> elatar@comptech.demon.co.uk writes:
> >> 
> >Hmm... Interesting... I have been looking at adding an extension to TCP to
> >reside between TCP and hosts to do optional data compression/decompression
> >on the fly on selected data, eg directory listings, News, Mail etc...
> >hopefully will be doing some tests soon. Obviously, it will only be useful
> >when compression is switched off on the modem.
> 
>    That is a very dangerous assumption.  The SPECIFIC modem
>    implementation of data compression makes your mileage vary a lot.
> 
>    SOME modems do a bit better job of compression--but only when they
>    are talking to another modem from the same class of vendors.  Thos
>    modems will provide a faster effective thruput with compression
>    enabled than a poorer implementation would with it disabled.
> 
>   

Well I agree with what you are saying, but my thoughts are on the lines of
compression at TCP level will yield less packets, less serial IRQ loading,
less packet processing loading, and coupled with something like VJ TCP/IP
header compression as well, will yield better throughput than even V42bis
can provide. And I think with a highly efficient algorithm, the gains made
reducing loading by the above will not be totally lost by the processor
time required for compression, thus I am hoping for an overall reduction
in processor loading as well as higher effective data throughput.

And before you say it, I am aware that V42bis does manage to sort it's self
out when having to deal with apparently uncompressable data, unlike MNP5.

And I am also aware that a number of people have allready looked at doing
compression on TCP/IP packets, but unfortuantely at IP level or lower, and
so don't benefit reducing the actual number of TCP and IP packets, and so
the overhead of dealing with them.

Elatar

+------------------------------------+
| email: elatar@comptech.demon.co.uk |
+------------------------------------+


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:57:28 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <6TymaRj024n@comptech.demon.co.uk> elatar@comptech.demon.co.uk writes:
>
>
>Well I agree with what you are saying, but my thoughts are on the lines of
>compression at TCP level will yield less packets, less serial IRQ loading,

 IRQ loading?  One thought you were talking about a REAL computer.  >:-)

>
>And before you say it, I am aware that V42bis does manage to sort it's self
>out when having to deal with apparently uncompressable data, unlike MNP5.

  Actually that was my point...even with fairly highly compressed data
  with SOME V.42bis implementations you can still gain a bit more by
  turning it on in the modems.  Some modems just don't have the cpu
  power to handle V.42bis adequately and these may be slower on some
  compressed streams.  


-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 94 05:51:16 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

In article <CMB924.M5I@aston.ac.uk> evansmp@mb48026.aston.ac.uk (Mark Evans) writes:
>Vernon Schryver (vjs@calcite.rhyolite.com) wrote:
>
>: (As for damage, consider what those UDP packets sent to random ports
>: will do if a program on the target happen to be using that UDP
>: port number.  True, it shouldn't be catastrophic, but it certainly
>: isn't friendly.)
>
>And I thought it used ICMP echo packets. I thought that was the
>point of traceroute being setuid. Becuase creating an ICMP is
>privileged, you can do things which are nasty.

	No, it does indeed use UDP packets. It builds a raw UDP
packet, since that is the only way it can change the time to live
field. There is no standard way to change the TTL of a packet, so it
has to build it from scratch. Thus it needs root priviledges.
	Why use a UDP packet instead of an (what would seem to be more
sensible at first glance, but really isn't) ICMP packet? Because ICMP
errors (including the ICMP Time Exceeded) are not sent in response to
ICMP's to prevent loops. Although it would have been nice to exclude
ICMP Echo Request and Echo Reply from packets which can not elicit an
ICMP error packet I think only ICMP error packets should not be able
to generate ICMP error packet; that would be sufficient to prevent
loops, but I digress...
	Traceroute works by sending UDP packets with increasing TTL's
and recording the IP address of the machine sending the Time Exceeded
(or Port Unreachable from the target host) to determine the route. A
kludge, but it works.
	As for safety, it is as safe as ping, telnet, or ftp, in my
opinion. If I was going to crash a net, I wouldn't use traceroute for
that job. ^:)

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 15:50:13 -0500
From:      mikeb@village.com (Are you Bunky?)
To:        comp.protocols.tcp-ip
Subject:   SLIP


Help!  If I wanted to offer slip service, ie the only thing the 
end user would need would be a 14.4 modem, what would I need on
the system operator end.  I mean I am not intrested in a leased
line 57.6k..  If the host machine is running SunOS and has
unlimited software, what would be the easiest way to provide
dial in slip?  It shouldn't require much proccessor time.  Do
i need hardware?  Software?  This is assuming I have the modems
in place.

Thanks in advance

-- mike

-- 
 
comrade@gnu.ai.mit.edu| Cyberspace is not ASCII, its concensual hallucination.
jfarnon on IRC........| "guh.  ugh. blag.  whee.  wheee."  -- confusion 
The opinions above are mine, and not of my company.

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 13:03:03
From:      john.miezitis@its.utas.edu.au (John Miezitis)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Is there an OSPF RFC ?

In article <id.5Q971.E72@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:
>From: ihsan@nmti.com (jaleel ihsan)
>Subject: Is there an OSPF RFC ?
>Date: Fri, 25 Feb 1994 16:33:33 GMT
 
>If yes, what is the number ?
 
>Thanks in advance.

RFC1247 and RFC1245.

Cheers.
--JohnM

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:35:44 -0500
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

In article <16F7394B0S86.J045820@lmsc5.is.lmsc.lockheed.com>,
 <J045820@LMSC5.IS.LMSC.LOCKHEED.COM> wrote:
>Hello , I am posting this note hoping to get some more information on DNS as
>opposed to NIS. We are a facility presently going from a IBM VM enviroment to
>a SunOs Unix enviroment.

Yay!  :-)

>We are running TCP/IP on our networks and will be
>implementing PC/nfs shortly.

Not yay.  Investigate third-party alternatives.  (I assume you mean Sun's
PC/NFS product).

>First I have heard the statement that DNS is
>going away and NIS is going to be its suvivor.  I heard this from some people
>who had attended classes for the Sun operating system. I find this hard to beli
>eve. Is this statement true or false, or does anyone have a clue?

Absolutely false.  (for starters, NIS is dying in favor of NIS+)

>using the NIS. When the master server goes down we have systems that are bound
>to it that hang. I was wondering would DNS work better for the name resoloution
>.

It would, unfortunately Sun's PC/NFS doesn't support DNS.  (Go third-party)

>I am a network type person is NIS normally handled by sysadmins?

Yes.  (as is DNS)

You should probably take a look at the Sun Admin FAQ, posted to
comp.sys.sun.admin.  (and archived on rtftm.mit.edu in 
/pub/usenet/comp.sys.sun.admin/)

--Dave
-- 
"Freedom of the press is guaranteed only to those who own one." -
A. J. Liebling

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Mar 1994  14:36 est
From:      longm@firnvx.firn.edu  (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you choose a port number for an application?

In Article <MBERG.94Jan25121019@netcom.netcom.com> "mberg@netcom.netcom.com (Mike Berg)" says:
> We are planning to release a new TCP/IP product that uses the inetd
> daemon to start new instances of its server. To properly install our
> product, we would expect the user to add an entry in the /etc/services
> file and the /etc/inetd file (in local and remote machines as
> appropriate).
> 
> Although the user could theoretically choose any unused port number
> over 1024, we would like to have a suggested default port number in
> our install instructions. 
> 
> We do not want to collide with other products, so how can we choose
> a number?  Is there some official group that assigns numbers for this
> purpose?  If not, it there some list available of the port numbers that 
> currently available software uses?
> 
> Thanks,
> Mike Berg 
> 
Mike,
You need to get RFC 1340. Assigned Numbers "AGuide to Numbers Used in TCP/IP.
This should be your >ONLY< source for port number assignment period.
MIKE.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Mar 1994  14:49 est
From:      longm@firnvx.firn.edu  (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1006

In Article <15@occab.win.net> "ogh@occab.win.net (Olof Haegerlund)" says:
> 
> Hi! 
> Does anyone Know where I can get RFC1006??
> 
> Thanks!
> 
> Olof Haegerlund
> 
> Internet: ogh@occab.win.net
> CompuServe: 100316.414@COMPUSERVE.com
> 
> 
> 
Try, merit.edu
Mike.

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 10:12:48 GMT
From:      dauphin@hubble.circe.fr (Marie-Noelle Dauphin)
To:        comp.protocols.tcp-ip
Subject:   tcpip for mac

Hello, 
I'm searching a free stack TCPIP for Mac 
someone has an idea ?
thanks a lot
Marie Noelle

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 10:26:51 GMT
From:      arsenio@uc.pt (Arsenio Monteiro dos Reis - lisbbs SU)
To:        comp.protocols.tcp-ip
Subject:   Routing problem

Hi, I've two machines, one as a SLIP server and other as a slip client,
my slip client is connected to a lan wich is connected to the internet.
From my client i can ping, telnet , ftp, ... to the server, but i can't 
reach the net connected to the server, i 've an entry in my server routing
table that specifies the route to the client, my question is how do the
server tells the net that he is the gateway to the client machine?
i tought that by running routed in the server, it inform the other net
machines to update their routing tables, but...
Any help is welcome.

--
   _
  /_|                                    arsenio@ciunix.ci.uc.pt
/   |rsenio Reis                         arsenio@lisbbs.uc.pt  
Laboratorio de Informatica e Sistemas               
Quinta da boavista lote I, 1                  
3000 Coimbra             /---------------------------------------\
Portugal                <      Living in a box, a Linux Box.      >
                         \---------------------------------------/

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 10:30:01 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

HANK@vm.biu.ac.il (Hank Nussbacher) writes:

>After I read the article I sent the following letter to the editor.
>[Only now do I see that the article has created a bit of a stir here.]
>I suggest rather than all of us complaining about the poor testbed
>we "educate" Data Communications so that they get it better the next
>time.
 
>    I have done numerous benchmarks and have indeed found that on  a
>single  segment  Ethernet  going  from  a  RAMDISK  on  a  large IBM
>mainframe to /dev/null (memory) on a fast IBM RS/6000, I was able to
>hit 4.8Mb/sec  (FTP binary  PUT).  This  might indeed  be indicative
>that TCPIP and Ethernet have a symbiosis problem when attempting  to
>reach wire speed.  Then again, everyone always says that an Ethernet
>is saturated when it hits 60% so perhaps not even the new glory  boy
>called APPC can do well on an Ethernet.


You're spreading even more misinformation.

Most current hardware/software combinations (or should I say all)
have no problem reaching wire speed over TCP/IP. 1000K/s transfers
are the rule, not the exception.


Casper

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 11:42:26 GMT
From:      samson@chpi.edu.tw (Samson Chen)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS over WAN?

Frank Lofaro (ftlofaro@unlv.edu) wrote:
: In article <2lfj8d$q0c@universe.digex.net> philp@universe.digex.net (Phil Perucci) writes:
: >Does NFS *always* work over the Internet?  I know it is slow...
: >                                           -----------------

	BSD4.4 can make NFS work under TCP protocol.

--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
samson@chpi.edu.tw, Department of Complain Science
Chung-Hua Polytechnic Institute =|8-) <Fat Dragon>
300, Hsin-Chu, Taiwan ... eMail:samson@chpi.edu.tw

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 12:03:57 GMT
From:      sherlock@netcom.com (Kevin S. Hanley)
To:        comp.protocols.tcp-ip
Subject:   Router..UNIX, DOS, OS2????

Help,
	I've been looking through Archie for information on this, but my 
searches have yielded scant information. I am looking to hook our Novell 
LAN to the Internet for E-mail.  
	I am not so familiar with UNIX, while I do know OS2 and DOS.  Is 
it possible to get a good router for our Network that uses OS2 or DOS?  
Or is setting up a UNIX machine inevitable?  Is SCO UNIX the best UNIX 
for a PC?  Does anyone sell a mailer system with its router software?

Any comments would be appreciated,

Thanks,
Kevin

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Mar 1994 11:24:13 +0100
From:      fritz@ani.univie.ac.at (fritz heigl)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address


> 
> I need simple applications to get Ethernet addresses for Macintosh and...

open MacTCP, hold the option key and klick on the Ethernet-Icon.
below there will be shown the Ethernet-Adr. of the Mac.


fritz
-----
university of vienna

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 13:09:23 GMT
From:      galileoswieng@cix.compulink.co.uk ("Galileo International")
To:        comp.protocols.tcp-ip
Subject:   Duplicate UDP Messages

Why would I ever get duplicate UDP messages if they are not broadcast.  
The only reason I can think of is a router duplicating messages across 
two links for some reason.

Regards
Antony

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 13:28:34 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: SUMMARY: Any intrinsic perfomance limit with IP protocol ?

Jochen Kornitzky <korni@shogun.ncp.sietec.de> wrote:
}And here's what the net answered (thanks to all):
 ...
}From: Peter Desnoyers <peterd@merlin.dev.cdx.mot.com>
 
}Without the large windows extension, the maximum TCP window size is
}64K. This limits one to transmitting 64K bytes during a
}single round trip time, from which you can derive a rate. Note that
}this is entirely independent of processor speed and network speed - if
}you have a 10ms round-trip delay, you'll never achieve >6.4 Mbyte/sec
}with a 64K window, even with 100-MIPS processors and gigabit networks.
 
}> BTW: Is the TCP large window option commonly used or special for some
}> implementations ?
 
}At this point in time I believe it's quite uncommon.

   I believe both DEC and SGI ship with TCP-LW now. (perhaps others?)

John

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 14:03:09 GMT
From:      kkarp@cbnewst.cb.att.com (karen.karp)
To:        comp.protocols.tcp-ip
Subject:   Finding out the IP address

how do I figure out the IP address of the server I am on?


thanks!
kkarp@attmail.com

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 12:28:00 +0100
From:      korni@shogun.ncp.sietec.de (Jochen Kornitzky)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: Any intrinsic perfomance limit with IP protocol ?


In comp.protocols.tcp-ip I wrote:

>Hi,
 
>I was told by some 'suits' :-) that IP protocol throuput/performance can be 
>increased beyond "any" limit by using highspeed (FDDI and above) wires.
>I "know" that there are certain limits in the IP protocol that apply
>especially to point to point connections but I need strong arguments.



And here's what the net answered (thanks to all):


*********

From: Berry Kercheval <kerch@parc.xerox.com>

The only inherent speed limit for IP is the speed of the medium.
Ethernet limit is 10mbps; FDDI 100, OC-3 ATM is 155, etc.

SGI, at least, has demonstrated 100mbps (minus unavoidable protocol
overhead) between two SGI machines over FDDI.



*********

From: Spencer Frink <sfrink@hpisrhs.cup.hp.com>

A great many WS vendors, including you know who :), have tcp/ip throughput
on FDDI near the theoretical 100 mbps limits.

The current "limitation" on IP and tcp is for very high bandwidth networks
with very high delay (e.g., transcontinental 45 mbps T3 links).  The various
protocol fields become exausted and the sender must wait for an ack, not fully
filling up the "pipe".

There are also a set of defined IP extensions that increase the size of these
protocol fields.  Cray has reported tcp/ip throughputs in the gbps range 
on special LANs.

So, for what you describe, 100 mbps is easily possible with FDDI.

We're optimistic that in a year or two, throughput close to this will be
possible with tcp/ip over fibrechannel for workstation users.



*********

From: Stuart Friedberg <stuartf@sequent.com>

The limits to IP "performance" are primarily checksum computation,
network per-packet losses and fragmentation/reassembly processing
at the entrance/exit of the network.  These can be vanishingly
small compared to network transmission delays.

Secondary limits involve the limited size of the IP message
identifiers, where the network latency*bandwidth product would
allow more messages in flight than the limited number of bits in
the IP identifier can distinguish.


*********

From: Peter Desnoyers <peterd@merlin.dev.cdx.mot.com>

I'd have to agree with the 'suits'. TCP without the large window
option does have an absolute upper speed on any path with a non-zero
delay, but there are no reasons why you can't increase IP speed (or
TCP with large windows) arbitrarily.

Vernon Shryver will no doubt let you know that he's done 96 or 98
Mbit/sec...



*********

From: Wayne Sung <sung@mcnc.org>

Why stop at fddi? Crays are getting _several_ hundred Mb/s over various
channels (HiPPI, for example).

The IP part normally isn't the problem, unless you consider a 32-bit address
space to be a problem (of course it isn't a performance problem). TCP does
have some issues, and these are under ongoing study.




*********

From: barnett@communications.crd.ge.com (Bruce Barnett)
[ a longish forwarded story (nice to have)

    From: Van Jacobson <van@ee.lbl.gov>
    To: tcp-ip@nic.ddn.mil
    Subject: saturating an ethernet from 1000 miles away
    Date: Wed, 05 Jun 91 07:47:44 PDT
]


*********

From: johannes@titan.westfalen.de (Johannes Stille)

[Sorry for no translation - no time for it :(  Jochen]

Streng genommen hat IP an sich _keine_ theoretische Obergrenze f|r den
Datendurchsatz. IP transportiert einfach Pakete, die vvllig unabhdngig
voneinander sind. Dadurch gibt es keine Grenze, wie viele Pakete man in
einem gegebenen Zeitraum verschicken kann. (Ein Paket kann max. 64KB
gro_ sein, aber das tut offensichtlich nichts zur Sache.) Grenzen gibt
es nur durch die Arbeitsgeschwindigkeit von Sender und Empfdnger und
durch die \bertragungsrate des Mediums.

Eine vvllig andere Sache ist TCP. TCP ist ja nur ein Protokoll, das auf
IP aufsetzt. TCP _hat_ inhdrente Beschrdnkungen. Die wichtigste ist
gegeben durch das "Window"-Feld, das nur 16 Bit breit ist. In diesem
Feld teilt der Empfdnger dem Sender (ich betrachte jetzt eine vorwiegend
einseitige \bertragung wie z.B. bei FTP, eine weitere \bertragung
gleichzeitig in Gegenrichtung ist weitgehend unabhdngig) mit, wieviel
Daten der Sender im Voraus verschicken darf, bevor der Empfdnger den
Empfang quittieren mu_. Das f|hrt dazu, da_ innerhalb einer
Round-Trip-Zeit nur 64KB Daten |bertragen werden kvnnen. Die
Round-Trip-Zeit ist physikalisch begrenzt durch Entfernung und
Signalgeschwindigkeit, die maximal gleich der Lichtgeschwindigkeit c ist
(bei Funkverbindung), in Glasfaser etwa 2/3 c betrdgt, auf Kupferkabeln
ist der Wert dhnlich. Zwei Beispiele:

100 km Entfernung, Glasfaser:
Round-Trip-Zeit 200 km / (200000 km/s) = 0.001 s
=> max. \bertragungsrate 64 MB/s

Interkontinentale Verbindung |ber _zwei_ Satellitenverbindungen (z.B.
von Europa in den pazifischen Raum):
Signal-Laufstrecke 8*36000 km = 288000 km, Geschwindigkeit 300000 km/s
=> Laufzeit etwa 1 s, max. \bertragungsrate etwa 64 KB/s

Das gilt nat|rlich nur f|r eine einzelne TCP-Verbindung, es kvnnen viele
gleichzeitig |ber einen physikalischen Link laufen.

Au_erdem gibt es schon eine Protokollerweiterung, die ein grv_eres
Window und damit hvhere Datenraten zuld_t.


Ein weiteres Problem ist die TCP-Sequence-Nummer. In einer
TCP-Verbindung ist jedes |bertragene Byte mit einer 32-Bit-Nummer
numeriert, um verspdtet eintreffende Pakete aussondern zu kvnnen. Ein
IP-Paket darf maximal 4 Minuten unterwegs sein (es kann ja in einem
Router kurz zwischengelagert werden). Wenn in diesen 4 Minuten mehr als
4 GB |bertragen werden kvnnen, ist das Protokoll nicht mehr sicher gegen
Datensalat bei verspdteten Paketen. Mvglicherweise lassen sich die 4
Minuten in Zukunft noch etwas verk|rzen, aber hier liegt eine
prinzipielle Grenze von TCP.


*********

From: Peter Desnoyers <peterd@merlin.dev.cdx.mot.com>

Without the large windows extension, the maximum TCP window size is
64K. This limits one to transmitting 64K bytes during a
single round trip time, from which you can derive a rate. Note that
this is entirely independent of processor speed and network speed - if
you have a 10ms round-trip delay, you'll never achieve >6.4 Mbyte/sec
with a 64K window, even with 100-MIPS processors and gigabit networks.

> BTW: Is the TCP large window option commonly used or special for some
> implementations ?

At this point in time I believe it's quite uncommon.

On the subject of your original question - 10mbit/sec (minus packet
overhead) has been achieved with TCP over Ethernet using 2 or 3 MIPS
machines, although it took a lot of tuning. Currently you can buy
100-MIPS machines, and soon we'll have 200 or 300-MIPS machines.
There's no reason to believe that these machines won't eventually run
TCP at 1Gbit/s over the proper networks.

[and we don't have to worry about TCP not running at a gigabit on
2-MIPS or 10-MIPS machines, because they couldn't deal with data
coming at that rate, anyway.]

*********

From: vjs@calcite.rhyolite.com (Vernon Schryver)

The 'suits' are approximately correctly.

There are no intrinsic limits to the rate at which you send or receive IP
datagrams, except those that might ultimately limit the speed of any
computation, such as limits imposed by the speed of light and the smallest
possible artifact we can make.   The human race is a long way away from
approaching those limits.

100Mbit/sec for a single TCP/IP connection is available in relatively
low cost UNIX workstations.  Several vendors can do 80Mbit/sec or more.
(Actually, the speed of light on FDDI is about 98Mbit/sec after 
accounting for headers, tokens, and so forth.)

You can buy systems that move about 1Gbit/sec using TCP/IP over
media other than FDDI.  200-500Mbit/sec is about to be common from
large system vendors.  I think Convex recent mentioned 30MByte/sec
file transfers.


*********

From: jas@talking.COM (Jim Shankland)

If the ratio of bandwidth to latency is much higher than on today's
typical TCP/IP networks, you may not be able to have a big enough
TCP window to keep the data pipe filled.  Consider a 100 Gigabit
link with a 3 second latency, and ask yourself how many unacknowledged
bytes you need to have outstanding in order not to stall waiting
for an ACK.  The TCP header has room for only a 16-bit window
size ....

*********

From: fitz@wang.com (Tom Fitzgerald)

There are no "intrinsic" limits, but things get messy as you get up into
the high-bandwidth high-delay areas, and eventually the speed of light will
get you.  As RFC 1110 points out, it's dangerous to reuse sequence numbers
within a small multiple of the round-trip-time of a connection; there's a
tiny danger that earlier packets will be duplicated, delayed, and then
reinserted into the stream the next time the same sequence number comes by.

In a couple of ways we're already near the danger zone in one area, and in
it in another.  It's <theoretically> possible for a packet to be duplicated
in the Internet and hang around for up to 2 minutes (the maximum segment
lifetime decreed by RFC 1122).  To avoid re-using sequence numbers within 2
minutes, you're limited to approximately 36 MB/sec.  If there's any risk of
packets being fragmented, then it's not 100% safe to reuse IP (16-bit)
identification values within 2 minutes, which limits you to 2^16 packets
per 2 minutes; at 536 data bytes/datagram, this is about 300 KB/sec.  Any
faster, and there's a chance that 2 packets with the same ID will be
fragmented, and the fragments of one will be duplicated and hang around
long enough to be reassembled into the other.

In reality these aren't dangers as long as you don't reuse either sequence
numbers or identification values within a small multiple of the round-trip
time of a connection.  The faster the connection is, the faster wandering
packets will have their TTL drop and expire.

*********

From: craigp@world.std.com (Craig Partridge)

jas@talking.COM (Jim Shankland) writes:

>If the ratio of bandwidth to latency is much higher than on today's
>typical TCP/IP networks, you may not be able to have a big enough
>TCP window to keep the data pipe filled.  Consider a 100 Gigabit
>link with a 3 second latency, and ask yourself how many unacknowledged
>bytes you need to have outstanding in order not to stall waiting
>for an ACK.  The TCP header has room for only a 16-bit window
>size ....

This limitation was fixed a few years ago and many TCP
implementations now support the extensions.  See RFC 1323 which defines
the window scale option and the extended sequence space.  The window
size is now 32-bits and the sequence space is now effectively 64 bits.


*********

From: tli@cisco.com (Tony Li)
    
    If the ratio of bandwidth to latency is much higher than on today's
    typical TCP/IP networks, you may not be able to have a big enough
    TCP window to keep the data pipe filled.  Consider a 100 Gigabit
    link with a 3 second latency, and ask yourself how many unacknowledged
    bytes you need to have outstanding in order not to stall waiting
    for an ACK.  The TCP header has room for only a 16-bit window
    size ....
    
Which is why RFC 1323 exists.  



*********

From: john@iastate.edu (John Hascall)


   Well, a 536 byte datagram shouldn't be fragmented, but...

   In any event, you could, of course, "safely" send 65535 datagrams
   of 65492 bytes in 2 minutes (~36MB/s).  They'd be fragmented all
   to hell, but there'd be no danger of misassembly.



*********

From: fitz@wang.com (Tom Fitzgerald)

john@iastate.edu (John Hascall) writes:

>   Well, a 536 byte datagram shouldn't be fragmented, but...

I believe it's okay to fragment datagrams of any size; the spec is that the
receiving host MUST be able to reassemble a 576-byte datagram (including
headers), and that senders should refrain from using larger datagrams
unless they know in advance that the receiver can handle them.

RFC 1051 for encapsulating IP on ARCnet required fragmenting at 253 bytes
or 508 bytes, depending on the type of hardware in use.  (That RFC is
indeed obsolete, but it was in effect for a few years.  The newer RFC added
a scheme for fragmentation and reassembly at the link layer.)


-- 
       Jochen Kornitzky
SNAIL: Sietec GmbH & Co. OHG        EMAIL:             FON: +49-30-386 28125
       Nonnendammallee 101
       D-13629 Berlin (Germany)     korni@sietec.de    FAX: +49-30-386 28321

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      08 Mar 1994 14:20:15 GMT
From:      bradley@wg.com (Doug Bradley)
To:        comp.protocols.tcp-ip
Subject:   RARP? Thundering silence...


  I posted a query about RARP examples/implementations a week ago.
Haven't heard or seen anything, and would really appreciate hearing
from anyone about it.

many many tia,
d
--
--
Doug Bradley
Wandel & Golterman Technologies
Research Triangle Park, NC   27709-3585 	USA
919-941-5730					bradley@wg.com

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 02:32:53 -0600
From:      ib@drifkoji.yy.kagu.sut.ac.jp (Igor Bakshee)
To:        comp.protocols.tcp-ip
Subject:   CSLIP on Data General AViiON?

I wonder if CSLIP 2.7 (or later?) runs on Data General Unix machines, 
particularly under DG/UX 5.4.  Is it possible to port the code for Sun?  
Any help is appreciated.

Thanks...

Igor Bakshee
ib@drifkoji.yy.kagu.sut.ac.jp



-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:11:38 GMT
From:      heimlich@kingbee.watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: SUMMARY: Any intrinsic perfomance limit with IP protocol ?

>   I believe both DEC and SGI ship with TCP-LW now. (perhaps others?)

AIX 3.2.5 ships with the large window extension as well.

Steve


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:14:48 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

agulbra@nvg.unit.no (Arnt Gulbrandsen) writes:

>In article <2lhk39$k18@mail.fwi.uva.nl>,
>Casper H.S. Dik <casper@fwi.uva.nl> wrote:
>>Most current hardware/software combinations (or should I say all)
>>have no problem reaching wire speed over TCP/IP. 1000K/s transfers
>>are the rule, not the exception.
 
>I've _never_ seen more than 920k/s over TCP/ethernet.  Have anyone
>else here?

TCP/IP Solaris 2.3 <-> Solaris 2.3  (SS10/41 -> SS10/51)

ftp> get bigfile /dev/null
200 PORT command successful.
150 Opening BINARY mode data connection for bigfile (13146536 bytes).
226 Transfer complete.
13146536 bytes received in 13 seconds (1e+03 Kbytes/s)


Same two machines ttcp:

ttcp-r: buflen=16364, nbuf=2048, align=16384/0, port=5001, sockbufsize=32728  tcp
ttcp-r: socket
ttcp-r: rcvbuf
ttcp-r: accept from xx
ttcp-r: 33513472 bytes in 31.42 real seconds = 1041.58 KB/sec +++
ttcp-r: 7261 I/O calls, msec/call = 4.43, calls/sec = 231.08
ttcp-r: 0.1user 1.2sys 0:31real 4% 0i+0d 0maxrss 0+0pf 6018+36csw

(On a not idle net)

Casper

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 17:35:15 GMT
From:      Dan Lacey <lacey@dsea.com>
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <2lf07v$ci2@sophia.inria.fr> Christian Huitema,
huitema@mitsou.inria.fr writes:
> PPP is a much more ambitious protocol than SLIP. Its main trust is to
 support
> multiple protocol on a single line, which SLIP does not. This is of
 little use
> for a modem connection, but is essential for a router to router
 connection
> over serial lines, say a T1 line. 

Little use unless you have a Mac Powerbook and want to Telnet to a UNIX
host AND access an AppleShare server over the same modem link! 

I am doing this quite often, but have to use ARA which encapsulates IP in
DDP :-(.

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:43:55 GMT
From:      ron@argus.lpl.Arizona.EDU (Ron Watkins)
To:        comp.protocols.tcp-ip
Subject:   FTP filename translation?

I have two machines I communicate with via FTP. One is a Ultrix and the other
runs VMS. When I send a file, say, abc.def.ghi.XXX.Z, the filename is
transformed into ABC.DEF$5NGHI$5N$XXX$5NZ. It seems the translation is first
to convert secondary dot characters to the string $5N. Next, if there is a
case translation in the string, it preceeds the change of case with a $ char.

This is all well and good as it allows for the proper storage of filenames on
the VAX. But when I try to retrieve these files using FTP, the naming
convention in not undone. I get back, abc.def$5nghi$5n$xxx$5nz, when I really
want back my origional name abc.def.ghi.XXX.Z.

Does anyone know why this happens and how I might undo this?
Please respond via e-mail to watkins@ssvs.gsfc.nasa.gov
			Ron Watkins
--
Ron Watkins    [ron@argus.lpl.arizona.edu]    /            /~~~~)     /
931 Gould-Simpson                            /            /____/     /
University of Arizona                       /            /          /
Tucson AZ. 85721 -- (602) 621-8606         (____ unar & / lanetary (____ ab.

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 17:50:17 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

In article <CMB924.M5I@aston.ac.uk> evansmp@mb48026.aston.ac.uk (Mark Evans) writes:
>Vernon Schryver (vjs@calcite.rhyolite.com) wrote:
>
>: (As for damage, consider what those UDP packets sent to random ports
>: will do if a program on the target happen to be using that UDP
>: port number.  True, it shouldn't be catastrophic, but it certainly
>: isn't friendly.)
>
>And I thought it used ICMP echo packets. I thought that was the
>point of traceroute being setuid. Becuase creating an ICMP is
>privileged, you can do things which are nasty.

No, Ping uses ICMP echo packets.  Traceroute sends UDP packets to a
(hopefully) unused port.  The responses are expected to be a series
of ICMP Time Exceeded messages (from the intermediate routers) followed
by an ICMP Port Unreachable message (from the target).  The reason
traceroute needs root priviledge, is that it needs a raw socket to
send pre-constructed IP headers (to set TTL, etc).

Art


-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:58:56 GMT
From:      pld@math.luc.edu (Peter Dordal)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?

In article <2l9e2o$a4c@cronkite.cisco.com>, tli@cisco.com (Tony Li) writes:
>     
>     If the ratio of bandwidth to latency is much higher than on today's
>     typical TCP/IP networks, you may not be able to have a big enough
>     TCP window to keep the data pipe filled.  Consider a 100 Gigabit
>     link with a 3 second latency, and ask yourself how many unacknowledged
>     bytes you need to have outstanding in order not to stall waiting
>     for an ACK.  The TCP header has room for only a 16-bit window
>     size ....
>     

I've been wondering about this: can it really happen?
Is there any existing situation where one can have a fast line
with this much latency?

On a single line, 3 seconds of latency should take you to the moon and
back a few times. That's a lot of wire.

If there are routers in between, then of course one could in theory have 
arbitrarily large latency times. However, in practice, doesn't a router
have to buffer all those packets?
For a router to introduce 1 sec average delay on a line with speed
1 megabyte/sec (eg Ethernet) on the input side, wouldn't that router
have to have 1 megabyte of buffer space? Multiply by N input lines,
and it seems surprising that this would be an issue in practice.
(Maybe 10 routers each introducing 0.1 sec on a T1 line?? = 15K/router??)

I don't doubt that 64K isn't always a big enough window; I'm just not
sure under exactly what conditions one runs into problems.
Suggestions, anyone?

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 18:34:24 GMT
From:      J045820@LMSC5.IS.LMSC.LOCKHEED.COM
To:        comp.protocols.tcp-ip
Subject:   DNS or NIS what do I need?

Hello , I am posting this note hoping to get some more information on DNS as
opposed to NIS. We are a facility presently going from a IBM VM enviroment to
a SunOs Unix enviroment. We are running TCP/IP on our networks and will be
implementing PC/nfs shortly. First I have heard the statement that DNS is
going away and NIS is going to be its suvivor. I heard this from some people
who had attended classes for the Sun operating system. I find this hard to beli
eve. Is this statement true or false, or does anyone have a clue?
We have only 700 PCs on our nets at this point I am presently running NIS on a
Sun Sparc 10. At this point we are doing only name resoloution on about 30 PCs
using the NIS. When the master server goes down we have systems that are bound
to it that hang. I was wondering would DNS work better for the name resoloution
. I am a network type person is NIS normally handled by sysadmins? Thanks for
the time.
                     Billy

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 94 18:38:32 GMT
From:      a09878@giant.rsoft.bc.ca (Curt Sampson)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

casper@fwi.uva.nl (Casper H.S. Dik) writes:

>Most current hardware/software combinations (or should I say all)
>have no problem reaching wire speed over TCP/IP. 1000K/s transfers
>are the rule, not the exception.

You certainly shouldn't say all. The I/O limitations of ISA bus PCs
and common 16-bit ethernet cards will let you get nowhere near wire
speed. An NE2000 will give you 400-500K/sec. on a good day.

cjs
--
Curt Sampson  a09878@giant.rsoft.bc.ca
Fluor Daniel		  604 691 5458
1444 Alberni Street				De te fabula est.
Vanouver, B.C., V6G 2Z4

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:23:35 +0100
From:      urlichs@smurf.noris.de (Matthias Urlichs)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: CSLIP with Sunos4.1.3 -- I_PUSH error

In comp.protocols.tcp-ip, article <2leh8r$abt@agate.berkeley.edu>,
  genie@con.Berkeley.EDU (Gene Choi) writes:
> 
> starting slip login for slipaccount
> sliplogin: I_PUSH: Not owner
>    Connection closed by foreign host
> 
Presumably you have to be root (or setuid-root) to push the IP access
module onto the stream.

Makes sense, actually.

-- 
CAPTAIN n. Decorative dummy found on sailboats. See FIGUREHEAD.
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:53:55 +0100
From:      agulbra@nvg.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <2lhk39$k18@mail.fwi.uva.nl>,
Casper H.S. Dik <casper@fwi.uva.nl> wrote:
>Most current hardware/software combinations (or should I say all)
>have no problem reaching wire speed over TCP/IP. 1000K/s transfers
>are the rule, not the exception.

I've _never_ seen more than 920k/s over TCP/ethernet.  Have anyone
else here?

--Arnt

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 21:23:06 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

Dan Lacey (lacey@dsea.com) wrote:
: In article <2lf07v$ci2@sophia.inria.fr> Christian Huitema,
: huitema@mitsou.inria.fr writes:
: > PPP is a much more ambitious protocol than SLIP. Its main trust is to
 support
: > multiple protocol on a single line, which SLIP does not. This is of
 little use
: > for a modem connection, but is essential for a router to router
 connection
: > over serial lines, say a T1 line. 
 
: Little use unless you have a Mac Powerbook and want to Telnet to a UNIX
: host AND access an AppleShare server over the same modem link! 

Or you want to use a mixture on IP and IPX over the connection.

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Mar 1994 19:53:23 +0100
From:      Kuypers@sri.ucl.ac.be (J.P. Kuypers)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address

In article <CMB0Jq.J8B@news.ci.ua.pt>, cooker@ci.ua.pt (Fernando
Cozinheiro) wrote:

> Dear friends:
> 
> I need simple applications to get Ethernet addresses for Macintosh and
> PC computers. Can anyone help me to find them?
> 
> Best regards.
> 
> --
> Fernando Cozinheiro                               Email: cooker@ci.ua.pt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Universidade de Aveiro      Phone:
> Centro de Informatica           Univ.Aveiro:  +351 34 370200 * Ext. 2254
> 3800 Aveiro                     Centro Inf.:  +351 34 370345
> Portugal                    Telefax:  +351 34 28600

For Macintosh: Option-click on the Ethernet icon, in the MacTCP control
panel.

Regards,

Jean-Pierre Kuypers

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 94 21:48:29 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <a09878.763151912@giant>, a09878@giant.rsoft.bc.ca (Curt Sampson) writes:
| casper@fwi.uva.nl (Casper H.S. Dik) writes:
| 
| >Most current hardware/software combinations (or should I say all)
| >have no problem reaching wire speed over TCP/IP. 1000K/s transfers
| >are the rule, not the exception.
| 
| You certainly shouldn't say all. The I/O limitations of ISA bus PCs
| and common 16-bit ethernet cards will let you get nowhere near wire
| speed. An NE2000 will give you 400-500K/sec. on a good day.

It's not as bad as all that.  I see 800+KB/sec from an ss10 to an ISA
PC (486DX50) with a generic NE2000 clone and a rather old version of the
NE2000 packet driver at that.  (This from a binary ftp get of /vmunix to
nul.)  The PC's bus is running at the typical 8Mhz.

				Dan Lanciani
				ddl@harvard.*

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 22:29:10 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

Casper H.S. Dik <casper@fwi.uva.nl> wrote:
}agulbra@nvg.unit.no (Arnt Gulbrandsen) writes:
 
}>I've _never_ seen more than 920k/s over TCP/ethernet.  Have anyone
}>else here?
 
} FTP/TCP/IP Solaris 2.3 <-> Solaris 2.3  (SS10/41 -> SS10/51)
} 13146536 bytes received in 13 seconds (1e+03 Kbytes/s)

  FTP/TCP/IP OSF/1 1.3 <-> OSF/1 1.3 (AXP3000/300l -> AXP3000/300l)
  6057672 bytes received in 5.4 seconds (1.1e+03 Kbytes/s)

  (4:20pm Monday, subnet with 33 machines.)

John

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 94 23:27:20 GMT
From:      anderson@mik.uky.edu (todd a anderson)
To:        comp.protocols.tcp-ip
Subject:   FTP/SLIP problem.

I'm currently using supertcp for Windows and my ftp sessions are terminted
by my ftp server after I've transfered over 250K of any file.  Files smaller
than 250k are transfered fine.  Anybody have any ideas on parameters to
tweak to fix this problem?

Todd


-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 23:41:06 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

In article <CMB924.M5I@aston.ac.uk> evansmp@mb48026.aston.ac.uk (Mark Evans) writes:
>And I thought it used ICMP echo packets. I thought that was the
>point of traceroute being setuid. Becuase creating an ICMP is
>privileged, you can do things which are nasty.

No, it uses UDP packets to a randomly chosen port.  From the man page:

     This program attempts to trace the route an IP packet  would
     follow  to some internet host by launching UDP probe packets
     with a small ttl (time to live) then listening for  an  ICMP
     "time  exceeded"  reply from a gateway.

I suspect this is because some routers don't send ICMP Time Exceeded
packets when dropping an ICMP Echo (ICMP errors aren't supposed to be sent
for ICMP error packets, and some routers may have misimplemented this by
not sending ICMP errors for *any* ICMP packets).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 00:35:58 GMT
From:      axb@defender.dcrl.nd.edu (Arindam Banerji)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP? Thundering silence...

I would take a look at the code described in Internetworking with TCP/IP
(Vol 2) by Doug Comer. 

 
-----------------------------------------------------------------------------
Arindam Banerji                              (219)-631-5273 (Voice)
384 FitzPatrick Hall                         (219)-631-5772 (Voice)
Dept. of Computer Science and Engineering    (219)-273-0862 (Voice)
University of Notre Dame                     (219)-631-9260 (FAX)
Notre Dame, IN 46556                         axb@cse.nd.edu (E-mail)
-----------------------------------------------------------------------------

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 02:04:26 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?

In article <2lied0$an5@apollo.it.luc.edu>, pld@math.luc.edu (Peter Dordal) writes:
|> In article <2l9e2o$a4c@cronkite.cisco.com>, tli@cisco.com (Tony Li) writes:
|> >     
|> >     If the ratio of bandwidth to latency is much higher than on today's
|> >     typical TCP/IP networks, you may not be able to have a big enough
|> >     TCP window to keep the data pipe filled.  Consider a 100 Gigabit
|> >     link with a 3 second latency, and ask yourself how many unacknowledged
|> >     bytes you need to have outstanding in order not to stall waiting
|> >     for an ACK.  The TCP header has room for only a 16-bit window
|> >     size ....
|> >     
|> 
|> I've been wondering about this: can it really happen?
|> Is there any existing situation where one can have a fast line
|> with this much latency?


Yes.  Consider a long-distance DS3 (45 Mbit/s) line with a 25ms round-
trip-time.  You would be limited to (64K / 25ms) 21 Mbit/s throughput
with a single TCP connection.

When I was in grad school I had brief access to such a line.  A DS3
was in place for the Xunet project between University of Illinios and Bell
Labs at Murray Hill.  On each side of the DS3 were DS3-FDDI routers
and SGI boxes with FDDI interfaces:

    SGI <--FDDI--> ROUTER <--------DS3 ---------> ROUTER <--FDDI--> SGI

With a single TCP connection and a 60K window (the SGI default is 60K and
at the time 64K was the limit), we didn't quite achieve the theoretical max
of 21 Mbit/s; we got about 16 Mbit/s.

After implementing RFC 1323, I jacked the window up to 250K and sustained
31 Mbit/s with a single TCP connection.

The whole exercise was merely to show that RFC 1323 was already useful at
the time (late '91 or early '92).


-- 
---
Thomas Skibo		Media Servers Division / Advanced Networking
skibo@sgi.com		Silicon Graphics, Inc.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 94 03:43:32 GMT
From:      gt0567a@prism.gatech.EDU (Mathieu Claude Hans)
To:        comp.protocols.tcp-ip
Subject:   structure of packets, any idea?

1/ I am writting a small program using UDP to send data on the internet. 
The packets will contain audio and video (raw or encoded). I am wondering
how I can structure the packets. It seems I need a header telling what
kind of data I am sending (audio or video or commands). The method of 
encoding should not be part of the header (this part is known when I
start the application, and does not change during one session).

As you can read, I only think of one feature. Does anybody think of another
one?

2/ the program is in C++, should I use a class to define a packet and use 
the inheritance property for future improvements, or should I just define
a struct (if so, should I use Unions, enums, structs of structs)?


Any pointers that would lead to interesting information would suit me as an
answer.

Thanks.
--
				=========

Mat Hans (-:


-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 12:55:04 -0500
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: structure of packets, any idea?

In article <143973@hydra.gatech.edu>,
Mathieu Claude Hans <gt0567a@prism.gatech.EDU> wrote:
>1/ I am writting a small program
>2/ the program is in C++

Isn't that sort of mutually exclusive?  :-)

--Dave
-- 
Dennis Thatcher, husband of Margaret Thatcher, when asked who wore the
pants in his house, said "I do, and I also wash and iron them."

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 94 05:32:59 GMT
From:      a09878@giant.rsoft.bc.ca (Curt Sampson)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:

>  Actually that was my point...even with fairly highly compressed data
>  with SOME V.42bis implementations you can still gain a bit more by
>  turning it on in the modems.  Some modems just don't have the cpu
>  power to handle V.42bis adequately and these may be slower on some
>  compressed streams.  

V.42bis modems are supposed to turn off their compression when they
see already compressed data (i.e., they realise that their compression
isn't making the data stream any smaller). However, the error
correction that goes along with V.42bis also uses a semi-synchronous
mode between the modems, so you can well see a 10% increase in speed
just through the dropping of the start and stop bits.

Quite frankly, to me, running compression on IP packets before sending
them off to the modem seems a bit silly, given the compression options
already available out there. But that's just me...

cjs
--
Curt Sampson  a09878@giant.rsoft.bc.ca
Fluor Daniel		  604 691 5458
1444 Alberni Street				De te fabula est.
Vanouver, B.C., V6G 2Z4

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      09 Mar 1994 06:46:39 GMT
From:      joshua@sleepy.retix.com (joshua geller)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

In article <2liuk0$8r2@bosnia.pop.psu.edu> barr@pop.psu.edu (David Barr) 
writes:
>    <J045820@LMSC5.IS.LMSC.LOCKHEED.COM> wrote:
 
>   >We are running TCP/IP on our networks and will be
>   >implementing PC/nfs shortly.
 
>   Not yay.  Investigate third-party alternatives.  (I assume you mean Sun's
>   PC/NFS product).

like which? and are there any nonproprietary alternatives that provide
the same functionality as pc/nfs (ie nfs)?

josh

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 07:45:30 GMT
From:      jel@xerver.icl.fi (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: Transparent TCP/IP over X.25

atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

>  Most TCP implementations lack the ability for the user to tune the
>TCP timer parameters.  This is very unfortunate because over Satellite
>links one usually wants different timer values than the default
>
I thought that TCPs are supposed to this kind of tweaking themselves
by estimating round-trip times, etc.  Is it really so that there are
lots of commonly used ('most'??!) implementations which use fixed
timer valuse?



-- 
Jerry Lahti             !  tel. +358-0-567 3639
ICL Personal Systems Oy !  fax. +358-0-567 5400
P.O.Box 780             !  Email: jel@xerver.icl.fi (Internet) 
00101 Helsinki, Finland !  X400:  C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Mar 1994 08:54:06 +0000
From:      dsc@sys.uea.ac.uk (Dave Cartwright)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

In article <16F7394B0S86.J045820@LMSC5.IS.LMSC.LOCKHEED.COM>,
J045820@LMSC5.IS.LMSC.LOCKHEED.COM wrote:

> We are a facility presently going from a IBM VM enviroment to a SunOs Unix
> enviroment. 
	
	Nice move ...

> We are running TCP/IP on our networks and will be implementing PC/nfs shortly.

	Is PC/NFS the result of a survey of user needs and available products ? I
only ask because in many cases people just assume that PC/NFS is the answer
to their problems. Okay, the recent versions are getting better but it's
far from perfect in my opinion. Are your PCs PC's ? I know it's a silly
question but Macintoshes are "Personal Computers". If you've got Macs that
want to access the Suns then I'd suggest that you don't want to use NFS to
do that part of it (AUFS probably).

> First I have heard the statement that DNS is going away and NIS is going
> to be its suvivor. 

	I heard somewhere that Sun are doing something about revamping NIS, but I
doubt that DNS will be disappearing. In fact we're soon to dump NIS "hosts"
maps and just use the DNS (if you use both you have two maps to update!).

> I find this hard to believe. Is this statement true or false, or does anyone
> have a clue?

	See above.

> We have only 700 PCs on our nets at this point I am presently running NIS on a
> Sun Sparc 10. At this point we are doing only name resoloution on about 30 PCs
> using the NIS. 

	What do you mean "mane resolution" ? Surely that's only within your domain
?

> When the master server goes down we have systems that are bound to it that 
> hang. I was wondering would DNS work better for the name resoloution.
> Is NIS normally handled by sysadmins?

	DNS has the concept of "secondary" servers; you choose your secondaries
wisely (including off-site machines) so that if your primary server goes
down your clients will automatically bind to one of the secondaries. So you
don't have two DNS's on the same subnet in case the gateway to that subnet
goes down, instead you have them in such places that if part of the world
dies you can probably still get to the other part(s).

	Dave

-- 
+-------------------------------------------------------------------+
|             Dave Cartwright, Macintosh Systems Manager            |
|         Computing Sector, SYS, UEA, Norwich, UK. NR4 7TJ.         |
|                    EMail: dsc@sys.uea.ac.uk                       |
|         Tel. : (0603) 592610 (DDI)     Fax : (0603) 507720        |
|                                                                   |
|          All opinions are my own unless otherwise stated.         |
+-------------------------------------------------------------------+

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 10:22:38 GMT
From:      etolrb@etn.ericsson.se (Lars Bakken)
To:        comp.protocols.tcp-ip,comp.realtime
Subject:   Serial Line IP on VRTX?


Hi,

We are planning to port VRTX with its TCP/IP executive SNX to a proprietary
MC68302 based HW unit. 

We need to run TELNET and FTP over a serial line interface using SLIP.

Later, we need to run Motif based X-clients on VRTX as well, if this is
possible.

If anybody out there has any experience in using VRTX with TNX/SNX in this kind of 
environments, we would be extremely glad if you would share your experiences 
with us.

Regards,

#######################################################################

Lars Bakken                   email: etolrb@etn.ericsson.se
Ericsson AS                   phone: +47 66 84 18 63
PO Box 34                     fax:   +47 66 98 19 15
N-1361 Billingstad
Norway                             


-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 16:10:20
From:      jack.christenson@stpaul.NCR.COM (Jack P. Christenson)
To:        comp.protocols.tcp-ip
Subject:   Packet Driver for Token Ring

Does anyone know of a packet driver for an IBM compatible token ring
adapter OTHER than the Crynwr IBMTOKEN.COM?  Or does anyone know 
how to modify it to allow frames larger than the normal ethernet limit of
1500 bytes?
If you have any ideas or advice, please post or e-mail.  Thanks.
Jack Christenson
NCR NPD
jack.christenson@stpaul.NCR.COM

 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/ Jack Christenson    AT&T GIS Network Products Division \
\ jack.christenson@stpaul.NCR.COM                        /
 \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 11:21:01 GMT
From:      rolland@cti.ecp.fr (Thierry ROLLAND)
To:        comp.protocols.tcp-ip
Subject:   IP gateway


Hi,


I am searching for a gateway that can translate IP address
My problem is :

    I have a big IP network with more than 1000 machines on 150 sites 
and I want to connect this network to the internet without changing
the internal IP addresses in the network.
I would like that people could connect to internet sites through
a gateway that translate internal IP address to a valid Internet address.

Does such stuff exists ?
Where can I find such application ?

    thank you for your help !

                                                 Thierry ROLLAND
                                              rolland@cti.ecp.fr



-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 12:13:32 +0000
From:      GeoffC@respub.demon.co.uk (GeoffC)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware.networking,comp.sys.mac.comm
Subject:   Re: Ethernet Address

> 
> I need simple applications to get Ethernet addresses for Macintosh and
> PC computers. Can anyone help me to find them?
> Fernando Cozinheiro                               Email: cooker@ci.ua.pt

I need this too please.


-- 
GeoffC

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 13:01:09 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   redundancy


I have two sites connected through a pair of routers (PPP/E1, routing
protocol = OSPF).  Is it possible to setup a second pair of routers
with another PPP link, so that no application could hang in case that
one link/router goes down?

thanks

+-------------------------------------------------------------------+
|     Antonis Kyriazis                                              |
| Networks & Communications       e-mail: antonis@intranet.gr       |
| INTRACOM sa                                                       |
| 19.5 km Marcopoulo Ave.          fax:   +30-1- 68 60 106          |
| Peania 190 02                                                     |
| GREECE                          phone:  +30-1- 68 60 122          |
| The expressed opinions are of my own     + - MACEDONIA IS GREEK - +
+-------------------------------------------------------------------+


-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Mar 1994 13:03:08 +0000
From:      mmcmullen@gsfcmail.nasa.gov (steve johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address

In article <763215212snz@respub.demon.co.uk>, GeoffC@respub.demon.co.uk
(GeoffC) wrote:

> > 
> > I need simple applications to get Ethernet addresses for Macintosh and
> > PC computers. Can anyone help me to find them?
> > Fernando Cozinheiro                               Email: cooker@ci.ua.pt
> 
> I need this too please.
> 
> 
> -- 
> GeoffC

9820-GetENetAddress will do it for mac.  don't know where you can ftp it
from, but i can send it to you or some server either by ftp or modem
(zmodem, 8n1, any speed up to 9600).

-- 
jesus left chicago
went down to new orleans...

                    - zz top

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Mar 1994 11:59:41 +0100
From:      gaeckle@sisc.ucl.ac.be (A.Gaeckle)
To:        comp.protocols.tcp-ip
Subject:   routing IP via macintosh

There is for pc a software like that called PCROUTE which is freeware.

I would like to know if there is a software for macintosh routing IP
packets ?


Thank's a lot.

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 13:49:43 GMT
From:      vanrein@cs.utwente.nl (Rick van Rein)
To:        comp.protocols.tcp-ip
Subject:   NFS in PD?


Does anybody know if NFS sources are PD and where? Or, even better,
can if get executables for the Commodore Amiga I use to access a Unix network?
And, most interesting to, is NFS standardized?

With love from Enschede,

Rick van Rein

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 14:27:20 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <CM5v18.EzM@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
   SLIP is just as much a standard as PPP.  SLIP has an RFC.  

But that RFC itself disclaims any standard status:

	Network Working Group                                        J. Romkey
	Request for Comments: 1055                                   June l988

	A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP
	...
	SLIP, Serial Line IP, is a currently a de facto standard, commonly
	used ... It is not an Internet standard.
	...
	Because there is no 'standard' SLIP specification, there is no real...
	
I agree that "de facto" standards (those enjoying wide popularity but
without the imprimatur of a formal sanctioning body like ISOC, CCITT,
EIA, ANSI, etc.) are valuable, but "just as much a standard" is
stating it a bit too strongly.

   PPP does have a link-layer checksum ...

Unless it negotiates Honeyman's Null FCS, in which case the frame
format becomes just SLIP with a leading type byte.

   ...that most varients of SLIP do not...

What variant of SLIP has a link-layer checksum?  If it has a checksum,
is it really SLIP?
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 14:36:20 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on client-server implementation ..

Sandeep Kamat (sandeep@newsservercs.uwindsor.ca) wrote:

:   There is a database on a machine  which has inforamtion concerning certain
:   topic.Also a set of queries are setup on this database.Aserver is running
:   on this machine which accpets connections form other machines over the
:   internet.
:    The users connecting to this server is given a choice of these queries
:   and corresponding to the query posed is answered by the database and the
:   answer is delivered to the user.

Depending on the complexity of the database, remote access needs, and
how much time you have to work on it, I would think that some combination
of the 'gopher', 'wais', and 'http' protocols would do the trick quite
nicely.

See the Usenet newsgruops 'comp.infosystems.gopher', 'comp.infosystems.www',
and 'comp.infosystems.wais' (roughly in that order).  Or ask on campus
about gopher services; or ftp to 'hopf.math.nwu.edu' for a copy of 'gn',
a gopher server for unix.

--Ed

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 14:42:34 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway

Thierry ROLLAND (rolland@cti.ecp.fr) wrote:

:     I have a big IP network with more than 1000 machines on 150 sites 
: and I want to connect this network to the internet without changing
: the internal IP addresses in the network.
: I would like that people could connect to internet sites through
: a gateway that translate internal IP address to a valid Internet address.

These boxes (called something like Network Address Translators, or NATs)
have been described as a possible transition step to next generation IP
protocols, but as far as I know they have not been built.

Short of renumbering, I would guess that you may be able to accomplish
some subset of what you want to really do by implementing a "firewall",
which will include application level gateways that allow inside hosts
to get to outside services without being directly on the Internet themselves.
A starting place to look for that is on the ftp site
	ftp.greatcircle.com:/pub/firewalls
which houses the 'firewalls' mailing list and archives of code, product
descriptions and reviews.

I would be inclined to recommend that you prepare for a great renumbering
in any case, at least in terms of having real IP addresses assigned to you,
since if this net is ever multiply connected via other private lines to
other sites using Internet protocols the firewall situation starts to
get more complex.

--Ed

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 15:20:47 GMT
From:      sjs@ulysses.att.com (Steve Silverman[smb] MT 3F-114)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Course

Course:         DC2244 - TCP/IP
Location:       Pleasanton, California
Date:           April 12-13 
Session:        9:00 - 4:00
Tuition:        $675.00
Registration:   1-800-TRAINER (prompt 3)
Instructor:     Dr. Steven J. Silverman, Member of Technical Staff AT&T
                Bell Laboratories, Technical Education
 
Course open to all people who have an interest in the protocol suite
TCP/IP
 
This lecture course describes the set of computer networking protocols known
as TCP/IP (Transmission Control Protocol/Internet
Protocol). The course covers information for the professional who utilitizes
computer networks and needs to know the principles
 of Internet technologies which provides both LAN and WAN connectivity. The
TCP/IP suite of protocols includes application prot
ocols for operations such as file transfer, remote login, and network
management. Text book included in course materials.
 
        -Architectural Model            -Underlying Network Technologies
        -Internetworking Concepts       -Internet Addresses
        -Protocol Layering              -Internet Protocol
        -User Datagram Protocol         -Mapping Internet Addresses to LANs
        -Routing                        -Reliable Transport Service (TCP)
        -Client-Server Model            -Domain Name System
        -Remote Login (TELNET)          -File Transfer Protocol (FTP)
        -Electronic Mail (SMTP)         -Internet Management (SNMP)
        -Global Internet (WAIS, Gopher, WWW, Xmosaic)
 
also included:
        >>>>>>>>   HANDS on DEMOS of TCP/IP     <<<<<<<<<<
        >>>>>>>>   Security and TCP/IP     <<<<<<<<<<
        >>>>>>>>   TCP/IP Book, Washburn,Evans <<<<<<<<<<<
        >>>>>>>>   Performance and Fine Tuning     <<<<<<<<<<




-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 16:46:04 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

In article <1994Mar8.055116.6791@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>	Why use a UDP packet instead of an (what would seem to be more
>sensible at first glance, but really isn't) ICMP packet? Because ICMP
>errors (including the ICMP Time Exceeded) are not sent in response to
>ICMP's to prevent loops. Although it would have been nice to exclude
>ICMP Echo Request and Echo Reply from packets which can not elicit an
>ICMP error packet I think only ICMP error packets should not be able
>to generate ICMP error packet; that would be sufficient to prevent
>loops, but I digress...

While the original ICMP RFC (792) states:

   The ICMP messages typically report errors in the processing of
   datagrams.  To avoid the infinite regress of messages about messages
   etc., no ICMP messages are sent about ICMP messages.  Also ICMP
   messages are only sent about errors in handling fragment zero of
   fragemented datagrams.  (Fragment zero has the fragment offeset equal
   zero).

RFC-1009 states:

   2.2.  Internet Control Message Protocol (ICMP)

      ICMP is an auxiliary protocol used to convey advice and error
      messages and is described in RFC-792 [2].

      We will discuss issues arising from gateway handling of particular
      ICMP messages.  The ICMP messages are grouped into two classes:
      error messages and information messages.  ICMP error messages are
      never sent about ICMP error messages, nor about broadcast or
      multicast datagrams.

         The ICMP error messages are: Destination Unreachable, Redirect,
         Source Quench, Time Exceeded, and Parameter Problem.

         The ICMP information messages are: Echo, Information,
         Timestamp, and Address Mask.

The Host Requirments RFC (1122) states:
(and the Router Requirements drafts says the same thing)

         ICMP messages are grouped into two classes.

         *
              ICMP error messages:

               Destination Unreachable   (see Section 3.2.2.1)
               Redirect                  (see Section 3.2.2.2)
               Source Quench             (see Section 3.2.2.3)
               Time Exceeded             (see Section 3.2.2.4)
               Parameter Problem         (see Section 3.2.2.5)


         *
              ICMP query messages:

                Echo                     (see Section 3.2.2.6)
                Information              (see Section 3.2.2.7)
                Timestamp                (see Section 3.2.2.8)
                Address Mask             (see Section 3.2.2.9)

	.
	.
	.
 
         An ICMP error message MUST NOT be sent as the result of
         receiving:
 
         *    an ICMP error message, or
 


So responding to ICMP Echo with ICMP error messages has been sanctioned
for quite a while.

Art


-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 17:21:50 GMT
From:      evansmp@mb48025.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages

Galileo International (galileoswieng@cix.compulink.co.uk) wrote:
: Why would I ever get duplicate UDP messages if they are not broadcast.  
: The only reason I can think of is a router duplicating messages across 
: two links for some reason.

Retransmission with a fault on the interface between the IP level and
a lower level, possibly?

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 17:31:34 GMT
From:      evansmp@mb48025.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

Dave Cartwright (dsc@sys.uea.ac.uk) wrote:

: far from perfect in my opinion. Are your PCs PC's ? I know it's a silly
: question but Macintoshes are "Personal Computers". If you've got Macs that

Also a valid question is what operating system are they running?

: want to access the Suns then I'd suggest that you don't want to use NFS to
: do that part of it (AUFS probably).
 
: > First I have heard the statement that DNS is going away and NIS is going
: > to be its suvivor. 
 
: 	I heard somewhere that Sun are doing something about revamping NIS, but I
: doubt that DNS will be disappearing. In fact we're soon to dump NIS "hosts"

It is quite possible to have a setup where the NIS server does a DNS lookup
in response to hostname/number queries.

: maps and just use the DNS (if you use both you have two maps to update!).
 
: > When the master server goes down we have systems that are bound to it that 
: > hang. I was wondering would DNS work better for the name resoloution.
: > Is NIS normally handled by sysadmins?
 
: 	DNS has the concept of "secondary" servers; you choose your secondaries
: wisely (including off-site machines) so that if your primary server goes
: down your clients will automatically bind to one of the secondaries. So you
: don't have two DNS's on the same subnet in case the gateway to that subnet
: goes down, instead you have them in such places that if part of the world
: dies you can probably still get to the other part(s).

This is an implimentation issue, NIS also supports "secondary servers".
In most DNS implimentations I have seen there is
a list (of up to 3) nameservers to try. In most NIS implimentations an
approach of send a broadcast and see what responds first is used.
I can see little reason why NIS could not use a list of servers to try, in
situations such as not having a NIS server on the same subnet a system of
broadcast discovery may not work or DNS using broadcast discovery. Or that
some combination, e.g. use a broadcast to attempt to find a local server if 
no response try a list of servers.

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 94 18:44:03 GMT
From:      rk@myan.uc.edu (Ramaswamy Krishnan)
To:        comp.unix.aix,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   ENET_SET_MULTI: No Space Left on Device

We get the message "ENET_SET_MULTI: No Space Left on Device" when
we start UAR (Unix Appletalk Router) on our RS/6000 AIX 3.2.0.

I guess this is because UAR sees too many mac-zones (?) as we do
not have a hardware appletalk router right now.

Can anyone suggest a workaround/solution ?

- can max. multicast addresses (10) on AIX ethernet driver be increased?
- can UAR be configured in some way to restrict the number of zones?

--
Ramaswamy Krishnan
rk@myan.uc.edu

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 19:07:59 GMT
From:      len@forge.Tandem.COM (Len Fishler)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages

In article <CMEqwF.M1n@aston.ac.uk>, evansmp@mb48025.aston.ac.uk (Mark Evans) writes:
>Galileo International (galileoswieng@cix.compulink.co.uk) wrote:
>: Why would I ever get duplicate UDP messages if they are not broadcast.  
>: The only reason I can think of is a router duplicating messages across 
>: two links for some reason.
>
>Retransmission with a fault on the interface between the IP level and
>a lower level, possibly?

Others include temporary routing loops, multiple bridges between two
segments (either incorrectly configured, or in a temporary duplicated
path condition due to spanning tree re-configuration), bugs in software
or hardware, incorrect router configurations, etc...

- Len Fishler -
fishler_len@tandem.com

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 19:09:48 GMT
From:      sac@oti-hsv.com (Scott Cechovic)
To:        comp.protocols.tcp-ip
Subject:   CSLIP causes kernel panic - help!

[ Article crossposted from comp.sys.sun.admin ]
[ Author was Scott Cechovic ]
[ Posted on 9 Mar 1994 19:08:30 GMT ]


I recently obtained cslip-2.7 and have been trying to install it.  Everything
seems to come up OK until I execute a telnet or ftp and then the kernel panics.
I have been able to ping remote hosts, but that's it.  I did not load and 
install the tahoe BSD release and I hacked the slip.login to use the ifconfig 
that came with cslip.  I'm running on a SPARC 2 with SunOS 4.1.3.  Is there 
some kind of Sun patch that I am missing???

Thanks,
Scott

-- 

+=================================()=====+
|                                   0    |
|               ()        +--------. o   |
|                ()   ---. \ ) ) *  \ *  |
|     +--------.  0      |>-> ) ) )  o   |
| ---. \ ) ) *  \ *     -' / ) ) )  /    |
|    |>-> ) ) )  o        +--------'     |
|   -' / ) ) )  /                        |
|     +--------'                         |
|                                        |
| Scott A. Cechovic                      |
| Optimization Technology, Inc.          |
| 5021 Technology Dr., Suite 1A          |
| Huntsville, AL 35805                   |
| email: scott.cechovic@oti-hsv.com      |
| Ph: (205)721-1288  FAX: (205)837-9682  |
+========================================+

--

+=================================()=====+
|                                   0    |
|               ()        +--------. o   |
|                ()   ---. \ ) ) *  \ *  |
|     +--------.  0      |>-> ) ) )  o   |
| ---. \ ) ) *  \ *     -' / ) ) )  /    |
|    |>-> ) ) )  o        +--------'     |
|   -' / ) ) )  /                        |
|     +--------'                         |
|                                        |
| Scott A. Cechovic                      |
| Optimization Technology, Inc.          |
| 5021 Technology Dr., Suite 1A          |
| Huntsville, AL 35805                   |
| email: scott.cechovic@oti-hsv.com      |
| Ph: (205)721-1288  FAX: (205)837-9682  |
+========================================+

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 19:21:36 GMT
From:      gm@informatik.uni-rostock.de (Guenter Millahn)
To:        comp.dcom.lans.ethernet,comp.protocols.tcpip.ibmpc,comp.protocols.tcpip,comp.protocols.pcnet
Subject:   WANTED: Packet driver for SMC 8216 Network Adaptor

[ Article crossposted from comp.binaries.ibm.pc.wanted ]
[ Author was  ]
[ Posted on Wed, 9 Mar 1994 12:44:15 GMT ]

Hi all!

I'm looking for a PD/free/Shareware packet driver for the SMC8216 because
I want to use some netprogs who need this. The SMC_WD driver from the Crynwr
collection doesn't work with this card.
Also welcome are hints regarding to a driver emulation like dis_pkt.zip.

Is there anybody who can help me ???
Please answer via email.

Thank you very much.
Guenter
--
Guenter Millahn, Systems and Network Administrator
Technical University of Cottbus, Computer Science Department

--
Guenter Millahn, Systems and Network Administrator
Technical University of Cottbus, Computer Science Department

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 19:24:16 GMT
From:      dyck@mprgate.mpr.ca (Trevor Dyck)
To:        comp.protocols.tcp-ip
Subject:   embedded TCP/IP solution

Hi there, 

I am looking for an embedded TCP/IP product that can be used with the Motorola
68K series of processors.  Source code would be nice, but not necessary.  Note
this does not have to be a free type of product.

Thanks for any info,
Trevor.

PS.  Has anyone heard of USNet by US Software?  Where can I get info on this?

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 94 19:42:24 GMT
From:      gt0567a@prism.gatech.EDU (Mathieu Claude Hans)
To:        comp.protocols.tcp-ip
Subject:   Sizes of UDP packets.

The RFC 768 (User Datagram Protocol) does not talk about size limitations
for the embedded data. But if you look at HP's manual, they decided:

"The maximum message size for a UDP datagram socket is 58254 bytes.
      The default message size is 9216 bytes. "

Do all systems have a lower and an upper bound for the message
size? Why a lower bound? is it because of their machines or because of
routers, or something out there on the Internet?

If you wanted to send packets as fast as possible (therefore not wanting 
routers to break them up, or something like that) what size would you
consider?


--
Mat Hans (-:
PhD candidate - estimated graduation year 1998....
Georgia Tech, school of Electrical and Computer Engineering 
Internet: 	gt0567a@acme.gatech.edu

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 19:46:53 GMT
From:      jhorn@snake1.cs.wisc.edu (Jeffrey Horn)
To:        comp.protocols.tcp-ip
Subject:   Anyone heard of NetCom???

Has anyone heard of an Internet provider called NetCom?  Better yet, 
is anyone actually using their service?  I am helping a company get
connected to the internet and NetCom charges only $400/month for a
class C frame relay connection while most others (AlterNet, etc.) charge
nearly three times that amount.  I want to know what the catch is, or 
if this deal is really as good as it sounds.

Thanks for your help, 

Jeffrey Horn
horn@cs.wisc.edu


-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 19:49:59 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

I wouldn't consider the FTP time valid. I have seen
rates that are higher than theoretical maximum.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 19:58:58 +0100
From:      urlichs@smurf.noris.de (Matthias Urlichs)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In comp.protocols.tcp-ip, article <a09878.763191179@giant>,
  a09878@giant.rsoft.bc.ca (Curt Sampson) writes:
> 
> V.42bis modems are supposed to turn off their compression when they
> see already compressed data (i.e., they realise that their compression
> isn't making the data stream any smaller). However, the error

Unfortunately, given one compressed and one uncompressed data snippet,
the two concatenated might still be compressible. Less compressible than
both snippets in uncompressed form, of course.

> correction that goes along with V.42bis also uses a semi-synchronous
> mode between the modems, so you can well see a 10% increase in speed
> just through the dropping of the start and stop bits.
> 
That's V.42. You can turn off V.42bis but leave V.42 on in most if not all
modems.

> Quite frankly, to me, running compression on IP packets before sending
> them off to the modem seems a bit silly, given the compression options
> already available out there. But that's just me...
> 
... and given the CPU load to compress these things -- unlike specialized
stuff like VanJ header compression, generic compression tends to be rather
slow, and it'd make more sense to implement it in some outside box that
doesn't have anything better to do than to move a few characters from point
A to point B and vice versa (i.e., a modem ;-) than in the Unix box which
presumably has better things to do.

-- 
Lord, give me patience -- now!
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 23:43:33 GMT
From:      schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder)
To:        comp.lang.tcl,comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   ANNOUNCE: tkined-0.9 & scotty-0.9 now available

A new release of our network editor tkined is now available on
ftp.ibr.cs.tu-bs.de [134.169.34.15]. The files are:

	/pub/local/tkined-0.9.tar.gz
	/pub/local/scotty-0.9.tar.gz

(No, you did not miss tkined-0.8. This was just an internal release.)

If you are going to the CeBIT computer exhibition in Hannover, Germany
(16.3.-23.3), you are welcome to visit us in hall 22 stand-no. C34. We
will show tkined and scotty plus our network simulator simuLan (which
uses tkined as a user interface) and some other neat stuff. I would be 
very happy to meet and talk with tkined `users'.


Whats new in tkined-0.9 ?

	- running monitoring jobs can be restarted when loading
	  a previously saved tkined map

	- stripchart and barchart widgets are resizable

	- stripcharts and barcharts can be scaled

	- the label tool has been turned into an alter tool

	- networks with one segment are resizable

	- a somewhat more consistent layout of the editor menus

	- legal and letter page sizes

	- lots of fixes


Whats new in scotty-0.9 ?

	- scotty is now running in its own eventloop (making after
	  and addinput commands possible)

	- a simple rpc mechanism between scotty interpreters

	- added Poul-Henning Kamp's SNMP implementation

	- a graph layout algorithm for discovered networks

	- some basic SNMP monitoring and troubleshooting scripts


What is tkined?

tkined is a drawing program that allows you to create maps of your
network configuration. But the most important feature of tkined is its
tcl-based programming interface that can be used to turn the editor
into a network management system. tkined provides commands to present
status information in stripcharts or barcharts.


And what about scotty?

scotty is a tcl interpreter that has extensions to set up TCP
connections, to submit ICMP packets and to query various RPC services.
Included are some sample scripts for troubleshooting your network
(ping, traceroute, finger, query tcp services, query RPC services),
for monitoring network status and to discover and layout your IP
network map.

This version also includes P.H. Kamps SNMP interface. There are
scripts to dump routing tables, to query interface status and to
monitor SNMP variables. Although we are planning to replace this
version with a SNMPv2 version in the future, I think that the SNMP
capability will be of interest to you.


Where do I report bugs and suggestions?

If you have problems or if you have made any changes to run tkined and
scotty on your hardware or if you have found any bugs, please contact
us. You are also invited to join our tkined mailing list.  To join,
send a request to tkined-request@ibr.cs.tu-bs.de. Messages that are to
be distributed by the list should be send to tkined@ibr.cs.tu-bs.de.

						Juergen


-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 23:59:58 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway

In article <2lkbet$7an@piston.ecp.fr> rolland@cti.ecp.fr (Thierry ROLLAND) writes:
>I am searching for a gateway that can translate IP address

This is hard to do in general, since many protocols include IP addresses in
the data portion.

You may be able to do it for selected protocols by using the proxy server
software from the TIS firewall toolkit.  Look for this on ftp.tis.com.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 13:20:57 -0800
From:      mahboud@aggroup.com (Mahboud Zabetian)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address

In article <CMGnuA.2tr@avalon.chinalake.navy.mil>, Tony Andreoli
<Tony_Andreoli_-_CTA@CL_63SMTP_GW.CHINALAKE.NAVY.MIL> wrote:

> In article <CMB0Jq.J8B@news.ci.ua.pt> Fernando Cozinheiro,
> cooker@ci.ua.pt writes:
> >I need simple applications to get Ethernet addresses for Macintosh and
> >PC computers. Can anyone help me to find them?
> 
> On the Mac, use GetMyAddress (I think it's at Sumex).
> 
> Tony Andreoli

The one at Sumex is old (last I checked).  Get the one off of
ftp.aggroup.com.

-mahboud
---------------------------------------------------------------
Mahboud Zabetian
mahboud@aggroup.com
ag group, inc.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 09:15:42 -0500
From:      shuford@cs.utk.edu (Richard Shuford)
To:        vmsnet.pdp-11,vmsnet.networks.tcp-ip.tcpware,comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: TCP/IP for an 11/44?

In article <2livgs$q13@news.u.washington.edu>,
    Brent Holterman  <bholt@u.washington.edu> writes:
>
>   Does anyone out there know of any (preferably inexpensive) solutions
>   which allow a DEC PDP-11/44 to understand TCP/IP and Telnet?
>
>   Platform:          PDP-11/44 (unibus)
>   Operating System:  RSX-11M-PLUS V4.2
>
>   Thanks,  Brent     (+1 206/685-2191)

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

The question about TCP/IP for the PDP-11 appears frequently in the
Info-PDP11 forum.  The only question more frequent is "How do I get
Unix for my PDP-11?"

The "TCPware" TCP/IP implementation for PDP-11 is a commercial product of

    Process Software, Inc.
    959 Concord Street
    Framingham, Massachusetts 01701  USA
    IDDD voice:  +1 508/879-6994
    WATS voice:     800/722-7770
    IDDD fax:    +1 508/879-0042

    Internet:    sales@process.com

Process Software sells TCPware TCP/IP for VAX/VMS, AXP/OpenVMS, and
the PDP-11 operating systems RSX, RT-11, IAS, and TSX.

Be advised that the PDP-11 products are rather bare-bones:  they perform
Telnet and FTP sufficiently, but they do not do such handy things as
respond to ICMP messages (ping).  (TCPware for VMS, however, provides a
fuller set of functions, including SLIP.)

There also exists a network newsgroup to discuss the Process Software
products:  "vmsnet.networks.tcp-ip.tcpware".  News feeds of the VMSnet
groups are widely available.

At my workplace, we have the Process Software TCPware TCP/IP product on
our RSX-11m+ system.  It performs adequately on our private network,
although some sites have reported routing difficulties on the Internet.

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

John Clayton <clayton@c-c.com> wrote me last July to say:
>
>   There is another TCP/IP for RSX available from our company.  It costs
>   $4495 for both a full TCP/IP software set and an EXOS Intelligent
>   Front-End Ethernet Processor.
>
>   Claflin & Clayton, Inc.
>   203 Southwest Cutoff
>   Northboro, MA 01532, USA
>   Voice: +1 508-393-7979
>   Fax:   +1 508-393-8788

The last price I heard quoted for TCPware was somewhat less.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-- 
...Richard S. Shuford  |"He who oppresses the poor to increase his wealth and
...shuford@cs.utk.edu  | he who gives gifts to the rich--both come to poverty."
...Info-Stratus contact| Proverbs 22:16  NIV

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 94 08:04:55 PDT
From:      Stephen Heilbronner <heilbron@isar.muc.de>
To:        comp.protocols.tcp-ip, gt0567a@prism.gatech.EDU
Subject:   Re: Sizes of UDP packets.


In article <144158@hydra.gatech.EDU>, <gt0567a@prism.gatech.EDU> writes:
> The RFC 768 (User Datagram Protocol) does not talk about size limitations
> for the embedded data. But if you look at HP's manual, they decided:
> 
> "The maximum message size for a UDP datagram socket is 58254 bytes.
>       The default message size is 9216 bytes. "
> 
> ...
> If you wanted to send packets as fast as possible (therefore not wanting 
> routers to break them up, or something like that) what size would you
> consider?
 
Since some MS-DOS based TCP/IP implementations (like PC-NFS by SUNSoft)
only support 1024 bytes I'd recommend that. On the other hand the *NIXes
I know about support at least 8K.

> Mat Hans (-:

Stephen Heilbronner
<heilbron@isar.muc.de>

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 09:28:28 -0400
From:      lhowie@prograph.com (Les Howie)
To:        comp.protocols.tcp-ip
Subject:   Re: Steven's new book!

In article <1994Mar7.132944.8268@noao.edu>
rstevens@noao.edu (W. Richard Stevens) writes:

> Would you believe 7 volumes comprising 12 chapters? :-)
> Seriously, Volume 1 is the only one so far.  Look for Volume 2 by
> the end of 1994.  I have ideas for many more, but who knows ...
> 
>         Rich Stevens

Would you be so good as to post a blurb, maybe a table of contents?  I
would like to learn a bit about programming TCP, maybe write a
newsreader or telnet to verify that I know what I am doing.  Does your
book cover what I would need to know?  Any others you recommend if not?
 If its all in RFC's, how do I find the right one?

Does this newsgroup have a FAQ for newbies sauch a I? :-)}}

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 11:40:28 -0500
From:      kenton@navaho.cc.bellcore.com (gidewall,kenton c)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.misc
Subject:   TCP-IP on a VAXstation

This is a VMS question:

My company needs to run tcp-ip on some VAXstation 3100 model 76s.  We
have been told that DECNET/OSI has tcp-ip included in it.  All you have
to do is turn it on and you have tcp-ip.  We haven't put DECNET/OSI on
our clusters yet (soon), so we can't verify that.  However, someone else
told us that the tcp-ip with OSI isn't a full-blown version and we won't
be able to do all the things we could with a 3rd-party version of tcp-ip.

My question is:  Who is right?  If we have DECNET/OSI on our machines are
we all set?  Or would we be better off with a full-blown 3rd-party vendor's?

Also, assuming we need a 3-rd party vendor product, who are the players in
the tcp-ip market and what are the pros and cons of each product?  
(If this is in a FAQ somewhere, please point me in the right direction).

Thanks for any help you can give me.  Also, if you post to the newsgroup,
please send me a copy via e-mail also, since our newsfeed tends to be
slow.

Thanks!

Kenton Gidewall 
kenton@cc.bellcore.com

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 94 03:36:04 GMT
From:      amolitor@blefscu.network.com (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway

In article <2lkbet$7an@piston.ecp.fr>, rolland@cti.ecp.fr (Thierry ROLLAND) writes:
|> 
|> Hi,
|> 
|> 
|> I am searching for a gateway that can translate IP address
|> My problem is :
|> 
|>     I have a big IP network with more than 1000 machines on 150 sites 
|> and I want to connect this network to the internet without changing
|> the internal IP addresses in the network.
|> I would like that people could connect to internet sites through
|> a gateway that translate internal IP address to a valid Internet address.

	Network Systems DX series routers will do IP address translating
through the Packet Control Facility (which will also do a lovely job
of more traditional security-oriented packet filtering). This is in the
latest software version, which is either out now or will be out in
a matter of weeks.

	That's address translation at the network layer. If you want
to do application layer translating (e.g. using an application on
an intermediate machine to accept FTP connections from your users, and
run a 2nd FTP connection out onto the Internet, and arrange it so
it looks to the user like their FTP is going out to the Internet), you
should look at the TIS firewall kit on ftp.tis.com, or the SOCKS package
(check with archie for where to get this). Either of these would set
up some generic Unix box to be the gateway.

	If you'd like to buy a DX, drop me some email, and I'll kick
our sales force repeatedly until they sell you one.

		Andrew Molitor
		not speaking for NSC, I just work here

|>                                                  Thierry ROLLAND
|>                                               rolland@cti.ecp.fr

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 16:30:45 -0600
From:      hlg9696@tamsun.tamu.edu (Han Lin Goh)
To:        comp.protocols.tcp-ip
Subject:   Multicast router

Can someone direct me to public-domain (preferable) or commercial software
that routes multicast packets? It can either run on the SPARC (Solaris 2.3) or
PC.

Thank you.


-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994  11:37 est
From:      longm@firnvx.firn.edu  (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP packages?

I am looking for TCP/IP packages that incorporate Telnet, FTP, Gopher,
Ping, etc.. I have found one for a DOS called NUPop which works great.  But,
I need more to look at, does anyone know of more that is Freeware/Shareware.
Mike.

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 07:22:24 GMT
From:      gabling@ks.id.ethz.ch (Maximilian Gablinger)
To:        comp.protocols.tcp-ip
Subject:   Protocolconverter between lat and tcp-ip with 2 Ethernet plugs on PC

Hi

I am looking for a PC programm which does protocol-conversion between lat 
and TCP/IP . I want two ethernet adapters in this PC, one net hat LAT and
the other one has tcp/ip outgoing.
Is ther a public domain PC Programm somewhere ?

thanks

_____________________________________________________________________
¦               Kommunikationssysteme der                           ¦
¦                         ETH                                       ¦
¦                     Clausiusstr. 59                               ¦
¦                     CH-8092 Zuerich                               ¦
¦                   Tel: +41 (1) 632 5801                           ¦
¦                   Fax: +41 (1) 252 82 43                          ¦
¦               Email:  gabling@ks.id.ethz.ch                       ¦
¦___________________________________________________________________¦

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 07:52:34 GMT
From:      whitmire@netcom.com (Scott Whitmire)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone heard of NetCom???

Jeffrey Horn (jhorn@snake1.cs.wisc.edu) wrote:
: Has anyone heard of an Internet provider called NetCom?  Better yet, 
: is anyone actually using their service?  I am helping a company get
: connected to the internet and NetCom charges only $400/month for a
: class C frame relay connection while most others (AlterNet, etc.) charge
: nearly three times that amount.  I want to know what the catch is, or 
: if this deal is really as good as it sounds.
 
: Thanks for your help, 
 
: Jeffrey Horn
: horn@cs.wisc.edu

As you can see from the address, I am a Netcom user.  So far, there is no 
catch.  If your company doesn't really need a class C connection, there 
are cheaper options, as well as more expensive ones.

-- 
  =================================================== 
  | Scott A. Whitmire         | whitmire@netcom.com |
  | Advanced Systems Research |                     |
  | 25238-127th Ave SE        | (206)631-7868       |
  | Kent  WA  98031           |                     |
  ===================================================


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 94 13:20:59
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway

> 	If you'd like to buy a DX, drop me some email, and I'll kick
> our sales force repeatedly until they sell you one.

So is Network Systems going to have an implementation of OSPF, like other
good router vendors?

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994  14:04 est
From:      longm@firnvx.firn.edu  (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Packages

I am looking for a TCP/IP package that include Telnet, FTP, Ping, Gopher,
etc... I have found one for the DOS enviroment called NUPOP.  If anyone knows
more please let me know.
Thanks Mike...
e-mail: longm@firnvx.firn.e

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 21:52:13 +0800
From:      rob@perth.DIALix.oz.au (Rob Mascaro)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

NIS and DNS are actually aimed at different services. DNS is for resolving
internet host names into IP numbers. NIS on the other hand is for administering
multiple hosts and keeping one copy of the system files (passwd, hosts etc...)
on one machine.
As you can see, many SUN sites on the internet would run both.
hope the helps,
Rob. 
-- 
  \        =                                                         ,_|\
  < []_[]= |      Rob Mascaro            email:  rob@DIALix.oz.au   /    \ 
  /\/(_)\|/|\     Systems Administrator  phone:  +61 9 4251804     <*     |
                  Racing and Gaming      Perth, Western Australia   \/--\/ 

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 11:42:23 GMT
From:      chris@marge.mikom.csir.co.za (Chris zwanepoel)
To:        comp.protocols.tcp-ip
Subject:   Re: Router..UNIX, DOS, OS2????

you +must+ get hold of karlbridge or karlbrouter !!!!!!
try archie for kbridge, you will not be disappointed.
the freeware version is quite handy and you only pay for the h/ware you use

cheers
chris@marge

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 12:34:39 GMT
From:      w-rolph@ds.mc.ti.com (Don Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

In article <16F7394B0S86.J045820@LMSC5.IS.LMSC.LOCKHEED.COM> J045820@LMSC5.IS.LMSC.LOCKHEED.COM writes:
>From: J045820@LMSC5.IS.LMSC.LOCKHEED.COM
>Subject: DNS or NIS what do I need?
>Date: Tue, 8 Mar 1994 18:34:24 GMT
 
>Hello , I am posting this note hoping to get some more information on DNS as
>opposed to NIS. We are a facility presently going from a IBM VM enviroment to
>a SunOs Unix enviroment. We are running TCP/IP on our networks and will be
>implementing PC/nfs shortly. First I have heard the statement that DNS is
>going away and NIS is going to be its suvivor. I heard this from some people
>who had attended classes for the Sun operating system. I find this hard to beli
>eve. Is this statement true or false, or does anyone have a clue?
>We have only 700 PCs on our nets at this point I am presently running NIS on a
>Sun Sparc 10. At this point we are doing only name resoloution on about 30 PCs
>using the NIS. When the master server goes down we have systems that are bound
>to it that hang. I was wondering would DNS work better for the name resoloution
>. I am a network type person is NIS normally handled by sysadmins? Thanks for
>the time.
>                     Billy

NIS is certainly not the primary standard outside of SUN and perhaps some HP 
environments.  DNS is alive, well, and the dominant standard for host table 
distribution among networks when interacting with the inetnet.

If you want to be aggressive go add HESIOD (for the rest of the admin data) 
and kerberos (for distributed security), and that constructed the best 
distributed environment I have ever used: project ATHENA at MIT.


Regards.
 
Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 21:42:28 -0500
From:      robb@epenviron.eapi.com (Rob Beckman)
To:        comp.protocols.tcp-ip
Subject:   int14 / remote modem communications

In the PC world there are a whole lot of products out there to allow
a networked PC to use another networked PC modem or serial port using
INT14 protocol.

My question is, does anyone know of anyway to allow a pc attached to
a unix server through tcp/ip use modems attached to unix server through
int14.  The main focus here is to find a int14 routine so we can take 
advantage of pc software that use int14.

Any information would be appreciated.

rob beckman
robb@eapi.com


-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 13:45:38 GMT
From:      bof@wg.saar.de (Patrick Schaaf)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway

barmar@think.com (Barry Margolin) writes:

>In article <2lkbet$7an@piston.ecp.fr> rolland@cti.ecp.fr (Thierry ROLLAND) writes:
>>I am searching for a gateway that can translate IP address
 
>This is hard to do in general, since many protocols include IP addresses in
>the data portion.

Thinking of it, such a thing would have to reassemble fragments, and
recalculate TCP checksums on the fly. Sounds like the wrong approach.

Patrick


-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 14:12:12 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocolconverter between lat and tcp-ip with 2 Ethernet plugs on PC

In article <2lmhrg$ago@elna.ethz.ch>, gabling@ks.id.ethz.ch (Maximilian Gablinger) writes:
|> Hi
|> 
|> I am looking for a PC programm which does protocol-conversion between lat 
|> and TCP/IP . I want two ethernet adapters in this PC, one net hat LAT and
|> the other one has tcp/ip outgoing.
|> Is ther a public domain PC Programm somewhere ?

Public domain, no, but Meridian Technology Corporation does a fine job
with their LAT products:

	Meridian Technology Corporation
	11 McBride Corporate Center Drive Suite 250
	Chesterfield MO  63005-1406
	Phone:  +1 314 532 7708
	FAX:    +1 314 532 3242

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 14:58:15 GMT
From:      sallen@herbie.raleigh.ibm.com (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Finding out the IP address

If you run AIX, use the host(1) command with your hostname.  On most
machines use nslookup(1) with your machines hostname.  To find out
your hostname, most machines can use the hostname(1) function, or
uname(1).  Both host(1) and nslookup(1) with also give you a hostname
from an IP address.

In article <CMCn1H.87L@cbnewst.cb.att.com>, kkarp@cbnewst.cb.att.com
(karen.karp) writes:
->how do I figure out the IP address of the server I am on?
->
->
->thanks!
->kkarp@attmail.com

Sean Allen                                      AIX/Database Administration
(919)543-6021 Fax 7996                        IBM Personal Computer Company
Internal Zip: D533/B205                          Research Triangle Park, NC
#include<std_disclaimer.h>                   Internet: allensd@vnet.ibm.com

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 94 15:51:10 GMT
From:      gt0567a@prism.gatech.EDU (Mathieu Claude Hans)
To:        comp.protocols.tcp-ip
Subject:   What is RTP?

I'd like to find some information about RTP (Real-time protocol),
I'd be glad to find the RFC, or any information available on
Internet.

--
Mat Hans (-:
Georgia Tech, school of Electrical and Computer Engineering 
Internet: 	gt0567a@acme.gatech.edu

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 16:01:26 GMT
From:      a336dhal@cdf.toronto.edu (Dhaliwal Bikram Singh)
To:        comp.protocols.tcp-ip
Subject:   HD bottle-neck? or ethernet?


When I am doing some transfers via TCP/IP over my P2P net I usually
get transfer rates ~400 KB/s (but only 150KB/s if I ftp from a DOS
client).  However when I run a testing utility I called tcpspray
I consistently get >650 KB/s.  

1. Is the testing utility correct

2.  If so is my bottleneck the speed of the hard-drives, which have
about 560kb/s transfer rates?

3.  Why is my DOS - Unix performance so abysmal?

I am running Linux-Linux, and Linux-Dos.  Using 99pl15 and Trumpet WinSock.
I am using 2 10BaseT cards.

-bikram
-- 
-a336dhal@cdf.toronto.edu
-bikram dhaliwal

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 16:53:03 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Steven's new book!

> Would you be so good as to post a blurb, maybe a table of contents?

You can anonymous ftp to aw.com (192.207.117.2) and fetch the file
aw.prof.comp.series/stevens.tcpipiv1.info.tar.Z, which has the TOC,
Preface, and one entire chapter in PostScript or ascii.  If you can't
anonymous ftp, e-mail me for the TOC.

	Rich Stevens  (rstevens@noao.edu)

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 16:58:06 GMT
From:      landin@cherokee.nsuok.edu (Mark Landin)
To:        comp.protocols.tcp-ip
Subject:   Need contact at NIC

Hi! I just discovered this newsgroup today, so pardon me if this
request is inappropriate or in an FAQ. 

We need to have some additional network numbers assigned to us. Is there
a standard contact or method  for doing this?

-- 
*-----------------------------------------------------------------------------*
*  Mark C. Landin					Northeastern St. Univ *
*  landin@cherokee.nsuok.edu					Tahlequah, OK *
*   "Living in the pools, they soon forget about the sea" - Neil Peart, RUSH  * 

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 17:28:10 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway

In article <2lkbet$7an@piston.ecp.fr> rolland@cti.ecp.fr (Thierry ROLLAND) writes:
>I am searching for a gateway that can translate IP address
>My problem is :
>
>    I have a big IP network with more than 1000 machines on 150 sites 
>and I want to connect this network to the internet without changing
>the internal IP addresses in the network.
>I would like that people could connect to internet sites through
>a gateway that translate internal IP address to a valid Internet address.
>
>Does such stuff exists ?
>Where can I find such application ?

I don't know of anyone who actually has an operational, production
version of such a box.  The problem is an open-ended, can-of-worms
kind of situation.  You can't just swap IP addresses in the IP header
as things pass by.  Any IP options carrying IP addresses must be
modified.  TCP and UDP checksums must be recalculated because of
the use of "psuedo-headers".  And worst of all, many applications
pass IP addresses back and forth as application data.  All of these
cases, in applications of interest, must be dealt with.  FTP and
DNS come to mind as common such applications.  Also, you are still
stuck with the (admittedly small) possibility that you need to talk
to a site that has the officially registered addresses that you are
using.  You might be better off with one machine on the Internet
with a legal address, and provide for your users to log this machine
for Internet access.  This is a bit more cumbersome, but gives you
a single point for security/access control.

Art


-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 03:31:07 -0600
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: What is RTP?

no RFCs, but Internet-drafts abound on RTP...

checkout
draft-ietf-avt-rtp-04.txt
on one of the internet draft repositoaries- 

here i reproduce the standard announcement....

Internet-Drafts are available by anonymous FTP.  Login with the
username "anonymous" and password "guest".  After logging in,
Type "cd internet-drafts".
     "get draft-ietf-imap-imap4-01.txt".
 
Internet-Drafts directories are located at:
 
     o  US East Coast
        Address:  ds.internic.net (198.49.45.10)
 
     o  US West Coast
        Address:  ftp.isi.edu (128.9.0.32)
 
     o  Pacific Rim
        Address:  munnari.oz.au (128.250.1.21)
 
     o  Europe
        Address:  nic.nordu.net (192.36.148.17)
 
Internet-Drafts are also available by mail.
 
Send a message to:  mailserv@ds.internic.net. In the body type:
     "FILE /internet-drafts/draft-ietf-imap-imap4-01.txt".
 
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
 
 
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
 
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
 
--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"
 
Content-Type: text/plain
Content-ID: <19940309151055.I-D@CNRI.Reston.VA.US>
 
FILE /internet-drafts/draft-ietf-imap-imap4-01.txt
 
--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-imap-imap4-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"
 
Content-Type: text/plain
Content-ID: <19940309151055.I-D@CNRI.Reston.VA.US>
 
--OtherAccess--
 
--NextPart--

-- 
jon crowcroft (hmmm...)

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 18:03:42 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Sizes of UDP packets.

Mathieu Claude Hans (gt0567a@prism.gatech.EDU) wrote:
: The RFC 768 (User Datagram Protocol) does not talk about size limitations
: for the embedded data. But if you look at HP's manual, they decided:

Becuse the size limit is determined by the IP protocol, giving just
under 64K.

: "The maximum message size for a UDP datagram socket is 58254 bytes.
:       The default message size is 9216 bytes. "
 
: Do all systems have a lower and an upper bound for the message
: size? Why a lower bound? is it because of their machines or because of

They depend on the implimentation of the operating system.

: routers, or something out there on the Internet?

Media such as ethernet have both an upper and lower limit on the size
of packets sent. The former is quite easily deal with by IP fragementation.
The latter by simply padding the ethernet packet.

: If you wanted to send packets as fast as possible (therefore not wanting 
: routers to break them up, or something like that) what size would you
: consider?

Check out the MTU Discovery RFC. Though this is more aimed at TCP, rather
than UDP.

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 18:10:57 GMT
From:      Tony Andreoli <Tony_Andreoli_-_CTA@CL_63SMTP_GW.CHINALAKE.NAVY.MIL>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware.networking,comp.sys.mac.comm
Subject:   Re: Ethernet Address

In article <CMB0Jq.J8B@news.ci.ua.pt> Fernando Cozinheiro,
cooker@ci.ua.pt writes:
>I need simple applications to get Ethernet addresses for Macintosh and
>PC computers. Can anyone help me to find them?

On the Mac, use GetMyAddress (I think it's at Sumex).

Tony Andreoli

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 94 18:14:58 GMT
From:      ddoshi@caip.rutgers.edu (ddoshi)
To:        comp.lang.c++,comp.protocols.tcp-ip
Subject:   gethostname() with CC and g++

Can anybody explain the strange behavior of CC and g++
compilers.



----------------------------------------------------------------------------[caip.Network]% g++ -g ServerMain.C
ServerMain.C:27: warning: return type for `main' changed to integer type
ServerMain.C: In function `int  main (...)':
ServerMain.C:29: warning: implicit declaration of function `gethostname'
[caip.Network]% a.out
NAME = caip.rutgers.edu
[caip.Network]% CC -g ServerMain.C
"ServerMain.C", line 29: error:  undefined function gethostname called
Compilation failed

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 19:42:11 GMT
From:      jime@well.sf.ca.us (Jim Eberle)
To:        comp.protocols.tcp-ip
Subject:   rcp client protocol wanted

    Does anyone know where I could find the client side of rcp? I'd like
    to use it for quickie file transfers and ftp looks daunting. I have
    had previous success w/ rsh thanks to Mr. Stevens "UNP". Rcp client
    is not in Stevens, Comer, Rago or mentioned in the RFC's.
    Any help would be greatly appreciated
    Jim Eberle


-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 19:47:25 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway

>    I have a big IP network with more than 1000 machines on 150 sites 
>and I want to connect this network to the internet without changing
>the internal IP addresses in the network.

	One option is to configure what amounts to a non-routing firewall
and permit access through it to the internet, via proxies.
	The disadvantage of this approach is that you'll be unable to
talk to whoever out there legitimately owns the addresses you have on
the "inside" unless you make the firewall 2 layers deep (and use a
weird internal network like 127.0.0.2 <-> 127.0.0.3)
	The proxy approach is what a lot of us use for internet security
as well as connectivity. It has its advantages (security, audit trail,
and authentication) and its disadvantages (no direct connects, need to
have a proxy for a service before you can run it, etc)  Still, if you
can telnet/rlogin/ftp/http to the outside, that's pretty good.
	We use the TIS firewall toolkit for ours (not surprisingly)
which is available for FTP from ftp.tis.com, pub/firewalls/toolkit

mjr.

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 20:16:43 GMT
From:      George D. Nincehelser <nincehelser@sbctri.sbc.com>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware.networking,comp.sys.mac.comm
Subject:   Re: Ethernet Address

In article <CMB0Jq.J8B@news.ci.ua.pt> Fernando Cozinheiro, cooker@ci.ua.pt
writes:
> I need simple applications to get Ethernet addresses for Macintosh and
> PC computers. Can anyone help me to find them?

If you have MacTCP installed on the etherneted Macs, you can option-click
on the ethernet icon in the MacTCP window.  This will show you the
ethernet address.

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 21:08:18 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages

In article <CMCKJo.H51@cix.compulink.co.uk> galileoswieng@cix.compulink.co.uk ("Galileo International") writes:
>Why would I ever get duplicate UDP messages if they are not broadcast.  
>The only reason I can think of is a router duplicating messages across 
>two links for some reason.

When a router sends an ICMP Redirect, it also forwards the packet.  If the
originating host resends the packet as well, you'll get a duplicate.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 94 21:09:36 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <262@ddlgw.UUCP>, ddl@harvard.edu (Dan Lanciani) writes:
| In article <a09878.763151912@giant>, a09878@giant.rsoft.bc.ca (Curt Sampson) writes:
| | casper@fwi.uva.nl (Casper H.S. Dik) writes:
| | 
| | >Most current hardware/software combinations (or should I say all)
| | >have no problem reaching wire speed over TCP/IP. 1000K/s transfers
| | >are the rule, not the exception.
| | 
| | You certainly shouldn't say all. The I/O limitations of ISA bus PCs
| | and common 16-bit ethernet cards will let you get nowhere near wire
| | speed. An NE2000 will give you 400-500K/sec. on a good day.
| 
| It's not as bad as all that.  I see 800+KB/sec from an ss10 to an ISA
| PC (486DX50) with a generic NE2000 clone and a rather old version of the
| NE2000 packet driver at that.  (This from a binary ftp get of /vmunix to
| nul.)  The PC's bus is running at the typical 8Mhz.

Following up to my own message...  Since there is always concern that
ftp may lie, I ran a quick test with ttcp (though I suppose it might
lie as well).  Using 16k windows and 16k buffers all around, and 1024
of those buffers, ttcp on the above hardware reports 1022KB/real sec
from the ss10 end.  (The PC's ttcp reports slightly higher--I suppose
that could be the greater clock quantization error.)  Now, granted this
isn't up there at wire speed, but neither is it a terrible bottleneck.

In the unlikely event that I've hit upon a magical combination of
motherboard and NIC that everyone wants to duplicate:

Oops, I was going to give the manufacturer of the NIC, but there is
no reference to a brand in the ``Ethernet Installation Manual'' which
says only ``Fourth Edition, August 1990, 6000''.  I knew it was generic....

And the motherboard manual is nearly as bad: ``Copyright 1991, Rev 1.1
Jan 1992'' and ``Part No. 200. ISA4.003''.  However, it does say that
they use ``the high performance ISA 486 SIS85C401/SIS85C402 chip set
by Silicon Integrated Systems Corp.''  I guess they were right about
the performance. :)

				Dan Lanciani
				ddl@harvard.*

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 12:50:37 -0800
From:      mahboud@aggroup.com (Mahboud Zabetian)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address

In article <CMGnuA.2tr@avalon.chinalake.navy.mil>, Tony Andreoli
<Tony_Andreoli_-_CTA@CL_63SMTP_GW.CHINALAKE.NAVY.MIL> wrote:

> In article <CMB0Jq.J8B@news.ci.ua.pt> Fernando Cozinheiro,
> cooker@ci.ua.pt writes:
> >I need simple applications to get Ethernet addresses for Macintosh and
> >PC computers. Can anyone help me to find them?
> 
> On the Mac, use GetMyAddress (I think it's at Sumex).
> 
> Tony Andreoli

The GetMyAddress on Sumex (and wuarchive) is old.  Try the one on
ftp.aggroup.com.

-mahboud
---------------------------------------------------------------
Mahboud Zabetian
mahboud@aggroup.com
ag group, inc.
2540 camino diablo, suite 200
walnut creek, ca 94596
510-937-7900 voice
510-937-2479 fax
510-937-6704 ara
ftp.aggroup.com anonymous ftp

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 12:54:04 -0800
From:      mahboud@aggroup.com (Mahboud Zabetian)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address

In article <CMGnuA.2tr@avalon.chinalake.navy.mil>, Tony Andreoli
<Tony_Andreoli_-_CTA@CL_63SMTP_GW.CHINALAKE.NAVY.MIL> wrote:

> In article <CMB0Jq.J8B@news.ci.ua.pt> Fernando Cozinheiro,
> cooker@ci.ua.pt writes:
> >I need simple applications to get Ethernet addresses for Macintosh and
> >PC computers. Can anyone help me to find them?
> 
> On the Mac, use GetMyAddress (I think it's at Sumex).
> 
> Tony Andreoli


GetMyAddress on Sumex (and wuarchive) is an older version.  Try the latest
on ftp.aggroup.com.

-mahboud
---------------------------------------------------------------
Mahboud Zabetian
mahboud@aggroup.com
ag group, inc.
2540 camino diablo, suite 200
walnut creek, ca 94596
510-937-7900 voice
510-937-2479 fax
510-937-6704 ara
ftp.aggroup.com anonymous ftp

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 94 01:37:36 GMT
From:      oberman@icaen.llnl.gov
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.misc
Subject:   RE: TCP-IP on a VAXstation

In Article <2lnihs$aig@navaho.cc.bellcore.com>
kenton@navaho.cc.bellcore.com (gidewall,kenton c) writes:

>My company needs to run tcp-ip on some VAXstation 3100 model 76s.  We
>have been told that DECNET/OSI has tcp-ip included in it.  All you have
>to do is turn it on and you have tcp-ip.  We haven't put DECNET/OSI on
>our clusters yet (soon), so we can't verify that.  However, someone else
>told us that the tcp-ip with OSI isn't a full-blown version and we won't
>be able to do all the things we could with a 3rd-party version of tcp-ip.
 
>My question is:  Who is right?  If we have DECNET/OSI on our machines are
>we all set?  Or would we be better off with a full-blown 3rd-party vendor's?

No. DECnet/OSI includes DECnet Phase IV (the current protocol suite) and the
OSI suite. It does NOT include TCP/IP. Digital's TCP/IP product is available
for VMS with or without DECnet/OSI (or any DECnet).

>Also, assuming we need a 3-rd party vendor product, who are the players in
>the tcp-ip market and what are the pros and cons of each product?  
>(If this is in a FAQ somewhere, please point me in the right direction).

Popular vendors include TGV (MultiNet), Process Software, and The Wollongong
Group. I have no recent experience with any except TGV. I use it and I like it
very well. (This is NOT an endorsement from my employer!)

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 02:06:28 GMT
From:      risner@lexmark.com (James Risner)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Driver for Token Ring

In article <jack.christenson.26.00102C91@stpaul.NCR.COM> jack.christenson@stpaul.NCR.COM (Jack P. Christenson) writes:

   Does anyone know of a packet driver for an IBM compatible token ring
   adapter OTHER than the Crynwr IBMTOKEN.COM?  Or does anyone know 
   how to modify it to allow frames larger than the normal ethernet limit of
   1500 bytes?

Well, the 1514 (?) byte limit is imposed by ethernet.
IBMTOKEN.COM is an ETHERNET packet driver that uses an
IBM TokenRing Card for the data, so it can NOT support more
than 1514 (or whatever it really is) bytes.

IBMTOKEN.COM is a type 1 packet driver.
Packet drivers are independent of the network card, but 
VERY dependent on the network TYPE.
 
What you need is a IBMTOKEN.COM that is a type 4 (I think Token 
ring is type 4) driver.  BUT you would also need all your software
changed to use a type 4 driver instead of a type 1 driver.

Risner


-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 02:50:47 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <2lf07v$ci2@sophia.inria.fr> huitema@mitsou.inria.fr (Christian Huitema) writes:
>In article <CM5v18.EzM@calcite.rhyolite.com>, vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>
>|> SLIP is just as much a standard as PPP.  SLIP has an RFC.  That PPP has
>|> bunches of RFC's with half a dozen to be released this year or next does
>|> not make PPP more standard, quite the contrary to rational people.
>|> 
>
>Sorry Vernon, I certainly don't want to let that pass. First and foremost, all
>readers within this list should be aware that
>         ********************************************************
>         *   It is important to remember that not all RFCs      *
>         *   are standards track documents, and that not all    *
>         *   standards track documents reach the level of       *
>         *   Internet Standard.                                 *
>         ********************************************************
>
>The reason why SLIP is a standard is not because it is published in an RFC,
>but because that RFC (1055) is recognized as an elective Internet Standard
>(standard number 47, ...

That's all true.  In my view, it's also at best as irrelevant as the
original statement that claimed SLIP is not a standard.  As far as the
CCITT (now ITU?), ANSI, and IEEE are concerned, neither PPP nor SLIP are
Standards, because they both come from that non-standards body, the IETF
(Yes, I've heard of the great peace treaty now being negoitated between
the CCITT and the IETF.  Talk about being co-opted into the enemy's camp.
Or of getting old, losing your ideals, cutting your hair, and buying a
BMW...).

The only things more boring and noxious than the plethora of standards
are the bureaucratic nits of standards making.  In the good old Internet
days, SLIP, PPP, and NFS (to pick 3 at random) would all be equally
Standards.  Now, of course, SLIP is an Untouchable Grandfathered Standard
and NFS is an Completely Irrelevant Non-Standard With Only An Informational
RFC.

Part of the reason there are so many PPP RFC's is that there are so many
link layers.  Another equally important reason is that some individuals
in the working group have fought to divide the existing RFC's and to
otherwise increase the number of PPP RFC's for reasons that have nothing
to do with the standards themselves.

Just as it is true that the best thing about standards is that there are
so many to choose from, it is also true that the best thing about standards
committees is that there are so many to choose from.


Vernon Schryver    vjs@rhyolite.com

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:00:29 GMT
From:      knopf@nisc.jvnc.net (Greg Knopf)
To:        comp.protocols.tcp-ip
Subject:   Re: Need contact at NIC

Mark,

You might want to contact your Internet service provider.  Service
providers such as my outfit, JvNCnet, have been given blocks of
class C networks which we then assign to people who contact
us.

- Greg
knopf@jvnc.net

In article <1994Mar10.165806.15114@cherokee.nsuok.edu>, landin@cherokee.nsuok.edu (Mark Landin) writes:
|> Hi! I just discovered this newsgroup today, so pardon me if this
|> request is inappropriate or in an FAQ. 
|> 
|> We need to have some additional network numbers assigned to us. Is there
|> a standard contact or method  for doing this?
|> 
|> -- 
|> *-----------------------------------------------------------------------------*
|> *  Mark C. Landin					Northeastern St. Univ *
|> *  landin@cherokee.nsuok.edu					Tahlequah, OK *
|> *   "Living in the pools, they soon forget about the sea" - Neil Peart, RUSH  * 

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:04:12 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <6TymaRj024n@comptech.demon.co.uk> elatar@comptech.demon.co.uk writes:
> ...
>Well I agree with what you are saying, but my thoughts are on the lines of
>compression at TCP level will yield less packets, less serial IRQ loading,
>less packet processing loading, and coupled with something like VJ TCP/IP
>header compression as well, will yield better throughput than even V42bis
>can provide. And I think with a highly efficient algorithm, the gains made
>reducing loading by the above will not be totally lost by the processor
>time required for compression, thus I am hoping for an overall reduction
>in processor loading as well as higher effective data throughput.
>
>And before you say it, I am aware that V42bis does manage to sort it's self
>out when having to deal with apparently uncompressable data, unlike MNP5.
>
>And I am also aware that a number of people have allready looked at doing
>compression on TCP/IP packets, but unfortuantely at IP level or lower, and
>so don't benefit reducing the actual number of TCP and IP packets, and so
>the overhead of dealing with them.

Remember "90% of networking is politics."  It helps to avoid getting the
technical details completely wrong, as the death of OSI shows.  However,
networking involves more than one player, so it is also necessary to get
other people to agree with you.  I agree that a negotiated network layer
option that says "the data is compressed by algorithm #57" would be almost
as good to have as the MSS option.  Unfortunately, TCP and IP will be dead
and forgotten before any such option is in enough implemenations to matter.
Doing compression within TCP or IP is completely impractical if you ever
want to exchange compressed bytes with any other implementation.

The FTP hacks wherein the remote FTP daemon automagically synthesizes
compress tar archives is a common and quite useful scheme.  CCP,
compression within PPP, is about to be common and so useful.  Compression
in the modems, such as v.42bis, will remain common and useful.  If you
care more about moving bits than being right or having your name on a
protocol, then your choice is among those three.


Vernon Schryver    vjs@rhyolite.com

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 94 22:12:03 +0300
From:      Oleg Orel <orel@oea.ihep.su>
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Wanted : Statistics on X.25 and TCP/IP

Hiren Chandiramani (hiren@li.loral.com) wrote:

: Hi,
: Can anyone tell me where I can statistics on the number of nets/users using
: X.25 ? I would also like to find the same information on TCP/IP. 
 
: Any pointers to this information would be helpfull and greatly appreciated.


Few moth ago I trying making trafic-statistic program with using DEC Packet 
Filter. You are mey take it from me and trying adaptation it for your 
situations. About statistic devided on users, I must say, what this problem
have not fully-wide method, but any protocols you are mey computing devided 
to users, for example such as smtp,ftp. For conputing any protocols you
are must protected (checked uid) its ports in kernel of system for 
user access,and write software with make handly statistic, witch 
worked under any users (for example root).


: Thanks,
: -Hiren Chandiramani
: hiren@li.loral.com




-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:12:04 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <2ll69i$q90@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
> ...
>... and given the CPU load to compress these things -- unlike specialized
>stuff like VanJ header compression, generic compression tends to be rather
>slow, and it'd make more sense to implement it in some outside box that
>doesn't have anything better to do than to move a few characters from point
>A to point B and vice versa (i.e., a modem ;-) than in the Unix box which
>presumably has better things to do.

That's not accurate on more than one count:

    1. you can compress typical text by 1.2X to 1.8X with 64Kbytes of
	memory and about 5 CPU cycles/byte.  12-bit LZW takes less memory,
	only a few more CPU cycles/byte, and does at least 2X on
	typical text.

	Thus, compressing in the host is not expensive.

    2. In general, it takes at least a dozen CPU cycles to handle a
	single byte of serial-I/O.

	Thus, compressing in the host can in fact save host CPU cycles.
	It can be cheaper for the host to compress the data than to
	send it uncompressed.

    3. Many, perhaps most UNIX boxes that are doing PPP have more spare
	CPU cycles than the modems connected to them.  Judging from
	their poor performance, many modems do not have enough CPU power
	to do their main jobs as well as compress.

Vernon Schryver    vjs@rhyolite.com

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:17:05 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user

In article <1994Mar8.055116.6791@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
> ...
>	Traceroute works by sending UDP packets with increasing TTL's
>and recording the IP address of the machine sending the Time Exceeded
>(or Port Unreachable from the target host) to determine the route. A
>kludge, but it works.
> ...

I really wish Van Jacobson had gone to the slightly greater trouble
of using TCP packets with short TTL's.  A stray TCP from a remote
host does no any harm.


Vernon Schryver    vjs@rhyolite.com

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:21:42 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <a09878.763151912@giant> a09878@giant.rsoft.bc.ca (Curt Sampson) writes:
>casper@fwi.uva.nl (Casper H.S. Dik) writes:
>
>>Most current hardware/software combinations (or should I say all)
>>have no problem reaching wire speed over TCP/IP. 1000K/s transfers
>>are the rule, not the exception.
>
>You certainly shouldn't say all. The I/O limitations of ISA bus PCs
>and common 16-bit ethernet cards will let you get nowhere near wire
>speed. An NE2000 will give you 400-500K/sec. on a good day.

Don't blame the bad performance caused by junk ISA Ethernet cards and
garbage software on the ISA bus.

The ISA bus is more than fast enough for a puny 1MByte/sec.  If it were
not, then ISA disk controllers would not be able to do a lot more than
that.

Some people using BSD/386 1.1 on ISA bus machines are claiming to hit
about 1MByte/sec with TCP/Ethernet.


Vernon Schryver    vjs@rhyolite.com

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:26:07 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST

In article <BARNETT.94Mar9144959@grymoire.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
>I wouldn't consider the FTP time valid. I have seen
>rates that are higher than theoretical maximum.

I think that only happens if you test with excessively small files, so
that errors in measuring the when the transfer started and when it
ended are on the same order as the time to do the transfer.

Any reasonable FTP implemenation should give valid times provided
the transfer requires 10 or more seconds.

Of course, as we all know, FTP measure file-system-to-file-system
performance.  Given fast enough wire, most good implemenations are
limited by the speed of the file systems and not the network.


Vernon Schryver    vjs@rhyolite.com

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 04:19:17 GMT
From:      mikebat@netcom.com (Mike Batchelor)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   KA9Q NOS 1.1a - routing between two nets over ISDN

This is rather long, but I wanted to be complete.

I am not sure if I am in over my head, treading water, or if I missed the
beach entirely.  I thought I understood simple static routing tables,
until my experience this week.

I am trying to connect two ethernets over ISDN phone lines.  The gateway
through the ISDN adapter is the sole gateway for the nets at both ends of
the connection.  This should be simple, but I am losing my hair! :(

I have a PC at each end, running KA9Q NOS v1.1a obtained from
biochemistry.cwru.edu (N/BEE 921225 v0.85-386-beta) (CWRU/MTA v1.1a). 
Each one has the ISDN adapter on ODIPKT (FTP v2.1) shim, and an ethernet
card also on a packet driver.  The ethernet at each end belongs to that
end's local net, and the two ISDN cards are on a third net all by
themselves.  Hosts on each local net have their default route pointing at
the KA9Q ethernet (route add default 199.88.131.2 1, for example).

At the KA9Q console, I can ping any host on the local net, the local ISDN
IP, and the remote ISDN IP.  I cannot ping the remote router's ether card
IP, nor any remote host.  I just get no reply.  If I disconnect the ISDN,
I get ICMP Quench errors when I try to ping across the link, which is what
I would expect.  Local hosts can ping the local router ether IP, and the
local ISDN IP, but don't get to the remote ISDN at all (no reply).

Now that the problem is defined, here is what I am doing (don't laugh if I
missed the boat on this, I am doing this sort of thing for the first
time):

I start up KA9Q with autoexec.nos:

attach packet 0x69 isdn
ifconfig isdn ipaddr 192.9.201.2
ifconfig isdn netmask 0xFFFFFF00
ifconfig isdn broadcast 192.9.201.255 (can leave off bcast without affect)
attach packet 0x60 eth
ifconfig eth ipaddr 199.88.131.2
ifconfig eth netmask 0xFFFFFF00
ifconfig eth broadcast 199.88.131.255
isat
ip ttl 255 (have tried 400 as well)
route add default isdn
route add 199.88.131/24 eth
start echo

I do likewise on the other end, except that iface 'isdn' has IP
192.9.201.1 and the ether has 192.9.200.1.  The remote net is 192.9.200. 
This gives me a routing table like this:

Destination	Len	Iface	Gateway	Metric
192.9.201.255	32	isdn		1
199.88.131.255	32	eth		1
192.9.201.0	24	isdn		0	
199.88.131.0	24	eth		1
default		0	isdn		1

If I do 'route add default isdn direct 0' instead, I get a metric of 0,
which seems more correct to me, but example configs in the FAQ leave it
off.  Nos_1229.man seems to imply that I ought to be getting a metric of 0
anyway.  It still doesn't work though.

Nos_1229.man also seems to indicate that routing will happen if the
routing table says so.  I don't find anyting that shows a command to
forward packets, and I see none in the sample configs, either.  Do I need
to do an 'ip permit' command?  I don't think I need to run a routing
protocol for a setup this simple, but I could be wrong here as well.  My
nos.exe also lacks a RIP command, contrary to nos_1229.man.  I do have
arp, though - is this what I need?  I have got the O'Reilly TCP/IP manual
as well, and perhaps this has made me merely dangerous, rather than
informed. :) I see the caution, in the nos_1229.man section about the
route command, for having default routes pointing at each other, and the
loop that could result - is this my problem?  Any help is most
appreciated, e-mail even more so, but I will check the group for replies,
and post a summary when I get it working.

Thanks in advance.

--
Mike Batchelor      | UseLinuxUseLinuxUseLinuxUseLinuxUseLinuxUseLinuxUseLinux
mikebat@netcom.com  | xuniLesUxuniLesUxuniLesUxuniLesUxuniLesUxuniLesUxuniLesU
------------------------------------------------------------------------------
Q:  What machine does Windows/NT run best on?

A:  A 35mm slide projector.

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 16:59:58 -0600
From:      oliver@cs.utexas.edu (Oliver Yehung Hsu)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

: : 	DNS has the concept of "secondary" servers; you choose your secondaries
: : wisely (including off-site machines) so that if your primary server goes
: : down your clients will automatically bind to one of the secondaries. So you
: : don't have two DNS's on the same subnet in case the gateway to that subnet
: : goes down, instead you have them in such places that if part of the world
: : dies you can probably still get to the other part(s).
 
: This is an implimentation issue, NIS also supports "secondary servers".
: In most DNS implimentations I have seen there is
: a list (of up to 3) nameservers to try. In most NIS implimentations an
: approach of send a broadcast and see what responds first is used.
: I can see little reason why NIS could not use a list of servers to try, in
: situations such as not having a NIS server on the same subnet a system of
: broadcast discovery may not work or DNS using broadcast discovery. Or that
: some combination, e.g. use a broadcast to attempt to find a local server if 
: no response try a list of servers.

You're correct; NIS does broadcast to find its server.  However, Sun chose to
implement NIS solely through broadcasting to find a server.  It does not allow
NIS to go down a list of servers to bind to.

The way NIS works is that a NIS client starts 'ypbind', which causes the client
to broadcast until it binds to the 1st server that responds.  If it cannot
bind, it just hangs there.  If the client looses the binding to the server, the
client will broadcast until a server responds.

Note that since ypbind broadcasts to find a server, these broadcasts do not
travel over subnets.  Therefore, if your NIS server is not on the same subnet
as the client, the client cannot bind  to it through broadcasting.  You must
explicitly tell the client to bind to that particular server with the 'ypset'
command.

Oliver

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 94 13:19:04 MDT
From:      dwing@uh01.Colorado.EDU (Dan Wing)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.misc
Subject:   Re: TCP-IP on a VAXstation

In article <2lnihs$aig@navaho.cc.bellcore.com>, kenton@navaho.cc.bellcore.com (gidewall,kenton c) writes:
>This is a VMS question:
>
>My company needs to run tcp-ip on some VAXstation 3100 model 76s.  We
>have been told that DECNET/OSI has tcp-ip included in it.  

DECnet/OSI does not have TCP/IP included with it.

>All you have
>to do is turn it on and you have tcp-ip.  We haven't put DECNET/OSI on
>our clusters yet (soon), so we can't verify that.  However, someone else
>told us that the tcp-ip with OSI isn't a full-blown version and we won't
>be able to do all the things we could with a 3rd-party version of tcp-ip.
>
>My question is:  Who is right?  If we have DECNET/OSI on our machines are
>we all set?  Or would we be better off with a full-blown 3rd-party vendor's?

DEC sells a product called "TCP/IP Services for VMS".  V3.0 is available for 
AXPs, and V3.0 is currently in beta test for VAXes.  There are third party 
TCP/IPs available, too, from TGV, Wollongong, Process Software, and a public 
domain version of TCP/IP called "CMU/IP", too.

>Also, assuming we need a 3-rd party vendor product, who are the players in
>the tcp-ip market and what are the pros and cons of each product?  
>(If this is in a FAQ somewhere, please point me in the right direction).

There are reviews published in various magazines every once in awhile 
comparing various TCP/IP products features and performance.  Check 'em out.

-Dan Wing, Systems Administrator, University Hospital, Denver
 dwing@uh01.colorado.edu or wing@eisner.decus.org

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 07:32:17 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway

In article <1994Mar10.172810.23843@acc.com> art@acc.com (Art Berggreen) writes:

    And worst of all, many applications
    pass IP addresses back and forth as application data.  All of these
    cases, in applications of interest, must be dealt with.  FTP and
    DNS come to mind as common such applications.  

And mail.

tli@[131.108.11.55]


-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 21:00:03 -0800
From:      tbrink@crl.com (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   X-windows port numbers


Anyone recall which port numbers Xwindows uses?  If not mistaken,
I believe it was in the 6000 range?  Thanks...  tom
-- 
    /|                          Tom Brink
 \`o.0'                         tbrink@crl.com
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 18:06:12 -0600
From:      uhhasan@uxa.ecn.bgu.edu (Hussain Hasan)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.token-ring,comp.protocols.tcp-ip
Subject:   100Base-T, 100VG-LAN, TCP/IP, SNA & IPX info needed

Hi all,

First of all I would like to excuse myself if you see this message twice as
I am cross-posting it.  I am doing Data Network load simulation using
COMNET III and was wondering if somebody could provide me with the
information listed below, that I need to setup my models.

For 100Base-T & 100VG-LAN		For TCP/IP, IPX and SNA
-------------------------		-----------------------

Collision windows (ms)			Packet data bytes
Jam Interval (ms)			Packet overhead bytes
Interframe gap (ms)			Window size
Propagation delay (ms)			End-to-End ack bytes
Session limit				Retransmit time (ms)
Frame min (bytes)			Ack end of message (y/n)
Frame max (bytes)			Retransmit blocked packets (y/n)
Frame Overhead (bytes)			Flow control method
Frame error prob
Slot time (ms)
Offset (ms)
Retry limit (ms)
Limit Delay (ms)

Any help will be greatly appreciated.  If possible please provide actual
values or pointers in the right direction.  Also please send it to my
mailbox.

Thanks in advance.

Hussain T. Hasan
Northeastern Illinois University
H-Hasan@bgu.edu

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 08:08:30 GMT
From:      turletti@jerry.NoSubdomain.NoDomain (Thierry Turletti)
To:        comp.protocols.tcp-ip
Subject:   Re: What is RTP?

In article <144308@hydra.gatech.EDU>, gt0567a@prism.gatech.EDU (Mathieu Claude Hans) writes:
|> I'd like to find some information about RTP (Real-time protocol),
|> I'd be glad to find the RFC, or any information available on
|> Internet.
|> 
|> --
|> Mat Hans (-:
|> Georgia Tech, school of Electrical and Computer Engineering 
|> Internet: 	gt0567a@acme.gatech.edu

Status of RTP is an Internet Draft. 

Cheers,

Thierry

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
A Revised Internet Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Audio/Video Transport Working
Group of the IETF.                                                         

       Title     : RTP: A Transport Protocol for Real-Time Applications    
       Author(s) : H. Schulzrinne, S. Casner
       Filename  : draft-ietf-avt-rtp-03.txt, .ps
       Pages     : 36

This memorandum describes a protocol called RTP suitable for the end-to-end
network transport of real-time data,  such as audio, video or simulation 
data for both multicast and unicast transport services.   The data 
transport is augmented by a control protocol (RTCP) designed to provide 
minimal control and identification functionality particularly in multicast 
networks.  RTP and RTCP are designed to be independent of the underlying 
transport and network layers.  The protocol supports the use of RTP-level 
translators and bridges.   Within multicast associations, sites can direct 
control messages to individual  sites.  The protocol does not address 
resource reservation and does not guarantee quality-of-service for 
real-time services.   

This specification is a product  of the Audio-Video Transport working group 
within the Internet Engineering Task  Force.   Comments are solicited and 
should be addressed to the working group's mailing list at rem-conf@es.net 
and/or the authors.                                                        

Internet-Drafts are available by anonymous FTP.  Login with the	
username "anonymous" and password "guest".  After logging in,
Type "cd internet-drafts".
     "get draft-ietf-avt-rtp-03.txt".
 Or 
     "get draft-ietf-avt-rtp-03.ps".
 
Internet-Drafts directories are located at:	
	                                                
     o  East Coast (US)                          
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  West Coast (US)                          
        Address:  ftp.nisc.sri.com (192.33.33.22)
							
     o  Pacific Rim        
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mail-server@nisc.sri.com. In the body type: 
     "SEND draft-ietf-avt-rtp-03.txt".
 Or 
     "SEND draft-ietf-avt-rtp-03.ps".
							
For questions, please mail to internet-drafts@cnri.reston.va.us.
							

-- 
Thierry Turletti <turletti@sophia.inria.fr>

Projet RODEO - INRIA Sophia-Antipolis    ivs-talk-site: jerry.inria.fr
   2004, Route des Lucioles BP 93        phone:        +33 93 65 77 18
 06902 Sophia Antipolis CEDEX France     fax:          +33 93 65 77 65

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 94 08:14:10 GMT
From:      amolitor@blefscu.network.com (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway

In article <STEINAR.HAUG.94Mar10132059@runit.sintef.no>,
	Steinar.Haug@runit.sintef.no (Steinar Haug) writes:
|> > 	If you'd like to buy a DX, drop me some email, and I'll kick
|> > our sales force repeatedly until they sell you one.
|> 
|> So is Network Systems going to have an implementation of OSPF, like other
|> good router vendors?

	Yes. We apparently attended some OSPF bake-off recently, and
performed nicely, thankyouverymuch. Normally, I'd have taken this to
email, but too many people would have read it the quoted article
as 'NSC doesn't have OSPF' and that's just false.

	On the subject of NATs (Network Address Translators), you can find
out all you ever wanted to know in draft-egevang-addrtrans-01.txt available
at fine internet draft sites near you. As Barry Margolin so wisely pointed
out, they cause problems with protocols which include IP addresses in the
data stream (FTP and X are two examples). My view on the matter is that such
apps should be hammered on until they call a library routine which returns
the right IP address, not necessarily the address the box thinks it has
(e.g. by determining if an address translation is in effect and calling upon
a central server elsewhere on the internal net to get the right address).
Another, more radical, viewpoint is that such apps are broken and should be
fixed ;)

	Address translation services are fundamentally difficult to set up
and administer. If you want to translate addresses for 3 hosts, that's
easy.  If you want to do it for 1500, that's harder. If you want to do the
very best possible thing, which would be to dynamically and transparently
assign translations from a pool, you have a great deal of administrative
code to write, something spiritually similar to bootpd. The NAT itself,
whether a DX or something else (they're easy, you could whack a BSD386
kernel up to do it, for example), is only part of the solution.

		Andrew Molitor
		not speaking for NSC

|> Steinar Haug, system/networks administrator
|> SINTEF RUNIT, University of Trondheim, NORWAY
|> Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 09:44:51 GMT
From:      creed@fse.ulaval.ca (Carlos Reed)
To:        comp.protocols.tcp-ip
Subject:   Re: What is TCP/IP?

>
>Well, *actually*, the TCP/IP bible is the collection of RFC's.
>
>Comer is, however, a highly regarded exegesis of them. (Hint: What is
>the difference between Torah and the Pentateuch?)
>
>I'd add a recommendation for Stevens' "TCP/IP Illustrated" for
>understanding the protocols in depth.
>

can any one drope me a line, telling me the ISBN for Steven's book

Bonjour! from beautiful and lovely Quebec
Carlos Reed  creed@fse.ulaval.ca

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 19:26:32 -0500
From:      phoff@panix.com (Phil Hoff)
To:        comp.protocols.tcp-ip
Subject:   arp table updates



We were having a problem and I was hoping the net could make some sense of
it. We had machine A up and running, we shutdown machine A and rebooted
machine B with the same tcpip address and the same hostname as the now
deceased machine A. Machine B would not ypbind, giving the error "
could not find domain server etc...." We went to a ypserver did an
arp -a and saw that the arp table had the old ethernet address. We
then deleted that ethernet address and the machine B came up fine. Machine A
was down for over 5 minutes.

Should not the arp table be updated automatically?

We tried it a number of times and in about half the cases it came up  without
manually deleting the ypserver arp table and half the time it did not.  We are
running SunOS 4.13.


Regards,
Phil


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994  16:30 est
From:      berman@space.honeywell.com  (Larry W. Berman)
To:        comp.protocols.tcp-ip
Subject:   Anonymous FTP Security

 
 
I am currently writing a paper dealing with security problems and
considerations setting up and maintaining an "anonymous FTP"
server. At this point, I have already accessed many RFCs and CERT
advisories. 
 
I was hoping that some of you could share some of your experiences
and other sources of information.  I'd like to know of any
vulnerabilities that you are aware of and possible remedies that
might be used.
 
Thanks for your input! 
 
 
 
berman@space.honeywell.com
Larry W. Berman
 
 


-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 11:42:56 GMT
From:      ignatios@cantor.cs.uni-bonn.de (Ignatios Souvatzis)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

In article <a09878.763191179@giant>, a09878@giant.rsoft.bc.ca (Curt Sampson) writes:

 > V.42bis modems are supposed to turn off their compression when they
 > see already compressed data (i.e., they realise that their compression
 > isn't making the data stream any smaller). However, the error
 > correction that goes along with V.42bis also uses a semi-synchronous
 > mode between the modems, so you can well see a 10% increase in speed
 > just through the dropping of the start and stop bits.
 Right...
 > Quite frankly, to me, running compression on IP packets before sending
 > them off to the modem seems a bit silly, given the compression options
 > already available out there. But that's just me...

But you should consider using gzip for e.g. long news batches, get gzipt files
from ftp archives etc... gzip is a lot better than compress or V42bis can ever
be. It's just too costly to do in realtime. (Btw, gunzip is quite fast... only
the compression is costly).

Then you'll get a lot less IP packets to handle by Protocol, Link encapsulation
and Modem error correction/compression (or deciding not to do it).

-- 
	Ignatios Souvatzis
-
Solaris 2.1:  it's slow, needs 200M of disk space and comes without C compiler,
which makes it remarkably close to MS-Windows. oleg@gd.cs.csufresno.edu

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 94 21:22:23 -0500
From:      harvey@indyvax.iupui.edu (James Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

In article <w-rolph.350.000F80FB@ds.mc.ti.com>, w-rolph@ds.mc.ti.com (Don Rolph) writes:
> In article <JOSHUA.94Mar8224639@sleepy.retix.com> joshua@sleepy.retix.com (joshua geller) writes:
>>In article <2liuk0$8r2@bosnia.pop.psu.edu> barr@pop.psu.edu (David Barr)
>>writes:
>>>    <J045820@LMSC5.IS.LMSC.LOCKHEED.COM> wrote:
 
>>>   >We are running TCP/IP on our networks and will be
>>>   >implementing PC/nfs shortly.
 
>>>   Not yay.  Investigate third-party alternatives.  (I assume you mean Sun's
>>>   PC/NFS product).
 
>>like which? and are there any nonproprietary alternatives that provide
>>the same functionality as pc/nfs (ie nfs)?
 
>>josh
>
> Yup chameleon.

Beame & Whiteside has an NFS client (Engineering here uses it) and
FTP Software, Inc. makes one (IDRIVE) for their PC/TCP product as well.
--
James Harvey   harvey@iupui.edu   IUPUI OIT Technical Support/VMS/Unix/Networks
Disclaimer:  These are my own opinions.  I do not speak for Indiana University.
It is easier to get forgiveness than permission.


-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 13:50:43 GMT
From:      russ@utcc.utoronto.ca (Russell Sutherland, NDIS)
To:        comp.protocols.tcp-ip
Subject:   Two questions...

Two questions:

1. Solaris 2.3 comes bundled with the ability to use the
   router discovery protocol (RFC 1256). Do any other UNIX hosts
   come with similar binaries? Is there any public domain code
   that implements router discovery on UNIX hosts.

2. Is there any public domain C code that implements the algorithms
   found in RFC 1219 (On the Assignment of Subnet Numbers)?

---

Russell Sutherland			Bell:	   (416)-978-0470
UTCC, Network Development 		Fax:	   (416)-978-6620
University of Toronto			E-mail:    russ@utcc.utoronto.ca
Toronto, Ontario CANADA M5S 1A1


-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 17:22:14 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Sizes of UDP packets.

Mathieu Claude Hans (gt0567a@prism.gatech.EDU) wrote:
> But if you look at HP's manual, they decided:
> "The maximum message size for a UDP datagram socket is 58254 bytes.
>       The default message size is 9216 bytes. "

  First, the last sentence __should__ say "default __maximum__ message size".
  (The error is in HP's documentation, not yours.)

> Do all systems have a lower and an upper bound for the message
> size?  Why a lower bound?

  So that should answer your second question:  there is __no__ lower bound.
  (Well, other than the fact that the link-layer frame might be padded to a
  minimum.  But this does not preclude your sending a 1-byte message; it is
  simply transmitted in a larger frame, transparent to the receiving
  application.)

  On BSD-based systems, the maximum UDP message size is based on the send
  socket buffer size (on the sender's side) and the receive socket buffer
  size (on the receiver's side).  That is, the entire message must fit into
  the socket buffer.

  (There is no easy way to determine the receiver's socket buffer size.
  There is no "MSS" for UDP.  Of course, the application can pass that 
  information in minimum-size UDP messages.)

  On HP-UX, 9216 is the default send and receive buffer size for UDP.  It
  might very well be smaller on other systems.  Consequently, they might not
  be able to receive large messages.  Conversely, their send buffers might be
  larger, and your application might not be able to receive large messages.

  On BSD, the SO_RCVBUF and SO_SNDBUF socket options control the size of the
  socket buffers.  So you can maximize your ability to receive large UDP
  messages by setting SO_RCVBUF to a larger value.  On 8.x and 9.x HP-UX,
  the largest possible SO_RCVBUF (or SO_SNDBUF) is 58254.  Some systems
  might permit even larger messages.  But IP itself imposes a limit of 65535.

  (Also note that the socket buffer limits apply to the aggregate of 
  received UDP messages not yet read by the application.  Associated with 
  each message is a sockaddr_in structure for the "from" address, which 
  reduces the maximum UDP message size to a little less than the socket
  buffer size.)

> If you wanted to send packets as fast as possible (therefore not wanting 
> routers to break them up, or something like that) what size would you
> consider?

  To some degree, the answer depends on the application and how likely it is
  that UDP messages might be dropped by the network (outbound or inbound
  interface or protocol stack, gateways, network media.)

  If you "knew" there was little chance of dropping UDP messages [*], you
  might consider sending large UDP messages because that results in fewer
  syscalls and fewer internal kernel calls.  However, large UDP messages may
  need to be fragmented and reassembled by IP, even on a local network, which
  can affect performance adversely.

  However, UDP is notoriously "lossy" because there is no retransmission
  capability in the protocol.  Application-level retransmission policies can
  be very costly; NFS with large wsize and rsize is a "good" example.

  In such cases, you might consider ensuring that UDP messages are no larger
  than the network MTU.  In current HP-UX releases, this is statically
  determined by the type of network (and the subnetconfig(1m) command), and
  it does __not__ take into account possibly smaller MTUs for distant
  networks (i.e., router fragmentation).  See the netstat(1) command for the
  MTU.

  (BTW, even if the UDP message is no larger than the MTU, it is possible to
  flood the network and lose messages.)

-- Ken Mintz

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 17:31:06 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: What is RTP?

In article <144308@hydra.gatech.EDU> gt0567a@prism.gatech.EDU (Mathieu Claude Hans) writes:
>I'd like to find some information about RTP (Real-time protocol),
>I'd be glad to find the RFC, or any information available on
>Internet.

	RTP is a "session-like" protocol for carrying voice/video over
UDP/IP.  Folks into teleconferencing over the Internet should ask
their vendors when the vendor will be shipping an RTP-compliant
video/audio teleconferencing application because RTP is required for
multi-vendor interoperability.

The most recent online version is:
	ftp.internic.net:/internet-drafts/draft-ietf-avt-rtp-04.*

  The spec is likely to change slightly in the very near future.  The
revised version is likely to become a Proposed Standard and appear as
an RFC soon after the revised I-D appears.

Ran
atkinson@itd.nrl.navy.mil



-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 17:46:21 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages

Barry Margolin (barmar@think.com) wrote:
: In article <CMCKJo.H51@cix.compulink.co.uk> galileoswieng@cix.compulink.co.uk ("Galileo International") writes:
: >Why would I ever get duplicate UDP messages if they are not broadcast.  
: >The only reason I can think of is a router duplicating messages across 
: >two links for some reason.
 
: When a router sends an ICMP Redirect, it also forwards the packet.  If the
: originating host resends the packet as well, you'll get a duplicate.

When sending an ICMP source quench the router MAY also forward the packet.

I would question if the originating host should be resending the 
packet. In either case.

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 18:10:35 GMT
From:      smb@research.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Steven's new book!

In article <2ln79s$glr@owl.nstn.ns.ca>, lhowie@prograph.com (Les Howie) writes:
> In article <1994Mar7.132944.8268@noao.edu>
> rstevens@noao.edu (W. Richard Stevens) writes:
> 
> > Would you believe 7 volumes comprising 12 chapters? :-)
> > Seriously, Volume 1 is the only one so far.  Look for Volume 2 by
> > the end of 1994.  I have ideas for many more, but who knows ...
> > 
> >         Rich Stevens
> 
> Would you be so good as to post a blurb, maybe a table of contents?

You can find the Table of Contents on the Addison-Wesley machine, as
aw.com:/aw.prof.comp.series/stevens.tcpipiv1.info.tar.Z.

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 18:28:54 GMT
From:      mishra@cs.sunysb.edu (Prateek Mishra)
To:        comp.protocols.tcp-ip
Subject:   ..Using Tcp/ip applications on multi-homed machine..


I have a SPARC-10 located on two separate networks with
two separate IP addresses. Question: how can I choose
one of the IP addresses as the source when using
standard applications such as ftp etc. In other words,
when I say

	ftp blah1.blah2.blah3.blah4

How can I avoid using the standard ethernet card
for the file transfer and instead use the second 
network??

please e-mail replies to me.
mishra@sbcs.sunysb.edu

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 18:53:43 GMT
From:      simon@tilapia.edec.locus.com (Simon Rosenthal)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Looking for Network Telesystems ?

--

Can anyone point me to an address/email address/phone for Network Telesystems ?
They were mentioned in January's Byte as having implemented a NetBIOS nameserver
for NetBIOS over TCP/IP.

Thanks in advance

- Simon

_________________________________________________________________________
Simon Rosenthal:  (simon@bos.locus.com)
Locus Computing Corporation
Burlington, MA 01803

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 20:30:07 GMT
From:      w-rolph@ds.mc.ti.com (Don Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

In article <JOSHUA.94Mar8224639@sleepy.retix.com> joshua@sleepy.retix.com (joshua geller) writes:
>From: joshua@sleepy.retix.com (joshua geller)
>Subject: Re: DNS or NIS what do I need?
>Date: 09 Mar 1994 06:46:39 GMT
 
>In article <2liuk0$8r2@bosnia.pop.psu.edu> barr@pop.psu.edu (David Barr) 
>writes:
>>    <J045820@LMSC5.IS.LMSC.LOCKHEED.COM> wrote:
 
>>   >We are running TCP/IP on our networks and will be
>>   >implementing PC/nfs shortly.
 
>>   Not yay.  Investigate third-party alternatives.  (I assume you mean Sun's
>>   PC/NFS product).
 
>like which? and are there any nonproprietary alternatives that provide
>the same functionality as pc/nfs (ie nfs)?
 
>josh

Yup chameleon.


Regards.
 
Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 09:57:15 -0800
From:      jlundgr@eis.calstate.edu (John E. Lundgren)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware.networking,comp.sys.mac.comm
Subject:   Re: Ethernet Address

Microsoft LanMan comes with a program ccalled NSTATUS.  It gives the 
ethernet address, among other things.  The program you want probably has 
to be for your particular brand of network, but you didn't say what that was.

--
Fortune cookie/Tagline for the week:  Funny -- only sensible people agree
with me.  Reality-ometer [\.....]  Hmmph!  Thought so...
Two rights don't make a wrong, they make an airplane.
Geek Code:  GAT d-- p-@ c++(++++) l? u? e+/* m++(*) s !n h+/(*) f g+ w+ 
t++ t- y-(*) 

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 21:54:01 GMT
From:      vic@lmsc.lockheed.com (Vic Okumura)
To:        comp.protocols.tcp-ip
Subject:   Std for SMTP enclosures

We have several gateways at our site that translate mail from various
AppleTalk LAN-based mail systems (e.g. MicroSoft Mail, QuickMail) to SMTP. 
The gateways can be set to uuencode or binhex enclosures.   Problems arise
when communicating with other sites via the Internet, because the two
enclosure encoding schemes are incompatible.  For example, if I send a
Microsoft mail message with an enclosure to another site on the Internet
through an SMTP gateway that binhexes the enclosure, and the SMTP gateway
at the receiving site tries to uudecode the enclosure, the enclosure gets
trashed.

Is either one of these encoding schemes (binhex or uuencoding) recommended
as a standard for use on the Internet?  Why can't everyone just get along
and use the same encoding scheme!?! 


-- 
Vic Okumura
1111 Lockheed Way
Dept 19-61 Bldg 102
Sunnyvale, CA  94089

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 22:37:47 UTC
From:      an76226@anon.penet.fi
To:        comp.protocols.tcp-ip
Subject:   FORTCOMING INTERNET BOOKS


FORTHCOMING INTERNET BOOKS

The initial dribble of Internet books has become a torrent, and few  
of us have the energy (or interest) to keep up with them. As a  
service to the Net, we are providing the following sneak-previews of  
books due for release in early April, 1994: 



LeVitus, Bob and Morris, Robert. Stupid Internet Tricks. Hayden,  
Carmel, Indiana, 1994. 


Thirty-Seven really annoying things you can do on the Internet, by  
the author of Stupid Mac Tricks, Stupid PC Tricks, and Incredibly  
Stupid PC Tricks. Includes complete source code for an updated  
version of the Internet worm, as well as the full text of a CERT  
advisory written especially for this book.


Kapor, Mitch. A Thousand and One Ways that You Can Save the Internet.  
EFF, Washington, DC, 1994. 


From recycling your IP address to "just saying no" to the clipper  
chip, this book is your guide to the little things you can do to save  
the Internet.


Gore, Albert. Internet in the Balance. Forward by Tracy LaQuey  
Parker.

Another tour de force by the Vice President, who in this book  
develops a convincing case for a linkage between the problem of  
global warming and the depletion of the IP address space. If the  
current growth in Internet books continues, the Vice President  
predicts that by the year 2001, every human on earth will have  
written a book on the Internet, and the resulting deforestation will  
have resulted in an environmental catastrophe. 



Hahn, Harley. The Complete Harley Hahn, Osborne/McGraw Hill, 1994.  
Forward by Harley Hahn.

"The most complete book on Harley Hahn ever written." - Harley Hahn

Another thorough treatment from the self-congratulatory author of A  
Student's Guide to UNIX. Comes with clip-out coupons for Harley Hahn  
posters, coffee mugs, and memorabilia. Reviews of this book are  
regularly posted to misc.books.technical by (who else?) Harley Hahn.


Leech, Robin. Internet Addresses of the Rich and Famous.

Did you know that Barbara Streisand resided for a while at  
128.57.147.10? That Todd Rundgren briefly inhabited the "data  
cottage" at 192.100.148.10? That the Sun IPC at 128.64.125.74 resides  
on a luxurious yacht? This book is your guide to IP addresses of the  
rich and famous.


Partridge, Craig S. Really, Really, *Really* Fast Networking.  
Addison-Wesley, 1994. A successor to Dr. Partridge's  

previous volume, Gigabit Networking, this book discusses networks so  
fast, they can show an entire 3.5 hour full screen motion picture in  
less than 5 seconds. Speed reading software included.


Sculley, John. Finding the Perfect Job, Internet edition.  
Osborne/McGraw Hill, 1994

The former CEO turned author pens a convincing tract on how use of  
the Internet can improve your career decisions. Includes a free  
two-hour trial of Dow Jones News Retrieval.


Schulman, Andrew. Undocumented TCP/IP. Addison-Wesley, 1994.

This book documents the secret "hooks" for accessing the  
connectionless, yet fully reliable communications mode that has been  
built into TCP/IP all along, and which the implementors have hidden  
from the public for years.  



Smolan, Rick. Riding the Internet Camel. Against all Odds  
Productions, 1994.

In this photo essay, Rick Smolan convincingly compares using the  
Internet to riding a camel across the Australian outback. Like the  
Internet, the Camel provides somewhat uncomfortable transportation.  
And, like the Internet, camels behave somewhat unpredictably at  
times, and are easier to deal with once you "get over the hump."  
Discussion of this book is found in alt.internet.analogies.camel.


Stern, Howard. Internet for Jerks. Howard Sams, 1994.

Now in its twentieth week on the New York Times Best seller list,  
Howard Stern's comprehensive guide to the Internet for the  
sensitivity challenged appears to have hit a responsive chord.


Twain, Mark. The Adventures of Huckleberry Finn, Internet Edition,  
Howard Sams, 1994. Forward by Dr. Vinton Cerf.

The classic adventure story brought up to date; our heroes travel  
down a virtual "data river" in search of adventure.


Wired Magazine. The Wired Guide to CyberFashion. Random House, 1994

From brain implants to pre-packaged upbeat ideas, Wired has almost  
single handly defined the culture of CyberFashion. In more than 300  
profusely illustrated pages, this book defines what the well-dressed  
TechnoHipster will be wearing and thinking in 1994. Includes an  
appendix on more than a dozen appearance-enhancing medical procedures  
with better than a 50 percent chance of survival.


-------------------------------------------------------------------------
To find out more about the anon service, send mail to help@anon.penet.fi.
Due to the double-blind, any mail replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Please report any problems, inappropriate use etc. to admin@anon.penet.fi.

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 23:09:06 GMT
From:      ck112@cleveland.Freenet.Edu (Larry Loiselle)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip, ftp,telnet .... help!


I have a problem for which you may have a solution.  I run a BBS for
the Texas Education Agency (primary purpose is recruitment):
 
 TEA-HR BBS ..................
   SYSOP:         Larry Loiselle
   SYSOP TEL:     (512) 475-1901
   SYSOP FAX:     (512) 463-9838
   BBS TEL:       (512) 475-3689
   BAUD RATE:     300-14400 N81 (V32b/V42b)
   OPEN:          24 hrs/day  7 days/week
   FIDONET:       1:382/6 (JOBS-NOW & ABLENEWS ECHOS)
   KESHERNET:     1:382/6 (K_ED ECHO)
   FAMILYNET:     8:71/5 (JOBSEEK ECHO)
 
It is possible for folks to Telnet to TENET and from there enter
the Window on State Government BBS.  On WOG they can drop down and
enter my BBS:
  
           If  you  have access to  Internet and can get to TENET
           Austin2.ts.tenet (198.213.2.6),  type WINDOW.TEXAS.GOV
           from  the  Unix  prompt  to get access  to  Window  On
           Government BBS.  From here you get into BBS  NEWS  and
           then request the TEA-HR BBS.
 
The problem is that although they can get to our BBS and read the
job listings, etc, they cannot download files or upload their
resumes.  I have xmodem, ymodem, ymodem-g, zmodem, sealink, and
pckermit.  What can I use for a file transfer protocol that will
allow them to transfer files?  MSKermit?  Other?  
 
I do program in Turbo/Borland Pascal and some "C".  Where can I
get a workable protocol driver, specifications, and/or source
code for a beginning?
 
Help?
 
   INTERNET ADDR:
     lloi@tenet.edu (HOME BASE - SEND MAIL HERE)
     ck112@cleveland.Freenet.Edu, ai153@freenet.buffalo.edu
     al628@freenet.HSC.Colorado.Edu, ldl777@freenet.fsu.edu
     ug410@freenet.Victoria.BC.CA, ak440@Freenet.carleton.ca
     loisell@bigcat.missouri.edu, ad385@leo.nmc.edu
     aa3231@freenet.lorain.oberlin.edu, & loiselle@cap.gwu.edu
 
  Larry
 
-- 
Larry D. Loiselle, lloi@tenet.edu, ck112@cleveland.freenet.edu,
FidoNet 1:382/6, FamilyNet 8:71/5 & 8:3000/6, TEA-HR BBS [300-
9600 N81] 7days/24hrs, Moshabel BBS [1200-14400 N81] Sun 8 a.m.
to 2 p.m. and Weds 7-10 p.m. CST.  Shalom folks ...............

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 00:12:54 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone heard of NetCom???

In article <2ll93d$ijq@daffy.cs.wisc.edu> jhorn@snake1.cs.wisc.edu (Jeffrey Horn) writes:
>Has anyone heard of an Internet provider called NetCom?  Better yet, 
>is anyone actually using their service?  I am helping a company get
>connected to the internet and NetCom charges only $400/month for a
>class C frame relay connection while most others (AlterNet, etc.) charge
>nearly three times that amount.  I want to know what the catch is, or 
>if this deal is really as good as it sounds.

I've never heard of them as a network service provider.  Netcom runs a
well-known public access Unix system.

It was originally only available in California, but last year they expanded
to many cities around the country.  It sounds like they did this using a
frame relay network, and now they're reselling bandwidth on their network
to the public.  If they're selling something that they were previously
treating as overhead, this may explain how they can afford such low prices.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 00:18:43 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: rcp client protocol wanted

In article <2lnt6j$455@nkosi.well.com> jime@well.sf.ca.us (Jim Eberle) writes:
>    Does anyone know where I could find the client side of rcp? I'd like
>    to use it for quickie file transfers and ftp looks daunting. I have
>    had previous success w/ rsh thanks to Mr. Stevens "UNP". Rcp client
>    is not in Stevens, Comer, Rago or mentioned in the RFC's.
>    Any help would be greatly appreciated

Rcp uses the rsh protocol.  "rcp host:file localfile" is roughly equivalent
to:

	rsh host cat file > localfile

It doesn't actually use "cat", but an undocumented option to rcp which does
a little bit of negotiation prior to transmitting (e.g. to copy file modes
and dates and verify client/server compatibility).

I've never seen the details of the protocol documented anywhere.  Probably
the only documentation is the BSD sources, which are publicly available on
ftp.uu.net.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 04:32:22 GMT
From:      griffin@admaix.sunydutchess.edu (Patrick J. P. Griffin)
To:        comp.protocols.tcp-ip
Subject:   Subnet address efficiency question

Does subnetting allow efficient use of IP addresses?

Can a class C address be split into four subnets, each with 64 hosts?

It sounds simple enough, given a class C address 198.138.112.x the 
default mask would be: 

11111111 11111111 11111111 00000000
or 255.255.255.0

Define a 2 bit subnet field adjacent to the network number would result in

11111111 11111111 11111111 11000000
or 255.255.255.192

I had originally conceptualized this as extending the network number by 
two additional bits.  However in reading RFC950 by Mogul & Postel, in a 
section dealing with the special meanings of addresses composed of all 
1's or all 0's there appears: 

     It is useful to preserve and extend the
     interpretation of these special addresses in
     subnetted networks.  This means the values of
     all zeros and all ones in the subnet field
     should not be assigned to actual (physical)
     subnets.

Does that mean that by subnetting a class C address using a two bit 
subnet mask the result is two networks of 64 hosts?  This would
result in the loss of half of the available address.

Is this correct? 

Is this the correct RFC to reference?

Have I missed anything important?

Is it mandatory to reserve the two special subnet numbers all 0's and all 
1's?

Thanks,

...pat

--
Patrick J. P. Griffin
Assistant Director of Information Systems
Dutchess Community College
53 Pendell Road
Poughkeepsie, NY 12601
Phone: 914/471-4500 x4604
Fax:   914/471-4869
Internet:  griffin@admaix.sunydutchess.edu

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 05:22:11 GMT
From:      sli@ascii.csc.lsu.edu (Siqiao Li)
To:        comp.os.ms-windows.apps,comp.os.ms-windows.setup,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.windows.x
Subject:   Re: selective appearance of network group under windows

In article <1994Mar1.124419.358@process.com> wadleigh@process.com writes:
>Why not make it simpler:
>
>Windows startup is preceded by a batch file that tests for the network drive.
>If the drive is not present (i.e. the network is not installed), it renames 
>the appropriate workgroup files from *.GRP to *.GRX using an internal list.
>If the drive is present, it renames the .GRX files to .GRP.  If the filenames
>are already proper for the current state, the normal batch error handling skips
>the operation.
>
>After this, you start Windows normally.  Since Windows recognizes Group file by
>the extension .GRP, those that were renamed to .GRX simply do not appear.
>
>Not especially elegant, but at least simple.
>

I guess using ur method, the user will get error msg like 'Can't find ???.GRP'
'cause in progman.ini there is a line pointing to it. 

I think the win.bat method is the general one for putting Windoze on Network.
Basically, win.bat will generate the system.ini or progman.ini, win.ini in
the user's network directory based on the user's machine type, network
interface, etc. while keeping some sections untouched(like the user's 
customer set-up). 

Currently, we are supporting 2 types or machines, Compaq and PS/2. So some
sessions like [386Enhanced] are totally different. But we have some problem
when the user logins in from Compaq and PS/2 simutaneously. You can
imgine why?

From my experience, putting Windoze on network su*ks. Windoze is not
a network system like X. It's just too slow, even for my Compaq 66M.*sigh* 
BTW, the LAN is lightly  loaded under ethrnet monitoring.

Ciao 

--SQL 


-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 05:38:37 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address efficiency question

Patrick J. P. Griffin (griffin@admaix.sunydutchess.edu) wrote:
> Does that mean that by subnetting a class C address using a two bit 
> subnet mask the result is two networks of 64 hosts?

  That is correct.

> This would
> result in the loss of half of the available address.

  That is a common complaint.

-- Ken Mintz

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 06:00:15 GMT
From:      911288c@dragon.acadiau.ca (EDwin Chung)
To:        comp.protocols.tcp-ip
Subject:   is this the idea ??


Dear networkfellow,

	I have a idea about how telnet & ftp can work
	in a Novell Netware from top to bottom layer.
	from the top application & presentation layer
	telnet & ftp program , then through Novell Core
	Protocol , then IPX, finally goto to data link
	& physical layer...

	Telnet & Ftp 
	    |
	Novell Core Protocol
	    |
	   IPX
	    |
	data link layer
	    |
	physical

or through TCP/IP ??

	Telnet & Ftp 
	    |
	Novell Core Protocol
	    |
	   TCP
	    |
	   IP
	    |
	data link layer
	    |
	physical

	Please have some comment on this !!
	I found no help for several month ...
	This is how far what i think .... :{
	Thank you for reading this ....

						edwin

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 20:39:07 -0800
From:      tbrink@crl.com (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address efficiency question

griffin@admaix.sunydutchess.edu (Patrick J. P. Griffin) writes:

>Does subnetting allow efficient use of IP addresses?

Kinda, OSPF allows variable length subnet masking for an entire
adress range.

>Can a class C address be split into four subnets, each with 64 hosts?

Yep, tho throw out the low and high (broadcast and multicast) for each
subnet.

>It sounds simple enough, given a class C address 198.138.112.x the 
>default mask would be: 
 
>11111111 11111111 11111111 00000000
>or 255.255.255.0
 
>Define a 2 bit subnet field adjacent to the network number would result in
 
>11111111 11111111 11111111 11000000
>or 255.255.255.192
 
>I had originally conceptualized this as extending the network number by 
>two additional bits.  However in reading RFC950 by Mogul & Postel, in a 
>section dealing with the special meanings of addresses composed of all 
>1's or all 0's there appears: 
 
>     It is useful to preserve and extend the
>     interpretation of these special addresses in
>     subnetted networks.  This means the values of
>     all zeros and all ones in the subnet field
>     should not be assigned to actual (physical)
>     subnets.
 
>Does that mean that by subnetting a class C address using a two bit 
>subnet mask the result is two networks of 64 hosts?  This would
>result in the loss of half of the available address.

You do get 4 subnets of 64 each.  I have done just this in the past.

>Is this correct? 
 
>Is this the correct RFC to reference?

Yep.

>Have I missed anything important?

Just remember not to use the low and high of each subnet.

>Is it mandatory to reserve the two special subnet numbers all 0's and all 
>1's?
 
>Thanks,
 
>...pat
 
>--
>Patrick J. P. Griffin
>Assistant Director of Information Systems
>Dutchess Community College
>53 Pendell Road
>Poughkeepsie, NY 12601
>Phone: 914/471-4500 x4604
>Fax:   914/471-4869
>Internet:  griffin@admaix.sunydutchess.edu
-- 
    /|                          Tom Brink
 \`o.0'                         tbrink@crl.com
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 08:32:01 GMT
From:      ew@actcom.co.il (Emanuel Wind)
To:        comp.protocols.tcp-ip
Subject:   SNMP-Netview

Hi,
I am looking for a product whuch translates SNMP traps into IBM Netview
alerts (and sends them to IBM mainframe of course), and runs over
MS-Windows.
Any idea ?
Emanuel


-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 18:58 -0500
From:      holdrege@eisner.decus.org (Matt Holdrege)
To:        comp.protocols.tcp-ip
Subject:   routed and ospf

I have a WAN that uses OSPF on dedicated routers. I have one new site that 
has a different class B address. They are 128.200 and I am 120.1. I am
guessing that without a router, I will have to run routed on one of their
unix boxes to link the two networks.

Can routed work with OSPF? I guess that I should run routed -q to inhibit
RIP since I have no RIP routers. What do I need to setup on this station
(128.200.x.x) to reach 120.1.x.x? Keep in mind that the hosts I wish to 
reach are across a local and remote OSPF router.

120.1.1.1  --------120.1.1.28------120.1.43.1	       128.200.1.2
VAX		   router            router|           | DG-UX
					   |	       |	
					   |120.1.43.50|
						PC

Specifically, how can the PC reach both the vax and the DG? I guess that 
the best way would be to run routed on the DG, but I'm open to any 
suggestions.

Thanks!
-matt@phs.com

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 12:39:05 GMT
From:      jin@spdcc.com (Jerry Natowitz)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

In article <w-rolph.348.00079410@ds.mc.ti.com>,
Don Rolph <w-rolph@ds.mc.ti.com> wrote:
> ...
>NIS is certainly not the primary standard outside of SUN and perhaps some HP 
>environments.  DNS is alive, well, and the dominant standard for host table 
>distribution among networks when interacting with the inetnet.
> ...

I dunno, all our UNIX boxes (SunOS, Solaris, HP/UX, Ultrix, and AIX) are
setup for NIS as a primary lookup, with DNS secondary.  Ultrix did come
configured the other way, but was easily reconfigurable.  Can't speak for
our few remaining SCO boxes, but then again, who cares?
-- 
     Jerry Natowitz - jin@spdcc.com

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 12:59:15 +0000
From:      elatar@comptech.demon.co.uk (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

vjs@calcite.rhyolite.com (Vernon Schryver) writes:

> In article <6TymaRj024n@comptech.demon.co.uk> elatar@comptech.demon.co.uk writes:
> > ...
> 
> The FTP hacks wherein the remote FTP daemon automagically synthesizes
> compress tar archives is a common and quite useful scheme.  CCP,

Which is exactly why I am interested in looking at carrying the effect over
to moving mail and news around.

> compression within PPP, is about to be common and so useful.  Compression
> in the modems, such as v.42bis, will remain common and useful.  If you
> care more about moving bits than being right or having your name on a
> protocol, then your choice is among those three.
> 

What I am interested in is looking for ways of improving the effeciency of
getting data from A to B, not just at the A and B ends, but at intermediate
sites along the route. (Less packets, means less work for routers as well).

> 
> Vernon Schryver    vjs@rhyolite.com

For the purposes of this discussion, politics are not an issue. It would be
if people suddenly though oo, yeh - this is a good idea, I want it! (So we
spend the next six years pushing it through internet working groups etc.)

Elatar

+------------------------------------+
| email: elatar@comptech.demon.co.uk |
+------------------------------------+


-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 13:07:21 +0000
From:      elatar@comptech.demon.co.uk (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

vjs@calcite.rhyolite.com (Vernon Schryver) writes:

> That's not accurate on more than one count:
> 
>     1. you can compress typical text by 1.2X to 1.8X with 64Kbytes of
> 	memory and about 5 CPU cycles/byte.  12-bit LZW takes less memory,
> 	only a few more CPU cycles/byte, and does at least 2X on
> 	typical text.
> 
> 	Thus, compressing in the host is not expensive.
> 
>     2. In general, it takes at least a dozen CPU cycles to handle a
> 	single byte of serial-I/O. 

+ a few dozen more to deal with buffering etc. And then multiply this
by 2 times the number of routers the byte has to pass through. Then take
into account the smaller number of packets. (assuming copmression occures
above TCP level)

> 
> 	Thus, compressing in the host can in fact save host CPU cycles.
> 	It can be cheaper for the host to compress the data than to
> 	send it uncompressed.
> 
>     3. Many, perhaps most UNIX boxes that are doing PPP have more spare
> 	CPU cycles than the modems connected to them.  Judging from
> 	their poor performance, many modems do not have enough CPU power
> 	to do their main jobs as well as compress.
> 
> Vernon Schryver    vjs@rhyolite.com

Thank you! - exactly the points I was making. Actually, the amount of
workspace needed for my 12 bit LZW compressor is around 20K, and around 16k
for the decompressor.


Elatar

+------------------------------------+
| email: elatar@comptech.demon.co.uk |
+------------------------------------+


-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 14:42:36 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: X-windows port numbers

Tom Brink <tbrink@crl.com> wrote:
}Anyone recall which port numbers Xwindows uses?  If not mistaken,
}I believe it was in the 6000 range?  Thanks...  tom

   6000 + Display#

Display# is typically 0.

John

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 16:10:57 GMT
From:      mikebat@netcom.com (Mike Batchelor)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: KA9Q NOS 1.1a - routing between two nets over ISDN

Mike Batchelor (mikebat@netcom.com) wrote:
: I am trying to connect two ethernets over ISDN phone lines.  The gateway
: through the ISDN adapter is the sole gateway for the nets at both ends of
: the connection.  This should be simple, but I am losing my hair! :(
 
: I have a PC at each end, running KA9Q NOS v1.1a obtained from
: biochemistry.cwru.edu (N/BEE 921225 v0.85-386-beta) (CWRU/MTA v1.1a). 

I have got the correct routing tables set up now, and it works very well. 
Thanks to Peter Stuermann, Ronald Ogawa, Patrick Installe and Mike Howarth
for their responses.

: route add default isdn
: route add 199.88.131/24 eth
 
: Destination	Len	Iface	Gateway	Metric
: 192.9.201.255	32	isdn		1
: 199.88.131.255	32	eth		1
: 192.9.201.0	24	isdn		0	
: 199.88.131.0	24	eth		1
: default		0	isdn		1

My problem was that I was trying to be too general on the routing tables
at the routers.  I need to do:

route add 192.9.200/24 isdn 192.9.201.2 (on the 199.88.131 side)
and
route add 199.88.131/24 isdn 192.9.201.1 (on the 192.9.200 side)

Ifconfig on the routers takes care of the route from isdn to local net,
and vice versa.  I neglected to specify the remote isdn card as the
gateway to the remote net, and that is where it fell down.  I could have
said 'default' as the destination, but we plan to connect to other remote
nets in the future, so specific routes to specific nets (and specific ISDN
gateways at the remote router) is what is best, I think.  Like I
suspected, I knew just enough to be dangerous! :)

KA9Q is doing a great job now routing between the two nets.  Lots of X
protocol traffic has been exchanged so far, with performance that exceeds
that obtained using NetWare TCP/IP routing, and on smaller PCs, to boot. 
I am a hero. :)

Thanks again to the net for its rapid response.  You all make me look
good time and again.  :)  I hope to return the favor for the next TCP/IP
newbie that comes along.


--
Mike Batchelor      | UseLinuxUseLinuxUseLinuxUseLinuxUseLinuxUseLinuxUseLinux
mikebat@netcom.com  | xuniLesUxuniLesUxuniLesUxuniLesUxuniLesUxuniLesUxuniLesU
------------------------------------------------------------------------------
Q:  What machine does Windows/NT run best on?

A:  A 35mm slide projector.

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 16:28:52 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address efficiency question

Patrick J. P. Griffin (griffin@admaix.sunydutchess.edu) wrote:
> Is it mandatory to reserve the two special subnet numbers all 0's and all 
> 1's?

  RFC-1122 sec. 3.2.1.3 p. 31 6th parag. states that IP addresses "are not
  permitted to have the value 0 or -1" (meaning all-ones) in any of the
  network-number, subnet-number or host-number fields (except for the
  special purposes noted).  I interpret that as a "MUST".

  As for recognizing broadcasts, RFC-1122 sec. 3.3.6 states that a host MUST
  recognize the all-ones form of broadcasts.  But a host (only) SHOULD
  recognize the all-zeros form of broadcasts.

-- Ken Mintz

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 17:47:24 GMT
From:      zdelesde@vt.edu (Zac DeLesDernier)
To:        comp.protocols.tcp-ip
Subject:   MacTCP & Telnet 'protocol'

Little question about the 'telnet' protocol, if anyone can oblige. I
wrote a terminal server for my Mac to run under MacOS & MacTCP. (I
mention MacOS because, under A/UX this would be a piece of cake, no
programming involved. Anyway...) it behaves strangely. I wrote the
program to run totally in the background. First it asks her for a host
name. Then it tries to (asynchrously) open the connection. After the
connection opens, it just loops, reading data from her computer
serially (I know, I would rather use AppleTalk Data Stream Protocol,
but she has a PS/2...) and writing it via TCP, while reading the
incominf TCP data and writing it serially. The end result is a working
terminal server. Here's were the problem starts. At every write
operation to TCP, the second to last byte in the buffer is lost. Try as
I might, I havent found a reason why. (Allow me to clarify what I mean
by 'lost'. Using a debugger it appears that the second to last byte is
sent with the rest of the buffer, the host on the other end just doesnt
recieve it.) Another (minor) problem: My SO muds a lot. (I know...).
Anyway, when she gets a prompt to enter her password, there are two
'garbage' characters preceding the prompt. The first is a Square Root
symbol, the second is a Smiley Face.  For lack of a chart of IBM ASCII,
I dont know what the codes are.  The characters are always the same.
One more thing... When she telnets to my machine, the second to last
byte _is_not_ dropped. Weird. Anyhow. My theory is that there are some
'control sequences' that the 'telnet protocol' uses that I didnt
program for. (I assumed that the 'telnet protocol' was just a raw byte
stream... Guess not.) Can anyone clue me in to what those control
sequences are? (i.e. What makes telnet other than just a raw byte
stream?)

---

Zac DeLesDernier
zdelesde@vt.edu

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 19:32:54 GMT
From:      coert@athena.research.ptt.nl (Vonk C.J.S.)
To:        comp.protocols.tcp-ip
Subject:   Help with specifying protocol on top of TCP

I have to specify a protocol on top of TCP.  As I imagine there must be
numerous people in hyperspace who did the same.  Is there an open
specification available, what I can take for a start.

The protocol has to support image-requests, image-transfer and image-
recognition-result-transfers.  I specially interested in things like
resyncing and initiation.  The image compression standard has been set
already.

Can you give me a head start by refering to some document or so...?

				coert (c.j.s.vonk@research.ptt.nl)
-- 
Coert J. Vonk                                          voice: +31 70 332.3614
                                                         fax: +31 70 332.7807
C.J.S.Vonk@research.ptt.nl                             where: the Netherlands

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 22:50:08 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: X-windows port numbers

In article <2lri8j$464@crl.crl.com> tbrink@crl.com (Tom Brink) writes:
>Anyone recall which port numbers Xwindows uses?  If not mistaken,
>I believe it was in the 6000 range?  Thanks...  tom

Port numbers are listed in the Assigned Numbers RFC (1340 is the most
recent one).  Unfortunately, it doesn't list this!

An X server uses 6000+display#, e.g. the server for foo:2.0 listens on port
6002.  XDMCP uses port 177.  I think the default port for the X font server
is 7000.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Mar 94 11:01:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici

M >Patrick J. P. Griffin (griffin@admaix.sunydutchess.edu) wrote:
M >> Is it mandatory to reserve the two special subnet numbers all 0's and all 
M >> 1's?
M >
M >  RFC-1122 sec. 3.2.1.3 p. 31 6th parag. states that IP addresses "are not
M >  permitted to have the value 0 or -1" (meaning all-ones) in any of the
M >  network-number, subnet-number or host-number fields (except for the
M >  special purposes noted).  I interpret that as a "MUST".

I always figured in his example that you'd have 4 subnets of 64 address
each, and you'd have to reserve the subnet addresses of xx000000 & xx111111.
You lose 8 addresses, not 128.

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Mar 94 04:35:02 GMT
From:      paul@netmanager-2.dotc.gov.au (Paul O'Farrell)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: BOOTPD for Solaris 2.3

cherasar@pegasus.montclair.edu (Ken J. Cherasaro) writes:

>Any information on the following topic would be greatly appereciated:
 
>	I am looking for a BOOTP daemon which will run on a Sun
>	box running Solaris 2.3.  I have tried compiling BOOTPD 2.1
>	with no luck.  I am looking to use this for configuring PC's 
>	running FTP's PC/TCP ver. 2.3.  

Ken

The current and must up to date version of the BOOTP server can be found
at the site it is maintained at:

    ftp.mc.com:/pub/bootp-2.3.6.tar.Z

It compiles without difficulty under Solaris.  The older CMU BOOTP server
is hopelessly out of date, yet many vendors still distribute it.

regards

Paul O'Farrell
paul@dotc.gov.au
Australian Department of Transport


>Thank you,
>Ken J. Cherasaro
 
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>~~	Ken J. Cherasaro						~~
>~~	Technical Analyst, Application Support				~~
>~~	Electronic Data Systems (EDS)					~~

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Mar 1994 06:01:49 GMT
From:      Watanabe.Maki@tko.dec.com (Maki Watanabe)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP on a VAXstation

In article <2lohvh$1vk@lll-winken.llnl.gov>, oberman@icaen.llnl.gov wrote:

> No. DECnet/OSI includes DECnet Phase IV (the current protocol suite) and the
> OSI suite. It does NOT include TCP/IP. Digital's TCP/IP product is available
> for VMS with or without DECnet/OSI (or any DECnet).

It is the "DEC TCP/IP Serevices for OpenVMS".
( I think the name is too long to remember. :-)
-- 
Watanabe Maki                        Internet  :Watanabe.Maki@tko.dec.com
Digital Equipment Corporation Japan  NiftyServe:NBA01637

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Mar 1994 11:21:08 GMT
From:      djh@cs.mu.OZ.AU (David Hornsby)
To:        comp.unix.aix,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: ENET_SET_MULTI: No Space Left on Device

rk@myan.uc.edu (Ramaswamy Krishnan) writes:
>We get the message "ENET_SET_MULTI: No Space Left on Device" when
>we start UAR (Unix Appletalk Router) on our RS/6000 AIX 3.2.0.

This is AIX's way of saying that you have tried to register too many
multicast addresses on a network interface.

AppleTalk Phase 2 uses one "broadcast" multicast address plus one per
AppleTalk zone defined on the local cable (unless two or more zones hash
to the same multicast address).

Note that this is not the total number of zones on your network but the
number of zones defined for the single network number range on the
attached cable.

The various solutions, in rapidly decreasing order of preference, are

	1. find out how to increase the AIX multicast limit (~10)
	   (and let me know).
	
	2. reduce the number of zone names on the cable, you can have
	   up to 255 but this many are rarely absolutely required.
	   (All other local routers must be changed too).

	3. run UAR with a uar.conf file that has the zone list
	   ordered such that the "important" zone names are first.

 - David.

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 94 21:08:23 PST
From:      tpoernomo@csupomona.edu
To:        comp.protocols.tcp-ip
Subject:   Help on these questions.

Help. I'm a student doing research on TCP/IP. I need to get info. on questions
such as :
* why RIP is developed while we have GGP 
* is ARPANET is still in operation, if not why ?
* Can BGP be used to replace EGP for communcation with the backbone ?
* BGP runs on top of TCP. What does it mean ?
Please give me an answer or at least references that discuss these matters.
I would appreaciate all replies.

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 94 01:11:13 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   127.x.x.x (was Re: UDP report card)

In article <Mar.13.17.50.52.1994.1393@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>ftlofaro@unlv.edu (Frank Lofaro) writes:
>
>>Linux USED TO handle 127.x.x.x right for all values of x.
>>Now all 127.x.x.x address other than 127.0.0.1 seem to try to send out 
>>the default route.
>>This is bad, can we bring back the old behavior (thus not violating the RFC's 
>>anymore like we are now)?
>
>I'm not convinced that it's right for 127.0.0.2 to be regarded as
>loopback.  But if you want it, you can get it.  It's all a matter of
>how you set up routing when you turn on loopback.  I just enabled lo
>(which I normally don't have running) using
>
>   ifconfig lo 127.0.0.1
>   route -n add 127.0.0.0 dev lo
>
>Ping works equally well to 127.0.0.1 or 127.0.0.200.

Well the route thing works.
However, I think that all 127.x.x.x addresses should be loopback.

1: It does not break anybody's set up, unless they are violating RFC's
by using the 127 net for their own purposes (they deserve to lose, they
aren't interoperable)
2: Have 127.x.x.x always be loopback is MANDATED by rfc1122.

RFC1122:

--- rfc excerpts follow:

   3. INTERNET LAYER PROTOCOLS ....................................   27
      3.1 INTRODUCTION ............................................   27
      3.2  PROTOCOL WALK-THROUGH ..................................   29
         3.2.1 Internet Protocol -- IP ............................   29
            3.2.1.1  Version Number ...............................   29
            3.2.1.2  Checksum .....................................   29
            3.2.1.3  Addressing ...................................   29

[...]

         3.2.1.3  Addressing: RFC-791 Section 3.2

[...]

            (g)  { 127, <any> }

                 Internal host loopback address.  Addresses of this form
                 MUST NOT appear outside a host.

--- end of RFC excerpts.

Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
comment?  If my interpretation is correct, 127.x.x.x should always be
looped back.

Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
hold?


-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 94 02:14:06 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

ftlofaro@unlv.edu (Frank Lofaro) writes:
>Well the route thing works.
>However, I think that all 127.x.x.x addresses should be loopback.
 
>Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
>comment?  If my interpretation is correct, 127.x.x.x should always be
>looped back.

1) "the route thing" is probably the only solution you're going to get
at the moment.  Where to send packets is by definition the
responsibility of the routing table.  Under 0.99pl15 and later, the
kernel does not make routing entries.  Your startup script is expected
to do so.  That's not specific to 127.  It's true for all networks.  I
think the reason this worked in previous releases is the ifconfig
created routes automatically, and it doesn't do so now.  After some
thought I believe I agree with Linus that enabling an interface
shouldn't create a route.  That's the job of the route command.  There
are different ways one might want to set up the route.

2) The RFC is clear that 127 addresses should never appear outside the
host.  I don't believe it was intended to say that they have to be
implemented on the host.  That is, one could simply drop all packets
to 127, and not receive any of them.  I personally consider 127 to be
a class A network with exactly one host on it, 127.0.0.1.  I believe
that any other 127 address should be considered "host unreachable".
But the point being made by the RFC's is: whatever you do with 127 on
your machine, no address involving it should show up outside your
machine.  In the Linux context, the easiest way to do that is with

  route add 127.0.0.0 dev lo

I think after release 1.0 we're going to tighten up on bogon
prevention.  This includes handling all kinds of illegal addresses,
etc.  I would argue that if the loopback interface is not enabled or
the route not set up, we should find a way to prevent 127 packets from
going out.  Note that even under the old code, if you didn't ifconfig
the loopback, 127 would be sent out the default route.  That's wrong.
One could argue that rc.local is part of the system as a whole, and
it's the responsibility of the people creating setup scripts to make
sure that the loopback interface is always turned on properly.  I
guess I'd be willing to accept that, but it would make me feel
slightly better to know that 127 will never leave the machine.

By the way, the same problem occurs with incoming packets.  If a
machine is misconfigured so that it sends to 127.0.0.1 on an Ethernet,
I believe we should not respond to an ARP response, and if a packet
addressed to 127.0.0.1 somehow comes from the outside, it should be
silently dropped.

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 09:45 MST
From:      gavron@hearts.aces.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on these questions.

In article <1994Mar13.210823.1@clstac>, tpoernomo@csupomona.edu writes...
#Help. I'm a student doing research on TCP/IP. I need to get info. on questions
#such as :
#* why RIP is developed while we have GGP 
#* is ARPANET is still in operation, if not why ?
#* Can BGP be used to replace EGP for communcation with the backbone ?
#* BGP runs on top of TCP. What does it mean ?
#Please give me an answer or at least references that discuss these matters.
#I would appreaciate all replies.

	Is it just me, or when I was a student wasn't it a REQUIREMENT
	that the student do HIS OR HER OWN WORK???

	I don't want to harp on this, but if you're "a student doing
	research"... and you want "an answer or... references" then
	you've got a bad need to go look up what "research" means.

	Hint: it doesn't mean "Post to usenet."

	Ehud

--
Ehud Gavron        (EG76)
gavron@aces.com

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 04:58:15 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP & Telnet 'protocol'

In article <2lsv7c$s3a@solaris.cc.vt.edu> zdelesde@vt.edu (Zac DeLesDernier) writes:
>'control sequences' that the 'telnet protocol' uses that I didnt
>program for. (I assumed that the 'telnet protocol' was just a raw byte
>stream... Guess not.) Can anyone clue me in to what those control
>sequences are? (i.e. What makes telnet other than just a raw byte
>stream?)

Your assumption is very wrong.  The TELNET protocol uses special control
sequences to indicate end of line (since some systems use CR, some use LF,
and others use CR LF), option negotiation (e.g. IBM 3270 emulation) and
parameter setting (e.g. the terminal type).

I suggest you get a copy of the TELNET specification to understand all
these control sequences.  You can also find some of the details explained
in good TCP/IP books such as Richard Stevens's new "TCP/IP Illustrated".
But it's more than can be explained here.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 05:20:23 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: routed and ospf

In article <12MAR199418584408@eisner.decus.org> holdrege@eisner.decus.org (Matt Holdrege) writes:
>Can routed work with OSPF? I guess that I should run routed -q to inhibit
>RIP since I have no RIP routers. 

The only thing that routed does is send and receive RIP packets.  If you
have no routers sending RIP, then there's no reason to run routed at all.

Are you under the impression that routed actually does routing?  On most
Unix systems, this is done automatically by the IP driver in the kernel.
Routed just updates and broadcasts the routing table that the kernel uses.

>				  What do I need to setup on this station
>(128.200.x.x) to reach 120.1.x.x? Keep in mind that the hosts I wish to 
>reach are across a local and remote OSPF router.
>
>120.1.1.1  --------120.1.1.28------120.1.43.1	       128.200.1.2
>VAX		   router            router|           | DG-UX
>					   |	       |	
>					   |120.1.43.50|
>						PC

You need to set up a default route on the DG telling it to send all
non-local packets via the PC, and a default route on the PC telling it to
send non-local packets to the 120.1.43.1 router.  Then you must enable IP
packet forwarding on the PC; the details of this depend on the version of
Unix running on the PC.

>Specifically, how can the PC reach both the vax and the DG? I guess that 
>the best way would be to run routed on the DG, but I'm open to any 
>suggestions.

The PC shouldn't need any help reaching the DG, since they're on the same
network.  The PC's interface to the DG's network should have an address on
that network, so it should automatically route to it.  And a default route
can be used to specify that everything else should go via the router.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 05:26:17 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Std for SMTP enclosures

In article <vic-110394135401@okumura_vic.is.lmsc.lockheed.com> vic@lmsc.lockheed.com (Vic Okumura) writes:
>Is either one of these encoding schemes (binhex or uuencoding) recommended
>as a standard for use on the Internet?  Why can't everyone just get along
>and use the same encoding scheme!?! 

You might as well ask why Microsoft Word and MacWrite use different file
formats.

Different systems have different needs.  Binhex was invented for
Macintoshes, and includes information about which parts of the file are the
data fork and resource fork; this concept doesn't exist on other systems.
Uuencode was invented for Unix, on which files are just a simple sequence
of bytes.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 94 18:52:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici

GR>: I always figured in his example that you'd have 4 subnets of 64 address
GR>: each, and you'd have to reserve the subnet addresses of xx000000 & xx111111.
GR>
GR>That's how I originally thought, but I believe that Ken is saying
GR>that we would lose all the addresses associated with subnet 0 and
GR>subnet -1 (all 1's), since the subnet-number itself can not be 0
GR>or -1.

On closer examination, you're probably correct.  That's a bummer, makes
subnetting kinda' useless in some cases...


-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 17:06:55 -0500
From:      Craig_Everhart@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: Std for SMTP enclosures

Excerpts from netnews.comp.protocols.tcp-ip: 14-Mar-94 Re: Std for SMTP
enclosures Barry Margolin@think.com (794) 

> In article <vic-110394135401@okumura_vic.is.lmsc.lockheed.com>
> vic@lmsc.lockheed.com (Vic Okumura) writes: 
> >Is either one of these encoding schemes (binhex or uuencoding) recommended 
> >as a standard for use on the Internet?  Why can't everyone just get along 
> >and use the same encoding scheme!?! 

What's recommended is MIME as an interchange format. 

		Craig 
 

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 10:34:14 +0000
From:      ash@cellar.demon.co.uk (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   RS-232 over RJ-45; any standards?

Are there any "standards" for the connections to use when running
RS-232 serial connections over RJ-45 connectors?
I note that everyone seems to sell the 25w D-type to RJ-45 adaptors
*unwired*, implying no standard.
What are other people doing??
Thanks.
-- 
+---------------------------------------------------------------------+
| Andrew Hardie                            Telephone: +44 71 219 5996 |
| London, England                                Fax: +44 71 219 5997 |
+---------------------------------------------------------------------+

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 10:54:38 -0000
From:      pcolmer@acorn.co.uk (Philip Colmer)
To:        comp.protocols.tcp-ip
Subject:   Sliding windows?

Do you have any source, or can you recommend any good books which deal with
implementing a sliding window protocol using UDP?

--Philip

---------------------------------------------------------------------
"You must remember that he is operating on a completely different
level to us now. To him, we are the intellectual equivalent of
domestic science teachers." -- Kryten.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 19:16:08 -0500
From:      dave@rochgte.fidonet.org (Dave Stoddard)
To:        comp.protocols.tcp-ip
Subject:   Two unrelated questions from a novice

I've looked through comp.answers and I don't see a faq for this group there,
so I thought I'd brave the waters and ask a couple of questions. Maybe someone
can lead me down the path to enlightenment.

I am looking for a textfile relating to the fundamentals of TCP/IP, things
like: How/When do I subnet, what are the names and/or functions of all the
octets, things like that. If someone can point me to one that can be FTP'd I'd
appreciate it.

The second question is kind of scary viewing the first. How would one go about
connecting a Class "C" address to a Class "B" address? Do I need a special
kind of router, or what?

Thanks to all the kind helpful folks who respond.


-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 94 19:42:29 PST
From:      tpoernomo@csupomona.edu
To:        comp.protocols.tcp-ip
Subject:   re:gavron@hearts.aces on help on these questions.

I'm not a student doing "homework". This is a research that is done by me and
my professors. So please don't jump to a conclusion and give a mean answer.
We already exhausted all sources of information about TCP/IP at our lib. But
thanks for your replies !  ....from tpoernomo@csupomona.edu

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 12:13:29 GMT
From:      gm@informatik.uni-rostock.de (Guenter Millahn)
To:        comp.binaries.ibm.pc.wanted,comp.dcom.lans.ethernet,comp.protocols.tcpip.ibmpc,comp.protocols.pcnet,comp.sys.ibm.pc.hardware.networking,comp.protocols.tcpip
Subject:   SUMMARY: Packet driver for SMC 8216 Network Adaptor

Guenter Millahn (gm@informatik.uni-rostock.de) wrote:
> I'm looking for a PD/free/Shareware packet driver for the SMC8216 because
> I want to use some netprogs who need this. The SMC_WD driver from the Crynwr
> collection doesn't work with this card.
> Also welcome are hints regarding to a driver emulation like dis_pkt.zip.
> Technical University of Cottbus, Computer Science Department

Thanks to all the persons who answered so fast:
	nelson@crynwr.crynwr.com (Russell Nelson)
	thomas.babsch@rz.uni-ulm.de (Thomas Babsch)
	jens@zaphood.oche.de (Jens Bitter)
	"Ben Bonnell" <BONNELLB@topaz.ucq.edu.au>
	manuel@engc.bu.edu (manuel Toledo-Quinones)
	Manfred Kwiatkowski <kwia4000@bronto.zrz.TU-Berlin.DE>
 
Manfred Kwiatkowski <kwia4000@bronto.zrz.TU-Berlin.DE> wrote:
> SMC_WD aus dem Upgrade (pktd11c.zip) laeuft. Gibt es u.a. auf
> ftp.zrz.tu-berlin.de:/pub/dos/packet.
> [SMC_WD from the upgrade (pktd11c.zip) runs. It resides on
> ftp.zrz.tu-berlin.de:/pub/dos/packet.]
 
nelson@crynwr.crynwr.com (Russell Nelson) wrote:
> Look for smc_wd.com version 11.8.3 in pktd11c.zip.
> [-- HOWTOGET.IT]
> The packet driver collection has its own directory devoted to it in
> the SimTel collection, msdos/pktdrvr.  The drivers are there, along
> host that is not accessible by Internet users, however its files are
> available by anonymous ftp from the primary mirror site OAK.Oakland.Edu
> (141.210.10.117) located in Rochester, Michigan, and from the secondary
> mirror sites:
>    St. Louis, MO: wuarchive.wustl.edu (128.252.135.4)
>    Corvallis, OR: archive.orst.edu (128.193.2.13)
> Falls Church, VA: ftp.uu.net (192.48.96.9
>        Australia: archie.au (139.130.4.6)
>          England: src.doc.ic.ac.uk (146.169.2.1)
>          Finland: ftp.funet.fi (128.214.6.100)
>          Germany: ftp.uni-paderborn.de (131.234.2.32)
>           Israel: ftp.technion.ac.il (132.68.1.10)
>      Switzerland: ftp.switch.ch (130.59.1.40)
>           Taiwan: NCTUCCCA.edu.tw (140.111.1.10)
> SimTel files may obtained by e-mail from various ftp-mail servers
> or through the BITNET/EARN file servers.  For details see file
> /pub/msdos/filedocs/mailserv.inf.  Gopher users can access the
> collection through Gopher.Oakland.Edu.  World Wide Web (WWW) and
> Mosaic users can connect to the URL http://www.acs.oakland.edu to
> access the files on OAK.Oakland.Edu.
 
thomas.babsch@rz.uni-ulm.de (Thomas Babsch) sent me the ulpkt111.exe driver.

jens@zaphood.oche.de (Jens Bitter) asked me:
> But, why you don't use the odipkt shim ? (Translate ODI to Packet Driver  
> interface). I think, you find it in the Crynwr collection also.
> And the SMC8216 ODI driver in the card package of course.

manuel@engc.bu.edu (manuel Toledo-Quinones) wrote:
> Call SMC technical assistance at 1-800-992-4762. They will give you the number
> of their bulletin board, from which you can retrieve the driver. I think the
> driver is in the file called edp111.exe.
 
And, last but not least, "Ben Bonnell" <BONNELLB@topaz.ucq.edu.au> offered:
> Probably out of your league, but If you come across any DE200 packet
> drivers in your travells let me know, I'd post myself if I could but alas
> cannot.

--
Guenter Millahn, Systems and Network Administrator
Technical University of Cottbus, Computer Science Department

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 22:44:02 -0500
From:      mthomps@aol.com (M Thomps)
To:        comp.protocols.tcp-ip
Subject:   Personal 'net connection providers

Can any one recommend a provider of internet access for a private individual. 
I would prefer either a SLIP or TCP 14.4 non-dedicated dial-in line....I've
priced one with Interconnect as low as $360.00/month...

Is this really too good to be true? that really isn;t that much money to pay to
be connected to ya'll...

Any advice would be greatly appreciated...

Please email to Mthomps1@Ithaca.edu

YOUR TIME AND EFFORT ARE GREATLY APPRECIATED

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 22:47:04 -0500
From:      mthomps@aol.com (M Thomps)
To:        comp.protocols.tcp-ip
Subject:   PERSONAL INTERNET PROVIDERS (REVISED)



In my previous message I mis quoted Interconnect's personal Slip connection fee
as $360/month...that should be $360.00/YEAR!!!

Any help regarding personal slip accounts with 14.4 dial-in access would be
greatly appeciated.

Please email to Mthomps1@Ithac.edu with advice

THANKS YA'LL FOR YOUR TIME AND EFFORT!

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 14:55:51 GMT
From:      griffin@admaix.sunydutchess.edu (Patrick J. P. Griffin)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici

John Will (john.will@dscmail.com) wrote:
: I always figured in his example that you'd have 4 subnets of 64 address
: each, and you'd have to reserve the subnet addresses of xx000000 & xx111111.
: You lose 8 addresses, not 128.

That's how I originally thought, but I believe that Ken is saying
that we would lose all the addresses associated with subnet 0 and
subnet -1 (all 1's), since the subnet-number itself can not be 0
or -1.

00xxxxxx and 11xxxxxx

Losing just the 0 and -1 host number for each subnet would not be
a problem for me, it just that to support 50 to 60 hosts at a
remote site, it looks like I'll lose half of a Class C address.

By dividing it up with a 2 bit subnet field, I would lose half of
the subnets created.


--
Patrick J. P. Griffin
Assistant Director of Information Systems
Dutchess Community College
53 Pendell Road
Poughkeepsie, NY 12601
Phone: 914/471-4500 x4604
Fax:   914/471-4869
Internet:  griffin@admaix.sunydutchess.edu

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 00:56 -0500
From:      holdrege@eisner.decus.org (Matt Holdrege)
To:        comp.protocols.tcp-ip
Subject:   Re: routed and ospf

In article <2m0s6nINN1r9@early-bird.think.com>, barmar@think.com (Barry Margolin) writes...
>Are you under the impression that routed actually does routing?  On most
>Unix systems, this is done automatically by the IP driver in the kernel.
>Routed just updates and broadcasts the routing table that the kernel uses.

My mistake. I thought that I would need routed to route to a totally
different IP network.

My drawing must have led you to the wrong conclusion. Let me try again:

120.1.1.1---------120.1.1.28-------120.1.43.1|
  VAX     ENET     Router    56K     Router  |
					    E|---120.1.43.50
					    N|       PC
					    E|---128.200.1.2
					    T|	     DG
					     |---128.200.1.10
					     |   Alpha-Micro

Each device has a single Ethernet adapter. The PC is running a cheap TCP/IP 
package called TUN. I had hoped to set a route on the DG to the 120.1.43.0
network and one for the 120.1.1.0 network. All device have a subnet mask
of 255.255.255.0. Is this possible? If not then how can I do this? Keep in
mind that I'm trying to avoid adding anothher route on the routers.

Thanks for any help!

-Matt@phs.com

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 16:56:50 GMT
From:      galileoswieng@cix.compulink.co.uk ("Galileo International")
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages

Thanks all.  Guess I should worry about them a bit then!

Regards
Antony

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 17:43:27 GMT
From:      leilabd@syma.sussex.ac.uk (Leila Burrell-Davis)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware.networking,comp.sys.mac.comm
Subject:   Re: Ethernet Address

John E. Lundgren (jlundgr@eis.calstate.edu) wrote:
: Microsoft LanMan comes with a program ccalled NSTATUS.  It gives the 
: ethernet address, among other things.  The program you want probably has 
: to be for your particular brand of network, but you didn't say what that was.

Once you've got the network software installed there's probably no
great problem, e.g. WATTCP has the tcpinfo program. Many ethernet
adapter manufacturers give you a utility to find the address for
their make of card. I suspect there is no generic way.

Leila
-- 
Leila Burrell-Davis, Computing Service, University of Sussex, Brighton, UK
Tel:   +44 273 678390              Fax:   +44 273 678470
Email: L.Burrell-Davis@susx.ac.uk

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 17:59:04 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article <1994Mar14.011113.2735@unlv.edu> ftlofaro@unlv.edu (Frank
Lofaro) writes: 
>Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
>comment?  If my interpretation is correct, 127.x.x.x should always be
>looped back.
>
>Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
>hold?

I know of at least two commercial versions of IP that have had bug
fixes applied to them that stop them from spitting out 127.* to the
wire.  I'm not aware of anything that supplants this requirement in
RFC 1122.

Any system that does spits 127.* to the wire is broken.

Warner



-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
"... but I can't promote you to "Prima Donna" unless you demonstrate a few
 more serious personality disorders"

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 18:42:37 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

Oliver Yehung Hsu (oliver@cs.utexas.edu) wrote:

: : This is an implimentation issue, NIS also supports "secondary servers".
: : In most DNS implimentations I have seen there is
: : a list (of up to 3) nameservers to try. In most NIS implimentations an
: : approach of send a broadcast and see what responds first is used.
: : I can see little reason why NIS could not use a list of servers to try, in
: : situations such as not having a NIS server on the same subnet a system of
: : broadcast discovery may not work or DNS using broadcast discovery. Or that
: : some combination, e.g. use a broadcast to attempt to find a local server if 
: : no response try a list of servers.
 
: You're correct; NIS does broadcast to find its server.  However, Sun chose to
: implement NIS solely through broadcasting to find a server.  It does not allow
: NIS to go down a list of servers to bind to.
 
: The way NIS works is that a NIS client starts 'ypbind', which causes the client
: to broadcast until it binds to the 1st server that responds.  If it cannot
: bind, it just hangs there.  If the client looses the binding to the server, the
: client will broadcast until a server responds.
 
: Note that since ypbind broadcasts to find a server, these broadcasts do not
: travel over subnets.  Therefore, if your NIS server is not on the same subnet
: as the client, the client cannot bind  to it through broadcasting.  You must
: explicitly tell the client to bind to that particular server with the 'ypset'
: command.

It is actually quite trivial to alter ypbind to read a list of servers.

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 19:07:12 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

Frank Lofaro (ftlofaro@unlv.edu) wrote:

: Well the route thing works.
: However, I think that all 127.x.x.x addresses should be loopback.
 
: 1: It does not break anybody's set up, unless they are violating RFC's
: by using the 127 net for their own purposes (they deserve to lose, they
: aren't interoperable)
: 2: Have 127.x.x.x always be loopback is MANDATED by rfc1122.


:             (g)  { 127, <any> }
 
:                  Internal host loopback address.  Addresses of this form
:                  MUST NOT appear outside a host.
 
: Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
: comment?  If my interpretation is correct, 127.x.x.x should always be
: looped back.

Also a host should NEVER respond to an arp request for such an address.
If it ever gets a datagram addressed to 127.x.x.x on any real device
it should silently ignore it.
(I'm not sure what the status of putting 127.x.x.x in a source route is,
however)

: Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
: hold?


-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 19:10:31 GMT
From:      ncherry@cbnewsg.cb.att.com (neil j.cherry)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article <CMo1yH.A82@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
>In article <1994Mar14.011113.2735@unlv.edu> ftlofaro@unlv.edu (Frank
>Lofaro) writes: 
>>Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
>>comment?  If my interpretation is correct, 127.x.x.x should always be
>>looped back.
>>
>>Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
>>hold?
>
>I know of at least two commercial versions of IP that have had bug
>fixes applied to them that stop them from spitting out 127.* to the
>wire.  I'm not aware of anything that supplants this requirement in
>RFC 1122.
>
>Any system that does spits 127.* to the wire is broken.
>
>Warner

In every commercial unix implementation  I've worked with I can make 127.x.x.x
ride the ether, and I can switch it back. But I've always seen the 127 net
defaulted to l0 (loopback) or something like that.

NJC

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 20:55:05 GMT
From:      ogh@occab.win.net (Olof Haegerlund)
To:        comp.protocols.tcp-ip
Subject:   RFC 1006

Hallo!

Alright you gals and pals! Thank you for your help in finding 
the RFC1006! I'm very grateful!

/Olof Haegerlund

OGH@OCCAB.win.net



-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 21:46:09 GMT
From:      NADEL@litc.lockheed.com (Ron Nadel)
To:        comp.protocols.tcp-ip
Subject:   NFS port numbers and...

I'm analyzing some NFS traffic as it goes through a multimedia router.  I 
notice that there are source and destination port numbers that are paired
between two systems.  I expected to see something like that, but I also see 
these numbers change, although I know there is no other NFS stream active 
between the two hosts.  Can someone tell me the significance of these port 
numbers?  Does NFS set up a port per file transaction, per connection, or is 
there something else going on?

Also, does NFS expect a response back for each packet sent out?  If it does 
expect a response, but does not get one, what are the consequences?

Thanks much,

Ron Nadel

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 22:00:56 GMT
From:      simen@thrasher.lis.pitt.edu (Simen Hagen)
To:        comp.protocols.tcp-ip
Subject:   Standards Survey

INFORMATION PROCESSING STANDARDS QUESTIONNAIRE

     The following questionnaire has been developed as part of an
ongoing research project on Information Technology Standards at the
University of Pittsburgh.  The goal of the research is to identify the
characteristics of standards development processes that contribute to
effective generation of quality standards.

     If you have actively participated in an information standards
process, we welcome your response to the survey.  If you have
experience with multiple standards, we would welcome multiple
responses, but would ask that on each survey all responses be made in
relation to one development process.  Please answer the questions as
they appear and do not alter the question statements or choices.  A
section for additional comments is at the end of the survey.

     Please complete and e-mail your completed survey to
mbsclass@lis.pitt.edu as soon as possible, but not after April 7,
1994.  All individual responses to the survey will be kept
confidential and will be used by researchers exclusively for compiling
and analyzing summary statistics.  After the data has been analyzed,
summarized findings will be available to you via Internet.

     If you prefer total anonymity, please send a copy of the
questionaire to:
          Andrew Snow
          Internet Survey Coordinator
          Suite 702, School of Library and Information Science
          University of Pittsburgh
          Pittsburgh
          PA 15213

     In accord with University of Pittsburgh and Federal guidlines
related to the conduct of reserch involving human subjects, we need to
be clear that your participation in this study is voluntary.  If you
choose to return this survey it is an indication of your consent to be
a part of the study described below and to publication of the data
obtained from the study for scientific purposes.

     This study is being conducted under the supervision of Dr.
Michael B.Spring, Department of Information Science, University of
Pittsburgh, Room 705 LIS, Pittsburgh, PA 15213.  The purpose of this
study is to identify steps in the standard development process and
characteristics human behavior that designate an effective standards
development process.

     There is neither a cost nor a payment involved in this reseach
project. Any information about you obtained from answers to
questionnaires will be kept strictly confidential and your identity
will not be revealed in any description or publication of this
research. (Upon receipt of the returned questionaire, your name will
be stripped from the mail note and discarded.)

     Any questions you have about this research will be answered by
Dr. Spring who may be reached at 412-624-9429, or via email at
spring@lis.pitt.edu.
 
A copy of the results of the study may be obtained by sending an email
request to spring@lis.pitt.edu.  Any questions you have about your
rights as a research subject will be answered by the Office of Senior
Vice Chancellor for Health Sciences at 412-647-8475.

     Thank you for your participation.


QUESTIONNAIRE (C-9)

1. Please state the standard for which you actively participated
   in development:

2. Please state the standards organization and specific
   standards committee/subcommittee of which you were a member:

3. On average, how many times a year did your
   committee/subcommittee meet (1,2,3,4,...)?

4. How many total meetings did you attend in the development of
   this standard?

5. What is the average size of the committees/subcommittees on
   which you participated?

6. Which of the following categories BEST describes your job
   function while engaged in the development of the identified
   standard? (Marketing/Sales, R&D, Product Development,
   Manufacturing, Operations, User Representative, Consortium
   Representative, Systems Integrator)

7. What percentage of your total work time was spent working
   on the development of the standard? (0 to 100 percent)

8. What one characteristic BEST DESCRIBES your personal
   contribution to this standards process (please select only one):
      ability to focus on objectives....................................
      ability to forge consensus........................................
      attention to technical detail.....................................
      ability to initiate proposals to get things moving................
      ability to actively head-off bad ideas............................
      ability to listen attentively and monitor activities to
          ensure process is going in the right direction................
   --------------------------------------------------------------------------
                                                                 total    100

9. How many years had you worked on technical issues
   related to the standards activity?

10.  How many years had you worked in
     information technology field at the time of your involvement?

11.  Please allocate 100 points among the categories that best
     describe your MOTIVATION for participating in this standards
     process (more points to a particular category means better
     description of motivation):
         professional prestige..........................................
         intellectual curiosity.........................................
         desire to positively influence the future......................
         boredom back at the office.....................................
         like to travel.................................................
         supervisor sent me.............................................
         protect the interests of employer..............................
   --------------------------------------------------------------------------
                                                                 total    100

12.  Please allocate 100 points among the skill areas you think are MOST
     IMPORTANT to individuals participating in the standards process
     (more points to an area means more importance):
         time management................................................
         art of negotiation.............................................
         how to run and participate in a meeting........................
         technical expertise............................................
         formal presentations...........................................
         competition and marketing......................................
         international relations........................................
         foreign language proficiency...................................
         product management.............................................
         technology forecasting.........................................
   --------------------------------------------------------------------------
                                                                 total    100


13.  On a scale of 1 to 10, rate the quality of the products (technical
     reports, drafts, annual reports, standards, etc.)
     produced by the committee/subcommittee ( 1 = poor and 10 =
     outstanding).

14.  On a scale of 1 to 10, rate the efficiency of the process
     that produced these products.

15.  On a scale of 1 to 10, rate the effectiveness of the
     chairperson in the management of the process that produced these
     products.

16.  Please allocate 100 points among the following categories
     that best describes the characteristics of the chairperson who
     oversaw these activities:
         able to focus on objectives....................................
         ability to forge consensus.....................................
         attention to technical detail..................................
         ability to initiate proposals to get things moving.............
         ability to actively head-off bad ideas.........................
         ability to listen attentively and monitor activities to
             ensure process is going in the right direction.............
   --------------------------------------------------------------------------
                                                                 total    100

17.  Please allocate 100 points among the following
     characteristics that you believe are necessary for a chairperson
     to succeed:
         able to focus on objectives....................................
         ability to forge consensus.....................................
         attention to technical detail..................................
         ability to initiate proposals to get things moving.............
         ability to actively head-off bad ideas.........................
         ability to listen attentively and monitor activities to
             ensure process is going in the right direction.............
   --------------------------------------------------------------------------
                                                                 total    100

18.  Please identify characteristic(s), if any, of the member of the
     committee/group that you found particularly debilitating or harmful to
     the process.

19.  Please identify characteristic(s), if any, of the chairperson of the
     committee/group that you found particularly debilitating or harmful to
     the process.

Please provide any comments you wish to make about the survey or
the standards development process:

-- 
Simen.
simen@lis.pitt.edu

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 23:11:06 GMT
From:      wmallory@amelia.sp.trw.com (Walter Mallory)
To:        comp.protocols.tcp-ip
Subject:   Re: int14 / remote modem communications

In article <2lolqk$7vo@epenviron.eapi.com> robb@epenviron.eapi.com (Rob Beckman) writes:

>My question is, does anyone know of anyway to allow a pc attached to
>a unix server through tcp/ip use modems attached to unix server through
>int14.  The main focus here is to find a int14 routine so we can take 
>advantage of pc software that use int14.
 
>Any information would be appreciated.

We do that here.  If you have tnglass as part of your tcpip arsenal then run 
it with the command line set for whatever comm program you have that supports 
int14.  We use the network version of Procomm with tnglass.  No support via 
Windows yet (see the tcpip.ibmpc for a thread about this).

I can't help you with the modem pool on the Unix end. Our net 
administrator wrote his own modem pool access code.




Walter Mallory
wmallory@amelia.sp.trw.com
The opinions expressed are wholly my own.

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 01:33:40 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici

In article <2m1ttn$ic4@admaix.sunydutchess.edu> griffin@admaix.sunydutchess.edu (Patrick J. P. Griffin) writes:
>John Will (john.will@dscmail.com) wrote:
>: I always figured in his example that you'd have 4 subnets of 64 address
>: each, and you'd have to reserve the subnet addresses of xx000000 & xx111111.
>: You lose 8 addresses, not 128.
>
>That's how I originally thought, but I believe that Ken is saying
>that we would lose all the addresses associated with subnet 0 and
>subnet -1 (all 1's), since the subnet-number itself can not be 0
>or -1.
>
>00xxxxxx and 11xxxxxx
>
>Losing just the 0 and -1 host number for each subnet would not be
>a problem for me, it just that to support 50 to 60 hosts at a
>remote site, it looks like I'll lose half of a Class C address.
>
>By dividing it up with a 2 bit subnet field, I would lose half of
>the subnets created.
>
>
	With variable length subnet masks you can get much higher
	ultilization.

	254 (no mask)
	or
	2x62+2x30+2x14+2x6+2x2 (182)
	or
	4x30+2x14+2x6+2x2
	or
	4x30+4x6+2x2
	...

	With a strictly classless routing protocol you can use
	all 4 networks. The reason for the restriction is that
	RIP and similar protocols don't pass around network mask
	information but have to derive it from the address itself.

	If you have a classless routing there is no such thing as an
	`all subnets broadcast' which removes the all ones restriction.
	The all zeros restriction can also disappear with a classless
	routing protocol though you need to take care when doing route
	consolidation.

	Mark

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 02:45:11 GMT
From:      jwiegand@opus.temple.edu (The Answer is 42.)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article <1994Mar14.011113.2735@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>In article <Mar.13.17.50.52.1994.1393@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>>ftlofaro@unlv.edu (Frank Lofaro) writes:
 [ ... ]
>>>Linux USED TO handle 127.x.x.x right for all values of x.
>>>Now all 127.x.x.x address other than 127.0.0.1 seem to try to send out 
>>>the default route.
>>>This is bad, can we bring back the old behavior (thus not violating the RFC's 
>>I'm not convinced that it's right for 127.0.0.2 to be regarded as
>>loopback.  But if you want it, you can get it.  It's all a matter of
 [ ... ]
>However, I think that all 127.x.x.x addresses should be loopback.
>1: It does not break anybody's set up, unless they are violating RFC's
>by using the 127 net for their own purposes (they deserve to lose, they
>aren't interoperable)
>2: Have 127.x.x.x always be loopback is MANDATED by rfc1122.
>RFC1122:
 [...]
>            (g)  { 127, <any> }
>                 Internal host loopback address.  Addresses of this form
>                 MUST NOT appear outside a host.
>--- end of RFC excerpts.
>Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
>comment?  If my interpretation is correct, 127.x.x.x should always be
>looped back.
>Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
>hold?
Gee, my sun here misbehaved even though it's right there in
/etc/networks:

localnet	127	loopback

I wonder why the loopback ping went all out to God Knows Where?

jim
a virtual alice in netland

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 11:09:56
From:      Gregory_French@brown.edu (Greg French)
To:        comp.os.ms-windows.apps,comp.os.ms-windows.setup,comp.windows.ms,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: selective appearance of network group under windows

In article <2kq55k$675@agate.berkeley.edu> ucbked@athena (Earl H Kinmonth) writes:
>From: ucbked@athena (Earl H Kinmonth)
>Subject: selective appearance of network group under windows
>Date: 27 Feb 1994 12:54:12 GMT
 
>I run WINQVT using Novell odi drivers under Windoze 3.1.  I offer a
>bootup menu that allows Windoze with and without the network drivers in
>order to maximize the memory that is available to DOS programmes spawned
>from Windoze.  Because the network.grp containing WINQVT always appears,
>there are users (myself included) who try to run WINQVT when the network
>drivers have not been loaded.  This hangs the machine.


Why not write a small program that acts as a loader for WINQVT, and either 
does nothing, or puts up a message box if the network isn't loaded.

For example:

int PASCAL WinMain(hinstCurrent, hinstPrevious, lpCmdLine, nCmdShow){

   if( getenv("NETLOADED") != NULL){

      if ( WinExec("WinQVT", SW_SHOW) < 32) {
         MessageBox(NULL, "Error loading program.", "Error", MB_ICONSTOP);
      }

   }else{
   MessageBox(NULL, "Network not loaded.", "Error",MB_ICONEXCLAMATION);
   }

   return FALSE;
} 


-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 07:01:12 GMT
From:      roye@zeus.datasrv.co.il (Roy Avidor)
To:        comp.protocols.tcp-ip
Subject:   nos? 1001 question ?!

Hi !
We are using NOS software for connecting with slip .
and we have some problems with the terminal type .
i want to change it to VT102 but I can't find were I can change it.

Is there some-one that can help me?

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 94 08:17:05 GMT
From:      wm@Materna.DE (Wilfried Marre)
To:        comp.protocols.tcp-ip,comp.client-server,comp.misc
Subject:   Accounting in networks

Hi folks !

Does anyone have information about accounting in networks?

Exscpecially:
- Which accounting data are available on router (e.g Cisco, Novell MPR)
- Produkts or/and tools to analyse the accounting data.
- Books or articels discribing the accounting in networks and their problems?

Thanks in advance

Pleas reply e-mail to 
      wm@materna.de     or
      wilfried.marre@materna.de    or
      write a follow up

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 10:30:05 GMT
From:      pelle@ost.fdata.se
To:        comp.protocols.tcp-ip
Subject:   "Manual UDP"

Any help on the following would be appreciated! :

I'm trying to write a pretty simple snmp client.
In order to verify my understanding of the protocol I would first like
to generate the UDP packages by hand (the same way as you could use
telnet "host" 25
and then manualy feed the commands to the smtp-server ,to verify that you
understand the SMTP protocol).
So my question is :is there some utility you could use (manually) to generate
udp ,the same way as telnet let you manually generate tcp?



-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 10:49:13 GMT
From:      galileoswieng@cix.compulink.co.uk ("Galileo International")
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages

Thanks for all the responses

Regards
Antony

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 11:15:04 GMT
From:      iiitac@uk.ac.swan.pyr (Alan Cox)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article <CMo1yH.A82@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
>I know of at least two commercial versions of IP that have had bug
>fixes applied to them that stop them from spitting out 127.* to the
>wire.  I'm not aware of anything that supplants this requirement in
>RFC 1122.
>
>Any system that does spits 127.* to the wire is broken.

Any system which when supposedly 'correctly configured' spits 127.* to the
wire is broken. On that basis Linux is ok. On the other basis nothign is OK
because as route I can force the issue anyway.

Alan


-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 94 11:18:37 GMT
From:      hart@apanix.apana.org.au (Leigh Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: Std for SMTP enclosures

vic@lmsc.lockheed.com (Vic Okumura) writes:

>We have several gateways at our site that translate mail from various
>AppleTalk LAN-based mail systems (e.g. MicroSoft Mail, QuickMail) to SMTP. 
>The gateways can be set to uuencode or binhex enclosures.   Problems arise
>when communicating with other sites via the Internet, because the two
>enclosure encoding schemes are incompatible.  For example, if I send a
>Microsoft mail message with an enclosure to another site on the Internet
>through an SMTP gateway that binhexes the enclosure, and the SMTP gateway
>at the receiving site tries to uudecode the enclosure, the enclosure gets
>trashed.
 
>Is either one of these encoding schemes (binhex or uuencoding) recommended
>as a standard for use on the Internet?  Why can't everyone just get along
>and use the same encoding scheme!?! 

I think you will find that the majority of sites on the Internet
use UUENCODE/DECODE.  Most (all??) unix sites have these tools, 
many VMS sites also have them.  There are versions available
for MS-DOS and I'm sure many other operating systems.

I personally havn't seen or used BinHex - then again, I tend to
stay away from Macs.

If you can source uu(en|de)code for the Macs, then I would suggest
using that as your "standard".  If anyone doesn't have uu(en|de)code,
I'm sure there's a machine close by to them that will have it :)


Cheers

Leigh
--
                                 Leigh Hart
                               C/- PO Box 758
                          North Adelaide  SA  5006
 hart@eppie.apana.org.au  hart@apanix.apana.org.au  hart@cleese.apana.org.au

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 12:27:13 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...

In article <NADEL.120.000DC558@litc.lockheed.com> NADEL@litc.lockheed.com (Ron Nadel) writes:
> I'm analyzing some NFS traffic as it goes through a
> multimedia router.  I notice that there are source and
> destination port numbers that are paired between two systems.
> I expected to see something like that, but I also see these
> numbers change, although I know there is no other NFS stream
> active between the two hosts.  Can someone tell me the
> significance of these port numbers?  Does NFS set up a port
> per file transaction, per connection, or is there something
> else going on?

On an NFS server, a number of nfsd kernel processes listen for
incoming requests on UDP port 2049. On the client, the kernel creates
a UDP socket on the fly if needed. This gives the outgoing request a
source port number for the server to send its reply to. The port
number used is effectively random: usually the first free UDP port
between 512 and 1023. The NFS client uses one of these port numbers,
fires the request at port 2049 on the server and waits for a reply.
One of the server nfsd processes gets this request, carries out the
transaction and returns a result to the waiting client process
"listening" on the port number it sent the request from. When the
reply is received, the client discards the socket it created for the
NFS request and returns a result to the user process that initiated
the request.

BTW, the client biod processes use the same kernel code to instantiate
sockets/port numbers. The only difference is that these sockets don't
get discarded and recreated for each NFS request that they deal with.

> Also, does NFS expect a response back for each packet sent
> out?  If it does expect a response, but does not get one,
> what are the consequences?

Every NFS request gets a reply which indicates the success or failure
of the request and may also include some data - the result of an NFS
read for instance. If the reply goes astray, the client repeats the
request. The server is supposed to do the right thing when this
duplicate request arrives. This procedure continues until the client
gets a reply or gives up, depending on how the NFS mount was done.

Although it should "never happen", interesting situations can arise
when servers don't recognise stale and/or duplicated requests. For
instance, if the reply to a NFS CREATE request is lost, the server
would fail the repeated request from the client EEXIST if it didn't
realise that the client was repeating an earlier request because the
reply went missing. This would mean that the client would think the
request had failed even though it had actually succeeded and the file
had been created OK.

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 14:05:48 GMT
From:      suresh@cs.uh.edu (Suresh Arunachalam)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.unix.admin
Subject:   tcp option in NFS

Hi!
I am trying to run NFS via tcp instead of UDP for testing purpose,
We have Sun Sparc Stations running Solaris 2.3. I tried the -p option 
with the nfsd command and I am not sure whether this is the right way to
invoke nfsd through tcp. Could some gurus enlighten me the way to run nfs
via tcp. I'll very much appreciate it.  
You can reply to suresh@uh.edu or arunas01@nmb.com.
Thanks,
Suresh.
-- 
email: suresh@uh.edu             phone: (713)743 9156
       suresh@uhou (BITNET)
       uhou::suresh (THEnet or DECnet)


-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 23:11:41 -0500
From:      sgt@iia.org (Stephen Tell)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on client-server implementation ..

In article <2l7jfv$1sup@locutus.rchland.ibm.com> goli@rasii.rchland.ibm.com (Srinivas Goli) writes:
>You should refer to the book
 
>Unix Network Programming -- Richard Stevens
>	Assuming that your need is to build on unix machines. The book has quite a few examples
>of how to build client server applications along with source code. Another book which is equally
>good is Internetworking with TCP/IP Comer and David Stevens.


Another good one is:

Power Programming with RPC, by John Bloomer
O'Reilly & Associates, 1992.  ISBN 0-937175-77-3

Lots of examples of using RPC (Remote Procedure Calls) to implement
client-server applications.  The example code in the book is available via
anonymous FTP from ora.com.

-- 
Steve Tell       tell@cs.unc.edu    H: +1 919 968 1792   #5L Estes Park apts
CS Grad Student, UNC Chapel Hill.   W: +1 919 962 1845   Carrboro NC 27510


-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 15:54:49 GMT
From:      longyear@netcom.com (Alfred Longyear)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

It seems to me that the address 127.x.x.x is not special. What is special
is the loopback device.

When the "lo" device is brought up, it will register itself as IP address
127.0.0.1. You must still create the route to the loopback device as you would
for any other device in your configuration.

If you don't have a route for 127.x.x.x to the "lo" device, but have a default
route to an ethernet controller, for example, then requests to 127.0.0.1 will
go out the wire just as requests to any other IP address. Until a route is
created to the loopback device, the address 127.x.x.x is an unknown address
just as if _I_ asked for address 192.83.17.1. It would need ARP to resolve it
to a real ethernet address and subsequently the request would go out the
default route.

So, it is not the "implementation of TCP/IP" which is broken, but the
operator's setup of the TCP/IP configuration which is broken. There is nothing
"magical" about the address 127.0.0.1 other than the convention that it is the
loopback device and is normally _configured_to_route_ back to your own machine.

I guess what I am saying is that the routing of frames is not a function
solely of the device's IP address, nor is it a function soley of the device
type. There is no magical "override" which says that "Oh, you have address
127.0.0.1. I won't bother to look it up. I know that this is the loopback
device and will simply put it there". It is a function of the routing tables
within the system. If the routing tables do not include a route for the 127
address, then it will use the default route or fail if there is no default
route. If it must use the default route to some eithernet controller then it
will need an ethernet address. This means that it will ask for the ARP
translation of 127.0.0.1.

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 16:31:07 GMT
From:      sybesma@unirsvl.rsvl.unisys.com (Eric Sybesma)
To:        comp.protocols.tcp-ip
Subject:   Routers and Broadcasting

Okay, I am curious about UDP broadcasts to different
lan segments.

1) First off, what exactly is a router.  Does it
   give visibility from LAN A to all hosts in LAN B.
   If LAN B has a router to LAN C, can LAN A in turn
   see all of LAN C?  Please elaborate.

2) Second.  What is a bridge?  Does it give visibility
   in a different way than a router.  If so , how.

3) Third, If I send a UDP broadcast to A.B.C.255, will
   all the hosts on A.B.C get the broadcast?  What if I
   had to go through several routers to get to A.B.C.

4) And finally, what is the difference between broadcasting
   to A.B.C.255 and A.B.C.0 ?  And what does a broadcast to	
   a CLASS A or B network look like.

Thanks for your time.  Email is appreciated, as well as any
good references, etc...

es

-- 
Eric Sybesma          |_sybesma@unirsvl.rsvl.unisys.com_|_(612) 635-3380_|
Unisys Corporation    |"Those who live in glass houses shouldn't."       | 
Roseville, MN 55113   | DISCLAIMER: All included Disclaimers are invalid.|

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 16:53:22 GMT
From:      jpbogers@reks.uia.ac.be (John-Paul.Bogers)
To:        comp.protocols.tcp-ip
Subject:   READ ME URGENT


Dear Friends,
 
  My name is Dave Rhodes.  In September 1988 my car was
reposessed and the bill collectors were hounding me like
you wouldn't believe.  I was laid off and my unemployment
checks had run out.  The only escape I had from the
pressure of failure was my computer and my modem.  I
longed to turn my advocation into my vocation.
  This January 1989 my family and I went on a ten day
cruise to the tropics.  I bought a Lincoln Town Car for
CASH in Feburary 1989.  I am currently building a home on
the West Coast of Florida, with a private pool, boat slip,
and a beautiful view of the bay from my breakfast room
table and patio.  I will never have to work again. Today I
am rich!  I have earned over $400,000.00 (Four Hundred
Thousand Dollars) to date and will become a millionaire
within 4 or 5 months.  Anyone can do the same.  This money
making program works perfectly every time, 100% of the
time.  I have NEVER failed to earn $50,000.00 or more
whenever I wanted.  Best of all you never have to leave
home except to go to your mailbox or post office.
  In October 1988, I received a letter in the mail
telling me how I could earn $50,000 dollars or more
whenever I wanted.  I was naturally very skeptical and
threw the letter on the desk next to my computer.  It's
funny though, when you are desperate, backed into a
corner, your mind does crazy things.  I spent a frustating
day looking through the want ads for a job with a future.
The pickings were sparse at best.  That night I tried to
unwind by booting up my computer and calling several
bulletin boards.  I read several of the message posts and
than glanced at the letter next to the computer.  All at
once it came to me, I now had the key to my dreams.
I realized that with the power of the computer I
could expand and enhance this money making formula into
the most unbelievable cash flow generator that has ever
been created.  I substituted the computer bulletin boards
in place of the post office and electronically did by
computer what others were doing 100% by mail.  Now only a
few letters are mailed manually.  Most of the hard work is
speedily downloaded to other bulletin boards throughout
the world.  If you believe that someday you deserve that
lucky break that you have waited for all your life, simply
follow the easy instructions below.  Your dreams will come
true.
 
  Sincerely yours,
 
  Dave Rhodes
 
 
INSTRUCTIONS
Follow these instructions EXACTLY, and in 20 to 60 days
you will have received well over $50,000.00 cash, all
yours.  This program has remained successful because of
the honesty and integrety of the participants.  Please
continue its success by carefully adhering to the
instructions.
 
Welcome to the world of Mail Order!  This little business
is a little different than most mail order houses.  Your
product is not solid and tangible, but rather a service.
You are in the business of developing Mailing lists.  Many
large corporations are happy to pay big bucks for quality
lists.
 
(The money made from the mailing lists are secondary to
the income which is made from people like yourself
requesting that they be included in that list.)
 
  1)  Immediately mail $1.00 to the first 5 (five) names
listed below starting at number 1 through number 5.  Send
CASH only please (total investment $5.00). Enclose a note
with each letter stating: "Please add my name to your
mailing list." For other countries the equvielent amount
may be sent, e.g. in Hong Kong Send HK$10 as this is the 
lowest denomination note.
 
  (This is a legitimate service that you are requesting
and you are paying $1.00 for this service).
 
  2)  Remove the name that appears number 1 on the list.
Move the other 9 names up one position. (Number 2 will
become number 1 and number 3 will become number 2, etc.)
Place your name, address and zip code in the number 10
position.
 
  3)  Post the new letter with your name in the number 10
position into 10 (Ten) separate bulletin boards in the
message base or to the file section, call the file,
MAKE.MONEY.FAST.
 
  4)  Within 60 days you will receive over $50,000.00 in
CASH.  Keep a copy of this file for yourself so that you
can use it again and again whenever you need money. As
soon as you mail out these letters you are automatically
in the mail order business and people are sending you
$1.00 to be placed on your mailing list. This list can
than be rented to a list broker that can be found in the
Yellow Pages for additional income on a regular basis.
The list will become more valuable as it grows in size.
This is a service.  This is perfectly legal. If you have
any doubts, refer to Title 18, Sec. 1302 & 1341 of the
postal lottery laws.
 
 NOTE: Make sure you retain EVERY Name and Address
sent to you, either on computer or hard copy, but do not
discard the names and notes they send you.  This is PROOF
that you are truely providing a service and should the IRS
or some other Government Agency question you, you can
provide them with this proof!
 
Remember as each post is downloaded and the
instructions carefully followed, five members will be
reimbursed for their participation as a List Developer
with one dollar each.  Your name will move up the list
geometrically so that when your name reaches the number
five position you will be receiving thousands of dollars
in cash.


  1. Ravi Murjani
  3 Henderson Road
  Jardines Lookout
  Hong Kong
 
  2. Sanjay Purswani
  2-D, Kowloon tong garden,
  No.1 Cambridge rd.,
  Kowloon,
  Hong Kong.
 
  3. Pual Law
  Flat A,11/F Yan Yee bldg.,
  Kin Yip Street,
  Yuen Long,N.T.,
  Hong Kong.
 
  4. Patrick Wong
  9A Fung Yau Street North,
  Grd Flr Shop 19,
  Yuen Long,N.T.,
  Hong Kong
 
  5. Ho Chi Kit
  P.O.Box 428,
  Tuen Mun Central Post Office,
  Tuen Mun,
  NT,
  Hong Kong
  
  6. Cindy Leung
  Flat 6, 18/F
  Yan Yuet House
  Yan Shing Court
  Fanling, N.T.
  Hong Kong
 
  7. Aaron Teche
  655 Sellery A Hall
  821 W. Johnson St.
  Madison, WI  53706-1798
  USA

  8. Thomas Ermesjo
  Lundsveien 16
  1820 Spydeberg
  Norway

  9. John-Paul Bogers
  Rederijkersstraat 90
  2610 Wilrijk
  Belgium

  10. Kurt Segers
  Groeningelei 65
  2550 Kontich
  Belgium

The following letters were written by participating
members in this program.
 
To Whom It May Concern:
 
  About six months ago I received the enclosed post in
letter form.  I ignored it.  I received about five more of
the same letter within the next two weeks.  I ignored them
also.  Of course, I was tempted to follow through and
dreamed of making thousands, but I was convinced it was
just another gimmick and could not possibly work.  I was
wrong!  About three weeks later I saw this same letter
posted on a local bulletin board in Montreal.  I liked the
idea of giving it a try with my computer.  I didn't expect
much because I figured, if other people were as skeptical
as I, they wouldn't be too quick to part with Five
Dollars.  But, I buy lottery tickets weekly in my province
and have nothing to show for it but ticket stubs.  This
week I decided to look at this as my weekly lottery
purchase. I addressed the envelopes and mailed out one
dollar in each as directed.  Two weeks went by and I
didn't recieve anything in the mail.  The fourth week
rolled around and I couldn't believe what happened!  I
can't say I received $50,000, but it was definitely well
over $35,000!  For the first time in ten years, I got out
of debt.   It was great.  Of course, it didn't take me
long to go through my earnings so I am using this
excellent money opportunity once again.  Follow the
instructions and get ready to enjoy.
 
  Please send a copy of this letter along with the
enclosed letter so together we can convince people who are
skeptical that it really works!
 
Good Luck,
 
Charles Kust
St Agathe Que.
 
Another letter:
  I tried a similar program in which the cost was $5.00
per response.  In that one the return was about 3%.  Since
I did not have a modem I sent out letters regular mail.  I
created a few mailing labels and printed out all of the
labels on pressure sensitive tape.  The first mailing that
I used the $1.00 dollar per reponse approach I started to
get return mail in just over one week!  I sent out 200
letters instead of 100 that is required if you use the
mail instead of the bulletion boards.  Additionally, I
included as many friends, relatives, classmates, that I
could think of in order to encourage their participation
if they happened to recognize my name, so my percentage of
gain was higher.  I am trying again with 500 letters to
see if I surpass the $141,000 of the last time. You just
won't believe it until you try.
Best Wishes,
Mark Garner
Dallas Texas
 
 
Additional Notes:
 
  This system works equally well if mailed out
manually.  Mind you it takes more effort to hand address
the envelopes and the cost goes up proportionately to
cover the postage and envelopes. You must also photo copy
the instructions, cross out the name in number one
position, write in your name in the number ten slot and
change the rest of the numbers accordingly. (It might be
neater to use white out or paste over the names.) In order
to achieve the same results you must send out the $1.00
dollar to the first five names and then send out another
100 letters with copies of the program enclosed.  It has
been suggested not to put a return address on the outside
of the envelope in order to encourage the recipient to
open it.  The return will approximate that then received
from the posts listed on the bulletin boards.
 
  Hello,

My name is JP Bogers and I'm playing this game for the third time.
The first time I played the postal system and it brought me some
17.500 USD. I bought myself a small sailing boat. The second time,
using this system, I earned 23.500 USD. I know, a long way from 50.000,
but not bad, huh. I bought a new car.

  Hello, my name is Steve Prester.  As you may have
noticed I'm the tenth name on this list, so I do not have
a rags-to-riches story to tell here.  However, I did make
a phone call to the 2nd name on this list, Ernest Goyette.
Did he have a rags to riches story to tell? Not exactly,
but then I found out that he did not follow the
instructions precisely.  You see, Ernest lost faith in
the program before he had finished following instructions.
He only uploaded this file on one BBS, which happens to be
operated by Darryl McGinnis, the 3rd name on this list.
Ernest told me that he has received $92.00 to date
(1/6/90).  I realize this is far from the $50,000.00
promised at the first of this file, yet one must keep
two things in mind:
 
 1. $92.00 is almost 10 times his initial investment, and
 it only took about an hour of his time (there's
 nothing to lose).
 
 2. This program works mathematically on an exponential
 scale.  In other words, for every one BBS that this
file is uploaded onto, it should spread to at least ten
other BBSs and possibly a whole lot more. So, if Ernest
had uploaded his file on all ten BBSs, he should have at
least gotten a hundred-fold of what he has, which would
be $9200.00.  Not bad for a few hours work and a $6.25
investment (including postage).
 
Finally, I would like to exhort those who become involved
in this program to maintain its integrity by being honest.
It is the only way that it can possibly pay off.  In other
words, be sure to enter your name at the bottom of the
list and not in one of the top five positions (actually
this would be robbing yourself since it is while your name
is in the lower positions that it gets multiplied
exponentially over hundreds of BBSs).  And, of course,
send your $1.00 off to the first five names.  As I write
this I have not made a penny (that's because I have not
uploaded this yet), but I thought you might like to hear
from someone at the bottom of the list, instead of someone
claiming rags-to-riches.  I hope such is true, and I'm
sure it will be if we all stick with it.  The potential is
definitely here!
 
P.S. Call me if you get rich.
 
Hello,

I'm Kurt Segers from Belgium and was inspired by the money earned
by a friend of mine. He honestly bought himself a sailing boat and
a new sportscar with the profit of this "game". Attracted by this
luxerous moneymaking by simply spending 5 USD enormously teashed
my attention.

Hello,
I am the current #10 on the list, I too am sceptical.
Well what do we  all have to lose.  It is worth a try
in order to realize some substantial gain.  Don't any of you
out there want to upgrade your PC's.  I certainly do, but
can't afford to.  I hope that this program will make enough
cash in order to buy a super system.
Nua Nicaj

----------------------------------------------------
Hey There! Glad your thinking about this seriously because
I am! If all these people are making money then why not be
included with them and get some also? I'm going to be #10 on
this list, and Im uploading it everywhere! If you have the
access :) then follow through, upload it, and see what happens!
Hey, Imagine earning enough to buy a 486? or one of those high
speed modems that cost hundreds of dollars? What about buying
your OWN BBS ? Who wouldnt want to be the Sys-Op of their VERY
OWN board? I know I wouldnt mind :) What do you have to lose
but 5 bucks compared to the hundreds and thousands you CAN make?
I know Im down.. Will you be the very next to EARN some cash?
  Talib Khan
----------------------------------------------------
Hello, I'm Stephanie Kemach and I am now the tenth person on
this list.  I'm trying out this idea in the hopes that it will
pan out, but I've never seen anything like this before.  Still,
for a meager investment of $5.00, what do any of us have to lose?
It's worth a try and I'm trying it out now.  Good luck to everyone
else who uses this great-looking money-making idea.
----------------------------------------------------
This is John Gibbs, call me Gibber.  Stephanie is no longer the
last on this list, hopefully I can say the same soon.  I agree that
the investment is quite meager, let's see if everybody can benefit
from it.  Just a note that Canadians will be happy to accept
American money at par if it is possible.  Good luck to all!  Bon
Chance, Au Revoir.
----------------------------------------------------
Hi this is Jurgen Kreisel, please add my name to the mailing list.
I am the new kid on the block as the last person on this list. I have
always been told that if it sounds to good to be true it probably
is, but what the hay I can blow 5.00 at the video store and get
nothing for my money either. Well here goes nothing.
----------------------------------------------------
Hi! I guess I'm now No#10. I have never done anything like this before.
I never even reply to chain letters. I guess I am doing this one coz I
think its actually gonna work. If it doesn't I simply lose a bit of 
money (which I probably would have lost at the race meet tommorow 
anyways). Time to find out if this thing really works....
----------------------------------------------------
Well gee shucks! ...i guess i'm now the 10th dude on this list, as always
u might feel that this is NOT going to work and that people are not gonna
start doing this crap and mailing people money, but hey! ...it's only 5 bucks
US isn't it? ...what've u got to lose eh? i'm certainly gonna try since right
now a bit of money wouldn't be bad while trying to get into a good university
with all the hassles of school!
...seeya lateR! =)
Sanjay Purswani
  09/02/94
---------------------------------------------------
Hi! I guess I'm No#10 now.I think it is a interesting game for me and u to
have a money making.I have never heard it before,but,at least,i believed it
can let me to upgrade the computer.
-----------------------------------------------------------------------------
Well! This chain letter can give me a hope ,it just cost me $10.
if it is workable,I have many times of this $10.So try this.
It is hoped that the result will be appeared as fast as possible.
-----------------------------------------------------------------------------
Now, I am No.#10.!!!!! I think this chain letter
investment is quite interesting......and worthy...
So..I try it now.....and It can help anyone to upgrade
his computer only by investment of "US$5.00" or "HK$50.00".
Finally, Anyone see this mail, please join this activity..
and please be honest!!! Don't add your name at the top 5 instead of
the bottom of the mailing list!!!!!!! Furthermore, Please send the
money to the first 5 people!!!!
 
Kit, 13/2/1994
-----------------------------------------------------------------------------
Do everyone want to try this!?  It is quite interesting.                    
I try it now.  

Cindy 14/3/1994
-----------------------------------------------------------------------------
I'm broke, so here goes nothing [and $5 ;) ]
Maybe I'll actually get some money.    Send the $1US to the first 5 people!!!
-----------------------------------------------------------------------------








-- 
--------------------------------------------------------------------
J.P. Bogers, M.D.
Universitaire Instelling Antwerpen (UIA)
Lab Pathology

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 23:32:41 CST
From:      Rich Chong <U41602@uicvm.uic.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address efficiency question

>Patrick J. P. Griffin (griffin@admaix.sunydutchess.edu) wrote:
>> Does that mean that by subnetting a class C address using a two bit
>> subnet mask the result is two networks of 64 hosts?
>
>  That is correct.
>
Well, not exactly correct. since the host addresses of all 0's and all 1's
have reserved meanings, you really only end up with 2 subnets of 62 hosts.

>> This would
>> result in the loss of half of the available address.
>
>  That is a common complaint.
>
>-- Ken Mintz

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 18:11:48 +0000
From:      elatar@comptech.demon.co.uk (Adam Goodfellow)
To:        comp.terminals,demon.ip.support,comp.protocols.tcp-ip,comp.protocols.misc,comp.unix.questions
Subject:   VT100, 102 & 220 Terminals

Does anyone have or know where to find documents covering the full
specifications for VT100, 102, 220 terminal emulations as I need to
embed such a beast in an application.

Please reply by email.

Thanks in advance...

Elatar

+------------------------------------+
| email: elatar@comptech.demon.co.uk |
+------------------------------------+


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 18:12:02 GMT
From:      kerch@parc.xerox.com (Berry Kercheval)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on these questions.

gavron@hearts.aces.com (Ehud Gavron) writes:

>In article <1994Mar13.210823.1@clstac>, tpoernomo@csupomona.edu writes...
>#Help. I'm a student doing research on TCP/IP. I need to get info. on questions
>	I don't want to harp on this, but if you're "a student doing
>	research"... and you want "an answer or... references" then
>	you've got a bad need to go look up what "research" means.
>	Hint: it doesn't mean "Post to usenet."

Not enough coffee this morning, Ehud?  Why not give the poor guy a
pointer to some useful references, like Tanenbaum's "Computer
Networks" (Prentice Hall, ISBN 0-13-162959) or Stevens "Unix Network
Programming" (QA76.76.O63S755) instead of lambasting him for trying to
find out his information?  Or at least suggest some useful catalog
numbers for the library (I suggest QA76.76 and the vicinity of TK5100)

It's not your job or mine to police the students.  If you don't want
to help him, fine, but why assume the worst?  Even so, why not give
him a useful pointer?  I look on the posting to Usenet as more in the
line of "Help, where do I look" than "Please do my work for me".

And besides, the Net is one of the BEST places to find out about the
cutting edge of networking, and the truth about its history (and all
the lies about its history too :-).

  --berry

--

Berry Kercheval :: kerch@parc.xerox.com 
"...start with Plan 9, which is free of sin..." -Mark V. Shaney


-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 19:02:02 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

Warner Losh (imp@boulder.parcplace.com) wrote:
: In article <1994Mar14.011113.2735@unlv.edu> ftlofaro@unlv.edu (Frank
: Lofaro) writes: 
: >Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
: >comment?  If my interpretation is correct, 127.x.x.x should always be
: >looped back.
: >
: >Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
: >hold?
 
: I know of at least two commercial versions of IP that have had bug
: fixes applied to them that stop them from spitting out 127.* to the
: wire.  I'm not aware of anything that supplants this requirement in
: RFC 1122.
 
: Any system that does spits 127.* to the wire is broken.

As also (IMHO) is any system which accepts such an address and either
trys to route it or send it to a user process. (Or for that matter chucks
out an ICMP error in response)

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 19:45:44 GMT
From:      pappu@ccwf.cc.utexas.edu (Mushfiqur Rahman)
To:        comp.protocols.tcp-ip
Subject:   Slip for Solaris 2.3

 I am looking for slip package for sun solaris 2.3. does anybody know where
 I can get such package?? or does anybody have one? I will really
appreciate
 any help on this.  thanks

******************************************************************************
Mushfiqur Rahman
University of Texas at Austin
pappu@ccwf.cc.utexas.edu
******************************************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        _                    _        _        _        _
     ,__@`                  'Q__,    'Q__,    'Q__,    'Q__,
      \<,   "Wrong way you   ,>/      ,>/      ,>/      ,>/
   /^\/ //\    IDIOTS!"    /\\ \/^\ /\\ \/^\ /\\ \/^\ /\\ \/^\
   \_/  \_/                \_/  \_/ \_/  \_/ \_/  \_/ \_/  \_/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 20:36:01 GMT
From:      sutantha@pdx103 (Suphachai Sutanthavibul)
To:        comp.protocols.tcp-ip
Subject:   RFC ftp-site?

I need to get RFC of Internet Protocol suites. Can some one tell me
the ftp-site for the RFC? Please reply to me directly since I don't read
this news group everyday.

Thanks in advance,
Suphachai.


-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 21:21:14 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article <2m37fn$jdd@cronkite.ocis.temple.edu> jwiegand@opus.temple.edu (The Answer is 42.) writes:
>Gee, my sun here misbehaved even though it's right there in
>/etc/networks:
>
>localnet	127	loopback

/etc/networks has nothing to do with routing.  It's just a
symbolic-to-numeric map, like /etc/hosts is for host names.

>I wonder why the loopback ping went all out to God Knows Where?

Look in your routing table.  You'll see a host entry for 127.0.0.1, but not
a network entry for 127.0.0.0.  So it will send to the default router.

Who ever claimed that SunOS conformed to everything in RFC 1122?
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 21:42:27 GMT
From:      efunken@rohcs1.uhc.com (Eric Funkenbusch)
To:        comp.protocols.tcp-ip
Subject:   Please Humor Me...

I am an extreme TCP/IP novice.  All I'm asking is for people to confirm
if it is possible to achieve my grand scheme (tm) as stated.

I want to set up a small WAN on TCP/IP.  I can connect to my provider with
my Unix system easily enough, but I want to have 2-3 other machines SLIP/PPP
into my Unix box.  These might be Dos, or other platforms, it's not really 
important as long as the SLIP software is there.

Anyways, My provider will set me up with a Class C network (what does that
mean anyways?) adresses, and I want to use the Unix box to route to my 2-3
SLIP connections... Is this possible?  So if it looked like this:

	       Provider (also SLIP)
		  |
		  |
                Unix   (NetBSD or System Vr4 (whichever works better)
		/ | \
	       /  |  \  <--- SLIP connections
              /   |   \
           Box a   b    c

could someone telnet into box a using the Unix box as a router?  Provided
box a was running a telnet server of course.

Is there any special configuration needed to do this?  any special network
software?

I'm also wondering about NFS between box a, b, c, and the Unix system.

Is it only possible to mount the Unix box's file system or can all 4 share
their resources?

Any pointers to where i might find this information will be helpfull.

I would appreciate an email response if possible, though I'll look here
as well for a followup.


-- 
.-----------------------------------------------------------------------------.
| efunken@rohcs1.uhc.com | The opinions stated in this message do not reflect |
| chucks@hotline.mn.org  | United HealthCare's.  My words and thoughts are my |
| chucks@1:282/2002      | own, since nobody would want them.                 |
|-----------------------------------------------------------------------------|
| Programming Consultant at large, employment options welcome, inquire within |
`-----------------------------------------------------------------------------'


-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 22:18:16 GMT
From:      jjh@mwncc.mitre.org ( Jennifer Horton )
To:        comp.protocols.tcp-ip
Subject:   tcp/ip protocol overhead costs

Anyone know how much tcp/ip overhead is added to a pkt ?
I need to figure out how much overhead will be added to  a mail messages on the company
network.  Communication between the client/server user-agent and message-store is via
tcp/ip.  There are other factors I'll need to consider, like latency
of routers and fragmentation issues...but determining the overhead for tcp/ip should
be basic.  Anyone have a clue?  I think the TCP header is 20 bytes.  I think the IP 
header is also 20 bytes.  The Ethernet will add another 14 or 18 bytes??  Do I add all
this to the message as overhead?

We basically have a mixed media 802.3 ethernet LAN/WAN including 56k lines, FDDI
between blgs, and twisted pair or thinnet within blgs.

My objective will be to determine the messaging rate that can be supported with a
new mail application (as yet to be specified).  I'm to assume a message size of
2048-Bytes.

Just getting started on this, but I think my approach will be to assume the minimum/
maximum packet size for ethernet (65/1518) and how that affects the message size with
overhead.

Suggestions on how to approach this will be graciously accepted.

_________
Thanks for your assistance.
email: m14585@mwvm.mitre.org
voice: (703) 883-6195

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 22:38:17 +0000
From:      elatar@comptech.demon.co.uk (Adam Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Re: READ ME URGENT

jpbogers@reks.uia.ac.be (John-Paul.Bogers) writes:

> 
> Dear Friends,
>  
>   My name is Dave Rhodes.  In September 1988 my car was
> reposessed and the bill collectors were hounding me like
> you wouldn't believe.  I was laid off and my unemployment
> checks had run out.  The only escape I had from the
> pressure of failure was my computer and my modem.  I
> longed to turn my advocation into my vocation.
>  
> .... blah blah blah....  [stuff compressed] %(!^$@#%%!$%(

I suppose this is compression in the form of squeezing lots of
$ bills into a single pocket.... :-)

(Why on earth was this posted here??????)

Thought chain letters were basically illegal in whatever form they take - at
least in the UK..

Elatar

+------------------------------------+
| email: elatar@comptech.demon.co.uk |
+------------------------------------+


-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 23:53:01 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on these questions.

In article <2m4tpi$51p@news.parc.xerox.com> kerch@parc.xerox.com (Berry Kercheval) writes:
> ...
>And besides, the Net is one of the BEST places to find out about the
>cutting edge of networking, and the truth about its history (and all
>the lies about its history too :-).

The Net is wonderful if you already know which is which, if you already
know to take most of it as nonsense, and have enough background to detect
some of its rare gold.  The Net is a dangerous place to send naive students.
You may as well send them to the nearest laundromat to learn about quantum
mechanics.  They might get lucky, but they're more likely to return as
members of a new church.

You're unlikely to get anyone who might qualify as knowledgable to answer
the typical student "what is TCP" question.  The people who know are long
since bored by such questions and will answer only rarely if at all, since
such questions are repeated so frequently.  The people mostly likely to
answer are likely to know less than the student, but to state their
misinformation with overwhelming certainty and apparent authority.

Instructors who do not teach their students to use libraries are
charlatans.  Those who send their innocent students to the Net with simple
questions significant harm their students.  On the other hand, maybe they
flunk students who innocently turn in nonsense gleaned from the Net,
thereby teaching them to not believe everything they hear in the greatest
gossip klatsch in history.


Vernon Schryver    vjs@rhyolite.com

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 00:16:08 GMT
From:      NADEL@litc.lockheed.com (Ron Nadel)
To:        comp.protocols.tcp-ip
Subject:   Re: READ ME URGENT

In article <1994Mar15.165322.24112@reks.uia.ac.be> jpbogers@reks.uia.ac.be (John-Paul.Bogers) writes:


[what amounted to a pyramid scheme]

Pyramids are illegal in most States in America.

Ron


-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 00:35:51 +0000
From:      matthew@casa.demon.co.uk (Matthew de Woeps)
To:        comp.terminals,demon.ip.support,comp.protocols.tcp-ip,comp.protocols.misc,comp.unix.questions
Subject:   Re: VT100, 102 & 220 Terminals

In article <6VxtMzj024n@comptech.demon.co.uk> 
           elatar@comptech.demon.co.uk "Adam Goodfellow" writes: 
 
> Does anyone have or know where to find documents covering the full 
> specifications for VT100, 102, 220 terminal emulations as I need to 
> embed such a beast in an application. 
>  
In the past I have had to do the same. I used the programmers hand book which
cames with a VT 220/320 terminal. Otherwise I suppose you will have to go to
DEC if you need a definitive guide. Costly I would have thought. If you have
no luck maybe I can find one, hand book that is.
 
--  
Matthew de Woeps 

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 00:38:36 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x

1> I'm not convinced that it's right for 127.0.0.2 to be regarded as
1> loopback.  But if you want it, you can get it.  It's all a matter of
1> how you set up routing when you turn on loopback.

2> ifconfig lo 127.0.0.1
2> route -n add 127.0.0.0 dev lo

  I'm not convinced that this (alone) will work, at least not without some
  special-casing.

  Yes, we can route all 127.* packets via the network route to 127.0.0.1.

  But when IP sees the packet, it will ask:  "is this for me?"  I think the
  answer should be "no" (without special-casing).  IP will search the 
  interfaces for one whose IP address matches the destination (127.0.0.2).
  If you can assign only one IP address per interface, the above ifconfig
  assigns 127.0.0.1 (not *.2) to the loopback interface.  Therefore, the
  packet will not appear to be addressed to us, and it should be dropped.

  (Of course, it should not be forwarded because the routing table would have
  us forward it out the same interface from which it arrived.)

> However, I think that all 127.x.x.x addresses should be loopback.

  I agree.  But I think this requires special-casing in IP so that __any__
  127.* destination address will match the loopback interface.

  (Alternatively, perhaps the special-casing could be done in ip_output,
  namely:  if the destination address is any 127.* address, change it to the
  IP address for the loopback interface.)

  Are there IP implementations out there that do this?  Do any major
  applications depend on this behavior?  Does anyone use any 127.* other than
  127.0.0.1?  Why (just out of curiosity)?

-- Ken Mintz

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 09:10:30 -0500
From:      philp@universe.digex.net (Phil Perucci)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <2m3b3o$6bg@search01.news.aol.com>,
M Thomps <mthomps@aol.com> wrote:
>
>
>In my previous message I mis quoted Interconnect's personal Slip connection fee
>as $360/month...that should be $360.00/YEAR!!!
>

Yes, but...

How many hours/day do you get?  "Real" internet nodes are on-line 24 hrs/day.
I opted for a dial-up server since all of the cut-rate SLIP providers
I have seen have a 1 hour/day limit (at the cut-rate price...).
Oh well, at least the server I dial-up is on-line 24 hours/day.

The cheapest full-time SLIP connection I have seen is about $200/month.

>Any help regarding personal slip accounts with 14.4 dial-in access would be
>greatly appeciated.
>
>Please email to Mthomps1@Ithac.edu with advice
>
>THANKS YA'LL FOR YOUR TIME AND EFFORT!


-- 
==============================================================================
 Phil Perucci             | "All postings are my own opinion - all comments
 Systems Programmer       |  are intended for research/educational purposes"
==============================================================================

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 02:15:18 +0000
From:      elatar@comptech.demon.co.uk (Adam Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip protocol overhead costs

jjh@mwncc.mitre.org ( Jennifer Horton ) writes:

> Anyone know how much tcp/ip overhead is added to a pkt ?
> I need to figure out how much overhead will be added to  a mail messages on the company
> network.  Communication between the client/server user-agent and message-store is via
> tcp/ip.  There are other factors I'll need to consider, like latency
> of routers and fragmentation issues...but determining the overhead for tcp/ip should
> be basic.  Anyone have a clue?  I think the TCP header is 20 bytes.  I think the IP 
> header is also 20 bytes.  The Ethernet will add another 14 or 18 bytes??  Do I add all
> this to the message as overhead?
> 
> My objective will be to determine the messaging rate that can be supported with a
> new mail application (as yet to be specified).  I'm to assume a message size of
> 2048-Bytes.
> 

As a very rough guide (not sure about packet sizes over Ethernet), you would
need to add your given overheads to every 512bytes of actual data. Though
this again is dependent upon packet sizes which can vary according to the
largest both sender and receiver can handle. Also if there is an
intermediate network between the ends 'A' and 'B' with gateways 'C' and 'D'
fragmentation may occure if link layer packet sizes are small between C and
D increasing the overheads on data.

   A--\      /--B
      C======D

IP and TCP are quite adaptive (within limits...) when it comes to packet
sizes and so giving a definate answer is not possible. Also better
implementations of TCP interrogate the IP layer, which may in turn
interrogate the Link layer to determine the most efficient packet size to
use.

In practice, over a dial-up link using SLIP is I think I lose about 5% or so
on news and mail transfers to protocol overheads, and host delays compared
with sending similar text to a BBS system with no protocol overhead. With
Ethernet, you probably won't notice the difference as there are delays
anyway caused by backing off when more than one machine tried to send data.

Elatar

+------------------------------------+
| email: elatar@comptech.demon.co.uk |
+------------------------------------+


-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 17:18:05 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 <--> TCP/IP Gateway ...?

In article <kleite-160394122614@157.176.173.2> kleite@sentry.ndhm.gtegsc.com (Keith J. Leite) writes:
>	And thanks for reading my message, I know there must be some expertise in
>this newsgroup on this subject. The question I have is at present I am
>using a UB (Ungermann-Bass) X25 gateway which happens to be running XNS, I
>am wondering if there are any other companies that manufactor X25 gateways
>but running the TCP/IP protocol. We are trying to convert the site we are
>at from running XNS to TCP/IP and this is one of our hang ups .....
>	Thanks for any information, we are just currently trying to gather as much
>as we can get .....
>
    Many vendors who offer tcp/ip and X.25 offer the magical "glue"
    layer which maps the IP addresses to/from X.121 and packetizes
    the tcp data. e.g. SCO, AIX, MVS, and us.   
    If you have a Unix box or MVS mainframe you could use it to run IP
    over X.25.  




-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 03:58:18 GMT
From:      matthews@teal.csn.org (John Matthews)
To:        comp.protocols.tcp-ip
Subject:   Delay/Throughput Utilities for TCP/IP??

Does anyone know of any UNIX (Preferably SunOS) utilities that can
do a pretty good job testing throughput and delay of TCP/IP?

I am looking for something can utilize ICMP echos to fill a simulated
window slowly to fully load Inter-Lata Frame-Relay circuits that we are
currently evaluating.  I have used utilities like "spray" and "ping -f"
and "tuecho" but none of them seem to do what I want.  I just want to
keep a sustained window of packets open so that I can keep these
circuits as fully loaded as possible.  I also would like to be able to
run these sorts of tests against hosts that only support ICMP echos.

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

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 12:27:01 -0500
From:      philp@universe.digex.net (Phil Perucci)
To:        comp.os.ms-windows.misc,comp.protocols.tcp-ip
Subject:   DLC for WFW 3.11?

Does anyone know what DLC is?  It seems to be some sort of network
protocol that work with, among others, IBM platforms.

When ftping the latest TCP for WFW 3.11 from ftp.microsoft.com, I also
saw the DLC.  If there is a chance of using it to talk to our mainframe...

I know what SDLC is, but don't know where to start with DLC.
-- 
==============================================================================
 Phil Perucci             | "All postings are my own opinion - all comments
 Systems Programmer       |  are intended for research/educational purposes"
==============================================================================

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 05:26:47 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: How to have several processes access one port in UDP?

In article <2m3bjh$kif@rand.org> burdorf@latrobe.edu.au (Chris Burdorf) writes:
>Does anyone out there know how to have more than one processes access the same port under
>UDP in UNIX?

If the processes have a common parent, create and bind the socket in the
parent before forking the children.  It will be inherited by the children.

If they're not related, you can transmit the socket via a UNIX domain
socket, using sendmsg().
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 05:33:08 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...

In article <NADEL.120.000DC558@litc.lockheed.com> NADEL@litc.lockheed.com (Ron Nadel) writes:
>I'm analyzing some NFS traffic as it goes through a multimedia router.  I 
>notice that there are source and destination port numbers that are paired
>between two systems.  I expected to see something like that, but I also see 
>these numbers change, although I know there is no other NFS stream active 
>between the two hosts.  Can someone tell me the significance of these port 
>numbers?  Does NFS set up a port per file transaction, per connection, or is 
>there something else going on?

NFS doesn't have "connections".  It uses independent remote procedure calls.

I think most NFS clients will allocate a different source port for each
mounted file system, even if they're on the same server.  But source port
numbers have no significance, so some implementations may use a different
one for each transaction.

>Also, does NFS expect a response back for each packet sent out?  If it does 
>expect a response, but does not get one, what are the consequences?

Yes, NFS expects a response for each request.  If it doesn't get one, it
resends the request.  Depending on mount options, it may eventually give
up, or it may keep trying indefinitely.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 08:32:27 GMT
From:      heathh@lust.ugcs.caltech.edu (Heath I Hunnicutt)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

longyear@netcom.com (Alfred Longyear) writes:

>It seems to me that the address 127.x.x.x is not special. What is special
>is the loopback device.

This assumption is wrong.  127 is specified in the RFCs as being a pseudo-
network that includes the loopback address.  The fact that it is specified
in the RFCs as a special address pretty well contradicts your premise.

>If you don't have a route for 127.x.x.x to the "lo" device, but have a default
>route to an ethernet controller, for example, then requests to 127.0.0.1 will
>go out the wire just as requests to any other IP address. Until a route is
>created to the loopback device, the address 127.x.x.x is an unknown address
>just as if _I_ asked for address 192.83.17.1. It would need ARP to resolve it
>to a real ethernet address and subsequently the request would go out the
>default route.

The difference is that the IP layer can make the correct decision not to put
anything to 127.* on any external interface.  The idea that someone should
need to configure their system to not violate the RFCs is ridiculous.  There
is a large responsibility on the part of the stack to not allow stupid things
like sending 127.* out on the net.

>I guess what I am saying is that the routing of frames is not a function
>solely of the device's IP address, nor is it a function soley of the device
>type. There is no magical "override" which says that "Oh, you have address
>127.0.0.1. I won't bother to look it up. I know that this is the loopback
>device and will simply put it there". 

You really should research these issues before posting.  For starters, see
the Hosts Requirements RFC.  There is indeed something "magical" about any
address on the 127 net.  Whether you set your system up with 127.0.0.1 as a
loopback or not is your problem.  No matter what, you should never send
packets to 127.anything out any interface, regardless of the routing table's
(mis)configuration.



-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 14:15:08
From:      clarkb@netstar.com (Clark Bremer)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 <--> TCP/IP Gateway ...?

In article <kleite-160394122614@157.176.173.2> kleite@sentry.ndhm.gtegsc.com (Keith J. Leite) writes:
>From: kleite@sentry.ndhm.gtegsc.com (Keith J. Leite)
>Subject: X25 <--> TCP/IP Gateway ...?
>Date: Wed, 16 Mar 1994 12:26:13 -0500
 
>....
>am wondering if there are any other companies that manufactor X25 gateways
>but running the TCP/IP protocol. We are trying to convert the site we are
>at from running XNS to TCP/IP and this is one of our hang ups .....

You might Try Apertus Technologies, in Minneapolis.  I'm pretty sure they can 
configure their box for that application.  Their main number is 
1-800-328-3998.  CB.

 =========================================================================
||             ___    ___                                                ||
||            /   \  /   \       Clark Bremer                            ||
||           /      /   __)      clarkb@netstar.com                      ||
||          (      /    \        Software Engineer, NetStar Inc.         ||
||           \    /      )       10250 Valley View Road                  ||
||            \__/ _____/        Minneapolis, MN 55344                   ||
||                                                                       ||
 =========================================================================

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 94 20:24:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on these questio

VR>You're unlikely to get anyone who might qualify as knowledgable to answer
VR>the typical student "what is TCP" question.  The people who know are long
VR>since bored by such questions and will answer only rarely if at all, since
VR>such questions are repeated so frequently.  The people mostly likely to
VR>answer are likely to know less than the student, but to state their
VR>misinformation with overwhelming certainty and apparent authority.

This is most likely true, but it's not necessarily bad. :-)  If the
student is naive enough to believe something from an unknown person
in an Internet newsgroup, he'll learn a valuable lession when he 
attempts to apply his new "knowledge"!

VR>On the other hand, maybe they
VR>flunk students who innocently turn in nonsense gleaned from the Net,
VR>thereby teaching them to not believe everything they hear in the greatest
VR>gossip klatsch in history.

My point exactly... :-)

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 11:35:43 GMT
From:      jpbogers@reks.uia.ac.be (John-Paul.Bogers)
To:        comp.protocols.tcp-ip
Subject:   EXCUSE ME


Dear reader,

Yesterday a "pyramid" letter was send from our PC to your usenet-group. This 
letter caused an enormous amount of reaction. I would like to apologize to
anyone if I caused any inconvenience. 
Some of the reactions were very personal and brutal against me in person. 
I would like to stress that this "letter" was started merely as a joke 
after office hours. We had no intention to harm anyone neither did we 
expect to gain a substantial amount of money. If any money will be send 
to me, I will send it to charity.

Again, I'm sorry.


-- 
--------------------------------------------------------------------
J.P. Bogers, M.D.
Universitaire Instelling Antwerpen (UIA)
Lab Pathology

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 94 12:16:00 GMT
From:      werme@alingo.uucp (Eric Werme USSG)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...

>In article <NADEL.120.000DC558@litc.lockheed.com> NADEL@litc.lockheed.com (Ron Nadel) writes:
>>I'm analyzing some NFS traffic as it goes through a multimedia router.  I 
>>notice that there are source and destination port numbers that are paired
>>between two systems.  I expected to see something like that, but I also see 
>>these numbers change, although I know there is no other NFS stream active 
>>between the two hosts.  Can someone tell me the significance of these port 
>>numbers?  Does NFS set up a port per file transaction, per connection, or is 
>>there something else going on?

On the server side, nfsd gets a socket and probably bind it to port 2049
and registers it with portmap.  All NFS traffic to the server will address
that port number.

On the client side, several UDP sockets are used, each has a unique
port number.  Each socket can support one NFS call at a time.  I.e. if
the client has sent a lookup for a file from one process and a read
from another, I'd expect two different client port numbers to be
involved.  Once the server replies, the client socket can be shut
down, but most clients these day keep several sockets around knowing
that other NFS requests will come through soon.  In general you like
to have enough so all the biods plus a few other processes can have
NFS requests in progress.  The port numbers are important so that the
replies from the server will be received by the right process in the
client.

The stateless nature of NFS means that it doesn't matter which nfsd receives
a request.
-- 
Eric (Ric) Werme		| werme@zk3.dec.com
Digital Equipment Corp.		| This space intentionally left blank.

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 13:17:38 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   netstat -r

    


  I am working on Suns running 4.1.x. When I use netstat -r I get a list of
routes in the routing table. Some routes seem to be invulnerable to route 
delete commands - I get "not in table". What is going on when routes displayed
in the routing table via netstat -r are not removeable because the are
"not in table"

                            Jerry Freedman,Jr

                 

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 13:44:13 GMT
From:      rchui@tethys.nswc.navy.mil (Raymond Chui)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip,comp.unix.sys5.r3,comp.lang.c,navy.nswc.netnews
Subject:   What is putmsg() and poll() ld link?

I am try to complied my C programs in HP-UX 8.07, but got following message:

{34}cc -c *.c
{35}cc -g -o tcpserv tcpserv.o acceptcall.o strecho.o -lxti ../lib.s5/libnet.a
/bin/ld: Unsatisfied symbols:
   putmsg (code)
   poll (code)

I never used these two function calls in my programs. What is the ld link
require for these two functions? Please do not just follow-up also
email me a copy. Thanks in advance!

-- 
Raymond H. Chui                 | Democracy is not a way of getting better
NSWC N55                        | solutions.
10901 New Hampshire Ave.        |
Silver Spring, MD 20903-5640    | It's just a way to spread the blame.
U.S.A.                          |
Voice:1-301-394-3807 Ext. 45    |
Fax:1-301-394-4483              |
E-Mail:rchui%tethys@relay.nswc.navy.mil
Or     rchui@tethys.nswc.navy.mil
  _ __                                  _    ,    __
 ' )  )                           /    ' )  /    /  ) /
  /--' __. , , ____   ______   __/      /--/    /    /_  . . o
 /  \_(_(_(_/_/) ) )_(_) /) )_(_(_     /  ( o  (__/ / /_(_/_(_
             /
            /

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 14:56:12 GMT
From:      suresh@cs.uh.edu (Suresh Arunachalam)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP-Netview

In article <CMJMDE.M1H@actcom.co.il> ew@actcom.co.il (Emanuel Wind) writes:
>Hi,
>I am looking for a product whuch translates SNMP traps into IBM Netview
>alerts (and sends them to IBM mainframe of course), and runs over
>MS-Windows.
>Any idea ?
>Emanuel
Bridgeway's EventIX can do that. But, To my knowledge it works only
with UNIX.To may want to check up.
      
Suresh A.



-- 
email: suresh@uh.edu             phone: (713)743 9156
       suresh@uhou (BITNET)
       uhou::suresh (THEnet or DECnet)


-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 15:32:55 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??

In article <CMqoD7.G0F@csn.org> matthews@teal.csn.org (John Matthews) writes:
>Does anyone know of any UNIX (Preferably SunOS) utilities that can
>do a pretty good job testing throughput and delay of TCP/IP?
>
>I am looking for something can utilize ICMP echos to fill a simulated
>window slowly to fully load Inter-Lata Frame-Relay circuits that we are
>currently evaluating.  I have used utilities like "spray" and "ping -f"
>and "tuecho" but none of them seem to do what I want.  I just want to
>keep a sustained window of packets open so that I can keep these
>circuits as fully loaded as possible.  I also would like to be able to
>run these sorts of tests against hosts that only support ICMP echos.
>
>                                Thanks in advance,
>                                        John Matthews
>					matthews@mis.uswest.com

In the systems I know about ICMP echo requests involve very different
paths on the source machine, the echoing machine, and back on the source
machine than ordinary TCP/IP or UDP/IP packets.  I would not believe any
conclusions drawn about the computers based on ICMP echo requests.

The echo port, port 7, both UDP and TCP, would yield somewhat less
uninteresting answers.

One could also use something like `ttcp` (source found on brl.mil and
sgi.com), or something hacked from `ttcp`, either UDP or TCP.


Vernon Schryver    vjs@rhyolite.com

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 15:38:41 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...

In article <2m65mkINNmbb@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
> ...
>I think most NFS clients will allocate a different source port for each
>mounted file system, even if they're on the same server. ...

I don't think so.  Each client handle may have its own port number, but
you don't have a different client handle for every server or mounted file
system.  ("Client handle" is the name of a kernel data structure in a
certain, well known "reference implementation.")


Vernon Schryver    vjs@rhyolite.com

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 16:10:22 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip protocol overhead costs

In article <6v4vuPj024n@comptech.demon.co.uk> elatar@comptech.demon.co.uk writes:
>jjh@mwncc.mitre.org ( Jennifer Horton ) writes:
>
>> Anyone know how much tcp/ip overhead is added to a pkt ?
>> ...
 
>As a very rough guide (not sure about packet sizes over Ethernet), you would
>need to add your given overheads to every 512bytes of actual data. ...

Not exactly.

A full size TCP/IP/Ethernet packet contains
      1. 14 bytes of MAC header (6 bytes of DA, 6 bytes of SA, 2 bytes of type)
      2. 20 bytes of IP header
      3. 20 bytes of TCP header
      4. 1460 bytes of TCP data
      5. 4 bytes of CRC

    (1) can be extend by 8 more bytes of SNAP header in the unlikely
	case 802.3 encapsulation is used.
    (2) and (3) can be extended with "IP options" and "TCP options".
	The first TCP packet usually contains an "MSS option" to negotiate
	the size of the TCP "segment size" used in subsequent packets.
	If you are using TCP-LW or selective ACK's (both unlikely today),
	there will be those kinds of options.  The least uncommon IP
	options are for source-routing and route-recording.
    (4) the size of the TCP segment is affected by:
	-the max. segment size negotiated with the TCP MSS option
	-the maximum size of the packet possible on the local wire
	    (e.g. 4352 for FDDI, 1452 for Ethernet using 802.3
	    encapsulation, the MRU negotiaged by PPP.)
	-the Host Requirements RFC (and older) dictum that packets to
	    "remote" networks should use 512 or 576 to minimuzes
	    fragmentation at intervening routers, except as modified
	    by de facto standard switches such as the BSD "subnetsarelocal".
	-information from MTU discovery mechanisms and protocol.
	-how much data the application has asked be sent
	-how much data is waiting to be sent from before (e.g. Nagle
	    algorithm) or retransmitted (e.g. after a timeout or for
	    fast retransmission)


Vernon Schryver    vjs@rhyolite.com

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 16:12:47 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article <2m6g6r$ijk@gap.cco.caltech.edu> heathh@lust.ugcs.caltech.edu (Heath I Hunnicutt) writes:
>longyear@netcom.com (Alfred Longyear) writes:
>
>>It seems to me that the address 127.x.x.x is not special. What is special
>>is the loopback device.
>
>This assumption is wrong.  127 is specified in the RFCs as being a pseudo-
>network that includes the loopback address.  The fact that it is specified
>in the RFCs as a special address pretty well contradicts your premise.
>
>>If you don't have a route for 127.x.x.x to the "lo" device, but have a default
>>route to an ethernet controller, for example, then requests to 127.0.0.1 will
>>go out the wire just as requests to any other IP address. Until a route is
>>created to the loopback device, the address 127.x.x.x is an unknown address
>>just as if _I_ asked for address 192.83.17.1. It would need ARP to resolve it
>>to a real ethernet address and subsequently the request would go out the
>>default route.
>
>The difference is that the IP layer can make the correct decision not to put
>anything to 127.* on any external interface.  The idea that someone should
>need to configure their system to not violate the RFCs is ridiculous.  There
>is a large responsibility on the part of the stack to not allow stupid things
>like sending 127.* out on the net.
>
>>I guess what I am saying is that the routing of frames is not a function
>>solely of the device's IP address, nor is it a function soley of the device
>>type. There is no magical "override" which says that "Oh, you have address
>>127.0.0.1. I won't bother to look it up. I know that this is the loopback
>>device and will simply put it there". 
>
>You really should research these issues before posting.  For starters, see
>the Hosts Requirements RFC.  There is indeed something "magical" about any
>address on the 127 net.  Whether you set your system up with 127.0.0.1 as a
>loopback or not is your problem.  No matter what, you should never send
>packets to 127.anything out any interface, regardless of the routing table's
>(mis)configuration.


"You should really research these issues before posting" as well.
The first guy is right.

The H-R RFC's do not say how 127 should be made special, only that it
should be.  Standards, including RFC's, specify external behavior, not
internal implementation.

You need a pretty dim view of your customers' intelligence and good sense
to put special checks against non-compliant configurations of net 127 in
what is in most systems the performance critical path.  (Route look-up is
particularly important for the performance of un-connect(2)'ed UDP
sockets).  Unless the customer does something wierd to the system, the
normal routing mechanisms do exactly the right things.  There is no excuse
to waste cycles checking for something that few sane customers would
change, and that practically all insane customers are too ignorant to be
able to break.  If the customer overrides those mechanisms, and makes the
system non-compliant with any or all RFC's, do you think the Network Police
will come and break someone's knee-caps?  Who is to say that the customer
does not have good and sufficent reasons for using some network other than
127 for loopback?


Vernon Schryver    vjs@rhyolite.com

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 19:25:52 GMT
From:      tad@cerc.wvu.edu (Tad Davis)
To:        comp.protocols.tcp-ip
Subject:   Isis


Could someone tell me the phone number and/or address of the
client/server software called or sold by Isis.  I'm not sure
if that is the product or company name.

Thanks,

Tad Davis
Concurrent Engineering Research Center

-- 
Tad Davis
Concurrent Engineering Research Center

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 20:39:30 GMT
From:      quadsys@netcom.com (Roland Besserer)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Routing to Internet



I am experiencing a problem trying to configure a small network
with Internet access and hope someone can shed some light on this:

Network configuration:

tsmail is SPARC-2 running SunOS 4.1.3. Net1 is on an exp0 Ethernet VME
card, net2 on the build-in ne0 Ethernet and local-ppp is a PPP link
on a leased line.


                                tsmail
                         +-------------------+
                         |                   |
	netcom-ppp <---> |local-ppp      net1| <---> net1 hosts
                         |                   |
                         |         net2      |
                         +-------------------+
                                    ^
                                    |
                                    v
                                net2 hosts

There are a number of PC hosts on net1 and a mixture of Suns, DECs and PCs
on net2.  The PPP link is the internet connection through Netcom.

Because the network is simple I have initially tried static routing but have
used routed and gated as well. Currently I'm running gated.

After setting up the routing tables (manually or gated) the following
works (tables later):

	* tsmail host can access any host on net1 or net2 and any
	  Internet host (tsmail runs NIS and DNS/Bind)
	* Any net1 host can access any net1 and net2 host and
	  tsmail.
	* Any net2 host can access any other net1 and net2 hosts
	* local-ppp is accessable to all hosts

What does not work:

	* No net1 or net2 host can access netcom-ppp or any internet host
	  

After running routed the first time with a default route through netcom-ppp
defined in /etc/gateways, all net1/net2 hosts were able to successfully
access the Internet but after a reboot (no configuration changes) I can't
make it work anymore. Here is the routing table for tsmail as set up
by gated:

Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
local-ppp            localhost            UGH      0      1          lo0
localhost            localhost            UH       1      87         lo0
netcom-ppp           local-ppp            UH       0      682        dp0
default              netcom-ppp           UG       0      369        dp0
net1                 hermes               U        7      16183      exp0
net2                 tsmail               U        17     22742      ne0


The hosts on net1/net2 simply define a default route to tsmail

traceroute output shows that all attempts at accessing unknow hosts
are directed to tsmail and stop there. But tsmail has a
default route to netcom-ppp installed and that default route is working,
as Internet access and DNS work properly from tsmail.

Here is the gated config file, but I get identical behaviour when running
routed with just netcom-ppp as the default route in /etc/gateways (replaced
addresses with names used above):


#
# Gated configuration for tsmail
#
traceoptions internal external route rip update ;
#traceoptions all ;
tracefile "/tmp/gated.trace" ;

interfaces { interface all passive ;
	     define netcom-ppp pointopoint local-ppp ;
} ;

routerid netcom-ppp ;

#
# Do rip except on the PPP interfaces
#
rip on ;

#
# Set up static routes to remote ethernets at the end of PPP links
# We are advertising ourself as a gateway to the subnetwork assigned
# to the PPP links.  For each remote ethernet, the remote end of a PPP
# link is being advertised as a gateway.
#
static {
	0.0.0.0 gateway netcom-ppp preference 20 ;
} ;


Any help would be appreciated.

roland@themis.com

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 21:01:20 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article <longyearCMpqvD.3ys@netcom.com> longyear@netcom.com (Alfred
Longyear) writes: 
>It seems to me that the address 127.x.x.x is not special. What is special
>is the loopback device.

No.  127.* is a special network.  It was born special.  IP
implementations should ***ALWAYS*** ignore everything they get from
this address if it comes in over the wire and should ***NEVER*** send
packets to this address out over the wire.  And it should do this be
default.  Robust implementations should enforce this compeletely and
leave no room for the user to configure this.  127.* ARP requests as
well should never be on the wire, and completely ignored if they are
seen by a host on the wire.  ICMP messages should likewise be treated.

To do otherwise is broken and will cause problems.  Think about the
network meltdown that would happen if everybody responded to an ARP
for 127.*....

Yes, SunOS 4.x is broken, in that it doesn't do all these things.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
"... but I can't promote you to "Prima Donna" unless you demonstrate a few
 more serious personality disorders"

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 21:16:14 GMT
From:      nguyen@Phuong.raleigh.ibm.com (Phuong Thanh Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 <--> TCP/IP Gateway ...?

In article <kleite-160394122614@157.176.173.2>, kleite@sentry.ndhm.gtegsc.com (Keith J. Leite) writes:
|> Hello,
|> 	And thanks for reading my message, I know there must be some expertise in
|> this newsgroup on this subject. The question I have is at present I am
|> using a UB (Ungermann-Bass) X25 gateway which happens to be running XNS, I
|> am wondering if there are any other companies that manufactor X25 gateways
|> but running the TCP/IP protocol. We are trying to convert the site we are
|> at from running XNS to TCP/IP and this is one of our hang ups .....
|> 	Thanks for any information, we are just currently trying to gather as much
|> as we can get .....
|> 
|> Keith ....
|> 
|> 
|> *********************************************
|>          Keith J Leite KA1AQB
|>    AX25 - KA1AQB @ WA1PHY.#EMA.MA.USA.NA
|>      AMPR - ka1aqb@switch.sema.ampr.org
|>   Internet - kleite@sentry.ndhm.gtegsc.com
|> 
|> **********************************************

I'm assuming that "gateway" you mentioned means "router". If what I
assuming is correct than the product you needs is IBM 6611 router.
This product does support TCP/IP on X25.

Phuong Nguyen
-- 
--------------------------------------------------------------------------
| Disclaimer: My opinions and IBM's are two different entities           |
| Hope you have a "phuongtastic" day      PNGUYEN@VNET.IBM.COM           |
--------------------------------------------------------------------------

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 21:34:00 GMT
From:      manfredi@rockwell.com (Bert Manfredi, 747-6735)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.misc
Subject:   Re: TCP-IP on a VAXstation

In article <1994Mar11.131905.1275@buckie.hsc.colorado.edu>, dwing@uh01.Colorado.EDU writes...

>DEC sells a product called "TCP/IP Services for VMS".  V3.0 is available for 
>AXPs, and V3.0 is currently in beta test for VAXes.  There are third party 
>TCP/IPs available, too, from TGV, Wollongong, Process Software, and a public 
>domain version of TCP/IP called "CMU/IP", too.

Dan or anyone on this net,

We're planning to upgrade from a DECNET PCSA V4.1 to PCSA V5.0 for our office
Ethernet (with all the requisite Internet services). PCSA V5.0 apparently
places the IP protocols in each PC, so that users can do FTP and TELNET
without having to log onto the VAX server. And you get DECNET too. And it
takes up less memory than V4.1.

Do you or anyone have any experience, knowledge, or prejudices about this
upgrade? Have you read about it?

Bert
manfredi@rockwell.com

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 22:53:28 GMT
From:      michael@cystron.win.net (Michael R. Berg)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

 
In article <2m740m$f94@universe.digex.net>, Phil Perucci (philp@universe.digex.net) writes:
>In article <2m3b3o$6bg@search01.news.aol.com>,
>M Thomps <mthomps@aol.com> wrote:
>>
>>
>>In my previous message I mis quoted Interconnect's personal Slip connection fee
>>as $360/month...that should be $360.00/YEAR!!!
>>
>
>Yes, but...
>
>How many hours/day do you get?  "Real" internet nodes are on-line 24 hrs/day.
>I opted for a dial-up server since all of the cut-rate SLIP providers
>I have seen have a 1 hour/day limit (at the cut-rate price...).
>Oh well, at least the server I dial-up is on-line 24 hours/day.
>
>The cheapest full-time SLIP connection I have seen is about $200/month.
>
>>Any help regarding personal slip accounts with 14.4 dial-in access would be
>>greatly appeciated.
>>
>>Please email to Mthomps1@Ithac.edu with advice
>>
>>THANKS YA'LL FOR YOUR TIME AND EFFORT!
>==============================================================================
> Phil Perucci             | "All postings are my own opinion - all comments
> Systems Programmer       |  are intended for research/educational purposes"
>==============================================================================

A great source for any type of connection from personal UUCP to
10Mbps is UUNET, send them some mail at info@uunet.uu.net, just tell
them I sent you, I'd like the brownie points!



-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 15:04:32 -0800
From:      velthuys@cs.ubc.ca (Rolf Velthuys)
To:        comp.protocols.tcp-ip
Subject:   Re: ST-II

atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

#In article <CMtnHv.K72@umassd.edu> rleary@UMASSD.EDU writes:
#>
#>  The current (Jan/Feb) issue of the IBM Multimedia Solutions magazine, 
#>in a discussion of the Ultimedia Server/6000, mentions the 
#>"Internet-family networking protocol called ST-II". Is this indeed 
#>an Internet family protol? 	

#NO

I guess this depends on what you call 'internet family'. It is defined
in RFC 1190 'the internet STream Protocol, version II'. It is not one
of the protocols with 'mandatory' status (not sure about the actual
term here).

#>If not, what is it? 

#A multicast protocol 

The STII specification describes a (connection oriented) protocol
which has a number of very interesting features. Some of these should
make it useful for high-speed networking.  Among these features:
	- multicasting 
	- optimized packet processing procedures allowing minimal delays when
          passing through ST-II internal nodes
	- late packet duplication mechanisms to minimize use of
          bandwidth when transmitting (same) packets to multiple targets
	- hooks for resource allocation and reservation mechanisms
        - hooks for routing mechanisms 
        - some interesting network management type functions to detect whether
          parts of the STII network are still alive.
        - STII does not have flow control or error detection mechanisms for
          as far as user data is concerned.
  
RFC 1190 describes how it can be used instead of/in combination with
IP.

#developed for use by the US DoD in the SIMNET,
#now called Defense Simulation Internet.  It is NOT on the Internet
#standards-track and is extremely unlikely to ever become really
#widespread or an Internet standard.

#>If so, please refer me to appropriate RFC. 

See above.

#ST-II is documented in an "informational" (i.e. not a standard) RFC,
#but few if any implementations conform to that RFC.  

I know of three implementations of STII. One is (was ?) available from
bbn on an anonymous ftp site, one was developed during a sabatical at
Swedish Institute of Computer Science (SICS) in Stockholm. Also there
is (was?) a group within IBM that used STII in a prototype high speed
network.

The SICS implementation is described in a paper:

An implementation of the revised internet stream protocol (ST-2),
Craig Partridge, Stephen Pink, 
in: Internetworking: research and Experience, vol.3, pp27-54,
John Wiley and Sons LTD, 1992.

For as far as I know, the RFC (i.o.w., the specification) has indeed
not been implemented as described. I believe that there are no
implementations that conform to the specification. 


#There is movement
#afoot to create a new RFC that accurately describes the actual
#implementations, but that won't be on the standards-track either
#in all liklihood.

Where did I get that strange notion anyway, first write a spec, then
write an implementation ?


#Folks who want multicasting should look into IP Multicast, which is
#commercial off the shelf technology today (been in IRIX for years and
#Solaris 2.x and the newest OSF/1 for Alpha, Proteon routers, etc).

There's more to ST-II then just multicasting. Also, even though they
both do have multicasting, there's probably a big difference in the
way it is done.  If only because ST-II is connection oriented and IP
connection less.

#RSVP is an adjunct to IP currently under development that will provide
#resource reservation to the Internet, including multicast.

RSVP ? 


Rolf Velthuys
velthuys@cs.ubc.ca

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 02:17:55 GMT
From:      ppessi@snakemail.hut.fi (Pekka Pessi)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article <2m6g6r$ijk@gap.cco.caltech.edu> heathh@lust.ugcs.caltech.edu (Heath I Hunnicutt) writes:
>>If you don't have a route for 127.x.x.x to the "lo" device, but have a default
>>route to an ethernet controller, for example, then requests to 127.0.0.1 will
>>go out the wire just as requests to any other IP address. Until a route is
>>created to the loopback device, the address 127.x.x.x is an unknown address
>>just as if _I_ asked for address 192.83.17.1. It would need ARP to resolve it
>>to a real ethernet address and subsequently the request would go out the
>>default route.
 
>The difference is that the IP layer can make the correct decision not to put
>anything to 127.* on any external interface.  The idea that someone should
>need to configure their system to not violate the RFCs is ridiculous.  There
>is a large responsibility on the part of the stack to not allow stupid things
>like sending 127.* out on the net.

	Uhh.. it seems to me that most (if not all) Unix IP implementations
	are based on that ridiculous idea of correct configuration.

	There is nothing in BSD net/2 preventing you from sending packets to
	127.1 to the network.  And the BSD is the culprit of this silly idea
	of local net, 127.0. 

	I just tested this on two net/2 based systems (namely, OSF 1.3 and
	AmiTCP/IP).  Both require you to say "ifconfig lo0 127.1".  Both
	send packets to 127.2 happily to default router.  SunOS 4.1 and
	HP-UX 9 route 127.2 to default router, too.  I guess that they are
	not conforming to RFC 1122.

--
Pekka.Pessi@hut.fi

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 10:51:29 -0500
From:      syklb@osiris.giss.nasa.gov (Ken Bell)
To:        comp.protocols.tcp-ip
Subject:   Re: netstat -r

In article <2m70ti$4to@linus.mitre.org>,
Freedman <jfjr@mbunix.mitre.org> wrote:
>
>  I am working on Suns running 4.1.x. When I use netstat -r I get a list of
>routes in the routing table. Some routes seem to be invulnerable to route 
>delete commands - I get "not in table". What is going on when routes displayed
>in the routing table via netstat -r are not removeable because the are
>"not in table"

Try "netstat -rn" to see the numeric IP addresses, then "route delete" those.

-- 
Ken Bell
syklb@nasagiss.giss.nasa.gov / syklb@nasagiss.bitnet / (212)-678-5545

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 94 05:04:42 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

longyear@netcom.com (Alfred Longyear) writes:

>So, it is not the "implementation of TCP/IP" which is broken, but the
>operator's setup of the TCP/IP configuration which is broken. There is nothing
>"magical" about the address 127.0.0.1 other than the convention that it is the
>loopback device and is normally _configured_to_route_ back to your own machine.

Actually, there is something magical about 127: RFC 1122 and RFC 1009
both specify that 127 is a bogus address, and must never appear in
a packet that goes out of your machine.

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 14:54 -0500
From:      holdrege@eisner.decus.org (Matt Holdrege)
To:        comp.protocols.tcp-ip
Subject:   Re: routed and ospf

In article <9403160805.AA02967@gandalf.think.com>, barmar@think.com (Barry Margolin) writes...
>In article <15MAR199400563246@eisner.decus.org> holdrege@eisner.decus.org (Matt Holdrege) writes:
>>120.1.1.1---------120.1.1.28-------120.1.43.1|
>>  VAX     ENET     Router    56K     Router  |
>>					     E|---120.1.43.50
>>					     N|       PC
>>					     E|---128.200.1.2
>>					     T|	     DG
>>					      |---128.200.1.10
>>					      |   Alpha-Micro
> 
>Why do you have a different network number for the DG and Alpha-Micro?  Why
>not give them addresses on the 120.1.43 network, since that's the network
>number for the ethernet.
> 
>If the router has the ability to configure multiple addresses on an
>interface, give its ethernet interface an address on the 128.200.1 network.
>Then configure a default route on the DG and Alpha-Micro that points to
>this address.  For instance, if the Router is from Cisco, you would
>configure this as a "secondary" address; I don't know how to do it with
>other routers.

The reason that I have to do it this way is due to politics. I want to change
the addresses to the 120.1 network, but I am getting resistance.

So you are saying that I cannot use the DG as a gateway router between 
networks?

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 07:01:47 GMT
From:      inemetz@hookup.net (Irwin Nemetz)
To:        comp.protocols.tcp-ip
Subject:   Slip and Ethernet On A PC

Good Day All,

     I am trying to set up a PC running Linux as an Internet gateway. I have 
managed to get SLIP working, then ethernet working and finally both going at 
the same time. I am having trouble figuring out how to set up the routing 
thought and I was wondering if somebody could give me a hand here.

Nodes:

128.1.1.1        vax1
128.1.1.2        irwin    (Ethernet on PC)
165.154.6.37  inemetz (Slip line on PC)
165.154.5.1    nic.ott.hookup.net (Internet gateway on other end)

/etc/gateways on PC

net     128.1.1.0       gateway 128.1.1.2    passive
net       default         gateway 165.154.5.1 active

On the VAX, I give the command:

set route/default/gateway=irwin 

which should send the stuff to irwin and then out the slip connection but 
nothing is happening. I am real close here but am stuck. No example for this 
in the O'Reilly book.

Irwin

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 07:22:49 GMT
From:      jaesoo@cs18.cs.aukuni.ac.nz (Jaesoo Kim)
To:        comp.protocols.tcp-ip
Subject:   Help:using Unix socket on Ultrix 4.3

Greetings,

My system that I am going to try consists of three Unix processes which
communicate using Unix sockets, allowing each process to run on separate
machines. All the processes are about to running on an Ultrix V4.3.

I am a very beginner on this matter. How can I tranfer data between the
three processes using Unix sockets. I would appreciate it if you could
send me sample c codes and comments applied to similar way. It would be 
a great helpful to understand about the usage of the sockets.

Thanks very much for your help and time.


Jaesoo Kim                         |E-mail:jkim03@cs.aukuni.ac.nz
Department of Computer Science     |       jaesoo@cs.aukuni.ac.nz
The University of Auckland         |Tel.: +64 9 3737 599 (x 7265)
Private Bag 92019                  |Fax.: +64 9 3737 453
Auckland                           |
NEW ZEALAND                        |

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 94 08:30:32 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x

In article <CMqF4C.8p5@cup.hp.com> mintz@cup.hp.com (Ken Mintz) writes:
>
>  Are there IP implementations out there that do this?  Do any major
>  applications depend on this behavior?  Does anyone use any 127.* other than
>  127.0.0.1?  Why (just out of curiosity)?
>
>-- Ken Mintz

It is kinda useful for testing. Telnet 127.0.0.2 and there is a TCP connection 
between 127.0.0.1 and 127.0.0.2. Having "unique" IP addresses might make 
testing a bit easier. That way you can test stuff that depenmds on different 
IP addresses BEFORE going on the net (which is usally a better time than
after, if you can help it).


-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 10:54:22 GMT
From:      simona@ithost1.it.dth.dk (simona somesan)
To:        comp.protocols.tcp-ip
Subject:   TELNET AND FTP sources?

Do anyone know where can I find telnet and ftp C sources???
EMAIL address is simona@it.dth.dk

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 12:03:30 +0100
From:      urlichs@smurf.noris.de (Matthias Urlichs)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In comp.os.linux.development, article <2m6g6r$ijk@gap.cco.caltech.edu>,
  heathh@lust.ugcs.caltech.edu (Heath I Hunnicutt) writes:
> 
> The difference is that the IP layer can make the correct decision not to put
> anything to 127.* on any external interface.  The idea that someone should
> need to configure their system to not violate the RFCs is ridiculous.  There
> is a large responsibility on the part of the stack to not allow stupid things
> like sending 127.* out on the net.
> 
You can do a lot of stupid RFC-violating things with your network
configuration (and other parts of the kernel) that the fact that the
kernel doesn't regard 127.* as special doesn't bother me.

With newer BSD networking code, the fix is easy; just add
	route add -reject -netmask 255.0.0.0 127.0.0.0 127.0.0.1
to the startup script. Voila, no more 127.* packets getting out.

> You really should research these issues before posting.  For starters, see
> the Hosts Requirements RFC.  There is indeed something "magical" about any
> address on the 127 net.  Whether you set your system up with 127.0.0.1 as a
> loopback or not is your problem.  No matter what, you should never send
> packets to 127.anything out any interface, regardless of the routing table's
> (mis)configuration.

Given that I've not heard of anybody who gets hurt by seeing spurious
127.anything_but_0_0_1 IP or ARP packets on the wire, I don't think special
code in the kernel to catch that case is all that necessary. Not if it can
be caught by a simple routint table entry.

-- 
A woman of generous character will sacrifice her life a thousand times over
for her lover, but will break with him for ever over a question of pride --
for the opening or the shutting of a door.
               --Stendhal
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 13:54:45 GMT
From:      Rob.Sadler@AtlantaGA.NCR.COM (Robert F. Sadler)
To:        comp.protocols.tcp-ip
Subject:   Books on Winsock or Sockets programming?

Hi all,  being somewhat new to this type of programming (comms), I was 
wondering if anyone out there can recommend example source code or books that 
explain or demo reading mail and news (SMTP, NNTP) over socket interfaces.
Thanks for reading this request.

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 14:00:44 GMT
From:      uknf@rzstud1.rz.uni-karlsruhe.de (Olaf Titz)
To:        comp.security.unix,comp.protocols.tcp-ip
Subject:   Re: Why is sendmail so nice?

In article <JROZES.94Mar16114829@allegro.cs.tufts.edu>,
J Rozes <jrozes@allegro.cs.tufts.edu> wrote:
> unlikely, but one possibility would be to place some type of identifier
> in OS's without priveledged ports that somehow distinguishes between a
> system and a user. Sure it wouldn't be 100% secure, but it sure would be

not possible. This would mean placing this identifier into the TCP or
IP header, which is under control of the system that is sending this
info about itself. It needs only one implementation of TCP/IP stack
for DOS that doesn't give out this info correct and the scheme is
subverted.

No, the problem is rather whom to trust. The least you have to know to
trust any other system is which sort of system that one is (and who
runs it). If you set up a Un*x machine to trust other machines (e.g.
by allowing .rhosts-controlled logins) you have to define whom to
trust on *this* machine, and never trust PCs.

Olaf
-- 
        olaf titz     o       olaf@bigred.ka.sub.org          praetorius@irc
  comp.sc.student    _>\ _         s_titz@ira.uka.de      LINUX - the choice
karlsruhe germany   (_)<(_)      uknf@dkauni2.bitnet     of a GNU generation
what good is a photograph of you? everytime i look at it it makes me feel blue

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 14:38:11 GMT
From:      german.1@nd.edu (Chad W. German)
To:        comp.protocols.tcp-ip
Subject:   test

ghgg

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 15:06:24 GMT
From:      brinkman@dalvm41b.iinus1.ibm.com
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Design and Planning Forum

TCP/IP Design and Planning Forum
An Invitation ...

You are cordially invited to attend the TCP/IP Design and Planning
Forum.  This two-day, program will address issues on designing and planning TCP/IP network. The session will be held at IBM's Networking Center in Raleigh, North Carolina.  Raleigh is served by the Raleigh/Durham International Airport.

he Program Objective ...
To provide you with information on how to implement TCP/IP in your current environment.  Topics to be discussed include:
 -  the changes you are facing with a multiprotocol network
 -  some of the planning issues with implementing TCP/IP
 -  the TCP/IP addressing scheme
 -  internetworking options
 -  management of a multiprotocol network

How Do I Attend?
Call Skill Dynamics at 1-800-IBM-TEACh and request Course E5227.  Enrollment
will be confirmed to you by fax.  Please provide your fax number to Skill Dynamics.

Unless you wish to make your own plans, the Networking Center staff will make arrangements for you to stay at a hotelwhich is located conveniently to both the airport and the NetworkingCenter.  You should plan to arrive at the session by about8:30 A.M.  The session will conclude at 4:00 P.M. so youshould schedule yourreturn flights after 5:00 P.M.  Lunch will be provided both days.  Business casual clothing is appropriate.

Scheduled Dates For The Forum
February 9-10, 1994; April 6-7, 1994; June 8-9, 1994

Fee:  $600.00

If You Have Any Questions ...
contact Robert Brinkman at (919)301-3194 or brinkman@vnet.ibm.com
 
Day One

Introductions and Objectives
 
TCP/IP Networking:
An overview of the architectural structure of the Transmission Control Protocol/Internet Protocol (TCP/IP).  The concepts and context of the major protocols and the key TCP/IP applications will be discussed.  Integration into existing LAN and WAN protocols will also   
be included.
 
IP Networking Infrastructure:
Alternatives for connecting networks such as bridges, routers, and gateways will be discussed and considerations for the use of each alternative will be provided.
 
IP Addressing:
The session will cover naming and addressingfundamentals for IP networks.  The networking consultant will also discuss considerations in selecting size of subnet, subnet masking, and Domain Name Server design.  Also discussed, protocols used between  multiprotocol  routers and their implications.

Day Two:	

Managing a TCP/IP Environment:
This session will describe the different management protocols available today and how they work in the network.  We will also discuss ways of reducing management overhead.
 
TCP/IP Network Management Demonstration:
This session will demonstration how you can manage a TCP/IP network using an SNMP Manager.  During the course of this demonstration, you will see the X.11 Motif based graphical user interface.  You will be shown how to use SNMP commands such as GET and SET to update and query real SNMP agents.
 
ISSC Southeast Region Network:
The IBM Southeast Region supports over 50,000 workstations that use close to 200 Mainframe Servers, 7500 applications, with TCP/IP and SNA WAN's and LAN's.  How did they staff?  How did they handle the new protocols on the network.  All those questions and
more will be answered.
 
TCP/IP Design and Planning Case Scenario:
The intent of this session is to determine the steps required to design and plan for a multiprotocol network. Attendees will be asked to design and plan for a proposed network 
given and existing network and planned clist/server application.

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 15:24:45 GMT
From:      nick@quay.ie (Nick Hilliard)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

Warner Losh (imp@boulder.parcplace.com) spoke thus:
[...]
: No.  127.* is a special network.  It was born special.  IP
: implementations should ***ALWAYS*** ignore everything they get from
: this address if it comes in over the wire and should ***NEVER*** send
: packets to this address out over the wire.  And it should do this be
: default.  Robust implementations should enforce this compeletely and
: leave no room for the user to configure this.  127.* ARP requests as
: well should never be on the wire, and completely ignored if they are
: seen by a host on the wire.  ICMP messages should likewise be treated.

I've actually seen a network whose admin (in his infinite wisdom) uses the
127.* network for normal IP numbers.  I.e. his machines are 127.0.0.2,
127.0.0.3, etc.  Strangely enough, it actually works.  Can't see why,
though.

Suffice it to say that there are only IBM implementations of TCP/IP on this
network.

Nick
-- 
| Nick Hilliard              | e-mail:   nick@quay.ie                    |
| Quay Financial Software,   | Phone:    [+353] 1 6612377                |
| 48-53, Lower Mount St,     |    The opinions expressed above do not    |
| Dublin 2, Ireland          | necessarily reflect those of my employers |

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 94 00:45:55 -0500
From:      tf49665@delphi.com
To:        comp.protocols.tcp-ip
Subject:   X3270 Emulation S/W Questions

 
   I have a need to automate the process of logging on to a IBM mainframe
from an UNIX platform using the x3270 emulation S/W.  Is there a way to send
a series of keystrokes which emulate the logon process to the x3270 program?
or I have to modify the program?  I will appreciate any help or advice and
please response via email.

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 16:35:44 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article <PPESSI.94Mar17041756@lk-hp-14.hut.fi> <Pekka.Pessi@hut.fi> writes:
> ...
>	I just tested this on two net/2 based systems (namely, OSF 1.3 and
>	AmiTCP/IP).  Both require you to say "ifconfig lo0 127.1".  Both
>	send packets to 127.2 happily to default router.  SunOS 4.1 and
>	HP-UX 9 route 127.2 to default router, too.  I guess that they are
>	not conforming to RFC 1122.

It looks to me that the SIOCSIFADDR ioctl() is not adding a network route
when the lo0 interface is turned on, because the in_ifinit() function
notices the IFF_LOOPBACK flag, and so adds a "host-route" as if the
loop-back interface is a point-to-point interface.

`route add 127.0 127.1 0` keeps packets to 127.2 from following a default
route in two somewhat different BSD implementations, one of them BSD/386
1.1.  Anyone who is bothered by packets to net-127 addresses other than
127.1 can simply add that command to their start-up scripts.

I do not know why the BSD code treats the loopback device as if it is a
point-to-point interface.  There must be a good reason, given the extra
two lines of code in if_ifinit().


Vernon Schryver    vjs@rhyolite.com

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 16:42:49 GMT
From:      drolling@lincoln.gpsemi.com (Dave Rollings LDC x 2392)
To:        comp.protocols.tcp-ip
Subject:   Data General AOS tcp/ip

Hello, I was wondering if anybody could help me...
I am looking into the availability of tcp/ip software for our
old Data General Computer System which runs an operating system called 
AOS.  The machine has no ethernet connection, so I would like
to be able to setup a slip connection through one of its
serial ports to allow a user to ftp or telnet onto it
from other tcp/ip hosts.
Has anybody successfully done this? and if so, can someone guide me
to a suitable ftp site which contains the apps I need.

Thanks in advance,

Dave Rollings

-----------------------------------------------
Dave Rollings
GEC Plessey Semiconductors
Lincoln. United Kingdom
email: drolling@lincoln.gpsemi.com
-----------------------------------------------

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 16:43:58 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Flow control and SLIP

In article <628@fjcp60.GOV> brinkema@fjc.GOV (John R. Brinkema) writes:
>A sad story: I have a machine and Unix operating system that does not
>support hardware flow control on the serial port (XON / XOFF works just
>fine).  I want to run SLIP on that serial port.  Do I have a problem?  Is
>there anyway I can configure the port / modem / whatever so that data
>overruns (if any) are benign.  I will be using V42bis with the ports set
>at 9600 baud.
>
>PPP is not an option.   jb.  tnx.


Lost data can never be "benign".  (Well, except for most of the 100MB/day
of netnews, including this text of mine.)  However, lost bytes or lost
packets are caused by lost SLIP delimiters not a big deal.  As long as
you disable XON/XOFF, only rarely does your computer get slow and drop
bytes, and you run below well the average speed of your modems (i.e. use
9600 with v.32bis/v.42/v.42bis), then SLIP will work fine.

Bytes lost to overruns will be detected by the packet lengths and
IP, TCP, and UDP checksums.

You could even use NFS with no more danger from implementations with UDP
checksums turned off than normal with SLIP, because lost bytes will be
noticed by the packet lengths.


Vernon Schryver    vjs@rhyolite.com

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 17:37:15 GMT
From:      dsc3jfs@imc220.med.navy.mil (John Skoda - ELF)
To:        comp.protocols.tcp-ip
Subject:   Re: Std for SMTP enclosures


 Try MIME!

--
--
                              _/\ /\_
                             {  . .  }
                             {       }
                               `V-V'

-- John F Skoda, Advisory Engineer	 | "Even a man who's pure in heart
-- electronic learning facilitators, inc.| and says his prayers by night,
-- Bethesda, MD                          | may become a wolf when the
-- Voice 301.968.4929                    | wolfbane blooms and the moon
-- Fax   301.986.0135                    | is full and bright"
-- Mail  jskoda@med.navy.mil.            |
                                 
with STD_DICLAIMER_PACKAGE;


-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 17:57:37 GMT
From:      rvw@laplace.math.purdue.edu (Rich Williams)
To:        comp.os.msdos.apps,comp.os.msdos.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip
Subject:   Need WinTel/NCSA telnet help (still).

I am looking for a real simple step by step instructions
for getting NCSA's WinTelnet running on a PC running
WFWG 3.1. All the systems are sharing disk and printers
but I can't figure out how to make the wintel stuff 
work.

The PCs have:
	3Com Ether Link II cards
	Running DOS 5.0 or 6.2
	486 or 386 processors
	Windows Netorking software

All suggestions are welcome.

 Best regards,

 Rich  Williams               |  Systems Administrator
 rvw@math.purdue.edu          |  Purdue University
                              |  Math Department
 #include <std/disclaimer.h>  |  West Lafayette, IN 47907

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 18:04:28 GMT
From:      jrv@truth.mitre.org (Van Zandt)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?

Here's an argument for putting the compression in the computer rather
than the modem: encrypted data.  I'd like to see IP (PPP?) connections
that negotiate session keys and encrypt all the data.  However, it would
defeat any compression built into the modem.

                       - Jim Van Zandt <jrv@mitre.org>



-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 94 18:31:46 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip protocol overhead costs

In article <CMrM9A.394@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>In article <6v4vuPj024n@comptech.demon.co.uk> elatar@comptech.demon.co.uk writes:
>>jjh@mwncc.mitre.org ( Jennifer Horton ) writes:
>>
>>> Anyone know how much tcp/ip overhead is added to a pkt ?
>>> ...
>
> [nifty discussion of per-packet overhead deleted]

The performance limiting aspects of TCP are typically related to other
things than "how many bytes am I adding to my packets".  At a gross
level, you need to count:

	1. Additional packets required for acknowledgements (see RFC 568),

	2. Additional packets for connection establishment/disestablishment,

	3. Effieciency of segment processing (header prediction, etc),

	4. Efficiency of moving the packet to user space.

All of these need to be addressed to really determine "efficiency" of a
protocol (probably more than these, in fact).  Different implementation
differ wildly, especially on (3) and (4), which are by far the most
important.

In other words, your mileage will DEFINATELY vary.  RFC967 discusses
this, too.

- Ted

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 410 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 18:32:17 GMT
From:      rleary@UMASSD.EDU
To:        comp.protocols.tcp-ip
Subject:   ST-II


  The current (Jan/Feb) issue of the IBM Multimedia Solutions magazine, 
in a discussion of the Ultimedia Server/6000, mentions the 
"Internet-family networking protocol called ST-II". Is this indeed 
an Internet family protol? If not, what is it? If so, please 
refer me to appropriate RFC. Thanks very much. 

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 18:36:00 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
: In article <CMo1yH.A82@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
: >I know of at least two commercial versions of IP that have had bug
: >fixes applied to them that stop them from spitting out 127.* to the
: >wire.  I'm not aware of anything that supplants this requirement in
: >RFC 1122.
: >
: >Any system that does spits 127.* to the wire is broken.
 
: Any system which when supposedly 'correctly configured' spits 127.* to the
: wire is broken. On that basis Linux is ok. On the other basis nothign is OK
: because as route I can force the issue anyway.

The problem with 'idiot proofing' a system is that 'idiots' can be highly
resorceful :-)

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 94 18:41:04 GMT
From:      jbrowne@zaphod.ncsa.uiuc.edu (Jim Browne)
To:        comp.os.msdos.apps,comp.os.msdos.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip
Subject:   Re: Need WinTel/NCSA telnet help (still).

rvw@laplace.math.purdue.edu (Rich Williams) writes:

>I am looking for a real simple step by step instructions
>for getting NCSA's WinTelnet running on a PC running
>WFWG 3.1. All the systems are sharing disk and printers
>but I can't figure out how to make the wintel stuff 
>work.

Try mailing wintel@ncsa.uiuc.edu.  (I'm not connected with Windows development,
so I don't know how to answer your question myself.)
-- 
Jim Browne                                             | jbrowne@ncsa.uiuc.edu |
Head NCSA Mac Telnet Hacker, SDG System Administrator  | (217) 244-7798        |
<a href="http://www.ncsa.uiuc.edu/SDG/People/jbrowne/jbrowne.html">Click me</a>
 "People can buy HANDGUNS easier." - S. Anichini, on accquiring IMSA yearbooks.

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 18:45:43 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...

Jim Reid (jim@cs.strath.ac.uk) wrote:

: On an NFS server, a number of nfsd kernel processes listen for
: incoming requests on UDP port 2049. On the client, the kernel creates
: a UDP socket on the fly if needed. This gives the outgoing request a
: source port number for the server to send its reply to. The port
: number used is effectively random: usually the first free UDP port
: between 512 and 1023. The NFS client uses one of these port numbers,
: fires the request at port 2049 on the server and waits for a reply.
: One of the server nfsd processes gets this request, carries out the
: transaction and returns a result to the waiting client process
: "listening" on the port number it sent the request from. When the
: reply is received, the client discards the socket it created for the
: NFS request and returns a result to the user process that initiated
: the request.
 
: BTW, the client biod processes use the same kernel code to instantiate
: sockets/port numbers. The only difference is that these sockets don't
: get discarded and recreated for each NFS request that they deal with.

The above is a description of a specific implimentation (Sun's). Though
many implimentations follow this. Alternatives such as creating a client
socket on a mount operation and destroying it on unmounting the file
system.

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 19:05:43 GMT
From:      goles@CS.UTK.EDU (Tomislav Goles)
To:        comp.protocols.tcp-ip
Subject:   traceroute?


Could someone please point me to the location of traceroute (utility
mentioned in Stevens' new TCP/IP book)?
Thanks in advance.

Sincerely,
Tom Goles
goles@cs.utk.edu or tgoles@mhfl.sbi.com

ps. Please respond by e-mail if possible.

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 19:37:00 GMT
From:      sean@oak.his.ucsf.edu
To:        comp.protocols.tcp-ip
Subject:   Changing gateways

Situation:  multiple sites with ethernet LANs supporting IP, IPX, AT,
interconnected by cisco routers and T1 serial links, all part of
subnetted class B net.

Problem:  Many hosts that are (and can only be) configured to use one
'gateway' address.  What happens when traffic moves to a different
router after router or link failure?

Options:  Reconfigure hosts.  Won't happen.  Run a gateway discovery
protocol on all hosts.  Not in my lifetime.  Use a 255.255.0.0 netmask
and let the routers answer with proxy ARP.  Why not?  Why not use
0.0.0.0 and never care about the gateway address?  Worst case, the user
can bounce there host and get a new gateway.  Best case, the host is
smart enough to ARP when a connection quits (unlikely).  What are folks
doing to deliver redundant gateway support to the desktop?

Sean McGrath - Voice: 510.653.8387
Email: sean@oak.his.edu
Paper: 638 66th st, Oakland Ca, 94609

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 20:12:52 GMT
From:      mre@teal.eng.sun.com (Mike Eisler)
To:        comp.protocols.tcp-ip
Cc:        
Subject:   Re: NFS port numbers and...

In article <JIM.94Mar15122713@dewar.cs.strath.ac.uk>,
Jim Reid <jim@cs.strath.ac.uk> wrote:
>On an NFS server, a number of nfsd kernel processes listen for
>incoming requests on UDP port 2049. On the client, the kernel creates
>a UDP socket on the fly if needed. This gives the outgoing request a
>source port number for the server to send its reply to. The port
>number used is effectively random: usually the first free UDP port
>between 512 and 1023. The NFS client uses one of these port numbers,
>fires the request at port 2049 on the server and waits for a reply.
>One of the server nfsd processes gets this request, carries out the
>transaction and returns a result to the waiting client process
>"listening" on the port number it sent the request from. When the

No arguments with all of this.

>reply is received, the client discards the socket it created for the
			       ^^^^^^^^

I would guess that most NFS implementations do not do this *as a
rule*.

The Sun NFS implementation (which was the basis for many other
implementations) for example allocates one socket or endpoint per
client handle, and once created, the socket stays with the RPC client
handle until the RPC client handle itself is destroyed.  RPC client
handles are allocated on demand up to a high water mark. The handles
(and their sockets) up to the high water mark are never deleted.  Early
implementations of NFS from Sun treated the high water mark as a fixed
wall, and if MAXCLIENT client handles were in use, the MAXCLIENT+1
request would have to wait for a client handle.

Later this was changed so that a client handle would be allocated
beyond the high water mark, and when the RPC request was completem the
extra handle, along with the socket, would be deleted.

For NFS in SVR4 and Solaris 2, replace "socket" up above with "stream".

The above is just one of a myraid of ways to do things. I've seen
implementations that have a socket per NFS mount (very space intensive
when using the automounter), and I'm pretty sure I've heard of
implementations that have just one UDP socket for all NFS client
handles and mount points (works well if you can tune up the flow
control limits and if contention on the socket is not an issue).

	-Mike Eisler
	mre@Eng.Sun.Com

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 20:13:40 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Design and Planning Forum

For those who couldn't tell, that was a commercial advertising/marketing
announcement.  Not appropriate for this list.  Of course, Raleigh is
best known for its SNA implementation so lack of civil posting practices
is perhaps not entirely unexpected...


-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 20:18:19 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: ST-II

In article <CMtnHv.K72@umassd.edu> rleary@UMASSD.EDU writes:
>
>  The current (Jan/Feb) issue of the IBM Multimedia Solutions magazine, 
>in a discussion of the Ultimedia Server/6000, mentions the 
>"Internet-family networking protocol called ST-II". Is this indeed 
>an Internet family protol? 	

NO

>If not, what is it? 

A multicast protocol developed for use by the US DoD in the SIMNET,
now called Defense Simulation Internet.  It is NOT on the Internet
standards-track and is extremely unlikely to ever become really
widespread or an Internet standard.

>If so, please refer me to appropriate RFC. 

ST-II is documented in an "informational" (i.e. not a standard) RFC,
but few if any implementations conform to that RFC.  There is movement
afoot to create a new RFC that accurately describes the actual
implementations, but that won't be on the standards-track either
in all liklihood.

Folks who want multicasting should look into IP Multicast, which is
commercial off the shelf technology today (been in IRIX for years and
Solaris 2.x and the newest OSF/1 for Alpha, Proteon routers, etc).
RSVP is an adjunct to IP currently under development that will provide
resource reservation to the Internet, including multicast.

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 20:44:47 GMT
From:      tburns@magnus.acs.ohio-state.edu (Timothy A N Burns)
To:        comp.protocols.tcp-ip
Subject:   baby questions

two easy(?) ones.

1) Help me get a LPD/LPR up and functioning.
     so far I have everyone connecting to the Internet via Telnet tcp apps.
     what do I need what do I do?  no WFWG or NetWare or anything, just want to
          share some printers.

2) oops question two goes someplace else...

tim+@osu.edu

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 22:43:47 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers and Broadcasting

In article <CMpsJw.1B5@unirsvl.rsvl.unisys.com> sybesma@unirsvl.rsvl.unisys.com (Eric Sybesma) writes:
>1) First off, what exactly is a router.  Does it
>   give visibility from LAN A to all hosts in LAN B.
>   If LAN B has a router to LAN C, can LAN A in turn
>   see all of LAN C?  Please elaborate.

The router gives these visibilities to all hosts and applications running
a network protocol that the router supports.  For instance, a TCP/IP router
will provide this visibility for TCP/IP applications, but not for Appletalk
applications (ignoring tunneling and encapsulation).  Most dedicated
routers these days are multi-protocol, so they can provide this visibility
for most networking protocols.

>2) Second.  What is a bridge?  Does it give visibility
>   in a different way than a router.  If so , how.

A bridge makes two LANs look like a single LAN.  It's sort of a smart
repeater -- it learns which addresses are on each LAN, and only forwards
packets to the appropriate LAN.

>3) Third, If I send a UDP broadcast to A.B.C.255, will
>   all the hosts on A.B.C get the broadcast?  What if I
>   had to go through several routers to get to A.B.C.

That's the normal behavior.  However, many routers can be configured not to
forward broadcast packets like these.  This is often done to prevent people
from an outside network from swamping your LAN with broadcasts.

>4) And finally, what is the difference between broadcasting
>   to A.B.C.255 and A.B.C.0 ?  And what does a broadcast to	
>   a CLASS A or B network look like.

Early TCP/IP implementations used A.B.C.0 as their broadcast address, due
to ambiguity in the specification.  This has since been standardized as
A.B.C.255, but some systems (e.g. SunOS 4.x) still come configured with
A.B.C.0 as the default broadcast address.

A Class A broadcast address looks like A.255.255.255, a Class B broadcast
address looks like A.B.255.255.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 21:39:37 +0200
From:      peter@nuustak.csir.co.za (Peter Greenwood)
To:        comp.protocols.tcp-ip
Subject:   Your experience with 3Com or Retix routers?

We're planning to upgrade our network, currently based on bridges,
with routers.  The network consists of 2500 PCs, 50 Netware file
servers, 80 UNIX workstations and hosts, 11 km (7 miles) of fibre
backbone linking 30 buildings in a ring running Ethernet, and 10 WAN
links (64 kbps).  Protocols are IP and IPX.

We're looking at several options, including Cisco, Wellfleet, 3Com and
Retix.  I'm particularly interested in hearing about anyone's
experiences with 3Com (Netbuilder II) and Retix (7000).  (I already 
have such information for 
Cisco and Wellfleet).  Does Retix/3Com do the job?  What problems
have you encountered?  How have they been resolved?  Would you
recommend or warn against either 3Com or Retix.

Please mail me at peter@csir.co.za.

Thanks in advance.

Peter Greenwood


-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 10:11:19 -0500
From:      aem@symbiosis.ahp.com (a.e.mossberg)
To:        comp.protocols.tcp-ip
Subject:   Re: RS-232 over RJ-45; any standards?

hak@alf.cooper.edu (Jeff Hakner) writes:

>We settled on a "standard" that is a modified version of DEC's
>MMJ pin assignments:
>	1	RTS
>	2	DTR
>	3	Tx
>	4	GND (Tx-)
>	5	GND (Rx-)
>	6	Rx
>	7	DSR/DCD
>	8	CTS



The only thing which appears modified in this is that you've swapped pins
1 and 8, which in MMJ (or RJ45 using MMJ pinning) 1 is CTS and 8 is RTS.


Note another advantage of using the MMJ-style pinning is that if you don't need
CTS/RTS you can use RJ12 cables into the RJ45 connectors.

aem
-- 
Andrew Mossberg      Network Administrator   Symbiosis Corporation,  Miami FL
(305) 597-4110 fax 597-4002, MD5OfPublicKey: 15784D117CC103912AEC427A3A99BA83

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 03:00:14 GMT
From:      samson@chpi.edu.tw (Samson Chen)
To:        comp.protocols.tcp-ip
Subject:   [Q] Why not use sendmail under inetd?

Dear netters,
	I have an old question.
	We have inetd as the super server for listening network. Why does
UNIX let sendmail listen network by itself.
Thanks.

--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
samson@chpi.edu.tw, Department of Complain Science
Chung-Hua Polytechnic Institute =|8-) <Fat Dragon>
300, Hsin-Chu, Taiwan ... eMail:samson@chpi.edu.tw

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 04:06:03 GMT
From:      sob@isr.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   Harvard router & bridge performance tests

	Well, Interop is just around the corner so it must be time for more
router and bridge abuse at Harvard  The window is from now until late April.
The results will be announced at a special session on May 4th during Interop
in Las Vegas and put up for anonymous ftp soon after.

	Since It is so soon after the last round of tests I'm mostly going to
be focusing on new products, ones that might have significantly different
performance than the versions tested last summer, and products that would use
one of the new types or quantities of interfaces.

	The tests performed include the Packet Loss Rate, Throughput and
Latency tests as defined in RFC 1242.

	This is an open invitation for any vendors of routers, bridges or
switches to take part.  There is no fee for participating in these tests.
(Since I expect that a representative of the vendor will be present during the
tests to configure the device and observe the procedure, the process is not
free to the vendor - but the hotels & airlines get the money not Harvard or
me)

        If you produce such a device and want to take part please give me a
call or send me email for more details and to schedule a testing time.

Scott Bradner
Harvard University
10 Ware St
Cambridge MA 02138
617-495-3864
sob@harvard.edu

----------------------------------------------------------
        There are two basic test setups:

setup 1
                           ---------------
                           |             |
               ------------|   tester    |-----------
               |           |             |          |
               |           ---------------          |
               |                                    |
      net A    |                                    |   net B
               |                                    |
               |           ---------------          |
               |           |   device    |          |
               ------------|    under    |-----------
                           |     test    |
                           ---------------

setup 2
                              ---------------
                              |             |
                              |             |
               ---------------|   tester    |--------------
               |              |             |             |
               |              ---------------             |
               |                                          |
      net A    |                                          |   net B
               |                                          |
               |   ------------            ------------   |
               |   |  device  |            |  device  |   |
               ----|   under  |------------|   under  |----
                   |    test  |   net C    |    test  |
                   ------------            ------------


	In the simple case for setup 1 traffic flows from the tester through
net A, through the device under test to net B and then back to the tester.

	In the simple case for setup 2 traffic flows from the tester through
net A, through the device under test to net C, through a second identical
device under test to net B and then back to the tester.

	Bi-directional traffic is also tested.

	Net A & net B are of the same type and can be Ethernets, token ring,
or FDDI. Testing will include devices with up to 48 Ethernet ports, 12 token
ring, 2 ATM T3 UNI or 6 FDDI ports.

	Net C can be a 64Kb, T1 or T3 WAN, a 64Kb, T1, or E1 frame relay
switch, an Ethernet, an FDDI ring or an ATM switch

	Protocols tested include TCP/IP, DECnet Phase IV, AppleTalk Phase II,
Novell IPX, OSI CLNP, Banyon Vines IP, bridge mode & mixtures of the same.


-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 11:19:16 CST
From:      zjhc05@amoco.com (John H. Caldwell)
To:        comp.protocols.tcp-ip
Subject:   Traceroute for Solaris 2.3?

Can anyone point me to a version of traceroute that has been ported
to Solaris 2.3 that can be picked up off the net?  Thank you in advance.

---

John H. Caldwell   Architecture and Standards Group    Amoco Oil Company
MC 802      200 E. Randolph Street      Chicago      Illinois      60601
(312) 856-3524      FAX: (312) 856-2558      SMTP:  jhcaldwell@amoco.com



-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 05:38:48 GMT
From:      hak@alf.cooper.edu (Jeff Hakner)
To:        comp.protocols.tcp-ip
Subject:   Re: RS-232 over RJ-45; any standards?

in article <763641254snz@cellar.demon.co.uk>, ash@cellar.demon.co.uk (Andrew Hardie) says:
> Date: Mon, 14 Mar 1994 10:34:14 +0000
> Message-ID: <763641254snz@cellar.demon.co.uk>
> Sender: usenet@demon.co.uk
> 
> Are there any "standards" for the connections to use when running
> RS-232 serial connections over RJ-45 connectors?
> I note that everyone seems to sell the 25w D-type to RJ-45 adaptors
> *unwired*, implying no standard.
> What are other people doing??
> Thanks.

We settled on a "standard" that is a modified version of DEC's
MMJ pin assignments:
	1	RTS
	2	DTR
	3	Tx
	4	GND (Tx-)
	5	GND (Rx-)
	6	Rx
	7	DSR/DCD
	8	CTS

The advantage of this scheme is that a null-modem cable is automatic
(just use a crossover RJ45-RJ45 cable).  It also allows for both
balanced and quasi-balanced operation (short the RS232 SG line to both
4 and 5).  If you then follow up with the provision that you wire
the DB25 or DB9 adapter kits so that the RJ45 always appears to be a DTE
(i.e.: for modems, wire the kit "crossed-over"), then you lose the
old worries about whether something is DTE or DCE and what cable
to use accordingly -- every RJ45 appearance is universal and you only
need a single style of patch cord (RJ45 crossed).

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 14:01:54 -0500
From:      conlonm@sentry.ndhm.gtegsc.com (Matthew Conlon)
To:        comp.protocols.tcp-ip
Subject:   FTP Software, WFWG, Sources?

Could a kind soul please point me towards a source for telnet/ftp software
package(s) for running under Windows for Workgroups?

Thank you.

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 07:25:04 GMT
From:      fkmunker@cip.informatik.uni-erlangen.de (Frank Munkert)
To:        comp.protocols.tcp-ip
Subject:   Routing table entry

Hi,

I have problems setting up the routing table entries for a SLIP
connection of a UNIX host to a router.

The address of the local SLIP interface is 193.100.1.1.
The address of the remote SLIP interface is 193.100.1.2.
The address of the remote router is 193.100.1.3.

After doing a slattach from 193.100.1.1 to 193.100.1.2, I cannot
perform the command

	/etc/route add net default 193.100.1.3 0

This command always fails with the error message "network is unreachable".

What am I doing wrong?

Many thanks in advance for any hints.

- Frank


---
Frank Munkert  <fkmunker@cip.informatik.uni-erlangen.de>

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 09:28:13 GMT
From:      asch@mx39.geu.siemens.co.at (Hans Aschenbrenner)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1006

From time to time there are requests on the net for the RFC1006 documents
Are there working implementations of RFC1006 interface for some stacks ore
winsockets ?
Hans

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 11:50:05 GMT
From:      jin@spdcc.com (Jerry Natowitz)
To:        comp.protocols.tcp-ip
Subject:   Re: netstat -r

In article <2m9ua1$ped@osiris.giss.nasa.gov>,
Ken Bell <syklb@nasagiss.giss.nasa.gov> wrote:
>In article <2m70ti$4to@linus.mitre.org>,
>Freedman <jfjr@mbunix.mitre.org> wrote:
>>
>>  I am working on Suns running 4.1.x. When I use netstat -r I get a list of
>>routes in the routing table. Some routes seem to be invulnerable to route 
>>delete commands - I get "not in table". What is going on when routes displayed
>>in the routing table via netstat -r are not removeable because the are
>>"not in table"
>
>Try "netstat -rn" to see the numeric IP addresses, then "route delete" those.
>
>-- 
>Ken Bell
>syklb@nasagiss.giss.nasa.gov / syklb@nasagiss.bitnet / (212)-678-5545

Would any of those routes be the route created by the ifconfig command for
an interface?  I'm not sure that those are flushable or deleteable.
-- 
     Jerry Natowitz - jin@spdcc.com

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 12:49:22 GMT
From:      hpa@ahab.eecs.nwu.edu (H. Peter Anvin N9ITP)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici

In article <CMon07.L9u@syd.dms.csiro.au> of comp.protocols.tcp-ip,
  marka@syd.dms.CSIRO.AU (Mark Andrews) writes:
> 
> 	With a strictly classless routing protocol you can use
> 	all 4 networks. The reason for the restriction is that
> 	RIP and similar protocols don't pass around network mask
> 	information but have to derive it from the address itself.
> 

How do you derive the subnet mask from an address such as 192.0.2.129?

Losing the 0* and 1* subnets really would lose in many contexts, in
particular subnetted class C networks.  Looks like a larger address
space is going to be needed soon...

	/hpa
-- 
INTERNET: hpa@nwu.edu               FINGER/TALK: hpa@ahab.eecs.nwu.edu
IBM MAIL: I0050052 at IBMMAIL       HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512    STORMNET:    181:294/101
This article might have been generated by a buggy newsreader.

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 94 14:51:45 GMT
From:      aml2@ukc.ac.uk (Andy Lagden)
To:        comp.protocols.tcp-ip
Subject:   SLIP

I have had an idea for a program which i could really use if it will work.
I would like any suggestions, or any ideas on possible problems.

Basically i have an Amiga running AmiTCP (which supports SLIP conections),
also we have terminal connections to the campus network via serial lines.
I believe these serial lines are 7bit and have a PAD ctrl-P break sequence.

I want to implement a SLIP type server to run under my UNIX account, so that
i can login, run the driver, and then startup SLIP on the Amiga, and carry on
by using telnet, rsh ect on the amiga.
The driver will do address decoding of the IP packets that the amiga sends, and
open the appropiate sockets ect to the destinations.
In all the program would be a like the term client/server that is available for
PCs and Unix, except the protocol would be SLIP.

Why: Because our campus hosts are not compiled for SLIP and probably never
     will be.
Problems: Would the 7bit or the PAD ctrl-P sequence get in the way?


Replies via email please..
 
Andrew Lagden
Computer Science Student, UK



-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 17:55:48 GMT
From:      tstark@clark.net (Tim Stark)
To:        comp.protocols.tcp-ip
Subject:   Wanted: network programming books

Hello Guys:

    I do not know how to write client/server programs for TCP/IP interface.
However I am looking for books that give lessions to write network programs
in C language. Does anyone have information about them? If so, can you
send me a listing of network programming books with descriptions,
publisher name, author name, ISBN number, and price list? If so,
I appericate that. Thanks you!!

-- Tim Stark

--
Timothy Stark			Inet: tstark@clark.net
6130 Edsall Rd. #301		TDD: (703)212-9731  FAX: (703)212-7598
Alexandria, Va. 22304-5859	Voice: Via VA Relay Center (800)828-1140
"God bless you! - My friend, Washington DC. - The Most Deaf Population City!"

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 18:14:51 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   Installing BSD iso code into Sun 4.1.x kernel



  Is it possible to install the BSDNet iso code ina Sun 4.1.x kernel?. How
much retooling is necessary?. I've written and installed drivers (character)
but nothing this extensive. Any advice, pro's cons etc would be appreciated.


-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 18:24:07 GMT
From:      paul@sprintlink.net (Paul Ferguson)
To:        comp.protocols.tcp-ip
Subject:   Re: SIPSO

Ran Atkinson (atkinson@itd.nrl.navy.mil) wrote:

> SIPSO was an attempt by the Internet community to fix CIPSO to conform
> to the IP spec, but the TSIG folks have a serious problem with "not
> invented here" and weren't willing to seriously consider the fix.
>
> Sigh.

Also, there is an interesting Internet Draft on the swIPe security
protocol.

The swIPe IP Security Protocol                            John Ioannidis
INTERNET DRAFT                                     (Columbia University)
Expires June 3, 1994                                          Matt Blaze
<draft-ipsec-swipe-01.txt>                              (AT&T Bell Labs)
                                                      December 3rd, 1993


e-mail: John Ioannidis <ji@cs.columbia.edu>

for more info or gopher it.

Cheers,


_______________________________________________________________________________
Paul Ferguson                         
US Sprint 
Enterprise Internet Engineering                    tel: 703.904.2437 
Herndon, Virginia  USA                        internet: paul@hawk.sprintmrn.com

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 19:31:45 GMT
From:      hleung@relay.nswc.navy.mil (Harry Leung)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip,comp.unix.sys5.r3,comp.lang.c,navy.nswc.netnews
Subject:   Re: What is putmsg() and poll() ld link?


Both of these are TLI functions.  TLI stands for Transport Layer Interface.
It is the System V equivalent of BSD sockets, not quite.  Hope this helps.

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 19:43:39 GMT
From:      mklee@gradient.cis.upenn.edu (Mike K Lee)
To:        comp.protocols.tcp-ip
Subject:   4.3BSD-TCP/IP for AIX3.2.5, HELP


Hello all, 

I am trying to port 4.3BSD's tcp/ip package to AIX 3.2.5...(to be
used as a user-level library and NOT putting it in the kernel) and I am
running into a lot problems.  I have read the /usr/lpp/bos/bsdport ,
and it helped, but not a whole lot....  

I want to know if anyone out there has done anything like this? 
(porting 4.3BSD system programs to AIX) 

Any info would be appreciated...

Mike Lee
mklee@gradient.cis.upenn.edu

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 20:20:44 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute for Solaris 2.3?

> Can anyone point me to a version of traceroute that has been ported
> to Solaris 2.3 that can be picked up off the net?  Thank you in advance.

Anon ftp to ftp.ee.lbl.gov.  I'm still running the version I compiled
under 4.1.3 and it runs fine under 2.3.  Be aware that the source route
mods that appear in various places for traceroute do not run under 2.3
(and won't without some coding changes).

	Rich Stevens

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 20:38:48 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip,comp.unix.sys5.r3,comp.lang.c,navy.nswc.netnews
Subject:   Re: What is putmsg() and poll() ld link?

Harry Leung (hleung@relay.nswc.navy.mil) wrote:
: Both of these are TLI functions.  TLI stands for Transport Layer Interface.
: It is the System V equivalent of BSD sockets, not quite.  Hope this helps.

Not quite - they are Streams functions. Streams is an optional product
on 9.X. There is no XTI/TLI interface to TCP on 9.x, but there will be
one on 10.0.

rick jones

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 21:13:31 GMT
From:      rchui@tethys.nswc.navy.mil (Raymond Chui)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip,comp.unix.sys5.r3,comp.lang.c,navy.nswc.netnews
Subject:   Re: What is putmsg() and poll() ld link?

In article <1994Mar18.193145.3036@relay.nswc.navy.mil>, hleung@relay.nswc.navy.mil (Harry Leung) writes:
|> 
|> Both of these are TLI functions.  TLI stands for Transport Layer Interface.
|> It is the System V equivalent of BSD sockets, not quite.  Hope this helps.

In HP-UX most TLI functions t_xxxxx are in /usr/lib/libxti.a, but
the functions getmsg(), putmsg() and poll() are in /usr/lib/libstr.a.
What a bum! HP-UX sucks! In your cc command require -lxti -lstr ld links.
But in Richard Stevens' book "Unix Network Programming" chapter 7 says
it needs -lnsl_s ld link. I guess he used different platform.

----------------------------------------------------------------------------
From: mark hahn <hahn@cortex.lrdc.pitt.edu>

Newsgroups: comp.sys.hp.hpux,comp.protocols.tcp-ip,comp.unix.sys5.r3,comp.lang.c

then presumably libnet does.  putmsg is a sysv streams thing and poll is
the sysv equivalent to select.  I don't know if either of them are available
on hpux, let alone hpux 8.  look at the man page for 'nm', which will allow
you to find what symbols are defined in your libraries.
---------------------------------------------------------------

For example:
{33}nm /usr/lib/libstr.a

Symbols from libstr.a[getmsg.o]:

Name                    Value   Scope  Type    Subspace

getmsg              |         0|extern|entry  |$CODE$
$cerror             |          |undef |code   |


Symbols from libstr.a[putmsg.o]:

Name                    Value   Scope  Type    Subspace

putmsg              |         0|extern|entry  |$CODE$
$cerror             |          |undef |code   |


Symbols from libstr.a[poll.o]:

Name                    Value   Scope  Type    Subspace

poll                |         0|extern|entry  |$CODE$
$cerror             |          |undef |code   |

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 21:43:18 GMT
From:      aszymane@mason1.gmu.edu (Anna A Szymanek)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP FAQ - does it exist? if yes how to get it? Thanks!

The subject has it all...


-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 23:45:05 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

Warner Losh (imp@boulder.parcplace.com) spoke thus:
[...]
: No.  127.* is a special network.  It was born special.  IP
: implementations should ***ALWAYS*** ignore everything they get from
: this address if it comes in over the wire and should ***NEVER*** send
: packets to this address out over the wire.  And it should do this be
: default.  Robust implementations should enforce this compeletely and
: leave no room for the user to configure this.  127.* ARP requests as
: well should never be on the wire, and completely ignored if they are
: seen by a host on the wire.  ICMP messages should likewise be treated.

Actually, I don't remember net 127 being allocated as the the loopback
net until after BSD unix started binding it's loopback psuedo interface
to address 127.0.0.1.  Maybe Jon Postel remembers more clearly than I.
In a lot of ways, BSD unix is responsible for the success of IP, but it
is also responsible for introducing some questionable practices as well.

Art


-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 23:54:56 GMT
From:      kkelly@metronet.com
To:        comp.protocols.tcp-ip
Subject:   Subnet Mask Feud

Here's your chance to help settle a brewing feud.  Is the
following true:

Assume a class B address with the following subnet mask:
144.9.0.0  netmask 255.255.255.128 (or 9 bits).  This would
result in 510 possible subnets (don't use 00000000.0 or
11111111.1) with up to 126 hosts on each (don't use 0000000
or 1111111). 

All subnets in 144.9.0.0 should use the same subnet mask.  
Consecutive subnets and availble host addresses would look
something like:
.....
144.9.35.0    hosts 1-126     broadcast 144.9.35.127  (net 70)
144.9.35.128  hosts 129-254   broadcast 144.9.35.255  (net 71)
144.9.36.0    hosts 1-126     broadcast 144.9.36.127  (net 72)
144.9.36.128  hosts 129-254   broadcast 144.9.36.255  (net 73)
..and so on....

Since we're using the high order bit in the last octet as part
of the subnetwork address the subnet address as ip sees it is 
different from the way we have to represent it using the dot
notation (i.e. subnet 70 is written as 35.0, 71 as 35.128, etc.).

The same goes for the broadcast address of all 1s.  Seven host
bits set to 1 results in 127, so the broadcast on 144.9.35.0 would 
be written as 144.9.35.127 and likewise the broadcast on 
144.9.35.128 would be written as 144.9.35.255 (because the high 
order bit is always set on this subnet).

The 4th host on subnet 144.9.35.0 would be addressed as 144.9.35.4
and on subnet 144.9.35.128 as 144.9.35.132.

Whattaya think?
-Keith
******************************************************************
* kkelly@metronet.com             *    4200 Amon Carter Blvd     *
* (817) 963-9050 voice            *    MD 2551A HDQCP            *
* (817) 963-8801 fax              *    Ft. Worth, TX 75019       *
******************************************************************

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 1994 01:16:06 GMT
From:      kathsed@cookie.rosemount.com (Kathy Sedro)
To:        comp.protocols.tcp-ip
Subject:   multiple-get with ftp

Hi Netters,

I am writing an ftp server and only intend to support stream mode. 

Since the client may not know how many files will be transferred in the case of a
multiple_get, and in stream mode, EOF is indicated by closing the data connection,
I am wondering how to indicate to the client that its data transfer process should
continue to listen on the same port for the next file.  

I suspect that this is normally handled via a particular reply on the control 
connection but none of them seem appropriate.


Thank you in advance for your answers.



Kathy

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 94 01:38:40 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip,comp.unix.ultrix,comp.sys.dec,comp.org.usenix,comp.dcom.lans.fddi,comp.unix.osf.osf1
Subject:   Port of Checksum Redundancy Avoidance to Alpha OSF/1


	This note is to announce availability of implementations of
checksum redundancy avoidance and a striping network interface driver
for Alpha OSF/1.  It is available for anonymous FTP from

ucsd.edu:/pub/csl/fastnet

	A while back Joe Pasquale and I published a paper on checksum
redundancy avoidance in the Winter '93 Usenix and released an
implementation of it for Ultrix.  This is a port of that software to
OSF/1.  Checksum redundancy avoidance is simply the observation that
for  TCP/IP data transmission over LANs, the software data checksums
are redundant with the LAN CRC, and it is worth avoiding doing the
software checksum in that case.  Checksumming is still done on routed
packets because then the software checksum is no longer redundant with
any CRC. 
	One problem we have with network research on Alphas is that
stock OSF/1 can already saturate an FDDI network, so we have to use a
striping driver to get higher bandwidths to see the effects of our
modifications.  Our solution is the striping, or concatenation driver.
This makes multiple FDDI drivers look like a single, much faster
driver.  We call this driver cat0 (for concatenation driver), and the
source code resides in io/dec/netif/if_cat.c.  It is included in the
distribution.
	Between the concatenation driver and checksum redundancy
avoidance, we are able to achieve 160 Mbps of throughput between two
Alpha 3000/500s, each equipped with two DEFTA FDDI interfaces striped
with cat0.  We are able to achieve 210 Mbps of throughput on the
loopback interface of a 3000/500.
	Note: the checksum elimination algorithm is experimental.  
	If you do anything with the software, or have comments on the
checksum elimination algorithm, I would be interested in hearing about it
(our addresses may be found at the bottom).
	There are miscellaneous other goodies likely to be of interest
to those interested in high performance networking: a SIGCOMM '93
paper on why realistic packet processing is not dominated by data
touching overheads (sigcomm93.ps), the old Ultrix 4.2a checksum
redundancy implementation in both patches to source and object files
(ultrix-4.2a-patches and ultrix-4.2a-BINARY, and a short monograph on
choosing packet size for best efficiency (BUFFERS).  Also, various
other software and papers written in the UCSD Computer Systems Lab can
be found in adjacent directories on the FTP server.  Still other
papers can be found on cs.ucsd.edu:/pub/csl.

There are several files in the distribution:

README - this note
DOC - documentation
BUFFERS - optimal I/O buffer size considerations
usenixw93.ps - the Usenix paper
sigcomm93.ps - a SIGCOMM paper on why data touching overheads don't
		dominate processing of realistic network workloads.
osf-1.3-patches - patches to Alpha OSF/1 1.3 source code implementing
		the improvements. 
osf-1.3-OBJS.tar.Z - object files for Alpha OSF/1 1.3 implementing the
		improvements. 
ultrix-4.2a-patches - patches to Ultrix 4.2a source code implementing
		the improvements. 
locore_patch - patch to Ultrix 4.2a MIPS /sys/machine/mips/locore.o
		(in BINARY distribution!) implementing RISC checksum.
ultrix-4.2a-OBJS.tar.Z - kit of object files to implement improvements
		on binary kernel.
ccsum.c	-	Extremely fast checksum routine for MIPS processors.


UNSUPPORTED OS's
	Oh, yeah: what happens if you aren't running exactly the same
version of OSF/1 or Ultrix than is supported here?  Good question.
This stuff will PROBABLY work with other releases since the TCP/IP
code doesn't seem to change much from release to release, but then
again it might not work.  I would be interested in hearing if you try
it out and it doesn't work - maybe some arrangements can be made.
	For that matter, it ought to be pretty easy to port the Ultrix
patches to any Berkeley Tahoe based OS, and it ought to be pretty easy
to port the OSF/1 patches to any Berkeley Reno or 4.4 based OS.


INSTALLATION

OSF/1 BINARY DISTRIBUTION:

	osf-1.3-OBJS has a BINARY subdirectory.  Copy the object files
in BINARY into the BINARY build directory of your kernel object tree,
being sure to first move old versions aside.   
	Next, some patches must be made.  Change directory to the top
directory of your kernel tree (normally /sys), and run

patch -p0 < osf-1.3-OBJS/patches

	The next step is to reconfigure your kernel.  If you are
running the GENERIC or GENERIC.rt kernel, this has been done for you.
Otherwise, use the same kernel configuration file (in /sys/conf on
Alphas and/sys/conf/mips on DECstations) as you already use EXCEPT you
need to specify that you want to use the checksum redundancy avoidance
and other performance-enhancing patches.  This is done by adding two
lines to the kernel configuration file:

options		SEQUOIA_FASTNET     	# faster networking
pseudo-device cat 1			# concatenation driver

Then follow normal procedures for building a kernel.


ULTRIX BINARY DISTRIBUTION:

	Copy in the object files in BINARY into /sys/MIPS/BINARY,
being sure to first move old versions aside.  Now, since locore.o is
typically recompiled whenever you reconfigure your kernel (even from
binary distribution!), you have to patch your locore.s using the patch
in locore_patch.
	The next step is to reconfigure your kernel.  Use the same kernel
configuration file (in /sys/conf/mips) as you already use EXCEPT you
need to specify which checksum improvement algorithm, if any, you wish
to use.  This is done by adding an option to the kernel configuration file:

options		SEQUOIA_FASTNET      # faster networking

Then follow normal procedures for building a kernel.
	Note: the object files are compiled in such a way that all the
improvements, even the experimental checksum elimination algorithm, are
enabled.  It is, however, possible to set things up so that you only use the
RISC checksum (more than halving the benefit of this package).  Since the
RISC checksum is completely contained in locore.s, and no other enhancements
are in there, one could only install that patch and avoid installing any of
the object files.

	Oh, yeah: what happens if you aren't running Ultrix 4.2a?  Good
question.  This stuff will PROBABLY work with other Ultrix releases
since the TCP/IP code doesn't seem to change much from release to
release, but then again it might not work.  I would be interested in
hearing if you try it out and it doesn't work - maybe some arrangements 
can be made.


OSF/1 SOURCE DISTRIBUTION:

	Change directory to the top directory of the kernel source
code to be patched.
	Make the patches to your source code, using 'patch -p0' and
the appropriate patches file.  If you are using source code of a
variant OS version, you may want to put in the patches by hand.  
	Next step is to reconfigure your kernel.  The patches
automatically configure the BINARY, BINARY.rt, GENERIC, and GENERIC.rt
kernel configuration files to add support for the SEQUOIA_FASTNET
option and cat0 concatenation interface.  If you are using a different
configuration file, you need to add the following two lines to it:

options		SEQUOIA_FASTNET     	# faster networking
pseudo-device cat 1			# concatenation driver

(the SEQUOIA_ prefix is to ensure that names of kernel enhancements from the
Sequioa 2000 project don't run afoul of other options invented
elsewhere).  
	Then build your kernel normally, starting with setup in the
kernel.sh script, because the patches don't modify the shadow in the
../obj directory.


ULTRIX SOURCE DISTRIBUTION:

	Make the patches to your source code, using the
ultrix-4.2a-patches file.  If you aren't using Ultrix 4.2a source
code, you may want to put in the patches by hand.  Then build your
kernel normally.

	Next step is to reconfigure your kernel.  Use the same kernel
configuration file (in /sys/conf/mips) as you already use EXCEPT you
need to specify which checksum improvement algorithm, if any, you wish
to use.  You do this by adding an option to your kernel.  There are
four options (if you specify none, you get a "normal" kernel): 

options		SEQUIOA_FASTNET      # all nifty new algorithms in one option
options		SEQUIOA_FASTSUM      # just RISC checksum
options		SEQUIOA_NOSUM        # just checksum elimination
options		SEQUOIA_NOSMALLBUFS  # just if_mtu reduction to 4k

(the SEQUOIA_ prefix is to ensure that names of kernel enhancements from the
Sequioa 2000 project don't run afoul of other options invented
elsewhere).  You can mix and match those options, but SEQUOIA_FASTNET
will save you time.


Addresses:

	Jonathan Kay			Professor Joseph Pasquale
	jkay@ucsd.edu			pasquale@ucsd.edu

	Department of Computer Science and Engineering
	University of California, San Diego
	La Jolla, CA 92093-0114

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 94 11:18:11 PDT
From:      fordjb@wln.com
To:        comp.protocols.tcp-ip
Subject:   Re: news reader?


In article <2m18eh$4po@krel.iea.com>, <santero@comtch.iea.com> writes:
> Path: 
> 
> Does anyone know of some good newsreaders for slip in Windows?
> 
> --
> --------------------------------------------------
> 
>  DCParsons - AlphaWave Computer Technology, Inc.
> 
>     santero@comtch.iea.com  509-326-6026
> 
I use NewtNews from Chameleon, and it works fine. I'm on with SLIP now, Win 
3.1, Norton Desktop 3.0. Nice product for me, though I've heard other folks 
grumble.

Call NetManage 408-973-7171, ask for Jim Verdi. They've got a new lower-cost 
version, I think.

BTW, where are you. Must be eastern Washington? I'm in Olympia.

Joe Ford <fordjb@wln.com>

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 1994 09:36:57 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet Mask Feud

In article <CMvx3K.9vz@metronet.com> kkelly@metronet.com writes:
    Here's your chance to help settle a brewing feud.  Is the
    following true:
    
The following, for the most part is true.

    Assume a class B address with the following subnet mask:
    144.9.0.0  netmask 255.255.255.128 (or 9 bits).  This would
    result in 510 possible subnets (don't use 00000000.0 or
    11111111.1) with up to 126 hosts on each (don't use 0000000
    or 1111111). 
    
    All subnets in 144.9.0.0 should use the same subnet mask.  
    Consecutive subnets and availble host addresses would look
    something like:
    .....
    144.9.35.0    hosts 1-126     broadcast 144.9.35.127  (net 70)
    144.9.35.128  hosts 129-254   broadcast 144.9.35.255  (net 71)
    144.9.36.0    hosts 1-126     broadcast 144.9.36.127  (net 72)
    144.9.36.128  hosts 129-254   broadcast 144.9.36.255  (net 73)
    ..and so on....
    
However, I know of no one who would refer to these as subnet 70, 71, 72,
etc. 

    Since we're using the high order bit in the last octet as part
    of the subnetwork address the subnet address as ip sees it is 
    different from the way we have to represent it using the dot
    notation (i.e. subnet 70 is written as 35.0, 71 as 35.128, etc.).
    
    The same goes for the broadcast address of all 1s.  Seven host
    bits set to 1 results in 127, so the broadcast on 144.9.35.0 would 
    be written as 144.9.35.127 and likewise the broadcast on 
    144.9.35.128 would be written as 144.9.35.255 (because the high 
    order bit is always set on this subnet).
    
    The 4th host on subnet 144.9.35.0 would be addressed as 144.9.35.4
    and on subnet 144.9.35.128 as 144.9.35.132.
    
    Whattaya think?

I think you're on the right track.  What is the point of contention?

Tony

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 1994 12:14:02 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: RS-232 over RJ-45; any standards?

In article <1994Mar18.053848.18705@alf.cooper.edu> hak@alf.cooper.edu writes:

>> Are there any "standards" for the connections to use when running
>> RS-232 serial connections over RJ-45 connectors?
 
>We settled on a "standard" that is a modified version of DEC's
>MMJ pin assignments:
>        1       RTS
>        2       DTR
>        3       Tx
>        4       GND (Tx-)
>        5       GND (Rx-)
>        6       Rx
>        7       DSR/DCD
>        8       CTS
>
>The advantage of this scheme is that a null-modem cable is automatic
>(just use a crossover RJ45-RJ45 cable).  It also allows for both
>balanced and quasi-balanced operation (short the RS232 SG line to both
>4 and 5).  If you then follow up with the provision that you wire
>the DB25 or DB9 adapter kits so that the RJ45 always appears to be a DTE
>(i.e.: for modems, wire the kit "crossed-over"), then you lose the
>old worries about whether something is DTE or DCE and what cable
>to use accordingly -- every RJ45 appearance is universal and you only
>need a single style of patch cord (RJ45 crossed).

Yes, but if your UTP cable is wired to the "stronger" standard
EIA/TIA PN 568  (also specified in UK GOSIP) then the following pairs
are twisted:
	1 & 2	no implications

	3 & 6	this causes Tx to be twisted with Rx, and is a source
		of cross-talk, and errors at high speeds.

	4 & 5	no implications, but pointless to twist 2 earths
	7 & 8	this twists CD  with CTS which might cause the 
		occasional transition error.
		
These things are only likely to cause a problem with long cable 
runs.

The only other problem we have not really got a good handle on
is the problem of a user incorrectly plugging an RS232C device (eg.
a terminal server seral port) into an ethernet 10baseT connection. 
Even with a structured wiring scheme, there's no foolproof way of 
clearly identifying RS232 serial ports from 10baseT ports. 
(Will a 50 volt Tx signal down pin 3 damage the 10baseT transceiver??)

Phil R
	
-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-986

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 94 14:36:00 GMT
From:      krishna@chainsaw (Kurapati SriKrishna)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP look-up methods, need help


Sometime ago I saw an article that discusses an efficient method for
TCP connection table lookup. But I forgot the article name, date,and
where it is published.

I am interested to know about articles that discuss this issue.
Please send me a mail if you got the information. 
send mail to krishna@anubis.network.com

Thanx in advance.

krishna

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 1994 16:40:43 GMT
From:      hurtta@dionysos.fmi.fi (Kari E. Hurtta)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: [Q] Why not use sendmail under inetd?

[ Added comp.mail.sendmail as receiver. Please select correct group for
  your followup. ]

samson@chpi.edu.tw (Samson Chen) writes:
»Dear netters,
»	I have an old question.
»	We have inetd as the super server for listening network. Why does
»UNIX let sendmail listen network by itself.

1) Nothing prevents starting sendmail from inetd with option -bs.

   However you must do also queue runs.

   Two possibility:
	a) You do queue runs from cron and run sendmail with option -q.

	b) You start sendmail with option -q<time>. That way sendmail
	   starts as deamon and does queue runs with given interval.

	However, if you select b), then you have already sendmail deamon
	running in system. So why not allow this same deamon to listen
	smtp -socket and accepting connections?

2) Or should you reprase question as:
	We have inetd as the super server for listening network. Why does
	UNIX let <arbitary program> listen network by itself? 

	Inetd's method to listening network isn't always sufficient. Sometimes
	programs need to do it itself. So listening network can't be
	exclusive privilege for inetd.

	(If you need examples, anyone can give couple of situations where
	 also some toher process than inetd must be able do listen -syscall).
--
- Kari E. Hurtta                             /  Elämä on monimutkaista
  Kari.Hurtta@Fmi.FI			     puh. (90) 1929 658

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 1994 17:08:10 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP look-up methods, need help

> Sometime ago I saw an article that discusses an efficient method for
> TCP connection table lookup. But I forgot the article name, date,and
> where it is published.

%T Efficient Demultiplexing of Incoming TCP Packets
%A P. E. McKenney
%A K. F. Dove
%J Computer Communication Review
%V 22
%N 4
%P 269-279
%D 1992
%m Oct.
%O Proceedings of the ACM SIGCOMM '92 Symposium

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 1994 19:49:37 GMT
From:      ptrubey@netcom.com (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 <--> TCP/IP Gateway ...?

In article <kleite-160394122614@157.176.173.2>,
Keith J. Leite <kleite@sentry.ndhm.gtegsc.com> wrote:
>Hello,
>	And thanks for reading my message, I know there must be some expertise in
>this newsgroup on this subject. The question I have is at present I am
>using a UB (Ungermann-Bass) X25 gateway which happens to be running XNS, I
>am wondering if there are any other companies that manufactor X25 gateways
>but running the TCP/IP protocol. We are trying to convert the site we are
>at from running XNS to TCP/IP and this is one of our hang ups .....

Any major multi-protocol router vendor these days supports both X.25 and
IP routing, specifically running IP encapsulated within X.25.  They can
also do X.29 PAD functionality translation to Telnet.  Router vendors
that support this that come to mind are Proteon and Cisco and Timeplex.

-- 

______________________________________________________________________

 Phil Trubey                 | 
 NetPartners                 |
                             | Providing independent consulting in the    
 E-mail: phil@netpart.com    |   application of Internet technology        
 Phone:  714-759-1641        |                                             
 Fax:    714-644-0577        |
______________________________________________________________________

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 1994 21:27:31 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] Why not use sendmail under inetd?

In article <2mb5fu$ggs@news.csie.nctu.edu.tw> samson@chpi.edu.tw writes:
>	We have inetd as the super server for listening network. Why does
>UNIX let sendmail listen network by itself.

Especially on older systems, sendmail startup can be expensive, as it has
to read the configuration file each time.  It's more efficient to start a
single sendmail and have it fork a child for each connection that comes in.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 1994 23:07:06 GMT
From:      pmetzger@andria.lehman.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)


In article <2m740m$f94@universe.digex.net> philp@universe.digex.net (Phil Perucci) writes:

>The cheapest full-time SLIP connection I have seen is about $200/month.

Netcom charges $160/month, I believe.

--
Perry Metzger		pmetzger@lehman.com
--
Otherwise reasonable people who understand that wishing will not make
rocks levitate often believe, in effect, that a well-intentioned government
program can successfully violate the laws of economics. This irrational
and almost religious belief in government is the root of our tragedy.

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Mar 1994 00:29:51 GMT
From:      epp4010@ultb.isc.rit.edu (E.P. Pylko)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: network programming books

In article <2mcpv4$bsd@clarknet.clark.net> tstark@clark.net (Tim Stark) writes:
>Hello Guys:
>
>    I do not know how to write client/server programs for TCP/IP interface.
>However I am looking for books that give lessions to write network programs
>in C language. Does anyone have information about them? If so, can you
>send me a listing of network programming books with descriptions,
>publisher name, author name, ISBN number, and price list? If so,
>I appericate that. Thanks you!!

"Unix Network Programming" is an excellent book.  I forget who wrote it
though.  The names Tannenbaum and Stallings sticks in my head although I
can't guarantee either of them is right.

>-- Tim Stark
>
>--
>Timothy Stark			Inet: tstark@clark.net
>6130 Edsall Rd. #301		TDD: (703)212-9731  FAX: (703)212-7598
>Alexandria, Va. 22304-5859	Voice: Via VA Relay Center (800)828-1140
>"God bless you! - My friend, Washington DC. - The Most Deaf Population City!"

BZZZT!  Rochester, NY is. :)  At least that's what my deaf friends say.

-Eric

-- 
Eric Pylko                            Great minds talk about ideas.
epp4010@ultb.isc.rit.edu              Average minds talk about things.
epp4010@cs.rit.edu                    Simple minds talk about people.

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1994 01:57:29 +0100
From:      robjan@rabo.nl (Rob Janssen)
To:        comp.protocols.tcp-ip
Subject:   IP address / hardware address monitor?

A local IP network consists of a few ethernet TP hubs interconnected
by routers.  The hubs have 'locked ports' which only accept traffic
with a hardware address configured for each port.

For security reasons (don't ask...) it is desired to prevent forging
of the IP address of the connected machines.  However, the hub cannot
do this, and the router cannot be configured to check the hardware
address on incoming packets.

To detect forged IP addresses, it would be a possibility to connect
a monitoring system to each ethernet segment (e.g. a PC with interface
card in promiscuous mode) which checks each received packet to make
sure the hardware address / IP address combination is legal (according
to a pre-configured table)

Does such a program already exist?
Or does anyone know of another method?

(I have considered reading the router's ARP table using SNMP, but
as the router does not check the table for received entries, and
the hub passes through all packets to all ports, this is no good...
one can still send packets from legal_hardware_address/forged_IP_address
and receive the replies sent back to the real hardware_address
corresponding to forged_IP_address)

Rob

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 94 07:31:29 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] How to determine TCP Max. Segment Size (MSS)?

In article <2m8j0iINNr2t@excalibur.cs.purdue.edu> lin@cs.purdue.edu (John Chueng-Hsien Lin) writes:
>  How does a TCP determine the maximum segment size (MSS) if the peer TCP is
>attached on the same cable?
>  Method 1) MSS = Interface_MTU - 40
>  Method 2) MSS = (Interface_MTU - 40) / MCLBYTES * MCLBYTES
>                  (i.e., Round down to nearest multiple of MCLBYTES)
>		  Where MCLBYTES is an mbuf cluster size.
>  Which method is better?

Most TCPs use method 2, probably mostly for historical reasons
involving data copying architecture of of 4.2 BSD.  To be sure, there
is a penalty to allocating an extra mbuf, but it isn't nearly as great
as the penalty for sending an extra packet.

Method 1 is better.
 
							Jon

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Mar 1994 08:51:56 GMT
From:      matthews@teal.csn.org (John Matthews)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??

In article <xxx>vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>In the systems I know about ICMP echo requests involve very different
>paths on the source machine, the echoing machine, and back on the source
>machine than ordinary TCP/IP or UDP/IP packets.  I would not believe any
>conclusions drawn about the computers based on ICMP echo requests.
>The echo port, port 7, both UDP and TCP, would yield somewhat less
>uninteresting answers.
>One could also use something like `ttcp` (source found on brl.mil and
>sgi.com), or something hacked from `ttcp`, either UDP or TCP.

I agree mostly with what you're saying except that you can't create
a big enough TCP window to keep multiple wide-area T1 paths completely
saturated.  I don't know if 'ttcp' can create a BIG simulated sliding window
using UDP echo packets.  If it can, or anything else you know of does,
please let me know.  I'd like to try them out.

I have already re-written ping to do exactly what I want and it simulates
a sliding window and automatically determines the window size to completely
saturate any network path by slowly growing the window until the pkts/sec
received during a certain number of intervals no longer increases.  I had
to do this because the existing flood option for ping would cause output
drops in our ciscos since the output buffers were exhausted because the
packets were coming in much faster than the cisco could deliver them across
a slower frame-relay circuit.  This new version of ping gives me a much
more accurate picture about what packets are really being dropped.  So far,
it's working well.  Another side-effect of the OLD flood algorithm is that
because it was stealing ALL output buffers across WAN links and was causing
my SNMP status polls to get dropped.  Now, I can completely load the circuits
at 100% and other network traffic (at least some) can still get through.

					John Matthews
					matthews@uswest.com

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 94 20:30:24 PST
From:      tpoernomo@csupomona.edu
To:        comp.protocols.tcp-ip
Subject:   OSPF Message Format Question

Anybody familiar with OSPF ? I have a question:
* In the header of the OSPF packet, there is a field of THE IP ADDRESS OF THE
SOURCE GATEWAY (The IP address of the gateway that sends the update message).
How can a gateway has has only one address ? What I know is that gateway
always have more than one connection. What does it mean by each gateway 
include its IP address on each OSPF message then ?
Thanks in advance!

Tedjo Poernomo   tpoernomo@csupomona.edu

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1994 22:12:02 -0500
From:      bacon@mtu.edu (Jeff Bacon)
To:        comp.protocols.tcp-ip
Subject:   Rhetorical question for the group

let us suppose the following:

you're in the middle of nowhere. assume third-world technology
available, i.e. poor local phone system based on old technology.
(you can make a long-distance phone call, but the link sucks rocks.)
you're at least 400 miles from anyone with any sort of real connectivity,
probably much more to connect in to a decent point-of-presence. 

you want to get on the internet. full IP connectivity required. 
at a minimum, 56kb. preferably T1 or T3. 

you have a LOT of money at your disposal. let's say, working figure of
$2mil US. satellite connections are not out of the question, there
are satellites available.

how would you do it?

-bacon

--
= Jeffery Bacon     General Systems Hack, Michigan Technological University =
= bacon@mtu.edu     ph-(906)487-2197 fax-(906)487-2822    Printing is Evil. =
=          End of Earth, 13 miles. Are your seat belts fastened?            =

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Mar 1994 17:12:04 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??

In article <CMyGML.999@csn.org> matthews@teal.csn.org (John Matthews) writes:
>In article <xxx>vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>>In the systems I know about ICMP echo requests involve very different
>>paths on the source machine, the echoing machine, and back on the source
>>machine than ordinary TCP/IP or UDP/IP packets.  I would not believe any
>>conclusions drawn about the computers based on ICMP echo requests.
>>The echo port, port 7, both UDP and TCP, would yield somewhat less
>>uninteresting answers.
>>One could also use something like `ttcp` (source found on brl.mil and
>>sgi.com), or something hacked from `ttcp`, either UDP or TCP.
>
>I agree mostly with what you're saying except that you can't create
>a big enough TCP window to keep multiple wide-area T1 paths completely
>saturated.  I don't know if 'ttcp' can create a BIG simulated sliding window
>using UDP echo packets.  If it can, or anything else you know of does,
>please let me know.  I'd like to try them out.

Each TCP window applies to a single TCP connection.  T1 is only
1.5Mbit/sec.  How many T1's do you have in series that a few MBytes of
TCP-LW window is not enough to keep them saturated?  The delay around the
world at the ground is less than 150 milliseconds, and at T1 speeds that
is only 30KBytes, so a 64K old fashioned TCP window is more than enough
to keep a T1 around the world busy.

Anything that simply transmitts at full speed can fake a "simulated sliding
window" as large as you want.  A sliding window is more a matter of not
transmitting than of transmitting.  You must already be doing something
in your ping code to infer the feedback needed to do something related to
the word "window."

`Ttcp -u` produces a largely (but not entirely) unidirectional flow.
It would be necessary to modify it to "simulate a sliding window."


>I have already re-written ping to do exactly what I want and it simulates
>a sliding window and automatically determines the window size  ...
 
>               ... the existing flood option for ping would cause output
>drops in our ciscos since the output buffers were exhausted because the
>packets were coming in much faster than the cisco could deliver them across
>a slower frame-relay circuit. ...

Have you asked Cisco if ICMP Echo's use the standard path?  Try `ping -R`
through a mesh of Cisco wide area routers, and notice that consecutive
packets do not take the same route.  That is because either the RR option
or the fact that it is an ICMP-Echo cause the Ciscos to handle the packet
specially.

In your position, I'd at least change that modified ping source to use
UDP or TCP traffic to port 7.


Vernon Schryver    vjs@rhyolite.com

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1994 18:20:32 GMT
From:      dpuertas@bu.edu (Daniel Puertas)
To:        comp.protocols.tcp-ip
Subject:   FTp to Mac HD

	I would like to FTP directly to my mac HD. If anyone has any information on free software available for this type of thing please mail me ASAP

				Daniel

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1994 23:45:13 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??

Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
}Each TCP window applies to a single TCP connection.  T1 is only
}1.5Mbit/sec.  How many T1's do you have in series that a few MBytes of
}TCP-LW window is not enough to keep them saturated?  The delay around the
}world at the ground is less than 150 milliseconds, and at T1 speeds that
}is only 30KBytes, so a 64K old fashioned TCP window is more than enough
}to keep a T1 around the world busy.

   Well, in at least one case, 150 ms only gets your 30 miles
   down the road:

traceroute to dsm6.dsmnet.com (198.202.223.38), 30 hops max, 40 byte packets
 1  router140.iastate.edu (129.186.140.254)  4 ms  4 ms  4 ms
       :
19  dsm6.dsmnet.com (198.202.223.38)  151 ms  148 ms  145 ms

  (of course, it passes through Lincoln, St Louis, Houston,
  Atlanta, Greensboro, Washington DC, and Chicago).

John `my packets visited the US, and all I got is this lousy traceroute' Hascall
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 00:52:50 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici

In article <CMv2AE.FMy@eecs.nwu.edu> hpa@nwu.edu (H. Peter Anvin) writes:
>In article <CMon07.L9u@syd.dms.csiro.au> of comp.protocols.tcp-ip,
>  marka@syd.dms.CSIRO.AU (Mark Andrews) writes:
>> 
>> 	With a strictly classless routing protocol you can use
>> 	all 4 networks. The reason for the restriction is that
>> 	RIP and similar protocols don't pass around network mask
>> 	information but have to derive it from the address itself.
>> 
>
>How do you derive the subnet mask from an address such as 192.0.2.129?
>
>Losing the 0* and 1* subnets really would lose in many contexts, in
>particular subnetted class C networks.  Looks like a larger address
>space is going to be needed soon...
>
>	/hpa

	Perhaps it would be been better to say 'derive it from external
	information.'

		e.g. interface netmasks, network class.

	If I wasn't on net 192.0.2 it has a mask of 255.255.255.255 i.e.
	it is a host route. If I am on 192.0.2 I would have to use other
	information.

	Is 192.0.2.0 a route to 192.0.2 or to the cidr block
	192.0.2 - 192.0.3?

	With RIP is is the former with a classless protocol it could be
	either or neither.

	Moving from RIP to RIP II or OSPF will prove more timely
	fixes.

	Mark

-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 16:13:19 -0800
From:      pamela@legato.com (Pamela Pledger)
To:        comp.dcom.sys.cisco,comp.sys.ibm.pc.hardware.networking,comp.protocols.appletalk,comp.protocols.tcp-ip,comp.unix.admin
Subject:   help: firsttime cisco set up

Hello,

Perhaps you can forwarn us, or beat the venders, in our
endevour to set up this cisco 4000.

We are setting up our cicso 4000 in parts. 
Part I ) split 1 net into 3.
	ie. 137.68.30.0 becomes 137.69.30.0, 137.69.31.0 and 137.69.32.0
	( not valid network numbers. )
Part II, use cisco to connect to our internet connections
	and use the packet filtering.
So, far we've run into a few problems.
	) The connections between the cisco 4000 and our david systems
		hubs only have traffic ( and with 20% packet loss )
		by connecting David systems aui to a allied telisys
		transiever to bnc to another allied telisys transciever
		to the cicso aui ports.  I'd rather not have packets
		lost on the link betIen the hub and cisco.  I'd 
		rather use twisted pair.  ( I use straight thru. )
	) I have not been able to get the apple talk to work with
		our gator box.
	) I couldnt get ip routing to work correctly, 
		137.69.30 only talked on it's hub, 137.69.31 only
		talked on it's hub, etc  No ip packets were
		routed to their destinations on the other nets.

I feel that I are just a few details away from getting the cisco
	to work. 
I am calling David Systems and cicso.  Cisco had not been 
	extremely helpful ( no contract,no classes ).  But I
	was under the impression from the salesperson and other
	users that it would take minimal setup to work on our simple 
	environment, and the manuals and tech support would fill in 
	the gaps.  This has not been our experience so far.
While the venders play pickle with us, I'd like to know if there
	is any more problems to expect with hardware compatability
	( very important ), routing, and alternet setup?  And/or
	any pointers on how to set the cisco up would be very
	helpful, too 8^).

Please reply via direct email, as I do not get to all these newgroups
every day. 

Thanks,

Pamela Pledger	
Unix System Admin
Legato Systems, Inc
"We Back You Up!"	
pamela@legato.com

Our set-up :
			cisco 400
 ___________________________|______________________________________
	|			|			|
 Net 1 ( Ethernet )     Net 2 ( Ethernet )      Net 3 ( Ethernet )
	|			|			|
   ( #!# Problem, we'd like twisted pair, see above #!# )
	|			|			|
 David Systems HDH	David Systems 12slot	David Systems 12slot
  |         |                   |			|
Internet  DS/12slot	Twisted Pair		Twisted Pair
System 	  10BaseT	

	EACH Net has :
		Unix TCP/IP, Netware, and Appletalk.



-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 03:32:05 GMT
From:      medik@cbnewsf.cb.att.com (david.i.kapalko)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   How to implement a timeserver?

Please forgive me for what might be simple question:
We're using bootp and DNS so I'm familiar with the idea of that kind of 
service provider under TCP/IP. Now I'd like to set up a timeserver on TCP/IP.
What is needed  for UNIX machines to be timeservers and what is needed
on another UNIX machine to be a client of that timeserver?  Also, what is
needed for a pc to be a client of that UNIX timerserver?

Thanks,
	Dave Kapalko
	medik@attme.att.com


-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 03:50:41 GMT
From:      m8242617@dec.mis.nsysu.edu.tw (m8242617)
To:        comp.protocols.tcp-ip
Subject:   Help for KA9Q

Hi,
   I am looking for KA9Q's source code, If you know where I can find it,
please tell me. Thank you very much!! My E-mail address is

    m8242617@dec.mis.nsysu.edu.tw     or
    frank@cc.nsysu.edu.tw

frank Lin

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 04:00:18 GMT
From:      nelson@crynwr.crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <PMETZGER.94Mar19180706@andria.lehman.com> pmetzger@andria.lehman.com (Perry E. Metzger) writes:

   In article <2m740m$f94@universe.digex.net> philp@universe.digex.net (Phil Perucci) writes:

   >The cheapest full-time SLIP connection I have seen is about $200/month.

   Netcom charges $160/month, I believe.

TLG charges $70/month for V.32bis, $130/month for V.FAST, $325/month
for 56Kbps, and $800/month for T1.  Only problem is, you have to know
what you're doing, and you have to be in the San Francisco Bay Area.
Ask <info@tlg.org> for more info.

--
-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 05:01:20 GMT
From:      brtatach@uncc.edu (Balaji Ramanujam Tatachari)
To:        comp.protocols.tcp-ip
Subject:   need help on select() - when listening on 'S O C K E T S'

i would appreciate if someone could explain the idea of using select() while listening on multiple sockets through an example.

Primarily, i would like to know how does one go abt deciding when 2 use multiple sockets (design considerations)? where is the need for multiple sockets? what does one achieve by using Select()?






-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 14:26:43 -0500
From:      cobrien@access.digex.net (Cary B. O'Brien)
To:        comp.protocols.tcp-ip
Subject:   etherfind/tcpdump not seeing outgoing packets ?

I have found that etherfind (on sun4 sunos4.1.3) and tcpdump
(on my linux box) both suffer from the same problem -- they
cannot see packets originating on the system where the monitor
program is running.  Because of this I always have to use
a third machine to monitor traffic between two machines, and at
some sites this is not available (i.e. 1 sun, many dos PCs).

Am I doing something wrong?

Cary O'Brien
cobrien@access.digex.net



-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 94 13:24:48 PDT
From:      bpeters@london.micrognosis.com
To:        comp.protocols.tcp-ip
Subject:   SUBNETTING CLASS C IP ON WAN



Has anyone out there experienced any problems subnetting Class C addresses over 
a WAN. This is something we need to do in a clients, and I have heard that we 
may have difficulties doing this.

Any replies would be gratefully appreciated, preferably on e-mail.

**************************************************************************
*									 *
*  Bill Peters			E-Mail: bpeters@london.micrognosis.com   *
*  Software Support		   Tel: (+44) 71 815 5298		 *
*  MICROGNOSIS			   Fax: (+44) 71 815 5201 	         *
*  LONDON U.K.								 *
* 									 *
**************************************************************************


-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 08:22:40 GMT
From:      terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] Why not use sendmail under inetd?

In article <2mb5fu$ggs@news.csie.nctu.edu.tw>, samson@chpi.edu.tw (Samson Chen) writes:
> 	We have inetd as the super server for listening network. Why does
> UNIX let sendmail listen network by itself.

  I'll answer this from the standpoint of a generic TCP service. Further info
about sendmail should probably be discussed in comp.mail.sendmail.

  The most probable reason that sendmail normally runs in daemon (-bd) mode
is for performance. Before the Host Requirements RFC's, some systems were
quite picky about getting fast response to SMTP connections. [Of course,
VAX/VMS systems put an end to much of that, VMS being rather slow at process
creation].

  You can change sendmail to run under inetd by changing your startup invo-
cation of sendmail to remove the -bd option. For example, "sendmail -bd -q30m"
becomes "sendmail -q30m". Then add sendmail to your inetd.conf file, sort of
like this:

smtp	stream	tcp	nowait	root	/usr/sbin/semdmail	sendmail -bs

  Unless you're trying to accomplish something special, this isn't very use-
ful. We do it here for two reasons: so we can have all connections logged in
/var/log/messages, and so we can use the TCP Wrapper program to selectively
deny access (we deny access from terminal servers, the loopback address, etc.)

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381

-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 09:27:34 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??

In article <CMz3s4.3qB@calcite.rhyolite.com> vjs@calcite.rhyolite.com
(Vernon Schryver) writes: 

    >I have already re-written ping to do exactly what I want and it simulates
    >a sliding window and automatically determines the window size  ...
 
    >               ... the existing flood option for ping would cause output
    >drops in our ciscos since the output buffers were exhausted because the
    >packets were coming in much faster than the cisco could deliver them
  across 
    >a slower frame-relay circuit. ...
    
    Have you asked Cisco if ICMP Echo's use the standard path?  Try `ping -R`
    through a mesh of Cisco wide area routers, and notice that consecutive
    packets do not take the same route.  That is because either the RR option
    or the fact that it is an ICMP-Echo cause the Ciscos to handle the packet
    specially.
    
ICMP Echo's use the "standard" heavily-optimized path through the router.
Packets with options don't.  Ping's of the routers themselves don't.

Tony

-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 11:05:48 GMT
From:      khweis1@mvmhp.ciw.uni-karlsruhe.de (Karl-Heinz Weiss)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,alt.winsock
Subject:   Announcing an access-controlprogram for slipgates

Announcement of SLIPLOG, an access-controlprogram for your slipgate
-------------------------------------------------------------------
What it does:
 -polls the modem for incoming rings
 -switches to auto-answer
 -sends a greeting message to the caller
 -prompts for a password
 -switches to packetmode after a successfull login
 -logs all calls with time and date 
 -can call- back the caller (increased security)
 -patches the slipdriver, so no packets ar send when not connected
  (this increases the stability of the gatesoftware and the modem) 

SLIPLOG may be useful for any ibmpc-gatesoftware which uses packet-
drivers, but has been tested with ka9q-nos (nos192 and nos10b) only.

You may ftp it from:
mvmpc9.ciw.uni-karlsruhe.de (129.13.118.9) /public/nos/sliplog.zip
(ws_ftp-users should select 'ka9q' as servertype!)

Enjoy!
-------------------------------------------------------------------
K.H. Weiss            E-mail  : <khweis@mvmhp.ciw.uni-karlsruhe.de>
Eulenweg 2            Phone   : (49)-7244-1792
76536 Weingarten      Germany

-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 13:41:54 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   source routing questions



   I am interested in any available (commercial or PD) osi
implementations that support source routing. This leads to the
question :

   Given that I have source routing how do I get to it. According to
the specs most of my interaction with the stack is at the application
layer which is far above the place(s) where source routing is a
factor. Therefore, is source routing specified in some initial
configuration? Is is toggled by some sort of ioctl?

  How does source routing play in the TCP/IP world. Does anybody
seriously use it?. For what? How do I get to it?


                               Jerry Freedman,Jr

-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 15:12:59 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple-get with ftp

In article <1994Mar18.191606@cookie.rosemount.com>, kathsed@cookie.rosemount.com (Kathy Sedro) writes:
|> Hi Netters,
|> 
|> I am writing an ftp server and only intend to support stream mode. 
|> 
|> Since the client may not know how many files will be transferred in the case of a
|> multiple_get, and in stream mode, EOF is indicated by closing the data connection,
|> I am wondering how to indicate to the client that its data transfer process should
|> continue to listen on the same port for the next file.  
|> 
|> I suspect that this is normally handled via a particular reply on the control 
|> connection but none of them seem appropriate.

"Multiple get" is implemented at the application level, not at the FTP
protocol level.  The FTP protocol supports transferring just one file at
a time.

To support "mget," an FTP client will do an "NLST" command to retrieve
the names of the files first, then it will do "RETR" for each of those
files.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 16:13:14 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: ST-II

In article <2manm0$mpj@cascade.cs.ubc.ca> velthuys@cs.ubc.ca (Rolf Velthuys) writes:

>I guess this depends on what you call 'internet family'. It is defined
>in RFC 1190 'the internet STream Protocol, version II'. It is not one
>of the protocols with 'mandatory' status (not sure about the actual
>term here).

ST-II is not an Internet standard protocol (see the most recent RFC on
IAB Official Standards which is the authoritative source for this data), 
nor is it on the Internet standards-track.  Many things that are not part
of the Internet Protocol Suite are documented in RFCs.

>#ST-II is documented in an "informational" (i.e. not a standard) RFC,
>#but few if any implementations conform to that RFC.  
>
>I know of three implementations of STII. One is (was ?) available from
>bbn on an anonymous ftp site, one was developed during a sabatical at
>Swedish Institute of Computer Science (SICS) in Stockholm. Also there
>is (was?) a group within IBM that used STII in a prototype high speed
>network.

The fact that most (all ?) extant ST-II implementations don't fully
conform with the current RFC was brought out by Craig Partridge and
others at the November 1993 IETF meeting in Houston, TX.  Craig
has implemented ST-II and had a number of interesting insights
into the problems with the current ST-II specification.


>RSVP ? 

There is an Internet Draft on RSVP available via anonymous ftp from:
	ftp.internic.net:/internet-drafts/draft-braden-rsvp-*.txt,ps

Ran
atkinson@itd.nrl.navy.mil



-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 16:45:04 GMT
From:      aboba@netcom.com (Bernard Aboba)
To:        alt.internet.services,comp.sys.mac.comm,alt.bbs.internet,comp.protocols.tcp-ip
Subject:   Internaut V1 N1 Now Available

Issue #1 of Internaut, an online magazine for users of the Internet, is 
now available. 

To obtain the magazine, ftp ftp.netcom.com, get 
/pub/mailcom/internaut/internt1.zip. In order to view these files you 
will need a Mosaic browser; use the Open Local... entry in the File menu, 
and select index.html. 

In this issue:

Net History

How the Internet Came to Be, by Dr. Vinton Cerf
Community Memory, a History, by Lee Felsenstein
How PC-IP Came to Be, by John Romkey
Information Ecology

How-To

An Introduction to Cable Internet
TCP/IP on the IBM PC
Setting up Taylor UUCP
BBSNet, by Brad Clements
CU-SeeMe: Video Conferencing over the Internet

Store and Forward Networks

The OneNet



-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 16:54:41 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple-get with ftp

In article <1994Mar18.191606@cookie.rosemount.com> MAKE_ADDRESS(USER,empros.com) writes:
>I am writing an ftp server and only intend to support stream mode. 
>
>Since the client may not know how many files will be transferred in the case of a
>multiple_get, and in stream mode, EOF is indicated by closing the data connection,
>I am wondering how to indicate to the client that its data transfer process should
>continue to listen on the same port for the next file.  

The FTP protocol doesn't contain a "multiple-get" operation.  The Unix
"mget" command works by using NLST to get the list of files, and then
performing a separate "get" on each file.  No special support is necessary
in the server.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 94 23:09:23
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: protocol between Terminal server and unix

Most terminal servers use either the telnet or rlogin protocols for
connections to unix systems.  In general, these should not place a
significant bottleneck in the way of zmodem transfers.  In fact, transfer
speeds in excess of 4000 bytes/second have been observed between PCs and
unix systems, connected with the relatively modestly-performing cisco
terminal server.

Now, you could have an especially poorly performing terminal server, but it
sounds like there is more likely to be a configuration problem like lack of
HW flow control between the modems and terminal server.

telnet/rlogin wise, the biggest performance bottleneck seems to be the pty
interface of most unix systems - each byte traverses the kernel/user boundry
several times before being input to your program.  While ideas to increase
the performance (or decrease the cpu overhead) of network terminal protocols
have surfaced from time to time, they generally aren't of much use unless
this problem is corrected first.

BillW


-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 19:54:59 GMT
From:      gnn@netcom.com (George Neville-Neil)
To:        comp.protocols.tcp-ip
Subject:   Network measuring programs up for FTP...


Hi Folks,

	Well, now that I have a new home I've moved the programs
I wrote to measure IP network performance (i.e. bandwidth, jitter)
to netcom.com:~ftp/pub/gnn/bwmeas-0.3.tar.Z .  There is a README
file and all the sources, Makefile, and man pages.  I'll hopefully be
adding applications to the suite soon.

Later,
George
-- 
gnn@netcom.com
#include <standard-disclaimer.txt>
Het was niet mij faut!

-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 20:03:56 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: etherfind/tcpdump not seeing outgoing packets ?

> I have found that etherfind (on sun4 sunos4.1.3) and tcpdump
> (on my linux box) both suffer from the same problem -- they
> cannot see packets originating on the system where the monitor
> program is running.  Because of this I always have to use
> a third machine to monitor traffic between two machines, and at
> some sites this is not available (i.e. 1 sun, many dos PCs).
>
> Am I doing something wrong?

No.  Under SunOS at least, the problem is Sun's NIT (Network Interface Tap).
I have no idea about Linux.

With BPF (Berkeley Packet Filter) and tcpdump you can see outgoing and
incoming packets.  The problem with SunOS 4.x is that you need the sources
to your interface drivers to replace the NIT code with BPF code.

	Rich Stevens

-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 20:08:23 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: etherfind/tcpdump not seeing outgoing packets ?

One more thing: under Solaris 2.x the DLPI stuff is better than NIT
in that Sun's snoop does see outgoing packets.  Now if I could just
find a copy of tcpdump that uses DLPI and get rid of snoop ...

	Rich Stevens

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 09:27:37 -0600
From:      sciog@MCS.COM (Robert Sciog)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Socket services


I am trying to learn who to access a TCP or UDP socket via an IBM machine on an ethernet network.

What type of commercial or shareware libraries are available to do this and where would I find them.

I have been monitoring here for about a month looking for FAQ information so ?I could look before asking. Is there a FAQ for this group ???


Bob S.

Sciog@mercury.mcs.com


-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 23:46:38 GMT
From:      john@gecko.mtc.ti.com (John Maline)
To:        comp.protocols.tcp-ip
Subject:   getsockname() blocks!?!

I've run into a problem under SCO's TCP stack that seems fairly odd to
me.  Can anyone please tell me who's crazy: me or SCO.

I've got a TCP application that looks like this:

	s = socket(...)
	for (...) {
		if (write(s,buf,buflen) != buflen) {
			/* error recovery */
			getsockname(s, ...)
		}
	}
		
If the remote end of the socket goes down ungracefully (eg, system
crash), this application continues to loop for a while, then blocks on
the write, then eventually falls out of the write with an error.  So
far, no problem.  I understand what's happening.

Then, as part of the error recovery, I do a getsockname() on the
socket.  This hangs forever (currently 9 hours and counting, let's
call it "forever").

I checked a few obvious things when something odd happens: streams
overflows, kernel data structure overflows, etc.  No problems.

I've started dealing with SCO on this and all I've gotten so far is an
explanation that "getsockname() is sleeping and will hang until
TCPV_KEEP_IDLE expires (120 minutes)".

Aside from their incorrect prediction of the application becoming
unblocked, this seems to avoid an obvious question: why would
getsockname() *ever* block?  Aren't we just returning some information
from the local TCP stack to the application?

In _UNIX Network Programming_, p. 321, Stevens lists the system calls
that FNDELAY sets non-blocking mode for (accept, connect and all the
variations of send, write, recv, read).  Those make sense since they
involve network traffic.  No mention is made of getsockname or
anything else like that.

Any enlightenment will be greatly appreciated.  Please mail to the
address below and I'll be glad to share with anyone interested.
--
John Maline
jmaline@lobby.ti.com    TI MSG: JWMX           214-995-6692
Texas Instruments       PO Box 655012 MS 351   Dallas, TX 75265


-----------[000509][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 23:49:44 GMT
From:      landin@cherokee.nsuok.edu (Mark Landin)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici

john.will@dscmail.com (John Will) writes:

>GR>: I always figured in his example that you'd have 4 subnets of 64 address
>GR>: each, and you'd have to reserve the subnet addresses of xx000000 & xx111111.
>GR>
>GR>That's how I originally thought, but I believe that Ken is saying
>GR>that we would lose all the addresses associated with subnet 0 and
>GR>subnet -1 (all 1's), since the subnet-number itself can not be 0
>GR>or -1.
 
>On closer examination, you're probably correct.  That's a bummer, makes
>subnetting kinda' useless in some cases...

Yes, this is correct. Using 'n' bits of an octet to specify a subnet,
you get 2^n - 2 possible subnets, each of which have 2^(8-n) - 2 possible
hosts. 

-- 
*-----------------------------------------------------------------------------*
*  Mark C. Landin					Northeastern St. Univ *
*  landin@cherokee.nsuok.edu					Tahlequah, OK *
*   "Living in the pools, they soon forget about the sea" - Neil Peart, RUSH  * 

-----------[000510][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 23:56:37 GMT
From:      john@gecko.mtc.ti.com (John Maline)
To:        comp.protocols.tcp-ip
Subject:   "simple" telnet (rlogin?) client implementation wanted

I've been given the task of implementing a telnet (or rlogin) client
on our embedded box (68k using the vxWorks OS).  VxWorks already has a
Berkeley-based TCP implementation so it's just telnet I need.  They
also have an rlogin client, but it doesn't meet our needs.

I've looked at the telnet client from the Berkeley Net 2 tape.  It
could probably be ported, but it looks like a big job.  Very
Unix-specific (as one might expect).  I haven't looked at rlogin yet,
but I fear it's as bad or worse (the two-process structure and so on).

If there were a "simpler" telnet or rlogin implementation, that might
make my life easer.  Maybe a DOS version?

If anyone has information on source for other good, free/cheap telnet
implementations, please sent mail to the address below.  Thanks.


--
John Maline
jmaline@lobby.ti.com    TI MSG: JWMX           214-995-6692
Texas Instruments       PO Box 655012 MS 351   Dallas, TX 75265


-----------[000511][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 00:15:34 GMT
From:      gnn@netcom.com (George Neville-Neil)
To:        comp.protocols.tcp-ip
Subject:   XV Ping 2.0 up for ftp...

Hi Folks,

	OK, I've now placed the version 2.0 of XVPing, a program that
maintains and watches a list of hosts, and their availability, through
the use of ICMP messages, in ftp.netcom.com:~ftp/pub/gnn/xv_ping-2.0.tar.Z


	The program requires X Windows and the XView toolkit to be built.

	A README, Makefile and man page are included that explain things 
more fully.

	Please direct all questions, comments and bugs to gnn@netcom.com

Later,
George

-- 
gnn@netcom.com
#include <standard-disclaimer.txt>
Het was niet mij faut!

-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 00:56:00 GMT
From:      dmag@engin.umich.edu (Daniel Demaggio )
To:        comp.protocols.tcp-ip
Subject:   Re: Rhetorical question for the group


> you're in the middle of nowhere. assume third-world technology
.
.
> you want to get on the internet. full IP connectivity required. 
> at a minimum, 56kb. preferably T1 or T3. 


  Hmm, maybe get on a plane back to civilization?  Or how about running
your own fiber? Sattellite downlink? (naw, that would suck) Several
phone lines in paralell w/a good distributing router and decent error
correcting modems?

I donno, why are you asking such a strange question?

> = Jeffery Bacon     General Systems Hack, Michigan Technological University =

 Oh, that explains it! ;)
-- 
dmag@umich.edu | When laws are outlawed,      | Ono-Sendai: the best
Dangerous  Dan | only outlaws will have laws. | Sim Stim decks

-----------[000513][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 01:34:51 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Network measuring programs up for FTP...

George Neville-Neil <gnn@netcom.com> wrote:
}	Well, now that I have a new home I've moved the programs
}I wrote to measure IP network performance (i.e. bandwidth, jitter)
}to netcom.com:~ftp/pub/gnn/bwmeas-0.3.tar.Z .  There is a README
}file and all the sources, Makefile, and man pages.  I'll hopefully be
}adding applications to the suite soon.

    Hmmm...

tigger.cc> ./tcp_speed -h pooh -b 1024 -c 1000 | tail
TCP Time to send 1024000 bytes: 976 milliseconds
TCP Time to send one 1024 byte chunk: 976.564000 microseconds
TCP Bandwidth Infinity bytes/second.
              ~~~~~~~~

   Cool!

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000514][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 01:59:15 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: etherfind/tcpdump not seeing outgoing packets ?

In article <1994Mar21.200356.7341@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>With BPF (Berkeley Packet Filter) and tcpdump you can see outgoing and
>incoming packets.  The problem with SunOS 4.x is that you need the sources
>to your interface drivers to replace the NIT code with BPF code.

With ULTRIX and its packet filter facility ("CMU/Stanford Packet Filter"),
and with OSF and either CSPF or BPF, tcpdump can see incoming and outgoing
packet after root does "pfconfig +p +c -a".  No source code required.

-Jeff

-----------[000515][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 02:22:03 GMT
From:      ltk@ss3.vlsi.ee.nus.sg (Teng-Kiat Lee)
To:        comp.protocols.tcp-ip
Subject:   protocol between Terminal server and unix


Hi,

I am curious what sort of protocol is working between a terminal server and
unix machines on a network. I am asking this because of the slow file transfer
rate I am getting with zmodem transfer to my home pc via modem. It begins to
look like there's some sort of limit placed on the speed of this transfer
from the unix machine to the TS.

Could someone enlighten me on this?

Thanks!!
Kiat
           ---------------    Teng-Kiat Lee   ----------------------
                           ltk@vlsi.ee.nus.sg  
                             t.lee@ieee.org      
           VLSI CAD & Design Lab                Voice: (65)-772-6319
           Dept. of Electrical Engineering             (65)-467-1518
           National University of Singapore     Fax:   (65)-777-3117
           ----------------------------------------------------------
           "We have reason to believe that man first walked upright to free his
           hands for masturbation."
           		-- Lily Tomlin

-----------[000516][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 09:13:26 GMT
From:      Alain Golan-Goldberg <alain@netmanage.co.il>
To:        comp.protocols.tcp-ip
Subject:   Re: nos? 1001 question ?!


In article <1994Mar15.070112.14089@datasrv.co.il> Roy Avidor,
roye@zeus.datasrv.co.il writes:
>We are using NOS software for connecting with slip .
>and we have some problems with the terminal type .
>i want to change it to VT102 but I can't find were I can change it.

You can use Kermit over the packet-driver, this would be the best vt102
emulation.

Bye,

-----------[000517][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 19:01:41 -0500
From:      kyle@crystal.WonderWorks.com (Kyle Jones)
To:        comp.protocols.tcp-ip,comp.mail.sendmail post-netnews@crystal.WonderWorks.com
Subject:   Re: [Q] Why not use sendmail under inetd?

Kari E. Hurtta writes:
 > [ Added comp.mail.sendmail as receiver. Please select correct group for
 >   your followup. ]
 > 
 > samson@chpi.edu.tw (Samson Chen) writes:
 > ;Dear netters,
 > ;	I have an old question.
 > ;	We have inetd as the super server for listening network. Why does
 > ;UNIX let sendmail listen network by itself.
 > 
 > 1) Nothing prevents starting sendmail from inetd with option -bs.
 > 
 >    However you must do also queue runs.

Also if you run sendmail in daemon mode you get the benefit of
load control, so that a surge of incoming mail won't cause
hundreds of sendmail's to be spawned and drive your system to its
knees.

For systems with light mail loads, running sendmail -bs out of
inetd works fine.


-----------[000518][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 12:30:17 GMT
From:      aledm@relay-europe.ps.net (Aled Morris)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] Why not use sendmail under inetd?

In article <1994Mar21.032240.1@spcvxb.spc.edu> terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:

>  You can change sendmail to run under inetd by changing your startup invo-
>cation of sendmail to remove the -bd option. For example, "sendmail -bd -q30m"
>becomes "sendmail -q30m". Then add sendmail to your inetd.conf file, sort of
>like this:
>
>smtp	stream	tcp	nowait	root	/usr/sbin/semdmail	sendmail -bs


If you're going to start sendmail from inetd, you might as well have
the queue processing started from cron using:

	0,30 * * * * /usr/sbin/sendmail -q

Then you don't need sendmail in rc or the process table at all.

Aled
--
aledm@relay-europe.ps.net  |  tel +44 81 476 2212
Perot Systems Europe Ltd.  |  fax +44 81 476 2419

-----------[000519][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 14:08:56 +0000
From:      alistair@ichthya.demon.co.uk (Alistair Bell)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <NELSON.94Mar20230018@crynwr.crynwr.com> nelson@crynwr.crynwr.com writes:

>In article <PMETZGER.94Mar19180706@andria.lehman.com>
> pmetzger@andria.lehman.com (Perry E. Metzger) writes:
>
>   In article <2m740m$f94@universe.digex.net> philp@universe.digex.net (Phil
> Perucci) writes:
>
>   >The cheapest full-time SLIP connection I have seen is about $200/month.
>
>   Netcom charges $160/month, I believe.
>
>TLG charges $70/month for V.32bis, $130/month for V.FAST, $325/month
>for 56Kbps, and $800/month for T1.  Only problem is, you have to know
>what you're doing, and you have to be in the San Francisco Bay Area.
>Ask <info@tlg.org> for more info.
>

Err... I can't quite believe I'm hearing this. In the UK, Demon Systems set up a
system a couple of years ago giving exactly what you are looking for - at less
than US$20 (yes, twenty) per month. How come nobody in the US has caught on to
doing the same?

Demon is immensely popular and has several thousand satisfied customers. Me, for
instance.

-- 
Alistair Bell,                     | Home address:
Brown's Operating System Services, | Alistair Bell,
St. Agnes House,                   | C.U.M.,
Cresswell Park,                    | 43 Old Jamaica Road,
Blackheath,                        | Bermondsey,
London                             | London
SE3 9RD.                           | SE16 4TE.
Tel. +44 81-852 3299.              | Tel. +44 71-237 6224.
Email: alistair@ichthya.demon.co.uk
I neither speak for Brown's, C.U.M., Demon, nor anyone else!

-----------[000520][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 94 14:25:08 GMT
From:      d0bpl@dtek.chalmers.se (Patrik Larsson)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   ARCNet and TCP/IP??

   We have some customers who have large lans using the old ARCNet
technology. Since they have invested so much money, they do not
want to buy new hardware (cards, cables).

   We want to connect RS/6000s and PCs to the lans. Is there
an easy way to do this? What we want is to use TCP/IP. Is it possible
to do that on ARCNet?

   Also any information or pointers to documentation about ARCNet is
appriciated.

   TIA!

      // Patrik

-----------[000521][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 14:52:55 GMT
From:      dant@minerva.rolm.com (Dan Tran)
To:        comp.protocols.tcp-ip
Subject:   Slip && FTP implementations


Hi I have  a technical question that I hope the netters can set 
some light for me.

The question is: 

                        Lan connection
        Station A <---------------------------> Station C

                         Slip Connection
        Station B <---------------------------> Station C


Station A and B are using the same operation systems (say Linux )


Do I need separate implementations of ftp  to transfer data between from
A to C, and B to C.  Due to different hardwares.


Thanks,



-----------[000522][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 15:58:45 GMT
From:      dabl2@lhc.nlm.nih.gov
To:        alt.internet.services,comp.sys.mac.comm,alt.bbs.internet,comp.protocols.tcp-ip
Subject:   Re: Internaut V1 N1 Now Available

In <abobaCn0x75.6n8@netcom.com>, aboba@netcom.com (Bernard Aboba) writes:
>Issue #1 of Internaut, an online magazine for users of the Internet, is 
>now available. 

Cool!  You may want to say something in your docs for people who use a lowly 
Dos/Windows system with 8.3 file naming conventions, ie I had to rename all 
*.html to *.htm to see them.  Also, don't you want comp.infosystems.www to 
know about you?  Is this stuff available 'live' on a web site yet?

--Don

Don A.B. Lindbergh II          | Why can't you make a living
                               | like the rest of the boys
dabl2@lhc.nlm.nih.gov          | Instead of filling your head
not a spokesperson for nlm     | with all that synthesized noise?  - Todd R.


-----------[000523][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 15:22:59 CET
From:      <ADEPAOLI@ESRIN.BITNET>
To:        comp.protocols.tcp-ip
Subject:   FP Batch ??

I would like to write a batch for TCP/IP (OS/2) to access the host (VAX).
In the IBM TCP/IP manual (under heading NETRC File) it mentions the
possibility of running in FTP batch. I have not been able to find anything
else on it. Has anyone out there ever written one, can you give me a few
tips, or where can I find documentation? Can anyone help ?
THANK YOU all very much in advance,

-----------[000524][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 18:22:40 GMT
From:      gutzs@crl.aecl.ca (Steven Gutz)
To:        comp.protocols.tcp-ip
Subject:   Need RFC for CSO phone book protocol

The subject says it all.

I need to know which RFC deals with CSO phone book protocol.

If you can help, please e-mail me with the the info.

----------------------------------------------------------------------------
| Steven Gutz             |  Internet:   gutzs@crl.aecl.ca                 |
| AECL Research Company   |  Compuserve: 73121,231                         |
| Chalk River Laboratories|-------------------------------------------------
| Chalk River, Ontario    | Author of the LA Times newsreader for OS/2 2.x |
| CANADA, K0J 1J0         |"Come with me if you want to live" - Terminator |
----------------------------------------------------------------------------



-----------[000525][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 18:31:20 GMT
From:      rjc@cc.gatech.edu (Russell J. Clark)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

>
 
>Err... I can't quite believe I'm hearing this. In the UK, Demon Systems set up a
>system a couple of years ago giving exactly what you are looking for - at less
>than US$20 (yes, twenty) per month. How come nobody in the US has caught on to
>doing the same?

Wow! Well around here, Southern Bell land, $20 would hardly pay for the phone
line at the service provider. At business rates, it wouldn't come close.

-- 
Russ Clark
College of Computing, Georgia Tech, Atlanta, GA 30332-0280
rjc@cc.gatech.edu

-----------[000526][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 18:50:30 GMT
From:      aledm@relay-europe.ps.net (Aled Morris)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <1994Mar22.183120.16093@cc.gatech.edu> rjc@cc.gatech.edu (Russell J. Clark) writes:

>Wow! Well around here, Southern Bell land, $20 would hardly pay for the phone
>line at the service provider. At business rates, it wouldn't come close.

BT charge GBP10.55/mo (= $15/mo) for a business line.  Remember,
though, that Demon operate a modem pool shared between their customer
base.  I believe their ratio is about 25:1 customers:modems.

Aled
--
aledm@relay-europe.ps.net  |  tel +44 81 476 2212
Perot Systems Europe Ltd.  |  fax +44 81 476 2419

-----------[000527][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 19:33:10 GMT
From:      tdrew@echonyc.com (Andrew Morone)
To:        comp.protocols.tcp-ip
Subject:   Is there a SLIP FAQ??

I'm trying to settup the Public Domain SLIP program intel-svr4-slip.tar.Z
I am having some trouble. Does anyone know where there is a step by step 
setup doc? The docs that come with it are pretty bare. I have been able to
make the program, and when I rebuild the kernel everything's OK. I'm not 
too clear where to go from there. I'm running Consensys 4.2.
Drew
tdrew@echonyc.com


-----------[000528][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 19:38:28 GMT
From:      gpe@rsvl.unisys.com (Glen Eiden)
To:        comp.protocols.tcp-ip
Subject:   Telnet source/program driveable telnet

I'm looking for information on any existing telnet programs that run on DOS
that can be fully driven by a program.  Some way to be able to pipe to the
program or drive it from a script would be perfect.  This must include the
userid/passwd as well as any commands once signed on.  Does anyone know of an
existing product that will do this?

Otherwise, if anyone has, or knows where I can get, some source code for a
telnet program, I would appreciate the information.

Thanks,  - GLEN

Please send any responses to:
gpe1@rsvl.unisys.com

-----------[000529][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 94 00:40:03
From:      vixie@vix.com (Paul A Vixie)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: [Q] Why not use sendmail under inetd?

> >    However you must do also queue runs.
 
>Also if you run sendmail in daemon mode you get the benefit of
>load control, so that a surge of incoming mail won't cause
>hundreds of sendmail's to be spawned and drive your system to its
>knees.

all true.

>For systems with light mail loads, running sendmail -bs out of
>inetd works fine.

it's faster for a sendmail listener to fork than for inetd to fork+exec,
generally speaking.  since a sendmail listener that isn't getting any new
connections is a prime candidate for having pages stolen for processes
that need them, there's really nothing to be gained from running out of
inetd.  inetd's generality wins in code simplicity, but sendmail has to
have the listener code in it for the various reasons stated above; inetd's
biggest boons come from "sub"-servers which are inetd's size or smaller.
--
Paul Vixie
Redwood City, CA    Also: <ftpmail-admin@pa.dec.com>,
decwrl!vixie!paul         <comp-sources-unix@uunet.uu.net>,
<paul@vix.com>            <{bind-workers,objectivism}-request@vix.com>

-----------[000530][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 19:45:19 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] How to determine TCP Max. Segment Size (MSS)?

In article <64019@sdcc12.ucsd.edu> jkay@cs.ucsd.edu (Jon Kay) writes:
>In article <2m8j0iINNr2t@excalibur.cs.purdue.edu> lin@cs.purdue.edu (John Chueng-Hsien Lin) writes:
>>  How does a TCP determine the maximum segment size (MSS) if the peer TCP is
>>attached on the same cable?
>>  Method 1) MSS = Interface_MTU - 40
>>  Method 2) MSS = (Interface_MTU - 40) / MCLBYTES * MCLBYTES
>>                  (i.e., Round down to nearest multiple of MCLBYTES)
>>		  Where MCLBYTES is an mbuf cluster size.
>>  Which method is better?
>
>Most TCPs use method 2, probably mostly for historical reasons
>involving data copying architecture of of 4.2 BSD.  To be sure, there
>is a penalty to allocating an extra mbuf, but it isn't nearly as great
>as the penalty for sending an extra packet.
>
>Method 1 is better.

"Better" in what sense?  To get more bits/sec over the wire?  If so, Method
1 is not always better than Method 2, and Method 2 is not always better
than Method 1.

For example, if your system can avoid the cache busting effects of byte
copies, and already avoids the cache effects of checksumming by doing the
TCP checksum in hardware, and if you system has a page size of 4096, then
using a MSS of 4096 on FDDI instead of 4352 is good for a major performance
improvement.  You get more bits/sec until you hit 100Mbit/sec, and then
you get more CPU cycles available for real work.

The same effects occur if your page size is 16K and you are using HIPPI.

If we're talking about media as slow as Ethernet or PPP, then no plausible
MSS involves many CPU cycles/sec, and the largest packet size possible,
or Method 1, is best.


Vernon Schryver    vjs@rhyolite.com

-----------[000531][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 19:55:53 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <764345336snz@ichthya.demon.co.uk> alistair@ichthya.demon.co.uk writes:
>>   Netcom charges $160/month, I believe.
>>
>>TLG charges $70/month for V.32bis, $130/month for V.FAST, $325/month
>>for 56Kbps, and $800/month for T1. ...
 
>  I can't quite believe I'm hearing this. In the UK, Demon Systems set up a
>system a couple of years ago giving exactly what you are looking for - at less
>than US$20 (yes, twenty) per month. How come nobody in the US has caught on to
>doing the same?
> ...

Netcom and others in the US offer SLIP or PPP accounts at from nothing to
$20/month and $1-$8/hour for connect time, sometimes with limits of
$250/month for the connect time.  The higher connect-time rates involve
800 numbers that can be dialed from anywhere in the U.S.  (At $0.10/minute,
long distance telephone charges cost the provider $6/hour.)

In the US, the flat-rate $100-$200/month SLIP or PPP accounts from the
big vendors involve dedicated telephone lines, modems and ports used only
by that single account.  In the US it would be impossible to do that for
$20/month, because the telephone line itself would cost 2 to 4 times that
much, leaving no money to pay for the modem, terminal server (or whatever),
and maintenance.

There is a big difference between 10 ports used by 1000 people and 10
ports used by 10 people.


Vernon Schryver    vjs@rhyolite.com

-----------[000532][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 20:03:19 GMT
From:      alhajery@cat.syr.edu (Eyas Al-hajery)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP code.



I am interested to get a code (any code) for the TCP/IP,  can anyone help
me locate it, if there is a copy on public domain in Internet, or from any
other source.
Thanks.

   E. Alhajery

-----------[000533][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 94 20:38:38 GMT
From:      djschoff@cibecue.az05.bull.com (Daniel J. Schoffelman)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1006


I have a broader question about RFC1006:  how prevalent is support for it
in the world today?  Is it part of standard OS releases, or an option?
How performant is it perceived to be?  Do implementations have problems
interoperating with each other?

-- 
Dan Schoffelman                         InterNet: D.Schoffelman@bull.com
Bull HN Information Systems             Voice:     +1 602 862 6246
13430 North Black Canyon Highway        FAX:       +1 602 862 4290
Phoenix, AZ 85029

-----------[000534][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 21:02:14 GMT
From:      cleelacj@agedwards.com (Chris Cleeland)
To:        comp.protocols.tcp-ip
Subject:   Strange connect() behavior...

[ Article crossposted from comp.sys.hp.hpux ]
[ Author was Chris Cleeland ]
[ Posted on Tue, 22 Mar 1994 01:56:53 GMT ]


First of all, I am working on an HP 9000/837 running HP-UX 9.0.  That
said, on to the problem...

I have a small test program which attempts to perform the typical "client"
side of a TCP connection --- the connect().  The socket is non-blocking.

The "normal" behavior is as follows:  I try to connect to a port on which
no one is listening.  The connect() fails and received a
"connection refused" error.  This is true when I connect to something
like port 9999 on host name "taft", where tafts IP is a standard IP
address (159.45.xxx.xxx).

Something very strange happens when, instead of connecting to port
9999 on host name "taft", I instead use host name "localhost", whose
IP address is the loopback --- 127.0.0.1.  In this case, the connect()
does not fail; instead it blocks indefinitely.

Is this supposed to happen, and I am simply an idiot?  Is 127.0.0.1
*that* special that it doesn't even behave the same as other IP addresses?
Please help me stay sane!

Thanks much...
-cj
-- 
==============================================================================
Chris Cleeland 	       	       	|  NeXTMail:  chris@milo.st-louis.mo.us
BOS Dev. Team                   |  MIMEMail:  cleeland@agedwards.com
                                |  BellNet:    (314) 289-5372
-- 
==============================================================================
Chris Cleeland 	       	       	|  NeXTMail:  chris@milo.st-louis.mo.us
BOS Dev. Team                   |  MIMEMail:  cleeland@agedwards.com
                                |  BellNet:    (314) 289-5372

-----------[000535][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 21:42:18 GMT
From:      gel102@gel.ulaval.ca (Jacques Tremblay)
To:        comp.protocols.tcp-ip
Subject:   bind

I have a problem when I try to restart a server that I have done. The bind
function returns the error "address already in use". It takes some time
for the port number to be freed by the system. After a while, it works and
my server runs perfectly. What can I do to force the port number to be
freed? Thanks a lot in advance. 


		Jacques Tremblay 
		

-----------[000536][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 20:09:00 +0100
From:      khweis@mvmpc9.ciw.uni-karlsruhe.de (Karl-Heinz Weiss)
To:        comp.protocols.tcp-ip.ibmpc,alt.winsock,comp.protocols.tcp-ip
Subject:   Re: Announcing an access-controlprogram for slipgates

> Announcement of SLIPLOG, an access-controlprogram for your slipgate
> -------------------------------------------------------------------
 [...]
> You may ftp it from:
> mvmpc9.ciw.uni-karlsruhe.de (129.13.118.9) /public/nos/sliplog.zip
> (ws_ftp-users should select 'ka9q' as servertype!)

As I could see in my logfile, some people have problems logging to my PC,   
because it's a ka9q/nos server not known by some GUI- ftp-clients. Those  
people should manually log to the server or use a gopher-client on port  
70!

-------------------------------------------------------------------
K.H. Weiss            E-mail  : <khweis@mvmpc9.ciw.uni-karlsruhe.de>
Eulenweg 2            Phone   : (49)-721608-2418  or  (49)-7244-1792
76356 Weingarten      Germany

-----------[000537][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 07:57:07 -0600
From:      sdorner@qualcomm.com (Steve Dorner)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: MacTCP window size problem?

In article <Cn3Ft5.3uq@gpu.utcc.utoronto.ca>, harald@enfm.utcc.utoronto.ca
(Harald Koch) wrote:

> However: MacTCP is only advertising a windowsize of 2920 bytes.

The window size is controlled by the application.  The bigger the buffer
the application gives to MacTCP when the connection is opened, the bigger
the window size.

-- 
Steve Dorner, Qualcomm Inc.
    "Don't give up hope.  Everyone is cured sooner or later.
     In the end we shall shoot you."  - George Orwell

-----------[000538][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 94 22:19:26 GMT
From:      tomm@Ingres.COM ()
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

pmetzger@andria.lehman.com (Perry E. Metzger) writes:
> 
> In article <2m740m$f94@universe.digex.net> philp@universe.digex.net (Phil Perucci) writes:
> 
> >The cheapest full-time SLIP connection I have seen is about $200/month.
> 
> Netcom charges $160/month, I believe.

I went with TLG (which another poster described) for a number of reasons.
A big one was price.  But another big concern of mine was getting a real
address space.  I talked to CERFnet a while ago and they told me 160/month
for ONE IP address.  This is a major pain since I have a LAN in my 
apartment and want to distribute things nicely around my net (I have news/mail
on one machine and run MOSAIC, etc on another).  One IP address implies lots
of hacking and ugliness if you have a LAN.

Why don't these vendors just let you apply for a class C from the NIC and
route packets for you.  Pretty obnoxious.

--tom


-----------[000539][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 22:20:24 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] How to determine TCP Max. Segment Size (MSS)?

Jon Kay (jkay@cs.ucsd.edu) wrote:
: Most TCPs use method 2, probably mostly for historical reasons
: involving data copying architecture of of 4.2 BSD.  To be sure, there
: is a penalty to allocating an extra mbuf, but it isn't nearly as great
: as the penalty for sending an extra packet.
: Method 1 is better.

Unless you're concerned about copy costs in bulk data transfer, in
which case, you'd probably round down to the nearest multiple of page
size.  

rick jones

-----------[000540][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 22:49:27 GMT
From:      mru@cc.univie.ac.at (Mark-Rene UCHIDA)
To:        comp.protocols.tcp-ip
Subject:   PPP connecting FTP PCTCP 2.3 and CISCO TS CS500


Has anybody managed to hookup a PC with FTP PCTCP 2.3 to a CISCO TS CS500
with PPP protocol?
If so, could you be so kind and mail or post the configuration files 
used, both for FTP PCTCP and CS500?
 
Somehow I have problems getting those two to talk to each other.
 
Thanks in advance,
Mark-Rene Uchida


-------------------------------------------------------------------------------
Mark-Rene Uchida                                      University of Vienna
Phone:   +43 1 408 74 88                              Universitaetsstr. 5/9
Fax:     +43 1 408 53 33 15                           A-1010 Vienna
E-Mail:  mark-rene.uchida@cc.univie.ac.at.            Austria
         m.uchida@ieee.org
-------------------------------------------------------------------------------



-----------[000541][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 23:26:31 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: need help on select() - when listening on 'S O C K E T S'

In article <Cn00M8.7sL@unccsun.uncc.edu> brtatach@uncc.edu writes:
>i would appreciate if someone could explain the idea of using select()
>while listening on multiple sockets through an example.

Have you tried reading a book like "Unix Network Programming" by W. Richard
Stevens?

>Primarily, i would like to know how does one go abt deciding when 2 use
>multiple sockets (design considerations)? where is the need for multiple
>sockets? what does one achieve by using Select()?

If a server needs to talk to multiple clients, you need to use multiple
sockets to do this.  A good example is an X server -- it has a connection
to each application that is displaying windows on it.  It uses select() to
wait for a command from any client.

The alternative to select() is a loop that checks each socket to see
whether there's anything waiting to be read.  This isn't as efficient as
simply waiting for any of them to indicate that they're ready to be read.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000542][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 23:43:18 GMT
From:      tomw@kalpana.com (Tom Walsh)
To:        comp.protocols.tcp-ip
Subject:   Re: READ ME URGENT

This is illegal you moron, so get bent and quit waisting our time!!
---
----------*----------*----------*---------*---------*---------*
Tom Walsh

"To Internet or not to Internet, That is the question"
#include <std.disclaim.h>
			( 408 ) 749-1600 ext 153
			( 408 ) 749-1690 ( FAX )
			internet: tomw@kalpana.com
				  tomw@netcom.com
---------*----------*----------*---------*---------*---------*



-----------[000543][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 23:59:06 GMT
From:      tomw@kalpana.com (Tom Walsh)
To:        comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)

In article 3ys@netcom.com, longyear@netcom.com (Alfred Longyear) writes:
> It seems to me that the address 127.x.x.x is not special. What is special
> is the loopback device.
> 
> When the "lo" device is brought up, it will register itself as IP address
> 127.0.0.1. You must still create the route to the loopback device as you would
> for any other device in your configuration.
> 
> If you don't have a route for 127.x.x.x to the "lo" device, but have a default
> route to an ethernet controller, for example, then requests to 127.0.0.1 will
> go out the wire just as requests to any other IP address. Until a route is
> created to the loopback device, the address 127.x.x.x is an unknown address
> just as if _I_ asked for address 192.83.17.1. It would need ARP to resolve it
> to a real ethernet address and subsequently the request would go out the
> default route.
> 
> So, it is not the "implementation of TCP/IP" which is broken, but the
> operator's setup of the TCP/IP configuration which is broken. There is nothing
> "magical" about the address 127.0.0.1 other than the convention that it is the
> loopback device and is normally _configured_to_route_ back to your own machine.
> 
> I guess what I am saying is that the routing of frames is not a function
> solely of the device's IP address, nor is it a function soley of the device
> type. There is no magical "override" which says that "Oh, you have address
> 127.0.0.1. I won't bother to look it up. I know that this is the loopback
> device and will simply put it there". It is a function of the routing tables
> within the system. If the routing tables do not include a route for the 127
> address, then it will use the default route or fail if there is no default
> route. If it must use the default route to some eithernet controller then it
> will need an ethernet address. This means that it will ask for the ARP
> translation of 127.0.0.1.

Check the assigned numbers RFC 1340

on page 4

(g)	{127, <any>}
	Internal host loopback address. Should never appear outside a host.


This pretty much means what it says :)






---
----------*----------*----------*---------*---------*---------*
Tom Walsh

"To Internet or not to Internet, That is the question"
#include <std.disclaim.h>
			( 408 ) 749-1600 ext 153
			( 408 ) 749-1690 ( FAX )
			internet: tomw@kalpana.com
				  tomw@netcom.com
---------*----------*----------*---------*---------*---------*



-----------[000544][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 94 00:46:05 GMT
From:      heye@asavax.asa.org
To:        comp.protocols.tcp-ip
Subject:   NCSA with BOOTP over routers

Can anyone help? We are trying to impliment NCSA Telnet with a bootp server
running from our Vax over multiple routers. We are able to run bootp using LWP
over the routers, but when we run NCSA the machine hangs on reading the
configuration file. We are running the latest NCSA 1.8 I believe and the latest
ODIPKT driver. Here is a copy of my CONFIG.TEL file:
termtype ="vt100"
myip=BOOTP
netmask=255.255.255.0
hardware=packet
interupt=0
ioaddr=0
tek=yes
video=ega
bios=no
ftp=yes
rcp=yes
capfile="telcap"
keyfile="keymap.tel"
domain="asa.org"
domainretry=4
arptime=120
beep=yes
concolor=020170
broadcast=255.255.255.0
windowgoaway=yes
autoscroll=no
services="services.tel"
host=asavax.asa.org
hostip=192.150.224.50
scrollback=400
erase=backspace
vtwrap=yes
crmap=4.3BSDCRNUL
contime=60
retrans=12
mtu=512
maxseg=512
rwin=512
name=cisco; hostip=192.150.224.10 gateway=1
name=asavax; hostip=192.1150.224.50 nameserver=1

If anyone could shed some light on this it would be greatly appreciated. 

Also I was able to get NCSA working using RARP over the one router but since
that's non-routable it's not an option for us.

Thanks,

Steve Heye
Computer Field Engineer
Antarctic Support Associates


-----------[000545][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 01:04:12 GMT
From:      tomw@kalpana.com (Tom Walsh)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] How to determine TCP Max. Segment Size

In article 2m8j0iINNr2t@excalibur.cs.purdue.edu, lin@cs.purdue.edu (John Chueng-Hsien Lin) writes:
> 
>   How does a TCP determine the maximum segment size (MSS) if the peer TCP is
> attached on the same cable?
> 
>   Method 1) MSS = Interface_MTU - 40
> 
>             Ex. For Ethernet with MTU = 1500 octets, MSS is 1460 (1500 - 40).
> 
>   Method 2) MSS = (Interface_MTU - 40) / MCLBYTES * MCLBYTES
>                   (i.e., Round down to nearest multiple of MCLBYTES)
> 		  Where MCLBYTES is an mbuf cluster size.
> 
>             Ex. Assume MCLBYTES = 1024
>                 For Ethernet with MTU = 1500 octets, MSS will be 1024.
> 		(i.e., 1460 round down to nearest multiple of 1024)
> 
>   Which method is better?
> 
> 
> Thanks,
> John Lin (lin@cs.purdue.edu)

method 2)

When using the MCLBYTES methods you are typically optimizing the packet size 
to the page size of the system ( ideally you may avoid any type of memory copy or  memory fragmentation issues, this may make a slow implementation move along fast 
or a fast one move even faster ). This apraoch is generally useful in a full 
featured #NIX kernel.

method 1)
When not using the MCLBYTES method you are generally optimizing the packet size 
for the media in use ( if the MTU is set optimally ). If you have a fast implementation
to start with  ( no memcopies, no matter what ) this approach may work well.
You may be able to take better advantage of this approach in an embedded system
where you don't have to fight a full featured #NIX kernel.



If you are using ethernet under any decent TCP stack you should get good mileage
from either approach ( unless you are using a 386 w/ some old SYS V code
or some other name-less major risc supplier of #NIX workstations who can't do
line speed yet )

---
----------*----------*----------*---------*---------*---------*
Tom Walsh

"To Internet or not to Internet, That is the question"
#include <std.disclaim.h>
			( 408 ) 749-1600 ext 153
			( 408 ) 749-1690 ( FAX )
			internet: tomw@kalpana.com
				  tomw@netcom.com
---------*----------*----------*---------*---------*---------*



-----------[000546][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 01:22:17 GMT
From:      harald@enfm.utcc.utoronto.ca (Harald Koch)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   MacTCP window size problem?

I've been connecting my Mac to the Unix systems at work using a dialup PPP
connection. I have a Rockwell NetHopper connected to my Macintosh via
Ethernet, so I'm not using MacPPP or similar programs; I'm talking TCP
directly out the Ethernet port.

However: MacTCP is only advertising a windowsize of 2920 bytes.  The MSS on
my Mac is set to 1460, so this is only two segments (which is supposed to
translate to two IP packets using an MTU of 1500, the MTU of the modem link).

This is *exceedingly* inefficient when operating over long-haul links, since
effectively no windowing is being done.

My question is: How do I convince MacTCP to use a larger window size? MacTCP
Watcher claims that the maximum window size is 64K, but MacTCP never uses it.

Pertinent data: Mac Quadra 804A/V, System 7.1, MacTCP 2.0.4, using the
Quadra's built-in Ethernet.

I'll monitor the newsgroup, but I prefer email responses, and I will
summarize to the net if requested.

Thanks in advance,
-- 
C. Harald Koch, Network Analyst | The best thing about deadlines is the
University of Toronto           | whooshing sound they make as they go past.
External Networking Fac. Mgmt.  |                             -Douglas Adams
chk@utcc.utoronto.ca            |

-----------[000547][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 16:22:53 -0800
From:      aha@kaiwan.com (Antony Halim)
To:        comp.protocols.tcp-ip
Subject:   Need help: doing 'write' on hungup socket


When you try to 'write' on a socket that has been hungup, then
normally you'll get SIGPIPE, and write will return with 0 and errno
is set to EPIPE.

But what I get when 'write'ing to a hangup socket is that
write returns successfully (with value equal to the bufferlen, which is
the third argument). I do not get SIGPIPE. A second call to write will
generate SIGPIPE.
The program is compiled using socket in solaris 2.2

If anyone knows what's going wrong here, please drop me a line.
Your help is greatly appreciated!

/aha



-----------[000548][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 03:09:10 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: need help on select() - when listening on 'S O C K E T S'

Barry Margolin <barmar@think.com> wrote:
}If a server needs to talk to multiple clients, you need to use multiple
}sockets to do this.

  This is true for TCP.  It is not true for UDP.  A UDP server *can*
  use a single socket to talk to multiple clients.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000549][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 11:59:36 -0500
From:      mikeb@village.com (Mike)
To:        comp.protocols.tcp-ip
Subject:   SLIPS


Try as I might I could not find a newsgroup dedicated to SLIP/PPP and so
and so forth.  Instead of annoying the posters here, I thought i'd ask
if anyone knows of any newsgroups dedicated to that?  If not, I just might
propose one.  Thanks in advance

-- mike

-- 
 
comrade@gnu.ai.mit.edu| Cyberspace is not ASCII, its concensual hallucination.
jfarnon on IRC........| "guh.  ugh. blag.  whee.  wheee."  -- confusion 
The opinions above are mine, and not of my company.

-----------[000550][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 08:46:19
From:      ismo@DF.elma.fi (Ismo Bergroth)
To:        comp.protocols.tcp-ip
Subject:   Printing problem WfW & FTP PC/TCP

I am having some trouble implementing printing services using
Windows for Workgroups 3.11 and FTP Software's PC/TCP version
2.2.
I want to be able to print over the network using WfW services so I
have a PC that has a printer connected to it. Other PC's in the network 
may print to it using WfW's peer-to-peer services. This works fine as
long as the PC requesting printing uses only WfW (the print server
has both WfW & PC/TCP). If I add TCP/IP as the second network
protocol,  prints are written over the screen on the sending machine.
Does't seem to be a printer driver problem as I have tried several
different printers and all exhibit the same problem.
It looks like PCTCPNET.DRV (or some other FTP component)
intercepts my print requests, which I do not want it to do, as all
printing should be handled by WIndows.

Any suggestions?

-------------------
Ismo Bergroth
Data Fellows Ltd.

-----------[000551][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 94 04:42:24 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <764345336snz@ichthya.demon.co.uk> alistair@ichthya.demon.co.uk writes:
>In article <NELSON.94Mar20230018@crynwr.crynwr.com> nelson@crynwr.crynwr.com writes:
>
>>In article <PMETZGER.94Mar19180706@andria.lehman.com>
>> pmetzger@andria.lehman.com (Perry E. Metzger) writes:
>>
>>   In article <2m740m$f94@universe.digex.net> philp@universe.digex.net (Phil
>> Perucci) writes:
>>
>>   >The cheapest full-time SLIP connection I have seen is about $200/month.
>>
>>   Netcom charges $160/month, I believe.
>>
>>TLG charges $70/month for V.32bis, $130/month for V.FAST, $325/month
>>for 56Kbps, and $800/month for T1.  Only problem is, you have to know
>>what you're doing, and you have to be in the San Francisco Bay Area.
>>Ask <info@tlg.org> for more info.
>>
>
>Err... I can't quite believe I'm hearing this. In the UK, Demon Systems set up a
>system a couple of years ago giving exactly what you are looking for - at less
>than US$20 (yes, twenty) per month. How come nobody in the US has caught on to
>doing the same?
>
>Demon is immensely popular and has several thousand satisfied customers. Me, for
>instance.
>

Are you sure you didn't drop a digit in converting from U.K. pounds to
U.S. dollars?! :) That is a GREAT deal (even on its own merits, but
especially in comparison to the providers I've heard of here in the
US) Heck, me having SLIP for even $40 a month at 9600 would make me
happy. Here in Nevada, there doesn't even appear to be any providers
at all. Excluding national companies like PSI, which charge $175/month
for 9600. What do they think I am, totally insane? I wish I had stock
in PSI, I'd be rich!

>-- 
>Alistair Bell,                     | Home address:
>Brown's Operating System Services, | Alistair Bell,
>St. Agnes House,                   | C.U.M.,
>Cresswell Park,                    | 43 Old Jamaica Road,
>Blackheath,                        | Bermondsey,
>London                             | London
>SE3 9RD.                           | SE16 4TE.
>Tel. +44 81-852 3299.              | Tel. +44 71-237 6224.
>Email: alistair@ichthya.demon.co.uk
>I neither speak for Brown's, C.U.M., Demon, nor anyone else!



-----------[000552][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 05:24:15 GMT
From:      annadata@nada.ics.Hawaii.Edu (Anil Annadata)
To:        comp.protocols.tcp-ip
Subject:   FAQ for tcp-ip



	I would like to have the FAQ fro tcp-ip. Can anyone of you
suggest me where I can download it from.



Thanks

Anil

-----------[000553][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 15:07:32 -0500
From:      rls@zeus.id.net (Robert Shady)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

rjc@cc.gatech.edu (Russell J. Clark) writes:

>>I can't quite believe I'm hearing this. In the UK, Demon Systems set up a
>>system a couple of years ago giving exactly what you are looking for - at less
>>than US$20 (yes, twenty) per month. How come nobody in the US has caught on to
>>doing the same?
 
>Wow! Well around here, Southern Bell land, $20 would hardly pay for the phone
>line at the service provider. At business rates, it wouldn't come close.

I missed the first part of this message, but we offer dialup accounts here
for $18/Month.  Local to all of 313/810 area code.

-- 
        Internet Service Provider / Hardware Sales / Consulting Services
      Innovative Data Services,   Farmington Hills,  Michigan.  48335-4382
                     Voice: (810)478-3554 / Fax: (810)478-2950

-----------[000554][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 17:14:33 -0600
From:      mjenkins@ncts.navy.mil (Mike Jenkins)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Solaris 2.2 defaults to "do not fragment"?

I noticed recently when telneting to a Solaris 2.2 host
that things worked for a bit and then the connection
would hang and timeout.  I traced it to the IP packets
coming from the Sun having the "do not fragment" flag
turned on.  This stopped the packets from reaching me
because an MTU along the way was too small for the packet
and the router dropped the packet.  Is this the default?
How do I change it?

  --- from snoop ---
  IP:   Flags = 0x4
  IP:         .1.. .... = do not fragment
  IP:         ..0. .... = last fragment

--
Mike Jenkins

(I must say NetBSD is looking better every day :-)






-----------[000555][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 12:47:52 EST
From:      Alan Claver <ALC@psuvm.psu.edu>
To:        comp.protocols.tcp-ip
Subject:   PING for DOS

I'm looking for a DOS PING that will set an ERRORLEVEL based on success
or failure in connecting to a specific host. We're writing a batch file
that will tell our users if particular hosts are alive. Thanks.

  /^/|^|    Alan Claver, Microcomputer Info Specialist                 |^|\^\
 / / | ||^| Penn State University Libraries                         |^|| | \ \
/_/  |_||_| E6 Pattee Library, University Park, PA 16802            |_||_|  \_\
     MA BELL:(814) 865-7213--INTERNET:ALC@PSULIAS.PSU.EDU
   "Practice random kindness ...  and senseless acts of beauty"

-----------[000556][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 08:12:39 GMT
From:      albertk@cs.kun.nl (Albert Koppes)
To:        comp.protocols.tcp-ip
Subject:   TCP socketopt for maximum segment lifetime over satellite

At the moment we are configuring TCP/IP services for
VMS 6.0 on Vaxstations 9000. Here clients are running that connect
to another system under VxWorks where the server is
running. The server listen socket can only serve one connection.

The TCP session is over satellite (roundtrip 0.5 sec) and
will run speeds up to 200 kbit/sec. 

Our problem is the configuration of socketoptions at
both sides especially related to the following:

- The client shall be able to reconnect very fast on
the same port number. For this we will need to adapt
the Maximum Segment Lifetime (Comer, part I,  section 12.25).
On the other hand we do not want to have a timeout too soon
if segments need to be resent.How do you configure this ???



Is there anyone having experience in this configuration, or
having experience with these kind of socketoptions at
VxWorks or VAX TCP/IP products ?


Thanks in advance,


Frank Zeppenfeldt
EUMETSAT
albertk@zeus.cs.kun.nl


-----------[000557][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 18:54:44 -0600
From:      sdorner@qualcomm.com (Steve Dorner)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: MacTCP window size problem?

In article <2mpsjt$q03@lastactionhero.rs.itd.umich.edu>, ljb@merit.edu
(Larry J. Blunk) wrote:

>    MacPPP clips the TCP window size down to 2920 (its not MacTCP's fault).
>...
> low-speed link.  Watch what happens when you offer a 24K window to
> SunOS.  It will blast out 24K before receiving an ack (since it
> doesn't do slow-start).

Why should all PPP users suffer because Sun never has done (and perhaps
never will do) networking properly?

Is this clipping adjustable?

-- 
Steve Dorner, Qualcomm Inc.
    "Don't give up hope.  Everyone is cured sooner or later.
     In the end we shall shoot you."  - George Orwell

-----------[000558][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 19:47:39 -0600
From:      victor@mickey.cc.utexas.edu (V Menayang)
To:        comp.protocols.tcp-ip
Subject:   NTP client?


This is a novice question so please excuse me if
it's not posted to the proper group.

I'd like to set the clock on my machine to an NTP
server on campus.  What program do I need to do this?
My machine is running a flavor of BSD unix.  I looked
at xntp, but it seems like an overkill.  I only
need a simple client that I could invoke at the command
line or through crontab.

Thanks for any advice.


-victor

-----------[000559][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 10:14:19 GMT
From:      wat@ewi.ch (Wacker Thomas)
To:        comp.protocols.tcp-ip
Subject:   Info about Applications in Packets

Higher Layer Information?

I am wondering which information about Layers 5-7 are present in packets
travelling on a routed network. In IP I think I see pretty clear:

Layer	Item			Info
3	Src/Dest Adress:	identifies the hosts 
	Protocol:		identifies the proto in IP (TCP, UDP, ..)
4 TCP	Src/Dest Port:		identifies the processes on the hosts
4 UDP	Src/Dest Port:		identifies the processes on the hosts

Ports are allocated dynamically so I do not know which applications
listen to the data being exchanged through a socket (pair of IP
addresses and ports). I would have to analyse the port lists (or
whatever they are called) on the corresponding hosts or the data
portion of the packets being exchanged.

Right?

Can anyone tell me about other protocols:

- DECnet Phase IV (has network objects, similar to the port concept in
    TCP/IP)
- Apple Talk
- Novell IPX

Any help or pointers warmly appreciated

				Thomas

--
----------------------------------------------------------------------------
___         .   Thomas Wacker                  |Phone       ++41 1 385 31 57
__   / / /  |   Internetworking Consultant     |Fax         ++41 1 385 24 25
___   / /   |   wat@ewi.ch     /g=Thomas/s=Wacker/o=EWI/p=EUNET/a=ARCOM/c=CH
   E l e k t r o w a t t  E n g i n e e r i n g  S e r v i c e s  L t d .

-----------[000560][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 10:22:44 GMT
From:      simms@sparc58.cs.uiuc.edu (dan simms)
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA with BOOTP over routers

In <1994Mar23.004605.45@asavax.asa.org> heye@asavax.asa.org writes:

>Can anyone help? We are trying to impliment NCSA Telnet with a bootp server
>running from our Vax over multiple routers. We are able to run bootp using LWP
>over the routers, but when we run NCSA the machine hangs on reading the
>configuration file. We are running the latest NCSA 1.8 I believe and the late
>ODIPKT driver. Here is a copy of my CONFIG.TEL file:

perhaps it is because 1.8 is not anywhere near the latest version (I think
2.3.07 is). I'm reasonably sure that BOOTP is included since 2.3.05...
have fun,


dan



-- 

Daniel Simms  "When I was three, I wanted to be a cook. At the age of six I
artie@uiuc.edu wanted to be Napoleon.  Since then my ambition has increased 
ph: 328-7060   all the time"  -Salvador Dali

-----------[000561][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 11:35:58 GMT
From:      dbruyne@reks.uia.ac.be (Karel.DeBruyne)
To:        alt.internet.services,comp.sys.mac.comm,alt.bbs.internet,comp.protocols.tcp-ip
Subject:   Re: Internaut V1 N1 Now Available

dabl2@lhc.nlm.nih.gov wrote:
: In <abobaCn0x75.6n8@netcom.com>, aboba@netcom.com (Bernard Aboba) writes:
: >Issue #1 of Internaut, an online magazine for users of the Internet, is 
: >now available. 
: 
: Cool!  You may want to say something in your docs for people who use a lowly 
: Dos/Windows system with 8.3 file naming conventions, ie I had to rename all 
: *.html to *.htm to see them.  Also, don't you want comp.infosystems.www to 
: know about you?  Is this stuff available 'live' on a web site yet?

Yes, I put this "stuff" in our Web-server yesterday.
http://reks.uia.ac.be/internaut/index.html

Greetings,

Karel
=========================================================================
Karel De Bruyne 				phone 	+ 32 3 820 22 04
UIA - Computer Center				fax   	+ 32 3 820 22 49
	  					email	dbruyne@uia.ac.be
=========================================================================
-- 
=========================================================================
Karel De Bruyne 				phone 	+ 32 3 820 22 04
UIA - Computer Center				fax   	+ 32 3 820 22 49
	  					email	dbruyne@uia.ac.be

-----------[000562][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 94 20:38:08 -0500
From:      harvey@indyvax.iupui.edu (James Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: SUBNETTING CLASS C IP ON WAN

In article <2mqb51$683@auggie.CCIT.Arizona.EDU>, leonard@telcom.arizona.edu (Aaron Leonard) writes:
>
> In article <764449567snz@peeras.demon.co.uk>, proyse@peeras.demon.co.uk
> (Phil Royse) writes:
>
> |There is some controversy over the use of a mask of:
> |
> |255.255.255.192   in that some people say that only gives you
> |two subnets of 62 hosts, instead of four, because the first two bits
> |of the last octet ought not to be 00 or 11.  I don't believe this,
> |but I'm nervous about recommending it in case they are right (and I
> |have no means of veryfying it).
>
> My feeling is that you needn't forgo the use of the all-zeros
> and all-ones subnets.  The problem with using these subnets is
> that you run into an ambiguity problem:
>
> - if something advertises a route to <net><subnet0><0>, then is
>   that an advertisement for the net as a whole, or for only
>   <subnet0>?  This problem can be finessed by using a mask-aware
>   routing protocol such as OSPF, or by judicious use of static routing.
>   Proxy ARP may be helpful in servicing endnodes that would otherwise
>   be confused.
>
> - if something sends a directed broadcast to
>   <net><subnet-all-1's><all-1's>, is that a directed broadcast
>   to all subnets of <net>, or only to <subnet-all-1's>?  In my
>   view, there is ordinarily no need for directed broadcasts at
>   all, and everyone should simply use the <all-1's> limited
>   broadcast, in which case this ambiguity is irrelevant.  (Some
>   people assert that some applications use directed broadcasts,
>   but I haven't seen any such applications.)

Directed network broadcasts can be useful for just about any UDP-based
inquiry/response protocol, e.g., bootp, time, named.  Cisco routers can
be setup to forward directed network broadcasts to a particular "helper"
address (or addresses?).  I imagine that other routers have similar features,
although my only experience is with Ciscos.  We are using this feature
for bootp in the new University Library here at IUPUI.  Ciscos can also
be setup to flood directed network broadcasts throughout an internetwork
in a controlled manner using a spanning-tree algorithm, but I've never
used that feature.

> Now, my site has a couple of class B networks to play around with,
> and we have the luxury of not using the all-zeros or all-ones
> subnets.  (If a network has 1024 subnets, then it's no great
> tragedy to waste two of them.)  But, what with ever increasing
> address space scarcity, many sites that once would have gotten
> class B's now need to live within the confines of a class C.  And
> I would submit that forcing people to throw away half of their
> address space in order to maintain semantic purity will prove
> to be increasingly less tolerable.

"Semantic purity" actually has little to do with it.  With some routers
and configurations it can be made to work (as I'm sure you are quite aware,
being the experienced network manager that you are).  However, RFC1122
doesn't *require* it to work, and IMHO it's easier to tell people who have
little experience getting anything to work who try it and find out that it
doesn't work for them that it just "doesn't work", and "no, it's not a bug,
it's a feature."

I agree that it will become increasingly less tolerable as time goes on,
but I for one will not recommend it to anyone unless I know enough about
their hardware/software and configuration to know that it can be made to
work in their particular case.
--
James Harvey   harvey@iupui.edu   IUPUI OIT Technical Support/VMS/Unix/Networks
Disclaimer:  These are my own opinions.  I do not speak for Indiana University.


-----------[000563][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 14:11:16 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: MacTCP window size problem?

In article <Cn3Ft5.3uq@gpu.utcc.utoronto.ca> harald@enfm.utcc.utoronto.ca (Harald Koch) writes:

>However: MacTCP is only advertising a windowsize of 2920 bytes.  The MSS on
>my Mac is set to 1460, so this is only two segments (which is supposed to
>translate to two IP packets using an MTU of 1500, the MTU of the modem link).
>
>This is *exceedingly* inefficient when operating over long-haul links, since
>effectively no windowing is being done.
>
>My question is: How do I convince MacTCP to use a larger window size? MacTCP
>Watcher claims that the maximum window size is 64K, but MacTCP never uses it.
>
>Pertinent data: Mac Quadra 804A/V, System 7.1, MacTCP 2.0.4, using the
>Quadra's built-in Ethernet.

MacTCP has historically had problems in its TCP Windowing code.  I had
thought those were fixed beginning with MacTCP version 2.0.4.  In
fact, I had thought that was the main advantage of using 2.0.4 rather
than some earlier version.  Given the history, I suspect that MacTCP
still doesn't have the windowing quite right.  It would be useful if
the MacTCP developers could look into this and then comment back to
the net. :-)

Ran
atkinson@itd.nrl.navy.mil



-----------[000564][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 14:29:58 GMT
From:      cmunoz@decmsu.sonda.cl (Carlos Munoz I.)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Wollongong Group Address

Hi.
Please, I need the Wollongong Group internet e-mail address. We have Pathway Runtime (TCP/IP)
that they do for DEC-VMS systems.
We have some problems and questions about the Pathway.

Please, send me mail to  cmunoz@decmsu.sonda.cl

Thanks in advance
			Carlos Munoz Ibacache.
			Support Engineer
			SONDA - SOFTWARE
			Chile.

-----------[000565][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 15:56:37 GMT
From:      nelson@crynwr.crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Re: ARCNet and TCP/IP??

In article <d0bpl.764346308@dtek.chalmers.se> d0bpl@dtek.chalmers.se (Patrik Larsson) writes:

      We have some customers who have large lans using the old ARCNet
   technology. Since they have invested so much money, they do not
   want to buy new hardware (cards, cables).

      We want to connect RS/6000s and PCs to the lans. Is there
   an easy way to do this? What we want is to use TCP/IP. Is it possible
   to do that on ARCNet?

Sure.  Use ARCETHER.  It's a packet driver that emulates Ethernet
while using an ARCNET adapter.  You'll have to be able to route the
packets to the RS/6000 at some point, either in a NetWare server or a
dedicated PC running PC-Route or KA9Q.


-- HOWTOGET.IT

		The Crynwr packet driver collection

Availability

The Crynwr packet driver collection is available on CD-ROM, by mail,
by FTP, by email, by UUCP and by modem.  The drivers are distributed
in three files: pktd11.zip, which contains most executables and
documentation, pktd11a.zip, which contains the first half of the
remaining files, and pktd11b.zip, which contains the second half of
the remaining files.

Mail:

Columbia University distributes packet drivers on PC diskette by
postal mail.  5.25-inch 360K and 3.5" 720K diskettes are available;
please specify size.  Two diskette sets are available, and two prices
are quoted for each; the first price is for the USA, Canada, and
Mexico; the second price is for shipment to all other countries.  All
prices are in US dollars.  Prepayment by check, MasterCard, or Visa
is accepted.  If your check is not drawn on a US bank, please add $35
check-cashing fee.

  1. Binaries and documentation:        $35  /  $40
  2. Source code:                       $60  /  $68

To order by credit card, please specify MasterCard or Visa, your card
number and expiration date, and sign and date your order.  For further
information, call +1 212 854-3703, or write to:

  Kermit Distribution, Dept PD
  Columbia University Academic Information Systems
  612 West 115th Street
  New York, NY  10025

or send e-mail to kermit@columbia.edu (Internet) or KERMIT@CUVMA
(BITNET/CREN/EARN).

FTP/email:

The packet driver collection has its own directory devoted to it in
the SimTel collection, msdos/pktdrvr.  The drivers are there, along
with a number of programs that use the packet drivers.

For security reasons the SimTel Software Repository is located on a
host that is not accessible by Internet users, however its files are
available by anonymous ftp from the primary mirror site OAK.Oakland.Edu
(141.210.10.117) located in Rochester, Michigan, and from the secondary
mirror sites:

   St. Louis, MO: wuarchive.wustl.edu (128.252.135.4)
   Corvallis, OR: archive.orst.edu (128.193.2.13)
Falls Church, VA: ftp.uu.net (192.48.96.9
       Australia: archie.au (139.130.4.6)
         England: src.doc.ic.ac.uk (146.169.2.1)
         Finland: ftp.funet.fi (128.214.6.100)
         Germany: ftp.uni-paderborn.de (131.234.2.32)
          Israel: ftp.technion.ac.il (132.68.1.10)
     Switzerland: ftp.switch.ch (130.59.1.40)
          Taiwan: NCTUCCCA.edu.tw (140.111.1.10)

SimTel files may obtained by e-mail from various ftp-mail servers
or through the BITNET/EARN file servers.  For details see file
/pub/msdos/filedocs/mailserv.inf.  Gopher users can access the
collection through Gopher.Oakland.Edu.  World Wide Web (WWW) and
Mosaic users can connect to the URL http://www.acs.oakland.edu to
access the files on OAK.Oakland.Edu.

Modem:

If you cannot access them via FTP or e-mail, most SimTel MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956.  DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP).  This is a subscription system
with an average hourly cost of 17 cents.  It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial.  New files
uploaded to SimTel are usually available on DDC within 2New files
uploaded to SimTel are usually available on DDC within 24 hours.

CD-ROM:

Title:  Packet Driver, WinSock & TCP/IP CD-ROM (aka Packet Driver CD)
Price:  US$29.95/each

Brochures and order forms for the CD (paper and electronic versions)
will be available from:

Gopher: gopher.CDPublishing.com
FTP:    ftp.CDPublishing.com
E-mail: <info@CDPublishing.com>
FAX:    604-874-1431
Phone:  604-874-1430
        800-333-7565
Postal: CD Publishing Corporation
        4824 Fraser Street
        Vancouver, B.C.  V5V 4H4
        Canada

UUCP:

The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr.  Contact UUNET for more details:

UUNET Technologies, Inc.
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 204 8000 (voice)
+1 703 204 8001 (fax)
info@uunet.uu.net

UK UUCP:

Steve Kennedy's BBS is on +44 71 483 2454 (Telebit T2500 PEP/V32 ...)
                                                2455 (USR HST/DS+)

Files will be in /pub
there will be an anonymous uucp (nuucp) account.

System name is "jedinet"

-- end of HOWTOGET.IT

--
-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000566][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 16:08:13 GMT
From:      les@chinet.chinet.com (Leslie Mikesell)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet source/program driveable telnet

In article <Cn2zw5.KFn@rsvl.unisys.com>,
Glen Eiden <gpe@rsvl.unisys.com> wrote:
>I'm looking for information on any existing telnet programs that run on DOS
>that can be fully driven by a program.  Some way to be able to pipe to the
>program or drive it from a script would be perfect.  This must include the
>userid/passwd as well as any commands once signed on.  Does anyone know of an
>existing product that will do this?

MSDOS Kermit versions 3.10 and up allow telnet connections and can be
driven by a script.  The current version is 3.13.

Les Mikesell
  les@chinet.com

-----------[000567][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 17:00:45 GMT
From:      ljb@merit.edu (Larry J. Blunk)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: MacTCP window size problem?

|> 
|> >However: MacTCP is only advertising a windowsize of 2920 bytes.  The MSS on
|> >my Mac is set to 1460, so this is only two segments (which is supposed to
|> >translate to two IP packets using an MTU of 1500, the MTU of the modem link).
   MacPPP clips the TCP window size down to 2920 (its not MacTCP's fault).
I've played around with this alot and in most cases its is very helpful
as it avoids execessive re-transmissions which are very costly on a
low-speed link.  Watch what happens when you offer a 24K window to
SunOS.  It will blast out 24K before receiving an ack (since it
doesn't do slow-start).   You terminal server will either queue these (if
it has enough buffer space) or just drop them on the floor.   In either
case, you'll probably end up seeing re-transmissions. 

|> >
|> >This is *exceedingly* inefficient when operating over long-haul links, since
|> >effectively no windowing is being done.

   It is not exceedingly inefficient.   Remember, you're on a low-speed
link here, not an Ethernet.  With a 14.4Kbps link, a window larger than
2920 would only improve performance in cases where the network latency
exceeds roughly 2 seconds.  How can you say there's no windowing being
done?  As you just noted above, there's 2 MSS's worth of window.   There
have been several papers written about problems experienced when offering
large windows over slow speed links.

-------------------
Larry J. Blunk
Merit Network, Inc.

-----------[000568][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 94 17:27:08 GMT
From:      walker@nlm.nih.gov (Frank Walker)
To:        comp.protocols.tcp-ip
Subject:   MIME

I am interested in using MIME-compliant email to send compressed bitmapped 
images produced by a desktop scanner.  The size of a typical attachment
to an email message will be 1 megabyte.  Does anybody know if there
are any problems in sending an email message of this size?  Obviously,
this could put a load on a mail server if many email messages this size
started to get stored on the server.  Any problems in going through routers?

Frank Walker
National Library of Medicine
walker@nlm.nih.gov 


-----------[000569][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 17:52:11 GMT
From:      kasturi@vu-vlsi.ee.vill.edu (Srinivasa M. Kasturi - EE8460 Spring 1991)
To:        comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.ibm,comp.protocols.misc,cpmp.unix.osf.misc,comp.sys.novell
Subject:   Application Encryption Control and Comm. Stack Crypto Engine availability

Hi Folks,

I am looking for available standards/products that provide a "control"
interface to an encryption engine that is embedded in the communications
stack - with only the on/off control available to the application programs.

This option is most suitable for applications to "selectively" use
encryption.

DCE provides such interface - would much appreciate other protocols
standar/products that provide such an option and interoperability problems
amongst them that you know of.

In the event of interesting information will summarize to the 
comp.protocols.misc newsgroup.

Thanx many for your replies in advance - have fun - Srini

-- Disclaimer: Ideas expressed are my own and not those of either --
	    my employer or my affiliations unless otherwise stated
kasturi@vu-vlsi.vill.edu  	TRW, 2701 Prosperity Avenue
703-876-4444 			Fairfax, VA - 22031

-- 
-- Disclaimer: Ideas expressed are my own and not those of either --
	    my employer or my affiliations unless otherwise stated
kasturi@vu-vlsi.vill.edu  	TRW, 2701 Prosperity Avenue
703-876-4444 			Fairfax, VA - 22031

-----------[000570][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 17:57:42 GMT
From:      pam@csn.org (Paul A. Morris)
To:        comp.protocols.tcp-ip
Subject:   hp -tcp

 i am looking for help in interfacing some tcpip terminal servers
to an hp975 using tcpip. currently we can ping to the host from
the terminal servers but we cannot initiate a telnet session.
does anyone know what software or additional hardware is necessary
on the 975 so that we can connect any terminal server other thant 
hp's own through a telnet session.


-----------[000571][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 18:18:44 GMT
From:      nelson@crynwr.crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <764345336snz@ichthya.demon.co.uk> alistair@ichthya.demon.co.uk (Alistair Bell) writes:

   In article <NELSON.94Mar20230018@crynwr.crynwr.com> nelson@crynwr.crynwr.com writes:

   >In article <PMETZGER.94Mar19180706@andria.lehman.com>
   > pmetzger@andria.lehman.com (Perry E. Metzger) writes:
   >
   >   In article <2m740m$f94@universe.digex.net> philp@universe.digex.net (Phil
   > Perucci) writes:
   >
   >   >The cheapest full-time SLIP connection I have seen is about $200/month.
   >
   >   Netcom charges $160/month, I believe.
   >
   >TLG charges $70/month for V.32bis, $130/month for V.FAST, $325/month
   >for 56Kbps, and $800/month for T1.  Only problem is, you have to know
   >what you're doing, and you have to be in the San Francisco Bay Area.
   >Ask <info@tlg.org> for more info.
   >

   Err... I can't quite believe I'm hearing this. In the UK, Demon
   Systems set up a system a couple of years ago giving exactly what
   you are looking for - at less than US$20 (yes, twenty) per
   month. How come nobody in the US has caught on to doing the same?

I think you didn't notice that we're discussing *full-time* IP.  24x7
access.

--
-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000572][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 19:06:07 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: SUBNETTING CLASS C IP ON WAN

In article <2mk7sd$88k@zeus.london.micrognosis.com> bpeters@london.micrognosis.com writes:

>
>
>Has anyone out there experienced any problems subnetting Class C addresses over
>a WAN. This is something we need to do in a clients, and I have heard that we 
>may have difficulties doing this.
>
>Any replies would be gratefully appreciated, preferably on e-mail.
>
>**************************************************************************
>*                                                                        *
>*  Bill Peters                  E-Mail: bpeters@london.micrognosis.com   *
>*  Software Support                Tel: (+44) 71 815 5298                *
>*  MICROGNOSIS                     Fax: (+44) 71 815 5201                *
>*  LONDON U.K.                                                           *
>*                                                                        *
>**************************************************************************

There are no special difficulties with subnetting Class C over WAN
links, any more than over LAN subnets.

I have done several.  Biggest one for a UK government dept. using a
clump of contiguous Class Cs and variable subnet masks.

There are some golden rules:

You need a subnet address for every WAN link (KiloStream?)

Use OSPF if possible, which allows the subnet masks to be passed
where RIP does not.  This will give you freedom of choice for many 
little sites or a few big ones, or a mixture.  You will need to use
variable length subnet masks.

There is some controversy over the use of a mask of:

255.255.255.192   in that some people say that only gives you
two subnets of 62 hosts, instead of four, because the first two bits 
of the last octet ought not to be 00 or 11.  I don't believe this, 
but I'm nervous about recommending it in case they are right (and I 
have no means of veryfying it).

To be on the safe side, assume that people who say the subnet
number cannot be all 1s or all 0s:

	 a mask of 255.255.255.224  will give you 6 subnets of 30 hosts
	 a mask of 255.255.255.240  will give you 14 subnets of 14 hosts
	 a mask of 255.255.255.248  will give you 30 subnets of 6 hosts

etc.


-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-986

-----------[000573][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 19:06:57 GMT
From:      wrk@cle.ab.com (Wm. R. King)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute for Solaris 2.3?

In article 896@noao.edu, rstevens@noao.edu (W. Richard Stevens) writes:
> > Can anyone point me to a version of traceroute that has been ported
> > to Solaris 2.3 that can be picked up off the net?  Thank you in advance.
> 
> Anon ftp to ftp.ee.lbl.gov.  I'm still running the version I compiled
> under 4.1.3 and it runs fine under 2.3.  Be aware that the source route
> mods that appear in various places for traceroute do not run under 2.3
> (and won't without some coding changes).
> 
> 	Rich Stevens


While the code will run, I recommend recompiling it under Solaris 2. There are a few
new ip "features" that are conditionally compiled in traceroute. Specifically, 
IP_HDRINCL now exists.

Bill King




-----------[000574][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 19:09:17 +0000
From:      philc@hipstech.demon.co.uk (Phil Cramp)
To:        comp.protocols.tcp-ip,comp.sys.hp.hpux
Subject:   HP-UX 8.02 and TCP/IP "hanging"

HI,
Can anyone help me with information or FAQ locations about a problem
for which we do not necessarily know the cause?

The problem manifests itself as a login session "hanging" (i.e. not
accepting input from the keyboard, updating the screen with new
output) at the users PC whilst accessing an application running on
a HP-UX 8.02 platform.
The customer uses a number of different PCs and various software
packages to connect to the host over long-distance links, but all
methods uses TCP/IP and invoke telnet to connect. Once the system
becomes 'heavily' utilised - many persons logged in and active - the 
application in use will seem to "hang", as described, but can be
"re-activated" by disconnecting PCs from the host (by whatever method is
available - reboot PC, kill process etc.)

The question I have is should be tuning the TCP/IP side of the operating
system, or any kernel parameters that may affect TCP/IP in order to
improve the situation? Should we be looking to modify re-transmission
times (or attempts) in any way? Does anyone have experience of similar
problems, and as a result have some kind of "work-around" we may be
able to use?
I am sorry the description of the problem is so vague, but its one of 
those "you have to be there" type of problems and this seems to be the 
best way to describe the effects that are being experienced.
Thanks in advance,
-- 
Phil Cramp                      philc@hipstech.demon.co.uk
AT&T Istel Ltd., Redditch, U.K.
#include "std/disclaimer"       Reedemable Value UKP0.01

-----------[000575][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 19:28:12 GMT
From:      alhajery@cat.syr.edu (Eyas Al-hajery)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP code.



Can anyone help me locating a code (any code) for TCP/IP.  Is there any
site on Internet where I can get the code ??.
Thanks.

  - Eyas


-----------[000576][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 20:42:03 GMT
From:      raj@acc.com (Richard Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: need help on select() - when listening on 'S O C K E T S'

In article <2mnur7INNp7s@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
|> If a server needs to talk to multiple clients, you need to use multiple
|> sockets to do this.  A good example is an X server -- it has a connection
|> to each application that is displaying windows on it.  It uses select() to
|> wait for a command from any client.

This isn't TOTALLY true.  For example, if you're sending UDP packets to multiple
IP addresses you can use one socket and simply use the "sendto" monitor call to
send each packet.  Of course, if you're creating a TCP connection, you'll need
multiple sockets since TCP has state.  In the same way, you can use one socket to
receive UDP packets from multiple places, but not to connect to multiple TCP
connections.

|> The alternative to select() is a loop that checks each socket to see
|> whether there's anything waiting to be read.  This isn't as efficient as
|> simply waiting for any of them to indicate that they're ready to be read.

Make sure you set those file descriptors into non-blocking reads mode, of course.
"Select" is really the way to go, however.  It's not really as hard to use as
many people make out.  You use a bitmap to select what file descriptors you're
interested in, you tell the OS how many bits of your bitmap it should pay
attention to, and other than that it's simple timeouts.  Just play with it a
little.

/raj


-----------[000577][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 20:49:48 GMT
From:      elmo@sun.soe.clarkson.edu (Paul B. Davidson)
To:        comp.protocols.tcp-ip
Subject:   Looking for tn5250-capably telnet client for Unix..

The subject just asbout says it all.  I'm looking for a tn5250 capable teelnet
client, for use on a unix LAN (primarily sun).  I'd prefer public available
anonymous ftp, but if someone knows of a vendor, I'd be willing to hear about
it.

I'd prefer if you mailed the response- if ther eis interest, I'll be happy to
post results.  Thanks.

Paul B. Davidson
elmo@sun.soe.clarkson.edu
-- 
Paul B. Davidson, elmo@sun.soe.clarkson.edu
ELMO@CLVM : BITNET
...!dumb!dumb!smart!sun.soe.clarkson.edu!elmo :Old-Style UUCP
--
Paul B. Davidson, elmo@sun.soe.clarkson.edu
ELMO@CLVM : BITNET
..!dumb!dumb!smart!sun.soe.clarkson.edu!elmo :Old-Style UUCP

-----------[000578][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1994 10:12:39 -0800
From:      wolfgang@wsrcc.com (Wolfgang Rupprecht)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

>>The cheapest full-time SLIP connection I have seen is about $200/month.
>Netcom charges $160/month, I believe.

For the folks that are in the (San Fran) Bay Area you might want to
check out TLG.  Dialup slip/PPP $70/mo. unlimited usage. email:
info@tlg.org anon-ftp: tlg.org .

-wolfgang
-- 
Wolfgang Rupprecht <wolfgang@wsrcc.com>

-----------[000579][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 21:08:49 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: SUBNETTING CLASS C IP ON WAN


In article <764449567snz@peeras.demon.co.uk>, proyse@peeras.demon.co.uk 
(Phil Royse) writes:

|There is some controversy over the use of a mask of:
|
|255.255.255.192   in that some people say that only gives you
|two subnets of 62 hosts, instead of four, because the first two bits 
|of the last octet ought not to be 00 or 11.  I don't believe this, 
|but I'm nervous about recommending it in case they are right (and I 
|have no means of veryfying it).

My feeling is that you needn't forgo the use of the all-zeros
and all-ones subnets.  The problem with using these subnets is
that you run into an ambiguity problem:

- if something advertises a route to <net><subnet0><0>, then is
  that an advertisement for the net as a whole, or for only
  <subnet0>?  This problem can be finessed by using a mask-aware
  routing protocol such as OSPF, or by judicious use of static routing.
  Proxy ARP may be helpful in servicing endnodes that would otherwise
  be confused.

- if something sends a directed broadcast to 
  <net><subnet-all-1's><all-1's>, is that a directed broadcast
  to all subnets of <net>, or only to <subnet-all-1's>?  In my
  view, there is ordinarily no need for directed broadcasts at
  all, and everyone should simply use the <all-1's> limited
  broadcast, in which case this ambiguity is irrelevant.  (Some
  people assert that some applications use directed broadcasts,
  but I haven't seen any such applications.)

Now, my site has a couple of class B networks to play around with,
and we have the luxury of not using the all-zeros or all-ones
subnets.  (If a network has 1024 subnets, then it's no great
tragedy to waste two of them.)  But, what with ever increasing
address space scarcity, many sites that once would have gotten
class B's now need to live within the confines of a class C.  And
I would submit that forcing people to throw away half of their
address space in order to maintain semantic purity will prove
to be increasingly less tolerable.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

-----------[000580][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 22:11:12 GMT
From:      rms@mercury.uah.ualberta.ca (Rick Slansky)
To:        comp.protocols.tcp-ip
Subject:   PC Telnet terminal emulators



Can anyone point me towards a PC based Tandem 6530 (or equiv) telnet
terminal emulator?

I am also looking for a vt100 telnet which uses NDIS NetBios, instead of
a packet driver for the network interface. 

Either one of these will a conflict I am having.

---------------------------------------------------------------------
Rick Slansky - Communication Analyst    | rms@mercury.uah.ualberta.ca
Information Systems                     | phone 403-492-4485
University of Alberta Hospital          | fax   403-492-3090
Edmonton Alberta, Canada                |
---------------------------------------------------------------------








-----------[000581][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 22:20:54 GMT
From:      wrolf@csfb1.uucp (Wrolf Courtney)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

In article <2lqt5e$ds0@earth.cs.utexas.edu> oliver@cs.utexas.edu (Oliver Yehung Hsu) writes:
....snip...
>Note that since ypbind broadcasts to find a server, these broadcasts do not
>travel over subnets.  Therefore, if your NIS server is not on the same subnet
>as the client, the client cannot bind  to it through broadcasting.  You must
>explicitly tell the client to bind to that particular server with the 'ypset'
>command.
>
>Oliver

cisco (and I assume other router manufacturers) have commands to enable
forwarding of ypbind broadcasts across subnets.

Right off the top of my head the cisco configuration command is "yphelper"
- you configure the cisco router to forward broadcasts for the UDP port number
that ypbind broadcasts on.

This gets around what would otherwise be a problem in large, centrally managed
networks - having to have an interface from a NIS server on every subnet.  Two
interfaces if you wanted redundancy.

Wrolf

-- 
Wrolf Courtney               CS First Boston             My employer knows
(212) 322-7017               Park Avenue Plaza           I'm crazy.
wrolf@csfb1.fir.fbc.com      New York, NY 10055
uunet!csfb1!wrolf

-----------[000582][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 22:29:40 GMT
From:      fdebruin@wm.estec.esa.nl (Frank J de Bruin)
To:        comp.protocols.tcp-ip
Subject:   Re: Rhetorical question for the group

dmag@engin.umich.edu (Daniel Demaggio ) writes:
>> you want to get on the internet. full IP connectivity required. 
>> at a minimum, 56kb. preferably T1 or T3. 


>                Sattellite downlink? (naw, that would suck) 
Would you mind elaborating on this some more?

Frank
--
--
-- fdebruin@wm.estec.esa.nl
--    ESA/ESTEC, Keplerlaan 1, Noordwijk, The Netherlands, +31 1719 84951

-----------[000583][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1994 22:45:43 GMT
From:      cho@gauss.math.usf.edu. (Leonard Cho)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.networking
Subject:   WATTCP and Borland C instead of Borland C++

We want to use WATTCP to develop a PC client for our database. We also want to
use Borland C not Borland C++. Is there a version written for Borland C? Or is
there a simple way to make WATTCP compile under Borland C?
One of our screen development tools requires Borland C.
Thanks in advance

Leonard Cho   cho@math.usf.edu
--
Leonard Cho   cho@math.usf.edu

-----------[000584][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 1994 23:03:42 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: MacTCP window size problem?

In article <2mpsjt$q03@lastactionhero.rs.itd.umich.edu> ljb@merit.edu writes:
>          .....  Watch what happens when you offer a 24K window to
>SunOS.  It will blast out 24K before receiving an ack (since it
>doesn't do slow-start).   ...

Are you entirely certain of that?  You must be talking about the newest
SunOS TCP/IP, since wasn't the previous version the same as SVR4?  Which
was really a STREAMized 4.3BSD-tahoe which has slow-start.  I don't have
any way of checking, but I'd be extremely surprised to hear that the new
SunOS TCP/IP doesn't have slow-start.

I suppose the version from 8 or 10 years ago, based on 4.2BSD did not have
slow-start, but that can't be what you're referring to.


Vernon Schryver    vjs@rhyolite.com

-----------[000585][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 94 18:29 GMT+0300
From:      irl@glas.apc.org
To:        comp.protocols.tcp-ip
Subject:   PC-NFS 5.0 and WinWord 6.0  HELP!

Hello everybody!

Does anybody succeeded in network installation of MS Word 6.0 under
PC-NFS 5.0?

I'm really confused, because of a lot of problems arised. First of all
it is impossible to enter Network Server during installation process, because
Setup converts lower case letters to upper case, while PC-NFS needs lowercase.
Winword6.inf file contains garbage in 50% cases. When I try to start
setup from the network drive (in order to set up Word on workstations)
then it ends in Segment Load Error.

Any ideas?

Thanks in advence,

Vladimir Gurevich
SYNAPSE Science Center / IRIS Moscow Data Center
System Manager

gurevich@idahub.ucsd.edu

-----------[000586][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1994 13:09:08 -0800
From:      lars@spectrum.rns.com (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <1994Mar22.221926.8890@pony.Ingres.COM> tomm@Ingres.COM () writes:
> ... another big concern of mine was getting a real address space.
> I talked to CERFnet a while ago and they told me 160/month
> for ONE IP address. ...
> Why don't these vendors just let you apply for a class C from the NIC and
> route packets for you.

Most low-end SLIP or PPP connections are offered for use by a single
workstation, with an address allocated out of the service provider's
IP address space. This means that there is no routing table maintenance
done explicitly on that customer's behalf.

Once you issue the customer a class C network number, every router in
the internet has to know how to get to that network. Currently, the
larger backbone networks have to keep track of just over 19000 routes.
This involves a very real cost: If we continued as we have been running
until now, the largest Cisco models would run out of memory to hold
these tables when we reach about 25000 routes. (I.e. in June of this
year.)

Fortunately, we are in the middle of changing this. For the last couple
of years, we have been working on issuing network numbers that are
grouped around the natural topology of the backbone networks. I.e.
all 198.x.x.x addresses are in North America; all 193.x.x.x addresses
are in Europe. A new routing table exchange protocol, known as BGP-4
(Border Gateway Protocol version 4) has been defined, which allows
a single routing table entry to cover a block of adjacent network
numbers rather than a single network number. This is expected to provide
relief for the next couple of years.

Routers closer to the periphery of the network, don't see these huge
tables. Mostly, they have a few network numbers on the local side, and
a default route says "and everything else goes towards the backbone".
-- 
/ Lars Poulsen			Internet E-mail: lars@CMC.COM
  CMC Network Products		Phone: (011-) +45-31 49 81 08
  Hvidovre Strandvej 72 B	Telefax:      +45-31 49 83 08
  DK-2650 Hvidovre, DENMARK	Internets: designed and built while you wait

-----------[000587][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 00:12:38 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2 defaults to "do not fragment"?

> I noticed recently when telneting to a Solaris 2.2 host
> that things worked for a bit and then the connection
> would hang and timeout.  I traced it to the IP packets
> coming from the Sun having the "do not fragment" flag
> turned on.  This stopped the packets from reaching me
> because an MTU along the way was too small for the packet
> and the router dropped the packet.  Is this the default?
> How do I change it?

It's called "Path MTU Discovery" and is described in RFC 1191.
Solaris 2.x is one of the few systems that implements it today.
Lots of details on it, and examples of it in use are in Sections
11.6, 11.7, 11.8, and 24.2 of my recent book "TCP/IP Illustrated"
(Addison-Wesley, 1994).

To turn it off use ndd(8) and set ip_path_mtu_discovery to 0.
Notice that if the router with the interface with the smaller
MTU dropped your packet it should have also sent an ICMP
unreachable error (fragmentation required and DF bit set),
telling your Solaris host to cut back the segment size.

	Rich Stevens  (rstevens@noao.edu)

-----------[000588][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 10:38:56 -0600
From:      resnick@cogsci.uiuc.edu (Pete Resnick)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: MacTCP window size problem?

In article <Cn4FEt.F3y@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Ran
Atkinson) wrote:

>MacTCP has historically had problems in its TCP Windowing code.  I had
>thought those were fixed beginning with MacTCP version 2.0.4.  In
>fact, I had thought that was the main advantage of using 2.0.4 rather
>than some earlier version.

MacTCP hasn't had general problems with its windowing code; it only had
problems with its retransmission timers. That's the main thing that was
addressed in 2.0.4.

pr
-- 
Pete Resnick    	(...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu

-----------[000589][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 02:34:34 GMT
From:      harp@martha.utcc.utk.edu (harp)
To:        comp.protocols.tcp-ip
Subject:   Unix system with two network interfaces


I would like to solicit some comments from the net on the following subject:
The pros and cons of two network interfaces on the same wire (two different
logical subnets).  What I would like to know is whether this is feasible.
This hypothetical machine would not be forwarding packets or acting as 
a gateway, but simply existing on the net.  You may ask "what is the point
of having a machine with two interfaces on the same network?", but that is not
what is in dispute.  I could also ask what the implications of having a 
machine with two interfaces (say one ethernet and one FDDI) on two different
networks separated by a bridge.  So the question would be:

  How would network traffic (broadcast packets in particular) affect the 
  machine?  Would the fact that each network interface receives them
  simultaneously cause any problems?  An example of such a broadcast would 
  be RIP.  Are there any other problems that could arise from such a 
  configuration?

Sean Harp
University of Tennessee 


-----------[000590][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 02:46:33 GMT
From:      karl@empirical.com (Karl Auerbach)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2 defaults to "do not fragment"?


>I noticed recently when telneting to a Solaris 2.2 host...
 
> I traced it to the IP packets
>coming from the Sun having the "do not fragment" flag
>turned on.  This stopped the packets from reaching me
>because an MTU along the way was too small for the packet
>and the router dropped the packet.

Did you notice whether that router was sending back ICMP messages
saying that the destination was unreachable because to get there would
require fragmentation?  Routers are supposed to do that.

What you are probably seeing is the Sun trying to do MTU discovery.

MTU discovery is a good thing; there are too many hosts out there that
are sending unnecessarily small packets (often 512 to 576 bytes) around the 
internet.  (And since overhead is often tied to the packet rate, not the 
byte count, this hurts everyone.)

But MTU discovery can't work unless the routers follow the rules and tell the
Sun that the packets are too big and that the Sun should ratched
down the packet size.

             --karl--



-----------[000591][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1994 02:47:18 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?

In article <Cn522w.H2G@csfb1.fir.fbc.com> wrolf@csfb1.uucp (Wrolf Courtney)
writes: 

    Right off the top of my head the cisco configuration command is
    "yphelper" - you configure the cisco router to forward broadcasts for
    the UDP port number that ypbind broadcasts on.

Close.  It's "ip helper-address" and "ip forward-protocol".

Tony

-----------[000592][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 10:08:20 GMT
From:      kardel@nessy.informatik.uni-erlangen.de (Frank Kardel)
To:        comp.protocols.tcp-ip
Subject:   Re: NTP client?

victor@mickey.cc.utexas.edu (V Menayang) writes:


>This is a novice question so please excuse me if
>it's not posted to the proper group.
 
>I'd like to set the clock on my machine to an NTP
>server on campus.  What program do I need to do this?
>My machine is running a flavor of BSD unix.  I looked
>at xntp, but it seems like an overkill.  I only
>need a simple client that I could invoke at the command
>line or through crontab.

Well, then use ntpdate from the xntp distribution and throw the rest
away.

Frank Kardel (kardel@informatik.uni-erlangen.de)

-----------[000593][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 94 10:33:49 GMT
From:      andras@concave.cs.wits.ac.za (Andras Salamon)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: [Q] Why not use sendmail under inetd?

In article <VIXIE.94Mar23004003@office.home.vix.com>,
Paul A Vixie <vixie@vix.com> wrote:
> since a sendmail listener that isn't getting any new connections is a
> prime candidate for having pages stolen for processes that need them,
> there's really nothing to be gained from running out of inetd.

Unless, for instance, you are running sendmail from a tcp wrapper via
inetd.
-- 
Andr\'as Salamon                   andras@cs.wits.ac.za

-----------[000594][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 94 19:43:42 PST
From:      cvadr047@csupomona.edu
To:        comp.protocols.tcp-ip
Subject:   FIX-EAST AND FIX-WEST!

Any body knows what reference discusses or mentions about fix-east and fix-west,
and also reference about discussion that RIP is a simpler protocol than GGP...
please give me info. Well, this is a specific info which I didn't get from the
Comer's or Stephen's book (or probably I overlook the info, if you know ?). 
Thank you for your reply. Thank you in advance.....

..Tedjo Poernomo

-----------[000595][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 12:40:32 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: MacTCP window size problem?


>In article <2mpsjt$q03@lastactionhero.rs.itd.umich.edu>, ljb@merit.edu
>(Larry J. Blunk) wrote:
>>...
>> low-speed link.  Watch what happens when you offer a 24K window to
>> SunOS.  It will blast out 24K before receiving an ack (since it
>> doesn't do slow-start).

In article <sdorner-230394185444@192.17.5.2> sdorner@qualcomm.com (Steve Dorner) writes:
>Why should all PPP users suffer because Sun never has done (and perhaps
>never will do) networking properly?

Fixed in Solaris 2.x where they claim to implement slow-start.  SunOS
4.1.3 is an old operating system, though still widespread.  Sun is
getting better, for example Solaris 2.x is one of the few systems that
implements Path MTU Discovery, for another example Solaris 2.x was the
second commercial operating system (SGI was first) to implement IP
Multicast.

Ran
atkinson@itd.nrl.navy.mil





-----------[000596][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 12:59:58 GMT
From:      ssudoher@csug.cs.reading.ac.uk (A.J. Doherty)
To:        comp.protocols.tcp-ip
Subject:   Re: bind

In article 764372538@rupert, gel102@gel.ulaval.ca (Jacques Tremblay) writes:
> I have a problem when I try to restart a server that I have done. The bind
> function returns the error "address already in use". It takes some time
> for the port number to be freed by the system. After a while, it works and
> my server runs perfectly. What can I do to force the port number to be
> freed? Thanks a lot in advance. 

you can overcome this problem by setting the SO_REUSEADDR option on the socket
before you bind it, something like the following ...

[blah]

int trueflag = 1;
setsockopt(socket_fd,SOL_SOCKET,SO_REUSEADDR,(char*)&trueflag,sizeof(int));

[blah] do bind call ...

This works for me on SunOS 4.1.X and Solaris 2.X

Andy.




-----------[000597][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 94 13:14:18 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2 defaults to "do not fragment"?

Just a followup to this discussion on path mtu discovery ...  If you're
interested in seeing what the MTUs are like on the paths you're using,
and whether the routers you deal with can handle this correctly, I have
a hacked up version of traceroute that does path mtu discovery: it sends
the UDP packets with the don't fragment bit set, handles the returned ICMP
unreachables, cuts back the datagram size, and prints the results as it
goes along.  Anon ftp the file /published/books/stevens.tcpipiv1.tar.Z
and compile the file traceroute.pmtu.c that's in there.  Be sure to read
the file README in that directory, as there are some funnies on certain
systems that I've tried it on.

	Rich Stevens

-----------[000598][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 94 13:37:00 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help: doing 'write' on hungup socket

> When you try to 'write' on a socket that has been hungup, then
> normally you'll get SIGPIPE, and write will return with 0 and errno
> is set to EPIPE.
> But what I get when 'write'ing to a hangup socket is that
> write returns successfully (with value equal to the bufferlen, which is
> the third argument). I do not get SIGPIPE. A second call to write will
> generate SIGPIPE.

Depends what you mean by "hungup".  If your TCP receives a FIN, it
still thinks the other end of the connection is there and capable
of receiving data.  This is TCP's half-close in action.  You are
allowed to send data, and if the process at the other end has really
gone away, its TCP will respond to the data with an RST.  The receipt
of a FIN does not tell the receiver whether the process at the other
end has done a half-close, terminated, or aborted.

When your TCP receives an RST, then SIGPIPE is generated if you
write to the socket.  That's why it takes 2 writes to get the
signal: one write is OK and generates an RST response.  The next
write generates the signal.

You should be select()ing on input from the socket to detect what's
happened at the other end, not counting on write() returning an error.

	Rich Stevens

-----------[000599][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 94 14:26:38 GMT
From:      vtwlee@dciem.dnd.ca (Vivian Lee)
To:        comp.protocols.tcp-ip
Subject:   delay & reliability of TCP/IP and modem



I am trying to decide where I should send packets of info. from Canada to US
via TCP/IP or modems. So I am concerning about delays and reliability
(especially when the load is heavy). I am also concerning about the
cost. If anyone knows where I can find the information, please send a
e-mail to me.

Vivian
vtwlee@dretor.dciem.dnd.ca


-----------[000600][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1994 15:00:50 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   key-exchange protocols




   We are working with swIPe here at MITRE(security at the ip network
layer). We got the basic code working and now we are including
Diffie-Hellman key exchange. Key-exchange is a protocol in itself and
before we get mired into design and implementation of a protocol from
scratch we'd like to know if its been done before or written about or
both. So here is the question:

  Are there any existing key-exchange protocols or is there anybody
out there working on key-exchange?


-----------[000601][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 15:05:24 GMT
From:      aorellan@dcc.uchile.cl (Alejandro Orellana)
To:        comp.protocols.tcp-ip
Subject:   Re: NTP client?

In article <2mroqkE7ma@uni-erlangen.de> kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) writes:
>victor@mickey.cc.utexas.edu (V Menayang) writes:
>
>
>>This is a novice question so please excuse me if
>>it's not posted to the proper group.
 
>>I'd like to set the clock on my machine to an NTP
>>server on campus.  What program do I need to do this?
>>My machine is running a flavor of BSD unix.  I looked
>>at xntp, but it seems like an overkill.  I only
>>need a simple client that I could invoke at the command
>>line or through crontab.
>
>Well, then use ntpdate from the xntp distribution and throw the rest
>away.
>

You can get it from louie.udel.edu . 

Alejandro.
-- 
---
Alejandro T. Orellana Burgos.      /\    Dios es real, a menos que sea
email:aorellan@dcc.uchile.cl      /  \   declarado como entero. :-)

-----------[000602][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 15:16:50 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2 defaults to "do not fragment"?

In article <1994Mar24.131418.20120@noao.edu> I wrote:
>
> Anon ftp the file /published/books/stevens.tcpipiv1.tar.Z
> and compile the file traceroute.pmtu.c that's in there.

I seem to have forgotten to give the host name ... it's ftp.uu.net.

	Rich Stevens

-----------[000603][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 15:58:25 GMT
From:      anw@allen.ess.harris.com (Allen Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: Rhetorical question for the group


In article <2mj3a2$2o2@minerva.doe>, bacon@mtu.edu (Jeff Bacon) writes:
>let us suppose the following:
>
>you're in the middle of nowhere. assume third-world technology
>available, i.e. poor local phone system based on old technology.
>(you can make a long-distance phone call, but the link sucks rocks.)
>you're at least 400 miles from anyone with any sort of real connectivity,
>probably much more to connect in to a decent point-of-presence. 
>
>you want to get on the internet. full IP connectivity required. 
>at a minimum, 56kb. preferably T1 or T3. 
>
>you have a LOT of money at your disposal. let's say, working figure of
>$2mil US. satellite connections are not out of the question, there
>are satellites available.
>
>how would you do it?
>
>-bacon
>
>--
>= Jeffery Bacon     General Systems Hack, Michigan Technological University =
>= bacon@mtu.edu     ph-(906)487-2197 fax-(906)487-2822    Printing is Evil. =
>=          End of Earth, 13 miles. Are your seat belts fastened?            =
>

If you get any solutions other than satellite (or ~30 microwave hops), I would
like to here it.  That also means you must set up a feed in some reasonably
civilized place.

-- 

Allen                                                    Voice: (407)727-5280
anw@allen.ess.harris.com                                 Fax:   (407)729-1985


-----------[000604][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1994 12:51:05 +0200
From:      eloranta@network.cc.jyu.fi (Jussi Eloranta)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2 defaults to "do not fragment"?

In article <2mqigp$gk2@terminator.ncts.navy.mil> mjenkins@ncts.navy.mil writes:
...stuff removed...
>
>(I must say NetBSD is looking better every day :-)
>
Try what happens when you run (for example):

main() { while(1) read(99,99); }

compile it and start it (not in background). Then type ctrl-z and try to leave
it in background... at least here it netbsd cuts off all network connections
for 15 mins or so. Even solaris can't do that ;-)

jussi


-- 
============================================================================
Jussi Eloranta               Dept. of physical chemistry
eloranta@jyu.fi              University of Jyväskylä, Finland

-----------[000605][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 17:49:17 GMT
From:      bsaffo01@cad.vmss.gmeds.com (Brian H. Safford)
To:        comp.protocols.tcp-ip
Subject:   X3270 Timeout

We are running x3270 3.0.1 and our mainframe folks tell us that there is a 10 
minute inactivity timeout for all mainframe sessions, and that the 10 minute 
value is an OSF standard. :-)

Ignoring for a moment that our mainframe folks might not know what they're 
talking about, has anyone else encountered this timeout? Is it a negotiable 
value? I'd like to set it much higher (say 120 minutes) if possible.

Thanks in advance (e-mail replies, please!)

Brian Safford

+-------------------------------------------------------------+
| Brian H. Safford         EMAIL: bsaffo01@cad.vssm.gmeds.com |
| Electronic Data Systems  PHONE: (810) 492-7967              |
 +-------------------------------------------------------------+
| NOTE: The views and opinions expressed herein are mine,     |
| and DO NOT reflect those of Electronic Data Systems Corp.   |
 +-------------------------------------------------------------+

-----------[000606][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 94 00:14:12
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: etherfind/tcpdump not seeing outgoing packets ?

> With BPF (Berkeley Packet Filter) and tcpdump you can see outgoing and
> incoming packets.  The problem with SunOS 4.x is that you need the sources
> to your interface drivers to replace the NIT code with BPF code.

Not quite. Thanks to Steven Casner, the necessary *binary* modules are
available with anonymous FTP from ftp.isi.edu:/mbone/sunos-bpf. Note that
these modules (if_le.o and if_loop.o) also include support for IP multi-
casting - if you want BPF you'll have to install the multicasting part also.
The rest of the IP multicasting code for SunOS is available with anonymous
FTP from gregorio.stanford.edu:/vmtp-ip.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000607][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1994 20:18:22 GMT
From:      yijou@solar.csie.ntu.edu.tw (Yih-Iuan Jou)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIPS

Mike (mikeb@village.com) wrote:

: Try as I might I could not find a newsgroup dedicated to SLIP/PPP and so
: and so forth.  Instead of annoying the posters here, I thought i'd ask
: if anyone knows of any newsgroups dedicated to that?  If not, I just might
: propose one.  Thanks in advance

I know that these is a newsgroupe, named "comp.protocols.ppp", which discusses
about PPP. Maybe you can subscribe it.
Hope it is helpful.
--
PLEASEPLEASEMEWITHTHEBEATLESAHARDDAYSNIGHTBEATLESFORSALEHELPRUBBERSOULREVOLVER
 SGTPEPPERSLONELYHEARTSCLUBBANDWHITEALBUMMAGICALMYSTERYTUOURABBEYROADLETITBE
              ---===||  yijou@csie.ntu.edu.tw [EAGLE]  ||===--- 

-----------[000608][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 94 21:04:39 GMT
From:      emm@sbphy.physics.ucsb.edu (Elise Meyer)
To:        comp.protocols.tcp-ip
Subject:   Workstations as Routers - Love them or Hate them?

If you have or had a workstation acting as a router, I
would be interested in hearing whether you loved it or
hated it.  I am specifically interested in the following
information: What you liked/disliked about it.  How many
hosts/subnets you supported with it.  Whether you just had
ethernet interfaces, fddi interfaces, or a combination of
the two.  What growth potential you see for it.  Thank you
for any information that you can give me.  I will summarize
responses to the net.

Elise Marie Meyer
Department of Physics
Santa Barbara, CA 93106

-----------[000609][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1994 22:07:47 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Slip && FTP implementations

In article <2mn0o7$rjn@mack.eng.sc.rolm.com> dant@minerva.rolm.com writes:
>                        Lan connection
>        Station A <---------------------------> Station C
>                         Slip Connection
>        Station B <---------------------------> Station C
 
>Do I need separate implementations of ftp  to transfer data between from
>A to C, and B to C.  Due to different hardwares.

No.  FTP just needs to be able to send IP packets.  The SLIP link is just
like any other network connection as far as application software is
concerned.  Isn't this the whole point of SLIP?
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000610][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 1994 22:31:37 GMT
From:      russ@sun.com (Russell Sutherland, NDIS)
To:        comp.protocols.tcp-ip
Subject:   RFC 1219 algorithms

I asked this question before but maybe was asleep or not reading this
group when the answer came. So here it is again. I do semi-regularly
read this group but please send e-mail if you have any information.

RFC 1219, On the Assignment of Subnet Numbers, by P. Tsuchiya (his name
has changed) proposes a clever method for assigning IP subnet masks and
numbers. Does anyone know the source for public domain code that
implements his algorithms (or equivalents)? TIA.

---

Russell Sutherland			Bell:	   (416)-978-0470
UTCC, Network Development 		Fax:	   (416)-978-6620
University of Toronto			E-mail:    russ@utcc.utoronto.ca
Toronto, Ontario CANADA M5S 1A1


-----------[000611][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1994 08:39:12 -0500
From:      newbury@tecsun1.tec.army.mil (George Newbury)
To:        comp.protocols.tcp-ip
Subject:   Re: FAQ for tcp-ip

annadata@nada.ics.Hawaii.Edu (Anil Annadata) writes:



>	I would like to have the FAQ fro tcp-ip. Can anyone of you
>suggest me where I can download it from.

FAQ's can be obtained from rtfm.mit.edu
They cover a lot of subjects, and ftp may be there.
-- 
George E. Newbury III  newbury@tec.army.mil  (703)355-2751 [DSN345]

-----------[000612][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1994 00:45:16 GMT
From:      dinowitz@bu.edu (Mitchell Dinowitz)
To:        comp.protocols.tcp-ip
Subject:   QUESTION!! Network Capacity Planning


Hello!!

I am doing research on network capacity planning, with the hopes of
developing a "cannonical" checklist of factors that could effect
network capacity and performance (hardware, software, cabling.....
anything and everything!!)

I would greatly appreciate input from anyone who has had experience
with this, or anyone who is knowledgeable in this area.

Please send responses to:

dinowitz@acs.bu.edu  OR  dinowitz@csa.bu.edu

Sincerely,

Mitchell J. Dinowitz


-----------[000613][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Mar 1994 01:12:27 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2 defaults to "do not fragment"?

Karl Auerbach (karl@empirical.com) wrote:
> But MTU discovery can't work unless the routers follow the rules and tell the
> Sun that the packets are too big

  I believe that's not exactly correct.  Old-style ICMPs __are__ supported by
  correct PMTU implementations.  In that case, the implementation should
  choose a default MTU and __not__ set DF in future packets (i.e., let the
  router fragment).

  However, I believe that some routers can be configured to __not__ send
  ICMPs (at least some ICMPs).  Certainly, PMTU will fail in that case if the
  originally-chosen MTU is too big.

-- Ken Mintz

-----------[000614][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1994 01:44:25 GMT
From:      kmiller@cs.sunysb.edu (Kevin Miller)
To:        comp.protocols.tcp-ip
Subject:   Stevens

Unix Network Programming is written by Richard Stevens.. The
publisher is Prentice Hall

-----------[000615][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Mar 1994 03:30:11 GMT
From:      mcknight@rbdc.wsnc.org (Michael Mcknight)
To:        comp.protocols.tcp-ip
Subject:   AS/400 Load?

I hate to post this here, but I couldn't find a newsgroup related to the IBM
AS/400 family...

Anyway, we have an AS/400 with TCP/IP on it.  It is running OS v2.2 and has
the appropriate version of TCP/IP.

I have been told that telnet sessions cause an extremely heavy load on an
AS/400 and 10 or so connections will bring the machine to its knees.  Now,
this is a very large AS/400 and currently handles over 200 users via Twin-Ax
and PC-Support SNA.

We have a 5250 emulation package that can use either SNA or TCP/IP to talk to
the AS/400.  My question is, Just why would a telnet session overload the
AS/400?  I have dealt with many TCP/IP systems and have even written RPC's
and other client/server applications and I just dont see how something as
simple as telnet could cause such a problem.

If someone out there is more familiar with the way the 400 handles its TCP/IP
and can explain this to me, please do.... I hate SNA!  Also, even if you dont
know about AS/400's but do know more about the inner-workings of a telnet
session, please enlighten me.

Thanks to all.

Please send all replies via Email directly.

_________________________________________________________________________
| Michael McKnight -- mcknight@rbdc.wsnc.org    |    Amiga 3000-25/100  |
|   Pi Kappa Phi                                |    486DX-33/210 VLB   |
 -------------------------------------------------------------------------
|      PP-ASEL -- See, I'm not a 100% geek... I fly airplanes too!      |
-------------------------------------------------------------------------

-----------[000616][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Mar 94 11:26:29 PDT
From:      Bruce White <bwwhite@mmm.com>
To:        comp.protocols.tcp-ip
Subject:   WFWG 3.11 & ChameleonNFS


Does anyone have any experience running Netmanage's ChameleonNFS 4.0 and WFWG 
3.11 together?  I am running them and they seem to be pretty compatible.  
However, I can't figure out how to print to a network printer when Chameleon is 
my network carrier (I don't know if that is the right word to use here).  I 
also can't print using Netmanage's LPD/LPR utility.  The printer is an HP 4si 
MX with a JetDirect card supporting multiple network protocols, one of which is 
TCPIP and is hooked up to a UNIX server.  I've called Netmanage, but their 
support lines are always busy and they seldom return my calls.  I've emailed 
them twice and they have not responed to either one.


Bruce White
bwwhite@mmm.com

-----------[000617][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Mar 1994 05:35:57 GMT
From:      atm@cse.iitb.ernet.in (Amit Tilak Mehta)
To:        comp.protocols.tcp-ip
Subject:   Fast Retransmit & Fast Recovery ??

I came across the mechanism "Fast Retransmit and Fast Recovery" 
during the course of my work on TCP/IP over ATM networks. 
I know that it has to do with error recovery, but I need further
details. It says that it can efficiently recover from 1 error per
window but more than that leads to a big fall in throughput.

Could anybody please give me more details on this mechanism.
Further postings or E-mails will do.

My address is amit@kedar.ee.iitb.ernet.in

Thanking you.

Amit.

-----------[000618][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1994 20:23:56 -0600
From:      victor@mickey.cc.utexas.edu (V Menayang)
To:        comp.protocols.tcp-ip,comp.protocols.time.ntp
Subject:   Re: NTP client?

Frank Kardel <kardel@nessy.informatik.uni-erlangen.de> wrote:
>
>Well, then use ntpdate from the xntp distribution and throw the rest
>away.
>

Thanks, to you and others who responded to my query.
I finally decided to get the whole xntp package and compile
the ntpdate utility.  BTW, perhaps because how I configure
the compile, I can only query NTP V3 servers.  Is this an expected
behavior of the ntpdate V3?


-victor

-----------[000619][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Mar 1994 15:37:13 +0100
From:      vdh@info.fundp.ac.be
To:        comp.protocols.tcp-ip
Subject:   ICMP rfc

Hi,

We are students in Computer Science at the University of Namur, Belgium.
We are looking for the RFCs defining ICMP and, for that matter, any
document that relates to this topic (should be freely available on the net :)

Can anyone help locate those gems ?

Please respond by e-mail to vdh@info.fundp.ac.be

Thanks in advance !

Vincent D'Haeyere and Xavier Gobert

=============================================================================
Vincent D'Haeyere
Student in Computer Science (4th)
Institut d'Informatique
Faculte Notre Dame de La Paix, Namur (Belgium)

E-mail : vdh@info.fundp.ac.be

-----------[000620][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1994 20:02:50 GMT
From:      dblaettl@waynesworld.ucsd.edu (Dave Blaettler)
To:        comp.protocols.tcp-ip
Subject:   [Q] How to get MacTCP libraries and headers

I was wondering of anyone can point me to the direction of the libraries
and headers that use the MacTCP protocol.  I'm trying to create a client that
can connect to a UNIX server using sockets.

Thanks in advance.
Dave Blaettler
UCSD Medical Center MRI
dblaettl@ucsd.edu

--
BreedersSmashingpumpkinsArresteddevelopmentPearljamCranberriesRedhotchilipeppers
Thrillkillcult10000maniacsStetienneTempleofthedogNirvanaScreamingtreesNineinch
nailsMinistryWhitezombieJesusjonesPaulwesterburgRageagainstthemachineBauhaus
ThecureKatebushU2SoundgardenSonicyouthPixiesBjorkGinblossomsAnthraxPublicenemy

-----------[000621][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Mar 1994 21:28:15 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Solaris 2.2 defaults to "do not fragment"?

> I've not heard the phrase "Old-style ICMPs" ??

The "old" ICMP Unreachable (fragmentation required) had 16 bits of 0.
Path MTU discovery changes this so that these 16 bits contain the MTU
of the outgoing interface that was larger than the datagram with the
DF bit.  But path MTU does *not* require this "newer" ICMP to work.
If the MTU is there, great, it tells the sender additional information,
but if the bits are 0, path mtu still works.

	Rich Stevens

-----------[000622][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1994 21:52:43 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: SUBNETTING CLASS C IP ON WAN


In article <1994Mar25.171351.1@cc.helsinki.fi>, jaakola@cc.helsinki.fi writes:

|How about the following variation of the problem:
|
|  - we have 6 subnets with 30 hosts (max) each i.e. mask 255.255.255.224
|  - let's suppose we are sitting on a SVR4 UNIX box
|  - we want to have routes to subNETs A.B.C.110***** and A.B.C.100*****
|    (the last octet represented in binary)
|
|What happens? SVR4 doesn't allow me to specify a mask in the "route add"
|command; so is there a risk that packets to A.B.C.110***** go to
|A.B.C.100*****?

Your TCP/IP should infer the correct netmask from what you've set
on your interface (via `ifconfig').  So 
route add net A.B.C.192 GATEWAY1   and   route add net A.B.C.128 GATEWAY2
should work OK.

|Can I have just two "route add net" commands or should I
|issue 30 static route adds to each host on each subnet?

Having a separate static route for each host sure sound unpleasant
to me.

AaronAaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

-----------[000623][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Mar 1994 04:51:47 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Keep clocks in sync (using ICMP?)

In article <1994Mar25.144829.10189@alias.com> mark@alias.com (Mark Andrews) writes:
>Anyone have a program or know of some way to keep workstation clocks in
>sync with a master running timed. We have SGI boxes which use timeslave
>for this purpose and I think it uses ICMP timestamps. I need something
>for RS6000's running AIX 3.2.4.

Timeslave uses ICMP timestamps for the time and the standard UDP port 13
service for the date.

Last year I included timeslave.c in the post-4.4BSD timed source in
sgi.com:sgi/src/timed.tar.Z.


Vernon Schryver    vjs@rhyolite.com

-----------[000624][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 1994 07:23:13 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <2msvhk$fda@spectrum.rns.com> lars@spectrum.rns.com (Lars
Poulsen) writes: 

    Once you issue the customer a class C network number, every router in
    the internet has to know how to get to that network. Currently, the
    larger backbone networks have to keep track of just over 19000 routes.
    This involves a very real cost: If we continued as we have been running
    until now, the largest Cisco models would run out of memory to hold
    these tables when we reach about 25000 routes. (I.e. in June of this
    year.)
    
Actually...  we've done a tiny run of boards that quadruple the high end
amount of memory.  Of course, we would prefer not to have to really ship
them.  And no one really wants to pay for them.  ;-) Of course, even with
this amount of memory, you buy less than 2 years worth of time.  ;-(

Tony

-----------[000625][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Mar 94 12:41:53 GMT
From:      rob@bsroso.atr.bso.nl (Rob van Son)
To:        comp.protocols.tcp-ip
Subject:   SLIP Products for MS-DOS

Hello,

From a remote PC running MS-DOS and Windows a SLIP (or C-SLIP) connection
with a Cisco-516 asynchronous communication server has to be setup. Via
this connection, LAN services will then become available for remote PC's. 
Can anyone of you give me more information on commercially available 
software packages supporting the SLIP functionality in this situation.

Thanks,
-----------------------------------------------------------------------------
Rob van Son                       Phone: (+31) 79 521 712
BSO/ZOETERMEER BV                 Fax:   (+31) 79 522 391
Netherlands                       Postal: Box 93
					  2700 AB Zoetermeer
					  The Netherlands
E-mail: rob@bsroso.atr.bso.nl
X.400 : S=van Son;G=Rob;I=RT;O=BSO/ZOETERMEER BV;P=BSO ORIGIN;A=400NET;C=NL
-----------------------------------------------------------------------------

-----------[000626][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Mar 1994 17:00:27 +0000
From:      richard@corixia.demon.co.uk (Richard Ashton)
To:        comp.protocols.tcp-ip
Subject:   Re: Q -- TCP retransmission timer

In article <2n3kcuINN5pm@early-bird.think.com>
           barmar@think.com "Barry Margolin" writes:

} In article <2mvedb$r2e@netnews.upenn.edu> hkim@gradient.cis.upenn.edu (Hyogon
}  Kim) writes:
} >Hi, I just began to learn TCP internals, and I have some questions
} >about retransmission timeout. My *guess* is that there is a timer
} >for each connection, and when an acknowledgement(with a higher
} >acknowledged sequence number than that the sender has) comes in,
} >the timer is reset, and if a certain period of time passes without
} >the acknowledged sequence number increasing at all, the sender knows
} >it should begin retransmission. How does it work?
}
} Your description is pretty close.  A retransmission is done when a timeout
} occurs while the last acknowledged sequence number is less than the next
} sequence number to be transmitted.
}
} >By the way, how is the timeout detected? By interrupt
} >from the timer or by polling, or, something else?
}
} This depends on the OS.
}
} You might want to get the book "Internetworking with TCP/IP: Volume 2", by
} Comer and Stevens.  It describes an implementation of TCP/IP.

A very good book but as you say you are a beginner I would get Volume 1
first {:-)

Regards   {} {} {}   Richard   {} {} {}   TEAM OS/2
--
   Richard Ashton    | richard@corixia.demon.co.uk | This opinion belongs
Fidelity Electronics |     GBIBMTJG at IBMMAIL     | to the Company and is
   Tunbridge Wells   |    Compuserve: 70734,465    | probably not my own.
         UK          | richard_ashton@vnet.ibm.com | I don't speak for IBM

"Avoid loud & aggressive persons, they are vexations to the spirit"
                                                       Max Ehrrman

-----------[000627][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 1994 21:37:25 GMT
From:      harri906@raven.csrv.uidaho.edu (Harrington)
To:        comp.protocols.tcp-ip
Subject:   Paralell Packet driver with IPX/ODI

Is there a paralell packet driver for PC's that might enable one to run a 
peer-peer network (such as with lantastic) over paralell ports???
Thankx
Dan Harrington


-----------[000628][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 03:36:21 GMT
From:      grantbow@netcom.com (Grant R. Bowman)
To:        alt.internet.services,comp.sys.mac.comm,alt.bbs.internet,comp.protocols.tcp-ip,comp.infosystems.www
Subject:   Re: Internaut V1 N1 Now Available

dabl2@lhc.nlm.nih.gov wrote:
: In <abobaCn0x75.6n8@netcom.com>, aboba@netcom.com (Bernard Aboba) writes:
: >Issue #1 of Internaut, an online magazine for users of the Internet, is 
: >now available. 
 
: Cool!  You may want to say something in your docs for people who use a lowly 
: Dos/Windows system with 8.3 file naming conventions, ie I had to rename all 
: *.html to *.htm to see them.  Also, don't you want comp.infosystems.www to 
: know about you?  Is this stuff available 'live' on a web site yet?

	the URL is file://ftp.netcom.com/pub/mailcom/internaut/index.html 
for the orignial and a bunch of other stuff.  For those that like to 
write HTML stuff, I have it in my Lynx BookMark file as:

<A HREF="file://ftp.netcom.com/pub/mailcom/internaut/index.html">Internaut>

Enjoy,

-- 
--
-- Grant R. Bowman                        Director of Planning, SV-PAL
-- grantbow@svpal.org                Silicon Valley Public Access Link


-----------[000629][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 10:37:57 GMT
From:      igb@fulcrum.co.uk (Ian G Batten)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   bootp forwarding

I'd like to have a central bootp server, which some machines would
access via routers.  My bootp-using machines are NCD and Tandberg X
terminals, HP printers and B+W NFS-equipped PCen.  I can't make it work,
and currently have to have /tftpboot NFS mounted onto a machine on each
subnet, as well as run bootp, because machines tend to tftp their boot
image from the machine that provides the bootp response.

My routers --- PCen running PCroute --- claim to support ``Bootp
Forwarding''.  What does this mean?  Can it help?

ian

-----------[000630][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 94 09:51:33 EET
From:      jaakola@cc.helsinki.fi
To:        comp.protocols.tcp-ip
Subject:   Re: SUBNETTING CLASS C IP ON WAN

In article <2mvmfb$hd1@auggie.CCIT.Arizona.EDU>, leonard@telcom.arizona.edu (Aaron Leonard) writes:
> In article <1994Mar25.171351.1@cc.helsinki.fi>, jaakola@cc.helsinki.fi writes:
> |How about the following variation of the problem:
> |
> |  - we have 6 subnets with 30 hosts (max) each i.e. mask 255.255.255.224
> |  - let's suppose we are sitting on a SVR4 UNIX box
> |  - we want to have routes to subNETs A.B.C.110***** and A.B.C.100*****
> |    (the last octet represented in binary)
> |
> |What happens? SVR4 doesn't allow me to specify a mask in the "route add"
> |command; so is there a risk that packets to A.B.C.110***** go to
> |A.B.C.100*****?
> 
> Your TCP/IP should infer the correct netmask from what you've set
> on your interface (via `ifconfig').  So 
> route add net A.B.C.192 GATEWAY1   and   route add net A.B.C.128 GATEWAY2
> should work OK.

In fact in this case "my interface" and the subnets A.B.C are different!
"My interface" is a on a X.25 WAN and each subnet is an ethernet, which
is connected to the WAN via a gateway. So lets mark "my interface"
A.B.D.1 where D!=C. How about this case?

> 
> |Can I have just two "route add net" commands or should I
> |issue 30 static route adds to each host on each subnet?
> 
> Having a separate static route for each host sure sound unpleasant
> to me.

To me too, that's why I'm asking...
--
Juhani Jaakola, jaakola@cc.helsinki.fi

-----------[000631][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 14:45:29 +0000
From:      dave@humbug.demon.co.uk (Dave Hudson)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

Anders Rolff (rolff@svea.eurokom.ie) wrote:

: Does Demon in the UK actually provide dial-up SLIP or PPP? From what
: I understand it is an on-line service where you read your e-mail, news,
: etc, on-line. As far as I understand, EUNET are the only ones in Europe
: who can provide IP, so Demon presumable bought their IP line from EUNET
: and are not allowed to resell it. EUNET provide dial-up SLIP and PPP
: in various European countries at various rates. 

Yes, Demon provides SLIP or PPP (selectable at call time).  Each system
connected via Demon has it's own IP number.  Quoting from one of Demon's
information notes:

        We have
	a 64K line connected to Sprintlink in the United States making
        us a totally independent Internet service provider.  We peer
        with EUNet and PIPEX to ensure good connectivity in Great
        Britain.  We are proud to have a direct line into the
        Department of Computing, Imperial College, London
        (doc.ic.ac.uk) from our Central London PoP (styx.demon.co.uk).

There are no calltime restrictions for the 11.75 UKP per month, and the
dialup connections are up to 14.4k.  I gather from the information they
periodically put out that they also do 64k leased lines (but they're 400 UKP
per month - going on info from January).  The only drawback is that I'm not
quite close enough to Warrington to get a local rate phone call :-(

		Regards,
		Dave

PS.  I have no connection with Demon other than being a very satisfied
customer :-)

-----------[000632][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 17:10:19 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: What protocol on 56Kb sync?

In article <lawsonCn2uDF.E1L@netcom.com> lawson@netcom.com (Steven Lawson) writes:
   I am looking at adding support for 56Kb synchronous line to our
   TCP/IP package.  My question: what protocol do I need to support
   over this interface? (SLIP, CSLIP, PPP, or something completely
   different?)

If you're talking to a router, it will talk PPP.  It may also talk a
proprietary encapsulation scheme left over from the same vendor's
products in the days before PPP, but today all routers can talk PPP.
I know of no products running SLIP over synchronous links.  CSLIP is
just SLIP with the redundancy left out of the headers.

   Also, at this data rate (and cost) would most installations tend to
   feed it into a host directly or into a dedicated piece of hardware
   on say an Ethernet backbone? (would providing a host interface for
   a 56Kb leased line connection be a waste of time for most
   installations?)

That depends entirely upon economics, expansion (connection count and
speed increase) plans, system management philosophy, etc.  We sell PPP
and SLIP, running async and sync, running on UNIX hosts and on
dedicated router hardware, and we see all different mixes.  There's no
"typical" installation - everyone's needs are different.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000633][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 17:10:34 GMT
From:      rchui@tethys.nswc.navy.mil (Raymond Chui)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer,comp.unix.sys5.r4,navy.nswc.misc
Subject:   How To Clea Or Free The Socket?

Hi, My Dare Net Dudes:
 
I am writting a simple socket client/server program with connection-oriented
protocol in TCP. Please refers to W. Richard Stevens's book "Unix Network 
Programming" page 261, Figure 6.2.

Connection-oriented protocol

myserver.c

socket()
   |
   |
 bind()
    |
    |
 listen()						myclient.c
   |							
   |							socket()
 accept()						|
   |							|
   |<-------block until connection from client--------->connect()
   |							|
 childpid=fork()					|
   if(childpid == 0)					|<---while(flag == 0)	
     |							|
     |							|
  read()<----------data request----------------------->write()
    |							|
    |							|
    |							|
 write()<----------data reply------------------------->read()
 
 My application is similar to ftp which that myclient can put files to
 myserver and myclient can get files from myserver. By the way I just
 modify the client.c/server.c programs in page 284 to page 286. in above's 
 book.I am written my own getfile() and putfile() functions.  So far my
 programs are doing O.K. its doing what I want. But I still got some
 problems with the client socket. When 1st time I get/put a file into the 
 socket with no problem at all. But when 2nd time I get/put a file into the
 socket, I got some garbage and append the command line into my 2nd file.
 This tell me after 1st data transfer, that socket still doesn't know EOF
 data file terminate, it still waiting there for more data, or tell the
 that socket has not flush clean the buffer ready for next data transfer.
 Can someone out there tell me why this happen and how to fix it? Is this
 one of FAQ? How do I use fcntl() and/or ioctl() system call(s) to control
 the client socket. The only way I can fixed this problem is I put the
 while() loop above the connect() system call in myclient.c. But this is
 not a good practice(you know why if you familiar ftp). Because you don't
 want to that client close(new_socket) and reconnect to server every time 
 finish data transfer. You want to close(new_socket) only when you decide
 quit() like:
 
 flag = 0;
 while(flag == 0) {
 	printf("myftp>");
 	scanf("%s %s", command, filename);
 	if (strcmp(command, "get") == 0)
 		do_get();
 	else if (strcmp(command, "put") == 0)
 		do_put();
 	else if (strcmp(command, "quit") == 0)
 		{ flag = 1; quit(); }
 	else			    
 		printf("unknow command\n");
  }
  
  If you know what the hell I am talking about and know the answers, 
  please do not just follow-up, please also send me a email.
  Thank you very much in advance!
    		

-- 
Raymond H. Chui                 | Democracy is not a way of getting better
NSWC N55                        | solutions.
10901 New Hampshire Ave.        |
Silver Spring, MD 20903-5640    | It's just a way to spread the blame.
U.S.A.                          |
Voice:1-301-394-3807 Ext. 45    |
Fax:1-301-394-4483              |
E-Mail:rchui%tethys@relay.nswc.navy.mil
Or     rchui@tethys.nswc.navy.mil
  _ __                                  _    ,    __
 ' )  )                           /    ' )  /    /  ) /
  /--' __. , , ____   ______   __/      /--/    /    /_  . . o
 /  \_(_(_(_/_/) ) )_(_) /) )_(_(_     /  ( o  (__/ / /_(_/_(_
             /
            /

-----------[000634][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 1994 17:54:24 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: Removing User's Host Site Name


In article <0097C124.2750CFE0.4822@rover.uchicago.edu>, 
eugene@rover.uchicago.edu writes:
|When in use many TCP-IP applications, the remote host is able to detect
|my hostname through UCX.  I was wondering if it were possible to make
|the user truly anonymous by disallowing the remote computer to gain
|this address, or perhaps to change this address to something like
|nowhere.edu.  Is this possible or is it too much trouble.  I don't
|want to permanantly change the hostname or change it for other users,
|I just want to withold the information on certain sessions.

Well, you can hack your DNS for your IN-ADDR.ARPA zone to map 
your IP address to "nowhere.edu".  This would have an effect
globally across name-to-number translations, which you could 
ameliorate by using a 0-TTL on the PTR and making the initiation
of the magic secret session actually trigger the PTR value update.

However, setting your PTR values bogusly in this manner would cause
the other members of the Internet community to stone you.  And it
would be pointless in any case, because you CAN'T (easily)
disguise the IP addresses in the packets you're emitting.

So, yeah, it's "too much trouble."  What are you really trying to do,
anyway?

(Followups to comp.protocols.tcp-ip.)

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

-----------[000635][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 19:57:08 GMT
From:      gfuchs@worldbank.org (Gil Fuchs)
To:        comp.protocols.tcp-ip
Subject:   DHCP - clarifications

I am looking for some clarifications regarding the DHCP protocol.
In "DHCP - TCP/IP Network Configuration Made Easy" by J.Allard, 
Microsoft Corp. I found a pretty good definition of this protocol.
The main difference between DHCP and BOOTP is the ability to provide 
a dynamically assigned IP address for a limited period, called the lease.

  According to the above article,when the client  reaches 50% of the lease 
time, It starts requesting the host that provided it's original IP Addr 
to extend the lease. if it does not receive an extension by 87.5% of the 
lease period, it starts asking any other host for an extension.

	If another host is to extend the lease, does it provide the 
Client with a new IP address, or use the same IP address which 
was already assigned before?

- If the host does assign a new IP address, how is the client able to 
preserve any active sessions, and notify the connected stations about this
change of address?

- If the host does not assign a new IP address, and maintains the old IP,
how does the original provider of this IP address get notified about it, 
so that it doesn't assume this address has been freed up for re-use?

Does anyone have any suggestions?

-----------[000636][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 1994 18:35:26 +0100
From:      cs_a206@ceres.king.ac.uk (Richard Smart)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,vmsnet.networks.tcp-ip.misc,vmsnet.networks.tcp-ip.multinet,vmsnet.networks.tcp-ip.misc
Subject:   INFO WANTED ON ARP, RARP and PORTS

Hi,

I have been studying data communications and I am not sure on the 
following areas:

  i)  ARP requests (getting the internet address - broadcast)
  ii) RARP requests (getting the ethernet address for a machine - to server)
  iii) PORTS and Datagrams

Does anyone have any information (including ftp site
documents) that could outline the above areas ? 

Cheers,

Richard Smart.
-- 
 ***********
Richard Smart
 ***********

-----------[000637][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 20:25:11 GMT
From:      tom@gursey.baruch.cuny.edu (Thomas Wong)
To:        comp.protocols.tcp-ip
Subject:   routable protocols

Hi, What makes a protocol routable?  I understand IP, appletalk, and
IPX/SPX are routable protocols but not NetBIEUS.  Why? Any books that
I can read more about it? Thanks.
Please reply directly.
--
Thomas Wong				We don't eat pork
tom@gursey.baruch.cuny.edu		But we like raw snake meat
Voice: 212-447-3047			We are the piglets family
Fax: 212-447-3076			---The Piglets

-----------[000638][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 20:35:01 GMT
From:      rleary@UMASSD.EDU
To:        comp.protocols.tcp-ip
Subject:   RFS - how widely used?


   How widely used is RFS (Remote File System) (in comparison to NFS, 
for example)? How does it different from NFS? A short 
succinct answer would be more than enough and much appreciated.

-----------[000639][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 21:32:09 GMT
From:      keithc@netcom.com (Keith Cornwell)
To:        comp.protocols.tcp-ip
Subject:   Port hung in LAST_ACK

Could someone please tell me if there's a way to clear a port that's stuck
in LAST_ACK state?  (Without a reboot of course.)

What causes a port to get hung in this state?

I'm running Solaris 2.3.

Thanks.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Keith Cornwell - Sr. Programming Specialist           Equifax, Inc. - M/S 42H
Voice:  404/740-7434                                  1505 Windward Concourse
Fax:    404/740-6790                                  Alpharetta, GA  30202
E-mail: keithc@netcom.com
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

-----------[000640][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 1994 22:04:07 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: SUBNETTING CLASS C IP ON WAN

> > jaakola@cc.helsinki.fi writes:
 
> > |  - we have 6 subnets with 30 hosts (max) each i.e. mask 255.255.255.224
> > |  - we want to have routes to subNETs A.B.C.110***** and A.B.C.100*****
> > |    (the last octet represented in binary)
> > |
> > |What happens? SVR4 doesn't allow me to specify a mask in the "route add"
> > |command; so is there a risk that packets to A.B.C.110***** go to
> > |A.B.C.100*****?
 
> In fact in this case "my interface" and the subnets A.B.C are different!
> "My interface" is a on a X.25 WAN and each subnet is an ethernet, which
> is connected to the WAN via a gateway. So lets mark "my interface"
> A.B.D.1 where D!=C. How about this case?

Then all A.B.C.* packets have to go to the same place.  (And yes, some of
them will cross X.25 twice.)  The only way to avoid this would be to make
your own system part of the A.B.C.* network, so that it can see the
subnetting.

-- 
Tom Fitzgerald   Wang Labs   Lowell MA, USA   1-508-967-5278   fitz@wang.com
Pardon me, I'm lost, can you direct me to the information superhighway?

-----------[000641][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 1994 10:51:39 -0700
From:      bioengr@taz.scs.ag.gov (Dennis E. Miyoshi)
To:        comp.protocols.tcp-ip
Subject:   Network Message Broadcast

Hopefully, I am asking this question in the correct newsgroup.  Please
forgive me if not.

I have a situation where there are a minimum number (3) of primary servers
and a maximum number (150+) workstations on a TCP/IP Network.  There
are times that I need to broadcast messages to the systems regarding
network upgrades and changes.  My question is:  Is there an easy way to
broadcast, to all stations, a message?  Even better, Is there a Network
message of the day program available?

Any help will be greatly appreciated.

=8^) Dennis

-- 
===============================================================================
ARPA Internet:  bioengr@scs.ag.gov
========================= ( ROBUST == A Broken Robot ) ========================

-----------[000642][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 94 11:10:39 -0700
From:      hitcmap@nebula.syscon.hii.com
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   VT100/TN3270 in one?

Hello!

I was wondering if there exists a TCP/IP client stack for DOS-based PC's that
offers Telnet for both standard emulation (ie VT class) and also covers TN3270
class emulation (ie 3278) in one package?  This would eliminate having each PC
loaded with two packages for example Novell's LAN Workplace for DOS and
Novell's TN3270 product.  We want to offer these PC users access to both a
RS/6000 running AIX and to a IBM 3090 host running TCP/IP, but the apps would
be written to a 3278 terminal type.

If anyone knows of such a package, please send a note with any comments.

Thanks and best regards. . . .  Mike


mpassineau@hii.com

class emual


-----------[000643][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 94 11:16:17 -0700
From:      hitcmap@nebula.syscon.hii.com
To:        comp.protocols.tcp-ip
Subject:   Telnet/WAN Question

Hello!

I read an article recently the advised to avoid using Telnet to access remote
servers and run applications at all costs over a WAN.  Well...my question is
what is the recommended method then to access remote hosts via TCP/IP to run
the applications on these hosts?  We are looking to setup several remote
offices to access a RS/600 - AIX based customer service application.  We are
considering either Frame-relay or the IBM Advantis network as our WAN carrier
solution.  The reason we are consdiering the Advantis network is because we
have some "true bluers" here that want to add yet another application to this
service that we subscribe to.  Unfortunately Advantis does not support anything
other than SNA today.

Any comments, advise would be greatly appreciated!

Thanks and best regards. . . .  Mike

mpassineau@hii.com


how do


-----------[000644][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 1994 01:53:45 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFS - how widely used?

In article <CnE6IF.IpI@umassd.edu> rleary@UMASSD.EDU writes:
>
>   How widely used is RFS (Remote File System) (in comparison to NFS, 
>for example)? How does it different from NFS? A short 
>succinct answer would be more than enough and much appreciated.

The "Emerging Network File System Standard" (AT&T, 1985) is dead.

It was quite different from NFS, being "stateful" and so more similar to
a familiary UNIX file system.  That stateful philosophy also made server
crashes or network problems much more inconvenient.  Accesses to device
inodes affected hardware on the server instead of the client.

The code that I saw was awful, spread all over the kernel, both above and
below the File System Switch.


Vernon Schryver    vjs@rhyolite.com

-----------[000645][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 1994 04:13:38 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Re: What protocol on 56Kb sync?

I would like to thank everybody who responded.  It appears PPP is the
protocol of choice for this interface.  I think I have also decided to
abandon this idea and work on more important portions of the TCP/IP
stack/application set.  My company sells multi-user systems (for which
I am implementing TCP/IP) and given our system sizes and other factors
in the design, a router solution would probably be a better choice over
the programming effort.

thanks again!

- Steve

-----------[000646][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 94 16:54:03 +1030
From:      sherwood@dstos3.dsto.gov.au
To:        comp.protocols.tcp-ip
Subject:   ARAP Config Help !!!


Hello,

I am trying to configure a CS500 terminal server for Appletalk Remote Access
at the moment and after doing the trivial config cannot get a connection to
the server when attempting to dial in.

I have turned appletalk routing on globally using the Appletalk Service
command. I have then specified our appletalk cable range and zone on the
ethernet port of the terminal server, and then enabled ARAP on all phone
lines into the server. We have a TACACS host to authenticate users so I
don't think I need to worry about anything else ! What have I missed ???

Thanks in advance.

--------------------------------------------------------------------------------
Kevin Mark Sherwood
Information Technology Services                E-mail: sherwood@scm.dsto.gov.au
Corporate Information Systems Unit         Message Pgr: +61 8 378 1111 (112753)
Defence Science & Technology Organisation                 Phone: +61 8 259 5715
PO Box 1500, Salisbury, 5108, Australia                     Fax: +61 8 259 5537
--------------------------------------------------------------------------------

-----------[000647][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 1994 12:55:25 GMT
From:      byoder@netcom.com (Brian K. Yoder)
To:        comp.sys.ibm.pc.hardware.networking,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   LAN Doctor Demo via FTP


I any of you are interested, there is now a copy of the LAN Doctor demo 
avaialable via FTP in /pub/USNetworx on ftp.netcom.com.  Previously you 
had to get it from Compuserve or by US Mail.

LAN Doctor is a software-only protocol analyzer that runs on a PC and is 
compatible with any NIC with either a Packet Driver or ODI driver.  The
interface is very intuitive (standard TurboVision interface with pull-down
menus, menus etc.), and it is driven by a C-like language called PDL (Protocol
Description Language) so if you are doing some custom development you can
support your own custom protocol decodes quite easily.  LAN Doctor is a 
commercial product and sells for $795/copy).  For more information contact 
Mark Peter (mpeter@netcom.com) or call US Networx at 800-677-8192.

--Brian
-- 

+------------------+-----------------------------------------------------------+
| Brian K. Yoder   | "The children who know how to think for themselves, spoil |
| byoder@netcom.com|  the harmony of the collective society that is coming,    |
| US Networx, Inc. |  where everyone (would be) interdependent" --John Dewey   |
+------------------+-----------------------------------------------------------+

-----------[000648][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 1994 21:19:26 -0500
From:      realtime@access.digex.net (Real Time Corp.)
To:        comp.protocols.tcp-ip
Subject:   need embedded TCP/IP for 80186/z80

I am looking for an embedded implementation of
TCP/IP for the 80186 or z80 cpus.

I am using a non commercial os.

If I can get the source, how difficult would it be
to modify for a new os? are drivers available
and for which chips?

if you have this product, which os is it attached
to?

If anyone knows of source or image that I can
buy/get, please post or email.

thank you

Naomi Avigdor
realtime@access.digex.net



-----------[000649][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 94 19:45:22 -0400
From:      sysmgr@wittenberg.edu
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: bootp forwarding

In article <CnDEv9.A9@fulcrum.co.uk>, igb@fulcrum.co.uk (Ian G Batten) writes:
> I'd like to have a central bootp server, which some machines would
> access via routers.  My bootp-using machines are NCD and Tandberg X
> terminals, HP printers and B+W NFS-equipped PCen.  I can't make it work,
> and currently have to have /tftpboot NFS mounted onto a machine on each
> subnet, as well as run bootp, because machines tend to tftp their boot
> image from the machine that provides the bootp response.
> 
> My routers --- PCen running PCroute --- claim to support ``Bootp
> Forwarding''.  What does this mean?  Can it help?
> 
> ian

What it means is that the routing software will look for UDP broadcasts on the
appropriate ports (67 &/| 68, I think) and then forward them to some designated
address (possibly a single host or a broadcast to another interface).  The
exact functionality will depend on who wrote the routing code.  We use a Cisco
router that allows us to selectively forward broadcasts to one or more
arbitrary addresses.
                             Cisco router
                           - - - - - - - - -
      bootpd host --------| 1.0        2.0  |------ no bootpd hosts
                          |                 |
      bootpd host --------| 5.0        3.0  |------ no bootpd hosts
                          |                 |
many bootpd hosts --------| 6.0        4.0  |------ no bootpd hosts
                           -----------------

The way Cisco implements it, I can define a "helper address" on the 2.0, 3.0,
and 4.0 interfaces that tell it to forward the broadcasts across to other
subnets.  In this case, the three would forward to the specific host on the
1.0 and 5.0, and possibly just broadcast again on the 6.0 subnet (i.e. 6.255). 
All of my bootpd hosts will then see the request and have the opportunity to
respond.

The BOOTP protocol can deal with packets that are forwarded in this way (I
don't know the details, but I know that it works).  Incidentally, TFTP is
another protocol that is handy to do this with.  Cisco allows a similar
configuration for any UDP-based protocol based on port numbers, so TFTP
requests can be forwarded the same way.  Once the client has received it's
bootp information, it should have enough information to reach the host that has
it's boot image for tftp.  One thing that took me a while to understand is the
way a bootpd determines it's response.  There are 2 parameters, hd and bf, that
can specify a partial or full path to the boot file.  The client can also send
a request for a certain path or file, or both.  Bootpd will generate a response
in this way:

1) If the client specifies no file or path, it will look at the hd and bf
parameters and if the file is accessible via tftp (i.e. world readable), then
it will send that complete path back in the response.

2) If the client specifies a file only, bootpd will combine this file name with
the hd parameter and if the file is available, return that path.

3) If the client specifies a file and path, bootpd will look for that explicit
file and if it is available, respond with it.

4) There are some other variations of this, like combining the host-name with
the file name, etc.  What it boils down to is, if any boot file is
specified by either the bootptab or the client, then the bootpd will only
respond if that file is available for tftp access.

All of these combinations make it a very flexible way to get boot images, once
you understand how they work (and assuming the clients will pay attention to
the path information returned to it).  We currently use bootp to configure
PC's, but not load an image.  As soon as our comm-server manufacturer gets the
bugs out of their boot code, we will be using it (with tftp) to download run
images and configuration files to the servers.

Since routing software is different, you are going to need to dive into the
documentation for PCRoute to see exactly how they do it.  The claim certainly
makes it sound like they support some method of accomplishing the above.


Kevin Yoders
System and Network Manager
Wittenberg University

PS.  The above information on bootp is based on my experience with various Unix
implementations (and 1 VMS implementation).  From my experience, the behaviour
is pretty consistent.  The behaviour of tftp does vary somewhat between
implementations (there's room in the RFC for interpretation).

-----------[000650][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 1994 16:26:26 GMT
From:      nitin@birch.ee.vt.edu (Nitin Mangalvedhe)
To:        comp.protocols.tcp-ip
Subject:   Info. on 2/multiple talk implementations

Could someone please provide the ftp site or books which would give information on
implementation of 2-way/n-way talk facilities. Is the source code for 2-way talk 
be available anywhere?

Thanks,
Nitin

-----------[000651][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 1994 17:41:49 GMT
From:      jrv@truth.mitre.org (Van Zandt)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Products for MS-DOS

vijay@ncsa.uiuc.edu (Vijay Rangarajan) writes:
>In article <764685713snx@bsroso.atr.bso.nl> rob@bsroso.atr.bso.nl (Rob van Son) writes:
>>
>>Can anyone of you give me more information on commercially available 
>>software packages supporting the SLIP functionality in this situation.
>
>Here's one that is free -> slip8250.com, ask archie for the site nearest
>you. If you need help in setting it up, email me.

There are also Trumpet Winsock and etherslip.  Dean Pentcheff's DOS
Internaut Kit (ftp://tbone.biol.scarolina.edu) includes all three.  Can
anybody supply a comparison?

                             - Jim Van Zandt <jrv@mitre.org>


-----------[000652][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 1994 19:39:38 GMT
From:      ddb0248@mcdata.com (David Beal)
To:        comp.protocols.tcp-ip
Subject:   Re: routable protocols

In article <TOM.94Mar28152511@gursey.baruch.cuny.edu> tom@kronecker.baruch.cuny.edu writes:
>Hi, What makes a protocol routable?  I understand IP, appletalk, and
>IPX/SPX are routable protocols but not NetBIEUS.  Why? Any books that
>I can read more about it? Thanks.
>Please reply directly.
>--
>Thomas Wong				We don't eat pork
>tom@gursey.baruch.cuny.edu		But we like raw snake meat
>Voice: 212-447-3047			We are the piglets family
>Fax: 212-447-3076			---The Piglets

Ooh, neat, a philosophical question!

You'll probably get replies that say "protocols at the network
layer are routable, protocols at the data link layer aren't."
That's a good rule of thumb, but doesn't explain the underlying
concepts.

What you're asking is really a question about addressing.
What routable protocols have in common is that you can determine 
the physical location of a node on the network by looking
at its address.  For instance, in IP, the high order portion
of a node's address indicates which "network" (i.e., which
physical ethernet/token ring/serial line etc.) it is connected to.
Routers use the information gleaned from the destination 
address of a frame, plus their knowledge of the network
topology to forward the frame directly toward the destination
node.  Their knowledge of the network topology is gained dynamically
by using a routing protocol, such as RIP, OSPF, IGRP, to
communicate with other routers.  Routers don't have to
guess or learn the locations of end nodes.

In a non-routable protocol, you can't determine the location
of a node solely by knowing its address.  For instance, NetBIOS
is not routable because it employs the LLC (IEEE 802.2) protocol,
which uses MAC (a.k.a., physical) addresses.  Although they can 
often be overridden manually, MAC addresses are burned
into LAN adapters at the factory.  Obviously, the manufacturer
doesn't know which ethernet you're going to connect the board
to when it's built, so a router can't find a node by knowing
its MAC address.

Bridges are commonly used to forward frames containing 
unroutable protocols.  With the exception of token ring
source routing bridges, bridges learn the locations of end 
nodes by watching the frames that the end nodes transmit.
Basically, the bridge thinks "I just saw a frame go by on
this ethernet with a source MAC address of A.  Therefore,
node A must be on that ethernet, or on an ethernet that's
bridged to this one.  If I get a frame addressed to A,
I'll forward it onto this ethernet."  The bridge builds
a table based on the source MAC addresses that it sees.
This is why these are usually referred to as "learning
bridges".  Spanning tree bridges are learning bridges
that talk to each other to avoid forwarding frames
in loops.  Note that while end nodes normally
have to be aware of routers in order to use them, end
nodes can "use" bridges without even knowing the
bridges are there.

The best book on this topic is "Interconnections -
Bridges and Routers" by Radia Perlman.  It's part of
the Addison-Wesley Professional Computing Series.
Perlman works for DEC, and is the inventor of the spanning 
tree bridging algorithm. 

Dave Beal
Advisory Software Engineer
McDATA Corporation
Broomfield, CO 80021

ddb@mcdata.com


-----------[000653][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 1994 16:30:46 +0200
From:      systems@apollo.is.co.za (Systems Publishers)
To:        comp.protocols.tcp-ip
Subject:   Tcp-ip Stacks co-existing with IPX & Netbeui

Hi all,

I'm trying to get tcp-ip, ipx, and netbeui to live together on one machine and
still have more than 5K of conventional memory left. I need to run Windows
for workgroups & chat to a lanmanager server & Novell server while being able
to telnet to the rest of the world - all under windows. Not too difficult a task
surely? 

Any thoughts?

Clayton Nash
clayton@syslab.systems.co.za

-----------[000654][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 1994 21:58:49 GMT
From:      espel@ens.fr (Roger Espel Llima)
To:        comp.client-server,comp.protocols.tcp-ip,comp.unix.programmer,comp.unix.sys5.r4,navy.nswc.misc
Subject:   Re: How To Clea Or Free The Socket?

>>>>> On Mon, 28 Mar 1994 17:10:34 GMT, rchui@tethys.nswc.navy.mil (Raymond Chui) said:
 
>> Hi, My Dare Net Dudes:
>>  
>> I am writting a simple socket client/server program with connection-oriented
>> protocol in TCP. Please refers to W. Richard Stevens's book "Unix Network 
>> Programming" page 261, Figure 6.2.
 
>> Connection-oriented protocol
 
>> myserver.c
 
>> socket()
>>    |
>>    |
>>   bind()
>>     |
>>     |
>> listen()						myclient.c
>>    |							
>>    |							socket()
 accept()						|
>>    |							|
>>    |<-------block until connection from client--------->connect()
>>    |							|
>>  childpid=fork()					|
>>    if(childpid == 0)					|<---while(flag == 0)	
>>      |							|
>>      |							|
>>   read()<----------data request----------------------->write()
>>     |							|
>>     |							|
>>     |							|
>>  write()<----------data reply------------------------->read()
>>  
>>  My application is similar to ftp which that myclient can put files to
>>  myserver and myclient can get files from myserver. By the way I just
>>  modify the client.c/server.c programs in page 284 to page 286. in above's 
>>  book.I am written my own getfile() and putfile() functions.  So far my
>>  programs are doing O.K. its doing what I want. But I still got some
>>  problems with the client socket. When 1st time I get/put a file into the 
>>  socket with no problem at all. But when 2nd time I get/put a file into the
>>  socket, I got some garbage and append the command line into my 2nd file.
>>  This tell me after 1st data transfer, that socket still doesn't know EOF
>>  data file terminate, it still waiting there for more data, or tell the
>>  that socket has not flush clean the buffer ready for next data transfer.
>>  Can someone out there tell me why this happen and how to fix it? Is this
>>  one of FAQ? How do I use fcntl() and/or ioctl() system call(s) to control
>>  the client socket. The only way I can fixed this problem is I put the
>>  while() loop above the connect() system call in myclient.c. But this is
>>  not a good practice(you know why if you familiar ftp). Because you don't
			^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

FTP does open a new socket connection for every file (or directory listing)
transfer! just do

$ ftp
ftp> debug
Debugging on (debug=1)
ftp> open somesite.somewhere.something
     [log in]
ftp> ls
---> PORT 129,199,129,14,11,15
	  ^^^^^^^^^^^^^^^^^^^^

the ftp client opened a server socket at the address 129.199.129.14, port
11*256+15, and is expecting the ftp server to send its data there.

200 PORT command successful.
---> LIST
150  Opening ASCII mode data connection for /bin/ls.
     [listing]
226 Transfer complete


			Roger

-- 
+----------------------------+---------------------------------------------+
|   Roger ESPEL LLIMA	     | 						   |
|   45, rue d'Ulm	     |         email: espel@clipper.ens.fr  	   |
|   75005 PARIS FRANCE	     |						   |
+----------------------------+---------------------------------------------+
|  Esane go farova xerva ga sa dedelamnio era.   (Tilar#go)		   |
|  Confusion will be my epitaph. (K.C.)					   |
+--------------------------------------------------------------------------+

-----------[000655][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 1994 22:12:50 GMT
From:      jeo@apple.com (Eric Okholm)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP window size problem?

In article <Cn4FEt.F3y@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Ran
Atkinson) wrote:
> 
> In article <Cn3Ft5.3uq@gpu.utcc.utoronto.ca> harald@enfm.utcc.utoronto.ca (Harald Koch) writes:
> 
> >However: MacTCP is only advertising a windowsize of 2920 bytes.  The MSS on
> >my Mac is set to 1460, so this is only two segments (which is supposed to
> >translate to two IP packets using an MTU of 1500, the MTU of the modem link).
> >
> >This is *exceedingly* inefficient when operating over long-haul links, since
> >effectively no windowing is being done.
> >
> >My question is: How do I convince MacTCP to use a larger window size? MacTCP
> >Watcher claims that the maximum window size is 64K, but MacTCP never uses it.
> >

The window size MacTCP advertises is based on the amount of memory given to
it by the application (e.g. Fetch, Eudora, Telnet) to use for receive
buffer space.   Users cannot control it directly.   Perhaps you haven't
given the application enough memory.   Try increasing the size of the
application and see if the window size increases as a result.  If it
doesn't, call the application developer or use a different application.


> MacTCP has historically had problems in its TCP Windowing code.  I had
> thought those were fixed beginning with MacTCP version 2.0.4.  In
> fact, I had thought that was the main advantage of using 2.0.4 rather
> than some earlier version.  Given the history, I suspect that MacTCP
> still doesn't have the windowing quite right. 

To the best of my knowledge, MacTCP's windowing code has always worked
fine.   There are no outstanding problem reports on it, nor were there any
when MacTCP 2.0.4 was created.

MacTCP 2.0.4's primary contribution was improvement in retransmission timer
algorithms which seem to help quite a bit for slow-link connections.  
There were other, less significant fixes which are all documented in the
release notes.

-Eric

-----------[000656][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 1994 23:31:12 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Message Broadcast

In article <2n9prb$g6m@t-rex.scs.ag.gov> bioengr@taz.scs.ag.gov (Dennis E. Miyoshi) writes:
> ...
>I have a situation where there are a minimum number (3) of primary servers
>and a maximum number (150+) workstations on a TCP/IP Network.  There
>are times that I need to broadcast messages to the systems regarding
>network upgrades and changes.  My question is:  Is there an easy way to
>broadcast, to all stations, a message?  Even better, Is there a Network
>message of the day program available?

Did the incident in about 1986 where an `rwall` got out of control
and wrote all over the Internet kill rwall?  Do many vendors still
ship it turned on?

If rwall is not available on all 153 machines, then one could have
the motd file on each workstation be a symbolic link to an NFS mounted
file system.  Or similar games with `msg`.

Or just use the most common "message of the day program", netnews
with your own, internal hierarchy.


Vernon Schryver    vjs@rhyolite.com

-----------[000657][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 1994 23:35:16 GMT
From:      aajackso@shadow.lehman.com (Aaron Jackson)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: binded ports


>  [ rebooting mud? What hell this means? ]

Muds often run like mini-kernels so killing the processing and restarting
it is like rebooting the mud.

>  When program closes port (voluntary or involuntary (ie. when it dies)), port
>  is kept reserved certain time. This is done in protocol, so that packets in
>  wire don't go to wrong program (ie. to new program which reopens port). 
 
>  You should wait two minutes before reopening it (or that program should 
>  retried binding of port after that period, if it get error 'address in use'
>  in first time.)
 
>  It's possible disable this safeguard time, but is violation of protocol and
>  therefore begging of problems.

int on = 1;
setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (char*) &on, sizeof(on));
--

-----------[000658][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1994 02:56:49 GMT
From:      ibrezac@vnet.net (ibrezac)
To:        comp.protocols.tcp-ip
Subject:   How to flush socket

Does anyone know how to flush socket besides reading from it until it is
empty?  Something like ioctl FLUSH message to unix streams.
Help would be apprecated.  Please send mail to ibrezac@vnet.net

Igor -

-----------[000659][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1994 03:13:17 GMT
From:      ibrezac@vnet.net (ibrezac)
To:        comp.protocols.tcp-ip
Subject:   TCP Packet efficientcy over WAN

I am new to TCP/IP programming and hopefully I am not posting a dumb
question but here it goes ...
We are useing low speed (2400 baud) WAN and we are receiving records 
(100 byte) from a data terminal.  Would like to kown if anyone 
knows how to, by using socket library, to receive that 100 byte record
in one packet (one read or recv system call).  Can this be done? 
What is happening now is that I have to make several read calls before 
getting the whole record.  End of record delimiter is carraige return.
Any help would be appreciated.  Please send mail to ibrezac@vnet.net.

Igor -


-----------[000660][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 94 09:37:17 CST
From:      anh@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip
Subject:   Ports for Master and Slave Sockets


Hello,


When the server uses accept() it gets back a slave socket. What port does
this slave socket use? The same port as the master socket? I don't want my
"future" sockets to collide with this port.

Thanks for all response.

Anh

-----------[000661][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 94 14:06:41 -0600
From:      "Robert J. Pauwels" <wk02007@worldlink.com>
To:        comp.protocols.tcp-ip
Subject:   Determining IP addresses of remote systems at runtime

To Network Administrators:

I am working on an application that needs to determine the IP address 
of any remote site that is running my application (on my host).  The 
remote locations may be of any type (UNIX, Mac, PCs, etc.).  If a location 
is using Telnet to access my computer to run an application on my 
computer, is it possible for my application to determine the remote 
site's IP address (perhaps through some sort of mapping of the 
pseudo-terminal device name or something).  My host is running SCO UNIX 
on an Intel platform.

Any ideas or suggestions as to how I might accomplish this will be greatly 
appreciated.  Thank you in advance.

Bob Pauwels
wk02007@worldlink.com

-----------[000662][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1994 15:05:50 -0600
From:      ROBERTS@DECUS.CA (Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067)
To:        alt.books.reviews,alt.books.technical,comp.infosystems,comp.protocols.tcp-ip,comp.unix.misc,misc.books.technical,vmsnet.networks.tcp-ip.misc
Subject:   "Practical Internetworking with TCP/IP and UNIX" by Quarterman/Carl-Mitchell

BKPIWTAU.RVW  931130
 
Addison-Wesley Publishing Co.
Kelly Ford, Promotion/Publicity Coordinator
Heather Rignanesi, Marketing, x340, 73171.657@Compuserve.com 
P.O. Box 520
26 Prince Andrew Place
Don Mills, Ontario
M3C 2T8
416-447-5101
fax: 416-443-0948
or
Tiffany Moore, Publicity  tiffanym@aw.com
Bob Donegon  bobd@aw.com
John Wait, Editor, Corporate and Professional Publishing johnw@aw.com
Tom Stone, Editor, Higher Education Division  tomsto@aw.com
1 Jacob Way
Reading, MA   01867-9984
800-822-6339
617-944-3700
Fax: (617) 944-7273
5851 Guion Road
Indianapolis, IN   46254
800-447-2226
"Practical Internetworking with TCP/IP and UNIX", Carl-Mitchell/Quarterman,
      0-201-58629-0, 1993
tic@tic.com smoot@tic.com
 
Another good explanatory title.  For those who need to connect a UNIX machine
to the Internet, this is a one-stop reference for most of the basic
necessities.
 
The book starts with a historical and conceptual backgrounder on the Internet. 
This first section also gives technical and even some programming details on
the basic IP, TCP and UDP protocols.  The technical level is advanced, but
fully explained for the perseverent newcomer.
 
Part two is the practical side.  Four chapters give the basics of the setup,
email, sendmail and other services.  For a standard system, this could be
almost all you need to get running.
 
Part three covers advanced topics such as the integration of microcomputers,
network management and debugging.  It is nice to see a work that addresses the
issues of micros, which are ubiquitous in the usual workplace.  It is equally
nice to see a practical approach, such as the suggestion to use terminal
emulation if such will fill the bill.  (It is amusing to see a mild tendency
towards UNIX chauvinism in such subtle ways as the use of the UNIX default
lower case filename convention applied to the case insensitive/upper case MS-
DOS file system.)
 
Appendices give tips on the use of various Internet services as well as some
useful utility program listings.
 
As always with Quarterman's writings, there are extensive biliographic and
reference listings.
 
copyright Robert M. Slade, 1993   BKPIWTAU.RVW  931130
Permission granted to distribute with unedited copies of the Digest
======================
DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
DECUS Symposium '94, Vancouver, BC, Mar 1-3, 1994, contact: rulag@decus.ca

-----------[000663][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 1994 05:07:10 GMT
From:      bwolfe@rpslmc.edu (Brian A. Wolfe)
To:        comp.protocols.tcp-ip
Subject:   Internet Providers with T3 access to NSFNet/CIXnet

Is anyone aware of any IP service providers with T3  access to the 
NSFNet or CIXnet backbone besides ANS? 

any pointers appreciated,

Brian


-- 
-------------------------------------------------------------------------
Brian Wolfe						
Associate Director
Dept of Diagnostic Radiology and Nuclear Medicine

-----------[000664][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1994 14:16:39 -0500
From:      jcarroll@panix.com (Jim Carroll)
To:        comp.protocols.tcp-ip
Subject:   SLIP Server

We would like to have a working SLIP server. A device that would allow
multiple SLIP ports, and put this traffic onto an ethernet -- sort of a 
SLIP bridge router.

We have tried a number of products that claimed to do this, but each of them
has had numerous bugs. So many, as a matter of fact, that the solution was
completely unacceptable.

We are pretty desparate for a solution, as we have now begun providing our
service, and are experiencing quite alot of down time.

If anyone has any experience with this, please email.

Jim C.

-- 
************************************************
* Infinite Diversity, in Infinite Combinations *
************************************************


-----------[000665][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 1994 09:30:33 GMT
From:      galileoswieng@cix.compulink.co.uk ("Galileo International")
To:        comp.protocols.tcp-ip
Subject:   BOOTP

Can anyone explain how bootp works across gateways?

Regards
Antony

-----------[000666][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1994 09:54:06 GMT
From:      kottos@cti.gr (Kottos Kostas)
To:        comp.protocols.tcp-ip
Subject:   Wanted : Last version of telnet for Unix


Hi netters,

   I'm looking for the last version of telnet ( both telnetd and client) for 
 Unix (not NCSA telnet or tn please). I would appreciate a good answer.
 Please respond in this list or by e-mail to: kottos@cti.gr

                  
                                                          Kostas


-----------[000667][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 1994 10:07:06 GMT
From:      skaamjm@ucl.ac.uk (Matthew Moore)
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA with BOOTP over routers

does NCSA telnet work without BOOTP (ie with a configured in IP address)?
(I am a little surprised by interupt=0, ioaddr=0)

My understanding is that bootp is supposed on the LAN only, and if you
want your router to pass BOOTP broadcasts, you need to configure it
accordingly.

heye@asavax.asa.org writes:

>Can anyone help? We are trying to impliment NCSA Telnet with a bootp server
>running from our Vax over multiple routers. We are able to run bootp using LWP
>over the routers, but when we run NCSA the machine hangs on reading the
>configuration file. We are running the latest NCSA 2.3.07 (Put wrong version on
>last message) and the latest ODIPKT driver. Here is a copy of my CONFIG.TEL 
>file:
>termtype ="vt100"
>myip=BOOTP
>netmask=255.255.255.0
>hardware=packet
>interupt=0
>ioaddr=0
>tek=yes
>video=ega
>bios=no
>ftp=yes
>rcp=yes
>capfile="telcap"
>keyfile="keymap.tel"
>domain="asa.org"
>domainretry=4
>arptime=120
>beep=yes
>concolor=020170
>broadcast=255.255.255.0
>windowgoaway=yes
>autoscroll=no
>services="services.tel"
>host=asavax.asa.org
>hostip=192.150.224.50
>scrollback=400
>erase=backspace
>vtwrap=yes
>crmap=4.3BSDCRNUL
>contime=60
>retrans=12
>mtu=512
>maxseg=512
>rwin=512
>name=cisco; hostip=192.150.224.10 gateway=1
>name=asavax; hostip=192.1150.224.50 nameserver=1
 
>If anyone could shed some light on this it would be greatly appreciated. 
 
>Also I was able to get NCSA working using RARP over the one router but since
>that's non-routable it's not an option for us.
 
>Thanks,
 
>Steve Heye
>Computer Field Engineer
>Antarctic Support Associates


-----------[000668][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 94 15:17:54
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: routable protocols

> The best book on this topic is "Interconnections -
> Bridges and Routers" by Radia Perlman.  It's part of
> the Addison-Wesley Professional Computing Series.
> Perlman works for DEC, and is the inventor of the spanning 
> tree bridging algorithm. 

Last I heard was that she had moved to Novell. But I agree,
it's a very good (and readable!) book.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000669][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 1994 10:45:00 GMT
From:      ulfalm@ulfs.sto.fdata.se (Ulf Almehed)
To:        comp.protocols.tcp-ip
Subject:   Re: VT100/TN3270 in one?

Winlink V rel 2.1 from Comma offers both VT100/VT220 and TN3270. 
I don't know if it's available outside northen Europe though.

-----------[000670][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 1994 12:12:31 GMT
From:      klos@mv.mv.com (Patrick Klos)
To:        comp.sys.ibm.pc.hardware.networking,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PacketView Demo via FTP

In article <byoderCnFFwD.F9z@netcom.com>,
Brian K. Yoder <byoder@netcom.com> wrote:
>
>I any of you are interested, there is now a copy of the LAN Doctor demo 
>avaialable via FTP in /pub/USNetworx on ftp.netcom.com.  Previously you 
>had to get it from Compuserve or by US Mail.
>
>LAN Doctor is (etc...)

I probably shouldn't be doing this (two wrongs don't make a right), but in
all fairness, if you're going to use the net for unsolicited advertising, I'm
gonna make sure the netters of the world are aware of the alternatives.

We (Klos Technologies, Inc.) have a product called PacketView that goes for
$299 and allows your PC to capture and decode network traffic on ethernet,
token-ring and ARCNET networks.  PacketView supports IPX/SPX/NCP, TCP/UDP/IP,
VINES IP and a few other protocols.  It has capture and display filtering,
good symbolic support, and allows you to write your own custom protocol
decoders (should the need arise).  A demo version of PacketView is available
on our BBS by calling (603) 429-0032 or via anonymous FTP at mv.mv.com in
the file pub/users/klos/pvdemo.zip.

Feel free to call or email if you have any additional questions.

Sincerely,

Patrick Klos

P.S. In fairness to other (who may want to make their own followup postings),
     other products in this area include LANDecoder from Triticom, LANWatch
     from FTP Software, LANalyzer from Novell, Snooper and EtherProbe from
     General Software, and (for those on the Apple side of the fence)
     EtherPeek from AG Group.  If there are others, I'm sorry, I didn't
     leave you out intentionally.
-- 
============================================================================
    Patrick Klos                           Internet: klos@mv.mv.com
    Klos Technologies, Inc.                Voice: (603) 424-8300
    604 Daniel Webster Highway             FAX:   (603) 424-9300
    Merrimack, New Hampshire  03054        BBS:   (603) 429-0032
==========See us in Las Vegas at NETWORLD+INTEROP 94 booth 5290!============

-----------[000671][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 1994 22:17:40 -0500
From:      Wilson Swee <ws8n+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   using mactcp....

Is there any helpful documentation as to how to establish a tcp/ip
connection, as well as doing send/recvs? Also, what kind of libraries or
tools (if any) do I need and where is it available?

Thanks,
Wilson


-----------[000672][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 1994 14:03:52 GMT
From:      Jim Spink
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   VT100/TN3270 in one?

In article <1994Mar29.111039.1@nebula> hitcmap@nebula.syscon.hii.com writes:
>Hello!
>
>I was wondering if there exists a TCP/IP client stack for DOS-based PC's that
>offers Telnet for both standard emulation (ie VT class) and also covers TN3270
>class emulation (ie 3278) in one package?  This would eliminate having each PC
>loaded with two packages for example Novell's LAN Workplace for DOS and
>Novell's TN3270 product.  We want to offer these PC users access to both a
>RS/6000 running AIX and to a IBM 3090 host running TCP/IP, but the apps would
>be written to a 3278 terminal type.
>
>If anyone knows of such a package, please send a note with any comments.
>
>Thanks and best regards. . . .  Mike
>
>
>mpassineau@hii.com
>
>class emual
>

IBM's TCP/IP for DOS version 2.1.1 product can do what
you need for $230 per license.  In particular
it has both a DOS TELNET and a Window GUI Telnet
that has bo