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