Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#11532 closed defect (fixed)

MSN SLP Call Spam

Reported by: jmlsteele Owned by: QuLogic
Milestone: 2.7.1 Component: MSN
Version: 2.6.6 Keywords: SLP call switchboard msnslp
Cc: ip, BigBrownChunx

Description

I've noticed recently that pidgin was using bandwidth for no apparent reason (about 10K/s for 3 second bursts every 5 seconds).

I did a packet capture and saw that it was the same message more or less repeating itself over and over again.

Here is what the pidgin debug log had to say (snipped for sanity of readers)

(07:51:11) msn: C: SB 002: USR 1 %MY_MSN% 1897716008.1617167.128180121
(07:51:11) msn: S: SB 002: USR 1 OK %MY_MSN% %MY_MSN%
(07:51:11) msn: C: SB 002: CAL 2 %FRIEND_MSN%
(07:51:11) msn: S: SB 002: CAL 2 RINGING 1897716008
(07:51:12) msn: S: SB 002: JOI %FRIEND_MSN% %FRIEND_NAME% 2789003372
(07:51:12) msn: Processing queue
(07:51:12) msn: Sending message
(07:51:12) msn: C: SB 002: MSG 3 D 866
(07:51:12) msn: switchboard send msg..
(07:51:12) msn: C: SB 002: MSG 4 U 98
(07:51:12) msn: S: SB 002: NAK 3
(07:51:12) msn: switchboard send msg..
(07:51:12) msn: C: SB 002: MSG 5 D 866
(07:51:12) msn: S: SB 002: NAK 5
...SNIP...
(07:56:11) msn: switchboard send msg..
(07:56:11) msn: C: SB 002: MSG 1502 D 866
(07:56:11) msn: S: SB 002: NAK 1502
(07:56:11) msn: switchboard send msg..
(07:56:11) msn: C: SB 002: MSG 1503 D 866
(07:56:11) msn: C: SB 002: OUT
(07:56:11) msn: destroy httpconn (049B1888)
(07:56:50) msn: C: NS 000: PNG
(07:56:50) msn: S: NS 000: QNG 45
(07:57:06) msn: S: NS 000: FLN %FRIEND_MSN% 1 0
(07:57:06) blist: Updating buddy status for %FRIEND_MSN% (MSN)
(07:57:06) blist: Updating buddy status for %FRIEND_MSN% (MSN)

It sent 1500 messages in the span of ~5 minutes, using ~1.5MB of bandwidth. I've noticed this about 6 times now, and it seems to happen right after I start pidgin, and then sporadically afterward. I've also seen 2 different friend's accounts be "targeted".

The Message that it is sending is as follows: (personal information removed, Base54 also altered to remove email address)

MSG 3 D 867
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: %FRIEND_MSN%

....M............................M..............INVITE MSNMSGR:%FRIEND_MSN% MSNSLP/1.0
To: <msnmsgr:%FRIEND_MSN%>
From: <msnmsgr:%MY_MSN%>
Via: MSNSLP/1.0/TLP ;branch={5A2D551E-416F-1235-11AA-204F4A1D8F98}
CSeq: 0
Call-ID: {264D23EC-3FB7-1CC4-12FC-37FA52CC6C02}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-sessionreqbody
Content-Length: 328

EUF-GUID: {A4268EEC-FEC5-49E5-95C3-F126696BDBF6}
SessionID: 28149
AppID: 1
Context: PG1zbm9iaiBDcmVhdG9yPSIlRlJJRU5EX01TTiUiIFNpemU9IjIzNzkzIiBUeXBlPSIzIiBMb2NhdGlvbj0iMCIgRnJpZW5kbHk9ImFnQmhBSG9BZWdBZ0FHZ0FZUUJ1QUdRQWN3QUFBQT09IiBTSEExRD0ibHp2VVZjUlkxNTBCRFk5eWZhZGJ6MDFERTVvPSIvPg==

.....

The Base64 encoded context field decodes to:

<msnobj Creator="%FRIEND_MSN%" Size="23793" Type="3" Location="0" Friendly="agBhAHoAegAgAGgAYQBuAGQAcwAAAA==" SHA1D="lzvUVcRY150BDY9yfadbz01DE5o="/>

Attachments (1)

11532-bandwidth-graph.jpg (113.7 KB) - added by jmlsteele 9 years ago.
Bandwidth Graph of the usage during an occurrence of the bug

Download all attachments as: .zip

Change History (14)

comment:1 Changed 9 years ago by ip

I have exactly the same problem. (Bandwidth being used up at the same rate; did a tcpdump and saw the same messages being sent over and over again.)

I am using Finch, though, so it seems to be a libpurple issue.

The problem started a few days ago with Finch 2.6.2 (as included in Ubuntu karmic).

I upgraded to Finch 2.6.6 (fc3d5c2a3920e0875ac235415cea9fc7f5ed780c), still Ubuntu karmic, and the problem is still continuing. I used the pidgin-developers PPA.

comment:2 Changed 9 years ago by darkrain42

  • Owner changed from khc to QuLogic

comment:3 Changed 9 years ago by QuLogic

  • Status changed from new to pending

Pidgin is merely requesting your buddy's icons. It should stop once they're all downloaded.

comment:4 Changed 9 years ago by jmlsteele

  • Status changed from pending to new

The problem is that it's requesting the SAME buddy's icon 1500 times over the course of 6 minutes. I haven't seen it happen recently, but then again I haven't been paying attention. I'll look for it to happen again and try to find out as much information about the other buddy as possible (what client they use, if they have an icon, the actual icon itself if i can get it, etc) to assist with the debugging.

comment:5 Changed 9 years ago by QuLogic

  • Status changed from new to pending

What makes you say that? That first log you posted is just for a single icon request.

comment:6 Changed 9 years ago by jmlsteele

  • Status changed from pending to new

I guess I wasn't clear enough.

"It sent 1500 messages in the span of ~5 minutes, using ~1.5MB of bandwidth."

Each of the 1500 messages was identical, except of course for the MSG #. So it sent 1500 Buddy requests to the same user over the course of 5 minutes. I didn't post the whole log because it was huge, and I thought it unnecessary as the only thing that was changing was the MSG # and the NAK #.

comment:7 Changed 9 years ago by jmlsteele

Sorry. When I said buddy requests in the previous comment, I meant Icon requests.

I still have the debug log file if you would like me to either post it, or send you a copy, and I noticed that the same issue occurred earlier today (I don't have debug logging enabled at this time though, so I don't have that log) based on my network usage (it makes a very specific and noticeable pattern).

Changed 9 years ago by jmlsteele

Bandwidth Graph of the usage during an occurrence of the bug

comment:8 Changed 9 years ago by darkrain42

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

comment:9 Changed 9 years ago by qulogic@…

  • Milestone changed from 2.7.1 to 2.7.0

(In 52fb5cb4cd8795906a7313dd5edde763a4848a3e):
Normalize the remote passport before sending a P2P message. If it's not lowercase, then the switchboard will reject it, causing a whole lot of extra network traffic as Pidgin attempts to resend the same (incorrect) message.

Fixes #11532.

comment:10 Changed 9 years ago by rekkanoryo

  • Milestone changed from 2.7.0 to 2.7.1

Sorry about the milestone spam there.

comment:11 Changed 9 years ago by jmlsteele

Excellent, thanks. I looked at the (uncensored) email address of my friend's email address that was involved, and it does have uppercase characters in it, so this should fix it.

comment:12 Changed 9 years ago by darkrain42

Ticket #11421 has been marked as a duplicate of this ticket.

comment:13 Changed 9 years ago by rekkanoryo@…

(In dd496d006f7414efd30774f23f17af433cd38a0e):
* Plucked cfe0e649dda34d9252d40d8f67e445336a247998 (darkrain42@…): yahoo: Fix a few race-condition crashes at login

(if the account disconnects while these fetches are in-progress).

* Plucked 1724c0c7cbf56b08b5454e796b80173ec9aef481 (rekkanoryo@…): Very hackily implement a fallback mechanism in Yahoo, but not for Yahoo Japan because we don't know hosts we can fall back to there yet. This fallback mechanism just blindly connects to scsa.msg.yahoo.com if the HTTP-based CS lookup fails. I guarantee this will break in the future. Refs #11986.

* Plucked 06fcbcb8d044bcd6887415dc87274071bb724596 (rekkanoryo@…): Change the function of the "proxy_ssl" account option to cover regular HTTP requests as well as HTTPS requests. While this does fix the core issue of #11986, there is still more that I need to do to fix his issue. Refs #11986.

* Plucked f08e4f567582f7d28683d043f759a720ee9142e3 (rekkanoryo@…): Make HTTP proxy detection in the yahoo prpls a bit more robust. This should solve some weird proxy related items I couldn't figure out before. Refs #11986.

* Plucked baeaaf7de69d9f99b7545dda73f219292c4dd106 (datallah@…): Attempt to improve handling of HTTP requests on port 80 when there is a HTTP proxy that requires authentication involved. This also has a fix to make sure that we continue to use the same proxy when we are redirected to an alternative URL. I'm tempted to create a purple_proxy_append_proxy_auth_headers(), but that would have to wait until 2.8.0. Refs #11986. Refs #11908.

* Plucked 52fb5cb4cd8795906a7313dd5edde763a4848a3e (qulogic@…): Normalize the remote passport before sending a P2P message. If it's not lowercase, then the switchboard will reject it, causing a whole lot of extra network traffic as Pidgin attempts to resend the same (incorrect) message.

Fixes #11532.

* Plucked e3dd36706068f3b8eabd630ff71d270c145cce42 (markdoliner@…): If we get an error SNAC on the ICBM family and it's missing buddy name then don't fallthrough to the default error handler in misc.c. This was causing purple_parse_msgerr() in oscar.c to get called with different va_args than it was expecting, which caused a crash. Specifically when trying to fetch the ICQ x-status of an offline buddy.

Fixes #11863. This is nosnilmot's patch, I believe. I had no part in it, other than verifying that I do believe it'll fix the crash.

The above revision plucks authorized by Zac West and Robert Vehse.

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!