On Sat, 2017-05-13 at 18:56 -0400, Nikolay Martynov wrote: > Hi. > > > > > > > > > > > > If they're actually going to send larger packets then ? as long as we > > > make bloody sure we're not going to overflow our allocations ? I > > > suspect we're better off actually receiving them. If they made them > > > through, why drop? > > I agree. "Be liberal in what you accept and conservative in what you transmit." > > > > In order to do this, I think it'd be good to make the > > packet-size-allocation consistent across all supported protocols. > > Perhaps by allocating at least a certain amount of headroom above the > > negotiated/estimated MTU, say 1024 bytes? I can submit a patch if > > that's desirable. > FWIW I've resubmitted that patch yesterday with just what you are > describing here (but I've used 256 for the headroom size). I've tested > it against my use case and it seems to be working - so approach works. > You guy obviously can make better or pore appropriate change if you so > desire :). > > Thanks for looking into this! Thanks for the patches. This whole thing has made me a bit sad about the packet handling; I think I want to put an explicit 'allocated size' field into struct pkt so we don't ever have to make assumptions. This has caused problems for CSTP before.? Long plane ride ahead of me today; I'll make sure I'm set up to do this, and also finally merge Daniel's GP support, while I'm locked in a tin can... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4938 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170514/e3be8337/attachment.bin>
