[SOLVED] ejabberd: unable to join multi user chats (muc) anymore

moneo · 2020-12-03 19:14:01

Hello after seven years... ;) Yes, thats true!

Since yesterday evening, around 9 to 10 PM and after I rebooted my Contabo-VPS my ejabberd is unable to join MUC's.
There was a new kernel (5.4.80-2-lts) and a new Python version (v3.9) which forced me to rebuild my whole Seafile environment. I had no time
and no reason to play around with /etc/ejabberd/ejabberd.yml. Why would I? All worked great for months. I noticed that Conversations droped a
message that I am no longer part of that particular MUC I was looking at the moment - which I ignored. I tapped rejoin and closed the program.
But tomorrow morning I recognized that this is a more severe problem as every MUC said so. Fun thing is: I can brows public MUC's and join
them for a second. I can even rejoin MUC's I already joined and for a short moment I can see all recent messages from other users. But after one
or two seconds I am kicked off of the MUC saying I am no longer part of the group.

Regardless of what I do, the error message is always the same for every MUC I try to join - which I can join for a second as I mentioned above

Outbound s2s connection started: netfg.net ->
2020-12-03 19:21:20.437830+01:00 [error] <0.658.0> ** Generic server <0.658.0> terminating 
  ** Last message in was {'$gen_cast',connect}
  ** When Server state == #{codec_options => [ignore_els],
  db_enabled => true,lang => <<"en">>,
  mod => ejabberd_s2s_out,on_route => queue,
  owner => <0.658.0>,password => <<>>,
  queue => {{[],[]},0,unlimited},
  remote_server => <<"conference.anoxinon.me">>,
  resource => <<>>,server => <<"netfg.net">>,
  server_host => <<"netfg.net">>,shaper => none,
  stream_authenticated => false,
  stream_direction => out,stream_encrypted => false,
  stream_id => <<"17627020073237256384">>,
  stream_restarted => false,
  stream_state => connecting,
  stream_timeout => -576454534304,
  stream_verified => false,user => <<>>,
  xmlns => <<"jabber:server">>}

andSome further informations are

2020-12-03 19:39:18.290306+01:00 [debug] <0.570.0>@ejabberd_sm:do_route/1:741 Sending to process <0.531.0>:
  #iq{id = <<"S_3yiEUvpvsY">>,type = error,lang = <<"en">>,
    from =
      #jid{
        user = <<"conversations">>,server = <<"conference.jabber.de">>,
        resource = <<>>,luser = <<"conversations">>,
        lserver = <<"conference.jabber.de">>,lresource = <<>>},
    to =
      #jid{
        user = <<"tfl">>,server = <<"netfg.net">>,
        resource = <<"Conversations.hfTl">>,luser = <<"tfl">>,
        lserver = <<"netfg.net">>,lresource = <<"Conversations.hfTl">>},
    sub_els =
    [#xmlel{
      name = <<"query">>,
      attrs =
      [{<<"xmlns">>,<<"http://jabber.org/protocol/disco#info">>}],
      children = []},
    #stanza_error{
      type = wait,code = 500,by = undefined,
      reason = 'internal-server-error',
      text =
      [#text{lang = <<"en">>,data = <<"Internal server error">>}],
      sub_els = []}],
    meta = #{ip => {0,0,0,0,0,65535,48322,4008}}}

With LogLevel 5 it fills the logs as if there is now tomorrow and it is completely irrelevant what MUC I would like to join: It's always the same except of course for the remote server name.

What I have done so far:

I toggled the client (Dino/Conversations)
I toggled the operating system (Android/ArchLinux)
I toggled the Andoid Device: OnePlus 3T and Samsung Galaxy Tab A
I downgraded the kernel from 5.4.80-2-lts to linux-lts-5.4.79 and vide-versa
I downgraded the Erlang runtime from erlang-(nox|unixodbc)-23.1.4 to erlang-(nox|unixodbc)-23.1.2 and vide-versa
I used the ejabberd.yml from my last backup

AND: I installed Prosody, made the necessary changes and had a stable connection to all the MUC's I would like to join.
So the problem must by on my local system... and I have no idea whats-o-ever

Maybe you have?
Torsten

PS:

ejabberd version is 20.07
TSL/SSL is enforced and based upon Letsencrypt

PPS:

One might ask, if Prosody works, why not switch? Well, I tested it and Up- and Downloads where slow.
Ejabberd also enables you to make Audio- and Videocalls. I tested that as well. Worked great!

Last edited by moneo (2020-12-06 19:15:18)

moneo · 2020-12-06 18:36:25

After a few days - and again and again digging through the logs - I came to the conclusion that it has to do something with the name resolution.
I run a local Unbound server for Postfix DNSSEC and let systemd write /etc/resolv.conf.

I gave it a shot: i cleared up resolv.conf and kept only two lines: two nameserver entries: 127.0.0.1 and ::1 (for IPv6).
After I restarted ejabberd S2S connections worked again! Whoa! Why is that?

I now restored my original resolv.conf and disabled/enabled every entry and tested ejabberd s2s connection until I reached the last line in /etc/resolv.conf:

search .

And that's it: "search ." keeps ejabberd from resolving foreign domains and server-2-server connections fail. Without it ejabberd works great again.
Due to the fact that no other software part of my server complains about name resolution and Prosody works great too with "search ." I suspect there
may be a bug in ejabberd regarding name resolution. But little do I know and until today I seem to be the only person on the planet who has this problem...
which is fixed now Well. Its not fixed but I can bypass the error condition. I think I file a bug against ejabberd.

For the public: with loglevel 5 you will see not DNS related errors. You have to go to loglevel 4 - which is INFO. It's insane!

Last edited by moneo (2020-12-06 20:23:24)

Arch Linux

#1 2020-12-03 19:14:01

[SOLVED] ejabberd: unable to join multi user chats (muc) anymore

#2 2020-12-06 18:36:25

Re: [SOLVED] ejabberd: unable to join multi user chats (muc) anymore

Board footer