/*
    Configuration of conversation test in the case of NAT between two sides (client and server).
    Trace file must represent one session.
    There are some configuration parameters that must be defined on higher level.
    After such configuration test may be started by RUN   PARAMETERS: <base request> <list of packets>
This command starts imitation of application's work. Parameters to command specify the request to result of test. <Base request> may be: drop, any, accept. List of packets, for example: 1;2;3-5;7-. Minus at the end of list means expanding to last packet in trace file. List "any" is equal to "1-".
The result for packets from list must correspond to base request. The result for packets not from list must correspond to inverted base request. Ex: "run accept 1-" means "all packets must be accepted", "run drop 6-" means "all packets before 6 must be accepted, rest of packets - dropped", "run any any" means no requests. See "samples/convtest1"

 command.
 
    Interfaces association:
 
       0 - public zone
       1 - private zone
       2 - DMZ
 
 */

INCLUDE   PARAMETERS: <name of file>
Starts processing the content of given file. The search of file will be performed in the current directory, all search paths (see option -I). For every path the content of samples, headers, traces folders will be also examined. You can also type just the name of file without INCLUDE   PARAMETERS: <name of file>
Starts processing the content of given file. The search of file will be performed in the current directory, all search paths (see option -I). For every path the content of samples, headers, traces folders will be also examined. You can also type just the name of file without INCLUDE   PARAMETERS: <name of file>
Starts processing the content of given file. The search of file will be performed in the current directory, all search paths (see option -I). For every path the content of samples, headers, traces folders will be also examined. You can also type just the name of file without include before it.

 before it.

 before it.

 natDefines   // includes configuration of NAT

IFNDEF   PARAMETERS: <name of entity> "{" <script's block> "}"
Executes block if given entity has not been defined (entity: variable, field, someone defined by GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

 or DEFINE   PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

.

 commands).

 clientIP {

	PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 "ERROR: clientIP must be defined (if server is in DMZ then client is in public network, otherwise - in private)\n"
	EXIT   PARAMETERS: <status>
Terminates the execution. The status may be some decimal number. Value 0 is reserved for successful test, 1 - fatal error, 2 - not successful test, 3 - error while TCP connecting or listening (timeout expires).

 1
}

IFNDEF   PARAMETERS: <name of entity> "{" <script's block> "}"
Executes block if given entity has not been defined (entity: variable, field, someone defined by GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

 or DEFINE   PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

.

 commands).

 serverIP {

	PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 "ERROR: serverIP must be defined (server may be in DMZ or in public network, beyond or before the gateway)\n"
	EXIT   PARAMETERS: <status>
Terminates the execution. The status may be some decimal number. Value 0 is reserved for successful test, 1 - fatal error, 2 - not successful test, 3 - error while TCP connecting or listening (timeout expires).

 1
}

IFNDEF   PARAMETERS: <name of entity> "{" <script's block> "}"
Executes block if given entity has not been defined (entity: variable, field, someone defined by GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

 or DEFINE   PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

.

 commands).

 externalServer {

	PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 "ERROR: flag externalServer must be defined.\n1: the server is beyond the public subnet (is accessible via the gateway)\n0 - otherwise\n"
	EXIT   PARAMETERS: <status>
Terminates the execution. The status may be some decimal number. Value 0 is reserved for successful test, 1 - fatal error, 2 - not successful test, 3 - error while TCP connecting or listening (timeout expires).

 1
}

IFNDEF   PARAMETERS: <name of entity> "{" <script's block> "}"
Executes block if given entity has not been defined (entity: variable, field, someone defined by GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

 or DEFINE   PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

.

 commands).

 ownClientMac {

	PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 "ERROR: flag ownClientMac must be defined\n1: uses other client mac\n0: uses client mac from trace file\n"
	EXIT   PARAMETERS: <status>
Terminates the execution. The status may be some decimal number. Value 0 is reserved for successful test, 1 - fatal error, 2 - not successful test, 3 - error while TCP connecting or listening (timeout expires).

 1
}

IFNDEF   PARAMETERS: <name of entity> "{" <script's block> "}"
Executes block if given entity has not been defined (entity: variable, field, someone defined by GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

 or DEFINE   PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

.

 commands).

 serverInDMZ {

   PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 "ERROR: flag serverInDMZ must be defined\n1: server IP must represent the host located in DMZ\n0: server is in public network\n"
   EXIT   PARAMETERS: <status>
Terminates the execution. The status may be some decimal number. Value 0 is reserved for successful test, 1 - fatal error, 2 - not successful test, 3 - error while TCP connecting or listening (timeout expires).

 1
}

IF   PARAMETERS: <value1> <type of compare> <value2> "{" <first block of script> "}" [ "else" "{" <second block of script> "}" ]
Processes the first block of script if condition is met, otherwise processes the second block if it is specified. <Types of compare>: = (==), !=, >, <, >=, <=. Hexadecimals number are treated as strings (with 0x prefix). If you have problems try to watch how these values are represented by string using PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 command for example.

 ownClientMac = 1 {

	IFNDEF   PARAMETERS: <name of entity> "{" <script's block> "}"
Executes block if given entity has not been defined (entity: variable, field, someone defined by GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

 or DEFINE   PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

.

 commands).

 clientMac {

	  PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 "ERROR: value of clientMac must be defined if flag ownClientMac was set\n"
	  EXIT   PARAMETERS: <status>
Terminates the execution. The status may be some decimal number. Value 0 is reserved for successful test, 1 - fatal error, 2 - not successful test, 3 - error while TCP connecting or listening (timeout expires).

 1
	}
}

IF   PARAMETERS: <value1> <type of compare> <value2> "{" <first block of script> "}" [ "else" "{" <second block of script> "}" ]
Processes the first block of script if condition is met, otherwise processes the second block if it is specified. <Types of compare>: = (==), !=, >, <, >=, <=. Hexadecimals number are treated as strings (with 0x prefix). If you have problems try to watch how these values are represented by string using PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 command for example.

 externalServer = 0 {

	IFNDEF   PARAMETERS: <name of entity> "{" <script's block> "}"
Executes block if given entity has not been defined (entity: variable, field, someone defined by GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

 or DEFINE   PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

.

 commands).

 serverMac {

	  PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 "ERROR: value of serverMac must be defined if server is in public subnet (before gateway) or in DMZ\n"
	  EXIT   PARAMETERS: <status>
Terminates the execution. The status may be some decimal number. Value 0 is reserved for successful test, 1 - fatal error, 2 - not successful test, 3 - error while TCP connecting or listening (timeout expires).

 1
	}
}

IF   PARAMETERS: <value1> <type of compare> <value2> "{" <first block of script> "}" [ "else" "{" <second block of script> "}" ]
Processes the first block of script if condition is met, otherwise processes the second block if it is specified. <Types of compare>: = (==), !=, >, <, >=, <=. Hexadecimals number are treated as strings (with 0x prefix). If you have problems try to watch how these values are represented by string using PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 command for example.

 serverInDMZ = 1 {

	IFNDEF   PARAMETERS: <name of entity> "{" <script's block> "}"
Executes block if given entity has not been defined (entity: variable, field, someone defined by GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

 or DEFINE   PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF   PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').

.

 commands).

 serverMac {

	  PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 "ERROR: value of serverMac must be defined if server is in DMZ\n"
	  EXIT   PARAMETERS: <status>
Terminates the execution. The status may be some decimal number. Value 0 is reserved for successful test, 1 - fatal error, 2 - not successful test, 3 - error while TCP connecting or listening (timeout expires).

 1
	}
}

// ETHERNET

IF   PARAMETERS: <value1> <type of compare> <value2> "{" <first block of script> "}" [ "else" "{" <second block of script> "}" ]
Processes the first block of script if condition is met, otherwise processes the second block if it is specified. <Types of compare>: = (==), !=, >, <, >=, <=. Hexadecimals number are treated as strings (with 0x prefix). If you have problems try to watch how these values are represented by string using PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 command for example.

 serverInDMZ = 0 {

   PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 '\nSession from $clientIP$ in private zone to $serverIP$ in public zone\n'

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 srcmac first natPublicMac
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 dstmac  first natPrivateMac

	IF   PARAMETERS: <value1> <type of compare> <value2> "{" <first block of script> "}" [ "else" "{" <second block of script> "}" ]
Processes the first block of script if condition is met, otherwise processes the second block if it is specified. <Types of compare>: = (==), !=, >, <, >=, <=. Hexadecimals number are treated as strings (with 0x prefix). If you have problems try to watch how these values are represented by string using PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 command for example.

 externalServer = 1 {

      PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 'ServerIP is beyond the gateway (gw mac = $natPublicGwMac$)\n'

		RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 dstmac first natPublicGwMac
		RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 srcmac second natPublicGwMac
	}
	else {

      PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 'ServerIP is in public subnet (its mac = $serverMac$)\n'

		RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 dstmac first serverMac
		RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 srcmac second serverMac
	}

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 srcmac second natPrivateMac

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 dstmac second natPublicMac

	IF   PARAMETERS: <value1> <type of compare> <value2> "{" <first block of script> "}" [ "else" "{" <second block of script> "}" ]
Processes the first block of script if condition is met, otherwise processes the second block if it is specified. <Types of compare>: = (==), !=, >, <, >=, <=. Hexadecimals number are treated as strings (with 0x prefix). If you have problems try to watch how these values are represented by string using PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 command for example.

 ownClientMac = 1 {

		RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 srcmac first clientMac
		RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 dstmac second clientMac
	}

	// IP

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

  srcip first clientIP
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 srcip first natPublicIP

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 dstip first serverIP
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 dstip first serverIP

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 srcip second serverIP
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 srcip second serverIP

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 dstip second natPublicIP
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 dstip second clientIP

	// PORTS

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 srcport first 1
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

  dstport second 2
	ARM   PARAMETERS: <name of field> <field's value>
Defines an adaptive replacement. This command gets two previously defined replacements (command RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

), marks them as not active initially. While imitation of application's work program will wait for the first packet for which the given <name of field> has the given <field's value>. Then for each of two replacements program sets its <value to set>, copying it from the received packet, then marks replacements as active. So the test will be finally configured after receiving some packet only.
Note: from received packet will be obtained value of that field which has been specified for the first replacement. Then this value will be copied to <value to set> of second replacement.
See "headers/natConfigSession"

 syn 1

	// CIEVES

	CIEVE   PARAMETERS: <name of field>
Causes that while imitation of application's work the value of specified field will not be considered when comparing waited packet with receiving one.

 ip.crc
	CIEVE   PARAMETERS: <name of field>
Causes that while imitation of application's work the value of specified field will not be considered when comparing waited packet with receiving one.

 tcp.crc

}
else {	// serverInDMZ = 1

   PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 '\nSession from $clientIP$ in public zone to $serverIP$ in DMZ\n'

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 srcip first clientIP
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 srcip first clientIP

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 srcip second serverIP
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 srcip second serverIP

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 dstip first serverIP
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 dstip first serverIP

	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 dstip second clientIP
	RM   PARAMETERS: <type> <name of field> <sought value> <value to set>
While imitation of application's work some values in packets from trace file may be automatically replaced before generating packet or before waiting one. So the <type> of replacement ("TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

" or "TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

") instructs when the replacement must be applied: before generating packet or before forming the packet which will be waited.
So it is possible to generate one packet but wait another. It may be useful if packets are modified on their way.
The <name of field> specifies the field for which the replacement must be applied. The <sought value> is the value of field which will be sought in packets to replace it. It will be replaced by the given <value to set>. Some special values are allowed: "first" and "second". In this case the concrete value will be obtained from the first or second packet in trace file. See "headers/natConfigSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 dstip second clientIP

	CIEVE   PARAMETERS: <name of field>
Causes that while imitation of application's work the value of specified field will not be considered when comparing waited packet with receiving one.

 ip.crc
	CIEVE   PARAMETERS: <name of field>
Causes that while imitation of application's work the value of specified field will not be considered when comparing waited packet with receiving one.

 tcp.crc
}

// END POINTS

IF   PARAMETERS: <value1> <type of compare> <value2> "{" <first block of script> "}" [ "else" "{" <second block of script> "}" ]
Processes the first block of script if condition is met, otherwise processes the second block if it is specified. <Types of compare>: = (==), !=, >, <, >=, <=. Hexadecimals number are treated as strings (with 0x prefix). If you have problems try to watch how these values are represented by string using PRINT   PARAMETERS: <message>
Displays the given message. Use symbol 
 in message to indicate that line feed must be performed.

 command for example.

 serverInDMZ = 0 {

   // client is in private network, server is in public

	EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in DEFAULTS   PARAMETERS: {accept | drop | any | REVERS   PARAMETERS: not command
Request specification. May only be given in parameters for DEFAULT command. Instructs to reverse the request for every packet.

 }
Defines default requests for packets. These requests will be applied when there are not enough explicitly defined requests for some packet (specified as parameters to command SEND, WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 and its analogs). Initially default requests are ACCEPT ANY ANY... i.e. a single request for the first interface specified via option -d.

 (command DEFAULT). For TCP DEVICE   PARAMETERS: <type of device> {<name of interface>}
Reopens interfaces. The type of device: eth, ip, tcp. The name of device is the same as for -d option, depends on the type of device. New line terminates the list of names.

 the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT   PARAMETERS: {accept | drop | any }
Analog of WAIT command. Adds the above packet to the set of packets which will be waited by command WAIT or its analogs. This command does not start actual waiting (doesn't suspend script execution). Nevertheless, just after adding the packet may be registered as received. If some packet is registered as received before the call to WAIT (WAITALL   PARAMETERS: no parameters
The analog of WAIT command. Doesn't add the previously defined packet to the list of waited ones. Starts waiting simply. Packets may be already added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command (or using of UNFIX command).

) then the command will ignore it and wait for a next packet (see also SENDWAITOTHER   PARAMETERS: no parameters
Works similar to "SEND WAITALL" sentence. Purpose: make atomic operation. Without this command there would be a chance that a waited packet did not cause command WAITALL stop waiting if it was accepted after SEND but before WAITALL started waiting. However it would be registered as received in any case. This command should be always used when you need to send a request and RELIABLY receive a response on it never missing.

).

 command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT   PARAMETERS: no parameters
After the work of WAIT command (its analogs) all trace threads will be blocked until the next call to WAIT command. So there will be no missed packets between subsequent calls to WAIT command.

). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command.

 command.

 command).

" (receiving EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command).

" (receiving ep) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 1 srcip first
	EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in DEFAULTS   PARAMETERS: {accept | drop | any | REVERS   PARAMETERS: not command
Request specification. May only be given in parameters for DEFAULT command. Instructs to reverse the request for every packet.

 }
Defines default requests for packets. These requests will be applied when there are not enough explicitly defined requests for some packet (specified as parameters to command SEND, WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 and its analogs). Initially default requests are ACCEPT ANY ANY... i.e. a single request for the first interface specified via option -d.

 (command DEFAULT). For TCP DEVICE   PARAMETERS: <type of device> {<name of interface>}
Reopens interfaces. The type of device: eth, ip, tcp. The name of device is the same as for -d option, depends on the type of device. New line terminates the list of names.

 the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT   PARAMETERS: {accept | drop | any }
Analog of WAIT command. Adds the above packet to the set of packets which will be waited by command WAIT or its analogs. This command does not start actual waiting (doesn't suspend script execution). Nevertheless, just after adding the packet may be registered as received. If some packet is registered as received before the call to WAIT (WAITALL   PARAMETERS: no parameters
The analog of WAIT command. Doesn't add the previously defined packet to the list of waited ones. Starts waiting simply. Packets may be already added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command (or using of UNFIX command).

) then the command will ignore it and wait for a next packet (see also SENDWAITOTHER   PARAMETERS: no parameters
Works similar to "SEND WAITALL" sentence. Purpose: make atomic operation. Without this command there would be a chance that a waited packet did not cause command WAITALL stop waiting if it was accepted after SEND but before WAITALL started waiting. However it would be registered as received in any case. This command should be always used when you need to send a request and RELIABLY receive a response on it never missing.

).

 command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT   PARAMETERS: no parameters
After the work of WAIT command (its analogs) all trace threads will be blocked until the next call to WAIT command. So there will be no missed packets between subsequent calls to WAIT command.

). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command.

 command.

 command).

" (receiving EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command).

" (receiving ep) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 0 srcip second

	EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in DEFAULTS   PARAMETERS: {accept | drop | any | REVERS   PARAMETERS: not command
Request specification. May only be given in parameters for DEFAULT command. Instructs to reverse the request for every packet.

 }
Defines default requests for packets. These requests will be applied when there are not enough explicitly defined requests for some packet (specified as parameters to command SEND, WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 and its analogs). Initially default requests are ACCEPT ANY ANY... i.e. a single request for the first interface specified via option -d.

 (command DEFAULT). For TCP DEVICE   PARAMETERS: <type of device> {<name of interface>}
Reopens interfaces. The type of device: eth, ip, tcp. The name of device is the same as for -d option, depends on the type of device. New line terminates the list of names.

 the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT   PARAMETERS: {accept | drop | any }
Analog of WAIT command. Adds the above packet to the set of packets which will be waited by command WAIT or its analogs. This command does not start actual waiting (doesn't suspend script execution). Nevertheless, just after adding the packet may be registered as received. If some packet is registered as received before the call to WAIT (WAITALL   PARAMETERS: no parameters
The analog of WAIT command. Doesn't add the previously defined packet to the list of waited ones. Starts waiting simply. Packets may be already added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command (or using of UNFIX command).

) then the command will ignore it and wait for a next packet (see also SENDWAITOTHER   PARAMETERS: no parameters
Works similar to "SEND WAITALL" sentence. Purpose: make atomic operation. Without this command there would be a chance that a waited packet did not cause command WAITALL stop waiting if it was accepted after SEND but before WAITALL started waiting. However it would be registered as received in any case. This command should be always used when you need to send a request and RELIABLY receive a response on it never missing.

).

 command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT   PARAMETERS: no parameters
After the work of WAIT command (its analogs) all trace threads will be blocked until the next call to WAIT command. So there will be no missed packets between subsequent calls to WAIT command.

). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command.

 command.

 command).

" (receiving EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command).

" (receiving ep) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 0 srcip first
	EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in DEFAULTS   PARAMETERS: {accept | drop | any | REVERS   PARAMETERS: not command
Request specification. May only be given in parameters for DEFAULT command. Instructs to reverse the request for every packet.

 }
Defines default requests for packets. These requests will be applied when there are not enough explicitly defined requests for some packet (specified as parameters to command SEND, WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 and its analogs). Initially default requests are ACCEPT ANY ANY... i.e. a single request for the first interface specified via option -d.

 (command DEFAULT). For TCP DEVICE   PARAMETERS: <type of device> {<name of interface>}
Reopens interfaces. The type of device: eth, ip, tcp. The name of device is the same as for -d option, depends on the type of device. New line terminates the list of names.

 the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT   PARAMETERS: {accept | drop | any }
Analog of WAIT command. Adds the above packet to the set of packets which will be waited by command WAIT or its analogs. This command does not start actual waiting (doesn't suspend script execution). Nevertheless, just after adding the packet may be registered as received. If some packet is registered as received before the call to WAIT (WAITALL   PARAMETERS: no parameters
The analog of WAIT command. Doesn't add the previously defined packet to the list of waited ones. Starts waiting simply. Packets may be already added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command (or using of UNFIX command).

) then the command will ignore it and wait for a next packet (see also SENDWAITOTHER   PARAMETERS: no parameters
Works similar to "SEND WAITALL" sentence. Purpose: make atomic operation. Without this command there would be a chance that a waited packet did not cause command WAITALL stop waiting if it was accepted after SEND but before WAITALL started waiting. However it would be registered as received in any case. This command should be always used when you need to send a request and RELIABLY receive a response on it never missing.

).

 command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT   PARAMETERS: no parameters
After the work of WAIT command (its analogs) all trace threads will be blocked until the next call to WAIT command. So there will be no missed packets between subsequent calls to WAIT command.

). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command.

 command.

 command).

" (receiving EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command).

" (receiving ep) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 1 srcip second
}
else {

   // client is in public network, server is in DMZ

	EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in DEFAULTS   PARAMETERS: {accept | drop | any | REVERS   PARAMETERS: not command
Request specification. May only be given in parameters for DEFAULT command. Instructs to reverse the request for every packet.

 }
Defines default requests for packets. These requests will be applied when there are not enough explicitly defined requests for some packet (specified as parameters to command SEND, WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 and its analogs). Initially default requests are ACCEPT ANY ANY... i.e. a single request for the first interface specified via option -d.

 (command DEFAULT). For TCP DEVICE   PARAMETERS: <type of device> {<name of interface>}
Reopens interfaces. The type of device: eth, ip, tcp. The name of device is the same as for -d option, depends on the type of device. New line terminates the list of names.

 the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT   PARAMETERS: {accept | drop | any }
Analog of WAIT command. Adds the above packet to the set of packets which will be waited by command WAIT or its analogs. This command does not start actual waiting (doesn't suspend script execution). Nevertheless, just after adding the packet may be registered as received. If some packet is registered as received before the call to WAIT (WAITALL   PARAMETERS: no parameters
The analog of WAIT command. Doesn't add the previously defined packet to the list of waited ones. Starts waiting simply. Packets may be already added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command (or using of UNFIX command).

) then the command will ignore it and wait for a next packet (see also SENDWAITOTHER   PARAMETERS: no parameters
Works similar to "SEND WAITALL" sentence. Purpose: make atomic operation. Without this command there would be a chance that a waited packet did not cause command WAITALL stop waiting if it was accepted after SEND but before WAITALL started waiting. However it would be registered as received in any case. This command should be always used when you need to send a request and RELIABLY receive a response on it never missing.

).

 command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT   PARAMETERS: no parameters
After the work of WAIT command (its analogs) all trace threads will be blocked until the next call to WAIT command. So there will be no missed packets between subsequent calls to WAIT command.

). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command.

 command.

 command).

" (receiving EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command).

" (receiving ep) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 0 srcip first
	EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in DEFAULTS   PARAMETERS: {accept | drop | any | REVERS   PARAMETERS: not command
Request specification. May only be given in parameters for DEFAULT command. Instructs to reverse the request for every packet.

 }
Defines default requests for packets. These requests will be applied when there are not enough explicitly defined requests for some packet (specified as parameters to command SEND, WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 and its analogs). Initially default requests are ACCEPT ANY ANY... i.e. a single request for the first interface specified via option -d.

 (command DEFAULT). For TCP DEVICE   PARAMETERS: <type of device> {<name of interface>}
Reopens interfaces. The type of device: eth, ip, tcp. The name of device is the same as for -d option, depends on the type of device. New line terminates the list of names.

 the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT   PARAMETERS: {accept | drop | any }
Analog of WAIT command. Adds the above packet to the set of packets which will be waited by command WAIT or its analogs. This command does not start actual waiting (doesn't suspend script execution). Nevertheless, just after adding the packet may be registered as received. If some packet is registered as received before the call to WAIT (WAITALL   PARAMETERS: no parameters
The analog of WAIT command. Doesn't add the previously defined packet to the list of waited ones. Starts waiting simply. Packets may be already added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command (or using of UNFIX command).

) then the command will ignore it and wait for a next packet (see also SENDWAITOTHER   PARAMETERS: no parameters
Works similar to "SEND WAITALL" sentence. Purpose: make atomic operation. Without this command there would be a chance that a waited packet did not cause command WAITALL stop waiting if it was accepted after SEND but before WAITALL started waiting. However it would be registered as received in any case. This command should be always used when you need to send a request and RELIABLY receive a response on it never missing.

).

 command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT   PARAMETERS: no parameters
After the work of WAIT command (its analogs) all trace threads will be blocked until the next call to WAIT command. So there will be no missed packets between subsequent calls to WAIT command.

). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command.

 command.

 command).

" (receiving EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command).

" (receiving ep) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

 TOGEN   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the sending of a packet.

 2 srcip second

	EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in DEFAULTS   PARAMETERS: {accept | drop | any | REVERS   PARAMETERS: not command
Request specification. May only be given in parameters for DEFAULT command. Instructs to reverse the request for every packet.

 }
Defines default requests for packets. These requests will be applied when there are not enough explicitly defined requests for some packet (specified as parameters to command SEND, WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 and its analogs). Initially default requests are ACCEPT ANY ANY... i.e. a single request for the first interface specified via option -d.

 (command DEFAULT). For TCP DEVICE   PARAMETERS: <type of device> {<name of interface>}
Reopens interfaces. The type of device: eth, ip, tcp. The name of device is the same as for -d option, depends on the type of device. New line terminates the list of names.

 the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT   PARAMETERS: {accept | drop | any }
Analog of WAIT command. Adds the above packet to the set of packets which will be waited by command WAIT or its analogs. This command does not start actual waiting (doesn't suspend script execution). Nevertheless, just after adding the packet may be registered as received. If some packet is registered as received before the call to WAIT (WAITALL   PARAMETERS: no parameters
The analog of WAIT command. Doesn't add the previously defined packet to the list of waited ones. Starts waiting simply. Packets may be already added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command (or using of UNFIX command).

) then the command will ignore it and wait for a next packet (see also SENDWAITOTHER   PARAMETERS: no parameters
Works similar to "SEND WAITALL" sentence. Purpose: make atomic operation. Without this command there would be a chance that a waited packet did not cause command WAITALL stop waiting if it was accepted after SEND but before WAITALL started waiting. However it would be registered as received in any case. This command should be always used when you need to send a request and RELIABLY receive a response on it never missing.

).

 command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT   PARAMETERS: no parameters
After the work of WAIT command (its analogs) all trace threads will be blocked until the next call to WAIT command. So there will be no missed packets between subsequent calls to WAIT command.

). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command.

 command.

 command).

" (receiving EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command).

" (receiving ep) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 2 srcip first
	EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in DEFAULTS   PARAMETERS: {accept | drop | any | REVERS   PARAMETERS: not command
Request specification. May only be given in parameters for DEFAULT command. Instructs to reverse the request for every packet.

 }
Defines default requests for packets. These requests will be applied when there are not enough explicitly defined requests for some packet (specified as parameters to command SEND, WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 and its analogs). Initially default requests are ACCEPT ANY ANY... i.e. a single request for the first interface specified via option -d.

 (command DEFAULT). For TCP DEVICE   PARAMETERS: <type of device> {<name of interface>}
Reopens interfaces. The type of device: eth, ip, tcp. The name of device is the same as for -d option, depends on the type of device. New line terminates the list of names.

 the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT   PARAMETERS: {accept | drop | any }
Analog of WAIT command. Adds the above packet to the set of packets which will be waited by command WAIT or its analogs. This command does not start actual waiting (doesn't suspend script execution). Nevertheless, just after adding the packet may be registered as received. If some packet is registered as received before the call to WAIT (WAITALL   PARAMETERS: no parameters
The analog of WAIT command. Doesn't add the previously defined packet to the list of waited ones. Starts waiting simply. Packets may be already added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command (or using of UNFIX command).

) then the command will ignore it and wait for a next packet (see also SENDWAITOTHER   PARAMETERS: no parameters
Works similar to "SEND WAITALL" sentence. Purpose: make atomic operation. Without this command there would be a chance that a waited packet did not cause command WAITALL stop waiting if it was accepted after SEND but before WAITALL started waiting. However it would be registered as received in any case. This command should be always used when you need to send a request and RELIABLY receive a response on it never missing.

).

 command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT   PARAMETERS: no parameters
After the work of WAIT command (its analogs) all trace threads will be blocked until the next call to WAIT command. So there will be no missed packets between subsequent calls to WAIT command.

). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command.

 command.

 command).

" (receiving EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT   PARAMETERS: {accept | drop | any }
Waits for packet whose mask is defined above. The command will finish work when such packet is received on waitable interface. The waitable interface is interface for which strict request (accept or drop) have been specified in parameters to command or in defaults (command DEFAULT). For TCP device the command will only wait data on the main interface. In the general case command may wait no one but several packets (added by ADD   PARAMETERS: 
Alias of TOWAIT command.

 command). If any of them is received then command terminates. Command waits packets until timeout expires (command TIMEOUT   PARAMETERS: <interval in milliseconds>
Defines the timeout for WAIT command (and its analogs), also for imitation of application's work. Null value means infinite timeout (such timeout will not be applied for imitation of application's work). In the case of negative value its absolute value will be obtained as timeout, but WAIT command (its analogs) will work differently: it will always wait for the whole timeout (not terminating on first received packet). So several packets may be registered as received. This command also defines the timeout for TCP server while waiting for connections.

). See "samples/waiting_packets.fws".

 command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC   PARAMETERS: no parameters
The received packet (see command WAIT, its analogs) will be copied to the buffer of current packet. Precision waiting must be first enabled (command PRECISEWAIT). See also NOTCOPYREC   PARAMETERS: no parameters
Reverses the action of COPYREC command.

 command.

 command).

" (receiving ep) and "gen" (generating EP   PARAMETERS: <type> <name of interface> <name of field> <field's value>
Defines an end point. While imitation of application's work the end point is a entity used for distinguishing between packets in trace file belonging to different sources (so they, for example, must be generated from different interfaces). All the packets for which the given <name of field> has the given <field's value> will belong to defined end point.
There are two <types> of end points: "RECV   PARAMETERS: 
Analog of WAIT command. This command is more convenient to use when working with tcp(udp). It clears the mask of packet automatically so stops working after receiving any data. It also enables mode when received packet is copied to the buffer of current packet (COPYREC command).

" (receiving ep) and "gen" (generating ep). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

). Generating end points search their packets in trace file and generate them. receiving end points - wait for their packets. The packets from trace file are scanned in series. The generation can only be performed after receiving previous packets. The wait will be started after generation previous packets. The <unique name of interface> specifies the interface from which packets will be generated or waited. See "headers/configSession"

 TORECV   PARAMETERS: no command
This special word specifies that some entity must perform its function upon the receiving of a packet.

 0 srcip second
}