November 2009

I'm thinking about adding a new type of handler (may be into rev 1.4). Performance is always an issue. This new handler would be more efficient then PcapPacketHandler but less efficient then JBufferHandler. In terms of efficiency, JBufferHandler is the most efficient since it doesn't do any packet copies or processing. It is simply peered with the libpcap provided packet buffer. The negative with this handler is that it must be processed immediately in the loop and can not be stored on a queue unless it is by copy.

Since it is a common requirement to store packets on a queue, buffer, list or whatever so that captured packets can be processed later and possibly in another thread, even when the fast JBufferHandler is used the packet data must still be copied so that it can be stored away, somewhere, temporarily.

This is where the new handler comes in. It would be able to copy both the pcap headers and packet data into a large user buffer as efficiently as possible, until it is filled up. It would then dispatch to the user, but only when the buffer is full. This type of bufferring would be best suitable for high packet rates and non interactive traffic. Although normal pcap timeout and buffer settings would still be applicable allowing for interactive traffic.

The user would call on a specialized Pcap.loop or Pcap.dispatch method, just like its done currently with other types of handlers, and specify the size of the user buffer to use. jNetPcap then would allocate a new type of buffer object, one which stores both a series of pcap headers and packet data, and dispatch that buffer object only when that buffer becomes full. The buffer would be filled by native method as fast as possible, without having to enter java space or do any behind the scene peering on a per packet basis. It would only need to invoke handler method and with no packet peering once the buffer is full.

Hi Mark ^^
EDITED !
i just link to the main web and found this pdf
http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf
so i can use inbound and outbound to separate them. Right ?^^

Sorry..
Thank you

Champ

This bug has resurfaced and I have reopened a ticket for it.

This a synchronization problem is in JMemoryPool class which is used when packet contents are copied around (ie. in PcapPacket and JMemoryPacket constructors and transferTo methods). It was not enough to use a synchronized list for caching memory blocks, but also needed to externally synchronize around iterators returned by the synchronized list. It appears that synchronized list does not return synchronized iterators.

The work around is to synchronize around areas of the user code that invoke either PcapPacket or JMemoryPacket copy constructors. Also around any of the transferTo methods. You should synchronize on the JMemoryPool object as returned by JPacket.getMemoryPool() method.

Here is a sample:


synchronized (packet.getMemoryPool()) {
JPacket packet2 = new PcapPacket(packet);
}


This problem has been fixed and code checked in. The fix will be released with the next release of jnetpcap-1.3.a2 (possibly this weekend).

This is what i saw in the log file today...i am sorry but i can't give any more info, that's all i have....do you have any idea what could have happened? This happens from time to time and it's always coming from the routine that does packet processing so i am guessing that it has something to do with malformed packets or something? Can you please tell me how to avoid this because the application should not crash like this...Error messages are not always the same but like i said, they always come from the same routine...since the routine is enclosed in try{}catch block i can sometimes catch the error but once in a while the application just crashes..

java.lang.NullPointerException
at org.jnetpcap.packet.JPacket.getHeader(JPacket.java:660)
at org.jnetpcap.packet.JPacket.getHeader(JPacket.java:640)
at java.lang.Thread.run(Thread.java:619)
PACKET DEBUG
------------
JMemory: JMemory@7f3f300e1294class org.jnetpcap.packet.PcapPacket: size=78 bytes
JMemory: owner=nio.JMemoryPool$Block.class(size=10240/offset=6468)
------------
PACKET DUMP
0000:*00 0a 8a 27 b8 80 00 30 48 32 72 86 08 00*45 00 ...'...0H2r...E.
0010: 00 40 d8 d5 40 00 40 06 2f 80 55 5e 40 14 c3 1d .@..@.@./.U^@...
0020: d9 d2*00 6e 06 86 c4 53 d9 dd 7c e1 ce 2c 50 18 ...n...S..|..,P.
0030: 16 d0 73 4b 00 00*2b 4f 4b 20 50 61 73 73 77 6f ..sK..+OK Passwo
0040: 72 64 20 72 65 71 75 69 72 65 64 2e 0d 0a* rd required...

------------

java.nio.BufferUnderflowException
at org.jnetpcap.nio.JBuffer.getUShort(Native Method)
at org.jnetpcap.protocol.network.Ip4.id(Ip4.java:1699)
at org.jnetpcap.protocol.network.Ip4.decodeHeader(Ip4.java:1530)
at org.jnetpcap.packet.JHeader.decode(JHeader.java:530)
at org.jnetpcap.packet.JPacket.getHeaderByIndex(JPacket.java:690)
at org.jnetpcap.packet.JPacket.hasHeader(JPacket.java:913)
at org.jnetpcap.packet.JPacket.hasHeader(JPacket.java:887)