1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Remote Desktop name resolution difficulty w/ latest Tomato

Discussion in 'Tomato Firmware' started by bigclaw, Apr 24, 2008.

  1. bigclaw

    bigclaw Network Guru Member

    Disclaimer: I don't have any conclusive evidence that the latest Tomato firmware has anything to do with the difficulty, but I have otherwise not changed any network or machine configurations other than upgrading to new Tomato firmware. It used to work with 1.15 or 1.17, I believe.

    Symptoms: I no longer have the ability to remote-desktop using the Windows computer name. I must use either the IP or host name (specified through static DHCP). My understanding is that RDP uses (DNS?) name resolution to find the machine.

    Setup: both the client and the server in this case are home PCs and have Vista w/ SP1 and in the same workgroup. The server has the following settings:

    Windows machine name: PC1
    IP: 192.168.1.111 (specified in static DHCP)
    hostname: pc1.lan (specified static DHCP)

    I used to be able to connect to PC1, but now I have to use either the IP or the hostname.

    I am using the router as a DNS forwarder.

    Finally, I guess I can temporarily flash back to 1.15 to see whether it's Tomato or not. However, I'm less tempted to do so because of the available workaround. I'm posting this just to see if anybody happens to know what's going on. :)
     
  2. HennieM

    HennieM Network Guru Member

    The RDP in WinXP does use the DNS system to resolve the IP it needs to connect to. I would think that Vista (which uses a higher version RDP than XP), would do the same.

    At the risk of stating the obvious, resolving an IP address generally goes like this:

    It's all about what the PC that you are working on does and knows, and has nothing to do with the PC you are connecting to. Say you are on PCA and you try to connect to-, ping-, PCB.

    You type
    ping PCB

    PCA now sees if it has an IP address for the term "PCB", in its host file. Not found.

    PCA MAY now ask the DNS server to resolve PCB before it does the steps below. If the DNS server has a fully qualified domain name (FQDN) PCB, it wil resolve. Most likely however, the DNS server will not have a FQDN without a dot.

    Now PCA looks at what domain names it knows. If PCA's FQDN is PCA.lan, it will now try to find PCB.lan in its host file. Not found.

    PCA now asks the DNS server to resolve PCB.lan. DNS server says not found.

    PCA now checks any other domain names to be searched:
    Say you specifed domains to be searched as net, net.lan, my.net.lan. PCA now asks the DNS server to resolve
    PCB.net
    PCB.net.lan
    PCB.my.net.lan

    Point I'm trying to make is that the DNS server, when it receives a query for "PCB", will not try to resolve PCB.something, but only PCB. Similarly if DNS gets PCB.lan to resolve, it will not find just PCB, or PCB.net.lan, but just PCB.lan; the PC you are working on must do the FQDN manipulation and send FQDN queries to the DNS server.

    Therefore, I'd suggest you do, in a DOS box, ipconfig -all, and see what domain names your PC has, and wil search. If "lan" is not on PCA's domain list, it will not find PCB.lan. If not, it may be that the upgraded Tomato assigns your PC's FQDN differently than before, or something like that, as I doubt that the working of the DNS server will be different.
     
  3. bigclaw

    bigclaw Network Guru Member

    I think you are correct in all that you said. I'll try what you suggested tonight.

    Let me see if I can describe my problem in simpler terms:

    PC1's Windows computer name is PC1 (Control Panel->System->Computer Name). Its hostname is pc1.lan (Tomato static DHCP). Its IP is 192.168.1.111.

    Before: I can remote-desktop using PC1.
    Now: I can only remote-desktop to pc1.lan or 192.168.1.111. I can no longer use PC1.
    What's changed: nothing except Tomato firmware upgrades (at least this is what I think.)

    So at this point, I'm just curious as to what's changed. It seems that my network's DNS no longer is able to resolve PC1. (Again, I'm not saying it's Tomato yet.)
     
  4. TexasFlood

    TexasFlood Network Guru Member

    I just tried to see if this would work on my network. I attached a diagram of my network as it sits today. I tried accessing PC1 via RDP from PC2 and PC3 (all running Windows XP). Sure enough, it wasn't working using the PC's name. Then I just tried pinging it and that didn't work either, as it couldn't find the host. However the same tests worked when accessing PC2 from PC3 via RDP. So I started checking the configuration of PC1 and found that the Symantec firewall had somehow dropped my LAN subnet from the trusted networks list therefore the netbios traffic was getting blocked. After adding it back in now everything works as it should. Not sure if you might have the same issue but that's what worked for me.
     

    Attached Files:

  5. bigclaw

    bigclaw Network Guru Member

    Thanks for testing this! Very interesting findings. I'm not using anything other than Windows firewall; I'll see if anything can be done there. However, in my case, PC1 is not resolving, not simply rejecting netbios traffic.

    Also, it seems that you are not using Tomato as your DHCP/DNS box, right? That means Tomato is not even involved in most of the work in your case?
     
  6. bigclaw

    bigclaw Network Guru Member

    Ha. It's working again. I can now connect using 'PC1'. Thanks for the help guys.

    The explanation is kind of convoluted. I won't litter the board unless somebody's interested. :)
     
  7. TexasFlood

    TexasFlood Network Guru Member

    Yes, my gateway router runs Tomato and provides DHCP & DNS. PC1 does hang off this router via a wired connection. My routers used to all run Tomato and I might go back to that setup soon but wasn't up to switching that router back for this test.

    I figured if the name is not resolving the name via the host file, DNS or WINS then it must be doing it via Netbios. In that case if the PC started rejecting Netbios then this woiuld cause the name to not resolve. Do I have that wrong?
     
  8. TexasFlood

    TexasFlood Network Guru Member

    I'm interested, :-D I might learn something.
     
  9. bigclaw

    bigclaw Network Guru Member

    OK. Let me see if I can explain this clearly. :) After one of my firmware upgrades, at one point I remember one of the domain/host name fields on Tomato actually got filled with "launchmodem.com" or something to that effect. (I think launchmodem.com is used by my Westell 6100 DSL modem to launch the config page, maybe.) By that time, my primary PC had already obtained its settings from the router (DHCP, etc). The end result is that the Connection-specific DNS Suffix on my primary PC became "launchmodem.com".

    Subsequently, I removed the "launchmodem.com" entry from the router, but the Connection-specific DNS Suffix on my primary PC never got updated.

    Later on, when I tried to connect to PC1 (server) from my primary PC, because of the suffix, it tried to resolve PC1.launchmodem.com, instead of just PC1. Of course, it couldn't resolve that.

    The solution is quite simple. I just did an "ipconfig /release" and "/renew" cycle, which finally got rid of the offending DNS suffix from my primary PC. Apparently the daily DHCP expiration/renewal is not enough to refresh this setting.

    All is well now.

    Does the above make sense? :confused:
     
  10. TexasFlood

    TexasFlood Network Guru Member

    It does and I have had very similar issues related to not recognizing that DHCP isn't automatically updated to reflect changes in the server config.

    The only question I have after testing is...
    On my network, the unqualified short name "PC1" will not resolve through DNS although it does through netbios. If I try to resolve it through DNS using nslookup, I have to use PC1.{domain} for a successful lookup and have to incluide the dot even if if there is no domain. I tried this hooked up to tomato only routers with dd-wrt out of the mix to make sure that wasn't a factor and got the same results.

    The Tomato FAQ states: "Names that have a dot, like "foo.lan", are treated as regular domain names. Undotted names like "foo" use the router's domain name. The hostnames should work on all computers connected to the LAN as long as the router's DNS forwarder is used (the default setting). They will not work from the Internet side."

    I'm seeing -almost- that behavior except my undotted names seem to still need the dot even if there is no domain. Weird, hmm, is it just me? Not that important I guess, just curious.
     
  11. HennieM

    HennieM Network Guru Member

    @TexasFlood: Thinking out loud here - if your router does not have domain assigned, it's entries in the DNS table all gets assigned as name. (name-dot), which is the fully qualified domain name AND short name as far as dnsmasq is concerned; i.e. the "name." IS the short name.

    The NetBIOS name scheme does not work with domains at all, and the tracking of these names are done by one of the PCs (the elected master browser) on your net. So, if your RDP or whatever client tries to resolve "name" by NetBIOS, it should succeed.
     
  12. TexasFlood

    TexasFlood Network Guru Member

    I guess so. Truth is this doesn't really bother me much, just wondering why the behavior seems to differ from what is stated here in the Tomato FAQ.

    Amd I believe it does work resolving the name via netbios, was just using nslookup to try and separate out the DNS behavior.

    Anyway as I said, no big deal just curious. Thanks for the input.
     

Share This Page