[Openvpn-devel,2/2] Permit unlimited connection entries and remotes
Commit Message
From: Selva Nair <selva.nair@gmail.com>
Currently we allow a max of 64 connection entries and remotes.
A larger number would allow users with 100's of independent
config files for different end points of same provider to
consolidate them to connection entries.
Signed-off-by: Selva Nair <selva.nair@gmail.com>
---
Changes.rst | 2 ++
src/openvpn/options.c | 34 ++++++++++++++++++++++++++++------
src/openvpn/options.h | 6 ++++--
3 files changed, 34 insertions(+), 8 deletions(-)
Comments
Hi,
On Wed, Aug 25, 2021 at 12:01:22AM -0400, selva.nair@gmail.com wrote:
> From: Selva Nair <selva.nair@gmail.com>
>
> Currently we allow a max of 64 connection entries and remotes.
> A larger number would allow users with 100's of independent
> config files for different end points of same provider to
> consolidate them to connection entries.
>
> Signed-off-by: Selva Nair <selva.nair@gmail.com>
The combination of this with the previous patch sounds quite useful
(= no longer distribute multiple different .ovpn for tcp/udp/... but
have them all in the same file).
I assume support in the UI is also already brewing :-)
There is one catch: I assume that this conflicts heavily with the
SRV patch (due to that one also changing connection entry handling),
and the SRV patch is overdue for final review and merging - thus, when
coming back to *this* patch, it might need a rebase.
gert
Hi,
On Wed, Aug 25, 2021 at 8:37 AM Gert Doering <gert@greenie.muc.de> wrote:
> Hi,
>
> On Wed, Aug 25, 2021 at 12:01:22AM -0400, selva.nair@gmail.com wrote:
> > From: Selva Nair <selva.nair@gmail.com>
> >
> > Currently we allow a max of 64 connection entries and remotes.
> > A larger number would allow users with 100's of independent
> > config files for different end points of same provider to
> > consolidate them to connection entries.
> >
> > Signed-off-by: Selva Nair <selva.nair@gmail.com>
>
> The combination of this with the previous patch sounds quite useful
> (= no longer distribute multiple different .ovpn for tcp/udp/... but
> have them all in the same file).
>
> I assume support in the UI is also already brewing :-)
>
Yes, that's the plan..
> There is one catch: I assume that this conflicts heavily with the
> SRV patch (due to that one also changing connection entry handling),
> and the SRV patch is overdue for final review and merging - thus, when
> coming back to *this* patch, it might need a rebase.
I think, either way it would be a simple rebase. This one against the SRV
patch or the other way.
Any idea why "options_preprocess_verify_ce()", which is called for each
connection-entry, contains many checks that apply to common,
non-ce-specific options? This causes some warnings like "using management
without password is strongly discouraged.." printed once for every
connection entry -- 100 times if you have 100 entries.
Selva
<div dir="ltr"><div dir="ltr">Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 25, 2021 at 8:37 AM Gert Doering <<a href="mailto:gert@greenie.muc.de">gert@greenie.muc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Wed, Aug 25, 2021 at 12:01:22AM -0400, <a href="mailto:selva.nair@gmail.com" target="_blank">selva.nair@gmail.com</a> wrote:<br>
> From: Selva Nair <<a href="mailto:selva.nair@gmail.com" target="_blank">selva.nair@gmail.com</a>><br>
> <br>
> Currently we allow a max of 64 connection entries and remotes.<br>
> A larger number would allow users with 100's of independent<br>
> config files for different end points of same provider to<br>
> consolidate them to connection entries.<br>
> <br>
> Signed-off-by: Selva Nair <<a href="mailto:selva.nair@gmail.com" target="_blank">selva.nair@gmail.com</a>><br>
<br>
The combination of this with the previous patch sounds quite useful<br>
(= no longer distribute multiple different .ovpn for tcp/udp/... but<br>
have them all in the same file). <br>
<br>
I assume support in the UI is also already brewing :-)<br></blockquote><div><br></div><div>Yes, that's the plan..</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There is one catch: I assume that this conflicts heavily with the <br>
SRV patch (due to that one also changing connection entry handling),<br>
and the SRV patch is overdue for final review and merging - thus, when<br>
coming back to *this* patch, it might need a rebase.</blockquote><div> </div><div>I think, either way it would be a simple rebase. This one against the SRV patch or the other way.</div><div><br></div><div>Any idea why "options_preprocess_verify_ce()", which is called for each connection-entry, contains many checks that apply to common, non-ce-specific options? This causes some warnings like "using management without password is strongly discouraged.." printed once for every connection entry -- 100 times if you have 100 entries.</div><div><br></div><div>Selva</div></div></div>
@@ -4,6 +4,8 @@ Overview of changes in 2.6
New features
------------
+Support unlimited number of connection entries and remote entries
+
New management commands to enumerate and list remote entries
Use ``remote-entry-count`` and ``remote-entry-get index``
commands from the management interface to get the number of
@@ -889,6 +889,14 @@ init_options(struct options *o, const bool init_gc)
void
uninit_options(struct options *o)
{
+ if (o->connection_list) {
+ free(o->connection_list->array);
+ CLEAR(*o->connection_list);
+ }
+ if (o->remote_list) {
+ free(o->remote_list->array);
+ CLEAR(*o->remote_list);
+ }
if (o->gc_owned)
{
gc_free(&o->gc);
@@ -1947,10 +1955,17 @@ alloc_connection_entry(struct options *options, const int msglevel)
struct connection_list *l = alloc_connection_list_if_undef(options);
struct connection_entry *e;
- if (l->len >= CONNECTION_LIST_SIZE)
+ if (l->len == l->capacity)
{
- msg(msglevel, "Maximum number of 'connection' options (%d) exceeded", CONNECTION_LIST_SIZE);
- return NULL;
+ int capacity = l->capacity + CONNECTION_LIST_SIZE;
+ struct connection_entry **ce = realloc(l->array, capacity*sizeof(struct connection_entry *));
+ if (ce == NULL)
+ {
+ msg(msglevel, "Unable to process more connection options: out of memory. Number of entries = %d", l->len);
+ return NULL;
+ }
+ l->array = ce;
+ l->capacity = capacity;
}
ALLOC_OBJ_GC(e, struct connection_entry, &options->gc);
l->array[l->len++] = e;
@@ -1973,10 +1988,17 @@ alloc_remote_entry(struct options *options, const int msglevel)
struct remote_list *l = alloc_remote_list_if_undef(options);
struct remote_entry *e;
- if (l->len >= CONNECTION_LIST_SIZE)
+ if (l->len == l->capacity)
{
- msg(msglevel, "Maximum number of 'remote' options (%d) exceeded", CONNECTION_LIST_SIZE);
- return NULL;
+ int capacity = l->capacity + CONNECTION_LIST_SIZE;
+ struct remote_entry **re = realloc(l->array, capacity*sizeof(struct remote_entry *));
+ if (re == NULL)
+ {
+ msg(msglevel, "Unable to process more remote options: out of memory. Number of entries = %d", l->len);
+ return NULL;
+ }
+ l->array = re;
+ l->capacity = capacity;
}
ALLOC_OBJ_GC(e, struct remote_entry, &options->gc);
l->array[l->len++] = e;
@@ -168,15 +168,17 @@ struct remote_entry
struct connection_list
{
+ int capacity;
int len;
int current;
- struct connection_entry *array[CONNECTION_LIST_SIZE];
+ struct connection_entry **array;
};
struct remote_list
{
+ int capacity;
int len;
- struct remote_entry *array[CONNECTION_LIST_SIZE];
+ struct remote_entry **array;
};
enum vlan_acceptable_frames