[Openvpn-devel] [PATCH v2 4/9] client-connect: Move multi_client_connect_setenv into early_setup

This patch moves multi_client_connect_setenv into multi_client_connect_early_setup and makes sure that every client-connect handling function updates the virtual address selection. Background: This unifies how the client-connect handling functions work. Signed-off-by: Fabian Knittel <fabian.k

[Openvpn-devel] [PATCH v2 7/9] client-connect: Add CC_RET_DEFERRED and cope with deferred client-connect

) additional call-back: The call-back for handling the deferred case. If the main call-back returns CC_RET_DEFERRED, the next call to the handler will be through the deferred call-back. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c

[Openvpn-devel] [PATCH v2 3/9] client-connect: Refactor multi_client_connect_source_ccd

Refactor multi_client_connect_source_ccd(), so that options_server_import() (or the success path in general) is only entered in one place within the function. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 29 + 1 file chang

[Openvpn-devel] [PATCH v2 5/9] client-connect: Refactor to use return values instead of modifying a passed-in flag

in completely identical ways. This is in preparation of handling the helpers as simple call-backs. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 122 +++- src/openvpn/multi.h | 11 - 2 files changed, 82 inse

[Openvpn-devel] [PATCH v2 8/9] client-connect: Add deferred support to the client-connect script handler

the value for deferral into the deferred_ret_file, the handler knows to indicate deferral. Later on, the deferred handler checks whether the value of the deferred_ret_file has been updated to success or failure. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c

[Openvpn-devel] [PATCH v2 9/9] client-connect: Add deferred support to the client-connect plugin v1 handler

Uses the infrastructure provided and used in the previous patch to provide deferral support to the v1 client-connect plugin handler as well. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 32 1 file changed, 20 inse

[Openvpn-devel] [PATCH v2 2/9] client-connect: Properly indent all functions

This patch adds proper indentation to all new helper functions. No functional changes are performed. Nothing is moved around. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 408 ++-- 1 file change

[Openvpn-devel] [PATCH v2 6/9] client-connect: Refactor client-connect handling to calling a bunch of hooks in a loop

This patch changes the calling of the client-connect functions into an array of hooks and a block of code that calls them in a loop. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 57 +++-- 1 file chang

[Openvpn-devel] [PATCH v2 1/9] client-connect: Split multi_connection_established into separate functions

patch will only do indentation changes.) Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 322 ++ src/openvpn/options.h | 6 + 2 files changed, 224 insertions(+), 104 deletions(-) diff --git a/src/o

[Openvpn-devel] [PATCH v2 0/9] Refactor client-connect / add support for deferred handling

vailabe on a Github branch: https://github.com/fknittel/openvpn/tree/feat_deferred_client-connect Cheers Fabian PS: See https://github.com/fknittel/openvpn/wiki/Patch-set-%22deferred-client-connect%22 in case you're interested in ready-made Debian packages. Fabian Knittel (9): client-connect: S

[Openvpn-devel] [PATCH 4/9] client-connect: Move multi_client_connect_setenv into early_setup

This patch moves multi_client_connect_setenv into multi_client_connect_early_setup and makes sure that every client-connect handling function updates the virtual address selection. Background: This unifies how the client-connect handling functions work. Signed-off-by: Fabian Knittel <fabian.k

[Openvpn-devel] [PATCH 5/9] client-connect: Refactor to use return values instead of modifying a passed-in flag

in completely identical ways. This is in preparation of handling the helpers as simple call-backs. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 122 +++- src/openvpn/multi.h | 11 - 2 files changed, 82 inse

[Openvpn-devel] [PATCH 2/9] client-connect: Properly indent all functions

This patch adds proper indentation to all new helper functions. No functional changes are performed. Nothing is moved around. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 408 ++-- 1 file change

[Openvpn-devel] [PATCH 8/9] client-connect: Add deferred support to the client-connect script handler

the value for deferral into the deferred_ret_file, the handler knows to indicate deferral. Later on, the deferred handler checks whether the value of the deferred_ret_file has been updated to success or failure. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c

[Openvpn-devel] [PATCH 9/9] client-connect: Add deferred support to the client-connect plugin v1 handler

Uses the infrastructure provided and used in the previous patch to provide deferral support to the v1 client-connect plugin handler as well. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 30 +++--- 1 file changed, 19 insertions(

[Openvpn-devel] [PATCH 6/9] client-connect: Refactor client-connect handling to calling a bunch of hooks in a loop

This patch changes the calling of the client-connect functions into an array of hooks and a block of code that calls them in a loop. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 57 +++-- 1 file chang

[Openvpn-devel] [PATCH 0/9] Refactor client-connect / add support for deferred handling

h: https://github.com/fknittel/openvpn/tree/feat_deferred_client-connect Cheers Fabian PS: See https://github.com/fknittel/openvpn/wiki/Patch-set-%22deferred-client-connect%22 in case you're interested in ready-made Debian packages. Fabian Knittel (9): client-connect: Split multi_connection_estab

[Openvpn-devel] [PATCH 3/9] client-connect: Refactor multi_client_connect_source_ccd

Refactor multi_client_connect_source_ccd(), so that options_server_import() (or the success path in general) is only entered in one place within the function. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 29 + 1 file chang

[Openvpn-devel] [PATCH 1/9] client-connect: Split multi_connection_established into separate functions

patch will only do indentation changes.) Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c | 312 +++--- src/openvpn/options.h | 6 + 2 files changed, 224 insertions(+), 94 deletions(-) diff --git a/src/openvpn/m

[Openvpn-devel] [PATCH 7/9] client-connect: Add CC_RET_DEFERRED and cope with deferred client-connect

) additional call-back: The call-back for handling the deferred case. If the main call-back returns CC_RET_DEFERRED, the next call to the handler will be through the deferred call-back. Signed-off-by: Fabian Knittel <fabian.knit...@lettink.de> --- src/openvpn/multi.c

Re: [Openvpn-devel] Async OPENVPN_PLUGIN_CLIENT_CONNECT plugin support

Hi Lev, 2014-10-07 20:50 GMT+02:00 Lev Stipakov : > Patch works great, thanks! I have rebased it a bit and added support > for client-connect plugin call. > Great to hear that my patch works for you! I've finally rebased the patches too, due to my current users complaining

Re: [Openvpn-devel] Async OPENVPN_PLUGIN_CLIENT_CONNECT plugin support

Hi Lev, 2014-07-29 12:56 GMT+02:00 Lev Stipakov : > I am pondering about asynchronous OPENVPN_PLUGIN_CLIENT_CONNECT > callback. Basically, I want _not_ to establish connection until > response is received and ofcI don't want to block rest of traffic. > [ Details of

Re: [Openvpn-devel] [PATCH] Repair "tap server" mode brokenness caused by fallout

Hi everyone, 2012/6/30 Gert Doering : > diff --git a/src/openvpn/mroute.c b/src/openvpn/mroute.c > index aecb702..850e336 100644 > --- a/src/openvpn/mroute.c > +++ b/src/openvpn/mroute.c > @@ -52,7 +52,7 @@ mroute_addr_init (struct mroute_addr *addr) >  static inline bool >  

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

Hi Alon, 2012/5/13 Alon Bar-Lev : > On Sun, May 13, 2012 at 9:10 PM, Gert Doering wrote: >> Huh?  You're the master of Autoconf, and I'm sure you will be able to >> produce a working PAM detection for those platforms that have it. > > Yes, and as such

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

Hi Alon, 2012/5/11 Alon Bar-Lev <alon.bar...@gmail.com>: > On Fri, May 11, 2012 at 12:11 AM, Fabian Knittel > <fabian.knit...@lettink.de> wrote: >> The main undecided points regarding the interface side of things appear to >> be: >> * How to pass

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

Hi, 2012/5/10 David Sommerseth : > On 10/05/12 16:50, Alon Bar-Lev wrote: >> Why? plugin is adding a custom logic, and you need custom logic. As >> I wrote it does not imply that you implement your JNI there. > > Okay ... fine ... there are plenty of big visions for

Re: [Openvpn-devel] [PATCH] build: add git revision to --version output if build from git repository

Hi, 2012/5/3 David Sommerseth : > What I would like to see is something more like what's found in TOR > projects' obfsproxy, where the Makefile generates a micro-version.i, > which is included.  As this file is forced to be (re-)created each > time, it will always

Re: [Openvpn-devel] [PATCH] cleanup: add .gitattributes to control eol style explicitly

Hi Alon, 2012/4/2 Alon Bar-Lev : > Having the text auto detection is a risk, as the detection may detect > text files that are not text and vise versa. > > Having global setting will create confusion and differentiate between > users. So this patch also move this to local

Re: [Openvpn-devel] [PATCH] cleanup: plugin: support C++ plugin

Hi Alon, 2012/4/7 Alon Bar-Lev : > Signed-off-by: Alon Bar-Lev > --- >  include/openvpn-plugin.h |    8 >  1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/include/openvpn-plugin.h b/include/openvpn-plugin.h > index

Re: [Openvpn-devel] [PATCH] cleanup: remove C++ comments

Hi Alon, 2012/4/7 Alon Bar-Lev : > Signed-off-by: Alon Bar-Lev > --- >  src/openvpnserv/openvpnserv.c |    6 +++--- >  1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/openvpnserv/openvpnserv.c b/src/openvpnserv/openvpnserv.c >

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

Hi Alon, 2012/4/2 Alon Bar-Lev : > I also intend to work and cleanup the whole PolarSSL/OpenSSL mess... > > Design will be to introduce crypto engine callback structure, > registering openssl and polarssl, in a way that code is using the > callback structure while using

Re: [Openvpn-devel] [DISCUSS] OpenVPN public repositories at github.com

Hi, 2012/3/30 Samuli Seppänen : >>> [*] As in "We will have the community services on our own servers. Period." BTW: If you like self-hosting, we're experimenting with Gerrit for code review (also provides Git repo hosting as a by-product) and it's looking quite promising.

Re: [Openvpn-devel] [PATCH] Avoid using ~0

Hi Alon, I stumbled over a minor mistake: 2012/3/28 Alon Bar-Lev : > diff --git a/src/openvpn/route.c b/src/openvpn/route.c > index bf7af63..05ea57f 100644 > --- a/src/openvpn/route.c > +++ b/src/openvpn/route.c > @@ -1367,7 +1367,7 @@ add_route (struct route *r, >    

Re: [Openvpn-devel] 2.3alpha1 fails on OS X when the --up argument contains more than an execution path

Hi Jonathan, 2012/3/28 Jonathan K. Bullard : > There is one part of check_cmd_access() which I took from code in > run_up_down() and I am not sure about -- the three lines: >   gc_arena gc; > and >   gc = gc_new (); > and >   gc_free (); > > Are they needed? I put them in

Re: [Openvpn-devel] [PATCH 35/52] build: proper selinux detection and usage

Hi Alon, >> AC_CHECK_LIB([selinux], [setcon], [SELINUX_LIBS="-lselinux"]) >> >> versus >> >> AC_CHECK_HEADER([selinux/selinux.h], [ >>    AC_CHECK_LIB([selinux], [setcon], [SELINUX_LIBS="-lselinux"], >>        [AC_MSG_RESULT([SELinux library not found.])] >>    )],  [AC_MSG_ERROR([SELinux headers

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

Hi Alon, 2012/3/16 Alon Bar-Lev <alon.bar...@gmail.com>: > On Fri, Mar 16, 2012 at 3:29 PM, Fabian Knittel > <fabian.knit...@lettink.de> wrote: >> In my opinion, the build defaults should reflect what the project >> considers as the recommended defaults - the featu

Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?

Hi, 2012/3/16 Alon Bar-Lev : > If we do not want to do auto detection, enabling optional components > may lead to configure failure, and force the user to explicitly > disable this feature. > > It is possible, and I don't mind so much, however, I prefer configure > to use

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

Hi Heiko, Am 9. März 2012 14:42 schrieb Heiko Hund : > Instead I plan to secure the process (and the probably the pipe handle as > well) against malicious operations by not granting the user any sophisticated > access to it, i.e. you can only inject code if you can write

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

Hi Gert, 2012/2/29 Gert Doering : > The model we follow is "openvpn.exe has the same permissions that you > already have, so there is no benefit in manipulating anything". That was my initial assumption, which would imply that there's no reason to restrict access to the

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

Hi Heiko, 2012/2/29 Heiko Hund <heiko.h...@sophos.com>: > On Wednesday 29 February 2012 14:07:01 Fabian Knittel wrote: [...] >> (There must be something missing, otherwise >> I don't get why you call it "interactive service" ...?) > > It's interactive in c

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

Hi Heiko, Am 29. Februar 2012 13:18 schrieb Heiko Hund : > [...] There will be a new service, I called it > interactive service. The GUI/client connects to a named pipe of that service. > It passes the working directory, command line options and stdin input for > openpvn to

Re: [Openvpn-devel] [PATCH 1/2] Added support for new PolarSSL 1.1 RNG

Hi Adriaan, I only found a minor nit: 2012/2/28 Adriaan de Jong : > --- a/ssl.c > +++ b/ssl.c > @@ -385,6 +385,11 @@ init_ssl (const struct options *options, struct > tls_root_ctx *new_ctx) >       tls_ctx_restrict_ciphers(new_ctx, options->cipher_list); >     } > > +#ifdef

Re: [Openvpn-devel] [PATCH 01/02] Add support for PolarSSL 1.1.x branch

Hi Igor, 2012/2/28 Igor Novgorodov <i...@novg.net>: > On 28.02.2012 1:37, Fabian Knittel wrote: >> Your patch removes the code that causes havege_init() to only be >> called once. You never want to initialise your PRNG more than once, >> otherwise you increase th

Re: [Openvpn-devel] [PATCH 01/02] Add support for PolarSSL 1.1.x branch

Hi Igor, 2012/2/27 Igor Novgorodov : > The attached patch adds checking for PolarSSL version on crypto_polarssl.c > and depending on which version we are using (1.0.x or 1.1.x) chooses a new > shiny havege_random() function, or an old ugly while{} loop hack to generate >

Re: [Openvpn-devel] OpenVPN and Android 4.0 VPN API

Hi Gert, 2012/2/8 Gert Doering : > On Wed, Feb 08, 2012 at 11:27:10AM -0800, James Ring wrote: >> Does other code within openvpn care whether the fd is a UNIX socket or >> a tun/tap device? I'm guessing there may be some ioctls it wants to >> perform on the device. > > There

Re: [Openvpn-devel] OpenVPN and Android 4.0 VPN API

Hi James, 2012/2/8 James Ring : > On Wed, Feb 8, 2012 at 10:24 AM, Gert Doering wrote: >> Exactly.  The first three things are sort of "nearly done", the >> "receive file descriptor to use for tun/tap" would need to be >> implemented (tun.c, open_tun(), #ifdef

Re: [Openvpn-devel] Problem with alloc_buf_gc function

Hi Tiran, Am 11.12.2011 21:57, schrieb Tiran Kaskas: > Looking into the function alloc_buf_gc() in file buffer.c, it returns a > struct buffer, which seems to me is allocated on the stack, which is > causing an issue, I believe, since the function calling alloc_buf_gc() > will work on a buffer

Re: [Openvpn-devel] [PATCH] Add option to disable priority tagged packets (VID=0)

Hi Alon, Am 08.12.2011 21:17, schrieb Alon Bar-Lev: > I fail to understand why this is relevant as far as usage (openvpn --help) and > manual (man openvpn) to document this. Ah. Sorry for the misunderstanding. Are you referring to the specific patch by Michael? I agree that it would have

Re: [Openvpn-devel] Summary of the IRC meeting (20th May 2010)

Am 25.05.2010 10:42, schrieb David Sommerseth: > Personally, I would also not enforce BSD as the only license for > bounties. We need to provide at least a choice, at least between GPL > and BSD. > > I would not consider to license my contributions to OpenVPN as BSD, > because a) I want other

[Openvpn-devel] [PATCH] ssl.c: fix use of openvpn_run_script()'s return value

value handling is fine for the other places where openvpn_run_script() is used, because those places previously used openvpn_execve_check() (notice the "_check" suffix). Signed-off-by: Fabian Knittel <fabian.knit...@avona.com> --- ssl.c | 20 ++-- 1 files change

[Openvpn-devel] [PATCH 6/6] vlan: move htons / ntohs into vlanhdr_get/_set functions

. The patch moves all htons() and ntohs() conversions into the vlan_hdr_* functions to avoid the needless repetition. The vlan_hdr_* functions now expect and return the values in host byte order. The callee doesn't need to perform any kind of conversion. Signed-off-by: Fabian Knittel <fabian.k

[Openvpn-devel] [PATCH 2/6] vlan: use uint16_t for storage of the VID where possible

-1. The patch should not cause any changes in behaviour. The improvement was suggested by Peter Stuge. Signed-off-by: Fabian Knittel <fabian.knit...@avona.com> --- mroute.c |6 +++--- mroute.h |6 +++--- multi.c | 24 options.c |2 +- options.h

[Openvpn-devel] [PATCH 4/6] vlan: Improve documentation of remove_vlan_tag()

This patch improves the comments that document the remove_vlan_tag() function. It clarifies what is meant by "priority-tagged frames" and documents the parameters and return value. Signed-off-by: Fabian Knittel <fabian.knit...@avona.com> --- multi.c |9 +++-- 1

[Openvpn-devel] [PATCH 5/6] vlan: is_ipv4: fix position of variable definition

To avoid difficulties on older / stricter C compilers, this patch moves the variable definition to the beginning of the block in is_ipv4(). Found by Peter Stuge. Signed-off-by: Fabian Knittel <fabian.knit...@avona.com> --- proto.c |2 +- 1 files changed, 1 insertions(+), 1 del

[Openvpn-devel] [PATCH 1/6] vlan: Mention 802.1Q in configuration descriptions

To clarify that the tagging/untagging is based on the 802.1Q standard, this patch adds "802.1Q-based" to a few descriptive strings. The improvement was suggested by Peter Stuge. Signed-off-by: Fabian Knittel <fabian.knit...@avona.com> --- configure.ac |4 ++-- options.c

[Openvpn-devel] [PATCH 3/6] vlan: slightly clean-up buf_filter_incoming_vlan_tags()

This patch changes buf_filter_incoming_vlan_tags() to use a less nested code-style. It also improves documentation of the function. In addition, the function is made static, as it is only used locally. Code based on a snippet by Peter Stuge. Signed-off-by: Fabian Knittel <fabian.k

Re: [Openvpn-devel] [PULL-REQUEST v3] VLAN-Tagging

Hi David, David Sommerseth wrote: > I've finally found some time to dig into this again. After some > consideration, I decided to rebase your work on your feat_vlan_tagging > branch against the openvpn-testing.git feat_vlan_tagging branch. > > This means that your earlier patches without

Re: [Openvpn-devel] [PATCHv2 1/3] Harden create_temp_filename() (version 2)

Hi David, David Sommerseth wrote: > +} > + while (attempts < 6); > > - return gen_path (directory, BSTR (), gc); > + msg (M_FATAL, "Failed to create temporary file after %i attempts", > attempts); > + return NULL; > } I noticed something else ... if - hypothetically - someone manages

Re: [Openvpn-devel] [PATCHv2 2/3] Renamed all calls to create_temp_filename()

Hi David, David Sommerseth wrote: > diff --git a/multi.c b/multi.c > index 2b04428..826a113 100644 > --- a/multi.c > +++ b/multi.c > @@ -1530,7 +1530,13 @@ multi_connection_established (struct multi_context *m, > struct multi_instance *mi >if (plugin_defined (mi->context.plugins, >

Re: [Openvpn-devel] [PATCH] Harden create_temp_filename()

Hi David, David Sommerseth wrote: > On 16/04/10 11:35, Gert Doering wrote: >> Hi, > >> On Fri, Apr 16, 2010 at 11:16:32AM +0200, David Sommerseth wrote: >>> I'll look more into this, as the only advantage is that if open() with >>> O_EXCL|O_CREAT fails if the file exists, it should be used

Re: [Openvpn-devel] [PATCH] Harden create_temp_filename()

Hi David, David Sommerseth schrieb: > As promised in the meeting today, a patch for hardening > create_temp_filename(). Great! :) > I've added more checks to what create_temp_filename() returns where it > is called in addition, to make it even safer. > + do { > uint8_t rndbytes[16]; >

Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames

[ I just noticed that I accidentally sent this only to David and not to the list. It was written and sent on Thu, 01 Apr 2010 15:46:21 +0200 ] David Sommerseth wrote: > But what kind traffic does hit the OpenVPN clients? Does the OpenVPN > server send only traffic to the corresponding VLAN the

Re: [Openvpn-devel] [RFC][PATCH 0/9] VLAN tagging on TAP devices in OpenVPN server mode

David Sommerseth schrieb: > If you have a public git tree available, I could pull that as well. (I > tried the git URL the webUI gave me yesterday, without luck). Ah, thanks for noticing ... the non-ssh path apparently doesn't get used often. I forgot to fix the URLs since switching to gitosis.

Re: [Openvpn-devel] [RFC][PATCH 0/9] VLAN tagging on TAP devices in OpenVPN server mode

David Sommerseth schrieb: > On 01/04/10 10:32, Fabian Knittel wrote: >> We'll definitely be doing that over here. My main concern was whether >> we would have to patch OpenVPN indefinitely with local enhancements or >> whether there was a chance to include it upstream.

Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames

Peter Stuge schrieb: > Jan Just Keijser wrote: >> FYI: 802.1Q defines VLAN 1 as the 'native' LAN: all packets on VLAN 1 >> are *by definition* not encapsulated (according to my CCNA guide ;-)) [...] >> Perhaps we need to make sure that VID 1 means untagged ... > > Any VID can be untagged. While

Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames

Fabian Knittel schrieb: > Peter Stuge schrieb: >> It would be nice to be able to use VID 0 to mean untagged packets. > > Hm, nice idea. I'll implement it in my next round of patches. I've just noticed a detail that might warrant discussion. To make sure we're talking about

Re: [Openvpn-devel] [RFC][PATCH 0/9] VLAN tagging on TAP devices in OpenVPN server mode

Hi David, David Sommerseth schrieb: > Thank you very much for your patches! I'll look into them soon. Thanks! > The > patches seems to apply nicely against the feat_passtos branch. I was > worried about a conflict here, until I noticed where you had your roots :) Actually, I was lucky to

Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames

Peter Stuge schrieb: > Fabian Knittel wrote: >> + if (ntohs (vlanhdr.tpid) != OPENVPN_ETH_P_8021Q) >> +{ >> + /* Drop untagged frames */ >> + goto err; >> +} > > It would be nice to be able to use VID 0 to mean untagged packets. Hm, n

Re: [Openvpn-devel] [PATCH 3/9] vlan: Add per-client --vlan-tag option

Hi Peter, Peter Stuge schrieb: > Fabian Knittel wrote: >> +#define OPENVPN_8021Q_MAX_VID 0xFFFE > > The max VID in 802.1q is 4095 = 0xfff. You are absolutely correct. Thanks for catching that. I intended it to say 0xFFE, because the standard talks about VID values being valid w

[Openvpn-devel] [PATCH 2/9] vlan: Add global --vlan-tagging option

This patch adds the new "--vlan-tagging" boolean option. The option is valid in server mode. It is off by default. The flag indicates whether openvpn should assume the tap device to be in tagged mode, i.e. packets coming in on the device are tagged via IEEE 802.1Q and packets going out through

[Openvpn-devel] [PATCH 3/9] vlan: Add per-client --vlan-tag option

This patch adds the new "--vlan-tag" integer option. The option is valid in server mode and can be set in a client context (e.g. from the client-connect hook). It defaults to 0. The value indicates which VID (VLAN identifier) to associate with a client. The client will only receive packets

[Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames

This patch adds parsing of the IEEE 802.1Q headers for incoming and outgoing ethernet frames. For frames coming in from the tap interface, the 802.1Q header is parsed and translated into a regular Ethernet II header. Note that the Priority Code Point (PCP) and Canonical Format Indicator (CFI)

[Openvpn-devel] [PATCH 8/9] vlan: add debug logging to tagging / untagging

--- multi.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/multi.c b/multi.c index 822ae29..661fd98 100644 --- a/multi.c +++ b/multi.c @@ -2143,11 +2143,15 @@ remove_vlan_identifier (struct buffer *buf) if (ntohs (vlanhdr.tpid) != OPENVPN_ETH_P_8021Q) {

[Openvpn-devel] [PATCH 7/9] vlan: Slightly enhance PF's protocol inspection of 802.1Q packets

To allow openvpn's PF code to inspect IP packets contained within 802.1Q packets, this patch enhances mroute_extract_addr_ether() to properly skip over the 802.1Q header. --- mroute.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/mroute.c b/mroute.c index

[Openvpn-devel] [PATCH 6/9] vlan: Restrict broadcasts to the sender's VLAN.

This patch enhances openvpn's internal packet routing to restrict broadcast packets to destinations with a matching VID. I.e. broadcasts from client to client or from tap interface to clients are now filtered based on whether the client belongs to the correct VLAN id. --- multi.c | 15

[Openvpn-devel] [PATCH 9/9] vlan: add debug logging to broadcast filter

--- multi.c | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/multi.c b/multi.c index 661fd98..641d464 100644 --- a/multi.c +++ b/multi.c @@ -1806,7 +1806,21 @@ multi_bcast (struct multi_context *m, } #endif if (vid != 0 && vid

[Openvpn-devel] [PATCH 5/9] vlan: Add VLAN identifier to mroute_addr for ethernet addresses

This patch appends the VID to the ethernet address in mroute_addr. By including the VID in mroute_addr, the routing space is divided by VLAN. This means: - duplicate MAC addresses on different VLANs no longer conflict and - all unicast-traffic is constrained to whatever VLAN the traffic came

[Openvpn-devel] [PATCH 1/9] is_ipv4(): add packet length check for 802.1Q packets

This patch adds an additional length check to is_ipv4(). Currently is_ipv4() only checks whether the frame is large enough for struct openvpn_ethhdr. In case of an 802.1Q packet the function now also checks whether the frame is large enough for struct openvpn_8021qhdr, which is 4 bytes larger