The idea
Lab 1 opened the Ethernet frame and looked at ARP. Lab 2 moves one layer up and looks at what IP does when something goes wrong, and what happens when a datagram is too big for the link carrying it.
Phase 1 uses two everyday tools, ping and traceroute, to generate ICMP messages and read their fields directly. Phase 2 uses traceroute again, this time to generate datagrams of different sizes on purpose, so you can watch the IP header’s own bookkeeping (Identification, Flags, Fragmentation Offset) do the job of splitting a datagram and telling the receiver how to put it back together.
Where marks get lost
This page does not contain the answers
Lab 2 is assessed, submitted within two weeks of your lab session.
So what follows is what each question is testing, which topic on this site explains the concept, and how to find the evidence in your own capture. The answers are specific to your machine, your route to the destination, and the packet sizes you actually sent, and are not something a revision page could give you even if it tried.
What you need
- Wireshark, plus the
libpcaporWinPCapcapture library - A command line:
pingandtracert(Windows) ortraceroute(Linux/Unix/macOS) - On Windows, pingplotter (
http://www.pingplotter.com) for Phase 2, so you can set the probe packet size, since the built-intracertcannot change it - The textbook reference is Kurose & Ross, 8th edition: ICMP pp. 621–630, Ping p. 627, Traceroute p. 628, Echo Request/Reply p. 625, IPv4 pp. 582–596, IP higher-level protocol values p. 588
- RFC 791 for the IP specification, RFC 792 for ICMP
Aside
If you cannot capture live traffic, the lab sheet’s fallback trace files
(ICMP-ethereal-trace-1, ICMP-ethereal-trace-2 and ip-ethereal-trace-1)
are in the same wireshark-traces.zip Lab 1 used.
Phase 1 — ICMP, ping and traceroute
How it works
Two tools, one protocol
Both tools generate ICMP traffic, but they ask different questions. Ping sends a single Echo Request and waits for a single Echo Reply, and that is reachability, nothing more. Traceroute never expects an Echo Reply at all; it sends packets with steadily increasing TTL and reads the router address off each Time Exceeded reply, one per hop, until a packet finally survives long enough to reach the destination. The full mechanism for both is on ICMP — Ping and Traceroute.
Task 1 — ping
| Q | What it tests | Where to look |
|---|---|---|
| 1 | Reading source and destination addresses off an ICMP packet | Select a ping packet, expand the Internet Protocol layer, and read the Source and Destination Address fields, the same layer you expanded for HTTP in Lab 1 |
| 2 | Why ICMP has no port numbers | Expand the ICMP layer itself and compare its fields against a TCP or UDP header. Where ICMP sits in the layer stack is covered on ICMP — Ping and Traceroute |
| 3, 4 | Reading the ICMP type, code and other header fields on a request and its reply | Expand the ICMP layer of the request (Q3) and the reply (Q4). The exact field widths are not something Lecture 5 gives; Wireshark's own field list, or RFC 792, is the authority here |
Aside
ICMP — Ping and Traceroute is explicit that the lecture never gives the ICMP header’s field widths or numeric type/code values — only the message names and what triggers them. For Q3 and Q4, read those values straight off Wireshark’s own decode of the packet, or from RFC 792, rather than expecting them on that topic page.
Task 2 — traceroute
| Q | What it tests | Where to look |
|---|---|---|
| 5 | Same addressing skill as Q1, applied to a traceroute capture | Source and destination address fields of a traceroute probe packet |
| 6 | What the IP header's Protocol field would show if the probe were UDP instead of ICMP | The IP header's Protocol field on your captured probes, plus the "IP Higher-level Protocol Values" table Kurose & Ross gives on p. 588; the lab sheet points you there deliberately rather than at this site |
| 7 | Whether traceroute's own ICMP probe differs from a plain ping Echo Request | Compare the TTL field and any other header differences between a probe packet here and a ping packet from Task 1 |
| 8 | What extra information an ICMP error message carries beyond a query message | Expand an ICMP error (Time Exceeded) packet fully, then an Echo packet, and compare what each contains below the ICMP header |
| 9 | Why the last few ICMP packets in the trace differ from the error packets before them | Compare the ICMP Type field on the final replies against the Time Exceeded replies earlier in the trace, alongside the TTL of the probes that produced them |
| 10 | Reading relative hop delay from your own tracert output | Your own Command Prompt or terminal timing columns; there is no site topic for this one, it is a direct reading of your own trace |
Where marks get lost
Extra credit — do not expect this site to name the message
The extra-credit task asks you to send a UDP probe to an unusual port and capture the response. ICMP — Ping and Traceroute already tells you, in general, that ICMP has a family of error messages for exactly this kind of failure. Which one your own capture shows is the thing you are confirming, not something to look up here.
Phase 2 — IP datagrams and fragmentation
Traceroute comes back for Phase 2, this time sending probes of three sizes,
56, 2000 and 3500 bytes, so that the larger two are forced to fragment
across a typical 1500-byte Ethernet MTU.
How it works
What the header does when a datagram is too big
The IPv4 Datagram covers every field in the fixed 20-byte header. Fragmentation is the one that matters for most of Phase 2: it explains why fragmentation happens, what Identification, Flags and Fragmentation Offset each do, and the multiply-by-8 rule the offset field always needs.
Part B — reading the header fields
| Q | What it tests | Which topic explains it |
|---|---|---|
| 1 | Reading your own computer's IP address off an Echo Request | The Source Address field, covered on The IPv4 Datagram |
| 2 | The upper-layer protocol field for an ICMP-carrying datagram | The Protocol field, covered on The IPv4 Datagram |
| 3 | Computing header bytes from HLEN, and payload bytes from Total Length | The IPv4 Datagram gives the exact formula: header bytes = HLEN x 4. Payload is what is left once you subtract that from Total Length |
| 4 | Telling whether a datagram has been fragmented at all | The fragmentation-related fields of the IP header, covered on Fragmentation |
| Q | What it tests |
|---|---|
| 5 | Which IP header fields change from one datagram to the next in a series sent by the same host |
| 6 | Which fields stay constant across that same series, and why some fields *must* while others *must not* |
| 7 | The pattern in the Identification field across successive datagrams from your host |
Aside
For Q5–Q7, The IPv4 Datagram explains what each header field is for; the purpose of a field is what tells you whether it has any reason to change between datagrams. Sort the packet list by source address first, as Lab 1 had you do for the ARP questions, so the series sits together, then compare the IP headers of consecutive packets field by field.
| Q | What it tests |
|---|---|
| 8 | Reading the Identification and TTL fields on the Time Exceeded replies from your first-hop router |
| 9 | Whether those two fields stay the same across every reply from that router, and why |
Fragmentation analysis
Sort the packet list back to time order for this part.
| Q | What it tests | Where to look |
|---|---|---|
| 10 | Whether the 2000-byte probe was actually fragmented | The fragmentation-related IP header fields of the first packet after your 2000-byte probe, using Fragmentation |
| 11 | Reading the first fragment: what marks it as fragmented, what marks it as the *first* piece, and its total length | The Flags and Fragmentation Offset fields and Total Length. Fragmentation explains what each one means |
| 12 | Reading the second fragment: what marks it as not-first, and whether more fragments follow | The same fields as Q11, read on the next fragment |
| 13 | Which header fields differ between the first and second fragment | Put the two fragments' IP headers side by side in Wireshark and go through every field |
| 14, 15 | The same fragmentation reading applied to the larger 3500-byte probe, including how many pieces it took | Repeat the Q10–Q13 method on the 3500-byte series; the mechanism is identical, only the numbers differ |
Where marks get lost
The offset field is not a byte count
Every one of Q11–Q15 turns on the same trap Fragmentation calls out directly: the value stored in the Fragmentation Offset field is not the byte position itself, it is that position divided by 8. Multiply the field’s value by 8 before you write down where a fragment’s payload actually starts.
What the marker wants
The Lab 2 sheet points at the same marking scheme document as Lab 1:
| Criterion | Marks | What it covers |
|---|---|---|
| Presentation and format | 1 | Writing clarity, grammar, report structure, template adherence, page limit |
| Experiments (Phase 1 and 2) | 7 | Answer quality, understanding of concepts, completeness of evidence |
Report requirements, from the sheet:
- Maximum 7 pages, title page included
- Due within two weeks of your lab session
- Follow the Canvas template: a two-sentence introduction, Phase 1 answers with evidence, Phase 2 answers with evidence, appendix for figures
- Every answer needs evidence: captures and screenshots, annotated to explain what they show
- Print only the minimum packet detail needed for each question
- Answering the numbered questions during the lab session is how you learn the material. The sheet is explicit that they do not all have to appear in the final report, which instead asks for your overall learning experience and main results within the page limit
In the exam
As in Lab 1, the rubric rewards connecting what you captured to what the lectures taught, not just a correct-looking number.
For the fragmentation questions especially, do not just report the Fragmentation Offset value you read. Show the multiply-by-8 step that turns it into a byte position, and say which field (MF, or a shared Identification value) is what told you two packets belong to the same original datagram. That reasoning is what separates a pass-level answer from a distinction-level one.