A notebook for working through network problems, one capture at a time. Pick a short exercise, inspect the evidence, and make the call. The original captures and deeper field notes are here when you want to go further.
Start with what the packets show.
Then work out what you still need to know.
| No. | Time | Source | Destination | Protocol | Info |
|---|
The exercises above use synthetic teaching traces. These files are Dustin's original published captures, recovered from the LAB-Files repository. Their contents were checked with TShark on September 14, 2026. The filenames do not always describe what the packets prove.
Duplicate-ARP.pcap contains three requests and three replies. All replies advertise the same gateway IP with the same sender MAC. This file alone does not demonstrate a duplicate address.
Try it: filter on arp. Compare the sender IP and MAC across all six frames. Explain what extra evidence would establish a conflict.
RADIUS-Accept-EAPTLS.pcap contains two successful exchanges: 18 Access-Requests, 16 Access-Challenges and 2 Access-Accepts. There are no Access-Reject packets.
Try it: filter on radius. Follow the first exchange through original frames 968 to 1028. Pair response identifiers with their requests. What does the challenge mean?
Repeat-Radisu.pcap contains nine Access-Requests and no RADIUS replies. Identifiers 69, 70 and 71 each appear three times.
Try it: compare request timing, identifiers and packet contents. State what a second capture point or server log would add. Missing replies here do not prove a wrong shared secret.
Open original capture on GitHub ↗The two RADIUS files also contain unrelated network traffic. This page links to the existing repository rather than republishing the complete captures as new downloads. Review and minimize them before a new public release. The synthetic lesson downloads remain plain text, not PCAP files.
This is the screenshot from the original repository, showing a successful EAP-TLS exchange ending in Access-Accept. Its displayed numbering is not the original full-capture frame numbering above. It is not evidence for the rejection exercise.
Original repository and attribution ↗ · Original MIT license
These are the original profile, column and filter animations. Open a tutorial to load it. Their interface reflects the version used when they were recorded; menu placement may differ today.
Keep a known column layout and saved filters for the task. Give the profile a clear name and keep a general profile available.
Current profile guide ↗For RADIUS, start with packet number, time, source, destination, code and identifier. Add radius.User_Name or radius.Calling_Station_Id when present and relevant. An empty cell can mean the attribute was not in that packet.
RADIUS field reference ↗Save frequently used display filters. A display filter hides rows from view; it does not remove those packets from the original capture file. Capture filters are a separate mechanism.
Current display-filter guide ↗| Question | Display filter | Read it correctly |
|---|---|---|
| Traffic involving an IPv4 address | ip.addr == 192.0.2.10 | Source or destination IPv4 address. IPv6 uses different fields. |
| Who is advertising this IPv4 address? | arp.src.proto_ipv4 == 192.0.2.1 | Compare sender MACs and operational context. A change is not automatically an unintended conflict. |
| Initial TCP connection requests | tcp.flags.syn == 1 && tcp.flags.ack == 0 | Excludes SYN-ACK replies. Does not establish why a reply is absent. |
| Traffic on TCP port 443 | tcp.port == 443 | Selects a port. Does not prove HTTPS or show decrypted application data. |
| IPv4 packet too large for the next hop | icmp.type == 3 && icmp.code == 4 | Fragmentation Needed for IPv4. Check the quoted packet and reported MTU. |
| IPv4 fragments | ip.flags.mf == 1 || ip.frag_offset > 0 | Includes the final fragment, which may have MF cleared. |
| DNS name errors | dns.flags.response == 1 && dns.flags.rcode == 3 | NXDOMAIN responses. NOERROR with an empty answer is a different case. |
| RADIUS acceptance or rejection | radius.code == 2 || radius.code == 3 | Code 2 accepts; code 3 rejects. Code 11 is a challenge, not a failure. |
| TCP analysis notes | tcp.analysis.flags | Includes multiple analyzer observations. Capture loss, reordering and offload can affect interpretation. |
| A gap between TCP packets | tcp.time_delta > 0.2 | A time gap, not a direct RTT or latency measurement. Inspect request/response context. |
These are corrected field notes for the original eight detail topics. They are not eight recovered packet captures. The old detail pages had screenshot placeholders. Use the rejecting endpoint's logs and policy alongside the capture.
Check that an eligible client certificate and its private key are accessible to the supplicant. Confirm the authentication profile and certificate selection rules. On the server, check whether a certificate was requested and received.
An empty certificate message may help when visible, but handshake details depend on TLS version and decryption context. A failed attempt alone does not prove the certificate is missing.
Check both NotBefore and NotAfter. For validation of the client certificate, the authenticating server's clock matters. Also check endpoint clock synchronization because each side can perform its own validation.
Confirm the server's reason, renew or re-enroll through the intended CA process, and test certificate selection after renewal. “Not yet valid” and “expired” are different conditions.
Check the server's intended trust anchors and the intermediate chain. A valid signature does not by itself establish trust. Confirm the certificate maps to an identity the server policy allows.
Supply the required intermediates and trust configuration through the managed certificate process. Do not solve this by disabling validation or trusting an arbitrary presented certificate.
Check the configured server identity, intended CA trust and chain on the supplicant. A certificate from a public CA is not automatically acceptable for your EAP deployment.
Use the expected CA and server-name restrictions in the managed profile. Confirm which side emitted the alert and inspect its log. Do not accept an unexpected server identity just to make login work.
Inspect Key Usage, Extended Key Usage and the EAP implementation's requirements. Client Authentication uses OID 1.3.6.1.5.5.7.3.2; Server Authentication uses 1.3.6.1.5.5.7.3.1.
Reissue using the correct template when the certificate and policy do not match. Missing EKU is not universally identical to the wrong EKU across all validators. Keep validation enabled and consult the actual server or supplicant rules.
A confirmed revoked status differs from an unavailable responder, stale CRL or failed network lookup. Inspect the validator's log and configured behavior.
For an actually revoked certificate, investigate the reason and replace it through the CA process. For a lookup failure, check access, freshness and policy. Do not collapse both conditions into “certificate revoked.”
Compare offered and supported versions, cipher suites and signature algorithms. If there is no acceptable combination, negotiation can fail before a successful ServerHello selection.
Review both endpoint policies and supported software versions. Update the incompatible component or policy deliberately; avoid enabling obsolete cryptography as a default workaround.
Capture both ends of the tunnel. Compare direction, usable MTU, DF behavior, ICMP errors and fragments. Separate EAP-TLS fragmentation from IP fragmentation.
TCP MSS does not resize UDP RADIUS traffic. A server's large certificate exchange can fail even when a smaller request arrives. Confirm the actual transport and apply its supported fragmentation or sizing controls.
Protocol references: EAP-TLS / RFC 5216, EAP-TLS with TLS 1.3 / RFC 9190, Certificate validation / RFC 5280, RADIUS / RFC 2865.