E. TCP/IP AND NETWARE
TCP/IP is another networking protocol (like IPX) widely used in academic and commercial networks. It is used to allow different types of computers to communicate over a network.
For further information, check out:
http://www.futureone.com/~opeth/internetwork.html
Also, check out the TCP/IP Transport Supervisor's Guide.
[Thx H.B. & S.R.#2]
"Daryl's TCP/IP Primer" is located at:
It is designed for people familiar with networking, but not necessarily familiar with TCP/IP networking. Includes a section on the differences between IPX and IP.
[Thx D.B.#4]
E.2 Why you might want TCP/IP and Netware to co-exist
Many organisations have different types of computers on their networks. For example most universities have PCs and Unix or VAX computers on the network. Most Unix computers (and many others besides) use TCP/IP as a networking protocol. Also the Internet uses TCP/IP as its networking protocol. If your Netware PC users want to access Unix computers, they will most likely use TCP/IP and a package like telnet to do this.
E.3 Packet drivers/ODI drivers/NDIS drivers
Packet Drivers, ODI drivers, and NDIS drivers share a common purpose of recognizing packets coming in and distributing them to the appropriate piece of networking software as well as sending pre-built packets. Packet Drivers were first on the block once FTP Software realized the difficulty of writing complete drivers for every Ethernet board on the market. It's a short specification that does little more than hand out packets; consequently a Packet Driver is very small (about 2.5K in memory) but highly effective.
3Com/Microsoft came out with the NDIS specification to accomplish the same goal, but with many enhancements. The specification itself is very large and difficult to understand, and the code was the same way. NDIS is most commonly seen on Lan Manager systems (3Com, Microsoft, DEC, AT&T and so on).
And, since Microsoft has of late taken to adding networking stuff in Windows products, those running Windows for Workgroups, Windows 95 or Windows NT as a network client will find themselves using NDIS, at least to some degree.
[Thx S.M.D.]
Then, most recently, Novell decided to tackle the board variety problem, but by starting from the top and looking down toward the hardware. Their ODI specification is the largest and most elaborate, and yet in many ways is the "best" of the bunch.
There is a new version of the documentation describing ODI calls, tables, and functionality which are expressed in ANSI-C available at:
ftp://netlab2.usu.edu/odi/update/codidocs.zip For Netscapers: ftp://netlab2.usu.edu/sys/anonftp/odi/update/codidocs.zip OR ftp://netlab1.usu.edu/pub/mirror/odi/update/codidocs.zip
Both NDIS and ODI drivers are commercial endeavors, but their specifications are public. However, neither NDIS or ODI makes any effort to accommodate alternate ("competing") protocol stacks. This is changing with the appearance of small software converter "shims" which have a Packet Driver interface as the common denominator. Novell's Lan WorkPlace for DOS is a shining example of providing an ODI driver supporting both NetWare and TCP/IP. You can see the pressures here: software vendors want a cheap way of using many boards because drivers are expensive to write, and users want everything, including the ability to run things requiring dual protocol stacks on a single board.
The commercial NDIS and ODI drivers should be more solid than the volunteer effort Packet Drivers, and correspondingly harder to get changed when bugs are found. NDIS and ODI drivers need to come from board vendors; Packet Drivers come, normally, from individuals and are distributed via Columbia University (you may get them by anonymous ftp from wuarchive.wustl.edu and many other sites).
ODI is at this stage the driver type with the widest acceptance. It the only driver that Novell supports (IPX.COM, the monolithic shell or "driver" used before the introduction of ODI has long since been discontinued).
[Thx Joe D.]
E.3.1 LAN WorkPlace (and other) documents available from Novell via WWW
The LAN WorkPlace 5.0, NetwareIP 2.1, NetWare NFS, Tuxedo RTK & SDK (and probably other) documents are now available on the Novell Publications Server at:
http://www.novell.com (click on the "Manuals")
E.4 Why can't multiple TCP/IP stacks run on a workstation?
In order to understand this problem, assume that two TCP/IP applications ARE running on a workstation: when an IP packet arrives at a board with two or more TCP/IP stacks are active, the packet is delivered to each. Each stack now has a valid TCP or UDP (and maybe ICMP, ARP, or whatever) packet, and decodes the protocol type (TCP etc.), the operation kind, sequence number, and so on to fairly great detail. If the numbers happen to overlap with what another stack is doing then chaos will probably result--and if not the stack will likely send an error report back to the host and the connection will be aborted. The several parallel stacks are uncoordinated and thus fratricidal.
In order to have multiple applications running in parallel, it is necessary that they be perfectly coordinated. How to do this? Simple: have one stack serving many applications. Each application gets a separate session identity within the stack and no conflicts can occur in properly written code; TCP/IP is designed for this. [Editor's note: unfortunately, there is no generally accepted sharable TCP/IP stack for PC workstations.] One well-known example of such a solution is Novell's LAN Workplace for DOS or Windows, which has a resident TCP/IP stack. Once you have the TCP/IP driver (and stack) loaded, you can load other applications (telnet, gopher etc) in tandem.
This argument applies to every method of delivering packets to stacks: PD, ODI, NDIS, even carrier pigeon (there's a famous RFC for avian carriers). For readers with a technical interest in these things there are now three excellent books on TCP/IP: _Unix Network Programming_ by Stevens, and _Internetworking with TCP/IP_, volumes I and II, by Comer.
Recently, a program named PKTMUX was written in the UK, which attempts to follow the detailed conversation between applications and their host; when multiple TCP programs are run over the same packet driver, it attempts to renumber the packet internals to avoid the conflicts noted above. It's a neat effort, but it cannot do the whole job. Under some conditions, it will work ok; under others we still get the effects described, so use it with caution.
[Thx Joe D.]
E.5 Routing TCP/IP through a file server
If you use TCP/IP on two or more network adapters in a file server, chances are you want to route TCP/IP through the server (for example, you have one network adapter attaching to a room of PCs and the other attaching to your campus backbone). Each interface to which you bind TCP/IP has an IP address and a network mask. The combination of network mask, IP address and the destination field in a received IP packet determines whether that packet is routed through the server. As an example, let's assume your server attaches to two IP subnets, one with the address 137.43.101.0 (IP numbers between 137.43.101.1 and 137.43.101.255) and the other subnet with the address 137.43.102.0. Here is the IP configuration of the two network interfaces:
IP address Network mask Driver 1: 137.43.101.1 255.255.255.0 Driver 2: 137.43.102.10 255.255.255.0
In Novell terms the bind configurations look like this:
BIND IP TO DRIVER1 ADDR=137.43.101.1 MASK=255.255.255.0 BIND IP TO DRIVER2 ADDR=137.43.102.10 MASK=255.255.255.0
Note: You must also have
LOAD TCPIP Forward=Yes
in AUTOEXEC.NCF to setup the routing of IP-packages.
This configuration will route packets from machines in 137.43.101.0 to 137.43.102.0 and vice versa. [Editor's note: these IP subnets are for example only. They actually exist in University College Dublin's IP network. If your IP network will connect to other networks you should apply for your own set of IP network addresses] DRIVER1 and DRIVER2 may be either driver types or aliases specified by the NAME= option when loading the driver.
Novell's documentation kit includes extensive manuals which cover how to configure a server to route TCP/IP, as well as the concepts behind subnets.
[Thanks to Amnat (Nat) Choeypatkul for some corrected info]
E.5.1 Why TCP/IP Routing Doesn't Always Work As Expected
The RFCs (Request For Comments, the papers which define Internet standards) governing IP addressing state that no portion of a node's address may consist of all zeros or of all ones. You can logically break down an address into two components where subnetting is not used (the network portion, defined by the address' class; and the node portion), and three components where subnetting is used (the network address; the subnetwork address, which is the difference between the subnetwork mask and the normal mask used for that address class; and the node address).
Let's look at an example. Let's say we're subnetting a class B address, 166.166.0.0, into a number of class C-sized subnetworks. We would do this with a subnetwork mask of 255.255.255.0. This yields 254 networks, 166.166.1.0 through 166.166.254.0. We cannot use 166.166.0.0, as the subnetwork portion (the third octet) is all zeroes; similarly, we cannot use 166.166.255.0, as the subnetwork portion is all ones.
Some equipment will allow you to use these illegal networks. Such equipment is providing an extension to the specificationss, and technically could be considered to be broken in that it does not behave according to the original specifications. Novell has released a version of MPR which permits the use of the all-zeroes subnet. Before using any all-zeroes or all-ones subnet, make sure you understand the applicable RFCs and are fully aware that you are "Off Spec".
[Thx S.M.D.]
There is a shareware program, SUBNET, that suggests appropriate masks based on the quantity of subnets and hosts per subnet; creates listings of subnets, directed broadcasts and host-ranges per the number of bits you tell it to use for subnetting (it then tells you what the mask should be). Lists include both binary and decimal displays and can be saved to disk as ASCII text or can be added to a database file (MS Access). The shareware version is limited to Class C addresses, the Deluxe version supports Class A - C addressing, including Variable Length Subnet Masks and Management tools for IP addresses. It needs VBRUN300.DLL. Author is Guy Michaud, gmichaud@cisco.com, and it can be downloaded at:
http://www.futureone.com/~opeth/internetwork.html
[Thx S.R.#2]
E.5.2 Security considerations of allowing IP Source Routing
IP source routing comes in loose and strict flavors...[A] bad guy on a far-away machine can send IP traffic to your place with a) source AND destination addresses at your place and b) an IP source route table which includes his far-away place. Naturally they have just tapped the wire and typically do not forward traffic back to the fake local destination.
[The net effect is to] penetrate firewalls which are unaware of IP [source routing]. IP source routing is rarely used and can be turned off forever with really no loss. So turn it off on your major routers.
[Thx Joe D.]
E.6 Setting up a Netware server as an FTP server
Novell's FTP server is bundled in both their Novell NFS package and in their NetWare Flex/IP package. According to the May 11, 1992 press release when Novell announced NetWare Flex/IP, the "high performance FTP server allows UNIX users to transfer files to and from NetWare v3.11 servers on the network. It also enables FTP clients to use the NetWare v3.11 server as an FTP gateway to access any other NetWare server on the network, including those that do not support TCP/IP. The FTP server provides full support of both UNIX/NFS and DOS name spaces..."
An alternate, and less expensive, solution is to run NCSA telnet in FTP server mode on a dedicated workstation--an old 8088 machine is perfectly suitable. (NCSA is available on many sites. The people ftp'ing into the workstation will have access to anything the account logged in on the workstation has access to. You can set up "accounts" and passwords, but the only thing this controls is who can ftp into the workstation. Additionally, only one ftp connection at a time is possible. In many cases, however, these restrictions will not be a problem.
Yet another alternative solution is a third-party FTPD.NLM. Brad Clements (MurkWorks) has an FTP NLM available: ftp to ftp.msen.com to pick up a demo copy. This is not shareware: you must pay Brad a license fee to use the actual software (the demo is free). HELLSOFT in the Czech Republic also produce an FTPD NLM, available via anonymous ftp from Michal Meloun's ftp site novell.felk.cvut.cz. Michal Meloun can be reached at meloun@vision.felk.cvut.cz. Both products work under NetWare 4.x but in Bindery Emulation mode only.
MurkWorks FTPD.NLM demo:
ftp://ftp.msen.com/pub/vendor/murkworks/demos/ftpd/ftpdnlm.zip
Hellsoft FTPD.NLM:
ftp://novell.felk.cvut.cz:/nw311/ftpd/ftpd18.zip
[Thanks to Steven Nygard for the info on Hellsoft]
There are much less expensive alternatives like SDLPD from Secure Designs. SDLPD provides LPD & LPR services for a Novell file server via an NLM. Their web page is:
[Thanks to John Villalovos for this info]
Bootp is a method by which a workstation can determine what ip number it should use and to find out what its nameservers and gateways are. If a workstation [using NCSA or CUTCP] runs telnet or ftp and has the myip variable in its config.tel file set to bootp, it will send out a broadcast on the network. A bootp server somewhere will see this broadcast, and respond to it with the ip number the workstation should use and what its nameserver and gateways are. The advantage is that all ip numbers, nameserver, and gateway information are kept in one file on the bootp server. You can get LPD.EXE at:
ftp://tacky.cs.olemiss.edu/pub/lpd/ncsa/lpd.exe
This will do bootp as well as lpd. You do not need a state of the art workstation to run this program. BOOTP is also available on lancaster.andrew.cmu.edu.
[Thanks to Dan Abts for this info]
Jocelyn Nadeau has informed me that the documentation for lpd doesn't indicate that it performs BOOTP; however, you can find BOOTP.ZIP and BOOTPNOS.ZIP as follows:
ftp://ftp.ci.cuslm.ca/public/network/bootp.zip ftp://ftp.ci.cuslm.ca/public/network/bootpnos.zip *142.17.2.244*
Another BOOTP server is BOOTPD.NLM from Hellsoft, available as follows:
ftp://novell.felk.cvut.cz/nw311/ftpd/bootpd18.zip *192.108.160.5* or ftp://ftp.salford.ac.uk/network/nlms/bootpd18.zip (needs resolv.nlm) ftp://ftp.salford.ac.uk/network/nlms/bootpfwd.nlm (bootp forwarder)
You'll need the Hellsoft name resolver NLM as well, available as follows:
ftp://novell.felk.cvut.cz:/nw311/resolv/resolv13.zip
[Thanks to David Gersic and J.P. for this info]
Rarp is similar in function to bootp, but is less sophisticated. As with bootp, the workstation sends out a broadcast request for an IP number. If a rarp server picks up this request it will respond with an IP number for the requesting workstation. No other information is returned (this is one major difference between bootp and rarp). If your workstations use NCSA or Clarkson TCP/IP software, you can get them to use rarp by specifying the MYIP variable to be RARP. Many Unix machines come equipped with a rarp server and PC versions are available from ftp servers.
One drawback with rarp is that it doesn't use IP packets: rarp is an ethernet protocol all to itself. This means that rarp requests *won't* make it through a Netware file server routing IP (or indeed through many other IP routers). Rarp servers are available for Novell servers and for PCs running LAN Workplace for DOS (and quite possibly for other platforms as well). An NLM-based rarp server is available as follows:
ftp://netlab2.usu.edu/misc/rarpserv.nlm For Netscapers: ftp://netlab2.usu.edu/sys/anonftp/misc/rarpserv.nlm
Douglas Comer's "Internetworking with TCP/IP: (in three volumes) is an excellent and complete guide to TCP/IP.