Jabber/Google Talk disconnects (..stream error: str:text)

[brynet@…]

Hi,

I previously sent a bug report about this, but my initial theory was wrong (..see #803).

I'm still seeing the following error:

Error: Stream error: str:text

It turns out Google is sending this XMPP message:

<stream:error><see-other-host xmlns="urn:ietf:params:xml:ns:xmpp-streams"/><str:text xmlns:str="urn:ietf:params:xml:ns:xmpp-streams">talk.google.com</str:text></stream:error>

..this causes bitlbee to reconnect, as it does for every <stream:error> from a jabber server.

I looked around for <see-other-host> but I'm not sure what the suggested fix is, would it be possible for bitlbee to ignore these messages or must it always reconnect?

Some places suggest that a jabber client shouldn't hardcode the server in the config and should instead attempt to query for DNS SRV records.. but I'm not sure that's the right thing to do for Google.

I have server manually configured to 'talk.google.com' as most clients do, it fails to connect with just google.com/gmail.com.

Thanks.

[wilmer]

What makes you think BitlBee is the one deciding to disconnect here BTW? ​http://xmpp.org/rfcs/rfc3920.html#rfc.section.4.7.3 describes what see-other-host means: "the server will not provide service to the initiating entity but is redirecting traffic to another host".

And see ​http://xmpp.org/rfcs/rfc3920.html#rfc.section.4.7.1 : "is assumed that all stream-level errors are unrecoverable; therefore, if an error occurs at the level of the stream, the entity that detects the error MUST send a stream error to the other entity, send a closing </stream> tag, and terminate the underlying TCP connection."

There's a separate bug for SRV lookups. I'm closing this one.

[brynet@…]

Replying to wilmer:

What makes you think BitlBee is the one deciding to disconnect here BTW? ​http://xmpp.org/rfcs/rfc3920.html#rfc.section.4.7.3 describes what see-other-host means: "the server will not provide service to the initiating entity but is redirecting traffic to another host".

And see ​http://xmpp.org/rfcs/rfc3920.html#rfc.section.4.7.1 : "is assumed that all stream-level errors are unrecoverable; therefore, if an error occurs at the level of the stream, the entity that detects the error MUST send a stream error to the other entity, send a closing </stream> tag, and terminate the underlying TCP connection."

There's a separate bug for SRV lookups. I'm closing this one.

I just don't know why the server keeps sending <see-other-host>, the host specified is the one that bitlbee is already connected to, talk.google.com.

I've found references that other clients ignore these and just wait for the server to actually disconnect.

Ah well, I'll just ignore reconnects for now and wait until DNS SRV records can be queried on OpenBSD.

Thanks, -Bryan.

[wilmer]

You can try to patch BitlBee to ignore the error and not disconnect but I'd be very surprised if it made a difference. Are you still seeing these disconnects very frequently? My guess is that they happen when servers are getting upgraded. It's pretty annoying but really shouldn't happen that often.

Auto-reconnect should help, and I assume you do have that enabled?

[brynet@…]

Just an update,

I was connecting to talk.google.com on port 5223, I also was enabling both set 'tls' and 'ssl'.

The <see-other-hosts> messages may have been Google trying to discourage me from use port 5223/SSL (..obsolete?), instead preferring port 5222 with TLS+SASL.

Apologies for the noise Wilmer.

-Bryan.