Decoding random data

Posted March 13th 2015

If you were to feed a timeslot random data and try to decode that as though it were MTP-2, how long would it take until you get a valid packet?

(Quick answer: it'll happen about once every week or two on a regular 64kbit/s link.)

What does it take for a packet to be valid MTP-2?

If we send random data, then every so often there's going to be a flag. That signals start- and end-of-packet for MTP-2, so random data will look like it has packets. But to get valid packets, there are several more hoops to jump through:

• The CRC must be right.
• The packet must be a multiple of 8 bits long, e.g. 31 bit packets aren't allowed.
• The length indicator must be right.
• The packet must be between 5 and 272 octets (bytes) long.

It's possible to calculate how often all of those requirements are met...but it seems easier and less prone to "oh, I didn't think of that" to just try it and see what happens.

Test setup

I used a Corelatus E1/T1 Messenger 2.1 with a crossover E1 cable so that everything it transmits on one E1 port is received on another. I didn't write any code to do this, I just used programs from the C sample code collection, like this:

    
      $ ./playback_file 172.16.2.7 3A 1 /dev/urandom
      // in another window
      $ ./save_to_pcap 172.16.2.7 4A 1 /tmp/random.pcap
    
  

Results

After about 12 hours, the MTP-2 counters looked like this:

We got 11 million bad packets and 3 good ones and no FISUs. Looking at the "good" ones more closely, it's obvious that they're not good either. Here's one of them:

    
      $ tshark -x -r /tmp/random.pcap | tail -2
      0000  9e e2 49 ef a1 95 0f b0 7a 34 b6                  ..I.....z4.

      $ tshark -V -r /tmp/random.pcap
      Frame 3: 11 bytes
      Interface id: 0 (4A:1)
      Encapsulation type: SS7 MTP2 (42)
      Arrival Time: Mar 13, 2015 11:36:56.057000000 CET
      Message Transfer Part Level 2
      .001 1110 = Backward sequence number: 30
      1... .... = Backward indicator bit: 1
      .110 0010 = Forward sequence number: 98
      1... .... = Forward indicator bit: 1
      ..00 1001 = Length Indicator: 9
      01.. .... = Spare: 1
      Message Transfer Part Level 3
      Service information octet
      11.. .... = Network indicator: Reserved for national use (0x03)
      ..10 .... = Spare: 0x02
      .... 1111 = Service indicator: Spare (0x0f)
      Routing label
      .... .... .... .... ..01 0101 1010 0001 = DPC: 5537
      .... 0000 0000 1111 10.. .... .... .... = OPC: 62
      1011 .... .... .... .... .... .... .... = Signalling Link Selector: 11
      Data: 7a34b6
    
  

Two things aren't quite right. First, the spare bits are normally set to zero (but Q.703 doesn't require this). Second, the length indicator is 9, but should be 6 for this packet (Q.703 requires checking this; Corelatus GTH accepts it anyway to make it easier to debug installations which use extended sequence number format).