On Fri, Jun 5, 2009 at 9:29 PM, Steven Edwardswinehacker@gmail.com wrote:
On Fri, Jun 5, 2009 at 9:40 AM, Gabriele Grecogabrielegreco@gmail.com wrote:
Hello guys, I'm lurking this list since a pair of weeks but I've not yet posted here. I've added socks 4/5 support right inside of ws2_32 library, I've tested it with various applications and it works correctly both with sync and async sockets (only TCP). The code works very well also with fairly intensive network apps like "world of warcraft" :) At the moment the support is activated by enviroment variables (SOCKS_SERVER/SOCKS_PROTOCOL/SOCKS_USER/...) and the code is not very clean. I've seen that wine patches are not accepted if not cleaned up, so I wanted to ask if my effort can be of any interest for the official GIT or if I'll have to mantain it for myself on my local GIT (I've written this patch mostly for personal use since I need socks support to use certain services cut down by the company firewall). Obviously if there is any interest to see socks support inside wine I'll try to clean up the patch and make it follow the specs that the wine socks support is supposed to have (for instance configurability through winecfg for example).
It sounds very useful. If there is not already a bug regarding socks, then I suggest filing one and posting the patch there as interested parties can comment and help point out bugs, design changes needed, etc. You can also send your patch here for review.
We have bugs 8686 and 18293 about SOCKS not working. The problem AFAICT is the native LD_PRELOAD based socksification libraries (that override socket functions like connect and accept to use SOCKS transparently) will break on Wine, since they are based on the concept of an immutable file descriptor. Wine continually dup()s sockets as they are shuttled between the app and wineserver, so socket identities change.
From what I see you can either write/patch a native socksification
library to track dup()s and dup2()s, as well as possibly do something about the unix domain sockets that are used to transfer file descriptors between the app and wineserver. Or alternatively fstat() a socket and use the inode number as its identity instead of the file descriptor, since the inode doesn't change between dup()s. I'd prefer this approach to socksifying our WS2_32.DLL, since proxy support is more of a third party feature, it was always designed to be done at a library or system level, we might need to support other types of proxies, etc.
In addition I know of a way this type of feature can fix bug 7929, but that's a story for another day.
Right off the bat I'd say the variables need to go. Alexandre is very picky about adding new variables to Wine. I assume there are some registry keys where a socks proxy is stored, it may even be the same place where normal proxy information is stored and an extra key to define if it uses socks or not. I would try looking at something like IE and see how it sets the proxy server stuff.
Thanks
Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Damjan Jovanovic