[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2101

           Summary: editcap broken
           Product: Wireshark
           Version: 0.99.6
          Platform: PC
               URL: http://http://www.wireshark.org/lists/wireshark-
                    dev/200712/msg00099.html
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: High
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: jingshao@xxxxxxxxxx


Build Information:
wireshark 0.99.6

Copyright 1998-2007 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.12.1, with GLib 2.14.2, with libpcap 0.9.1, with libz
1.2.2, with libpcre 7.4, with Net-SNMP 5.3.1, with ADNS, without Lua, with
GnuTLS 2.0.2, with Gcrypt 1.2.4, with Heimdal Kerberos, with PortAudio <= V18,
without AirPcap.

Running on FreeBSD 6.1-STABLE, with libpcap version 0.9.1.

Built using gcc 3.4.4 [FreeBSD] 20050518.

--
    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. 

-------- comment from Guy Harris -------
>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.


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.