Skip to content

fix(protocols): makers reject bad arguments with the reader's 'invalid format' text #2296

Closed

Description

@JarryShaw

Describe the bug
Several _make_* builders reject a caller-supplied argument with the parse-error text <alias>: [Chunk|Param|Cause|OptNo N] invalid format. That text says the wire data is malformed. Here nothing was parsed, so the caller gets no hint which keyword was wrong or what value was passed.

Reproduction (main 9d504ead5)

>>> SCTP.__new__(SCTP)._make_chunk_data(Chunk(0), flags=b'\x00\x00')
ProtocolError: SCTP: [Chunk 0] invalid format
>>> SCTP.__new__(SCTP)._make_param_hostname(Parameter.Host_Name_Address, name=b'example')
ProtocolError: SCTP: [Param 11] invalid format

Expected behavior
SCTP: [Chunk 0] invalid flags: must be one octet, not b'\x00\x00' and SCTP: [Param 11] invalid name: must be NUL-terminated, not b'example'. One convention covers all of these sites: the maker names the argument and shows its value.

  • SCTP: the _make_chunk_* flags guards, _make_param_hostname, _make_cause_invalid_stream
  • MH: make, _make_opt_bad, _make_opt_badf, _make_opt_auth, and the _make_opt_pad warning
  • TCP _make_mptcp_capable, HIP _make_locator, PCAP-NG _make_block_dsb
    Readers keep the invalid format text, so the SCTP: [Chunk 0] invalid format pin in test_transport_edge_roundtrip_unit (a parse case) stays. No test pins a maker's text.

System information
Linux, CPython 3.14.9, checkout main 9d504ead5.

Related: #2276 and #2273 change _make_locator and _make_block_dsb for other reasons; land whichever is first and rebase the other.

Activity

  1. added this to the PyPCAPKit v1.5 milestone on Oct 26, 2026
  2. added
    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)
    on Oct 26, 2026
  3. moved this to Pending in PyPCAPKiton Oct 26, 2026
  4. JarryShaw commented on Oct 26, 2026

    @JarryShaw
    OwnerAuthor

    Blocked until the round-7 fix PRs for #2268–#2316 merge. This change spans the makers in most protocol modules, which those fixes edit, so it starts from the merged tree.

  5. added
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 26, 2026
  6. moved this from Pending to Blocked in PyPCAPKiton Oct 26, 2026
  7. added
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 27, 2026
  8. JarryShaw commented on Oct 27, 2026

    @JarryShaw
    OwnerAuthor

    Unblocking — the round-7 fix PRs for #2268–#2316 have all landed now (this is the last one still open in that range). Open to pick up.

  9. moved this from Blocked to Pending in PyPCAPKiton Oct 27, 2026
  10. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 28, 2026
  11. moved this from Pending to WIP in PyPCAPKiton Oct 28, 2026
  12. Qiu-LingYan commented on Oct 28, 2026

    @Qiu-LingYan

    Picking this up as suggested — see PR #2404, which aligns all maker-side guards with the invalid <argument>: <requirement>, not <value!r> convention (reader-side messages untouched) and adds 12 full-string message tests.

  13. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions