[jdev] Re: SOCKS5 Bytestream File Transfer problem (SOLVED!)

[Anthony Ortiz]

Hello again!!

Thanks to everyone who responded! Justin pointed me in the right
direction and Rachel Blackman finally clinched the answer. I was doing
everything right all along EXCEPT that I wasn't telling the proxy to
NOT resolve the address. It was trying to resolve the address (DUH!!)
to an ip before sending it and of course this resulted in an
exception.

Thanks everyone, I'm posting this in case anyone has the same problem
I had. Now I'm going to finish implementing the rest of the
protocol... woohoo!!

Anthony

On Sat, 26 Feb 2005 15:05:18 -0500, Anthony Ortiz
<anthonypaulo at gmail.com> wrote:
> Hello everyone!
> 
> It seems that I may be confusing this issue, so let me see if I have
> everything straight :
> 
> My understanding is that the SOCKS(5) server acts as a firewall
> between a host and a client. In order for a client to reach the host,
> it must authenticate with the SOCKS(5) server which is in essence a
> proxy. The SOCKS(5) server in turn then forwards the data to the
> actual host. The following is a diagram of what I think is going on :
> 
> client ---- SOCKS(5) server [aka. proxy] --- host
> 
> If my understanding is correct, then I must assume that a barebones
> SOCKS(5) library *MUST* include a connection mechanism in which they
> must specify both a proxy AND a host address as such [in pseudo code]
> :
> 
> SetSOCKS5Proxy(proxy_ip, proxy_port)
> s = OpenSOCKS5Socket(host_ip, host_port)
> 
> In this particular case, where a jabber bytstream file transfer occurs
> as detailed in http://www.jabber.org/jeps/jep-0065.html#proto-establish,
> I see this as being the case :
> 
> client [aka. file xfer receiver] ---- internet --- SOCKS(5) server
> [aka. proxy] --- host [aka. file xfer initiator]
> 
> Now, here is where I am running into trouble... The JEP-0065 seems to
> indicate that the host is a SHA-1 hash of the sid + initiator_jid +
> target_jid. I would assume such a host would not exist, but that's
> what the protocol says to do, so I go with it. Given the following
> actual data, I get a UnknownHost exception (and I am going by the
> book!) :
> 
> ** INITIATOR TO RECEIVER **
> <iq xmlns='jabber:client' type='set' to='aortiz at 68.101.84.233/JClient'
> id='aad5a' from='venkata at 68.101.84.233/Psi'>
>  <query xmlns='http://jabber.org/protocol/bytestreams' mode='tcp'
> sid='s5b_9490b8d451352325'>
>   <streamhost xmlns='http://jabber.org/protocol/bytestreams'
> port='8010' host='192.168.1.100' jid='venkata at 68.101.84.233/Psi'/>
>    <fast xmlns='http://affinix.com/jabber/stream'/>
>   </query>
> </iq>
> *** END ***
> 
> sid = "s5b_9490b8d451352325'"
> 
> // note : the following jid's have been nodeprepped + "@" +
> nameprepped + "/" + resourceprepped... turns out that in this case the
> result jid's are the same as the originals.
> 
> initiator_jid = "venkata at 68.101.84.233/Psi"
> target_jid = "aortiz at 68.101.84.233/JClient"
> 
> proxy_host = "192.168.1.100"
> proxy_port = 8010
> 
> host = SHA1(sid + initiator_jid + target_jid) // resulting HASH =
> "863965e5a89fed0b9aeeab809733b3ef234aa835"
> port = 0
> 
> Given the above data, the diagram should look as follows :
> 
> client [aka. file xfer receiver] ---- internet --- SOCKS5 PROXY
> [192.168.1.100:8010] --- host
> [863965e5a89fed0b9aeeab809733b3ef234aa835:0]
> 
> Therefore, I must issue the following calls to the SOCKS5 library in
> order to establish the connection [pseudo_code] :
> 
> SetSOCKS5Proxy("192.168.1.100", 8010)
> s = OpenSOCKS5Socket("863965e5a89fed0b9aeeab809733b3ef234aa835", 0)
> 
> The OpenSOCKS5Socket call does exactly what the JEP-0065 protocol
> describes... that is, it sends the following :
> 
> ** REQUEST PACKET **
> CMD = X'01'
> ATYP = X'03'
> DST.ADDR = "863965e5a89fed0b9aeeab809733b3ef234aa835"
> DST.PORT = 0
> ** END **
> 
> Yet, this results in an exception error!!! :(
> 
> I have also implemented a straight SOCKS5 connection to
> 192.168.1.100:8010 and (upon successfull connection) manually sending
> that request packet as the protocol describes, but I get 9 bytes of
> 0's as a result, which indicates an error of some sort.
> 
> Can anyone shed some light on the matter???
> 
> Thanks!
> 
> Anthony
>