On Fri, Aug 2, 2019 at 3:03 PM Bernd <e...@zusammenkunft.net> wrote: > > Hello, > > While analyzing a aborted upload packet capture I came across a odd > trace where a sender was not responding to a duplicate SACK but > sending further segments until it stalled. > > Took me some time until I remembered this fix, and actually the > problems started since the security fix was applied. > > I see a high counter for TCPWqueueTooBig - and I don’t think that’s an > actual attack. > > Is there a probability for triggering the limit with connections with > big windows and large send buffers and dropped segments? If so what > would be the plan? It does not look like it is configurable. The trace > seem to have 100 (filled) inflight segments. > > Gruss > Bernd > -- > http://bernd.eckenfels.net
What's the exact kernel version you are using? Eric submitted a patch recently that may address your issue: tcp: be more careful in tcp_fragment() https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=b617158dc096709d8600c53b6052144d12b89fab Would you be able to test your workload with that commit cherry-picked, and see if the issue still occurs? That commit was targeted to many stable releases, so you may be able to pick up that fix from a stable branch. cheers, neal
