Opened 11 years ago

Closed 10 years ago

Last modified 6 years ago

#5278 closed defect

Disconnects from google talk

Reported by: newbie455 Owned by: darkrain42
Milestone: Component: Google Talk
Version: 2.4.0 Keywords: disconnect
Cc:

Description

I've been hoping this would be fixed with new releases for a while now but since it hasn't, and I was unable to find any other tickets on it, I am going to report it here.

I am constantly getting disconnected from google talk. About every hour of so (sometimes more often), I just get disconnected for no apparent reason. I have not caught the debug window output when it gets disconnected, but there are many instances of the following error in the debug window.

(19:26:41) jabber: Recv (ssl)(219): <iq type="error" id="purple4a1d85fb" to="me@…/HomeB2FEC053"><ping xmlns="urn:xmpp:ping"/><error code="501" type="cancel"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>

If I do get the output of the debug window when it disconnects, I will post back. Thank you.

Change History (47)

comment:1 follow-up: Changed 11 years ago by newbie455

here's what I got when it just disconnected if that helps at all.

(19:43:11) jabber: Sending (ssl): <iq type='get' id='purple4a1d8614'><ping xmlns='urn:xmpp:ping'/></iq>
(19:43:12) account: Disconnecting account 00C4BF88
(19:43:12) connection: Disconnecting connection 0568C990
(19:43:12) connection: Deactivating keepalive.
(19:43:12) connection: Destroying connection 0568C990
Last edited 6 years ago by Robby (previous) (diff)

comment:2 in reply to: ↑ 1 Changed 11 years ago by MCroft

I get similar errors with frequent disconnects from a Jabber server.

(11:45:34) jabber: Sending (ssl): <iq type='get' id='purple580da44c'><ping xmlns='urn:xmpp:ping'/></iq>
(11:45:34) jabber: Recv (ssl)(223): <iq type="error" id="purple580da44c" to="michael.croft@gmail.com/Home943251F2"><ping xmlns="urn:xmpp:ping"/><error code="501" type="cancel"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>
(11:45:55) jabber: Sending: <iq type='get' id='purplee90f5e12'><ping xmlns='urn:xmpp:ping'/></iq>
(11:45:59) jabber: Recv (ssl)(1):  
(11:46:15) account: Disconnecting account 00D2C3D0
(11:46:15) connection: Disconnecting connection 03F2A868
(11:46:15) connection: Deactivating keepalive.
(11:46:15) jabber: jabber_actions: have pep: NO
(11:46:15) connection: Destroying connection 03F2A868
Last edited 6 years ago by Robby (previous) (diff)

comment:3 Changed 11 years ago by deryni

  • pending changed from 0 to 1

I believe this is likely caused by the default timeout for xmpp pings in 2.4.0, if this is not mitigated significantly in 2.4.1 (which will hopefully be out today/tomorrow) please post new comments.

comment:4 follow-up: Changed 11 years ago by newbie455

  • pending changed from 1 to 0

I have upgraded to 2.4.1 and I am having the same issue just as frequently.

comment:5 in reply to: ↑ 4 Changed 11 years ago by MCroft

Replying to newbie455:

I have upgraded to 2.4.1 and I am having the same issue just as frequently.

We must have had different errors, then. My problem (and the other 2.4.0 user at my office's problem) was resolved.

comment:6 Changed 11 years ago by newbie455

The disconnect message at the bottom of my buddy list just says "Read error" and asks if I want to disable the account or reconnect it. I'm not behind a corporate firewall or anything and I have a very good connection (2.5mbps/400kbps with 20 ms ping last time I checked).

comment:7 Changed 11 years ago by newbie455

Also, this seems to be the error I am getting when it disconnects.

(20:05:16) jabber: Sending (ssl): <iq type='get' id='purple6792ae8c'><ping xmlns='urn:xmpp:ping'/></iq>
(20:05:16) account: Disconnecting account {removed}
(20:05:16) connection: Disconnecting connection {removed}
(20:05:16) idle: Setting me@gmail.com/Home unidle
(20:05:16) connection: Deactivating keepalive.
(20:05:16) connection: Destroying connection {removed}
Last edited 6 years ago by Robby (previous) (diff)

comment:8 Changed 11 years ago by deryni

That's not an error that is pidgin sending a ping to a server, and those XXXXXXX numbers aren't private they are memory addresses and mean nothing except in your given run of pidgin.

comment:9 Changed 11 years ago by newbie455

I don't know anything about the XMPP protocol and I didn't bother to check whether or not the connection ID changed every time because I assumed they weren't necessary anyways. That said, something must be failing when the ping is sent, because as you can see, it disconnected right after that. I didn't lose my internet connection or anything because all of the other protocols remained connected.

A few more lines prior to the disconnect, I have the same error I posted earlier:

(20:04:46) jabber: Sending (ssl): <iq type='get' id='purple6792ae8b'><ping xmlns='urn:xmpp:ping'/></iq> (20:04:46) jabber: Recv (ssl)(219): <iq type="error" id="purple6792ae8b" to="me@…/Home5F09F188"><ping xmlns="urn:xmpp:ping"/><error code="501" type="cancel"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>

comment:10 follow-ups: Changed 11 years ago by deryni

That "error" is fine, it means the server saw our ping request and doesn't know how to correctly handle it, but given that it is a ping all we care about is that we got a response not what the response was. Also no, what is directly before the disconnection does not necessarily have anything to do with the disconnection. If you yank your ethernet cable the last sent stanza will have nothing to do with the fact that your connection just went dead (for example). It is entirely possible to lose connection to one location without losing connection to others. Did you have other Google Talk connections that stayed alive when this one died?.

comment:11 Changed 11 years ago by filofel

Same problem here. This is running 2.4.0 under Windows, in case that matters. Example of a sequence before a disconnect (names consistently mangled in identifiers/addresses):

(16:58:54) jabber: Recv (ssl)(447): <presence from="xxxxxx@gmail.com/DevBookD95058BE" to="yyyyyyyy@gmail.com">
<priority>5</priority>
<x xmlns="jabber:x:signed">iD8DBQBH9PDBq5jCbWUb+GgRAtwgAJ9Um6t3/e9DjT4/7Rssd4+fxGPnCACgvSzj
JVdSgaYHTgmCEbUcjy4VOKg=
=Gj80</x>
<c node="http://psi-im.org/caps" ver="0.12-dev-rev1" ext="cs ep-notify html" xmlns="http://jabber.org/protocol/caps"/>

<x xmlns="vcard-temp:x:update"><photo>004916c9cb41ff4a9a4ae6b7c14cdb784be9eccf</photo></x></presence>
(16:58:54) jabber: Sending (ssl): <iq type='get' id='purple2aee7f53' to='xxxxxx@gmail.com/DevBookD95058BE'><query xmlns='http://jabber.org/protocol/disco#items' node='http://jabber.org/protocol/commands'/></iq>
(16:58:54) blist: Updating buddy status for xxxxxx@gmail.com (XMPP)
(16:58:54) jabber: Recv (ssl)(227): <iq type="result" to="yyyyyyyy@gmail.com/Work.Win.eC51BB8B1" id="purple2aee7f53" from="xxxxxx@gmail.com/DevBookD95058BE">
<query node="http://jabber.org/protocol/commands" xmlns="http://jabber.org/protocol/disco#items"/>
</iq>
(16:59:11) jabber: Recv (ssl)(116): <iq to="yyyyyyyy@gmail.com/Work.Win.eC51BB8B1" id="07127768" type="set"><new-mail xmlns="google:mail:notify"/></iq>
(16:59:11) jabber: Got new mail notification. Sending request for more info
(16:59:11) jabber: Sending (ssl): <iq type='get' id='purple2aee7f54'><query xmlns='google:mail:notify' newer-than-time='1207234473033' newer-than-tid='1265877079372369549'/></iq>
(16:59:11) jabber: Recv (ssl)(815): <iq to="yyyyyyyy@gmail.com/Work.Win.eC51BB8B1" id="purple2aee7f54" type="result"><mailbox url="http://mail.google.com/mail" total-matched="1" result-time="1207234772971" xmlns="google:mail:notify"><mail-thread-info tid="1265877349765411380" url="http://mail.google.com/mail?view=cv&amp;search=inbox&amp;th=1265877349765411380&amp;lvp=-1&amp;cvp=9&amp;qt=&amp;fs=1&amp;tf=1" participation="2" messages="2" date="1207234716344"><senders><sender address="yyyyyyyy@gmail.com" name="aaaaaaaa bbbbbbbb" originator="1"/><sender address="ssssssss@wanadoo.fr" name="wwwww vvvvvvvv" unread="1"/></senders><labels>^all|^f|^i|^ts0|^u</labels><subject>re: situation cts</subject><snippet>Si, c'est les HT. Les sommes sont débitées HT ! Mais comme ça n'est pas mentionné, on …</snippet></mail-thread-info></mailbox></iq>
(16:59:14) jabber: Sending (ssl): <iq type='get' id='purpleda89f2c6'><ping xmlns='urn:xmpp:ping'/></iq>
(16:59:15) jabber: Recv (ssl)(181): <iq from='jabber.hp.com' id='purpleda89f2c6' to='aaaaaaaa.bbbbbbbb@jabber.hp.com/Win.Work.eClient' type='error'><ping xmlns='urn:xmpp:ping'/><error code='404'>Not Found</error></iq>
(16:59:56) jabber: Sending (ssl): <iq type='get' id='purple2aee7f55'><ping xmlns='urn:xmpp:ping'/></iq>
(16:59:56) jabber: Recv (ssl)(225): <iq type="error" id="purple2aee7f55" to="yyyyyyyy@gmail.com/Work.Win.eC51BB8B1"><ping xmlns="urn:xmpp:ping"/><error code="501" type="cancel"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>
(17:00:14) jabber: Sending (ssl): <iq type='get' id='purpleda89f2c7'><ping xmlns='urn:xmpp:ping'/></iq>
(17:00:14) jabber: Recv (ssl)(181): <iq from='jabber.hp.com' id='purpleda89f2c7' to='aaaaaaaa.bbbbbbbb@jabber.hp.com/Win.Work.eClient' type='error'><ping xmlns='urn:xmpp:ping'/><error code='404'>Not Found</error></iq>
(17:00:26) jabber: Sending (ssl): <iq type='get' id='purple2aee7f56'><ping xmlns='urn:xmpp:ping'/></iq>
(17:00:26) account: Disconnecting account 00C6C2E0
(17:00:26) connection: Disconnecting connection 00F27860
(17:00:26) connection: Deactivating keepalive.
(17:00:26) jabber: jabber_actions: have pep: NO
(17:00:26) connection: Destroying connection 00F27860
Last edited 6 years ago by Robby (previous) (diff)

comment:12 in reply to: ↑ 10 Changed 11 years ago by newbie455

Replying to deryni:

That "error" is fine, it means the server saw our ping request and doesn't know how to correctly handle it, but given that it is a ping all we care about is that we got a response not what the response was. Also no, what is directly before the disconnection does not necessarily have anything to do with the disconnection. If you yank your ethernet cable the last sent stanza will have nothing to do with the fact that your connection just went dead (for example). It is entirely possible to lose connection to one location without losing connection to others. Did you have other Google Talk connections that stayed alive when this one died?.

No, I only have one google talk account. Finally someone else with the same problem! If you need more from my log, let me know. I just have a bunch of other accounts (not on google talk), so there is a lot of unnecessary info in my log as far as this error goes.

comment:13 Changed 11 years ago by cassius

I have the same problem. Frequent disconnects on a fat ~2MB (with a capital 'B') connection. This has been going on for a while, through both a gtalk and a jabber.org account.

Let me know what I could post to help identify.

comment:14 in reply to: ↑ 10 Changed 11 years ago by filofel

Replying to deryni: Did you have other Google Talk connections that stayed alive when this one died?.

To answer that question, I ran Pidgin yesterday concurrently with the GTalk applet running in Firefox (http://talkgadget.google.com/talkgadget/popout). The Google applet didn't exhibit any connection drop, while the Pidgin connection failed and reconnected regularly, every 5 minutes or so.

comment:15 follow-ups: Changed 11 years ago by deryni

That tests basically nothing useful unfortunately. If you have more than one Google Talk account connecting them both in pidgin might tell us something useful. As might using some other local (not web based) XMPP client for your single Google Talk account.

comment:16 Changed 11 years ago by jaybz

hi, i had the same problem with an older version of pidgin. probably 2.1.1 or 2.2.0. i upgraded to 2.4.1 yesterday and problem persisted until today. i have 2 gtalk accounts and both of them experience the same problem. before and after i upgraded to 2.4.1. most of the time they would both get disconnected almost at the same time. there are times though that one would disconnect about a minute or 2 before the other one would get disconnected. now i said the problem persisted until today. today, i can't even connect at all. i still get the same error message (Read Error) however i'm currently downloading gtalk to check if this is a new problem with the gtalk server this time.

comment:17 in reply to: ↑ 15 Changed 11 years ago by Merkaba

Replying to deryni:

As might using some other local (not web based) XMPP client for your single Google Talk account.

I've had the same problems as the other users here and have tried a variety of other IM clients. Psi regularly disconnects on GTalk as does the official client from my work's ADSL (which I don't believe is all too stable). Digsby is far more stable when using my GTalk account. I have noticed that 2.3.1 appears to have far less disconnects for me personally.

Using my more stable home connection it appears to be only Pidgin that will frequently disconnect with either Read errors or ping timeouts. My Jabber account also disconnects but far less frequently and usually its a server side problem.

I'll try Pidgin again with a few other Gtalk accounts and see whether the frequncy of disconnect is affected in any way.

comment:18 Changed 11 years ago by jaybz

well ok, the problems seems to have disappeared for me. after half a day of not being able to connect at all i stopped trying pidgin and decided to try the gtalk client to check if it was a gtalk problem. 30 minutes later (i had to download and install the client on the same computer as pidgin among other things), i connected via the gtalk client and it was fine. i tried pidgin again, and it was fine. and so far, no disconnections on both accounts.

this is far fetched but it may be possible that google is blacklisting ips that don't log on using the gtalk client. either that or it was an issue that solved itself. i'll post again if it recurs tomorrow.

comment:19 Changed 11 years ago by newbie455

Other clients such as Digsby and Trillian do not do this at all for GTalk. This has been an ongoing problem for me since I started using GTalk with pidgin. 6 months maybe?

comment:20 in reply to: ↑ 15 ; follow-ups: Changed 11 years ago by filofel

Replying to deryni:
Quite frankly, it's not clear to me what we should actually be looking for: I'm running Pidgin on two very hi-speed connections (work and home) that have error rates close to zero, so I consider the quality of the connection itself as irrelevant as a potential cause. This looks to me much more like a protocol issue, and one that obviously affects quite a few people. I see this problem occurring juste the same with both Pidgin Windows and Pidgin Linux, BTW. The Pidgin debugging window can give us a bunch of information about the protocol / dialog context of the error, but that doesn't seem to be enough to pinpoint what the problem is.
What else can we do?
Could it help if I installed WireShark? (nee EtherReal?) on a machine, captured the stream with the GTalk server up to a connection error event and posted it here?

comment:21 in reply to: ↑ 20 Changed 11 years ago by newbie455

Also, the fact that other protocols remain connected somewhat eliminates the possibility of a connection issue.

comment:22 in reply to: ↑ 20 ; follow-up: Changed 11 years ago by deryni

Replying to filofel: If I knew what to have you look for I would probably know what the problem is. Since I don't know what the problem is I need you to look for anything. A number of people in this thread have professed to have wonderful and stable internet connections but I take all such claims with a grain of salt because virtually all applications that use the internet are extremely tolerant to connection faults (including pidgin in a lot of cases, so much so that we have bugs filed because pidgin doesn't notice dead connections fast enough for many people). Network monitors are unlikely to be of particularly large help though they certainly couldn't hurt and may in fact provide something useful (again it depends on what the problem is exactly); also the fact that the connection is going to be encrypted is going to make getting much useful data about it harder (unless the problem is at a different layer, which it might be).

newbie455: No, it doesn't you can very easily lose connection to only parts of the internet it all depends on how your connection is set up and how you are getting there at that moment.

comment:23 in reply to: ↑ 22 Changed 11 years ago by jaybz

ok, it might be useful for me to mention that my disconnection issues have been resolved. it might also be useful information that for my both gtalk accounts, i have pretty much the same list of contacts.

and deryni, since you're looking for anything at all, here's something you might want to check on if you haven't already taken it into account. afaik, gtalk encryption is done over SSL and so is https. recently i've experienced https issues with major browsers due to MTU settings on a router on the web server's network being too high compared to the MTU settings we have on the network in which i experience issues with. the web server is owned by the company i work for and we have full control of the said router. our system administrators managed to solve the issue by lowering the router's MTU setting. to explain further, the https issue we've been having behaves like this. handshakes, and headers work fine. smaller html pages work fine (but the images almost always never load). larger html pages also fail to load. it also happens much less often when tcp window scaling (basically scales MTU upward to take advantage of higher bandwidths) is off on the web servers themselves and on the computer experiencing the issue. also, not all computers in our network have the same bug. the issue occurs both on linux and windows desktops, but mostly on windows desktops. i wish i could give more info on which linux distros/kernels the bug occurrs on but i don't think we kept track of that. it seems that our https problem happens when the packets get split due to MTU by the router in question, and then again by another router somewhere else, most possibly the one in our local office. i don't know how you can do so but you might want to check on the possibility of pidgin experiencing the same issue.

comment:24 Changed 11 years ago by Endymion

I just posted http://developer.pidgin.im/ticket/5589 and wonder if this might be related; the description could refer to the same symptoms, but for me, this happens in Jabber, not Google Talk.

comment:25 Changed 11 years ago by kscarr

I am seeing this as well, connecting to openfire. It appears the ping request is sent, and the server sends a response immediately saying feature is not implemented.

Then, pidgin timeouts after a bit, and the reconnect occurs.

It seems like pidgin should ping, and if it gets any kind of response including the feature not implemented, it should be ok.

comment:26 Changed 11 years ago by deryni

pidgin does do that, any response correct or error to the ping is enough.

comment:27 Changed 11 years ago by kscarr

In this case, it doesn't seem to be following that. Right after I get the ping error, it waits about 10-15 seconds, and then does a reconnect. This is happening on multiple computers.

comment:28 Changed 11 years ago by deryni

Paste the xml output of pidgin sending the ping and the error coming back from your server.

comment:29 Changed 11 years ago by deryni

Oh also, the ping timeout pidgin uses for disconnecting an account when it doesn't hear a response to the ping is 120 seconds so 10-15 seconds after the ping almost certainly isn't from that one.

comment:30 Changed 11 years ago by kscarr

This appears to only be a problem with the 2.4 series of Pidgin. Going back to the 2.3 series fixed this problem for us.

It gives a read error and exits is what the user sees. I will try to get the logs for you.

comment:31 Changed 11 years ago by kscarr

Not sure if this is relevant, but I am using SSL on this connection.

comment:32 Changed 11 years ago by kscarr

Here is my debug log:

Pidgin Debug Log : 5/6/2008 1:32:56 PM
(13:31:03) jabber: Recv (ssl)(392): <presence from="person3@xmpp.myserver.com/Home" to="person1@xmpp.myserver.com"><show>away</show><status>I'm not here right now</status><c xmlns="http://jabber.org/protocol/caps" node="http://pidgin.im/caps" ver="2.4.1" ext="mood moodn nick nickn tune tunen avatarmeta avatardata avatar"/><x xmlns="vcard-temp:x:update"><photo>e5cc13ade26e46fbbb672124ea78d9fe8c52be8a</photo></x></presence>

(13:31:03) blist: Updating buddy status for person3@xmpp.myserver.com (XMPP)

(13:31:03) sound: Playing C:\Program Files\Pidgin\sounds\purple\login.wav

(13:31:04) jabber: Recv (ssl)(526): <message to="person1@xmpp.myserver.com/Work" from="person3@xmpp.myserver.com" id="person3@xmpp.myserver.com__person1@xmpp.myserver.com__5G8UT"><event xmlns="http://jabber.org/protocol/pubsub#event"><items node="http://jabber.org/protocol/tune"><item id="zlqgzGRL22LDSI0" node="http://jabber.org/protocol/tune"><tune xmlns="http://jabber.org/protocol/tune"/></item></items></event><addresses xmlns="http://jabber.org/protocol/address"><address type="replyto" jid="person3@xmpp.myserver.com/Home"/></addresses></message>

(13:31:13) jabber: Sending (ssl): <iq type='get' id='purple1c46ce63'><ping xmlns='urn:xmpp:ping'/></iq>

(13:31:25) jabber: Recv (ssl)(102): <presence type="unavailable" from="person5@xmpp.myserver.com/Work" to="person1@xmpp.myserver.com"/>

(13:31:25) blist: Updating buddy status for person5@xmpp.myserver.com (XMPP)

(13:31:25) sound: Playing C:\Program Files\Pidgin\sounds\purple\logout.wav

(13:31:25) blist: Updating buddy status for person5@xmpp.myserver.com (XMPP)

(13:31:25) jabber: Recv (ssl)(364): <presence from="person4@xmpp.myserver.com/Work" to="person1@xmpp.myserver.com"><priority>1</priority><c xmlns="http://jabber.org/protocol/caps" node="http://pidgin.im/caps" ver="2.4.1" ext="mood moodn nick nickn tune tunen avatarmeta avatardata avatar"/><x xmlns="vcard-temp:x:update"><photo>d1dcb801eb4f667a09e2fa5b20ea85286bf9f68b</photo></x></presence>

(13:31:25) blist: Updating buddy status for person4@xmpp.myserver.com (XMPP)

(13:31:25) sound: Playing C:\Program Files\Pidgin\sounds\purple\login.wav

(13:31:25) jabber: Recv (ssl)(544): <message to="person1@xmpp.myserver.com/Work" from="person4@xmpp.myserver.com" id="person4@xmpp.myserver.com__person1@xmpp.myserver.com__mVxxo"><event xmlns="http://jabber.org/protocol/pubsub#event"><items node="http://jabber.org/protocol/tune"><item id="2C3P2D9Ycv04HDV" node="http://jabber.org/protocol/tune"><tune xmlns="http://jabber.org/protocol/tune"/></item></items></event><addresses xmlns="http://jabber.org/protocol/address"><address type="replyto" jid="person4@xmpp.myserver.com/Work"/></addresses></message>

(13:31:28) jabber: Recv (ssl)(101): <presence type="unavailable" from="person6@xmpp.myserver.com/Work" to="person1@xmpp.myserver.com"/>

(13:31:28) blist: Updating buddy status for person6@xmpp.myserver.com (XMPP)

(13:31:28) sound: Playing C:\Program Files\Pidgin\sounds\purple\logout.wav

(13:31:28) blist: Updating buddy status for person6@xmpp.myserver.com (XMPP)

(13:31:30) util: Writing file blist.xml to directory C:\Documents and Settings\scarr\Application Data\.purple

(13:31:30) util: Writing file C:\Documents and Settings\scarr\Application Data\.purple\blist.xml

(13:31:39) jabber: Recv (ssl)(104): <presence type="unavailable" from="person7@xmpp.myserver.com/Home" to="person1@xmpp.myserver.com"/>

(13:31:39) blist: Updating buddy status for person7@xmpp.myserver.com (XMPP)

(13:31:39) sound: Playing C:\Program Files\Pidgin\sounds\purple\logout.wav

(13:31:39) blist: Updating buddy status for charles.ryan@gmail.com (XMPP)

(13:31:39) sound: Playing C:\Program Files\Pidgin\sounds\purple\login.wav

(13:31:39) blist: Updating buddy status for charles.ryan@gmail.com (XMPP)

(13:31:44) util: Writing file blist.xml to directory C:\Documents and Settings\scarr\Application Data\.purple

(13:31:44) util: Writing file C:\Documents and Settings\scarr\Application Data\.purple\blist.xml

(13:31:47) jabber: Recv (ssl)(105): <presence type="unavailable" from="person2@xmpp.myserver.com/Home" to="person1@xmpp.myserver.com"/>

(13:31:47) blist: Updating buddy status for person2@xmpp.myserver.com (XMPP)

(13:31:47) sound: Playing C:\Program Files\Pidgin\sounds\purple\logout.wav

(13:31:52) util: Writing file blist.xml to directory C:\Documents and Settings\scarr\Application Data\.purple

(13:31:52) util: Writing file C:\Documents and Settings\scarr\Application Data\.purple\blist.xml

(13:31:52) jabber: Recv (ssl)(16): </stream:stream>

(13:32:13) jabber: Sending (ssl): <iq type='get' id='purple1c46ce64'><ping xmlns='urn:xmpp:ping'/></iq>

(13:32:40) jabber: Sending (ssl): <iq type='get' id='purpled98d428c'><ping xmlns='urn:xmpp:ping'/></iq>

(13:32:40) account: Disconnecting account 00C8FD38

(13:32:40) connection: Disconnecting connection 019FE040

(13:32:40) connection: Deactivating keepalive.

(13:32:40) jabber: jabber_actions: have pep: YES

(13:32:40) connection: Destroying connection 019FE040

(13:32:40) GLib-GObject: invalid cast from `GtkEventBox' to `GtkButton'

(13:32:40) Gtk: gtk_button_get_relief: assertion `GTK_IS_BUTTON (button)' failed

(13:32:43) GLib-GObject: invalid cast from `GtkEventBox' to `GtkButton'

(13:32:43) Gtk: gtk_button_get_relief: assertion `GTK_IS_BUTTON (button)' failed

(13:32:43) jabber: Sending (ssl): <iq type='get' id='purple1c46ce65'><ping xmlns='urn:xmpp:ping'/></iq>

(13:32:45) util: Writing file accounts.xml to directory C:\Documents and Settings\scarr\Application Data\.purple

(13:32:45) util: Writing file C:\Documents and Settings\scarr\Application Data\.purple\accounts.xml

(13:32:45) util: Writing file blist.xml to directory C:\Documents and Settings\scarr\Application Data\.purple

(13:32:45) util: Writing file C:\Documents and Settings\scarr\Application Data\.purple\blist.xml
Last edited 6 years ago by Robby (previous) (diff)

comment:33 Changed 11 years ago by deryni

In that debug log pidgin sends out at least four ping stanzas and receives no reply to any of them. If pidgin doesn't receive a ping response (a response which is required by XMPP) then it assumes it has been disconnected and disconnects the account. It would seem to me that that is rather clearly what is happening here, what is not at all clear to me is why no responses are coming back. Notably it doesn't include any of the ping errors we were discussing and you were claiming you were seeing. pidgin 2.3.x did not include this ping functionality and as such will not disconnect you.

comment:34 Changed 10 years ago by deryni

  • Status changed from new to pending

Is anyone here still encountering this issue? If you are, please get the debug log from the disconnection while only having a single XMPP (and Google Talk) account logged in. Unfortunately our ping requests are not marked with the sending account or destination and as such they cannot easily be distinguished at send time (they can be matched up with responses, but only if we get some).

comment:35 Changed 10 years ago by filofel

I just updated to 2.5.6 this morning, launched it and got a disconnect after a while (around 20 mn). I'm going to set the log, recreate the problem and send it along.

This problem never occurs when I use the gtalk Javascript gadget available from the https gmail page in Firefox (that's what I've been using to work around the Pidgin disconnect problem). What's the trick they use? Couldn't we ride the same?

comment:36 Changed 10 years ago by filofel

deryni,

When I'm ready to send you a full session debug log, what is the preferred way to send you the file?
And what am I supposed to remove from the file before I send it, BTW?

comment:37 Changed 10 years ago by filofel

Deryni,

Done. I captured a full session, from Pidgin start to loss of connection then autorecon.

The point when it fails looks like this:

(13:28:41) jabber: Sending (ssl): <iq type='get' id='purple3166010b'><ping xmlns='urn:xmpp:ping'/></iq>
(13:28:41) jabber: Recv (ssl)(73): <iq to="---------@gmail.com/F762FCAC" id="purple3166010b" type="result"/>
(13:29:11) jabber: Sending (ssl): <iq type='get' id='purple3166010c'><ping xmlns='urn:xmpp:ping'/></iq>
(13:29:11) jabber: Recv (ssl)(73): <iq to="---------@gmail.com/F762FCAC" id="purple3166010c" type="result"/>
(13:29:41) jabber: Sending (ssl): <iq type='get' id='purple3166010d'><ping xmlns='urn:xmpp:ping'/></iq>
(13:29:41) jabber: Disconnected: Remote host closed connection.
(13:29:41) account: Disconnecting account 00E0EF80
(13:29:41) connection: Disconnecting connection 019EA588
(13:29:41) connection: Deactivating keepalive.

Just gimme instructions about what to remove from the file and how to ship it to you, and I'll send it zipped.

comment:38 Changed 10 years ago by deryni

That looks like Google Talk is disconnecting you "Remote host closed connection." a ping timeout should report the error as "Ping timeout".

And no the javascript gadget almost certainly doesn't use XMPP to connect to the Google Talk servers.

comment:39 Changed 10 years ago by filofel

I sure understood it was disconnecting me. The question is why does it?

The whole dialog before the disconnect seems to occur perfectly normally - Piding sends pings every minute, and the GTalk server instantly sends a reply back. Conversation goes on like this, until some seemingly random point were Pidgin sends its usual ping and the server instantly disconnects it.

Strangerer and strangerer, said Alice.

comment:40 follow-up: Changed 10 years ago by deryni

  • Status changed from pending to new

Indeed, I have no idea what might be causing this problem. Does this happen with other (normal) desktop XMPP clients? Is the length of time before you get kicked off constant?

comment:41 Changed 10 years ago by QuLogic

  • Owner changed from seanegan to darkrain42

comment:42 follow-up: Changed 10 years ago by darkrain42

(in addition to deryni's questions) What sort of network are you on, filofel? Are you behind a NAT?

comment:43 in reply to: ↑ 40 Changed 10 years ago by filofel

Replying to deryni:

Indeed, I have no idea what might be causing this problem. Does this happen with other (normal) desktop XMPP clients? Is the length of time before you get kicked off constant?

The times have changed since I first ran into this problem, and in the interim, both GTalk and Pidgin have significantly changed. I'll re-test everything before I answer those questions.

comment:44 in reply to: ↑ 42 Changed 10 years ago by filofel

Replying to darkrain42:

(in addition to deryni's questions) What sort of network are you on, filofel? Are you behind a NAT?

Behind a NAT that isolates my small group of machines from the outside wild world, and to make things worse, the NAT is itself behind a corporate proxy. But what's disturbing is that 1) it still works most of the time. 2) the disconnect is initiated by Google 3) the disconnect always happens as an "answer" to a Pidgin ping.

comment:45 Changed 10 years ago by deryni

It is possible it is the NAT disconnecting you and not Google Talk, the error message means only that pidgin (and your local machine) is not doing it (unless I am mistaken). You would need to see what the Google Talk servers think is happening to know for sure.

Is there a constant period of time between disconnections? Is the length of your connection to Google Talk constant when you get disconnected? Are you perhaps hitting some bandwidth cap, connection time limitation, or similar local network policy?

comment:46 Changed 10 years ago by darkrain42

  • Status changed from new to pending

comment:47 Changed 10 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!