sub showme {
        use Data::Dumper;

        print Dumper(@_);
        print "\n";
        foreach ( @_ ) {
                chomp $_;
                print "Thing is $_.\n";
        }
        exit;
}
[download]

As it turns out, the problem is the way the switch closes the connection at the end of the file transfer. Apparently, Net::SCP::Expect doesn't expect (pardon the pun) the string it gets. So here's the code I'm using (successfully, so far) in the production script to handle it:

sub scp_errors {
        use strict;

        my $line = shift;

        if ( $line =~ /Connection.+closed by remote host/ ) {
                # This is expected from an 8600.
                return(0);
        } else {
                # Get rid of CR and LF.
                $line =~ s/\012//g;
                $line =~ s/\015//g;
                print "Got error pulling file:\n";
                print "\t", $line;
                print "\n";
                return(1);
        }
}
[download]

As far as I can tell, only one error line gets passed to the error handler. If this turns out not to be the case later, I'll have to change scp_errors to deal with multiple args.

--J

Difficult to comment without seeing your code.

The docs state:

error_handler(sub ref)
This sets up an error handler to catch any problems with a call to 'scp()'. If you do not define an error handler, then a simple 'croak()' call will occur, with the last line sent to the terminal added as part of the error message.

So what is the error does it croak with?

That's one of the problems. Multiple errors that include the carriage return character (but no line feed!) are printed to the screen, so you can't see what went wrong.

I actually got this solved; I'll post the code I used to troubleshoot it in a sec.

--J

Since I'm pulling down a file, and since the remote end is a switch, not a server, this approach doesn't help me, since there is no 'cat' command at the far end (or anything even close, I don't think).

Thanks, though...

--J

Remember, I'm not talking about servers, I'm trying to SCP files from switches, so they don't have as sophisticated a key-handling scheme. They want to have a single DSA key pair. Using the same key pair on every switch creates a new security risk, plus it is sort of a pain to set up. Using different keys for each switch would be a major pain to set up.

But it goes beyond that. Since SSH is already enabled on each switch, the OS won't let you run the keygen command on the switch. I.e. it won't create or load the keys until SSH is disabled. We use SSH to get to the switches. Catch-22.

Hence, I need to use password-based authentication (for now).

--J

Please remember, I'm using SCP to talk to a switch, not a server, so there isn't anything to accept an SFTP connection. I know it's all over port 22, but SFTP uses semantics that aren't available from this SSH service.

Case in point:

[user@mybox user]$ sftp Admin@10.11.12.62
Connecting to 10.11.12.62...
Admin@10.11.12.62's password:
Request for subsystem 'sftp' failed on channel 0
Couldn't read packet: Connection reset by peer
[download]

--J

I got solution for error_handler()

but the thing is u dont know how to use it