On Wed, 2016-05-04 at 11:05 -0700, Rick Jones wrote:
> Assuming Peter's assertion about just drops when syncookies are not
> enabled is accurate, should there be some one-time message in that case too?
We have plenty of drop points in the kernel without a message in syslog,
but proper SNMP
On 05/04/2016 10:34 AM, Eric Dumazet wrote:
On Wed, 2016-05-04 at 10:24 -0700, Rick Jones wrote:
Dropping the connection attempt makes sense, but is entering/claiming
synflood really indicated in the case of a zero-length accept queue?
This is a one time message.
This is how people can
On Wed, 2016-05-04 at 10:24 -0700, Rick Jones wrote:
> Dropping the connection attempt makes sense, but is entering/claiming
> synflood really indicated in the case of a zero-length accept queue?
This is a one time message.
This is how people can learn about their user space bugs, or too small
On 05/03/2016 05:25 PM, Eric Dumazet wrote:
On Tue, 2016-05-03 at 23:54 +0200, Peter Wu wrote:
When applications use listen() with a backlog of 0, the kernel would
set the maximum connection request queue to zero. This causes false
reports of SYN flooding (if tcp_syncookies is enabled) or
On Tue, May 03, 2016 at 05:25:44PM -0700, Eric Dumazet wrote:
> On Tue, 2016-05-03 at 23:54 +0200, Peter Wu wrote:
> > When applications use listen() with a backlog of 0, the kernel would
> > set the maximum connection request queue to zero. This causes false
> > reports of SYN flooding (if
On Tue, 2016-05-03 at 23:54 +0200, Peter Wu wrote:
> When applications use listen() with a backlog of 0, the kernel would
> set the maximum connection request queue to zero. This causes false
> reports of SYN flooding (if tcp_syncookies is enabled) or packet drops
> otherwise.
>
> Prior kernels
When applications use listen() with a backlog of 0, the kernel would
set the maximum connection request queue to zero. This causes false
reports of SYN flooding (if tcp_syncookies is enabled) or packet drops
otherwise.
Prior kernels enforce a minimum size of 8, so do that now as well.
Fixes:
