Stefan Monnier wrote:
Implementing a DHCP client within OpenVPN tends to make this a more
self-contained problem.
I don't think OpenVPN should get into the DHCP business.
Especially because this is not a problem specific to OpenVPN: the same
problem of refreshing DHCP info happens with ethernet and with wifi when
you disconnect and reconnect.
Various solutions to this problem already exist: a tool (e.g. ifplugd)
can monitor the interface's status, or OpenVPN can be instructed (via
its script hooks) to run commands upon (re|dis)connection.
These existing solutions are better because they profit from the general
infrastructure and will hence blend in much better. E.g. they will
automatically adopt the global DHCP customizations.
I tend to agree with Stefan here:
it would be useful if the package builder or system engineer has more
control over how a tun or tap device is configured but why re-invent the
wheel ? I'd more than happy if the /sbin/ip command (as determined by
./configure) became scriptable so that a package maintainer can
determine which script/program to use to bring the interface up and
down. I do most of my work on RedHat based systems so I'd replace
/sbin/ifup with a script which writes out
/etc/sysconfig/networking-scripts/ifup-tap
and then simply call
/sbin/ifup tap0
or something like that... On Ubuntu the package maintainer can choose to
write his or her favourite /etc/network script, etc etc. Adding your own
DHCP code is more than likely only going to interfere with system
package which are already in place (NetworkManager, ifplugd, etc etc).
Let's not add more complexity to openvpn itself, I'd be much happier if
the complexity is separated as much as possible (heck, why am I even
stuck using a tun or tap adapter? It'd be nice/fun to be able to use a
ppp adapter as well, provided that I provide the right interface between
what openvpn expects and what ppp expects)
JM2CW,
JJK / Jan Just Keijser
