Subject: comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 1 of 3
From: [email-masked] (Bernard Aboba)
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,alt.winsock,comp.os.ms-windows.networking.tcp-ip,comp.answers,news.answers

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

comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 1, 8/1/94

#################  Legalese #################

This document is Copyright (C) 1993,1994 by Bernard Aboba, except where 
the copyright is retained by the original author(s). This document
may be distributed non-commercially, provided that it is not
modified in any way. However, no part of this publication may be 
sold or packaged with a product for sale in any form without the 
prior written permission of Bernard Aboba. 

This FAQ is presented with no warranties or guarantees of ANY KIND
including correctness or fitness for any particular purpose. The
author(s) of this document have attempted to verify correctness of the
data contained herein; however, slip-ups can and do happen.  If you use
this data, you do so at your own risk. While we make every effort to
keep this FAQ up to date, we cannot guarantee that it is, and we will
not be responsible for any damages resulting from the use of the information
or software referred to herein. 

Unless otherwise stated, the views expressed herein are my own.  Last
time I looked, I had not been appointed official spokesperson of any
of the following:

	The Planet Earth
	The U.S.Government
	The State of California (not so good)
	The University of California, Berkeley
	The City of Berkeley (bringing you Riot of the Week(SM))
        Addison-Wesley
        Publisher's Group West
	Any major or minor breakfast cereal (not even oatmeal!)
	
This FAQ will be posted monthly. In between it will be
available as: 
file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip

################# HTML version goes online #################

This FAQ is now fully HTML compatible, and is
being automatically converted to HTML. 
This means that if you have a WWW browser, 
you can read the FAQ online, and click on links 
to download individual files. 

This is how I read the FAQ myself, and it is
highly recommended. To get at the HTML
version, use:
http://www.zilker.net/users/internaut/forth.html#upd

################# Citation entry  #################

This FAQ may be cited as:

  Aboba, Bernard D.(1994) "comp.protocols.tcp-ip.ibmpc Frequently
  Asked Questions (FAQ)" Usenet news.answers, available via 
  file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip, 
  57 pages.

################# Change History  #################

Changes from 7/1/93 posting:
FAQ now available in HTML format. Entries
changed in last two FAQs sport a *. 

################# Related FAQs #################

There is a FAQ available on features of TCP/IP
Packages for DOS and Windows. This is available at:
file://ftp.cac.psu.edu/pub/dos/info/tcpip.packages. 

The Windows Sockets Faq is posted to alt.winsock, and
is available at:
ftp://SunSite.UNC.EDU/pub/micro/pc-stuff/ms-windows/winsock/FAQ

The PC-NFS FAQ is available at:
file://seagull.rtd.com/pub/tcpip/pcnfs.FAQ.v1.4.Z or pcnfsfaq.zip
file://ftp.york.ac.uk/pub/FAQ/pcnfs.FAQ

The SNMP FAQ is regularly posted to comp.protocols.snmp

The TCP/IP FAQ is posted to comp.protocols.tcp-ip, and is
maintained by mailto:[email-masked]. 

The "How To Get It" FAQ on the Crynwr packet driver 
collection is irregularly posted to comp.protocols.tcp-ip.ibmpc
by Russ Nelson, mailto:[email-masked]. 

################# Book info  #################

A bunch of you have requested information on the
book I am working on.  Here is the basic info:

Title: The PC-Internet Connection, TCP/IP
Networking for DOS and Windows
Authors: Bernard Aboba and Britt Bassett
Pages: 800 (estimated), 7" by 9"
Distributor: Publisher's Group West
ISBN: 1-883979-00-5
Price: $32.95 (est), includes Chameleon Sampler
software, WS-Gopher, PC-Eudora. 
Estimated release: October, 1994

To look at sample chapters from the book, check out
the following WWW page:  
http://www.zilker.net/users/internaut/forth.html

For those of in North America who *must* have 
a look at the book before it comes out, and are 
willing to comment on it, send me $25 to cover 
copying and postage, and I'll send you a copy. 
If you send back comments, I'll return the $25.
Since this is a big book, be prepared to spend 
some time looking at it.    

For those outside North America, sorry but we're on
a tight deadline, and so we will not be able to
include you. 

################# EXAMPLE CONFIG FILES  #################

Many thanks to Dave Fetrow ([email-masked])
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 [email-masked]. 

The archive itself is located at:
ftp://ftp.biostat.washington.edu/ftp/pub/msdos/network.setups 

Late breaking development: the archive has crashed, and 
files have been lost. 

TABLE OF CONTENTS

A. Components of a TCP/IP solution

A-1. What do I need to run TCP/IP on the PC?
A-2. What are packet drivers?  Where do I get them?
A-3. What is Winsock?  Where can I get it? 
A-4. What is Trumpet Winsock? How do I get it to dial? 
A-5. What publicly distributable TCP/IP applications are there
     for DOS?  Windows?
A-6. What software is available for doing SLIP?  Compressed SLIP?
     PPP?  For DOS?  For Windows?
A-7. What about the software included with various books? 
A-8. What diagnostic utilities are available to find problems with
     my connection?  Where can I get them?
A-9. Is there a CD-ROM with the software included in this FAQ? 
A-10. Does Windows NT support SLIP? PPP? 
A-11. Where can I take a peak at the WFW v3.11 VxD beta?
A-12. How do I get my BBS to run over TCP/IP? 
A-13. Are there graphical TCP/IP servers out there?
A-14. What methods of dynamic address assignment are available?
A-15. How can I set up PPP server on a UNIX host? 
A-16. What is WinSNMP? 

B. Questions about drivers

B-1. What do I need to know before setting up SLIP or PPP?
B-2. How do I configure SLIPDISK?
B-3. How do I install packet drivers for Windows applications?
B-4. When do I need to install  WINPKT? 
B-5. How to do I run both WinQVT and ODI?
B-6. Is it possible to use BOOTP over SLIP?
B-7. How do SLIP drivers work? 
B-8. When do I need to install PKTMUX?
B-9. Can NDIS be used underneath multiple protocol stacks of the same type?
B-10. Is there an NDIS over packet driver shim? 
B-11. How do I run NetBIOS over TCP/IP? 
B-12. How do I run NFS and another TCP/IP application?
B-13. How do I run Trumpet Winsock along with KA9Q or NFS? 
B-14. Sample Stick Diagrams
B-15. Strange and wonderful configuration files submitted by readers

C. KA9Q Questions

C-1.  What version of KA9Q should I use and where do I get it?
C-2.  What do I need to run KA9Q? Why won't it do VT-100 emulation?
C-3.  How do I configure KA9Q as a SLIP dialup connection?
C-4.  How do I configure KA9Q as a router?
C-5.  How do I get KA9Q to support BOOTP?
C-6.  How do I get KA9Q to support PPP?
C-7.  How do I get KA9Q to support SLIP dialin?
C-8.  Can I use KA9Q as a packet filter? 

D. Hints for particular packages

D-1. How do I get DesQView X to run over the network?
D-2. Why is NFS so slow compared with FTP?
D-3. Where can I get information on running NetWare and TCP/IP
      concurrently? 
D-4. What NetWare TCP/IP NLMs are out there and how do I get them
      to work? 
D-5. How do I get a telecom package supporting Int 14h redirection
      to work? 
D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP?
D-7. How do I get Windows For Workgroups to work alongside NetWare?
D-9. How come package X doesn't support the AppleTalk packet driver?
D-10. NCSA Telnet doesn't reassemble fragments. What should I do?

E. Information for developers

E-1. What publicly distributable TCP/IP stacks are there that I can
     use to develop my own applications?
E-2. Where can I get a copy of the Windows Sockets FAQ?

--------------------- FAQ Begins Here ---------------------------

A. Components of a TCP/IP solution

A-1. What do I need to run TCP/IP on the PC?

To run TCP/IP on the PC you will need:

* Appropriate hardware, such as:

    Ethernet card
    Token Ring card
    AppleTalk card
    Serial Port

  Any other network card with a packet driver or NDIS or ODI driver,
  (such as Arcnet), will also work.  If your card supports NetBIOS,
  this is also acceptable, since you can run a packet-driver-over-
  NetBIOS shim.

* Drivers for your hardware.

  Your card probably came with one or more of the following drivers:
 
    Network Device Interface Specification (NDIS) drivers
      [spec. by 3Com and Microsoft, used by LAN Manager, Windows
      for Workgroups, and Windows NT. LAN Manager uses NDIS 2.0,
      Windows NT uses 3.0, and WFW supports 2.0 and will support 
      3.0]
    ODI Drivers [spec. by Novell, abbreviation for Open DataLink
      Interface]
    Packet Drivers [spec. by FTP Software]
   
  TCP/IP stacks have been written for each of these driver interfaces, 
  so the important thing is whether your chosen stack is compatible 
  with the interface available for your card.
 
  A shim is software that runs on top of one set of drivers to
  provide an interface equivalent to another set. This is useful,
  for example,if you are looking to run software requiring an
  NDIS driver(such as Chameleon NFS) alongside software
  requiring a packet driver interface (such as KA9Q, Gopher, Popmail,
  NCSA Telnet, etc.), or run software intended for, say, a packet
  driver over an NDIS driver instead.
 
  Shims are available to run packet drivers over NetBIOS, ODI,
  or NDIS, in order to run software expecting a packet driver over
  NDIS, ODI, or NetBIOS instead. There are also shims to run NDIS
  over ODI (ODINSUP), and ODI over Packet Drivers (PDETHER). 

* A TCP/IP protocol stack.

  The TCP/IP protocol stack runs on top of the driver software, and
  uses it to access your hardware. If you are running a TCP/IP
  protocol stack that requires drivers that aren't available for your
  hardware, you're in trouble. Check into this before purchasing!

* If running Windows applications that require it, WINSOCK.DLL. 

  Windows Sockets is a sockets interface which was created as a 
  Windows DLL. Each  TCP/IP implementation requires its own version 
  of Windows Sockets. Trumpet Winsock and VxDTCP are the only
  two publicly distributable Windows Sockets implementations. 
  WINSOCK.DLL provides 16-bit support; WSOCK32.DLL provides 32-bit support. 

* Applications software.

  Although most of us in this newsgroup seem to spend our time
  looking for working combinations of applications,WINSOCK.DLLs,
  Windows Sockets compliant TCP/IP implementations, shims, 
  drivers, and hardware, ultimately your goal is eventually to 
  run an application successfully. If and when that happens, 
  please send me a note, so I can add it to this FAQ.

A-2. What are packet drivers?  Where do I get them?

Packet drivers provide a software interface that is independent of the  
interface card you are using, but NOT independent of the particular 
network technology. As Frances K. Selkirk ([email-masked]) notes:

"That's one reason they're easier to write than ODI drivers! If you
write a class three (802.5 Token Ring) driver, you will need to use
software that expects a class three driver, not software that expects
a class 1 (DIX ethernet) driver. There are a few drivers that fake class 1. 

I believe only class 1 and class 6 (SLIP) drivers are supported by 
freeware packages."

The chances are fair that your Ethernet card came with a packet
driver, and if so, you should try that first. If not, then you
can try one of the drivers from the Crynwr collection (formerly
called the Clarkson Drivers). See the Resource listing for info.

For 3COM drivers, try ftp ftp.3com.com. For technical information,
try [email-masked]. For marketing and product info, try
[email-masked] packet driver specification is available
from vax.ftp.com in packet-d.ascii

The following vendors have packet drivers with source available for
their pocket lan adaptors:

D-Link - +1-714-455-1688
Solectek - +1-619-450-1220
Accton - +1-415-266-9800
Compulan - +1-408-922-6888
(soon Kodiak's Noteport - +1-408-441-6900)

You can obtain a complete library of packet drivers from many of the
Simtel20 mirror sites, including:
file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip, 
file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip. 

A-3. What is Windows Sockets?  Where can I get it?

  The idea for Windows Sockets was born at Fall Interop '91, during a
  Birds of a Feather session.  

  From the Windows Sockets specification:
  [courtesy of Mark Towfiq, mailto:[email-masked]]:

    The Windows Sockets Specification is intended to provide a
    single API to which application developers can program and
    multiple network software vendors can conform. Furthermore, in
    the context of a particular version of Microsoft Windows, it
    defines a binary interface (ABI) such that an application
    written to the Windows Sockets API can work with a conformant
    protocol implementation from any network software vendor.

Windows Sockets will be supported by Windows, Windows for Workgroups,
Win32s, and Windows NT. It will also support protocols other than TCP/IP.
Under Windows NT, Microsoft will provides Windows Sockets support over
TCP/IP and IPX/SPX. DEC will be implementing DECNet. Windows NT will 
include mechanisms for multiple protocol support in Windows Sockets, 
both 32-bit and 16-bit.

Mark Towfiq writes:

    "Files and information related to the Windows Sockets API are
     available via ftp://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock, 
     which is a mirror of /pub/winsock on Microdyne.COM (SunSite has a much
     faster connection to the Internet, so you are advised to use
     that).

     If you do not have FTP access to the Internet, send a message
     with the word "help" in the body to either
     mailto:[email-masked], or mailto:[email-masked], to obtain
     information about the FTP to Mail service there."
 
  Alternative sources for the Windows Sockets specification include
  rhino.microsoft.com (an FTP server running NT), as well as the
  Microsoft forum on CompuServe (go msl).
  
  Currently NetManage (NEWT), Distinct, Spry, FTP and Frontier are shipping
  Winsock TCP/IP stacks, as is Microsoft (Windows NT and TCP/IP for
  WFW), Beame & Whiteside Software (v1.1 compliant), and Sun PC-NFS. 
  If you are looking for a Winsock.dll, you should first contact your TCP/IP
  stack vendor. Novell has one in beta for their Lan Workplace for DOS.

A-4 What is Trumpet Winsock? How can I get it to dial? 

Peter Tattam has released a shareware Windows Sockets compliant
  TCP/IP stack. You can obtain it via    
  file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip, 
  file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zipwinapps.zip, or
  file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winsock.zip.   
  
The first thing to do after you download WINSOCK.ZIP is to create
a directory for Trumpet Winsock, such as C:/TRUMPWSK, and put it
in your DOS PATH statement. 

Trumpet Winsock operates over packet drivers, or over a serial port
using its own built-in SLIP/CSLIP. If you are using a network
adapter, this means that you will have to locate a packet driver
for your adapter, and load it. Trumpet Winsock also comes with 
WINPKT, and this is loaded next, via the command
WINPKT.COM 0x60 [or whatever the software interrupt for your packet driver]

You will then enter Windows, and create a group in the Program Manager
for all the files that come with Trumpet Winsock. The stack itself is loaded
by executing TCPMAN. Applications that come with it include WinCHAT, 
a chatting program; PINGW, a ping utility; FTPW for FTP, WINARCH for Archie. 

When you first execute TCPMAN, you will be asked to fill out the setup 
information for the stack. Select whether you will be using a network
adapter or SLIP; you cannot use both. 

Since Trumpet Winsock does not yet support PPP, you will need to load the
EtherPPP driver and WINPKT prior to running Windows. EtherPPP is available via
file://merit.edu/pub/ppp/etherppp.zip. This is an Ethernet simulation driver, so you
will configure Trumpet Winsock as though it were running over an Ethernet
Packet driver, i.e. by loading WINPKT 0x60, and setting the packet driver
vector in TCPMAN to 60. 

EtherPPP comes with its own dialer, so you will need to create a dialing script.
If your TCP/IP address will be changing, you will also need to write a little
batch script to capture the assigned IP address, and insert it into Trumpet's
initialization file.  EtherPPP takes up too much RAM (121K), but otherwise
works fine.  

If for some reason you don't like Trumpet Winsock's scripting language, 
you can use any other comm program that doesn't drop carrier on exit, or 
the DIALER program, available via: 

file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip. 

As for Trumpet Winsock's built-in scripting language, the default dialout
script is LOGIN.CMD. A sample LOGIN.CMD file from Geoff Cox (mailto:[email-masked]):

#
# initialize modem
#
output atzm0\13
input 10 OK
#
# set modem to indicate DCD
#
output at&d2&c1\13
input 10 OK\n
#
# send phone number
#
output atdt0813434848\r
#
# my other number
#
#output atdt241644\13
#
# now we are connected.
#
#input 30 CONNECT
#
#  wait till it's safe to send because some modem's hang up
#  if you transmit during the connection phase
#
#wait 30 dcd
#
# now prod the terminal server
#
#output \13
#
#  wait for the username prompt
#
input 30 ogin:
username Enter your username
output \satro\r
#
# and the password
#
input 30 assword:
password Enter your password
output \my password\r
#
# we are now logged in
#
input 30 otocol:
#
# see who on for informational reasons.
#
output SLIP\r
input 30 HELLO

A-5. What publicly distributable TCP/IP applications are there for
     DOS?  Windows?

Right now there are a wealth of publicly distributable TCP/IP
applications running under DOS.  Windows also has a wealth of 
programs available, including implementations of Gopher, Mail
(POP3/SMTP), FSP, Mosaic, Telnet, FTP, IRC, and WAIS. 

See the Resource listings for information.

A-6. What software is available for doing SLIP?  Compressed SLIP?
     PPP?  For DOS?  For Windows?  For OS/2?

For SLIP or CSLIP use with DOS, I recommend using SLIPPER or CSLIPPER. 
These are packet drivers that can be used along with a dialer. For PPP, 
I recommend the EtherPPP packet driver described above.  

There is a special version of NCSA Telnet for PPP, available from
ftp://merit.edu/pub/ppp. 

KA9Q supports SLIP/CSLIP, but unfortunately can not be used as a
TCP/IP protocol stack to run other apps.

I have heard good things about IBM's TCP/IP for OS/2, but haven't
used it msyelf. Please see the FAQ from news:comp.os.os2.networking for details.

IBM, FTP Software, Beame & Whiteside, Frontier, SPRY and Netmanage also 
offer SLIP support in their products. See the resource listings for details.  

A-7. What about the software included with various books?

The software included with various books (including mine) is usually
Chameleon Sampler from NetManage. Sampler supports SLIP/CSLIP/PPP, but
not connection over a network, and includes software for FTP, Telnet,
TN3270, and Mail. The stack included with Sampler (NEWT) is Winsock
compatible, so you can run any Windows Sockets-compatible application
over it. Installation is quite a bit simpler compared with going the
Trumpet Winsock route, so this is probably the best way to go assuming
that you are a dialup IP user. 

A-8. What diagnostic utilities are available to find problems with
my connection?  Where can I get them?

Frequently used diagnostic utilities include ifconfig (checks the
configuration of the network interfaces), ping (tests IP layer
connectivity), traceroute (traces the route that a packet takes
between two sites), netstat (checks the routing table), tcpdump
(protocol analyzer), arp (looks at the IP to Ethernet address
mappings).

KA9Q includes ifconfig, ping and traceroute functions. In KA9Q hop
check is the equivalent of traceroute. The Trumpet TCP/IP stack also
has a hopchk2 command that is a traceroute equivalent.

Etherload is very useful for network profiling, while Etherdump can
be used for packet catching, although I wish it would give more
information, along the lines of TCPDUMP.  

Trumpet Winsock comes with Windows implementations of Ping and Traceroute. 

A-9. Is there a CD-ROM with the software included in this FAQ?

The Packet Driver, WinSock & TCP/IP CD-ROM is available from
CDPublishing for $29.95. This includes the packet drivers of course,
but also lots of other DOS and Windows TCP/IP stuff, including
Windows Sockets applications. It also includes the text of all
the RFCs. This is now somewhat out of date (it was cut in
December), but is otherwise highly recommended. 

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

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

The "Daytona" release of Windows NT will include support for 
PPP (client and server) and SLIP (client), both including
support for Van Jacobson header compression. 

A-11. Where can I take a peak at the WFW v3.11 VxD beta?

This is a beta release of the forthcoming 32 bit-TCP/IP stack for 
Windows for Workgroups v3.11. This is looking *very* good; it's
fast, and has worked fine for me. It also supports a host of very
nice new features, including DHCP automatic configuration, WINS
name resolution, and Windows Sockets v1.1. However, plesae not that
it does not offer SLIP or PPP support. 
The final beta release is now available via:
ftp://ftp.microsoft.com/PerOpSys/WFW/tcpip/ 

A-12. How do I get my BBS to run over TCP/IP? 

First off, let's clarify what we mean by "over TCP/IP." Usually
this means "accessible via Telnet." Be aware that doing this will
not necessarily work well, since few BBSes have been tested running
over TCP/IP. As a result you may experience frequent crashes, or
abominable transfer rates. For example, I have seen transfer rates 
as low as 100 characters/second over a 14.4 Kbps PPP connection 
which routinely supports 1600 cps transfers with FTP.

This situation might be improved by running an FTP server instead. 
This could be accomplished for example by running KA9Q in another
window under DesQView, or by putting the files on an NFS-mounted
drive, then using another machine as the FTP server. 

One way to hook up a multi-line BBS is to use a terminal server, 
and hook up the BBS's serial ports to that. The disadvantage of this is that
if your BBS is really big you will need multiple terminal servers
which will each have their own domain names and TCP/IP addresses. 
Confusing. 

Brian Clements of Murkworks has a better solution, called BBSnet. 
It provides a Telnet interface that looks like a FOSSIL driver.  The first
version runs partly as an NLM; some of the code resides on the server.
For info, contact 

BBSnet,MurkWorks, Inc., P.O. Box 631,Potsdam, NY 13676, 
+1 315 265 4717, mailto:[email-masked]

eSoft has also recently announced that they are working on a TCP/IP
compatible version of TBBS. Look for this to be shown at OneBBS
Con '94 in Atlanta. 

A-13. Are there graphical servers out there?

Yes! For Windows there is a graphical SMTP daemon which is not very
functional (it can't do as much as KA9Q); several Web servers, including
a Windows version of NCSA's HTTP, and SerWeb. 

For Windows NT, The European Microsoft Windows Academic Consortium (EMWAC) has
released Windows NT servers for Gopher, WAIS, and WWW. These servers
are easy to install, and fast, and offer the full complement of capabilities,
including support for forms, access to WAIS indices from within HTTPS, 
installation as a Windows NT service, etc. 

See the resource section for details.

A-14. What methods of address assignment are available?

Methods of address assignment include client/server protocols
(RARP, BOOTP, DHCP), as well as script-based methods 
(terminal server indicates, "your address is 192.187.147.2"). PPP
supports assignment of addresses from the server. 

As part 2 of this FAQ discusses, there are RARP and BOOTP clients
and servers available for DOS. Typically the clients work by stashing
the IP address in a DOS environmental variable. It is then your responsibility 
to modify the appropriate config files to reflect this 
address. This can be done using a DOS batch script and a utility such as 
DOS awk. This same approach can be used to modify config files when using
EtherPPP; this does not place the IP address into a variable, but the output
of EtherPPP can be piped to a file and the IP address picked off and inserted 
in the appropriate locations. If this sounds complicated, it is; be warned.

Trumpet Winsock supports script-based assignment of addresses. Microsoft 
supports a DHCP client in WFW TCP/IP, and both client and server in Windows NT. 
There is also a forthcoming DHCP server for Sun. 

A-15. How can I set up PPP server on a UNIX host? 

This is not the appropriate place to address that question, but lots
of info on this is available in the comp.protocols.ppp FAQ. 

A-16. What is WinSNMP? 

WinSNMP is an API which provides a standard interface to to the
Simple Network Management Protocol (SNMP) for network
management applications running under Windows. Applications written to 
WinSNMP can run on any WinSNMP-compatible implementation. 

Vendors supporting WinSNMP include FTP Software, which supports it
in both OnNet 1.1, and PC/TCP 3.0. 

B. Questions about drivers

B-1. What do I need to know before setting up SLIP or PPP?

Before setting up your SLIP or PPP connection, you should
have available the following information:

* The domain name and TCP/IP address of your host.
* Whether your TCP/IP address will be assigned statically,
  dynamically, or from the server.
* If from the server, whether you will be using RARP, BOOTP or DHCP. 
* The domain name and TCP/IP address of your machine (if you are not
  configuring the address dynamically or via BOOTP)
* The domain name and TCP/IP address of the primary and secondary
  Domain Name Server.
* The subnet mask.
* The domain name and TCP/IP address of an NNTP server.
* Whether your host supports POP, and if so, what version.
* Whether the host supports compressed or uncompressed SLIP, or PPP.
* The size of the Maximum Receivable Unit (MRU). 

Do not attempt to connect to your host before you have this
information, since it will just waste your time and money, and may
cause problems for the network.  In particular, do not attempt to
initiate a connection using a made up TCP/IP address! It is possible
that your made-up address may conflict with an existing address.  

This is probably the quickest way to get people very angry at you.

Static addressing means that your TCP/IP address will always
be the same. This makes it easy to configure your setup files.
Dynamic addressing means that the host will send you a message
containing your TCP/IP address when you log on. This can be
problematic if your software doesn't support grabbing the address
and inserting it into the setup files. If not, then you may have
to edit your setup files every time you log on. Yuck!

Chameleon NFS includes a version of SLIP which can handle dynamic
addressing. The most recent version of Novell's Lan Workplace for
DOS does as well. 

You can also retrieve your address using RARP, BOOTP or DHCP. RARP
is only available to those on the same LAN as the RARP server, since
it uses broadcasting. BOOTP clients can access BOOTP servers on other
LANs via BOOTP relay. DHCP is a BOOTP extension, which allows
complete configuration of a client from info stored on a DHCP server, and in
addition supports new concepts such as "address leases". Since
DHCP frames are very similar to BOOTP frames, devices supporting BOOTP relay 
will also support DHCP relay. 

Of course, for DHCP or BOOTP to work, you will need to set up a DHCP
or BOOTP server. DHCP servers are available for UNIX, and Windows NT.

PPP also supports server assignment of TCP/IP addresses.

B-2. How do I configure SLIPDIAL?

From Ashok Aiyar, mailto:[email-masked]:

PHONE Script Files:

PHONE comes with several scripts (for various modems) and for the
University of Minnesota Terminal server built into it.  The command
PHONE WRITE writes these scripts to an ASCII file called PHONE.CMD,
which can be edited to your needs (modem and slip server)

The documentation that accompanies PHONE, provides good instructions on
writing script files to get PHONE to dial SLIP servers other than
the University of Minnesota server.  For example here is a script
that I use to dial a CISCO server at the University that I attend.

Background:  To start a SLIP connection, I dial our terminal server,
and login with a username and password.  After doing so, I start a SLIP
session with the following command "slip username-slip.dialin.cwru.edu",
followed by my password -- again.

Here then is the relevant portion of the PHONE.CMD script file -
#
# CWRU-TS2 SLIP login script by Ashok Aiyar 3/26/93
# Last revised 3/28/93
Procedure    Host.CWRU.Login
TimeOut 60      'CWRU-TS2 terminal server is not responding'
Message         "CWRU-TS2 SLIP login script -- Version 1.1"
Message         'Waiting for SLIP server to respond'
Quiet ON
Expect 'Verification'
Message         'Request for User Verification Received from CWRU-TS2'
Message         'Sending your user name and password'
Quiet OFF
Expect   'Username:'
Send '%u<'
Expect   'Password:'
Private
Send '%p<'
Reject    'Access denied'   'Your user name or password was not accepted'
TimeOut 30    'SLIP server did not respond to your validation request'
Expect 'CWRU-TS2>'
Send 'SLIP<'
TimeOut 10    'SLIP server did not respond to SLIP command'
Expect 'IP hostname or address:'
Send '%u-slip.dialin.cwru.edu<'
TimeOut 10 'SLIP server did not respond to hostname'
Reject    'Bad IP address'   'Incorrect Hostname'
Expect 'Password:'
Send '%p<'
Reject    'Access denied'    'Password not accepted.'
TimeOut 10
Expect 'Header Compression will match your system'
Message 'Login to CWRU SLIP server successful'
Wait 1.0
EndProcedure   Host.CWRU.Login
#
#
Procedure      Host.CWRU.LogOut
# Nothing special needs to be done to logout
EndProcedure   Host.CWRU.LogOut
#
#   End of Script file
#
----------------------------------------------------------------------
How to use packet drivers other than UMSLIP with PHONE?

The quick answer -- there is no "clean" way.  Below is a batch file
hack that I wrote to use PHONE with other packet drivers.  In this
example, the packet driver is Peter Tattam's CSLIPPER.  To use a
batch file like this, you must know the parameters with which you
plan to use the packet driver -- i.e interrupt vector, baud rate,
port address, and IRQ.  This batch file requires UMSLIP.COM,
CSLIPPER.EXE, and TERMIN.COM to be in the same directory
or in your path ...

All that the BATCH file does is to let you dial the SLIP connection
using PHONE, load the appropriate packet driver, hangup the
connection, and unload the driver when you are done ...

-- being CWRUSLIP.BAT --
@echo off
rem   this batch file is an ugly hack of U. of Minn. "SLIP.BAT"
rem   awaiting a version of C/SLIPPER that can directly interact
rem   with PHONE
rem   CWRUSLIP.BAT file is used with PHONE.EXE to start a SLIP
rem   connection on CWRU-TS2
rem   last modified 3/28/93 -- Ashok Aiyar

@echo off
cls
goto start

:start
if %1. == ?.         goto help
if %1. == help.      goto help
if %1. == setup.     goto setup
if %1. == dial.      goto forceD
if %1. == hangup.    goto forceH
if %1. == quit.      goto forceH
if %1. == HELP.      goto help
if %1. == SETUP.     goto setup
if %1. == DIAL.      goto forceD
if %1. == QUIT.      goto forceH
goto bogus
goto unload

:forceH
termin 0x60
umslip >nul
phone force hangup
goto unload

:slipper
termin 0x60
REM  the following line must be changed to reflect the COM port,
REM  IRQ, baud rate, and software interrupt
lh c:\packet\cslipper com1 vec=60 baud=57600 ether
goto end

:forceD
termin 0x60
umslip >nul
phone force dial
goto slipper

:setup
termin 0x60
umslip >nul
phone setup
goto help

:unload
termin 0x60
goto end

:bogus
echo %1 is not a valid command.
echo Try "cwruslip help" for a list of valid commands
echo.

:help
echo --------------------------------------------------------------
echo           Case Western Reserve University SLIP Setup
echo                  using Univ. of Minnesota PHONE
echo --------------------------------------------------------------
echo cwruslip setup     modem settings, phone number, username etc.
echo.
echo cwruslip dial      DIAL and establish the SLIP connection
echo cwruslip quit      HANGUP the phone and unload the driver
echo cwruslip help      this screen
echo.

:end
-- end CWRUSLIP.BAT --

B-3. How do I install packet drivers for Windows applications?

How do I install packet drivers for Windows applications?

The secret is to load the packet driver, then run Windows. If you
are running Trumpet Winsock, you will also have to load WINPKT
before running Windows, as follows:

winpkt 0x60

If you are running DOS applications within a virtual DOS session
under Windows, you should load PKTMUX after your packet driver, as
follows:

PKTMUX 4 [or however many sessions you want]
WIN [load windows]
 
Then within each DOS session, load PKTDRV, the virtual packet driver.

If you are running Trumpet Winsock along with other DOS apps in a 
virtual DOS session, then you will need to load PKTDRV prior to
loading Windows, and then load WINPKT on top of it, as follows:

PKTMUX 4
PKTDRV 0x62
WINPKT 0x62
PKTDRV 0x60
WIN

TCPMAN will then find the virtual packet driver at 0x62. 

B-4. When do I need to install  WINPKT? 

PKTMUX and WINPKT both accomplish the same thing: allowing you to
connect to a DOS packet driver running in real mode from a virtual
DOS session under Windows. PKTMUX is useful when you are running
more than one TCP/IP stack, and since it takes up more RAM and is
slower than WINPKT, you should only use it when you want to run more
than one stack at a time. If you are running only one DOS app,
or are using Trumpet Winsock, stick with WINPKT. 

James Harvey (mailto:[email-masked]) 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:[email-masked]) notes:
Windows in enhanced mode uses the protected mode of the
386 CPU to create multiple virtual machines.  Winpkt tells
Windows to switch to the correct virtual machine before
trying to pass up the packet.  This reduces the chances of
Windows crashing.

B-5. How to do I run both WinQVT and ODI?

My advice is to use the Windows Sockets version of WinQVT/Net, Trumpet
Winsock, and ODIPKT. ODIPKT will allow you to run packet driver software
over ODI. You will also need to load WINPKT for Trumpet Winsock. 

The loading sequence is:

LSL [Link support layer]
NE2000.COM [or other ODI driver]
IPXODI [IPX version supporting ODI]
NETX
ODIPKT 1 96
WINPKT 0x60
WIN [run windows]

Then run Trumpet Winsock, and load WinQVT/Net. 

B-6. Is it possible to use BOOTP over SLIP?

Yes, but it is easier to use dynamic address assignment to get 
your IP address. This is where the SLIP server outputs your IP address 
before switching to SLIP. 

If you need BOOTP, then you should run a BOOTP server on the SLIP
server so that it can tell which SLIP connection originated the
request. Of course, the BOOTP server will ignore the hardware address
of the request originator, but instead will keep track of the SLIP
interface the request came in on. See the question on adding BOOTP to
KA9Q for info on how to handle this on the PC. Under UNIX, you may
have to add BOOTP capability to your slip driver, and rebuild the
kernel. (Not recommended for the squimish). 

B-7. How do SLIP drivers work? 

Some TCP/IP applications are written to only support Class 1 (Ethernet)
packet drivers, but do not support Class 6 (SLIP). For these applications, you
need software to make the application think it is dealing with a class 1
interface. This is done by adding fake ethernet headers to incoming 
SLIP or PPP packets and stripping the headers off outgoing packets. 

B-8. When do I need to install PKTMUX?

PKTMUX is needed to allow you to use more than one TCP/IP stack at the same 
time. This is useful if you have applications that require different stacks. 
Note that you do not need PKTMUX to run different protocols, since packet 
drivers only look at packets in the protocol they're designed to handle, 
and therefore you can use more than one of these at a time without conflict. 
You also don't need PKTMUX if all your applications use the same TCP/IP stack. 

PKTMUX works by looking at outgoing datagrams, and caching information on 
source and destination ports and addresses. Using this information, PKTMUX
tries to sort incoming datagrams by TCP/IP stack. If it can't figure out
which stack to send a datagram to (as might be the case if you were running
a server application on a well-known port, and had not sent any outgoing
packets yet), PKTMUX will send the datagram to all stacks. If all stacks
do not complain about the datagram, PKTMUX will throw away the ensuing outgoing
ICMP error message, assuming that one of the stacks correctly received
the datagram. If all stacks complain, it will send a single ICMP message
and throw the rest away.

While PKTMUX does its job very well, there are some situations that it cannot
handle, such as port conflicts. If two applications open the same TCP port,
chaos is inevitable, and there is little that PKTMUX can do to help. 

B-9. Can NDIS be used underneath multiple protocol stacks of the same type?
No. There is no equivalent to PKTMUX for NDIS.  

B-10. Is there an NDIS over packet driver shim? 
Joe Doupnik writes:

"No. Packet Drivers work by having an application register
for a particular packet TYPE, such as 0800 for IP. NDIS works much
differently, by offering a peekahead of every packet to applications in turn,
a polling operation. The only way NDIS could gracefully sit on a PD would
be to run the Packet Driver in all-types mode and let NDIS see all pkts
not used by other clients. Needless to say, that's an undesirable situation.
The quick solution, costing about US$100 (at least at my place,
more at yours) is a second Ethernet board in the client together with a
second IP address (most important, please)."

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

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

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

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

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

According to Chip Sparling of FTP Software:

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

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

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

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

WINS will be included in the next WFW TCP/IP release, which is currently
in beta test and available for download from ftp.microsoft.com. Consult the 
beta release documentation for more information on this. 

B-12. How do I run NFS along with another TCP/IP application?

The DOS NFS implementation by M. Durkin now supports a built-in
packet multiplexer that can handle NFS plus another stack loaded
simultaneously. If you need to load more stacks, then you will need
to run PKTMUX as well.

See the resource section for details. 

B-13. How do I run Trumpet Winsock along with KA9Q or NFS? 

The secret is to load WINPKT on top of the PKTDRV virtual
packet driver, if you are running PKTMUX. 

B-14. Sample Stick Diagrams

It has been proposed that we begin to collect some diagrams of working
combinations of hardware, drivers, shims, stacks, and applications. I'm
game, and have made a start below. If you've got some other exotic
configuration that works (or if you've tried one of the configurations below
and discovered it doesn't work, drop me a line).

   Running an individual DOS application under Windows

    NCSA telnet / DOS Trumpet / POPmail/ PC Gopher III
                 |
             DOS Session
                 |
             Windows 3.1
                 |
               WinPKT
                 |
            Packet driver or Shim
                 |
                DOS
		 |
           Network Adapter

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

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

PC Gopher III, NCSA Telnet over CSLIP under Windows

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

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

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

PC Gopher III and NetWare on a LAN - Alternative II

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

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

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

WinQVT/Net, PC Gopher III and NetWare over a LAN - Alternative II
	
	                                         QVT/Net
  PC Gopher III                 NCSA telbin        |
       |                             |             |            
     PKTDRV1        .....        PKTDRVn           |
       |           |                 |             |
     DOS Session                DOS Session    Windows Session
       +-----------+-----------------+             |
                   |                               |                                  
		   |                               |            
             WINDOWS 3.1 .......................WINDOWS 3.1
                   |                               |
                   |                      PKTINT(QVT/NET own)
                   |                               |
                   |                           PKTDRVx
              	   |	                           |      
		   |		                   |
		   |		                   |
		   |		                   |
		   +------------------+------------+
				      |
                    NetWare            |
                        \            /
                      NETX         PKTMUX n (use if >1 TCP/IP app)
                          \        /
                        IPXODI   ODIPKT
                             \   /
                              \ /
			       |
		        Link Support Layer
                               |
                           ODI driver
                               |
			  Network Adapter

PC Eudora and Windows Trumpet over CSLIP under Windows using Trumpet Winsock

 PC Eudora    Windows Trumpet
     \         /
      \       /
       \     /
        \   /
       TCPMAN
          |
     Windows 3.1
	  |
     WINPKT 0x60
          |
         DOS
          |
      Serial Port
      
PC Eudora and Windows Trumpet supporting Ethernet and CSLIP under Windows 
using NDIS supporting stack [Chameleon]

[Please note: this is not possible under Trumpet Winsock, since it can
only handle a single interface; it requires a stack that routes]

 PC Eudora    Windows Trumpet
     \         /
      \       /
       \     /
        \   /
      Chameleon NEWT
          |
      Windows v3.1
          |
	  +------------------+
	  |                  |
    Protocol Manager         |
          |                  |
      NDIS Mac Driver     Serial Port
          |
         DOS
          |
     Ethernet card

PC Eudora, Windows Trumpet, and KA9Q under Windows

       WinTrump   PC Eudora
            \     /
             \   /
 KA9Q         \ /
   |           |
 PKTDRV      TCPMAN
     \         |
      \       /
       \     /
        \   /
	 \ /
        Windows
          |
        PKTDRV 0x62
	  |
        PKTMUX 2
          |
     Packet Driver
          |
         DOS
          |
     Ethernet Card

HGopher, PC Eudora, and WinTrumpet Under Windows
(Whether the TCP/IP stack is loaded before or
after Windows depends on the stack)

       HGopher
         |       
         |
   PC    |
 Eudora  |  WinTrumpet
     \   |   /
      \  |  /
       \ | /
        \|/
       TCPMAN
         |
     Windows 3.1
         |
      WINPKT
         |
  Packet Driver
         |
        DOS
         |
   Ethernet Card

B-15. Strange and wonderful configuration files submitted by readers

Robert Clift (mailto:[email-masked]) writes:

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

Here is the stick diagram (yikes!): 

Win/QVTNet 3.7     KA9Q Gopher      PC POPMail 3.2     PC Gopher III 1.01
on interrupt 65    & FTP Server           \                    /
    \                  |                    \                /
      \                |                      \            /
        \              |                        \        /
          \          PKTDRV                       PKTDRV
            \          |                            /
              \      DOS Session               DOS Session
                \      |                        /
                  \    |    -------------------       
                    \  |  /                 
                  Windows 3.1
                       |
                     PKINT
                       |
         PKTDRV on Int 65 no listeners set
                       | 
           PKTMUX 1.2 with 3 channels
                       |
          Clarkson 3C503 Packet Driver
	               |
	              DOS
                       |
           3Com Etherlink II/16 TP
                       |
                    Ethernet

NOTES:

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

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

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

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

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

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

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

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

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

C. KA9Q Questions

C-1. What version of KA9Q should I use and where do I get it?

There are so many releases of KA9Q that it is a significant amount of
work just to keep track of them all. This has occurred partly because
KA9Q does not support extended or expanded memory, and therefore many
people have needed to customize it with the features relevant to them
in order to allow it to do what they want as well as fit into memory. 
The primary difference among the various releases is whether they 
include code for a BBS, packet radio support (AX.25), synchronous cards (for
use with leased lines), NNTP, CSO or Gopher servers, packet filtering, DNS,
RIP or PPP support. 

The three primary KA9Q releases at this time are those managed by Ashok Aiyar
([email-masked]), those put out by Demon Internet
Services (DIS), and the JNOS distribution. JNOS is the primary packet radio-
oriented release; the other two major releases do not include AX.25 support.
Since JNOS does not include several features important to non-packet radio
users (DNS/Gopher/CSO server, hop check), try one of the other two releases
if you're not interested in packet radio.

Ashok's release is based on the N1BEE 0.85-beta which in turn 
is based on PA9GRI 2.0m NOS. Version 11c includes support for NTP, CSO,
gopher, FTP, FINGER, HTTP and SMTP/POP2/POP3 servers, plus VT102 and packet 
filtering support. Please not that this release does *not* include radio or 
synchronous card support, unlike the standard KA9Q release, and only support 
SLIP/CSLIP. Also, there is no DNS server support, and the tip command has been 
removed, so that you need to use an external dialer to make the connection.

Available as:

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

The TextWin version from Demon Internet Services includes support for DNS server, packet filtering, FTP, SMTP/POP2/POP3 servers, NNTP server, VT102 support, NTP, BBS, SLIP/CSLIP,PPP (I don't know anyone who has gotten this to work), demand dial, ping, hop check (traceroute equivalent). 

From mailto:[email-masked] (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:[email-masked] but other
DIS users do support them. All these programs can be found on
ftp://ftp.demon.co.uk/pub/ibmpc/ and are written to
work with KA9Q (specifically the DIS version)."

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

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

Editorial: To my mind, the time has come for the major releases to combine 
their code bases and produce a version with the best features of all of them. 
To my mind, the ideal KA9Q release would be a release combining the improved 
server support of the CWRU release with a working PPP implementation, demand 
dial, and DNS server support. 

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

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

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

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

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

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

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

Here is a sample CSLIP only configuration file, which was
written for Demon Internet Service's version of KA9Q (as
are all other KA9Q sample configs in this FAQ): 

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

dialer.sl0 file:

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

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

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

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

Other possible diagnostic commands:

ASYSTAT <interface>	Gives statistics on packets received, sent, etc.
TRACE <interface> 1011	Shows incoming characters
RIP TRACE 1		Traces RIP packets
HOP CHECK <address>	Traces the route to the designated system. Useful 
			for figuring out routing problems. 

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

The KA9Q configuration that follows uses two interfaces, one a PPP
interface (pp0), the other an Ethernet interface (lan). Here I
am implementing dial on demand, and can also be doing packet 
filtering, and DNS serving on the same box. 

Please note the strange interrupt settings (Interrupt 5, port is COM3).  One of 
the nice things about KA9Q is that it is flexible enough to deal with 
such situations.

Here is a sample router configuration file:

# This config file is for use with the large TextWin 
# version of KA9Q available from ftp.demon.co.uk
#
# Set the host name
#
hostname gate.foobar.com
#
# Configure COM3 on Interrupt 5, at 38400 bps with 
# RTS/CTS (c) and PPP
# 
attach asy 0x3e8 5 ppp pp0 8092 576 38400 c
ifconfig pp0 ipaddress [192.187.147.2] 
ifconfig pp0 netmask 255.255.255.0
dialer pp0 dialer.ppp demand
#
ppp pp0 trace 2
ppp pp0 quick
ppp pp0 lcp open
ppp pp0 ipcp open
#
# Packet driver installed at software interrupt 
# number 0x60.
#
attach packet 0x60 lan 2 1500
ifconfig lan ipaddress [192.187.157.4] 
ifconfig lan etmask 255.255.255.0
#
route add default pp0
#
# The local Ethernet has a Class C network address so
# route all IP addresses beginning with 192.187.157 to 
# it.
route add 192.187.157/24 lan
#
# Time To Live is the maximum number of hops a packet 
# can take before it is thrown away.  This command 
# prevents packets from looping infinitely. 
#
ip ttl 255
#
# The Maximum Segment Size is the largest single 
# transmission that you care to receive.  An mss of 216 
# will force folks to send you packets of 256 characters 
# or less (counting the overhead). 
#
tcp mss 576
#
# The Window parameter establishes the maximum number 
# of bytes that may be outstanding before your system 
# expects an ack. If window is twice as big as mss, 
# for example, there will be two active packets on the 
# channel at any given time.  Large values of window 
# provide improved throughput on full-duplex links, but 
# are a problem on the air.  
# Keep  mss <= window <= 2*mss if you're on the air.
#
tcp window 6888
#
# This entry will open net.log in the \spool directory 
# and will record the server activity of your system.  If 
# you don't want a log, comment out this line; if you do, 
# make sure you have a \spool directory!
#
log \textwin\spool\net.log
#
# Each of the servers (services you will provide) must 
# be turned on before they will be active.  The 
# following entries turn all of them on.  To turn any 
# function off use the command 'stop' after NET gets 
# fired up, or just comment out the line here.
#
start ftp
ftpopt binary
start echo
start discard
start telnet
start smtp
# This machine will act as a DNS server;
# Boot file is c:\textwin\named.boo, configuration
# goes in c:\textwin\spool\zones
domain startdns
# Command indicating presence of IBM AT
isat on
#
smtp gateway 192.187.157.2
#
# Use Router Information Protocol (RIP) to inform 
# the router at 192.187.147.253 about the existence 
# of the local network. Send RIP packets every 240 
# seconds. Only useful for dedicated routers.
rip add 192.187.147.253 240
#
# THE END

dialer.ppp file:

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

Here is another routing configuration file, using CSLIP and proxy arp:

# This config file is for use with the large TextWin 
# version of KA9Q available from ftp.demon.co.uk
#
# Set the host name
#
hostname gate.foobar.com
#
# Configure COM3 on Interrupt 5, at 38400 bps with 
# RTS/CTS (c) and Van Jacobsen Compression (v) and
# MTU = 1008
# 
attach asy 0x3e8 5 vjslip sl0 8092 1008 38400 cv
ifconfig sl0 ipaddress [157.151.0.253] 
ifconfig sl0 netmask 255.255.255.0
dialer sl0 dialer.sl0
#
#
#
# Packet driver at 0x60; probably an Ethernet card
#
attach packet 0x60 lan 2 1500
ifconfig lan ipaddress [157.151.64.1] 
ifconfig lan netmask 255.255.255.0
#
# route all packets over sl0 by default (sl0 is the route 
# to the Internet)
#
route add default sl0
#
# The local Ethernet has a Class C network address so
# route all IP addresses beginning with 157.151.64 to it.
route add 157.151.64/24 lan
#
#  Use Proxy ARP
arp publish 157.151.64.1 ether 00:00:c0:33:f3:13
arp publish 157.151.64.254 ether 00:00:c0:33:f3:13
#
# Time To Live is the maximum number of hops a packet 
# can take before it is thrown away.  This command 
# prevents packets from looping infinitely. 
#
ip ttl 255
#
# The Maximum Segment Size is the largest single 
# transmission that you care to receive.  An mss of 216 
# will force folks to send you packets of 256 characters 
# or less (counting the overhead). 
#
tcp mss 576
#
# The Window parameter establishes the maximum number 
# of bytes that may be outstanding before your system 
# expects an ack. If window is twice as big as mss, 
# for example, there will be two active packets on the 
# channel at any given time.  Large values of window 
# provide improved throughput on full-duplex links, but 
# are a problem on the air.  
# Keep  mss <= window <= 2*mss if you're on the air.
#
tcp window 6888
#
# This entry will open net.log in the \spool directory 
# and will record the server activity of your system.  If 
# you don't want a log, comment out this line; if you do, 
# make sure you have a \spool directory!
#
log \textwin\spool\net.log
#
# Each of the servers (services you will provide) must 
# be turned on before they will be active.  The 
# following entries turn all of them on.  To turn any 
# function off use the command 'stop' after NET gets 
# fired up, or just comment out the line here.
#
start ftp
ftpopt binary
start echo
start discard
# start telnet
start smtp
# This machine uses primary and seconary DNS servers
# to resolve addresses
#
domain addserver 157.151.0.2
domain addserver 157.151.0.1
smtp gateway 157.151.0.2
#
# Command indicating presence of IBM AT
isat on
#
#
#
# THE END

dialer.sl0 file:

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

C-5  How do I get KA9Q to support BOOTP?

The CWRU NOS version has a working BOOTP client and server built-in,
and is the best version if you are looking for BOOTP support.
[Does Textwin offer full BOOTP support?]
If you are using another version of KA9Q that does not support BOOTP,
try the following: 

Steven L. Johnson (mailto:[email-masked]) notes:

  KA9Q does have a bootp client but it is not compiled in by default.
  It has a bug that truncates the returned ip address to 16 bits
  which must be corrected before it will work.  It also complains
  about bootp servers that only support RFC 951 bootp without RFC
  1084 (or 1048) vendor extensions.  Other than that it seems to work
  for me.

  To enable the bootp client, add the following line to config.h:

    #define BOOTP 1

  To correct the ip address truncation problem, in bootp.c change:

                Ip_addr = (int) reply.yiaddr.s_addr;    /* yiaddr */
                          ^^^^^problem
  at line 188 to:

                Ip_addr = (int32) reply.yiaddr.s_addr;    /* yiaddr */
                          ^^^^^^^solution

  And of course, recompile.

  This worked on the src1229 (1991) version and may work on the
  most recent version.  I did check to make sure that the bug still
  exists, but I haven't rechecked whether there are additional
  problems in the new version.

C-6.  How do I get KA9Q to support PPP?

Although I haven't gotten this to work yet, there is hope. 
The only major version of KA9Q supporting PPP is the TextWin version.
Here is a sample ppp configuration file for it: 

# Set the host name
#
hostname aboba.slip.netcom.com
ip address [192.187.134.3]
#
#
#
# Configure COM3 on Interrupt 5, at 38400 bps with
# MTU = 1008
#
attach asy 0x3e8 5 ppp pp0 8092 1008 38400
dialer pp0 dialer.ppp
ifconfig pp0 netmask 255.255.255.252
ppp pp0 trace 2
ppp pp0 quick
ppp pp0 lcp open
ppp pp0 ipcp open
#
#
#
route add default pp0
# route all packets over pp0 by default (pp0 is the route to
# the Internet)
#
# Time To Live is the maximum number of hops a packet can take
# before it is thrown away.  This command prevents an inadvertent
# infinite loop from occuring with packets in the network.
#
ip ttl 400
#
#-------------------------------------------------
#
# The Maximum Segment Size is the largest single transmission that
# you care to receive.  An mss of 216 will force folks to send you
# packets of 256 characters or less (counting the overhead). 
#
tcp mss 1048
#
#-------------------------------------------------
#
# The Window parameter establishes the maximum number of bytes that
# may be outstanding before your system expects an ack.  If window is
# twice as big as mss, for example, there will be two active packets
# on the channel at any given time.  Large values of window provide
# improved throughput on full-duplex links, but are a problem on the
# air.  Keep mss <= window <= 2*mss if you're on the air.
#
#
tcp window 6888
#
#-------------------------------------------------
#
# This entry will open net.log in the \spool directory and will
# record the server activity of your system.  If you don't want a log,
# comment out this line; if you do, make sure you have a \spool
# directory!
#
log \spool\net.log
#
#-------------------------------------------------
#
# Each of the servers (services you will provide) must be turned
# on before they will be active.  The following entries turn all
# of them on.  To turn any function off use the command "stop" after
# NET gets fired up, or just comment out the line here.
#
start ftp
start echo
start discard
#start telnet
start smtp
#
isat on
#
domain addserver 192.100.81.101
domain addserver 192.100.81.105
smtp gateway 140.174.7.1
#
#
#  Display Name and IP Address
#
hostname
ip address
#
# THE END

In file dialer.ppp:

control down
wait 1000
control up
wait 1000
wait 2000
send "at\r"
wait 3000 "OK"
send "atdt8659004\r"
wait 60000 "login: "
send "<userID>\r"
wait 5000 "word:"
wait 1000
send "<password>\r"

C-7. How do I get KA9Q to support SLIP dialin?

If you are willing to settle for little or no security, there is not
much you have to change to allow a KA9Q system to receive calls, as
opposed to originating them. These should include:

1. Setting the system to autoanswer, via use of the ATS0=1 command to
the modem. 

2. Setting up a trace on the router end, to figure out if it's working,
via the command:
TRACE <interface> 1011, where <interface> = sl0 for SLIP, or another
value such as LAN or ether0 for the Ethernet interface. It's probably
a good idea to put a trace on all interfaces until the system is
shaken down. 

Note that without addition of a special dialing script, this setup
is completely insecure! 

C-8.  Can I use KA9Q as a packet filter? 

Yes! Both the TextWin Large and CWRU NOS versions support this. You can
filter by incoming or outgoing, TCP or UDP port number, IP address, SYN
bit on, etc. 

D. Hints for particular packages

D-1. How do I get DesQView X to run over the network?

V1.0 of DesQView X did not include a TCP/IP protocol stack.
Surprise! It required a TCP/IP implementation such as Beame & Whiteside,
PC-NFS, FTP's PC/TCP, or Novell LWP. They've corrected the situation 
in subsequent revisions. Contact QuarterDeck for assistance.

[pricing and availability, anyone?]

D-2. Why is NFS so slow compared with FTP?

NFS usually runs over RPC via UDP, rather than utilizing TCP. NFS only 
acknowledges a write request when the disk completes; there
are no sliding windows as in TCP. This makes NFS fairly inefficient.

Frances K. Selkirk ([email-masked] ) notes:

"There are NFS implementations that use TCP. They are only
faster over WANs. UDP is faster over most normally functioning LANs.
The lockstep paradigm is inherent to NFS, but some implementations
provide the ability to violate it - a speed win when the net is
reliable, a loss when it is not.

Whatever the transport, NFS will have more overhead than TCP, because
it is trying to transparently imitate an OS, and has to do a lot of
shuffling and translating."

D-3. Where can I get information on running NetWare and TCP/IP
      concurrently? 
      
The bit.listserv.novell group regularly posts a FAQ
which includes information on concurrent use of TCP/IP and Novell
IPX. 

D-4. What NetWare TCP/IP NLMs are out there and how do I get them
      to work? 

A public and known to work reliable TFTP and BOOTP daemon for NetWare
OS 3.1x/4.0x and NetWare/IP are available from 
file://ftp.novell.de/~/pub/netwire/unsupported/server/bootpd.exe. 
Contact: mailto:[email-masked]

D-5. How do I get a telecom package supporting Int 14h redirection
      to work? 

INT 14 is the BIOS serial port interrupt. "Int 14h redirection" means
that Interrupt 14 is redirected to a Telnet connection to a 
particular host. This is useful because it allows a communications 
application to readily support telnet. Int 14h support is becoming 
increasing common, with vendors such as Mustang (QMODEM Pro) and
Procomm Plus for networks having included this feature. 

Aside from commercial stacks (such as FTP's PC/TCP),
try the TCPPORT program in WATTCP, available via 
file://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.

D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP?

Rumour has it that there is a serial NDIS driver available called
NBR11. This is available via ftp://complab.gtri.gatech.edu/pub/lanman/ndis.  

D-7. How do I get Windows For Workgroups to work alongside NetWare?

ODINSUP from Novell is an NDIS over ODI shim. This allows you to run 
software requiring ODI drivers, as well as software requiring NDIS 
drivers. Since IPX and TCP/IP are different protocols, you will not
need to run PKTMUX. 

Available via 
file://ftp.novell.com/netwire/novfiles/client.kit/doswin/files/WSDOS1.EXE. 

D-9. How come package X doesn't support the AppleTalk packet driver?

An AppleTalk driver is available as appletlk.com as part of the Crynwr 
driver set. NCSA Telnet 2.3.03 and NuPOP support it, but very few other
applications do, including Trumpet Winsock. This is because AppleTalk
corresponds to packet driver class 5, while most applications only
support Class 1 (Ethernet). 

Vendors with Windows Sockets implementations that support AppleTalk include
FTP Software's PC/TCP. WinQVT/Net's built-in TCP/IP stack version is also
rumored to be due to support AppleTalk in a future release.

D-10. NCSA Telnet doesn't reassemble fragments. What should I do?

Yell at the folks at NCSA to fix the problem, and to notify all
the people who are using the same TCP/IP code to insert the fix in
their software as well. This problem is really common, and
very annoying, and affects NCSA Telnet as well as PC Gopher III,
and POPmail. One possible workaround is to set the MTU to 576,
but this will not always work.

The following solution has been provided by Matthew T
Kaufman (mailto:[email-masked]):

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, [email-masked]")
    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:
[email-masked]. I am willing to help, within the limits of my schedule.

changes follow:

file: engine\ip.c (the only file that needs to change)

delete the following:
>/*
>*  We cannot handle fragmented IP packets yet, return an error
>*/
>
>    if(p->i.frags &0x20) {           /* check for a fragmented packet */
>        netposterr(304);
>        return(1);
>      }

----------
after the line:
>    iplen-=hlen;

but before the lines:
> /*
> *  check to make sure that the packet is for me.

add this:

	/* check for fragment and handle. note that the &0x20 above is WRONG */
    if(p->i.frags)           /* NOW check for a fragmented packet - mtk add*/
    {
	ipfraghandle(p,iplen);	/* pass in computed iplen to save time */
        return(1);
      }

----------
and then, at the end of that file (ip.c) add this:

/*
* IP Fragment Reassembly Hack
* by Matthew T Kaufman ([email-masked])
* 1/1993, 8/1993
*/

typedef struct ipb {
        DLAYER d;
        IPLAYER i;
        uint8 data[4104];	/* "Big Enough" */
}FIPKT;

#define IPF_CHUNKS 513 /* 4104 / 8 */
#define IPF_BITWORDS 18  /* 513 / 32 round up + 1*/
#define IPF_BUFFERS 7  /* Max # of different fragmented pkts in transit */

typedef struct {
	FIPKT pkt;
	unsigned long bits[IPF_BITWORDS];
	int lastchunk;
	unsigned long lasttime;
	unsigned int iplen;
}FPBUF;

static FPBUF far Frag[IPF_BUFFERS];

ipfraghandle(IPKT *p, int iplen)
{

	uint16 fraginfo;
	uint16 foffset;
	uint16 iden;
	FPBUF far *buf;
	int i;

	fraginfo = intswap(p->i.frags);
	foffset = fraginfo & (0x1fff);
#define morefrags (fraginfo & (0x2000))

	iden = intswap(p->i.ident);

/* we already KNOW that this IS fragmented */
/* see if we can find any friends who've already arrived... */

	buf = (FPBUF *) 0L;
	for(i=0; i<IPF_BUFFERS; i++)
	{
		if(p->i.ident == Frag[i].pkt.i.ident)
		{
			buf = &(Frag[i]);
			goto foundfriend;
		}
	}
	/* otherwise, we must be the first one here */
	{	
		long oldtime = 0x7fffffff;
		int oldest = 0;

		for(i=0; i<IPF_BUFFERS; i++)
		{
			if(Frag[i].lasttime == 0)	/* unused buffer? */
			{
				buf = &(Frag[i]);
				goto foundempty;
			}

			if(Frag[i].lasttime < oldtime)	/* track LRU */
			{
				oldtime = Frag[i].lasttime;
				oldest = i;
			}
		}

		/* if we're here, we need to reuse LRU */

		buf = &(Frag[oldest]);

foundempty:	;
		/* initialize new buffer */
		/* time will be filled in later */

		for(i=0; i<IPF_BITWORDS; i++) buf->bits[i] = 0L; /* reset */
		buf->lastchunk = 0;	/* reset */
		/* fill in the header with the current header */
		movmem(p,&(buf->pkt), sizeof(DLAYER) + sizeof(IPLAYER) );
	}

foundfriend: ;

	/* now, deal with this specific fragment... */
	/* copy data */
	movmem(&(p->x.data),&(buf->pkt.data[8 * foffset]),iplen);
	/* update rx chunks information */
	for(i=foffset; i<= (foffset+(iplen / 8)); i++)
	{
		buf->bits[i/32] |= (unsigned long) (1L<<(i % 32));
	}

	if(!morefrags)
	{
		/* now we can tell how long the total thing is */
		buf->iplen = (8*foffset)+iplen;
		buf->lastchunk = foffset;
			/* actually, lastchunk is more than this, but it */
			/* IS true that we only need to check through    */
			/* this foffset value to make sure everything has */
			/* arrived  -mtk */
	}

	/* now touch the time field, for buffer LRU */
	buf->lasttime = clock();

	/* check to see if there are fragments missing */

	if(buf->lastchunk == 0)
	{
		/* we haven't even gotten a fragment with a cleared MORE */
		/* FRAGMENTS flag, so we're missing THAT piece, at least */
		return 1;
	}
	for(i=0; i<= buf->lastchunk; i++)
	{
		/* scanning to see if we have everything */
		if(0 == ((buf->bits[i/32]) & (unsigned long)(1L<<(i % 32))) )
		{
			return 1;	/* still waiting for more */
		}
	}

	/*  otherwise, done waiting... use the packet we've gathered */
	/* first clear stuff from fragment buffer: */
	buf->lasttime = 0L;	/* mark as free to take */
	buf->lastchunk = 0;	/* need to do this, because we use it as flag */
	buf->pkt.i.ident = 0;	/* so we don't find this later */
	buf->pkt.i.frags = 0;	/* in case anybody above us checks */
	/* then send it on its way... */

    if(!comparen(nnipnum,p->i.ipdest,4)) {     /* potential non-match */
        if(comparen(nnipnum,junk,4) && p->i.protocol==PROTUDP)
            return(udpinterpret((UDPKT *)p,iplen));
        return(1);              /* drop packet */
      } /* end if */

   	switch (buf->pkt.i.protocol) {        /* which protocol */
        	case PROTUDP:
            	return(udpinterpret((UDPKT *)&(buf->pkt),buf->iplen));
		
        	case PROTTCP:
            	return(tcpinterpret((TCPKT *)&(buf->pkt),buf->iplen));  
		
        	case PROTICMP:
        	return(icmpinterpret((ICMPKT *)&(buf->pkt),buf->iplen));
		
       	default:
       		netposterr(303);
       		return(1);
  	}

}

*** helpful hint:

if you run out of space in DGROUP, its because your compiler doesn't
place each 'far' data object in its own segment. To make things work,
you need to make the raw packet buffer be in its own segment.
Here's how:
in include/pcdefs.h search for:

-->  unsigned char far raw[17000];

 (the 17000 might be some other number... smaller, if someone tried to
  fix this before)
 and change to

-->  unsigned char far raw[17000]={0,0};	/* force into own segment */  

E. Information for developers

E-1. What publicly distributable TCP/IP stacks are there that I can
     use to develop my own applications?

In writing an application, you can use device drivers provided by
particular vendors, or you can opt for an Application Binary Interface (ABI) 
that supports multiple TCP/IP protocol stacks, such as Winsock. For a given 
version of Windows, Winsock is an ABI for both Windows 3.x and Windows NT 
(via the NT Win16 subsystem).

Device drivers are included with PC-NFS and Beame & Whiteside's
BW-TCP.  Free examples of ABIs are the WATTCP API, the NCSA API
(public domain), the Trumpet ABI from Peter Tattum, and the NuPOP ABI.

All major TCP/IP vendors have by now implemented Windows Sockets.

E-2. Where can I get a copy of the Windows Sockets FAQ?

A separate developer-oriented FAQ file about Windows Sockets created
by Mark Towfiq is available on
ftp://SunSite.UNC.EDU/pub/micro/pc-stuff/ms-windows/winsock/FAQ
and ftp://Microdyne.COM/pub/winsock/FAQ

An alternative source for the FAQ is ftp.microsoft.com.

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

Please send comments to:

Bernard Aboba
Author of:
The Online User's Encyclopedia, Addison-Wesley, 1993
The PC-Internet Connection, Publisher's Group West, 1994 
mailto:[email-masked]
WWW page: http://www.zilker.net/users/internaut/index.html