Hi,
On Fri, Jul 3, 2020 at 3:39 AM Jan Just Keijser <janj...@nikhef.nl> wrote:
>
> Hi,
>
> On 02/07/20 23:04, David Sommerseth wrote:
> > On 30/06/2020 16:15, Jan Just Keijser wrote:
> >> hi,
> >>
> >> On 30/06/20 16:11, Gert Doering wrote:
> >>> Hi,
> >>>
> >>> On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
> >>>> @@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf,
> >>>> const struct tuntap_options *o)
> >>>> write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len,
> >>>> &error);
> >>>> write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len,
> >>>> &error);
> >>>>
> >>>> + for (int i=0; i < o->domain_search_list_len; i++)
> >>>> + {
> >>>> + write_dhcp_search_str(buf, 119, o->domain_search_list[i],
> >>>> &error);
> >>>> + }
> >>> I assume that this won't work. In the DHCP answer, it must be a single
> >>> option with the concatenated list, not multiple answers with a single
> >>> domain name each.
> >>>
> >>> gert
> >>>
> >> see https://tools.ietf.org/html/rfc3397
> >>
> >> "
> >>
> >> In the above diagram, Searchstring is a string specifying the
> >> searchlist. If the length of the searchlist exceeds the maximum
> >> permissible within a single option (255 octets), then multiple
> >> options MAY be used, as described in "Encoding Long Options in the
> >> Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396
> >> <https://tools.ietf.org/html/rfc3396>].
> >>
> >> "
> >>
> >>
> >> so you MAY use this option multiple times - and wireshark groks it fine. I
> >> don't have a Windows 10
> >> client to test it against, however, so I am hoping that someone (Selva?)
> >> can do that for me.
> >>
> > Hi,
> >
> > Can we please see this discussion also in context of this mail thread, which
> > tries to look a broader at this challenge?
> >
> > Message-Id: <c4628c37-0c3b-a402-ee9d-68ee7062e...@sf.lists.topphemmelig.net>
> > URL:
> > <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20101.html>
> >
> > One change in that RFC since last time is that we will move IV_PROTO to be
> > only about the OpenVPN wire protocol (features/settings only affecting
> > protocol for the communication between the OpenVPN end-points themselves).
> > The DNS settings and more related to host configuration and similar will be
> > moved into an IV_FEAT field. Except of that, nothing else has changed from
> > the initial mail.
> >
> > The main purpose of that RFC is to ensure we handle DNS and --dhcp-options
> > consistently across all OpenVPN implementations we care about, and that we
> > document this properly.
> >
>
> I see one as an implementation issue (can we specify a particular DHCP
> option more than once) and one as an OpenVPN protocol issue.
> I fully agree that it's time to think about and overhaul the DNS
> settings for OpenVPN but I also believe that further abusing the option
> 'dhcp-option' is not the best way forward.
+1
> The option 'dhcp-option'
> only really applies to the Windows tap-win adapter as that is the only
> adapter where you can use DHCP to add/change settings. AFAIK even the
> new win-tun adapter does not use DHCP for this. Hence the term 'dhcp-'
> is moot.
If you mean the term 'dhcp' should not be used in the name of the
option, I agree. Perhaps something like "interface-option" would be
better.
But the _option_ isn't only for Windows tap-win adaptor. The option's
arguments are passed to scripts via $foreign_option_* environment
variables (on macOS, at least, and I think on most or all platforms).
And the Tunnelblick scripts use them to modify network settings, sort
of as if they came from DHCP, but not actually using DHCP.
> Thus, moving forward, I'd be more in favor of overhauling this
> *completely* and review all 'dhcp-option' flags to see how we can
> a) specify then more logically and more neutrally
> b) implement these features for each of the different platforms:
>
> Windows+tap-win: use DHCP
> Windows+win-tun: use netsh ?
> Linux: use systemd? use scripts
> BSD: scripts? systemd?
> MacOS: just copy what Jonathan is using ;)
+1 here, too, for overhauling this "completely".
I'll have further comment soon on the other thread:
> > Message-Id: <c4628c37-0c3b-a402-ee9d-68ee7062e...@sf.lists.topphemmelig.net>
> > URL:
> > <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20101.html>
Best regards,
Jon
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
