Opened 13 months ago

Last modified 12 months ago

#911 accepted Bug / Defect

interface mtu calculation in 2.4 significantly different from 2.3

Reported by: Gert Döring Owned by: Steffan Karger
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.4.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Steffan Karger


debian bug report:

with --link-mtu 1400, 2.3 sets ip ... mtu 1344 while 2.4 sets ip ... mtu 1278 (which is too small for IPv6).

I can see a few bytes being lost to account for worst-case crypto overhead before negotiation, but 80 extra bytes? This needs a closer look...

Attachments (2)

0001-Add-tls_cipher_list_for_each-helper-function.patch (2.4 KB) - added by Steffan Karger 12 months ago.
0002-Calculate-max-crypto-overhead-more-accurately.patch (9.3 KB) - added by Steffan Karger 12 months ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 13 months ago by Antonio

733 size_t
734 crypto_max_overhead(void)
735 {
736 return packet_id_size(true) + OPENVPN_MAX_IV_LENGTH
739 }

this is huge and was introduced with 2.4 (I guess due to ncp).

packet_id_size(true): 8

TOT: 120Bytes.

This function then affects the extra_frame member of the frame object that is used to defer the tun_mtu from the link_mtu.

This is a really pessimistic approach as it uses all the MAX values.

First of all: --auth is not negotiable (right?), so can't we use the size of the signature produced by the configured algorithm?

Second: could we use the maximum values of the configured ciphers (--cipher + --ncp-ciphers) ?

comment:2 Changed 12 months ago by Steffan Karger

Owner: set to Steffan Karger
Status: newaccepted

Yeah, those bounds can be tighter. Though the difference between 2.3 and 2.4 is not 80, but 66 bytes.

I've looked into this while implementing NCP, but even though it sounds simple I found it tricky to implement in the current codebase. I'll see if I can come up with a (somewhat clean) way to fix this.

But if someone else wants to have a go at it, please do!

comment:3 Changed 12 months ago by Steffan Karger

The attached two commits introduce a more accurate worst case crypto overhead calculation, but introduce quite a bit of (tricky) code to do so. I'm not sure it's worth it...

Note: See TracTickets for help on using tickets.