Your patch has been applied to the master branch.
I do not really have a test rig to test this, currently. I think it would
need a long-running client instance that connects to a server, receives
a set of options, disconnects (server kicking it out?), reconnects, and
receives *different* options. Or possibly "not receives options that
were set before", so verify "fall back to default/config file settings".
OTOH staring at the code looks reasonable - we only restore if something
was saved before (o->pre_pull initialized) and if we succeed connecting,
it's the same amount of energy spent.
I have run this through the enhanced client side tests (including the
"must fail!") tests, but since these all only do single-shot connections,
this is not really excercising the code change.
I do wonder if connection *failures* would cause an increased memory
consumption now... is "&c->c2.gc" cleared eventually? (Because we
allocate new copies of route-lists in that GC)... *looking*... ah, yes,
c2.gc lives only for "one instance" (init_instance() to close_instance()),
and since that one talks about "advance connection entry", it looks
like "this dance is done per connection attempt"...
commit 528a78fb144ff6a3d5865c871a402ba98fdfe21e
Author: Arne Schwabe
Date: Wed Mar 17 17:00:36 2021 +0100
Move restoring pre pull options to initialising of c2 context
Signed-off-by: Arne Schwabe <[email protected]>
Acked-by: Antonio Quartulli <[email protected]>
Message-Id: <[email protected]>
URL:
https://www.mail-archive.com/[email protected]/msg21676.html
Signed-off-by: Gert Doering <[email protected]>
--
kind regards,
Gert Doering
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
