On 05/10/16 22:51, David Woodhouse wrote: > On Wed, 2016-10-05 at 21:29 +0100, Matt Caswell wrote: >> Hmmmm....well its not constant even by cipher. It depends on the >> transport (IPv6 has a bigger overhead than IPv4). > > That is included in d1->link_mtu (DTLS_set_link_mtu()) but is not > included in d1->mtu (SSL_set_mtu()). > > Even when we let DTLS autodetect by using BIO_CTRL_DGRAM_QUERY_MTU, it > gets a value without the (assumed) IP/UDP overhead, which goes straight > into d1->mtu. > > The "link MTU" thing is purely a special case for application > convenience. AFAICT we only *ever* use it by subtracting the > BIO_CTRL_DGRAM_GET_MTU_OVERHEAD value (which again assumes UDP not > SCTP) and then dealing with d1->mtu thereafter.
That is not correct. It *is* defined for SCTP. It's just defined to be zero (because SCTP allows fragmentation so MTUs are kind of irrelevant anyway). > > So let's forget all about the "link MTU" and the IP/UDP overhead for > now. They are an orthogonal issue. > >> So why not: >> >> DTLS_get_data_mtu(SSL *s) > > Yeah. OK. And I don't think we need a DTLS_set_data_mtu(). If the > application knows the largest data payload it'll ever send... who cares > about telling OpenSSL the MTU? Just call SSL_set_mtu(s, 65536) and then > send what you like. Fair enough. Matt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev