Why is the "terminal speed" of a native linux telnet client 0,0 when spawned from Java (and how can I fix it)?

Question

I'm unable to login to an HPUX host using telnet when the telnet process is created by a Java program.

When I telnet to the HPUX host from the command line (from bash), I am able to login and use the session.

When I spawn the telnet process from Java, something strange happens. I am prompted for the username and submit it. I also get the prompt for the password. But for some reason the telnet server does not wait for the password; it quits the session before it is sent.

Looking at the exchange in wireshark, I see that as soon as the telnet client sends an ACK for the password prompt, the server sends a FIN packet, terminating the initializing session.

One of the differences I can see in the handshaking leading up to the password prompt is that the server asks for the terminal speed. When running telnet from the command line, the terminal speed it sends is 38400,38400. When running telnet from Java, the terminal speed is 0,0.

Looking at the source code of a telnet client, I found that one source of the "terminal speed" sent by the telnet client is the output of the cfgetospeed()/cfgetispeed() APIs. According to this, a meaning of 0 baud rate is "hang up", which is how it looks like the HPUX telnetd process is interpreting it.

I'm running from Linux Fedora Core 6.

Answer 1

I suspect that the $TERM environment variable is indirectly used to determine the speed, and is not set when spawning it from Java.

If that's not it, you could also try launching telnet through bash, i.e. start bash from Java and send it the telnet command line. That should provide exactly the same environment as when you launch it manually.