This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Hi,

I have a problem with a Wireshark produced PCAP-file. With Wireshark I exported 1 packet in a seperate PCAP-file, which demonstrate the issue:

This is a dropbox link to a PCAP File with 1 packet.

If I load this PCAP in WireShark I nicely get a TCP and IP header, see sreenshot below.

The problem is that if I try to load this using:

  • Java with JNetPcap 1.3.0 with WinCap 4.1.3 DLL I get only a Ethernet Header and a Payload Header.
  • Python with DPKT goes completely crazy, where the ethernet data is of type string !!

    for ts, buf in pcap:
        eth = dpkt.ethernet.Ethernet(buf)
        print 'eth type %d python datatype %s '%(eth.type,type(eth.data))
    

Results in:

    eth type 44048 python datatype type str

Now CAPINFOS reveals that this PCAP file is Raw IP encapsulation, where correct readable ones are Ethernet encapsulated.

I tried to convert the PCAP file using:

editcap -T ether t_0.pcap t_.new.pcap

The encapsulation is now reported as Ethernet, however even in WireShark the TCP and IP header are now gone.

So my question is: What is wrong with this Wireshark generated 1 packet file, causing that it cannot be read by WinCap/DPTK?

How can I modify this pcap file to get it processed by WinPcap and get TCP and IP headers?

Thanks.

alt text

asked 27 Jan '16, 23:51

Jos's gravatar image

Jos
6225
accept rate: 0%

edited 27 Jan '16, 23:57


but the idea that I have lib/winpcap to do this for me

No, you don't. libpcap/winPcap don't parse any headers for you.

So I want to know how I can convert this RAW PCAP to a PCAP which WinPcap/LibPcap interprets as IP/TCP/UDP-headers.

The cat command will do so quite nicely. :-)

I.e., a pcap file with type "Raw IP" HAS packets that contain IP headers - each packet begin with an IP header. Do not look for an Ethernet header, because there are no Ethernet headers - or any other headers before the IP header.

The problem is that if I try to load this using:

  • Java with JNetPcap 1.3.0 with WinCap 4.1.3 DLL I get only a Ethernet Header and a Payload Header.

No, you get an IP header - no Ethernet header. If JNetPcap can't handle "Raw IP" packets, then it can't handle your capture file (and it's not as good a library as it could be, because it certainly could handle "Raw IP" packets).

  • Python with DPKT goes completely crazy, where the ethernet data is of type string !!

Don't use dpkt.ethernet, because there is no Ethernet header in the packet.

Now CAPINFOS reveals that this PCAP file is Raw IP encapsulation,

Because that's what it is.

where correct readable ones are Ethernet encapsulated.

Correct pcap files can have ANY of these encapsulations; they are NOT necessarily Ethernet-encapsulated.

There may be some lesser tools that can only handle Ethernet encapsulation, but the better tools can read more than just Ethernet-encapsulated pcaps; at minimum, a good tool or library should be able to handle Ethernet, 802.11, 802.11 with radiotap, Raw IP, and LINKTYPE_NULL/LINKTYPE_LOOP.

What is wrong with this Wireshark generated 1 packet file

Nothing. Something is, however, wrong with:

  • either JNetPcap or the program you wrote using it;
  • either DPKT or the program you wrote using it.

For JNetPcap, try first using the GetValue method of the DataLinkType class to get the encapsulation, and:

  • if and only if it's Ethernet (PcapDLT.EN10MB.value), you can use the Ethernet class;
  • if and only if it's 802.11 (PcapDLT.IEEE802_11.value), it's not clear whether what classes you can use, as the JNetPcap JavaDocs I found don't mention any classes for 802.11;
  • the same applies to 802.11 + radiotap;
  • if and only if it's Raw IP (PcapDLT.RAW.value), you might be able to use the Ip4 or Ip6 classes if JNetPcap supports Raw IP.

For DPKT, use dpkt.pcap.FileHdr.linktype to find out the encapsulation type, and do similar checks; if it's raw IP, you might be able to use the dpkt.ip or dpkt.ip6 modules.

permanent link

answered 28 Jan '16, 03:00

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Guy,

Thanks for your comment, but:

  • Why should I go for your solution, and not inject fake Ethernet headers with tcprewrite as I wrote here above. If I inject fake Ethernet headers, I also get access to JNetPcap PcapPacket.getHeader(tcp) (and IP/UDP).

  • You wrote: "libpcap/winPcap don't parse any headers for you.". He? But I can do in JNetPcap for example myPacket.getHeader(tcp), and then I get a TCP object. So JNetPcap/WinPcap is indeed parsing.

(28 Jan '16, 04:02) Jos

@Jos, most people answering questions on this site prefer to provide answers which are generic in terms that someone else asking a similar question can make use of an existing answer. That's why, I guess, @Guy Harris has spent so much time to comment the individual steps of your description.

Why should I go for your solution

If you look for the fastest method to handle a single capture taken as "raw IP" encapsulation (to say "raw" and to say "raw IP" is quite a difference) using an existing tool which can only process ethernet encapsulation, then your approach (use editcap to augment the raw IP packets with forged, meaningless, but formally correct ethernet layer) is the correct one; if you want to handle such captures systematically, Guy's suggestion to modify your tool in such a way that it would take the information about encapsulation type into account and start parsing the packet from the corresponding layer is the correct one.

The pcap file indicates the encapsulation type in order to allow the parsing application to choose the proper entry point to the parser without need to tell it so "manually".

I can do in JNetPcap for example myPacket.getHeader(tcp)

Yes. In JNetPcap. Are you sure that JNetPcap is a mere wrapper of WinPcap, or it also has some parsing logic in it?

(28 Jan '16, 04:40) sindy

JNetPcap MOST DEFINITELY has parsing logic in it. THAT is why it's doing parsing; the parsing is NOT being done by libpcap/WInPcap, it's being done by the ADDITIONAL parsing code in JNetPcap.

(28 Jan '16, 10:56) Guy Harris ♦♦

Technically there's nothing wrong with the capture. What you need to appreciate is that the encapsulation is "Raw IP", while you seem to insist of getting it interpreted as Ethernet, which it is not (since there is no Ethernet header, forcing the encapsulation to 'ether' by means of editcap just makes the file header incorrect with respect to the content of the frame(s) and therefore Wireshark cannot interpret the manipulated capture file anymore either).

So, whatever you are doing using WinPcap or DPTK, stop interpreting it as an Ethernet frame, which it isn't, and look at it as an Raw IP frame, which it is.

permanent link

answered 28 Jan '16, 00:22

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

Thanks, but for my research I want to get access to IP/TCP/UDP/ARP etc headers.Of course I can parse everything directly by hand, but the idea that I have lib/winpcap to do this for me. So I want to know how I can convert this RAW PCAP to a PCAP which WinPcap/LibPcap interprets as IP/TCP/UDP-headers. Since WireShark is showing TCP/IP/etc. headers in the Window, I assume there is some way to convert RAW PCAP to an "enhanced" PCAP format.

Also I have multiple PCAP-captures of which the most are not raw (so I can extract IP/TCP/UDP headers with libpcap), so it would be nice if I can convert the raw ip to this form, so I can process them with 1 data extraction algo.

(28 Jan '16, 00:47) Jos

Thanks, but for my research I want to get access to IP/TCP/UDP/ARP etc headers.

You have access to them if you're willing to parse the raw packet data, and if JNetPcap can handle LINKTYPE_RAW, it would be able to parse them for you. (If it doesn't, it should be fixed to do so.)

Of course I can parse everything directly by hand, but the idea that I have lib/winpcap to do this for me.

No, you have JNetPcap to do it for you. libpcap/WInPcap doesn't do any parsing of packet data.

So I want to know how I can convert this RAW PCAP to a PCAP which WinPcap/LibPcap interprets as IP/TCP/UDP-headers.

The only place where libpcap/WinPcap interprets the headers is in packet filtering, where it compiles a filter expression into BPF "machine code" to check whether the filter matches or not - and that code does handle LINKTYPE_RAW.

Since WireShark is showing TCP/IP/etc. headers in the Window, I assume there is some way to convert RAW PCAP to an "enhanced" PCAP format.

You assume incorrectly. For one thing, "RAW" isn't a different format of pcap, it's a different link-layer header type code; there's no "enhancement" involved. For another thing, Wireshark shows the headers because it has code to parse them - or, rather, it has code that does not try to parse link-layer headers for LINKTYPE_RAW captures - just as it has code to parse Ethernet headers and Token Ring headers and FDDI headers and 802.11 headers and so on and so forth.

(28 Jan '16, 11:02) Guy Harris ♦♦

I found the solution. RAW IP PCAPs should first be processed by tcprewrite.

tcprewrite --dlt=enet --enet-dmac=00:11:22:33:44:55 --enet-smac=66:77:88:99:AA:BB --infile=input.pcap --outfile=output.pcap

The output file has nicely some TCP and IP headers.

Source here,

permanent link

answered 28 Jan '16, 02:06

Jos's gravatar image

Jos
6225
accept rate: 0%

What you are doing here is adding a fake Ethernet header. While this does allow you to then not rewrite your pcap processing code to handle Raw IP, it's an extra step in your workflow that could easily be avoided if you re-read the answer from @Guy Harris on how you should handle a pcap that has either Ethernet or Raw IP.

(28 Jan '16, 04:07) grahamb ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×1,620
×238
×24
×20
×14

question asked: 27 Jan '16, 23:51

question was seen: 3,788 times

last updated: 28 Jan '16, 11:02

p​o​w​e​r​e​d by O​S​Q​A