In message <_A4560@delegate-en.ML_> on 09/15/09(23:33:50)
you <email@example.com> wrote:
|There is a bug in the way delegate handles socks5 upstreaming of udp
|In the udp assicate command request that delegate sends to the upstream
|socks5 proxy, delegate sets the 途emote addressGfield to the address of
|the destination host instead of his own address.
|The upstream socks5 proxy then answers with an error message on the tcp
|stream between delegate and the upstream proxy.
|May this be fixed in an upcoming release?
Could you tell me the name of your upstream SOCKS server?
It might take a while for me to remember exactly what was the intension
of my implementation of the SOCKS client for UDP ASSOCIATE in DeleGate...
> The UDP ASSOCIATE request is used to establish an association within
> the UDP relay process to handle UDP datagrams. The DST.ADDR and
> DST.PORT fields contain the address and port that the client expects
> to use to send UDP datagrams on for the association. The server MAY
> use this information to limit access to the association. If the
> client is not in possesion of the information at the time of the UDP
> ASSOCIATE, the client MUST use a port number and address of all
It is possible that I thought the DST.ADDR might be used by a SOCKS proxy
to restrict and fix the destination address to be relayed. And I used
DST.ADDR to switch among upstream SOCKS proxies based on it.
In the existing implementation of DeleGate, you seem to able to suppress
the behavior of DeleGate with
9 9 Yutaka Sato <firstname.lastname@example.org> http://delegate.org/y.sato/
( ~ ) National Institute of Advanced Industrial Science and Technology
_< >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller