Support for SOCKS5 UDP_ASSOCIATE command

[hc-syn]

I have been working on the UDP support in ProxyChains. I have written a wiki (https://github.com/hc-syn/proxychains-ng/wiki) to explain my implementation.

[Abhinavpatel00]

looks interesting , why its still not merged yet?

[rofl0r]

@Abhinavpatel00 proxychains wasn't designed with UDP in mind, and integrating this properly is a huge task - or even impossible, if we want to keep all existing configuration knobs working.

first of all, this PR only supports UDP via socks5, whereas proxychains supports HTTP, SOCKS4(a) and SOCKS5. next it's unclear whether this PR only supports a single proxy, or chaining of multiple proxies - which is the main feature of proxychains, as reflected in the name. it's also unclear whether the PR works properly with dnat, localnet, and all the other features. the PR is also huge - more than 2000 lines of code changed or added. a proper review would require a lot of time, which i'm currently unable to spend. even with that done, it's likely a lot of new bugs would be introduced in corner-cases, which i would have to fix myself over time.

last but not least the PR introduces a dependency on libuv, if i understand correctly, just because the author likes that particular library and wants to support it out-of-the-box. that's completely unacceptable for upstreaming.
i think the author is aware of these points and chose from the get-go to do his own feature-fork, as evident from the PR description and the linked-to wiki.

[Abhinavpatel00]

@Abhinavpatel00 proxychains wasn't designed with UDP in mind, and integrating this properly is a huge task - or even impossible, if we want to keep all existing configuration knobs working.

first of all, this PR only supports UDP via socks5, whereas proxychains supports HTTP, SOCKS4(a) and SOCKS5. next it's unclear whether this PR only supports a single proxy, or chaining of multiple proxies - which is the main feature of proxychains, as reflected in the name. it's also unclear whether the PR works properly with dnat, localnet, and all the other features. the PR is also huge - more than 2000 lines of code changed or added. a proper review would require a lot of time, which i'm currently unable to spend. even with that done, it's likely a lot of new bugs would be introduced in corner-cases, which i would have to fix myself over time.

last but not least the PR introduces a dependency on libuv, if i understand correctly, just because the author likes that particular library and wants to support it out-of-the-box. that's completely unacceptable for upstreaming. i think the author is aware of these points and chose from the get-go to do his own feature-fork, as evident from the PR description and the linked-to wiki.

thanks a ton for such a detailed reply :D , you might be on of the most humble oss maintainer out there