[https://nuudel.digitalcourage.de/NROHeFlkfaYnoNGC](https://nuudel.digitalcourage.de/NROHeFlkfaYnoNGC)

It is also possible to book a room directly at the "Hotel Paradiso", so that you can

Take the Alibus shuttle to Piazza Garibaldi (~20–25 minutes, €5).

Then either:

Take Metro Line 2 to Mergellina and walk/bus to Via Catullo 11, OR

Take Bus 151 from Piazza Garibaldi to Bruno‑Sannazaro, then walk.

🕒 Around 50–60 minutes total | 💰 ~€6–€9

Option 2: Taxi

Travel time: 15–20 minutes.

Distance: ~12–13 km.

Cost: €35–€45 depending on time of day and luggage.

🗺️ Notes:

The nearest funicular station to Via Catullo 11 is Sant’Antonio, but it's usually not required unless coming from uphill areas like Vomero.

Local tickets (valid for metro/bus within Naples):

Single ride: around €1.20–€1.50.

| Name | Topics | Arrival | Departure | Hotel | T-shirt size |

| Antonio Quartulli | mesh-mode | 24 afternoon | 26 afternoon | Paradiso | M |

Saturday 25:

Sunday 26:

planned for beta4 last wed, but not happened. too many open things. planned for next week.

few features to merge: host-route thing by Arne, a few integer conversion fixes. we try to merge what's in gerrit right now. any new integer fix will be ignored for 2.7.

next week we will release rc1 (no beta4). No new features after that.

Full release 2-4 weeks after the last bug comes in.

we need to understand what features are supported by the running DCO.

There might be new features (not yet supported by userspace), or features that have been retired (i.e. for security reasons).

Logic for some features is split between kernel and userspace, so activating half-feature (i.e. in DCO only) would break somewhere else (i.e. float notifications).

Each platform needs its own implementation to figure out what features are supported by the kernel.

In dco.c we will need some high level API that returns a bitmap of features.

we have done some rudimental test, but we need something more reliable and reproducible.

Basic tests: compare userspace vs DCO in the same environment. 1core and 4 cores (to show that userspace doesn't scale with cores, while DCO does). Community will take care of this.

Enhanced tests: push DCO to the limits (expensive). Test major use cases (i.e. involve cloud and everyday applications). OpenVPN Inc. will most likely look into this, for their own marketing material.

we currently use WiX3, but it's EOL. We need to migrate, but the jump to WiX4 is large and needs time (after that, moving to WiX6 or 7 is exepcted to be less problematic).

Using modern WiX sems to be free for community projects (not for commercial ones).

Frank will create tickets in the openvpn-build repo, in order to move forward with this.

We will take changes in parallel with openvpn development (i.e. not waiting 2.8, but rather start offering both installers in some 2.7.x release).

Current drawbacks: it's an out-of-tree "project". Heiko (and most openvpn contributors) can't do C#.

It'd be nice to bring it back to our repo and write it in C. This way we can re-use code and maintain/review it better. However C# allows easier interaction with Windows API .

We can then implement both services in one executable.

Heiko will look into doing the conversion (#877).

now we have 4 backends, but we want to converge to using the interactive service and remove all code from openvpn core. Heiko (+Lev) will take care of looking into this (#878).

Later we can look into using the internal networking API for windows as well (in order to simplify route.c/tun.c)

Arne will put up on the wiki a document including some protocol change suggestions to start working with.

We envision different steps, from simplest to most complex:

* multipeer-to-multipeer: with static configuration and IP assignment (aka server-to-server)

* client-to-client: with clients connected to one server and the server pushing peer infos to clients so that they can connect directly to each other

* client-to-multi-server: with one client connected to multiple servers, both serving resources

interface self-destruction: userspace will keep the RTNL socket open after completing the NEW_LINK call. ovpn will listen to that socket and self-destroy the interface when the socket gets closed.

This requires chaging the RTNL kernel code a bit so that the socket is passed all the way down to ovpn. We will have to also add an IFLA_OVPN flag to allow enabling disabling this logic (default off for backwards compatibility and ip link usage)

we need to write down documentation about what to use when (assert vs ASSERT vs handling errors).

Frank will sum up the main guidelines about how to use assert in the codestyle wikipage.

It got figured out. Gert will add some guidelines on the wiki and check consistency.

Aiming at release in 18/24 months, without being too strict.

at the end of 2026 (12 months from now) we review the status and try to make an educated decision on the actual roadmap.

Features we'd like to see in 2.8:

* multipeer-to-multipeer

* win32/openvpnserv cleanup

* drop static keys

* drop ntlm support

* upgrade support for WiX3

* transport API

* more complete VRF support (low prio)

* peer session restoring (to support live upgrades)

* PUSH_UPDATE support with DCO enabled (client and server)

* DCO capability negotiation

* make --fast-io deprecated/obsolete

* drop Win7 support

* drop x86 support for Windows

* monitor network changes and adapt accordingly

* make data-channel in userspace an independent component, talking via the same DCO APIs

* support TLS record splitting

* disable congestion avoidance in control channel in TCP mode

* ip rule based --block-local for linux

Currently using the old LDAP (used for the old wiki). No good way to create/manage accounts.

We will integrate authentication with GitHub.

Yuriy will check if we can combine current users with the integration (some usernames do not match). If that works, we will move forward. New users will be put in the basic group (no buildbot permissions).

Frank will check if we can run uncrustify as a separate scheduler to be applied to new users too.

currently available only via community VPN, which not everybody has always access to.

Frank will investigate how to create a separate "read-only" master BB that can be internet facing and accessed by every users.

GitHub seems to have a way to report security issues, but it looks too special for reports that are not known for being security vulnerabilities or not yet.

A proposed solution consists in creating a private repo on GitHub where we can open issues that will stay privately until we move them (i.e. to public repo, if the report is not an actual vulnerability)

* openvpn2-go (light client for driving kernel module in P2P mode)

* submission only mailing list: we use the private GitHub repo for now