TCP bridged connection loses Windows Network Places

[upandacross]

I'm having a little trouble keeping a UDP connection up reliably at public hotspots (sometimes dies after 2 minutes requiring a Reconnect). After experimenting with a TCP connection, I found it seemed to stay up better at certain hotspots but when exploring My Network Places after a TCP connect, I see only the laptop in my MS Workgroup (my desktop computer hosting the OpenVPN server does not show up). Unlike a TCP connection, a UDP connection does show both computers in the workgroup including the desktop computer.

Reading the log I noticed a difference in the client events leading to a TCP connection vs a UDP connection. Now I'm using ip-win32 netsh on the client as I've found this more reliably sets the Tap's address (and may allow MS to modify the netsh code to conform to a new OS, e.g. Vista). In addition to setting the TAP's address, there are two additional calls to netsh on a TCP connection: 1) delete the Tap's DNS; and 2) delete the Tap's WINS. This latter delete might explain why all hosts in the Workgroup don't show up in a TCP connection. The UDP connection log shows a single netsh call to set the Tap's address via dhcp without changing the DNS or WINS.

I suppose the questions are: 1) do I have this right?; and 2) can I/should I eliminate or override the deletion of DNS and Wins on a TCP connection?

[upandacross]

Just so nobody spends a lot of time on this, I've gone back to udp (performance risk associated with tcp is too great).

As for the network places problem, the ways of NETBIOS are many and mysterious. I seem to have resolved the issue with several measures (some of which may be superstition as changing lots of variables means you're not sure which are needed and which didn't matter).

This is what I did:

1. Reran Windows Network Setup Wizard from Control Panel - didn't change anything but let it reinitialize the windows network to a known state (requires reboot afterward).
2. Updated client's registry TCP Parameter IPEnableRouter to 1.
3. Added route-delay to client conf file (no parameters for route-delay letting it default).
4. Added dhcp-renew and dhcp-release to client conf file (I set Tap device to "Always Connected" to avoid the annoying "getting network address" that never resolves if I don't run OpenVPN).

As I said, some of this may have no effect but I'm tired and don't have the energy to try every permutation to see what matters.

Now the Tap device reliably gets DHCP, gateway, dns, and dhcp addresses. Windows' My Network Places works as expected. Life is good.