Hi, On Sun, Jun 21, 2020 at 7:14 AM Gert Doering <g...@greenie.muc.de> wrote: > > Hi, > > going through OpenVPN threads that went stale - I think this is > actually a nice addition (read: other people have already asked > me if this can be done). > > On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote: > > So, for what it's worth, I've dusted off the patch again and rebased it > > to the current openvpn master tree. See attached. Note that I did only > > rudimentary testing, as I don't use Windows 10 a lot and I was testing > > using a mingw cross-compile only. In wireshark I *do* see that the > > correct DHCP offer is sent to the tap-win adapter. > > > > Also note that I implemented multiple search domains by separating them > > using semi-colons, e.g. > > > > --dhcp-option SEARCH example.com;example.org;example.nl;example.de > > > > etc as that was easier to implement > > The patch looks okay-ish on quick reading.
Feature wise yes, but some improvements needed.. I do not like that option format "example.com; example.org" with quotes will parse right and fail later on because of the space, for example. And, we support multiple statements of dhcp options like DNS, so this is counter-intuitive. It's only a little more work to support a more forgiving format. > > > Also note that I did not fully implement the RFC3397 encoding of the > > search list, as that requires one to merge domain names that occur more > > than once - that would have made the code far more complicated. > > Indeed. I haven't looked at what other DHCP implementations do, but > "correct" encoding definitely sounds like quite a bit of extra code just > to save a few bytes on the wire - might come handy if you have many > subdomains of a long internal DNS domain, though, but this can be > added "if needed". Same as my thoughts, the encoding part could be kept simple as in here and possibly improved later. But option format is hard to change or deprecate. > > > More interesting is the question "which option to use" - it should > be synchronized between openvpn platform handlers. So if systemd-networkd > uses "SEARCH-DOMAIN" it would make sense to use that for windows > as well. I think we need both --- the current one retained as the connection specific suffix which would be just one entry and then this search list. As we allow multiple entries for DOMAIN right now, a user friendly approach would be to continue doing so but internally treat all but the first as a part of --dhcp-option DOMAIN-SEARCH. We could also deprecate the use of multiple entries in the dhcp-option DOMAIN keyword. Selva _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
