tlshd: Fix the error in kernel capability probe

[Dwyane-Yan]

As the issue described in https://github.com/oracle/ktls-utils/issues/137

The kernel capability probing introduced in commit 3dd6a9414da ("tlshd: Add extensible kernel capability detection") fails when probing for the second optional netlink attribute
(HANDSHAKE_A_DONE_REMOTE_AUTH). The genl_ctrl_resolve() call returns -12, causing the feature to be incorrectly reported as "not available" even on supporting kernels.

After sending each probe message, explicitly drain the kernel's response by calling nl_recvmsgs_default().

Reported-by: Geliang Tang geliang@kernel.org

[chucklever]

The fix correctly addresses the root cause. When tlshd_probe_attr() sends a probe message, the kernel queues a response. Without draining that response via nl_recvmsgs_default(), the next call to genl_ctrl_resolve() (during the second probe) encounters stale data in the socket buffer, causing the -12 (ENOMEM) error.

This pattern is consistent with existing code in the same file - tlshd_genl_get_handshake_parms() uses the same nl_send_auto() followed by nl_recvmsgs_default() sequence (lines 514-521).

One optional suggestion: a brief comment could help future maintainers understand why the drain is necessary, e.g.:

supported = (err >= 0);
/* Drain kernel response to prevent stale data on socket reuse */
nl_recvmsgs_default(nls);

However, the existing comment block above this code already explains the probing logic, so this is not a blocking concern.

Tested-by would be valuable if available.

[Dwyane-Yan]

Hi @chucklever, thanks for your review.

I've applied your suggestions in the latest commit. Geliang and I have tested this commit in two ways:

• The scripts from issue#137 work well with this patch.
• We primarily focused on KTLS support for MPTCP, and this patch has been tested in mptcp-upstream-virtme-docker (our CI environment).