Bug 50491 - Google Talk file transfers fail
Summary: Google Talk file transfers fail
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
: 29466 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-05-29 23:50 UTC by Caleb Langeslag
Modified: 2019-12-03 19:57 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Empathy-debugger log (33.66 KB, text/plain)
2012-05-29 23:50 UTC, Caleb Langeslag
Details

Description Caleb Langeslag 2012-05-29 23:50:14 UTC
Created attachment 62254 [details]
Empathy-debugger log

When trying to do a file transfer from the official Google Talk desktop client on Windows to a user with Empathy, will fail. 

When a file transfer request is initiated, there will be a prompt from Empathy to accept the request, then I click Accept, then it will say "Waiting for the other participant's response" for about 20 seconds. While that message is displaying on Empathy, the Google Talk side will show a progress bar shifting left-to-right (not indicating any progress), and then fail. On the Empathy side it will say "Error while trying to transfer the file", and on the GTalk side it will say "(User) declined the offer".

I am able to do file transfer just fine between Pidgin and Empathy (as it's probably not using XEP-0234, or something).

I cannot determine the appropriate version of Telepathy-gabble installed, based upon the version options provided.
 - In 'Help > About', the version of Empathy is 3.4.1
 - The version of telepathy-gabble installed is '0.16.0-0ubuntu1', but there is no option for "0.16" in the 'version' selection, if correct.
 - This is on Ubuntu 12.04 LTS (64-bit)
Comment 1 Danielle Madeley 2012-05-30 21:51:35 UTC
*** Bug 29466 has been marked as a duplicate of this bug. ***
Comment 2 Simon McVittie 2012-05-31 08:22:48 UTC
(In reply to comment #0)
> When trying to do a file transfer from the official Google Talk desktop client
> on Windows to a user with Empathy, will fail. 

This isn't actually XEP-0234: it's a different Jingle-based thing, (re)invented by Google ("Jingle sharing"). We implement it to be interoperable with GTalk.

We don't implement XEP-0234 yet.

> I am able to do file transfer just fine between Pidgin and Empathy (as it's
> probably not using XEP-0234, or something).

This is likely to be XEP-0096 (Stream Initiation file transfer), which is implemented in many XMPP clients, but not Google Talk.
Comment 3 Simon McVittie 2012-05-31 08:28:42 UTC
We send:

* iq xmlns='jabber:client' type='set' to='takyoji@gmail.com/Talk.v104CACB3101' id='300418955850'
    * session xmlns='http://www.google.com/session' initiator='takyoji@gmail.com/Talk.v104CACB3101' id='1981029369' type='transport-info'
        * transport xmlns='http://www.google.com/transport/p2p'
            * candidate address='2602:100:18b1:6e2c:21f:c6ff:fe3b:d0db' port='35139' username='/PDjJ6wI4bEMm5DF' password='' preference='0.000015' protocol='udp' type='local' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='2602:100:18b1:6e2c:35c1:5a15:90b:b2d6' port='40215' username='LE1A+N7fTnngWW1N' password='' preference='0.000015' protocol='udp' type='local' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='192.168.1.145' port='49693' username='mXnXVnPGldPwBen1' password='' preference='0.000015' protocol='udp' type='local' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='24.177.110.44' port='49693' username='I4dpltK6IB950hkJ' password='' preference='0.000000' protocol='udp' type='stun' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='209.85.225.127' port='19305' username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp' type='relay' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='209.85.225.127' port='19305' username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp' type='relay' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='209.85.225.127' port='19305' username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp' type='relay' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='209.85.225.127' port='19305' username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp' type='relay' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='24.177.110.44' port='35139' username='QYETj/Nd/FuUvoXT' password='' preference='0.000000' protocol='udp' type='stun' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='24.177.110.44' port='40215' username='uzG+Rh/JfEQHcder' password='' preference='0.000000' protocol='udp' type='stun' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='209.85.225.127' port='443' username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp' type='relay' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='209.85.225.127' port='443' username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp' type='relay' component='1' network='0' generation='0' name='gabble-1'
            * candidate address='209.85.225.127' port='443' username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp' type='relay' component='1' network='0' generation='0' name='gabble-1'

GTalk replies:

    * error type='modify'
        * bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
        * text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
            "candidate has address of zero"

Since none of your candidates actually have 0 in their address, my guess is that what it really means is that GTalk doesn't support IPv6, and is mis-parsing the two IPv6 candidates at the top as an IPv4 address of 0.0.0.0.

If I'm right, then we could maybe work around this by omitting IPv6 candidates when using the http://www.google.com/transport/p2p dialect of Jingle?
Comment 4 Caleb Langeslag 2012-07-05 20:58:04 UTC
(In reply to comment #3)
> We send:
> 
> * iq xmlns='jabber:client' type='set' to='takyoji@gmail.com/Talk.v104CACB3101'
> id='300418955850'
>     * session xmlns='http://www.google.com/session'
> initiator='takyoji@gmail.com/Talk.v104CACB3101' id='1981029369'
> type='transport-info'
>         * transport xmlns='http://www.google.com/transport/p2p'
>             * candidate address='2602:100:18b1:6e2c:21f:c6ff:fe3b:d0db'
> port='35139' username='/PDjJ6wI4bEMm5DF' password='' preference='0.000015'
> protocol='udp' type='local' component='1' network='0' generation='0'
> name='gabble-1'
>             * candidate address='2602:100:18b1:6e2c:35c1:5a15:90b:b2d6'
> port='40215' username='LE1A+N7fTnngWW1N' password='' preference='0.000015'
> protocol='udp' type='local' component='1' network='0' generation='0'
> name='gabble-1'
>             * candidate address='192.168.1.145' port='49693'
> username='mXnXVnPGldPwBen1' password='' preference='0.000015' protocol='udp'
> type='local' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='24.177.110.44' port='49693'
> username='I4dpltK6IB950hkJ' password='' preference='0.000000' protocol='udp'
> type='stun' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='209.85.225.127' port='19305'
> username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp'
> type='relay' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='209.85.225.127' port='19305'
> username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp'
> type='relay' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='209.85.225.127' port='19305'
> username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp'
> type='relay' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='209.85.225.127' port='19305'
> username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp'
> type='relay' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='24.177.110.44' port='35139'
> username='QYETj/Nd/FuUvoXT' password='' preference='0.000000' protocol='udp'
> type='stun' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='24.177.110.44' port='40215'
> username='uzG+Rh/JfEQHcder' password='' preference='0.000000' protocol='udp'
> type='stun' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='209.85.225.127' port='443'
> username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp'
> type='relay' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='209.85.225.127' port='443'
> username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp'
> type='relay' component='1' network='0' generation='0' name='gabble-1'
>             * candidate address='209.85.225.127' port='443'
> username='B9ygfBQmeLS4KZy7' password='' preference='0.000000' protocol='udp'
> type='relay' component='1' network='0' generation='0' name='gabble-1'
> 
> GTalk replies:
> 
>     * error type='modify'
>         * bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
>         * text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
>             "candidate has address of zero"
> 
> Since none of your candidates actually have 0 in their address, my guess is
> that what it really means is that GTalk doesn't support IPv6, and is
> mis-parsing the two IPv6 candidates at the top as an IPv4 address of 0.0.0.0.
> 
> If I'm right, then we could maybe work around this by omitting IPv6 candidates
> when using the http://www.google.com/transport/p2p dialect of Jingle?

Certainly worth a shot, since there doesn't seem to be any other suggestions. Perhaps have a checkbox for enabling/disabling the workaround as well, although I'm not sure where an appropriate location for said checkbox would be.
Comment 5 GitLab Migration User 2019-12-03 19:57:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/230.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.