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 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,
(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
