Fix the "crossed chopping region" problem. Also, move chopping to its own function for both clarity and correctness since we need to compute chop offsets and lengths on a per-packet basis whereas previously this was not being done.

Lastly, try to improve the documentation a bit concerning chopping and provide another example depicting 2 separate chopping regions.  *Maybe* this is clearer?

One more example here for posterity:  Given the following 75 byte packet, there
are 8 different ways to chop the 2 regions marked as 10 and 20 in a single pass:

    <--------------------------- 75 ---------------------------->
 
    +---+-------+-----------+---------------+-------------------+
    | 5 |   10  |     15    |       20      |         25        |
    +---+-------+-----------+---------------+-------------------+

1) editcap -C 5:10 -C -25:-20 in.pcap out.pcap
2) editcap -C 5:10 -C 50:-20 in.pcap out.pcap
3) editcap -C -70:10 -C -25:-20 in.pcap out.pcap
4) editcap -C -70:10 -C 50:-20 in.pcap out.pcap
5) editcap -C 30:20 -C -60:-10 in.pcap out.pcap
6) editcap -C 30:20 -C 15:-10 in.pcap out.pcap
7) editcap -C -45:20 -C -60:-10 in.pcap out.pcap
8) editcap -C -45:20 -C 15:-10 in.pcap out.pcap


svn path=/trunk/; revision=51886

1 files changed, 14 insertions, 6 deletions

diff --git a/doc/editcap.pod b/doc/editcap.pod
index fda1228558..abeacb87f0 100644
--- a/doc/editcap.pod
+++ b/doc/editcap.pod
@@ -105,8 +105,10 @@ file formats leaves some random bytes at the end of each packet. Another use is
 for removing vlan tags.
 
 NOTE: This option can be used more than once, effectively allowing you to chop
-bytes from the beginning of a packet as well as from the end of a packet in a
-single step.
+bytes from two different areas of a packet in a single pass provided that
+you specify at least one chop length as a postive value and at least one as a
+negative value.  All positive chop lengths are added together as are all
+negative chop lengths.
 
 =item -d
 
@@ -189,7 +191,7 @@ packets were used).
 
 =item -S  E<lt>strict time adjustmentE<gt>
 
-Time adjust selected packets to insure strict chronological order.
+Time adjust selected packets to ensure strict chronological order.
 
 The <strict time adjustment> value represents relative seconds
 specified as [-]I<seconds>[I<.fractional seconds>].
@@ -205,7 +207,7 @@ will adjusted.  The adjusted timestamp value will be set to be
 equal to the timestamp value of the previous packet plus the value
 of the <strict time adjustment> value.  A <strict time adjustment>
 value of 0 will adjust the minimum number of timestamp values
-necessary to insure that the resulting capture file is in
+necessary to ensure that the resulting capture file is in
 strict chronological order.
 
 If <strict time adjustment> value is specified as a
@@ -344,7 +346,7 @@ To advance the timestamps of each packet forward by 3.0827 seconds:
 
     editcap -t 3.0827 capture.pcap adjusted.pcap
 
-To insure all timestamps are in strict chronological order:
+To ensure all timestamps are in strict chronological order:
 
     editcap -S 0 capture.pcap adjusted.pcap
 
@@ -352,10 +354,16 @@ To introduce 5% random errors in a capture file use:
 
     editcap -E 0.05 capture.pcap capture_error.pcap
 
-To remove vlan tags from an Ethernet-encapsulated capture file use:
+To remove vlan tags from all packets within an Ethernet-encapsulated capture
+file, use:
 
     editcap -L -C 12:4 capture_vlan.pcap capture_no_vlan.pcap
 
+To remove the IP header as well as the last 4 bytes from all packets within an
+Ethernet-encapsulated capture file, use:
+
+    editcap -C 14:20 -C -4 capture.pcap chopped.pcap
+
 =head1 SEE ALSO
 
 pcap(3), wireshark(1), tshark(1), mergecap(1), dumpcap(1), capinfos(1),