Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 5240] Patch to editcap to allow chop from beginning of packet for decapsulatio

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5240

Jason Masker <jason@xxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #5206|0                           |1
        is obsolete|                            |
   Attachment #5891|                            |review_for_checkin?
               Flag|                            |

--- Comment #15 from Jason Masker <jason@xxxxxxxxxx> 2011-02-04 10:51:30 PST ---
Created an attachment (id=5891)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=5891)
Modify -C to allow chopping at beginning or end of packet

I have modified the patch to include the cast. I tested applying the patch and
do get the desired behavior.

The classic behavior of -C is now accessed by specifying a negative value for a
chop length to chop from the end of each packet. The new functionality is
accessed by passing a positive value which will chop headers from the beginning
of each packet. The reason for modification of the existing behavior when
adding the new functionality came about as a result of the discussion above,
where it seemed reversing the current behavior and adding the new behavior for
positive values passed would be more consistent with the use of positive and
negative numbers elsewhere. 

To verify the new behavior, download the sample ERSPAN capture attached and you
can see that the ERSPAN headers are correctly removed, leaving a clean pcap
file with only 1 ethernet and IP header when used with the following
parameters:

editcap -C 50 t1.pcap out.pcap

Passing a negative value, like so:

editcap -C -20 t1.pcap out.pcap

will chop 20 bytes off the end of each packet.

There is a sanity check when using either method that will not chop the packet
if the value passed would eliminate the packet entirely. This was not something
I decided should be the behavior, but mimics the behavior already implemented
for chopping the end of the packet. If the requested chop is greater than the
size of an individual packet, then that packet is left alone.

Please let me know if all that makes sense. :)

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