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.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             g...@greenie.muc.de

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to