[Vorherige]
[Nächste]
[Index]
comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 1 of 3
- Subject: comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 1 of 3
- From: aboba@netcom.com (Bernard Aboba)
- Date: Wed, 28 Dec 1994 13:33:15 GMT
- Keywords: TCP/IP, IBM PC, SLIP, PPP, NDIS, ODI
- 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
- Sender: aboba@netcom.com (Bernard Aboba)
- Summary: Frequently Asked Questions (and answers) about TCP/IP on PC-Compatible Computers
Archive-name: ibmpc-tcp-ip-faq/part1
comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 1, 1/1/95
################# Legalese #################
This document is Copyright (C) 1993,1994,1995 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 Internet
Microsoft, IBM, Sun or Apple
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:
ftp://ftp.netcom.com/pub/ma/mailcom/IBMTCP/ibmtcp.zip
Please note the change in the archive address!
############ This FAQ is on the Web ###############
After each posting, this FAQ is automatically
converted to HTML by Ohio State, and made available
on the Web. 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, try:
http://www.zilker.net/users/internaut/update.html
################# 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
ftp://ftp.netcom.com/pub/ma/mailcom/IBMTCP/ibmtcp.zip,
57 pages.
################# Change History #################
Changes from 11/1/94 posting:
Updated commercial stack entries, cleaned up broken
links reported by readers (thanks!). New entries
sport a "*"
################# Related FAQs #################
There is a FAQ available on features of TCP/IP
Packages for DOS and Windows. This is available at:
ftp://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:
ftp://seagull.rtd.com/pub/tcpip/pcnfsfaq.zip
ftp://ftp.york.ac.uk/pub/FAQ/pcnfs.FAQ
The SNMP FAQ is regularly posted to news:comp.protocols.snmp
The TCP/IP FAQ is posted to news:comp.protocols.tcp-ip, and is
maintained by mailto:gnn@netcom.com.
The Windows NT FAQ is available from
Steve Scoggins, mailto:sscoggin@enet.net
An NT Web FAQ is available from:
http://www.luc.edu/~tbaltru/faq/
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.
################# 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
Pages: 600 (estimated), 8.5" by 11"
Distributor: Publisher's Group West
ISBN: 1-883979-00-5
Price: $32.95 (est), includes CD-ROM with
Chameleon Sampler software, WS-Gopher, PC-Eudora,
Etherload, EtherDump, much more.
Estimated release: No date set (yeah, it slipped a
few months)
To look at sample chapters from the book, check out
the following WWW page:
http://www.zilker.net/users/internaut/forth.html
I'm currently working on incorporating comments
from the first beta release, finishing the index
and generally cleaning it up, so the second beta
release won't be out for at least another month.
Until the second beta is out, I will not be accepting
review requests. Sorry!
########### 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/pub/msdos/network.setups
################# EXAMPLE CONFIG FILES #################
Many thanks to Dave Fetrow (fetrow@biostat.washington.edu)
for creating an archive of setup files. The archive is
particularly oriented toward sets of applications that
are somewhat tricky, such as combinations involving
different driver sets, mixtures of NetWare, TCP/IP,
and W4WG, etc.
Please include not only the setup and configuration files
but some directions. Comments included with the setup files
are highly desirable. The files can include your name if you
desire.
Please mail submissions to mailto:ftp@ftp.biostat.washington.edu.
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 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 HTTP proxies are available for use with NCSA Mosaic?
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?
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
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 source-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. Hints for particular packages
E-1. How do I get DesQView X to run over the network?
E-2. Why is NFS so slow compared with FTP?
E-3. Where can I get information on running NetWare and TCP/IP
concurrently?
E-4. What NetWare TCP/IP NLMs are out there and how do I get them
to work?
E-5. How do I get a telecom package supporting Int 14h redirection
to work?
E-6. I am having trouble running Netmanage Chameleon apps along with
WFW TCP/IP-32. What do I do?
E-7. How do I get Windows For Workgroups to work alongside NetWare?
E-9. How come package X doesn't support the AppleTalk packet driver?
E-10. NCSA Telnet doesn't reassemble fragments. What should I do?
E-11. I am trying to configure a Macintosh to set its parameters automatically
on bootup, but it isn't working. What's wrong?
E-12. I've heard that DHCP is a potential security risk. Is this true?
E-13. What is TIA?
E-14. What PC TCP/IP implementations support recent advances?
E-15. What network adapters have on-board SNMP agents?
E-16. What is the easiest way to get WFW and Novell Netware to coexist?
E-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?
E-18. What proxy software is available for those concerned about security?
E-19. How do I mount ftp.microsoft.com on the desktop using file manager?
E-20. I am having trouble connecting to a Windows NT PPP server. What should
I do?
F. Information for developers
F-1. What publicly distributable TCP/IP stacks are there that I can
use to develop my own applications?
F-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 (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-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:
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-stuff/ms-windows/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/trumpwsk/winsock.zip.
ftp://biochemistry.bioc.cwru.edu/pub/trumpwsk/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/win3/util/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/WFW/tcpip/tcpip32.exe
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 HTTP proxies are available for use with NCSA Mosaic?
Mosaic and WinWeb now both support proxies via the CERN httpd, which
supports http, ftp, gopher, and wais proxies, as well as caching.
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 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 stack 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 SOCKS-compliant
TCP/IP stack, and it apparently has problems with rbind, which
can get gotten around by using FTP in PASV mode.
It would be cool to have a list of which applications support
SOCKS, and which support other proxy servers such as CERN
HTTPd. Please send me mail if you have info on this.
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
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 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 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?
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 >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.
C. KA9Q Questions
C-1. What version of KA9Q should I use and where do I get it?
There are so many releases of KA9Q that it is a significant amount of
work just to keep track of them all. This has occurred partly because
KA9Q does not support extended or expanded memory, and therefore many
people have needed to customize it with the features relevant to them
in order to allow it to do what they want as well as fit into memory.
The primary difference among the various releases is whether they
include code for a BBS, packet radio support (AX.25), synchronous cards (for
use with leased lines), NNTP, CSO or Gopher servers, packet filtering, DNS,
RIP or PPP support.
The three primary KA9Q releases at this time are those managed by Ashok Aiyar
(ashok@biochemistry.bioc.cwru.edu), those put out by Demon Internet
Services (DIS), and the JNOS distribution. JNOS is the primary packet radio-
oriented release; the other two major releases do not include AX.25 support.
Since JNOS does not include several features important to non-packet radio
users (DNS/Gopher/CSO server, hop check), try one of the other two releases
if you're not interested in packet radio.
Ashok's release is based on the N1BEE 0.85-beta which in turn
is based on PA9GRI 2.0m NOS. Version 11c includes support for NTP, CSO,
gopher, FTP, FINGER, HTTP and SMTP/POP2/POP3 servers, plus VT102 and packet
filtering support. Please not that this release does *not* include radio or
synchronous card support, unlike the standard KA9Q release, and only 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.
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 <= 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.
Very useful, particularly if you need to know if
you should install a 16550 on your serial port.
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?
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 <= 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
#
#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 <= 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: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 <= 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
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 <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!
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 source-routed packets? If so, is there any way to
turn off this (rather undesirable) behavior?
It looks to me like KA9Q will route source-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. Hints for particular packages
E-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?]
E-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."
E-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.
E-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/unsupported/server/bootpd.exe.
Contact: mailto:dirk@rhein-main.de
E-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.
E-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.
E-7. How do I get Windows For Workgroups to work alongside NetWare?
ODINSUP from Novell is an NDIS over ODI shim. This allows you to run
software requiring ODI drivers, as well as software requiring NDIS
drivers. Since IPX and TCP/IP are different protocols, you will not
need to run PKTMUX.
Available via
ftp://ftp.novell.com/netwire/novfiles/client.kit/doswin/files/WSDOS1.EXE.
E-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.
E-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:
>/*
>* We cannot handle fragmented IP packets yet, return an error
>*/
>
> if(p->i.frags &0x20) { /* check for a fragmented packet */
> netposterr(304);
> return(1);
> }
----------
after the line:
> iplen-=hlen;
but before the lines:
> /*
> * check to make sure that the packet is for me.
add this:
/* check for fragment and handle. note that the &0x20 above is WRONG */
if(p->i.frags) /* NOW check for a fragmented packet - mtk add*/
{
ipfraghandle(p,iplen); /* pass in computed iplen to save time */
return(1);
}
----------
and then, at the end of that file (ip.c) add this:
/*
* IP Fragment Reassembly Hack
* by Matthew T Kaufman (matthew@echo.com)
* 1/1993, 8/1993
*/
typedef struct ipb {
DLAYER d;
IPLAYER i;
uint8 data[4104]; /* "Big Enough" */
}FIPKT;
#define IPF_CHUNKS 513 /* 4104 / 8 */
#define IPF_BITWORDS 18 /* 513 / 32 round up + 1*/
#define IPF_BUFFERS 7 /* Max # of different fragmented pkts in transit */
typedef struct {
FIPKT pkt;
unsigned long bits[IPF_BITWORDS];
int lastchunk;
unsigned long lasttime;
unsigned int iplen;
}FPBUF;
static FPBUF far Frag[IPF_BUFFERS];
ipfraghandle(IPKT *p, int iplen)
{
uint16 fraginfo;
uint16 foffset;
uint16 iden;
FPBUF far *buf;
int i;
fraginfo = intswap(p->i.frags);
foffset = fraginfo & (0x1fff);
#define morefrags (fraginfo & (0x2000))
iden = intswap(p->i.ident);
/* we already KNOW that this IS fragmented */
/* see if we can find any friends who've already arrived... */
buf = (FPBUF *) 0L;
for(i=0; i<IPF_BUFFERS; i++)
{
if(p->i.ident == Frag[i].pkt.i.ident)
{
buf = &(Frag[i]);
goto foundfriend;
}
}
/* otherwise, we must be the first one here */
{
long oldtime = 0x7fffffff;
int oldest = 0;
for(i=0; i<IPF_BUFFERS; i++)
{
if(Frag[i].lasttime == 0) /* unused buffer? */
{
buf = &(Frag[i]);
goto foundempty;
}
if(Frag[i].lasttime < oldtime) /* track LRU */
{
oldtime = Frag[i].lasttime;
oldest = i;
}
}
/* if we're here, we need to reuse LRU */
buf = &(Frag[oldest]);
foundempty: ;
/* initialize new buffer */
/* time will be filled in later */
for(i=0; i<IPF_BITWORDS; i++) buf->bits[i] = 0L; /* reset */
buf->lastchunk = 0; /* reset */
/* fill in the header with the current header */
movmem(p,&(buf->pkt), sizeof(DLAYER) + sizeof(IPLAYER) );
}
foundfriend: ;
/* now, deal with this specific fragment... */
/* copy data */
movmem(&(p->x.data),&(buf->pkt.data[8 * foffset]),iplen);
/* update rx chunks information */
for(i=foffset; i<= (foffset+(iplen / 8)); i++)
{
buf->bits[i/32] |= (unsigned long) (1L<<(i % 32));
}
if(!morefrags)
{
/* now we can tell how long the total thing is */
buf->iplen = (8*foffset)+iplen;
buf->lastchunk = foffset;
/* actually, lastchunk is more than this, but it */
/* IS true that we only need to check through */
/* this foffset value to make sure everything has */
/* arrived -mtk */
}
/* now touch the time field, for buffer LRU */
buf->lasttime = clock();
/* check to see if there are fragments missing */
if(buf->lastchunk == 0)
{
/* we haven't even gotten a fragment with a cleared MORE */
/* FRAGMENTS flag, so we're missing THAT piece, at least */
return 1;
}
for(i=0; i<= buf->lastchunk; i++)
{
/* scanning to see if we have everything */
if(0 == ((buf->bits[i/32]) & (unsigned long)(1L<<(i % 32))) )
{
return 1; /* still waiting for more */
}
}
/* otherwise, done waiting... use the packet we've gathered */
/* first clear stuff from fragment buffer: */
buf->lasttime = 0L; /* mark as free to take */
buf->lastchunk = 0; /* need to do this, because we use it as flag */
buf->pkt.i.ident = 0; /* so we don't find this later */
buf->pkt.i.frags = 0; /* in case anybody above us checks */
/* then send it on its way... */
if(!comparen(nnipnum,p->i.ipdest,4)) { /* potential non-match */
if(comparen(nnipnum,junk,4) && p->i.protocol==PROTUDP)
return(udpinterpret((UDPKT *)p,iplen));
return(1); /* drop packet */
} /* end if */
switch (buf->pkt.i.protocol) { /* which protocol */
case PROTUDP:
return(udpinterpret((UDPKT *)&(buf->pkt),buf->iplen));
case PROTTCP:
return(tcpinterpret((TCPKT *)&(buf->pkt),buf->iplen));
case PROTICMP:
return(icmpinterpret((ICMPKT *)&(buf->pkt),buf->iplen));
default:
netposterr(303);
return(1);
}
}
*** helpful hint:
if you run out of space in DGROUP, its because your compiler doesn't
place each 'far' data object in its own segment. To make things work,
you need to make the raw packet buffer be in its own segment.
Here's how:
in include/pcdefs.h search for:
--> unsigned char far raw[17000];
(the 17000 might be some other number... smaller, if someone tried to
fix this before)
and change to
--> unsigned char far raw[17000]={0,0}; /* force into own segment */
E-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.
E-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.
E-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.
You can obtain TIA from marketplace.com.
E-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!]
E-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.
E-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.
E-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.
E-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.
E-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.
E-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. Information for developers
F-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.
F-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://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, due 2/95
mailto:aboba@netcom.com
FTP archive: ftp://ftp.netcom.com/pub/ma/mailcom/
WWW page: http://www.zilker.net/users/internaut/index.html