jNetPcap 2.X

Stand alone libpcap wrapper module

Checking latest fixes

I have checked in the latest fixes related to wire-len and how data is read out of truncated headers. The algorithm has been updated as the old way was causing problems with certain packets.

Just in case, I tag the trunk as tags/1.3/trunk-2009-08-17 before the changes were checked in.

I'm still working on a few other important items and more testing before I make another dev snapshot build.

Pcap.nextEx

Here is an example that demonstrates how to use Pcap.nextEx method. The example uses various peering methods, Libpcap DLT to jNetPcap protocol ID mapping, initiating a new PcapPacket object and invoking the scanner on a newly created packet.
Download Source from SVN:


package org.jnetpcap.examples;

import org.jnetpcap.Pcap;
import org.jnetpcap.PcapHeader;
import org.jnetpcap.nio.JBuffer;
import org.jnetpcap.nio.JMemory;
import org.jnetpcap.packet.JRegistry;
import org.jnetpcap.packet.PcapPacket;
import org.jnetpcap.packet.format.FormatUtils;
import org.jnetpcap.protocol.lan.Ethernet;
import org.jnetpcap.protocol.network.Ip4;

/**
 * This example opens up a capture file found in jNetPcap's installation
 * directory for of the "source" distribution package and iterates over every
 * packet. The example also demonstrates how to property peer
 * PcapHeader, JBuffer and initialize a new
 * PcapPacket object which will contain a copy of the peered
 * packet and header data. The libpcap provide header and data are stored in
 * libpcap private memory buffer, which will be overriden with each iteration of
 * the loop. Therefore we use the constructor in PcapPacket to
 * allocate new memory to store header and packet buffer data and perform the
 * copy. The we
 * 
 * @author Mark Bednarczyk
 * @author Sly Technologies, Inc.
 */
public class NextExExample {

	/**
	 * Start of our example.
	 * 
	 * @param args
	 *          ignored
	 */
	public static void main(String[] args) {
		final String FILE_NAME = "tests/test-l2tp.pcap";
		StringBuilder errbuf = new StringBuilder(); // For any error msgs

		/***************************************************************************

Chasing bugs

I've been chasing several bugs all day today:

  • scanner came up with invalid RTP header length on one-off packet in a huge capture. Turned out the RTP extension header address was incorrectly calculated in validate_rtp().
  • JMemoryPacket incorrectly set wire_length of the packet this also caused header lengths to be miscalculated
  • Ip4 payload calculation was incorrectly set for ip fragments. This also caused problems with a sanity check that scanner performs making sure that header lengths never exceed wire_len. This check was failing for ICMP encapsualated IP4 header which don't have their tot_len adjusted.

Also added a small native debugging and tracing library. It allows the main decoder loop to be traced in detail for debugging purposes as well as a number of protocols. I plan on making this a java software switchable to enable/disable low level tracing output. All trace statements are enclosed in ifdef(DEBUG) preprocessor conditionals, therefore all the debugging and tracing code will not be compiled into production versions of library. But I will be releasing dev builds with full DEBUG compiled in and controllable through a verbosity level just like with java loggers.

I've been working on automated debugging and tracing in case something goes wrong. Packet decoder exceptions will be able to gather lots of debug information to be sent back to developers, including complete trace output of the scanners, dissectors and analyzers. I'm automating it so that on exception, the thrown object will generate a working java jUnit testcase with the packet that threw the exception. The testcase will contain the packet data, all the traces and all available debug string, as well as library and platform info to be reported back.

PcapPacket constructor

I have added the implicit "transferTo" type copy of the packet in both PcapPacketHandler and JPacketHandler. Now both of these handlers deliver a stand-alone packet with fully copied contents. All 3 packet components header, state and data are copied into a single buffer and the java JMemory objects peered to point at their respective offsets into this memory block. Exactly the same as if done with PcapPacket.transferTo methods except its done natively.

This almost obsoletes the PcapPacket(PcapPacket) constructor. I say almost, because there may still be legitimate reasons to make an extract copy of all this information. It is however not neccessary to make a copy anymore in order to get the packet out of the temporary libpcap ring-buffer or JScanner ring-state-buffer.

I think this is the more intuitive behavior of both of these handlers and that should not only clear up many questions I receive and lots of frustrating programming errors for users learning jNetPcap library, but it also positions these 2 handlers for the enhanced memory model that will be implemented after 1.2 release. The new memory model will enhance JMemoryPool class and allow complex native structures to be peered.

Any existing implementations of these 2 handlers that perform a copy of the packets, should simply remove the code block that does the memory copies either using "transferTo" method or PcapPacket() constructors. In eclipse you can select the contructors and transferTo methods and perform "references" search which will list all the areas of the code that utilize these methods, pin pointing potential code that may need to be disabled.

If the code is not disabled, it will only result in packet data being copied twice. This is undersirable but not fatal in most cases resulting in some waist of memory and CPU, but fully functional.

4.3.1 - Quickscan

The most important function of the scanner is to perform a quick scan of the packet buffer and record information about what headers are found and at what location within the buffer. This information is then associated with a java packet or more specifically JPacket and JPacket.State classes. The first provides access to packet data buffer and the second to scanner state structures for packet. There is also a JHeader.State class which provides access to each individual's header's state. JHeader itself is peered (linked) with native memory location that is the packet buffer, but specifically at offset into the buffer that points to the start of the each header.

Syndicate content