#520 closed defect (fixed)

msn connection failure with pending buddy invite(s)

Reported by: anonymous Owned by: wilmer
Priority: major Milestone:
Component: MSN Version: 1.2.3
Keywords: msn buddy list invite msnp13 Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro:


i seem to be unable to connect to the MSN network, while there are 1 of more buddy invites pending. (buddy invites created with bitlbee).

when i try to connect, i get this:

[zo 19:57:36] <root> msn - Logging in: Connecting

[zo 19:57:37] <root> msn - Logging in: Connected to server, waiting for reply

[zo 19:59:11] <root> msn - Couldn't log in: Error while reading from server

[zo 19:59:11] <root> msn - Logging in: Signing off..

deleting a buddy from the buddylist, and then add them again, results in the same behaviour, while bitlbee connected just fine before making the invite.

connecting the account with pidgin works just fine.

maybe you guys can use libpurple as the IM connecting backbone, since they already figured everything out ;)

i hope there will be a fix very soon, because i cannot use bitlbee like this :(

Attachments (0)

Change History (14)

comment:1 Changed at 2009-09-26T07:39:17Z by anonymous

Yes, I am having the same problem. Can this be made higher priority as it really cripples the software?

comment:2 Changed at 2009-09-28T10:53:33Z by anonymous

i'm not sure the buddy list is the problem.

login still fails like 9 out of 10 times (or fails even more) with the error from above, but when i'm logged in, i get a lot of these messages: 'Warning: Many switchboard failures on MSN connection. There might be problems delivering your messages.'

and indeed resulting in an unusable state of bitlbee (messages that are sent are not received by the other user and incoming messages are not received by me). as i cannot trust that all messages are indeed delivered and messages for me are indeed received, i cann't use bitlbee :(

btw: i'm using a non-standard MSN address (an address not ending with or, but that should not be a problem ?

comment:3 Changed at 2009-10-02T23:20:08Z by wilmer

Can you give a tcpdump of what happens here?

comment:4 Changed at 2009-10-05T13:58:29Z by anonymous

wilmer: can you give options (and filter?) to use with tcpdump ? i used tcpdump port 1863, but i don't see any useful info in that output ;)

comment:5 Changed at 2009-10-05T14:13:51Z by Wilmer van der Gaast <wilmer@…>

Nothing useful, really? :-/ Try adding -s0 so it dumps full packets and not just the first 60 bytes.

comment:6 Changed at 2009-10-05T15:57:34Z by anonymous


tcpdump -s0 port 1863
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:48:49.844045 IP <localhost>.42814 > S 1676014655:1676014655(0) win 5840 <mss 1460,sackOK,timestamp 1581259069 0,nop,wscale 6>
17:48:50.011742 IP > <localhost>.42814: S 151348702:151348702(0) ack 1676014656 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK>
17:48:50.011862 IP <localhost>.42814 > . ack 1 win 92 <nop,nop,timestamp 1581259111 0>
17:48:50.012000 IP <localhost>.42814 > P 1:19(18) ack 1 win 92 <nop,nop,timestamp 1581259111 0>
17:48:50.179361 IP > <localhost>.42814: P 1:14(13) ack 19 win 65517 <nop,nop,timestamp 672225643 1581259069>
17:48:50.179407 IP <localhost>.42814 > . ack 14 win 92 <nop,nop,timestamp 1581259152 672225643>
17:48:50.179710 IP <localhost>.42814 > P 19:89(70) ack 14 win 92 <nop,nop,timestamp 1581259153 672225643>
17:48:50.347157 IP > <localhost>.42814: P 14:183(169) ack 89 win 65447 <nop,nop,timestamp 672225644 1581259153>
17:48:50.347486 IP <localhost>.42814 > P 89:121(32) ack 183 win 108 <nop,nop,timestamp 1581259194 672225644>
17:48:50.514782 IP > <localhost>.42814: P 183:228(45) ack 121 win 65415 <nop,nop,timestamp 672225646 1581259194>
17:48:50.515011 IP > <localhost>.42814: F 228:228(0) ack 121 win 65415 <nop,nop,timestamp 672225646 1581259194>
17:48:50.515148 IP <localhost>.42814 > F 121:121(0) ack 229 win 108 <nop,nop,timestamp 1581259236 672225646>
17:48:50.515389 IP <localhost>.45130 > by2msg3010809.phx.gbl.msnp: S 1695564864:1695564864(0) win 5840 <mss 1460,sackOK,timestamp 1581259236 0,nop,wscale 6>
17:48:50.679679 IP by2msg3010809.phx.gbl.msnp > <localhost>.45130: S 2509564416:2509564416(0) ack 1695564865 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK>
17:48:50.679757 IP <localhost>.45130 > by2msg3010809.phx.gbl.msnp: . ack 1 win 92 <nop,nop,timestamp 1581259278 0>
17:48:50.680030 IP <localhost>.45130 > by2msg3010809.phx.gbl.msnp: P 1:19(18) ack 1 win 92 <nop,nop,timestamp 1581259278 0>
17:48:50.682284 IP > <localhost>.42814: . ack 122 win 65415 <nop,nop,timestamp 672225647 1581259236>
17:48:50.846186 IP by2msg3010809.phx.gbl.msnp > <localhost>.45130: P 1:14(13) ack 19 win 65517 <nop,nop,timestamp 576504102 1581259236>
17:48:50.846292 IP <localhost>.45130 > by2msg3010809.phx.gbl.msnp: . ack 14 win 92 <nop,nop,timestamp 1581259319 576504102>
17:48:50.846575 IP <localhost>.45130 > by2msg3010809.phx.gbl.msnp: P 19:89(70) ack 14 win 92 <nop,nop,timestamp 1581259319 576504102>
17:48:51.010118 IP by2msg3010809.phx.gbl.msnp > <localhost>.45130: P 14:183(169) ack 89 win 65447 <nop,nop,timestamp 576504105 1581259319>
17:48:51.010462 IP <localhost>.45130 > by2msg3010809.phx.gbl.msnp: P 89:121(32) ack 183 win 108 <nop,nop,timestamp 1581259360 576504105>
17:48:51.174502 IP by2msg3010809.phx.gbl.msnp > <localhost>.45130: P 183:375(192) ack 121 win 65415 <nop,nop,timestamp 576504106 1581259360>
17:48:51.211705 IP <localhost>.45130 > by2msg3010809.phx.gbl.msnp: . ack 375 win 125 <nop,nop,timestamp 1581259411 576504106>
17:49:56.363492 IP by2msg3010809.phx.gbl.msnp > <localhost>.45130: F 375:375(0) ack 121 win 65415 <nop,nop,timestamp 576504759 1581259411>
17:49:56.363961 IP <localhost>.45130 > by2msg3010809.phx.gbl.msnp: F 121:121(0) ack 376 win 125 <nop,nop,timestamp 1581275699 576504759>
17:49:56.527130 IP by2msg3010809.phx.gbl.msnp > <localhost>.45130: . ack 122 win 65415 <nop,nop,timestamp 576504760 1581275699>

27 packets captured
27 packets received by filter
0 packets dropped by kernel

bitlbee messages:

[17:48:49] <root> Trying to get all accounts connected...
[17:48:49] <root> msn - Logging in: Connecting
[17:48:50] <root> msn - Logging in: Connected to server, waiting for reply
[17:48:50] <root> msn - Logging in: Transferring to other server
[17:48:50] <root> msn - Logging in: Connected to server, waiting for reply
[17:49:56] <root> msn - Couldn't log in: Error while reading from server
[17:49:56] <root> msn - Logging in: Signing off..

comment:7 Changed at 2010-03-14T01:44:03Z by wilmer

Ouch. Apologies for dropping the ball on this.

This tcpdump isn't really enough, I need packet contents as well. Are you still able to reproduce this problem? Because I'm not, I also have accounts with pending friend requests and they just work..

comment:8 Changed at 2010-05-11T21:57:42Z by wilmer

Resolution: moreinfo
Status: newclosed

Can't reproduce this and no response anymore. :-( I hope it went away or you probably just gave up. If you or someone finds this again, just reopen and I hope I can get some full tcpdumps then..

comment:9 Changed at 2010-07-18T16:57:47Z by ander.punnar@…

Resolution: moreinfo
Status: closedreopened

19:52:59 <ander> i added second msn account 19:53:08 <ander> and it keeps disconnecting 19:53:17 <ander> every 10+ minutes 19:53:26 <ander> first account is all cool 19:54:09 <ander> hmm, found bug on that

Using version bzr-devel-612-0

So, how do I turn on some sort of debug mode for bitlbee?

comment:10 Changed at 2010-07-27T14:10:05Z by wilmer

Resolution: moreinfo
Status: reopenedclosed

As we discussed on IRC, this is probably an issue with MSN. auto_reconnect to the rescue.

comment:11 Changed at 2010-08-07T19:33:20Z by wilmer

Resolution: moreinfo
Status: closedreopened

This just came up again in #bitlbee, looks like it's still an issue. :-(

comment:12 Changed at 2010-08-07T22:53:23Z by anonymous

I removed my second msn account and now I have now only one again. And few days ago I got several disconnections in few hours. I didn't have tcpflow running, but when I had same problem with 2 accounts, tcpflow dumps didn't show anything. Connections just ended and new one were initiated. But I think there's no connection between how many accounts you have since I have more users using bitlbee in my machine.

Anyway, bitlbee really needs some better internal debugging facility since usual tcpdump/flow doesn't show anything... at all.

comment:13 Changed at 2010-08-14T22:06:47Z by wilmer

Keywords: msnp13 added

That should fix this, hopefully. Updating the module to today's MSNP versions.

comment:14 Changed at 2010-10-02T06:02:50Z by wilmer

Resolution: fixed
Status: reopenedclosed

Fixed by msnp13 branch, now merged.

Modify Ticket

as closed The owner will remain wilmer.
The resolution will be deleted.

Add Comment

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

Note: See TracTickets for help on using tickets.