Modify

#870 closed defect (invalid)

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

Reported by: brynet@… Owned by: wilmer
Priority: normal Milestone:
Component: Jabber Version: devel
Keywords: Cc:
IRC client+version: Client-independent Operating System: OpenBSD
OS version/distro:

Description

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.

Attachments (0)

Change History (4)

comment:1 Changed at 2011-12-07T09:28:34Z by wilmer

Resolution: invalid
Status: newclosed

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.

comment:2 in reply to:  1 Changed at 2011-12-07T23:20:34Z by 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.

comment:3 Changed at 2011-12-11T12:27:21Z by 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?

comment:4 Changed at 2011-12-15T09:19:24Z by 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.

Modify Ticket

Action
as closed The owner will remain wilmer.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.