udp response destaddress and destport fault about socks5

[grayscott]

udp response destaddress and destport should be connect dest address and port
a, addr, port, err := ParseAddress(ue.RemoteConn.RemoteAddr().String())
if err != nil {
log.Println(err)
break
}
d1 := NewDatagram(a, addr, port, b[0:n])
if _, err := s.UDPConn.WriteToUDP(d1.Bytes(), ue.ClientAddr); err != nil {
break
}

[txthinking]

The RFC doesn't describe this addr when socks5 reply to udp client.

Based RFC1928, we can guess the intention. When a socks5 client want to send UDP, then:

1. TCP: client prepares a UDP address A (that the client expects
   to use to send UDP datagrams)
2. TCP: server sends a address B(tell client should send data to)
3. UDP: client uses A send data to B
4. UDP: server sends data to remote and get data from remote
5. UDP: server sends data to client, and write a address in datagram, so I think this address should be A, so client can pair this data cause by which send

[0990]

RFC1928 say " when a UDP relay server receives a replay datagram from a remote host,it must encapsulate that datagram using the above UDP request header",so I guess grayscott is right
1,TCP: client prepares a UDP address A (that the client expects
to use to send UDP datagrams)
2,TCP: server sends a address B(tell client should send data to)
3,UDP: client uses A send data to B and write a address C in datagram,C means remote target
4,UDP: server sends data to remote C and get data from remote C
5,UDP: server sends data to client, and write a address in datagram, so I think this address should be C, so client can pair this data cause by which send

[0990]

I test ss5(http://ss5.sourceforge.net/ ),found the address udp datagram returned to client is C

[txthinking]

@0990 Thank you.