Hi,
On Tue, Oct 11, 2022 at 09:11:25PM +0200, Gert Doering wrote:
> OTOH, in "not peer2peer mode", we only support topology subnet anyway,
> so maybe it should autoconfigure that, depending on the mode OpenVPN
> requests (p2p mode -> IFF_POINTOPOINT, p2mp mode -> IFF_BROADCAST),
> so we don't even
Hi,
On Fri, Oct 07, 2022 at 11:56:52AM +0200, Gert Doering wrote:
> I'll dig into the POINTTOPOINT issue... configure a real MULTIPOINT
> interface for --topology subnet (which is something I've always avoided
> so far, because "we know the other stuff works")
This is... an interesting problem.
On Tue, Oct 11, 2022 at 03:07:04PM +0200, Heiko Hund wrote:
> On Montag, 27. Juni 2022 10:36:02 CEST Frank Lichtenheld wrote:
> > As mentioned this is true for the specific options configured above.
> > But you can easily also get different values out of this function by
> > changing the options be
On Montag, 27. Juni 2022 10:36:02 CEST Frank Lichtenheld wrote:
> As mentioned this is true for the specific options configured above.
> But you can easily also get different values out of this function by
> changing the options because frame_calculate_payload overhead does
> not always return the
On Tue, Oct 11, 2022 at 01:49:35PM +0200, Arne Schwabe wrote:
> From the implemention and the fact that it is a an OCC message
> (basically the rudimentary predecessor to control channel),
> this message is very old.
>
> I think in the past this feature fit nicely to the weird inetd + openvpn mode
Doesn't apply to master anymore, please rebase.
On Sonntag, 26. Juni 2022 01:41:47 CEST Arne Schwabe wrote:
> --- a/doc/man-sections/vpn-network-options.rst
> +++ b/doc/man-sections/vpn-network-options.rst
> @@ -516,6 +516,11 @@ routing.
>It's best to use the ``--fragment`` and/or ``--mssfix``
>From the implemention and the fact that it is a an OCC message
(basically the rudimentary predecessor to control channel),
this message is very old.
I think in the past this feature fit nicely to the weird inetd + openvpn mode
that seems to have far to many hacks still left in our code. With inet
>From the implemention and the fact that it is a an OCC message
(basically the rudimentary predecessor to control channel),
this message is very old.
I think in the past this feature fit nicely to the weird inetd + openvpn mode
that seems to have far to many hacks still left in our code. With inet
