Feature #432

PCAP-NG support

Added by Victor Julien about 3 years ago. Updated 6 months ago.

Status:AssignedStart date:03/22/2012
Priority:NormalDue date:
Assignee:Eric Leblond% Done:

50%

Category:-
Target version:TBD

History

#1 Updated by Victor Julien almost 3 years ago

  • Status changed from New to Assigned
  • Assignee set to Eric Leblond

#2 Updated by Victor Julien over 2 years ago

  • Target version changed from 1.4 to 1.4beta2

#3 Updated by Eric Leblond over 2 years ago

  • % Done changed from 0 to 100

It is already working with at least pcap v1.3.0 (version since 2010 should work if we trust website).

It is enough to do:

bin/suricata -r ~eric/git/oisf/benches/sample-wlan0.pcapng

to have a correct parsing of sample-wlan0.pcapng which is a pcap-ng 1.0 file:
file ~eric/git/oisf/benches/sample-wlan0.pcapng
/home/eric/git/oisf/benches/sample-wlan0.pcapng: pcap-ng capture file - version 1.0

#4 Updated by Eric Leblond over 2 years ago

  • % Done changed from 100 to 30

Suricata could have some issues when multiple interfaces (with different datalink) are used in the file.

#5 Updated by Eric Leblond over 2 years ago

This case is not supported by libpcap (example file can be provided privately)

Do we try a completely different approach (like using a new library) ?

#6 Updated by Victor Julien over 2 years ago

So libpcap 1.3 supports pcap NG but not all features? Is it on their roadmap?

#7 Updated by Eric Leblond over 2 years ago

It is not mentioned in any feature request (http://sourceforge.net/tracker/?group_id=53067&atid=469580). It is possible this is not planned at all as it will break some important part of the API. For example, pcap_datalink() which is used by suricata as a pcap handle argument. This is not good in pcap-ng where the datalink can depends on the packet (and need to be updated for each packets).

Currently, when running in pcap mode with a file with two different interfaces (on Ethernet and one tuntap iface), we've got this:

[5722] 10/9/2012 -- 17:50:19 - (source-pcap-file.c:188) <Error> (ReceivePcapFileLoop) -- [ERRCODE: SC_ERR_PCAP_DISPATCH(20)] - error code -1 an interface has a type 12 different from the type of the first interface

pcap detects the problem but do not support the feature.

#8 Updated by Victor Julien over 2 years ago

Does wireshark support this? If so, how?

#9 Updated by Eric Leblond over 2 years ago

Victor Julien wrote:

Does wireshark support this? If so, how?

Wireshark does it with a non-exportable code. They've got a library to parse some fromat but libpcap-ng seems to be parsed with non in-core code.

#10 Updated by Victor Julien over 2 years ago

Like we discussed in person yesterday, we'll go with the libpcap 1.3+ pcap-ng support for now. If the need comes up we can consider adding more complete support.

#11 Updated by Victor Julien over 2 years ago

  • Target version changed from 1.4beta2 to TBD
  • % Done changed from 30 to 50

#12 Updated by Guy Harris 6 months ago

FYI:

At some point, in my Copious Free Time(TM), I want to add new APIs to libpcap that support the full capabilities of pcap-ng. The routines implementing those APIs will also be able to read pcap files transparently, so if code is changed to use the new APIs, it will still be able to read pcap files. However, to support the full capabilities of pcap-ng, a program or library would have to be changed. The old APIs will continue to be supported, with the existing limitations.

I have no schedule for that; see the previous reference to Copious Free Time. :-)

Wireshark's code to read pcap-ng is in the same place in the source code as the other code to read file formats - the wiretap subdirectory, in wiretap/pcapng.c. However, neither the API to libwiretap nor the interface between code to read file formats and the libwiretap core is stable.

Also available in: Atom PDF