Repository navigation
fix(corekit): IPv4InterfaceField reads hostmask-shaped masks as hostmasks and repacks a different mask #1294
Description
Describe the bug
IPv4InterfaceField.post_process builds the interface with ipaddress.ip_interface(f"{ip}/{mask}") (pcapkit/corekit/fields/ipaddress.py:432), and the stdlib treats a mask such as 0.0.0.255 as a hostmask. The octets are then re-derived as a netmask on pack. Affects pcapng IF_IPv4AddrOption.
To Reproduce
f = IPv4InterfaceField()
v = f.unpack(bytes.fromhex("0a000001000000ff"), {}) # 10.0.0.1/24
f.pack(v, {}).hex() # "0a000001ffffff00"
# 0a0000017fffffff -> 10.0.0.1/1 -> 0a00000180000000Repro: /tmp/rtissues/corekit-repro.py (check D8) on origin/main 11ae68e.
Expected behavior
The four mask octets round-trip as read (keep the netmask as given, or reject a non-contiguous mask instead of reinterpreting it).
Found by the corekit round-trip audit (#1202). The repro was re-checked by an independent verifier, and I re-ran it on main at 11ae68ebf.
Activity
JarryShaw commentedon Oct 7, 2026
A worker is on it now.
fix(corekit): IPv4InterfaceField keeps non-netmask masks; OrderedMult…
JarryShaw commentedon Oct 7, 2026
Decision needed on a string-parsing side effect of #1346. The PR keeps a non-contiguous wire mask, so
0a000001000000ffparses to10.0.0.1/0.0.0.255. To make that string pack back byte-exactly, it now reads a dotted mask literally whenever the mask is not a contiguous netmask. The stdlib reads the same string as a hostmask:mainpackswith_netmask10.0.0.1/0.0.0.255…ffffff00(/24)…000000ff(literal)/255.255.255.010.0.0.1/255.0.255.0FieldValueError…ff00ff00ValueError10.0.0.1/24,/255.255.255.0…ffffff00…ffffff00/255.255.255.0Options:
str()→packround trips for every wire value. The cost is that a user who passes the stdlib's hostmask spelling of/24now gets a different mask.str()form (e.g. a raw hex mask). Wire round trips still hold; string round trips hold only through that form.I recommend (1): it matches the every-round-trip ruling and the field's wire meaning. It is a
breakingchange, and the PR body states it.JarryShaw commentedon Oct 7, 2026
(1) sounds right but if stdlib's hostmask will be parsed different, can we either drop stdlib or fix that properly (prefer the latter)?
JarryShaw commentedon Oct 7, 2026
Ruling recorded: option (1), keeping the wire mask literal, but without diverging from the stdlib wherever the stdlib already defines a meaning. Fix the ambiguity properly rather than dropping the stdlib.
Concrete shape, now going to #1346:
/prefixlen, and a hostmask such as10.0.0.1/0.0.0.255(which means/24) all parse exactly as onmain.255.0.255.0fall into this group. They raise onmaintoday, so no existing input changes meaning.str()of a raw-mask value never produces a string the stdlib would read differently. A wire mask that is hostmask-shaped (0.0.0.255on the wire) renders in an unambiguous form instead of dotted quad, andpre_processaccepts that form back. Sopack(str(unpack(wire))) == wirestill holds for every mask, and no stdlib-legal string changes meaning.If this reading is off, say so on #1346 before it lands.
fix(corekit): IPv4InterfaceField keeps non-netmask masks; OrderedMult…