Telnet connection had been closed by a foreign host

The client PC IP: 10.49.46.5/24 and the server PC IP: 10.49.46.2/24 are two computers linked to the same network.
When I try to create an interactive communication between these two computers using the command telnet, I get the following:

[root@xxx:~]# telnet 10.49.46.2

Trying 10.49.46.2...

Connected to 10.49.46.2.

Escape character is '^]'.



Connection closed by foreign host.

[root@xxx:~]#

The server xinetd.conf are as follows:

    defaults

    {

            instances               = 60

            log_type                = SYSLOG authpriv

            log_on_success          = HOST PID EXIT

            log_on_failure          = HOST ATTEMPT

            cps                     = 25 30

    }

includedir /etc/xinetd.d

The server telnet.config are as follows:

service telnet

{

        flags           = REUSE

        socket_type     = stream

        wait            = no

        user            = root

        server          = /usr/sbin/telnetd

        log_on_failure  += USERID

        instances       = 10

        disable         = no

}

The TCPWrapper hosts.allow are:

telnetd: /etc/telnetd.hosts

tfdpd: /etc/tftpd.hosts

sshd: /etc/sshd.hosts

The TCPWrapper hosts.deny are:

ALL:ALL

NOW:

I checked ssh and it is running on port 22.

I checked /var/log/message and had found that the command xinetd starts and then exits the telnet immediately.

I checked that iptables do not drop telnet package using the command: iptables -L

Would you please help me figure out what is the problem and how can I fix it?

edited Sep 3 at 16:24

Jeff Schaller

38.5k1053125

asked Sep 23 '17 at 8:12

Yuri

6113

bumped to the homepage by Community♦ 14 hours ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

What's listening on the server side?
– Kusalananda
Sep 23 '17 at 8:39

At a guess, the default timeout on the remote server (say a webserver) was hit and the connection was disconnected. Copy your list of commands (or at least the initial connection command) to the clipboard and paste them as soon as the connection is established.
– Tigger
Sep 23 '17 at 9:13

@Tigger I updated my question
– Yuri
Sep 23 '17 at 9:35

add a comment |

[root@xxx:~]# telnet 10.49.46.2

Trying 10.49.46.2...

Connected to 10.49.46.2.

Escape character is '^]'.



Connection closed by foreign host.

[root@xxx:~]#

The server xinetd.conf are as follows:

    defaults

    {

            instances               = 60

            log_type                = SYSLOG authpriv

            log_on_success          = HOST PID EXIT

            log_on_failure          = HOST ATTEMPT

            cps                     = 25 30

    }

includedir /etc/xinetd.d

The server telnet.config are as follows:

service telnet

{

        flags           = REUSE

        socket_type     = stream

        wait            = no

        user            = root

        server          = /usr/sbin/telnetd

        log_on_failure  += USERID

        instances       = 10

        disable         = no

}

The TCPWrapper hosts.allow are:

telnetd: /etc/telnetd.hosts

tfdpd: /etc/tftpd.hosts

sshd: /etc/sshd.hosts

The TCPWrapper hosts.deny are:

ALL:ALL

NOW:

I checked ssh and it is running on port 22.

I checked /var/log/message and had found that the command xinetd starts and then exits the telnet immediately.

I checked that iptables do not drop telnet package using the command: iptables -L

Would you please help me figure out what is the problem and how can I fix it?

edited Sep 3 at 16:24

Jeff Schaller

38.5k1053125

asked Sep 23 '17 at 8:12

Yuri

6113

bumped to the homepage by Community♦ 14 hours ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

What's listening on the server side?
– Kusalananda
Sep 23 '17 at 8:39

At a guess, the default timeout on the remote server (say a webserver) was hit and the connection was disconnected. Copy your list of commands (or at least the initial connection command) to the clipboard and paste them as soon as the connection is established.
– Tigger
Sep 23 '17 at 9:13

@Tigger I updated my question
– Yuri
Sep 23 '17 at 9:35

add a comment |

[root@xxx:~]# telnet 10.49.46.2

Trying 10.49.46.2...

Connected to 10.49.46.2.

Escape character is '^]'.



Connection closed by foreign host.

[root@xxx:~]#

The server xinetd.conf are as follows:

    defaults

    {

            instances               = 60

            log_type                = SYSLOG authpriv

            log_on_success          = HOST PID EXIT

            log_on_failure          = HOST ATTEMPT

            cps                     = 25 30

    }

includedir /etc/xinetd.d

The server telnet.config are as follows:

service telnet

{

        flags           = REUSE

        socket_type     = stream

        wait            = no

        user            = root

        server          = /usr/sbin/telnetd

        log_on_failure  += USERID

        instances       = 10

        disable         = no

}

The TCPWrapper hosts.allow are:

telnetd: /etc/telnetd.hosts

tfdpd: /etc/tftpd.hosts

sshd: /etc/sshd.hosts

The TCPWrapper hosts.deny are:

ALL:ALL

NOW:

I checked ssh and it is running on port 22.

I checked /var/log/message and had found that the command xinetd starts and then exits the telnet immediately.

I checked that iptables do not drop telnet package using the command: iptables -L

Would you please help me figure out what is the problem and how can I fix it?

edited Sep 3 at 16:24

Jeff Schaller

38.5k1053125

asked Sep 23 '17 at 8:12

Yuri

6113

[root@xxx:~]# telnet 10.49.46.2

Trying 10.49.46.2...

Connected to 10.49.46.2.

Escape character is '^]'.



Connection closed by foreign host.

[root@xxx:~]#

The server xinetd.conf are as follows:

    defaults

    {

            instances               = 60

            log_type                = SYSLOG authpriv

            log_on_success          = HOST PID EXIT

            log_on_failure          = HOST ATTEMPT

            cps                     = 25 30

    }

includedir /etc/xinetd.d

The server telnet.config are as follows:

service telnet

{

        flags           = REUSE

        socket_type     = stream

        wait            = no

        user            = root

        server          = /usr/sbin/telnetd

        log_on_failure  += USERID

        instances       = 10

        disable         = no

}

The TCPWrapper hosts.allow are:

telnetd: /etc/telnetd.hosts

tfdpd: /etc/tftpd.hosts

sshd: /etc/sshd.hosts

The TCPWrapper hosts.deny are:

ALL:ALL

NOW:

I checked ssh and it is running on port 22.

I checked /var/log/message and had found that the command xinetd starts and then exits the telnet immediately.

I checked that iptables do not drop telnet package using the command: iptables -L

Would you please help me figure out what is the problem and how can I fix it?

linux telnet xinetd tcp-wrappers

edited Sep 3 at 16:24

Jeff Schaller

38.5k1053125

asked Sep 23 '17 at 8:12

Yuri

6113

edited Sep 3 at 16:24

Jeff Schaller

38.5k1053125

asked Sep 23 '17 at 8:12

Yuri

6113

edited Sep 3 at 16:24

Jeff Schaller

38.5k1053125

edited Sep 3 at 16:24

Jeff Schaller

38.5k1053125

edited Sep 3 at 16:24

Jeff Schaller

38.5k1053125

asked Sep 23 '17 at 8:12

Yuri

6113

asked Sep 23 '17 at 8:12

Yuri

6113

asked Sep 23 '17 at 8:12

Yuri

6113

bumped to the homepage by Community♦ 14 hours ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

bumped to the homepage by Community♦ 14 hours ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

What's listening on the server side?
– Kusalananda
Sep 23 '17 at 8:39

At a guess, the default timeout on the remote server (say a webserver) was hit and the connection was disconnected. Copy your list of commands (or at least the initial connection command) to the clipboard and paste them as soon as the connection is established.
– Tigger
Sep 23 '17 at 9:13

@Tigger I updated my question
– Yuri
Sep 23 '17 at 9:35

add a comment |

What's listening on the server side?
– Kusalananda
Sep 23 '17 at 8:39

At a guess, the default timeout on the remote server (say a webserver) was hit and the connection was disconnected. Copy your list of commands (or at least the initial connection command) to the clipboard and paste them as soon as the connection is established.
– Tigger
Sep 23 '17 at 9:13

@Tigger I updated my question
– Yuri
Sep 23 '17 at 9:35

What's listening on the server side?
– Kusalananda
Sep 23 '17 at 8:39

At a guess, the default timeout on the remote server (say a webserver) was hit and the connection was disconnected. Copy your list of commands (or at least the initial connection command) to the clipboard and paste them as soon as the connection is established.
– Tigger
Sep 23 '17 at 9:13

@Tigger I updated my question
– Yuri
Sep 23 '17 at 9:35

add a comment |

2 Answers
2

active

oldest

votes

[root@xxx:~]# telnet 10.49.46.2

Trying 10.49.46.2...

Connected to 10.49.46.2.

Escape character is '^]'.

This means that you have successfully established a TCP connection to the remote daemon. What daemon? The xinetd one which serves as a hub. Now that you are connected, xinetd attempts to launch the specific service (telnet).

Connection closed by foreign host.

This means that launching the telnet service failed. You may want to add debugging options to the telnetd command line and read xinetd logs to see what exactly failed.

You appear to be running the BusyBox version of telnetd. Contrary to classic versions of telnetd, the one provided with Busybox is a standalone daemon which needs a -i option to interface with inetd (services launched by inetd have a specific interface incompatible with a standalone daemon: they must not open and listen to sockets, they must communicate with the client through stdin/stdout).

Your xinetd configuration should thus be:

service telnet

{

        flags           = REUSE

        socket_type     = stream

        wait            = no

        user            = root

        server          = /usr/sbin/telnetd

        server_args     = -i

        log_on_failure  += USERID

        instances       = 10

        disable         = no

}

edited Sep 26 '17 at 22:53

answered Sep 23 '17 at 11:33

xhienne

12k2654

The questioner has been reading logs. What the log said is in the question. The questioner is not launching telnetd as a standalone daemon. That, too, is in the question. The xinetd configuration snippet to launch telnetd is right there, as indeed is the fact that xinetd logged launching it. And the executable could be either telnetd or in.telnetd, neither name implying a standalone daemon. One implies GNU inetutils and other implies BSD telnetd, both launchable via (x)inetd.
– JdeBP
Sep 23 '17 at 12:41

@JdeBP Thanks, that's right that I didn't the OP carefully enough. I tried to address your points by amending my answer.
– xhienne
Sep 25 '17 at 22:27

@xhienne Yes, I use BusyBox v1.25.0.git (checked by busybox | head -1 command) and linux kernel version: 4.0.0-xilinx-00007-g5dab41c-dirty (checked by uname -r command). I changed telnet config file (/etc/xinetd.d/telnet) to add -i option as you mentioned (server = /usr/sbin/telnetd -i) but it had a new issue: Connection refused. I have stopped and started xinetd again but it's not different.
– Yuri
Sep 26 '17 at 2:55

@xhienne I tried with server_args = /usr/sbin/telnetd -i, nothing change :)
– Yuri
Sep 26 '17 at 6:41

@Yuri Connection refused means that the telnet service is not set up (misconfiguration I guess). The telnet port should be open and connection should be accepted, as in you original question. I don't have the Openwrt's xinetd manual at hand. However, the Debian version states "In contrast to inetd, the server name should not be included in server_args". Try with just -i. You may add -l date to the args for your tests: if the telnet daemon writes the date, your configuration is ok.
– xhienne
Sep 26 '17 at 22:57

add a comment |

xhienne makes some good points. The TCP handshake is completing. That the connection is then closed means one of 2 things.

1) The telnetd service is failing when it starts (check your logs)

2) the client you are connecting from is not listed in /etc/telnetd.hosts (check your logs, or rename /etc/hosts.deny temporarily to confirm)

The client IP: 10.49.46.5/24

No, IP host addresses don't have network masks.

And please stop using telnetd. Every time you telnet a kitten cries. (use ssh or telnet-tls)

answered Sep 25 '17 at 21:19

symcbean

2,27911121

The TCP wrappers library is used by inetd, not by telnetd. Why would inetd start telnetd (as reported in the question) if your client is denied access by the /etc/hosts.* files ?
– xhienne
Sep 25 '17 at 22:32

@xhienne: no. TCP wrappers will be used by any daemon compiled against Weistse Venema's socket library, If telnetd is run as a daemon and linked to the library, it will use hosts.all/deny. inetd and xinetd are usually compiled against the library. /etc/hosts does not grant/deny access - its the the data file for file based host name service. The behaviour you describe (connect, then close) is entirely consistent with the behaviour of TCP wrappers. Its also consistent with a badly configured [x]inetd. Instead of arguing, would it be so hard to text?
– symcbean
Sep 25 '17 at 22:46

Not sure what you mean by "to text". If you don't want to argue, just don't elaborate on a /etc/hosts file that I didn't even mention and just answer my one and only question. OP states that xinetd starts telnet and exits immediately. xinetd has no reason to do so if your access is denied.
– xhienne
Sep 25 '17 at 23:47

Sorry typo - not text / test.
– symcbean
Sep 26 '17 at 9:28

"host addresses don't have network masks." they don't, but it's a very convenient useful and appropriate way of signifying the subnet mask.
– roaima
12 hours ago

add a comment |

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f393959%2ftelnet-connection-had-been-closed-by-a-foreign-host%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

[root@xxx:~]# telnet 10.49.46.2

Trying 10.49.46.2...

Connected to 10.49.46.2.

Escape character is '^]'.

Connection closed by foreign host.

This means that launching the telnet service failed. You may want to add debugging options to the telnetd command line and read xinetd logs to see what exactly failed.

Your xinetd configuration should thus be:

service telnet

{

        flags           = REUSE

        socket_type     = stream

        wait            = no

        user            = root

        server          = /usr/sbin/telnetd

        server_args     = -i

        log_on_failure  += USERID

        instances       = 10

        disable         = no

}

edited Sep 26 '17 at 22:53

answered Sep 23 '17 at 11:33

xhienne

12k2654

The questioner has been reading logs. What the log said is in the question. The questioner is not launching telnetd as a standalone daemon. That, too, is in the question. The xinetd configuration snippet to launch telnetd is right there, as indeed is the fact that xinetd logged launching it. And the executable could be either telnetd or in.telnetd, neither name implying a standalone daemon. One implies GNU inetutils and other implies BSD telnetd, both launchable via (x)inetd.
– JdeBP
Sep 23 '17 at 12:41

@JdeBP Thanks, that's right that I didn't the OP carefully enough. I tried to address your points by amending my answer.
– xhienne
Sep 25 '17 at 22:27

@xhienne Yes, I use BusyBox v1.25.0.git (checked by busybox | head -1 command) and linux kernel version: 4.0.0-xilinx-00007-g5dab41c-dirty (checked by uname -r command). I changed telnet config file (/etc/xinetd.d/telnet) to add -i option as you mentioned (server = /usr/sbin/telnetd -i) but it had a new issue: Connection refused. I have stopped and started xinetd again but it's not different.
– Yuri
Sep 26 '17 at 2:55

@xhienne I tried with server_args = /usr/sbin/telnetd -i, nothing change :)
– Yuri
Sep 26 '17 at 6:41

@Yuri Connection refused means that the telnet service is not set up (misconfiguration I guess). The telnet port should be open and connection should be accepted, as in you original question. I don't have the Openwrt's xinetd manual at hand. However, the Debian version states "In contrast to inetd, the server name should not be included in server_args". Try with just -i. You may add -l date to the args for your tests: if the telnet daemon writes the date, your configuration is ok.
– xhienne
Sep 26 '17 at 22:57

add a comment |

[root@xxx:~]# telnet 10.49.46.2

Trying 10.49.46.2...

Connected to 10.49.46.2.

Escape character is '^]'.

Connection closed by foreign host.

This means that launching the telnet service failed. You may want to add debugging options to the telnetd command line and read xinetd logs to see what exactly failed.

Your xinetd configuration should thus be:

service telnet

{

        flags           = REUSE

        socket_type     = stream

        wait            = no

        user            = root

        server          = /usr/sbin/telnetd

        server_args     = -i

        log_on_failure  += USERID

        instances       = 10

        disable         = no

}

edited Sep 26 '17 at 22:53

answered Sep 23 '17 at 11:33

xhienne

12k2654

The questioner has been reading logs. What the log said is in the question. The questioner is not launching telnetd as a standalone daemon. That, too, is in the question. The xinetd configuration snippet to launch telnetd is right there, as indeed is the fact that xinetd logged launching it. And the executable could be either telnetd or in.telnetd, neither name implying a standalone daemon. One implies GNU inetutils and other implies BSD telnetd, both launchable via (x)inetd.
– JdeBP
Sep 23 '17 at 12:41

@JdeBP Thanks, that's right that I didn't the OP carefully enough. I tried to address your points by amending my answer.
– xhienne
Sep 25 '17 at 22:27

@xhienne Yes, I use BusyBox v1.25.0.git (checked by busybox | head -1 command) and linux kernel version: 4.0.0-xilinx-00007-g5dab41c-dirty (checked by uname -r command). I changed telnet config file (/etc/xinetd.d/telnet) to add -i option as you mentioned (server = /usr/sbin/telnetd -i) but it had a new issue: Connection refused. I have stopped and started xinetd again but it's not different.
– Yuri
Sep 26 '17 at 2:55

@xhienne I tried with server_args = /usr/sbin/telnetd -i, nothing change :)
– Yuri
Sep 26 '17 at 6:41

@Yuri Connection refused means that the telnet service is not set up (misconfiguration I guess). The telnet port should be open and connection should be accepted, as in you original question. I don't have the Openwrt's xinetd manual at hand. However, the Debian version states "In contrast to inetd, the server name should not be included in server_args". Try with just -i. You may add -l date to the args for your tests: if the telnet daemon writes the date, your configuration is ok.
– xhienne
Sep 26 '17 at 22:57

add a comment |

[root@xxx:~]# telnet 10.49.46.2

Trying 10.49.46.2...

Connected to 10.49.46.2.

Escape character is '^]'.

Connection closed by foreign host.

This means that launching the telnet service failed. You may want to add debugging options to the telnetd command line and read xinetd logs to see what exactly failed.

Your xinetd configuration should thus be:

service telnet

{

        flags           = REUSE

        socket_type     = stream

        wait            = no

        user            = root

        server          = /usr/sbin/telnetd

        server_args     = -i

        log_on_failure  += USERID

        instances       = 10

        disable         = no

}

edited Sep 26 '17 at 22:53

answered Sep 23 '17 at 11:33

xhienne

12k2654

[root@xxx:~]# telnet 10.49.46.2

Trying 10.49.46.2...

Connected to 10.49.46.2.

Escape character is '^]'.

Connection closed by foreign host.

This means that launching the telnet service failed. You may want to add debugging options to the telnetd command line and read xinetd logs to see what exactly failed.

Your xinetd configuration should thus be:

service telnet

{

        flags           = REUSE

        socket_type     = stream

        wait            = no

        user            = root

        server          = /usr/sbin/telnetd

        server_args     = -i

        log_on_failure  += USERID

        instances       = 10

        disable         = no

}

edited Sep 26 '17 at 22:53

answered Sep 23 '17 at 11:33

xhienne

12k2654

edited Sep 26 '17 at 22:53

answered Sep 23 '17 at 11:33

xhienne

12k2654

answered Sep 23 '17 at 11:33

xhienne

12k2654

answered Sep 23 '17 at 11:33

xhienne

12k2654

The questioner has been reading logs. What the log said is in the question. The questioner is not launching telnetd as a standalone daemon. That, too, is in the question. The xinetd configuration snippet to launch telnetd is right there, as indeed is the fact that xinetd logged launching it. And the executable could be either telnetd or in.telnetd, neither name implying a standalone daemon. One implies GNU inetutils and other implies BSD telnetd, both launchable via (x)inetd.
– JdeBP
Sep 23 '17 at 12:41

@JdeBP Thanks, that's right that I didn't the OP carefully enough. I tried to address your points by amending my answer.
– xhienne
Sep 25 '17 at 22:27

@xhienne Yes, I use BusyBox v1.25.0.git (checked by busybox | head -1 command) and linux kernel version: 4.0.0-xilinx-00007-g5dab41c-dirty (checked by uname -r command). I changed telnet config file (/etc/xinetd.d/telnet) to add -i option as you mentioned (server = /usr/sbin/telnetd -i) but it had a new issue: Connection refused. I have stopped and started xinetd again but it's not different.
– Yuri
Sep 26 '17 at 2:55

@xhienne I tried with server_args = /usr/sbin/telnetd -i, nothing change :)
– Yuri
Sep 26 '17 at 6:41

@Yuri Connection refused means that the telnet service is not set up (misconfiguration I guess). The telnet port should be open and connection should be accepted, as in you original question. I don't have the Openwrt's xinetd manual at hand. However, the Debian version states "In contrast to inetd, the server name should not be included in server_args". Try with just -i. You may add -l date to the args for your tests: if the telnet daemon writes the date, your configuration is ok.
– xhienne
Sep 26 '17 at 22:57

add a comment |

The questioner has been reading logs. What the log said is in the question. The questioner is not launching telnetd as a standalone daemon. That, too, is in the question. The xinetd configuration snippet to launch telnetd is right there, as indeed is the fact that xinetd logged launching it. And the executable could be either telnetd or in.telnetd, neither name implying a standalone daemon. One implies GNU inetutils and other implies BSD telnetd, both launchable via (x)inetd.
– JdeBP
Sep 23 '17 at 12:41

@JdeBP Thanks, that's right that I didn't the OP carefully enough. I tried to address your points by amending my answer.
– xhienne
Sep 25 '17 at 22:27

@xhienne Yes, I use BusyBox v1.25.0.git (checked by busybox | head -1 command) and linux kernel version: 4.0.0-xilinx-00007-g5dab41c-dirty (checked by uname -r command). I changed telnet config file (/etc/xinetd.d/telnet) to add -i option as you mentioned (server = /usr/sbin/telnetd -i) but it had a new issue: Connection refused. I have stopped and started xinetd again but it's not different.
– Yuri
Sep 26 '17 at 2:55

@xhienne I tried with server_args = /usr/sbin/telnetd -i, nothing change :)
– Yuri
Sep 26 '17 at 6:41

@Yuri Connection refused means that the telnet service is not set up (misconfiguration I guess). The telnet port should be open and connection should be accepted, as in you original question. I don't have the Openwrt's xinetd manual at hand. However, the Debian version states "In contrast to inetd, the server name should not be included in server_args". Try with just -i. You may add -l date to the args for your tests: if the telnet daemon writes the date, your configuration is ok.
– xhienne
Sep 26 '17 at 22:57

The questioner has been reading logs. What the log said is in the question. The questioner is not launching telnetd as a standalone daemon. That, too, is in the question. The xinetd configuration snippet to launch telnetd is right there, as indeed is the fact that xinetd logged launching it. And the executable could be either telnetd or in.telnetd, neither name implying a standalone daemon. One implies GNU inetutils and other implies BSD telnetd, both launchable via (x)inetd.
– JdeBP
Sep 23 '17 at 12:41

@JdeBP Thanks, that's right that I didn't the OP carefully enough. I tried to address your points by amending my answer.
– xhienne
Sep 25 '17 at 22:27

@xhienne Yes, I use BusyBox v1.25.0.git (checked by busybox | head -1 command) and linux kernel version: 4.0.0-xilinx-00007-g5dab41c-dirty (checked by uname -r command). I changed telnet config file (/etc/xinetd.d/telnet) to add -i option as you mentioned (server = /usr/sbin/telnetd -i) but it had a new issue: Connection refused. I have stopped and started xinetd again but it's not different.
– Yuri
Sep 26 '17 at 2:55

@xhienne I tried with server_args = /usr/sbin/telnetd -i, nothing change :)
– Yuri
Sep 26 '17 at 6:41

@Yuri Connection refused means that the telnet service is not set up (misconfiguration I guess). The telnet port should be open and connection should be accepted, as in you original question. I don't have the Openwrt's xinetd manual at hand. However, the Debian version states "In contrast to inetd, the server name should not be included in server_args". Try with just -i. You may add -l date to the args for your tests: if the telnet daemon writes the date, your configuration is ok.
– xhienne
Sep 26 '17 at 22:57

add a comment |

xhienne makes some good points. The TCP handshake is completing. That the connection is then closed means one of 2 things.

1) The telnetd service is failing when it starts (check your logs)

2) the client you are connecting from is not listed in /etc/telnetd.hosts (check your logs, or rename /etc/hosts.deny temporarily to confirm)

The client IP: 10.49.46.5/24

No, IP host addresses don't have network masks.

And please stop using telnetd. Every time you telnet a kitten cries. (use ssh or telnet-tls)

answered Sep 25 '17 at 21:19

symcbean

2,27911121

The TCP wrappers library is used by inetd, not by telnetd. Why would inetd start telnetd (as reported in the question) if your client is denied access by the /etc/hosts.* files ?
– xhienne
Sep 25 '17 at 22:32

@xhienne: no. TCP wrappers will be used by any daemon compiled against Weistse Venema's socket library, If telnetd is run as a daemon and linked to the library, it will use hosts.all/deny. inetd and xinetd are usually compiled against the library. /etc/hosts does not grant/deny access - its the the data file for file based host name service. The behaviour you describe (connect, then close) is entirely consistent with the behaviour of TCP wrappers. Its also consistent with a badly configured [x]inetd. Instead of arguing, would it be so hard to text?
– symcbean
Sep 25 '17 at 22:46

Not sure what you mean by "to text". If you don't want to argue, just don't elaborate on a /etc/hosts file that I didn't even mention and just answer my one and only question. OP states that xinetd starts telnet and exits immediately. xinetd has no reason to do so if your access is denied.
– xhienne
Sep 25 '17 at 23:47

Sorry typo - not text / test.
– symcbean
Sep 26 '17 at 9:28

"host addresses don't have network masks." they don't, but it's a very convenient useful and appropriate way of signifying the subnet mask.
– roaima
12 hours ago

add a comment |

xhienne makes some good points. The TCP handshake is completing. That the connection is then closed means one of 2 things.

1) The telnetd service is failing when it starts (check your logs)

2) the client you are connecting from is not listed in /etc/telnetd.hosts (check your logs, or rename /etc/hosts.deny temporarily to confirm)

The client IP: 10.49.46.5/24

No, IP host addresses don't have network masks.

And please stop using telnetd. Every time you telnet a kitten cries. (use ssh or telnet-tls)

answered Sep 25 '17 at 21:19

symcbean

2,27911121

The TCP wrappers library is used by inetd, not by telnetd. Why would inetd start telnetd (as reported in the question) if your client is denied access by the /etc/hosts.* files ?
– xhienne
Sep 25 '17 at 22:32

@xhienne: no. TCP wrappers will be used by any daemon compiled against Weistse Venema's socket library, If telnetd is run as a daemon and linked to the library, it will use hosts.all/deny. inetd and xinetd are usually compiled against the library. /etc/hosts does not grant/deny access - its the the data file for file based host name service. The behaviour you describe (connect, then close) is entirely consistent with the behaviour of TCP wrappers. Its also consistent with a badly configured [x]inetd. Instead of arguing, would it be so hard to text?
– symcbean
Sep 25 '17 at 22:46

Not sure what you mean by "to text". If you don't want to argue, just don't elaborate on a /etc/hosts file that I didn't even mention and just answer my one and only question. OP states that xinetd starts telnet and exits immediately. xinetd has no reason to do so if your access is denied.
– xhienne
Sep 25 '17 at 23:47

Sorry typo - not text / test.
– symcbean
Sep 26 '17 at 9:28

"host addresses don't have network masks." they don't, but it's a very convenient useful and appropriate way of signifying the subnet mask.
– roaima
12 hours ago

add a comment |

xhienne makes some good points. The TCP handshake is completing. That the connection is then closed means one of 2 things.

1) The telnetd service is failing when it starts (check your logs)

2) the client you are connecting from is not listed in /etc/telnetd.hosts (check your logs, or rename /etc/hosts.deny temporarily to confirm)

The client IP: 10.49.46.5/24

No, IP host addresses don't have network masks.

And please stop using telnetd. Every time you telnet a kitten cries. (use ssh or telnet-tls)

answered Sep 25 '17 at 21:19

symcbean

2,27911121

xhienne makes some good points. The TCP handshake is completing. That the connection is then closed means one of 2 things.

1) The telnetd service is failing when it starts (check your logs)

2) the client you are connecting from is not listed in /etc/telnetd.hosts (check your logs, or rename /etc/hosts.deny temporarily to confirm)

The client IP: 10.49.46.5/24

No, IP host addresses don't have network masks.

And please stop using telnetd. Every time you telnet a kitten cries. (use ssh or telnet-tls)

answered Sep 25 '17 at 21:19

symcbean

2,27911121

answered Sep 25 '17 at 21:19

symcbean

2,27911121

answered Sep 25 '17 at 21:19

symcbean

2,27911121

answered Sep 25 '17 at 21:19

symcbean

2,27911121

The TCP wrappers library is used by inetd, not by telnetd. Why would inetd start telnetd (as reported in the question) if your client is denied access by the /etc/hosts.* files ?
– xhienne
Sep 25 '17 at 22:32

@xhienne: no. TCP wrappers will be used by any daemon compiled against Weistse Venema's socket library, If telnetd is run as a daemon and linked to the library, it will use hosts.all/deny. inetd and xinetd are usually compiled against the library. /etc/hosts does not grant/deny access - its the the data file for file based host name service. The behaviour you describe (connect, then close) is entirely consistent with the behaviour of TCP wrappers. Its also consistent with a badly configured [x]inetd. Instead of arguing, would it be so hard to text?
– symcbean
Sep 25 '17 at 22:46

Not sure what you mean by "to text". If you don't want to argue, just don't elaborate on a /etc/hosts file that I didn't even mention and just answer my one and only question. OP states that xinetd starts telnet and exits immediately. xinetd has no reason to do so if your access is denied.
– xhienne
Sep 25 '17 at 23:47

Sorry typo - not text / test.
– symcbean
Sep 26 '17 at 9:28

"host addresses don't have network masks." they don't, but it's a very convenient useful and appropriate way of signifying the subnet mask.
– roaima
12 hours ago

add a comment |

The TCP wrappers library is used by inetd, not by telnetd. Why would inetd start telnetd (as reported in the question) if your client is denied access by the /etc/hosts.* files ?
– xhienne
Sep 25 '17 at 22:32

@xhienne: no. TCP wrappers will be used by any daemon compiled against Weistse Venema's socket library, If telnetd is run as a daemon and linked to the library, it will use hosts.all/deny. inetd and xinetd are usually compiled against the library. /etc/hosts does not grant/deny access - its the the data file for file based host name service. The behaviour you describe (connect, then close) is entirely consistent with the behaviour of TCP wrappers. Its also consistent with a badly configured [x]inetd. Instead of arguing, would it be so hard to text?
– symcbean
Sep 25 '17 at 22:46

Not sure what you mean by "to text". If you don't want to argue, just don't elaborate on a /etc/hosts file that I didn't even mention and just answer my one and only question. OP states that xinetd starts telnet and exits immediately. xinetd has no reason to do so if your access is denied.
– xhienne
Sep 25 '17 at 23:47

Sorry typo - not text / test.
– symcbean
Sep 26 '17 at 9:28

"host addresses don't have network masks." they don't, but it's a very convenient useful and appropriate way of signifying the subnet mask.
– roaima
12 hours ago

The TCP wrappers library is used by inetd, not by telnetd. Why would inetd start telnetd (as reported in the question) if your client is denied access by the /etc/hosts.* files ?
– xhienne
Sep 25 '17 at 22:32

@xhienne: no. TCP wrappers will be used by any daemon compiled against Weistse Venema's socket library, If telnetd is run as a daemon and linked to the library, it will use hosts.all/deny. inetd and xinetd are usually compiled against the library. /etc/hosts does not grant/deny access - its the the data file for file based host name service. The behaviour you describe (connect, then close) is entirely consistent with the behaviour of TCP wrappers. Its also consistent with a badly configured [x]inetd. Instead of arguing, would it be so hard to text?
– symcbean
Sep 25 '17 at 22:46

Not sure what you mean by "to text". If you don't want to argue, just don't elaborate on a /etc/hosts file that I didn't even mention and just answer my one and only question. OP states that xinetd starts telnet and exits immediately. xinetd has no reason to do so if your access is denied.
– xhienne
Sep 25 '17 at 23:47

Sorry typo - not text / test.
– symcbean
Sep 26 '17 at 9:28

"host addresses don't have network masks." they don't, but it's a very convenient useful and appropriate way of signifying the subnet mask.
– roaima
12 hours ago

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Unix & Linux Stack Exchange!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you're in danger of being blocked from answering.

Please pay close attention to the following guidance:

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Sstrhsrtj