Hi!
I've done some more investigation and I've found out that problem was
introduced in commit:
09ae6280 tun.c: revise the IPv4 ifconfig flow on Windows
in the following change:
@@ -6420,10 +6419,7 @@ open_tun(const char *dev, const char *dev_type, const
char *dev_node, struct tun
struct gc_arena gc = gc_new(); /* used also for device_guid allocation */
tun_open_device(tt, dev_node, &device_guid, &gc);
- if (tt->windows_driver == WINDOWS_DRIVER_TAP_WINDOWS6)
- {
tuntap_post_open(tt, device_guid);
- }
gc_free(&gc);
Due to that, DHCP setup section in tuntap_set_ip_addr() is executed when
Wintun is used, but it shouldn't.
As dhcp_masq_post is false for Wintun, fork_dhcp_action() is executed and
that outputs warning and does unnecessary fork.
With my patch applied, DHCP setup is done only when TAP-Windows6 is used.
In my case server pushes both dhcp-renew and dhcp-release.
When I pull-filter ignore them no forking occurs and thus no warning.
I hope this helps.
Regards,
Domagoj
On Fri, Dec 18, 2020 at 12:45:43PM +0200, Lev Stipakov wrote:
> Hi,
>
> The patch looks fine, but I wonder how did you manage to trigger this case?
>
> dhcp_release() or dhcp_renew() are called if dhcp_masq_post is set to true,
> which only happens for tap-windows6.
>
> fork_dhcp_action() is no-op unless dhcp-renew/dhcp-pre-release
> are explicitly defined in the ovpn profile.
>
> If latter is the case, I wonder if options postprocessing would be a
> better place
> to fix it.
>
> -Lev
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
