On Dec 12, 2007, at 9:03 AM, Jingshao Chen wrote:
I am trying to change the timestamp of the packets in a pcap file
with editcap. But it does not work. Is it broken or I used it wrong?
wireshark> editcap -t +100 test.pcap out.pcap 4635-4636
Add_Selected: 4635-4636
Inclusive ... 4635, 4636
wireshark>
After this, when I open out.pcap, the packets #4635 and #4636 were
removed from the pcap file and that is it.
From looking at the code, it appears that the "-t" flag doesn't
disable editcap's removal of packets.
The man page says
-t <time adjustment>
Sets the time adjustment to use on selected packets. If
the -t
flag is used to specify a time adjustment, the specified
adjustment
will be applied to all selected packets in the capture
file. The
adjustment is specified as [-]seconds[.fractional
seconds]. For
example, -t 3600 advances the timestamp on selected
packets by one
hour while -t -0.5 reduces the timestamp on selected
packets by
one-half second.
This feature is useful when synchronizing dumps collected on
different machines where the time difference between the two
machines is known or can be estimated.
The first two sentences seem to suggest that the intent is to allow
the adjustment to be applied to some but not all packets; if the
specification of packets *also* causes those packets not to be written
to the file, that's not a very useful behavior, so it would seem to be
that, if you specify the "-t" flag, *all* packets should be copied
from the source file to the destination file, and the selected packets
should have their time stamps changed.
I.e., without "-r", the selected packets aren't even copied to the
output file, so their time stamps can't be changed, so the resulting
file has no time stamps changed; with "-r", the packets that are
selected are written to the file, with a changed time stamp, but the
non-selected packets aren't written to the file, so the resulting file
has all time stamps changed. In either case, there's no way not to
have packets removed.
So it appears to me that it's broken, as, with its current behavior,
there's no way to use it right. Anybody care to defend the current
behavior? If not, you should file a bug on this on the
bugs.wireshark.org site, so we have a record of the problem.
