TCP._make_mptcp_capable writes length 20/32 where RFC 8684 gives 12/20, and now packs wrong bytes rather than crashing

[JarryShaw]

TCP._make_mptcp_capable writes an MP_CAPABLE length that is wrong in both branches. Found while fixing #541, which unmasked it; filed separately.

The arithmetic

pcapkit/protocols/transport/tcp.py:2669:

length=20 if rkey is None else 32,

RFC 8684 section 3.1 gives MP_CAPABLE as 12 octets without the receiver's key and 20 octets with it. So both branches are wrong, and confusingly the no-key branch writes 20 — which is the correct value for the other case.

Why it appears now

It was entirely masked. Before #541, MPTCP declared kind/length only under typing.TYPE_CHECKING, so the maker's length= was dropped with UnknownFieldWarning and packing died on KeyError: 'length' before the value could reach the wire. #541 declares them as real fields, so the length now lands — and lands wrong.

That makes this the more dangerous of the two defects #541 exposed: unlike #566, which raises, this one packs successfully with wrong bytes. A caller gets an MP_CAPABLE option whose length octet disagrees with its own payload and no exception to warn them.

Coverage

A test asserting the packed byte length of MP_CAPABLE for both the key-present and key-absent cases, against RFC 8684 section 3.1 rather than against current behaviour. Proven to fail without the fix, exit code read from a file.

Worth checking the sibling _make_mptcp_* helpers' length arithmetic in the same pass: #541 established that all eleven share a common history of never having had their lengths exercised, so this may not be the only one. The four packed-byte assertions #541 added for ADD_ADDR (1e08340101020304 at length 8, 1e0a34010102030401bb at 10, and the IPv6 forms at 20 and 22) are the pattern to follow.

[JarryShaw]

Scope correction: the maker's arithmetic is only half of it. MPTCPCapable.rkey's own predicate is independently wrong and directly contradicts the maker, so fixing the maker alone would leave the defect half-live.

Found during #565's cross-review, and verified against origin/main:

pcapkit/protocols/schema/transport/tcp.py:667-670

rkey: 'int' = ConditionalField(
    UInt64Field(),
    lambda pkt: pkt['length'] != 32,
)

So the receiver key is included when length != 32 — that is, dropped when length == 32. But _make_mptcp_capable writes length=20 if rkey is None else 32, meaning it signals rkey present with the single value that tells the schema to discard it. The two are exactly opposed.

Measured consequences, both on a tree where the kind/length fields are real (i.e. post-#541):

• length=32 with an rkey packs 12 octets, with the receiver key silently gone.
• length=12 — the RFC 8684 value for the no-key form — without an rkey packs 20 octets, carrying a phantom all-zero key.

So the schema cannot currently express a 12-octet MP_CAPABLE at all. That is a stronger statement than the original filing: it is not only that the maker writes wrong numbers, but that the field's own condition is keyed to a value the RFC never uses for that meaning.

Whatever fix lands must therefore change both the maker's arithmetic and the predicate, in one pass, and should assert the packed octet count for each of the two RFC-defined forms — 12 without the receiver key, 20 with it — rather than asserting against either component in isolation. Fixing one without the other swaps which of the two forms is broken rather than repairing either.