Cannot connect to Yahoo - "connection refused" error

[christophermerkel]

I'm unable to connect to Yahoo through Pidgin, though I was connecting fine last week on the same machine.
I'm running 2.5.5 for over 2 weeks.
I am successfully able to ping scs.msg.yahoo.com with 0 packets lost at ~49ms.
I have tried changing the port number for Yahoo to all ports I know of that it uses, with no effect: 80, 5050, 8001, 8002
Uninstalling the program and reinstalling from scratch (not copying .purple directory) has no effect on this error, and it reproduces 100% of the time.
This is on Windows XP SP3.

A dump of my Debug window follows, minus my Yahoo username:

(10:29:52) prefs: /purple/savedstatus/default changed, scheduling save. 
(10:29:52) account: Connecting to account ****@yahoo.com 
(10:29:52) connection: Connecting. gc = 03730910 
(10:29:52) dnsquery: Performing DNS lookup for scs.msg.yahoo.com 
(10:29:55) dnsquery: IP resolved for scs.msg.yahoo.com 
(10:29:55) proxy: Attempting connection to 66.163.181.166 
(10:29:55) proxy: Connecting to scs.msg.yahoo.com:5050 with no proxy 
(10:29:55) proxy: Connection in progress 
(10:29:56) proxy: Connecting to scs.msg.yahoo.com:5050. 
(10:29:56) proxy: Error connecting to scs.msg.yahoo.com:5050 (Connection refused.). 
(10:29:56) proxy: Connection attempt failed: Connection refused. 
(10:29:56) account: Disconnecting account 00CC48E8 
(10:29:56) connection: Disconnecting connection 03730910 
(10:29:56) connection: Destroying connection 03730910 
(10:29:57) util: Writing file status.xml to directory C:\Documents and Settings\Chris Merkel\Application Data\.purple 
(10:29:57) util: Writing file C:\Documents and Settings\Chris Merkel\Application Data\.purple\status.xml 
(10:29:58) util: Writing file prefs.xml to directory C:\Documents and Settings\Chris Merkel\Application Data\.purple 
(10:29:58) util: Writing file C:\Documents and Settings\Chris Merkel\Application Data\.purple\prefs.xml 
(10:29:58) util: Writing file accounts.xml to directory C:\Documents and Settings\Chris Merkel\Application Data\.purple 
(10:29:58) util: Writing file C:\Documents and Settings\Chris Merkel\Application Data\.purple\accounts.xml 

[christophermerkel]

Replying to christophermerkel: Other details which may be useful... * I'm not and haven't been using a proxy server * I am able to sign into other Yahoo services, including Mail and Web Messenger * The real Yahoo Messenger program signs in OK * I can reproduce this error while signed in at home, at work, and over a cell modem

[dcs]

Same problem connecting to Yahoo Messenger service through Pidgin.

[tiedyedphoenix]

I'm having the same problem. Though I have Vista if that makes a difference. I've seen other people with this problem, one of whom says he resolved it through resetting his router, but I'm connecting to a university network so I can't try that. It seemed to resolve itself after leaving it alone for a couple hours the other day, but it's back to not working.

[tiedyedphoenix]

Okay, about three seconds after I posted that it started working. ???

[solarisjedi]

This seems to be a yahoo server thing, and this happens to me occasionally with pidgin. Yahoo has many servers and they are round robin'ed in DNS. If you flush your dns cache in windows (ipconfig /flushdns) thus allowing your system to grab another IP of the many yahoo uses 9 out of 10 it will work for you again.

Non-authoritative answer: Name: scs.msg.yahoo.com Address: 66.163.181.183 Name: scs.msg.yahoo.com Address: 66.163.181.166 Name: scs.msg.yahoo.com Address: 66.163.181.167 Name: scs.msg.yahoo.com Address: 66.163.181.168 Name: scs.msg.yahoo.com Address: 66.163.181.169 Name: scs.msg.yahoo.com Address: 66.163.181.170 Name: scs.msg.yahoo.com Address: 66.163.181.171 Name: scs.msg.yahoo.com Address: 66.163.181.172 Name: scs.msg.yahoo.com Address: 66.163.181.179 Name: scs.msg.yahoo.com Address: 66.163.181.180 Name: scs.msg.yahoo.com Address: 66.163.181.181 Name: scs.msg.yahoo.com Address: 66.163.181.182

Mine was failing today on 66.163.181.166 with the exact same symptoms you described, so I flushed my dns cache and ping'ed scs.msg.yahoo.com again to grab a new IP from the list 66.163.181.182, afterward pidgin could connect once again. Your's may have started working again when your system naturally expired that DNS and grabbed a new IP (or that yahoo server started working again).

It seems pidgin is letting the DNS round robin logic handle choosing the servers, which is fine. But yahoo's official client may cycle through them on it's own if one is not responding. (just a guess).

Anyway, flushing your cache may help next time it happens to you.

[dcs]

Thanks, I should have tried that myself...does clean up up the problem.

[deryni]

So is this "fixed" now?

[tibormolnar]

I've been having the same problem with Yahoo for 2 days now. I tried the flushdns + ping method (several times, actually) but it did not help. I still get "Connection refused."

[mihai.birsan]

I had the same problem, and ipconfig /flushdns has fixed it.

[trowe]

I have also been having the problem for 3 days now. The flushdns trick seems to work only randomly. This behavior is occurring on both machines I have setup (WinXP) and I have heard others I know who use Pidgin mention it. I have both 2.5.2 and 2.5.5 running and it occurs on both versions.

[mzpristine]

Same here.. I've tried the suggested fix on here, and it is still an issue. This has only been happening in the last two days with Pidgin.

[tirkster]

I've also started having this problem in Windows XP with pidgin 2.5.5 over the last couple days. The ipconfig /dnsflush seems to work, though it's not a permanent fix and sometimes you have to do it a few times before it works. I don't seem to notice this problem while in Ubuntu, but I can't remember the exact version of pidgin being used there at this time.

[ronjie]

Hello,

I'm new to Pidgin, so I'm not sure about troubleshooting this program. I have used Trillian, and know about troubleshooting on that one. I can't get yahoo to connect either.

I've tried: closing re-opening. reinstalling. mofified account information. disableing and re enableing the account. changed the pager ports.

But I just get connection refused.

Also, on a seperate note: is there anyway to set pidgin to just notify when there's an increase in emails, and not when there's a DECREASE in emails. In other words, I don't need pidgin to get excited when I read an email and is therefore no longer new.

Thanx,

Ron V.

[christophermerkel]

Replying to deryni:

So is this "fixed" now?

[christophermerkel]

Hello deryni,

Pidgin is now working for me after applying the "ipconfig /flushdns" command in an MS-DOS command prompt window per solarisjedi's suggestion.

From other posters in this ticket, I can see that it is not a permanent fix, though. I myself had to apply the /flushdns command twice before my copy of Pidgin successfully connected to Yahoo again. It is of course up to you fellows to close this ticket or keep it open, but if I may suggest, at least forward this item to whomever is working on the Yahoo component of Pidgin so that they may find and create a solution for the next version.

DNS is obviously the main (or at least major) culprit of my issue, that's certain.

I'd like to thank all of you who've posted for your support in helping identify and fix this!

Sincerely,
Chris

PS: My apologies for messing up the ticket's Description. I was not paying attention to where I was typing, and modified the wrong dialog box.

[ronjie]

Guys,

FYI, I should have mentioned this before. I was using trillian before i found pidgin. Just so's we know, I have full access to Yahoo chat and mail notification using trililan, which I'm using now till this situation can get resolved.

Just my 2c.

Ron V.

[CompanyV]

Replying to tirkster:

I've also started having this problem in Windows XP with pidgin 2.5.5 over the last couple days. The ipconfig /dnsflush seems to work, though it's not a permanent fix and sometimes you have to do it a few times before it works. I don't seem to notice this problem while in Ubuntu, but I can't remember the exact version of pidgin being used there at this time.

Thanks for that I had to do ipconfig /flushdns 3 times before it worked . This has been a problem for the past 3 days for me also (yahoo im destroying connection)

[deryni]

ronjie: Can you use something like wireshark to find out what trillian is doing differently? My guess is that they are either trying more servers, or using a different version of the protocol and therefore using different servers. But I know nothing about the Yahoo protocol.

If the issue is simply that some servers being returned by DNS are broken then (other than changing pidgin to try fallback entries) I'm not sure what we can do about this.

[cringer0]

On Windows XP Service Pack 3 with Pidgin 2.5.5, I just had this problem a while ago and the "ipconfig /flushdns" fixed this issue for now. A list of servers to try if the first server fails would be a good idea. Then if a refused error occurs, the next server could be tried and if say, 5 total, including the first server fail, then a failure message could be shown. I chose 5 since it seems like a good number that isn't to large nor to small. Thanks.

[silekonn]

i have the same problem with 255/xp3 as of yesterday, and flushdns does not assist.

[ics]

I have the same problem on Vista Ultimate X64 and Windows 7 X64. Flushdns does not help.

[sarowe]

I have the same problem with 2.5.5/xp,sp3

Debug window reported:

(11:57:57) dnsquery: Performing DNS lookup for scs.msg.yahoo.com (11:57:57) dnsquery: IP resolved for scs.msg.yahoo.com (11:57:57) proxy: Attempting connection to 66.163.181.171 (11:57:57) proxy: Connecting to scs.msg.yahoo.com:5050 with no proxy (11:57:57) proxy: Connection in progress (11:57:58) proxy: Connecting to scs.msg.yahoo.com:5050. (11:57:58) proxy: Error connecting to scs.msg.yahoo.com:5050 (Connection refused.).

"ipconfig /flushdns" worked for me after two tries. After the first try, the IP address for scs.msg.yahoo.com had not changed, but after the second try, the IP address was different, and the connection succeeded.

Pidgin rocks^HH^HH flies!!! (Well, at least 73.1% of the time, anyway...)

[wb6vpm]

I am experiencing the same issue, however the ipoconfig /flushdns did work for me, after the 3rd time.

please fix this!

[darkrain42]

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

[darkrain42]

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

[Iyeru]

Here's my debug log,

(15:23:56) connection: Connecting. gc = 04D330C0
(15:23:56) yahoo: Calculated buddy icon checksum: 95077506(15:23:56) yahoo: buddy icon is up to date. Not reuploading.
(15:23:56) dnsquery: Performing DNS lookup for scs.msg.yahoo.com
(15:23:56) dnsquery: IP resolved for scs.msg.yahoo.com
(15:23:56) proxy: Attempting connection to 66.163.181.166
(15:23:56) proxy: Connecting to scs.msg.yahoo.com:5050 with no proxy
(15:23:56) proxy: Connection in progress
(15:23:57) proxy: Connecting to scs.msg.yahoo.com:5050.
(15:23:57) proxy: Error connecting to scs.msg.yahoo.com:5050 (Connection refused.).
(15:23:57) proxy: Connection attempt failed: Connection refused.
(15:23:57) account: Disconnecting account 026F3928
(15:23:57) connection: Disconnecting connection 04D330C0
(15:23:57) connection: Destroying connection 04D330C0

ipconfig hasn't worked yet. Sometimes after 10-20 minutes, this resolves itself.

[dandv]

I edited my account settings and replaced 'scs.msg.yahoo.com' with one of the IPs it resolves to. That fixed the connectivity issue.

Would be very nice if Pidgin had this feature built-in.

[ronjie]

Replying to deryni:

ronjie: Can you use something like wireshark to find out what trillian is doing differently? My guess is that they are either trying more servers, or using a different version of the protocol and therefore using different servers. But I know nothing about the Yahoo protocol. If the issue is simply that some servers being returned by DNS are broken then (other than changing pidgin to try fallback entries) I'm not sure what we can do about this.

Sorry it took me so long to reply to this... I just got it.

Scratch trillian... it's not connecting either... I can however connect with yahoo im

Ron V.

[solarisjedi]

Trillian will be the same as pidgin in DNS lookups. They simply use the systems OS resolver (gethostbyname if I'm not mistaken). The OS resolver does all the work of looking up the IP and nowadays usually putting it in a resolver cache. (hence the flushdns on windows to purge the cache, and other various tools on unix systems)

I think in order to pull all IP's from a query and rotate thru them, pidgin (and even trillian) would possibly need to write their own form of a dns resolver/nslookup mechanism to incorporate into the IM program. I'm not a developer however, that may or may not be a pain since pidgin is a cross platform app, and also possibly negate any benefits of using the systems builtin libraries for DNS resolution.

I've noticed this happening to me almost every time I sign in of a morning. It used to be once in a blue moon, but now it's every day. I just keep flushing the resolver cache until it connects. Dandy's work around above works good too for short term. I'd probably forget I had done that however if that single IP stopped working LOL.

[Coyote]

No doubt Yahoo has some dead hosts in their round-robin DNS, but I've had it consistently fail to connect after a reboot on two different machines.

Also consider your network's router/gateway might be caching lookups. I'll flush mine out and see if it connects.

[dg]

Only 8 of 18 hosts configured as scs.msg.yahoo.com are answering right now:

Flushing did not work for me (~4 times). Adding one of the working hosts to scs.msg.yahoo.com in c:\windows\system32\drivers\etc\hosts.

# nslookup scs.msg.yahoo.com
Server:         4.2.2.1
Address:        4.2.2.1#53

Non-authoritative answer:
Name:   scs.msg.yahoo.com
Address: 66.163.181.169
Name:   scs.msg.yahoo.com
Address: 66.163.181.170
Name:   scs.msg.yahoo.com
Address: 66.163.181.171
Name:   scs.msg.yahoo.com
Address: 66.163.181.172
Name:   scs.msg.yahoo.com
Address: 66.163.181.173
Name:   scs.msg.yahoo.com
Address: 66.163.181.174
Name:   scs.msg.yahoo.com
Address: 66.163.181.175
Name:   scs.msg.yahoo.com
Address: 66.163.181.176
Name:   scs.msg.yahoo.com
Address: 66.163.181.177
Name:   scs.msg.yahoo.com
Address: 66.163.181.166
Name:   scs.msg.yahoo.com
Address: 66.163.181.167
Name:   scs.msg.yahoo.com
Address: 66.163.181.168



# nslookup scs.msg.yahoo.com | 
             grep -i Address | 
             grep -v 4.2.2.1 | 
             while read a b; do 
                 echo $b; done |
    xargs nmap -sT -p 5050 -oG -

# nmap 3.70 scan initiated Tue Apr 21 10:02:09 2009 as: nmap -sT -p 5050 -oG - 66.163.181.168 66.163.181.169 66.163.181.170 66.163.181.171 66.163.181.172 66.163.181.173 66.163.181.174 66.163.181.175 66.163.181.176 66.163.181.177 66.163.181.178 66.163.181.179 66.163.181.180 66.163.181.181 66.163.181.182 66.163.181.183 66.163.181.166 66.163.181.167

Host: 66.163.181.168 (cs103.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.169 (cs104.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.170 (cs105.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.171 (cs106.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.172 (cs107.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.173 (cs108.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.174 (cs109.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.175 (cs110.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.176 (cs111.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.177 (cs112.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.178 (cs113.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.179 (cs114.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.180 (cs115.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.181 (cs116.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.182 (cs117.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.183 (cs118.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.166 (cs101.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.167 (cs102.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///

[dg]

"Adding one of the working hosts to scs.msg.yahoo.com in c:\windows\system32\drivers\etc\hosts."

Adding one of the working hosts to etc\hosts DID work around the issue for me.

[datallah]

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

[scurrilous]

I'm having the same issue. One thing I notice is that Yahoo Messenger seems to be using an entirely different set of hosts. It's connected to 76.13.15.53:5050 (cs125.msg.ac4.yahoo.com), whereas scs.msg.yahoo.com resolves to this (note that the majority are down):

$ nslookup scs.msg.yahoo.com | grep -i Address | grep -v \#53 | cut -d ' ' -f 2 | xargs xargs nmap -sT -p 5050 -oG - # Nmap 4.62 scan initiated Wed Apr 22 13:14:23 2009 as: nmap -sT -p 5050 -oG - 66.163.181.178 66.163.181.179 66.163.181.180 66.163.181.181 66.163.181.182 66.163.181.183 66.163.181.166 66.163.181.167 66.163.181.168 66.163.181.169 66.163.181.170 66.163.181.171 66.163.181.172 66.163.181.173 66.163.181.174 66.163.181.175 66.163.181.176 66.163.181.177 Host: 66.163.181.178 (cs113.msg.mud.yahoo.com) Ports: 5050/open/tcp//mmcc/// Host: 66.163.181.179 (cs114.msg.mud.yahoo.com) Ports: 5050/open/tcp//mmcc/// Host: 66.163.181.180 (cs115.msg.mud.yahoo.com) Ports: 5050/open/tcp//mmcc/// Host: 66.163.181.181 (cs116.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.182 (cs117.msg.mud.yahoo.com) Ports: 5050/open/tcp//mmcc/// Host: 66.163.181.183 (cs118.msg.mud.yahoo.com) Ports: 5050/open/tcp//mmcc/// Host: 66.163.181.166 (cs101.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.167 (cs102.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.168 (cs103.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.169 (cs104.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.170 (cs105.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.171 (cs106.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.172 (cs107.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.173 (cs108.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.174 (cs109.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.175 (cs110.msg.mud.yahoo.com) Ports: 5050/closed/tcp//mmcc/// Host: 66.163.181.176 (cs111.msg.mud.yahoo.com) Ports: 5050/open/tcp//mmcc/// Host: 66.163.181.177 (cs112.msg.mud.yahoo.com) Ports: 5050/open/tcp//mmcc///

[scurrilous]

BTW, I notice that Yahoo Messenger contains the string "scsd.msg.yahoo.com", which yields a lot more open hosts (though still not the one it seems to use):

nslookup scsd.msg.yahoo.com | grep -i Address | grep -v \#53 | cut -d ' ' -f 2 | xargs xargs nmap -sT -p 5050 -oG -
# Nmap 4.62 scan initiated Wed Apr 22 13:33:14 2009 as: nmap -sT -p 5050 -oG - 66.163.181.179 66.163.181.180 66.163.181.181 66.163.181.182 66.163.181.183 66.163.181.184 66.163.181.185 66.163.181.186 66.163.181.187 66.163.181.188 66.163.181.189 66.163.181.193
Host: 66.163.181.179 (cs114.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.180 (cs115.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.181 (cs116.msg.mud.yahoo.com)  Ports: 5050/closed/tcp//mmcc///
Host: 66.163.181.182 (cs117.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.183 (cs118.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.184 (cs119.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.185 (cs120.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.186 (cs121.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.187 (cs122.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.188 (cs123.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.189 (cs124.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///
Host: 66.163.181.193 (cs125.msg.mud.yahoo.com)  Ports: 5050/open/tcp//mmcc///

[nerddtvg]

I see what scurrilous saw with the DNS strings, however my Yahoo client doesn't lookup these hosts. It instead does the following:

Lookup A record for vcs1.msg.yahoo.com (68.180.216.31)

Sends HTTP request to IP: GET /capacity HTTP/1.1 Cache-Control: no-cache Host: vcs1.msg.yahoo.com User-Agent: Mozilla/5.0 Connection: Close

Response: HTTP/1.1 200 OK Content-Length: 46 Content-Type: text/plain; charset=utf-8 Cache-Control: max-age=0, must-revalidate Expires: Sun, 10 Jun 2007 12:01:01 GMT COLO_CAPACITY=1 CS_IP_ADDRESS=68.180.217.30

Then it connects to 68.180.217.30:5050 for paging. The rDNS comes back as cs125.msg.sp1.yahoo.com. which seems to follow a similar pattern as the lookups Pidgin does.

I'm not an expert in the protocols here, so I'm just guessing. I compared with Pidgin does with the IP it looks up for the paging server and saw the same results as with the connections Yahoo made. It seems that Yahoo has changed their protocols a bit. Hope this helps.

[kharris]

Not sure if this will help or not, but it might give some insight. I used telnet scs.msg.yahoo.com 5050 Trying 66.163.181.181... telnet: connect to address 66.163.181.181: Connection refused Trying 66.163.181.181... telnet: connect to address 66.163.181.181: Connection refused Trying 66.163.181.181... telnet: connect to address 66.163.181.181: Connection refused Trying 66.163.181.181... telnet: connect to address 66.163.181.181: Connection refused Trying 66.163.181.182... Connected to scs.msg.yahoo.com. Escape character is '^]'. ] telnet> quit Connection closed.

As you can see, eventually it connects (and so does Pidgin). Perhaps an extended timeout or faster retry?

[briansemerick]

Replying to scurrilous:

BTW, I notice that Yahoo Messenger contains the string "scsd.msg.yahoo.com", which yields a lot more open hosts (though still not the one it seems to use): }}}

I did this and it worked. Thanks!

[tirkster]

One thing to note, as people talk about this issue, I am not sure it is a problem with pidgin per se, as I have none of these issues in the LINUX version, only in the windows version. So it has something to do with windows and pidgin.

[richalger]

Replying to tirkster:

One thing to note, as people talk about this issue, I am not sure it is a problem with pidgin per se, as I have none of these issues in the LINUX version, only in the windows version. So it has something to do with windows and pidgin.

I am on windows too. Here is my debug window output with user names replaced

(09:11:08) account: Connecting to account <yahooId>
(09:11:08) connection: Connecting. gc = 01A45138
(09:11:08) dnsquery: Performing DNS lookup for scs.msg.yahoo.com
(09:11:08) dnsquery: IP resolved for scs.msg.yahoo.com
(09:11:08) proxy: Attempting connection to 66.163.181.172
(09:11:08) proxy: Connecting to scs.msg.yahoo.com:5050 with no proxy
(09:11:08) proxy: Connection in progress
(09:11:10) util: Writing file prefs.xml to directory C:\Documents and Settings\<windowsUsername>\Application Data\.purple
(09:11:10) util: Writing file C:\Documents and Settings\<windowsUsername>\Application Data\.purple\prefs.xml
(09:11:10) proxy: Connecting to scs.msg.yahoo.com:5050.
(09:11:10) proxy: Error connecting to scs.msg.yahoo.com:5050 (Connection refused.).
(09:11:10) proxy: Connection attempt failed: Connection refused.
(09:11:10) account: Disconnecting account 00C83840
(09:11:10) connection: Disconnecting connection 01A45138
(09:11:10) connection: Destroying connection 01A45138
(09:11:13) util: Writing file accounts.xml to directory C:\Documents and Settings\<windowsUsername>\Application Data\.purple
(09:11:13) util: Writing file C:\Documents and Settings\<windowsUsername>\Application Data\.purple\accounts.xml
(09:11:16) prefs: /pidgin/debug/width changed, scheduling save.
(09:11:16) prefs: /pidgin/debug/height changed, scheduling save.
(09:11:21) util: Writing file prefs.xml to directory C:\Documents and Settings\<windowsUsername>\Application Data\.purple
(09:11:21) util: Writing file C:\Documents and Settings\<windowsUsername>\Application Data\.purple\prefs.xml

[kharris]

I am running pidgin on Windows, but the telnet post I submitted was from my Linux machine.

[datallah]

Just to clarify - this isn't at all related to the OS except that perhaps the DNS caching might work differently on different OSes.

[tirkster]

It must be tied to the OS to some degree, perhaps as you say in the caching methods, because this only happens for me with the Windows, none of my LINUX machines have the issue, but every Windows machine I use I must do the ipconfing /flushdns. So it's OS related in a way, in that either the OS has a bug in how it deals with the dns cache, or pidgin is using the dns cache incorrectly.

[dg]

Replying to tirkster:

It must be tied to the OS to some degree, perhaps as you say in the caching methods, because this only happens for me with the Windows, none of my LINUX machines have the issue, but every Windows machine I use I must do the ipconfing /flushdns. So it's OS related in a way, in that either the OS has a bug in how it deals with the dns cache, or pidgin is using the dns cache incorrectly.

I am in a corporate environment with an AD domain and multiple DNS servers. Some of my servers are reporting 12 hosts for "scs" and some are reporting 18. I suspect the 12 results I have are mostly dead hosts.

It looks like the DNS server is a confounding issue here.

[nerddtvg]

Replying to tirkster:

One thing to note, as people talk about this issue, I am not sure it is a problem with pidgin per se, as I have none of these issues in the LINUX version, only in the windows version. So it has something to do with windows and pidgin.

I would not restrict this to just Windows. I had an issue with my Linux box at work and I fixed it by entering a permanent IP of a working server. However, my DNS server for that computer might be a corporate Windows server. I will have to verify that tomorrow when I get back as I don't remember if I changed it or not.

But I would agree it could easily be OS dependent on how it pulls IPs from DNS. If Windows does not give a list of IPs via the system call, Pidgin would not have anything to fall back onto. This would require a DNS library be included in Pidgin and would be a bad hack in that the OS should provide this functionality already.

[LiquidLight]

Just a note to explain some of this behavior:

I don't know for certain (I'm not a Yahoo admin), but the primary reason to setup a round robin DNS is to establish some very simple load balancing across a non-clustered server grid. Given the behavior that we're seeing, and the HUGE influx of spam SMS coming out of the Yahoo network, I'd suggest that the servers that become unresponsive are not down, they're just maxed out and are refusing new connections of any kind in order to preserve stability.

This explains the behavior that's been seen up to this point, and from a connection handler perspective should be fairly easy to correct, pull multiple server addresses from the resolution and cycle through a preset number (say 10 given the very quick failure time) in the event of a connection failure.

Unfortunately the only way to confirm my theory would be to get in touch with a Yahoo admin, and I rather doubt that they'd be willing to discuss those numbers.

In the interim, I just keep clicking Reconnect :D

Thanks for a great app!

[nerddtvg]

No matter the reason the servers are having problems, I think it is a problem inside libpurple.

http://google.com/codesearch/p?hl=en#7OEMyONFOOA/pidgin-2.0.0beta7/libpurple/dnsquery.c&q=purple_dnsquery_a%20package:pidgin&l=836

Newest revision: http://developer.pidgin.im/viewmtn/revision/file/e54933232e44b0c259cee6eff8f9354e6b94fe5d/libpurple/dnsquery.c

gethostbyname() returns a structure that can contain a list of addresses [h_addr_list] (for DNS round-robin load balancing) as well a single entry that is the first entry in the list as h_addr. According to this MAN Page it is for backwards compatability. However, I think that libpurple needs to take this list into account as it is there for fall-back purposes and the library is ignoring that.

Now that first link goes to the non-Win32 function used, but the same problem occurs in Windows in the dns_thread() function in the same file. It may only happen if HAVE_GETADDRINFO is false as I can't confirm if libpurple's use of getaddrinfo might break it either.

A similar patch (#2930) has been proposed allowing people to specify multiple servers in the account settings. This shows that something needs to be done about fall-back choices and we should by default use DNS information that we are given for that purpose.

Of course, I could be completely wrong here (which happens a lot) so I'm sorry if I am. I would attempt to patch this myself and test it but I just don't have the time for several weeks. If I do get some extra time, I may just run some tests using the base code from libpurple to simulate what happens but I can't promise it.

As a side note, hitting Reconnect doesn't work for me as the addresses are cached and the first address returned on the list is going to be the same until that list is updated, so Pidgin would still use the same bad server to connect to. I have to flush my DNS several times before it will get a new server.

[rekkanoryo]

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

[QuLogic]

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

[nerddtvg]

Just to update what I said earlier, I can not confirm what my problem was on my Fedora machine at work. The issue has not come back on it and I haven't done any testing with Wireshark to see what servers it is searching for and using. So it may be only on the Windows port.

[nerddtvg]

Replying to nerddtvg:

Just to update what I said earlier, I can not confirm what my problem was on my Fedora machine at work. The issue has not come back on it and I haven't done any testing with Wireshark to see what servers it is searching for and using. So it may be only on the Windows port.

Sorry to put in another update to this, but I wanted to clarify something. I realized that the computer I was having problems with was my desktop at school. It is an OpenSolaris? box running the 2.5.1 package distributed via Sun's package manager. It was the same DNS resolver issue where it only tried one IP according to my logs and failed.

[darkrain42]

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

[darkrain42]

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

[steevithak]

Started having this problem today for the first time ever. I'm running Redhat Fedora GNU/Linux v11, Pidgin v2.5.6-1, and libpurple v2.5.6-1. The /etc/hosts work-around described in bug 9386 solved it for me, so it seems to be a DNS issue of some sort.

[quamer]

I have the same trouble connecting to yahoo... I'm using windows vista and pidgin version 2.5.6

(16:52:10) account: Connecting to account xxxxxxx
(16:52:14) connection: Connecting. gc = 045FA028
(16:52:14) util: Writing file C:\Users\xxxxxxx\AppData\Roaming\.purple\icons\d39ce39c5e4642b75e8da35fca34ff77ffddb2b1.png
(16:52:14) yahoo: Calculated buddy icon checksum: 39759714(16:52:14) yahoo: buddy icon is up to date. Not reuploading.
(16:52:14) dnsquery: Performing DNS lookup for scs.msg.yahoo.com
(16:52:14) dnsquery: IP resolved for scs.msg.yahoo.com
(16:52:14) proxy: Attempting connection to 68.180.217.10
(16:52:14) proxy: Connecting to scs.msg.yahoo.com:5050 with no proxy
(16:52:14) proxy: Connection in progress
(16:52:15) proxy: Connecting to scs.msg.yahoo.com:5050.
(16:52:15) util: Writing file accounts.xml to directory C:\Users\xxxxxxx\AppData\Roaming\.purple
(16:52:15) util: Writing file C:\Users\xxxxxxx\AppData\Roaming\.purple\accounts.xml
(16:52:15) yahoo: 94 bytes to read, rxlen is 114
(16:52:15) yahoo: Yahoo Service: 0x57 Status: 1
(16:52:15) yahoo: yahoo status: 0

I read in yahoo messenger blog that old version of yahoo will be out soon, may be pidgin use a old protocol version... I don't know.

[tonyg]

wireshark packet capture of the yahoo issue

[tonyg]

hi, i am having the same issue, flush does not help. i am on suse 11.1 and using pidgin 2.5.6 I have uploaded a wireshark packet capture and here is the debug output

Pidgin Debug Log : Thu 18 Jun 2009 08:30:26 PM EDT
(20:28:21) account: Connecting to account tonyguadagno
(20:28:21) connection: Connecting. gc = 0x7fa922c857a0
(20:28:21) dns: DNS query for 'scs.msg.yahoo.com' queued
(20:28:21) dns: Wait for DNS child 6296 failed: No child processes
(20:28:21) dns: Created new DNS child 7097, there are now 1 children.
(20:28:21) dns: Successfully sent DNS request to child 7097
(20:28:21) dns: Got response for 'scs.msg.yahoo.com'
(20:28:21) dnsquery: IP resolved for scs.msg.yahoo.com
(20:28:21) proxy: Attempting connection to 68.180.217.6
(20:28:21) proxy: Connecting to scs.msg.yahoo.com:5050 with no proxy
(20:28:21) proxy: Connection in progress
(20:28:21) proxy: Connecting to scs.msg.yahoo.com:5050.
(20:28:21) yahoo: 100 bytes to read, rxlen is 120
(20:28:21) yahoo: Yahoo Service: 0x57 Status: 1
(20:28:21) yahoo: yahoo status: 99
(20:28:26) util: Writing file accounts.xml to directory /home/tonyg/.purple
(20:28:26) util: Writing file /home/tonyg/.purple/accounts.xml
(20:28:41) msn: C: NS 000: PNG
(20:28:41) msn: S: NS 000: QNG 50

[darkrain42]

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

[valholla]

I found this while researching this issue. I am not sure how "valid" it is... if a pidgin developer would please comment on it.

http://www.celticwolf.com/useful-information/faqs/26-pidgin-yahoo

[pEEf]

(version: 2.56 win32) This was happening to me a few months ago, then it cleared up on it's own. Now it's happening again. The only way I can connect is by using 66.163.181.166 as chat server, then everything works normally. Is yahoo really upgrading their servers? If so, what's that mean for us Pidgin'ers?

[nerddtvg]

Replying to pEEf:

(version: 2.56 win32) This was happening to me a few months ago, then it cleared up on it's own. Now it's happening again. The only way I can connect is by using 66.163.181.166 as chat server, then everything works normally. Is yahoo really upgrading their servers? If so, what's that mean for us Pidgin'ers?

I think this puts us back to where we were before. There are two issues here as shown by the link valholla provided. Pidgin doesn't use all returned DNS entries, which is a minor bug and while it needs to be fixed, it's not a major problem that needs to be immediately solved. And second, Yahoo is updating their systems so Pidgin is having issues logging into some of them.

If libpurple used all the returned DNS, it would eventually find a good server and connect, however if Yahoo is going to eventually update all their systems, we'll be back to square one if libpurple doesn't support the new system.

However, the article linked above says that 2.6.0 will support the new system. So it may be near getting pushed into the main source code. This will in turn fix the issue, but there is no clear date on when this will happen.

[darkrain42]

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

[unikuser]

Looks like Yahoo is updating their servers to stop supporting legacy protocol. Pidgin should use new login method to fix this issue permanently. All servers which are working for now would cease to work probably in August.

http://www.ymessengerblog.com/blog/2009/06/09/we’re-retiring-versions-60-to-75/

http://sourceforge.net/mailarchive/forum.php?thread_name=2e95f9b80902181546s7293ad0bmbd44ca768d7e68f6%40mail.gmail.com&forum_name=libyahoo2-users

[todo]

Replying to valholla:

I found this while researching this issue. I am not sure how "valid" it is... if a pidgin developer would please comment on it. http://www.celticwolf.com/useful-information/faqs/26-pidgin-yahoo

My pidgin 2.5.6 doesn't work for me. But my old gaim 1.5.0 is fine. This tells me they still support both the old auth method and the new auth method (which is in http://pidgin.im/pipermail/devel/2009-May/008122.html).

I deduct the latest Yahoo change is in enforcing their current protocol with the "current" (it's not new to Y!, but new to pidgin) auth method. Pidgin move to protocol 16, so it could support p2p file transfer and other fancy features in the new protocol. However, I vaguely remember talks about not able to crack the auth method in protocol 16. However, since Y allows people to use old auth method with the new protocol, there isn't much incentive for pidgin to move to the new auth method, or at least until now. :)

For those (I am one of them) that don't care about the "fancy" features, could we somehow go back down to protocol 14 or lower. So we can use pidgin.

The other option is to use gaim 1.5.x. However, I cannot seemed to find any old binaries on the web.

[ardsouza]

I used to face this problem earlier but flushing the DNS using "ipconfig /flushdns" worked for me. Since the last few hours, even this didn't work for me. Now, I changed the Pager server to 66.163.181.173. This did the trick.

So far so good. Need to see how long does this last.

[deryni]

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

[deryni]

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

[gagern]

Coming from #9414, I find that the "connection refused" error mentioned in the subject here doesn't apply to me, but the more recent comments probably do.

[mkmurray]

Coming from #9391, we aren't having the "connection refused" error either, you'll have to see the closed ticket that was marked as a duplicate in order to see the specific symptoms. I'm not so convinced 9391 is a duplicate of this ticket. The flush DNS didn't work for our situation.

[pozunmv]

Coming from #9414

@mkmurray, the flushdns wont necessarily work because the dns still grabs whichever server is next up in the round robin scheme. Since apparently more and more servers are being migrated to the new protocol, the likely hood that you will receive a compatible server is pretty low. To get around this you can setup the server in your connection to use one of the known servers which still works (who knows how long this will still be up). The server I am using is 66.163.181.167 which is cs102.msg.mud.yahoo.com

Also the title to this thread is misleading for some of the "duplicate" threads because we are not receiving the mentioned error, while the cause is the same the title is misleading and not applicable to the issues the most recent people have been having. Pidgin just sits there saying its connecting, no connection refused message. This could possibly be a different bug because pidgin doesnt seem to be timing out the connection, it appears to be infinitely trying to connect even though the initial connection attempt never makes it through.

Should this be raised as a separate issue since no timeout is happening on the connection attempt?

[mkmurray]

Thank you. Changing the Yahoo "Paging Server" to "cs102.msg.mud.yahoo.com" did indeed get me connected again. This is a solution (albiet a temporary one) to #9391.

[acker]

Replying to todo:

However, since Y allows people to use old auth method with the new protocol, there isn't much incentive for pidgin to move to the new auth method, or at least until now. :)

I've created a binary patch for libyahoo.dll that will change authentification from version 15 to 12 (one byte change). Patch is available here:

www.tehnica.org/patch/pidgin.2.5.6-patch.exe

I know you can't really trust it, maybe some will have the technical knowledge to confirm is ok. I've tried it on libyahoo.dll versions 2.4.2 (compiled by me) and the original 2.5.6. Also, some reported working on 2.5.5.

The inconvenient with this patch is that you will get a message from Yahoo that the protocol will expire on August 15.

File packed with UPX, created with dUP from diablo2oo2.

Manual patch:

C:\Program Files\Pidgin\plugins>fc /b libyahoo.dll libyahoo.dll.BAK
Comparing files libyahoo.dll and LIBYAHOO.DLL.BAK
00014EB7: 0C 0F

C:\Program Files\Pidgin\plugins>md5sum libyahoo.dll.BAK
f8cb9461fcf8141e5f33051afcd8237f *libyahoo.dll.BAK

ProductVersion 2.5.6

[valholla]

I just compiled the development snapshot from last night on fedora 10 and yahoo works like a charm.

does anyone have a rough time line on the release?

[LeonLanford]

I've been using pidgin for more than one year then I got this problem for the first time 2 weeks ago, my cousin and friend also experiencing the same problem, I thought upgrading pidgin to 2.5.6 solve the problem but it's not. So today I searched about the problem and fixed the problem by changing the server to cs102.msg.mud.yahoo.com, pidgin should've updated the default server to cs102.msg.mud.yahoo.com in the next release

[darkfly]

I just had the same problems, I applied the patch as listed above, and it works now, however just though I'd share with everyone a system message from Yahoo:

Warning: This version of Messenger will expire on August 15, 2009. Please upgrade to the latest supported version: http://messenger.yahoo.com/download .

[nerddtvg]

I just tried out the new 2.5.7 release that was meant to fix this problem by implementing protocol version 16, and it worked for me. Tried flushing DNS several times to get Pidgin to try other servers and it still worked. I obviously can't test all the servers, but figured it would be good to post a follow-up on it.

[dlevine278]

Question for the folks who are closest to the protocol change:

do you anticipate having to issue another patch in August because Y! authentication changed again and/or the patch is only a short-term solution OR the patch should suffice based on what you know and what Y! has publicly commented on?

[acker]

Replying to dlevine278:

do you anticipate having to issue another patch in August because Y! authentication changed again and/or the patch is only a short-term solution OR the patch should suffice based on what you know and what Y! has publicly commented on?

The (binary) patch worked by downgrading the version from 15 to 12. The version 12 had the August limitation, the 16 (!) introduced in pidgin 2.5.7 is going to work for a much longer time I think. The 15 version is no longer working on many Yahoo servers.

Hope this clears it up. Use the latest version of pidgin (2.5.7) !

[dlevine278]

Thank you for the prompt replay and to all those involved in getting a patch out!!!!

[wb6vpm]

i am still having the issue see log entry:

Pidgin Debug Log : 6/23/2009 21:44:00
(21:43:06) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:06) proxy: No environment settings found, not using a proxy
(21:43:08) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:08) proxy: No environment settings found, not using a proxy
(21:43:10) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:10) proxy: No environment settings found, not using a proxy
(21:43:11) util: Writing file prefs.xml to directory C:\Users\mikeo\AppData\Roaming\.purple
(21:43:11) util: Writing file C:\Users\mikeo\AppData\Roaming\.purple\prefs.xml
(21:43:11) account: Connecting to account wb6vpm
(21:43:11) connection: Connecting. gc = 0362EF88
(21:43:11) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:11) proxy: No environment settings found, not using a proxy
(21:43:11) dnsquery: Performing DNS lookup for 66.163.181.173

(21:43:11) dnsquery: IP resolved for 66.163.181.173
(21:43:11) proxy: Attempting connection to 66.163.181.173
(21:43:11) proxy: Connecting to 66.163.181.173
:5050 with no proxy
(21:43:11) proxy: Connection in progress
(21:43:12) proxy: Connecting to 66.163.181.173
:5050.
(21:43:12) proxy: Error connecting to 66.163.181.173
:5050 (Connection refused.).
(21:43:12) proxy: Connection attempt failed: Connection refused.
(21:43:12) account: Disconnecting account 00CA9170
(21:43:12) connection: Disconnecting connection 0362EF88
(21:43:12) connection: Destroying connection 0362EF88
(21:43:12) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:12) proxy: No environment settings found, not using a proxy
(21:43:14) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:14) proxy: No environment settings found, not using a proxy
(21:43:16) util: Writing file accounts.xml to directory C:\Users\mikeo\AppData\Roaming\.purple
(21:43:16) util: Writing file C:\Users\mikeo\AppData\Roaming\.purple\accounts.xml
(21:43:16) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:16) proxy: No environment settings found, not using a proxy
(21:43:18) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:18) proxy: No environment settings found, not using a proxy
(21:43:19) msn: Releasing buddy icon request
(21:43:20) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:20) proxy: No environment settings found, not using a proxy
(21:43:22) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:22) proxy: No environment settings found, not using a proxy
(21:43:24) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:24) proxy: No environment settings found, not using a proxy
(21:43:26) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:26) proxy: No environment settings found, not using a proxy
(21:43:28) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:28) proxy: No environment settings found, not using a proxy
(21:43:30) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:30) proxy: No environment settings found, not using a proxy
(21:43:32) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:32) proxy: No environment settings found, not using a proxy
(21:43:34) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:34) proxy: No environment settings found, not using a proxy
(21:43:36) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:36) proxy: No environment settings found, not using a proxy
(21:43:38) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:38) proxy: No environment settings found, not using a proxy
(21:43:40) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:40) proxy: No environment settings found, not using a proxy
(21:43:42) account: Connecting to account wb6vpm
(21:43:42) connection: Connecting. gc = 0362FA08
(21:43:42) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:42) proxy: No environment settings found, not using a proxy
(21:43:42) dnsquery: Performing DNS lookup for 66.163.181.173

(21:43:42) dnsquery: IP resolved for 66.163.181.173
(21:43:42) proxy: Attempting connection to 66.163.181.173
(21:43:42) proxy: Connecting to 66.163.181.173
:5050 with no proxy
(21:43:42) proxy: Connection in progress
(21:43:42) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:42) proxy: No environment settings found, not using a proxy
(21:43:43) proxy: Connecting to 66.163.181.173
:5050.
(21:43:43) proxy: Error connecting to 66.163.181.173
:5050 (Connection refused.).
(21:43:43) proxy: Connection attempt failed: Connection refused.
(21:43:43) account: Disconnecting account 00CA9170
(21:43:43) connection: Disconnecting connection 0362FA08
(21:43:43) connection: Destroying connection 0362FA08
(21:43:44) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:44) proxy: No environment settings found, not using a proxy
(21:43:46) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:46) proxy: No environment settings found, not using a proxy
(21:43:47) util: Writing file accounts.xml to directory C:\Users\mikeo\AppData\Roaming\.purple
(21:43:47) util: Writing file C:\Users\mikeo\AppData\Roaming\.purple\accounts.xml
(21:43:48) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:48) proxy: No environment settings found, not using a proxy
(21:43:50) imgstore: Error reading : Failed to open file '': Invalid argument
(21:43:50) imgstore: Error reading : Failed to open file '': Invalid argument
(21:43:50) imgstore: Error reading : Failed to open file '': Invalid argument
(21:43:50) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:50) proxy: No environment settings found, not using a proxy
(21:43:52) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:52) proxy: No environment settings found, not using a proxy
(21:43:56) Gtk: Could not find the icon '"C:\Windows\system32\wusa.exe",-101'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
	http://icon-theme.freedesktop.org/releases
(21:43:56) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:56) proxy: No environment settings found, not using a proxy
(21:43:58) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:43:58) proxy: No environment settings found, not using a proxy
(21:44:00) proxy: Windows Proxy Settings set to autodetect (not supported).
(21:44:00) proxy: No environment settings found, not using a proxy
(21:44:00) prefs: /pidgin/filelocations/last_save_folder changed, scheduling save.

[wb6vpm]

may have been my fault, forgot to change the IP back to the correct pager host, scs.msg.yahoo.com, will update if i see problem happen again