Wireshark lab: reading real telecom captures

Theory becomes skill only when you read real traffic. This module gives seven labs on public sample captures. Every result shown was produced by actually running tshark (Wireshark 4.6.9) on the file; each lab has questions with collapsible solutions — try first, then open the solution.

Privacy note. Some sample captures contain real-looking numbers and names. In this module phone numbers, IMSI-like values and account names are masked (shown as …). Do the same when you share your own captures.

0. Setup and safety

Tools

Safety rules (follow them)

1. Download captures only from sources you trust (the Wireshark wiki is the usual one) and keep them in a separate folder; never run anything from that folder.
2. Check before opening: file name.pcap should say pcap capture file; the sizes in this lab are small (258 B to 111 KB).
3. Keep Wireshark updated. Protocol dissectors have had security bugs; a hostile capture could exploit an old version. Prefer tshark for untrusted files, and do not enable Lua scripts or plug-ins you do not know.
4. Capture only where you are authorised. Capturing other people's traffic without permission can be illegal. Telecom traces contain personal data (numbers, IMSI, locations) — handle them under GDPR (Module 22).

tshark cheat sheet

Display filter vs capture filter. A capture filter (tcp port 2775) limits what is recorded and uses a different, simpler syntax. A display filter (smpp.command_id == 4) only hides packets already recorded. In the GUI: Statistics → Protocol Hierarchy / Conversations / Flow Graph, Telephony → VoIP Calls / SIP Flows / RTP Streams, Analyze → Decode As… / Expert Information, right-click → Follow → Stream.

Lab 1 — An SMPP session (A2P SMS submission)

File: smpp.cap (1.4 KB) · Layers: Ethernet / IP / TCP / SMPP · Module 1, 23

Run:

tshark -n -r smpp.cap
tshark -n -r smpp.cap -Y smpp -T fields -e frame.number -e smpp.command_id -e smpp.command_status -e smpp.sequence_number

What you should see (17 packets, 8 are SMPP):

Questions

1. Which TCP port does the SMSC listen on, and why does Wireshark still decode SMPP?
2. How are a request and its response linked in SMPP?
3. What text was sent? (Convert the hex.)
4. Did this capture prove that the message reached the phone?
5. After how many seconds into the session was the message submitted?

Lab 2 — A MAP USSD request over SIGTRAN

File: gsm_map_with_ussd_string.pcap (258 B, one packet) · Layers: IP / SCTP / M2UA / MTP3 / SCCP / TCAP / GSM MAP · Modules 3, 4, 23

Run:

tshark -n -r gsm_map_with_ussd_string.pcap -q -z io,phs
tshark -n -r gsm_map_with_ussd_string.pcap -V | less

What you should see (decoded values):

Questions

1. Draw the protocol stack from the bottom up.
2. Which SSNs are used, and what do they mean?
3. Which MAP operation is this, and what is its opcode?
4. Why does the USSD string need decoding?
5. Which identifier tells the receiver which MAP "dialogue type" this is?

Lab 3 — A CAMEL prepaid call (CAP over TCAP/SCCP/MTP3/M2UA)

File: camel.pcap (1 KB) · Layers: IP / SCTP / M2UA / MTP3 / SCCP / TCAP / CAP · Modules 4, 29

Wireshark does not know the proprietary SSNs, so tell it which layer to use:

tshark -n -r camel.pcap -d sccp.ssn==200,tcap -d sccp.ssn==152,tcap
tshark -n -r camel.pcap -d sccp.ssn==200,tcap -d sccp.ssn==152,tcap -V | grep -i -E "opcode|serviceKey|eventTypeBCSM|application-context"

What you should see (5 packets):

Application context: CAP-v2-gsmSSF-to-gsmSCF-AC (0.4.0.0.1.0.50.1). The armed events in frame 2 are routeSelectFailure (4), oCalledPartyBusy (5), oNoAnswer (6), oAnswer (7), oDisconnect (9, two legs) and oAbandon (10).

Questions

1. Which node is the SSP (switch) and which is the SCP (service control)?
2. What did the switch do at call setup and what did the SCP answer?
3. Why did the SCP ask for oAnswer and oDisconnect events?
4. Roughly how long did the call last?
5. Where in this flow does charging start?

Lab 4 — A 3G Iu-CS mobile-originated call (RANAP / DTAP / RTP)

File: Mobile-Originating-Call(AMR).pcap (28 KB, 299 packets) · Layers: IP / SCTP / M3UA / SCCP / RANAP / DTAP (MM, CC) and UDP / RTP · Modules 3, 9, 10, 28

Run:

tshark -n -r Mobile-Originating-Call\(AMR\).pcap -q -z io,phs
tshark -n -r Mobile-Originating-Call\(AMR\).pcap -Y 'ranap || sccp'
tshark -n -r Mobile-Originating-Call\(AMR\).pcap -q -z rtp,streams
tshark -n -r Mobile-Originating-Call\(AMR\).pcap -Y 'rtp && ip.src==50.2.1.0' -T fields -e udp.length | sort | uniq -c

Signalling timeline (point codes 4096 = RNC side, 8192 = core side; M3UA over SCTP port 2905):

Voice (RTP): two streams (50.2.1.0:50000 ⇄ 50.3.1.0:40000), 127 packets each, payload type 96 (a dynamic type negotiated elsewhere, here AMR), no loss.

Questions

1. Name the three signalling "planes" visible: radio network (RANAP), call control and mobility.
2. Which message corresponds to "the call is answered" and how long did the conversation last?
3. What quality-of-service class and speed does the RAB request, and what does 12.2 kbit/s mean?
4. The RTP packet count is much lower than 10.5 s / 20 ms ≈ 520. Why? (Hint: look at udp.length values.)
5. What is the role of SCCP connection setup/release here?

Lab 5 — SIP registration, authentication and failed calls

File: aaa.pcap (111 KB, 691 packets; 81 SIP) · Layers: UDP / SIP (+ SDP) / RTP · Modules 9, 23

The capture is a real softphone with a registration problem and several failed calls (mixed with DNS/NetBIOS noise).

Run:

tshark -n -r aaa.pcap -Y sip
tshark -n -r aaa.pcap -Y sip -T fields -e sip.Method -e sip.Status-Code | sort | uniq -c | sort -rn
tshark -n -r aaa.pcap -q -z rtp,streams

Counts of SIP messages: 18 REGISTER · 14 × 401 · 11 INVITE · 11 CANCEL · 7 ACK · 7 × 100 Trying · 3 × 407 · 3 × 403 · 3 × 200 OK · 2 × 408 · 1 × 183 · 1 × 480.

Key episodes:

Questions

1. Why does the first REGISTER always get 401?
2. What is the difference between 401 and 407?
3. The INVITE at 508 s was sent three times within 1.5 s. Why, and what timer explains the gaps?
4. Why does the same pattern (0.5, 1, 2, 4 s) appear for the CANCELs?
5. What does a 183 with SDP followed by RTP and then a 480 tell you?
6. Give two possible causes of the repeated "403 Wrong password".

Lab 6 — An SCTP association (the transport under SIGTRAN, S1AP, NGAP, Diameter)

File: sctp-test.cap (69 KB, 74 packets) · Layers: IP / SCTP · Modules 4, 11, 12, 23

Run:

tshark -n -r sctp-test.cap | head -14
tshark -n -r sctp-test.cap -T fields -e frame.number -e sctp.chunk_type -e sctp.verification_tag | head -8

What you should see:

Both ports are 7 (echo test); in real telecom the ports are 2905 (M3UA), 36412 (S1AP), 38412 (NGAP), 3868 (Diameter).

Questions

1. Why does SCTP need a four-way handshake and what does the cookie protect against?
2. What is the verification tag for?
3. What do TSN and SACK do?
4. Name two reasons telecom signalling prefers SCTP over TCP.

Lab 7 — A GSM location update on the Abis interface

File: abis-accept-network.pcap (4.9 KB, 85 frames) · Layers: LAPD / A-bis OML & RSL / DTAP (MM, SMS) · Modules 2, 10, 28

Tell Wireshark to use GSM SAPI values for LAPD:

tshark -n -r abis-accept-network.pcap -o lapd.use_gsm_sapi_values:TRUE | grep -i -E "Location|Identity|TMSI|SMS|RELease|IMMEDIATE"

What you should see (selected frames):

Questions

1. Which procedure from Module 28 does frames 72–78 correspond to, and which network nodes behind the BSC would be involved?
2. Why does the network ask for identities twice?
3. How can an SMS be delivered right after the location update?
4. Where does the TMSI come from and why is it used?

8. A reading method that works on any capture

1. Hierarchy first: -z io,phs tells you which protocols are present and what is missing (expected layers absent often means a decode problem, as in the ISUP draft‑6 note below).
2. Conversations: who talks to whom, how many packets and bytes, in which direction.
3. Timeline: read messages in time order and write the story in plain words (like the tables above).
4. Identify the procedure: is it registration, call setup, handover, session, SMS?
5. Find the first failure: the first error response, reject cause or timeout (Module 23 checklist).
6. Check the timers: compare gaps with known timers (SIP T1/T2, TCP/SCTP retransmission, keep-alives).
7. Cross-check identities: numbers, point codes, TEIDs, Call-IDs.
8. Use the lookup tool: the Calculators & lookup page translates cause and error codes from verified tables.

A decoding trap I met while writing this lab

isup.cap (also on the sample page) is encoded with an old "draft‑6" M3UA that current Wireshark releases no longer decode (the parameters appear as unknown). When a capture shows only the outer layers, check the Wireshark wiki note for that file and the protocol preferences before assuming the traffic is wrong.

9. Build your own practice

• Replay your own lab: set up an open-source core (Open5GS, free5GC, Kamailio) and capture attach, registration and SIP calls — Module 23 lists the tools.
• Filters to memorise: sip, smpp, diameter, gtpv2, s1ap, ngap, pfcp, http2, sctp, m3ua, isup, gsm_map.
• Always mask numbers before sharing a capture, and delete captures when you no longer need them.

Remember this: a capture is a story with timestamps. Learn the handful of messages of each procedure, read the first error, and compare gaps with the protocol's timers — most "mysteries" turn out to be a challenge not answered, a timer expiring, or an identity in the wrong format.