Repository navigation
fix(dumpkit): a nanosecond trace of a microsecond PCAP keeps the fraction unscaled #1500
Description
Describe the bug
Tracing a microsecond PCAP with trace_nanosecond=True writes a nanosecond-magic file but copies the microsecond fraction as is, so every timestamp shrinks by 1000.
Reproduction
A µs PCAP record (1500000000, 123456) traced with trace_nanosecond=True writes magic 4d3cb2a1 and record (1500000000, 123456), which re-reads as 1500000000.000123456.
Expected behavior
1500000000.123456: the fraction is scaled to the output resolution (×1000 for µs → ns, ÷1000 for ns → µs).
System information
Linux, CPython 3.14.7, main at 00aa1fc90.
Additional context
pcapkit/dumpkit/pcap.py:206-207 writes frame_info.ts_usec unconverted. For PCAP-NG input, foundation/engines/pcapng.py converts at the block's own resolution. many_interfaces.pcapng also hits this.
Found by the #1202 foundation round-trip slice; reproduced on main.
Activity
JarryShaw commentedon Oct 9, 2026
Blocked until the #1202 foundation-slice test PR (branch
test/1202-foundation-roundtrips) merges. That PR adds this defect'sGaprow, and the fix must delete the row.test(foundation): reassembly, traceflow, engine and registry round tr…
test(foundation): reassembly, traceflow, engine and registry round tr…
test(foundation): reassembly, traceflow, engine and registry round tr…
test(foundation): reassembly, traceflow, engine and registry round tr…
test(foundation): reassembly, traceflow, engine and registry round tr…
test(foundation): reassembly, traceflow, engine and registry round tr…
JarryShaw commentedon Oct 9, 2026
Unblocked: #1508 has merged, so this defect's known-failure row is on
main. A worker is on the fix, and the fix PR deletes the row.fix(dumpkit): scale a PCAP trace record's fraction to the trace's res…