From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/61510 Path: news.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.gnus.general Subject: Re: nntp problems with hibernating and waking up in a new network Date: Tue, 13 Dec 2005 13:34:21 +0100 Organization: Probably a good idea Message-ID: <87k6e9qipe.fsf@dod.no> References: <87lkyq3a60.fsf@dod.no> <87hd9em007.fsf@obelix.mork.no> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1134478343 14323 80.91.229.2 (13 Dec 2005 12:52:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Dec 2005 12:52:23 +0000 (UTC) Original-X-From: ding-owner+m10042@lists.math.uh.edu Tue Dec 13 13:52:17 2005 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Em9bU-0005Ql-Qb for ding-account@gmane.org; Tue, 13 Dec 2005 13:50:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1Em9bJ-0001xT-00; Tue, 13 Dec 2005 06:49:49 -0600 Original-Received: from nas01.math.uh.edu ([129.7.128.39]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1Em9RE-0001x7-00 for ding@lists.math.uh.edu; Tue, 13 Dec 2005 06:39:24 -0600 Original-Received: from quimby.gnus.org ([80.91.224.244]) by nas01.math.uh.edu with esmtp (Exim 4.52) id 1Em9RC-0005sl-B1 for ding@lists.math.uh.edu; Tue, 13 Dec 2005 06:39:24 -0600 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Em9RA-000202-00 for ; Tue, 13 Dec 2005 13:39:20 +0100 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Em9PJ-0002SV-GH for ding@gnus.org; Tue, 13 Dec 2005 13:37:25 +0100 Original-Received: from cm-80.111.224.068.chello.no ([80.111.224.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2005 13:37:25 +0100 Original-Received: from sb by cm-80.111.224.068.chello.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2005 13:37:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org Original-Lines: 48 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cm-80.111.224.068.chello.no Mail-Copies-To: never User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:SjWJrNqiEdnFq7Esh2oe/iSDrCk= X-Spam-Score: -2.6 (--) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:61510 Archived-At: >>>>> Bjørn Mork : > The main problem when doing this is that emacs (or libc?) will cache > DNS resolvers for you, and these probably won't work in your new > network environment. Therefore there is no nntp traffic, only > unanswered DNS queries. I thought it might be something like this, but I had hoped it was in the lisp code in the nntp backend, since nnimap worked. However... > Can't explain why the nnimap sessions work. Maybe they are using > some external process to set up the connection, e.g a ssh tunnel? That is indeed the case. That is, not an SSH tunnel, but as NNIMAPS using the "openssl" executable. > Never found a good solution to the cached DNS resolver problem. > Note that is isn't confined to emacs. The same problem applies to > most applications running forever without mechanisms for reloading > /etc/resolv.conf, like most browsers. Actually, my browsers survive. I used to have a problem with a similar situation in Opera, when I went on VPN using PPTP, and back (this changed the /etc/resolv.conf file but the browser didn't keep track). But with recent versions of Opera, this problem has gone away. > Personally I resorted to running BIND locally on the laptop... That won't work for me, because this would confuse the PPTP client, I think. Or perhaps I could just list all DNS clients at work and at home, and let BIND sort them out? But if so, what happens when I go online in a different network where I'm passed a name server with the DHCP lease? I'm thinking of a simple workaround, which would be to use an intermediate connection like nntp-open-via-rlogin-and-telnet or something. But instead of connecting to a remote machine, just use the current machine. The idea here is to "misuse" the indirection to fork off a new process that would actually read /etc/resolv.conf. We'll see.