The Corelatus Blog
E1/T1 and SDH/SONET telecommunications

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:

  1. Replaying a bit-exact recording of an E1 timeslot.
  2. Reading SS7 packets from a .pcap file, re-create layer 2.
  3. 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:

data flow of PCap packets

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 trucated 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