PcapPlusPlus  24.09
IPReassembly.h File Reference
#include "Packet.h"
#include "LRUList.h"
#include "IpAddress.h"
#include "PointerVector.h"
#include <unordered_map>

Go to the source code of this file.

Classes

class  pcpp::IPReassembly
 
class  pcpp::IPReassembly::PacketKey
 
class  pcpp::IPReassembly::IPv4PacketKey
 
class  pcpp::IPReassembly::IPv6PacketKey
 

Namespaces

 pcpp
 The main namespace for the PcapPlusPlus lib.
 

Macros

#define PCPP_IP_REASSEMBLY_DEFAULT_MAX_PACKETS_TO_STORE   500000
 

Detailed Description

This file includes an implementation of IP reassembly mechanism (a.k.a IP de-fragmentation), which is the mechanism of assembling IPv4 or IPv6 fragments back into one whole packet. As the previous sentence imply, this module supports both IPv4 and IPv6 reassembly which means the same pcpp::IPReassembly instance can reassemble both IPv4 and IPv6 fragments. You can read more about IP fragmentation here: https://en.wikipedia.org/wiki/IP_fragmentation.
The API is rather simple and contains one main method: pcpp::IPReassembly::processPacket() which gets a fragment packet as a parameter, does the reassembly and returns a fully reassembled packet when done.

The logic works as follows:

  • There is an internal map that stores the reassembly data for each packet. The key to this map, meaning the way to uniquely associate a fragment to a (reassembled) packet is the triplet of source IP, destination IP and IP ID (for IPv4) or Fragment ID (for IPv6)
  • When the first fragment arrives a new record is created in the map and the fragment data is copied
  • With each fragment arriving the fragment data is copied right after the previous fragment and the reassembled packet is gradually being built
  • When the last fragment arrives the packet is fully reassembled and returned to the user. Since all fragment data is copied, the packet pointer returned to the user has to be freed by the user when done using it
  • The logic supports out-of-order fragments, meaning that a fragment which arrives out-of-order, its data will be copied to a list of out-of-order fragments where it waits for its turn. This list is observed each time a new fragment arrives to see if the next fragment(s) wait(s) in this list
  • If a non-IP packet arrives it's returned as is to the user
  • If a non-fragment packet arrives it's returned as is to the user

In order to limit the amount of memory used by this mechanism there is a limit to the number of concurrent packets being reassembled. The default limit is PCPP_IP_REASSEMBLY_DEFAULT_MAX_PACKETS_TO_STORE but the user can set any value (determined in pcpp::IPReassembly c'tor). Once capacity (the number of concurrent reassembled packets) exceeds this number, the packet that was least recently used will be dropped from the map along with all the data that was reassembled so far. This means that if the next fragment from this packet suddenly appears it will be treated as a new reassembled packet (which will create another record in the map). The user can be notified when reassembled packets are removed from the map by registering to the pcpp::IPReassembly::OnFragmentsClean callback in pcpp::IPReassembly c'tor

Macro Definition Documentation

◆ PCPP_IP_REASSEMBLY_DEFAULT_MAX_PACKETS_TO_STORE

#define PCPP_IP_REASSEMBLY_DEFAULT_MAX_PACKETS_TO_STORE   500000

IP reassembly mechanism default capacity. If concurrent packet volume exceeds this numbers, packets will start to be dropped in a LRU manner