Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I'm working on a local dev setup that requires the use of telnet (playing with setting up a MUD server) so please no feedback suggesting I use SSH as a more secure alternative.

However, though I've got the telnet daemon up, I am getting this output when I telnet localhost.

$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

What are some reasons that the connection is closed? I have checked the docs on hosts.allow and hosts.deny, and have decided to not put any entries in either as the default is to allow all and that is sufficient for my local dev purposes.

share|improve this question
2  
I think you'll have to tell us more about the specific multi-user dungeon software you're using. Ubuntu's telnetd daemon normally works just fine out of the box...but it also gives you a normal login. I'm guessing the MUD server itself is what's listening on port 23, so the problem is probably in its configuration. It most likely has nothing to do with what you're doing with the telnet client. Alternatively, if you're trying to use your MUD server with native Ubuntu telnetd, please tell us what configuration you've used to try to facilitate this. –  Eliah Kagan Jan 6 '13 at 7:08
    
MUD server usually does not use telnetd. It runs as a service on a different port. –  Alistair Buxton Jan 9 '13 at 13:53
    
Ok, I was unaware that the MUD server would likely not use the native daemon. I am working on using a PHP game server library, which I assumed ran "on top of" native telnet. –  jerome Jan 9 '13 at 21:27
    
What library, and what have you done with it? If it's PHP, that suggests it might provide a web-based MUD server (though that's not guaranteed), rather than a telnet-based one. Also, assuming you installed telnetd and didn't change its configuration, it's still curious that you're not able to get a shell when you telnet to localhost. Do you still want help with that problem, even though it likely won't get in the way of you running your MUD server? –  Eliah Kagan Jan 11 '13 at 4:02
2  
If your server is running via inetd, it's quite common for inetd to listen on a port, and close connections in the manner that you're seeing if the actual server daemon cannot then be started. This might be a useful clue for you, or it might be completely irrelevant. I'm not sure which. –  Robie Basak Jan 11 '13 at 13:43
show 3 more comments

3 Answers

Okay, let's investigate this, step by step. To figure out what is actually running on telnet's port, type:

sudo netstat -tulpn | grep :23

and paste the output.

From another angle: what PHP game library are you using?

share|improve this answer
    
Alright! Sounds like we may get somewhere. –  jerome Jan 12 '13 at 3:58
    
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 2842/inetd –  jerome Jan 12 '13 at 4:00
    
The PHP game library is called NAGS, and it sounds like, based on some emails with it's creator, it is still in and of itself in a less than complete state. But I'm interested in carrying this problem through to the finish line with the information I pick up along the way. –  jerome Jan 12 '13 at 4:02
add comment

Note: I just went around looking for MUD server with NAGS game library and found this: nags-php-mud. My answer is irrelevant if you are using something else.

The config.php had the following config:

<?
    /*Modify the setting here to set up your game server */
    $configarray = array(
        'DB_HOST' => 'localhost',
        'DB_USERNAME' => 'nags',
        'DB_PASSWORD' => 'password',
        'DB_DATABASE' => 'nags',
        'IP_ADDRESS' => '0.0.0.0',
        'SERVER_PORT' => '4000',
        'SERVER_NAME' => 'NAGS GAMING SYSTEM',
);?>

So the port number is 4000. Can you try updating the IP Address to 127.0.0.1 then connecting to port 4000 using telnet: telnet 127.0.0.1 4000

Updated
In the above command, you have telnet localhost and not telnet localhost 4000.
I tried running it but I am getting some issue. It displays the following and I am unable to trace it:

PHP Notice:  Undefined index: quiet in /home/blvdeer/Downloads/nags-php-mud-master/nags.php on line 34  
PHP Notice:  Undefined index: q in /home/blvdeer/Downloads/nags-php-mud-master/nags.php on line 34
PHP Notice:  Undefined index: deamon in /home/blvdeer/Downloads/nags-php-mud-master/nags.php on line 38
PHP Notice:  Undefined index: d in /home/blvdeer/Downloads/nags-php-mud-master/nags.php on line 38
PHP Notice:  Undefined property: MAIN::$MESSAGE in /home/blvdeer/Downloads/nags-php-mud-master/modules/main.php on line 158
SYSTEM: (LOAD MODULE)   MESSAGE
SYSTEM: (LOAD MODULE)   CONFIGURE
SYSTEM: (LOAD MODULE)   DATABASE
share|improve this answer
    
That's exactly what I've been up to, without positive results. –  jerome Jan 13 '13 at 20:07
    
Updated the answer. Also in the question, you've mentioned telnet localhost instead of telnet localhost 4000 –  blvdeer Jan 16 '13 at 18:08
    
Yeah I'm hoping to hear back from the developer of the NAGS library. As far as the specific telnet issue (to 4000 or 23 or any port), still up for suggestions. –  jerome Jan 17 '13 at 19:00
add comment

Try with telnet localhost 80 Where 80 is the port on which your server is running. I tried with 80 port for apache server and it works.

Also you might need to use -K and -X option. Read more about them in the man telnet

share|improve this answer
3  
Apache is a web server, and port 80 is the port for HTTP. Telnet works for connecting to a variety of servers since it is a very basic protocol--you can manually enter commands for HTTP, SMTP, and so forth. Port 23 is the port for telnetd. So there's no reason to expect that it would be running on port 80. Sometimes people run non-HTTP servers on port 80 to enable clients to get around outbound firewall restrictions, but there's no indication that's whats going on here. Here, the OP set up the server. telnet and MUD servers are unlikely to listen on port 80 without being configured to do so. –  Eliah Kagan Jan 11 '13 at 3:59
2  
Furthermore, there is a server running on port 23 here, because the connection was made. It was just terminated after that. If the server were running on a different port and there was nothing listening on port 23, the connection would have been refused. –  Eliah Kagan Jan 11 '13 at 4:01
    
Yeah we're making the connection but then it is closed. Made me originally think there was some security reason. –  jerome Jan 12 '13 at 4:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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