Created attachment 217871 [details] accept.cpp testcase g++ -std=gnu++0x -Wall accept.cpp && ./a.out then while the program is running netcat -v localhost <port> Expected (behavior with 3.12, or backlog = 1): PASS localhost [127.0.0.1] <port> open Actual behavior with 4.4.11: Both programs remain blocking in accept and select (after connect), with no output from netcat. man 3p listen: "A backlog argument of 0 may allow the socket to accept connections, in which case the length of the listen queue may be set to an implementation- defined minimum value." That's not entirely clear, but I've noticed a couple of applications expecting to accept connections with backlog 0.
Created attachment 218301 [details] LD_PRELOAD workaround
"If listen() is called with a backlog argument value that is less than 0, the function behaves as if it had been called with a backlog argument value of 0." but passing backlog = -1 permits accepting connections while 0 does not.
If using a networked epson scanner, they supply a closed binary (/usr/lib64/iscan/network) which is called during detection of the scanner. That binary listens on a localhost socket with listen()s backlog argument set to 0. Something then tries to connect to that socket. Used to work, now fails as above. Also,this appears in the logs: TCP: request_sock_TCP: Possible SYN flooding on port XXXXX. Dropping request. Check SNMP counters. I am guessing because one SYN exceeds a backlog of 0. I just wanted to note that this not just a regression in theory, but it broke my real world application. (I was able to get it working using the LD_PRELOAD hack -- thanks.)