Results 1 to 8 of 8

Thread: 30-second Telnet Login Delay?

  1. #1
    Junior Member
    Join Date
    Mar 2017
    Posts
    4

    30-second Telnet Login Delay?

    Hello All...first post to the forum with a curious behavior issue.

    I've been testing command sets for a Caseta Pro2 Bridge through a telnet session from various development PC's. For some reason, every one of them is seeing a precise 30-second delay in the Telnet session before the prompt for "Login" appears.

    I found one other person reporting something similar off of the boards. https://discussions.apple.com/thread/7774694?start=0&tstart=0

    I've tried multiple machines, both on and off the same subnet, both on and off the same switch behind the residential router. The delay is consistent for me regardless of network configuration.

    Is anyone familiar with this? Any way to circumvent the 30-second Telnet authentication delay if I do not want a controlling system to maintain a persistent connection when commands are not being sent?

    Any help would be appreciated, including relocation of this thread if there is a more appropriate location for it.

  2. #2
    Authorized Lutron Contributor
    Join Date
    Jul 2015
    Posts
    111
    Are you doing all these tests over the same network? If you connect directly to the Smart Bridge (no router) does the delay remain? NOTE: static IPs will need to be used in this configuration. What program are you using to send the commands? What happens if you send the commands from a cmd window?

  3. Thanks kallhands thanked for this post
    Likes kallhands liked this post
  4. #3
    Junior Member
    Join Date
    Mar 2017
    Posts
    4
    Tried this in the following configurations, with the same result in each:

    wired (cat6) to common router, same subnet
    wired to common router, different subnet
    wired to common switch behind router, same subnet
    Caseta wired, computers wireless

    I do not have a crossover cat6 to allow cirect PC-to Bridge connection, but will see if I can find the Wifi connection from the bridge.

    Also, if the referenced post is indeed accurate, I don't see how some computers would have the delay and others wouldn't on a common connection method, especially when that telnet prompt would be controlled by the bridge itself.

  5. #4
    Junior Member
    Join Date
    Mar 2017
    Posts
    4
    Update.

    One laptop out of seven, running Windows 10 with the latest patches (as do all of our other systems) just received an instant login response to a Telnet session request from the Bridge. Comparison of registry and system configurations to the other six show no differences on the systems...yet one always gets an instant response and the others don't. This is the case whether using Telnet.exe, Telnet fired from command prompt or when using telnet via PUTTY.

    Since the request for login is sent from/by the Bridge, what configuration settings can be set/checked at the bridge that may alter its response time to a request? As a note, this may also account for some of the 3rd-party control system lags/delays I have found posted on this board while searching for a solution to this problem

  6. #5
    Authorized Lutron Contributor
    Join Date
    Jul 2015
    Posts
    111
    This could be a DNS resolution issue... even when we try the telnet IP address, the server would do DNS reverse lookup and that might take ~30secs. One work around is to add server IP address details in windows hosts file (C:\windows\system32\drivers\etc\hosts)

    This issue would not be specific to our devices. If you do a web search (for "telnet prompt delay"), there are a lot of posts on similar telnet issues on non-Lutron devices.

  7. Thanks kallhands thanked for this post
    Likes kallhands liked this post
  8. #6
    Junior Member
    Join Date
    Mar 2017
    Posts
    4
    Thank for the response, but if we're using Telnet to reach a fixed IP address, how does DNS come into play? I'm continuing my search.

  9. #7
    Junior Member
    Join Date
    Mar 2017
    Posts
    1
    I agree, it may be a DNS issue, but if it is then adding that in your Telnet client's host table will not help as in Linux it is the Telnet server that is trying to do a reverse DNS lookup to validate the client trying to connect to it. To fix this one would have to add the client to the /etc/hosts table of the Linux server and/or adjust the /etc/resolv.conf file. Problem is, we can't do that on the Caseta HUB. Know of any other workarounds?

  10. #8
    Senior Member
    Join Date
    Oct 2013
    Posts
    379
    Quote Originally Posted by kallhands View Post
    One laptop out of seven, running Windows 10 with the latest patches (as do all of our other systems) just received an instant login response to a Telnet session request from the Bridge.
    Then one has to wonder what's different about that particular laptop. When debugging network weirdness I find it best to step back and make sure all the basic settings are configured properly. Start at the router. Make sure it has it's own DNS lookup addresses configured properly. As in, when the router does lookups. Then make sure whatever DHCP service and DNS service you're using on the network are tying into the same DNS database. As in, a client asks for an IP address, the DHCP server then also provides that address and hostname to the DNS server. In many residential setups this is all done by the router. This way any new clients (laptops, etc) on the network will all be pulling from the same DNS server resources.

    DO NOT configure the individual clients to use an outside DNS server. Doing that would prevent them from being able to lookup local IP addresses. An outside DNS server won't have local addresses in it (and would refuse to accept them if offered).

    There's a lot of 'behind the scenes handshaking' that goes on when software wants to connect over hardware to make network connections. Every little bit needs to be configured properly otherwise the errors tend to cascade, making it very hard to debug.

    DO NOT ASSUME any of the current setup is correct. MAKE SURE.

    Then, once you know everything is correct, retry the connections. If the one that WAS working is still working then swap it's IP address with one that isn't. As in, working laptop has 1.2.3.4 and slow-connecting laptop has 1.2.3.5. Change them both to use a static IP address. Change the working one to something unused. Change the slow one to 1.2.3.4 (addresses used as examples, use appropriate ones for the local network which MAY NOT BE 192.168.1.0/24). See if the slow one's performance changes. If so then there's something amiss on the router or other on-site networking hardware.

    When changing IP addresses of clients from DHCP to static it's often useful to also REBOOT the router. This way there won't be any stored ARP lookups on the router that might confuse the hardware MAC addresses between the various devices.

    Telnet is pretty simple. If it's 'slow' then something underpinning how the client is connecting is usually at fault. Break it down. But realize that sometimes it's faster to just punt and set the whole thing back up again from scratch rather than trying to debug it. This can be a risky process if you're not ONE HUNDRED PERCENT savvy with what services are configured for use on the network. As in, any router-based configuration changes for firewalls, outside services, etc.

Similar Threads

  1. 30 sec delay in 10.6
    By MitchE in forum Troubleshooting - RA2
    Replies: 5
    Last Post: 01-08-2017, 10:29 AM
  2. disabling default telnet login
    By Bktay in forum General Discussion - RA2
    Replies: 5
    Last Post: 02-04-2016, 11:54 AM
  3. Main Repeater HTTP login?
    By grork in forum General Discussion - RA2
    Replies: 3
    Last Post: 08-20-2015, 05:53 PM
  4. Nest stuck on login screen
    By RevertAV in forum Troubleshooting - CAS
    Replies: 2
    Last Post: 03-11-2015, 08:48 AM
  5. Mini-PC used for remote login.
    By bloucks in forum General Discussion - HWQS
    Replies: 4
    Last Post: 04-04-2014, 05:21 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •