XMPP Service Operators - 2024-01-19

  1. Stefan


  2. Licaon_Kter

    Stefan: yo, what brings you here?

  3. Stefan

    Hi! It seems I have a problem with my server records. the thing is, gajim needs more than 15 seconds to connect. (psi+ connects immediately). and I could first not connect to this muc, said "not reachable" (second try worked then). I thought it could be a problem with ipv6 not available (had this with putty), but others said i should check my server records. I have a dynip setup with a myfritz domain.

  4. Stefan

    compliance tester from inputmice didn't pass the server-records test formerly.

  5. Licaon_Kter

    Stefan: what did it complain about?

  6. Licaon_Kter

    Gajim logs say what? DNS SRV records are fine?

  7. Stefan

    I don't remember exactly, and now it doesn't work anymore.

  8. Stefan

    > DNS SRV records are fine? i don't know enough about it to be able to answer that. could i show you the records?

  9. Licaon_Kter


  10. Stefan


  11. Stefan

    I remember I saw failures in the ejabberd log too, somethin with certificates.

  12. Licaon_Kter

    Which client sent a picture as link?

  13. Stefan


  14. Licaon_Kter

    1.8.4? Odd

  15. jonas’

    Licaon_Kter, embeddings may be stripped here.

  16. jonas’

    for reasons

  17. Licaon_Kter


  18. Stefan

    yes, 1.8.4

  19. jonas’

    Stefan, * CNAME is..... potentially causing issues

  20. Licaon_Kter

    Good to know. jonas’: how? MUC server manipulates messages?

  21. jonas’

    Licaon_Kter, yes.

  22. jonas’

    Licaon_Kter, I suspect https://modules.prosody.im/mod_muc_restrict_media.html is loaded here

  23. Stefan

    I changed settings on my router, so the daily disconnection doesn't take place anymore. I think of putting in the ip directly now. ip change every 180 days should be not too bad?

  24. jonas’

    Stefan, the ****.de suffix on conference.chat.*****.de needs to be removed

  25. Stefan

    I even read about some methods of automatically change dns settings, it was an article in c't

  26. jonas’

    and try removing the `*` CNAME.

  27. jonas’

    that may cause issues depending on the particular DNS software used.

  28. Stefan

    jonas’, thank you!

  29. Stefan

    so only "conference.chat" ist enough?

  30. jonas’


  31. jonas’

    (probably—the DNS provider will add that suffix on their own)

  32. Stefan

    ok, I changed the settings. I will check later to see if there has been a change.

  33. jonas’

    good luck!

  34. jonas’

    if it still doesn't work, you can tell us the domain name and we can take a look---it's often easier to poke at these kind of things from the outside because in particular with CNAMEs there's a lot that can go wrong.

  35. Stefan

    can't you see the domain name in my upload link?

  36. jonas’

    oh :)

  37. jonas’


  38. Stefan

    I didn't think of it when posting..;-)

  39. jonas’

    ok so the first thing I notice is that the SRV records don't seem to be actually present?

  40. jonas’

    ah, you didn't set them up correctly

  41. jonas’

    but even the other ones don't show up

  42. Stefan

    perhaps because of the change?

  43. Stefan

    how do you lookup that?

  44. jonas’

    I use `dig` on the commandline: `dig +short SRV _xmpp-server._tcp.chat.rxmpp.de` (empty)

  45. Stefan

    perhaps it doesn't work with cname with my provider at all?

  46. Stefan

    or it takes a while, I just changed them, so perhaps that is the reason. thank you very much !

  47. jonas’

    no, even when asking their servers directly (`dig +short @ns01.1blu.de. SRV _xmpp-server._tcp.chat.rxmpp.de`) the SRV record does not show up, but the `*` CNAME is gone already.

  48. Stefan


  49. jonas’

    but that shouldn't be an issue, actually, quite the opposite. The chat.rxmpp.de record exists and seems to work

  50. jonas’

    and a server answers on that (looks like an ejabberd?)

  51. Stefan


  52. jonas’

    so it should work

  53. jonas’

    so maybe the stuff with the MUC component will sort itself out now that you fixed the CNAMEs

  54. jonas’

    I'd delete the SRV records in your case, because (a) they do not work and (b) it's not correct to point an SRV at a CNAME

  55. jonas’

    and (c) you don't need them because you have CNAMEs pointing at A records for your XMPP domains

  56. Stefan

    ok. but I could change the cnames to my ip?

  57. jonas’

    no need for that

  58. Stefan

    i mean, remove the cnames, and use ip instead

  59. jonas’

    yeah, no need for that

  60. Stefan

    so what do you think is the reason for the delayed connection in gajim?

  61. jonas’

    does it happen alwyas?

  62. jonas’

    does it happen always?

  63. Stefan

    yes. but psi+ is faster, always.

  64. Stefan

    15-20 seconds

  65. Stefan

    i have only ipv4 enabled for my server.

  66. jonas’


  67. jonas’

    in that case one would probably have to look at network traces. the connection to your server is fast. maybe that's something to ask in the gajim room though, maybe there are debug logs you can look at before shooting with the big guns (wireshark) at the problem.

  68. Stefan

    I asked there already, they said me I should check the server records ;-)

  69. jonas’

    right, but Psi+ seems to work and your server records look ok now to me.

  70. jonas’

    oh, something weird *is* going on

  71. jonas’


  72. jonas’


  73. Stefan

    the problem is very similar to the one I had with ssh / putty, but with a different computer. switching from "auto" to "ipv4" in putty solved the problem and the connection was re-established without delay. the delay was also about 15-20 seconds.

  74. jonas’

    Stefan, your myfritz domain publishes *both* IPv6 and IPv4 records

  75. jonas’

    if your xmpp server only listens on IPv4, that's going to cause issues

  76. jonas’

    you need to make your xmpp server listen on IPv6, or fix the myfritz to only show the IPv4 IP

  77. Stefan

    hmm I already thought about changing the server settings to support ipv6 too. but I don't have any knowledge about ipv6, so I didn't do it yet.

  78. Stefan

    first step i planned now was to not use the cname anymore but put the ip in there.

  79. Stefan

    > Stefan, your myfritz domain publishes *both* IPv6 and IPv4 records great that you noticed that, thank you!

  80. Stefan

    > Stefan, your myfritz domain publishes *both* IPv6 and IPv4 records it looks as if there is no way to change this behaviour of myfritz.

  81. jonas’

    then you should enable IPv6 on your XMPP service :)

  82. Guus

    fun: https://github.com/berthubert/trifecta/issues/38

  83. MattJ

    Random issues like this is a reason Snikket uses a subdomain for HTTP upload, as "defence in depth"

  84. MattJ

    Random issues like this are a reason Snikket uses a subdomain for HTTP upload, as "defence in depth"

  85. jonas’

    if your http upload component doesn't already set a strict content security policy, yesterday was a good time to change that.

  86. Stefan

    > and (b) it's not correct to point an SRV at a CNAME now I'm a bit desoriented what would be the best way for me. (not regarding the problem with ipv4/ipv6). point an SRV at a CNAME ist not correct - but what is better now? setting it to the ip(v4), or deleting the SRV as jonas´ suggested? It seems that everything works without these Records? why do I need them at all?

  87. MattJ

    There is a good chance you don't

  88. MattJ

    They are necessary if you have non-standard ports or need to balance connections over multiple servers

  89. Stefan

    ah I see.

  90. moparisthebest

    > fun: https://github.com/berthubert/trifecta/issues/38 Ah yes, I assume everyone remembers this moment in their life, I know I do: > I never knew that SVG could contain javascript which would run...

  91. jonas’

    Stefan, *if* you wanted to keep SRV records (which you probably don't need to), you could point the SRV directly at your myfritz domain