Gary VirkIT Specialist
← All work

04 Networking · TShark · Troubleshooting

Four packet captures, four network faults

Four short cases cover DNS failure, a TCP reset, duplicate-IP ARP, and path MTU, each with a post-change capture.

Issue
Which small set of frames explains the symptom, and what separate capture shows that the condition changed?
Decisive evidence
Each case links the user’s symptom to the relevant packet fields and a new capture taken after the change.E01
Result
Each note identifies the frames that explain the symptom and keeps the post-change capture separate.
Boundary
These are controlled packet cases in an isolated ARM64 lab.Full limit
Completion
Complete within stated scope
Execution
Isolated ARM64 packet lab
Review
Field extraction and manifest review
Evidence
Selected evidence on this page
  • TShark
  • tcpdump
  • Capinfos
  • Python

Project scope

What was built and checked.

Project record: The synthetic cases, protocol fields that explain each symptom, failure and post-change captures, and the support interpretation.

Method

Start with the symptom, apply one relevant filter, then capture the post-change result.

  1. 01

    State where the capture was taken and what the user observed.

  2. 02

    Select only the protocol fields needed to test the suspected fault.

  3. 03

    Record the exact change outside the capture.

  4. 04

    Use a separate post-change capture to confirm the new result.

Four notes

Short records for four different symptoms.

DNS name failure
Symptom
The service could not be opened by name.
Evidence
The DNS response returned NXDOMAIN for the requested record.
Post-change
The post-change capture returned the expected A record.
Limit
This note does not identify why the DNS record was wrong.
TCP reset
Symptom
The client reached the host, but the TCP connection was refused immediately.
Evidence
The service address returned a TCP reset in response to the connection attempt.
Post-change
After the listener started, the separate post-change capture completed the handshake and carried the test payload.
Limit
The capture proves transport behavior, not the application configuration change.
Duplicate-IP ARP
Symptom
Connectivity changed between two devices using the same address.
Evidence
ARP replies associated one IPv4 address with two different MAC addresses.
Post-change
The post-change capture showed one remaining owner.
Limit
The case uses synthetic devices and does not claim switch-level remediation.
Path MTU
Symptom
Small traffic worked while a larger payload failed.
Evidence
ICMP type 3, code 4 reported that fragmentation was needed for the path.
Post-change
The post-change capture delivered the same test payload without that response.
Limit
The capture identifies the path symptom, not every possible MTU cause.

Evidence from the lab

The checks used to reach the conclusion.

Selected outputs from the lab. Sensitive and unnecessary details are omitted.

Failure     : rcode 3, NXDOMAIN
Post-change : rcode 0, A 198.51.100.11
E01 · Derived from captured lab outputDNS failure and retestThe failure response returns NXDOMAIN. A separate post-change capture returns a successful response and the expected documentation address.
View artifact Back to C01 
Failure     : reset frame present
Post-change : zero resets, echo verified
E02 · Derived from captured lab outputTCP reset and retestThe failure capture contains a server-side reset. The post-change capture has no reset and carries the test payload in both directions.
View artifact Back to C01 
Failure owners     : 2
Post-change owners : 1
E03 · Derived from captured lab outputDuplicate-IP ARP and retestThe failure record associates one IPv4 address with two hardware addresses. The post-change record shows one remaining owner.
View artifact Back to C01
Full evidence archive2 additional artifacts
Failure     : ICMP type 3, code 4, MTU 1200
Post-change : same DF payload delivered
E04 · Derived from captured lab outputPath MTU failure and retestThe failure record contains ICMP type 3, code 4 with a next-hop MTU. The same test payload is delivered in the post-change capture.
View artifact Back to C01 
TShark / Capinfos : Wireshark 4.6.7
Arguments          : sanitized
Exit status        : 0
E05 · Derived from captured lab outputAnalyzer provenanceThis shared analyzer record covers the four cases on this page and one DHCP validation published separately. It lists tool versions, selected fields, sanitized arguments, exit status, and output digests.
View artifact

Result and limits

What changed, and what this lab does not prove.

Result

The packet fields distinguish name-resolution failure, a refused TCP connection, duplicate-IP ownership, and path-MTU failure. Each case includes a separate post-change capture.

Limit

These are controlled packet cases in an isolated ARM64 lab. Public downloads are sanitized validation records derived from private captures. They do not claim production monitoring or broad incident response.

Claims and evidence

What the evidence supports.

Each case links the user’s symptom to the relevant packet fields and a new capture taken after the change.

The cases use owned lab endpoints and documentation addresses; raw packet captures remain private.

EvidenceE01E02E03E04