Subject: [ libssh2-Bugs-2788319 ] Problems with remote port forwarding

[ libssh2-Bugs-2788319 ] Problems with remote port forwarding

From: SourceForge.net <noreply_at_sourceforge.net>
Date: Tue, 12 May 2009 08:57:10 +0000

Bugs item #2788319, was opened at 2009-05-07 12:32
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=703942&aid=2788319&group_id=125852

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: API
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: SKujala (samikujala)
Assigned to: Daniel Stenberg (bagder)
Summary: Problems with remote port forwarding

Initial Comment:
Out of curiosity (and to educate myself) I decided to try and set up remote port forwarding with using Libssh2. Something along the lines of

ssh -nNT -R 5900:localhost:5900 user_at_host

This turned out to be a non-trivial task due to my little experience with libssh2 and sparse documentation. To explain my findings, let's call my end host A, and the remote end host B. I wish to connect from host A to host B, after which the ssh daemon in host B is to establish remote port forwarding back to host A.

I was successful, but it appears that there are some bugs in channel.c file, which I address in the attached patch file. The way I establish the remote port forwarding, 'tcpip-forward' channel is as follows:

(assume the connection and session are established and user authentication is successful)

listener = libssh2_channel_forward_listen(session, 5900);
channel = libssh2_channel_forward_accept(listener);

1. as packet_queue_listener() in packet.c successfully allocates and queues the incoming connection from host B into a new channel, _libssh2_packet_add() in packet.c fails to add the incoming packets into the proper channel, as _libssh2_channel_locate() in channel.c fails to locate the previously allocate channel.

If I understand correctly, this is because _libssh2_channel_locate() tries to locate the channels only from the current session, whereas the channel it is looking for is in the queue of incoming connections.

I fixed this by changing _libssh2_packet_add() to iterate not only through the current session, but also through the queues contained in the listeners contained in the current session.

2. channel_forward_accept() in channel.c fails to break from the do-while loop because the condition to end the do-while loop is wrong. The condition (rc > 0) should read (rc < 0).

Please review my attached patch and if deemed correct, commit it into the tree.

Best regards,

Sami

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2009-05-12 10:57

Message:
Ahem. There's no need to loop when NONE is returned as then it didn't add
anything. Thus > 0 is a fine check since then it loops only as long as
there were packets actually added...

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2009-05-12 10:48

Message:
First, the _libssh2_transport_read() function can in fact return a few
other errors too, but all errors (including EAGAIN) are negative values.

The PACKET_NONE is 0 and indicates that all is fine.

I figure the loop should then be (rc >= 0) so that it'll "drain" the
incoming socket properly?

----------------------------------------------------------------------

Comment By: Neil Gierman (roadrunn)
Date: 2009-05-11 20:07

Message:
Is this another use case that was fixed with the patch from bug #2785173
(https://sourceforge.net/tracker/?func=detail&atid=703942&aid=2785173&group_id=125852)

----------------------------------------------------------------------

Comment By: SKujala (samikujala)
Date: 2009-05-11 11:03

Message:
Hi,

Sorry for the late reply.

According to the code documentation, _libssh2_transport_read() returns the
packet type ( > 0 ), PACKET_NONE, PACKET_FAIL, or PACKET_EAGAIN. The loop
in channel_forward_accept() as it is now only ends when
_libssh2_transport_read() reports failure. Please correct me if I'm wrong
but would it not make more sense if loop would end when there are actual
packets in the connection queue?

At least in my case I was not able to have channel_forward_accept() give
me a channel upon remote connection before I changed the condition as it is
in my patch.

Now that I'm thinking about it more, maybe the condition to end the loop
should be ( rc <= 0 ) rather than ( rc < 0 ) to not end looping if we get
PACKET_NONE from _libssh2_transport_read().

Regards,
Sami

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2009-05-07 21:36

Message:
Thanks for your patch.

Can you please tell me what that second part of the patch is supposed to
fix? It will bail out the _libssh2_transport_read() loop in
channel_forward_accept() if it returns something >= 0 and I would like to
know what you think that's a good idea!

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=703942&aid=2788319&group_id=125852

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
libssh2-devel mailing list
libssh2-devel_at_lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
Received on 2009-05-12