Opened 6 years ago

Closed 5 years ago

#6869 closed defect (fixed)

FT failes because S5B proxy is outruled on gajim startup

Reported by: Flow_ Owned by:
Priority: normal Milestone:
Component: xmpppy Version: hg
Severity: normal Keywords: bytestream, ft,
Cc: Blocked By:
Blocking: OS: Unix


<!-- In --> <iq id="AJDYING3X5VL7CPB" to="flo@xxx/flo-pc" from="flo-android@xxx/GTalkSMS" type="result"> <si xmlns=""> <feature xmlns=""> <x xmlns="jabber:x:data" type="submit"> <field var="stream-method"> <value></value> </field> </x> </feature> </si> </iq>

<!-- Out --> <iq xmlns="jabber:client" to="flo-android@xxx/GTalkSMS" type="set" id="id_AJDYING3X5VL7CPB"> <query xmlns="" mode="plain" sid="AJDYING3X5VL7CPB"> <streamhost host="" jid="flo@xxx/flo-pc" port="28011" /> </query> </iq>

"Use file transfer proxies" is checked and I also configured the socks5 proxy of my xmpp server (openfire) via ACE. But still Gajim does only tell the other side about the local ip as streamhost. Using the latest hg version of gajim. The other direction works fine. The client (smack-based) seems to detect the socks5 proxy of my server and is therefore able to send files to gajim.

Change History (15)

comment:1 Changed 6 years ago by asterix

  • Status changed from new to needinfo

Gajim tests proxies when starting. Maybe there is a problem in this test or in your proxy. Could you run "gajim -l gajim.c.proxy65_manager=DEBUG" and show me the result please?

comment:2 Changed 6 years ago by Flow_

Hmm this looks right:

22:33:52 (I) gajim.c.proxy65_manager start resolving 22:33:52 (D) gajim.c.proxy65_manager Receiver Connecting to 22:33:52 (D) gajim.c.proxy65_manager Receiver connected to 22:33:52 (D) gajim.c.proxy65_manager Receiver authenticating to

Could it be that the other side does not declare support for proxy FTs?

comment:3 Changed 6 years ago by asterix

  • Status changed from needinfo to new

no it's not linked to the other side. The next step should be :

Receiver authenticated to

So there is maybe a problem with your proxy. Could this be possible?

comment:4 Changed 6 years ago by Flow_

I would rule that option out, as the smack-based client is able to send files via this proxy (

But I see the following errors on the openfire log

2011.04.28 22:36:34 Error processing file transfer proxy connection Illegal proxy transfer

at org.jivesoftware.openfire.filetransfer.proxy.ProxyConnectionManager?.processConnection(ProxyConnectionManager?.java:207) at org.jivesoftware.openfire.filetransfer.proxy.ProxyConnectionManager?.access$200(ProxyConnectionManager?.java:57) at org.jivesoftware.openfire.filetransfer.proxy.ProxyConnectionManager?$1$ at java.util.concurrent.Executors$RunnableAdapter?.call( at java.util.concurrent.FutureTask?$Sync.innerRun(FutureTask?.java:303) at java.util.concurrent.FutureTask?.run(FutureTask?.java:138) at java.util.concurrent.ThreadPoolExecutor?$Worker.runTask(ThreadPoolExecutor?.java:886) at java.util.concurrent.ThreadPoolExecutor?$ at

Have to check if its related to this.

comment:5 Changed 6 years ago by Flow_

Well, the Openfire Exceptions IS related to this problem. Looking at, it is basically an Unauthorized Error. Anything that gajim is doing different than other clients? Anything that openfire is expecting different (order, format, etc.) than other servers? I am gonna double check that other clients are able to use the proxy.

comment:6 Changed 5 years ago by asterix

  • Resolution set to invalid
  • Status changed from new to closed

if you want to debug what is sent to authenticate to your proxy component, you can add some print in _get_sha1_auth function in src/common/

In any case, there is no reason for your server to crash and not reply to Gajim (with an error if needed).

I close the ticket 'cause I don't think it's Gajim related, but if I'm wrong, reopen it.

comment:7 Changed 5 years ago by Flow_

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Summary changed from FT failes because streamhost is set to local ip although FT proxies are enabled to FT failes because S5B proxy is outruled on gajim startup

Problem: Gajim tests the bytestreams proxies on startup, whereas openfire only allows connection to his very own bytestream proxies when an actual file transfer negotiation is going on.

This can fixed on openfire's side by setting an undocumented value:


XEP-65 is not unambiguous about this. I could imagine that gajim's behaviour, testing the bytestream proxies on start-up without an actual transfer, could lead to further problems in the feature.

I reopened the issue as I'd like to hear the gajim dev's opinion about this and to raise awareness of the issue.

comment:8 Changed 5 years ago by asterix

What the best? not test proxies and maybe have a not working proxy and transfer fails, or test proxies and with openfire server with this option enabled, fail to use this proxy? I don't know ...

comment:9 Changed 5 years ago by Flow_

Why not blacklist proxies when they fail on an actual filetransfer (timeout or rejection) and proceed to the next possible proxy with IBB as last resort? What was your intention that the proxies have to be tested on gajim startup?

After reading XEP-65 again I come more and more to the conclusion that the assumptions openfire makes are right and improve security. Therefore setting the flag to flase is more a work-around.

comment:10 Changed 5 years ago by asterix

once a proxy fails, user have to re-send the file. Gajim cannot automatically choose another proxy, negociation is already done on the proxy.

We did that because as the time we did, we found some proxy that didn't work, we can disco them, but transfer doesn't work. We wanted to test proxies to remove them and not use them.

comment:11 Changed 5 years ago by Flow_

Sorry but I don't get it: Why can't gajim just restart stream negotiation (from the very beginning if you will) with a new proxy?

comment:12 Changed 5 years ago by asterix

because recipient will have to re-accept file

comment:13 Changed 5 years ago by Flow_

Are you sure that you can't just reuse the streamID and initiate a new stream negotiation? This way there will be no further user interaction needed to provide fall-back. This is what smack does (S5B/IBB fall-back). Also XEP-96 eplicitly states that there MUST be support for fall-back. Which is there stated as S5B and IBB, but I see no reason why the fall-back could not also be another S5B transfer (chaining them and using IBB as last resort).

comment:14 Changed 5 years ago by asterix

it's not what that mean. Gajim (in 0.15 version) supports S5B and IBB, but that's not the problem. Once a method is choosen, the protocol doesn't let you go back and use another streamhost. Even Jingle FT, which lets you fallback to IBB if S5B fails, doesn't let you choose another proxy if one fails. Once a proxy is choosen, we go for it. The fallback is here is none on the parties can conenct to the other or to other's proxies. So once a brocken proxy is choosen, transfer will fail.

comment:15 Changed 5 years ago by asterix

  • Resolution set to fixed
  • Status changed from reopened to closed

there is now a test_ft_proxies_on_startup option.

Note: See TracTickets for help on using tickets.