So, I have this class that uses the org.apache.commons.net.telnet.TelnetClient class. It attempts to send commands and read the response.
public class Automa
Have you checked about expect4J?
URL - http://code.google.com/p/expect4j
This is actually a java implementation for expect library.
Apache is buggy. EchoOptionHandler(false, false, false, false)
is not working. In one case new TelnetClient("dumb")
helped me. Another server obeyed only stty -echo
command.
The telnet echo command is a simple command does not require sub-negotiation. Try:
telnet.sendCommand((byte)(TelnetCommand.DONT | TelnetOption.ECHO));
It works for me.
By default, TelnetClient indicates to the remote system that it is a "vt100" terminal. The [m
is part of a VT100 escape sequence. When constructing the TelnetClient
pass "dumb"
as the first argument to indicate the terminal does not support escape sequences. So
TelnetClient telnet = new TelnetClient("dumb");
Update:
It may be the shell prompt on the remote is set to display in color. If you run "echo $PS1" you'll see what the prompt is set to and it might be something like:
\[\e]2;\u@\h : \w\007\]\[\e[39m\e[0;49m\][\[\e[1;34m\]\u\[\e[0;37m\]@\[\e[0;32m\]\h\[\e[0;36m\] \[\e[0;33m\]\w\[\e[39m\e[0;49m\]]$
That displays on my terminal as "[user@host directory]$ " with the brackets and dollar sign in white, the user in blue, the host in green and the directory in yellow. All very nice for people, but bad for machines.
As soon as you log in, send "PS1='$ '\n". That will set the prompt to exactly a dollar sign followed by a space without any extra sequences.
Interesting problem. To summarize my effort: I didn't get it working properly But here are some of my findings:
You cannot write IAC DON'T ECHO
directly to the data channel, this is done with commands and options like this example
int[] msg = {TelnetCommand.DONT,TelnetOption.ECHO};
telnet.sendSubnegotiation(msg);
You can register telnet.registerNotifHandler(new MyNotificationHandler());
to debug the commands during connection setup
public class MyNotificationHandler implements TelnetNotificationHandler
{
@Override
public void receivedNegotiation(int negotiation_code, int option_code)
{
System.out.println("--->"+get(negotiation_code)+" "
+TelnetOption.getOption(option_code));
}
private String get(int i)
{
if(i==TelnetNotificationHandler.RECEIVED_DO){return "RECEIVED_DO";}
else if(i==TelnetNotificationHandler.RECEIVED_DONT){return "RECEIVED_DONT";}
else if(i==TelnetNotificationHandler.RECEIVED_WILL){return "RECEIVED_WILL";}
else if(i==TelnetNotificationHandler.RECEIVED_WONT){return "RECEIVED_WONT";}
else if(i==TelnetNotificationHandler.RECEIVED_COMMAND)
{return "RECEIVED_COMMAND";}
return "UNKNOWN";
}
}
We have this problem also in our use of the java TelnetClient. It is inconsistent whether the telnet server returns the sent command in its responses.
What we are doing currently to make sure the command is not included in the response data is sending the stty command to the telnet session to turn off terminal echoing. This works for telnet servers running on linux and if the command is entered in the bash shell:
stty -echo