MTU mismatch with 7.08 and "Unknown DTLS packet"

[Nikos Mavrogiannopoulos]

On Mon, Jan 8, 2018 at 5:51 AM, Chaskiel Grundman <cgrundman at gmail.com> wrote:
>> Could you be more specific which code path you are referring to? As
>>far as I see openconnect seems to call gnutls_dtls_set_mtu(), as well
>> as gnutls_dtls_set_data_mtu() on different code paths.
>
> in the non-PSK-NEGOTIATE case, openconnect calls
> gnutls_dtls_*s*et_data_mtu with the negotiated MTU (+1).
> gnutls_set_data_mtu uses the data mtu parameter to compute an internal
> mtu. It does this by adding values computed by record_overhead_rt and
> RECORD_HEADER_SIZE to the mtu parameter.
> The mtu parameter is passed unchanged to record_overhead_rt as est_data.

> gnutls_record_send calls gnutls_dtls_*g*et_data_mtu to find out the
> maximum amount of data that is allowed to be written to a single
> record.
> gnutls_dtls_*g*et_data_mtu reads the internal mtu
> (session->internals.dtls.mtu) and attempts to reverse the computation
> done by gnutls_dtls_*s*et_data_mtu. However, it does not pass the same
> parameters to record_overhead_rt (because it doesn't know the old
> est_data). If gnutls_dtls_*g*et_data_mtu's call to record_overhead_rt
> returns a larger value (due to padding).  gnutls_dtls_*g*et_data_mtu
> will incorrectly return a smaller value than was requested by
> gnutls_dtls_*s*et_data_mtu, resulting in the client having a lower
> effective mtu than the gateway.

Indeed. There seems to be an issue there. Could you open a bug at:
http://gitlab.com/gnutls/gnutls/issues to discuss it further?

regards,
Nikos