questions on MTU

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

 



Hello,
 I have some issues with MTU on a particular link and I am trying to
figure out MTU handling in openconnect. It seems openconnect sends to
the server the MTU value of the link (as seen from calculate_mtu()) and
then it sets as vpninfo->actual_mtu the value that was received by the
server.

Is that supposed to be the link MTU, or the MTU excluding any TLS or
DTLS headers? As it is handled now it is used as the latter, but that is
inconsistent with the initial value sent by the client on the same header.

Nevertheless, in both cases the handling of MTU using
gnutls_dtls_set_data_mtu() seems wrong.

1. If vpninfo->actual_mtu contains the link MTU, then the current
behavior is to add to the link MTU the DTLS headers, MAC etc., thus
packet sizes will exceed the actual MTU.

I think that gnutls_dtls_set_mtu() should be called with the MTU value
and then the real data MTU for this connection can be seen using
gnutls_dtls_get_mtu().

2. If vpninfo->actual_mtu contains the MTU after all headers, then the
current behavior again exceeds it by setting it as actual_mtu+1. The
correct should have been to set it as actual_mtu.

Am I missing something from these interpretations?

btw. Some DTLS overhead values for different ciphersuites and 1500
initial mtu:
AES-xxx-CBC-SHA1: 65 bytes
AES-xxx-GCM: 33 bytes (that one is available from DTLS 1.2 and later)

I am also experimenting with SALSA20 with UMAC [0] which gives an
overhead of 25 bytes and other performance benefits.

regards,
Nikos

[0]. http://nmav.gnutls.org/2013/05/salsa20-and-umac-in-tls.html



[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