A TCP connection made by sendto() with TCP_FASTOPEN set always sets the
TCP_FASTOPEN readback getsockopt. It would be (possibly more) useful to the
client application to know if a supposedly valid TFO cookie was sent on the SYN
(as opposed to the current possibilty of only having sent a TFO request) and/or
whether the server agreed that the cookie was acceptable.
TCP_INFO TCPOPT_FAST_OPEN appears to match getsockopt/TCP_FASTOPEN, for a client.
I'm not sure that we really want to go so far as knowing whether client
data-on-SYN was actually accepted with the SYN, but it's another item in the
Related, though possibly should be a separate bz:
API for a server application to arrange for Fast Open data to travel in
the SYN,ACK packet. I can see two possible implementations:
a) where the application pre-loads data before the SYN arrives
b) where the application supplies data between the SYN arriving and the
SYN,ACK being sent, permitting the data to depend on the initiating IP
Primary use-case is for SMTP, where the server banner is the first data sent
for the application-level protocol. I could see it being of use for TLS also,
where the Client Hello can travel on the SYN and the Server Hello on the
SYN,ACK (in fact, with kTLS this may not need a kernel/user API).