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:      [email protected] (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: [email protected]

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 01:49:38 GMT
From:      [email protected] (Alfred Longyear)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP/PPP FAQ location?
[email protected] (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:      [email protected] (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE question
[email protected] (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
[email protected] 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:      [email protected] (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 <[email protected]> [email protected] (Peter Welsby) writes:
>In article <[email protected]> [email protected] (Earl H Kinmonth) writes:
>>From: [email protected] (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                                [email protected]    #
# Sacramento Public Access UNIX                [email protected] #  
# "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:      [email protected] (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 <[email protected]> [email protected] 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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 17:22:00 -0800
From:      [email protected] (Lon Stowell)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] (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 <[email protected]>
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know a TN5250 client for PC or Mac ???

In article <[email protected]>, <[email protected]> writes:
(Gerry Winsor) writes:
> >David Sims ([email protected]) 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 <[email protected]>


-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 94 12:44:19 -0400
From:      [email protected]
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:      [email protected] (George Edmond Eddy)
To:        comp.protocols.tcp-ip
Subject:   Re: cluster mbufs
jagane[email protected] (Jagane D Sundar) writes:

>In article <[email protected]> [email protected] (Jim Reid) writes:
>>In article <[email protected]> [email protected] (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

[email protected]

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 16:43:27 -0500
From:      [email protected] (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
   [email protected]

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 14:48:59 GMT
From:      [email protected] (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
[email protected]


--
Yan Xiang
[email protected]

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1994 14:56:35 GMT
From:      [email protected] (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
[email protected]


--
   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:      [email protected] (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
				[email protected]
 				[email protected]

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 17:12:38 GMT
From:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 Address resolution for TCP/IP networks.
In article <[email protected]> [email protected] (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 ([email protected])
>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:      [email protected] (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 <[email protected]>

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 17:49:57 +0000
From:      [email protected] (Alistair Bell)
To:        comp.protocols.tcp-ip
Subject:   Re: ? PC-based TCP/IP Decode Analyzer?
In article <[email protected]> [email protected] 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:      [email protected] (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
[email protected]

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 94 23:10:08
From:      [email protected] (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: [email protected], [email protected]

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 18:25:50 GMT
From:      [email protected] (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: SYN-RECEIVED-->CLOSE-WAIT
In article <[email protected]> [email protected] 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
						[email protected]

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Mar 1994 18:39:50 GMT
From:      [email protected] (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: [email protected]
National Science Foundation               BITNET: [email protected]
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:      [email protected] (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
[email protected]


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 94 19:58:28 GMT
From:      [email protected] (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  [email protected]  
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:      [email protected] (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:      [email protected] (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
[email protected]

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 94 22:08:58 GMT
From:      [email protected] (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: [email protected]        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:      [email protected] (Ian Phillipps)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]>,
gidewall,kenton c <[email protected]> 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:      [email protected] (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: [email protected],
	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=<[email protected]>
  Mar  1 20:47:31 gradient sendmail[27501]: AA27501:
	from=<[email protected]>, 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.
	[email protected]

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 09:43:14
From:      [email protected] (Bruce Grunewald)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know a TN5250 client for PC or Mac ???
In article <[email protected]> [email protected] (Ed Maioriello) writes:
>From: [email protected] (Ed Maioriello)
>Subject: Re: Anyone know a TN5250 client for PC or Mac ???
>Date: 22 Feb 1994 13:29:48 GMT
 
>In article <[email protected]> [email protected] (Gerry Winsor) writes:
>>David Sims ([email protected]) 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 <[email protected]>
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 [email protected], 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:      [email protected] (Amit Tilak Mehta)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Info
Ann Toh Hwee Choo ([email protected]) 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.
([email protected])

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 94 07:57:38 GMT
From:      [email protected] (Jim Martin)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast IP
[email protected] (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: [email protected]
	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:      [email protected] (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:      [email protected] (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
[email protected] (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: [email protected]  |
+------------------------------------+


-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 09:46:46 GMT
From:      [email protected] (Luis VEGA)
To:        comp.protocols.tcp-ip
Subject:   Re: FAQ Requested
In article <[email protected]>, [email protected] (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:      [email protected] (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:      [email protected] (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
[email protected]

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Mar 1994 18:28:51
From:      [email protected]  (Frances K. Selkirk)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] (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                                        [email protected]
FTP Software, Inc.        Technical Support            (800) 382-4FTP
---------------------------------------------------------------------
Get our support newsletter from       | FTP support - [email protected]
ftp.ftp.com or our BBS (508-659-6240) | FTP sales   -    [email protected]


-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 22:48:05 -0500
From:      [email protected] (Aleksandar Matijaca)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP with OS2?
In article <[email protected]>,
Chester <[email protected]> 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
>    [email protected]
>


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
[email protected]
Toronto, Ontario Canada



-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 23:10:33 -0500
From:      [email protected] (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 <[email protected]>,
Lawrence Levin <[email protected]> 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
[email protected]
Toronto, Ontario Canada



-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 14:50:49 GMT
From:      [email protected] (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:      [email protected] (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

	[email protected]

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

-- 

				-- Arif Diwan ([email protected])
						617/873-6274

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 15:43:11 GMT
From:      [email protected] (Arif Diwan)
To:        comp.protocols.tcp-ip
Subject:   Re: Hardware fault on Wellfleet BLN
In article <[email protected]>, [email protected] (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 ([email protected])
						617/873-6274

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 15:56:55 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (Arif Diwan)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Load balancing on multiple paths
In article <[email protected]>, [email protected] (Tony Li) writes:
 In article <[email protected]> [email protected] (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 ([email protected])
						617/873-6274

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 17:21:35 GMT
From:      [email protected] (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
[email protected]

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 17:57:12 GMT
From:      [email protected] (Casper H.S. Dik)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: Solaris 2.3 tcp problems
[email protected] (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: [email protected],
>	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:      [email protected] (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, [email protected] | ``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:      [email protected] (Carlos Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: How does one apply for a tcp/ip address ?
Dan Angst ([email protected]) wrote:
: [email protected] ([email protected]) 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 [email protected]
The correct number is: (800)444-4345

8^)-carlos

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

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 20:08:00 GMT
From:      [email protected] (Dan Swartzendruber)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]>, [email protected] (Adam Goodfellow) writes:
> [email protected] (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: [email protected]  |
> +------------------------------------+
> 
 
-- 

#include <std_disclaimer.h>

Dan S.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 1994 20:50:54 GMT
From:      [email protected] (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          |[email protected]_|_(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 <[email protected]>
To:        comp.protocols.tcp-ip
Subject:   Re: How do multi-homed hosts choose the interface?
In article <[email protected]> Christian Huitema,
[email protected] 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:      [email protected] (Mark Evans)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
Ian Phillipps ([email protected]) 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:      [email protected] (Mark Evans)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
Adam Goodfellow ([email protected]) wrote:
: [email protected] (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:      [email protected] (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: ? PC-based TCP/IP Decode Analyzer?
In article <[email protected]>,
Alistair Bell <[email protected]> wrote:
>In article <2ks[email protected]> [email protected] 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:      [email protected] (Ian Phillipps)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]>,
Mark Evans <[email protected]> wrote:
>Adam Goodfellow ([email protected]) wrote:
>: [email protected] (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:      [email protected] (Dave Mitton)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PCNFS over Token Ring (Source Route Bridging)

In article <[email protected]>, [email protected] (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,					[email protected]
Token Ring Program, Networks Engineering, Digital Equipment Corp.


-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1994 23:45:12 GMT
From:      [email protected] (John Gottschalk)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted : Statistics on X.25 and TCP/IP
Hiren Chandiramani ([email protected]) 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, 				[email protected]
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:      [email protected] (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
[email protected] (Peter Welsby) writes:

>In article <[email protected]> [email protected] (Earl H Kinmonth) writes:
>>From: [email protected] (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                                         [email protected]
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:      [email protected] (Martin Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Avoid/Recover from "Bus Error"
[email protected] (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                                         [email protected]
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:      [email protected] (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,comp.unix.bsd,comp.unix.ultrix
Subject:   Re: How do multi-homed hosts choose the interface?
[email protected] (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   [email protected]
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:      [email protected] (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
[email protected] (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:      [email protected] (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          |[email protected]_|_(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:      [email protected] (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:      [email protected] (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 <[email protected]>,
[email protected] (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 -- [email protected] -- [email protected]
Author of the Internet Starter Kit for Macintosh -- [email protected]

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 94 18:52:13 -0500
From:      [email protected] (James Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: all-one-bits versus all-zero-bits in broadcasting
In article <[email protected]>, [email protected] (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   [email protected]   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:      [email protected] (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)     [email protected]    FAX: +49-30-386 28321

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 94 20:14:16 MST
From:      kruckenb%[email protected] (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:

[email protected] (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:      [email protected] (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              [email protected]


-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 14:50:14 GMT
From:      [email protected] (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 [email protected] or [email protected]
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)
[email protected] (e-mail)
[email protected] (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:      [email protected] (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:      [email protected] (Mark Reardon)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]>, [email protected] (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
|>    [email protected]

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: [email protected], attmail!tridom!mwr

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 16:56:17 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] (Mark Evans) writes:
>Ian Phillipps ([email protected]) 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    [email protected]

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 17:05:28 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?
In article <[email protected]> [email protected] (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    [email protected]

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

In article <[email protected]> [email protected] 
(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), <[email protected]>
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:      [email protected] (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 [email protected]

	Thanks in advance.

	Bye,Gri

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 18:38:44 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
In article <[email protected]> [email protected] (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    [email protected]

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 22:55:56 GMT
From:      [email protected] (E.P. Pylko)
To:        comp.protocols.tcp-ip
Subject:   Re: PC/NFS and DNS
In article <[email protected]> [email protected] (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.
[email protected]              Average minds talk about things.
[email protected]                    Simple minds talk about people.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Mar 1994 23:40:08 GMT
From:      [email protected] (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 <[email protected]> [email protected] (Tom Fitzgerald) writes:
>[email protected] (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   [email protected]
>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:      [email protected]
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" <[email protected]>
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.
[email protected]
Phone: (415)962-7140   fax:(415)969-5547

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 00:19:50 GMT
From:      [email protected] (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 [email protected]
Thanks in advance. dd!


-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 00:37:52 GMT
From:      [email protected] (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:      [email protected] (Aleksandar Matijaca)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]>,
Adam Goodfellow <[email protected]> wrote:
>[email protected] (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: [email protected]  |
>+------------------------------------+
>

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:      [email protected] (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				[email protected]
Systems & Network Analyst		[email protected]
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:      [email protected] (Simon Hackett)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
[email protected] (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
	[email protected]

-- 
      Simon Hackett,  Internode Systems Pty Ltd, Adelaide, Australia
      [email protected]   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 <[email protected]>
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
[email protected] (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:      [email protected] (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: Microsoft TCP/IP (vs. NetBIOS)
[email protected] (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: [email protected] (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:      [email protected] (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        |
|     [email protected]      ||            down   |
\----------------------------------------------------/\-------------------/


-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 11:06:38 GMT
From:      [email protected] (Harald Dunkel)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: Solaris 2.3 tcp problems
[email protected] (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: [email protected],
>	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 | [email protected]  |  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:      [email protected] (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: [email protected], [email protected]

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:      [email protected] (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:      [email protected] (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:      [email protected] (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
[email protected] (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 [email protected]

Roger


-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 16:18:56 GMT
From:      [email protected] (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
[email protected] (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
[email protected]

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 16:33:27 GMT
From:      [email protected] (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:      [email protected] (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: [email protected], [email protected]

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 16:52:08 GMT
From:      [email protected] (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: [email protected] (or I can
forward replies otherwise).

Thanks!



-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 17:02:32 GMT
From:      [email protected]
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
[email protected]




-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 17:33:49 GMT
From:      [email protected] (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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: all-one-bits versus all-zero-bits in broadcasting
James Harvey ([email protected]) wrote:
: In article <[email protected]>, [email protected] (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:      [email protected] (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 [[email protected]]
"Origami: a creative approach to paperwork"

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 19:31:07 +0000
From:      [email protected] (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
[email protected] (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: [email protected] |
+------------------------------------+


-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 20:52:51 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 21:01:47 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: internet address forms
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Mar 1994 21:29:35 GMT
From:      [email protected] (Jim Shankland)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?
In article <[email protected]> [email protected] (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:      [email protected] (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:      [email protected] (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] (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    [email protected]

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 94 22:15:30 GMT
From:      [email protected] (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

[email protected]
(708) 317 3493



-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 1994 22:45:43 GMT
From:      [email protected] (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:      [email protected] (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP and Multiple subnets on 1 Enet

In article <[email protected]>, [email protected] 
(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), <[email protected]>
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:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options
In article <[email protected]> [email protected] (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    [email protected]

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 01:24:08 GMT
From:      [email protected] (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

[email protected]

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1994 01:46:45 GMT
From:      [email protected] (Tom Walsh)
To:        comp.protocols.tcp-ip
Subject:   Re: Why does a host arp for itself?
In article [email protected], [email protected] (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: [email protected]
				  [email protected]
---------*----------*----------*---------*---------*---------*



-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 02:11:09 GMT
From:      [email protected] (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: internet address forms
>> a.b b< 256*256*256 also valid..?

[email protected] (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   [email protected]
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:      [email protected] (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] 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    [email protected]

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 03:23:11 GMT
From:      [email protected] (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?
[email protected] (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   [email protected]
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:      [email protected] (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?
[email protected] (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:      [email protected] (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?
In article <[email protected]> [email protected] (Jim Shankland) writes:
    In article <[email protected]> [email protected]
	(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:      [email protected] (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
In article <[email protected]> [email protected] (Vernon Schryver) writes:
>In article <[email protected]> [email protected] (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    [email protected]

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:      [email protected] (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?
In article <[email protected]>, Tom Fitzgerald <[email protected]> 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:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: internet address forms
In article <[email protected]> [email protected] (Tom Fitzgerald) writes:
>[email protected] (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    [email protected]

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 1994 18:28:59 GMT
From:      [email protected] (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:      [email protected] (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  ([email protected])

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Mar 1994 22:46:48 GMT
From:      [email protected] (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
-- 
[email protected]
-bikram dhaliwal

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1994 10:26:28 -0500
From:      [email protected] (Aleksandar Matijaca)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone know a TN5250 client for PC or Mac ???
In article <[email protected]>,
Bruce Grunewald <[email protected]> wrote:
>In article <[email protected]> [email protected] (Ed Maioriello) writes:
>>From: [email protected] (Ed Maioriello)
>>Subject: Re: Anyone know a TN5250 client for PC or Mac ???
>>Date: 22 Feb 1994 13:29:48 GMT
 
>>In article <[email protected]> [email protected] (Gerry Winsor) writes:
>>>David Sims ([email protected]) 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:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
In article <[email protected]> [email protected] (Frank Lofaro) writes:
>In article <[email protected]> [email protected] (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    [email protected]

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1994 15:35:29 -0500
From:      [email protected] (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:      [email protected] (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?

-- 
[email protected]
-bikram dhaliwal

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 09:33:24 GMT
From:      [email protected] (Dhaliwal Bikram Singh)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping, eth0, WD8023, 99pl15, crashes: SOLUTION!
In article <[email protected]> [email protected] (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?
>
>-- 
>[email protected]
>-bikram dhaliwal


-- 
[email protected]
-bikram dhaliwal

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 13:15:20 +0000
From:      [email protected] (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
[email protected] (Vernon Schryver) writes:

> In article <[email protected]> [email protected] 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    [email protected]

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: [email protected] |
+------------------------------------+


-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 15:26:52 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP and Multiple subnets on 1 Enet
In article <[email protected]> [email protected] 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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Mar 1994 21:11:52 GMT
From:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Transparent TCP/IP over X.25
In article <[email protected]> [email protected] (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
[email protected]





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

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

Thanks!

Olof Haegerlund

Internet: [email protected]
CompuServe: [email protected]



-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 00:09:48 GMT
From:      [email protected] (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?
[email protected] (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   [email protected]
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:      [email protected] (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:      [email protected] (Lon Stowell)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] 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:      [email protected] (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:      [email protected] (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

[email protected]




-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 94 04:04:13 GMT
From:      [email protected] (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:      [email protected] (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
[email protected]

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 16:49:35 -0600
From:      [email protected] (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:      [email protected] (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:      [email protected] (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
 [email protected]  | Cadarache, France
 -----------------------------------------------------------------




-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1994 10:38:55 GMT
From:      [email protected] (Christian Huitema)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]>, [email protected] (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:      [email protected] (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.

--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
[email protected], Department of Complain Science
Chung-Hua Polytechnic Institute =|8-) <Fat Dragon>
300, Hsin-Chu, Taiwan ... eMail:[email protected]

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 13:29:44 GMT
From:      [email protected] (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:      [email protected] (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1006
In article <[email protected]>, Olof Haegerlund <[email protected]> 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:      [email protected] (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
[email protected]



-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 94 16:20:11 GMT
From:      [email protected] (David Breneman)
To:        comp.protocols.tcp-ip
Subject:   Re: What is TCP/IP?
Robinson David Paul Mr ([email protected]) 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: [email protected]
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:      [email protected] (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: [email protected]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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:      [email protected] (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 <[email protected]>
> 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 <[email protected]>

> 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 <[email protected]>

> 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 [email protected] 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 <[email protected]>

> 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: [email protected] (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: [email protected] (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 [email protected] 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.

	[email protected]
	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: [email protected] (Chuck Smoko - E81)
Subject: Re: Multiple IP Addresses on the Same Interface
Message-ID: <[email protected]>
Sender: [email protected]
Organization: Naval Surface Warfare Center
References: <[email protected]>
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: [email protected] (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 <[email protected]> [email protected] (Hitoaki Sakamoto) writes:
>    >In article <[email protected]> [email protected] (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 
> [email protected] // [email protected] // ...!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: [email protected]
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:      [email protected] (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.
[email protected]

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 1994 18:38:44 GMT
From:      [email protected] (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 - [email protected]
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:      [email protected] (Louis Chu)
To:        comp.protocols.tcp-ip
Subject:   Re: Steven's new book!
In article <[email protected]>,
Samson Chen <[email protected]> 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.
>
>--
>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>[email protected], Department of Complain Science
>Chung-Hua Polytechnic Institute =|8-) <Fat Dragon>
>300, Hsin-Chu, Taiwan ... eMail:[email protected]

 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......"
[email protected]   --or--   uunet.ca!obc!lchu      |

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 94 19:23:08 GMT
From:      [email protected] (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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
Vernon Schryver ([email protected]) 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:      [email protected] (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:      [email protected] (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS over WAN?
In article <[email protected]> [email protected] (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:      [email protected] (Barry Flanagan)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q]: Best 20+ line terminal server for TCP/IP, ARA?
Alex Curylo ([email protected]) 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.

[email protected] 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:      [email protected] (Berry Kercheval)
To:        comp.protocols.tcp-ip
Subject:   Re: What is TCP/IP?
[email protected] (David Breneman) writes:

>Robinson David Paul Mr ([email protected]) 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 :: [email protected] 
"...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:      [email protected] (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
[email protected] (Lon Stowell) writes:

> In article <[email protected]> [email protected] 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: [email protected] |
+------------------------------------+


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:57:28 -0800
From:      [email protected] (Lon Stowell)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] 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:      [email protected] (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
In article <[email protected]> [email protected] (Mark Evans) writes:
>Vernon Schryver ([email protected]) 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:      [email protected] (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

-- 
 
[email protected]| 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:      [email protected] (John Miezitis)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Is there an OSPF RFC ?
In article <[email protected]> [email protected] (jaleel ihsan) writes:
>From: [email protected] (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:      [email protected] (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?
In article <[email protected]>,
 <[email protected]> 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:      [email protected]  (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you choose a port number for an application?
In Article <[email protected]> "[email protected] (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:      [email protected]  (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1006
In Article <[email protected]> "[email protected] (Olof Haegerlund)" says:
> 
> Hi! 
> Does anyone Know where I can get RFC1006??
> 
> Thanks!
> 
> Olof Haegerlund
> 
> Internet: [email protected]
> CompuServe: [email protected]
> 
> 
> 
Try, merit.edu
Mike.

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 10:12:48 GMT
From:      [email protected] (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:      [email protected] (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.

--
   _
  /_|                                    [email protected]
/   |rsenio Reis                         [email protected]  
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:      [email protected] (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST
[email protected] (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:      [email protected] (Samson Chen)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS over WAN?
Frank Lofaro ([email protected]) wrote:
: In article <[email protected]> [email protected] (Phil Perucci) writes:
: >Does NFS *always* work over the Internet?  I know it is slow...
: >                                           -----------------

	BSD4.4 can make NFS work under TCP protocol.

--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
[email protected], Department of Complain Science
Chung-Hua Polytechnic Institute =|8-) <Fat Dragon>
300, Hsin-Chu, Taiwan ... eMail:[email protected]

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 1994 12:03:57 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] ("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:      [email protected] (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: SUMMARY: Any intrinsic perfomance limit with IP protocol ?
Jochen Kornitzky <[email protected]> wrote:
}And here's what the net answered (thanks to all):
 ...
}From: Peter Desnoyers <[email protected]>
 
}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:      [email protected] (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!
[email protected]

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 12:28:00 +0100
From:      [email protected] (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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

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: [email protected] (Bruce Barnett)
[ a longish forwarded story (nice to have)

    From: Van Jacobson <[email protected]>
    To: [email protected]
    Subject: saturating an ethernet from 1000 miles away
    Date: Wed, 05 Jun 91 07:47:44 PDT
]


*********

From: [email protected] (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 <[email protected]>

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: [email protected] (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: [email protected] (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: [email protected] (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: [email protected] (Craig Partridge)

[email protected] (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: [email protected] (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: [email protected] (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: [email protected] (Tom Fitzgerald)

[email protected] (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)     [email protected]    FAX: +49-30-386 28321

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      08 Mar 1994 14:20:15 GMT
From:      [email protected] (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					[email protected]

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 02:32:53 -0600
From:      [email protected] (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
[email protected]



-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 17:11:38 GMT
From:      [email protected] (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:      [email protected] (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST
[email protected] (Arnt Gulbrandsen) writes:

>In article <[email protected]>,
>Casper H.S. Dik <[email protected]> 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 <[email protected]>
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> Christian Huitema,
[email protected] 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:      [email protected] (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 [email protected]
			Ron Watkins
--
Ron Watkins    [[email protected]]    /            /~~~~)     /
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:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
In article <[email protected]> [email protected] (Mark Evans) writes:
>Vernon Schryver ([email protected]) 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:      [email protected] (Peter Dordal)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?
In article <[email protected]>, [email protected] (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:      [email protected]
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:      [email protected] (Curt Sampson)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST
[email protected] (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  [email protected]
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:      [email protected] (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 <[email protected]>,
  [email protected] (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: [email protected]
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:      [email protected] (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST
In article <[email protected]>,
Casper H.S. Dik <[email protected]> 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:      [email protected] (Mark Evans)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
Dan Lacey ([email protected]) wrote:
: In article <[email protected]> Christian Huitema,
: [email protected] 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:      [email protected] (J.P. Kuypers)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address
In article <[email protected]>, [email protected] (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: [email protected]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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:      [email protected] (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST
In article <[email protected]>, [email protected] (Curt Sampson) writes:
| [email protected] (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
				[email protected]*

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1994 22:29:10 GMT
From:      [email protected] (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST
Casper H.S. Dik <[email protected]> wrote:
}[email protected] (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:      [email protected] (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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 00:35:58 GMT
From:      [email protected] (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                         [email protected] (E-mail)
-----------------------------------------------------------------------------

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 02:04:26 GMT
From:      [email protected] (Thomas Skibo)
To:        comp.protocols.tcp-ip
Subject:   Re: Any intrinsic perfomance limit with IP protocol ?
In article <[email protected]>, [email protected] (Peter Dordal) writes:
|> In article <[email protected]>, [email protected] (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
[email protected]		Silicon Graphics, Inc.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 94 03:43:32 GMT
From:      [email protected] (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:      [email protected] (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: structure of packets, any idea?
In article <[email protected]>,
Mathieu Claude Hans <[email protected]> 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:      [email protected] (Curt Sampson)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
[email protected] (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  [email protected]
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:      [email protected] (joshua geller)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?
In article <[email protected]> [email protected] (David Barr) 
writes:
>    <[email protected]> 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:      [email protected] (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: Transparent TCP/IP over X.25
[email protected] (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: [email protected] (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:      [email protected] (Dave Cartwright)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?
In article <[email protected]>,
[email protected] 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: [email protected]                       |
|         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:      [email protected] (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: [email protected]
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:      [email protected] (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
[email protected]

 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/ Jack Christenson    AT&T GIS Network Products Division \
\ [email protected]                        /
 \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 11:21:01 GMT
From:      [email protected] (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
                                              [email protected]



-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 12:13:32 +0000
From:      [email protected] (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: [email protected]

I need this too please.


-- 
GeoffC

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 13:01:09 GMT
From:      [email protected] (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: [email protected]       |
| 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:      [email protected] (steve johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address
In article <[email protected]>, [email protected]
(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: [email protected]
> 
> 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:      [email protected] (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:      [email protected] (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:      [email protected] (Bob Sutterfield)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] (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
[email protected]                                   +1 614 459 5054 (FAX)

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 14:36:20 GMT
From:      [email protected] (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on client-server implementation ..
Sandeep Kamat ([email protected]) 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:      [email protected] (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway
Thierry ROLLAND ([email protected]) 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:      [email protected] (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:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
In article <1994Mar[email protected]> [email protected] (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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages
Galileo International ([email protected]) 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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?
Dave Cartwright ([email protected]) 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:      [email protected] (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
[email protected]

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 19:07:59 GMT
From:      [email protected] (Len Fishler)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages
In article <[email protected]>, [email protected] (Mark Evans) writes:
>Galileo International ([email protected]) 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 -
[email protected]

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 19:09:48 GMT
From:      [email protected] (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: [email protected]      |
| 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: [email protected]      |
| Ph: (205)721-1288  FAX: (205)837-9682  |
+========================================+

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 19:21:36 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (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: 	[email protected]

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 19:46:53 GMT
From:      [email protected] (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
[email protected]


-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 1994 19:49:59 GMT
From:      [email protected] (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 <[email protected]> uunet!crdras!barnett

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 19:58:58 +0100
From:      [email protected] (Matthias Urlichs)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In comp.protocols.tcp-ip, article <[email protected]>,
  [email protected] (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: [email protected]
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:      [email protected] (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 [email protected] Messages that are to
be distributed by the list should be send to [email protected]

						Juergen


-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 23:59:58 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 13:20:57 -0800
From:      [email protected] (Mahboud Zabetian)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address
In article <[email protected]>, Tony Andreoli
<[email protected]_63SMTP_GW.CHINALAKE.NAVY.MIL> wrote:

> In article <[email protected]> Fernando Cozinheiro,
> [email protected] 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
[email protected]
ag group, inc.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 09:15:42 -0500
From:      [email protected] (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 <[email protected]>,
    Brent Holterman  <[email protected]> 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:    [email protected]

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 <[email protected]> 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
[email protected]  | 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 <[email protected]>
To:        comp.protocols.tcp-ip, [email protected]
Subject:   Re: Sizes of UDP packets.

In article <[email protected]>, <[email protected]> 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
<[email protected]>

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 09:28:28 -0400
From:      [email protected] (Les Howie)
To:        comp.protocols.tcp-ip
Subject:   Re: Steven's new book!
In article <[email protected]>
[email protected] (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:      [email protected] (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 
[email protected]

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 94 03:36:04 GMT
From:      [email protected] (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway
In article <[email protected]>, [email protected] (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
|>                                               [email protected]

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 16:30:45 -0600
From:      [email protected] (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:      [email protected]  (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:      [email protected] (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:  [email protected]                       ¦
¦___________________________________________________________________¦

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 07:52:34 GMT
From:      [email protected] (Scott Whitmire)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone heard of NetCom???
Jeffrey Horn ([email protected]) 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
: [email protected]

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         | [email protected] |
  | 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:      [email protected] (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: [email protected], [email protected]

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994  14:04 est
From:      [email protected]  (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: [email protected]

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 1994 21:52:13 +0800
From:      [email protected] (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:  [email protected]   /    \ 
  /\/(_)\|/|\     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:      [email protected] (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
[email protected]

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 12:34:39 GMT
From:      [email protected] (Don Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?
In article <[email protected]> [email protected] writes:
>From: [email protected]
>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 [email protected] WD3 MS10-13 (508)-699-1263

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1994 21:42:28 -0500
From:      [email protected] (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
[email protected].com


-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 13:45:38 GMT
From:      [email protected] (Patrick Schaaf)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway
[email protected] (Barry Margolin) writes:

>In article <[email protected]> [email protected] (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:      [email protected] (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocolconverter between lat and tcp-ip with 2 Ethernet plugs on PC
In article <[email protected]>, [email protected] (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 <[email protected]>            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:      [email protected] (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 <[email protected]>, [email protected]
(karen.karp) writes:
->how do I figure out the IP address of the server I am on?
->
->
->thanks!
->[email protected]

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: [email protected]

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 94 15:51:10 GMT
From:      [email protected] (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: 	[email protected]

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 16:01:26 GMT
From:      [email protected] (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
-- 
[email protected]
-bikram dhaliwal

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 16:53:03 GMT
From:      [email protected] (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  ([email protected])

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 16:58:06 GMT
From:      [email protected] (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 *
*  [email protected]					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:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway
In article <[email protected]> [email protected] (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:      [email protected] (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:  [email protected] In the body type:
     "FILE /internet-drafts/draft-ietf-imap-imap4-01.txt".
 
For questions, please mail to [email protected]
 
 
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="[email protected]"
 
Content-Type: text/plain
Content-ID: <[email protected]>
 
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: <[email protected]>
 
--OtherAccess--
 
--NextPart--

-- 
jon crowcroft (hmmm...)

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 1994 18:03:42 GMT
From:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Sizes of UDP packets.
Mathieu Claude Hans ([email protected]) 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 <[email protected]_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 <[email protected]> Fernando Cozinheiro,
[email protected] 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:      [email protected] (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:      [email protected] (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:      [email protected] (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 <[email protected]>
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 <[email protected]> Fernando Cozinheiro, [email protected]
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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages
In article <[email protected]> [email protected] ("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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 94 21:09:36 GMT
From:      [email protected] (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST
In article <[email protected]>, [email protected] (Dan Lanciani) writes:
| In article <[email protected]>, [email protected] (Curt Sampson) writes:
| | [email protected] (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
				[email protected]*

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 12:50:37 -0800
From:      [email protected] (Mahboud Zabetian)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address
In article <[email protected]>, Tony Andreoli
<[email protected]_63SMTP_GW.CHINALAKE.NAVY.MIL> wrote:

> In article <[email protected]> Fernando Cozinheiro,
> [email protected] 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
[email protected]
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:      [email protected] (Mahboud Zabetian)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address
In article <[email protected]>, Tony Andreoli
<[email protected]_63SMTP_GW.CHINALAKE.NAVY.MIL> wrote:

> In article <[email protected]> Fernando Cozinheiro,
> [email protected] 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
[email protected]
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:      [email protected]
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.misc
Subject:   RE: TCP-IP on a VAXstation
In Article <[email protected]>
[email protected] (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: [email protected]		(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:      [email protected] (James Risner)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet Driver for Token Ring
In article <[email protected]> [email protected] (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:      [email protected] (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] (Christian Huitema) writes:
>In article <[email protected]>, [email protected] (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    [email protected]

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:00:29 GMT
From:      [email protected] (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
[email protected]

In article <[email protected]>, [email protected] (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 *
|> *  [email protected]					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:      [email protected] (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected] 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    [email protected]

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 94 22:12:03 +0300
From:      Oleg Orel <[email protected]>
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Wanted : Statistics on X.25 and TCP/IP
Hiren Chandiramani ([email protected]) 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
: [email protected]




-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:12:04 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]> [email protected]oris.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    [email protected]

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:17:05 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute for non-root user
In article <[email protected]> [email protected] (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    [email protected]

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:21:42 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST
In article <[email protected]> [email protected] (Curt Sampson) writes:
>[email protected] (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    [email protected]

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 03:26:07 GMT
From:      [email protected]te.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: APPC LEAVES TCP/IP IN THE DUST
In article <[email protected]> [email protected] (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    [email protected]

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 04:19:17 GMT
From:      [email protected] (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
[email protected]  | 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:      [email protected] (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:      [email protected] (Dan Wing)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,vmsnet.networks.misc
Subject:   Re: TCP-IP on a VAXstation
In article <[email protected]>, [email protected] (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
 [email protected] or [email protected]

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 07:32:17 GMT
From:      [email protected] (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway
In article <[email protected]> [email protected] (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.

[email protected][131.108.11.55]


-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 21:00:03 -0800
From:      [email protected] (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'                         [email protected]
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 18:06:12 -0600
From:      [email protected] (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
[email protected]

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 08:08:30 GMT
From:      [email protected] (Thierry Turletti)
To:        comp.protocols.tcp-ip
Subject:   Re: What is RTP?
In article <[email protected]>, [email protected] (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: 	[email protected]

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 [email protected] 
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:  [email protected] In the body type: 
     "SEND draft-ietf-avt-rtp-03.txt".
 Or 
     "SEND draft-ietf-avt-rtp-03.ps".
							
For questions, please mail to [email protected]
							

-- 
Thierry Turletti <[email protected]>

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:      [email protected] (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   Re: IP gateway
In article <[email protected]>,
	[email protected] (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: [email protected], [email protected]

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 09:44:51 GMT
From:      [email protected] (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  [email protected]

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 19:26:32 -0500
From:      [email protected] (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:      [email protected]  (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! 
 
 
 
[email protected]
Larry W. Berman
 
 


-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 11:42:56 GMT
From:      [email protected] (Ignatios Souvatzis)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
In article <[email protected]>, [email protected] (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. [email protected]

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 94 21:22:23 -0500
From:      [email protected] (James Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?
In article <[email protected]>, [email protected] (Don Rolph) writes:
> In article <[email protected]> [email protected] (joshua geller) writes:
>>In article <[email protected]> [email protected] (David Barr)
>>writes:
>>>    <[email protected]> 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   [email protected]   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:      [email protected] (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:    [email protected]
Toronto, Ontario CANADA M5S 1A1


-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 17:22:14 GMT
From:      [email protected] (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Sizes of UDP packets.
Mathieu Claude Hans ([email protected]) 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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: What is RTP?
In article <[email protected]> [email protected] (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
[email protected]



-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 17:46:21 GMT
From:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate UDP Messages
Barry Margolin ([email protected]) wrote:
: In article <[email protected]> [email protected] ("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:      [email protected] (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Steven's new book!
In article <[email protected]>, [email protected] (Les Howie) writes:
> In article <[email protected]>
> [email protected] (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:      [email protected] (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.
[email protected]

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 18:53:43 GMT
From:      [email protected] (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:  ([email protected])
Locus Computing Corporation
Burlington, MA 01803

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Mar 1994 20:30:07 GMT
From:      [email protected] (Don Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?
In article <[email protected]> [email protected] (joshua geller) writes:
>From: [email protected] (joshua geller)
>Subject: Re: DNS or NIS what do I need?
>Date: 09 Mar 1994 06:46:39 GMT
 
>In article <[email protected]> [email protected] (David Barr) 
>writes:
>>    <[email protected]> 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 [email protected] WD3 MS10-13 (508)-699-1263

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 09:57:15 -0800
From:      [email protected] (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-- [email protected] 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:      [email protected] (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:      [email protected]
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 [email protected]
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 [email protected]

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 1994 23:09:06 GMT
From:      [email protected] (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:
     [email protected] (HOME BASE - SEND MAIL HERE)
     [email protected], [email protected]
     [email protected], [email protected]
     [email protected], [email protected]
     [email protected], [email protected]
     [email protected], & [email protected]
 
  Larry
 
-- 
Larry D. Loiselle, [email protected], [email protected],
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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Anyone heard of NetCom???
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 00:18:43 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: rcp client protocol wanted
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 04:32:22 GMT
From:      [email protected] (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:  [email protected]

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 05:22:11 GMT
From:      [email protected] (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 <[email protected]> [email protected] 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:      [email protected] (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address efficiency question
Patrick J. P. Griffin ([email protected]) 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:      [email protected] (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:      [email protected] (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address efficiency question
[email protected] (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:  [email protected]
-- 
    /|                          Tom Brink
 \`o.0'                         [email protected]
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 08:32:01 GMT
From:      [email protected] (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:      [email protected] (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!
[email protected]

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 12:39:05 GMT
From:      [email protected] (Jerry Natowitz)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?
In article <[email protected]>,
Don Rolph <[email protected]> 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 - [email protected]

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 12:59:15 +0000
From:      [email protected] (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
[email protected] (Vernon Schryver) writes:

> In article <[email protected]> [email protected] 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    [email protected]

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: [email protected] |
+------------------------------------+


-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 13:07:21 +0000
From:      [email protected] (Adam Goodfellow)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP over modem line?
[email protected] (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    [email protected]

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: [email protected] |
+------------------------------------+


-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 14:42:36 GMT
From:      [email protected] (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: X-windows port numbers
Tom Brink <[email protected]> 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:      [email protected] (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 ([email protected]) 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
[email protected]  | 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:      [email protected] (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address efficiency question
Patrick J. P. Griffin ([email protected]) 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:      [email protected] (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
[email protected]

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1994 19:32:54 GMT
From:      [email protected] (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 ([email protected])
-- 
Coert J. Vonk                                          voice: +31 70 332.3614
                                                         fax: +31 70 332.7807
[email protected]                             where: the Netherlands

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 1994 22:50:08 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: X-windows port numbers
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Mar 94 11:01:00 -0640
From:      [email protected] (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici
M >Patrick J. P. Griffin ([email protected]) 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:      [email protected] (Paul O'Farrell)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: BOOTPD for Solaris 2.3
[email protected] (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
[email protected]
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:      [email protected] (Maki Watanabe)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP on a VAXstation
In article <[email protected]>, [email protected] 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  :[email protected]
Digital Equipment Corporation Japan  NiftyServe:NBA01637

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Mar 1994 11:21:08 GMT
From:      [email protected] (David Hornsby)
To:        comp.unix.aix,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: ENET_SET_MULTI: No Space Left on Device
[email protected] (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:      [email protected]
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:      [email protected] (Frank Lofaro)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   127.x.x.x (was Re: UDP report card)
In article <[email protected]> [email protected] (Charles Hedrick) writes:
>[email protected] (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:      [email protected] (Charles Hedrick)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
[email protected] (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:      [email protected] (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on these questions.
In article <[email protected]>, [email protected] 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)
[email protected]

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 04:58:15 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP & Telnet 'protocol'
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 05:20:23 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: routed and ospf
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 05:26:17 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Std for SMTP enclosures
In article <[email protected]_vic.is.lmsc.lockheed.com> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 94 18:52:00 -0640
From:      [email protected] (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:      [email protected]
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 [email protected] (794) 

> In article <[email protected]_vic.is.lmsc.lockheed.com>
> [email protected] (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:      [email protected] (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:      [email protected] (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:      [email protected] (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:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   re:[email protected] 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 [email protected]

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 12:13:29 GMT
From:      [email protected] (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 ([email protected]) 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:
	[email protected] (Russell Nelson)
	[email protected] (Thomas Babsch)
	[email protected] (Jens Bitter)
	"Ben Bonnell" <[email protected]>
	[email protected] (manuel Toledo-Quinones)
	Manfred Kwiatkowski <[email protected]>
 
Manfred Kwiatkowski <[email protected]> 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.]
 
[email protected] (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.
 
[email protected] (Thomas Babsch) sent me the ulpkt111.exe driver.

[email protected] (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.

[email protected] (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" <[email protected]> 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:      [email protected] (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 [email protected]

YOUR TIME AND EFFORT ARE GREATLY APPRECIATED

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 22:47:04 -0500
From:      [email protected] (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 [email protected] with advice

THANKS YA'LL FOR YOUR TIME AND EFFORT!

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 1994 14:55:51 GMT
From:      [email protected] (Patrick J. P. Griffin)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici
John Will ([email protected]) 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:  [email protected]

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 00:56 -0500
From:      [email protected] (Matt Holdrege)
To:        comp.protocols.tcp-ip
Subject:   Re: routed and ospf
In article <[email protected]>, [email protected] (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!

[email protected]

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 16:56:50 GMT
From:      [email protected] ("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:      [email protected] (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 ([email protected]) 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: [email protected]

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 17:59:04 GMT
From:      [email protected] (Warner Losh)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
In article <[email protected]> [email protected] (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		[email protected]	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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS or NIS what do I need?
Oliver Yehung Hsu ([email protected]) 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:      [email protected] (Mark Evans)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
Frank Lofaro ([email protected]) 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:      [email protected] (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 <[email protected]> [email protected] (Warner Losh) writes:
>In article <[email protected]> [email protected] (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:      [email protected] (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

[email protected]



-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 21:46:09 GMT
From:      [email protected] (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:      [email protected] (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
[email protected] 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
[email protected]
 
A copy of the results of the study may be obtained by sending an email
request to [email protected]  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.
[email protected]

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Mar 1994 23:11:06 GMT
From:      [email protected] (Walter Mallory)
To:        comp.protocols.tcp-ip
Subject:   Re: int14 / remote modem communications
In article <[email protected]> [email protected] (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
[email protected]
The opinions expressed are wholly my own.

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 01:33:40 GMT
From:      [email protected] (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici
In article <[email protected]> [email protected] (Patrick J. P. Griffin) writes:
>John Will ([email protected]) 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:      [email protected] (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 <[email protected]> [email protected] (Frank Lofaro) writes:
>In article <[email protected]> [email protected] (Charles Hedrick) writes:
>>[email protected] (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:      [email protected] (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 <[email protected]> [email protected] (Earl H Kinmonth) writes:
>From: [email protected] (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:      [email protected] (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:      [email protected] (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 
      [email protected]     or
      [email protected]    or
      write a follow up

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 10:30:05 GMT
From:      [email protected]
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:      [email protected] ("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:      [email protected] (Alan Cox)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
In article <[email protected]> [email protected] (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:      [email protected]ix.apana.org.au (Leigh Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: Std for SMTP enclosures
[email protected] (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
 [email protected]  [email protected]  [email protected]

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 12:27:13 GMT
From:      [email protected] (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...
In article <[email protected]> [email protected] (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:      [email protected] (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 [email protected] or [email protected]
Thanks,
Suresh.
-- 
email: [email protected]             phone: (713)743 9156
       [email protected] (BITNET)
       uhou::suresh (THEnet or DECnet)


-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 23:11:41 -0500
From:      [email protected] (Stephen Tell)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on client-server implementation ..
In article <[email protected]> [email protected] (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       [email protected]    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:      [email protected] (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:      [email protected] (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          |[email protected]_|_(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:      [email protected] (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 <[email protected]>
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address efficiency question
>Patrick J. P. Griffin ([email protected]) 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:      [email protected] (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: [email protected] |
+------------------------------------+


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 18:12:02 GMT
From:      [email protected] (Berry Kercheval)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on these questions.
[email protected] (Ehud Gavron) writes:

>In article <[email protected]>, [email protected] 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 :: [email protected] 
"...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:      [email protected] (Mark Evans)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
Warner Losh ([email protected]) wrote:
: In article <[email protected]> [email protected] (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:      [email protected] (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
[email protected]
******************************************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        _                    _        _        _        _
     ,[email protected]`                  'Q__,    'Q__,    'Q__,    'Q__,
      \<,   "Wrong way you   ,>/      ,>/      ,>/      ,>/
   /^\/ //\    IDIOTS!"    /\\ \/^\ /\\ \/^\ /\\ \/^\ /\\ \/^\
   \_/  \_/                \_/  \_/ \_/  \_/ \_/  \_/ \_/  \_/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 20:36:01 GMT
From:      [email protected] (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:      [email protected] (Barry Margolin)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 1994 21:42:27 GMT
From:      [email protected] (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.


-- 
.-----------------------------------------------------------------------------.
| [email protected] | The opinions stated in this message do not reflect |
| [email protected]  | United HealthCare's.  My words and thoughts are my |
| [email protected]: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:      [email protected] ( 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: [email protected]
voice: (703) 883-6195

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 22:38:17 +0000
From:      [email protected] (Adam Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Re: READ ME URGENT
[email protected] (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] %(!^[email protected]#%%!$%(

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: [email protected] |
+------------------------------------+


-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 1994 23:53:01 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on these questions.
In article <[email protected]> [email protected] (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    [email protected]

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 00:16:08 GMT
From:      [email protected] (Ron Nadel)
To:        comp.protocols.tcp-ip
Subject:   Re: READ ME URGENT
In article <[email protected]> [email protected] (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:      [email protected] (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 <[email protected]> 
           [email protected] "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:      [email protected] (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:      [email protected] (Phil Perucci)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)
In article <[email protected]>,
M Thomps <[email protected]> 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 [email protected] 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:      [email protected] (Adam Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip protocol overhead costs
[email protected] ( 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: [email protected] |
+------------------------------------+


-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 17:18:05 -0800
From:      [email protected] (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 <--> TCP/IP Gateway ...?
In article <[email protected]> [email protected] (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:      [email protected] (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
					[email protected]

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 12:27:01 -0500
From:      [email protected] (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:      [email protected] (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 <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 05:33:08 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 08:32:27 GMT
From:      [email protected]t.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)
[email protected] (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:      [email protected] (Clark Bremer)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 <--> TCP/IP Gateway ...?
In article <[email protected]> [email protected] (Keith J. Leite) writes:
>From: [email protected] (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                            ||
||           /      /   __)      [email protected]                      ||
||          (      /    \        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:      [email protected] (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:      [email protected] (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:      [email protected] (Eric Werme USSG)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...
>In article <[email protected]> [email protected] (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		| [email protected]
Digital Equipment Corp.		| This space intentionally left blank.

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 13:17:38 GMT
From:      [email protected] (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:      [email protected] (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%[email protected]
Or     [email protected]
  _ __                                  _    ,    __
 ' )  )                           /    ' )  /    /  ) /
  /--' __. , , ____   ______   __/      /--/    /    /_  . . o
 /  \_(_(_(_/_/) ) )_(_) /) )_(_(_     /  ( o  (__/ / /_(_/_(_
             /
            /

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1994 14:56:12 GMT
From:      [email protected] (Suresh Arunachalam)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP-Netview
In article <[email protected]> [email protected] (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: [email protected]             phone: (713)743 9156
       [email protected] (BITNET)
       uhou::suresh (THEnet or DECnet)


-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 15:32:55 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??
In article <[email protected]> [email protected] (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
>					[email protected]

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    [email protected]

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 15:38:41 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...
In article <[email protected]> [email protected] (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    [email protected]

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 16:10:22 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip protocol overhead costs
In article <[email protected]> [email protected] writes:
>[email protected] ( 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    [email protected]

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 16:12:47 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
In article <[email protected]> [email protected] (Heath I Hunnicutt) writes:
>[email protected] (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    [email protected]

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 19:25:52 GMT
From:      [email protected] (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:      [email protected] (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.

[email protected]

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 21:01:20 GMT
From:      [email protected] (Warner Losh)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
In article <[email protected]> [email protected] (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		[email protected]	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:      [email protected] (Phuong Thanh Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 <--> TCP/IP Gateway ...?
In article <[email protected]>, [email protected] (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 - [email protected]
|>   Internet - [email protected]
|> 
|> **********************************************

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      [email protected]           |
--------------------------------------------------------------------------

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 21:34:00 GMT
From:      [email protected] (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 <[email protected]>, [email protected] 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
[email protected]

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 1994 22:53:28 GMT
From:      [email protected] (Michael R. Berg)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)
 
In article <[email protected]>, Phil Perucci ([email protected]) writes:
>In article <[email protected]>,
>M Thomps <[email protected]> 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 [email protected] 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 [email protected], 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:      [email protected] (Rolf Velthuys)
To:        comp.protocols.tcp-ip
Subject:   Re: ST-II
[email protected] (Ran Atkinson) writes:

#In article <[email protected]> [email protected] 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
[email protected]

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 02:17:55 GMT
From:      [email protected] (Pekka Pessi)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
In article <[email protected]> [email protected] (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.

--
[email protected]

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 10:51:29 -0500
From:      [email protected] (Ken Bell)
To:        comp.protocols.tcp-ip
Subject:   Re: netstat -r
In article <[email protected]>,
Freedman <[email protected]> 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
[email protected] / [email protected] / (212)-678-5545

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 94 05:04:42 GMT
From:      [email protected] (Charles Hedrick)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
[email protected] (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:      [email protected] (Matt Holdrege)
To:        comp.protocols.tcp-ip
Subject:   Re: routed and ospf
In article <[email protected]>, [email protected] (Barry Margolin) writes...
>In article <[email protected]> [email protected] (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:      [email protected] (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:      [email protected] (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:[email protected]
Department of Computer Science     |       [email protected]
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:      [email protected] (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x
In article <[email protected]> [email protected] (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:      [email protected] (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 [email protected]

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 12:03:30 +0100
From:      [email protected] (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 <[email protected]>,
  [email protected] (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: [email protected]
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:      [email protected] (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:      [email protected] (Olaf Titz)
To:        comp.security.unix,comp.protocols.tcp-ip
Subject:   Re: Why is sendmail so nice?
In article <[email protected]>,
J Rozes <[email protected]> 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       [email protected]          [email protected]
  comp.sc.student    _>\ _         [email protected]      LINUX - the choice
karlsruhe germany   (_)<(_)      [email protected]     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:      [email protected] (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:      [email protected]
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 [email protected]
 
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:      [email protected] (Nick Hilliard)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
Warner Losh ([email protected]) 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:   [email protected]                    |
| 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:      [email protected]
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:      [email protected] (Vernon Schryver)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
In article <[email protected]> <[email protected]> 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    [email protected]

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 16:42:49 GMT
From:      [email protected] (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: [email protected]
-----------------------------------------------

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 16:43:58 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Flow control and SLIP
In article <[email protected]> [email protected] (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    [email protected]

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 17:37:15 GMT
From:      [email protected] (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  [email protected]            |
                                 
with STD_DICLAIMER_PACKAGE;


-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 17:57:37 GMT
From:      [email protected] (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
 [email protected]          |  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:      [email protected] (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 <[email protected]>



-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 94 18:31:46 GMT
From:      [email protected] (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip protocol overhead costs
In article <[email protected]> [email protected] (Vernon Schryver) writes:
>In article <[email protected]> [email protected] writes:
>>[email protected] ( 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:      [email protected]
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:      [email protected] (Mark Evans)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
Alan Cox ([email protected]) wrote:
: In article <[email protected]> [email protected] (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:      [email protected] (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).
[email protected] (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 [email protected]  (I'm not connected with Windows development,
so I don't know how to answer your question myself.)
-- 
Jim Browne                                             | [email protected] |
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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS port numbers and...
Jim Reid ([email protected]) 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:      [email protected] (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
[email protected] or [email protected]

ps. Please respond by e-mail if possible.

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 19:37:00 GMT
From:      [email protected]
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: [email protected]
Paper: 638 66th st, Oakland Ca, 94609

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 20:12:52 GMT
From:      [email protected] (Mike Eisler)
To:        comp.protocols.tcp-ip
Cc:        
Subject:   Re: NFS port numbers and...
In article <[email protected]>,
Jim Reid <[email protected]> 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
	[email protected]

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 1994 20:13:40 GMT
From:      [email protected] (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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: ST-II
In article <[email protected]> [email protected] 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:      [email protected] (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...

[email protected]

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 22:43:47 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers and Broadcasting
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1994 21:39:37 +0200
From:      [email protected] (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 [email protected]

Thanks in advance.

Peter Greenwood


-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 10:11:19 -0500
From:      [email protected] (a.e.mossberg)
To:        comp.protocols.tcp-ip
Subject:   Re: RS-232 over RJ-45; any standards?
[email protected] (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:      [email protected] (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.

--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
[email protected], Department of Complain Science
Chung-Hua Polytechnic Institute =|8-) <Fat Dragon>
300, Hsin-Chu, Taiwan ... eMail:[email protected]

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1994 04:06:03 GMT
From:      [email protected] (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
[email protected]

----------------------------------------------------------
        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:      [email protected] (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:  [email protected]



-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 05:38:48 GMT
From:      [email protected] (Jeff Hakner)
To:        comp.protocols.tcp-ip
Subject:   Re: RS-232 over RJ-45; any standards?
in article <[email protected]>, [email protected] (Andrew Hardie) says:
> Date: Mon, 14 Mar 1994 10:34:14 +0000
> Message-ID: <[email protected]>
> Sender: [email protected]
> 
> 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:      [email protected] (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:      [email protected] (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  <[email protected]>

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 09:28:13 GMT
From:      [email protected] (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:      [email protected] (Jerry Natowitz)
To:        comp.protocols.tcp-ip
Subject:   Re: netstat -r
In article <[email protected]>,
Ken Bell <[email protected]> wrote:
>In article <[email protected]>,
>Freedman <[email protected]> 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
>[email protected] / [email protected] / (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 - [email protected]

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 12:49:22 GMT
From:      [email protected] (H. Peter Anvin N9ITP)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici
In article <[email protected]> of comp.protocols.tcp-ip,
  [email protected] (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: [email protected]               FINGER/TALK: [email protected]
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:      [email protected] (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:      [email protected] (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: [email protected]
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:      [email protected] (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:      [email protected] (Paul Ferguson)
To:        comp.protocols.tcp-ip
Subject:   Re: SIPSO
Ran Atkinson ([email protected]) 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 <[email protected]>

for more info or gopher it.

Cheers,


_______________________________________________________________________________
Paul Ferguson                         
US Sprint 
Enterprise Internet Engineering                    tel: 703.904.2437 
Herndon, Virginia  USA                        internet: [email protected]

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 19:31:45 GMT
From:      [email protected] (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:      [email protected] (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
[email protected]

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 1994 20:20:44 GMT
From:      [email protected] (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:      [email protected] (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 ([email protected]) 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:      [email protected] (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 <[email protected]>, [email protected] (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 <[email protected]>

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:      [email protected] (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:      [email protected] (Art Berggreen)
To:        comp.os.linux.development,comp.protocols.tcp-ip
Subject:   Re: 127.x.x.x (was Re: UDP report card)
Warner Losh ([email protected]) 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:      [email protected]
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
******************************************************************
* [email protected]             *    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:      [email protected] (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:      [email protected] (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
	[email protected]			[email protected]

	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:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   Re: news reader?

In article <[email protected]>, <[email protected]> writes:
> Path: 
> 
> Does anyone know of some good newsreaders for slip in Windows?
> 
> --
> --------------------------------------------------
> 
>  DCParsons - AlphaWave Computer Technology, Inc.
> 
>     [email protected]  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 <[email protected]>

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 1994 09:36:57 GMT
From:      [email protected] (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet Mask Feud
In article <[email protected]> [email protected] 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:      [email protected] (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: RS-232 over RJ-45; any standards?
In article <[email protected]> [email protected] 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:      [email protected] (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 [email protected]

Thanx in advance.

krishna

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 1994 16:40:43 GMT
From:      [email protected] (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. ]

[email protected] (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
  [email protected]			     puh. (90) 1929 658

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 1994 17:08:10 GMT
From:      [email protected] (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:      [email protected] (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 <--> TCP/IP Gateway ...?
In article <[email protected]>,
Keith J. Leite <[email protected]> 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: [email protected]    |   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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] Why not use sendmail under inetd?
In article <[email protected]> [email protected] 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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 1994 23:07:06 GMT
From:      [email protected] (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)

In article <[email protected]> [email protected] (Phil Perucci) writes:

>The cheapest full-time SLIP connection I have seen is about $200/month.

Netcom charges $160/month, I believe.

--
Perry Metzger		[email protected]
--
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:      [email protected] (E.P. Pylko)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: network programming books
In article <[email protected]> [email protected] (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: [email protected]
>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.
[email protected]              Average minds talk about things.
[email protected]                    Simple minds talk about people.

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1994 01:57:29 +0100
From:      [email protected] (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:      [email protected] (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] How to determine TCP Max. Segment Size (MSS)?
In article <[email protected]> [email protected] (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:      [email protected] (John Matthews)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??
In article <xxx>[email protected] (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
					[email protected]swest.com

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 94 20:30:24 PST
From:      [email protected]
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   [email protected]

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1994 22:12:02 -0500
From:      [email protected] (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 =
= [email protected]     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:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??
In article <[email protected]> [email protected] (John Matthews) writes:
>In article <xxx>[email protected] (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    [email protected]

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1994 18:20:32 GMT
From:      [email protected] (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:      [email protected] (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??
Vernon Schryver <[email protected]> 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:      [email protected] (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici
In article <[email protected]> [email protected] (H. Peter Anvin) writes:
>In article <[email protected]> of comp.protocols.tcp-ip,
>  [email protected] (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:      [email protected] (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!"	
[email protected]

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:      [email protected] (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
	[email protected]


-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 03:50:41 GMT
From:      [email protected] (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

    [email protected]     or
    [email protected]

frank Lin

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 04:00:18 GMT
From:      [email protected] (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)
In article <[email protected]> [email protected] (Perry E. Metzger) writes:

   In article <[email protected]> [email protected] (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 <[email protected]> for more info.

--
-russ <[email protected]>      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:      [email protected] (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:      [email protected] (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
[email protected]



-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 94 13:24:48 PDT
From:      [email protected]
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: [email protected]   *
*  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:      [email protected] (Terry Kennedy, Operations Mgr.)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] Why not use sendmail under inetd?
In article <[email protected]>, [email protected] (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
	[email protected]	St. Peter's College, Jersey City, NJ USA
	[email protected]	+1 201 915 9381

-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 09:27:34 GMT
From:      [email protected] (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Delay/Throughput Utilities for TCP/IP??
In article <[email protected]> [email protected]
(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:      [email protected] (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  : <[email protected]>
Eulenweg 2            Phone   : (49)-7244-1792
76536 Weingarten      Germany

-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1994 13:41:54 GMT
From:      [email protected] (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:      [email protected] (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple-get with ftp
In article <[email protected]>, [email protected] (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 <[email protected]>            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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: ST-II
In article <[email protected]> [email protected] (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
[email protected]



-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 16:45:04 GMT
From:      [email protected] (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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple-get with ftp
In article <[email protected]> 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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 94 23:09:23
From:      [email protected] (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:      [email protected] (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
-- 
[email protected]
#include <standard-disclaimer.txt>
Het was niet mij faut!

-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 20:03:56 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (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.

[email protected]


-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 1994 23:46:38 GMT
From:      [email protected] (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
[email protected]    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:      [email protected] (Mark Landin)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet address effici
[email protected] (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 *
*  [email protected]					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:      [email protected] (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
[email protected]    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:      [email protected] (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 [email protected]

Later,
George

-- 
[email protected]
#include <standard-disclaimer.txt>
Het was niet mij faut!

-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 00:56:00 GMT
From:      [email protected] (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! ;)
-- 
[email protected] | 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:      [email protected] (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Network measuring programs up for FTP...
George Neville-Neil <[email protected]> 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:      [email protected] (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: etherfind/tcpdump not seeing outgoing packets ?
In article <[email protected]> [email protected] (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:      [email protected] (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   ----------------------
                           [email protected]  
                             [email protected]      
           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 <[email protected]>
To:        comp.protocols.tcp-ip
Subject:   Re: nos? 1001 question ?!

In article <[email protected]> Roy Avidor,
[email protected] 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:      [email protected] (Kyle Jones)
To:        comp.protocols.tcp-ip,comp.mail.sendmail [email protected]
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. ]
 > 
 > [email protected] (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:      [email protected] (Aled Morris)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] Why not use sendmail under inetd?
In article <[email protected]> [email protected] (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
--
[email protected]  |  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:      [email protected] (Alistair Bell)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)
In article <[email protected]> [email protected] writes:

>In article <[email protected]>
> [email protected] (Perry E. Metzger) writes:
>
>   In article <[email protected]> [email protected] (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 <[email protected]> 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: [email protected]
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:      [email protected] (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:      [email protected] (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:      [email protected]
To:        alt.internet.services,comp.sys.mac.comm,alt.bbs.internet,comp.protocols.tcp-ip
Subject:   Re: Internaut V1 N1 Now Available
In <[email protected]>, [email protected] (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
[email protected]          | 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:      <[email protected]>
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:      [email protected] (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:   [email protected]                 |
| 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:      [email protected] (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
[email protected]

-----------[000526][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1994 18:50:30 GMT
From:      [email protected] (Aled Morris)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)
In article <[email protected]> [email protected] (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
--
[email protected]  |  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:      [email protected] (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
[email protected]


-----------[000528][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 19:38:28 GMT
From:      [email protected] (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:
[email protected]

-----------[000529][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 94 00:40:03
From:      [email protected] (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: <[email protected]>,
decwrl!vixie!paul         <[email protected]>,
<[email protected]>            <{bind-workers,objectivism}[email protected]>

-----------[000530][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 19:45:19 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: [Q] How to determine TCP Max. Segment Size (MSS)?
In article <[email protected]> [email protected] (Jon Kay) writes:
>In article <[email protected]> [email protected] (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    [email protected]

-----------[000531][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 1994 19:55:53 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: PERSONAL INTERNET PROVIDERS (REVISED)
In article <[email protected]> [email protected] 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 ti