Hi,

On Tue, Jun 05, 2018 at 03:38:44PM -0400, Selva Nair wrote:
> FWIW, I did a quick test --- looking into tap-windows sources it seems
> the address is used only for ARP so passing some random address to the
> ioctl looks ok (?).

Not sure about that.  For ARP spoofing, it should use the route-gateway 
address - the "ifconfig" address is likely to end up in the DHCP-server
code.  Haven't checked yet (busy repairing my own test right which
deteriorated a bit...).

[..]
> There is a less than ideal log message which could be improved:
> 
> "Set TAP-Windows TUN subnet mode network/local/netmask =
> 0.0.0.0/0.0.0.0/0.0.0.0 [SUCCEEDED]"

Indeed :-)

> However, even with !ipv4, redirect-gateway ipv6 appears to error out
> -- it fails with
> 
> "TEST ROUTES: 0/2 succeeded len=1 ret=0 a=0 u/d=up
> Route: Waiting for TUN/TAP interface to come up..."

Interesting.  This is route.c, test_routes(), using test_route_helper()
-> test_route(), which basically tries to find the adapter index where
a given (route)->gateway is configured on.  Since it cannot find anything,
it assumes "tun interface is stuck in DHCP" and is unhappy.

This shouldn't actually try to do anything in the first place - it
looks at "struct route_list *rl", which should not be populated if
we have no v4 address to point the routes to.  (Or maybe it should,
but only for "non-tun/tap routes").


> A couple of other random things I noticed
> 
> If a v4 address is not being set:
> 
> - some management messages could be bypassed as Gert had guessed --
> eg., ASSIGN_IP which includes the v4 and v6 address.
> The GUI takes the address from the final CONNECTED,SUCCESS message but
> other clients may parse this message.

What does our GUI display here?  "0.0.0.0" or "<blank>"?

> - setting of mtu may get skipped in some systems at least
> 
> Here is the diff of what I did for the Windows build run:
> 
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 2e33880..75336a9 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -5824,9 +5824,9 @@ open_tun(const char *dev, const char *dev_type,
> const char *dev_node, struct tun
> 
>      if (tt->type == DEV_TYPE_TUN)
>      {
> -        if (!tt->did_ifconfig_setup)
> +        if (!tt->did_ifconfig_setup && !tt->did_ifconfig_ipv6_setup)
>          {
> -            msg(M_FATAL, "ERROR: --dev tun also requires --ifconfig");
> +            msg(M_WARN|M_INFO, "WARNING: neither ifconfig nor
> ifconfig-ipv6 specified");
>          }

Thanks.  This is easy enough to integrate...  Antonio, are you listening? ;-)

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

Attachment: 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

Reply via email to