jNetPcap 2.X

Stand alone libpcap wrapper module

Header checksums

I got the tcp, udp and ip4 header checksums working. New class org.jnetpcap.util.checksum.Checksum has a number of static methods that compute various types of CRCs. These are of course native methods that compute the CRCs. There will be wrapper and convenience methods within the protocol definitions to get and compare CRC that are present in these headers.

I'm currently testing Tcp over Ip6 checksums but it looks good.

I have found 2 bugs in low level code. First is bug is a some kind of failure when using PcapPacket(PcapPacket source) copy constructor. Everything works for many packet copies and then breaks. This suggests something to do with memory boundary and the memory allocation algorithm. I'm still investigating.

The second, is Ip6 is not decoding but loops infinitely. I just discovered this one and will look into as well.

But I'm real happy with the checksum calculations. They are very efficiently setup and executed. The crc methods work on generic JBuffers, so that you can use them to generate or validate checksums with any kind of data. Currently 2 families of CRCs are implemented. The INET family for Tcp/ip protocols and CCITT others.

Truncated packet support

I've updated the scanner to keep track packets that have been truncated. Until now, headers assumed certain header properties based on the current length of the buffer, which might have been truncated during capture by pcap (i.e. by using snaplen parameter during capture). Although this approach worked OK most of the time, it did not work all the time when dealing with a truncated packet.

I have enhanced the scanner to keep track of both buffer length and original packet wire length, where wire length (wirelen) is the length of the packet during transmission. The scanner keps track of 3 packet length properties: buffer-length, memory-length, wire-length.

Update to header structure

I have updated how the header structure is represented in jnetpcap. Currently the header was simply described in native structures in 2 properties: offset and length. The offset is the offset into the overall packet buffer where the header starts and length property stored how many bytes long the header is. So offset + length pointed at the first byte past the header.

Finalizing ver 1.2.alpha

I'm finalizing the release. I've been fixing a lot of bugs that were reported to me and working on the API.

I'm adding many different "core" protocols such as SLL, Arp, SpanTree, VLAN, Rip 1 & 2, DNS, Telnet, FTP, ISL and HSRP. All basic types of protocol you will find in a typical networks.

I'm also working on last few bits of the API I needed to change. Specifically with new protocol development adding container classes for sub header, fields. Currently for sub headers for example you have to subclass JHeaderMap. This is very restrictive in its use. Instead you will now be using SubHeader containers as objects within the main header definition. This allows mixing of different type of containers for more complex headers.

Another area that I've addressed is use of custom "field formatters". The existing hardcoded field formats have been replaced with flexible "JFieldFormatter" objects. Each of these objects is used to hook into JFormatter to format the way a field is represented textually. Header definitions can supply their own custom JFieldFormatters and reference them in the annotations. jNetPcap of course comes with a comprehensive array of field formatters that core protocols already utilize, and this new mechanism allows completely new types of fields to be properly displayed.

With the addition of field and header containers you will be able to create very complex header/subheader or field/subfield hierararchies. Formatter is now also extensible with JFieldFormatter objects for new types of fields that need to be formatted for textual output.

Most people will not be affected by these changes as they only affect how headers are defined in jnetpcap, not how they are accessed.

1.1 - Getting Around

Let briefly go over all of the packages in jNetPcap SDK and what they contain:

  +-> jnetcap - this is the main libpcap wrapper package. It contains
      +         all of the API for accessing libpcap functionality.
      |         These classes and methods do very little of their own
      |         logic and simply pass your requests over to native
      |         libpcap which handles those the requested actions.
      +-> winpcap - extension to libpcap wrapper that provides WinPcap 
      |          functions. This is operating system dependent package
      |          and you must use WinPcap.isSupported() call before
      |          using any classes and methods in this package.
      +-> nio - native IO and memory classes. This package defines
      |         memory management classes that allocate native memory,
      |         peer native structures and functions to java classes. 
      |         This is also where the very important JBuffer class resides.
      +-> util - various utility classes. This is where you will find
      |          logging helpers, JConfig class which manages configurations
      |          through property files and address resolvers. 
      +-> protocol - a library of supported CORE protocol headers.
      |              This is where you will find Ip4, Tcp, Udp, Ethernet
      |              and a host of other header definitions, ready for you
      |              to use.
      +-> packet - packet decoding framework. This package defines important 
          |      components of the decoder. JScanner, PcapPacket, and the very
          |      important baseclass JHeader. JScanner decodes packets
          |      and stores the packet state information in native structures.
          |      PcapPacket class reads this state information and can
          |      peer (or reference via native memory) header objects. 
Syndicate content