Packet Processors

What are packet processors?

jNetPcap SDK utilizes a pipeline of "processors" that handle captured packets, each performing specific tasks as the data progresses from the initial capture to the user-defined handler. Every processor in the chain has the opportunity to inspect and modify the packet before passing it to the next one. Finally, after all processors have finished their work, the modified packet is delivered to the user handler.

These processors have numerous configuration options accessible through a fluent (method chaining) programming model. Additionally, most of these options can be set using system properties, each with a pre-defined default value. This flexibility allows programmers to easily enable, disable, and configure processor behavior without needing to recompile the code. This enables functionalities like activating "packet level" debugging directly from the command line.

There are three types of packet processors 

jNetPcap offers three types of processors for customizing how you handle network data

• Pre-processors: Dig deep into the raw data. These processors operate directly on the raw bytes of captured packets, including the pcap header and payload. This low-level access is ideal for specialized tasks requiring direct manipulation of the raw data.

• Post-processors: Analyze and manipulate structured data. These processors operate on fully parsed Packet objects, providing access to structured information and offering high-level processing capabilities.

• Tx-processors: Preparing Packets for Seamless Network Transmission. These processors manipulate packets before they are transmitted on the network. They handle tasks like DLT header insertion, network routing lookups, and protocol compliance, paving the way for seamless data exchange across networks.

List of processors

Here is a list of processors

Pre-processors

1. PacketPlayer: Facilitates the playback of offline captures, allowing users to replay captured packets from a file at their original Inter-Frame Gap (IFG) or at a user-defined speed based on the embedded timestamps within each packet. This enables analysis and testing scenarios with precise control over the timing and pacing of network traffic.

2. PacketDelay: Manipulates the temporal aspects of replayed packets beyond simply adhering to their original Inter-Frame Gaps (IFG). It allows for the introduction of additional delays between packets, extending the IFG, or even re-basing the timestamps to any desired starting time. This enables scenarios like "replaying" captured packets in real-time, effectively simulating live network traffic by aligning their timestamps with the current time.

3. PacketRepeater: Effortlessly generate massive volumes of simulated network traffic. This processor seamlessly replicates captured packets a user-defined number of times, significantly increasing traffic volume with minimal CPU overhead. This feature proves invaluable for simulating realistic network conditions in testing scenarios, allowing you to analyze your system's behavior under heavy traffic loads without expending excessive resources.

4. DataObfuscator: Safeguards user privacy by employing obfuscation techniques to mask sensitive information within captured packets. This includes fields such as IP addresses, usernames, passwords, and other potentially identifiable data. This masking ensures that sensitive information remains concealed and protected from unauthorized access, even when dealing with captured network traffic.

5. PacketPeeker: The ability to "peek" at packets before they are dispatched to the main processing pipeline, similar to the Stream::peek function in Java. This facilitates efficient debugging by enabling console output, logging, and other monitoring activities without impacting the core functionality of the processor chain. Moreover, processors can be readily disabled or enabled through the command line or programmatically, eliminating the need for recompilation and allowing for dynamic debugging and experimentation.

6. PacketRebuffer: By default, pcap packets are delivered one at a time with limited lifespan within the handler. Once the handler finishes processing, the packet data becomes inaccessible. This "rebuffer" processor addresses this limitation by enabling the copying of packets to a custom buffer, significantly extending their lifespan and allowing for further processing, analysis, or storage beyond the immediate scope of the handler.

8. PacketMixer: Seamlessly merge external packets with the captured packet stream. It acts as a mixer, combining two separate pcap captures into a single, unified stream. This functionality enables scenarios like integrating traffic from multiple sources into a single dataset for analysis or testing. For example, two different offline pcap captures can be effortlessly merged into a single stream for further processing or playback.

9. PacketDeduplicator: Eliminates redundant copies of packets within the stream, ensuring only unique packets reach subsequent processors. This optimization reduces data volume and optimizes resource utilization.

10. PacketDropper: Provides granular control over packet filtering and dropping based on user-defined rules. It allows for scenarios like simulating network conditions with random packet loss or selectively dropping packets matching specific criteria specified by the user through filters. This enables a wide range of testing and analysis scenarios by manipulating the flow of packets through the processing pipeline.

11. PacketGenerator: Inject custom packets into the capture stream, enabling the generation of diverse network traffic types and rates. It seamlessly integrates with the PacketMixer processor, allowing for effortless blending of synthetically generated packets with live or captured traffic streams. This functionality opens up a wealth of possibilities for testing, analysis, and simulation scenarios. For instance, users can create a "dead" pcap handle, attach the PacketGenerator to it, and then mix the generated traffic with a live capture stream, effectively augmenting real-world network data with specific types of simulated packets.

Post-processors

1. IpfReassembler: This versatile processor reassembles fragmented IP packets, ensuring you have complete and accurate data for analysis and manipulation. When used in conjunction with the jNetWorks SDK and Napatech SmartNICs, it leverages hardware-accelerated IP fragmentation (IPF) features, delivering exceptional performance and minimal CPU overhead. In environments without hardware acceleration, the IpfReassembler seamlessly switches to software-based reassembly, ensuring consistent functionality regardless of the available hardware. This flexible approach ensures that fragmented IP packets are always properly handled, regardless of the underlying hardware configuration. The extensive feature set and configuration options of the IpfReassembler, in conjunction with its hardware acceleration and software fallback capabilities, offer a robust and reliable solution for working with fragmented IP packets using jNetPcap.

2. ProtocolPeeker: Grants access to the intricate details of network traffic, unveiling the inner workings of various protocols and data structures within each packet. Much like Java Stream::peek, it provides a glimpse into the flow of information without altering the stream itself.

3. PacketCloner: Offers a unique approach to handling captured data, akin to a Java-style object creation. Unlike the default behavior where packets are short-lived and disappear after processing, PacketCloner duplicates each packet, including its payload, creating a new, independent instance with a global scope. This cloned object persists until the Java Virtual Machine (JVM) loses all references to it, aligning with the familiar Java programming model.

Tx-processors

1. DataLinkLayer: The DataLinkLayer processor is responsible for adding or modifying the data-link header (DLT header) on a packet before it is transmitted. The DLT header is a crucial component of a packet, as it provides essential information for the packet to be successfully transmitted over the physical network.

   • DLT Header Preparation: For outbound packets, the DataLinkLayer processor is responsible for constructing the DLT header. This involves filling in the header fields with appropriate information, such as the destination MAC address, the packet type, and the frame control flags.

   • MAC Address Resolution: To determine the destination MAC address for outbound packets, the DataLinkLayer processor utilizes the system's ARP table. The ARP table maintains a mapping between IP addresses and their corresponding MAC addresses.

   • Network Layer Information Utilization: The DataLinkLayer processor extracts relevant information from the network layers, such as the destination IP address, to facilitate DLT header preparation and MAC address resolution.