Skip to content

Conversation

@mozillazg
Copy link
Owner

@mozillazg mozillazg commented Oct 6, 2025

Closes #156

Summary by CodeRabbit

  • New Features

    • Added --absolute-tcp-sequence-numbers (-S) to show absolute TCP sequence numbers (relative is now default).
    • Added --utc-time to display timestamps in UTC.
  • Documentation

    • Updated README and README.zh-CN for new flags and behavior.
    • Added/updated CHANGELOG entries.
  • Tests

    • Expanded coverage with new fixtures and cases for sequence-number modes, timestamps, and formatting variants.
  • Chores

    • Bumped vendored dependency version.

This change makes the default behavior to output relative TCP sequence
numbers. The `-S` flag is introduced to output absolute TCP sequence
numbers for backward compatibility.

This makes the output more readable for humans.

The test suite has been updated to reflect this change, and new tests
with the `-S` flag have been added to ensure correctness.
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 6, 2025

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)
Check name Status Explanation Resolution
Out of Scope Changes Check ⚠️ Warning The PR includes additions unrelated to the “relative TCP sequence numbers” goal such as the new --utc-time flag, corresponding UTC timestamp support in the stdout writer, and documentation/test fixtures for timestamp formatting that are not part of issue #156’s scope. These UTC timestamp features and related test coverage should be extracted into a separate PR or explicitly linked to a separate issue, leaving this PR focused solely on implementing default relative TCP sequence numbering.
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title concisely describes the primary feature addition—defaulting to relative TCP sequence numbering in the stdout TCP formatter—matching the main change in the PR.
Linked Issues Check ✅ Passed The changes implement default relative TCP sequence number formatting with an override flag -S/--absolute-tcp-sequence-numbers, add the necessary state tracking and helper methods in the stdout writer and pktdump vendor code, and include test fixtures covering both default relative and absolute modes, satisfying the linked issue’s goal for relative numbering and suppression when no advancement occurs.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch support-relative-tcp-seq

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (5)
testdata/format/tcp.pcapng.-tttt.out.txt (1)

5-24: Relative TCP seq formatting and ACK-only suppression look correct.

  • Post-handshake uses relative seq/ack (e.g., ack 1, seq 1:87).
  • Pure ACK lines omit seq. Data/FIN math is consistent.

Consider adding fixtures for retransmissions, out-of-order segments, and 32-bit wraparound to harden relative mapping.

cmd/writer.go (1)

59-59: Add nil-check for formatter in StdoutWriter.Write
StdoutWriter.Init is idempotent; however, Write() will panic if Init() isn’t called (w.formatter == nil). Add a guard at the start of Write() to return a clear error when the formatter is uninitialized. No code paths create a StdoutWriter without Init().

internal/writer/stdout.go (1)

70-75: Guard against missing Init to avoid nil deref

If some code path forgets to call Init(), w.formatter/w.formatOpts will be nil. Add a lazy init to be safe.

Apply near the top of Write():

 func (w *StdoutWriter) Write(e *event.Packet) error {
   if w.DoNothing {
     return nil
   }
+  if w.formatter == nil || w.formatOpts == nil {
+    w.Init()
+  }

Ensure all writer creation paths invoke Init() (cmd/writer.go already does per PR summary).

vendor/github.com/x-way/pktdump/format.go (2)

490-496: Avoid re-entering defaultFormatter; call the receiver’s formatter to prevent deadlock/state corruption

These nested FormatWithStyle calls use the package-level defaultFormatter introduced above. If Format uses a lock, this can deadlock. If not, it can race on shared state. Call the receiver’s non-exported formatter instead.

Apply:

@@
-       case layers.EthernetTypeIPv4:
-           out += FormatWithStyle(gopacket.NewPacket(gre.LayerPayload(), layers.LayerTypeIPv4, gopacket.Default), f.opts.HeaderStyle)
+       case layers.EthernetTypeIPv4:
+           out += f.formatWithOptions(gopacket.NewPacket(gre.LayerPayload(), layers.LayerTypeIPv4, gopacket.Default))
-       case layers.EthernetTypeIPv6:
-           out += FormatWithStyle(gopacket.NewPacket(gre.LayerPayload(), layers.LayerTypeIPv6, gopacket.Default), f.opts.HeaderStyle)
+       case layers.EthernetTypeIPv6:
+           out += f.formatWithOptions(gopacket.NewPacket(gre.LayerPayload(), layers.LayerTypeIPv6, gopacket.Default))
@@
-   case layers.PPPTypeIPv4:
-       return FormatWithStyle(gopacket.NewPacket(ppp.LayerPayload(), layers.LayerTypeIPv4, gopacket.Default), f.opts.HeaderStyle)
+   case layers.PPPTypeIPv4:
+       return f.formatWithOptions(gopacket.NewPacket(ppp.LayerPayload(), layers.LayerTypeIPv4, gopacket.Default))
-   case layers.PPPTypeIPv6:
-       return FormatWithStyle(gopacket.NewPacket(ppp.LayerPayload(), layers.LayerTypeIPv6, gopacket.Default), f.opts.HeaderStyle)
+   case layers.PPPTypeIPv6:
+       return f.formatWithOptions(gopacket.NewPacket(ppp.LayerPayload(), layers.LayerTypeIPv6, gopacket.Default))

Also applies to: 531-534


59-81: Unreachable fallback for ACK printing

In the relative branch, ackPart is always set when tcp.ACK is true, so:

  • if ackPart == "" && tcp.ACK { out += fmt.Sprintf(", ack %d", tcp.Ack) }

never triggers. Remove to simplify.

-        if ackPart == "" && tcp.ACK {
-            out += fmt.Sprintf(", ack %d", tcp.Ack)
-        }
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 324649d and 9f18ef0.

⛔ Files ignored due to path filters (1)
  • go.sum is excluded by !**/*.sum
📒 Files selected for processing (71)
  • CHANGELOG.md (1 hunks)
  • README.md (3 hunks)
  • README.zh-CN.md (1 hunks)
  • cmd/options.go (3 hunks)
  • cmd/read.go (1 hunks)
  • cmd/read_test.go (23 hunks)
  • cmd/root.go (1 hunks)
  • cmd/writer.go (1 hunks)
  • go.mod (1 hunks)
  • internal/writer/stdout.go (5 hunks)
  • testdata/format/curl-thread.pcapng.-S.out.txt (1 hunks)
  • testdata/format/curl-thread.pcapng.-v.-S.out.txt (1 hunks)
  • testdata/format/curl-thread.pcapng.-v.out.txt (3 hunks)
  • testdata/format/curl-thread.pcapng.out.txt (1 hunks)
  • testdata/format/curl-user.pcapng.-S.out.txt (1 hunks)
  • testdata/format/curl-user.pcapng.-v.-S.out.txt (1 hunks)
  • testdata/format/curl-user.pcapng.-v.out.txt (1 hunks)
  • testdata/format/curl-user.pcapng.out.txt (1 hunks)
  • testdata/format/ipoptions.pcap.-S.out.txt (1 hunks)
  • testdata/format/ipoptions.pcap.-v.-S.out.txt (1 hunks)
  • testdata/format/ipoptions.pcap.-v.out.txt (1 hunks)
  • testdata/format/ipoptions.pcap.out.txt (1 hunks)
  • testdata/format/mptcp.pcap.-S.out.txt (1 hunks)
  • testdata/format/mptcp.pcap.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-A.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-A.out.txt (5 hunks)
  • testdata/format/tcp.pcapng.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-X.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-X.out.txt (7 hunks)
  • testdata/format/tcp.pcapng.-XX.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-XX.out.txt (7 hunks)
  • testdata/format/tcp.pcapng.-c.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-q.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-t.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-t.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-tt.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-tt.nano.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-tt.nano.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-tt.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-ttt.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-ttt.nano.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-ttt.nano.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-ttt.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-tttt.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-tttt.nano.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-tttt.nano.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-tttt.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-ttttt.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-ttttt.nano.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-ttttt.nano.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-ttttt.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-v.--context.process.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-v.--context.process.out.txt (5 hunks)
  • testdata/format/tcp.pcapng.-v.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-v.out.txt (5 hunks)
  • testdata/format/tcp.pcapng.-x.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-x.out.txt (7 hunks)
  • testdata/format/tcp.pcapng.-xx.-S.out.txt (1 hunks)
  • testdata/format/tcp.pcapng.-xx.out.txt (7 hunks)
  • testdata/format/tcp.pcapng.out.txt (1 hunks)
  • testdata/format/tfo.pcap.-S.out.txt (1 hunks)
  • testdata/format/tfo.pcap.out.txt (1 hunks)
  • testdata/format/tls.pcap.-S.out.txt (1 hunks)
  • testdata/format/tls.pcap.out.txt (1 hunks)
  • vendor/github.com/x-way/pktdump/.gitignore (1 hunks)
  • vendor/github.com/x-way/pktdump/format.go (5 hunks)
  • vendor/github.com/x-way/pktdump/formatter.go (1 hunks)
  • vendor/github.com/x-way/pktdump/options.go (2 hunks)
  • vendor/github.com/x-way/pktdump/tcp.go (1 hunks)
  • vendor/github.com/x-way/pktdump/tcp_sack.go (1 hunks)
  • vendor/modules.txt (2 hunks)
🧰 Additional context used
📓 Path-based instructions (6)
**/*.go

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.go: Follow standard Go formatting using go fmt
Run go vet before committing Go code
Use meaningful variable and function names in Go code
Add godoc comments for exported functions and types

Files:

  • vendor/github.com/x-way/pktdump/options.go
  • cmd/writer.go
  • cmd/options.go
  • cmd/read_test.go
  • vendor/github.com/x-way/pktdump/tcp_sack.go
  • vendor/github.com/x-way/pktdump/tcp.go
  • cmd/read.go
  • vendor/github.com/x-way/pktdump/formatter.go
  • internal/writer/stdout.go
  • vendor/github.com/x-way/pktdump/format.go
  • cmd/root.go
vendor/**

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

vendor/**: Vendor dependencies with go mod vendor
Do not manually edit files in vendor/

Files:

  • vendor/github.com/x-way/pktdump/options.go
  • vendor/github.com/x-way/pktdump/tcp_sack.go
  • vendor/github.com/x-way/pktdump/tcp.go
  • vendor/modules.txt
  • vendor/github.com/x-way/pktdump/formatter.go
  • vendor/github.com/x-way/pktdump/format.go
CHANGELOG.md

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Update CHANGELOG.md for notable changes

Files:

  • CHANGELOG.md
{go.mod,go.sum}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use go mod tidy to manage Go dependencies

Files:

  • go.mod
**/*_test.go

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*_test.go: Write unit tests for new functionality
Place unit tests as *_test.go files alongside source code

Files:

  • cmd/read_test.go
README.md

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Update README.md when changes are user-facing

Files:

  • README.md
🧬 Code graph analysis (7)
vendor/github.com/x-way/pktdump/options.go (1)
cmd/options.go (1)
  • Options (36-115)
cmd/read_test.go (1)
cmd/options.go (1)
  • Options (36-115)
vendor/github.com/x-way/pktdump/tcp_sack.go (2)
vendor/github.com/x-way/pktdump/formatter.go (1)
  • Formatter (9-13)
vendor/github.com/gopacket/gopacket/layers/tcp.go (2)
  • TCP (20-36)
  • TCPOption (104-118)
vendor/github.com/x-way/pktdump/tcp.go (1)
vendor/github.com/x-way/pktdump/formatter.go (1)
  • Formatter (9-13)
vendor/github.com/x-way/pktdump/formatter.go (2)
vendor/github.com/x-way/pktdump/options.go (1)
  • Options (6-19)
vendor/github.com/x-way/pktdump/format.go (1)
  • Format (608-610)
internal/writer/stdout.go (3)
vendor/github.com/x-way/pktdump/formatter.go (2)
  • Formatter (9-13)
  • NewFormatter (15-21)
cmd/options.go (1)
  • Options (36-115)
vendor/github.com/x-way/pktdump/options.go (3)
  • Options (6-19)
  • FormatStyle (3-3)
  • ContentStyle (4-4)
vendor/github.com/x-way/pktdump/format.go (3)
vendor/github.com/x-way/pktdump/formatter.go (2)
  • Formatter (9-13)
  • NewFormatter (15-21)
vendor/github.com/gopacket/gopacket/layers/tcp.go (1)
  • TCP (20-36)
vendor/github.com/x-way/pktdump/options.go (2)
  • Options (6-19)
  • FormatStyle (3-3)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (20)
  • GitHub Check: e2e-test (tp-btf, 5.10-20250630.013259)
  • GitHub Check: e2e-test (socket-filter, 6.1-20250630.013259)
  • GitHub Check: e2e-test (tp-btf, 6.1-20250630.013259)
  • GitHub Check: e2e-test (cgroup-skb, 5.4-20250630.013259)
  • GitHub Check: e2e-test (tc, 6.12-20250630.013259)
  • GitHub Check: e2e-test (tc, 6.6-20250630.013259)
  • GitHub Check: e2e-test (tc, bpf-next-20250630.013259)
  • GitHub Check: e2e-test (tc, 5.15-20250630.013259)
  • GitHub Check: e2e-test (tc, 6.1-20250630.013259)
  • GitHub Check: e2e-test (tc, 5.10-20250630.013259)
  • GitHub Check: e2e-test (tc, 4.19-20250630.013259)
  • GitHub Check: e2e-test (tc, 5.4-20250630.013259)
  • GitHub Check: containerd-integration-test
  • GitHub Check: k8s-integration-test
  • GitHub Check: docker-integration-test
  • GitHub Check: release-test
  • GitHub Check: unit-test
  • GitHub Check: build-with-dynamic-link
  • GitHub Check: build
  • GitHub Check: scan
🔇 Additional comments (70)
testdata/format/tcp.pcapng.-ttttt.-S.out.txt (1)

1-24: Absolute TCP seq rendering looks correct for -S.

Handshake, data ranges, and ACK/FIN math are consistent. No issues.

testdata/format/tcp.pcapng.-c.-S.out.txt (1)

1-2: LGTM for -c with -S.

SYN/SYN-ACK lines show absolute sequence numbers as expected.

testdata/format/tcp.pcapng.-v.--context.process.-S.out.txt (1)

1-100: Verbose/context output with -S is consistent.

Absolute seq/ack retained on ACK-only packets; payload ranges and headers align.

testdata/format/tcp.pcapng.-v.--context.process.out.txt (1)

14-100: Relative sequencing in verbose/context looks right.

ACK-only lines omit seq; ranges and totals match payload lengths.

testdata/format/tcp.pcapng.-tttt.-S.out.txt (1)

1-24: LGTM for -tttt with -S.

Absolute time plus absolute TCP seq/ack; sequence arithmetic checks out.

testdata/format/tcp.pcapng.-tttt.nano.-S.out.txt (1)

1-24: Nano timestamp variant with -S looks consistent.

Absolute seq/ack and payload ranges match other fixtures.

testdata/format/tcp.pcapng.-A.out.txt (1)

13-124: Relative TCP sequencing and seq-omission on pure ACKs look correct

Handshake shows absolute; subsequent lines use relative seq/ack and omit seq on ACK-only packets. Matches expected tcpdump-style defaults.

testdata/format/tcp.pcapng.-t.-S.out.txt (1)

1-24: -S variant correctly uses absolute TCP seq/ack

Absolute numbers throughout, as intended for -S.

testdata/format/tcp.pcapng.-tt.-S.out.txt (1)

1-24: Looks good: -tt with -S uses absolute seq/ack

Output matches the absolute-numbering expectation for -S.

testdata/format/tcp.pcapng.-XX.-S.out.txt (1)

1-234: Hex/ASCII dump with -S shows absolute sequencing as expected

Formatting and numbering match the -S behavior; payload framing consistent.

testdata/format/tcp.pcapng.-tttt.nano.out.txt (1)

5-24: Relative sequencing with nano timestamps looks correct

Seq/ack relative after handshake; seq omitted on ACK-only packets. Matches intended default behavior.

testdata/format/tcp.pcapng.-v.out.txt (2)

18-122: Verbose (-v) output correctly uses relative TCP numbering

Relative seq/ack and omission of seq on pure ACKs align with new default; payload and metadata unchanged otherwise.


146-206: Response frames and teardown also consistent with relative numbering

Data ranges and FIN/ACK sequence/ack increments look correct.

testdata/format/tcp.pcapng.-X.out.txt (1)

21-210: Hex view (-X) uses relative seq/ack post-handshake as intended

Relative numbering present; handshake absolute; payload formatting intact.

testdata/format/tcp.pcapng.-t.out.txt (1)

5-24: Ignore: -t fixture prints relative seq/ack correctly
Handshake frames are shown with absolute numbers; all subsequent sequence and acknowledgment numbers (including P-frames and FINs) are relative as intended.

Likely an incorrect or invalid review comment.

testdata/format/tcp.pcapng.-ttttt.nano.out.txt (1)

5-24: LGTM! Test data correctly reflects relative TCP sequence numbering.

The updated test data properly demonstrates the new default behavior where TCP sequence and acknowledgment numbers are displayed as relative values (e.g., ack 1, seq 1:87) after the initial handshake, while the SYN packets retain absolute sequence numbers. This aligns with tcpdump's standard behavior.

testdata/format/tfo.pcap.out.txt (1)

3-4: LGTM! TFO test data correctly updated for relative sequencing.

The relative sequence numbers are properly applied to TCP Fast Open packets with MPTCP options.

testdata/format/tcp.pcapng.-x.out.txt (1)

21-206: LGTM! Hex dump test data correctly updated.

The text portions of the output correctly show relative TCP sequence numbers while the hex dump sections remain unchanged (as they display the actual packet bytes on the wire).

testdata/format/tcp.pcapng.-xx.out.txt (1)

25-229: LGTM! Extended hex dump test data correctly updated.

Relative sequence numbering is properly reflected in the text output portions.

testdata/format/tcp.pcapng.-tt.nano.out.txt (1)

5-24: LGTM! Nanosecond timestamp test data correctly updated.

Relative sequence numbering is consistently applied across all packets after the handshake.

testdata/format/mptcp.pcap.out.txt (1)

3-14: LGTM! MPTCP test data correctly preserves DSS sequence numbers.

The relative TCP sequence numbers are properly applied while MPTCP DSS (Data Sequence Signal) fields correctly retain their absolute data-level sequence numbers, which is the expected behavior per the MPTCP specification.

cmd/read.go (1)

35-35: LGTM! Init() correctly placed.

The Init() call follows the same pattern as in cmd/writer.go: create writer → apply options → initialize → use writer. This consistency ensures proper initialization across all stdout writer usage paths.

README.zh-CN.md (1)

397-397: LGTM! Documentation accurately reflects the new feature.

The flag table correctly marks -S, --absolute-tcp-sequence-numbers as supported (✅), consistent with the implementation in cmd/root.go and the English documentation in README.md.

go.mod (1)

113-113: LGTM! Dependency version updated correctly.

The pktdump dependency is updated to v0.0.9-0.20251006081716-1f836652cfec to support the new relative TCP sequence number formatting feature. This version bump is consistent with the corresponding update in vendor/modules.txt.

cmd/root.go (1)

146-148: LGTM! CLI flags implemented correctly.

The new flags are properly defined:

  • -S, --absolute-tcp-sequence-numbers: Matches tcpdump's convention for printing absolute (rather than relative) TCP sequence numbers
  • --utc-time: Provides UTC timestamp option

Both flags follow proper cobra flag definition patterns and have clear, accurate help text.

testdata/format/mptcp.pcap.-S.out.txt (1)

1-14: LGTM! Test data validates -S flag for MPTCP traffic.

This test data file appropriately validates the -S (absolute TCP sequence numbers) flag behavior for MPTCP (Multipath TCP) packets, showing absolute sequence numbers like seq 412382786 and ack 2707981558 as expected when the flag is enabled.

vendor/modules.txt (1)

409-409: LGTM! Vendor module references updated consistently.

The pktdump module version references are updated to v0.0.9-0.20251006081716-1f836652cfec, matching the version specified in go.mod. Both the module listing (line 409) and the replace directive comment (line 616) are consistently updated.

Also applies to: 616-616

README.md (2)

508-508: LGTM! Flag documentation is clear and accurate.

The -S, --absolute-tcp-sequence-numbers flag is properly documented with clear description: "Print absolute, rather than relative, TCP sequence numbers." This correctly describes the flag's purpose of overriding the default relative sequence number behavior to match tcpdump's convention.


618-618: LGTM! Comparison table accurately updated.

The tcpdump comparison table correctly marks the -S, --absolute-tcp-sequence-numbers option as supported (✅) for both tcpdump and ptcpdump, accurately reflecting feature parity.

testdata/format/tls.pcap.out.txt (1)

3-7: LGTM! Test data validates default relative sequence number behavior.

The TLS handshake output correctly demonstrates the default relative TCP sequence number behavior (without -S flag). Sequence and acknowledgment numbers are normalized (e.g., ack 1, seq 1:518, ack 518), making the packet flow easier to read and matching tcpdump's default behavior.

testdata/format/ipoptions.pcap.-S.out.txt (1)

1-3: LGTM! Test data validates -S flag for IP options scenario.

This test data appropriately validates the -S (absolute TCP sequence numbers) flag behavior for packets with IP options, showing absolute sequence numbers (e.g., seq 122218745, ack 122218746) as expected when the flag is enabled.

testdata/format/curl-user.pcapng.-S.out.txt (1)

1-5: LGTM - Test data for absolute sequence numbers.

This test fixture correctly demonstrates absolute TCP sequence number output with the -S flag, showing large sequence numbers (e.g., seq 940329637) as expected. The data complements other test cases covering relative sequence number behavior.

cmd/options.go (3)

69-69: LGTM - UTC time option added.

The utcTime field addition follows the existing pattern for boolean configuration options in the Options struct.


87-87: LGTM - Absolute TCP sequence numbers option added.

The absoluteTcpSequenceNumbers field enables support for absolute vs. relative TCP sequence number display, addressing the PR objective to default to relative sequence numbers (like tcpdump's behavior).


276-278: LGTM - Options properly wired to stdout writer.

Both new options are correctly applied to the stdout writer, following the established pattern used by other formatting options in this method.

testdata/format/tcp.pcapng.-XX.out.txt (1)

25-234: LGTM - Test data demonstrates relative TCP sequence numbers.

This test fixture correctly shows the default relative TCP sequence number behavior, where subsequent packets display small sequence numbers (ack 1, seq 1:87, etc.) after the initial handshake, matching tcpdump's standard output format.

testdata/format/tls.pcap.-S.out.txt (1)

1-7: LGTM - TLS test data with absolute sequence numbers.

This test fixture demonstrates absolute TCP sequence number display for TLS handshake traffic when using the -S flag, providing appropriate test coverage for the new feature.

testdata/format/tcp.pcapng.-S.out.txt (1)

1-24: LGTM - Comprehensive test data for absolute sequence numbers.

This test fixture provides thorough coverage of absolute TCP sequence number display across a complete HTTP transaction, from handshake through teardown, when using the -S flag.

testdata/format/curl-thread.pcapng.-v.-S.out.txt (1)

1-59: LGTM - Verbose test data with absolute sequence numbers.

This test fixture demonstrates the combination of verbose output (-v) with absolute TCP sequence numbers (-S), providing appropriate coverage for this flag combination with detailed process, thread, and IP header information.

testdata/format/curl-user.pcapng.out.txt (1)

3-5: LGTM - Test data updated for default relative sequence numbers.

The modified lines correctly demonstrate the default relative TCP sequence number behavior, where sequence and acknowledgment numbers are displayed relative to the connection's initial sequence numbers (e.g., ack 1, seq 1:518). This aligns with tcpdump's standard behavior and the PR's objective.

testdata/format/tcp.pcapng.-ttt.nano.out.txt (1)

5-24: LGTM - Test data demonstrates relative sequence numbers with nanosecond timestamps.

The modified lines correctly show relative TCP sequence numbers combined with nanosecond-precision delta timestamps (-ttt.nano flags), providing appropriate test coverage for this flag combination.

testdata/format/tcp.pcapng.-ttttt.nano.-S.out.txt (1)

1-24: LGTM!

This test fixture correctly demonstrates the -S (absolute TCP sequence numbers) flag behavior. The sequence and acknowledgment numbers are displayed in their absolute form (e.g., seq 217911223, ack 217911224), which aligns with the PR objective to support both relative (default) and absolute (via -S) TCP sequence number display.

testdata/format/tcp.pcapng.-xx.-S.out.txt (1)

1-234: LGTM!

This test fixture correctly demonstrates the combination of -xx (hex output with link-layer header) and -S (absolute TCP sequence numbers) flags. The absolute sequence numbers (e.g., seq 217911223, ack 3879633684) are correctly displayed alongside the hex packet dumps.

testdata/format/curl-user.pcapng.-v.-S.out.txt (1)

1-25: LGTM!

This test fixture correctly demonstrates the combination of -v (verbose output with IP header details) and -S (absolute TCP sequence numbers) flags for a curl HTTPS connection. The absolute sequence numbers and verbose process/packet metadata are properly displayed.

testdata/format/tcp.pcapng.-ttt.out.txt (1)

5-24: LGTM! This correctly demonstrates the new default behavior.

This test fixture shows relative TCP sequence numbers (e.g., seq 1:87, ack 1), which is the new default behavior introduced by this PR. This aligns with tcpdump's default behavior where the first SYN uses the absolute sequence number, and subsequent packets show relative offsets from the initial sequence number.

The relative numbering makes the output more readable by showing:

  • Small, predictable numbers instead of large random values
  • Clear relationships between sequence and acknowledgment numbers
  • Easier tracking of data transfer (e.g., seq 1:87 shows 86 bytes of data)
testdata/format/curl-user.pcapng.-v.out.txt (1)

12-25: LGTM! Relative sequences correctly displayed.

This test fixture demonstrates the default relative TCP sequence number behavior for a verbose curl trace. The relative numbering (e.g., ack 1, seq 1:518) makes it easier to follow the TLS handshake and data transfer, especially when reviewing the 517-byte TLS Client Hello payload.

testdata/format/curl-thread.pcapng.-S.out.txt (1)

1-10: LGTM!

This test fixture correctly demonstrates absolute TCP sequence numbers with the -S flag for a curl thread trace. The absolute sequence numbers (e.g., seq 1249028847, ack 2029530090) are properly displayed throughout the TCP connection lifecycle, including the HTTP GET request and 302 redirect response.

testdata/format/tcp.pcapng.-ttt.nano.-S.out.txt (1)

1-24: Negative delta timestamps are correct The -ttt fixtures (e.g., tcp.pcapng.-ttt.out.txt and tcp.pcapng.-ttt.nano.out.txt) all show the same negative value at line 17, matching expected delta-timestamp behavior.

vendor/github.com/x-way/pktdump/options.go (1)

17-84: Vendor file update verified: relative TCP sequence support originates from upstream commit 9f18ef0; file matches a proper vendored update.

testdata/format/tcp.pcapng.-x.-S.out.txt (1)

1-210: LGTM!

The test data correctly demonstrates absolute TCP sequence number formatting with the -x (hex dump) and -S (absolute sequence numbers) flags. The trace shows a complete TCP flow with proper sequence/acknowledgment progression through the handshake, data transfer, and teardown phases.

testdata/format/tcp.pcapng.-A.-S.out.txt (1)

1-124: LGTM!

The test data correctly demonstrates absolute TCP sequence number formatting with the -A (ASCII payload) and -S (absolute sequence numbers) flags. The HTTP request and response content is properly rendered, and the sequence/acknowledgment numbers match the expected absolute values throughout the flow.

testdata/format/tcp.pcapng.-ttttt.out.txt (1)

1-24: LGTM!

The test data correctly demonstrates relative TCP sequence number formatting (default behavior) with the -ttttt (delta timestamp) flag. After the initial handshake, sequence and acknowledgment numbers are displayed relative to the initial sequence numbers (e.g., seq 1:87 instead of absolute values), significantly improving readability as intended by PR objective #156.

testdata/format/tcp.pcapng.-tt.out.txt (1)

1-24: LGTM!

The test data correctly demonstrates relative TCP sequence number formatting with the -tt (Unix timestamp) flag. The relative sequence numbers (e.g., ack 1, seq 1:87) match the expected behavior, while timestamps are displayed in Unix epoch format with microsecond precision.

testdata/format/tcp.pcapng.-X.-S.out.txt (1)

1-210: LGTM!

The test data correctly demonstrates absolute TCP sequence number formatting with the -X (hex and ASCII display) and -S (absolute sequence numbers) flags. The combined hex and ASCII rendering is properly formatted, and the absolute sequence numbers are consistent throughout the TCP flow.

testdata/format/curl-thread.pcapng.out.txt (1)

1-10: LGTM!

The test data correctly demonstrates relative TCP sequence number formatting for a multi-threaded curl scenario. The relative sequence numbers (e.g., ack 1, seq 1:74) improve readability while preserving thread and parent process context information.

vendor/github.com/x-way/pktdump/tcp_sack.go (2)

9-40: Logic improvements look good.

After addressing the concurrency issue above, the other changes to formatSack are well-designed:

  • Adding block count to the output (Line 14-15) provides useful context.
  • The loop boundary check change from i < dataLen to i+8 <= dataLen (Line 29) is safer and prevents potential out-of-bounds access.
  • The relative sequence number logic correctly uses the reverse flow's base sequence number to compute relative SACK offsets.

Based on learnings


21-27: Race condition: missing mutex protection.

The method accesses f.tcpState[reverseKey] at Line 23 without acquiring the f.mu lock. This is the same concurrency issue present in the ensureTCPState and resetTCPDirection methods—concurrent access to the shared tcpState map will cause data races.

Apply this diff to add mutex protection:

 	if f != nil && f.opts.relativeTCPSeqEnabled() {
+		f.mu.Lock()
 		reverseKey := makeTCPFlowKey(dst, src, tcp.DstPort, tcp.SrcPort)
 		if reverse := f.tcpState[reverseKey]; reverse != nil && reverse.seqInitialized {
 			relBase = reverse.baseSeq
 			relative = true
 		}
+		f.mu.Unlock()
 	}

Likely an incorrect or invalid review comment.

vendor/github.com/x-way/pktdump/tcp.go (1)

28-42: Race condition: missing mutex protection.

Both ensureTCPState and resetTCPDirection access the shared f.tcpState map without acquiring the f.mu lock. Per the Formatter struct definition (shown in relevant code snippets), tcpState is protected by a sync.Mutex. Concurrent calls to these methods will cause data races.

Apply this diff to add mutex protection:

 func (f *Formatter) ensureTCPState(key tcpFlowKey) *tcpDirectionState {
+	f.mu.Lock()
+	defer f.mu.Unlock()
 	if state, ok := f.tcpState[key]; ok {
 		return state
 	}
 	state := &tcpDirectionState{}
 	f.tcpState[key] = state
 	return state
 }

 func (f *Formatter) resetTCPDirection(key, reverseKey tcpFlowKey) *tcpDirectionState {
+	f.mu.Lock()
+	defer f.mu.Unlock()
 	delete(f.tcpState, reverseKey)
 	state := &tcpDirectionState{}
 	f.tcpState[key] = state
 	return state
 }

Likely an incorrect or invalid review comment.

testdata/format/tcp.pcapng.out.txt (1)

5-24: Relative TCP sequence output looks correct

Handshake absolute; subsequent packets show relative seq/ack and proper ranges/ACK increments. Matches tcpdump-style defaults.

testdata/format/tcp.pcapng.-v.-S.out.txt (1)

1-124: Verbose (-v) + absolute (-S) fixture consistent

Absolute seq/ack are shown as expected; formatting and payload sections look correct.

testdata/format/curl-thread.pcapng.-v.out.txt (1)

11-58: Relative TCP sequence formatting aligns with new default

Relative seq/ack values and ranges are correct for the flow; verbose sections preserved.

cmd/read_test.go (2)

19-550: Great test matrix expansion for -S and timestamps

Comprehensive coverage across -S, -t/-tt/-ttt/-tttt/-ttttt, nano precision, verbosity, contexts, and multiple pcaps. Ensure all referenced expectedOutFile fixtures are committed to avoid CI failures.


555-555: UTC time in tests is a good call

Forcing utcTime=true stabilizes timestamp expectations across environments.

internal/writer/stdout.go (3)

58-69: Initialization and relative/absolute TCP sequence wiring look good

Init builds pktdump.Options, sets RelativeTCPSeq based on absoluteTcpSequenceNumbers, and instantiates a reusable Formatter. This matches the new default (relative) and -S override.

Also applies to: 36-41


302-317: UTC/local time toggle helper is correct

time() helper and WithUseUTCTime() cleanly switch timestamp base; integration in Write is fine.


154-156: Guard Write or use per-call Formatter
pktdump.Formatter and its Options share mutable state; concurrent Write calls can interleave header and content. Serialize Write with a mutex or instantiate a new Formatter via pktdump.NewFormatter(&pktdump.Options{}) per call and read its Options.FormatedContent.

vendor/github.com/x-way/pktdump/formatter.go (1)

31-47: Thread-safe formatter and options handling look solid

Mutex-guarded FormatWithOptions with options normalization and per-instance tcpState are appropriate for maintaining relative TCP seq state safely.

Also applies to: 9-21, 23-29

vendor/github.com/x-way/pktdump/format.go (3)

15-17: Good defensive bound on negative payload length

Capping negative length to zero avoids bogus seq range math.


103-103: SACK formatting via helper improves cohesion

Delegating to f.formatSack is cleaner and keeps TCP option formatting centralized.


148-214: Clean up TCP state on FIN or implement idle eviction

  • f.tcpState entries are only deleted on RST; flows closed with FIN accumulate indefinitely.
  • Minimal change: extend the RST check to also handle FIN
@@ format.go
-    if tcp.RST {
+    if tcp.RST || tcp.FIN {
         delete(f.tcpState, key)
         delete(f.tcpState, reverseKey)
     }
  • Recommended: track lastSeen per flow and periodically evict idle entries via a TTL or map-size cap
    Do you want a patch sketch for TTL-based eviction?

Likely an incorrect or invalid review comment.

00:00:00.000106 lo curl.345650 In IP 127.0.0.1.58694 > 127.0.0.1.8000: Flags [.], seq 217911310, ack 3879633870, win 511, options [nop,nop,TS val 2363239522 ecr 2363239522], length 0, ParentProc [ptcpdump.345626]
00:00:00.000427 lo curl.345650 Out IP 127.0.0.1.58694 > 127.0.0.1.8000: Flags [F.], seq 217911310, ack 3879634339, win 512, options [nop,nop,TS val 2363239522 ecr 2363239522], length 0, ParentProc [ptcpdump.345626]
00:00:00.000060 lo curl.345650 In IP 127.0.0.1.58694 > 127.0.0.1.8000: Flags [F.], seq 217911310, ack 3879634339, win 512, options [nop,nop,TS val 2363239522 ecr 2363239522], length 0, ParentProc [ptcpdump.345626]
00:00:00.-00243 lo curl.345650 Out IP 127.0.0.1.8000 > 127.0.0.1.58694: Flags [P.], seq 3879633870:3879634339, ack 217911310, win 512, options [nop,nop,TS val 2363239522 ecr 2363239522], length 469, ParentProc [ptcpdump.345626]
Copy link
Contributor

@coderabbitai coderabbitai bot Oct 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Negative delta timestamp in -ttt output (formatting bug).

Line 17 shows 00:00:00.-00243. With -ttt, deltas should be non-negative. Likely subtraction order/rounding issue or out-of-order event handling in delta computation.

  • Ensure delta = max(0, curr_ts - prev_ts) with correct units/rounding.
  • Verify ordering around paired Out/In loopback packets.
  • Update code and this expected fixture accordingly.

🏁 Script executed:

#!/bin/bash
# Inspect test fixture around reported line
sed -n '14,20p' testdata/format/tcp.pcapng.-ttt.-S.out.txt

# Search code for “-ttt” timestamp handling
rg -n "ttt" -C3 .

# Search code for delta/subtraction logic
rg -n "delta" -C3 .

Length of output: 159950


Clamp -ttt deltas to non-negative
testdata/format/tcp.pcapng.-ttt.-S.out.txt:17 prints “00:00:00.-00243”, but -ttt must never show negative values. Change delta computation to delta = max(0, curr_ts – prev_ts) (with correct units/rounding) and update this fixture.

🤖 Prompt for AI Agents
In testdata/format/tcp.pcapng.-ttt.-S.out.txt around line 17, the printed -ttt
delta shows "00:00:00.-00243" (negative); change the delta computation where
-ttt values are produced to clamp negatives: compute delta = max(0, curr_ts -
prev_ts) using the same time units and rounding/formatting pipeline used
elsewhere (convert timestamps to the display unit, round/truncate consistently,
then max with 0), regenerate/update this fixture line to reflect the
non-negative delta output.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot try to fix it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@coveralls
Copy link

Coverage Status

coverage: 72.764% (-0.2%) from 72.935%
when pulling 9f18ef0 on support-relative-tcp-seq
into 324649d on master.

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR implements relative TCP sequence numbers as the default behavior, addressing issue #156. The change makes TCP sequence numbers start from 1 for better readability while maintaining compatibility with absolute sequence numbers via a new flag.

  • Switches from absolute to relative TCP sequence numbers as the default output format
  • Adds a new -S flag to display absolute TCP sequence numbers when needed
  • Updates all test fixtures to reflect the new relative numbering format

Reviewed Changes

Copilot reviewed 64 out of 72 changed files in this pull request and generated no comments.

Show a summary per file
File Description
testdata/format/tls.pcap.out.txt Updated to show relative TCP sequence numbers starting from 1
testdata/format/tls.pcap.-S.out.txt New test fixture showing absolute sequence numbers with -S flag
testdata/format/tfo.pcap.out.txt Updated TCP sequence numbers to use relative format
testdata/format/tfo.pcap.-S.out.txt New test fixture for absolute sequence numbers with TFO
testdata/format/tcp.pcapng.out.txt Updated all TCP connections to show relative sequence numbers
testdata/format/tcp.pcapng.-xx.out.txt Updated hexdump output with relative sequence numbers
testdata/format/tcp.pcapng.-xx.-S.out.txt New hexdump test with absolute sequence numbers
testdata/format/tcp.pcapng.-x.out.txt Updated hex output with relative sequence numbers
testdata/format/tcp.pcapng.-x.-S.out.txt New hex test fixture with absolute sequence numbers
testdata/format/tcp.pcapng.-v.out.txt Updated verbose output with relative sequence numbers
testdata/format/tcp.pcapng.-v.-S.out.txt New verbose test with absolute sequence numbers
testdata/format/tcp.pcapng.-v.--context.process.out.txt Updated process context output with relative numbers
testdata/format/tcp.pcapng.-v.--context.process.-S.out.txt New process context test with absolute numbers
testdata/format/tcp.pcapng.-ttttt.out.txt Updated elapsed time output with relative sequence numbers
testdata/format/tcp.pcapng.-ttttt.nano.out.txt Updated nanosecond timing with relative sequence numbers
testdata/format/tcp.pcapng.-ttttt.nano.-S.out.txt New nanosecond timing test with absolute numbers
testdata/format/tcp.pcapng.-ttttt.-S.out.txt New elapsed time test with absolute sequence numbers
testdata/format/tcp.pcapng.-tttt.out.txt Updated date format output with relative sequence numbers
testdata/format/tcp.pcapng.-tttt.nano.out.txt Updated nanosecond date format with relative numbers
testdata/format/tcp.pcapng.-tttt.nano.-S.out.txt New nanosecond date test with absolute numbers
testdata/format/tcp.pcapng.-tttt.-S.out.txt New date format test with absolute sequence numbers
testdata/format/tcp.pcapng.-ttt.out.txt Updated delta time output with relative sequence numbers
testdata/format/tcp.pcapng.-ttt.nano.out.txt Updated nanosecond delta time with relative numbers
testdata/format/tcp.pcapng.-ttt.nano.-S.out.txt New nanosecond delta test with absolute numbers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support relative TCP sequence numbers

3 participants