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
