Description
When enabling kTLS on a socket (which mostly involves setting up the SOL_TLS sockopt), that socket may receive some control messages like so:
2023-06-29T11:56:33.154070Z TRACE ktls::ktls_stream: received UnknownCmsg(
cmsghdr {
cmsg_len: 17,
cmsg_level: 282,
cmsg_type: 2,
},
[
23,
],
)
The cmsg_level corresponds to libc::SOL_TLS, cmsg_type corresponds to TLS_GET_RECORD_TYPE
I believe the additional data in the Vec<u8> corresponds to TLS message types: 22 is handshake, 23 is application data, see RFC 5246.
This happens because, after the TLS 1.3 handshake, tickets can be sent by the server to the client (for resumption, see rustls 0.21's flag for that).
If you're doing userland TLS, your deframer handles those messages gracefully and either throws away or stores the tickets for further use. But with kTLS, they have to go somewhere, and.. if you've received a ticket and you do a read() on the socket, you get errno 5 (helpful, I know!). If you do a recvmsg() you get one of these with the "bonus data" set to 22, which again, is the TLS 1.2/1.3 "handshake" type.
I'm working on a PR that recognizes those message types, adding a variant to ControlMessageOwned. The diff is probably a handful of lines and y'all don't need to bother yourselves with those details anyway but since there's fuck-all documentation about kTLS offline I needed to put it down somewhere.