I've been learning about socket programming recently, and am just beginning learning about tcp/ip sockets. My study material gives an example of connecting to the localhost daytime service by running telnet 13 with the expected result that a telnet session should be opened. I have an entry for "daytime 13/tcp" in my /etc/services file, and I have the xinetd service running, but when I try the telnet command, I immediately get "Connection refused".

Q: why doesn't telnetting to the daytime service work?

Q: are there other localhost services that would accept a telnet connection? I tried to telnet to a random selection of services that had tcp entries in /etc/services, but all of them gave the same "Connection refused" error.

My short-term goal is just to replicate my study material's successful telnet connection to a localhost tcp service - if not inetd, then anything else; I just want to learn by practice.

>telnet 13
telnet: connect to address Connection refused
>telnet 49000
telnet: connect to address Connection refused
>telnet 9009
telnet: connect to address Connection refused
>uname -a
Linux linuxbox 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  • If you can't telnet locally to the specified ports such as 13, 49000, etc. that only means the ports aren't open in iptables.. – ryekayo Jun 13 '17 at 17:40
  • 1
    @ryekayo Well, and also no service is running on those ports. – mattdm Jun 18 '17 at 11:15
  • Yes, forgot to mention that as well :-) – ryekayo Jun 19 '17 at 12:13

The /etc/services does not indicate what services are actually running. See purpose of /etc/services. You will need to find a service that is running (or start one). You can see what is listening by looking at netstat -nlt. The particular services will vary, but you will see something like:

$ netstat -nlt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0   *               LISTEN
tcp        0      0*               LISTEN
tcp        0      0    *               LISTEN
tcp        0      0 *               LISTEN
tcp        0      0  *               LISTEN
tcp6       0      0 :::3306                 :::*                    LISTEN
tcp6       0      0 :::111                  :::*                    LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 ::1:631                 :::*                    LISTEN
tcp6       0      0 ::1:25                  :::*                    LISTEN


  1. daytime service is probably not running. If it does not appear in the list (and you can see from the listing above I do not have it running), then nothing is listening on the port. It may be possible to start the service if it is installed.
  2. There are lots of other potential services depending upon what is installed and active. In the listing above, port 25 is listening, which is the mail service. So I could connect via telnet to port 25. As telnet is not installed by default, I use nc to connect, but the principle is the same:

    $ nc 25 220 centos7.feedthecoder.com ESMTP Postfix HELO me.theworld.com ...

Edit: as mentioned in a comment, it could of course be a firewall issue. Generally installations do not block, but it is always a possibility.

Also, depending upon your distribution, daytime may not be installed, which would be a further impediment. If it is installed, you should be able to start it via the normal service start (e.g., service start daytime, or the distro equivalent).

Edit: it turns out that daytime is provided solely by xinetd as an internal service. So while the information above about listing services is correct, to have daytime, ensure that xinetd is installed, and that the file /etc/xinetd/daytime-stream has disabled set to no.

  • Confirming: I could reproduce your examples, and was able to telnet 25. You are correct: daytime appears to not be running. There's some relationship between inetd and daytime I don't fully understand yet. I thought because the former was running meant the latter was as well. But I guess that's a separate question to follow shortly. :) – StoneThrow Jun 13 '17 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.