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... so at the beginning of ovpn_transmit_to_peer(), I have
>
> ping -s 1460
> Sep 12 14:36:34 fbsd14 kernel: GERT: ovpn_transmit_to_peer, tunnel_len=1488
>
> ping -s 1461
> Sep 12 14:36:43 fbsd14 kernel: GERT: ovpn_transmit_to_peer, tunnel_len=1489
>
> -> check!
>
> ... and then there is code that deals with rounding up...?!
>
> --------------- snip --------------
> printf( "GERT: ovpn_transmit_to_peer, real_len=%d\n", (int) real_len );
>
> ovpn_hdr_len = sizeof(struct ovpn_wire_header);
> if (key->encrypt->cipher == OVPN_CIPHER_ALG_NONE)
> ovpn_hdr_len -= 16; /* No auth tag. */
> else {
> /* Round up the len to a multiple of our block size. */
> len = roundup2(real_len, AES_BLOCK_LEN);
>
> /* Now extend the mbuf. */
> m_append(m, len - real_len, EMPTY_BUFFER);
> }
>
> printf( "GERT: ovpn_transmit_to_peer, len=%d\n", (int) len );
> --------------- snip --------------
>
> and after this block:
>
> Sep 12 14:40:40 fbsd14 kernel: GERT: ovpn_transmit_to_peer, tunnel_len=1489
> Sep 12 14:40:40 fbsd14 kernel: GERT: ovpn_transmit_to_peer, real_len=1489
> Sep 12 14:40:40 fbsd14 kernel: GERT: ovpn_transmit_to_peer, len=1504
>
> Wohoo, 1504! +16!
>
>
> Now, I have no idea about crypto, *and* I have no idea about OpenVPN
> wire format (Arne is the resident expert on this), but Arne tells me
> "there is no padding needed"
>
> 14:00 <@cron2__> is there padding with AES-GCM?
> 14:04 <@plaisthos> cron2__: no. AES-GCM is basically CTR and a stream cipher
>
> ... so, not sure what that code does.
>
> If I just kill it :-)
>
> /* Round up the len to a multiple of our block size. */
> // len = roundup2(real_len, AES_BLOCK_LEN);
>
> I can ping just fine...
>
> gert@fbsd14:/usr/obj $ SU ping -s 1461 10.194.0.1
> PING 10.194.0.1 (10.194.0.1): 1461 data bytes
> 1469 bytes from 10.194.0.1: icmp_seq=0 ttl=64 time=124.774 ms
> 1469 bytes from 10.194.0.1: icmp_seq=1 ttl=64 time=124.930 ms
>
> and with double fragmentation too...
>
> gert@fbsd14:/usr/obj $ SU ping -s 3000 10.194.0.1
> PING 10.194.0.1 (10.194.0.1): 3000 data bytes
> 3008 bytes from 10.194.0.1: icmp_seq=0 ttl=64 time=126.363 ms
> 3008 bytes from 10.194.0.1: icmp_seq=1 ttl=64 time=126.642 ms
> 3008 bytes from 10.194.0.1: icmp_seq=2 ttl=64 time=126.200 ms
>
>
> Now, I'm not submitting a patch for that, because usually there is
> a good reason for rounding up and doing blocks and all that - so, I
> found the offending lines, but do not feel qualified for a correct
> fix.
>
The offending code is almost certainly wrong.
I know the guy who wrote them and … he means well ;)
I think I was confused about what was needed in packet size. I’ll try to test
your patch in the next couple of days.
Kristof
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
