Packet Processors

What are packet processors?

Its a chain of "processors" that  each captured packet passes through, as its makes its way from the native pcap capture to the user handler. At each step, every processor in the chain, has a opportunity to inspect and modify the packet. After all the processors are done, the packet is finally dispatched to the user handler.

Processors take lots of options and are configured using fluent (method chaining) programming model. Most of these options can be set via system properites as well and each property has its own default value. This allows the programmer to enable/disable and set processor properties with ease without having to recomplie. For example enabling "packet level" debugging from the command line, etc...

There are 2 types of packet processors 

The 2 types of processors are simply called "pre" and "post" processors.

Pre processors work on raw packets directly at a native memory location (both pcap header and packet data). This is more efficient and better applicable for certain tasks.

Post processors work on fully dissected `Packet` objects and are best suited for more user level processors.

List of processors

Here is a list of processors

Pre processors:

1. `PacketPlayer` - used with offline captures to play back packets from the file at the original IFG (inter-frame-gap) or speed using packet timestamps

2. `PacketDelay` - can add additional delay or extend the IFG between packets also rebase the timestamp to any starting time desired. For example rebase played back packets to current time and play them back in real time as being captured from a live network.

3. `PacketRepeater` - repeats a captured packet certain number of times, easy way to generate lots of simulated traffic

4. `DataObfuscator` - protects privacy by obfuscating sensitive fields within a packet such as addresses, user name fields, passwords, etc..

5. `PacketPeeker` - similar to JRE's `Stream.peek` call allowing early access to a packet before being dispatched. This is good for debugging (console output, logging, etc...) since any processor can easily be turned on or off from the command line or programatically before hitting any business code

6. `PacketRebuffer` - pcap packets are dispatched 1 packet at a time natively with a scope lasting only the duration of the packet within the handler after which the packet is no longer accessible, this rebuffer allows packets to be copied to a custom buffer with a much more expanded scope

8. `PacketMixer` - allows external packets to be mixed with the captured packet stream. This processor allows 2 pcap packet streams to be mixed together into a single one. For example mix 2 different offline pcap captures

9. `PacketDeduplicator` - removes duplicate packets

10. `PacketDropper` - drops packets according to user rules. Allows simulation packets being dropped ramdomly for example or for packets matched by a specific user filter, etc...

11. `PacketGenerator` - generate user defined packets at different rates, types, etc. Mix into existing capture streams using a `PacketMixer`. For example open a 'dead' pcap handle, attach a generator and mix it into another pcap stream from a live capture.

Post processors:

1. `IpfReassembler` - IP fragmented packet reassembler. Reassembles IP packets. This is a big processor has lots of functionality and configuration options

2. `ProtocolPeeker` - allows protocol level access to packets and their protocol level detail

3. `PacketCloner` - similar to rebuffer functionality, except that each packet is cloned, including its payload data, to a new instance of a packet and the scope becomes global based and data deallocated when VM looses all references to it. This is more inline how Java programming model works, but of course not provided by default as packet captures can overwhelm VM memory system with the number of packets that is possible to capture per second on fast multi-gig networks