msn connection failure with pending buddy invite(s)

[anonymous]

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 :(

[anonymous]

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

[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 @hotmail.com or @live.com), but that should not be a problem ?

[wilmer]

Can you give a tcpdump of what happens here?

[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 ;)

[Wilmer van der Gaast <wilmer@…>]

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

[anonymous]

tcpdump:

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 > 64.4.50.62.msnp: S 1676014655:1676014655(0) win 5840 <mss 1460,sackOK,timestamp 1581259069 0,nop,wscale 6>
17:48:50.011742 IP 64.4.50.62.msnp > <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 > 64.4.50.62.msnp: . ack 1 win 92 <nop,nop,timestamp 1581259111 0>
17:48:50.012000 IP <localhost>.42814 > 64.4.50.62.msnp: P 1:19(18) ack 1 win 92 <nop,nop,timestamp 1581259111 0>
17:48:50.179361 IP 64.4.50.62.msnp > <localhost>.42814: P 1:14(13) ack 19 win 65517 <nop,nop,timestamp 672225643 1581259069>
17:48:50.179407 IP <localhost>.42814 > 64.4.50.62.msnp: . ack 14 win 92 <nop,nop,timestamp 1581259152 672225643>
17:48:50.179710 IP <localhost>.42814 > 64.4.50.62.msnp: P 19:89(70) ack 14 win 92 <nop,nop,timestamp 1581259153 672225643>
17:48:50.347157 IP 64.4.50.62.msnp > <localhost>.42814: P 14:183(169) ack 89 win 65447 <nop,nop,timestamp 672225644 1581259153>
17:48:50.347486 IP <localhost>.42814 > 64.4.50.62.msnp: P 89:121(32) ack 183 win 108 <nop,nop,timestamp 1581259194 672225644>
17:48:50.514782 IP 64.4.50.62.msnp > <localhost>.42814: P 183:228(45) ack 121 win 65415 <nop,nop,timestamp 672225646 1581259194>
17:48:50.515011 IP 64.4.50.62.msnp > <localhost>.42814: F 228:228(0) ack 121 win 65415 <nop,nop,timestamp 672225646 1581259194>
17:48:50.515148 IP <localhost>.42814 > 64.4.50.62.msnp: 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 64.4.50.62.msnp > <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..

[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..

[wilmer]

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..

[ander.punnar@…]

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?

[wilmer]

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

[wilmer]

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

[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.

[wilmer]

​http://code.bitlbee.org/wilmer/msnp13/

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

[wilmer]

Fixed by msnp13 branch, now merged.