When I try to send a file from Gabble 0.9.2-1 (and Empathy) in Debian to Pidgin 2.5.4 in Windows, each participant's UI claims to be waiting for the other, and I get this Gabble debug log (slightly anonymized, but the JID in googlemail.com is the recipient and the JID in pseudorandom.co.uk is me):
gabble/file-transfer-DEBUG: 1.259013e+09: gabble_ft_manager_handle_request: Requested outgoing channel with contact: firstname.lastname@example.org
gabble/jid-DEBUG: 1.259013e+09: gabble_signal_connect_weak: connecting to 0x9918098:presences-updated with context 0x9d3b690
gabble/file-transfer-DEBUG: 1.259013e+09: gabble_file_transfer_channel_constructor: New FT channel created: /org/freedesktop/Telepathy/Connection/gabble/jabber/_________40pseudorandom_2eco_2euk_2freptile/FileTransferChannel/0x993ba40 (contact: email@example.com, initiator: firstname.lastname@example.org, file: "________.mp3", size: 3906147)
gabble/file-transfer-DEBUG: 1.259013e+09: gabble_file_transfer_channel_offer_file: Offering file transfer to email@example.com/9B3E1067
wocky-DEBUG: 1.259013e+09: wocky_xmpp_writer_write_stanza: wocky-xmpp-writer.c:463: Writing xml: <iq to="firstname.lastname@example.org/9B3E1067" type="set" id="6559087454"><si id="1259012722-3645628678" profile="http://jabber.org/protocol/si/profile/file-transfer" xmlns="http://jabber.org/protocol/si"><feature xmlns="http://jabber.org/protocol/feature-neg"><x type="form" xmlns="jabber:x:data"><field var="stream-method" type="list-single"><option><value>http://jabber.org/protocol/bytestreams</value></option><option><value>http://jabber.org/protocol/ibb</value></option></field></x></feature><si-multiple xmlns="http://telepathy.freedesktop.org/xmpp/si-multiple"></si-multiple><file name="________.mp3" size="3906147" mime-type="audio/mpeg" hash="68aa471d424a89b3a3a07f592fdcc10f" date="2009-10-29T05:03:48Z" xmlns="http://jabber.org/protocol/si/profile/file-transfer"><desc/><range/></file></si></iq>.
gabble/jid-DEBUG: 1.259013e+09: gabble_signal_connect_weak: connecting to 0x993ba40:closed with context 0x9d87da0
gabble/file-transfer-DEBUG: 1.259013e+09: setup_local_socket: local socket /tmp/gabble-ft-H71gaG/ft-channel-0x993ba40
wocky-DEBUG: 1.259013e+09: wocky_xmpp_reader_push: wocky-xmpp-reader.c:603: Parsing chunk: <iq email@example.com/9B3E1067' firstname.lastname@example.org/reptile' type='result' id='6559087454'><si xmlns='http://jabber.org/protocol/si'><feature xmlns='http://jabber.org/protocol/feature-neg'><x type='submit' xmlns='jabber:x:data'><field var='stream-method'><value>http://jabber.org/protocol/bytestreams</value></field></x></feature></si></iq>
wocky-DEBUG: 1.259013e+09: _end_element_ns: wocky-xmpp-reader.c:525: Received stanza
wocky-DEBUG: 1.259013e+09: handle_iq_reply: wocky-porter.c:706: email@example.com/9B3E1067 attempts to spoof an IQ reply
gabble/connection-DEBUG: 1.259013e+09: connection_iq_unknown_cb: got unknown iq:
<iq xmlns='jabber:client' firstname.lastname@example.org/9B3E1067' email@example.com/reptile' type='result' id='6559087454'>
<x xmlns='jabber:x:data' type='submit'>
<field xmlns='jabber:x:data' var='stream-method'>
It looks as though either Wocky or the code in Gabble that interacts with Wocky is failing to match the sent message to the reply, perhaps because it has added an ID to the <si> and (wrongly?) expects the reply to have that ID, rather than the ID of the <iq>.
My status at the time was hidden, in case that's significant.
That message (spoofed reply) crops up when the recipient registered in the
handler does not match (as per wocky_strdiff) the 'from' attribute of the
The SI ID is weird, but wocky is actually finding a handler in its lookup table
so I don't think it's a contributory factor.
Just trying to reproduce the bug now to see if I can figure out what's going
on, file transfers from empathy -> libpurple working here (not tried a gtalk
The status is unlikely to be significant, but the exact content of the from/to
File transfers worked in both directions between gtalk-account-on-libpurple and jabber-account-on-telepathy-gabble
(In reply to comment #1)
> That message (spoofed reply) crops up when the recipient registered in the
> handler does not match (as per wocky_strdiff) the 'from' attribute of the
> IQ reply.
Aha! I think I know what's going on, then: some of the instances of the recipient's JID were in mixed-case, others weren't. You can probably reproduce this by typing in ExAmPlE@test.collabora.co.uk (or something) as your JID in Pidgin?
Right. We now normalise our copy of the recipient JID on the way out
and if the comparison fails on the way in, we normalise the sender and
try the comparison again.
(Actually a wocky bug since gabble no longer handles that logic itself)
Fix merged into wocky, Gabble updated.