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 July 1994 (573 messages, 459089 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1994/07.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 Jul 1994 00:04:14 GMT
From:      rao@acsc.com (Rao Srinivasa)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2utmev$9o2@cherokee.advtech.uswest.com>, crohrer@advtech.uswest.com (Chris Rohrer) writes:|> Hi all,
|> 
|>  
|> My real question is more like this: Will "typical" host IP software obey
|> this 1500 byte restriction and tell its users (TCP, UDP and possibly other
|> entities) that THEIR maximum "block" size is of that same approximate
|> value (1500 minus the IP overhead)?  Or will this "typical" IP software
|> present a 64k-sized interface to its layer 4 users and take the initiative
|> to do real header-mediated IP fragmentation down to the 1500 byte size?
|> 
   As far as I know IP does the fragmentation and assembling of the 
   packets ....
   I look at it this way ..
	
    If I open an UDP socket and write data which is more than 1500 bytes 
     it reaches the peer without any problem ...

    So either UDP or IP does this work ...

    If UDP does this work then it has to done by TCP too ...

    So I feel( that's not what you want though ..) IP does this work for both UDP and TCP.
    
     Lets wait for others say ...Mean while I will dig in to some UDP/IP books ..


Rao.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jul 94 08:32:45 PDT
From:      katherine.deforest@airdata.com
To:        misc.jobs.offered,comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Seattle/Wireless Data Customer Engineer


McCaw Cellular's Wireless Data Division in Kirkland, WA is 
looking for a Customer Engineer to act as a pre-sales technical 
resource to leverage our exciting new wireless data products 
and services.  This is an incredible opportunity to be a part of 
the wireless data revolution.

Responsibilities:

* Manage the technical customer relationship while actively 
participating in the design and implementation of a total 
customer solution.
* Act as customer advocate within the customer organization, 
with hardware and software suppliers, and within McCaw.
* Assist customers with application development and porting, 
as well as application integration, with both systems and networks.
* Maintain relationships with multiple hardware and software 
developers and manufacturers.

Qualifications:

* Minimum of 5 years experience with computer hardware/software 
and data communications.
* Strong knowledge of packet switching and router-based networking.
* Experience with:
	TCP/IP and OSI protocols
	Apps development including: C, C++, GUI's, 
	   and host-based back-ends
	Integrating PC-based applications with LANS and WANS
* Undergraduate degree in CS or Engineering
* Proven customer relations and presentation skills.

Salary and benefits are competitive and we will assist you, if necessary,
in your move to the Northwest.  

Please send your resume by one of the following means:

Email:    katherine.deforest@airdata.com
Fax:      (206)803-4001
US Mail:  Katherine DeForest
	  McCaw Cellular Communications, Inc.
	  10230 NE Points Drive
	  Kirkland, WA 98033-7869 
No phone calls please.  Thanks!	

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 15:38:58 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: CD-ROM and TCP/IP

In article <1994Jun30.185731.23356@moore.com> chris@moore.com (Chris Box) writes:
>Does anyone know how I'd attach a CD-ROM to a TCP/IP network as an
>independent device?  I don't want it attached to anyone's PC, but would
>rather it have a direct connection something along the lines of a
>printserver device which attaches directly to the ethernet cabling.

  Sure.  Since you don't want to do the obvious and cheapest and most
  robust thing and just put in on a PC and treat it like any other
  drive and NFS mount it to the tcp/ip network, the following is
  pretty much what you are stuck with:

  o Build a black box which knows how to talk to the CD-ROM drive.  
    
  o Implement your own file system, i/o drivers, etc. etc. to make
    that CD-ROM drive look to your TCP/IP and NFS interface exactly
    as if it were a CD-ROM drive attached to a PC.

  o Put some type of operating system in your little black box.  You
    can now either write or buy a nice clean TCP/IP UDP protocol
    stack.  If you used the wrong operating system, this is gonna
    get "highly interesting".  

  o Either write or buy NFS or PC/NFS and put in on that operating
    system.  

  o Build or buy your own ethernet (or whatever LAN adapter you are
    using) board.  

  o Buy or write your own LAN driver for your LAN adapter. 

  For the sake of saving maybe a few hundred dollars in off the
  shelf PC and software, you are likely in for a complete destroyal of
  your personal life, your sanity, and very likely your user's data.

  This answer, although somewhat unduly sarcastic is not entirely
  in jest.  You can either attach it to someone's PC or buy a
  standalone unit and put the CD-ROM on that.  These are cheap, pretty
  reliable, off-the-shelf answers.  The alternative, until someone
  sells a CD-ROM NFS server box, is gonna get pretty ugly. 



-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jun 1994 15:04:43 +0800
From:      peter.lewis@info.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp setup

>I'd be grateful for replies by email.

If you don't need them, stay away from fancy servers - obviously the more
complex the server, the more places for holes.

Never have any directory in ~ftp owned by ftp.  Best is owned by a user
and group that no one can log in as.  Alternatively, owned by you and with
a dummy group (a group not including the ftp user).

Never allow any directory to be both readable and writeable.  If you have
a drop folder, make it write and execute, buit not read.  Make sure any
file put in to that directory does not immediately become world readable. 
If you allow read&write, people will take the opertunity to set up illicit
sites (pirate or x-rated usually) on your host.

Obviously ensure that no files or directories are world writeable unless
you know exactly what you are doing and why.  Perhaps write a script to
verify this and run it regularly with cron.

Sign on to the CERT mailing list and listen for security problems.

Those are probably the main ones,
   Peter.
_______________________________________________________________________
Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jul 1994 05:35:35 GMT
From:      gnn@netcom.com (George Neville-Neil)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP FAQ Version 1.3 July 1994


OK, folks here's the latest FAQ.  Not much changed this time.  I may add
some more of my own stuff in August.

Later,
George

--- Begin FAQ --- 
Internet Protocol Frequently Asked Questions

Maintained by: George V. Neville-Neil (gnn@netcom.com)
Contributions from:
Ran Atkinson
Stephane Bortzmeyer
Phill Conrad 
Jon Kay 
William Manning
Barry Margolin 
Jim Muchow
W. Richard Stevens 
 
Version 1.3

Last Update:  July 1, 1994

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

	The following is a list of Frequently Asked Questions, and
their answers, for people interested in the Internet Protocols,
including TCP, UDP, ICMP and others.  Please send all additions,
corrections, complaints and kudos to the above address.  This FAQ will
be posted on or about the first of every month.

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

Table of Contents:
Glossary
1) Are there any good books on IP?
2) Where can I find example source code for TCP/UDP/IP?
3) Are there any public domain programs to check the performance of an
IP link? 
4) Where do I find RFCs?
5) How can I detect that the other end of a TCP connection has
crashed?  Can I use "keepalives" for this?
6) Can the keepalive timeouts be configured?
7) Can I set up a gateway to the Internet that translates IP
addresses, so that I don't have to change all our internal addresses 
to an official network? 


Glossary:

I felt this should be first given the plethora of acronyms used in the
rest of this FAQ.

IP: Internet Protocol.  The lowest layer protocol defined in TCP/IP.
This is the base layer on which all other protocols mentioned herein
are built.  IP is often referred to as TCP/IP as well.

UDP: User Datagram Protocol.  This is a connectionless protocol built
on top of IP.  It does not provide any guarantees on the ordering or
delivery of messages.  This protocol is layered on top of IP.

TCP: Transmission Control Protocol.  TCP is a connection oriented
protocol that guarantees that messages are delivered in the order in
which they were sent and that all messages are delivered.  If a TCP
connection cannot deliver a message it closes the connection and
informs the entity that created it.  This protocol is layered on top
of IP.

ICMP:  Internet Control Message Protocol.  ICMP is used for
diagnostics in the network.  The Unix program, ping, uses ICMP
messages to detect the status of other hosts in the net.  ICMP
messages can either be queries (in the case of ping) or error reports,
such as when a network is unreachable.

RFC: Request For Comment.  RFCs are documents that define the
protocols used in the IP Internet.  Some are only suggestions, some
are even jokes, and others are published standards.  Several sites in
the Internet store RFCs and make them available for anonymous ftp.

SLIP:  Serial Line IP.  An implementation of IP for use over a serial
link (modem).  CSLIP is an optimized (compressed) version of SLIP that
gives better throughput.

Bandwidth:  The amount of data that can be pushed through a link in
unit time.  Usually measured in bits or bytes per second.

Latency:  The amount of time that a message spends in a network going
from point A to point B.

Jitter:  The effect seen when latency is not a constant.  That is, if
messages experience a different latencies between two points in a
network.

RPC:  Remote Procedure Call.  RPC is a method of making network access
to resource transparent to the application programmer by supplying a
"stub" routine that is called in the same way as a regular procedure
call.  The stub actually performs the call across the network to
another computer.

Marshalling:  The process of taking arbitrary data (characters,
integers, structures) and packing them up for transmission across a
network.

MBONE: A virtual network that is a Multicast backBONE.  It is still a
research prototype, but it extends through most of the core of the
Internet (including North America, Europe, and Australia).  It uses IP
Multicasting which is defined in RFC-1112.  An MBONE FAQ is available
via anonymous ftp from: ftp.isi.edu"  There are frequent broadcasts of
multimedia programs (audio and low bandwidth video) over the MBONE.


1) Are there any good books on IP?

A) Yes.  Please see the following:

Internetworking with TCP/IP Volume I
(Principles, Protocols, and Architecture)
Douglas E. Comer
Prentice Hall 1991

This volume covers all of the protocols, including IP, UDP, TCP, and
the gateway protocols.  It also includes discussions of higher level
protocols such as FTP, TELNET, and NFS.

Internetworking with TCP/IP Volume II
(Design, Implementation, and Internals)
Douglas E. Comer / David L. Stevens
Prentice Hall 1991

Discusses the implementation of the protocols and gives numerous code
examples.

Internetworking with TCP/IP Volume III (BSD Socket Version)
(Client - Server Programming and Applications)
Douglas E. Comer / David L. Stevens
Prentice Hall 1993

This book discusses programming applications that use the internet
protocols.  It includes examples of telnet, ftp clients and servers.
Discusses RPC and XDR at length.

TCP/IP Illustrated, Volume 1: The Protocols, 
W. Richard Stevens
(c) Addison-Wesley, 1994 

An excellent introduction to the entire TCP/IP protocol suite,
covering all the major protocols, plus several important applications.

Unix Network Programming
W. Richard Stevens
Prentice Hall 1990

An excellent introduction to network programming under Unix.

The Design and Implementation of the 4.3 BSD Operating System
Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, John S.
Quarterman 
Addison-Wesley 1989

Though this book is a reference for the entire operating system, the
eleventh and twelfth chapters completely explain how the networking
protocols are implemented in the kernel.


2)  Where can I find example source code for TCP/UDP/IP?

A)  Code from the Internetworking with TCP/IP Volume III is available
for anonymous ftp from:

arthur.cs.purdue.edu:/pub/dls

Code used in the Net-2 version of Berkeley Unix is available for
anonymous ftp from:

ftp.uu.net:systems/unix/bsd-sources/sys/netinet 

and

gatekeeper.dec.com:/pub/BSD/net2/sys/netinet

Code from Richard Steven's book is available on:
ftp.uu.net:/published/books/stevens.*

3)  Are there any public domain programs to check the performance of
an IP link?

A)  

TTCP:  Available for anonymous ftp from....

Host gatekeeper.dec.com

    Location: /.0/BSD/NetBSD/NetBSD-current/othersrc
      DIRECTORY dr-xr-xr-x        512  Apr  8 09:57  ttcp
    Location: /.0/BSD/NetBSD/NetBSD-current/othersrc/ttcp
           FILE -r--r--r--       3885  Nov  7 03:35  ttcp.1
           FILE -r--r--r--      19225  Nov  7 03:35  ttcp.c

Host world.std.com

    Location: /src/wuarchive/graphics/graphics/mirrors/sgi.com/sgi/src/ttcp
           FILE -r--r--r--       3885  Oct  4 1991  ttcp.1
           FILE -r--r--r--      19170  May 17 1993  ttcp.c
           FILE -r--r--r--      13033  Sep  5 1989  ttcp.c-brl

On ftp.sgi.com are netperf (from Rick Jones at HP) and nettest
(from Dave Borman at Cray).  ttcp is also availabel at ftp.sgi.com.




There is suite of Bandwidth Measuring programs from gnn@netcom.com.
Available for anonymous ftp from ftp.netcom.com in
~ftp/gnn/bwmeas-0.3.tar.Z These are several programs that meausre
bandwidth and jitter over several kinds of IPC links, including TCP
and UDP.


4) Where do I find RFCs?

A)  This is the latest info on obtaining RFCs:
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@ISI.EDU with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@ISI.EDU
        Subject: getting rfcs

        help: ways_to_get_rfcs

The response to this mail query is quite long and has been omitted.

RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET,
NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or FTP.SESQUI.NET.


Using Web, WAIS, and gopher:

Web:

http://web.nexor.co.uk/rfc-index/rfc-index-search-form.html

WAIS access by keyword:

wais://wais.cnam.fr/RFC

Excellent presentation with a full-text search too:

http://www.cis.ohio-state.edu/hypertext/information/rfc.html

With Gopher:

gopher://r2d2.jvnc.net/11/Internet%20Resources/RFC
gopher://muspin.gsfc.nasa.gov:4320/1g2go4%20ds.internic.net%2070%201%201/.ds/
.internetdocs



5) How can I detect that the other end of a TCP connection has crashed?
Can I use "keepalives" for this?

A) Detecting crashed systems over TCP/IP is difficult.  TCP doesn't require
any transmission over a connection if the application isn't sending
anything, and many of the media over which TCP/IP is used (e.g. ethernet)
don't provide a reliable way to determine whether a particular host is up.
If a server doesn't hear from a client, it could be because it has nothing
to say, some network between the server and client may be down, the server
or client's network interface may be disconnected, or the client may have
crashed.  Network failures are often temporary (a thin ethernet will appear
down while someone is adding a link to the daisy chain, and it often takes
a few minutes for new routes to stabilize when a router goes down), and TCP
connections shouldn't be dropped as a result.

Keepalives are a feature of the sockets API that requests that an empty
packet be sent periodically over an idle connection; this should evoke an
acknowledgement from the remote system if it is still up, a reset if it has
rebooted, and a timeout if it is down.  These are not normally sent until
the connection has been idle for a few hours.  The purpose isn't to detect
a crash immediately, but to keep unnecessary resources from being allocated
forever.

If more rapid detection of remote failures is required, this should be
implemented in the application protocol.  There is no standard mechanism
for this, but an example is requiring clients to send a "no-op" message
every minute or two.  An example protocol that uses this is X Display
Manager Control Protocol (XDMCP), part of the X Window System, Version 11;
the XDM server managing a session periodically sends a Sync command to the
display server, which should evoke an application-level response, and
resets the session if it doesn't get a response (this is actually an
example of a poor implementation, as a timeout can occur if another client
"grabs" the server for too long).

6) Can the keepalive timeouts be configured?

A) I know they can on many systems, but I don't know the details.

7) Can I set up a gateway to the Internet that translates IP addresses, so
that I don't have to change all our internal addresses to an official
network?

A) There's no general solution to this.  Many protocols include IP
addresses in the application-level data (FTP's "PORT" command is the most
notable), so it isn't simply a matter of translating addresses in the IP
header.  Also, if the network number(s) you're using match those assigned
to another organization, your gateway won't be able to communicate with
that organization (RFC 1597 proposes network numbers that are reserved for
private use, to avoid such conflicts, but if you're already using a
different network number this won't help you).

However, if you're willing to live with limited access to the Internet from
internal hosts, the "proxy" servers developed for firewalls can be used as
a substitute for an address-translating gateway. See the firewall FAQ.

--- End FAQ--
-- 
gnn@netcom.com

Law is there to clean up etiquette's failures.
					Ms. Manners

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jul 94 05:45:27 GMT
From:      hal9001@panix.com (Robert A. Rosenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: SLIP for MACs

In Article <2uu6f7$eks$1@heifetz.msen.com>, ssayer@garnet.msen.com (Stephen
Sayer) wrote:

>
>        MacPPP 2.0.1 can be found at many FTP sites and on many online
>services. It's a public domain package from Merit. 
>
>        I've also been very happy with VersaTermSLIP in concert with
>VersaTerm Link which rolls POP3/SMTP mail, NNTP, FTP, Telnet, finger
>and external clients into one nice little package. You'll want to
>contact Synergy about VersaTerm et al. at info@synergy.com. As far as
>SLIP on the Mac goes I think it's the easiest to configure and use.
>
>Later,
>
><SS>
>
>--
>--
>     { ssayer@mail.msen.com | ssayer@umcc.umich.edu }
>I have a plan... if you need to know, you can finger it out.

As you can see, I use VersaTerm Link. If you have MacPPP selected by MacTCP
(in lieu of VersaSLIP) VTL is perfectly happy and will work just as well
(I'm using MacPPP right now so this is not just theoretical <g>) so those
who want/need a PPP instead of a SLIP link can get it.

One comment about VTL's News Support. It is neat in that it has support for
capturing Articles to your HD and then reading them while you are offline
(ie: The Captured Articles serve as a NewsServer). The only short-coming is
that the scanning of the Titles (to select which articles to capture) must
still be done online in real time (unless you chose to just capture ALL the
articles in a newsgroup).

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 09:04:17 GMT
From:      pbs@zuunix.zuo.dec.com (Philip Shearer @ZUO-DC EBS-Team)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Help with UDP Broadcast

bertg@fwi.uva.nl (Bert Gijsbers) writes:
: mintz@cup.hp.com (Ken Mintz) writes:
: 
: >  That is, __if__ inet_addr returns -1, we merely need to also check to see
: >  if the parameter is indeed "255...255" and, if so, accept the -1 as a
: >  valid sin_addr.
: 
: Shouldn't we be testing for INADDR_NONE rather than -1?
: Where INADDR_NONE is #defined as ((unsigned long)0xffffffff).

The define in the header on OSF1 ALPHA (a 64 bit machine):

#ifndef _KERNEL
#define INADDR_NONE     0xffffffff      /* -1 return */
#endif

: I'm also unsure about how this works on 64 bit CPUs.
: Do they return (-1) or ((unsigned long)0xffffffff)?

YES
: 
: >-- Ken Mintz
: 
: Bert Gijsbers

The function returns 0xffffffff if assigned to an int it will be -1,
or 0xffffffff if assigned to a long.

In my previous posting to this thread I commented on the manual page, 
the mention of -1 as the return confuses the issue and leads to the 
danger of:

    if ( (rtn=inet_addr(var)) < 0 )
        printf("This will never print because the < is  always false\n");
    else
        printf("This will always appear\n");



Here is the result of a test of 64 and 32 bit sizes on an OSF1 ALPHA.
(the display size of size32 at 0xffffffffffffffff happens as soon as
the bit shift caused the int overflows the 32 bit boundry. 
But the xor shows that the number can still be manipulated as expected)

TTFN Philip
---------------------------- result ---------------------
 YES, rtn == 0xffffffff

 size64 == 0xffffffffffffffff
 size32 == 0xffffffffffffffff
 size32 ^ (1 << 31) == 0x7fffffff
 size32 == 0xffffffff
 size64 = size32 = 0xffffffff
 32 bits from an int assigned to long int on an OSF1 Alpha :-)

--------------------X cut here for the source to the above. X-------------
#include <stdio.h>
main()
{
    const bits =  64 ;
    unsigned long int rtn;

    rtn=inet_addr("255.255.255.255") ;

    printf("---------------------------- result ---------------------\n");

    if ( rtn == 0xffffffff )
        printf(" YES,") ;
    else
        printf(" NO,") ;

    printf(" rtn = 0x%lx\n\n", rtn);

    displaysizes(bits) ;
}

displaysizes(int bits)
{
    int i ;
    unsigned long size64 = 0 ;
    unsigned int  size32 = 0 ;

    for ( i = 0 ; i < bits; i++ )
    {
        size64 = size64 << 1 ;
                size64 |= 1 ;
        size32 = size32 << 1 ;
        size32 |= 1 ;
    }


    printf("size64 == 0x%lx\n", size64);
    printf("size32 == 0x%lx \n", size32);
    printf("size32 ^ (1 << 31) == 0x%lx\n ", size32 ^ (1 << 31)  );
    printf("size32 == 0x%x\n ", size32);

    size64 = size32 ;

    printf("size64 = size32 = 0x%lx\n", size64);
    printf(" 32 bits from an int assigned to long int on an OSF1 Alpha :-)\n");
}

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 10:11:54 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2utmev$9o2@cherokee.advtech.uswest.com> crohrer@advtech.uswest.com (Chris Rohrer) writes:
>I'm trying to understand just what the relationship between maximum IP packet
>size and MTU size really is.

RFC 1122 has a section on MTU.

>It had always been by understanding only routers would do fragmentation
>and that hosts would just obey the MTU limitation on their local nets and
>generate packets of the appropriate size with no IP fragmentation
>indicated in the IP header.  And further, that the MTU limitation would be
>"visible" to higher layers, well at least to layer 4.

Hosts aren't REQUIRED to do fragmentation, but they are permitted to;
receivers are required to be able to reassemble, whether the packet
originated on the local net or was routed.  Implementations based on BSD
Unix will fragment anything but a broadcast packet.  My expectation is that
most host implementations that are capable of acting as a router will
fragment packets it originates, since the transmission routine is usually
in a layer that doesn't care whether the packet originated locally.

The next higher layer is supposed to be able to find out the MTU.  TCP
implementations usually use this to compute the MSS option, to try to avoid
fragmented TCP segments.  The layer above UDP should also be able to find
out the MTU, since UDP broadcasts won't be fragmented and the application
may need to take this into account (for instance, routed sends out multiple
packets if the routing table doesn't fit in a single UDP packet).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 19:51:20 -0500
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP Question

In article <2uvga0$4eu@clarknet.clark.net>, wwds2@clark.net () writes:
|> I am considering building a fault tolerant system containing two (up to 
|> four) seperate networks (ethernet or FDDI) to allow for failures. Each 
|> computer in the system will be connected to at least two of the networks.
|> I need to establish reliable (as in TCP vs UDP) connections between 
|> computers. 
|> 
|> I have been told that OSI protocols will handle switching between the two or 
|> more possible networks to establish connections without my writing specific 
|> code to do so. I have also been told that TCP/IP will not support this.
|> 
|> Can anyone tell me what OSI protocol or service provides this function 
|> and whether or not similiar operations can be performed using TCP/IP?
|> 
|> I'd like to stay with one protocol and TCP/IP is necessary for the SNMP 
|> managemment.


you need to identify what faults you anticipate mostly to build a fault tolerant network

if you believe the links will fail most, then  a reduent link network interconnected by
routers wil work for OSI TP4/CLNP and TCP/IP

however, if you cannot trust routers either then you need multi-homed hosts on your replicated
ethers or fddis

then you have a problem with TCP, as for each network interface, you have to have a seperate
IP address, but if an interface breaks, a TCP connection cannot continue as part of the TCP
"connection id" is the IP address....

however ,there are many products that will switch between redundent ethers _below_ the IP
level

with FDDI, ayo uget the option of DAS (Dual Attached Stations/ring) which again is below the
IP level

in OSI, the TP4 connectio nis a reference number once made, so the CLNP level can migrate...


-- 
jon crowcroft (hmmm...)

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 14:23:39 GMT
From:      bansal@ccrl.nj.nec.com (Vivek Bansal)
To:        comp.protocols.tcp-ip
Subject:   STREAMS, TLI ...


TLI or Sockets, what are the (dis)advantages of providing either as APIs
to the application. Has there been any comparision done in terms of
there performance and functionality ?

Secondly I would like to know the performance benefits in implementing
of implementing any TCP/IP like protocol in STREAMS as compared to a
the way it is implemented in BSD.

Any responses that I get to my account, I will post it on the net....

Vivek...

bansal@ccrl.nj.nec.com

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 14:35:34 GMT
From:      crohrer@advtech.uswest.com (Chris Rohrer)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2uvmhu$k2q@acsc.com>, Rao Srinivasa <rao@acsc.com> wrote:
>In article <2utmev$9o2@cherokee.advtech.uswest.com>, crohrer@advtech.uswest.com (Chris Rohrer) writes:|> Hi all,
>|> 
>|>  
>|> My real question is more like this: Will "typical" host IP software obey
>|> this 1500 byte restriction and tell its users (TCP, UDP and possibly other
>|> entities) that THEIR maximum "block" size is of that same approximate
>|> value (1500 minus the IP overhead)?  Or will this "typical" IP software
>|> present a 64k-sized interface to its layer 4 users and take the initiative
>|> to do real header-mediated IP fragmentation down to the 1500 byte size?
>|> 
>   As far as I know IP does the fragmentation and assembling of the 
>   packets ....
>   I look at it this way ..
>	
>    If I open an UDP socket and write data which is more than 1500 bytes 
>     it reaches the peer without any problem ...
>
>    So either UDP or IP does this work ...
>
>    If UDP does this work then it has to done by TCP too ...
>
>    So I feel( that's not what you want though ..) IP does this work for both UDP and TCP.
>    
>     Lets wait for others say ...Mean while I will dig in to some UDP/IP books ..
>
>
>Rao.

The consensus of the responses I've received so far indicate that TCP will
be "well-behaved" and set its MSS or Maximum Segment Size to a number equal
to the datalink layer's MTU limitation minus room for the IP header.  So on
an Ethernet based system, with an MTU of 1500 bytes, TCP would create
segments 1480 bytes in length.  In this way, the transmitted IP packets
would not be fragmented, they'd be just the right size.

However, with a protocol stack based on UDP, things are not so nice.  For
example, I have oberved NFS PDUs greater than 8000 bytes in length that are
chopped up into sequences of Ethernet frames of 1500 bytes each, all having
the fragmentation fields used.

I would expect that, in general, other applications are going to do the
exact same thing when operating over UDP, that is, they'll hand a block of
data to IP expecting that it will do this fragmentation operation.

I had thought that the applications would have been better behaved and do
this chopping up themselves.  But if the mechanism exists in IP
implementations to perform this useful function, then why not use it?

After all, by making use of the fragmentation mechanism for reassembly in
the receiver, problems of mis-ordered packets can be taken care of at the
network layer where they belong.  This thus allows applications to not have
to worry about this particular problem.

Chris Rohrer

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 15:31:48 GMT
From:      Per.Weisteen@hda.hydro.com (Per Weisteen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Microsoft's Windows Internet Name Service?

In article <2utpqi$1b4@usenet.INS.CWRU.Edu>, bq274@cleveland.Freenet.Edu (Andy J. Berkvam) says:
>
>
>In a previous article, phil@lykos.netpart.com (Phil Trubey) says:
>
>>Does anyone have some detailed info about Microsoft's new 
>>Windows Internet Name Service that they will be offering in their upcoming
>>TCP/IP products?  I remember reading somewhere that it was similar to DNS, but
>>not, in fact, DNS.  Does this mean that large sites that currently use DNS
>>will have to maintain two machine naming systems?
>>
>>Thanks for any info,
>
>'lo
>
>  As I understand it, another server will be required.  The Wolverine
>TCP stack put out by Microsoft for WfW 3.11 uses it.
>
>  Check out http://www.microsoft.com/wolverine.  There's some
>information out there.  For more info, get the actual Wolverine release
>and read the Windows Help file.  (No need to install, just unzip it and
>load it into Windows Help.)  All sorts of good info on the new name
>resolution, DHCP, etc.
>
>Andy
>

I read somewhere that it only does host->address lookups and not
address->host (in-addr.arpa domains). Which means it's useless 
in a real Internet environment.

+-----------------------------------------------------------------------+
| Per Weisteen          Email: Per.Weisteen@hda.hydro.com               |
| Hydro Data            Phone: +47 2273 8227                            |
| Norsk Hydro           "It is better to light a candle,                | 
| Norway                 no matter how small, than to curse darkness"   |
|                                                  Kung-fu-tse          |
 +-----------------------------------------------------------------------+

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 15:41:39 GMT
From:      Per.Weisteen@hda.hydro.com (Per Weisteen)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for dynamic-assignment BOOTP

In article <1994Jun30.160105.6475@ivax>, imhw400@indyvax.iupui.edu (Mark H. Wood) says:
>
>I'm looking for *any* implementation of BOOTP that can dish out cynamically-
>assigned addresses to hosts on subnets other than its own.  I would have
>thought that this was commonplace, but I find now that the only implementation
>of dynamic assignment I can find has no way to express the desire for address
>pools per-subnet.  Yes, I know this presents some nasty problems (someone who
>wonders what they are would do well to start by reading my own analysis), but I
>need the capability anyway if it has been done.  Any pointers would be
>appreciated.
>-- 
>Mark H. Wood, Lead Systems Programmer    +1 317 274 0749   [@disclaimer@]
>Internet:  MWOOD@INDYVAX.IUPUI.EDU       BITNET:  MWOOD@INDYVAX
>"It's *better* than good -- it's CHEAP!" - Cosmo Spacely

DHCP protocol (RFC 1541  ++) is a new protocol which does exactly
what you want. I know Microsoft has implemented this for NT and I think
SUN has a version out "real soon now" , and yes Novell is also supposed
to have one implemented as a NLM for their 4.x Netware.

I'm desperately looking for a UNIX source. I'd hate to be in the hands of those
PC-guys talking IP.... ;-)
 
+-----------------------------------------------------------------------+
| Per Weisteen          Email: Per.Weisteen@hda.hydro.com               |
| Hydro Data            Phone: +47 2273 8227                            |
| Norsk Hydro           "It is better to light a candle,                | 
| Norway                 no matter how small, than to curse darkness"   |
|                                                  Kung-fu-tse          |
 +-----------------------------------------------------------------------+

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jul 1994 19:41:01 GMT
From:      salman@aplcenmp.apl.jhu.edu (Ashfaq salman (703) 516-7616)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.programmer.networks,comp.sys.ibm.pc.hardware.misc,comp.os.os2.networking
Subject:   WTB: Info on Schneider & Koch ethernet cards

Hello,
 
I badly need "any info" on the following cards:
 
They are make by a German company Schneider & Koch and cards are 16-bit
ethernet adapters. The software tries to identify them as SK-Junior
boards.
 
I am particularly interested in getting Novell, Windows, etc. drivers for it.
I only have netbios software for it. I don't have any other documentation
on it. Any information about its compatibility or the company will be greatly
appreciated. Thanks in advance.
 
-Salman
salman@lccinc.com


-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jul 1994 20:53:28 GMT
From:      yuvalt@silver.weizmann.ac.il (Tal Yuval)
To:        comp.protocols.tcp-ip
Subject:   Installing SLIP

Hi,

I am trying to make SLIP work in my site and I have a question: Our
network is class C (ie the subnetmask is 255.255.255.0), our computers are
on network 132.76.80 (wisdom.weizmann.ac.il).

My question is: If I want to connect a SLIP machine to the network
(lets say that the host is 132.76.80.121), do I have to create a new
network (i.e. 132.76.81) and make 132.76.80.121 its gateway or can I
put my SLIP machine on the same IP network?

I succeeded in creating a new subnet but I was wondering if the other
method also works. If it does, what is the configuration of the SLIP
host and the SLIP machine.

Thanks,

-Yuval

--

Yuval Tal, System programmer // Faculty of mathematics
yuvalt@wisdom.weizmann.ac.il // Weizmann Institute Of Science, Rehovot, Israel

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jul 1994 21:15:24 GMT
From:      John Martinez <martinez@rahul.net>
To:        comp.protocols.tcp-ip
Subject:   Public Domain TCP/IP


I didn't see this in the FAQ, but does anyone know of a public domain/freeware
implementation of TCP/IP for DOS PC's?

Please post or email.

Thanks.
-- 
# John Martinez (martinez@bats.com) UNIX System Administration Consultant
# Bright Apex Technology Services   San Jose, California, USA

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 21:39:58 GMT
From:      vern@daffy.ee.lbl.gov (Vern Paxson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPDUMP-3.0

In article <2uucjd$alg@helios.intranet.gr>,
Antonis Kyriazis (ext-1122) <antonis@intranet.gr> wrote:
# I'm trying to build tcpdump (I made also libpcap->libfl.a) and
# ld cannot find _yy_flex_realloc, _yy_flex_free and _yy_flex_alloc.
# Does one know what is missing here?

You need to upgrade to flex 2.4.6, which you can get from ftp.ee.lbl.gov.

		Vern

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Jul 1994 00:15:32 GMT
From:      hsm@unislc.slc.unisys.com (Helge Moulding)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Chris Rohrer wrote,
: [...asked about IP datagram sizes, and MTU sizes...]

IP hosts originating messages try to avoid fragmenting by using
the MTU size information. Routers shouldn't have to do a lot of
fragmenting, for the same reason. This is done because fragmenting
is quite expensive...

The MTU size is not just dependent on the network 
connected to the local interface, but on the smallest frame
size of all the frame sizes between the two hosts at the
end points, and may even be affected by buffer sizes of intervening routers.
TCP protocol implementations try to dynamically
adjust the transmitted segment size to account for network
load, etc.

Try RFCs 1435, 1191, 1063, 879, and 813 for more information.
(Heck, you probably already did, right?)
--
	Helge "Some advice is free" Moulding
	(Just another guy with a weird name)

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Jul 1994 05:45:45 GMT
From:      aboba@netcom.com (Bernard Aboba)
To:        comp.protocols.tcp-ip
Subject:   Round robin DNS?

I am told that the latest version of BIND supports load balancing
via "round robin" DNS. I am interested in how well this works,
pointers to docs, etc.

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 94 11:58:00 GMT
From:      tom.lewis@ftl.mese.com (Tom Lewis)
To:        comp.protocols.tcp-ip
Subject:   Slip connection info

Would this be a good newsgroup to ask some basic questions about
connecting a W4WG 3.11 network to internet through a Slip connection?
If not, I would appreciate it if someone would refer me to a more
appropriate area. If someone would just give me a list of WinSock apps
that I need to procure and where they can be obtained it would be very
helpful. I think I understand how things work. What I need is a simple
presentation of the specifics. Thanks...
---
. QMPro 1.52 . Internet: tom.lewis@sharpcor.com


-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Sun, 03 Jul 94 00:43:21 cdt
From:      hgwill@zilker.net
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.ms-windows.programmer.networks,comp.os.ms-windows.networking.tcp-ip
Subject:   Re: NCSA Winsock


In article <9406292355.AA12980@ariake.nwk.cl.nec.co.jp>, 
<mweiss@nwk.cl.nec.co.jp> writes:
> Winsock.  Also if anyone knows the email address of its creators, please
> let me know.

Try: mosaic-win@ncsa.uiuc.edu
That's the email address of the creators for Mosaic, and to submit bug reports 
on the product.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1994 04:07:10 GMT
From:      frank@vcsun1.tamu.edu (Franklin S. Cheng)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Multicast

You can also take a look at a popular doc named IPmulticast.README under
/vmtp dir @ havefun.stanford.com , where you will find some programming
example and explanations.

Regards,
Frank


--
Franklin S. Cheng                     | <email>: frank-cheng@tamu.edu
Multimedia & Networking Lab           | tel: (W) 409-845-5774
Department of Electrical Engineering  |      (H) 409-268-8293
Texas A&M University , College Station, Texas 77843          

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Sun, 3 Jul 94 04:39:14 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Annex and general SLIP information needed (soon)

	An organization here is going to be soon providing SLIP
access.  However, they plan to use dynamic IP address assignment on a
per-port basis. In other words, connection on a given port gives you a
given IP address. They are using Xylogics Annex terminal servers (one
of them quite new, supposedly supports both SLIP/CSLIP and PPP). There
is going to be authentication of individual users.
	Unfortunately, dynamic IP address assignment would be a
headache for me and many other users. It would make it impossible to
run ftp/http and other servers, and would even make it very difficult
to find our own machine to telnet back into if we wanted to connect to
it through the Internet. It is especially hard for those that have
un*x based machines, (e.g. Linux)
	The justification given is that static IP addresses are harder
to set up and that they could run out.
	Anyone have any pointers to documents and information on
static versus dynamic IP address assignment, or on Annex terminal
server configuration? Especially information on the benefits of static
addressing and how to configure it on a Xylogics Annex. Any
information would be appreciated, as soon as possible (things are
moving very quickly).
	Does anyone know why stty fwdtimer x where x is less than 5
(the default) says I can't lower it? Also, if an Annex is in non-SLIP
mode, does it hold characters (e.g. use the Nagle algorithm)? Could
this be turned off on a port by a regular user for that session? This
information might be helpful for another project that I may have to
undertake soon.
	I hope to be able to convince the people in charge of SLIP to
use static based IP addressing, but I want to confirm that I have all
the relevant facts. Thus any information would be greatly appreciated.


-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1994 08:27:44 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2v19jm$k2i@cherokee.advtech.uswest.com> crohrer@advtech.uswest.com (Chris Rohrer) writes:
>I had thought that the applications would have been better behaved and do
>this chopping up themselves.  But if the mechanism exists in IP
>implementations to perform this useful function, then why not use it?

Because it can cause problems.

I know of some systems whose ethernet interface can only buffer 2 frames at
a time.  When a Sun sends 6 back-to-back frames as a result of fragmenting
an 8K UDP datagram from NFS, the last two packets are always dropped.
Eventually the request times out, it retries, and the same thing happens on
the retransmission.  When we discovered this was happening we changed this
system's equivalent of the "rsize" parameter.

Even ignoring such pathological situations, it can generally cause
performance problems.  If a datagram is fragmented, loss of one of the
packets will require all of them to be retransmitted.  If you break the
data up in the layer that implements retransmission, it can retransmit only
the lost packet.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Sun, 03 Jul 1994  14:51 ET
From:      gmangum@umich.edu  (Gene Mangum)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for PC/TCP 3.X

In Article <2uptcp$j59@news.CCIT.Arizona.EDU> "feng@bigdog.engr.arizona.edu (Gene Feng)" says:
> I heard that the new PCT/CP shareware program had come out.  I wonder if
> anyone could tell me where it is (I have verson 2.1).  Thank you much.
 
  First, PC/TCP is not shareware, it's a commercial product.   Second, 
  version 3.0 is not out yet.

+=================================+=========================================+  
| Gene Mangum                     |  OS/2 ver 2 - Increased productivity    |
| Univ of Michigan Hospitals      |               through the use of a      |
| h198@hosp.med.umich.edu         |               "dead" operating system.  |
+=================================+=========================================+


-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Sun, 3 Jul 1994 19:49:13
From:      karl@cavebear.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2v73ru$q7b@hpindda.cup.hp.com> raj@cup.hp.com (Rick Jones) writes:
>
>Poppycock!-) IP framentation is simply a matter of pointer
>manipulation and perhaps some scatter-gather abilities in the DMA
>hardware. IP fragmentation being perceived as "expensive" is more
>likely a function of IP fragmentation being left up to a router's
>(underpowered) main CPU instead of VLSI.

Fragmentation isn't so hard, but you should try your hand at writing a good 
solid reassembly engine.  It isn't easy and if done wrong can be a real memory 
hog.  There are many implementations out there that don't do it right in all 
cases (such as when the first fragment arrives first or when fragments overlap 
rather than simply abut one another.)

                  --karl--

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 94 23:15:01
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

    : Routers shouldn't have to do a lot of
    : fragmenting, for the same reason. This is done because fragmenting
    : is quite expensive...

    Poppycock!-) IP framentation is simply a matter of pointer
    manipulation and perhaps some scatter-gather abilities in the DMA
    hardware. IP fragmentation being perceived as "expensive" is more
    likely a function of IP fragmentation being left up to a router's
    (underpowered) main CPU instead of VLSI.

Regardless of whether fragmentations "should" be expensive or not, the fact
remains that it \IS/ in most (all?) currently popular routers.  Since
fragmentation is generally considered a bad idea regardless of the expense
in routers, router vendors are not very motivated to improve the state of
affairs.  There are more important things to do...

BillW


-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1994 19:34:22 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Helge Moulding (hsm@unislc.slc.unisys.com) wrote:
: Routers shouldn't have to do a lot of
: fragmenting, for the same reason. This is done because fragmenting
: is quite expensive...

Poppycock!-) IP framentation is simply a matter of pointer
manipulation and perhaps some scatter-gather abilities in the DMA
hardware. IP fragmentation being perceived as "expensive" is more
likely a function of IP fragmentation being left up to a router's
(underpowered) main CPU instead of VLSI.

rick jones
speaking only as rick jones...


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 11:15:51 -0600
From:      dbform@tibalt.supernet.ab.ca (Data Business Forms)
To:        comp.protocols.tcp-ip
Subject:   IP Address

I am having a problem changing a workstations IP address.  The address of 
the server is 192.0.0.250 (I think this is the problem) and the address 
of the workstation is 192.0.0.122  I want to change the workstation 
address to 192.10.10.1  but when I do this the workstation cannot connect 
and it hangs up.  I have to do a cold boot to get the PC to work again.  
What is wrong with the scheme?

				David Wood


-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 13:46:26 -0700
From:      schmidt@tango.ics.uci.edu (Douglas C. Schmidt)
To:        comp.client-server,comp.object,comp.lang.c++,comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Object-oriented network programming components now available

       Version 2.14.3 of the ADAPTIVE Communication Environment (ACE)
object-oriented network programming toolkit is now available for
anonymous ftp from the ics.uci.edu (128.195.1.1) host in the
gnu/C++_wrappers.tar.Z file (approximately .5 meg compressed).  This
release contains contains the source code, documentation, and example
test drivers for C++ wrapper libraries and higher-level network
programming frameworks developed as part of the ADAPTIVE project at
the University of Calfornia, Irvine.

        o The contents of this release encapsulate the following 
          user-level BSD and System V Release 4 (SVR4) IPC facilities
          via type-secure, object-oriented C++ interfaces:

                o Internet and UNIX-domain sockets (including
                  broadcasting) and TLI 
                o Event multiplexing via select and poll
                o named pipes (FIFOs) and STREAM pipes (plus connld) 
                o the mmap family of memory-mapping APIs
                o System V IPC (i.e., shared memory, semaphores,
                  message queues) 
                o SVR4 explicit dynamic linking facilities (i.e.,
                  dlopen/dlsym/dlclose) 

        o In addition, there are also a set of higher-level network
          programming frameworks that integrate and enhance the
          lower-level C++ wrappers to support the dynamic
          configuration of concurrent network daemons composed of
          complex distributed application services 

        Many of the C++ wrappers and higher-level components have been
described in issues of the C++ Report, as well as in the proceedings
of (1) the 2nd C++ World conference, October 1993, (2) the 11th and
12th Annual Sun Users Group Conference in December 1993 and June 1994,
(3) the 2nd International Workshop on Configurable Distributed
Systems, March 1994, the 6th USENIX C++ Conference in April 1994, the
9th OOPSLA Conference to be held in October 1994, and the 3rd C++
World conference in November 1994.

        ACE components are currently being used in a number of
commercial products including the AT&T Q.port ATM signaling software
product, the Ericsson EOS family of PBX monitoring applications, and
the network management portion of the Motorola Iridium mobile
communications system.

        A relatively complete set of documentation and extensive
examples are included in the release.  The current release has been
tested fairly extensively on Sun workstations running Sun OS 4.1.x and
Solaris 2.x using GNU G++ and Sun C++ 3.x and 4.x.  Portions of the
release have also been ported to SCO UNIX, HP-UX, OSF/1, Windows 3.1
and Windows NT.  I expect that major portions of the release will port
easily to other platforms.  If anyone is willing to help coordinate
ports to other platforms please let me know.

        A mailing list is available for discussing bug fixes,
enhancements, and porting issues regarding ACE.  Please send mail to
ace-users-request@ics.uci.edu if you'd like to become part of the
mailing list.

CONTENTS OF THE RELEASE

        The following subdirectories are included in this release:

        o apps    -- complete applications written using the ACE wrappers
        o bin     -- utility programs for building this release
        o build   -- a separate subdirectory that keeps links into the main
                     source tree in order to facilitate multi-platform
                     build-schemes
        o include -- symbolic links to the include files for the release
        o lib     -- object archive libraries for each C++ wrapper library
        o libsrc  -- the source code for the following C++ wrappers:
                        ASX -- higher-level C++ network programming framework
                        Get_Opt -- a C++ version of the UNIX getopt utility
                        SOCK_SAP -- wrapper for BSD sockets
                        TLI_SAP -- wrapper for SVR4 TLI 
                        FIFO_SAP -- wrapper for FIFOS (named pipes)
                        SPIPE_SAP -- wrapper for SVR4 STREAM pipes and connld 
                        Log_Msg -- library API for a local/remote
                                   logging facility 
                        Mem_Map -- wrapper for BSD mmap() memory mapped files 
                        Message_Queues -- wrapper for SysV message queues
                        Reactor -- a framework for event
                                   demultiplexing and dispatching 
                        Semaphores -- wrapper for SysV semaphores
                        Service Configurator -- a framework for
                                                dynamically linking/unlinking
                        Shared_Memory -- wrapper for SysV shared memory
                        Shared_Malloc -- wrapper for SysV/BSD shared mallocs 
        o tests -- programs that illustrate how to use the various wrappers

Please refer to the INSTALL file for information on how to build and
test the ACE wrappers.  Due to the large size of the release (~2 Meg)
I'm sorry that I will be unable to distribute the ACE wrappers via
email.  The BIBLIOGRAPHY file contains information on where to obtain
articles that describe the ACE wrappers and the ADAPTIVE system in
more detail.

        Also, please note that there are companion tar files called
C++_wrappers_doc.tar.Za[a-c].  These files are in the same ftp/gnu
directory as the source code distribution and contain the following
subdirectories from the ACE release:

        o doc     -- LaTeX documentation (in both latex and .ps format)
        o papers  -- postscript versions of various papers describing ACE 

I used the UNIX "split" command to make sure each of these files is
less than 1.2 Meg in size to accommodate ACE users who only have
access to modem connections on PCs.  To recreate the original tar
file, simply to the following:

% cat C++_wrappers_doc.tar.Za[a-c] doc.tar.Z
% uncompress doc.tar.Z
% tar xvf doc.tar

COPYRIGHT INFORMATION

        You are free to do anything you like with this code.  However,
you may not do anything to this code that will prevent it from being
distributed freely in its original form (such as copyrighting it,
etc.).  Moreover, if you have any improvements, suggestions, and or
comments, I'd like to hear about it!  It would be great to see this
distributed evolve into a comprehensive, robust, and well-documented
C++ class library that would be freely available to everyone.
Natually, I am not responsible for any problems caused by using these
C++ wrappers.

        Thanks,
        
                Douglas C. Schmidt
                (schmidt@ics.uci.edu)
                Department of Information and Computer Science
                University of California, Irvine
                Irvine, CA 92717
                Work #: (714) 856-4105
                FAX #: (714) 856-4056

ACKNOWLEDGEMENTS
        
        Special thanks to Paul Stephenson for devising the recursive
Makefile scheme that underlies this distribution, as well as for
devoting countless hours to discussing object-oriented techniques for
developing distributed application frameworks.  

	Thanks to Olaf Kruger for explaining how to instantiate
templates for shared libraries on SunOS 4.
-- 
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 11:47:31 -0400
From:      berke@panix.com (Wayne Berke)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In <karl.2.0013D29E@cavebear.com> karl@cavebear.com (Karl Auerbach) writes:

>In article <2v73ru$q7b@hpindda.cup.hp.com> raj@cup.hp.com (Rick Jones) writes:
>>
>>Poppycock!-) IP framentation is simply a matter of pointer
>>manipulation and perhaps some scatter-gather abilities in the DMA
>>hardware. IP fragmentation being perceived as "expensive" is more
>>likely a function of IP fragmentation being left up to a router's
>>(underpowered) main CPU instead of VLSI.
 
>Fragmentation isn't so hard, but you should try your hand at writing a good 
>solid reassembly engine.  It isn't easy and if done wrong can be a real memory 
>hog.  There are many implementations out there that don't do it right in all 
>cases (such as when the first fragment arrives first or when fragments overlap 
>rather than simply abut one another.)


Reassembly might be considerably more complex than fragmentation, but it only
gets done on end-systems, never on routers.  And I believe the original reference
was to the cost of fragmentation on routers.

>                  --karl--

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 10:18:10
From:      karl@cavebear.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU


>Reassembly might be considerably more complex than fragmentation, but it only
>gets done on end-systems, never on routers.  And I believe the original reference
>was to the cost of fragmentation on routers.

There is a strong argument to be made that when one does fragmentation, that 
the first fragment which should be sent is the last fragment.

The reason for doing this is that the receiver has no idea how big the 
reassembled packet will be until the last fragment is received.  If the 
receiver is "lucky" enough to get the last fragment first, it has a chance to 
allocate an appropriate size reassembly buffer.

Of course, some commercial implementations have been known to crash if they 
get the last fragment first.

        --karl--



-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 07:55:37 GMT
From:      albertk@cs.kun.nl (Albert Koppes)
To:        comp.protocols.tcp-ip
Subject:   FTP timers modification ?



On a SUN Sparc 10 Solaris 2.3 we are initiating
an ftp-session. 

If the remote host/network is not reachable the ftp
application will time out only after 8 times trying
to send an SYN-segment to connect to the other control-port.
With the exponential backoff
timers this takes about 4 minutes. For out operational
system this is too long.


1. How does on change the number of retries, or the timer
behaviour (preferable via the ndd utility in Solaris 2.3)


2. We have looked at a ftp-implementation (ftp.c, bsd-alike)
but this implementation is only issueing one (1) connect()-call.
Does somebody know where one can find the source of an ftp-imple
mentation that is similar to the Solaris 2.3 one.

Thank you in advance ,



Frank Zeppenfeldt
EUMETSAT
albertk@zeus.cs.kun.nl
tel: +49 6151 950236
fax: +49 6151 950225



-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 08:06:57 GMT
From:      wgaige@netcom.com (Wesson E. Gaige)
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN, Lan-to-Internet & TCP-IP

In article <2usese$euo@www.interramp.com>, fedor@interramp.com wrote:

> In article <mhuff@zilker.net> writes:
> 
> 
> BTW, PSI does not have an ISDN presence in Austin yet.... hopefully soon.
> 
> send mail to info@psi.com if you have any questions...
> 

Will you have an ISDN presence in Dallas when SWBell starts offering it
here in the fall?

-- 
| Wesson E. Gaige                   | wgaige@netcom.com              |
| Manager, PC and Network Support   | WesGaige@aol.com               |
| Parkland Memorial Hospital        | 75046.1461@compuserve.com      |
| Dallas, Tx                        |                                |
|-----------------------------------|--------------------------------|

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 10:06:33 GMT
From:      reinken@tu-harburg.d400.de
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.programmer.networks,comp.sys.ibm.pc.hardware.misc,comp.os.os2.networking
Subject:   Re: WTB: Info on Schneider & Koch ethernet cards

In <CsA1CD.M3v@aplcenmp.apl.jhu.edu>, salman@aplcenmp.apl.jhu.edu (Ashfaq salman (703) 516-7616) writes:
>Hello,
> 
>I badly need "any info" on the following cards:
> 
>They are make by a German company Schneider & Koch and cards are 16-bit
>ethernet adapters. The software tries to identify them as SK-Junior
>boards.
> 
>I am particularly interested in getting Novell, Windows, etc. drivers for it.
>I only have netbios software for it. I don't have any other documentation
>on it. Any information about its compatibility or the company will be greatly
>appreciated. Thanks in advance.
> 
>-Salman
>salman@lccinc.com
>

The adress of the company is :

       Siemensstraáe 23
       D - 76275 Ettlingen

Voice-Mail : 49 7243 / 502 - 0
        Fax : 49 7243 / 502 - 989

You normaly get all drivers with the card. There is a driver packet called SK - UPPS (universal programmel
prtocol stack) you can use to communicate with novell (ipx, spx) and unix-workstation (tcp/ip) at the same
time. This driver packet should be send with your SK-Junior board i think. 

Wolfram Reinken

E- Mail : reinken@tu-harburg.d400.de
       or rztwr@molly.rz.tu-harburg.de

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 22:19:52 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PACKET  DRIVER

I am attempting to use WATTCP (in DOS) with an Allied Telesis Ethernet
board (I believe manufactured by FTP inc.)

Can someone please reccomend a good packet driver that is available by ftp?

Thanks,

--Mike

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 10:49:16 +0200
From:      Herbert.Hotz@alcatel.ch (Herbert Hotz)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.programmer.networks,comp.sys.ibm.pc.hardware.misc,comp.os.os2.network
Subject:   Re: WTB: Info on Schneider & Koch ethernet cards

In article <CsA1CD.M3v@aplcenmp.apl.jhu.edu> salman@aplcenmp.apl.jhu.edu (Ashfaq salman (703) 516-7616) writes:

>Hello,
> 
>I badly need "any info" on the following cards:
> 
>They are make by a German company Schneider & Koch and cards are 16-bit
>ethernet adapters. The software tries to identify them as SK-Junior
>boards.
> 
>I am particularly interested in getting Novell, Windows, etc. drivers for it.
>I only have netbios software for it. I don't have any other documentation
>on it. Any information about its compatibility or the company will be greatly
>appreciated. Thanks in advance.
> 
>-Salman
>salman@lccinc.com

Would be interested too. Does SK have any drivers for their network products
foor WindowsNT? Do they offer support on the internet?

Kind regards
Herbert



Herbert Hotz (3.278) | Tel: +41-1-465 2249                 Fax: +41-1-465 3525 |
Alctatel STR AG      | INTERNET: Herbert.Hotz@alcatel.ch                       |
Friesenbergstr. 75   | X.25:     PSI%4795123920::H_HOTZ                        |
CH-8055 Zurich       | X.400:    C=ch ADMD=arcom PRMD=Alcatel S=Hotz G=Herbert |

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 15:01:34 GMT
From:      ronald@demon.co.uk (Ronald Khoo)
To:        comp.protocols.tcp-ip
Subject:   Re: HLLAPI TN3270 over Winsock

In article <Jun.28.09.57.53.1994.15307@remus.rutgers.edu>,
Richard Kao <rtkao@remus.rutgers.edu> wrote:

>There are several commercial vendors...
>Attachmate Extra For Windows
>Wall Data's Rumba 3270 for Windows
>DCA's IRMA Workstation for Windows
>These are the more popular ones.


Also NetSoft.  Try chanr@netsoft.mhs.compuserve.com for details.

Disclaimer: In my other life I work for a NetSoft distributor, although I
have nothing to do with that product line

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 20:52:53
From:      karl@cavebear.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Reassembly.  Was: Re: Max IP packet length and MTU




>karl@cavebear.com (Karl Auerbach)
>> There is a strong argument to be made that when one does fragmentation, that 
>> the first fragment which should be sent is the last fragment.
>> 
>> The reason for doing this is that the receiver has no idea how big the 
>> reassembled packet will be until the last fragment is received.  If the 
>> receiver is "lucky" enough to get the last fragment first, it has a chance to 
>> allocate an appropriate size reassembly buffer.
 
>There is an argument that allocating a reassembly buffer is a mistake.
>That implies that you are doing extra copying at precisely the worst
>moment - when somebody (likely NFS) is trying to get bulk data across
>the wire.  Or are you talking about the reassembly queue data
>structure?  With some work, you can use the headers for that.... 

I suspect that you are thinking of Un*x/BSD code constructs.  My concern is 
about reassembly in general.  When I say "reassembly buffer" I mean that one 
is allocating space to put the packet.  In memory rich environments I would 
guess that people could allocate 64K byte buffers in anticipation of even the 
largest possible size of IP reassembled packet.  In lesser environments, such 
as pre-windows PCs and many embedded controller systems, it is important to 
try to be careful about wasted buffer space.

I've made the argument a few times to the IPng folk, but never very strongly, 
that whatever happens in IPng, one should be able to know the reassembled size 
from any fragment, not just the last one.

(It would also be nice if TCP stacks would have some way to tell the 
underlying IP that they are retransmitting an *identical* segment, so that IP 
can assign the same IP ID as the original packet.  That way, the fragments 
from the first and subsequent retransmissions could be aggregated at the 
receiver.  The way it is done today, with different IP ID values, reassembly 
is not possible even though all the pieces may be present at the receiver.)

            --karl--
 

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 16:21:39 GMT
From:      jdam@cs.uml.edu (jack tam)
To:        comp.protocols.tcp-ip
Subject:   Setting slip at home

Hi,
I am looking for pointers on how to set up SLIP at home.
Wonder if the FAQ discusses this. If it does, where is it?
Thank you
Jack


-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 16:23:27 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <BILLW.94Jul3231501@glare.cisco.com> billw@glare.cisco.com (William ) writes:
>    : Routers shouldn't have to do a lot of
>    : fragmenting, for the same reason. This is done because fragmenting
>    : is quite expensive...
>
>    Poppycock!-) IP framentation is simply a matter of pointer
>    manipulation and perhaps some scatter-gather abilities in the DMA
>    hardware. IP fragmentation being perceived as "expensive" is more
>    likely a function of IP fragmentation being left up to a router's
>    (underpowered) main CPU instead of VLSI.
>
>Regardless of whether fragmentations "should" be expensive or not, the fact
>remains that it \IS/ in most (all?) currently popular routers.  Since
>fragmentation is generally considered a bad idea regardless of the expense
>in routers, router vendors are not very motivated to improve the state of
>affairs.  There are more important things to do...

That is an overstatement based on the prejudices of the designers at a
particular vendor.  It's circular reasoning.  Since fragmentation is
considered unimportant, Cisco does not do it fast, which makes many of
us have those familiar arguments with Cisco people about how hard
fragmentation is and since it is slow, it must be unimportant.

It is also just plain wrong.  For UDP/IP based applications such as NFS,
it makes no sense for FDDI hosts to fragment to 1500 just so that
FDDI-Ethernet routers and bridges won't be stressed.   The usual Cisco
response to that point is to demand hosts implement MTU path discovery,
which is a good thing for TCP, but unreasonable for UDP, what with the
statelessness of NFS, subnetting, and the bad experiences Sun Microsystem's
customers have had recently with bridges and routers that don't handle
the DF bit right.

Consider the speed of Digital's FDDI-Ethernet bridges which can bridge
several Ethernets to an FDDI ring at 100% of the speed of 5 (or 6?)
Ethernets simultaneously, fragmenting as required.  I understand Cisco
has improved things, but a few years ago Cisco's FDDI-Ethernet
fragmentation speed on 4K NFS/UDP/IP/FDDI datagrams at one large customer
was a modest fraction of one Ethernet.  Of course a router is harder
than a bridge, but the fast paths should be similar and the Digital
boxes shows that IP fragmentation need not be such a big deal if one
puts asside prejudices about what is unimportant and necessarily slow.


Vernon Schryver    vjs@rhyolite.com

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 19:55:41 GMT
From:      micky@namaste.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   ttcp_fwd-like program available?

For those of you who don't know ttcp_fwd is a general purpose program
for reading in data over one port and forwarding it to another port.
Both tcp and udp are supported and connections are duplex.  Anyway,
enough of an advertisement for ttcp_fwd...

I am looking for a program that can take a socket connection as
input and fan it out to several other ports.  Does such an animal
exist yet?  If you know of any, I would appreciate any pointers
that you may be able to provide.

I know that this sounds like multicast and I have been looking into
using the MBONE software to achieve the same results, but I am
worrysome about having to make system level changes as well as
having to create special MBONE routers to go across LANs.  Basically,
I would be really happy with a 'user-level' multicast ability...

In any case, any guidance would be greatly appreciated.  Please try
to reply by email as I have a difficult time keeping up with netnews ;-)

Micky Liu
micky@ejv.com


-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 94 19:37:54
From:      vanklem@uk.ac.sbu.vax (Mike van Kleef)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

Got sent the full table of contents last year when I emailed the author
an enquiry regarding one of his other books. I've limited this message
to the main chapter headings; for those interested I can email the full
TOC.
Mike.
------------------------------------------------------------------
TCP/IP Illustrated, Volume 1: The Protocols, by W. Richard Stevens
Addison-Wesley, 1994  (available December 1993)
ISBN 0-201-63346-9

Chapter 1.  Introduction      1
Chapter 2.  Link Layer     21
Chapter 3.  IP: Internet Protocol     33
Chapter 4.  ARP: Address Resolution Protocol     53
Chapter 5.  RARP: Reverse Address Resolution Protocol     65
Chapter 6.  ICMP: Internet Control Message Protocol     69
Chapter 7.  Ping Program     85
Chapter 8.  Traceroute Program     97
Chapter 9.  IP Routing    111
Chapter 10.  Dynamic Routing Protocols    127
Chapter 11.  UDP: User Datagram Protocol    143
Chapter 12.  Broadcasting and Multicasting    169
Chapter 13.  IGMP: Internet Group Management Protocol    179
Chapter 14.  DNS: The Domain Name System    187
Chapter 15.  TFTP: Trivial File Transfer Protocol    209
Chapter 16.  BOOTP: Bootstrap Protocol    215
Chapter 17.  TCP: Transmission Control Protocol    223
Chapter 18.  TCP Connection Establishment and Termination    229
Chapter 19.  TCP Interactive Data Flow    263
Chapter 20.  TCP Bulk Data Flow    275
Chapter 21.  TCP Timeout and Retransmission    297
Chapter 22.  TCP Persist Timer    323
Chapter 23.  TCP Keepalive Timer    331
Chapter 24.  TCP Futures and Performance    339
Chapter 25.  SNMP: Simple Network Management Protocol    359
Chapter 26.  Telnet and Rlogin: Remote Login    389
Chapter 27.  FTP: File Transfer Protocol    419
Chapter 28.  SMTP: Simple Mail Transfer Protocol    441
Chapter 29.  NFS: Network File System    461
Chapter 30.  Other TCP/IP Applications    481

Appendix A.  The tcpdump Program    491
Appendix B.  Computer Clocks    499
Appendix C.  The sock Program    503
Appendix D.  Solutions to Selected Exercises    507
Appendix E.  Configurable Options    525
Appendix F.  Source Code Availability    539

Bibliography    543
Index    555            

 =================================================================
+ Mike van Kleef, Comp.& Maths, Southbank University, London, UK  +
+ Voice(071)-8157405 FAX(071)-8157499 EMail:vanklem@uk.ac.sbu.vax +
 =================================================================

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 09:17:30 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2v73ru$q7b@hpindda.cup.hp.com> raj@cup.hp.com writes:
>
>Poppycock!-) IP framentation is simply a matter of pointer
>manipulation and perhaps some scatter-gather abilities in the DMA
>hardware. IP fragmentation being perceived as "expensive" is more
>likely a function of IP fragmentation being left up to a router's
>(underpowered) main CPU instead of VLSI.

   Then on the LAN, if fragment 4 out of 23 is lost, the other 22
   don't have to be retransmitted?   

   Seems kinda expensive to me.




-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 22:28:13 GMT
From:      georgeb@netcom.com (George H. Bosworth)
To:        comp.infosystems.www,comp.infosystems.www.providers,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmps
Subject:   SEF/UniForum Open Systems SIG, Tues. July 12 -- Internet Panel

                  SEF/UniForum Open Systems SIG
                    (Formerly SEF Unix SIG) 

      "Taxis to the Super Highway" -- An Internet Start-Up Panel
      -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Our Tuesday July 12 meeting will feature three Internet activists who
  deliver Internet products and services to businesses, individuals, and
  government organizations who want to travel on the Information Super
  Highway, but don't know how and need an expert driver:

      Andrew Conru, Internet Media Services, conru@netmedia.com
      Matisse Enzer, Internet Consultant and Educator, matisse@well.sf.ca.us
      Gary Kremen, Electric Classifieds, info.set@match.com

  Hear these diverse entrepreneurs talk about the newest in Internet features,
  about careers in Internet, and about what Internet is and isn't as a
  target for new business.

  The world of Internet is changing so rapidly that YOU MUST either devote
  some time to learn and understand it -- or be left behind.

  Place:        Digital Equipment Corporation
                130 Lytton Street, Palo Alto CA
                (Corner of Alma, 1 block N. of University)

  Date & Time:  Tuesday, July 12, 1994, 7:00-9:00 p.m.

  Cost:         $10; free for SEF and UniForum members and DEC employees

  Information:  George Bosworth, Unix consultant, 415/851-3304,
                georgeb@netcom.com
  
  The Software Entrepreneurs' Forum and UniForum have combined forces
  to co-sponsor what used to be the SEF Unix SIG, and call it the
  SEF/UniForum Open Systems SIG. Same time and place, same objectives,
  but now backed by two major organizations.

  The Software Entrepreneurs' Forum, started in 1983, is a leading
  Silicon Valley-based non-profit organization dedicated to software
  professionals, with over 900 members. SEF informs and educates its
  members on all facets of the software industry.  SEF also sponsors 10
  other special interest groups, which meet once a month: Business
  Operations, Intelligent Systems, International, Macintosh, Marketing,
  Multimedia, Networking, Pen Software, Visual Basic, and Windows. Call
  415/854-7219 for more SEF information.
  
  UniForum, The International Association of Open Systems Professionals,
  is a vendor-independent, not-for-profit professional association that
  helps individuals and their organizations increase their Information
  Systems effectiveness through the use of open systems, based on shared
  industry standards. Central to UniForum's mission is the delivery of
  high quality educations programs, trade shows and conferences,
  publications, on-line services, and peer group interactions.  Call
  800/255-5620 for more UniForum information.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 22:45:25 GMT
From:      micky@bonjour.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   Current Status of CMP and TMux?

I've just retrieved the minutes for the last IETF BOF meeting on
tcp connection multiplexing and it is from last year (early 1993).
I am wondering if there was any further work done on either the
CMP (Connection Multiplexing Protocol) or on TMux.  Any pointers
would be greatly appreciated.

Micky Liu
micky@ejv.com


-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 94 23:02:11 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Helge Moulding (hsm@unislc.slc.unisys.com) sez:
> Routers shouldn't have to do a lot of
> fragmenting, for the same reason. This is done because fragmenting
> is quite expensive...

NFS does IP fragmentation because it's cheaper than sending out gobs
of individual small UDP packets (especially if you have to wait for a
response for each one).

This tends to be a win on LANs; across WANs it doesn't work so
well - fragments start getting dropped too frequently, probably
because of the increased number of potentially full queues that must
be crossed.  That drops entire packets, and your congestion control
scheme often ends up backing up so far you lose throughput relative to
the non-fragmented case.

karl@cavebear.com (Karl Auerbach)
> There is a strong argument to be made that when one does fragmentation, that 
> the first fragment which should be sent is the last fragment.
> 
> The reason for doing this is that the receiver has no idea how big the 
> reassembled packet will be until the last fragment is received.  If the 
> receiver is "lucky" enough to get the last fragment first, it has a chance to 
> allocate an appropriate size reassembly buffer.

There is an argument that allocating a reassembly buffer is a mistake.
That implies that you are doing extra copying at precisely the worst
moment - when somebody (likely NFS) is trying to get bulk data across
the wire.  Or are you talking about the reassembly queue data
structure?  With some work, you can use the headers for that.... 

Even if you hate traditionally complex network buffer descriptors like
mbufs more than the performance penalty from using a reassembly
buffer, there is an alternative algorithm: allocate a 9k ("likely
max") buffer (on many of the networks I've seen, max NFS requests are
responsible for most of the fragments).  You have to be prepared to be
wrong under your scheme anyway, so this boils down the the same thing
but less harsh on the numerous schemes that hope for FIFO order to get
good performance (or even, as you observed, to work at all, in some
unfortunate instances...). 

							Jon
-- 
--
WWW/Mosaic Home Page:  http://www-cse.ucsd.edu/users/jkay
Email:                 jkay@cs.ucsd.edu

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 23:25:53 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP timers modification ?

> On a SUN Sparc 10 Solaris 2.3 we are initiating
> an ftp-session. 
>
> If the remote host/network is not reachable the ftp
> application will time out only after 8 times trying
> to send an SYN-segment to connect to the other control-port.
> With the exponential backoff
> timers this takes about 4 minutes. For out operational
> system this is too long.
>
> 1. How does on change the number of retries, or the timer
> behaviour (preferable via the ndd utility in Solaris 2.3)

Check out Appendix E of my recent book "TCP/IP Illustrated"
(Addison-Wesley, 1994): all the Solaris 2.3 configurable
TCP/IP parameters are in there.  To change this one you need
to execute ndd and change the tcp_ip_abort_cinterval value
(which defaults to 240000 ms, or 4 minutes).

	Rich Stevens

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 23:28:27 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

> Got sent the full table of contents last year when I emailed the author
> an enquiry regarding one of his other books. I've limited this message
> to the main chapter headings; for those interested I can email the full
> TOC.

FYI, the entire TOC (ascii and PS), Preface, and complete sample chapter in
PS are available via anonymous ftp from aw.com in the aw.prof.comp.series
directory.

	Rich Stevens

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 12:31:55 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Keep Alives

In article <773409903snz@paxdata.demon.co.uk> Giles@paxdata.demon.co.uk writes:
>
>I am trying to work out how to handle TCP Keep Alives in my company's ISDN
>bridging products.  RFC1122 states that Keep Alives MUST be defaulted to
>off, be sent at configurable intervals and default to no less than every
>two hours.  This would suggest to me that no specific support for these 
>packets is required (i.e. allow them to bring up the ISDN link and be sent
>to the far end which will respond).

  You realize you are treading on religious issues. 

>
>Imagine my surprise when I found that NCSA Telnet's FTP client sends what
>appears to be a Keep Alive at three minute intervals!  Does this mean that
>I need to "spoof" the Keep Alive (just like an IPX/NCP Keep Alive) so as to
>keep ISDN bills manageable?
>

   You would likely want to make this configurable....allow the users
   to decide whether to have your black box spoof the keepalives or
   indeed pass them thru to the far end.

   Some folks tune the keepalive down to very short periods and use
   it to detect dead connections...this allows them to use telnet and
   other such protocols transparently to an application without
   having to put dead-session detection in that application.  

   Spoofing would pretty much eliminate the ability of those folks to
   do this...      

   Then there are some folks who put all dead session detection in the
   application and don't need keepalives at all, even though the
   systems administrator has configured keepalives at short
   intervals.  



-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 10:22:57 -0500
From:      gpalmer@blue.weeg.uiowa.edu (Gary Palmer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   [Q] Pricing for Trumpet winapps

Has anyone read or heard of what the shareware pricing scheme might be
for Peter Tattam's winapps applications?

TELW, FTPW, etc. are all part of a zip file that contain a couple of
simple documentation files--one doc file states that the software will
become shareware.  I also obtained a copy of TRMPTEL.EXE, which wasn't
packaged with anything else.  TRMPTEL is a much improved Telnet program
over TELW.  It seems to lack some things like the ability to remap
backsapce for delete without having to press Ctrl-backspace, but has much
better vt100 terminal emulation than TELW.

I am in a position where I need to make a decision on TCP/IP software
for Windows and would like to consider TRUMPET applications.  I know
the price of Trumpet Winsock, but have never seen what the price is
(or will be) for the suite of apps.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 03:24:40 GMT
From:      derekt@superior.carleton.ca (Derek Taylor)
To:        comp.protocols.tcp-ip
Subject:   Setting up Trumpet Winsock?


Bonehead, I know, but could someone tell me how to designate IP address,
Name server, Domain Server, Netmask, and Time server. Is there a way of
checking your own address and does it have to be entered numerically?
Thanks, Derek.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      05 Jul 1994 03:37:42 GMT
From:      wy1z@elvis.coe.neu.edu (Scott Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   HELP: How to transfer files via telnet?


Although this newsgroup doesn't have a .misc suffix, from the types of
messages posted, I think I'm safe asking this here:

A friend of mine told me he was able to transfer a binary file during
a telnet session (via an Amateur Radio TCP/IP connection to another
Ham TCP/IP station).

I've tried experimenting with this a bit on the Internet, but have not
been successful.  I tried to telnet from one of my accounts to another 
account, then transfer a binary file, but no luck.

If anyone has successfully done this or knows how, please e-mail me.

Thanks!



--
Scott Ehrlich, Amateur Radio Callsign: wy1z 
How to reach me: wy1z@neu.edu [Internet], wy1z@wa1phy.ma [Packet]
Boston ARC ftp archives: ftp oak.oakland.edu /pub/hamradio
Boston ARC Web page: http://www.acs.oakland.edu/barc.html

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 04:33:10 GMT
From:      bass@cais.cais.com (Tim Bass (Network Systems Engineer))
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

This review is too late.  Stevens book, _TCP/IP Illustrated_
is great book.  This books has been out as long as Philadephia 
(the movie) or longer.  We certainly don't need a review on
6 month old movies OR 6 month old books.

This goes to show everyone; The Internet is just like the
wild west - every gun trying to make a name for himself.
I guess cowboys with shiny guns always interest kids who
ride ponies.  

Danny (danny@cs.su.oz.au) wrote:
:      title: TCP/IP Illustrated, Volume 1
:           : The Protocols
:         by: W. Richard Stevens
:  publisher: Addison-Wesley 1994
:   subjects: computer science, networking
:      other: 576 pages, bibliography, index
 
: Stevens is well known for his books on Unix programming.  In the first
: volume of _TCP/IP Illustrated_ he deals with the specification and
: behaviour of the protocols that make up the TCP/IP suite.  He begins
: at the bottom of the network stack, with the link layer protocols,
: and works his way upwards, dealing with IP, ARP, ICMP, routing, UDP,
: IGMP, DNS, TFTP, BOOTP, TCP, SNMP, telnet, FTP, SMTP and NFS (among
: others).  Chapters on tools like ping and traceroute are included,
: and a tcpdump program is used throughout (on a real network) to
: allow us to actually watch the protocols in action on the wire;
: we are always kept in touch with what is happening at the link layer.
 
: The focus is very much on how the protocols work in practice rather
: than on the theory behind them.  So the discussion of RIP includes
: a detailed look at the protocol's behaviour on an example network,
: but only mentions the counting to infinity problem in passing,
: and ASN.1 is only given a brief description, since "the details of
: ASN.1 and BER are only important to implementors of SNMP".  If you
: are primarily interested in the theory behind the algorithms and
: protocols then this will be frustrating, but if you are interested
: in the protocols from an practical perspective then it will probably
: be a welcome simplification.
 
: _TCP/IP Illustrated_ is not an introductory book: the treatment is more
: systematic than pedagogic and a fair amount of knowledge is assumed.
: (So, for example, SLIP and PPP are discussed in chapter two along with
: the other link layer protocols; this would probably be confusing to
: someone without much networking background.)  This approach does make it
: easy to find things, however, and, together with a thorough index,
: enhances the volume's value as a reference.  There are useful exercises
: at the end of each chapter (with solutions at the back), which make it
: suitable as a textbook for those who already have some acquaintance with
: networking.
 
: For many years the recommended survey of TCP/IP protocols has
: been Comer's _Internetworking with TCP/IP_.  While I certainly
: wouldn't suggest that that book has been superseded, since it has
: a rather different approach, _TCP/IP Illustrated_ is definitely
: serious competition.  Particularly attractive features of Stevens'
: book are its coverage of different Unix versions (BSD4.3, Sun, SVR4,
: Solaris, BSD4.4 and others), its consideration of what the protocols
: actually mean in terms of "packets on the wire" and its concentration
: on issues of practical importance.  As mentioned, complete beginners
: and those interested in theoretical issues will probably prefer
: other books, but for many people I think _TCP/IP Illustrated_ would
: be the book of choice on TCP/IP.
 
: -
 
: %T 	TCP/IP Illustrated, Volume 1 - The Protocols
: %A 	W. Richard Stevens
: %I 	Addison-Wesley
: %C 	Reading, MA
: %D 	1994
: %O 	hardcover, bibliography, appendices, index
: %G 	ISBN 0-201-63346-9
: %P 	xix,576pp
: %K 	computer science, networking
 
: Danny Yee (danny@cs.su.oz.au)
: 30 June 1994
 
:  -----------------------------------------------------------------
:  All book reviews by Danny Yee are available via anonymous FTP to:
:  ftp.anatomy.su.oz.au in /danny/book-reviews (index INDEX) or with 
:  http://www.anatomy.su.oz.au/danny/book-reviews/index.html !Enjoy!
:  -----------------------------------------------------------------
:  Copyright (C) Danny Yee 1994 : Comments and criticism are welcome
:  -----------------------------------------------------------------


-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 12:40:04 -0400
From:      goutham@access3.digex.net (S.Goutham)
To:        comp.protocols.tcp-ip
Subject:   Info needed on auto. discovery of nodes in a net.


Can anyone out there please give me some suggestions on how to do
automatic discovery of all the nodes in a subnet and going beyond
the subnet? How is this generally done? I would greatly appreciate
any help on hints/pointers/books. Thanks...Goutham.


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 06:42:02 GMT
From:      barryf@iol.ie (Barry Flanagan)
To:        comp.protocols.tcp-ip
Subject:   Multiple hosts under 1 hostname - HOW?

Hi,

I need to have connections to a certain hostname work like a huntgroup - if
the first host doesn't respond then the next on the list is tried, until a
successful connection is made.

Can any kind soul tell me how to do this with (I guess) DNS records?

Thanks in advance.

-Barry

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

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 06:42:47 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <CsFC74.8GF@calcite.rhyolite.com> vjs@calcite.rhyolite.com
(Vernon Schryver) writes: 

    That is an overstatement based on the prejudices of the designers at a
    particular vendor.  It's circular reasoning.  Since fragmentation is
    considered unimportant, Cisco does not do it fast, which makes many of
    us have those familiar arguments with Cisco people about how hard
    fragmentation is and since it is slow, it must be unimportant.
    
As of 10.0, cisco routers with the silicon switch processor now fragment
extremely quickly.  I would post a number, but I haven't been able to get
enough test equipment together to find the top end.

    It is also just plain wrong.  For UDP/IP based applications such as NFS,
    it makes no sense for FDDI hosts to fragment to 1500 just so that
    FDDI-Ethernet routers and bridges won't be stressed.   The usual Cisco
    response to that point is to demand hosts implement MTU path discovery,
    which is a good thing for TCP, but unreasonable for UDP, what with the
    statelessness of NFS, subnetting, and the bad experiences Sun Microsystem's
    customers have had recently with bridges and routers that don't handle
    the DF bit right.

And just so no one gets confused, hosts should STILL do path MTU discovery.
There's a reason why "Fragmentation considered harmful" is a classic
article.  It still stresses the router, the receiving host, and, when
there's congestion, the network as a whole.

Tony

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue,  5 Jul 94 18:29:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP

SUBJECT:Re: Book Review - TCP/IP Illustrated, Volu                   

R > Any idea how much the book costs ? 

The price I paid was 47.50.

R >What do the followup volumes contain ?

The follow-up volume haven't been written yet, so they don't contain
anything. :-)

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Tue,  5 Jul 94 18:31:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   u

Yu>Message-ID: <CsH52z.L5r@epsilon.com>
Yu>Newsgroup: comp.protocols.tcp-ip
Yu>From: you@somehost.somedomain (Your Name Here)
Yu>Organization: Your Organization

Hmm... someone needs to do some work on their configuration! :-)
If you're listing, "Your Name Here", I'd check a few things before 
posting any more articles.

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 94 15:28:28 PDT
From:      tbleakney@hmcvax.ac.hmc.edu
To:        comp.protocols.tcp-ip
Subject:   IP dead on PPP link

	I have been trying to get MacPPP to work for weeks, and I am
stumped. I am posting to this group because I think I could have
a problem with the IP layer.
 
On the Mac I am using MacTCP 2.04 and system 7.1.  On the 
other end of the dial-up line is a Datability server on a campus 
LAN, with a Class B network with a subnet mask of 255.255.255.0.

	I have setup MacTCP with manual IP assignment.  When I dial in,
I give the server a command of:
	connect ppp 0.0.0.0
the server is supposed to pick an IP out of the IP pool.  There is only
1 such address, and it is the one I am using. It is on the same subnet
as the server.

MacPPP responds, saying the PPP link is established.  The stats
box shows that some packets were exhanged in setting up the link.
However, when I try a Ping to any IP address on the LAN (including
the server), NOTHING comes back.  The server has an ARP proxy for my
IP address, but this doesn't help.
	I am the first person to ever try PPP on this campus network, so
we don't know where to start.  If anyone has a clue to what I should
try next, I would greatly appreciate your help.
	Thanks.
--------
tbleakne@chs.cusd.claremont.edu


-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 08:42:06 GMT
From:      mw00378@lime.sbil.co.uk (Malcolm White)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Address

The address you are attempting to change to is a different Class C address and therefore the two devices will not communicate directly. The first three bytes must be the same for a Class C network so you'll have to stick with 192.0.0.x ( or change both! ).

Regards, Malcolm White
Salomon Brothers, London




-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 09:04:37 GMT
From:      rsgawera@wg.icl.co.uk (Raj Gawera)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volu

Hi,
	Any idea how much the book costs ? What do the followup volumes
contain ?
		cheers,
			Raj Gawera
rsgawera@wg.icl.co.uk

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 09:22:12 GMT
From:      bertg@fwi.uva.nl (Bert Gijsbers)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

bass@cais.cais.com (Tim Bass (Network Systems Engineer)) writes:

>This review is too late.  Stevens book, _TCP/IP Illustrated_
>is great book.  This books has been out as long as Philadephia 
>(the movie) or longer.  We certainly don't need a review on
>6 month old movies OR 6 month old books.

I cannot agree with this.  Books like these are well worth
reading years after publishing date.  The same holds for
good reviews on them.

>This goes to show everyone; The Internet is just like the
>wild west - every gun trying to make a name for himself.
>I guess cowboys with shiny guns always interest kids who
>ride ponies.  

Please take your childish flames to /dev/null.

Bert Gijsbers

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 14:54:02 EST
From:      MARCO PACE <MPACE@ESOC.BITNET>
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   TCP anomalous (?) behaviour in application

Hi,

can anybody provide some useful advice on the following problem?

I have two applications (running on a SUN workstation with Solaris 2.3)
communicating using TCP. One is a server, accepting connections; the
other is a client, connecting to the server. The client writes some
data to the server after connecting to it, the server reads the data
after accepting the connection.

The behaviour I can't explain is that, if the server dies (is killed)
after accepting the connection from the client, the client can still
perform successfully its write without realizing the death of the
server. In other words, the write primitive returns successfully.
A second write to the server, on the contrary, fails as expected.

Why this behaviour ? I think it might be related to the connection
status (to be checked with the UNIX utility 'netstat') which appears
to be still existing after the server's death.
How can I detect the server's death immediately ??

Any help will be appreciated.

Thanks,

Marco

-------------------------------------------------------------------------
Marco Pace, Software Engineer                   Tel   : +49 6151 903065
Vitrociset S.p.A.                               Fax   : +49 6151 904065
ESOC, Robert-Bosch-Strasse 5                    e-Mail: mpace@esoc.bitnet
D-64293 Darmstadt, Germany   x400: C=DE;A=DBP;P=ESA;O=ESOC;S=PACE;G=MARCO

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 10:09:58 GMT
From:      dmore@gisws3.rtpnc.epa.gov (Duane More)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   APIs for LWP/LWG

I am interested in finding out the development abstractions 
(RPC isn't really an API) available for LAN WorkPlace for DOS 
and LAN WorkGroup for DOS.

My understanding is that the WINSOCK interface is available 
for LW[PG] clients running under MS Windows. The quesiotns are then:
1) Is the ONC RPC (or some variant thereof) available for LW[PG] running 
   under windows. Preferably something provided by Novell because I know
   of DCE vendors whose stuff will run on WINSOCK.
2) What API is available for non-Windows devices. The current environment
   I am in has 8000-9000 286 devices which can be rather painful to run 
   Windows on.
3) Is the RPC abstraction available for the non-Windows devices 
   running LW[PG].

I am don't regularly read this group so I would appreciate mail responses 
if possible. I will post a summary if the response merits it. 


--
Duane N. More                       |  In Support of:                      
dmore@unixmail.rtpnc.epa.gov        |      US EPA 


-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 16:38:45
From:      padgett@141.240.2.145 (Padgett 0sirius)
To:        comp.protocols.tcp-ip
Subject:   Re: Info needed on auto. discovery of nodes in a net.

In article <2vc2d4$nka@access3.digex.net> goutham@access3.digex.net (S.Goutham) writes:
>Can anyone out there please give me some suggestions on how to do
>automatic discovery of all the nodes in a subnet and going beyond
>the subnet? How is this generally done? I would greatly appreciate
>any help on hints/pointers/books. Thanks...Goutham.

Well, I just ping all all of the addresses on the subnet and record those
that respond. "Active monitoring" is the polite term but it is really a "
daemon-pinger". Port connection attempts with record of those accepted
follow. I roll my own but understand that ATT has just released "PingWare"
to do the same thing is you have a spare four grand (six with consultation).

If you want a pointer to get started, try reading up on ARPs.

			A. Padgett Peterson, P.E.
                        Cybernetic Psychophysicist
			   We also walk dogs
	 	       PGP 2.4 Public Key Available

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 11:51:26 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Annex and general SLIP information needed (soon)

In article <1994Jul3.043914.29871@unlv.edu>, ftlofaro@unlv.edu (Frank Lofaro) writes:
|> 	An organization here is going to be soon providing SLIP
|> access.  However, they plan to use dynamic IP address assignment on a
|> per-port basis. In other words, connection on a given port gives you a
|> given IP address. They are using Xylogics Annex terminal servers (one
|> of them quite new, supposedly supports both SLIP/CSLIP and PPP). There
|> is going to be authentication of individual users.

We've supported both [C]SLIP and PPP since October 1992.

|> 	Unfortunately, dynamic IP address assignment would be a
|> headache for me and many other users. It would make it impossible to
|> run ftp/http and other servers, and would even make it very difficult
|> to find our own machine to telnet back into if we wanted to connect to
|> it through the Internet. It is especially hard for those that have
|> un*x based machines, (e.g. Linux)

Btw:  in our documentation, this is called "static IP addressing," since
the IP address is fixed per port.  "Dynamic IP addressing" is assigning
addresses by user name or any other metric.  (The default security
daemon is able to assign addresses by user name, but any other data may
be used.)

|> 	The justification given is that static IP addresses are harder
|> to set up and that they could run out.

Well, they do cause a *lot* of problems.  The first problem, of course,
is what to do if you have more users than you have addresses from the
NIC.  It's quite likely that the number of ports you have is much
smaller than the number of users, so assigning addresses by port will
conserve this resource better than by assigning by user.

The second problem is more serious.  There is a routing problem
associated with allowing users with unique IP addresses to "roam" among
a set of gateways.  If you use one large subnet (not an option for many
Internet providers who have boxes in several locations), then a user
hanging up and dialing in again on a different line will experience
trouble due to stale data in the host (or router) ARP cache.

If you break up the Annexes across subnets, then you need to use RIP to
reassign the routes, and everything gets even *more* complex, because
not everyone honors host routes.

In general, rapidly changing topologies are a "bad" thing when using
Internet protocols.

|> 	Anyone have any pointers to documents and information on
|> static versus dynamic IP address assignment, or on Annex terminal
|> server configuration? Especially information on the benefits of static
|> addressing and how to configure it on a Xylogics Annex. Any
|> information would be appreciated, as soon as possible (things are
|> moving very quickly).

By "static" I assume you mean per-user assignment.  You can set this up
quite easily by turning on the "port dialup_address" switch and entering
a user-name/IP-address pair in the acp_dialup file.

|> 	Does anyone know why stty fwdtimer x where x is less than 5
|> (the default) says I can't lower it? Also, if an Annex is in non-SLIP
|> mode, does it hold characters (e.g. use the Nagle algorithm)? Could
|> this be turned off on a port by a regular user for that session? This
|> information might be helpful for another project that I may have to
|> undertake soon.

The "fwdtimer" parameter has nothing to do with the Nagle algorithm.  It
controls the behavior of the serial port itself, not the network layers.

You can't set it below the value configured in "port forwarding_timer"
for security reasons.  Administrators don't like users taking more
bandwidth than allotted.

The Nagle algorithm is enabled on all Annex TCP connections.  There is
currently no way for the administrator to control this.

(Based on your questions, I should warn you that timing is in NO way
guaranteed by TCP.  If your "other project" requires that some special
relationship exists between the timing of characters and the delivery of
them to your application, you may need to rethink that project.)

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 18:38:13 -0400
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Round robin DNS?

In article <abobaCsAtC9.Hzr@netcom.com>,
Bernard Aboba <aboba@netcom.com> wrote:
>I am told that the latest version of BIND supports load balancing
>via "round robin" DNS. I am interested in how well this works,
>pointers to docs, etc.

It works as well as to be expected with a round-robin algorithm.
It doesn't take much thought to realize the limitations of round-robin.

A good source of docs would be the BIND docs itself.

However, I'm told ever since the root nameservers all switched to
using round-robin versions of BIND, mail load on big equal-preference-MX
sites like uunet.uu.net became much more uniform.

--Dave
-- 
"Opera is when a guy gets stabbed in the back and instead of bleeding
he sings." - Ed Gardner

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 12:05:03 +0000
From:      giles@paxdata.demon.co.uk (Giles Heron)
To:        comp.protocols.tcp-ip
Subject:   TCP Keep Alives

Hi

I am trying to work out how to handle TCP Keep Alives in my company's ISDN
bridging products.  RFC1122 states that Keep Alives MUST be defaulted to
off, be sent at configurable intervals and default to no less than every
two hours.  This would suggest to me that no specific support for these 
packets is required (i.e. allow them to bring up the ISDN link and be sent
to the far end which will respond).

Imagine my surprise when I found that NCSA Telnet's FTP client sends what
appears to be a Keep Alive at three minute intervals!  Does this mean that
I need to "spoof" the Keep Alive (just like an IPX/NCP Keep Alive) so as to
keep ISDN bills manageable?

Any help with this would be much appreciated...

-- 
| Giles Heron                        | Phone: +44 442 236336              |
| Paxdata Networks Limited           | Fax:   +44 442 236343              |
| Frogmore Road, Hemel Hempstead,    | Email: giles@paxdata.demon.co.uk   |
| HERTS HP3 9RW, United Kingdom.     | Opinions are of course my own...   |

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 12:50:59 GMT
From:      btl@hogpf.ho.att.com (-B.LING)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Help with PC-NFS - unable to register (PCNFSDPROG...)


folks,

i'm running a SUN 630 server which has pc-nfs running on it.
at least, it used to.  all of a sudden, for some unknown 
reason, when trying to run the rpc.pcnfsd daemon, i'm getting:

machname  pcnfsd[165]: unable to register (PCNFSDPROG, PCNFSDVERS, udp).

can anyone help me with this?  does PC-NFS has a license which
can expire?  any ideas would be greatly appreciated....

thanx in advance,

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%  The Linguistic Tongue, AT&T  %%  C Code.  C Code Run.  Run, Code, RUN! %%
%%       btl@hogpf.att.com       %%               PLEASE!!!!               %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 19:31:57 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.dcom.servers
Subject:   [draft TWO] comp.dcom.sys.cisco Frequently Asked Questions (FAQ)

Archive-name: cisco-faq
Last-modified: 5 July 1994
Version: Beta 0.2

This is the DRAFT frequently asked questions (FAQ) list
for comp.dcom.sys.cisco.

There should evntually be an html version of this FAQ available. Question should
also be numbered, and perhaps divided into subcategories for large
things (like ntp...)

Please contribute answers to the questions in the Todo section! If your
answer is somewhat complicated, posting would probably be best (to
comp.dcom.sys.cisco). Otherwise, e-mail it to cisco-faq@panix.com. I
meant to get some of these todos done, but I've just been too busy, so
I'm posting this as-is now.

This draft FAQ is in RFC1153 digest format, so you can follow each
question with your newsreader. I suppose that question-numbers should
be moved to the From: field. Note that Date: fields represent last-modification
times for the questions.

Table of Contents

1.	How can I contact cisco?
2.	What is this newsgroup?
3.	What's the first letter in ``cisco''?
4.	How do I save the configuration of a cisco?
5.	Where can I get ancillary software for my cisco?
6.	Is there a World-Wide-Web (www) information source?
7.	How can I get my cisco to talk to a third party router over 
8.	How can I get my cisco to talk to a 3rd-party router over Frame Relay?
9.	How can I use debugging?
10.	How can I use NTP (Network Time Protocol) with my cisco?
10a.    Sample NTP configurations
11.	Presence of cisco employees here
12.	How do I avoid the annoying DNS lookup if I have misspelled a command?
13.	Tracing bad routing information
14.	Acknowledgements.

todo:
----
* How to configure TACACS
* What is SNMP and how can I use it? What software is available and how do
I use Cisco enterprise MIBs?
* Pointers to other s/w that's particularly useful in this sort
of routing environment (like Charley Kline's VLSM program).
* Sample configurations of complicated things, like NTP. Also
routing protocols samples, but care should be taken not to just
duplicate the docs.
* Pointers to other net resources, like comp.protocols.tcp-ip, RFCs,
the firewalls mailing list, etc (bgpd?[or is it cidrd now? :-)]).
* Hints about confusing and not-well documented things like xtacacs...
* Comments on interoperability issues WRT other vendors.
* What's SMARTnet, why should I subscribe, how much does it cost,
and what do I get?
* What should I name my router, my interfaces, etc.?
* How should I restrict access to my router?
* What can I do about source routing?
* Where can I buy Cisco equipment.
	mail order
	used
	turnkey
		(much hand-holding/pre-setup)
	etc?
*  Should we adjust the buffer parameters on the routers?  What should be the 
   indicator before tunning the buffer parameters?  How should one fine tune the
   buffer parapeters?

*  discribtions of "show buffer" output, how should one read these output?
*  what routing protocol should I use?
*  what is the real purpose of the network subcommand of
   router commands?  When do I not want to include a network
   I know about?
*  What is a VLSM and why would I want one?  What supports
   them?
*  What are some methods for conserving IP addresses for
   serial lines?
*  Is there a block of private network numbers I can use
   within my organization only?  When should I use them?
   How do I access them from outside?
*  What do I do if I have to partition a network number?
*  Questions and answers about access lists


The Real Stuff:

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

From: cisco-faq
Date: 5 July 1994
Subject: How can I contact cisco?

The following phone numbers are available:

  Technical Assistance Center                           (800) 553-6387
                                                        (800) 553-2447
                                                             (553-24HR)
  Training Services                                     (415) 903-7290
  Protocol Interface (cisco Systems Training Partner)   (415) 491-8950
  Customer Service (Documentation, Warranty &           (800) 553-6387
      Contract Services, Order Status
  Order Processing                                      (415) 903-7231
  Engineering                                           (800) 553-2447
                                                             (553-NETS)
  On-site Services, Time & Materials Service            (800) 829-2447
                                                             (829-NETS)

cisco can also be contacted via e-mail to tac@cisco.com -- please
follow the directions available on CIO before doing this.  cisco
provides an on-line service for information about their routers and
other products, called CIO (cisco Information Online?).  telnet to
cio.cisco.com for more details.

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

From: cisco-faq
Date: 5 July 1994
Subject: What is this newsgroup?

[anyone have a copy of the charter?]

comp.dcom.sys.cisco, which is gatewayed to the mailing list
cisco@spot.colorado.edu, is a newsgroup for discussion of cisco
hardware and related issues. Remember that you can also consult with
cisco technical support.

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

From: cisco-faq
Date: 5 July 1994
Subject: What's the first letter in ``cisco''?


Apparently it used to be a lowercase c (cisco Systems), but rumor has
it that it has now becmome a more convetional and less-pleasing
uppercase C.


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

From: cisco-faq
Date: 5 July 1994
Subject: How do I save the configuration of a cisco?

If you have a tftp server available, you can create a file on the
server for your router to write to, and then use the write network
command:

	mytftpserver$ touch /var/spool/tftpboot/myconfig
	mytftpserver$ chmod a+w /var/spool/tftpboot/myconfig

	myrouter#write net
	Remote host [10.7.0.63]? 10.7.0.2
	Name of configuration file to write [myrouter-confg]? foobar
	Write file foobar on host 10.7.0.2? [confirm] y

Additionally, you can also use an expect, available from:

	ftp://ftp.uu.net/languages/tcl/expect/expect.tar.gz
	ftp://ftp.cme.nist.gov/expect/expect.tar.gz

script to telnet to the router and do a ``write terminal''.

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

From: cisco-faq
Date: 5 July 1994
Subject: Where can I get ancillary software for my cisco?

Try ftping to

	ftp://ftp.cisco.com/pub

It's a hodgepodge collection of useful stuff, some maintained and some
not.

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

From: cisco-faq
Date: 5 July 1994
Subject: Is there a World-Wide-Web (www) information source?

You can try the www homepage of this FAQ

	http://www.panix.com/cisco-faq [no, it's not there yet]

or the cisco Systems homepage

	http://sunsite.unc.edu/cisco/cisco-home.html

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

From: cisco-faq
Date: 5 July 1994
Subject: How can I get my cisco to talk to a third party router over 
a serial link?

You need to tell your cisco to use the same link-level protocol as the
other router; by default, ciscos use a rather bare variant of HDLC
(High-level Data Link Control) all link-level protocols use at some
level/layer or another. To make your cisco operate with most other
routers, you need to change the encapsulation from HDLC to PPP on the
relevant interfaces. For instance:

	sewer-cgs#conf t
	
	Enter configuration commands, one per line.
	Edit with DELETE, CTRL/W, and CTRL/U; end with CTRL/Z
	interface serial 1
	encapsulation ppp
	^Z

	sewer-cgs#sh int s 1
	
	Serial 1 is administratively down, line protocol is down 
	  Hardware is MCI Serial
	  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
	  Encapsulation PPP, loopback not set, keepalive set (10 sec)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]

If you're still having trouble, you might wish to turn on serial interface
debugging:

	sewer-cgs#ter mon
	sewer-cgs#debug serial-interface

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

From: cisco-faq
Date: 5 July 1994
Subject: How can I get my cisco to talk to a 3rd-party router over Frame Relay?

You should tell your cisco to use ``encapsulation frame-relay ietf''
(instead of ``encapsulation frame-relay'') on your serial interface
that's running frame relay if your frame relay network contains a
diverse set of manufacturers' routers. The keyword ``ietf'' specifies
that your cisco will use RFC1294-compliant encapsulation, rather than
cisco's optimized version (which only talks to other ciscos).  If only
a few routers in your frame relay cloud are other brands, then you can
use optimized cisco encapulsation on everything and specify the
exceptions with the frame-relay map command:

	frame-relay map ip 10.1.2.3 56 broadcast ietf
                                                 ^^^^

(ietf stands for Internet Engineering Task Force, the body which
evaluates Standards-track RFCs).

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

From: cisco-faq
Date: 5 July 1994
Subject: How can I use debugging?


[Could someone please comment on what an appropriate scheduler-interval is?]

The ``terminal monitor'' command directs your cisco to send debugging
output to the current session. It's necessary to turn this on each time
you telnet to your router to view debugging information. After that,
you must specify the specific types of debugging you wish to turn on;
please note that these stay on or off until changed, or until the
router reboots, so remember to turn them off when you're done.

Debugging messages are also logged to a host if you have trap logging
enabled on your cisco. You can check this like so:


	sl-panix-1>sh logging
	Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
	    Console logging: level debugging, 66 messages logged
	    Monitor logging: level debugging, 0 messages logged
	    Trap logging: level debugging, 69 message lines logged
	        Logging to 198.7.0.2, 69 message lines logged
	sl-panix-1>

If you have syslog going to a host somewhere and you then set about a
nice long debug session from a term your box is doing double work and
sending every debug message to your syslog server. Additionally, if you
turn on something that provides copious debugging output, be careful
that you don't overflow your disk (``debug ip-rip'' is notorious for
this).

One solution to this is to only log severity ``info'' and higher:

	sl-panix-1#conf t
	Enter configuration commands, one per line.  End with CNTL/Z.
	logging trap info

The other solution is to just be careful and remember to turn off
debugging. This is easy enough with:

	sl-panix-1#undebug all

If you have a heavily loaded box, you should be aware that debugging
can load your router.  The console has a higher priority than a vty so
don't debug from the console; instead, set a scheduler interval in the box,
to allows the processor to check other processes periodically:

	cix-west.cix.net#conf t
	Enter configuration commands, one per line.  End with CNTL/Z.
	scheduler-interval 750

Then always debug from a vty.  If the box is busy and you are a little
too vigorous with debugging and the box is starting to sink, quickly
run, don't walk to your console and kill the session on the vty.  If
you are on the console your debugging has top prioority and then the
only way out is the power switch.  This of course makes remote
debugging a real sweaty palms adventure especially on a crowded box.
Caveat debugger!

Also, if you for some reason forget what the available debug commands are
and don't have a manual handy, remember that's what on-line help
is for. Under pre 9.21 versions, ``debug ?'' lists all commands. Under
9.21 and above, that gives you general categories, and you can check
for more specific options by specifying the category: ``debug ip ?''.

Lastly, if you're not sure what debugging criteria you need, you can
try ``debug all''. BE CAREFUL!  It is way useful, but only in a very
controlled environment, where you can turn off absolutely everything
you're not interested in.  Saves a lot of thinking.  Turning it on on a
busy box can quickly cause meltdown.


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

From: cisco-faq
Date: 5 July 1994
Subject: How can I use NTP (Network Time Protocol) with my cisco?

>What level of software is required for NTP support in
>a Cisco router?

9.21 or above.

>Which Cisco routers support NTP?

It is a software feature exclusively. Anything that supports
9.21 or 10 will run NTP (when running that s/w).

>How do I set it up?

The basic hook is:
	ntp server <host> [version n]
or
	ntp peer <host> [version n]

depending on whether you want a client/server or peer relationship.
There's a bunch of other stuff available for MD5 authentication,
broadcast, access control, etc.  You can also use the
context-sensitive help feature to puzzle it out; try "ntp ?" in config
mode.

You'll also want to play with the SHOW NTP * router commands.  Here
are two examples.

EXAMPLE 1:

router# show ntp assoc

      address         ref clock     st  when  poll reach  delay  offset    disp
+~128.9.2.129      .WWVB.            1   109   512  377    97.8   -2.69    26.7
*~132.249.16.1     .GOES.            1   309   512  357    55.4   -1.34    27.5
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

EXAMPLE 2:

router#show ntp stat
Clock is synchronized, stratum 2, reference is 132.249.16.1
nominal freq is 250.0000 Hz, actual freq is 249.9981 Hz, precision is 2**19
reference time is B1A8852D.B69201EE (12:36:13.713 PDT Tue Jun 14 1994)
clock offset is -1.34 msec, root delay is 55.40 msec
root dispersion is 41.29 msec, peer dispersion is 28.96 msec

For particular cisco NTP questions, feel free to ask in comp.dcom.sys.cisco.

For broader NTP info, see ftp://louie.udel.edu:pub/ntp/doc.  The file
clock.txt in that directory has info about various public NTP servers.
There is also information on radio time receivers that can be
connected to an NTP server (this is handy on private networks, if you
have an entire campus to get chiming, or if you become a hard core
chimer).

The "ntp clock-period" command is added automagically to jump-start
the NTP frequency compensation when the box is rebooted.  This is
essentially a representation of the frequency of the crystal used as
the local timebase, and may take several days to calculate otherwise.
(Do a "write mem" after a week or so to save a good value.)

Caveat: Note that the CS-500 will not be able to achieve quite the same
level of accuracy as other platforms, since its hardware clock
resolution is roughly 242Hz instead of the 1MHz available on other
platforms.  In practice this shouldn't matter for anyone other than
true time geeks.

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

From: cisco-faq
Date: 5 July 1994
Subject: Sample Cisco NTP Configurations

You will need to substitute your own NTP peers, timezones, and GMT
offsets into the examples below, of course.  Example 1 is in US Central
Time Zone, while example 3 is in US Pacific Time Zone.  Both account
for normal US Daylight Savings Time practices.

EXAMPLE 1 (Charley Kline):
...
clock timezone CST -6
clock summer-time CDT recurring
ntp source eth 0
ntp peer <host1>
ntp peer <host2>
ntp peer <host3>
...


EXAMPLE 2 (Tony Li):
...
ntp source Ethernet0/0
ntp update-calendar
ntp peer <host1> 
ntp peer <host2> prefer
...


EXAMPLE 3 (Dave Katz):
...
service timestamps debug datetime localtime
service timestamps log datetime localtime
clock timezone PST -8
clock summer-time PDT recurring
interface Ethernet0
ip address <mumble>
ntp broadcast
ntp clock-period 17180319
ntp source Ethernet0
ntp server <host1>
ntp server <host2>
ntp server <host3>

COMMENTS ON EXAMPLE 3: 
	The config file is commented with date and time (and user id,
if TACACS is enabled) when the system thinks the clock is accurate.
I've enabled timestamping of debug and syslog messages.  I send NTP
broadcast packets out onto the local ethernet.  I'm in Pacific
Standard Time, with U.S. standard daylight saving time rules.  I use
the IP address of the ethernet as the source for all NTP packets.


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

From: cisco-faq
Date: 5 July 1994
Subject: Presence of cisco employees here

or: Why are there so many obnoxious Cisco people flaming on this
newsgroup when someone discusses a competitor?

Cisco does not own this newsgroup or mailing list.  They have no
control (and no right to control) the content here.  Most of the people
there know this.  Periodically new people are hired who think that it
is a service provided by Cisco and send inappropriate mail.  They are
soon educated.

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

From: cisco-faq
Date: 5 July 1994
Subject: How do I avoid the annoying DNS lookup if I have misspelled a command?
 
By default, all lines are configured to automatically try a telnet
connection if the first word in a input line is not recognized as a
valid command.  You can disable this by setting "transport preferred
none" on every line (con, aux and vty). For instance:


	sl-panix-1#conf t
	Enter configuration commands, one per line.  End with CNTL/Z.
	line vty 0 10
	transport preferred none


You can see the number of vty's currently configuered with ``show lines''
 
------------------------------

From: cisco-faq
Date: 5 July 1994S
Subject: Tracing bad routing information

or: How do I find out which non-Cisco systems on my networks generate IP-RIP
   information without letting them mess up my routing tables.
 
Here you could work with a default administrative distance. Administrative distance is the
basis upon which the cisco prefers routing information of one protocol over another. In
this example:

	router rip
	network 192.125.254.0
	distance 255
	distance 80 192.125.254.17     ! list all valid RIP suppliers
	[...]

the value 255 has the implicit meaning of not putting this information
into the routing table. Therefore, setting an administrative distance
of 255 means that all RIP suppliers are by default accepted but their
information is not put into the routing table. The administrative
distance for the router 192.125.244.17 has been reset to the default
(for RIP) of 80, causing its routes to be accepted into the routing table.

Then you can look them up with ``show ip protocols'' and restore the
original administrative distance for the ones you want to fill in the
routing table.

The same results can be acheived with an ip access-list, but with that,
"show ip protocols" will only show the valid ones. But often it is more
useful to see which systems were generating routing information at all.

This trick works for other routing protocols as well, but please select
the proper adminstrative distance (rather than 80) for the protocol
you're using.

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

From: cisco-faq
Date: 5 July 1994
Subject: How to use access lists

                    Frequently Asked Questions
                    contributed by Howard C. Berkowitz
                    PSC International
                    hcb@world.std.com
                       @clark.net   [probably will be my permanent 
                                     personal account]
                    PSC's domain is in mid-setup

Where in the router are access lists applied?

    
    In general, Basic access lists are executed as filters on
outgoing interfaces.  Newer releases of the Cisco code, such as
9.2 and 10, do have increased ability to filter on incoming ports.
Certain special cases, such as broadcasts and bridged traffic,
can be filtered on incoming interfaces in earlier releases.
There are also special cases involving console access.

Rules, written as ACCESS-LIST statements, are global for the entire
Cisco box; they are activated on individual outgoing interfaces by
ACCESS-GROUP subcommands of the INTERFACE major command.
    Filters are applied after traffic has entered on an incoming
interface and gone through a routing process; traffic that originates in
a router (e.g., telnets from the console port) is not subject to
filtering.

             +-------------------+
             |     GLOBAL        |
             |                   |
             | Routing           |
             | ^  v       Access |
             | ^  v       Lists  |
             +-^--v--------^---v-+
             | ^  v        ^   v |
             | ^  v        ^   v |
A----------->|-|  |>>>>Access  >>----------->B
             |1        Group   2 |
<------------|                   |<-----------
             |                   |
             |                   |
             +-------------------+

    Some types of "filter," using "filter" as a broader class than
ACCESS-LIST, can operate on incoming traffic.  For example, the INPUT-
SAP-FILTER used for Novell networks is applied to Service Advertisement
Packets (SAP) seen at incoming interfaces.  In general, incoming
filtering can only be done for "system" rather than user traffic.

Rules of thumb in defining access lists.

    First, define what you want to do and in which directions.  An
informal drawing is a good first step.  As opposed to the usual
connectivity drawings among routers, it's often convenient to draw
unidirectional links between routers.
    Second, informally write out your filtering rules.  In general, it
is best to go from most specific to least specific. Modify the order of
writing things to minimize the number of rules needed.
    Third, determine which rules need to be on which routers.
Explicitly consider the direction of flow, and the possible existence of
additional paths that could inadvertently bypass a filter.

Can a Cisco router be a "true" firewall?

    This depends on the definition of firewall.  Some writers (e.g.,
Gene Spafford in _Practical UNIX Security_) define a firewall as a host
on which an "inside" and/or an "outside" application process run, with
application-level code linking the two.  For example, a firewall might
provide FTP access to the outside world, but it would not also provide
direct FTP service to the inside world.  To place a file on the FTP
external server, a designated user would explicitly log onto the FTP
server, transfer a file to the server, and log off.  The firewall
prevents direct FTP connectivity between the inside and outside
networks; only indirect, application-level connectivity is allowed.
   Firewalls of this sort are complemented by chokes, which filter on
network addresses and/or port numbers.  Cisco routers cannot do
application-level control with access control lists.
   Other authors do not distinguish between chokes and filters.  Using
the loose definition that a firewall is anything that selectively blocks
access from the inside to the outside, routers can be firewalls.


IP Specific
-----------

Can the "operand" field be used with a protocol keyword of IP to filter
on protocol ID?

    No.  Operand filtering only works for TCP and UDP port numbers.

How can I prevent traffic for a certain Internet application to flow in
one direction but not the other?

    Remember that Internet applications flow from client port to server
port.  Denying traffic from port 23, for example, blocks flow from the
client to the server.

             +-------------------+
             |                   |
A----------->|                   |----------->B
             |1                 2|
<------------|                   |<-----------
             |                   |
             +-------------------+

    If we deny traffic to Port 23 of address B by placing a filter at
interface 2, we have blocked A's ability to telnet to B, but not B's
ability to telnet to A.  A second filter at interface A would be needed
to block telnet in both directions.
    Assume that we only have the filter at interface 2.  Telnets to A
from B will not be affected because the filter at 2 does not check
incoming traffic.
-------
What really happens when a Cisco router boots, from boot start to live
interfaces?

 
           powercycle
 
Does some delay stuff to let the power settle.  Goto I.
 
           reload (from the EXEC)
Goto I.

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

From: cisco-faq
Date: 5 July 1994
Subject: Acknowledgements.

The following people contributed to this FAQ, and their contributions
are greatly appreciated, both questions and answers

	"Ronnie B. Kon" <ronnie@cisco.com>
	Charley Kline <cvk@uiuc.edu>
	Dave Katz <dkatz@cisco.com>
	John Wright
	Pete Siemsen <siemsen@skat.usc.edu>
	Sanjay Rungta~ <srungta@sedona.intel.com>
	Steve Cunningham <steve@vf.ge.com>
	atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
	jerry@ksu.ksu.edu (Jerry Anderson)
	jhawk@panix.com (John Hawkinson)
	john@gulfa.ods.gulfnet.kw (John Temples)
	peter@ulisse.rhein-main.de (Peter Radig)
	tli@cisco.com (Tony Li)
	tom@park.uvsc.edu (Thomas R. Kimpton)
        Howard C. Berkowitz, PSC International, <hcb@world.std.com>

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 21:38:23 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Packet Drivers II

I am interested in learning about packet drivers and how they work.

From the little I was able to find out, it seems as if they have a
standard interface for dealing with applications.  Who defined this
interface?
Is there a standard document which is available?

Where can I learn more about what they work, how they do?

I would also warmly welcome any insight that you might have on the
topic.

Thanks,

--Mike

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 15:02:38 GMT
From:      s2929773@techst02.technion.ac.il (Yosefi Ori )
To:        comp.protocols.tcp-ip
Subject:   Connecting Appletalk+ethernet+SLIP internet

Hi,

I wanted to know if there is any way I can connect an existing
Appletalk network (consisting of an EtherTalk Zone and A localtalk zone)
to the Internet Over a SLIP connection (Dial Up).


I installed MacTCP on the computer with the modem and I can use the internet
OK, but I can't manage to use the internet from another Mac (Not having a modem)

Is there any way to cause Macs to sends their Packets throuhgh another one?

Thank a lot for any help,

Ori Yosefi.

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 00:06:26 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Coding Conventions

Is there any widespread standard for coding conventions, such as nameing
functions, variables, uppercase, lowercase, etc., or is this too
personal and non-urgent a matter for such a standard to be accepted?

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 12:56:47 +0200
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you get TCP/IP address by program ?

zi@cli51jo.der.edf.fr (Zixiong Wang) writes:

>	I must get my local host's address by program, I can 
>of cause read in /etc/hosts, but I don't think it is the best 
>way to do that.
>	I'v tried gethostbyname(), which returns a hostname
>and a pointer to an address, the hostname is always the same
>than the one that I'v passed to the function, so not at all
>informative. The Sun Solaris manual says that the address is
>of form of in_addr, which can be manipulated by inet...
>system calls, so I call inet_ntoa(), but what I get is
>not my address:

There's a bug in Solaris 2.x which causes the argument to
gethostbyname to be returned as the h_name field.

>struct hostent *ent = gethostbyname("cli51jo");
>struct in_addr in;
>memcpy(&in, ent->h_addr_list, sizeof(struct in_addr));
>cout << inet_ntoa(in) << endl;
 
>this code gives me:
>0.3.104.252

The h_addr_list is an array of pointers to addresses.

(The Solaris manual misses a crucial '*' in the h_addr_list type)

The address you want is ent->h_addr_list[0].

Casper

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 00:47:09 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Packet Drivers, Wattcp, Mobile Computing

Maybe you have seen my previous posts on the TCP/IP groups about how I
am trying to implement a TCP/IP variant scheme designed to cater to the
needs of mobile computing.  My original plan was to add code to WATTCP,
probably at the point just before it calls the packet driver.

What do you think of this other approach?

Leave WATTCP intact and the packet driver intact.
Write a software layer in between to do the following:

It would act like the packet driver on one end, so that WATTCP will call
it instead of the real packet driver.

It will take outgoing packets from WATTCP and modify them to conform
with our mobile computing IP scheme, then send them to the packet driver
as if they came from WATTCP.

It will take packets from the packet driver and change them back to
regular TCP/IP, and hand them to WATTCP as the packet driver would in a
conventional case.

I think this idea may work.  I think the packet driver stuff is
exciting, so if it sounds like a decent idea from a feasibility  point
of view, it seems like a good way to go about things, since it can be
used with standard TCP/IP and a standard packet driver.

What is your evaluation of this idea?
Does it seem feasible?

Please let me know what you think.

--Mike

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 00:57:19 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Unbalanced routing -- How to detect?

In <1994Jul5.211423.22685@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:

>> I would like a tool which showed me the full round trip routing for IP
>> packets, so I could detect if there are unbalanced routes. I can use
>> traceroute in one direction, but then again, I don't see which route
>> the reply packets take.
>> Any hints on how to detect unbalanced routing? Thanks,
 
>Yes, put in the loose source routing option and then you can see the
>round trips (assuming enough routers in the path support the LSRR
>option).  Check out Section 8.5 of my recent book "TCP/IP Illustrated"
>(Addison-Wesley, 1994) for some examples.  The source code for a version
>of traceroute that supports the LSRR option is available in the tar file
>for this book (ftp.uu.net:/published/books/stevens.tcpipiv1.tar.Z).

This is the -g option, BTW, and it only works if all the routers in
your path do not have source-routing disabled (not always a safe bet
in our firewalled world). You can also get such atraceroute w/o
associated Stevens' stuff from ftp.uu.net:/networking/ip/trace/ -
traceroute_pkg.tar.Z.

Here's an example; if my regular path to swidir.switch.ch is:

[panix!jhawk] /tmp% traceroute swidir.switch.ch
traceroute to swidir.switch.ch (130.59.72.10), 30 hops max, 40 byte packets
 1  transit.nyc.access.net (198.7.0.126)  9 ms  3 ms  3 ms
 2  sl-dc-1-S12-T1.sprintlink.net (144.228.2.193)  19 ms  11 ms  15 ms
 3  icm-dc-1-F0/0.icp.net (144.228.20.101)  36 ms  23 ms  18 ms
 4  washington2.dante.net (192.41.177.220)  30 ms  15 ms  24 ms
 5  Geneva3.Dante.net (192.77.157.2)  103 ms  106 ms  108 ms
 6  swice1.switch.ch (192.65.185.130)  106 ms  104 ms  111 ms
 7  swiEL2.switch.ch (130.59.92.1)  147 ms  112 ms  109 ms
 8  swidir.switch.ch (130.59.72.10)  108 ms  122 ms  111 ms

And the roundtrip looks like this:

[panix!jhawk] /tmp% traceroute -g swidir.switch.ch panix.com
traceroute to panix.com (198.7.0.2), 30 hops max, 40 byte packets
 1  transit.nyc.access.net (198.7.0.126)  4 ms  3 ms  4 ms
 2  sl-dc-1-S12-T1.sprintlink.net (144.228.2.193)  75 ms  109 ms  116 ms
 3  icm-dc-1-F0/0.icp.net (144.228.20.101)  17 ms  105 ms  115 ms
 4  washington2.dante.net (192.41.177.220)  119 ms  100 ms  21 ms
 5  Geneva3.Dante.net (192.77.157.2)  111 ms  107 ms  114 ms
 6  swice1.switch.ch (192.65.185.130)  110 ms  115 ms  109 ms
 7  swiEL2.switch.ch (130.59.92.1)  117 ms  110 ms  117 ms
 8  swidir.switch.ch (130.59.72.10)  112 ms  115 ms  130 ms
 9  swiEL2.switch.ch (130.59.72.2)  158 ms  123 ms  118 ms
10  swiCE1.switch.ch (130.59.92.2)  134 ms  112 ms  111 ms
11  geneva3.Dante.net (192.65.185.204)  116 ms  143 ms  119 ms
12  Washington2.Dante.net (192.77.157.1)  143 ms  116 ms  123 ms
13  sl-dc-2-E1.sprintlink.net (192.41.177.239)  116 ms  112 ms  112 ms
14  sl-dc-1-F0.sprintlink.net (144.228.20.1)  117 ms  220 ms  354 ms
15  sl-panix-1-S0-T1.sprintlink.net (144.228.2.194)  167 ms  133 ms  127 ms
16  panix (198.7.0.2)  143 ms  116 ms  114 ms
[panix!jhawk] /tmp% 

Just remember that not all interfaces on a router have the same
naming, so don't be mislead. For instance, hops 15 and 1 in the above
traceroute are the same router.

In the case of people who have source-routing turned off, you can
often used the next-hop back. For instance:

traceroute to panix.com (198.7.0.2), 30 hops max, 40 byte packets
 1  transit.nyc.access.net (198.7.0.126)  4 ms  3 ms  3 ms
 2  sl-dc-1-S12-T1.sprintlink.net (144.228.2.193)  12 ms  11 ms  12 ms
 3  sl-dc-6-F0/0.sprintlink.net (144.228.20.6)  13 ms  160 ms  18 ms
 4  Boone1.VA.ALTER.NET (192.157.65.227)  21 ms  20 ms  21 ms
 5  Falls-Church4.VA.ALTER.NET (137.39.43.97)  21 ms  159 ms  34 ms
 6  IBMpc01.UU.NET (137.39.8.20)  28 ms !S

That fails at one of uunet's internal routers. So if we take the
backwards path from just before it:

[panix!jhawk] /tmp% traceroute -g 137.39.43.97 panix.com
traceroute to panix.com (198.7.0.2), 30 hops max, 40 byte packets
 1  transit.nyc.access.net (198.7.0.126)  4 ms  5 ms  5 ms
 2  sl-dc-1-S12-T1.sprintlink.net (144.228.2.193)  16 ms  22 ms  29 ms
 3  sl-dc-6-F0/0.sprintlink.net (144.228.20.6)  18 ms  14 ms  14 ms
 4  Boone1.VA.ALTER.NET (192.157.65.227)  48 ms  29 ms  16 ms
 5  Falls-Church4.VA.ALTER.NET (137.39.43.97)  25 ms  18 ms  28 ms
 6  Boone1.VA.ALTER.NET (137.39.43.66)  25 ms  26 ms  23 ms
 7  sl-dc-6-E3/5.sprintlink.net (192.157.65.228)  42 ms  25 ms  25 ms
 8  sl-dc-1-F0.sprintlink.net (144.228.20.1)  31 ms  35 ms  30 ms
 9  sl-panix-1-S0-T1.sprintlink.net (144.228.2.194)  26 ms  29 ms  27 ms
10  panix (198.7.0.2)  34 ms  24 ms  27 ms
[panix!jhawk] /tmp% 

You can get a fairly good idea of what the path is, but you
should remember this is just a guess.

Additionally, don't forget that these paths change all the time
as route info changes, so today's path may not be tomorrow's.

--
John Hawkinson
jhawk@panix.com

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 01:00:52 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Round robin DNS?

In <2vcncl$pe6@bosnia.pop.psu.edu> barr@pop.psu.edu (David Barr) writes:

>However, I'm told ever since the root nameservers all switched to
>using round-robin versions of BIND, mail load on big equal-preference-MX
>sites like uunet.uu.net became much more uniform.

How could this be? The root nameservers don't return RRs for such
domain names, unless they cache them, which seems unlikely. It's
merely a question of when the servers for the zone that uunet.uu.net
is in started running round robin.

--
John Hawkinson
jhawk@panix.com

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 19:15:05 GMT
From:      skov@ilx.com (John Skovron)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for dynamic-assignment BOOTP

In article <2v1dfj$s4p@vkhdib01.hda.hydro.com>,
Per Weisteen <Per.Weisteen@hda.hydro.com> wrote:
>In article <1994Jun30.160105.6475@ivax>, imhw400@indyvax.iupui.edu (Mark H. Wood) says:
>>
>>I'm looking for *any* implementation of BOOTP that can dish out cynamically-
>>assigned addresses to hosts on subnets other than its own.  I would have
>>  ...
>
>DHCP protocol (RFC 1541  ++) is a new protocol which does exactly
>what you want. I know Microsoft has implemented this for NT and I think
>SUN has a version out "real soon now" , and yes Novell is also supposed
>to have one implemented as a NLM for their 4.x Netware.
>
>I'm desperately looking for a UNIX source. I'd hate to be in the hands of those
>PC-guys talking IP.... ;-)
> 

On this note, is _anybody_ actually shipping a DHCP server yet?  Microsoft
NTAS (that's the Windows NT Application Server, in case you haven't learned
their corpo-babble yet) v3.5 still seems to be stuck in a tightly controlled
beta, and the other commercial implementations seem to be in the same
place at best.  Microsoft was kind enough to include a DHCP client with
their latest TCPIP protocol stack, but there's no server to test it against.
Is there anything - whether Unix or not - that I could actually put my
hands on today?




-- 
-----------------------------------------------------------------------------
John Skovron
ILX Systems Inc.
skov@ilx.com

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 19:27:53 GMT
From:      rao@acsc.com (Rao Srinivasa)
To:        comp.protocols.tcp-ip
Subject:   Re: Installing SLIP

In article <1994Jul1.205328.13600@wisipc.weizmann.ac.il>, yuvalt@silver.weizmann.ac.il (Tal Yuval) writes:
|> Hi,
|> 
|> I am trying to make SLIP work in my site and I have a question: Our
|> network is class C (ie the subnetmask is 255.255.255.0), our computers are
|> on network 132.76.80 (wisdom.weizmann.ac.il).
|>

 According to the IP address you have class B IP address. ( 128 to 191 of first byte. )
  Your subnetmask shows that the  last 16 bits that are allocated for you by the
   class B address are divided in to 8bits for subnets and remaining 8bits for
    hosts within the subnets.
	

|> My question is: If I want to connect a SLIP machine to the network
|> (lets say that the host is 132.76.80.121), do I have to create a new
|> network (i.e. 132.76.81) and make 132.76.80.121 its gateway or can I
|> put my SLIP machine on the same IP network?
|>

 You can connect a host by SLIP without wasting a subnet number for it ... 
 

   



				130.76.79 
		   	-------------------------------------
						    |
						    |
	          130.76.80.126			    | 130.76.79.100
---------		----------		---------
Host	| SLIP  	| 	  |		|	|
to 	|---------------|   M1    |		|  M2   |
connect	|             	|	  |		|	|
--------		---------		---------
 130.76.80.125		    |130.76.80.66	     | 130.76.80.65
		   	-------------------------------------



Here we are using variable length subnet mask.

8 bits for subnet mask. 
8bits that are remaining for hosts are divided in to 
2 bits for subnets within the subnet and 6 bits for hosts.

So in this topolozy you are sacrificing the number of hosts that you 
can connect to 64  just to avoid the usage of one more subnet.


<-------16bits----------><---8bits------><2 bits><6bits for hosts>
----------------------------------------------------------
 130.76			| (79 and 80 in |
			|   this field) |
----------------------------------------------------------

SubnetMask:
<----all 1s-------------------------------------><- Last 6bits 0s -->
=  0xffffffc0 = 255.255.255.192



 |> I succeeded in creating a new subnet but I was wondering if the other
|> method also works. If it does, what is the configuration of the SLIP
|> host and the SLIP machine.
|> 


	IP address		 SubnetMask		SubnetID	HOST

M2:	130.76.79.100		255.255.255.0		130.76.79	100
	130.76.80.65		255.255.255.192		130.76.80.64	1

M1:	130.76.80.66		255.255.255.192		130.76.80.64	2
	130.76.80.126		255.255.255.192		130.76.80.124	2

SLIP:	130.76.80.125		255.255.255.192		130.76.80.124	1



Good luck ...


Rao.

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 19:53:58 GMT
From:      adiwan@siacbbn.com (Arif Diwan (BBN))
To:        comp.protocols.tcp-ip
Subject:   Re: Best way to change IP addresses for a group of systems

In article <2v1902$8km@ccnet.ccnet.com>,
	jantypas@ccnet.com (John Antypas) writes:
...
  a) is there a way I can give my hosts TWO IP addresses on their interfaces?
  (Old IP and New IP) for say, a month.
  (Thery're BSDI boxes)

  b) If this isn't the way to do it, what is the best way?
...
<<<

You can assign multiple IP addresses to an interface. I know of three ways:

a) Probably requires a kernel hack:
	ifconfig lo1 second-ipaddr ...

where lo1 is an extension to the loopback interface (lo0). BSD 4.4
might have a better way to do this.

b) You can get MorningStar Technologies PPP software and use their
   IP tunnel drivers to create pseudo interface du0, du1, etc and
   create multiple IP addresses to a host.
 
c) This might work:
   Create arp entries for the new IP addresses and then use gated
   to propagate the route to the new address via the old address.
   You may need to hack gated.


-- 

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

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 20:00:30 GMT
From:      lichtin@olsen.ch (Martin Lichtin)
To:        comp.protocols.tcp-ip
Subject:   Unbalanced routing -- How to detect?


I would like a tool which showed me the full round trip routing for IP
packets, so I could detect if there are unbalanced routes. I can use
traceroute in one direction, but then again, I don't see which route
the reply packets take.

Any hints on how to detect unbalanced routing? Thanks,


Martin Lichtin                            Olsen & Associates AG (info@olsen.ch)
lichtin@olsen.ch                       Research Institute for Applied Economics
T +411-386-4848  F +411-422-2282   Seefeldstr. 233, CH-8008 Zurich, Switzerland

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 20:40:13 GMT
From:      wag@swl.msd.ray.com (William Gianopoulos {84718})
To:        comp.protocols.tcp-ip
Subject:   MS-DOS TCP/IP question

This is probably a dumb question, but a coworker asked me to post this for him.
He is looking for a MS-DOS TCP/IP implementation which allows multiple
simultaneous FTP and Telnet servers.  He is trying to implement a TCP/IP
based buletin board type system on an MS-DOS PC.

-- 
William A. Gianopoulos; Raytheon Missile Systems Division
wag@sccux1.msd.ray.com

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 20:56:58 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Lon Stowell (lstowell@pyrnova.mis.pyramid.com) wrote:
:    Then on the LAN, if fragment 4 out of 23 is lost, the other 22
:    don't have to be retransmitted?   
 
:    Seems kinda expensive to me.

Ah, but the question is should one be optimizing for the "error" case
and not work as fast as one might in the "error-free" case, or the
error-free case, and not work as well as one might in the error case?

Of course, the answer to the question is likely to be "it depends..."
:) :( :) ... on how many errors happen in the error case, how often
one hits the error case, and such. I imagine that most people (myself
included) would say that sending packets that have to be fragmented
into 23 parts might be a bit excessive (or perhaps a contrived
example, or NFS V3?  :), but sending packets that have to be fragmented
into say 8 parts isn't the root of all evil.

Just was is the typical frame loss rate these days? I expect that if a
network had a loss rate of 1 in 23 frames, or even one in 230, 2300,
or perhaps even 23,000 (perhaps that's a stretch?), that very little
would work well - independent of the presence of IP fragments - and
people would be dispatched to fix that network in short order.

I was not there, I was too young, but I expect that a lot of the "IP
fragments are evil" thinking was generated back when networks did have
higher error rates, and we did have more interfaces which could not
handle back to back packets - now that we can get "back to back"
packets without IP fragments, those interfaces are being replaced, now
we now have links which are less susceptible to noise, we have a
better understanding of how to avoid and recover from congestion.

If our congestion is based on number of bytes, don't we actually
transmit more bytes in the no fragment case, than in the fragmented
case because we replicate the upper level headers?

In short, our technology is evolving - our thinking should evolve with
it. 

rick jones
speaking only as rick jones...
everything in moderation, nothing in excess...

#really arcane drift...

Here is a side track - Path MTU discovery is a way to make our
networks run better by avoiding intermediate node fragmentation. I can
see where if one was running TCP, and trying at all cost to avoid IP
fragments, that Path MTU discovery would be happiness and joy. My
question is "Is it good when you know that you are going to be sending
fragments in the first place?" In other words, do we even want to try
and fragment down to the lowest common segment size at the sending
host for something like NFS? I would think that we would be better-off
*not* doing that when we know that we are going to fragment anyway.
The reasoning is this - by not fragmenting down to the smallest size
along the path, we reduce the total number of frames transmitted,
thereby reducing the likelihood that any one or more of the frames are
going to be lost. This is predicated on the assumption that the unit
queued in intermediate nodes is a "packet" and not a number of bytes,
and that intermediate nodes are at least as good as the end nodes in
fragmenting IP datagrams, and that the primary cause of lost fragment
is congestion.

I imagine that the counter argument would be that when fragmenting IP
fragments in an intermediate node, one ends-up creating more IP
fragments than fragmenting to the smallest size in the first place.

I wonder which is correct, in which cases? In the FDDI to Ethernet
case, and using NFS (8KByte read/write), we would start with 2
fragments on the fibre, each of which would be further fragmented into
3 fragments on the Ethernet, giving 6. Total fragments transmitted
would be 8. If we fragment to Ethernet size in the first place, we
would put 6 fragments on the fibre, and 6 on the Ethernet, for a total
of 12.

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 21:14:23 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Unbalanced routing -- How to detect?

> I would like a tool which showed me the full round trip routing for IP
> packets, so I could detect if there are unbalanced routes. I can use
> traceroute in one direction, but then again, I don't see which route
> the reply packets take.
> Any hints on how to detect unbalanced routing? Thanks,

Yes, put in the loose source routing option and then you can see the
round trips (assuming enough routers in the path support the LSRR
option).  Check out Section 8.5 of my recent book "TCP/IP Illustrated"
(Addison-Wesley, 1994) for some examples.  The source code for a version
of traceroute that supports the LSRR option is available in the tar file
for this book (ftp.uu.net:/published/books/stevens.tcpipiv1.tar.Z).

	Rich Stevens

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 21:27:22 GMT
From:      mark@wizard.pilot.dmg.ml.com (Mark Hahn)
To:        comp.protocols.tcp-ip
Subject:   Lastest info on Next Generation IP

Does any one know where I can get information about the
proposals for the next version of IP.  I believe that there
are two current proposals under review, and that the IETF
has descriptions available some where, but I cannot find
the reference.  Please send reponsed via E-Mail (and to 
prevent the me-too's,)  I'll post the answers.
-- 

---------------------------------------------------------
Mark P. Hahn                  | E-Mail: mark@ml.com
Systems & Technology Audit    |  Phone: 212-236-7280
Merrill Lynch, South Tower    |    Fax: 212-236-7282
New York, New York 10080-6114 | 

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 13:20:02 -0700 (PDT)
From:      David L Miller <dlm@cac.washington.edu>
To:        comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime martin bowman <mbowman@sita.int>
Subject:   Re: POP on SCO


Are you looking for a client or server?  If a server, then try the ipop2d
and/or ipop3d servers from the UW IMAP Toolkit, available from
ftp.cac.washington.edu in the file mail/imap.tar.Z. 

|\ |  |\/|  David L. Miller    dlm@cac.washington.edu  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing, JE-20
4545 15th Ave NE, Seattle WA 98105, USA

On Wed, 6 Jul 1994, martin bowman wrote:

> 
> Does anyone have any information on implementing the POP protocol on SCO UNIX?
> 
> 

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 07:06:07
From:      jlamia@skypoint.nat
To:        comp.protocols.tcp-ip
Subject:   115200 baud with Trumpet TCP Manger

I am unable to set a abud rate of over 57600 with Trumpet's TCP Manger 1.0A. I 
would like to use a 28.8 modem with compression and acheive 115200 baud. Is 
there a newer version of this sfotware or is there a way to configure this 
baud rate through the dialing script and override the setup settings?

Any help will be greatly appreciated.

--
J.R. Lamia          jlamia@skypoint.net
SHL Systemhouse
Minneapolis, MN

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 02:59:25 GMT
From:      sar@prologic.com (Steve Rago)
To:        comp.protocols.tcp-ip
Subject:   Re: Using SIGIO on socket with Esix ??

In article <Cs8CEw.IH7@afp.com> erick@afp.com writes:
>
>Hi.
>
>I don't kown how to make the "Interrupt Driven Socket I/O" work on Esix 4.1-2

[ stuff deleted ]

>With the program listed:
>
>	/* set the process receiving SIGIO/SIGURG signals to us. */
>	if (fcntl(ISocket, F_SETOWN, getpid()) < 0) {
>		perror("fcntl F_SETOWN");
>		exit(1);
>	}
>
>	/* allow receipt of asynchronous I/O signals. */
>	if (fcntl(ISocket, F_SETFL, FASYNC) < 0) {
>		perror("fcntl F_SETFL");
>		exit(1);
>	}
>
>it always does a "invalid argument" on the F_SETOWN fcntl.
>Why ?

[ source deleted ]

The problem is that in your makefile, your specify the following
libraries:	-lc -lsocket -lnsl

If you remove the "-lc" and recompile, the programs work as expected
because, on SVR4, the F_SETOWN emulation is handled in the socket
library, and you are explicitly forcing ld to resolve the fcntl symbol
from the C library instead of the socket library.

Steve Rago
sar@prologic.com

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 08:15:39
From:      padgett@141.240.2.145 (Padgett 0sirius)
To:        comp.protocols.tcp-ip
Subject:   Re: MS-DOS TCP/IP question

In article <1994Jul5.204013.15421@swlvx2.msd.ray.com> wag@swl.msd.ray.com (William Gianopoulos {84718}) writes:
>This is probably a dumb question, but a coworker asked me to post this for him.
>He is looking for a MS-DOS TCP/IP implementation which allows multiple
>simultaneous FTP and Telnet servers.  He is trying to implement a TCP/IP
>based buletin board type system on an MS-DOS PC.

I have been able to have at least two simultaineous FTP connections to a PC
using FTP Software's PCTCP FTPSRV (800.282.4387). Haven't tried more though.

			A. Padgett Peterson, P.E.
                        Cybernetic Psychophysicist
			   We also walk dogs
	 	       PGP 2.4 Public Key Available

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 03:19:57 GMT
From:      gnb@bby.com.au (Gregory Bond)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

In article <2vanq6$g7e@sun.cais.com> bass@cais.cais.com (Tim Bass (Network Systems Engineer)) writes:

   This review is too late.  Stevens book, _TCP/IP Illustrated_
   is great book.  This books has been out as long as Philadephia 
   (the movie) or longer.  We certainly don't need a review on
   6 month old movies OR 6 month old books.

Speak for yourself, yankee.

This is the other side of the world, and books take forever to get out
here.
--
Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia

Atilla The Hun's Maxim: If you're going to rape, pillage and burn, be sure to 
do things in that order.  -- P. J. Plauger, Programming On Purpose, p147


-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 94 12:19:17
From:      zhao@crl.nmsu.edu (Z. Zhao)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp
Subject:   where can I get the interSLIP for MAC?

Can anybody here tell me where the interSLIP for MAC is hidden ?
Is it a freeware or shareware or commercial package?


Thanks in advance,

ZZ

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 13:31:00
From:      loss@husky.bloomu.edu (Doug Loss)
To:        comp.protocols.tcp-ip
Subject:   Re: CD-ROM and TCP/IP

In article <2v25u2$d1q@pyrnova.mis.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
>In article <1994Jun30.185731.23356@moore.com> chris@moore.com (Chris Box)
>writes:
>>Does anyone know how I'd attach a CD-ROM to a TCP/IP network as an
>>independent device?  I don't want it attached to anyone's PC, but would
>>rather it have a direct connection something along the lines of a
>>printserver device which attaches directly to the ethernet cabling.
 
>  Sure.  Since you don't want to do the obvious and cheapest and most
>  robust thing and just put in on a PC and treat it like any other
>  drive and NFS mount it to the tcp/ip network, the following is
>  pretty much what you are stuck with:

[description of do-it-yourself file server deleted]

>  This answer, although somewhat unduly sarcastic is not entirely
>  in jest.  You can either attach it to someone's PC or buy a
>  standalone unit and put the CD-ROM on that.  These are cheap, pretty
>  reliable, off-the-shelf answers.  The alternative, until someone
>  sells a CD-ROM NFS server box, is gonna get pretty ugly. 

Actually, DEC does sell such a box.  It's called an InfoServer, as I recall, 
and it allows you to hang lots of different mass storage devices on your net.  
It costs about $2000 US, I think.



Doug Loss                        Only a sadistic scoundrel
Data Network Coordinator         --or a fool--
Bloomsburg University            tells the bald truth
loss@husky.bloomu.edu            on social occasions.
Voice (717) 389-4797

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 15:35:52 -0400
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Round robin DNS?

In article <2vddq4$nst@panix.com>, John Hawkinson <jhawk@panix.com> wrote:
>In <2vcncl$pe6@bosnia.pop.psu.edu> barr@pop.psu.edu (David Barr) writes:
>
>>However, I'm told ever since the root nameservers all switched to
>>using round-robin versions of BIND, mail load on big equal-preference-MX
>>sites like uunet.uu.net became much more uniform.
>
>How could this be? The root nameservers don't return RRs for such
>domain names, unless they cache them, which seems unlikely.

When doing cross-root-domain lookups (.edu to .com, .uk to .gr),
lookups involve the root nameservers.  (which are thus cached)

>It's
>merely a question of when the servers for the zone that uunet.uu.net
>is in started running round robin.

that too.  (true, most of the effect is gained there)

--Dave
-- 
"Opera is when a guy gets stabbed in the back and instead of bleeding
he sings." - Ed Gardner

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 17:22:52 -0500
From:      sulistio@futon.sfsu.edu (Sulistio Muljadi)
To:        comp.protocols.tcp-ip
Subject:   Connecting to Internet

Hello,
I am trying to set up Internet conection (full IP) for my company.
It will be on 56kbps leased line.  I am trying to figure out what kind
of hardware needed to set the connection.  We are using many flavor of UNIXes.
Please send me e-mail, and possibly the prices w/ the phone number to contact.
Thanks.

-- 
Mul			    |  Alt. address: sulistio@chop.isca.uiowa.edu
sulistio@futon.sfsu.edu	    |  Compu$erve id 73232,1324
#include "std/disclaimer.h" | 
>Genius is one per cent inspiration and ninety-nine per cent perspiration.
>					  Thomas Alva Edison (1847-1931)

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 14:45:44
From:      padgett@141.240.2.145 (Padgett 0sirius)
To:        comp.protocols.tcp-ip
Subject:   FTP Software Kernel API

Would someone please point me to the FTP Software PCTCP Kernel System Calls 
API. I have looked on ftp.ftp.com but may have just missed it.

Called FTP and they said "send $400 for the SDK and the API is included". 
Since the SDK is all C modules and I program in assembly this does not
seem reasonable. Am about ready to revert to programming the driver 
directly (have the driver API v111) but since we purchased PCTCP v2.3 & 
have the kernel this seems like a lot of bother.

Assistance would be appreciated.

			A. Padgett Peterson, P.E.
                        Cybernetic Psychophysicist
			   We also walk dogs
	 	       PGP 2.4 Public Key Available

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 94 10:20:57 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU


>karl@cavebear.com (Karl Auerbach)
> I suspect that you are thinking of Un*x/BSD code constructs.  My concern is 
> about reassembly in general.  When I say "reassembly buffer" I mean that one 
> is allocating space to put the packet.  

I don't understand what you're trying to say here.  Perhaps you could
elaborate?  In BSD, to a first approximation, the only place
allocation gets done is in the driver, for space for individual
incoming packets.  So my question is, how does your environment work,
and where does the reassembly buffer fit in?

> In memory rich environments I would 
> guess that people could allocate 64K byte buffers in anticipation of even the 
> largest possible size of IP reassembled packet.  In lesser environments, such 
> as pre-windows PCs and many embedded controller systems, it is important to 
> try to be careful about wasted buffer space.

The idea here is that if you guess that a frame is 8k+epsilon (8336)
long (a sophisticated version might have incestuous knowledge of NFS
rsize/wsize), you'll usually be right.  You'll be right so often that
relatively little memory is lost.  In my trace, 70% of the
fragmented packets were 8k NFS packets.  Nearly all the rest 
were 4k NFS packets.  Thus, 4k of memory would be wasted on 30% of the
packets.  Thus, in this environment, my algorithm would waste

(0.3 * 4k) / 8k = 15% of the memory

Many memory allocators do worse than this.

> I've made the argument a few times to the IPng folk, but never very strongly, 
> that whatever happens in IPng, one should be able to know the reassembled size 
> from any fragment, not just the last one.

Well, here's your chance to convince us...a start.  I think you'd need an
inevitable structural reason or a noticeable savings in overall
implementation or processing time for a lot of people to convince
people to add to an already noticeably more complex protocol than IP
itself when lots of people will have to implement it, and
TCP/IPcurrent processing latency is already high.  My opinion, of
course - I am in no present danger of becoming an IPng designer.

							Jon
-- 
WWW/Mosaic Home Page:  http://www-cse.ucsd.edu/users/jkay
Email:                 jkay@cs.ucsd.edu

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 10:30:04 GMT
From:      jhalpin@netcom.com (Joe Halpin)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Coding Conventions

In article <9407060505.AA24165@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes:
>Is there any widespread standard for coding conventions, such as nameing
>functions, variables, uppercase, lowercase, etc., or is this too
>personal and non-urgent a matter for such a standard to be accepted?

You might be interested in a book called "Writing Solid Code" published 
by Microsoft press. It's about the internal practices of Microsoft, and 
contains some good ideas that are widely applicable.

-- 
--------------------------------------------------------------------------
Joe Halpin                           |             Centex Real Estate Corp 
jhalpin@netcom.com                   |                           Dallas TX 
Programmer/Analyst/Whatever          |         Standard Disclaimer Applies
---------------------------------------------------------------------------

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 10:47:16 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2vcheq$71f@hpindda.cup.hp.com> raj@cup.hp.com writes:

>Of course, the answer to the question is likely to be "it depends..."
>:) :( :) ... on how many errors happen in the error case, how often
>one hits the error case, and such. I imagine that most people (myself
>included) would say that sending packets that have to be fragmented
>into 23 parts might be a bit excessive (or perhaps a contrived
>example, or NFS V3?  :), but sending packets that have to be fragmented
>into say 8 parts isn't the root of all evil.

I'm not sure that I'd want to be trying to defend intentional
fragmentation.  Certainly older versions of NFS/UDP have a history of
causing problems because of fragmentation.  One of the advantages of
NFS/TCP is that it can easily take advantage of Path MTU Discovery and
thereby avoid fragmentation in routers.

Fragmentation can be expensive throughout the whole distributed
system.  It can be expensive in hosts (both fragmentation and
reassembly) and it can also increase the load on routers (whose load
is more nearly proportional to packets/second than bits/second).  As a
relatively minor side effect, subnets with much fragmentation appear
often to have relatively low channel bandwidth utilisation.

It isn't an accident that the IP/ATM MTU is larger than an older ~8K
NFS/UDP packet.  There was a strong desire to avoid having to fragment
NFS/UDP over homogeneous IP/ATM subnets.  There are other reasons for
the chosen IP/ATM MTU, but NFS/UDP was definitely a major
consideration.

>I was not there, I was too young, but I expect that a lot of the "IP
>fragments are evil" thinking was generated back when networks did have
>higher error rates, and we did have more interfaces which could not
>handle back to back packets - now that we can get "back to back"
>packets without IP fragments, those interfaces are being replaced, now
>we now have links which are less susceptible to noise, we have a
>better understanding of how to avoid and recover from congestion.

Hmmm.  This originated a bit before my time as well.  However I can
say from implementation experience that fragmentation/reassembly in
hosts is not free.  Also, technologies such as Path MTU Discovery
exist and can significantly reduce fragmentation.  At least one of
the IPng proposals is requiring implementation of Path MTU Discovery
because the principals concluded that fragmentation remains evil
in the modern day.

Perhaps I wouldn't choose to couple discussions about link noise with
discussions about congestion avoidance and control.  The congestion
avoidance and control problems were solved by Van Jacobson after
careful study (see his paper in SIGCOMM for more details).

>Here is a side track - Path MTU discovery is a way to make our
>networks run better by avoiding intermediate node fragmentation. I can
>see where if one was running TCP, and trying at all cost to avoid IP
>fragments, that Path MTU discovery would be happiness and joy. My
>question is "Is it good when you know that you are going to be sending
>fragments in the first place?" In other words, do we even want to try
>and fragment down to the lowest common segment size at the sending
>host for something like NFS? I would think that we would be better-off
>*not* doing that when we know that we are going to fragment anyway.

No.  Consider the impact on routers, for example.  Also, it matters
whether you are talking about NFS/TCP or NFS/UDP.  I strongly favour
the former for several reasons, not least of which is that the client
can know when the server goes down and take appropriate action.
Having a stateless file service protocol does NOT imply that is can
not or should not use a stateful transport protocol (there is a common
misconception about this).


-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 18:15:31 -0400
From:      "Bryan J. Ischo" <bi04+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Getting Remote Host Address Before Accept()


This is more of a UNIX question than tcp-ip, but ... does anyone know how to
get the address of the next remote host on the listener queue BEFORE calling
accept()?  Basically, I want to know who is trying to connect so I know
whether or not to accept the connection.  I could accept the connection,
the check the remote address in the struct sockaddr filled in by accept(),
then disconnect the remote host is not on my access list ... but as far as I
know, the connect() call on the other end would succeed, and I don't want that.

Any responses should be sent to this account as well as to this bboard.

Thank you very much,
Bryan
bji+@cs.cmu.edu (preferred), bi04+@andrew.cmu.edu

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 12:44:13 GMT
From:      ckingsbu@mason1.gmu.edu (Christopher E Kingsbury)
To:        comp.protocols.tcp-ip
Subject:   Help Tuning FTP...

What can I do to tweak the transfer rate of FTP (i.e. packet size,
process priority, ...).  Currently, I am having to transfer very large
files between UNIX boxes across dedicated lines, a local ethernet 
network, and the internet.  If somebody could recommend some books, 
electronic documents, or has some ideas I would be very grateful.

Thanks in advance,
Christopher Kingsbury

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 94 13:41:59 GMT
From:      waghani@elof.acc.iit.edu (Anita Waghani)
To:        comp.sys.novell,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip
Subject:   Which protocol ? IP or IPX?


Which is a better choice of protocol IP or IPX ? for a Novell Network
of PC compatibles.
If both protocols are required what would be the ideal mix ?
The LAN may require to network with other networks hence IP would be
necessary, but what percentage of nodes should have IP capability ?
Only one ? or all ?
would the size of network would have any influence on decision ?

I do remember IP vs IPX discussion on the net . Is there a FAQ, archives,
technical papers, books etc which discusses this issue ?

I will post a summary if there's enough intrest.

Thanks for reading this post.
--aw




-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 13:42:03 GMT
From:      wjw@pt.com (Wald Wojdak)
To:        comp.protocols.tcp-ip
Subject:   LLA for the HP-UX network interface driver.

Hi there,

Is anyone out there who is familiar with the HP-UX rev 9.0x A 9000/747?
I am in a process of writing a VME FDDI network interface driver for 
the HP-UX 9.0x. The device driver interfaces to the TCP/IP and also needs to 
provide a Link Level Access (LLA) interface which allows application to talk 
directly to the driver. This LLA is the HP invention. I have been working with
the HP Technical Support located in Chelmsford, Massachusetts for the last 
two months trying to get some information regarding this LLA interface but 
they are not of any help. 

Is anyone out there who knows how to implement the LLA interface for
the HP-UX 9.0x network interface driver?

Waldemar Wojdak
Performance Computer                 --    --   --    Phone: (716) 256-0200
A Performance Technologies Company     |  |    |      Fax:   (716) 256-0791
315 Science Parkway                  --   |    |      Internet:  wjw@pt.com
Rochester, NY 14620                 |      --   --
-- 
__
Wald Wojdak, Performance Technologies Incorporated	wjw@pt.com
315 Science Parkway, Rochester, New York 14620            uupsi!ptsys1!wjw

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 14:54:14 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Help Tuning FTP...

> What can I do to tweak the transfer rate of FTP (i.e. packet size,
> process priority, ...).  Currently, I am having to transfer very large
> files between UNIX boxes across dedicated lines, a local ethernet 
> network, and the internet.  If somebody could recommend some books, 
> electronic documents, or has some ideas I would be very grateful.

The best reference I've found on this is Jeff Mogul's chapter:

	%T IP Network Performance
	%A J. C. Mogul
	%B Internet System Handbook
	%E D. C. Lynch and M. T. Rose
	%I Addison-Wesley
	%C Reading, Mass.
	%P 575-675
	%D 1993

My first idea is for you to find out the window size used by your two
hosts.  (If the transfer is always unidirectional, then all you really
care about is the window advertised by the receiver.)  tcpdump is a
simple way to find that out.  Then calculate the bandwidth-delay product
for your pipe between the two hosts (ping can help here to measure the
RTT), and compare.  If there's a big difference then you can probably
change the default TCP receive buffer size on the receiver.

	Rich Stevens

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 17:01:25 GMT
From:      Bob Smith <bsmith@rahul.net>
To:        comp.protocols.tcp-ip
Subject:   RFD: comp.dcom.cdpd

************************************************************************
                      REQUEST FOR DISCUSSION (RFD)
                            comp.dcom.cdpd
************************************************************************

(This is **NOT** a Call For Votes.  A Call For Votes will be issued in
the groups to which this message is posted 21 to 30 days from the date
that this message first appears. Voting is to be recorded by a neutral
third party.)

Group Name:     comp.dcom.cdpd
Status:         Unmoderated
Summary:        Discussion of all aspects of Cellular Digital Packet
                Data (CDPD), including discussions of carriers, services,
                applications, specifications, and noteworthy events.
Distribution:   World

                                CHARTER
                                -------

CDPD is wireless protocol which offers low cost and ubiquitous radio
coverage to TCP-IP networks.  The technology uses the idle voice channels
available in the existing cellular telephone system for packet data
transmission. Application interface to CDPD can be via telnet, SLIP, UDP,
or TCP.  A CDPD modem uses the AT command set and has an IP address which
is assigned by the local cellular company (just as your cellular carrier
assigned the phone number to your cellular phone). CDPD may be the 
preferred remote/mobile WAN since the time and cost overhead of a cellular
call establishment is not present.

The aim of comp.dcom.CDPD would be to provide an informal electronic
conference for anyone curious about, or involved with CDPD. It is hoped
that the group may further the understanding and awareness of CDPD. 

CDPD's success requires the cooperation and coordination of many diverse
players: application developers, system integrators, cellular carriers, 
infrastructure manufacturers, and modem manufactures. A newsgroup where
ideas, suggestions, and questions can be freely exchanged is needed to 
help tie these players into an industry.

The FAQs would be an important part of the newsgroup and would include
as a minimum:
        FAQs about the nature and scope of CDPD
        a list of CDPD carriers and services offered
        a list of CDPD modem manufacturers
        a list of other CDPD products available

This newsgroup would allow the rapid and timely discussion of CDPD
related issues and events which might otherwise never be fully 
disseminated.

Topics for discussion would include :-

        Product announcements
        Press releases of interest to the CDPD community
        Innovative CDPD applications
        CDPD deployment issues and plans
        Interpretation of the CDPD specification
        Infrastructure hardware: NMS, MDBS, MD-IS, ...
        Infrastructure software: NMS, MDBS, MD-IS, ...
        Modems - specifications, opinions, etc.
        New product ideas
        Databases, lists of...
        CDPD security, encryption, and firewalls
        Announcements/reviews of papers/conferences
        Comparisons to alternatives such as RAM, Ardis
        General discussion/opinions/questions.
        Positions vacant
        Professional news
        Economic issues


We hope that you will support this group, and look forward to your
comments and participation in the discussions in news.groups.

Please distribute this proposal to your friends and colleagues.
This RFD has been posted to:
        alt.digital.radio
        comp.dcom.lans.misc
        comp.dcom.modems
        comp.dcom.telecom
        comp.os.ms-windows.networking.tcp-ip
        comp.os.ms-windows.programming.networks
        comp.protocols.misc
        comp.protocols.tcp-ip
        comp.std.wireless
        news.announce.newgroups
        sci.geo.satellite-nav


Thank you.




The Process of Creating a Newsgroup
------------------------------------

(a) RFD: Request for Discussion, i.e.., public hearing to take place in
           the newsgroup news.groups on Internet for approximately one
           month
(b) CFV: Call for votes (the voting period will be about 25 days)
(c) Counting of votes and public display of votes
(d) Announcement of new newsgroup

(a)-->(b) assumes no major disagreements about this newsgroup during
           discussion.
(c)-->(d) assumes that the vote is favorable, i.e., Y > N+100 .and.
           Y > (2/3)(Y+N)

Y being the number of YES votes, N being the number of NO votes for the
creation of the proposed newsgroup.


-- 
Bob Smith <bsmith@rahul.net>

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 02:07:29 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   DNS

Can someone explain what DNS is?

Also, what does it have to do with DHCP?

Where can I look for more info? (RFCs, etc.)

Thanks,

--Mike

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 18:25:39 GMT
From:      philippe@gull.cfmu.eurocontrol.be (Philippe Waroquiers)
To:        comp.protocols.tcp-ip,comp.unix.programmer,comp.sys.hp.hpux
Subject:   changing route gives TCP problem


We have +- 30 workstations connected to a server via two Ethernet LANs.
TCP/IP is used between the server and the workstations.
Each worstation has two IP addresses (wsad1 and wsad2).
The server has also two IP addresses (serverad1 and serverad2)
The applications are using the first address (wsad1 and serverad1).
When there is a problem on one LAN, we want to have the other LAN used
transparently by the applications in less than 60 seconds.

The IDEA we are looking is :
  if we cannot contact the server via the lan1 then
    first: add another route to the server via the other address of the
      server (the internal IP router of the server will route the packets).

    second: on the server, add a route to our workstation via the second
      address (again, the internal IP router of the ws will route the packets).
The lan problem is simulated by disconnecting the cable.

To do this, we have a SHELL SCRIPT running on each ws. The shell script
does an infinite loop :

    while true
      if PING serverad1 FAILS 
      then
         route add host serverad1 serverad2 1
         remsh serverad2 -n /etc/route add host wsad1 wsad2
      fi

After changing the routes, we obtain the following NICE results :
  1) new tcp/ip connections can be opened without any problems between
     the addresses serverad1 and wsad1.

  2) idle connections (i.e. with no traffic on it when disconnection)
     works after changing the routes.

BUT PROBLEM :
  3) non-idle connections (i.e. traffic going on when disconnection) seems
     to behave erratic :

        some small number of packets are transmitted at very large interval
        (typically 1 min). After a few minutes, connection is closed (reset).

     or
        nothing happens anymore on this connection. After a few minutes,
        connection is closed (reset).

Is there an explanation for this behaviour ?
Is there a solution to this behaviour ?
     
Many thanks in advance for any help/idea/suggestion/explanation.

     
   
--
Philippe WAROQUIERS             Eurocontrol - Central Flow Management Unit
philippe@cfmu.eurocontrol.be    Rue de la fusee, 96
Tel: +32 2 729 97 35            1130 Brussels
Fax: +32 2 729 90 22            Belgium

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 19:28:53 GMT
From:      jimrush@indirect.com (Jim Rush)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

W. Richard Stevens (rstevens@noao.edu) wrote:
: > Got sent the full table of contents last year when I emailed the author
: > an enquiry regarding one of his other books. I've limited this message
: > to the main chapter headings; for those interested I can email the full
: > TOC.
 
: FYI, the entire TOC (ascii and PS), Preface, and complete sample chapter in
: PS are available via anonymous ftp from aw.com in the aw.prof.comp.series
: directory.
 
: 	Rich Stevens
My 2cents,

	Thanks Rich.  I have found the book to be very usefull.

Jim

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 19:35:35 GMT
From:      ken@jazz.concert.net (Ken Whitfield)
To:        comp.protocols.tcp-ip
Subject:   IP Routing

Fellow Netters:

Looking for software thay allows a MAC or PC to route or bridge IP packets from 
an ethernet interface through a serial port. 

		        PC/Mac          PC/Mac
			Router 		Router
			 or		  or
			Bridge		Bridge
		_____	_____		_____	_____
		|   |	|   | Serial	|   |   |   |
		|   |   |   |-----------|   |   |   |
		|   |   |   |           |   |   |   |
 -----   -----           -----	-----
		  |       |		  |       |
		============		==============


Thanks in Advance!

--
-------------------------------------------------------------------------------
Ken Whitfield				MCNC Information Technologies Division
Network Specialist			3021 Cornwallis Road
(919)248-1998				RTP, NC 27709-2889

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 94 18:52:28 BST
From:      udaa055@bay.cc.kcl.ac.uk (Andy Harper, KCL Systems Manager)
To:        comp.protocols.tcp-ip
Subject:   Implementing IP address extensions

An oft discussed question is how the IP addresses used on Internet can be
extended now that the explosion in personal computers and connectivity has left
the 32-bit address space looking a bit sick! Rumour has it that, if growth
increases at the same rate as currently, we'll run out of addresses in the near
future.

Clearly, there a number of ways it COULD be done and many are being examined by
the powers that be to decide on a way forward. What concerns me though, is how
to implement any of them without incurring significant cost and inconvenience
to our existing users! Isn't it the case that all of the mechanisms so far
proposed will require changes to routers and/or the IP software (if you're
going to have any kind of address extension then software and routers need to
be aware of it).

I had considered that changes might be localised to the external connections of
a site, leaving all internal systems as they are, but those internal systems
would still need the ability to specify an extended address if they want to get
elsewhere. Some clever mapping techniques might be possible but I can't see one
that is totally effective.

So, what options are there that don't require all and sundry who use Internet
to spend wads of cash and/or find upgraded network applications that understand
new addressing formats?

Thanks

Andy Harper
Kings College London

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      06 Jul 1994 20:49:13 GMT
From:      lee@netspace.students.brown.edu (Lee J. Silverman)
To:        comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime
Subject:   Re: POP on SCO


	There's a POP server (and source) for Linux, available on
sunsite.unc.edu.  Presumably you could download the source for the
server and recompile it for SCO.

Lee

--
Lee Silverman, Brown class of '94, Brown GeoPhysics ScM '95
Email to: Lee_Silverman@brown.edu
Phish-Net Archivist: phish-archives@phish.net
"Nonsense - you only say it's impossible because nobody's ever done it."

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Thu,  7 Jul 94 08:01:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   FTP Software Kernel API

P >Called FTP and they said "send $400 for the SDK and the API is included". 
P >Since the SDK is all C modules and I program in assembly this does not
P >seem reasonable.

I think it might be time to learn C... :-)

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu,  7 Jul 94 08:03:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: CD-ROM and TCP/IP

L >>  This answer, although somewhat unduly sarcastic is not entirely
L >>  in jest.  You can either attach it to someone's PC or buy a
L >>  standalone unit and put the CD-ROM on that.  These are cheap, pretty
L >>  reliable, off-the-shelf answers.  The alternative, until someone
L >>  sells a CD-ROM NFS server box, is gonna get pretty ugly. 
L >
L >Actually, DEC does sell such a box.  It's called an InfoServer, as I recall, 
L >and it allows you to hang lots of different mass storage devices on your net.  
L >It costs about $2000 US, I think.

You bet, and when you take the covers off that box, I'll bet you find a
pretty standard PC inside!

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 21:32:23 GMT
From:      martin bowman <mbowman@sita.int>
To:        comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime
Subject:   POP protocol on SCO


Does anyone have any information about implementing the POP protocol on SCO 
UNIX?

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 21:38:06 GMT
From:      martin bowman <mbowman@sita.int>
To:        comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime
Subject:   POP on SCO


Does anyone have any information on implementing the POP protocol on SCO UNIX?

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 22:22:50 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Ran Atkinson (atkinson@sundance.itd.nrl.navy.mil) wrote:
: Fragmentation can be expensive throughout the whole distributed
: system.  It can be expensive in hosts (both fragmentation and
: reassembly) and it can also increase the load on routers (whose load
: is more nearly proportional to packets/second than bits/second).  As a
: relatively minor side effect, subnets with much fragmentation appear
: often to have relatively low channel bandwidth utilization.

First - perhaps that low utilization is the result of not having to
replicate transport headers, and fewer acknowledgements?-) (Or did you
mean effective utilization, but the real utilization was high?)

"Can be" and "Must be (is)" are different statements. It is just as
easy I should think to have "expensive" support for receiving out of
order TCP segments, but just about all (multitasking OS anyway?) TCP
implementations support this feature and do it without people claiming
that it was expensive.

When I look at a profile of a kernel being exercised by the SPEC SFS
(LADDIS) benchmark, the IP fragmentation and reassembly routines are
*way* far down on the list - below fortieth and beyond. Of course,
this could be used as reasoning to go ahead and do the fragmentation
all the way down to the smallest path's size in the host, but it also
indicates (along with the post from the fellow at Cisco) that
fragmentation in the routers does not have to be all that expensive.

While the act of generating IP fragments itself is not "expensive" in
terms of instruction cycles, fragmenting all the way down to the
smallest size will increase the CPU used on the originating host
because it will force more trips through the interface driver. Would
you rather go through an ATM driver and card firmware once, or six
times?

When you say that a router's load is more nearly proportional to
packets/second than bits/second, doesn't that imply that it would be
less "loadful" on the router to send it two larger fragments on the
FDDI ring rather than six smaller fragments? The first case would seem
to place 1/3 the load on the router.

: Perhaps I wouldn't choose to couple discussions about link noise with
: discussions about congestion avoidance and control.  The congestion
: avoidance and control problems were solved by Van Jacobson after
: careful study (see his paper in SIGCOMM for more details).

I wasn't really looking to couple them. However, the only reason that
I can see as being valid for stating that IP fragmention should be
avoided at most cost is the argument that when you loose one IP
fragment, you effectively loose them all. It is also the argument that
I would agree with (modulo the number of fragments you wish to
generate per datagram) The two causes of packet loss with which I am
familiar are congestion, and corruption.

: >Here is a side track - Path MTU discovery is a way to make our
: >networks run better by avoiding intermediate node fragmentation. I can
: >see where if one was running TCP, and trying at all cost to avoid IP
: >fragments, that Path MTU discovery would be happiness and joy. My
: >question is "Is it good when you know that you are going to be sending
: >fragments in the first place?" In other words, do we even want to try
: >and fragment down to the lowest common segment size at the sending
: >host for something like NFS? I would think that we would be better-off
: >*not* doing that when we know that we are going to fragment anyway.
 
: No.  Consider the impact on routers, for example.  Also, it matters

But it was just said that the load on a router is proportional to the
number of packets, and PathMTU has already been shown to *increase*
the number of packets (in one very common case anyhow) that a (first
hop) router will be sent when the packet has to be fragmented in the
first place.

It would definitely increase the number of packets when that router is
routing NFS V2 from ATM to Ethernet or FDDI because the datagram can
arrive unfragmented, in *one* packet on the ATM interface as opposed
to six.

I wonder which is more expensive in the new Cicso routers - receiving
six packets as opposed to one, or receiving one and having to
fragment it into six? (The ATM to Ethernet case)

Running NFS over TCP would have the same effect then of increasing the
load on the router because it increases the number of packets it
processes (both pseudo fragmentation *and* ACK's I'd imagine ;-)
However, I can agree on advantages in running NFS over TCP in a WAN
case that would outweigh that.

Lest anyone think that I am trying to ferment revolution and start
flooding the Internet with IP fragments, as much as what I've been
saying has been to challenge assumptions to ascertain their validity.
Particularly the one that says that IP Fragmentation is "expensive"
(an unfortunately vague term) I know that I've learned some things
from it (such as the now improved IP fragmenting ability of new Cisco
routers), and I hope that others have too.

rick jones
speaking only as rick jones...

I've always liked the phrase "Don't raise the bridge, lower the
river!"


-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 02:40:15 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2vfarq$562@hpindda.cup.hp.com> raj@cup.hp.com writes:

    I wonder which is more expensive in the new Cicso routers - receiving
    six packets as opposed to one, or receiving one and having to
    fragment it into six? (The ATM to Ethernet case)
    
Fragmenting.  I wasn't able to improve it THAT much.  ;-)

Tony

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 03:34:23 GMT
From:      dkaye@rds.com (Doug Kaye)
To:        comp.sys.novell,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip
Subject:   Re: Which protocol ? IP or IPX?

In article <1994Jul6.134159.2175@iitmax.iit.edu> waghani@elof.acc.iit.edu (Anita Waghani) writes:
>Which is a better choice of protocol IP or IPX ? for a Novell Network
>of PC compatibles.
>If both protocols are required what would be the ideal mix ?

Oooh!  Not an easy question, Anita.  At this point in time it is easier to 
make NetWare adapt to TCP/IP than it is to make "other" things adapt to IPX.  
That's primarily because TCP/IP is found on a wider range of platforms than is 
IPX.  If you're primarily a NetWare shop, there are a number of opportunities 
to linke to other systems using IPX, but they are not universal.  OTOH, while 
it takes some extra effort (and $$) to run NetWare using TCP/IP, you then have 
access tomost non-NetWare systems.

I fyou could be more specific, we could probably give you better advice.  TO 
what must you connect othern than NetWare?

   ...doug

=================================
Doug Kaye         <dkaye@rds.com>
Rational Data Systems, Novato, CA 
Tel:415-382-8400 FAX:415-382-8441
=================================





-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 10:16:32 -0400
From:      jmb@kryten.atinc.com (Jonathan M. Bresler x346)
To:        comp.protocols.tcp-ip
Subject:   slip--must be 2 nets

i have just installed a terminal server with slip capabilities.  
the vendor chase iolan informs me that the two endpoints of the slip
connection must be either on different networks or on different subnets
of a single network.

i checked the rfc1055 and did not find this addressed.  

or is the limitation of different nets/subnets, a routing limitation?

thanks,
jmb
-- 
Jonathan M. Bresler  jmb@kryten.atinc.com	| Analysis & Technology, Inc.  
						| 2341 Jeff Davis Hwy
play go.					| Arlington, VA 22202
ride bike. hack FreeBSD.--ah the good life	| 703-418-2800 x346

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 10:26:19 -0400
From:      imatex@CAM.ORG (Imatex Communications Inc.)
To:        comp.protocols.tcp-ip
Subject:   How to use UDP in interrupt manner with SCO sV r3.2 v4.0?

I want to acheive communications between many servers (that don't
communicate to each other) and many clients (that don't communicate to 
each other neither) using UDP protocol.


I would prefer to work in asynchronous communication, since each clients must
wait for their stdin to receive data to be transmitted on the lan.

I tought to use SIGIO as described by Richard Stevens in Unix Network 
Programming. Since I am developping on SCO Unix System V release 3.4 
version 4.0, SIGIO is not available. I also took a look to streams, but I 
have not found how to implement interrupts.

So far, as I've seen, the only way to use streams in TCP/IP
communication is via TLI. Tell me I am wrong!

Any sugestion, with C code examples, will be VERY helpfull.
Many thanks in advance.

Daniel Beaudry


-- 
Imatex Communications Inc.

imatex@cam.org.ca

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 12:13:19 -0500
From:      claird@Starbase.NeoSoft.COM (Cameron Laird)
To:        comp.os.vms,comp.protocols.tcp-ip,alt.culture.internet
Subject:   What's the metric of your space? (was: VMS and (bundled) TCP/IP)

In article <1994Jul4.130746.1@spcvxb.spc.edu>,
Terry Kennedy, Operations Mgr. <terry@spcvxb.spc.edu> wrote:
>In article <1994Jul2.013658.5866@pinet.aip.org>, boswell@pinet.aip.org (jonathan_boswell) writes:
>> Yes, but the SMTP "conversation" is still layered on top of TCP, which is in
>> turn layered on top of IP, and those darn packets are going to travel all
>> over the country and (possibly) around the world, before they reach their
>> destination.  I think this was the point of the original post, was it not?
>
>  The situation today is that there are a variety of Internet providers in
>most areas. This is a Good Thing - it lets customers shop based on price, per-
>formance, or whatever else makes them happy. However, it means that a site
>that was "real close" one day may be somewhat further away the next day if one
>or both of the parties changes providers. For example, this traceroute (be-
>tween SPC and Stevens Tech, sites only a few miles apart in NJ) goes via Cal-
>ifornia:
>
> 1  gw2-nj.new-york.net (192.107.46.1)  2.2 ms  3.5 ms  2.1 ms
> 2  gw1-nj.new-york.net (165.254.21.2)  5.8 ms  2.8 ms  2.8 ms
			.
			.
			.
>15  stevens-gateway.jvnc.net (130.94.7.50)  299.6 ms *  235.6 ms
>16  vaxc.stevens-tech.edu (155.246.1.4)  207.8 ms *  197.3 ms
			.
			.
			.
>  Unless you have a great deal of traffic destined for a single host or net-
>work that is really suboptimally routed, you should probably ignore this. If
>you do have a lot of traffic, consider a point-to-point link between your
>nets. Of course, you'll have to justify the cost of that, which may not make
>the existing route seem so bad 8-)
			.
			.
			.
This conversation has me confused.  I understand everything
you wrote, Mr. (?) Kennedy--in fact, this was an outstanding
article, being both entertaining and informative--but I don't
know whether it bears on the question (whose?  I've lost
track) of how silly it is for those darn little packets to
bounce around as they do.  I say, there's nothing inherently
wrong in taking a shortcut through California to get from
Delaware to NYC, although it does inspire ruminations on The
Essence of the Post-Industrial World.  Does someone believe
that such a situation inherently involves a call to action?
-- 

Cameron Laird
claird@Neosoft.com (claird%Neosoft.com@uunet.uu.net)	+1 713 267 7966
claird@litwin.com (claird%litwin.com@uunet.uu.net)  	+1 713 996 8546

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 12:03:08 -0400
From:      tal@Warren.MENTORG.COM (Tom Limoncelli)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

In <2vanq6$g7e@sun.cais.com> bass@cais.cais.com (Tim Bass (Network Systems Engineer)) writes:

>This review is too late.  Stevens book, _TCP/IP Illustrated_
>is great book.  This books has been out as long as Philadephia 
>(the movie) or longer.  We certainly don't need a review on
>6 month old movies OR 6 month old books.

Mini-Review of "Philadelphia"
----------------------------- by Tom Limoncelli
I thought the movie Philadelphia was excellent and brought a very
hidden (but pervasive) issue to an audience that would usually not deal
with, nor appreciate, such issues until they were facing them head-on.
(at which time it may be too late to deal with the issue rationally).
I can ignore the minor cultural and acting mistakes, but I was
disappointed to find that the ending is not consistent with the actual
laws in Philadelphia, PA.  To me it was a "suprize ending" because I
was expecting the ending to be consistent with the actual current law.
Though I am not a legal expert, I believe the judge's decision would be
legally consistent with reality if the movie took place elsewhere, for
example New Jersey, where the anti-discrimination laws are different.
I'm not much of an audiophile, but I thought the soundtrack was
excellent.

-Tom
-- 
S ******************* I do not speak for Mentor Graphics Corp ********
W    Anonymous FTP: vector.casti.com /pub/QRD/events/stonewall25
2  WWW/Mosaic/Lynx: http://vector.casti.com/QRD/Stonewall25.html
5    gopher: vector.casti.com select 10, 1, 24, 29.  or call +1-212-242-7366

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 94 06:40:00 GMT
From:      paul@alantec.com (G. Paul Ziemba)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   why no more than 3 interfaces with cslip-2.7?

Software:	LBL cslip-2.7
Hardware:	Sun4
OS:		SunOS 4.1.2

I recently tried increasing NSL from 2 to 4. When I tried loading
cslip.o (I'm using loadable modules), modload ran ld a couple times
(I used the -v argument) but eventually snarked with "invalid argument".

Reducing NSL to 3 eliminated the problem.

How can I get more than 3 slip interfaces?

many thanks,

 ~!paul
-- 
Paul Ziemba, software archaeologist: paul@alantec.com	alantec!paul
    "The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore, all progress
depends on the unreasonable man." - George Bernard Shaw

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 12:08:59 UNDEFINED
From:      mojoski@mindspring.com (Warren D. Simmons)
To:        rec.autos.marketplace,comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Internet Technical Survey ( less than a page )

In article <940707120510.B31800@news.nbnet.nb.ca> davidd@nbnet.nb.ca (David Delaney) writes:

>>Thank You for your time I will post a summary if there is enough responses or 


I beleive this was supposed to be e-mailed, not posted!
-Del Simmons

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 1994 15:59:35 -0500
From:      messina@mcs.com (David Messina)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp
Subject:   Re: where can I get the interSLIP for MAC?

In article <ZHAO.94Jul6121917@crl.crl.nmsu.edu>, zhao@crl.nmsu.edu (Z.
Zhao) wrote:

> Can anybody here tell me where the interSLIP for MAC is hidden ?
> Is it a freeware or shareware or commercial package?

It's free, and available on many archives (info-mac, e.g.)  It also should
be at 

ftp://ftp.tidbits.com/pub/tidbits/tisk/tcp/inter-slip-installer-101.hqx

-- 
David Messina
messina@mcs.com

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 1994 12:05:10 AST
From:      davidd@nbnet.nb.ca (David Delaney)
To:        rec.autos.marketplace,comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Internet Technical Survey ( less than a page )

On Fri, 24 Jun 1994 09:10:38 GMT,  tomw@netcom.com writes:
>
>This is a short questionaire to find out usage trends for various internet 
>connectivity issues, If you have time please fill it out and E-mail to 
>tomw@netcom.com ( no flames please! ). I will post a summary.
>
>How do you currently connect to the internet: ( use an X to fill in field )
>-------------------------------------------------------------------------------
>Raw Serial ( TTY ):Slip:x
>PPP:
>Direct Connection ( via ethernet or other "direct" meachanism ):
>Other:
>Don't know (??):
>
>If you are not directly connected:
>do you use an internet provider ( netcom, delphi... ):x
>do you use a bbs ( any bbs or america online, compuserve ... ):
>are you a university student:
>do you consider PPP or Slip Difficult to set up:
>
>What kind of host machine do you use:
>PC (windows):x
>Sun:
>Other Unix Vendor:
>Mac:
>Other:
>
>Do you read more than 10 news groups:xx
>Do you use telnet:x
>Do you use Ftp:x
>Do you use a Gopher client: x
>Do you use a Wais client:
>Do you use a www client ( like mosaic ):x
>
>If you never have used a mosaic like client do you think you might?:
>do you know what the world wide web is:x
>
>If it was safe, would you use internet shopping or other "non-intrusive" ( you 
>must ask ) services : xx
>
>Do you see the Internet as a way to propagate published documents or other 
>media:x
>-------------------------------------------------------------------------------
>Thank You for your time I will post a summary if there is enough responses or 
>you may ask me via E-mail ( in about a week or so ).
>
>
>
>

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 08:25:38 GMT
From:      bubgo@alf.uib.no (Bjarte Johnsen)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

DNS = Doman Name Server (Cryptic :)

Well basicly it's like this:

All TCP/IP networks relies on ip addresses 129.177.34.221, you get the idea, this however is kinda hard
to remember for a long period, therefor they have made up a sceme that maps this ip number to a address like
this : flie.ifi.uib.no.

So unless you have this mapping stated in your own HOSTS file, wich basicly says that whenever you use 
FLIE.IFI.UIB.NO you really mean 129.177.34.221.
You have to have a sentral machine who does this for you and sends the right translation back to your application.

I don't think I will go any closer into the subject on HOW a DNS server work, doing so would probably make me yet 
another author of a "How DNS work" book.


DHCP = Dynamic Host Configuration Protocol

This doesn't really have anything to do with DNS.

It's "just" a automatic network configurator.
When you put a new pc in a lan, you might have a server who runs DHCP, the network installation program enquires the 
server for it's IP address, netmask, broadcast address, gateways, DNS server, and all other relevant data.



Yours 

Bjarte Johnsen
Engineer
Inst. for Informationscience
Uni. of Bergen, Norway.


-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 16:49:34 -0400
From:      alberg@pipeline.com (Al Berg)
To:        comp.protocols.tcp-ip
Subject:   Routers, packet size, and RFC 1122 (a query)

A client of mine has made some changes to their LAN recently 
with interesting results...

The LAN used to be one big segment with 130 users. In an effort 
to segment traffic, we put a router in and broke the LAN up 
into 6 segments.  In general, performance is good.  FTP between 
the PC clients and the UNIX hosts (1 IBM AIX and 1 SCO) has 
gotten really slow, however.  

We put a protocol analyzer on the net and found that:

When FTPs happen between the UNIX boxes and a PC on the same 
segment, the maximum packet size is about 1500 bytes and 
performance is good.

When FTPs happen between a host on segment A and a client on 
segment B, maximum packet size drops to 576 bytes and speed 
drops by a factor of 5 or more.

When we put up a Chameleon FTP server on a PC on segment A and 
do an FTP from a PC on segment B, maximum packet size stays at 
1500 bytes and performance is good.


The IBM rep sent us info saying that RFC 1122 basically says 
that when IP packets cross a router, IP decides to throttle 
back the max packet size to 576 since any router or gateway 
along the path to the destination will be able to handle that 
size packet.


Some questions:

So, NetManage is breaking the rules here, no?  (Not that I am 
complaining...)

Has anyone "solved" this problem on their net?  



Thanks in advance for any advice you can offer...

Al Berg
NETLAN Inc.
al_berg@netlan.com

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 94 22:16:09 -0700 (PDT)
From:      Robert_Bradford@mindlink.bc.ca (Robert Bradford)
To:        comp.protocols.tcp-ip
Subject:   Small and Compact TCP/IP/PPP


How small and compact, in terms of memory requirements, can you
make a TCP/IP and PPP implementation?

The thought here is to support a particular application that
allows users to dial-up a paging system and to send a page to
another user. Future services in paging will support sending
pages to users with PDAs and laptops that can receive pages.
This will allow sending binary data (e.g., spreadsheet data) to
someone with a pager equipped PDA or laptop.

People using Macs or PCs should be able to connect to the
paging service to send pages using basic TCP/IP (through local
networks or PPP) packages for these platforms. PDAs and similar
small devices may not (do not?) have TCP/IP packages, so the
page entry application on these platforms needs a custom
dial-up protocol or a very small TCP/IP/PPP implementation that
can be bundled with the application.

So, the question is how small can you make such an
implementation? It can be "shrink wrapped" with the application
and just support one application (i.e., one TCP connection) on
one port using only the serial port. It must be able to do
dial-up and accept IP address assignment from the remote
system. The remote end will fully support TCP and IP and PPP,
but the local end need only implement enough to support its
application and still establish a working link to the remote
end.

Any and all thoughts are welcomed. If there is a good response,
I will summarize back to the net. Pointers to other references
are also welcomed.

Bob

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Bob Bradford                 Email: bbradfor@glenayre.com
                                    robert_bradford@mindlink.bc.ca
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+





-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 94 22:18:57 -0700 (PDT)
From:      Robert_Bradford@mindlink.bc.ca (Robert Bradford)
To:        comp.protocols.tcp-ip
Subject:   Choosing TCP or UDP



I am looking for detailed information that will help us decide
whether to use TCP or UDP for some new features we want to
implement.

We currently ship data between our terminals using a serial
based protocol at up to 9600 bps (there may be several such
ports on each terminal). We are moving to TCP/IP over a single
Ethernet port. We are debating whether to use TCP or UDP.

We can model our data in two ways:
  1 - like a transaction system where the application sends an
      APDU to another terminal and the terminal responds.

  2 - like a stream, where one application is sending a number
      of these APDUs back to back, but the responses, which are
      much smaller, may have some gaps between them.

I like TCP for its realiability. We need to be sure the data
gets where its going, and we really don't want to build TCP
type reliability into our application. Further, TCP does some
congestion avoidance, which UDP does not.

Others favor UDP for its reduced overhead, no need to manage
connections, supports the transaction model in 1 above, and may
provide better throughput.

Our current throughput requirements are not great, but new
features involving the real-time movement of compressed voice
are being planned. I should indicate that the networks are wide
area, not LANs, some will be nationwide. Current estimates are
that we will need 1.5 Mbps throughput rates (sustained) into and
out of our equipment.

So we need the best protocol for reliable, high-bandwidth,
real-time applications (actually only the voice data movement
has a real-time requirement). We want to avoid congestion
problems during peak usage periods.

So I need pointers to references for the use of UDP and TCP in
high bandwidth real-time applications. I would also like to
correspond with anyone who has experience in this area. I would
like to hear all advantages and disadvantages for both TCP and
UDP. Posted or email responses are welcomed, and I will
summarize back to this group.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Bob Bradford         Email: bbradfor@glenayre.com,
                            robert_bradford@mindlink.bc.ca
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 10:39:11 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Remote Host Address Before Accept()

> This is more of a UNIX question than tcp-ip, but ... does anyone know how to
> get the address of the next remote host on the listener queue BEFORE calling
> accept()?  Basically, I want to know who is trying to connect so I know
> whether or not to accept the connection.  I could accept the connection,
> the check the remote address in the struct sockaddr filled in by accept(),
> then disconnect the remote host is not on my access list ... but as far as I
> know, the connect() call on the other end would succeed, and I don't want that.

You cannot do this with the typical (i.e., Berkeley-derived) Unix TCP/IP.
Period.  (Well, I guess you could *if* you used something like BPF or
DLPI to look at every SYN that arrives, but I don't think that's what
you're asking ...)  Solaris 2.x has an "experimental" tcp_eager_listeners
variable that was intended for this capability, but as I hear they found
enabling it broke certain applications (FTP).

Also, don't be fooled into thinking TLI can do this for you, and that
it's a sockets problem.  I'm not familiar with a single Unix TCP/IP
TLI stack that gives you this capability either.

Berkeley actually provide a way to do this with sockets but only for the
OSI protocols.  Van Jacobson posted the following note on this same topic
a few weeks ago.

> Message-Id: <9406271419.AA08874@rx7.ee.lbl.gov>
> To: Ian Heavens <ian@spider.co.uk>
> Cc: end2end-interest@charm.isi.edu
> Subject: Re: half baked anycastoff idea...
> Date: Mon, 27 Jun 94 07:19:38 PDT
> From: Van Jacobson <van@ee.lbl.gov>
> 
> > The market demands conformance to Berkeley TCP/IP semantics and
> > API, but I thought the RFCs and not the damn Berkeley code was
> > the standard!
> 
> RFCs typically do a detailed description of the protocol and a
> cursory description of the API.  Berkeley sockets actually
> follow the API sketched in RFC793 very closely (compare the
> description of "OPEN" on p.45 with the semantics of "accept")
> and if you know the early BBN-to-Berkeley history of the BSD
> code, you know that this similarity is no accident.
> 
> It's fairly easy to extend the Berkeley API, in a backwards
> compatible way, to allow a defered accept.  Here is part of the
> accept(2) manual page from 4.4BSD:
> 
>      For protocols marked as requiring an explicit confirmation, such as ISO
>      or DATAKIT, accept() can be thought of as merely dequeueing the next con-
>      nection request and does not imply confirmation.  Confirmation is im-
>      plied by a normal read or write on the new file descriptor, and rejection
>      is implied by closing the new socket.
> 
>      One can obtain user connection request data without confirming the con-
>      nection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non-
>      zero msg_controllen, or by issuing a getsockopt(2) request.  Similarly,
>      one can provide user connection rejection information by issuing a
>      sendmsg(2) call with providing only the control information, or by call-
>      ing setsockopt(2).
> 
> The 'lazy accept' on first read/write is compatible with almost
> all the existing programs.  Work was planned to add a sockopt to
> set/reset the "explicit confirmation" option on a per-listen-socket
> basis for TCP and to do the minor surgery on tcp_input &
> tcp_usrreq needed to implement the option.  Berkeley CSRG died
> from lack of funding before this work was completed.
> 
>  - Van

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 18:26:57 -0400
From:      zbig@junior.wariat.org (Zbigniew J. Tyrlik)
To:        comp.protocols.tcp-ip
Subject:   Re: slip--must be 2 nets

In <2vh2oe$gr1@kryten.atinc.com> jmb@kryten.atinc.com (Jonathan M. Bresler x346) writes:

>i have just installed a terminal server with slip capabilities.  
>the vendor chase iolan informs me that the two endpoints of the slip
>connection must be either on different networks or on different subnets
>of a single network.

I know I am using ( and selling to my customers  :-) Livingstone routers
for some reasons..  

>i checked the rfc1055 and did not find this addressed.  
 
>or is the limitation of different nets/subnets, a routing limitation?

Using Livingstone PM series I use one C class to service a dozen hosts 
on Ethernet, and 2 PM's with dial-up lines; no problems assiging
IP's from this same network, no subnetting in use... 

>thanks,
>jmb


_zjt ( wannabe in training )
-- 
********************************************************************
Zbigniew J. Tyrlik       DoD# 0759   VF700C '84      zbig@wariat.org
APK	       Public Access UNI* Cleveland,          (216)-481-9436
Feeds, shell, FTP, telnet, IRC, MUD      Uniboard distribution point 
********************************************************************

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 23:37:24 -0700
From:      pls@crl.com (Paul Schauble)
To:        comp.protocols.tcp-ip
Subject:   Book recommendation? IP routing

Would anyone care to recommend a book that covers the tcp/ip protocols 
with particular emphasis on ip routing?

I believe that some work has been done by DoD on IP routing over radio 
links. I would be very interested in information on this.

  Thanks,
    ++PLS


-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Fri,  8 Jul 94 00:34:00 -0700
From:      philip.burton@spacebbs.com (Philip Burton)
To:        comp.protocols.tcp-ip
Subject:   Re: THE winsock??


[stuff deleted]

>The big change/addition is expanding the spec to include other networks
>such  as IPX/SPX and OSI based networks.
 
>There is no mystery that both Chicago and Daytona will include a
>finished  version of the TCP/IP stack that's now in beta.
 
>Short term, I don't know if Chicago will include a fully compliant
>WinSock 2.0  DLL right out of the gate.  It would be an incredible feat
>if they could get  all that work done on time [Plus I have no idea
>where MS would get  something like an OSI stack !!!]

But why use OSI?  Why should MS spend resource to do this?  (Don't they 
have other things to do with their money?)

Although it seemed say 5 years ago that OSI would displace TCP/IP in the 
marketplace, in part due to US Government pressure (GOSIP), that 
displacement hasn't happened.  In fact, even in parts of Europe, TCP/IP 
is displacing OSI!

And, OSI still has the (silly, unnecessary) problem of the two 
incompatible transport stacks:  TP4/CLNS vs. TP0/X.25.  Plus, plus, 
plus.

Damn shame, though.  There are some good parts of OSI.  Too bad the 
purists didn't design the OSI applications to run on top of the TCP 
layer.

-- Phil Burton --    philip.burton@spacebbs.com
- Palo Alto, CA -
---
þ CMPQwk #1.4þ UNREGISTERED EVALUATION COPY

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 13:12:04 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2vfpuf$q03@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>In article <2vfarq$562@hpindda.cup.hp.com> raj@cup.hp.com writes:
>
>    I wonder which is more expensive in the new Cicso routers - receiving
>    six packets as opposed to one, or receiving one and having to
>    fragment it into six? (The ATM to Ethernet case)
>    
>Fragmenting.  I wasn't able to improve it THAT much.  ;-)
>
>Tony

A few years ago Network Systems' FDDI-Cray adapters achieved what at
the time was a very impressive TCP/IP/FDDI speed of about 32Mbit/sec by
using an IP MTU and TCP MSS much larger than 4352.  I think they like
something like 32KBytes.  As I understand it, the FDDI adapters fragment
and reassemble on the fly, so that the host only sees big IP datagrams.
Owners of Crays continue to pester my daytime employer, a high performance
workstation vendor, about using a giant TCP MSS over FDDI.

My point is that although when everything else is equal, IP fragments
are considered harmful, sometimes everything else is not equal.  What
turns out to be equal depends a lot on how you think about things.


Vernon Schryver    vjs@rhyolite.com

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 13:21:17 GMT
From:      cacciam@xsft5.ico.olivetti.com (Marco Caccia)
To:        comp.protocols.tcp-ip
Subject:   TCP extension for High Performance

I'm implementing the new tcp options explained in the RFC1323
"TCP Extensions for High Performance".

In the RFC is referenced the document:

		Jacobson V.,"Modified TCP congestion avoidance algorthm",
		Message to end2end-interest mailing list, April 1990.

Does anyone have any information about how to get this document ?

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 13:39:36 GMT
From:      cacciam@xsft5.ico.olivetti.com (0000-Admin(0000))
To:        comp.protocols.tcp-ip
Subject:   TCP extension for High Performance


I'm implementing the new tcp options explained in the RFC1323
"TCP Extensions for High Performance".
In the RFC is referenced the document:

		Jacobson V.,"Modified TCP congestion avoidance algorthm",
		Message to end2end-interest mailing list, April 1990.


Does anyone have any information about how to get this document ?

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 14:11:19 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP: How to transfer files via telnet?

>A friend of mine told me he was able to transfer a binary file during
>a telnet session (via an Amateur Radio TCP/IP connection to another
>Ham TCP/IP station).

	I do it the stupid way:

otter-> script
Script started, file is typescript
otter-> telnet sol
Trying 192.33.112.100 ...
Connected to sol.tis.com.
Escape character is '^]'.


SunOS UNIX (sol)

login: mjr
Password:
Last login: Wed Jul  6 11:16:03 from otter
OS/MP 4.1A.3 Export(SOL/root)#0: Wed May 12 14:57:21 1993

sol-> 
sol-> uuencode .profile .profile
begin 600 .profile
M(V)A<VEC<PI004=%4CTG+W5S<B]L;V-A;"]B:6XO;&5S<R<*141)5$]2/2<O
K='1E<B(@73L@=&AE;@H)97AE8R O=7-R+V)I;B]8,3$O<W1A<G1X"F9I"B)O
 
end
sol-> ^D
Connection closed by foreign host.
otter-> ^D
Script done, file is typescript
otter-> vi typescript
otter-> uudecode typescript
otter-> 


	the 'vi typescript' is where you edit the ^M off the lines.

mjr.

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 14:17:22 GMT
From:      tony@mpg.phys.hawaii.edu (Antonio Querubin)
To:        comp.protocols.tcp-ip
Subject:   router recommendations?

Need to connect two IP subnets separated by about two miles via either 
dedicated high-speed modems or a DDS line using DSU/CSUs.  The line will 
probably be upgraded to fiber in about two years.  What kind of routing 
equipment would I need to make the initial connection now and be upgradeable
to a fiber connection several years from now?  If the routers could handle
Banyan Vines packets also that would be a plus.

--
Antonio Querubin  
tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@hawaii.bitnet

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 14:20:12 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP extension for High Performance

> I'm implementing the new tcp options explained in the RFC1323
> "TCP Extensions for High Performance".

You might want to look at Thomas Skibo's code in the 4.4BSD-Lite
release.  You can get the source code release on CD-ROM from
O'Reilly for $40.  I also see that Bob Braden has made his diffs
for RFC 1323 for SunOS 4.1.x available on ftp.isi.edu in the file
pub/braden/rfc1323.shar.  You might want to go through those diffs.

Also, there was an Internet Draft update to RFC 1323 with a few
clarifications and changes, dated June 21, 1993 by Bob Braden.
Internet Drafts expire 6 months after their release, so this is
now expired, and I don't believe it's been published as an RFC
(yet).  Nevertheless, you should try and track down a copy.

> In the RFC is referenced the document:
>		Jacobson V.,"Modified TCP congestion avoidance algorthm",
>		Message to end2end-interest mailing list, April 1990.
> Does anyone have any information about how to get this document ?

This is Van's description of his fast retransmit, fast recovery
algorithms.  I've attached a copy (seems I repost this every 6
months or so).  You might also want to take a look at my recent
book "TCP/IP Illustrated" (Addison-Wesley, 1994) for some real
examples of these algorithms in action.  The code was implemented
in the BSD Net/1 release in 1989, so it should be in most systems
today.

	Rich Stevens

--------------------------------------------------------------------
From van@helios.ee.lbl.gov Mon Apr 30 01:44:05 1990
To: end2end-interest@ISI.EDU
Subject: modified TCP congestion avoidance algorithm
Date: Mon, 30 Apr 90 01:40:59 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>
Status: RO

This is a description of the modified TCP congestion avoidance
algorithm that I promised at the teleconference.

BTW, on re-reading, I noticed there were several errors in
Lixia's note besides the problem I noted at the teleconference.
I don't know whether that's because I mis-communicated the
algorithm at dinner (as I recall, I'd had some wine) or because
she's convinced that TCP is ultimately irrelevant :).  Either
way, you will probably be disappointed if you experiment with
what's in that note.

First, I should point out once again that there are two
completely independent window adjustment algorithms running in
the sender:  Slow-start is run when the pipe is empty (i.e.,
when first starting or re-starting after a timeout).  Its goal
is to get the "ack clock" started so packets will be metered
into the network at a reasonable rate.  The other algorithm,
congestion avoidance, is run any time *but* when (re-)starting
and is responsible for estimating the (dynamically varying)
pipesize.  You will cause yourself, or me, no end of confusion
if you lump these separate algorithms (as Lixia's message did).

The modifications described here are only to the congestion
avoidance algorithm, not to slow-start, and they are intended to
apply to large bandwidth-delay product paths (though they don't
do any harm on other paths).  Remember that with regular TCP (or
with slow-start/c-a TCP), throughput really starts to go to hell
when the probability of packet loss is on the order of the
bandwidth-delay product.  E.g., you might expect a 1% packet
loss rate to translate into a 1% lower throughput but for, say,
a TCP connection with a 100 packet b-d p. (= window), it results
in a 50-75% throughput loss.  To make TCP effective on fat
pipes, it would be nice if throughput degraded only as function
of loss probability rather than as the product of the loss
probabilty and the b-d p.  (Assuming, of course, that we can do
this without sacrificing congestion avoidance.)

These mods do two things: (1) prevent the pipe from going empty
after a loss (if the pipe doesn't go empty, you won't have to
waste round-trip times re-filling it) and (2) correctly account
for the amount of data actually in the pipe (since that's what
congestion avoidance is supposed to be estimating and adapting to).

For (1), remember that we use a packet loss as a signal that the
pipe is overfull (congested) and that packet loss can be
detected one of two different ways:  (a) via a retransmit
timeout or (b) when some small number (3-4) of consecutive
duplicate acks has been received (the "fast retransmit"
algorithm).  In case (a), the pipe is guaranteed to be empty so
we must slow-start.  In case (b), if the duplicate ack
threshhold is small compared to the bandwidth-delay product, we
will detect the loss with the pipe almost full.  I.e., given a
threshhold of 3 packets and an LBL-MIT bandwidth-delay of around
24KB or 16 packets (assuming 1500 byte MTUs), the pipe is 75%
full when fast-retransmit detects a loss (actually, until
gateways start doing some sort of congestion control, the pipe
is overfull when the loss is detected so *at least* 75% of the
packets needed for ack clocking are in transit when
fast-retransmit happens).  Since the pipe is full, there's no
need to slow-start after a fast-retransmit.

For (2), consider what a duplicate ack means:  either the
network duplicated a packet (i.e., the NSFNet braindead IBM
token ring adapters) or the receiver got an out-of-order packet.
The usual cause of out-of-order packets at the receiver is a
missing packet.  I.e., if there are W packets in transit and one
is dropped, the receiver will get W-1 out-of-order and
(4.3-tahoe TCP will) generate W-1 duplicate acks.  If the
`consecutive duplicates' threshhold is set high enough, we can
reasonably assume that duplicate acks mean dropped packets.

But there's more information in the ack:  The receiver can only
generate one in response to a packet arrival.  I.e., a duplicate
ack means that a packet has left the network (it is now cached
at the receiver).  If the sender is limitted by the congestion
window, a packet can now be sent.  (The congestion window is a
count of how many packets will fit in the pipe.  The ack says a
packet has left the pipe so a new one can be added to take its
place.)  To put this another way, say the current congestion
window is C (i.e, C packets will fit in the pipe) and D
duplicate acks have been received.  Then only C-D packets are
actually in the pipe and the sender wants to use a window of C+D
packets to fill the pipe to its estimated capacity (C+D sent -
D received = C in pipe).

So, conceptually, the slow-start/cong.avoid/fast-rexmit changes
are:

  - The sender's input routine is changed to set `cwnd' to `ssthresh'
    when the dup ack threshhold is reached.  [It used to set cwnd to
    mss to force a slow-start.]  Everything else stays the same.

  - The sender's output routine is changed to use an effective window
    of min(snd_wnd, cwnd + dupacks*mss)  [the change is the addition
    of the `dupacks*mss' term.]  `Dupacks' is zero until the rexmit
    threshhold is reached and zero except when receiving a sequence
    of duplicate acks.

The actual implementation is slightly different than the above
because I wanted to avoid the multiply in the output routine
(multiplies are expensive on some risc machines).  A diff of the
old and new fastrexmit code is attached (your line numbers will
vary).

Note that we still do congestion avoidance (i.e., the window is
reduced by 50% when we detect the packet loss).  But, as long as
the receiver's offered window is large enough (it needs to be at
most twice the bandwidth-delay product), we continue sending
packets (at exactly half the rate we were sending before the
loss) even after the loss is detected so the pipe stays full at
exactly the level we want and a slow-start isn't necessary.

Some algebra might make this last clear:  Say U is the sequence
number of the first un-acked packet and we are using a window
size of W when packet U is dropped.  Packets [U..U+W) are in
transit.  When the loss is detected, we send packet U and pull
the window back to W/2.  But in the round-trip time it takes
the U retransmit to fill the receiver's hole and an ack to get
back, W-1 dup acks will arrive (one for each packet in transit).
The window is effectively inflated by one packet for each of
these acks so packets [U..U+W/2+W-1) are sent.  But we don't
re-send packets unless we know they've been lost so the amount
actually sent between the loss detection and the recovery ack is
U+W/2+W-1 - U+W = W/2-1 which is exactly the amount congestion
avoidance allows us to send (if we add in the rexmit of U).  The
recovery ack is for packet U+W so when the effective window is
pulled back from W/2+W-1 to W/2 (which happens because the
recovery ack is `new' and sets dupack to zero), we are allowed
to send up to packet U+W+W/2 which is exactly the first packet
we haven't yet sent.  (I.e., there is no sudden burst of packets
as the `hole' is filled.)  Also, when sending packets between
the loss detection and the recovery ack, we do nothing for the
first W/2 dup acks (because they only allow us to send packets
we've already sent) and the bottleneck gateway is given W/2
packet times to clean out its backlog.  Thus when we start
sending our W/2-1 new packets, the bottleneck queue is as empty
as it can be.

[I don't know if you can get the flavor of what happens from
this description -- it's hard to see without a picture.  But I
was delighted by how beautifully it worked -- it was like
watching the innards of an engine when all the separate motions
of crank, pistons and valves suddenly fit together and
everything appears in exactly the right place at just the right
time.]

Also note that this algorithm interoperates with old tcp's:  Most
pre-tahoe tcp's don't generate the dup acks on out-of-order packets.
If we don't get the dup acks, fast retransmit never fires and the
window is never inflated so everything happens in the old way (via
timeouts).  Everything works just as it did without the new algorithm
(and just as slow).

If you want to simulate this, the intended environment is:

    - large bandwidth-delay product (say 20 or more packets)

    - receiver advertising window of two b-d p (or, equivalently,
      advertised window of the unloaded b-d p but two or more
      connections simultaneously sharing the path).

    - average loss rate (from congestion or other source) less than
      one lost packet per round-trip-time per active connection.
      (The algorithm works at higher loss rate but the TCP selective
      ack option has to be implemented otherwise the pipe will go empty
      waiting to fill the second hole and throughput will once again
      degrade at the product of the loss rate and b-d p.  With selective
      ack, throughput is insensitive to b-d p at any loss rate.)

And, of course, we should always remember that good engineering
practise suggests a b-d p worth of buffer at each bottleneck --
less buffer and your simulation will exhibit the interesting
pathologies of a poorly engineered network but will probably
tell you little about the workings of the algorithm (unless the
algorithm misbehaves badly under these conditions but my
simulations and measurements say that it doesn't).  In these
days of $100/megabyte memory, I dearly hope that this particular
example of bad engineering is of historical interest only.

 - Van

-----------------
*** /tmp/,RCSt1a26717	Mon Apr 30 01:35:17 1990
--- tcp_input.c	Mon Apr 30 01:33:30 1990
***************
*** 834,850 ****
  				 * Kludge snd_nxt & the congestion
  				 * window so we send only this one
! 				 * packet.  If this packet fills the
! 				 * only hole in the receiver's seq.
! 				 * space, the next real ack will fully
! 				 * open our window.  This means we
! 				 * have to do the usual slow-start to
! 				 * not overwhelm an intermediate gateway
! 				 * with a burst of packets.  Leave
! 				 * here with the congestion window set
! 				 * to allow 2 packets on the next real
! 				 * ack and the exp-to-linear thresh
! 				 * set for half the current window
! 				 * size (since we know we're losing at
! 				 * the current window size).
  				 */
  				if (tp->t_timer[TCPT_REXMT] == 0 ||
--- 834,850 ----
  				 * Kludge snd_nxt & the congestion
  				 * window so we send only this one
! 				 * packet.
! 				 *
! 				 * We know we're losing at the current
! 				 * window size so do congestion avoidance
! 				 * (set ssthresh to half the current window
! 				 * and pull our congestion window back to
! 				 * the new ssthresh).
! 				 *
! 				 * Dup acks mean that packets have left the
! 				 * network (they're now cached at the receiver) 
! 				 * so bump cwnd by the amount in the receiver
! 				 * to keep a constant cwnd packets in the
! 				 * network.
  				 */
  				if (tp->t_timer[TCPT_REXMT] == 0 ||
***************
*** 853,864 ****
  				else if (++tp->t_dupacks == tcprexmtthresh) {
  					tcp_seq onxt = tp->snd_nxt;
! 					u_int win =
! 					    MIN(tp->snd_wnd, tp->snd_cwnd) / 2 /
! 						tp->t_maxseg;
  
  					if (win < 2)
  						win = 2;
  					tp->snd_ssthresh = win * tp->t_maxseg;
- 
  					tp->t_timer[TCPT_REXMT] = 0;
  					tp->t_rtt = 0;
--- 853,864 ----
  				else if (++tp->t_dupacks == tcprexmtthresh) {
  					tcp_seq onxt = tp->snd_nxt;
! 					u_int win = MIN(tp->snd_wnd,
! 							tp->snd_cwnd);
  
+ 					win /= tp->t_maxseg;
+ 					win >>= 1;
  					if (win < 2)
  						win = 2;
  					tp->snd_ssthresh = win * tp->t_maxseg;
  					tp->t_timer[TCPT_REXMT] = 0;
  					tp->t_rtt = 0;
***************
*** 866,873 ****
  					tp->snd_cwnd = tp->t_maxseg;
  					(void) tcp_output(tp);
! 
  					if (SEQ_GT(onxt, tp->snd_nxt))
  						tp->snd_nxt = onxt;
  					goto drop;
  				}
  			} else
--- 866,879 ----
  					tp->snd_cwnd = tp->t_maxseg;
  					(void) tcp_output(tp);
! 					tp->snd_cwnd = tp->snd_ssthresh +
! 						       tp->t_maxseg *
! 						       tp->t_dupacks;
  					if (SEQ_GT(onxt, tp->snd_nxt))
  						tp->snd_nxt = onxt;
  					goto drop;
+ 				} else if (tp->t_dupacks > tcprexmtthresh) {
+ 					tp->snd_cwnd += tp->t_maxseg;
+ 					(void) tcp_output(tp);
+ 					goto drop;
  				}
  			} else
***************
*** 874,877 ****
--- 880,890 ----
  				tp->t_dupacks = 0;
  			break;
+ 		}
+ 		if (tp->t_dupacks) {
+ 			/*
+ 			 * the congestion window was inflated to account for
+ 			 * the other side's cached packets - retract it.
+ 			 */
+ 			tp->snd_cwnd = tp->snd_ssthresh;
  		}
  		tp->t_dupacks = 0;
*** /tmp/,RCSt1a26725	Mon Apr 30 01:35:23 1990
--- tcp_timer.c	Mon Apr 30 00:36:29 1990
***************
*** 223,226 ****
--- 223,227 ----
  		tp->snd_cwnd = tp->t_maxseg;
  		tp->snd_ssthresh = win * tp->t_maxseg;
+ 		tp->t_dupacks = 0;
  		}
  		(void) tcp_output(tp);

From van@helios.ee.lbl.gov Mon Apr 30 10:37:36 1990
To: end2end-interest@ISI.EDU
Subject: modified TCP congestion avoidance algorithm (correction)
Date: Mon, 30 Apr 90 10:36:12 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>
Status: RO

I shouldn't make last minute 'fixes'.  The code I sent out last
night had a small error:

*** t.c	Mon Apr 30 10:28:52 1990
--- tcp_input.c	Mon Apr 30 10:30:41 1990
***************
*** 885,893 ****
  			 * the congestion window was inflated to account for
  			 * the other side's cached packets - retract it.
  			 */
! 			tp->snd_cwnd = tp->snd_ssthresh;
  		}
- 		tp->t_dupacks = 0;
  		if (SEQ_GT(ti->ti_ack, tp->snd_max)) {
  			tcpstat.tcps_rcvacktoomuch++;
  			goto dropafterack;
--- 885,894 ----
  			 * the congestion window was inflated to account for
  			 * the other side's cached packets - retract it.
  			 */
! 			if (tp->snd_cwnd > tp->snd_ssthresh)
! 				tp->snd_cwnd = tp->snd_ssthresh;
! 			tp->t_dupacks = 0;
  		}
  		if (SEQ_GT(ti->ti_ack, tp->snd_max)) {
  			tcpstat.tcps_rcvacktoomuch++;
  			goto dropafterack;



-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 14:47:45 GMT
From:      grpjl@iastate.edu (Paul J Lustgraaf)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2vfarq$562@hpindda.cup.hp.com>, Rick Jones <raj@cup.hp.com> wrote:
...lots deleted...
>
>When you say that a router's load is more nearly proportional to
>packets/second than bits/second, doesn't that imply that it would be
>less "loadful" on the router to send it two larger fragments on the
>FDDI ring rather than six smaller fragments? The first case would seem
>to place 1/3 the load on the router.
>

Except for the fact that some routers do fragmentation with the main CPU
and forwarding with auxiliary processors.  Cisco, for example, does this.

...lots deleted...
>
>But it was just said that the load on a router is proportional to the
>number of packets, and PathMTU has already been shown to *increase*
>the number of packets (in one very common case anyhow) that a (first
>hop) router will be sent when the packet has to be fragmented in the
>first place.
>
>It would definitely increase the number of packets when that router is
>routing NFS V2 from ATM to Ethernet or FDDI because the datagram can
>arrive unfragmented, in *one* packet on the ATM interface as opposed
>to six.
>
>I wonder which is more expensive in the new Cicso routers - receiving
>six packets as opposed to one, or receiving one and having to
>fragment it into six? (The ATM to Ethernet case)
>
>Running NFS over TCP would have the same effect then of increasing the
>load on the router because it increases the number of packets it
>processes (both pseudo fragmentation *and* ACK's I'd imagine ;-)
>However, I can agree on advantages in running NFS over TCP in a WAN
>case that would outweigh that.
>
>Lest anyone think that I am trying to ferment revolution and start
>flooding the Internet with IP fragments, as much as what I've been
>saying has been to challenge assumptions to ascertain their validity.
>Particularly the one that says that IP Fragmentation is "expensive"
>(an unfortunately vague term) I know that I've learned some things
>from it (such as the now improved IP fragmenting ability of new Cisco
>routers), and I hope that others have too.

To illustrate the problem:
NFS throughput from an Alpha 3000/600 to an Alpha 3000/300:

On same ethernet:                                        1,032 KBps
From ethernet through 2 routers across
an FDDI ring and to another ethernet:                      661

FDDI through Cisco 7000 to ethernet:                       501

FDDI through Cisco AGS+ to ethernet:                       361

FDDI through Cisco 7000 to ethernet w/1024 byte mount:     305

FDDI through Cisco 7000 to ethernet w/1500 byte mount:     187

FDDI through Cisco Catalyst switch to ethernet:          1,004

Conclusions:

   1. Cisco routers don't fragment very fast.

   2. Hosts have no problem fragmenting fast.

   3. NFS mounts smaller than 8K cost more than fragmentation.

   4. Other devices CAN fragment fast.

Recommendations:

   Ask YOUR vendor how fast their router fragments!


>
>rick jones
>speaking only as rick jones...
>
>I've always liked the phrase "Don't raise the bridge, lower the
>river!"
>
After last summers flooding, most Iowans would agree with you!

-- 
Paul Lustgraaf             "It's easier to apologize than to get permission."
Network Specialist                                      Grace Hopper
Iowa State University Computation Center                    grpjl@iastate.edu
Ames, IA  50011                                                  515-294-0324

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 15:02:50 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: slip--must be 2 nets

In article <2vh2oe$gr1@kryten.atinc.com>, jmb@kryten.atinc.com (Jonathan M. Bresler x346) writes:
|> i have just installed a terminal server with slip capabilities.  
|> the vendor chase iolan informs me that the two endpoints of the slip
|> connection must be either on different networks or on different subnets
|> of a single network.
|> 
|> i checked the rfc1055 and did not find this addressed.  
|> 
|> or is the limitation of different nets/subnets, a routing limitation?

Sort of.  This is an IP routing limitation -- you can't have
discontiguous subnets.

Most terminal servers can also hack around this problem if the other end
is a single node.  The server can do a proxy-ARP for the remote end-
point's address if it's on the same subnet as the server.

But, if you have more than one node at the remote end, you'll be forced
to use separate nets (or at least a separate unrouted network) for them.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 15:04:23 GMT
From:      scollins@da_vinci.mtt.it.uswc.uswest.com (Steven Collins)
To:        comp.object,comp.protocols.tcp-ip,comp.lang.c++
Subject:   Wanted: Object Oriented distributed communication toolkit


 Looking for an Object Oriented distributed communication toolkit
with a C++ interface.  CORBA implementations are too heavyweight.
I'm interested in something that is much much easier to use than 
BSD sockets and XDR.
Would "like" the product to run on different UNIX flavors plus MAC/PC.

I will post a follow-up article detailing replies.

Thanks, Steve
-- 

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 15:16:57 GMT
From:      crohrer@advtech.uswest.com (Chris Rohrer)
To:        comp.protocols.tcp-ip
Subject:   Fake network addresses


Hi all,

I was of the understanding that there is a Class A or maybe a Class B
address that is reserved and not allocated to anyone on the Internet,
The purpose is to alllow private networks that do not/can not/will not
connect directly to the Internet the opportunity to have an address space
that will not conflict with or confuse anyone's routing tables.

Anyone know any more about this and, like, what the number(s) might be?

Thanks

Chris Rohrer

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 15:24:07 GMT
From:      dstoun@garnet.acns.fsu.edu (Douglas Stoun)
To:        comp.protocols.tcp-ip
Subject:   Different speeds using WFTPD!!!???

We are testing the shareware version of WFTPD as an ftp server (since
WinQvt is so unstable) and for the most part we are pleased with the
results and plan on registering.  However, we are having inconsistencies
in speed between the computers.

We have 10 Gateways (9 486DX/33 and 1 486DX2/66V).  We also have 3 Dells
(486DX/33).  All 13 computers have 8 megs of RAM and are connected using
winsock, 8003pkdr, and winpkt.

The problem is that MOST of the computers will have a transfer rate of
60-100 Kbytes/second while some of them transfer at only 2-3 
Kbytes/second !!!!!  There is no difference between setups (from what we
can see), in fact, all of the network information was put on the 
computers by way of tape backup!  

Another interesting aspect is that it only effects 'get'.  'put' seems to
work at the fast rate no matter which computer is putting to which.  
Also, when using ws_ftp, the 'get' from a computer whose rate is slow, 
does not bring up the progress bar that moves to the right during most 
transfers.  But the 'get' from machines with fast transfer rates, does!?

Well, any help would be appreciated..send email to the address below.

Doug Stoun
stoun_d@cmr.fsu.edu
Center for Music Research
Florida State University

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 17:24:59 GMT
From:      wali@gate.net (Tom Techoueyres)
To:        comp.protocols.tcp-ip
Subject:   IP address selection

Hi,

My company is getting a 56K dedicated connection to Internet, I got already 
 the IP address that my service provider gave me. It is a class C. this 
means that the last octet of the IP address is for our company, which gives
us 254 addresses. the primary server is a MicroVax running VMS, is there
a logical way to assign an address to the primary server? The first three
octet are control by the service provider, the last octet by the company, 
but should it be 1, 37 or 250? I don't know what value I should assign 
to the primary server?
I would appreciate any help, thank you!

tom
wali@gate.net


-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 18:36:45 GMT
From:      morley@suncad.camosun.bc.ca (Mark Morley)
To:        comp.protocols.tcp-ip
Subject:   Help on subnetting a class 'C'

Actually, our "class C" is a subnet of a class B network.  What I want to
do is divide our range of addresses across two physical locations with a
SLIP or PPP connection between them.  On the one site we'll have only a
handful of machines.  At the other a lab of 15-20 PC's.

The thing I'm not familiar with is how to divide our address range into 2
subnets.  Can anyone offer some advice on this?  Is it as easy as simply
changing the netmask?  I doubt it...

Mark

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 20:13:41 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Keep Alives

In article <773409903snz@paxdata.demon.co.uk> Giles@paxdata.demon.co.uk writes:
>I am trying to work out how to handle TCP Keep Alives in my company's ISDN
>bridging products.  RFC1122 states that Keep Alives MUST be defaulted to
>off, be sent at configurable intervals and default to no less than every
>two hours.

RFC-1122 deals with the communications layers. Its recommendations for
defaults therefore apply only to the TCP implementation. Not that that
matters much, since many, many TCP implementations have much shorter
defaults than those suggested by RFC-1122.

>Imagine my surprise when I found that NCSA Telnet's FTP client sends what
>appears to be a Keep Alive at three minute intervals!

Although one cannot say with this information what is really going on,
it is possible that the FTP client implementation has overridden TCP's
default values to get a shorter keep-alive. I have no idea why anyone
would want an FTP *client* to use a short keep-alive -- or any
keep-alive at all for that matter -- but since RFC-1122 doesn't apply
and RFC-1123 (which involves the application layers) doesn't discuss
keep-alives, this behavior is within specs.

>Does this mean that I need to "spoof" the Keep Alive (just like an
>IPX/NCP Keep Alive) so as to keep ISDN bills manageable?

Either that or you assume that a TCP connection that's actively
sending keep-alives is likely to come into use at any time so it's
worth keeping the connection up.  This isn't entirely unreasonable
since TCP connections are a little different than NCP connections. A
TCP connection is an actual invocation of a specific service, while a
NCP connection is just authentication conduit not necessarily
reflecting an actual desire for any particular service at any given
time.  Unfortunately, specific cases will likely make this general
observation moot. A statistical argument will not help you molify the
customer that left an FTP connection open for two weeks while he was
on vacation.

Or you could say that anyone using an application that sends this many
keep-alives deserves what he gets...

I find it somewhat amusing that by spoofing TCP keep-alives, you're
making them useless. I hope people that put so much faith in
keep-alives and consider them so important will take heed of your
actions.

						don provan
						donp@novell.com

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 20:32:44 GMT
From:      Debby Koren <deb@radmail.rad.co.il>
To:        comp.protocols.tcp-ip
Subject:   addresses on SLIP or PPP links


I'm trying to gather information on the ways that access servers or access
routers (like Netblazer and Nethopper, for example) assign IP addresses to the
SLIP or PPP interfaces.  Suppose such a device has several SLIP or PPP
interfaces and a host connected (possibly through dial-up or temporary
connection) to each one.  Is each link considered a separate subnet?  Which
products don't require addresses on the link?  How do they do this?  Which
products support DHCP?


-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 20:42:26 GMT
From:      li@virtual12.harvard.edu (W. David Li)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   INFOR NEEDED: NOS PROGRAMMING


Hi, 

I am doing some networking programming(TCP/IP) using NOS -- Network Operating
System by Phil Karn. The trouble is that I could not find any
programming guide or manual to help me through this. Do I really have
to go through all those source code? Can anyone tell me a bit on where
to find the information? I am familiar with the Unix networking
programming but not sure how large the difference is between NOS and
UNIX.

Please reply to my account. Thanks

David


-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 21:12:33 GMT
From:      zhou@isis.epm.ornl.gov
To:        comp.protocols.tcp-ip,comp.client-server,comp.unix.internals
Subject:   Data formats needed for non-XDR conversion

I would like to know if you could give me some pointers on where can I
find all (or some of) the data formats for all machine types. Instead of
using XDR converting routines to convert the data formats used by 
different processors, I am trying to code my own routines to do such
conversions due to performance reasons.  

I heard that OSF' DCE doesn't use XDR routines too. Any comments on this?

Thanks a lot in advance.

Honbo
Honbo Zhou (Ph. D.),   (615) 481-8354 (H), 576-6129 (O)
Engineerin, Physics, and Mathematics Division  ---- PVM
Oak Ridge National Laboratory, Oak Ridge, TN 37831-6367
          http://www.epm.ornl.gov/~zhou

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 21:14:51 GMT
From:      mike_gore@ccm.hf.intel.com
To:        misc.jobs.offered,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   SR NETWORK INFASTRUCTURE ENGINEER @ INTEL IN OREGON


Intels Information Technology Group in Oregon is looking for an individual to 
implement and support new networking technology for HW/SW Engineering, 
Manufacturing, Administration and Product Research. You initial focus will be 
support of site domain name system (DNS) servers and conversion of hosts to the 
different sites in oregon domain.. Will maintain Perl scripts to automate the 
generation of DNS records and correlation of other network databases. Qualified 
candidates will posses experience in Unix systems administration with a focus 
on networking. Sun OS & ATT SYSV.4 needed along with PERL. In addition you 
should have experience in support of PC DOS/Windows TCP/IP. This position is 
located outside of Portland Oregon and offers an excellent salary, bonus, stock 
options and relocation package. If you are interested EMAIL an ASCII resume OR 
Call Mike @ 602-554-4485

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1994 13:05:21 -0700
From:      nsi@teleport.com (Northwest Software)
To:        comp.protocols.tcp-ip
Subject:   Help, we need a TCP/IP SWQA Contractor

We're looking for a TCP/IP SWQA Contractor for a Client Project in
Portland, OR.  Job desc. contact info below.

Thanks

**********************************************************************
Mike Nelson                     Consulting and Recruiting
Sales Engineer                  Software & Hardware Engineers
Northwest Software, Inc.        Technical Writers
P.O. Box 91396                  Portland, Oregon & other locations
Portland, OR 97291-0396
nsi@teleport.com                My favorite quote from a job seeker:
FAX:   (503) 645-5892           "I'm still looking for a job that pays
                                me to drink beer and chase women."
**********************************************************************


	***********************************
	*  SWQA Engineer, TCP/IP          *
	***********************************

DESCRIPTION:

5-7 months, Portland, Oregon (on-site); Develop SW tests for network
software used to interface PC/MAC perhipheral equipment.  SW Technicians
will assist conducting the tests.  Further project details will be
disclosed to qualified applicants.

REQUIRED:

Min 5 years industry experience, 1 year of formal SWQA experience, 2
years with TCP/IP network protocols, BSCS or equivalent.

DESIRED:

DOS, MSW, Macintosh, other LAN/WAN protocols, "sniffer" debug tool

INTERESTED ?  RESPOND IN STRICT CONFIDENCE TO:

		Northwest Software, Inc.
		P.O. Box 91396
		Portland, OR 97291-0396
		FAX: 503-645-5892
		Email: nsi@teleport.com

BELOW YOU WILL FIND:

A. General Notes about NSI's openings
B. A message for recent college grads
C. Information about NSI
D. Information about the Pacific Northwest

GENERAL NOTES ABOUT OUR OPENINGS:

1. If convenient, NSI prefers emailed resumes -ASCII only.  Your resume
will be added to our on-line resumes, which gives you greater exposure
within NSI.  It is desirable to follow up with a postal mailed d
resume so we have a "pretty" copy on file.

2. We will not forward your resume to any Client without your specific
permission.  After we review your resume we will call or send email back
disclosing who our Client is and asking your specific permission to
represent you.

3. Double representation is a situation we avoid.  Once you have given
NSI permission to represent you with a specific Client DO NOT have other
Companies represent you to this same Client without first obtaining
permission from NSI.  In general representation expires after about 3
months, you do not need NSI's permission to be represented by someone
else if it has been > 3 months.

4. Some of our Clients can be slow giving us feedback.  Once you have
given NSI permission to represent you **feel free** to check back with
us in 2 weeks if you haven't heard anything.

5. Unless otherwise stated in the posting, ALL JOBS must be done at our
Client site.

6. Openings for "regular" employment with our Clients require that you
are a USA Citizen or Permanant Resident.

7. For temporary positions NSI will sponsor visas if necessary.

8. If you are not a good match for the position you have applied for we
will keep your resume on file to consider for future openings.  However,
feel free to apply again as you see new jobs posted.

MESSAGE TO NEW COLLEGE GRADUATES:

If you are a new college graduate, you should be aware that our clients
pay our fees and usually expect us to recruit experienced professionals
and/or consultants.  Therefore, we'd like to suggest that you either
contact your college placement center, or college recruiters at the
employers' directly.  Most large companies have a program to recruit new
college graduates like yourself.

ABOUT NORTHWEST SOFTWARE, INC.:

Northwest Software, Inc. (NSI) provides Consulting Services 
to top-rated high technology companies across the United States.  
NSI has offices in Portland Oregon and India.

NSI's services include temporary positions and regular employment.  We
fill jobs for Software Engineers, Hardware Engineers, Technical Writers,
Programmer/Analysts, Management, and Marketing positions.  Most of our
temporary positions pay by the hour.  Occasionally NSI bids on fixed
price projects.

ABOUT THE PACIFIC NORTHWEST:

The majority of our openings are in the Portland/Vancouver area.  The
Oregon Coast and mountain Skiiing areas are about 60 miles away.  Many
outdoor people take advantage of the convenient camping, hunting, and
fishing spots.  The Portland area has a population of about 1,000,000
and includes a variety of suburbs with a high quality of living.  The
cost of living is about 20% less than California.  Oregon does not have
a sales tax, but does have a 9% State income tax.  Washington has a
sales tax, but no State income tax.
-- 
nsi@teleport.COM  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at (503) 220-1016 (2400-14400, N81)

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1994 09:46:16 -0400
From:      jmb@kryten.atinc.com (Jonathan M. Bresler x346)
To:        comp.protocols.tcp-ip
Subject:   subnetting

having just read rfc950 again, i understand the following to apply
to subnetting.

1.	the "all subnet bits 0" subnet should not be used as a physical
	network.
2.	the "all subnet bits 1" subnet should not be used as a physical
	network.
3.	no host should be "all host bits 0"
4.	and no host at "all host bits 1"


so....

#subnet bits	#of subnets	#of hosts	#lost addresses
						due to subnetting

1		0		 0 * 126	all = 254
2		2		 2 *  62	2 * 62 +  2 * 2 = 128
3		6		 6 *  30	2 * 30 +  6 * 2 = 72 
4		14		14 * 14		2 * 14 + 14 * 2 = 56
etc

is this correct?

jmb
-- 
Jonathan M. Bresler  jmb@kryten.atinc.com	| Analysis & Technology, Inc.  
						| 2341 Jeff Davis Hwy
play go.					| Arlington, VA 22202
ride bike. hack FreeBSD.--ah the good life	| 703-418-2800 x346

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 09:15:21
From:      karl@cavebear.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Small and Compact TCP/IP/PPP

In article <48575@mindlink.bc.ca> Robert_Bradford@mindlink.bc.ca (Robert Bradford) writes:
>From: Robert_Bradford@mindlink.bc.ca (Robert Bradford)
 
>How small and compact, in terms of memory requirements, can you
>make a TCP/IP and PPP implementation?

Geoff Cooper wrote a TinyTCP package to bootload the Imagen laser printers.  
And it was pretty small.

There's a lot you can do to shrink the code to tiny proportions if you start 
removing the generalizations.  For example, I just came across a TCP/IP 
implementation that knew nothing about being an arp client, subnet masks or 
routes, it simply sent everything to the ethernet address of a device which it 
had been configured to use as a "router".   The original PC/IP code ignorred 
offered windows on the basis that it was carrying telnet traffic, and no human 
could type fast enough to fill a window.

Of course, such a diminished piece of code should be used only in constrained 
circumstances.  Any attempt to use it in general practice is pretty much 
doomed.

I've lost track of both Geoff and the software.

               --karl--

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1994 11:29:04 -0400
From:      mossburg@aol.com (MOSSBURG)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting to Internet

In article <9407062222.AA27444@futon.sfsu.edu>, sulistio@futon.sfsu.edu
(Sulistio Muljadi) writes:
>I am trying to set up Internet conection (full IP) for my company.
>It will be on 56kbps leased line.  I am trying to figure out what kind
>of hardware needed to set the connection. 

I would like the same info but for novell 3.12 server.

Matthew Mossburg
mossburg@aol.com

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1994 15:00:55 -0600
From:      wllarso@sandia.gov (William L. Larson)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Obtaining Ethernet/MAC Network Addresses From Sun System

I am interested in identifying the Ethernet/MAC address for the network
interfaces on a Sun computer running 4.1.3.  My situation is that I
have three Ethernet interfaces plus one FDDI interface, but Sun only
reports a single MAC address for the system which is for the first
Ethernet interface.  All other network interfaces report the same MAC
address.

Is anyone aware of any mechanism for obtaining the Ethernet addresses
for the second and third Ethernet interfaces along with the MAC address
for the FDDI interface?

Responses via Email are most appreciated.  Thanks

Bill Larson  (wllarso@sandia.gov)	Phone: (505)844-2103
Sandia National Laboratories		  FAX: (505)844-2067
Org. 13918 M/S 0806
PO Box 5800
Albuquerque NM 87185

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 05:04:52 GMT
From:      jamesd@netcom.com (James A. Donald)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Windows screws up as server?

I have heard that windows does not work well as an internet
server, and in consequence you are likely to lose mail.

Allegedly if another computer contacts your computer to
deliver mail while your computer is busy, your computer
will screw up and and may lose the mail.

Is this a problem, is it only a problem with particular
implementations, or is it an inherent problem because
windows is non pre-emptive?


-- 
 ---------------------------------------------------------------------
We have the right to defend ourselves and our
property, because of the kind of animals that we              James A. Donald
are.  True law derives from this right, not from
the arbitrary power of the omnipotent state.                jamesd@netcom.com


-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 05:26:41 GMT
From:      micky@ejv.com (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   ttcp_fwd-like program available?


For those of you who don't know ttcp_fwd is a general purpose program
for reading in data over one port and forwarding it to another port.
Both tcp and udp are supported and connections are duplex.  Anyway,
enough of an advertisement for ttcp_fwd...

I am looking for a program that can take a socket connection as
input and fan it out to several other ports.  Does such an animal
exist yet?  If you know of any, I would appreciate any pointers
that you may be able to provide.

I know that this sounds like multicast and I have been looking into
using the MBONE software to achieve the same results, but I am
worrysome about having to make system level changes as well as
having to create special MBONE routers to go across LANs.  Basically,
I would be really happy with a 'user-level' multicast ability...

In any case, any guidance would be greatly appreciated.  Please try
to reply by email as I have a difficult time keeping up with netnews ;-)

Micky Liu
micky@ejv.com

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 05:29:51 GMT
From:      micky@ejv.com (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   Current Status of CMP and TMux?


I've just retrieved the minutes for the last IETF BOF meeting on
tcp connection multiplexing and it is from last year (early 1993).
I am wondering if there was any further work done on either the
CMP (Connection Multiplexing Protocol) or on TMux.  Any pointers
would be greatly appreciated.

Micky Liu
micky@ejv.com

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1994 12:45:56 -0400
From:      jonbeal@saturn.caps.maine.edu (Jon Beal)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Does a DHCP daemon exist?


I am looking for a daemon for the Dynamic Host Configuration Protocol, as 
detailed in RFC1541.  Does anyone know if a Unix implementation exists 
yet?  (If so, where can I find it?)


Thanks in advance,

Jon Beal


-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Fri,  8 Jul 1994 14:43:23 -0500
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: where can I get the interSLIP for MAC?

messina@mcs.com (David Messina) writes:
> It's free, and available on many archives (info-mac, e.g.) 

The canonical source is ftp.intercon.com, in the directory /InterCon/sales.
It's also available on ftp.tidbits.com, but it's *not* generally available
on random archive sites.  If it's on info-mac, it should be taken off of it.
Putting InterSLIP up for FTP on any server requires explicit permission of
InterCon Systems Corporation.  InterSLIP may be free of charge, but it still 
copyrighted commercial software.


Amanda Walker
InterCon Systems Corporation









-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 06:23:32 GMT
From:      boyd@ssmd.mrl.dsto.gov.au (Steve Boyd)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp
Subject:   Re: where can I get the interSLIP for MAC?

In article <ZHAO.94Jul6121917@crl.crl.nmsu.edu> zhao@crl.nmsu.edu (Z. Zhao) writes:
>From: zhao@crl.nmsu.edu (Z. Zhao)
>Subject: where can I get the interSLIP for MAC?
>Date: 6 Jul 94 12:19:17
 
>Can anybody here tell me where the interSLIP for MAC is hidden ?
>Is it a freeware or shareware or commercial package?

It's freeware. You can download it from InterConn Systems at ftp.intercon.com. 
Sorry but I don't know the directory(s).


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Steve Boyd  email:boyd@ssmd.mrl.dsto.gov.au                   
 voice: +61 3 626 8305    Fax: +61 3 626 8999      __  |\     
                                                  /  |_| \
 D E P A R T M E N T   O F   D E F E N C E      .'        \   
 --------------------*--------------------     /           \  
 DEFENCE SCIENCE & TECHNOLOGY ORGANISATION     \     __    /  
Aeronautical & Maritime Research Laboratory     \_.-'  \_*/
    Ship Structures & Materials Division                 v    
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All opinions expressed here are mine.

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 94 06:24:56 GMT
From:      jonesjg@dg-rtp.dg.com (Greg Jones)
To:        comp.protocols.tcp-ip
Cc:        bji+@cs.cmu.edu
Subject:   Re: Getting Remote Host Address Before Accept()

In article <773532931.5620.0@unix9.andrew.cmu.edu> "Bryan J. Ischo" <bi04+@andrew.cmu.edu> writes:
> 
> This is more of a UNIX question than tcp-ip, but ... does anyone know how to
> get the address of the next remote host on the listener queue BEFORE calling
> accept()?  Basically, I want to know who is trying to connect so I know
> whether or not to accept the connection.  I could accept the connection,
> the check the remote address in the struct sockaddr filled in by accept(),
> then disconnect the remote host is not on my access list ... but as far as I
> know, the connect() call on the other end would succeed, and I don't want that.
> 

Actually the client connect will complete reguardless of when you accept the
connection.  Since the server is listening on the socket the connection
request is queued on the servers socket.  The accept creates a new
socket for connection, but the TCP handshake has already completed, before
the server calls accept().

Common practice is as you suggest - accept(), getpeername(), 
and disconnect if you so desire.

> Bryan
> bji+@cs.cmu.edu (preferred), bi04+@andrew.cmu.edu
 
-- 
Greg Jones


-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1994 09:08:07 GMT
From:      antonis@intranet.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   HYPERCOM


Hi

Did one have any good/bad experiences using Hypercom routers?

thank you
+-------------------------------------------------------------------+
|     Antonis Kyriazis                                              |
| Networks & Communications       e-mail: antonis@intranet.gr       |
| INTRACOM sa                                                       |
| 19.5 km Marcopoulo Ave.          fax:   +30-1- 68 60 106          |
| Peania 190 02                                                     |
| GREECE                          phone:  +30-1- 68 60 122          |
| The expressed opinions are of my own     + - MACEDONIA IS GREEK - +
+-------------------------------------------------------------------+


-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 94 14:12:40 EDT
From:      un027714@wvnvms.wvnet.edu (J. Parcone)
To:        comp.protocols.tcp-ip
Subject:   Can't reconnect....HELP!

Hello, Net!!

Slight problem:

I have two processes connected via sockets across Ethernet.  When the
client process quits it closes the connection, but then the server
closes the connection but it doesn't really close.  There is a huge
delay before the connection can be opened again, (might be because I'm
trying to read from a broken pipe now?).

What can I do to prevent this?  Is there any good example socket C
source I can ftp?

All help appreciated,

James Parker


-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 11:34:19 GMT
From:      swel@bluecross.on.ca (Steve Welsh)
To:        comp.protocols.tcp-ip
Subject:   TN3270

Does anyone know of a TN3270 s/w that runs on DOS and
provides a "mod 4" emulation. I have DOS s/w that provides
"mod 2" emulation and windows s/w that provides "mod 4".

Any help would be aprreciated.

Thanks

Steve

-- 
Steve Welsh                     \\\///
swel@bluecross.on.ca           / @  @ \   __   __              ___          __
Telecommunications Specialist  |   j  |  [_   /    |_| \    /   |    /\  / / _
Ontario Blue Cross             | (---)|  __]  \__  | |  \/\/   _|_  /  \/  \_|

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 11:51:19 GMT
From:      brobbins@newbridge.com (Bert Robbins)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address selection

Tom Techoueyres (wali@gate.net) wrote:
: Hi,
 
: My company is getting a 56K dedicated connection to Internet, I got already 
:  the IP address that my service provider gave me. It is a class C. this 
: means that the last octet of the IP address is for our company, which gives
: us 254 addresses. the primary server is a MicroVax running VMS, is there
: a logical way to assign an address to the primary server? The first three
: octet are control by the service provider, the last octet by the company, 
: but should it be 1, 37 or 250? I don't know what value I should assign 
: to the primary server?
: I would appreciate any help, thank you!

It dosen't matter unless you are going to subnet your class C address. If 
you do subnet then take a look at RFC 1219 for an idea on how to do this
with flexibility.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 17:17:19
From:      karl@cavebear.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Fake network addresses


>Chris Rohrer (crohrer@advtech.uswest.com) wrote:
 
>: I was of the understanding that there is a Class A or maybe a Class B
>: address that is reserved and not allocated to anyone on the Internet,
>: The purpose is to alllow private networks that do not/can not/will not
>: connect directly to the Internet the opportunity to have an address space
>: that will not conflict with or confuse anyone's routing tables.

The RFC you cited is quite separate from the "test" reserved addresses.

Class C 192.0.2.x is reserved and should not exists.  I use it as a 
preconfigured address in products I write and I coerce the IP stack into never 
sending from that Class C net number.  This forces the user to configure the
product.

I doubt, however, that routers and such would keep such addresses out of their
routing tables should they accidently appear.

            --karl--


-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 14:20:18 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Different speeds using WFTPD!!!???

Lost the original message, but it was about someone who
only got 2 or 3 kilobytes per second on a PC with an
SMC 8013 or WD 8013 or 8003 card.

I seem to post this every few weeks to some group or another.

Trash 8003PKDR and get the free Crynwr packet driver named
WD8003 or something similar.  It can be found at many 
sites including Simtel, wuarchive, ftp.ftp.com 

The problem is this, Western Digital wrote that packet
driver before SMC bought them out. 

That packet driver has a bug in that it does not check
to see that the previous packet has been fully outputted
before attempting to write the next packet.  So any TCP
which writes back-to-back packets, ie. any TCP you would
want to use, will end up trashing most of the packets.

The stuff on the actual wire is crap, so you would be
annoying others with this bad driver.

I have given up on SMC, I have explained it to them 
many times but they still distribute that broken driver.

Erick

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 14:26:17 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Small and Compact TCP/IP/PPP

Robert Bradford <Robert_Bradford@mindlink.bc.ca> wrote:
>
>How small and compact, in terms of memory requirements, can you
>make a TCP/IP and PPP implementation?

My WATTCP package can be stuffed into about 30 kilobytes,
more if you converted it from C.  It is designed for MS-DOS
but is easily ported to most other architectures.  

You can find it at dorm.rutgers.edu in pub/msdos/wattcp/wattcp.zip

>So, the question is how small can you make such an
>implementation? It can be "shrink wrapped" with the application
>and just support one application (i.e., one TCP connection) on
>one port using only the serial port. It must be able to do
>dial-up and accept IP address assignment from the remote
>system. The remote end will fully support TCP and IP and PPP,
>but the local end need only implement enough to support its
>application and still establish a working link to the remote
>end.

That's how it is set up.  It is also the TCP used in MS-Kermit,
TSoft's shareware NFS for MS-DOS, and countless net utilities.

Erick


-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 15:57:26 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.client-server,comp.unix.internals
Subject:   Re: Data formats needed for non-XDR conversion

In article <2vhr41$8u7@stc06.CTD.ORNL.GOV> zhou@isis.epm.ornl.gov writes:
>I would like to know if you could give me some pointers on where can I
>find all (or some of) the data formats for all machine types. Instead of
>using XDR converting routines to convert the data formats used by 
>different processors, I am trying to code my own routines to do such
>conversions due to performance reasons.  
>
>I heard that OSF' DCE doesn't use XDR routines too. Any comments on this?


DCE is based on the Apollo NCS scheme.  NCS has some advantages, but
data formating was not one of them.

Instead of XDR, NCS had what its authors called "receiver makes it right"
but was jokingly known to others as "receiver makes it wrong."  In fact,
NCS has a complicated version of XDR.  For example, instead of one
integer format as in XDR that just happens to match the byte order of
the CPU's used by the vendor that pushed XDR (and common network practice),
you have at least two, and the receiver must be prepared to convert from
any of them to its native format.  "Reciever makes it right" makes sense
provided you grew up in a closed and controlled environment and think
that you can enumerate all possible data formats now.  (Remember Apollo.)
In real life, there are always more formats than you can know about,
and people are always inventing new ones.  In real life, XDR made it
easy for 32-bit big-endian machines using one kind of floating point
and one character set, while NCS made it fairly easy for 32-bit big- or
little-endian machines using a few kinds of floating point and two
character sets.  All other machines must convert their data.  NCS did
not make the conversion faster or easier.  It just bloated the necessary
code.


Vernon Schryver    vjs@rhyolite.com

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 16:02:56 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers, packet size, and RFC 1122 (a query)

In article <2vhpou$9vg@pipe1.pipeline.com> alberg@pipeline.com (Al Berg) writes:

> ...
>When FTPs happen between the UNIX boxes and a PC on the same 
>segment, the maximum packet size is about 1500 bytes and 
>performance is good.
>
>When FTPs happen between a host on segment A and a client on 
>segment B, maximum packet size drops to 576 bytes and speed 
>drops by a factor of 5 or more.

A factor of 5 is high.  I would expect a factor a little smaller
than 1500/576 or about 2.5.

>When we put up a Chameleon FTP server on a PC on segment A and 
>do an FTP from a PC on segment B, maximum packet size stays at 
>1500 bytes and performance is good.
 
> ...
>The IBM rep sent us info saying that RFC 1122 basically says 
>that when IP packets cross a router, ...


>Has anyone "solved" this problem on their net?  

Many BSD derived systems have an "all subnets are local" switch to
violate the "Host Requirements" RFC rule.  I think AIX uses BSD-derived
network code, and so it might have that switch.  If so, and if subnets
are being used, that would solve the problem.  Some systems also have
an "all nets are local" switch, which would fix the problem.

The official, recommended solution is to use "MTU path discovery."


Vernon Schryver    vjs@rhyolite.com

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1994 16:55:10 GMT
From:      murf@perftech.com (John Murphy)
To:        comp.protocols.tcp-ip
Subject:   Re: Different speeds using WFTPD!!!???

In article <CsML5v.K9n@watserv1.uwaterloo.ca>, erick@sunee.uwaterloo.ca (Erick Engelke) says:

>I have given up on SMC, I have explained it to them >many times but they still distribute that broken driver.
>
That's not the only bug in that driver.  I even sent them the code to


Murf

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 17:30:01 +0000
From:      Roger@natron.demon.co.uk (Roger Barnett)
To:        comp.object,comp.protocols.tcp-ip,comp.lang.c++
Subject:   Re: Wanted: Object Oriented distributed communication toolkit

In article <CsKsJC.9BI@da_vinci.ecte.uswc.uswest.com>
           scollins@da_vinci.mtt.it.uswc.uswest.com "Steven Collins" writes:

>  Looking for an Object Oriented distributed communication toolkit
> with a C++ interface.  CORBA implementations are too heavyweight.
> I'm interested in something that is much much easier to use than 
> BSD sockets and XDR.
> Would "like" the product to run on different UNIX flavors plus MAC/PC.


<< apologies for posting instead of mailing >>


Steve, 

I tried to mail you the following but it was bounced at your end:

  Although you say you don't want CORBA stuff, have you looked at the DOME
  product from Object Oriented Technologies Ltd in the UK (not to be confused
  with a US piece of software of the same name) ? This is written entirely
  in C++ and offers a full C++ binding, supports various comms protocols,
  and is available on a wide range of systems.

  Contact info:  Chris Nugent on chris@rtc.co.uk

Regards,

-- 
Roger Barnett
                            "There are helicopters on the walls of Troy"
                                                            Clive James

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 17:40:59 GMT
From:      w-rolph@ds.mc.ti.com (Don Rolph)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address selection

In article <2vhdpb$ef7@tequesta.gate.net> wali@gate.net (Tom Techoueyres) writes:
>From: wali@gate.net (Tom Techoueyres)
>Subject: IP address selection
>Date: 7 Jul 1994 17:24:59 GMT
 
>Hi,
 
>My company is getting a 56K dedicated connection to Internet, I got already 
> the IP address that my service provider gave me. It is a class C. this 
>means that the last octet of the IP address is for our company, which gives
>us 254 addresses. the primary server is a MicroVax running VMS, is there
>a logical way to assign an address to the primary server? The first three
>octet are control by the service provider, the last octet by the company, 
>but should it be 1, 37 or 250? I don't know what value I should assign 
>to the primary server?
>I would appreciate any help, thank you!
 
>tom
>wali@gate.net

We made the primary server xxx.xxx.xxx.001 for what its worth!



Regards.
 
Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 17:42:52 GMT
From:      droehr@borland.com (Daev Roehr)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Windows screws up as server?

James,

>Is this a problem, is it only a problem with particular
>implementations, or is it an inherent problem because
>windows is non pre-emptive?

Windows make a lousy server, mostly because of the coopertive multi-tasking, 
partly because the 16-bit address space is all shared, and partly because 
it's not very robust. It does however, make a pretty good WWW reader.<g> The 
Daytona release (ie NT 3.5) is a better bet.

_daev



My opinions are my own. My corporate master wishes it so. 
"Resistance is futile." - The Borg    "Oh Yeah?" - Tommy Smothers 


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      08 Jul 1994 18:25:06 GMT
From:      tjfs@golf.tadpole.co.uk (Tim Steele)
To:        comp.protocols.tcp-ip
Subject:   Does anyone know of a scriptable telnet for Sun (or anything else?)

I'd like to be able to run a script, a bit like a uucp script, but to
a telnet server.

Any ideas?

Thanks

Tim

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 20:50:50 GMT
From:      Your Name <first.last@xxxxxxx.aaaaa.bbb>
To:        comp.protocols.tcp-ip
Subject:   Message for Anonymous FTP server

Is there a way with the Wollongong Implementation of TCP/IP to
add a message to a guest login to an anonymous FTP server?

Thank you.

Dorothy.Edmondson@daytonOH.NCR.COM
AT&T Global Information Solutions




dorothy.edmondson@daytonOH.NCR.COM






-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1994 20:54:20 GMT
From:      bpc@taichitaichi.cc.bellcore.com (chapman,benjamin p)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.programmer,comp.protocols.tcp-ip
Subject:   Help with MacTCP and Telnet

I am forwarding this message from a friend.  Please respond directly to him
but if that doesn't work, I'll forward a response to him.  I can be reached
at bpc@taichi.cc.bellcore.com

Hi,

I am trying to finish a program that I have taken over from another programmer
that needs to be able to communicate to a Unix machine via telnet.  What I am
looking for is some high-level libraries or functions that will enable me
to open and close a telnet session, and send and receive characters through
that session.  The code that I am working on has been ported from a PC
version that the previous programmer wrote, and that program used a package
called Distinct which provided those calls that were needed.  What I need to
know is if there is some similar package available for the mac, or if there
is something similar via FTP.

Any help on this matter would be greatly appreciated as I am a novice when it
comes to Mac programming.  Please send email to alan@hudtech.com


 <Hit CR to continue, "q" to leave message >

Many thanks in advance.

Alan Davey
w)(212)779-2225

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 21:16:21 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: Fake network addresses

Chris Rohrer (crohrer@advtech.uswest.com) wrote:

: Hi all,
 
: I was of the understanding that there is a Class A or maybe a Class B
: address that is reserved and not allocated to anyone on the Internet,
: The purpose is to alllow private networks that do not/can not/will not
: connect directly to the Internet the opportunity to have an address space
: that will not conflict with or confuse anyone's routing tables.

1597  I    Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, "Address
	   Allocation for Private Internets", 03/17/1994. (Pages=8)
	   (Format=.txt)


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 21:53:36 GMT
From:      rvw@laplace.math.purdue.edu (Rich Williams)
To:        comp.protocols.tcp-ip
Subject:   Phone # for Grand Junction needed.

I need the number for Grand Junction Networks Inc. I was
hoping to talk to some one about their new ether switch.


 Best regards,

 Rich  Williams               |  Systems Administrator
 rvw@math.purdue.edu          |  Purdue University
 (317) 494-4246               |  Math Department
 #include <std/disclaimer.h>  |  West Lafayette, IN 47907

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 22:29:18 GMT
From:      deleon@cat.hpl.hp.com (Laura de Leon)
To:        ba.seminars,comp.unix.large,comp.protocols.tcp-ip,comp.unix.admin
Subject:   BayLISA: Next Generation Internet Protocol


July 21st:	Dino Farinacci (Cisco)

		Title: Next Generation Internet Protocol (IPng)

		Description:

		The global Internet is going through growing pains.
		Address space exhaustion is approaching and routing
		table sizes are becoming too large for modern day routers
		to handle. IPng will be a new internet network layer
		protocol to address these problems.

		This talk will present a bit of history leading up to
		the proposals put forth today. Describe the IETF
		structure that supports the proposals. Introduce the
		various proposals and the mergers that have occured over
		the course of refinement. And in conclusion, hint at
		leading candidates and indicate when the IETF will decide.

August 18th:	Peter Salus: The History of UNIX

The Bay-LISA group meets monthly to discuss topics of interest for
administration of sites with more than 100 users and/or computers.
The meetings are free and open to the public.

BayLISA holds monthly meetings on the third Thursday of each month at
7:30 PM (please do not arrive before 7:00).  We meet at Synopsys
Building C in Mountain View off Highway 237 at Middlefield.

To get further information on the meeting location, you can request it
from the majordomo server on baylisa.org, you can ftp it from
	
	ftp.baylisa.org:/BayLISA/location

or you can query the BayLISA mail server by cutting and pasting
the following line to your shell:

	echo "index baylisa" | mail majordomo@baylisa.org

Starting this May and going through the rest of the summer, we plan
on broadcasting our meetings via MBONE. For more information, please
send email to:

	mbone@baylisa.org

BayLISA makes video tapes of the meetings available to members.  For more
information on available videos, please send email to:

	video@baylisa.org

For any other information, please send email to:

	info@baylisa.org

If you have any questions, please contact me or the info alias listed
above.

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 00:39:22 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip,comp.os.misc
Subject:   Call for beta testers - Adaptive File Distribution Protocol (AFDP)

The Adaptive File Distribution Protocol (AFDP) addresses the need for
efficient and reliable group communication.

The protocol is built on top of UDP, and uses a rate-based flow control
mechanism to provide efficient and reliable file distribution.  AFDP
uses the publishing metaphor: any machine receiving files is called a
subscriber and any machine sending files is called a publisher.  One
special subscriber is designated as the secretary; this machine is
responsible for managing the group membership and authorizing publishers.
AFDP dynamically selects between 3 different transfer modes: unicast,
multicast (on hosts that support it), and broadcast.

You can call AFDP from any of your applications, or just use the existing
file transfer mechanisms of AFDP.

AFDP has been tested on IRIX, SunOS, Solaris, RISC/os, Ultrix, and SVR4.2.
Our sources also include a library of convenience functions for writing
network applications, which can be re-used in other programs.

AFDP is not yet ready for public release, but we are looking for a group
of beta-testers who are familiar with network programming.  If you do not
fit in this category, please wait for the public release of AFDP. 

If you would like to beta-test AFDP,
please send the following to afdp@ecf.toronto.edu:

- the operating systems you are running
- which systems support IP multicast
- tell us what you would like to use AFDP for

We will contact the beta-team next week, with information on 
how to obtain our code.

	Steve Kotsopoulos <steve@ecf.toronto.edu>
	Jeremy Cooperstock <jer@dgp.toronto.edu>
-- 
Steve Kotsopoulos  P.Eng.                         steve@ecf.toronto.edu
Systems Analyst,  Engineering Computing Facility, University of Toronto

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Sat, 09 Jul 1994 10:59:49 -0500
From:      messina@mcs.com (David Messina)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: where can I get the interSLIP for MAC?

In article <9407081443.AA23279@fusion.intercon.com>, amanda@intercon.com
(Amanda Walker) wrote:

> messina@mcs.com (David Messina) writes:
> > It's free, and available on many archives (info-mac, e.g.) 
> 
> The canonical source is ftp.intercon.com, in the directory /InterCon/sales.
> It's also available on ftp.tidbits.com, but it's *not* generally available
> on random archive sites.  If it's on info-mac, it should be taken off of it.
> Putting InterSLIP up for FTP on any server requires explicit permission of
> InterCon Systems Corporation.  InterSLIP may be free of charge, but it still 
> copyrighted commercial software.

Sorry to step on your toes, Amanda. :)  

I incorrectly assumed InterSLIP was widely distributed, but I did not
actually check.  So as Amanda said, get InterSLIP from InterCon or
TidBits.  Don't expect to find it anywhere else.

-- 
David Messina
messina@mcs.com

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Sat,  9 Jul 94 23:32:00 -0700
From:      philip.burton@spacebbs.com (Philip Burton)
To:        comp.protocols.tcp-ip
Subject:   NDIS supported for Mac?

I hope this isn't a dumb question.  This came up in a "bull session."

Is there NDIS support for the Mac under System 7?  If not, is this 
support unnecessary?  Is there an equivalent mac-level interface?

-- Phil Burton --    philip.burton@spacebbs.com
- Palo Alto, CA -
---
þ CMPQwk #1.4þ UNREGISTERED EVALUATION COPY

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 1994 13:21:17 GMT
From:      marcin@pk-siec (Marcin Klimowski)
To:        comp.protocols.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime
Subject:   Re: POP protocol on SCO

martin bowman (mbowman@sita.int) wrote:

: Does anyone have any information about implementing the POP protocol on SCO 
: UNIX?
try ftp.sco.com:/TLS/BLAH bLAH bLAH
or  soils.agron.iastate.edu:
and read biz.sco.* !!!
--
------------------------------------------------------------------------------
Marcin Klimowski | e-mail - marcin@oeto.pk.edu.pl | IRCNICK - Cinek
		 | 	    marcin@twins.pk.edu.pl|			
------------------------------------------------------------------------------
		 	YOUR bus ALWAYS ARRIVES LATER :(
------------------------------------------------------------------------------

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 17:36:31 GMT
From:      tung@eespcb.ncku.edu.tw (Assistant)
To:        comp.protocols.tcp-ip
Subject:   A interesting routing quesiton.....

Hi,

This is a long message, first, thanks for your patient reading...

Here is a old network configuration of our lab:

                            140.116.32.0                     internet
 140.116.32.01...252 -------------------------140.116.32.253----------->
(netmask ff.ff.ff.00)                             (router)


Now we decide devide 4 subnet from 140.116.32.0, and route the IP packet
from the novell server, below is the new configurtion:

             140.116.32.64
  /----------------------------140.116.065...077 (netmask ff.ff.ff.f0
  |          140.116.32.192                       gate 140.116.32.78)
  | /--------------------------140.116.193...205 (netmask ff.ff.ff.f0
  | |        140.116.32.208                       gate 140.116.32.206)
  | | /------------------------140.116.209...221 (netmask ff.ff.ff.f0
  | | |      140.116.32.224                       gate 140.116.32.222)
  | | | /----------------------140.116.225...237 (netmask ff.ff.ff.f0
  | | | |                                         gate 140.116.32.238)
  | | | |      novell server
  | | | |   +-----------------+
  | | | \---|140.116.32.238(A)| netmask=?, gate=? (Q2,3)
  | | \-----|140.116.32.222(B)|
  | \-------|140.116.32.206(C)|
  \---------|140.116.32.078(D)|
            |                 |
  /---------|140.116.32.241(Z)| netmask=?, gate=? (Q4,5)
  |         +-----------------+
  |
  |                   140.116.32.0                                   internet
  \----------------------------------------------------140.116.32.253--------->
     (140.116.32.XXX not include in A,B,C,D subnet)       (router)

We have set the netmask and default gateway of PCs connecting to port A,B,C,D
but at novell,we have some question here...

1. We load tcpip.nlm with tcpip=yes, rip=yes, anything else needed?
   Does tcpip.nlm ver 1.00 work fine?
2. What netmask sould we set for port ABCD, FF.FF.FF.F0?
3. What gateway sould we set for port ABCD, 140.116.32.241?
   ps: When we load tcpip.nlm with this setting, it shows:
       "140.116.32.238 is not on the same subnet as 140.116.32.241....."
4. What netmask sould we set for port Z, FF.FF.FF.F0 or FF.FF.FF.00
   if ff.ff.ff.f0, how can hosts at port a, b, c, d connect to 140.113.32.xxx
   not on ABCD? (ex:140.116.32.60)
   Should we add static route to port Z?
5. What gateway sould we set for port Z, 140.116.32.253?
6. It is said that all the port of novell should has the same netmask,
   is it true?
7. The manual said that we'd better set RIP to off, why?

This is serious to us, any suggestion will be much appreciated.....

thanks again.

tung@eespcb.ncku.edu.tw


-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 17:39:20 GMT
From:      aboba@netcom.com (Bernard Aboba)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.answers,news.answers
Subject:   comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 1 of 3

Archive-name: ibmpc-tcp-ip-faq/part1

comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 1, 7/1/94

****************  Legalese ************

This document is Copyright (C) 1993,1994 by Bernard Aboba, except where 
the copyright is retained by the original author(s). This document
may be distributed non-commercially, provided that it is not
modified in any way. However, no part of this publication may be 
sold or packaged with a product for sale in any form without the 
prior written permission of Bernard Aboba. 

This FAQ is presented with no warranties or guarantees of ANY KIND
including correctness or fitness for any particular purpose. The
author(s) of this document have attempted to verify correctness of the
data contained herein; however, slip-ups can and do happen.  If you use
this data, you do so at your own risk. While we make every effort to
keep this FAQ up to date, we cannot guarantee that it is, and we will
not be responsible for any damages resulting from the use of the information
or software referred to herein. 

Unless otherwise stated, the views expressed herein are my own.  Last
time I looked, I had not been appointed official spokesperson of any
of the following:

	The Planet Earth
	The U.S.Government
	The State of California (not so good)
	The University of California, Berkeley
	The City of Berkeley (bringing you Riot of the Week(SM) )
        Addison-Wesley
        Publisher's Group West
	Any major or minor breakfast cereal (not even oatmeal!)
	
This FAQ will be posted monthly. In between it will be
available as: 
file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip

*********** Citation entry  ***********

This FAQ may be cited as:

  Aboba, Bernard D.(1994) "comp.protocols.tcp-ip.ibmpc Frequently
  Asked Questions (FAQ)" Usenet news.answers, available via 
  file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip, 
  57 pages.


*********** Test HTML FAQ  ***********

As a test, I've been playing with putting this FAQ into
HTML form. To try it out, point your browser to:
http://www.zilker.net/users/internaut/current.html

*********** Change History  ***********

Changes from 6/1/93 posting:
FAQ split into three parts. Updated several entries;
Over half a dozen new entries. Have added coverage
on 32-bit support. Changed entries sport a "*".
 
*********** KA9Q Request  ***********

In order to beef up the section of the FAQ on KA9Q,
I am asking for sample config files for use with the
CWRU or DIS KA9Q versions, to demonstrate use of the
following features:

1. Dial on demand. 
2. Use of KA9Q with built-in PPP. (has *anyone*
   gotten this work?)
3. DNS server. 
4. Use of KA9Q as a SLIP server with security.
5. Use of the SMTP/POP3 server with rewriting of
   addresses or rejection of junk mail. 
6. Use of the Gopher/HTTP/CSO server.

*********** Related FAQs ***************************

There is a FAQ available on features of TCP/IP
Packages for DOS and Windows. This is available at:
file://ftp.cac.psu.edu/pub/dos/info/tcpip.packages. 

The Windows Sockets Faq is posted to alt.winsock, and
is available at:
file://SunSite.UNC.EDU/pub/micro/pc-stuff/ms-windows/winsock/FAQ

The PC-NFS FAQ is available at:
file://seagull.rtd.com/pub/tcpip/pcnfs.FAQ.v1.4.Z or pcnfsfaq.zip
file://ftp.york.ac.uk/pub/FAQ/pcnfs.FAQ

The SNMP FAQ is regularly posted to comp.protocols.snmp

The TCP/IP FAQ is posted to comp.protocols.tcp-ip, and is
maintained by gnn@netcom.com. 

The "How To Get It" FAQ on the Crynwr packet driver 
collection is irregularly posted to comp.protocols.tcp-ip.ibmpc
by Russ Nelson, nelson@crynwr.com. 


***************** Book info  ******************

A bunch of you have requested information on the
book I am working on.  Here is the basic info:

Title: The PC-Internet Connection, TCP/IP
Networking for DOS and Windows
Authors: Bernard Aboba and Britt Bassett
Pages: 800 (estimated), 7" by 9"
Distributor: Publisher's Group West
ISBN: 1-883979-00-5
Price: $32.95 (est), includes Chameleon Sampler
software, WS-Gopher, PC-Eudora. 
Estimated release: October, 1994

To look at sample chapters from the book, check out
the following WWW page:  
http://www.zilker.net/users/internaut/forth.html

For those of in North America who *must* have 
a look at the book before it comes out, and are 
willing to comment on it, send me $25 to cover 
copying and postage, and I'll send you a copy. 
If you send back comments, I'll return the $25.
Since this is a big book, be prepared to spend 
some time looking at it.    

For those outside North America, sorry but we're on
a tight deadline, and so we will not be able to
include you. 


*********** EXAMPLE CONFIGURATION FILES  ***********

Many thanks to Dave Fetrow (fetrow@biostat.washington.edu)
for creating an archive of setup files. The archive is 
particularly oriented toward sets of applications that 
are somewhat tricky, such as combinations involving 
different driver sets, mixtures of NetWare, TCP/IP, 
and W4WG, etc. 

Please include not only the setup and configuration files
but some directions. Comments included with the setup files
are highly desirable. The files can include your name if you
desire. 

Please mail submissions to ftp@ftp.biostat.washington.edu. 

The archive itself is located at:
file://ftp.biostat.washington.edu/ftp/pub/msdos/network.setups 

Late breaking development: the archive has crashed, and 
files have been lost. 



TABLE OF CONTENTS

A. Components of a TCP/IP solution

A-1. What do I need to run TCP/IP on the PC?
A-2. What are packet drivers?  Where do I get them?
A-3. What is Winsock?  Where can I get it? 
A-4. What is Trumpet Winsock? How do I get it to dial? 
A-5. What publicly distributable TCP/IP applications are there
     for DOS?  Windows?
A-6. What software is available for doing SLIP?  Compressed SLIP?
     PPP?  For DOS?  For Windows?
A-7. What about the software included with various books? 
A-8. What diagnostic utilities are available to find problems with
     my connection?  Where can I get them?
A-9. Is there a CD-ROM with the software included in this FAQ? 
A-10. Does Windows NT support SLIP? PPP? 
A-11. Where can I take a peak at the WFW v3.11 VxD beta?
A-12. How do I get my BBS to run over TCP/IP? 
A-13. Are there graphical TCP/IP servers out there?
A-14. What methods of dynamic address assignment are available?
A-15. How can I set up PPP server on a UNIX host? 
A-16. What is WinSNMP? 

B. Questions about drivers

B-1. What do I need to know before setting up SLIP or PPP?
B-2. How do I configure SLIPDISK?
B-3. How do I install packet drivers for Windows applications?
B-4. When do I need to install  WINPKT? 
B-5. How to do I run both WinQVT and ODI?
B-6. Is it possible to use BOOTP over SLIP?
B-7. How do SLIP drivers work? 
B-8. When do I need to install PKTMUX?
B-9. Can NDIS be used underneath multiple protocol stacks of the same type?
B-10. Is there an NDIS over packet driver shim? 
B-11. How do I run NetBIOS over TCP/IP? 
B-12. How do I run NFS and another TCP/IP application?
B-13. How do I run Trumpet Winsock along with KA9Q or NFS? 
B-14. Sample Stick Diagrams
B-15. Strange and wonderful configuration files submitted by readers

C. KA9Q Questions

C-1.  What version of KA9Q should I use and where do I get it?
C-2.  What do I need to run KA9Q? Why won't it do VT-100 emulation?
C-3.  How do I configure KA9Q as a SLIP dialup connection?
C-4.  How do I configure KA9Q as a router?
C-5.  How do I get KA9Q to support BOOTP?
C-6.  How do I get KA9Q to support PPP?
C-7.  How do I get KA9Q to support SLIP dialin?
C-8.  Can I use KA9Q as a packet filter? 


D. Hints for particular packages

D-1. How do I get DesQView X to run over the network?
D-2. Why is NFS so slow compared with FTP?
D-3. Where can I get information on running NetWare and TCP/IP
      concurrently? 
D-4. What NetWare TCP/IP NLMs are out there and how do I get them
      to work? 
D-5. How do I get a telecom package supporting Int 14h redirection
      to work? 
D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP?
D-7. How do I get Windows For Workgroups to work alongside NetWare?
D-9. How come package X doesn't support the AppleTalk packet driver?
D-10. NCSA Telnet doesn't reassemble fragments. What should I do?


E. Information for developers

E-1. What publicly distributable TCP/IP stacks are there that I can
     use to develop my own applications?
E-2. Where can I get a copy of the Windows Sockets FAQ?


--------------------- FAQ Begins Here ---------------------------

A. Components of a TCP/IP solution

A-1. What do I need to run TCP/IP on the PC?

To run TCP/IP on the PC you will need:

* Appropriate hardware, such as:

    Ethernet card
    Token Ring card
    AppleTalk card
    Serial Port
   

  Any other network card with a packet driver or NDIS or ODI driver,
  (such as Arcnet), will also work.  If your card supports NetBIOS,
  this is also acceptable, since you can run a packet-driver-over-
  NetBIOS shim.

* Drivers for your hardware.

  Your card probably came with one or more of the following drivers:
 
    Network Device Interface Specification (NDIS) drivers
      [spec. by 3Com & Microsoft, used by LAN Manager, Windows
      for Workgroups, and Windows NT. LAN Manager uses NDIS 2.0,
      Windows NT uses 3.0, and WFW supports 2.0 and will support 
      3.0]
    ODI Drivers [spec. by Novell, abbreviation for Open DataLink
      Interface]
    Packet Drivers [spec. by FTP Software]
   
  TCP/IP stacks have been written for each of these driver interfaces, 
  so the important thing is whether your chosen stack is compatible 
  with the interface available for your card.
 
  A shim is software that runs on top of one set of drivers to
  provide an interface equivalent to another set. This is useful,
  for example,if you are looking to run software requiring an
  NDIS driver(such as Chameleon NFS) alongside software
  requiring a packet driver interface (such as KA9Q, Gopher, Popmail,
  NCSA Telnet, etc.), or run software intended for, say, a packet
  driver over an NDIS driver instead.
 
  Shims are available to run packet drivers over NetBIOS, ODI,
  or NDIS, in order to run software expecting a packet driver over
  NDIS, ODI, or NetBIOS instead. There are also shims to run NDIS
  over ODI (ODINSUP), and ODI over Packet Drivers (PDETHER). 


* A TCP/IP protocol stack.

  The TCP/IP protocol stack runs on top of the driver software, and
  uses it to access your hardware. If you are running a TCP/IP
  protocol stack that requires drivers that aren't available for your
  hardware, you're in trouble. Check into this before purchasing!
 

* If running Windows applications that require it, WINSOCK.DLL. 


  Windows Sockets is a sockets interface which was created as a 
  Windows DLL. Each  TCP/IP implementation requires its own version 
  of Windows Sockets. Trumpet Winsock and VxDTCP are the only
  two publicly distributable Windows Sockets implementations. 
  WINSOCK.DLL provides 16-bit support; WSOCK32.DLL provides 32-bit support. 

   
* Applications software.

  Although most of us in this newsgroup seem to spend our time
  looking for working combinations of applications,WINSOCK.DLLs,
  Windows Sockets compliant TCP/IP implementations, shims, 
  drivers, and hardware, ultimately your goal is eventually to 
  run an application successfully. If and when that happens, 
  please send me a note, so I can add it to this FAQ.


A-2. What are packet drivers?  Where do I get them?

Packet drivers provide a software interface that is independent of the  
interface card you are using, but NOT independent of the particular 
network technology. As Frances K. Selkirk (fks@vaxeline.ftp.com) notes:

"That's one reason they're easier to write than ODI drivers! If you
write a class three (802.5 Token Ring) driver, you will need to use
software that expects a class three driver, not software that expects
a class 1 (DIX ethernet) driver. There are a few drivers that fake class 1. 

I believe only class 1 and class 6 (SLIP) drivers are supported by 
freeware packages."

The chances are fair that your Ethernet card came with a packet
driver, and if so, you should try that first. If not, then you
can try one of the drivers from the Crynwr collection (formerly
called the Clarkson Drivers). See the Resource listing for info.

For 3COM drivers, try ftp ftp.3com.com. For technical information,
try info@3com.com. For marketing and product info, try
leads@hq.3mail.3com.com.The packet driver specification is available
from vax.ftp.com in packet-d.ascii

The following vendors have packet drivers with source available for
their pocket lan adaptors:

D-Link - +1-714-455-1688
Solectek - +1-619-450-1220
Accton - +1-415-266-9800
Compulan - +1-408-922-6888
(soon Kodiak's Noteport - +1-408-441-6900)

You can obtain a complete library of packet drivers from many of the
Simtel20 mirror sites, including:
file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip, pktd11c.zip. 


A-3. What is Windows Sockets?  Where can I get it?

  The idea for Windows Sockets was born at Fall Interop '91, during a
  Birds of a Feather session.  

  From the Windows Sockets specification:
  [courtesy of Mark Towfiq, towfiq@Microdyne.COM]:
 

    The Windows Sockets Specification is intended to provide a
    single API to which application developers can program and
    multiple network software vendors can conform. Furthermore, in
    the context of a particular version of Microsoft Windows, it
    defines a binary interface (ABI) such that an application
    written to the Windows Sockets API can work with a conformant
    protocol implementation from any network software vendor.

Windows Sockets will be supported by Windows, Windows for Workgroups,
Win32s, and Windows NT. It will also support protocols other than TCP/IP.
Under Windows NT, Microsoft will provides Windows Sockets support over
TCP/IP and IPX/SPX. DEC will be implementing DECNet. Windows NT will 
include mechanisms for multiple protocol support in Windows Sockets, 
both 32-bit and 16-bit.

Mark Towfiq writes:

    "Files and information related to the Windows Sockets API are
     available via file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock, 
     which is a mirror of /pub/winsock on Microdyne.COM (SunSite has a much
     faster connection to the Internet, so you are advised to use
     that).

     If you do not have FTP access to the Internet, send a message
     with the word "help" in the body to either
     ftpmail@SunSite.UNC.Edu, or ftpmail@DECWRL.DEC.Com, to obtain
     information about the FTP to Mail service there."
 
  Alternative sources for the Windows Sockets specification include
  rhino.microsoft.com (an FTP server running NT), as well as the
  Microsoft forum on CompuServe (go msl).
  
  Currently NetManage (NEWT), Distinct, Spry, FTP and Frontier are shipping
  Winsock TCP/IP stacks, as is Microsoft (Windows NT and TCP/IP for
  WFW), Beame & Whiteside Software (v1.1 compliant), and Sun PC-NFS. 
  If you are looking for a Winsock.dll, you should first contact your TCP/IP
  stack vendor. Novell has one in beta for their Lan Workplace for DOS.

A-4 What is Trumpet Winsock? How can I get it to dial? 

Peter Tattam has released a shareware Windows Sockets compliant
  TCP/IP stack. You can obtain it via    
  file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip, winapps.zip, or
  file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winsock.zip.   
  
The first thing to do after you download WINSOCK.ZIP is to create
a directory for Trumpet Winsock, such as C:/TRUMPWSK, and put it
in your DOS PATH statement. 

Trumpet Winsock operates over packet drivers, or over a serial port
using its own built-in SLIP/CSLIP. If you are using a network
adapter, this means that you will have to locate a packet driver
for your adapter, and load it. Trumpet Winsock also comes with 
WINPKT, and this is loaded next, via the command
WINPKT.COM 0x60 [or whatever the software interrupt for your packet driver]

You will then enter Windows, and create a group in the Program Manager
for all the files that come with Trumpet Winsock. The stack itself is loaded
by executing TCPMAN. Applications that come with it include WinCHAT, 
a chatting program; PINGW, a ping utility; FTPW for FTP, WINARCH for Archie. 

When you first execute TCPMAN, you will be asked to fill out the setup 
information for the stack. Select whether you will be using a network
adapter or SLIP; you cannot use both. 

Since Trumpet Winsock does not yet support PPP, you will need to load the
EtherPPP driver and WINPKT prior to running Windows. EtherPPP is available via
file://merit.edu/pub/ppp/etherppp.zip. This is an Ethernet simulation driver, so you
will configure Trumpet Winsock as though it were running over an Ethernet
Packet driver, i.e. by loading WINPKT 0x60, and setting the packet driver
vector in TCPMAN to 60. 

EtherPPP comes with its own dialer, so you will need to create a dialing script.
If your TCP/IP address will be changing, you will also need to write a little
batch script to capture the assigned IP address, and insert it into Trumpet's
initialization file.  EtherPPP takes up too much RAM (121K), but otherwise
works fine.  

If for some reason you don't like Trumpet Winsock's scripting language, 
you can use any other comm program that doesn't drop carrier on exit, or 
the DIALER program, available via: 

file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip. 

As for Trumpet Winsock's built-in scripting language, the default dialout
script is LOGIN.CMD. A sample LOGIN.CMD file from Geoff Cox (geoff@satro.demon.co.uk):

#
# initialize modem
#
output atzm0\13
input 10 OK
#
# set modem to indicate DCD
#
output at&d2&c1\13
input 10 OK\n
#
# send phone number
#
output atdt0813434848\r
#
# my other number
#
#output atdt241644\13
#
# now we are connected.
#
#input 30 CONNECT
#
#  wait till it's safe to send because some modem's hang up
#  if you transmit during the connection phase
#
#wait 30 dcd
#
# now prod the terminal server
#
#output \13
#
#  wait for the username prompt
#
input 30 ogin:
username Enter your username
output \satro\r
#
# and the password
#
input 30 assword:
password Enter your password
output \my password\r
#
# we are now logged in
#
input 30 otocol:
#
# see who on for informational reasons.
#
output SLIP\r
input 30 HELLO


A-5. What publicly distributable TCP/IP applications are there for
     DOS?  Windows?

Right now there are a wealth of publicly distributable TCP/IP
applications running under DOS.  Windows also has a wealth of 
programs available, including implementations of Gopher, Mail
(POP3/SMTP), FSP, Mosaic, Telnet, FTP, IRC, and WAIS. 

See the Resource listings for information.


A-6. What software is available for doing SLIP?  Compressed SLIP?
     PPP?  For DOS?  For Windows?  For OS/2?

For SLIP or CSLIP use with DOS, I recommend using SLIPPER or CSLIPPER. 
These are packet drivers that can be used along with a dialer. For PPP, 
I recommend the EtherPPP packet driver described above.  

There is a special version of NCSA Telnet for PPP, available from
merit.edu, /pub/ppp directory.

KA9Q supports SLIP/CSLIP, but unfortunately can not be used as a
TCP/IP protocol stack to run other apps.

I have heard good things about IBM's TCP/IP for OS/2, but haven't
used it msyelf. Please see the FAQ from comp.os.os2.networking for details.

IBM, FTP Software, Beame & Whiteside, Frontier, SPRY and Netmanage also 
offer SLIP support in their products. See the resource listings for details.  


A-7. What about the software included with various books?

The software included with various books (including mine) is usually
Chameleon Sampler from NetManage. Sampler supports SLIP/CSLIP/PPP, but
not connection over a network, and includes software for FTP, Telnet,
TN3270, and Mail. The stack included with Sampler (NEWT) is Winsock
compatible, so you can run any Windows Sockets-compatible application
over it. Installation is quite a bit simpler compared with going the
Trumpet Winsock route, so this is probably the best way to go assuming
that you are a dialup IP user. 


A-8. What diagnostic utilities are available to find problems with
my connection?  Where can I get them?

Frequently used diagnostic utilities include ifconfig (checks the
configuration of the network interfaces), ping (tests IP layer
connectivity), traceroute (traces the route that a packet takes
between two sites), netstat (checks the routing table), tcpdump
(protocol analyzer), arp (looks at the IP to Ethernet address
mappings).

KA9Q includes ifconfig, ping and traceroute functions.  In KA9Q hop
check is the equivalent of traceroute.  The Trumpet TCP/IP stack also
has a hopchk2 command that is a traceroute equivalent.

Etherload is very useful for network profiling, while Etherdump can
be used for packet catching, although I wish it would give more
information, along the lines of TCPDUMP.  

Trumpet Winsock comes with Windows implementations of Ping and Traceroute. 

A-9. Is there a CD-ROM with the software included in this FAQ?

The Packet Driver, WinSock & TCP/IP CD-ROM is available from
CDPublishing for $29.95. This includes the packet drivers of course,
but also lots of other DOS and Windows TCP/IP stuff, including
Windows Sockets applications. It also includes the text of all
the RFCs. This is now somewhat out of date (it was cut in
December), but is otherwise highly recommended. 

CDPublishing, (604)874-1430, (800)333-7565, fax: (604)874-1431,
email: info@CDPublishing.com, FTP archive: ftp.CDPublishing.com,
Gopher site: gopher.CDPublishing.com, WWW: http://www.CDPublishing.com

A-10. Does Windows NT support SLIP? PPP? 

The "Daytona" release of Windows NT will include support for 
PPP (client and server) and SLIP (client), both including
support for Van Jacobson header compression. 

A-11. Where can I take a peak at the WFW v3.11 VxD beta?

This is a beta release of the forthcoming 32 bit-TCP/IP stack for 
Windows for Workgroups v3.11. This is looking *very* good; it's
fast, and has worked fine for me. It also supports a host of very
nice new features, including DHCP automatic configuration, WINS
name resolution, and Windows Sockets v1.1. However, plesae not that
it does not offer SLIP or PPP support. 
The final beta release is now available via:
file://ftp.microsoft.com/PerOpSys/WFW/tcpip/ 


A-12. How do I get my BBS to run over TCP/IP? 

First off, let's clarify what we mean by "over TCP/IP." Usually
this means "accessible via Telnet." Be aware that doing this will
not necessarily work well, since few BBSes have been tested running
over TCP/IP. As a result you may experience frequent crashes, or
abominable transfer rates. For example, I have seen transfer rates 
as low as 100 characters/second over a 14.4 Kbps PPP connection 
which routinely supports 1600 cps transfers with FTP.

This situation might be improved by running an FTP server instead. 
This could be accomplished for example by running KA9Q in another
window under DesQView, or by putting the files on an NFS-mounted
drive, then using another machine as the FTP server. 

One way to hook up a multi-line BBS is to use a terminal server, 
and hook up the BBS's serial ports to that. The disadvantage of this is that
if your BBS is really big you will need multiple terminal servers
which will each have their own domain names and TCP/IP addresses. 
Confusing. 

Brian Clements of Murkworks has a better solution, called BBSnet. 
It provides a Telnet interface that looks like a FOSSIL driver.  The first
version runs partly as an NLM; some of the code resides on the server.
For info, contact 

BBSnet,MurkWorks, Inc., P.O. Box 631,Potsdam, NY 13676, 
+1 315 265 4717, info@MurkWorks.com

eSoft has also recently announced that they are working on a TCP/IP
compatible version of TBBS. Look for this to be shown at OneBBS
Con '94 in Atlanta. 

A-13. Are there graphical servers out there?

Yes! For Windows there is a graphical SMTP daemon which is not very
functional (it can't do as much as KA9Q); several Web servers, including
a Windows version of NCSA's HTTP, and SerWeb. 

For Windows NT, The European Microsoft Windows Academic Consortium (EMWAC) has
released Windows NT servers for Gopher, WAIS, and WWW. These servers
are easy to install, and fast, and offer the full complement of capabilities,
including support for forms, access to WAIS indices from within HTTPS, 
installation as a Windows NT service, etc. 

See the resource section for details.

A-14. What methods of address assignment are available?

Methods of address assignment include client/server protocols
(RARP, BOOTP, DHCP), as well as script-based methods 
(terminal server indicates, "your address is 192.187.147.2"). PPP
supports assignment of addresses from the server. 

As part 2 of this FAQ discusses, there are RARP and BOOTP clients
and servers available for DOS. Typically the clients work by stashing
the IP address in a DOS environmental variable. It is then your responsibility 
to modify the appropriate config files to reflect this 
address. This can be done using a DOS batch script and a utility such as 
DOS awk. This same approach can be used to modify config files when using
EtherPPP; this does not place the IP address into a variable, but the output
of EtherPPP can be piped to a file and the IP address picked off and inserted 
in the appropriate locations. If this sounds complicated, it is; be warned.

Trumpet Winsock supports script-based assignment of addresses. Microsoft 
supports a DHCP client in WFW TCP/IP, and both client and server in Windows NT. 
There is also a forthcoming DHCP server for Sun. 

A-15. How can I set up PPP server on a UNIX host? 

This is not the appropriate place to address that question, but lots
of info on this is available in the comp.protocols.ppp FAQ. 

A-16. What is WinSNMP? 

WinSNMP is an API which provides a standard interface to to the
Simple Network Management Protocol (SNMP) for network
management applications running under Windows. Applications written to 
WinSNMP can run on any WinSNMP-compatible implementation. 

Vendors supporting WinSNMP include FTP Software, which supports it
in both OnNet 1.1, and PC/TCP 3.0. 

B. Questions about drivers

B-1. What do I need to know before setting up SLIP or PPP?

Before setting up your SLIP or PPP connection, you should
have available the following information:

* The domain name and TCP/IP address of your host.
* Whether your TCP/IP address will be assigned statically,
  dynamically, or from the server.
* If from the server, whether you will be using RARP, BOOTP or DHCP. 
* The domain name and TCP/IP address of your machine (if you are not
  configuring the address dynamically or via BOOTP)
* The domain name and TCP/IP address of the primary and secondary
  Domain Name Server.
* The subnet mask.
* The domain name and TCP/IP address of an NNTP server.
* Whether your host supports POP, and if so, what version.
* Whether the host supports compressed or uncompressed SLIP, or PPP.
* The size of the Maximum Receivable Unit (MRU). 


Do not attempt to connect to your host before you have this
information, since it will just waste your time and money, and may
cause problems for the network.  In particular, do not attempt to
initiate a connection using a made up TCP/IP address! It is possible
that your made-up address may conflict with an existing address.  

This is probably the quickest way to get people very angry at you.

Static addressing means that your TCP/IP address will always
be the same. This makes it easy to configure your setup files.
Dynamic addressing means that the host will send you a message
containing your TCP/IP address when you log on. This can be
problematic if your software doesn't support grabbing the address
and inserting it into the setup files. If not, then you may have
to edit your setup files every time you log on. Yuck!

Chameleon NFS includes a version of SLIP which can handle dynamic
addressing. The most recent version of Novell's Lan Workplace for
DOS does as well. 

You can also retrieve your address using RARP, BOOTP or DHCP. RARP
is only available to those on the same LAN as the RARP server, since
it uses broadcasting. BOOTP clients can access BOOTP servers on other
LANs via BOOTP relay. DHCP is a BOOTP extension, which allows
complete configuration of a client from info stored on a DHCP server, and in
addition supports new concepts such as "address leases". Since
DHCP frames are very similar to BOOTP frames, devices supporting BOOTP relay 
will also support DHCP relay. 

Of course, for DHCP or BOOTP to work, you will need to set up a DHCP
or BOOTP server. DHCP servers are available for UNIX, and Windows NT.

PPP also supports server assignment of TCP/IP addresses.


B-2. How do I configure SLIPDIAL?


From Ashok Aiyar, ashok@biochemistry.bioc.cwru.edu:

PHONE Script Files:

PHONE comes with several scripts (for various modems) and for the
University of Minnesota Terminal server built into it.  The command
PHONE WRITE writes these scripts to an ASCII file called PHONE.CMD,
which can be edited to your needs (modem and slip server)

The documentation that accompanies PHONE, provides good instructions on
writing script files to get PHONE to dial SLIP servers other than
the University of Minnesota server.  For example here is a script
that I use to dial a CISCO server at the University that I attend.

Background:  To start a SLIP connection, I dial our terminal server,
and login with a username and password.  After doing so, I start a SLIP
session with the following command "slip username-slip.dialin.cwru.edu",
followed by my password -- again.

Here then is the relevant portion of the PHONE.CMD script file -
#
# CWRU-TS2 SLIP login script by Ashok Aiyar 3/26/93
# Last revised 3/28/93
Procedure    Host.CWRU.Login
TimeOut 60      'CWRU-TS2 terminal server is not responding'
Message         "CWRU-TS2 SLIP login script -- Version 1.1"
Message         'Waiting for SLIP server to respond'
Quiet ON
Expect 'Verification'
Message         'Request for User Verification Received from CWRU-TS2'
Message         'Sending your user name and password'
Quiet OFF
Expect   'Username:'
Send '%u<'
Expect   'Password:'
Private
Send '%p<'
Reject    'Access denied'   'Your user name or password was not accepted'
TimeOut 30    'SLIP server did not respond to your validation request'
Expect 'CWRU-TS2>'
Send 'SLIP<'
TimeOut 10    'SLIP server did not respond to SLIP command'
Expect 'IP hostname or address:'
Send '%u-slip.dialin.cwru.edu<'
TimeOut 10 'SLIP server did not respond to hostname'
Reject    'Bad IP address'   'Incorrect Hostname'
Expect 'Password:'
Send '%p<'
Reject    'Access denied'    'Password not accepted.'
TimeOut 10
Expect 'Header Compression will match your system'
Message 'Login to CWRU SLIP server successful'
Wait 1.0
EndProcedure   Host.CWRU.Login
#
#
Procedure      Host.CWRU.LogOut
# Nothing special needs to be done to logout
EndProcedure   Host.CWRU.LogOut
#
#   End of Script file
#
----------------------------------------------------------------------
How to use packet drivers other than UMSLIP with PHONE?

The quick answer -- there is no "clean" way.  Below is a batch file
hack that I wrote to use PHONE with other packet drivers.  In this
example, the packet driver is Peter Tattam's CSLIPPER.  To use a
batch file like this, you must know the parameters with which you
plan to use the packet driver -- i.e interrupt vector, baud rate,
port address, and IRQ.  This batch file requires UMSLIP.COM,
CSLIPPER.EXE, and TERMIN.COM to be in the same directory
or in your path ...

All that the BATCH file does is to let you dial the SLIP connection
using PHONE, load the appropriate packet driver, hangup the
connection, and unload the driver when you are done ...

-- being CWRUSLIP.BAT --
@echo off
rem   this batch file is an ugly hack of U. of Minn. "SLIP.BAT"
rem   awaiting a version of C/SLIPPER that can directly interact
rem   with PHONE
rem   CWRUSLIP.BAT file is used with PHONE.EXE to start a SLIP
rem   connection on CWRU-TS2
rem   last modified 3/28/93 -- Ashok Aiyar

@echo off
cls
goto start

:start
if %1. == ?.         goto help
if %1. == help.      goto help
if %1. == setup.     goto setup
if %1. == dial.      goto forceD
if %1. == hangup.    goto forceH
if %1. == quit.      goto forceH
if %1. == HELP.      goto help
if %1. == SETUP.     goto setup
if %1. == DIAL.      goto forceD
if %1. == QUIT.      goto forceH
goto bogus
goto unload

:forceH
termin 0x60
umslip >nul
phone force hangup
goto unload

:slipper
termin 0x60
REM  the following line must be changed to reflect the COM port,
REM  IRQ, baud rate, and software interrupt
lh c:\packet\cslipper com1 vec=60 baud=57600 ether
goto end

:forceD
termin 0x60
umslip >nul
phone force dial
goto slipper

:setup
termin 0x60
umslip >nul
phone setup
goto help

:unload
termin 0x60
goto end

:bogus
echo %1 is not a valid command.
echo Try "cwruslip help" for a list of valid commands
echo.

:help
echo --------------------------------------------------------------
echo           Case Western Reserve University SLIP Setup
echo                  using Univ. of Minnesota PHONE
echo --------------------------------------------------------------
echo cwruslip setup     modem settings, phone number, username etc.
echo.
echo cwruslip dial      DIAL and establish the SLIP connection
echo cwruslip quit      HANGUP the phone and unload the driver
echo cwruslip help      this screen
echo.

:end
-- end CWRUSLIP.BAT --
 


B-3. How do I install packet drivers for Windows applications?

How do I install packet drivers for Windows applications?

The secret is to load the packet driver, then run Windows. If you
are running Trumpet Winsock, you will also have to load WINPKT
before running Windows, as follows:

winpkt 0x60

If you are running DOS applications within a virtual DOS session
under Windows, you should load PKTMUX after your packet driver, as
follows:

PKTMUX 4 [or however many sessions you want]
WIN [load windows]
 
Then within each DOS session, load PKTDRV, the virtual packet driver.

If you are running Trumpet Winsock along with other DOS apps in a 
virtual DOS session, then you will need to load PKTDRV prior to
loading Windows, and then load WINPKT on top of it, as follows:

PKTMUX 4
PKTDRV 0x62
WINPKT 0x62
PKTDRV 0x60
WIN

TCPMAN will then find the virtual packet driver at 0x62. 


B-4. When do I need to install  WINPKT? 

PKTMUX and WINPKT both accomplish the same thing: allowing you to
connect to a DOS packet driver running in real mode from a virtual
DOS session under Windows. PKTMUX is useful when you are running
more than one TCP/IP stack, and since it takes up more RAM and is
slower than WINPKT, you should only use it when you want to run more
than one stack at a time. If you are running only one DOS app,
or are using Trumpet Winsock, stick with WINPKT. 

James Harvey (harvey@iupui.edu) notes:
Winpkt is only useful running DOS applications with built-in TCP/IP
stacks under Windows, and for some Windows-based stacks (like the
Trumpet winsock.dll).  When an application registers with a packet
driver TSR to receive packets of a specified protocol type, one of the
things it hasto pass as a parameter to the packet driver in the call
is the address of a routine in the application that the packet driver
is to call when it has a packet to pass back to the application.  In
the case of an application running in 386 enhanced mode in a DOS shell
under Windows that is using a packet driver loaded in real mode before
Windows was loaded, the packet driver must ensure that Windows has the
application in memory when it does the callback, otherwise the callback
jumps off into space and your system locks up.  Winpkt does a Windows
system call to force the app into memory before the callback is done.

Erick Engelke (erick@development.uwaterloo.ca) notes:
Windows in enhanced mode uses the protected mode of the
386 CPU to create multiple virtual machines.  Winpkt tells
Windows to switch to the correct virtual machine before
trying to pass up the packet.  This reduces the chances of
Windows crashing.


B-5. How to do I run both WinQVT and ODI?

My advice is to use the Windows Sockets version of WinQVT/Net, Trumpet
Winsock, and ODIPKT. ODIPKT will allow you to run packet driver software
over ODI. You will also need to load WINPKT for Trumpet Winsock. 

The loading sequence is:

LSL [Link support layer]
NE2000.COM [or other ODI driver]
IPXODI [IPX version supporting ODI]
NETX
ODIPKT 1 96
WINPKT 0x60
WIN [run windows]

Then run Trumpet Winsock, and load WinQVT/Net. 

B-6. Is it possible to use BOOTP over SLIP?

Yes, but it is easier to use dynamic address assignment to get 
your IP address. This is where the SLIP server outputs your IP address 
before switching to SLIP. 

If you need BOOTP, then you should run a BOOTP server on the SLIP
server so that it can tell which SLIP connection originated the
request. Of course, the BOOTP server will ignore the hardware address
of the request originator, but instead will keep track of the SLIP
interface the request came in on. See the question on adding BOOTP to
KA9Q for info on how to handle this on the PC. Under UNIX, you may
have to add BOOTP capability to your slip driver, and rebuild the
kernel. (Not recommended for the squimish). 


B-7. How do SLIP drivers work? 

Some TCP/IP applications are written to only support Class 1 (Ethernet)
packet drivers, but do not support Class 6 (SLIP). For these applications, you
need software to make the application think it is dealing with a class 1
interface. This is done by adding fake ethernet headers to incoming 
SLIP or PPP packets and stripping the headers off outgoing packets. 


B-8. When do I need to install PKTMUX?

PKTMUX is needed to allow you to use more than one TCP/IP stack at the same 
time. This is useful if you have applications that require different stacks. 
Note that you do not need PKTMUX to run different protocols, since packet 
drivers only look at packets in the protocol they're designed to handle, 
and therefore you can use more than one of these at a time without conflict. 
You also don't need PKTMUX if all your applications use the same TCP/IP stack. 

PKTMUX works by looking at outgoing datagrams, and caching information on 
source and destination ports and addresses. Using this information, PKTMUX
tries to sort incoming datagrams by TCP/IP stack. If it can't figure out
which stack to send a datagram to (as might be the case if you were running
a server application on a well-known port, and had not sent any outgoing
packets yet), PKTMUX will send the datagram to all stacks. If all stacks
do not complain about the datagram, PKTMUX will throw away the ensuing outgoing
ICMP error message, assuming that one of the stacks correctly received
the datagram. If all stacks complain, it will send a single ICMP message
and throw the rest away.

While PKTMUX does its job very well, there are some situations that it cannot
handle, such as port conflicts. If two applications open the same TCP port,
chaos is inevitable, and there is little that PKTMUX can do to help. 

B-9. Can NDIS be used underneath multiple protocol stacks of the same type?
No. There is no equivalent to PKTMUX for NDIS.  

B-10. Is there an NDIS over packet driver shim? 
Joe Doupnik writes:

"No. Packet Drivers work by having an application register
for a particular packet TYPE, such as 0800 for IP. NDIS works much
differently, by offering a peekahead of every packet to applications in turn,
a polling operation. The only way NDIS could gracefully sit on a PD would
be to run the Packet Driver in all-types mode and let NDIS see all pkts
not used by other clients. Needless to say, that's an undesirable situation.
The quick solution, costing about US$100 (at least at my place,
more at yours) is a second Ethernet board in the client together with a
second IP address (most important, please)."

B-11. How do I run NetBIOS over TCP/IP? 

NetBIOS over TCP/IP is discussed in RFCs 1001 and 1002, which defines
three types of NetBIOS nodes:  

* B nodes, which use UDP broadcast packets to distribute datagrams and
resolve names. 
* P nodes, which use point-to-point communications and which 
require NetBIOS Datagram Distribution (NBDD) and NetBIOS Name 
Servers (NBNS). P nodes do not listen to or use broadcast 
services, so they cannot be used alongside B nodes. Unfortunately NBNS, 
and NBDD servers were not widely implemented, and those
that do exist (such as an implementation from Network Telesystems) 
are not inexpensive.  
* M nodes, which use both point-to-point and broadcast. 

B node technology cannot be used on an IP internet without extensions, 
since UDP broadcast packets are not forwarded through routers. This 
is not a problem with use of NetBIOS over IPX/SPX, since in IPX/SPX 
broadcast packets are forwarded. 

However, until very recently, M and P node technology was not supported 
by popular TCP/IP implementations. For example, PC/TCP supports
B node technology with extensions such as a broadcast file, host file, 
or DNS resolution of NetBIOS names. Windows NT and WFW TCP/IP uses an 
LMHOSTS file for resolving names. 

According to Chip Sparling of FTP Software:

"From what I remember from our discussions of a few years ago, P
nodes were only implemented by Ungermann Bass and 3COM (and they 
required you to use a NetBIOS name resolver which was non-rfc 1001, 1002 compliant), 
nobody did M nodes (as far as I remember) and PC-LAN, Lantastic and
LanManager used B node.  Also, if you did a P or M node it wouldn't be
compatible with a B node NetBIOS.  We decided that we could give the
compatibility and functionality (routability) with a B node plus
extensions implementation.  So, that's what we did." 

Without implementation of M and P node technology, the only way 
to run over an IP internet is to to implement B node technology 
with extensions, as FTP Software does in PC/TCP. According to Chip, 
"one way to handle large numbers of hosts on multiple networks is 
to use the broadcast file extenstion.  Instead of putting specific 
ip addresses in the broadcast file, use a subnet broadcast address 
like nnn.nnn.nnn.255. which will cover an entire subnet."

Assuming you don't need any of the extensions to RFC NetBIOS 
Microsoft created to make NetBIOS work smoothly in a routed environment 
(available only in their IP stack), you can choose from a wide variety of
commercial vendors. For example, FTP Software's PC/TCP includes RFC NetBIOS 
support; Performance Technologies has a NetBIOS that runs over packet drivers,
as does Accton (LANSoft). 

If any other vendors are reading this, I'd love to have information 
on how *you* implement NetBIOS over TCP/IP, and whether you'll be
supporting WINS, the new P-node technology name resolution service
from Microsoft. 

WINS will be included in the next WFW TCP/IP release, which is currently
in beta test and available for download from ftp.microsoft.com. Consult the 
beta release documentation for more information on this. 


B-12. How do I run NFS along with another TCP/IP application?

The DOS NFS implementation by M. Durkin now supports a built-in
packet multiplexer that can handle NFS plus another stack loaded
simultaneously. If you need to load more stacks, then you will need
to run PKTMUX as well.

See the resource section for details. 

B-13. How do I run Trumpet Winsock along with KA9Q or NFS? 

The secret is to load WINPKT on top of the PKTDRV virtual
packet driver, if you are running PKTMUX. 

B-14. Sample Stick Diagrams

It has been proposed that we begin to collect some diagrams of working
combinations of hardware, drivers, shims, stacks, and applications. I'm
game, and have made a start below. If you've got some other exotic
configuration that works (or if you've tried one of the configurations below
and discovered it doesn't work, drop me a line).

   Running an individual DOS application under Windows

    NCSA telnet / DOS Trumpet / POPmail/ PC Gopher III
                 |
             DOS Session
                 |
             Windows 3.1
                 |
               WinPKT
                 |
            Packet driver or Shim
                 |
                DOS
		 |
           Network Adapter


DOS Trumpet, NCSA Telnet, and WinQVT/Net over Ethernet under Windows

                                                QVT/NET
                                                   |
     TRUMPET                    NCSA telbin        |
       |                             |             |            
     PKTDRV1                     PKTDRVn           |
       |                             |             |
     DOS Session                DOS Session    Windows Session
       +-----------+-----------------+             |
                   |                               |
                   +                               |             
             WINDOWS 3.1 .............        WINDOWS 3.1
                   |                               |
                   |                      PKTINT(QVT/NET own)
                   |                               |
                   |                           PKTDRVx
                   +-------------------------------+            
               PKTMUX n
                   |                   
          Packet Driver or SHIM
                   |              
                  DOS 
		   |
            Network Adapter

PC Gopher III, NCSA Telnet over CSLIP under Windows


                                                
                                                   
  PC Gopher III                 NCSA telbin        
       |                             |                         
     PKTDRV1                     PKTDRVn           
       |                             |             
     DOS Session                DOS Session   
       +-----------+-----------------+             
                   |                               
                   +                                            
             WINDOWS 3.1 
                   |                               
                   |                   
                   |                               
                   |                           
                   +           
                PKTMUX n
                   |                   
               CSLIPPER
                   |              
                  DOS
		   |
	      Serial Port  

PC Gopher II and NetWare on a LAN - Alternative I
[Didn't work for me, but it's supposed to be OK]

               NetWare
PC Gopher        |
  III            |
   |             |
DOS Session    NETX
   |             |
 Windows 3.1     |
   |           PDIPX
  WINPKT        /
     \         /
      \       /
       \     /
        \   /
     Packet Driver
          |
	 DOS
          |
     Network Adapter
   

PC Gopher III and NetWare on a LAN - Alternative II

                                  PC-Gopher III
				      |
				  DOS Session
				      |
			          Windows 3.1                 
                                      |
                                      |
                    NetWare            |
                        \            /
                      NETX         WINPKT
                          \        /
                        IPXODI   ODIPKT
                             \   /
                              \ /
			       |
			Link Support Layer
                               |
                            ODI driver
			       |
			      DOS
                               |
                          Network Adapter

WinQVT/Net and PC Gopher II and NetWare over a LAN - Alternative I

PC Gopher      
  III 
   |             Win QVT/Net      
 PKTDRV1            |      
   |                |   
DOS session      Windows 3.1
   |                |
Windows 3.1      PKTINT (QVT/NET own)
   |                |
   |             PKTDRVn
 WinPKT             |
   |                |          NetWare
   +----------------+            |
   |                             |
   |                             |
 PKTMUX n                      NETX
   |                             |
    \                          PDIPX
     \                           |
      \                          |
       \                         |
        \                        |
     Packet Driver --------------+
          |
	 DOS
          |
     Network Adapter

WinQVT/Net, PC Gopher III and NetWare over a LAN - Alternative II
	
	                                         QVT/Net
  PC Gopher III                 NCSA telbin        |
       |                             |             |            
     PKTDRV1        .....        PKTDRVn           |
       |           |                 |             |
     DOS Session                DOS Session    Windows Session
       +-----------+-----------------+             |
                   |                               |                                  
		   |                               |            
             WINDOWS 3.1 .......................WINDOWS 3.1
                   |                               |
                   |                      PKTINT(QVT/NET own)
                   |                               |
                   |                           PKTDRVx
              	   |	                           |      
		   |		                   |
		   |		                   |
		   |		                   |
		   +------------------+------------+
				      |
                    NetWare            |
                        \            /
                      NETX         PKTMUX n (use if >1 TCP/IP app)
                          \        /
                        IPXODI   ODIPKT
                             \   /
                              \ /
			       |
		        Link Support Layer
                               |
                           ODI driver
                               |
			  Network Adapter



PC Eudora and Windows Trumpet over CSLIP under Windows using Trumpet Winsock


 PC Eudora    Windows Trumpet
     \         /
      \       /
       \     /
        \   /
       TCPMAN
          |
     Windows 3.1
	  |
     WINPKT 0x60
          |
         DOS
          |
      Serial Port
      
PC Eudora and Windows Trumpet supporting Ethernet and CSLIP under Windows 
using NDIS supporting stack [Chameleon]

[Please note: this is not possible under Trumpet Winsock, since it can
only handle a single interface; it requires a stack that routes]

 PC Eudora    Windows Trumpet
     \         /
      \       /
       \     /
        \   /
      Chameleon NEWT
          |
      Windows v3.1
          |
	  +------------------+
	  |                  |
    Protocol Manager         |
          |                  |
      NDIS Mac Driver     Serial Port
          |
         DOS
          |
     Ethernet card



PC Eudora, Windows Trumpet, and KA9Q under Windows

       WinTrump   PC Eudora
            \     /
             \   /
 KA9Q         \ /
   |           |
 PKTDRV      TCPMAN
     \         |
      \       /
       \     /
        \   /
	 \ /
        Windows
          |
        PKTDRV 0x62
	  |
        PKTMUX 2
          |
     Packet Driver
          |
         DOS
          |
     Ethernet Card

HGopher, PC Eudora, and WinTrumpet Under Windows
(Whether the TCP/IP stack is loaded before or
after Windows depends on the stack)

       HGopher
         |       
         |
   PC    |
 Eudora  |  WinTrumpet
     \   |   /
      \  |  /
       \ | /
        \|/
       TCPMAN
         |
     Windows 3.1
         |
      WINPKT
         |
  Packet Driver
         |
        DOS
         |
   Ethernet Card

B-15. Strange and wonderful configuration files submitted by readers

Robert Clift (clifta@sfu.ca) writes:

"I have WinQVT/Net 3.4, PC Gopher III (including NCSA DOS Telnet), KA9Q 
(gopher and FTP server), and POPMail all running together under Windows 
over PKTMUX on a 3C503 packet driver (and Ethernet card)."

Here is the stick diagram (yikes!): 

Win/QVTNet 3.7     KA9Q Gopher      PC POPMail 3.2     PC Gopher III 1.01
on interrupt 65    & FTP Server           \                    /
    \                  |                    \                /
      \                |                      \            /
        \              |                        \        /
          \          PKTDRV                       PKTDRV
            \          |                            /
              \      DOS Session               DOS Session
                \      |                        /
                  \    |    -------------------       
                    \  |  /                 
                  Windows 3.1
                       |
                     PKINT
                       |
         PKTDRV on Int 65 no listeners set
                       | 
           PKTMUX 1.2 with 3 channels
                       |
          Clarkson 3C503 Packet Driver
	               |
	              DOS
                       |
           3Com Etherlink II/16 TP
                       |
                    Ethernet

NOTES:

Win/QVTNet must be loaded as the very first Windows application and must be 
kept operating as long as your are in Windows.  It appears that its TCP/IP 
stack does some strange things when it disconnects and kills access to the 
actual packet driver.

I run PC gopher and POPMail alternatively, so they share one channel which 
is allocated via PKTDRV before running the application and deallocated 
after the application is finished (I usually throw in a reset command to 
PMTMUX as well just to be safe).

To explain what is happening (as best I can since a lot of this came from 
experimentation):

1.  The packet driver is loaded
2.  PKTMUX is run over the packet driver in order to multiplex it (in this 
    case three channels).
3.  A virtual packet driver is loaded for Win/QVTNet on interrupt 65 and 
    the packet driver is told that it is not to listen for any server 
    requests.
4.  PKINT is loaded over top of the virtual packet driver
5.  Start Windows and run Win/QVTNet as the first application, it must be 
    kept running throughout the Windows session.
6.  Load a virtual packet driver from a DOS session and start KA9Q.  I use 
    the following batch file to do this:

         c:\network\pktdrv 63 /l
         h:
         cd \
         net091b
         c:\network\pktdrv 63 /uu
         c:\network\pktmux /r

7.  Load a virtual packet driver and run PC Gopher or POPMail as needed.  I 
    use the following batch files for PC Gopher and POPMail respectively:

         c:\network\pktdrv 63
         h:\goph-cli\gopher /T=h:\goph-cli\text /X=h:\goph-cli\binary
         c:\network\pktdrv 63 /uu


         c:\network\pktdrv 66 /c
         h:\popmail\popmail /noems
         c:\network\pktdrv 66 /uu

8.  The only problem seems to be that the NNTP module in Win/QVTNet will 
    not operate correctly if POPMail is operating.  Otheriwse it seems to 
    work okay without too many problems.

C. KA9Q Questions

C-1. What version of KA9Q should I use and where do I get it?

There are so many releases of KA9Q that it is a significant amount of
work just to keep track of them all. This has occurred partly because
KA9Q does not support extended or expanded memory, and therefore many
people have needed to customize it with the features relevant to them
in order to allow it to do what they want as well as fit into memory. 
The primary difference among the various releases is whether they 
include code for a BBS, packet radio support (AX.25), synchronous cards (for
use with leased lines), NNTP, CSO or Gopher servers, packet filtering, DNS,
RIP or PPP support. 

The three primary KA9Q releases at this time are those managed by Ashok Aiyar
(ashok@biochemistry.bioc.cwru.edu), those put out by Demon Internet
Services (DIS), and the JNOS distribution. JNOS is the primary packet radio-
oriented release; the other two major releases do not include AX.25 support.
Since JNOS does not include several features important to non-packet radio
users (DNS/Gopher/CSO server, hop check), try one of the other two releases
if you're not interested in packet radio.

Ashok's release is based on the N1BEE 0.85-beta which in turn 
is based on PA9GRI 2.0m NOS. Version 11c includes support for NTP, CSO,
gopher, FTP, FINGER, HTTP and SMTP/POP2/POP3 servers, plus VT102 and packet 
filtering support. Please not that this release does *not* include radio or 
synchronous card support, unlike the standard KA9Q release, and only support 
SLIP/CSLIP. Also, there is no DNS server support, and the tip command has been 
removed, so that you need to use an external dialer to make the connection.

Available as:

file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.exe, nos11c.txt, 
nos11c.map, nos192.txt, nos_1229.man, vt102.zip, filter.txt, autoexec.nos

The TextWin version from Demon Internet Services includes support for DNS server, packet filtering, FTP, SMTP/POP2/POP3 servers, NNTP server, VT102 support, NTP, BBS, SLIP/CSLIP,PPP (I don't know anyone who has gotten this to work), demand dial, ping, hop
 check (traceroute equivalent). 

From mike@childsoc.demon.co.uk (Michael Bernardi):

"Demon Internet Services have a dialin Internet service in the UK.
They also support a customised version of KA9Q optimised for
dialup, they also support the PCElm mailer, SNEWS news reader and
a customised front end. There is also a combined NEWS and MAIL
program called CPPNEWS and an alternative MAIL program called
VIEW, these last are unsupported by Internet@demon.co.uk but other
DIS users do support them. All these programs can be found on
ftp.demon.co.uk in the pub/ibmpc/ directory, and are written to
work with KA9Q (specifically the DIS version)."

Anthony McCarthy has added a multi-windowing system to KA9Q that 
supports the mouse, which has been recommended. See Resource 
listings for info. 

The DIS release includes three versions, small, medium and large. 
The large version includes everything but the kitchen sink, including
an NNTP server. I also believe it includes the KA9Q BBS code, and
radio support. 

Editorial: To my mind, the time has come for the major releases to combine 
their code bases and produce a version with the best features of all of them. 
To my mind, the ideal KA9Q release would be a release combining the improved server support of the CWRU release with a working PPP implementation, demand 
dial, and DNS server support. 


C-2. What do I need to run KA9Q? Why won't it do VT-100 emulation?

KA9Q is usually run from a startup script, such as my script
startnos.bat:

\nos\drivers\8003pkdr
\nos\net -d \nos

Here I first load the packet drivers for my 8003 Ethernet card, then
run KA9Q (known as net.exe).

The KA9Q package then reads commands from a configuration file, called
AUTOEXEC.NOS in some implementations, AUTOEXEC.NET in others. 

For VT100 emulation with KA9Q, try using Giles Todd's VT102.COM,
available via ftp from ftp.demon.co.uk, cd /pub/ibmpc/DIS.

C-3. How do I configure KA9Q as a SLIP dialup connection?

Here is a sample CSLIP only configuration file:

# Set the host name
#
hostname aboba.slip.netcom.com
ip address [192.187.134.3]
#
#
#
# Configure COM3 on Interrupt 5, at 38400 bps with
# RTS/CTS (c) and Van Jacobson Compression (v) and MTU = 1008
#
attach asy 0x3e8 5 VJSLIP sl0 8092 1008 38400 cvj
ifconfig sl0 netmask 255.255.255.252
#
#
#
route add default sl0
# route all packets over sl0 by default (sl0 is the route to
# the Internet)
#
# Time To Live is the maximum number of hops a packet can take
# before it is thrown away.  This command prevents an inadvertent
# infinite loop from occuring with packets in the network.
#
ip ttl 255
#
#-------------------------------------------------
#
# The Maximum Segment Size is the largest single transmission that
# you care to receive.  An mss of 216 will force folks to send you
# packets of 256 characters or less (counting the overhead). 
#
tcp mss 1048
#
#-------------------------------------------------
#
# The Window parameter establishes the maximum number of bytes that
# may be outstanding before your system expects an ack.  If window is
# twice as big as mss, for example, there will be two active packets
# on the channel at any given time.  Large values of window provide
# improved throughput on full-duplex links, but are a problem on the
# air.  Keep mss <= window <= 2*mss if you're on the air.
#
#
tcp window 6888
#
#-------------------------------------------------
#
# This entry will open net.log in the \spool directory and will
# record the server activity of your system.  If you don't want a log,
# comment out this line; if you do, make sure you have a \spool
# directory!
#
log \spool\net.log
#
#-------------------------------------------------
#
# Each of the servers (services you will provide) must be turned
# on before they will be active.  The following entries turn all
# of them on.  To turn any function off use the command 'stop' after
# NET gets fired up, or just comment out the line here.
#
start ftp
start echo
start discard
#start telnet
start smtp
#
isat on
#
domain addserver 192.100.81.101
domain addserver 192.100.81.105
smtp gateway 140.174.7.1
#
#
#  Display Name and IP Address
#
hostname
ip address
#
# Just for yucks, lets try calling the other end.
comm sl0 atdt14082411528
# THE END

After executing this setup file, if your version of KA9Q supports
the comm command you should hear the modem dial out
to your SLIP host. Enter TIP sl0 at the prompt to be connected to the
SLIP interface. You will then see your hosts's login prompt. Give
the login name and password, and when you go into SLIP mode, hit
F10 to get back to the prompt. Note that newer versions of KA9Q
may not be compatible with the comm command, since they support
more sophisticated dialing scripts. 

Type RESET 1 at the prompt. This moves session 1 from tip mode into
SLIP mode. Type another RESET to kill any residual processes that
may be operating.  

At this point you should have a functioning connection. You might
try to ping your host via the command:
PING <host adddress>
If this works, you will then see the round trip time to your host,
in milliseconds. 

Other possible diagnostic commands:

ASYSTAT <interface>	Gives statistics on packets received, sent, etc.
TRACE <interface> 1011	Shows incoming characters
RIP TRACE 1		Traces RIP packets
HOP CHECK <address>	Traces the route to the designated system. Useful 
			for figuring out routing problems. 


C-4. How do I configure KA9Q as a router?

The KA9Q configuration that follows uses two interfaces, one a CSLIP
interface to an annex terminal server (sl0), the other an Ethernet
interface (lan) with another machine (a NeXT) attached.

Note the use of Van Jacobson compression (v) on the slip line, as well 
as the strange interrupt settings (Interrupt 5, port is COM3).  One of 
the nice things about KA9Q is that it is flexible enough to deal with 
such situations.

Here is a sample router configuration file:

# Set the host name
#
hostname gate.slip.holonet.net
#
#
# Configure COM3 on Interrupt 5, at 38400 bps with
# RTS/CTS (c) and Van Jacobson Compression (v)
#
attach asy 0x3e8 5 VJSLIP sl0 8092 576 38400 cv
ifconfig sl0 ipaddress [157.151.0.253] netmask 255.255.255.0
#
# FTP, Inc., compatible packet driver installed at software interrupt number
# 0x60; probably an Ethernet card of some kind.
#
attach packet 0x60 lan 2 1500
ifconfig lan ipaddress [157.151.64.1] netmask 255.255.255.0
#
route add default sl0
# The local Ethernet has a Class C network address so
# route all IP addresses beginning with 157.151.64 to it.
route add 157.151.64/24 lan
#
#
# Time To Live is the maximum number of hops a packet can take
# before it is thrown away.  This command prevents an inadvertent
# infinite loop from occuring with packets in the network.
#
ip ttl 400
#
#-------------------------------------------------
#
# The Maximum Segment Size is the largest single transmission that
# you care to receive.  An mss of 216 will force folks to send you
# packets of 256 characters or less (counting the overhead). 
#
tcp mss 576
#
#-------------------------------------------------
#
# The Window parameter establishes the maximum number of bytes
# that may be outstanding before your system expects an ack.
# If window is twice as big as mss, for example, there will be two
# active packets on the channel at any given time.  Large values of
# window provide improved throughput on full-duplex links, but are a
# problem on the air.  Keep  mss <= window <= 2*mss if you're on the air.
#
#
tcp window 6888
#
#-------------------------------------------------
#
# This entry will open net.log in the \spool directory and will
# record the server activity of your system.  If you don't want a log,
# comment out this line; if you do, make sure you have a \spool
# directory!
#
log \spool\net.log
#
#-------------------------------------------------
#
# Each of the servers (services you will provide) must be turned
# on before they will be active.  The following entries turn all
# of them on.  To turn any function off use the command 'stop' after
# NET gets fired up, or just comment out the line here.
#
start ftp
start echo
start discard
#start telnet
start smtp
#
isat on
#
domain addserver 157.151.0.2
domain addserver 157.151.0.1
smtp gateway 157.151.0.2
#
#
# Use Router Information Protocol (RIP) to inform the router at
# 157.151.0.253 about the existence of the local network. Send
# RIP packets every 240 seconds.
rip add 157.151.0.253 240
#
#
# Just for yucks, lets try calling the other end...
#
comm sl0 atdt7041063
#
# THE END

Here is another routing configuration file, using proxy arp:

# Set the host name
#
hostname gate.slip.holonet.net
#
#
# Configure COM3 on Interrupt 5, at 38400 bps with
# RTS/CTS (c) and Van Jacobson Compression (v)
#
attach asy 0x3e8 5 VJSLIP sl0 8092 576 38400 cv
ifconfig sl0 ipaddress [157.151.0.253] netmask 255.255.255.0
#
# FTP, Inc., compatible packet driver installed at software interrupt number
# 0x60; probably an Ethernet card of some kind.
#
attach packet 0x60 lan 2 1500
ifconfig lan ipaddress [157.151.64.1] netmask 255.255.255.0
#
#  Set Routing Tables
#
#
route add default sl0
# The local Ethernet has a Class C network address so
# route all IP addresses beginning with 157.151.64 to it.
route add 157.151.64/24 lan
#
#  Use Proxy ARP
#
arp publish 157.151.64.1 ether 00:00:c0:33:f3:13
arp publish 157.151.64.254 ether 00:00:c0:33:f3:13
#
#  For PC AT
#
isat on
#
# Add Domain Name Servers
#
domain addserver 157.151.0.2
domain addserver 157.151.0.1
smtp gateway 157.151.0.2
#
#
# Time To Live is the maximum number of hops a packet can take
# before it is thrown away.  This command prevents an inadvertent
# infinite loop from occuring with packets in the network.
#
ip ttl 400
#
#-------------------------------------------------
#
# The Maximum Segment Size is the largest single transmission that
# you care to receive.  An mss of 216 will force folks to send you
# packets of 256 characters or less (counting the overhead). 
#
tcp mss 576
#
#-------------------------------------------------
#
# The Window parameter establishes the maximum number of bytes
# that may be outstanding before your system expects an ack.
# If window is twice as big as mss, for example, there will be two
# active packets on the channel at any given time.  Large values of
# window provide improved throughput on full-duplex links, but are a
# problem on the air.  Keep  mss <= window <= 2*mss if you're on the air.
#
#
tcp window 6888
#
#-------------------------------------------------
#
# This entry will open net.log in the \spool directory and will
# record the server activity of your system.  If you don't want a log,
# comment out this line; if you do, make sure you have a \spool
# directory!
#
log \spool\net.log
#
#-------------------------------------------------
#
# Each of the servers (services you will provide) must be turned
# on before they will be active.  The following entries turn all
# of them on.  To turn any function off use the command 'stop' after
# NET gets fired up, or just comment out the line here.
#
start ftp
start echo
start discard
#start telnet
start smtp
#
#  Display Name and IP Address
#
hostname
ip address
#
# Just for yucks, lets try calling the other end.
comm sl0 atdt7041063
# THE END

C-5  How do I get KA9Q to support BOOTP?

The CWRU NOS version has a working BOOTP client and server built-in,
and is the best version if you are looking for BOOTP support. If
you are using another version of KA9Q that does not support BOOTP,
try the following: 

Steven L. Johnson (johnson@TIGGER.JVNC.NET) notes:

  KA9Q does have a bootp client but it is not compiled in by default.
  It has a bug that truncates the returned ip address to 16 bits
  which must be corrected before it will work.  It also complains
  about bootp servers that only support RFC 951 bootp without RFC
  1084 (or 1048) vendor extensions.  Other than that it seems to work
  for me.

  To enable the bootp client, add the following line to config.h:

    #define BOOTP 1

  To correct the ip address truncation problem, in bootp.c change:

                Ip_addr = (int) reply.yiaddr.s_addr;    /* yiaddr */
                          ^^^^^problem
  at line 188 to:

                Ip_addr = (int32) reply.yiaddr.s_addr;    /* yiaddr */
                          ^^^^^^^solution

  And of course, recompile.

  This worked on the src1229 (1991) version and may work on the
  most recent version.  I did check to make sure that the bug still
  exists, but I haven't rechecked whether there are additional
  problems in the new version.



C-6.  How do I get KA9Q to support PPP?

Although I haven't gotten this to work yet, there is hope. 
The only major version of KA9Q supporting PPP is the TextWin version.
Here is a sample ppp configuration file for it: 

# Set the host name
#
hostname aboba.slip.netcom.com
ip address [192.187.134.3]
#
#
#
# Configure COM3 on Interrupt 5, at 38400 bps with
# MTU = 1008
#
attach asy 0x3e8 5 ppp pp0 8092 1008 38400
dialer pp0 dialer.ppp
ifconfig pp0 netmask 255.255.255.252
ppp pp0 trace 2
ppp pp0 quick
ppp pp0 lcp open
ppp pp0 ipcp open
#
#
#
route add default pp0
# route all packets over pp0 by default (pp0 is the route to
# the Internet)
#
# Time To Live is the maximum number of hops a packet can take
# before it is thrown away.  This command prevents an inadvertent
# infinite loop from occuring with packets in the network.
#
ip ttl 400
#
#-------------------------------------------------
#
# The Maximum Segment Size is the largest single transmission that
# you care to receive.  An mss of 216 will force folks to send you
# packets of 256 characters or less (counting the overhead). 
#
tcp mss 1048
#
#-------------------------------------------------
#
# The Window parameter establishes the maximum number of bytes that
# may be outstanding before your system expects an ack.  If window is
# twice as big as mss, for example, there will be two active packets
# on the channel at any given time.  Large values of window provide
# improved throughput on full-duplex links, but are a problem on the
# air.  Keep mss <= window <= 2*mss if you're on the air.
#
#
tcp window 6888
#
#-------------------------------------------------
#
# This entry will open net.log in the \spool directory and will
# record the server activity of your system.  If you don't want a log,
# comment out this line; if you do, make sure you have a \spool
# directory!
#
log \spool\net.log
#
#-------------------------------------------------
#
# Each of the servers (services you will provide) must be turned
# on before they will be active.  The following entries turn all
# of them on.  To turn any function off use the command "stop" after
# NET gets fired up, or just comment out the line here.
#
start ftp
start echo
start discard
#start telnet
start smtp
#
isat on
#
domain addserver 192.100.81.101
domain addserver 192.100.81.105
smtp gateway 140.174.7.1
#
#
#  Display Name and IP Address
#
hostname
ip address
#
# THE END

In file dialer.ppp:

control down
wait 1000
control up
wait 1000
wait 2000
send "at\r"
wait 3000 "OK"
send "atdt8659004\r"
wait 60000 "login: "
send "<userID>\r"
wait 5000 "word:"
wait 1000
send "<password>\r"

C-7. How do I get KA9Q to support SLIP dialin?

If you are willing to settle for little or no security, there is not
much you have to change to allow a KA9Q system to receive calls, as
opposed to originating them. These should include:

1. Setting the system to autoanswer, via use of the ATS0=1 command to
the modem. 

2. Setting up a trace on the router end, to figure out if it's working,
via the command:
TRACE <interface> 1011, where <interface> = sl0 for SLIP, or another
value such as LAN or ether0 for the Ethernet interface. It's probably
a good idea to put a trace on all interfaces until the system is
shaken down. 

Note that without addition of a special dialing script, this setup
is completely insecure! 


C-8.  Can I use KA9Q as a packet filter? 

Yes! Both the TextWin Large and CWRU NOS versions support this. You can
filter by incoming or outgoing, TCP or UDP port number, IP address, SYN
bit on, etc. 


D. Hints for particular packages

D-1. How do I get DesQView X to run over the network?

V1.0 of DesQView X did not include a TCP/IP protocol stack.
Surprise! It required a TCP/IP implementation such as Beame & Whiteside,
PC-NFS, FTP's PC/TCP, or Novell LWP. They've corrected the situation 
in subsequent revisions. Contact QuarterDeck for assistance.

[pricing and availability, anyone?]

D-2. Why is NFS so slow compared with FTP?

NFS usually runs over RPC via UDP, rather than utilizing TCP. NFS only 
acknowledges a write request when the disk completes; there
are no sliding windows as in TCP. This makes NFS fairly inefficient.

Frances K. Selkirk (fks@vaxeline.ftp.com ) notes:

"There are NFS implementations that use TCP. They are only
faster over WANs. UDP is faster over most normally functioning LANs.
The lockstep paradigm is inherent to NFS, but some implementations
provide the ability to violate it - a speed win when the net is
reliable, a loss when it is not.

Whatever the transport, NFS will have more overhead than TCP, because
it is trying to transparently imitate an OS, and has to do a lot of
shuffling and translating."


D-3. Where can I get information on running NetWare and TCP/IP
      concurrently? 
      
The bit.listserv.novell group regularly posts a FAQ
which includes information on concurrent use of TCP/IP and Novell
IPX. 

D-4. What NetWare TCP/IP NLMs are out there and how do I get them
      to work? 

A public and known to work reliable TFTP and BOOTP daemon for NetWare
OS 3.1x/4.0x and NetWare/IP are available from ftp.novell.de at
~/pub/netwire/unsupported/server/bootpd.exe. Contact: dirk@rhein-main.de

D-5. How do I get a telecom package supporting Int 14h redirection
      to work? 

INT 14 is the BIOS serial port interrupt. "Int 14h redirection" means
that Interrupt 14 is redirected to a Telnet connection to a 
particular host. This is useful because it allows a communications 
application to readily support telnet. Int 14h support is becoming 
increasing common, with vendors such as Mustang (QMODEM Pro) and
Procomm Plus for networks having included this feature. 

Aside from commercial stacks (such as FTP's PC/TCP),
try the TCPPORT program in WATTCP, available via ftp
dorm.rutgers.edu, get /pub/msdos/wattcp/apps.zip. However, I have
tried to get this to run with QMODEM Pro and found that I didn't
have enough RAM.

FTP's PC/TCP includes a program called tnglass that supports Int 14h
redirection.

D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP?

Rumour has it that there is a serial NDIS driver available called
NBR11. This is available via ftp complab.gtri.gatech.edu, 
cd /pub/lanman/ndis.  

D-7. How do I get Windows For Workgroups to work alongside NetWare?

ODINSUP from Novell is an NDIS over ODI shim. This allows you to run 
software requiring ODI drivers, as well as software requiring NDIS 
drivers. Since IPX and TCP/IP are different protocols, you will not
need to run PKTMUX. 

Available via ftp.novell.com, 
cd /netwire/novfiles/client.kit/doswin/files/WSDOS1.EXE. 

D-9. How come package X doesn't support the AppleTalk packet driver?

An AppleTalk driver is available as appletlk.com as part of the Crynwr 
driver set. NCSA Telnet 2.3.03 and NuPOP support it, but very few other
applications do, including Trumpet Winsock. This is because AppleTalk
corresponds to packet driver class 5, while most applications only
support Class 1 (Ethernet). 

Vendors with Windows Sockets implementations that support AppleTalk include
FTP Software's PC/TCP. WinQVT/Net's built-in TCP/IP stack version is also
rumored to be due to support AppleTalk in a future release.


D-10. NCSA Telnet doesn't reassemble fragments. What should I do?

Yell at the folks at NCSA to fix the problem, and to notify all
the people who are using the same TCP/IP code to insert the fix in
their software as well. This problem is really common, and
very annoying, and affects NCSA Telnet as well as PC Gopher III,
and POPmail. One possible workaround is to set the MTU to 576,
but this will not always work.

The following solution has been provided by Matthew T
Kaufman (matthew@echo.com):

How to get rid of the message:
"IP: fragmented packet received, frags not supported"
(assuming you have a C compiler and source code)
by Matthew T Kaufman (matthew@echo.com)

Many people on the net have complained that NCSA Telnet
(among other useful PC TCP/IP programs) doesn't properly handle 
fragmented IP packets. this problem becomes especially evident if 
any of your packets are arriving over SLIP connections.
I figured that the fastest way to get it to work would be to go
ahead and do it myself rather than wait for it to get to the
top of the list of desired features.

MANY other programs have used the NCSA TCP/IP implementation, so
if you maintain a program which does, PLEASE add this fix.
I (and MANY OTHERS) are unable to use your software until you do.

I posted the basic form of this fix around the beginning of the year,
but it didn't seem to make it into several subsequent versions of
related software, so I am posting and mailing this once again, in
a revised form, with helpful hints at the end.

I request only the following in return:
    This software revision is in the public domain. It may be
    used anywhere without further permission from the author.
    Please credit the origin of the fix in your release notes
    or bug fix document. (I am "Matthew Kaufman, matthew@echo.com")
    If you are the official maintainer of a software package
    which you have added this fix to, please send me an
    email note letting me know that the fix made it in.
    (So I don't need to worry that, for instance, the next
    version of NCSA Telnet or WinQVT/Net isn't going to
    include this) And, please add this fix as soon as possible.

So here's my fix:

The following are the changes to the NCSA Telnet TCP/IP engine to add
support for IP fragment reassembly. I also know how to make telnet compile 
properly under Borland C without running out of space in DGROUP (see the end of this)

if you have any questions, you can reach me at:
matthew@echo.com. I am willing to help, within the limits of my schedule.

changes follow:

file: engine\ip.c (the only file that needs to change)

delete the following:
>/*
>*  We cannot handle fragmented IP packets yet, return an error
>*/
>
>    if(p->i.frags &0x20) {           /* check for a fragmented packet */
>        netposterr(304);
>        return(1);
>      }

----------
after the line:
>    iplen-=hlen;

but before the lines:
> /*
> *  check to make sure that the packet is for me.


add this:

	/* check for fragment and handle. note that the &0x20 above is WRONG */
    if(p->i.frags)           /* NOW check for a fragmented packet - mtk add*/
    {
	ipfraghandle(p,iplen);	/* pass in computed iplen to save time */
        return(1);
      }

----------
and then, at the end of that file (ip.c) add this:

/*
* IP Fragment Reassembly Hack
* by Matthew T Kaufman (matthew@echo.com)
* 1/1993, 8/1993
*/

typedef struct ipb {
        DLAYER d;
        IPLAYER i;
        uint8 data[4104];	/* "Big Enough" */
}FIPKT;

#define IPF_CHUNKS 513 /* 4104 / 8 */
#define IPF_BITWORDS 18  /* 513 / 32 round up + 1*/
#define IPF_BUFFERS 7  /* Max # of different fragmented pkts in transit */

typedef struct {
	FIPKT pkt;
	unsigned long bits[IPF_BITWORDS];
	int lastchunk;
	unsigned long lasttime;
	unsigned int iplen;
}FPBUF;

static FPBUF far Frag[IPF_BUFFERS];

ipfraghandle(IPKT *p, int iplen)
{

	uint16 fraginfo;
	uint16 foffset;
	uint16 iden;
	FPBUF far *buf;
	int i;

	fraginfo = intswap(p->i.frags);
	foffset = fraginfo & (0x1fff);
#define morefrags (fraginfo & (0x2000))

	iden = intswap(p->i.ident);

/* we already KNOW that this IS fragmented */
/* see if we can find any friends who've already arrived... */

	buf = (FPBUF *) 0L;
	for(i=0; i<IPF_BUFFERS; i++)
	{
		if(p->i.ident == Frag[i].pkt.i.ident)
		{
			buf = &(Frag[i]);
			goto foundfriend;
		}
	}
	/* otherwise, we must be the first one here */
	{	
		long oldtime = 0x7fffffff;
		int oldest = 0;

		for(i=0; i<IPF_BUFFERS; i++)
		{
			if(Frag[i].lasttime == 0)	/* unused buffer? */
			{
				buf = &(Frag[i]);
				goto foundempty;
			}

			if(Frag[i].lasttime < oldtime)	/* track LRU */
			{
				oldtime = Frag[i].lasttime;
				oldest = i;
			}
		}

		/* if we're here, we need to reuse LRU */

		buf = &(Frag[oldest]);

foundempty:	;
		/* initialize new buffer */
		/* time will be filled in later */

		for(i=0; i<IPF_BITWORDS; i++) buf->bits[i] = 0L; /* reset */
		buf->lastchunk = 0;	/* reset */
		/* fill in the header with the current header */
		movmem(p,&(buf->pkt), sizeof(DLAYER) + sizeof(IPLAYER) );
	}

		
foundfriend: ;

	/* now, deal with this specific fragment... */
	/* copy data */
	movmem(&(p->x.data),&(buf->pkt.data[8 * foffset]),iplen);
	/* update rx chunks information */
	for(i=foffset; i<= (foffset+(iplen / 8)); i++)
	{
		buf->bits[i/32] |= (unsigned long) (1L<<(i % 32));
	}

	if(!morefrags)
	{
		/* now we can tell how long the total thing is */
		buf->iplen = (8*foffset)+iplen;
		buf->lastchunk = foffset;
			/* actually, lastchunk is more than this, but it */
			/* IS true that we only need to check through    */
			/* this foffset value to make sure everything has */
			/* arrived  -mtk */
	}

	/* now touch the time field, for buffer LRU */
	buf->lasttime = clock();

	/* check to see if there are fragments missing */

	if(buf->lastchunk == 0)
	{
		/* we haven't even gotten a fragment with a cleared MORE */
		/* FRAGMENTS flag, so we're missing THAT piece, at least */
		return 1;
	}
	for(i=0; i<= buf->lastchunk; i++)
	{
		/* scanning to see if we have everything */
		if(0 == ((buf->bits[i/32]) & (unsigned long)(1L<<(i % 32))) )
		{
			return 1;	/* still waiting for more */
		}
	}

	/*  otherwise, done waiting... use the packet we've gathered */
	/* first clear stuff from fragment buffer: */
	buf->lasttime = 0L;	/* mark as free to take */
	buf->lastchunk = 0;	/* need to do this, because we use it as flag */
	buf->pkt.i.ident = 0;	/* so we don't find this later */
	buf->pkt.i.frags = 0;	/* in case anybody above us checks */
	/* then send it on its way... */

    if(!comparen(nnipnum,p->i.ipdest,4)) {     /* potential non-match */
        if(comparen(nnipnum,junk,4) && p->i.protocol==PROTUDP)
            return(udpinterpret((UDPKT *)p,iplen));
        return(1);              /* drop packet */
      } /* end if */

   	switch (buf->pkt.i.protocol) {        /* which protocol */
        	case PROTUDP:
            	return(udpinterpret((UDPKT *)&(buf->pkt),buf->iplen));
		
        	case PROTTCP:
            	return(tcpinterpret((TCPKT *)&(buf->pkt),buf->iplen));  
		
        	case PROTICMP:
        	return(icmpinterpret((ICMPKT *)&(buf->pkt),buf->iplen));
		
       	default:
       		netposterr(303);
       		return(1);
  	}

}

*** helpful hint:

if you run out of space in DGROUP, its because your compiler doesn't
place each 'far' data object in its own segment. To make things work,
you need to make the raw packet buffer be in its own segment.
Here's how:
in include/pcdefs.h search for:

-->  unsigned char far raw[17000];

 (the 17000 might be some other number... smaller, if someone tried to
  fix this before)
 and change to

-->  unsigned char far raw[17000]={0,0};	/* force into own segment */  
 

E. Information for developers

E-1. What publicly distributable TCP/IP stacks are there that I can
     use to develop my own applications?

In writing an application, you can use device drivers provided by
particular vendors, or you can opt for an Application Binary Interface (ABI) 
that supports multiple TCP/IP protocol stacks, such as Winsock. For a given 
version of Windows, Winsock is an ABI for both Windows 3.x and Windows NT 
(via the NT Win16 subsystem).

Device drivers are included with PC-NFS and Beame & Whiteside's
BW-TCP.  Free examples of ABIs are the WATTCP API, the NCSA API
(public domain), the Trumpet ABI from Peter Tattum, and the NuPOP ABI.

All major TCP/IP vendors have by now implemented Windows Sockets.

E-2. Where can I get a copy of the Windows Sockets FAQ?

A separate developer-oriented FAQ file about Windows Sockets created
by Mark Towfiq is available on
SunSite.UNC.EDU:/pub/micro/pc-stuff/ms-windows/winsock/FAQ
and Microdyne.COM:/pub/winsock/FAQ

An alternative source for the FAQ is ftp.microsoft.com.


------------------------------ END OF PART 1 ------------------------

Please send comments to:

Bernard Aboba
Author of:
The Online User's Encyclopedia, Addison-Wesley, 1993
The PC-Internet Connection, Publisher's Group West, 1994 
email: aboba@netcom.com
WWW page: http://www.zilker.net/users/internaut/index.html



-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 17:40:01 GMT
From:      aboba@netcom.com (Bernard Aboba)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.answers,news.answers
Subject:   comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 2 of 3

Archive-name: ibmpc-tcp-ip-faq/part2

comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 2, 7/1/94

*********** QUICKIE Guide to Useful Stuff ************

Drivers

Packet drivers: file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip
                file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip
Packet specs:   file://vax.ftp.com/pub/packet-d.ascii
NDIS specs:     file://vax.ftp.com/pub/ndis-mac.v101.txt
                file://vax.ftp.com/pub/ndis-mac.v201.txt
ODI driver info:     
                file://sjf-lwp.novell.com/anonymous/dev_docs/lan_drv/*, 
ODI Protocol stack info: 
                file://sjf-lwp.novell.com/anonymous/dev_docs/pstacks/* 
Slipper:        file://ftp.utas.edu.au/pc/trumpet/slipper/slipper.zip
PKTMUX:         file://dorm.rutgers.edu/pub/msdos/wattcp/pktmux12.exe
EtherPPP:       file://merit.edu/pub/ppp/etherppp.zip
GoSLIP:	        file://ftp.cdrom.com/.5/cica/winsock/goslip11.zip
ODIPKT:         file://hsdndev.harvard.edu/pub/odipkt/odipkt.com
Config file:    file://hsdndev.harvard.edu/pub/odipkt/net.cfg
Readme file:    file://hsdndev.harvard.edu/pub/odipkt/readme

Winsock Applications
 
Trumpet Winsock:
                file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winsock.zip
                file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip
                file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winapps.zip
                file://ftp.utas.edu.au/pc/trumpet/winsock/winapps.zip
Trumpet Newsreader: 
                file://biochemistry.bioc.cwru.edu/pub/wintrumpet/wtwsk10z.zip
HGopher:        file://lister.cc.ic.ac.uk/pub/wingopher/hgopher2.4.zip
Voice Chat:     file://ftp.cica.indiana.edu/pub/pc/win3/winsock/IVC10.ZIP
PCEudora:       file://ftp.cdrom.com/.5/cica/winsock/eudora14.exe
WinFTP:	        file://ftp.cdrom.com/.5/cica/winsock/winftp.zip
WinTalk:	file://ftp.cdrom.com/.5/cica/winsock/wtalk11.zip
GoSLIP:	        file://ftp.cdrom.com/.5/cica/winsock/goslip11.zip
3270:           file://ftp.ccs.queensu.ca/pub/msdos/tcpip/qws-3270.zip
PhWIN:	        file://ftp.cdrom.com/.5/cica/winsock/phwin22.zip
FTP client:     file://ftp.usma.edu/pub/msdos/winsock.files/ws_ftp.zip
EINet WAIS:     file://ftp.einet.net/einet/pc/EWAIS200.ZIP
Finger:         file://ftp.cica.indiana.edu/pub/pc/win3/winsock/finger31.zip
Dialer:         file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip
WinQVTNet:      file://biochemistry.cwru.edu/pub/qvtnet/
Mosaic:         file://ftp.ncsa.uiuc.edu/PC/Mosaic/wmos20a5.zip, win32s.zip, readme.now
WinTelnet:      file://ftp.ncsa.uiuc.edu/Telnet/windows/executables/wtel1b1.zip
MPEG Viewer:    file://ftp.ncsa.uiuc.edu/PC/Mosaic/viewers/mpegw32c.zip
Windows Quicktime:    
                file://lister.cc.ic.ac.uk/pub/wingopher/viewers/movies/qtwplay.zip
Windows sound player:    
                file://lister.cc.ic.ac.uk/pub/wingopher/viewers/audio/wnplny09b.zip
Cello:          file://ftp.law.cornell.edu/pub/LII/Cello/cello.zip, cellofaq.zip
Viewers:        file://ftp.law.cornell.edu/pub/LII/Cello/viewers.zip
Windows W3 server:        
                file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/serweb03.zip
JPEG Viewer:    file://ftp.law.cornell.edu/pub/LII/Cello/lview31.zip
GIF Viewer:     file://ftp.law.cornell.edu/pub/LII/Cello/wingif14.zip
Wham viewer:    file://ftp.law.cornell.edu/pub/LII/Cello/wham131.zip
Ghostscript:    file://ftp.law.cornell.edu/pub/LII/Cello/gswin.zip
X Windows Demo: file://ftp.cica.indiana.edu/pub/pc/win3/uploads/xwindemo.zip

Windows NT servers

W3 server:      file://emwac.ed.ac.uk/pub/https/HSI386.ZIP
WAIS server:    file://emwac.ed.ac.uk/pub/waistool
Gopher server:  file://emwac.ed.ac.uk/pub/gophers/GSI386.ZIP
FTP server:     file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/nt-ftpd.zip

DOS Applications

Minuet:         file://boombox.micro.umn.edu/pub/pc/minuet/latest/minuarc.exe, install.txt
PC-Pine:        file://ftp.cac.washington.edu/mail/PC-PINE/pcpine_p.zip
NCSA Telnet:    file://merit.edu/pub/ppp/pc/ncsappp.zip
KA9Q:           file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.exe, nos11c.txt, nos192.txt
NOS View:       file://ucsd.edu/hamradio/packet/tcpip/nosview/nosvw304.zip
NUPOP:          file://ftp.acns.nwu.edu/pub/nupop/nupop201
Minuet:         file://boombox.micro.umn.edu/pub/pc/minuet/minuarc.exe
PC Pine:        file://ftp.cac.washington.edu/mail/pcpine_p.zip
NCSA Telnet:    file://mer.edu/pub/ppp/ncsappp.zip
 
******************************************************

RESOURCE LISTING

Key

Downright speculation = I have not used this product personally, nor 
has anyone I know.  However, the specifications sounded interesting, 
so it's included.

Suggestion = I have not used this enough to pass judgement, but it 
has come to me recommended by someone I respect.

Recommendation = I use this package regularly, and like it.

BOOKS

Downright speculation
NOSIntro - An Introduction to the KA9Q Network Operating System
Price: 11.50 Pounds sterling, plus postage and handling.
U.S. price, including shipping:  17.34 pounds sterling

This book by Ian Wade (author of NOSView) thoroughly covers
KA9Q. Publisher is Dowermain, 356 pages, 35 chapters, 6 appendices,
illustrated. ISBN 1-897649-00-2.

Dowermain, Ltd., 7 Daubeney Close, Harlington, DUNSTABLE, Bedfordshire, 
LU5 6NF, United Kingdom, email  ian@g3nrw.demon.co.uk. Written orders only, 
no U.S. distributor yet.

Recommendation
InfoPOP - Guide to Internet Resources	Free

InfoPOP/Windows is a smallish guide to the Internet in the form of a 
Windows Help application. InfoPOP/DOS is a TSR with the same content. 

Available via ftp gmuvax2.gmu.edu, or the fenwick.gmu.edu gopher
 Computers/Info-Technology/Software
  |___under Software available on this  Gopher

 MAILING LISTS

Windows Sockets

winsock-request@microdyne.com
winsnmp-request@microdyne.com

W3 for Windows

mail LISTSERV@fatty.law.cornell.edu, with

         sub cello-l your full name

in the body of the message. 

Firewalls

mail majordomo@greatcircle.com, with
        sub firewalls-digest 

in the body of the message. Back issues
are available at ftp.greatcircle.com:/pub/firewalls.digest/vNN.nMMM.Z
where NN is the volume number and MMM is the issue number. 

SNMPv1 list

mail snmp-request@psi.com, subject: subscribe, 
body: youraddress@yourhost.domain

SNMPv2 list

mail snmpv2-request@tis.com, subject: subscribe, 
body: youraddress@yourhost.domain

Novell mailing list

mail listserv@suvm.acs.syr.edu
body: subscribe NOVELL <Your Full Name>

CUTCP mailing list

mail listserv@nstn.ns.ca
body: sub cutcp-l <Your Full Name>

 
PUBLICLY DISTRIBUTABLE SOFTWARE

Key

Recommendation = I use, or have used this software or 
equipment, and I like it. 

Suggestion = I have not used this software, but it has been 
recommended to me by people that I trust. 

Downright Speculation = Neither myself nor anyone I know 
has used this, but it claims to offer interesting 
capabilities, so it's included. 

If you don't have access to FTP, you can retrieve the 
files via e-mail, using the following mail servers: 

FTPmail

ftpmail@decwrl.dec.com
ftpmail@ftp.uni-stuttgart.de
ftpmail@grasp.insa-lyon.fr
ftpmail@doc.ic.ak.uk

BITFTP (available to BITNET users only)

bitftp@vm.gmd.de
bitftp@plesarn.edu.pl
bitftp@pucc.princeton.edu

DRIVERS AND SHIMS

Recommendation
Crynwr drivers	free
Support	Contact Crynwr for info	

The Crynwr drivers, formerly known as the Clarkson University 
CUTCP drivers, are created by Russ Nelson of Crynwr Software, 
which sells packet and other driver support. The Crynwr 
drivers support many Ethernet adapter boards, including 
those from 3COM, Telesystems, AT&T, Digital, Mitel, HP, 
BICC, NCR, Novell, Interlan, MICOM, Racal/Interlan, NTI, 
Tiara, Ungermann-Bass, and Western Digital. 

The Packet Driver Specification v1.09 is available via:
file://vax.ftp.com/pub/packet-d.ascii, packet-d.mss

Drivers available at:
file://ftp sun.soe.clarkson.edu/pub/packet-drivers/drivers.zip,
drivers1.zip, drivers2.zip 
 
PC-NFS drivers available in
file://ftp.sun.soe.clarkson.edu/pub/packet-drivers/compat.zip 
(requires Sun's PC-NFS).

The drivers, currently in release 11 are available at:
file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip (executables)
file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11a.zip (sources)
file://oak.oakland.edu/pub/msdos/pktdrvr/pktdt11b.zip (sources)
file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip (executables)
file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip (additional executables and sources)

Crynwr Software, 11 Grant St., Potsdam, NY 13676, 
(315)268-1925, fax: (315)268-9201, email: nelson@Crynwr.com

*Downright speculation
Drivers for Western Digital Ethernet Boards free

Available as:
file://ftp.cdrom.com/.2/SimTel/msdos/lan/wdpost.zip

Recommendation
NDIS Drivers	free

Libraries of free NDIS drivers for DOS and OS/2 are 
available at FTP Software, Inc. at
file://vax.ftp.com/ndis/ndis.txt. Another source of 
NDIS drivers is the Windows for Workgroups package.  
New drivers are available for download from Microsoft 
Product Support Services, available at (206)936-MSDL, 
or on CompuServe or GEnie. The Windows Driver LIbrary (WDL), 
which includes printer, display and network drivers is also 
available on disk from Microsoft by calling (800)426-9400. 

The NDIS spec is available as:
file://vax.ftp.com/pub/ndis-mac.v101.txt, ndis-mac.v201.txt

Suggestion
SLIPPER v1.3	Free
CSLIPPER	Free

SLIPPER and CSLIPPER get rave reviews for being less 
obtrusive than some other SLIP/CSLIP drivers so that 
the machine loses fewer clock ticks. The result is 
that the clock stays more accurate. SLIP/CSLIP operation 
is supported at up to 57.6 Kbps on a 486. CSLIPPER is a 
version which supports Van Jacobson header compression. 
Supports PKTMUX. 

SLIPPER is available from: 
file://ftp.utas.edu.au/pc/trumpet/slipper/slipper.zip
file://biochemistry.cwru.edu/pub/slipper/slippr13.zip

CSLIPPER is available from:  
file://biochemistry.cwru.edu/pub/slipper/cslipper.exe

P. Tattam, Programmer; Psychology Department, University of 
Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email: 
peter@psychnet.psychol.utas.edu.au

Recommendation
ETHERPPP	Free

Glenn McGregor, formerly of Merit Network, has released 
ETHERPPP, a PPP packet driver that simulates a class 
1 (Ethernet) packet driver. It works well enough, is 
simple to configure, but takes up too much RAM (121K).  
Available as: file://merit.edu/pub/ppp/etherppp.zip

Recommendation
PKTMUX v1.2	Free

This program allows multiple TCP/IP protocol stacks to 
use a single packet driver. It can also run over shims 
such as DIS_PKT; I have used it with four or more 
simultaneous DOS-based applications. Works great. However, 
if you are only using a single DOS TCP/IP application 
under Windows, use WINPKT instead, since it takes less 
memory and is faster. 

Available via file://ftp-ns.rutgers.edu/pub/msdos/wattcp/pktmux12.exe,
or file://biochemistry.bioc.cwru.edu/pub/dos/pktmux12.exe, pktmux12.txt

Downright speculation
ODITRPKT v2.0

Supports packet drivers over ODI and token ring. 
Available as file://datacomm.ucc.okstate.edu/pub/oditrpkt/BETA12.ZIP

Recommendation
WINPKT	free

WINPKT is needed for running DOS applications with 
built-in TCP/IP stacks under Windows, as well as for 
some Windows-based TCP/IP stacks (suck as Trumpet 
Winsock). Compatible with ODIPKT. 
Available at file://biochemistry.bioc.cwru.edu/pub/slip/dos/winpkt.com

Downright speculation
PKTINT

PKTINT is included with the non-Winsock-compatible version 
of WinQVT/Net to communicate with the real mode packet driver. 
Available at file://biochemistry.micro.umn.edu/pub/qvtnet/qvtne397.zip

*Recommendation
DIS_PKT	free

Provides a packet driver over an NDIS driver. This is useful 
when you need to run both packet driver software (such as 
KA9Q or NCSA Telnet) and NDIS-based software (such as Chameleon NFS).
The latest version works with WFW v3.11, and includes a help file
WFW.TXT with sample PROTOCOL.INI files, etc.  

Available via:
file://biochemistry.bioc.cwru.edu/pub/qvtnet/dis_pkt9.zip
file://netlab.usu.edu/novell.dir/dis_pkt9.zip

Suggestion
PDEther v1.03

Supports ODI over packet drivers. Although I haven't had much 
success with it, others have used it on thousands of machines 
and found it better than ODIPKT, especially under Windows. 
Available as:
file://sjf-lwp.novell.com/odi/pdether/getpde103.zip

*Recommendation
Odipkt v3.0

Supports packet drivers over ODI. This is the recommended 
method of getting Novell NetWare to coexist with a packet-driver 
based TCP/IP stack. Compatible with WINPKT. 

Available as file://hsdndev.harvard.edu/pub/odipkt/odipkt.com,  
net.cfg, odipkt.8, odipkt.asm.  

Recommendation
CIRA RARP server	Free

This is a RARP server that runs under DOS, and can give 
out an IP address from a pool. 

Available as file://pine.circa.ufl.edu/pc/rarp/rarp.zip.

Recommendation
RARP client	Free

This is a RARP client that can store the retrieved IP 
address in a DOS environmental variable, for later 
substitution into a file.   

Available as file://pine.circa.ufl.edu/pc/rarpset.zip. 

Recommendation
BOOTPQ v1.2	Free

BOOTPQ is a BOOTP client that can take an IP address 
extracted via BOOTP and put it into a DOS environmental 
variable. 

Available as file://biochemistry.cwru.edu/pub/dos/bootpq12.zip

Recommendation
BOOTP	Free

A bootp server available via 
file://biochemistry.cwru.edu/pub/dos/bootp.zip or 
file://ftp-ns.rutgers.edu/pub/msdos/wattcp/bootp.zip

WINDOWS SOCKETS IMPLEMENTATIONS

Recommendation
Trumpet WinSock
	
A shareware version of Windows Sockets that runs over packet 
drivers and requires WINPKT. Available as:
file://ftp.utas.edu.au/pc/trumpet/winsock/twsk10a.zip, 
winapps.zip, or  
file://biochemistry.bioc.cwru.edu/pub/trumpwsk/twsk10a.zip, winapps.zip

P. Tattam, Programmer; Psychology Department, University of 
Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email: 
peter@psychnet.psychol.utas.edu.au

Recommendation
Dialer

DIALER is a Windows program that will dial up a host and then 
run a series of WIndows applications. It isn't needed with 
Trumpet Winsock anymore, since this now has its own built-in 
scripting language. Available at: 
file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip


Recommendation
Chameleon Demo       Free

This is a a demonstration version of the NetManage Chameleon 
TCP/IP stack. Quoting from the install instructions:
To install the software, copy each .zip file onto a 
separate floppy. Insert diskette #1 into drive A: 
type win a:setup (assuming you have the installation 
floppy in the A drive).  You will be prompted for all 
the other relevant information (i.e. adapter type, IP 
address, subnetmask, etc.).  You can use Custom to 
configure some optional information (i.e. default 
gateway, DNS server, etc.). During the installation 
you will be prompted for a serial number. The valid 
serial number is DEMO_520045343970001, and the Key is F39B.
The included software is only valid for 30 days from 
March 3, 1994.  So, some time in April you'll get a 
license violation message, at which time you are 
supposed to run out and purchase a legal copy (we 
will not object to purchases prior to the expiration day).
The winsock.dll provided in this release is compatible 
with the Windows Sockets version 1.1 specification.  
If you find any problems, please send your e-mail to 
winsock@netmanage.com.  Actually, we want to hear 
from you even if you don't have any problems. Ò

Available at: file://ftp.netmanage.com/pub/winsock/chameln1.zip,
chameln2.zip, chameln3.zip,chameln4.zip, readme.txt

Downright Speculation
VxDTCP
	
A shareware version of Windows Sockets, running over NDIS, 
and implemented as a VxD driver. Available at: 
file://biochemistry.bioc.cwru.edu/pub/wintcp/vxdtcpa2.zip

Downright Speculation
Microsoft TCP/IP for WFW 3.11
	
Adds TCP/IP to WFW 3.11. Available as:  
file://ftp.microsoft.com/Advsys/MSclient/WFW/WFWTCP.EXE, README.TXT


WINDOWS SOCKETS COMPATIBLE APPLICATIONS

*Recommendation
Windows Mosaic v2.0a5	free

The Internet's Swiss army knife: supports hypertext links, 
font styles, embedded pictures, sounds, and movies. An amazing 
application. Compatible with Windows Sockets. Version 2.0 
supports forms, clickable regions within pictures. 

Please note: Since Mosaic is now a 32-bit app,
unless you are running Windows NT, you must install Win32s 
(available from ftp.microsoft.com) in order to run Mosaic. Also,
make sure you get the viewers for sounds, JPEG, and MPEG. 
Available at:
file://ftp.ncsa.uiuc.edu/PC/Mosaic/wmos20a5.zip, win32s.zip, 
readme.now (Windows Mosaic) 

GIF viewer: 
file://lister.cc.ic.ac.uk/pub/wingopher/viewers/image/wingif14.zip
file://lister.cc.ic.ac.uk/pub/wingopher/viewers/image/gv.zip

JPEG viewer: 
file://ftp.ncsa.uiuc.edu/PC/Mosaic/viewers/lview31.zip
file://lister.cc.ic.ac.uk/pub/wingopher/viewers/image/lview31.zip
file://lister.cc.ic.ac.uk/pub/wingopher/viewers/image/jview090.zip

MPEG viewer: 
file://biochemistry.cwru.edu/pub/dos/mpeg2.zip
file://lister.cc.ic.ac.uk/pub/wingopher/viewers/movies/mpeg2.zip

Windows Quicktime: 
file://lister.cc.ic.ac.uk/pub/wingopher/viewers/movies/qtwplay.zip 

Sound player: 
file://lister.cc.ic.ac.uk/pub/wingopher/viewers/audio/wnplny09b.zip

Downright Speculation
WinIRX	free

A Windows Sockets program that makes it easier to search 
or retrieve from the National Center for Biotechnology 
Information (NCBI) Retrieve Email server. Available via:
file://biochemistry.cwru.edu/pub/dos/win-irx.zip, win-irx.txt. 

*Recommendation
PCEudora v1.42	Free	

The Windows version of Eudora, compatible with Windows Sockets. 
Handles SMTP, POP3. This is the nicest TCP/IP mail client 
available anywhere.  To be able to send and receive file 
enclosures, make sure to obtain BINHEX.EXE. The lastest
version now runs under Windows NT. 

Available at:

file://ftp.qualcomm.com/quest/eudora/windows/1.4/beta
file://ftp.cdrom.com/.5/cica/winsock/eudora14.exe (PC Eudora)
file://boombox.micro.umn.edu/pub/pc/binhex/binhex.exe (BINHEX)

Qualcomm, sales: eudora-sales@qualcomm.com, bug reports:
pc-eudora-bugs@qualcomm.com, (800)238-3672

Suggestion
Trumpet Telnet v0.5

A Windows Sockets compatible Telnet implementation. Available at:
file:/petros.psychol.utas.edu.au/pub/trumpet/trmptel/trmptel.exe 

Downright speculation
WinTimeSync

A Windows Sockets-compatible implementation of NTP. Available at:
file://ftphost.cac.washington.edu/pub/winsock/tsync1_4.zip

*Downright speculation
WinTalk v1.1

A Windows Sockets-compatible implementation of Ntalk and Talk. Available at:
file://elf.com/pub/wintalk/wtalk11.zip
file://ftp.cdrom.com/.5/cica/winsock/wtalk11.zip

Downright speculation
Windows Telnet beta 3	free

An unsupported Telnet implemenation for Windows. Windows Sockets compatible.
Available at:
file://ftp.ncsa.uiuc.edu/PC/Telnet/windows/wintelb3.zip 

*Recommendation
WinFTP

A Windows Sockets-compatible FTP client, with a 32 bit version available,
written by slahiri@magnus.acs.ohio-statie.edu. Available via:
file://ftp.cdrom.com/.5/cica/winsock/winftp.zip
file://cnuce-arch.cnr.it/pub/msdos/win3/winsock/winftp.zip

A non-blocking version is available via:
file://lahiri.chrr.ohio-state.edu/?/wsaftp.zip


*Downright speculation
PhWin

Windows implementation of Ph. Available at:
file://ftp.cdrom.com/.5/cica/winsock/phwin22.zip

Suggestion
WS-FTP client	free

This is a graphical FTP implementation by John A. Junod. Available at:
file://ftp.usma.edu/pub/msdos/winsock.files/ws_ftp.zip (executable)
file://ftp.usma.edu/pub/msdos/winsock.files/ws_ftp_s.zip (source code)
file://microdyne.com/pub/incoming/ws_ftp.zip
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/ws_ftp.zip

John Junod; zj8549@trotter.usma.edu; junodj@gordon-emh2.army.mil
NCOIC, Technology Integration Branch, Computer Science School, 
FT Gordon, GA 30905; (706)791-3245  AV:780-3245

Downright Speculation
USGS WAIS Client

A Windows WAIS client, available at: 
file://ridgisd.er.usgs.gov/software/wais/wwais23.zip. 

Downright Speculation
WAIS Manager

A Windows WAIS client, now compatible with Windows 
Sockets, available at: 
file://ftp.cnidr.org/pub/NIDR.tools/wais/pc/windows/waisman3.zip

Jim Fullton, UNC Office of Information Technology, Computing 
Systems Development Group, (919)962-9107; email: fullton@samba.oit.unc.edu.

*Recommendation
EINet winWAIS v2.00	shareware, $35

The most mature Windows WAIS client,  Windows Sockets-compatible. Available at:
file://ftp.einet.net/einet/pc/EWAIS155.ZIP or 
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/ewais200.zip
Note: this program does not run under Windows NT.

EINet Windows Shareware, MCC, 3500 West Balcones Center Drive, 
Austin, TX 78759-6509

*Downright Speculation
Internet Voice Chat v1.0

This is a program that allow voice conversations over the Internet. It
even supports an answering machine and call screening!
Requires WinSock 1.1, a sound card with microphone, and 386 or better.
Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/IVC10.ZIP
file://www.unb.ca/pub/winsock/IVC10.ZIP
file://ftp.demon.co.uk/pub/ibmpc/winsock/IVC10.ZIP

Recommendation
Windows IRC

This is a Windows IRC client, available as:
file://ftp-ns.rutgers.edu/pub/msdos/trumpet/irc/winirc.exe, winirc.doc

*Downright Speculation
WS-IRC
Shareware

A really nice shareware Windows IRC client, available as:
file://ftp.cdrom.com/.5/cica/winsock/wsirc13a.zip
Also available on cs.bu.edu, winftp.cica.indiana.edu, 
ftp.undernet.org, ftp.demon.co.uk

Recommendation
Windows Trumpet v1.0a

WinTrumpet is a Windows-Sockets compatible NNTP client 
from P. Tattam that supports the Trumpet ABI, packet 
drivers, Novell Lan Workplace for DOS and WinSock v1.1. 
It is the nicest shareware NNTP newsreader for Windows 
Sockets. Available at:
file://ftp.utas.edu.au/pc/trumpet/wintrump/*
file://biochemistry.cwru.edu/pub/wintrump/wtwsk10a.zip 
(Windows Sockets version), wtpkt10a.zip, wtabi10a.zip, 
winpkt.com, wtlwp10a.zip (Lan Workplace for DOS)

Recommendation
HGopher v2.4	Free

This is a Windows-sockets compatible version of Gopher. Looks good. 
Be sure to get the viewers, too. 
Available at:
file://lister.cc.ic.ac.uk/pub/wingopher/hgopher2.4.zip

Downright Speculation
WLPRSPL v4.0	Shareware

This is a windows sockets-compatible lpr implementation that 
offers support for multiple queues. Be aware that LPQ doesn't 
run with LAN Workplace for DOS, since it doesn't fully 
implement Windows Sockets. It also runs with wslpd's new 
"raw spooler," provided that you get lpd up and running 
prior to printing, since it will timeout quickly. Also, 
remember to name the spool files correctly and once you set 
the default spool directory, don't specify a full path in 
defining a spool file. 

Contact: th.heil@kfa-juelich.de Available as:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/wlprsp40.zip. 

Recommendation
WinLPR v1.0	Shareware

This is an implementation of lpr, lpq, and lprm that allows 
you to print to a machine running lpd. It works fine for me. 
Contact: th.heil@kfa-juelich.de. Available at:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/winlpr10.zip 

Recommendation
Winfsp v1.2	Free	

A Windows Sockets-compatible implementation of the 
File Slurping Protocol.  I got it working with no 
problem. Be aware that the Òprotocol searchÓ option 
can take quite a while; you may have be asking the 
client to individually test hundreds of ports, at 
a second per port. Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/winfsp12.zip

*Recommendation
WinQVT/Net v3.97
Shareware	$40
Students	$20

QVTNet is a Windows v3.1 application that supports FTP 
client and server (not fully graphical; commands are 
entered at the bottom of the window), telnet (up to 
15 simultaneous sessions), mail (SMTP and POP3), 
NNTP (up to 30 newsgroups) and lpr.  It is written 
as a DLL, and comes in several versions: a Windows 
Sockets-compatible version (recommended); a 32-bit 
version;  and a version with it's own built-in 
TCP/IP stack. The version with the built-in stack 
requires that you load PKTINT in DOS before running 
it, and also requires you to supply your own packet 
drivers, and is compatible with AppleTalk as well as 
class 6 SLIP drivers. 

Note: the 16-bit Winsock version of WinQVT/Net has
problems under Windows NT; use the 32-bit version instead.

Available at:
file://biochemistry.bioc.cwru.edu/gopher/pub/qvtnet/qvtne397.zip 
(packet driver version with built-in TCP/IP stack),
file://biochemistry.bioc.cwru.edu/gopher/pub/qvtnet/qvtnt397.zip 
(Windows NT version), 
file://biochemistry.bioc.cwru.edu/gopher/pub/qvtnet/qvtws397.zip 
(Windows Sockets version). 

Contact: djpk@troi.cc.rochester.edu

*Downright Speculation
WinVN v0.82	

A semi-graphical Windows application for reading news 
which supports NNTP over TCP/IP or serial line connections.  
Compatible with Winsock v1.1; a version is also available 
for Windows NT. Does not support LocalTalk. Current 
version has been tested with:

NetManage's WINSOCK
FTP Inc.'s WINSOCK
Wollongong's WINSOCK
NT's WSOCK32
DEC's Pathworks
MS's Lan Man

Available at: 
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/wnvn082s.zip
file://ftp.cdrom.com/.5/cica/winsock/wnvn082s.zip


Sam Rushing, email: rushing@titan.ksc.nasa.gov,
hoggle!hoggle2!rushing@peora.sdc.ccur.com

You'll find a bunch of zip files. Be sure to use binary mode. 
Read the file announce-2.txt first.

Recommendation
WS-Finger	Free

A Windows Sockets compatible finger implementation. Available at:
file://sparky.umd.edu/pub/winsock/wsfngr11.zip

Recommendation
Finger v3.1	Free	

The Windows version of Finger, which requires a Winsock DLL. 
It works; try it out. 
Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/finger31.zip

*Recommendation
Cello WWW client v1.0	Free

Unlike Mosaic, Cello WWW does not support inline pictures, 
although it does support viewing of sounds, pictures, 
postscript and movies through external viewers. The 
current version supports Windows Sockets, and can be run
under Windows NT. 

Available at:
file://ftp fatty.law.cornell.edu/pub/LII/Cello/cello.zip, 
viewers.zip, the graphics viewer and sound player; 
gswin.zip, a Ghostscript Postscript viewer for Windows.

Suggestion
SMTP client v1.1	Free

A Windows Sockets-compatible SMTP client that is limited to 
send only. Not as functional as PCEudora (which also handles 
POP3). Available at:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/smtp11.zip

Contact: Todd.Young@StPaul.NCR.COM

Suggestion
Windows TN3270 client	Free

A Windows Sockets-compatible TN3270 client. Available at:
file://ftp.ccs.queensu.ca/pub/msdos/tcpip/qws3270.zip

Suggestion
Hlook

This is a reverse lookup tool that gives you the DNS name 
from an IP address. Available as:  
file://petros.psychol.utas.edu.au/pub/trumpet/uploads/iwork.zip

*Recommendation
WS-Archie

A windows sockets compatible Archie implementation by David Woakes.
Looks very good; runs fine under Windows NT.  
file://ftp.demon.co.uk/pub/ibmpc/winsock/apps/wsarchie/wsarch05.zip

Suggestion
X.500 implementation

A windows sockets compatible X.500 implementation: 
file://naic.nasa.gov/software/windows-dua/pixie22b.zip, wdua12.zip

Suggestion
SWIX X.500 implementation

A windows sockets compatible X.500 implementation: 
file://ftp.demon.co.uk/pub/ibmpc/winsock/apps/swix/swixb1.exe

Downright speculation
HTML Assistant	Free

This an MS Windows-compatible text editor for use in 
creation of HTML documents. It supports multiple documents. 
Available at:
file://ftp.cs.dal.ca/htmlasst/htmlasst.zip, vbrun300.zip,readme.1st

Downright speculation
HTMTools	Free

This program is a DLL that allows you to go directly from 
MS Word for Windows v2.0 to HTML. Written by Jorma 
Hartikka, Jorma.Hartikka@csc.fi. Available as: 
file://ftp.funet.fi/pub/msdos/windows/winword/htmtl050.zip

*Downright speculation
Word Macros for HTML	free

This adds a toolbar to MS Word for Windows that supports adding
links, inline images, etc. Available via:
file://ftp.cuhk.hk///pub/www/windows/util/cu_html.zip  


*Downright speculation
HTMLWriter	Free

HTML Writer is another tool for producing HTML documents.
It is available via file://ftp.byu.edu/tmp/htmlwrit.zip.


Downright speculation
Mr. Squiggle	Free

This a Windows-Sockets compatible whiteboard application 
that allows two people to share the same drawing window 
over the Internet.  It was implemented in Visual Basic V3, 
and uses Brian Syme's VBWSK Visual Basic Winsock control.
Available at:
file://commsun.its.csiro.au/csiro/win3/squiggle/squiggle.zip, squiggle.doc



APPLICATIONS DEMOS

Suggestion
Starnet X-Window Server Demo       Free

This is a a demonstration version of the Starnet X-server. 
The pricing is reasonable and the product is fast. 
They have versions that work with Windows Sockets, 
packet drivers under DOS, and some other brands under 
DOS. It is available at: 
file://ftp.cica.indiana.edu/pub/pc/win3/uploads/xwindemo.zip

Suggestion
ECSmail	Commercial

ECSmail is a commercial product supporting IMAP with DOS, 
Windows and Mac clients. this is a demo version. Available at:
file://info.asu.edu/pub/mail/ecs/ecsmail/MUASet/windows/mua2-3.exe

DOS TCP/IP STACKS

Suggestion
WATTCP	free

Development package for TCP/IP.  Available via:
file://ftp-ns.rutgers.edu/pub/msdos/wattcp/apps.zip, readme.1st, newwattcp.zip

Erick Engelke, WATTCP Architect; email erick@ftp-ns.rutgers.edu

Suggestion
Trumpet TCP/IP stack

This TCP/IP stack comes in three versions: a TSR version; a 
Windows Sockets version (discussed below); and a built-in 
version. It includes a traceroute program called hopchk2. 

Available as file://ftp.utas.edu.au/pc/trumpet/abi-version/
Available at file://biochemistry.bioc.cwru.edu/pub/trumpet/tcp201.zip

P. Tattam, Programmer; Psychology Department, University of 
Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email: 
peter@psychnet.psychol.utas.edu.au

Downright Speculation
PC-IP	Free

This was the software that started it all. It has been worked 
on at MIT, Carnegie Mellon, and Harvard and other places, but 
by now is out of date. Its authors recommend looking at newer 
alternatives such as NCSA, WATTCP, etc. 

Harvard version: Source code: 
file://ftp hsdndev.harvard.edu,/pub/pcip/pcip.tar.Z, 
doc.tar.Z, readme, readme.cmu
Binaries: file://hsdndev.harvard.edu/pub/pcip/bin/packet/*.exe
file://hsdndev.harvard.edu/pub/pcip/bin/general/*.exe

Another version:
file://netlab.usu.edu/netwatch/pcip96.zip

DOS APPLICATIONS

Suggestion
IRC client	free

A client for Internet Relay Chat.

Available at file://ftp.utas.edu.au/pc/trumpet/irc/irc100.zip
Available at 
file://biochemistry.bioc.cwru.edu/pub/trumpet/irc100.zip, 
ircabi.zip, irclwp.zip 

P. Tattam, Programmer; Psychology Department, University of 
Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email: 
peter@psychnet.psychol.utas.edu.au

Recommendation
WAIS for DOS	free

A DOS WAIS client which uses the Clarkson drivers is 
available at 
file://sunsite.unc.edu/pub/packages/infosystems/wais/DOS/pcdist.zip. 

A DOS WAIS client that requires the PC/TCP software from
FTP Software is available at 
file://oac.hsc.uth.tmc.edu/public/dos/misc/oacwais.exe.

For information, contact: Steven E. Newton, Office of Academic 
Computing, University of Texas Health Science Center, Houston, 
email: snewton@oac.hsc.uth.tmc.edu.

There is also a Novell LAN Workplace WAIS client available at 
file://ftp.oit.unc.edu/pub/WAIS/UNC/nov-cli-visual.zip.

Suggestion
PDCLKSET	Free

Requiring a packet driver, this software sets your PC clock 
via an Internet time server.It also offers several useful 
network testing functions. Supports ping, and can build an arp
table of nodes on the subnet. Available at 
file://oak.oakland.edu/pub/msdos/pkdrvr/pdclk207.zip 

Suggestion
NCSA Telnet	Free

Available at file://zaphod.ncsa.uiuc.edu/PC/Telnet/msdos/tel2307b.zip, 
tel2307s.zip.  Also available at 
file://wsmr-simtel20.army.mil/PD1:<MSDOS.PKTDRVR>/tel2307b.zip
 
Compatible with LocalTalk.  A special version which supports 
PPP is available at file://merit.edu/pub/ppp/ncsappp.zip, 
ncsappp.txt. A PPP FAQ is available at file://merit.edu/pub/ppp/ppp.faq

Be aware that the current version does not reassemble fragments, even
though a fix is available for this (argghhh....)

Recommendation
MS-Kermit 	Free

This version of Kermit supports telnet, VT320 and Tektronix 
emulation, as well as SIXEL. It incorporates the WATTCP 
stack, and also runns over Novell's LWP/DOS+Telapi, FTP 
Inc's PC/TCP+Tnglass, Beame & Whiteside's TCP/IP stack; 
DEC Pathworks, as well as over NetBIOS. It supports Int 
14h as well as Int 6Bh, and can run over packet drivers. 

Available at file://kermit.cc.columbia.edu/kermit/bin/msvibm.zip, 
msvibm.pif (Windows PIF file for MS-DOS Kermit)

Downright speculation
PCUCP    Free

This is a Windows v3.1 application that allows multiple open 
text windows at the UNIX end. It is available at 
file://ftp.cica.indiana.edu/pub/pc/win3/modem/pcucp11a.zip.

Recommendation
CUTCP Telnet	Free

CUTCP is the premiere DOS telnet application. Aside from 
VT100, and Tektronxi emulation, CUTCP also handles 3270 
emulation. The latest release has added ping and ODI 
support. Now supported by Rutgers University, having 
been tranferred from Clarkson University and Brad 
Clements. This directory contains the source and 
binary distributions, both in zip archives. For 
information contact cutcp-support@ftp-ns.rutgers.edu. 

Available at 
file://ftp-ns.rutgers.edu/pub/msdos/cutcp/current/cutcp-b.zip 
(Documentation and binaries), cutcp-s.zip 
(Source, documentation, and binaries). 

Downright speculation
Clarkson Archie	Free

Available at file://omnigate.clarkson.edu/pub/cutcp/archie.zip

Suggestion
Princeton Telnet Free

The Princeton version of Telnet supports localtalk cards 
and also does tn3270 access. Works on all localtalk cards 
(Sitka, Daystar, Farallon, ... )

Available at file://pusun3.princeton.edu/pub/PU2-2TN/pu2-2tn.zip

Recommendation
Clarkson Charon IPX/TCP email and printer gateway v4.0

Charon is a gateway widely used with Pegasus mail. 
Available at file://omnigate.clarkson.edu/pub/cutcp/charon40.zip, 
file://sun.soe.clarkson.edu/pub/cutcp/charon.zip

*Suggestion
Pegasus mail

Ron Sires <rons@netcom.com> writes:

"The latest version of Pegasus Mail for Windows supports POP3/SMTP mail
transfer through the WinSock interface.  I haven't used it for tcp/ip mail
yet, but its great as a Novell network email system.  My company uses it
extensively.  The program is free, but the author charges for printed
manuals.  The on-line docs are pretty good though. For more information, 
check out the bit.listserv.pmail newsgroup"

Pegasus mail is available via:
file://risc.ua.edu/pub/pegasus/winpm111.zip (Windows version),
pmail311.zip (DOS version)

Recommendation
Phone package	Free

A phone dialer package for DOS that was written to run with 
the UMSLIP driver. Be aware that UMSLIP does not work with PKTMUX. 

Available at file://ftp.ncsa.uiuc.edu/pub/pc/slip/sliparc.exe, phone.doc

*Downright speculation
NFS Client 
Business users	$20 (Shareware)
Home or Ed. use $15 (Shareware)

This a shareware NFS client. The shareware fee includes the right to a year's worth of free upgrades. All TCP/IP stack versions of it are available under one license. Site license discounts start at 20 machines. I have tried this,
and it works well. The latest version includes a built-in packet
multiplexer. Available at:
file://polyslo.calpoly.edu/pub/mdurkin/nfs/bugs.lst 
(Known and recently fixed bugs list)
file://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs025-m.zip   
(MS-DOS NFS client for Microsoft Lan Manager)
file://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs025-n.zip  
(MS-DOS NFS client for Novell LAN WorkPlace)
file://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs025-t.zip   
(MS-DOS NFS client for Trumpet TCPDRV)
file://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs025-w.zip  
(WATTCP MS-DOS NFS client)

*Downright speculation
XFS  Shareware	
Educational license   $15
Commercial            $25

This is another NFS client implementation for MS-DOS, by Robert Juhasz (robertj@lwfws1.uni-paderborn.de). It runs over packet drivers and
includes a built-in PKTDRVR multiplexer so you can run other software
concurrently. There are site license discounts. Requires a 286. Available as:
file://ftp.cdrom.com/.2/SimTel/msdos/nfs/xfs171.zip

Recommendation
Talk v1.2	Free

A DOS Talk client running over packet drivers. Available as:
file://oak.oakland.edu/pub/msdos/pktdrvr/talk-12.zip 

Recommendation
PC Gopher III	Free

An MS-DOS client for the Gopher information server. Be aware 
that you must load WINPKT.COM (or PKTMUX if you are running 
multiple TCP/IP applications) to get this program to work 
under Windows. The code for PC Gopher III has also been 
incorporated into Minuet. 

Available at file://boombox.micro.umn.edu/pub/gopher/PC_client/docs/pcgopher.txt
file://boombox.micro.umn.edu/pub/gopher/PC_client/00README, also:
file://biochemistry.cwru.edu/pub/dos/pcg3.zip, pcg3doc.zip

WINPKT is available at file://biochemistry.micro.umn.edu/pub/slip/dos/winpkt.com

Downright Speculation
Uwho	Free
	
Uwho is Stan Barber's interface to whois and ph e-mail 
address servers that runs under MS-DOS. An alpha test 
version is available at 
file://punisher.caltech.edu/pub/dank/uwho/uwho218b.tar.Z, 
uwho218b.zip, or unarchived in subdir uwho218b.  
The archived text files are inUnix format.

Recommendation
DOS Trumpet v1.06b 	Shareware, $10. 

Trumpet is an NNTP newsreader for DOS that can be placed on a 
NetWare server, while storing news groups and configuration 
files in each user's directory. It supports packet drivers, 
LAN WorkPlace for DOS, and Trumpet ABI.    

Available at file://ftp.utas.edu.au/pc/trumpet/dostrump/trmp106b.zip
Available at file://biochemistry.bioc.cwru.edu/pub/trumpet/trmp106b.zip, 
newsabi.zip, newslwp.zip 

Contact: peter@psychnet.psychol.utas.edu.au

Multi-user site licenses

Trumpet will be charged by the total number of users who 
have  access to Trumpet on  a  network. A site is designated 
as  being one organization located within a radius of10 km.

The pricing structure is:

1-99 users	$10 US per user
100-999 users	$1000 US + $2 US per additional user above 100
1000-4999 users	$2800 US + $0.20 US per additional user over 1000
5000+	$3600 US

P. Tattam, Programmer; Psychology Department, University of 
Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email: 
peter@psychnet.psychol.utas.edu.au

Downright Speculation
Broadcast	Free

This is a PC client for the Macintosh Broadcast program, by Kai Getrost. 

Available at file://caisr2.caisr.cwru.edu/pub/net/bdcst11.zip

*Suggestion
DOSLynx	free

This is a textual browser for WWW that requires a class 1 packet
driver, and includes its own built-in TCP/IP stack. It can call 
external viewers but does not allow viewing of inline images. 
It is compatible with EtherSLIP or EtherPPP, but takes up quite
a bit of memory, leaving little left over for documents on a
640K machine. Available via:
ftp://ftp2.cc.ukans.edu/pub/WWW/DosLynx/

Suggestion
NuPOP/PC  free

In addition to a POP/SMTP mail client that supports MIME, NuPOP 
contains an FTP client, a Ph (phonebook) client, a Gopher client, 
a news reader, a Telnet client, and an LPR (print) client. 
Version of NuPOP are also available that support Wollongong 
TCP kernel, WATTCP kernel, and Trumpet ABI TCP kernel. 
Can be gotten to support LocalTalk via the provided LocalTalk 
driver. Do not use the Clarkson drivers for this. By the way, 
NuPOP also supports serial access, as well as running over TCP/IP. 

Available at file://ftp.acns.nwu.edu/pub/nupop/nupoprea.zip (real mode executable)
file://ftp.acns.nwu.edu/pub/nupop/nupoppro.zip (protected mode executable)
file://ftp.acns.nwu.edu/pub/nupop/nupopsup.zip (additional files required)

If you want the news reading and MIME support,  you must first 
install the protected mode version described above, and then 
install the following over it.
file://ftp.acns.nwu.edu/pub/nupop/nupop210_test_release/nupop210.zip
or if you get the real mode executable:
file://ftp.acns.nwu.edu/pub/nupop/nupop210_test_release/real210.zip

Suggestion
POPmail-PC v3.2.2	

This is the package included with SLIPDISK.  Supports Ethernet, 
AppleTalk, and SLIP. Use the AppleTalk driver that works with NuPOP. 

Available at 
file://boombox.micro.umn.edu/pub/pc/popmail/popmail-3.2.2/program/popmail.exe, 
popmail.hlp

file://boombox.micro.umn.edu/pub/pc/popmail/popmail-3.2.2/manuals/manual.asc, 
popmail.doc, popmail.sty

A POP3 server for VMS and MS-DOS client software is available at 
file://logos.ucs.indiana.edu/INDEX.

Recommendation
Minuet	

A smorgasbord of DOS TCP/IP applications, including gopher, mail, 
ftp, news, and telnet, Minuet includes code from PC Gopher III, 
and POPmail. It supports multiple windows, as well as Ethernet, 
AppleTalk and SLIP packet drivers. Use the AppleTalk driver 
that works with NuPOP.  Since Minuet does so much, and does 
it well, you may not want to use anything else, unless you 
don't have enough RAM for it. 

Available at file://boombox.micro.umn.edu/pub/pc/minuet/minuarc.exe

Suggestion
PC-Pine v3.88	Free

This is a PC-compatible version of Pine, running under DOS. 
There are versions written for FTP Software's PC/TCP, Novell's 
Lan WorkPlace for DOS, and WATTCP. 

Available at file://ftp.cac.washington.edu/mail/pcpine_p.zip 
(WATTCP version), pcpine_n.zip (Novell LWP), pcpine_f.zip (FTP PC/TCP)
 
Note that PC Pine relys on the Interactive Mail Access Protocol 
(IMAP2) rather than POP. You must have an IMAP server installed 
in order to use it. IMAPd is available at 
file://ftp.cac.washington.edu/mail/imap.tar.Z

For a listing of other IMAP-compatible clients, get
file://ftp.cac.washington.edu/mail/imap.software. 

Downright speculation
Ph client	

University of Illinois CCSO name server client.

Available at file://uxc.cso.uiuc.edu/net/ph/dos/pcph.com, pcph.README

Downright Speculation
FTPNuz	$10/shareware

Gene Mangum's shareware newsreader for DOS, which requires FTP 
Software's PC/TCP kernel. Runs under MS-DOS, as well as in a 
DOS window under MS Windows and OS/2. Features include support 
for NNTP,pull-down menus, reading and posting of news, reply 
by mail via SMTP.

Available at file://calvin.sfasu.edu/pub/dos/network/ftp-pctcp/ftpnuz10.zip

Gene Mangum; email: h198@hosp.med.umich.edu

DOS SERVERS

Recommendation
KA9Q	
Educational Use	Free
Commercial Use	$50

There are several versions of KA9Q, each with different 
capabilities. The current most capable versions are the 
ones put together by the folks at Demon Internet Services 
(DIS) in the UK, and the version put out by Ashok Aiyar at 
CWRU. CWRU Version 1.0b is based on the N1BEE 0.85-beta 
which in turn is based on PA0GRI 2.0m NOS, and includes 
support for NTP, CSO, Gopher, FTP, and SMTP/POP2/POP3 
servers, plus VT102 and packet filtering support. Base 
code is by Ashok Aiyar, ashok@biochemistry.cwru.edu. 
The Textwin version from DIS does not include Gopher 
support, but does support Domain Name Service and 
can act as an NNTP server. 

KA9Q can route TCP/IP packets over X.25, Ethernet, 
LocalTalk (with a special version), and serial lines 
(via SLIP/CSLIP/PPP). It supports connection to 56 
Kbps leased lines via a CSU/DSU and an SCC card, and 
supports up to 4 serial ports per machine. This means 
you can purchase a 56 Kbps Internet link, then divide it 
among 4 users, bringing the cost way down. KA9Q is a 
useful tool for sysops looking to hook their systems 
to the Internet, regardless of what kind of computer 
the BBS runs on.   

Available as: 
file://biochemistry.cwru.edu/pub/nos/nos10b.exe, nos10b.txt, 
nos10b.map, nos192.txt, nos_1229.man, vt102.zip, filter.txt, 
autoexec.nos

Alternative sites: 
file://ucsd.edu/hamradio/packet/tcpip/ka9q
file://boombox.micro.umn.edu/pub/gopher/PC_server/ka9q

A Macintosh port (NetMac) is available at 
file://sumex-aim.stanford.edu/info-mac/comm/

Textwin (multiwindowing version with mouse support) package 
is available in three versions: large, small and tiny. The 
tiny package includes support for NNTP, SMTP and POP servers; 
the small version adds support for FTP servers; and the 
large version adds packet filtering, RIP and DNS support. 
Available as: 
file://ftp.demon.co.uk/pub/ibmpc/textwin.

Contact: amc@beryl.demon.co.uk, amccarthy@cix.compulink.co.uk, 
100012.3712@compuserve.com

An access control program for SLIP gates, known as SLIPLOG, 
is available via: 
file://mvmpc9.ciw.uni-karlsruhe.de/public/nos/sliplog.zip
If you have trouble accessing this with the ws-ftp client, 
set your servertype to ka9q. 

Phil Karn, KA9Q; 7431 Teasdale Ave, San Diego, CA 92122; 
(619)587-8281, fax: (619)587-1825

Downright Speculation
NOSView v3.04	

Written by Ian Wade, G3NRW, NOSView is online documentation 
for KA9Q, which describes all the NOS commands. It also 
contains a complete set of templates for use of KA9Q.

Available at file://ucsd.edu/hamradio/packet/tcpip/nosview/nosvw304.zip

Contact: Ian Wade, ian@g3nrw.demon.co.uk 

Downright Speculation
Hamburg Gopher Server

Available at:
file://boombox.micro.umn.edu/pub/gopher/PC_server/hamburg/gophserv.zip (server package), 
file://boombox.micro.umn.edu/pub/gopher/PC_server/hamburg/gophdoc.zip (documentation), file://boombox.micro.umn.edu/pub/gopher/PC_server/hamburg/engine.zip (database engine)
file://ftp.informatik.uni-hamburg.de/pub/infosystems/gopher/pc/go4ham/go4ham.zip

Downright Speculation
Stan's Own Server	Free

SOS is based on the now-outdated PC-IP, and as a result 
is not used much anymore. However, there is no other 
publicly distributable NFS server package out there, 
so if you need one, you might as well try this. 
Available at file://sun.soe.clarkson.edu/pub/packet-drivers/soss.zoo, 
sossread.me.  Also available at file://spdcc.com/pub/sos/soss.zoo, sossexe.zoo

A version with a couple of bugs fixed is available at 
file://hilbert.wharton.upenn.edu/pub/tcpip/soss.zip

For info, contact: Richard Bruan, rbraun@spdcc.com, or Seemong Tan,
stan@cs.uiuc.edu.

Downright Speculation
BOOTP and FTPD NLMs

Available via file://novell.felk.cvut.cs/pub/nw311/ftpd,
/pub/nw311/bootpd, /pub/nw311/resolv. 

Downright Speculation
LPD	Free
FTP and BOOTP server  included

This software is a freeware line printer daemon as 
well as an FTP and BOOTP server.  Available via 
file://tacky.cs.olemiss.edu/pub/lpd/lpd.zip, lpdsrc.zip

Recommendation
TELNETD	Free

TELNETD is a simple, free and unsupported TELNET 
server for PCs, by Erick Engelke. It works on top 
of packet drivers and lets you run most DOS software. 
However, it doesn't do everything; if you want a 
commercial-quality implementation, get Everywhere Access. 

Available at file://ftp-ns.rutgers.edu/pub/msdos/wattcp/telnetd.zip

Recommendation
COMD	Free

COMD by Erick Engelke allows you to share serial port 
devices, including printers and modems with another 
TCP/IP connected computer. 

Available at file://ftp-ns.rutgers.edu/pub/msdos/wattcp/comd.zip

Downright Speculation
SMTP server	free

An SMTP server for DOS. Available at: 
file://ftp-ns.rutgers.edu/pub/msdos/wattcp/smtpserv.zip

WINDOWS SERVERS

Recommendation
WS-Gmail	Free

An SMTP and POP3 server implementation with a matching 
mail client that supports multiple userIDs as well as 
aliases. Written by y John A. Junod. Available as: 
file://ftp.usma.edu/pub/msdos/winsock.files/ws_gmail.zip (Mail implementation)

John A. Junod; 267 Hillwood Street, Martinez, GA 30907; 
email: jundj@css583.gordon.army.mil; (706)791-3245  AV:780-3245

Recommendation
Fingerd	Free

A Windows Sockets compatible finger server:   
file://sparky.umd.edu/pub/winsock/wfngrd10.zip

Downright Speculation
Web4Ham v0.14	Free

A Windows Sockets compatible HTTP server, by Gunter Hille, 
hille@informatik.uni-hamburg.de. Available as:   
file://cica.indiana.edu/pub/pc/win3/uploads/web4ham.zip
ftp://ftp.informatik.uni-hamburg.de/pub/net/winsock/web4ham.zip

Recommendation
SerWeb v0.3	Free

A fully functional HTTPd implementation for Windows. 
For info, contact: estrella@cass.ma02.bull.com. Available as: 
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/serweb03.zip

*Suggestion
NCSA HTTPd for Windows Free

This is a fully compliant  HTTTP server from NCSA that supports 
scripts. Available as: ftp://ftp.ncsa.uiuc.edu/Web/ncsa_httpd/contrib/whtp11a6.zip

Downright speculation
Cookie server	Free

This is a Windows-Sockets compatible fortune cookie server 
(RFC 865) that runs on port 17. Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/cooksock.zip. 

Contact: alun@huey.wst.com

Suggestion
Windows Sockets for PC/NFS	free

An implementation of Windows Sockets for PC/NFS.   

Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/wsck-nfs.zip 

*Suggestion
WinFTPd	$15 (shareware)

An FTP daemon for Windows by Alun Jones (alun@huey.wst.com). 

Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/wftpd19.zip
file://ftp.cdrom.com/.5/cica/winsock/wftpd19.zip 

Downright Speculation
WinLPD	Free

An lpd implementation for Windows.  Contact: dog@inel.gov

Available at:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/wslpd-11.exe 

Downright speculation
Text server

This is an extended finger client, which can also serve text 
files. Available at 
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/txtsrv.zip

Recommendation
SMTP daemon v1.6	free

A Windows-Sockets SMTP daemon, complete with source code. 
Works fine. Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/wsmtpd16.zip.  

contact: iblenke@cip60.corp.harris.com

WINDOWS NT SERVERS

Recommendation
Windows NT FTP daemon	Free

This is a Windows NT version of ftpd. Quite fast. 
Available at:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/nt-ftpd.zip 

*Recommendation
HTTPS v0.6	Free

This is a very powerful and easy to install HTTP server,
probably the best I've seen running under any OS.
HTTPS is a Windows NT HTTP v1.0 server for Windows NT 
produced as part of the European Microsoft Windows NT 
Academic Centre (EMWAC).  Binaries are available for 
Intel and DEC Alpha architectures. HTTPS is 
multi-threaded, understands HEAD and GET methods, 
supports Forms and CGI-BIN scripts, and runs as a Windows 
NT service.

HTTPS (For HTTP Service) can be configured via the control 
panel, is integrated with the WAISS server, and logs HTTP 
transactions in the event logger. Available at: 
file://emwac.ed.ac.uk/pub/https/HSI386.ZIP (Intel version), 
HSALPHA.ZIP (DEC Alpha version), HHTPS.TXT 
(description of the server)

*Recommendation
GOPHERS v0.6	Free

This is a Windows NT Gopher server for Windows NT 
produced as part of the European Microsoft Windows 
NT Academic Centre (EMWAC).  Binaries are available 
for Intel and DEC Alpha architectures. This gopher 
server is multi-threaded, and runs as a Windows NT 
service. It can be configured via the control panel. 
Available at: 
file://emwac.ed.ac.uk/pub/gophers/GSI386.ZIP (Intel version), 
GSALPHA.ZIP (DEC Alpha version), MESSAGE.TXT 
(description of the server)

*Recommendation
WAISS v0.6	Free

This is a Windows NT WAIS server for Windows NT produced as 
part of the European Microsoft Windows NT Academic Centre 
(EMWAC). It inclues an indexing tool, WAISINDX that lets you
index documents in a number of formats. This is the easiest
to set up WAIS server I've seen, and it is well integrated
with the Gopher and HTTP servers. 

Binaries are available for Intel and DEC Alpha 
architectures. This WAIS server is multi-threaded, and 
runs as a Windows NT service. It can be configured via 
the control panel. Available at: 
file://emwac.ed.ac.uk/pub/waistool

Downright speculation
NT-Perl	Free

This is a Windows NT implementation of Perl v4.036, ported by Intergraph.  

Available at: 
file://emwac.ed.ac.uk/pub/ntperl.zip.

UNIX SERVERS

Recommendation
SMBServer v1.6	Free

SMBServer includes a UNIX-based SMB file and print server, 
as well as a UNIX SMB client and a NetBIOS nameserver (NBNS). 
It can be used with clients such as Windows for Workgroups, 
Windows NT, OS/2, Pathworks, and LanManager for DOS. This 
means that it can attach to Windows NT and WFW servers or 
mount portions of the UNIX file system on these machines. 
You can also print from UNIX to an SMB printer by adding 
an entry in /etc/printcap. It supports username/password 
security, umask support, guest connections and system 
attribute mapping. SMBServer is being run under Linux, 
SunOS, Solaris, SVR4, Ultrix, OSF1, AIX, BSDI, NetBSD, 
Sequent, HP-UX, SGI, FreeBSD, and NeXT.

Available at:
file://nimbus.anu.edu.au/pub/tridge/server/tarred/smbserver-1.6.03.tar.gz 

WAN CONNECTIVITY

Suggestion
Niwot synchronous board	 $695

This Niwot synchronous adapter comes with a packet driver 
that works with PCROUTE or KA9Q, and can handle speeds up to T1. 

Niwot Networks, (303)444-7765

Suggestion
RISCom N1 single port card	$495
N2 dual port card

This board is supported by BSD/386, and supports HDLC at 
56 Kbps for connection to Cisco routers running PPP. 

SDL Communications, Inc.; (508)238-4490 

Suggestion
Livingston Portmaster IRX-114 terminal servers

Livingston Enterprises; (800)458-9966, fax: (510)426-8951, 
email: doug@livingston.com

Suggestion
Morning Star Routers

Morning Star Technologies, Inc; (614)451-1883, (800)558-7827, 
fax: (614)459-5054, email: marketing@morningstar.com, 
support@morningstar.com, ftp archive: ftp.morningstar.com, 
WWW server: http://www.morningstar.com

Suggestion
Tylink ONS-150 CSU/DSU

This is a reasonably priced T1 CSU/DSU. 

Capella Networking; (415)591-3400, (408)225-2655, email: dstolz@capella.com

ROUTERS AND BRIDGES

Recommendation
KA9Q	
Educational Use	Free
Commercial Use	$50

KA9Q includes routing and packet filtering capabilities, along 
with a variety of other client and server capabilities. See 
the listing under Servers. 

Suggestion
PCRoute v2.24	Free

This package can convert a PC into a TCP/IP router. It doesn't 
require more than 1 Mb of memory, and works fine on an 8088, 
although faster machines are recommended. This is a fast and 
reliable router and highly recommended for routing between Ethernets. 

Available at file://ftp.acns.nwu.edu/pub/pcroute/readme.1st (Readme file)
file://ftp.acns.nwu.edu/pub/pcroute/readme.pcroute.doc (PCRoute documentation)
file://ftp.acns.nwu.edu/pub/pcroute/pcroute2.24.tar.Z (executables)
file://ftp.acns.nwu.edu/pub/pcroute/pcroute2.24.src.tar.Z (source code)

Vance Morrison, LANport, Inc.; 2040 Polk Street #340, 
San Francisco, CA 94109; (415)775-0188, email: lanport@cup.portal.com

Suggestion
PCBridge v2.77	Free

Originally by Vance Morrison of Northwestern, PCBridge has been taken 
over by  Alessandro Fanelli and Luigi Rizzo. The latest version of 
PCBridge is now ROMable. The  
software is available at file://pical3.iet.unipi.it/pub/bridge/bdg277.tar.Z

Alessandro Fanelli, Luigi Rizzo (luigi@iet.unipi.it), 
Universita` di Pisa - via Diotisalvi 2, 56126 Pisa, Italy ; 
+39-50-568533, fax:  +39-50-568522

Downright Speculation
Drawbridge v1.1

Drawbridge is a bridging filter that requires two ethernet cards. 
It is comprised of three programs: Filter, Filter Compiler and Filter Manager.

It is available at 
file://net.tamu.edu/pub/security/TAMU/drawbridge-1.1.tar.gz, 
drawbridge.README,  drawbridge-1.1-des.tar.gz

Downright Speculation
KarlBridge v1.41

This software, which uses WATTCP, provides a two port 
Ethernet to Ethernet bridge that can filter based on any 
Ethernet protocol, including IP, XNS, DECNET, LAT, 
EtherTalk, NetBEUI, Novell IPX, etc. It will also 
act as an IP firewall by filtering IP packets based on 
IP address/network/subnet combinations and socket numbers. 
It can also filter DECNET and AppleTalk Phase 1 & 2 packets. 
It now supports SNMP queries for remote management. Novell 
SAP and NCR WaveLAN filtering are coming in a future release. 
Available at file://128.146.1.7/pub/kbridge/kbridge141.zip

TROUBLESHOOTING

Downright Speculation
Windows Ping	free

Available at:
file://microdyne.com/pub/incoming/ws_ping.zip, 
file://ftp.usma.edu/pub/msdos/winsock.files/ws_ping.zip

John Junod; zj8549@trotter.usma.edu; junodj@gordon-emh2.army.mil
NCOIC, Technology Integration Branch, Computer Science School, 
FT Gordon, GA 30905; (706)791-3245  AV:780-3245

Downright Speculation
DOS Ping	free

Available at:
file://ftp.usma.edu/pub/msdos/misc/ping.exe 

Downright Speculation
Traceroute	free

A version of traceroute for DOS, available at:  
file://biochemistry.bioc.cwru.edu/pub/trumpet/tcp201.zip

There are also versions of ping and traceroute included with Trumpet Winsock. 

Downright Speculation
SNMP monitor	Free

An SNMP monitor for Sun, available at:
file://sun.soe.clarkson.edu/pub/packet-drivers/snmpsrc.zip.  
Also available at file://enh.nist.gov/misc/snmpsrc.zip, 
snmpsup.zip, snmpsun.tar_Z

Suggestion
Fergie	Free

Fergie is a packet monitoring and grabbing tool that supports SNMP 
and supersedes The Beholder and Gobbler. Spectre is a network 
host profiler. Tricklet is a set of SNMP utilities.

Fergie is available at file://dnpap.et.tudelft.nl/pub/Fergie/frgbin2.zip. The
source code is available at file://dnpap.et.tudelft.nl/pub/Fergie/frgsrc2.zip. 

To get on the Fergie mailing list, send mail to: request@dnpap.et.tudelft.nl

Suggestion
Beholder - The Next Generation (BTNG)	Free

BTNG is an RMON compatible Ethernet monitor for OS/2, 
SunOS and Ultrix. Tricklet is a set of SNMP utilities for 
OS/2 and UNIX. To run these tools under OS/2, you will need 
an Ethernet card with an NDIS driver for OS/2. Available at:
file://dnpap.et.tudelft.nl/pub/btng/README (Readme file)
file://dnpap.et.tudelft.nl/pub/btng/btng41exe.zip (OS/2 binaries)
file://dnpap.et.tudelft.nl/pub/btng/btng41src.zip  (OS/2 source)
file://dnpap.et.tudelft.nl/pub/btng/BTNG.FAQ  (Frequently Asked Questions)

Suggestion
NetProbe	Free

An unsupported utility from 3Com that can decode XNS,
TCP/IP, ICMP, AppleTalk, IPX/SPX, SMB, and other protocols, 
but only supports the Etherlink, Etherlink II, EtherLink 
Plus and Token Plus adapters. Available on CompuServe in 
the 3Com forum as EPROBE.ZIP in lib 5, unsupported utilities.

Downright Speculation
Netwatch	Free

Essential network debugging tools for the PC.  Available at 
file://netlab.usu.edu/netwatch.dir/netwatch.exe. 

Recommendation
Ethload v1.04	Free

This is an Ethernet load monitor that gives all kinds of useful
statistics on your network, including breakdowns by protocol
(supports IP, NetWare, OSI, DECNet, NetBEUI), source or destination,
ports, etc. Very useful. 

Available at file://oak.oakland.edu/pub/msdos/lan/ethld104.zip. 
Also available at file://wsmr-simtel20.army.mil/<msdos.lan>/ethld104.zip.


*Recommendation
EtherDump v1.04	Free

This is a tracing program, similar to TCPDump. However, the output
isn't quite as sophisticated or easy to read, although it certainly
is voluminous. 

Available at:
file://oak.oakland.edu/pub/msdos/lan/ethdp104.zip 
file://wsmr-simtel20.army.mil/<msdos.lan>/ethdp104.zip
file://ftp.cdrom.com/.2/SimTel/msdos/lan/ethdp104.zip


*Downright speculation
SNMPMAN

SNMPMAN is an SNMP-based network monitoring 
package written by Abner Correia, Jorge Pires,
and Tiago Silva (snmpman@di.fc.ul.pt). 

Information on SNMPMAN is available
via http://www.fc.ul.pt/software/snmpman.html. 

Available at:
file://ftp.fc.ul.pt/pub/networking/snmp/snmpman.zip 

SNMPMAN, Faculdade de Ciencias da Universidade de
Lisboa (Departamento de Informatica), Campo Grande-Bloco
C5, 1700 LISBOA, Portugal; voice: +351 1 7510003,
fax: +351 1 7577831. 
 
*Downright speculation
NetGuardian v1.1

NetGuardian is an SNMP-based network monitoring 
package written by Paulo Sergio Mena,
Ricardo Machado de Oliveira and Rui Santos Antonio,
(netguard@di.fc.ul.pt). It requires Ling Thio
and Dirk Wisse's WINSNMP.DLL.

Information on NetGuardian is available
via http://www.fc.ul.pt/software/netguard.html. 

Available at:
file://ftp.fc.ul.pt/pub/networking/snmp/netguard.zip 
 
NetGuardian, Faculdade de Ciencias da Universidade de
Lisboa (Departamento de Informatica), Campo Grande-Bloco
C5, 1700 LISBOA, Portugal; voice: +351 1 7510003,
fax: +351 1 7577831. 

*Downright speculation
NetAddress v1.1	Free

This program collects Ethernet addresses and various statistics,
including protocols used, IP and IPX address, AppleTalk name,
etc.

Available at:
file://oak.oakland.edu/pub/msdos/lan/net-ad11.zip
file://ftp.cdrom.com/.2/SimTel/msdos/lan/net-ad11.zip   
 
TCP/IP AND NETWARE

Downright speculation
BYU Netware shell drivers	free

Allows you to build an IPX.COM that runs over packet drivers.  
Works by  providing .obj and .lan files for the Neware shell 
generation program, shgen.exe. Running shgen.exe produces netX.com 
as well as an ipx.com for your interface card. Again, I've had 
better results with ODIPKT than with this. 

Available at:
file://vax.ftp.com/pub/packet.driver/pubdom/byu  

Downright speculation
Intel PDIPX	free

Another way of building an IPX.COM that runs over packet drivers.  

Available at:
file://ftp sun.soe.clarkson.edu/pub/packet-drivers/intel.pdipx.zip 

Suggestion
PDEther v1.03

An ODI over packet driver shim. See entry under Drivers and Shims. 

Recommendation
Odipkt v3.0

A packet driver over ODI shim. See entry under Drivers and Shims. 

UNCLASSIFIABLE (BUT INTERESTING) STUFF

Downright speculation
GIGO Free

This has nothing to do with TCP/IP, but rather is a UUCP 
packet to FidoNet *.PKT translator. For info, contact: 
gigo-r@wmeonlin.sacbbx.com. Available at 
file://ftp.netcom.com/pub/jfesler/gigo.zip




------------------------------ END OF PART 2 ------------------------

Please send comments to:

Bernard Aboba
Author of:
The Online User's Encyclopedia, Addison-Wesley, 1993
The PC-Internet Connection, Publisher's Group West, 1994 
email: aboba@netcom.com
WWW page: http://www.zilker.net/users/internaut/index.html






-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 1994 17:42:13 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Fake network addresses

John Kalucki (johnk@gordian.com) wrote:
: Chris Rohrer (crohrer@advtech.uswest.com) wrote:
 
: : I was of the understanding that there is a Class A or maybe a Class B
: : address that is reserved and not allocated to anyone on the Internet,
: : The purpose is to alllow private networks that do not/can not/will not
: : connect directly to the Internet the opportunity to have an address space
: : that will not conflict with or confuse anyone's routing tables.
 
: 1597  I    Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, "Address
: 	   Allocation for Private Internets", 03/17/1994. (Pages=8)
: 	   (Format=.txt)

There's a response to this RFC by E.Fair (Apple), E.Lear (SGI) et
seq. that notes that it is not unusual for networks originally
designed as "will not connect" to be either connected to other
corporate private nets or eventually to the whole world.

Frankly I think you're making a decision to re-number at some
point in the future if you're using "reserved" addresses, and
if you can't quantify and budget for the cost of renumbering
you shouldn't use "reserved" addresses for real computers.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 320 Miller, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)
 msen info addresses:   info@msen.com - $20/mo public access Internet
 			occ-info@msen.com - Online Career Center jobs database

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 17:42:46 GMT
From:      aboba@netcom.com (Bernard Aboba)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.answers,news.answers
Subject:   comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 3 of 3

Archive-name: ibmpc-tcp-ip-faq/part3

comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 3, 7/1/94

COMMERCIAL PRODUCTS

*Downright speculation
TCP/IP BOOT-PROM

The TCP/IP BOOT-PROM is a TCP/IP based Boot ROM available for about
34 Ethernet and Token Ring PC network controllers. It uses the protocols
BOOTP and TFTP to download the DOS operating system and network software
from a TCP/IP based servers like UNIX, NetWare, OS/2 or Windows NT.
Several network software like PC-NFS, PC/TCP, PC-Interface, B&W NFS,
LAN WorkPlace, NetWare, NetWare/IP, LanManager, TUN and other are supported
on the diskless client site.

The builtin application interface allows to access the ROMs TCP/IP stack
for building low cost terminals or downloading other operating systems
e.g. UnixWare.

Dirk Koeppen EDV-Beratungs-GmbH, Germany
Phone: +49 69 89 3000, Fax: +49 69 89 3004, email: dirk@incom.de


Downright Speculation 
3Com TCP w/ DPA v2.0

3Com; (800)638-3266


Downright Speculation 
Internet in a Box

This is a much ballyhooed product, which will include a special version
of Ed Krol's book, alongside a complete suite of applications. Rumour
has it that the installation procedure is quite streamlined in that it
sets up all the stack as well as all the applications in one fell swoop.

Spry Inc.; 1319 Dexter Ave North, Seattle WA 98109; (206)286-1412, email:
sales@spry.com


Downright Speculation 
AIR for Windows

Spry Inc.; 1319 Dexter Ave North, Seattle WA 98109; (206)286-1412, email:
sales@spry.com

Downright Speculation
Teemtalk for DOS
Teemtalk for Windows

Teemtalk supports connections over ARPA Services 2.0+ (HP), Beame & Whiteside, 
CTerm (DEC), Int-6B (Novell NASI), Int-14, MS LanManager, Lan Workplace, LAT, 
NetBIOS, Netmanage Chameleon, OSLAN (ICL), Pathway, PC-NFS, PCTCP, 
TELAPI (Novell), and also support Windows Sockets, and regular or BIOS level
serial connections. 

Emulations include  VT 52/100/220/240/320/340/640, Viewdata 
40/80/Split, DG200, HP2392A, Tek4014, Regis and W2119. Protocol support 
Kermit and Xmodem. It also supports DDE. 

Pericom,  1-609-895-0404 (US) and 0908-265533 in the UK.

Suggestion 
BW-NFS v3.0c

NFS is implemented as a TSR; the TCP stack is a device driver.  
The package supports SLIP, NFS client, Telnet (VT220 and
3270 emulation), finger, talk, ftp, and SMTP mail.  It also can act as a
server for telnet, FTP, finger, and lp.  The 3270 emulation is reportedly
OK.

Beame & Whiteside Software Inc.; 706 Hillsborough St., Raleigh, NC 27603-1655
(919)831-8989, tech: (919)831-8975, fax: (919)831-8990, email: sales@bws.com


Suggestion 
Chameleon v3.15	$125 (upgrade price) 
ChameleonNFS v3.15
$400

Chameleon is a Windows 3.x TCP/IP implementation that can handle FTP,
Telnet (3270, ANSI, VT-52, VT100 and VT220 emulation), ping, SMTP, POP2,
and NFS (client and server) all in multiple windows, simultaneously.  The
package also supports DNS via an implementation of BIND, as well as SNMP.
ChameleonNFS is compatible with the IPX/Link product for Netware from
NetManage. Most of the code resides in a DLL. Chameleon supports multiple
interfaces, and can route betweenthem. The newest release supports CSLIP,
PPP and NNTP.

NetManage, Inc.; 20823 Stevens Creek Blvd.,Cupertino, CA 95101;
(408)973-7171, fax: (408)257-6405, email: support@netmanage.com


Downright speculation 
Distinct Network Applications v3.02	$395
Distinct Software Development Kit	$495 
Network & Developer Combination	        $695

Distinct TCP/IP for Windows - Network Applications v3 integrates several
Windows based TCP/IP utilities under a single interface.

These include: Distinct Telnet which allows multiple concurrent Telnet
sessions on different remote hosts, allowing you to cut and paste
information between these systems as well as between the systems and your
local host. Distinct FTP is a drag and drop FTP which allows you to drag a
local or remote file to a local printer. Distinct FTP has both a client and
a server; this means that files can be also transferred by selected users
from PC to PC (password protection is included). TFTP provides file
transfer services to  communications servers and routers that do not have
FTP. Network Monitor monitors host-to-host communication and data
transmission traffic and is able to capture network traffic to a file.


Distinct TCP/IP for Windows - Software Development Kit

This product is engineered as 100% DLL, and requires only 4 Kb DOS memory
for a driver. The product supports up to 64 concurrent sockets, and buffers
are allocated and deallocated as they open and close.

Includes three development kits:

Distinct TCP/IP for Windows - Berkeley-style Sockets (TCP, UDP, ICMP,
Telnet, FTP)

Distinct TCP/IP for Windows - Windows Sockets ver. 1.1

Distinct RPC - a complete ONC RPC/XDR toolkit for Windows (Client and
Server RPC over both TCP and UDP; includes RPCGEN)

Distinct Corporation;14395 Saratoga Avenue, Suite 120, Saratoga, CA 95070;
(408)741-0781, fax: (408)741-0795, email: chris@distinct.com

Distinct Corporation; P.O. Box 3410, Saratoga, CA 95070-1410;
(408)741-0781, email: mktg@distinct.com

Suggestion 
Everywhere Access

This is a remote access package for TCP/IP, including support for telnet
server, FTP and Kermit transfers, VT100, VT220, VT300 emulation, password
security. Includes versions working with WATTCP as well as other
implementations.

Supro Network Software Inc.; P.O. Box 18, Warsaw, Ontario, Canada K0L-3A0;
(705) 652-1572, email: info@snsi.com

Downright Speculation 
Fusion

Pacific Software; (800)541-9508

Downright Speculation 
ICE/TCP

James River Group; 125 North First St., Minneapolis, MN 55401;
(612)339-2521, email: jriver@jriver.com


Downright Speculation 
Lanera TCPOpen/Standard v2.2

Lanera Corporation; 516 Valley Way, Milpitas CA 95035; (408)956-8344,
email: lanera@netcom.com


Downright Speculation 
Lantastic for TCP/IP

Artisoft, Inc.;  691 East River Road, Tucson, AZ 85704; (602)293-6363

Suggestion   
LAN Workplace for DOS v4.1r8

Novell, Inc.; 122 East 1700 South, Provo, UT 84606; (800)772-UNIX


Downright Speculation 
NS & ARPA Services v2.5

Hewlett-Packard; 19420 Homestead Rd., Cupertino, CA  94014; (408)725-8111


Downright Speculation 
The Wollongong Group's PathWay Access

A family of complete IP Services for DOS/Windows, Macintosh, OS/2, and VMS
systems, as well as SNMP and X-400/X-500 products.  Wollongong has been
providing IP solutions for over 14 years.

PathWay Access for DOS/Windows 3.0 - This product has been significantly
enhanced with the majority of changes being to the Windows applications,
emulations and remote access. Integrated into Windows, the
applications are Windows Sockets compatible. Support for all NOS, extensive 
DBMS and third party support.


VT100-220, VT320-330, VT240-340, 3270 mods 2-5, 3179g, tek4010-4105, drag
& drop FTP client/server, LPR/LPD/IPR, NetBIOS, NDIS/ODI/PDS/ASI, 
SLIP/CSLIP/PPP/X.25, MIB2 SNMP agent, Scripting, Graphical Remapping, NFS, 
SMTP/IMAP/POP(MIME), NetNews reader.

Pricing:  Many different pricing schemes exist for these products based on
customer requirements, from shrink-wrap bundles to expandable licenses that
can be added to in any number, with discounts based on accrued amount levels.
Aggressive educational discounts and trade-up pricing are offered.

PathWay Access (Single User-DOS/Windows or Mac) - $350
Client NFS module - $95
API - $200

Technically supported evaluations are provided free of charge to qualified
individuals.  Also offered is a demonstration disk tour of PathWay Access 3.0
free and yours to keep.

The Wollongong Group; 1129 San Antonio Rd, Palo Alto, CA 94303;
800-872-8649 (Outside Cal), 800-962-8649 (In Cal), (519)747-9900
(Canada), +31 2503-24142 (Europe), (415)962-7134,
(415)962-7247, email: sales@twg.com


Downright Speculation 
PC-LINK for DOS 
PC-LINKW for Windows

X LINK Technology; 741 Ames Avenue, Milpitas CA 95035; (408)263-8201, fax:
(408)263-8203, email: tom@xlink.com


Suggestion 
PC-NFS v5.0	$395

PC-NFS from SunSelect (a Sun Microsystems business) includes a TCP/IP
stack, TCP/IP utilities under DOS and Windows, an NFS client, remote
printing support, SNMP, and Windows Sockets. Add-on packages support email
and advanced telnet. A Programmer's Toolkit is available which provides DOS
and Windows support for TCP/IP over sockets and XTI, as well as TIRPC, NIS
and supporting APIs.

SunSelect; 2 Elizabeth Drive, Chelmsford, MA 01824-4195;(800)24-SELECT or
(508)442-0000; fax: (508)250-5068


Recommendation 
PC/TCP v2.2	$400 
Kernel Only	$200

PC/TCP v2.2 offers a solid implementation of TCP/IP for DOS, with some
Windows applications.  It includes NFS for UDP or TCP, remote login
(telnet, rlogin, supdup) with a variety of terminal emulators, file
transfer (FTP, TFTP, rcp), electronic mail and news (pop2, pop3, pcmail,
mail, SMTP, NNTP), printing (LPR and print redirection) and informational
utilities (whois, ping, finger, host). Some kerberos support is available
to domestic customers. If used alongside ConcordCommunications Mapware
controllers, this product is capable of handling both OSI and TCP/IP
concurrently. 3270 support is OK.

It is available for Ethernet (DIX or 802.3), Token Ring, SLIP, PPP,
LocalTalk and X.25 interfaces, over packet drivers, ODI drivers, NDIS
drivers, banyan drivers, and ASI drivers.

This package does not route; you are therefore restricted to installing it
with PPP, SLIP or Ethernet, but not some combination of the above.


PC/TCP is incompatible with Stacker. As of version 2.2, the Windows
applications have been improved. New to Windows support is the ability to
mount and unmount NFS drives from within Windows, and to use PCNFSD printer
services from Windows.

The 2.2 manual includes a 6-page install guidelette, and now offers a
menu-driven installation and configuration program.

FTP Software, Inc.; 2 High St., North Andover, MA 01845; (800)282-4387,
Support: 1-800-382-4ftp, fax: (508)794-4477, email: sales@ftp.com


Downright Speculation 
Piper/IP	$375 
Developer's Kit	$375

Piper/IP runs under DOS protected mode, using less than 6K of lower DOS
memory. The company claims that FTP transfers take place at100K/second over
a LAN. They also claim the ability to run concurrrently with NetWare,
VINES, LAN Manager, LAN Server, and WFW. The package includes a FTP, Telnet
(client and server), and SMTP.


Ipswitch, Inc.; 580 Main St, Reading, MA 01867; (617)942-0621, email:
ub@ipswitch.com


Downright Speculation 
Super-TCP v3.00r	$495 
Super-NFS client v3.00r

SuperTCP supports telnet (3270, VT100, VT102, and VT220 emulation), talk,
SMTP, ftp, ping, and with Super-NFS, NFS client.  SuperTCP supports both
TCP/IP and Novell IPX protocols, as well as SNMP.

It is written as a DLL, although a TSR version of the protocol stack is
also available for those who want to use DOS as well. Network statistics
(arp, ICMP messages, etc.) are available. 

Frontier Technologies;10201 North Port Washington Road, Mequon, WI 53092,
(414)241-4555, fax:(414)241-7084, email: tcp@frontiertech.com


Downright Speculation 
TCP/IP for DOS v2.10

IBM; Dept. E15, P.O. Box 12195, Research Triangle Park, NC 27709;
(800)IBM-CALL


Downright Speculation 
TCP/IP Utilities for LanManager v1.0 
Windows for Workgroups TCP/IP 
Windows NT

Microsoft; One Microsoft Way, Redmond WA 95052-6399; (206)882-8080

Downright Speculation 
TCP/2 for DOS

Essex Systems; (508)532-5511


Downright Speculation 
TTCP v1.2r2

Turbosoft Pty Ltd; 248 Johnston St., Annandale, NSW Aus. 2038; +61 2 552
1266, email: info@abccomp.oz.au 


XWARE 


Suggestion 
PC-Xview

PC-Xview is available for DOS or Windows, supporting use of X over the
network.  It also supports NCD's Xremote protocol that allows X to run over
a modem much faster than could be achieved running a standard X package
over SLIP or PPP.

Network Computing Devices, Inc.; (800)793-7638


Downright Speculation
MicroX for Windows

A demo of this product is available as:
file://ftp.cica.indiana.edu/pub/pc/win3/uploads/xwindemo.zip

StarNet Communications, Corp. 


Downright speculation 
XVISION	$449

XVision allows X applications to run under Windows.  You have a choice of
running each X app in its own Window, or all X applications within one big
Window.

VisionWare, Ltd.; 57 Cardigan Lane, Leeds, England; 44-0-532-788858,
(800)222-0550, fax:44-0-532-304676

Downright Speculation 
DesQView X

DesQView X integrates networks of DOS and UNIX machines using the X-Windows
protocol, allowing DOS machines to act as X-Windows clients and servers.


Quarterdeck Office Systems; 150 Pico Boulevard, Santa Monica, CA90405;
(213)392-9851, fax:(213)399-3802 Development Software Epilogue Technology:
Includes source code. info@epilogue.com, fax: (505)271-9788

Spider Systems Available for many architectures. ian@spider.co.uk, fax:
44-31-555-0664

Marben Produit 
TCP/IP Source 

available, fax: 33-1-47.72.55.00

Network Research 
FUSION 
Source available, fax: 1(805)485-8204


------------------------------ END OF PART 3 ------------------------

Please send comments to:

Bernard Aboba
Author of:
The Online User's Encyclopedia, Addison-Wesley, 1993
The PC-Internet Connection, Publisher's Group West, 1994 
email: aboba@netcom.com
WWW page: http://www.zilker.net/users/internaut/index.html



-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 18:19:30 +0000
From:      mickm@mickm.demon.co.uk (Mick Morgan)
To:        comp.protocols.tcp-ip
Subject:   Re: THE winsock??

In article <6.14403.716.0NAEA18E@spacebbs.com>
           philip.burton@spacebbs.com "Philip Burton" writes:

> [stuff deleted]
> 
> Damn shame, though.  There are some good parts of OSI.  Too bad the 
> purists didn't design the OSI applications to run on top of the TCP 
> layer.
> 
> -- Phil Burton --    philip.burton@spacebbs.com
> - Palo Alto, CA -
 
-- 
Mick Morgan                             Home 'phone 0508-470938
CCTA ("Can't Change The Acronym")       Work 'phone 0603-694927
                                        Email mickm@mickm.demon.co.uk

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 19:20:42 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Best way to change IP addresses for a group of systems

In article <1994Jul5.153915@siacbbn.com>
           adiwan@siacbbn.com "Arif Diwan (BBN" writes:

>In article <2v1902$8km@ccnet.ccnet.com>,
>        jantypas@ccnet.com (John Antypas) writes:
>...
>  a) is there a way I can give my hosts TWO IP addresses on their interfaces?
>  (Old IP and New IP) for say, a month.
>
>You can assign multiple IP addresses to an interface. I know of three ways:
>
>                                -- Arif Diwan (adiwan@bbn.com)
>                                                617-873-6274

That sounds OK, but (sorry if it's a dumb question) how does the
process know which IP address to use.  I'm thinking of a user on this 
machine (say) telnetting to another host... which IP source address
is used if there are two (or more) assigned to the interface...?


-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 19:53:09 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing IP address extensions

In article <1994Jul6.185228.3682@bay.cc.kcl.ac.uk>
           udaa055@bay.cc.kcl.ac.uk "Andy Harper, KCL Systems Manager" writes:

>An oft discussed question is how the IP addresses used on Internet can be
>extended now that the explosion in personal computers and connectivity has left
>the 32-bit address space looking a bit sick! Rumour has it that, if growth
>increases at the same rate as currently, we'll run out of addresses in the near
>future.

[stuff deleted]

>So, what options are there that don't require all and sundry who use Internet
>to spend wads of cash and/or find upgraded network applications that understand
>new addressing formats?
>
>Andy Harper
>Kings College London

Yes, wads of cash, it's bound to be.  I've follwed all the stuff on IPng, 
TUBA, SIPP CATNIP and now Big Ten (?).  None of them will be a low-cost
migration.

I just think that people will become more careful over address allocation.
I have already floated at least two heretical ideas and one neutral one...

The neutral one is that DHCP will make life a lot easier and allow
N temporary users (e.g. PCs) to share M addresses on a " lease " basis.

The heretical ideas:

1.	there are many more TCP/IP users who don't want to connect
to the Internet and fewer organisations *need* to.  Most of academe
(as your good selves) is connected.  Corporations who have "a few"
technical people who can justify Internet connectivity will
probably settle for clever use of firewalls and proxy telnet, ftp etc.

2.	there may come a time when IP address space is so scarce
that some people will offer it for sale and some will buy it.... well,
it happens with some very unusual commodities....  Wimbledon tickets,
cherished number plates, antique toys, trade marks... why not:

	"For sale: 123.1.29 to 32  only one owner, $5,000 o.n.o."  
	"PLUS - an X.21 PPP link into our Internet router, 
	only $4,000 pa."

There must be many academic bodies with spare address space?

Any thoughts?

Phil

-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 20:41:10 GMT
From:      wdawson@willard.atl.ga.us (Willard Dawson)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: Obtaining Ethernet/MAC Network Addresses From Sun System

wllarso@sandia.gov (William L. Larson) writes:

>I am interested in identifying the Ethernet/MAC address for the network
>interfaces on a Sun computer running 4.1.3.  My situation is that I
>have three Ethernet interfaces plus one FDDI interface, but Sun only
>reports a single MAC address for the system which is for the first
>Ethernet interface.  All other network interfaces report the same MAC
>address.
 
>Is anyone aware of any mechanism for obtaining the Ethernet addresses
>for the second and third Ethernet interfaces along with the MAC address
>for the FDDI interface?
 
>Responses via Email are most appreciated.  Thanks

Please summarize your findings to the newsgroup.  Thanks.

Oh, and just to complicate your data collection by adding this data
point by news instead of by email:  There is a bit of code that is
referenced in one of the SunSolve documents that purports to show
ethernet addresses.  However:

  1)  Due to a problem on SunSolve, or in the original document, the
      source code is obviously not clean, with the beginning of the
      program re-appearing in the middle of the listing.
  2)  Even after being fixed up, the program does not compile under
      SunOS nor under Solaris 2.3.  That is, there are undefined
      DEFINE symbols that do not exist under /usr/include/*.h nor in
      /usr/include/sys/*.h... the code is probably BSD stuff, instead of
      SunOS stuff.

So, I've not really helped you, yet... which is why I'm interested in
seeing your answers.  Hopefully, such exists for Solaris 2.3 as well.

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 03:30:23 GMT
From:      samg@netcom.com (Sam Ghandchi)
To:        comp.protocols.tcp-ip
Subject:   Need to Find TTCP???

Hi 

I am looking for TTCP.  Could you tell me where 
I can find it?  

TIA,
- Sam Ghandchi
samg@netcom.com


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 03:32:13 GMT
From:      samg@netcom.com (Sam Ghandchi)
To:        comp.protocols.tcp-ip
Subject:   Any Info on TK/TCL would be appreciated


Is there any newsgroup where TK/TCL expert programmers
discuss topics?

Any info is appreciated.

Regards,
- Sam Ghandchi
samg@netcom.com


-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 16:45:52 -0700
From:      tbrink@crl.com (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

mike@ozonline.com.au (Michael Bethune) writes:

>Anyone got any comments about the behaviour of variable subnetting
>used with say, OSPF based routing.
 
>Specifically, All host based TCP/IP implementations that I'm aware of only
>recognise non-variable sub-netting, ie through RIP or other implementation.
 
>My understanding is that such hosts will make sub-optimal routing decisions
>without full knowlege of the network significant part of the IP address.
 
>Comments?

OSPF is more practical in a Wide Area Network sense, not a LAN.  We use
OSPF for our WAN, then flood RIP (or default route) into the LAN.  Default
Route works better, as the local subnet mask will probably not do for RIP.
-- 
    /|                          Tom Brink
 \`o.0'                         tbrink@crl.com
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 09:58:27 +0000
From:      tfl@psp.co.uk (Thomas F Lee)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

In article <9407070706.AA01007@ariake.nwk.cl.nec.co.jp>
           mweiss@nwk.cl.nec.co.jp "Michael J. Weiss" writes:

> Can someone explain what DNS is?

DNS = Domain Name Server

A DNS server is a _server_ which resolves _Host Names_ into _IP Addresses_.
A host name is a textual name for a particular host on a TCP/IP internetwork
whilst the IP address is a 32-bit address which the lower levels of the
protocol require.  

DNS is covered by two rfc's: RFC1034 which describes the concepts and 
faciliteis and RFC1035 which details the implementation and specification.
The most common implementation of DNS is called BIND - Berkely Internet
Name Domain server.
 
> Also, what does it have to do with DHCP?

Not a lot really.  DHCP, Dynamic Host Configuration Procotol, is a protocol
which a host uses a server to give the host an IP address.	If a host
does not know or have it's IP address, DHCP could be used to deliver it.
This has a lot to do with both diskless workstations (which use bootp to
determine ip address and then tftp to load the hosts's boot image).  DHCP
is based on bootp.

Where I think there may be a connection relates to the inclusing of DHCP and
WINS in Daytona.  In Daytona NTAS, the NTAS box can be a DHCP server. NT
and WfWG boxes can then use the server to give the client's their IP address.
The connection is that DHCP will then pass WINS (Windows Internet Name Service)
the IP address so that WINS can then be used as an alternative to DNS
for resolving IP addresses.  WINS is a part of Daytona (server bits being
in Daytona NTAS and client facilities in Daytona Desktop, and in the 
Wolverine client for W4WG). 

We played with this a bit during last week and the DHCP stuff works
great.  Didn't really have much time to explore WINS though.  Documentation
on DHCP can be found on gowinnt.microsoft.com (there is a DHCP.DOC Word
document by J Allard - worth reading).  Additionally, see RFC 1531 
and RFC 1533.

Hope this helps.


Thomas
-- 
+-----------------+---------------------------+
! Thomas F Lee    !  Voice: 0628 850 077      !
! tfl@psp.co.uk   !  Fax  : 0628 850 143      !
+-----------------+---------------------------+

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 14:17:04 GMT
From:      gerryw@hpbrak42.uksr.hp.com (Gerry WINSOR)
To:        comp.protocols.tcp-ip
Subject:   IP Usage Billing package ?

Hi,

Anyone aware of a commercially available "TCP/IP Billing" package which'll
use actual IP usage rates as the billing calculation ?

GerryW

--
____________________________________________________________________________
**************
**** /_ _ ****   "Mr. Osborne, sir, may I be excused ?  
*** / //_/ ***    My brain is full."
****  /   ****                 		- Larson
**************

Gerry Winsor            HPDESK:      Gerry WINSOR/HP8005/OA
Hewlett-Packard Ltd     UnixMail:    gerryw@hpbrak42.uksr.hp.com
Mailstop Q3             X.400 :      WINSOR,Gerry/HP8005,OA/HP/GB/GOLD 400/HP
Cain Road, Bracknell    Telephone:   (+44) 344 362384
Berks.  RG12 1HN.       Fax:         (+44) 344 362199
United Kingdom          Telnet:      316-2384
			VoiceMail:   316-2384
____________________________________________________________________________


-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 15:26:15 GMT
From:      bear@world.std.com (William J Sanderson)
To:        comp.protocols.tcp-ip
Subject:   ARCHIE  request and its port and protocols

When performing ARCHIE lookups on the net, does ARCHIE user TCP or UDP or
both packets.  Also is there a "known" port for ARCHIE???

Thanks

Bill Sanderson
wsanders@ccmg.lotus.com


-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 17:20:40 GMT
From:      samg@netcom.com (Sam Ghandchi)
To:        comp.protocols.tcp-ip
Subject:   I am looking for an EXPERT TK/TCL PROGRAMMER $55.00/hr

I am looking for a TK/TCL Expert Programmer.  I can pay
$55.00/hr.  Knowledge of X.25/Frame Relay/SMDS/ATM and 
Fiber is a plus.
 
The contract will be a six month contract
with possibility to extend.  The location is the
Milpitas area. Please send resume and salary
history to: 

samg@netcom.com (Sam Ghandchi) 

PRINCIPALS ONLY PLEASE




-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 17:39:18 GMT
From:      mike@ozonline.com.au (Michael Bethune)
To:        comp.protocols.tcp-ip
Subject:   Variable Subnetting

Anyone got any comments about the behaviour of variable subnetting
used with say, OSPF based routing.

Specifically, All host based TCP/IP implementations that I'm aware of only
recognise non-variable sub-netting, ie through RIP or other implementation.

My understanding is that such hosts will make sub-optimal routing decisions
without full knowlege of the network significant part of the IP address.

Comments?

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 23:00:42
From:      tnemeth@immuno.imvs.sa.gov.au
To:        comp.protocols.tcp-ip
Subject:   Re: Does anyone know of a scriptable telnet for Sun (or anything else?)

In article <TJFS.94Jul8192506@golf.tadpole.co.uk> tjfs@golf.tadpole.co.uk (Tim Steele) writes:

>I'd like to be able to run a script, a bit like a uucp script, but to
>a telnet server.


Why don't you try the latest C-Kermit?  


-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 18:35:51 GMT
From:      gloria@cais.cais.com (Gloria Fu)
To:        comp.protocols.tcp-ip
Subject:   Help Configuring MacPPP????  and TCP

Hello!  I have been trying to configure my MacPPP on my computer.  I have 
actuallly tried MacSlip, InterSLIP and now have been steered toward 
MacPPP.  After reading the directions, I still get the message "MacPPP down".

I have a PB 180 with a Global Village Powerport Gold Internal Modem.  I 
have been told that because the modem is not Hayes compatible, it has led 
to problems with my provider.  The provider uses the basic Unix shell, 
but still I have had enormous difficulties trying to get the SLIP 
connection.  I don't even get a dial tone. 

Any suggestions?

Gloria Fu
gloria@cais.com

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 18:52:55 GMT
From:      skendric@fred.fhcrc.org (Stuart Kendrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting Appletalk+ethernet+SLIP internet

You need an IP router.  I've never heard of a software-based one which
will support dial-up via SLIP on one interface.  I think you are stuck,
without spending the bucks for a hardware-based solution.

--sk


In article <CsH34F.Dsn@discus.technion.ac.il>
s2929773@techst02.technion.ac.il (Yosefi Ori ) writes:

> Hi,
> 
> I wanted to know if there is any way I can connect an existing
> Appletalk network (consisting of an EtherTalk Zone and A localtalk zone)
> to the Internet Over a SLIP connection (Dial Up).
> 
> 
> I installed MacTCP on the computer with the modem and I can use the internet
> OK, but I can't manage to use the internet from another Mac (Not having a modem)
> 
> Is there any way to cause Macs to sends their Packets throuhgh another one?
> 
> Thank a lot for any help,
> 
> Ori Yosefi.


Stuart Kendrick
Network Admin
FHCRC

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 08:15:14 -0700
From:      jantypas@ccnet.com (John Antypas)
To:        comp.protocols.tcp-ip
Subject:   Is this a crazy idea?

Am I insane for thinking about this?

I have a client that would like to connect his office machine and
a few dialin employees to the Internet.  While the traditional solutions
would work, would the following also work?

- Client buys a 56Kb CSU
- Client gets a Portmaster terminal server or equiv.
- Provider provides an async framed PPP via the CSU to the portmaster.
- Everyone else just runs off the portmaster using it as a router.

Does this buy anything?  The portmaster can be had for about $900, a CSU
for about $300.
-- 
John Antypas@21st Century Softwware (jantypas@soft21.s21.com)

"God is too busy to create chaos and disorder in this world, he can't be
 everywhere at once all of the time,  That's why he made two year olds"
 "

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 21:44:04 GMT
From:      geertj@ripe.net (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   Re: Fake network addresses

In <2vmnhl$fma$1@heifetz.msen.com> emv@garnet.msen.com (Edward Vielmetti) writes:

>: : I was of the understanding that there is a Class A or maybe a Class B
>: : address that is reserved and not allocated to anyone on the Internet,
>: : The purpose is to alllow private networks that do not/can not/will not
>: : connect directly to the Internet the opportunity to have an address space
>: : that will not conflict with or confuse anyone's routing tables.
 
>: 1597  I    Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, "Address
>: 	   Allocation for Private Internets", 03/17/1994. (Pages=8)
>: 	   (Format=.txt)
 
>There's a response to this RFC by E.Fair (Apple), E.Lear (SGI) et
>seq. that notes that it is not unusual for networks originally
>designed as "will not connect" to be either connected to other
>corporate private nets or eventually to the whole world.

That really depends. First, I highly doubt that applications like
electronic door relays (for access control) will ever need public
access. You can think of this as a niche but we have cases where
people have more than 100000 of these devices. If you think they
need public address space; fine, but do realize that we will all
suffer because we will run out of address space much more quickly.
(I can tell; the RIPE NCC is the regional registry for Europe and
I make my living working on applications like these).

The second kind of applications are the enterprizes that want to
have a class B so they can assign a class C network number to
each of their 30-host subsidiaries, 15 in total, because this
makes administration very convienent. According to
current guidelines, their class B application would be denied and
they would get something like 8C's or some more if they can justify it.
Some organisations *really* want a B and RFC1597 gives them an
alternative.

We frequently get applications for organisations applying for a
class A so they can assign a B to each of their subsidiaries.
For Europe alone, we get something like 8 of these per year.
I hope you agree that it is a good thing that some of these
can be addressed using RFC1597. What to think of an electricity
company that wants an A to address each eletricity meter?

Please recognize that the vast majority of TCP/IP applications
is *not* Internet-connected. Why would they be forced to comply
to assignment efficiency guidelines when they could care less
about Internet connectivity? Again, RFC1597 provides an alternative.

The address space defined in RFC1597 makes certain that if such
an organisation wants external connectivity after all, there will
be no routing ambiguity. In contrast, if you would pick a random
number as suggested in RFC1627, say, network 15.0.0.0, you will
*never* be able to talk to HP (to which 15.0.0.0 has been 
assigned to). 
You think that is unrealistic? Talk to the network people at
my previous employer who had picked 194.0.0.0 as private address
space (194.0.0.0 is the class C block from which class C number
assignments are done in Europe).
In contrast, RFC1597 specifies that if you are using network 10.0.0.0,
that network will *never* show up on the Internet itself and your
firewall will *always* be able to speak to other organisations 
(even if they use network 10 too, their firewall would not, 
so you can talk to your firewall, the firewall can talk to 
their firewall, and their firewall can talk to their internal net 10). 
I fail to see how picking a number as per RFC1627 can guarantee this.
(and there is no such thing as address space that will never be
assigned; current Address Lifetime Expectency reports are about
using up *all* address space, including chopping up class A's
to smaller chunks for assignment).

Concerns that firewalls will not be needed in future network developments
will not hold either. While I agree that future authentication 
improvements will make life easier, it will take a long while for these
to get implemented. There is no guarantee that there will not be
programming errors which cause security flaws. There is no guarantee
that all machines in your network will be upgraded to the lastest,
safest, version. Someone might want to bring in his own machine
and connect it to your network.
If your bank would connect to the Internet in full, and a cracker
would use a flaw and get all data on your financial situation 
(including mortgages, loads and debts), you can do whatever you want
but your data will still be out there. A bank will very likely not
open up itself to this kind of liability.
If someone breaks into your engeneering machine, stealing 
confidential design data, you can close the security hole after the
fact but the competition will still have information on your future 
designs.
Therefore, people will continue to deploy firewalls.

We have to recognize that IPv4 will be here for a long time to
come. Whatever IPng will be decided in Toronto, it will take at
least 3 years for mature implementations to become available
and older equipment to die off.
After that, it will take a considerable  amount of time for
people to migrate, at least 5 years. In non-technical environments,
people usually plan to depreciate their equipment over a long
period so this time scale is not unrealistic.
We don't want to run out of address space in that time, do we?

One can think of forcibly getting address space back to the 
Internet Registries, as suggested in RFC1627. I think this will
not work. How would you react if someone would say: 'based on 
the current size of your network, we will reassign the top half of
your class B network to someone else by jan 1st, 1995'?
You might even sue me.

If you want address space, you have 3 choices:

1. Obtain official address space. Plan to come up with extensive
   documentation on how you will set up your network, and what
   the future plans will be. Your initial plan should be at least 
   10% efficient.

2. Use private address space as defined in RFC1597. You can be
   much more liberal with your address space assignments.
   The behaviour with respect to external connectivity,
   is closely defined.

3. Use private address space, but pick a number as per RFC1627.
   You can still be liberal assigning address space. However,
   external connectivity behaviour is completely undefined
   and there will be cases where communication will be impossible.

I don't like to say 'no' to many of the applications I see but
unfortunately, this is the current situation. RFC1597 provides
relief to those applications that do not want to plan for
efficient network utilisation but still want defined behaviour
for their external connectivity.

We (Yakov, Bob, Daniel and me) have been asked to write a rebuttal
document by various people. We are currently evaluating the
situation but feel that such a discussion should not be done 
via RFC documents series and we will have some discussion first.
It will likely be discussed at the next IETF.

We have been informed that the allocation of address space,
as defined in RFC1597, stands. If you choose for option 2 above,
there will be no routing ambiguity for your firewall hosts.

Geert Jan


-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 02:12:59 GMT
From:      hsm@unislc.slc.unisys.com (Helge Moulding)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Rick Jones wrote,
: Lest anyone think that I am trying to ferment revolution 
As long as it is good to drink...

: and start
: flooding the Internet with IP fragments, as much as what I've been
: saying has been to challenge assumptions to ascertain their validity.
: Particularly the one that says that IP Fragmentation is "expensive"
: (an unfortunately vague term) [...]
The implementation of TCP-IP that I am familiar with incurs fragmentation
costs principally during reassembly, due to the fact that received
fragments must be staged until all fragments are there. Since higher
layers (particularly TCP) may (or must) do the same, CPU cost isn't
nearly as significant as buffer cost.

As far as routers are concerned, however, the best performance is 
reached when the software needs only to decrement the hopcount, 
adjust the checksum and call the packet driver for the outgoing 
interface. I suspect that when adding the need to fragment, no matter
how sophisticated the pointer-handling capabilities, the performance
may suffer by much more than just a factor of two or so.

I find that remembering that I am not the only one pulling shenanigans
on the network helps put things like this into perspective... Also
keep in mind that (usually!) the only time that *router* fragmenting 
occurs is when the routers are connecting two disparate media: 802.3 
to FDDI, ferinstance. Chances are that the differing data transfer 
rates of the two media may already be creating all kinds of gremlins...

I suppose "expensive" is still vague, but, hey, so is "enchilada"...
--
	Helge "How many Megs must a man install before his PC
	is a host...?" Moulding
	(Just another guy who is only human)
 ------------------------------------------------------------------------------
    It is a curious fact that when a man is acting most like an animal,
    he excuses his behavior on the grounds that he is "only human."
    -- paraphrased from _The_Fringe_of_the_Unknown_ by L.Sprague de Camp
 ------------------------------------------------------------------------------

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 13:10:38 -0500
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: where can I get the interSLIP for MAC?

messina@mcs.com (David Messina) writes:
> Sorry to step on your toes, Amanda. :)  

No problem.  We actually haven't had problems with people copying it around 
indiscriminately, but our legal beagles don't want anyone to think it's in the 
public domain :)...


Amanda Walker
InterCon Systems Corporation





-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 06:26:12 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

Tom Limoncelli (tal@Warren.MENTORG.COM) wrote:
> >We certainly don't need a review on
> >6 month old movies OR 6 month old books.
>
> Mini-Review of "Philadelphia"
> ----------------------------- by Tom Limoncelli
> I thought the movie Philadelphia was excellent and brought a very
> hidden (but pervasive) issue to an audience that would usually not deal
> with, nor appreciate, such issues until they were facing them head-on.

  Thanks for the timely review.  I had not seen the movie, wasn't even aware
  of it.  Your review has heightened my interest.

-- Ken Mintz (allegorically speaking; touche'!)

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 07:45:43 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

In article <773834307snz@psp.co.uk> tfl@psp.co.uk "Thomas F Lee" writes:

>A DNS server is a _server_ which resolves _Host Names_ into _IP Addresses_.
>
>We played with this a bit during last week and the DHCP stuff works
>great.  Didn't really have much time to explore WINS though.  Documentation
>on DHCP can be found on gowinnt.microsoft.com (there is a DHCP.DOC Word
>document by J Allard - worth reading).  

Thomas,  what were using for the DHCP server?  an NTAS system? Beta?

I have got the TCP-32 Beta stack working between my two WfWG 3.11
PCs here, and I would like to play with DHCP, ahead of advising some 
clients on this.

Phil

-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 16:45:34 -0500
From:      netguide@panix.com
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted
Subject:   SLIP and PPP Clients/Dynamic Addressing


I am interested in finding out what SLIP and PPP clients there are
available for the Macintosh besides InterSLIP, InterPPP and MacPPP.
Additionally, I am looking for the ability to utilize dynamic IP
addressing; I would be very interested in any packages that make this
(easily) possible.

Does anyone have any suggestions?
(email copies of posts appreciated)

David Wood
obsidian@panix.com

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 15:06:32 -0400
From:      jmb@kryten.atinc.com (Jonathan M. Bresler)
To:        comp.protocols.tcp-ip
Subject:   subnetting


having just read rfc950 again, i understand the following to apply
to subnetting.

1.	the "all subnet bits 0" subnet should not be used as a physical
	network.
2.	the "all subnet bits 1" subnet should not be used as a physical
	network.
3.	no host should be "all host bits 0"
4.	and no host at "all host bits 1"


so....

#subnet bits	#of subnets	#of hosts	#lost addresses
						due to subnetting

1		0		 0 * 126	all = 254
2		2		 2 *  62	2 * 62 +  2 * 2 = 128
3		6		 6 *  30	2 * 30 +  6 * 2 = 72 
4		14		14 * 14		2 * 14 + 14 * 2 = 56
etc

is this correct?

jmb
-- 
Jonathan M. Bresler  jmb@kryten.atinc.com	| Analysis & Technology, Inc.  
						| 2341 Jeff Davis Hwy
play go.					| Arlington, VA 22202
ride bike. hack FreeBSD.--ah the good life	| 703-418-2800 x346

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 15:10:29 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: Problems with IBM OS/2 TCP/IP implementation

Well, I want to thank everyone who helped me with my problem.  To expound:

I was trying to code up some sockets stuff, and I got the code from a co-
worker who has recently left the company.  The code worked on his machine, but
not on mine when I tried it.  On the server I got:

Sent 108 bytes
Sent 108 bytes
.
.
.
Sent 108 bytes   (10th send)

But the receiver saw:

Received 108 bytes
Received 216 bytes
Received 300 bytes

...


I thought TCP had record delimiters, but it does not.  Aha, as many people
told me, I have to create them myself.

I stole the solution from "Client/Server Programming for OS/2 2.0" to fix
the problem.

Pseudo code:

Send{

send length in network order
send data

}

Recv{

read data until you get 4 bytes.
change to host from network format.
read in data until you get length number of bytes.
}

Took a few compiles to get h->n n->h number conventions tucked away, but...

It now works!  

Now, if someone could just tell me how to get my TCP/os/2 machine to
quit asking the nameserver for the address to go to, as it installed in my
local hosts file.  But at least the dang stuff works.

What's funny, is that I have read the books on sockets in an effort to learn
all about it, but nowhere did I see this caveat.  I guess it is implied.

Thanks to all who helped.

Jim 


-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 09:47:18 GMT
From:      phrrngtn@dcs.st-andrews.ac.uk (Paul J. J. Harrington)
To:        comp.protocols.tcp-ip
Subject:   Re: Does anyone know of a scriptable telnet for Sun (or anything else?)

tnemeth@immuno.imvs.sa.gov.au writes:

>In article <TJFS.94Jul8192506@golf.tadpole.co.uk> tjfs@golf.tadpole.co.uk (Tim Steele) writes:
 
>>I'd like to be able to run a script, a bit like a uucp script, but to
>>a telnet server.


>Why don't you try the latest C-Kermit?

Or Libes' "expect"

pjjH



--
Paul Harrington, phrrngtn@dcs.st-andrews.ac.uk  	 +44 334 463261
Division of Computer Science, St Andrews University, Scotland KY16 9SS

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 10:22:07 GMT
From:      jmi@csd.cri.dk (John Mills)
To:        comp.protocols.tcp-ip
Subject:   Re: Any Info on TK/TCL would be appreciated

In article 34x@netcom.com, samg@netcom.com (Sam Ghandchi) writes:
>
>Is there any newsgroup where TK/TCL expert programmers
>discuss topics?
>

comp.lang.tcl



>Any info is appreciated.
>
>Regards,
>- Sam Ghandchi
>samg@netcom.com
>






-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 13:11:13 GMT
From:      igb@fulcrum.co.uk (Ian G Batten)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: Obtaining Ethernet/MAC Network Addresses From Sun System

In article <2vkeq7$bsd@somnet.sandia.gov>,
William L. Larson <wllarso@sandia.gov> wrote:
> Ethernet interface.  All other network interfaces report the same MAC
> address.

That's because Suns as standard use the same MAC address for each
interface.  This is quite legal, and is I believe actively encouraged by
the specs.

ian

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 13:30:26 GMT
From:      larryp@sco.COM (Larry Philps)
To:        comp.protocols.tcp-ip
Subject:   Re: How to use UDP in interrupt manner with SCO sV r3.2 v4.0?

In <2vh3ab$e3l@cumulus.CAM.ORG> imatex@CAM.ORG (Imatex Communications Inc.) writes:

> I want to acheive communications between many servers (that don't
> communicate to each other) and many clients (that don't communicate to 
> each other neither) using UDP protocol.
> 
> I would prefer to work in asynchronous communication, since each clients must
> wait for their stdin to receive data to be transmitted on the lan.
> 
> I tought to use SIGIO as described by Richard Stevens in Unix Network 
> Programming. Since I am developping on SCO Unix System V release 3.4 
> version 4.0, SIGIO is not available. I also took a look to streams, but I 
> have not found how to implement interrupts.
> 
> So far, as I've seen, the only way to use streams in TCP/IP
> communication is via TLI. Tell me I am wrong!

SCO has a BSD socket layer that sits on top of the STREAMS implemenation
of TCP/IP, and allows you to program to the sockets interface just like
on BSD based systems.  There is no SIGIO, but asynchronous I/O is indeed
possible, it uses SIGPOLL.

> Any sugestion, with C code examples, will be VERY helpfull.
> Many thanks in advance.

#define SIGIO SIGPOLL

	sigset(SIGIO, input_handler);

	int pid;
	int s;
	int on;

	/* Create socket */
	if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
		perror("socket");
		exit(1);
	}

	/* Mark this process as the one to receive async I/O signals */
	pid = getpid();
	if (ioctl(s, SIOCSPGRP, &pid) == -1) {
		perror("ioctl: SIOCSPGRP");
		exit(1);
	}

	/* Turn on non-blocking I/O */
	on = 1;
	if (ioctl(s, FIONBIO, &on)) {
		perror("ioctl: FIONBIO");
		exit(1);
	}

	/* Turn on async I/O */
	on = 1;
	if (ioctl(s, FIOASYNC, &on)) {
		perror("ioctl: FIOASYNC);
		exit(1);
	}

---
Larry Philps              Senior Software Engineer            larryp@sco.com
SCO Canada, Inc., 130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
Phone: (416) 960-4012                                    Fax: (416) 922-2704

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 13:33:30 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

In article <2vpbo6$bbv@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes:
>Anyone got any comments about the behaviour of variable subnetting
>used with say, OSPF based routing.
>
>Specifically, All host based TCP/IP implementations that I'm aware of only
>recognise non-variable sub-netting, ie through RIP or other implementation.
>
>My understanding is that such hosts will make sub-optimal routing decisions
>without full knowlege of the network significant part of the IP address.
>
>Comments?

Host which are not multi-homed need know nothing of the network
other than how to find their default router. ICMP redirects should get
them to the best router regardless of routing protocol being used or
whether variable subnets are being used.

Host should be using IRDP if available to find the default router.

Multi-homed hosts are the only hosts that should potentially be
listening routing protocols. This is regardless of whether they are
acting as a router or not. Be carful with multi-homed machines as most of
the current crop of OS's  don't cope with having different netmasks on
the same network. (BSD 4.4 derived system do cope with this senario.)

I wouldn't want a machine to be listening to routing protocols in a
variable subnet envirionment unless you know for sure that it can cope
with variable subnets as it is actually more likly to misdirect packets.

Mark

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 13:47:53 GMT
From:      tpoind@advtech.uswest.com (Tom Poindexter)
To:        comp.protocols.tcp-ip
Subject:   Re: Any Info on TK/TCL would be appreciated

In article <samgCspGHp.34x@netcom.com> samg@netcom.com (Sam Ghandchi) writes:
>
>Is there any newsgroup where TK/TCL expert programmers
>discuss topics?


comp.lang.tcl  - very active newsgroup, FAQ posted frequently, ftp archive
site is harbor.ecn.purdue.edu 
-- 
Tom Poindexter     tpoind@advtech.uswest.com  or  tpoindex@nyx.cs.du.edu  
U S WEST Advanced Technologies,  Boulder, Colorado
"I hate it when that happens"

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 14:34:09 GMT
From:      rsalz@osf.org (Rich Salz)
To:        comp.protocols.tcp-ip,comp.client-server,comp.unix.internals
Subject:   Re: Data formats needed for non-XDR conversion

In <CsMpnq.8F9@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>Instead of XDR, NCS had what its authors called "receiver makes it right"
>but was jokingly known to others as "receiver makes it wrong."  In fact,
>NCS has a complicated version of XDR.

Well, yeah, kinda.

XDR is "use a canonical format."  That is, everyone converts to a specified
format and some machines pay a penalty.  NCS is "pick a canonical format."
That is, everyone can convert to one of a couple of different formats and
everyone must know all of them.  In theory this is ugly and leads to
bloated code.  In practice, there are two integer formats and three or
four floating point formats.  Contrary to what Vernon says, the NCS scheme
was believed to be better in a heterogenous world, not a closed world.

Nobody really knows which method is better because nobody has done
any comparisons, at any level:  cost of marshalling on both sides,
and cost of marshalling in comparison to a typical RPC (and what is
a typical RPC, anyway).
	/r$

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 17:18:00 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Is this a crazy idea?

In article <2vrnm2$ksb@ccnet.ccnet.com>, jantypas@ccnet.com (John Antypas) writes:
|> Am I insane for thinking about this?
|> 
|> I have a client that would like to connect his office machine and
|> a few dialin employees to the Internet.  While the traditional solutions
|> would work, would the following also work?
|> 
|> - Client buys a 56Kb CSU
|> - Client gets a Portmaster terminal server or equiv.
|> - Provider provides an async framed PPP via the CSU to the portmaster.
|> - Everyone else just runs off the portmaster using it as a router.
|> 
|> Does this buy anything?  The portmaster can be had for about $900, a CSU
|> for about $300.

We do this here for connecting our East and West Coast offices through
a sw56 link.  (Although, of course, we use Annexen instead of
Portmasters...)

Some things to be aware of:

	- Asynch-to-synch converting CSU/DSUs don't do hardware flow
	  control, so you'll have to run XON/XOFF over the link and
	  properly configure PPP to mask these characters.
	- Lost XONs are a particular problem over such a link.  You'll
	  need to make sure that the vendor has made special provisions
	  to handle this problem.  (Namely, periodically outputting XON
	  until new data are received.)
	- Asynch PPP is not compatible with synch PPP.  You'll need to
	  make sure that the other end of this link has the same type of
	  encapsulation.  (This may be a problem when connecting to
	  Internet access providers.)

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 17:59:45 GMT
From:      coghlan@bcarh5f8.bnr.ca (Patrick Coghlan)
To:        comp.protocols.tcp-ip
Subject:   How can I build an X sniffer (xscope?)

I want to intercept all packets between an X terminal and a host.

I believe X runs over TCP so can someone please point me at:

   - relevant RFCs I should look at
   - what "tricks" I need to employ to intercept and forward all
     packets between the X terminal and the host

Thanks in advance.

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 18:31:10 GMT
From:      samg@netcom.com (Sam Ghandchi)
To:        comp.protocols.tcp-ip
Subject:   Re: Any Info on TK/TCL would be appreciated

THANKS A LOT FOR ALL THE REFERENCES.  

Regards,
- Sam Ghandchi

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 18:59:25 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: A interesting routing quesiton.....

In article <1994Jul9.173631.559@dec8.ncku.edu.tw> tung@eespcb.ncku.edu.tw (Assistant) writes:
>Here is a old network configuration of our lab:

Very good picture. It told me everything I needed to know. I'll leave
it out of the response for brevity and summarize as follows: you are
trying to have four sub-subnets hanging off one of your subnets.  The
sub-subnets have a mask of ff.ff.ff.f0, while the subnet mask is
ff.ff.ff.0.

>We have set the netmask and default gateway of PCs connecting to port A,B,C,D
>but at novell,we have some question here...

OK, I'll answer the questions, but let me jump ahead and answer
question 6 first, as it is the crux.

>6. It is said that all the port of novell should has the same netmask,
>   is it true?

The v1.00 version of the TCPIP.NLM, all subnets of a given network
must have the same network mask. The routing protocol RIP does not
support variable subnet masks, so that release of TCP/IP support for
NetWare doesn't support them, either.

V2.x releases of the TCPIP.NLM support something called proxy-ARP,
which allows you to do exactly what you want. You can find that NLM in
the v4.x releases of NetWare as well as the v2.x releases of Novell's
MultiProtocol Router product. (It wouldn't surprise me to discover
that this NLM is available on NetWire, but I can't recall whether it's
been released that way or not.) Perhaps this is a good excuse to
upgrade your NetWare to the v4.02 release? :-)

I'll answer the other questions in the context of the v2.x TCPIP.NLM
using proxy-ARP.

>1. We load tcpip.nlm with tcpip=yes, rip=yes, anything else needed?

No, that is sufficient.

>   Does tcpip.nlm ver 1.00 work fine?

Yes, but it doesn't support this feature. There was, however, one
deficiency (well, privately I'd admit it was a bug) in that it does
not detect and prevent attempts to use variable subnet masks. In other
words, you're problems have been somewhat magnified because TCPIP.NLM
let you get a lot farther down a dead end then it really should have.

>2. What netmask sould we set for port ABCD, FF.FF.FF.F0?

Yes.

>3. What gateway sould we set for port ABCD, 140.116.32.241?

No. You should not specify any gateway. The GATEWAY parameter informs
IP about a router on that network which leads out to the wider world.
It should be used only when there is such a gateway that doesn't speak
RIP. In this case, there are no gateways on your sub-subnets of any
sort, so no GATEWAY parameter is appropriate

>4. What netmask sould we set for port Z, FF.FF.FF.F0 or FF.FF.FF.00
>   if ff.ff.ff.f0, how can hosts at port a, b, c, d connect to 140.113.32.xxx
>   not on ABCD? (ex:140.116.32.60)
>   Should we add static route to port Z?

With proxy-ARP, the correct mask is the one you've been trying to use
unsuccessfully with v1.0: ff.ff.ff.0. No static route is necessary;
the routing will all be handled automatically by the v2.x NLM.

>5. What gateway sould we set for port Z, 140.116.32.253?

You can if you want. If 140.116.32.253 speaks RIP, it will be
discovered automatically, so in that case the GATEWAY parameter would
be redundant

>7. The manual said that we'd better set RIP to off, why?

I'm not sure what manual you're talking about, and I don't know why it
would tell you to set RIP off. Perhaps it was only talking about a
server not being used as a router?  In your case, if you're already
using RIP on your network, there's no reason not to let the NetWare
router participate in the RIP conversation.

>This is serious to us, any suggestion will be much appreciated.....

I hope this helps.

						don provan
						donp@Novell.com

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 20:14:10 GMT
From:      dowd@eng.buffalo.edu (Patrick Dowd)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM'94 Advance Program - Early registration deadline Aug 1



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

Please Note: the deadline for early registration is August 1st.

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



                           Advance Programme
                      ACM SIGCOMM'94 CONFERENCE
       Communications Architectures, Protocols and Applications

                      University College London
                              London, UK

                    August 31 to September 2, 1994
                 (Tutorials and Workshop, August 29-30)


                             Sponsored by
         The ACM Special Interest Group of Data Communication

This  conference provides an international  forum for the presentation
and discussion of communication network applications and technologies,
architectures,  protocols,  algorithms, and  performance models.   The
conference  and tutorials will be conducted on  the University College
London, London England.


		  ----------------------------------
		  T E C H N I C A L    P R O G R A M
		  ----------------------------------

Monday 29 August 1994

*  7:30AM - 5:00PM 
   Tutorial and Conference Registration
   UCL CS Department, Pearson Building

*  9:00AM - 5:00PM, Tutorial T1
   "Personal Communication Services and Networks"
   Zygmunt Haas (AT&T Bell Labs)
   UCL CS Department, Pearson Building

*  9:00AM - 5:00PM, Tutorial T2
   "Protocol Performance"
   David D. Clark (MIT)
   UCL CS Department, Pearson Building

Tuesday 30 August 1994

*  7:30AM to 5:00PM 
   Tutorial and Conference Registration
   Edward Lewis Lecture Theatre, Windeyer Building

*  9:00AM - 5:00PM, Workshop W1
   "Topics    in   High   Performance   Networking   Support   of
    Distributed Systems" 
   Derek McAuley (University of Cambridge)
   UCL CS Department, Pearson Building

*  9:00AM - 5:00PM, Tutorial T3
   "Fiber Optic Networks"
   Paul  E. Green, Jr. (IBM Corporation)
   UCL CS Department, Pearson Building

*  9:00AM - 5:00PM, Tutorial T4
   "Multimedia Conferencing on the Internet"
   Van Jacobson (Lawrence Berkeley Laboratories)
   Edward Lewis Lecture Theatre, Windeyer Building

*  9:00AM - 5:00PM, Tutorial T5
   "Asynchronous Transfer Mode"
   Rainer Handel (Siemens Munich)
   UCL CS Department, Pearson Building

*  5:30PM - 8:30PM
   Welcoming Reception
   The Quad at University College London


Wednesday 31 August 1994

*  7:30AM to 5:00PM 
   Conference Registration
   Edward Lewis Lecture Theatre, Windeyer Building

*  9:00AM - 10:00AM
   Session 1: Keynote Address
   (1994 ACM SIGCOMM Award Winner)
   Edward Lewis Lecture Theatre, Windeyer Building

*  10:30AM-12:30PM
   Session 2: Protocol Performance
   Experiences with a High-Speed Network 

   Adaptor: A Software Perspective (Best Student Paper)
   P. Druschel (University of Arizona), L.L. Peterson (University of 
   Arizona), & B.S. Davie (Bellcore) 

   User-space Protocols Deliver  High Performance to Applications on a
   Low-Cost Gb/s LAN 
   A. Edwards, G. Watson, J. Lumley, D. Banks, 
   C. Calamvokis, & C. Dalton (Hewlett-Packard Labs, Bristol)  

   TCP Vegas: New Techniques for Congestion Detection and Avoidance
   L.S. Brakmo, L.L. Peterson, & S.W. O'Malley (University of Arizona)

   A Structured TCP in Standard ML
   E. Biagioni (Carnegie Mellon University)

*  12:30PM  - 2:00PM
   Lunch

*  2:00PM-3:30PM
   Session 3: Congestion Management

   Making Greed Work  in Networks: A  Game-Theoretic  Analysis of
   Switch Service Disciplines 
   S. Shenker (Xerox PARC)

   Scalable Feedback Control for Multicast Video Distribution in the Internet
   J. Bolot (INRIA), T. Turletti (INRIA) & I. Wakeman 
   (University College, London)

   Statistical Analysis of Generalized Processor 
   Sharing Scheduling Discipline
   Z.-L. Zhang, D. Towsley, & J. Kurose (University of Massachusetts)

*  4:00PM-5:30PM
   Session 4: ATM Flow Control

   The Dynamics of TCP Traffic over ATM Networks
   A. Romanow (Sun Microsystems) & S. Floyd (Lawrence Berkeley Labs)

   Reliable and Efficient Hop-by-Hop Flow Control
   C. Ozveren (DEC, Littleton), R. Simcoe (DEC, Littleton)  & 
   G. Varghese (Washington University, St. Louis)

   Credit Update Protocol for Flow-Controlled ATM 
   Networks: Statistical Multiplexing and Adaptive Credit Allocation
   H.T. Kung (Harvard University), T.  Blackwell (Harvard 
   University), & A. Chapman (BNR)

*  7:30PM - 10:00PM
   SIGCOMM Social: Reception and Dinner 
   The Dinosaur Room, Natural History Museum 
   (Tickets  Required)


Thursday 1 September 1994

*  7:30AM to 5:00PM 
   Conference Registration
   Edward Lewis Lecture Theatre, Windeyer Building

*  8:30AM - 10:00 AM
   Session 5: Internet Routing

   Flexible Routing and Addressing for a Next Generation IP
   P. Francis (NTT Software Labs) & R. Govindan (Bellcore)

   An Architecture for Wide-Area Multicast Routing
   S. Deering(Xerox PARC), D. Estrin (University of Southern 
   California), D. Farinacci (Cisco Systems), V. Jacobson 
   (Lawrence  Berkeley Labs), C.-G.  Liu (University of  Southern
   California) & L. Wei (University of Southern California) 

   Distributed Routing Based on Link-State Vectors
   J. Behrens & J.J.  Garcia-Luna-Aceves (University of 
   California at Santa Cruz)

*  10:30AM-12:00PM
   Session 6: ATM Switching and Signalling

   Signaling and Operating System Support for  
   Native-Mode ATM Applications
   R. Sharma & S. Keshav (AT&T Bell Labs)

   Experiences of Building ATM Switches for the Local Area
   D.R. McAuley, R.J. Black & I.M. Leslie (University of Cambridge)

   Controlling Alternate Routing in General-Mesh 
   Packet Flow Networks
   S. Sibal (RPI) & A. DeSimone (AT&T Bell Labs)

*  12:00PM  - 1:30PM
   Lunch

*  1:30PM-3:00PM
   Session 7: Nueral and Optical Networks

   On Optimization of Polling Policy Represented 
   by Neural Network
   Y. Matumoto (I.T.S., Inc., Japan)

   An Optical Deflection Network
   J.  Feehrer  (University of  Colorado,  Boulder),  L.  Ramfelt
   (University of Colorado, Boulder/Royal Institute of Technology,   
   Stockholm), & J. Sauer (University of Colorado, Boulder) 

   Conflict-Free Channel Assignment for an Optical 
   Cluster-Based Shuffle Network Configuration
   K.A. Aly (University of Central Florida)

*  3:30PM-5:30PM
   Session 8: Selected Topics

   MACAW: A Media Access Protocol for Wireless LANs
   V. Bharghavan (UC Berkeley), A. Demers (Xerox PARC), 
   S. Shenker (Xerox PARC) & L. Zhang (Xerox PARC)

   Asymptotic Resource Consumption in Multicast 
   Reservation Styles
   D.J. Mitzel (University of  Southern  California) & S. Shenker
   (Xerox PARC) 

   Highly Dynamic  Destination-Sequenced  Distance-
   Vector Routing  (DSDV) for Mobile Computers
   C.E. Perkins & P. Bhagwat (IBM, Watson Research Center)

   A Methodology for Designing Communication Protocols
   G. Singh (Kansas State University)

*  5:30PM - 6:30PM
   SIGCOMM Business Meeting


Friday 2 September 1994

*  8:30AM - 10:00AM
   Session 9: Traffic Models

   Wide-Area Traffic: The Failure of Poisson Modeling
   V. Paxson & S. Floyd (Lawrence Berkeley Labs)

   Analysis, Modeling and Generation of Self-Similar 
   VBR Video Traffic
   M.W. Garrett & W. Willinger (Bellcore)

   An Algorithm for Lossless Smoothing of MPEG Video
   S.S. Lam, S. Chow, & D. Yau (University of Texas, Austin)

*  10:30AM-12:00PM
   Session 10: Host Software

   USC: A Universal Stub Compiler
   S.W. O'Malley, T. Proebsting, & A. Montz (University of Arizona)

   An Object-based Approach to Protocol Software Implementation
   C.-S. Liu (Chung Yuan Christian University, Taiwan)

   Improved Algorithms for Synchronizing Computer Network Clocks
   D.L. Mills (University of Delaware)

*  12:00PM - 12:15PM
   Closing Session
   
Note: Program subject to change.
				   
			  -----------------
			  T U T O R I A L S
			  -----------------
				                       
Tutorial T1 
-----------
Zygmunt Haas, AT&T Bell Labs
"Personal Communication Services and Networks"

The  recent explosion  of interest  in  wireless and mobile  networks,
stimulated  by  the effort  of  Personal  Communication  Services  and
Networks (PCS & PCN) to  be  deployed at  the  beginning  of  the next
century,  suggests   the  enormous   technological,   scientific,  and
commercial potential in this field. The subject of wireless and mobile
communication  integrates  the  large body  of  knowledge  accumulated
through   the  traditional  radio   research,  the   large  networking
experience accumulated through the proliferation of LANs and WANs, and
the  vision  of  ubiquitous  connectivity anywhere,  at anytime,  with
anyone, and in any format.
   The  tutorial exposes both the theoretical  and  the practical
aspects  of mobile  networking,  from  a  networking  and  application
perspective.   We   will   present   the  concept,  architecture,  and
functionality of Personal Communications Services  and Networks (PCS &
PCN)  and  Universal  Personal  Telecommunications (UPT)  and  we will
describe the most  common  platform  for  mobile  communications:  the
wireless systems. In  particular, systems such  as cellular, cordless,
and satellite will be  discussed. Existing  and in-progress  standards
are also outlined.
   Finally, an abundance of examples of  the  wireless and mobile
networks will be described, giving realism to the presented material. 
TOPICS:
* Elements of Wireless Mobile Communications
* Wireless Services and Applications
* The Cellular Concept 
* The Cordless Concept 
* Digital Communication Networks
* Local-Area Wireless Data Access
* Wide-area Wireless Data Access
* Mobile Satellite Communications
* Standardization of Wireless Networks
* PCS/PCN and UPT
* Summary: Where we have started and where are going .

Zygmunt Haas received his B.Sc. in EE in 1979 and M.Sc. in EE in 1985,
both with  Summa Cum Laude.   From  1979  till 1985  he worked for the
Government of Israel.  In  1988,  he  earned  his Ph.D.  from Stanford
University researching fast packet-switched networks, and subsequently
joined AT&T Bell Laboratories in Holmdel NJ, where he is now  a Member
of  Technical  Staff in the Wireless Networks Department.  Dr. Haas is
an author of  numerous  technical papers and holds several  patents in
the field  of high-speed networking, wireless  networks,  and  optical
switching.  He has organized  several workshops and  served as a guest
editor for  JSAC issues.  Dr. Haas is a Senior  Member of IEEE and his
interests  include:   mobile   and  wireless  communication  networks,
personal  communication services,  high-speed communication protocols,
and optical switching.



Tutorial T2 
-----------
David D. Clark, MIT
"Protocol Performance"

Getting proper  performance from  a  network  or  protocol  is often a
difficult task. This tutorial uses examples from the Internet (TCP/IP)
protocol suite to illustrate critical performance issues. The focus is
on  providing  real-world  advice  on  how  to  design  and  implement
protocols in ways that  avoid performance  problems. The  presentation
will include  examples  of various  performance  problems and  how  to
detect and recognize them.

Topics
* Performance issues (reliability, throughput and delay)
* Implementation bottlenecks
* Specifications and their limitations
* Heterogeneity and its impact on implementation
* Network dynamics
* Visualizing protocol performance
* Limits of protocol performance

Dr. David Clark  is a senior research scientist  at MIT Laboratory for
Computer Science  and  a  recipient  of the ACM SIGCOMM  Award. He has
worked  on TCP/IP  since the  mid-1970s and  from  1981  to  1989  was
chairman of the Internet Activities Board. He is widely known for  his
insight into  protocol design and performance  and for  his  skill  in
identifying and  eliminating  myths about  protocol implementation and
performance.  His current areas  of  research include high-performance
networks,   the  evolution   of  the  Internet,  ATM  and  information
networking. He received his doctorate from MIT in 1973.

Tutorial T3 
-----------
Paul E. Green, Jr., IBM
"Fiber Optic Networks"

Fiber  optic   technology  has  completely  transformed  the  internal
operation of the world's telephone networks and is beginning to impact
local  computer networks.  Compared to  the  voice  grade  phone  line
technology, which defined  most of the  network architectures  that we
are  still  living with  today,  fiber  offers ten orders of magnitude
better bandwidth and an  equal  improvement in  achievable  bit  error
rate.  By use of WDM and circuit switching, the additional benefits of
protocol transparency can be achieved.
   There is a widespread  feeling that  the generation of network
that  will  follow today's ATM and upgraded  Internet structures might
very  well   be  based   on  techniques  that  directly  unlock   this
revolutionary improvement at the physical level.
   The  course is  devoted  to  the  new  class  of "all-optical"
networks  that attempt  to  do  this.  The  lecturer  will  cover  the
optoelectronic components  involved and will  also treat  some  of the
network  architectural  consequences,  the  regulatory   and  economic
picture, and review some systems already implemented.

TOPICS 
* Motivating fiber optic networks
* Fibers, couplers and taps
* Optical resonant structures
* Laser diodes and amplifiers
* Optical receivers
* System considerations
* Network topologies and link budgets
* Protocols, layers and network control
* Some implemented systems
* Status and prospects

Paul E. Green, Jr, is Manager of Advanced Optical Networking Member at
IBM Research in Hawthorne, NY.  He received the ScD degree from M.I.T.
in  1953, and after some  years at M.I.T. Lincoln Laboratory, where he
made pioneering  contributions to spread spectrum, adaptive receivers,
radar astronomy and seismic data processing, he joined IBM Research in
1969.  At  IBM  he has held  a  variety  of  management and  Corporate
Technical  Staff  positions. His technical interests  have centered on
computer  network  architecture,  and  he  has  received  several  IBM
Outstanding Innovation Awards for his  role in the initial formulation
and promotion of Advanced Peer to  Peer Networking,  now the basis for
further evolution of IBM's System Network Architecture. He is a member
of   the  National  Academy  of   Engineering,  in  1983   was   named
Distinguished Engineering Alumnus by North Carolina  State University,
and received the IEEE's Simon Ramo  Medal in 1991. He is the author of
many  technical   papers,  has   edited   several  books  on  computer
communications,  and  is  the  author  of  the  textbook  Fiber  Optic
Networks,  published  by  Prentice  Hall  in  June,1992.  He  has been
President of  both the IEEE  Communication  Information Theory Society
and the Communication Society.

Tutorial T4 
-----------
Van Jacobson, LBL
"Multimedia Conferencing on the Internet" 

An architectural overview  and detailed walk-through of  the protocols
and applications that provide  real-time, multiparty, audio, video and
shared workspace conferencing on today's Internet.
   Experiments and demonstrations over the Internet MBONE and the
DARTNET  testbed  have  shown   that   multimedia   and   conferencing
applications can indeed work  over  IP internets.  Playback algorithms
that  adapt  to  variations  in  network  delay  (such  as   VAT)  and
information  distribution  algorithms  designed  to  facilitate shared
workspaces (such  as those used in the  shared  whiteboard)  have made
these sorts  of applications  possible. This tutorial describes  these
algorithms and the applications that use them.
Topics
* IP as a real-time infrastructure: multicasting and queueing
* Adaptive Playback: VAT
* Managing Sessions: SD
* Managing Shared Workspaces: Shared Whiteboard
* Implications for the future of IP

Van Jacobson is a senior researcher at Lawrence Berkeley Laboratories,
where he works on real-time system performance, protocol and operating
system performance.  He is widely known for his groundbreaking work on
TCP/IP  performance,  TCP/IP   congestion  control,  and  support  for
multimedia  applications  on the  Internet. He is  the recipient of  a
number  of  awards and  teaches  periodically  at  U.C.  Berkeley  and
Stanford University.  

Tutorial T5 
-----------
Rainer Handel, Siemens Munich
"Asynchronous Transfer Mode" 

The  tutorial  will  provide  a   comprehensive  introduction  to  the
Asynchronous Transfer Mode (ATM). Both technical and marketing aspects
of ATM will be addressed. ATM specification is not yet complete but in
a state that allows implementations which are basically compliant with
a worldwide agreed, unique standard supporting  data, voice, image and
multimedia applications.
       The presentation of the concept of ATM networking  will include
the ATM  protocol reference model,  the architecture of  ATM networks,
interfaces  and procotols, traffic  control  and resource  management,
signalling, operational  aspects,  ATM evolution  and  internetworking
aspects, and of course a detailed description of the ATM layer and ATM
adaptation layer  functions. An overview of how ATM cells are switched
and  transmitted  will  also  be  given. The  possible use of ATM in a
business   and  residential  environment  and  its  market  acceptance
depending on product availability, cost  and feature offerings will be
clarified.   
TOPICS:  
* High speed networks  
* ATM concept 
* ATM protocols  
* ATM interfaces 
* interworking and evolvability
* market  aspects 
* switching and transmission products 
* network  implementations and  service offerings  

Rainer Handel  has  been with Siemens  (Public Communications Networks
Group)  since  1978 doing system  design and software  development for
switching  systems,  ATM  conceptual  and  standardization  work,  ATM
network and  product planning,  and currently long-term telecom market
and  technology trend evaluation. For several years  he  was active in
the standards bodies  CCITT, ETSI and T1, and is the author of several
papers and a book on ATM.

Workshop W1 
----------
Derek McAuley, University of Cambridge
"Topics in High Performance Networking Support of Distributed Systems" 

This  one day workshop will present the experiences of the speakers in
building various  components  of  distributed  systems  which  aim  to
effectively  utilise modern  high performance  networks. This workshop
consists of 4 talks. Each  talk will be 60 minutes with 15 minutes for
discussion.

1. The CHORUS Communication Architecture, Marc Rozier

The   communication   service  is   a  key  component  of  the  CHORUS
micro-kernel  architecture. First,  it provides  the  basic  framework
allowing  efficient   modular  operating  system  implementations.  By
dramatically reducing the overhead of  local communications, it is key
to the success of such  serverized implementations, which are now able
to  compete  with  monolithic  implementations.  Second,  it  provides
efficient, network-transparent, communication  services, well  adapted
to the distribution of  the operating system servers.   In particular,
it makes  possible  the  implementation  of UNIX systems  on massively
parallel architectures, offering a single system image to their users.
This tutorial will  address the  various aspects of this communication
architecture, from  the definition of the communication  services,  to
some  aspects of  its  implementation.  Emphasis  will  be  placed  on
insights from previous versions of this service.

2. The Organization of Networks in Plan 9, Rob Pike

In  a distributed system networks  are  of paramount importance.  This
tutorial   describes  the   implementation,   design  philosophy   and
organization of  network support  in  Plan  9. Topics include  network
requirements  for  distributed  systems,  our  kernel  implementation,
network naming, user interfaces and performance. We also observe  that
much of this organization is relevant to current systems.

3. Mixed media applications, David Tennenhouse

WWW  is a rapidly growing  phenomena which highlights the  interesting
applications possible with mixed media types. From experience with the
WWW this tutorial will  address the issues  raised in supporting these
mixed media types and the problems  in building systems  which support
media with time constraints.

4. What can you do with ATM today?, Derek McAuley

ATM must now be officially a  bandwagon. Some will tell you it  solves
all the world's problems because it was designed to, while others will
say  it's  good  for  nothing.  The  reality  and  hype  are  hard  to
distinguish. This talk will address what ATM can be used for today and
highlight those features for which it  is rightly criticised not least
of  which is  end-system  integration.  The talk could  be  subtitled,
"Difficult questions to ask your ATM salesman''.


Marc Rozier is the head  of the Micro-Kernel Department  within Chorus
systemes. He graduated from Ecole Nationale Superieure Informatique et
de  Mathematiques Applique'es  de Grenoble (ENSIMAG) before earning  a
doctor's   degree   in  Computer   Science  from   Institut   National
Polytechnique  de Grenoble (INPG). In 1981-82,  he was involved in the
CESAR  project at  IMAG  (Grenoble),  working  on  the  Validation  of
Distributed Systems. He gained experience in programming languages for
distributed applications  and distributed  systems. He joined INRIA in
1982 as  a  researcher  in  the CHORUS  distributed  operating  system
project. In 1987, he became one of the founders of Chorus systemes. He
is one of the main designers of the CHORUS-v3 Micro-Kernel technology.
He is the author of several publications in international journals and
conferences.

Rob Pike is  well known for his appearances on "Late Night with  David
Letterman",  is  also  a  Member  of  Technical  Staff  at  AT&T  Bell
Laboratories in Murray Hill, New Jersey, where he has been since 1980,
the same year he won  the  Olympic silver medal in Archery. In 1981 he
wrote the first  bitmap window system  for Unix systems, and has since
written ten  more.  With Bart Locanthi he designed  the Blit terminal;
with Brian Kernighan he  wrote The Unix  Program- ming Environment.  A
shuttle mission nearly  launched a gamma-ray telescope he designed. He
is a Canadian citizen and has never written a program that uses cursor
addressing.

David Tennenhouse is  an Assistant  Professor of Computer Science  and
Electrical Engineering at MIT's Laboratory for Computer Science. He is
leader  of  the  Telemedia,  Networks  and  Systems  Group,  which  is
addressing  systems  issues  arising  at   the  confluence   of  three
intertwined  technologies: broadband networks,  high  definition video
and distributed computing.   David  studied electrical  engineering at
the  University of Toronto, where he received  his B.A.Sc. and M.A.Sc.
degrees.  In 1989 he completed his Ph.D. at the Computer Laboratory of
the University  of Cambridge. His Ph.D.  research focused on ATM-based
site interconnection issues. This work, which was conducted within the
Unison  Project, led to  the early implementation of an ATM-based wide
area testbed.

Derek  McAuley  is  a  Lecturer  in  the  Computer  Laboratory at  the
University  of  Cambridge. His research  interests include networking,
distributed   systems   and   operating  systems.    Recent  work  has
concentrated on the support  of time dependent  mixed  media types  in
both  networks and operating systems. He has failed to leave Cambridge
since  arriving in  1979 to read Mathematics. In 1989 he completed his
Ph.D. on ATM internetworking. He has had a hand in  de-commissioning 4
ATM  networks,  including  Tennenhouse's carefully  constructed Unison
platform.
 
              
			   ---------------
			   L o c a t i o n
			   ---------------

The conference will be held in the Edward Lewis  Lecture Theatre which
is located in the  Windeyer Building on the UCL campus.  This building
is located on the corner of  Cleveland Street and Howland Street, with
the entrance  on  Cleveland Street.  Tutorials are all in UCL Computer
Science  Department in the Pearson Building, except T4 (Van  Jacobson)
on  the Tuesday which is held in the Edward Lewis Lecture Theatre. 

The main entrance of UCL  is located at the north end of Gower Street,
close to Euston Square, Warren Street,  or Euston tube stations.   The
UCL  Computer Science  Department is located in  the  basement of  the
Pearson Building.  Location


		     ---------------------------
		     T r a n s p o r t a t i o n
		     ---------------------------

* Getting to  London 

There  are  four  airports  in  and  around   London.   Here  is  some
information that  might help you to plan your journey.  Please consult
your travel agency or the airports directly for further information.

LONDON Heathrow Airport: 24 km west of London 
Telephone: +44-81-745-6156 
LONDON Gatwick Airport: 46 km south of London 
Telephone: +44-293-535-353 
STANsted Airport: 55 km north east of London 
Telephone: +44-279-680-500 

* Getting to UCL and Hotels

UCL is located  in central London, and is served by Warren St,  Euston
and Euston Square Underground (tube) stations, as well as several main
bus  routes.   The department  of  computer  science is  right  by the
entrance to the main quadrangles, on Gower Street.

From Heathrow:  Best  by  tube with Victoria Line  to  Euston  Station
(about #3, 50 minutes). Alternatives are via Bus with London Transport
A1 Airbus to Victoria Station (45 minutes).

For local hotels it is probably best to go to Euston Station and get a
taxi from  there  unless  you have a  street map already  and know the
nearest tube station.  A free tube map may  be obtained at any  ticket
office.

From Gatwick:  Best  by train, BR  Gatwick Express  to London Victoria
Station every 15 minutes (about #8.60, 30 minutes).

Unless you plan to sightsee  outside London a car  is probably a waste
of time.  Tube  fares are based on a zone system. After 9:30AM you can
get One Day Travel cards which allow you unlimited travel within given
zones  for the rest of the day -  that includes train and bus services
within  that zone too.  Zones 1,2 & 3 #2.30 pounds.   Zones  1-5 #2.60
pounds.


		      -------------------------
		      A c c o m o d a t i o n s
		      -------------------------

The following hotels are  walking distance from the conference meeting
room  on  the  UCL  campus.   Contact  the  hotel  directly  to  place
reservations.It  is highly recommended that reservations  are  made as
early as possible. Refer to SIGCOMM'94 when making the reservation.

* 	Hotel Ibis Euston
	3 Cardington Street, NW1
	Telephone: +44-71-388-7777, Fax: +44-71-388-0001
	Total Rooms: 300
	Single Room #49.50, Double Room #49.50
	Near UCL, about 10 minute walk from main Conference Hall. 

* 	St. George's Hotel 
	Langham Place, W1N
	Telephone: +44-71-580-0111, Fax: +44-71-436-7997
	Total Rooms: 86
	Single Room: #80.00, Double Room: #100.00 
	(Includes Continental Breakfast)
	Situated near Oxford Circus, about 10 minute walk from main venue. 

* 	RAMSAY HALL 
	20 Maple Street, W1P
	Total Rooms: 400
	Telephone: +44-71-387-4537, Fax: +44-71-383-0843
	Single Room: #19.50, Double Room: not available.
	(Includes Continental Breakfast) 
	Student residence used as hotel during summer break, 5 minute walk 
	from main conference venue.

* 	Hotel Russell 
	Russell Square, WC1
	Telephone: +44-71-837-6470, Fax: +44-71-837-2857
	Total Rooms: 328
	Single Room: #70.00, Double Room: #90.00 
	(Includes Continental Breakfast)
	Old Victorian Style Hotel. About 15 minute walk from Conference 
	venues. Russel Square  Station is on the Picadilly  line which
        reaches	to Heathrow Airport. Airport Bus stop nearby as well. 

* 	Forte Crest Bloomsbury 
	Coram Street, WC1
	Telephone: +44-71-837-1200
	Fax: +44-71-837-5374
	Total Rooms: 230
	Single Room: #69.00, Double Room: #79.00 
	(Includes Continental Breakfast)
	Modern hotel near Hotel Russell.

There  are  a large  number  of hotels near the conference. Almost any
hotel in the WC1 area of London is within 15 minutes walking distance.
A    list    of    more    hotels    may    be     found    via    www
(http://www.cs.ucl.ac.uk/sigcomm94)       or       anonymous       ftp
(norman.eng.buffalo.edu:/pub/SIGCOMM94). The list also includes nearby
lower cost housing and youth hostels.


	   ------------------------------------------------
	   R E G I S T R A T I O N    I N F O R M A T I O N
	   ------------------------------------------------

Full conference  registration  includes breaks, lunch, Tuesday evening
reception, one  ticket to dinner in the  Dinosaur Room of the  Natural
History Museum on Wednesday, and a copy of the conference proceedings.

Student  registration includes breaks, lunch and proceedings but  does
not include the  dinner/museum event.  On site registration will begin
Monday August 29, 1994 from 7:30AM - 5:00PM, and every day of the con-
ference starting at 7:30 am.



ACM and SIGcomm Membership
--------------------------

If  you are not an ACM or a SIGCOMM member at this time, you may  join
now to take  full advantage of ACM/SIGcomm Member or Student rates for
SIGCOMM94:

- ACM Associate Member Dues      	$82/#52
- Add SIGCOMM to ACM Membership      	$22/#15
- ACM Student Dues                  	$25/#17
- Add SIGCOMM to ACM Student Membership	$15/#10
- SIGCOMM Membership only (non-ACM)  	$50/#32

Total Membership Fees              $/#  _________

(Note: $ indicates U.S. dollars, and # British Pounds Sterling)

To advance the sciences and arts of information processing; to promote
the free interchange of  information about  the sciences  and  arts of
information processing both among  specialists and  among the  public;
and  to  develop  and  maintain  the  integrity  and   competence   of
individuals engaged  in  the  practice  of  information processing.  I
hereby affirm that I subscribe  to the purpose of  ACM and  understand
that my membership is not transferable.

Signature _________________________________________ Date ____________


Tutorials 
---------

Check each tutorial attending.  The tutorial registration fee includes
one copy  of the tutorial notes and  lunch.  Tutorials  are on a first
come first serve basis.

- T1 	Personal Communication Services & Networks (Monday) 
- T2 	Protocol Performance (Monday)
- T3 	Fiber Optic Networks (Tuesday) 
- T4 	Multimedia Conferencing on the Internet (Tuesday) 
- T5 	Asynchronous Transfer Mode (Tuesday) 
- W1 	Workshop on Distributed Systems (Tuesday)  

Tutorial Rates         
			Postmarked by         	Postmarked
			aug/1/1994           	after aug/1/1994
                                          
ACM/SIG Member          _____@ $275/#172        _____@ $325/#205  
Non-Member              _____@ $350/#220        _____@ $400/#250 
Student                 _____@ $138/#87         _____@ $175/#110 

Total Tutorial Fees     _____$/#                _____$/#  


Special Needs 
-------------

Vegetarian Meals:    	- Yes  	- No


Conference Registration
-----------------------

Please complete and  send  registration form, with check,  credit card
information or money orders (no purchase orders) to the address below.
Registrations accepted  via postal  mail,  fax or  email (with  credit
card) only.

				Postmarked by         	Postmarked
				Aug/1/1994           	after Aug/1/1994
                                          
ACM/SIG Member			_____@ $315/#200 	_____@ $365/#230  
Non-Member     			_____@ $397/#252  	_____@ $440/#275 
Student       	 		_____@ $100/#63 	_____@ $130/#82 
	
Total Registration  Fees    $/# _____               $/# _____

Extra Dinner/Museum Ticket      _____@ $55/#35


TOTAL ENCLOSED             $/#  _____ (ACM/SIGCOMM Membership, tutorials,
                                       conference registration)



NAME _________________________________________________________________

AFFILIATION __________________________________________________________

ADDRESS ______________________________________________________________

______________________________________________________________________

PHONE _____________________________ FAX ______________________________

Email ADDRESS ________________________________________________________

SIGCOMM Member? 	- YES    	 - NO
ACM/SIGCOMM Member Number ____________________________________________

CREDIT CARD PAYMENT 	- VISA   - MASTERCARD   - euroCARD

CARD HOLDER NAME _____________________________________________________

CARD NUMBER ______________________________________ EXP. DATE _________

SIGNATURE ____________________________________________________________


Please send this  form and a check,  credit card information  or money
orders (no purchase orders) to SIGCOMM'94.  Registrations accepted via
postal mail, fax or email only.

Send U.S. or   				Send Pound Sterling
Credit Card Payments to:

Patrick McCarren                        Soren-Aksel Sorensen
ACM - 17th Floor                        Dept. of Computer Science
1515 Broadway                           University College London
New York, NY 10036                      London WC1E 6BT
USA                                     United Kingdom
phone: +1 212/626/0611                  phone: +44 71 380 7269
fax: +1 212/302-5826                    fax +44 71 387 1397
mccarren@acm.org 

Email registrations  can  only  be  made  by a credit card  during the
pre-registration period ending 1 August 1994 and must use credit  card
payment.   A registration confirmation  letter  will  be sent to  each
participant  upon  receipt of  the  completed  registration  form  and
accompanying  payment.   Registration fee  will  be  refunded,  less a
$30/#19 administration fee, if  cancelation  notification  is received
prior  to  15  August  1994.  Substitution  for  a  paid  attendee  is
acceptable.
				   
	    ----------------------------------------------
	    C o n f e r e n c e    O r g a n i z a t i o n
	    ----------------------------------------------

General Chair:   Jon Crowcroft, University College London
Program Chairs:  Stephen Pink, Swedish Institute of Computer Science
                 Craig Partridge, BBN (Program Co-Chair for North America)

Ian F. Akyildiz, Georgia Institute of Technology, USA
Lillian N. Cassel, Villanova Univ., USA
Vinton Cerf, MCI, USA
Lyman Chapin, BBN, USA
Jon Crowcroft, Univ. College London, UK
Andre Danthine, Univ. of Liege, Belgium
Gary Delp, IBM, USA
Patrick W. Dowd, SUNY/Buffalo, USA
Deborah Estrin, Univ. Southern California, USA
David Feldmeier, Bellcore, USA
Sally Floyd, Lawrence Berkeley Laboratory, USA
David Greaves, ORL Cambridge, UK
Per Gunningberg, Swedish Institute of Computer Science, Sweden
Christian Huitema, INRIA, France
David Hutchison, Lancaster Univ., UK
Raj Jain, Ohio State University, USA
Jim Kurose, Univ. of Massachusetts, USA
Ian Leslie, Univ. of Cambridge, UK
David Oran, Digital Equipment Corp, USA
Gerard Parr, University of Ulster, Northern Ireland
Guru Parulkar, Washington Univ. St Louis, USA
Krzysztof Pawlikowski, Univ. of Canterbury, New Zealand
Bernhard Plattner, ETH Zurich, Switzerland
Scott Shenker, XEROX PARC, USA
Deepinder Sidhu, Univ. of Maryland-BC, USA
Jonathan M. Smith, Univ. Pennsylvania, USA
Khosrow Sohraby, Univ. of Missouri - Kansas City, USA
James Sterbenz, IBM Research, USA
Greg Watson, Hewlett Packard Labs, UK
Greg Wetzel, AT&T Bell Laboratories, USA
Lixia Zhang, XEROX PARC, USA


	 ---------------------------------------------------
	 F O R   A D D I T I O N A L   I N F O R M A T I O N
	 ---------------------------------------------------

Additional information may be found/requested from:

www:           http://www.cs.ucl.ac.uk/sigcomm94
anonymous ftp: norman.eng.buffalo.edu:/pub/sigcomm94
email:         sigcomm94@eng.buffalo.edu
fax:           +1 716.645.3656
phone:         +1 716.645.2406






-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 23:44:23 +0000
From:      mmcmullen@gsfcmail.nasa.gov (steve johnson)
To:        comp.protocols.tcp-ip
Subject:   simple X protocol questions

someone around here wrote a document specifying certain network
requirements and referred to the X protocol as X-11.  i always thought it
was X.11.  is either one of us right?

i know how to hook people up using X (rexec, rlogin, telnet, etc.), but
have very little knowledge of the details.  i seem to remember seeing
things like X.11R3 and X.11R4.  are these revisions?  am i crazy?  if our
users are running mostly over TCP/IP ethernet lans with an occasional
Novell or AppleShare does it make a difference to our specification?

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 08:26:06 -0500
From:      trisoft@bga.com (TriSoft)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted
Subject:   Re: SLIP and PPP Clients/Dynamic Addressing

David,

   I will make a quick (and highly prejudice) recommendation for MacSLIP. 
It has a very powerful scripting language for automating the connection,
extremely high throughput, and will give good performance on everything up
through a PowerMac.

   If you want to get more information on MacSLIP, you can contact TriSoft
via this email, or 1-800-531-5170 (512-472-0744).

					James M. Knox


-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 94 09:24:49 -0500
From:      imhw400@indyvax.iupui.edu (Mark H. Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing IP address extensions

In article <773783589snz@peeras.demon.co.uk>, proyse@peeras.demon.co.uk (Phil Royse) writes:
> In article <1994Jul6.185228.3682@bay.cc.kcl.ac.uk>
>            udaa055@bay.cc.kcl.ac.uk "Andy Harper, KCL Systems Manager" writes:
> 
>>An oft discussed question is how the IP addresses used on Internet can be
>>extended now that the explosion in personal computers and connectivity has left
>>the 32-bit address space looking a bit sick! Rumour has it that, if growth
>>increases at the same rate as currently, we'll run out of addresses in the near
>>future.
> 
> [stuff deleted]
> 
>>So, what options are there that don't require all and sundry who use Internet
>>to spend wads of cash and/or find upgraded network applications that understand
>>new addressing formats?
>>
>>Andy Harper
>>Kings College London
> 
> Yes, wads of cash, it's bound to be.  I've follwed all the stuff on IPng, 
> TUBA, SIPP CATNIP and now Big Ten (?).  None of them will be a low-cost
> migration.
> 
> I just think that people will become more careful over address allocation.
> I have already floated at least two heretical ideas and one neutral one...
> 
> The neutral one is that DHCP will make life a lot easier and allow
> N temporary users (e.g. PCs) to share M addresses on a " lease " basis.
> 
> The heretical ideas:
> 
> 1.	there are many more TCP/IP users who don't want to connect
> to the Internet and fewer organisations *need* to.  Most of academe
> (as your good selves) is connected.  Corporations who have "a few"
> technical people who can justify Internet connectivity will
> probably settle for clever use of firewalls and proxy telnet, ftp etc.
> 
> 2.	there may come a time when IP address space is so scarce
> that some people will offer it for sale and some will buy it.... well,
> it happens with some very unusual commodities....  Wimbledon tickets,
> cherished number plates, antique toys, trade marks... why not:
> 
> 	"For sale: 123.1.29 to 32  only one owner, $5,000 o.n.o."  
> 	"PLUS - an X.21 PPP link into our Internet router, 
> 	only $4,000 pa."
> 
> There must be many academic bodies with spare address space?
> 
> Any thoughts?

Yeah, but you won't like them.  Bite the bullet and do it right, right now.  IP
was quite good enough for the academic/military/industrial complex, but the
game has changed.  5.5 billion people can't be served with 4 billion addresses,
even if we take all the Coke machines off the net.

It doesn't have to be all-or-nothing.  Gateways exist for VTP/Telnet and
FTAM/FTP, for example, and that should take care of 95% of "traditional" use if
we choose to go that direction.  The infosystem stuff that's growing furiously
right now can ride alternatives just as easily as it can IP, and in fact should
never notice the change.  The backbone network and big players can change as
soon as they all agree on it, and the smaller players can adapt over time as
their vendors give them more attractive options.

After all, that's why we have a layered architecture instead of monolithic
applications.  As long as the interfaces and the semantics are unchanged (so
far as the client knows), the internals of any layer (and layers on the other
side of it) are irrelevant.
-- 
Mark H. Wood, Lead Systems Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  MWOOD@INDYVAX.IUPUI.EDU       BITNET:  MWOOD@INDYVAX
"I live the greatest adventure one could ever wish." - a tosc

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 1994 10:16:05 -0500
From:      dmacfarlane@zip.sbi.com (David R.D. Macfarlane)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   How do I set up routing on SunOS for rempte SLIP users?

I'm having trouble setting up cslip-2.7 on SunOS 4.1.3.  I can get
the line to answer and go into SLIP mode, and my remote station 
(running Trumpet Winsock) can use TCP/IP to the host directly, but
they can't see any hosts outside the local domain.  FTP, Mosaic,
etc., just time out when they try to connect to a distant host.

I think its something to do with routing, but I'm not sure.  How
should routing be set up on the host to which SLIP users dial in?

If I have a default route (created by the existance /etc/defaultroute)
then the in.routed daemon doesn't run, but I don't think I need
dynamic routing so perhaps that's okay.  When the SLIP user is 
connected, sliplogin adds a route so that netstat -r looks like:

Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
localhost            localhost            UH       4      17440      lo0
199.123.192.10       parts                UH       1      33         sl0
default              199.123.192.1        UG       3      6342       le0
199.123.192.0        parts                U        2      308        le0

So, .10 can talk to parts and TCP/IP services on parts, and parts
can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc., 
but .10 can't talk to ftp.uu.net, etc.  

Any suggestions or solutions will be very much appreciated.
Thanks.

	David.


David R.D. Macfarlane    |  "I'm stubborn as those
dmacfarlane@zip.sbi.com  |  garbage bags that time
                         |  cannot decay." - L. Cohen


-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 94 11:21:32 -0500
From:      jefrob@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: THE winsock??

A word on OSI (from a biased vendor of an OSI-based real-time object database):
 
CLNP/CLNS, the OSI connectionless network layer, is arguabbly superior
to IP in both routing algorithms and address space.   Even if you
don't like OSI (probably because it was over-hyped and under-hacked and
in general presented as a top-down big-brained thing nowhere near as
cool as the Internet), you have to admit that the IP layer is undergoing
some potentially serious retooling!
 
Oh, by the way, we have a HIGH-PERFORMANCE OSI stack for windows implemented
as straight 32-bit code in the kernel (VxDs) which supports multiple
netcards full-tilt AND is enabled by X.500.  Our customers use it
underneath our LiveData product, which uses OSI application layer
protocols as the back-bone of a real-time client-server object database.
 
Could our stuff run over TCP-IP?  Of course.  But we decided to get real
with architecture first (which OSI IMHO achieves) and then worry about
low-level issues like whose sliding window is best.
 
Jeff Robbins
Cycle Software, Inc.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 94 11:25:36 -0500
From:      jefrob@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP Question

Walt,
 
I can't answer your TCP question, but our OSI-based products (LiveNet and
LiveData) support multiple simultaneous sub-nets.  You get your choice of
using all sub-nets at once, or designating fall-back sub-nets.
 
LiveNet is a seven-layer OSI stack implemented as 32-bit code in the Windows
kernel.  LiveData is a real-time client-server object database which uses
OSI application protocols like MMS (manufacturing message spec.) as its
backbone.
 
Jeff Robbins
Cycle Software, Inc.
(617) 770-9594

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 1994 03:37:55 GMT
From:      <dennyfox@maroon.tc.umn.edu>
To:        comp.protocols.tcp-ip,comp.os.linux.misc
Subject:   BOOTP Test Program

Can anyone point me to a BOOTP test program which will display the results 
from any/all BOOTP servers who respond to a BOOTP request issued from the 
command line?

Tried the comp.protocols.tcp-ip and comp.os.linux... FAQs with no luck. 
Source code would be nice, I'd like to compile versions for SunOS 4.1.3, 
Linux, and MSDOS.

Thanks in advance...

Denny Fox    E-Mail: dennyfox@maroon.tc.umn.edu

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 06:46:05 GMT
From:      pblack@amos.trl.OZ.AU (Peter Black)
To:        comp.protocols.tcp-ip
Subject:   Query on cwnd algorithm in BSD code


I have been looking at the BSD code for TCP (1990 code and 4.4BSD-Lite), and 
have a query.
In the tcp_input.c code, the cwnd update algorithm is:-

	cwnd += pk_size * pk_size / cwnd + pk_size / 8

for (cwnd > ssthresh).

The first part of this is standard (in the rfc), however, the second part 
(pk_size / 8) is stated as being used to allow large windows to open quicker.  
I was wondering where this addition is suggested/defined (eg rfc's, ietf, 
papers) and what precise reasoning is given for this term.

Thanks in advance for any pointers.


Peter Black
Telecom Research Laboratories, Clayton, Vic, Australia
p.black@trl.oz.au
--------------------------------------------------------------------
Peter Black                            |    Phone: +61 3 253 6384
Telecom Research Laboratories          |    Fax:   +61 3 253 6144   
P.O. Box 249                           |    Email: p.black@trl.oz.au
Clayton  Vic  3168                     |
Australia                              |
--------------------------------------------------------------------

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 1994 09:48:31 GMT
From:      jmi@csd.cri.dk (John Mills)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I build an X sniffer (xscope?)

In article 24950@bcarh54a.bnr.ca, coghlan@bcarh5f8.bnr.ca (Patrick Coghlan) writes:
>I want to intercept all packets between an X terminal and a host.
>
>I believe X runs over TCP so can someone please point me at:
>
>   - relevant RFCs I should look at
>   - what "tricks" I need to employ to intercept and forward all
>     packets between the X terminal and the host
>
>Thanks in advance.


I used a freeware product called xscope a few years ago... it came with source...
(You should be able to fiund it with archie?)

It is placed at the display end of the x chain... with a different address,
i.e. 10001 (I think), it's task is to connect to the REAL X-server, and also to
present a server socket to callers... when a caller connectes, it copies the
input socket data to the display socket (and visa versa) printing out any
useful data it finds to it's STDOUT...

You then start your XClient program with <name>:<10001>.0 (or the other way around?)
and your program routes through this... reasopnably easy...

We where thinking of modifying it to record keystrokes and mouse movements for later
replay, but never had the budget to get it to function 100%...

hope this helps!

P.S. You PROBABLY don't need to refer to RFC's but you will need to refer to the
lower level X manuals (some of 0 - 5) in the O'reiley sets...



-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 16:36:48 -0400
From:      chrisl@ncms.org (Chris Lang)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

tfl@psp.co.uk (Thomas F Lee) writes:
>In article <9407070706.AA01007@ariake.nwk.cl.nec.co.jp>
>           mweiss@nwk.cl.nec.co.jp "Michael J. Weiss" writes:
>> Can someone explain what DNS is?
 
>DNS = Domain Name Server

Just to pick a nit, DNS stands for "Domain Name System".  I don't know
of an acronym for the actual servers, they're just called "DNS servers"
or "nameservers".

 -Chris

-- 
Chris Lang                      |   Technology Integration, Inc.
chrisl@ncms.org          	|   3025 Boardwalk
+1 313 995 4042                 |   Ann Arbor, MI  48108

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 17:07:04 -0400
From:      gallaugher@aol.com (Gallaugher)
To:        comp.protocols.tcp-ip
Subject:   MacSLIP w/Zoom v.32bis probs?

I'm trying to use MacSLIP 2.0.4 with my Zoom v.32bis modem.  I can connect
to my host but I get a MacSLIP BOOTP Failed error shortly after
connection.  Does anyone know what could be causing this?  I'm pretty sure
it's in the MacSLIP software because I've used a Supra 144 (before it got
struck by lightning) and a USR 2400 with the same cables, etc. & the both
work fine.  The Zoom works with other services, too.  Also, if anyone
knows how I can contact Hydepark for tech support (I sent a message to
info@hydepark.com), I'd appreciate a phone number or at least a city
they're located in. 

Please E-Mail me at:
jmgallau@mailbox.syr.edu (not my aol account)
Regards, John Gallaugher

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 1994 16:54:24
From:      timc@sni.com.au (Tim Cullen)
To:        comp.protocols.tcp-ip
Subject:   open UDP socket returns ENOSPC - Why ?

On our Unix SVR4 system, the following call
          int s = socket(AF_UNIX,SOCK_DGRAM,0) 
returns s < 0 and errno = ENOSPC, perror() gives 
"No space left on device

Investigation using "truss" shows
         open("/dev/udp", O_RDWR, 0)        Err#28 ENOSPC 

The only way to remove this problem is to re-boot until it happens again.

Does anyone know the cause ? 

ENOSPC is not a documented error form a socket call.

Thanking you in advance

Regards,

Tim Cullen (timc@sni.com.au)
Siemens Nixdorf Information Systems Pty Ltd
655 Pacific Highway, St Leonards, NSW, 2065, AUSTRALIA
Voice: +61-2-430-2154, Fax: +61-2-439-5734

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 1994 11:55:30 +0000
From:      ronald@demon.co.uk (Ronald Khoo)
To:        comp.protocols.tcp-ip
Subject:   TOS bits vs routers

What do notice do IP routers take of TOS bits ?  If you have good info
for any particular router, I would be grateful if you could reply to me
personally, and I will summarise in a week to the list.

If such a summary of this info already exists, I'd be grateful for a pointer.
I've been nearly off-net for almost two years and am a bit lost.

Thanks.

-- 
Ronald Khoo, <ronald@demon.net>
Tel: +60 3 7560 439 (Home)  +60 3 241 5232 (Work) Fax: +60 3 241 8832

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 1994 14:06:56 GMT
From:      hughes@logos.ucs.indiana.edu (Larry J. Hughes Jr.)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

In article <773834307snz@psp.co.uk>, tfl@psp.co.uk (Thomas F Lee) writes:
#In article <9407070706.AA01007@ariake.nwk.cl.nec.co.jp>
#           mweiss@nwk.cl.nec.co.jp "Michael J. Weiss" writes:
#
#> Can someone explain what DNS is?
#
#DNS = Domain Name Server
#
#A DNS server is a _server_ which resolves _Host Names_ into _IP Addresses_.

Not to pick nits, but DNS stands for "Domain Name System."  It can
potentially consist of hundreds or thousands of servers, as it does 
on the Internet.

It would be slightly more accurate to say that it maps a hierarchical
namespace of host names and network addresses.  This includes host names 
to network addresses, and vice-versa (network addresses to host names).

It also supports a separate mapping for mail exchange purposes.

A pretty good conceptual intro to DNS can be found in Douglas Comer's 
"Internetworking with TCP/IP."

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Larry J. Hughes, Jr.                                     hughes@indiana.edu
Indiana University, UCS                                   Software Engineer
Service Development Group                   "Subvert the dominant paradigm"
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 14:37:06 GMT
From:      adiwan@siacbbn.com (Arif Diwan (BBN))
To:        comp.protocols.tcp-ip
Subject:   Re: Installing SLIP

In article <2vcc7p$lbv@acsc.com>, rao@acsc.com (Rao Srinivasa) writes:
R.Srinivasa|> In article <1994Jul1.205328.13600@wisipc.weizmann.ac.il>,
R.Srinivasa|> yuvalt@silver.weizmann.ac.il (Tal Yuval) writes:
...
T.Yuval|> My question is: If I want to connect a SLIP machine to the network
T.Yuval|> (lets say that the host is 132.76.80.121), do I have to create a new
T.Yuval|> network (i.e. 132.76.81) and make 132.76.80.121 its gateway or can I
T.Yuval|> put my SLIP machine on the same IP network?

R.Srinivasa|> You can connect a host by SLIP without wasting a subnet
R.Srinivasa|> number for it ...
...
<<<

You do not have to put the SLIP host on a different subnet. I am on a dialup
SLIP connection and I am on the same parent network. A point-to-point
connection can be thought of as a tuple where the local IP can be the same
as on of your other interfaces. In my case,

le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 128.89.4.202 netmask ffff0000 broadcast 128.89.255.255
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000 
du0: flags=51<UP,POINTOPOINT,RUNNING>
        inet 128.89.4.202 --> 128.89.8.11 netmask ffff0000 
du1: flags=10<POINTOPOINT>
        inet 128.89.4.202 --> 128.89.8.14 netmask ffff0000 

In another scenario I have used variable length subnets to create a virtual
interface which has sort of p2p "connections" to two real interfaces. Here
I used one bit subnets, with the broadcast address of the one-bit subnet
being the virtual interface address. A good many people have objections to
this scheme but we needed it and it works.

-- 

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

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 15:15:10 GMT
From:      longm@firnvx.firn.edu (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   DNS for Windows?

I am looking for a DNS Windows Package.  If anyone knows where I can ftp
one I would appreciate it.

Thanks Mike...
*****************************************************************************
Michael Long - Sr. Systems Programmer
Florida State University/Florida Information Resource Network/Florida D.O.E.
E-mail: longm@firnvx.firn.edu         Phone: (904)487-0911
*****************************************************************************
\\\\
C-oo
  ~

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 17:52:00 GMT
From:      bumble@hudson.cse.psu.edu (Marc David Bumble)
To:        comp.protocols.tcp-ip
Subject:   ATM Performance Monitoring?


I have access to an ATM network in the Bay Area.  The project involves
running audio, video, and shared X applications across the network to other
connected sites.  We can get the applications to run, but we dont
have access to the application source code.

We would like to monitor the performance of the network, and produce
meaningful results.  Is there any shareware software available which
would help us to monitor the network performance across the atm
network?  What parameters are good to monitor, ie which parameters
will be meaningful to others?

The host machine which connects to the atm network, connects directly
to atm via fiber, so ethernet monitors will not help.

thanks for any assistance,

marc

bumble@riacs.edu
NASA Ames Research Center
Research Institute for Advanced Computer Science
Moffett Field, CA

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 18:18:00 GMT
From:      mbrodsky@lmumail.lmu.edu (Deal)
To:        comp.protocols.tcp-ip
Subject:   What is:   FILE SERVICE PROTOCOL  ?



 The L.A. Times Article published and article today on Page 1, 
called "Computer at Nuclear Lab Used for Access to Porn" by Adam S. Bauman 
(A1 Tuesday , July 12, 1994) .

I thought that the article was particularly sensational, accusing 
the Internet as haven for hackers and pirates, and at one point in the 
article he writes:

"Pirate sites...can generally be found only by highly sophisticated 
computer users who are well-schooled in the intricacies of the Internet. 
The pirates use a new and relaitvely obscure method for transfering 
information, known as the "file service protocol," and they often change 
the location of their sites every few weeks to avoid detection"

Does he mean "FTP" or is this "FSP" something else, all together?

I am thinking of writing a letter to the editor, so also respond to 
me directly asap, so that I can confirm what also appears to be sloppy
reporting.

- Michael Brodsky
mbrodsky@lmumail.lmu.edu

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 19:23:14 GMT
From:      twallace@mason1.gmu.edu (Todd A Wallace)
To:        comp.protocols.tcp-ip
Subject:   Problem: our net vs Internet

We are supposed to join the wonderful world of Internet connectivity. To
that end, we have a NetHopper router and a new upgraded account with
Netcom.

However, we have a problem.

The IP addresses are totally different from the IP address we have been
assigned from Netcom. 

QUESTION: Is there a way to resolve this problem without having to
change the IP addresses on every single one of our PCs and UNIX boxes?

Thanks for any help/hints.
Todd Wallace


-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 19:32:55 GMT
From:      gottloeb@kakadu.nba.trw.com (Jeffrey R. Gottloeb)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted
Subject:   Re: SLIP and PPP Clients/Dynamic Addressing

In article <netguide-1107941645340001@netguide.dialup.access.net>, netguide@panix.com writes:
|> 
|> I am interested in finding out what SLIP and PPP clients there are
|> available for the Macintosh besides InterSLIP, InterPPP and MacPPP.
|> Additionally, I am looking for the ability to utilize dynamic IP
|> addressing; I would be very interested in any packages that make this
|> (easily) possible.
|> 
|> Does anyone have any suggestions?
|> (email copies of posts appreciated)
|> 
|> David Wood
|> obsidian@panix.com

We are using MacPPP here in conjuctino with Telebit NetBlazers.
They support dynamic IP addressing.  On the Mac side, you need 
to set MacTCP to server addressing.  On the NetBlazer side you
need to use the pool command to enable address serving.


Jeff
gottloeb@gumby.sp.trw.com

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 04:13:25 -0500
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Usage Billing package ?

In article <2vovt0$bjn@hpwin055.uksr.hp.com>, gerryw@hpbrak42.uksr.hp.com (Gerry WINSOR) writes:
|> Hi,
|> 
|> Anyone aware of a commercially available "TCP/IP Billing" package which'll
|> use actual IP usage rates as the billing calculation ?

and how will it deal with retransmits ?

are they the fault of 
a) a poor RTT estimator in the client
b) a badly engineered network
c) a provider downstream being overbusy
or what have you

and will they bill for the duration of an FTP (the longer my FTP takes, the
_cheaper_ i want t to be, but i rely on loss to triger the TCP backoff to find the
bandiwdth, so how are they gonna reconcile that with the above>?

and who do you charge for sending me mail, or for me sending NFS traffic back to?

sorry, such a package would necessiate looking in and above the transport layer,
and i am not gonna permit you to run it, and anyhow, it will make your routers go 
appalingly slowly

charging by usage only makes sense for traffic that must be restrained - e.g. real time
traffic - bulk data transfer (ftp, email bboards, archie, gopher, wais, www, etc) is
best not useage charged.....it is not optimal...

for these latter, charge for the per annum link into the internet, and rely on fair share
tcp algorithms and sensible packet drop strategies in the routers to do the rest

do you really want to revisit the nightmare most telcos have of spending 30%+ of your
revenuse simply recovering bills?

there is a "market force" myth going around (some people at INET in prague were trying to
perpertrate it) that you get more money by doing useage based charging

this is false, and there are people who even have maths to show it...

-- 
jon crowcroft (hmmm...)

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 20:06:39 GMT
From:      dmore@gisws3.rtpnc.epa.gov (Duane More)
To:        comp.protocols.tcp-ip
Subject:   TTL Versus Expire time

In setting up cache-only server, the Expire time is set to, say, 1000 hours.
I notice that the TTL entry for records coming from the 12 Hours. 

What I am wondering is in the event of some failure, how long will the 
resource records kept by the cahce-only server be used. I guess the real
questions is what the TTL is used for as opposed to the Expire entry
in the SOA record of the cache server.


--
----
Duane N. More                       |  In Support of:                      
dmore@unixmail.rtpnc.epa.gov        |      US EPA 


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 94 20:33:26 GMT
From:      EMMA@pge.com (Edmond Melkomian)
To:        comp.protocols.tcp-ip
Subject:   IBM TCP/IP

Has anyone done work with SMF on MVS and IBM TCP/IP product. Any info is 
appreciated. Please email me at EMMA@PGE.COM

thanks,

Edmond 

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 21:00:50 GMT
From:      vern@daffy.ee.lbl.gov (Vern Paxson)
To:        comp.protocols.tcp-ip
Subject:   Re: What is:   FILE SERVICE PROTOCOL  ?

In article <mbrodsky-120794122315@157.242.64.49>,
Deal <mbrodsky@lmumail.lmu.edu> wrote:
> Does he mean "FTP" or is this "FSP" something else, all together?

FSP is something else.  From the INFO file that comes with the sources:

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

FSP is UDP-based, trading off slow transfer rates for the additional
robustness that comes from a stateless service.  The INFO files directs
interested parties to contact jtraub@cs.cmu.edu.

		Vern

	Vern Paxson				vern@ee.lbl.gov
	Information and Computing Sciences	ucbvax!ee.lbl.gov!vern
	Lawrence Berkeley Laboratory		(510) 486-7504

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 09:18:45 -0700
From:      jbarnes@crl.com (John Barnes)
To:        comp.protocols.tcp-ip
Subject:   How to register UDP ports

  Hi,

  I need to register two UDP ports.  I can not remember how to
  go about doing it.  We have a client/server application we will
  be selling and want to reserve two UDP ports for are application.
  Please email replies to jbarnes@crl.com.

  Thanks,

  Jym Barnes 


-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 08:17:16 -0500
From:      trisoft@bga.com (TriSoft)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted
Subject:   Re: SLIP and PPP Clients/Dynamic Addressing

>You know what? I wish that you would configure my copy of MacSLIP. I got 
>MacSLIP with my Microphone Pro software and found it VERY difficult to set
>up. I'm sorry that I paid extra to get the product, as the free package, 
>MacPPP, is much easier to set up and, according to our unix guys, more 
>reliable. I'm not a moron either, but MacSLIP certainly is a pain to set
>up. 

Curt,

    Have you talked to Software Ventures (the Microphone folks)?  They have
a tech support department to help with problems like this.  And if they
can't solve the problems, then they are supposed to contact the MacSLIP
developer for help.  [Same thing we do for copies *we* sell.]

    In spite of the fact that you purchased MacSLIP from Software Ventures
instead of us, I would still be happy to help you get it set up.  Usually it
only takes a couple of minutes.  Since there is very little setup for
MacSLIP itself (most of the messy stuff is actually config. for MacTCP -- a
problem you would have with *either* MacSLIP or MacPPP), I presume you had a
problem with the setting up a script.

     The first thing needed to make any mods to the script is, of course, to
know what you want it to do.  I.e., what does your service provider expect
from you and what does it send to you.  After that it is just a matter of
going down the sample script (at least, that is how most folks do it), and
making a couple of changes as needed.  [For instance, the sample script we
send out looks for a prompt "Username:", but your server may send the prompt
"login:" -- so you just change the word.]

     If you would like to e:mail me your script and a printout of the
sequence your service provider expects, I will be happy to "mark it up" for
you.  It probably needs about three lines changed, maybe four.

     And (before you ask): No, I am certain you are "not a moron".  The
configuration really is usually pretty simple, but can be intimidating to
someone looking at it "cold."  That makes it easy to get "turned around",
frustrated, and to give up on it.  [BTW, suggestions as to why MacPPP is "so
much easier" would be appreciated.]

     Disclaimer:  Most of the above comments about the sample script refer
to copies of MacSLIP sold by TriSoft.  I do not guarantee they exactly match
whatever Software Ventures may be distributing.

				jmk

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 09:22:45 -0400
From:      jonbeal@saturn.caps.maine.edu (Jon Beal)
To:        comp.protocols.tcp-ip
Subject:   DHCP daemon (or lack thereof)

Sorry to be posting this here, but...

I received a request from someone at mayo.edu this morning about the 
responses I had received for my earlier request of DHCP information.  I 
inadvertently deleted that note before responding, and I can't seem to 
get the right email address.  (I know it's close, but not quite...)
So anyway, my results...

It seems that no DHCP daemon currently exists.  Several companies have 
announced commercial products, but it sounds like they are still in the 
development stages.  It looks like we're stuck waiting or finding other 
solutions...


-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 04:33:12 GMT
From:      balenson@tis.com (David M. Balenson)
To:        sci.crypt,alt.privacy,alt.security,alt.security.pgp,alt.security.ripem,comp.protocols.kerberos,comp.protocols.tcp-ip,comp.security.misc,comp.security.unix,ieee.announce
Subject:   2nd CFP: ISOC Symposium on Network and Distributed System Security

                             CALL FOR PAPERS
                    The Internet Society Symposium on
                 Network and Distributed System Security

        16-17 February 1995, Catamaran Hotel, San Diego, California

GOAL: The symposium will bring together people who are building
software and/or hardware to provide network and distributed system
security services.  The symposium is intended for those interested in
the more practical aspects of network and distributed system security,
focusing on actual system design and implementation, rather than in
theory.  We hope to foster the exchange of technical information that
will encourage and enable the Internet community to apply, deploy and
advance the state of the available security technology.  Symposium
proceedings will be published by the Internet Society.  Topics for the
symposium include, but are not limited to, the following:

*  Design and implementation of security services -- access control,
   authentication, availability, confidentiality, integrity, and
   non-repudiation.

*  Design and implementation of security mechanisms and support
   services -- encipherment, authentication, and key management
   systems, including fair cryptography -- access control,
   authorization and audit systems -- and intrusion detection systems.

*  Requirements and designs for securing distributed applications
   and network functions -- message handling, file transport, remote
   file access, directories, time synchronization, interactive
   sessions, remote data base management and access, routing, voice and
   video multicast and conferencing, news groups, network management,
   boot services, mobile computing, and remote I/O.

*  Requirements and designs for securing networked information
   resources and tools -- Archie servers, the Wide Area Information
   Servers (WAIS), the Internet Gopher, and the WorldWide Web (WWW).

*  Design and implementation of measures for controlling internetwork
   communication and services in a coherent manner -- firewalls, packet
   filters, application gateways, and user/host authentication
   schemes.

*  Requirements and designs for telecommunications security especially
   for emerging technologies -- very large systems like the
   international Internet, high-speed systems like the gigabit
   testbeds, wireless systems, and personal communication systems.

*  Special issues and problems in security architecture, such as
   interplay between security goals and other goals -- efficiency,
   reliability, interoperability, resource sharing, and cost.

GENERAL CHAIR:
   Jim Ellis, CERT Coordination Center

PROGRAM CHAIRS:
   David Balenson, Trusted Information Systems
   Rob Shirey, The MITRE Corporation

PROGRAM COMMITTEE:
   Tom Berson, Anagram Laboratories
   Matt Bishop, University of California at Davis
   Ravi Ganesan, Bell Atlantic
   Burt Kaliski, RSA Laboratories
   Steve Kent, BBN Communications
   Paul Lambert, Motorola
   John Linn, OpenVision Technologies
   Clifford Neuman, Information Sciences Institute
   Hilarie Orman, University of Arizona
   Michael Roe, Cambridge University (UK)
   Rob Rosenthal, U.S. National Institute of Standards and Technology
   Jeff Schiller, Massachusetts Institute of Technology
   Mike St. Johns, Advanced Research Projects Agency
   Peter Yee, U.S. National Aeronautics and Space Administration
   Roberto Zamparo, Telia Research (Sweden)

SUBMISSIONS:  The committee invites both technical papers and
proposals for panel discussions on technical and other topics of
general interest.  Technical papers should be 10-20 pages in length.
Panel proposals should be two pages in length, and should describe the
panel topic, name the panel chair, explain the format of the panel, and
list three to four potential panelists.  The technical papers will
appear in the proceedings.  Panel chairs and panelists will have the
option of having written statements appear in the proceedings.

All submissions should contain a separate title page which includes the
type of submission (paper or panel), the title or topic, the names of
the author(s), organizational affiliation(s), telephone and FAX
numbers, postal addresses, Internet electronic mail addresses, and the
point of contact, if more than one author.  Since the review process
will be anonymous, the author's names, affiliations and other
information should appear only on the separate title page.

        Deadline for paper submission:      August 15, 1994
        Notification sent to authors by:    October 17, 1994
        Deadline for camera-ready copy:     November 15, 1994

Submissions must be made by 15 August 1994.  Submissions should be made
via electronic mail.  Submissions may be in either of two formats:
PostScript or ASCII.  If the committee is unable to print a PostScript
submission, it will be returned and ASCII requested.  Therefore,
PostScript submissions should arrive well before 15 August.  If
electronic submission is absolutely impossible, submissions should be
sent via postal mail.

All submissions and other correspondence should be directed to the
Program Co-Chair:

                   David M. Balenson
		   Trusted Information Systems, Inc.
                   3060 Washington Road (Rt. 97)
                   Glenwood, Maryland 21738 USA
		   Phone: 301-854-6889
		   FAX:   301-854-5363
		   Email: balenson@tis.com

Each submission will be acknowledged through the medium by which it is
received.  If acknowledgment is not received within seven days, please
contact the Program Co-Chair as indicated above.  Authors and panelists
will be notified of acceptance by 17 October 1994.  Instructions for
preparing camera-ready copy for the proceedings will be postal mailed
at that time.  The camera-ready copy must be received by 15 November
1994.

-----
-- 
David M Balenson

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 05:11:29 GMT
From:      tpa@well.sf.ca.us (Thomas Paul Anderson)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

MARCO PACE (MPACE@ESOC.BITNET) wrote:
: Hi,
 
: can anybody provide some useful advice on the following problem?
 
: I have two applications (running on a SUN workstation with Solaris 2.3)
: communicating using TCP. One is a server, accepting connections; the
: other is a client, connecting to the server. The client writes some
: data to the server after connecting to it, the server reads the data
: after accepting the connection.
 
: The behaviour I can't explain is that, if the server dies (is killed)
: after accepting the connection from the client, the client can still
: perform successfully its write without realizing the death of the
: server. In other words, the write primitive returns successfully.
: A second write to the server, on the contrary, fails as expected.
 
: Why this behaviour ? I think it might be related to the connection
: status (to be checked with the UNIX utility 'netstat') which appears
: to be still existing after the server's death.
: How can I detect the server's death immediately ??
 
: Any help will be appreciated.
 
: Thanks,
 
: Marco
 
: -------------------------------------------------------------------------
: Marco Pace, Software Engineer                   Tel   : +49 6151 903065
: Vitrociset S.p.A.                               Fax   : +49 6151 904065
: ESOC, Robert-Bosch-Strasse 5                    e-Mail: mpace@esoc.bitnet
: D-64293 Darmstadt, Germany   x400: C=DE;A=DBP;P=ESA;O=ESOC;S=PACE;G=MARCO

I guess it depends which side is which:  assuming you are using sockets, then
the "living" side should get a SIGPIPE.  In BSD the default action for SIGPIPE
is "ignore", in SVR4 the default action is termination (talk about a subtle 
change :-}).  

In any event, I would think it advisable to install a SIGPIPE handler to 
allow your applictions to shutdown in an orderly manner.


-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 05:45:08 GMT
From:      davep@comtch.iea.com (Dave Paulsen)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Windows screws up as server?

In article <droehr.16.0009B73A@borland.com>, droehr@borland.com (Daev Roehr) says:

>>Is this a problem, is it only a problem with particular
>>implementations, or is it an inherent problem because
>>windows is non pre-emptive?
>
>Windows make a lousy server, mostly because of the coopertive multi-tasking, 
>partly because the 16-bit address space is all shared, and partly because 
>it's not very robust. It does however, make a pretty good WWW reader.<g> The 

I dunno, it seems to work fine.  My system is a 386-40 w/8Mb and a
couple of older Conner 340Mb IDEs.  Using W4Wg 3.11, Trumpet 1.0b, WinQVT
3.97 FTPServer, and httpd 1.2 on a 28.8 SLIP connection, I've done ftp's
with QVT's client and ws_ftp and get from 26-35 Kbps transfer rates.  The
system is still very experimental, but in limited testing transfering
files and html documents, it hasn't crashed without my deliberately
screwing with it.

_dave_(seemingly obligatory and definately bandwidth wasting .sig)

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 06:20:21 GMT
From:      curt@uhunix3.uhcc.Hawaii.Edu (Curt Fiedler)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted
Subject:   Re: SLIP and PPP Clients/Dynamic Addressing

TriSoft (trisoft@bga.com) wrote:
: David,
 
:    I will make a quick (and highly prejudice) recommendation for MacSLIP. 
: It has a very powerful scripting language for automating the connection,
: extremely high throughput, and will give good performance on everything up
: through a PowerMac.
 
:    If you want to get more information on MacSLIP, you can contact TriSoft
: via this email, or 1-800-531-5170 (512-472-0744).
 
: 					James M. Knox

You know what? I wish that you would configure my copy of MacSLIP. I got 
MacSLIP with my Microphone Pro software and found it VERY difficult to set
up. I'm sorry that I paid extra to get the product, as the free package, 
MacPPP, is much easier to set up and, according to our unix guys, more 
reliable. I'm not a moron either, but MacSLIP certainly is a pain to set
up. 

Use MacPPP, if you want fewer set up headaches, IMHO. Or get the guys/gals
at TriSoft to configure it for you. :)

Good Luck,

Curt

up.


-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 07:01:19 GMT
From:      ice@actlab.rtf.utexas.edu (Jeffrey J. Radice)
To:        comp.protocols.tcp-ip
Subject:   Gateway through dynamic SLIP??

I have a local network of tcp/ip connected Linux and WFW3.11.
The Linux box also serves as a SLIP connection to the internet.
It is a dynamic SLIP connection so my host ip varies, while the remote
host ip is constant.
I don't have access to the remote host at all...all i get is an address
from them.

I have played with the /sbin/route to no end, using different default gw
#s, and nothing changes...it is the same effect as when i assign no gateway.
I can telnet through SLIP just fine...I can telnet/ftp from WFW to Linux fine
and from there out.  I can't telnet from WFW to the internet directly.  I
would assume that this is because i need to set up my Linux as the gateway.
What am i missing here?

All help is appreciated.  Please respond via email as i'll be out of town
for a few days.  Thanks.

-jjr
ice@actlab.rtf.utexas.edu


-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 16:25:49 -0400
From:      Ajay.Simha@launchpad.unc.edu (Ajay Simha)
To:        comp.protocols.tcp-ip
Subject:   KA9Q


Hi!


Does anyone know about the copyright info on ka9q?
Any other opinions about this software?

-- 
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
Launchpad is an experimental internet BBS. The views of its users do not 
necessarily represent those of UNC-Chapel Hill, OIT, or the SysOps.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 12:23:21 GMT
From:      mharrop@interlog.com (Matt Harrop)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted
Subject:   Re: SLIP and PPP Clients/Dynamic Addressing

In article <netguide-1107941645340001@netguide.dialup.access.net>,
obsidian@panix.com wrote:

> I am interested in finding out what SLIP and PPP clients there are
> available for the Macintosh besides InterSLIP, InterPPP and MacPPP.
> Additionally, I am looking for the ability to utilize dynamic IP
> addressing; I would be very interested in any packages that make this
> (easily) possible.
> 

MacPPP does dynamic with no problem at all.  InterSLIP may or may not,
I'm not sure.

Regards,
-- 
Matt Harrop                                      mharrop@interlog.com
InterLog Internet Services  voice (416) 537-7453   fax (416) 532-5015
Online   Publishing,  Marketing,   and   Support  on   the   Internet
Lowest  Cost  Dial-Up Internet  Connectivity in Toronto -- $0.25/hour

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 17:29:11
From:      jlamia@skypoint.net
To:        comp.protocols.tcp-ip
Subject:   Trumpet Winsock SLIP at 115200

I would like to run Trumpet's Winosck at 115200 but am unable to set the 
entery field for seepd that high. Is this possible with Trumpet?



-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 10:49:04 +0200
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

tpa@well.sf.ca.us (Thomas Paul Anderson) writes:

>I guess it depends which side is which:  assuming you are using sockets, then
>the "living" side should get a SIGPIPE.  In BSD the default action for SIGPIPE
>is "ignore", in SVR4 the default action is termination (talk about a subtle 
>change :-}).  

That isn't true: SIGPIPE was designed to *kill* naive processes that
continued to write to a pipe w/o a reader. E.g., lastcomm | head
will show the first 10 lines.  You don't want lastcomm to  keep
using up CPU time until it's done reading the pacct file, since none
gets its output.  It gets killed with SIGPIPE.

This is the same for BSD and for SVR4.  (SunOS 4.x and SunOS 5.x both
terminate, as does 4.x BSD)

>In any event, I would think it advisable to install a SIGPIPE handler to 
>allow your applictions to shutdown in an orderly manner.

signal(SIGPIPE, SIG_IGN) will help too (write will return an error).

Casper

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 15:15:45 GMT
From:      mike@ozonline.com.au (Michael Bethune)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

In article <Css2zx.Ezz@syd.dms.CSIRO.AU>, marka@syd.dms.CSIRO.AU (Mark Andrews) says:
>
>In article <2vpbo6$bbv@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes:
>>Anyone got any comments about the behaviour of variable subnetting
>>used with say, OSPF based routing.
 
>Host which are not multi-homed need know nothing of the network
>other than how to find their default router. ICMP redirects should get
>them to the best router regardless of routing protocol being used or
>whether variable subnets are being used.

Hmm, how about subnets with multiple routers. Don't hosts on these networks
need to know more about routing than can be supplied by simply a default router entry?



>
>Host should be using IRDP if available to find the default router.

Umm, whats IRDP?

>
>Multi-homed hosts are the only hosts that should potentially be
>listening routing protocols. This is regardless of whether they are
>acting as a router or not. Be carful with multi-homed machines as most of
>the current crop of OS's  don't cope with having different netmasks on
>the same network. (BSD 4.4 derived system do cope with this senario.)

By the same network, what are we referring to here, does that mean the same
C class or B class network with multiple subnet masks?



>Mark

Thank you for your reply to my Post.

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 15:19:21 GMT
From:      fmanchon@zenon.inria.fr (Francois Manchon)
To:        comp.protocols.dicom,comp.protocols.ibm,comp.protocols.iso,comp.protocols.iso.x400,comp.protocols.misc,comp.protocols.nfs,comp.protocols.pcnet,comp.protocols.ppp,comp.protocols.snmp,comp.protocols.tcp-ip,comp.protocols.appletalk,comp.dcom.cell
Subject:   Summary: Want papers on network performance evaluation

Here is the summary of answers to my question. Thanks to all those who
replied.  Not many answers I am afraid.  But many queries to send the
summary...

Here goes my original question, and then a couple of pointers.

Cheers,

	Francois MANCHON	<Francois.Manchon@sophia.inria.fr>
======================================================================
SIMULOG - Agence Sophia-Antipolis - Les Taissounieres HB2
Route des Dolines - 06560 VALBONNE - FRANCE
Tel: +33 93 65 25 46 - Fax: +33 93 65 25 57
......................................................................
  ``Puisque toutes ces choses nous depassent, 
    feignons d'en etre l'organisateur...'' -- Jean Cocteau

......................................................................
Date: Wed, 29 Jun 1994 11:37:20 +0200
Subject: Want papers on network performance evaluation - comp.protocols.misc #2164
From: Francois.Manchon@sophia.inria.fr (Francois Manchon)

	Hello Netters !

First of all, sorry for posting to so many groups at once.  I really
could not find any well-suited group for this question.  PLEASE do not
post a follow-up.  Reply to me by e-mail and I will post a summary to
comp.protocols.misc if people ask for it.

I am currently doing a survey of performance evaluation for corporate
telecom networks.  I am looking for articles or technical reports
describing experiments or (preferably), algorithms to evaluate the
performances of a network under various load conditions.

Mathematical algorithms are preferred, though simulators might be of
interest.  On-line measurements can be interesting too.

The protocols we are interested in are the following:

- Physical layer: voice/data multiplexers

- Link layer: HDLC/SDLC/LAPB/LAPD, PPP, 802.x (mostly Ethernet,
  Token-Ring and FDDI), Frame-Relay, ATM, ICMP, SMDS

- Network layer: X.25, SNA, IP, CBDS, RIPE, OSPF

- Transport layer: TCP, UDP, APPN, DECnet, ISO transport, IPX


Questions we try to answer are (among others):

- Impact of error recovery on performance (e.g., on packet transmission delay)

- Protocol overheads

- Traffic paterns occurring in real networks

Thanks in advance to all, and please remember to reply by e-mail.
......................................................................
Date: Mon, 18 Apr 1994 14:21:03 +0200
Subject: Re: TCP-IP performance references. - comp.protocols.tcp-ip #13301
From: tkr@puffball.demon.co.uk (Tim Rylance)

The "Internet System Handbook" edited by Daniel C. Lynch and Marshall T. Rose,
Addison Wesley 1993, ISBN 0-201-56741-5 has an excellent 100-page chapter by
Jeffrey Mogul on "IP Network Performance".
--
Tim Rylance <tkr@puffball.demon.co.uk>
......................................................................
Date: Mon, 27 Jun 94 08:36:26 EDT
From: kevin_dubray@wellfleet.com (Kevin Dubray)

Francois,

You might check out "OSI Internet Performance," by Rick Wilder &
Allison Mankin.  (Mitre Technical Report, 1991, MTR-90W001173).  This
report focuses on congestion avoidance and flow control mechanisms in
a TP4 environment.  Perhaps better for you, it also has a good
bibliography which may provide more datapoints for your work.

Allison Mankin (mankin@cmf.nrl.navy.mil) may be able to give you further
pointed insight to your topic.

If possible, would you forward me a copy of your summary?  Unfortunately, I
don't often get a chance to read comp.* and would not like to miss seeing your
summary.  Thank you.

Regards,
Kevin

Kevin Dubray
Wellfleet Communications, Inc.
kdubray@wellfleet.com

[Note: I have not been able to get the Mitre report yet.  Any hint? -- FM]
......................................................................
Date: Mon, 27 Jun 1994 13:19:04 -0500
From: Geoff.Sobering@nih.gov (Geoff Sobering)

You probably already know of the review of ethernet swithes in the March,
1994 issue of "Data Communications".  While the spcifics of the article may
be of little interest to you, the testing methdology may.  The test was
specifically constructed to test the perfomance of the various devices
under full-load, worst-case conditions.

I look forward for your synopsis.

Good luck,

Geoff Sobering                            Geoff.Sobering@nih.gov
In Vivo NMR Research Center               (301) 402-3209 (voice)
National Institutes of Health             (301) 402-0119 (FAX)
Bldg. 10, Rm. B1D-125
Bethesda, MD 20892
......................................................................
Date:      Mon, 27 Jun 1994 17:55:45 PDT
From: "Jose Carrasco" <jcarras@telemtrx.com>
Organization: Network Telemetrics, Inc.

Hello Francois...in reply to your posted request for information.

Network Telemetrics in Los Angeles, California USA manufactures a unique 
system for measuring end-to-end response time from  PCs to SNA mainframes
and from PCs to file servers.  The name of the product is ProView-SNA.

ProView-SNA lets you monitor Service Level 24 hours a day, is independent
of network topology and generates its' own traffic at the application layer.

The Proview-SNA consists of three components:

        1.The Master Station, which executes on a dedicated OS/2 workstation,
        serves as the main user interface and provides the centralized  
        SQL database for storing data, generating reports and charts of the  
        response times. 

        2.Remote Agents, which execute in the background on user workstations
        to query SNA hosts and generate file transfers with any file servers
        the user has authorized access to. 

        3.The ProView-SNA VTAM application which executes in an MVS 
        environment that routes test commands and results between the Master
        Station and the Remote Agents.

In reply to your request I will gladly mail to you literature on our product
and a white paper titled, "Response Time Service Levels On Interconnected
LANs and WANs-- Where Are They?".  Please provide your mailing address.

ProView-SNA is vital to network specialists who need to how their network is
performing and to validate tuning changes.  
     Regards, 

-- 
Jose Carrasco                              Network Telemetrics, Inc.
                                           27001 Agoura Road
Telephone: (818) 878-7300                  Suite 280
E-Mail:    jcarras@telemtrx.com            Calabasas Hills, CA 91301
......................................................................
Date: Tue, 28 Jun 1994 11:48:18 +0200
From: Ornulf Rodseth <Ornulf.Rodseth@regtek.sintef.no>

One very good reference for Ethernet is:

D.R. Boggs, J.C. Mogul and C.A. Kent, "Measured Capacity of an
Ethernet:  Myths and Reality", Proc. ACM Sigcomm '88, Computer
Communication Review, Vol 18, No. 4, August 1988, pp.222-234.
ISBN 0-89791-279-9

There is also a longer version, containing more figures, that is
available as WRL Research Report 88/4 from

Digitial Western Research Laboratory
100 Hamilton Avenue
Palo Alto, Ca 94301

This can also be got electronically by sending mail to
"wrl-techreports@decwrl.dec.com" with "Subject: send postscript 88/4".

Could you please e-mail a summary. I do not regularly read these
news-groups.

Ornulf Jan Rodseth M.Sc.	ornulf.rodseth@regtek.sintef.no
SINTEF Automatic Control	+(47) 7359-4351 (direct) / -4375 (switchboard)
N-7034 TRONDHEIM, NORWAY	+(47) 7359-4399 (fax)

[I got this tech report via e-mail.  It works fine.  Very interesting. -- FM]
......................................................................
Date: Tue, 28 Jun 1994 12:24:46 +0500
From: barnett@grymoire.crd.ge.com (Bruce Barnett)

Here is a copy of my paper. Published at InterOp this year...

[7815 lines of PostScript suppressed... here is the title and abstract -- FM]

	      A Multi-level Network Analysis Technique.

			    Bruce Barnett
			   General Electric
	      Corporate Research and Development Center
			PO Box 8, 1 River Road
			Schenectady, NY 12301
			(518)-387-5220 (Voice)
			 (518)-387-7332 (FAX)
			 <barnett@crd.ge.com>

			       ABSTRACT
  This paper describes a technique for analyzing low-level  network
  performance  data  captured  using  tcpdump.   It  can categorize
  gigabyte-level traffic by volume  and  packets,  protocol,  port,
  source,  and/or  destination.   IP  fragments  information may be
  placed with the appropriate TCP or  UDP  session.   Raw  data  is
  abstracted into sessions, providing duration and transmission in-
  formation.  High-level errors such as dropped  packets,  received
  buffer  exhausted, etc., are detected.  The percentage of elapsed
  time spent waiting for responses,  timeouts,  interpacket  delays
  and inter-buffer delays is automatic ally calculated by analyzing
  state-sensitive delays between packets.  This can be used to  op-
  timize distributed applications, and diagnose problem areas.
......................................................................
From: seanf@ngc.com (Sean Finn)
Date: Wed, 29 Jun 1994 20:17:10

Francois,

  I am very interested in this subject as well. I work for Network General, 
and use our Sniffer product in the assessment of network conditions. 

I have been able to locate only a few items that I consider worthwhile, such 
as the DEC WRL 88/4 report from David Boggs, et al. re: measurement of 
Ethernet capacity. The Jain book on Performance Analysis had some concepts, 
but not specific to communication issues. 

I'd be interested in knowing what type of results you find, & perhaps identify 
any other tidbits that would go towards a Network Performance Analysis 
resource list.

thanks -- Sean   (finns@ngc.com)
......................................................................
Date: Thu, 30 Jun 1994 15:46:18 -0400
From: wsmith@etc.com (Randy Smith [Warren Randall Smith])

I have several pieces of advice.  First of all, you're never going to
get a mathematical or simulation model that will give you a real taste
of network performance.  In reality little consequences (software
and hardware implementation and bugs) get in the way of these nice
models.  I'm not sure what your goal is, but I'd bet that a little
use of mathematical models to get very rough performance estimates
followed by some real-world testing is going to give you the best
results.  You can spend forever trying to model something that
you can go out and buy for a fraction of the cost of the models.

I've got information on traffic patterns of several real networks
for work I did on my Ph.D. thesis (all using several Ethernets).

Send me e-mail if you have any questions.

-Randy
wsmith@etc.com or wsmith@cedar.cic.net

[I agree with you, Randy.  Modelling will never totally replace
real-world testing.  But sometimes you really need modelling. -- FM]
......................................................................
			  That's all folks!

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 94 18:14:11 GMT
From:      carlson@dwp.la.ca.us (Carlson Peters)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Windows screws up as server?

In article <2vvv14$1o5@krel.iea.com> r.phantom.com!hkwu writes:
>In article <droehr.16.0009B73A@borland.com>, droehr@borland.com (Daev Roehr) says:
>
>>>Is this a problem, is it only a problem with particular
>>>implementations, or is it an inherent problem because
>>>windows is non pre-emptive?
>>
>>Windows make a lousy server, mostly because of the coopertive multi-tasking, 
>>partly because the 16-bit address space is all shared, and partly because 
>>it's not very robust. It does however, make a pretty good WWW reader.<g> The 
>
>I dunno, it seems to work fine.  My system is a 386-40 w/8Mb and a
>couple of older Conner 340Mb IDEs.  Using W4Wg 3.11, Trumpet 1.0b, WinQVT
>3.97 FTPServer, and httpd 1.2 on a 28.8 SLIP connection, I've done ftp's
>with QVT's client and ws_ftp and get from 26-35 Kbps transfer rates.  The
>system is still very experimental, but in limited testing transfering
>files and html documents, it hasn't crashed without my deliberately
>screwing with it.

Don't bet anything important on Windows as a server platform.  The
fact that you can deliberately crash it says boatloads.  It might be
passable running one server process with a single client at a time and
nothing else running.  Just try stressing it a little bit and see the
whole thing crash fast.


































-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Carlson Peters			carlson@asg.dwp.la.ca.us

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 18:37:29 +0000
From:      tfl@psp.co.uk (Thomas F Lee)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

In article <773912743snz@peeras.demon.co.uk>
           proyse@peeras.demon.co.uk "Phil Royse" writes:

> 
> In article <773834307snz@psp.co.uk> tfl@psp.co.uk "Thomas F Lee" writes:
> 
> >A DNS server is a _server_ which resolves _Host Names_ into _IP Addresses_.
> >
> >We played with this a bit during last week and the DHCP stuff works
> >great.  Didn't really have much time to explore WINS though.  Documentation
> >on DHCP can be found on gowinnt.microsoft.com (there is a DHCP.DOC Word
> >document by J Allard - worth reading).  
> 
> Thomas,  what were using for the DHCP server?  an NTAS system? Beta?

NTAS Beta 1 running on a 486/50.  It all seemed quite easy, really.
 
> I have got the TCP-32 Beta stack working between my two WfWG 3.11
> PCs here, and I would like to play with DHCP, ahead of advising some 
> clients on this.

It's pretty neat stuff, but I am going to have to play with it a bit
more to really understand the relationship between DHCP and WINS.

Thomas
-- 
+-----------------+---------------------------+
! Thomas F Lee    !  Voice: 0628 850 077      !
! tfl@psp.co.uk   !  Fax  : 0628 850 143      !
+-----------------+---------------------------+

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 19:13:49 GMT
From:      micky@ejv.com (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   Multiple IP Addresses on One Physical Wire?


I know that it is technically feasible to have a network with
devices that are running different IP addresses on the same
wire in this fashion.

+-----------+                             +-----------+
| 142.9.1.1 |                             | 142.9.1.2 |
|     A     |                             |     B     |
+-----------+                             +-----------+
      |                                         |
=============================================================================
      |              |                                            |
      |        +-----------+                                +-----------+
      |        | 135.3.1.1 |                                | 135.3.1.2 |
      |        |     C     |                                |     D     |
      |        +-----------+                                +-----------+
      |
+-----------+
| 135.3.1.9 |
|     R     |
+-----------+

And I only expect A to reach B, and for C to reach D -- and have no
expectation for A to reach either C nor D (same for B).  Meaning
connectivity between machines with similar network addresses.

What I want to know is, does this confuse any of the devices on this
net?  [A-D] are sun workstations, and R is a router.  Given this
configuration will any of these devices have a problem when they
see packets with a 'foreign' network address?

I know that Cisco routers can actually be configured to support
multiple IP addresses out of one physical interface.  

Is this 'legal' to do in tcp/ip-land?  Given that it works, is there
any reason that I shouldn't do this?  And if I shouldn't do this,
why does Cisco have this feature?

Micky


-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 19:36:12 GMT
From:      kruckenb@sal.cs.utah.edu (Pete Kruckenberg)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell,comp.os.linux.admin
Subject:   [Q] Use one Class C for two networks w/ Novell MPR?

I have a network with the following topology:

    IPX 300
 ----------------------------------
 |
 |    IPX 400                                     PPP
 [MPR]----------------------------[    Linux     ]-----(Internet)
 |                           |   [Gateway/Router]
 |                           |
 |                   [IPX/Ethertalk router]
 |                           |
 | Ethertalk (Appletalk)     |
 -----------------------------

The 300, 400, and Ethertalk segments are all connected into a variety
of Netware servers. What I need to do is route TCP/IP traffic between
the three segments, so a machine on any segment can talk to any other
machine, including external machines through the Linux gateway. Right
now, any machine on the 400 segment can go through the gateway just
fine.

We've got Novell's Multi-Protocol-Router (MPR), a Class C IP (254
hosts) allocation, and connections from the MPR machine to each of the
segments. My (first) question is whether we can do this with a single
Class C, or if we need a class C for each segment (we only need about
100 IP #'s now, so three Class C's would be unnecessary except for
this). Is there a way we can use the subnet mask to spread the Class C
over the three segments? How would I do this (assume no more than
80 hosts on each segment)?

My second question will hopefully be answered by the first, but I'll
ask it anyways. Right now, I've got just two cards in the MPR machine
connected to the 300 and 400 segments. When I configure them (with
INETCFG), I assign them IP addresses: 198.60.81.X. If I make them
different, say X is 253 and 254, I get an error message on boot that
they have to be the same because they are on the same interface. If I
make them the same, say X is 254 and 254, I get an error message that
they have to be unique because they're on the same network. What
gives?

Third question: on the 300/Ethertalk segments will my host's default
gateway be the MPR machine, whose default gateway will be the Linux
box? I know that on the 400 segment, the default gateway will be the
Linux box, but I'm a little unsure about the MPR and hosts on the
other segments.

Any help and/or pointers to help will be greatly appreciated. Email or
post is fine. I have directed follow-ups to comp.sys.novell, as this
deals mostly with the MPR, which is Novell.

Thanks for your help and time!
Pete Kruckenberg
kruckenb@sal.cs.utah.edu


-- 
  ------------------------------------------------------------------------
  Pete Kruckenberg                       School: kruckenb@sal.cs.utah.edu
  University of Utah                       Work: pete@dswi.com
  Computer Engineering    For even more addresses, "finger pete@dswi.com"

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 20:28:47 GMT
From:      evansmp@mb52112.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Fake network addresses

Karl Auerbach (karl@cavebear.com) wrote:

: The RFC you cited is quite separate from the "test" reserved addresses.
 
: Class C 192.0.2.x is reserved and should not exists.  I use it as a 
: preconfigured address in products I write and I coerce the IP stack into never 
: sending from that Class C net number.  This forces the user to configure the
: product.
 
: I doubt, however, that routers and such would keep such addresses out of their
: routing tables should they accidently appear.

Agreed, especially as there are machines which manage to route 127.x.x.x
(execpt 127.0.0.1) arround.

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 22:02:48 GMT
From:      art@now.midnight.com (Art Mellor)
To:        comp.protocols.tcp-ip
Subject:   How do you tell if unknown option type is followed by a length byte?


I'm reading the Draft router requirements spec and it says that unknown
options should be ignored. The problem I have is when parsing the options
in an IP packet and you hit a type that you don't know, how do you know
if it is a single byte option or an option followed by a length byte?

Am I missing something in an RFC somewhere that indicates that No Operation
and End of Option List are the only 2 options that are allowed to be
one byte?

Please reply by email. Thanks - art@midnight.com

--


...............................................................................
  Art Mellor       : Midnight Networks Inc. 100 Fifth Avenue Waltham MA 02154 
  art@midnight.com : Vox 617/890-1001 Fax 0028  The Best in Network Software


-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 23:24:00 +0000
From:      mmcmullen@gsfcmail.nasa.gov (steve johnson)
To:        comp.protocols.misc,comp.protocols.tcp-ip,gsfc.network
Subject:   is gosip OFFICIALLY dead?

got an ongoing and rather important debate going with a coworker.  how
true is the following:

1) gosip is officially no longer mandated by the federal government for
use by civil servants and contractors (specifically NASA).

2) you can still use it if you want, but there will be little or no
support for it in the future, so you might as well switch to tcp or
whatever.

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 00:21:18 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

In article <3010f1$h6q@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes:
>In article <Css2zx.Ezz@syd.dms.CSIRO.AU>, marka@syd.dms.CSIRO.AU (Mark Andrews) says:
>>
>>In article <2vpbo6$bbv@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes:
>>>Anyone got any comments about the behaviour of variable subnetting
>>>used with say, OSPF based routing.
 
>>Host which are not multi-homed need know nothing of the network
>>other than how to find their default router. ICMP redirects should get
>>them to the best router regardless of routing protocol being used or
>>whether variable subnets are being used.
>
>Hmm, how about subnets with multiple routers. Don't hosts on these networks
>need to know more about routing than can be supplied by simply a default router entry?
>

	No. The first packet to a destination that would not noramally
	go via the default router should generate a ICMP Redirect.
	Traffic should then go via the optimal router.

>>
>>Host should be using IRDP if available to find the default router.
>
>Umm, whats IRDP?
>

	ICMP Router Discovery Protocol. See rfc-1256.

	This is supported by CISCO's and Solaris 2.3. There is a version
	of a IRDP daemon available from CISCO, look for prindeville,
	that will supply host and router services for BSD 4.2/4.3 derived
	systems. The IRDP daemon should deal with dead router detection
	an removal of bad redirect routing entries. (The kernel really
	should time these out anyway, though most don't).

>>
>>Multi-homed hosts are the only hosts that should potentially be
>>listening routing protocols. This is regardless of whether they are
>>acting as a router or not. Be carful with multi-homed machines as most of
>>the current crop of OS's  don't cope with having different netmasks on
>>the same network. (BSD 4.4 derived system do cope with this senario.)
>
>By the same network, what are we referring to here, does that mean the same
>C class or B class network with multiple subnet masks?
>

	The above statment was independent of the class of the network
	involved. If a network, whether it be classs A, B or C, has
	different netmasks applied anywhere on it, the routing
	information when installed in a kernel that does not know about
	variable network masks can potentially stuff up internal routing
	in that network, or choose very sub optimal routes.

>
>
>>Mark
>
>Thank you for your reply to my Post.

	Mark.

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 00:52:24 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you tell if unknown option type is followed by a length byte?

> I'm reading the Draft router requirements spec and it says that unknown
> options should be ignored. The problem I have is when parsing the options
> in an IP packet and you hit a type that you don't know, how do you know
> if it is a single byte option or an option followed by a length byte?
> Am I missing something in an RFC somewhere that indicates that No Operation
> and End of Option List are the only 2 options that are allowed to be
> one byte?

I don't know the exact reference, but I'm pretty sure there exists in
writing somewhere, that other than EOL and NOP there will *never* be
a new option without a length field.

	Rich Stevens

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 08:04:32 GMT
From:      albert@dn.itg.telecom.com.au (Albert Fu)
To:        comp.protocols.tcp-ip
Subject:   ARP update mechanism on unix hosts

Could someone please explain how various unix hosts 
(eg. Sun, HP, NCR, Dec Ultrix) update the arp entries.

We had a problem with an ethernet board on a router
yesterday, and when the board was replaced and the router
restarted, we lost connectivity with a number of NCR unix 
hosts attached to the router's ethernet segments. This
lasted for a few hours.

The router would have ARP'ed the host after the restart
(eg in response to a ping request from our operator).
This ARP request would have been sent to the broadcast
Mac address. However, since we couldn't ping the host,
I suspect the host did not update its ARP entry for the
router with the new Mac address that was contained in 
the ARP request, and instead, it sent the ARP response 
to the router's old Mac address.

Should a host updates its ARP cache every time it receives
an IP packet? Also, is there a mechanism for the Unix host to
refresh its ARP cache periodically, eg every 10 minutes?

Albert Fu.

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 16:34:25 -0400
From:      zbig@junior.wariat.org (Zbigniew J. Tyrlik)
To:        comp.protocols.tcp-ip
Subject:   Re: slip--must be 2 nets

In <774184249snz@peeras.demon.co.uk> proyse@peeras.demon.co.uk (Phil Royse) writes:

>In article <2vhvfh$5pj@junior.wariat.org>
>           zbig@junior.wariat.org "Zbigniew J. Tyrlik" writes:
 
>>Using Livingstone PM series I use one C class to service a dozen hosts 
>>on Ethernet, and 2 PM's with dial-up lines; no problems assiging
>>IP's from this same network, no subnetting in use... 
>>
>>
>>_zjt ( wannabe in training )
 
>Yes, but do you need to use two IP addresses per remote link?

No. 

>one for the actual PC at the remote site and one for the terminal 
>servers' SLIP port?

No. Whole Livingstone lives with one IP, fpr ethernet and all 30 
serial lines. 

>How many simultaneous remote users can you support with one Class C
>network address?  254?

Assuming that I will use this C class only for slip, 253: 
one IP for Terminal Server; 
one IP for remote machine. 

With limitation that remote units are always single machines. 

>TIA
 
>-- 
 
>Phil Royse     Comms Consultant  |  PRA Consulting Ltd.


_zjt ( wannbae in training )

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 10:39:59 GMT
From:      H.J.Snel@ATT.COM (Henk J. Snel)
To:        comp.protocols.tcp-ip
Subject:   wanted: tcpping

I am wondering if someone has written a ping program which uses the
TCP protocol i.s.o. UDP (i.e. tcpping). 

This program must have the same capabilities like fping
(timeout limit, retry limit, etc.)

--
Henk J. Snel	      | Internet:    H.J.Snel@ATT.COM
Network Administrator | UUCP:        ...!uunet!att!hvlpa!hsnel
Room BG-S64	      | Phone:       +31 35 872311
Larenseweg 50	      | Fax:	     +31 35 875857
1200 BD Hilversum     | 
The Netherlands	      | "The Wonderful World of UNIX"

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 10:44:27 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Installing SLIP

In article <2vcc7p$lbv@acsc.com> rao@acsc.com "Rao Srinivasa" writes:

>
> You can connect a host by SLIP without wasting a subnet number for it ... 
>
>
>                                130.76.79 
>                        -------------------------------------
>                                                    |
>                                                    |
>                  130.76.80.126                     | 130.76.79.100
>---------               ----------              ---------
>Host    | SLIP          |         |             |       |
>to      |---------------|   M1    |             |  M2   |
>connect |               |         |             |       |
>--------                ---------               ---------
> 130.76.80.125              |130.76.80.66            | 130.76.80.65
>                        -------------------------------------


Rao,

I found your answer very interesting, re setting up SLIP connections.

Are you saying that a single SLIP connection needs to use up TWO
IP addresses?  one for the remote host (130.76.80.125) and one
(130.76.80.126) for the base connection (is that a terminal server 
port?)

If we are setting up many remote dial-in connections using SLIP and 
we want each remote PC to have a fixed (dedicated) IP address, then 
we need to use twice as many IP addresses as we have remote PCs?

Thanks for your advice.

Phil
-- 
Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 11:01:51 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

In article <774124649snz@psp.co.uk> tfl@psp.co.uk "Thomas F Lee" writes:

PR> Thomas,  what were using for the DHCP server?  an NTAS system? Beta?
>
>NTAS Beta 1 running on a 486/50.  It all seemed quite easy, really.
> 
>It's pretty neat stuff, but I am going to have to play with it a bit
>more to really understand the relationship between DHCP and WINS.
>
>Thomas

Thanks.

Re. WfWG 3.11 and the TCP/IP-32, I have just started playing with the
address assignments and seeing what happens when I configure more
than one IP address for each interface (as one is allowed to do in the
"Network Setup- Advanced" pulldown window).

I have had some fairly wierd results, which were inconclusive and
probably due to finger trouble on my part.

It seems that I can easily configure TWO IP addresses to each
Ethernet card on each of my 2 Ethernet connected PCs.  This is confirmed 
with the "ipconfig /all" command.

However, in the LMHOSTS. file if I "#PRE" both addresses, then the
interfaces refuse to link at NetBIOS level, ie. WfWG stops talking.
With #PRE -loaded addresses for only one IP address per PC, WfWG
works just like before, but totally ignores the second IP address(s)

But I can perfectly well ping from any PC to BOTH of the IP addresses
on each machine, using ping<IP address>.  When I ping<hostname>, it
grabs the first listed IP address in the HOSTS. file.

It seems that the TCP/IP transport is happy with multiple addresses
on any PC, but WfWG 3.11 (ie. the NetBIOS stuff) doesn't like it?

Why is this?

What is the point of multiple IP addresses on a PC?

Am I missing some interesting functionality here?

Any ideas?

-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 11:10:49 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: slip--must be 2 nets

In article <2vhvfh$5pj@junior.wariat.org>
           zbig@junior.wariat.org "Zbigniew J. Tyrlik" writes:

>Using Livingstone PM series I use one C class to service a dozen hosts 
>on Ethernet, and 2 PM's with dial-up lines; no problems assiging
>IP's from this same network, no subnetting in use... 
>
>
>_zjt ( wannabe in training )

Yes, but do you need to use two IP addresses per remote link?
one for the actual PC at the remote site and one for the terminal 
servers' SLIP port?

How many simultaneous remote users can you support with one Class C
network address?  254?

TIA

-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 11:51:02 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Usage Billing package ?

In article <1994Jul12.125058.30409@ucl.ac.uk>
           ucacjon@ucl.ac.uk "Jon Crowcroft" writes:

>In article <2vovt0$bjn@hpwin055.uksr.hp.com>, gerryw@hpbrak42.uksr.hp.com
> (Gerry WINSOR) writes:
>|> Hi,
>|> 
>|> Anyone aware of a commercially available "TCP/IP Billing" package which'll
>|> use actual IP usage rates as the billing calculation ?
>
>and how will it deal with retransmits ?

[stuff deleted]
>
>charging by usage only makes sense for traffic that must be restrained 
> - e.g. real time traffic - bulk data transfer (ftp, email bboards,
> archie, gopher, wais, www, etc) is best not useage charged.....
> it is not optimal...
>
>-- 
>jon crowcroft (hmmm...)

I agree, charging for infrastructure usage is very problematical
and expensive to do, even when usage is measurable as it is on connection-
oriented networks.

Charging for connectionless networking is even worse. Don't do it.

In any case, usage-charging is a totally artificial mechanism which
isolates the revenue from the actual costs.  Just look at X.25 PDN
charges:  low connection/capital; medium fixed periodic charge; very
high usage-dependent element.   

And compare this to the **cost** structure, which is totally different:
Very high capital cost (PSEs); medium high fixed periodic
charges (line rentals & maintenance) and VERY, VERY, VERY low 
usage-dependent costs (the extra electricity consumed if more packets 
are flowing thru the PSE).

For a large community and a public service (eg. an X.25 PDN) this glaring
inconsistency is generally accepted, but the smaller the community
for which you want to set up charging eg. a group of companies, local 
authorities, trade assocn. etc it appears really unfair to some. I've gone 
thru this with several clients: you'll never get users all to agree 
on what's fair.  And once you've worked out how to do your usage-based 
charging, you'll never get agreement on a fair tariff structure.

Then, again, depending on the environment you are planning to serve
you may be constrained to charge something competitive....
what are your users' alternatives?.....

Finally, usage-based charging is a nightmare recipe for making
either a huge profit or a huge loss, based on a small change in 
your tariff.

Do you really want your revenue stream to be that sensitive to others'
usage?

-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 18:38:29 -0400
From:      tal@Warren.MENTORG.COM (Tom Limoncelli)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there a self-aliasing IP address?

In <einste44-1407941544450001@ts6-47.upenn.edu> einste44@wharton.upenn.edu (Eric L. Einstein) writes:

>I connect to the Internet via a SLIP connection, so I have a different IP
>address every time I sign on.  I would like to know if there is a reserved
>IP address that always bounces back to the originator of the signal, no
>matter what the real IP address of that machine is.  This is probably a
>really simple question, but, obviously, I'm IP deficient.  Thanks for your

127.0.0.1 always refers to the "localhost".  "ifconfig -a"
will tell you that 127.0.0.1 is the address of the "loopback"
interface "lo0".  "lo0" is software.

Tom
-- 
    Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)

                   The internet is like a box of chocolates.


-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 12:19:10 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you tell if unknown option type is followed by a length byte?

> I don't know the exact reference, but I'm pretty sure there exists in
> writing somewhere, that other than EOL and NOP there will *never* be
> a new option without a length field.

Just found it: RFC 1122, p. 35.

	Rich Stevens

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 14:45:17 GMT
From:      knight@henson.cc.wwu.edu (Matthew Scott)
To:        comp.protocols.tcp-ip
Subject:   Help, Should we add IPX routing to our campus IP net?


Hello,

I would like to make a request for information about adding IPX routing to
our campus IP backbone.  This is __NOT__ intended to start any religious wars 
(although the topic by definition is one).  I just really need to hear peoples 
opinions and fact, and hopefully pointers to documents that address this 
situation.

The facts:
Our campus has always been a IP network.  We were a small net with 1 Cisco
router.  Just like everyone else, access to local and Internet resources is
now in high demand.  Many Novell lan's, and even an NTAS lan have shown up
all over campus.  We now have 2 Cisco routers (small <8 ports each) and a
large Cisco 7000 on the way.  There have been, and continue to be networking
plans.  On these plans I have my own feelings about what is the best way to do
things, but then don't we all :-)  

The big consideration now is, in an attempt to allow NTAS and Novell 
to function better, whether to route IPX along with IP across the entire
campus.

All the individuals involved have their own __IDEAS__ of what is "right"
and what is "wrong".  I am one of those people.  However, I have _always_
argued that we should evaluate the technology and then based upon the
resulting information make a well thought out decision, that is the best 
solution based upon technical and empirical information, __NOT__ on 
sales hype and peoples personal preferences!

This all being the case I must say that I have a "knowledge deficit" in the
realm of one of these protocols.  Therefore, I would like to get as much
information on the effects of adding IPX routing to an IP only backbone.
Are there huge performance hits, do the networks typically experience
significantly larger amounts of traffic,  do the benefits of routing
multiple protocols out weigh any negative effects?  Any information that I 
can use to help educate those (on both sides of the fence) would be 
greatly appreciated.

I understand that there are __MANY__ facts about network design that
affect the ability of the network to perform its duty.  These many other
issues will be considered along with the info that I am able to gather from
the collective net wisdom.

Thank you for your time, and hopefully information.
Matt

(This is being posted to comp.protocols.tcp-ip, comp.sys.novell and
comp.dcom.cisco to try and get all sides of the issue.)

---
Matthew Scott - knight@admcs.wwu.edu           Western Washington University
Voice: (206) 650-6839                          Administrative Computing Services
Fax: (206) 650-7323                            Unix sys admin/sys programmer

And you might notice no one is ever free
And maybe, just maybe for now that's how it's supposed to be
Could be so far we've only earned the right to barely see

-Blues Traveler

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 23:40:04 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   What is MBONE?

The subject line says it all: What is MBONE? (not just what the acronym
stands for, either--what IS it?)

Thanks,

--Mike

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 94 23:46:47 -0500
From:      jefrob@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: MAP TOP details

Try http://litwww.epfl.ch/~ppvx/mms.html on www
 
Jeff Robbins
Cycle Software, Inc.
(617) 770-9594

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 15:33:05 GMT
From:      chris@quay.ie (Christopher Davey)
To:        comp.unix.aix,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip
Subject:   Linking 2 IP Subnets through SNA

Does anyone know whether it is possible to link 2 IP subnets
through a SNA network. If so, what it required ?

The machines at each end are Windows NT machines. 

Is it possible to tunnel IP through using PPP or somesuch ?

Please email me at chris@quay.ie and I will post a summary if 
there is an answer....

Thanks in advance,

Chris
-- 
----WNA----------------------------------------------------------------------
Chris Davey                       Internet: chris@quay.ie
Quay Financial Software           Phone   : +353 1 6612377 Fax: +353 1 6607592
The views expressed above do not necessarily reflect those of my employer

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 94 21:39:48 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP Addresses on One Physical Wire?

In article <1994Jul13.191349.658@ejv.com>, micky@ejv.com (Micky Liu) writes:
> 
> I know that it is technically feasible to have a network with
> devices that are running different IP addresses on the same
> wire in this fashion.
> 
> +-----------+                             +-----------+
> | 142.9.1.1 |                             | 142.9.1.2 |
> |     A     |                             |     B     |
> +-----------+                             +-----------+
>       |                                         |
> =============================================================================
>       |              |                                            |
>       |        +-----------+                                +-----------+
>       |        | 135.3.1.1 |                                | 135.3.1.2 |
>       |        |     C     |                                |     D     |
>       |        +-----------+                                +-----------+
>       |
> +-----------+
> | 135.3.1.9 |
> |     R     |
> +-----------+
> 
> And I only expect A to reach B, and for C to reach D -- and have no
> expectation for A to reach either C nor D (same for B).  Meaning
> connectivity between machines with similar network addresses.
> 
> What I want to know is, does this confuse any of the devices on this
> net?  [A-D] are sun workstations, and R is a router.  Given this
> configuration will any of these devices have a problem when they
> see packets with a 'foreign' network address?
> 
> I know that Cisco routers can actually be configured to support
> multiple IP addresses out of one physical interface.  
> 
> Is this 'legal' to do in tcp/ip-land?  Given that it works, is there
> any reason that I shouldn't do this?  And if I shouldn't do this,
> why does Cisco have this feature?
> 
> Micky
-----------
	It's commonly done. The essentials are to not listen to RIP, so
there is no confusion about "this network" and the like. Instead stations
use static routes to the cisco (or equiv) and that in turn knows how to
relay to the target. Doubled network traffic is the frequent result.
	The attraction is as you have shown, and frequently in the form
of different subnet masks on each station and those that may be located
behind them. The subnet mask (identity of "this network") need not be
consistent amongst stations on the backbone. If we used a better RIP
replacment (OSPF or whatever) which carried subnet mask information
with it then this kludge would be less attractive.
	Just think of it as a fully routed Internet, all on one piece
of coax. But don't think of it if traffic is quite heavy already.
	Whether it's fully legal I don't know. I do know that my site
has depended upon it for some time (K's of stations).
        Joe D.

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 94 16:12:24 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

In article <2vvt21$e04@nkosi.well.com> tpa@well.sf.ca.us (Thomas Paul Anderson) writes:
>MARCO PACE (MPACE@ESOC.BITNET) wrote:
>: Hi,
 
>: can anybody provide some useful advice on the following problem?
 
>: I have two applications (running on a SUN workstation with Solaris 2.3)
>: communicating using TCP. One is a server, accepting connections; the
>: other is a client, connecting to the server. The client writes some
>: data to the server after connecting to it, the server reads the data
>: after accepting the connection.
 
>: The behaviour I can't explain is that, if the server dies (is killed)
>: after accepting the connection from the client, the client can still
>: perform successfully its write without realizing the death of the
>: server. In other words, the write primitive returns successfully.
>: A second write to the server, on the contrary, fails as expected.
 
>: Why this behaviour ? I think it might be related to the connection
>: status (to be checked with the UNIX utility 'netstat') which appears
>: to be still existing after the server's death.
>: How can I detect the server's death immediately ??
 
>: Any help will be appreciated.
 
>: Thanks,
 
>: Marco
 
>: -------------------------------------------------------------------------
>: Marco Pace, Software Engineer                   Tel   : +49 6151 903065
>: Vitrociset S.p.A.                               Fax   : +49 6151 904065
>: ESOC, Robert-Bosch-Strasse 5                    e-Mail: mpace@esoc.bitnet
>: D-64293 Darmstadt, Germany   x400: C=DE;A=DBP;P=ESA;O=ESOC;S=PACE;G=MARCO
>
>I guess it depends which side is which:  assuming you are using sockets, then
>the "living" side should get a SIGPIPE.  In BSD the default action for SIGPIPE
>is "ignore", in SVR4 the default action is termination (talk about a subtle 
>change :-}).  
>
>In any event, I would think it advisable to install a SIGPIPE handler to 
>allow your applictions to shutdown in an orderly manner.
>

I'll throw in my $.02.  Most TCP implementations with which I am
familar will buffer a certain amount of data at a new endpoint before
it is accept()ed by the application.  That is part of the reason one
or more client side write()s may succeed when the server dies shortly
after accept()ing the connection.  The other part may be a bit harder
for you to swallow. There is a time lag between when the server dies
and the connection reset arrives at the client host.  write()s which
occur before this notification will "succeed" while write()s that
occur after will fail and generate a SIGPIPE. NOTE: A SIGPIPE is
generate in response to a write() on a disconnected endpoint, not as
a result of the endpoint becoming disconnected.  However, a SIGIO is
generated (assuming you have set asynch I/O on the socket) will be
generated by a disconnect (as well as when data arrives or there is
room to write data).

Depending on your application, you may want to setup receiving
asynch events (SIGIO) so you can be notified as soon as possible when
the connection is lost (i.e. the server dying).

--
John A. Scott                         Data General
Phone: +1 919 248 5995                62 TW Alexander Drive
Email: scott@rtp.dg.com               Research Triangle Park, NC 27709

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 17:21:17 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

> >: The behaviour I can't explain is that, if the server dies (is killed)
> >: after accepting the connection from the client, the client can still
> >: perform successfully its write without realizing the death of the
> >: server. In other words, the write primitive returns successfully.
> >: A second write to the server, on the contrary, fails as expected.
 
>>In any event, I would think it advisable to install a SIGPIPE handler to 
>>allow your applictions to shutdown in an orderly manner.
 
> There is a time lag between when the server dies
> and the connection reset arrives at the client host.  write()s which
> occur before this notification will "succeed" while write()s that
> occur after will fail and generate a SIGPIPE.

All of this discussion confirms my claim that the majority of network
programming problems arise from a lack of understanding of the underlying
protocols, and have nothing to do with the interface (TLI or sockets)
or operating system.  (This is why I wrote "TCP/IP Illustrated" before
starting the 2nd edition of "Unix Network Programming.")

Fact: when a process terminates, be it voluntary (i.e., exit()) or
involuntary (i.e., killed by a signal) all open descriptors are closed.

Fact: when an established TCP connection is closed, TCP sends a FIN
and goes through the normal four packet exchange to gracefully close
the connection.  If you read() from a connection that has received a
FIN, after all pending receive data has been returned, read() returns
0 (i.e., end of file).  TCP's FIN gets returned as an EOF.

Fact: TCP purposely provides a half-close facility.  One end can call
shutdown(fd,1) (using sockets; the same thing can be done with TLI).
This causes TCP to send a FIN, but the end calling shutdown can still
receive data, it just can't write any more.  The other end that receives
the FIN won't receive any more data, but it can still write to the
connection.  KEY point here: when you receive a FIN, TCP still lets
you write to the end point because of the half-close capability.
Remember: TCP connections are full-duplex.

Fact: when your end receives a FIN you cannot tell whether the other
end terminated or did a half-close.  If your application protocol
never uses a half-close, then you can assume the other end terminated.

Fact: if you write to a TCP end point that has received a FIN, TCP
gladly sends the data (because of the half-close).

Fact: when TCP receives data for a connection for which a process no
longer exists, TCP responds with an RST segment.  If you issue a read()
on an end point that has received an RST, read() returns -1 and errno
is set to ECONNRESET.

Fact: under Unix when you write() to a TCP end point that has received
an RST, SIGPIPE is sent to the process.

Put all this together and you discover that the first write() after
receiving a FIN succeeds.  But if the process at the other end really
went away, your end receives an RST in return.  Naturally, receiving
either a FIN or an RST causes a select() on readability to return true,
which is the normal way to detect these scenarios.  I'd guess you
also get SIGIO on the receipt of either, but haven't verified this.

Bottom line: use select() to determine when you receive a FIN in a
network application.  Almost every one of the now-frequent postings
"how can I tell if the other end died" can be solved by using select()
and *always* testing for readability, since the process at the other
end can die at any time, but it'll always cause a FIN to be sent.
Now if you want to tell if the *host* at the other end has died (not
the process) then that takes us back to the keepalive wars ... :-)

	Rich Stevens

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 17:56:14 GMT
From:      crohrer@advtech.uswest.com (Chris Rohrer)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP Addresses on One Physical Wire?

In article <1994Jul13.191349.658@ejv.com>, Micky Liu <micky@ejv.com> wrote:
>
>I know that it is technically feasible to have a network with
>devices that are running different IP addresses on the same
>wire in this fashion.

(figure deleted)
>
>And I only expect A to reach B, and for C to reach D -- and have no
>expectation for A to reach either C nor D (same for B).  Meaning
>connectivity between machines with similar network addresses.
>
>What I want to know is, does this confuse any of the devices on this
>net?  [A-D] are sun workstations, and R is a router.  Given this
>configuration will any of these devices have a problem when they
>see packets with a 'foreign' network address?
>
>I know that Cisco routers can actually be configured to support
>multiple IP addresses out of one physical interface.  
>
>Is this 'legal' to do in tcp/ip-land?  Given that it works, is there
>any reason that I shouldn't do this?  And if I shouldn't do this,
>why does Cisco have this feature?
>
>Micky
>

I would have thought the only significant problem in doing this is that
any traffic going from, let's say, A to C would have to pass through the
router. The effect is that you double the amount of traffic on the wire
for any such packets.  

As long as each host's routing decision making code knows about next hops
for 'foreign' addresses, the packets should be routed correctly in and
back out of the router.  Cisco routers do in fact have the ability to
assign a primary and several so-called secondary addresses to a given
port.

I can't imagine any host on the system having a problem with the existence
of packets with 'foreign' addresses in them.  They shouldn't even ever see
them since a host only pays attention to things arriving with the right MAC
address anyway.

If you have a router there, though, why wouldn't you just use it in the
'normal way' and allocate a port and segment to each group of devices?

Chris Rohrer


-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 19:03:11 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

In article <3009q0$ken@mail.fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes:
>tpa@well.sf.ca.us (Thomas Paul Anderson) writes:
>>I guess it depends which side is which:  assuming you are using sockets, then
>>the "living" side should get a SIGPIPE.  In BSD the default action for SIGPIPE
>>is "ignore", in SVR4 the default action is termination (talk about a subtle 
>>change :-}).  
 
>This is the same for BSD and for SVR4.  (SunOS 4.x and SunOS 5.x both
>terminate, as does 4.x BSD)

I think what causes people to think that some Unix versions ignore the
error is that the C Shell doesn't print "Broken pipe" when a process
terminates due to SIGPIPE.  So they execute "something | head", don't see a
termination error, and assume the commands both ran to completion.  I
assume this message was removed because such terminations are so common and
normal, and printing an error would make it seem like something had gone
wrong.


-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 19:27:12 GMT
From:      nirav@manduca.neurobio.arizona.edu (Nirav C. Merchant)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   MAP TOP details

Hi,
  I was looking for details on MAP/TOP and its existing status ... and if it is alive then possible products that are complaint to MAP/TOP standards.

Could someone give me pointers for locating such products/information.


Thanks,

Nirav
--





-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 19:48:03 GMT
From:      einste44@wharton.upenn.edu (Eric L. Einstein)
To:        comp.protocols.tcp-ip
Subject:   Is there a self-aliasing IP address?

I connect to the Internet via a SLIP connection, so I have a different IP
address every time I sign on.  I would like to know if there is a reserved
IP address that always bounces back to the originator of the signal, no
matter what the real IP address of that machine is.  This is probably a
really simple question, but, obviously, I'm IP deficient.  Thanks for your
help.

Eric

-- 
Eric L. Einstein
einste44@wharton.upenn.edu
The Wharton School of the University of Pennsylvania

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 21:16:47 GMT
From:      edward@ece.concordia.ca (Edward Milczarek)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Source Code


I would like to get the source code for the various TCP/IP
functions. I would be grateful if someone can help me out.

	Thanks in advance.


-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 94 06:14:29 -0500
From:      baldwinl@delphi.com
To:        comp.protocols.tcp-ip
Subject:   RFC implementation for all TCP/IP vendors?

Is there a document that describes which RFC's the various
TCP/IP vendors
implement in their TCP/IP's (preferable by product version #).
 
Boy, am I dreaming.
 
Thanks.

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 23:31:25 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP Addresses on One Physical Wire?

In article <1994Jul13.191349.658@ejv.com> micky@ejv.com (Micky Liu) writes:
>
>I know that it is technically feasible to have a network with
>devices that are running different IP addresses on the same
>wire in this fashion.
>
>+-----------+                             +-----------+
>| 142.9.1.1 |                             | 142.9.1.2 |
>|     A     |                             |     B     |
>+-----------+                             +-----------+
>      |                                         |
>=============================================================================
>      |              |                                            |
>      |        +-----------+                                +-----------+
>      |        | 135.3.1.1 |                                | 135.3.1.2 |
>      |        |     C     |                                |     D     |
>      |        +-----------+                                +-----------+
>      |
>+-----------+
>| 135.3.1.9 |
>|     R     |
>+-----------+
>
>And I only expect A to reach B, and for C to reach D -- and have no
>expectation for A to reach either C nor D (same for B).  Meaning
>connectivity between machines with similar network addresses.
>
>What I want to know is, does this confuse any of the devices on this
>net?  [A-D] are sun workstations, and R is a router.  Given this
>configuration will any of these devices have a problem when they
>see packets with a 'foreign' network address?
>
>I know that Cisco routers can actually be configured to support
>multiple IP addresses out of one physical interface.  
>
>Is this 'legal' to do in tcp/ip-land?  Given that it works, is there
>any reason that I shouldn't do this?  And if I shouldn't do this,
>why does Cisco have this feature?
>
>Micky
>

	This is a pretty standard sort of configuration.

	With standard configurations A, B and R will communicate
	between themselves, and C and D between themselves.

	There are a number of ways you can change the above
	configuration and have everything talking.

	1. The router R should have an address on every network
	   on the ethernet. This will permit A and B to talk to C and D
	   via R.

	2. You can optimise the routing by telling A and B that they can
	   reach the other net by installing additional routes by hand.

	   For BSD 4.2 derived system "route add net 135.2.0.0 142.9.1.1 0"
	   will enable A to send packet to C and D directly.

	Alternatively you could enable "proxy arp" on the router and set
	the default route to be the local interface i.e. "route add
	0.0.0.0 142.9.1.1 0".

	Mark

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1994 00:10:24 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there a self-aliasing IP address?


In article <304ep5$rfb$1@sdl.Warren.MENTORG.COM>, tal@Warren.MENTORG.COM (Tom Limoncelli) writes:
|In <einste44-1407941544450001@ts6-47.upenn.edu> einste44@wharton.upenn.edu (Eric L. Einstein) writes:
|
|>I connect to the Internet via a SLIP connection, so I have a different IP
|>address every time I sign on.  I would like to know if there is a reserved
|>IP address that always bounces back to the originator of the signal, no
|>matter what the real IP address of that machine is.  This is probably a
|>really simple question, but, obviously, I'm IP deficient.  Thanks for your
|
|127.0.0.1 always refers to the "localhost".  "ifconfig -a"
|will tell you that 127.0.0.1 is the address of the "loopback"
|interface "lo0".  "lo0" is software.

Well, sure enough 127.0.0.1 will refer to your SLIP client machine
from the context of that machine, but from the context of a remote
machine, 127.0.0.1 will be THAT machine.  So this won't help you
much.

The real answer is: all providers of dialup SLIP service should 
provide THE SAME IP address to each client every connection.  If
you don't do this, nameservice, SMTP, .rhosts, etc., etc.
will not work tolerably.  Encourage your provider to get his
act together.

Aaron

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

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 1994 01:31:57 GMT
From:      samg@netcom.com (Sam Ghandchi)
To:        comp.protocols.tcp-ip
Subject:   Re: Need to Find TTCP???

Sam Ghandchi (samg@netcom.com) wrote:
: Hi 
 
: I am looking for TTCP.  Could you tell me where 
: I can find it?  
 
: TIA,
: - Sam Ghandchi
: samg@netcom.com

Thank you all for your help in your Emails.


-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 1994 03:49:27 GMT
From:      biegler@aristotle.cs.uregina.ca (Mark Biegler)
To:        comp.protocols.tcp-ip
Subject:   UDP Broadcast with no loopback?

Is it possible to broadcast UDP packets to an ethernet network without
having the sending host receive them itself?  I'd like my software
to only receive packets sent by other systems... not the info it's
sending out.

FYI, it's running under IRIX4 and eventually SunOS, Linux, and ULTRIX.

Thanks in advance.

Please mail me at biegler@cs.uregina.ca

- Mark

---
Mark Biegler   (VE5MPB)				biegler@cs.uregina.ca
Department of Computer Science			W:  (306) 585-4110
University of Regina				H:  (306) 522-1770
Regina, Saskatchewan  Canada  S4S 0A2		Office:  CW 307.12

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1994 04:12:33 GMT
From:      lorraine@snrc.uow.edu.au (Lorraine de Vere)
To:        comp.protocols.tcp-ip
Subject:   Dynamic IP addressing


Hi,

I'm currently trying to track down different protocols that provide dynamic
IP address assignment.  Pointers to documents describing the dynamic assignment
mechanisms would be particularly appreciated.

So far I know about DHCP and PPP.  If anyone knows which of the RFCs and Internet
Drafts that discuss PPP describe dynamic IP addressing that would also help.


Thanks in advance

Lorraine :-)


-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 1994 11:27:12 -0400
From:      Sean McLinden <sean+@andrew.cmu.edu>
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.sys.novell
Subject:   Q: Motorola CODEX 3260 and Netware DIALUP.EXE


Has anyone a clue as to how to get a CODEX 3260 (V.FC) modem to properly
initialize for Novell dialup slip? I seem to have no problem using the
modem from a terminal package but the DIALUP.EXE chokes and dies on it.

Thanks.

Sean

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1994 04:55:22 GMT
From:      cooperb@unixg.ubc.ca (Peter Cooperberg)
To:        comp.protocols.tcp-ip
Subject:   network switching

appletalk, ethertalk, Duo, Duodock

I have a Duo 230 and 2 Docks. The one at the hospital is on an ethernet 
but not the one at home. At home it switches back to appletalk. However 
at work I have to switch back to ethertalk using the control panel "network".
Anybody knbow of an easier way. Preferably automatically.
Thanks


-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 1994 07:44:14 GMT
From:      synopsis@zeus.datasrv.co.il (Synopsis Sys.)
To:        comp.protocols.tcp-ip
Subject:   ISO Transport on TCP (RFC1006)

Subject: ISO Transport on TCP (RFC1006)
Newsgroups: comp.protocols.tcp-ip
Organization: DataServe LTD. (An Internet Access Provider), Israel.
Summary:
Keywords:

Subject: ISO Transport on TCP (RFC1006)?
Newsgroups: comp.protocols.tcp-ip
Organization: DataServe LTD. (An Internet Access Provider), Israel.
Summary:
Keywords:

Has anyone had any experience with implementing / using ISO Transport on
top of TCP/IP as defined in RFC1006?

RFC983 mentions that a UNIX version is available from the authors: D.E.
Cass & M.T. Rose. Where can I find the sources / How do I contact the
autohrs?

Thanks, Gal Nachum

------------------------------------------------------------
Gal Nachum              Tel: +972-3-7528698
Synopsis Systems        Fax: +972-3-7527248
P.O Box 62010
Tel-Aviv 61620          email: synopsis@zeus.datasrv.co.il
I S R A E L             Compuserve: CSID 100274,1141
------------------------------------------------------------




-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1994 09:51:51 GMT
From:      Erik Molenaar
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: What is MBONE?

In article <9407150439.AA13226@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes:
>The subject line says it all: What is MBONE? (not just what the acronym
>stands for, either--what IS it?)
>
>Thanks,
>
>--Mike

Mike,

If WWW lies in you possibilities try the following URL. 

http://www.eit.com/techinfo/mbone/mbone.html

Good luck!

Erik Molenaar
erik.molenaar@net.iend.wau.nl
Wageningen Agricultural University - the Netherlands

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1994 12:51:23 GMT
From:      jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO Transport on TCP (RFC1006)

In article 2710@news.datasrv.co.il, synopsis@zeus.datasrv.co.il (Synopsis Sys.) writes:
>
>Has anyone had any experience with implementing / using ISO Transport on
>top of TCP/IP as defined in RFC1006?

Yup, much experience using...  You will find that most commercial OSI stack
implementations support RFC1006 (OSI TP over TCP/IP) as well as native OSI
network protocols (CLNP, X.25).  SunSofts' OSI Stack, SunLink/OSI, can support
simultaneous connections over CLNP, X.25 & RFC1006-type networks.

>>RFC983 mentions that a UNIX version is available from the authors: D.E.
>Cass & M.T. Rose. Where can I find the sources / How do I contact the
>autohrs?

What you are looking for is ISODE (ISO Development Environment).  I believe the
latest freely distributed version is 8.0.  Commercial development of the code
was taken over a few years ago by X-Tel (now known as Nexor) in the UK.  The
free version of ISODE can be found on many anonymous FTP servers, including the
one at University College London (where most of the ISODE development took place).

ISODE will compile (with no code changes) on most BSD-based UNIXes, but could be
ported to other platforms as well.

>Thanks, Gal Nachum
>
>------------------------------------------------------------
>Gal Nachum              Tel: +972-3-7528698
>Synopsis Systems        Fax: +972-3-7527248
>P.O Box 62010
>Tel-Aviv 61620          email: synopsis@zeus.datasrv.co.il
>I S R A E L             Compuserve: CSID 100274,1141
>------------------------------------------------------------

You're welcome,

-- John Brady, Consultant
   SunNetworks, A Sun Microsystems, Inc. Business
   (703) 204-4859 (voice)
   (703) 204-4782 (fax)
   john.brady@East.Sun.Com



-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 1994 13:08:59 GMT
From:      hbae@cwis.unomaha.edu (Hansang Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: network switching

cooperb@unixg.ubc.ca (Peter Cooperberg) writes:
>appletalk, ethertalk, Duo, Duodock
>I have a Duo 230 and 2 Docks. The one at the hospital is on an ethernet 
>but not the one at home. At home it switches back to appletalk. However 
>at work I have to switch back to ethertalk using the control panel "network".
>Anybody knbow of an easier way. Preferably automatically.

If you get an email answer, could you plz post it!


  Hansang Bae --------------------------------------------------------
| hbae@unomaha.edu        | Data Communication  EAB 013C              |
| hbae@cwis.unomaha.edu   | Voice: (402) 554-3769 FAX: (402) 554-3475 |
 ---------------------------------------------------------------------

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1994 16:09:02 GMT
From:      harri906@raven.csrv.uidaho.edu ( That Harrington)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.i386,comp.os.386bsd.questions,alt.os.bsdi
Subject:   SLIP: Setting it up on BSDI 1.1

	Hello all,
I am struggling to set SLIP up on BSDI 1.1.  I don't have a book on it, 
and man pages stink, so my net friends are the last resort. :)
	
	I want to enable users to dialin, login, and type 'slip'...and it 
will start.  Or something.

	ANY help on it would be appreciated.
	
Dan Harrington


-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1994 16:09:09 GMT
From:      kannan@ISI.EDU (Kannan Varadan)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   Increasing the number of mbufs in a SunOS4.1.3, sparcstation 10 kernel

I am trying to increase the number of mbufs available to the UNIX kernel
in a SUN sparcstation 10, running SunOS 4.1.3 system.

I had initially tried adjusting some of the definitions in various
include files in <machine/*.h> and rebuilding the kernel from source.
I had tried two strategies, one where I tried moving all hard-wired
addresses in the kernel that I could find down by 2MB; and another where
I stole 2MB from the buffer cache, adjusting addresses in between.

In the former, I adjusted
	KERNELSIZE, KERNELBASE, SYSBASE, MBPOOLBYTES in <machine/param.h>
	V_WKBASE_ADDR, VA_PERCPU, VA_PERCPUME and other "compatibility"
		addresses in <machine/devaddr.h>
	IOMMU_MBUTL_BASE in <machine/iommu.h>
	AUXIO_REG in <machine/auxio.h>
only to get an "Instruction Access Exception".  Running it through kadb
yields a stack trace on crash which makes scant sense to me.

Stealing 2MB from the buffer cache,
	SYSBASE, MBPOOLBYTES, BUFBYTES in <machine/param.h>
	V_WKBASE_ADDR, VA_PERCPU, VA_PERCPUME and other "compatibility"
		addresses in <machine/devaddr.h>
	IOMMU_MBUTL_BASE in <machine/iommu.h>
	AUXIO_REG in <machine/auxio.h>
In this instance, I get a "Data Access Exception".

I would appreciate talking to someone who has achieved this, or can
help me figure out what I am missing.

Thanks,


Kannan

Folllowups directed to comp.unix.internals; there is no
comp.sys.sun.internals newsgroup.

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 1994 19:09:23 GMT
From:      evansmp@mb52112.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: slip--must be 2 nets

Zbigniew J. Tyrlik (zbig@junior.wariat.org) wrote:

: >How many simultaneous remote users can you support with one Class C
: >network address?  254?
 
: Assuming that I will use this C class only for slip, 253: 
: one IP for Terminal Server; 

The terminal server does not need to use an address from the class
C network, it can use it "other" address.

: one IP for remote machine. 

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 1994 20:30:22 GMT
From:      sybesma@unirsvl.rsvl.unisys.com (Eric Sybesma)
To:        comp.protocols.tcp-ip
Subject:   ARP - when does it delete cache entries

Hi all,
	We have an application which makes frequent TCP/IP
connect requests to other hosts.  If one of these hosts 
changes its Ethernet address, by maybe swapping the Ethernet
card or the whole host, the TCP/IP software will try to connect
to the old Physical Ethernet address because it is still in
the ARP cache.  The connections continues to time out.

	My questions:

1)  How often is the ARP cache purged?
2)  Is there any way to alert the network to a new physical address 
	at an old IP address?  Do other hosts typically listen in
	on ARP requests and update their cache?

Any suggestions to keep the latent time to a minimum?

es
-- 
Eric Sybesma, Unisys     | sybesma@unirsvl.rsvl.unisys.com | (612) 635-3380 |
Site Management Products | "Sorry, can't talk right now, I'm non-blocking." |
Roseville, MN 55113      | self.am = 0;if (self.mode == thinking) self.am++;| 

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 94 20:31:24 GMT
From:      cgh018@tijc02.uucp (Calvin Hayden x2254)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Re: Does a DHCP daemon exist?

From article <2vjvs4INN1ivq@saturn.caps.maine.edu>, by jonbeal@saturn.caps.maine.edu (Jon Beal):
> 
> I am looking for a daemon for the Dynamic Host Configuration Protocol, as 
> detailed in RFC1541.  Does anyone know if a Unix implementation exists 
> yet?  (If so, where can I find it?)
> 
> 
> Thanks in advance,
> 
> Jon Beal
> 
Me too!  Please email info to me as well.
Only one I know of is one supported as server in NT.  One for Sun on way,
but who from, when, which OS, etc...

Calvin Hayden
cgh018%tijc02@uunet.uu.net
-- 
Calvin Hayden                   Uucp: uunet!tijc02!cgh018        
Siemens Industrial Automation   Inet: cgh018%tijc02@uunet.uu.net  
-- My opinions and mine alone --      cgh018@tijc02.uucp         

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 1994 22:01:09 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

In article <1994Jul14.172117.9666@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>All of this discussion confirms my claim that the majority of network
>programming problems arise from a lack of understanding of the underlying
>protocols, and have nothing to do with the interface (TLI or sockets)
>or operating system.

It's funny, but all of your comments confirms *my* claim that a
popular bogus implementation can completely change the semantics of a
protocol to the point where the underlaying specification is no longer
important. I mean, really, the fact that a violent abortion of a
process could generate a graceful close of its open TCP connections is
just extraordinary. It virtually negates the advantage of a graceful
close, since the peer is no longer sure the application layer protocol
was responsible for the close, or a SIGTERM was.

						don provan
						donp@novell.com

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 1994 23:49:16 GMT
From:      drhodes@hercules.win.net (Dylan Rhodes)
To:        comp.protocols.tcp-ip
Subject:   Q: FTP...how?


        A reeeeeaaaal naive question:

If I have:

- IBM-type PC 
- Ethernet card 
- Netware 3.11 network 
- Off-the-shelf MS-DOS or Windows TCP/IP package, with FTP
  client/server capability

What more do I need to get my machine talking to the outside world
in such a manner that I can offer an FTP site?  What are my
options?

Can anybody recommend a text which covers basic stuff such as
this?  Is there an appropriate FAQL?

Thanks.

Dylan Rhodes                   drhodes@hercules.win.net
I'm not speaking for my employer at the present moment.
 
 


-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1994 01:02:48 GMT
From:      jjs@snjst0.pacbell.com (John Sottile(TNM))
To:        comp.protocols.tcp-ip
Subject:   Passive Mode FTP


I'm looking for any examples of FTP commands which describe the Passive
Mode File Transfer.  I'm able to put the Server into passive mode via the
quote pasv command.  The RFC describes the Server to Server use of the PASSIVE
command (using the quote port ... command) but I can't seem to get it to 
work.  

I start 2 FTP commands to 2 different Servers as it describes in the RFC.

ftp A
(login)
quote PASV
(get port number)


ftp B
(login)
quote port (port from above)


Then I let FTP server a fly with commands (either via get or QUOTE STOR/RETR)
and the connection eventually times out.

Has anyone out there done this before?  Better yet, is there a way to completely
initiate the file transfer from a single FTP client?

Thanks in advance for any information.

-----------------------------------------
John Sottile
jjs@snjst0.pacbell.com



-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Jul 1994 06:23:59 GMT
From:      samg@netcom.com (Sam Ghandchi)
To:        comp.protocols.tcp-ip
Subject:   Re: Need to Find TTCP???



I was asked to summarize my replies on the net.
You can find TTCP from ftp.sgi.com

Regards,
- SamG

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1994 21:29:02 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

In <CswMBI.K4A@syd.dms.CSIRO.AU> marka@syd.dms.CSIRO.AU (Mark Andrews) writes:

>In article <3010f1$h6q@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes:
 
>>Hmm, how about subnets with multiple routers. Don't hosts on these
>>networks need to know more about routing than can be supplied by
>>simply a default router entry?
>>
 
>	No. The first packet to a destination that would not noramally
>	go via the default router should generate a ICMP Redirect.
>	Traffic should then go via the optimal router.

I'm not sure if the IDRP daemon handles this case (I've never used it),
but consider the problem of the "mobile" host (M). If host A on
a subnet with routers AA and BB uses AA as a default router, when
it tries to send a packet to M and is ICMP redirected to BB, all is
fine; but then M moves (say it's a PPP connection that dials up in different
areas) such that the path from A to M is via AA. Then A receives a 2nd
ICMP redirect for M, this time to AA; it seems that many implementations
(SunOS 4, for instance), ignore this second ICMP redirect, resulting in
packets going to BB _then_ AA, each time. I can find no justiciation
for this behavior in RFC792...

--
John Hawkinson
jhawk@panix.com

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 94 18:47:17 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

In article <1994Jul15.220109.17838@novell.com>, donp@novell.com (don provan) writes:
| In article <1994Jul14.172117.9666@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
| >All of this discussion confirms my claim that the majority of network
| >programming problems arise from a lack of understanding of the underlying
| >protocols, and have nothing to do with the interface (TLI or sockets)
| >or operating system.
| 
| It's funny, but all of your comments confirms *my* claim that a
| popular bogus implementation can completely change the semantics of a
| protocol to the point where the underlaying specification is no longer
| important. I mean, really, the fact that a violent abortion of a
| process could generate a graceful close of its open TCP connections is
| just extraordinary. It virtually negates the advantage of a graceful
| close, since the peer is no longer sure the application layer protocol
| was responsible for the close, or a SIGTERM was.

Historians may wish to note that 2.9 (and, I think, 4.1c) actually
passed a flag to the tcp stack to tell it whether the socket was
being closed at process termination.  (Of course, it didn't tell
whether the process had died gracefully. :()  I suspect the reason
for removing this flag was simply that it made socket handle semantics
different from those of all other handles.  (All other handles were
closed identically by process exit or close().)

				Dan Lanciani
				ddl@harvard.*

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 1994 17:56:00 -0500
From:      mflll@uxa.ecn.bgu.edu (Dr. Laurence Leff)
To:        alt.dcom.telecom.ip,comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Livingston Portmaster woes

We are having trouble setting up our account mechanisms on our Livingston
Portmaster 2E.  It is running Version 3.0.1 of the software

We need to support both SLIP users and login id's.

When we create a login user the system correctly connects us to the
default host.  We also can configure it to prompt for a host if desired.

However, When we create a network user,

the system always gives us error message
Invalid login after we enter our account and password.

We specified our network user name and password, we had a screen as shown
below
.

Type: Network User
Protocol: Slip
User IP Address: Assigned

Netmask: 255.255.255.0

Routing: Listen

MTU: 100 (created by system)

Compression: Disabled.

There were no filters.

We clicked on create in the radius screen and the system said 
  "User successfully added"

In general, we want regular "normal" users to simply be passed through
to our Sun Workstation which is our default user.

Our SLIP users should be asked for an account and password by the sun.  
Then, they
should be free to use FTP, Telnet, etc. on their computer to whatever
we want.

We want our normal users to be validated by our Sun and to type 
little or nothing to the Portmaster.  However, we need to recognize
our SLIP users.  "They" can be forced to type more information--as they
will be using in with a SLIP MODEM SCRIPT
The normal users should be  allowed to continue on with a minimum of
keystrokes.

How do you suggest handling this.

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jul 1994 10:42:05 GMT
From:      ke4dpx@gregl.slip.iglou.com (Greg Law)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q

In article <301ikd$ql4@lambada.oit.unc.edu> Ajay.Simha@launchpad.unc.edu (Ajay Simha) writes:

>Does anyone know about the copyright info on ka9q?
>Any other opinions about this software?

KA9Q is basically public domain software with commercial restrictions. You can 
use it, modify it, and distribute it to your heart's content provided you 
don't sell it. This may vary slightly with specific releases, but all are 
based on the original public domain code.

I'm currently running the JNOS varient (WG7J/PA3DIS) on amateur packet radio 
and have also experimented with NOSview (PA0GRI) and TNOS. JNOS is more 
service oriented (loads of clients and servers) while TNOS is more user 
oriented (built-in tutorial, help files for everything, etc.) and NOSview is 
easy to get up and running (comes with everything zipped into the proper 
directories). You can get the latest version of JNOS at pc.usl.edu and other 
versions at oak.oakland.edu or ftp.ucsd.edu.


============================================================================
73 de Greg  AMPRNet  - ke4dpx@ke4dpx.ampr.org [44.106.56.35]
            AX.25    - ke4dpxg@wi9p.#ncky.ky.usa.noam
            Internet - gregl@iglou.com
============================================================================

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 1994 17:01:19 GMT
From:      roth@panda.dnr.state.mi.us (Dave Roth)
To:        comp.protocols.tcp-ip
Subject:   Re: NDIS driver source code

In article <CsvGr4.AoD@csd.cri.dk>, jmi@csd.cri.dk (John Mills) says:
>
>In article 120794172221@macheha.biochem.mpg.de, heha@biochem.mpg.de (Herbert Hanewinkel) writes:
>>Does somebody know where I can find the source code of
>>an NDIS driver. I would like to use it as a template.
>>
>>Herbert Hanewinkel
>
>
>The windows NT Device Driver kit (DDK) has a sample NDIS driver... you can find
>it on MSDN level II CD-ROM set (amongst others)... 
>
>Contact MicroSoft for pricing/availability etc...
>
>

But is there something out in the pub dom that could help? I have ripped apart DIS_PKT9.DOS as
much as I think can be done and have looked at the NDIS v2 specs, but that doesnt explain the
questions I have, just tells me what each call expects.
ANYTHING out there?
I have tried to track down something in our local university and via the Library of Congress only
to fail (but then again, Library of Congress is does not use the friendliest search engine).
dave
============================================================================
Dave Roth                                         roth@panda.dnr.state.mi.us
System Administrator
State of Michigan                              "These views are mine, not my
Department of Natural Resources                 employer, blah, blah, blah"
Wildlife Division

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 1994 19:40:07 GMT
From:      aoj@access1.digex.net (aaronjones)
To:        comp.protocols.tcp-ip
Subject:   Simple T1 WAN Networking




Greetings Y'all,

I have a client who has a T1 running between two points seperated by
approximately 1700 miles.
They have a LAN at each one of the two locations. The machines on the
LANS are an assortment of Macs, Windows PCs, and UNIX boxes (SCO,
Solaris 2.3, Motorola 88/Open(yechh), and an RS-6000 thrown in for
good measure.

The machines on the LANs at both ends are running a mixture of TCP/IP,
The LANs are running a mixture of TCP/IP,IPX/SPX, and Ethertalk.

What they would like to do is (strangely enough) connect their LANs
together over the T1 circuit.

They would like to do so at the cheapest possible cost.

BTW, The T1 is currently sitting idle awaiting installation of a Frame
Relay network, but they need something _now_.
I will not be receiving any renumeration for this, but I would like to
help out a friend.

Any advise as to how they might accomplish this would be greatly 
appreciated.

Aaron Jones		Ph: (416) 213-2040  <Witty thought of the day omitted>
InterAccess Consulting  Fax:(416) 213-5760
Toronto, Ontario	Email: aoj@digex.net

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jul 1994 02:14:38 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

In article <30a1gu$3mm@panix.com> jhawk@panix.com (John Hawkinson) writes:
>In <CswMBI.K4A@syd.dms.CSIRO.AU> marka@syd.dms.CSIRO.AU (Mark Andrews) writes:
>
>>In article <3010f1$h6q@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes:
 
>>>Hmm, how about subnets with multiple routers. Don't hosts on these
>>>networks need to know more about routing than can be supplied by
>>>simply a default router entry?
>>>
 
>>	No. The first packet to a destination that would not noramally
>>	go via the default router should generate a ICMP Redirect.
>>	Traffic should then go via the optimal router.
>
>I'm not sure if the IDRP daemon handles this case (I've never used it),
>but consider the problem of the "mobile" host (M). If host A on
>a subnet with routers AA and BB uses AA as a default router, when
>it tries to send a packet to M and is ICMP redirected to BB, all is
>fine; but then M moves (say it's a PPP connection that dials up in different
>areas) such that the path from A to M is via AA. Then A receives a 2nd
>ICMP redirect for M, this time to AA; it seems that many implementations
>(SunOS 4, for instance), ignore this second ICMP redirect, resulting in
>packets going to BB _then_ AA, each time. I can find no justiciation
>for this behavior in RFC792...
>
>--
>John Hawkinson
>jhawk@panix.com

	I could have swarn that I've seen redirects of redirects take
	under SunOS 4.1. Anyway this is very much a kernel issue rather
	than a IDRP daemon issue. The IDRP daemon should flush all
	routes via a gateway once it has stopped announcing its
	presence.

	I can see why a IP stack writer may wish to wish to catch this
	sought of event but I wouldn't do it unless I could also
	timestamp the redirect route entries. i.e. only clobber the
	redirect if the last redirect occured with x seconds, x ~30
	secs.

	Redirects of redirects are normal events where there is more
	that one router attached to the network and any IP statck which
	does not cope with them is very broken.

	Mark.

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jul 1994 02:24:00 GMT
From:      rpk@niagara.edu (Richard P. Kernin)
To:        comp.protocols.tcp-ip
Subject:   Security/Firewall FAQ?

Hello,

I'm currently in the process of researching the use of a firewall machine
to allow our administrative network Internet access, but allow them to
stay "secure" from people hacking in (ie. students, etc.).  I read awhile
back in some document that there was a Firewall FAQ, but I can't find
the document anymore, and have been unable to turn it up in my travels on
the net.  Could someone drop me a line with information on this beastie?

Thanks much!

Take care,

-Rich

---------------------------------------------------------------------------
Richard P. Kernin
Niagara University - Administrative Computer Center

Internet: rpk@niagara.edu	or	visnurpk@ubvms.cc.buffalo.edu

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jul 94 09:39:05 PDT
From:      adar0@routers.com
To:        comp.protocols.tcp-ip
Subject:   Re: How do I set up routing on SunOS for rempte SLIP users?



> I'm having trouble setting up cslip-2.7 on SunOS 4.1.3.  I can get
> the line to answer and go into SLIP mode, and my remote station 
> (running Trumpet Winsock) can use TCP/IP to the host directly, but
> they can't see any hosts outside the local domain.  FTP, Mosaic,
> etc., just time out when they try to connect to a distant host.
> 
> I think its something to do with routing, but I'm not sure.  How
> should routing be set up on the host to which SLIP users dial in?
> 

In /etc/rc.local, add the -s option to the startup of in.routed and
see if that helps.  I'm assuming your routered network uses RIP for
a routing protocol.
Rich
adar0@routers.com


-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 11:04:05 -0500
From:      pieper@cs.uwp.edu (Nathan Pieper)
To:        comp.protocols.tcp-ip
Subject:   BOOTP Help

Does anybody out there know of a dynamic BOOTP server for unix???

Thanks

Nathan Pieper        pieper@cs.uwp.edu
University of Wisconsin Parkside

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 12:53:00 -0500
From:      ross@ndlc.occ.uky.edu (Ross Hayden)
To:        comp.protocols.tcp-ip
Subject:   "easy" bootp question

Hi all!

I have been struggling to get bootp working on several unix system here on
campus, with little luck.

I have several DOS pc's running NCSA telnet, along with the packet drivers
needed to run it on top of my netware drivers (ie odipkt.com).  On my unix
systems I've installed various versions of CMU's bootp package.  The
problem seems to be that replies from the server are never reaching the
workstations.  The bootp server starts on queue, and tcpdump also
indicates this and shows the reply being sent.  The pc, however, just sits
and continually resends requests as if never having received a reply.

If I hard code an IP address into the config file for NCSA telnet,
everything works ok.  Also, I can't get rarp to work either.  So I'm not
really sure if I need to examine my network setup, or if there's a problem
with NCSA telnet.  I've examined my network setup, checking out subnet
masks and broadcast addresses.

Any ideas on what to check here?  I'm stumped.

Thanks for any help,
Ross
--
Ross Hayden, Systems Programmer                   ross@ndlc.occ.uky.edu
The National Distance Learning Center

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 13:13:18 -0400
From:      zbig@junior.wariat.org (Zbigniew J. Tyrlik)
To:        alt.dcom.telecom.ip,comp.protocols.tcp-ip,comp.dcom.servers
Cc:        bri@livingston.com
Subject:   Re: Livingston Portmaster woes


In <30ccu0$ls4@uxa.ecn.bgu.edu> mflll@uxa.ecn.bgu.edu (Dr. Laurence Leff) writes:

>We are having trouble setting up our account mechanisms on our Livingston
>Portmaster 2E.  It is running Version 3.0.1 of the software
 
>We need to support both SLIP users and login id's.
 
>When we create a login user the system correctly connects us to the
>default host.  We also can configure it to prompt for a host if desired.
 
>In general, we want regular "normal" users to simply be passed through
>to our Sun Workstation which is our default user.
 
>Our SLIP users should be asked for an account and password by the sun.  
>Then, they
>should be free to use FTP, Telnet, etc. on their computer to whatever
>we want.
 
>We want our normal users to be validated by our Sun and to type 
>little or nothing to the Portmaster.  However, we need to recognize
>our SLIP users.  "They" can be forced to type more information--as they
>will be using in with a SLIP MODEM SCRIPT
>The normal users should be  allowed to continue on with a minimum of
>keystrokes.
 
>How do you suggest handling this.


I do handle it on PM2e, with 70+ UUCP accounts, 20+ TCP/IP connections, and 
200+ usrs. 

1) set up for everyone an account on Sun. 

2) Set properly RADIUS. Default for user + UUCp is to be connected wia
rlogin to host; on host set hosts.equiv to postmaster address. 
TCP/IP wrapper is handy.... 

3) for SL/IP and PPP prepare an entry for each machine in RADIUS database. 

Here is sample:
###
agar     Password = "UNIX"
       User-Service-Type = Framed-User,
       Framed-Protocol = SLIP,
       Framed-Address = 192.147.145.222,
       Framed-Netmask = 255.255.255.0,
       Framed-MTU = 1006,
        Framed-Compression = Van-Jacobsen-TCP-IP

astro   Password = "UNIX"
        User-Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-Address = 192.147.145.223,
        Framed-Netmask = 255.255.255.0,
        Framed-Compression = Van-Jacobsen-TCP-IP

###
#
#       UUCP users
#
###
###
###
#
#
allbob   Password = "UNIX"
        User-Service-Type = Login-User,
        Login-Host = wariat.org,
        Login-Service = Rlogin
#
bbs     
        User-Service-Type = Login-User,
        Login-Host = wariat.org,
        Login-Service = Rlogin


        
DEFAULT Password = "UNIX"
        User-Service-Type = Login-User,
        Login-Host = wariat.org,
        Login-Service = Rlogin


This way you maintain login/password under UNIX ( shadow password suite 
is a must ); interactive users are loggin once; SL/IP and PPP users are
handled by PM, but files are living under control of UNIX. 


if you need more details, or want me to set it for you - e-mail me
for details ( zbig@wariat.org ). 


_zjt  (zbig@wariat.org) 
-- 
********************************************************************
Zbigniew J. Tyrlik       DoD# 0759   VF700C '84      zbig@wariat.org
APK	       Public Access UNI* Cleveland,          (216)-481-9436
Feeds, shell, FTP, telnet, IRC, MUD      Uniboard distribution point 
********************************************************************

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 18:30:54 -0400
From:      goutham@access1.digex.net (S.Goutham)
To:        comp.protocols.tcp-ip
Subject:   Techniques for finding dead nodes in a WAN.

Can anyone point me in the right direction for constantly checking, say
every 5 minutes, what nodes are down/up in a network. I dont want to ping
constantly all the nodes in the net. I want to know if there are specific
techniques to do this. For example we can have each node look at a set
of nodes and then make them report on their status. The ideal solution
would be to know immediately when a node goes down, rather than taking
about 5 to 10 minutes to find that out. Also, I would not want to send
constant node-alive info. from each node as this could consume net bandwidth
if, say evry minute, a set of 100 to 200 or even 1000 nodes start doing this.

Any hints/suggestions/pointers would be greatly appreciated...Goutham.


-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 21:33:49 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Here's the Story With WATTCP

I have been getting a lot of mail inquiring about WATTCP, and I have
seen quite a few posts with the same questions.  Since I am growing
weary of saying the same thing a hundred times, I will post it:


NOTE: This posting contains just about everything I know about WATTCP,
which is precisely why I posted it.  So, please DO NOT EMAIL ME WITH
QUESTIONS, but POST THEM INSTEAD.  If I know the answer, I will email
you.  Besides, there are many people much more knowledgeable than I who
will also see your post.


DISCLAIMER: I have absolutely no relationship with WATTCP and its
author(s) other than being a satisfied user.  The contents of this
messag are strictly things that are true to the best of my knowledge and
bear no association with any statements, opinions, etc. made by the
authors.


1) Where can I get WATTCP?

WATTCP and related software can be obtained by anonymous ftp to
dorm.rutgers.edu, in the directory /pub/msdos/wattcp.

The following is a PARTIAL list of files and descriptions:


2) What is WATTCP?

WATTCP stands for Waterloo TCP.  It is a public domain TCP/IP package
for DOS written by Erick Engelke of the University of Waterloo.  The
core of this package is the WATTCP kernel, a cleanly written, compact
TCP/IP library written in Borland C (or Turbo C, same thing).  The
package also comes with some sample applications which use the library
functions, such as FTP, finger, etc.  The source code for the
applications as well as the library is available and in the public domain.

Beginners Explanation:  The WATTCP kernel is a C library which contains
the code for "socket" or networking functions.  It can be used to
compile the existing applications (they are also available precompiled
in APPS.ZIP, see question #1) or to allow you to write your own programs
that run on a network, providing you with an easy to use interface to
functons which will handle all of the larborious details of network
communication.

3) What can I do with WATTCP? or Why would I want to use WATTCP?

There are three main uses I can think of:

i) You can run TCP/IP applications such as telnet, ftp, and finger
on your computer.

In this case, you only need the file APPS.ZIP which contains the
application executables.  You will probably want to compare the WATTCP
applications with others from comparable packages before you decide on a
favorite.  My initial impression is that WATTCP is most useful as a
library for programmers wishing to build on it, rather than an
application package for end users, but I am not an expert, and this is
purely a matter of taste.

ii) You can write a "network-able" application.

Writing an appication that supports network communication is as easy as
learning the interface to the WATTCP functions (see question #4),
calling them from your application code, and linking to the WATTCP
library.  If you have never written "socket code" before, you should
take a look at the series of books entitled _Internetworking With
TCP/IP_ by Douglas Comer.  

iii) You can modify the WATTCP library to do something else.

This is a relatively rare case, but if you wanted to implement a variant
on TCP/IP, or otherwise change how a TCP/IP library functions, the fact
that the source code is available makes this possible.


3) What do I need to use WATTCP?

If you're going to program, you will obviously need a C compiler.  If
you plan to compile any of the WATTCP code, you will need to use Borland
C or Turbo C (also by Borland).  There is a port available for Microsoft
C, but there doesn't seem to be any support for it, so I wouldn't
reccommend using it.

You will also need a packet driver.  This is a piece of software that
controls the network card.  WATTCP takes data from the application
(telnet, finger, etc.) formats it according to the rules of the TCP/IP
protocols, and then passes it to the packet driver.  The packet driver
then passes the packet to the network hardware (ethernet board, serial
line, etc.)

If you don't have a packet driver for your card, you can obtain one from
the Crynwr Software Packet Driver Collection.  These are available by
anonymous FTP.  For details, see the document HOWTOGET.IT, appended to
the end of this message.


3) What documentation and support is available?

	i) There is minimal documentation available with the source code
	   (in the file WATTCP.ZIP)  Enough to get the applications up
	   and running and provide background information.

	ii) A programmer's guide, which is a relatively casually
written, but well organized document (about 50 pages long) is available
by contacting:

         WATTCP Manual
         c/o Supro Network Software Inc.
         P.O. Box 18,
         Warsaw, Ont.
         CANADA
         
	 K0L 3A0

	 PHONE: (705) 652-1572

The price varies depending on where you live, but it is in the
neighborhood of $40-$50 US Dollars.

iii) One of the best resources around is right here, USENET.  Posts to
comp.protocols.tcp-ip.ibmpc are very likely to yield good results.


4) Are there any similar packages I might want to look at?

There is one called CUTCP, which judging by what I have heard, sounds
comparable.  Also, NCSA has comparable software available.  Post to
comp.protocols.tcp-ip.ibmpc for more info.

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

This is starting to look like a FAQ.  If someone wants to start a FAQ,
you are free to use what I have written here.  I will be finishing
(hopefully) this project by the end of August and returning to school,
so I will not be able to make the commitment necessary to do it myself.

Enjoy!

--Mike

PS. Please feel to post any corrections/additions to this...it is more
of a spur of the moment effort than an edited masterpiece.


NOTE: This posting contains just about everything I know about WATTCP,
which is precisely why I posted it.  So, please DO NOT EMAIL ME WITH
QUESTIONS, but POST THEM INSTEAD.  If I know the answer, I will email
you.  Besides, there are many people much more knowledgeable than I who
will also see your post.


KEEP ON READING FOR INFORMATION ON HOW TO GET A PACKET DRIVER:

-- HOWTOGET.IT

		The Crynwr packet driver collection

Availability

The Crynwr packet driver collection is available on CD-ROM, by mail,
by FTP, by email, by UUCP and by modem.  The drivers are distributed
in three files: pktd11.zip, which contains most executables and
documentation, pktd11a.zip, which contains the first half of the
remaining files, and pktd11b.zip, which contains the second half of
the remaining files.

Mail:

Columbia University distributes packet drivers on PC diskette by
postal mail.  5.25-inch 360K and 3.5" 720K diskettes are available;
please specify size.  Two diskette sets are available, and two prices
are quoted for each; the first price is for the USA, Canada, and
Mexico; the second price is for shipment to all other countries.  All
prices are in US dollars.  Prepayment by check, MasterCard, or Visa
is accepted.  If your check is not drawn on a US bank, please add $35
check-cashing fee.

  1. Binaries and documentation:        $35  /  $40
  2. Source code:                       $60  /  $68

To order by credit card, please specify MasterCard or Visa, your card
number and expiration date, and sign and date your order.  For further
information, call +1 212 854-3703, or write to:

  Kermit Distribution, Dept PD
  Columbia University Academic Information Systems
  612 West 115th Street
  New York, NY  10025

or send e-mail to kermit@columbia.edu (Internet) or KERMIT@CUVMA
(BITNET/CREN/EARN).

FTP/email:

The packet driver collection has its own directory devoted to it in
the SimTel collection, msdos/pktdrvr.  The drivers are there, along
with a number of programs that use the packet drivers.

For security reasons the SimTel Software Repository is located on a
host that is not accessible by Internet users, however its files are
available by anonymous ftp from the primary mirror site OAK.Oakland.Edu
(141.210.10.117) located in Rochester, Michigan, and from the secondary
mirror sites:

   St. Louis, MO: wuarchive.wustl.edu (128.252.135.4)
   Corvallis, OR: archive.orst.edu (128.193.2.13)
Falls Church, VA: ftp.uu.net (192.48.96.9
       Australia: archie.au (139.130.4.6)
         England: src.doc.ic.ac.uk (146.169.2.1)
         Finland: ftp.funet.fi (128.214.6.100)
         Germany: ftp.uni-paderborn.de (131.234.2.32)
          Israel: ftp.technion.ac.il (132.68.1.10)
     Switzerland: ftp.switch.ch (130.59.1.40)
          Taiwan: NCTUCCCA.edu.tw (140.111.1.10)

SimTel files may obtained by e-mail from various ftp-mail servers
or through the BITNET/EARN file servers.  For details see file
/pub/msdos/filedocs/mailserv.inf.  Gopher users can access the
collection through Gopher.Oakland.Edu.  World Wide Web (WWW) and
Mosaic users can connect to the URL http://www.acs.oakland.edu to
access the files on OAK.Oakland.Edu.

Modem:

If you cannot access them via FTP or e-mail, most SimTel MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956.  DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP).  This is a subscription system
with an average hourly cost of 17 cents.  It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial.  New files
uploaded to SimTel are usually available on DDC within 24 hours.

CD-ROM:

Title:  Packet Driver, WinSock & TCP/IP CD-ROM (aka Packet Driver CD)
Price:  US$29.95/each

Brochures and order forms for the CD (paper and electronic versions)
will be available from:

Gopher: gopher.CDPublishing.com
FTP:    ftp.CDPublishing.com
E-mail: <info@CDPublishing.com>
FAX:    604-874-1431
Phone:  604-874-1430
        800-333-7565
Postal: CD Publishing Corporation
        4824 Fraser Street
        Vancouver, B.C.  V5V 4H4
        Canada

UUCP:

The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr.  Contact UUNET for more details:

UUNET Technologies, Inc.
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 204 8000 (voice)
+1 703 204 8001 (fax)
info@uunet.uu.net

UK UUCP:

Steve Kennedy's BBS is on +44 71 483 2454 (Telebit T2500 PEP/V32 ...)
                                                2455 (USR HST/DS+)

Files will be in /pub
there will be an anonymous uucp (nuucp) account.

System name is "marvin"

-- end of HOWTOGET.IT

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jul 1994 15:26:40 GMT
From:      jra@lawdept.daytonOH.ncr.com (John Ackermann)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q

In article <ke4dpx.22.0005B3C0@gregl.slip.iglou.com> ke4dpx@gregl.slip.iglou.com (Greg Law) writes:

>KA9Q is basically public domain software with commercial restrictions. You can 
>use it, modify it, and distribute it to your heart's content provided you 
>don't sell it. This may vary slightly with specific releases, but all are 
>based on the original public domain code.

The answer is a bit more complicated than this, though Greg's pretty close.  
The base KA9Q code was written by Phil Karn.  His copyright notice permits 
unlimited, free use of the code for amateur radio or education purposes.  Any 
other use -- whether the code is freely distributed or not -- requires 
negotiation of a license with Phil.

To complicate things further, there are literally dozens of folks who've done 
work on Phil's base code, and they have their own, sometimes inconsistent 
copyright statements.

But in any event, if you're planning to make any non-ham radio, 
non-educational use of KA9Q, you need to contact Phil for permission, as well 
as possibly contacting others.

John   AG9V
jra@lawdept.daytonOH.ncr.com

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jul 1994 17:38:15 GMT
From:      ANDY@[144.206.142.199] (Andy A. Savchenkov)
To:        comp.protocols.tcp-ip
Subject:   Wanted: VT1000 emulator for TCP/IP

Hi, wise people!

I have one little question concerning VAX/VMS/DECWindows.
I need to work under DECWindows using my PC as a terminal, but
I don't know how to emulate a VT1000 or greater terminal.

I have two VAX-es and PathWorks on one of them. DECWindows under
Pathworks works perfect, but it is installed only on one VAX.

So the question is : Does the VT1000 terminal emulator (working under
TCP/IP on DOS or/and Windows for Workgroups 3.11) exists?

Of course, I need a "public domain" software 'cause I haven't enough
money to buy it. If you can say me the ftp-server where something like
this emulator exists I would say you "Great Thanks!"

                         Bye.
+========================================================+
|   Andy A. Savchenkov             Moscow, Russia        |
|========================================================|
| Nuclear Fusion Institute  |   ANDY@[144.206.142.199]   |
| Russian Research Centre   |  k238@ivk-vax.ivk.kiae.su  |
|  "Kurchatov Institute"    |   YOU ARE ALWAYS WELCOME   |
|========================================================|
|     ...Take it easy, baby, take it as it comes...      |
+========================================================+

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 20:34:04 GMT
From:      mekatako@vela.acs.oakland.edu ( )
To:        comp.protocols.tcp-ip
Subject:   HELP: SunOs TCP/IP setup? how?

	I'm running SunOs 4.0.2 on a Sun 386i.  I need to know how I can
get the TCP/IP related stuff setup... I can get to the telnet prompt,
but it does not work right since I dint have the system configed for my
net.  Thanks for any help you can give...

Andrew


-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 20:42:52 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP update mechanism on unix hosts

In article <albert.774173072@netboss> albert@dn.itg.telecom.com.au (Albert Fu) writes:
>Should a host updates its ARP cache every time it receives
>an IP packet? 

Not every time it receives an IP packet, but every time it receives an ARP
packet.  But since an IP packet can't sent until an ARP packet is sent,
this should be equivalent (unless the router has a preconfigured ARP
cache).  Here's what RFC 826 (the ARP specification) says:

    Notice that the <protocol type, sender protocol address, sender
    hardware address> triplet is merged into the table before the
    opcode is looked at.  This is on the assumption that communcation
    is bidirectional; if A has some reason to talk to B, then B will
    probably have some reason to talk to A.  Notice also that if an
    entry already exists for the <protocol type, sender protocol
    address> pair, then the new hardware address supersedes the old
    one.  Related Issues gives some motivation for this.

>	       Also, is there a mechanism for the Unix host to
>refresh its ARP cache periodically, eg every 10 minutes?

This probably depends on the Unix version.  I don't think there's a
built-in timeout in BSD Unix.  You could have a cron job that executes a
script that deletes all the entries in the ARP cache.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 21:09:44 +0100
From:      dehartog@kwetal.comcons.nl (Hans de Hartog)
To:        comp.protocols.tcp-ip
Subject:   Routing localnet <--> SLIP-provider?

My setup is as follows:
a local lan (ethernet, network-address 222.222.222.0),
one fat linux-box and a few dos-pc's (using soss, lpt, telnet,
bootp and ftp). This worked for months and I want to keep it that way.
Now the linux-box can SLIP to Internet with (static) ip-address
193.78.38.226. The SLIP-provider is 193.78.33.42 (which is supposed
to be gateway and nameserver for me). This also works fine (telnet,
ftp, X-mosaic), but only for the linux-box that made the SLIP-
connection (with dip).
However (and that's the problem), when the SLIP-connection exists,
I want the dos-pc's also be able to acces the Internet (at least
telnet). I do not have routed running yet (is it necessary and if
yes, what to put in /etc/gatewaysi?), but when I try to telnet from
a dos-pc to the outside world, I can see that something is being
sent out via the modem... The answer however is always "hostname
lookup failure", "network unreachable" or simply nothing (hang).

# /etc/hosts:
127.0.0.1	localhost
193.78.38.226	kwetal.hacktic.nl
222.222.222.225	kwetal.comcons.nl	kwetal	linux
222.222.222.226	bommel.comcons.nl	bommel
193.78.33.42	xs4all.hacktic.nl	xs4all
193.78.33.33	news.hacktic.nl		news

# /etc/networks				# /etc/resolv.conf
default		0.0.0.0			domain	comcons.nl
loopback	127.0.0.0		nameserver	193.78.33.42
homelan		222.222.222.0		nameserver	193.78.240.1
hacktic		193.78.33.0

When the SLIP-connection is up, route gives:
Kernel routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xs4all.hacktic. *               255.255.255.255 UH    0      0        0 sl0
222.222.222.0   *               255.255.255.0   U     0      0    62231 eth0
127.0.0.0       *               255.0.0.0       U     0      0    48227 lo
default         xs4all.hacktic. *               UG    0      0        0 sl0

Thank you for reading, thank you double for helping me.
-- 
 _____________________________________________________________________________
 Hans de Hartog, dehartog@comcons.nl, Voice: +31 348033100, Fax: +31 348033181
 Committed Consultancy BV, Korenmolenlaan 1b, 3447 GG Woerden, The Netherlands 
 Home: dehartog@kwetal.comcons.nl, Voice/Data: +31 838038560, CIS: 100121,3301

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 00:20:03 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.misc,comp.protocols.tcp-ip,gsfc.network
Subject:   Re: is gosip OFFICIALLY dead?

In article <mmcmullen-1307942324000001@taygeta.gsfc.nasa.gov> mmcmullen@gsfcmail.nasa.gov (steve johnson) writes:
>got an ongoing and rather important debate going with a coworker.  how
>true is the following:
>
>1) gosip is officially no longer mandated by the federal government for
>use by civil servants and contractors (specifically NASA).

I dunno.  I do know that GOSIP did not ever really mandate "use" of
OSI.  It tried (with only mixed success) to mandate "purchase" of OSI.
The DoD does NOT require purchase of OSI in practice and has not
required that for a long time.

>2) you can still use it if you want, but there will be little or no
>support for it in the future, so you might as well switch to tcp or
>whatever.

Smart people will move towards whatever networking technology solves
their problems at the lowest cost.  This will most usually be a
mainstream commercially viable protocol stack (e.g. SPX/IPX, TCP/IP).

Ran
atkinson@itd.nrl.navy.mil
(speaking strictly as a private citizen)


-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1994 00:11:52 +0100
From:      dehartog@kwetal.comcons.nl (Hans de Hartog)
To:        comp.protocols.tcp-ip
Subject:   Re: "easy" bootp question

Ross Hayden (ross@ndlc.occ.uky.edu) wrote:
| Hi all!
 
| I have been struggling to get bootp working on several unix system here on
| campus, with little luck.
 
| I have several DOS pc's running NCSA telnet, along with the packet drivers
| needed to run it on top of my netware drivers (ie odipkt.com).  On my unix
| systems I've installed various versions of CMU's bootp package.  The
| problem seems to be that replies from the server are never reaching the
| workstations.  The bootp server starts on queue, and tcpdump also
| indicates this and shows the reply being sent.  The pc, however, just sits
| and continually resends requests as if never having received a reply.
 
| If I hard code an IP address into the config file for NCSA telnet,
| everything works ok.  Also, I can't get rarp to work either.  So I'm not
| really sure if I need to examine my network setup, or if there's a problem
| with NCSA telnet.  I've examined my network setup, checking out subnet
| masks and broadcast addresses.
 
| Any ideas on what to check here?  I'm stumped.
 
| Thanks for any help,
| Ross
| --
| Ross Hayden, Systems Programmer                   ross@ndlc.occ.uky.edu
| The National Distance Learning Center

I just helped somebody else with the same problem. It seems that
NCSA-stuff V2.3.07 doesn't groc the bootpd answer. I'm running
V2.3.03 (aka V2.3b) and I have no problems.
-- 
 _____________________________________________________________________________
 Hans de Hartog, dehartog@comcons.nl, Voice: +31 348033100, Fax: +31 348033181
 Committed Consultancy BV, Korenmolenlaan 1b, 3447 GG Woerden, The Netherlands 
 Home: dehartog@kwetal.comcons.nl, Voice/Data: +31 838038560, CIS: 100121,3301

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1994 02:07:10 GMT
From:      mathias@solomon.technet.sg (Mathias Koerber)
To:        comp.protocols.tcp-ip,comp.os.linux.help,comp.dcom.lans.ethernet
Subject:   tcpdump analysis prg?

I just installed tcpdump-3.0 from the binaries at sunsite on my linux box.

Now I wonder whether someone has already written some tools to do
analysis and statistics from the tcpdump output.
Something that can run parallel in realtime would be nice,
but I'd also be  happy with something that reads from a filedump.

cheers

--
Mathias Koerber                                       Tel: +65 / 778 00 66 x 29
SW International Systems Pte Ltd                           Fax: +65 / 777 94 01
14 Science Park Drive #04-01                 e-mail: Mathias.Koerber@swi.com.sg
S'pore 0511   <A HREF=http://www.swi.com.sg/public/personal/mathias.html>MK</A>
May your Tongue stick to the Roof of your Mouth 
with the Force of a Thousand Caramels	- ??

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 08:43:53
From:      padgett@141.240.2.145 (Padgett 0sirius)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: VT1000 emulator for TCP/IP

In article <25@[144.206.142.199]> ANDY@[144.206.142.199] (Andy A. Savchenkov) writes:
>I need to work under DECWindows using my PC as a terminal, but
>I don't know how to emulate a VT1000 or greater terminal.

Well the current MS-DOS Kermit (on oak.oakland.edu but I forget where) can 
be used to emulate a VT-100 et subs or I use the NCSA Telnet. Both of
these can be used with a TCP/IP packet driver though the Kermit setup
is a bit strange.

You may also need the GOLD.COM TSR to be able to use the NumLock key as PF-1
(think it is included with Kermit). Both seem to be Freeware.

			A. Padgett Peterson, P.E.
                        Cybernetic Psychophysicist
			   We also walk dogs
	 	       PGP 2.4 Public Key Available

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 12:17:40 -0500
From:      king@acpub.duke.edu (King Rhoton)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   routing on SunOS (with dp2.3) for remote PPP users?

> I'm having trouble setting up cslip-2.7 on SunOS 4.1.3.  I can get
> the line to answer and go into SLIP mode, and my remote station 
> (running Trumpet Winsock) can use TCP/IP to the host directly, but
> they can't see any hosts outside the local domain.  FTP, Mosaic,
> etc., just time out when they try to connect to a distant host.
> 
> I think its something to do with routing, but I'm not sure.  How
> should routing be set up on the host to which SLIP users dial in?
> 
> Routing tables
> Destination          Gateway              Flags    Refcnt Use        Interface
> localhost            localhost            UH       4      17440      lo0
> 199.123.192.10       parts                UH       1      33         sl0
> default              199.123.192.1        UG       3      6342       le0
> 199.123.192.0        parts                U        2      308        le0
> 
> So, .10 can talk to parts and TCP/IP services on parts, and parts
> can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc., 
> but .10 can't talk to ftp.uu.net, etc.  

I'm having the exact same problem, only with PPP connections instead of
slip.  I'm entirely baffled.  I've set up an arp entry for my remote
machine, and from the remote machine ping requests to non-dialup-hosts do
go through the PPP link (I see the tx led flicker), but I never get
anything back.  I have full access to the dialup host, though.  I've tried
both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and
they behave the same.  It's got to be something in the Sun's
configuration, but I'm out of ideas.  SunOS 4.1.3 and dp2.3pl2.

Anybody?
Thanks,

King Rhoton                                       king@acpub.duke.edu

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 05:37:15 GMT
From:      davidk@csn.org (David Kirkpatrick)
To:        comp.protocols.tcp-ip
Subject:   TCP error message on SCO UNIX

Hi,

I'm porting some DOS/Windows software to use Winsock to communicate with
a daemon running on a SCO UNIX system.  The software is to the point where
it is running, and most communications seem to be OK.  Sometimes though,
when either reading or writing on a socket from the DOS side, I get a
console message on the SCO box that says:

	NOTICE: tcp: sum xxxxx yyyyy

xxxxx & yyyyy are hex numbers.  I can't find any specific error information
in the SCO documentation, but I guess this is coming from the tcp driver,
in the "sum" routine (that's all I can find out.)  Does anyone know what
these hex numbers mean?  BTW, the software that causes the message seems
to work correctly, and all the operations have apparently completed.  
Another oddity, is that if I use a debugger on the DOS side to see exactly
which call causes the error, the message never occurs!  This leads me to
think that is has something to do with timing or something.  Thus, I'm not
sure which socket call on the DOS client side causes the message.  It occurs
consistently if the section of code runs without a breakpoint....

Also, I don't have source code to the server side daemon, so I don't know
what it's doing when the message occurs.  All I know is that the client
side is in a loop doing sowrite() and soread().

Thanks,


--
------------------------
-- David Kirkpatrick  --
-- Southwest Software --
-- davidk@csn.org     --

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 07:02:08 GMT
From:      bos@surfnet.nl (Erik-Jan Bos)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing localnet <--> SLIP-provider?

Hans de Hartog (dehartog@kwetal.comcons.nl) wrote:
: My setup is as follows:
: a local lan (ethernet, network-address 222.222.222.0),
: one fat linux-box and a few dos-pc's (using soss, lpt, telnet,
: bootp and ftp). This worked for months and I want to keep it that way.
: Now the linux-box can SLIP to Internet with (static) ip-address
: 193.78.38.226. The SLIP-provider is 193.78.33.42 (which is supposed
: to be gateway and nameserver for me). This also works fine (telnet,
: ftp, X-mosaic), but only for the linux-box that made the SLIP-
: connection (with dip).
: However (and that's the problem), when the SLIP-connection exists,
: I want the dos-pc's also be able to acces the Internet (at least
: telnet). I do not have routed running yet (is it necessary and if
: yes, what to put in /etc/gatewaysi?), but when I try to telnet from
: a dos-pc to the outside world, I can see that something is being
: sent out via the modem... The answer however is always "hostname
: lookup failure", "network unreachable" or simply nothing (hang).

Packets from the DOS PCs to the Internet make it okay, but since you are
using a fake IP network number (222.222.222.0) which is not routed on the
Internet packets do not know how to go back.

What you need to do is:
- obtain registered IP address space from your provider,
- renumber your hosts to this address space,
- ask your provider to set up a static route for this address space to
  your Linox box (which is acting as a router, you do not need routed,
  the Linux kernel is perfectly capable of routing packets).

--
Erik-Jan.

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 07:38:39 GMT
From:      banker1@shakti.ncst.ernet.in (Citicorp Overseas Software Limited. Team FINWARE.)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP implementation benchmarking ?


Hi,
    I'm interested in knowing if there are any benchmark figures for
Unix IPC mechanisms ( pipes, FIFOs, message queues, unix domain sockets)
available on the Internet. I would also like to know if the C source code
for any benchmarking programs is available. I'm also interested in statistics
and C code for benchmarking TCP/UDP implementations.

Thanks,
Shailesh
-- 

(FINWARE Group, Citicorp Software)    
Internet : banker1@shakti.ncst.ernet.in


-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 08:03:20 GMT
From:      prasert@vast.unsw.edu.au (Prasert Kanthamanon)
To:        comp.protocols.tcp-ip
Subject:   A packet filter software needed?

Hi netters,

Where can I find any packet filter software running on both SUN 4.1.X and
solaris 2.2?  I would like to setup a Sun SPARC working like a gateway that
can filter IP packets based on IP address/network/subnet combinations and
socket numbers.

Thanks in advance,
prasert.

prasert@vast.unsw.edu.au


-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 08:48:34 +0000
From:      neil@palnu.demon.co.uk (Neil Motteram)
To:        comp.protocols.tcp-ip,demon.local,comp.protocols.tcp-ip.ibmpc
Subject:   TCP-IP over Ethernet to Omron PLC

Help?

We have a programmable logic controller, that we can connect to an Ethernet
network. The network must be hardware wise IEEE802.3. Software wise we 
are using the Ethernet-2 Standard. The PLC Ethernet unit uses TCP/IP. I would
like to coneect a PC to this unit. Therefore I need a TCP/IP driver. I in the
first stage only would like to test the connection of the network, without
writing programs. A PING would be enough. I am interested in commercial 
solutions or anything that is available in the net. As a second stage I am 
looking for programming libraries/dll(preferably MSC 6/7 or Visual Basic).

I am posting this for a non-networked collegue. I shall scan the newsgroups
but if anyone would like to reach him directly then please e-mail
edwin.holtkamp@ibmmail.ibmx400.nl

Thanks very much in advance.

-- 
Neil Motteram - Omron Electronics Europe BV - Hoofddorp, Netherlands
Internet: neil@palnu.demon.co.uk             Compu$lime: 100115,1020
IBM Mail: NLOMRNM0 IBMMAIL                     Voice: +31 2503 81332
     ** If you use Synon/2, and you're on the net, e-mail me! **

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1994 17:44:09 -0500
From:      nilesh@jaws.wustl.edu (Nilesh Gohel)
To:        comp.protocols.tcp-ip
Subject:   Wanted: TCP Finite State Machine implementation for net snooper

We are designing a network snooping tool for client-server
communications that use a standard protocol which sits on top of 
TCP/IP in the protocol stack. 

The lower layers of software are already in place that generate
the raw TCP packet stream between the two nodes involved in a 
communication. The next layer to be developed would take the
raw TCP packet stream and output the "clean" data stream. Many 
of the functionalities of the TCP layer (input side) are 
required such as checking checksums, resequencing packets,
monitoring handshaking, removal of duplicate packets, striping
the headers, etc.

Is there any public domain software which performs the task described
above of "cleaning up" a TCP packet stream ? Public domain UNIX 
implementations may be useful, however source code that is less
elaborate and more geared to a "snooper" type application would be
most desirable. 

Thanks.

Nilesh R. Gohel

Research Assistant

Electronic Radiology Laboratory         Tel. (314) 362-6965
Mallinckrodt Institute of Radiology     Fax. (314) 362-6971
510 S. Kingshighway Blvd.
St. Louis, MO 63110, U.S.A.             E-mail: nilesh@wuerl.wustl.edu

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 94 14:48:32
From:      dave@denali.ccs.neu.edu (David Philip Kormann)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: VT1000 emulator for TCP/IP

In article <padgett.127.0008BB7B@141.240.2.145> padgett@141.240.2.145 (Padgett 0sirius) writes:
> In article <25@[144.206.142.199]> ANDY@[144.206.142.199] (Andy A. Savchenkov) writes:
> >I need to work under DECWindows using my PC as a terminal, but
> >I don't know how to emulate a VT1000 or greater terminal.
 [...]
> Well the current MS-DOS Kermit (on oak.oakland.edu but I forget where) can 
> be used to emulate a VT-100 et subs or I use the NCSA Telnet. Both of
> these can be used with a TCP/IP packet driver though the Kermit setup
> is a bit strange.
[...]

ummmm, no.
the original poster wanted a _vt1000_ emulator.  the vt1000 is the DEC X
terminal, strangely enough.
what he _really_ wants is X server software for MS/DOS.

for the original poster:
the VT1000 you're using is significantly more than a termninal, and requires a
pretty complex set of software to emulate.  DECwindows is DEC's implementation
of the X window system, a cross-platform GUI.  the software running on the
VT1000 (and other machines that provide displays for X-based programs) is
called an X server.
there are, to the best of my knowlege, no freely-available X servers for
MS/DOS.  however, there are a number of commercial ones.  check out
Reflection/X (the vendor name escapes me at the moment) or Desqview/X.  both
of these have the required DEC cruft to do DECwindows, as far as i know.
you might want to check out comp.windows.x for more information on this.
				dk
			STILL giggling that
			DEC called its X terminals
			"VT1000"s.

			

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1994 10:43:20 +0200
From:      Frank Hoffmann <fh.muc@sni.de>
To:        comp.protocols.tcp-ip
Subject:   Re: TCP error message on SCO UNIX

davidk@csn.org (David Kirkpatrick) writes:

>when either reading or writing on a socket from the DOS side, I get a
>console message on the SCO box that says:
 
>	NOTICE: tcp: sum xxxxx yyyyy

SCO says:
[CUT]

	  This is a warning message generated by the TCP driver in
	  the kernel. 

	  It is generated when the machine receives an Ethernet packet from
	  another machine which has an error in the TCP part of the packet.

	  The 'src' is a hexidecimal representation of the IP address of the
	  remote machine and 'sum' is the checksum of the packet.

	  To convert the hexidecimal value to an IP address use bc(C).
          	At your prompt enter: 
		bc 
	   	ibase=16        < enter this string for conversion
		C0		< enter first hexidecimal octet
		192		< you get
		09		< enter second hexidecimal octet
		194		< you get
	 	C2 		< enter third hexidecimal octet
		194		< you get
		E9		< enter forth hexidecimal octet
		233		< you get 

	        For example: src C0,09,C2,E9 = 192.9.194.233

	  The TCP driver places a header on the data to be sent and then 
	  checksums the packet and places the checksum in the header. The 
	  packet is then passed to the IP layer which agains adds a header 
	  including a checksum (the IP checksum is only a checksum of the 
	  IP header). The packet then goes to the network adapter driver 
	  for sending across the network.

	  On the receiving end, the headers are removed and the checksums
	  checked.  This message appears if the checksum in the TCP header
	  does not match the checksum generated on the packet received.

	  This is a non-fatal error.  The TCP layer ignores the packet with
	  the checksum error and then receives 'out-of-sequence' data, causing
	  it to request a re-send of the packet. A few of these errors a day
	  on a busy network is to be expected.

	  This has been seen on fast machines (486 and 33Mhz 386) with the
	  3COM 503 card and SCO TCP/IP Release 1.1.1, however, persistent,
	  nearly constant error messages are most often caused by bad 
	  cabling/termination, cable ringing, or a bad card (or simply 
	  an incompatable one) on the network. You may also see sporadic
	  occurances when running via SLIP or PPP due to line noise.
[CUT]

Hope this helps

frank

	     How can you tell a marketing guy is lying? - His lips are moving.
 ------------------------------------------------------------------------------
    Frank Hoffmann;Siemens Nixdorf Info-Systems;BU BA NM 14;Rosenh.Str 116\
    81669 Munich; Germany; Email= US:fh.muc@sni-usa.com; !US:fh.muc@sni.de\
    UUCP: [not available];  Voice: +49-894-144-7615;  Fax: +49-894-144-7746
 ------------------------------------------------------------------------------
*$*^$%&N0 CARRIER

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1994 21:11:42 -0400
From:      debiso@pipeline.com (Joe Debiso)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem: our net vs Internet

I have the same problem... Please let me know what the answer 
is also!
Thanx!


twallace@mason1.gmu.edu (Todd A Wallace) wrote:


>
>We are supposed to join the wonderful world of Internet 
>connectivity. To  that end, we have a NetHopper router 
>and a new upgraded account with  Netcom.
>
>However, we have a problem.
>
>The IP addresses are totally different from the IP 
>address we have been  assigned from Netcom. 
>
>QUESTION: Is there a way to resolve this problem 
>without having to
>change the IP addresses on every single one of our PCs 
>and UNIX boxes?
>
>Thanks for any help/hints.
>Todd Wallace

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 19:41:48
From:      CAMARA@novell.wd.cubic.com (Raland Camara)
To:        comp.protocols.tcp-ip
Subject:   connect() and ECONNREFUSED

When issueing the connect() system call, what conditions may exist to generate 
the error, ECONNREFUSED "The attempt to connect was forcefully refused"?  I 
do not have access to the source code for the connect() system call, so any 
help will be greatly appreciated.  

The situation that I am currently debugging exists between a server program 
residing on a host running hpux and a client program running on an IBM pc 
running UnixWare.  When client and server programs communicate through their 
perspective ethernet interfaces, everything works fine.  When an attempt is 
made to connect to a similarly configured pc through a SLIP router the above 
error is encountered.  (The hpux system is connected to the ethernet.  A 
netblazer SLIP router is also connected to the ethernet.  It is also connected 
to the serial port of the pc.  Both the netblazer and the pc are configured to 
talk SLIP.)  Both the hpux system and the pc are able to communicate through 
this SLIP router via ping, telnet, ftp, etc.  However, the same client/server 
programs which ran previously through their ethernet connections do not.
Any suggestions?

Thanks in advance,

Raland

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1994 15:05:28 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Security/Firewall FAQ?

>I'm currently in the process of researching the use of a firewall machine
>to allow our administrative network Internet access, but allow them to
>stay "secure" from people hacking in (ie. students, etc.).  I read awhile
>back in some document that there was a Firewall FAQ, but I can't find
>the document anymore, and have been unable to turn it up in my travels on
>the net.  Could someone drop me a line with information on this beastie?

	FAQs are archived on rtfm.mit.edu

	The firewall FAQ and other firewalls related stuff is archived
on ftp.tis.com: pub/firewalls or http://www.tis.com

mjr.

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1994 17:21:14 GMT
From:      march@indirect.com (Michael March)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q

: In article <ke4dpx.22.0005B3C0@gregl.slip.iglou.com> ke4dpx@gregl.slip.iglou.com (Greg Law) writes:
: The answer is a bit more complicated than this, though Greg's pretty close.  
: The base KA9Q code was written by Phil Karn.  His copyright notice permits 
: unlimited, free use of the code for amateur radio or education purposes.  Any 
: other use -- whether the code is freely distributed or not -- requires 
: negotiation of a license with Phil.
 
: To complicate things further, there are literally dozens of folks who've done 
: work on Phil's base code, and they have their own, sometimes inconsistent 
: copyright statements.
 
: But in any event, if you're planning to make any non-ham radio, 
: non-educational use of KA9Q, you need to contact Phil for permission, as well 
: as possibly contacting others.


 I want to get a hold of Phil to do JUST that that.. I wrote to his address at 
 qualcomm.com and I have yet to get any response.  Does he have a new address?

<march>

--
Michael F. March-----------KB7EXY (yep...a tech)---------march@indirect.com
Internet Direct, Inc., 1366 E. Thomas Rd, Suite 210, Phoenix, AZ 85014-5738
Arizona's Internet Connection------mail info@indirect.com-----(602)274-0100
I am not only the president of Internet Direct, Inc.----I am also a client. 


-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 17:32:58 GMT
From:      bbosen@netcom.com (Bob Bosen)
To:        comp.protocols.tcp-ip
Subject:   Re: Security/Firewall FAQ?

Richard P. Kernin (rpk@niagara.edu) wrote:
: Hello,
 
: I'm currently in the process of researching the use of a firewall machine
: to allow our administrative network Internet access, but allow them to
: stay "secure" from people hacking in (ie. students, etc.).  I read awhile
: back in some document that there was a Firewall FAQ, but I can't find
: the document anymore, and have been unable to turn it up in my travels on
: the net.  Could someone drop me a line with information on this beastie?
 
: Thanks much!
 
: Take care,
 
: -Rich
 
: ---------------------------------------------------------------------------
: Richard P. Kernin
: Niagara University - Administrative Computer Center
 
: Internet: rpk@niagara.edu	or	visnurpk@ubvms.cc.buffalo.edu

I hope somebody else will point you at an appropriate FAQ. In addition,
you might like to take a look at the animated tutorial software that
my company has made available for your VGA-equipped IBM PC. This
stuff teaches many important issues regarding firewalls, and it's
quite entertaining to watch. It's good for motivating your management
team on the importance and functionality of firewalls. It stresses
the kinds of firewalls that can positively identify the _people_ that
request access to your networks, as opposed to just filtering on
protocols. To see it, use anonymous ftp to go to:

ftp.netcom.com

Then cd to:

/pub/bbosen/Enigma/Tutorials/VGA/Grasp/Firewall
and
/pub/bbosen/Enigma/Tutorials/VGA/Grasp/Cisco

Get all of the files in each directory (there are two separate
tutorials in those two separate directories).

Pay special attention to the "read.me" files to get oriented.

Regards,


-- 

Bob Bosen
Enigma Logic Inc.
2151 Salvio St. #301
Concord, CA   94520
USA

Tel: +1 510 827-5707
Internet: bbosen@netcom.com
**************************************************************************
* "It wasn't me!!! Somebody must have captured my username/password!!!"  *
**************************************************************************

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 17:46:15 GMT
From:      bruceo@loki.isc-br.com (Bruce Oscarson)
To:        comp.protocols.tcp-ip
Subject:   How to use setsockopt with TLI?

I am working on a server that supports multiple protocols 
(a proprietary and tcp/ip). The server was written using the TLI 
interface and runs on 5.4 Unix. If the server restarts while tcp/ip 
clients are connected, the port is placed in a FIN_WAIT2 state.  
This state lasts for about 13 minutes.  During this time, the 
server cannot re-connect to the port.

I attempted to set tcp/ip based connections to SO_REUSEADDR to 
ignore the FIN_WAIT2 state, but the fd returned from the t_open is 
not a valid socket fd.

Does anyone have a suggestion as to how I can get the socket 
fd?  Any suggestions as to how I might solve this 'delay' problem
without using SO_REUSEADDR or convert all of my clients to 
async IO. (With async IO the client would detect the close on from 
the server and initiate its own close.  The TIME_WAIT delay is 
only about 1 minute.)

I would appreciate any suggestions.  Thanks.

bruceo@mail.isc-br.com



--

Bruce Oscarson          | bruceo@mail.spk.olivetti.com
Olivetti North America  |
N7RWO                   | ma-bell  (509) 927-5437

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 20:31:28 GMT
From:      p_quinn@ECE.Concordia.CA (Paul Quinn)
To:        comp.unix.questions,comp.unix.pc-clone.32bit,comp.protocols.ibmpc,comp.protocols.tcp-ip
Subject:   telnetd: not enough ports.



I recently had to use TCP/IP on a DOS box to connect to an Altos UNIX box.

I used LAN Workplace for DOS to get TCP/IP.

The network connection appears to be fine.  Occationnaly the UNIX system will 
not allow Telnet sessions and generate the following message (or something very
close)

telnetd: no network ports availible.


Any indeas?



Thanks in advance
--
________
Paul Quinn
p_quinn@ece.concordia.ca
Computer Science: Systems Architecture
Concordia University
Montreal, QC, CANADA
--------

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 20:47:45 GMT
From:      cavenewt@netcom.com (...In Bed)
To:        comp.protocols.tcp-ip
Subject:   connection wierdness


I've been using   gethostbyname(localhost), where localhost is determined by
gethostname(localhost,255) to get the sockadd_in structure infromation for
a server I'm making.  When I run the server and telnet machinename portnumber
then it responds.  If I  telnet localhost (as in 127.0.0.1) portnumber
I get connection refused.   Is this normal?  How do I make my server
accept connections to all local IP addresses (interfaces, whatever).

(This is on a Linux machine running net 3 , for what it's worth.)


-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 21:25:11 GMT
From:      curt@maroon.tc.umn.edu (Curtis W Griesel)
To:        comp.protocols.tcp-ip,comp.sys.apple2
Subject:   SLIP for apple 2?

Does anyone know if SLIP software exists for an Apple 2e?  And, I suppose
the next logical question would be, does anyone know of any Internet tools
(telnet, ftp, gopher, etc) that would work with SLIP on an Apple 2e?

Thanks for any info or pointers.
Curt
--
Curtis W. Griesel
University of Minnesota - Computer and Information Services
curt@boombox.micro.umn.edu

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 00:21:45 GMT
From:      leng@cougar.vut.edu.au (Leng Kaing)
To:        comp.protocols.tcp-ip
Subject:   Help: key mapping


Can someone please help me out. I need to map the vt100 keyboard for
MicroFocus cobol running on UNIX Sun-OS 5.3. This situations is as such:

M-Cobol needs its own set of key sequences. Each function must be
preceded by a "/" (forward slash) and followed by another keystroke.
For example, F6 is "/6". The manual that I have access to 
(PC/TCP Network Software v2.3 - DOS/windows) gives me 2 options: 

	1. Enclose the remapping sequence in double quotes. So if I do
	the following, it should work:
	
			0,0x3b,"/6" 

	This causes an error. So may remap file is ignored. 


	2. Download the function keys from the remote host. So I have
	create a file with the following:

			^[P1;1|17/2F36^[\

	(where ^[ is the escape key captured in literal mode.) Then I
	cat the file. But nothing happens. What I am doing wrong?

In summary: can someone please suggest ways of mapping a function
to a set of key sequences, not preceded by the escape character.

Thanks in great anticipation.

Leng.
Victoria University of Technology.
Footscray Campus.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 01:10:24 GMT
From:      futuretracs@delphi.com (David J. King)
To:        comp.protocols.tcp-ip
Subject:   AD- All you need to know!

What's it worth to you to become an expert in Open Systems, 
LANS, Programming, or UNIX?

        * Your job?
        * Your promotion
        * Your company?

Here's what everyone should really know about Unix, Lans, Programming,
and Open Systems.  If topics such as Portability, Interoperability, and
Integration are subjects of discussion at your company, then we can
help.

FutureTracs is the definitive source for advanced information systems
video-based courseware.  We offer material developed by independant
industry experts.

These courses, previously unabailable without attending costly and
time consuming off-ste meetings, can educate you on the advantages and
problems of Lans, Unix, Open Systems, Programming, and Enterprise
Networking at your convenience either at the office or at home.

Some courses that are available are:
        Open System Library:
                * Open Systems for Managers
                * Open Systems for Techincal Staff
                * Client/Server, Distributed Databases and Networks
                * Introduction to the OSI Reference Model
                * Introduction to Data Communications
        Unix Library:
                * Fundamentals of the Unix System
                * Unix System Administration v3.2
                * Fundamentals of Unix System V v4.0
                * Unix System V v4.0 Internals
                * The Shell Command Language for Programmers
                * Korn Shell Command and Programming Language
                * Security for the Unix System
        "C" Language Library:
                * C Language for Programmers
                * C Language for Programmers: The ANSI Standard
                * Using C++
        LAN Library:
                * Introduction to Data Communication
                * Local Area Networks (Technical Staff)
                * Novell 3.11 Systems Administration

We also have courses covering Wordprocessing, Spreadsheats, Databases
and much more.  So if you don't see what you are looking for, then feel
free to email us.  Demo tapes are available for most courses.  
  Get an edge up on your competition!
  For more info email: Futuretracs@delphi.com


               


-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 08:07:07 -0400
From:      mascari@cis.ohio-state.edu (michael v mascari)
To:        comp.protocols.tcp-ip
Subject:   lpr client

	I am attempting to write an lpr client which would redirect 
printing on an Amiga 4000 to an RS/6000 over a SLIP connection.

	I do the following:
		1) getservbyname() to get information regarding "printer"
			services
		2) gethostbyname() to get host info
		3) socket() to allocate/open a socket
		4) connect() to establish the connection w/ lpqd
	I then send the print server a binary 2 followed by the name
	of the printer "lp", followed by a newline.

	I am supposed to receive an acknowledgement of a binary 0
	back as an okay.  Instead, I get back the string:

	ill-formed FROM address

	Any clues?

	Thanks for any info
		
	Mike Mascari (mascari@cis.ohio-state.edu)


-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 13:16:34 -0700
From:      jbarnes@crl.com (John Barnes)
To:        comp.protocols.tcp-ip
Subject:   How to have two processes listen on same port?

  Hi,

  I am writing a program which intercepts SNMP trap messages and
  processes them.  The problem is that the system I am intercepting
  the messages is also running a NMS.  I need to intercept the
  messages and then pass them onto the NMS.  I know some NMS's offer
  an API but we need this program to work with any NMS.  

  What I plan on doing is changing in /etc/services the port
  snmp-trap from 162 to some unused port.  This should cause the
  NMS to read from the wrong port.  I then will have my program listen
  on port 162 and then send the trap message on to the port I changed
  snmp-trap to.  

  The problem is how do I make the header information say that the
  packet came from the real destination instead of the local system?

  Please reply to jbarnes@crl.com.

  Thanks,

  Jym Barnes 


-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 01:49:57 GMT
From:      breyer@pcsi.com (Larry Breyer)
To:        comp.protocols.tcp-ip
Subject:   Dynamic Host Configuration Protocol

Is anyone working on DHCP?  I have an applicaton employing SUN workstations as servers
to a large number of portable PCs using CDPD wireless communications.  I'm looking for
a developer in need of Beta sites.

thank you

           +--------------------------------------------------+
           | Larry Breyer (breyer@pcsi.com) 619.535.9500.1873 |
           | Pacific Comm Sciences, Inc.    FAX: 619.535.9235 |
           | 10075 Barnes Canyon Road, San Diego, CA 92121    |
           +--------------------------------------------------+





-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jul 1994 02:28:11 GMT
From:      alagu@apple.com (Alagu Periyannan)
To:        comp.protocols.tcp-ip
Subject:   Public domain FTP code using TLI/XTI ?

Hi,

Does anyone know of any public domain code for TCP/IP
based applications that use the TLI/XTI interface rather
than the BSD sockets interface ?

In particular I am interested in obtaining source code for
an FTP application. (other popular internet applications
such as Telnet, gopher, www, etc. will also be useful.)

Any pointers will be appreciated.

Thanks.

-------------------------------------------------------------------------
Alagu Periyannan               alagu@apple.com

Advanced Technology Group
Apple Computer, Inc.

Disclaimer: My opinions are my own, not Apple's ...

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 03:21:19 GMT
From:      jtravis@herbie.unl.edu (Drizzt)
To:        comp.protocols.tcp-ip
Subject:   TCPIP Shareware for DOS

I am new to this newsgroup so no flames please.. I am looking for some
good shareware TCP-IP packages for DOS (similar to Winsock for 
Windoze) - Any TCP-IP packages would be helpful, but preferred for 
DOS.. And only shareware - please mail me (jtravis@herbie.unl.edu)

     				Thank ewe..


-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 04:48:24 GMT
From:      bfriesen@iphase.com (Bob Friesenhahn)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem: our net vs Internet

: >We are supposed to join the wonderful world of Internet 
: >connectivity. To  that end, we have a NetHopper router 
: >and a new upgraded account with  Netcom.
: >
: >However, we have a problem.
: >
: >The IP addresses are totally different from the IP 
: >address we have been  assigned from Netcom. 
: >
: >QUESTION: Is there a way to resolve this problem 
: >without having to
: >change the IP addresses on every single one of our PCs 
: >and UNIX boxes?

This is solely a routing problem.  Your network must be an officially
assigned subnet.  Also, you should obtain a domain name associated with
your subnet.  Entries are then placed in the Internet DNS system which
advertise the route to your subnet via Netcom.  Netcom should be able
to handle this for you.

In order to make it out of your subnet to the Internet, you will need
to configure your hosts such that they know to route through your
gateway for addresses outside of the local net.  A default route can
work for this.

Bob
--- 
Bob Friesenhahn, Interphase
bfriesen@iphase.com

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 10:36:45 GMT
From:      kohlhage@quantum.de (juergen kohlhage)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.programmer.networks,comp.sys.ibm.pc.hardware.misc,comp.os.os2.networking
Subject:   Re: WTB: Info on Schneider & Koch ethernet cards

reinken@tu-harburg.d400.de wrote:
: In <CsA1CD.M3v@aplcenmp.apl.jhu.edu>, salman@aplcenmp.apl.jhu.edu (Ashfaq salman (703) 516-7616) writes:
: >Hello,
: > 
: >I badly need "any info" on the following cards:
: > 
: >They are make by a German company Schneider & Koch and cards are 16-bit
: >ethernet adapters. The software tries to identify them as SK-Junior
: >boards.
: > 
: >I am particularly interested in getting Novell, Windows, etc. drivers for it.
: >I only have netbios software for it. I don't have any other documentation
: >on it. Any information about its compatibility or the company will be greatly
: >appreciated. Thanks in advance.
: > 
: >-Salman
: >salman@lccinc.com
: >
 
: The adress of the company is :
 
:        Siemensstraáe 23
:        D - 76275 Ettlingen
 
: Voice-Mail : 49 7243 / 502 - 0
:         Fax : 49 7243 / 502 - 989
 
: You normaly get all drivers with the card. There is a driver packet called SK - UPPS (universal programmel
: prtocol stack) you can use to communicate with novell (ipx, spx) and unix-workstation (tcp/ip) at the same
: time. This driver packet should be send with your SK-Junior board i think. 
 
: Wolfram Reinken
 
: E- Mail : reinken@tu-harburg.d400.de
:        or rztwr@molly.rz.tu-harburg.de



Hi there,

the Company Schneider & Koch has also a mailbox where you  can download new 
drivers and routing software: 49 7243 502 586

Bye Juergen 

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jul 94 12:01:22 GMT
From:      egn@athen.mch.sni.de (Emil Naepflein)
To:        comp.protocols.tcp-ip
Subject:   Re: How to use setsockopt with TLI?

In article <1994Jul19.174615.2395@isc-br.isc-br.com> bruceo@loki.isc-br.com (Bruce Oscarson) writes:
>I am working on a server that supports multiple protocols 
>(a proprietary and tcp/ip). The server was written using the TLI 
>interface and runs on 5.4 Unix. If the server restarts while tcp/ip 
>clients are connected, the port is placed in a FIN_WAIT2 state.  
>This state lasts for about 13 minutes.  During this time, the 
>server cannot re-connect to the port.
>
>I attempted to set tcp/ip based connections to SO_REUSEADDR to 
>ignore the FIN_WAIT2 state, but the fd returned from the t_open is 
>not a valid socket fd.
>
>Does anyone have a suggestion as to how I can get the socket 
>fd?  Any suggestions as to how I might solve this 'delay' problem
>without using SO_REUSEADDR or convert all of my clients to 
>async IO. (With async IO the client would detect the close on from 
>the server and initiate its own close.  The TIME_WAIT delay is 
>only about 1 minute.)

There is an internet protocol specific option called IP_REUSEADDR.
Setting this one to T_YES should provide the same behaviour as SO_REUSEADDR.
I got this information from the CAE Specification, X/Open Transport Interface
(XTI). You may have to check if this option is implemented in your flavour
of 5.4 Unix.

Emil Naepflein


-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jul 1994 13:24:53 GMT
From:      dbeedle@rs6000.cmp.ilstu.edu (Dave Beedle)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: routing on SunOS (with dp2.3) for remote PPP users?

King Rhoton (king@acpub.duke.edu) wrote:
> > I'm having trouble setting up cslip-2.7 on SunOS 4.1.3.  I can get
> > the line to answer and go into SLIP mode, and my remote station
> > (running Trumpet Winsock) can use TCP/IP to the host directly, but
> > they can't see any hosts outside the local domain.  FTP, Mosaic,
> > etc., just time out when they try to connect to a distant host.
> >
> > I think its something to do with routing, but I'm not sure.  How
> > should routing be set up on the host to which SLIP users dial in?
> >
> > Routing tables
> > Destination          Gateway              Flags    Refcnt Use        Interfa

ce
> > localhost            localhost            UH       4      17440      lo0
> > 199.123.192.10       parts                UH       1      33         sl0
> > default              199.123.192.1        UG       3      6342       le0
> > 199.123.192.0        parts                U        2      308        le0
> >
> > So, .10 can talk to parts and TCP/IP services on parts, and parts
> > can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc.,
> > but .10 can't talk to ftp.uu.net, etc.
 
> I'm having the exact same problem, only with PPP connections instead of
> slip.  I'm entirely baffled.  I've set up an arp entry for my remote
> machine, and from the remote machine ping requests to non-dialup-hosts do
> go through the PPP link (I see the tx led flicker), but I never get
> anything back.  I have full access to the dialup host, though.  I've tried
> both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and
> they behave the same.  It's got to be something in the Sun's
> configuration, but I'm out of ideas.  SunOS 4.1.3 and dp2.3pl2.

   Same problem here to.  We can reach host on the local net but nothing
outside that.  Would gated or routed have to runn to allow these connections?
Anybody got a tip?  Thanks!

-- 
  Dave Beedle  - Unix Support Manager - dbeedle@ilstu.edu -  Network Services
     http://www.ilstu.edu/~dbeedle/                 Illinois State University
 "It is better to think of church in the ale-house than      136A Julian Hall
  to think of the ale-house in church." - Martin Luther     Normal, IL  61761

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 20:20:04 -0400
From:      allen@stone.ucs.indiana.edu (Allen Robel)
To:        news.announce.newgroups,news.groups,comp.dcom.cell-relay,comp.dcom.isdn,comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.dcom.lans.misc,comp.protocols.tcp-ip,bit.listserv.novell
Subject:   RFD: comp.dcom.frame-relay

REQUEST FOR DISCUSSION

NEWSGROUP: comp.dcom.frame-relay

UNMODERATED

Crossposted to:
news.groups
news.announce.newgroups 
comp.dcom.cell-relay
comp.dcom.isdn 
comp.dcom.lans.ethernet 
comp.dcom.lans.fddi
comp.dcom.lans.misc
comp.protocols.tcp-ip
bit.listserv.novell

Given that Frame Relay is beginning to emerge as a mainstream WAN
service, and given that discussions of Frame Relay technology are
appearing with increasing frequency on other newsgroups such as
comp.dcom.cell-relay, perhaps now is the time to create a newsgroup to
provide a home for this topic.  Below is a draft charter, written by Tom
Jones, ex-chair of the Frame Relay Forum and continuing proponent of
Frame Relay services and technologies.  It is intended as a starting
point for discussion over the next month as to what shape a
Frame Relay newsgroup might take. Comments are welcome and encouraged.

As per Usenet "policy"/tradition, the following timeline will be adhered to:

7/21/94 - 8/21/94  
Discussion period

8/21/94 - ~9/21/94  
Voting (if it is generally agreed that this group would be a Good Thing).  
We will defer to the Usenet Volunteer Votetakers at Qualcomm to setup and 
conduct the vote.

Below is the proposed charter.  The Followup-To: field has been set to 
news.groups.  Please direct all comments concerning this Request for 
Discussion there.  

DRAFT CHARTER:

To provide a mechanism for the discussion of issues related to the
technology and application of frame relay in communications networks.

Topics expected to be discussed include (but are not limited to) the
following examples:

- frame relay standards and proposed standards
- applications of frame relay
- user experiences with frame relay
- relationship and comparison of frame relay to other technologies,
  including asynchronous transfer mode (ATM), cell relay, SMDS, X.25 packet
  switching, IP routing, ISDN, Broadband ISDN, etc.
- announcements of conferences, seminars, etc., related to frame relay
- news of the availability of frame relay products or services
- testing and interoperability of frame relay
- information related to performance and implementation of frame relay
- research findings
- activities of The Frame Relay Forum and other similar organizations with
  activities related to frame relay
- sources of additional information regarding frame relay

This newsgroup is not intended to be a forum in which standards are
developed, although it may be expected to relate news pertaining to
standards and to the progress of recognized standards bodies.

regards,
-- 
Allen Robel                        Internet: robelr@indiana.edu
Network Engineer                   voice:    (812)855-0962
Indiana University                 FAX:      (812)855-8299

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 20:20:10 -0400
From:      Bob Smith <bsmith@wci.com>
To:        news.announce.newgroups,news.groups,comp.dcom.lans.misc,comp.dcom.modems,comp.dcom.telecom.tech,comp.protocols.misc,comp.protocols.tcp-ip,sci.geo.satellite-nav
Subject:   RFD: comp.dcom.wireless.cdpd

************************************************************************
                      REQUEST FOR DISCUSSION (RFD)
                        comp.dcom.wireless.cdpd
************************************************************************

Group Name:     comp.dcom.wireless.cdpd
Status:         Unmoderated
Summary:        Discussion of all aspects of Cellular Digital Packet
                Data (CDPD), including discussions of carriers, services,
                applications, specifications, and noteworthy events.
Distribution:   World

                                CHARTER
                                -------

CDPD is wireless protocol which offers low cost and ubiquitous radio
coverage to TCP-IP networks.  The technology uses the idle voice channels
available in the existing cellular telephone system for packet data
transmission. Application interface to CDPD can be via telnet, SLIP, UDP,
or TCP.  A CDPD modem uses the AT command set and has an IP address which
is assigned by the local cellular company (just as your cellular carrier
assigned the phone number to your cellular phone). CDPD may be the 
preferred remote/mobile WAN since the time and cost overhead of a cellular
call establishment is not present.

The aim of comp.dcom.wireless.cdpd would be to provide an informal 
electronic conference for anyone curious about, or involved with CDPD. It
is hoped that the group may further the understanding and awareness of CDPD. 

CDPD's success requires the cooperation and coordination of many diverse
players: application developers, system integrators, cellular carriers, 
infrastructure manufacturers, and modem manufactures. A newsgroup where
ideas, suggestions, and questions can be freely exchanged is needed to 
help tie these players into an industry.

The FAQs would be an important part of the newsgroup and would include
as a minimum:
        FAQs about the nature and scope of CDPD
        a list of CDPD carriers and services offered
        a list of CDPD modem manufacturers
        a list of other CDPD products available

This newsgroup would allow the rapid and timely discussion of CDPD
related issues and events which might otherwise never be fully 
disseminated.

Topics for discussion would include :-

        Product announcements
        Press releases of interest to the CDPD community
        Innovative CDPD applications
        CDPD deployment issues and plans
        Interpretation of the CDPD specification
        Infrastructure hardware: NMS, MDBS, MD-IS, ...
        Infrastructure software: NMS, MDBS, MD-IS, ...
        Modems - specifications, opinions, etc.
        New product ideas
        Databases, lists of...
        CDPD security, encryption, and firewalls
        Announcements/reviews of papers/conferences
        Comparisons to alternatives such as RAM, Ardis
        General discussion/opinions/questions.
        Positions vacant
        Professional news
        Economic issues


We hope that you will support this group, and look forward to your
comments and participation in the discussions in news.groups.

Please distribute this proposal to your friends and colleagues.
This RFD has been posted to:
        comp.dcom.lans.misc
        comp.dcom.modems
        comp.dcom.telecom.tech
        comp.protocols.misc
        comp.protocols.tcp-ip
        news.announce.newgroups
        sci.geo.satellite-nav




The Process of Creating a Newsgroup
- ------------------------------------

(a) RFD: Request for Discussion, i.e.., public hearing to take place in
           the newsgroup news.groups on Internet for approximately one
           month
(b) CFV: Call for votes (the voting period will be about 25 days)
(c) Counting of votes and public display of votes
(d) Announcement of new newsgroup

(a)-->(b) assumes no major disagreements about this newsgroup during
           discussion.
(c)-->(d) assumes that at least two-thirds of the vote are positive and
          that the 'yes' votes outnumber the 'no' votes by at least 100.


Thank-you,

Bob Smith
-- 
Wireless Connect, Inc.
Voice: 408.296.1546  Fax: 408.296.1547
Email: bsmith@wci.com or bsmith@rahul.net

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 14:52:24 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        alt.dcom.telecom.ip,comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: Livingston Portmaster woes

Dr. Laurence Leff (mflll@uxa.ecn.bgu.edu) wrote:
: We are having trouble setting up our account mechanisms on our Livingston
: Portmaster 2E.  It is running Version 3.0.1 of the software

There is a mailing list for owners of Livingston Portmaster and IRX
hardware; send mail to
	To: majordomo@mail.msen.com

	subscribe portmaster-users
to join it.

thanks

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
Msen Inc., 320 Miller, Ann Arbor MI  48103 +1 313 998 4562 (fax: 998 4563)

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 14:53:10 GMT
From:      nelson@crynwr.crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Integrating DNS and BOOTP (was Re: Newbie DNS questions)

In article <30f2a3$asj@babs.nsr.hp.com> cricket@nsr.hp.com (Cricket Liu) writes:

Cricket is being modest.  If you have questions about the DNS, you
can't go wrong with the O'Reilly and Associates _DNS and Bind_,
written by Paul Albitz & Cricket Liu.

   The BOOTP server doesn't care whether the IP address it's assigning
   really maps to the hostname it's assigning in DNS, nor does DNS
   care that BOOTP is giving out the information.  I suppose some
   vendor may have created a nice system to integrate the management
   of these services, but I don't know of one.

Here's some code I wrote for a customer.  It's public domain.  It
parses a named input file, looking for special comments.  Here's an
example of the input.  The host's IP address is remembered, and
combined with the Ethernet address on the BOOTP comment line.

ray8180 IN      A       137.143.111.245
;                       BOOTP   000094573758
ray8152 IN      A       137.143.111.246
;                       BOOTP   AA000400A34F
ray8153 IN      A       137.143.111.247
;                       BOOTP   AA000400A44F
ray9154 IN      A       137.143.111.248
;                       BOOTP   AA000400A24F


#! /bin/sh
# This file is /usr/lib/named/makebootptab
# create /etc/bootptab from /etc/bootptab.head and /var/dss/namedb/named.potsdam
cat /etc/bootptab.head >/tmp/bootptab
nawk '$2 == "IN" {
        host = $1
        ip = $4
}

$2 == "BOOTP" {
        if ($3 in addr_to_host) {
                print "# Duplicate hardware address " $3 " for " host " and " addr_to_host[$3]
        } else {
                addr_to_host[$3] = host
        }
        printf("%s:tc=global.dummy:ht=ethernet:ha=%s:ip=%s:\n", host, $3, ip);
}' /var/dss/namedb/named.potsdam >>/tmp/bootptab

mv /etc/bootptab /etc/bootptab.bak
mv /tmp/bootptab /etc/bootptab
exit 0


#and this is all that needs to be in /etc/bootptab.head:
global.dummy:\
        :sm=255.255.252.0:\
        :ds=137.143.110.101:\
        :gw=137.143.110.254:\
        :to=18000:

--
-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jul 1994 15:20:55 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: connect() and ECONNREFUSED

> When issueing the connect() system call, what conditions may exist to generate 
> the error, ECONNREFUSED "The attempt to connect was forcefully refused"?  I 
> do not have access to the source code for the connect() system call, so any 
> help will be greatly appreciated.  

On BSD-based systems this only occurs when the response to the client's
SYN is an RST.  Normally this is only caused by the server's host
receiving a SYN for a server that doesn't exist (i.e., there does not
exist a TCP end point in the LISTEN state at the specified port).

	Rich Stevens

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jul 1994 15:28:19 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: connect() and ECONNREFUSED

One additional point upon rereading your posting ... it's possible
to start a server three different ways on a BSD-based system:
(1) accept any connection request to my port, (2) accept any
connection request to my port that arrives on a particular local
interface, and (3) only accept connections that arrive for my port
that originate from a particular client IP address and port.  Check
out Section 18.11 ("TCP Server Design") of my "TCP/IP Illustrated"
(Addison-Wesley, 1994) for additional details.

Check that your server (which accepts the incoming connection from
the client on the Ethernet) isn't started with either conditions
(2) or (3) above.  "netstat -a" should show you the status of the
server's listening socket.

	Rich Stevens

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jul 1994 16:43:08 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP update mechanism on unix hosts

In article <30epgcINN6ac@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <albert.774173072@netboss> albert@dn.itg.telecom.com.au (Albert Fu) writes:
 
> ...
>>	       Also, is there a mechanism for the Unix host to
>>refresh its ARP cache periodically, eg every 10 minutes?
>
>This probably depends on the Unix version.  I don't think there's a
>built-in timeout in BSD Unix.  You could have a cron job that executes a
>script that deletes all the entries in the ARP cache.

A quick peak at netinet/if_ether.c would probably be more illuminating
that inaccurate speculations. Consider these lines from one version
of if_ether.c

#define ARPT_KILLC      20      /* kill completed entry in 20 mins. */
#define ARPT_KILLI      3       /* kill incomplete entry in 3 minutes */


Vernon Schryver    vjs@rhyolite.com

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jul 1994 16:43:38 GMT
From:      dtoppin@ucserv.melpar.esys.com (Doug Toppin)
To:        comp.protocols.tcp-ip
Subject:   Do UNIX domain sockets cause any disk activity?


We are heavily using Unix domain sockets and regularly notice
disk activity on our Sun 4.1.3 systems that I can't attribute to
anything else.
I don't believe that any disk activity should be related to the domain
sockets excepting for the opening of the socket (implemented as
a named pipe in the file system).
Since the size and mod date/time never change I don't see any
reason for this to cause disk activity.

Doug Toppin
dtoppin@melpar.esys.com

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 17:00:32 GMT
From:      kong@pascal.cs.albany.edu (Waiyee L Kong)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.domains,comp.os.ms-windows.networking.tcp-ip,comp.protocols.nfs
Subject:   RPC Gen and ASN.1


hi, everybody,

If anybody can tell me where (or which ftp sites) I can get information on  RPC,
RPC Gen, XDR and ASN.1 (the actual RPC Gen code/compiler and documentation aboutwhat system it supports and the specfications, or which company out there 
gives such services), I would really really appreciate it.

I need it in these 2 days... please email me at kong@cs.albany.edu
Thank you very much.

Lydia

--MAA26433.774723274/pascal.cs.albany.edu--



-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jul 94 17:48:51 GMT
From:      lutz@prodigal.psych.rochester.edu (Dave Lutz)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: routing on SunOS (with dp2.3) for remote PPP users?

In <1994Jul20.132453.89403@rs6000.cmp.ilstu.edu> dbeedle@rs6000.cmp.ilstu.edu (Dave Beedle) writes:

>King Rhoton (king@acpub.duke.edu) wrote:
>> > I'm having trouble setting up cslip-2.7 on SunOS 4.1.3.  I can get
>> > the line to answer and go into SLIP mode, and my remote station
>> > (running Trumpet Winsock) can use TCP/IP to the host directly, but
>> > they can't see any hosts outside the local domain.  FTP, Mosaic,
>> > etc., just time out when they try to connect to a distant host.
>> >
>> > I think its something to do with routing, but I'm not sure.  How
>> > should routing be set up on the host to which SLIP users dial in?
>> >
>> > Routing tables
>> > Destination          Gateway              Flags    Refcnt Use        Interfa
 
 ce
>> > localhost            localhost            UH       4      17440      lo0
>> > 199.123.192.10       parts                UH       1      33         sl0
>> > default              199.123.192.1        UG       3      6342       le0
>> > 199.123.192.0        parts                U        2      308        le0
>> >
>> > So, .10 can talk to parts and TCP/IP services on parts, and parts
>> > can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc.,
>> > but .10 can't talk to ftp.uu.net, etc.
 
>> I'm having the exact same problem, only with PPP connections instead of
>> slip.  I'm entirely baffled.  I've set up an arp entry for my remote
>> machine, and from the remote machine ping requests to non-dialup-hosts do
>> go through the PPP link (I see the tx led flicker), but I never get
>> anything back.  I have full access to the dialup host, though.  I've tried
>> both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and
>> they behave the same.  It's got to be something in the Sun's
>> configuration, but I'm out of ideas.  SunOS 4.1.3 and dp2.3pl2.
 
>   Same problem here to.  We can reach host on the local net but nothing
>outside that.  Would gated or routed have to runn to allow these connections?
>Anybody got a tip?  Thanks!


  I am running the loadable version of cslip-2.7 on a Sun3 running SunOS 4.1.1,
and it works fine for some clients, but not for others.  When I run cslipper on
a PC, then use NCSA telnet, I can telnet to any host I want.  If I run an NCR X
terminal over the same connection, I can only connect to the slip server.  I
can't even connect to other hosts in the same network.

  The routing tables on the server look like this:

solace:~% netstat -r
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
localhost            localhost            UH       1      789        lo0
slip86               solace               UH       0      6          sl0
128.151.80.0         solace               U        19     379419     le0
default              128.151.80.24        UG       0      412        le0

  Arp shows the following:

solace:~% arp -a
slip86.psych.rochester.edu (128.151.80.86) at 8:0:20:0:7d:ac permanent published

  On another system, arp shows:

prodigal:~% arp -a | egrep "solace|slip"
solace.psych.rochester.edu (128.151.80.53) at 8:0:20:0:7d:ac
slip86.psych.rochester.edu (128.151.80.86) at 8:0:20:0:7d:ac

  I don't know what this all means, but for me it seems to be a client
problem, not a server problem.

Dave

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 18:14:44 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: connection wierdness

In article <cavenewtCt7GFL.3K7@netcom.com> cavenewt@netcom.com (...In Bed) writes:
>I've been using   gethostbyname(localhost), where localhost is determined by
>gethostname(localhost,255) to get the sockadd_in structure infromation for
>a server I'm making.  When I run the server and telnet machinename portnumber
>then it responds.  If I  telnet localhost (as in 127.0.0.1) portnumber
>I get connection refused.   Is this normal?  How do I make my server
>accept connections to all local IP addresses (interfaces, whatever).

Yes, it's normal.  You said you only wanted to serve connections to a
specific IP address, so connections to other addresses are refused.

Use INADDR_ANY as the address in the bind(2) call if you want to accept
connections to any of the host's addresses.  This is also useful if a host
has multiple interfaces.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 16:06:16 +0300
From:      yosi@wiscon.weizmann.ac.il (Yosi Mass)
To:        comp.protocols.tcp-ip
Subject:   file transfer facility


I'm looking for a file transfer facility beyond copy (VMS) and FTP
over tcp/ip which offers:

- An API for add-on applications
- Triggering follow-up tasks on reciever's side
- Guranteed delivery (e.g if reciever is currently down, recovery from failures)
- On the fly compression
- Monitoring and statistics

Does anybody knows of something that does some or all of the above?


--
Yosi Mass

Ubique Ltd.
--
Yosi Mass

Ubique Ltd.

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 23:17:03 GMT
From:      jenkins@oils (Jon Jenkins)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: routing on SunOS (with dp2.3) for remote PPP users?

Dave Beedle (dbeedle@rs6000.cmp.ilstu.edu) wrote:
: King Rhoton (king@acpub.duke.edu) wrote:
: > > I'm having trouble setting up cslip-2.7 on SunOS 4.1.3.  I can get
: > > the line to answer and go into SLIP mode, and my remote station
: > > (running Trumpet Winsock) can use TCP/IP to the host directly, but
: > > they can't see any hosts outside the local domain.  FTP, Mosaic,
: > > etc., just time out when they try to connect to a distant host.
: > >
: > > I think its something to do with routing, but I'm not sure.  How
: > > should routing be set up on the host to which SLIP users dial in?
: > >
: > > Routing tables
: > > Destination          Gateway              Flags    Refcnt Use        Interfa
 
 ce
: > > localhost            localhost            UH       4      17440      lo0
: > > 199.123.192.10       parts                UH       1      33         sl0
: > > default              199.123.192.1        UG       3      6342       le0
: > > 199.123.192.0        parts                U        2      308        le0
: > >
: > > So, .10 can talk to parts and TCP/IP services on parts, and parts
: > > can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc.,
: > > but .10 can't talk to ftp.uu.net, etc.
 
: > I'm having the exact same problem, only with PPP connections instead of
: > slip.  I'm entirely baffled.  I've set up an arp entry for my remote
: > machine, and from the remote machine ping requests to non-dialup-hosts do
: > go through the PPP link (I see the tx led flicker), but I never get
: > anything back.  I have full access to the dialup host, though.  I've tried
: > both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and
: > they behave the same.  It's got to be something in the Sun's
: > configuration, but I'm out of ideas.  SunOS 4.1.3 and dp2.3pl2.
 
:    Same problem here to.  We can reach host on the local net but nothing
: outside that.  Would gated or routed have to runn to allow these connections?
: Anybody got a tip?  Thanks!
you might need to enable ipforwarding and ipgateway on both machines. On OSF/1 this is done
by a function called: iprsetup (it just sets two kernel variables: ipforwarding
and ipgateway to != 0. The host RFC requires that it NOT be enabled by default.

hope this helps 
jon

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 01:24:47 GMT
From:      rao@acsc.com (Rao Srinivasa)
To:        comp.protocols.tcp-ip
Subject:   Ethernet card in Promiscuous mode ..?


Hi,
	
	Can some one let me know how to set Ethernet card in promiscuous mode
        on RS6000 machines ...
 
	Is it System/OS dependent ...?
	


Thanks in advance ...
Rao.



-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jul 1994 02:05:07 GMT
From:      alagu@apple.com (Alagu Periyannan)
To:        comp.protocols.tcp-ip
Subject:   BSD sockets to XTI/TLI API conversion code ?

Hi,

Does anyone know of public domain source code that
converts BSD sockets API to the XTI/TLI API ?

I should be able to take any application written for
the BSD sockets API and link it with this "magic code"
and be able to use the XTI/TLI API instead.
(I am looking specifically to use this to port TCP/IP apps
like FTP.)

Any pointers will be much much much ... appreciated.

Thanks in advance.

-------------------------------------------------------------------------
Alagu Periyannan               alagu@apple.com

Advanced Technology Group
Apple Computer, Inc.

Disclaimer: My opinions are my own, not Apple's ...

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 10:47:43 +1000
From:      yonsei@usenet.hana.nm.kr (Yonsei News Adm)
To:        comp.protocols.tcp-ip
Subject:   Call for Paper ICCC95



Following is the FIRST CALL FOR PAPER for ICCC'95 to be held in Seoul
Korea 1995.

Publicity Chair, 
ICCC'95
-----------------cut here---------------------------------------------
----------------------------------------------------------------------

                     	  CALL FOR PAPERS

                       	     ICCC '95 

       "Information Highways for a Smaller World  & Better Living" 
			  Seoul, Korea
                     August 21 - 24, 1995

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

    The ICCC, the International Council for Computer Communication (ICCC), 
    founded in 1972,  is an Affiliate Member of the International Federation 
    for Information Processing (IFIP). 

    Its purposes are to foster:   
        · scientific research and the development of computer communication;
        · progress in the evaluation of applications of computer communication 
	  to educational, scientific, medical, economic, legal, cultural and 
	  other peaceful purposes;
        · study of the potential social and economic impacts of computer 
	  communcation and of policies which influence those impacts. 

    This 12th conference aims at providing a forum to exchange ideas, discuss 
    key issues and to present  the late research results for "Information Highways 
    for a Smaller World  & Better Living."  The main program includes technical 
    presentations, invited talks, tutorials, and technical visits. 


    TOPICS :  Areas of interest include but are not limited to

	. Strategies, Policies, and User       . Wireless Communications
	  Perspectives of Information          . Intelligent Networks		
	  Superhighways                        . Personal Communications Systems
        . Social and Economical Impacts        . Broadband Communication
	  of Information Superhighways         . ATM Switching
        . Computer Communication for           . International Emergencies
	  Developing Countries                 . Distance Learning
        . Network Planning                     . Optical Communications
	. Security and Privacy in Computer     . Multimedia Communication and its
	  Communications                         Applications
        . Evolution towards the High-Speed     . High-Speed Protocols
	  Networks including Frame Relay       . Network Management  
	  and SMDS                             . Protocol Engineering     
	. Packet Radio Technologies
	. Satellite Communications


    SUBMISSION OF PAPERS  

        Prospective authors should send 5 copies of a full paper to the following 
	address;
		ICCC'95
		Dr. Seon Jong Chung
		ICCC'95 Technical Program Chairman
		ETRI,  Yusong P.O.Box 106, Taejon, Korea, 305-606
		Tel: +82-42-860-8630
		Fax: +82-42-860-6465
		E-mail: iccc95@giant.etri.re.kr


        The manuscript should not exceed 4000 words in length and should include 
	author's name, affiliation, and addresses(telephone, e-mail, fax), and 
	150-200 words abstracts in the title page. Also, authors are encouraged 
	to send a Postscript version of their full paper to the Technical Program 
	Committee Chairman by e-mail iccc95@giant.etri.re.kr

                             |-------------------------------|
                             |  Important Dates              |
                             |    Submission of Paper        |
                             |      February 1st, 1995       |
                             |    Notification of Acceptance |
                             |      May 1st, 1995            |
                             |    Camera-ready Papers        |
                             |      June 15th, 1995          |
                             |-------------------------------|

-----------------------------------------------------------------------------------
    Sponsored by
	The International Council for Computer Communication

    Hosted by
	Electronics and Telecommunications Research Institute
	Korea Information Science Society

    Under the Patronage of
	Ministry of Communication, The Republic of Korea


    Conference Governor                          
	Ronald P.Uhlig, Northern Telecom, U.S.A.
					       

    Conference Organizing Committee
	Chair : Chongsun Hwang, KISS, Korea
	Co-Chair : Seungtaik Yang, ETRI, Korea

    Local Arrangement 
	Dongho Lee, Kwangwoon Unvi., Korea

    Publication 
	Keosang Lee, Dacom, Korea
    
    Publicity
	Jaiyong Lee, Yon-Sei Univ., Korea

    Registration 
	Samyoung Suh, NCA, Korea

    Treasurer 
	Seungkyu Park, Ajou Univ., Korea

    Tutorial 
	Sunshin An, Korea Univ., Korea

    Social Program 
	Nosik Kim, KTRC, Korea

    Secretariate 
	Yanghee Choi, SNU, Korea
        Jinpyo Hong, ETRI, Korea

    Technical Program 
        Chair : Seonjong Chung, ETRI, Korea
	Co-Chairs : Serge Fdida, MASI, France
		    Nicholas Georganas, Univ. of Otawa, Canada
		    Roger Needham, Univ. of Cambridge, U.K.
		    Otto Spaniol, Aachen Tech. Univ., Germany
		    Hideyoshi Tominaga, Waseda Univ., Japan
		    Pramode Verma, AT&T, U.S.A.
        Members : Byungchul Shin, KAIST, Korea
		  Yongjin Park, Hanyang Univ., Korea
		  Donggyoo Kim, Ajou Univ., Korea
		  Kwangsue Chung, Kwangwoon Univ., Korea
		  Daeyoung Kim, Cheoungnam National Univ., Korea
		  Ilyoung Chung, ETRI, Korea
		  Chimoon Han, ETRI, Korea
		  Woojik Chon, ETRI, Korea
		  Hoon Choi, ETRI, Korea
		  Tadao Saito, Tokyo Univ., Japan
                  Tahahiko Kamae, HP Lab., Japan
		  Reigo Yatsuboshi, Fujitsu Lab., Japan
		  Kinji Ono, NCIS, Japan
		  Michael Diaz, LAAS, France
		  Christophie Diot, INRIA, France
		  Georgio Ventre, Univ. di Napoli, France
		  David Hutchison, Lonchaster Univ., U.K.
		  Augusto Casaca, IST-INESC, Spain
		  Martina Zitterbart, Univ. of Karlsiuhe, Germany
		  Ulf Koerner, Lund Univ., Sweden
		  Albert Kuendig, Swiss Federal Inst. of Tech., Swiss

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



-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 94 03:57:28 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: connect() and ECONNREFUSED

In article <1994Jul20.152819.17687@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes:
| One additional point upon rereading your posting ... it's possible
| to start a server three different ways on a BSD-based system:
| (1) accept any connection request to my port, (2) accept any
| connection request to my port that arrives on a particular local
| interface, and (3) only accept connections that arrive for my port
| that originate from a particular client IP address and port.  Check
| out Section 18.11 ("TCP Server Design") of my "TCP/IP Illustrated"
| (Addison-Wesley, 1994) for additional details.

I assume your case (2) refers to bind()ing to the particular IP address
associated with one of your local interfaces.  What this really does is
accept connections destined for said IP address, regardless of which
interface their SYNs arrive on.  Although the difference is subtle, it
can be important in some multi-homed situations.

Case (3) is not one I've seen supported on typical BSD systems (at
least not intentionally :).  Can you be more specific?

				Dan Lanciani
				ddl@harvard.*

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1994 15:04:03 +0800
From:      smenda@perth.DIALix.oz.au (Greg Smenda)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   OSPF sources


I am looking for a list of sources for OSPF code, both public domain  
and private. I am interested in how many people are actually  
producing implementations of this protocol, given the seemingly 
large interest in it as a successor to RIP. 

Greg

Please respond to my email address, smenda@dialix.oz.au

Thanks

-- 
Greg Smenda           Internet :  smenda@DIALix.oz.au
                        ACSnet :  smenda@DIALix.oz
                        Voice  :  +61-9-4451888   0800 - 1730 WST
        - Fishy fishy fishy fish, it would go where ever I did go -

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 01:30:00 +0200
From:      pb@fasterix.frmug.fr.net (Pierre Beyssac)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Usage Billing package ?

In article <1994Jul12.125058.30409@ucl.ac.uk>,
Jon Crowcroft <ucacjon@ucl.ac.uk> wrote:
>there is a "market force" myth going around (some people at INET
>in prague were trying to
>perpertrate it) that you get more money by doing useage based charging
>
>this is false, and there are people who even have maths to show it...

No need for complicated maths.

Charging by usage means billing overhead everywhere in your system...
Hence a less efficient use of available ressources.

Of course the user has to pay for this overhead. He ends up paying
more for the same service...

To put it another way, the IP provider ends up with prices higher
than the competition for providing a service worse or no better.

Guess what the users will do next...

This very scenario is currently occuring in France : some IP
providers charge by usage, not their competition...

Usage charges are still very popular in Europe, probably a legacy
of X25. X25 is dying partly for lack of services. Correct me if
I'm wrong, but I see a relation between these...
-- 
Pierre Beyssac                  FreeBSD@home: pb@fasterix.frmug.fr.net

FreeBSD, NetBSD, Linux 	-- Il y a moins bien, mais c'est plus cher.
You can also get less bang for more bucks. (translation F. Berjon)

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 04:53:13 GMT
From:      bumble@hudson.cse.psu.edu (Marc David Bumble)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over atm performance measurement question?


We are running tcp/ip over an atm network.  In addition to testing
applications, we would like to take some meaningful network
performance measurements.  What types of network parameters are
good to check and what is the best way of accessing these parameters?

thanks,

marc

BAGnet Gigabit Testbed

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 18:28:58 -0700
From:      zeno@zebu.abstractsoft.com (Sean T. Lamont)
To:        alt.dcom.telecom.ip,comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: Livingston Portmaster woes

In article <30ccu0$ls4@uxa.ecn.bgu.edu> mflll@uxa.ecn.bgu.edu (Dr. Laurence Leff) writes:
>We are having trouble setting up our account mechanisms on our Livingston
>Portmaster 2E.  It is running Version 3.0.1 of the software
>
>We need to support both SLIP users and login id's.

you may not have the port set up as a login / network port. To do this try:

set port s1 login network dialin

-Sean

-- 
Sean T. Lamont                           |   Ask me about the WSI-Fonts
Abstract Software                        |   Professional collection for NeXT 
lamont@abstractsoft.com                  |____________________________________

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 17:18:50 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip
Subject:   SIGPOLL SIGIO on TCP on SunOS: Is it there?

I am starting development on a TCP/IP application, and I have heard that
on some systems, you can use the SIGIO/SIGPOLL signal to alert the app
to when data is in the TCP/IP pipe.  I am working on SunOS, so can
somoen point me in the right direction to learn if and how to do this on
SunOS (Solaris 1.1)

--
Jim Brain, Embedded Systems Designer, Brain Innovations.
brain@msen.com  
Dabbling in VR, Old Commodore Computers, and Good Times!
"The above views DO reflect my employer, since I am my employer" - Jim Brain


-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 12:57:40 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   SIPP implementations


Since SIPP apparently is winning(won?) I would like to take a close
look at it. I am looking for an implementation (even a partial one)
for KA9Q NOS, Sun 4.1.x, BSD 4.4, or Linux. Anybody got one they want
to share.


-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jul 1994 13:56:11 GMT
From:      dtaylor@empros.com (Dave Taylor)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet card in Promiscuous mode ..?

In article <30kiov$ko9@acsc.com>, rao@acsc.com (Rao Srinivasa) writes:
|> 
|> Hi,
|> 	
|> 	Can some one let me know how to set Ethernet card in promiscuous mode
|>         on RS6000 machines ...
|>  
|> 	Is it System/OS dependent ...?
|> 	
|> 
|> 
|> Thanks in advance ...
|> Rao.
|> 
|> 

RTFM.  InfoExplorer "Ethernet Device Handler Overview" says:
"Note:	The Ethernet device handler does not support promiscuous addressing."

(Although I understand that a future release will support it.)

-- 
David K. Taylor                       dtaylor@empros.com
Siemens Empros Power Systems Control  (612) 553-4717

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 10:58:53 +0200
From:      schneck@GeNUA.DE (Bernhard Schneck)
To:        comp.protocols.tcp-ip,comp.os.linux.help,comp.dcom.lans.ethernet
Subject:   Re: tcpdump analysis prg?

mathias@solomon.technet.sg (Mathias Koerber) writes:

>Now I wonder whether someone has already written some tools to do
>analysis and statistics from the tcpdump output.

Take a look at the NNStat package ... it doesn't work on top of
tcpdump, though.
-- 
Bernhard Schneck                                      Bernhard.Schneck@GeNUA.DE
Gesellschaft fuer Netzwerk-
und Unix-Administration mbH                                 Auslaender bleiben,
Leoprechtingstr. 13, 81739 Muenchen, Germany                  Nazis vertreiben!

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 15:07:06 GMT
From:      goli@rasii.rchland.ibm.com (Srinivas Goli)
To:        comp.protocols.tcp-ip
Subject:   Re: connect() and ECONNREFUSED

In article <1994Jul20.152819.17687@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes:
|> One additional point upon rereading your posting ... it's possible
|> to start a server three different ways on a BSD-based system:
|> (1) accept any connection request to my port, (2) accept any
|> connection request to my port that arrives on a particular local
|> interface, and (3) only accept connections that arrive for my port
|> that originate from a particular client IP address and port.  Check
|> out Section 18.11 ("TCP Server Design") of my "TCP/IP Illustrated"
|> (Addison-Wesley, 1994) for additional details.
|> 
|> Check that your server (which accepts the incoming connection from
|> the client on the Ethernet) isn't started with either conditions
|> (2) or (3) above.  "netstat -a" should show you the status of the
|> server's listening socket.
|> 
|> 	Rich Stevens

How about a concurrent server in the LISTEN state but its LISTEN queue full?
I had once created a concurrent server which would accept requests from multiple
clients and create a subserver to process the clients request. 

I was getting ECONNREFUSED for some of the requests while others were working fine.
So the solution I used was whenever I get this error I would retry the connect function.
It worked fine. Am I right in assumin that the the LISTEN queue was full. It was on ULTRIX
but I am not sure about the version.


-- 
\begindata{text,537360512}
\textdsversion{12}
\template{messages}



\bold{Srinivas Reddy Goli,564545} \italic{(goli@rchland)}

department 4a6 (BVT Team)

IBM   Rochester, Minnesota

         (507)253-3882

t/l      553-3882

\enddata{text,537360512}

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jul 1994 15:44:08 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: connect() and ECONNREFUSED

> | One additional point upon rereading your posting ... it's possible
> | to start a server three different ways on a BSD-based system:
> | (1) accept any connection request to my port, (2) accept any
> | connection request to my port that arrives on a particular local
> | interface, and (3) only accept connections that arrive for my port
> | that originate from a particular client IP address and port.  Check
> | out Section 18.11 ("TCP Server Design") of my "TCP/IP Illustrated"
> | (Addison-Wesley, 1994) for additional details.
>
> I assume your case (2) refers to bind()ing to the particular IP address
> associated with one of your local interfaces.  What this really does is
> accept connections destined for said IP address, regardless of which
> interface their SYNs arrive on.  Although the difference is subtle, it
> can be important in some multi-homed situations.

Correct.

> Case (3) is not one I've seen supported on typical BSD systems (at
> least not intentionally :).  Can you be more specific?

You are right, this option is not typically found with BSD-based systems.
(I must have been thinking of the RFC 793 OPEN, or the BSD UDP connect()
scenario.)  Indeed, when looking at the table in my book I see the
parenthetical note "normally not supported"!

	Rich Stevens

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jul 1994 15:59:33 GMT
From:      exujlg@exu.ericsson.se (Jon L. Gauthier)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   HP JetDirect card in HP4Si Mx printer?

We've been installing HP LaserJet 4Si printers with the HP JetDirect network
interface card on our ethernet TCP/IP network for several months now.  So far
they've been performing flawlessly.

Until now, they've all been installed on a single IP subnet (Actually, it's
quite a large subnet - 2/3's of our PC network.  Since only a few PCs are
running TCP/IP, one class C subnet works fine.).  They're all configured
to use bootp, and it works great. I've got 2 bootp servers on that subnet,
overkill, but we need the redundancy.  

But now, I have two new printers, each one on a different subnet.  Our routers
have the bootp helper protocol enabled, which works fine for all the PC users
on each of those subnets.  I get bootp requests from those PC fine, but I
never see a single request from either printer, even though bootp is enabled.

The only other difference I can see is that the JetDirect firmware on the
working printers is version A.02.01, and on the new printers it is A.03.03.

HP hasn't been of any help, so I appeal to the netgods for divine guidance...;^)


------------------------------------------------------------------------------
Jon L. Gauthier                                 Ericsson Network Systems, Inc
EXU/IS/N Sr. Systems Programmer                               P.O. Box 833875
+1 214 997-0157                                     Richardson, TX 75083-3875

e-mail:  exujlg@exu.ericsson.se, exu.exujlg@memo.ericsson.se
------------------------------------------------------------------------------


-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 16:16:14 GMT
From:      swbarnes@slb.com (Simon Barnes)
To:        comp.protocols.tcp-ip
Subject:   TTL too small


Sorry if this is a FAQ, but how does one talk to hosts which are more than
30 hops away on the network?  Ping works but other Unix programs such as telnet 
and sendmail either set the IP time-to-live to 30, or else allow it to default
to 30.  It's not big enough!

Simon Barnes
Geco-Prakla (Gatwick)
swbarnes@slb.com

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 22:58:25 -0400
From:      m-sm0088@cs.nyu.edu (Srinivasu Mandava)
To:        comp.protocols.tcp-ip
Subject:   Interconnction 2 LANs using 2 leased lines ?

        I need to interconnect 2 LANS using leased line and a pair of
        routers on either end. As a backup I plan to use 2 such pairs.
        I.e 2 routers  on each LAN even though mean time between failures
        of a router is reasonably high.

        Are there any routers in the market which can do the following:
        1. When both the lines are functional share the load i.e when
        both the lines are up the through put should be double that of
        a single line.
        2. Interconnection should be maintained even if a line or
        a router is down.

        If I cannot achieve (1) , (2) is essential.

	Srinivasu Mandava
	m-sm0088@dopey.nyu.edu

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 23:57:36 -0400
From:      gt2540b@prism.gatech.edu (Tim Shelling)
To:        comp.protocols.tcp-ip
Subject:   Re: Security/Firewall FAQ?

bbosen@netcom.com (Bob Bosen) writes:

>I hope somebody else will point you at an appropriate FAQ. In addition,
>you might like to take a look at the animated tutorial software that
>my company has made available for your VGA-equipped IBM PC. This
>stuff teaches many important issues regarding firewalls, and it's
>quite entertaining to watch. It's good for motivating your management
>team on the importance and functionality of firewalls. It stresses
>the kinds of firewalls that can positively identify the _people_ that
>request access to your networks, as opposed to just filtering on
>protocols. To see it, use anonymous ftp to go to:
 
>ftp.netcom.com
 
>Then cd to:
 
>/pub/bbosen/Enigma/Tutorials/VGA/Grasp/Firewall
>and
>/pub/bbosen/Enigma/Tutorials/VGA/Grasp/Cisco

There's absolutely nothing in Cisco.
Just checked.



>-- 
 
>Bob Bosen
>Enigma Logic Inc.
>2151 Salvio St. #301
>Concord, CA   94520
>USA
 
>Tel: +1 510 827-5707
>Internet: bbosen@netcom.com
>**************************************************************************
>* "It wasn't me!!! Somebody must have captured my username/password!!!"  *
>**************************************************************************
-- 
 Ultimately, you believe all things because you want to believe you know. FH
 Argue for your limitations -- and sure enough -- they're yours. RB
main(){write(0,"Tim Shelling, CmpE, Sr.\n" "gt2540b@prism.gatech.edu\n",50);}

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 19:03:11 GMT
From:      shirono@ssd.csd.harris.com (Roberto Shironoshita)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem: our net vs Internet

In article <30iaao$pbi@que.iphase.com> bfriesen@iphase.com (Bob Friesenhahn) writes:

> : >We are supposed to join the wonderful world of Internet 
> : >connectivity. To  that end, we have a NetHopper router 
> : >and a new upgraded account with  Netcom.
> : >
> : >However, we have a problem.
> : >
> : >The IP addresses are totally different from the IP 
> : >address we have been  assigned from Netcom. 
> : >
> : >QUESTION: Is there a way to resolve this problem 
> : >without having to
> : >change the IP addresses on every single one of our PCs 
> : >and UNIX boxes?
>
> This is solely a routing problem.  Your network must be an officially
> assigned subnet.  Also, you should obtain a domain name associated with
> your subnet.  Entries are then placed in the Internet DNS system which
> advertise the route to your subnet via Netcom.  Netcom should be able
> to handle this for you.

Note that the DNS has nothing to do with routing.  The routing information
is exchanged between the diverse routers in the Internet, and is based on
the IP addresses.  The DNS is a system that maps human-friendly domain
names to machine-friendly IP addresses (with a few other things thrown in,
like mail exchangers).

> In order to make it out of your subnet to the Internet, you will need
> to configure your hosts such that they know to route through your
> gateway for addresses outside of the local net.  A default route can
> work for this.

The reply to the original question depends on whether they are using an
assigned IP number.  If they are, then Netcom can add the network to their
routing tables, and that is it, insofar as people "outside" the LAN sending
packets to the LAN.  Then, a default route inside the LAN (pointing at the
Nethopper) would be sufficient to establish two-way communications.

If the LAN was using an un-assigned IP network number, then the only real
choice is to switch to the addresses given out by Netcom.
--

------------------------------------------------------------------------------
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
            opinion or policies of Harris Computer Systems.

        In-Real-Life:   Roberto Shironoshita
                        Harris Computer Systems
        Internet:       Roberto.Shironoshita@mail.csd.harris.com
        UUCP:           ...!uunet!mail.csd.harris.com!Roberto.Shironoshita

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 94 19:36:38 GMT
From:      fredn@sunriv.UUCP (Fred Nemecek)
To:        comp.mail.sendmail,comp.mail.misc,comp.protocols.tcp-ip,comp.unix.sysv386,sco.opendesktop,misc.misc
Subject:   Sendmail Help Needed...

Hello Netland,

I am in need of some help with my companies network
more specificly sendmail.  We have a small subnet
the connects to the internet through a FreeBSD PC
running SLIP.  My problem is with the SCO ODT machine,
I need it to deliver local mail to its self and send all
other mail to the FreeBSD machine to be resolved.  The SCO
machine should not be accessible by the outside world
and will receive its mail from the FreeBSD machine via 
sendmail.

The system is currently working with the SCO machine doing
some of the resolving.  We have it setup using the /etc/hosts, 
/etc/resolv.conf files, and have the routing as "route add default
FreeBSD_machine".  This is a bubble gum and bailing wire setup
at best.  

I want to get rid of the /etc/resolv.conf or at least change it
to be simple so the routing is more direct.

Any and all assistance in this manner will be greatly
appreciated.  Flames are also well come, thats how desperate
I am.  

PS - Please reply to USENET News or Email me at 
root@defender.sunriver.com.

Thanks again...

Fred Nemecek
Technical Support MGR
SunRiver Corporation
(512) 835-8001 x125

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 20:35:57 GMT
From:      grpjl@iastate.edu (Paul J Lustgraaf)
To:        comp.protocols.tcp-ip
Subject:   Re: TTL too small

In article <30m70e$l1d@gorgon.gatwick.geco-prakla.slb.com>,
Simon Barnes <swbarnes@slb.com> wrote:
>
>Sorry if this is a FAQ, but how does one talk to hosts which are more than
>30 hops away on the network?  Ping works but other Unix programs such as telnet 
>and sendmail either set the IP time-to-live to 30, or else allow it to default
>to 30.  It's not big enough!


Buy some modern software?  (:-)

-- 
Paul Lustgraaf             "It's easier to apologize than to get permission."
Network Specialist                                      Grace Hopper
Iowa State University Computation Center                    grpjl@iastate.edu
Ames, IA  50011                                                  515-294-0324

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jul 1994 21:59:11 GMT
From:      drubin@poly.edu (Dave Rubin)
To:        comp.sys.sun.apps,comp.protocols.tcp-ip,comp.protocols.snmp,comp.dcom.lans.ethernet
Subject:   Modeling of Network Routing?


I am interested in an environment that would allow modeling of network
routing behavior, specifically with OSPF.

I would like to create a representation of a specific network topology,
ideally in a graphical fashion using a tool such as SunNet Manager.
Based on OSPF, the system should be able to identify the routes between
various points on the network.

Then, I would like to analyze various "what if" scenarios, to see how the
routing in the network would be affected by, for example, a router failure.
The goal is to identify potential problems and bottlenecks BEFORE the
actual network is deployed.

Does anyone know of any software, or SunNet Manager add-on, that would
do this or some form of network routing modeling?  If not, can
you point me in the right direction?

Thanks ... please respond via E-mail.

--
Dave Rubin				E-mail: drubin@poly.edu
Polytechnic University			Phone:  (718) 260-3212
Brooklyn, NY				FAX:    (718) 260-3930

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 22:40:59 GMT
From:      carlos@m3isystems.qc.ca (Carlos Perez)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Addresing scheme

My company has branch offices in Chicago, and Pittsburgh. We are 
part of the Internet in Montreal, Canada. I'm looking for some advice on 
how to link our branch offices to Montreal. 


	o Would it be a good idea to set up a PPP box in
          the branch offices and use a private phone line?
          This way branch offices will be under my domain
          name and I 'll assign them IP addresses. Will the
          telecom cost prohibit this scheme?

	o Would it be better to use a local organization to provides 
          Internet access to the branch offices?. Will they need their
	  own IP adddresses or will the branch offices appear as another 
          node of the Internet service provider?


	o Any references for Internet services providers in 
          Chicago and Pittsburgh will be appreciated.


Where can I get the form to register a domain and request for 
class C addresses in the US.


==================================================================     
Carlos Perez                          carlos@M3iSystems.QC.CA
Systemes M3i Inc.,	 	      
1111, rue St-Charles ouest            phone: (514) 928-3386 x-2478
Longueuil, J4K 5G4, Quebec            fax:   (514) 442-5076
==================================================================     


-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 02:55:29 GMT
From:      eel@auspost.com.au (Elena Leong)
To:        comp.protocols.tcp-ip
Subject:   OSPF on gated

Hi,

I trying to implement OSPF using gated on a mesh network of 7 separate
LANs - each network has a Primary rate ISDN connection, this is 
connected to an Ascend access router, which allows us to individually 
dial every other network from this one ISDN connection - if we didnt have
the Ascend router, we would have 6 ISDN connections at each instead.

Anyway, the documentation on gated I find hard to understand, and I
cant find any examples of what I am trying to do.  I have a copy of
the O'Reilly book TCP/IP Network Administration with info on gated, but
their gated version doesnt have OSPF.

Can a kind soul point me to any documentation or books that would tell me
how to configure OSPF on gated?

Thanks in advance
Elena.
==============================
Elena Leong
System & Network Administrator
EDIPost Australia Post
==============================

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jul 94 10:36:51 PDT
From:      adar0@routers.com
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: routing on SunOS (with dp2.3) for remote PPP users?



> King Rhoton (king@acpub.duke.edu) wrote:
> > > I'm having trouble setting up cslip-2.7 on SunOS 4.1.3.  I can get
> > > the line to answer and go into SLIP mode, and my remote station
> > > (running Trumpet Winsock) can use TCP/IP to the host directly, but
> > > they can't see any hosts outside the local domain.  FTP, Mosaic,
> > > etc., just time out when they try to connect to a distant host.
> > >
> > > I think its something to do with routing, but I'm not sure.  How
> > > should routing be set up on the host to which SLIP users dial in?
> > >
> > > Routing tables
> > > Destination          Gateway              Flags    Refcnt Use        
 Interfa
> 
> ce
> > > localhost            localhost            UH       4      17440      lo0
> > > 199.123.192.10       parts                UH       1      33         sl0
> > > default              199.123.192.1        UG       3      6342       le0
> > > 199.123.192.0        parts                U        2      308        le0
> > >
> > > So, .10 can talk to parts and TCP/IP services on parts, and parts
> > > can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc.,
> > > but .10 can't talk to ftp.uu.net, etc.
 
> > I'm having the exact same problem, only with PPP connections instead of
> > slip.  I'm entirely baffled.  I've set up an arp entry for my remote
> > machine, and from the remote machine ping requests to non-dialup-hosts do
> > go through the PPP link (I see the tx led flicker), but I never get
> > anything back.  I have full access to the dialup host, though.  I've tried
> > both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and
> > they behave the same.  It's got to be something in the Sun's
> > configuration, but I'm out of ideas.  SunOS 4.1.3 and dp2.3pl2.
> 
>    Same problem here to.  We can reach host on the local net but nothing
> outside that.  Would gated or routed have to runn to allow these connections?
> Anybody got a tip?  Thanks!
> 

It sounds like all three of you have basically the same problem.  Its a
routing issue in that the Sun host has sufficient knowledge to know where
to send packets that are not destined for him.  The Sun learns about
connected or accessible networks either by being told by other systems
and routers via some routing protocols, or, by someone setting a "default
route" within the Sun to point to a system or router external to the Sun
that DOES know how to reach connected or accessible networks.  Either way
will work.

If the Sun is attached to an Ethernet network with other systems and
routers, you can add the '-s' option to the in.routed startup located
in /etc/rc.local file.  This will force the Sun to transmit and listen
to a routing protocol called RIP (the only routing protocol understood
by in.routed).  If your site does not use the RIP protocol, then your
choices are either to run gated or install static routes manually.  The
gated software understands other routing protocols, however in order for
you to have any chance at all in making it work, you need to know 
exactly what types of routing protocols your company uses.  Gated is not
easy to set up.

If the Sun connects to a terminal server, terminal servers sometimes have
parameters to turn on/off the transmission of RIP packets on the serial
line.  Most Internet providers will charge you to turn this software
function on.  When it is turned on, then the Sun will listen to the
RIP packets and build dynamic routing tables for you.

If you cannot make in.routed work, or, if your site does not support RIP,
then you will need to install a static default route on the Sun to at
least let the Sun know what to do with packets that are not his.  See
the Sun man pages for the exact syntax; it is something like:
	route add default [network] [gateway]

You can also experiment with other forms of static routes to force the
Sun to send all packets that are not his to a gateway (router) that does
know how to route your PC packets.

If you have arbitrarily picked an IP address and netmask for your PC's,
you might have someone that understands your site's network configuration
review these to be sure they are consistent with the overall network.
There are possibilities that picking wierd addresses and netmasks could
also cause the same syptoms.

Hope this helps some.  If you need more help, send an email with details
on all addresses, netmasks, backbone info, etc.
Rich Adamson
adar0@routers.com


-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 10:54:19 -0400
From:      lrogers@oasys.dt.navy.mil (Larry Rogers)
To:        comp.protocols.tcp-ip
Subject:   RIP-OSPF Conversion

Hi,

I am looking for a router that supports a 
RIP network on one interface and an OSPF 
network on a second interface.  The 
key is that the translation from OSPF to 
RIP must retain the advertisement of 
multiple subnets of a Class B. The RIP
OSPF to RIP conversion must not aggregate
the subnets into the larger Class B.
Example:

	RIP			OSPF

10.10.5.0 			10.10.5.0
10.10.6.0			10.10.6.0

NOT
10.10.0.0

If you know of a mainstream stand alone implementation
please let me know.

Larry

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 94 06:55:15 GMT
From:      yc23@uk.co.gec-mrc (Trevor Wright)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.networking
Subject:   Sun PC-NFS 5.1 License Violation Detection - Cisco setup problem?

Having installed the new 5.1 release of Sun PC-NFS, we immediately get
a License Violation Detection - with the indicated 'other' machine being
the one we are on. It seems Sun have changed the LVD broadcast from all
F's to xxx.xxx.xxx.255 where the x's are your local class C subnet - if
this is the way your net is formed.

Sun are being most helpful but at present we are the only customer with
the problem - everyone else is OK. There was one customer a while back -
who thought it was some problem with the setup of some Cisco routers,
leading to a reflection of the LVD broadcast packet. We can't get in
touch with him at present.

Would any users with knowledge of this problem please sound out. We will
publish the fix to the problem when found for the benefit of others.

Apart from this problem 5.1 looks fine.

Trevor Wright
Operations Manager
Computer Resources Dept.
-- 
Trevor Wright,Computer Resources | Tel: +44 245 473331 x 3224 + Answerphone
GEC-Marconi Research Centre      | Fax: +44 245 475244 or 478639
GEC-Marconi Ltd, Great Baddow    | uucp: <world>!uknet!gec-mrc!wright
Chelmsford,Essex. UK CM2 8HN     | Other: wright@gec-mrc.co.uk

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jul 1994 11:56:07
From:      kcroll@iac.net (Kenneth Croll)
To:        comp.protocols.tcp-ip
Subject:   tcpdump on sVr4?

Does anyone know if tcpdump will run on Unix sVr4?  I have collected the files 
to make tcpdump from the Internet, but the documentation only seems to refer 
to BSD flavors of Unix.  Since it comes from Lawrence Berkeley Labs I guess 
they favor BSD.  I thought I would ask if anyone had used this product on AT&T 
Unix before I took the time to compile and test this thing.

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 20:08:37 -0700
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Source Code

Edward Milczarek (edward@ece.concordia.ca) wrote:

: I would like to get the source code for the various TCP/IP
: functions. I would be grateful if someone can help me out.

Get a copy of one of the MANY free (or real cheap) Unixes out
there; FFreeBSD, Linux etc that come with source.


-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 20:13:47 -0700
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   ??NPI/TP0 Streams info??

I have the task of writing a streams module on Unix SVR4.2 to
host the NPI/TP0 interface to an OSI upper layer(s). 

Where can I get understandable DOC for the NPI etc interface??

Does anyone have sample, working NPI streams module (SVR4.2 or
any other ??) source??

Any help or advice.  Thanks...



-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 20:15:25 -0700
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   ??NPI/TP0 Streams Mod. Source??

I'm looking for a streams module that delivers NPI+TP0 for
hosting OSI upper layer services. 

The target is SVR4.2 or any SVR4.x.

Thanks.


-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 16:59:40 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip
Subject:   Just can't get TCP/IP Client-Server down...

I really need a person to sit with me and help me through this stuff with
TCP/IP.  The books I am reading assume I know what is going on, and I do not.
I need to implement a C/S prg, and I am stumped.  Notable questions:

My server program only needs to respond to one client, but there may be 
multiple copies of my server running.  I want all the servers to use the same
port, and all the clients could be on one machine.  Can they all use that port?
Or do they need to request a new port for all subsequent traffic from client,
so that more clients can talk on the original port number?

I want to use UNIX inetd server to run my code.  However, my server code needs
some parms to be passed to it.  Can I pass those through inetd somehow?

I am looking at ftpd explanations to help me understand this, but it isn't
easy.  For one thing, I just can't understand what inetd is doing.  I know it
listens on all the ports in the inetd.conf file, and does a select on all the 
socket handles, but that is as far as I get.  Let me explain:

Suppose inetd is running on machine A.  
A person at machine B wants to run ftp.  
Another person on machine B wants to run ftp.

The first ftp request comes in on port 21.  inetd select call comes out and
(I assume spawns a shell that runs ftpd, and maps the socket into stdin and
stdout) runs ftpd.  ftp and ftpd then open a new connection between ftp and
port 20.

Now, here is where I am stumped.  If they continue to use 21 and 20, wont
the inetd select call keep popping?  Does ftp and ftp allocate two new
sockets on the server end to use, which inetd is not listening on?

The next ftp request comes in.  I assume inetd is listening for it, but
if it is listening on the next ftp request, it must not be listening to the
old ftp request any longer.  How is that?  

I am stumped.  This is preceisely the scenario my server needs to operate,
and I am more confused as I go on.  
HELP.....



--
Jim Brain, Embedded Systems Designer, Brain Innovations.
brain@msen.com  
Dabbling in VR, Old Commodore Computers, and Good Times!
"The above views DO reflect my employer, since I am my employer" - Jim Brain


-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 17:29:39 -0400
From:      ezy@panix.com (Ezra Story)
To:        comp.protocols.tcp-ip
Subject:   Re: Just can't get TCP/IP Client-Server down...

In article <rN1CkmoZjGZJ064yn@msen.com>, Jim Brain <brain@mail.msen.com> wrote:
>
>The first ftp request comes in on port 21.  inetd select call comes out and
>(I assume spawns a shell that runs ftpd, and maps the socket into stdin and
>stdout) runs ftpd.  ftp and ftpd then open a new connection between ftp and
>port 20.
>
>Now, here is where I am stumped.  If they continue to use 21 and 20, wont
>the inetd select call keep popping?  Does ftp and ftp allocate two new
>sockets on the server end to use, which inetd is not listening on?

The key to all this is that sockets that are being used to listen for
connections are never used for the connections themselves.  Every time
accept() is called on the server socket (sitting at port 21, for example)
a -new- socket is created for that connection.

So, what inetd does, is open up a socket, bind it to port 21 and listen for
connections.  When a connection attempt comes in, it accept()s on that
socket, which creates a new socket that refers to the new connection..and
calls ftpd.  After the accept() the server socket (on port 21) is free to
accept more connections.


-- 
| Ezra Story | ezy@panix.com | Ezy (IRC) | *********************** |
| Penguins!  Get yer ice cold penguins here!  Free alien monster    |
| with every purchase!  Money back guarantee! | +++++++++++++++++++ |

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Jul 94 00:19:00 -0700
From:      philip.burton@spacebbs.com (Philip Burton)
To:        comp.protocols.tcp-ip
Subject:   PCs as IP routers

Does anyone have experience with PC-based TCP/IP packages that can do IP 
routing?  under DOS?  under Windows?  

What kind of machine is necessary for what level of performance?  Can I 
used a dusty old '286 with 1 MB RAM for a DOS-based router?  What about 
Windows?

Intuitively performance should be better under DOS than Windows?  Any 
experience here?

Which protocols are supported?  Any experience with a PC-based router 
talking to a Wellfleet or Cisco?

Thanks in advance.

Phil Burton

-- Phil Burton --    philip.burton@spacebbs.com
- Palo Alto, CA -
---
þ CMPQwk #1.4þ UNREGISTERED EVALUATION COPY

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jul 1994 12:54:43 GMT
From:      ccadda@beluga.upe.ac.za (Daryl Anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: "easy" bootp question

Helo,
You have hit the same problem as quite a few people.
I develope the NCSA code and have fixed BOOTP, amoungst other things.
You can mail me but I am finding support difficult when I uuencode
and send executables all around the globe.
I have feed back that it does not work, when in fact we use it on campus
for all our DOS Telnet/Ftp needs :-(.
Also my configuration files will be different to everone elses,
so thats another source of problems, although I have made the TCP/IP
kernel configuration file independant.

You can mail me or sit tight and wait for my announcement.
I have just set up an anonymous FTP site on campus, and will
make available my binaries and source.
I have Telnet working, ftpbin, finger and a few surprises :-).
Regards
Daryl

It is of course true that the older versions work.
Little functionality was added to the 2.3.07 release.  If you look at
the code it was more like disfunctionality.
This last comment was NOT meant to offend the official NCSA developer.
If it did, sorry Ryan.

>Ross Hayden (ross@ndlc.occ.uky.edu) wrote:
>| Hi all!
 
>| I have been struggling to get bootp working on several unix system here on
>| campus, with little luck.
 
>| I have several DOS pc's running NCSA telnet, along with the packet drivers
>| needed to run it on top of my netware drivers (ie odipkt.com).  On my unix
>| systems I've installed various versions of CMU's bootp package.  The
>| problem seems to be that replies from the server are never reaching the
>| workstations.  The bootp server starts on queue, and tcpdump also
>| indicates this and shows the reply being sent.  The pc, however, just sits
>| and continually resends requests as if never having received a reply.
 
>| If I hard code an IP address into the config file for NCSA telnet,
>| everything works ok.  Also, I can't get rarp to work either.  So I'm not
>| really sure if I need to examine my network setup, or if there's a problem
>| with NCSA telnet.  I've examined my network setup, checking out subnet
>| masks and broadcast addresses.
 
>| Any ideas on what to check here?  I'm stumped.
 
>| Thanks for any help,
>| Ross
>| --
>| Ross Hayden, Systems Programmer                   ross@ndlc.occ.uky.edu
>| The National Distance Learning Center
 
>I just helped somebody else with the same problem. It seems that
>NCSA-stuff V2.3.07 doesn't groc the bootpd answer. I'm running
>V2.3.03 (aka V2.3b) and I have no problems.
>-- 
> _____________________________________________________________________________
> Hans de Hartog, dehartog@comcons.nl, Voice: +31 348033100, Fax: +31 348033181
> Committed Consultancy BV, Korenmolenlaan 1b, 3447 GG Woerden, The Netherlands 
> Home: dehartog@kwetal.comcons.nl, Voice/Data: +31 838038560, CIS: 100121,3301

+--------------------------------------------------------------------+
 Daryl Anderson                     Internet: ccadda@beluga.upe.ac.za
 Network Consultant                      Tel: +27 41 5042321
 University of Port Elizabeth            Fax: +27 41 5042574

  "A program that works first time contains a more subtle bug" - DLS
+--------------------------------------------------------------------+

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 13:23:06 GMT
From:      tzs@u.washington.edu (Tim Smith)
To:        comp.protocols.tcp-ip
Subject:   IP address for a local network?

I'm going to be connecting a Mac and a PC together via ethernet.  They
will be the only things on the ethernet, and shall communicate via
TCP/IP.  If this were the end of the story, I would suppose that I
could just pick any IP addresses I wanted for these two machines (as long
as they match in the network portion of the address, of course).

However, there is a slight complication.  These machings aren't quite
isolated.  The Mac occassionally establishes a SLIP connection over a
modem to a commercial SLIP provider so that it can fetch news from an
NNTP server (and sometimes so I can FTP things).  When that connection
is established, it is given an IP address that is not fixed--I get a
different one each time I call.

In such an environment, how should I obtain IP addresses for use on my
ethernet?  Do I have to obtain an offical network number, or is there
something "safe" I can use?

--Tim Smith

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 15:07:08 GMT
From:      tzs@u.washington.edu (Tim Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address for a local network?

I wrote:
>I'm going to be connecting a Mac and a PC together via ethernet.  They
 ...
>However, there is a slight complication.  These machings aren't quite
>isolated.  The Mac occassionally establishes a SLIP connection over a
>modem to a commercial SLIP provider so that it can fetch news from an
 ...
>In such an environment, how should I obtain IP addresses for use on my
>ethernet?  Do I have to obtain an offical network number, or is there
>something "safe" I can use?

Based on email I've received, I seem to have left out something that is
important.  The Mac is running A/UX, and the PC will be running Linux or
FreeBSD when it is running TCP/IP.  The email I received pointed out that
I might have problems on the Mac because the IP software for the Mac OS
apparently does not like the idea of being connected to different networks
by different ports at the same time.  A/UX should have no problem in that
area.

--Tim Smith

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jul 94 16:37:19 GMT
From:      lff@sequent.com (Lou Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Re: Techniques for finding dead nodes in a WAN.

In article <30evqu$p56@access1.digex.net>,
S.Goutham <goutham@access1.digex.net> wrote:
>Can anyone point me in the right direction for constantly checking, say
>every 5 minutes, what nodes are down/up in a network. 

Since you mentioned WAN, I'll assume that you are talking about a
network in which the nodes are connected to each other through
point-to-point links.  

I suggest you have each node continuously verify that it can communicate
with each of its neighboring nodes and report a failure if it can't.  If
a single link fails, both nodes at its endpoints will report that it
failed.  If a node fails, all of the node's neighbors will report that
links to that node failed.  At the management system, analyze the link
failure reports to decide whether a node has failed or a link has
failed.

Note that if a node is connected to the rest of the network through only
one link, if communication stops, you can't tell whether the link failed
or the node failed.  However, this is true for any in-band management
strategy.

I would also have each node report its operational state to the
management system at a slow rate, say every few minutes.  This allows
you to catch failures where the node is keeping its links up but is
otherwise failing to do work.  You could also have the management
station poll each node periodically.  This would double the amount of
management traffic but would allow the management system to control the
rate.

Good luck,
...Lou
-- 
Louis F. Fernandez			Sequent Computer Systems
lfernandez@sequent.com			Beaverton, OR 97006-6063

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jul 1994 17:27:35 GMT
From:      bjork@telebit.com (Steven Bjork)
To:        comp.protocols.tcp-ip
Subject:   Re: TTL too small

In article <30m70e$l1d@gorgon.gatwick.Geco-Prakla.slb.com> swbarnes@slb.com writes:

>Sorry if this is a FAQ, but how does one talk to hosts which are more than
>30 hops away on the network?  Ping works but other Unix programs such as telne
 
>Simon Barnes

The current RFC specifies a ttl of 64, I think. On an earlier sunos
you had to adb vmunix and search for something like _tcp_ttl and
set it that way. Newer sunos does something different.

../Steven

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 18:24:38 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: TTL too small

Simon Barnes (swbarnes@slb.com) wrote:
: Sorry if this is a FAQ, but how does one talk to hosts which are
: more than 30 hops away on the network?  Ping works but other Unix
: programs such as telnet and sendmail either set the IP time-to-live
: to 30, or else allow it to default to 30.  It's not big enough!

It probably depends on which software you are running.

rick jones

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 17:38:36 +0100
From:      maral@csv.warwick.ac.uk (Mr A C Rocha)
To:        comp.protocols.tcp-ip
Subject:   FAQ ???


Can anybodu tell me where is the FAQ for this newsgroup please ??
Cheers,

andre

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1994 19:41:59 GMT
From:      parprods@ecn.uoknor.edu (Dorwin Shields)
To:        comp.protocols.tcp-ip
Subject:   Help with htons, htonl--problem with a sun

  Hi --I'm working on a distributed mandelbrot program--the 
program works using  stream sockets , and select between to linux pc's
and an alpha machine--but when I try to add a sun the program dies--it
seems that the sun gets garbled data--I read and write on the streams
using the read and write calls--do I need to use htonl and htons--if so
How?--I'm sending arrays of integers and doubles over the sockets--thanks
for any help--Dorwin

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jul 1994 20:28:22 GMT
From:      piercarl@sabi.demon.co.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing localnet <--> SLIP-provider?

>>> On 18 Jul 1994 21:09:44 +0100, dehartog@kwetal.comcons.nl (Hans de
Hartog) said:

Hans> My setup is as follows:

	[ ... a linux box with two interfaces: a slip one with
	an officially assigned number, and one on an ethernet with
	a bunch of PCs with "invented" numbers ... ]

Hans> However (and that's the problem), when the SLIP-connection exists,
Hans> I want the dos-pc's also be able to acces the Internet (at least
Hans> telnet).

You have two stark choices: never ever route at the TCP/IP level, and
keep the two interfaces isolated (I dearly hope that you are not running
with IP forwarding enabled), and use application level gateways, or
requesting an official class C network number, register your domain with
the DNS, and start IP forwarding between the slip and the ethernet
interfaces, having set up routing somehow (statically, as suggested in
another followup, or using gated).

If you go for application level gatewaying you need proxy daemons on the
Unix machine. Something like that is readily available from ftp.tis.com,
under /pub/firewalls, and several other places.

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 94 21:36:17 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: connect() and ECONNREFUSED

In article <1994Jul21.154408.3307@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes:

| > Case (3) is not one I've seen supported on typical BSD systems (at
| > least not intentionally :).  Can you be more specific?
| 
| You are right, this option is not typically found with BSD-based systems.
| (I must have been thinking of the RFC 793 OPEN, or the BSD UDP connect()
| scenario.)  Indeed, when looking at the table in my book I see the
| parenthetical note "normally not supported"!

Well, see, you should always carefully read your book before posting. :)
Seriously, what BSD system does implement this?  (There must be at least
one for it to make it into the table...)  It is a potentially useful
feature.

				Dan Lanciani
				ddl@harvard.*

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 1994 00:22:21 GMT
From:      masaru@lis.pitt.edu (Masaru Okuda)
To:        comp.protocols.tcp-ip
Subject:   [Q] Broadcast/Multicast

How does TCP react to a corrupted broadcast/multicast message? 
Does the source retransmit the message as a point-to-point addressing mode?
What would happen if tans of retransmission requests arrived?  

Masaru



-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Jul 1994 04:55:56 GMT
From:      ibottema@alkaid.sce.carleton.ca (Ike Bottema)
To:        comp.protocols.tcp-ip
Subject:   ICMP Subnet Mask Request/Reply

Can anyone confirm whether cisco and/or Wellfleet (or for that matter other
router vendors) will respond to a ICMP Subnet Mask Request with the proper
Subnet Mask Reply as specified in RFC 950?  I understand that many products
do not implement all ICMP messages.

Ike Bottema

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Jul 94 18:45:32 EST
From:      stein@gcomm.com
To:        comp.protocols.tcp-ip
Subject:   Ephemeral ports


Anyone know how one might use Berkeley Sockets API to determine a good
ephemeral port number to use before instigating the passive side of a
TCP connection?

This is required when implementing an FTP client to fill in the last 2
of the 6 parameters of the PORT command.  The client has to passively
listen() for the data connection that the server actively makes with
connect().  But the client is supposed to specify a "non-default data
port before each transfer command is used" (RFC 1123, Host Requirements,
4.1.2.5).

How does the client ask its API to cough up an ephemeral port number that
isn't currently in use, and that isn't in the TIME_WAIT state?

-- Bob Stein                            Internet mail: stein@gcomm.com
 ______________________________________________________________________
|                                                                      |
|  Galacticomm, Inc.                            (305) 583-5990 (voice) |
|  4101 SW 47 Avenue, Suite 101                 (305) 583-7846 (FAX)   |
|  Ft Lauderdale, Florida, USA, 33314           (305) 583-7808 (BBS)   |
|______________________________________________________________________|

--
==============================================================================
| ... The Galacticomm Demo System - 305/583-7808 - Home of The Major BBS ... |
==============================================================================


-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 1994 20:41:02 GMT
From:      darrell@cse.ucsc.edu (Darrell Long)
To:        comp.protocols.tcp-ip
Subject:   Mobile94 Workshop --- deadline 8/20

                        CALL FOR PARTICIPATION

        WORKSHOP ON MOBILE COMPUTING SYSTEMS AND APPLICATIONS

                          DECEMBER 8-9 1994
                      DREAM INN, SANTA CRUZ, CA

             Sponsored by the IEEE Computer Society TCOS
       (in cooperation with ACM SIGOPS and USENIX Association)



General Chair   Darrell Long, University of California, Santa Cruz

Program Chair   M. Satyanarayanan, Carnegie Mellon University

Exhibits        Peter Honeyman, University of Michigan

Finance & Registration
                Richard Golding, Hewlett-Packard

Publication     Luis-Felipe Cabrera, IBM Almaden

Program Committee
                Dan Duchamp, Columbia University
                Peter Honeyman, University of Michigan
                Randy Katz, UC Berkeley & ARPA
                Jay Kistler, DEC SRC
                Krishan Sabnani, AT&T Holmdel
                M. Satyanarayanan, Carnegie Mellon University
                Amal Shaheen, IBM Austin
                Marvin Theimer, Xerox PARC
                Rich Wolff, Bellcore


A major challenge of this decade is the effective exploitation of  two
symbiotic  technologies:  portable  computers  and  wireless networks.
Harnessing these technologies will dramatically change  the  computing
landscape.    But realizing the full potential of the resulting mobile
computing systems will require advances in many areas such as:

   hardware  communications   scalability      power management
   security  data access      user interfaces  location sensitivity

The goal of this workshop is to foster exchange  of  ideas  in  mobile
computing  among  workers in the field.  Attendance will be limited to
about  60  participants,  based  on  the  position  papers  submitted.
Submissions  should  be  fewer than 5 pages in length and may expose a
new problem,  advocate  a  specific  solution,  or  report  on  actual
experience.

In  addition,  we will be hosting a small number of novel hardware and
software exhibits relevant to mobile computing.  The exhibits  may  be
research prototypes or commercial products.  Interested parties should
submit technical descriptions of their exhibits.

Online copies of the  position  papers  will  be  made  available  via
anonymous  FTP  prior  to the workshop.  A printed proceedings will be
published after the workshop, and mailed to participants.

A small number of graduate students will be granted a  waiver  of  the
registration  fee.  In return, these students will be required to take
notes at the workshop and help put together the proceedings.  Students
who  wish  to  be  considered  for  the  waiver  must  send in a brief
description of their current  research,  and  an  explanation  of  how
participation in the workshop is likely to help them.

Send 10 copies of position papers to:

  M. Satyanarayanan           Email: satya@cs.cmu.edu
  School of Computer Science  Phone: (412)-268-3743
  Carnegie Mellon University  Fax:   (412)-681-5739
  Pittsburgh, PA 15213

Send exhibit descriptions to:

  Peter Honeyman              Email: honey@citi.umich.edu
  CITI                        Phone: (313)-763-4413
  University of Michigan      Fax:   (313)-763-4434
  Ann Arbor, MI 48103-4943


                           IMPORTANT DATES

       Submissions due               August 20 1994

       Acceptance Notification       October 1 1994

       Camera-ready copy due         November 15 1994

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1994 07:01:36 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Interconnction 2 LANs using 2 leased lines ?

In article <30nckh$ett@dopey.cs.nyu.edu> m-sm0088@cs.nyu.edu (Srinivasu
Mandava) writes: 
            I need to interconnect 2 LANS using leased line and a pair of
            routers on either end. As a backup I plan to use 2 such pairs.
            I.e 2 routers  on each LAN even though mean time between failures
            of a router is reasonably high.
    
            Are there any routers in the market which can do the following:
            1. When both the lines are functional share the load i.e when
            both the lines are up the through put should be double that of
            a single line.
            2. Interconnection should be maintained even if a line or
            a router is down.
    
            If I cannot achieve (1) , (2) is essential.
    
Almost all routers on the market today can do (2).  Today, the problem is
finding hosts which are smart enough to figure out that their router died.
(1) is challenging because half of the hosts have to know to use each line.

Assuming that you have dumb hosts, and don't mind your packets taking an
extra LAN hop, you can do a credible job of approximating this by
designating one of the two routers as the "lead" router and having all
hosts prefer the lead router.  Next, play with your routing protocol
metrics so that both paths look to be equal cost _to the lead router_.

Tony

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1994 07:05:00 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Subnet Mask Request/Reply

In article <ibottema.774939356@alkaid.sce.carleton.ca>
ibottema@alkaid.sce.carleton.ca (Ike Bottema) writes: 
    Can anyone confirm whether cisco and/or Wellfleet (or for that matter other
    router vendors) will respond to a ICMP Subnet Mask Request with the proper
    Subnet Mask Reply as specified in RFC 950?  I understand that many products
    do not implement all ICMP messages.
    
cisco routers can respond with an ICMP Mask reply.  However, ICMP mask
replies are pretty dangerous and are disabled by default.  You need to
configure "ip mask-reply" on the interface to enable this feature.

Tony

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1994 11:39:56 GMT
From:      sager@asys-h.de (Peter Sager)
To:        comp.protocols.tcp-ip
Subject:   Re: Just can't get TCP/IP Client-Server down...


The secret is that there is a difference between the LISTEN socket,
on which inetd is doing the SELECT, and which is bound to port 21
on the server machine, and the socket for the ftp control connection.
Every time a new connect-request comes in from a client, the TCP/IP
software on the server creates a new socket which is at this time
already connected to the foreign socket of the client, and puts it
onto the QUEUE OF INCOMING CONNECTIONS of the LISTEN socket.
The inetd process is notified of the new connection by means of
the select system call ("Something ready to read on the LISTEN socket")
Inetd then fetches the next incoming connection from the queue with
ACCEPT. Depending on the LISTEN socket, inetd recognizes "This is for ftpd"
from its configuration tables, and forks the ftpd process, handing the
socket fd of the CONNECTED socket over to the daemon on stdin/out.

But how can the system handle two sockets with identical local port number ?
The answer is, there can be more than one socket be associated with the same local port, provided that they can be distinguished by their foreign address/port.
Every incoming UDP or TCP-Packet carries its source address/port as well
as a destination address/port. Every socket also has a local address/port
(This is the one you gave the LISTEN socket with bind) AND a foreign address/port, if
it is connected. This way the system is able to find out the right socket
for incoming packets.

The actual mechanisms are more complicated, but from the API user's
view this info should be sufficient.

More info can be found in the books of 

   Douglas Comer                          Internet Networking with TCP/IP
   Leffler/McKusick/Karels/Quarterman     The Design and Implementation of
       the 4.3BSD UNIX Operating System

and of course in the sources of the NETBSD distribution.

o-----------------------------------------------------------o
|   Peter Sager                     sager@asys-h.de         |
|   Advanced Systems Software GmbH                          |
|   Vahrenwalder Strasse 7          VOICE: +49 511 9357390  |
|   D-30165 Hannover                FAX:   +49 511 9357100  |
o-----------------------------------------------------------o







-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Jul 1994 14:28:05 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Ephemeral ports

> How does the client ask its API to cough up an ephemeral port number that
> isn't currently in use, and that isn't in the TIME_WAIT state?

bind() a port number of 0.  If you then want to know the ephemeral
port that was assigned, call getsockname().

	Rich Stevens

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1994 17:01:08 GMT
From:      Fernando Madruga
To:        comp.protocols.tcp-ip
Subject:   1:Winsock.H->Pascal; 2:Telnet Startup Codes

Hi!
  I have two questions; if U have 1 or 2 answers, jump in.
  I'm starting to work with WinSock and I've managed to
make a small Telnet program, in less than an hour after
spending some 6 hours converting WINSOCK.H to a suitable
Borland Pascal Unit.

Q1: What are the sizes for C data types? What is the
    difference between 'short integer' and 'integer' ?
    I think their the same, but in some places it seems
    more suitable to use a 'word' (unsigned integer) for
    short integer...
Q2: When I logged into my account on a UNIX machine with
    my fresh new Telnet program, I wasn't able to comunicate
    with it, unless I sent the ascii codes 255, 252, 24 in
    response to the 255, 253, 24 that I got on from the machine
    on startup. The UNIX machine then sent me a few more 
    sequences of three byte codes started with 255, and I was
    able to communicate! Q: Where can I find more information
    about these codes?

  Email to a friends account: rupino@mercurio.uc.pt

TKS,
  Fernando Madruga


-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Jul 1994 20:36:41 GMT
From:      aboba@netcom.com (Bernard Aboba)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,alt.winsock,comp.os.ms-windows.networking.tcp-ip,comp.answers,news.answers
Subject:   comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 1 of 3

Archive-name: ibmpc-tcp-ip-faq/part1

comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 1, 8/1/94

#################  Legalese #################

This document is Copyright (C) 1993,1994 by Bernard Aboba, except where 
the copyright is retained by the original author(s). This document
may be distributed non-commercially, provided that it is not
modified in any way. However, no part of this publication may be 
sold or packaged with a product for sale in any form without the 
prior written permission of Bernard Aboba. 

This FAQ is presented with no warranties or guarantees of ANY KIND
including correctness or fitness for any particular purpose. The
author(s) of this document have attempted to verify correctness of the
data contained herein; however, slip-ups can and do happen.  If you use
this data, you do so at your own risk. While we make every effort to
keep this FAQ up to date, we cannot guarantee that it is, and we will
not be responsible for any damages resulting from the use of the information
or software referred to herein. 

Unless otherwise stated, the views expressed herein are my own.  Last
time I looked, I had not been appointed official spokesperson of any
of the following:

	The Planet Earth
	The U.S.Government
	The State of California (not so good)
	The University of California, Berkeley
	The City of Berkeley (bringing you Riot of the Week(SM))
        Addison-Wesley
        Publisher's Group West
	Any major or minor breakfast cereal (not even oatmeal!)
	
This FAQ will be posted monthly. In between it will be
available as: 
file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip

################# HTML version goes online #################

This FAQ is now fully HTML compatible, and is
being automatically converted to HTML. 
This means that if you have a WWW browser, 
you can read the FAQ online, and click on links 
to download individual files. 

This is how I read the FAQ myself, and it is
highly recommended. To get at the HTML
version, use:
http://www.zilker.net/users/internaut/forth.html#upd

################# Citation entry  #################

This FAQ may be cited as:

  Aboba, Bernard D.(1994) "comp.protocols.tcp-ip.ibmpc Frequently
  Asked Questions (FAQ)" Usenet news.answers, available via 
  file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip, 
  57 pages.

################# Change History  #################

Changes from 7/1/93 posting:
FAQ now available in HTML format. Entries
changed in last two FAQs sport a *. 
 

################# Related FAQs #################

There is a FAQ available on features of TCP/IP
Packages for DOS and Windows. This is available at:
file://ftp.cac.psu.edu/pub/dos/info/tcpip.packages. 

The Windows Sockets Faq is posted to alt.winsock, and
is available at:
ftp://SunSite.UNC.EDU/pub/micro/pc-stuff/ms-windows/winsock/FAQ

The PC-NFS FAQ is available at:
file://seagull.rtd.com/pub/tcpip/pcnfs.FAQ.v1.4.Z or pcnfsfaq.zip
file://ftp.york.ac.uk/pub/FAQ/pcnfs.FAQ

The SNMP FAQ is regularly posted to comp.protocols.snmp

The TCP/IP FAQ is posted to comp.protocols.tcp-ip, and is
maintained by mailto:gnn@netcom.com. 

The "How To Get It" FAQ on the Crynwr packet driver 
collection is irregularly posted to comp.protocols.tcp-ip.ibmpc
by Russ Nelson, mailto:nelson@crynwr.com. 


################# Book info  #################

A bunch of you have requested information on the
book I am working on.  Here is the basic info:

Title: The PC-Internet Connection, TCP/IP
Networking for DOS and Windows
Authors: Bernard Aboba and Britt Bassett
Pages: 800 (estimated), 7" by 9"
Distributor: Publisher's Group West
ISBN: 1-883979-00-5
Price: $32.95 (est), includes Chameleon Sampler
software, WS-Gopher, PC-Eudora. 
Estimated release: October, 1994

To look at sample chapters from the book, check out
the following WWW page:  
http://www.zilker.net/users/internaut/forth.html

For those of in North America who *must* have 
a look at the book before it comes out, and are 
willing to comment on it, send me $25 to cover 
copying and postage, and I'll send you a copy. 
If you send back comments, I'll return the $25.
Since this is a big book, be prepared to spend 
some time looking at it.    

For those outside North America, sorry but we're on
a tight deadline, and so we will not be able to
include you. 


################# EXAMPLE CONFIG FILES  #################

Many thanks to Dave Fetrow (fetrow@biostat.washington.edu)
for creating an archive of setup files. The archive is 
particularly oriented toward sets of applications that 
are somewhat tricky, such as combinations involving 
different driver sets, mixtures of NetWare, TCP/IP, 
and W4WG, etc. 

Please include not only the setup and configuration files
but some directions. Comments included with the setup files
are highly desirable. The files can include your name if you
desire. 

Please mail submissions to ftp@ftp.biostat.washington.edu. 

The archive itself is located at:
ftp://ftp.biostat.washington.edu/ftp/pub/msdos/network.setups 

Late breaking development: the archive has crashed, and 
files have been lost. 



TABLE OF CONTENTS

A. Components of a TCP/IP solution

A-1. What do I need to run TCP/IP on the PC?
A-2. What are packet drivers?  Where do I get them?
A-3. What is Winsock?  Where can I get it? 
A-4. What is Trumpet Winsock? How do I get it to dial? 
A-5. What publicly distributable TCP/IP applications are there
     for DOS?  Windows?
A-6. What software is available for doing SLIP?  Compressed SLIP?
     PPP?  For DOS?  For Windows?
A-7. What about the software included with various books? 
A-8. What diagnostic utilities are available to find problems with
     my connection?  Where can I get them?
A-9. Is there a CD-ROM with the software included in this FAQ? 
A-10. Does Windows NT support SLIP? PPP? 
A-11. Where can I take a peak at the WFW v3.11 VxD beta?
A-12. How do I get my BBS to run over TCP/IP? 
A-13. Are there graphical TCP/IP servers out there?
A-14. What methods of dynamic address assignment are available?
A-15. How can I set up PPP server on a UNIX host? 
A-16. What is WinSNMP? 

B. Questions about drivers

B-1. What do I need to know before setting up SLIP or PPP?
B-2. How do I configure SLIPDISK?
B-3. How do I install packet drivers for Windows applications?
B-4. When do I need to install  WINPKT? 
B-5. How to do I run both WinQVT and ODI?
B-6. Is it possible to use BOOTP over SLIP?
B-7. How do SLIP drivers work? 
B-8. When do I need to install PKTMUX?
B-9. Can NDIS be used underneath multiple protocol stacks of the same type?
B-10. Is there an NDIS over packet driver shim? 
B-11. How do I run NetBIOS over TCP/IP? 
B-12. How do I run NFS and another TCP/IP application?
B-13. How do I run Trumpet Winsock along with KA9Q or NFS? 
B-14. Sample Stick Diagrams
B-15. Strange and wonderful configuration files submitted by readers

C. KA9Q Questions

C-1.  What version of KA9Q should I use and where do I get it?
C-2.  What do I need to run KA9Q? Why won't it do VT-100 emulation?
C-3.  How do I configure KA9Q as a SLIP dialup connection?
C-4.  How do I configure KA9Q as a router?
C-5.  How do I get KA9Q to support BOOTP?
C-6.  How do I get KA9Q to support PPP?
C-7.  How do I get KA9Q to support SLIP dialin?
C-8.  Can I use KA9Q as a packet filter? 


D. Hints for particular packages

D-1. How do I get DesQView X to run over the network?
D-2. Why is NFS so slow compared with FTP?
D-3. Where can I get information on running NetWare and TCP/IP
      concurrently? 
D-4. What NetWare TCP/IP NLMs are out there and how do I get them
      to work? 
D-5. How do I get a telecom package supporting Int 14h redirection
      to work? 
D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP?
D-7. How do I get Windows For Workgroups to work alongside NetWare?
D-9. How come package X doesn't support the AppleTalk packet driver?
D-10. NCSA Telnet doesn't reassemble fragments. What should I do?


E. Information for developers

E-1. What publicly distributable TCP/IP stacks are there that I can
     use to develop my own applications?
E-2. Where can I get a copy of the Windows Sockets FAQ?


--------------------- FAQ Begins Here ---------------------------

A. Components of a TCP/IP solution

A-1. What do I need to run TCP/IP on the PC?

To run TCP/IP on the PC you will need:

* Appropriate hardware, such as:

    Ethernet card
    Token Ring card
    AppleTalk card
    Serial Port
   

  Any other network card with a packet driver or NDIS or ODI driver,
  (such as Arcnet), will also work.  If your card supports NetBIOS,
  this is also acceptable, since you can run a packet-driver-over-
  NetBIOS shim.

* Drivers for your hardware.

  Your card probably came with one or more of the following drivers:
 
    Network Device Interface Specification (NDIS) drivers
      [spec. by 3Com and Microsoft, used by LAN Manager, Windows
      for Workgroups, and Windows NT. LAN Manager uses NDIS 2.0,
      Windows NT uses 3.0, and WFW supports 2.0 and will support 
      3.0]
    ODI Drivers [spec. by Novell, abbreviation for Open DataLink
      Interface]
    Packet Drivers [spec. by FTP Software]
   
  TCP/IP stacks have been written for each of these driver interfaces, 
  so the important thing is whether your chosen stack is compatible 
  with the interface available for your card.
 
  A shim is software that runs on top of one set of drivers to
  provide an interface equivalent to another set. This is useful,
  for example,if you are looking to run software requiring an
  NDIS driver(such as Chameleon NFS) alongside software
  requiring a packet driver interface (such as KA9Q, Gopher, Popmail,
  NCSA Telnet, etc.), or run software intended for, say, a packet
  driver over an NDIS driver instead.
 
  Shims are available to run packet drivers over NetBIOS, ODI,
  or NDIS, in order to run software expecting a packet driver over
  NDIS, ODI, or NetBIOS instead. There are also shims to run NDIS
  over ODI (ODINSUP), and ODI over Packet Drivers (PDETHER). 


* A TCP/IP protocol stack.

  The TCP/IP protocol stack runs on top of the driver software, and
  uses it to access your hardware. If you are running a TCP/IP
  protocol stack that requires drivers that aren't available for your
  hardware, you're in trouble. Check into this before purchasing!
 

* If running Windows applications that require it, WINSOCK.DLL. 


  Windows Sockets is a sockets interface which was created as a 
  Windows DLL. Each  TCP/IP implementation requires its own version 
  of Windows Sockets. Trumpet Winsock and VxDTCP are the only
  two publicly distributable Windows Sockets implementations. 
  WINSOCK.DLL provides 16-bit support; WSOCK32.DLL provides 32-bit support. 

   
* Applications software.

  Although most of us in this newsgroup seem to spend our time
  looking for working combinations of applications,WINSOCK.DLLs,
  Windows Sockets compliant TCP/IP implementations, shims, 
  drivers, and hardware, ultimately your goal is eventually to 
  run an application successfully. If and when that happens, 
  please send me a note, so I can add it to this FAQ.


A-2. What are packet drivers?  Where do I get them?

Packet drivers provide a software interface that is independent of the  
interface card you are using, but NOT independent of the particular 
network technology. As Frances K. Selkirk (fks@vaxeline.ftp.com) notes:

"That's one reason they're easier to write than ODI drivers! If you
write a class three (802.5 Token Ring) driver, you will need to use
software that expects a class three driver, not software that expects
a class 1 (DIX ethernet) driver. There are a few drivers that fake class 1. 

I believe only class 1 and class 6 (SLIP) drivers are supported by 
freeware packages."

The chances are fair that your Ethernet card came with a packet
driver, and if so, you should try that first. If not, then you
can try one of the drivers from the Crynwr collection (formerly
called the Clarkson Drivers). See the Resource listing for info.

For 3COM drivers, try ftp ftp.3com.com. For technical information,
try info@3com.com. For marketing and product info, try
leads@hq.3mail.3com.com.The packet driver specification is available
from vax.ftp.com in packet-d.ascii

The following vendors have packet drivers with source available for
their pocket lan adaptors:

D-Link - +1-714-455-1688
Solectek - +1-619-450-1220
Accton - +1-415-266-9800
Compulan - +1-408-922-6888
(soon Kodiak's Noteport - +1-408-441-6900)

You can obtain a complete library of packet drivers from many of the
Simtel20 mirror sites, including:
file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip, 
file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip. 


A-3. What is Windows Sockets?  Where can I get it?

  The idea for Windows Sockets was born at Fall Interop '91, during a
  Birds of a Feather session.  

  From the Windows Sockets specification:
  [courtesy of Mark Towfiq, mailto:towfiq@Microdyne.COM]:
 

    The Windows Sockets Specification is intended to provide a
    single API to which application developers can program and
    multiple network software vendors can conform. Furthermore, in
    the context of a particular version of Microsoft Windows, it
    defines a binary interface (ABI) such that an application
    written to the Windows Sockets API can work with a conformant
    protocol implementation from any network software vendor.

Windows Sockets will be supported by Windows, Windows for Workgroups,
Win32s, and Windows NT. It will also support protocols other than TCP/IP.
Under Windows NT, Microsoft will provides Windows Sockets support over
TCP/IP and IPX/SPX. DEC will be implementing DECNet. Windows NT will 
include mechanisms for multiple protocol support in Windows Sockets, 
both 32-bit and 16-bit.

Mark Towfiq writes:

    "Files and information related to the Windows Sockets API are
     available via ftp://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock, 
     which is a mirror of /pub/winsock on Microdyne.COM (SunSite has a much
     faster connection to the Internet, so you are advised to use
     that).

     If you do not have FTP access to the Internet, send a message
     with the word "help" in the body to either
     mailto:ftpmail@SunSite.UNC.Edu, or mailto:ftpmail@DECWRL.DEC.Com, to obtain
     information about the FTP to Mail service there."
 
  Alternative sources for the Windows Sockets specification include
  rhino.microsoft.com (an FTP server running NT), as well as the
  Microsoft forum on CompuServe (go msl).
  
  Currently NetManage (NEWT), Distinct, Spry, FTP and Frontier are shipping
  Winsock TCP/IP stacks, as is Microsoft (Windows NT and TCP/IP for
  WFW), Beame & Whiteside Software (v1.1 compliant), and Sun PC-NFS. 
  If you are looking for a Winsock.dll, you should first contact your TCP/IP
  stack vendor. Novell has one in beta for their Lan Workplace for DOS.

A-4 What is Trumpet Winsock? How can I get it to dial? 

Peter Tattam has released a shareware Windows Sockets compliant
  TCP/IP stack. You can obtain it via    
  file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip, 
  file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zipwinapps.zip, or
  file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winsock.zip.   
  
The first thing to do after you download WINSOCK.ZIP is to create
a directory for Trumpet Winsock, such as C:/TRUMPWSK, and put it
in your DOS PATH statement. 

Trumpet Winsock operates over packet drivers, or over a serial port
using its own built-in SLIP/CSLIP. If you are using a network
adapter, this means that you will have to locate a packet driver
for your adapter, and load it. Trumpet Winsock also comes with 
WINPKT, and this is loaded next, via the command
WINPKT.COM 0x60 [or whatever the software interrupt for your packet driver]

You will then enter Windows, and create a group in the Program Manager
for all the files that come with Trumpet Winsock. The stack itself is loaded
by executing TCPMAN. Applications that come with it include WinCHAT, 
a chatting program; PINGW, a ping utility; FTPW for FTP, WINARCH for Archie. 

When you first execute TCPMAN, you will be asked to fill out the setup 
information for the stack. Select whether you will be using a network
adapter or SLIP; you cannot use both. 

Since Trumpet Winsock does not yet support PPP, you will need to load the
EtherPPP driver and WINPKT prior to running Windows. EtherPPP is available via
file://merit.edu/pub/ppp/etherppp.zip. This is an Ethernet simulation driver, so you
will configure Trumpet Winsock as though it were running over an Ethernet
Packet driver, i.e. by loading WINPKT 0x60, and setting the packet driver
vector in TCPMAN to 60. 

EtherPPP comes with its own dialer, so you will need to create a dialing script.
If your TCP/IP address will be changing, you will also need to write a little
batch script to capture the assigned IP address, and insert it into Trumpet's
initialization file.  EtherPPP takes up too much RAM (121K), but otherwise
works fine.  

If for some reason you don't like Trumpet Winsock's scripting language, 
you can use any other comm program that doesn't drop carrier on exit, or 
the DIALER program, available via: 

file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip. 

As for Trumpet Winsock's built-in scripting language, the default dialout
script is LOGIN.CMD. A sample LOGIN.CMD file from Geoff Cox (mailto:geoff@satro.demon.co.uk):

#
# initialize modem
#
output atzm0\13
input 10 OK
#
# set modem to indicate DCD
#
output at&d2&c1\13
input 10 OK\n
#
# send phone number
#
output atdt0813434848\r
#
# my other number
#
#output atdt241644\13
#
# now we are connected.
#
#input 30 CONNECT
#
#  wait till it's safe to send because some modem's hang up
#  if you transmit during the connection phase
#
#wait 30 dcd
#
# now prod the terminal server
#
#output \13
#
#  wait for the username prompt
#
input 30 ogin:
username Enter your username
output \satro\r
#
# and the password
#
input 30 assword:
password Enter your password
output \my password\r
#
# we are now logged in
#
input 30 otocol:
#
# see who on for informational reasons.
#
output SLIP\r
input 30 HELLO


A-5. What publicly distributable TCP/IP applications are there for
     DOS?  Windows?

Right now there are a wealth of publicly distributable TCP/IP
applications running under DOS.  Windows also has a wealth of 
programs available, including implementations of Gopher, Mail
(POP3/SMTP), FSP, Mosaic, Telnet, FTP, IRC, and WAIS. 

See the Resource listings for information.


A-6. What software is available for doing SLIP?  Compressed SLIP?
     PPP?  For DOS?  For Windows?  For OS/2?

For SLIP or CSLIP use with DOS, I recommend using SLIPPER or CSLIPPER. 
These are packet drivers that can be used along with a dialer. For PPP, 
I recommend the EtherPPP packet driver described above.  

There is a special version of NCSA Telnet for PPP, available from
ftp://merit.edu/pub/ppp. 

KA9Q supports SLIP/CSLIP, but unfortunately can not be used as a
TCP/IP protocol stack to run other apps.

I have heard good things about IBM's TCP/IP for OS/2, but haven't
used it msyelf. Please see the FAQ from news:comp.os.os2.networking for details.

IBM, FTP Software, Beame & Whiteside, Frontier, SPRY and Netmanage also 
offer SLIP support in their products. See the resource listings for details.  


A-7. What about the software included with various books?

The software included with various books (including mine) is usually
Chameleon Sampler from NetManage. Sampler supports SLIP/CSLIP/PPP, but
not connection over a network, and includes software for FTP, Telnet,
TN3270, and Mail. The stack included with Sampler (NEWT) is Winsock
compatible, so you can run any Windows Sockets-compatible application
over it. Installation is quite a bit simpler compared with going the
Trumpet Winsock route, so this is probably the best way to go assuming
that you are a dialup IP user. 


A-8. What diagnostic utilities are available to find problems with
my connection?  Where can I get them?

Frequently used diagnostic utilities include ifconfig (checks the
configuration of the network interfaces), ping (tests IP layer
connectivity), traceroute (traces the route that a packet takes
between two sites), netstat (checks the routing table), tcpdump
(protocol analyzer), arp (looks at the IP to Ethernet address
mappings).

KA9Q includes ifconfig, ping and traceroute functions. In KA9Q hop
check is the equivalent of traceroute. The Trumpet TCP/IP stack also
has a hopchk2 command that is a traceroute equivalent.

Etherload is very useful for network profiling, while Etherdump can
be used for packet catching, although I wish it would give more
information, along the lines of TCPDUMP.  

Trumpet Winsock comes with Windows implementations of Ping and Traceroute. 

A-9. Is there a CD-ROM with the software included in this FAQ?

The Packet Driver, WinSock & TCP/IP CD-ROM is available from
CDPublishing for $29.95. This includes the packet drivers of course,
but also lots of other DOS and Windows TCP/IP stuff, including
Windows Sockets applications. It also includes the text of all
the RFCs. This is now somewhat out of date (it was cut in
December), but is otherwise highly recommended. 

CDPublishing, (604)874-1430, (800)333-7565, fax: (604)874-1431,
mailto:info@CDPublishing.com, ftp://ftp.CDPublishing.com/,
Gopher site: gopher://gopher.CDPublishing.com/, WWW: http://www.CDPublishing.com/

A-10. Does Windows NT support SLIP? PPP? 

The "Daytona" release of Windows NT will include support for 
PPP (client and server) and SLIP (client), both including
support for Van Jacobson header compression. 

A-11. Where can I take a peak at the WFW v3.11 VxD beta?

This is a beta release of the forthcoming 32 bit-TCP/IP stack for 
Windows for Workgroups v3.11. This is looking *very* good; it's
fast, and has worked fine for me. It also supports a host of very
nice new features, including DHCP automatic configuration, WINS
name resolution, and Windows Sockets v1.1. However, plesae not that
it does not offer SLIP or PPP support. 
The final beta release is now available via:
ftp://ftp.microsoft.com/PerOpSys/WFW/tcpip/ 


A-12. How do I get my BBS to run over TCP/IP? 

First off, let's clarify what we mean by "over TCP/IP." Usually
this means "accessible via Telnet." Be aware that doing this will
not necessarily work well, since few BBSes have been tested running
over TCP/IP. As a result you may experience frequent crashes, or
abominable transfer rates. For example, I have seen transfer rates 
as low as 100 characters/second over a 14.4 Kbps PPP connection 
which routinely supports 1600 cps transfers with FTP.

This situation might be improved by running an FTP server instead. 
This could be accomplished for example by running KA9Q in another
window under DesQView, or by putting the files on an NFS-mounted
drive, then using another machine as the FTP server. 

One way to hook up a multi-line BBS is to use a terminal server, 
and hook up the BBS's serial ports to that. The disadvantage of this is that
if your BBS is really big you will need multiple terminal servers
which will each have their own domain names and TCP/IP addresses. 
Confusing. 

Brian Clements of Murkworks has a better solution, called BBSnet. 
It provides a Telnet interface that looks like a FOSSIL driver.  The first
version runs partly as an NLM; some of the code resides on the server.
For info, contact 

BBSnet,MurkWorks, Inc., P.O. Box 631,Potsdam, NY 13676, 
+1 315 265 4717, mailto:info@MurkWorks.com

eSoft has also recently announced that they are working on a TCP/IP
compatible version of TBBS. Look for this to be shown at OneBBS
Con '94 in Atlanta. 

A-13. Are there graphical servers out there?

Yes! For Windows there is a graphical SMTP daemon which is not very
functional (it can't do as much as KA9Q); several Web servers, including
a Windows version of NCSA's HTTP, and SerWeb. 

For Windows NT, The European Microsoft Windows Academic Consortium (EMWAC) has
released Windows NT servers for Gopher, WAIS, and WWW. These servers
are easy to install, and fast, and offer the full complement of capabilities,
including support for forms, access to WAIS indices from within HTTPS, 
installation as a Windows NT service, etc. 

See the resource section for details.

A-14. What methods of address assignment are available?

Methods of address assignment include client/server protocols
(RARP, BOOTP, DHCP), as well as script-based methods 
(terminal server indicates, "your address is 192.187.147.2"). PPP
supports assignment of addresses from the server. 

As part 2 of this FAQ discusses, there are RARP and BOOTP clients
and servers available for DOS. Typically the clients work by stashing
the IP address in a DOS environmental variable. It is then your responsibility 
to modify the appropriate config files to reflect this 
address. This can be done using a DOS batch script and a utility such as 
DOS awk. This same approach can be used to modify config files when using
EtherPPP; this does not place the IP address into a variable, but the output
of EtherPPP can be piped to a file and the IP address picked off and inserted 
in the appropriate locations. If this sounds complicated, it is; be warned.

Trumpet Winsock supports script-based assignment of addresses. Microsoft 
supports a DHCP client in WFW TCP/IP, and both client and server in Windows NT. 
There is also a forthcoming DHCP server for Sun. 

A-15. How can I set up PPP server on a UNIX host? 

This is not the appropriate place to address that question, but lots
of info on this is available in the comp.protocols.ppp FAQ. 

A-16. What is WinSNMP? 

WinSNMP is an API which provides a standard interface to to the
Simple Network Management Protocol (SNMP) for network
management applications running under Windows. Applications written to 
WinSNMP can run on any WinSNMP-compatible implementation. 

Vendors supporting WinSNMP include FTP Software, which supports it
in both OnNet 1.1, and PC/TCP 3.0. 

B. Questions about drivers

B-1. What do I need to know before setting up SLIP or PPP?

Before setting up your SLIP or PPP connection, you should
have available the following information:

* The domain name and TCP/IP address of your host.
* Whether your TCP/IP address will be assigned statically,
  dynamically, or from the server.
* If from the server, whether you will be using RARP, BOOTP or DHCP. 
* The domain name and TCP/IP address of your machine (if you are not
  configuring the address dynamically or via BOOTP)
* The domain name and TCP/IP address of the primary and secondary
  Domain Name Server.
* The subnet mask.
* The domain name and TCP/IP address of an NNTP server.
* Whether your host supports POP, and if so, what version.
* Whether the host supports compressed or uncompressed SLIP, or PPP.
* The size of the Maximum Receivable Unit (MRU). 


Do not attempt to connect to your host before you have this
information, since it will just waste your time and money, and may
cause problems for the network.  In particular, do not attempt to
initiate a connection using a made up TCP/IP address! It is possible
that your made-up address may conflict with an existing address.  

This is probably the quickest way to get people very angry at you.

Static addressing means that your TCP/IP address will always
be the same. This makes it easy to configure your setup files.
Dynamic addressing means that the host will send you a message
containing your TCP/IP address when you log on. This can be
problematic if your software doesn't support grabbing the address
and inserting it into the setup files. If not, then you may have
to edit your setup files every time you log on. Yuck!

Chameleon NFS includes a version of SLIP which can handle dynamic
addressing. The most recent version of Novell's Lan Workplace for
DOS does as well. 

You can also retrieve your address using RARP, BOOTP or DHCP. RARP
is only available to those on the same LAN as the RARP server, since
it uses broadcasting. BOOTP clients can access BOOTP servers on other
LANs via BOOTP relay. DHCP is a BOOTP extension, which allows
complete configuration of a client from info stored on a DHCP server, and in
addition supports new concepts such as "address leases". Since
DHCP frames are very similar to BOOTP frames, devices supporting BOOTP relay 
will also support DHCP relay. 

Of course, for DHCP or BOOTP to work, you will need to set up a DHCP
or BOOTP server. DHCP servers are available for UNIX, and Windows NT.

PPP also supports server assignment of TCP/IP addresses.


B-2. How do I configure SLIPDIAL?


From Ashok Aiyar, mailto:ashok@biochemistry.bioc.cwru.edu:

PHONE Script Files:

PHONE comes with several scripts (for various modems) and for the
University of Minnesota Terminal server built into it.  The command
PHONE WRITE writes these scripts to an ASCII file called PHONE.CMD,
which can be edited to your needs (modem and slip server)

The documentation that accompanies PHONE, provides good instructions on
writing script files to get PHONE to dial SLIP servers other than
the University of Minnesota server.  For example here is a script
that I use to dial a CISCO server at the University that I attend.

Background:  To start a SLIP connection, I dial our terminal server,
and login with a username and password.  After doing so, I start a SLIP
session with the following command "slip username-slip.dialin.cwru.edu",
followed by my password -- again.

Here then is the relevant portion of the PHONE.CMD script file -
#
# CWRU-TS2 SLIP login script by Ashok Aiyar 3/26/93
# Last revised 3/28/93
Procedure    Host.CWRU.Login
TimeOut 60      'CWRU-TS2 terminal server is not responding'
Message         "CWRU-TS2 SLIP login script -- Version 1.1"
Message         'Waiting for SLIP server to respond'
Quiet ON
Expect 'Verification'
Message         'Request for User Verification Received from CWRU-TS2'
Message         'Sending your user name and password'
Quiet OFF
Expect   'Username:'
Send '%u<'
Expect   'Password:'
Private
Send '%p<'
Reject    'Access denied'   'Your user name or password was not accepted'
TimeOut 30    'SLIP server did not respond to your validation request'
Expect 'CWRU-TS2>'
Send 'SLIP<'
TimeOut 10    'SLIP server did not respond to SLIP command'
Expect 'IP hostname or address:'
Send '%u-slip.dialin.cwru.edu<'
TimeOut 10 'SLIP server did not respond to hostname'
Reject    'Bad IP address'   'Incorrect Hostname'
Expect 'Password:'
Send '%p<'
Reject    'Access denied'    'Password not accepted.'
TimeOut 10
Expect 'Header Compression will match your system'
Message 'Login to CWRU SLIP server successful'
Wait 1.0
EndProcedure   Host.CWRU.Login
#
#
Procedure      Host.CWRU.LogOut
# Nothing special needs to be done to logout
EndProcedure   Host.CWRU.LogOut
#
#   End of Script file
#
----------------------------------------------------------------------
How to use packet drivers other than UMSLIP with PHONE?

The quick answer -- there is no "clean" way.  Below is a batch file
hack that I wrote to use PHONE with other packet drivers.  In this
example, the packet driver is Peter Tattam's CSLIPPER.  To use a
batch file like this, you must know the parameters with which you
plan to use the packet driver -- i.e interrupt vector, baud rate,
port address, and IRQ.  This batch file requires UMSLIP.COM,
CSLIPPER.EXE, and TERMIN.COM to be in the same directory
or in your path ...

All that the BATCH file does is to let you dial the SLIP connection
using PHONE, load the appropriate packet driver, hangup the
connection, and unload the driver when you are done ...

-- being CWRUSLIP.BAT --
@echo off
rem   this batch file is an ugly hack of U. of Minn. "SLIP.BAT"
rem   awaiting a version of C/SLIPPER that can directly interact
rem   with PHONE
rem   CWRUSLIP.BAT file is used with PHONE.EXE to start a SLIP
rem   connection on CWRU-TS2
rem   last modified 3/28/93 -- Ashok Aiyar

@echo off
cls
goto start

:start
if %1. == ?.         goto help
if %1. == help.      goto help
if %1. == setup.     goto setup
if %1. == dial.      goto forceD
if %1. == hangup.    goto forceH
if %1. == quit.      goto forceH
if %1. == HELP.      goto help
if %1. == SETUP.     goto setup
if %1. == DIAL.      goto forceD
if %1. == QUIT.      goto forceH
goto bogus
goto unload

:forceH
termin 0x60
umslip >nul
phone force hangup
goto unload

:slipper
termin 0x60
REM  the following line must be changed to reflect the COM port,
REM  IRQ, baud rate, and software interrupt
lh c:\packet\cslipper com1 vec=60 baud=57600 ether
goto end

:forceD
termin 0x60
umslip >nul
phone force dial
goto slipper

:setup
termin 0x60
umslip >nul
phone setup
goto help

:unload
termin 0x60
goto end

:bogus
echo %1 is not a valid command.
echo Try "cwruslip help" for a list of valid commands
echo.

:help
echo --------------------------------------------------------------
echo           Case Western Reserve University SLIP Setup
echo                  using Univ. of Minnesota PHONE
echo --------------------------------------------------------------
echo cwruslip setup     modem settings, phone number, username etc.
echo.
echo cwruslip dial      DIAL and establish the SLIP connection
echo cwruslip quit      HANGUP the phone and unload the driver
echo cwruslip help      this screen
echo.

:end
-- end CWRUSLIP.BAT --
 


B-3. How do I install packet drivers for Windows applications?

How do I install packet drivers for Windows applications?

The secret is to load the packet driver, then run Windows. If you
are running Trumpet Winsock, you will also have to load WINPKT
before running Windows, as follows:

winpkt 0x60

If you are running DOS applications within a virtual DOS session
under Windows, you should load PKTMUX after your packet driver, as
follows:

PKTMUX 4 [or however many sessions you want]
WIN [load windows]
 
Then within each DOS session, load PKTDRV, the virtual packet driver.

If you are running Trumpet Winsock along with other DOS apps in a 
virtual DOS session, then you will need to load PKTDRV prior to
loading Windows, and then load WINPKT on top of it, as follows:

PKTMUX 4
PKTDRV 0x62
WINPKT 0x62
PKTDRV 0x60
WIN

TCPMAN will then find the virtual packet driver at 0x62. 


B-4. When do I need to install  WINPKT? 

PKTMUX and WINPKT both accomplish the same thing: allowing you to
connect to a DOS packet driver running in real mode from a virtual
DOS session under Windows. PKTMUX is useful when you are running
more than one TCP/IP stack, and since it takes up more RAM and is
slower than WINPKT, you should only use it when you want to run more
than one stack at a time. If you are running only one DOS app,
or are using Trumpet Winsock, stick with WINPKT. 

James Harvey (mailto:harvey@iupui.edu) notes:
Winpkt is only useful running DOS applications with built-in TCP/IP
stacks under Windows, and for some Windows-based stacks (like the
Trumpet winsock.dll).  When an application registers with a packet
driver TSR to receive packets of a specified protocol type, one of the
things it hasto pass as a parameter to the packet driver in the call
is the address of a routine in the application that the packet driver
is to call when it has a packet to pass back to the application.  In
the case of an application running in 386 enhanced mode in a DOS shell
under Windows that is using a packet driver loaded in real mode before
Windows was loaded, the packet driver must ensure that Windows has the
application in memory when it does the callback, otherwise the callback
jumps off into space and your system locks up.  Winpkt does a Windows
system call to force the app into memory before the callback is done.

Erick Engelke (mailto:erick@development.uwaterloo.ca) notes:
Windows in enhanced mode uses the protected mode of the
386 CPU to create multiple virtual machines.  Winpkt tells
Windows to switch to the correct virtual machine before
trying to pass up the packet.  This reduces the chances of
Windows crashing.


B-5. How to do I run both WinQVT and ODI?

My advice is to use the Windows Sockets version of WinQVT/Net, Trumpet
Winsock, and ODIPKT. ODIPKT will allow you to run packet driver software
over ODI. You will also need to load WINPKT for Trumpet Winsock. 

The loading sequence is:

LSL [Link support layer]
NE2000.COM [or other ODI driver]
IPXODI [IPX version supporting ODI]
NETX
ODIPKT 1 96
WINPKT 0x60
WIN [run windows]

Then run Trumpet Winsock, and load WinQVT/Net. 

B-6. Is it possible to use BOOTP over SLIP?

Yes, but it is easier to use dynamic address assignment to get 
your IP address. This is where the SLIP server outputs your IP address 
before switching to SLIP. 

If you need BOOTP, then you should run a BOOTP server on the SLIP
server so that it can tell which SLIP connection originated the
request. Of course, the BOOTP server will ignore the hardware address
of the request originator, but instead will keep track of the SLIP
interface the request came in on. See the question on adding BOOTP to
KA9Q for info on how to handle this on the PC. Under UNIX, you may
have to add BOOTP capability to your slip driver, and rebuild the
kernel. (Not recommended for the squimish). 


B-7. How do SLIP drivers work? 

Some TCP/IP applications are written to only support Class 1 (Ethernet)
packet drivers, but do not support Class 6 (SLIP). For these applications, you
need software to make the application think it is dealing with a class 1
interface. This is done by adding fake ethernet headers to incoming 
SLIP or PPP packets and stripping the headers off outgoing packets. 


B-8. When do I need to install PKTMUX?

PKTMUX is needed to allow you to use more than one TCP/IP stack at the same 
time. This is useful if you have applications that require different stacks. 
Note that you do not need PKTMUX to run different protocols, since packet 
drivers only look at packets in the protocol they're designed to handle, 
and therefore you can use more than one of these at a time without conflict. 
You also don't need PKTMUX if all your applications use the same TCP/IP stack. 

PKTMUX works by looking at outgoing datagrams, and caching information on 
source and destination ports and addresses. Using this information, PKTMUX
tries to sort incoming datagrams by TCP/IP stack. If it can't figure out
which stack to send a datagram to (as might be the case if you were running
a server application on a well-known port, and had not sent any outgoing
packets yet), PKTMUX will send the datagram to all stacks. If all stacks
do not complain about the datagram, PKTMUX will throw away the ensuing outgoing
ICMP error message, assuming that one of the stacks correctly received
the datagram. If all stacks complain, it will send a single ICMP message
and throw the rest away.

While PKTMUX does its job very well, there are some situations that it cannot
handle, such as port conflicts. If two applications open the same TCP port,
chaos is inevitable, and there is little that PKTMUX can do to help. 

B-9. Can NDIS be used underneath multiple protocol stacks of the same type?
No. There is no equivalent to PKTMUX for NDIS.  

B-10. Is there an NDIS over packet driver shim? 
Joe Doupnik writes:

"No. Packet Drivers work by having an application register
for a particular packet TYPE, such as 0800 for IP. NDIS works much
differently, by offering a peekahead of every packet to applications in turn,
a polling operation. The only way NDIS could gracefully sit on a PD would
be to run the Packet Driver in all-types mode and let NDIS see all pkts
not used by other clients. Needless to say, that's an undesirable situation.
The quick solution, costing about US$100 (at least at my place,
more at yours) is a second Ethernet board in the client together with a
second IP address (most important, please)."

B-11. How do I run NetBIOS over TCP/IP? 

NetBIOS over TCP/IP is discussed in RFCs 1001 and 1002, which defines
three types of NetBIOS nodes:  

* B nodes, which use UDP broadcast packets to distribute datagrams and
resolve names. 
* P nodes, which use point-to-point communications and which 
require NetBIOS Datagram Distribution (NBDD) and NetBIOS Name 
Servers (NBNS). P nodes do not listen to or use broadcast 
services, so they cannot be used alongside B nodes. Unfortunately NBNS, 
and NBDD servers were not widely implemented, and those
that do exist (such as an implementation from Network Telesystems) 
are not inexpensive.  
* M nodes, which use both point-to-point and broadcast. 

B node technology cannot be used on an IP internet without extensions, 
since UDP broadcast packets are not forwarded through routers. This 
is not a problem with use of NetBIOS over IPX/SPX, since in IPX/SPX 
broadcast packets are forwarded. 

However, until very recently, M and P node technology was not supported 
by popular TCP/IP implementations. For example, PC/TCP supports
B node technology with extensions such as a broadcast file, host file, 
or DNS resolution of NetBIOS names. Windows NT and WFW TCP/IP uses an 
LMHOSTS file for resolving names. 

According to Chip Sparling of FTP Software:

"From what I remember from our discussions of a few years ago, P
nodes were only implemented by Ungermann Bass and 3COM (and they 
required you to use a NetBIOS name resolver which was non-rfc 1001, 1002 compliant), 
nobody did M nodes (as far as I remember) and PC-LAN, Lantastic and
LanManager used B node.  Also, if you did a P or M node it wouldn't be
compatible with a B node NetBIOS.  We decided that we could give the
compatibility and functionality (routability) with a B node plus
extensions implementation.  So, that's what we did." 

Without implementation of M and P node technology, the only way 
to run over an IP internet is to to implement B node technology 
with extensions, as FTP Software does in PC/TCP. According to Chip, 
"one way to handle large numbers of hosts on multiple networks is 
to use the broadcast file extenstion.  Instead of putting specific 
ip addresses in the broadcast file, use a subnet broadcast address 
like nnn.nnn.nnn.255. which will cover an entire subnet."

Assuming you don't need any of the extensions to RFC NetBIOS 
Microsoft created to make NetBIOS work smoothly in a routed environment 
(available only in their IP stack), you can choose from a wide variety of
commercial vendors. For example, FTP Software's PC/TCP includes RFC NetBIOS 
support; Performance Technologies has a NetBIOS that runs over packet drivers,
as does Accton (LANSoft). 

If any other vendors are reading this, I'd love to have information 
on how *you* implement NetBIOS over TCP/IP, and whether you'll be
supporting WINS, the new P-node technology name resolution service
from Microsoft. 

WINS will be included in the next WFW TCP/IP release, which is currently
in beta test and available for download from ftp.microsoft.com. Consult the 
beta release documentation for more information on this. 


B-12. How do I run NFS along with another TCP/IP application?

The DOS NFS implementation by M. Durkin now supports a built-in
packet multiplexer that can handle NFS plus another stack loaded
simultaneously. If you need to load more stacks, then you will need
to run PKTMUX as well.

See the resource section for details. 

B-13. How do I run Trumpet Winsock along with KA9Q or NFS? 

The secret is to load WINPKT on top of the PKTDRV virtual
packet driver, if you are running PKTMUX. 

B-14. Sample Stick Diagrams

It has been proposed that we begin to collect some diagrams of working
combinations of hardware, drivers, shims, stacks, and applications. I'm
game, and have made a start below. If you've got some other exotic
configuration that works (or if you've tried one of the configurations below
and discovered it doesn't work, drop me a line).

   Running an individual DOS application under Windows

    NCSA telnet / DOS Trumpet / POPmail/ PC Gopher III
                 |
             DOS Session
                 |
             Windows 3.1
                 |
               WinPKT
                 |
            Packet driver or Shim
                 |
                DOS
		 |
           Network Adapter


DOS Trumpet, NCSA Telnet, and WinQVT/Net over Ethernet under Windows

                                                QVT/NET
                                                   |
     TRUMPET                    NCSA telbin        |
       |                             |             |            
     PKTDRV1                     PKTDRVn           |
       |                             |             |
     DOS Session                DOS Session    Windows Session
       +-----------+-----------------+             |
                   |                               |
                   +                               |             
             WINDOWS 3.1 .............        WINDOWS 3.1
                   |                               |
                   |                      PKTINT(QVT/NET own)
                   |                               |
                   |                           PKTDRVx
                   +-------------------------------+            
               PKTMUX n
                   |                   
          Packet Driver or SHIM
                   |              
                  DOS 
		   |
            Network Adapter

PC Gopher III, NCSA Telnet over CSLIP under Windows


                                                
                                                   
  PC Gopher III                 NCSA telbin        
       |                             |                         
     PKTDRV1                     PKTDRVn           
       |                             |             
     DOS Session                DOS Session   
       +-----------+-----------------+             
                   |                               
                   +                                            
             WINDOWS 3.1 
                   |                               
                   |                   
                   |                               
                   |                           
                   +           
                PKTMUX n
                   |                   
               CSLIPPER
                   |              
                  DOS
		   |
	      Serial Port  

PC Gopher II and NetWare on a LAN - Alternative I
[Didn't work for me, but it's supposed to be OK]

               NetWare
PC Gopher        |
  III            |
   |             |
DOS Session    NETX
   |             |
 Windows 3.1     |
   |           PDIPX
  WINPKT        /
     \         /
      \       /
       \     /
        \   /
     Packet Driver
          |
	 DOS
          |
     Network Adapter
   

PC Gopher III and NetWare on a LAN - Alternative II

                                  PC-Gopher III
				      |
				  DOS Session
				      |
			          Windows 3.1                 
                                      |
                                      |
                    NetWare            |
                        \            /
                      NETX         WINPKT
                          \        /
                        IPXODI   ODIPKT
                             \   /
                              \ /
			       |
			Link Support Layer
                               |
                            ODI driver
			       |
			      DOS
                               |
                          Network Adapter

WinQVT/Net and PC Gopher II and NetWare over a LAN - Alternative I

PC Gopher      
  III 
   |             Win QVT/Net      
 PKTDRV1            |      
   |                |   
DOS session      Windows 3.1
   |                |
Windows 3.1      PKTINT (QVT/NET own)
   |                |
   |             PKTDRVn
 WinPKT             |
   |                |          NetWare
   +----------------+            |
   |                             |
   |                             |
 PKTMUX n                      NETX
   |                             |
    \                          PDIPX
     \                           |
      \                          |
       \                         |
        \                        |
     Packet Driver --------------+
          |
	 DOS
          |
     Network Adapter

WinQVT/Net, PC Gopher III and NetWare over a LAN - Alternative II
	
	                                         QVT/Net
  PC Gopher III                 NCSA telbin        |
       |                             |             |            
     PKTDRV1        .....        PKTDRVn           |
       |           |                 |             |
     DOS Session                DOS Session    Windows Session
       +-----------+-----------------+             |
                   |                               |                                  
		   |                               |            
             WINDOWS 3.1 .......................WINDOWS 3.1
                   |                               |
                   |                      PKTINT(QVT/NET own)
                   |                               |
                   |                           PKTDRVx
              	   |	                           |      
		   |		                   |
		   |		                   |
		   |		                   |
		   +------------------+------------+
				      |
                    NetWare            |
                        \            /
                      NETX         PKTMUX n (use if >1 TCP/IP app)
                          \        /
                        IPXODI   ODIPKT
                             \   /
                              \ /
			       |
		        Link Support Layer
                               |
                           ODI driver
                               |
			  Network Adapter



PC Eudora and Windows Trumpet over CSLIP under Windows using Trumpet Winsock


 PC Eudora    Windows Trumpet
     \         /
      \       /
       \     /
        \   /
       TCPMAN
          |
     Windows 3.1
	  |
     WINPKT 0x60
          |
         DOS
          |
      Serial Port
      
PC Eudora and Windows Trumpet supporting Ethernet and CSLIP under Windows 
using NDIS supporting stack [Chameleon]

[Please note: this is not possible under Trumpet Winsock, since it can
only handle a single interface; it requires a stack that routes]

 PC Eudora    Windows Trumpet
     \         /
      \       /
       \     /
        \   /
      Chameleon NEWT
          |
      Windows v3.1
          |
	  +------------------+
	  |                  |
    Protocol Manager         |
          |                  |
      NDIS Mac Driver     Serial Port
          |
         DOS
          |
     Ethernet card



PC Eudora, Windows Trumpet, and KA9Q under Windows

       WinTrump   PC Eudora
            \     /
             \   /
 KA9Q         \ /
   |           |
 PKTDRV      TCPMAN
     \         |
      \       /
       \     /
        \   /
	 \ /
        Windows
          |
        PKTDRV 0x62
	  |
        PKTMUX 2
          |
     Packet Driver
          |
         DOS
          |
     Ethernet Card

HGopher, PC Eudora, and WinTrumpet Under Windows
(Whether the TCP/IP stack is loaded before or
after Windows depends on the stack)

       HGopher
         |       
         |
   PC    |
 Eudora  |  WinTrumpet
     \   |   /
      \  |  /
       \ | /
        \|/
       TCPMAN
         |
     Windows 3.1
         |
      WINPKT
         |
  Packet Driver
         |
        DOS
         |
   Ethernet Card

B-15. Strange and wonderful configuration files submitted by readers

Robert Clift (mailto:clifta@sfu.ca) writes:

"I have WinQVT/Net 3.4, PC Gopher III (including NCSA DOS Telnet), KA9Q 
(gopher and FTP server), and POPMail all running together under Windows 
over PKTMUX on a 3C503 packet driver (and Ethernet card)."

Here is the stick diagram (yikes!): 

Win/QVTNet 3.7     KA9Q Gopher      PC POPMail 3.2     PC Gopher III 1.01
on interrupt 65    & FTP Server           \                    /
    \                  |                    \                /
      \                |                      \            /
        \              |                        \        /
          \          PKTDRV                       PKTDRV
            \          |                            /
              \      DOS Session               DOS Session
                \      |                        /
                  \    |    -------------------       
                    \  |  /                 
                  Windows 3.1
                       |
                     PKINT
                       |
         PKTDRV on Int 65 no listeners set
                       | 
           PKTMUX 1.2 with 3 channels
                       |
          Clarkson 3C503 Packet Driver
	               |
	              DOS
                       |
           3Com Etherlink II/16 TP
                       |
                    Ethernet

NOTES:

Win/QVTNet must be loaded as the very first Windows application and must be 
kept operating as long as your are in Windows.  It appears that its TCP/IP 
stack does some strange things when it disconnects and kills access to the 
actual packet driver.

I run PC gopher and POPMail alternatively, so they share one channel which 
is allocated via PKTDRV before running the application and deallocated 
after the application is finished (I usually throw in a reset command to 
PMTMUX as well just to be safe).

To explain what is happening (as best I can since a lot of this came from 
experimentation):

1.  The packet driver is loaded
2.  PKTMUX is run over the packet driver in order to multiplex it (in this 
    case three channels).
3.  A virtual packet driver is loaded for Win/QVTNet on interrupt 65 and 
    the packet driver is told that it is not to listen for any server 
    requests.
4.  PKINT is loaded over top of the virtual packet driver
5.  Start Windows and run Win/QVTNet as the first application, it must be 
    kept running throughout the Windows session.
6.  Load a virtual packet driver from a DOS session and start KA9Q.  I use 
    the following batch file to do this:

         c:\network\pktdrv 63 /l
         h:
         cd \
         net091b
         c:\network\pktdrv 63 /uu
         c:\network\pktmux /r

7.  Load a virtual packet driver and run PC Gopher or POPMail as needed.  I 
    use the following batch files for PC Gopher and POPMail respectively:

         c:\network\pktdrv 63
         h:\goph-cli\gopher /T=h:\goph-cli\text /X=h:\goph-cli\binary
         c:\network\pktdrv 63 /uu


         c:\network\pktdrv 66 /c
         h:\popmail\popmail /noems
         c:\network\pktdrv 66 /uu

8.  The only problem seems to be that the NNTP module in Win/QVTNet will 
    not operate correctly if POPMail is operating.  Otheriwse it seems to 
    work okay without too many problems.

C. KA9Q Questions

C-1. What version of KA9Q should I use and where do I get it?

There are so many releases of KA9Q that it is a significant amount of
work just to keep track of them all. This has occurred partly because
KA9Q does not support extended or expanded memory, and therefore many
people have needed to customize it with the features relevant to them
in order to allow it to do what they want as well as fit into memory. 
The primary difference among the various releases is whether they 
include code for a BBS, packet radio support (AX.25), synchronous cards (for
use with leased lines), NNTP, CSO or Gopher servers, packet filtering, DNS,
RIP or PPP support. 

The three primary KA9Q releases at this time are those managed by Ashok Aiyar
(ashok@biochemistry.bioc.cwru.edu), those put out by Demon Internet
Services (DIS), and the JNOS distribution. JNOS is the primary packet radio-
oriented release; the other two major releases do not include AX.25 support.
Since JNOS does not include several features important to non-packet radio
users (DNS/Gopher/CSO server, hop check), try one of the other two releases
if you're not interested in packet radio.

Ashok's release is based on the N1BEE 0.85-beta which in turn 
is based on PA9GRI 2.0m NOS. Version 11c includes support for NTP, CSO,
gopher, FTP, FINGER, HTTP and SMTP/POP2/POP3 servers, plus VT102 and packet 
filtering support. Please not that this release does *not* include radio or 
synchronous card support, unlike the standard KA9Q release, and only support 
SLIP/CSLIP. Also, there is no DNS server support, and the tip command has been 
removed, so that you need to use an external dialer to make the connection.

Available as:

file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.exe, 
file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.txt, 
file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.map, 
file://biochemistry.bioc.cwru.edu/pub/nos/nos192.txt, 
file://biochemistry.bioc.cwru.edu/pub/nos/nos_1229.man, 
file://biochemistry.bioc.cwru.edu/pub/nos/vt102.zip, 
file://biochemistry.bioc.cwru.edu/pub/nos/filter.txt, 
file://biochemistry.bioc.cwru.edu/pub/nos/autoexec.nos

The TextWin version from Demon Internet Services includes support for DNS server, packet filtering, FTP, SMTP/POP2/POP3 servers, NNTP server, VT102 support, NTP, BBS, SLIP/CSLIP,PPP (I don't know anyone who has gotten this to work), demand dial, ping, hop
 check (traceroute equivalent). 

From mailto:mike@childsoc.demon.co.uk (Michael Bernardi):

"Demon Internet Services have a dialin Internet service in the UK.
They also support a customised version of KA9Q optimised for
dialup, they also support the PCElm mailer, SNEWS news reader and
a customised front end. There is also a combined NEWS and MAIL
program called CPPNEWS and an alternative MAIL program called
VIEW, these last are unsupported by mailto:Internet@demon.co.uk but other
DIS users do support them. All these programs can be found on
ftp://ftp.demon.co.uk/pub/ibmpc/ and are written to
work with KA9Q (specifically the DIS version)."

Anthony McCarthy has added a multi-windowing system to KA9Q that 
supports the mouse, which has been recommended. See Resource 
listings for info. 

The DIS release includes three versions, small, medium and large. 
The large version includes everything but the kitchen sink, including
an NNTP server. I also believe it includes the KA9Q BBS code, and
radio support. 

Editorial: To my mind, the time has come for the major releases to combine 
their code bases and produce a version with the best features of all of them. 
To my mind, the ideal KA9Q release would be a release combining the improved 
server support of the CWRU release with a working PPP implementation, demand 
dial, and DNS server support. 


C-2. What do I need to run KA9Q? Why won't it do VT-100 emulation?

KA9Q is usually run from a startup script, such as my script
startnos.bat:

\nos\drivers\8003pkdr
\nos\net -d \nos

Here I first load the packet drivers for my 8003 Ethernet card, then
run KA9Q (known as net.exe).

The KA9Q package then reads commands from a configuration file, called
AUTOEXEC.NOS in some implementations, AUTOEXEC.NET in others. 

For VT100 emulation with KA9Q, try using Giles Todd's VT102.COM,
available via ftp://ftp.demon.co.uk/pub/ibmpc/DIS.

C-3. How do I configure KA9Q as a SLIP dialup connection?

Here is a sample CSLIP only configuration file, which was
written for Demon Internet Service's version of KA9Q (as
are all other KA9Q sample configs in this FAQ): 

# This config file is for use with the large TextWin 
# version of KA9Q available from ftp.demon.co.uk
#
# Set the host name
#
hostname foobar.com
#
# Configure COM3 on Interrupt 5, at 38400 bps with 
# RTS/CTS (c) and Van Jacobsen Compression (v) and
# MTU = 1008
# 
attach asy 0x3e8 5 vjslip sl0 8092 1008 38400 cv
ifconfig sl0 ipaddress [192.187.134.3] 
ifconfig sl0 netmask 255.255.255.0
dialer sl0 dialer.sl0
#
#
# route all packets over sl0 by default (sl0 is the route 
# to the Internet)
#
route add default sl0
#
# Time To Live is the maximum number of hops a packet 
# can take before it is thrown away.  This command 
# prevents packets from looping infinitely. 
#
ip ttl 255
#
# The Maximum Segment Size is the largest single 
# transmission that you care to receive.  An mss of 216 
# will force folks to send you packets of 256 characters 
# or less (counting the overhead). 
#
tcp mss 1048
#
# The Window parameter establishes the maximum number 
# of bytes that may be outstanding before your system 
# expects an ack. If window is twice as big as mss, 
# for example, there will be two active packets on the 
# channel at any given time.  Large values of window 
# provide improved throughput on full-duplex links, but 
# are a problem on the air.  
# Keep  mss <= window <= 2*mss if you're on the air.
#
tcp window 6888
#
# This entry will open net.log in the \spool directory 
# and will record the server activity of your system.  If 
# you don't want a log, comment out this line; if you do, 
# make sure you have a \spool directory!
#
log \textwin\spool\net.log
#
# Each of the servers (services you will provide) must 
# be turned on before they will be active.  The 
# following entries turn all of them on.  To turn any 
# function off use the command 'stop' after NET gets 
# fired up, or just comment out the line here.
#
start ftp
ftpopt binary
start echo
start discard
# start telnet
start smtp
# This machine uses primary and seconary DNS servers
# to resolve addresses
domain addserver 192.100.81.101
domain addserver 192.100.81.105
# Command indicating presence of IBM AT
isat on
#
smtp gateway 140.174.7.1
#
#
# THE END

dialer.sl0 file:

# Configuration section.
#
configure:
init "ATZ\r"
dial_cmd "ATDT"
ld_code ""
number "15108658169"
retries 5
#
# Execution section.
#
execute:
#
# Toggle DTR.
#
control down
wait 2000
control up
wait 2000
#
# Initialize the modem.
#
init
wait 3000 "OK"
#
# Dial and wait for connection.
#
dial
wait 45000 "CONNECT"
#
# Now log in.
#
wait 60000 "ogin:"
wait 1000
send "userID\r"
wait 60000 "word:"
send "password\r"


After executing this setup file, you should hear the modem dial out
to your SLIP host. Assuming that the dialing script is correct,
it should login and go into SLIP mode.

Type RESET at the prompt. This kills any residual processes that
may be operating.  

At this point you should have a functioning connection. You might
try to ping your host via the command:
PING <host adddress>
If this works, you will then see the round trip time to your host,
in milliseconds. 

Other possible diagnostic commands:

ASYSTAT <interface>	Gives statistics on packets received, sent, etc.
TRACE <interface> 1011	Shows incoming characters
RIP TRACE 1		Traces RIP packets
HOP CHECK <address>	Traces the route to the designated system. Useful 
			for figuring out routing problems. 


C-4. How do I configure KA9Q as a router?

The KA9Q configuration that follows uses two interfaces, one a PPP
interface (pp0), the other an Ethernet interface (lan). Here I
am implementing dial on demand, and can also be doing packet 
filtering, and DNS serving on the same box. 

Please note the strange interrupt settings (Interrupt 5, port is COM3).  One of 
the nice things about KA9Q is that it is flexible enough to deal with 
such situations.

Here is a sample router configuration file:

# This config file is for use with the large TextWin 
# version of KA9Q available from ftp.demon.co.uk
#
# Set the host name
#
hostname gate.foobar.com
#
# Configure COM3 on Interrupt 5, at 38400 bps with 
# RTS/CTS (c) and PPP
# 
attach asy 0x3e8 5 ppp pp0 8092 576 38400 c
ifconfig pp0 ipaddress [192.187.147.2] 
ifconfig pp0 netmask 255.255.255.0
dialer pp0 dialer.ppp demand
#
ppp pp0 trace 2
ppp pp0 quick
ppp pp0 lcp open
ppp pp0 ipcp open
#
# Packet driver installed at software interrupt 
# number 0x60.
#
attach packet 0x60 lan 2 1500
ifconfig lan ipaddress [192.187.157.4] 
ifconfig lan etmask 255.255.255.0
#
route add default pp0
#
# The local Ethernet has a Class C network address so
# route all IP addresses beginning with 192.187.157 to 
# it.
route add 192.187.157/24 lan
#
# Time To Live is the maximum number of hops a packet 
# can take before it is thrown away.  This command 
# prevents packets from looping infinitely. 
#
ip ttl 255
#
# The Maximum Segment Size is the largest single 
# transmission that you care to receive.  An mss of 216 
# will force folks to send you packets of 256 characters 
# or less (counting the overhead). 
#
tcp mss 576
#
# The Window parameter establishes the maximum number 
# of bytes that may be outstanding before your system 
# expects an ack. If window is twice as big as mss, 
# for example, there will be two active packets on the 
# channel at any given time.  Large values of window 
# provide improved throughput on full-duplex links, but 
# are a problem on the air.  
# Keep  mss <= window <= 2*mss if you're on the air.
#
tcp window 6888
#
# This entry will open net.log in the \spool directory 
# and will record the server activity of your system.  If 
# you don't want a log, comment out this line; if you do, 
# make sure you have a \spool directory!
#
log \textwin\spool\net.log
#
# Each of the servers (services you will provide) must 
# be turned on before they will be active.  The 
# following entries turn all of them on.  To turn any 
# function off use the command 'stop' after NET gets 
# fired up, or just comment out the line here.
#
start ftp
ftpopt binary
start echo
start discard
start telnet
start smtp
# This machine will act as a DNS server;
# Boot file is c:\textwin\named.boo, configuration
# goes in c:\textwin\spool\zones
domain startdns
# Command indicating presence of IBM AT
isat on
#
smtp gateway 192.187.157.2
#
# Use Router Information Protocol (RIP) to inform 
# the router at 192.187.147.253 about the existence 
# of the local network. Send RIP packets every 240 
# seconds. Only useful for dedicated routers.
rip add 192.187.147.253 240
#
# THE END

dialer.ppp file:

# Configuration section.
#
configure:
init "ATZ\r"
dial_cmd "ATDT"
ld_code ""
number "15108658169"
retries 5
#
# Execution section.
#
execute:
#
# Toggle DTR.
#
control down
wait 2000
control up
wait 2000
#
# Initialize the modem.
#
init
wait 3000 "OK"
#
# Dial and wait for connection.
#
dial
wait 45000 "CONNECT"
#
# Now log in.
#
wait 60000 "ogin:"
wait 1000
send "userID\r"
wait 60000 "word:"
send "password\r"

Here is another routing configuration file, using CSLIP and proxy arp:

# This config file is for use with the large TextWin 
# version of KA9Q available from ftp.demon.co.uk
#
# Set the host name
#
hostname gate.foobar.com
#
# Configure COM3 on Interrupt 5, at 38400 bps with 
# RTS/CTS (c) and Van Jacobsen Compression (v) and
# MTU = 1008
# 
attach asy 0x3e8 5 vjslip sl0 8092 1008 38400 cv
ifconfig sl0 ipaddress [157.151.0.253] 
ifconfig sl0 netmask 255.255.255.0
dialer sl0 dialer.sl0
#
#
#
# Packet driver at 0x60; probably an Ethernet card
#
attach packet 0x60 lan 2 1500
ifconfig lan ipaddress [157.151.64.1] 
ifconfig lan netmask 255.255.255.0
#
# route all packets over sl0 by default (sl0 is the route 
# to the Internet)
#
route add default sl0
#
# The local Ethernet has a Class C network address so
# route all IP addresses beginning with 157.151.64 to it.
route add 157.151.64/24 lan
#
#  Use Proxy ARP
arp publish 157.151.64.1 ether 00:00:c0:33:f3:13
arp publish 157.151.64.254 ether 00:00:c0:33:f3:13
#
# Time To Live is the maximum number of hops a packet 
# can take before it is thrown away.  This command 
# prevents packets from looping infinitely. 
#
ip ttl 255
#
# The Maximum Segment Size is the largest single 
# transmission that you care to receive.  An mss of 216 
# will force folks to send you packets of 256 characters 
# or less (counting the overhead). 
#
tcp mss 576
#
# The Window parameter establishes the maximum number 
# of bytes that may be outstanding before your system 
# expects an ack. If window is twice as big as mss, 
# for example, there will be two active packets on the 
# channel at any given time.  Large values of window 
# provide improved throughput on full-duplex links, but 
# are a problem on the air.  
# Keep  mss <= window <= 2*mss if you're on the air.
#
tcp window 6888
#
# This entry will open net.log in the \spool directory 
# and will record the server activity of your system.  If 
# you don't want a log, comment out this line; if you do, 
# make sure you have a \spool directory!
#
log \textwin\spool\net.log
#
# Each of the servers (services you will provide) must 
# be turned on before they will be active.  The 
# following entries turn all of them on.  To turn any 
# function off use the command 'stop' after NET gets 
# fired up, or just comment out the line here.
#
start ftp
ftpopt binary
start echo
start discard
# start telnet
start smtp
# This machine uses primary and seconary DNS servers
# to resolve addresses
#
domain addserver 157.151.0.2
domain addserver 157.151.0.1
smtp gateway 157.151.0.2
#
# Command indicating presence of IBM AT
isat on
#
#
#
# THE END

dialer.sl0 file:

# Configuration section.
#
configure:
init "ATZ\r"
dial_cmd "ATDT"
ld_code ""
number "15108658169"
retries 5
#
# Execution section.
#
execute:
#
# Toggle DTR.
#
control down
wait 2000
control up
wait 2000
#
# Initialize the modem.
#
init
wait 3000 "OK"
#
# Dial and wait for connection.
#
dial
wait 45000 "CONNECT"
#
# Now log in.
#
wait 60000 "ogin:"
wait 1000
send "userID\r"
wait 60000 "word:"
send "password\r"

C-5  How do I get KA9Q to support BOOTP?

The CWRU NOS version has a working BOOTP client and server built-in,
and is the best version if you are looking for BOOTP support.
[Does Textwin offer full BOOTP support?]
If you are using another version of KA9Q that does not support BOOTP,
try the following: 

Steven L. Johnson (mailto:johnson@TIGGER.JVNC.NET) notes:

  KA9Q does have a bootp client but it is not compiled in by default.
  It has a bug that truncates the returned ip address to 16 bits
  which must be corrected before it will work.  It also complains
  about bootp servers that only support RFC 951 bootp without RFC
  1084 (or 1048) vendor extensions.  Other than that it seems to work
  for me.

  To enable the bootp client, add the following line to config.h:

    #define BOOTP 1

  To correct the ip address truncation problem, in bootp.c change:

                Ip_addr = (int) reply.yiaddr.s_addr;    /* yiaddr */
                          ^^^^^problem
  at line 188 to:

                Ip_addr = (int32) reply.yiaddr.s_addr;    /* yiaddr */
                          ^^^^^^^solution

  And of course, recompile.

  This worked on the src1229 (1991) version and may work on the
  most recent version.  I did check to make sure that the bug still
  exists, but I haven't rechecked whether there are additional
  problems in the new version.



C-6.  How do I get KA9Q to support PPP?

Although I haven't gotten this to work yet, there is hope. 
The only major version of KA9Q supporting PPP is the TextWin versio