[PATCH 3/3] Drop packets that are too large without dropping connection

[David Woodhouse]

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>