XMPP Service Operators - 2020-04-30

Huxx, I suggest to pipe it through `jq` for prettyprinting

Ok

Apr 30 08:55:07 s2sin558964761310 debug Incoming s2s connection Apr 30 08:55:07 s2sin558964761310 debug Incoming s2s received <stream:stream from='api.observe.jabber.network' xmlns='http://etherx.jabber.org/streams' version='1.0' xml:lang='en' to='lightwitch.org'> Apr 30 08:55:07 mod_s2s debug sending: <?xml version='1.0'?> Apr 30 08:55:07 mod_s2s debug sending: <stream:stream from='api.observe.jabber.network' xmlns='jabber:server' id='cae86f11-6eb3-46dc-9056-7a4553a004c7' xmlns:db='jabber:server:dialback' version='1.0' to='lightwitch.org' xmlns:stream='http://etherx.jabber.org/streams'> Apr 30 08:55:07 mod_s2s debug Sending stream features: <stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls><bidi xmlns='urn:xmpp:features:bidi'/><compression xmlns='http://jabber.org/features/compress'><method>zlib</method></compression><dialback xmlns='urn:xmpp:features:dialback'><errors/></dialback><sm xmlns='urn:xmpp:sm:2'/><sm xmlns='urn:xmpp:sm:3'/></stream:features> Apr 30 08:55:07 mod_s2s debug sending: <stream:features> Apr 30 08:55:07 s2sin558964761310 debug Received[s2sin_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> Apr 30 08:55:07 mod_s2s debug sending: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'> Apr 30 08:55:07 socket debug try to start ssl at client id: 558964761310 Apr 30 08:55:07 socket debug ssl session delayed until writebuffer is empty... Apr 30 08:55:07 s2sin558964761310 debug TLS negotiation started for s2sin_unauthed... Apr 30 08:55:07 socket debug starting ssl handshake after writing Apr 30 08:55:07 socket debug starting handshake... Apr 30 08:55:07 socket debug ssl handshake of client with id:table: 0x558964761310, attempt:1 Apr 30 08:55:07 socket debug ssl handshake of client with id:table: 0x558964761310, attempt:2 Apr 30 08:55:07 socket debug ssl handshake of client with id:table: 0x558964761310, attempt:3 Apr 30 08:55:07 socket debug ssl handshake of client with id:table: 0x558964761310, attempt:4 Apr 30 08:55:07 socket debug ssl handshake of client with id:table: 0x558964761310, attempt:5 Apr 30 08:55:07 socket debug ssl handshake done Apr 30 08:55:07 s2sin558964761310 warn Received invalid XML: </stream:stream> Apr 30 08:55:07 s2sin558964761310 warn Problem was: not well-formed (invalid token) Apr 30 08:55:07 mod_s2s debug sending: <?xml version='1.0'?> Apr 30 08:55:07 mod_s2s debug sending: <stream:stream version='1.0' xmlns='jabber:server' id='' xmlns:stream='http://etherx.jabber.org/streams'> Apr 30 08:55:07 s2sin558964761310 debug Disconnecting (unknown host)[s2sin_unauthed], <stream:error> is: not-well-formed Apr 30 08:55:07 mod_s2s debug sending: <stream:error> Apr 30 08:55:07 mod_s2s debug sending: </stream:stream> Apr 30 08:55:07 s2sin558964761310 info incoming s2s stream api.observe.jabber.network->lightwitch.org closed: not-well-formed Apr 30 08:55:07 s2sin558964761310 debug Destroying incoming session api.observe.jabber.network->lightwitch.org: not-well-formed Apr 30 08:55:07 socket debug try to close client connection with id: 558964761310 Apr 30 08:55:07 socket debug closing delayed until writebuffer is empty Apr 30 08:55:07 socket debug closing client after writing Apr 30 08:55:07 socket debug closing client with id: 558964761310 client to close

🤔 🤔 🤔 🤔 🤔 🤔 🤔

CC jonas’

yeah, some odd stuff happens after TLS negotiation

ISTM that it closes the stream before sending the stream header

Maranda, I’d love to debug this further, but https://github.com/mellium/xmpp/issues/31 blocks me from seeing what’s going on

:(

Also on checking s2s shouldn't it at least reopen the stream after starttls? (or it won't see if the service supports SASL External or not)

Maranda, it should, and if it doesn’t, I need to figure out why

but I can’t right now because of #31

it’s a PITA to debug this with binary garbage on my console ;-)

currently it doesn't for sure at least :D

you sure? because I’ve seen external offered to me already

on a non-dialback domain

{"auth_info":{"dialback_offered":true,"sasl_mechanisms":[]},"certificate_expiration":"2020-06-07T18:34:36Z","durations":{"connect":0.643939568,"starttls":0.198006831},"request_id":"QFTlPx_iMNAoplmF@2600:3c03::f03c:92ff:fe24:b7ee","success":true,"total_duration":1.3246845304965973} -> as long as it doesn't present a certificate or it's invalid during the handshake

but I don't see it reopening the stream after STARTTLS on lightwitch.org

that’s odd

because if you try mdosch.de for example, it definitely sees EXTERNAL

(but no dialback)

so far I assumed this was a bug with the SASL/Dialback detection (perfectly possible, the feature negotiation in that library is ... weird to say the least)

Pity, so if a domain supports both it'll fail detection I take, after all to check dialback support it does/should check the stream header, not features ✏

huh?

I guess it’s also a variant of https://github.com/mellium/xmpp/issues/47

jonas’, well mdosch.de doesn't look to have mod_dialback loaded.

(hence my previous message)

@ping jabber.fr

Maranda: Pong from jabber.fr in 0.086 seconds

> jonas’, well mdosch.de doesn't look to have mod_dialback loaded. Yeah, no dialback there.