Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-23 Thread Gert Doering 
Hi,

On Sat, Jun 23, 2018 at 11:13:07AM +0800, Antonio Quartulli wrote:
> > Very likely. It would be nice to find the on-link route that triggers that 
> > code
> > path to ensure it doesn't cause any other issues.
> 
> My server was on the same LAN (connecting via v4) as the client - should
> that be considered on-link? maybe this is what triggers that code path.

Oh, definitely.  I had the feeling it was related to "server over v4",
but that would trigger "on-link" too.

Actually it might trigger the on-link ASSERT for the "ipv4 and ipv6"
case as well, as soon as "redirect-gateway ipv4" is involved.

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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Antonio Quartulli 
Hi,

On 23/06/18 11:09, Selva Nair wrote:
>> My guts say that the issue might be related to "gateway-redirect",
>> because only 8/8 makes sure that no logic is activated for IPv4 and
>> without that patch there might be some IPv4 route being installed
>> nonetheless.
> 
> Very likely. It would be nice to find the on-link route that triggers that 
> code
> path to ensure it doesn't cause any other issues.

My server was on the same LAN (connecting via v4) as the client - should
that be considered on-link? maybe this is what triggers that code path.

> 
> But not very critical as the assert is fixed and route errors are not FATAL.
> 

If you like the argv patch v2, would you mind giving your blessing? :-)

Thanks!
Cheers,

> 

-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Selva Nair 
Hi,

On Fri, Jun 22, 2018 at 10:07 PM, Antonio Quartulli  wrote:
> Hi,
>
> On 23/06/18 02:27, Gert Doering wrote:
>> Hi,
>>
>> On Fri, Jun 22, 2018 at 02:12:24PM -0400, Selva Nair wrote:
>>> My tap adapter has a link local address (169.254.98.86) on it possibly due
>>> to a previous dhcp failure. May be I need to get rid of that (how?) to
>>> activate this code path?
>>
>> I guess this is related - the branch in question is triggered by
>> is_on_link(), so maybe in Antonio's case the tap adapter is set to
>> 0.0.0.0 - or it actually tried to install a route related to
>> redirect-gateway.
>>
>> Are you connecting to your VPN server over IPv6 or IPv4?  You already
>> spotted one weirdness with "redirect-gateway !ipv4" which still seems
>> to setup "something" in the route_list - so maybe it's related to that,
>> but needs "VPN over IPv4" to trigger.
>>
>> In other words, no idea - hoping for a log from Antonio that shows the
>> "route.exe ..." call with "IF " so we can see what openvpn
>> tried to do :-)
>>
>
> attached you have the log, however there is no message containing
> "route.exe ..".

No assert (with argv patch applied?) and no sign of any v4 routes.

>
> Gert, the ASSERT was triggered with your binary: was it simply master +
> 2/8 (this patch)?
>
> What I used for my last test is:
> * master +
> * all the remaining patches from ipv6-only +
> * the fix for argv_printf()

So I guess there wont be any assert with such a build even if the argv patch
is left out. That would match with what I re-tested.

>
> The server side is running master + ipv6-only and there is no --server
> directive in the configuration.
>
> In the log "Ethernet 2" is the TAP interface".
>
> My guts say that the issue might be related to "gateway-redirect",
> because only 8/8 makes sure that no logic is activated for IPv4 and
> without that patch there might be some IPv4 route being installed
> nonetheless.

Very likely. It would be nice to find the on-link route that triggers that code
path to ensure it doesn't cause any other issues.

But not very critical as the assert is fixed and route errors are not FATAL.

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Antonio Quartulli 
Hi,

On 23/06/18 02:27, Gert Doering wrote:
> Hi,
> 
> On Fri, Jun 22, 2018 at 02:12:24PM -0400, Selva Nair wrote:
>> My tap adapter has a link local address (169.254.98.86) on it possibly due
>> to a previous dhcp failure. May be I need to get rid of that (how?) to
>> activate this code path?
> 
> I guess this is related - the branch in question is triggered by
> is_on_link(), so maybe in Antonio's case the tap adapter is set to
> 0.0.0.0 - or it actually tried to install a route related to
> redirect-gateway.
> 
> Are you connecting to your VPN server over IPv6 or IPv4?  You already
> spotted one weirdness with "redirect-gateway !ipv4" which still seems
> to setup "something" in the route_list - so maybe it's related to that,
> but needs "VPN over IPv4" to trigger.
> 
> In other words, no idea - hoping for a log from Antonio that shows the 
> "route.exe ..." call with "IF " so we can see what openvpn
> tried to do :-)
> 

attached you have the log, however there is no message containing
"route.exe ..".

Gert, the ASSERT was triggered with your binary: was it simply master +
2/8 (this patch)?

What I used for my last test is:
* master +
* all the remaining patches from ipv6-only +
* the fix for argv_printf()

The server side is running master + ipv6-only and there is no --server
directive in the configuration.

In the log "Ethernet 2" is the TAP interface".

My guts say that the issue might be related to "gateway-redirect",
because only 8/8 makes sure that no logic is activated for IPv4 and
without that patch there might be some IPv4 route being installed
nonetheless.

Cheers,


-- 
Antonio Quartulli
Sat Jun 23 00:38:44 2018 us=143551 Current Parameter Settings:
Sat Jun 23 00:38:44 2018 us=144050   config = 'client-lan.ovpn'
Sat Jun 23 00:38:44 2018 us=144050   mode = 0
Sat Jun 23 00:38:44 2018 us=144531   show_ciphers = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   show_digests = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   show_engines = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   genkey = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   key_pass_file = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   show_tls_ciphers = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   connect_retry_max = 0
Sat Jun 23 00:38:44 2018 us=144531 Connection profiles [0]:
Sat Jun 23 00:38:44 2018 us=144531   proto = udp
Sat Jun 23 00:38:44 2018 us=144531   local = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   local_port = '1194'
Sat Jun 23 00:38:44 2018 us=144531   remote = '192.168.1.190'
Sat Jun 23 00:38:44 2018 us=144531   remote_port = '1194'
Sat Jun 23 00:38:44 2018 us=144531   remote_float = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   bind_defined = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   bind_local = ENABLED
Sat Jun 23 00:38:44 2018 us=144531   bind_ipv6_only = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   connect_retry_seconds = 5
Sat Jun 23 00:38:44 2018 us=144531   connect_timeout = 120
Sat Jun 23 00:38:44 2018 us=144531   socks_proxy_server = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   socks_proxy_port = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   tun_mtu = 1500
Sat Jun 23 00:38:44 2018 us=144531   tun_mtu_defined = ENABLED
Sat Jun 23 00:38:44 2018 us=144531   link_mtu = 1500
Sat Jun 23 00:38:44 2018 us=144531   link_mtu_defined = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   tun_mtu_extra = 0
Sat Jun 23 00:38:44 2018 us=144531   tun_mtu_extra_defined = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   mtu_discover_type = -1
Sat Jun 23 00:38:44 2018 us=144531   fragment = 0
Sat Jun 23 00:38:44 2018 us=144531   mssfix = 1450
Sat Jun 23 00:38:44 2018 us=144531   explicit_exit_notification = 0
Sat Jun 23 00:38:44 2018 us=144531 Connection profiles END
Sat Jun 23 00:38:44 2018 us=144531   remote_random = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   ipchange = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   dev = 'tun'
Sat Jun 23 00:38:44 2018 us=144531   dev_type = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   dev_node = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   lladdr = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   topology = 1
Sat Jun 23 00:38:44 2018 us=144531   ifconfig_local = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   ifconfig_remote_netmask = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   ifconfig_noexec = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   ifconfig_nowarn = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   ifconfig_ipv6_local = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   ifconfig_ipv6_netbits = 0
Sat Jun 23 00:38:44 2018 us=144531   ifconfig_ipv6_remote = '[UNDEF]'
Sat Jun 23 00:38:44 2018 us=144531   shaper = 0
Sat Jun 23 00:38:44 2018 us=144531   mtu_test = 0
Sat Jun 23 00:38:44 2018 us=144531   mlock = DISABLED
Sat Jun 23 00:38:44 2018 us=144531   keepalive_ping = 10
Sat Jun 23 00:38:44 2018 us=144531   keepalive_timeout = 120
Sat Jun 23 00:38:44 2018 us=144531   inactivity_timeout = 0
Sat Jun 23 00:38:44 2018 us=144531   ping_send_timeout = 10
Sat Jun 23 00:38:44 2018 us=144531

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Selva Nair 
On Fri, Jun 22, 2018 at 2:27 PM, Gert Doering  wrote:
> Hi,
>
> On Fri, Jun 22, 2018 at 02:12:24PM -0400, Selva Nair wrote:
>> My tap adapter has a link local address (169.254.98.86) on it possibly due
>> to a previous dhcp failure. May be I need to get rid of that (how?) to
>> activate this code path?
>
> I guess this is related - the branch in question is triggered by
> is_on_link(), so maybe in Antonio's case the tap adapter is set to
> 0.0.0.0 - or it actually tried to install a route related to
> redirect-gateway.
>
> Are you connecting to your VPN server over IPv6 or IPv4?

This physical link is v4.

I tried without !ipv4 in redirect-gateway and got:

(i) without route-gateway defined: redirecting v4 fails with a warning
"route-gateway or ifconfig is missing"

(ii) with route-gateway: the route is added but warns "route gateway
not reachable by any active
interfaces" -- fair enough.

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Gert Doering 
Hi,

On Fri, Jun 22, 2018 at 02:12:24PM -0400, Selva Nair wrote:
> My tap adapter has a link local address (169.254.98.86) on it possibly due
> to a previous dhcp failure. May be I need to get rid of that (how?) to
> activate this code path?

I guess this is related - the branch in question is triggered by
is_on_link(), so maybe in Antonio's case the tap adapter is set to
0.0.0.0 - or it actually tried to install a route related to
redirect-gateway.

Are you connecting to your VPN server over IPv6 or IPv4?  You already
spotted one weirdness with "redirect-gateway !ipv4" which still seems
to setup "something" in the route_list - so maybe it's related to that,
but needs "VPN over IPv4" to trigger.

In other words, no idea - hoping for a log from Antonio that shows the 
"route.exe ..." call with "IF " so we can see what openvpn
tried to do :-)

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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Selva Nair 
Hi,

On Fri, Jun 22, 2018 at 5:49 AM, Antonio Quartulli  wrote:

> Hi,
>
> On 22/06/18 17:46, Gert Doering wrote:
> > Hi,
> >
> > On Fri, Jun 22, 2018 at 03:27:02PM +0800, Antonio Quartulli wrote:
> >> Fri Jun 22 13:43:51 2018 us=116232 PUSH: Received control message:
> 'PUSH_REPLY,redirect-gateway !ipv4 ipv6,tun-ipv6,ping 10,ping-restart
> 120,ifconfig-ipv6 2002::1001/112 2002::2,peer-id 0,cipher AES-256-GCM'
> >
> > As an afterthought - the error could be totally unrelated to the changes,
> > and the win32 API refusing 2002:: addresses because it knows that they
> > are not "free for grabs"...  (6to4, normally auto-configured unless
> > disabled, with 2002::: being the prefix that a host on  or
> > a network behind a router on  can use - but that's old stuff and
> > should no longer be used in any case).
>
> After changing the prefix to 2001:db8:cafe::/112 the error is gone.
>
> However, the assert at the end of the log in argv.c:299 is still there.
> This might be some argv_new()/reset() that has been misplaced (maybe?).
>

While the assert is definitely due to buggy code (as discussed in the other
thread),
I cant reproduce this. Both the version I had tested earlier and the v2/v3
patches
work without throwing this error.

Earlier I had tested with

pull-filter ignore "ifconfig "
route 192.168.0.0  255.255.255.0# test a tunnel route
route 192.168.1.0 255.255.255.0 net_gateway  # test an external route
redirect-gateway ipv6 !ipv4

Now retested by adding

pull-filter ignore route-gateway

as otherwise the v4 tunnel gateway was not null and the v4 route succeeded
with a simple warning (gateway unreacahble). With the route gateway removed,
the v4 route fails with

Fri Jun 22 13:52:08 2018 OpenVPN ROUTE: OpenVPN needs a gateway parameter
for a --route option and no default was specified by either --route-gateway
or --ifconfig options
Fri Jun 22 13:52:08 2018 OpenVPN ROUTE: failed to parse/resolve route for
host/network: 192.168.0.0
Fri Jun 22 13:52:08 2018 GDG6: remote_host_ipv6=n/a
Fri Jun 22 13:52:08 2018 GetBestInterfaceEx() returned if=15
Fri Jun 22 13:52:08 2018 GDG6: II=15 DP=::/0 NH=fe80::2d0:b7ff:febe:d8bc
Fri Jun 22 13:52:08 2018 GDG6: Metric=256, Loopback=0, AA=1, I=0
Fri Jun 22 13:52:08 2018 ROUTE6_GATEWAY fe80::2d0:b7ff:febe:d8bc I=15

Again, no assert.

Possibly you have some v4 route that triggers the assert, but I can't
figure which.
Or are you testing using a v6 only server -- even if so, its not clear how
that would
matter.

My tap adapter has a link local address (169.254.98.86) on it possibly due
to a previous dhcp failure. May be I need to get rid of that (how?) to
activate
this code path?

Selva
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Antonio Quartulli 
Hi,

On 22/06/18 17:46, Gert Doering wrote:
> Hi,
> 
> On Fri, Jun 22, 2018 at 03:27:02PM +0800, Antonio Quartulli wrote:
>> Fri Jun 22 13:43:51 2018 us=116232 PUSH: Received control message: 
>> 'PUSH_REPLY,redirect-gateway !ipv4 ipv6,tun-ipv6,ping 10,ping-restart 
>> 120,ifconfig-ipv6 2002::1001/112 2002::2,peer-id 0,cipher AES-256-GCM'
> 
> As an afterthought - the error could be totally unrelated to the changes,
> and the win32 API refusing 2002:: addresses because it knows that they
> are not "free for grabs"...  (6to4, normally auto-configured unless
> disabled, with 2002::: being the prefix that a host on  or
> a network behind a router on  can use - but that's old stuff and
> should no longer be used in any case).

After changing the prefix to 2001:db8:cafe::/112 the error is gone.

However, the assert at the end of the log in argv.c:299 is still there.
This might be some argv_new()/reset() that has been misplaced (maybe?).

Cheers,


-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Gert Doering 
Hi,

On Fri, Jun 22, 2018 at 03:27:02PM +0800, Antonio Quartulli wrote:
> Fri Jun 22 13:43:51 2018 us=116232 PUSH: Received control message: 
> 'PUSH_REPLY,redirect-gateway !ipv4 ipv6,tun-ipv6,ping 10,ping-restart 
> 120,ifconfig-ipv6 2002::1001/112 2002::2,peer-id 0,cipher AES-256-GCM'

As an afterthought - the error could be totally unrelated to the changes,
and the win32 API refusing 2002:: addresses because it knows that they
are not "free for grabs"...  (6to4, normally auto-configured unless
disabled, with 2002::: being the prefix that a host on  or
a network behind a router on  can use - but that's old stuff and
should no longer be used in any case).

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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Gert Doering 
HI,

On Fri, Jun 22, 2018 at 03:27:02PM +0800, Antonio Quartulli wrote:
> The failure is reported as:
> 
> TUN: adding address failed using service: The parameter is incorrect.
> [status=87 if_index=42]

This is surprising.  I initially assumed that this is related to IPv4,
but we do not even use the service for IPv4 today...

This *might* trigger something that the iservice logs to the windows
event log - so it might be worth having a look :-)

gert

PS: as a side note - with XP and Vista dropped, we might consider ripping
out every win32-api besides IPAPI and iservice, for 2.5...

-- 
"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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-22 Thread Antonio Quartulli 
Hi,

On 20/06/18 23:53, Gert Doering wrote:
[cut]
> 
> ... because it's just "tt" here, so "tt->did_ifconfig_setup" should
> be fine...  at least it compiled :-) - I've sent you a link to an 
> installer for testing.
>

Thanks for the installer Gert!
I just tried it on Windows 10 (not my laptop! just in case somebody
thinks I use Windows :-P) and unfortunately it does not work as expected.

The failure is reported as:

TUN: adding address failed using service: The parameter is incorrect.
[status=87 if_index=42]

I have to double check the code to understand what is different from
what Selva tested. In the meantime, you have the full log attached to
this email in case somebody wants to give it a look.


Cheers,

-- 
Antonio Quartulli
Fri Jun 22 13:43:48 2018 us=883035 Current Parameter Settings:
Fri Jun 22 13:43:48 2018 us=883535   config = 'client-lan.ovpn'
Fri Jun 22 13:43:48 2018 us=883535   mode = 0
Fri Jun 22 13:43:48 2018 us=883535   show_ciphers = DISABLED
Fri Jun 22 13:43:48 2018 us=883535   show_digests = DISABLED
Fri Jun 22 13:43:48 2018 us=883535   show_engines = DISABLED
Fri Jun 22 13:43:48 2018 us=883535   genkey = DISABLED
Fri Jun 22 13:43:48 2018 us=883535   key_pass_file = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=883535   show_tls_ciphers = DISABLED
Fri Jun 22 13:43:48 2018 us=883535   connect_retry_max = 0
Fri Jun 22 13:43:48 2018 us=883535 Connection profiles [0]:
Fri Jun 22 13:43:48 2018 us=883535   proto = udp
Fri Jun 22 13:43:48 2018 us=883535   local = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=883535   local_port = '1194'
Fri Jun 22 13:43:48 2018 us=883535   remote = '192.168.1.190'
Fri Jun 22 13:43:48 2018 us=883535   remote_port = '1194'
Fri Jun 22 13:43:48 2018 us=883535   remote_float = DISABLED
Fri Jun 22 13:43:48 2018 us=883535   bind_defined = DISABLED
Fri Jun 22 13:43:48 2018 us=883535   bind_local = ENABLED
Fri Jun 22 13:43:48 2018 us=883535   bind_ipv6_only = DISABLED
Fri Jun 22 13:43:48 2018 us=883535   connect_retry_seconds = 5
Fri Jun 22 13:43:48 2018 us=883535   connect_timeout = 120
Fri Jun 22 13:43:48 2018 us=883535   socks_proxy_server = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=883535   socks_proxy_port = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=883535   tun_mtu = 1500
Fri Jun 22 13:43:48 2018 us=883535   tun_mtu_defined = ENABLED
Fri Jun 22 13:43:48 2018 us=884034   link_mtu = 1500
Fri Jun 22 13:43:48 2018 us=884034   link_mtu_defined = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   tun_mtu_extra = 0
Fri Jun 22 13:43:48 2018 us=884034   tun_mtu_extra_defined = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   mtu_discover_type = -1
Fri Jun 22 13:43:48 2018 us=884034   fragment = 0
Fri Jun 22 13:43:48 2018 us=884034   mssfix = 1450
Fri Jun 22 13:43:48 2018 us=884034   explicit_exit_notification = 0
Fri Jun 22 13:43:48 2018 us=884034 Connection profiles END
Fri Jun 22 13:43:48 2018 us=884034   remote_random = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   ipchange = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   dev = 'tun'
Fri Jun 22 13:43:48 2018 us=884034   dev_type = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   dev_node = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   lladdr = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   topology = 1
Fri Jun 22 13:43:48 2018 us=884034   ifconfig_local = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   ifconfig_remote_netmask = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   ifconfig_noexec = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   ifconfig_nowarn = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   ifconfig_ipv6_local = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   ifconfig_ipv6_netbits = 0
Fri Jun 22 13:43:48 2018 us=884034   ifconfig_ipv6_remote = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   shaper = 0
Fri Jun 22 13:43:48 2018 us=884034   mtu_test = 0
Fri Jun 22 13:43:48 2018 us=884034   mlock = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   keepalive_ping = 10
Fri Jun 22 13:43:48 2018 us=884034   keepalive_timeout = 120
Fri Jun 22 13:43:48 2018 us=884034   inactivity_timeout = 0
Fri Jun 22 13:43:48 2018 us=884034   ping_send_timeout = 10
Fri Jun 22 13:43:48 2018 us=884034   ping_rec_timeout = 120
Fri Jun 22 13:43:48 2018 us=884034   ping_rec_timeout_action = 2
Fri Jun 22 13:43:48 2018 us=884034   ping_timer_remote = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   remap_sigusr1 = 0
Fri Jun 22 13:43:48 2018 us=884034   persist_tun = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   persist_local_ip = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   persist_remote_ip = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   persist_key = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   passtos = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   resolve_retry_seconds = 10
Fri Jun 22 13:43:48 2018 us=884034   resolve_in_advance = DISABLED
Fri Jun 22 13:43:48 2018 us=884034   username = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   groupname = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   chroot_dir = '[UNDEF]'
Fri Jun 22 13:43:48 2018 us=884034   cd_dir =

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-20 Thread Gert Doering 
Hi,

On Wed, Jun 20, 2018 at 03:31:39PM -0400, Selva Nair wrote:
> > This code is a bit optimstic :-) - there is no "c" here...
> 
> When did this change?  In a previous version this was done as

v2 to v3, because I complained that check_add_routes_dowork() is 
hard enough to read as it is, and suggested to put the check
elsewhere.

All my fault :-)

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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-18 Thread Gert Doering 
Hi,

On Wed, Jun 13, 2018 at 10:12:13PM +0800, Antonio Quartulli wrote:
> From: Antonio Quartulli 
> 
> This patch ensures that the TAP driver on a windows host is still
> configured, even though no IPv4 has been provided.
> 
> In this case the TAP driver ioctl will be invoked with a fake
> 0.0.0.0/0.0.0.0 IPv4 which will simply start the interface and
> get it to a working state.
> 
> Trac: #208
> Signed-off-by: Antonio Quartulli 

I think this is good enough, though I haven't tested it yet (compile
and run).  Will do that tomorrow, before I merge & push.

Before I go ahead with it - Selva, are you fine with this version?

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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v3 2/8] windows: properly configure TAP driver when no IPv4 is configured

2018-06-13 Thread Antonio Quartulli 
From: Antonio Quartulli 

This patch ensures that the TAP driver on a windows host is still
configured, even though no IPv4 has been provided.

In this case the TAP driver ioctl will be invoked with a fake
0.0.0.0/0.0.0.0 IPv4 which will simply start the interface and
get it to a working state.

Trac: #208
Signed-off-by: Antonio Quartulli 

---

Changes from v2:
- rebased on top ov v4 1/8
- extended commit message
- moved did_ifconfig_setup check into test_routes()
- added longer comment into test_routes() to explain check condition


 src/openvpn/route.c |  6 +-
 src/openvpn/tun.c   | 24 +---
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/src/openvpn/route.c b/src/openvpn/route.c
index 8990a986..be07bd65 100644
--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -2642,7 +2642,11 @@ test_routes(const struct route_list *rl, const struct 
tuntap *tt)
 ret = true;
 adapter_up = true;
 
-if (rl)
+/* we do this test only if we have IPv4 routes to install, and if
+ * the tun/tap interface has seen IPv4 ifconfig - because if we
+ * have no IPv4, the check will always fail, failing tun init
+ */
+if (rl && c->c1.tuntap->did_ifconfig_setup)
 {
 struct route_ipv4 *r;
 for (r = rl->routes, len = 0; r; r = r->next, ++len)
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 878fd845..c0d1ac18 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5703,7 +5703,10 @@ open_tun(const char *dev, const char *dev_type, const 
char *dev_node, struct tun
 msg(M_FATAL, "ERROR: --dev tun also requires --ifconfig");
 }
 
-if (tt->topology == TOP_SUBNET)
+/* send 0/0/0 to the TAP driver even if we have no IPv4 configured to
+ * ensure it is somehow initialized.
+ */
+if (!tt->did_ifconfig_setup || tt->topology == TOP_SUBNET)
 {
 in_addr_t ep[3];
 BOOL status;
@@ -5716,12 +5719,19 @@ open_tun(const char *dev, const char *dev_type, const 
char *dev_node, struct tun
  ep, sizeof(ep),
  ep, sizeof(ep), , NULL);
 
-msg(status ? M_INFO : M_FATAL, "Set TAP-Windows TUN subnet mode 
network/local/netmask = %s/%s/%s [%s]",
-print_in_addr_t(ep[1], IA_NET_ORDER, ),
-print_in_addr_t(ep[0], IA_NET_ORDER, ),
-print_in_addr_t(ep[2], IA_NET_ORDER, ),
-status ? "SUCCEEDED" : "FAILED");
-
+if (tt->did_ifconfig_setup)
+{
+msg(status ? M_INFO : M_FATAL, "Set TAP-Windows TUN subnet 
mode network/local/netmask = %s/%s/%s [%s]",
+print_in_addr_t(ep[1], IA_NET_ORDER, ),
+print_in_addr_t(ep[0], IA_NET_ORDER, ),
+print_in_addr_t(ep[2], IA_NET_ORDER, ),
+status ? "SUCCEEDED" : "FAILED");
+}
+else
+{
+msg(status ? M_INFO : M_FATAL, "Set TAP-Windows TUN with fake 
IPv4 [%s]",
+status ? "SUCCEEDED" : "FAILED");
+}
 }
 else
 {
-- 
2.17.1


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel