DataReady not returning enough (General questions)

I am running into a problem at a single customer using the SSH ActiveX component. We are successfully connecting via uid/privkey and sending a shell script to ESX 4.0, but DataReady is not returning enough to continue.

I've tried to explain the problem in pseudo-code. As you can see we are not continuing until DataReady is more than our command length. So, because DataReady only returns 17 it loops endlessly.

Please advise.

sCommand = if [ -e /etc/vmware-release ]; then RELFILE=/etc/vmware-release; OSVER=`sed -e 's/[^[:digit:]]*//' -e 's/[ ]*(.*//' $RELFILE`; OSNAME=`sed -e 's/[ ]*[[:digit:]].*//' $RELFILE`;elif [ -e /proc/vmware/version ]; then RELFILE=/proc/vmware/version; OSVER=`sed -n '1p' $RELFILE | sed -e 's/.*Server[ ]*//' -e 's/[ ]*[.*//'`; OSNAME=`sed -n -e '1s/[ ]*[[:digit:]].*//p' $RELFILE`;else OSVER= Unknown ; OSNAME= Unknown ;fi;echo -n $OSNAME $OSVER ; echo -e 0000
ISSH.Send(sCommand)

eState = Sending
do
{
eState = ISSH.State(sCommand)
Sleep(1000)
}
while(eState == Sending)

// State == Connected

lDataReady = 0
do
{
lDataReady = ISSH.DataReady()
// first call returns 0
// second call returns 17

if(0 == lDataReady || lDataReady < sCommand.length())
lDataReady = 0
}
while(lDataReady == 0)

...

Hi Bruce,

Which version of the component you use? Did you try the latest one?

If not, can you please do so, since there is a chance this was already dealt with in the past.

Also, is there any chance we can reproduce this behaviour?

Regards,
Damba

I'm using wodSSH ActiveX 2.6.8. What would I need to try the new one, as a test? Just replace a single dll?

And the problem is only reproducible in the customer environment.

Another thing I'm looking for is possible troubleshooting steps. For instance, I've started ESX's sshd daemon in debug (-d -d -d) mode, but nothing terribly useful has resulted. Where else can I look? /var/log/secure, etc.

Bruce,

You can request an update from http://www.weonlydo.com/index.asp?update=1 if you have an active subscription.

Or, you can try the Trial version, but in that case please make a backup of your existing version.

You will also need to re-import the component into your project.

As for debugging, you can try setting DebugFile property, but I'm not really sure how much that would help, since all communication in SSH is encrypted.

Regards,
Damba

Bruce,

one more thing - can you wait longer to see if DataReady will return enough info? If data is coming slower, it is possible in the moment you check not all data has arrived yet.

However, please do not use Sleep API, since you're not allowing wodSSH to process internal data since you're blocking the thread.

Anyway, why not using Waitfor instead of DataReady, especially if you're waiting for some known result in received data?

Regards,
Kreso

Bruce,

BTW this code (not sure if it's correct one or it's just pseudo)

do
{
lDataReady = ISSH.DataReady()
// first call returns 0
// second call returns 17

if(0 == lDataReady || lDataReady < sCommand.length())
lDataReady = 0
}
while(lDataReady == 0)

will not allow wodSSH to process anything, since you're looping in the same thread forever.

Kreso

I've downloaded a trial for wodSSH, installed and found wodSSH.dll. Can I just 1) rename existing version 2.6.8 and 2) copy in version 2.9.4.141?

I don't understand the necessity of re-importing into my project for a simple test. It's a COM component and backward compatible. Correct?

This is pseudo code and I forgot the sleep.

do
{
lDataReady = ISSH.DataReady()
// first call returns 0
// second call returns 17

if(0 == lDataReady || lDataReady < sCommand.length())
{
lDataReady = 0
Sleep(1000)
}
}
while(lDataReady == 0)

Bruce,

but Sleep isn't good for the purpose. It blocks the thread - your own, but same one where wodSSH lives, and it cannot process the messages (WaitMessage/GetMessage.....) so it's basically the same thing.

Perhaps this is the reason why you never receive more data. Maybe they arrive from the socket, but wodSSH can never receive them since you don't give it any slice of time.

Kreso

I understand and I agree the code should be modified. However, the curious part of this problem is it works fine in house and at all our other customers.

As a test, I put v2.9.4.141 of wodSSH.dll on my test box and, viola, I reproduced the exact same problem. Can you think of why the code would work with v2.6.6.77, but not v2.9.4.141?

Also, can you express your recommended changes via the pseudo code I've previously included?

Bruce,

as you using blocking mode, or it is event driven?

If it's event driven, I would suggest you wait for Received event, read all received data and append to your inernal buffer.

Then check everything in the buffer, and look if your data is inside.

If it's blocking, then call Receive in the loop. It will wait for data to arrive, but wodSSH will not block (your app will since it will sit in Receive call).

Can you try that?

Kreso

I've noted your suggestions and will try them during our next release cycle. Thank you!

For now, the fix for the customer was to revert to v2.6.6.77 of wodSSH.dll. It turns out some other product installed a later version of wodSSH.dll exposing the issue. And since wodSSH.dll is a COM object, last one registered wins.

Any idea why v2.6.6.77 would work, but the latest version does not?

Bruce,

There were some changes related to DataReady property, which fixed the possibility of it returning a negative value.

A simple .dll swap should work. However, without actually reproducing and debugging the issue, I can't say why it doesn't.

Regards,
Damba