MTU mismatch with 7.08 and "Unknown DTLS packet"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux