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
---
src
ional) 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
---
src/openvpn/multi.c | 255 ++--
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
---
src/openvpn/multi.c | 29 +
1 file changed, 13 insertions(+), 16 deletions
completely identical
ways. This is in preparation of handling the helpers as simple call-backs.
Signed-off-by: Fabian Knittel
---
src/openvpn/multi.c | 122 +++-
src/openvpn/multi.h | 11 -
2 files changed, 82 insertions(+), 51 deletions(-)
diff
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
---
src/openvpn/multi.c | 185
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
---
src/openvpn/multi.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git
This patch adds proper indentation to all new helper functions. No functional
changes are performed. Nothing is moved around.
Signed-off-by: Fabian Knittel
---
src/openvpn/multi.c | 408 ++--
1 file changed, 204 insertions(+), 204 deletions
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
---
src/openvpn/multi.c | 57 +++--
1 file changed, 16 insertions(+), 41 deletions
patch will only do indentation changes.)
Signed-off-by: Fabian Knittel
---
src/openvpn/multi.c | 322 ++
src/openvpn/options.h | 6 +
2 files changed, 224 insertions(+), 104 deletions(-)
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
lso availabe 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-
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
---
src
completely identical
ways. This is in preparation of handling the helpers as simple call-backs.
Signed-off-by: Fabian Knittel
---
src/openvpn/multi.c | 122 +++-
src/openvpn/multi.h | 11 -
2 files changed, 82 insertions(+), 51 deletions(-)
diff
This patch adds proper indentation to all new helper functions. No functional
changes are performed. Nothing is moved around.
Signed-off-by: Fabian Knittel
---
src/openvpn/multi.c | 408 ++--
1 file changed, 204 insertions(+), 204 deletions
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
---
src/openvpn/multi.c | 177
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
---
src/openvpn/multi.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a
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
---
src/openvpn/multi.c | 57 +++--
1 file changed, 16 insertions(+), 41 deletions
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: Split multi_connec
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
---
src/openvpn/multi.c | 29 +
1 file changed, 13 insertions(+), 16 deletions
patch will only do indentation changes.)
Signed-off-by: Fabian Knittel
---
src/openvpn/multi.c | 312 +++---
src/openvpn/options.h | 6 +
2 files changed, 224 insertions(+), 94 deletions(-)
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
ional) 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
---
src/openvpn/multi.c | 255 ++--
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
about the old OpenVPN
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 approach snipped. ]
What do
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
> is_mac_mcast_addr (con
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 I tell you that automatic detection is someth
Hi Alon,
2012/5/11 Alon Bar-Lev :
> On Fri, May 11, 2012 at 12:11 AM, Fabian Knittel
> wrote:
>> The main undecided points regarding the interface side of things appear to
>> be:
>> * How to pass the fds back and forth: Special-case the management
>> interface fo
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 a future version
> of OpenVPN,
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 be accurate.
>
> I don't say that
Hi Alon,
2012/4/26 Alon Bar-Lev :
> At embedded system and several distros like Gentoo, the ipv6 should be
> made enable/disabled, just like any other project.
> It is the same #ifdef as we already have these in code.
> Even in 2012 kernels can be compiled without ipv6.
If embedded systems really
Hi David,
2012/4/26 David Sommerseth :
> These days it is highly unlikely that OpenVPN will be built in a non-IPv6
> capable Linux environment.
Agreed.
> This also solves an issue which was introduced in commit 51bd56f46f55177cf0f8b
> where HAVE_TUN_PI and HAVE_IPHDR is no longer detected. As t
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 repository.
IMHO, this i
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 f82f61f..1c80eec 100644
> --- a/include/openvpn-plugin.
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
> index a9a9441..56f5a02 100755
> --- a/src/openvp
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 runtime configuration one c
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. Would formalise the ACK
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,
> else if ((flags & ROUTE_MET
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 (&gc);
>
> Are they needed? I put them in because I assume that
Hi Alon,
2012/3/24 Alon Bar-Lev :
> On Sat, Mar 24, 2012 at 9:15 PM, Alon Bar-Lev wrote:
>> PPC architectures and conflict with stdbool.h.
>>
>> basic.h defines a type 'bool' that conflicts with the altivec
>> keyword bool which has to be fixed upstream, see bugs[1][2].
>>
>> [1] https://bugs.gen
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
Hi Alon,
sorry for digging up the dead, but our disagreements might have
started earlier and just went unnoticed so far ... :)
2012/3/8 Alon Bar-Lev :
> I wrote this in the introduction of the patch set.
>
> There are two approaches to detecting dependencies:
>
> 1. Detect all compile time depend
Hi Alon,
2012/3/16 Alon Bar-Lev :
> On Fri, Mar 16, 2012 at 3:29 PM, Fabian Knittel
> wrote:
>> In my opinion, the build defaults should reflect what the project
>> considers as the recommended defaults - the features we want to see in
>> every typical OpenVPN server an
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 the minimum absolutely ne
Hi,
2012/3/13 Heiko Hund :
> On Monday 12 March 2012 19:01:41 Alon Bar-Lev wrote:
>> What is the baseline? This what we should agree first...
>> Should openvpn daemon be run on completely unprivileged account or not.
>
> I don't support the idea about running openvpn.exe with elevated privileges.
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 the process'
> memory. Thi
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 named pipe (apart from mak
Hi Heiko,
2012/2/29 Heiko Hund :
> 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 contrast to the
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 the service. The servic
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 USE_POLARSSL
> + /*
Hi Igor,
2012/2/28 Igor Novgorodov :
> 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 the risk that your randomness
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
> randomness.
Your patch re
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 aren't any ioctl()s (I
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 ANDROID_MAGIC_VPN :-) )
>
> I was th
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 whi
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 neede
Hi Michael, Hi David, Hi Alon,
On 08/12/11 09:33, michael-dev wrote:
> This patch adds an option to disable the creation of tagged priority
> packets with VID=0. This is for the feature_vlan_tagging
> openvpn-testing head.
Great to know that other people are using the patch-set too. Your patch
i
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 peo
Hi,
as we've now completed (almost) all necessary building blocks for
running OpenVPN in our intended environment, we've started testing the
feat_vlan_tagging branch in earnest.
Of course, we've immediately encountered the first problem. :)
Currently, if VLAN-tagged packets coming in on the tap
ling 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
---
ssl.c | 20 ++--
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git
.
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
---
mu
returning -1.
The patch should not cause any changes in behaviour.
The improvement was suggested by Peter Stuge.
Signed-off-by: Fabian Knittel
---
mroute.c |6 +++---
mroute.h |6 +++---
multi.c | 24
options.c |2 +-
options.h |2 +-
proto.
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
---
multi.c |9 +++--
1 files changed, 7 insertions(+), 2 deletion
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
---
proto.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/proto.c b
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
---
configure.ac |4 ++--
options.c|2 +-
2 files changed, 3
branch on
git://fsmi-dev.fsmi.uni-karlsruhe.de/openvpn.git
Cheers
Fabian
Fabian Knittel (6):
vlan: Mention 802.1Q in configuration descriptions
vlan: use uint16_t for storage of the VID where possible
vlan: slightly clean-up buf_filter_incoming_vlan_tags()
vlan: Improve docume
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
---
multi.c | 39
Hi Peter,
Peter Stuge wrote:
Fabian Knittel wrote:
+++ b/configure.ac
@@ -212,6 +212,12 @@ AC_ARG_ENABLE(selinux,
[SELINUX="yes"]
)
+AC_ARG_ENABLE(vlan-tagging,
+ [ --disable-vlan-tagging Disable support for VLAN tagging/untagging],
+ [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 signed-
Hi David,
David Sommerseth wrote:
> +}
> + while (attempts < 6);
>
> - return gen_path (directory, BSTR (&fname), gc);
> + msg (M_FATAL, "Failed to create temporary file after %i attempts",
> attempts);
> + return NULL;
> }
I noticed something else ... if - hypothetically - someone ma
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,
> OPENV
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 instea
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];
>
struct mroute_addr *esrc,
struct mroute_addr *edest,
- const struct buffer *buf);
+ const struct buffer *buf,
+ int16_t vid);
unsigned int ret = 0;
verify_align_4 (buf);
if (tunnel_type == DEV_TYPE_TUN)
ret = mroute_extract_addr_ipv4 (src, dest, buf);
Hi,
Gert Doering schrieb:
> On Thu, Apr 01, 2010 at 10:59:05AM +0200, Jan Just Keijser wrote:
>>> Hm, nice idea. I'll implement it in my next round of patches.
>>>
>> FYI: 802.1Q defines VLAN 1 as the 'native' LAN: all packets on VLAN 1
>> are *by definition* not encapsulated (according to my
Hi Gert,
Gert Doering wrote:
> Something else I need to check: the "standard" mroute code hashes based
> on ethernet address (in tap mode). What happens if the same MAC address
> shows up for two different VLAN IDs? (Not very likely for virtual
> ethernet devices, though, but this can happen in
[ 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
if (proto == OPENVPN_ETH_P_8021Q &&
+ BLEN (buf) >= (int) sizeof (struct openvpn_8021qhdr))
{
const struct openvpn_8021qhdr *tag = (const struct openvpn_8021qhdr *) BPTR (buf);
proto = ntohs (tag->proto);
@@ -314,7 +322,9 @@ mroute_addr_print_ex (const struct mroute_
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. I
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 upst
Jan Just Keijser schrieb:
> Peter Stuge wrote:
>> Look at the spec, Table 9-2 on page 86. (100 in PDF)
>>
>> VID Use
>> 0 "no VLAN identifier is present in the frame"
>> 1 "The default PVID value used for classifying frames on ingress ..
>> The PVID value of a Port can be changed by manage
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 1
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 talk
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 noti
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
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
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 t
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 which
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) fie
---
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)
{
concept. At this point I'm very interested in
all kinds of feed-back and would like to determine whether you might be
interested in integrating something like this in an official OpenVPN release
at some point.
Cheers
Fabian
Fabian Knittel (9):
is_ipv4(): add packet length check for 802.1Q
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 1040b8
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 +
---
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
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
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 than
93 matches
Mail list logo
