Bug: Direct Socks5 connections are not available when using GTALK

Smack Smack Dev
1

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
2

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.

3

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.

4

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.

5

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

6

Logged as SMACK-395

7

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

Thank you.

8

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