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>