looking at the multitude of DHCP clients available for unix, the completely
different handling of DHCP on MacOS, and the issues that most unix clients
seem to have with "DHCP active on two different interfaces (ethX and tapY),
and both trying to set a default gateway", ...
On Mon, Mar 08, 2010 at 08:21:35AM -0700, James Yonan wrote:
(2) Complex method: Write code in OpenVPN to simulate a DHCP client,
then translate the settings received in the DHCP reply to OpenVPN
push-style directives (such as ifconfig, route, etc.) as if they had
been pushed by the OpenVPN server.
... this seems to be the most portable way, as we already have the
ifconfig/route code for all the platforms.
Well. Let me rephrase.
The "simple way" is simple as far as the packet flow inside OpenVPN
goes (because OpenVPN only needs to transport packets, but not generate
them or parse them), but is, at the same time, the "most complex way"
as far as getting it to work reliably across all supported operating
systems. Lots of testing and "configure" magic would be necessary to
reliably figure out how to do DHCP properly on each individual system.
I'm not saying it can't be done :-) - but just that the "simple way"
is not so simple, it's just complex in other places.
I would tend to agree. All the discussion about the non-portable
semantics of DHCP clients on different platforms makes me think that the
"complex" method might really be the correct approach.
OpenVPN is already in the business of abstracting platform-specific
network configuration complexity to a portable interface, i.e. in the
manner of pushable directives such as route, ifconfig, dhcp-option,
etc., so I think it makes sense to leverage on this. Implementing a
DHCP client within OpenVPN tends to make this a more self-contained problem.
James
