Hi,
I get an exception if I read to much packets from an offline file. The offline file has more than 100 000 packets. The problem is that the exception occur short before all packets are read. When I limit the dispatch to 50 000 packets the exception occur short before it's finished and if I limit it to 80 000 it also occur short before it's finished.
fr.tcp.net.ExtractResponseTimes.testTcpReassembly2(ExtractResponseTimes.java:49)
pcapOffline.dispatch(40000, controller, pcapOffline);
java.lang.IllegalArgumentException: Invalid [68,598,530) range.
at org.jnetpcap.nio.JMemory.peer(JMemory.java:391)
at org.jnetpcap.nio.JBuffer.peer(JBuffer.java:269)
at org.jnetpcap.packet.JPacket.getHeaderByIndex(JPacket.java:687)
at org.jnetpcap.packet.JPacket.hasHeader(JPacket.java:913)
at org.jnetpcap.packet.JPacket.hasHeader(JPacket.java:887)
at org.jnetpcap.protocol.tcpip.HttpAnalyzer.processPacket(HttpAnalyzer.java:80)
at org.jnetpcap.packet.analysis.JController.processHeaders(JController.java:331)
at org.jnetpcap.packet.analysis.JController.processPacket(JController.java:397)
at org.jnetpcap.packet.analysis.JController.processInboundQueue(JController.java:349)
at org.jnetpcap.packet.analysis.JController.nextPacket(JController.java:292)
at org.jnetpcap.packet.analysis.JController.nextPacket(JController.java:122)
at org.jnetpcap.Pcap.loop(Native Method)
at org.jnetpcap.Pcap.loop(Pcap.java:2223)
at fr.tcp.net.ExtractResponseTimes.testTcpReassembly2(ExtractResponseTimes.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
I would think the problem would be my JPacketHandler but it's not stacktraced.
Any suggestions how to avoid this or why it occurs?
Cheers
Tim
The error occurs in this method in HttpAnalyzer line 4.
public boolean processPacket(JPacket packet) throws AnalysisException {
Http http = httpLocal.get();
if (packet.hasHeader(http)) {
processHttp(packet, http);
}
return true;
}
I would need to see what the packet looks like. Even though from the trace it looks like the packet came from the Pcap.loop down at the bottom, it may actually have been a brand new injected packet by TcpAssembler. It puts a reassembled packet back on top of the "inbound" queue so it gets processed again by the analyzer. I suspect there is something wrong with the reassembled packet.
I don't think this is something you can debug. Would it be possible for me to take a look at your capture file? Either let me download it or I can give you a private area on the server where you can upload. The file will be strictly confidential and not published anywhere.
Well, I also stepped in your code nevertheless I thought the problem has to be in my code 
.
I really would like to provide you the capture file but that are captured production data and I would breach a lot of policies 
.
Maybe you can build you an own file with more than 100 000 tcp packets.
The problem is that it is always a different packet when the error occurs depending on the loop limitation. And if it is infinite it is also short before the complete package is finished. It is approx. ~150 packets before it finishes.
I know just debugging it with the pcap file would be much easier to determine the error 
.
I don't believe tcp analyzers properly timeout entries and they don't handle extremely long tcp streams either at this point. Another words that code is not ready for prime time yet. Its suitable for testing and getting familiar with it, but it still needs a lot more work. 
The problem is that 1.2 is not ready for prime time either 
That is why version 1.2 has my highest priority right now. I'm working on header and field containers which is the last piece of code I need to include in 1.2 release. It is essential because the current jheader definition implementation can't handle all types of protocols. This will allow 1.2 to mature very nicely with new protocols coming on board.
After containers and 1.2 release itself, analyzers are next on my list.
Don't hurry on this topic. I can live with this bug with a try catch block .