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 will operate on 16 byte blocks, so no matter
the block chaining mode we’re going to have that multiple-of-16-bytes thing.
> Sep 12 08:01:59 phillip tun-udp-p2mp[52730]:
> freebsd-14-amd64/194.97.140.5:14894 tun packet too large on write
> (tried=1504,max=1500)
>
> this is the "I have received a packet from the network, decrypted it, and
> tried to send it onwards towards the tun interface, and it was too large".
>
> So my guess is that "something" gets confused on the sending side DCO, and
> corrupts the payload size (-> so '-s 1461' becomes '-s 1476' = 16 byte
> increase instead of +1, resulting in 'ip packet size 1504' on the receiving
> end). The t_client server is running a slightly older master, which
> enforces the "mtu is 1500, so no bigger packets", newer openvpn are
> are somewhat more permissive on incoming baby giants.
>
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.
> 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.
>
Thanks!
I’m on my way to Vienna for EuroBSDCon now, so I will be distracted until early
next week, but when I’m back I should be able to dig into this as well.
Best regards,
Kristof
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
