Export all packets without pcap header as raw file

asked 2024-07-13 06:30:49 +0000

updated 2024-07-13 06:31:30 +0000

I have a pcap file. I'd like to keep everything (Ethernet, IP, UDP/TCP etc) except the pcap header(s). This is so I can use C code to parse the packets as if they arrived via a NIC.

When I select all packets, click on File, Export Specified Packets, but it does not have raw file type.

If I select one packet, click on File, Export Packet Bytes and this does have raw but it's only exporting one packet.

What am I doing wrong?

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2024-07-13 21:49:24 +0000

Guy Harris
19890 ●3 ●652 ●207

This is so I can use C code to parse the packets as if they arrived via a NIC.

For pcap files, and for pcapng files in which all the network interfaces have the same link-layer type and snapshot length (which includes all captures in which there is only one interface), you can use libpcap to read the file. Libpcap is provided with most if not all modern UN*Xes (you may have to install a "developer package" on Linux distributions), and is also available for Windows with Npcap (you'd have to install the Npcap SDK).

edit flag offensive delete link

Comments

@guy-harris , As PCAP does not exist in real traffic, how do NIC drivers know how large a frame/packet is?

Wireshark77 ( 2024-07-13 22:40:01 +0000 )edit

how do NIC drivers know how large a frame/packet is?

The NIC tells the driver how large a received frame is. See, for example, the data sheet for the Intel 82576EB Ethernet controller chip, sections 7.1.4 "Legacy Receive Descriptor Format", which shows a "packet length" field, and 7.1.5.2 "Advanced Receive Descriptors — Writeback Format", which shows "header length" and "packet length" fields (in "advanced" mode, the chip can put the packet header and what follows the packet header into separate buffers).

(When transmitting, the driver tells the NIC how large the frame to be transmitted is.)

Guy Harris ( 2024-07-14 09:25:05 +0000 )edit

add a comment

answered 2024-07-13 09:03:26 +0000

Jaap

13742 ●703 ●115

What you are missing is the fact that Ethernet frames, as on the wire and as such received by the NIC, have a beginning (preamble) and end (CRC + IPG). These boundaries are preserved, when the NIC (barring any optimisation techniques) hands over the received Ethernet frame (sans preamble, optionally with or without CRC) to the NIC driver. It is in this path that packet capture is taking place and the software can encapsulate these Ethernet frames in a file format, e.g. PCAP or PCAPNG.

What you propose to do is to get rid of these boundaries and create a single, uninterrupted, byte stream of all concatenated Ethernet frames. This will give you no option to identify the individual Ethernet frames and inhibit you from doing anything useful with this aggregated data.

edit flag offensive delete link

Comments

Thanks for replying. I'm processing ARP and IP packets. ARP is effectively fixed size and IP contains header length and total size fields. So surely I can work out the total length of each packet/frame?

Wireshark77 ( 2024-07-13 18:54:08 +0000 )edit

Thanks for replying. I'm processing ARP and IP packets. ARP is effectively fixed size and IP contains header length and total size fields. So surely I can work out the total length of each packet/frame?

If they're Ethernet frames, a sufficiently-short IP packet may require padding, so the IPv4 total size field isn't the frame size minus 14 bytes for the Ethernet header length. A TCP initial SYN, for example, might require padding - 14-byte Ethernet header, 20-byte IPv4 header with no options, 20-byte TCP header with no options, f or a total of 54 bytes, so 2 additional bytes of padding are needed to pad out to the minimum Ethernet frame size.

And if you know the file is Ethernet, and compute the size as the maximum of 60 bytes and the value computed from values in the packet, that might not work for packed that ...(more)

Guy Harris ( 2024-07-13 21:46:16 +0000 )edit

add a comment