December 2009

Hi all. I before use jpcap but it not updated I use yours.
One qestion is became

I use it

		_jpacketHandler = new PcapPacketHandler()
		{

			public void nextPacket(PcapPacket packet, String user)
			{
				try
				{
					byte[] data = packet.getByteArray(0, packet.size());
					NioBuffer buf = NioBuffer.wrap(data);
					buf.order(ByteOrder.LITTLE_ENDIAN);

					buf.get(new byte[26]);

					byte[] sIP = new byte[4];
					byte[] dIP = new byte[4];

					buf.get(sIP);
					buf.get(dIP);

					String sourceIP = InetAddress.getByAddress(sIP).getHostAddress();
					String descIP = InetAddress.getByAddress(dIP).getHostAddress();

					buf.get(new byte[20]);

					if(buf.hasRemaining())
					{
						int size = buf.getUnsignedShort();
						PacketType type;
						if(sourceIP.equalsIgnoreCase("192.168.0.102"))
						{
							type = PacketType.CLIENT;   //client
						}
						else
						{
							type = PacketType.SERVER;  //server
						}

						if(buf.remaining() >= (size - 2))
						{
							byte[] packe = new byte[size - 2];
							buf.get(packe);

							jds.jn.network.packets.Packet jdsP = new jds.jn.network.packets.Packet(type, NioBuffer.wrap(packe).order(ByteOrder.LITTLE_ENDIAN));
							PacketReceiver.receive(JNetPcap.this, jdsP);
						}
					}

				}
				catch (UnknownHostException e)
				{
					e.printStackTrace();
				}
			}
		};

	}

I know is stupied... How it simply...
It code is not work good, many packets is not send by client or server, I don't known what..
Help me simply this code...

I'm extracting Call_id from SIP message through this block:

public void nextPacket(JPacket packet, String user)
{			
    if(packet.hasHeader(sipHeader))  //sipHeader is of Sip
    {
         System.out.println("Get length of the packet : " + sipHeader.getLength());
         System.out.println("Get Sip header");
         if(sipHeader.hasField(Sip.Fields.Call_ID))
         {
             System.out.println("Get Call Id " + sipHeader.fieldValue(Sip.Fields.Call_ID));
         }else
         {
	     System.out.println("No call id in this fragment");
         }
         System.out.println(packet);
         System.out.println(packet.toHexdump());
   }
}

The result is that some SIP message has no Call_Id extracted. But hexdump shows that there is Call_id encoded in the message. What shall do to these cases?

The output and message and wireshark decoding result attached.

$ uname -a
Linux localhost.localdomain 2.6.31.6-166.fc12.x86_64 #1 SMP Wed Dec 9 10:46:22 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
$ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)

I've tried this case in a 32-bit winxp, got the same result.

Thansk.

We (many thanks to Vikram Roopchand) have been working on an issue over last week or so related to packet drops with certain VMWare products and combinations of host and guest operating systems.

Let me demonstrate from one of many different test runs we've attempted:

Ubuntu 9.04 guest on WinXP host using VMTools pcnet32 drivers:
Opening eth2 interface
#000000: recv=10050, drop=9, ifDrop=0 pps=1126.13 bps=8287.78Kb
#010000: recv=20063, drop=25, ifDrop=0 pps=1118.82 bps=8346.30Kb
#020000: recv=30094, drop=49, ifDrop=0 pps=1138.56 bps=8447.87Kb
#030000: recv=40098, drop=61, ifDrop=0 pps=1112.97 bps=8322.98Kb
#040000: recv=50096, drop=67, ifDrop=0 pps=1130.84 bps=8447.94Kb
#050000: recv=60107, drop=72, ifDrop=0 pps=1120.07 bps=8344.61Kb
#060000: recv=70115, drop=84, ifDrop=0 pps=1126.89 bps=8401.01Kb
#070000: recv=80135, drop=100, ifDrop=0 pps=1129.43 bps=8435.64Kb
#080000: recv=90134, drop=102, ifDrop=0 pps=1132.25 bps=8438.27Kb
#090000: recv=100139, drop=107, ifDrop=0 pps=1126.89 bps=8389.70Kb

The test application simply invokes Pcap.loop using JBufferHandler method and provides an empty handler adds up total packet received byte count and number of packets. There are no packet copies or any type of processing. Libpcap statistics are retrieved using Pcap.getStats method.

You can see some packets being dropped by libpcap as indicated by the "drop" counter. Other guest operating system such as fedora and debian do not drop packets. Wireshark sometimes does not drop packets, but does in other test scenerios.

I started work on 1.4.b0001. The new branch-1.4 is based branch-1.3. Its using exact same code base, but will have few new features added and expanded platform support. Any bugs that will be discovered in 1.3, the fixes will be incorporated into 1.4 as well.

Here is what I'm working on right at the moment:

1) Adding the "lazy decode" feature.

2) Adding JPacketBufferHandler feature.

Lazy decode is when packet scan/decoding is triggered only when the packet contents are first accessed and not when the packet is created. This will delay packet decoding to a time when its actually needed. This will allow packet decoding to be delayed by the user, to be performed in other threads and not the capture thread.

The JPacketBufferHandler is a new dispatcher handler that is designed for efficiency and minimization of java overhead during capture. This new handler uses a new container object JPacketBuffer which is designed to allocate large user memory buffer to store multiple packets. The default allocation size is 1MB and allows storage of anywhere between 500 to 10,000 packets depending on the packet size. Both the pcap header and the packet contents are stored in the buffer. The native dispatcher copies incoming packets from libpcap into this buffer until its full. Only when the buffer is full is the buffer dispatched to java handler with all of the captured packets. The JPacketBuffer container provides an iterator to access packets within the buffer. This minimizes interaction with java as hundreds if not thousands of packets can be efficiently stored in the buffer before any interaction with java has to occur. After the buffer is dispatched to java, a new buffer is allocated to receive more packets.