The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 91 23:13:59 GMT
From:      patelsan@cookman.edu
To:        comp.protocols.tcp-ip
Subject:   ...Need Nameserver soft. for vax-vms or unix sysV/386

HI!
	Does anybody have or know of nameserver software, which is used 
for TCP/IP, for VAX785-vms or UNIX System V/386. We already installed 
CMUTEK TCP/IP V6.2 on our vax system. Can you give me any suggestion(s)
or e-mail address of place, where it is available.
	Thanks in Advance,

Sanjay Patel
Bethune-Cookman College
e-mail- patelsan@cookman.edu

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 91 18:08:33 GMT
From:      perreaul@interlan.Interlan.COM (Jason Perreault)
To:        comp.protocols.tcp-ip
Subject:   Integer computation of smoothed round trip time

I'm looking at "Internetworking with TCP/IP" by Comer and Stevens,
pp. 276-278 regarding integer computation of average and deviation
for round trip timing estimation (to derive retransmission timeout).
Raw round trip time, measured per transmitted packet, is used to 
adjust round trip time average and mean deviation, which in turn are 
used to compute the retransmission timeout value.

Are there any known typos or discrepancies among:

a. the text describing the derivation of equations
b. the source fragment for routine tcprtt()
c. the comments in tcprtt() re equations implemented

Two examples:

a. The text first presents the equation to update deviation as

         deviation = deviation + (|error| - deviation)

   while the source seems to implement 

         deviation = deviation + (|error| - deviation)/4.

   The latter seems more correct to me, as it applies a weighting
   to the adjustment term.


b. A comment in the source describes the retransmit timeout as

         rto = 2*(average + deviation)

   but the code itself seems to implement 

         rto = average + (2 * deviation).

   Again, the latter seems more correct to me, that any round trip
   time will likely fall within two deviations of the average.

Part of my confusion might stem from the fact that, to do the
integer computations, the values for average and deviation are
scaled by 8 and 4 respectively (ie, shifted left by 3 and 2) so
that "fractional" terms can be added to the low bits of these 
scaled values. The scaling corresponds to a weighting factor 'd'
that is less than one, which I surmise should be applied to the
"adjustment" terms in both the average and deviation updates. 
However, different values of 'd' are used for the two equations: 
(1 / 2**3) = 1/8 for average, and (1 / 2**2) = 1/4 for deviation. 
The text actually says at one point:

         "To further improve performance, TCP uses a slightly
          larger value for d, making the final form..."

but seems to apply the larger value [1/4 instead of 1/8] only to the 
computation of deviation, without any clarifying explanantion.

So the final results (in my mind, anyway) should be:

         error = raw_round_trip_time - average
         average = average + error/8
         deviation = deviation + (|error| - deviation)/4
         rto = average + 2*deviation

Any knowledgable comments would be greatly appreciated.
-- 
Jason J. Perreault            Internet: perreaul@interlan.interlan.com
Racal Datacom, Inc            Phone   : (508) 263-9929 x383
155 Swanson Road              FAX     : (508) 263-8655
Boxborough MA 01719

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 91 22:10:13 GMT
From:      ced@bcstec.uucp (Charles Derykus)
To:        comp.protocols.tcp-ip
Subject:   BIND 4.8.1 looping problem


We have been plagued by a tightly looping bind which has been
afflicting our lowest level nameservers.


Our root nameserver (not Internet connected) and all the next level
subdomain servers under root are Sun Sparc's 4.1 running bind 4.8.1.
Beneath the Suns, are a few Apollos serving their own subdomains and
a few caching-only RS/6000's. These are also at bind 4.8.1.

In a nutshell, the Apollo and RS/6000 apparently go into a tight loop
occasionally and stop serving. As resolvers, they still work fine. The
specific debug errors seem to indicate that the root servers 
venus.boeing.com and hera.boeing.com are going stale. DIG and DOC
were not helpful.

A few lines of the debug from the RS/6000 are shown below::
ns_forw()
nslookup(nsp=x2ff7e8d4,qp=x20060400)
nslookup: NS venus.boeing.com c1 t2 (x0)
nslookup: stale entry 'venus'
nslookup: 0 ns addrs
sysquery(venus.boeing.com, 1, 1)
findns: using cache
findns: 2 NS's added for ''
nslookup(nsp=x2ff7e4cc,qp=x20062800)
nslookup: NS venus.boeing.com c1 t2 (x0)
nslookup: stale entry 'venus'
nslookup: 0 ns addrs
nslookup: NS hera.boeing.com c1 t2 (x0)
nslookup: stale entry 'hera'
delete_all: 'hera' 0x2005c740 class 1 type 1
rm_datum(20048f80, 20048f80, 0) -> 0
nslookup: 0 ns addrs
nslookup: 0 ns addrs total
resp: no addrs found for NS's
nslookup: NS hera.boeing.com c1 t2 (x0)
nslookup: 0 ns addrs
sysquery(hera.boeing.com, 1, 1)
findns: using cache
findns: 2 NS's added for ''
nslookup(nsp=x2ff7e4cc,qp=x20062800)
nslookup: NS venus.boeing.com c1 t2 (x0)
nslookup: stale entry 'venus'
nslookup: 0 ns addrs
nslookup: NS hera.boeing.com c1 t2 (x0)
nslookup: 0 ns addrs
nslookup: 0 ns addrs total
resp: no addrs found for NS's
nslookup: 0 ns addrs total
forw: no nameservers found
findns: using cache
findns: 2 NS's added for ''
ns_forw()
  
This debug repeats ad nauseum until your disk is full. 
I thought I remembered a thread on this subject some time
ago on the Net. 

Can anyone suggest some possibilites?

Thanks for all explanation and response,


Charles DeRykus				Internet:   ced@bcstec.boeing.com
Boeing Computer Services		UUCP:	    ...!uunet!bcstec!ced
Bellevue, WA.  M/S 7M-HA			(206) 957-5326

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 91 13:59:55 GMT
From:      mhb@sppy00.UUCP (Michael Burkhardt)
To:        comp.protocols.tcp-ip
Subject:   Network print server

One of the departments here wants to put some laser printers on the network
with dedicated printer spoolers.  There are a couple of 286 PC's available
for this purpose, but I was wondering if anyone out there had any experience
with such a setup.  If a dedicated PC would do the trick what kind of software
should I use?  If a special piece of hardware exists (I know it does) for this
should I use that instead?  BTW, there are at least 3 printers which need to be
networked and possibly more.

Any help in this area would be greatly appreciated.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 00:06:41 GMT
From:      vsp@hpcupt3.cup.hp.com (V Shankar Prasad)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet manufacturer's IDs

In article <flamer.693075089@mithril> 
                      flamer@mithril.intel.com (Jim Trethewey) writes:
>
>Does anyone happen to have a (reasonably) current list of both the
>manufacturer IDs and Ethertypes that have been registered to date?
>Could you post it?

For the list of Ethertypes, see RFC 1010 "ASSIGNED NUMBERS" under the section
"Ethernet numbers of interest"

Shankar Prasad

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 02:29:57 GMT
From:      oldera@twg.com (Ed R. Alcoff)
To:        comp.protocols.tcp-ip
Subject:   Re: Wolinggong (sp?) drivers?

In article <1991Dec16.144307.13160@rs6000.cmp.ilstu.edu> dbeedle@rs6000.cmp.ilstu.edu (Dave Beedle) writes:
>
>     Hi I'm looking for the Wollinggong (just how do you spell it anyway?)
>tcp/ip drivers for an IBM ps/2.  If they are a comercial product, who who
>makes 'em?  If they are PD where can I get 'em?  Thanks for any info!
>
>TTFN
>
>-- 
>  Dave Beedle                                    Office of Academic Computing
>                                                    Illinois State University
>  Internet:  dbeedle@rs6000.cmp.ilstu.edu                    136A Julian Hall  
>    Bitnet:  dbeedle@ilstu.bitnet                          Normal, Il   61761

Dave et al,

	We have commercial products available for the PS/2 running
OS/2 or DOS: for OS/2, it is only the runtime w/ sockets library,
PathWay Runtime for OS/2; for
DOS, you can get just the runtime (PathWay Runtime for DOS),
or you can get a complete TCP/IP implementation with the smallest 
kernel available (flame on competition- it's a documented fact). 
PathWay Access for DOS.
 Look for the complete Pathway Access for OS/2 in the Spring.


	A 40% discount is provided to educational institutions: call
for more info (800) 872 - 8649 (outside of California).

	Yes, this is marketing hype for a legitimate request. 

	And we spell it - The Wollongong Group, Inc.

Regards,

Ed Alcoff
Product Manager, 
VMS & Network Management Products
The Wollongong Group, Inc.
1129 San Antonio Rd.
Palo Alto, Ca.  94303

ph  # (415) 962 - 7240
fax # (415) 969 - 5547
e-mail: oldera@twg.com

std disclaimer: These opinions are my own and do not necessarily
reflect those of my employer.

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 05:54:36 GMT
From:      bf049@cleveland.Freenet.Edu (Mike Pechura)
To:        comp.protocols.tcp-ip
Subject:   Need simple telnet like pgm

I am looking for source in C for a simple telnet like program written
to run in UNIX environment (actually DEC Ultrix workstation) to use
as an example in a data communications course. Just something that
establishes a connection to a given server on a given machine then
sends lines typed to the server and displays responses from the server.
I have written the program below as an attempt at what I am looking 
for but have a problem with it. If I connect to servers like FTP or
NNTP it works as expected but when I try to connect to a telnet (23)
server all I get back is 3 characters of repeatable garbage and 
nothing more (I expect to see a login request line). Modifying the
program to just print lines received from the server makes no
difference. Any suggestions, ideas, places to look? Thanks for the
help!

Here is my sample program: 
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <errno.h>
 
main(argc,argv) int argc; char *argv[];
{
struct sockaddr_in sin;
struct servent *sp;
struct hostent *hp;
int len,s;
char buf[512];
char server[20],machine[20];
strcpy(server,"telnet");
strcpy(machine,"coffman");
if (argc>2) strcpy(server,argv[2]);
if (argc>1) strcpy(machine,argv[1]);
 
sp=getservbyname(server,"tcp");
if (sp==NULL) {fprintf(stderr,"tcp/%s: unknown service\n",server);
exit(1);}
 
hp=gethostbyname(machine);
if (hp==NULL) {fprintf(stderr,"Unknown host: %s\n",machine); exit(1);}
 
bzero((char *)&sin,sizeof(sin));
bcopy(hp->h_addr,(char *)&sin.sin_addr,hp->h_length);
sin.sin_family=hp->h_addrtype;
sin.sin_port=sp->s_port;
s=socket(AF_INET,SOCK_STREAM,0);
if (s<0) { perror("%s: socket",server); exit(1);}
 
printf("Using socket number %d\n",s);
printf("Attempting to connect to %s:%s\n",machine,server);
if (connect(s,(char *)&sin,sizeof(sin))<0)
   {
   perror("%s: connect",server);
   exit(1);
   }
printf("Connected!\n");
while (1)
      {
      len=recv(s,buf,sizeof(buf),0);
      buf[len]=0;
      printf("Server said %d bytes: '%s'\n",len,buf);
      fgets(buf,200,stdin);
      strcat(buf,"\r");
      send(s,buf,strlen(buf),0);
      }
close(s);
 
}
 


-- 

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 11:33:45 GMT
From:      kaba@lehre24.informatik.Uni-Bremen.DE (Kai Bartels)
To:        comp.protocols.tcp-ip
Subject:   repost: problems while talking to a SVR4 ftpd

Hi!

I already asked this question in this group but I'm not sure my article left our
local site :-( so here we go again:

I'm curently writing a little TCP/IP-package (TCP,IP,ARP,TELNET,FTP) and I'm
stuck with a weird problem: my FTP can talk to the ftpd on the other side (SVR4)
without any problems as long as the protocol connection is concerned. But if I
send a PORT and a LIST over the protocol connection, the SVR4-ftpd simply 
opens the data connection and closes it again. It sends no data at all.

Anyone out there who has an idea? (pls recall: the TCP is also mine, so maybe I
missed something in there!?)

a merry Xmas to all of you, Kai
-- 
"It sounds like a whisper   Don't you know"                   <Tracy Chapman>
Uni: kaba@lehre2.informatik.uni-Bremen.de   +  Home: kaba@wintermute.north.de
Snail:    Kai Bartels    +    Poelzigstr. 4    +    2800 Bremen 1    +    FRG

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 13:51:48 GMT
From:      rah@sppy00.UUCP (MOORE ROBIN)
To:        comp.protocols.tcp-ip
Subject:   PD FTP source?

I'm looking for a source (anonymous FTP or otherwise) for public domain 
source code for an FTP server.  Client code would also be appreciated, 
but is not as crucial.  "C" language and sockets are required, and if
it happens to run on a Tandem system under the Guardian OS, that would
be fantastic (but I'll sure be surprised!)  8-)

If possible, please reply via E-mail to rah@oclc.org (in order to cut 
down on unnecessary net traffic).  Thanks very much in advance!
--
[          h                           Robin A Hermance-Moore                 ]
[      rrr hhh === mmmmm      rah@oclc.org                (614) 764-6215      ]
[      r   h h     m m m         OCLC Online Computer Library Center          ]
[      r   h h     m m m          6565 Frantz Road, Dublin OH 43017           ]
-- 
[          h                           Robin A Hermance-Moore                 ]
[      rrr hhh === mmmmm      rah@oclc.org                (614) 764-6215      ]
[      r   h h     m m m         OCLC Online Computer Library Center          ]
[      r   h h     m m m          6565 Frantz Road, Dublin OH 43017           ]

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 16:26:18 GMT
From:      black@ll.mit.edu (Jerry Glomph Black)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Looking for XNS software for Sun, Vax, etc.

We have some archaic Xerox Documentation Systems machines which talk to
each other via XNS on an ethernet link.  The only way to get data in/out
of these beasts is on PC floppies.   

Is there XNS software, client or server, which would run on a modern or
near-modern machine, preferably a Sun, which could be used to deal with
these beasties?

Yes, the best answer would be to pitchfork these big babies, but we're
stuck with 'em for now....

Thanks!  JG Black, black@LL.mit.edu
-- 
--------
TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST 
--------

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 21:47:58 GMT
From:      mengel@dcdmwm.uucp (Marc W. Mengel)
To:        comp.protocols.tcp-ip
Subject:   Re: Help in SLIP!


	Check to see if your 9600 baud modem has flow controll turned
	on; many such modems are configurable for RTS/CTS (hardware)
	flow controll, Xon/Xoff and/or ACK/NAK (software) flow controll.
	The software flow controll options will stop your average 8-bit
	protocol pretty quickly; usually as soon as the send/receive
	frame number becomes Xoff...
-------
Marc Mengel
mengel@fnal.fnal.gov

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 22:04:55 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

*Sigh*

The IP destination address in a broadcast (not multicast) datagram is
*irrelevant* because you already have a far more reliable indicator of
whether a packet is a broadcast or not: the ETHERNET destination
address.

If the implementations passed up a flag along with every incoming
frame that indicated whether or not it was received with an Ethernet
broadcast address, then it wouldn't matter at all what was in the IP
destination field. No broadcast storms, no confusion about all 1s or
all 0s, etc, etc.

Phil

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 22:10:44 GMT
From:      denisb@leland.stanford.edu (Denis Bohm)
To:        comp.protocols.tcp-ip
Subject:   How to dynamically allocate port numbers safely?

I hope this is the right group for this...

I have an application where I want to create ports dynamically.  I have
my own name server for the ports (because I didn't know if there was
a standard one.  Is there?).  What I am worried about is that the port
number that I choose may conflict with a predetermined one that is not
active at the moment (like the ones listed in /etc/services).  To avoid
this I use a range of numbers (like 2000-3000) that are much larger
than those that I have seen in /etc/services.  But if there was another
port name server that I don't know about I could conflict with it.  In
my port name server I only register ports that are alreay bound, so I
know that two of my port name servers can't conflict.

Can I get a conflict?  If so is there any way to avoid it?  Is there a
standard port name server that I can use?

Thanks,

-- 
Denis Bohm (denis@redwood.com)

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 91 22:54:54 GMT
From:      rgoldstone@OAVAX.CSUCHICO.EDU (Robin Goldstone)
To:        comp.protocols.tcp-ip
Subject:   Re: ...Need Nameserver soft. for vax-vms or unix sysV/386

In article <119.294e3e68@cookman.edu>, patelsan@cookman.edu writes:
>HI!
>	Does anybody have or know of nameserver software, which is used 
>for TCP/IP, for VAX785-vms or UNIX System V/386. We already installed 
>CMUTEK TCP/IP V6.2 on our vax system. Can you give me any suggestion(s)
>or e-mail address of place, where it is available.

There is a domain name server for CMUTek, written by Bruce Orchard.  It
is available at harry.waisman.wisc.edu, or e-mail orchard@don.waisman.wisc.edu
for more info.

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

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 91 00:27:18 GMT
From:      lyndon@cs.athabascau.ca (Lyndon Nerenberg)
To:        comp.unix.misc,comp.sources.wanted,comp.protocols.tcp-ip
Subject:   RIP daemon for CTIX 5.23

Does anyone out there know of a port of routed (or anything else that
can poke kernel routing tables based on RIP info) to CTIX 5.23?

Replies via e-mail - I'll summarize if I hear anything positive.
-- 
           atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca
                    Packet: ve6bbm@ve6mc.ab.can.noam
        Admittedly, the CA domain registrars seem a bit overzealous in
     their quest to preserve the purity of the namespace.   --Mark Moreas

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 91 02:52:15 GMT
From:      peiffer@janus.cs.umn.edu (Tim Peiffer (The Net Guy))
To:        comp.protocols.tcp-ip,comp.unix.admin,comp.unix.sysv386
Subject:   Re: Problems Sun to Interactive 386 - TCP/IP


	My apologies to various vendors in this area who
may have taken issue with my over generalization in certain areas.  I
should have stated that some ethernet controllers are slow.  The 
object of my original article was to show how to compensate when
controller speed is an issue.

	Personally I think that slowing down any network is the wrong
direction to go.  Consequently, the reasonable approach is to
temporarily publish arps.  Both of these approaches are *ugly*
workarounds in terms of overall management of a network.

Tim 
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
MPLS MN 55455

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 91 04:29:37 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

In article <1991Dec20.220455.9009@qualcomm.com> karn@chicago.qualcomm.com writes:
>The IP destination address in a broadcast (not multicast) datagram is
>*irrelevant* because you already have a far more reliable indicator of
>whether a packet is a broadcast or not: the ETHERNET destination
>address.

I disagree.  Supposed a confused host was sending all IP packets to the MAC
broadcast address, although it had the correct destination addresses in the
IP header.  If the IP header were ignored for MAC broadcasts, every host
would process all of them at least through the transport layer; but if the
IP address were checked then the processing would stop at the IP layer.

Also, what about when there are multiple logical subnets on a single
cable?  In this case, at least the network and subnet parts of the
destination address must be checked to determine whether the packet was
intended for this host's subnet.

Finally, the above scheme only works on media with a MAC broadcast
capability.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 91 05:00:50 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Floating Point

visser@convex.com (Lance Visser) writes:
+---------------
| rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
| +>Yeah, use scaled fixed-point. Go read the Berkeley TCP/IP code.
| +>No floating point. "Never had it; never will..."
| 
| 	"Never" in this case means not since 4.3-tahoe.  I think "4.3" orginal 
| did still have the floats for the rtt's.
+---------------

Several people have pointed out my error. I apologize. I let the cuteness
of the 7-Up slogan get in the way of accuracy. Since 4.3-Tahoe (or rather,
what might now be called "BSD Networking Release 1") was the first version
that I deeply dug into, I mistakenly assumed it had always been that way.


-Rob

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 91 05:32:01 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Need simple telnet like pgm

bf049@cleveland.Freenet.Edu (Mike Pechura) writes:
+---------------
| I am looking for source in C for a simple telnet like program...
| I have written the program below as an attempt at what I am looking 
| for but have a problem with it. If I connect to servers like FTP or
| NNTP it works as expected but when I try to connect to a telnet (23)
| server all I get back is 3 characters of repeatable garbage ...
+---------------

Try this:

1. Modify your program to decode Telnet "options" and pretty-print them
   (see RFC 854 "Telnet" and RFC 1060 "Assigned Numbers" for the format
   and numbers -- though not the meaning -- of the options).

2. Modify your program to allow the user some way of manually typing
   arbitary octets into the data stream, e.g. possibly a backslash
   escape or something ("hello\255\xff").

3. Each time the remote Telnet server sends an option "DO <such&such>",
   type back "WON'T <such&such>" ("WON'T" == <IAC><WON'T> == "\0xff\0xfc").

That will probably let you get far enough to see a login banner.


-Rob

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 91 05:50:26 GMT
From:      jeff@onion.rain.com (Jeff Beadles)
To:        comp.protocols.tcp-ip
Subject:   Re: qotd protocol

dsbarr@psuvax1.cs.psu.edu (Dave Barr) writes:

>   Is anyone out there running a qotd daemon?  Also, where would be
>a good place to look for the source (and hopefully some good quotes)
>for running my own qotd daemon?

%> grep qotd /etc/inetd.conf
qotd	stream	tcp	nowait	nobody	/usr/etc/tcpd fortune -s


That's about as simple as it can get :)  tcpd is part of the log_tcp package
to log incoming TCP connection, and is not needed.


	-Jeff
-- 
Jeff Beadles		jeff@onion.rain.com

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 91 14:59:17 GMT
From:      wb8foz@mthvax.cs.miami.edu (David Lesher)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   disruptions and recovery

{Not sure if this is a better -ip or -ip.domains question}

I get to mthvax by telneting on a long convoluted path over the
backbone and a regional or two.

Daily, and more usually hourly, the backbone stalls, leaving me hanging
for a period of between 10 seconds to 10 minutes. If you're familiar
with NSS-10 history over the last 4 months, you know what I'm talking
about...

But my question is about a specific behaviour I've noticed.  Sometimes,
when I am dead in the water, I break out out at my local terminal server
(that's never a problem to do) and request a SECOND session to mthvax.

Many times, it's NFG. But others, I CAN and do get a new session
running. Yet swapping back to session one shows it still stalled.
Eventually, the backbone recovers, and session one works once more.

My trivial knowledge of how TCP-IP works tells me this is not kosher.
Since there is no "connection", rather just a series of packets with
headers and data bits, why does the second set work when the first does
not?
-- 
A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu 
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 91 17:20:34 GMT
From:      win@incom.de (Winfried Koenig)
To:        comp.protocols.tcp-ip,comp.sys.unisys,comp.sys.sequent
Subject:   Networking product without socket interface

Yesterday I installed the UNISYS NET-6000 networking product for
U 6000/7x and U 6000/8x Systems. I was surprised not to find any
BSD SOCKET interface. There is only TLI STREAMS support.

Therefore I could not install some other software packages and
failed to finish my service. In the future I would like to avoid
such situations. Now my questions:

- Are there other UNIX networking products without socket interfaces?
  If yes, please send me manufacturer and product names.

- Is there any socket support in the original DYNIX system from Sequent?

- Is there any optional product from UNISYS to support the BSD socket
  interface on U 6000/7x and U 6000/8x systems?

Thanks in advance.

Winfried

-- 
Winfried Koenig        win@incom.de
Arendsstrasse 12       win@in.sub.org
6050 Offenbach         +49 69 868707
Germany

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 91 21:55:00 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: disruptions and recovery

In article <kl6lm5INNrk7@mthvax.cs.miami.edu> wb8foz@mthvax.cs.miami.edu (David Lesher) writes:
>{Not sure if this is a better -ip or -ip.domains question}

It's a tcp-ip question, as I didn't see any references to the Domain Name
System in your message.  I'm not sending my response to .domains.

>But my question is about a specific behaviour I've noticed.  Sometimes,
>when I am dead in the water, I break out out at my local terminal server
>(that's never a problem to do) and request a SECOND session to mthvax.
 
>Many times, it's NFG. But others, I CAN and do get a new session
>running. Yet swapping back to session one shows it still stalled.
>Eventually, the backbone recovers, and session one works once more.

Many TCP/IP implementations cache routing information in TCP connection
state.  This information is passed down to the IP layer, so that IP doesn't
have to recompute the route for each packet.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 91 06:31:05 GMT
From:      dror@FibHaifa.com (Dror Caspi)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over Token Ring with Source Routing


Is there as standard way to use Token Ring Source Routing when implementing
IP over 802.5 Token Ring ?  The problem, as I see it, is with the path 
finding (using single or all route broadcst). This is normally defined using
the LCC TEST or XID frames.

Thanks for any help,

--- 
--- Dror Caspi                                                       ---
--- Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL       ---
--- phone : +972-4-313655    fax: +972-4-516266 (550266 from 1/1/92) ---
--- e-mail: dror@FibHaifa.com   or  dror@fibronics.UUCP              ---
-- 
--- Dror Caspi                                                       ---
--- Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL       ---
--- phone : +972-4-313655    fax: +972-4-516266 (550266 from 1/1/92) ---
--- e-mail: dror@FibHaifa.com   or  dror@fibronics.UUCP              ---

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 91 15:05:54 GMT
From:      andre@inducom.nl (Andre Somberg)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Problems with Ethernet on ESIX V.4


Hi there.
We are evaluating ESIX V.403a on a 386 33 MHz clone, which we also
want to hook on to our Ethernet with several different types of
systems (PCs with NCSA Telnet and OS-9/680x0 systems with TCP/IP).
While trying to telnet to or from the ESIX system to a PC or
an OS-9/680x0 system, the system crashes with the message "kernel trap
0e" "bad nxtpkt value:nxtpkt=0000000ff" (plus or minus some leading zeros).
We do get a login prompt. The crash occurs after or during typing in
the username/password.
We are using a WD8013EB 16 bit Ethernet board, using the WD8003 driver
of ESIX. Besides the Ethernet board there is an Adaptec AHA1542A and
a Computone IntelliPort board. There seems to be no conflict in
interrupts, I/O and memory addresses. The mdevice/sdevice are conform
also.
Can anyone give us a hint where to look for? Has anyone experienced
a challenge like this one? We are currently getting bald by ripping out
our hair....
Please email or post your answers. Thanks in advance!
--
  Is, uh,...Is your wife a goer, eh?  Know whatahmean, know whatahmean,
  nudge nudge, know whatahmean, say no more? (Monty Python)
  Andre Somberg, Inducom Systems B.V. +31-4120-41922, fax +31-4120-22640
  UUCP: andre@inducom.nl        ...!uunet!mcsun!hp4nl!inducom!andre

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 91 22:09:31 GMT
From:      mkl@nw.com ("Mark Lottor")
To:        comp.protocols.tcp-ip
Subject:   NSFnet goes commercial


   The following topic surprisingly hasn't seen much discussion on the net.
Apparently, NSF is allowing ANS to sell commerical connections to the
NSFnet, thus allowing commercial traffic to flow over the NSFnet backbone.
This implies that NSF has changed its acceptable use policy and it is now
completely acceptable to use NSFnet for commercial purposes, with your
tax dollars paying the bill.

------------
U.S. SAID TO PLAY FAVORITES IN PROMOTING NATIONWIDE COMPUTER NETWORK
By John Markoff
c.1991 N.Y. Times News Service

   Just one week after President Bush signed legislation calling for the
creation of a nationwide computer data "superhighway," a debate has erupted
over whether the government gave an unfair advantage to a joint venture of
IBM and MCI that built and manages a key part of the network.
   The IBM-MCI venture, known as Advanced Network and Services, manages a
network called NSFnet, which connects hundreds of research centers and
universities. NSFnet also manages links to dozens of other countries. All
these networks are collectively known as Internet.
   Some private competitors say Advanced Network and Services uses its
favored position to squeeze them out of the data-transmission market by
establishing rules that make it difficult to connect to NSFnet.
   NSFnet was founded by the National Science Foundation, a federal agency,
and is composed of leased telephone lines that link special computers
called routers, which transmit packages of data to three million users in
33 countries. Data traffic over the NSFnet backbone has doubled in the last
year.
   The government wants to develop a national data highway for electronic
commerce, digital video transmissions to homes and vast electronic
libraries that could be drawn on by the nation's schools.
   Advanced Network and Services, based in Elmsford, N.Y., was set up last
year as a non-profit corporation with $10 million from International
Business Machines Corp. and MCI Communications Corp.  Earlier this year it
set up a for-profit subsidiary, called ANS CO+RE, to sell computer network
services.  That led some competitors to complain that Advanced Network and
Services would be able to compete unfairly because of its arrangement with
the government.
   People involved in planning for a national data network say it is
essential to provide for fair competition, which will lead rival companies
to offer creative and entrepreneurial services in the hope of building
market share. Without competiton, they say, the government will have
created a monopoly that has little incentive to innovate.
   "This is the first major communication business to be born under the
deregulation era," said David Farber, a computer scientist at the
University of Pennsylvania and a pioneer in data networking. "This hasn't
happened since the growth of the telephone industry. You want it to be a
business that doesn't repeat the errors of the past."
   In recent years, the National Science Foundation has tried to shift its
operations and ownership of NSFnet to Advanced Network and Services. And it
will try to establish competition through contracts for networks to compete
with NSFnet next year.
   But there is no level playing field, complained William L.  Schrader,
president of Performance Systems International Inc., a Reston, Va., company
that provides commercial data connections to Internet.
   He made public two letters between officials of Advanced Network and
Services and the National Science Foundation that he said gave the company
unfair control over access to the network. The result, he added, was that
the government turned over valuable public property to a private company.
   "It's like taking a federal park and giving it to Kmart," Schrader said.
"It's not right, and it isn't going to stand. As a taxpayer, I think it's
disgusting."
   Performance Systems and several other companies have set up an
alternative to NSFnet, known as a CIX.
   Schrader said his company and the venture of IBM and MCI were competing
for the same customers but unlike his rival he lacked a federal subsidy. He
said he might ask the Internal Revenue Service to look at the business
relationship between Advanced Network's non-profit and for-profit
operations.
   Allan Weis, the president of Advanced Network, disputed that his company
had an unfair advantage. "It's a very competitive environment right now,"
he said. "We have lost quite a few bids to PSI and to other competitors as
well."
   At the National Science Foundation, Stephen Wolff, director of its
networking division, said IBM and MCI had overbuilt the network and were
selling commercial service based on the excess capacity that was available.
   A number of organizations are working informally to settle the dispute.
   "I think it's a mess," said Mitchell D. Kapor, the founder of Lotus
Development Corp. and now head of the Electronic Frontier Foundation, a
public-interest group focusing on public policy issues surrounding data
networks. "Nobody should have an unfair advantage. This is important
because we're talking about something that is in its infancy but that one
day could be on the order of the personal computer industry."
-------

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 91 23:56:10 GMT
From:      andrew@megadata.mega.oz.au (Andrew McRae)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

From article <1991Dec20.220455.9009@qualcomm.com>, by karn@qualcom.qualcomm.com (Phil Karn):
> 
> If the implementations passed up a flag along with every incoming
> frame that indicated whether or not it was received with an Ethernet
> broadcast address, then it wouldn't matter at all what was in the IP
> destination field. No broadcast storms, no confusion about all 1s or
> all 0s, etc, etc.
> 
> Phil

This may not be good enough; certainly with IP multicast the problem is
that the multicast address usually gets sent with a MAC broadcast
address (even though 802.[34] has a multicast capability - I guess it
is too hard to map IP multicast to the MAC multicast groups), so you still
have a requirement to look at the address.

It also seems a bit nasty to rely on the MAC layer to inform you of
an IP broadcast - this relies on the MAC layer HAVING a broadcast
capability. Certainly with the rapid movement towards newer WAN technology
such as ISDN, Frame Relay, QPSX etc. the goalposts have moved as different
MAC layer characteristics are employed. I am no expert on this stuff, but
I see people talking about `directed ARPs, Ethernet-like MANs etc.'.

Perhaps I am misunderstanding what you are saying, however. Are you
saying `I will use the flag to indicate that this packet IS a broadcast
packet, regardless of the IP address.'? Or are you saying `This packet has
an IP address which could be a broadcast address, but I will only
treat it as a broadcast IF the network interface tells me it was
received using a MAC broadcast address.'?

If the latter, then the flag becomes an advisory bit of information which
may be useful to prevent these broadcast storms, but I would have
thought it is just as easy to fix the receiving code to accept both 0's
and 1's as broadcast packets. Where's the win?

I notice the newer BSD (Reno) code has a network layer to MAC driver
interface which includes a flag to indicate whether a MAC broadcast address
should be used. This sounds like a better idea, as the driver then doesn't
have to go messing about to discover whether this particular packet's protocol
destination address is a broadcast address. This means the network layer
(which is, of course, protocol dependant) tells the driver whether the
packet is a broadcast. The corollary IMHO is also true; when a packet is
received, it is up to the network layer protocol handler NOT the driver to
determine whether the packet is a broadcast packet. It is a slippery
slope to start using MAC level attributes to influence protocol processing.

Andrew McRae			inet:	andrew@megadata.mega.oz.au
Megadata Pty Ltd,		uucp:	..!uunet!megadata.mega.oz.au!andrew
North Ryde  2113		Phone:	+61 2 805 0899
NSW    AUSTRALIA		Fax:	+61 2 887 4847

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 91 09:09:08 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

In article <1991Dec22.235610.1854@megadata.mega.oz.au>, andrew@megadata.mega.oz.au (Andrew McRae) writes:
> 
> This may not be good enough; certainly with IP multicast the problem is
> that the multicast address usually gets sent with a MAC broadcast
> address (even though 802.[34] has a multicast capability - I guess it
> is too hard to map IP multicast to the MAC multicast groups), so you still
> have a requirement to look at the address. ...


The 4.3BSD IGMP code maps IP multicasts to ethernet multicasts.  If you
want to do reasonable SNMP, and satisfy Host Requirements, you must tag
incoming packets as multicast (including broadcast) as they come in, and
before sending them up.

(The Deering IGMP code was integrated into a tree at Berekely, but
didn't make the most recent release, and then the IETF revolution in
multicasting came along.)


Vernon Schryver,   vjs@sgi.com

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 91 13:43:26 GMT
From:      baileyaj@zetbok.prl.philips.nl (Alister Bailey)
To:        comp.protocols.tcp-ip,comp.os.os9
Subject:   TCP,UDP/IP implementations for OS-9?


I am interested in finding implementations of the basic
Internet protocols TCP,UDP and IP for 68XXX based OS-9,
PD or commercial. All replies/help appreciated

          Merry Christmas
Alister Bailey  (baileyaj@prl.philips.nl)    o
                                            `|'
( I'd rather be skiing - but NL is flat!)    \\

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 91 14:16:27 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFnet goes commercial

In article <29550d1d.nw@nw.com> mkl@nw.com ("Mark Lottor") writes:
   The following topic surprisingly hasn't seen much discussion on the
   net.

There has been plenty of discussion on the mailing list that discusses
commercializing and privatizing the networks, com-priv@psi.com.  Write
to com-priv-request for pointers to the list's archives, or to
subscribe.

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 91 14:31:49 GMT
From:      dla@se05.wg2.waii.com (Doug Acker)
To:        comp.protocols.tcp-ip
Subject:   routing question

If on a subnet I have two gateways to a corporate backgroupd, which
of the routing protocols should I use?  RIP, EGP and HELLO?  

If I understand Comer's book correctly, RIP and HELLO will not
find a loop ... and EGP never mentions this ...

We currently run static routing ... the big reason if a route goes
down we know immediately.  Does anyone have a solution to run
dynamic routing but get alarmed when a route goes down?

-- 
Douglas L. Acker

Western Geophysical Exploration Products
Systems Engineer

Email (internal):  acker                Phone:  713-964-6128
      (Internet):  acker@se01.wg2.waii.com

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 91 21:05:41 GMT
From:      mitton@dave.enet.dec.com (Dave Mitton)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet manufacturer's IDs


In article <1991Dec19.132222.137@gacvx2.gac.edu>, dan@gacvx2.gac.edu writes:
>From: dan@gacvx2.gac.edu
>Newsgroups: comp.protocols.tcp-ip
>Subject: Re: Ethernet manufacturer's IDs
>Date: 19 Dec 91 19:22:22 GMT
>
>Are token ring addresses and ethernet addresses assigned by the same people?  I
>would expect that there would be conflicts if they are not.  The IBM "08005a"
>is one I have seen used by IBM Token hardware manufactured by IBM.  Token ring
>addresses are, of course, reversed when compaired to ethernet addresses.


All 802.x physical layer addresses come from the same numeric space.
In fact all 802.x physical layers are required to have the addresses on 
the wire with the multicast bit first.

This coupled with the differences between media byte/bit tranmission order
is why IBM token ring addresses look backwards.

IEEE 802-1990 says that the little endian order (eg: Ethernet) is the
correct and canonical way that address values are to be represented 
above the MAC layer. (sect 5.4)

Not being aware of these issues can cause interesting problems for
protocols that use MAC address values across different media.

	Dave Mitton
	Token Ring Program
	Networks and Comm.
	Digital Equipment Corp

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 91 23:06:33 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

In article <kl5gphINNsce@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
|> I disagree.  Supposed a confused host was sending all IP packets to the MAC
|> broadcast address, although it had the correct destination addresses in the
|> IP header.  If the IP header were ignored for MAC broadcasts, every host
|> would process all of them at least through the transport layer; but if the
|> IP address were checked then the processing would stop at the IP layer.

This is, at best, a 2nd order CPU efficiency issue that appears only
when another host is misconfigured.  It is far less important than
preventing broadcast storms, which this technique clearly does, as IP
also refuses to forward or otherwise answer (e.g., with an ICMP
message) packets received as MAC layer broadcasts.

Note that the "MAC broadcast flag" should also be passed up by IP to
the transport layer, so point-to-point protocols like TCP can ignore
broadcasts.

|> Also, what about when there are multiple logical subnets on a single
|> cable?  In this case, at least the network and subnet parts of the
|> destination address must be checked to determine whether the packet was
|> intended for this host's subnet.

Does this cause any real problem? If necessary, the application can
still decide if it wants to process a given broadcast; it's only the
*IP layer* that should ignore the IP destination field when receiving
a MAC-layer broadcast. By "ignore", I mean it should always toss the
packet up to the transport layer regardless of the IP destination
address in the packet. It should never attempt to forward such packets.

|> Finally, the above scheme only works on media with a MAC broadcast
|> capability.

Yes, because broadcasting is *inherently* a MAC-level function! What
does it mean to "broadcast" something on a point-to-point link?

Of course, nothing I say here should be construed to say that
implementations of true IP multicasting cannot look at their IP
destination addresses when receiving packets as MAC-level broadcasts.
But the notion of "broadcasting" is completely alien to IP as it was
originally designed, which is why we got into this mess in the first
place.

Phil

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 91 23:21:42 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

In article <1991Dec22.235610.1854@megadata.mega.oz.au>, andrew@megadata.mega.oz.au (Andrew McRae) writes:
|> This may not be good enough; certainly with IP multicast the problem is
|> that the multicast address usually gets sent with a MAC broadcast
|> address (even though 802.[34] has a multicast capability - I guess it
|> is too hard to map IP multicast to the MAC multicast groups), so you still
|> have a requirement to look at the address.

I guess I overstated my original point a bit, which was only to put in
a bit of IP bulletproofing to guard against broadcast storms in the
event other hosts are configured with bogus broadcast addresses.

|> It also seems a bit nasty to rely on the MAC layer to inform you of
|> an IP broadcast - this relies on the MAC layer HAVING a broadcast
|> capability. Certainly with the rapid movement towards newer WAN technology
|> such as ISDN, Frame Relay, QPSX etc. the goalposts have moved as different
|> MAC layer characteristics are employed. I am no expert on this stuff, but
|> I see people talking about `directed ARPs, Ethernet-like MANs etc.'.
|> 
|> Perhaps I am misunderstanding what you are saying, however. Are you
|> saying `I will use the flag to indicate that this packet IS a broadcast
|> packet, regardless of the IP address.'? Or are you saying `This packet has
|> an IP address which could be a broadcast address, but I will only
|> treat it as a broadcast IF the network interface tells me it was
|> received using a MAC broadcast address.'?

The former -- IF the MAC-layer destination is a broadcast or multicast
address, THEN treat this packet as a broadcast or multicast no matter
what is in the IP destination field. If, but NOT "only if". Then it
doesn't really matter what you put in the IP destination field, does
it? The only reason to look at the IP destination field is if you happen
to support IP multicasting.

When the MAC layer says that a packet was a physical broadcast even
though the IP dest field says it's not (by the receiver's possibly
incorrect interpretation of the IP dest field) the safe thing to
do is to assume that the packet is in fact a broadcast.  Remember that
the packet was also received by everyone else on the same subnet and
they're all having to make the same decision, so the last thing you
want to do is to forward it or to return an ICMP message. That's how
broadcast or ARP storms happen.

Phil

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 91 23:55:46 GMT
From:      pete@wvus.org (Pete Gregory - UNIX SA)
To:        comp.protocols.tcp-ip
Subject:   promiscuous mode

Hi - SCO UNIX, WD8013W here...

I've got an SCO UNIX system acting strangely ever since I installed a
WD8013W ethernet card; simply put: *inbound* serial input drops by 2/3
(because of missed characters in the serial stream - the characters make
it to the adaptor but the CPU doesn't get them fast enough [but used to
with my old Racal Interlan ethernet adaptor] if I physically connect the 
ethernet to the adaptor - whether or not the UNIX kernel I'm running has 
ethernet drivers or not.

No IRQ, DMA or ADDR conflicts - I'll bet my paycheck on it.  Broadcast
traffic (and packets for THIS workstation) are so low in number that
this isn't a cause for serial slowdown.

I suspect the WD board may be in "promiscuous" mode (passing ALL packets
to UNIX drivers and inflicting more overhead - enough so that the CPU
misses inbound serial characters).  WD says "no way" but my gut feeling
tells me this.  Is there any definitive way to tell if the WD card is
passing EVERYTHING to the bus or not?

Pete Gregory, UNIX SA   Internet: pete@wvus.org
World Vision U.S.       Bangpath: elroy.jpl.nasa.gov!wvus!pete
			Slowpath: 919 W. Huntington Dr., Monrovia, CA 91016

"Candy-gram for Mongo!".....  BOOM!

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 91 06:23:09 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

In article <1991Dec23.230633.27506@qualcomm.com> karn@chicago.qualcomm.com writes:
>|> Also, what about when there are multiple logical subnets on a single
>|> cable?  In this case, at least the network and subnet parts of the
>|> destination address must be checked to determine whether the packet was
>|> intended for this host's subnet.
>
>Does this cause any real problem? If necessary, the application can
>still decide if it wants to process a given broadcast; it's only the
>*IP layer* that should ignore the IP destination field when receiving
>a MAC-layer broadcast. By "ignore", I mean it should always toss the
>packet up to the transport layer regardless of the IP destination
>address in the packet. It should never attempt to forward such packets.

All transport and higher-layer protocol implementations I'm familiar with
depend on the IP and lower-layer protocols to filter out packets not
intended for this host.  Each layer is responsible for a particular set of
filtering and demultiplexing, and it doesn't make sense for the higher
layers to have to check that the lower layer fulfilled its responsibility.
Should TCP check that the protocol field of the IP header is 6, and should
applications check the local port field of the TCP header?  If not, then
why should TCP check that the IP destination is this host?

Also, how does passing the packet up to the transport layer solve the
problem?  That simply means that the broadcast address has to be configured
at that layer, rather than the IP layer.

>|> Finally, the above scheme only works on media with a MAC broadcast
>|> capability.
>
>Yes, because broadcasting is *inherently* a MAC-level function! What
>does it mean to "broadcast" something on a point-to-point link?

Some subnets consist of a set of point-to-point links.  Wasn't this the
architecture of the old Arpanet?  I believe broadcasting on such subnets is
done using a flooding algorithm.

If all you're trying to accomplish is preventing broadcast storms and
inappropriate forwarding of broadcasts, then I think you're on the right
track, but wrong in the detail.  I think that a MAC broadcast that doesn't
have a recognizable IP destination address that includes this host (either
an IP broadcast address, a multicast address for a group we belong to, or
one of our interfaces' addresses) should be discarded with no ICMP error,
*not* passed up to the transport layer or forwarded.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 91 09:17:59 GMT
From:      tony@mwuk.UUCP (Tony Mountifield)
To:        comp.protocols.tcp-ip,comp.os.os9
Subject:   Re: TCP,UDP/IP implementations for OS-9?

In article <4632@prles2.prl.philips.nl> baileyaj@zetbok.prl.philips.nl (Alister Bailey) writes:
> 
> I am interested in finding implementations of the basic
> Internet protocols TCP,UDP and IP for 68XXX based OS-9,
> PD or commercial. All replies/help appreciated

The Microware OS-9 Internet package provides TCP, UDP, IP and BSD4.3
sockets. It is available from Microware for a variety of hardware, and
also directly from other hardware vendors for their own boards.

Please call Amanda Forrest at our office (see .sig below) for further
details and pricing - she already has contact with many Philips people.

>           Merry Christmas
> Alister Bailey  (baileyaj@prl.philips.nl)    o
>                                             `|'
> ( I'd rather be skiing - but NL is flat!)    \\

Tony.
-- 
Tony Mountifield                   | Microware Systems (UK) Ltd.
MAIL:  tony@mwuk.uucp              | Leylands Farm, Nobs Crook,
INET:  tony%mwuk.uucp@uknet.ac.uk  | Colden Common, WINCHESTER, SO21 1TH.
UUCP:  ...!mcsun!uknet!mwuk!tony   | Tel: 0703 601990   Fax: 0703 601991
**** OS-9, OS-9000 Real Time Systems **** MS-DOS - just say "No!" ****
------------------------------------------------------------------------
** Any opinions are mine, not Microware's - but you knew that anyway. **
------------------------------------------------------------------------

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 91 14:46:32 GMT
From:      ribet@math.berkeley.edu (Kenneth A. Ribet)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: How Do I Get A Macintosh Connected To Internet Via SLIP?


There's a version of NCSA Telnet which apparently works with slip.
It's available by anonymous ftp from ftp.utexa.edu, in
~ftp/pub/slip/mac/ncsa.

I hope to run NCSA Telnet on my mac, and set up a SLIP session with this
machine (math.berkeley.edu).  The kernel here on math has not yet been
modified to accomodate users' SLIP activities.

I'd love to hear from people who have gotten SLIP to work with this
flavor of NCSA telnet.

Ken Ribet
UC Berkeley Math Dept

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 91 19:23:06 GMT
From:      klassen@sol.UVic.CA (Melvin Klassen)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: How Do I Get A Macintosh Connected To Internet Via SLIP?

In article <klei28INNs33@agate.berkeley.edu> 
                    ribet@math.berkeley.edu (Kenneth A. Ribet) writes:
>
>There's a version of NCSA Telnet which apparently works with slip.
>It's available by anonymous ftp from ftp.utexa.edu, in
>~ftp/pub/slip/mac/ncsa.              !!!!!!!!!!!!!
                                      !!!!!!!!!!!!!
              I assume that you mean 'FTP.UTexas.EDU'.  :-)

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 91 22:41:20 GMT
From:      cliff@demon.co.uk (Cliff Stanford)
To:        comp.protocols.tcp-ip
Subject:   Re: Network print server

lapp@hppad.waterloo.hp.com (lapp@hppad.waterloo.hp.com) writes:
: One of the departments here wants to put some laser printers on the network
: with dedicated printer spoolers.  There are a couple of 286 PC's available
: for this purpose, but I was wondering if anyone out there had any experience
: with such a setup.  If a dedicated PC would do the trick what kind of software
: should I use?  If a special piece of hardware exists (I know it does) for this
: should I use that instead? BTW, there are at least 3 printers which need to be
: networked and possibly more.
: 
	I have just written a pair of utilities to use a PC (in
background) as a print server.  The client sits on the Unix box and
sleep on a pipe.  When it reads the pipe, fed by the lp scheduler, it
establishes a TCP/IP connection to a TSR server on a PC which is running
FTP's PC/TCP.  I use a shareware rint spooler utility, DMP, to buffer
the incoming data for the laser, meaning my TSR takes very little time
from the user.  The TSR can sit on up to three ports for LPT 1 to 3.
I'm currently logged on from home via a dial-up slip line and am typing
this whilst printing some documentation.
		Regards,
			Cliff.
-- 
Cliff Stanford				Email:	cliff@demon.co.uk (Work)
Demon Systems Limited				cms@demon.co.uk   (Home)
42 Hendon Lane				Phone:	081-349 0063	  (Office)
London	N3 1TT	England				0860 375870	  (Mobile)

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 91 23:07:41 GMT
From:      NIBMSCM@NDSUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   TLI libraries


  I've just begun working on a development project where we are using
the TLI api for a PPP server.  However, when I attempted to perform my
first compile and link, I was unable to find the TLI routines as part of
the standard link libs - and still haven't found them - I'm running SunOS 4.1.1

  Could one of you be so kind as to point me in the right direction.  Thanks
ahead of time for your help...


 ___________
|           |   Regards,
| N.D.----> *      Steve Malme    -->NIBMSCM@NDSUVM1.NODAK.EDU<--
|____________|      FBS Data Systems

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 91 17:27:46 GMT
From:      lpc@ddssuprs.uucp (Luis Caamano)
To:        bit.listserv.aix-l,comp.unix.aix,comp.protocols.tcp-ip
Subject:   SLIP gateway on rs6000s with subnets

Hello!!
I really need some help. I've tried everything, I've read as much
as I could. Believe me, I really tried before posting to the net.
Now, this is the scenario. 

Systems: RS6000s, AIX Version 3.1 (3.1.5, 3.1.6)

We have 3 ethernet segments but we have only one Class C address. We 
have decided to use subnets. The segments will be connected through 
SLIP over v32bis modems. We have decided to use 255.255.255.192
as the subnet mask to get four networks each with 62 possible host 
numbers. 

To test the SLIP connection I connected two hosts with a direct
connection, so forget the modems for now. What I'm interested in
is in subnetting and the routing tables. Since this is a small
network we decided to use static routing. So far so good.

Now, I've defined the SLIP interfaces, they work fine. 

This is what I've defined: (numbers and names are examples)

MachA is the gateway for network 192.9.200.0: 
    slip interface sl0 is slmachA, ip address 192.9.200.62
    ether interface en0 is machA, ip address 192.9.200.3, 
    mask 255.255.255.192

MachB is the gateway for network 192.9.200.128:
    slip interface sl0 is slmachB, ip address 192.9.200.129
    ether interface en0 is machB, ip address 192.9.200.130, 
    mask 255.255.255.192

Now if I want to telnet to a host on network 192.9.200.128 for
which machB is the gateway from another hosts on machA network,
I need to enter an static route. If I add a host type route it
works fine, but, for obvious reasons, I want to add a net type
route so anybody on machA network can access any host on machB
network. Sure, but I got inconsistent errors on the 3006 machine,
that is, sometimes I wanted to add a net type route but the
flags on the output of netstat -r said the it was a host type
route. This is what I got on machB routing tables:

Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
slmachA              slmachB		  UGH	   0	  330	     sl0
default	   	     slmachB		  UG	   1	  197	     sl0
192.131.82.128	     machB		  U	   9	  233	     en0
192.131.82           slmachB              UG       26     424        sl0
127                  loopback             U        1      858        lo0

However, I wasn't able to enter the equivalent routes on machA 
(3.1.6). Sometimes they came up as Host type routes or with the 
wrong interface. (en0 instead of sl0).

I could give more examples of what I've done, but then the article
would be too long. So, I can summarize the question to this:

Has anybody set up SLIP gateways with subnets on the RS6000?

Does anybody know of any gotchas or bugs with static routes and
subnets on the rs6000?

Any pointers to any documentation? 

thanks for you time.
-- 
---------------------------------------------------------------------------
Luis P. Caamano                    |         
Support Services Engineer          |         uunet!ddssuprs!lpc
Dickens Data Systems, Norcross GA  |         (404) 242-5991
---------------------------------------------------------------------------
If you think you know something, you'll stop learning. -myself

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 91 07:03:38 GMT
From:      nirad@newdelphi.ceu.uq.oz.au (Nirad Sharma)
To:        comp.protocols.tcp-ip
Subject:   Secure RPC using DES (outside USA)

I got hold of the secure RPC code and it mentions that DES is not included
due to export restrictions (outside of USA).  After consulting an AnonFTP doc,
I found a site in .funet.fi that had a DES implementation.  I was about to
"roll my own" DES (as indicated in the RPC docs) using these pieces of software
and then thought that I should check here to see if anyone has already done this
(debugging and all).  If not,  I'll have to get down to it soon.

So,  has anyone rolled their own DES / RPC that works on the Suns or have I
missed the point completely ?

(SunOS 4.1.1 Sparc,  if it matters)
--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 91 05:25:54 GMT
From:      pushp@nic.cerf.net (Pushpendra Mohta)
To:        comp.protocols.tcp-ip
Subject:   LAN/WAN Actual Traffic Traces Sought

If you have a collection of time traces of packet traffic
collected on Local/Metropolitan/Wide Area networks that you don't mind 
sharing, I would like to prepare a summary. Drop me a note and I will
send you a template. 

(The traffic need not be TCP/IP, any protocol suite is fine. 
If a summary exists, I will appreciate a pointer to it.)

I suspect most such traces were collected on a "broadcast" network, like
ethernet. Has anyone attempted a trace of packet traffic on a 
point-to-point link ? Do any sniffer-like protocol analysers come
with hooks to do this ?

thanks
--pushpendra

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 91 06:13:53 GMT
From:      rwed@hal.gnu.ai.mit.edu (El-surfamundo)
To:        comp.protocols.tcp-ip
Subject:   TCP retrans

Hello.. I am interested in having any algorithms and formulas for
the best way to compute TCP retransmission time outs/delays...

Thank you very much... 

Robert Wedlock... rwed@gnu.ai.mit.edu

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 91 21:46:12 GMT
From:      nirad@newdelphi.ceu.uq.oz.au (Nirad Sharma)
To:        comp.protocols.tcp-ip
Subject:   Some miscellaneous RPC questions

I'm new to RPC programming and have a couple of questions regarding RPC.

	Are there any archives of example RPC apps ?

	Has anyone got an example of an asynchronous RPC server ?  From what I
	read in the man pages, svc_getreqset & select play a part. Furthermore,
	how can an asych server be used in conjunction with rpcgen ? Preferably,
	the example would include dispatching routines with basic
	authentication.

	Is it best to check if a remote proc is alive by calling proc # 0
	of that service on the remote RPC server ?

	When using rpcgen,  how can I change the default timeout of client
	creation from 25 secs to something smaller ?  The manual mentions how
	to change the timeout on client calls but not the initial handle
	creation.

Thanks for any help.
--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 02:07:13 GMT
From:      karn@chicago.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

In article <kldkidINNla2@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>Should TCP check that the protocol field of the IP header is 6, and should
>applications check the local port field of the TCP header?  If not, then
>why should TCP check that the IP destination is this host?

No, TCP should not check that the IP destination is this host, but it
*should* examine the "physical broadcast flag" and ignore the packet
if it is set. This is just an example of defensive programming that
can protect a net against big traffic surges when somebody mistakenly
tries to connect to the broadcast address, or gets a bogus entry in
their table mapping some real host to a physical broadcast or
multicast address.

>Also, how does passing the packet up to the transport layer solve the
>problem?  That simply means that the broadcast address has to be configured
>at that layer, rather than the IP layer.

No, because, once again, the transport layer examines the physical
broadcast flag associated with the packet. If the flag is set, the
transport layer makes a protocol-dependent decision as to whether to
process the broadcast packet.  If it is TCP, then the packet should be
ignored: TCP is a connection oriented protocol and there is nothing
meaningful that can be done with a "TCP broadcast". But if it is UDP,
then the packet may be processed since UDP is frequently used with
broadcast packets. The IP destination address doesn't even enter into
it, unless multicasting is implemented.

>Some subnets consist of a set of point-to-point links.  Wasn't this the
>architecture of the old Arpanet?  I believe broadcasting on such subnets is
>done using a flooding algorithm.

The old ARPANET did provide a flooding scheme for internal use in
distributing routing updates, but this was not available for use by
client hosts. But it's certainly possible that a network consisting of
point-to-point links *could* provide a virtual broadcasting service.
So what? In such a case I think it would be even more important to
program hosts and routers to behave defensively when it comes to the
actions they take on incoming physical (or subnet) broadcast packets,
because broadcasting in such a network would be so expensive in terms
of resources.

>If all you're trying to accomplish is preventing broadcast storms and
>inappropriate forwarding of broadcasts, then I think you're on the right
>track, but wrong in the detail.  I think that a MAC broadcast that doesn't
>have a recognizable IP destination address that includes this host (either
>an IP broadcast address, a multicast address for a group we belong to, or
>one of our interfaces' addresses) should be discarded with no ICMP error,
>*not* passed up to the transport layer or forwarded.

This is certainly a defensible position, and perhaps we don't disagree
as much as you think. One can certainly argue that it should not be a
host (or router's) job to bend over backwards in compensating for
other hosts' misconfigured broadcast addresses, at least in the sense
of going beyond simply defending against broadcast storms to keep the
misconfigured hosts communicating with you despite their errors.  But
I think the Internet Implementer's Creed comes into play here: "Be
conservative in what you send, and liberal in what you accept". If you
get an Ethernet packet that looks just like an IP/UDP broadcast except
that the IP level broadcast address is wrong (a very common mistake),
then isn't accepting it as a valid IP broadcast in keeping with this
philosphy?

Phil

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 03:55:41 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

In article <1991Dec30.020713.2786@qualcomm.com> karn@chicago.qualcomm.com (Phil Karn) writes:
>I think the Internet Implementer's Creed comes into play here: "Be
>conservative in what you send, and liberal in what you accept". If you
>get an Ethernet packet that looks just like an IP/UDP broadcast except
>that the IP level broadcast address is wrong (a very common mistake),
>then isn't accepting it as a valid IP broadcast in keeping with this
>philosphy?

I think it is reasonable to recognize the host-part-zero broadcast address,
under the above philosophy.  It's a well-known incorrect IP broadcast
address, so good software should accomodate this common error.  In
addition, it's not a valid host IP address.  But if the broadcast packet
has an IP destination address that looks like a valid host address (for
some other host), I don't think the MAC broadcast flag should override the
decision to discard the packet.  It seems just as likely that an ARP
screwup caused some entry to get filled in with a broadcast address.  The
sender was expecting one response, but it ends up with dozens or hundreds;
the ones for which it wasn't expecting a reply might generate ICMP errors,
and if there are other screwed up ARP table entries, these might get
broadcast as well.  In other words, processing such an incorrect packet
could result in a broadcast storm, which was what you were hoping to
prevent!
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 08:24:42 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet manufacturer's IDs

sorting your addr list would have made it useful - as it is its trash.....

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 08:29:51 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP internals reference

Have you heard of Comers book? It's the bible of TCP/IP.

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 08:34:20 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP internals reference

Low shot on that reply - everyone starts from the basics - no need to to take
a shot below the belt. WE ALL started into this technology from the same 
level - NEW.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 08:38:51 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: Network print server

Novell should be one of your prime candidates to take care of this and
Netware V3.11would be the ideal solution.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 08:55:43 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: disruptions and recovery

Then you also know TCP/IP is a connectionless session - ie not dependent on
whether one packet arrives before another. But if packets are lost (and they
are) the originating host tries to resend them. Then again the route is also
unreliable - so it can change mid transmission - which could result in 
packets dying because of hop count or cost.

It's not a perfect world or network........

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 08:59:37 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFnet goes commercial

Are you paranoid for some reason?

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 09:06:31 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: PD FTP source?

Haven't people learned that the only way computing is going to really make
inroads to bith business and academics is that it has to be an open
architecture? Proprietary means death to the company that promotes it!!!!!

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 09:09:22 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: routing question

IGRP would be the preffered method if you have a network you can set
it up on. We're in such a large netwogk moving from RIP to IGRP is 
going to be a killer.

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 09:28:37 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   Re: Network print server

You know - I've been playing the computer game for 15 years and have yet 
to undertaken the task of rewritting code that someone else has done -
sucessesfully. I commend your efforts, but would rather use existing code
for my clients - since they depend on my resources to make money - and
supply me with income.

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 16:36:08 GMT
From:      mengel@dcdmwm.uucp (Marc W. Mengel)
To:        comp.protocols.tcp-ip
Subject:   Re: promiscuous mode

pete@wvus.org (Pete Gregory - UNIX SA) writes:

>I suspect the WD board may be in "promiscuous" mode (passing ALL packets
>to UNIX drivers and inflicting more overhead - enough so that the CPU
>misses inbound serial characters).  WD says "no way" but my gut feeling
>tells me this.  Is there any definitive way to tell if the WD card is
>passing EVERYTHING to the bus or not?

	Just hook a scope up to the IRQ lead on the bus and watch it.
	Most PC technical reference books have a pinout for it the bus,
	but  you can usually cheat and hook your test "hot" lead to the 
	IRQ jumper on the card, with ground hooked to the chassis.  Should 
	be basic TTL levels, so you *could* rig a little op-amp/LED circuit 
	to watch it if you don't have a scope.  It should light up every
	time the interrupt triggers...
-------
Marc Mengel
mengel@fnal.fnal.gov

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 16:41:00 GMT
From:      mengel@dcdmwm.uucp (Marc W. Mengel)
To:        bit.listserv.aix-l,comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: SLIP gateway on rs6000s with subnets

lpc@ddssuprs.uucp (Luis Caamano) writes:

>We have 3 ethernet segments but we have only one Class C address. We 
>have decided to use subnets. The segments will be connected through 
>SLIP over v32bis modems. We have decided to use 255.255.255.192
>as the subnet mask to get four networks each with 62 possible host 
>numbers. 

Ooops... You need 5 subnets.  One for each ethernet segment, and
one for each SLIP segment.  Of course you only need a few numbers
(like maybe four) on your SLIP lines...

	ether1		ether2		ether3
	|		|		|
	+h1		+h3		+h5
	+h2		+h4		+h6
	|		|		|
	+gw1		+gw2		+gw3
	   +---slip1-----+ +----slip2----+

>This is what I've defined: (numbers and names are examples)
 
>MachA is the gateway for network 192.9.200.0: 
>    slip interface sl0 is slmachA, ip address 192.9.200.62
>    ether interface en0 is machA, ip address 192.9.200.3, 
>    mask 255.255.255.192

See, both your sl0 and en0 interfaces are on the same network (192.9.200.0), 
and hence nothing will get routed;  What you want is something like:

	name	network		mask		description
	eth1	192.9.200.0	255.255.255.192	First ethernet
	eth2	192.9.200.64	255.255.255.192 Second ethernet
	eth3	192.9.200.128	255.255.255.192	Third ethernet
	sli1	192.9.200.192	255.255.255.240	First slip network
	sli2	192.9.200.208	255.255.255.240	Second slip network

Now your gateways look something like

	machine	gateway			addresses
	gw1	ethernet1 to slip1	192.9.200.1	on en0
					192.9.200.193	on sl0

	gw2	slip1,2 to ethernet2	192.9.200.65	on en0
					192.9.200.194	on sl0
					192.9.200.209	on sl1

	gw3	slip2 to ethernet3	192.9.200.129	on en0
					192.9.200.210	on sl0

Then your routing tables look like (sans 192.9.'s)

		Dest	Gateway	Flags	Interface

	gw1:	200.192	200.193	U	sl0
		200.0	200.1	U	en0
		200.64	200.194 UG	sl0
		200.128	200.194 UG	sl0

	gw2:	200.64	200.65	U	en0
		200.192 200.194	U	sl0
		200.208 200.209 U	sl1
		200.0	200.193 UG	sl0
		200.128 200.210 UG	sl2
	
etc.

>However, I wasn't able to enter the equivalent routes on machA 
>(3.1.6). Sometimes they came up as Host type routes or with the 
>wrong interface. (en0 instead of sl0).

The wrong interface problem is 'cause you have two interfaces on
the same network number in your configuration.

>Does anybody know of any gotchas or bugs with static routes and
>subnets on the rs6000?

The config database doesn't add subnetted addresses
explicitly as network routes at boot, so they default to
host routes. To work around this wierdness you have to add them 
via /etc/route and explicitly say they are network addresses.  
(i.e. /etc/route add net 192...)
		     ^^^
Add them in /etc/rc.net where the static route commands
are commented out, after flushing the bogus ones the 
config database added; like:

	/etc/route -f			# clean out broken host routes
	/etc/route add net ether1 gw1s 2
	...

-------
Marc Mengel
mengel@fnal.fnal.gov

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 16:46:42 GMT
From:      ben@monmouth.edu (Bennett Broder)
To:        comp.protocols.tcp-ip
Subject:   Help on slip


We are planning on setting up a SLIP connection between two SUN 3/60s at
different locations.  The connection would be via Telebit modem.  I would
like to set it up so that whenever a connection was needed, it would
automatically be established.  This could be for mail, ftp or telnet.

Is it possible to do this with SLIP?  Any pointers would be appreciated.
Please respond by mail, I will summarize if there is interest.


-- 

Bennett Broder               Monmouth College
                             Computer Services
ben@monmouth.edu             W. Long Branch, NJ 07764

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 91 23:55:43 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: 0s as broadcast

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

|> I think it is reasonable to recognize the host-part-zero broadcast address,
|> under the above philosophy.  It's a well-known incorrect IP broadcast
|> address, so good software should accomodate this common error.  In
|> addition, it's not a valid host IP address.  But if the broadcast packet
|> has an IP destination address that looks like a valid host address (for
|> some other host), I don't think the MAC broadcast flag should override the
|> decision to discard the packet.  It seems just as likely that an ARP
|> screwup caused some entry to get filled in with a broadcast address.  The
|> sender was expecting one response, but it ends up with dozens or hundreds;
|> the ones for which it wasn't expecting a reply might generate ICMP errors,
|> and if there are other screwed up ARP table entries, these might get
|> broadcast as well.  In other words, processing such an incorrect packet
|> could result in a broadcast storm, which was what you were hoping to
|> prevent!
 
|> Barry Margolin, Thinking Machines Corp.

But most of these bogus packets will probably be TCP (simply because
most of the traffic on the net is TCP) and by the rule I mentioned
earlier, TCP would ignore packets received as MAC broadcasts. So bogus
TCP packets could not create an ARP storm in any event.

UDP broadcasts are more problematic, but for many applications there
is no real problem -- if the host doesn't support the application it
will just ignore the packet. (It can't return an ICMP Port Unreachable
because of the rule that one never generates ICMP messages in response
to MAC layer broadcasts.) If the application is supported on the host
in question, it could still decide to ignore UDP packets received as
MAC broadcasts (e.g., NFS might and probably should work this way).
The few UDP applications that can (and should) respond to broadcasts
(e.g., RIP, when answering a REQUEST or doing a triggered update) will
continue to work in any event since virtually all their traffic is
broadcast anyway.

My point in all this is the following: until the invention of IP
multicast, there was no notion of "broadcasting" in IP. Broadcasting
was strictly a MAC layer concept. The MAC layer destination address
therefore tells you everything you need to know. In hosts without IP
multicasting, the IP destination address in a MAC layer broadcast is
at best superfluous and at worst ambiguous (if it does not contain
what the receiving host considers to be an "IP broadcast address".

It's just like the old joke about how someone with a watch knows what
time it is, but someone with TWO watches is never sure. It seems better
to pick the more reliable watch and ignore the other one.

Phil

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 91 01:31:31 GMT
From:      taybh@hpsgm2.sgp.hp.com (Tay Beng Hang)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP retrans

In comp.protocols.tcp-ip, rwed@hal.gnu.ai.mit.edu (El-surfamundo) writes:

    > Hello.. I am interested in having any algorithms and formulas for
    > the best way to compute TCP retransmission time outs/delays...

    The recent TCP implements adaptive retransmission timer. Please refer to
    the following papers for details:

    1) Karn, P., and Partridge C., "Improving round-trip time estimates in 
    Reliable Transport Protocol", SIGCOMM'87 workshop, Aug 1987, p 2-7.

    2) Jacobson, V., "Congestion Avoidance and Control', Proc. pf ACM SIGCOMM
    '88 workshop, Aug 1988, pp.314-329.

    Also, the latest edition of Comer's book "Internetworking with TCP/IP"
    Vol. 1, 2nd Ed. does provide a easy to understand explaination.

    Hope this helps.


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

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 91 15:58:51 GMT
From:      patty@vaxeline.ftp.com (Patty Hanagan)
To:        comp.protocols.tcp-ip
Subject:   lists of:  Ethernet Protocol types, Multicast & Vendor addresses


FTP Software maintains an updated list of: 

	Ethernet Protocol Types 
	Ethernet Vendor Addresses 
	Ethernet Multicast Addresses and 
	ProNET-10 Protocol Types

These lists reside in appendices of our LANWatch documentation.

I am in the process of updating the lists for our next major release of
LANWatch.  If you have additions to any of these lists, you can email them to
me (patty@@ftp.com) and I'll add them.

You can get the current lists through anonymous ftp to vax.ftp.com.  They
reside in the directory </u/ftp/pub/lanwatch> in the files: eth-type,
vendor.lst, multicas, and pro-prot.
			
If there is enough response, I will post the lists to tcp-ip.

						Thanks!
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Patty Hanagan          FTP Software, Inc.        internet: patty@@ftp.com
                       26 Princess St.                            
Documentation        Wakefield, Ma  01880          (617) 224-6315

END OF DOCUMENT