I need to modify a .pcap file captured over a timespan of 5 minutes such that it simulates a .pcap file captured over a timespan of 20 minutes. The problem is that I don't know how to do this.
To illustrate the problem, suppose I have a .pcap file with 4 captured packets p1-p4 and t as a start time such that:
p1 is sent at t+ 0 minutesp2 is sent at t+ 1 minutesp3 is sent at t+ 2 minutesp4 is sent at t+ 3 minutesI want my resulting .pcap file to contain the same four packets but with the timestamps scaled (from 5 minutes to 20 minutes) such that they represent the following:
p1 is sent at t+ 0 minutesp2 is sent at t+ 4 minutesp3 is sent at t+ 8 minutesp4 is sent at t+ 12 minuteseditcap, however the only option I could find here is to adjust all timestamps with a set value using the -t option.I am using tcpreplay to replay a scenario in which a user browsers a webpage. I simultaniously inject some packets which are dependent on the .pcap file I replayed, i.e. the packets are injected by live monitoring of the replayed traffic and subsequently adjusting the packets it sends out. This entire traffic trace - i.e. both the replayed traffic and the injected packets - are captured using tcpdump. As there are a lot of large .pcap files I want to replay, I use the tcpreplay --multiplier option to speed up the process. However, this means the final capture is a compressed version of the original .pcap file. I would like to 'stretch' the newly created .pcap to be the same size as the original.
This can be accomplished with Wireshark using its "Time Shift" feature.
Assuming the timestamp for packet 1 is 2017-08-17 12:00:00.000000, select packet 1 then choose "Edit -> Time Shift..." and set the time for packet 1 to 2017-08-17 12:00:00.000000 (i.e., don't change this one). Click the box next to "...then set packet" and enter 2 for the packet number and 2017-08-17 12:04:00.000000 as the timestamp. You'll notice that it also indicates, "and extrapolate the time for all other packets", which is what you want. Hit Apply.
At this point, the timestamps should be adjusted to what you want, although the sub-second component might not end up being exactly the same for all packets and for some reason even packet 1's sub-second component is not exactly what was originally specified. If you really want to retain the original sub-second component, then you'll have to adjust one packet at a time. Considering that there are only 4 packets to adjust, this should be feasible. I might suggest filing a Wireshark bug report for the erroneous sub-second adjustment though.