www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples

Archive Index This month's Index

Subject: Re: Potential remote listener bug

Re: Potential remote listener bug

From: Przemysław Szczygielski <qus123_at_gmail.com>
Date: Fri, 11 Nov 2011 08:18:54 +0100

Hello,

If I might refresh old topic. According to someone's suggestion, that
tunnelier handles RDC in a special way (fixing potential framing
problem) I asked bitvise directly if it does really. They denied:

"I honestly don't see a reason why PuTTY wouldn't work. I don't see
any substantial differences between how PuTTY implements the reverse
tunnel, and how Tunnelier does."

https://fogbugz.bitvise.com/default.asp?flowssh.3.17114.2

I made one test with synchronized timers on remote RDP server and
client connecting to -R-ed port. Here's the outcome (last number is
the amount of bytes sent):

=======================================================================================
enter pressed in login window
=======================================================================================-------"
Client to RDC 19:34:57 17
Client to RDC 19:34:58 59
Client to RDC 19:34:58 45
Client to RDC 19:34:58 31
Client to RDC 19:34:58 59
Client to RDC 19:34:58 31
Client to RDC 19:34:58 31
RDC to client 19:34:59 30
=======================================================================================
a minute passes, nothing happens
=======================================================================================
RDC to client 19:35:59 357
=======================================================================================
RDC window becomes black
=======================================================================================
Client to RDC 19:36:00 697
Client to RDC 19:36:00 52
=======================================================================================
a minute passes, nothing happens
=======================================================================================
RDC to client 19:36:59 327
=======================================================================================
RDC window becomes blue ("desktop blue")
=======================================================================================
Client to RDC 19:37:00 527
RDC to client 19:37:00 100
Client to RDC 19:37:00 226
RDC to client 19:37:00 128
RDC to client 19:37:00 51
RDC to client 19:37:00 1606
RDC to client 19:37:00 272
Client to RDC 19:37:00 46
Client to RDC 19:37:00 72
=======================================================================================
disconnect
=======================================================================================

Before I try to examine the protocol using network snoopers - do you
have any more ideas?

Cheers,

Przemek

2011/9/26, Przemysław Szczygielski <qus123_at_gmail.com>:
>>
>> > Well, yes, I suspected that a the end of the day I will have to do
>> > protocol snooping. Ok, thank you for your explanation.
>>
>> I first suggested another method of gaining more data. You seem to
>> have overlooked that. Please do not overlook any advice you get.
>>
>> But yes, you will need to understand the application protocol better
>> to determine if there is a problem with libssh2, and how it should be
>> fixed.
>>
>>
>>
> I didn't overlook it, I will test linux client as soon as I get hold of a
> linux machine. If I can bother you a bit more. I debugged the circuit a bit
> and the last thing that happens before disconnect is this:
>
> ("TCP" being local network port on which RDC client talks to "SSH" -
> channel got from listener on a local ssh server, d_readyRead shows each
> clearing of blocking condition in libssh2):
>
> "1. SSH->TCP 627 bytes
> QxtSshClientPrivate::d_readyRead----------------------------------------------
> "1. SSH->TCP 104 bytes
> "2. TCP->SSH: 327 bytes
> QxtSshClientPrivate::d_readyRead----------------------------------------------
> "1. SSH->TCP 527 bytes
> "2. TCP->SSH: 100 bytes
> QxtSshClientPrivate::d_readyRead----------------------------------------------
> "1. SSH->TCP 226 bytes
> "2. TCP->SSH: 104 bytes
> "2. TCP->SSH: 1412 bytes
> "2. TCP->SSH: 327 bytes
> QxtSshClientPrivate::d_readyRead----------------------------------------------
> "1. SSH->TCP 118 bytes
> QxtSshClientPrivate::d_readyRead----------------------------------------------
> TCP disconnects, breaking circuit
>
> I tested it several times and the sequence before disconnect looks very
> similar each time. Don't know much about frames, but the number of bytes
> exchanged seems... well... so small, are these frames smaller than 1kB?
>

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2011-11-11

the libssh2 team