A-1. What do I need to run TCP/IP on the PC?
To run TCP/IP on the PC you will need:
You may also use any other network card with a packet driver or NDIS or ODI driver, such as an Arcnet card. If your card supports NetBIOS, this is also acceptable, since you can run a packet-driver-over- NetBIOS shim.
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-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 (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).
For 3COM drivers, try ftp ftp.3com.com. For technical information, try info@3com.com. For marketing and product info, try leads@hq.3mail.3com.com.The packet driver specification is available from vax.ftp.com in packet-d.ascii
The following vendors have packet drivers with source available for their pocket lan adaptors:
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, 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.
As Mark Towfiq notes:
The next rev. of Winsock will not be until towards the end of 1993. We need 1.1 of the API to become firmly settled and implemented first."Files and information related to the Windows Sockets API are available via file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock, which is a mirror of /pub/winsock on Microdyne.COM (SunSite has a much faster connection to the Internet, so you are advised to use that).If you do not have FTP access to the Internet, send a message with the word "help" in the body to either ftpmail@SunSite.UNC.Edu, or ftpmail@DECWRL.DEC.Com, to obtain information about the FTP to Mail service there.
Alternative sources for the Windows Sockets specification include rhino.microsoft.com (an FTP server running NT), as well as the Microsoft forum on CompuServe (go msl).
Currently NetManage (NEWT), Distinct, 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.
Peter Tattam is alpha-testing a shareware Windows Sockets compliant TCP/IP stack. If you're interested in helping with the testing, you can obtain it via: file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip, file://ftp.utas.edu.au/pc/trumpet/winsock/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 or CSLIP. If you are using a network adapter, this means that you will have to locate a packet driver for your adapter, and load it. Trumpet Winsock also comes with WINPKT, and this is loaded next, via the command WINPKT.COM 0x60 [or whatever the software interrupt for your packet driver]
You will then enter Windows, and create a group in the Program Manager for all the files that come with Trumpet Winsock. The stack itself is loaded by executing TCPMAN. Applications that come with it include WinCHAT, a chatting program; PINGW, a ping utility; FTPW for FTP, WINARCH for Archie.
When you first execute TCPMAN, you will be asked to fill out the setup information for the stack. Select whether you will be using a network adapter or SLIP; you cannot use both.
Note that since Trumpet Winsock now includes a scripting language, you will not need an external dialer if you use this. If you do decide to use an external dialer, the follow program is recommended for use with windows: file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip
A-4. What publicly distributable TCP/IP applications are there for DOS? Windows?
Right now there are a wealth of publicly distributable TCP/IP applications running under DOS. Windows also has a wealth of programs available, including implementations of Gopher, Mail (POP3/SMTP), FSP, Mosaic, Telnet/FTP, and WAIS.
A-5. What software is available for doing SLIP? Compressed SLIP? PPP? For DOS? Windows? OS/2?
For SLIP or CSLIP 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, which while taking up too much RAM (121K), works just fine, and includes a built-in dialer.
If you are running Windows Sockets, I recommend the Trumpet Winsock, which comes with its implementation of SLIP/CSLIP, but which does not appear to work with EtherPPP.
KA9Q supports SLIP/CSLIP/PPP, but unfortunately can not be used as a TCP/IP protocol stack to run other apps.
There is a special version of NCSA Telnet for PPP, available from merit.edu, /pub/ppp directory.
IBM is reportedly shipping TCP/IP for OS/2. Please see the FAQ from comp.os.os2.networking for details.
IBM, FTP Software, Beame & Whiteside, Frontier, Netmanage, and Trumpet Winsock also offer SLIP support in their products. See the resource listings for details.
A-6. What diagnostic utilities are available to find problems with my connection?
Frequently used diagnostic utilities include ifconfig (checks the configuration of the network interfaces), ping (tests IP layer connectivity), traceroute (traces the route that a packet takes between two sites), netstat (checks the routing table), tcpdump (protocol analyzer), arp (looks at the IP to Ethernet address mappings).
KA9Q includes ifconfig, ping and traceroute functions. In KA9Q hop check is the equivalent of traceroute. The Trumpet TCP/IP stack also has a hopchk2 command that is a traceroute equivalent.
The DNPAP tools (check the resource guide for listings) include Ethernet packet catchers, networking monitors and a network host profiler.
Trumpet Winsock comes with a Windows implementation of Ping.
A-7. 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.
A-8. When do I need to install WINPKT?
PKTMUX and WINPKT both accomplish the same thing: allowing you to connect to a DOS packet driver running in real mode from a virtual DOS session under Windows. PKTMUX is useful when you are running more than one TCP/IP stack, and since it takes up more RAM and is slower than WINPKT, you should only use it when you want to run more than one stack at a time. If you are running only one DOS app, or are using Trumpet Winsock, stick with WINPKT.
James Harvey (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 (erick@development.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.
A-9. How do I run both WinQVT/Net 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.
A-10. 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).
A-11. How do SLIP and PPP 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.
A-12. When do I need to use 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.
A-13. Can NDIS be used underneath multiple protocol stacks of the same type?
No. There is no equivalent to PKTMUX for NDIS.
A-14. 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).
