jdev - 2021-10-24

Ge0rG, its not old, a few weeks

thoug i take back the "by default"

who knows what i changed in my wisdom

but the option in openwrt is really bad named, i try to find it

https://share.hoerist.com/philipp/QB1JMKjEDlfQGJfx/b1abc041-690c-4d7a-a7d9-403e619eadc4.png

There tell me you see this option and think, No i defenitly want useless requests

so i leave this unchecked

turns out the useless request are not that useless

thought to be fair thats not openwrt

thats LUCI a webinterface for openwrt

Wat!

What are 'useless requests' in openwrt jargon translated to plain english? ✏

in dnsmask config which openwrt uses there is a decade old configswitch

-f, --filterwin2k Later versions of windows make periodic DNS requests which don't get sensible answers from the public DNS and can cause problems by trigger- ing dial-on-demand links. This flag turns on an option to filter such requests. The requests blocked are for records of types SOA and SRV, and type ANY where the requested name has underscores, to catch LDAP requests.

this LUCI option turns this on, and filters all srv requests

seems 12 years ago srv records counted as useless

sorry all srv records with underscore

which xmpp uses

but i doubt this is on by default, i probably activated it because it looked good, when i configured my router

goes to show that you should not push buttons if you dont know what they do

Win2k?!

yeah more like 2 decades old :D

but that option is so bad named in in luci

the only reason to not activate that is when you actually know the background of what it does

but if Zash wouldnt have made that issue, i would probably never know that srv requests didnt work, like i wasnt impacted at all by this

https://git.openwrt.org/?p=project/luci.git;a=blob;f=modules/luci-mod-network/htdocs/luci-static/resources/view/network/dhcp.js;h=f425bd060509167d9be4ca6b50fd1c258fe45969;hb=HEAD#l385 https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=dnsmasq.conf.example;hb=9560658c5ba27a370b97d30850db474ce67912b7#l38 # Note that (amongst other things) this blocks all SRV requests, # so don't use it if you use eg Kerberos, SIP, XMMP or Google-talk. Yeah.

Not that useless.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464357 so this was fixed in upstream in 2008, but 13 years later it's still labelled as "useless" in OpenWrt :-\

Things breaking SRV → admins deploying without → things continuing to break SRV

Speaking of SRV, what level of support and adoption do direct TLS s2s connections and _xmpps-server SRV records have?

ejabberd seems to do it, and Daves proxy thing but the name escapes me

Metre

Prosody trunk has some partial support, in that it can set up such a listening port and check if the SRV record is correctly set up

Zash, will Prosody connect to a server via direct TLS s2s if _xmpps-server record is correctly set up?

No

That's the hard part

Minor weird thing that I didn't expect to cause me so much trouble: turns out pubsub items aren't directly in the IQ payload, they have a second wrapper (eg. instad of "<iq><pubsub><item1/><item2/>" you have "<iq><pubsub><items><item1/><item2/>"). Very clearly documented in the XEP, but I just kind of skipped over the extra wrapper not expecting it and took forever to track down the problem.

But you have something locally. Are there any issues stopping you from pushing it?

Making it *only* use `_xmpps-server` is easy. ✏

Making it use _both_ is *hard*

I see.

Anyway, my server was part of the first prosody - prosody direct tls s2s connection. 😃

In pubsub land do you have to publish a complete XML document? If it's wrapped in <item/> could you publish <foo/><bar/> for example?

Sam: Yes. One child of `<item/>`, no more, no less.

Thanks

Once upon a time there was a bunch of batch processing support in XEP-0060, that's where all the seemingly extra wrapper elements comes from

That's what I figured; it seemed weird that there was a wrapper but then you couldn't eg. retract multiple items at once, why wrap in <items/> if it's only one item?

`<items/>` _can_ have multiple items

err, <item/> then, whatever it's called

But you have iq/publish/item/{foo}bar

https://xmpp.org/extensions/xep-0060.html#nt-idm45119980301424

Trying to follow the constraints in this document is very difficult; thanks for the help.

Ah, there it is: https://xmpp.org/extensions/xep-0060.html#publisher-publish-error-badpayload > If the <item/> element does not contain exactly one payload element [...] the service MUST bounce the request with a <bad-request/> error

Conveniently far away from "The syntax is as follows:" https://xmpp.org/extensions/xep-0060.html#publisher-publish-request

"Ah, there it is" after some amount of time is exactly the problem I've been having :)

What, aren't you used to reading kleinbottle-shaped hyperdimensional documents by now? 😉

Alas, it's a skill I've never mastered.

Tho this is one of those that constantly grow new text when you're not looking, so I agree it can be a bit confusing.

However, after multiple attempts to get something as simple as "be able to publish and retract an item" working, I think I've finally done it. Integration tests running now, so we'll see how ejabberd handles them though.

Is this a client implementation?

Yah

Cool

Eventually it will grow a server side implementation too, but for now I just want "enough to fetch bookmarks"

When do we finish the XEP-0060 split?

Zash, I see, thanks. That is what I expected. I thought DTLS s2s is not supported anywhere, so I didn't configure it on my server, but since XEP-0368 mentions it, I decided to ask.

Excellent, ejabberd works too (for some reason it locks up the whole test suite if I try it locally, but works fine on the CI runner, so I'm never sure)

Also I stumbled upon https://code.moparisthebest.com/moparisthebest/xmpp-proxy , it looks very interesting.

Sam, if you don't already have https://xmpp.org/extensions/xep-0223.html open in parallel, might be worth to do so

Another one? *sigh* thanks

Don't worry, it's only Informational, on use of pubsub for bookmarks and such

lovetox, you did not, by chance, open an openwrt issue for, at least, better describing the configuration option, or maybe dropping it alltogether? ✏

Yes, please do

> Zash filed https://github.com/openwrt/luci/issues/5456 Closed already…