Measure 6LoWPAN addresses and the fragment gate

Compare the address scope, compressed frame budget and delivery of a 52-byte report and a 300-byte diagnostic packet.

Packet Pete — I check the next hop and the reply before trusting a route., your practice guide

Packet Pete — I check the next hop and the reply before trusting a route.
Predict the reading, then compare it with the measurement.

Contiki-NG Cooja

Third party Tool

Tier 2 · Free simulator · install required · No account

Version tested: Contiki-NG release/v4.9 c20b12cd, Cooja 4.8 (2022071901), Temurin 17.0.20.1, image sha256:b14d5afb0a2a852d9e72bbed607ead03f6ccc5f4d4dee44f0799110be2f4b609. Date: 2026-09-10.

Download the complete lab packet and follow README.md to run it in the free simulator.

Download the setup and run guide

Get the lab files

Download the complete packet for the simulation and its firmware, or download individual files for inspection. README.md gives the setup and run commands.

Steps

Screens captured against Contiki-NG Cooja Contiki-NG release/v4.9 c20b12cd, Cooja 4.8 (2022071901), Temurin 17.0.20.1, image sha256:b14d5afb0a2a852d9e72bbed607ead03f6ccc5f4d4dee44f0799110be2f4b609 on 2026-09-10; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    Run the primary CSC until 125 s. Filter Mote output for ^-- (fd00|fe80)::202|^-- Prefix:. Record the receiver addresses and root prefix.
    You will see
    Input: seed-1 52-byte CSC; read receiver 2 and root 1 after 50 s. Observed: "50549000 ID:2 -- fd00::202:2:2:2" Observed: "50549000 ID:2 -- fe80::202:2:2:2" Observed: "52549000 ID:1 -- Prefix: fd00::/64" Expected: one fd00::/64 global address and one fe80:: link-local address on receiver 2.
    Why it matters
    Meaning: The advertised prefix supplies the routed lab address; fe80:: is local to the link. Limit: Addresses alone do not prove packet delivery or Internet reachability.

  2. Step 2

    Do
    In Cooja's Mote output window, filter for output: header len 56|uncompression: UDP length: 60. Compare the sender’s frame budget with the receiver’s rebuilt UDP header.
    You will see
    Input: send the 52-byte report; compare the 6LoWPAN sender and receiver lines. Observed: "80549000 ID:1 [INFO: 6LoWPAN ] output: header len 56 -> 15, total len 108 -> 67, MAC max payload 104, frag_needed 0" Observed: "80558912 ID:2 [DBG : 6LoWPAN ] uncompression: UDP length: 60 (ext: 8) ip_len: 0 udp_len: 60" Expected: 108 bytes before compression, 67 after, below the 104-byte MAC payload; no fragment.
    Why it matters
    Meaning: The run saved 41 header bytes and rebuilt a UDP length of 60 at receiver 2. Limit: This saving applies to this header context and route, not every IPv6 packet.

  3. Step 3

    Do
    In Cooja's Mote output window, filter for ^Data .*length 52|^-- MOP:. Match the accepted length to the original 52-byte report.
    You will see
    Input: check the 52-byte report at receiver 2 and root routing mode. Observed: "52549000 ID:1 -- MOP: Non-storing" Observed: "80558912 ID:2 Data 1 received length 52" Expected: one delivered application payload of 52 bytes in non-storing RPL mode.
    Why it matters
    Meaning: The receiver line confirms that the compressed packet became one application delivery. Limit: The payload is a size fixture, not a decoded environmental sensor report.

  4. Step 4

    Do
    From Cooja's File menu, open cooja-6lowpan-addressing-large.csc from the packet. After it stops, filter for output: header len 56|output: fragmentation needed.
    You will see
    Input: run the 300-byte large CSC with the same addresses and radio layout. Observed: "80549000 ID:1 [INFO: 6LoWPAN ] output: header len 56 -> 15, total len 356 -> 315, MAC max payload 104, frag_needed 1" Observed: "80549000 ID:1 [INFO: 6LoWPAN ] output: fragmentation needed. fragments: 4, free queuebufs: 64" Expected: 356 bytes before compression, 315 after, requiring four fragments.
    Why it matters
    Meaning: The longer application payload crosses the 104-byte MAC frame budget. Limit: Fragment count is measured for this packet and simulated link configuration.

  5. Step 5

    Do
    In Cooja's Mote output window, in the large run, type this regular expression exactly as shown in the filter: input: fragment \(tag|^Data .*length 300. Keep the backslash: it matches a literal opening parenthesis. Compare the fragment rows with the accepted payload.
    You will see
    Input: read all receiver 2 fragment rows in the 300-byte run. Observed: "80559936 ID:2 [INFO: 6LoWPAN ] input: fragment (tag 0, payload 80, offset 0) -- 99 19" Observed: "80587000 ID:2 [INFO: 6LoWPAN ] input: fragment (tag 0, payload 96, offset 136) -- 101 5" Observed: "80612000 ID:2 [INFO: 6LoWPAN ] input: fragment (tag 0, payload 96, offset 232) -- 101 5" Observed: "80623824 ID:2 [INFO: 6LoWPAN ] input: fragment (tag 0, payload 28, offset 328) -- 33 5" Observed: "80623824 ID:2 Data 1 received length 300" Expected: offsets 0, 136, 232 and 328, then one 300-byte delivery.
    Why it matters
    Meaning: The four fragments reassemble into one datagram before the application receives it. Limit: Each fragment is not a separate application report.

  6. Step 6

    Do
    From Cooja's File menu, open cooja-6lowpan-addressing-loss.csc. In the filter, type this regular expression exactly as shown: received first element|input: fragment \(tag|^Data . Keep the backslash: it matches a literal opening parenthesis. Check expected-loss-output.txt and write the README release decision.
    You will see
    Input: run the loss CSC; move receiver 2 after its first fragment. Observed: "80559936 ID:2 [INFO: 6LoWPAN ] input: received first element of a fragmented packet (tag 0, len 356)" Observed: "FAULT receiver moved out of range after first fragment at_us=80559936" Observed: "80559936 ID:2 [INFO: 6LoWPAN ] input: fragment (tag 0, payload 80, offset 0) -- 99 19" Expected: one received fragment, zero 300-byte Data deliveries through 125 s.
    Why it matters
    Meaning: The fault interrupts reassembly even though the sender emitted four fragments. Limit: TEST OK here asserts the intended loss; it is not a successful report delivery.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. A 6LoWPAN design promises that every packet will compress to the same tiny header size. What evidence should a reviewer request?

    Return to the chapter’s knowledge check

  2. Which release evidence best proves an IPv6 and 6LoWPAN deployment is ready for constrained IoT traffic?

    Return to the chapter’s knowledge check

Return to IPv6 and 6LoWPAN for IoT · Browse Labs