File transfer error - no stream, files end up with 0 kb

Hi there,

I’‘m having a problem with file transfers from inside LAN to WAN or vice versa. Everything works fine, but after accepting the file transfer there’‘s no stream and the files are saved with 0 kb. I’‘m using Spark and the newest wildfire beta with the parameter xmpp.proxy.externalip set to my external IP address (also tried the xmpp.domain). Nat and firewall rules for port tcp 7777 are in place, clients from the outside are able to connect, the firewall log doesn’'t reveal anything strange.

I guess this is a known problem, maybe I’'m missing something important.

Anyone any ideas…?

There was a problem with beta 2 but it wasn’'t files coming up with 0 kb, they were coming up corrupted. Are you seeing anything in your log files?

Thanks,

Alex

Hi Alex,

I’'ve set the xmpp.proxy.externalip to my WAN IP address and restarted wildfire.

Then, after quite some testing I found the following:

  • WAN client can transfer files inbound to a LAN client (slow speed around 20 KB/s, but might be normal).

  • Initial negotiation seems to be running on port 7777, the actual data transfer goes on port 5222 via the proxy.

Now the strange behavior:

  • Outband LAN -> WAN transfers doesn’'t work at all.

  • no log entries in wildfire whatsoever, even with debugging enabled.

  • no firewall log entries of possible blocked traffic.

  • the firewall states show that the LAN client was connected to IP 192.168.2.101 a couple of times (which doesn’'t exist on my LAN anyway??)

  • after that it kept on connecting to my WAN address (according to xmpp.proxy.externalip parameter, I guess).

Shouldn’'t it connect to the proxy server directly in this case? In my network it makes no sense to connect to the WAN address, its on a different machine.

Maybe using a dns name and pointing the internal dns to the proxy? Then it should work with xmpp.domain.

I hope you can brew some usefull medicine with this…

Cheers and thanks

The machines internal to your network need to know how to connect to the proxy just as they need to know how to connect to the server when they logon… You likely have an internal DNS address for this? The client will also attempt to connect to the initiator of the file transfer, likely why you are seeing the connections to 192.168.2.101. If all of this fails then the file will be transfered over the XMPP connection… 5222.

Hope that sheds some light on things,

Alex

Alright, as far as my understanding of the streaming part goes:

A sends file to B:

  1. A tries to connect to B directly p2p, which works when both clients are on the same network (thats the 192.168.2.101 LAN address of the external client?)

  2. If it fails, A connects to the wildfire proxy server that is specified in xmpp.proxy.externalip on port 7777 to negotiate

  3. Proxy picks it up and sends it to client B.

In this example it doesn’'t matter, whether A or B are internal or external.

I guess in my case the xmpp.proxy.externalip must be a domain name which has to be resolved by the internal DNS server for the internal client. Same as xmpp.domain would be ok. The external client is routed from WAN via inbound NAT to wildfire (5222 and 7777). This way both clients, internal and external, find their way to the wildfire machine via dns. Providing the WAN address, or “external ip” won’'t work for internal clients to stream a file to an external client on the WAN.

Sorry for bothering you about network stuff, I thought it could possibly be a bug of some sort.

Maybe it’'s usefull for someone else.

Anyways, I’'ll come back with the results as soon as I tested the beast again.

Thanks a lot,

Dick

Problem solved.

You have to set the xmpp.proxy.externalip to subdomain.domain.tld and resolve it with your internal dns server.

What doesn’'t work is “domain.tld” without a subdomain name.

Because my xmpp.domain is set to domain.tld (nice short jids) I ended up with this specific problem.

So in my case xmpp.proxy.externalip=xmpp.domain didn’'t work.

Cheers,

Dick