On 04/19/2011 01:03 PM, Bengt-Arne Fjellner wrote: > Hi I would like to add support for tunneling over a socks connection. > This is a first draft to show how it could be used. > I have not done any work (yet) on argument passing since this needs to > be discussed how it should look. > > This is only tested on OSX but should work fine on any unix. > Might work on windows but I doubt it (how to get username there?). > Rest of it should work there to. > > Usage steps: > > first start ssh like this > > ssh -D 1234 relay_host > or in putty configure a "dynamic" ssh forwarding > > next > in bash: > RDPDEST=realdest RDPPORT=3389 xfreerdp localhost:1234 > > tcsh > env RDPDEST=realdest RDPPORT=3389 xfreerdp rdpoptions localhost:1234 > > where realdest is the rdpserver you want to reach > RDPPORT the port on the rdp server defaults to 3389 > localhost where the socks4 server is, in this case localhost > 1234 the socks port > > Now your rdp session will go via a sshtunnel and hopefully be on right > side of firewall rules. > > > Patch attached this only affects tcp.c in libfreerdp > > Bengt-Arne Fjellner > Luleå University of Technology
Right. SOCKS is an old, widely used, generic and quite well-defined protocol, and many client tools do have built-in support for SOCKS, so why shouldn't freerdp have it. But on the other side: Why should it? And why can't those who need it just use a socksifier (tsocks, dante, runsocks, ProxyChains etc) that injects SOCKS into the application through dynamic linking? SOCKS is however IMHO substantially different from the XP Unlicensed hack. The XP hack was designed to be implemented in a wrapper around a rdp client. For some reason we got some hooks to do that in a more complex way. The SOCKS protocol kind of replaces and redefines getaddrinfo and connect and is thus very different from the XP stuff. Just like SSL support is isn't something that is suitable for implementation through generic hooks. My tentative conclusion is that I would like to see SOCKS support built in. Some comments to the patch: You send the local username. Why? It could in principle be used for some kind of load balancing and persistent reconnect, but are you aware of any products that do that? I would suggest just leaving the username field blank/empty. If there is good reason to specify the username: Shouldn't it use the specified username (if available) rather than the local account name? Note also that it has to work on Windows as well. The configuration also has to be swapped around so the server address always is the server address and the socks server is optional. So instead of RDPDEST=realdest RDPPORT=3389 xfreerdp localhost:1234 it should be more like SOCKS_SERVER=localhost:1234 xfreerdp realdest:3389 The option should however also be available on the command line, for example as xfreerdp --socks=localhost:1234 realdest:3389 I am not aware of any widely used standards for variables and options for controlling SOCKS, but you might want to take a look at curl and other tools for inspiration. I think it is very important that we use SOCKS4a (or later) and do name resolution on the server side (at least unless an IP address is specified). It is important that this feature works together with server redirects - that is where it could be really useful. We would have to use SOCKS5 to support IPv6. Is it relevant to support SOCKS4 at all? Finally: Please try to follow the coding style used in the rest of the code, especially regarding white-space. /Mads ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
