I am running the IpReassemblyExample on a pcap file
and getting the following exception:
Exception in thread "main" java.lang.IllegalArgumentException: wirelen < buffer len
at org.jnetpcap.packet.JScanner.scan(Native Method)
at org.jnetpcap.packet.JScanner.scan(JScanner.java:364)
at org.jnetpcap.packet.JPacket.scan(JPacket.java:957)
at IpReassemblyExample$1.nextIpDatagram(IpReassemblyExample.java:376)
at IpReassemblyExample.dispatch(IpReassemblyExample.java:523)
at IpReassemblyExample.bufferLastFragment(IpReassemblyExample.java:510)
at IpReassemblyExample.nextPacket(IpReassemblyExample.java:579)
at org.jnetpcap.Pcap.loop(Native Method)
at org.jnetpcap.Pcap.loop(Pcap.java:2417)
at IpReassemblyExample.main(IpReassemblyExample.java:350)
Hi. I have a problem with filter:
Pcap pcap = Pcap.openLive(netDevice.getName(), sp.getQuantiByte(), sp.getFlag(), sp.getTimeout(), errors);
if (pcap == null) {
System.err.printf("ERRORE NELL'APERTURA DEL DEVICE: " + errors);
}
PcapBpfProgram program = new PcapBpfProgram();
int optimize = 0;
int netmask = 0;
String expression="port 23";
if (pcap.compile(program, expression, optimize, netmask) != Pcap.OK) {
System.err.println(pcap.getErr());
return;
}
if (pcap.setFilter(program) != Pcap.OK) {
System.err.println(pcap.getErr());
return;
}
System.out.println("Il filtro è stato applicato con successo: " + expression);
JPacketHandler
public void nextPacket(JPacket pacchetto, String usr) {
System.out.println(pacchetto.toString());
}
};
pcap.loop(sp.getNumPack(), handler, "CONTROLLO");
pcap.close();
This code continue to analyze all traffic,but it should analyze only traffic on PORT 23.
I would like to propose a split of jNetPcap monolithic structure into 3 main modules that would be developed independently:
Since the wrapper code hardly ever changes it makes no sense to drag the wrapper code from release to release. On the other hand the Decoder/Dissector code is much more fluid with constant updates and bug fixes. Analysis code is not under heavy development right now, but when it does it will also be the cause of many update releases.
There are some API implications with this split. This would mean that all API references that would end up in the decoder or analyzer module have to be removed from libpcap wrapper module. Functions such as Pcap.loop, Pcap.dispatch, Pcap.next, Pcap.nextEx and Pcap.analyzer would have to be moved from the main Pcap class into new factory classes in their respective modules.
The dependencies between modules could be carefully crafted so no module would be dependent on any other module. For example, libpcap wrapper would only be dependent on libpcap library and nothing else. Decoder module would become only dependent on something that provides a packet buffer sources and that could be abstracted in such a way as not to be dependent on libpcap wrapper. Same with the analyzer module, it could be made dependent on something that provides decoded packets and not on decoder modules directly.
This breakup would also be very helpful with the other project, jNetStream.
In retrospect, I think it was a mistake to combine the libpcap wrapper which has been always most stable with ever changing decoder code. The breakup would mean that there would be 2 or 3 modules to install. It would also facilitate better sharing of functionality between different projects and other packet sources that are not necessarily libpcap based.
Hi
I'm trying to write a little packet sniffer with jnetpcap.
In the examples on the site,is always used the method:
public void nextPacket():
For these two interface this method is defined as:
Interface: JPacketHandler
method: public void nextPacket(Jpacket packet,T user);
Interface: JBufferHandler
method: public void nextPacket(PcapHeader header,JBuffer buffer,T user);
Ok,now,what I'm asking to me is:
What rapresent @param T user ???
in the API i read:
Parameters:
....
....
user - user supplied object
But I don't understand what exactly rapresents this parameter.
Someone can help me to understand? 
Thank you
Hi,
I'm starting to look at how/if we can incorporate some higher-level type processing (e.g., analysis) to the software that we have that already uses jNetPcap for processing previously-captured PCAP files, so I've been searching around the forums, etc. for info. It looks like most of the threads about this (e.g., HTTP analysis, SIP analysis, etc.) are from 2009, and that the analysis support in jNetPcap was "in flux", so I was wondering what is the status of that now?
Also, it looks like most of the previous inquiries were for analysis with live capture, so I was wondering does this work with previously-capture PCAPs also?
Thanks,
Jim
I added feature#2939537 to release 1.4 - Lazy scan for packet decoding. This feature defers the process of decoding a packet until the packet contents are accessed. Currently with packet based handlers, the packet is decoded in the same thread as being captured. The feature delays the decoding the step until packet contents are accessed through one of the packet's header accessors.
There is no change or any known impact to the current usage of the API. The packet can be forced to scan as well with a new API method JPacket.scan() which cause the packet to be decoded. Also the usage of the JPacket.hasHeader or JPacket.getHeader accessors will also trigger a packet decode if the packet has not been previously decoded.
The benefit of "lazy decoding" is that packets are not automatically decoded right within the same thread that also captured the packet. Packets are typically put on an inter-thread queue and processed later by another worker thread. This simple mechanism delegates the decoding of packets, by user's choosing, to the secondary worker thread and provide maximum efficiency within the capture thread for capturing packets by not tying up the CPU with packet decoding task.
This feature is especially useful when used in multiple threads. There is no performance gain when the packet is accessed within the same capture thread as that will cause the packet to be decoded and captured by the same handler.
Hi
I'm new with pcap.
I wont to realize a simple sniffer in this way:
1. User choose a PROTOCOL
2. Sniffer extract all packets,according to chosen PROTOCOL
Is it possibile with jnetpcap ?
If possibile,Can you give me a general idea to proceed ?
Thank you
Hi,
I'm trying to port my jNetPcap code to a 64-bit Ubuntu system. Here's the 'uname -a':
Linux Demo 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux
I downloaded 'jnetpcap-1.3.a1-1.ubuntu9.i386.tgz' and extracted the .jar and .so file from it, and I was able to re-compile my code that uses jNetPcap.
However, when I tried to run one of my test apps, I got:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /Data/libjnetpcap.so.1.3.a1: libpcap.so.0.8: wrong ELF class: ELFCLASS64
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at org.jnetpcap.Pcap.
at jnetsinglenew.main(jnetsinglenew.java:71)
I think this is because the libpcap is 64-bit, but I checked on the system, and I don't see any 32-bit libpcap.so.
So, I was wondering: Is there any way to get this working on this system?
Thanks,
Jim
Hi,
I have some code that uses/works with PcapPacket to process info from PCAP files, and I need to modify it to do some stuff with the packet payloads.
I've seen threads like this:
but, it looks like PcapPacket doesn't have a getPayload() method, so I was wondering how I can get the payload?
Thanks,
Jim