Comment 2 for bug 134274

Pending feed-back from the Linux netdev mailing list as to whether this can be considered a bug in the kernel's implementation of TCP_DEFER_ACCEPT on this basis:

An RFC standard TCP handshake requires three stages:

client SYN > server LISTENING
client < SYN ACK server SYN_RECEIVED
client ACK > server ESTABLISHED

client PSH ACK + data > server

TCP_DEFER_ACCEPT is designed to increase performance by reducing the number of TCP packets exchanged before the client can pass data.

client SYN > server LISTENING
client < SYN ACK server SYN_RECEIVED

client PSH ACK + data > server ESTABLISHED

At present with TCP_DEFER_ACCEPT the kernel treats the RFC handshake as invalid; dropping the ACK from the client without replying.

There is a case for arguing the kernel is operating in an enhanced handshaking mode when TCP_DEFER_ACCEPT is enabled, not an alternative mode, and therefore should accept *both* client responses (ACK, then PSH ACK + data, or PSH ACK + data). I've been unable to find a specification or RFC for implementing TCP_DEFER_ACCEPT aka BSD's SO_ACCEPTFILTER.

It seems incorrect to penalise a client that is trying to complete the handshake according to the RFC specification, especially as the client has no way of knowing ahead of time whether or not the server is operating deferred accept.

I'll update once the kernel net-devs have given their views.