Here's a list of useful TIDs describing common problems and workarounds that customers have encountered with the TCPIP common server stack. Symptom:- After loading the new TCPIP.NLM (v4.0), the server could no longer PING any of the remote networks it could previously connect to. Looking at the contents of the routing table, we saw that it no longer had the default route entry statically assigned, as well as a number of static routes that existed beforehand. Solution:- Make sure that TCPIP.NLM is loaded with the option STATIC=YES. Previous versions of the stack used the IPCONFIG.NLM to force a reading of the sys:\etc\gateways file where the static routing entries were inserted. With the TCPN04 patch, the IPCONFIG is a dummy NLM for backward compatibility and the STATIC=YES option when loading TCPIP actually reads in the entries from sys:\etc\gateways. TID #2927775 ============ Symptom:- When attempting to bind an ip address to a LAN Interface via INETCFG, the following error occurs: The local IP address "194.131.128.202" with mask "ff.ff.ff.c0" is not a valid combination. The subnet part of the IP address cannot be all ones. <Press ENTER to continue> When executing the BIND statement from the server console, everything bound correctly. Cause:- With TCPN03.EXE, (tcpip.nlm server patch) the TCPIP.NLM stack for the server allowed the all ones subnet ip addresses as well as the all zeros subnet. However, the INETCFG does not recognize these as valid ip addresses and subnet masks. The TCPN04.EXE patch will contain a new TCPCFG.NLM (TCPIP snap in to INETCFG) that will solve this. TID #2927651 ============ Symptom:- Even though INETCFG seems to have the default / static routes configured correctly, they don't show up (or the wrong address shows up) in TCPCON (IP Routing Table). Troubleshooting:- Verify the following: - the latest TCPIP.NLM has been applied (from TCPN04 at the time of this writing) - in INETCFG, Bindings, TCPIP, RIP Bind Options, Originate Default Route is DISABLED - in SYS:ETC\TCPIP.CFG, OriginateDefault is set to OFF - SYS:ETC\GATEWAYS has the correct syntax for the default route (i.e. Net 0 <ip address> Gateway Metric 1 Passive TID #2928157 ============ Symptoms:- Considering the following configuration: RtrA ----(lan/rip)---- RtrB ----(wan/lan/ospf)-----RtrC RtrA is runing RIP on its interface RtrB is running Both Rip and Ospf (ASBR) on its interfaces RtrC is running OSPF only RtrB has filters configured for OSPF, in Deny Mode, ALL routes deny What this means is that RtrB should deny all routes learnt from A to C in its OSPF domain. A advertises RIP routes to B and B takes in the RIP routes (because it is an ASBR) and turns them into OSPF routes, before sending it to C. Now when we have a deny filter configured on B, it should deny all these routes to C. The problem is that when the router comes up or when IPFLT modules are unloaded or reloaded, the OSPF filters alone are NOT activated until you do a reinitialize system on B or manually "touch" them through the filtcfg utility again. Solution:- There are 2 work arounds for the above problem:- 1) "Reinitialize system" after nodifying any OSPF filters and/or 2) manually touching (add/del/change) the filter via FILTCFG to make it effective The reinit solution makes more sense. When you down and bootup, or simply unload ipflt/reload ipflt and execute reinitialize system, all the OSPF "dead" filters come alive. TID #2922805 ============ Issue:- When loading the new common stack (TCPIP.NLM v4.0) on a Netware 3.12 server, the message "Unable to find load file CSL.NLM" is printed to the console screen when autoloading the CSLIND.NLM. The goal of the CSLIND module is to dynamically import WAN functions from the CSL.NLM, assuming that a version of MPR is running on the Netware 3.12 server. These WAN functions are used to initiate calls, authenticate, negotiate data being exchanged at the CSL layer. Assuming that no MPR was isntalled on the Netware 3.12 server, the request to import these WAN functions will fail because no CSL module will have been loaded. Any user that sees this message and does not have the MPR 3.x product installed should simply ignore this error. TID #2921532 ============ Symptom:- After loading the new TCPIP.NLM (v4.00 from TCPN03.EXE) on a Netware 3.12 server, any static route that previously existed were lost ie. the administrator would no longer be able to see it throuth TCPCON's routing table option. Solution:- We need to follow these steps:- 1) create a \sys:\etc\netinfo.cfg file with 2 lines- #!VERSION=2.3 load IPCONFIG 2) make sure that his sys:\etc\gateways syntax is correct- host/net <address> gateway <address> metric <eg.1> passive 3) create a file sys:\system\tcpcfg.nlm - just a dummy file! 4) make sure TCPIP is loaded with the parameter STATIC=YES to force a reading of the SYS:\ETC\GATEWAYS file eg. LOAD TCPIP FORWARD=NO STATIC=YES