Opened 12 years ago

Closed 10 years ago

#2825 closed patch (fixed)

Pidgin cannot reconnect after changing networks

Reported by: novakyu Owned by: darkrain42
Milestone: 2.6.0 Component: libpurple
Version: 2.1.1 Keywords:
Cc:

Description

Pidgin cannot automatically reconnect after changing networks. Automatic and manual reconnection attempts result in error, such as: "novakyu disconnected: Could not connec... Error resolving login.oscar.aol.com: Name or service not known".

This happens for me when I put my laptop to hibernate, come to work, and boot it up to use the network there (so this *might* be related to the hibernation). I should also note that I use wireless connection at home (eth2), and wired connection at work (eth1).

Restarting pidgin seems to fix it (i.e. it can connect again) for the time being, but it should be able to re-connect to the networks when the network + network interface is changed while it's running.

Thank you,

Andrew

P.S. I am not sure if this makes a difference, but I am using Dell Inspiron 700m, running current Debian stable (etch). My version of Pidgin is compiled from source from pidgin.im website, after running "apt-get build-dep gaim" (the only non-stable, or backported packages on my system are related to video stuffs, like mplayer, etc.).

Attachments (3)

pidgin_san.log (73.7 KB) - added by novakyu 12 years ago.
sanitized (removed all lines referring to @gmail.com and "Buddy") output from "pidgin -d", until pidgin cannot reconnect on its own (Internet was available through the router 192.168.2.1, via eth2) and had to be restarted.
res_init_bench.c (841 bytes) - added by dyfrgi 10 years ago.
c program to benchmark res_init overhead
reinit-resolver.patch (2.8 KB) - added by darkrain42 10 years ago.
Call res_init() if DNS queries return errors

Download all attachments as: .zip

Change History (18)

comment:1 follow-ups: Changed 12 years ago by wlad

Comment regarding the bug I filed that was duped to this one: The crash does not appear in v2.0.2, so it appears to be a regression issue, at least for winpidgin.

Changed 12 years ago by novakyu

sanitized (removed all lines referring to @gmail.com and "Buddy") output from "pidgin -d", until pidgin cannot reconnect on its own (Internet was available through the router 192.168.2.1, via eth2) and had to be restarted.

comment:2 in reply to: ↑ 1 Changed 12 years ago by novakyu

Replying to wlad:

Comment regarding the bug I filed that was duped to this one: The crash does not appear in v2.0.2, so it appears to be a regression issue, at least for winpidgin.

I don't think this is the same bug---Pidgin does not crash in this case (although it did seem to crash every once in a while when trying to connect to Google Talk, this cannot be reliably reproduced). However, it does need to be restarted manually before it can connect to either AIM or Google Talk servers.

comment:3 in reply to: ↑ 1 ; follow-up: Changed 12 years ago by Iyeru

Replying to wlad:

Comment regarding the bug I filed that was duped to this one: The crash does not appear in v2.0.2, so it appears to be a regression issue, at least for winpidgin.

The connection error "Name of service not known" Happens when Linux (Debian based so far, like Xubuntu, which I run) tries to use Pidgin to connect after starting up the computer (hibernate is the same as shutdown.)

Although you can fix the problem by clicking the error and hitting the connect button on the Debian Version of Pidgin. This problem doesn't appear in Pidgin 2.2.1 for Windows, but does appear in Linux Pidgin 2.2.1 that is bundled with X/Ubuntu family OS.

comment:4 in reply to: ↑ 3 Changed 12 years ago by Iyeru

It is also known that MSN gives a "could not connect" error in the same manner. Yahoo IM is the only part of Pidgin that I have that starts up when Pidgin does.

comment:5 Changed 12 years ago by novakyu

*bump*

The bug is still present in 2.2.2. And I can confirm that this is unrelated to shutdown/hibernation.

Example: at my work, I have access both to wired internet and wireless internet. I usually use the wired internet.

First, I connected to AIM and Google Talk through the wired internet (pidgin is configured Not to autodetect my IP (why does it need this feature anyway? For file transfers?), and configured to connect through a SOCKS proxy).

Then, I disconnected the wired network and brought up my wireless device, connecting to a different router that has a different public IP. Then pidgin could not connect to either AIM or Google Talk (I tested my internet connection with a web browser that uses the same SOCKS proxy).

And, this time, I didn't restart pidgin, but switched back to my wired network (bringing down the wireless device), then pidgin can connect to AIM and GoogleTalk? just fine.

I believe the bug is related to whether pidgin gets the internet connection through the same network device as when it was started up (and originally made the connection?). But, why should it matter? I specifically made pidgin use a SOCKS proxy (at localhost:8000) hoping these hardware differences would be abstracted out, but it doesn't seem to work, so far.

comment:6 Changed 12 years ago by novakyu

Another update---I think I tracked down the error ... as pidgin not being able to resolve the server IPs after a substantial change to the network (as described above).

When I look up the IP manually and enter that instead of the usual server FQDN like login.oscar.aol.com or talk.google.com, pidgin can connect to AIM and Google Talk again, without the need to restart.

Also, this seems to work whether I'm using a proxy or not, and it works when pidgin has an wrong IP as my IP (this is probably used for file transfer and such things only anyways?).

comment:7 Changed 12 years ago by novakyu

I think I finally got it. This is a DNS-related bug. It appears Pidgin (at least on GNU/Linux) remembers only the DNS server in use when Pidgin was launched and does not re-check /etc/resolv.conf for each new DNS inquiry. Here is how I can reproduce the bug every time (no changing of network interfaces required):

  1. Set the DNS to a public DNS, like (63.226.12.96), in /etc/resolv.conf. Everything works fine, including pinging, web browser, and pidgin (launched after setting DNS to the public DNS).
  1. I set an iptables rule blocking outgoing connection to the said DNS server (in my particular case, "iptables -A OUTPUT -d 63.226.12.96 -j DROP" does the job). Nothing works, such as "nslookup" or web browsing, or pidgin (still the same process).
  1. Then, I change my DNS server to my router, (192.168.2.1), in /etc/resolv.conf. Everything starts working again, including web browsing. But pidgin still does not work.
  1. Then, I delete my iptables rule (with "iptables -D OUTPUT -d 63.226.12.96 -j DROP"). Pidgin starts working again. I re-instate the rule and pidgin can't make new connections.
  1. Finally, I restart Pidgin, and it works fine, even while 63.226.12.96 is blocked.

Please let me know if this does not reproduce the same error for anyone using GNU/Linux and Pidgin 2.2.2.

comment:8 Changed 12 years ago by Iyeru

I can't do that on Windows I believe, nova. And Windows sometimes receives this issue as well.

comment:9 Changed 12 years ago by novakyu

lyeru: You are right that you can't do that with Windows Firewall.

However, if you want to check this on Windows, you can install Comodo firewall (it doesn't seem to be free software, but it's free as in beer), and I think (from a brief 30 minutes of using it when I was using a co-worker's computer) Comodo firewall will give you enough control to block a specific destination IP.

I assume you already know how to change DNS servers on the TCP/IP setup page to ensure everything else but pidgin works when the original DNS server is blocked and the system setup is changed to another DNS server.

comment:10 Changed 12 years ago by Iyeru

I have ZoneAlarm? Free Edition. Pidgin connects fine when I connect it manually, but it usually gives connection errors when it tries to do it automatically.

comment:11 Changed 12 years ago by novakyu

Hmm. If it doesn't happen ALWAYS, I don't think it's the same error. At least, I believe (without looking at the actual relevant source code yet) this is very OS specific. For one, in GNU/Linux (and Unix), DNS server is specified in a file, /etc/resolv.conf, and maybe if pidgin opens it at the beginning but never closes it, it'll always read the old value, I think (and this would be the standard behavior in GNU/Linux). I don't think Windows stores DNS server information in a file (and if it did, if you try to edit it while it's opened by another application, you will just get access denied error).

But, just to clarify, are you saying that after you block your DNS server by a firewall rule (you have to do this manually, as a sane firewall will not automatically block access to DNS servers), you can still connect to AIM and Google Talk if you do it manually (without specifying explicit IP)? This just *may* be related, but without actually looking at the relevant section of the source code, I doubt it.

comment:12 Changed 10 years ago by darkrain42

  • Component changed from pidgin (gtk) to libpurple
  • Owner set to darkrain42

This is an issue when NetworkManager isn't around. res_init (rereads /etc/resolv.conf) is only called in the NM path. Red Hat's patch is effectively the right solution, but has a bit of overhead.

15:21:00 < khc> probably can wrap that over a timestamp and only if 
                !networkmanager

comment:13 Changed 10 years ago by dyfrgi

The overhead is minimal. I wrote a short C program to benchmark how long it takes to run res_init 100 times, and the result was about 0.003 seconds. This will be slightly higher if other things are done in between, but resolv.conf should stay in cache for the duration of (e.g.) startup, when many connections are initiated. When run more times, it scales roughly linearly. 10 times (closer to the number of connections initiated by most users, I suspect) takes 0.000534 seconds.

I've attached the C program, if anyone wants to verify this. Compile with gcc -lresolv res_init_bench.c -o res_init_bench.

Changed 10 years ago by dyfrgi

c program to benchmark res_init overhead

Changed 10 years ago by darkrain42

Call res_init() if DNS queries return errors

comment:14 Changed 10 years ago by darkrain42

  • Milestone set to Patches Needing Review
  • Type changed from defect to patch

Patch attached that calls res_init() when DNS queries return errors. This could also be changed so that dnssrv.c and dnsquery.c call purple_network_refresh_dns, which would be a nop in most situations unless NM isn't functioning (and then it would call res_init at most once a minute or some such).

I don't feel strongly about either option there (something better?)

comment:15 Changed 10 years ago by darkrain42@…

  • Milestone changed from Patches Needing Review to 2.6.0
  • Resolution set to fixed
  • Status changed from new to closed

(In d8736814cb67ade87f1a48b8ff85c8690327fa71):
Call res_init() when DNS queries fail in case the failure indicates a timeout because we've moved networks. Closes #2825.

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!