I’m running Spark 2.6.3 + Openfire 3.7.0 on FreeBSD 6.4-STABLE.
I have the Openfire file transfer proxy enabled. I have port 7777 opened on the firewall.
After reading some other posts, I have proxy.mydomain.com set in DNS to resolve to mydomain.com (the openfire server).
I’ve also set xmpp.proxy.externalip to the same IP.
Spark 2.5.8 works without any issues - when both clients have 2.5.8.
But in any combination, if either sending or receiving client is 2.6.0, 2.6.2, or 2.6.3, the transfer fails in one of 2 ways:
1. Periodically, it attempts to negociate...takes a while.....then errors.
2. Most frequently, it starts, shows the sender 100% and completes, but the receiver only gets 20-30% and it hangs...then errors.
Not sure if it’s related, but “Check for update” fails as well. Pops up the download box, but nothing happens. No download. Although periodically/sporatically, it’ll work.
Any assistance in getting file transfer working for us would be greatly appreciated. Thank you.
I have the same problem, please help.
Att.:
Alan
There was a change in Smack (a base library for Spark) some time ago that apparently causes this issue. We were unable to reproduce the situation during 2.6.3 development. One situation was fixed, but other than that we are on an open bug hunt.
The current assumption on the root cause is a failure of IBB as the fall back file transfer mode if the faster bytestream does not work.
I would like to ask you about some mor detailed information.
First of all: Are all clients member of one network? Can one IP reach the other IP directly or are VPN involved? Are there firewalls in the network line?
Second: If you start the file transfer with an active debugger, what is the send and received packages on both clients? Is the file transfer attempting a bytestream or IBB file transfer?
I appreciate the response.
Most all of our 120-some users are working remote from their homes (Cable/DSL). Most are not VPN, but occasionally have travelers using VPN back to HQ. The OF server is also remote - leased 3rd party server.
How/where do you turn on a debugger for the clients?
please go to the advance section of the login screen. There is a checkbox in the first tab “Start debugger on startup”. You can use the context menue to clear send and received. The file transfer has a start up session that either goes via IBB or sock5. I would assume that the clients in your network need IBB and that is somewhat faulty.
Can you please take a look in the debugger during an attempted file transfer?
Hope this helps. It’s beyond me.
http://pastebin.com/HEjNvseP
In this particular case, the file negociated successfully and told the sending client that it sent successfully and ended at 100%. The receiving client received 4%, where it locked up. We repeated both ways several times with same results.
Is there any easy way to use Smack 3.2.1 in Spark 2.6.3 (replace the pre-built in Smack)? I assume from what I’ve read here and on other threads that this is the root cause of the issue. But I’ve never done a custom Spark compile. Don’t mess with Java much.
I’m still having the issue and hoping there’s a way to resolve it. Thinking Smack update might be the solution. Has anyone done this? Any thoughts or help would be appreciated. Thanks.
It’s using the 3.2.1 code base
I am also having the same issue, I have this problem occuring on intranet to intranet clients as well as internet to intranet clients. I will run debugger once I’m at work tommorrow.
Please take alook at the debugger send/receive tab. If you see large chunks of text being send, your client went to IBB as transfer mode. There is a know bug.
Please check, if a 2.5.8 client can send to a 2.6.3 client and vice versa. And also, if it is bytestream or IBB. The 2.5.8 client is still available at http://community.igniterealtime.org/docs/DOC-2183
Please check, if the behaviour changes with OF providing proxy services.
I have been able to create a test environment that shows the bug, we will look into the details in the next week.
We have the following behaviour:
Setup VMWare based W7 client and VMware W2k3 server
OF 3.6.4 no Proxy enabled
2.6.3 to 2.6.3 works in bytestream without error in both directions on port 7777
OF 3.6.4 with Proxy enabled
w2k3 to w7 uses IBB, file transfer fails after less than 1 MB
W7 to W2k3 uses Bytestream via proxy on 7777 works.
Two seperate bugs.
Usage of proxy function fails
IBB transfer is buggy (possible Patch was publishd in the community)
I experimented with various verisons of Spark as well as various internet connections.
Sender Intranet 2.6.3 W7 Client to Reciever Internet 2.6.3 XP Client - Sender Status - Completed - Reciever Status Receiving - Sent IBB
Sender Intranet 2.6.3 W7 Client to Reciever Intranet 2.6.3 XP Client - Sender Status - Completed - Reciever Status - Receiving - Sent IBB
Sender Intranet 2.5.8 W7 Client to Reciever Intranet 2.6.3 XP Client - Sender Status - Completed - Reciever Status -Receiving - Sent Bytestreams
Sender Intranet 2.5.8 W7 Client to Reciever Internet 2.6.3 XP Client - Sender Status - Completed - Reciever Status - Receiving - Sent IBB
Sender Internet 2.6.3 XP Client to Reciever Intranet 2.5.8 W7 Client - Sender Status - Negotiating File transfer - Reciever Status - Negotiating connection stream - Trying Bytestreams
Sender Internet 2.5.8 XP Client to Reciever Intranet 2.5.8 W7 Client - Sender Status - Sent - Reciever Status - Received - IBB
Sender Intranet 2.5.8 XP Client to Reciever Intranet 2.5.8 W7 Client - Sender Status - Sent - Reciever Status - Received - Bytestreams
Hello!
This problem have in our office - Spark 2.6.3 / Openfire 3.7 - periodically unable to file/screenshot transfer.
Please Help.
Please wait for the 2.6.4 beta due soon. The file transfer in Spark and it’s base library Smack is unstable. We have an experimental fix at hand that needs some baking…