Skip Menu |

This queue is for tickets about the Net-Telnet CPAN distribution.

Report information
The Basics
Id: 51113
Status: rejected
Priority: 0/
Queue: Net-Telnet

People
Owner: Nobody in particular
Requestors: lordadmira [...] yahoo.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: (no value)
Fixed in: (no value)



Subject: @ (at sign) corruption over ssh
Hi Jay, I hope ur still maintaining Net-Telnet. I've encountered a problem that makes no sense. I'm using the ssh example in the documentation to connect to a Sun 10 box. It doesn't support telnet. I can log in OK and do shell commands. However I need to transfer a dynamically generated Perl script over the connection. I do a "print perl -" and wait for a returned newline indicating that Perl is running. Then I iterate over each line of the HERE program sending it with a print(). The code is transferred OK except for one thing. All @ signs have a CRLF after them in the code echoed back by the box. I'm using the dump log and it shows that I send "@var" and get back "@\r\nvar" in the return stream. Perl then dies complaining about trying to modify a constant. I'm using this exact same construct on a telnet connection with no problems. I tried changing the print() to put() once character at a type and no difference. The line position of the @ sign makes no difference. Setting Binmode on the object made no difference either. It does it on three different Perl binaries that I tried, all different versions. Net-Telnet is 3.03. Ssh is OpenSSH_4.3p2-hpn, OpenSSL 0.9.7i 14 Oct 2005, HP-UX Secure Shell-A.04.30.006, HP-UX Secure Shell version. Here's some snippets. Dumplog Show quoted text
> 0x00000: 22 " > 0x00000: 40 @ > 0x00000: 62 b > 0x00000: 6f o > 0x00000: 62 b > 0x00000: 22 " > 0x00000: 3b ; > 0x00000: 0a . > 0x00000: 28 ( > 0x00000: 40 @ > 0x00000: 7b { > 0x00000: 64 d > 0x00000: 69 i > 0x00000: 72 r > 0x00000: 73 s > 0x00000: 7d } > 0x00000: 20 > 0x00000: 3d =
... < 0x000d0: 0a 24 7c 20 3d 20 31 3b 0d 0a 22 40 0d 0a 62 6f .$| = 1;.."@..bo < 0x000e0: 62 22 3b 0d 0a 28 40 0d 0a 7b 64 69 72 73 7d 20 b";..(@..{dirs} < 0x000f0: 3d 20 67 6c 6f 62 20 24 61 72 63 68 69 76 65 73 = glob $archives Constructor $pty = &spawn($sshcmd, "-l", $username, $server); # spawn() defined below $ssh = new Net::Telnet (-fhopen => $pty, -telnetmode => 0, -cmd_remove_mode => 1, -output_record_separator => "\r", Dump_Log => "cwtelnet.log", Binmode => 1 ); sub spawn { my(@cmd) = @_; my($pid, $pty, $tty, $tty_fd); ## Create a new pseudo terminal. $pty = new IO::Pty or die $!; ## Execute the program in another process. unless ($pid = fork) { # child process die "problem spawning program: $!\n" unless defined $pid; ## Disassociate process from existing controlling terminal. POSIX::setsid or die "setsid failed: $!"; ## Associate process with a new controlling terminal. $tty = $pty->slave; $pty->make_slave_controlling_terminal(); ## fix $tty_fd = $tty->fileno; close $pty; ## Make stdio use the new controlling terminal. open STDIN, "<&$tty_fd" or die $!; open STDOUT, ">&$tty_fd" or die $!; open STDERR, ">&STDOUT" or die $!; close $tty; ## Execute requested program. exec @cmd or die "problem executing $cmd[0]\n"; } # end child process return $pty; } Hope u can help. Thanks.
From: lordadmira [...] yahoo.com
I'm posting this for the benefit of other users who might happen across this bug report. I don't know what's causing the bug but I have found workarounds. The problem is that some Net-Telnet/ssh/Pty weirdness is corrupting the remote terminal control. Running stty -a through the connection will reveal bizarre values for the terminal control characters. As in a plain @ character for kill. The way to fix this is to make running stty sane the very first thing u do over ur connection. That resets the terminal controls so u can do business. A related problem is that sending data over the connection can overload the other side resulting in lost data. I've been using this to transfer Perl code to Perl's standard input to run HERE programs. If the remote Perl is overloaded it will print a ^G (BELL). To handle that u have to monitor the $ssh->buffer value for a ^G. If it's there, retransmit the chucked line. It sucks but it works.
Sorry I didn't have time to help you debug this when you submitted it. It looks like an interesting problem and it would have been nice to know how the stty setting was getting messed up. However it does not appear to be a bug with Net::Telnet. Thanks for submitting it.