1. Abstract
This page describes how astf-sim can be used to solve two following problems:
-
Too large packets in pcap
-
Too small time diffs in pcap
2. Large packets
Too large packets might cause fragmentation by DUT (smaller than 9KB) or even stop TRex from loading the pcap file (larger than 9KB)
astf-sim tool can help in following way:
-
TCP flows will be fragmented (offline)
-
UDP packets will be trimmed
Example of pcap that might get fragmented (by tunneling etc.):
./astf-sim -f cap2/http_get.pcap -o http_get_fixed.pcap --mss 1000 WARNING: Enabling fix timing implicitly RTT is 21.49 msec
After fix:
3. Small time diffs
Sometimes pcap has too small intervals between request and response.
For example, by capturing at end-point device or in network with low latency.
This is bad for STF behavior, as it sends response according to time written in pcap (not waiting for request to arrive), thus response might reach the DUT earlier.
|
|
Currently, this fix is only for TCP flows. |
Two improvements that can be applied:
3.1. Centering the capture point
Change the capture times as if the capture was done in the intermediate device (assuming the RTT is big enough).
Example of pcap capture that was done at client machine:
The response from server (packet #2) has almost the same time as next client packet (#3).
> ./astf-sim -f cap2/http_get.pcap -o http_get_fixed.pcap --fix-timing RTT is 21.49 msec
The times are fixed to be like the capture was done in the middle between client and server.
3.2. Enlarging overall RTT.
Sometimes the network is too fast, and previous section is not enough for STF needs.
In this case, one can enlarge the RTT (simulate slower network).
> ./astf-sim -f cap2/190_packet.pcap -o 190_packet_fixed.pcap --fix-timing RTT is 0.245 msec Could not fix timing: RTT is less than 5msec, enlarge the RTT
> ./astf-sim -f cap2/190_packet.pcap -o 190_packet_fixed.pcap --rtt 10 WARNING: Enabling fix timing implicitly RTT is 10.005 msec
Result:
Table of Contents