Nov. 11, 2004: Here is a summary of when to use NICI, NULL or Domestic version of TCPIP. (Explanation of what those versions mean is given later on this web page).
Feb 14, 2004: A Novell engineer summarized the NICI/DOMESTIC situation nicely as follows (read the Feb 8 post below). Note that currently, all new TCPIP patches no longer include
either the Domestic or Export versions of TCPIP.NLM. With new support packs for NetWare, only Null or NICI versions are now used.
This is if VPN is enabled on the server.
Feb 8, 2004 - Here is some information regarding TCP608T, NW6SP4 and BorderManager VPN:
BorderManager 3.8 VPN used a new method of encryption involving NICI. Consequently, it needed a different version of TCPIP.NLM than previous versions of BorderManager VPN servers.
There were three versions of TCPIP as of February 2004: null (no encryption, for non-VPN servers), domestic (128-bit encryption for NBM 3.7 or earlier), and nici (BorderManager 3.8 VPN). Then came
NW6SP4.EXE, which update VPTUNNEL.LAN to a version that uses NICI encryption, regardless of the version of BorderManager. Once you have applied NW6SP4, you must use the NICI version of TCPIP if you
have any version of BorderManager VPN running. If you use the domestic or null version of TCPIP, you will have public symbol errors on the logger screen and VPTUNNEL will not load. Solution: Either
install the correct (nici) version of TCPIP, or back-rev the VPTUNNEL.LAN module to the previous version. Going forward, only one encrypted version of TCPIP will be required, and new TCPIP patches
will no longer offer the Domestic version.
Feb. 4, 2004 - Added the following comment:
I want to give a general warning on TCPIP patch versions - they are often specific to NetWare service packs and both assume and require particular service packs being installed first. The very latest TCPIP patch is most likely dependent on the very latest NetWare service pack being installed first, and may not work if you are one patch behind. For instance, if you have NW51SP6 installed, you can use TCP583L.EXE, but not TCP585T.EXE, and TCP583L will probably not work with earlier or later NetWare service packs, like NW51SP7 and NW51SP5. TCP585T is for NW51SP7 only, and may not work if there is a NW51SP8, etc.
Feb. 28, 2003 - I'm going to try to summarize the current state of TCPIP.NLM patches somewhat, and add an explanation of how the TCPIP stack is be different with BorderManager
3.8 involved (or later patches). There are a number of versions of TCPIP out, and you need to understand the basic differences between them:
There are multiprocessor-capable (SMP) versions for NetWare 6, and non-SMP capable versions for NetWare 5.x. The TCPIP 6.x versions should be SMP-capable, meaning they should scale better in high-traffic environments. Non-SMP capable versions will run on SMP, but not take advantage of multiple processors. Non-SMP capable versions should be the 5.x versions of TCPIP.NLM. You should not run 5.x versions of TCPIP.NLM on NetWare 6.
There are encryption- and non-encryption versions of TCPIP.NLM. The encrypted versions are only needed for BorderManager VPN. the only difference between encryption- and non-encryption-capable versions is if the encryption logic for VPN is included in the TCPIP stack, and the version number of TCPIP.NLM.
The versions numbers between encrytion and non-encryption version of TCPIP.NLM are 0.1 different. Example: TCPIP version 5.90n is the encryption version of TCPIP 5.80n.
Non-encrypted versions of TCPIP are called the 'NULL' versions. The encryption versions are always a higher number than the null versions.
The TCPIP patch naming scheme changed in 2002, which caused confusion. The patches used to be named after the encrypted version (higher number), but then changed to call out the non-encrypted
number. Thus, the TCP581o.EXE patch was actually newer than the TCP590s.EXE patch. The TCP581o patch has versions 5.81o (Null) and 5.91o (Domestic). The TCP590s patch has versions 580s (Null) and
590s (Domestic). As of Feb. 23, 2003, the latest patches were TCP605o (NW6) and TCP581o (NW51SP4 or later). TCP553V.EXE is the last patch for NW 5.0.
There used to be two levels of encryption for TCPIP versions: 56-bit and 128-bit. (Actually, for a while there was a 40-bit version as well). The reason for having two levels was due to
government requirements on control of encryption. For a while in 2001, only France, to my knowledge, did not allow 128-bit encryption, without special approval, but that changed in 2002.
'Domestic' is 128-bit, while 'Export' is 56-bit. A MODULES TCPIP command will show you the encryption level of the TCPIP.NLM version that is loaded. Newer TCPIP patches contain only a 128-bit and
null version of TCPIP. In general, if you are not using BorderManager VPN, you do not need to use an encrypted version of TCPIP, and in fact it may be better not to use an encrypted version.
There are pre-NW51SP4 and post-NW51SP4 versions of TCPIP. If you are only up to the NW51SP3 patch, you should NOT use TCP590N.EXE or later. (Check the readme closely on new TCPIP patches as this might change). Pre-SP3 versions should be the 5.4/5.5 revisions of TCPIP.NLM. SP4 and later versions should be the 5.8/5.9 versions of TCPIP. If you have installed NW51SP4, you should not try to back-rev to a 5.4/5.5 version of TCPIP. The reason is given in the next paragraph.
Before NW51SP4, all TCPIP.NLM versions included all TCPIP stack functions within the basic TCPIP.NLM module itself. In NW51SP4, those functions have been separated into four different modules, and all the modules have interdependencies. The modules are:
These modules should not be mixed with other versions. The TCP590N.EXE (and later) patch does not contain the BSDSOCK.NLM - that file is contained in the NW51SP4 patch. Therefore, the
TCP590N patch has a dependency on NW51SP4 being installed, and if NW51Sp4 is installed, its BSDSOCK.NLM has a dependency on a later version of TCPIP than 5.5x.
BorderManager (versions prior to 3.8) installations will automatically install an encryption (Domestic or Export) version of TCPIP. If you then install TCPIP patches afterwards, the patches should
see that an encryption version of TCPIP is installed, and update TCPIP with an encryption version and not a Null version. But if you should somehow have a Null version installed when applying a TCPIP
patch, you will probably end up with a Null version of TCPIP running. You can simply look in the patch file for the Domestic version of TCPIP, and copy it to SYS:SYSTEM, and reboot the server. A
symptom of using the wrong TCPIP version in BorderManager is one or more public symbol messages regarding encryption modules at boot.
Some versions of TCPIP direct TCP DEBUG data to a special screen instead of the main console screen. Unfortunately, you cannot then use CONLOG to capture the data. This is true of TCPIP in the NW6SP1 patch and in the NW51SP4 patch. However, the issue has been fixed in the TCP590N.EXE (and later) patches, and debug data is again sent to the console screen. The TCP604S.EXE patch fixes this in a different way - the debug data is sent to the Logger screen instead of the server console. (You can save Logger screen to a file with F2. Later patch levels allow you to specify the location of the logger file as well.)
(Feb. 28, 2003) - When BorderManager 3.8 comes out, there will be a new version of TCPIP that will be different from all other versions for a certain period of time. BorderManager 3.8 moves away from using the SKIP protocol for VPN key exchange, in favor of IKE. (BorderManager 3.8 will still be able to use SKIP, but only for backwards capability in site-site VPN for BorderManager 3.0, 3.5, 3.6 and 3.7). One of the related changes is that BorderManager 3.8 will use a new IPSec library using NICI for encryption instead of using encryption within the TCPIP stack. The bottom line here is that BorderManager 3.8 servers will have a new, special version of TCPIP which will only be used on BorderManager 3.8. This leads to multiple versions of TCPIP with encrytion - BorderManager 3.7 servers will use the old ('bSafe') version of TCPIP, which will be distributed with normal patches, such as NetWare support packs. BorderManager 3.8 servers will only get TCPIP in BorderManager 3.8 patches. At some point, the new version of TCPIP will be merged into support packs for the next version of NetWare, and the old version will quit being updated.
Sep. 24, 2002 - There have been some problems reported with the latest versions of TCPIP patches ('H' series) when coupled with certain filter exceptions or DHCP servers.
Work-around is to back-rev to an older version of TCPIP. Should you have to back-rev TCPIP, you may find that you get a lot of error messages when you reboot the server, and TCPIP doesn't load. The
problem may well be that whatever version of TCPIP you changed to could not understand newer parameter in the SYS:ETC\TCPIP.CFG file. (The particular settings causing issues is dependent on both the
version of TCPIP you went up to and the version you backed off to). It will be obvious which settings cause problems because you will see a syntax error message when TCPIP loads when you reboot the
server. (Hint: put a pause in autoexec.ncf right after the INITSYS statement). You will have to manually edit out the offending lines from TCPIP.CFG and reboot the server until TCPIP is happy again.
Unless you have a backup of the old TCPIP.CFG file.
Dec. 19, 2001 - There was somewhat of a fiasco on the TCP553L.EXE patch in the past few days. Lessons have been learned at Novell, and I think going forward, there will be more testing on
BorderManager before a patch like that gets released again. Here's what happened: The TCP553L.EXE patch was released (in Internal Test status, which is semi-meaningless since all internal test
patches are also now available for download) with several new features. Load balancing, fault tolerance, dead gateway detection, bug fixes, PDF implementation guide, you name it, the patch had it.
Unfortunately, there was also a special version of INETCFG.NLM included which caused problems on BorderManager with VPN if you made a change in INETCFG and then rebooted. You would find the server
abending when the LAN drivers loaded. Using Netbasic/Shell, or TOOLBOX, you could copy back the old files (including tcpip.cfg, if you had it backed up) and reboot the server and recover. I went
through a series of troubleshooting steps myself when testing to see if the problem would occur to me. (It did). I had originally installed all the files in the patch except INETCFG.NLM, and had no
problems. A new version of the TCP553L.EXE patch has been posted on December 18, without the problem INETCFG installed. Check the readme carefully on the newer version of the patch.
Dec. 17, 2001 - TCP553L.EXE gets rave reviews from one user in the forums, and it comes with an implementation guide, updated support for INETCFG, and a load-balancing feature. Have a look at
it. (May be a later version out by the time you read this, so also check tip #1).
Aug 27, 2001 - The comments below, starting at the Feb. 8, 2001 warning, are mostly obsolete. There are still various TCPIP.NLM issues, but not discussed here so much. At the moment, the .0
and .255 problem discussed below is back again in the 5.52 versions of TCPIP.NLM, and a patch is supposed to be coming to fix them. The NW51SP3 version of TCPIP.NLM somehow missed the proper files
needed to configure Dead Gateway Detection, but there is a way to get that back. Have a look at tip #1A at this web site for post-NW51SP3 patches.
Feb. 8, 2001 WARNING - Loading NETDB /N manually before TCPIP loads may cause serious communications issues! A version of NETDB dated 4/13/00 (from some of the later support packs) is
implicated in the problem. See THIS LINK for more explanation. (Note: there should not be problems with this parameter in patches from about 2002 on).
New TCPIP AND an electronic guide to TCPIP - Jan. 25, 2001: Novell has a new version of TCPIP.NLM at www.novell.com/download (128- and 56-bit) in the
TCPIP Enhancement Pack. The version there is capable of supernetting and has been engineered to work with multiple CPU's. There is a also nice guide to TCPIP included in PDF (Adobe Acrobat) format.
The new version of TCPIP, naturally, is designed to work only with servers patched with a later version of the NetWare support packs:
This is one patch where you need to thoroughly study the README file before implementing.
In general, the problems with TCPIP are getting much better with the versions in the latest NetWare support packs. It should not be necessary to back-rev to TCPIP 5.31a anymore, with
the possible exception of BorderManager 2.1 servers. Also, I found an issue the other week on my test network (not confirmed anywhere else yet) where I was unable to establish a site-site VPN link
between TCPIP 5.32y and 5.31a. When I put 5.32y on both servers (one NetWare 4.11 with BorderManager 3.0 and the other NetWare 5.0 with BorderManager 3.5) the VPN link came up within seconds.
Note, Nov. 30, 2000: Novell says about the filtering modules in BorderManager that "they are NetWare OS dependency NLMs. Both share same header files with OS's TCPIP.NLM modules. All must go
together in order to work correctly. We had many customer instances installing BorderManager support packs without updating TCPIP.NLM module causing filtering problems. Upgrading TCPIP.NLM must also
upgrade the entire OS patch."
Somewhat like intermittent NAT, there have been reports of TCPIP problems along the lines of communications slowly grinding to a halt. Novell has released quite a number of new versions
of TCPIP.NLM over the past couple of years, not all of which were publicly known. The only version (as of 6/2/00) that I am comfortable with is 5.31a, the 40-bit version of which is found in the BMTCPE4.EXE patch. This version seems very stable, as long as the following set parameter is used:
SET TCP IP MAXIMUM SMALL ECBS=65534
If you have 128-bit encryption set up, this version will not work for you. Novell used to have a domestic (128-bit) version available, but I don't know if it is still available. You would have to
contact Novell about that.
To install this version, first make a copy of the TCPIP.NLM currently in use in your sys:system. Next, simply copy the 5.31a version into sys:system. Next, add the above SET statement into
autoexec.ncf. Finally, reboot the server. Get the BMTCPE4.EXE patch here. Read the November 30 note above first.
The issues that I see with the newer versions of TCPIP.NLM are basically that new features and new bugs have been added. The new features include limited support for CIDR (supernetting), but only as
an end-node. As a BorderManager server, end-node CIDR support is of very limited use, though it can be used in specific instance (like when ONLY proxies, VPN and IP Gateway features are being used -
no dynamic NAT and routing support). Also, the newer versions of TCPIP.NLM are *supposed* to have fixed the .0 and .255 addressing problem, but I can't confirm that for sure on all versions, though
5.31o, 5.22j and 5.32j all worked OK for me in some limited testing..
The .0 and .255 addressing problem: If you have a valid class A or class B subnet, and probably variable length subnets greater than a class C, you can have legitimate IP addresses like the
following, for a 172.16.0.0 network with 255.255.0.0 subnet mask.
The network number for the above network is 172.16.0.0 and the broadcast address is 172.16.255.255. All addresses, including ones with .0 and .255 in the third and fourth octects, are
valid host IP addresses. If you are used to class C (255.255.255.0) subnet masks, this may seem confusing.
The problem is that many early versions of Novell's tcpip stack will IGNORE those valid IP addresses which have a .0 or .255 as part of them. In my NetWare configurations using such networks,
I configure DHCP to reserve such IP addresses and avoid putting them on servers and routers. For best results, I suggest you also avoid using such host addresses. Newer versions of tcpip.nlm are not
supposed to have this issue. I have personally done some testing of 5.31o, 5.22j and 5.32j and found that they can communicate to such valid class A addresses as 10.0.0.255 and 10.0.255.255, and
class B address 172.16.0.255. So far, I have not tested 5.31a for this issue.
UPDATE, July 19, 2000: Apparently the .0 and .255 addressing problem still exists under certain conditions when certain versions of IPFLT.NLM and IPFLT31.NLM in BorderManager 3.x are in use.
(These modules provide IP packet filtering capability). Novell is working on new versions of these NLM's, and will send you a copy to try if you open an incident. I am told these modules have some
issues and are not ready for general release, but at least one user in the public forums reported that they worked for him. I am trying to get more information on just how the filtering modules
affect communications in this way.
Problems With GWIA and TCPIP.NLM 5.32j from NetWare 5.1 Service Pack 1: One of the sysops reported that immediately upon applying the NetWare 5.1 Service Pack 1 to his BorderManager 3.5
server, GWIA quit sending SMTP mail. In his configuration, GWIA was running on an internal NetWare 5.0 server and using a Static NAT connection on the BorderManager server for inbound/outbound
mail.
His comments:
"I installed NW5.1 SP1 on my BM server last night, and it installed the dreaded TCPIP 5.32j.
Now, GWIA won't send any mail out....all mail is coming back "450 Host Down". Can't ping 207.36.148.84 from outside. Can't connect to POP3 of GWIA."
Solution: Backrev the TCPIP.NLM to the previous version, which was 5.31o, the one that ships with NW5.1.
Note, Nov. 30, 2000: I have heard from Novell that supposedly there should be no problems running the same version of TCPIP.NLM on both a BorderManager server running GWIA and a GroupWise
server. (Meaning - put the BorderManager version of TCPIP on the GroupWise server). Doing this must take into account Novell's recommendation that the version of TCPIP used is also tied to the
version of the NetWare support pack due to file dependencies.
Running BorderManager versions of TCPIP.NLM on Non-BorderManager Servers: The 5.31a version of TCPIP *should* be useable on non-BorderManager servers. However, there may be some issues with
GroupWise servers. I don't have enough experience with GroupWise to know for sure, so if anyone can confirm specific instances of GroupWise/BorderManager incompatibility with tcpip.nlm versions,
please let me know in the Novell public forums.
Support Pack Issues and TCPIP.NLM Versions: There are (at least) two issues commonly seen when applying certain NetWare service packs to a BorderManager server, or installing BorderManager on
a patched server.
1. Installing BorderManager to a server that already has NW4SP4 installed - You can end up with 0 byte length files, TCPIP.NLM being one of them, in sys:system. Look for any such files and manually
replace them with the BorderManager versions. BorderManager 3.5 wants to be installed to a server with SP2 installed, and SP2 is included on the BorderManager CD. Once you install BorderManager 3.5
and replace any 0 byte files, go ahead and install the BM35SP1.EXE patch (it is VERY much needed).
2. Installing a new service pack on a BorderManager 3.x server with TCPIP 5.31a installed - the newer service packs will replace the older version of BorderManager TCPIP.NLM with a newer, 56-bit
version. You will also see a note in the installation process which informs you of this. You can try the newer version and see if if works (give it a month or so), but if you have problems, try
reverting to the old version. Also be sure to make that SMALL ECBS setting above if using TCPIP 5.31a.
Note to BorderManager 2.1 users - for best results, do not apply any service packs later than IWSP6A to your server. If you have, and you are having problems, back off the later service packs.
BorderManager 2.1 was end-of-life some time ago, and the newer NetWare patches will break things or cause problems.
What are the different versions of each TCPIP.NLM revision all about? Novell has made three versions of TCPIP.NLM for each revision since BorderManager came out. Supposedly, the only
difference is an encryption module included. One version, seen on non-BorderManager servers, though perhaps not with NetWare 5.1 (since it includes a Certificate Server option) is the NULL version.
This version will have no encryption capabilities. The other two versions are the Domestic and Export versions. Domestic versions (for USA and Canada) have 128-bit encryption modules, while Export
versions have 40-bit or 56-bit encrytion modules. As the USA is changing requirements on export of cryptographic products, there is some confusion over what is available for download and what will be
available in the future. Hopefully, the Export version will be eliminated and everyone can get a domestic version at some point (see June 21 note below). In the past, you had to call Novell and
request a domestic version of TCPIP.NLM.
What's up with the export and domestic versions of various patches? For some time now, the 128-bit version of TCPIP.NLM was legally blocked for export outside of the USA and Canada. There are
other 128-bit enabled encryption modules (NICI and JSSL) that can be exported without a problem. For instance, 128-bit versions of encryption-related files are available worldwide in the NetWare 5.1
Service Pack 1 (D51SP1.EXE, a 244MB monster download), EXCEPT for the TCPIP.NLM files, one of which is 56-bit, while another is null (no encryption). SEE THE NEW NOTE BELOW!
As of June 21, 2000: You can download the 128-bit version of TCPIP.NLM for NetWare 5/5.1 and NW4 (if NW4SP8A is installed first) by going to
support.novell.com and downloading NW5TCP.EXE. Also, the NW 5.1 support pack has been renamed to NW51SP1 and now includes the 128-bit version of TCPIP.NLM. However, you must fill out a
small form to perform at least the NW5TCP.EXE download, and Novell does not have approval to ship the 128-bit version outside the USA or Canada to BorderManager customers. I'm not sure how to
interpret this restriction, except perhaps that Novell cannot proactively ship the 128-bit version to everyone. Note that the newer support packs for NetWare 4.11/4.2, 5.0 and 5.1 are coming with
128-bit TCPIP versions in one of the subdirectories.
Also read TID 2956935, at this link.
Prior to June 21, 2000 - How do I get a domestic version of TCPIP.NLM? This information was provided by Novell on June 8, 2000, and I leave it here for reference. THIS INFORMATION IS NOW
OBSOLETE, SEE THE PREVIOUS PARAGRAPH! It will (may?) be available shortly as a TID as well. I do not know that the requester has a choice as to which version of TCPIP.NLM will be sent, as Novell
is likely to only want to distribute whichever version is the latest. Don't count on getting beta versions either.
"Goal: How do I get the 128bit TCPIP.NLM file?
Fix: Due to government restrictions Novell is not able to provide this as a free, public download file. You must call 800-858-4000 to request it. There is a form that will be emailed to
you, in .PDF format. Print the form, fill it out and fax it back to the number provided and the file will then be sent to the same email address used for the form."