>> Let's not add more complexity to openvpn itself, I'd be much happier if
> You just don't understand.
> The complexity *WILL* be in OpenVPN, if we decide to support
> "route-gateway dhcp" for non-Windows platforms.
I'm not sure what "route-gateway dhcp" does, so maybe that's part of the
reason why we disagree. I thought the discussion was about how to make
DHCP work over an OpenVPN bridge (i.e. a TAP device) under systems like
GNU/Linux. On those systems, the only thing you need to do is to make
sure that things like ifplugd correctly receive the info about when the
tunnel goes up and down.
> a) figuring out how to properly run the system's DHCP client [which might
> not even be installed] for *this* version of Linux or FreeBSD or
> OpenBSD or NetBSD or Solaris or MacOS in the right way
That's not something OpenVPN should worry about. It's the
distribution's job to do that.
> This might be the other big misunderstanding here. As of today, if you
> want to use "ifplugd + dhcp + ..." on a TAP interface, just do so - OpenVPN
> won't stand in your way. This is not the issue at hand - the issue is
> that OpenVPN wants to be friendly to the users, and give them an option
> to do DHCP-on-TAP without(!) having to fiddle with their local network
> setup.
I find the effort would be better spent on working with other people
trying to make sure that ifplugd/NetworkManager/distributions/... make
this setup as troublefree as possible. E.g. make sure that ifplugd
works well with tap devices (e.g. that it tries to handle them by
default) and that NetworkManager can easily use OpenVPN and correctly
(re)starts dhcp clients for the corresponding tap devices.
Stefan
