Friday, August 24, 2007

Fileshares: Connecting with the wrong hostname

Situation: Occasionally I need to connect to servers with names formed from a spoon of alphabet soup - impossible to remember. Of course, since the customer is always right, he gets to choose the names of his own server. I however, need to refer to computer names I can remember or that has a meaning.

Workaround: Put an entry in your hosts/lmhosts file (in the c:\windows\system32\drivers\etc folder), or if you have access to the DNS or WINS server, put the entry there, using your preferred name and the IP of the server you want to reach. If, for instance, a server is named something like SA823SX3B and you want to name it FILESERVER, just put in an entry for FILESERVER with the SA823SX3B's IP. It works for ping and many other services, but:

Problem: This does (by default) NOT work if you want to connect to a NetBIOS fileshare. You can verify that firewalls etc. is not the cause of this problem by connecting via \\SA823SX3B\fileshare and even by using \\192.168.0.1\fileshare (given that that's the IP of our example server).

Solution: You need to hack the following registry key on the server in question:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\
DisableStrictNameChecking

Set the value to 1 and reboot. You can now connect to the server using any name you please, as long as it is referring to the right IP address.

Caveat: On a NT4 computer, you will still not be able to connect without using either the real name or the IP address as reference.

See Microsoft KB 281308 for a description of this parameter.

Thursday, August 23, 2007

eBay thumbs - Always with Greasemonkey!

Not very technical this time, but definitely nerdy

Ever been annoyed by eBay ads with only the green camera icon on the item list page? eBay charges extra to let sellers display a thumb aside the item title, so obviously many eBay sellers only put images inside their ads - showing up after you click to view the ad.

With Greasemonkey and the Firefox web browser, the world in this respect looks a bit brighter. Greasemonkey is a client-side scripting engine addon to Firefox that processes web pages that you view in realtime.

Add this script to Greasemonkey and you get thumbs on all eBay ads that have images!

Thursday, August 16, 2007

WinMed Connect preferences & setup

Situation: A client computer that were running the WinMed healthcare software application had been replaced and an attempt had been made to transfer the software to the new computer. The WinMed program and data files all reside on a server network share with no values stored in registry, so apparently recreating the shortcuts to the server located apps on the new computer should do the trick.

Problem: The WinMed Connect program was asking for path specifications every time it was run.

Solution: The WinMed Connect shortcut points to a program called xmlparse.exe in the xml subfolder of the WinMed system files. There was also a xmlparse.ini file in this folder. This needed to be copied to the Windows folder and modified with the right paths. Also the winmed.ini file located in the WinMed folder on the server had to be copied to the local Windows folder. Both files had to be given change permissions to the user who was running the program.

Monday, August 13, 2007

Which Default Gateway is default?

This is kind of a lightweight post, but still nice to know:

Scenario: I wanted to configure a new VPN device using my laptop. The laptop uses wireless to connect to the company LAN and the internet. I would use the wired network interface to connect to the VPN device to configure it.

Problem: Once the VPN device is connected to the wired interface, all traffic destined for the internet insists on being routed through the wired, not the wireless connection. That's a problem when the wireless interface is on the subnet where internet can be reached.

Dead end: I tried to go to Control panel-Network connections, selecting Advanced-Advanced settings from the menu, to set the wireless interface on top of the "connections" list. This did not work - it would only have worked for network services like file sharing etc..

Clue: Using the command-prompt command "route print" (listing the current routing table of the computer), I can see that the computer has chosen the default gateway (given over DHCP by the VPN device) on the wired interface as default. The default gateway given by the company LAN DHCP server over the wireless interface has a higher metric (30) than the wired interface gateway route (20). Result: Wired interface default gateway becomes the computer's first choice of gateway.

Reason: So I need a way to change the metric of the default gateway defined on the wireless network interface. On Microsoft Knowledge Base, I found article no. 315088. It explains that Windows assigns metrics based on the connection speed. That's normally fine, but it did not tell me how to accomplish what I wanted. The referenced article no. 258487 however does:

Solution: I opened the wireless interface network properties, selected the Internet Protocol and opened its properties, clicked advanced, and manually overrided the Adapter Metric by setting it to 15.

I could set up my VPN device and stay online on the internet while doing it, however I reset the Adapter Metric when I was done. I think Microsoft's assumption that the faster interface should be preferred is generally a good idea, only not in this case!

Sunday, August 12, 2007

MTU too large, communication stalls (under research)

I have been researching this problem for some time now, found a workaround, but no problem reason and no good permanent solution:

Environment and problem: LAN1 is connected to LAN2 via a LINUX PC with two network interfaces, running NAT in both directions. On LAN2, a VPN device has a site-to-site VPN tunnel over the internet to a remote LAN3. When computers on LAN1 tries to talk to computers on LAN3, it works well on some computers, while on others, all comms stalls after a few packets. There are other LANs connected to LAN2 via the same VPN device where the problem never occurs.

Clue: When connecting to LAN2 over a VPN client from a remote location, the communication to LAN3 always works.

Technical details: Using the Ethereal Wireshark network protocol analyzer, a bunch of TCP DUP ACK messages occurs around the time of the freeze.

Workaround: On computers where this is a problem, if the MTU value of the network interface used is modified to 1300 (or 514 hex), the problem goes away. This is done here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ID for Adapter
For a reference on this value, see Microsoft Knowledge Base art. no.
314053.

Potential negative effects of workaround: Smaller MTUs cause more network overhead because smaller and thereby more network packets must be transmitted, all with their own network packet header. In practice though, I could see no negative effect in my case.

Problem cause: Not found. The MTU that should have been used for the overall transfer should have been determined by the lowest MTU given by any router along the path the packets take. My assumption is therefore that some router "out there" is set up with a MTU larger than the network packet size it can actually handle (is this possible?). It works for the first few packets, then the router gets overloaded and freezes.

Permanent solution NOT found: A permanent solution where the MTU value of each client computer is untouched has not been found. Given that my assumption is right, a permanent solution can only be found if the router working under false MTU conditions can be identified and accordingly modified.

Further research: I want to try setting the MTU of the interfaces on the LINUX computer that routes between LAN1 and LAN2 to 1300. If my theory holds, this should lower the overall packet size so that the problem goes away. Since traffic load between the two LANs are never significant, it is acceptible in my case to live with that, even though it does not address the problem at the router that I assume is causing the real problem.

UPDATES ON MY RESEARCH WILL (may) FOLLOW

Saturday, August 11, 2007

Intro

Hello all, just a very brief intro on what you will find on this blog. Contents will be nerdy notes from my nerdy work as a consultant on practically anything that has to do with computers, in addition to the occasional note on technology related hobbies. It is supposed to work as an easily accessible brain dump to get back to the next time I encounter the same problem again. Use it if you like, comment on my posts if you like, but please note that:
  • This blog will NOT be updated regularly
  • This blog will NOT necessarily have technically correct info (it just worked for me)
Enjoy!