Windows file sharing connects over WiFi instead of LAN

Question

I have a laptop and a desktop computer, and I need to sync lots of files to the laptop and back whenever I go on a trip, etc. I've got a LAN cable connected into an extra port on the desktop that I plug into the laptop so I can get gigabit file transfers instead of wireless G. They connect fine.

If I do an FTP transfer, for instance, using the LAN IP addresses, it goes at ~40MB/s, as it should. However when I copy files using explorer and native windows file sharing it detects the other computer by name, not IP (eg \\DESKTOP-PC\ instead of \\192.168.0.100\) and always connects to it by its wireless IP address instead of the faster LAN address.

Both computers are running Windows 7. I have tried editing the priorities of the adapters in Advanced Settings and putting the LAN adapters above the wifi ones, but this didn't have any effect

Results of nbtstat -c: (on desktop)

Node IpAddress: [192.168.56.1] Scope Id: []

    No names in cache

Local Area Connection: (lan connection, using *.*.1.*)
Node IpAddress: [192.168.1.180] Scope Id: []

    No names in cache

Wireless Connection: (wifi connection, using *.*.0.*)
Node IpAddress: [192.168.0.180] Scope Id: []

    No names in cache

Hamachi:
Node IpAddress: [0.0.0.0] Scope Id: []

    No names in cache

VMware Network Adapter VMnet1:
Node IpAddress: [192.168.126.1] Scope Id: []

    No names in cache

VMware Network Adapter VMnet8:
Node IpAddress: [192.168.101.1] Scope Id: []

    No names in cache

Local Area Connection 2:
Node IpAddress: [0.0.0.0] Scope Id: []

    No names in cache

Nothing changed after running nbtstat -R

Answer 1

Netbios caches names, so if it already has an ip bound, it will use it. To clear cache, you need to issue nbtstat -R on your laptop. If you try to connect after clearing cache, netbios will issue query on all interfaces (assuming there are no open sessions to your desktop, so you need to close those as well), and then name will bind to first response which is non deterministic - however in my small 'lab' it always bound 'properly' ie to wired adapter.

Assuming your wired connection IP on desktop is static you could also put a static binding on your laptop using LMHOSTS. You would need to enable LMHOST lookup (it's done in Advanced properties of TCP/IP), then put a line in LMHOSTS (typically located at: C:\Windows\System32\drivers\etc\, if you never used it there will be only LMHOSTS.sam which you need to rename or just create empy LMHOSTS:
your.desktop.ip.address your_desktop_computer_name

This will still need purge/Reload of netbios cache for this to work

Edit: Addtionally you may look into this document: http://support.microsoft.com/kb/166159 as it seems to offer a way to always bind to primary adapter, but I have not tested if/how it works.

TCP Connections to and from Multi-homed Computers If the connection is a NetBIOS-based connection that uses the redirector, little routing information is available at the application level. The NetBIOS interface supports connections over various protocols and has no knowledge of IP. Instead, the redirector places calls on all the transports that are bound to it. If there are two interfaces in the computer and one protocol is installed, there are two transports that are available to the redirector. Calls are placed on both transports. NetBT submits connection requests to the stack by using an IP address from each interface. Both calls may succeed. If so, the redirector cancels one of them. The choice of which one to cancel depends upon the redirector IgnoreBindingOrder registry value. If the registry value is 0, the primary transport, which is determined by binding order, is the preferred one. The redirector waits for the primary transport to time out before accepting the connection on the secondary transport. If this value is 1, the binding order is ignored. The redirector accepts the first connection that succeeds and cancels the others.

Answer 2

By far the most reliable method is to connect using the Ethernet IP address of the target.

There are articles that suggest that you can get around this using metrics on the routing table. This is incorrect and it is not a reliable method.