Environment
Novell Client for Vista
Situation
When attempting the initial login from the Credential Provider, the
user sees "tree or server not found" type messages. After several
retries (about 30 seconds), the login is eventually successful.
Examining LAN traces taken while the machine was experiencing the failure, we see that the workstation was broadcasting traffic, but none of the packets were being seen by the target server. When the packets finally made it to the server, it responded immediately and the login completed successfully.
Examining LAN traces taken while the machine was experiencing the failure, we see that the workstation was broadcasting traffic, but none of the packets were being seen by the target server. When the packets finally made it to the server, it responded immediately and the login completed successfully.
Resolution
The problem can be resolved by setting the switch port to the
abbreviated version of STP (instead of the full 30-second hold-down).
Cisco calls this mode "PortFast".
Additional Information
Often, the first thing tried in these cases is to replace the name of the tree/server in the login dialog with the IP address of the tree/server. This removes the name resolution step from the login process. With the IP address defined, the workstation next needs to know the MAC (hardware) address of the server so that a connection can be established. This requires an Address Resolution Protocol (ARP) request be broadcast.
ARPs, SYNs, ACKs or RSTs and retransmits are all functions of the Microsoft TCP/IP stack. The Novell Client resides above the TCP/IP stack, and simply says "please establish a TCP session to port 524 on host XX.XX.XX.XX"; from there it's up to the TCP/IP stack to decide whether an ARP needs to be sent at all, if it does need to be sent, how long should it be attempted, if we successfully ARP the destination how many SYN attempts should be made, etc.
So at the Novell Client level, we're simply moving from one point of requesting "please establish a TCP session to port 524 on host XX.XX.XX.XX" to the next, and the TCP/IP stack returns back "success" or "failure" to each attempt. What exactly had to happen on the wire, if anything at all, in order for the TCP/IP stack to make the success or failure determination is not something we have a hand in.
Note that in some cases, connection problems may exist while connecting with the Novell Client for Windows Vista, while they are not seen with the Novell Client for Windows XP/2003. This can be explained by understanding that, due to design differences, the Novell Client for Windows Vista behavior isn't going to be completely identical to the Novell Client for Windows XP/2003 behavior, with regard to exactly how early the attempts start, exactly how many attempts to connect at an NCP level to a given address are made, how soon we give up at an NCP level, etc., since they are engineered differently. In addition, we also have Microsoft's re-written TCP/IP stack for Windows Vista as compared to Windows XP/2003 and earlier. This can result in the Windows Vista workstation behaving differently as compared to Windows XP in the face of STP hold-down of traffic being forwarded off the port.
If shortening the STP processing or turning it off entirely aren't options, the fallback recommendation is to force the Windows machine to acquire its IPv4 address via DHCP. If the network card is going to be for all intents and purposes "up, but non-functional" for ~30 seconds, then having Windows configure the IPv4 interface via DHCP will prevent Windows from thinking the interface is ready from an IPv4 perspective. Until such time that the port finally /is/ forwarding traffic, and therefore the DHCP retries have succeeded, and therefore Windows essentially "delays" telling any software there is an available IPv4 interface until it actually is ready for use.
ARPs, SYNs, ACKs or RSTs and retransmits are all functions of the Microsoft TCP/IP stack. The Novell Client resides above the TCP/IP stack, and simply says "please establish a TCP session to port 524 on host XX.XX.XX.XX"; from there it's up to the TCP/IP stack to decide whether an ARP needs to be sent at all, if it does need to be sent, how long should it be attempted, if we successfully ARP the destination how many SYN attempts should be made, etc.
So at the Novell Client level, we're simply moving from one point of requesting "please establish a TCP session to port 524 on host XX.XX.XX.XX" to the next, and the TCP/IP stack returns back "success" or "failure" to each attempt. What exactly had to happen on the wire, if anything at all, in order for the TCP/IP stack to make the success or failure determination is not something we have a hand in.
Note that in some cases, connection problems may exist while connecting with the Novell Client for Windows Vista, while they are not seen with the Novell Client for Windows XP/2003. This can be explained by understanding that, due to design differences, the Novell Client for Windows Vista behavior isn't going to be completely identical to the Novell Client for Windows XP/2003 behavior, with regard to exactly how early the attempts start, exactly how many attempts to connect at an NCP level to a given address are made, how soon we give up at an NCP level, etc., since they are engineered differently. In addition, we also have Microsoft's re-written TCP/IP stack for Windows Vista as compared to Windows XP/2003 and earlier. This can result in the Windows Vista workstation behaving differently as compared to Windows XP in the face of STP hold-down of traffic being forwarded off the port.
If shortening the STP processing or turning it off entirely aren't options, the fallback recommendation is to force the Windows machine to acquire its IPv4 address via DHCP. If the network card is going to be for all intents and purposes "up, but non-functional" for ~30 seconds, then having Windows configure the IPv4 interface via DHCP will prevent Windows from thinking the interface is ready from an IPv4 perspective. Until such time that the port finally /is/ forwarding traffic, and therefore the DHCP retries have succeeded, and therefore Windows essentially "delays" telling any software there is an available IPv4 interface until it actually is ready for use.