dhcp-option DNS in client config is broken for dco-win

[lstipakov]

Since both wintun and dco-win set ip_win32_type to IPW32_SET_NETSH, having dhcp-option DNS 8.8.8.8 in config breaks it because of this code:

    if (options->tuntap_options.dhcp_options
        && options->windows_driver != WINDOWS_DRIVER_WINTUN
        && options->tuntap_options.ip_win32_type != IPW32_SET_DHCP_MASQ
        && options->tuntap_options.ip_win32_type != IPW32_SET_ADAPTIVE)
    {
        msg(M_USAGE, "--dhcp-option requires --ip-win32 dynamic or adaptive");
    }

[cron2]

Hi,

On Fri, Feb 03, 2023 at 01:15:22PM -0800, Lev Stipakov wrote: Since both wintun and dco-win set `ip_win32_type` to `IPW32_SET_NETSH`, having `dhcp-option DNS 8.8.8.8` in config breaks it because of this code: ```

Why do these drivers modify ip_win32_type? And why "netsh" and not IPAPI?

if (options->tuntap_options.dhcp_options && options->windows_driver != WINDOWS_DRIVER_WINTUN && options->tuntap_options.ip_win32_type != IPW32_SET_DHCP_MASQ && options->tuntap_options.ip_win32_type != IPW32_SET_ADAPTIVE) { msg(M_USAGE, "--dhcp-option requires --ip-win32 dynamic or adaptive"); } ```

... but this check is broken in so many ways... so yes, let's fix that :-) gert

…

-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ***@***.***

[selvanair]

Get rid of --ip-win32 and --route-method. Hopefully saying it again and again may make the wish come true. Why this extra degree of freedom to inflict self-harm only on Windows....

[cron2]

Hi,

On Fri, Feb 03, 2023 at 02:41:54PM -0800, Selva Nair wrote: Get rid of --ip-win32 and --route-method. Hopefully saying it again and again may make the wish come true. Why this extra degree of freedom to inflict self-harm only on Windows....

It's from the dawn of times, way before I got involved - and I guess it's because Windows systems wildly differed in what worked and what didn't, IPAPI only worked when running privileged, etc. But I think making both a no-op for 2.7 sounds like a plan - we just need to decide what to do with TAP ifconfig (move to IPAPI or keep DHCP). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ***@***.***

[selvanair]

But I think making both a no-op for 2.7 sounds like a plan - we just need
to decide what to do with TAP ifconfig (move to IPAPI or keep DHCP).

I would suggest

• use IPAPI through iService if available
• fallback to DHCP for tap-window6 if DHCP is enabled on the adapter
  (optionally, we could continue to try enable DHCP as we do now)
• else use IPAPI or netsh directly
  (optionally replace current netsh code for IPv4 with IPAPI where possible).

It would be much simpler if DHCP is completely eliminated --- no route-delay, no forking and waiting for address to get assigned, no renew/release etc. But some setups that do not use iService may fail without it -- say, limited privileges which is okay for DHCP. Not sure how important is that.

route-method is much easier -- just use IPAPI through iService or directly.

[cron2]

Hi,

On Sat, Feb 04, 2023 at 07:43:15AM -0800, Selva Nair wrote: > But I think making both a no-op for 2.7 sounds like a plan - we just need > to decide what to do with TAP ifconfig (move to IPAPI or keep DHCP). I would suggest - use IPAPI through iService if available - fallback to DHCP for tap-window6 if DHCP is enabled on the adapter (optionally, we could continue to try enable DHCP as we do now) - else use IPAPI or netsh directly (optionally replace current netsh code for IPv4 with IPAPI where possible).

netsh should definitely go, so "IPAPI for both IPv4 and IPv6, if the service is not available".

It would be much simpler if DHCP is completely eliminated --- no route-delay, no forking and waiting for address to get assigned, no renew/release etc. But some setups that do not use iService may fail without it -- say, limited privileges which is okay for DHCP. Not sure how important is that.

DHCP works without privileges and without iservice, but installing routes doesn't (and until recently, route addition failures would be hidden, so it would "silently not do the right thing"). Plus, DHCP brings this "offset" aspects. So indeed, getting rid of DHCP might simplify everything.

route-method is much easier -- just use IPAPI through iService or directly.

This! (And do the metrics properly :-) ) gert

…

-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ***@***.***

[lstipakov]

What should we do for 2.6? Shall we just fix the faulty behavior and allow dhcp options, which do not require dhcp (sounds good, no?) for drivers which do not use dhcp?

[cron2]

Hi,

On Sat, Feb 04, 2023 at 09:27:40AM -0800, Lev Stipakov wrote: What should we do for 2.6? Shall we just fix the faulty behavior and allow dhcp options, which do not require dhcp (sounds good, no?) for drivers which do not use dhcp?

For 2.6, just fix this option check. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ***@***.***

[lstipakov]

Fixed in commit 469158f