openvpn-devel Mailing List for OpenVPN

On 28/05/2019 15:30, Lorenz wrote: > Hi, > > has anyone already succeeded to compile the OpenVPN 3 Linux Client on an arm > architecture? > > I am trying to compile the project on a Raspberry Pi 3 Model B+ running > Raspbian (basically Debian Stretch). But make always fails (see attached log). > To check if there is a problem with Raspbian I also tried compiling inside a > LXC container running Ubuntu 18.04 however the same error occurred. > > GCC version: > gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516 > gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04) 7.4.0 > > uname: > Linux test 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux > > > make finishes without problems on my amd64 machine (tested Debian Stretch and > Ubuntu 18.04). > > Do you have any ideas why the error only occurs on the Raspberry Pi? Hi, Thanks for testing openvpn3-linux! :) Yes, 32 bit is a known issue. It's related to some type deduction challenge C++ provides which is not an issue on 64 bit platforms. So far I've just been ignorant to 32 bit platforms (sorry!), as I didn't think it was that used that much any more - and especially not on ARM. But I also didn't think if RasperryPi ... so this needs to be fixed! If anyone is willing to dive into this issue and try to come up with a patch, I will happily review and merge it. Otherwise I'll have a look at it once I get a chance. It's probably not a big challenge, just need to fully grasp the C++ template complaint and find a fix which also doesn't break 64 bit. Btw ... (and I'm NOT pointing fingers) .. but these kind of questions are usually better suited for openvpn-devel mailing list (on Cc). -- kind regards, David Sommerseth OpenVPN Inc 

 Hi, The Debian 9 (stretch), Ubuntu 16.04 (xenial) and Ubuntu 18.04 (bionic) repositories for OpenVPN 3 Linux is now available! Installing the OpenVPN 3 Linux client ===================================== First ensure that your apt supports the https transport: # apt install apt-transport-https Install the OpenVPN repository key used by the OpenVPN 3 Linux packages # wget https://swupdate.openvpn.net/repos/openvpn-repo-pkg-key.pub # apt-key add openvpn-repo-pkg-key.pub Then you need to install the proper repository. Replace $DISTRO with stretch, xenial or bionic, depending on your Debian/Ubuntu distribution. # wget -O /etc/apt/sources.list.d/openvpn3.list https://swupdate.openvpn.net/community/openvpn3/repos/openvpn3-$DISTRO.list # apt update And finally the openvpn3 package can be installed # apt install openvpn3 Using the OpenVPN 3 Linux client ================================ With all this in place, you can now start VPN tunnels, even as an unprivileged user, using the openvpn2 and openvpn3 command line interfaces: # openvpn2 --config $MY_CONFIGURATION_FILE --verb 6 or # openvpn3 session-start --config $MY_CONFIGURATION_FILE If the configuration profile contains --daemon or you used the openvpn3 approach, you can stop the tunnel like this: # openvpn3 session-manage --config $MY_CONFIGURATION_FILE --disconnect For more information, see the man pages for openvpn2, openvpn3 and openvpn3-linux as starting points. Both openvpn2 and openvpn3 also provides --help screens, and openvpn3 also provides that for each "command" you give to it, like openvpn3 session-manage --help. If you have any questions, issues, comments, suggestions, etc ... please get in touch! -- kind regards, David Sommerseth OpenVPN Inc 

Hi, Here's the summary of the IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net Date: Wednesday 29th May 2019 Time: 11:30 CEST (9:30 UTC) Planned meeting topics for this meeting were here: <https://community.openvpn.net/openvpn/wiki/Topics-2019-05-29> Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> SUMMARY cron2, dazo, lev, mattock, ordex and plaisthos participated in this meeting. --- Talked about the possible DoS attack that forums had a few days ago. Investigation of what happened is still ongoing. It is possible that it was just a misbehaving bot (happens occasionally on community/trac). This possible DoS attack was mitigated by turning on CloudFlare temporarily. This caused some bad blood in the community. We'll continue the discussion once we know exactly what happened. --- Discussed tap-windows6 HLK testing. Mattock will setup a physical HLK environment in his office. Developers can experiment with trying to make tap-windows6 appear as a virtual device, as described in last meeting summary: <https://www.mail-archive.com/ope...@li.../msg18476.html> These two approaches ("make it virtual", "build physical HLK environment") can and will go hand-in-hand. It is known that sgstair and jamallx made all the (mandatory) tests pass using a physical HLK environment, so that route is "guaranteed" to work, unlike the "make it virtual" route. --- Discussed dropping TAP support from Windows. Agreed that it can happen in 2.6 at earliest (if at all). Tons of people are probably using TAP. It was also agreed that if TAP support was ever dropped, it would be best to just migrate to wintun altogether. --- Talked about wintun. Agreed that having wintun support as an option in OpenVPN 2.5 makes perfect sense. Lev is adding wintun support to OpenVPN 2 right now. --- Next mini-hackathon will be arranged Friday next week (7th June) starting in European morning. As usual, it will focus on OpenVPN 2.5 work. --- Dazo is soon going to announce the public availability of openvpn3-linux client v6 apt repositories for Debian and Ubuntu. --- Full chatlog attached. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

 Hi, The OpenVPN 3 Linux v6 beta release has been pushed out. This is available in our git repositories [0] and URLs for source tarballs are listed later in this e-mail. RPM binaries for Fedora and RHEL/CentOS/Scientific Linux [1] completed the build process quite recently too. More details on Debian/Ubuntu packages further down in this mail. The highlights of this release includes: # OpenSSL 1.1.0/1.1.1 support The OpenVPN 3 Core Library has been updated with full OpenSSL 1.1.0/1.1.1 support. # Improved --persist-tun support This will avoid leaking traffic if using --redirect-gateway when switching to a new server. It manages this by creating a new tun device setting up all the routes before removing the old (and now non-working) tun device and the related routes. It also ensures the IP address to the new VPN server gets the appropriate bypass route to avoid pushing that traffic into the VPN tunnel. This will normally work very fine, with the exception when programs binds to specific interfaces. # Improved service shut-down In all previous releases, the various backend services didn't exit as quickly as they could when being sent SIGINT or SIGTERM signals. The whole idle-exit mechanism causing this bad behaviour has been revamped and improved resulting in an almost instant service shutdown. OpenVPN 3 Linux is on track for prime-time production. It will still come a some more beta releases, to iron out last missing minor features and other improvements. But OpenVPN 3 Linux is essentially feature ready now. If you are using OpenVPN 3 Linux, please report back if there are issues you have or improvements you feel is important for the stable release. * Debian and Ubuntu package repositories There has been several requests for Debian and Ubuntu repositories with pre- compiled binaries. They are on the way now. I hoped we would have them ready for this announcement, but we're still fighting with a few issues for the final deployment. Packages are built and ready for Debian 9, Ubuntu 16.04 LTS and Ubuntu 18.04 LTS, we just need to figure out what went wrong when publishing them into the public repositories. Stay tuned, I hope this will be sorted out in not too many days. * Quick-start with OpenVPN 3 Linux once it has been installed $ openvpn2 --config my-vpn-config.conf --verb 6 This will start a VPN configuration profile with the most verbose logging. If the configuration does not contain --daemon, all logging will also be present in the console and the tunnel will be torn down with a simple CTRL-C. Otherwise the VPN session will be running in the background and you get your command prompt back again, and you need to manage this session using `openvpn3 session-manage --config my-vpn-config.conf` For more information see the various man-pages available [2]. * Install Fedora Copr packages for Fedora, RHEL, CentOS and Scientific Linux Ensure you have the yum-plugin-copr or the dnf copr plugin installed. For RHEL/CentOS/Scientific Linux you will also need to have the Fedora EPEL repository enabled [3]. Then run the following commands: For yum users: $ yum copr enable dsommers/openvpn3 $ yum install openvpn3-client or for dnf users: $ dnf copr enable dsommers/openvpn3 $ dnf install openvpn3-client [0] <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> [1] <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/> [2] <https://github.com/OpenVPN/openvpn3-linux/tree/master/docs/man/> [3] <https://fedoraproject.org/wiki/EPEL> ---- Source tarballs ---------------------------------------------------- * OpenVPN 3 Linux v6 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-6_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-6_beta.tar.xz.asc> ---- SHA 256 Checksums -------------------------------------------------- 7f92d294705b29f109a35ec6f7957f8b8eefe8829dc9be08751e428d90a8ccb0 openvpn3-linux-6_beta.tar.xz 0f6298e3b642aad675f5b155273952ccf857f57f0ef72f0a6854256758a16865 openvpn3-linux-6_beta.tar.xz.asc ---- git references ----------------------------------------------------- git tag: v6_beta git commit: e6c66892ba0868206d558ad8b81351140c1195b4 ---- Changes from v5 to v6 ---------------------------------------------- David Sommerseth (12): build: Add sitnl debug messages compile time switch ovpn3cli/sessions: Add --cleanup to session-manage sessionmgr: Improve backend Ping() error handling when registering dbus: Improve IdleCheck documentation dbus: Revamp IdleCheck to use std::condition_variable dbus/services: Clean up after IdleCheck signal handling changes dbus/services: Remove NOP SetPollTime() log: Make the log tag mechanism more generic Update Core library to latest upstream build: Strip out build date/time stamp by default docs: Update README.md client/netcfg: Add proper support for persist-tun Lev Stipakov (3): netcfg: adapt to refactored TunLinuxSetup netcfg: implement addBypassRoute method client: take addBypassRoute into use ------------------------------------------------------------------------- -- kind regards, David Sommerseth OpenVPN Inc 

Acked-by: Gert Doering <ge...@gr...> "Obvious oversight". More configure silliness might be fixable, but this is like easy and direct :-) - smoke tested on FreeBSD. Your patch has been applied to the master branch. commit e077726c768c24809531a55332ae1e273f8e41c2 Author: Arne Schwabe Date: Fri May 24 11:02:36 2019 +0200 Fix poll.h logic in syshead.h Acked-by: Gert Doering <ge...@gr...> Message-Id: <201...@rf...> URL: https://www.mail-archive.com/ope...@li.../msg18475.html Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

Hi, Here's the summary of the IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net Date: Thursday 23rd May 2019 Time: 20:00 CEST (18:00 UTC) Planned meeting topics for this meeting were here: <https://community.openvpn.net/openvpn/wiki/Topics-2019-05-23> Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> SUMMARY cron2, dazo, lev, mattock and ordex participated in this meeting. --- Discussed tap-windows6. The two-machine tests are now working on a basic level on EC2 Windows instances. Testing on physical computers is known to work, so in the worst case somebody (mattock) will have to setup some physical Windows Server 2019 (evaluation) instances and run HLK on bare metal. Post-meeting note: there is also the possibility that we could avoid the HLK tests that target physical network adapters (NDISTest) by modifying driver parameters (ifType, PhysicalMediaType): <https://docs.microsoft.com/en-us/windows-hardware/drivers/network/keywords-not-displayed-in-the-user-interface> <https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib> --- Discussed "constants.h: make driver not halt on suspend" PR: <https://github.com/OpenVPN/tap-windows6/pull/86> Agreed that the PR makes sense, but it needs proper testing before merge. --- Full chatlog attached. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Commit 62063162 change the include from sys/poll.h to just poll.h but forgot to also change all occurrences of HAVE_SYS_POLL_H to HAVE_POLL_H. --- src/openvpn/syshead.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/openvpn/syshead.h b/src/openvpn/syshead.h index 2b4c49ff..899aa59e 100644 --- a/src/openvpn/syshead.h +++ b/src/openvpn/syshead.h @@ -600,7 +600,7 @@ socket_defined(const socket_descriptor_t sd) /* * Is poll available on this platform? */ -#if defined(HAVE_POLL) && defined(HAVE_SYS_POLL_H) +#if defined(HAVE_POLL) && defined(HAVE_POLL_H) #define POLL 1 #else #define POLL 0 -- 2.21.0 

Hi, On Tue, May 21, 2019 at 09:18:32AM +0200, Pieter Hulshoff wrote: > Who would be the best person to approach regarding this issue? It was > originally reported 2 years ago ( > https://community.openvpn.net/openvpn/ticket/880), but perhaps wasn't > properly identified as bug at that time. Steffan or Arne are likely best qualified to figure out what is happening here, but as far as I hear, both are horribly busy... 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 ge...@gr... 

Hallo all, Op vr 26 apr. 2019 om 19:56 schreef Gert Doering <ge...@gr...>: > On Fri, Apr 26, 2019 at 04:55:36PM +0200, Pieter Hulshoff wrote: > > As you can see, the message is never actually decrypted after the > > reconnect, and as such the server will never receive it. > > So that's most certainly a bug, but not related to the suppression > of PUSH_REPLY messages - but "something handshake crypto mumble mumble". > > I'm not the one who understands these bits, though... > Who would be the best person to approach regarding this issue? It was originally reported 2 years ago ( https://community.openvpn.net/openvpn/ticket/880), but perhaps wasn't properly identified as bug at that time. Kind regards, Pieter Hulshoff 

Hi, While wintun support is not yet added to openvpn3 master, I think it would be beneficial to share my own branch. https://github.com/lstipakov/openvpn3/tree/feature/wintun-wip#building-the-openvpn-3-client-on-windows See instructions in README on how to build openvpn3 library and test client on Windows. Note that only "topology subnet" is supported (see https://community.openvpn.net/openvpn/wiki/Topology#Topologysubnet). I have included test client and wintun driver binaries if someone would like to try it out (Tested on Windows 10 and Windows Server 2016): 1. Since wintun driver is not signed, you need to enable loading of test signed code. For that, run > bcdedit /set testsigning in admin command prompt and restart Windows. 2. Download and unzip wintun driver https://github.com/lstipakov/openvpn3/blob/feature/wintun-wip/wintun.7z 3. Open Device Manager (Control Panel\System and Security\System\Device Manager). Right click on tree root, select "Add legacy hardware" -> "Next" -> ".. hardware that I manually select from a list" -> "Next" -> "Show all devices" -> "Have Disk..." -> Locate wintun.inf unpacked at step 2 -> select "Wintun Userspace Tunnel" -> "Next" -> "Install this software anyway" (since driver is not signed). 4. Make sure you see "Wintun Userspace Tunnel" under Device Manager -> Network adapters. 5. Download cli_wintun.exe from https://github.com/lstipakov/openvpn3/blob/feature/wintun-wip/cli_wintun.exe 6. Open command prompt as an administrator and run: > C:\Users\Administrator\Downloads>cli_wintun.exe <your_vpn_profile.ovpn> 7. Enjoy! -- -Lev 

Hi, On Sat, May 18, 2019 at 02:38:29PM +0200, Christopher Schenk wrote: > any other thoughts on this patch? Any chance to getting it applied? It got an ACK, so it's in my work queue :-) - there is a given chance that I might find something on my "double check before merging", but usually when Selva says something is good it is so. Lack of time, mostly... sorry for that. 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 ge...@gr... 

Hi, any other thoughts on this patch? Any chance to getting it applied? Christopher On 4/23/19 5:35 PM, Christopher Schenk wrote: > Hi, > > i think this is not a big issue since the mtu is only set until the > system gets rebooted. So it behaves exactly like my netsh version where > i specified a "store=active" in the set command. > > Christopher > > On 18/04/2019 17:47, Selva Nair wrote: >> Hi, >> >> Thanks for the new version. I somehow missed it as it >> went into a new thread. >> >> For the record, this is an updated version of the series >> https://patchwork.openvpn.net/project/openvpn2/list/?series=471 >> with requested changes: >> >> (i) tabs removed + some good white-space changes >> (ii) GetIpInterfaceEntry() called first to read-in the current >> parameters before calling SetIpInterfaceEntry() >> >> Summary: >> The  patch sets the tun_mtu value (either the default of 1500 or >> user-specified --tun-mtu xxx) on the tun/tap  interface on Windows >> using the IP helper API, preferably via the interactive service. >> >> Looks good now and a quick test on WIndows 7 behaves >> as expected. >> >> I'm ACKing this, but one remark: the patch does not revert the >> mtu back to the previous value on disconnect. This is an issue >> only (?) if we want to support clean downgrades to an earlier >> version without recreating the tun/tap interfaces. >> >> On Thu, Apr 4, 2019 at 7:18 AM Christopher Schenk < >> cs...@ma...> wrote: >> >>> Signed-off-by: Christopher Schenk <cs...@ma...> >>> --- >>>   include/openvpn-msg.h         |  8 ++++ >>>   src/openvpn/tun.c             | 89 +++++++++++++++++++++++++++++++++++ >>>   src/openvpnserv/interactive.c | 31 ++++++++++++ >>>   3 files changed, 128 insertions(+) >>> >>> diff --git a/include/openvpn-msg.h b/include/openvpn-msg.h >>> index 66177a21..10cd68ac 100644 >>> --- a/include/openvpn-msg.h >>> +++ b/include/openvpn-msg.h >>> @@ -39,6 +39,7 @@ typedef enum { >>>       msg_del_block_dns, >>>       msg_register_dns, >>>       msg_enable_dhcp, >>> +    msg_set_mtu, >>>   } message_type_t; >>> >>>   typedef struct { >>> @@ -117,4 +118,11 @@ typedef struct { >>>       interface_t iface; >>>   } enable_dhcp_message_t; >>> >>> +typedef struct { >>> +    message_header_t header; >>> +    interface_t iface; >>> +    short family; >>> +    int mtu; >>> +} set_mtu_message_t; >>> + >>>   #endif /* ifndef OPENVPN_MSG_H_ */ >>> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c >>> index 48a8fdf7..3895e421 100644 >>> --- a/src/openvpn/tun.c >>> +++ b/src/openvpn/tun.c >>> @@ -69,6 +69,10 @@ static void netsh_ifconfig(const struct >>> tuntap_options >>> *to, >>>                              const in_addr_t netmask, >>>                              const unsigned int flags); >>> >>> +static void windows_set_mtu(const int iface_index, >>> +                            const short family, >>> +                            const int mtu); >>> + >>>   static void netsh_set_dns6_servers(const struct in6_addr *addr_list, >>>                                      const int addr_len, >>>                                      const char *flex_name); >>> @@ -201,6 +205,47 @@ out: >>>       return ret; >>>   } >>> >>> +static bool >>> +do_set_mtu_service(const struct tuntap *tt, const short family, >>> const int >>> mtu) >>> +{ >>> +    DWORD len; >>> +    bool ret = false; >>> +    ack_message_t ack; >>> +    struct gc_arena gc = gc_new(); >>> +    HANDLE pipe = tt->options.msg_channel; >>> +    const char *family_name = (family == AF_INET6) ? "IPv6" : "IPv4"; >>> +    set_mtu_message_t mtu_msg = { >>> +        .header = { >>> +            msg_set_mtu, >>> +            sizeof(set_mtu_message_t), >>> +            0 >>> +        }, >>> +        .iface = {.index = tt->adapter_index,.name = tt->actual_name }, >>> +        .mtu = mtu, >>> +        .family = family >>> +    }; >>> + >>> +    if (!send_msg_iservice(pipe, &mtu_msg, sizeof(mtu_msg), &ack, >>> "Set_mtu")) >>> +    { >>> +        goto out; >>> +    } >>> + >>> +    if (ack.error_number != NO_ERROR) >>> +    { >>> +        msg(M_NONFATAL, "TUN: setting %s mtu using service failed: %s >>> [status=%u if_index=%d]", >>> +            family_name, strerror_win32(ack.error_number, &gc), >>> ack.error_number, mtu_msg.iface.index); >>> >> +    } >>> +    else >>> +    { >>> +        msg(M_INFO, "%s MTU set to %d on interface %d using service", >>> family_name, mtu, mtu_msg.iface.index); >>> +        ret = true; >>> +    } >>> + >>> +out: >>> +    gc_free(&gc); >>> +    return ret; >>> +} >>> + >>>   #endif /* ifdef _WIN32 */ >>> >>>   #ifdef TARGET_SOLARIS >>> @@ -984,6 +1029,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char >>> *ifname, int tun_mtu, >>>       { >>>           do_address_service(true, AF_INET6, tt); >>>           do_dns6_service(true, tt); >>> +        do_set_mtu_service(tt, AF_INET6, tun_mtu); >>>       } >>>       else >>>       { >>> @@ -1000,6 +1046,7 @@ do_ifconfig_ipv6(struct tuntap *tt, const char >>> *ifname, int tun_mtu, >>>           netsh_command(&argv, 4, M_FATAL); >>>           /* set ipv6 dns servers if any are specified */ >>>           netsh_set_dns6_servers(tt->options.dns6, tt->options.dns6_len, >>> ifname); >>> +        windows_set_mtu(tt->adapter_index, AF_INET6, tun_mtu); >>>       } >>> >>>       /* explicit route needed */ >>> @@ -1394,6 +1441,14 @@ do_ifconfig_ipv4(struct tuntap *tt, const char >>> *ifname, int tun_mtu, >>> >>>                   break; >>>           } >>> +        if (tt->options.msg_channel) >>> +        { >>> +            do_set_mtu_service(tt, AF_INET, tun_mtu); >>> +        } >>> +        else >>> +        { >>> +            windows_set_mtu(tt->adapter_index, AF_INET, tun_mtu); >>> +        } >>>       } >>> >>>   #else  /* if defined(TARGET_LINUX) */ >>> @@ -5236,6 +5291,40 @@ out: >>>       return ret; >>>   } >>> >>> +static void >>> +windows_set_mtu(const int iface_index, const short family, >>> +                const int mtu) >>> +{ >>> +    DWORD err = 0; >>> +    struct gc_arena gc = gc_new(); >>> +    MIB_IPINTERFACE_ROW ipiface; >>> +    InitializeIpInterfaceEntry(&ipiface); >>> +    const char *family_name = (family == AF_INET6) ? "IPv6" : "IPv4"; >>> +    ipiface.Family = family; >>> +    ipiface.InterfaceIndex = iface_index; >>> +    err = GetIpInterfaceEntry(&ipiface); >>> +    if (err == NO_ERROR) >>> +    { >>> +        if (family == AF_INET) >>> +        { >>> +            ipiface.SitePrefixLength = 0; >>> +        } >>> +        ipiface.NlMtu = mtu; >>> +        err = SetIpInterfaceEntry(&ipiface); >>> +    } >>> + >>> +    if (err != NO_ERROR) >>> +    { >>> +        msg(M_WARN, "TUN: Setting %s mtu failed: %s [status=%u >>> if_index=%d]", >>> +            family_name, strerror_win32(err, &gc), err, iface_index); >>> +    } >>> +    else >>> +    { >>> +        msg(M_INFO, "Successfully set %s mtu on interface %d", >>> family_name, iface_index); >>> +    } >>> +} >>> + >>> + >>>   /* >>>    * Return a TAP name for netsh commands. >>>    */ >>> diff --git a/src/openvpnserv/interactive.c >>> b/src/openvpnserv/interactive.c >>> index 623c3ff7..c24cb22b 100644 >>> --- a/src/openvpnserv/interactive.c >>> +++ b/src/openvpnserv/interactive.c >>> @@ -1198,6 +1198,29 @@ HandleEnableDHCPMessage(const >>> enable_dhcp_message_t >>> *dhcp) >>>       return err; >>>   } >>> >>> +static DWORD >>> +HandleMTUMessage(const set_mtu_message_t *mtu) >>> +{ >>> +    DWORD err = 0; >>> +    MIB_IPINTERFACE_ROW ipiface; >>> +    InitializeIpInterfaceEntry(&ipiface); >>> +    ipiface.Family = mtu->family; >>> +    ipiface.InterfaceIndex = mtu->iface.index; >>> +    err = GetIpInterfaceEntry(&ipiface); >>> +    if (err != NO_ERROR) >>> +    { >>> +        return err; >>> +    } >>> +    if (mtu->family == AF_INET) >>> +    { >>> +        ipiface.SitePrefixLength = 0; >>> +    } >>> +    ipiface.NlMtu = mtu->mtu; >>> + >>> +    err = SetIpInterfaceEntry(&ipiface); >>> +    return err; >>> +} >>> + >>>   static VOID >>>   HandleMessage(HANDLE pipe, DWORD bytes, DWORD count, LPHANDLE events, >>> undo_lists_t *lists) >>>   { >>> @@ -1210,6 +1233,7 @@ HandleMessage(HANDLE pipe, DWORD bytes, DWORD >>> count, >>> LPHANDLE events, undo_lists >>>           block_dns_message_t block_dns; >>>           dns_cfg_message_t dns; >>>           enable_dhcp_message_t dhcp; >>> +        set_mtu_message_t mtu; >>>       } msg; >>>       ack_message_t ack = { >>>           .header = { >>> @@ -1277,6 +1301,13 @@ HandleMessage(HANDLE pipe, DWORD bytes, DWORD >>> count, LPHANDLE events, undo_lists >>>               } >>>               break; >>> >>> +        case msg_set_mtu: >>> +            if (msg.header.size == sizeof(msg.mtu)) >>> +            { >>> +                ack.error_number = HandleMTUMessage(&msg.mtu); >>> +            } >>> +            break; >>> + >>>           default: >>>               ack.error_number = ERROR_MESSAGE_TYPE; >>>               MsgToEventLog(MSG_FLAGS_ERROR, TEXT("Unknown message type >>> %d"), msg.header.type); >>> >>> >> Acked-by: Selva Nair <sel...@gm...> >> >> Selva >> > > > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Hi, However, if I am not mistaken the version of OpenVPN used in the test > was a *Windows* build of OpenVPN3 with a wintun patch included. Correct. > That is not open source, is it? I'd *not* be in favour of writing > community > wiki pages on the non-open source version of OpenVPN. > That's an open source openvpn3 test client, which is part of library (openvpn/test/ovpncli/cli.cpp). We'll incorporate required changes into master branch soon. -- -Lev 

Hi David, * On 15/05/19 19:32, David Sommerseth wrote: > On 15/05/2019 16:49, Илья Шипицин wrote: >> it will most probably get lost in mailing list. >> can we add it to https://openvpn.net website ? something like "performance >> testing" with full configs provided ? > Good idea, but maybe not the official corp web pages just yet. But we should > definitely have some wiki pages under https://community.openvpn.net/ related > to how to prepare a good setup for performance testing. > > a community wiki page on how to prepar a good setup for performance testing sounds like a good plan. However, if I am not mistaken the version of OpenVPN used in the test was a *Windows* build of OpenVPN3 with a wintun patch included. That is not open source, is it?  I'd *not* be in favour of writing community wiki pages on the non-open source version of OpenVPN. JM2CW, JJK 

Your patch has been applied to the master branch. I'm not really happy with this patch - it adds lots of code which is not used yet. It claims that this is "the code from route.c / tun.c", but as it is not moved over but just copied, "git diff --color-moved=zebra" won't help in actually verifying that it is, indeed, the same code - and it cannot be tested because it is never called... so this is not a good patch granularity. But since Arne has already ACKed the whole series, I'm not holding this up, just grumbling a bit, hoping for a slightly more convincing (= there is a way to actually test the code changes every single commit brings) granularity in future series. Oh, and as a side note - can we please stop configuring broadcast addresses? This was silly 15 years ago already... the machine knows quite well what the broadcast address is. + char *brd_str = (char *)print_in_addr_t(*broadcast, 0, NULL); + + argv_printf(&argv, "%s addr add dev %s %s/%d broadcast %s", iproute_path, + iface, addr_str, prefixlen, brd_str); .. and as yet another side note - this code introduces string allocations using (implicit) malloc() and free()... so this is very much *different* code than "what we have in route.c/tun.c" - and it questions the design of this API if every single backend *except* sitnl will have to start doing local memory management. ** This needs to be fixed **. commit 678111936ffb33992684dd3b96dc5b21693dfa58 Author: Antonio Quartulli Date: Wed Dec 19 15:01:12 2018 +1000 implement networking API for iproute2 Signed-off-by: Antonio Quartulli <a...@un...> Acked-by: Arne Schwabe <ar...@rf...> Message-Id: <201...@un...> URL: https://www.mail-archive.com/ope...@li.../msg18031.html Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

Acked-by: Gert Doering <ge...@gr...> This patch does not actually *do* anything - it just brings in a new file (networking.h) with the new API. The file wouldn't compile because it references not-yet-existing other .h files, so the patch is a bit confusing - but since the rest of the series has ACKs and needs this prequel, here we go. Your patch has been applied to the master branch. Note: I think "networking.h" and "networking_iproute2.h" are very long file names (and are hurting my sense for aesthetics) so I suggest we rename those to "net.h" and "net_<method>.h" afterwards - not the most elegant approach but I do not want to hold up the series any longer. Note2: when this is in, I want us to drop support for ifconfig/route on Linux, and get rid of --enable-iproute2 (this would become the fallback if --enable-sitnl is not set). Two options are enough. commit 3d26593736982852fcf277b541da38b4c3cc7fc8 Author: Antonio Quartulli Date: Tue May 14 10:11:59 2019 +0200 implement platform generic networking API Signed-off-by: Antonio Quartulli <a...@un...> Acked-by: Gert Doering <ge...@gr...> Message-Id: <201...@un...> URL: https://www.mail-archive.com/ope...@li.../msg18458.html Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

On 15/05/2019 16:49, Илья Шипицин wrote: > it will most probably get lost in mailing list. > can we add it to https://openvpn.net website ? something like "performance > testing" with full configs provided ? Good idea, but maybe not the official corp web pages just yet. But we should definitely have some wiki pages under https://community.openvpn.net/ related to how to prepare a good setup for performance testing. -- kind regards, David Sommerseth OpenVPN Inc > ср, 15 мая 2019 г. в 18:49, Lev Stipakov <lst...@gm... > <mailto:lst...@gm...>>: > > Hi guys, > > I made openvpn3 (required changes will be incorporated into main branch at > some point) work with wintun and did performance testing in AWS. > > Client:    c5.xlarge, Windows Server 2016, patched openvpn3 test client > and OpenVPN Connect 2.7.1.103 (uses tap-windows6, based on openvpn3). > > Server:  c5.xlarge, Ubuntu 18.04, openvpn 2.4.4 > > Client and server instances are in the same VPC and placement group. > > iPerf3 running on server: > > > iperf3 -s -B 0.0.0.0 -V > > iPerf3 running on client: > > > iperf3 -c 10.8.0.1 -V (server VPN address) > > iperf3 -c 10.0.0.18 -V (server VPC address)   > > Results: > > - no vpn > > [ ID] Interval           Transfer     Bandwidth > [  4]   0.00-10.00  sec  8.67 GBytes  7.45 Gbits/sec                  sender > [  4]   0.00-10.00  sec  8.67 GBytes  7.45 Gbits/sec                  receiver > CPU Utilization: local/sender 61.4% (5.6%u/55.8%s), remote/receiver 33.9% > (1.7%u/32.2%s) > > - tap-windows6 > > [ ID] Interval           Transfer     Bandwidth > [  4]   0.00-10.00  sec   404 MBytes   339 Mbits/sec                  sender > [  4]   0.00-10.00  sec   404 MBytes   339 Mbits/sec                  receiver > CPU Utilization: local/sender 4.6% (0.3%u/4.3%s), remote/receiver 21.4% > (2.2%u/19.2%s) > > - wintun > > [ ID] Interval           Transfer     Bandwidth > [  4]   0.00-10.00  sec   536 MBytes   449 Mbits/sec                  sender > [  4]   0.00-10.00  sec   536 MBytes   449 Mbits/sec                  receiver > CPU Utilization: local/sender 2.9% (0.1%u/2.8%s), remote/receiver 10.1% > (0.7%u/9.3%s) > > As you see, wintun performs 30% better comparison to tap-windows6 and > incurs significantly less CPU usage. > > -- > -Lev 

I think so, but before we need to incorporate wintun support into openvpn2/3 masters. ke 15. toukok. 2019 klo 17.49 Илья Шипицин (chi...@gm...) kirjoitti: > it will most probably get lost in mailing list. > can we add it to https://openvpn.net website ? something like > "performance testing" with full configs provided ? > -- -Lev 

it will most probably get lost in mailing list. can we add it to https://openvpn.net website ? something like "performance testing" with full configs provided ? ср, 15 мая 2019 г. в 18:49, Lev Stipakov <lst...@gm...>: > Hi guys, > > I made openvpn3 (required changes will be incorporated into main branch at > some point) work with wintun and did performance testing in AWS. > > Client: c5.xlarge, Windows Server 2016, patched openvpn3 test client > and OpenVPN Connect 2.7.1.103 (uses tap-windows6, based on openvpn3). > > Server: c5.xlarge, Ubuntu 18.04, openvpn 2.4.4 > > Client and server instances are in the same VPC and placement group. > > iPerf3 running on server: > > > iperf3 -s -B 0.0.0.0 -V > > iPerf3 running on client: > > > iperf3 -c 10.8.0.1 -V (server VPN address) > > iperf3 -c 10.0.0.18 -V (server VPC address) > > Results: > > - no vpn > > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 8.67 GBytes 7.45 > Gbits/sec sender > [ 4] 0.00-10.00 sec 8.67 GBytes 7.45 > Gbits/sec receiver > CPU Utilization: local/sender 61.4% (5.6%u/55.8%s), remote/receiver 33.9% > (1.7%u/32.2%s) > > - tap-windows6 > > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 404 MBytes 339 > Mbits/sec sender > [ 4] 0.00-10.00 sec 404 MBytes 339 > Mbits/sec receiver > CPU Utilization: local/sender 4.6% (0.3%u/4.3%s), remote/receiver 21.4% > (2.2%u/19.2%s) > > - wintun > > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 536 MBytes 449 > Mbits/sec sender > [ 4] 0.00-10.00 sec 536 MBytes 449 > Mbits/sec receiver > CPU Utilization: local/sender 2.9% (0.1%u/2.8%s), remote/receiver 10.1% > (0.7%u/9.3%s) > > As you see, wintun performs 30% better comparison to tap-windows6 and > incurs significantly less CPU usage. > > -- > -Lev > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > 

Hi guys, I made openvpn3 (required changes will be incorporated into main branch at some point) work with wintun and did performance testing in AWS. Client: c5.xlarge, Windows Server 2016, patched openvpn3 test client and OpenVPN Connect 2.7.1.103 (uses tap-windows6, based on openvpn3). Server: c5.xlarge, Ubuntu 18.04, openvpn 2.4.4 Client and server instances are in the same VPC and placement group. iPerf3 running on server: > iperf3 -s -B 0.0.0.0 -V iPerf3 running on client: > iperf3 -c 10.8.0.1 -V (server VPN address) > iperf3 -c 10.0.0.18 -V (server VPC address) Results: - no vpn [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 8.67 GBytes 7.45 Gbits/sec sender [ 4] 0.00-10.00 sec 8.67 GBytes 7.45 Gbits/sec receiver CPU Utilization: local/sender 61.4% (5.6%u/55.8%s), remote/receiver 33.9% (1.7%u/32.2%s) - tap-windows6 [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 404 MBytes 339 Mbits/sec sender [ 4] 0.00-10.00 sec 404 MBytes 339 Mbits/sec receiver CPU Utilization: local/sender 4.6% (0.3%u/4.3%s), remote/receiver 21.4% (2.2%u/19.2%s) - wintun [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 536 MBytes 449 Mbits/sec sender [ 4] 0.00-10.00 sec 536 MBytes 449 Mbits/sec receiver CPU Utilization: local/sender 2.9% (0.1%u/2.8%s), remote/receiver 10.1% (0.7%u/9.3%s) As you see, wintun performs 30% better comparison to tap-windows6 and incurs significantly less CPU usage. -- -Lev 

Hi, Here's the summary of the IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net Date: Wednesday 15th May 2019 Time: 11:30 CEST (9:30 UTC) Planned meeting topics for this meeting were here: <https://community.openvpn.net/openvpn/wiki/Topics-2019-05-09> Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> SUMMARY dazo, lev, mattock, ordex, plaisthos, rozmansi, syzzer and zx2c4 participated in this meeting. -- Mattock gave a brief tap-windows6 HLK testing update. He's working on an OpenVPN setup that HLK tests would be happy with. The simplistic version proposed by cron2 did not work as-is. -- Talked about the wintun driver. Lev managed to make it work on openvpn3 with a fairly small amount of work. It was agreed that integrating it with openvpn2 makes sense. -- Discussed the location of the next hackathon. Decided on Trento, Italy, where ordex lives at the moment. Ordex will create a Doodle poll for the hackathon. Other proposed alternatives were Delft, Netherlands and Oulu, Finland. -- Discussed the patches in patchwork. The sitnl patches have been ACKed and cron2 wants to work them in tonight. Dazo is working on patches for auth-token hmac from plaisthos. -- Agreed that mini-hackathons will be organized on "Fridays after Thursday meetings". Mattock will mention the mini-hackathons in the the monthly meeting invitation emails. -- Full chatlog attached. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi, On Tue, May 14, 2019 at 10:18:48AM +0200, Gert Doering wrote: > On Tue, May 14, 2019 at 10:11:59AM +0200, Antonio Quartulli wrote: > > +#ifdef ENABLE_SITNL > > +#include "networking_sitnl.h" > > +#elif ENABLE_IPROUTE > > +#include "networking_ip.h" > > +#else > > NAK, this patch breaks compilation - there is no "networking_ip.h" in > our tree, and this patch isn't introducing it either. Oh well. It doesn't break compilation, as networking.h is not yet included anywhere. And "1/7 v3" fixes the include. So while this is a slightly confusing commit, it won't *break* anything and I'll merge it ASAP. Acked-By: ge...@gr... (Gert Doering) 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 ge...@gr... 

Hi, On Tue, May 14, 2019 at 10:11:59AM +0200, Antonio Quartulli wrote: > +#ifdef ENABLE_SITNL > +#include "networking_sitnl.h" > +#elif ENABLE_IPROUTE > +#include "networking_ip.h" > +#else NAK, this patch breaks compilation - there is no "networking_ip.h" in our tree, and this patch isn't introducing it either. If we need this together with 1/7 of the v3 series, maybe we really need to make this into a joint "1/7 v4"... but every single patch needs to compile (on mainstream platforms). 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 ge...@gr... 

tun.c and route.c contain all the code used by openvpn to manage the tun interface and the routing table on all the supported platforms. Across the years, this resulted in a longer functions and series of ifdefs. This patch introduces a new "networking API" which aims at creating a simple abstraction between the tun/route logic and the platform dependent code. The is API expected to be implemented outside of tun.c/route.c by using platform specific functionalities. Signed-off-by: Antonio Quartulli <a...@un...> --- src/openvpn/Makefile.am | 1 + src/openvpn/networking.h | 278 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 279 insertions(+) create mode 100644 src/openvpn/networking.h diff --git a/src/openvpn/Makefile.am b/src/openvpn/Makefile.am index 197e62ba..8afc4146 100644 --- a/src/openvpn/Makefile.am +++ b/src/openvpn/Makefile.am @@ -80,6 +80,7 @@ openvpn_SOURCES = \	mtu.c mtu.h \	mudp.c mudp.h \	multi.c multi.h \ +	networking.h \	ntlm.c ntlm.h \	occ.c occ.h \	openssl_compat.h \ diff --git a/src/openvpn/networking.h b/src/openvpn/networking.h new file mode 100644 index 00000000..716e61a5 --- /dev/null +++ b/src/openvpn/networking.h @@ -0,0 +1,278 @@ +/* + * Generic interface to platform specific networking code + * + * Copyright (C) 2016-2018 Antonio Quartulli <a...@un...> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program (see the file COPYING included with this + * distribution); if not, write to the Free Software Foundation, Inc., + * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef NETWORKING_H_ +#define NETWORKING_H_ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#elif defined(_MSC_VER) +#include "config-msvc.h" +#endif + +#include "syshead.h" + +struct context; + +#ifdef ENABLE_SITNL +#include "networking_sitnl.h" +#elif ENABLE_IPROUTE +#include "networking_ip.h" +#else +/* define mock types to ensure code builds on any platform */ +typedef void * openvpn_net_ctx_t; +typedef void * openvpn_net_iface_t; + +static inline int +net_ctx_init(struct context *c, openvpn_net_ctx_t *ctx) +{ + return 0; +} +#endif + +#if defined(ENABLE_SITNL) || defined(ENABLE_IPROUTE) + +/** + * Initialize the platform specific context object + * + * @param c openvpn generic context + * @param ctx the implementation specific context to initialize + * + * @return 0 on success, a negative error code otherwise + */ +int net_ctx_init(struct context *c, openvpn_net_ctx_t *ctx); + +/** + * Bring interface up or down. + * + * @param ctx the implementation specific context + * @param iface the interface to modify + * @param up true if the interface has to be brought up, false otherwise + * + * @return 0 on success, a negative error code otherwise + */ +int net_iface_up(openvpn_net_ctx_t *ctx, const openvpn_net_iface_t *iface, + bool up); + +/** + * Set the MTU for an interface + * + * @param ctx the implementation specific context + * @param iface the interface to modify + * @param mtru the new MTU + * + * @return 0 on success, a negative error code otherwise + */ +int net_iface_mtu_set(openvpn_net_ctx_t *ctx, + const openvpn_net_iface_t *iface, uint32_t mtu); + +/** + * Add an IPv4 address to an interface + * + * @param ctx the implementation specific context + * @param iface the interface where the address has to be added + * @param addr the address to add + * @param prefixlen the prefix length of the network associated with the address + * @param broadcast the broadcast address to configure on the interface + * + * @return 0 on success, a negative error code otherwise + */ +int net_addr_v4_add(openvpn_net_ctx_t *ctx, const openvpn_net_iface_t *iface, + const in_addr_t *addr, int prefixlen, + const in_addr_t *broadcast); + +/** + * Add an IPv6 address to an interface + * + * @param ctx the implementation specific context + * @param iface the interface where the address has to be added + * @param addr the address to add + * @param prefixlen the prefix length of the network associated with the address + * + * @return 0 on success, a negative error code otherwise + */ + +int net_addr_v6_add(openvpn_net_ctx_t *ctx, const openvpn_net_iface_t *iface, + const struct in6_addr *addr, int prefixlen); + +/** + * Remove an IPv4 from an interface + * + * @param ctx the implementation specific context + * @param iface the interface to remove the address from + * @param prefixlen the prefix length of the network associated with the address + * + * @return 0 on success, a negative error code otherwise + */ +int net_addr_v4_del(openvpn_net_ctx_t *ctx, const openvpn_net_iface_t *iface, + const in_addr_t *addr, int prefixlen); + +/** + * Remove an IPv6 from an interface + * + * @param ctx the implementation specific context + * @param iface the interface to remove the address from + * @param prefixlen the prefix length of the network associated with the address + * + * @return 0 on success, a negative error code otherwise + */ +int net_addr_v6_del(openvpn_net_ctx_t *ctx, const openvpn_net_iface_t *iface, + const struct in6_addr *addr, int prefixlen); + +/** + * Add a point-to-point IPv4 address to an interface + * + * @param ctx the implementation specific context + * @param iface the interface where the address has to be added + * @param local the address to add + * @param remote the associated p-t-p remote address + * + * @return 0 on success, a negative error code otherwise + */ +int net_addr_ptp_v4_add(openvpn_net_ctx_t *ctx, + const openvpn_net_iface_t *iface, + const in_addr_t *local, const in_addr_t *remote); + +/** + * Remove a point-to-point IPv4 address from an interface + * + * @param ctx the implementation specific context + * @param iface the interface to remove the address from + * @param local the address to remove + * @param remote the associated p-t-p remote address + * + * @return 0 on success, a negative error code otherwise + */ +int net_addr_ptp_v4_del(openvpn_net_ctx_t *ctx, + const openvpn_net_iface_t *iface, + const in_addr_t *local, const in_addr_t *remote); + + +/** + * Add a route for an IPv4 address/network + * + * @param ctx the implementation specific context + * @param dst the destination of the route + * @param prefixlen the length of the prefix of the destination + * @param gw the gateway for this route + * @param iface the interface for this route (can be NULL) + * @param table the table to add this route to (if 0, will be added to the + * main table) + * @param metric the metric associated with the route + * + * @return 0 on success, a negative error code otherwise + */ +int net_route_v4_add(openvpn_net_ctx_t *ctx, const in_addr_t *dst, + int prefixlen, const in_addr_t *gw, + const openvpn_net_iface_t *iface, uint32_t table, + int metric); + +/** + * Add a route for an IPv6 address/network + * + * @param ctx the implementation specific context + * @param dst the destination of the route + * @param prefixlen the length of the prefix of the destination + * @param gw the gateway for this route + * @param iface the interface for this route (can be NULL) + * @param table the table to add this route to (if 0, will be added to the + * main table) + * @param metric the metric associated with the route + * + * @return 0 on success, a negative error code otherwise + */ +int net_route_v6_add(openvpn_net_ctx_t *ctx, const struct in6_addr *dst, + int prefixlen, const struct in6_addr *gw, + const openvpn_net_iface_t *iface, + uint32_t table, int metric); + +/** + * Delete a route for an IPv4 address/network + * + * @param ctx the implementation specific context + * @param dst the destination of the route + * @param prefixlen the length of the prefix of the destination + * @param gw the gateway for this route + * @param iface the interface for this route (can be NULL) + * @param table the table to add this route to (if 0, will be added to the + * main table) + * @param metric the metric associated with the route + * + * @return 0 on success, a negative error code otherwise + */ +int net_route_v4_del(openvpn_net_ctx_t *ctx, const in_addr_t *dst, + int prefixlen, const in_addr_t *gw, + const openvpn_net_iface_t *iface, uint32_t table, + int metric); + +/** + * Delete a route for an IPv4 address/network + * + * @param ctx the implementation specific context + * @param dst the destination of the route + * @param prefixlen the length of the prefix of the destination + * @param gw the gateway for this route + * @param iface the interface for this route (can be NULL) + * @param table the table to add this route to (if 0, will be added to the + * main table) + * @param metric the metric associated with the route + * + * @return 0 on success, a negative error code otherwise + */ +int net_route_v6_del(openvpn_net_ctx_t *ctx, const struct in6_addr *dst, + int prefixlen, const struct in6_addr *gw, + const openvpn_net_iface_t *iface, + uint32_t table, int metric); + +/** + * Retrieve the gateway and outgoing interface for the specified IPv4 + * address/network + * + * @param ctx the implementation specific context + * @param dst The destination to lookup + * @param prefixlen The length of the prefix of the destination + * @param best_gw Location where the retrieved GW has to be stored + * @param best_iface Location where the retrieved interface has to be stored + * + * @return 0 on success, a negative error code otherwise + */ +int net_route_v4_best_gw(openvpn_net_ctx_t *ctx, const in_addr_t *dst, + int prefixlen, in_addr_t *best_gw, + openvpn_net_iface_t *best_iface); + +/** + * Retrieve the gateway and outgoing interface for the specified IPv6 + * address/network + * + * @param ctx the implementation specific context + * @param dst The destination to lookup + * @param prefixlen The length of the prefix of the destination + * @param best_gw Location where the retrieved GW has to be stored + * @param best_iface Location where the retrieved interface has to be stored + * + * @return 0 on success, a negative error code otherwise + */ +int net_route_v6_best_gw(openvpn_net_ctx_t *ctx, const struct in6_addr *dst, + int prefixlen, struct in6_addr *best_gw, + openvpn_net_iface_t *best_iface); + +#endif /* ENABLE_SITNL || ENABLE_IPROUTE */ + +#endif /* NETWORKING_H_ */ -- 2.21.0 

Your patch has been applied to the master and release/2.4 branch. Why 2.4? Because since this changes the calling convention of quite a number of functions (by removing never-used arguments) I'm fairly sure it will get in the way of future bugfixes that tackle "related code" - and *those* need to go to 2.4. So take this in, even if "refactoring" is normally not done here. But these are very straightforward changes. commit 91ba1add2f8f231a7ccf4557cdd593547e625723 (master) commit 0c1cc8d65539f5e156866056df9074d47bc3ed4b (release/2.4) Author: Lev Stipakov Date: Tue Oct 30 10:53:35 2018 +0200 Fix various compiler warnings Signed-off-by: Lev Stipakov <le...@op...> Acked-by: Arne Schwabe <ar...@rf...> Message-Id: <154...@gm...> URL: https://www.mail-archive.com/ope...@li.../msg17855.html Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering