Article ID: 838207
Article Last Modified on 7/8/2005
APPLIES TO
- Microsoft Windows XP Home Edition
- Microsoft Windows XP Professional
INTRODUCTION
This article describes the networking problems and update scenarios that are addressed in Microsoft Windows XP Service Pack 2 (SP2).
For additional information about the problems that are resolved in Windows XP SP2, click the following article number to view the article in the Microsoft Knowledge Base:
811113 List of fixes included in Windows XP Service Pack 2
MORE INFORMATION
Windows XP SP2 addresses all the following networking-related problems and update scenarios:
A server error occurs when you try to start a remotely created ASP.NET program
After you create an ASP.NET program on a remote computer, when you try to start that program, you receive a "server error" error message.
Update to resolve a problem where certain real-time communications client computers can receive video but cannot send video
Real-time communications client computers that use certain network adapters can successfully send Real-Time Control Protocol (RTCP) packets. However, these computers do not send Real-time Transport Protocol (RTP) packets successfully. This problem occurs if Windows binds the Quality of Service (QoS) protocol to the socket where the RTP packets are sent from. This update changes the default Layer 2 priority behavior for the generic QoS (GQoS) protocol implementation.
Update to add functionality to the Peer Name Resolution Protocol (PNRP) service
This update introduces new policy settings to permit all the following PNRP modifications:
- Disable Peer-to-Peer Networking
- Set the seed server
- Disable multicast bootstrap
You experience occasional file-sharing problems on a multihomed computer
When you try to access shared resources from a computer that has more than one IP address assigned, you may experience occasional problems. On a computer that has more than one IP address, the NetBIOS transport (NetBT) registers the computer's name and IP address with the multihomed flag set. A computer that has more than one IP address may have more than one network adapter, a VPN connection, an IEEE 1394 adapter, or a dialup adapter. If this computer later obtains a new IP address, Windows Internet Name Service (WINS) keeps the original IP address until the tombstone interval expires. This causes stale IP addresses to remain cached in WINS. In NetBT, if you resolve the computer name by using WINS, and if that computer name has more than one IP address assigned, NetBT sends Internet Control Message Protocol (ICMP) packets to connect to each of these IP addresses to determine the valid IP address. If there is no response to the ICMP packets, NetBT tries to connect to the first IP address that it received from the WINS server. In this scenario, the following two problems may occur:
- The first IP address that NetBT received from the WINS server is not the correct IP address.
- If the WINS server has more than 3 IP addresses assigned for the remote computer, the NetBT timeout counter expires before you can successfully connect to the remote computer.
Because the default setting in Windows XP SP2 is to turn on Windows Firewall, you may experience occasional file sharing problems. To resolve this problem, this update configures Windows XP to respond to inbound ICMP packets if traffic to TCP port 445 is permitted. If traffic to TCP port 445 is not permitted, Windows XP does not respond to the inbound ICMP packets.
Update to permit the Cisco VPN Client program to work in TCP transport mode in Windows XP SP2
After you install a pre-release version of Windows XP SP2, if you configure Cisco VPN Client version 4.0.3.D to use Internet Protocol security (IPSec) over TCP, you receive the following error message when you try to connect to a Cisco VPN concentrator:
This problem occurs because the TCP/IP protocol is changed to drop any packets that are directed to the loopback IP address, but that arrive on an interface other than the loopback interface. Because the Cisco VPN client sends packets to the loopback IP address, but the packet comes from a physical interface, the packets are dropped.
Peer-to-Peer networking stops functioning when the profile policy changes from Standard to Domain
After you install a pre-release version of Windows XP SP2, when you enable the Peer-to-Peer (P2P) networking component, the Peer to Peer Setup program opens the required ports to enable peer-to-peer functionality. If you type netsh firewall show portopening and then press ENTER, you notice that the Setup program only opens ports for either the Standard profile or the Domain profile. Therefore, if the profile policy changes, P2P no longer functions. This update modifies the P2P Setup program to open both the Standard profile ports and the Domain profile ports. After you install this update, when you enter this command, you receive results that are similar to the following:
Port configuration for Domain profile: Port Protocol Mode Name ------------------------------------------------------------ 3587 TCP Enable Windows Peer-to-Peer Grouping 3540 UDP Enable Peer Name Resolution Protocol (PNRP) 1900 UDP Enable SSDP Component of UPnP Framework Port configuration for Standard profile: Port Protocol Mode Name ------------------------------------------------------------ 3587 TCP Enable Windows Peer-to-Peer Grouping 3540 UDP Enable Peer Name Resolution Protocol (PNRP) 1900 UDP Enable SSDP Component of UPnP Framework Port configuration for Local Area Connection: Port Protocol Mode Name ------------------------------------------------------------ 3544 UDP Enable Teredo
A DirectX program may stop responding if Windows Firewall removes focus from it
If a DirectX program is running in full-screen mode, and Windows Firewall removes focus from it to display a message, that program may stop responding. This update configures Windows Firewall to display messages in the background if a DirectX program is running in full-screen mode.
The Recv function returns a socket error in APC function calls
When you use the QueueUserAPC function to open the Socket function in an asynchronous procedure call (APC) thread, the Recv function returns a socket error.
When a blocking Winsock call is issued, Winsock may have to wait for a network event to occur before the call can complete. Such calls include calls to the Send, Recv, Select, Accept, and Connect functions. In this scenario, Winsock performs a wait operation. However, this operation can be interrupted by an APC that is scheduled on the same thread. When this problem occurs, unexpected results may occur.
Roaming profiles fail to download when using 802.1x
Roaming profiles could not be downloaded because 802.1x would cancel authentication attempts in cases where the user data could not be saved to the registry. This problem may occur at logon time because the user's HKCU registry hive was not fully loaded from the remote profile. Windows XP SP2 is more resilient when it saves the user data to the registry, enabling 802.1x authentication to continue and the roaming profile to load. RFC 54637
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.
Additional query words: winxpsp2 xpsp2
Keywords: kberrmsg kbinfo kbtshoot kbbug kbfix kbfirewall kbenv kbsecurity kbprb kbbackup KB838207
