powered by Jive Software

Bug: Direct Socks5 connections are not available when using GTALK

The Google Talk service does not support the discovery of items. Performing a query will throw an

XMPP exception.

Problem:

When trying to establish a Socks5 stream, the Socks5StreamManager tries to retrieve all Socks5 proxy of the XMPP server.

This fails for Google Talk and so no Socks5 stream is established although a direct Socks5 stream connection may be possible.

Class: Socks5BytestreamManager

Method: public Socks5BytestreamSession establishSession(String targetJID, String sessionID) throws XMPPException, IOException, InterruptedException

Change:

// determine SOCKS5 proxies from XMPP-server

List proxies = determineProxies();

to

List proxies = new ArrayList()

try

{

proxies.addAll(determineProxies());

} catch(XMPPException e)

{

… do exception stuff here

}

1 Like

That sounds legit.

What kind of XMPPException is thrown and from which code place? Can you give us some more information which google service you query with service discovery and a XMPP stanza log? That would be great.

ERROR 02:20:50,087 [Worker-5] (Router.java:210) * failed to connect using XEP 65 SOCKS5

java.io.IOException: feature-not-implemented(501)

at *.ByteStreamTransport.connect(ByteStreamTransport.java:36)

at *.Router.connect(Router.java:206)

at *.NetworkServiceImpl.connect(NetworkServiceImpl.java:53)

at *.OutgoingSessionNegotiation.start(OutgoingSessionNegotiation.java:70)

Caused by: feature-not-implemented(501)

at org.jivesoftware.smackx.ServiceDiscoveryManager.discoverItems(ServiceDiscoveryM anager.java:495)

at org.jivesoftware.smackx.ServiceDiscoveryManager.discoverItems(ServiceDiscoveryM anager.java:461)

at org.jivesoftware.smackx.bytestreams.socks5.Socks5BytestreamManager.determinePro xies(Socks5BytestreamManager.java:526)

at org.jivesoftware.smackx.bytestreams.socks5.Socks5BytestreamManager.establishSes sion(Socks5BytestreamManager.java:423)

at org.jivesoftware.smackx.bytestreams.socks5.Socks5BytestreamManager.establishSes sion(Socks5BytestreamManager.java:83)

at *.Socks5Transport.establishConnection(Socks5Transport.java:47)

at *.ByteStreamTransport$ConnectionRequest.accept(ByteStreamTransport.java:129)

*.Router$3.connectionRequest(Router.java:114)

*.ByteStreamTransport.connect(ByteStreamTransport.java:32)

… 6 more

Domain used was googlemail.com . I do not know what Smack is using as service name, maybe googlemail.com or the real hostname like talk.google.com or some other server.

Hmm, after looking at the source, I am not 100% sure if this will do the trick. Your basic idea is correct: Don’t fallback to IBB unless you haven’t tried a direct Socks5 connection to the remote host. But from looking at establishSession() it seems like the current code doesn’t even try to initate a direct connection as describe by XEP-65 5.

So even if we catch the exception that is caused by the user’s XMPP server not implementing service discovery (like gmail.com), we have not point to fallback/jump to if we still want to go the Socks5 way instead of IBB.

Correct me if I am wrong.

Well this is my patched code

public Socks5BytestreamSession establishSession(String targetJID,

String sessionID) throws XMPPException, IOException,

InterruptedException {

XMPPException discoveryException = null;

// check if target supports SOCKS5 Bytestream

if (!supportsSocks5(targetJID)) {

throw new XMPPException(targetJID

  • " doesn’t support SOCKS5 Bytestream");

}

// determine SOCKS5 proxies from XMPP-server

List proxies = new ArrayList();

try {

proxies.addAll(determineProxies());

} catch (XMPPException e) {

discoveryException = e;

}

// determine address and port of each proxy

List streamHosts = determineStreamHostInfos(proxies);

// compute digest

String digest = Socks5Utils.createDigest(sessionID,

this.connection.getUser(), targetJID);

if (streamHosts.isEmpty()) {

// TODO: better exception message

throw discoveryException != null ? discoveryException

: new XMPPException(“no SOCKS5 proxies available”);

}

[rest of the method is unmodified]


The “trick” is done in the determineStreamHostInfos method which will add your local socks5 proxy host addresses and that is the reason that the direct socks5 negotiation may still succeed

Logged as SMACK-395

Can you attach this as a .patch file please so it can be attached to the Jira ticket.

Thank you.

Diff for the current trunk.
socks5_xmpp_error_501_abort_fix.patch.zip (832 Bytes)