Hmmm... okay, so I took your suggestion regarding the handshake. I change my code to do the following now :
[pseudo code] Set Socks5Proxy to 192.168.1.100:8010 Set Socks5Proxy to direct connect to 192.168.1.100 and no-authentication Open a Socks5Connection to 192.168.1.100:8010 So far so good, everything works well up to this point. I then send a SOCKS request as described in the protocol and send it [http://www.faqs.org/rfcs/rfc1928.html]. It sends just fine but then I get a weird response back from the initiator. Instead of getting a response packet I get the following : 000000000 *sigh*... 9 zeros... nothing at all like the request packet that i was expecting according to the protocol. Now I know I'm definitely doing something wrong. How were you guys able to implement this based on just the JEP-0065?? Am I really that dense or is there another document I should be looking at?? :((( Anyway, thanks for the assist so far... it's gotta be something stupid in the way I'm implementing this but I can't see it for the life of me... Anthony On Fri, 25 Feb 2005 15:38:32 -0800, Justin Karneges <[EMAIL PROTECTED]> wrote: > On Friday 25 February 2005 02:50 pm, Anthony Ortiz wrote: > > [1] If the Target is willing to accept the bytestream, it MUST attempt > > to open a standard TCP socket on the network address of the StreamHost > > communicated by the Initiator. If the Initiator provides more than one > > StreamHost, the Target SHOULD try to connect to them in the order they > > occur. > > > > ... > > > > [3] If the Target is able to open a TCP socket on a StreamHost, it > > MUST utilize the SOCKS5 protocol specified in RFC 1928 [7] to > > establish the connection with the StreamHost. In accordance with the > > SOCKS5 RFC, the Target MAY have to authenticate in order to use the > > proxy. However, any authentication required is beyond the scope of > > this JEP. > [snip] > > At first, my understanding was that I should open a standard TCP > > connection to the streamhost(s) (192.168.1.100:8010 in this particular > > case) in order to test if the connnection could be made (as per the > > paragraph [1]). I did this at first and that part worked fine & was > > able to connect, but then I stripped that code out because it seemed > > redundant after I read paragraph [3] which states that I will have to > > open a SOCKS5 connection to that streamhost anyway, and in the > > Maybe it's not fully clear (and I'm simply reading from the quoted text you > provided), but what [3] is intended to mean is that you would perform the > SOCKS5 protocol over the established TCP connection from [1]. There are not > two connections. I suppose it is spelled out in steps like this in case > you're writing your own SOCKS protocol code. If you're using a SOCKS library > to perform the connection, which will both create the TCP connection as well > as negotiate the SOCKS5 protocol over it, then that's all you need to use. > > > Proxy.setDefaultProxy(host, port); // sets SOCKS5 proxy to be > > 192.168.1.100:8010 > > > [snip] > > So this tells me that the actual SOCKS5 host to connect to is the SHA1 > > hash of sid + from + to and that the port is 0. That is why I have the > > following line in my code : > > Well, just to ensure our terminology is clear, the SOCKS5 host (or proxy, or > server, or whatever) is 192.168.1.100. The destination (or DST) host, ie the > one that you'll ask the SOCKS5 host to bridge you to, is the hash. > > Of course, you're aware that the hash is not a real host, and that the SOCKS5 > host (in this example, Psi) is not actually going to perform an outbound > connection to the DST as a result. It is simply used as a handshake. > > > Socket ss = new SocksSocket(SocksHost, 0); > > My confusion with this line of code is that I don't see how it relates to the > Proxy object. In other words, how does the SocksSocket know what SOCKS5 host > to connect to? I know nothing about the library you're using though, so > maybe the Proxy object interfaces with some global settings in the > background, and SocksSocket draws from that. > > It could be that you understand the protocol, and are coding with the right > intent, but simply coding it wrong. ;-) > > > p.s. btw Justin... great work on the PSI client! > > Glad you like it. :) > > Have fun, > -Justin > _______________________________________________ > jdev mailing list > [email protected] > http://mail.jabber.org/mailman/listinfo/jdev > _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
