Cannot get the stream content about ssh2

[mscdex]

What ssh server, server version, and OS/platform is this with?

[rabierp]

It's an appliance for measuring power consumption of connected servers.
a PDU with an ethernet port in fact (product named HP SL APM).
The trick is that I can connect to it using other SSH command line clients (either Putty on Windows or ssh on linux) and I get the output of the command I'm using.

[mscdex]

Have you tried starting an interactive session with shell() instead of performing a one-off command execution with exec()?

[rabierp]

Just tried it. I now get the banner and prompt of the "server", but then I'm locked (cannot type anything except Break it). Is this a question of tty setup ?

[mscdex]

Hrmm, so maybe the server does not support exec(). I'm curious as to what the server claims to be though. Can you install the master branch (npm install https://github.com/mscdex/ssh2/tarball/master) and then set 'debug: console.login the object passed toconnect()`? You will see the server identification string near the beginning of the output, post that whole string here.

With regards to shell(), how it works is you're given a "duplex" stream. So if you want to send keystrokes, you have to stream.write() them (including a newline at the end when entering commands).

[rabierp]

Sorry, I had to go after other priorities for a few days.
Here's what util.inspect got me on the connection object:
_server_ident_raw: 'SSH-1.99-IPSSH-6.6.0'

[mscdex]

Hrmm... not enough information out there on that server software and definitely no free/open source code available (being a part of vxworks).

Can you post the entire debug output?

[mscdex]

I wonder if this patch on top of the current master branch would help any.

[rabierp]

Hi Brian,

Sorry, I'm not a node.js expert developper. I am more a sysadmin trying to
improve my skills with this language that I find very interesting.
Could you please detail how I can generate the kind of output you're
waiting for ?
Regards,
Pascal
2013/5/25 Brian White [email protected]

I wonder if this patchhttps://gist.github.com/mscdex/c639b997314d64535688on top of the current master branch would help any.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-18447697
.

Pascal Rabier
https://twitter.com/R3z0lv3R
France - Europe - World

[mscdex]

Install from the master branch and use the uptime exec example you were trying initially: npm install https://github.com/mscdex/ssh2/tarball/master. I'm curious to see if it works after I landed that patch.

[dstrek]

Not sure if this is related but I notice that for some commands stream.exit is firing before it finishes receiving data

Connection :: connect
Connection :: ready
Stream :: exit :: code: 0, signal: undefined
Stream :: data
 16:26:44 up  4:34,  1 user,  load average: 0.00, 0.01, 0.05

Stream :: EOF
Stream :: close
Connection :: end
Connection :: close

if I use stream.data to collect the output lines and wait for stream.end then I have the output proper but if you expect the output to be finished at stream.exit you get nothing.

Oh and yes I tested with master too

[dstrek]

For commands such as uptime and uname -a, exit will fire before EOF
but if you try something like ping -c4 google.com it looks in order

Connection :: connect
Connection :: ready
Stream :: data
Stream :: data
Stream :: data
Stream :: data
Stream :: data
Stream :: data
Stream :: EOF
Stream :: exit :: code: 0, signal: undefined
PING google.com (74.125.237.128) 56(84) bytes of data.
64 bytes from syd01s13-in-f0.1e100.net (74.125.237.128): icmp_req=1 ttl=58 time=2.13 ms
64 bytes from syd01s13-in-f0.1e100.net (74.125.237.128): icmp_req=2 ttl=57 time=2.38 ms
64 bytes from syd01s13-in-f0.1e100.net (74.125.237.128): icmp_req=3 ttl=57 time=2.54 ms
64 bytes from syd01s13-in-f0.1e100.net (74.125.237.128): icmp_req=4 ttl=57 time=2.84 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.137/2.476/2.840/0.259 ms

Stream :: close
Connection :: end
Connection :: close

[mscdex]

@dstrek That is expected behavior just like with node's child_process.spawn(). The 'close' event is what signals that all i/o streams are closed.