Get raw text for this example (you can click any command below to see its doc)
/*   Default configuration for simple conversation test. In trace file a common session must be represented   with two sides: the first packet is from client side, the second - from server side.     The interface with user number 0 corresponds to client, interface 1 - server.  */
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 srcmac 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 srcmac 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.
1 srcmac 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" (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"
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).
0 srcmac second