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>