Slow logins due to unexpected eDirectory referral costing choices by Novell Client IP Costing

When costing the referrals returned by an eDirectory object resolve, the Novell Client can be observed to consistently or intermittently choose the first referral returned instead of the most optimal referral.

This results in the workstation connecting to more and/or different Novell servers than expected, which can also lead to slower eDirectory access performance depending on the performance of the referral selected (due to WAN links, distance, etc.).

Apply the latest post SP5 NWFS.SYS found at https://download.novell.com/Download?buildid=ITyGMZlRZdc~ .

Change the product to Novell Client and Novell Client 4.91 SP5 for Windows XP/2003.

In the Keywords field enter NWFS.SYS

Select the latest version of NWFS.SYS available

In Novell Client IP Costing, there are several factors that are taken into account beyond simply "round trip time" (when ICMP Echo is being used) or "closest subnet" (when subnet matching is being used).  Those additional factors include the number of hops (estimated according to the remaining IP TTL if ICMP Echo costing is used); whether the workstation already has an established NCP connection to the specified address; and whether the address represents the preferred protocol configured on the workstation.
 
In addition, and specific to the processing of eDirectory referrals (as opposed to more general name resolution and costing through SLP, DNS, etc.), an additional factor of whether the referral address is one for which we already know the entry ID of the object being resolved is taken into account.  Since depending on the usage context of the eDirectory object resolve, this can optimize both client and server operation by eliminating one or more re-resolves of the object to its corresponding entry ID.
 
The issue identified was that this "entry ID is known for this referral" costing factor was causing that referral to simply always "win", when in reality this factor should have been secondary to other conditions such as whether we already had an established NCP connection to that address, and whether that referral was non-optimal from a round-trip time or subnet matching perspective.
 
To resolve this issue the eDirectory referral processing has been adjusted to provide this "entry ID is known for this referral" costing bias only when the workstation already has an established NCP connected to the address in question.  Such that the referral for which we already know the eDirectory entry ID will "win" over other established NCP connections the workstation has.  But will take factors such "round trip time" or "closest subnet" into account if a new NCP connection is needed, rather than proceeding based on the "entry ID is known for this referral" condition alone.