Hostnames and windows machines

Discussion in 'Tomato Firmware' started by schnappi, Aug 14, 2014.

  1. schnappi

    schnappi Networkin' Nut Member

    Long story short hostnames on network with a Tomato router only work when using Linux systems...

    -When trying to access "bugatti" (windows machine) via RDP or VNC from another Windows machine the connection fails when using the hostname. Using IP works fine. In same way ping fails to hostname but works with IP.

    -When trying to access "bugatti" (windows machine) over a SSH tunnel (basically a linux machine) a hostname works fine. Can also ping bugatti via the server command line using the hostname.

    -Can ping "bugatti" via both hostname and IP from Tomato router interface.

    Does anyone know what it going on? Netbios names are a headache...
  2. koitsu

    koitsu Network Guru Member

    In order of issues:

    1. NetBIOS probably isn't involved here, instead the Windows systems are doing DNS lookups and failing. More on that in a moment.

    2. Description makes no sense; cannot just say "over a SSH tunnel (basically a Linux machine)". This topology/explanation makes no sense. Same with "Can also ping bugatti via the server command line" -- what server? This is beyond confusing. (Note: I am very familiar with SSH port forwarding and the like)

    3. Understandable. The /etc/resolv.conf on Tomato routers usually has in it, using dnsmasq, so that's that.

    So there are multiple things at play here. First and foremost: stop thinking about NetBIOS. Throw that thing on the floor. Focus just on DNS.

    First and foremost is the issue of what "domain" your Windows machines are part of. I am not talking about the "Windows Domain", I am talking about the DNS domain (suffix) that is associated with the clients. This is usually provided by the DHCP server when the client requests an IP and they negotiate information. Common examples are home.lan or lan or other such things. I recommend two words (ex. home.lan, my.home, etc.) and ones using a TLD that does not conflict with real-world things (i.e. please don't go with

    If I remember right, the domain portion used by dnsmasq and the Tomato router itself come from Basic / Identification. Router name is just a label for your router (mine is tomato), Hostname is the actual shorthand name of your router (I call mine "gw"), and Domain name is the actual DNS domain name you want to use (mine is home.lan).

    Now the second part is what you're using for a DNS server for your LAN clients. You need to be using an IP address of the router itself so that you're sending these DNS requests to dnsmasq. If you've got custom DNS set up on your clients that don't hit dnsmasq, then they're not going to be able to resolve your "LAN" names under whatever domain suffix you pick. Instead those lookups go out onto the Internet and naturally fail.

    The third part is knowing whether or not your DHCP clients are submitting hostnames when using DHCP. (Yes, the client can tell the server "Hey, my name is bigfatsnake" and dnsmasq will register that internally/track it so that lookups for "bigfatsnake" go back to that IP).

    Let's start there and see what your responses are.

    I should note however: I do not use dnsmasq myself. I actually run two nameservers on my LAN: a full BIND (named) instance running on a FreeBSD box, and also on my Tomato router as a secondary (slaving home.lan and zones from the FreeBSD box). Both servers are listed in my DNS server config for DHCP -- that way if I reboot my FreeBSD box or do work on it, machines on the local network can still resolve things like "somebox" or "gw" or "gw.home.lan" successfully. (For many years I just ran with the FreeBSD box, but Entware providing a BIND package caused me to set all that up on Tomato as a slave). For a DHCP server I run ISC DHCPD on my FreeBSD box (I simply prefer it is all), and I configure the DNS suffix in DHCP to be home.lan (for obvious reasons). ISC DHCPD and BIND/named have absolutely no relation to one another (unlike dnsmasq which does the job of both but in a single daemon), but what I have works just fine. The only thing I don't have fixed/working is the router able to talk to the shortnames of either box, and that has to do with some resolv.conf "search" bits I haven't set up yet -- but FQDNs (ex. icarus.home.lan) work fine. I don't particularly care that the router can't use shortnames though.

    Some evidence of my claims and my setup:

    koitsu -- -- Windows XP Pro SP3 workstation
    icarus -- -- FreeBSD 9.3-STABLE box running BIND named and ISC DHCPD (server). IP of this box is statically configured
    gw -- -- Tomato router (Asus RT-N66U running Toastman and Entware)

    C:\>ipconfig /all
    Windows IP Configuration
            Host Name . . . . . . . . . . . . : koitsu
            Primary Dns Suffix  . . . . . . . :
            Node Type . . . . . . . . . . . . : Unknown
            IP Routing Enabled. . . . . . . . : No
            WINS Proxy Enabled. . . . . . . . : No
            DNS Suffix Search List. . . . . . : home.lan
    Ethernet adapter Local Area Connection:
            Connection-specific DNS Suffix  . : home.lan
            Description . . . . . . . . . . . : Qualcomm Atheros AR8161/8165 PCI-E Gigabit Ethernet Controller
            Physical Address. . . . . . . . . : 90-2B-34-57-E8-93
            Dhcp Enabled. . . . . . . . . . . : Yes
            Autoconfiguration Enabled . . . . : Yes
            IP Address. . . . . . . . . . . . :
            Subnet Mask . . . . . . . . . . . :
            Default Gateway . . . . . . . . . :
            DHCP Server . . . . . . . . . . . :
            DNS Servers . . . . . . . . . . . :
            Lease Obtained. . . . . . . . . . : Monday, August 11, 2014 18:01:53
            Lease Expires . . . . . . . . . . : Monday, August 18, 2014 18:01:53
    C:\>ping icarus
    Pinging icarus.home.lan [] with 32 bytes of data:
    Reply from bytes=32 time<1ms TTL=64
    Reply from bytes=32 time<1ms TTL=64
    Reply from bytes=32 time<1ms TTL=64
    icarus$ cat /etc/resolv.conf
    search home.lan
    icarus$ ping koitsu
    PING koitsu.home.lan ( 56 data bytes
    64 bytes from icmp_seq=0 ttl=64 time=0.152 ms
    64 bytes from icmp_seq=1 ttl=64 time=0.174 ms
    64 bytes from icmp_seq=2 ttl=64 time=0.117 ms
    icarus$ telnet gw
    Connected to gw.home.lan.
    Escape character is '^]'.
    gw login: root
    Tomato v1.28.0505 MIPSR2Toastman-RT-N K26 USB Ext
    root@gw:/tmp/home/root# cat /etc/resolv.conf
    root@gw:/tmp/home/root# ping icarus
    ping: bad address 'icarus'
    root@gw:/tmp/home/root# ping koitsu
    ping: bad address 'koitsu'
    root@gw:/tmp/home/root# ping icarus.home.lan
    PING icarus.home.lan ( 56 data bytes
    64 bytes from seq=0 ttl=64 time=0.417 ms
    64 bytes from seq=1 ttl=64 time=0.364 ms
    As for the router not being able to resolve shortnames, as I mentioned it has to do with a missing "search home.lan" line in /etc/resolv.conf. That's a "quirk/bug" in TomatoUSB, by the way. Proof:

    root@gw:/tmp/home/root# cat /etc/resolv.conf
    root@gw:/tmp/home/root# echo 'search home.lan' >> /etc/resolv.conf
    root@gw:/tmp/home/root# ping koitsu
    PING koitsu ( 56 data bytes
    64 bytes from seq=0 ttl=64 time=0.283 ms
    64 bytes from seq=1 ttl=64 time=0.262 ms
    --- koitsu ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max = 0.262/0.272/0.283 ms
    root@gw:/tmp/home/root# nvram show | grep _domain
    Note the lan_domain field being empty, and the wan_domain field matching what's in the TomatoGUI for "Domain name". Yeah... that really needs to be re-worked. Possibly I could just do nvram set lan_domain=home.lan && nvram commit and then reboot and maybe there's some logic to put a search/domain line in /etc/resolv.conf from that, but I dunno. It's still a quirk/bug as I see it. I really need to look at the code to figure out what all is going on with those NVRAM variables + how they're used in reference to things.
  3. schnappi

    schnappi Networkin' Nut Member

    "bugatti" sees the incoming RDP connection request coming from the SSH server itself, not actual machine you are sitting at using the SSH tunnel.

    Make sense?

    Thanks as well for response.

    You are a genius. Adding a entry (the-lan-is-strong.with-this-one) under identification in identification solved the issue (after flushing dns).
    Last edited: Aug 14, 2014
  4. koitsu

    koitsu Network Guru Member

    Not really. There are two kinds of SSH port forwardings -- local and remote. I think what you're describing is a local SSH port forward, which would work as follows:

    SSH client sets up a port forward of --> SSH client is run from a machine with an IP address of, and connects to an SSH server with an IP address of We assume the SSH server can actually reach on TCP port 443.

    This allows software the machine running the SSH client to connect to TCP port 7890, which gets tunnelled through the SSH connection, through the server, and over to TCP port 443. The system sees the connection coming from whatever the address of the SSH server is (in that case it would probably have its own local IP within 10/8, such as, but it's all transparent to the client.

    A "remote" forward works the opposite way, where instead of the listening port being done on the SSH client, it's done on the SSH server (and thus forwards back to the client). It's basically like a "local" forward but in reverse, to allow a SSH server or system to access a local resource on the client.

    You don't have to use IP addresses in your SSH forwards either -- you can use FQDNs or even short names. For example, in the first example I gave, replace with ilikerice:443. What happens is that the SSH server does the DNS resolution of ilikerice (hope it resolves!) and then connects to whatever that resolves to on TCP port 443. People often forget this fact; they think "shouldn't the SSH client be doing the resolution of ilikerice?" (no, the server does it).

    My main point of confusion is this: why is SSH port forwarding being used / mentioned at all in this case, when the issue in question relates entirely to machines on your local LAN segment? Are you actually doing SSH forwarding between LAN machines due to subnet segregation / VLANs or what?
    Last edited: Aug 14, 2014
  5. schnappi

    schnappi Networkin' Nut Member

    Was (doing a poor job) of describing local port forwarding. The gist of local port forwarding is that the SSH server accesses the resource that forwards/tunnels it to the computer initiating the SSH session. So we understand each other, enough said.

    Thank you again very much as your original post resolved my issue! Don't really care for internet forums...but this one is absolutely awesome! Very intelligent (a better word may be knowledgeable!) people here.

    When accessing "bugatti" via RDP on the lan previously (before fixing the issue with your help) had to use an IP to RDP in. Hoever am out of town alot...and prefer a SSH tunnel to a VPN (so can use one browser for stuff that don't care about the hotel seeing at at a lot faster speed). At the same time use the SSH tunnel to secure a RDP session to "bugatti" and secure browsing on a different browser. So to answer your question when am out of town was able to use a hostname when accessing "bugatti" via RDP...but had to use a IP to access "bugatti" via RDP when at home (which is not very much). But it still was bothering me enough to try and figure it out.

    Make sense this time?
  6. koitsu

    koitsu Network Guru Member

    I think what you're describing is: you want to be able to access one of your Windows machines on your LAN, but across the Internet, and you understandbly don't want to leave a port forward open (for WANIP:3389 --> bugatti:3389 -- or even some other port on WANIP). So instead you opted for an SSH port forward like so:

    SSH client IP: (some Internet IP, doesn't matter)
    router WAN IP: (some Internet IP, doesn't matter)
    router LAN IP:
    bugatti IP:
    SSH client configured to tunnel TCP port 4567 ( to
    SSH client connects to (or some other port where sshd/dropbear is listening, doesn't matter), and once connected, you're able to visit in your local MSTSC/RD client and reach the bugatti workstation.

    (You could also configure the SSH client to tunnel TCP port 4567 ( to bugatti:3389 (really!) because the server (router) is what would do the DNS resolution of "bugatti")

    If my topology description is correct, then yes, that's an SSH local forward. Most people use that when trying to access TCP-based resources that's on a private network or behind NAT and don't like the complexity of a VPN (that includes me! I only use VPNs when I have two networks to bridge together across a WAN link, or when UDP or ICMP protocols are needed).
  7. schnappi

    schnappi Networkin' Nut Member

    I *think* we are on the same page but just to be sure...

    -The first shows how had to login to "bugatti" while on LAN
    -Second and third shows how was able to login to "bugatti" through a SSH tunnel

    Of course you helped so that now can login using a hostname while on the LAN...



  8. koitsu

    koitsu Network Guru Member

    Yup, we're on the same page. What's shown in the 2nd screenshot in PuTTY/KiTTY means define a local SSH forward/tunnel to bugatti (whatever that resolves to on the SSH server side) TCP port 3389, bound to (a.k.a. localhost) TCP port 3389. I think you and I just have different ways of describing the same thing, but yep, correct :)
  9. schnappi

    schnappi Networkin' Nut Member

    Does giving a Tomto router a top level domain cause issues (mainly can't resolve top level domain of the same name on the internet without manually adding local zone records) similar to doing the same thing with an active directory server?

    Assume not since Tomato doesn't do its own external DNS like an active directory server.

    Additionally has anyone given a Tomato router the same top level domain as an active directory server on the same network?
    Last edited: Feb 26, 2015
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice