On 12 Sep 2022, at 14:45, Gert Doering wrote:
> Hi,
>
> On Mon, Sep 12, 2022 at 02:09:52PM +0200, Gert Doering wrote:
>> So, observation suggests "it's happening inside the DCO module". I'll
>> go instrument my kernel with printf()'s now... and will report if I find
>> anything useful.
>
> ok...
Hi,
On Mon, Sep 12, 2022 at 03:06:47PM +0200, Kristof Provost via Openvpn-devel
wrote:
> Can you reproduce the panic?
Yes, very easy.
Start a handful of OpenVPN instances, some with DCO
gert@fbsd14:~/t_server.git $ SU /root/t_server/start
starting tun-tcp-p2mp/server.conf...
starting
On 12 Sep 2022, at 14:36, Gert Doering wrote:
> On Mon, Sep 12, 2022 at 02:27:57PM +0200, Gert Doering wrote:
>> trying to load my newly-instrumented if_ovpn.ko, I kldunload'ed the
>> existing one - without shutting down *all* OpenVPN instances first.
>>
>> *Boom*...
>>
>> Console attached.
>
>
Hi,
On Mon, Sep 12, 2022 at 02:43:09PM +0200, Kristof Provost via Openvpn-devel
wrote:
> > it *does* bump the outside packet length up by +16 bytes ("bad length 1512"
> > ->
> > "1528"). Smells cipher algorithm padding or so - but why 16? And why pad
> > at all (AES-256-GCM used, so I think
Hi,
On Mon, Sep 12, 2022 at 02:43:09PM +0200, Kristof Provost via Openvpn-devel
wrote:
> That???s very interesting information. You may be closing in on the cause.
> What version do you run on the t_client server? Perhaps that will help me to
> reproduce it.
OpenVPN 2.6_git
Hi,
On Mon, Sep 12, 2022 at 02:09:52PM +0200, Gert Doering wrote:
> So, observation suggests "it's happening inside the DCO module". I'll
> go instrument my kernel with printf()'s now... and will report if I find
> anything useful.
ok... so at the beginning of ovpn_transmit_to_peer(), I have
On 12 Sep 2022, at 14:09, Gert Doering wrote:
> it *does* bump the outside packet length up by +16 bytes ("bad length 1512" ->
> "1528"). Smells cipher algorithm padding or so - but why 16? And why pad
> at all (AES-256-GCM used, so I think we should not pad)?
>
I would still expect padding. AES
Hi,
On Mon, Sep 12, 2022 at 02:27:57PM +0200, Gert Doering wrote:
> trying to load my newly-instrumented if_ovpn.ko, I kldunload'ed the
> existing one - without shutting down *all* OpenVPN instances first.
>
> *Boom*...
>
> Console attached.
Ah, nice, dmesg has all the info in text format, no
Hi,
(copying back the list)
On Mon, Aug 15, 2022 at 03:42:38PM +0200, Kristof Provost wrote:
> Thanks. That works, and I also see the failure with fragmented packets.
> I still have no idea why though. Things look correct on the sending
> side.
>
> I did spend a little time finding the exact
This builds wolfSSL as part of the github actions with gcc and clang+asan
and will allow us to see how well wolfSSL is maintaining the support in
OpenVPN.
Signed-off-by: Arne Schwabe
---
.github/workflows/build.yaml | 69
1 file changed, 69 insertions(+)
Acked-by: Gert Doering
Thanks. Tested on FreeBSD with and without DCO (the latter is more
for good measure, as the changes only influence the FreeBSD-iroute part).
Your patch has been applied to the master branch.
commit b5b132c1ba36e6d2ca261d15a9d70648890021f7
Author: Kristof Provost
Date:
Arne,
the type casting warning was fixed in
https://github.com/wolfSSL/wolfssl/pull/5571. OpenVPN should now compile
without any warnings.
Juliusz
On 02/09/2022 11:50, Juliusz Sosinowicz wrote:
I'll try to propose a solution to avoid this warning.
Juliusz
On 01/09/2022 14:39, Arne
Hi,
are there still Dragonfly BSD users around?
We have code to support that OS, but I suspect that it might have
rotted a bit - so it should get proper testing before 2.6.0 release...
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into
From: Lev Stipakov
On startup, check following conditions:
- ovpn-dco-win driver is installed. Perform this check
by trying to open adapter by symbolic name.
- options are compatible with dco. Same checks as on
Linux and FreeBSD. In addition, check that --mode server
is not used and
During the research for commit a5cf4cfb77f745 it turned out that
OpenVPN's behaviour regarding "--dev arbitrary-name" is very
platform-specific and not very well documented.
The referenced commit fixed DCO behaviour to be in line with non-DCO
linux behaviour, this commit catches up on the
Acked-by: Gert Doering
Thanks.
I've taken the liberty to improve language a bit, as suggested by Richard
on IRC.
Your patch has been applied to the master branch.
commit 7b42a0ebc968d178faa1083dd42a0c170d4dfe74
Author: Arne Schwabe
Date: Sun Sep 11 16:48:34 2022 +0200
Update
Acked-by: Gert Doering
Looks reasonable, and my github instance was able to successfully build
those mingw builds
Your patch has been applied to the master branch.
commit 4c1419266e177b423c18fa3dead78e2ac7c4b51c
Author: Arne Schwabe
Date: Fri Aug 26 17:30:26 2022 +0200
Add OpenSSL 3.0
17 matches
Mail list logo
