Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Presumably you're trying to remove the 14 Ethernet framing bytes from the start of each packet? Well, if that's the case, then as far as I'm aware, you can't achieve that using such an old version of editcap. If possible, you should upgrade Wireshark (and thus editcap) to a version that supports the -C [offset:]<choplen> syntax. If you're able to do that, then the syntax you'd probably want, assuming all Ethertypes are IPv4, would be:

editcap -w 0.001 -C 14 -L -T rawip pcap_file pcap_file_updated

NOTE: The -T rawip part is necessary; otherwise the encapsulation would still be Ethernet, but since the Ethernet framing bytes have been stripped away, the resulting output capture file would not be interpreted properly.

If it's not possible for you to upgrade your version of Wireshark, then you will have to resort to other solutions, some more painful than others, such as:

  • Use tcprewrite. For example (untested):

    tcprewrite --strip=14 -i pcap_file -o pcap_file_updated_temp

NOTE: While tcprewrite does support a --dlt=[string] option, it doesn't appear that it supports --dlt=rawip, so you'll likely need to set the encapsulation in a separate step using editcap, for example:

editcap -T rawip pcap_file_updated_temp pcap_file_updated

  • A more painful solution: File -> Export Packet Dissections -> As Plain Text... -> Packet Format: Packet Bytes (only), File name: pcap_file.txt

    This will produce a text file with the bytes of each packet displayed in a format similar to the example shown in the text2pcap man page. For example:

    000000 00 0e b6 00 00 02 00 0e b6 00 00 01 08 00 45 00
    000010 00 28 00 00 00 00 ff 01 37 d1 c0 00 02 01 c0 00
    000020 02 02 08 00 a6 2f 00 01 00 01 48 65 6c 6c 6f 20
    000030 57 6f 72 6c 64 21

You will then need to write a script to remove the first 14 bytes of each packet and adjust all the offsets accordingly. Using the example above, you'd need to end up with something like this:

    000000 45 00
    000002 00 28 00 00 00 00 ff 01 37 d1 c0 00 02 01 c0 00
    000012 02 02 08 00 a6 2f 00 01 00 01 48 65 6c 6c 6f 20
    000022 57 6f 72 6c 64 21

Once you have the packets in this format, you can use text2pcap to convert the data back into a pcap file, like so:

text2pcap -l 101 pcap_file.txt pcap_file_updated

NOTE: The -l 101 part is needed for the same reason as -T rawip was needed for the editcap command above. For reference, link types are defined at https://www.tcpdump.org/linktypes.html.


Other possibilities?

  • Write to the author of TraceWrangler asking for an enhancement to be made to this tool that allows the removal of the Ethernet framing bytes and [optionally?] sets the output encapsulation to a user-specified value (i.e., such as "rawip" in this case). TraceWrangler supports other packet layer removal tasks such as removing Juniper headers, VLAN tags, GRE headers, etc., but it doesn't currently support the removal of the Ethernet framing bytes.

  • Some other solution(s) I haven't considered ...

Presumably you're trying to remove the 14 Ethernet framing bytes from the start of each packet? Well, if that's the case, then as far as I'm aware, @grahamb mentioned, you can't you can achieve that using such an old the older version of editcap. If , but you won't be able to adjust the frame lengths because the version you're using doesn't support the -L option. So, if possible, you should upgrade Wireshark (and thus editcap) to a version that supports the -C [offset:]<choplen> syntax. -L option. If you're able to do that, then the syntax you'd probably want, assuming all Ethertypes are IPv4, would be:

editcap -w 0.001 -C 14 -L -T rawip pcap_file pcap_file_updated

NOTE: The -T rawip part is necessary; otherwise the encapsulation would still be Ethernet, but since the Ethernet framing bytes have been stripped away, the resulting output capture file would not be interpreted properly.

If it's not possible for you to upgrade your version of Wireshark, then you will have to resort to other solutions, some more painful than others, such as:

  • Use tcprewrite. For example (untested):

    tcprewrite --strip=14 -i pcap_file -o pcap_file_updated_temp

NOTE: While tcprewrite does support a --dlt=[string] option, it doesn't appear that it supports --dlt=rawip, so you'll likely need to set the encapsulation in a separate step using editcap, for example:

editcap -T rawip pcap_file_updated_temp pcap_file_updated

  • A more painful solution: File -> Export Packet Dissections -> As Plain Text... -> Packet Format: Packet Bytes (only), File name: pcap_file.txt

    This will produce a text file with the bytes of each packet displayed in a format similar to the example shown in the text2pcap man page. For example:

    000000 00 0e b6 00 00 02 00 0e b6 00 00 01 08 00 45 00
    000010 00 28 00 00 00 00 ff 01 37 d1 c0 00 02 01 c0 00
    000020 02 02 08 00 a6 2f 00 01 00 01 48 65 6c 6c 6f 20
    000030 57 6f 72 6c 64 21

You will then need to write a script to remove the first 14 bytes of each packet and adjust all the offsets accordingly. Using the example above, you'd need to end up with something like this:

    000000 45 00
    000002 00 28 00 00 00 00 ff 01 37 d1 c0 00 02 01 c0 00
    000012 02 02 08 00 a6 2f 00 01 00 01 48 65 6c 6c 6f 20
    000022 57 6f 72 6c 64 21

Once you have the packets in this format, you can use text2pcap to convert the data back into a pcap file, like so:

text2pcap -l 101 pcap_file.txt pcap_file_updated

NOTE: The -l 101 part is needed for the same reason as -T rawip was needed for the editcap command above. For reference, link types are defined at https://www.tcpdump.org/linktypes.html.


Other possibilities?

  • Write to the author of TraceWrangler asking for an enhancement to be made to this tool that allows the removal of the Ethernet framing bytes and [optionally?] sets the output encapsulation to a user-specified value (i.e., such as "rawip" in this case). TraceWrangler supports other packet layer removal tasks such as removing Juniper headers, VLAN tags, GRE headers, etc., but it doesn't currently support the removal of the Ethernet framing bytes.

  • Some other solution(s) I haven't considered ...