On Wed, Feb 10, 2016 at 1:35 PM, Woodhouse, David <david.woodhouse at intel.com> wrote: > On Mon, 2016-02-08 at 22:34 -0800, Kevin Cernekee wrote: >> >> openconnect_obtain_cookie() >> openconnect_make_cstp_connection() >> openconnect_setup_dtls() >> openconnect_get_ip_info() >> # ask the OS to create the tun interface >> openconnect_setup_tun_fd() >> openconnect_mainloop() >> >> But now that MTU is calculated a few seconds after the mainloop starts >> up, it is necessary to provide a callback so that the calling application >> can create a tun interface with the correct MTU. > > What happens if apps *don't* update, and the library is just updated > (with no soname bump) without the application being changed. > > Does the dynamic MTU detection still happen, but achieve nothing and > basically leave things as they were in OpenConnect 7.05? Yes, that is the intention. One thing that worries me: it looks like ip_info.mtu could potentially change on each DTLS reconnection? That's probably the right thing to do if the device is roaming between wifi/mobile networks. But the tun interface MTU then needs to be updated every time openconnect computes a new MTU - we don't want to keep getting 1341-byte packets from the kernel if we just decided that the MTU should be lowered to 1300. Changing the tun interface MTU should be possible via set_tun_mtu() if we're running as root, but it isn't currently possible using the Android / Chrome OS / script-tun APIs. Maybe the library API should add an mtu_changed callback, and if it is NULL, only perform MTU detection when !tun_is_up. Also, I'm not sure if this code is safe if ip_info.mtu is low when cstp_pkt is allocated, but higher when the buffer gets populated: int len = vpninfo->deflate_pkt_size ? : vpninfo->ip_info.mtu; int payload_len; if (!vpninfo->cstp_pkt) { vpninfo->cstp_pkt = malloc(sizeof(struct pkt) + len); if (!vpninfo->cstp_pkt) { vpn_progress(vpninfo, PRG_ERR, _("Allocation failed\n")); break; } } len = ssl_nonblock_read(vpninfo, vpninfo->cstp_pkt->cstp.hdr, len + 8);