Hi,

I have an app that's similar in structure to the new nextEx() example, that basically creates a list containing information on all/each of the packets in a PCAP file. Per the nextEx() example, among the information output is the output from packet.getFrameNumber().

I have another app that, when given a frame number, is suppose to search through the original PCAP file, find the packet with a matching frame number, then dump out more detailed info on that packet.

The problem that I'm having is that when the 2nd app is run, it can't find the packet with the matching frame number. It appears that the frame numbers output from the 1st app are completely different from the frame numbers?

What does packet.getFrameNumber() actually do? Is it getting some number that is actually in the PCAP file, or is it just an incrementing number or something like that, that jNetPcap is keeping track of?

What I really need is something, some number that is constant, that I can use to reference/identify/locate a given packet within a PCAP ...

BTW, it may be that I missed it, but I've been looking through the Javadocs, and I don't see a getFrameNumber() method in PcapPacket. I just found getFrameNumber() in JPacket, but I'm not using JPacket (at least, I don't think I am).

Thanks,
Jim

Since updating from r795, I am now getting an exception when scanning a packet created with JMemoryPacket(byte[]).

Exception in thread "Thread-16" java.lang.IllegalArgumentException: wirelen < buffer len
at org.jnetpcap.packet.JScanner.scan(Native Method)
at org.jnetpcap.packet.JScanner.scan(JScanner.java:357)
at org.jnetpcap.packet.JScanner.scan(JScanner.java:335)

The problem appears that scan now expects that the "wirelen" of the packet to have been set. I do not see a way to specify the wire length of the packet, either from the constructor or from a setter.

Looking at the two forms of the JMemoryPacket constructors, JMemoryPacket(byte[] buffer) and JMemoryPacket(int id, byte[] buffer), the later is setting "wirelen" [header.setWirelen(buffer.length);]. Is that line simply missing from the other constructor?

An update on builds for those interested.

I've been steadily improving the build scripts over last couple of releases. This is mainly due to the fact that we have a lot more platforms getting ready for support coming. With that in mind, the build scripts now determine the pre-installed "libcap" package version on the build system and appropriately set a global def macro LIBPCAP_VERSION. This is then used to determine support for certain libpcap functions. Not all functions were introduced into libpcap all at the same, but steadily over the many releases of that library.

This allows jNetPcap to be compiled on systems with libpcap version 0.8.0 or higher. If ever needed we could even make the compatiblity level lower then that, but I don't see any need for it at this time. However if we ever needed to support an older OS such as RHEL 2 or 3, then it would actually be quiet trivial to disable certain functions and provide Pcap.is*Supported accessors just like jNetPcap provides support for Pcap.isSendPacketSupported and few others.

This weekend we ported to Redhat Enterprise Linux 4 and jNetPcap already compiled on ubuntu platforms with just a tiny whimper. So I'm also going to release RHEL4 and ubuntu with this next release.

Over next quarter (2 - 3 months):

I will work on OpenSolaris 2009 and Solaris 10 which are ready to be ported.

After Solaris its is FreeBSD and I'm also working on OpenDarwin and OSX10.5 (Leopard). BSD port should make port to OSX/Darwin fairely straight forward.

Lastly, I've placed a large order for duplicate servers in AMD64bit architecture. The AMD port will be compatible with intel 64 arch. Since the number of supported platforms is growing rapidly, the build scripts will be changed to allow multi-platform network builds to be done from centralized location. This will be a separate jnetpcap module dedicated for master builds.

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:

• Pcap.nextEx Example featured below

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

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