Re: [Openvpn-devel] [PATCH v3] wintun: add --windows-driver config option

[Gert Doering]

Hi,

On Mon, Nov 18, 2019 at 11:17:33PM -0500, Selva Nair wrote:
> Looks like this will most likely break any dhcp-related options
> in the client config.. Say "dhcp-option DNS xxx". We currently require
> ip_win32_type to be  adaptive or dynamic when such options are specified.
> I think we should set this to adaptive here, and then handle it in tun.c
> 
> Although there is no dhcp when wintun is used, we'll still support
> dhcp-options such as DNS etc using netsh or service, right?

I had the same concerns, and if I remember right (I haven't looked just now)
one of the later patches adds the missing bits to the iservice.

So we'd accept the DHCP options, pass them on, and iservice would IPAPI
them in.

I'll have another look...

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 g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device

[Selva Nair]

Hi,

On Thu, Nov 7, 2019 at 12:49 PM Lev Stipakov  wrote:

> From: Lev Stipakov 
>
> To open wintun device, we cannot use "\\.\Global\Wintun"
> path as before. To get device path which we supply to CreateFile,
> we have to use SetupAPI to:
>
>  - enumerate network adapters with "wintun" as component id
>  - for each adapter save its guid
>  - open device information set
>  - for each item in set
>- open corresponding registry key to get net_cfg_instance_id
>- get symbolic link name of device interface by instance id
>  - path will be symbolic link name of device instance matched with
> adapter's guid
>
> See
> https://github.com/OpenVPN/openvpn3/blob/master/openvpn/tun/win/tunutil.hpp
> and
>
> https://github.com/WireGuard/wireguard-go/blob/master/tun/wintun/wintun_windows.go
> for
> implementation examples.
>
> Signed-off-by: Lev Stipakov 
>

This also has been ACKed and merged,  but two questions that may need some
attention:

@@ -5541,7 +5668,8 @@ void
>  open_tun(const char *dev, const char *dev_type, const char *dev_node,
> struct tuntap *tt)
>  {
>  struct gc_arena gc = gc_new();
> -char device_path[256];
> +char tuntap_device_path[256];
> +char *path = NULL;
>  const char *device_guid = NULL;
>  DWORD len;
>  bool dhcp_masq = false;
> @@ -5571,6 +5699,8 @@ open_tun(const char *dev, const char *dev_type,
> const char *dev_node, struct tun
>  {
>  const struct tap_reg *tap_reg = get_tap_reg();
>  const struct panel_reg *panel_reg = get_panel_reg();
> +const struct device_instance_id_interface
> *device_instance_id_interface = get_device_instance_id_interface();
> +
>  char actual_buffer[256];
>
>  at_least_one_tap_win(tap_reg);
> @@ -5586,24 +5716,22 @@ open_tun(const char *dev, const char *dev_type,
> const char *dev_node, struct tun
>  }
>
>  /* Open Windows TAP-Windows adapter */
> -openvpn_snprintf(device_path, sizeof(device_path), "%s%s%s",
> +openvpn_snprintf(tuntap_device_path,
> sizeof(tuntap_device_path), "%s%s%s",
>   USERMODEDEVICEDIR,
>   device_guid,
>   TAP_WIN_SUFFIX);
>
> -tt->hand = CreateFile(
> -device_path,
> -GENERIC_READ | GENERIC_WRITE,
> -0,/* was: FILE_SHARE_READ */
> -0,
> -OPEN_EXISTING,
> -FILE_ATTRIBUTE_SYSTEM | FILE_FLAG_OVERLAPPED,
> -0
> -);
> +tt->hand = CreateFile(tuntap_device_path,
> +  GENERIC_READ | GENERIC_WRITE,
> +  0,/* was:
> FILE_SHARE_READ */
> +  0,
> +  OPEN_EXISTING,
> +  FILE_ATTRIBUTE_SYSTEM |
> FILE_FLAG_OVERLAPPED,
> +  0);
>
>  if (tt->hand == INVALID_HANDLE_VALUE)
>  {
> -msg(M_ERR, "CreateFile failed on TAP device: %s",
> device_path);
> +msg(M_ERR, "CreateFile failed on TAP device: %s",
> tuntap_device_path);
>

Doesn't this mean that  if --dev-node is specified, we'll open  tapwindows
adapter
with that name even if "--window-driver wintun" is specified? The open may
succeed
but subsequent wintun-specific processing will fail.

 }
>  }
>  else
> @@ -5613,43 +5741,78 @@ open_tun(const char *dev, const char *dev_type,
> const char *dev_node, struct tun
>  /* Try opening all TAP devices until we find one available */
>  while (true)
>  {
> +bool is_picked_device_wintun = false;
>  device_guid = get_unspecified_device_guid(device_number,
>actual_buffer,
>
>  sizeof(actual_buffer),
>tap_reg,
>panel_reg,
> +
> _picked_device_wintun,
>);
>
>  if (!device_guid)
>  {
> -msg(M_FATAL, "All TAP-Windows adapters on this system
> are currently in use.");
> +msg(M_FATAL, "All %s adapters on this system are
> currently in use.", tt->wintun ? "wintun" : "TAP - Windows");
>

If I'm not mistaken wintun device can be opened multiple times, so we'll
never get the
"All wintun adapters on this system" error. Instead, open will succeed
here and
something else may fail later. FILE_SHARE_READ = 0 will not save us when
the driver
does not enforce it.

Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3] wintun: add --windows-driver config option

[Selva Nair]

Hi,

I have been late to this wintun party (no time for anything fun, these days)
and this has already been committed, it seems. But some concerns below..


> +/* for wintun kernel doesn't send DHCP requests, so use ipapi to set
> IP address and netmask */
> +if (options->wintun)
> +{
> +options->tuntap_options.ip_win32_type = IPW32_SET_IPAPI;
> +}
>

Looks like this will most likely break any dhcp-related options
in the client config.. Say "dhcp-option DNS xxx". We currently require
ip_win32_type to be  adaptive or dynamic when such options are specified.
I think we should set this to adaptive here, and then handle it in tun.c

Although there is no dhcp when wintun is used, we'll still support
dhcp-options such as DNS etc using netsh or service, right?

Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Community meetings in November 2019

[Samuli Seppänen]

Hi,

Our community meetings will alternate between Wed 11:30 CET and Thu
20:00 CET.

Next meetings have been scheduled to

- Thu 21st November 20:00 CET
- Wed 27th November 11:30 CET

The place is #openvpn-meeting IRC channel at Freenode. Meeting agendas
and summaries are in here:



Samuli




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 5/4] Add ncp files to Visual studio print

[Arne Schwabe]

Am 17.11.19 um 22:23 schrieb Arne Schwabe:
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/openvpn.vcxproj | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
> index 7446d97d..b3d35ba2 100644
> --- a/src/openvpn/openvpn.vcxproj
> +++ b/src/openvpn/openvpn.vcxproj
> @@ -191,6 +191,7 @@
>  
>  
>  
> +
>  
>  
>  
> @@ -276,6 +277,7 @@
>  
>  
>  
> +
>  
>  
>  
> 

Note this patch can be merged into the 4/4 patch. I just did not want to
resend 4/4 for this tiny patch. Should a V2 of 4/4 be needed, I will
include this one into it.

Arne



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel