Skip to content

fix(corekit): PaddingField sites outside #1223 still zero-fill their padding on rebuild #1437

Closed

Description

@JarryShaw

Describe the bug
#1436 makes PaddingField write back the octets it is given, and threads them through the sites #1223 and #1329 list. Other PaddingField sites still zero-fill non-zero padding on rebuild, because their reader, data model and make() never carry the value.

Site Status
MH reserved fields not listed in #1223 (about 37 of them, e.g. Home Test Init, MNP, HNP, GRE, QoS) MH Home Test Init reserved aabb was confirmed on #1436's head to still rebuild as 0000
IPv4 Quick-Start report "not used" octet and IPv4 option padding (protocols/{,schema/,data/}internet/ipv4.py) reported by the #1436 worker, not yet re-measured
L2TP offset pad, kept-as-captured on parse (protocols/link/l2tpv2.py) reported by the #1436 worker, not yet re-measured
PCAP-NG SPB padding (schema/misc/pcapng.py:1549) and option padding, which needs _read_block_spb/_make_block_spb in protocols/misc/pcapng.py reported by the #1436 worker, not yet re-measured

Expected behavior
Byte-exact, per the every-round-trip ruling: each site keeps its captured padding and writes it back, with a zero default for fresh builds.

Blocked until #1436 merges, because these sites rely on its PaddingField.pack and its maker pattern. The IPv4 sites also wait on #1431, which owns ipv4.py, and the PCAP-NG sites on #1429, which owns protocols/misc/pcapng.py.

Activity

  1. added
    fixPull requests that fix a defect (fix: subject prefix)
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 8, 2026
  2. JarryShaw commented on Oct 8, 2026

    @JarryShaw
    OwnerAuthor

    Unblocked: #1436 (3fdcf535f), #1431 and #1429 have all merged. Two workers are on it now, on disjoint files:

    • Part A, MH reserved sites: fix/1437-mh-reserved-padding
    • Part B, IPv4 QS/option padding, L2TP offset pad, PCAP-NG SPB/option padding: fix/1437-ipv4-l2tp-pcapng-padding. Each site is re-measured on main before it is fixed.
  3. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 8, 2026
  4. moved this from Blocked to WIP in PyPCAPKiton Oct 8, 2026
  5. JarryShaw commented on Oct 9, 2026

    @JarryShaw
    OwnerAuthor

    Both halves are merged, so I'm closing this. Part B, PCAP-NG (with guard tests confirming that IPv4 and L2TP already round-trip), is #1441 as 8fcee466d. Part A, the 38 MH reserved sites, is #1442 as 78991b7d5.

  6. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 9, 2026
  7. added this to the PyPCAPKit v1.5 milestone on Oct 26, 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

    fixPull requests that fix a defect (fix: subject prefix)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions