Need for explanation: NetBIOS over TCP/IP on VMware network adapter disturbs access to network shares

Question

(Moved here from StackOverflow)

Some time ago nearly all workstations in our team (Windows XP SP2) exhibited intermittend but frequent delays when accessing shares on the network. Typically the first access to a share which hadn't been accessed for some time resulted in a nearly frozen workstation for up to 30 seconds. Then everything started working fine again.

Using TCPView from Sysinternals I saw that during this delays there was a connection to the netbios-ssn port on the file server which was in state SYN_SENT.

First try:

Disable NetBIOS over TCP/IP for the intranet network adapter.

Problem solved, but I didn't like to manipulate our centrally managed network configuration for the intranet.

Second try:

Disable NetBIOS over TCP/IP only for the VMWare network adapter (VMNet1 used for host only communications).

Problem solved again!

My questions:

• Why does NetBIOS over TCP/IP on one network adapter disturb NetBIOS over TCP/IP on another network adapter?
• Is this problem specific to VMWare network adapters?
• Has anybody else seen this phenomen?

Additional information:

• VMWare Workstation version 6.0.3
• At the time I started seriously analysing the problem it was no more possible to find out what had been changed to our systems at the time the problems started.

Solution

I have seen a similar phenomen.

Symptoms sound not too similar at first sight: Windows Explorer sometimes hangs for a few seconds regardless whether a local disk or a network share is accessed.

But after some investigation I believe the hang is caused by a similar NetBIOS issue.

Some system details:

• Windows XP Pro SP3
• VMware Server 1.0.9 installed
• VMNet1 (host-only) network adapter and NetBOIS over TCP/IP enabled
• VMNet8 (NAT) network adapter and NetBOIS over TCP/IP enabled
• The system's only physical network adapter's static IP address is 192.168.10.111. This adapter is configured to use 192.168.10.192 as its only WINS server. MAC address: 00-16-17-FA-2C-D4
• On the VMNet1 adapter the system's static IP address is 192.168.137.1. No WINS server configured. MAC address: 00-50-56-C0-00-01
• On the VMNet8 adapter the system's static address is 192.168.145.1. No WINS server configured. MAC address: 00-50-56-C0-00-08
• All VMs are configured to use NAT but are stopped anyway.

I was running Wireshark all day sniffing packets on the physical adapter. I noticed that whenever Explorer hung for a few seconds simultaneously a NetBIOS Name Service query packet was sent to the WINS server. These packets contained one of the VMNet adapter's address as its source IP address!

Here's one of the suspicious packets:

Frame 25475 (92 bytes on wire, 92 bytes captured)
Ethernet II, Src: 00:16:17:fa:2c:d4 (00:16:17:fa:2c:d4), Dst: 00:15:c5:87:4f:6a (00:15:c5:87:4f:6a)
Internet Protocol, Src: 192.168.145.1 (192.168.145.1), Dst: 192.168.10.192 (192.168.10.192)
User Datagram Protocol, Src Port: netbios-ns (137), Dst Port: netbios-ns (137)
NetBIOS Name Service
  Transaction ID: 0x82a5
  Flags: 0x0000 (Name query)
  Questions: 1
  Answer RRs: 0
  Authority RRs: 0
  Additional RRs: 0
  Queries
    *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>: type NBSTAT, class IN

I think this is not correct. The packet's source IP address should be set to 192.168.10.111 instead.

I haven't sniffed packets on the WINS server's interface. But I expect it to send a reply to 192.168.145.1 via its default gateway since it is not connected to the 192.168.145.0 network. The gateway should reject this packet with "network unreachable".

As this is a UDP packet there's no connection in SYN_SENT state. But a TCP SYN packet that is "corrupted" in the same way should leave the connection in SYN_SENT state until a timeout occurs.

Some things I tried to work around this problem:

1. Disable both the VMNet adapters: Problem solved. No suspicious packets.
2. Re-enable VMnet1: Explorer starts again hanging sometimes. Suspicious packets with source 192.168.137.1.
3. Disable VMNet1 and re-enable VMNet8: Explorer hangs sometimes. Suspicious packets with source 192.168.145.1.
4. Enable both the VMNet adapters, but disable NetBIOS over TCP/IP for both: Problem solved. No suspicious packets.
5. Re-enable NetBIOS over TCP/IP for VMNet1: Explorer starts again hanging sometimes. Suspicious packets with source 192.168.137.1.
6. Disable NetBIOS over TCP/IP for VMNet1 and re-enable it for VMNet8: Explorer hangs sometimes. Suspicious packets with source 192.168.145.1.
7. Change interface metrics from automatic metric to static values for all interfaces. The LAN adapter having the lowest metric: Explorer still hangs sometimes and suspicious packtes captured.

I have checked adapter ordering in Network Connections->Advanced->Advanced Settings as well as by running netsh interface ip show config. Local Area Connection is the first connection listed in both places.

Additionally I noticed some NTP packets with source IP address 192.168.137.1 as well as 192.168.145.1 being sent to 192.168.10.192 (it's an AD DC) via the physical adapter.

Comments

[gyrolf]

Thank you very much for this detailed information. Unfortunately I don't have enough repution (at least in Server Fault) to vote your answer up.