Time for a 6.00 release?

[David Woodhouse]

On Tue, 2014-06-24 at 08:04 -0700, Kevin Cernekee wrote:
> On Tue, Jun 24, 2014 at 2:53 AM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
> >> Hm, joy. So that's a third way of negotiating the MTU, and this time
> >> possibly even after the interface has been set up?
> >
> > That's a quite reasonable approach as one's idea of the MTU during
> > negotiation may not be precise. I don't think it's an issue to change
> > the MTU of the tun device at any point (at least if you know the name
> > of the tun device and SIOCSIFMTU is available).
> 
> That does require CAP_NET_ADMIN; Android will have a problem with
> this.  The app only has the ability to perform a one-time interface
> setup through a special API[1]; it doesn't run with root access.

That's true when we're running from NetworkManager too. OpenConnect is
spawned as an unprivileged user and given a pre-created tun device to
use, and its vpnc-script is just a simple tool that spews all the
information back to NetworkManager over DBus.

We could potentially come up with a way to allow MTU changes on the fly
when used with NetworkManager, but it's non-trivial.

> I have an outstanding problem report from a user who sees an MTU of
> 1406 on OpenConnect but 1405 on AnyConnect.  When his phone is
> connected to wifi, 1405 is the highest value that works; but 1406
> works on 3G.  Not really sure how to probe for this value if the
> device can freely switch to a different interface/network with a
> different path MTU.  Maybe in this case it was just luck.

Well, if the path MTU is limited by the local device then we might have
a chance of getting it right at the time we make the connection. Our
calculate_mtu() in cstp.c does make some attempt to adapt using that.
It'll even use the path MTU if we know it... which we might not.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140624/0032c513/attachment-0001.bin>