Hi, On Tue, Jun 30, 2015 at 07:50:16AM +0200, Arne Schwabe wrote: > > Note that this patch does *not* yield an optimal solution, but it is a > > simple and rather safe change that will improve connection setup times > > significantly. > > I have no experience with the code and what happens on a small MTU > connection. Are there still very strange small MTU connections (like 56k > dialup modems) around?
A 56k dialup doesn't *need* to have a strange small MTU - at least not
unless someone followed the "speed optimization tricks" common at that
time and messed up their windows 3.1 TCP/IP settings... :-)
But anyway. If somone's line has a MTU below 1300 bytes, the control
packets will end up being fragmented - which is not necessarily a killer,
but in combination with NAT routers might indeed be a problem.
Now, *if* someone has such a line, and non-working fragmentation, their
data packets will also run into this. So I wonder if we can (ab-)use
one of the existing mtu-capping command line arguments, like --link-mtu,
to set a configurable upper bound for control packets as well (and default
to 1250 otherwise).
The option is there, the manpage description of the option "fits", we
just need to make it visible inside ssl.c... :-) - Steffan?
> On the other hand the OpenVPN 3.0 also uses 1200ish packet.
Indeed... but then, in a household with 56k Internet, you just do not
want to use any modern iOS or Android gear anyway... ("upgrade Angry
Birds?" - "yes!" - "ok, ready in 36 hours!")
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]
fax: +49-89-35655025 [email protected]
pgppS6XVDkQHY.pgp
Description: PGP signature
