Stream Export YAML syntax

In order to provide a fluent work-flow that utilize the best TRex user’s time, an export-import mini language has been created.

This enables a work-flow that supports saving and sharing a built packets and its scenarios, so that other tools (such as TRex Console) could use them.

The TRex Packet Builder module supports (using ___ method) the export of built stream according to the format described below.

Guidelines

  1. The YAML file can either contain Byte representation of the packet of refer to a .pcap file that contains it.

  2. The YAML file is similar as much as possible to the add_stream method of TRex RPC server spec, which defines the raw interaction with TRex server.

  3. Only packet binary data and VM instructions are to be saved. Any meta-data packet builder module used while creating the packet will be stripped out.

Export Format

 1
 2# PACKET REP - OPTION #1
 3packet:
 4  is_pcap         : YES/NO                  # <1>
 5  binary          : []                      # <2>
 6  pcap            : path/to/pcap/file.pcap  # <3>
 7  meta            : any metadata wished to  # <4>
 8
 9# PACKET REP - OPTION #2
10packet:
11  data            : [] / path/to/pcap/file.pcap # <5>
12  meta            : any metadata wished to  # <4>
13
14vm:                                         # <6>
15  - vm instruction #1
16  - vm instruction #2
17  ...
18  - vm instruction #N
19
20
21###################################
22####         Comments          ####
23###################################
24#
25# <1>: is_pcap is a boolean field that indicates if packet is transferred by pcap referencs
26#      ('YES') or binary representation ('NO').
27#
28# <2>: binary field encodes the packet in binary representation. in a sequence (array) data.
29#      Each array item is an integer ranging 0-255.
30#      **LEAVE BLANK IF USING PCAP REFERENCE**
31#
32# <3>: path to the linked pcap file. Make sure to provide path with reading credentials.
33#      **LEAVE BLANK IF USING BINARY REP FOR THE PACKET**
34#
35# <4>: meta data is any JSON formatted data ment to be passed on.
36#
37# <5>: data field can be both binary representation or pcap file refernce,
38#      without the need for user's explicit typing.
39#      The application logic differs between the cases by the object type
40#      (array/string ending in '.pcap')
41#      Less configuration, little more confusing, LESS similar to RPC spec
42#
43# <6>: vm instructions passed in array representation (sequence).
44#      Each instruction is deifned according to the structures of the supported VM instructions.

Example

The following files snapshot represents each of the options (Binary/pcap) for the very same HTTP GET request packet.