Managing TERM TYPE Option Requests with Net::Telnet

[initself]

I wrote an application that uses Net::Telnet to login to a remote server. On servers that don't expect to receive a particular term type, the application runs fine. However, on servers that expect a VT102 terminal type, the application errors out.

The logs for Putty tell me that the troublemaking server expects my application to send back a Terminal Type:

Event Log: server:    SB TTYPE SEND
Event Log: client:    SB TTYPE IS XTERM

According to the docs, Net::Telnet the option_send method to answer a Telnet option negotiation request "is not yet implemented". Luckily I found Net::Telnet::Options, which appears to be designed to manage such requests.

use Net::Telnet;
use Net::Telnet::Options;

# Create Telnet Object
my $t = new Net::Telnet(Dump_log   => 't_dump.txt', 
                        Output_log => 't_input.txt', 
                        Input_log  => 't_output.txt',
                        Errmode    => 'return',
                        Timeout    => '10',  
                        );

# Create Telnet Options Object
my $nto = Net::Telnet::Options->new();

# Accept and deal with incoming TERM TYPE option requests
$nto->acceptDoOption('TTYPE', {'SB' => \&ttype_sb_callback } );

sub ttype_sb_callback
{
   my ($cmd, $subcmd, $data, $pos) = @_;
   my $socket = "23";

   $nto->sendOpt($socket, 'SB', 24, 'IS', 'VT102');
   return ;
}

$t->open($host);
$t->waitfor('/login:/');
$t->print("$username");

Right after the initial login, the error occurs since the TERM TYPE handshake is not able to be made between my application and the server application:

($prematch, $match) = $t->waitfor(Match => "/Welcome/");
unless (defined $match) {
  print $t->errmsg;
}

The error message is: pattern match read eof

Net::Telnet::Options looks very promising but it looks like I'm not integrating it into my code correctly. What might I have to change to get the application to see my TERM TYPE response?

[castaway]

Yup, you're missing a vital call.. It seems that Net::Telnet does in fact use IO::Sockets. You need to add something like:

 $data = $nto->answerTelnetOpts($t, $data);

i.e. you need to tell N::T::O to actually do some parsing. What I'm not to sure of, is how you get the raw data out of Net::Telnet. It looks to me like you want to use $t->buffer, and set telnet_mode => 0, but I haven't tried it.

C.

[initself]

Excellent! Given your advice, I was able to see how use my telnet object $t as a socket.

First I set the TERM TYPE Option in the $nto object:

my %options = (TTYPE => { 'DO' => sub {} },);
my $nto = Net::Telnet::Options->new(%options);

Then I set my telnetmode to 0:

$t->telnetmode(0);

After opening my host, I received three sets of data from the application server. Since the first request contained the TERM TYPE request, I sent the reply that I was an 'xterm' with the sendOpt function:

$t->open($host);
recv($t, $data, 1024, 0);
$nto->answerTelnetOpts($t, $data);
$nto->sendOpt($t, 'SB', 24, 'IS', 'xterm');
recv($t, $data, 1024, 0);
$nto->answerTelnetOpts($t, $data);
recv($t, $data, 1024, 0);
$nto->answerTelnetOpts($t, $data);

And then I went about my business as usual with Net::Telnet:

$t->telnetmode(1);
($prematch, $match) = $t->waitfor('/login:/');

[castaway]

Woo, I'm impressed. I would have thought that you could use the sub callback as you had before, with this method, and just get NTO to send the "xterm" reply for you.. But yours apparently works too. Since it doesnt really care in which order it gets which options replied to, and if you get a host that doesnt send the TTERM option, itll just ignore your reply.

Would you mind trying with callback as well? Then I'll add this to the NTO docs, thanks!

C.

[Khen1950fx]

Since some of the servers that expect VT102 are erroring out, I would suggest using Term::VT102 along with Net::Telnet. You'll need to interface Term::VT102 with Net::Telnet though. The Term::VT102 distribution has an examples/directory that will show how to do that.