Reading SS7 packets from a PCap file and replaying
Posted March 25th 2019
This is the second in a three-part series about different ways to replay signalling on an E1/T1 line in the lab. The three parts are:
- Replaying a bit-exact recording of an E1 timeslot.
- Reading SS7 packets from a .pcap file, re-create layer 2.
- Creating SS7 packets from scratch.
This post is about the second approach. It's particularly useful because we can use this technique to convert a SIGTRAN capture into an SS7 capture with MTP-3 and MTP-2. It's also satisfying because we can take packets full circle—we can play the packets from a PCap file and make a new PCap file with the same packets after they've passed through an E1 line. It assumes you have an E1 cable between P5 and P6, as illustrated in the previous post on this subject.
Approach #2: Read packets from a PCap file, replay on E1
Here's what the data-flow looks like:
1. The 'replay_mtp2' program reads SS7 packets from a PCap file.
2. The Corelatus box does bit-stuffing and inserts flags and FISUs.
3. After the signal goes out through an E1 cable and back in again,
the Corelatus box recovers the SS7 packets.
4. 'save_to_pcap' saves the packets in PCapNG format.
5. Wireshark decodes MTP-3 and higher SS7 layers to display the packets.
The API command 'fr_layer' does step 2, it's described in the API manual. Here's what we do if we're using the C sample code:
./enable 172.16.1.10 pcm5A
./enable 172.16.1.10 pcm6A
./replay_mtp2 gth30 isup_load_gen.pcapng 5A 16
The PCap file with the signalling was made by a load generator. We can capture the signalling and make a new PCap file with the same packets, like this, in a separate window:
./save_to_pcap -l 172.16.1.10 6A 16 gth.pcapng
monitoring 6A:16 interface_id=0
capturing packets, press ^C to abort
saving to file gth.pcapng_00001
Fri Mar 15 17:17:34 2019 signalling job m2mo0 changed state to 'in service'
Fri Mar 15 17:17:48 2019 signalling job m2mo0 changed state to 'no signal units'
^C
We can view both files in Wireshark and compare them. They'll contain the same packets, but with different relative timing, since 'replay_mtp2' just replays the packets as fast as possible.
Replaying other files
Wireshark has a collection of SS7 capture files, with all sorts of contents. They're all in the old 'classic' PCap format, so we have to convert them.
isup.cap
This file has three challenges. First, it's in the old PCap format. Second, the transport is SIGTRAN, so we have to extract the MTP-3 packets. Third, it uses a pre-RFC version of M3UA, so it's hard to see where the MTP-3 packets are. By inspecting the hex dump, we can see that MTP-3 starts 74 bytes into each packet, so we can use 'editcap' to make a new PCap file and then play it:
> editcap -L -C 74 -T mtp3 isup.cap isup_fixed.pcap
> ./replay_ss7 172.16.1.10 isup_fixed.pcap 5A 16
Found link type 141 in capture file
packet bytes replayed: 158. Sleeping to drain buffers.
Here's what the contents look like after a round-trip through the E1:
>tshark -r mml.pcap_00001
1 0.000 11522 -> ISUP(ITU) 77 IAM (CIC 213)
2 0.003 12163 -> 11522 ISUP(ITU) 21 CFN (CIC 213)
3 0.005 12163 -> 11522 ISUP(ITU) 17 ACM (CIC 213)
4 0.007 12163 -> 11522 ISUP(ITU) 17 ANM (CIC 213)
5 0.010 11522 -> 12163 ISUP(ITU) 21 REL (CIC 213)
6 0.012 12163 -> 11522 ISUP(ITU) 17 RLC (CIC 213)
7 0.013 -> MTP2 5 FISU
If you look at the output file more closely, you can see that the MTP-2 fields are faked; the sequence numbers don't increment. That's because the original data didn't have any sequence numbers in it. If we wanted to, we could extend 'replay_ss7' to generate realistic sequence numbers.
camel.pcap and camel2.pcap
These are more classic PCap files with SIGTRAN, but again we can convert them:
> editcap -L -C 74 -T mtp3 camel.pcap camel_fixed.pcap
> ./replay_ss7 172.16.1.10 camel_fixed.pcap 5A 16
Found link type 141 in capture file
packet bytes replayed: 559. Sleeping to drain buffers.
Viewing it in Wireshark requires "Signalling Connection Control Part"/"Protocol Preferences"/"Default Payload" to be set to TCAP. Same thing in 'tshark':
>tshark -o "sccp.default_payload: tcap" -r mml.pcap_00001
1 0.000 10 -> 100 Camel-v2 165 invoke initialDP
2 0.027 100 -> 10 Camel-v2 217 invoke requestReportBCSMEvent invoke applyCharging invoke continue
3 0.034 10 -> 100 TCAP 57 Continue otid(06f7) dtid(13b8)
4 0.045 10 -> 100 TCAP 85 Continue otid(ec0f) dtid(0d7c)
5 0.051 100 -> 10 TCAP 45 End dtid(ec0f)
6 0.052 -> MTP2 5 FISU
gsm_map_with_ussd_string.pcap
Same encoding as the 'camel' files. Contents:
>tshark -r mml*
1 0.000 1041 -> 8744 GSM MAP 149 invoke processUnstructuredSS-Request
ansi_map_ota.pcap
editcap -L -C 82 -T mtp3 ansi_map_ota.pcap ansi_fixed.pcap
...
>tshark -r mml* // after a round-trip through E1:
1 0.000 18 -> 10 ANSI MAP 81 SMS Delivery Point to Point Invoke
2 0.009 10 -> 18 ANSI MAP 69 SMS Delivery Point to Point ReturnResult
3 0.020 18 -> 10 ANSI MAP 85 SMS Delivery Point to Point Invoke
4 0.026 10 -> 18 ANSI MAP 45 SMS Delivery Point to Point ReturnResult
5 0.036 18 -> 10 IS-683 81 SMS Delivery Point to Point Invoke
japan_tcap_over_m2pa.pcap
This file uses the Japanese variant of MTP-3. We need to tell Wireshark about that in the MTP-3 preferences:
editcap -L -C 79 -T mtp3 japan_tcap_over_m2pa.pcap japan_fixed.pcap 2 4 6
...
> tshark -o "mtp3.heuristic_standard: TRUE" -r /tmp/mml.pcap*
1 0.000 3003 -> 2730 SCCP (Japan) 32 SSA
2 0.009 2730 -> 3003 TCAP 72 Begin otid(18250001)
3 0.016 3003 -> 2730 GSM MAP 56 returnResultLast Unknown GSM-MAP opcode
ansi_tcap_over_itu_sccp_over_mtp3_over_mtp2.pcap
This is the only SS7 capture on the Wireshark Sample Captures page which actually captured MTP-2. The hardware that captured it didn't save the FCS (Frame Check Sequence, a 16-bit CRC), so we need to tell 'replay_ss7' about that, otherwise the last two bytes of each packet will be chopped off:
tshark -r ansi_tcap_over_itu_sccp_over_mtp3_over_mtp2.pcap ansi_fixed.pcap
./replay_ss7 -f 172.16.2.8 ansi_fixed.pcap 5A 16
...
> tshark -r /tmp/mml.pcap*
1 0.000 9283 -> 9444 ANSI MAP 150 Origination Request Invoke
Skipped files
I didn't bother with a few of the sample captures in the Wireshark wiki.
'bicc.cap' only contains one packet and it's not SS7.
'ansi_map_win.pcap' contains truncated packets.
'packlog-example.cap' contains a hex dump of a few packets,
in a pinch we could convert it with 'text2pcap'.
Permalink | Tags: GTH, telecom-signalling