By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 2723 - Kopete - Jabber connection error: Host not found
Summary: Kopete - Jabber connection error: Host not found
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdenetwork (show other bugs)
Version: R14.0.x [Trinity]
Hardware: Other Linux
: P5 normal
Assignee: Slávek Banko
URL:
Depends on:
Blocks: R14.0.5
  Show dependency tree / graph
 
Reported: 2016-11-07 08:16 CST by linux
Modified: 2017-01-26 01:59 CST (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Process all SRV records or fallback if SRV records not exist (1.79 KB, patch)
2016-11-13 04:18 CST, Slávek Banko 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description linux 2016-11-07 08:16:43 CST 
After upgrading from Trinity 14.0.3 to 14.0.4, some jabber accounts in Kopete stopped working with this error message:

Connection problem with Jabber server xyz
There was a connection error: Host not found

One of my accounts still worked so I found out that enabling "override default server information" in account setup makes it work. I guess that Kopete is now expecting SRV record to exist in DNS without falling back to A record.
Comment 1 Slávek Banko 2016-11-09 18:32:49 CST 
Yes, there is a different behavior from previous versions. In the previous version was always enforced "Override default server information" and used older XMPP protocol (see bug 698). Now is used newer versions of XMPP protocol and server is searched using the SRV records, if the user deliberately not turn on the "Override default server information",

I'm looking into the specs, it seems that it can be used as a fallback server name and the default port if the server SRV records do not exist.
Comment 2 Slávek Banko 2016-11-13 04:18:43 CST 
Created attachment 2742 [details]
Process all SRV records or fallback if SRV records not exist

As I understand from the specification, fallback can be used only in the event that there are no SRV records. The patch adds this option. It also complements the processing of all SRV records.

See: http://xmpp.org/rfcs/rfc6120.html#tcp-resolution
Comment 3 Slávek Banko 2016-11-13 21:44:44 CST 
Patch pushed to GIT in hash 244c1e03 (master) and 8fb0b52d (r14.0.x).

Please, you're using Debian or Ubuntu? You can test whether the issue is resolved through packages in the Preliminary Builds Stable repository?
Comment 4 linux 2017-01-26 01:59:04 CST 
Tested in R14.0.5 development and it seems to work.

"Use protocol encryption (SSL)" unchecked, "Override default server information" unchecked and it connects fine using TLSv1.2 (according to Wireshark).