the connection is likely only closed when teh server dies.  are you sure the server was still running at this point?  can you find any crash messages in the logg if not?

Server did not die i.e. this  could be repeated....

[root@maloxf-music scripts]# telnet 10.102.34.70 9090
Trying 10.102.34.70...
Connected to 10.102.34.70 (10.102.34.70).
Escape character is '^]'.
00:04:20:05:b7:16 playlist play Playlists/morning.cl.m3u
00%3A04%3A20%3A05%3Ab7%3A16 playlist play Playlists%2Fmorning.cl.m3u
Connection closed by foreign host.

if server was not running I assume there would be no 'connected to' message  and the telnet session would timeout or be refused.

fred, any thoughts?

Can you enable d_command and d_cli and try it again? Thanks

There are other technical reasons while the connection can be closed, but they involve connections problems (like the CLI cannot read from it, etc).

One reason why the CLI can disconnect at the first command is because of security. If enabled, the CLI wants a correct login. Any other command (or a wrong login) leads to a disconnection. At least this is noted (as could well be the case here) by any legacy code...

So please check the security status of the server. If that does not fix it, please enable the debug flag d_cli, try again, and post the log here.

Any news?

(In reply to comment #6)
> Any news?
> 

Apologies for delay on further info. 

Yes it appears that turing on password security causes this to happen.
This is new behaviour as having security turned on in v 5.4 made no difference to CLI function.

Is the CLI logon procedure documented anywhere?

(In reply to comment #7)
> (In reply to comment #6)
> > Any news?
> > 
> 
> Apologies for delay on further info. 
> 
> Yes it appears that turing on password security causes this to happen.
> This is new behaviour as having security turned on in v 5.4 made no difference
> to CLI function.
> 
> Is the CLI logon procedure documented anywhere?
> 

Ah yes I found the relevant paragraph(s) in the CLI documentation

"# The Security settings of the SlimServer preferences apply to CLI connections when they are established. A change in security settings do not affect established connections. The connection is only accepted from allowed hosts. If password protection is enabled, the "login" command must be the first command sent after the connection. Any error in the user and/or password, or using any other command as the first one, results in the server disconnecting.

General commands

login <user> <password>

The "login" command allows the caller to authenticate itself on the server, as defined in the Security pane of the SlimServer preferences. Like any other command, the user and password must be escaped. If successful, the server replaces the password with 6 star characters. If unsuccessful, the server disconnects. If security is off this command is always successful.

Examples:

    Request: "login user correctpassword<LF>"
    Response: "login user ******<LF>"

    Request: "login user wrongpassword<LF>"
    Response: (Connection terminated)

------------------------
So this is not a bug, just an unexpected change functionality. 

Very good.

Yes when implementing it we gave some thought to the issue of legacy code not aware of the change. We thought disconnection would at least get some notice, as it did in this case. I just wonder why it took me so long to think about it... Maybe I should add something to the log in this case. Will do.

Have fun with the CLI