tlshd: probe the attributes with correct attribute length

[alesax]

During probing of attributes, kernel can validate attribute length, which triggers warning:

netlink: 'tlshd': attribute type 3 has an invalid length.

Probing should send appropriate attribute length. This is a minimal way to do it, certainly not perfect.

Closes: #140

[chucklever]

The diagnosis is correct — nla_put_string() sends a NUL-terminated string for HANDSHAKE_A_DONE_REMOTE_AUTH, but the kernel policy expects an s32 (4 bytes), so the attribute length validation fails before the probe can determine whether the attribute is supported.

A couple of concerns with the fix as proposed:

1. attr_len=1 for HANDSHAKE_A_DONE_TAG is suspect. This attribute is a string — nla_put_string() is used at line 814 when actually sending it. A 1-byte raw payload via nla_put() has no NUL terminator, so a kernel with NLA_NUL_STRING policy may reject it for a different reason. The original nla_put_string() call was already correct for this attribute.

2. Raw length parameter pushes type knowledge to the caller. Each call site must know the wire size of the attribute, which is fragile if more probed attributes are added later.

A cleaner approach would be to dispatch on the attribute's actual type rather than adding a generic length parameter. For example, the probe function could use nla_put_s32(msg, attr_type, 0) for integer attributes and keep nla_put_string(msg, attr_type, "__probe__") for string attributes. This could be a switch on attr_type inside tlshd_probe_attr(), or two separate helper calls in tlshd_detect_kernel_caps().

[alesax]

Thank you for the elaborate review, you're right, this seems like the most effective way - I've now pushed the updated code.

[chucklever]

Thanks for the update — the switch-on-attr_type approach looks right.

One thing to tighten up: the default case logs an error but then falls through to nl_send_auto(), which sends a message with no probe attribute attached. That produces a silent false result at best, or a confusing kernel response at worst. The existing switch (cmd) block at line 251 handles its default by freeing the message and returning false — the same pattern would be appropriate here:

	default:
		tlshd_log_error("Attribute %d not supported", attr_type);
		nlmsg_free(msg);
		return false;

With that fix, this looks good to me.

[alesax]

I see, pushed. Thank you for the guidance.