XSF Discussion - 2019-07-06

hi

something stange is happening with ejabberd. you are not connected to this chat... latest git ejabberd. attention

There are lots of hills that Ge0rG isn't willing to die on

Also lots of hills where I'm fighting to death... 😉

ping

RST

I seem to have a stuck s2s link between xmpp.org and wielicki.name

Any idea when it started?

yes

18:40Z

18:33Z was last successful contact

±2min

Like say 18:31:17

I see an unanswered ping being sent to xmpp.org at 18:35:12 from my prosody

I luckily have debug logs \o/

18:33:17 also looks unanswered (going further up)

I see nothing after that

And I see an error.

oh yes, I have 18:31:17 as the last answer

And I know the reason for that.

the reason is?

A chain of unshaved yaks I'm afraid

oh dear

is this again the thing where I start to test/monitor stuff and I find bugs in servers?

Bug in lua-event. It's fixed, but there's where the chain of unshaved yaks starts, waiting for iteam to fix the world 🙂

I see

s/lua-event/epoll/ and see how much fire comes out of things?

Ge0rG, are you okay with me registering an account on yax.im for ping-probing my own domains from yax.im every 60s or so, possibly along with xmpp.org for fun & profit?

Zash, so you have all data you need?

why are there features registered for MUC and no description what they mean

whats muc_unsecured !?

lovetox, opposite of the one where it has a password

I think?

whats muc_public vs muc_open

Zash no there is muc_passwordprotected

muc_persistent vs muc_temporary

jonas’, not entirely sure why the error causes s2s to be stuck

muc_public and muc_open are not mutually exclusive

how do you know that?

lovetox, I run search.jabbercat.org ;)

One is the opposite of hidden and the other is maybe the opposite of members-only?

yes

that’s the case

haha ok, so now we know its used in the wild

but still no idea what it means

I do

is_joinable_muc = ( "muc_open" in info.features and "muc_passwordprotected" not in info.features and "muc_persistent" in info.features )

is_indexable_muc = ( "muc_public" in info.features and "muc_persistent" in info.features )

https://xmpp.org/extensions/xep-0045.html#registrar-features has some short descriptions

a MUC needs to be indexable && joinable to appear in the listing

thus, there are quite a few which are both open and public :)

Zash thats what im looking at

I don’t look at muc_unsecured

so they added a feature for every state

instead of if muc_open is absent it means its not open

Zash, would closing the s2s link from my side help fixing the stuckness?

probably, tho I wonder if it'll notice the closing if it doesn't notice incoming data

hm

my question is thus: can I do that, or would that hinder investigations you want to take on this?

Hold on

alright, I just silenced the alert for now :)

jonas’, eh, kill it

em

ejabberd returns on disco info on a muc room

a form that has not only the typical roominfo stuff

they also add roomconfig stuff in there even with options

Zash, that fixed things

https://paste.gajim.org/view/a337ac53

should i report this?

looks really weird and not right

Specifically?

what’s weird about it?

a form of formtype muc#roominfo

having muc#roomconfig vars

not unusual

jonas’: feel free to IBR and set up monitoring

lovetox, xsf@muc.xmpp.org has it too

Ge0rG, thanks!

(if you come across zombofant-blackbox-prober@yax.im, that’s me)

i dont see how this is relevant

lovetox, it is relevant insofar as this is not an ejabberd specific thing

or is now everything ok if i find X things that do it like that

jonas’: IIRC the conversations uptime monitor is also doing a bunch of things, with a 2min period.

Also my cpu load is back to normal, so I'm relaxed now.

https://xmpp.org/extensions/xep-0045.html#registrar-features <name>http://jabber.org/protocol/muc#roominfo</name> <desc>Support for the muc#roominfo FORM_TYPE</desc>

why not just add a second form with the correct form type

why even bother having a form type if we can infer nothing from it

What

What's the correct form type?

It looks like it has `http://jabber.org/protocol/muc#roominfo`, which is correct

not if you put then vars in it that are registered under a different form type

a form type is just a hint anyways

I don’t see a reason to duplicate the names and semantics of the fields

There's some text under example 10 https://xmpp.org/extensions/xep-0045.html#example-10 that seems to say that this is ok

Zash no

that example is wrong :D

> whereas other information is based on the more-stable room configuration, which is why any field defined for the muc#roomconfig FORM_TYPE can be included in the extended service discovery fields (as shown above for the "muc#roomconfig_changesubject" field).

is it?

the text seems to say it’s right

yes

indeed XEP allows it

the example is wrong because of this

muc#roominfo_changesubject

this var is not registered and does not exist

but its unrelated to the topic :)

oh it should be roomconfig_changesubject, I guess

no also wrong

i mean you could but there is a better option

which is?

muc#roominfo_subjectmod

which is actually registered

:D

fun

it gets even more funnier

i wanted to show that value in Gajim

so i looked at the example, and told ejabberd and prosody devs to add roomconfig_changesubject

both did

:D

too tired

sleepytime

seconded

ah no even worse, i requested adding the wrong one muc#roominfo_changesubject

:/