Opened 11 years ago

Closed 11 years ago

#6342 closed defect (fixed)

MSN disconnects with servconn read error ...

Reported by: visionkrew Owned by: khc
Milestone: 2.5.0 Component: MSN
Version: Keywords:


I'm using Adium with latest libpurple (MSNP15, checked out from the im.pidgin.pidgin branch). MSN gets disconnected in about every 5 minutes. The debug log says:

22:05:34: (Libpurple: msn) C: NS 000: PNG 22:05:34: (Libpurple: msn) servconn read error,len: -1, errno: 54, error: Connection reset by peer 22:05:34: (Libpurple: msn) Connection error from Notification server ( Reading error 22:05:34: (Libpurple: msn) C: SB 014: OUT 22:05:34: (Libpurple: msn) destroy httpconn (0x1a396700) 22:05:34: (Libpurple: msn) C: NS 000: OUT 22:05:34: (Libpurple: msn) Connection error from Notification server ( Writing error

I'm sure that my internet connection is OK, because with the official MSN client everything works fine.

Sometimes I just go offline while the program still thinks that I'm online, but maybe it's another bug.

Attachments (1)

adiumerr.txt (31.8 KB) - added by visionkrew 11 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 11 years ago by khc

  • pending changed from 0 to 1
$ mtn log --from latest
mtn: expanding selection 'latest'
mtn: misuse: no match for selection 'latest'

comment:2 Changed 11 years ago by khc

not enough debug log, either

comment:3 Changed 11 years ago by khc

  • Keywords msn disconnect servconn error removed

and please don't fill up the keywords with random words

comment:4 Changed 11 years ago by visionkrew

  • pending changed from 1 to 0

The main problem is that the debug log doesn't seem to contain anything else relevant-looking... The disconnect usually happens when I'm in a converstion with some of my buddies. I have normal switchboard activity (MSGs, ACKs, etc.), and suddenly a NS PNG, and no QNG, just the servconn read error message. This problem exists for a longer time in the MSNP14/15-related branches. Anyway, I'll post a full debug log later.

Changed 11 years ago by visionkrew

comment:5 Changed 11 years ago by Dimmuxx

The msn servers have had problems in some countries today so it's probably because of that. Some people even reported that the current svn msn-pecan builds crashed today because of the server problems.

comment:6 Changed 11 years ago by visionkrew

I always have this problem, when using libpurple ... and in the other hand, the official client was flawless yesterday as well. I'm pretty sure that it's a bug.

comment:7 Changed 11 years ago by QuLogic

It looks like that PNG is sent on the NS after some timeout after the last message on the SB. I'm not sure if SB messages should count, since they're on a different server. These PNG's should probably be sent after the timeout specified by the QNG, without regard for other SB's or SOAP or direct connections (whenever those happen).

comment:8 Changed 11 years ago by visionkrew

I'm pretty sure that SB messages should count...

The QNG command's parameter is an integer from 0 to 50. It represents the number of seconds to wait before sending another PNG, and is reset to 50 every time a command is sent to the servers (NS/SB/...). Idle connections are closed after a short time, so you should send a command to the server (even if it's just a PNG) at least this often.

As you see in the debug log, the last (SB) activity was 57 seconds before the PNG. So the PNG was too late (7 seconds), and the server dropped the connection.

This should be a timer bug resulting in late PNGs and dropped connections. You should check the timer function responsible for sending the PNGs.

comment:9 Changed 11 years ago by qulogic@…

  • Milestone set to 2.5.0
  • Resolution set to fixed
  • Status changed from new to closed

(In 34b47d7799f6c19a4e88fae539cec7821d69207e):
Update MSN's last_received time when we receive something on the NS only. The default keepalive timeout is 30 seconds, which is shorter than what the MSN server usually requests, so it should still be OK. gc->last_received only seems to be used for the keepalive timer, so I don't think I broke anything.

Should fix #6342, I think.

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!