PcapPlusPlus
Next
|
#include <string>
#include <vector>
#include <memory>
#include "ProtocolType.h"
#include <stdint.h>
#include "ArpLayer.h"
#include "RawPacket.h"
Go to the source code of this file.
Classes | |
class | pcpp::internal::BpfProgramDeleter |
class | pcpp::BpfFilterWrapper |
class | pcpp::GeneralFilter |
class | pcpp::BPFStringFilter |
class | pcpp::IFilterWithDirection |
class | pcpp::IFilterWithOperator |
class | pcpp::IPFilter |
class | pcpp::IPv4IDFilter |
class | pcpp::IPv4TotalLengthFilter |
class | pcpp::PortFilter |
class | pcpp::PortRangeFilter |
class | pcpp::MacAddressFilter |
class | pcpp::EtherTypeFilter |
class | pcpp::CompositeFilter |
class | pcpp::CompositeLogicFilter< op > |
class | pcpp::NotFilter |
class | pcpp::ProtoFilter |
class | pcpp::ArpFilter |
class | pcpp::VlanFilter |
class | pcpp::TcpFlagsFilter |
class | pcpp::TcpWindowSizeFilter |
class | pcpp::UdpLengthFilter |
Namespaces | |
pcpp | |
The main namespace for the PcapPlusPlus lib. | |
Typedefs | |
using | pcpp::AndFilter = CompositeLogicFilter< CompositeLogicFilterOp::AND > |
using | pcpp::OrFilter = CompositeLogicFilter< CompositeLogicFilterOp::OR > |
Enumerations | |
enum | pcpp::Direction { pcpp::SRC , pcpp::DST , pcpp::SRC_OR_DST } |
enum | pcpp::FilterOperator { pcpp::EQUALS , pcpp::NOT_EQUALS , pcpp::GREATER_THAN , pcpp::GREATER_OR_EQUAL , pcpp::LESS_THAN , pcpp::LESS_OR_EQUAL } |
enum class | pcpp::CompositeLogicFilterOp { pcpp::AND , pcpp::OR } |
Functions | |
template<CompositeLogicFilterOp op> | |
constexpr const char * | pcpp::internal::getCompositeLogicOpDelimiter ()=delete |
Most packet capture engines contain packet filtering capabilities. In order to set the filters there should be a known syntax user can use. The most popular syntax is Berkeley Packet Filter (BPF) - see more in here: http://en.wikipedia.org/wiki/Berkeley_Packet_Filter. Detailed explanation of the syntax can be found here: http://www.tcpdump.org/manpages/pcap-filter.7.html.
The problem with BPF is that, for my opinion, the syntax is too complicated and too poorly documented. In addition the BPF filter compilers may output syntax errors that are hard to understand. My experience with BPF was not good, so I decided to make the filters mechanism more structured, easier to understand and less error-prone by creating classes that represent filters. Each possible filter phrase is represented by a class. The filter, at the end, is that class. For example: the filter "src net 1.1.1.1" will be represented by IPFilter instance; "dst port 80" will be represented by PortFilter, and so on. So what about complex filters that involve "and", "or"? There are also 2 classes: AndFilter and OrFilter that can store more filters (in a composite idea) and connect them by "and" or "or". For example: "src host 1.1.1.1 and dst port 80" will be represented by an AndFilter that holds IPFilter and PortFilter inside it
|
constexprdelete |
Returns the delimiter for joining filter strings for the composite logic filter operation.