1

Hi I was using this example for offline packet capture using JNETPCAP. But I am getting this exception all the time, illegalarguementexception wirelen < buffer len

Any idea how can I resolve this problem?

P basak
  • 4,874
  • 11
  • 40
  • 63
  • Do you have a valid capture file? – user207421 Dec 05 '12 at 05:54
  • yes the capture file is valid, every captured files are giving the same exception. – P basak Dec 05 '12 at 05:56
  • Post your exception stack trace. Looks like your wirlen arguments is lesser than buffer length which is not expected by your program. – sakthisundar Dec 05 '12 at 06:08
  • hi the exception is from the JNETPCAP library which is just one line I posted. This problem seemed to occur in many cases, i found on their forum. But no workaround is given for offline capturing. current solutions existing for other cases. – P basak Dec 05 '12 at 06:26
  • There is no such thing as "offline capturing"; either you're capturing from a device or you're reading a saved capture that was written to a file. In the former case, it's not offline; in the latter case, the capture was done when the file was written, and it's probably a program with the program that wrote the file, not with jNetPcap. The latter is what's happening here, so whatever file you're reading was written by a buggy program. – user16139739 Jul 06 '23 at 08:55

1 Answers1

0

In my case, Wireshark shows issues as well, for exactly the same packets where jnetpcap processing fails: enter image description here

I'm using the nextEx(...) API and was able to "skip" such problematic issues by catching the IllegalArgumentException and just continue with the next call to nextEx(...) and get through the file.

schneida
  • 729
  • 3
  • 11
  • 37
  • Is this doing a live capture on the Npcap loopback device on Windows, or is this reading a capture file that was captured on some other machine? – user16139739 Jul 06 '23 at 08:57
  • If memory serves, this was done on Windows loopback with jnetpcap - BUT I had a bug in the capture logic that led to those corrupted files (accessing old `JPacket` from the `nextEx(...)` API without copying them later). So first mistake was the corrupt capture, second mistake was jnetpcap not being able to read said capture - both problems solved now for me! – schneida Jul 07 '23 at 12:15
  • "this was done on Windows loopback with jnetpcap" JNetPcap runs atop with either WInPcap or Npcap, so this was really done with WinPcap or Npcap. "accessing old JPacket from the nextEx(...) API without copying them later" `nextEx(...)` probably uses `pcap_next_ex()`. `pcap_next_ex()`, if called more than once with the same arguments, overwrite the structures passed to it, so, yes, a second call to `pcap_next_ex()` could scribble on the results of the previous call, so you have to copy the results. – user16139739 Jul 08 '23 at 07:59