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).
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.
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
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
On Sat, Jun 06, 2009 at 12:45:58PM +0200, Damjan Jovanovic wrote:
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'm not 100% sure you can guarantee (probably OS dependant) that fstat() on a socket return anything sensible for an inode number.
David
On Fri, 5 Jun 2009, Steven Edwards wrote: [...]
Right off the bat I'd say the variables need to go.
One possible exception is if the environment variables are the standard way to configure SOCKS support on Linux. Then Wine should respond to the same variables to activate its own SOCKS support (if it has to implement SOCKS support itself).
Hi Gabriele,
On Fri, Jun 5, 2009 at 6:40 AM, Gabriele Grecogabrielegreco@gmail.com wrote:
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).
The usual test is whether Windows supports something. If Windows has SOCKS support in ws2_32, then certainly, we're interested. If not, figuring out how Windows does it and adding support for that method is more likely to get accepted. As Steven said, adding new environment variables is generally frowned on. --Juan
-
Damjan Jovanovic -
David Laight -
Francois Gouget -
Gabriele Greco -
Juan Lang -
Steven Edwards