On Tue, 2017-08-15 at 14:17 -0700, Daniel Lenski wrote: > Aha, thanks, I'll look at dtls_get_data_mtu() and try to get this exactly > right.
Thanks. I am being distracted by real work — can I leave you to continue my initial pass over the code? Really I was just looking at each function one at a time with fresh eyes and no context, and concentrating on the details. Including spaces — I'm sure there are better tools but when changing the way a variable 'foo' is handled, or just looking for where it's set, I often do just do a trivial search for 'foo = '. And if you ever assign to foo without the spaces, that will directly lead to bugs ;) > One frustrating thing about GP is that I literally have *no clue* what > the MTU "inside" the VPN looks like. > > At least one user has reported > (https://github.com/dlenski/openconnect/issues/43) that the VPN is > much faster when using --mtu with a value that's several times higher > than the apparent "wire MTU." Which means that fragmenting and > reassembling packets between the local host and the VPN gateway is > significantly more efficient than passing the smaller packets through. Hm, interesting. I wonder if that can be accurately described as "using --mtu with a value that is a precise multiple of the apparent wire MTU". That is, if we over-estimate the MTU by just a byte so that every packet we send turns into a sanely-sized packet followed by a tiny one- byte packet, that does pessimise the overhead.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/openconnect-devel
