Hi, On Fri, Jun 26, 2015 at 07:02:15PM +0200, Holger Kummert wrote: > >Mulling over this for a while, I think I've come to a conclusion on > >"what we should do", and "what we should do in the 'persistant tun' > >case" (#141) > > > > - normal case: we do "ip addr add" and "delete" - proper housekeeping, > > and having IPv4 and IPv6 in sync (so, Holger's patch for Linux, > > and possible similar additional code for all the other OSes) > > I looked at some other OSes in tun.c and found no other with this flaw > at a first glance (other do simply a 'destroy' or 'unplumb' of the > interface). But probably I oversaw something here.
"destroy" is only done if we actually created it - if we found the
device to be "already there", we leave it alone (so that might end up
with a newly acquired v6 address, then).
> > - if someone really wants/needs a persistant device (created with
> > "openvpn --mktun --dev tun3" on Linux / "ifconfig tun3 create"
> > on *BSD), and expect it to always keep the addresses on it, they
> > should call "openvpn --ifconfig-noexec".
>
> Yes, this sounds like a good idea to me. Had also something like
> "--ifconfig-notouch" in mind, but your proposal is shorter.
Since --ifconfig-noexec is already there... .-)
But I'm still interested to understand why your setup triggers this issue,
and mine doesn't. The only reason I can see (really!) is that tunX has
been created outside OpenVPN... - which might actually make sense if
a firewall is involved, so you can tie rules to the interface right
away, which won't work if the interface does not exist yet... (does it?)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpcLwOTfEtl9.pgp
Description: PGP signature
