https://bugs.openldap.org/show_bug.cgi?id=10549
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- On Mon, Jul 27, 2026 at 09:21:46AM +0000, openldap-its@openldap.org wrote:
I think it's not a violation of the PROXY protocol happen here (e.g. fragmented header). The PROXY protocol header is received in one chunk right after the 3-wy handshake, but "too late" - the buffer is read slightly before.
From PROXY Protocol specs:
The receiver may apply a short timeout and decide to abort the connection if the protocol header is not seen within a few seconds (at least 3 seconds to cover a TCP retransmit).An example out of a tcpdump with relative timings: 11.201180 C->S SYN 11.201208 S->C SYN,ACK 11.201424 C->S ACK <- bare ACK completes handshake, carries NO data 11.201524 S->C FIN <- lloadd closes 100us later, before any data arrives 11.201546 C->S 28 bytes <- PROXY v2 PROXY/TCPv4 header arrives -- too late 11.201581 S->C RST 11.201618 C->S 31 bytes <- LDAP StartTLS ExtendedRequest (1.3.6.1.4.1.1466.20037) 11.201626 S->C RST
Right, on Linux, using TCP_DEFER_ACCEPT for PROXY sockets looks tempting, except there is no universally available equivalent for *BSDs.
We can't block the rest of the balancer's listener for seconds, so the only alternative seems to be splitting the accept/proxyp/setup phases into their own stages. Not ideal but might be necessary.
I would note that running a proxy in front of lloadd doesn't buy you much if anything, lloadd cannot and will not pass this information to its backends (we route requests on a per-operation basis, not per connection as all traditional proxies do). The support exists only because of reports that some clouds (Amazon?) force the use of PROXY protocol.
Regards,