File transfer slow in LAN, strange log entries connecting to hostname

Hello,

I’m facing an issue for some time now (more since initially setting up openfire here), which I’m unable to solve, maybe someone of you has a hint or an idea, what’s causing this.

About the environment:
We’re using an openfire server installation in a VM on a linux host machine (VM having a static IP).
A second host machine hosts in VMs a Windows server as domain controller (IN-DC).
The DC’s DNS provides the entry for our openfire server, called in-openfire.
User management and authentification is done via LDAP against the AD, but I think this is optional information here.
The openfire system is used just internally in the LAN here.

About the problem:
When sending files over XMPP (Clients used Pidgin and Gajim), the same thing happens: The file transfer is slow, about 500 - 600 kB/s in a Gigabit LAN environment (performance tested with iperf3, netto reachable speed should be around 72 MB/s).
In my understanding in which way XMPP file transfer works, I’m suspecting that the fallback transfer protocoll (IBB) and not binary stream is used.
Trying to investigate this problem further, I found the following entrys in warn.log, which seem to be the cause for this:

session due to incorrect hostname in stream header. Host: in-openfire. Connection: org.jivesoftware.openfire.net.SocketConnection@18c3f1e socket: Socket[addr=/127.0.0.1,port=52542,localport=5269] session: null
2020.04.16 15:20:54 org.jivesoftware.openfire.net.SocketReader - Closing session due to incorrect hostname in stream header. Host: in-openfire. Connection: org.jivesoftware.openfire.net.SocketConnection@3cfa026f socket: Socket[addr=/127.0.0.1,port=52544,localport=5269] session: null
2020.04.16 15:20:54 org.jivesoftware.openfire.server.ServerDialback[Acting as Originating Server: Create Outgoing Session from: in-openfire.ad.ingeneers.de to RS at: in-openfire (port: 5269)] - Unable to create a new outgoing session
2020.04.16 15:20:54 org.jivesoftware.openfire.session.LocalOutgoingServerSession[Create outgoing session for: in-openfire.ad.ingeneers.de to in-openfire] - Unable to create a new session: Dialback (as a fallback) failed.
2020.04.16 15:20:54 org.jivesoftware.openfire.session.LocalOutgoingServerSession[Authenticate local domain: 'in-openfire.ad.ingeneers.de' to remote domain: 'in-openfire'] - Unable to authenticate: Fail to create new session.
2020.04.16 15:23:59 org.jivesoftware.openfire.net.SocketReader - Closing session due to incorrect hostname in stream header. Host: in-openfire. Connection: org.jivesoftware.openfire.net.SocketConnection@663210d7 socket: Socket[addr=/127.0.0.1,port=52546,localport=5269] session: null
2020.04.16 15:23:59 org.jivesoftware.openfire.server.ServerDialback[Acting as Originating Server: Create Outgoing Session from: in-openfire.ad.ingeneers.de to RS at: in-openfire (port: 5269)] - Unable to create a new outgoing session
2020.04.16 15:23:59 org.jivesoftware.openfire.session.LocalOutgoingServerSession[Create outgoing session for: in-openfire.ad.ingeneers.de to in-openfire] - Unable to create a new session: Dialback (as a fallback) failed.
2020.04.16 15:23:59 org.jivesoftware.openfire.session.LocalOutgoingServerSession[Authenticate local domain: 'in-openfire.ad.ingeneers.de' to remote domain: 'in-openfire'] - Unable to authenticate: Fail to create new session.
2020.04.16 15:23:59 org.jivesoftware.openfire.net.SocketReader - Closing session due to incorrect hostname in stream header. Host: in-openfire. Connection: org.jivesoftware.openfire.net.SocketConnection@466377e5 socket: Socket[addr=/127.0.0.1,port=52548,localport=5269] session: null
2020.04.16 15:24:53 org.jivesoftware.openfire.net.SocketReader - Closing session due to incorrect hostname in stream header. Host: in-openfire. Connection: org.jivesoftware.openfire.net.SocketConnection@36aae0a socket: Socket[addr=/127.0.0.1,port=52550,localport=5269] session: null
2020.04.16 15:24:53 org.jivesoftware.openfire.server.ServerDialback[Acting as Originating Server: Create Outgoing Session from: in-openfire.ad.ingeneers.de to RS at: in-openfire (port: 5269)] - Unable to create a new outgoing session
2020.04.16 15:24:53 org.jivesoftware.openfire.session.LocalOutgoingServerSession[Create outgoing session for: in-openfire.ad.ingeneers.de to in-openfire] - Unable to create a new session: Dialback (as a fallback) failed.
2020.04.16 15:24:53 org.jivesoftware.openfire.session.LocalOutgoingServerSession[Authenticate local domain: 'in-openfire.ad.ingeneers.de' to remote domain: 'in-openfire'] - Unable to authenticate: Fail to create new session.
2020.04.16 15:24:53 org.jivesoftware.openfire.net.SocketReader - Closing session due to incorrect hostname in stream header. Host: in-openfire. Connection: org.jivesoftware.openfire.net.SocketConnection@431d4423 socket: Socket[addr=/127.0.0.1,port=52552,localport=5269] session: null

The openfire XMPP domain is called in-openfire.ad.ingeneers.de (FQDN) , but it seems to try to connect to in-openfire, which looks wrong to me.
Honestly, I’m not quite understanding what is going on here, as the other user I tested this with (and created the log entries above) and myself use both @in-openfire.ad.ingeneers.de as login-ID.

Do you have an idea, why when initiating a file transfer the openfire server tries to connect it’s short domain name?
Thanks in advance for any answers!

Kind regards
Markus

Some output which may help:

# cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       in-openfire.ad.ingeneers.de in-openfire

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
# cat /etc/hostname
in-openfire

Windows clients are able to lookup both ‘in-openfire’ and the FQDN from the DC:

C:\>nslookup in-openfire
Server:  IN-DC.ad.ingeneers.de
Address:  192.168.5.2

Name:    in-openfire.ad.ingeneers.de
Address:  192.168.5.10


C:\>nslookup in-openfire.ad.ingeneers.de
Server:  IN-DC.ad.ingeneers.de
Address:  192.168.5.2

Name:    in-openfire.ad.ingeneers.de
Address:  192.168.5.10

…but the openfire-VM itself isn’t:

# nslookup in-openfire.ad.ingeneers.de
Server:         192.168.5.2
Address:        192.168.5.2#53

Name:   in-openfire.ad.ingeneers.de
Address: 192.168.5.10

root@in-openfire:/etc/openfire# nslookup in-openfire
;; Got SERVFAIL reply from 192.168.5.2, trying next server
Server:         192.168.5.250
Address:        192.168.5.250#53

** server can't find in-openfire: NXDOMAIN

This sounds as if there’s a component that generates a stanza that has an incorrect ‘to’ value.

Instead of:

<message to="in-openfire.ad.ingeneers.de" ...

Something like this is probably generated:

<message to="in-openfire" ...

If Openfire would receive a stanza addressed like this, it determines that the ‘to’ address does not match it’s own XMPP domain, and will try to federate with what it thinks must then be a remote domain. That would explain the logs that you’re seeing.

Note that this could very well be an IQ or Presence stanza instead of a Message stanza.

It’s hard to determine what’s causing this. I’d try sniffing the network, to find if there are indeed incorrectly addressed stanzas.

If you’re using TLS, sniffing might be hard. You can also try to use the Openfire XML Debugger plugin, which can be used to dump some (but not all) traffic.

I’m not sure how this ties into degraded performance, but it might be good to fix one problem and see where that gets you.

Note that in-band data requires data to be serialized in very inefficient ways. All data will also be processed by Openfire. I don’t expect you’d reach very good speeds with that. Better solutions would be to use clients that either do peer-to-peer transfers, or use something like HTTP File Upload.

Hi, thanks for your answer.
Yes, I know that in-band data transfer is slow, and indeed the final goal I want to achieve here is a direct peer to peer connection.
This shouldn’t be a problem at all in my opinion (all clients on same LAN/Windows-Domain, reachable by others, ports intern in LAN all open, etc.).
As the mentioned error message is the only one I saw in the logs, I thought that this strange mixing of FQDN and hostname leads to a fallback to in-band data transfer and therefore slowness of transfer.

I’ll take a look and make further investigations with the XML Debugger plugin (thanks for the tip) and with wireshark.
If you have any other ideas or hints for debugging, pleae let me know.