Closed Bug 775977 Opened 12 years ago Closed 11 years ago

Google Talk (gtalk) disconnects if a contact uses iTeleport, because it sends invalid XML and Google unfortunately passes it through to clients

Categories

(Thunderbird :: Instant Messaging, defect)

15 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: nihaopaul, Unassigned)

References

()

Details

(Whiteboard: [GS])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20100101 Firefox/14.0
Build ID: 20120710123126

Steps to reproduce:

setup gtalk in thunderbird


Actual results:

setup went fine, however on connect it gets terminated, error logs the following:

Timestamp: 7/20/12 10:49:21 PM
Error: parse-fatal-error: XML Parsing Error: prefix must not be bound to one of the reserved namespace names
Location: about:blank
Line Number 1, Column 297275:
Source Code:
xmpp-session


Expected results:

stayed connected
Do you have an HTTP or HTTPS proxy configured in the system settings?
i do not use any proxy to connect or have any configured.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm hitting this on Linux x86_64 Earlybird (v17).  Platform --> ALL
OS: Mac OS X → All
Hardware: x86 → All
I got the same problem here, no proxy. I do use 2 step verification, but it does seem like that it connects successfully, but it disconnects immediately after connecting.
(In reply to or from comment #5)
> I got the same problem here, no proxy. I do use 2 step verification, but it
> does seem like that it connects successfully, but it disconnects immediately
> after connecting.

It indeed connects successfully (so this is not an issue related to authentication). The error and disconnection happens when we receive something that the gtalk server sends us immediately after we sent our vCard.
Contacts?
I've no idea what changed, but now it's working perfectly.
Daniel do you still have the issue ?
Yes, I do.

Also: my "Instant Messaging Status" window says "Error: received unexpected data" after I'm disconnected.

I suspect it has to do with an unexpected character / format in the metadata for one of my buddies -- maybe something that makes us trip over some XML parsing, or something.  (That would explain Comment 8 -- if the responsible buddy changes their status message etc., that could make the problem go away.)
Sounds like it could be good to take a look at the messages being received from the server.

You should be able to set purple.debug.loglevel to 1 to see the raw XMPP being sent to from the server in the error console. (Obviously there are some privacy concerns with this and the data should be anonymized before being posted anywhere.) If you'd prefer you could email it to Florian and/or I, instead of attaching it here too.

Thanks!
(In reply to Daniel Holbert [:dholbert] from comment #10)
> I suspect it has to do with an unexpected character / format in the metadata
> for one of my buddies

Ah yes -- Florian confirmed that over in https://bugzilla.instantbird.org/show_bug.cgi?id=1653#c2 (duplicate bug)

Cool -- I'll try toggling that log pref and report back.
(In reply to Daniel Holbert [:dholbert] from comment #12)
> (In reply to Daniel Holbert [:dholbert] from comment #10)
> > I suspect it has to do with an unexpected character / format in the metadata
> > for one of my buddies
> 
> Ah yes -- Florian confirmed that over in
> https://bugzilla.instantbird.org/show_bug.cgi?id=1653#c2 (duplicate bug)
> 
> Cool -- I'll try toggling that log pref and report back.

(In reply to comment https://bugzilla.instantbird.org/show_bug.cgi?id=1653#c2)
> Unfortunately the stanza we failed to parse isn't in the log, as we pretty
> print stanzas to the error console (ie they are printed after parsing).

Uhhh...this seems like this won't be helpful. :( Florian, maybe we can add a try catch here to print out the message received as well as the error?
(Darn, I was afraid of that)

I'm happy to try a thunderbird nightly after the Try/Catch (or otherwise-improved-logging) has landed.
(In reply to Patrick Cloke [:clokep] from comment #13)

> Uhhh...this seems like this won't be helpful. :( Florian, maybe we can add a
> try catch here to print out the message received as well as the error?

It's not as easy. We directly pass the nsIInputStream to the SAX parser.

I was talking to some XMPP folks a few minutes ago, discussing creating a plugin for an XMPP server, so that I can receive junk on demand through the XMPP connection so that I can have a way to improve the error logging, and check that it actually prints to the error console the string we can't parse.

FYI, we just tried sending some invalid characters through the connection and that didn't cause any issue. We suspect the gtalk server may be sending us some illegal XML like <fdsq xmlns:xml="…"/>
Depends on: 795296
(In reply to Daniel Holbert [:dholbert] from comment #14)
> (Darn, I was afraid of that)
> 
> I'm happy to try a thunderbird nightly after the Try/Catch (or
> otherwise-improved-logging) has landed.

I improved the logging in bug 795296. It would be awesome if you could show us the error reported to the Error Console with a tinderbox build from this changeset: https://tbpl.mozilla.org/?tree=Thunderbird-Trunk&rev=82d5e37e3a60
Sent the info from Error Console to Florian over email. (It's got my contacts' email addresses and other info in there, so I'd prefer not to post it publicly.)
Thanks Daniel!

This is the stanza causing the parse error in what Daniel emailed me:

<presence from="contact@gmail.com/iTeleport Connect.MAC.ABC12E42" to="user@gmail.com/Daily3F19472C" id="5">
  <status/>
  <nick xmlns="http://jabber.org/protocol/nick">server</nick>
  <type xmlns="">MAC</type>
  <id xmlns="">vnc</id>
  <xmlns:server xmlns="http://www.w3.org/2000/xmlns/"/>
  <server xmlns=""/>
  <show>offline</show>
  <invisible value="true"/>
  <priority>-127</priority>
  <name xmlns="">iTeleport Connect</name>
  <version xmlns="">6.0.0.2</version>
  <ssh-enabled xmlns="">false</ssh-enabled>
  <supports-dh xmlns="">true</supports-dh>
  <mac-username xmlns="">Administrator</mac-username>
  <vnc-version xmlns="">RFB 003.889</vnc-version>
  <os-version xmlns="">1138.51</os-version>
  <automanage-vnc xmlns="">false</automanage-vnc>
  <encryption-enabled xmlns="">true</encryption-enabled>
  <host-mac-address xmlns="">00:1f:a1:18:f1:3f</host-mac-address>
  <router-mac-address xmlns="">28:ac:82:b6:6e:f8</router-mac-address>
  <host-id xmlns="">A4752E4194721BB2667BB3B9391F24D8</host-id>
  <host-ips xmlns="">fe84::1;fd1a:d8b:9172:767b:20e:c2ef:fe93:f0af;fe84::22e:c2af:fea3:f03f;10.0.1.3;fe84::23f:5brf:fab9:2a31;10.0.1.158;fe84::22e:c2ff:fa13:f05f</host-ips>
  <x xmlns="vcard-temp:x:update">
    <photo>46747a1aa5c5aa9302f5ac8d26e3a38350306f83</photo>
  </x>
</presence>


(note: I've replaced a few random characters in each hexadecimal strings to ensure this doesn't contain personal data or valid IP addresses.)


It turns out the string we can't parse is:
<xmlns:server xmlns=\"http://www.w3.org/2000/xmlns/\"/>
(In reply to Florian Quèze [:florian] [:flo] from comment #18)
> <presence from="contact@gmail.com/iTeleport Connect.MAC.ABC12E42"
> to="user@gmail.com/Daily3F19472C" id="5">

For the record: this "iTeleport" gchat client isn't really for chatting -- it's a remote-desktop system, which happens to use Google chat as a presence mechanism. (to let you reach a machine that's e.g. behind a router)  (for reference, see http://www.iteleportmobile.com/support/faq )

So that's what it sends a bunch of metadata with username/vnc/router-mac-address info.

Also: it looks like other chat clients have had the exact same trouble that we're having with this --see: https://bugs.freedesktop.org/show_bug.cgi?id=33857#c0
...and another instance of this breaking another chat client:
http://blog.talkatone.com/2010/12/10/no-audio-incoming-calls-voip-vs-firewalls/
Quoting: "We are seriously tired of iTeleport inventing new ways of sending corrupted XML."

Heh.

Anyway -- looks like we need to be able to gracefully handle invalid XML from buggy gchat clients, by ignoring the whole <presence> block or something.
(In reply to Daniel Holbert [:dholbert] from comment #20)

> Anyway -- looks like we need to be able to gracefully handle invalid XML
> from buggy gchat clients, by ignoring the whole <presence> block or
> something.

Ignoring the whole received data would be less difficult, but as you noticed, we receive at the same time a lot of other useful presence stanzas, so it's not an option.

iTeleport is obviously broken and sending junk, but the Google Talk server should also not relay such invalid XML and disconnect the broken client right away. Unfortunately I don't have any contact at Google that could be likely to implement this change.
Summary: gtalk xmpp constant disconnect → Google Talk (gtalk) disconnects if a contact uses iTeleport
I expected this, but verified to be sure: ignoring the "fatal" parsing error doesn't work. The next time we call onDataAvailable on the parser, it throws NS_ERROR_UNEXPECTED.
Could someone confirm if the above GS thread is also a consequence of this bug? I am not 100% sure...
(In reply to Vincent (caméléon) from comment #23)
> Could someone confirm if the above GS thread is also a consequence of this
> bug? I am not 100% sure...

I can confirm. The error message " Error: parse-fatal-error: XML Parsing Error: prefix must not be bound to one of the reserved namespace names " that the user reported seeing in the error console is specific enough to be sure it's the same bug.

The user also mentions seeing "Warning: received presence stanza for unknown buddy myaccount@gmail.com/android_talk27... ". That's a different bug and I don't think it's been filed yet, but it's harmless (just noise in the error console).
For reference: http://productforums.google.com/d/topic/chat/nCB8nsjpXpg/discussion

No one responded from Google, however. I've posted another topic on it: http://productforums.google.com/d/topic/chat/G1jMHFajdyc/discussion maybe it'll have better luck.

I've also attempted to contact iTeleport about the issue.
I also have this problem. Waiting for a fix...
I've received a response from iTeleport that they could verify the issue (and concur that they are creating invalid XML). I've been told they have created a fix and are going through internal QA. If all their tests pass, it will be fixed in the next version (it is unclear to me about whether a new version will be released FOR this issue or not).

The reference ticket (which might only be viewable by me?) is http://support.iteleportmobile.com/tickets/41952
I've received word that a new version of iTeleport is being released and should be available by the end of next week. (And that my support ticket with them has been closed.)

I'd recommend closing this after they release a new version.
This is fixed in:
> iTeleport: VNC & RDP version 6.1.4 (via the App Store)
> iTeleport for Mac version 6.1.4 (via the App Store)
> 
> iTeleport Connect for Mac: 6.0.0.3*
> iTeleport Connect for Win: 6.0.0.3*
>
> * will be released as soon as the new app versions are made available via the App
> Store. This should happen within a week's time. 

I've never heard back from Google, but I'm going to close this as WONTFIX.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Summary: Google Talk (gtalk) disconnects if a contact uses iTeleport → Google Talk (gtalk) disconnects if a contact uses iTeleport, because it sends invalid XML and Google unfortunately passes it through to clients
You need to log in before you can comment on or make changes to this bug.