[PATCH V2 11/11] library: Add setup_tun() callback

David Woodhouse dwmw2 at infradead.org
Tue Mar 8 02:22:09 PST 2016

On Wed, 2016-02-10 at 20:00 -0800, Kevin Cernekee wrote:
> 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);

Hm. I think I looked at this to check it would be OK on CSTP reconnect,
and it was. But you're right, the MTU detection code has introduced the
problem you describe — at least theoretically.

In *practice*, however, I think the MTU can only ever go down and not
up. Each time we trigger MTU detection, don't we use ->ip_info.mtu as
the *maximum* for our probe?

Perhaps we need to keep 'negotiated MTU' vs. 'detected MTU' separate.
With the former being a "maximum MTU', despite the apparent redundancy
in that acronym.

Then the cstp_pkt could be sized for the 'negotiated MTU', as would
deflate_pkt_size. And the *actual* MTU at any moment would be stored
separately in a more ephemeral variable.

Out of interest, how does this work on the server side anyway? We can
reduce the size of the packets that *we* send, but how do we tell the
*server* to send smaller packets? Without breaking the CSTP connection
and reconnecting, at least?

David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

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

More information about the openconnect-devel mailing list