Debian Bug report logs - #460200
vpnc does not always call resolvconf -d on terminaison

version graph

Package: vpnc; Maintainer for vpnc is Florian Schlichting <fschlich@zedat.fu-berlin.de>; Source for vpnc is src:vpnc.

Reported by: Vincent Danjean <vdanjean@debian.org>

Date: Fri, 11 Jan 2008 09:48:02 UTC

Severity: normal

Found in version vpnc/0.5.1r275-1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Eduard Bloch <blade@debian.org>:
Bug#460200; Package vpnc. Full text and rfc822 format available.

Acknowledgement sent to Vincent Danjean <vdanjean@debian.org>:
New Bug report received and forwarded. Copy sent to Eduard Bloch <blade@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Vincent Danjean <vdanjean@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: vpnc does not always call resolvconf -d on terminaison
Date: Fri, 11 Jan 2008 10:45:33 +0100
Package: vpnc
Version: 0.5.1r275-1
Severity: normal

I often use vpnc in my university. Here, I connect to an wide-open wifi
network (on the subnet 10.0.0.0/8). Then, I can start vpnc (which I do
with vpnc-connect) to be able to talk to all internet.

* If I stop with vpnc-disconnect, all goes well
* If I stop the wifi before vpnc, then vpnc dies and does not call
  resolvconf to remove the interface.
  In this case, vpnc-disconnect tells me 'no vpnc found running'
  and I have to manually type 'resolvconf -d tun0' to remove nameservers
  linked to the VPN in /etc/resolv.conf

  The first time it occures, it took me some times before figuring out
why /etc/resolv.conf was bad (the tun0 interface were not there anymore
with ifconfig) and how to correct it (editing directly /etc/resolv.conf
does not work as this file is regenerated at each DHCP lease)

  So, it would be good if vpnc can call 'resolvconf -d XXX' each time it
stops.

  Best regards,
    Vincent

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-rc5-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages vpnc depends on:
ii  libc6                         2.7-5      GNU C Library: Shared libraries
ii  libgcrypt11                   1.4.0-2    LGPL Crypto library - runtime libr

Versions of packages vpnc recommends:
ii  iproute                       20071016-3 Professional tools to control the 
ii  resolvconf                    1.37       nameserver information handler

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Eric Warmenhoven <warmenhoven@debian.org>:
Bug#460200; Package vpnc. (Mon, 07 Feb 2011 23:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andrew Pimlott <andrew@pimlott.net>:
Extra info received and forwarded to list. Copy sent to Eric Warmenhoven <warmenhoven@debian.org>. (Mon, 07 Feb 2011 23:15:03 GMT) Full text and rfc822 format available.

Message #10 received at 460200@bugs.debian.org (full text, mbox):

From: Andrew Pimlott <andrew@pimlott.net>
To: 460200@bugs.debian.org
Cc: Vincent Danjean <vdanjean@debian.org>
Subject: Re: vpnc does not always call resolvconf -d on terminaison
Date: Mon, 07 Feb 2011 14:32:01 -0800
I have this problem too.  I think there is a simple work-around.  Just
move tun* down in /etc/resolvconf/interface-order.  This will put the
VPN's nameservers at the end of /etc/resolv.conf, so your "normal"
nameserver will be used first.

In fact, I think that's a better default for
/etc/resolvconf/interface-order, so I filed a wishlist bug:
http://bugs.debian.org/612351

Andrew




Information forwarded to debian-bugs-dist@lists.debian.org, Eric Warmenhoven <warmenhoven@debian.org>:
Bug#460200; Package vpnc. (Tue, 08 Feb 2011 00:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Danjean <vdanjean@debian.org>:
Extra info received and forwarded to list. Copy sent to Eric Warmenhoven <warmenhoven@debian.org>. (Tue, 08 Feb 2011 00:42:03 GMT) Full text and rfc822 format available.

Message #15 received at 460200@bugs.debian.org (full text, mbox):

From: Vincent Danjean <vdanjean@debian.org>
To: Andrew Pimlott <andrew@pimlott.net>
Cc: 460200@bugs.debian.org, 612351@bugs.debian.org
Subject: Re: vpnc does not always call resolvconf -d on terminaison
Date: Tue, 08 Feb 2011 01:39:15 +0100
On 07/02/2011 23:32, Andrew Pimlott wrote:
> I have this problem too.  I think there is a simple work-around.  Just
> move tun* down in /etc/resolvconf/interface-order.  This will put the
> VPN's nameservers at the end of /etc/resolv.conf, so your "normal"
> nameserver will be used first.
> 
> In fact, I think that's a better default for
> /etc/resolvconf/interface-order, so I filed a wishlist bug:
> http://bugs.debian.org/612351

It depends a lot on the local config of the VPN you are using.
It can be a workaround for some user. It is a not fix for this
bug (460200).

In my university, it would be an error not to use the VPN provided
DNS servers (they have entries for some resources on the VPN that
are not visible to other external DNS).

It seems more logical to me to ask VPN resolvers first and other next.
And /etc/resolvconf/interface-order can be configured by the user to
fit its needs if required.

  Regards,
    Vincent

> Andrew

-- 
Vincent Danjean                 Adresse: Laboratoire d'Informatique de Grenoble
Téléphone:  +33 4 76 61 20 11            ENSIMAG - antenne de Montbonnot
Fax:        +33 4 76 61 20 99            ZIRST 51, avenue Jean Kuntzmann
Email: Vincent.Danjean@imag.fr           38330 Montbonnot Saint Martin




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 20:01:22 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.