powered by Jive Software

Error when trying to connect to Google Talk (cannot parse presence extension)

Hello,

I am having a problem when connecting to the Google Talk service with smack from an android device(currently testing with asmack-android-8-4.0.3-SNAPSHOT-2014-08-04.jar)

I am not entirely sure, but the problem seems to be related (or even the same?) as described in this old thread that I found on a google search:

What happens (from my understanding, correct me if I’m wrong):

login/authenticate

announce my presence

retrieve contact entires

get presence packets for the contacts.

parse presence packets

—> Thats the point where I get the error:

org.jivesoftware.smack.packet.Presence cannot be cast to org.jivesoftware.smackx.vcardtemp.packet.VCard

also followed by a warning:

WARNING: Failed to parse extension packet in Presence packet.

So with my limited understanding of XMPP, I have the strong suspicion that Google uses an extension for presence that is either not supported by smack and/or not according to XMPP specification?

By the way, this is the presence packet:

<presence from="anderscorechat@gmail.com/50A80A35" to="anderscorechat@gmail.com/SmackAE0E4866"><priority>1</priority><c node="http://pidgin.im/" hash="sha-1" ver="71LAP/wlWGfun7j+Q4FCSSuAhQw=" xmlns="http://jabber.org/protocol/caps"/><x xmlns="vcard-temp:x:update"><photo/></x></presence>

I think especially part could be a problem?

**You can see the full debug logcat output with the XML stream here: **

http://pastebin.com/x8nQB2Ps

Hope this helps to find the root of the problem!

best regards

Ralf

—> Thats the point where I get the error:

I don’t think so. For more info about the warning, see SMACK-390. But let’s have look at the stacktrace:

  1. 08-07 14:08:23.990: E/ConnectionAdapterXMPP(4375): java.lang.ClassCastException: org.jivesoftware.smack.packet.Presence cannot be cast to org.jivesoftware.smackx.vcardtemp.packet.VCard
  2. 08-07 14:08:23.990: E/ConnectionAdapterXMPP(4375): at org.jivesoftware.smackx.vcardtemp.packet.VCard.doLoad(VCard.java:560)
  3. 08-07 14:08:23.990: E/ConnectionAdapterXMPP(4375): at org.jivesoftware.smackx.vcardtemp.packet.VCard.load(VCard.java:555)
  4. 08-07 14:08:23.990: E/ConnectionAdapterXMPP(4375): at com.anderscore.anderchat.service.ConnectionAdapterXMPP.fetchRosterEntries(Connec tionAdapterXMPP.java:174)

So the CCE is thrown in a call stack where your code calls VCard.load() and happens in the doLoad() method which reads

VCard result = (VCard) connection.createPacketCollectorAndSend(this).nextResultOrThrow();

this causes Smack to send the following stanza

From your log we see that the next received stanza is in fact a presence stanza

1

Now we could infer that this presence stanza get’s in fact collected by collector and is returned as result of nextResultOrThrow(). This match which the CCE, which says that Presence can not be cast to VCard.

But I have no idea how the collector would collect the presence stanza, since the collector only collects iq stanzas.

Furthermore I don’t see "WARNING: Failed to parse extension packet in Presence packet." in the pastebin log.

What is at com.anderscore.anderchat.service.ConnectionAdapterXMPP.fetchRosterEntries(Connec tionAdapterXMPP.java:174)?

It’s there:

  1. 08-07 14:08:24.010: W/PacketParserUtils(4375): Failed to parse extension packet in Presence packet.
    (just realized it looks a little different than what I posted, dont know where I got that from)

Ok ok ok I just realized a dumb mistake: I use my own IQReplyFilter subclass now (as a temporary workaround for the IQReplyFilter bug) —> in this method accept always returns true to circumvent the “fromFilter” check.

BUT I just noticed this is also the place everything is filtered out that is not an IQ packet and has not the correct ID set. facepalm

So disabling that leads obviously to all sorts of ugly mess (like the CCE by collecting a wrong packet)

Your comment helped me see that! (I haven’t tested it yet but that MUST be it)

Thanks (and sorry for the unnecessary confusion)

You want to match at least the packet id in your custom IQReplyFilter (and that it’s an iq stanza). Note that leaving out the from verification makes you vulernable to spoofed IQ replies. That’s where you have to decide if you are willing to take that risk.

Yes I am aware of that — it’s just intended as a very temporary workaround and I will upgrade to 4.1.0 snapshot soon anyways… :slight_smile: