Repository navigation
tcp: MP_CAPABLE parses only 12 and 20 of RFC 8684's five lengths #1042
Description
TCP rejects three of the five MP_CAPABLE forms that RFC 8684 §3.1 defines. Measured on main:
| Length | Form (RFC 8684 §3.1) | Result |
|---|---|---|
| 4 | SYN, v1, no key | ProtocolError: TCP: [OptNo 30] invalid format |
| 12 | SYN/ACK, sender's key | parses |
| 20 | ACK, both keys | parses |
| 22 | first data ACK: both keys + Data-Level Length | ProtocolError |
| 24 | first data ACK: both keys + Data-Level Length + Checksum | ProtocolError |
Cause: pcapkit/protocols/transport/tcp.py:1550 raises unless schema.length in (12, 20). The comment above it cites §3.1 but names only those two lengths. The schema matches that limit: MPTCPCapable.rkey is ConditionalField(UInt64Field(), lambda pkt: pkt['length'] == 20) (schema/transport/tcp.py:894-897), skey is unconditional, and there is no Data-Level Length or Checksum field. Figure 4 makes the sender's key conditional on "Length > 4" and the receiver's key on "Length > 12".
Fix:
- Accept lengths 4, 12, 20, 22 and 24.
- Make
skeyconditional onlength > 4andrkeyonlength > 12. - Add the Data-Level Length (16 bits, present from length 22) and the optional Checksum (16 bits, length 24).
- Mirror all of this on the
makeside. - Add a parse and a round-trip test for each of the five lengths.
Blocked on #1034 and #1040, the open docstring-only PRs for the #719 sweep that edit transport/tcp.py and schema/transport/tcp.py. Starts once both merge or close. Found while reviewing #1040.
Activity
JarryShaw commentedon Oct 5, 2026
Unblocked: #1034 and #1040 merged. A worker is on the fix now.
fix(tcp): parse all five MP_CAPABLE lengths of RFC 8684 (#1042)
fix(tcp): parse all five MP_CAPABLE lengths of RFC 8684 (#1042) (#1048)