Opened 10 years ago

Closed 10 years ago

Last modified 6 years ago

#1768 closed defect (fixed)

File transfer doesn't work with XMPP very often

Reported by: zerwas Owned by: nwalp
Milestone: 2.3.1 Component: XMPP
Version: 2.0.2 Keywords:


File transfer does not not work with Miranda (Windows), often Trillian and Kopete. "not work" means, that it does not start or get abrupted before it starts. Perhaps this is due to a bad implementation of JEP-0096?

Change History (28)

comment:1 Changed 10 years ago by zerwas

What i have tested and experienced so far:

Jabbin to

-> Pidgin OK

-> Kopete FALSE -- "Unable to negotiate transfer. This can happen if the contact did not understand our request, or if the contact is offline."

Pidgin to

-> Kopete FALSE -- "Could not connect to host zerberus@…/Home701842CF"

-> Jabbin FALSE -- "Unable to accept the file. Perhaps the sender has cancelled the request." Second attempt: Pidgin CRASHES

-> Pidgin FALSE -- "Stopped"

Kopete to

-> Pidgin OK

Psi to -> Psi OK

comment:2 Changed 10 years ago by bernhard


I know a similar problem from Adium and since they both use libpurple, they have likely the same reason.

The problem is that libpurple only sends (on outgoing FT) or uses (on incoming FT) one IP Address.

An Example:

Suppose you have two hosts, both are MultiHomed? (e.g. are connected to the Internet as well as to a local LAN) Lets assume the following Setup:


  • Internet IP is
  • and the LAN IP is:
  • Client: Adium


  • Internet IP is
  • and the LAN IP is:
  • Client: PSI

On filetransfer Host2->Host1, Psi will send the following Message:

<iq type="set" to="host1@jabber/Adium" id="...." >
<query xmlns="" mode="tcp" sid="" >
<streamhost port="8010" host="" jid="host2@jabber" />
<streamhost port="8010" host="" jid="host2@jabber" />
<streamhost port="6565" host="" jid="" >
<proxy xmlns=""/>
<fast xmlns=""/>

Note that it includes 3 IPs (the LAN and Internet, as well as an StreamingProxy?) Now the sane thing to do would be to see which of those ips we can connect to and the transfer the file.

What libpurble does is: it just uses the first IP (the internal one) and of course Host1 does not have a Route to, so the File Transfer fails

Now, even WORSE:

On filetransfer Host1->Host2, Adium will often send the following Message:

<iq type="set" to="host2@jabber/Adium" id="...." >
<query xmlns="" mode="tcp" sid="" >
<streamhost port="8010" host="" jid="host1@jabber" />
<proxy xmlns=""/>
<fast xmlns=""/>

Note that, not only does libpurple send only one IP even though the Host is MultiHomed?, the one IP it sends is one Host2 doesn't have a Route to. So Host2 has no chance at all to establish a connection for filetransfer to Host1 and the transfer failes as soon as it recieves the expected ICMP Error.

Greetings, Bernhard

comment:3 Changed 10 years ago by bernhard

P.S.: I don't think this is a minor problem, it should be upgraded to major bug !

P.P.S.: in the second example, it should of course state 'to='host2@jabber/Psi"'.

comment:4 Changed 10 years ago by hdh

When a gtalk/Pidgin buddy send me a file, my also try to connect to his internal address. This is a major stopper for me in converting him to XMPP.

I think this one and #116 should some how be linked together.

comment:5 Changed 10 years ago by skliarieh

Adium (which also uses libpurple) has similar file transfer problems, described in following bug report:

Is there libpurple-specific bug report on this? How can it be added?

comment:6 Changed 10 years ago by kiddo

adding my vote to this. I'm stuck at not using pidgin for anything jabber until this can work through firewalls.

Sorry to spam your inboxes, I just couldn't find any other way to subscribe myself to this bug report, other than commenting on it.

comment:7 Changed 10 years ago by seanegan

  • Component changed from libpurple to XMPP
  • Owner set to nwalp

comment:8 Changed 10 years ago by zerwas

Let me say that: Most filetransfer problems are results of wrong configuration. Now that everybody i know has Pidgin and i told them how to set it up right, everything works fine. Perhaps it could help some people (and could get anywhere on where more people can see it (FAQ?))

  • Port deallocation
    • Make sure that the right port (8010 TCP) is opened in your firewall and/or router (if exists) for the IP address of the computer on which Pidgin runs
  • Port usage
    1. Tools -> Settings -> Network
    2. "Specify the port range manually" (sounds something like this): Enter "8010" in both fields
  • Verify the IP address that Pidgin is using
    1. Tools -> Settings -> Network
    2. Look at the IP address that is shown at "Public IP" - you can find your public IP at
      • If it is right: You are done, transfer should work if both sides has set up their clients
      • If it is wrong: Enter, restart Pidgin and perhaps wait a few minutes until the correct IP address appears

comment:9 Changed 10 years ago by kiddo

No. Or reopen my ticket #1206.

If you have to do all this configuration (easy for geeks that know their router), you failed. It was acceptable back in 1997.

My ticket was about making it work automagically (and believe me, it *does* work automagically on gajim or psi or google talk, without having to forward ports) through jingle and proxies. Please don't consider this a RTFM issue.

On a more rational note, also think of all the people behind networks which they do not control/cannot administer. For example, people behind a NAT in a school network or lan party or library or whatever. Your trick falls apart in that case, AFAIK.

comment:10 Changed 10 years ago by pedro-kun

I really think the problem is the one bernhard mentioned. And I must agree when he says that this should be considered a major bug.

I can transfer files between computers on my LAN, but when I try to transfer them to another person located somewhere other than my house, the transfer never gets to begin.

major bug indeed

comment:11 Changed 10 years ago by galt

If you want this issue resolved, you can help by testing my patch #3730, and give some feedback :)

comment:12 Changed 10 years ago by datallah@…

  • Milestone set to 2.3.0
  • Resolution set to fixed
  • Status changed from new to closed

(In 5727e9151416612d63670c49ed8982d3bb1704b4) Implement more of XEP-0065 to support sending files through a proxy. To avoid adding strings this close to a release, it only supports using a proxy that is discovered from the server, but we'll include an account option to manually specify a ft proxy in the next release. Lots of this is based on a patch from galt - Fixes #3730, #116, #1768

comment:13 Changed 9 years ago by kiddo

afaik, gtalk uses no proxies. Will you folks make it work through jingle or something like that? Or should pidgin use a hardcoded list of proxies when no proxy could be autodetected and when the user has set no proxy manually?

comment:14 Changed 9 years ago by galt

kiddo: 2.3.1 will have a field for setting the proxy manually, with as the default. I think you'd have to enable it manually though (but I hope not). Ideally it should probably detect when the server has no proxy for us, or just send whatever proxies the server gives us plus a default one, and have the other side pick whatever works, with priority to whatever the server gave us.

comment:15 Changed 9 years ago by skliarieh

I tried to send a file from pidgin 2.3.0 to gtalk, and the sending got stuck in "Waiting for transfer to begin". On Gtalk side, nothing happened.

When I tried to send a file from gtalk to pidgin 2.3.0, I have got following message in gtalk: You cannot send files because Arie @ Work is using chat in Gmail or is using another chat program.

Both gtalk and pidgin 2.3.0 are in the same local network.

comment:16 Changed 9 years ago by galt

skliarieh: GTalk uses a different method for file transfers. Pidgin does not detect that the receiver is using the GTalk client, so as far as it knows, the other side never responds. The GTalk client does detect that the receiver is not using a GTalk client, hence the message that you are getting in the second instance.

This is a GTalk specific issue so it's probably not relevant to this ticket. From a quick search, #3975 seems to match the issue that you encountered.

comment:17 Changed 9 years ago by skliarieh

I understand. Can pidgin, at least, detect whether recevier is using file-transfer-compatible client and display informative error message?

comment:18 Changed 9 years ago by galt

skliarieh: It's definitely possible in one way or another, but from what I know some developers are working on implementing Google's file transfer method, along with other things, so there is probably no point of doing it.

You could figure this out manually though, simply by hovering the mouse cursor over the buddy in question. In the tooltip that will appear, there will be a line that says "Status($RESOURCE): $STATUS", where $RESOURCE is the resource used by that buddy. If the buddy is using the GTalk client or GMail, it will be clear from the resource string.

This way you can tell what client they are using even without trying to send a file.

comment:19 Changed 9 years ago by skliarieh

galt: users of pidgin would definitely appreciate informative message about inability to send file (or greyed-out "Send File" option), instead of wondering whether file transfer was never accepted by recepient, or there was an technical problem.

IMHO, this is very simple change, but it will make pidge more user-friendlier, which is always good thing.

Even when Google's file transfer method will be implemented, there would remain other networks, that pidgin can not do file transfer with. Thus, the recipient-file-transfer-ability check, would always be useful.

comment:20 Changed 8 years ago by AZ

Well... I'm experiencing some kind of difficulty when using pidgin on a multihomed computer with multiple jabber accounts. Imagine..

[Host] --- CompanyNetwork? --- CompanyJabberServer?

\------- some VPN --- some JabberServer? in VPN

The other hosts in the companies network cannot contact any host by its vpn ip (since that is private) and the vpn hosts cannot contact any company internal ip (since that is priate too).

So pidgin on [Host] does not known which IP to use for file transfer. If I exchange a file with somebody on the company network, I need the company internal ip. If i exchange a file with somebody on the vpn, I need the vpn ip.

Even if I configure pidgin accordingly to that guideline in comment #8, there is no ip i can give pidgin for static usage. Funny but even using a file transfer proxy does not help here.

comment:21 Changed 8 years ago by datallah

AZ: You should be able to use a file transfer proxy that both parties can connect to successfully. Alternatively, you should be able to use In-Band-Bytestreams if you have a new enough version of pidgin (>= 2.6.0).

Your issues aren't related to this bug (and don't appear to actually be a bug at all), you probably should use the support mailing list for this type of question instead of commenting on old tickets.

comment:22 Changed 8 years ago by AZ

Thanks a lot.

comment:23 Changed 6 years ago by kip

It's hard to believe that something so fundamental has still been broken for four years now. I am using Pidgin 2.9.0 (libpurple 2.9.0) and almost every file transfer to another XMPP user stalls and aborts part way through. I have tried different file transfer proxy servers and currently use, to no avail. The client I am most often sending or receiving files to is also another Pidgin client of the same version.

I don't have a firewall. I am behind an NAT, but it has UPnP enabled both on the router and in Pidgin. My public IP is correctly identified in Tools -> Settings -> Network.

This bug is clearly not fixed and should never have been closed.

comment:24 Changed 6 years ago by datallah

kip: It sounds like you're experiencing a different issue, this particular ticket is about a set of issues that have been addressed.

Feel free to open a new ticket for your issue, including debug logs.

comment:25 Changed 6 years ago by kip

datallah: I can see that suspected causes have been discussed, but the original reporter's description matches with my problem which still occurs. The only difference is that I have seen the same problem happen Pidgin to Pidgin, and not just Pidgin to a different client's implementation.

comment:26 Changed 6 years ago by datallah

Despite it seeming similar to you (mostly because the original description is really generic), it is a different issue and nothing useful can happen until you create a new ticket that includes debug logs.

comment:27 Changed 6 years ago by kip

datallah: I will collect the necessary debug logs and then create a new ticket.

comment:28 Changed 6 years ago by kip

datallah: Ok, here you go:

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!