jdev - 2025-02-23

This is awesome! Do you use it with starttls?

Yes.

blue, you might want to check which TLS library you built against, IIRC gloox can use either gnutls or openssl and one of them had an issue last time I checked (which was in 2020).

I reported the issue, but never got any feedback on it IIRC.

I also reported a bug during time at Debian Buster - [#287] The login on a server with Debian Buster does not work. This was also in Issue with TLS, I think it has been fixed.

Link Mauve: Nice https://gitlab.com/inkscape/inkscape/-/merge_requests/1540

my gloox is system package, it looks like it's built against gnutls... So, there can be a problem with it, right?

blue, I think it would help if you'd describe the actual issue with gloox

Okay. So, once out of 10-15 attempts everything works just fine. But more often it happens like this, here is the log ``` Log message: This is gloox 1.0.27, connecting to macaw.me... Log message: Resolving: _xmpp-client._tcp.macaw.me Log message: Connecting to macaw.me (45.79.76.58), port 5222 Log message: <?xml version='1.0' ?><stream:stream to='macaw.me' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' version='1.0'> Log message: <stream:stream id='7485812570620749751' version='1.0' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' from='macaw.me' xmlns='jabber:client'/> Log message: <stream:features xmlns:stream='http://etherx.jabber.org/streams'><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>PLAIN</mechanism><mechanism>SCRAM-SHA-1</mechanism><mechanism>X-OAUTH2</mechanism></mechanisms><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><register xmlns='http://jabber.org/features/iq-register'/></stream:features> Log message: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> Log message: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> Log message: starting TLS handshake... Log message: connection encryption active Log message: <?xml version='1.0' ?><stream:stream to='macaw.me' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' version='1.0'> ``` Then the program waits for about 3 - 7 minutes

after that, the program resuumes with the following log ``` Log message: <stream:stream id='136089709372077487' version='1.0' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' from='macaw.me' xmlns='jabber:client'/> Log message: <stream:features xmlns:stream='http://etherx.jabber.org/streams'><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>PLAIN</mechanism><mechanism>SCRAM-SHA-1-PLUS</mechanism><mechanism>SCRAM-SHA-1</mechanism><mechanism>X-OAUTH2</mechanism></mechanisms><sasl-channel-binding xmlns='urn:xmpp:sasl-cb:0'><channel-binding type='tls-exporter'/><channel-binding type='tls-server-end-point'/></sasl-channel-binding><register xmlns='http://jabber.org/features/iq-register'/></stream:features> Log message: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1-PLUS'>cD10bHMtdW5pcXVlLCxuPWpheV8wLHI9N2VjOTczOWYzOTJiOWVmMzI3MmUxZmE1MzRkNDgyZTA=</auth> Log message: <stream:error xmlns:stream='http://etherx.jabber.org/streams'><connection-timeout xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Idle connection</text></stream:error> Log message: </stream:stream> ``` Then it quits, because event loop let's go

blue, TLS seems to be established successfully, I don't think TLS is the issue here

blue, and please use a pastebin next time

Look for exceptions on the server, it should be replying to that <auth/>

Who is sending the stream error? Logging does not make that very clear

alright, sorry, will do next time! Yep, it seems to be fine, and it seems like gloox request a new stream after it established a tls, but the server seems to be waiting for something else... What is the right flow there?

let me figure out who sends an error... I was absolutely sure it's the server, but now i'm not so sure

Smells like a race condition where each side is waiting for the other to respond

kinda does, but i'm doing something so primitive, that I was absolutely sure that this is just my misunderstanding of something

Obviously it's nothing you're doing if there is a library bug causing it

https://pastebin.com/md8LrM1Q Welp, I was right, it's the server sending error stream

blue, Can you get some timestamps on that?

blue, spdlog may be your friend, here. But even a time_t would be fine, just to udnerstand the timings.

A moment

blue, Also you might need to get a tcp dump to see if that <auth/> is really being sent. Or server logs to see what's happening on that side. Or run your own server. Or all the above.

blue, And, total aside, I have wondered about writing a new C++ XMPP library. I'm not a huge fan of gloox, one of my clients uses it and it feels pretty awkward compared to modern C++ idioms.

Basically, gloox was the first one I've found... Normally I would use qxmpp, but this time I wanted something very light, without qt

I would totally follow the recomendation if you have something nice in mind)

I think gloox is the nicest of them, really. Which isn't saying much.

Swiften also exists, that’s the only thing I know about it.

Link Mauve, Ah, yes, I'd forgotten that existed separately.

Ah! dwd, you meant writing a new one! That would probably be cool, is there anything I can be of assistance there?)

timestamped https://pastebin.com/s4EgQM7N

That's very odd. Are you doing anything esoteric in your TLS, like sending a client certificate? It really does look as if the server gets stuck during the TLS handshake, and then has already decided to timeout the connection when it answers.

dwd, the server sends a new stream open after TLS, hence I assume everthing went as planned for both ends regarding TLS

hmm, otoh, the trace shows no evidence that the server was able to read what the client send post-TLS

blue, first try rebuilding it with openssl, to check the possibility that gnutls integration is busted.

blue, To clarify, I'm unconvinced that your stream open is actually sent until 17:10. if it is sent, it's not being read (I think).

if I read the RFC right, then the server would only send the stream open after it received the stream open from the initiating entity. that would mean we do have a confirmation that the server was able to read what the client send post-TLS ✏

Any client dev here plan to implement XEP-0389: Extensible In-Band Registration at some point? singpolyma, I think you basically did something similar via an adhoc command, what's the rationale for not using this XEP?

> if I read the RFC right, then the server would only send the stream open after it received the stream open from the initiating entity. that would mean we do have a confirmation that the server was able to read what the client send post-TLS Well, servers send a unilateral one if they send an error, but usually not with stream features, so you're probably right it gets read eventually.

"sometimes works but sometimes hangs for minutes before timing out" smells a bit like missing a .flush() on the network stream

nicoco: i submitted something similar years before and it was rejected by council. So I used ad hoc instead which they convinced me was a.better idea. I think it's probably still the right idea

There's a reason we don't see new http verbs and headers invented every time someone wants to submit a form to a server

> "sometimes works but sometimes hangs for minutes before timing out" smells a bit like missing a .flush() on the network stream Yeah, or the TLS handshake is blocking for some reason on one or other side.

singpolyma, I see, thanks for your reply. The value in this specific XEP is mostly to register a new XMPP account on a given server, where adhoc commands are not possible, are they?

Sure they are

It's just a series of iqs, same as this

Sent to the server itself, which is the only case that can work well with an unathed session

Welp, there definitely no flush on the client api... I'm not quite sure what's the correct protocol in this situalion? Should the client close the stream before asking for a new one? Should he have carried on with the authentication in the current stream? Meanwhile i'll try to build gloox agains opennssl, but it might take me a while