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. 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.
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 ;)
JM2CW,
JJK
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
