-
BeagleIM jumps to the next DNS entry if it is not able to connect to the remote server. In your logs you have following entries:
SocketConnector sending stanza: <stream:stream to='domain.tld' from='ij@domain.tld' version='1.0' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'> WriteBuffer sent 138 bytes 138 of 138 SocketConnector stream event: HasSpaceAvailable SocketConnector stream event: HasBytesAvailable SocketConnector stream event: EndEncountered connection state changed: connected
which means that remote server was available and accepted TCP connection and due to that BeagleIM decided that connection to that endpoint is valid.
Subsequent disconnection was assumed as an issue on the server - ie. some timeout, so BeagleIM backed of and retried with DNS entries assuming that all entries are still valid (as TCP connection to the server was possible).
Due to that I do not think that is an error in BeagleIM. It is a valid mechanism jumping to the next entry if TCP connection would not be possible.
-
It still didn't work. I was not online... I can do a screencast to show it... :) Maybe it's the restrictive firewall that shows up as connection... the FW is looking maybe at the content and decide whether or not this is a WhatsApp connection on port 5222 (allowed) or a standard XMPP connection (blocked).
-
Nope, negative... there was no connection at all...
I can provide you a video where you can see the timing of the events (just message me in the Tigase MUC)... the log hangs for quite a long time at this point:
WriteBuffer sent 138 bytes 138 of 138 SocketConnector stream event: HasBytesAvailable
Then, the next lines are this:
SocketConnector stream event: EndEncountered connection state changed: connected SessionObject removing properties for scopes [TigaseSwift.SessionObject.Scope.stream] XMPPClient connection stopped...... ##### ij@hookipa.net - disconnected 2020-07-21 06:44:05 +0000 XMPPClient starting connection...... connection state changed: disconnected
And as you can see from this screenshot of the company firewall, the access to port 5222 has been denied:
So, definitely there is no established connection to port 5222 in this case and I think the message
connection state changed: connected
is wrong here. Beagle cannot connect to the standard port and should try the next host in DNS SRV RR. -
Actually "connected" is written only if TCP connection was established - (if TCP socket connection was established).
Looking at the screen from your firewall I'm convinced that the connection was established. There is an
Application
column which actually states type of the connection and that can only be detected by traffic inspection which is only possibile after TCP connection is established.
Hi!
For me it seems as if BeagleIM just tries to connect to the first DNS SRV entry for _xmpp-client._tcp.domain.tld, that is: the one with the lowest priority, and not trying other entries, although they are listed in the result set of DNS query.
Below you can see the console output after starting BeagleIM 4.0b97. You can see the resolver result includes the entry for port 443 with priority 15 first. While Beagle was running, I changed DNS zone to have port 443 priority of 1. After that change was done Beagle was able to connect successfully.
I believe this is an error and Beagle should try other DNS entry than just the first one with lowest priority. Basically I want to have port 443 as a fallback port in case some restrictive firewalls are blocking standard XMPP ports 5222 and 5223.