jNetPcap 2.X

Stand alone libpcap wrapper module

4.3 - Scanner Internals

JScanner class is the front end to a small library of functionality implemented native code (C/C++ language). The scanner can be invoked from both native code and from java space. For example the PcapPacketHandler.nextPacket method, before it is invoked by native libpcap dispatcher, it first invokes the scanner before transferring control to user's java handler. At the same time, a newly created packet using JMemoryPacket can invoke the scanner from java space using JMemoryPacket.scan which will invoke the default packet scanner for the currently active thread.

The scanner performs several functions:

  • discovery of main headers in the packet
  • discovery of the next header in the chain of headers using direct binding method
  • invokes a java bind method
  • invokes a java headerLength method defined in a header
  • dissects the contents of a header. Actually maintains 2 separate tables, one for dissecting sub-headers and the second for dissecting optional fields.

Header containers

Just a quick update on what I'm working on right now. As described in the dev priorities thread (http://jnetpcap.com/node/309), I'm currently focusing on 1.2 work. The highest priority is redesign of header containers.

Header containers are objects that a header definition can allocate to store detailed information about the header structure such as its fields and subheaders. jNetPcap's scanner records information about the packet and where the headers start and end, but not what they look like inside. That is done by the header definition such as Ip4.class which looks at its options, flags and optional headers.

Header definition classes are free to use whatever means and mechanism to scan the header contents and record the results. Existing approach provided some container classes that also extended JHeader (the main header super class). This is not very scalable since if you have 2 different ways you need to store certain portions of the header such as some parts as a list and other parts as a tree, you would need to find a specialized container class you could subclass that would provide storage both ways or implement something completely from scratch to satisfy your requirements.

As jNetPcap's API goal is to be super friendly, it needs to provide these basic building blocks for flexible header design.

This is what I'm workin on now. I am writting several containers in 2 categories, field containers and sub-header containers. The main design work is focused on how to allow native scanners efficiently record detailed header breakdown. This would allow a low level scanner to dissect a header into fields and subheaders, record that information in native header structures where in java peered header objects would share this information instead of redissecting the header everytime a new header object is peered.

Build jnetpcap-1.3.b0003 available

Development build jnetpcap-1.3.b0003 is available for download. This is the latest snapshot of the main development trunk. It looks stable on all the platforms tested.

Key updates:

  • Sip, Sdp, Rtp, Arp, Rip, SLL protocols are all now CORE protocols.
  • Protocol heuristics (bindings are guessed based on evaluation of raw header data for matches against protocols.)
  • Low level header-state-structure has been expanded to take into account a header prefix, the header itself, a gap between header and payload, payload length and a postfix.
  • Packet truncation is now also applied at low level to scanner and appropriate packet and header specific flags are set to indicate packet fragments and/or truncated packets.
  • Checksum calculation class and package is provided. Checksum validation is supported through a new interface JHeaderChecksum which is implemented by Ip4, Tcp, Udp, Icmp headers.
  • a number of bug fixes in protocols and analyzers.

You can download the build package for MsWindows, Linux and Debian from sourceforge.net file release system:

https://sourceforge.net/project/showfiles.php?group_id=164277&package_id...

Packet fragmentation check

Added fragmentation check using JHeader.isFragmented():boolean. Now every header can check if its a fragment or complete protocol message. Also updated Tcp, Upd and Icmp protocol to supress crc check for fragmented or truncated packets. Here is what the description method looks like in all 3 of them:

	@Dynamic(Field.Property.DESCRIPTION)
	public String checksumDescription() {

		if (isFragmented()) {
			return "supressed for fragments";
		}

		if (isPayloadTruncated()) {
			return "supressed for truncated packets";
		}

		final int crc16 = calculateChecksum();
		if (checksum() == crc16) {
			return "correct";
		} else {
			return "incorrect: 0x" + Integer.toHexString(crc16).toUpperCase();
		}
	}

I think that is pretty self explanatory. The fragmented flag is a cummulative flag. In ip4 packets, the ip4 scanner sets the flag and any subsequent headers, inherit that flag. So a Udp packet that has been fragmented, won't check is checksum because ip4 scanner sets the fragmented flag which udp can see.

A sample Udp header output:

Udp: ******* Udp offset=34 (0x22) length=8
Udp:
Udp: source = 7001
Udp: destination = 7000
Udp: length = 52
Udp: checksum = 0x3F2 (1010) [correct]
Udp:

org.jnetpcap.util.checksum package

I SVN checked in the above package. This package is responsible for calculating various types of checksum and CRCs. Also appropriate Tcp, Udp, Ip4, Ip6 and Icmp headers received new methods calculateChecksum and dynamic description method checksumDescription which compares the claculated checksum with the computed one and displays "correct" or "incorrect" next to the checksum field in each of the above protocols. Both Tcp and Udp over Ip4 and Ip6 are supported with pseudo headers.

Syndicate content